How it works
Protocol description for the working of the diligence watchtower
Last updated
Protocol description for the working of the diligence watchtower
Last updated
Security for optimistic rollups (ORs) is derived from dispute resolution at L1 for suspicious transactions. The first line of defense is offered by parties who first identify suspicious transactions.
Currently deployed ORs rely on relatively centralized (and trusted) entities who offer this line of defense; e.g., Arbitrum’s state assertion can only be disputed by a set of 12 whitelisted defensive validator nodes.
The surge in demand for app-specific rollups and platforms to support them (e.g., Base and Eigenlayer) results from increasing value and diversity of transactions relying on L2s. In turn, there is a need for decentralized and trust-free validators who diligently raise the alarm when they detect a suspicious transaction.
Witness Chain Watchtowers provide the first line of defense for rollups, which is:
Trustfree: provides Proof of Diligence of watchtowers with Ethereum trust (through EigenLayer)
Decentralized: provides a Proof of Location for verifying the geolocation of watchtowers and enforcing desired physical decentralization.
Programmable: provides SLA smart contracts to scale the number/stake of watchtowers and their decentralization properties with the value of vulnerable transactions.
The diagram summarizes the different entities participating in the Watchtower network
EigenLayer (re)stakers who stake/delegate on/to EigenLayer operators providing Ethereum's crypto-economic trust to the watchtower network.
EigenLayer operators are a pool of staked node operators who run the watchtower client
Set of Dapps built on top of the Watchtower networking utilizing it's real-time transaction tracer APIs
Watchtower is the independent validation entity which cross verifies the L2 state assertions made on the L1. These watchtowers are incentivized to watch and validate the assertions made by the L2 proposers (even in a happy path scenario (avoiding the lazy-validator problem)) with the help of Proof of Diligence
Watchtowers also watch out for L2 transaction inclusions in a block.
L2 network nodes run by the operators alongside the watchtower client. This is the node which computes the state for L2 and is used by the watchtower client to validate the state assertions on the Layer 1. These are L2 archive nodes.
L1
A set of smart contracts deployed by WitnessChain on Layer 1 (Ethereum). Following are the descriptions of the smart contracts:
OperatorRegistry: Register a EigenLayer node operator as a watchtower in the network
AlertManager: Raise alerts in case of identifying an invalid state assertion by an L2
L2
A set of smart contracts deployed by WitnessChain on Layer 2 (Ethereum) to aggregate the proof of diligence. Following are the descriptions of the smart contracts:
DiligenceProofManager: Submit diligence proofs / inclusion proofs and get rewarded for watching the network
The Witness Chain watchtower client runs a system of 2 proofs of diligence
State Assertions : Validate the L2 state assertions on Ethereum and generate the proof of diligence
Transaction Inclusion: Validate the inclusion of a L2 txn in a Block and generate the proof of inclusion
A Watchtower client register's using the OperatorRegistry smart contract
On startup, the watchtower subscribes to an L1 node for the real-time events of the L2 assertions (OutputProposed event of L2OO in case of optimism). At the same time, the watchtower is also maintaining the L2 state and executing the transaction from the sequencer commitments on L1.
When the watchtower notices a state assertion being made on L1, it quickly validates it against the corresponding L2 state for that block number using the state it has been independently advancing.
Two cases might exist:
State assertion matches the computed L2 state
State assertion does not match the computer L2 state
In this case, the watchtower raises an alarm via the AlertManager contract to let the participants be aware of the misbehavior of the
Regardless of the case, the watchtower then prepares the signed proof of diligence and submits it to the DiligenceProofManager smart contract to claim their rewards. We call this the bounty mining process, and this ensures the diligent nature of a watchtower even in case of a happy path.
The diagram summarizes the sequences of steps involved in the Diligence Proof Submission process
Pre-requisites - Witness Chain watchtowers are expected to be registered as EL operators
The WitnessChain Admin initiates a Bounty for each L2 Chain designated for monitoring.
Bounty Miners, running Witness Chain Watchtower (WT) clients, register on the Watchtower network and monitor State Assertions on the L2OO smart contract.
Upon receiving an event from the L2OO contract, WT clients commence validation by tracing (re-executing) transactions on the L2 Archive Node for the proposed block. (A Witness Chain Watchtower node runs both the watcher software and L2 Archive node)
Upon successful reconciliation between L2OO and L2 Node Tracer Results, the watchtower posts a Proof of Diligence (PoD) on the Witness Chain smart contract, called the DiligenceProofManager.
In the newer v2 release, the Diligence Proof Manager smart contract is created on a Layer 2 Chain. In the earlier releases, this was on Ethereum. The change is done to save gas costs for the watchtower operators
If reconciliation fails, the Watchtower submits an Alert to an AlertManager Contract in addition to providing the PoD.
The Aggregator, which is a centralized entity for now, aggregates the proofs by listening on the events from the DiligenceProofManager contract, computes the winning watchtower and submits the winner details (points) on the Settlement contract (we call it the EigenTower Contract). The Settlement contract is hosted on Ethereum.
The Witness Chain Watchtower client also accumulates the proofs (at the off-chain client side) for a block of period, before posting on the L2 contract. This is applicable for Proof of Transaction Inclusions as it accumulates proofs across multiple blocks before posting it on the L2 contract
The scope of currently described PoD construction is limited to op-stack based L2 chains only. We monitor Optimism, Base and Zora
The actual proof of diligence, which is verified on the DiligenceProofManager smart contract and is used for rewards is defined as below:
Signed PoD = Sign(Hash(prefix || PSH)), where
`prefix` is added just for compliance with ethereum chain
PSH = Hash(latestBlockNumber || midPointPenultimateBlock || midPoint || version_number)
Hash = Keccak256Hash
latestBlockNumber = the L2 block number for which the PoD is signed/computed. This is the same L2 blocknumber that is currently proposed on L2OO
midPointPenultimateBlock = the state root after the midpoint transaction of the block before the latestBlockNumber (ref. intermediate state roots)
midPoint = the state root after the midpoint transaction of the latestBlockNumber’th block
version_number = proof of diligence version number, which is incremented every time there is a protocol update. It is currently set to `0`
The SignedPoD is submitted to the DiligenceProofManager smart contract.
Proof of inclusion is a guarantee provided by the watchtower that it has seen the particular txn (with a given txn hash) being included in a L2 block. This is presented in the form of a signed Txn Receipt received from the watchtower node
These receipts can belong to unsafe, safe, or finalized blocks of L2 and the status can be queries via the transaction tracer API
Many blocks' worth of txn receipts are batched to commit to the contract, and the batch size is configured on the Diligence Proof Manager (DPM) contract
Proof of inclusion tech workflow:
Upon startup, the watchtower subscribes to L2 block head
On every new block added, it performs following action(s)
Fetch all receipts in the block
Prepare Proof of inclusion for the block
Add the proof of inclusion of the block (receipt trie root hash) to a merkle tree
Once batch is completed -> post the signed batch to the submission chain
The watchtower also caches these receipts for the transaction tracer APIs to query from, reducing the latency for Dapps using the service
The proof of inclusion , which is submitted to DiligenceProofManager smart contract and is used for rewards is defined as below:
Signed PoI = Sign(Hash(prefix || PSH)), where
`prefix` is added just for compliance with ethereum chain
PSH = Hash(blockNumber,inclusionProofMerkleRoot,versionNumber)
Hash = Keccak256Hash
blockNumber = decimal representation of the block number of last block in the batch
inclusionProofMerkleRoot = the hexadecimal encoding of root hash of the merkle tree
versionNumber = the proof of inclusion version number, it is currently set to 0
As specified in PoD construction, the protocol requires the watchtower to commit to some of the intermediate states of execution across 2 proposed output roots.
To achieve this we make use of (op-geth in op-stack) geth’s tracer APIs
In particular, we use the `debug.intermediateRoots` by providing it the block hashes
This works via a re-execution of transaction from an earlier state in the history which is available to the node, which in our case would be the state at latestBlockNumber-2’th block and latestBlockNumber-1’th
As it re-executes the transaction in those specific blocks, it stores the state roots after each transaction and outputs them in a list for our watchtower client to further process and get the midpoint root alone
This ensures, that node had the head state after each L2 block and that it actually executed the
The merkle tree is formed by placing the receipt root hashes of the blocks involved in the batch at the leaf nodes
As an example if batch size is 4, and 455 happens to be a start block of the batch, then the tree would look something like shown in the example figure above
4 consecutive blocks, 455-458 both inclusive, are part of the batch
Receipt root hash of each of these blocks is placed as leaf node in the merkle tree
node 1,2 hash forms the inclusionProofMerkleRoot for this example batch
Since watchtowers are also required to execute the entire batch of L2 transactions, they can earn rewards by performing their duties diligently. This role closely resembles that of the asserter in the original optimistic rollup system, who posts computation results in exchange for rewards. As a result, one prominent challenge the watchtower design must confront is the “lazy watchtower” problem. This issue arises because of two main reasons:
(1) rational watchtowers may submit arbitrary responses if the results lack verification process
(2) they might opt out of protocol participation if the associated costs outweigh potential rewards.
In essence, the watchtowers must provide a form of evidence for their work and the protocol must offer sufficient incentives to encourage participants to actively and consistently perform tasks.
Read more about the Problem and Solution to it in our research.
