Hey there,

Over the past few months, we have been working with Polygon Labs to understand what has been cooking under the hood with the network. Today’s piece is the first in a series of articles exploring the evolution of the network.

As always, we retained editorial rights. So, instead of a piece endorsing the network, you will likely embark on a journey through Polygon’s positioning in 2021, the market landscape, and how it has since evolved. In the piece, we explore what the AggLayer and CDK are and their implications for the web. The intent is to invite healthy debate and critique about how the network could evolve.

As always, if you are a founder looking to use Polygon CDK (Chain Development Kit), drop details here. We’d happily facilitate introductions and help you get from zero to one. On to the story itself now.

The article may break in your email client. Click here to read it directly on our website.

Joel

It was March 2020. Markets have experienced a black swan event in the form of worldwide lockdowns induced by the pandemic. ‘Unprecedented’ was one of the more frequently used words in discourse. The Fed placed a massive put as the world of finance begins to reel from COVID shock. In this environment, BTC, ETH, and a handful of other tokens experienced the run of their lifetimes. But more than prices, a seismic technological shift changed the way Ethereum would scale.

Ethereum was far from solving its scalability problem in 2020. This is when Polygon (known as Matic Network then) launched, one of the ways applications using the Ethereum Virtual Machine (EVM) could scale. Through 2020 and early 2021, Polygon was one of the very few solutions that offered the same quality applications on Ethereum (such as Aave) at trivial fees. This made Polygon stand out from the rest of the Ethereum scaling solutions.

From 2021 to 2023, the competition for scaling Ethereum increased significantly. Optimistic rollups (ORs) launched working products before any Zero Knowledge rollups (ZKRs). ORs were less complex to design than ZKRs. Performant ZKRs fully compatible with the EVM were thought to be years away. Bear with me here; I will get into ORs, ZKRs, and the difference later in the article. Although ORs are often considered an intermediate scaling option, they have amassed users and capital. In contrast, ZKRs have been lacklustre. This can be observed in the total value locked (TVL) in both solutions.

Value locked in ORs is ~$35 billion, whereas ZKRs have $3.7 billion locked.

As ORs gained popularity with incentives and new narratives, users moved assets to these new chains. Polygon, which was one of the first working solutions in the form of a sidechain, extended its focus to a longer-term ZK solution. Just like the rest of ZK and other scaling solutions, the network ceded ground to ORs. All ZKRs took time to go live. Naturally, incentives were delayed. By the time ZKRs launched, ORs were well established and had captured users’ attention.

Moreover, once they launched, there was little differentiation between them and ORs in terms of UX. Getting users’ attention was an uphill battle for ZKRs. To do so, ZKRs needed to have a hook for the users that ORUs don’t have. In addition, all ORs (and new ZKRs) offered users and developers incentives.

Polygon Labs’ solutions were diverse, with a PoS chain, multiple upcoming ZKR implementations, and development kits. Looking at Polygon from the outside was confusing and overwhelming. To me, it always seemed like they were trying everything.

On how Polygon seemed to fit every narrative

After diving deeper, though, I have realised how the pieces align. This article presents how the Polygon ecosystem has evolved and what to expect in the coming months.

The need for speed

Everyone remembers the Crypto Kitties era: a harmless experiment to bring a sense of community to Ethereum users by allowing them to breed and trade unique digital kittens. The prices of some kitties exceeded $100k in December 2017, which accounted for over 10% of the gas consumption on Ethereum. The fervour reached such heights that even the BBC was compelled to write a story. Obviously, amidst high prices and demand, Ethereum became unusable for average users due to high gas fees.

Just as a refresher— think of the gas situation as similar to that of a city with limited fuel resources and free markets. When citizens know that the supply is limited and their commute is inevitable, their bids on fuel increase, which sends prices higher. Like fuel consumed for travel, all Ethereum operations consume gas. Fuel is priced in fiat currencies like AED, INR, USD, and so on, while gas is priced in gwei (a nano ETH). During times of congestion, more people want to get into limited blockspace, and they are willing to pay higher prices for gas.

In 2017, it was clear that Ethereum, the world computer, needed a massive scaling overhaul so everyone could use it, and it was a major research problem. A natural solution arose from considering the following question: If one chain does 12 transactions per second, can we split this chain into multiple independent chains? If there are 100 chains, they all will produce 12 transactions per second, giving us a total of 1200 transactions per second. As the number of chains increases, so does the possibility to scale.

This is the broad idea of ‘sharding’ the base chain. A shard is basically a small chain that runs in parallel with other small chains. However, making these independent shards a part of one Ethereum by ensuring seamless interoperability is as difficult as scaling itself. For the sake of providing an example, how these chains interact with one another matters a lot when users need to execute transactions involving applications on different shards. This would mean breaking the validator set into multiple sets that would verify different chains.

While sharding was the ultimate solution, Ethereum would take multiple necessary intermediate steps that would act like building blocks of the sharding architecture. These intermediate steps were state channels, Plasma, et cetera.

Meanwhile, a different school of thought started developing. What if, instead of breaking down the validator set, we reduced the computational burden on them? This is exactly what rollups proposed to do. Instead of using Ethereum’s resources (gas) for every transaction, rollups use them to post bundles of transactions.

So, the computations needed for making the state changes (think of Ethereum’s state as every account’s balance, smart contracts, and externally owned accounts) are performed on a different layer than Ethereum, saving Ethereum’s resources. Instead of directly interacting with millions of consumers, Ethereum now has to deal with a handful of rollups that interact with tens of millions of users. Rollups help Ethereum go from B2C to B2B.

Of course, it is not as easy. When Ethereum validators no longer perform the computation, how do users know whoever is performing them is doing so with honesty? When you and I use Ethereum, we trust Ethereum’s validators. Of course, we can run our own nodes to check if the validators are executing our transactions correctly, but we don’t. So, we end up trusting the validators.

When you transfer an asset or swap it for another, validators are the ones making changes, like adding and subtracting balances of an account, to the state of Ethereum. When this computation is taken off-chain, users are essentially placing their trust in whoever operates that layer. Now, if we are saying these layers are mere extensions of Ethereum, users should not be forced to trust anybody but Ethereum validators. It is that layer’s responsibility to somehow prove that what they do is per Ethereum’s rules.

How different rollups perform computations and prove them to Ethereum largely determines their type. ORs give Ethereum results of their computation along with data necessary to replay transactions (the results of which they post on Ethereum). Until someone challenges the execution, whatever is submitted by optimistic rollups is assumed to be correct, hence the name optimistic.

Verifiers are typically given a seven-day period to challenge the results. Readers should note that except for Optimism, no other OR has implemented fraud-proof as of June 2024. Optimism has stage 1 fault or fraud proofs, which means that the training wheels are still intact, in that the security council can intervene if the fault-proof system goes down for any reason.

The other major category is ZKRs. Zero-knowledge tech allows us to prove anything without disclosing details of what we are trying to prove. For example, let’s say Sid wants to prove to Joel that he knows the combination of a vault Joel bought for them. However, he doesn’t want to reveal the combination because he fears their communication may be intercepted. How can he do that?

Well, Joel can put things (like messages on a piece of paper) inside the vault that Sid doesn’t know about. Later, if Sid can match what Joel placed in the vault, then Joel can confirm that Sid knows the combination without Sid having to reveal the combination itself. From a 10,000-foot view, this is how zero-knowledge proofs work. Instead of posting all the data for verifiers to be able to replay all the transactions, they submit proofs of execution to Ethereum.

Ethereum, the anchor of L2s or scaling layers

Ethereum, as we know it today, grew with protocols and applications. Some projects adapted as Ethereum evolved, while others were left behind. The story of Matic Network, now known as Polygon, fits that bill well. As Ethereum’s sun shined, Polygon’s planet thrived.

The cryptoassets and blockchain landscape has changed a lot since the early days of 2015 when Ethereum launched. Ethereum’s scaling plans took a significant turn in late 2020 when Vitalik wrote the rollup-centric Ethereum post. Ethereum’s development arc, in particular, can be split into two eras: before rollups and after rollups. If Ethereum is your anchor, you have to move with it. Polygon ensured that it adapted as the Ethereum roadmap changed.

It was clear early on that Ethereum would need to scale massively to become the world computer. Before understanding how Ethereum scaling evolved, we should revisit what scaling, in general, means. Scaling is about scaling Ethereum’s security guarantees. Whatever way we adopt should rely on Ethereum’s security in some way. That is, Ethereum L1 should be able to have a final say on the state of the scaling layer.

Several approaches, such as state channels, plasma, sidechains, and sharding, were proposed. They were in different phases of development before Ethereum decided to favour rollups.

Plasma and sidechains are somewhat similar approaches. Plasma is a separate chain where transactions are executed, and compressed data is periodically posted on Ethereum. Plasma chains pose a data availability challenge.

Data availability (DA) solutions typically separate consensus data from transaction data. As the size of the chain grows, storing and processing the state becomes a challenge. DA solutions address the scalability issues by introducing a separation between the consensus layer and the data layer. The consensus layer handles the ordering and integrity of transactions, whereas the data layer stores transaction data and state updates.

All the historical data of plasma chains is only available with the plasma operators and not with Ethereum full nodes. Full nodes are only aware of the compressed data. Thus, users have to trust operators to maintain data availability. Security on the plasma chain relies on the security of the root chain (Ethereum). Fraud proofs and challenges are resolved as per the rules of the root chain.

Sidechains are separate chains with their own consensus and validator set. They periodically post data on Ethereum. The key difference between the two is having a separate validator set based on a different consensus. Users have to trust sidechain validators to maintain the integrity of their transactions.

ORs are an improvement over Plasma and sidechains in the following ways:

1. Unlike Plasma, they avoid data availability issues by posting all the data on Ethereum.
2. Unlike Plasma and sidechains, users don’t have to expand to bigger trust assumptions; that is, they don’t have to trust a new set of operators or validators.

This is why rollups were accepted as a superior form of scaling. One may say they are an improved version of Plasma.

State channels were a solution similar to Bitcoin’s Lightning Network. Here’s an analogy for state channels. Two friends, Sid and Joel, run their joints for sandwiches and coffee, respectively, right next to each other. They like the idea of cross-selling and decide to club their menu as their patrons often want both. So, when a patron orders a sandwich at Joel’s joint, he just passes on the order to Sid, who serves the sandwich.

However, patrons pay only where they dine even though their order may be from the other restaurant. Both Sid and Joel keep a tab on how many patrons from the other joint ordered from them. Instead of settling the tab every time they receive the money from the customer, they do it at the end of the day.

Sid and Joel both keep a tab of sandwiches and coffees they serve at the other joint, which is equivalent to keeping a tab of the state. Throughout the day, if Joel served $200 worth of coffee to Sid’s customers and Sid served $250 worth of sandwiches to Joel’s customers, at the end of the day, Joel pays Sid $50, and the tab is settled. This is much more efficient than sharing revenue after every cross-sale. This tab that Sid and Joel have opened with one another is like a channel between two nodes or accounts.

At a high level, two users or applications can open an off-chain channel, execute transactions, and settle on-chain when closing the channel. This approach requires opening several channels between users (opening and closing a channel is an on-chain transaction) and is difficult to scale. As of June 2024, the Lightning Network’s capacity is only about 5K BTC. In a rough sense, that means it can’t handle much more than 5K BTC going back and forth simultaneously.

Polygon was one of the very early scaling solutions that launched its mainnet. Polygon’s development, both technical and in terms of the ecosystem, has four eras:

1. Matic Network
2. Polygon expansion
3. The ZK embrace
4. Aggregate it all

Matic Network

Matic Network was a combination of the Plasma and sidechain approaches. Validators staked MATIC tokens as collateral to validate transactions and secure the chain. As an additional security measure, checkpoints (snapshots of the chain’s state) were submitted to Ethereum. So, once a checkpoint was final on Ethereum, this state would freeze on the Matic Network. After this, blocks could not be contested and re-organised.

In 2021, Matic Network rebranded to Polygon, but it was more than just a name change. While Matic Network was a single-chain effort to scale Ethereum, Polygon moved to a multi-chain ecosystem. In line with this vision of attacking scaling from multiple angles, Polygon launched a software development kit (SDK) that made it easy for developers to port over their applications to Polygon.

A few months after Aave deployed on Polygon in April 2021, the TVL jumped from ~$150 million to nearly $10 billion. At the time, Polygon dominated most chains in metrics like number of active users and transactions. Even as of June 2024, Polygon PoS dominates in terms of the number of daily active users. Readers must take this with a grain of salt since there’s no way to know the real number of active users. Data providers typically track active addresses. One address doesn’t necessarily mean one user since one user may have (almost always has) multiple addresses.

Source – Polygon Blog

What did the SDK do exactly? SDKs provide building blocks for a larger piece of software – in this case, different kinds of chains. Polygon SDK provided tools to build two types of chains:

1. Standalone chains with their own validator sets
2. Chains that rely on Ethereum for security (L2s)

Sidechains and enterprise chains that demand more control over how things work (who can participate, who can run nodes, etc.) opt for the first option. In contrast, young projects that lack resources or are okay with Ethereum’s security and consensus rules choose the second option.

The ZK Embrace

As Polygon’s PoS chain grew and attracted more users, Polygon Labs explored more ways to scale Ethereum. In 2021, when ZKRs were pretty much under development, Polygon Labs allocated a $1 billion treasury towards ZK development. They acquired Hermez Network, Miden, and Mir Protocol. Although all these teams fell under the broad umbrella of ZK, they served special purposes.

Hermez focused on building a live zkEVM, Mir focused on building a leading proving technology in the industry, used by many other ZK teams aiming to create a zkVM rollup with client-side proving—ZK in your pocket.

When Polygon Labs went all in on ZK, many believed that ZK tech wouldn’t be ready for another three to five years. On the other hand, OR production was just around the corner, although without fraud proofs. This begs the question of why Polygon Labs went after something that would take much longer instead of just deploying the OR solution first and working on ZK simultaneously.
The answer lies in two parts:

1. ORs would have been an incremental solution over Polygon PoS in terms of scalability and security.
2. ZKRs were agreed upon as the ultimate solution that would win over ORUs.

Yes, as long as ORs have fraud proofs, their security guarantees are better than sidechains (like Polygon PoS), but costs don’t change that much for the end user. It is important to note that fraud proofs are not live for any ORs, except for Optimism, yet. Optimism began testing fraud proofs in March 2024. So, there is still time before all ORs have fraud proofs live on their respective mainnets. Polygon PoS had already handled millions of transactions daily.

So, if you think in terms of a barbell strategy, where risk is typically distributed by having very high and very low-risk instruments in the portfolio, this is how Polygon technology looks.

Recall the difference between ORs and ZKRs and how the former must submit all the transaction data on Ethereum. As the number of transactions on ORs increases, the amount of data they must post on Ethereum increases almost linearly. However, the size of the ZK proof increases quasilinearly. So, as the number of transactions increases, ZKRs are significantly more efficient than ORs.

This gives ZKRs an advantage over ORs. But the number of people who sufficiently understood ZK tech to create an infrastructure layer that might handle hundreds of billions of dollars was probably in the three digits. ZK tech needed time to mature. Acquiring teams working on ZK gave Polygon Labs a tactical advantage that few in the industry enjoy.

Rollups and trains

Among the most important Polygon technology is zkEVM. Why? Let’s say old blockchains are like old engines and train sets. They are slow and have low capacity, so they are expensive. But since they have been around for a while, they’ve built a network of tracks through many areas. Think of the EVM as this track network; it’s among the most widely adopted standards and thus has the tooling to facilitate its use. Continued usage of these trains is impossible because they are too slow and expensive.

ORs resemble an improved version of this train, using the same tracks as the earlier train sets but 10X to 100X faster. Eventually, however, this will be insufficient. We need another few orders of magnitude of speed and capacity to ensure quick and cheap travel. ZK rollups aim to deliver that. But the problem is these train sets don’t use the old track network; they need some modifications. zkEVM allows ZK rollups to be used with the existing EVM tooling.

From the safety point of view, ORs cannot do much to prevent accidents from happening. They run on the assumption that they don’t happen. Fraud proofs are like Nolan films. They cannot prevent accidents, but give the ability to the system to go back in time and fix the problem before the accident takes place. But the ZK tech, on the other hand, can prevent accidents from happening.

The EVM equivalence problem

Let us dive a little deeper into the whole zkEVM business. The train-tracks analogy explains why we need compatibility with the EVM. However, this compatibility is not 0 and 1 but can be seen as a spectrum. Prover is a critical component of the ZK machinery. It proves that an event took place without revealing facts about events. For example, if a protocol wants to confirm whether a user possesses certain wealth, think of ZK prover as something that can do this without revealing the user’s wealth.

Why get into the ZK stuff at all? SNARK or STARK technology allows chains to create cryptographic proofs. Both are ways of generating proofs that are easy to verify. These proofs can be used to demonstrate that transactions took place on a certain chain. If we want to scale Ethereum, we can use this tech to prove that Ethereum-like transactions took place on some layer. These layers are rollups, and ZK tech allows rollups to compress transaction data by order of magnitude and thus scale Ethereum. If the goal is to scale Ethereum, then the goal of zkEVMs is to prove the execution in a way that the execution layer of Ethereum can verify.

When a rollup is fully Ethereum equivalent, it can reuse things like Ethereum’s existing clients. Fully Ethereum equivalent means that the rollup maintains full compatibility with Ethereum smart contracts and the entire Ethereum ecosystem. For example, the addresses are the same, wallets like MetaMask can be used on the rollup, and so on.

It is challenging to prove things in a way that Ethereum understands. When Ethereum was designed, ZK friendliness was not among the factors to be considered. This is why some parts of Ethereum are computationally intensive for a ZK proof. This means the time and costs needed to generate these proofs increase. Thus, a proving system is bulky if it has to use Ethereum as is. On the other hand, a proving system can be relatively lightweight, but it has to build its pieces to fit itself with Ethereum.

As a result, different zkEVMs make trade-offs between how easy it is to use the existing tooling versus the cost and difficulty of proving. Vitalik maps the existing zkEVMs in a blog post along these lines. I will spare you further details (we will cover this in future articles), but here are different types of zkEVMs (or provers). Type 1 is the most compatible and least performant prover, and type 4 is the least compatible but most performant.

• Type 1 – These zkEVMs are fully Ethereum equivalent.
• Type 2 – These are EVM equivalent but not Ethereum equivalent. This means minor modifications to Ethereum are needed to make proof generation easier.
• Type 2.5 – These are similar to Type 2 except for gas costs. Not every operation has the same difficulty level when it comes to ZK proving them. This type of zkEVMs increases the gas costs of certain operations, which signals developers to avoid these operations.
• Type 3 – This kind of zkEVMs modifies Ethereum to improve prover times, sacrificing exact equivalence in the process.
• Type 4 – This approach compiles the source code written in Solidity or Vyper (languages for Ethereum) into a different language. This type of prover completely drops overhead from Ethereum and makes the prover the lightest among the types. The drawback here is that it looks quite different from Ethereum. Right from the addresses, everything is different. If you’ve noticed, Starknet requires different wallets like Argent. Even the addresses look different from Ethereum.

Source – Vitalik’s blog post

Polygon Labs recently released an upgrade that introduced a new era of proving technology with a type 1 prover. Using type 1 means that any EVM chain, whether newly spun up with Polygon CDK or a standalone layer 1, can become an Ethereum-equivalent ZK L2.

Aggregate it all

No EVM chain is ready to take on the load of the internet. It is not even close. This is why we moved to L2s. Now, there are several L2s on the market, but the number of users and capital did not increase with the same vigour. Liquidity, users, value locked — almost everything that makes a chain valuable — got fragmented across multiple L2s. In a way, L1s and L2s pose a paradox: The base layer can’t scale as much, and multiple chains threaten dilution.

A solution to this paradox is a service that allows the seamless flow of assets and information between multiple L1s and L2s—but, crucially, without rent-seeking or imposing extractive fees and ensuring that these chains retain their sovereignty.

The AggLayer has been designed to do just that.

It’s a solution that allows for secure, fast cross-chain interoperability. Connected chains share liquidity and state. Before the AggLayer, sending assets between chains required either the trust assumption and wrapped assets of some third-party bridge service or the fee-intensive, bad UX of withdrawing from an L2 to Ethereum and then bridging to the desired chain.

The AggLayer eliminates this friction in cross-chain transactions and creates a web of interoperable chains. But how? We will get into the details of how the AggLayer works in later articles, but here are the broad strokes. Currently, L2s are different contracts on Ethereum. Transferring funds from one L2 to another involves three separate security zones – two L2 contracts and Ethereum.

In the case of a cross-chain transfer, a security zone is part of the infrastructure where validator sets intersect. Validity checks and forwarding transactions occur at these junctions. The result of different security zones is that when you sign a transaction to transfer assets from one L2 to another, Ethereum is involved in the transfer. In the background, assets get sent to Ethereum from the source L2, claimed on Ethereum, and deposited to the destination L2. These are three different orders or transactions or intentions.

With the AggLayer, the entire transfer is tackled in one click. The AggLayer has a single unified bridge contract on Ethereum, to which any chain can connect. So Ethereum sees one contract, but the AggLayer sees many different chains. A ZK proof called “pessimistic proof” keeps the total funds locked on the unified bridge safe by treating every connected chain suspiciously. In other words, the pessimistic proof is a cryptographic guarantee of safety that means one chain cannot rug the entire bridge.

With the AggLayer, there is no need to involve Ethereum when transferring assets from one L2 to another, because all the L2s share state and liquidity. The three transactions or intentions mentioned above are lumped into one.

The endgame for the AggLayer looks like this:

Sid wants to buy some NFT on chain A but has all his assets on chain B. He connects his Polygon wallet, presses the Buy button, and gets the NFT in his wallet. The bridging of assets from chain B to A before the purchase is completely abstracted away.

The advantages of the AggLayer are the following:

1. It turns the zero-sum game of liquidity and user fragmentation into a more collaborative approach among chains.
2. Chains benefit from security and tooling while maintaining sovereignty, without posting bonds in the earlier models like Polkadot
3. It allows chains to interact with each other at a latency lower than that of Ethereum’s
4. It brings fungibility to bridged assets and improves the UX. Everything happens within a single bridge contract, so there’s no need for different versions of the wrapped assets to exist.
5. Better UX for users as bridging is abstracted away.

Currently, rollups and validiums post their chain states to Ethereum individually. The AggLayer aggregates chain states and submits everything to Ethereum in a single proof, which helps save the protocols gas costs.

The L2 space has a lot of competition. Arbitrum, Optimism, Polygon, Scroll, Starknet, zkSync, and so on are all competing against each other. You can, of course, compete, but finding ways to collaborate is often a better strategy, given that we are still early in the crypto adoption cycle if we consider the scale of the internet.

Even research based on game theory suggests that collaboration is almost always the best way to survive and grow. The AggLayer is a positive sum in that it is

1. Credibly neutral (it’s not biased toward any specific project; any chain can connect) and
2. Unifies liquidity and state, allowing new chains to bootstrap users and liquidity of any connected chain.

Whereas other multichain ecosystems impose fee extraction on chains (and therefore, downstream, on the users of these chains), the AggLayer is designed to be as minimal as possible, while providing secure, low-latency cross-chain interoperability.

Recently, there’s been a trend of apps launching appchains and appchains becoming general purpose. Aevo, dYdX, and Osmosis are the leading examples of this trend. Jon Charbonneau points out the following:

• Apps want flexibility and sovereignty, so they launch their appchain.
• The appchain sees growth in users and activity and wants to capture more value by allowing others to build ‘on top’.
• Then, the appchain becomes a general-purpose chain.

Source – X (@jon_charb and @LanrayIge)

As Lanre mentions, the market seems to value apps becoming appchains and then becoming general-purpose chains. If I extend this trend to its extreme, we will be left with several general-purpose chains. While several chains can exist, liquidity and users remain constant and are shared across those chains. The higher the number of chains, the worse the overall crypto UX.

As we argued previously, this is because liquidity and users are shared across the number of L2s, leading to poor liquidity on many L2s. There must be a solution that brings all of this together, and the AggLayer is a step in the right direction. There is a multitude of reasons for apps to have dedicated blockspace.

For example, a trading app shouldn’t have to compete for precious blockspace when there’s a popular NFT mint on the same chain. Running liquidations or closing positions shouldn’t be impacted (in terms of fees or throughput) due to other activity on the chain. But if many applications go in the direction of appchains, they run the risk of fragmentation.

So, the AggLayer brings about the integration of these different chains. It is a simple solution that allows a gaming chain and a DeFi chain to avoid direct competition for blockspace but enables cross-chain interoperability nevertheless.

On the one hand, the AggLayer can help unify liquidity across chains, and on the other, Polygon CDK can be used to spin up chains.

Polygon CDK is a collection of open-source technology that has evolved over the years. It started as an SDK and transitioned into supernets before assuming its present form. Polygon CDK allows developers to build two kinds of L2s: rollups and validiums.

Polygon CDK’s most important attribute is its flexibility. Developers building a new chain (L2) can customise different options across four parameters – VM, mode, DA, and gas token.

• A VM is the environment in which transaction executions are carried out. Polygon CDK will allow developers to pick from different VMs, such as zkEVM.
• Mode refers to the choice between validium or rollup. The difference between the two lies in what kind of data they post on Ethereum. Rollups post the compressed transaction data on Ethereum, lending more security to the rollup mode. Validiums, on the other hand, post this data on a separate layer, such as their own DA layer.
• DA is a critical aspect of scaling in which the consensus layer is separated from the data layer. Full nodes on chains like Ethereum and Bitcoin store all the data so that they can independently verify all transactions. Polygon CDK allows chains to build their own customised DA committee or use DA solutions like Celestia.
• Gas token customisation refers to the ability of chains to collect gas fees in a token of their choice. For example, Polygon CDK gives developers the freedom to make users pay for gas using their chain’s native token instead of ETH.
• The sequencer, or the operator deciding the order of transactions and executing them, is currently centralised. In the future, other teams or individuals may be able to run the sequencer.

Besides this modularity and sovereignty, building using CDK has other advantages. Polygon CDK gives chains an opt-in functionality that allows them to use the single, unified bridge contract of the AggLayer. With this, there’s no need to have different versions of the wrapped assets. This improves the UX of CDK-based appchains.

Note that the unified bridge contract of the AggLayer lends this capability to assets. Chains built using CDK have to “opt-in” to use this functionality. They can choose to have their separate bridge and maintain different assets. While other solutions like Arbitrum have USDC, USDC.e, and other variants of USDC. Often, users must swap between these variants while bridging back to the mainnet.

For example, with Polygon CDK, an appchain for lending plus derivatives can pick a roll-up mode (where all data is posted on Ethereum), with Polygon zkEVM as the virtual machine (VM), and collect gas in its native token instead of ETH. However, an NFT-specific appchain may go for the validium mode, and it can choose to post data on the likes of Celestia or a separate data availability committee (DAC) with ETH as its gas token.

The sequencer is currently centralised (as it is across all major ZK rollups). Eventually, CDK chains will be able to use a shared sequencer if they want. It’s important to note that aggregation is not incompatible with modularity or sovereignty.

Source – Polygon Blog

As of March 2024, nine teams have built chains using Polygon CDK, and twenty more are already in various stages of development. The CDK framework is completely open source, and anyone can build a chain using the same.

The MATIC token upgrade to POL is critically important. Currently, MATIC secures the Polygon PoS chain. The architecture of the proposed Staking Hub hasn’t been made available yet, but proposals suggest that POL will play an integral part.

The Ecosystem

Note that this is just a representation of the Polygon ecosystem. It is not meant to be exhaustive.

Developers are the lifeblood of any ecosystem. Developer activity is often the precursor to user activity on a chain. Despite the market’s downturn through 2022 and for the better part of 2023, the Polygon ecosystem is second only to Ethereum regarding the number of new developers joining.

Source – Electric Capital

If developers are leading indicators of what is to come, users are a feedback loop for chains. User activity remains on the higher side for Polygon. The only EVM chain with higher user activity than Polygon is the BNB chain. Note that Polygon here refers only to Polygon PoS. As more chains connect to the AggLayer and/or use the CDK, this figure is likely to be significantly higher in the future. Ultimately, developers are looking to customise networks to suit their needs. And that is what Polygon is optimising for with the CDK.

Data until Apr 2024

DEX activity remains on the lower side for Polygon in comparison to other L2s or chains like Solana.

Interestingly, Quickswap is the leading DEX with ~60% of the volume. Typically, Uniswap dominates the volume across EVM chains.

Source – DefiLlama (data until Apr 2024)

The following chart compares DEX volume across different EVM chains. Arbitrum is the dominant leader, followed by Polygon. Since incentives drive everything in crypto, it is important to mention that while Arbitrum offers trading incentives to DEX protocols and users, Polygon stopped offering incentives in 2022. The volume remains largely organic.

Data until Apr 2024

Total value locked (TVL) is not a great metric to gauge the success of a chain, as it doesn’t tell you the quality of the capital. That is, most of the capital in crypto can be considered mercenary. Capital flows where incentives are. Protocols either offer incentives or users sybil them in anticipation of airdrops. Still, a high or moderate TVL for a long time means users prefer the chain or protocol in some form. The following chart shows the weekly TVL of different L2s.

Data until Apr 2024

Most of the TVL in lending applications in Polygon comes from Aave. Aave constitutes a whopping 87% of the total lending TVL on Polygon.

Data until Apr 2024

In terms of NFT volume, the leading chains are Bitcoin and Ethereum, primarily because NFTs are priced in their native assets (BTC and ETH) and the liquidity of these assets is almost always the highest in the industry. When we look at the number of transactions, Polygon is ahead of its EVM peers.

Data until Apr 2024

Gaming has been a major contributor to the growth of the Polygon PoS. The number of unique addresses interacting with games on Polygon has become fivefold, from 80k to close to 400k since the start of 2024, and Matr1x and Sunflower Land have attracted over a million users over their lifetimes.

A major driver of this growth is Polygon Labs’ collaboration with Immutable. Immutable offers a suite of products for game developers, from NFT minting mechanisms to wallets to SDKs, which is everything that game developers need. It also offers all the blockchain-related support so that game developers can focus on the game side and not worry about the blockchain aspects of web3 games.

The ecosystem already has over 40 playable games, with several more in development. Immutable’s zkEVM, built using Polygon CDK, is live on the mainnet for early access. During this phase, custom smart contract deployment is restricted to a select group of game studios.

Beyond DeFi, Gaming, and NFTs

We often talk about how crypto doesn’t materially impact ‘normal’ lives. Decentralised physical infrastructure (DePIN) is an area where that is gradually changing. Blockchains are good at aligning incentives and ensuring they are delivered based on predecided agreements.

DePIN projects operate at the critical intersection of physical and digital realms. Typically, users help a network grow with some form of resources, and the network, in return, incentivises users via inflationary tokens and revenue from users. The sustainability of DePIN projects hinges on whether they attract fee-paying users.

Polygon significantly lags behind DePIN leader Solana in terms of DePIN-related transactions. For context, in February, Solana supported over 4 million DePIN-related transactions; by contrast, Polygon did ~39k.

DIMO, aka Digital Infrastructure for Moving Objects, is the clear leader on Polygon in terms of DePIN adoption metrics.

Data until Apr 2024

It enables moving objects to share data in a privacy-preserving manner. The first use case is for cars where drivers use DIMO devices and share data with stakeholders like manufacturers and policy issuers. Currently, almost 70k drivers use DIMO to share data with applications like marketplaces, insurance, and peer-to-peer ride sharing. In return, they get DIMO tokens.

Although its use started with cars, DIMO can expand to any moving object, including drones, and may find application in areas such as supply chain management, smart mobility, and autonomous vehicles.

Other DePIN projects on Polygon include the following:

• Fleek Network is a decentralised hosting platform that serves websites and web apps from a globally distributed network of nodes, providing fast, secure, and redundant access.
• GEODNET aims to improve GPS accuracy by building a decentralised real-time kinematics network and token incentives.
• Space and Time, which aims to create a global transparent data warehouse not owned by a single entity.
• XNET, which seeks to improve mobile connectivity.

As things stand, networks like Solana have a clear lead with DePin. Part of what is incentivising developers to build on Polygon in the near future is its EVM compatibility. The ability for a user to be paid in tokens and instantly access the number of applications built across the Ethereum network (and all of its chains) could be a strong draw. That said, it remains to be seen how this segment will evolve for Polygon. These are still early days.

Challenges

Naturally, all of these changes come with their fair share of trouble. Like any ecosystem constantly evolving into something larger, Polygon has its share of challenges. They are as follows.

Low frequency of proof submission

Finality on Polygon zkEVM can roughly be broken down into three stages -

1. Trusted state where transactions are final on L2
2. Virtual state where Ethereum receives transaction data from the L2
3. Consolidated state where Ethereum receives the proof that validates the data

For all practical purposes, users can keep interacting with the L2 applications after the first stage itself. But they need to wait if they desire Ethereum’s guarantees. Transactions on L2 are final on Ethereum only after the third state. Polygon zkEVM submits proofs to Ethereum roughly every 20 to 30 minutes, meaning users must trust the Polygon zkEVM sequencer for 20 to 30 minutes between the two batches.

Why don’t they just post batches more frequently? Each batch has a fixed cost amortised over the number of transactions. Submitting batches more frequently would mean increased fixed costs, which would get amortised over the same number of transactions, increasing the per-transaction cost.

If Polygon zkEVM (applicable for other rollups, too) needs to submit proofs on Ethereum more frequently, there has to be more activity on top, or the cost of submitting proofs needs to drop significantly. As ZK tech matures the proving costs will likely reduce, but at the moment, they remain high. Thus, rollups need more users to submit proofs to Ethereum more frequently and maintain low transaction costs.

Polygon PoS reorgs

Polygon was infamous for its constant reorgs. Although the risks have been mitigated to a large extent, they are not solved entirely. I will first explain why reorgs, in general, are common across chains and then address why Polygon faces this issue more frequently than other chains.

For chains like Bitcoin, many miners compete to find a new block. At times, more than one miner may succeed. Assume two miners find new blocks (#1000A and #1000B) at the same height of 1000. Due to propagation delays, some nodes will see block #1000A, and others will see block #1000B. Now, if a new block is found on top of block #1000B, the chain with block #1000B becomes the longest, and block #1000A is discarded or reorganised by the network.

Note that it is possible that a third block, #1000C, was found by another miner at the same height (1000) and the same miner or other miners building on this block found two more blocks (#1001 and #1002). In this case, both blocks #1000A and #1000B will be discarded, and #1000C will become part of the chain. Ethereum, too, faces reorgs, but the depth is rarely more than 1 block.

Polygon’s reorgs are more frequent because it uses two consensus protocols: Bor and Heimdall. Bor block producers sprint for efficiency, producing 16 blocks at a time and delivering them to Heimdall for validation. Missing a block from the previous producer or validator is not uncommon. When a validator misses the previous block producer’s sprint, up to 32 blocks (16 x 2) can get reorged. Polygon PoS has a block time of ~2 seconds, so 32 blocks will be ~1 minute. So what these reorgs mean is applications should not (cannot) assume finality for at least 1 minute for transactions like deposits.

Although Polygon has solved for deeper reorgs, reorgs up to 32 blocks are not unlikely to take place.

zkEVM Halts

Like most of the EVMs, Polygon zkEVM also has just one sequencer. Any bugs can result in unwarranted chain halts. Polygon zkEVM halted for about 10 hours between two batches, 2001558 and 2001559, on March 23. As of March 25, the team has yet to reveal the exact reason but has pointed out that the sequencer faced issues due to a reorg on Ethereum L1. It’s early days for zk tech, and Polygon zkEVM TVL is not that high. However, such halts would probably drive the capital away from the chain if they happened in later stages.

What’s Next

Over the course of this piece, we went on a journey of what has been and what is. We started by understanding how Polygon had a dominant position among EVM networks and the reason it is lagging on several fronts. In writing this piece, I was reminded of the phoenix, a Greek mythological character known for rising from ashes, growing up, and burning out. Repeatedly. Many technological advances experience similar cycles. We see new standards emerge, being adopted and becoming incumbent very fast. Attention trends towards what is new and hip until the incumbent out-innovates with its existing resources.

Polygon may be perceived as an incumbent throughout 2022. Its positioning was safe and comfortable, given the edge it had throughout DeFi summer. However, as optimism and arbitrum came into the market, developers had alternatives. Once meme coins on Solana took off, it gradually became the ‘safe’ option for developers looking for niche use cases – kind of like IBM, but for blockchains. In our research for this piece, we interacted with the crew at Polygon Labs multiple times and raised these concerns.

What emerged from an interaction is an understanding of how standards evolve. When a standard is in its growth phase, the incentive for everyone involved is to maximise its adoption. Polygon Labs did this with its BD efforts in 2021. The largest firms and enterprises were building on Polygon. As competition rises, the incentives for a network like Polygon swing in the other direction, towards the development of new solutions that help onboard more developers.

This is what Polygon has been focusing on over the last year, with its emphasis on the AggLayer and associated CDK. Markets tend not to price in technological changes until they are implemented and functional at scale. The charts we began this piece with reflect that.

While AggLayer and CDK help unify chains on top of Ethereum, Polygon also needs a number of break-out applications that make the case for the network at this point. For Solana, it was Jupiter and Tensor. Users going to Jupiter (to trade memes) or Tensor (to trade NFTs) got a taste of the network.

Applications that use CDKs (to scale) in retail environments are still being built because the underlying infrastructure (the AggLayer) has been evolving. So, you have multiple moving parts. If and when these break-out applications emerge, attention will flow back towards Polygon. Then, much like the phoenix, its rise will become apparent.

There is continuity in the phoenix’s evolution. Polygon builds off the lessons learned from being the network Aave and Uniswap scaled on. It has paid close attention to what developers need. However, its implementation will take time, which is where we are now.

Traditional sectors, such as computing, have seen a variation of this. Apple was early to the computing revolution, only to lose out to IBM and Windows in the 1980s. It took a decade, some corporate restructuring, and the return of Steve Jobs to make Apple a dominant force again.

In a market where attention constantly chases the hot new thing, Polygon’s evolution may go unnoticed. Still, as long as the tech delivers, it is only a matter of time before it is back at the centre of conversation. Until then, we have a front-row seat watching how this transition plays out.

Noting India’s chances in the T20I World Cup,
Saurabh Deshpande

Disclaimer：

1. This article is reprinted from [Decentralised.co], All copyrights belong to the original author [SAURABH DESHPANDE AND SIDDHARTH]. If there are objections to this reprint, please contact the Gate Learn team, and they will handle it promptly.
2. Liability Disclaimer: The views and opinions expressed in this article are solely those of the author and do not constitute any investment advice.
3. Translations of the article into other languages are done by the Gate Learn team. Unless mentioned, copying, distributing, or plagiarizing the translated articles is prohibited.