🏦Watchtower Architecture

Software Architecture - client, APIs and contracts

Architecture

WitnessChain Watchtowers' software stack comprise of

1. Node Client (written in Go)

2. On-chain Smart Contracts on Ethereum

3. 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

1. Output State Root Extraction from L1

2. Output State Root Extraction (Tracer execution) from L2 Node

3. Comparison

4. Smart Contract integration

Sequence of Steps

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.