Polygon CDK Interop

The blockchain industry has recently seen an increasing number of layer 2 solutions, including a list of app-chains. One organization after another decides they want control over the design decisions that go into their L2 solution, tailoring the setup specifically to their dApp, use case, or community interests. This diversity of solutions has many benefits, e.g. offering the ability to make design decisions such as rollup vs. validium can be dealt with on a case-by-case basis. However, it also exposes the blockchain community to an important problem, sometimes referred to as the “walled garden” problem: Organizations are building very nice solutions that have a hard time interacting with one another and the outside world in an ergonomic way.

This situation has two significant drawbacks:

1. Each dApp or L2 chain only has access to the liquidity provided by its own community, which is often not enough to provide sustainable economics.
2. Security and transaction throughput are increased significantly within each specific L2, but not between L2s.

A solution is needed urgently to resolve the current situation of diverging ecosystems.

Polygon decided to look into this problem and came up with a novel solution: The Polygon Chain Development Kit (CDK), with its new Interop layer. Polygon CDK is a set of open source software that allows organizations to build their own modular and customizable ZK-based L2 on top of Ethereum, with built-in interoperability between the different Polygon chains as well as with Ethereum itself. This idea provides each app-chain access to the liquidity in the entire Polygon ecosystem, and ensures not only high transaction throughput within each dApp individually but also between dApps.

In this blog post, we will both delve into how the Polygon CDK is designed, and what the Interop layer brings to the table.

Polygon CDK

When designing your own CDK L2, you can configure a number of things, including the data availability layer, whether your L2 will be a ZK validium or rollup, and whether you prefer using a centralized or decentralized sequencer. For example, it is possible to set up your data availability layer to leverage Polygon’s data availability committee (DAC). The result of these design decisions is your customized L2 system, which you can deploy and people can interact with through RPCs. Your L2 system will process the user requests and send the results to the prover to verify and generate ZK proofs and batch proofs. The resulting state update and batch proof and used to update a set of Ethereum smart contracts.

There are a number of advantages to such a design for building custom L2s. Firstly, the customizability built into this design allows to combine the resources which would have otherwise been split into developing many separate app-chains. Secondly, this architecture gives Polygon Labs enough control over the system to allow for updating their ZK proving system, thereby making the CDK future-proof.

Finally, given the shared design of many L2s, Polygon and other players are now able to build bridges between L2s in a more scalable way, no longer requiring a separate bridge design between any two chains. This observation was leveraged into building the so-called LxLy bridge, allowing anyone to connect any two CDK-based L2s without too much trouble.

Interop layer

Polygon’s version 2.0 includes a new solution to the interoperability problem: The Interop layer. This design has been described as “a shared aggregate prover safeguarded by Polygon validators”. In this new architecture, separate L2s no longer have to post directly to Ethereum, each in its own set of smart contracts. Instead, all communication between individual CDK L2s and Ethereum can be aggregated by the Interop layer. ZK proofs generated based on transactions from different L2s are batched, and the batch proofs posted into a singular smart contract setup on Ethereum. This allows CDK L2s to interact with one another directly and with the same transaction throughput as if they were a unified L2. Meanwhile, each L2 is still able to configure their individual chain’s properties based on their specific community requirements.

Conclusion

In recent years, the blockchain industry has diversified in search of L2 solutions for the sake of privacy and scalability. Significant progress has been made towards these goals, though an unfortunate side-effect is the creation of the “walled garden” problem, where individual L2 ecosystems enjoy significant transaction throughput and low gas fees but interactions between L2s are difficult. The Polygon CDK, with its new Interop layer, eliminates this issue through built-in interoperability between their L2s. This is accomplished by the Interop layer, which aggregates all L2 ZK proofs into ZK batch proofs independently of which L2 a ZKP originates from. This allows for direct interoperability between CDK-based L2s, allowing both individual configurability and communal interoperability.