Pith. sign in

REVIEW 3 major objections 6 minor 21 references

Decoupling Trusted Setup from Rollup Throughput

Reviewed by Pith at T0; open to challenge. T0 means a machine referee read the full paper against a public rubric. the ladder, T0–T4 →

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

T0 review · glm-5.2

2026-07-09 00:20 UTC pith:DZRDYXSS

load-bearing objection New systems idea (decentralized L2 as coordination layer for recurring CRS ceremonies), but the headline decoupling claim is never tested concurrently — and throughput numbers use dummy proofs. the 3 major comments →

arxiv 2607.05776 v1 pith:DZRDYXSS submitted 2026-07-07 cs.DC

Layer 2 Coordinated Trusted Setup for Continuous CRS Generation

Khalid Hassan , Sara Rouhani This is my paper
classification cs.DC
keywords trusted setupCRS generationZK-rollupPBFT consensusdecentralized sequencerLayer 2Powers of Taucommit-reveal
verification ladder T0 review T1 audit T2 compute T3 formal T4 reserved

The pith

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

The paper argues that a decentralized, PBFT-coordinated ZK-rollup sequencer network can safely decouple its high-throughput transaction processing pipeline from the execution of continuous, recurring trusted setup ceremonies. The central mechanism is the isolation of ceremony liveness: by running CRS generation either through an on-chain smart contract or through an asynchronous peer-to-peer consensus variant, ceremony latency and multi-round coordination overhead do not degrade transaction throughput. The paper demonstrates this through a Golang implementation of a decentralized ZK-rollup with a PBFT sequencer network, where rotating subsets of sequencers periodically execute Powers of Tau-style multi-party CRS generation. The key claim is that this decoupling works: ceremonies complete reliably within practical time bounds (47-275 seconds depending on configuration) even under node dropouts and malicious contributions, while the transaction pipeline sustains approximately 41,000 transactions per second.

Core claim

The core discovery is that trusted setup ceremonies and high-throughput transaction processing, which have fundamentally different operational characteristics, can be co-located on the same decentralized sequencer network without either degrading the other. The paper shows that by decoupling ceremony execution from the transaction pipeline and employing commit-reveal structures with PBFT-validated contribution steps, the system can handle adversarial conditions (random disconnections, invalid contributions) through timeout-based participant exclusion and consensus-level rejection, allowing all ceremonies to complete without restart. The CRS size is dominated by the power parameter ratherthan

What carries the argument

PBFT consensus + Powers of Tau MPC + commit-reveal + epoch-based CRS lifecycle

Load-bearing premise

The evaluation was conducted on a single machine with nodes communicating over localhost using dummy ZK proofs rather than real proof generation, so the claimed throughput and ceremony completion times may not reflect performance under wide-area network conditions with actual cryptographic proof computation.

What would settle it

If real ZK proof generation overhead or wide-area network latency significantly degrades either transaction throughput or ceremony completion time beyond the paper's reported bounds, the central claim of safe decoupling would not hold in practice.

Watch this falsifier — get emailed when new claim-graph text bears on it.

If this is right

  • If the decoupling holds at scale, Layer 2 networks could host continuous trusted setup as a native protocol service, eliminating the need for standalone ceremony coordination infrastructure.
  • The epoch-based CRS lifecycle with rotating participant subsets could reduce long-term trust concentration in ZK systems, since compromise of one ceremony round is temporally bounded and does not affect subsequent rounds.
  • The framework could be extended to support other multi-round cryptographic ceremonies beyond CRS generation, potentially broadening the role of rollup sequencer networks from transaction processing to general-purpose decentralized coordination.
  • If real ZK proof generation overhead is comparable to the dummy proofs used in evaluation, the claimed throughput may not hold, necessitating end-to-end testing with actual proof generation.

Where Pith is reading between the lines

These are editorial extensions of the paper, not claims the author makes directly.

  • The single-machine localhost simulation with 3-12 nodes likely underestimates ceremony completion times for geographically distributed sequencer networks, where WAN latency and packet loss would increase PBFT consensus rounds per contribution.
  • The smart contract variant may face gas cost issues on production L2 systems for large CRS sizes, since each contribution update requires an on-chain transaction; the P2P variant avoids this but requires all participants to maintain replicated ceremony state.
  • The reputation mechanism for penalizing disruptive behavior is mentioned but not formally analyzed; its effectiveness against strategic adversarial behavior (e.g., griefing attacks where malicious nodes join ceremonies solely to trigger timeouts) remains untested.
  • The claim that CRS size grows marginally with participant count suggests that larger participant sets for enhanced security are feasible from a storage perspective, but the linear increase in ceremony duration with participants may impose a practical upper bound on decentralization of each ceremony round.

Editorial analysis

A structured set of objections, weighed in public.

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

Referee Report

3 major / 6 minor

Summary. The paper proposes an L2-coordinated framework for continuous CRS (Common Reference String) generation, leveraging a decentralized PBFT-based sequencer network to transform trusted setup from a one-time ceremony into a recurring protocol service. Two coordination variants are presented: an on-chain smart contract approach and an asynchronous P2P consensus variant. Both use commit-reveal structures and NIZK proofs of knowledge to prevent adaptive manipulation. The framework is implemented in Golang using libp2p, and evaluated on transaction throughput (3 nodes, up to 100k transactions) and CRS ceremony completion time (6–12 nodes, power sizes 8–12, under adversarial conditions). The security analysis inherits the standard Powers of Tau trust model (at least one honest participant per round) and argues a 'temporally bounded compromise' property from the independence of ceremony rounds.

Significance. The idea of using a decentralized sequencer network as a coordination substrate for recurring trusted setup ceremonies is a reasonable architectural contribution, and the implementation is publicly available on GitHub, which supports reproducibility. The security analysis is correct in inheriting the standard PoT trust model and does not overclaim novel cryptographic guarantees. The commit-reveal integration and epoch-based CRS lifecycle management are sensible design choices. However, the paper's central empirical claim — that ceremony execution does not degrade transaction pipeline performance — is not actually tested, which significantly limits the significance of the evaluation.

major comments (3)
  1. §VI, Abstract, Contribution 3: The paper's central claim is that the framework 'safely decouples transaction pipelines from ceremony execution' and 'preserving stable L2 transaction throughput.' However, no experiment runs both systems concurrently. §VI.A measures throughput (3 nodes, ~41,000 tx/sec) with no ceremony running and with dummy proofs (§V.A). §VI.B measures ceremony completion time (6–12 nodes) with no transaction load. The decoupling is asserted architecturally but never empirically validated. This is load-bearing: if PBFT consensus rounds for ceremony state updates (§III.C.2: 'Following each contribution, the updated state is validated and agreed upon through PBFT before the next participant proceeds') share the same consensus pipeline as transaction batching, throughput degradation could occur. For power size 12 with 12 participants, this means 12+ sequential PBFT rounds.
  2. §V.A: The rollup uses 'dummy proofs' instead of real zkSNARK proofs. The throughput of ~41,000 tx/sec therefore does not reflect the cost of actual proof generation and verification. Since the paper's claim includes 'preserving stable L2 transaction throughput,' the baseline throughput itself is inflated. The paper should either run experiments with real proof generation or explicitly scope the throughput claim to the sequencing/consensus layer only, excluding proof generation.
  3. §VI and Abstract: The paper claims experiments were conducted 'under simulated wide-area network constraints,' but §VI describes only a single-machine deployment where nodes communicate via libp2p on localhost. No description is given of how WAN latency, bandwidth constraints, or packet loss were simulated. Real WAN conditions would affect PBFT consensus latency, ceremony completion times, and throughput. Either the WAN simulation methodology must be described in detail, or the claim should be removed.
minor comments (6)
  1. §III.B: The reputation mechanism is mentioned ('penalizes disruptive behavior,' 'eventual exclusion') but never formally specified. What are the exact penalty values? How is reputation computed? Is this a load-bearing component or an informal design note?
  2. Figure 5 shows CRS sizes for Power 14 and Power 16, but the evaluation in §VI.B only tests power sizes 8, 10, and 12. The figure should either be scoped to tested values or the evaluation should be extended.
  3. §VI.A: The throughput evaluation uses only 3 nodes. Given that the ceremony evaluation uses 6–12 nodes, the throughput experiment should at minimum use a consistent node count, or the discrepancy should be justified.
  4. §III.C.1, Step 4 (Finalization): The text says 'commitments are revealed to ensure the integrity of the final generated CRS' after all contributions are applied. It would help to clarify what verification is performed during reveal — is it just checking that the committed hash matches, or is there a proof of correct contribution?
  5. §IV.D: The commit-reveal description is conceptual. A more formal treatment (e.g., what happens if a participant commits but fails to reveal) would strengthen the security argument.
  6. Table I: The 'Type' field lists 'Preprepare' (one word) while §III.B uses 'Pre-prepare' (hyphenated). Consistent terminology would help.

Simulated Author's Rebuttal

3 responses · 0 unresolved

We thank the referee for a careful and constructive review. The referee identifies three major concerns: (1) the central claim that ceremony execution does not degrade transaction throughput is never empirically tested by running both concurrently, (2) the throughput baseline uses dummy proofs rather than real zkSNARK proofs, inflating the reported numbers, and (3) the claim of 'simulated wide-area network constraints' is unsupported because all experiments run on a single machine over localhost. We agree with all three points. In the revised manuscript, we will (1) add a concurrent-execution experiment measuring throughput during active CRS ceremonies, (2) explicitly scope the throughput claim to the sequencing/consensus layer and clarify that dummy proofs are used, and (3) either describe the WAN simulation methodology in detail or remove the WAN claim. We do not believe any of the referee's comments are unanswerable, though the concurrent-execution experiment requires additional work that we commit to completing in the revision.

read point-by-point responses

  1. Referee: §VI, Abstract, Contribution 3: The paper's central claim is that the framework 'safely decouples transaction pipelines from ceremony execution' and 'preserving stable L2 transaction throughput.' However, no experiment runs both systems concurrently. §VI.A measures throughput (3 nodes, ~41,000 tx/sec) with no ceremony running and with dummy proofs (§V.A). §VI.B measures ceremony completion time (6–12 nodes) with no transaction load. The decoupling is asserted architecturally but never empirically validated. This is load-bearing: if PBFT consensus rounds for ceremony state updates share the same consensus pipeline as transaction batching, throughput degradation could occur. For power size 12 with 12 participants, this means 12+ sequential PBFT rounds.

    Authors: The referee is correct. The current evaluation measures transaction throughput and ceremony completion time in isolation, and the decoupling claim is supported only architecturally, not empirically. We acknowledge this is a significant gap. In the revised manuscript, we will add a concurrent-execution experiment that runs transaction load and CRS ceremony execution simultaneously, measuring throughput degradation (if any) during active ceremony rounds. This will directly test whether the 12+ sequential PBFT rounds for ceremony state updates (at power size 12, 12 participants) interfere with transaction batching on the shared consensus pipeline. We will report throughput before, during, and after ceremony execution. If degradation is observed, we will report it honestly and discuss mitigation strategies (e.g., prioritizing transaction batches, or using a separate consensus channel for ceremony state). The abstract and Contribution 3 will be revised to reflect what is actually measured. revision: yes

  2. Referee: §V.A: The rollup uses 'dummy proofs' instead of real zkSNARK proofs. The throughput of ~41,000 tx/sec therefore does not reflect the cost of actual proof generation and verification. Since the paper's claim includes 'preserving stable L2 transaction throughput,' the baseline throughput itself is inflated. The paper should either run experiments with real proof generation or explicitly scope the throughput claim to the sequencing/consensus layer only, excluding proof generation.

    Authors: The referee is correct. The use of dummy proofs means the reported throughput of ~41,000 tx/sec reflects only the sequencing and consensus layer, not the full cost of zkSNARK proof generation and verification. We will explicitly scope the throughput claim in the revised manuscript to 'sequencing and consensus layer throughput, excluding proof generation,' and add a clear statement in §V.A that dummy proofs are used. We chose dummy proofs because the paper's architectural contribution is the coordination framework for CRS lifecycle management, not a novel prover implementation. However, we agree that the current phrasing in the abstract and contributions overclaims what is measured. We will also add a discussion of how real proof generation would affect throughput, referencing typical prover costs from the literature, and note that integrating a production-grade prover is future work. revision: yes

  3. Referee: §VI and Abstract: The paper claims experiments were conducted 'under simulated wide-area network constraints,' but §VI describes only a single-machine deployment where nodes communicate via libp2p on localhost. No description is given of how WAN latency, bandwidth constraints, or packet loss were simulated. Real WAN conditions would affect PBFT consensus latency, ceremony completion times, and throughput. Either the WAN simulation methodology must be described in detail, or the claim should be removed.

    Authors: The referee is correct. The manuscript does not describe any WAN simulation methodology — no latency injection, bandwidth throttling, or packet loss simulation is applied. All nodes communicate via libp2p on localhost. The phrase 'simulated wide-area network constraints' in the abstract and §VI is misleading and should not have been included without a corresponding methodology description. In the revised manuscript, we will remove the WAN claim from the abstract and §VI, and clearly state that experiments were conducted on a single machine with nodes communicating over localhost. We will add a discussion of this as a limitation and note that evaluating under real WAN conditions (using network emulation tools such as tc/netem or a geo-distributed deployment) is important future work, since PBFT consensus latency and ceremony completion times would be affected by network delay. revision: yes

Circularity Check

0 steps flagged

No circularity found: security properties inherit standard PoT assumptions, experimental results are independent measurements

full rationale

The paper's derivation chain is self-contained and does not exhibit circularity. The security analysis (Section IV) explicitly inherits the standard Powers of Tau trust model from [8] (Nikolaenko et al., a fully external citation with no author overlap): 'The proposed scheme follows the standard trust model of PoT-style multi-party trusted setup ceremonies [8]... Security relies on the assumption that at least one participant in a given round behaves honestly.' This is a stated assumption, not a derived result, so there is no self-definitional loop. The 'temporally bounded compromise' property (Section IV.E) follows straightforwardly from the independence of ceremony rounds and fresh randomness per round — it is a logical consequence of the protocol design, not a circular restatement. The experimental results (Section VI) are empirical measurements: throughput is measured by submitting transaction batches (Figure 3), ceremony completion times are measured under adversarial conditions (Figure 4), and CRS sizes are measured directly (Figure 5). No parameter is fitted to a subset of data and then 'predicted' on related data. The two protocol variants (smart contract and P2P) are described architecturally and evaluated independently. While the reader correctly notes that the decoupling claim is not empirically validated under concurrent load and that dummy proofs inflate throughput, these are correctness and completeness concerns — not circularity. The paper does not define a quantity in terms of itself, rename a known result as a derivation, or smuggle an ansatz through self-citation. The one self-citation [6] (Hassan et al.) concerns blockchain interoperability and is not load-bearing for any security or performance claim in this paper.

Axiom & Free-Parameter Ledger

3 free parameters · 5 axioms · 2 invented entities

Legacy field mirrored from axiom_ledger.axioms.

free parameters (3)
  • roundDuration
    Smart contract parameter controlling ceremony round duration; set during deployment but value not specified in the paper.
  • maxParticipants
    Smart contract parameter limiting ceremony participants; set during deployment but value not specified.
  • CRS power size (8, 10, 12) = 8, 10, 12
    Determines CRS size and ceremony computational cost; chosen for evaluation but not derived from any optimality criterion.
axioms (5)
  • standard math Hardness of the Elliptic Curve Discrete Logarithm Problem (ECDLP)
    Invoked in Section III.C and Section IV.B as the cryptographic foundation ensuring that individual participant contributions cannot be reversed, even if all other participants collude.
  • standard math Collision resistance of the commitment hash function H
    Invoked in Section IV.A as a standard cryptographic assumption underpinning the commit-reveal scheme.
  • domain assumption At least one participant in each ceremony round behaves honestly and destroys their secret randomness
    Stated in Section IV.B: 'Security relies on the assumption that at least one participant in a given round behaves honestly and does not reveal or retain its secret randomness after contributing.' This is the standard PoT trust model, inherited by the protocol.
  • domain assumption PBFT fault tolerance threshold (n >= 3f+1) holds in the sequencer network
    Implicit in Section III.B and Section IV.A: the PBFT consensus protocol provides fault-tolerant agreement 'within its standard fault threshold,' meaning the adversary controls fewer than one-third of nodes.
  • ad hoc to paper Single-machine simulation with localhost communication approximates WAN deployment behavior
    Section VI states experiments use 'a simulated distributed environment hosted on a machine' but does not describe how WAN latency or packet loss was simulated. This unstated assumption underlies all experimental claims.
invented entities (2)
  • CRSCeremonyState (shared ceremony state structure) independent evidence
    purpose: Replicates ceremony round, participant set, current step, and intermediate CRS across sequencer nodes for P2P-coordinated CRS generation.
    This is a protocol data structure, not a new physical or mathematical entity. It is implemented in code and its behavior is tested in the evaluation.
  • Reputation mechanism for sequencer nodes no independent evidence
    purpose: Penalizes disruptive behavior (disconnections, invalid contributions) and excludes repeat offenders from consensus and CRS generation rounds.
    Mentioned in Section III.B but not formally specified, implemented in detail, or evaluated. The reputation scoring rules, penalty magnitudes, and threshold for exclusion are not described.

pith-pipeline@v1.1.0-glm · 13864 in / 4539 out tokens · 275863 ms · 2026-07-09T00:20:21.081984+00:00 · methodology

0 comments
read the original abstract

Zero-knowledge proof systems rely on a trusted setup phase to generate a Common Reference String (CRS), yet existing approaches are typically static, one-time ceremonies that are inflexible and vulnerable to long-term compromise. Offloading continuous, recurring trusted setups to a decentralized Layer 2 (L2) network introduces a fundamental coordination challenge arising from the mismatch between high-throughput transaction processing and the multi-round requirements of trusted setup ceremonies. This paper presents an L2-coordinated framework that safely decouples transaction pipelines from ceremony execution to achieve automated, continuous CRS generation without centralized coordination. We design and implement two protocol variants over a decentralized, PBFT-coordinated ZK-rollup architecture: an on-chain smart contract approach and an asynchronous peer-to-peer consensus variant. Both designs utilize non-interactive zero-knowledge proofs of knowledge alongside commit-reveal structures to eliminate adaptive manipulation vectors and isolate ceremony latency. Experimental evaluations under simulated wide-area network constraints and adversarial conditions demonstrate that our architecture successfully isolates ceremony liveness. Continuous setups complete reliably within practical time bounds despite node dropouts or malicious contributions, while preserving stable L2 transaction throughput.

Figures

Figures reproduced from arXiv: 2607.05776 by Khalid Hassan, Sara Rouhani.

Figure 2
Figure 2. Figure 2: Decentralized Sequencer Architecture C. Decentralized CRS Generation ZKPs are cryptographic protocols that enable one party, the prover, to convince another party, the verifier, of the validity of a statement without revealing any additional information. Among the various classes of ZKPs, zkSNARKs (Zero￾Knowledge Succinct Non-Interactive Arguments of Knowl￾edge) are particularly well-suited for blockchain … view at source ↗
Figure 1
Figure 1. Figure 1: Centralized Sequencer Architecture Beyond improving fault tolerance, decentralized sequencing distributes control over transaction inclusion and ordering across multiple participants, reducing censorship risks and increasing resilience against node failures and targeted at￾tacks. Consensus-based coordination also provides a globally consistent view of system state, enabling sequencers to agree on protocol … view at source ↗
Figure 3
Figure 3. Figure 3: ZK-Rollup Transaction Throughput B. Decentralized CRS Generation The decentralized CRS generation ceremony was evaluated using a testbed designed to measure both its performance and its fault tolerance. Extensive tests were conducted under normal and adversarial conditions to ensure the robustness of the system. The testbed employed two network configurations, one consisting of 6 nodes while the other cons… view at source ↗
Figure 5
Figure 5. Figure 5: CRS Size Correlation with Number of Participants [PITH_FULL_IMAGE:figures/full_fig_p008_5.png] view at source ↗
Figure 4
Figure 4. Figure 4: Decentralized CRS Generation Ceremony Durations [PITH_FULL_IMAGE:figures/full_fig_p008_4.png] view at source ↗

discussion (0)

Sign in with ORCID, Apple, or X to comment. Anyone can read and Pith papers without signing in.

Reference graph

Works this paper leans on

21 extracted references · 21 canonical work pages · 3 internal anchors

  1. [1]

    A review of blockchain platforms based on the scalability, security and decentralization trilemma,

    J. Werth, M. H. Berenjestanaki, H. R. Barzegar, N. E. Ioini, and C. Pahl, “A review of blockchain platforms based on the scalability, security and decentralization trilemma,” inInternational Conference on Enterprise Information Systems, 2023. [Online]. Available: https://api.semanticscholar.org/CorpusID:258369909

    work page 2023

  2. [2]

    Ethereum white paper: A next generation smart contract & decentralized application platform,

    V . Buterin, “Ethereum white paper: A next generation smart contract & decentralized application platform,” 2013. [Online]. Available: https://github.com/ethereum/wiki/wiki/White-Paper

    work page 2013

  3. [3]

    A comprehensive review of blockchain technology: Underlying principles and historical background with future challenges,

    G. Tripathi, M. A. Ahad, and G. Casalino, “A comprehensive review of blockchain technology: Underlying principles and historical background with future challenges,”Decision Analytics Journal, vol. 9, p. 100344, 2023. [Online]. Available: https://www.sciencedirect.com/science/article/pii/S2772662223001844

    work page 2023

  4. [4]

    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, p. 103539, 2023

    work page 2023

  5. [5]

    Layer 2 trade-offs: Evaluating privacy, security, and decentralization in ethereum scaling,

    V . Pareek, K. Kumawat, A. Tiwari, and T. Sunil, “Layer 2 trade-offs: Evaluating privacy, security, and decentralization in ethereum scaling,” in2025 IEEE International Conference on Blockchain and Distributed Systems Security (ICBDS). IEEE, 2025, pp. 1–5

    work page 2025

  6. [6]

    Sok: Systematizing blockchain inter- operability through layered architecture and layer 2 interoperability,

    K. Hassan, A. Nik, A. Sokhankhosh, K. Esmaeilzadeh Khorasani, S. Moradi, and S. Rouhani, “Sok: Systematizing blockchain inter- operability through layered architecture and layer 2 interoperability,” Distributed Ledger Technologies: Research and Practice, 2025

    work page 2025

  7. [7]

    SoK: Decentralized Sequencers for Rollups

    S. Motepalli, L. Freitas, and B. Livshits, “Sok: Decentralized sequencers for rollups,”arXiv preprint arXiv:2310.03616, 2023

    work page internal anchor Pith review Pith/arXiv arXiv 2023

  8. [8]

    Powers- of-tau to the people: Decentralizing setup ceremonies,

    V . Nikolaenko, S. Ragsdale, J. Bonneau, and D. Boneh, “Powers- of-tau to the people: Decentralizing setup ceremonies,” inApplied Cryptography and Network Security, C. P ¨opper and L. Batina, Eds. Cham: Springer Nature Switzerland, 2024, pp. 105–134

    work page 2024

  9. [10]

    A Decentralized Sequencer and Data Availability Committee for Rollups Using Set Consensus

    [Online]. Available: https://arxiv.org/abs/2503.05451

    work page internal anchor Pith review Pith/arXiv arXiv

  10. [11]

    ChonkyBFT: Consensus Protocol of ZKsync

    B. Franc ¸a, D. Kolegov, I. Konnov, and G. Prusak, “Chonkybft: Consensus protocol of zksync,” 2025. [Online]. Available: https://arxiv.org/abs/2503.15380

    work page internal anchor Pith review Pith/arXiv arXiv 2025

  11. [12]

    The espresso sequencing network: Hotshot consensus, tiramisu data-availability, and builder-exchange,

    J. Bearer, B. B ¨unz, P. Camacho, B. Chen, E. Davidson, B. Fisch, B. Fish, G. Gutoski, F. Krell, C. Linet al., “The espresso sequencing network: Hotshot consensus, tiramisu data-availability, and builder-exchange,” Cryptology ePrint Archive, 2024

    work page 2024

  12. [13]

    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, vol. 10, pp. 93 039– 93 054, 2022

    work page 2022

  13. [14]

    Ethereum, smart contracts and the optimistic roll- up,

    M. Armstrong, “Ethereum, smart contracts and the optimistic roll- up,” Ph.D. dissertation, BSc Dissertation: University of Dublin, Trinity College, 2021

    work page 2021

  14. [15]

    Analyzing and benchmarking zk-rollups,

    S. Chaliasos, I. Reif, A. Torralba-Agell, J. Ernstberger, A. Kattis, and B. Livshits, “Analyzing and benchmarking zk-rollups,” in6th Conference on Advances in Financial Technologies (AFT 2024). Schloss Dagstuhl– Leibniz-Zentrum f ¨ur Informatik, 2024, pp. 6–1

    work page 2024

  15. [16]

    Attacks on rollups,

    A. Koegl, Z. Meghji, D. Pellegrino, J. Gorzny, and M. Derka, “Attacks on rollups,” inProceedings of the 4th International Workshop on Distributed Infrastructure for the Common Good, 2023, pp. 25–30

    work page 2023

  16. [17]

    Promise of zero-knowledge proofs (zkps) for blockchain privacy and security: Opportunities, chal- lenges, and future directions,

    N. R. CHIRAKAROTU and P. P. KUMAR, “Promise of zero-knowledge proofs (zkps) for blockchain privacy and security: Opportunities, chal- lenges, and future directions,”Security and Privacy, 2024

    work page 2024

  17. [18]

    Privacy-preserving solutions for blockchain: Review and challenges,

    J. B. Bernabe, J. L. Canovas, J. L. Hernandez-Ramos, R. T. Moreno, and A. Skarmeta, “Privacy-preserving solutions for blockchain: Review and challenges,”Ieee Access, vol. 7, pp. 164 908–164 940, 2019

    work page 2019

  18. [19]

    A survey on zero-knowledge proof in blockchain,

    X. Sun, F. R. Yu, P. Zhang, Z. Sun, W. Xie, and X. Peng, “A survey on zero-knowledge proof in blockchain,”IEEE Network, vol. 35, no. 4, pp. 198–205, 2021

    work page 2021

  19. [20]

    Scalable multi-party computation for zk-snark parameters in the random beacon model,

    S. Bowe, A. Gabizon, and I. Miers, “Scalable multi-party computation for zk-snark parameters in the random beacon model,” IACR Cryptol. ePrint Arch., p. 1050, 2017. [Online]. Available: http://eprint.iacr.org/2017/1050

    work page 2017

  20. [21]

    (2025) libp2p

    Protocol Labs. (2025) libp2p. Accessed: 2025-06-21. [Online]. Available: https://pkg.go.dev/github.com/libp2p/go-libp2p

    work page 2025

  21. [22]

    Kademlia: A peer-to-peer infor- mation system based on the xor metric,

    P. Maymounkov and D. Mazi `eres, “Kademlia: A peer-to-peer infor- mation system based on the xor metric,” inPeer-to-Peer Systems, P. Druschel, F. Kaashoek, and A. Rowstron, Eds. Berlin, Heidelberg: Springer Berlin Heidelberg, 2002, pp. 53–65

    work page 2002