Snowfork - Nervos-Ethereum Bridge

Team and background

Our team at Snowfork has worked together for several years, successfully implementing various blockchain protocols and supplementary tools. Relevant past experience includes the design and implementation of Peggy, a two-way bridge between Cosmos and Ethereum, and a security audit of pTokens, a one-way bridge between Bitcoin and Ethereum. We have a passion to dive deep into different decentralized ecosystems and allow them to communicate with each other.

Please find some of our key team member’s experience outlined below:

  • Aidan Musnitzky (https://www.linkedin.com/in/aidanmusnitzky/, https://github.com/musnit/): Aidan is a technologist with many years of experience across multiple industries and roles. He has worked as a developer, architect and a product manager on projects ranging from distributed systems to user-facing consumer products. He has experience working on distributed systems at Amazon Web Services on the EC2 compute service. Specifically in Blockchain, he is a researcher for the token fund 1kx Capital, a director for consulting and development firm Swish Labs, leading their blockchain development initiatives. Most relevant to this project, he recently developed the de facto token bridge between Cosmos and Ethereum for the Interchain Foundation (https://github.com/cosmos/peggy).
  • Philip Stanislaus (https://www.linkedin.com/in/philipstanislaus/, https://github.com/philipstanislaus): Philip has 13+ years of experience as a full-stack engineer. He delivered hundreds of projects and worked with some of the most renowned development ecosystems (Gigster Inc. and Swish Labs). Most recently, Philip worked on the technical specification and implemented parts of Flow, the recently announced general purpose blockchain of Dapper Labs. Philip has extensive experience with the Polkadot ecosystem, architecting and building the Substrate-based Centrifuge Chain, a domain specific blockchain allowing tokenization of real world assets to use them as collateral for loans from MakerDAO, Compound and others. Philip was also heavily involved in the architecture of a bridge between Substrate and Ethereum, which received a grant from Web3 Foundation. Besides his engineering work, Philip’s relevant experience includes the security audit of pTokens, a one-way bridge between Bitcoin and Ethereum. In 2018, Philip was the lead architect and engineer on THORChain, a decentralized exchange protocol built on top of the Cosmos SDK. He wrote most of the open sourced protocol (https://github.com/thorchain/THORChain) as well as the block explorer (https://github.com/thorchain/THORChain.info) and the decentralized exchange (https://github.com/thorchain/ASGARDEX).
  • Jazear Brooks (https://www.linkedin.com/in/jazearbrooks/): Jazear is a computer scientist (BS Computer Science and Economics from Yale) with a decade of leadership and engineering experience working within the technology and financial services industry. Before moving into blockchain, Jazear held positions at Microsoft, Glassboard, Pixorial, and Madrone (a hedge fund analytics company). Blockchain became Jazear’s paradise when he was able to combine his skill set in engineering and economics. Whilst exploring blockchain investments and technology, he took on the roles of Director of Engineering at Swish and lead Product Manager at THORChain. Jazear also develops proprietary quant trading algorithms and trades crypto frequently. Most recently, he also served as a technical product manager for the peggy token bridge between Cosmos and Ethereum.
  • Vincent Geddes (https://www.linkedin.com/in/vgeddes/, https://github.com/vgeddes): Vincent has 12+ years experience as a software engineer, mainly focused on systems and backend engineering. For the past 5 years, Vincent was the lead senior engineer for the virtualization layer at Oracle Cloud Infrastructure/Classic. Before that, he helped build EC2 at AWS. Among other projects, he played a critical role in the development of the pioneering t1.micro instance type, which was key to enabling the AWS Free Tier as well as Elastic Beanstalk. Vincent also has a keen interest in programming language development and language runtimes. In his spare time, he has developed a performance-focused compiler and virtual machine for the Smalltalk language.

Project and justification

Nervos has expressed interest in an RFC for bridging Nervos to Ethereum. The Nervos-Ethereum bridge would allow the creation of eCKB, a token on Ethereum that represents one CKB, and nETH, a token on Nervos that represents one ETH. These tokens (commonly called pegged tokens) would allow cryptocurrency holders to transact in a blockchain ecosystem and participate in its services while maintaining price parity of value with a native token to another blockchain ecosystem.

High level technical specification and implementation

There are various potential bridge designs with different security models implying varying levels of trust and complexity for the transfer of assets between blockchains. Designs range from systems based on highly trusted validators, miners, and relayers, to systems with staked validators and economic security, to systems that rely purely on cryptographic proofs and guarantees.

In the simplest bridge design, a set of trusted actors will be used to lock (unlock) and mint (burn) tokens. Trust can be reduced by requiring votes of these actors to surpass a threshold before the message will be accepted. Further trustlessness can be achieved by introducing economic incentives for intended behavior, by requiring the actors to stake funds, which can be slashed in the case of offences. The necessity to trust external actors can be removed through light clients that verify messages from the other chains within the runtime. Finally, cryptographic proofs can be generated that replace the need of light clients.

Through our past experience, we have a deep understanding of those trade offs and technical implications. We have detailed technical specifications for the components needed, but we believe it is the right call to first evaluate at a high level which setup is desired before getting into implementation details. This is especially important since a setup with a light client would fall under two different RFCs, implying a double grant application.

In the following, we explain our framework for thinking about building bridges and convey our understanding of how we plan to build for Nervos. We believe that this architecture simplifies how to develop, analyze and compare bridges and their security levels.

Flow

At a high, generic level, any bridge design has the following basic architecture, described with the example Ethereum<->Nervos flow:

For issuing new backed tokens ETH -> nETH:

  1. Alice locks token into a bank contract on Ethereum in transaction with a target Nervos destination address.
  2. Any user sees this, confirms it was included in the main Ethereum chain with enough confirmations, generates a proof that this happened and sends the proof to Nervos.
  3. Nervos interprets and verifies the proof, ensures it is legal and was included in the main Ethereum chain, mints nETH to the destination address.

For redeeming those tokens nETH -> ETH:

  1. Alice burns nETH with a target Ethereum destination address.
  2. Any user sees this, confirms it was committed on the Nervos blockchain, generates a proof that this happened and sends the proof to Ethereum.
  3. The bank contract interprets and verifies the proof, ensures it is legal and was included in the Nervos chain, unlocks and sends Ethereum to the destination address.

For issuing new backed tokens CKB -> eCKB:

  1. Alice locks CKB into cell on Nervos in a transaction with a target Ethereum destination address.
  2. Any user sees this, confirms it was included in the main Nervos chain in the commitment zone of a block, generates a proof that this happened and sends the proof to Ethereum.
  3. Ethereum interprets and verifies the proof, ensures it is legal and was included in the main Nervos chain, and mints eCKB to the destination address.

For redeeming those tokens, ie, eCKB -> CKB:

  1. Alice burns eCKB with a target Nervos destination address.
  2. Any user sees this, confirms it was committed on the Ethereum blockchain, generates a proof that this happened and sends the proof to Nervos.
  3. Nervos interprets and verifies the proof, ensures it is legal and was included in the Ethereum chain, unlocks and sends CKB to the destination address.

Core Components

There are a few generic components to any system with this architecture that may have different implementations depending on the security model of the design:

  1. The bank that is holding the locked up tokens from steps 1 and 7
  2. The Ethereum-transaction-proof that is generated in steps 2 and 11 by some prover
  3. The Ethereum-transaction-verifier, running on Nervos, from steps 3 and 12
  4. The Nervos-transaction-proof that is generated in steps 5 and 8 by some prover
  5. The Nervos-transaction-verifier, running on Ethereum from steps 6 and 9

Any given bridge will implement a component for each piece depending on the trust and security level it is trying to achieve.

Secondary Components

Besides for the core components, there can be additional tangential components that some designs may add to improve the security of their bridge in the event that one of the core components fails. Components that allow for actors to be further incentivized beyond block rewards of their native chains when taking part in the functioning of any of the core components could be added.

Some example secondary components:

Slashable Collateral - In a system where one side of the verifiers may fail due to malicious or other reasons, it can be useful to add a component that collects slashable collateral in a different asset on the other side of the system which remains secure to insure participants against these kinds of attacks.

Oracle - More advanced collateral systems also take into account the exchange rate between collateral assets and locked up token assets to cover fluctuations that may put collateral at risk of losing value. They use an oracle component to provide this exchange rate.
Chainlink is currently considered best in class for oracles in DeFi as trusted by Synthetix and other leading DEXes. They have a strong direct connection to Google. Another solution to consider is subscribing to the price feed of a decentralized liquidity pool trading platform such as Uniswap or THORchain.

Relayer - Some designs expect the user to transmit messages between chains. Others expect staked or incentivized relayers to watch for messages and transmit them between chains on behalf of users.
By allowing users to transmit messages themselves, we enable them to take control over their own security in messaging. However, for users who prefer to offload this responsibility, a staked or incentivized relayer system is preferable.

Signing Group - In cases where users prefer a staked or incentivized relayer system, a signing group is a collection of nodes that custody source assets for users from a source chain to mint a corresponding pegged asset on a destination chain.
These signing groups vote on the correct action to take on a destination chain on behalf of a user who has deposited tokens with them. Depositors pay a service fee to the validators in these signing groups to incentivize their behavior.

Verifier Components

As mentioned, each of the components may be implemented in different ways. The verifiers specifically may fall into different categories with different subcomponents. Verifiers can be stateless or stateful, and may or may not be used with secondary components too.

Some example implementations:

Stateless Signature Verifier - A verifier just confirming that a message has been signed by a trusted bridge validator.

Stateless SPV Verifier - A verifier that receives details about a block, it’s difficulty, and a light client merkle inclusion proof of a transaction. This works for proof of work chains, including Nakamoto Consensus and Common Knowledge Base Consensus, because the validity of a block can be confirmed in a stateless way, purely by checking the amount of work attached to the details.

Stateful Threshold Signature Verifier - A verifier that confirms a message has been signed by a threshold of trusted validators which may change over time. The state of which validators are active and their thresholds change through some secondary process.

Stateful Light Client Verifier - A verifier that keeps up to date with the latest block header of the chain it is verifying. It uses light client merkle inclusion proofs to verify transactions have been included in some block of that chain. The state of the latest block can change through some secondary process - perhaps through a similar threshold signature process to the above, or through a proper trustless, full consensus verification.

Verifier for Secondary Component - With the Slashable Collateral example above, a verifier may also be used to control the collateral in that component in the same way as for the core flow.

Examples

To clarify the above architecture, some example imagined security models and their respective component implementations are described. In these cases, ETH -> nETH is used as the default direction. The tools mentioned would also work on the opposite blockchains to power CKB -> eCKB:

A) Simple Trusted Authority:

A model where a single authority operates the bridge and is fully trusted.

  • Bank contract: Simple smart contract that locks up tokens on deposit
  • Ethereum-transaction-proof: Transaction details signed by authority
  • Ethereum-transaction-verifier: Check signature by authority
  • Nervos-transaction-proof: Transaction details signed by authority
  • Nervos-transaction-verifier: Check signature by authority

B) Proof of Authority Threshold Signature:

A model where a set of validators operate the bridge and transactions are verified once a trusted threshold of them, either based on number or stake signs a message.

  • Bank contract: Multisig smart contract that locks up tokens on deposit
  • Ethereum-transaction-proof: Transaction details signed by enough signatories
  • Ethereum-transaction-verifier: Check signatures of validators above threshold
  • Nervos-transaction-proof: Transaction details signed by enough signatories
  • Nervos-transaction-verifier: Check signatures of validators above threshold

C) Random Validators Threshold Signature:

A model where a set of validators are randomly selected to verify specific transactions. Validators would be randomly chosen either per transaction or per transaction group (ie. user randomly selects from one of many signing groups, where signing group’s participants are consistently together).

  • Bank contract: Multisig smart contract that triggers the selection (and if necessary, the creation) of a signing group from a subset of all validators. Signing group locks up tokens on deposit.
  • Ethereum-transaction-proof: Transaction details signed by enough signatories
  • Ethereum-transaction-verifier: Check signatures of validators above threshold
  • Nervos-transaction-proof: Transaction details signed by enough signatories
  • Nervos-transaction-verifier: Check signatures of validators above threshold

D) Proof of Authority Threshold Signature + Light client:

In this example, light client based verification-logic is requested for the ETH->nETH direction, and threshold signature for the reverse. With a simple modification to the bank contract, the validators can be randomly chosen as described in C, but for simplicity, we describe a proof of authority setup here.

  • Bank contract: Multisig smart contract that locks up tokens on deposit
  • Ethereum-transaction-proof: Transaction details + Merkle proof of inclusion
  • Ethereum-transaction-verifier: Check inclusion proof based on known recent block header
    • Verifier type: Stateful EthereumNervos Light Client with the latest block header state being updated based on the longest chain rule.
  • Nervos-transaction-proof: Transaction details signed by enough signatories
  • Nervos-transaction-verifier: Check signatures of validators above threshold
  • Potential secondary components
    • Pure Service Fee Component: Relayers earn in CKB tokens or ETH as paid as a service fee from depositors
    • Staked Collateral Component: Relayers place stake in CKB tokens or ETH on Nervos in a component that can slash them for inactivity or exchange rate fluctuations. Relayers earn a service fee from depositors
    • Oracle Component: An oracle may be used to adjust the CKB/Ethereum exchange rate

E) Pure Light client:

An example where the verification logic on both sides runs a full light client that can verify the transactions independently of any validators or trusted party needed

  • Bank contract: Simple smart contract that locks up tokens on deposit
  • Ethereum-transaction-proof: Transaction details + Merkle proof of inclusion
  • Ethereum-transaction-verifier: Check inclusion proof based on known recent block header
    • Verifier type: Stateless SPV Verifier
  • Nervos-transaction-proof: Transaction details + Merkle proof of inclusion
  • Nervos-transaction-verifier: Check inclusion proof based on known recent block header

We intend to present these bridge design options and discuss with the Nervos team the best path forward.

Timeline and project duration

The timeline for this project heavily depends on the design choices outlined above. A bridge without on-chain light clients can likely be deployed to production in 3-4 months, while a bridge with on-chain light clients will take rather 3-6 months to production, depending on architectural constraints of Nervos UTXO model. This requires more research that we plan to provide once the initial design decisions are made.

4 Likes

This is all very cool! I had a question about this- CKB would not directly verify the transaction correct? It would be verifying an aggregate signature from a bonded group or something like that?

@mathoticus that depends on the bridge design, mainly the Ethereum-transaction-proof and Ethereum-transaction-verifier components.

For minimizing trust in external parties and their signatures, you would use a light client in the Ethereum-transaction-verifier as in example E) above. There are certain trade-offs though: A light client takes more time (and budget) to develop, and its operation consumes much more resources on-chain. It stores Ethereum block headers in cells, consuming capacity, and it needs to verify Merkle proofs on-chain, consuming cycles.

A trusted authority on the other hand as in example A) above is much easier to implement and requires very little resources to operate. Since it puts all locked funds into the hands of one a single entity, I would not suggest to choose that design other than for a proof of concept as a development milestone.

A sensible middle ground is normally a design with a threshold signature verifier (where multiple relayers need to sign each transaction) and a slashable collateral component (where each of them needs to stake tokens as a collateral that can be slashed for signing wrong messages).

In the end, we are facing a trade-off here between trustlessness/decentralization and cost of implementation and operation.

It is useful to note that light client operation contains higher fixed resource usage on-chain (meaning it scales well and get’s cheaper for every additional transaction), while a threshold signature setup contains higher variable resource usage off-chain (since the relayers need to be incentivized to coordinate, sign and behave correctly, meaning costs for users do not decrease significantly with additional transactions).

Hope that answers your question!