Glossary

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

accepted proposal

A proposal in which voting has concluded affirmatively, but the signature remains pending.

acknowledge proposal

A proposal that has been voted for in favour.

active DKG public key

The public key of the DKG protocol that is currently active.

active nomination

A validator (or validators) that a nominator has selected to nominate and is actively validating this era. The nominator is placing their stake behind this validator for this era and will potentially receive staking rewards in return for doing so.

active proposal

A proposal in which voting is ongoing.

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.

block

A collection of data, such as transactions, that together indicate a state transition of the blockchain.

block explorer

An application that allows a user to explore the different blocks on a blockchain.

bounty

A mechanism which works in some sense as the reverse of a Treasury Proposal, allowing the Polkadot Council to indicate that there is a need to do some task for the Polkadot network and allowing users to receive DOT in return for working on that task.

bridge

A parachain that acts as an intermediary between the Polkadot Relay Chain and an external chain, in such a way that it appears to the Relay Chain that the external chain is a parachain (i.e., meets the Polkadot Host's requirements of parachains). Bridges allow for interaction between other blockchains, such as Ethereum and Bitcoin, that are not natively compatible with Polkadot.

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.

crowdloan

A mechanism for potential parachains to temporarily source tokens to win an auction for a parachain slot. Tokens gathered in this way are programmatically returned to the lender after the lease period is over or the crowdloan period ends.

distributed key generation

A cryptographic process in which multiple parties contribute to the calculation of a shared public and private key set. Unlike most public key encryption  models, distributed key generation does not rely on Trusted Third Parties. Instead, the participation of a threshold of honest parties determines whether a key pair can be computed successfully.  Distributed key generation prevents single parties from having access to a private key. The involvement of many parties requires Distributed key generation to ensure secrecy in the presence of malicious contributions to the key calculation.

epoch

An epoch is a time duration in the BABE protocol that is broken into smaller time slots. Each slot has at least one slot leader who has the right to propose a block. In Kusama, it is the same duration as a session.

era

A (whole) number of sessions, which is the period that the validator set (and each validator's active nominator set) is recalculated and where rewards are paid out.

extrinisic

State changes that come from the outside world, i.e. they are not part of the system itself. Extrinsics can take two forms, "inherents" and "transactions".

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.

next DKG public key

The public key of the DKG protocol that will be active after the next authority set change.

next session

This indicates that the validator will be a member of the active set in the next session.

proposal header

The proposal header is the first 40 bytes of the proposal. It contains the following: • The ResourceId which is a 32 byte value that uniquely identifies the target system. • The FunctionSignature which is a 4 byte value that uniquely identifies the function to be executed on the target system. • The Nonce which is a 4 byte value that is used to prevent replay attacks.

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.

refresh delay

The length of time within a session that a key refresh protocol will be initiated.

rejected proposal

A proposal in which voting has resulted in a non-passage.

relayer

Relayers are oracle systems that listens to external Events, and posts this data back on chain. In Webb Protocol relayer watches for the state of anchors on bridge. This information is then used to update the anchors, acting as proposer of proposals.

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.

root origin

A system-level origin in Substrate. This is the highest privilege level and can be thought of as the superuser of the runtime origin. To learn about more raw origins in Substrate, visit Substrate Docs

runtime

The state transition function of a blockchain. It defines a valid algorithm for determining the state of the next block given the previous state.

session

A session is a Substrate implementation term for a period that has a constant set of validators. Validators can only join or exit the validator set at a session change.

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.

signature threshold

The ‘t’ in (t-out-of-n) threshold signatures used in the DKG signing system. Required of DKG authorities to generate signatures.

signed proposal

A proposal in which voting has concluded affirmatively, and a signature has been made.

threshold cryptosystem

A cryptosystem that protects information by encrypting it and distributing it among a cluster of fault-tolerant computers. The message is encrypted using a public key, and the corresponding private key is shared among the participating parties. With a threshold cryptosystem, in order to decrypt an encrypted message or to sign a message, several parties (more than some threshold number) must cooperate in the decryption or signature protocol.

transaction

An extrinsic that is signed. Transactions are gossiped on the network and incur a transaction fee. Transactions are "provably true", unlike inherents. For example, one can prove that Alice wants to send funds to Bob by the fact that she signed a transfer-funds message with her private key.

unsigned proposal

A Proposal that is unsigned and is ready to be signed by the DKG authorities

unsigned queue proposal

A queue of unsigned proposals that are ready for signing.

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

validator

A node that secures the Relay Chain by staking, validating proofs from collators on parachains and voting on consensus along with other validators.

voting

The process of stakeholders determining whether or not a referendum should pass. Votes are weighted both by the number of tokens that the stakeholder account controls and the amount of time they are willing to lock their tokens.

webassembly

An instruction format for a virtual, stack-based machine. Polkadot Runtime Modules are compiled to WebAssembly. Also known as Wasm.

witness

Cryptographic proof statements of data validity.