{"id":"cb417fdc-922c-407a-9898-4890553dc85f","arxiv_id":"2507.00824","paper_version":1,"verdict":"CONDITIONAL","confidence":"MODERATE","novelty_score":7.0,"correctness_risk":"medium","formal_verification":"none","parameter_count":6,"one_line_summary":"PANDAS is a peer-to-peer protocol that claims to complete Ethereum data-availability sampling within the consensus 4-second window using direct UDP exchanges, builder-led seeding, and adaptive fetching.","lead":"Ethereum plans to let layer-2 networks publish large data blobs, but checking that this data is available must fit into the 4 seconds a validator has to approve each block. This paper introduces PANDAS, a peer-to-peer protocol that spreads and samples blob data via direct one-hop messages, claiming it can finish within the deadline for networks up to about 20,000 nodes.","discovery_kind":"new_method","skeptic_critique":{"model":"deepseek-v4-flash","headline":"The 4-second guarantee is measured on cell reception, not on KZG-verified sampling after the block header arrives; §8.1's own admission puts the tight-fork-choice claim at risk.","rationale":"The reader's weakest assumption identifies the same load-bearing gap: the evaluation starts DAS at slot time zero and completes sampling without requiring the block header or KZG commitments. My stress-test sharpens this in two ways. First, because block dissemination and DAS are genuinely concurrent, the correct test is not to add the block latency to the sampling time, but to measure the joint completion distribution for the two paths together; the paper does not report this. Second, even on the DAS path alone, the reported completion time counts unverified cell arrival, while the protocol itself defers KZG verification until the block header is available. Since an attestation under the tight fork-choice rule requires verified availability, the reported 100% success at 1,000 nodes is not yet evidence that all committee members can complete their full verification step within 4 seconds. This does not invalidate the protocol idea, but it means the abstract's unconditional 4-second claim is stronger than the evaluation supports. The proposed test would settle the concern directly by measuring the end-to-end verified-sampling CDF. The conditional verdict remains appropriate: the system is credible and likely publishable, but the headline timing guarantee needs either an end-to-end measurement or an explicitly scoped claim that KZG verification and header reception are assumed to fit in the remaining margin.","tokens_in":39160,"tokens_out":10074,"duration_ms":139249,"concrete_test":"Re-run the 1,000-node prototype with the redundant (k=8) seeding strategy and the real GossipSub block-dissemination path active. Redefine each node's sample-completion time as the time at which the node (i) has received its 73 sampled cells, (ii) has received the block header containing the blob commitments, and (iii) has successfully KZG-verified those cells; report the joint CDF and P99 against the 4,000 ms deadline. Run the same experiment with verification disabled to isolate cryptographic cost. If the P99 exceeds 4,000 ms, or any node misses the deadline at 1,000 nodes, the central guarantee as stated in the abstract is not established.","verdict_should_be":"UNCHANGED","load_bearing_attack":"PANDAS's central timing claim rests on a metric that stops when cells are received, not when they are usable for an attestation. Section 8.1 defines \"time to sampling\" as the moment a node has received (or can reconstruct) its 73 random cells; KZG verification is explicitly deferred in Section 7, where Algorithm 1 omits the checks \"performed when receiving C (e.g., verifying the cells KZGPs if/when the block header is available).\" Under the tight fork-choice rule, a committee member must have both the block header containing blob commitments and verified samples before attesting. The relevant completion time is therefore approximately max(cell-reception, header-arrival) + KZG verification, but the paper reports only the first term. The paper's own Section 8.1 states that if block dissemination latency were added to the reported sampling times, meeting the 4 s deadline \"would be at risk for many nodes, even with the redundant strategy.\" Because the two paths are concurrent, the issue is not simply additive; the missing quantity is the joint deadline CDF including the header path and verification. The reported redundant-strategy maximum of 3,009 ms leaves under one second of margin for any header/verification overhead, and the 20,000-node results already show 10% of nodes missing the deadline. Without an end-to-end measured completion time, the claim that PANDAS enables the tight fork-choice rule overreaches the evidence.","agreement_with_reader":"agree"},"referee_report":{"model":"deepseek-v4-flash","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.","tokens_in":39473,"tokens_out":5764,"duration_ms":68525,"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":[{"comment":"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.","section":"Section 8.1, Figure 11d, Algorithm 1"},{"comment":"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.","section":"Abstract, Section 8.2, Figure 15"},{"comment":"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.","section":"Section 8.1, network emulation"},{"comment":"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.","section":"Section 7, default parameters"}],"minor_comments":[{"comment":"The footnote refers to \"KZMPs\" but the paper uses the abbreviation KZGP elsewhere; this appears to be a typo and should be corrected.","section":"Section 7, Algorithm 1 footnote"},{"comment":"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.","section":"Section 8.1, consolidation timing"},{"comment":"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.","section":"Section 8.2, simulation methodology"},{"comment":"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.","section":"Section 8.1, Figure 11a"},{"comment":"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.","section":"References"}],"recommendation":"major_revision","confidential_remarks":null},"author_rebuttal":null,"desk_editor":{"model":"deepseek-v4-flash","letter":"PANDAS is one of the more serious DAS designs I've seen. The combination of RANDAO-seeded deterministic cell assignment, builder-led one-hop UDP seeding, consolidation boost maps, and adaptive redundancy is genuinely new, and the evaluation is substantial: a 1,000-node libp2p prototype on emulated WAN links, a simulator cross-validated against it up to 20k nodes, and fair baselines (GossipSub, Kademlia). The paper also earns credit for stating its weaknesses openly.\n\nThe soft spot is the one the authors themselves flag in Section 8.1: the 4-second deadline is measured on when a node has received or reconstructed its 73 random cells, not on when it can actually attest under the tight fork-choice rule. That requires the block header (with blob commitments) to have arrived via GossipSub and the KZG proofs to be checked. Algorithm 1 explicitly omits these checks, deferring them until the header is available. The paper says adding block dissemination latency to the reported sampling times \"would be at risk for many nodes, even with the redundant strategy.\" That is not a minor caveat; it is the difference between sampling completing and attestation being possible. The reported redundant-strategy maximum of about 3.0s leaves under a second of margin, and the 20k-node results already show 10% missing even the sampling-only deadline. Without an end-to-end measurement of the joint block-plus-sampling-plus-verification path, the claim that PANDAS enables the tight fork-choice rule overreaches the data.\n\nTwo smaller issues: the latency model uses an IPFS all-pair trace as a proxy for Ethereum, which is reasonable but not validated against Ethereum-specific measurements; and the adaptive fetching parameters are hand-tuned on the same emulated network used for evaluation, so the margin numbers are best-case.\n\nNone of this kills the core idea. The protocol is well constructed, the paper is honest, and the baseline comparison is useful. But the central guarantee needs to be either re-measured end-to-end or restated as a sampling-only result. As it stands, this is a conditional accept, not a clean one.","headline":"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.","tokens_in":40045,"tokens_out":2819,"would_cite":true,"duration_ms":31130,"reading_group":"yes","serious_thinker":"yes","would_accept_peer_review":true},"rs_alignment":null,"lean_confirmation":null,"pith_extraction":{"msc":[],"pacs":[],"model":"deepseek-v4-flash","headline":"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.","keywords":["data availability sampling","Ethereum Danksharding","peer-to-peer networking","adaptive fetching","erasure coding","consensus timebounds","layer-2 scaling"],"falsifier":"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.","tokens_in":38964,"feed_emoji":"⛓️","tokens_out":8543,"duration_ms":90065,"temperature":0.7,"pith_summary":"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.","feed_headline":"PANDAS completes blob sampling within Ethereum's 4-second window","feed_subtitle":"Direct one-hop fetching gets all 1,000 testbed nodes sampled before the attestation deadline.","key_machinery":"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.","core_discovery":"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.","pith_inferences":["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."],"forward_implications":["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."],"supporting_citations":[{"why":"Supplies the all-pair latency trace used for network emulation and simulations.","marker":"[45]"},{"why":"GossipSub is the multi-hop overlay used both for block dissemination and as the baseline for blob dissemination via channels.","marker":"[64]"},{"why":"Kademlia is the DHT baseline whose multi-hop storage and retrieval fails the deadline in the comparison.","marker":"[50]"},{"why":"Defines the tight fork-choice rule that requires availability sampling before attestation.","marker":"[16]"},{"why":"PeerDAS, the leading alternative DAS proposal, whose postponed sampling PANDAS contrasts with the tight fork-choice rule.","marker":"[5]"},{"why":"KZG commitments and proofs authenticate individual blob cells before the block header is verified.","marker":"[41]"},{"why":"Reed-Solomon erasure coding lets nodes reconstruct assigned rows and columns from half their cells.","marker":"[65]"},{"why":"Sets the Danksharding blob size and sampling parameters that PANDAS targets.","marker":"[24]"},{"why":"Defines the 25 Mbps home-server bandwidth target used to judge node load.","marker":"[1]"}],"fun_headline_variants":["PANDAS hits 4-second DAS deadline at 20,000 peers","Direct peer exchanges beat gossip for Ethereum DAS","PANDAS scales blob sampling to 20,000 nodes","Ethereum DAS in under 4 seconds: PANDAS proves it","One-hop fetching meets Danksharding time bounds"],"cache_read_input_tokens":3200,"weakest_assumption_plain":"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.","fun_headline_variants_meta":{"raw":{"variants":["PANDAS hits 4-second DAS deadline at 20,000 peers","Direct peer exchanges beat gossip for Ethereum DAS","PANDAS scales blob sampling to 20,000 nodes","Ethereum DAS in under 4 seconds: PANDAS proves it","One-hop fetching meets Danksharding time bounds"]},"model":"deepseek-v4-flash","effort":"low","cost_usd":0.000294,"raw_usage":{"total_tokens":1700,"prompt_tokens":922,"completion_tokens":778,"prompt_tokens_details":{"cached_tokens":384},"prompt_cache_hit_tokens":384,"prompt_cache_miss_tokens":538,"completion_tokens_details":{"reasoning_tokens":689}},"tokens_in":538,"tokens_out":778,"duration_ms":7858,"temperature":1.0,"reasoning_tokens":689,"cache_read_input_tokens":384,"cache_creation_input_tokens":0},"cache_creation_input_tokens":0},"created_at":"2026-08-06T21:06:42.518596+00:00","model_set":{"reader":"deepseek-v4-flash"},"falsifier":"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.","supporting_citations":[{"cited_title":"Final report: NAT hole punching measurement cam- paign","cited_arxiv_id":null,"evidence_quote":"Supplies the all-pair latency trace used for network emulation and simulations."},{"cited_title":"Kademlia: A peer-to-peer information system based on the XOR metric","cited_arxiv_id":null,"evidence_quote":"Kademlia is the DHT baseline whose multi-hop storage and retrieval fails the deadline in the comparison."},{"cited_title":"Das fork-choice","cited_arxiv_id":null,"evidence_quote":"Defines the tight fork-choice rule that requires availability sampling before attestation."},{"cited_title":"https://github.com/ethereum/consensus-specs/tree/dev/specs/ _features/eip7594, May 2024","cited_arxiv_id":null,"evidence_quote":"PeerDAS, the leading alternative DAS proposal, whose postponed sampling PANDAS contrasts with the tight fork-choice rule."},{"cited_title":"Constant-size commit- ments to polynomials and their applications","cited_arxiv_id":null,"evidence_quote":"KZG commitments and proofs authenticate individual blob cells before the block header is verified."},{"cited_title":"Reed-Solomon codes and their applica- tions","cited_arxiv_id":null,"evidence_quote":"Reed-Solomon erasure coding lets nodes reconstruct assigned rows and columns from half their cells."},{"cited_title":"Ethereum roadmap: Danksharding","cited_arxiv_id":null,"evidence_quote":"Sets the Danksharding blob size and sampling parameters that PANDAS targets."},{"cited_title":"archive node","cited_arxiv_id":null,"evidence_quote":"Defines the 25 Mbps home-server bandwidth target used to judge node load."}],"review_version":1}