# A framework for understanding cross-chain systems - 0xpostman - Medium

By [postman](https://paragraph.com/@postman) · 2022-04-22

---

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.

![](https://storage.googleapis.com/papyrus_images/e51e42005ca6c6b8d5caff7e29a8b0b3a0f851fcf320d4013debf0476be7d5e0.jpg)

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](https://axelar.network/blockchain-infrastructure-is-falling-behind) 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 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_

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

**Transport** **layer**
-----------------------

Logic that defines connectivity paths, routing and delivery rules. e.g. _Relayer logic_

**Interface layer**
-------------------

Message format standard. e.g. _smart contract interfaces that define the shape of message data_

![](https://storage.googleapis.com/papyrus_images/29e766ea0e1efb4fd5ac19f1d8ca4c754af553b2f7601c2eb68fdcf879670ff6.jpg)

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.

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.

Consensus overlap
-----------------

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.

![](https://storage.googleapis.com/papyrus_images/362804b99ac3abdcb4a821b52e69cbfa7f2d25c83c4938284c6390271fb92e3a.jpg)

![](https://storage.googleapis.com/papyrus_images/87c700dfcade75e6c0880e69c33d7ba0f424190860cf87e01677126e2c875755.jpg)

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

![](https://storage.googleapis.com/papyrus_images/e43671018d6a503e349215a1bda82ca4a6470add4a203ca9c9c11c7c63608013.jpg)

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.

---

*Originally published on [postman](https://paragraph.com/@postman/a-framework-for-understanding-cross-chain-systems-0xpostman-medium)*