Merkle Bridge
A simple protocol for inter-chain asset transfers.
The goal of the Merkle bridge is to be a simple and light protocol for transferring assets between blockchains while providing decentralized custody and censorship resistance. The first application will be to transfer Aergo ERC20 tokens to Aergo Mainnet native tokens. Once the bridge is deployed, any Ethereum or Aergo asset will be directly transferrable between those networks. In this article, we will present some technical details of the protocol.
Context
We can describe a 2 way pegged (2WP) asset transfers as follows : a token first exists on blockchain A; to transfer it to blockchain B it must be locked and a copy is minted on blockchain B with a 1:1 ratio, finally the locked token on blockchain A can only be unlocked if it’s copy has been burnt on blockchain B.
The simple way of maintaining a peg is to lock assets in a single key or in a multisig contract (how most exchanges store fund). The first case (single key) is insecure as the key can be stolen or lost. The second case (multisig) is more secure but transfer fees are expensive as they require 2/3 signature verification on chain for each transfer. Letting a multisig process each transfer also means that it is easy to censor individual user transfers. Other more secure and trust-less methods exist like the ETH-ETC peace bridge but require capital lockup for staking and slashing.
Our goal is to achieve decentralized funds locking/unlocking allowing 20+ validators, but at the same time keeping bridge transfer costs low by designing a simple protocol that doesn’t require the bridge operators to process individual transfers.
Merkle bridge design
The Aergo Merkle bridge enables decentralized custody and efficient minting of assets.
Proof of authority sidechains often use anchoring of their state root on a public chain to provide a verifiable source of truth. The Merkle bridge uses these anchored state roots to allow users to submit proofs of a sidechain’s state.
Fund custody
The security of this design relies on the validity of anchored roots. The pegged blockchain state root contains the information of locked and burnt balances, so any invalid state root can be used to steal locked user funds.
To ensure validity of state roots, the anchoring uses a simple form of DAO (Decentralized Autonomous Organization) similar to a multisig oracle. The members of this DAO are called Validators.
Validators have several responsibilities:
- agree on the roots that will be anchored (so they must be known entities with a reputation to ensure valid anchors).
- agree on validator set update proposals (validators are added or removed with signatures of 2/3 current validators).
- agree on the bridge settings update proposals (also requires approval from 2/3 validators).
Operation
At regular intervals, a Proposer (anybody willing to pay the anchoring fee) publishes the state root of the bridge contract on the bridged chain. The state root is recorded only if it has been signed by 2/3 of validators.
User wallets can then independently mint assets on the destination bridge contract by verifying a Merkle proof of their locked assets with the anchored state root.
The lock keeps track of an account’s total deposited token balance. A Merkle proof of inclusion of this balance is created and that balance can be minted on the other side of the bridge. The mint keeps track of the total minted balance so that an account can never mint more than was deposited. The same process is used for burnt and unlocked balances.
This design makes the memory management and operation of the contract simple as it doesn’t need to record transfer nonces or return values. A limitation is that as the number of users and pegged tokens grows, the size of Merkle proofs increases (contract state tree becomes deeper), making transfers a little more expensive.
Benefits include the following :
- Validators are simple to implement as they only need to sign finalized state roots they believe are valid (by running full nodes on both sides of the bridge). Validators don’t need to watch and validate user transfers.
- User wallets directly make their transfers with the bridge contracts which doesn’t require Validators approval.
- The anchoring period is flexible and state roots can be signed by many Validators (20+).
- Token transfers cannot be arbitrarily censored without 2/3 validators colluding and broadcasting an invalid side-chain state root.
- Micro transfers can be made and the total deposited balance can be minted/unlocked and any time.
- On-chain Merkle proof verification is cheaper than signature verification
- Any new asset can be transferred through the bridge without needing approval from Validators (the first transfer will be more expensive as a new pegged contract will be deployed when minting).
- Multiple transfers to the same account on another chain can be finalized with a single transaction withdrawing the total locked balance send to that account.
Limitations:
- Once initiated, a transfer should be finalized on the other side of the bridge (with no timeout constraint), but it means a transfer cannot be canceled.
- The bridge pauses indefinitely (new withdrawals not possible) if more than 1/3 validators stops cooperating.
Implementation
The POC implementation of the Merkle bridge between 2 Aergo blockchains can be found in this repository :
Documentation: https://merkle-bridge.readthedocs.io
The POC implementation of the Merkle bridge between Ethereum and Aergo blockchains can be found in this repository :
Documentation: https://eth-merkle-bridge.readthedocs.io
The Javascript SDK for transferring assets between Ethereum and Aergo can be found in this repository :
Bridge operators:
They run a full node for each blockchain they are bridging. At regular intervals (every 10 min ?), they will get the latest finalized state root and register it on the opposite blockchain in the Root and Height state variables of the bridge contract.
There are 2 types of bridge operators: the Proposer which broadcasts the set_root() transaction and the Validators which sign the two bridged chains state roots requested by the Proposer. Anybody can be a proposer: the bridge contract will only allow a state root update that happens after the anchoring period and that has valid signatures. The number of validators can vary depending on the multisig security required, they sign a requested state root if it is valid.
Updating the set of bridge validators:
A new set of validators can be defined if 2/3 of the current validators agree on the new set.
Version 0.2.0
In version 0.2.0 of the Merkle bridge, the signature verification is refactored in a separate oracle contract which will have full control on the bridge contract. This enables upgrading the consensus mechanism of the oracle contract and keeping the same bridge contract for user transfers. Security properties of the bridge remain the same.
Version 0.3.0
This version is an upgrade to the oracle contract, validators, and proposers. Now, the validators sign the general state root of the blockchain (previously the bridge contract storage root) which is recorded in the oracle contract for other applications to use. Proposers relay the bridge storage root by verifying a Merkle proof of the bridge account storage root included in the general state root.
User asset transfers :
To transfer tokens, a user will lock them in the bridge contract and wait for the next anchor on the destination blockchain.
The user’s wallet will read the new anchored state root (Root, Height) on the destination blockchain and request a Merkle proof of inclusion of his locked balance for that state root to a full node. A user’s locked balance is recorded in the Locks state mapping where keys are the account reference for a token. The account reference is the concatenation of the user address and the token address. A mint transaction can then be made on the destination blockchain with a Merkle proof of locked tokens. The user cannot mint more than the total amount deposited and recorded by the contract.
If the bridge operators anchor a new state root before the user mints his balance, the user’s wallet can simply create a new Merkle proof for the newly anchored state root.
The user’s wallet repeats a similar process for burning tokens before unlocking them on the origin blockchain.
For details about the Merkle proof verification in the Merkle bridge contract see:
Related works
The approach taken by Merkle bridge is to use the simplest and most robust design possible so that validators don’t need to come to consensus about user transfers, but instead, focus all resources on the validity of the blockchain state roots they are anchoring. Also, users don’t have any time constraint for finalizing transfers, and multiple transfers to the same account can be finalized with a single transaction. This is a key difference with the following protocols:
Other projects like Cosmos IBC take a different approach where all individual cross-chain asset transfers are abstracted into data packets (which can also support contract calls) and where peg zone validators come to consensus on those packets. This is a very interesting approach to trust-less cross-chain asset transfers but raises questions when the value of locked funds by peg validators exceeds the value of atoms at stake and the design also ends up relying on the reputation of validators.
It is important to note that relaying deposit events to transfer tokens is necessary for connecting blockchains like Bitcoin and EOS which do not merkelize state.
Plasma
The Merkle bridge design was inspired by researching Plasma and solving the issue of running contracts on Plasma. The Merkle bridge is not Plasma because it doesn’t have the same security properties: there is no exit cue to challenge exits from the sidechain, and withdrawing has to be initiated on the sidechain. The security of the Merkle bridge relies on the decentralization of the anchoring validators. Since an unlimited number of transfers can be made for a single state root, the required number of signatures of that state root can be high. Users don’t need to watch a blockchain for invalid withdrawals and mass exit situations but should instead trust the decentralized Validators. Also in the context of POA enterprise sidechains, we generally assume consensus safety so initializing withdrawals on the sidechain is acceptable and sidechain operators don’t need to watch the parent pegged chain for exits.
Conclusion
The Merkle bridge is composed of a simple DAO (multisig oracle) to validate anchors, update the validator set and bridge settings. Users wallets can independently create Merkle proofs of their locked/burnt balances to make cross-chain transfers without Validators needing to watch transfer events.
The EthAergo bridge will be used to send AergoERC20 and any other tokens between Aergo and Ethereum mainnets.
The Aergo — Aergo bridge will be used by users of enterprise sidechains to transfer their assets to and from Aergo mainnet in a cost-efficient and secure way.
This enables exciting applications like MakerDAO’s DAI stable coin and any other ERC20 to be available for Aergo mainnet users and secured by the Merkle bridge peg.
I hope you found this useful, feedback and contributions are welcome.
