{"id":"5cedbbcf-4879-4860-a598-eac59bf79bad","arxiv_id":"2411.10026","paper_version":2,"verdict":"CONDITIONAL","confidence":"MODERATE","novelty_score":5.0,"correctness_risk":"medium","formal_verification":"none","parameter_count":0,"one_line_summary":"A new taxonomy divides DAG-based consensus protocols into availability-focused and consistency-focused families, with subcategories for structured versus unstructured and optimistic versus certified DAGs.","lead":"This paper is a survey of DAG-based blockchain consensus protocols, grouping them by whether they prioritize availability or consistency. It maps their design choices, attack vectors, and open research problems, aiming to give researchers a structured overview of the field.","discovery_kind":"review","skeptic_critique":{"model":"deepseek-v4-flash","headline":"The binary availability/consistency taxonomy is internally falsified by its own hybrid entry: Slipstream appears in both Table II categories, so the central classification is not a partition unless a hybrid or non-exclusive category is defined.","rationale":"The reader flagged the informal CAP mapping and the duplicate Slipstream entry. I agree that the CAP mapping is loose, but I do not think that alone is load-bearing: Section III openly says the correlation is informal, and the actual operational criteria used in the table are about lottery/dynamic availability versus BFT/permissioned settings, not CAP's linearizability and total availability. The load-bearing weakness is that those operational criteria are not disjoint, and the paper's own table contains a protocol that meets both. Slipstream is not an edge case; it is an ebb-and-flow protocol explicitly designed to combine an optimistic, dynamically available fast path with a BFT-style deterministic final path. Listing it in both columns is internally consistent with its design, but it is inconsistent with the paper's unqualified claim of two primary classes. A reader cannot tell whether Table II is intended as a partition, a set of design emphases, or a list of properties. That ambiguity affects the central contribution of the SoK, because the classification is the paper's main deliverable. The fix is straightforward: either introduce a third category or a stated hybrid axis, or explicitly define the categories as non-exclusive design dimensions and mark cross-listed protocols. The abstract and contribution section should then be adjusted. This is a correctness issue in the taxonomy, not a disagreement with external consensus, and it is verifiable from the paper's own text. The underlying survey material otherwise appears useful and honestly caveated: the paper disclaims performance evaluation and notes unverified finality claims. I therefore keep the reader's CONDITIONAL verdict rather than moving to REJECT; the concern is substantial but repairable. A machine-checked proof is absent, but this is a SoK, so internal consistency and accuracy of assignment are the relevant standards.","tokens_in":28577,"tokens_out":7282,"duration_ms":78923,"concrete_test":"Apply the definitions in Sec. III to Slipstream using its own abstract and security statements (arXiv:2410.14876): does it claim both (i) liveness in a sleepy/dynamically available model with up to 50% Byzantine nodes and (ii) safety of a final ordering with up to 33% Byzantine nodes? If yes, re-run Table II by checking every entry against the same two criteria and record how many protocols satisfy both. If at least one protocol, here Slipstream, is hybrid by design, the taxonomy needs an explicit hybrid or non-exclusive category, or a precise explanation of why the two categories are not a partition; either change requires revising the abstract's 'two primary classes' claim.","verdict_should_be":"UNCHANGED","load_bearing_attack":"The central claim is a classification of DAG-based consensus protocols into two primary classes, availability-focused and consistency-focused (Abstract and Sec. III). For such a classification to be sound, the defining criteria must be applicable exclusively. Section III defines availability-focused protocols as those maintaining continuous progress via weighted lottery in permissionless/dynamically available settings, and consistency-focused protocols as those built on BFT primitives in permissioned/quasi-permissionless settings. Under these definitions, Slipstream [54] satisfies both criteria simultaneously: the text itself describes it as an ebb-and-flow protocol with an optimistic ordering that is live in a sleepy model under up to 50% Byzantine faults and a final ordering that is safe in an eventual lock-step synchronous model under up to 33% Byzantine faults. Ebb-and-flow protocols (Neu et al. [75]) exist precisely to combine dynamic availability with deterministic finality. Accordingly, Table II lists Slipstream in both the availability-focused Unstructured DAG column and the consistency-focused Optimistic DAG column. The paper nowhere defines a hybrid category, nor does it state that membership in the two categories may overlap; the contribution section says the paper offers 'a structured classification ... into Availability-focused and Consistency-focused categories.' The duplicate is therefore not a cosmetic inconsistency: it demonstrates that the binary framing derived from the CAP-style trade-off cannot accommodate the paper's own example of a protocol that deliberately refuses the trade-off. The classification's central organizing claim is left without a precise statement of which protocols count as availability-focused versus consistency-focused and what it means for a protocol to be both.","agreement_with_reader":"partial"},"referee_report":{"model":"deepseek-v4-flash","summary":"This SoK surveys DAG-based consensus protocols and organizes them around a CAP-inspired availability/consistency dichotomy. After introducing background concepts (ordering, ledger model, participation, network model, dynamic availability, broadcast primitives, adversarial model, finality), the paper categorizes protocols in Table II into availability-focused (structured/unstructured DAG) and consistency-focused (optimistic/certified DAG) families. It then reviews attack vectors, desirable properties such as fairness and MEV protection, recent developments, and future research directions. The paper states in Section I.C that it does not present performance evaluations, and it flags unverified finality claims and uncertain network classifications in footnotes 2 and 3.","tokens_in":28728,"tokens_out":7158,"duration_ms":66363,"significance":"If the classification were made internally consistent, this would be a useful reference for researchers entering DAG-based consensus: the coverage is broad and current (through 2024), the tables (Tables I–III) condense a large literature, and the paper is transparent about its limitations. The explicit disclaimers about unverified finality claims and uncertain network models are commendable for a systematization. The paper does not provide formal proofs, machine-checked artifacts, or reproducible code, but those are not required for a SoK. However, the central contribution is the availability/consistency taxonomy, and that taxonomy currently contains a concrete internal inconsistency that must be fixed before the paper can serve as a reliable reference.","major_comments":[{"comment":"The binary classification is internally falsified by the duplicate listing of Slipstream under both Availability-Focused Unstructured DAG and Consistency-Focused Optimistic DAG. Section III-B describes Slipstream as an ebb-and-flow protocol [54] that offers an optimistic ordering live in a sleepy model under up to 50% Byzantine faults and a final ordering safe in an eventual lock-step synchronous model under up to 33% Byzantine faults; ebb-and-flow protocols [75] exist precisely to combine dynamic availability with deterministic finality. Slipstream therefore satisfies both category criteria from Section III simultaneously. Meshcash, also described as ebb-and-flow in Section III-B, is listed only under availability-focused, which suggests the placement is not being applied by a consistent rule. The paper nowhere defines a hybrid category or states that membership can be non-exclusive, while Section I.C promises 'a structured classification ... into Availability-focused and Consistency-focused categories.' The taxonomy as presented is not a partition. The authors should either introduce a hybrid category (including at least Slipstream and Meshcash) or explicitly state that the two categories are non-exclusive and provide guidance for classifying mixed protocols.","section":"Sec. III, introductory paragraph"},{"comment":"The CAP-based motivation is load-bearing for the classification, but the paper states only an informal correlation of consistency with safety and availability with liveness, while acknowledging these terms are 'traditionally distinct concepts.' Because the subsequent category definitions rely on notions such as dynamic availability, permissionless settings, BFT primitives, and permissioned environments rather than on a formal CAP interpretation, it is unclear whether the availability/consistency labels are derived from the CAP lens or retrofitted onto protocol families. The authors should either make the mapping precise (for example, define availability-focused as satisfying liveness under dynamically available participation and consistency-focused as satisfying deterministic safety under BFT quorum assumptions) or explicitly frame the taxonomy as a pragmatic, non-formal heuristic and engage with known critiques of applying CAP to permissionless/dynamically available systems. As written, the informal mapping contributes to the ambiguous placement of hybrid protocols such as Slipstream.","section":"Sec. III"}],"minor_comments":[{"comment":"The abstract states that the paper analyzes 'performance and trade-offs' of DAG-based protocols, but the note in Section I.C says 'the paper does not discuss or present any performance evaluation of the included protocols.' The abstract should be revised to avoid this overclaim, or the note should be moved to a more prominent position.","section":"Abstract vs. Sec. I.C"},{"comment":"The sentence ending 'Lin et al. developed TangleSim [113] ... Byzantine environments. Bullshark [47].' leaves a dangling citation 'Bullshark [47].' that appears to be a leftover fragment; complete the sentence or remove the dangling reference.","section":"Sec. VI.D"},{"comment":"In 'The Slipstream protocol, [54], is also ebb-and-flow style consensus protocol [75]', the indefinite article 'a' is missing before 'ebb-and-flow'.","section":"Sec. III.B"},{"comment":"The author name 'E. G /dieresis.ts1un Sirer' appears corrupted; it should read 'E. Gün Sirer'.","section":"Reference [66]"},{"comment":"The 'Reachability challenge' bullet is vague; it would benefit from a concrete example, such as how pruning or light-client operation depends on reachability information in the DAG.","section":"Sec. I.B.4"}],"recommendation":"major_revision","confidential_remarks":"The paper's broad survey and transparent disclaimers make it a potentially valuable SoK, and the topic is well within the venue's scope. However, the self-citation pattern is notable: Slipstream [54], Tangle 2.0 [17], and fairness work [94] are all authored or co-authored by the paper's own authors, and Slipstream is precisely the protocol that breaks the binary taxonomy. Adding a rule-based placement criterion or a hybrid category would not only fix the technical inconsistency but also mitigate any appearance that the taxonomy was shaped to feature the authors' own protocols. I would also ask the authors to resolve the abstract/Section I.C contradiction about performance evaluation."},"author_rebuttal":null,"desk_editor":{"model":"deepseek-v4-flash","letter":"The paper is worth reading and worth refereeing. It is a real systematization: the two-axis split (availability- vs consistency-focused, with structured/unstructured and optimistic/certified subcategories) is not in the earlier surveys it cites, and it organizes a fast-growing literature in a way that lets you locate protocols and open problems quickly. The authors are also honest in the right places: footnote 2 flags that finality claims are unverified, footnote 3 flags uncertain network-model assignments, and Section I.C explicitly disclaims performance evaluation even though the abstract promises it. That last mismatch is real and should be fixed, but it is cosmetic compared with the classification issue.\n\nThe soft spot is the Slipstream entry. Table II lists Slipstream in both the availability-focused (unstructured DAG) and consistency-focused (optimistic DAG) columns. The paper's own description of Slipstream says it is an ebb-and-flow protocol with an optimistic ordering that is live under a sleepy model and a final ordering that is safe in eventual lock-step synchrony. That is precisely a protocol that refuses the binary trade-off. The paper nowhere defines a hybrid category or says the two classes may overlap, so the central classification is not a partition. This is not a fatal flaw, but it is the kind of thing a serious referee should push on: either add a hybrid/overlap label, or justify why ebb-and-flow protocols get split. Meshcash, also ebb-and-flow, is placed only in the availability column, which makes the Slipstream duplicate look like an oversight rather than a deliberate modeling choice.\n\nThe CAP mapping is likewise informal, and the paper says so. That is acceptable for a survey, but the informality means the taxonomy should be read as a heuristic lens, not a theorem. The attack-vector table and the discussion of desirable properties (fairness, MEV, garbage collection) are useful additions, and the self-citations (Tangle 2.0, Slipstream, the fairness paper) involve protocols that anchor the taxonomy; that is a mild burden, not a disqualifier, because the descriptions match the cited work as far as I can tell.\n\nBottom line: this is a solid, useful survey with one internal inconsistency that needs resolving. It deserves peer review, and I would cite it once the Slipstream issue is addressed. Worth bringing to the reading group if anyone works on DAG consensus or survey methodology.","headline":"Useful SoK with a genuinely new availability/consistency taxonomy, but the binary classification is undermined by its own duplicate entry for Slipstream and needs a clarifying revision before it becomes a stable reference.","tokens_in":29397,"tokens_out":1383,"would_cite":true,"duration_ms":15827,"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":"This SoK argues that DAG-based consensus protocols are best understood through a CAP-theorem-inspired trade-off between availability and consistency, and it sorts the field into two families accordingly: availability-focused protocols…","keywords":["DAG-based consensus","blockDAG","CAP theorem","Byzantine fault tolerance","distributed ledger technology","availability-focused protocols","consistency-focused protocols","broadcast primitives"],"falsifier":"Finding a documented DAG-based consensus protocol that combines open, dynamically available participation with deterministic finality and no BFT-style quorum certificates, and that therefore fits neither the availability-focused nor the consistency-focused description, would refute the classification's completeness. A formal counterexample showing that the consistency-safety and availability-liveness correlations cannot be instantiated together in any DAG protocol would similarly undermine the CAP-inspired framing.","tokens_in":28291,"feed_emoji":"🗺️","tokens_out":3916,"duration_ms":44968,"temperature":0.7,"pith_summary":"This systematization of knowledge claims that the design of DAG-based consensus protocols is governed by the same trade-off captured in the CAP theorem: a protocol can emphasize availability or consistency, but not both. It divides the protocols into availability-focused and consistency-focused families, then subdivides them by DAG structure and by whether block dissemination uses optimistic best-effort broadcast or reliable, certified broadcast. The paper maps each protocol to its participation model, network assumptions, ordering guarantees, finality type, and known attack vectors, and it identifies research gaps such as standardized benchmarks, formal security proofs, fairness, and mempool design. A reader would care because DAG-based ledgers are a major candidate for scalable, low-latency consensus, and this paper provides a structured way to compare their otherwise heterogeneous designs.","feed_headline":"DAG consensus, mapped by availability versus consistency","feed_subtitle":"A new SoK splits blockDAG protocols into two families and lays out their safety, liveness, and finality trade-offs.","key_machinery":"The organizing device is the CAP-theorem-inspired dichotomy itself, which the paper uses to split protocols into availability-focused and consistency-focused categories. The second load-bearing mechanism is the blockDAG: a directed acyclic graph in which each block references multiple predecessors via hash links, establishing causal order and enabling parallel block production, unlike a linear blockchain. Within the two families, the central distinguishing machinery is the broadcast primitive: best-effort broadcast for optimistic DAGs versus reliable or consistent broadcast for certified DAGs, with the certified case making every block a certificate signed by a quorum of validators. The paper maps concepts such as finality, leader-based or leaderless consensus, mempool structure, and network model onto these categories, making the taxonomy the analytical engine of the survey.","core_discovery":"The paper's central claim is that every DAG-based consensus protocol can be classified by which side of the availability-versus-consistency trade-off it prioritizes. Availability-focused protocols, further split into structured DAGs and unstructured DAGs, aim to keep the ledger making progress through lottery-based block proposal, often in permissionless and dynamically available settings, and they typically offer probabilistic finality. Consistency-focused protocols, split into optimistic DAGs and certified DAGs, build on Byzantine fault tolerant agreement, typically in permissioned settings, and they offer deterministic finality. The paper further argues that the choice of broadcast primitive is a defining design decision: best-effort broadcast underlies optimistic DAGs and requires mechanisms to handle equivocation, while reliable or consistent broadcast underlies certified DAGs and represents each block as a quorum-signed certificate. It also surveys the attack vectors that matter for each family, including balance attacks, parasite-chain attacks, equivocation attacks, liveness attacks, censorship, fork bombs, and data-availability attacks, and it discusses desirable properties such as ordering, fairness, MEV protection, and garbage collection.","pith_inferences":["The CAP-inspired divide is an instrumental ordering device rather than a proven theorem; the paper does not derive the two classes from first principles, so the taxonomy is best read as a map of the field rather than a law of nature.","The availability/consistency axis could be combined with the broadcast-primitive axis to make testable predictions: optimistic-DAG families should show lower common-case latency but weaker equivocation resistance than certified-DAG families, a comparison that a common benchmark could settle.","Because the paper deliberately excludes performance evaluation, the classification cannot currently predict which family achieves higher throughput; running the surveyed protocols on a shared benchmark would test whether the taxonomy correlates with measured trade-offs.","The identified research gaps, especially standardized benchmarks and formal security proofs, suggest that the next synthesis of DAG consensus is likely to be empirical rather than purely taxonomic."],"forward_implications":["Designers can locate a protocol by the trade-off it accepts: availability-focused DAGs sacrifice deterministic ordering for continuous progress, while consistency-focused DAGs sacrifice openness for deterministic finality.","The subcategories map onto implementation choices: optimistic DAGs rely on best-effort broadcast and must handle equivocation, whereas certified DAGs sign every block with a quorum certificate and gain stronger consistency guarantees.","Attack surfaces divide by category: availability-focused protocols are more exposed to balance and parasite-chain attacks, while consistency-focused protocols face liveness, equivocation, and censorship risks.","For payment-only applications, partial ordering from the DAG is sufficient, so total ordering is not an unavoidable cost in such systems.","The paper's research gaps point to concrete next steps: standardized benchmark suites, generalized security abstractions, mempool designs that prevent transaction duplication, and fairness and MEV analyses for open writing access."],"supporting_citations":[{"why":"Supplies the original CAP theorem statement that the paper uses as its guiding trade-off.","marker":"[57]"},{"why":"Provides the modern reading of consistency, availability, and partition tolerance that the paper adopts for its classification.","marker":"[58]"},{"why":"Defines the Hashgraph optimistic DAG approach that anchors the consistency-focused optimistic-DAG category.","marker":"[6]"},{"why":"Introduces SPECTRE, a central example of an availability-focused unstructured DAG protocol with partial ordering.","marker":"[16]"},{"why":"Presents PHANTOM and GHOSTDAG, key availability-focused protocols that establish total ordering via k-cluster structure.","marker":"[33]"},{"why":"Introduces Aleph, a certified-DAG protocol whose design and attack analysis support the consistency-focused certified category.","marker":"[38]"},{"why":"Presents DAG-Rider, the asynchronous DAG atomic broadcast protocol that many certified-DAG designs extend.","marker":"[39]"},{"why":"Introduces Narwhal and Tusk, the DAG-based mempool and BFT consensus that define the certified-DAG approach in practical systems.","marker":"[46]"},{"why":"Presents Bullshark, a zero-overhead DAG BFT protocol used as a canonical certified-DAG example and as a comparison point for latency work.","marker":"[47]"},{"why":"Introduces Cordial Miners, a family of optimistic-DAG consensus protocols that underpin several later consistency-focused designs.","marker":"[48]"}],"fun_headline_variants":["DAG consensus: two families, one trade-off","Mapping DAG protocols by availability vs consistency","SoK: blockDAGs split on finality vs liveness","DAG consensus: the availability-consistency divide","BlockDAG protocols: choose your finality trade-off"],"cache_read_input_tokens":3200,"weakest_assumption_plain":"The classification assumes that the CAP theorem is a meaningful lens for DAG-based consensus and that consistency can be informally equated with safety while availability is equated with liveness; if that mapping fails in permissionless or quasi-permissionless settings, the two-category split loses its grounding.","fun_headline_variants_meta":{"raw":{"variants":["DAG consensus: two families, one trade-off","Mapping DAG protocols by availability vs consistency","SoK: blockDAGs split on finality vs liveness","DAG consensus: the availability-consistency divide","BlockDAG protocols: choose your finality trade-off"]},"model":"deepseek-v4-flash","effort":"low","cost_usd":0.000196,"raw_usage":{"total_tokens":1317,"prompt_tokens":859,"completion_tokens":458,"prompt_tokens_details":{"cached_tokens":384},"prompt_cache_hit_tokens":384,"prompt_cache_miss_tokens":475,"completion_tokens_details":{"reasoning_tokens":379}},"tokens_in":475,"tokens_out":458,"duration_ms":4842,"temperature":1.0,"reasoning_tokens":379,"cache_read_input_tokens":384,"cache_creation_input_tokens":0},"cache_creation_input_tokens":0},"created_at":"2026-08-12T20:02:40.200052+00:00","model_set":{"reader":"deepseek-v4-flash"},"falsifier":"Finding a documented DAG-based consensus protocol that combines open, dynamically available participation with deterministic finality and no BFT-style quorum certificates, and that therefore fits neither the availability-focused nor the consistency-focused description, would refute the classification's completeness. A formal counterexample showing that the consistency-safety and availability-liveness correlations cannot be instantiated together in any DAG protocol would similarly undermine the CAP-inspired framing.","supporting_citations":[{"cited_title":"Towards robust distributed systems,","cited_arxiv_id":null,"evidence_quote":"Supplies the original CAP theorem statement that the paper uses as its guiding trade-off."},{"cited_title":"Cap twelve years later: How the","cited_arxiv_id":null,"evidence_quote":"Provides the modern reading of consistency, availability, and partition tolerance that the paper adopts for its classification."}],"review_version":1}