Interoperability protocols, like the scaling trilemma, may adhere to a maximum of two-thirds of three essential properties: trustlessness, extensibility, and generalizability.

Interoperable protocol layers have traditionally been divided into three categories of bridges:

Natively validated
Externally validated
Locally validated

Today, we'll concentrate on natively certified bridges. Unlike externally and locally verified bridges, the operators of natively verified bridges (also referred to as light client-based bridges) are the validators of the underlying chains. Chains that interoperate run on-chain light clients for each other in their execution levels which validate the consensus of the counterparty chains.

The architecture demands just trust in the economic security of each participant chain's consensus and avoid the need for further trust. As a result, natively certified bridges such as Rainbow and IBC are thought to be the most "trustless" over L1s. Natively verified bridges may be used to move any arbitrary data from the source chain to the destination chain, such as balances, storage, transactions, and events.

They do, however, have two major drawbacks: cost and extensibility. To validate each other's consensus, the chains must maintain track of the active validator sets and validate their signatures on a constant basis (consensus votes). This may be computationally costly, particularly if the receiving chain lacks native support for the requisite precompiles and curves associated with the transmitting chain's consensus method. This makes it difficult to extend light client bridges across heterogeneous chains.

Only IBC on Cosmos app chains has so far successfully deployed on-chain light clients at a large scale. This has been accomplished via significant standardization, which requires all chains to meet established compatibility standards.

Why ZK-Bridges?

There has recently been a substantial attempt to employ ZKP technology to develop low-cost light client-based bridges. These bridges, at their heart, use ZKPs (also known as ZK-SNARKs) to lower the gas costs of on-chain verification.

ZK-SNARKs enable two primary functions:

Aspect of ZK: conceal inputs into the function being demonstrated
Aspect of SNARK: succinctness gives way to scalability

The key to this scalability is the succinctness attribute; rather than directly on-chain verification, consensus may be demonstrated off-chain and inexpensively validated on-chain using succinct ZK-proofs. As a result, ZK-bridges extend the extensibility of light client bridges since chains no longer need to natively support each other's signature schemes in order to interoperate inexpensively.

ZK- Bridges vs. ZK-Rollups

It's crucial to differentiate between ZK-bridges and ZK-rollups for clarity's sake. ZKPs are used in ZK-rollups to verify every state change, guaranteeing that the rollup never makes an invalid transition. In contrast, ZK-bridges only verify consensus (with 2/3 validator signatures) and not individual state changes. This implies that if the validators on the source chain work together, they may mislead the destination chain into accepting an incorrect state change, such as producing bogus tokens. The destination chain's on-chain lite client would be unable to discover this since it only confirms consensus (through 2/3 validator signatures) and not the state transition rules.

To conclude, ZKP technology is utilized in ZK-bridges to lower verification costs without adding new trust assumptions. As a result, ZKPs aid in the extensibility of natively validated bridges.

>>> Read more: Optimistic Rollups versus ZK-Rollups - What is more optimal for Layer 2?

ZK-Bridge Landscape

There are a few prominent protocols that use similar techniques to bridge design but vary in terms of which consensus protocols they accept and how they prove their validity: zkBridge, Succinct, Electron Labs, Polymer Labs, and =nil; Foundation are other examples.

All of these protocols have a common ideology: they seek to demonstrate a source chain's consensus on the target chain's execution layer in a reliable and scalable way. Access to the block header is allowed upon verification, allowing the proof of anything on the status of the source chain in the context of the destination chain, such as messages and token transfers.

We'll now go further into each project.

zkBridge

zkBridge focuses on connecting Cosmos and Ethereum. This is owing to the high Ethereum gas prices and the EVM's lack of support for precompiles for verifying signatures (EdDSA), which are commonly employed in the Cosmos ecosystem.

The overall concept of zkBridge is identical to that of all previous ZK-bridges. Rather than directly confirming validator signatures on-chain, they prove signature correctness off-chain and verify the evidence on-chain. A key feature that distinguishes zkBridge from competitors is its two-layer proof-generation approach, which decreases both proof-generation time and on-chain verification costs to manageable levels.

zkbridge mechanism

Source: zkBridge.org

Computations that must be demonstrated in ZKPs must be stated as an arithmetic circuit. Nowadays, ZK-SNARKs are the most widely utilized ZKPs in the blockchain realm. Although SNARK proof verification is quick (can be fixed size), proof production may be sluggish, growing linearly with circuit size. Due to the intricate nature of digital signatures and the enormous number of signatures involved in each block, circuit sizes in bridges may grow quite big. If proof creation is done natively, this may greatly increase the bridge's latency.

The good news is that most bridge verification can be decomposed into identical sub-units. A single circuit that verifies 100 signatures, for example, may be divided into 100 sub-circuits that individually check a single signature.

This characteristic is used by zkBridge, which employs deVirgo, a revolutionary distributed ZKP protocol. Proof creation in deVirgo is dispersed across numerous computers and conducted in parallel. The greater the number of computers employed, the quicker the proofs may be created. Everyone may take part in this evidence generation and perhaps be rewarded.

DeVirgo resolves the latency issue. Virgo proofs, on the other hand, might be quite huge and expensive for on-chain verification, in contrast to most SNARKs, which have fixed proof sizes. In order to overcome this, zkBridge adds a second layer to its proving procedure. Virgo proofs are converted into a frequently used ZK-SNARK (Groth16) with a constant size in this stage. This cuts on-chain gas expenses by a factor of 330.

zkBridge delivers realistic performance for both quick proof production and affordable proof verification using their new two-layer proof architecture. Their findings are astounding: a single block header from a typical Cosmos chain can be confirmed on Ethereum in 20 seconds while using just 230k gas (around 1.5x a Uniswap swap fee).

It should be noted that one significant benefit of zkBridge's implementation is that parallel proving through deVirgo may make bridges in other directions possible as well. Building an on-chain light client for Ethereum, in particular, has been very difficult owing to the enormous number (400k+) of Ethereum validators (more on that later). DeVirgo may be an appropriate remedy in this case. Indeed, zkBridge claims to have a prototype for an on-chain Ethereum ZK lite client, but technical specifics have not yet been made public.

Another key feature of zkBridge is its modular implementation, which separates the verification mechanism from the application. This would allow many cross-chain apps to utilize the same zkBridge implementation.

There isn't much information available on the timescale for productizing zkBridge, but we do know that it has already been integrated by several chains, and we're excited to track the team's development.

Electron Labs

Electron Labs, like zkBridge, has initially focused on providing proofs for Tendermint consensus with the goal of bringing IBC to Ethereum.

In contrast to zkBridge, which parallelizes proof creation, Electron does batching. Electron Labs, in particular, has developed a circom-based library that creates ZK-SNARK proofs for batches of Ed25519 signatures (used in Tendermint lite clients), creating proof-of-signature validity off-chain and confirming it on-chain on Ethereum.

As a result, there is a trade-off between gas and latency. The number of batches may be lowered if each batch has a significant number of signatures. This lowers on-chain expenses (fewer proofs to verify) but raises delay since proving a batch needs a bigger circuit size.

Applications choose their preferred balance along this range, with a bridge from Cosmos to Ethereum generally resulting in minutes of delay. Gas expenses are reasonable, as shown by Electron's performance. Verifying a Cosmos block costs roughly $20. Nevertheless, due to concurrent proof creation, a single header verification might take 5-10 minutes, which is an order of magnitude faster than zkBridge (mins vs. seconds).

The following are Electron Laboratories' performance results:

To further decrease gas and time, Electron explores creating proofs in parallel and recursively converting them into a single proof.

Electron Labs just received a grant to upgrade NEAR's Rainbow Bridge. Rainbow Bridge, as previously stated, is a natively certified bridge between Ethereum and NEAR. Bridge delay from NEAR to Ethereum may be many hours due to its optimistic nature (Rainbow employs fraud proofs). The goal here is to shorten this time by using Electron's batched ZK-proofs. Electron has already constructed a version of this that is now available on the public testnet, reaching eight minutes of delay with a $5 gas cost per header.

Polymer Labs

Polymer's architecture differs from others in that it includes the PolymerDAO, a Cosmos app chain with ambitions to become an IBC hub. Polymer, like zkBridge and Electron, wants to expand IBC beyond Cosmos. Polymer's method, on the other hand, is far larger in scope.

polymer labs ibc transport

Source: Polymer labs

Polymer will act as an omni-chain hub, linking L1s from both IBC and non-IBC chains. Polymer, interestingly, seeks to introduce IBC to rollups. It is anticipated to debut this year as one of the Cosmos Hub's consumer chains.

Technical information on Polymer's implementation has yet to be released (whitepaper expected soon). For the time being, we only know that the Polymer team has done substantial research and development on enhancing IBC with both ZK-proofs (ZK-IBC) and fraud-proofs (optimistic-IBC).

Polymer Labs used a mix of the recursive Plonky2 and Groth16 SNARK constructs for their ZK-IBC. The motives are quite similar to those observed in the zkBridge implementation; using recursive proofs decreases proof-generation time by dispersing the linear effort over numerous computers.

Polymer's design aim is to achieve complete compatibility with IBC, allowing Polymer to implement sophisticated IBC features such as Interchain Accounts and multi-hop transfers. It would also enable linked chains to benefit from the IBC community's continual advancements.

We examined initiatives whose primary goal is to demonstrate the consensus of Cosmos chains. We'll now focus on Ethereum and the problems of developing an Ethereum on-chain light client.

Due to Ethereum's PoW consensus method, developing an on-chain light client has been challenging in the past. With Ethereum switching to PoS and quick improvements in ZKP technology, there is a lot of interest in building on-chain ZK-light Ethereum clients.

Sadly, developing a secure Ethereum on-chain light client with realistic performance is really difficult. Light clients, as previously stated, maintain track of active validators. This necessitates the storage of active validators' public keys as well as their stake weights. Ethereum has a massive validator set (over 400k) that rotates on a regular basis, making it very costly to maintain and manage on-chain.

To overcome this problem, the Altair hard fork of Ethereum included a different consensus method optimized for light clients. The sync committee is in charge of this agreement. The sync committee is made up of 512 randomly selected validators who rarely cycle, making it simpler for light clients to keep track of things. This, however, results in a security trade-off. The 512 validators' slashable stake is substantially lower than the stake of the whole Ethereum consensus. Under the present implementation, the sync committee is not punished for signing invalid attestations. In other words, there is little to no security backing up the sync committee's attestations. Although this protocol is still useful for off-chain light clients, it cannot serve as a secure foundation for a light-client bridge solution.

Succinct Labs

As previously stated, a light client supported by Ethereum's complete economic security must maintain track of 400k+ validators, which is prohibitively costly on-chain.

Exactly, this is why Succinct designed an Ethereum and Gnosis bridge that does not ZK-prove the complete Ethereum consensus but simply the sync committee's attestations. As previously stated, this is insufficient to construct a safe, secure bridge.

succint labs UI

Source: Succinct labs

Succinct's future plans include demonstrating complete Ethereum consensus. Succinct has made significant improvements in this area. Instead of maintaining the list of validator public keys directly on-chain, they have opted to store simply a commitment to this list and utilize an extra SNARK to show that the commitment matches the list when validators rotate. Developing a comprehensive Ethereum lite client is not easy, and in fact, smart workarounds like these will be required.

A new academic paper describes how to develop realistic, responsible light clients for PoS chains with big validator sets. The job includes, among other things, storing a commitment to a list of all the signers' public keys.

=nil; Foundation

Unlike past initiatives, Nil is not just concerned with ZK-bridges but also with the development of ZK-based infrastructure that may be utilized in a variety of ways. Nil defines itself as "trustless data accessibility" to this degree. Bridges, dApps, Oracles, and even L1 protocols may utilize Nil's offers (Pluggable Scaling, as they call it).

Nil is developing a permissionless marketplace to decentralize ZK-proof generation, (ii) ZK-LLVM, a compiler that makes high-level programming languages like Rust or C++ ZK-provable, and (iii) Placeholder, their own proof system (yes, that is the actual proof-system name). All of these items complement one another and serve as the foundation for their services.

Nil's key aim on the bridge front is to validate the Mina blockchain on Ethereum. This effort dates back to 2021 when the Mina and Ethereum foundations jointly released a call for ideas. Nil has gone a long distance since then and is now very near to having a Mina->Ethereum bridge.

Mina is a one-of-a-kind L1 blockchain in which every state change (from genesis to tip) is recursively proved and summarized in a single SNARK proof that is always 22 kilobytes in size. In other words, utilizing recursive SNARKs, Mina already has O(1)-sized light-client proofs. It should be noted that these light clients are unique in that they verify not just consensus but also every state transition.

As a result, a Mina to Ethereum bridge is a distinct situation from the previously mentioned ZK-bridges. Similar to rollups and validium bridges (and unlike IBC), Ethereum would not have to trust Mina's validators for state validity.

Although Mina already has its own SNARK-proof method (Kimchi), it is too costly to verify for Ethereum smart contracts. As a result, before uploading Mina's proofs to Ethereum, Nil first converts them into its own Placeholder proofs.

We should notice that this bridge will initially only travel in one way. It does not allow Ethereum tokens to be moved to Mina, but it does allow Ethereum to validate Mina's full state and access any of its data. This is still very helpful since it allows zkSnapps (Mina smart contracts) to transfer data to Ethereum. zkOracles is an intriguing predicted use case here.

Predictions for ZK bridges

So, are ZK-bridges the pinnacle of bridge design? Let's take a look at some bull and bear situations.

Bull cases

Recursive & parallelizable ZKPs offer us:

Recursive ZKPs combined with parallelized proof production may produce impressive results. At maturity, blocks from many chains may be proved together, resulting in zero amortized costs per transaction. Additionally, proof creation may be parallelized to match the pace of block production across the board. All connections between chains may be point-to-point. It's difficult not to be optimistic in this situation.

ZKP scope

ZK-rollups and ZK-bridges have distinct goals and are not competitors. Nonetheless, we would like to point out that the scope of ZKPs in ZK-bridges is significantly narrower than in ZK-rollups. Rollup circuits are intended to prove every state change, while ZK-bridge circuits are intended to validate signatures. The small scope aids in the commoditization of proofs and the reduction of the total program bug surface.

Lowering dependency on Infura ZK-based light clients is important not just for bridging but also for all types of applications (wallets, indexers, block explorers, RPC services) that seek to query/serve data with confidence. They lessen dependency on centralized middleware while also improving user privacy.

Increasing Investment in IBC

Many consider IBC to be the best secure interoperability option, and it has established network effects. ZKPs have the potential to expand IBC to ecosystems other than Cosmos. Composable is introducing IBC to Polkadot and NEAR, Electron/zkBridge to Ethereum, and Polymer to Celestia/Ethereum rollups, among other things.

Many innovations

As we've seen, there are several separate initiatives, and developer interest is growing. Our list is not exhaustive, and other significant projects going in a similar direction include DendrETH, HyperOracle, Lagrange, Herodotus, and others.

Bear cases

Incentives for relayers and liveness

One topic we haven't covered yet is liveness. Relayers and provers in ZK-bridges are trusted for liveness rather than safety. The majority of DeFi (loan protocols, oracles, and so on) cannot tolerate liveness failures. It is critical for ZK-bridges to have dependable relaying in order to develop secure cross-chain dApps. In ZK-bridges, relayers must produce ZKPs in addition to relaying messages or delegate this work to provers.

Nil's Proof Market is worth mentioning since it can play a critical role in providing an open, robust market for ZKPs. As previously shown, the performance of ZKPs may vary depending on proof kinds, circuit sizes, and hardware specifications. The Proof Market concept is to incentivize proof creation and circuit design. Provers compete on the supply side depending on the cost and speed of proof creation. Applications such as ZK-bridges, indexers, and others bid for proofs on the demand side.

In a similar manner, the monetization of bridges, including ZK-bridges, remains an unanswered subject. Cross-chain MEV is projected to constitute the lion's share for the foreseeable future.

Bugs in software

The most serious problem is software flaws. Software defects, not trust assumptions, have been the major culprits of bridge hacks. We recognize ZKP technology's strength in not adding new assumptions, however, the majority of these circuits increase the complexity of code and create more surface area for software vulnerabilities. It remains to be seen how far the market can create trust in these software solutions. Audits, rate caps, and emergency shutdowns will all be essential.

Bridges connecting L1s exhibit anti-network effects.

This is related to Vitalik's "the future is multi-chain but not cross-chain" post. Although we believe bridge adoption is unavoidable, we also believe there is a limit to how much benefit bridges can provide. Cross-chain has an anti-network impact, as described in that post; as more activity occurs cross-chain, the validators of underlying chains have the incentive to collude and steal. Notably, certain consensus algorithms are not held responsible (for example, Mina, Avalanche, etc.). If there is collusion, it is impossible to determine which subset of validators colluded.

Extensibility and maintenance

Although ZK-bridges lower the cost of bridging across diverse chains, the extensibility advantage is limited in this case. The verification logic of ZK-bridges is inextricably linked to consensus. As a result, chains with various consensus algorithms/signatures need distinct implementations. Any changes in consensus or hard forks must be reflected in the light clients, which necessitates more labor and maintenance.

Will there ever be safe on-chain light clients for Ethereum?

As we've shown throughout this article, Ethereum's massive validator set isn't ideal for on-chain light clients. Yet, as previously said, a recent solution seems to be a realistic option. It does not need modifications to consensus, but it does necessitate that the EVM support SNARK-friendly curves.

Bottom lines

To summarize, ZK-bridges use ZKPs to enhance the performance of light-client bridges while avoiding the introduction of additional trust assumptions. Polymer and zkBridge distinguish themselves by using parallelizable/recursive proofs. Others will follow suit in order to reduce proving time and verification expenses. Nil's Proof Market is a critical step for ZK-bridges and other ZK-middleware seeking dependable proof generation/relaying via incentives. Likewise, ZKPs will assist IBC in expanding beyond Cosmos. As infra rails for ZK-bridges evolve over the next year or two, the app-specific bridging market will explode.

Disclaimer:
This article is intended for and only to be used for reference purposes only. No such information provided constitutes advice or a recommendation that any investment or trading strategy is suitable for any specific name.

Zk bridges: The next big thing after zk rollups?