🏦Watchtower Architecture
Software Architecture - client, APIs and contracts
WitnessChain Watchtowers' software stack comprise of
Node Client (written in Go)
On-chain Smart Contracts on Ethereum
Transaction Tracer APIs (for dApps to consume and configure the status)
Node client
At a high level, the process of validation in a watchtower node client has 4 stages
Output State Root Extraction from L1
Output State Root Extraction (Tracer execution) from L2 Node
Comparison
Smart Contract integration
List of Smart Contracts
1. OperatorRegistry
This is Registry-type contract for keeping track of operators. It is used for registering and deregistering new operators. Only registered and delegated EigenLayer operators are allowed into the watchtower network
addToOperatorWhitelist()
Called By | Contract Owner |
Returns | None |
Emits | None |
Adds the list of operators to the whitelist mapping
removeFromOperatorWhitelist()
Called By | Contract Owner |
Returns | None |
Emits | None |
Removes the list of operators from the whitelist mapping
register
Called By | Node operator |
Returns | None |
Emits | None |
Registers the operator as a watchtower
deRegister
Called By | Node operator |
Returns | None |
Emits | None |
Deregisters the operator as a watchtower
2. DiligenceProofManager
The DiligenceProofManager Contract contains functionality for miners (aka Watchtowers) to submit (mine) their Proofs of Diligence for a Bounty Period (which is the period between 2 L2 Txn Batch submissions). After the next L2 output state root is posted on L1, the bounty is rewarded to the miner. Bounties are given for every L2 Output (L2 Block).
setBounty(chainID, amount)
Called By | Owner of the Contract |
Returns | None |
Emits | NewBountyInitialized event |
The owner of the Contract sets the Bounty Amount.
Consider bounties are just reward points for now. Lets say 1 point for every L2 block mined successfully by a WatchTower.
submitProof (chainID, l2_blockNumber, proofOfDiligence, signedProofOfDiligence)
Called By | WatchTower (EigenLayer Node Operator) |
Returns | None |
Emits | NewBountyClaimed event |
Watchtower(s) submits/mine a L2 block by submitting the Hash(intermediate state root) and signing the Hash.
Validations on Contract take care if the right sender is sending this transaction and if the blockNumber is a valid block to be mined.
If the validations go through, the watchtower’s claim is accepted into the bounty, waiting for the rewardBounty to be called at the end of the mining cycle (which is roughly 60 mins on Optimism)
rewardBounty (chainID, l2_blockNumber)
Called By | Owner |
Returns | Winner(WatchTower address) |
Emits | NewBountyRewarded event |
A reward (credit point) is awarded for every L2Block successfully mined by a miner using the MIN logic
When the L2 Block Number moves on to the next one on L2OracleOutput, the bounty is rewarded to the miner (based on minimum submitted hash logic)
3. AlertManager
This contract is used for keeping track of alerts raised by watchtowers
raiseAlert()
Called By | Node Operator |
Returns | Winner(WatchTower address) |
Emits | NewBountyRewarded event |
Raise an alert when there is a mismatch in output root between what is exeucte on L2 Node and asserted on L1 Contract
getAlerts(chainID,L2BlockNumber)
Called By | Node Operator |
Returns | Winner(WatchTower address) |
Emits | NewBountyRewarded event |
Get all alerts raised so far a particular chainID and L2BlockNumber
Assumptions
Currently, watch Period is defined by the L2 Block Number that is obtained from the L2OutputOracle contract. So, a watchtower has to mine for that L2 block number. Any block numbers in the future or in the past will be rejected in the Contract.
One WatchTower can mine only 1 bounty during that period for that L2 block number.
With the current configuration, every WatchTower client runs an archived L2 node.
Last updated
