Get Early Access
You're in! We received your sign-up successfully. 🥳
Oops! Something went wrong while submitting the form.
Please, refresh the page and try again.
Please, refresh the page and try again.
Thinking in Modular
Modular is currently a popular term in web3 that a number of protocols and projects are using to describe themselves. Celestia popularized the term by introducing the concept of modular blockchains. Our goal is to narrow the focus and usage of the term on a very specific definition of modular interoperability. We’ll also introduce a framework for thinking about and evaluating modular blockchains and interoperability protocols.
Breaking down blockchain protocols
There are a few composable layers in the modular blockchain stack:
- Data availability (DA)
- Sequencing or transaction ordering (TO)
- Execution
- Settlement
Monolithic chains like Ethereum combine all three layers into one and bundle in consensus. Modular blockchains break up the layers above into parts and implement one or more while outsourcing others.
Note that consensus isn’t included here because it can be bundled into any of the layers above to allow for verifying a consensus proof instead of checking the rules of the functional layer directly.
For example, one could deploy a single node rollup on top of Celestia sans consensus that relies on fraud proofs to convince a third party of correctness. This would be called an optimistic rollup. If we swap the fraud proof out for a zero knowledge (zk) proof then we’d get a zk rollup. If we add in consensus, we can instead use the consensus proof to convince a third party of correctness. This would be called a pessimistic rollup.
Breaking down interoperability protocols
A complete interoperability protocol has three well defined layers with clear separation in between.
A simple definition of each interoperability layer:
- Application: What do packets of data mean?
- Transport: How do we translate the state of the other chain into app <> app conversations and packets of data?
- State: How do blockchains become aware of each other’s state?
To relate the interoperability stack to existing concepts, we’ll use an imperfect analogy borrowing knowledge from the layers of a blockchain stack popularized by our friends at Celestia and the well understood OSI model.
Defining modular interoperability
Since modular is a term often thrown around and is relevant in any number of contexts, we’ll try to relate our definition of a modular interoperability protocol to the layers defined above as well as Celestia’s definition of a modular blockchain. Celestia defines a modular blockchain as a blockchain that fully outsources at least one functional layer to an external chain. We define a modular interoperability protocol as one that fully outsources the transport layer.
The key difference between the two is that the defining layer for interoperability protocols is the transport layer. The analogy here, using the OSI model as an example, is that if you swap out TCP/UDP for another transport protocol you get an entirely different networking protocol. Also, the state layer can be established through a variety of means and does not uniquely define an interoperability protocol (e.g. light clients, zero knowledge proofs, optimistic fraud proofs etc). Application layer logic can also be generalized and does not make an interoperability protocol compatible with another. For example, swapping out IBC transport for a different transport layer makes the new protocol incompatible with IBC enabled chains.
The state layer can also be partly outsourced but outsourcing alone does not make the protocol modular as it’s not the defining layer of interoperability protocols. It is considered fully on-chain when each chain directly runs the light client logic of its counterpart. The state layer is considered partly on-chain when light client logic is run off-chain and verified on-chain using zero knowledge (zk) proofs or when a trusted third party is used.
Also, modularizing monolithic chains has implications on the state layer of interoperability protocols. For example, a single logical chain can no longer be represented by a single light client because proof of various functional layers are now sourced from multiple chains.
Polymer the IBC Transport Hub
Polymer is building the first truly modular interoperability protocol that fully outsources the transport layer and partly outsources the state layer. As seen in the diagram below, the IBC transport layer runs on Polymer while the IBC app layer runs on the IBC enabled chain. With this design, enabling IBC on a new chain using Polymer is as easy as deploying a roll up onto Celestia. Polymer partly outsources the state layer by using zk-IBC connections to connect to newly IBC enabled chains while the zk verifier sits on chain (not shown in the diagram above for simplicity).
Let’s build together
Let’s build a future where IBC is the standard interoperability protocol for all chains. Ideas for improvements to IBC are always welcome. Come chat with us on discord. We’re also hiring. Innovation accelerates when we all work together!
Thank you for the conversations Jim (Catalyst) and Josh (Astria)!
About Polymer
Polymer believes in a multichain future connected primarily by one open-sourced, community-developed, and maintained industry standard, IBC x Polymer. Polymer is the first IBC transport hub focused on expanding IBC to all chains. The Polymer hub integrates the IBC transport layer with connected chains. At the state layer, it opens zk-IBC connections to all integrated chains. This is a trust-minimized architecture based on light client state proof verification.
Follow our Twitter, visit our Website, and join our community on Discord!