Pith. sign in

REVIEW 4 major objections 5 minor 68 references

PANDAS: Peer-to-peer, Adaptive Networking for Data Availability Sampling within Ethereum Consensus Timebounds

T0 review · 4 major / 5 minor · reviewed 2026-08-06 · deepseek-v4-flash

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

Pith's one-line read PANDAS claims layer-2 blob data can be disseminated and availability-sampled within Ethereum's four-second consensus window, making the tight fork-choice rule viable without consensus modifications.

desk verdict A genuinely new DAS protocol with a substantial evaluation, but the headline 4-second guarantee is measured on cell reception only, not on the full block-plus-verification path the tight fork-choice rule actually requires. read the letter →

arxiv 2507.00824 v1 pith:BOSNWFGX submitted 2025-07-01 cs.DC cs.NIcs.PF

Matthieu Pigaglio , Onur Ascigil , Micha{l} Król , Sergi Rene , Felix Lange , Kaleem Peeroo , Ramin Sadre , Vladimir Stankovic
show 1 more author
Etienne Rivière
This is my paper · ORCID
classification cs.DCcs.NIcs.PF
keywords dataavailabilitysamplingEthereumDankshardingpeer-to-peernetworkingadaptivefetchingerasurecodingconsensustimeboundslayer-2scaling
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

PANDAS is a peer-to-peer protocol designed to prove that data availability sampling (DAS) for Ethereum's Danksharding can fit inside the four-second window in which consensus committees must attest to a new block. If the proof holds, layer-2 blob data no longer has to be broadcast to every node; instead, the 32 MB blob can be erasure-coded into 140 MB of cells, distributed selectively, and verified by random sampling within the slot deadline. This would let Ethereum keep its tight fork-choice rule and avoid consensus changes to revert blocks with unavailable data. The paper evaluates a 1,000-node prototype and simulations up to 20,000 nodes, reporting that all nodes complete sampling within four seconds at moderate scale.

What carries the argument

The load-bearing mechanism is a deterministic, short-lived assignment $\sigma(n_i,e)$ that maps each node to eight rows and eight columns of the $512\times 512$ erasure-coded blob matrix, using a pseudo-random sortition seeded by the same RANDAO epoch seed that selects Ethereum committees. Because every node and builder computes $\sigma$ identically from public epoch seeds, any node can determine who should custody any cell without a DHT lookup. Around this assignment PANDAS runs three phases: the builder seeds cells and an optional consolidation-boost map directly to nodes over UDP; nodes consolidate missing assigned cells from peers that share rows or columns; and nodes sample 73 random cells concurrently. The adaptive fetching algorithm arbitrates the trade-off between message redundancy and time, starting with conservative single queries (400 ms round) and increasing query redundancy while shrinking timeouts as the four-second deadline approaches; Reed-Solomon erasure coding lets a node reconstruct any row or column once it holds half its cells.

What would settle it

Run the protocol on real Ethereum node-to-node latency measurements and start the clock when the block header actually arrives at each node; if header propagation plus sampling exceeds four seconds for a significant share of committee nodes, the central claim fails.

Watch

Extended reading notes

Core claim

On the paper's own terms, the central discovery is that direct, one-hop communication can replace multi-hop gossip as the carrier of DAS without overloading ordinary nodes or builders. PANDAS assigns each node eight rows and eight columns of the $512\times 512$ erasure-coded blob matrix through a deterministic, epoch-randomized sortition; the builder seeds cells directly to nodes; consolidation and sampling then run concurrently while an adaptive fetching algorithm escalates request redundancy as time runs out. The paper reports that at 1,000 nodes 100% of nodes fetch their 73 random samples by the deadline, that at 10,000 nodes all nodes still make it, and that at 20,000 nodes about 90% do, while GossipSub- and Kademlia-based baselines miss the deadline even at 1,000 nodes.

Load-bearing premise

The evaluation assumes nodes can begin receiving blob cells and sampling at the very start of the slot, before the block header that cryptographically commits to the blob has arrived through the gossip network; the paper itself notes that adding block dissemination time to its measured sampling times would put the four-second deadline at risk for many nodes.

Editorial extensions

If this is right

  • Committee members can attest to block validity and blob availability in the same four-second window, so the tight fork-choice rule becomes compatible with Danksharding without consensus-layer changes.
  • Layer-2 rollups can post 32 MB blobs without requiring every node to receive the full 140 MB erasure-coded extended blob; nodes only hold about 4.4 MB of assigned cells plus 40 KB of samples.
  • The four-second target is met at 10,000 nodes and for a majority at 20,000, while keeping node bandwidth below 25 Mbps and builder bandwidth below 10 Gbps.
  • GossipSub- and Kademlia-based DAS designs miss the deadline at 1,000 nodes in the paper's comparison, so direct one-hop fetching with adaptive redundancy is the necessary ingredient.
  • With up to 50% dead or out-of-view nodes, a majority of correct nodes still finish sampling within the deadline, and unavailable data is systematically detected.

Reading between the lines

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

  • If block-header propagation delay is genuinely part of the critical path, the paper's measured margin of roughly one second at 1,000 nodes shrinks; a testable extension would integrate PANDAS's trigger with header arrival and re-tune round timeouts accordingly.
  • PANDAS accepts unverified seed cells before the KZG commitment is known, trusting a proposer signature and builder incentives; an adversarial proposer-builder pair could feed nodes invalid cells, so the protocol implicitly relies on slashing or reputation to keep builders honest.
  • The RANDAO-seeded assignment is predictable one epoch (about 6.4 minutes) in advance, which is what makes eclipse and censorship attacks hard to time; the same predictability could be probed by an adversary who correlates assignment with node identity over many epochs.
  • The fixed round parameters (400 ms first timeout, doubling redundancy) are tuned to a particular all-pair latency trace; on networks with fatter tails the same parameters may not hold, suggesting an adaptive parameter-learning variant as a natural follow-up.
Share X Bluesky LinkedIn Reddit HN

Signed reviews

No signed human review yet.

Editorial analysis

A structured set of objections, weighed in public.

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

Referee Report

4 major / 5 minor

Summary. The paper proposes PANDAS, a peer-to-peer protocol for data availability sampling (DAS) in Ethereum's Danksharding roadmap. PANDAS assigns each node a deterministic set of blob rows and columns, has the block builder seed cells via direct UDP exchanges, and lets nodes consolidate missing cells and sample 73 random cells using an adaptive fetching algorithm. The stated goal is to complete dissemination and sampling within the four-second consensus window so that the tight fork-choice rule can be used without modifying Ethereum's consensus or discovery protocols. The paper reports a 1,000-node prototype on an emulated WAN and simulations up to 20,000 nodes, comparing against GossipSub- and Kademlia-based baselines, and claims that PANDAS meets the deadline at moderate scales and for the vast majority of nodes at large scales.

Significance. If the central timing claim were fully supported, PANDAS would address a real and important obstacle for Danksharding: completing DAS inside the four-second slot deadline would let committee members attest to blob availability simultaneously with block validity, avoiding changes to the fork-choice rule and the associated reversion risks. The paper's engineering contribution is substantial: a full libp2p-based implementation, a 1,000-node cluster deployment, a simulator cross-validated against the prototype (Section 8.2), and a clear comparison to GossipSub and DHT baselines. The fault experiments in Section 8.2 also provide useful evidence on robustness. However, as detailed below, the headline claim is currently measured against a metric that does not include the full end-to-end attestation path, and the published results themselves contain a 10% tail of deadline misses at 20,000 nodes. The protocol is plausible and the work is significant, but the evidence as presented does not yet establish the strong claim made in the abstract.

major comments (4)
  1. [Section 8.1, Figure 11d, Algorithm 1] The metric "time to sampling" is defined as the time when a node has received or reconstructed its 73 random cells, but it does not include the arrival of the block header via GossipSub nor the KZG verification of the sampled cells. Algorithm 1 explicitly defers those checks, stating they are performed "if/when the block header is available" (Section 7, Algorithm 1 comment). Under the tight fork-choice rule, an attestation requires both the block header containing the blob commitments and verified samples, so the relevant completion time is approximately max(header arrival, samples ready) plus verification time. The paper's own warning that adding block dissemination latency "would be at risk for many nodes" (Section 8.1) confirms that the reported 3,009 ms maximum for the redundant strategy leaves little margin. The paper should report the joint distribution of the end-to-end completion time, including the GossipSub header path and KZG verification, for both the 1,000-node deployment and the 20,000-node simulation.
  2. [Abstract, Section 8.2, Figure 15] The abstract states that PANDAS allows dissemination and sampling "within the 4-second deadline," but at 20,000 nodes the evaluation reports that 10% of nodes fail to meet the deadline (Section 8.2, Figure 15). The Introduction and Section 8.2 use the weaker phrase "vast majority," so the evidence supports a probabilistic claim with an explicit miss rate, not the unqualified deadline claim. Since Claim C1 in Section 8 states "PANDAS completes DAS within 4 s," the presentation should either revise the claim to quantify the tail probability under the intended consensus and attestation model, or provide additional evidence that the 10% tail is acceptable for the tight fork-choice rule.
  3. [Section 8.1, network emulation] The evaluation uses an all-pair latency trace from IPFS [45] as a proxy for Ethereum node-to-node latencies, with the explicit justification that no public Ethereum latency data exists. Because the four-second deadline is an Ethereum consensus requirement and the protocol's timing behavior (e.g., the seeding timeouts and fetching rounds in Section 7) depends directly on the latency distribution, this is a load-bearing assumption rather than a minor implementation detail. The paper should either provide a convincing argument that IPFS latencies are representative of Ethereum's node population, or perform a sensitivity analysis over plausible Ethereum-specific latency distributions and report how the deadline miss rate changes. This would also address the concern that the adaptive-fetching parameters were tuned to the same trace used for evaluation.
  4. [Section 7, default parameters] The default adaptive-fetching parameters (t1 = 400 ms, t2 = 200 ms, the redundancy schedule k1=1, k2=2, k3=4, and cb_boost = 10,000) are chosen based on the estimated timing of the builder's seeding and the inter-node latencies of the same emulated network used for the evaluation. No sensitivity analysis is reported, so it is unclear whether the 4-second guarantee survives plausible parameter variations or different network conditions. Since the paper claims robustness under "adverse environments" (Objective Robustness in Section 4.2), the authors should add a parameter-sensitivity study showing the range of t_i, k_i, and cb_boost values for which the deadline is still met.
minor comments (5)
  1. [Section 7, Algorithm 1 footnote] The footnote refers to "KZMPs" but the paper uses the abbreviation KZGP elsewhere; this appears to be a typo and should be corrected.
  2. [Section 8.1, consolidation timing] In the description of the minimal seeding strategy, the text states a consolidation time of "2,2213 ms," which appears to be a typo for 2,213 ms or 2,221 ms; please correct the digit grouping.
  3. [Section 8.2, simulation methodology] For simulations with more than 10,000 nodes, the paper states that vertices of the 10,000-node latency topology are reused randomly. This means multiple simulated nodes share the same network coordinates, which may reduce the effective diversity of the latency model at 20,000 nodes. This limitation should be stated explicitly and, if possible, supplemented with an alternative topology or a sensitivity check.
  4. [Section 8.1, Figure 11a] The block dissemination distribution is shown in Figure 11a but is not summarized with numerical values in the text. Given the major concern about the joint deadline, please state the maximum and P99 of the block dissemination time, and use them in the end-to-end analysis.
  5. [References] The 25 Mbps node bandwidth target is cited to a vendor guide (reference [1]). Please cite a canonical Ethereum documentation or specification source for this requirement if it is used as a normative bound.

Circularity Check

0 steps flagged · score 0.0 of 10

No significant circularity: PANDAS's 4-second claim is an empirically evaluated protocol outcome, not a quantity derived by construction from its own inputs.

full rationale

PANDAS is an engineering protocol, and its central claim (C1) that dissemination and sampling complete within 4 seconds is established by prototype deployment and simulation, not by an equation that assumes the deadline. The adaptive-fetching parameters are presented as tunable defaults ('We use the following universal parameters, but stress that nodes could select them differently, e.g., based on local connectivity'), and the evaluation shows that the deadline is not automatic: a constant-fetching variant misses it, and the GossipSub and DHT baselines also miss it. The simulator is validated against the libp2p prototype at 1,000 nodes before being used at larger scales, which is standard model calibration rather than circularity. The paper's own caveat in Section 8.1 that adding block-dissemination latency to sampling times 'would be at risk for many nodes, even with the redundant strategy' is an explicit scope limitation affecting the tight-fork-choice claim, but it is an empirical caveat, not a circular step. The only self-citations (e.g., Disc-NG [43] in the discussion of IP diversity) support secondary points and are not load-bearing for the deadline claim. No fitted parameter is renamed as a prediction, and no equation reduces to its own inputs.

Assumptions & free parameters 6 free parameters · 8 assumptions · 0 invented entities

The protocol rests on standard cryptographic and erasure-coding assumptions plus several domain assumptions about node views, builder behavior, and network latency. The hand-tuned parameters (timeouts, redundancy, cb_boost) are design choices, not fitted physical quantities, but they are load-bearing for the deadline result.

free parameters (6)
  • rows_and_columns_per_node = 8 rows and 8 columns
    Section 5 default custody assignment; controls per-node storage (about 4.4 MB) and redundancy across the network; chosen by design, not derived.
  • redundancy_factor_k = 8
    Section 6.1 redundant seeding policy; builder sends k copies per cell; affects bandwidth (1,120 MB) and success; selected by hand.
  • adaptive_fetch_timeouts = t1=400ms, t2=200ms, tj=100ms
    Section 7 default parameters; chosen based on estimated builder seeding and inter-node latencies.
  • adaptive_fetch_redundancy_schedule = k1=1, k2=2, k3=4, kj>=6=10
    Section 7 default parameters; escalation schedule tuned to meet the 4-second deadline in the evaluated network model.
  • consolidation_timer = 400ms
    Section 6.2 default; if no seed cells are received within this delay, consolidation starts without seed data.
  • cb_boost = 10000
    Section 7 default; weight given to consolidation boost map entries; chosen to strongly prioritize seeded peers.
assumptions (8)
  • domain assumption Ethereum nodes can be reached directly via ENR IP/port information over UDP.
    Section 4.1: nodes are identified by ID and contact info in ENRs; PANDAS uses one-way UDP with no connection setup.
  • domain assumption The IPFS all-pair latency trace from Probe Lab is representative of Ethereum node-to-node latencies.
    Section 8.1: the paper states there is no publicly available Ethereum latency data and uses the IPFS trace for emulation.
  • domain assumption All correct nodes perform DAS and custody data to hide the association between validators and nodes.
    Section 4.3: PANDAS assumes all correct nodes are expected to custody data and sample, avoiding deanonymization.
  • domain assumption The builder is rational and will not send incorrect data, though it may withhold data.
    Section 4.1: incorrect data would be detected via KZG proofs and would cost the builder rewards.
  • standard math Reed-Solomon erasure coding permits reconstruction from any 50% of cells in a row or column.
    Section 3: the blob is extended with a two-dimensional Reed-Solomon code; reconstruction from half of a row or column is a standard property.
  • domain assumption RANDAO epoch seeds are unpredictable and known one epoch in advance.
    Section 5: PANDAS uses the existing Ethereum RANDAO mechanism to seed the deterministic cell assignment.
  • ad hoc to paper Nodes can accept seed cells signed by the proposer before receiving the block header.
    Section 6.1: the proposer signs a binding of the builder identity; nodes start receiving blob data before the block arrives. This is required for the concurrent timeline.
  • domain assumption A fixed 3% UDP packet loss rate is representative of WAN conditions.
    Section 8.1: the evaluation applies a 3% loss rate to UDP communication in the cluster.

how reviews work

0 comments
Cite this review

Pith. "Pith review of PANDAS: Peer-to-peer, Adaptive Networking for Data Availability Sampling within Ethereum Consensus Timebounds." pith.science (2026). https://pith.science/paper/BOSNWFGX

@misc{pith2026250700824,
  author       = {Pith},
  title        = {Pith review of: PANDAS: Peer-to-peer, Adaptive Networking for Data Availability Sampling within Ethereum Consensus Timebounds},
  year         = {2026},
  howpublished = {\url{https://pith.science/paper/BOSNWFGX}},
  note         = {Machine review of arXiv:2507.00824}
}
read the original abstract

Layer-2 protocols can assist Ethereum's limited throughput, but globally broadcasting layer-2 data limits their scalability. The Danksharding evolution of Ethereum aims to support the selective distribution of layer-2 data, whose availability in the network is verified using randomized data availability sampling (DAS). Integrating DAS into Ethereum's consensus process is challenging, as pieces of layer-2 data must be disseminated and sampled within four seconds of the beginning of each consensus slot. No existing solution can support dissemination and sampling under such strict time bounds. We propose PANDAS, a practical approach to integrate DAS with Ethereum under Danksharding's requirements without modifying its protocols for consensus and node discovery. PANDAS disseminates layer-2 data and samples its availability using lightweight, direct exchanges. Its design accounts for message loss, node failures, and unresponsive participants while anticipating the need to scale out the Ethereum network. Our evaluation of PANDAS's prototype in a 1,000-node cluster and simulations for up to 20,000 peers shows that it allows layer-2 data dissemination and sampling under planetary-scale latencies within the 4-second deadline.

Figures

Figures reproduced from arXiv: 2507.00824 by the authors.

Figure 1
Figure 1. Proposer-Builder Separation (PBS). The proposer, [PITH_FULL_IMAGE:figures/full_fig_p003_1.png] view at source ↗
Figure 3
Figure 3. Each node samples 73 randomly chosen cells. [PITH_FULL_IMAGE:figures/full_fig_p003_3.png] view at source ↗
Figure 4
Figure 4. The minimal data enabling reconstruction (left), and [PITH_FULL_IMAGE:figures/full_fig_p004_4.png] view at source ↗
Figures from the paper (10 more)
Figure 7
Figure 7. Figure 7: Assignment 𝜎 of cells to nodes. Node 𝑛1 is assigned columns 𝑐𝑎 and 𝑐𝑏 and rows 𝑟𝑐 and 𝑟𝑑 in epoch 𝑒. Any node 𝑛2 that knows 𝑛1 deterministically determines its assigned cells, regardless of the rest of its view 𝑉𝑛2 \ 𝑛1. establishment of connections or keep-alive messa…
Figure 6
Figure 6. Figure 6: Timeline of events within a slot. Starting from the [PITH_FULL_IMAGE:figures/full_fig_p005_6.png]
Figure 8
Figure 8. Figure 8: Three seeding policies. The “minimal” policy splits the first half of each row or column amongst known peers having it in their assignment. The “single” policy splits the entire row or column. The “redundant” policy shares each split to 𝑘 nodes. A better approach is to…
Figure 10
Figure 10. Figure 10: Node 𝑛 determines a set of nodes to query at each round. The adaptive strategy adjusts the redundancy of queries (i.e., the number of nodes queried for each missing cell) and the timeout before the next round. and scheduling of requests are delegated to PANDAS’s fetch…
Figure 11
Figure 11. Figure 11: Distribution of times for the three phases of PANDAS across all nodes, for the three seeding strategies. All times are from [PITH_FULL_IMAGE:figures/full_fig_p009_11.png]
Figure 12
Figure 12. Figure 12: Distribution of messages and traffic volume for fetch [PITH_FULL_IMAGE:figures/full_fig_p009_12.png]
Figure 14
Figure 14. Figure 14: Distribution of time to sampling and messages com [PITH_FULL_IMAGE:figures/full_fig_p010_14.png]
Figure 13
Figure 13. Figure 13: Comparison of the performance of adaptive fetching, [PITH_FULL_IMAGE:figures/full_fig_p010_13.png]
Figure 15
Figure 15. Figure 15: Simulation of seeding, consolidation, and sampling [PITH_FULL_IMAGE:figures/full_fig_p011_15.png]
Figure 17
Figure 17. Figure 17: Simulation of time to consolidation and time to sam [PITH_FULL_IMAGE:figures/full_fig_p011_17.png]

Discussion (0). Continue with ORCID to comment.

Reference graph

Works this paper leans on

68 extracted references · 65 canonical work pages

  1. [45]

    Final report: NAT hole punching measurement cam- paign

    Probe Lab. Final report: NAT hole punching measurement cam- paign. https://github.com/plprobelab/network-measurements/blob/master/results/ rfm15-nat-hole-punching.md, 2023

    work page 2023

  2. [1]

    archive node

    Ethereum full node vs. archive node. https://www.quicknode.com/guides/ infrastructure/node-setup/ethereum-full-node-vs-archive-node

    work page

  3. [2]

    https://etherscan.io/nodetracker

    Ethereum node tracker. https://etherscan.io/nodetracker

    work page

  4. [3]

    official go implementation of the ethereum protocol

    Go ethereum. official go implementation of the ethereum protocol. https://geth. ethereum.org/

    work page

  5. [4]

    https://libp2p.io

    libp2p: A modular network stack. https://libp2p.io

    work page

  6. [5]

    https://github.com/ethereum/consensus-specs/tree/dev/specs/ _features/eip7594, May 2024

    EIP-7594: PeerDAS. https://github.com/ethereum/consensus-specs/tree/dev/specs/ _features/eip7594, May 2024

    work page 2024

  7. [6]

    Lazyledger: A distributed data availability ledger with client- side smart contracts

    Mustafa Al-Bassam. Lazyledger: A distributed data availability ledger with client- side smart contracts. arXiv preprint arXiv:1905.09274, 2019

    arXiv 1905

  8. [7]

    Fraud and data availability proofs: Detecting invalid blocks in light clients

    Mustafa Al-Bassam, Alberto Sonnino, Vitalik Buterin, and Ismail Khoffi. Fraud and data availability proofs: Detecting invalid blocks in light clients. In Interna- tional Conference on Financial Cryptography and Data Security , FC. Springer, 2021

    work page 2021

Show all 68 references
  1. [8]

    IPFS: content addressed, versioned, P2P file system

    Juan Benet. IPFS: content addressed, versioned, P2P file system. arXiv preprint arXiv:1407.3561, 2014

    2014 arXiv

  2. [9]

    Fair and efficient gossip in hyperledger fabric

    Nicolae Berendea, Hugues Mercier, Emanuel Onica, and Etienne Riviere. Fair and efficient gossip in hyperledger fabric. In 40th International Conference on Distributed Computing Systems, ICDCS, pages 190–200. IEEE, 2020

    2020

  3. [10]

    Eip-4844: Shard blob transactions

    Vitalik Buterin, Dankrad Feist, Diederik Loerakker, George Kadianakis, Matt Garnett, Mofi Taiwo, and Ansgar Dietrichs. Eip-4844: Shard blob transactions. https://eips.ethereum.org/EIPS/eip-4844, 2024

    2024

  4. [11]

    On the design of ethereum’s data availability sampling: A comprehensive simulation study

    Arunima Chaudhuri, Sudipta Basak, Csaba Kiraly, Dmitriy Ryajov, and Leonardo Bautista-Gomez. On the design of ethereum’s data availability sampling: A comprehensive simulation study. In 2024 6th Conference on Blockchain Research & Applications for Innovative Networks and Servi...

    2024

  5. [12]

    Discovering the Ethereum2 P2P network

    Mikel Cortes-Goicoechea and Leonardo Bautista-Gomez. Discovering the Ethereum2 P2P network. In 2021 Third International Conference on Blockchain Computing and Applications, BCCA. IEEE, 2021

    2021

  6. [13]

    Scalability limitations of Kademlia DHTs when enabling Data Availability Sampling in Ethereum, 2024

    Mikel Cortes-Goicoechea, Csaba Kiraly, Dmitriy Ryajov, Jose Luis Muñoz-Tapia, and Leonardo Bautista-Gomez. Scalability limitations of Kademlia DHTs when enabling Data Availability Sampling in Ethereum, 2024

    2024

  7. [14]

    SubnetDAS - an intermediate DAS approach

    Francesco D’Amato and Ansgar Dietrichs. SubnetDAS - an intermediate DAS approach. https://ethresear.ch/t/subnetdas-an-intermediate-das-approach/17169, 2023

    2023

  8. [15]

    Recent latest message driven ghost: Balancing dynamic availability with asynchrony resilience

    Francesco D’Amato and Luca Zanolini. Recent latest message driven ghost: Balancing dynamic availability with asynchrony resilience. In 2024 IEEE 37th Computer Security F oundations Symposium (CSF), pages 127–142. IEEE, 2024

    2024

  9. [16]

    Das fork-choice

    Francesco D’Amato, Luca Zanolini, and Roberto Saltini. Das fork-choice. https: //ethresear.ch/t/das-fork-choice/19578, May 2024

    2024

  10. [17]

    Accelerating content routing with bitswap: A multi-path file transfer protocol in IPFS and Filecoin

    Alfonso De la Rocha, David Dias, and Yiannis Psaras. Accelerating content routing with bitswap: A multi-path file transfer protocol in IPFS and Filecoin. Technical report, Protocol Labs, 2021

    2021

  11. [18]

    Randao: Ethereum random number generator

    Ethereum. Randao: Ethereum random number generator. https://github.com/ randao/randao, 2022

    2022

  12. [19]

    Zero-knowledge rollups

    Ethereum. Zero-knowledge rollups. https://ethereum.org/en/developers/docs/ scaling/zk-rollups/, 2024

    2024

  13. [20]

    Discv4 ENR periodic crawls

    Ethereum. Discv4 ENR periodic crawls. https://github.com/ethereum/discv4-dns- lists, 2025

    2025

  14. [21]

    DAS query analysis notebook

    Ethereum community. DAS query analysis notebook. https://colab.research. google.com/drive/1Di1-hBae8tZr1tZqcu1JqYycOFy8FdAy, 2024

    2024

  15. [22]

    The merge: Ethereum switch to proof-of-stake

    Ethereum foundation. The merge: Ethereum switch to proof-of-stake. https: //ethereum.org/en/upgrades/merge/, 2023

    2023

  16. [23]

    Ethereum roadmap

    Ethereum foundation. Ethereum roadmap. https://ethereum.org/en/roadmap/, 2024

    2024

  17. [24]

    Ethereum roadmap: Danksharding

    Ethereum foundation. Ethereum roadmap: Danksharding. https://ethereum.org/ en/roadmap/danksharding/, 2024

    2024

  18. [25]

    Ethereum roadmap: Proposer-builder separation

    Ethereum foundation. Ethereum roadmap: Proposer-builder separation. https: //ethereum.org/en/roadmap/pbs/, 2024

    2024

  19. [26]

    Optimistic rollups

    Ethereum foundation. Optimistic rollups. https://ethereum.org/en/developers/ docs/scaling/optimistic-rollups/, 2024

    2024

  20. [27]

    Proofs of custody

    Dankrad Feist. Proofs of custody. https://dankradfeist.de/ethereum/2021/09/30/ proofs-of-custody.html, 2021

    2021

  21. [28]

    MEV-Boost in a Nutshell

    Flashbots. MEV-Boost in a Nutshell. https://boost.flashbots.net, 2024

    2024

  22. [29]

    Node discovery protocol v5 - wire proto- col

    Ethereum Foundation. Node discovery protocol v5 - wire proto- col. https://github.com/ethereum/devp2p/blob/master/discv5/discv5-wire.md# udp-communication

  23. [30]

    A survey of Layer-two blockchain protocols

    Ankit Gangwal, Haripriya Ravali Gangavalli, and Apoorva Thirupathi. A survey of Layer-two blockchain protocols. Journal of Network and Computer Applications , 209, 2023

    2023

  24. [31]

    Maximal extractable value: Current understanding, categorization, and open research questions

    Vincent Gramlich, Dennis Jelito, and Johannes Sedlmeir. Maximal extractable value: Current understanding, categorization, and open research questions. Elec- tronic Markets, 34(1):49, 2024

    2024

  25. [32]

    One-hop lookups for peer-to-peer overlays

    Anjali Gupta and Barbara Liskov. One-hop lookups for peer-to-peer overlays. In 9th Workshop on Hot Topics in Operating Systems , HotOS, 2003

    2003

  26. [33]

    Scaling blockchains: A comprehensive survey

    Abdelatif Hafid, Abdelhakim Senhaji Hafid, and Mustapha Samih. Scaling blockchains: A comprehensive survey. IEEE access, 8:125244–125262, 2020

    2020

  27. [34]

    Ethereum’s proposer-builder separation: Promises and realities

    Lioba Heimbach, Lucianna Kiffer, Christof Ferreira Torres, and Roger Watten- hofer. Ethereum’s proposer-builder separation: Promises and realities. In Internet Measurement Conference, IMC, pages 406–420. ACM

  28. [35]

    Deanonymizing Ethereum validators: The P2P network has a privacy issue

    Lioba Heimbach, Yann V onlanthen, Juan Villacis, Lucianna Kiffer, and Roger Wattenhofer. Deanonymizing Ethereum validators: The P2P network has a privacy issue. In USENIX Security Symposium, 2025

    2025

  29. [36]

    Eclipsing Ethereum peers with false friends

    Sebastian Henningsen, Daniel Teunis, Martin Florian, and Björn Scheuermann. Eclipsing Ethereum peers with false friends. In 2019 IEEE European Symposium on Security and Privacy Workshops (EuroS&PW), pages 300–309. IEEE, 2019

    2019

  30. [37]

    Incentive mechanisms in peer-to-peer networks—a systematic literature review

    Cornelius Ihle, Dennis Trautwein, Moritz Schubotz, Norman Meuschke, and Bela Gipp. Incentive mechanisms in peer-to-peer networks—a systematic literature review. ACM Computing Surveys, 55(14s):1–69, 2023

    2023

  31. [38]

    SoK: A taxonomy for Layer-2 scalability related protocols for cryptocurrencies

    Maxim Jourenko, Kanta Kurazumi, Mario Larangeira, and Keisuke Tanaka. SoK: A taxonomy for Layer-2 scalability related protocols for cryptocurrencies. Cryp- tology ePrint Archive, Paper 2019/352, 2019

    2019

  32. [39]

    Proof of validator: A simple anonymous credential scheme for ethereum’s dht

    George Kadianakis, Mary Maller, Andrija Novakovic, and Suphanat Chun- hapanya. Proof of validator: A simple anonymous credential scheme for ethereum’s dht. https://ethresear.ch/t/proof-of-validator-a-simple-anonymous- credential-scheme-for-ethereums-dht/16454, August 2023

    2023

  33. [40]

    Arbitrum: Scalable, private smart contracts

    Harry Kalodner, Steven Goldfeder, Xiaoqi Chen, S Matthew Weinberg, and Ed- ward W Felten. Arbitrum: Scalable, private smart contracts. In 27th USENIX Security Symposium, 2018

    2018

  34. [41]

    Constant-size commit- ments to polynomials and their applications

    Aniket Kate, Gregory M Zaverucha, and Ian Goldberg. Constant-size commit- ments to polynomials and their applications. In Intl. conf. on the theory and app. of cryptology and info. sec. , ASIACRYPT, 2010

    2010

  35. [42]

    FullDAS - towards massive scalability with 32mb blocks and beyond https://ethresear.ch/t/fulldas- towards-massive-scalability-with-32mb-blocks-and-beyond/19529/1, May 2024

    Csaba Kiraly, Leonardo Bautista-Gomez, and Dmitriy Ryajov. FullDAS - towards massive scalability with 32mb blocks and beyond https://ethresear.ch/t/fulldas- towards-massive-scalability-with-32mb-blocks-and-beyond/19529/1, May 2024

    2024

  36. [43]

    Disc-NG: Robust service discov- ery in the Ethereum Global Network

    Michał Król, Onur Ascigil, Sergi Rene, Alberto Sonnino, Matthieu Pigaglio, Ramin Sadre, Felix Lange, and Etienne Riviere. Disc-NG: Robust service discov- ery in the Ethereum Global Network. In 9th European Symposium on Security and Privacy, EuroS&P, pages 193–215. IEEE, 2024

    2024

  37. [44]

    Formal model-driven analysis of resilience of gossipsub to attacks from misbe- having peers

    Ankit Kumar, Max von Hippel, Panagiotis Manolios, and Cristina Nita-Rotaru. Formal model-driven analysis of resilience of gossipsub to attacks from misbe- having peers. In 2024 IEEE Symposium on Security and Privacy (SP) , pages 2142–2160. IEEE, 2024

    2024

  38. [46]

    MEV Watch

    Labrys.io. MEV Watch. https://www.mevwatch.info, 2024

    2024

  39. [47]

    Perigee: Efficient peer-to-peer network design for blockchains

    Yifan Mao, Soubhik Deb, Shaileshh Bojja Venkatakrishnan, Sreeram Kannan, and Kannan Srinivasan. Perigee: Efficient peer-to-peer network design for blockchains. In Proceedings of the 39th Symposium on Principles of Distributed Computing , pages 428–437, 2020

    2020

  40. [48]

    Low-resource eclipse attacks on Ethereum’s peer-to-peer network

    Yuval Marcus, Ethan Heilman, and Sharon Goldberg. Low-resource eclipse attacks on Ethereum’s peer-to-peer network. IACR Cryptology ePrint Archive, 2018(236), 2018

    2018

  41. [49]

    Matter Labs. zkSync. https://zksync.io, 2024

    2024

  42. [50]

    Kademlia: A peer-to-peer information system based on the XOR metric

    Petar Maymounkov and David Mazieres. Kademlia: A peer-to-peer information system based on the XOR metric. In International Workshop on Peer-to-Peer Systems, IPTPS. Springer, 2002

    2002

  43. [51]

    PeerSim: A scalable P2P simulator

    Alberto Montresor and Márk Jelasity. PeerSim: A scalable P2P simulator. In Proc. of the 9th Int. Conference on Peer-to-Peer, P2P, 2009

    2009

  44. [52]

    Information dispersal with provable retrievability for rollups

    Kamilla Nazirkhanova, Joachim Neu, and David Tse. Information dispersal with provable retrievability for rollups. In Proceedings of the 4th ACM Conference on Advances in Financial Technologies, pages 180–197, 2022

    2022

  45. [53]

    https://www.optimism.io, 2024

    Optimism. https://www.optimism.io, 2024

    2024

  46. [54]

    Byzantine attacks exploiting penalties in ethereum pos

    Ulysse Pavloff, Yackolley Amoussou-Guenou, and Sara Tucci-Piergiovanni. Byzantine attacks exploiting penalties in ethereum pos. In 2024 54th Annual IEEE/IFIP International Conference on Dependable Systems and Networks (DSN), pages 53–65. IEEE, 2024

    2024

  47. [55]

    https://polygon.technology, 2024

    Polygon. https://polygon.technology, 2024

    2024

  48. [56]

    Failure mode assumptions and assumption coverage

    David Powell. Failure mode assumptions and assumption coverage. InPredictably dependable computing systems, pages 123–140. Springer, 1995

    1995

  49. [57]

    A survey on blockchain scalability: From hardware to layer-two protocols

    Gabriel Antonio F Rebello, Gustavo F Camilo, Lucas Airam C de Souza, Maria Potop-Butucaru, Marcelo Dias de Amorim, Miguel Elias M Campista, and Luís Henrique MK Costa. A survey on blockchain scalability: From hardware to layer-two protocols. IEEE Communications Surveys & Tutor...

    2024

  50. [58]

    Crawling the ethereum discv5 network, fast

    Codex.storage Research. Crawling the ethereum discv5 network, fast. https: //ethresear.ch/t/crawling-the-ethereum-discv5-network-fast/20962, 2024

    2024

  51. [59]

    PeerDAS – a simpler DAS approach using battle-tested P2P compo- nents

    Danny Ryan. PeerDAS – a simpler DAS approach using battle-tested P2P compo- nents. https://ethresear.ch/t/peerdas-a-simpler-das-approach-using-battle-tested- p2p-components/16541, 2023

    2023

  52. [60]

    ACeD: Scalable data availability oracle

    Peiyao Sheng, Bowen Xue, Sreeram Kannan, and Pramod Viswanath. ACeD: Scalable data availability oracle. In Financial Cryptography and Data Security, FC. Springer, 2021

    2021

  53. [61]

    Content censorship in the interplanetary file system

    Srivatsan Sridhar, Onur Ascigil, Navin Keizer, François Genon, Sébastien Pierre, Yiannis Psaras, Etienne Rivière, and Michał Król. Content censorship in the interplanetary file system. In Network and Distributed System Security Symposium, NDSS, 2024

    2024

  54. [62]

    gossipsub v1.0: An extensible baseline pubsub protocol

    LibP2P Team. gossipsub v1.0: An extensible baseline pubsub protocol. https: //github.com/libp2p/specs/blob/master/pubsub/gossipsub/gossipsub-v1.0.md

  55. [63]

    Nebula: A network agnostic dht crawler and monitor

    Dennis Trautwein. Nebula: A network agnostic dht crawler and monitor. https: //github.com/dennis-tra/nebula, 2025

    2025

  56. [64]

    Gossipsub: Attack-resilient message propagation in the Filecoin and ETH2.0 networks

    Dimitris Vyzovitis, Yusef Napora, Dirk McCormick, David Dias, and Yiannis Psaras. Gossipsub: Attack-resilient message propagation in the Filecoin and ETH2.0 networks. arXiv preprint arXiv:2007.02754, 2020

    2007 arXiv

  57. [65]

    Reed-Solomon codes and their applica- tions

    Stephen B Wicker and Vijay K Bhargava. Reed-Solomon codes and their applica- tions. John Wiley & Sons, 1999

    1999

  58. [66]

    Ethereum eclipse attacks

    Karl Wüst and Arthur Gervais. Ethereum eclipse attacks. Technical report, ETH Zurich, 2016

    2016

  59. [67]

    Honeybee: Decentralized peer sampling with verifiable random walks for blockchain data sharding

    Yunqi Zhang and Shaileshh Bojja Venkatakrishnan. Honeybee: Decentralized peer sampling with verifiable random walks for blockchain data sharding. arXiv e-prints, pages arXiv–2402, 2024

    2024

  60. [68]

    Mercury: Fast transaction broadcast in high perfor- mance blockchain systems

    Mingxun Zhou, Liyi Zeng, Yilin Han, Peilun Li, Fan Long, Dong Zhou, Ivan Beschastnikh, and Ming Wu. Mercury: Fast transaction broadcast in high perfor- mance blockchain systems. In IEEE Conference on Computer Communications , INFOCOM, 2023. 14

    2023

Pith tools

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