Gargantua v2

Do not index

Today we take a step closer towards cryptographically secure interoperability. We’re unveiling Gargantua v2 our mainnet release candidate for Hyperbridge. Gargantua v2 brings support for zk proofs of consensus, permissionless relayers, support for the Binance smart chain network and more.

We’ve been heads down working on the making Hyperbridge mainnet-ready since our first alpha release in November last year. Let’s explore some of the new things in hyperbridge.

zkBEEFY

Hyperbridge is uniquely empowered by the BEEFY consensus protocol. This proof mechanism brings succinct ancestry proofs, Ethereum-friendly ECDSA signatures, and hashing for Polkadot. This would suggest that we can verify Polkadot's consensus proofs on any chain at a low cost. However, that's not entirely accurate. While it is less costly than attempting to perform ed25519 signature verification for all of Polkadot's validators on Ethereum—which would exceed 20 million gas—it's still not as inexpensive enough to frequently update the state of Polkadot, and consequently, the state of Hyperbridge.

The is because, the cost of consensus proof verification scales linearly with the number of signatures that need to be verified. For instance, Kusama has 1,000 active validators. Any consensus proof from Kusama requires a super-majority set to sign the most recent finalized block header, resulting in over 667 signatures. The ecrecover precompile, used for secp256k1 signature verification on EVM chains, costs 3000 gas per call. This implies that signature verification alone for the Kusama chain would exceed 2 million gas. This calculation does not include the calldata costs associated with these signatures or the merkle proof checks to assert that the signers are in the current set. In total, this amounts to roughly 5 million gas. Our naive BEEFY verifier, used in Gargantua v1 for the Rococo testnet with just under 120 validators, costs over 1.3 million gas.

To significantly reduce the costs of BEEFY consensus proof verification, we realised that we must turn to SNARK proof schemes. Where we can perform the costly signature verification within a SNARK, and provide cryptographic proofs that can be inexpensively verified on any chain. This SNARK verification would be cheap enough that we can post it’s proofs as frequently as possible resulting in faster messaging finality for all the applications that rely on hyperbridge.

We conducted a survey of all existing SNARK frameworks to identify the one with the fastest proving time for the Secp256k1 signature verification scheme. Our survey included:

Halo2

Circom

Barretenberg

Of all of them, the Barretenberg framework by the Aztec team stood out. With a proving time of just under 2s for a single secp256k1 signature. We quickly got to work and implemented our BEEFY light client using the noir frontend for Barretenberg. Proving the verification of the over 199 ECDSA signatures (for Polkadot super-majority) and it’s associated merkle proofs on our local prover takes around 15minutes. The specifications of our prover is as follows:

AMD Ryzen Threadripper PRO 5995WX 64-core

512GB Kit 4x128GB DDR4-3200MHZ PC4-25600 8Rx4 ECC Load Reduced Memory by Nemix Ram

Dual NVIDIA GeForce RTX 4090 Founders Edition Graphics Card 24GB GDDR6X with NVLINK

We believe that the current proving time can be further reduced by integrating supranational’s sppark libraries into Barretenberg. This allows for accelerated computation of FFTs and MSMs using CUDA on GPUs. We'll provide updates regarding this in the future.

The new zk consensus proof costs around 800k gas to verify on any EVM chain. You can see an example of the consensus proof being verified on sepolia here.

Unlike our initial BEEFY verifier for Gargantua v1, which has costs that scale with the number of validators in the consensus proof, our new zk consensus proof has constant verifier costs, regardless of the number of signatures.

The final step would be to integrate with NEBRA's universal proof aggregation service, which will reduce the cost of consensus proof verification to less than a penny. This will allow us to publish proofs even more frequently, potentially every 5 minutes, providing the fastest finality times for secure cross-chain messaging.

Incentivised Relayers

Gargantua v2 introduces support for a completely decentralized and permissionless pool of relayers. These relayers are ready to cover the costs of delivery and execution of cross-chain messages on the destination chain on behalf of users. They are completely permissionless and can earn fees for cross-chain messaging without needing to be staked or whitelisted. This is made possible by Hyperbridge's fully secure and permissionless design.

Users making cross-chain “requests” will now be required to lock up some funds in the DAI stablecoin to offer as fees for relayers delivering messages. Relayers will choose to deliver these requests based on their profitability settings. If the fees are too low, for example, due to a spike in transaction fees, relayers will ignore the request, allowing it to time out. Once a request has been timed out, users can withdraw any funds they had previously offered to relayers. Learn more about our relayer incentivization protocol here.

We believe that the future of blockchains, and by extension bridges, will be decentralized. A fully permissionless set of relayers will establish Hyperbridge as the first truly unstoppable cross-chain interoperability protocol. Become a relayer today.

Gateway

We're introducing Gateway, our cross-chain asset transfer protocol secured by Hyperbridge. Gateway enables the transfer of assets across any chains connected to Hyperbridge. Its design is a hybrid of mint-and-burn and token swaps. The mint and burn mechanism is facilitated by the ERC6160 interface we proposed last year. This approach enables access-controlled minting and burning of native tokens, offering a more capital-efficient solution to token bridging without requiring the locking up of scarce liquidity for bridges.

Gateway enables the permissionless transfer of native ERC20 assets through token swaps, facilitated by Hyperbridge relayers. If a user wants to send a native asset like WETH, this asset can't be burnt by Gateway or minted on the destination chain. Instead, the user will lock this asset on the source chain. Hyperbridge relayers, who have previously approved the Gateway contract as a spender, act as liquidity providers and give the user the native asset on the destination chain, minus some fees. The Gateway protocol then allows the relayer to immediately claim this locked asset on the source chain.

This design offers several benefits. Firstly, it avoids locking up liquidity in centralized pools, which would be a honeypot for attackers. Secondly, relayers hold their assets in their own accounts and can freely decide when they wish to stop providing liquidity. Lastly, this design allows Gateway to automatically rebalance liquidity across all its connected chains, eliminating the need for intervention by a centralised authority.

Gateway also includes an escape hatch feature. If relayers can't deliver a user's request to the destination chain due to insufficient transaction fees or unavailable liquidity, Gateway allows users to recover their bridged funds through this escape hatch mechanism. This feature is a unique benefit of Hyperbridge's fully trustless design.

Please try it out on testnet here: gateway.hyperbridge.network. You’ll need to have some Sepolia ETH or tBNB.

Binance Smart Chain

We’ve added support for the Binance Smart Chain with the recent introduction of it’s fast-finality mechanism, Plato. The Plato upgrade means that the Binance smart chain is finalizing every block and as a result, users on the binance smart chain can enjoy fast bridging to any network. Since these consensus proofs can be immediately made available to Hyperbridge. Read more about Binance Smart Chain fast finality here.

OP Stack Stage 1

We’ve introduced support for the OP Stack stage 1 fault proof mechanism. This mechanism was introduced to their Optimism Sepolia testnet on March 19th. We quickly reviewed their code and implemented support for the new dispute games mechanism. Learn more about optimism’s Stage 1 design here.

Polygon Pos

We previously developed what we believed to be a fully Byzantine light client for the Polygon PoS, intending to bring support for the Polygon PoS network to Hyperbridge. However, we found that Polygon’s PoS documentation is somewhat inconsistent with its actual network behavior. During our experiments, we observed numerous reorgs and authority set handovers that weren't confirmed by the previous set. These are just a few of the issues that make it risky to support Polygon PoS in its current state.

It’s worth noting that Polygon POS is still using a modified version of clique consensus, a protocol that was designed by Ethereum core devs for the Ethereum testnet as a way to avoid using it’s Proof of work algorithm Ethash on testnets. In order to support the Polygon network, they would have to switch to using a deterministic fork choice rule that would place an upper bound on the number of blocks that confirms transaction finality, rather than a probabilistic fork choice rule that can re-org at any time.

Summary

These are some of the major updates we've made to Hyperbridge since its initial launch last year. We want to inform our community that our Polkadot Crowdloan is now live. This will enable us secure a two-year slot for the Hyperbridge parachain on the Polkadot mainnet before its transition to agile core-time. You can learn more about our crowdloan here. Contribute to the crowdloan on the official page: hyperbridge.network/crowdloan