This post is part #2 of my bridges journey where I take readers through asset security in a cross-chain world and how the tech behind these magical structures aka bridges work. Today we will go down the rabbit hole of
-
How to cook your own Bridge
-
Isn't ZK the solution to everything?
-
How to get your moni back(incase of bridge switch off)
How to cook a bridge from scratch
Well if you are not a chain maximalist spending all your attention and brain power about why some chain is the best, you must have at one point held different crypto assets and maybe even tried to move the same ones across chains just to f*ck around and find out. Well then you have 2 choices, go the old Centralised exchange way or try the risky and more fun path leading to cross-chain bridges but have you wondered how these
Hey there, my fellow degens! In today's enlightening session, we'll reveal the mind-blowing concoction of ingredients required to whip up a magical bridge that lets us juggle assets and even the wildest of data across the chaotic abyss of chains. Hold onto your socks, folks, because this is about to get as exciting as watching paint dry!
First, we need to which ingredients we need and why ->
-
Smart contract on Chain(1) -> We need a program that can accept proofs or inputs that we provide about the assets we want it to handle and check state changes from others.This could also be used as the burn/mint contract for assets.
-
Smart Contract on Chain(2) -> A program that works as the endpoint for assets and messages on the chain that we want the message/asset relayed from.
-
Relayer -> And Finally we need some third party that works as the proxy and communication layer between the two chains as every chain is an isolated virtual computer unable to take data unless it fits its model. At this point, we are able to divide bridges based on what kind of relayer of off chain third party they use.
And Voila! With just three simple Ingredients you have your own whole new bridge. Smart contracts to receive data on both sides and an agent/system that can relay data.
It's a bit akin to the art of telegraphy—setting up those essential hooks at both ends and linking them with a communication wire. All you need is a sender, a receiver, and a reliable means of transportation.
Relayer is the part where we differentiate between bridges present right now, every bridge has its own approach to transport the messages.
-
Trusted Threshold Network -> A bridge has its node network that works as guardian that verifies the cross-chain message requests and passes it on to sequencers/relayers that then turn it into a transaction interaction with its smart contracts on the other end.
Wormhole and DeBridge both use this approach where agents that are trusted by the creators are entrusted as node operators and will likely benefit from the network. Though there are plans to turn this into DAO governed bridges.
-
Light Client Bridges -> Replacing the guardian node network with a light client that only downloads the headers of the block and is able to verify state transitions by relying on the honest majority assumption makes it an LC bridge. The smart contract on the receiving end could have something like
`msg.sender` where only the Deployer Light client is able to verify the state transitions or the network of light clients could be rewarded on posting the fastest proof.
Doesn't ZK magic solve this?
ZK Bridges -> Using Light clients and an off-chain network that produces a Zero-knowledge proof of the state attestations to feed it to the receiver chain allows for a better security model at the cost of computational overhead. We can delve into more precise details by considering the option to generate a Zero-Knowledge (ZK) proof exclusively for the cross-chain messages directed at the bridge's smart contracts. Alternatively, we have the choice to create a ZK proof that encompasses the entire state transitions or even an entire block this to some sort can be tackled by using deVirgo.
But one of the biggest issues remains that ZK curve signatures are supported by the chains, Some chains support ed25519 and other BN254 so developers have to compute zk proofs over different curves in their bridge mechanisms which imposes the complexity of bigger zk circuits, and the required gas costs to verify the signatures/proofs on chains. Some Signatures like Groth16 that have a size of ~130 bytes can take 250k gas units to verify on mainnet while the ones like old zksnarks take 20M gas units which renders it impossible with the compute unit cap leaving the costs aside. One of the ways to solve this is to do recursive proving that allows you to shrink the proof size and you are able to verify even the history of the state.
One of my open questions was If we introduce more distributed proof generation like with DeVirgo to introduce a better level of decentralization in the bridge but how do we maintain a level of incentive alignment between the actors?
Currently, Gnosis Succinct Bridge and LayerZero are using Zk light clients with different architectures.
One of the most basic mechanisms used by bridge networks to send assets across chains is something called lock and release where you lock your tokens on one chain and release the tokens on the other chain to a desired wallet. Now this data transfer is the component of the bridge but the real assets lay in the escrows/smart contracts on the chains. This is where we have to be careful and choose our bridges wisely, Let differentiate between Custodian and ownership. When someone has full control over some arbitrary assets we say they have the ownership of that asset and Custodianship/escrowing means that the user still owns the asset but has passed the custody to interact and manage assets to a third party. From this a favorable feature we want our bridge to be an escrow bridge that can manage our assets but never has full control over them but become a custodian or guardian for our assets.
what if the bridge goes rogue?
As all bridges necessitate the involvement of trusted third parties to interface with diverse blockchains, there's an inherent need for alignment of incentives among these parties and the users, even when employing the mystical power of zero-knowledge proofs.Nonetheless, there remains a lurking possibility that these involved parties could misappropriate user funds and attempt to manipulate the network. This risk is notably challenging in threshold networks like Wormhole and Debridge, where a robust network of nodes is established. However, it's a different story for most L2 bridges, where only a handful of proving nodes exist. In such cases, users lack the capacity to submit fraud proofs to contest transactions that might harm them.
The onus falls entirely upon the teams operating these proof generators and sequencers. While Starknet is making strides towards decentralizing its sequencers and provers as outlined in its roadmap, many other zk and optimistic rollups, despite proclaiming "robust networks" in their grand roadmaps, are yet to make significant progress . A mechanism called Escape Hatches was introduced where users are able to exit their funds by forcing a state transition transaction of the L2 on L1 where the funds were locked, They usually are either able to submit a fraud proof or merkle tree root to exit. There are a few ways to exit with escape shuttles →
-
Force Exit L1: The user sends a transaction to the L1 that introduces a state change to the L2 bridge smart contract on the mainnet. These transactions can not be censored by the rollup sequencer and like in Arbitrum any of these txns are delayed by a day and then executed.
-
Enqueue L1: Users can post transactions to exit the assets but they are not guaranteed for execution.
-
Applicative : As zkrollups usually don’t have the same address it’s hard to map them beforehand, for this bridges have to maintain a directory of mapped addresses. In Starknet When a forced transaction is pushed, the L1 contract pings a cross chain message to the address directory on the Starknet.
You can head to L2Beat and check which of the L2 bridges have escape and hatches and how they are deployed but even right now unless you are good at solidity and calling functions on chain it will be super hard to use this functionality.
Some Open questions about shuttles
One of the biggest challenges is that Force exit transactions go through the same pipeline as any other transaction, and in times of high gas or market turbulence, it might not be viable for the user to exit $500 worth of funds by paying $1k to call the escape functions on chain.
Other than L2 bridges, many cross chain bridges don’t have any security fallbacks if the trusted committee is down. If while bridging the Trusted third party goes which is solely responsible for consensus and custody, the assets could be locked as long as the network is back up.
Which assets to exit? One of the functionalities I am curious about is whether a user is able to exit specific tokens or standards or whether the whole account state is moved. You might have a few AAVE positions on an L2 which due to sequencer failure is unable to process new transactions is there any way to move the AAVE balance and position directly to the mainnet? If the users just want to exit their ERC-20 or wrapped tokes and not the Native tokens that they bridged?
PS: Big shoutout to yet again making it till the end of my bridge rendezvous, This was a series of 2(till which I planned) on writing about bridge security.This work was funded by a Wormhole Grant so a huge shoutout to them for giving me the support to work on this! Next time till then. Resources: