Cross chain security part 1— A framework for understanding cross-chain systems
The world of blockchain interoperability moves fast. In just a few short months, we’ve gone past conversations about pairwise bridges and into conversations about cross chain interoperability networks.
As this complexity hits us full force, we’re missing a useful framework for evaluating the architectures of cross chain interoperability networks. I think we have the beginnings of it in a post published last week by Sergey of Axelar Network. I will be expanding on it with my own musings, ready to apply it to some cross-chain projects in Part 2 and assess their security along the way.
Breaking cross-chain protocols into layers
Sergey has proposed breaking cross-chain systems into stack components. This allows us to better understand the services they provide and evaluate the security of those services:
Base layer
Infrastructure installed on source and destination chains for cross-chain read/write. This maintains state, and accesses it for cross-chain messages. E.g., gateway smart contracts, light clients, home and replica, IBC module, Bitcoin accounts.
Auth layer
Protocol-level logic that utilises the security of the base layer to verify messages from other consensus environments. e.g. Light client verification, block header & tx proof verification, multi-party crypto, merkle root proofs.
Transport layer
Logic that defines message routes and delivery rules through blockchain modules and between blockchains. e.g. Relaying logic.
Interface layer
Message format standard. e.g. Smart contract or protocol-level interfaces that define the shape of message data.
Cross-chain security principles
In order to apply this framework to a discussion of cross-chain security, I’ve developed a few cross-chain security principles/metaphors that relate universally to various cross-chain architectures.
Cross-chain read/write
I use read/write in cross-chain to mean reading or writing State AND Security from/to another chain. “Write” in this case really means you’re giving a destination chain the ability to securely read your own state. That is, be able to verify state came from you.
Cross-chain security protocol designs differ mostly at the intersection of the Auth layer and the Base layer in how they allow the system to perform read/write actions.
Consensus overlap
In order to share state between two consensus environments and preserve security, there needs to be an overlap of the consensus of the two networks, like a multidimensional Venn diagram. This comes in the form of many-to-many validator sets, optimistic protocols, light clients, multi-party crypto, etc.
The destination chain* needs a way to check that a submitted message has in fact been verified by the source chain’s consensus, otherwise we regress to web2 trust. It’s like consensus-level man-in-the middle attack.
Think of it like two towns communicating. You can’t trust a messenger on horseback to tell you a murder happened in the town square of their town, and you can’t trust one of you civilians either. The people of both towns need to inhabit the same square and be constantly gossiping between themselves.
* “chain” in this case could be a zk or an optimistic approach to consensus, or a bank’s database.
Note cross-chain communication is always between two trust environments. IBC is the best generic model for two unrelated chains to trustlessly act as a reader to the other without an intermediary. If the destination or source can’t read or write, we need to introduce a third decentralised protocol which can both read A and write to C. This involves two “cross-chain” steps A:B:C
For each step, the destination must have a proxy of the source chain’s consensus protocol available to its own nodes in order to communicate security and trust. Cryptography is not enough in most cases; we need an any-to-any relationship between the nodes of various distributed systems.
Once the state and security of these consensus zones are made available to each other, safe communication is possible, using public-private-key cryptography.
One quirk of cross-chain security
Obscured economic risk
A key difference in cross-chain security compared to single-chains is the difference in economic security assumptions.
It’s hard to accurately measure the maximum extractable value from hacking a cross-chain protocol. One would need to model all the possible combinations of smart contract calls on the destination chain that the rogue cross-chain protocol would have authority to carry out.
There is also concern about the economic security of cross-chain protocols keeping up with the value they are securing on the multiple chains they connect. For Layer Zero and Nomad, I’m not sure how they will scale, but for Axelar and Gravity Bridge, I’m excited about Interchain Security, which would allow the cross-chain protocol to leverage the economic security of multiple chains at once, including the chains that they are connecting.
Impossibility of social roll-backs
Unless you get agreement from all the chains involved in an attack to roll back together, it’s unlikely you can fall back to social policing to secure a network which was subject to a cross-chain hack. Ethereum isn’t going to roll-back its chain just because some silly people on Wormhole lost some ETH!
This prospect has lead to some of the double up designs, like Nomad and Layer Zero, where you effectively layer two networks on top of each other, and if one node network gets hacked, the other can block a hacker from getting anything through. This has some game theoretical and practical flaws, but it is an area of ongoing research and could be a useful mechanism.
In Part 2 we will be applying all these principles to IBC, Nomad, LayerZero and Axelar Network.
