🗼How it works
Protocol description for the working of the watchtower
Last updated
Protocol description for the working of the 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
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.
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
DiligenceProofManager: Submit diligence proofs and get rewarded for watching the network
AlertManager: Raise alerts in case of identifying an invalid state assertion by an L2
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
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.
If reconciliation fails, the Watchtower submits an Alert to an AlertManager Contract in addition to providing the PoD.
The cycle concludes with a call to a rewardBounty Smart Contract function, triggered periodically to compensate the watchtower client with a diligence bounty.
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
prefix := []byte("\x19Ethereum Signed Message:\n32")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.
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