The State of ZK-

Bridges
by Vaish Puri, Can Gurel

1
 BRIDGES

The State of ZK-Bridges

Feb 16th, 2023 • 17 min read

Written by: Vaish Puri, Can Gurel

The author(s) of this report may personally hold material positions in ETH and CELESTIA. The authors have not purchased or sold
any token for which the authors had material non-public information while researching or drafting this report. These statements
are made consistent with Delphi’s commitment to transparency and should not be misconstrued as a recommendation to
purchase or sell any token or to use any protocol. The content of this report reflects the opinions of its authors and is presented for
informational purposes only. This is not and should not be construed to be investment advice.

Our affiliate Delphi Ventures LLC may have investments in assets or protocols identified in this report. Please see Ventures’
website for investment disclosures. These disclosures are solely the responsibility of Delphi Ventures.

1
Table of Contents
Introduction ..................................................................................................................... 2
ZK-Bridges - What Are They Good For? ............................................................... 3
ZK-Bridges vs. ZK-Rollups ................................................................................ 3
ZK-Bridge Landscape ........................................................................................ 4
zkBridge ............................................................................................................................ 5
Electron Labs .................................................................................................................. 7
Polymer Labs .................................................................................................................. 9
ZKPs to the Rescue? .................................................................................................. 10
Succinct Labs ............................................................................................................... 10
=nil; Foundation ............................................................................................................. 11
Conclusion ..................................................................................................................... 12
Bull Cases .............................................................................................................. 12
Bear Cases ............................................................................................................ 13
Final Words .................................................................................................................... 15

1
Introduction
Similar to the scalability trilemma, protocols engaging in interoperability can
follow a maximum of 2/3 fundamental properties: trustlessness, extensibility, and
generalizability.

Traditionally, interoperable protocol layers can be broken down into three types
of bridges:

Natively verified

Externally verified

Locally verified

Today, our focus will be on natively verified bridges. Unlike in externally and
locally verified bridges, in natively verified bridges (also known as light client-
based bridges), the operators of the bridge are the validators of the underlying
chains. Chains that interoperate run on-chain light clients for each other in their
execution layers which verify the consensus of the counterparty chains.

The design only requires trust in the economic security of the consensus of each
participating chain and eliminates the need for additional trust. For this reason,
natively verified bridges like Rainbow and IBC are considered to be the closest to
“trustless” across L1s. Natively verified bridges can be used to transfer any

2
arbitrary data such as balances, storage, transactions, and events from the
source chain to the target chain.

However, they have two main limitations: cost and extensibility. To verify each
other’s consensus, the chains must continuously keep track of the active
validator sets and verify their signatures (consensus votes). This can be
computationally expensive, especially if the receiving chain does not natively
support the necessary precompiles and curves related to the consensus
mechanism of the sending chain. This hinders the extensibility of light client
bridges across heterogenous chains.

So far, only IBC on Cosmos app-chains has successfully deployed on-chain light
clients at significant scale. This has been achieved by substantial standardization,
which requires all chains to conform to predetermined compatibility
requirements.

ZK-Bridges – What Are They

Good For?
Recently, there has been significant effort to use ZKP technology to build cheap
light client-based bridges. At their core, these bridges leverage ZKPs (commonly
ZK-SNARKs) to reduce the gas costs of on-chain verification.

ZK-SNARKs allow for two main functionalities:

ZK aspect: hide inputs into the function being proved

SNARK aspect: succinctness gives way to scalability

The key to this scaling is the succinctness property; instead of verification being
done directly on-chain, consensus can be proven off-chain and cheaply
verified on-chain via succinct ZK-proofs. As a side effect, ZK-bridges also
stretch the extensibility of light client bridges, as chains no longer need to natively
support each other’s signature schemes in order to cheaply interoperate.

ZK-Bridges vs. ZK-Rollups

For the sake of clarity, it’s important to distinguish between ZK-bridges and ZK-

3
rollups. In ZK-rollups, ZKPs are used to validate every state transition, ensuring
the rollup never makes an invalid transition. ZK-bridges, on the other hand, only
prove consensus (with 2/3 validator signatures) and not individual state
transitions (think transactions). This means that if the source chain’s validators
collude, they could trick the destination chain into accepting an invalid state
transition such as creating fake tokens. The on-chain light client on the
destination chain wouldn’t be able to detect this, as it only verifies consensus (via
2/3 validator signatures) and not the state transition rules.

To summarize — in ZK-bridges, ZKP technology is used to reduce the costs of

verification without introducing new trust assumptions. As a side effect, ZKPs
also help natively verified bridges improve their extensibility.

ZK-Bridge Landscape
There are a few major protocols that have similar approaches to bridge design
but differ in which consensus protocols they support as well as their proving
mechanisms: zkBridge, Succinct, Electron Labs, Polymer Labs, and =nil;
Foundation.

4
All of these protocols have a similar ideology — they aim to prove the consensus
of a source chain on the target chain’s execution layer in a reliable and scalable
manner. Upon verification, access to the block header is granted, which enables
the proving of anything on the state of the source chain in the context of the
target chain, such as messages and token transfers.

We’ll now take a deeper look into each project.

zkBridge
zkBridge focuses on bridging from Cosmos to Ethereum. This is because it has
historically been costly to do this in practice due to high Ethereum gas fees and
the EVM not supporting precompiles for verifying signatures (EdDSA) used widely
in the Cosmos ecosystem.

The high-level idea in zkBridge is similar to all other ZK-bridges. Instead of directly
verifying validator signatures on-chain, they prove correctness of signatures off-
chain and verify the proof on-chain. A crucial aspect that differentiates zkBridge
from others is their two-layer proof-generation process which reduces both
proof-generation time and on-chain verification costs to practical levels.

In ZKPs, computation that needs to be proven has to be expressed as an

arithmetic circuit. ZK-SNARKs are the most commonly used ZKPs in the
blockchain space today. While proof verification in SNARKs is fast (can be

5
constant size), proof generation can be slow, scaling linearly with the circuit size.
With bridges in particular, circuit sizes can become very large due to the complex
nature of digital signatures and the large number of signatures involved in each
block. This can significantly increase the latency of the bridge if proof generation
is done natively.

The good news is that most of the verification in bridges can be broken down to
identical sub-units. For example, a single circuit verifying 100 signatures can be
broken down into 100 sub-circuits, each verifying a single signature.

zkBridge takes advantage of this fact by using deVirgo, a novel distributed ZKP
protocol. With deVirgo, proof generation is distributed over multiple machines
and performed in parallel. The more machines used, the faster the proofs can be
generated. Anyone can participate in this proof generation and potentially get
rewarded in return.

deVirgo fixes the latency problem. However, unlike most SNARKs, which have
constant proof sizes, Virgo proofs can be very large and costly for on-chain
verification. To address this, zkBridge introduces a second layer to their proving
process. In this step, Virgo proofs are transformed into a commonly used ZK-
SNARK (Groth16) which has a constant size. This reduces on-chain gas costs by
~330x.

Through their novel two-layer proof system, zkBridge achieves practical

performance for both fast proof generation and cheap proof verification. Their
results are remarkable — a single block header from a typical Cosmos chain can
be verified on Ethereum within 20 seconds and consume only 230k gas (around
1.5x a Uniswap swap fee).

This process can be visualized below:

6
Note that a major advantage of zkBridge’s implementation is that parallel proving
via deVirgo can render bridges in other directions feasible as well. Particularly,
building an on-chain light client for Ethereum has been very challenging due to
the large number (400k+) of Ethereum validators (more on that later). deVirgo can
be an effective solution here. Indeed, zkBridge claims to already have a prototype
for an on-chain Ethereum ZK light client, but technical details haven’t been
publicly shared yet.

Another important aspect of zkBridge is the modular nature of their

implementation, where the verification logic is decoupled from the application.
This would enable many cross-chain applications to make use of the same
zkBridge implementation.

There isn’t much info regarding the timeline for productizing zkBridge, but we
know that it has been implemented by certain chains already and we’re eager to
follow the team’s progress.

Electron Labs
Similar to zkBridge, Electron Labs’ initial focus has been on generating proofs for
Tendermint consensus, specifically aiming to bring IBC to Ethereum.

Unlike zkBridge, which parallelizes proof generation, Electron conducts

batching. Namely, Electron Labs has created a circom-based library that

7
generates zk-SNARK proofs for batches of Ed25519 signatures (used in
Tendermint light clients), generating proof-of-signature validity off-chain and
verifying it on-chain on Ethereum.

This leads to a trade-off between gas and latency. If each batch contains a large
number of signatures, the number of batches can be reduced. This decreases
on-chain costs (less proofs to be verified) but increases latency because proving
a batch requires a larger circuit size.

Applications determine their desired balance along this spectrum, with bridging
from Cosmos to Ethereum typically resulting in latency in the order of minutes. As
shown by Electron’s results, gas costs are practical. Verifying a Cosmos block
costs around $20. However, because there is parallel proof generation, a single
header verification can take around 5-10 mins, which is an order of magnitude
higher than that of zkBridge (mins vs. seconds).

Electron Labs’ performance results can be seen below:

We note that Electron also considers generating proofs in parallel and recursively
transforming them into a single proof to further reduce gas and latency.

Recently, Electron Labs was given a grant to improve NEAR’s Rainbow Bridge. As
we mentioned earlier, Rainbow Bridge is a natively verified bridge between
Ethereum and NEAR. Due to its optimistic nature (Rainbow uses fraud proofs),
bridge latency can be several hours when going from NEAR to Ethereum. The
idea here is to reduce this time via Electron’s batched ZK-proofs. Electron has
already built an implementation of this which is currently in public testnet,

8
achieving eight minutes of latency with $5 of gas costs per header.

Polymer Labs
Polymer’s architecture is distinct from others because it incorporates the
PolymerDAO, a Cosmos app-chain with plans to become an IBC hub. Similar to
zkBridge and Electron, Polymer wants to extend IBC beyond Cosmos. However,
Polymer’s approach encompasses a much broader scope.

Polymer will serve as an omni-chain hub connecting both IBC and non-IBC L1s.
Interestingly enough, Polymer also wants to bring IBC to rollups. It is expected to
launch this year as one of the consumer chains of the Cosmos Hub.

Technical details of Polymer’s implementation have yet to be shared (whitepaper

expected soonTM). For the time being, all we know is that the Polymer team has
conducted extensive research and development in augmenting IBC with both
ZK-proofs (ZK-IBC) and fraud-proofs (optimistic-IBC).

For their ZK-IBC construction, Polymer Labs has selected a combination of the
recursive Plonky2 and Groth16 SNARK constructions. The motivations here are
quite similar to the dynamics seen in the zkBridge implementation; the use of
recursive proofs reduces the proof-generation time by distributing the linear
work across multiple machines.

A distinct design goal of Polymer is to enable full compatibility with IBC, which

9
would allow Polymer to support advanced IBC features such as Interchain
Accounts and multi-hop transfers. It would also allow connected chains to benefit
from the ongoing progress made by the wider IBC community.

ZKPs to the Rescue?

We have evaluated projects that primarily focus on proving the consensus of
Cosmos chains. We’ll now zoom in on Ethereum and the challenges involved in
building an Ethereum on-chain light client.

Building an on-chain light client for Ethereum has been difficult in the past due to
its PoW consensus mechanism. With Ethereum moving to PoS and rapid
advancements in ZKP technology, there is excitement about developing on-chain
ZK-light clients for Ethereum.

Unfortunately, it’s very hard to build a secure Ethereum on-chain light client with
practical performance. As previously explained, light clients keep track of active
validators. This requires storing the public keys of active validators and their
stake weights. Ethereum has a large validator set (over 400k) which regularly
rotates, making it very expensive to store and track on-chain.

To address this issue, Ethereum introduced a separate consensus algorithm

designed for light clients in the Altair hard fork. This consensus is run by the sync
committee. The sync committee consists of 512 randomly chosen validators and
rotates infrequently, making it easier for light clients to keep track. However, this
results in a security trade-off. The slashable stake of the 512 validators is much
less than the stake of the full Ethereum consensus. As it turns out, the sync
committee doesn’t get slashed for signing invalid attestations in the current
implementation. In other words, there is little-to-no security backing up the
attestations of the sync committee. While this protocol can still be useful for off-
chain light clients, it simply can’t provide a secure basis for a light-client bridge
implementation.

Succinct Labs
As previously mentioned, a light client backed by Ethereum’s full economic
security has to keep track of 400k+ validators, which is very expensive to do on-

10
chain.

Indeed, this is why Succinct built an Ethereum and Gnosis bridge which doesn’t
ZK-prove the full Ethereum consensus, but only the attestations of the sync
committee. As mentioned earlier, this isn’t sufficient to build an accountable,
secure bridge.

Succinct’s future roadmap involves proving the full Ethereum consensus.

Succinct has achieved noteworthy optimizations in this direction. For example,

instead of storing the list of validator public keys directly on-chain, they have
decided to store only a commitment (think hash) to this list on-chain and use an
additional SNARK to prove that the commitment matches the list as validators
rotate. Building a full Ethereum light client is not trivial, and clever workarounds
like these will be necessary to build them in practice.

Fun fact — a recently released academic study walks through how to build
practical, accountable light clients for PoS chains with large validator sets. Among
other innovations, the work involves storing a commitment to a list of all the
signers’ public keys.

=nil; Foundation
Unlike the previous projects, Nil is not only focused on ZK-bridges but also on
building ZK-based infrastructure that can be used in a number of different ways.
To this extent, Nil describes itself as trustless data accessibility. Nil’s offerings can
be used by bridges, dApps, oracles, and even L1 protocols (Pluggable Scaling, as
they call it).

Nil is building (i) 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) their own proof system known as
Placeholder (yes, that is the actual proof-system name). All of these products
complement each other and form the building blocks for their offerings.

On the bridging front, Nil’s primary focus is to verify the Mina blockchain on
Ethereum. This work goes back to 2021, when the Mina and Ethereum foundations
announced a joint request for proposals. Since then, Nil has come a long way, and
is getting very close to having a Mina->Ethereum bridge.

11
For the uninitiated, Mina is a unique L1 blockchain where every state transition
(from genesis to the tip) is recursively proven and summarized as a single SNARK
proof, which is always 22 kilobytes in size. In other words, Mina already has O(1)-
sized light-client proofs using recursive SNARKs. Note that these light clients are
special in that they not only verify consensus but also every state transition.

Therefore, a Mina to Ethereum bridge is a special case that’s different from

previously discussed ZK-bridges. Similar to rollups and validium bridges (and
unlike IBC), Ethereum would not have to trust Mina’s validators for state validity.
Those interested in this unique aspect of Mina can read more here.

While Mina already comes with its own SNARK-proof system (Kimchi), it’s too
expensive for Ethereum smart contracts to verify. For this reason, Nil first
transforms Mina’s proofs into its own Placeholder proofs before posting them to
Ethereum.

We note that this bridge will only go in one direction to start. It will not enable
Ethereum tokens to be transferred to Mina, but will allow Ethereum to verify the
entire state of Mina and read any of its data. This is still quite useful, as it will allow
zkSnapps (Mina smart contracts) to send data to Ethereum. An interesting
anticipated use case here is zkOracles.

Conclusion
So, are ZK-bridges really the end-all-be-all for bridge design? Let’s look at a few
bull and bear cases.

Bull Cases
Recursive & parallelizable ZKPs promise us wonderland

Recursive ZKPs coupled with parallelized proof generation can achieve

remarkable performance. At maturity, blocks from many chains can be proven
together, driving amortized costs per transaction to zero. Furthermore, via
parallelization, proof generation can match the rate of block production across
the board. Connections across chains can all be point-to-point. It’s hard not to be
bullish in this scenario.

Narrow ZKP scope

12
ZK-rollups and ZK-bridges have different objectives and aren’t in competition.
However, we want to highlight that the scope of ZKPs in ZK-bridges is much
smaller than in ZK-rollups. Rollup circuits are designed to prove every state
transition, whereas ZK-bridge circuits’ main task is to verify the validity of
signatures. The narrow scope is helpful in commoditizing proofs and decreasing
the overall software bug surface.

Reducing reliance on Infura

ZK-based light clients aren’t only useful for bridging, but also for all kinds of
applications (wallets, indexers, block explorers, RPC services) that want to
trustlessly query/serve data. They reduce reliance on centralized middleware
and enhance user privacy.

Doubling down on IBC

Deemed as the most secure interoperability solution by many, IBC has existing
network effects. ZKPs can be used to extend IBC to ecosystems beyond Cosmos.
Composable is bringing IBC to Polkadot and NEAR, Electron/zkBridge to
Ethereum, and Polymer (among others) to Celestia/Ethereum rollups.

Too much brain power

As we saw, there are a number of independent projects and developer interest is

increasing. Our list isn’t comprehensive, and there are other notable projects
working in the same direction such as DendrETH, HyperOracle, Langrange,
Herodotus, etc.

Bear Cases
Relayer incentivization and liveness

One aspect we haven’t discussed yet is liveness. In ZK-bridges, relayers and

provers aren’t trusted for safety but are trusted for liveness. Most of DeFi (lending
protocols, oracles, etc.) can’t tolerate liveness failures. To build safe cross-chain
dApps, it’s vital for ZK-bridges to have reliable relaying. In ZK-bridges, in addition
to relaying messages, relayers will have to generate ZKPs or outsource that task
to provers.

Nil’s Proof Market is worth highlighting here, as it can play an important role by

13
enabling an open, healthy market for ZKPs. As we saw, the performance of ZKPs
can change based on proof types, circuit sizes, and hardware specs. The idea
with Proof Market is to incentivize proof generation and circuit design. On the
supply side, provers compete based on the cost and speed of proof generation.
On the demand side, applications such as ZK-bridges, indexers, etc. bid for
proofs.

On a related note, monetization of bridges remains an open question, and ZK-

bridges are no exception. Cross-chain MEV is likely to represent the lion’s share
for the foreseeable future.

Software bugs

The biggest bear case is software bugs. The primary causes of bridge hacks have
been software bugs, not trust assumptions. We acknowledge the power of ZKP
tech for not introducing new assumptions, but most of these circuits add
complexity to code and introduce new surface area for software bugs. It remains
to be seen to what extent the market can build confidence for these software
implementations. Audits, rate limits, and emergency shutdowns will be crucial.

Bridges across L1s have anti-network effects

This goes back to Vitalik’s “the future is multi-chain but not cross-chain” post.
While we think bridge adoption is inevitable, we do agree that there is a limit to
how much value can rely on bridges. As stated in that post, cross-chain has an
anti-network effect; as more activity happens cross-chain, the validators of
underlying chains have motivation to collude and steal. Importantly, some
consensus algorithms aren’t accountable (for example, Mina, Avalanche, etc.). If
there is collusion, one can’t tell which subset of validators colluded.

Extensibility and maintenance

While ZK-bridges reduce the costs of bridging across heterogenous chains, the
extensibility benefit here is limited. The verification logic of ZK-bridges is tightly
coupled with consensus. Thus, chains with different consensus algos/signatures
require different implementations. Crucially, any changes in consensus or hard
forks must be reflected in the light clients, requiring additional work and
maintenance.

Will Ethereum ever have secure on-chain light clients?

14
 As we saw throughout this report, the large validator set of Ethereum isn’t friendly
for on-chain light clients. However, as mentioned, a recent solution shows
promise to be a viable solution. It doesn’t require changes to consensus, but
requires the EVM to support SNARK-friendly curves.

Final Words
To sum things up, ZK-bridges use ZKPs to improve performance of light-client
bridges without introducing new trust assumptions. Polymer and zkBridge stand
out with their use of parallelizable/recursive proofs. Others will adopt similar
solutions to cut down proving time and verification costs. Nil’s Proof Market is an
important step for ZK-bridges and other ZK-middleware seeking to receive
reliable proof generation/relaying via incentives. Meanwhile, ZKPs will help IBC to
extend beyond Cosmos. As infra rails for ZK-bridges mature in the next year or
two, we will see an explosion of growth in the app-specific bridging arena.

Special thanks to Abe Weiskorn for designing the cover image for this report and
to Ashwath Balakrishnan and Brian McRae for editing.

delphi-1091-a135f6

15