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.
Polymer, the Interoperability Hub of Ethereum, is paving the way for collaboration among Ethereum rollups through its native IBC (Inter-blockchain Communication) technology. As the Ethereum ecosystem grapples with scaling challenges and the need for composability, Polymer emerges with a solution, a customizable model of interoperability that connects Ethereum with its integrated Layer 2 solutions.
Since 2015, Ethereum has faced scalability issues, despite the success of its Layer 2 solutions. While these layers improve scalability and user experience, they introduce execution environments that hinder liquidity and complicate the developer journey. Ensuring composability across Layer 2s remains a challenge due to the absence of a standardized native message-passing solution that the Polymer team is tackling using IBC.
IBC has several properties that make it a great candidate for an interoperability standard versus alternatives.
Polymer positions itself not as a bridge but as a Layer 2 dedicated to serving as Ethereum's Interoperability Hub. Polymer provides IBC execution to connected Layer 2s without requiring a native IBC integration, enabling new L2s to permissionlessly connect to the IBC network.
Polymer enhances composability between Ethereum rollups while leveraging IBC’s expanding network of applications. Although initially focused on the Ethereum ecosystem, the Polymer network looks to scale and connect all major blockchains.
Polymer will support various modes of verification or IBC clients between connected rollups. The default mode of verification will be to use the Ethereum L1 for verification. Additionally, any AVS that performs state transition verifications of rollups can be turned into an IBC client and used for pre-confirmations.
Polymer's modular stack consists of a few building blocks;
The core insight of EigenDA is that the problem of data availability does not require independent consensus to solve. If we are building a decentralized transient data store for Ethereum, we can use Ethereum for aspects of coordination required, and for everything else address EigenDA operators directly.
EigenDA has the following characteristics:
Choosing EigenDA aligns with Polymer's commitment to security and scalability, taking advantage of security measures from Ethereum staking and the validator set. The flexible cost model of EigenDA ensures affordable data availability services, crucial for high throughput applications like cross-chain interoperability.
Polymer is building on top of Optimism's OP Stack. EigenLabs recently announced integration support of EigenDA with OP Stack! Let's understand briefly how the integration works.
The components of OP Stack fall into four categories:
The OP Stack batcher is the sequencer module responsible for posting batches of L2 transaction data to DA. We modified this component to write batches to EigenDA instead of Ethereum. When a batch is successfully written to EigenDA, the disperser returns a unique blob key (4), which can be used to later retrieve the data that was written. The batcher then posts this blob key to Ethereum calldata (4), so that Ethereum remains the source of truth for the L2 ordering of EigenDA blobs.
Importantly, the OP Stack x EigenDA fork supports writing each batch to multiple EigenDA quorums, enabling redundant security and mitigating data withholding attacks.
OP Stack full nodes derive the L2 state from transaction data posted to DA, downloading batches and executing them. We modified the OP Stack node to seamlessly handle retrieving EigenDA blobs using blob keys indexed in the Ethereum calldata. This involves a set of scatter-gather requests to EigenDA Operators storing chunks of the blob requested. If the retrieval of the blob from one quorum fails, the next will be tried, until the blob is retrieved or there are no more quorums to try.
At the time of writing, OP Stack does not support fraud proofs, and neither does the EigenDA x OP Stack fork. When fraud proofs are enabled for OP Stack, we plan to update the contracts in OP Stack to support verifying the correctness and availability of L2 inbox data using KZG verification and calls to EigenDA contracts.
Polymer combines OP Stack’s settlement capabilities, Cosmos SDK’s interoperability, and EigenDA’s data availability solution. In doing so, Polymer is delivering a leading hub for domain-specific interoperability, which improves the developer experience, facilitates interconnectivity, and prioritizes security across Ethereum.
Not only is Polymer addressing Ethereum's current challenges, but it also facilitates collaboration with Cosmos. By bringing IBC to Ethereum and allowing for direct connectivity and standardized composability between the two ecosystems, Polymer unites the strengths of both platforms. Ethereum and Cosmos, previously built in siloes, now share innovations, accelerating advancements for both chains.
In summary, Polymer is leading the way toward achieving interoperability and scalability for Ethereum and its Layer 2 chains. It tackles composability issues while fostering collaboration among ecosystems. And finally, by using EigenDA, it is able to achieve greater security, scalability, and cost-effectiveness in achieving its mission.
We’re always looking for talented individuals interested in working on problems in web3 interoperability infrastructure. Click the link below to get in touch.