Pith. sign in

REVIEW 27 references

Scaling DeFi with ZK Rollups: Design, Deployment, and Evaluation of a Real-Time Proof-of-Concept

T0 review · reviewed 2026-08-07 · deepseek-v4-flash

Challenge this review Re-run · record.json Download PDF Read on arXiv ↗

Pith's one-line read A self-hosted ZKsync rollup forked with Uniswap V2 sustained 71 swap transactions per second in a 14-second stress test, versus Ethereum's 12-15 TPS.

desk verdict A useful benchmark data point, but the 71.43 TPS headline is a burst average from a single run, not a demonstrated capacity ceiling. read the letter →

arxiv 2506.00500 v1 pith:AJST6543 submitted 2025-05-31 cs.CR

Krzysztof Gogol , Szczepan Gurgul , Faizan Nehal Siddiqui , David Branes , Claudio Tessone This is my paper
classification cs.CR
keywords ZKrollupEthereumscalingLayer2transactionthroughputgaspersecondUniswapV2sequencerbottleneckDeFi
verification ladder T0 review T1 audit T2 compute T3 formal

The pith

A machine-rendered reading of the paper's core claim, the machinery that carries it, and where it could break.

The reading

This paper is a stress test of a zero-knowledge rollup built to run decentralized-finance workloads. The paper deployed a self-hosted ZKsync chain, forked Uniswap V2 onto it, and flooded it with 1,000 token-swap transactions generated by five parallel load generators. It reports the rollup sustained 71.43 swap transactions per second over a 14-second window, compared with roughly 12-15 general transactions per second on Ethereum, with most swaps reaching soft finality in under 2.5 seconds. The paper's point is that realistic, gas-heavy DeFi transactions, not simple token transfers, are the right yardstick for judging rollup throughput, and that the measured gap over Ethereum is substantial. It also documents where the bottleneck sits: sequencer overload, Merkle-tree computation during L1 batch sealing, and the efficiency gap between small miniblocks and larger L1 batches.

What carries the argument

The load-bearing mechanism is the ZKsync rollup stack operated as a standalone chain: a sequencer receives swap transactions, groups them into miniblocks, and later seals them into L1 batches, while a prover generates validity proofs for each batch. The benchmark machinery is a modified transaction generator that uses WebSocket submission from five parallel instances, each with its own IP address, to flood a forked Uniswap V2 router's swapExactTokensForTokens function. The analysis pipeline computes cumulative TPS from submission and inclusion timestamps, and the internal ZKsync logging and parsing path breaks down L1 batch sealing into stages, isolating the Merkle-tree update stage as the dominant delay at up to 2.44 seconds. The paper's key comparative device is gas-per-second reasoning: swap transactions consume far more gas than transfers, so the reported TPS is meant as a conservative estimate of real-world DeFi throughput.

What would settle it

Rerun the same Uniswap V2 swap workload on the same ZKsync deployment with six or more generator instances and a sustained load lasting several minutes; if cumulative TPS collapses toward or below Ethereum L1's rate as generators increase, the 71.43 TPS result is an artifact of the test harness's five-instance ceiling. Alternatively, instrument the sequencer's memory and queue depth during the run: if the sequencer is idle while generators wait, or if transaction inclusion stops despite an open mempool, the bottleneck is not the rollup protocol.

Watch

Extended reading notes

Core claim

On its own terms, the paper establishes that a locally deployed ZKsync-based ZK rollup can process gas-intensive Uniswap V2 swap transactions at a sustained cumulative rate of 71.43 TPS, peaking at 98.4 TPS at the four-second mark, over a 14-second burst of 1,000 swaps from 50 funded accounts. It contrasts this with Ethereum's native throughput of about 15 TPS and with headline rollup numbers that are often measured using simple transfers. The paper further reports that over 50% of swaps were included in L2 miniblocks within 2.5 seconds (soft finality), while hard finality on L1 took 10-20 minutes, and that adding a sixth generator instance destabilized the sequencer. It identifies sequencer scheduling toggling, Merkle-tree updates (up to 2.44 s per batch), and miniblock under-filling relative to L1 batches as the principal performance limiters in this configuration.

Load-bearing premise

The headline throughput rests on the assumption that the five-generator, 1,000-swap, 14-second run is a true measure of rollup capacity, not a reflection of generator-side saturation or a sequencer that becomes unstable with a sixth generator.

Editorial extensions

If this is right

  • If the measured throughput holds, a single self-hosted ZK rollup node of comparable specifications can carry gas-heavy DeFi traffic at several times Ethereum L1's rate, at least for bursts of roughly a thousand transactions.
  • Soft finality in under 2.5 seconds means user-facing DEX interactions can feel instant, but settlement-critical logic such as liquidations or bridges must budget for 10-20 minutes to reach hard finality.
  • Sequencer instability beyond five parallel generators implies current ZK-rollup deployments need load shedding or decentralized sequencing before they can absorb sustained high-volume traffic.
  • Because miniblocks carry fewer than one-third the transactions of L1 batches, latency-oriented sequencing raises per-transaction L1 cost; aligning miniblock size with batch capacity would improve cost amortization.
  • Merkle-tree updates dominate batch sealing, so improving that single cryptographic step would shorten hard-finality latency more than most other pipeline optimizations.

Reading between the lines

Editorial extensions of the paper, not claims the author makes directly.

  • Beyond the paper, the 71 TPS figure should not be read as a protocol ceiling; rerunning the same harness on other rollup architectures or with a decentralized sequencer set could show whether throughput is a property of validity proofs or of sequencer scheduling.
  • Beyond the paper, a direct implication left implicit is that gas per second, not raw TPS, is the transferable comparison; re-expressing the 1,000 swaps as gas per second would let any DEX workload on any chain be compared without knowing block sizes.
  • Beyond the paper, if the six-generator instability is a sequencer memory or priority issue rather than a networking artifact, then a simple queue-depth limiter or backpressure mechanism could raise sustained throughput, and that is testable in the same setup.
  • Beyond the paper, extending the 14-second window to several minutes would reveal whether 71 TPS is sustainable or only a burst behavior, since the paper's own data show throughput declining as generator count rises.
Share X Bluesky LinkedIn Reddit HN

Editorial analysis

A structured set of objections, weighed in public.

Desk editor's note, referee report, and a circularity audit.

Circularity Check

0 steps flagged · score 0.0 of 10

No significant circularity: the throughput result is a direct measurement of logged transactions, and the self-citations are contextual only.

full rationale

The paper makes an empirical benchmark claim rather than a derived one. The central quantity, 71.43 TPS, is computed from the paper's own explicitly stated formula in Section V-A: 'Cumulative TPS = Total (swap) transactions processed / Elapsed time (in seconds)', which is just the definition of a throughput measurement applied to logged inclusion data. Nothing is fitted to a subset and then renamed a prediction; the value 1,000/14 = 71.43 is an arithmetic summary of one recorded run. The stress-test harness limits (six generator instances destabilize the sequencer; Table I shows throughput declining with instance count) are validity threats to the generalizability of the measurement, but they are not circularity: the claim does not become true by construction through any parameter fitted from the data or through any self-citation. The cited prior works by the same authors ([3], [17]) are used only as related-work context and motivation, not as premises of the throughput computation; no uniqueness theorem or ansatz is imported from them. The benchmark is externally falsifiable: the code and modifications are public and the measurement depends on independent run-time behavior. Therefore no load-bearing circular step is present.

Assumptions & free parameters 3 free parameters · 3 assumptions · 0 invented entities

The central claim depends on three main assumptions: representative deployment of a ZK rollup, a valid external Ethereum baseline for the comparison, and a single stress-test run being sufficient. The main chosen values are the 300-swap-per-block utilization cap, the inconsistent Ethereum TPS baselines, and the five-instance generator cap. The paper introduces no new entities, particles, forces, or consensus changes.

free parameters (3)
  • Block capacity normalization = 300 swap transactions per block
    Section V-C defines 100% block utilization as 300 swap transactions per block, described as an upper bound 'derived from the optimized memory footprint of such transactions'; no calculation or source is given, and the block utilization analysis depends on this chosen value.
  • Ethereum baseline TPS = 12, 15, and 15-23 TPS in different places
    The abstract claims comparison to 12 general transactions per second, Section V-A compares to 15 TPS, and Section VII-A compares to 15-23 TPS. These are external estimates, not measured in the same experimental setup, yet they anchor the paper's speedup claim.
  • Generator instance count = 5 instances
    The number of concurrent transaction generators was set to five because adding a sixth caused sequencer instability (Section IV-B). The reported 71.43 TPS is the result of this chosen configuration, not of an optimization for peak throughput.
assumptions (3)
  • domain assumption A private ZKsync elastic chain on Sepolia with a local sequencer and prover is a representative ZK rollup deployment for benchmarking.
    Section III-A states the setup uses the ZKsync elastic chain framework with its own sequencer and prover on the Sepolia testnet, and the paper generalizes from this single-node testbed to statements about ZK rollups in general.
  • domain assumption Ethereum L1 throughput estimates from external sources are a valid baseline for comparing swap TPS on the rollup.
    The paper does not measure Ethereum under the same swap workload; it cites or states general TPS figures (12, 15, or 15-23) and uses them as the comparison baseline in the abstract and Section V-A.
  • ad hoc to paper One stress-test run is sufficient to estimate sustained throughput.
    All throughput, latency, and utilization conclusions are drawn from a single 14-second run of 1,000 swaps, with no repeated trials or statistical confidence intervals reported in Section V.

how reviews work

0 comments
Cite this review

Pith. "Pith review of Scaling DeFi with ZK Rollups: Design, Deployment, and Evaluation of a Real-Time Proof-of-Concept." pith.science (2026). https://pith.science/paper/AJST6543

@misc{pith2026250600500,
  author       = {Pith},
  title        = {Pith review of: Scaling DeFi with ZK Rollups: Design, Deployment, and Evaluation of a Real-Time Proof-of-Concept},
  year         = {2026},
  howpublished = {\url{https://pith.science/paper/AJST6543}},
  note         = {Machine review of arXiv:2506.00500}
}
read the original abstract

Ethereum's scalability limitations pose significant challenges for the adoption of decentralized applications (dApps). Zero-Knowledge Rollups (ZK Rollups) present a promising solution, bundling transactions off-chain and submitting validity proofs on-chain to enhance throughput and efficiency. In this work, we examine the technical underpinnings of ZK Rollups and stress test their performance in real-world applications in decentralized finance (DeFi). We set up a proof-of-concept (PoC) consisting of ZK rollup and decentralized exchange, and implement load balancer generating token swaps. Our results show that the rollup can process up to 71 swap transactions per second, compared to 12 general transaction by Ethereum. We further analyze transaction finality trade-offs with related security concerns, and discuss the future directions for integrating ZK Rollups into Ethereum's broader ecosystem.

Figures

Figures reproduced from arXiv: 2506.00500 by the authors.

Figure 1
Figure 1. High-level architecture of ZK Rollups. A sequencer bundles and [PITH_FULL_IMAGE:figures/full_fig_p003_1.png] view at source ↗
Figure 2
Figure 2. Cumulative (swap) transaction throughput. Peak TPS of 98.4 achieved [PITH_FULL_IMAGE:figures/full_fig_p005_2.png] view at source ↗
Figure 4
Figure 4. Block utilization during stress test. Early and late phases show [PITH_FULL_IMAGE:figures/full_fig_p006_4.png] view at source ↗
Figures from the paper (6 more)
Figure 5
Figure 5. Figure 5: L1 batch height and transaction activity. Shows the progression of batches from sealing to proof publication. Heatmap highlights the correlation [PITH_FULL_IMAGE:figures/full_fig_p007_5.png]
Figure 6
Figure 6. Figure 6: Latency distribution between transaction receipt and miniblock inclusion. 50% of transactions are included within 2.5s, showing responsiveness of [PITH_FULL_IMAGE:figures/full_fig_p010_6.png]
Figure 7
Figure 7. Figure 7: Transactions per miniblock vs. L1 batch. Illustrates efficiency gains through batching: L1 batches include over 3× more transactions than individual [PITH_FULL_IMAGE:figures/full_fig_p010_7.png]
Figure 8
Figure 8. Figure 8: Processing time of L1 batch sealing stages. Highlights Merkle tree update as a performance bottleneck with a 2.44s delay. Other stages complete [PITH_FULL_IMAGE:figures/full_fig_p011_8.png]
Figure 9
Figure 9. Figure 9: Percentage share of each stage in total L1 batch sealing time. Confirms the dominant contribution of Merkle tree computation and illustrates benefits [PITH_FULL_IMAGE:figures/full_fig_p012_9.png]
Figure 10
Figure 10. Figure 10: Detailed breakdown of L1 sealing stage durations. Emphasizes stage-level granularity for optimization in future prover implementations. [PITH_FULL_IMAGE:figures/full_fig_p012_10.png]

Discussion (0). Sign in to comment.

Reference graph

Works this paper leans on

27 extracted references · 21 canonical work pages

  1. [1]

    Ethereum: A Next-Generation Smart Contract and Decen- tralized Application Platform

    V . Buterin, “Ethereum: A Next-Generation Smart Contract and Decen- tralized Application Platform.” 2014

    work page 2014

  2. [2]

    Bitcoin: A Peer-to-Peer Electronic Cash System,

    S. Nakamoto, “Bitcoin: A Peer-to-Peer Electronic Cash System,” 2008

    2008

  3. [3]

    SoK: Decentralized Finance (DeFi) - Fundamentals, Taxonomy and Risks,

    K. Gogol, C. Killer, M. Schlosser, T. Boeck, and B. Stiller, “SoK: Decentralized Finance (DeFi) - Fundamentals, Taxonomy and Risks,” arXiv preprint arXiv:2404.11281 , 2023

    arXiv 2023

  4. [4]

    Sok: Decentralized finance (defi),

    S. M. Werner, D. Perez, L. Gudgeon, A. Klages-Mundt, D. Harz, and W. J. Knottenbelt, “Sok: Decentralized finance (defi),” 2022

    work page 2022

  5. [5]

    Decentralized finance: On blockchain- and smart contract- based financial markets,

    F. Sch ¨ar, “Decentralized finance: On blockchain- and smart contract- based financial markets,” 2020. [Online]. Available: https://ssrn.com/ abstract=3571335orhttp://dx.doi.org/10.2139/ssrn.3571335

    work page doi:10.2139/ssrn.3571335 2020

  6. [6]

    The technology of decentralized finance (defi),

    R. Auer, B. Haslhofer, S. Kitzler, P. Saggese, and F. Victor, “The technology of decentralized finance (defi),” 2023

    work page 2023

  7. [7]

    Total Value Locked All Chains,

    DeFi Llama, “Total Value Locked All Chains,” 2024, accessed on February 7, 2025. [Online]. Available: https://defillama.com/chains

    work page 2024

  8. [8]

    The scalability challenge of ethereum: An initial quantitative analysis,

    M. Bez, G. Fornari, and T. Vardanega, “The scalability challenge of ethereum: An initial quantitative analysis,” 2019

    work page 2019

Show all 27 references
  1. [9]

    Blockchain Scaling Using Rollups: A Comprehensive Survey,

    L. T. Thibault, T. Sarry, and A. S. Hafid, “Blockchain Scaling Using Rollups: A Comprehensive Survey,” 2022

    2022

  2. [10]

    Shades of Finality and Layer 2 Scaling,

    B. Yee, D. Song, P. McCorry, and C. Buckland, “Shades of Finality and Layer 2 Scaling,” 2022

    2022

  3. [11]

    zksync era: Overview,

    ZKSync, “zksync era: Overview,” 2024

    2024

  4. [12]

    Scaling Actitivy,

    L2Beat, “Scaling Actitivy,” 2024, accessed on February 7, 2025. [Online]. Available: https://l2beat.com/scaling/activity

    2024

  5. [13]

    Rollup Gas per Second (GPS),

    ConduitXYZ, “Rollup Gas per Second (GPS),” 2024, accessed on February 7, 2025. [Online]. Available: https://rollup.wtf/

    2024

  6. [14]

    SoK: Decentralized exchanges (DEX) with automated market maker (AMM) protocols,

    J. Xu, K. Paruch, S. Cousaert, and Y . Feng, “SoK: Decentralized exchanges (DEX) with automated market maker (AMM) protocols,” ACM Computing Surveys, vol. 55, no. 11, pp. 1–50, feb 2023. [Online]. Available: https://doi.org/10.1145%2F3570639

    2023

  7. [15]

    Ethereum, smart contracts and the optimistic roll-up,

    M. Armstrong, “Ethereum, smart contracts and the optimistic roll-up,” 2021

    2021

  8. [16]

    Analyzing and Benchmarking ZK-Rollups,

    S. Chaliasos, I. Reif, A. Torralba-Agell, J. Ernstberger, A. Kattis, and B. Livshits, “Analyzing and Benchmarking ZK-Rollups,”6th Conference on Advances in Financial Technologies (AFT 2024) , 2024

    2024

  9. [17]

    Quan- tifying arbitrage in automated market makers: An empirical study of ethereum zk rollups,

    K. Gogol, J. Messias, D. Miori, C. Tessone, and B. Livshits, “Quan- tifying arbitrage in automated market makers: An empirical study of ethereum zk rollups,” 2024

    2024

  10. [18]

    SoK: Decentralized Exchanges (DEX) with Automated Market Maker (AMM) Protocols,

    J. Xu, K. Paruch, S. Cousaert, and Y . Feng, “SoK: Decentralized Exchanges (DEX) with Automated Market Maker (AMM) Protocols,” 2021

    2021

  11. [19]

    A Comprehensive Review of Blockchain Consensus Mechanisms,

    B. Lashkari and P. Musilek, “A Comprehensive Review of Blockchain Consensus Mechanisms,” IEEE Access, 2021

    2021

  12. [20]

    SoK: Sharding on Blockchain,

    G. Wang, Z. J. Shi, M. Nixon, and S. Han, “SoK: Sharding on Blockchain,” in Proceedings of the 1st ACM Conference on Advances in Financial Technologies, 2019

    2019

  13. [21]

    Layer 2 blockchain scaling: a survey,

    C. Sguanci, R. Spatafora, and A. M. Vergani, “Layer 2 blockchain scaling: a survey,” arXiv preprint arXiv:2107.10881 , 2021

    2021 arXiv

  14. [22]

    A Survey of Layer-Two Blockchain Protocols,

    A. Gangwal, H. R. Gangavalli, and A. Thirupathi, “A Survey of Layer-Two Blockchain Protocols,” Journal of Network and Computer Applications, Vol 209, 2022

    2022

  15. [23]

    Blockchain Scaling Using Rollups: A Comprehensive Survey,

    L. T. Thibault, T. Sarry, and A. S. Hafid, “Blockchain Scaling Using Rollups: A Comprehensive Survey,” IEEE Access, 2022

    2022

  16. [24]

    Towards a formal foundation for blockchain rollups,

    B. L. Stefanos Chaliasos, Denis Firsov, “Towards a formal foundation for blockchain rollups,” arXiv preprint arXiv:2406.16219 , 2024. [Online]. Available: https://arxiv.org/abs/2406.16219

    2024

  17. [25]

    SoK: Decentralized Se- quencers for Rollups,

    S. Motepalli, L. Freitas, and B. Livshits, “SoK: Decentralized Se- quencers for Rollups,” arXiv preprint arXiv:2310.03616 , 2023

    2023 arXiv

  18. [26]

    (2024) Rollup amm tps test: Transaction generator

    github.com/bogatyy. (2024) Rollup amm tps test: Transaction generator. Online, accessed: 2024-10-25. [Online]. Available: https://github.com/ bogatyy/rollup-amm-tps-test/tree/main

    2024

  19. [27]

    Waiting for Tree

    T. generator. (2024) Generator of amm swaps. [Online]. Available: https://gitlab.uzh.ch/szczepandominik.gurgul/amm-transactiongenerator APPENDIX APPENDIX : DETAILED BATCH SEALING BREAKDOWN This appendix provides a deeper view into the internal execution stages involved in fina...

    2024

Pith tools

Reviewed August 7, 2026 · model on record in the stance chip above.