WOO Network: A Deep Dive into Different Layer2 Scaling Solutions
CMC Research

WOO Network: A Deep Dive into Different Layer2 Scaling Solutions

1 year ago

In the first column for CMC Research, WOO Network Research and Strategic Investment Team analyzes Layer 2 scaling solutions currently in the market.

WOO Network: A Deep Dive into Different Layer2 Scaling Solutions

Tabla de contenidos

Currently, Bitcoin can support ~5 transactions per second (TPS) on average, Ethereum at ~10 TPS, while the global payment network VISA processes more than 1,700 TPS. Users pay gas fees to use blockchain infrastructures, and these fees go toward paying each validator who works to incorporate new information into the blockchain. As a result, networks with a higher degree of decentralization charge more for gas as they require more validators.  On the other hand, networks with higher TPS will charge less gas fees per transaction, because fees are split between more users. Therefore, new blockchains must have higher TPS if we wish to maintain decentralization while enabling cheaper gas fees, to make them more accessible to a global user base, and this is where Layer 2 scaling solutions (L2) come into play. Simply put, L2 is analogous to the concept of batch-processing transactions in traditional banking, where payments are not settled immediately on the root chain (L1) to increase processing efficiency. In addition to speed, L2s establish a cost and security spectrum of decentralized computation environments which applications with innovative data processing needs may select from. A Decentralized Autonomous Organization (DAO) on Ethereum, for example, may allow its members to vote on L2 to save money while processing large transactions on L1 to utilize its full security and market liquidity.

The Lightning Network on Bitcoin, the first blockchain scaling solution, was built in 2017. Since then developers have proposed an increasing number of scaling solutions, including rollups, the primary scaling solution for Ethereum today, which were deployed on chain in late 2020 and early 2021. This article contains three sections. In the first section, we review the underlying technologies of L2. We look at how to evaluate these technologies in section 2. And finally, in section 3, we look at the development of L2 projects in the past 2 years, their adoption rates, and what ETH 2.0 might imply. We show that, as compared to the root chain, L2s are considerably underutilized despite the untapped potential. Furthermore, we believe that L2 security should focus on its implementation in addition to design, including centralized operators and upgrade keys.

Join us in showcasing the cryptocurrency revolution, one newsletter at a time. Subscribe now to get daily news and market updates right to your inbox, along with our millions of other subscribers (that’s right, millions love us!) — what are you waiting for?

1. Layer 2 solutions

Currently, there are three types of mainstream scaling solutions on Ethereum: state channels, plasma, and rollups.

1.1 State channels


In the world of scaling solutions, state channels are the earliest and structurally the simplest. A state refers to database content, such as transactions recorded in blocks. In this design, Intermediate state changes, such as new transactions, are stuck to off-chain “state channels” which then submit only the final state back online. State channels thus save gas fees because they move computation and irrelevant middle-state data off L1.

Imagine two players playing dice and betting some asset on the blockchain. This is how they could utilize the state channel to save money on a multi-round game:

1. Part of the blockchain state is locked:

The relevant assets (=state) are locked between the two players so that they both have to agree on the next transaction for it to happen on these assets. In addition, the smart contract needs to have some sort of mechanism to protect a player’s asset from being frozen if the other party drops offline for a long period of time.

2. Participants update the state amongst themselves:

The two players play dice and sign transactions that could be submitted to the blockchain, but they only send the signed transactions to each other, delaying the on-chain settlement. Here, some mechanisms might be implemented to make sure a third party can execute the transactions if one player goes offline. In addition, an on-chain mechanism must allow later signed transactions to negate the previous transactions, so that if Player A was winning but starts losing, they can’t submit an intermediate transaction to gain profit. This could be done by a Hash Time-Locked Contract (HTLC), where submitted payments are open for a challenge for a period of time before getting settled, so that Player B may challenge with a later transaction.

3. Participants agree on & submit the final state to the blockchain:

Finally when the game ends, both players agree on the final state of their assets and submit one transaction on-chain, closing the state channel and unlocking the assets (=state, but probably in a different distribution than when it started).

All the rules involved in each step described above could be enforced by on-chain smart contracts. Just like any safety mechanism on the blockchain, the point is if the mechanism is robustly designed, they should never be exploited unless there is an unexpected emergency.

Pros & Cons

From the above implementation, we can see that state channels have clear advantages and disadvantages. On one hand, they can basically scale infinitely, and support micropayments for any DApps that might want to implement a pay-as-you-go service. Also, it provides instant subjective settlement as transactions could be submitted at any time. Participants don’t need to wait for block confirmation and they are limited only by the speed at which they can sign and exchange messages. Finally, they also provide some inherent privacy.

On the other hand, because all parties have to agree on a locked state and open a channel together, state channels can’t support open participation. For instance, users can’t send funds to people who are not “in” the channel; they also can’t support activities involving objects without a clear logical owner, like Uniswap. Also, opening channels requires a lot of capital to be locked up, especially if we were to conduct complex activities offline without clear expectations of the transaction amount, making them capital inefficient. It also requires liveliness, which means participants have to constantly check L1 to see if someone has submitted an intermediate transaction, either by themselves or with a third party. Channels also require liveliness, maybe in the form of a third-party watch tower, to monitor L1 and/or submit transactions to L1. Finally, because of closed participation and the locking of assets, they usually only stay open for a short period of time before settlement.

Use Case

The most popular project that uses state channels is the Lightning Network on top of Bitcoin. With a whitepaper written by Joseph Poon and Thaddeus Dryja in 2016, the first transaction happened on the mainnet in May 2017. The Lightning labs, founded in 2016 by Elizabeth Stark and Olaoluwa Osuntokun, are developing the software that powers the Lightning Network, making it more accessible.

The basic idea of Lightning Network is that it forms a network of bidirectional payment channels, a subset of state channels with limited functionalities, where each node can be connected to multiple payment channels. And because nodes themselves can “push” liquidity from one side to another, or “across channels”, without losing value, the network can route payment across nodes/channels. The nodes along the path are not trusted, instead, payment is enforced with a script that enforces atomicity (either the entire payment succeeds or fails) via time-locks. And although the middle routers aren’t losing value from acting as a connection, they might be making themselves less flexible as liquidity is moved around. Thus, they might charge routing fees. We illustrate this with a transaction through a simple network of 3 nodes, 2 channels below.

Imagine if A wants to send C 4 BTC through a payment network. A is not connected to C but they are both connected to B. A can then send B 4 BTC, and B sends C 4 BTC through another channel. After the transaction B still does have 15 BTC in total, but now they have limited ability to route payments towards C. They can choose to either take payments routed from C, or close and reopen a channel when the liquidity is drained, which costs money, so they may charge for this transaction. Note that in this scenario, the transaction amount is already limited by the least liquidity in the channels, which is 5 BTC.

According to 1ML, the Lightning Network currently has 4,652 BTC (0.02% of the total) locked on the network, 17,820 nodes, and 86,634 channels. The average node capacity is 0.263 BTC, with an average channel capacity of 0.052 BTC (as of 09/03/22). Although there are many nodes in the network, the network is still centralized if we look at its liquidity distribution. Currently, the biggest five nodes are run by Bitfinex Node #1 (552 BTC), ACINQ (364 BTC), Bitfinex Node #2 (352 BTC), River Financial (223 BTC), and Kraken (198 BTC), together they control 36% of the liquidity. Zabka et al. measured the centrality of the Lightning network by betweenness centrality, the node’s centrality based on how many shortest paths traverse it, in a paper published in 2022. And they observed an increase in the Gini coefficient of from 81.5% to 91.9% from 2019 to 2021. This indicates that routing paths may indeed be concentrated to a small subset of nodes. On the other hand, Lightning Network has very low fees: currently, the median base fee is ~1 satoshi (~$0.0002), with a median fee rate of 0.0027%. This might be good for the users, but people operating smaller nodes with less traffic might not be making money, from the high costs of running a node and the channel opening/closing fees. Another reason why Lightning Network might be centralized. Centrality is not only a problem because we hope L2s can inherit the decentralized property of L1s, but may also influence the efficiency of the network and make it more vulnerable to attack with central points of failure. This problem might only be solved by making network participation more accessible and incentivized.
Now we can look at the adoption of Lightning Network: the usage of the network has been steadily growing since it went live. In terms of BTC, the network experienced an 800% increase in TVL in February 2019, reaching 1,000 BTC in March of that year. Another 400% jump in capacity occurred in Q3 2021, bringing the TVL to nearly 4,000 BTC. In addition to the increase caused by capital attracted during crypto bull markets, the number of users has also increased with the adoption of Chivo, Paxful, Cashapp, and many other wallets. These apps enabled users to create and interact with other lightning wallets, making it easier to utilize Lightning Network. The number of users grew to over 80 million in March 2022, according to Arcane Research. The number of payments roughly doubled over 2021, and the value of the payments has increased by more than 400% (measured in USD).

1.2 Plasma


Similar to state channels, plasma scales by enabling users to only supervise relevant state changes. The basic idea of plasma is a non-custodial side chain. We can think of a side chain as a separate blockchain that uses less validators, thus transaction fees are cheaper, and communicates to L1. Compared to blockchains with more validators, side chains are a direct trade-off between cost and security. However, side chains are “custodial”, meaning validators can collectively decide to commit fraud, making a transaction to transfer users’ funds to their wallet on L1.

Going back to plasmas, they execute transactions off-chain while periodically publishing some data on-chain, making them non-custodial. According to the original Plasma whitepaper by Joseph Poon and Vitalik Buterin, a plasma chain forms a tree structure, as shown below.
Transactions are computed in a child chain (imagine a side chain), and the state is merkleized and committed to the parent blockchain, merkleized again and committed to its parent, and so on. The Merkle proofs submitted by the child chains do not allow complete reconstruction of the state of the child chain, but it allows efficient and secure verification of the transactions. To ensure security in an economical way, the parent chains do not check the validity of the committed data, instead, users can challenge the invalid state transition with a bond, and the loser in the dispute gets slashed. If the block submitted was indeed invalid, the block is rolled back and the block creator is penalized. In terms of disputes, the tree structure can be viewed as a “court system”, with the root chain the “supreme court”. This maximizes data availability and minimizes costs for uploading fraud proofs.

The issue here is that in order for a user to challenge the invalid block, they would require data from the parent chain, which validators may avoid by withholding invalid blocks. This is when a mass exit is needed: all child chain participants must exit the chain by a certain date. Mass exit guarantees that the Byzantine behavior of the Plasma chain does not impact one's assets beyond a significant time delay and halting the chain; it is also more economical than a dispute by throwing all current state data on L1.

In conclusion, Plasma uses fraud proofs to arbitrate disputes concerning the validity of state transitions and penalize bad behavior, enabled by data availability on L1. And when validators commit fraud by withholding data, users can securely move funds back to L1 in a mass exit. However, the original design of plasma was too complex to implement, so different simplified versions were designed for different purposes, including Plasma MVP, More Viable Plasma, Plasma cash, and many many more.

Pros and Cons

The key advantage of plasma over state channels is that it now supports open participation, which means that users can send assets to participants who were never part of the system before. It also has lower capital requirements and cannot be halted by uncooperating participants.

But by providing some data availability with each transaction, Plasma has a larger L1 footprint.  And with fraud proof mechanism comes a wait time for finality, and an expectation for liveliness to monitor any invalid blocks being submitted. Besides, in the event of a mass exit, users must provide their own data to prove ownership, and a large amount of funds will be locked up for the challenge period before being released on L1. Additionally, implementing EVM on plasma is hard because of the nuances in the implementation of the logic of mass exit.
Although this was thought to be the solution to the blockchain scaling problem at that time, the scaling technology was soon replaced by other ones. The OMG network which was building a Plasma scaling layer is now building Boba, an L2 using optimistic rollup. The optimistic rollup network Optimism was previously the Plasma Group. As of now, the only widely adopted project that uses Plasma is Polygon. However, Plasma did get people thinking about “parallel computation models” on a blockchain, where anyone can create a custom plasma chain for different use cases, and their activities might be computed in parallel, using L1 as the base data availability layer.

Use Case

Polygon was founded in 2017, and its mainnet was launched in 2019. The team just finished a $450M round of financing this February, led by Sequoia Capital India, with a $2 billion valuation. There are 37k+ dApps deployed on the network. And its token market cap is over $10 B (CMC, as of 3/20/23).

Polygon has a three-layer architecture: smart contracts on Ethereum, a Proof-of-Stake layer for mainnets consensus (Heimdall), and a block production layer (Bor). The Bor layer aggregates transactions into blocks, Heimdall layer validates them, aggregates blocks produced by Bor into a Merkle tree, and publishes the Merkle root periodically to the root chain. A validator who locks up MATIC participates in the network by running both a Heimdall validator and a Bor block producer. The smart contracts on Ethereum provide finality and validator management. Because Polygon uses a Plasma sidechain backed by Proof-of-Stake consensus, it can provide PoS security, Plasma security (mass exit guarantee, developers will need to write their own dispute conditions set), or hybrid security.

The network is open participation, any participant can become a validator by staking a MATIC token, but the number of validators is capped at 100, which is what they have right now. Looking at transaction data, Polygon has now processed over 2,000 M transactions, with an average transaction speed of 23.6 TPS, and a median gas price of 51.9 Gwei (< $0.01). The network currently hosts over 220 M unique addresses, after its exponential growth last year (Polyscan, as of 2/19/2023).

WOOFi is on Polygon.

1.3 Rollups


In contrast to state channels which move both data and computation off-chain, or plasma that submits merkelized proofs of computation on-chain, scale by handling transactions off of L1 while publishing compressed data to L1 such that the L2 state can always be reconstructed. The transactions are written as calldata on Ethereum, ensuring complete data availability on-chain. But when a validator of L2 rollup posts on-chain an assertion that “rolls up” all of the calls and their results into a single L1 transaction, how do we know the assertion is correct? That is what divides rollups into two kinds: optimistic rollups and zero-knowledge (ZK)-rollups.

Optimistic Rollups

When an assertion is submitted to an optimistic rollup, it does not come with accompanying proof ensuring its validity. Instead, the validator making the claim posts a bond, and there is a time frame during which anybody may challenge the assertion with their own bond, similar to how a fraud-proof works in Plasma. If the asserter is incorrect, the validator will lose their bond; if the challenge time ends with no successful challenges, the assertion is accepted and becomes final.

ZK Rollups

On the contrary, validators in a ZK-Rollup must produce a zero-knowledge proof (ZKP) for each assertion, which is verified by the Rollup contract on the mainchain. This ZK proof confirms the existence of a series of transactions, correctly signed by owners, that update account balances in the correct way and lead from the old Merkle root to the new one. As a result, the operators cannot commit an invalid or manipulated state.

Pros & Cons

Compared to state channels or plasma, rollups give better data availability, thus it can never be censored by validators and provides better security. It also fully supports open participation and could be completely compatible with any applications that run on L1. But with full data availability, some scalability is sacrificed.

Comparing the two types of rollups, the main advantage of OP over ZK is that they are very flexible in generalized computation. Virtual machines on OP rollups only need to support the generation of fraud proofs, whereas the VMs on ZK rollups will need to support ZKP generation. This makes migrating to optimistic L2s very easy for developers. On Ethereum, this means that developers can simply write code in Solidity as they would on L1. ZK-EVMs are under development, but right now there is no single party that can provide EVM-compatible implementations. In addition, ZKP generations are quite computationally intensive at the moment, meaning they won’t be able to process as many transactions as OP rollups at full speed. According to a recent post by Vitalik, ZK-EVM performance and compatibility are negatively proportionate, meaning that the more compatible a ZK-EVM is with the native Ethereum environment, the less efficient it is. This is because the EVM was not developed with ZK-friendliness in mind, making many operations difficult to ZK-prove.
On the opposite end of the spectrum, we have much faster high-level-language equivalent ZK-EVMs. But because they work by compiling programs to a language that is explicitly built to be ZK-prove-friendly, the downside is that they are less compatible with some applications, such as those that employ handwritten EVM bytecode. Furthermore, many infrastructures, such as debugging infrastructure or execution clients (software that runs on a node) from L1 could not be shared with this type of ZK-EVM. And in the future, quantum computing might pose a threat to the security provided by ZKP which is guaranteed by the fact that currently there is no computer capable enough of reverse engineering them.

The main advantage of ZK rollups is that they provide the most security, because states submitted to L1 are guaranteed to be valid, while users for OP rollups still need liveliness to check relevant transactions because of the 3rd party aggregators, and the network gets more vulnerable to crypto-economic attacks as the TVL increases. And because fraud proofs are not needed, L1 finality is the fastest compared to all other scaling solutions, which need to wait for the challenge period time out. They also might have a smaller on-chain footprint because while the Optimistic Rollup witness (digital signatures that prove the consent of the transacting parties) scales linearly with the number of transactions, ZK Rollups replaces all those witnesses with a single proof that scales poly-logarithmically with the number of transactions. And problems might be generated for OP rollups when a fraud-proof is too big to be submitted in one transaction. Finally, they also introduce some privacy by default.

Use Cases

The Optimism Foundation established the Optimism Rollup Project in 2019 and the network went live in 2021. Its block production is managed by a single entity known as the sequencer, which constructs, executes L2 blocks, batches, and submits user transactions to L1. Users can also submit transactions to L1 directly, to avoid any censorship. This sequencer is currently centralized and run by Optimism. The team intends to decentralize the sequencer by 2023 by implementing an economic mechanism that creates a competitive market for sequencing and a governance mechanism that prevents sequencers from prioritizing short-term profits over the long-term health of the network. The team airdropped their governance tokens in May 2022, and the token market cap is $833 M (CMC, as of 03/20/23)
Another OP rollup project, Arbitrum, was developed by off-chain Labs in 2018. Noticeably it was founded by a team of a computer science professor and two Ph.D. students from Princeton University. Offchain Labs launched Arbitrum Nova in August 2022, a modified sidechain, targeting projects with high transaction volumes that seek to drive costs even lower (e.g. gaming and social projects). While Arbitrum One, which went online in September 2021, was a traditional roll-up chain. For both chains, the sequencer, which controls the ordering of transactions, is currently centralized and run by Offchain Labs. The team is actively researching a decentralized fair sequencing algorithm. However, anyone can choose to run a validator, which can propose blocks or watch the L2 to ensure correct behavior. Arbitrum One also has a more flexible fraud-proof structure, with multi-round interactive proving that does as much off-chain work as possible needed to resolve disputes. The team claims that this is more efficient.
ZkSync, founded in 2019 by Matter Labs, uses ZK rollup. ZkSync v1.0 went live in June of 2020, scaling payments on Ethereum. With zkSync, transactions are submitted via a centralized zkSync operator using the API. Then, the operator rolls up the transactions and submits the root hash of a new state, state delta (a small amount of data for every transaction indicating the change in state) along with cryptographic proof of the transactions. The team recently released zkSync 2.0, their ZK-EVM Alpha test net which would allow more general-purpose ZK rollup scaling. Right now, zkSync’s ZK-EVM is considered a “Type 4 (high-level-language equivalent)” ZK-EVM in Vitalik’s post mentioned earlier, which compiles code to some ZK-friendly language, and has the best performance but the least compatibility with EVM.
StarkEx, founded by Starkware in 2018, is another project that uses ZK rollup scaling. It uses a more bespoke approach for projects onboard, and currently has seven customers who integrate Starkex into their DApp and are deployed on Ethereum. Because StarkEx is powered by Cairo, a Turing-complete programming language designed for ZK-STARKs, DApps written in Solidity cannot be deployed directly. Applications send transactions to the centralized StarkEx Service, which processes them, generates proofs, batches them, and sends them to L1. StareEx also offers users a data availability spectrum, allowing them to choose what data to store on-chain or off-chain, balancing their requirement for security vs. cost. In a recent article, the team unveils their decentralization strategy for a permissionless proof-of-stake leader election mechanism, as well as on-chain payment of transaction fees, both supported by a native token.

The Scroll team, which emerged in 2022, has been building zkEVM with the Privacy and Scaling Explorations group at the Ethereum Foundation for over a year. It uses EVM-equivalent zkRollup to scale, and its architecture is comprised of three parts: scroll nodes which construct blocks, roller network which generates proofs, and smart contacts which provide data availability and verification to enable transactions. The project is currently at its Pre-Alpha testnet, with around 50k transactions on its L2.

Finally, Polygon Zero is the EVM solution Polygon is developing through their acquisitions of ZK-Rollups Hermez and Mir this year. The team claims that its novel proving technology, Plonky2, is the fastest ZK-proof generator. Polygon Zero also consisted of nodes for data transactions and provers for proof generations. In addition, the team has proposed an incentive structure with MATIC. The Polygon zkEVM Public Testnet was announced in October.

2. Evaluating L2s

There are different ways to evaluate L2 projects, here we talk about the infamous scalability trilemma in terms of L2 solutions and a more detailed evaluation framework for looking at projects.

2.1 The scalability trilemma

According to the scalability trilemma, blockchain systems have to trade off between scalability, security, and decentralization. Let's go through these ideas again: Scalability describes the number of transactions a blockchain can process; decentralization refers to how many parties participate in the consensus of the blockchain's state; and security refers to the work required to attack a blockchain, such as the number of nodes to take over. And, given our limited resources, we must seek a compromise between these three. For example, everyone is running a node for some blockchain, it is incredibly decentralized and secure (impossible to take over), but it is not particularly scalable since everybody (or most people) must reach consensus, and the throughput would be limited by slower nodes. And if we are to increase scalability by demanding higher quality nodes, fewer individuals would be able to join, resulting in a more centralized network, and possibly making the network more vulnerable to takeovers.

L2s do not solve this problem since at the root of the scalability trilemma is the limitation of resources. However, L2s provide developers with more options on the trilemma spectrum. L1s can be placed at the bottom of the trilemma, where they have the least scalability but the highest security and decentralization. Then there are rollups, which are less decentralized with fewer nodes but more scalable since transactions are processed off-chain and uploaded data is compressed. A lesser number of nodes has no effect on security for ZK rollups because mathematical proofs are provided with each transaction, but it does for OP rollups. However, OP rollups are more scalable than ZK rollups since computing ZKP for each transaction takes time.Finally, on the other end of the spectrum, we have state channels, which are extremely scalable but easily taken over with only a few participants in a channel. And plasma, which is somewhat more secure than state channels but less scalable with some data availability.

Keep in mind that in the trilemma, security is defined purely by attacks like validator takeover, the cost of which increases with the number of resources utilized to run nodes. There are additional security considerations that we shall discuss later, making security in this specific context less important in evaluating a project.

2.2 An evaluation framework

This evaluation framework is adapted from an article written by Alex Gluchowski, founder of Matter Labs, in 2020. We try to add new data and insights from the recent year of L2 to this table, which looks at L2 projects from three aspects.


  • Liveness: do users need to be monitoring all on-chain (i.e. L1) activity of the scaling solution by themselves or via trusted representatives (watch-towers). Liveliness is required for any project with fraud proof instead of validity proof.
  • Custodial: can a fraction of L2 validators commit fraud by preventing users from accessing funds for extended periods? Can they take assets from users? Only side chains are custodial as plasma and rollups both try to solve the problem by providing data availability.


  • Max throughput: here we try to use the stress test data from existing projects. Even though theoretically state channels can support infinite TPS, in reality, it is limited by the speed of nodes’ messaging as well as limits to resources (which limits the number of state channels). For Lightning Network, we can estimate the TPS very roughly by 18,000 nodes * 500TPS/2.8nodes/payment = 3 million TPS. And even if we assume only the top 10 nodes are utilized because not all nodes can take all transactions, that still gives us around 1,800 TPS. For practical purposes, we see that Lightning Network should be able to take as much TPS as needed (much more than Visa), and because there is not yet a stress test being conducted on Lightning network or a robust way to calculate its limit, we marked it as infinite. For side chains, we used data for Polygon: with a stress test on the testnet in 2020, Polygon achieved a TPS of 7,200 TPS. And for OP rollups, Arbitrum’s benchmark shows that they can go up to 4,500 TPS with simple transfer transactions. Finally, for ZK rollups, zkSync can process up to 2,000 TPS, while StarkEx has achieved 3,000 TPS for The Great Reddit Scaling Bake-Off (note that this is not representative of general-purpose tx scaling).
  • Cost of tx: cost per transaction, here we use actual data from the projects we mentioned above.
  • Capital efficiency: does the L2 require a substantial amount of capital to be locked in order to operate? State channels are the least capital efficient.
  • Withdrawal time: how long do withdrawals to L1 take? Because Plasma and OP rollups both require fraud proof, any confirmation has to wait for a challenging period, which is usually a week.
  • Subjective finality: how quickly can a transaction reach a state where it cannot be reverted on L1 anymore under the security assumptions of the protocol?

Other aspects

  • EVM code portability: can a project deploy its code written in Solidity directly onto the L2?
  • Native Privacy Options: Does the project protect the privacy of its users by default? State channels provide privacy because all intermediate transactions happen offline, not a single third party needs to have that information. As a result, it has been criticized for failing to keep proper accounting records. ZK Rollups, on the other hand, grants security with ZKP, which provides both records and privacy.

These categories are not definitions of what projects are good or bad, more like a checklist for what to look out for different types of projects. For example, if we are looking at an OP rollup project, we should take special consideration how their incentive structure/infrastructure is designed for parties to monitor their relevant assets and their projects that front the liquidity on L1 for a quicker withdrawal.

As previously stated, many L2s still use centralized operators for one or more of the processes, such as submitting rolled-up transactions to L1. In addition, many projects contain upgrade keys, which are frequently held by a multi-signature committee, to quickly resolve bugs in the smart contracts. Users and developers should be aware of these issues, and we shall all keep an eye on their progress toward decentralization. In addition, most vulnerabilities that were exploited with L2s had nothing to do with any particular design of that L2 or even the fact that the project is an L2 project. For example, funds were stolen from Polygon due to a lack of balance/allowance check in the transfer function, while the Optimism token airdrop was hacked when working with third-party market maker Wintermute. When evaluating projects, the structure itself is important, but a focus on safety in every network update, and every activity is more important.

3. Current state of L2

*StarkEx & zkSync TPS are calculated directly from the total number of transactions divided by the number of days since mainnet launched

** From l2fees, fee for the token swap.

The above table compares the TVL, TPS, and transactions fees (as of Feb 18, 2023), as well as the valuation and funding for the six projects we mentioned in previous sections. We can see that Lightning Network and Polygon have the lowest transaction fees and Polygon has processed most transactions with the highest TPS, as expected from our previous analysis of their underlying technology. However, Aribitrum has the highest TVL and StarkEx has the highest valuation, showing that investors have high expectations for the future of rollups.

Comparing the average TPS to the highest achievable TPS in the form above, we can see that L2s have much more potential and can unload more DApps from the Ethereum mainnet. Specifically, rollups are very underutilized. To demonstrate, we can compare L2s with Ethereum. In 2022, Ethereum had around 1.2M transactions per day. Polygon has had an average of around 3M transactions per day, while Optimism around 0.1M per day (similar data for other rollups), which is <10% of Ethereum. Besides, Ethereum now has over 200M unique addresses, around 0.5M of them active daily. Polygon has 170M unique addresses, around 0.3M of them active daily. While Optimism has 1.5M total users, <1% of Ethereum.
With the rollup-centric roadmap of Eth 2.0, efforts are being focused on scaling user activity at layer 2, while enabling L1 mainnet as a secure decentralized settlement layer optimized for rollup data storage to help make roll-up transactions exponentially cheaper. For instance, EIP-4844 (Proto-Danksharding) reduces data availability costs for rollups. Eth 2.0 should benefit the development of rollups, making it more accessible and attracting more users to L2.

4. Conclusion

In this post, we reviewed the technical design of state channels, plasma, and rollups, as well as the structure of six popular projects that use those technologies. We examined how to assess these projects, with an emphasis on the centralized points of failure that often arise during the deployment of a new project, as well as vulnerabilities in any future upgrades. Finally, we examine the present status of these initiatives, suggesting that they are underutilized, and we expect that Eth2.0 will support L2, particularly rollups, in reaching their full potential.


Jeff Coleman. State Channels. https://www.jeffcoleman.ca/state-channels/
Joseph Poon, Vitalik Buterin. Plasma: Scalable Autonomous Smart Contracts. https://www.plasma.io/plasma.pdf
Vitalik Buterin. An Incomplete Guide to Rollups. https://vitalik.ca/general/2021/01/05/rollup.html
Episode 151: John Adler on Optimistic vs ZK Rollup and the data availability problem https://zeroknowledge.fm/151-2/
Validity Proofs vs. Fraud Proofs Strike Back. StarkWare. https://medium.com/starkware/validity-proofs-vs-fraud-proofs-strike-back-4d0bf90eed15
Why sharding is great: demystifying the technical properties. https://vitalik.ca/general/2021/04/07/sharding.html

The content above is neither a recommendation for investment and trading strategies nor does it constitute an offer, solicitation, or recommendation of any product or service. The content is for informational sharing purposes only. Anyone who makes or changes the investment decision based on the content shall undertake the result or loss by himself/herself.

WOO Network will not be responsible or liable for any losses (including, without limitation, any direct or indirect damages for loss of profits) resulting or arising directly or indirectly from your own decisions.

The content of this document has been translated into different languages and shared throughout different platforms. In case of any discrepancy or inconsistency between different posts caused by mistranslations, the English version on our official website shall prevail.

This article contains links to third-party websites or other content for information purposes only (“Third-Party Sites”). The Third-Party Sites are not under the control of CoinMarketCap, and CoinMarketCap is not responsible for the content of any Third-Party Site, including without limitation any link contained in a Third-Party Site, or any changes or updates to a Third-Party Site. CoinMarketCap is providing these links to you only as a convenience, and the inclusion of any link does not imply endorsement, approval or recommendation by CoinMarketCap of the site or any association with its operators. This article is intended to be used and must be used for informational purposes only. It is important to do your own research and analysis before making any material decisions related to any of the products or services described. This article is not intended as, and shall not be construed as, financial advice. The views and opinions expressed in this article are the author’s [company’s] own and do not necessarily reflect those of CoinMarketCap.
2 people liked this article