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.

Designing cross chain apps was so much easier before

As this complexity hits us full force, we’re missing is 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.

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:

Infrastructure for consensus and cross-chain read/write. This maintains state, and accesses it for cross-chain messages. e.g. Validators, light clients, multi-party crypto ability

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, merkle root proofs.

Logic that defines connectivity paths, routing and delivery rules. e.g. Relayer logic

Message format standard. e.g. smart contract interfaces that define the shape of message data

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.

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.

Cross-chain security 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.

In order to share state between two consensus environments and preserve security, there needs to be a direct overlap of the consensus of the two networks, like a multidimensional Venn diagram. This comes in the form of light clients, optimistic protocols, 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, and be sure of no man in the middle attacks.

*chain 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 main model where two unrelated chains can trustlessly act as a reader to the other directly. If the destination or source can’t read or write, we need to introduce a third chain (or 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 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. This is the Auth Layer.

In Part 2 we will be applying these principles to four designs: IBC, Nomad, LayerZero and Axelar Network.

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.

Designing cross chain apps was so much easier before

As this complexity hits us full force, we’re missing is 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.

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:

Infrastructure for consensus and cross-chain read/write. This maintains state, and accesses it for cross-chain messages. e.g. Validators, light clients, multi-party crypto ability

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, merkle root proofs.

Logic that defines connectivity paths, routing and delivery rules. e.g. Relayer logic

Message format standard. e.g. smart contract interfaces that define the shape of message data

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.

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.

Cross-chain security 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.

In order to share state between two consensus environments and preserve security, there needs to be a direct overlap of the consensus of the two networks, like a multidimensional Venn diagram. This comes in the form of light clients, optimistic protocols, 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, and be sure of no man in the middle attacks.

*chain 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 main model where two unrelated chains can trustlessly act as a reader to the other directly. If the destination or source can’t read or write, we need to introduce a third chain (or 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 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. This is the Auth Layer.

In Part 2 we will be applying these principles to four designs: IBC, Nomad, LayerZero and Axelar Network.