Glossary

This glossary defines and explains Webb ecosystem specific concepts and terminology.

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.

anchorHandler

Every SignatureBridge 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 SignatureBridge admin.

authority

The nodes that act as a collective to manage consensus on a blockchain network. In a proof-of-stake blockchain—for example, a blockchain that use the Staking pallet from FRAME—authorities are determined through a token-weighted nomination and voting system.

The terms authorities and validators sometimes seem to refer the same thing. However, validators is a broader term that can include other aspects of chain maintenance such as parachain validation. In general, authorities are a (non-strict) subset of validators and many validators are authorities.

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.

merkle tree

Merkle trees’ primary purpose is to prove the consistency of data, and is essentially a tree of hashes. Merkle tree is a tree in which every leaf node is labelled with the hash of a data block and every non-leaf node is labelled with the cryptographic hash of the labels of its child nodes.

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.

proposals

A message that is voted on which suggests a change in the merkle roots or system. Proposals can be unsigned and unsigned. Below are all the proposal types in the system.

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.

signature bridge

The SignatureBridge 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.

UTXO

The unspent transaction output (UTXO) model for ledger-keeping, which is most notably used by the Bitcoin blockchain, is logically more similar to a cash-based system than Ethereum's account model. In a cash-based system, a finite set of discrete units (cash) represents value. In a UTXO  system, entities may only spend the discrete units of value of which they have ownership. This means that each transaction consists of some set of "inputs" (the collection of cash that is used to pay for the transaction) and some set of "outputs" (the change that is leftover).