Fragmented Ethereum, Connected by Polymer with IBC

Launching a blockchain network can be time-consuming and resource-intensive. This applies not only to individual blockchains but also to rollups. However, with technological advancements, 2023 saw exponential growth in infrastructure as rollups began providing their codebases for use as frameworks.

The maturity of RaaS providers fueled this development, leading to the emergence of many providers like Conduit, Caldera, Gelato, Ankr, Luganodes, Zeeve, Tanssi, Dymension, Lumoz, Karnot, and more. This trend increased the interest in interoperability solutions, with many projects actively working to better connect blockchains and rollups.

In this article, we will first gain a better understanding of the current interoperability landscape and the need for improved standardization. Then we will explore how "Polymer" is positioning itself as a secure connection hub within this landscape.

1. Background: Current Status of Ethereum Connectivity

1.1 Looking back into 2021

Reflecting on the famous image by Dmitriy Berenzon in 2021, Ethereum has made significant progress. Previously, the functionalities of bridges were straightforward, primarily focusing on "transferring tokens," whether achieved through wrapping, using liquidity bridges, or via centralized operators.

As more blockchain launched, and the needs for other functionalities increased, lots of other functionalities increased.

Source: Blockchain Bridges: Building Networks of Cryptonetworks | 1kxnetwork

1.2 Current Status of Connectivity

Cross-chain became more like a plugin, allowing connectivity to all chains. Now chains are better connected than ever, messages are now easily transferred and can be customized by the developers need. Now GMP (General Message Passing) is more widely used, allowing projects to send message to the destination chain and trigger executions there. Dapps can utilize other chains infrastructure like using cross chain solutions. For example, lending protocol utilizing layerzero to access liquidity in multiple blockchains.

1.3 Current Issues: Lack of Standards, Independent building

However, the interoperability landscape is still in its early stages, with each project currently developing its own stack. The approaches are more leaning towards making each code and infrastructure into a standardized and customizable module. For instance, LayerZero is announcing v2 to allow custom security modules and middle relayer provider, while Hyperlane v3 is enabling permissionless and customizable deployment.

To utilize these interoperability solutions, developers need to comprehend their usage and the application logic developed alongside. This is crucial as each solution differs and fosters a unique ecosystem.

2. Standards in Interoperability and IBC

2.1 Efforts of Standardization

As the adoption of interoperability increases and the need for customization for other chains becomes more diverse, standardization of application logic and core infrastructure logic has grown in importance.

There are two layers:

1. Application logic: This handles how messages are processed. The trend in the application logic side of interoperability is increasingly leaning towards custom modules for each stacks like OFT-20 by layerzero, although efforts like xERC20 are being made. Also in terms of 

   Interface, projects like Hashi and Multi-Message-Aggregation (MMA) leading the way to create aggregate bridges through a similar adapter format.

2. Core logic: This handles the core transport functionalities. Projects are standardizing their infrastructure, such as Axelar. Meanwhile, projects like Hyperlane and LayerZero are standardizing their infrastructure, and projects like Polymer are working to make standards like IBC more universal.

2.1 Adoption of IBC

The Inter-Blockchain Communication (IBC) protocol is a blockchain interoperability standard and solution that allows for arbitrary data transfer across blockchains in a secure and permissionless manner, especially in Cosmos. It lets blockchains, applications, and smart contracts send and receive data, tokens, and general arbitrary messages to different blockchains

Since IBC was launched in March 2021, there has been exponential growth in usage. In 2022, IBC facilitated 52M transfers of $29B in value. There are more than 100 chains connected to the IBC network. Indeed, access to IBC as a built-in feature was the primary reason behind chains choosing to launch with the Cosmos SDK. However, IBC is not just protocol within Cosmos ecosystem, there are more projects expanding the IBC ecosystem. (Reference part “4.2 Projects Expanding IBC” for more projects expanding IBC to another ecosystem.)

To accelerate this adoption, the Interchain Foundation (ICF) recently released the Interchain Stack Roadmap 2024, which outlines the GTM strategy and development plans for expanding IBC to other ecosystems. Several projects are actively working on expanding IBC to other blockchains.

Source: Adi on X: "prob nothing. @IBCProtocol https://t.co/k0RZTPg8Dv"

2.2 IBC Stack: Core and Application Logic

IBC's architecture consists of a core and application logic that developers can use. The core logic handles the basic transport functionalities, while the application logic is responsible for processing the messages. This modular structure allows for flexibility and customization according to the specific requirements of each project. (Reference APPENDIX B for the architecture and transaction flow of IBC Core Module)

This has enabled the development of the following functionalities on the application side:

• ICA (Interchain Account): This allows one blockchain to operate an account on another blockchain. As a result, a blockchain can perform actions such as transferring tokens, voting, or executing smart contracts on another chain.

• ICQ (Interchain Query): This is designed to enable blockchains to request and securely retrieve data from each other. This functionality allows blockchains to use data from other chains for decision-making processes, smart contract execution, or to enhance their on-chain data availability.

• Cross-Chain Validation: Also more known as interchain security, Cross-Chain Validation allows validators on the main chain to validate transactions or blocks on the secondary chain, effectively extending their security model to other chains.

3. Polymer: The Most Secure Connection Hub for Ethereum

Polymer is currently the project that is trying to bring the functioanlites of IBC to the Ethereum ecosystem, with the “Ethereum Security,” powered by OP-Stack and EigenDA by Eigenlayer.

3.1 Vision of Polymer

Polymer, through the use of IBC and its own OP-Stack Rollup, is constructing the foundational connection layer for Ethereum and, ultimately, for all blockchains.

Similar to a router in web2, which receives and sends data across computer networks, Polymer Rollup receives IBC packets from various blockchains and forwards them to the target chain, adhering to the highest security standards of IBC.

This goal can be achieved in two steps:

1. Step 1: Connect all Ethereum rollups and Cosmos using Polymer's own rollup.

2. Step 2: Establish connections with other ecosystems, including Solana, Avalanche, Sui, among others.

Source: Polymer Labs

3.2 Past Efforts by Polymer: Strong Team in the Interoperability Space

3.2.1 Strong Team with a History

Polymer's team comprises individuals with a diverse and professional background, boasting experience from esteemed firms such as Google, Citadel, McKinsey, Amazon, Verizon, EY, and Uber. The majority of their engineering team, primarily senior developers, was recruited from outside the crypto industry, bringing valuable experience in scaling infrastructure from the traditional internet (Web 2.0) sector.

Initially, Polymer aspired to utilize IBC to create links between different blockchains. Nevertheless, they soon realized that native IBC integrations were resource-intensive. This challenge was initially addressed by establishing Polymer as an independent app chain.

However, as rollups, especially within the Ethereum ecosystem, started proliferating, it became apparent that an independent app chain serving as a distribution conduit for IBC wasn't the ideal fit for communication between rollups. The reason is that there is an inherent interaction between the rollup and the settlement layer it's built upon.

Native bridges of these rollups naturally hold the trust-minimized attributes of the rollup/settlement layer, which are crucial for communication across rollups. Introducing an additional third-party validator set disrupts these attributes. Consequently, the sovereign hub and spoke model, effective for connecting sovereign Layer 1s, falls short in efficiency when it comes to rollups.

To address this issue, Polymer chose to develop a solution that inherits security from the same source as the rollups. As a result, they decided to build Polymer as a Layer 2 solution, inheriting the same security attributes as the rollups it aims to connect.

3.3 Understanding Polymer: The Interoperability Hub

*Refer to APPENDIX A to understand the detailed architecture of Polymer

Polymer acts as the router hub with the structure of an OP-Stack Rollup, making it possible to integrate and add IBC transport to any chain minimally intrusively.

It consists of two primary infrastructures:

1. Interface Layer: This is the Light Client Cluster, which includes an IBC light client and a virtual Light Client. The virtual IBC light client manages incoming requests from Ethereum Rollups, and the IBC light client processes requests from Cosmos chains.

2. Polymer Rollup Layer: This layer has a multihop feature, which facilitates one-click transactions between different chains. IBC channels can be established over Polymer as a middle connection hop, with Polymer functioning like a router.

Polymer acts as an intermediary, following the principles of modular interoperability where the application, transport, and state layers are decoupled but still provide an interconnected solution. This allows non-IBC chains like Ethereum to leverage IBC through a lightweight implementation while relying on Polymer to handle the transport work. In this way, vIBC enables interoperability for greater blockchain interconnection.

3.4 Polymer Tech Stack

The Polymer tech stack is built on two fundamental philosophies:

1. Adopting the security of Ethereum through the most used rollup framework and the most Ethereum-aligned altDA.

2. Incorporating technology that enables Inter-Blockchain Communication (IBC), with also leveraging the IBC codebase and related application logics.

Here's a breakdown of the key components of the “Polymer Tech Stack” and their functions (from a Modular Blockchain perspective):

1. Execution: The Cosmos SDK is integrated into Polymer to natively provide Inter-Blockchain Communication (IBC) interoperability for connected rollups. This allows for the transfer of arbitrary data between blockchains, enabling seamless interaction and data transfer.

2. Settlement: Polymer employs the OP Stack to provide reliable and efficient settlement and chain derivation logic to and from Ethereum.

3. Data Availability: EigenDA is crucial in ensuring scalable data availability within the Polymer network. By boosting the data bandwidth of the Ethereum network, EigenDA enhances the network's capacity for high-throughput applications like cross-chain interoperability.

Through the use of OP-Stack, Cosmos-SDK, and EigenDA, Polymer ensures the establishment of a secure interoperability infrastructure.

Source: The Polymer Tech Stack | Polymer Developer Docs

3.5 Leading the Coordination of IBC

To ensure efficient development and coordination, it is necessary to have a single entity driving the development of each component and coordinated by a single entity.

Currently, Polymer is leading the development and coordination efforts. IBC Explorer, OpenIBC and IBC Summit, which is operated by Polymer are three initiatives focused on coordinating these efforts.

3.5.1 IBC Explorer

Source: polymerdao/ibc-explorer: IBC dashboard

IBC Explorer is designed to enhance the user experience for developers working with IBC. The IBC Explorer aims to address these areas by offering features such as:

• Simplified tracking of packet lifecycles, allowing for a better monitoring process.

• Health tracking of application-specific channels, providing a clear overview of their performance.

• Providing control over network configurations, enabling developers to specify the chains they want to communicate with via specific clients.

These features are meant to enhance the practical application of IBC, making it more user-friendly and adaptable to the needs of developers.

3.5.2 OpenIBC (Website, Twitter)

OpenIBC is an organization founded by Polymer that focuses on developing and promoting inter-blockchain communication (IBC) protocols. Its main objective is to establish a united network of developers, projects, and organizations collaborating to advance IBC standards and implementations.

The OpenIBC has a forum that serves as a platform for discussions, collaboration, and knowledge sharing regarding IBC development. By bringing together stakeholders from various blockchain communities, OpenIBC encourages open and collaborative development of IBC, enabling secure communication and interaction between different networks. The forum aims to play a crucial role in coordinating efforts to further establish IBC protocols across the industry.

3.5.3 IBC Summit (Website, Twitter)

The IBC Summit is a gathering that brings together individuals in the ecosystem to enhance their understanding of IBC and engage in discussions about the industry's future direction. Numerous industry experts have shared insights on the utilization and potential of IBC.

4. More on the IBC Ecosystem, Over Ethereum

4.1 IBC Ecosystem in Cosmos

As the Cosmos ecosystem has the most active customization and development in the IBC Stack, let’s look into the current development.

In the past, The Interchain Foundation (ICF) and Informal Systems were the teams responsible for maintaining and developing core components related to IBC. The ICF focuses on maintaining the IBC specification, ibc-go, and ics23-go. On the other hand, Informal Systems maintains hermes, ibc-rs, ics23-rs, and tendermint-rs (in collaboration with the CometBFT team).

There also have been significant advancements in IBC functionalities in various Cosmos-based blockchains. Here are some examples:

• Osmosis: It offers outposts and cross-chain swaps.

• Stride and Neutron: These blockchains are built with extensive middleware, ICA, and queries.

• DAO DAO: They created Polytone, a protocol that provides every smart contract with an account on every IBC-connected blockchain.

• Evmos: They built IBC precompiles for transfers through the EVM.

• Injective: They developed an oracle data streaming module.

4.2 Projects Expanding IBC

There are multiple projects making IBC to be utilized in multiple blockchain networks. This made the technical landscape and resource diverse for IBC, and it is being tested in different environments, which is leading to a more diverse ecosystem.

When extending IBC to other blockchains, there need to be four things to be developed to enable IBC based interoperability

1. Core Logic: Implementing a custom IBC transport layer is key to integrate other blockchains, as ibc-go only works for Go chains. Alternatives like ibc-rs for Rust are being developed but not as mature.

2. Light Client: A new non-Cosmos chain requires a light client for verification to validate transactions trustlessly.

3. Relayer: Relayer software and operators are needed to route IBC packets between connected zones and propagate data from the new chain within the ecosystem.

4. Verification Logic: IBC in Cosmos utilizes merkle proof to verify cross-chain transactions. However, different blockchains have varying finality and verification logic. For instance, Ethereum allows for reversibility, unlike Tendermint. OP-Mainnet, which utilizes Fraud Proof for finality, also has its own unique logic. Therefore, the verifying client should employ different measures to ensure correct finality across blockchains.

Additionally, connecting two different blockchains with varying finality and technical specifications can be challenging. To address this, various modifications and supplementary logic are required. One example is the Conditional Client and the virtual Light Client developed by Polymer Labs.

5. Looking Ahead - The Interoperability Landscape

In 2023, numerous projects aimed to address interoperability issues. Some succeeded, while others failed. However, current players have solidified their positions and are standardizing the way messages and tokens are transferred between chains.

I believe there are two interesting aspects that are under development in the core transportation of logic:

• Application logic: Sending packets between chains means that not only can assets be transferred, but data can also be sent, and smart contracts can be executed from other chains. This opens up the potential for interesting implementations, such as Hashi building interface adapters for chains and creating a secure multi-chain wallet with Safe. Another example is Catalyst, which is constructing a liquidity layer for all blockchains.

• Greater coordination among projects: As interoperability solutions become more permissionless, they can support each other and mitigate failures. The proposal for standards like xERC20 is intriguing, as this standard could be adopted by other solutions. This coordination appears to address the fragmentation of development, where each solution initially aimed to resolve the fragmentation of chains.

In this context, it's interesting to see how Polymer is addressing these elements by bringing Cosmos IBC application logic developments to Ethereum, and continuing to support the IBC ecosystem through education and development. It will be interesting to see how this impacts the overall Ethereum ecosystem once it goes live.

APPENDIX A: Polymer Architecture Deep Dive

This section delves into the intricacies of Polymer's architecture, looking into the roles and interconnections of its various components.

The core components are like below

1. IBC Interface:

   1.1 Entry contracts: These are the contracts that are deployed on each rollups/blockchains.

   1.2 Relayers: These are the entities that listen to events in other rollups/blockchains and relay them to Polymer, and vice versa.

2. Polymer Rollup

   2.1 Cosmos-SDK: This is the execution layer where the logic is constructed.

   2.2 OP-Stack: This is the rollup infrastructure where the transaction and settlement processes are managed.

   2.3 EigenDA: This is where data availability is handled, offering lower costs but maintaining Ethereum level security.

Source: The Polymer Tech Stack | Polymer Developer Docs

A.1 IBC Interface - Access Polymer

A.1.1 Entry Contracts

At the user interface level, we have IBC proxy contracts which serve as the primary point of contact for users. These entry points are built on a foundation of core smart contracts that define the operational logic for application. Below are core components of Polymer making connections available.

• IBC: The standard protocol facilitating interoperability between different blockchain networks.

• vIBC: Representing Virtual Inter-Blockchain Communication, this adaptation of the Inter-Blockchain Communication (IBC) protocol is designed to make IBC available to any chains. 

  Virtual IBC allows for permissionless IBC connectivity. The idea is that instead of needing to do a native integration of IBC, devs can deploy a set of smart contracts, and instead have Polymer act as an IBC sidecar performing IBC execution on behalf of the connected rollup, making the rollup appear as any normal IBC chain in the network itself.

• Middle Hop: enables a one-click transaction between different chains; IBC channels can be defined over Polymer as a middle connection hop, as Polymer acts like a router.

A.1.2 The Relayer Component

The Relayer is a bridge-like entity within the Polymer architecture, responsible for monitoring and conveying events across different blockchain networks. It's a vital cog in the machinery, ensuring that operations on one chain can trigger corresponding actions on another.

A.2. Polymer Rollup: Cosmos-SDK, OP-Stack and EigenDA

A.2.1 Polymer Rollup, built with Cosmos-SDK and OP-Stack

Diving deeper into the architecture, the Polymer Chain App integrates a variety of technologies:

Cosmos-sdk: This framework is used to build blockchain execution logic within the Cosmos ecosystem, illustrating Polymer's compatibility with this environment. Polymer has successfully integrated with OP-Stack, using Cosmos-SDK as an execution engine for Ethereum rollups.

OP-Stack: The OP Engine API and the OP rollup node, key components of the Optimistic Rollup infrastructure, are central. The OP Engine API interacts with cosmos-sdk, while the OP rollup node serves as the settlement layer for a sequencer.

• L2Client (ABCI): This Layer 2 client uses the Application Blockchain Interface (ABCI) to facilitate communication between Cosmos-SDK and the OP Engine API.

• Sequencer: This node sequences transactions, determining their order before they're finalized on the blockchain.

• Proposer: This entity proposes new blocks for the blockchain.

A.2.2 Data Availability (DA) Layer with EigenDA

The Data Availability (DA) layer is responsible for ensuring that data across the chains remains accessible and verifiable. This is crucial for maintaining transparency and security within the ecosystem. Polymer use EigenDA to achieve this, which allows Polymer Rollup to operate at a much lower cost while maintaining Ethereum level security.

APPENDIX B: IBC Protocol and Its Detailed Process

The Inter-Blockchain Communication (IBC) protocol is a blockchain interoperability solution that allows for arbitrary data transfer across blockchains in a secure and permissionless manner. It lets blockchains, applications, and smart contracts seamlessly send and receive data cross-chain.

When discussing cross-chain solutions, the Inter-Blockchain Communication (IBC) protocol is often mentioned as a secure and reliable cross-chain protocol, but mainly only actively used within the Cosmos ecosystem.

Lets look into how IBC actually works:

B.1 IBC Stack

IBC has different standards and consists of various components. The two main operators are the Light Client and Relayer. The application logic and the connection are implemented in its core logic.

1. IBC Light Clients: IBC clients, also known as light clients, track the consensus state of other blockchains and the proof specs required to verify proofs against the client's consensus state. Each client is identified by a unique client ID and can be associated with any number of connections to the counterparty chain.

2. Relayers: Relayers play a key role in IBC communication. They are off-chain processes responsible for relaying data between two chains running the IBC Protocol. Relayers scan the state of each chain, construct appropriate datagrams and execute them on the opposite chain as allowed by the protocol.

B.2 Lifecycle of IBC

IBC enables communication through a process of establishing connections. Channels are then opened between modules to allow packet sending, receiving, and acknowledgment using a channelID and portID. Once connections, channels and ports are set, applications can transmit packets across chains. A user initiates a cross-chain transaction delivered via relayers to the light client of the receiving chain for verification.

B.2.1 Initialization

1. Establish Connections: Connections, as facilitated by ICS-3, are responsible for all cross-chain verifications of an IBC state. Each connection encapsulates two ConnectionEnd objects on two separate blockchains. Each ConnectionEnd is associated with a light client of the counterparty blockchain.

1. Open Channels: Modules on one blockchain can communicate with other modules on different blockchains by sending, receiving, and acknowledging packets through channels. Channels are established with a handshake and are uniquely identified by the (channelID, portID) tuple. They encapsulate two ChannelEnds that are associated with a connection.

2. Bind Ports: An IBC module can bind to any number of ports with each identified by a unique portID. The portID denotes the type of application, for instance, in fungible token transfers the portID is 'transfer'.

B.2.2 Packet Transfer

Applications can now send data packets across the established channels. Once a data packet is sent from the source chain, it's received and acknowledged by the destination chain, utilising the light client on the destination chain for verification.

1. A user, which can be an end user, smart contract, or module, initiates a cross-chain transaction on Chain A.

2. The transaction request is transmitted to the IBC Transport Layer to be delivered to the receiving chain, Chain B.

3. An off-chain process, known as a relayer, takes responsibility for transporting the message from Chain A to Chain B.

4. Chain B utilizes its light client of Chain A to verify the consensus state and confirm that the transaction has indeed occurred on Chain A.

5. If the verification is successful, indicating that the transaction is legitimate and has been executed on Chain A, Chain B proceeds to execute the requested action on its own chain.

Thanks to Kate for designing the graphics for this article.