Skip to content

Architecture

The Webb protocol architecture is modelled off the ChainBridge and Tornado Cash architectures. We merge and augment both protocols and increase the relayer responsibilities to design our private bridge protocol. The modifications can be summarized as:

  • Augmenting Tornado's into Anchor's which additionally track an edge list to other Anchors.
    • Anchors are private transaction systems that function both as Tornados but also as cross-chain bridges.
    • Anchors use a zero-knowledge one-of-many merkle tree membership proof instead of one for a single merkle tree.
    • Anchors can mint/burn the underlying token being deposited and withdrawn.
  • Augmenting ChainBridge's Bridge into a private bridge protocol.
    • We create a new AnchorHandler which modifiers the edge list of Anchors needing updates.
    • We augment the Bridge relayers w/ a multi-party threshold signing scheme, so that one or many threshold networks can govern the bridge.

Example diagram of the architecture and governance of cross chain private bridging of WEBB tokens on EVM chains:

Architecture

Definitions

commitment

A commitment is generated upon a users deposit into an anchor and later used in a ZK proof for withdrawal. The commitment is the PoseidonHash(DestinationChainID + nullifier + secret). DestinationChainID is a user input indicating the chain they will withdraw on.

neighborRoots

Every LinkableAnchor stores its neighborRoots, a mapping containing the merkle roots of the anchors it is connected to. Each anchor stores a history of 30 roots, so users can verify against a historical root while new deposits occur.

resourceID

resourceID's provide a chain agnostic identifier to connect tokens with the handlers and anchors that interact with that token. A resourceID for a given token and denomination is defined as the hash of that token name concatenated with its denomination. The resourceID for a token used in public bridging that is not tied to a denomination will simply be the hash of its token name.

Main System Components

Anchor

Anchors are augmented Tornado Cash Tornados that possess graph-like data structures and functionality; that is, they can be connected and have edges. Users interact with Anchors through a deposit/withdraw API. To deposit into a Webb Anchor, a user generates a hashed commitment and submits this to the Anchor's merkle tree for insertion. The commitment contains the chainID of the chain they wish to withdraw on as well as some secret data.

Bridge

The Bridge contract allows for both fixed denomination, private bridging and standard, public bridging of assets. The private bridging functionality uses an AnchorHandler to track the state of connected chains while the standard bridging uses an ERC20Handler. The Bridge's state is is maintained by a set of relayers through voting. These relayers vote to update the latest merkle roots of connected anchors in the case of private bridging, and to distribute bridged assets in the case of public bridging.

AnchorHandler

Every Bridge contract has a corresponding AnchorHandler to add or update the neighborRoots of the anchors on that chain after relayers pass and execute a proposals containing connected anchors' root updates. The Handler updates a specific anchor based on a mapping of a resourceID to a LinkableAnchor contract address which is set by the Bridge admin.

ERC20Handler

Every Bridge contract has a corresponding ERC20Handler to keep track of deposits on a connected bridge. This allows the user to bridge tokens publicly and a fixed denomination as seen in standard bridges. See Chainbridge's Documentation for more detail on this standard bridge architecture.