Gear Bridge is an implementation of a trustless ZK-based cross-chain bridge facilitating the transfer of assets between Ethereum and Gear-based blockchains, such as the Vara network.
The Gear -> Eth transfer protocol allows relaying messages from Gear-based blockchains to Ethereum. These messages consist of generic data defined by protocols built on top of the bridge. The protocol doesn't guarantee the order in which messages are relayed.
This repository contains the implementation of a token bridging protocol built on top of a more generic messaging protocol.
- GRC-20: A program capable of transferring, burning, and minting
GRC-20
tokens. It repeats the implementation of theERC20
standard on the Gear network, the standard implementationGRC-20
can be found here. - GRC-20 Gateway: Receives
GRC-20
tokens from users, burns them, and emits a message to thepallet-gear-bridge
built-in actor. This message contains information about which token is being bridged, how much of it, and the recipient of funds on the Ethereum network. - Pallet-Gear-Bridges: a Built-in Actor - the entry point into the generic bridging protocol. Receives messages from any actor on the Gear network and relays them to
pallet-gear-bridge
. - Pallet-Gear-Bridge: Receives messages from the
pallet-gear-bridges
built-in actor and stores them in the binary Merkle trie. This Merkle trie gets slashed at the end of eachERA
. - Backend: Reads Gear state, queues ZK-proof generation, and submits ZK-proofs to Ethereum.
- Prover: Capable of creating two types of ZK-proofs: proof of authority set changes and proof of inclusion of Merkle trie root into the storage of
pallet-gear-bridge
. The combination of these proofs allows for trustless relaying of Merkle trie roots frompallet-gear-bridge
storage to Ethereum. - Relayer Contract: Accepts proofs of Merkle trie root inclusion and, if they're valid, stores Merkle trie roots in memory.
- Gnark-Verifier: A contract capable of verifying
plonk
proofs created by gnark. The submitted proofs are plonky2 proofs wrapped bygnark
. - Message Queue Contract: Used to recover messages from Merkle tries. A user can request a message to be relayed further onto Ethereum by providing proof of inclusion of a message actually included in the Merkle trie, given that this Merkle root was already relayed by
backend
(or another party). This is also the exit point of the generic Gear -> Eth bridging protocol. - ERC20 Treasury: A treasury that accepts user funds and releases them. Release can only be triggered by a message relayed over the bridge from the
GRC-20 gateway
.
Note
*Gear itself is not a blockchain network and has no native token. This refers to the token of any network built on Gear technology, such as Vara.
- The user submits a message to the
GRC-20 gateway
to initiate bridging. - The
GRC-20 gateway
burnsGRC-20
tokens and emits a message to thepallet-gear-bridge
built-in actor. - The
pallet-gear-bridge
built-in actor relays the message topallet-gear-bridge
. - The
pallet-gear-bridge
stores the message in a Merkle trie. - Eventually, the
backend
(or another party) relays the message to therelayer contract
, and it gets stored there. - The user sees that their message was relayed and submits a Merkle proof of inclusion to the
message queue contract
. - The
message queue contract
reads the Merkle root from therelayer contract
, checks the Merkle proof, and relays the message to theERC20 treasury
. - The
ERC20 treasury
releases funds to the user's account on Ethereum.
The Block Finality circuit proves that a specific block was finalized by an authority set on the Gear chain. This involves verifying that a majority (>2/3) of validators have signed the GRANDPA vote for the block.
The Validator Set Change circuit proves that the validator set has changed. This change means that the current validator set finalized a block containing the next validator set in its storage. The circuit verifies that a majority of validators from the current set have set hash inclusion into the storage of pallet-gear-bridge
and signed the vote for the change.
Substrate storage trie circuits are used to prove the inclusion of data into the Substrate storage trie. Currently, there are two types of nodes supported:
This circuit parses branch nodes in the trie, which do not contain a value but help navigate the structure.
This circuit parses leaf nodes in the trie, which contain the hashed values of the stored data.
These individual proofs are composed into a storage proof, which proves that specific data exists at a particular address within a block's storage.
The Recent Validator Set circuit is used to prove a chain of validator set changes, demonstrating the transition from the genesis validator set to the most recent validator set. The genesis validator set is encoded as a constant within the circuit.
The Message Inclusion circuit is used to prove that a specific message Merkle root was submitted on the Gear chain for bridging, indicating its inclusion in the pallet-gear-bridge
storage.
The Final Proof circuit is the proof submitted to Ethereum. It proves that a message Merkle root was present in the storage of pallet-gear-bridge
at a specific finalized block. This final proof ensures the validity of the cross-chain message.