Modular Expansion Needs Standardization: A Case for Unification
This is a guest post authored by Charleen Fei, Software Engineer on the IBC team at the Interchain Foundation.
I've been thinking a lot lately about historical cycles of unification and fragmentation. In the 900s, Harald Bluetooth, before lending his name to the wireless standard we all know today, united many warring tribes in Denmark, Norway, and Sweden only to be overthrown just years later by his son who subsequently fragmented the realm again between the victors of the rebellion. In modern-day Europe, unification has resulted in both positive and negative consequences for its individual Member States. It is increasingly being challenged by a multitude of euro-sceptic voices critical of European integration, calling for a greater focus on the sovereignty of individual nation-states.
In the blockchain space, we sometimes have a naive unwillingness to acknowledge that, despite all efforts to remove dependency on human judgment calls from the designs, our blockchains are only the latest iteration of systems dictated by human dynamics. Codified primitives for governance or decentralisation on the base layer do not prevent the loudest voices from controlling the debate on a community pool funding proposal or rule out the possibility of centralisation on the application level.
Though the systems we built can enforce or enable specific behaviours, the people behind the code will make the decisions on the design and ultimate creation of the system. In the upcoming content covering various technical features of an interoperability standard for cross-chain communication, it is important to remember that the decision to come together is a human one, which could result in a standard that will connect and add value for all communities involved – or continue to fragment our communities and chains into a landscape of highly customised, highly incompatible state spaces.
Why standardize transport?
In my talk with Susannah Evans at Protocol Berg 2023, we discussed the layers that comprise the IBC understanding of interoperability. This separation of interoperability into component layers built on top of each other was first set out in the IBC specs, which itself was modelled on the concepts presented by TCP/IP.
Though IBC is typically referred to as two layers (transport and application), the definition may be extended in the context of rollups to three layers encompassing transport, application, and state. Rollup architectures largely have designs in place for the application layer, which handles end-user interactions, and the state layer (settlement/consensus and data availability), which provides security to the application layer.
However, one layer that remains largely undefined in the rollup space is the transport layer between application and state – the glue that holds them together. Transport defines how messages are routed from one rollup to another or can be passed from one layer to the next. From the transport layer’s point of view, the data being passed around in generic packets could be anything from tokens to state proofs – it only cares that the packets are assembled correctly so that the state layer can verify data packets and route them to the correct destination. In IBC, this transport layer is modeled with the IBC packet lifecycle.
Why does this matter? While it may be tempting for an interoperability protocol to optimistically send out a data packet and then continue right on to the next packet in the queue, I believe that for an end user, a packet lifecycle does not seem complete without an in-protocol acknowledgment that your packet has been successfully received, or the ability to timeout a packet if the initial send was not successful. This full packet life cycle is critical to supporting a rich design space for cross-chain application flows through acknowledgement/timeout triggered callbacks on the sending chain.
Furthermore, a full packet lifecycle is the only way for rollups/app chains to provide their users with an in-protocol guarantee of packet delivery given a light client security model – a precondition for the growing space of cross-chain MEV products or other products dependent on a guaranteed state transition. As a bonus, the IBC transport layer is about to get the ability to add upgrades, which will allow features such as the incentivisation of relayers to be added to all application data packets – another rich space for continued product innovation.
As I touch on the topic of light clients and their role in verifying state changes, I want to be upfront in saying that I believe that the best bridging solution is the one that doesn't rely on an intermediary, and the ibc-go team has a body of upcoming work around conditional light client features which make it easier for rollups to integrate with IBC. It used to be that having light clients representing each domain for interoperability solutions was seen as too difficult and time-consuming for products scrambling to get market share. Nowadays, it seems that development in the rollup and shared sequencer space has led to a greater understanding – and therefore perhaps greater acceptance – of the need to develop light clients to enable everything from shared sequencer atomicity to simply good security practices.
However, to accommodate market demands for speed, it is important to provide a way for different security models to be incorporated, which can evolve and be swapped out over time as light clients are developed and ZK proofs become easier and cheaper to verify. The IBC generic transport layer allows for this kind of market-friendly security model while allowing you to swap out verification methods over time.
In Summary
2023 was the year that everyone started to understand the importance of interoperability protocols with the VC money out there to back them. Going into a future of explosive growth across a multitude of bridges across all these different parts of the modular stack, I am reminded of the protocol wars of the 1970s through 1990s and what lessons we might learn from their cycles of unification and fragmentation, which resulted in our currently standardized networking protocol for the Internet.
With this in mind, we want your help making IBC the generic transport standard that will work for the entire modular blockchain space.
To date, interoperability protocols that support cross-rollup communication have largely focused on modular optimisations on the security models of the state layer, with the protocol design allowing for the swapping out of different proof types as rollups, such as moving from centralised to decentralised sequencers, or from fraud to validity proofs. However, it's important to note that while these protocols allow for swapping on the state layer, their transport layers are hardcoded, non-standardizable, and fundamentally non-compatible with other interoperability protocols, resulting in hundreds of chains that are siloed off from one another as competing protocols strive to gain market space.
It is critical to have a standardized transport layer to support a world where any rollup or chain can connect to any other chain, regardless of which application or consensus/settlement/DA layer a chain chooses. The IBC transport standards are permissionless, generic, and extensible enough to support the pace of innovation on the other layers. They've gone through a rigorous specification and development cycle, which has resulted in zero exploits to date over a network of 100+ chains with a monthly transfer volume of $3.7Bn at time of writing.
IBC has been executing this thesis since 2021, and we want to invite you to join us. We have so much room left to explore how we could improve things for the entire modular blockchain space (interoperability tx with their mempool, IBCI, auctions in the relayer space, shielded IBC tx for shielded cross-chain networks, etc). You can get involved by reading the IBC specifications and letting us know how we can continue to evolve the generic transport primitives so that they work for your use case. You can also get started by integrating extensible interoperability to evolve the IBC protocol with us.
2024, onwards, and upwards!
