The Namada Ethereum Bridge

The Namada blockchain aims to provide a unified shielded set for as many assets as possible, since data protection is additive. As such, interoperability is an essential component for Namada. In addition to implementing the IBC protocol, Namada will have an integrated bridge to Ethereum.

In this blog post, we will discuss the design and features of this bridge. We will break the design down into three sections. In the first section we will explain why we decided to build a dedicated bridge and how the basic bridge design works. In the second section, we give the details for relaying transfers of assets from Ethereum to Namada and back from Namada to Ethereum. In the third section, we will discuss the smart contract architecture.

For any feedback, questions or discussions on this article, please go to this topic on the Namada forum.

Direct integration into Namada

The Ethereum bridge is directly integrated into Namada instead of being a standalone protocol. Namada validators run the bridge as part of the core Namada protocol. For transferring assets to Namada, validators also act as relayers; no other actors are necessary. However, for transferring assets to Ethereum, third party actors (relayers) will be involved, but they are not responsible for any validation or securing of the bridge.

This means that the liveness and the security of the Ethereum bridge is directly tied to the liveness and security of Namada as a whole. In general, when transferring assets across bridges to other chains, users must trust both the validators of the bridge as well as the validators of the destination chain. The security of their assets is only as good as the weakest link. Since users must trust Namada validators in order to use Namada anyways, integrating the bridge in this way does not add any extra security assumptions. There are other solid IBC-compatible bridge designs such as those of Gravity and Axelar, and Namada can also connect to and support those bridges, but they do require users to accept additional security assumptions (and some latency).

Namada validators will run Ethereum full nodes and monitor events emitted by the bridge smart contracts deployed on Ethereum. The events from the smart contracts are triggered by various transactions such as moving tokens back and forth across the bridge, as well as some administrative purposes. Namada validators wait until the triggering transaction is finalized, and then share with other validators that they have seen a certain event emitted from Ethereum.

When voting on a new Namada block, validators must include a signed list of new events that they have seen as part of their vote. When a 2/3 staking majority of validators have voted on a particular event, it is considered as truth and the Namada chain may act upon it. A validator should only vote on events that are unlikely to be reverted (in the sense of Ethereum 1 PoW) or are finalized (in the sense of Ethereum 2 PoS).

For context, in Ethereum 2 (at the moment), finality is determined when 2/3 of staking power has voted on an event "twice", and in separate epochs. More specifically, the first block in each epoch can be finalized when it has been voted on in two separate (but joint) pairs. The first pair allows the block to be "justified", and the second pair allows it to be finalized. Hence, finality occurs later than it would in Namada.

Events are unlikely to be reverted if the containing block has sufficiently many descendants, called "confirmations". The number of confirmations necessary to consider an event "final" is set at genesis in Namada, but can be changed via governance. In Ethereum 2, once a block reaches 64 confirmations, it either belongs to or is the ancestor of a finalized checkpoint block. This means that in order for another block at the same height to be attested to an Ethereum validator quorum, at least one-third of the total stake by validators is at risk of loss. As such, the 64 confirmations should be considered sufficient in Ethereum 2.

It is worth noting that any validator may submit a fake event, but it will not accumulate enough backing votes to be acted upon unless the whole security of Namada has been compromised. If Namada validators wished to verify that events were authentic, this would require providing light client proofs attesting to the inclusion of a transaction into Ethereum that spawned a given event. This in turn would require Namada validators to run Ethereum light clients to verify such proofs. Allowing fake events means that Namada validators don't need to run Ethereum light clients to verify that events are real. This greatly simplifies the bridge and does not substantially affect our security assumptions (because 2/3 of voting power could sign arbitrary blocks anyways).

Transferring assets to Namada

Because the Namada chain acts as an oracle for the relevant Ethereum contracts, it is a very seamless process for users to transfer assets from Ethereum to Namada. Simply submitting the relevant transaction to the bridge contracts will cause an event to emitted. This will be seen and voted on by Namada validators. Once it has a backing quorum, the issuing of assets to a Namada address will occur automatically and free of charge. The payment of gas on Ethereum is enough to prevent any denial of service attack vectors.

Transferring assets back to Ethereum

Transferring assets back to Ethereum is obviously not as simple as its reverse counterpart, since Ethereum does not run Namada full nodes. This means that transactions on Namada that initiate a transfer to Ethereum need to be relayed to the relevant smart contract.

This presents numerous challenges:

• An Ethereum transaction must be crafted
• Someone must submit this transaction
• Someone must pay the gas fees
• It isn't cost efficient to submit transactions individually, batching is needed

To solve these issues, Namada will keep an Ethereum bridge pool consisting of requests to transfer assets to Ethereum. This pool should be thought of as a mempool. When a Namada user adds a transfer request to the pool, they can choose to pay a certain amount of NAM (or another whitelisted asset) as a fee. This fee is escrowed by Namada.

Anyone may choose to relay a subset of transfer requests in the pool at any time. The Ethereum bridge pool is organized as a Merkle tree and the latest root is signed by the validators. Relaying transfer requests entails submitting the transfers to the relevant Ethereum smart contract along with a Merkle proof of the transfers and a Merkle tree root signed by a quorum of Namada validators.

Such a transaction will emit an event that will be seen by Namada validators. Once it has been confirmed on chain, the escrowed fees for the transfers will be issued to the person who relayed them.

Note that by using Merkle trees, any subset of the bridge pool may be relayed in any order. This prevents attacks whereby large quantities of small transactions are sent over the bridge in order to slow it down. However, each batch of transfers will be given a nonce to prevent replaying transfers.

This design avoids the need for Ethereum gas oracles as market incentives will compel users to determine appropriate fees and which transfer request are most economical to relay. If a fee for a transfer request is too low, eventually the request will "time out" and be removed from the pool and all escrowed assets returned. This time out period is a protocol parameter set at genesis that can be changed via Namada governance.

Proofs on Ethereum

We mentioned above that we must submit a signed Merkle root to the relevant Ethereum contracts to relay transfer requests. In fact, any transaction signed by a quorum of validators should be accepted by the Ethereum smart contracts, as they are essentially Namada lightclient proofs.

To make such proofs gas efficient, proofs must use Keccak hashing and Ethereum's ABI serialization format. Namada validators must also have accounts on Ethereum that allows them to sign proofs with secp256k1 keys.

Since validator sets on Namada may change every epoch, the Ethereum smart contracts need a way to know which signatures to check when verifying a proof. This requires sending a validator set update to Ethereum every epoch with the new validator addresses, public keys, and voting power.

This validator set update must be signed by at least 2/3 of validators by stake of the previous epoch authorizing this update using their Ethereum keys. When a new epoch starts, the new validator set must sign off on the next epoch's validator set as part of their vote for a block.

Their vote will be signed by their Namada key and will contain the new validator set signed with their Ethereum key. Validator sets are pipelined, so they are known two epochs in advance. This way, the "transfer of power" is tied to consensus and available at the end of an epoch.

When a new epoch begins, the leader chosen for the first block in this epoch must send the validator set update as a transaction to Ethereum, which will emit an event. Once this event is confirmed on Namada, this validator is payed inflationary rewards to compensate them.

There is no mechanism to punish the leader if they fail to successfully submit the validator set update. Since the signed update is publicly available on chain, anyone can send the update to the Ethereum contract if necessary. Thus this design does not expose an attack vector and the financial reward should sufficiently incentivize the chosen leader to relay the validator set updates.

The smart contracts

Architecture

Several smart contracts will be deployed on Ethereum mainnet as part of the bridge. The main contracts that users will interact with are the Bridge Contract and the wNAM contract. The Bridge Contract is used for sending or receiving assets from Namada. The wNAM contract is an ERC20 token for allowed wrapped NAM on Ethereum. It should be noted that only ERC20 tokens may be transferred between Namada and Ethereum. This means that Ether cannot be transferred, but wrapped Ether can (the wrapping can be automated by the interface).

In addition, there are three other contracts: The Proxy, Governance, and Vault contracts. The Proxy contract is a fixed contract that maintains the address of all the latest contracts. This is so that if a contract is updated, there is a single contract to look to find the address where that contract is deployed.

The Governance contract maintains the validator sets needed for verifying proofs. It also is used when replacing contracts, halting the bridge, or accessing the funds locked in the bridge if necessary.

The Vault contract is an escrow and ledger of all the token balances of assets on the bridge. Keeping this as separate contract minimizes the amount of storage that needs to be migrated if the Bridge contract is updated.

Defense in depth

As we mentioned earlier, Namada validators must have Ethereum accounts with public keys that are known to the bridge. In fact, validators must have both hot and cold keys. Hot keys are those that are used regularly, while cold keys should be used infrequently as they are for sensitive operations. Up until this point, by "Ethereum key", we have been referring to the hot keys.

Validators may use their cold keys to recover the bridge in extreme cases, e.g. liveness failure. A quorum of Namada validators can use their cold keys to extract the funds escrowed in the Vault to any Ethereum address.

These keys are also used for the administration of the bridge, including upgrading to new contracts as well as important security aspects such as token whitelists, escrow caps, and withdrawal limits.

A whitelist of allowed ERC20 tokens will be maintained by the bridge. Furthermore, a cap of the total amount of each token that the bridge may keep in escrow will be enforced. This limits the potential losses from the bridge as well as reduces the value of attacking it. An especially important point is that over-collateralizing the bridge can invalidate Namada security assumptions. This happens if the amount of value on the bridge sufficiently exceeds the value staked by any quorum of Namada validators.

Token caps help ensure that staking validators aren't securing vastly more value than they have staked. A further mitigation is rate limiting, meaning that a maximum amount of a given token may be be removed from the bridge per epoch. This slows down attempts to quickly move value off of the bridge in the case of a safety failure.