WOO Network: A Deep Dive into Different Layer2 Scaling Solutions

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.

1. Layer 2 solutions

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

1.1 State channels

Structure

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:

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 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.

1.2 Plasma

Structure

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.

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.

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.

Use Case

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.

WOOFi is on Polygon.

1.3 Rollups

Structure

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.

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 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

Security

• 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.

Performance/Usability

• 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.

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.

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.

References

—

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.