DLT Interoperability and More ⛓️#13 ⛓️ — zkBridge: Trustless Cross-chain Bridges Made Practical

In this series, we analyze papers on blockchain and interoperability.

This edition covers a recent paper on a zero-knowledge-based cross-chain bridge.

Grey Concrete Bridge on Body of Water Under Blue and White Sky during Daytime by Klas Tauberman

➡️ Title: zkBridge: Trustless Cross-chain Bridges Made Practical
➡️ Authors: Tiancheng Xie, Jiaheng Zhang, Zerui Cheng, Fan Zhang, Yupeng Zhang, Yongzheng Jia, Dan Boneh, Dawn Song

➡️ Paper source: https://arxiv.org/abs/2208.07119

➡️ Background:

This paper presents a bridge that is secured by SNARKs (the authors adopt a succinct non-interactive arguments of knowledge (SNARK) scheme satisfying completeness and knowledge soundness, and not zero-knowledge). Curiosity: just after a few days after this paper was released, and a few weeks after our own, there was yet another bridge hack: this time, the Binance bridge, for a total of around $560M.

The security assumptions of the bridge are 1) the underlying blockchains are secure, i.e., consistent and live, 2) underlying light client protocols and their implementation are secure, 3) there exists at least one honest node in the block header relay network.

Typically smart contracts implementing bridges can invoke a contract to retrieve verified block headers. After that, one can submit a Merkle proof to prove transaction inclusion (for example, that an asset is locked). This enables use cases as bridges. Thus, the light client is the entity that verifies block headers, and the applications using them are decoupled from the bridge. zk-SNARKS are used to prove that a block header is valid, namely because it follows the update rules for block headers. In Ethereum 2.0, the logic for a valid update is described here.

The technical challenges to implementing such a system are multiple. First, the light client update logic needs to be expressed as an arithmetic circuit. The EdDSA signature verification logic needs to be expressed as circuits because verifying the signatures from the light sync committee is necessary. While cheap to verify on CPUs, verifying EdDSA signatures on arithmetic circuits is expensive.

➡️ Contributions:

In this article, we will focus on the first contribution.

➡️ The bridge:

The idea is relatively simple: we have a set of relayers and a set of smart contracts. The relayers obtain block headers from the source chain, compute a proof of correctness (that asserts the new block header is valid), and send them to a smart contract on the target blockchain (the light client — which the authors call the updater contract). Now, there are different ways to do these proofs of correctness —e.g., e a notary signature, a multi-sig, using multi-party computation, or, in this case, zk-SNARKs. The proof is computed off-chain (expensive to calculate) and then sent to this light client contract.

The light client now is responsible for verifying the SNARK proof. Upon right validation, the new block header is accepted and exposed to a third-party contracts that want to use the light client. Bridges can be built on top of this light client, namely with the following logic: 1) we lock an asset on the source chain; 2) the process described above generates a proof that the new block header is X, 3) the light client takes the proof and verifies it. If correct, it exposes a list of updated block headers. The bridge consumes these block headers and basically exposes an interface for users (or parties operated by the bridge) to verify Merkle proofs. Then these proofs are validated against the new block header. If the proof is valid, it means that a transaction locking an asset took place on the source blockchain, and now we can mint tokens as part of the bridging process. This decoupling is powerful because it allows arbitrary cross-chain use cases to be developed, powered by a decentralized bridge.

💪 Strong points:

🤞 Suggestions for improvement:

🔥 Points of interest:

🚀 How does it relate to our work at Técnico Lisboa, INESC-ID, and Blockdaemon? (views are my own and do not necessarily reflect the opinions of my employer)

🚀 What are the implications for our work?

--

--

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store
Rafael Belchior

R&D Engineer at Blockdaemon. Opinions and articles are my own and do not necessarily reflect the view of my employer. https://rafaelapb.github.io