Why Polymer?
The blockchain space is moving towards an ever growing number of execution shards appearing. L1s, alt-L1s, rollups, app chains and app rollups all fall under this category. Modular blockchains also further complicate the landscape by massively opening up the design space for blockchains.
These advancements improve the overall throughput of web3 as a whole but increase fragmentation. What’s gained in scalability is lost in lack of interoperability.
This motivates the need for industry wide interoperability standards as well as a secure and trust-minimized communication layer.
This explosion in different execution environments all but solidify the importance of interoperability, incentivizing a fierce competition among novel and existing interoperability protocols alike.
The interoperability model
To solve this problem, numerous projects have tried different approaches ranging from highly centralized solutions using a permissioned relayer and oracle pair to computing zero knowledge consensus proofs. The main issue with these approaches is that they are merely innovating on how to move the state from one blockchain to another. This indeed is a critical part of the interoperability problem but is far from the complete picture as the state component only addresses the lowest layer of the interoperability model.
Taking the OSI model as inspiration
At Polymer, we believe that a complete interoperability model consists of 3 layers with clear separation between each layer.
The layers in the interoperability model mirror familiar ones in the classic Open Systems Interconnection model (OSI model) for network communication.
The application layer represents application logic that sits on top of the common transport layer. There are already a number of application protocol standards in IBC ranging from basic functionality like token transfers ICS20 to advanced functionality like cross chain validation ICS28 (also known as interchain security). As a developer of IBC-enabled smart contracts, you are challenged to further develop IBC on this layer.
The transport layer of IBC encodes transport, authentication and ordering (TAO) logic. The transport logic in IBC is almost identical to that of TCP and UDP and for good reason. Most competing interoperability protocols have extremely simplistic transport layer implementations that lack TAO logic and do not have an accompanying specification.
Most of the innovation in the space has been happening at the state layer, or how to move state (proofs) from one chain to another. All of the trust mechanisms below are encoded as clients in the IBC model. The 02-client specification allows for the definition of a variety of client types inclusive of most if not all trust mechanisms used in the space.
Tackling interoperability fragmentation
Increasing interoperability fragmentation is a mostly ignored fact since all of the focus of builders and investors has been on the state layer of interoperability as depicted above.
Focusing on the speed to go to market, most new interoperability protocols exacerbates the issues by introducing incompatible transport layers further fragmenting web3.
Counter intuitively perhaps, the transport layer is arguably the most important layer in the interoperability model. The transport layer produces a commitment to all of the messages sent and received from a chain while also enforcing TAO logic. This commitment is called a transport commitment.
Currently, transport commitments produced by one interoperability protocol are not understood by another, requiring translation layers between protocols. This is anti-competitive and promotes vendor lock in at the protocol level.
Who's ultimately going to be the be the victim of this fragmentation and incompatibility?
We think it's the developers (and through them, the end-users). At Polymer, we believe we should put the developers first and strive for transport standards that allow to transfer your skills and knowledge to any environment.
Incentivization
Additionally, there are no protocol level incentives that encourage open participation of clients at the state layer.
With some of the IBC innovations that the Polymer Labs team is working on, client update incentivization will happen in protocol ensuring an open market for clients.
IBC as the standard
Instead of building yet another incompatible transport layer, the Polymer Labs team has been working on firmly establishing the open-source IBC (inter-blockchain communication) protocol as the universal interop standard. Put in a different way, we advocate the transport commitments produced by every interoperability follow the IBC standard.
While it’s normally quite difficult to integrate and maintain IBC compatibility natively in a chain, Polymer, the IBC router hub, makes it possible to integrate and add IBC transport to any chain in a minimally intrusive manner. The different interoperability protocols of today can opt in to become IBC clients in the IBC network of tomorrow.
Why should you care?
Through its efforts, Polymer plays a pivotal role in the wide adoption of IBC as a transport layer standard.
You, the developers of IBC applications, are the prime benefactors of this push towards standardization because of the following benefits:
- Flexibility in terms of the state layer solutions are encapsulated in the IBC client interface, so they don't interfere with the standardization of transport commitments. This will lead to your developer experience being similar when developing cross-chain applications, no matter what chains and ecosystems are involved.
- No vendor lock-in, but open-source contributions and freedom of choice on the protocol level
- With IBC as the transport layer standard, efforts towards developer tooling, education and support with respect to interoperability will grow much faster without fragmentation holding the space back.