Overview

The Anchor System is a bridged system between a set of identical smart contract protocols.

The smart contract protocol (or pallet protocol) defines a system for connecting merkle trees on different blockchains in a graph-like framework so that anchors maintain the latest state of their neighboring anchors. This state is utilized to prove the existence of data in any anchor from any anchor. The primary goal of the Anchor System is to satisfy 2 properties:

• Liveness - all anchors can continue to be updated in a partially-synchronous environment
• Safety - all anchor updates are guaranteed to be valid

Data Structures

Each anchor maintains an on-chain merkle tree and an edge list to the latest valid neighboring anchors’ merkle tree roots. Each anchor updates its edges of its neighbors using an external governance system, such as a single-signer, multi-signature, threshold-signature, or alternative voting / messaging protocol.

An edge is a directed connection between 2 anchors. In the language of graphs. A bridge is a graph G=(A, E) where A is the set of anchor nodes and E is the set of directed edges between them. We represent this data structure using an Edge or EdgeMetadata that looks like:

// An edge for a specific chain
pub struct EdgeMetadata<ChainID, Element, LastLeafIndex> {
	/// chain id of the connected merkle tree
	pub src_chain_id: ChainID,
	/// root of source chain anchor's native merkle tree
	pub root: Element,
	/// height of source chain anchor's native merkle tree
	pub latest_leaf_index: LastLeafIndex,
	/// target system of the anchor (contract address or tree id)
	pub target: Element,
}

Anchor State

Each anchor maintains an edge list containing EdgeMetadata objects and a history of the merkle root updates up to some bounded limit.

/// An example of an edge list data structure
struct EdgeList<ChainID, Element, LastLeafIndex> {
	/// Map of edges (
	pub edges: HashMap<ChainID, EdgeMetadata<ChainID, Element, LastLeafIndex>
	/// Map of historical roots (chain -> index -> merkle root)
	pub history: HashMap<ChainId, HashMap<u8, Element>>
}

Elements of an Anchor

The elements of an anchor are intended to be 32-byte hashes of arbitrary data. The preimage to these hashes represent the underlying application for a connected bridge of anchors. For each unique element being inserted into an anchor, we assume the existence of a zero-knowledge program that verifies knowledge of the preimage of the element.

Oftentimes these hashes are hashes of structured data that are relevant for an end-user application. For example, it might be the hash of a unspent transaction output (UTXO) (opens in a new tab) in the tree that allows someone to prove knowledge of a UTXO in one anchor from a different anchor directly.

Zero-knowledge Membership

The main utility of the Anchor System is the ability to prove membership of elements in any anchor on a bridge in zero-knowledge. These proofs of membership disclose no more data than is necessary to prove that there exists an element with some defined preimage structure in one-of-many of the anchors.

The primary sketch for a zero-knowledge membership program and proof in the Anchor System is:

1. A proof of knowledge of preimage of an element in the anchor.
2. A proof of knowledge of membership of an element in a merkle tree.
3. A proof of knowledge of membership of a merkle root in a set of merkle roots.

The membership proof here is unique for a given element but need not be in practice. That is, we could envision an Anchor System where multiple element types are supported and multiple zero-knowledge programs are provided for verification of membership proofs. For example, we may consider an Anchor System over a UTXO a decentralized identity (DID (opens in a new tab)) elements together.

Oracle Network

The Anchor System encompasses a system with a variety of agents and requires some of these agents to play the role of witnessing and relaying changes across all anchors to each other and to the external governance system. We call these agents oracles and define their roles as:

• Listening for new insertions into anchors’ merkle trees.
• Composing the EdgeMetadata objects from these observations.
• Relaying these EdgeMetadata objects to the governing system of the Anchor System instance.
• Relaying the output of the governing system back to the respective anchors.

The oracles of the Anchor System instance are tightly coupled with the external governance system being used. For more information on how these oracles are used in practice can be found here (opens in a new tab).

Relayer Network

Other agents in the Anchor System are responsible with preserving privacy for users interacting with the anchor instances. While we use the term relaying/relayer interchangeably, we remark here on a specific relaying role that involves the relaying of zero-knowledge proof data to their target system for users.

In any blockchain context, users are required to possess funds in order to interact and transact with smart contracts. Therefore, if a privacy-interested user intends to prove membership of some element’s preimage in one of the anchors’ merkle trees, they must be able to do so without compromising their privacy by requiring them to submit these proofs themselves. They must be able to delegate the submission of their proof through some overlay network.

The relayer network provides this delegation service. Anyone can run a relayer and provide this service. We consider an agent a relayer if they expose an API that enables the submission of zero-knowledge proofs of membership for specific anchor instances and if this agent submits the relevant transaction on-chain on behalf of the user delegating their proof through this API.

Relayer incentives are key component of ensuring privacy for end users utilizing the applications built over the Anchor System instance. Incentives are highly coupled to the applications implemented. For example, for a private bridge application, users can pay a fee to relayers by committing to a specified fee at proof generation which is extracted and transferred out of the users transfer to the relayer’s account.

Oracle & Relayer Similarities

In practice, the oracle and relayers roles are synergistic and often taken out by the same participant in the protocol. While we remark about these roles separately, we often consider them as being undertaken by the same party. We use the terms interchangeably to represent the network that provides both relaying and oracle services in the Anchor System.

Further reading

• Merkle Tree (opens in a new tab)
• Unspent Transaction Output (opens in a new tab)