Polygon: L2 or not L2?

It’s time for another L2 comparison! The other day I came across a project I wasn’t aware of: Polygon. Polygon is advertised on its official site as the “Ethereum’s Internet of Blockchains”. What does this mean?

Polygon seems to be tackling all of Ethereum’s current limitations at the same time: its current low throughput (which hopefully will be improved with Ethereum 2.0); the poor UX provided for applications as a result of gas fees and the delayed PoW finality; and what they call “no sovereignty” which translates into the lack of composability of the Ethereum stack; and its governance dependence, which limits the influence decentralized applications can have over the underlying blockchain substrate. They aim to solve all of this by building “a protocol and a framework for building and connecting Ethereum-compatible blockchain networks.”

If you’ve been reading my publications lately, you may already be aware of how several projects in the community are trying to mitigate some (or all) of the aforementioned limitations by building Ethereum-compatible blockchains. They’re building completely new blockchain protocols like Polkadot which are EVM-compatible or implementing Layer 2 solutions built on top of Ethereum’s mainnet, such as Metis, Optimism, or Arbitrium.

Polygon is attempting to resolve multiple challenges at the same time, offering one-click deployment of the preset blockchain network (Polygon commit-chains); a set of modules to develop custom networks (like what you can do with Parity’s Substrate); an interoperability protocol for exchanging arbitrary messages with Ethereum and other blockchain networks; and adaptor modules to achieve interoperability for existing blockchains (similar to Polkadot’s bridges).

Source: https://polygon.technology/

When I read this list of promises from Polygon, I thought: “Wow! They are basically trying to do everything!” But the more I read, the more I wonder if they were trying to bite off more than they could chew. In order to get convinced that all of this was possible and could be implemented by the same team, I had to go deep into the tech. Let’s jump into it.

The tech behind Polygon

Polygon is not a single blockchain, but an ecosystem of tools to deploy your own blockchain network, and host your blockchain applications. In certain ways it may be close to a L2 solution, but currently it is more an interoperability project and a blockchain framework (you’ll see in a moment why).

Polygon’s PoS “main chain”

With Polygon you are able to deploy your own blockchain network, interact with other EVM- or Polygon-compatible blockchains, and give an additional level of security and trust to your network leveraging the Ethereum main chain, Polygon’s main proof of stake chain, or a “security as a service” feature.

Polygon’s main chain, also known as Matic POS Chain, is an Ethereum commit-chain with a proof-of-stake consensus. The relationship between Matic POS chain and the Ethereum main chain is depicted in the following figure:

Block producers in the Matic network are producing blocks at fast speed. In order to commit these blocks to Ethereum’s main chain, the Matic chain uses a proof of stake consensus. For every few blocks on the block layer, a proposer will be chosen among the stakeholders to propose a checkpoint on the Ethereum main chain. These checkpoints are created by the proposer after validating all the blocks on the block layer of the Matic Network and creating the Merkle tree of the block hashes since the last checkpoint.

The root of this block commitment is then broadcast to all the stakers in the network. In order for a checkpoint to be accepted as valid, at least ⅔ of all stakers in the network need to accept it. With all the signatures collected, the checkpoint is committed to the Ethereum chain. From there on, anyone in the Ethereum network can challenge the proposed checkpoint for a period of time. If no one challenges it, the checkpoint is considered final and included on the main chain. All of this is orchestrated by a set of Polygon smart contracts deployed in Ethereum.

The Matic POS Chain has a utility token, Matic, which is used for staking and governance purposes, as well as of course to pay for transactions in the chain. In order for a node in the Matic POS chain to become a proposer or a staker, it needs to stake a certain amount of Matic.

For those of you who are regular readers of my publications, this scheme may have reminded you of an optimistic rollup, with its sequencing of transactions. This is one of the aspects where Polygon resembles a Layer 2 solution. However, the security and trust guarantees of Matic chains checkpointing are weaker than the ones for optimistic rollups. We’ll dive further into this issue after introducing a few more Polygon concepts.

Bridges

Polygon also supports interoperability between chains through what it calls bridges. These bridges can be used for arbitrary message passing and asset exchange between chains. With these bridges, developers are able to migrate tokens, or make smart contract calls from one chain to another. Technically, a bridge is a set of contracts in both chains that orchestrates this migration of assets from the root chain to the source chain. In a nutshell, and disregarding the bridge’s specific implementation, an asset exchange between two chains using bridges has the following stages:

• A user deposits funds into the bridge in the source (or parent) chain, and a representation of the assets is issued in the destination (or child) chain.
• The bridge is notified about the new account balances and enables the withdrawal process.
• From here on, the user can withdraw their assets in the child chain. The assets in the parent chain are burnt and the user’s balance in the child chain is updated.

Polygon currently supports two different implementation of bridges for the interoperability between chains:

• A PoS bridge, which is faster and more flexible, but a less secure solution than the second bridge currently supported by Polygon, the Plasma Bridge. In the PoS bridge developers need to map the addresses of the source and destination contracts, block the assets, and run the exchange. The PoS bridge uses Matic’s state sync mechanism, which is the scheme used by the Metis POS chain to read from Ethereum. These exchanges take 10 to 30 minutes.
• The Plasma bridge provides increased security guarantees but with a 7-day withdrawal period associated with all withdrawals from Matic to Ethereum. In the next figure you can get a glimpse of how the Plasma bridge operates for the case of an NFT migration. You can follow this link for further details.

Polygon SDK

The reason why I mentioned that Polygon is more a framework than just a blockchain is the Polygon SDK. The Polygon SDK is a modular and extensible framework for building Ethereum-compatible blockchain networks. You can think of it as an alternative to Parity’s Substrate but written in Golang, instead of Rust, and exclusively for EVM-compatible chains.

The Polygon SDK provides the following layers that you can configure and modify to implement your own chain:

• The blockchain layer is the core of the SDK. It implements everything related to block and the state of the chain. It manages the logic that happens when a new block is included into the blockchain, and defines the state behavior. The state represents the state transition object. It deals with the state changes when a new block is added to the chain and the state handles (the execution of transactions), executing the EVM, and changing the state Merkle Tries of the blockchain according to the transaction being performed.
• The consensus layer provides an interface for different consensus algorithms. It lets you plug in or implement any consensus algorithm you want into your blockchain. The only consensus currently supported by the Polygon SDK is the Istanbul Byzantine Fault Tolerant (IBFT). But according to Polygon’s documentation, the company is also working on implementations for Clique, Ethash, and PoW.
• The TxPool module is what you would expect: it represents the transaction pool implementation, where transactions are added from different parts of the system, for their subsequent processing by the consensus and the blockchain layer.
• Finally, the SDK includes a p2p networking layer for the communications between peers implemented over libp2p, and a gRPC and JSON RPC APIs to interact with the peer.

What is yet to come

We’ve gone through all of the solutions that are currently implemented through Polygon. But if you remember from my brief introduction to the project, and the figure with the list of solutions, Polygon has way more than this in its roadmap in order to fulfill its vision. Mainly:

1. Polygon chains: Polygon is planning to support two major types of Ethereum-compatible networks: standalone networks and networks that leverage “security as a service”.

• Standalone chains are fully independent blockchain networks in charge of their own security. They enjoy full independence, but the level of security of the chain depends on the number of nodes participating in the network, and the specific consensus being used. This can be a great fit for big enterprises or established projects and communities.
• On the other hand, secured chains are blockchain networks that use Polygon’s security layer instead of establishing their own independent validator tool like standalone chains. This security as a service can come in the form of a delegated pool of validators, or the combination of other verification schemes like rollups and fraud proofs.

2. Security as a service: Polygon offers a specialized and non-mandatory layer to provide “validators as a service”. These validators periodically check the validity of any Polygon chain for a fee. This runs in parallel to the Ethereum chain, and is fully abstract so it has multiple instances. This looks a lot like Metis’ pool of sequencers (but more about this in the next section).

3. Rollups: Polygon has in its roadmap the implementation of ZK and optimistic rollups. I couldn’t find additional information, but I personally expect these schemes to become part of the aforementioned security layer, as an additional security mechanism that standalone chains can request.

How does Polygon differ from a L2 solution?

I wouldn’t call Polygon an L2 solution, at least not yet. For me, it is currently more of an Ethereum commit-chain, an interoperability solution, and a blockchain framework to offer flexibility to DApp developers. If you take a true L2 project like Metis, which you may probably be familiar with by now because it has been featured in a few of my previous publications, you see that:

• While Metis has a clear proposal to tackle Ethereum’s scalability limitations, a user of Polygon needs to navigate through all of its solutions to understand the one that suits its needs: the Matic PoS chain to overcome Ethereum’s scalability limitations, bridges if interoperability of networks is the key issue, or the Polygon SDK to build a brand new EVM-compatible standalone chain.
• Matic PoS Chain’s checkpoint scheme is quite similar to an optimistic rollup. But if you then look at Polygon’s roadmap, the company is also thinking about implementing optimistic rollups. So how can this be? My take is that Polygon’s rollup implementation will belong to the pluggable security layer. Metis and other L2 solutions on the other hand already come with optimistic rollups “by design” as part of their protocol; it is not an optional layer that needs to be configured ad hoc into your chain. The chain just has it. I was trying to find some numbers on the performance of the Matic PoS chain in order to compare them with the numbers we saw in this comparison between Metis and other optimistic rollup solutions, but couldn’t find anything. However, at a glance, Metis’ sequencing pool, and the use of rangers as verifiers with a stake in the network, seem more robust than the ones in place for the Matic PoS chain. Matic’s PoS chain more closely resembles the optimistic rollup approach from projects like Arbitrium.
• Companies looking to deploy blockchain applications may choose Polygon to deploy their standalone chains. This may make sense for certain use cases, as many L2 solutions are not focused on corporate use cases, and they lack the isolation and security guarantees required by this kind of organization. However, this won’t be the case for solutions like Metis. Metis supports DACs (Decentralized Autonomous Companies) from scratch, which gives organizations access rights and other permissioning schemes without requiring the deployment and maintenance of a complete independent chain (with the overhead and the burden that this may entail).
• Polygon standalone chains can also be a great way of horizontally scaling use cases. However, L2 solutions like Metis also allow this horizontal scale by decoupling the state and the execution of transactions without requiring the deployment of a brand new chain.
• When I was reading about Polygon’s security layer and “validators as a service,” it also reminded me about how Metis already has “by default” rangers and sequencers with a stake securing the L2 and committing blocks to the mainnet. However, while in Polygon’s security layer, validators are “rented” for specific standalone networks. With Metis, rangers and sequencers rotate through every DAC enforcing that everything is working as it is supposed to in all of them (not only a small number of selected ones).
• Something that many L2 solutions lack and where Polygon excels is in the interoperability between chains. I would be curious to see how Polygon bridges operate with L2 solutions like Metis. Metis, like almost every L2 solution, is EVM-compatible, which means that it would be theoretically possible to use Polygon bridges to perform token exchanges between Metis and other Polygon-compatible chains. Can you imagine how powerful a decentralized application would be by leveraging Metis Layer 2 capabilities (with its IPFS integration), and Polygon interoperability features?
• Finally, let’s come back to something I briefly brought up at the beginning of the article: the security and trust guarantees of Polygon bridges and its interaction with L1 are weaker than those of L2 solutions based on rollups like Metis. This is no small item. We’ve seen many times how so-so security has led to disastrous results for blockchain projects. Since Metis is a fully decentralized platform running on top of the secure Ethereum network, it’s a more secure option than a centralized commit-chain like Polygon.

It all boils down to who you choose to trust

Polygon PoS bridge is secured by a set of external verifiers. The security of this chain is guaranteed by the verifier’s stake in the system, and the penalty of misbehaving. Nothing new on this front, we place our trust on the security of the system in the economic incentives of the consensus. The more verifiers and the more stake in the network, the more we can trust it. Something similar happens for optimistic rollups, due to the economics of the scheme, the more sequencers and verifiers involved in the network, the more we can trust the security of the L2 solution. This is why I mentioned in my comparison of L2 solutions that having an incentive system where not only sequencers but also verifiers have “skin in the game” (as is the case with Metis) can really benefit the performance and security of optimistic rollup implementations. But what about Polygon bridges?

Polygon PoS doesn’t have a single custodian, and also tries to follow a decentralized crypto-economic approach. However, the bridge contract, where user assets are deposited and the overall setup is responsible for their withdrawal and asset exchange, retains admin authority and is controlled by a multi-signature wallet via a proxy. This multi-signature wallet started with a 2/3 multi-signature and is now upgraded to a 5/8 scheme. Among the eight signatories, four are Polygon co-founders, and the other four are key members from other Polygon DeFi projects.

As stated by an independent security analysis of Polygon’s PoS bridge: “Through our examination of the contract code, the owner of the contract can upgrade and replace the contract at any time (without a delay period), which means that the owner can withdraw all user assets in the contract at any time, which is certainly a potential security risk. Therefore, the assets transferred to the Polygon chain through the PoS Bridge are not trustless at this stage.”

The security guarantees of Polygon’s Plasma bridge are a bit stronger but still far from perfect. If you recall from our brief description of the Plasma bridge, a challenge period of seven days is required when withdrawing funds, because of the use of fraud proofs. The important shortcoming of this approach has to do with data availability. While in optimistic rollups, all the data you need to verify a rollup is on L1 and there is no need to interact with the L2 commit-chain, this is not the case for Polygon. In Polygon, a user needs the Merkle root generated in the Matic PoS chain’s checkpoint in order to verify the proof. This translates to a user being unable to identify a malicious actor without interacting with the Matic PoS chain.

This tweet thread describes perfectly in six tweets why optimistic rollups (and optimistic rollup-based bridge solution) is a way better approach in terms of security. It all comes down to who you trust: a set of validators and the data in L1; or a small number of validators and some data stored in a commit-chain.

“TL/DR: users need to trust validators for the safety of their funds and the ability to exit them. Validators can easily block funds on a sidechain (by withholding data) or seize them (by assigning all tokens to themselves)” — source: https://twitter.com/bkiepuszewski/status/1394048672367849478?s=20

As a final note, this post has a great overview of different implementations of bridges (including Polygon’s bridge) and a brief comparison with L2 protocols.

Closing words

And that is all that I have (at least for now). Today we had the opportunity to learn about another interesting project in the Ethereum ecosystem, Polygon. I approached this project thinking that it was another yet another L2 solution, and what I ended up encountering is an interoperability project and blockchain framework with a vision to improve Ethereum. Lots of interesting concepts and new developments ahead. Let’s see where it gets!