PaperlayerView exact revision on arXiv

Source-linked AI summary

Layer 2 Blockchain Scaling: a Survey

Cosimo Sguanci, Roberto Spatafora, Andrea Mario Vergani

arXiv:2107.10881v1cs.DCcs.CR

TL;DR

Blockchain scalability is limited by low transaction throughput and constraints on block propagation. This paper surveys Layer 2 frameworks and compares their properties, then evaluates them in a supermarket use case. The frameworks improve on pure Layer 1 applications in throughput and latency, while the suitable choice depends on the application context.

  • Problem

    Blockchain throughput is limited, while reducing block intervals or increasing block size is constrained by the time needed to propagate blocks across the network.

    Source: §2 · p. 3

  • Method

    The paper compares Lightning Network, Plasma, and Rollups across scalability, security, decentralization, privacy, fees, and micropayments, then examines a supermarket use case.

    Source: §9 · p. 47

  • Results

    All examined frameworks perform better than a pure Layer 1 application in throughput and latency in the supermarket use case.

    Source: §9 · p. 47

  • Takeaways & Limitations

    The frameworks’ different properties make the application context relevant when selecting among them.

    Source: §9 · p. 47

    Plasma withdrawals require users to wait through a 7 day dispute period before retrieving funds on the root chain.

    Source: §8.2.2 · p. 42

Abstract

from arXiv · show

Blockchain technology is affected by massive limitations in scalability with consequent repercussions on performance. This discussion aims at analyzing the state of the art of current available Layer II solutions to overcome these limitations, both focusing on theoretical and practical aspects and highlighting the main differences among the examined frameworks. The structure of the work is based on three major sections. In particular, the first one is an introductory part about the technology, the scalability issue and Layer II as a solution. The second section represents the core of the discussion and consists of three different subsections, each with a detailed examination of the respective solution (Lightning Network, Plasma, Rollups); the analysis of each solution is based on how it affects five key aspects of blockchain technology and Layer II: scalability, security, decentralization, privacy, fees and micropayments (the last two are analyzed together given their high correlation). Finally, the third section includes a tabular summary, followed by a detailed description of a use-case specifically thought for a practical evaluation of the presented frameworks. The results of the work met expectations: all solutions effectively contribute to increasing scalability. A crucial clarification is that none of the three dominates the others in all possible fields of application, and the consequences in adopting each, are different. Therefore, the choice depends on the application context, and a trade-off must be found between the aspects previously mentioned.

1 Blockchain Introduction

Blockchain is presented as a decentralized, immutable ledger intended to support trustless electronic payments without a third-party dispute authority. Its chained blocks and proof-of-work help secure transactions, while the paper distinguishes blockchain generations by their capabilities and consensus approaches.

1 Blockchain Introduction

  • Blockchain is a decentralized public ledger of immutable, linked information intended to enable trustless electronic payments without third-party dispute management.Cryptographic proofs can replace the trust required in traditional cash systems.Source: §1 · p. 2
  • Blocks link by hashes and are propagated and stored by nodes, which can validate transactions and address double spending.Proof of work makes transactions computationally infeasible to reverse, while miners are incentivized by transaction fees.Source: §1 · p. 2
  • Second-generation blockchains add smart-contract execution, enabling decentralized programs and complex functionality without a central authority.Ethereum is given as an example.Source: §1 · p. 2
  • Third-generation blockchains explore consensus mechanisms beyond proof of work, such as proof of stake, and generally aim to improve scalability.Cardano and Polkadot are examples.Source: §1 · p. 3

2 Blockchain Scalability issue

The section frames limited transaction throughput as a blockchain scalability bottleneck and shows that increasing block size or shortening block intervals is constrained by network propagation time. SegWit improves effective block size but does not scale transaction throughput.

2 Blockchain Scalability issue

  • Bitcoin processes 4.6 TPS and Ethereum around 14.3 TPS, compared with Visa’s around 1,736 TPS and peak of 47,000 TPS.The section gives Bitcoin’s block interval as about 10 minutes, block size as 1MB, and average transaction size as 380 bytes.Source: §2 · p. 3
  • Block parameters alone cannot solve scalability: relay time constrains how far block intervals can be reduced or block size increased.In January 2021, propagation to 99% of an estimated 10,000 Bitcoin nodes took approximately 14 seconds, and increasing block size makes that relay time insufficient.Source: §2 · pp. 3–4
  • SegWit scaled Bitcoin’s block size theoretically to 4MB and practically to around 2MB, but did not improve TPS in a scalable manner..Source: §2 · p. 4

3 Layer II solutions

Layer 2 solutions reduce main-chain load by handling transactions off-chain and recording summaries or updates on-chain, but must balance scalability with security and decentralization. The section distinguishes channels, sidechains, and rollups, and notes that sharding is a Layer 1 approach rather than Layer 2.

3 Layer II solutions

  • Scaling solutions face a trilemma in which improving scalability negatively affects security, decentralization, or both, making a trade-off necessary.Multiple Layer 2 protocols can be combined on the same unaltered main chain; sharding instead partitions the main chain’s nodes and is classified as Layer 1 scaling.Source: §3 · pp. 4–6
  • Layer 2 frameworks handle transactions off-chain and report summaries on the main chain to reduce blockchain load and improve transaction speed.They generally lower fees, can support micropayments, and require no modification to the main chain, though they depend on it to register transaction summaries.Source: §3 · pp. 4–5
  • Channels manage transactions between connected nodes off-chain and report only channel opening and closing transactions on-chain.Lightning Network and Raiden Network are given as state-channel examples.Source: §3 · p. 4
  • Sidechains run off-chain transactions on child blockchains anchored to the main chain, typically trading decentralization for speed.Plasma is described as a sidechain architecture offering more guarantees in security and decentralization than standard sidechains.Source: §3 · p. 5
  • Rollups execute transactions off-chain but publish data for every state update, rather than only opening and closing transactions.They broadcast a smaller amount of data than usual on-chain transactions.Source: §3 · p. 5

4 Lightning Network (and references to Raiden Network)1

This section examines how the Lightning Network and Raiden Network use state channels to move peer-to-peer transactions off-chain while recording channel openings and closings on-chain. It also considers routing fees, micropayment viability, and the privacy implications of route choices.

4.5 Fees and micropayments

  • Direct-channel transactions have no fees, while routed payments may incur small intermediary fees, enabling micropayments as small as 0.00000001 BTC.At the time described, the fee market was still in an early phase with very low additional costs, though LN’s topology could shape its evolution.Source: §4 · p. 7, §4.5 · pp. 16–17

Multisignature addresses & HTLC

  • A multisignature channel can require multiple parties to authorize spending, so a noncooperative participant can lock funds; HTLCs provide a mechanism to address this impasse.In a 2-of-2 scheme, both participants must sign to move funds.Source: Multisignature addresses & HTLC · pp. 7–8
  • HTLCs use hashlocks and timelocks to let a receiver claim a payment with the secret before expiry or return funds to the sender, while shared old secrets deter cheating.A malicious user may still exploit a counterparty’s offline period; RN’s paid Monitoring Service can watch for cheating while the user is offline, at a cost to privacy.Source: Multisignature addresses & HTLC · p. 8, §4.2 · pp. 11–12

Routing payments

  • Routing lets users pay indirectly through intermediaries, but a payment cannot exceed the funds available in any channel along its route.If a route lacks the required funds, the sender must seek another path; in Raiden, payments are treated as multi-hop transactions, with zero intermediaries for a direct channel.Source: Routing payments · pp. 8–9

4.1 Scalability

  • LN raises Bitcoin’s capacity from almost 5 TPS to an estimated average of at least 11,000 TPS, with theoretical capacity of billions of transactions per day.Payments can fail when a route lacks sufficient channel funds, while an uncooperative user at closure can force a timelock wait; splitting large payments may help with the first issue, but not the second.Source: §4.1 · p. 10

4.3 Decentralization

  • Although LN is peer-to-peer in design, users’ preference for reliable, well-connected hubs produces a less distributed, scale-free topology that can concentrate connectivity and high-value routing.Hub outages can threaten robustness, and limited channel capacities at most nodes constrain high-value payments.Source: §4.3 · p. 15

4.4 Privacy

  • LN reveals channel balances only at opening and closing, and onion routing limits intermediaries’ knowledge to adjacent nodes, but short hub-centered routes reduce privacy.Direct-channel transactions are completely private, while privacy on routed payments varies with path length; RN’s Monitoring Service trades away some privacy for security.Source: §4.4 · pp. 15–16

4.5 Fees and micropayments

  • Senders choose payment routes, and the lowest-fee paths are usually among the shortest available, though shorter paths are worse for privacy.Intermediate routers set fees that typically combine a fixed charge with a payment-proportional component.Source: §4.5 · p. 17
  • Because intermediate nodes may charge fees, short routes are generally better than long routes for payment costs, but worse for privacy.Source: §4.5 · p. 17
  • Centralized routing hubs could raise fees for micropayments, while Lightning fees are currently low and state channels theoretically add no transaction cost.If Alice cannot reach Bob directly, routing may be her only practical option for a micropayment; future fee markets depend on the network’s topology.Source: §4.5 · p. 17

5 Plasma

Plasma moves transaction processing to child chains while committing block headers to the root chain, where fraud proofs can enforce state. Its throughput, security, usability, and fees depend on design choices and trade-offs.

5 Plasma

  • Plasma publishes child-chain block headers to the root chain, enabling fraud proofs and state enforcement while compressing multiple transitions into a Merkle-root commitment.The construction shifts transaction load to child chains and reduces root-chain storage, assuming the root chain is secure and available.Source: §5 · p. 18

Fraud Proofs

  • Merkle proofs let users support withdrawals and challenge invalid blocks, while Plasma’s initial UTXO design makes fraud-proof verification more compact but generally excludes smart contracts.Withdrawals need a challenge period because a user cannot prove an output remains unspent; block-data availability is also required for fraud proofs.Source: §5 · p. 19, Fraud Proofs · p. 20

Deposits and Withdrawals

  • Deposits begin on the root chain, while withdrawals stake a bond and await a dispute timeout; a commonly adequate challenge period is seven days.A liquidity provider can offer faster exits for an extra fee, subject to validating the Plasma chain.Source: Deposits and Withdrawals · p. 21

5.1 Scalability

  • Approximately 175 TPS is estimated for Polygon, about 11 times Ethereum mainnet throughput, but the paper says this remains short of mass-adoption needs.The estimate is described as conservative, and additional Plasma sidechains could provide horizontal scaling.Source: §5.1 · p. 22

5.2 Security

  • Data unavailability and block withholding require users to monitor the child chain and may trigger mass exits that congest the root chain.The paper also identifies risks from complex root-chain contracts, expensive redemption transactions, and censorship during a 51% attack on the root chain.Source: §5.2 · p. 23

5.3 Decentralization

  • A Plasma chain’s decentralization depends on its consensus and finality choices; root-chain commitment of a block’s Merkle root is the stated condition for L1-equivalent security.Proof of stake is discussed as a way to balance decentralization and scalability while mitigating block-withholding risk.Source: §5.3 · p. 24

5.4 Privacy

  • Plasma avoids broadcasting every transaction on the root ledger, while privacy depends on child-chain design and could be increased through designs inspired by ZCash.Source: §5.4 · p. 24

5.5 Fees and micropayments

  • Plasma can lower transaction fees and support micropayments; a dedicated chain could compress many low-value transfers into light block headers, though users must monitor it and periodically withdraw to the root chain.The paper notes that Plasma can send assets to users outside the current participant set, unlike classical state channels; variants trade features, including Plasma Cash’s fractional-asset limitation and Plasma Debit’s channel-based transfers.Source: §5.5 · p. 25, Plasma variants · pp. 25–26

6 Rollups

Rollups execute transactions off-chain while posting transaction data to the root chain, reducing congestion and fees. ZK and Optimistic Rollups differ in verification, performance, privacy, and decentralization trade-offs.

6 Rollups

  • Rollups execute state computation off-chain, while the root-chain contract tracks the state root and stores data for each transaction.Actors can submit batches containing compressed transactions and old and new state roots; the contract checks that the submitted prior root matches its current root.Source: §6 · p. 26

ZK Rollups

  • ZK Rollups attach validity proofs to batches; these are cheap to verify but expensive to compute, making them unsuitable for complex contract execution.The proof verifies that the batch correctly changes the prior state to the new state and avoids the need for fraud proofs.Source: ZK Rollups · p. 27, §6.2 · p. 29

Optimistic Rollups

  • Optimistic Rollups publish batches without first proving them correct, relying on challengers to identify invalid state roots.The contract can verify a fraud proof, restore the last valid batch, and penalize the publisher.Source: Optimistic Rollups · p. 27, §6.2 · p. 29

6.1 Scalability

  • 100x is the approximate theoretical scalability improvement for ZK Rollups over Ethereum L1; Optimistic Rollups are estimated at more than 800 TPS.The ZK estimate is for ETH transfers; Optimistic Rollups require more transaction data for verification but support general smart-contract computability. ZK withdrawals need only wait for the next batch, while Optimistic withdrawals can take 1–2 weeks.Source: §6.1 · p. 28

6.3 Decentralization

  • Rollups store state-reconstruction data on-chain, but their use of a single contract can increase centralization.ZK Rollups also face an early-life centralization concern because a small group controls the trusted initial condition for SNARK proofs.Source: §6.3 · pp. 29–30

6.4 Privacy

  • Rollups provide less privacy than solutions that commit only initial and final transactions because they publish a summary of every off-chain transaction.Using Optimistic Rollups as a Layer 3 privacy measure on top of another Ethereum L2 is proposed, but the paper says this would cause excessive fragmentation.Source: §6.4 · p. 30

6.5 Fees and micropayments

  • In the analyzed scenario, Rollup cryptocurrency transfers cost up to 11 times less than mainnet transfers.The last ten zkSync transfers averaged 0.000046841 ETH (about $0.11); that fee was still considered high for a micropayment such as a $1 coffee.Source: §6.5 · pp. 30–31

7 Comparative table

The comparative table organizes the analyzed solutions by strengths and weaknesses across five aspects. Its entries show differing trade-offs in security, decentralization, privacy, and fees rather than one uniform advantage.

7 Comparative table

  • The table compares the solutions across five aspects, highlighting each framework’s strengths and weaknesses.The aspects covered are scalability, security, decentralization, privacy, and fees and micropayments.Source: §7 · p. 32

Lightning Network

  • Lightning Network combines hashlock and timelock security with private direct-channel payments, while indirect routing can incur fees and its real network structure includes a limited number of hubs.The table describes direct-channel transactions as fee-free, with low additional fees for multi-hop payments and L1 fees for channel opening and closure.Source: §7 · pp. 33–34

Plasma

  • Plasma uses L1 merkle-root commitments for security, but block withholding and mass exit remain open issues.Its child-chain consensus is usually less decentralized than L1; transactions are much cheaper than L1 but still need fees to discourage spam, and deposits and withdrawals require L1 fees.Source: §7 · pp. 33–34

Rollups

  • Rollups publish transaction summaries on-chain, providing a decentralization benefit while increasing centralization through management by a limited number of smart contracts.The table characterizes Rollups as having the least privacy among the analyzed solutions; ZK off-chain transfer fees are described as negligible, while Optimistic fees are higher than ZK fees but low compared with L1.Source: §7 · pp. 33–34

8 Layer 2 Use Case: Supermarket

The use case proposes evaluating Layer 2 payment frameworks in a supermarket cryptocurrency-payment application. It considers implementation effort, customer usability, and throughput and latency, while treating public-test-network results as indicative rather than fully reproducible.

8 Layer 2 Use Case: Supermarket

  • The proposed supermarket proof of concept evaluates implementation commitment, customer usability, and performance for cryptocurrency payments.Implementation effort also serves as an indication of platform ecosystem maturity; usability combines customer ease of use and transaction cost, while performance includes confirmation latency as well as throughput.Source: §8 · p. 35

Proposed Schema

  • The proposed customer interaction uses real-time socket.io communication, with a QR code and supermarket mobile wallet suggested for a real-world setup.Keeping private keys on users’ devices leaves customers in control of their funds.Source: Proposed Schema · pp. 36–37

Common usability drawbacks

  • Decentralized use requires customers to manage private keys and wallets and to handle deposits and withdrawals with on-chain fees.These are identified as usability drawbacks common to the solutions considered.Source: Common usability drawbacks · p. 37

Estimated performance requirements

  • 0.083 TPS per store is the estimated throughput requirement for a nationwide supermarket with about 400 stores and 10 registers per store, each processing one payment every two minutes.The reported application benchmarks are only indicative: public testing networks and external API providers can make performance results variable and difficult to reproduce.Source: §8 · p. 35, Estimated performance requirements · p. 37

0.083 TPS · 400 ≈33 TPS

Each test execution attempted to process 200 transactions.

0.083 TPS · 400 ≈33 TPS

8.1 Lightning Network

The Lightning Network supermarket design uses routed channels, with customer wallets and supporting supermarket infrastructure. Its testnet benchmark averaged around 63 TPS with confirmation waiting time under two seconds.

8.1.1 Development effort and costs

  • Supermarket deployment requires Bitcoin and Lightning nodes, a customer mobile wallet, and backend services to generate invoices and verify payments.Customer wallet apps commonly connect to a remote Bitcoin node, balancing privacy and usability against running a local node.Source: §8.1.1 · pp. 37–38
  • Routing-node fees apply to transfers, averaging around 1 satoshi per routing node; the supermarket could limit L1 closures to channels with routing hubs.Closing fewer channels can mitigate withdrawal costs and avoid congesting L1; the supermarket could close and reopen channels periodically or above a threshold.Source: §8.1.1 · pp. 38–39

8.1.2 Customers usability

  • Customers need some channel knowledge and pay on-chain fees to open and close channels; when a channel runs out of funds, it must be closed and reopened to top up.Projects such as Lightning Loop were still in beta at the time of writing.Source: §8.1.2 · p. 39

8.1.3 Performance

  • Around 63 TPS on average, with confirmation waiting time under 2 seconds, was observed in Lightning Network benchmark tests.The tests used an implementation with a single routing node between customer and supermarket nodes.Source: §8.1.3 · pp. 39–40

8.2 Plasma

The proof of concept uses Polygon, an account-based Plasma implementation with a PoS checkpoint layer. Its measured performance was worse than Lightning Network, while a dedicated chain was presented as a possible performance improvement with greater setup and maintenance costs.

8.2.1 Development effort and costs

  • Polygon adapts account-based Plasma with a PoS checkpoint layer, and its EVM basis allows Ethereum-like services to connect by changing the RPC endpoint.The application architecture could use fewer components than the Lightning Network design, though dedicated nodes may help avoid third-party RPC traffic limits.Source: §8.2 · p. 40, §8.2.1 · pp. 40–41

8.2.2 Customers usability

  • Plasma transfers incur fees on every transaction, which the supermarket could cover; withdrawals to the root chain require a 7-day dispute-period wait.The proposed application also requires users to keep private-key credentials secure and make transfers accessible through suitable UX/UI.Source: §8.2.2 · pp. 41–42

8.2.3 Performance

  • Polygon performance was worse than Lightning Network; the authors suggest node-client optimization and RPC-provider dependence as possible factors.A dedicated Plasma chain could improve performance, but would increase supermarket setup effort and maintenance costs.Source: §8.2.3 · pp. 42–43

8.3 Rollups

The proof of concept uses zkSync, a ZK Rollup whose APIs and libraries are needed to interact with the system at the time of writing. Its fees, withdrawal timing, and highly variable throughput present different usability and performance characteristics.

8.3.1 Development effort and costs

  • At the time of writing, zkSync was not EVM-compatible, so existing Ethereum software could not be ported merely by changing an RPC endpoint.Users interact through zkSync libraries and APIs, and validators publish validity proofs on-chain.Source: §8.3.1 · p. 43

8.3.2 Customers usability

  • zkSync transfers were approximately 8x cheaper than Ethereum mainnet transfers, and batched transfers let one sender pay fees for multiple transactions.In one test, 10 transfers were bundled for approximately 0.0001084 ETH in fees paid by a single account.Source: §8.3.2 · pp. 43–44
  • Withdrawals from zkSync took approximately 10 minutes, and transfer fees could be paid in the transferred token rather than the chain’s native currency.Withdrawals also carried an off-chain fee of approximately 0.0029 ETH at the time of writing.Source: §8.3.2 · p. 44

8.3.3 Performance

  • zkSync test throughput showed great variability, while transaction latency appeared stable and low compared with the Plasma use case.The authors cite API rate limits, backend changes, and a maximum of 10 transaction authors per batch as possible constraints, and caution that the results may not represent the best achievable ZK Rollup performance.Source: §8.3.3 · p. 45

8.4 Use case conclusions

The use-case benchmark comparison reported improvements over Ethereum Ropsten even in the proof of concept’s worst-case scenario. Lightning Network appeared most mature for performance, though other tools may require less architectural or software-engineering effort.

8.4 Use case conclusions

  • In the proof of concept’s worst-case scenario, throughput improved by approximately 2x and transaction latency by approximately 9x.The comparison followed benchmark tests on Ethereum Ropsten testnet using the same tests.Source: §8.4 · pp. 45–46
  • Lightning Network seemed the most mature tested solution for performance, while other tools probably required less architectural or software-engineering effort.The tools used were under development, so their features could change or improve over time.Source: §8.4 · p. 46

9 Conclusion

The paper compares Lightning Network, Raiden Network, Plasma, and ZK and Optimistic Rollups theoretically and across key dimensions, then evaluates the frameworks in a supermarket use case. It concludes that Layer 2 solutions improve scalability, while their characteristics and adoption contexts differ.

9 Conclusion

  • Plasma extends traditional sidechains with security and decentralization improvements, while Rollups use compression to support scalability.Source: §9 · p. 47
  • Lightning Network, Plasma, and Rollups could also be combined; the paper cites Lightning Network on top of Plasma as a possible architecture.Source: §9 · p. 47
  • In the supermarket use case, all evaluated frameworks outperform pure Bitcoin and Ethereum L1 applications in latency and throughput.Source: §9 · p. 47
  • Lightning Network is Bitcoin’s most mature scaling technology, though its current hub-and-spoke architecture can partly threaten its theoretical features.Source: §9 · p. 47
  • Layer 2 solutions can complement Ethereum 2.0: adapted Plasma and Rollups may remain important during adoption and continue supporting higher throughput alongside sharding.Source: §9 · p. 48
  • Raiden Network remains immature, but its distinctive privacy features may attract users independently of throughput and Ethereum 2.0 progress.Source: §9 · p. 48
  • The paper concludes that Layer 2 solutions address blockchain scalability while retaining a secure and decentralized architecture.Source: §9 · p. 48
Loading 2107.10881v1…