Authors: Nina Rhines, Adit Kolli, Oluwadamola Olaiya, Pratik Nadipelli, Shrey Patel
This research was completed by Michigan Blockchain, in collaboration with LayerZero
Blockchain bridging protocols connect separate blockchain networks to allow for the transfer of digital assets or information between them. Bridging is a key component of achieving interoperability between different blockchain networks. An area of focus for many is the ability to bridge various cryptocurrencies, say to convert Bitcoin to Ethereum. However, there are many security concerns with existing bridging protocols, with DefiLlama reporting that over $2.5 billion has been stolen in bridge hacks since June 2016. Notable hacks in recent years include the Ronin, Binance, Wormhole, Nomad, Multichain, and Harmony hacks. The Ronin and Harmony hacks happened as a result of targeting the custodians in charge of validation on these bridges, while the other hacks happened as a result of exploiting vulnerabilities in the codebase of the bridges.
This is where zero-knowledge bridging protocols come into play. Zero-knowledge protocols offer a trustless, secure, permissionless, and decentralized blockchain bridging option. While there are other trustless, secure and permissionless non zk bridges in existence, the advantages zero-knowledge provides positions themselves to be the future of blockchain bridging.
The status quo of cross chain bridges hardly makes use of zero-knowledge proofs. Some of the most commonly used bridges include Binance Bridge, Multichain, and Portal Token Bridge. These bridges each offer unique advantages, but it is crucial to note that they have all been hacked over the past two years. To understand potential vulnerabilities in these bridges, we must first examine how these bridges function.
The core mechanism that supports the bridging functionality in all three of these bridges is nearly the same. The bridges lock a user’s tokens on the source chain and then mint the corresponding wrapped tokens on the destination chain. This results in the user having easily convertible pegged tokens on the destination chain, and the bridge keeping the user’s tokens on the source chain. Binance Bridge only supports bridging between Ethereum and the Binance Smart Chain, whereas Multichain and Portal Token Bridge offer bridging between a number of different blockchains such as Solana, Near, and Polygon.
Multichain also utilizes liquidity pools when the tokens a user is trying to bridge can’t use the traditional bridging approach. This is essentially a swap between what the user owns on the source chain and what another user, the liquidity provider, owns on the destination chain. Multichain incentivizes users to provide tokens on the destination chain by offering a share of the transfer fee, and then it will conduct the swap giving the original user tokens on the destination chain and the liquidity provider tokens on the source chain (Multichain) as a reward.
There are a variety of approaches when validating transactions on bridges, with the most popular one utilizing community based validation. This approach is faster and less expensive than other solutions, but a significant drawback is that anybody looking to use the bridge must trust the set of validators. Thus, these validators are an external trust assumption, and reliance on them makes assets on the bridge less secure than native assets, which could make the bridge susceptible to a single point of failure. The single point of failure vector, however, is not a significant concern for many popular bridges such as Multichain. This is because Multichain uses secure multiparty computation, or SMPC, which requires transactions to be independently signed by a number of nodes. SMPC does not allow for a transaction to be signed by only one node, and thus, the bridge is not susceptible to a single point of failure. And yet, regardless of these security architectures, the external trust assumption made by bridges is still a concern. On July 6th, 2023, $102 Million worth of assets were taken out of Mulitchain’s Fantom bridge. According to a Chainanalysis report, the exploit was conducted using the project administrator’s keys, meaning that either the keys had been compromised or this was a rug pull. To those ends, novel approaches for cross chain bridges are being developed to eliminate this trust assumption while still maintaining or improving upon the efficiency of community-based validation bridges.
Zero-knowledge bridging offers a trustless, decentralized, and secure alternative to these traditional bridging protocols. By using cryptographic schemes called zero-knowledge proofs, zero-knowledge bridges validate transactions without revealing the actual transaction details. This ensures that the transaction amount, sender, and recipient information remain confidential. By operating in a decentralized manner, zk bridges can reduce the risk of a single point of failure and enhance the overall security of cross-chain transactions.
In the upcoming sections, we will try to understand what zero-knowledge proofs are and how they can be applied to blockchain bridging. Then we will go into a deeper discussion on comparing zk and non-zk bridging systems to understand the considerations that go into the adoption of such systems.
A zero-knowledge proof is a way of proving the validity of a statement without revealing the statement itself. Operationally, one party (the prover) can prove to another party (the verifier) that something is true. These proofs utilize algorithms that take some data as an input and return ‘true’ or ‘false’ as an output. Zero-knowledge proofs must satisfy the criteria of completeness (if the input is valid, the zk proof always returns ‘true’), soundness (if the input is invalid, it is theoretically impossible for the protocol to return ‘true’), and zero-knowledge (the verifier learns nothing about a statement the prover doesn’t want known beyond its validity or falsity). The ability to verify without needing to gain access to sensitive information theoretically eliminates concerns that the verifier may use sensitive data maliciously or can be exploited to do so.
Here we will introduce ZK-SNARK and take an indepth look at two zero-knowledge protocols based on this system.
zk-SNARK stands for Zero-Knowledge Succinct Non-Interactive Argument of Knowledge. As suggested by the “zk” in its name, it is a class of cryptographic proof systems that enable one party (the prover) to prove to another party (the verifier) that a given statement is true without revealing any additional information about the statement. In order for the system to be considered a SNARK, it must fit three criteria:
Succinct: The proofs are small in size, meaning that they should be smaller in length than the original message. This ensures that the system is efficient and suitable for environments with less computational resources.
Non-Interactive: A proof is generated by the prover and verified by the verifier with only a single interaction between the two parties to pass the proof. This simplifies the work, improves efficiency, and minimizes the trust in the system.
Arguments of Knowledge: demonstrates the prover's knowledge of specific information related to the statement, and not just the statement's truth. It ensures that the prover cannot create a valid proof without knowing the required data.
zk-SNARKs are a great tool for situations where privacy is a key criteria. That is why almost all zk-Bridging systems are using them as the backbone of their architecture. zk-SNARKs do have their flaws though, as they require a trusted setup. zk-SNARKs rely on a Generator to create private keys for the proving and verification processes. If that generator was compromised, or if the randomly generated key used to create the private keys was leaked, someone could easily create fake proofs. The solution researchers came up with is what is called zk-STARKS (Zero-Knowledge Scalable Transparent Argument of Knowledge). Although this solution provides a trustless setup that drastically reduces security risks, the zk-STARKS are far less efficient than zk-SNARKS. Many teams, such as BerkeleyRDI, are working to create a trustless Bridging system that maintains the integrity that zk-SNARKs provide while also minimizing concerns with a trusted setup.
Developed by BerkeleyRDI, zkBridge is a trustless, permissionless, extensible, and efficient cross-chain bridge. zkBridge consists of an off-chain block header relay network and an on-chain updater contract. In the block header relay network, relayers retrieve the block headers from the sender chain C1, generate validity proofs, and send the headers along with the proofs to the updater contract which is set up on the receiver chain C2. The updater contract on C2 maintains a list of block headers and the light-client state of C1 and once a new block header is relayed and the associated proof is verified, the contract stores the header, changes the light-client state, and updates the current main chain of C1. The updater contract also exposes an API through which an application on C2 can obtain the block header of a given height on C1, with which the application can build application-level logic.
zkBridge uses a highly optimized zk-SNARK scheme for block header relay, which helps achieve cryptographic security assurance without any external trust assumptions. To make the underlying zk-SNARK system efficient for on-chain usage, both fast proof generation and low on-chain proof verification cost are required. zkBridge uses a 2-layer recursive proof system to satisfy both properties. In the first layer, deVirgo is presented, a distributed version of the Virgo proof system. It achieves this 2-layer recursive proof system by making both sumcheck and polynomial commitment phases distributed. The proof generation is accelerated by orders of magnitude for zkBridge workload. Furthermore, to reduce on-chain verification cost, zkBridge uses recursive proof in the second layer. The Groth16 is applied in the second layer to prove that the previously generated proof by deVirgo proves the validity of the corresponding block headers. This second layer significantly reduces the on-chain verification gas cost from about 80 million to less than 230K. Through the 2-layer recursive proof scheme, zkBridge achieves fast proof generation and low verification cost at the same time. In summary, zkBridge is different from other zero-knowledge proofs due to the fact that it only requires the existence of one honest node in the relay network and the assumption that the zkSNARK is sound.
In June of 2023, LayerZero and Polyhedra Network teamed up to bring the power ZK to LayerZero’s existing bridging protocol. LayerZero is an omnichain interoperability protocol that enables cross-chain messaging over 30+ chains.
Polyhedra Network, a leader in zero-knowledge proof technology, has developed zkLightClient technology built on LayerZero, enabling secure cross-chain infrastructure for Layer-1 and Layer-2 interoperability. This technology integrates seamlessly with LayerZero's messaging protocol, enabling developers to utilize ZKP technology without hindrance. Together, LayerZero and Polyhedra Network work to provide a robust solution for cross-chain interoperability by combining LayerZero's messaging capabilities with Polyhedra's efficient ZKP protocols to reduce on-chain verification costs and latency, allowing multiple transaction verifications to be batched into a single zero-knowledge proof. Their collaboration aims to unleash the full potential of zero-knowledge proof technology for a secure, efficient, and cost-effective decentralized ecosystem for interoperability in the blockchain and Web3 industry.
This system is built on the foundation of LayerZero’s Oracle and Relayer to transfer messages between on-chain endpoints. Internally, LayerZero’s Oracle moves a requested block header from a source chain to a destination chain. This happens by Oracle forwarding the packet hash to the endpoint on chain B and the Relayer submitting that packet to be verified on-chain against the hash. After it is verified on-chain, the Relayer then delivers the message. On the user side, a user application contract built on LayerZero will come preconfigured with defaults for both Oracle and Relayer.
The power of on-chain verification is that each step of the chain can communicate through their validator set. However, Polyhedra cites that previously “on-chain transaction verification has been cost-prohibitive to the tune of $50m-$100m/day per pair-wise chain connected to Ethereum due to the presence of extensive transaction logs, which are necessary for the proof but not for the application itself.” Polyhedra’s zkLightClient integration in LayerZero addresses these issues by reducing the cost of on-chain verification using efficient zero-knowledge proofs that don’t require these logs.
In this section, we will further discuss specific limitations of implementations of zk technology. As is the case with most bridging implementations, it is important to understand trade-offs made when utilizing zero-knowledge.
As mentioned previously, zk-SNARKS require a trusted setup, also known as ceremony. During this process, a trusted party generates a common reference string (CRS). Once the CRS is created, the information used to create the CRS must be destroyed. Otherwise, malicious parties can use the information to generate fraudulent proofs. Additionally, many constructions such as Groth16 are specific to a given program. New programs require completely new parameters and setups.
With this security flaw in mind, there are multiple strategies to securely generate the common reference string. The most common of these methods is known as multi-party computation, in which interactive protocols involving multiple parties contribute an element of randomness to iteratively construct the CRS. In these scenarios, each of the parties needs to keep their inputs to the string hidden and deleted immediately. Otherwise, this system creates the “toxic waste” problem present with zk-SNARKS. The first family of multi-party computation schemes is known as the BCGTV scheme and was used to generate the CRS for the first version of ZCash. ZCash, a cryptocurrency that uses zk-SNARKS for security, was successful in its process of the ceremony as it emphasized the independence of the contributors to the CRS in order to prevent malicious collusion.
An improvement on this protocol is known as MMORPG, which allows for the setup to not have to choose contributors in advance, so participants don’t have to be online at all times. However, with this process, the creation of the CRS was still serialized, meaning that only one participant could contribute at a time. The most advanced proposals for the trusted setup aim to eliminate this issue. In order to parallelize the process, the creation of the CRS is split into smaller segments known as rounds and works on the creation of different parts of the string simultaneously. This optimistic approach reduces end-to-end computation time for multi-party computation.
Choosing the method for ceremony is critical for ensuring the security of a zk system when using zk-SNARKS, which is currently the most optimal solution for most zk products.
While the advancements made in advancing security for zk-SNARKs have been essential in improving their viability, there are inherent risks associated with using zk-SNARKs that are unavoidable. In comparison to zk-SNARKs, zk-STARKs offer increased security by not requiring the process of a trusted setup. As the proofs generated by STARKs use publicly available randomness and don’t rely on external parameters, they avoid the “toxic waste” problem associated with zk-SNARKs. Additionally, in comparison to SNARKs, STARKs allow for increased scalability by enabling developers to take storage and computation off-chain and post relevant information on-chain. Along with this increase in scalability, STARKs rely on hash functions that are considered to be quantum resistant, which could become more important in the future.
The significant downside currently with STARKs, however, is that they present a massive tradeoff in efficiency compared to SNARKs due to the increased proof size. SNARKs can often be verified in a matter of milliseconds, while STARKs can take seconds or even minutes to verify. This exchange makes STARKs more gas intensive than their counterparts.
Over the past few years, a great deal of research has been done into the creation of recursive proof composition. Recursive proof composition is the process of splitting proofs into smaller subproofs and merging them until a final proof is created. With the Halo Protocol, which was implemented into Zcash as of October 2021, the merging techniques of the proofs were cheap, which allowed for increased efficiency. Additionally, with this protocol, proofs were able to be incrementally verified, which allows for the use of an existing proof that is mixed with a proof of the new statement and combined into a new statement. The ability to incrementally verify proofs decreases the verification time of the proofs from linear to a point where they take place in what resembles constant time.
The most efficient of these new protocols is PLONK, which is the basis of Halo 2. Plonk uses optimized hardware in order to reduce the gate count for multiplication required in proof verification. Optimizations such as these in the development of zk-SNARKs and zk-STARKs are increasing their flexibility, security, and efficiency for the future.
While traditional bridging has become the driving force of the transaction volume between chains, the current infrastructure often has the tradeoff of being highly susceptible to hacks or requiring an exhaustive management level. Irrespective of either of these downsides, all forms of traditional bridging need more privacy and security to give consumers peace of mind.
Zk rollups, built off of zk-SNARKS or zk-STARKS, drastically improve on the flaws of traditional bridging. While not a perfect solution, zk-SNARKS have become a computationally comparable alternative to other bridges, reducing security risk to ceremony. Additionally, advances in the techniques used in the trusted setup have further reduced the risk of false proof generation.
In the long term, the increasing viability of zk-STARKS and other completely trustless solutions can decentralize the space completely. This guarantee that all transactions have no third-party involvement can render current bridging technology obsolete, given the assumption that efficiency can be improved.
The status quo of cross-chain bridging is certainly in need of improvement. Even the most widely used bridges are not built robustly enough to prevent exploitation, meaning that the underlying mechanisms used currently for bridging are not suitable for this task. Improvements to bridging must come in the form of dramatic changes to how they work, not simple optimizations and patches to a flawed technology that has shown over and over again that it is not secure enough.
The use of zero-knowledge in cross chain bridges provides a more robust foundation for bridges to be built upon in the future. Despite this, it is important to mention that zero-knowledge solutions are not perfect and still pose security risks. This is especially true when discussing zk-SNARKS as opposed to zk-STARKS since zk-SNARKS requires an extremely secure ceremony. A compromise of the information created during this ceremony could result in exploitations that very easily surpass the other cross-chain bridge hacks in scale. zk-STARKS do not possess this security concern, but they are currently much too inefficient to be widely implemented.
With the current zero-knowledge technology, we believe that a bridge built with zk-SNARKS would be more secure than traditional cross-chain bridges, while also being reasonably economical and computable. Improvements to the security and efficiency of zk-SNARKS could be crucial to how quickly the technology is adopted for bridging, but we do not believe that further improvements need to be made for a zk-SNARK based bridge to outperform the most widely used bridges of today. The use of zk-STARKs for bridging with current optimizations is idealistic. Although zk-STARK setups have no notable security concerns that we could uncover, such implementations are much too computationally intensive for mass adoption. We can not rule out zk-STARKS for bridging entirely, however. If future innovations can make zk-STARK systems more efficient, it may be preferable to use zk-SNARK based bridging as opposed to a less robust zk-SNARK bridge.
To conclude, zero-knowledge technology promises a new future for bridging by providing trustless, secure, permissionless, and decentralized bridging options. As zk bridging protocols continue to evolve and improve, zk setups could cement themselves as the basis behind the future of blockchain bridging.