Introducing Polymer
Introducing the Polymer Hub: A Rollup built for interoperability
Interoperability for rollups on Ethereum today is both highly fragmented and insecure. Polymer solves this by bringing the strong interoperability foundation set by IBC to Ethereum and its ecosystem of rollups. Our approach to doing so is to put the Cosmos SDK on top of the OP stack and build Ethereum’s first interoperability hub.
Polymer is built around these three technical pillars:
-
Ethereum Security: as an Ethereum rollup, Polymer shares the same source of security as the other rollups it connects to.
-
Native IBC interoperability: having no enshrined in-protocol interoperability standards, Polymer ports the IBC standard into the Ethereum ecosystem.
-
Scalable connectivity: as an app rollup Polymer specializes to provide interoperability service to all Ethereum rollups featuring low cost of connectivity and high scalability.
Let's investigate these in more detail.
1. Ethereum security
The rollup-centric roadmap has surfaced as the way forward for the Ethereum ecosystem to tackle its scalability challenges. However, this approach hasn’t been without tradeoffs. Sharding execution across rollups, while enabling scalability, has come at the expense of creating relatively siloed execution environments that fragment liquidity, confuse end users, and complicate the developer journey. Secure composability across Layer 2s has emerged as one of the most significant issues plaguing Ethereum.
There is currently no enshrined interoperability protocol in the Ethereum ecosystem creating a lack of standardization. All of the existing arbitrary messaging bridges (AMBs) are implemented as smart contracts with diverging implementations causing fragmented composability. These problems are expected to get worse as we enter a period of exponential growth of L2 launches.
Realizing the potential of introducing an interoperability standard to provide rollup-to-rollup communication (arbitrary message passing) for the Ethereum rollups, Polymer has decided to build as a rollup settling on Ethereum. We examine the major benefit below.
Trust-minimisation by sharing security
Settling on Ethereum means benefitting from its high security. That's not all though. Additionally, there's an important benefit gained with regards to security when an interoperability hub shares a settlement layer with the chains it's providing connectivity for.
Consider competing interoperability providers that have an intermediate validator set, guardian set or oracles in between the source and destination chains. This introduces additional security assumptions that introduce an attack vector associated with potentially much less economic stake.
Polymer's design as an Ethereum L2 providing connectivity to other Ethereum secured L2s, eliminates this additional trust assumption.
2. Native IBC interoperability
IBC is best positioned to become the interoperability standard for Ethereum specifically and the entire web3 industry more broadly. It’s an open and neutral standard with no single entity controlling the direction of the technology. It’s the product of a collaboration across a number of teams and exists as both a formal specification and a number of implementations across a growing number of ecosystems.
The ethos of IBC has some interesting benefits for cross-chain builders.
Zero Value Capture & Open Competition
IBC has no value capture at the protocol level. It also enables open competition in terms of connectivity. An IBC channel (user/developer facing) can be formed over any list of IBC connections (more infra facing). A connection over an IBC hub is unable to create a vendor lock in for bridged tokens over the ICS20 standard.
How you ask?
IBC allows any channel to be updated (via a feature called channel upgradability) to use another underlying connection.The protocol allows for either using another middle hop/router or to connect directly with its destination.
Transparent Upgrades
Polymer’s architecture allows it to enable IBC on connected chains and make them visible to the IBC network without the chains needing to implement IBC themselves, using a protocol called virtual IBC. However, chains connected via Polymer are not locked into using Polymer. If the chain ends up implementing IBC natively, a channel upgrade can be performed to update the underlying list of connections from using Polymer to another hub or direct connection.
Open Client Marketplace
The IBC client design is flexible enough to represent arbitrary verification logic. They are not restricted to verifying the consensus of a chain. In fact, many interoperability protocols today could easily be represented as an IBC solo machine client which can support one or more private keys. The IBC network itself is essentially client agnostic and allows client builders to compete with one another for business.
3. Scalable connectivity
Polymer could be described as an application-specific rollup or app rollup. This is a concept borrowed from early adopters like the Cosmos or Polkadot ecosystems. It introduces a chain (or rollup) that offers no general-purpose platform for developers to build applications on, but rather a specialized service, thus application specific.
Ethereum itself has opted for protocol minimalism at the L1 level. This is a similar approach to the Cosmos Hub whose major function (this philosophy is called hub minimalism) is to provide security, where functionality is implemented by chains that are secured by the L1 (Cosmos Hub) through interchain security (ICS). For example, Ethereum is leaning on L2s for scalability and sharding whereas the Cosmos Hub is leaning on ICS chains for a smart contract chain (Neutron) and liquid staking (Stride) etc.
Polymer is being built as an L2 on Ethereum’s dedicated to one application, interoperability. In a sense, Polymer enshrines IBC interoperability into the Ethereum ecosystem. Its design as an application specific hub allows for scalable connectivity. Let's investigate the benefits.
Evolution of Network Topologies
There are different high level approaches to interoperability when it comes to network topology. Peer-to-peer or p2p approaches were some of the earliest approaches that were explored. P2P connectivity scales poorly with the number of connected chains as you have an N^2 connectivity problem.
Hub and spoke approaches came next and improve on the scalability at the cost of introducing a middleman between connected chains. An IBC enabled hub like Polymer further improves on scalability by allowing for a mesh network topology where any chain in the IBC network can connect to any other chain no matter how "distant" using multi-hop routing.
Polymer as a Port City
By combining its native IBC implementation along with sharing Ethereum as settlement layer with the rollups it connects, Polymer is an ideal IBC hub for Ethereum L2s. However, it doesn't stop there... .
Additionally, Polymer acts a port city (reference to similar Cosmos Hub metaphor) connecting rollups on Ethereum with the growing IBC network effectively making the Ethereum ecosystem a part of the interchain (i.e. the network of IBC connected chains).
To connect with Polymer (and thus the Ethereum L2), a Cosmos chain would have to run an IBC client to track Polymer's consensus. In other words, it needs to run an Ethereum client. This may not be something every chain may want to do, but one could imagine a setup where the Cosmos Hub or Osmosis runs the client. A multi-hop channel could then be created to connect any IBC enabled Cosmos chain to any Ethereum L2 supported by Polymer. Polymer could act as the port city for Ethereum, the Cosmos Hub (or any other candidate) as the port city for Cosmos.
Same goes for other ecosystems as IBC expansion grows.
Cost of Connectivity
Polymer's design aims to lower the cost of connectivity as much as possible. The cost of connectivity is the sum of the cost of client updates, packets, infrastructure and security. Existing interoperability hubs are built as sovereign chains or guardian sets. The cost of infrastructure for these protocols scales with the number of connected chains and validators. These protocols also generally utilize the protocol token for security which results in either low security or a high security budget if they decide to utilize security solutions such as ICS or restaking.
Polymer as an L2 merges infrastructure and security costs into the cost of settlement. This allows Polymer to provide lower cost of connectivity without trading off security.
Bonus: A Network of Interoperable Rollups
The secondary goal will play a big part in growing the interchain. Putting the Cosmos SDK on top of the OP stack combines best in class developer experience when it comes to building app chains with powerful settlement functionality. The developer experience when it comes to building app rollups with the existing OP stack is still developing. It’s currently quite challenging to add a new execution engine (EE) in addition to making an EE highly customizable for app developers. In contrast, the Cosmos SDK has been an industry leader for years and has solid developer UX.
Combining Cosmos SDK and OP stack technologies, Polymer envisions a new framework to build interoperable rollups.
-
Cosmos SDK complements currently lacking developer UX problem in OP stack
-
OP stack for settlement increases the distribution problem for Cosmos tech
More information to follow...