Introduction

In Part I we covered the concept of blockchain interoperability and how it will only increase in importance as alternative L1s, L2s and appchains emerge. The large amount of capital moved on bridges makes them attractive targets for hackers and in 2022 we saw $2.5b lost to multisig and smart contract vulnerabilities. Of all exploits that occurred that year, a staggering 69% were related to bridges.

At the heart of these losses were failures at Verification step of bridging, where the trust mechanism used to verify transaction validity was underpinned by humans & multisigs:

1. Ronin’s bridge was secured by a 5 of 9 multisig. 4 validators were operated by one party and compromised in one go, making the 5th an easy trigger
2. Harmony Bridge was secured by a 2 of 5 multisig which was compromised through unknown methods, though social engineering was suspected
3. Multichain’s private keys were a ‘multisig’ effectively held by one person

Given these vulnerabilities, the Verification step in the bridging process is much better served by trust-minimized methods that rely on code and math.

This is where Consensus Proofs come in as a potential solution. The approach relies on a prover verifying blockchain consensus of the source chain and using zero knowledge proofs to attest to validity of a transaction before releasing funds to a destination.

That’s a lot to unpack, so let’s first define what we mean by verifying blockchain consensus.

Verifying the source blockchain’s state / ‘consensus’

At their core, blockchains are ledgers that record transactions between accounts maintained by nodes that do not trust each other. Since there are many nodes validating a blockchain network, agreement must be reached amongst these validators on which block is the most recently added one, i.e. they must reach ‘consensus’ on the latest state.

Source: Adapted from Ethereum EVM illustrated

Reliably verifying source chain consensus on the destination chain is key to bridging because if you can verify the latest block of the source chain in a trust-minimized manner, you determine the latest ‘truth’ and then have the comfort to execute a corresponding action on the destination chain.

Verifying source chain consensus to enable bridging

For bridging, the protocol needs to determine that a ‘deposit’ transaction on the source chain was validly made. In practice this involves verifying two things:

1. Step 1. Verifying blockchain consensus, i.e. that the block we’re querying is a valid part of the source chain’s world state; and
2. Step 2. Check that the specific transaction, i.e. the ‘deposit’ transaction is included in the block (this can be proven with a Merkle Inclusion proof)

Upon verification of both, the destination chain can release assets to the user.

Voila, assets bridged.

In theory this sounds simple, but the tricky part is step 1: it is not so easy for a smart contract on one chain to verify the consensus of another (typically Ethereum as the source chain).

Current challenges with verifying consensus for bridging

The first challenge to point out is that different blockchains have different consensus mechanisms and proving consensus on each source chain requires very specific engineering work to set up. This means the verifying consensus step will need to be customized for each source chain. For now let’s focus on proving Ethereum consensus given it has the lion’s share of TVL and is the typical L1 users bridge from.

Ethereum has a large validator set of 700,000+ out of which more than 21,000 validators vote on a block in a slot. To achieve finality, a block should get votes from the ⅔ of the validator set which is roughly equivalent to 450,000 validator votes. Verifying full consensus would mean checking the validity of 450,000 signatures.

A less cumbersome method of checking Ethereum’s consensus involves the ‘light client protocol’. This uses a sync committee (512 validators selected at random every 27.3 hours) to attest that the latest block proposed is valid. Here, verifying consensus means checking the validity of 512 aggregated signatures.

In a bridging context, a smart contract on the destination chain can use the light client protocol and act as an on-chain ‘light client’ to verify the latest state of the source chain and ensure a ‘deposit’ was made. If satisfied, the smart contract releases funds on the destination chain.

Verifying source chain consensus (on Ethereum) via sync committee

This approach is not very practical because verifying 512 aggregated signatures directly in a smart contract on-chain is prohibitively costly without pre-compiles given Ethereum validators use BLS signatures.

The key to making this possible then, is taking the verification step off-chain…

… and this is where Consensus Proofs come in.

The Solution: Consensus Proofs of the sync committee signatures

Zero knowledge proofs have emerged as a viable solution to help blockchains take costly computations off-chain and verify the result on-chain. This allows a bridging smart contract on the destination chain to move costly computations (like validating source chain consensus) to an off-chain zero knowledge prover:

1. The prover will verify the signature and generate a Consensus Proof - i.e. a succinct zero-knowledge proof that attests that the block is the next valid block, as it has received ⅔ of sync committee attestations. This proof verifies the source blockchain’s consensus (Step 1. from above).
2. Once the validity of a block is proven, we can prove that a transaction was part of this block (Step 2. from above) using Merkle inclusion proofs. (Alternatively, a zero-knowledge proof can be generated off-chain and verified by a smart contract on the destination chain for the same purpose).

Verification with zk proofs allows us to move closer to trust-minimized bridging

After these two steps, the destination smart contract can safely release funds on the destination chain.

Using Consensus Proofs to verify source blockchain state is an important step towards trust-minimized bridging, but relying on the light client protocol & 512 validators has some limitations (highlighted in the table below).

Limitations with relying on the sync committee to verify consensus

As such, some teams are working on proving full ethereum consensus, which is a complex task and would involve verifying 450,000 signatures at the time of writing. Doing so in a zero knowledge circuit is no mean feat - but teams like Polyhedra Network and Succinct have committed to achieving this.

What’s better than proving 512 signatures? 450,000 signatures!

Polyhedra Network recently announced that they managed to verify 21,000 validator signatures that sign a block at a given slot in ZK and are working toward verifying all 450,000 signatures. More details on their approach and proving system can be found in their zkBridge paper.

Once we can verify full Ethereum consensus in zero-knowledge, verifying consensus of other chains with smaller validator sets in zero-knowledge should be relatively straightforward.

Risks of using zero knowledge proofs

While zero knowledge tech & Consensus Proofs solve for human fallibility, the discussion would be incomplete without acknowledging some of the risks that arise with using them in bridging.

Zero-knowledge technology is rapidly changing, as novel algorithms and systems continue to emerge. Some of these implementations are unaudited and could contain vulnerabilities, making them susceptible to potential exploits when significant incentives arise. Furthermore, even after audits, such complex cryptographic systems may contain undiscovered attack vectors which will be identified and rectified over time, to reach a matured, battle-hardened state.

Moreover, it remains to be seen at what transaction volume does the expense of generating and verifying zero-knowledge proofs become sufficiently amortized to be deemed cost-effective.

The teams building

To conclude, we’ll highlight some of the players building solutions in this space. While they have slightly differing approaches and go-to-markets they are pushing the limits of what zk-based bridging can do and heralding the emergence of trust-minimized interoperability.

Among them we have:

1. Polyhedra Network who have been designing and implementing the zkBridge protocol, and can be used to attest to another chain’s state. zkBridge currently supports bridging across more than 20 L1s and L2s, including Ethereum, Polygon, Binance Smart Chain, Optimism, Arbitrum. Polyhedra Network has integrated both sync committee based proofs and full consensus based proofs with LayerZero to facilitate zk-based bridging.
2. Succinct Labs who have been developing zk-based light clients to attest to Ethereum’s state and facilitate bridging between Gnosis Chain & Ethereum as source chains and Gnosis, Arbitrum, Avax, Binance Smart Chain, Optimism and Polygon as destination chains
3. Electron Labs who is focused on building bridging approaches between Ethereum and the Cosmos ecosystem
4. Polymer Labs aims to extend IBC connectivity across different chains through Polymer Hub, which enforces the IBC transport or TAO semantics across connected chains. Polymer Hub also enables a mesh interoperability model which has improved scaling properties compared to p2p or hub and spoke models.
5. Lagrange Labs who will use their own state committees (that are secured by Eigenlayer re-staking) to attest to the state of blockchains. They are targeting optimistic L2s (Arbitrum, Optimism, Base) and major L1s as their go-to-market

Teams working on Consensus Proofs

Conclusion

Interoperability is a core part of blockchain infrastructure. The first innings of bridging saw trust mechanisms underpinned by multisigs and compromised by reliance on humans. We’re now starting to move into the realm of bridges being secured by cryptography and math made feasible by the application of zero-knowledge proofs in the context of bridging.

In this part we covered how Consensus Proofs help solve for bridging by checking the latest finalized source blockchain consensus.

This technology, however, can be extended further to check historical consensus which enables more flexible cross-chain use cases beyond just bridging at the moment. And that is what we’ll explore in Part III of our series on Interoperability: Storage Proofs & the use cases they unlock.

Disclaimer：

1. This article is reprinted from [Superscrypt]. All copyrights belong to the original author [Jacob Ko]. If there are objections to this reprint, please contact the Gate Learn team, and they will handle it promptly.
2. Liability Disclaimer: The views and opinions expressed in this article are solely those of the author and do not constitute any investment advice.
3. Translations of the article into other languages are done by the Gate Learn team. Unless mentioned, copying, distributing, or plagiarizing the translated articles is prohibited.