🗼How it works

Protocol description for the working of the watchtower

Table of Contents

Introduction

Participating Entities

Protocol Description

Process Flow

Proof of Diligence

Introduction

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:

  1. Trustfree: provides Proof of Diligence of watchtowers with Ethereum trust (through EigenLayer)

  2. Decentralized: provides a Proof of Location for verifying the geolocation of watchtowers and enforcing desired physical decentralization.

  3. Programmable: provides SLA smart contracts to scale the number/stake of watchtowers and their decentralization properties with the value of vulnerable transactions.

Participants and Entities

The diagram summarizes the different entities participating in the Watchtower network

Participants in the watchtower network

Stakers

EigenLayer (re)stakers who stake/delegate on/to EigenLayer operators providing Ethereum's crypto-economic trust to the watchtower network.

Operators

EigenLayer operators are a pool of staked node operators who run the watchtower client

Users/Dapps

Set of Dapps built on top of the Watchtower networking utilizing it's real-time transaction tracer APIs

Watchtower (watchtower client)

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 nodes

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.

Smart contracts

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

Protocol Description

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.

Process Flow

The diagram summarizes the sequences of steps involved in the Diligence Proof Submission process

Process Flow

Pre-requisites - Witness Chain watchtowers are expected to be registered as EL operators

  1. The WitnessChain Admin initiates a Bounty for each L2 Chain designated for monitoring.

  2. Bounty Miners, running Witness Chain Watchtower (WT) clients, register on the Watchtower network and monitor State Assertions on the L2OO smart contract.

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

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

  5. If reconciliation fails, the Watchtower submits an Alert to an AlertManager Contract in addition to providing the PoD.

  6. The cycle concludes with a call to a rewardBounty Smart Contract function, triggered periodically to compensate the watchtower client with a diligence bounty.

Proof of Diligence

The scope of currently described PoD construction is limited to op-stack based L2 chains only

Proof of Diligence (PoD) Construction and Bounty Mining (Go Client)

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.

Notes

The intermediate state roots

  • 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

PreviousWatchtower Protocol (Architecture v1)NextWatchtower Roadmap

Last updated