We’re excited to share the culmination of our research & development into the blockchain interoperability problem. We introduce Hyperbridge an interoperability coprocessor capable of scaling cryptographically secure, consensus & state proof-based interoperability to all blockchains.

Secure cross-chain communication requires the verification of consensus, consensus faults, state proofs, and state transitions. However, these verification processes are typically too expensive to be performed onchain. This limitation leads to the proliferation of attestation networks using multi-sig committees who attest to the state of the counter party chain. These types of architectures have resulted in a cumulative loss of $2 billion in crypto assets. (sources [1], [2]). We believe It’s time to for cross-chain bridges with more rigorous security assumptions to take the stage and usher in the next wave of secure cross-chain applications.

Since verification is too expensive to be performed onchain, this necessitates the coprocessor model. Where the computation is performed off-chain and the results of the execution are presented onchain alongside cryptographic proofs of its correct execution. A popular example of a coprocessor is a SNARK circuit. In this model, a “prover” commits using a Polynomial Commitment scheme to the so-called execution trace of the computation in question, and attempts to convince a “verifier” through a Polynomial Interactive Oracle Proof combined with a Fiat-Shamir heuristic that the execution trace indeed describes a valid computation.

This has both upsides and downsides. First, the proof for this computation can be very small, in fact, of constant size when using the KZG commitment scheme. Unfortunately, proving the execution trace places immense memory (RAM) requirements on the prover, as they have to work with very large execution traces that describe the computation in question. Another downside is that these circuits would have millions of "constraints" and would be very difficult to securely audit and guarantee the absence of bugs.

Take for example the Casper FFG consensus proof, which requires the prover to prove the correct BLS signature verification of over a million validators, every 15 minutes. It’s clear that this would be too computationally expensive for proof generation within the 15-minute window. Furthermore, consensus proof verification alone may not always be sufficient. It is only applicable when we seek to verify the validity of enshrined state machines. For instance, Parachains are enshrined on the Polkadot relay chain, the Ethereum execution layer is enshrined on the Beacon chain, and zk rollups are indirectly enshrined on their settlement layer. In these cases, the validity of state transitions is a predicate for consensus. Therefore**, c**onsensus proofs alone are a sufficient argument for the validity of the state transitions of an enshrined state machine. This lemma is the foundation of “light” client security assumptions.

Consensus proofs alone are a sufficient argument for the validity of the state transitions of an enshrined state machine.

Whereas in the case of optimistic state machines otherwise known as optimistic rollups, the consensus proof cannot be used as an argument for the validity of their transitions. It can only serve as a proof for the inputs (transactions) to their state transitions (so-called “Data Availability”). This limitation introduces the need for a challenge window where state transitions are optimistically confirmed. Hence, any chain that wanted faster finality to these kinds of state machines would indeed need to either verify the state transitions themselves or wait for the (7-day) challenge period. To verify the state transition of an optimistic rollup, the coprocessor needs to re-execute the state transition using a "state witness". This witness contains all the storage items and merkle proofs for the items accessed by the transactions in the block. Additionally, it requires the transactions in the block themselves. This allows the coprocessor to re-execute the block and derive the correct "post-state root". I discuss this topic in a more in-depth research post here: State (Machine) Proofs.

In a SNARK coprocessor model, the state transition function for the optimistic rollups would also need to be embedded into a circuit. This is necessary to provide proofs of the correctness of their transitions, in addition to consensus proofs. However, this addition further increases the already substantial prover costs. These consensus & state transition proofs must also be updated frequently for it to be usable by applications & users who want to perform cross-chain actions, whether messaging or state reads.

Finally, there exists the problem of proof aggregation. Operating n-onchain verifiers for n-coprocessors doesn’t scale. Seeing as we have to frequently update the view of the networks of these n-verifiers to enable near-instant cross-chain message passing. What would be somewhat ideal, would be to somehow aggregate these n proofs into a single proof. This way the number of chains the coprocessor supports can grow indefinitely while the verifier stays constant. In the case of a zk coprocessor, this introduces the need for recursive proof verification, a major performance overhead in existing proving systems.

Clearly, it is evident that relying solely on a SNARK coprocessor is insufficient for achieving highly scalable and cryptographically secure interoperability. Even if, by some miracle, their security could be guaranteed, they would still heavily depend on VC funding to subsidise the exorbitant cloud computing costs associated with the prover. However, we expect that this situation will change within the next 5-10 years, thanks to improved circuit auditing tools and specialised hardware designed for accelerated computing of FFTs & MSMs (as discussed in this blog post), which are critical bottlenecks in SNARK proof generation.

Based on my previous lemma, we can consider a consensus proof as a proof of work done. In this manner we can assert that, enshrined state machines perform computations that can be verified through consensus proofs. With this in mind, rather than relying solely on a zk coprocessor, we can leverage another blockchain as a coprocessor.

However, we quickly encounter a critical vulnerability: crypto-economic security. How much is at stake for each consensus proof? If this coprocessor were to bootstrap its own validator set using POS consensus, it would be vulnerable to governance attacks in its early days. This is because the network token stake would not hold much value, resulting in very low crypto-economic security. This would allow Byzantine actors to gain control of the network quickly and sign blocks that do not contain valid work. Effectively compromising applications that rely on this coprocessor. In order to achieve secure interoperability via a blockchain coprocessor, this blockchain must provide high crypto-economic security guarantees. In other words, there must be a significant amount of capital at stake to discourage Byzantine attacks.

This coprocessor must also be highly scalable and must not bottleneck message passing across it’s connected chains. You can see how a single state machine can quickly become bottlenecked if it is to verify consensus proofs, state proofs & (re-execute) state transitions of it’s multiple connected state machines. This necessitates that the coprocessor must be multi-threaded. That is, it is able to shard the work of performing all the necessary verifications across multiple state machines. These state machines must also be enshrined, such that a single consensus proof can be used as an argument for the validity of the work done across them.

Finally, this blockchain coprocessor must have the cheapest consensus and state proofs. Since it’s job is to verify expensive consensus proofs, it is the case that all of that offloaded work is pointless if the coprocessor itself also has very expensive consensus proofs. Cheap consensus proofs can be achieved using BLS signatures and the APK proofs scheme as proposed by web3 foundation researchers. Combining these two schemes results in two pairing checks for consensus proof verification. State proof verification must also be very cheap, the cheapest known state trie scheme remains verkle tries using KZG commitments which allows for amortising the verification cost of multiple items in a state proof using a constant-sized proof & a single pairing check.

Hyperbridge (short for hyper-scalable bridge) is an interoperability coprocessor that has been designed with all of the considerations given above. By leveraging Polkadot as a consensus layer, we obtain high crypto-economic security, equivalent to about $2.75 billion at the time of writing. This ensures that hyperbridge is resistant to governance attacks that would’ve otherwise successfully compromised the protocol if it had to bootstrap its own validator set.

Additionally, we benefit cheap consensus proofs through BEEFY, which attests to the validity of all parachain state transitions secured by the network. Because of this, we can shard the work of validating consensus, state proof and state transition re-execution across multiple so-called parachain cores. This allows us to aggregate the cross-chain messages from multiple connected blockchains which are verified on multiple parachain cores into a single zk consensus & state proof that can be verified cheaply on any chain.

This cost will be cheap enough to compete with non-consensus proof based bridges which simply verify MPC signatures onchain for attestation. It is critical to note that the reason this kind of interoperability coprocessor hasn’t been attempted before is because it is an architecture that is uniquely enabled by Polkadot. All of this culminates in what is undoubtedly the holy grail of interoperability: a single proof that aggregates multiple sub-proofs to facilitate the most secure and scalable cross-chain message passing.

With the ability to re-execute blocks of its connected chains, Hyperbridge achieves the elusive full node security in cross-chain bridges. This is accomplished by compressing the state witness, transaction data, and contract code, which can then be uncompressed and re-executed within a parachain core. This is how smart-contract parachains currently function on the Polkadot relay chain. Parachains like Moonbeam provide the state witness, transaction data, and contract code to the relay chain as a bundle known as the Proof of Validity (POV) to be re-executed. The current maximum size for this POV is 5mb per parachain block. This size is six times larger than what proto-danksharding allows (0.75mb per beacon block), guaranteeing that L2 blocks will always fit within our parachain blocks.

Additionally, consensus fault proofs can be posted to hyperbridge, allowing it to detect byzantine behaviour and prevent applications from being compromised on any of the connected chains. These consensus fault proofs are typically two distinct consensus proofs that describe conflicting views of the network. This allows hyperbridge to be fully byzantine fault tolerant, another first for a cross-chain bridge.

A single Polkadot consensus proof attests to the validity of all its state machines. This feature enables sharding consensus and state transition verification across multiple parachain cores, also known as parachain slots. As a result, Hyperbridge can scale easily with the number of connected blockchains. We envision Hyperbridge becoming the central hub for the multi-chain future, enabling disparate chains to pass messages to each other secured by their full consensus & safety protocols.

Hyperbridge is built on top of our in-house cross-chain messaging framework, ISMP. ISMP has been designed to be modular and extensible, enabling us to quickly incorporate support for additional consensus systems and state machines with minimal new code.

ISMP provides a familiar HTTP-like API for developers who want to make cross-chain requests to trigger certain logic on the counterparty chain. It allows making POST requests to send arbitrary data to connected chains, as well as GET requests to read the storage (verified through state proofs) of applications on connected chains.

In addition to facilitating cross-chain message passing among connected chains, ISMP also serves as a synchronisation primitive across Hyperbridge's internal state machines. This enables its parachain cores to communicate with each other and delegate tasks. Hyperbridge will be the first multi-core parachain on Polkadot.

Hyperbridge can facilitate faster withdrawals from optimistic L2s by confirming the validity of optimistic L2 blocks. The fraud proof window exists because L1 does not check L2 blocks, thus necessitating a third party, either in the form of a fraud or a validity prover. Hyperbridge serves as this validity prover, short-circuiting the fraud proof window and enabling near instant withdrawals and communication amongst optimistic L2s.

From the ability to re-execute L2 blocks also comes the ability to execute view functions, functions that potentially read multiple parts of contract state. Hyperbridge can facilitate this by executing the contract’s view functions and POSTing the data to wherever it is needed acting as a verifiable oracle for cross-chain contract state.

Since Hyperbridge stores all verified blocks and headers indefinitely, it can also be used to access historical on-chain state, although in an asynchronous manner. This enables on-chain applications to request historical DEX pricing, check the age of accounts, and more.

Finally, Hyperbridge unlocks polkadot parachains as coprocessors for Ethereum. As an example, Polkadot currently has the most robust data availability protocol ever built.

With a bridge to Ethereum, we envision Parachain cores can also be used for the data availability of rollup transaction data on Ethereum or any chain. Beyond data availability, this also unlocks parachain coprocessors for identity, onchain DAO voting with the robust pallet-democracy that currently powers Polkadot’s open-gov, DeFi, Privacy, and other zk applications with a more developer friendly set of elliptic-curve precompiles.

We are proud to share that Hyperbridge v0 (codename: Gargantua) is live today on the Rococo testnet and is currently connected to Goerli, Optimism-Goerli, Arbitrum-Goerli & Base-Goerli. Eager developers who want to start playing with hyperbridge for cross-L2 instant & secure, cross-L2 message passing can do so today, visit the documentation to get started.

In addition, we have created a cross-chain message passing application to demonstrate the capabilities of Hyperbridge to end users. This application enables the transfer of arbitrary messages or assets that implement the ERC-6160 standard between our supported networks on Goerli. Both end users and developers can access the application here.

We are heads down working on bringing Hyperbridge to mainnet, but before doing so, we have a few upgrades to make. The current v0 release utilizes a merkle mountain range verifier for state proofs, which is cheaper than the base-16 merkle-patricia trie. However, it is not as efficient as a verkle trie. In the upcoming weeks, we will be finalising our development efforts to introduce the first verkle trie implementation to our testnet.

The final significant upgrade involves replacing the current sync-committee scheme with our SNARK-based scheme, zkCasper. This scheme directly verifies the more resource-intensive Casper FFG consensus protocol, which includes over 800k signers. We accomplish this by executing the Casper FFG consensus protocol on a dedicated parachain core. This effectively positions Hyperbridge as the most secure Ethereum bridge to date, benefiting from the full security of the beacon chain consensus. Stay tuned for more updates.

We’re excited to share the culmination of our research & development into the blockchain interoperability problem. We introduce Hyperbridge an interoperability coprocessor capable of scaling cryptographically secure, consensus & state proof-based interoperability to all blockchains.

Secure cross-chain communication requires the verification of consensus, consensus faults, state proofs, and state transitions. However, these verification processes are typically too expensive to be performed onchain. This limitation leads to the proliferation of attestation networks using multi-sig committees who attest to the state of the counter party chain. These types of architectures have resulted in a cumulative loss of $2 billion in crypto assets. (sources [1], [2]). We believe It’s time to for cross-chain bridges with more rigorous security assumptions to take the stage and usher in the next wave of secure cross-chain applications.

Since verification is too expensive to be performed onchain, this necessitates the coprocessor model. Where the computation is performed off-chain and the results of the execution are presented onchain alongside cryptographic proofs of its correct execution. A popular example of a coprocessor is a SNARK circuit. In this model, a “prover” commits using a Polynomial Commitment scheme to the so-called execution trace of the computation in question, and attempts to convince a “verifier” through a Polynomial Interactive Oracle Proof combined with a Fiat-Shamir heuristic that the execution trace indeed describes a valid computation.

This has both upsides and downsides. First, the proof for this computation can be very small, in fact, of constant size when using the KZG commitment scheme. Unfortunately, proving the execution trace places immense memory (RAM) requirements on the prover, as they have to work with very large execution traces that describe the computation in question. Another downside is that these circuits would have millions of "constraints" and would be very difficult to securely audit and guarantee the absence of bugs.

Take for example the Casper FFG consensus proof, which requires the prover to prove the correct BLS signature verification of over a million validators, every 15 minutes. It’s clear that this would be too computationally expensive for proof generation within the 15-minute window. Furthermore, consensus proof verification alone may not always be sufficient. It is only applicable when we seek to verify the validity of enshrined state machines. For instance, Parachains are enshrined on the Polkadot relay chain, the Ethereum execution layer is enshrined on the Beacon chain, and zk rollups are indirectly enshrined on their settlement layer. In these cases, the validity of state transitions is a predicate for consensus. Therefore**, c**onsensus proofs alone are a sufficient argument for the validity of the state transitions of an enshrined state machine. This lemma is the foundation of “light” client security assumptions.

Consensus proofs alone are a sufficient argument for the validity of the state transitions of an enshrined state machine.

Whereas in the case of optimistic state machines otherwise known as optimistic rollups, the consensus proof cannot be used as an argument for the validity of their transitions. It can only serve as a proof for the inputs (transactions) to their state transitions (so-called “Data Availability”). This limitation introduces the need for a challenge window where state transitions are optimistically confirmed. Hence, any chain that wanted faster finality to these kinds of state machines would indeed need to either verify the state transitions themselves or wait for the (7-day) challenge period. To verify the state transition of an optimistic rollup, the coprocessor needs to re-execute the state transition using a "state witness". This witness contains all the storage items and merkle proofs for the items accessed by the transactions in the block. Additionally, it requires the transactions in the block themselves. This allows the coprocessor to re-execute the block and derive the correct "post-state root". I discuss this topic in a more in-depth research post here: State (Machine) Proofs.

In a SNARK coprocessor model, the state transition function for the optimistic rollups would also need to be embedded into a circuit. This is necessary to provide proofs of the correctness of their transitions, in addition to consensus proofs. However, this addition further increases the already substantial prover costs. These consensus & state transition proofs must also be updated frequently for it to be usable by applications & users who want to perform cross-chain actions, whether messaging or state reads.

Finally, there exists the problem of proof aggregation. Operating n-onchain verifiers for n-coprocessors doesn’t scale. Seeing as we have to frequently update the view of the networks of these n-verifiers to enable near-instant cross-chain message passing. What would be somewhat ideal, would be to somehow aggregate these n proofs into a single proof. This way the number of chains the coprocessor supports can grow indefinitely while the verifier stays constant. In the case of a zk coprocessor, this introduces the need for recursive proof verification, a major performance overhead in existing proving systems.

Clearly, it is evident that relying solely on a SNARK coprocessor is insufficient for achieving highly scalable and cryptographically secure interoperability. Even if, by some miracle, their security could be guaranteed, they would still heavily depend on VC funding to subsidise the exorbitant cloud computing costs associated with the prover. However, we expect that this situation will change within the next 5-10 years, thanks to improved circuit auditing tools and specialised hardware designed for accelerated computing of FFTs & MSMs (as discussed in this blog post), which are critical bottlenecks in SNARK proof generation.

Based on my previous lemma, we can consider a consensus proof as a proof of work done. In this manner we can assert that, enshrined state machines perform computations that can be verified through consensus proofs. With this in mind, rather than relying solely on a zk coprocessor, we can leverage another blockchain as a coprocessor.

However, we quickly encounter a critical vulnerability: crypto-economic security. How much is at stake for each consensus proof? If this coprocessor were to bootstrap its own validator set using POS consensus, it would be vulnerable to governance attacks in its early days. This is because the network token stake would not hold much value, resulting in very low crypto-economic security. This would allow Byzantine actors to gain control of the network quickly and sign blocks that do not contain valid work. Effectively compromising applications that rely on this coprocessor. In order to achieve secure interoperability via a blockchain coprocessor, this blockchain must provide high crypto-economic security guarantees. In other words, there must be a significant amount of capital at stake to discourage Byzantine attacks.

This coprocessor must also be highly scalable and must not bottleneck message passing across it’s connected chains. You can see how a single state machine can quickly become bottlenecked if it is to verify consensus proofs, state proofs & (re-execute) state transitions of it’s multiple connected state machines. This necessitates that the coprocessor must be multi-threaded. That is, it is able to shard the work of performing all the necessary verifications across multiple state machines. These state machines must also be enshrined, such that a single consensus proof can be used as an argument for the validity of the work done across them.

Finally, this blockchain coprocessor must have the cheapest consensus and state proofs. Since it’s job is to verify expensive consensus proofs, it is the case that all of that offloaded work is pointless if the coprocessor itself also has very expensive consensus proofs. Cheap consensus proofs can be achieved using BLS signatures and the APK proofs scheme as proposed by web3 foundation researchers. Combining these two schemes results in two pairing checks for consensus proof verification. State proof verification must also be very cheap, the cheapest known state trie scheme remains verkle tries using KZG commitments which allows for amortising the verification cost of multiple items in a state proof using a constant-sized proof & a single pairing check.

Hyperbridge (short for hyper-scalable bridge) is an interoperability coprocessor that has been designed with all of the considerations given above. By leveraging Polkadot as a consensus layer, we obtain high crypto-economic security, equivalent to about $2.75 billion at the time of writing. This ensures that hyperbridge is resistant to governance attacks that would’ve otherwise successfully compromised the protocol if it had to bootstrap its own validator set.

Additionally, we benefit cheap consensus proofs through BEEFY, which attests to the validity of all parachain state transitions secured by the network. Because of this, we can shard the work of validating consensus, state proof and state transition re-execution across multiple so-called parachain cores. This allows us to aggregate the cross-chain messages from multiple connected blockchains which are verified on multiple parachain cores into a single zk consensus & state proof that can be verified cheaply on any chain.

This cost will be cheap enough to compete with non-consensus proof based bridges which simply verify MPC signatures onchain for attestation. It is critical to note that the reason this kind of interoperability coprocessor hasn’t been attempted before is because it is an architecture that is uniquely enabled by Polkadot. All of this culminates in what is undoubtedly the holy grail of interoperability: a single proof that aggregates multiple sub-proofs to facilitate the most secure and scalable cross-chain message passing.

With the ability to re-execute blocks of its connected chains, Hyperbridge achieves the elusive full node security in cross-chain bridges. This is accomplished by compressing the state witness, transaction data, and contract code, which can then be uncompressed and re-executed within a parachain core. This is how smart-contract parachains currently function on the Polkadot relay chain. Parachains like Moonbeam provide the state witness, transaction data, and contract code to the relay chain as a bundle known as the Proof of Validity (POV) to be re-executed. The current maximum size for this POV is 5mb per parachain block. This size is six times larger than what proto-danksharding allows (0.75mb per beacon block), guaranteeing that L2 blocks will always fit within our parachain blocks.

Additionally, consensus fault proofs can be posted to hyperbridge, allowing it to detect byzantine behaviour and prevent applications from being compromised on any of the connected chains. These consensus fault proofs are typically two distinct consensus proofs that describe conflicting views of the network. This allows hyperbridge to be fully byzantine fault tolerant, another first for a cross-chain bridge.

A single Polkadot consensus proof attests to the validity of all its state machines. This feature enables sharding consensus and state transition verification across multiple parachain cores, also known as parachain slots. As a result, Hyperbridge can scale easily with the number of connected blockchains. We envision Hyperbridge becoming the central hub for the multi-chain future, enabling disparate chains to pass messages to each other secured by their full consensus & safety protocols.

Hyperbridge is built on top of our in-house cross-chain messaging framework, ISMP. ISMP has been designed to be modular and extensible, enabling us to quickly incorporate support for additional consensus systems and state machines with minimal new code.

ISMP provides a familiar HTTP-like API for developers who want to make cross-chain requests to trigger certain logic on the counterparty chain. It allows making POST requests to send arbitrary data to connected chains, as well as GET requests to read the storage (verified through state proofs) of applications on connected chains.

In addition to facilitating cross-chain message passing among connected chains, ISMP also serves as a synchronisation primitive across Hyperbridge's internal state machines. This enables its parachain cores to communicate with each other and delegate tasks. Hyperbridge will be the first multi-core parachain on Polkadot.

Hyperbridge can facilitate faster withdrawals from optimistic L2s by confirming the validity of optimistic L2 blocks. The fraud proof window exists because L1 does not check L2 blocks, thus necessitating a third party, either in the form of a fraud or a validity prover. Hyperbridge serves as this validity prover, short-circuiting the fraud proof window and enabling near instant withdrawals and communication amongst optimistic L2s.

From the ability to re-execute L2 blocks also comes the ability to execute view functions, functions that potentially read multiple parts of contract state. Hyperbridge can facilitate this by executing the contract’s view functions and POSTing the data to wherever it is needed acting as a verifiable oracle for cross-chain contract state.

Since Hyperbridge stores all verified blocks and headers indefinitely, it can also be used to access historical on-chain state, although in an asynchronous manner. This enables on-chain applications to request historical DEX pricing, check the age of accounts, and more.

Finally, Hyperbridge unlocks polkadot parachains as coprocessors for Ethereum. As an example, Polkadot currently has the most robust data availability protocol ever built.

With a bridge to Ethereum, we envision Parachain cores can also be used for the data availability of rollup transaction data on Ethereum or any chain. Beyond data availability, this also unlocks parachain coprocessors for identity, onchain DAO voting with the robust pallet-democracy that currently powers Polkadot’s open-gov, DeFi, Privacy, and other zk applications with a more developer friendly set of elliptic-curve precompiles.

We are proud to share that Hyperbridge v0 (codename: Gargantua) is live today on the Rococo testnet and is currently connected to Goerli, Optimism-Goerli, Arbitrum-Goerli & Base-Goerli. Eager developers who want to start playing with hyperbridge for cross-L2 instant & secure, cross-L2 message passing can do so today, visit the documentation to get started.

In addition, we have created a cross-chain message passing application to demonstrate the capabilities of Hyperbridge to end users. This application enables the transfer of arbitrary messages or assets that implement the ERC-6160 standard between our supported networks on Goerli. Both end users and developers can access the application here.

We are heads down working on bringing Hyperbridge to mainnet, but before doing so, we have a few upgrades to make. The current v0 release utilizes a merkle mountain range verifier for state proofs, which is cheaper than the base-16 merkle-patricia trie. However, it is not as efficient as a verkle trie. In the upcoming weeks, we will be finalising our development efforts to introduce the first verkle trie implementation to our testnet.

The final significant upgrade involves replacing the current sync-committee scheme with our SNARK-based scheme, zkCasper. This scheme directly verifies the more resource-intensive Casper FFG consensus protocol, which includes over 800k signers. We accomplish this by executing the Casper FFG consensus protocol on a dedicated parachain core. This effectively positions Hyperbridge as the most secure Ethereum bridge to date, benefiting from the full security of the beacon chain consensus. Stay tuned for more updates.