Pith. sign in

REVIEW 3 major objections 4 minor 76 references

Bullshark on Narwhal: Implementation-level Workflow Analysis of Round-based DAG Consensus in Theory and Practice

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

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

Pith's one-line read The paper provides a code-level workflow analysis of Bullshark on Narwhal, tracing a transaction from submission to commitment across worker, primary, consensus, and execution layers.

desk verdict A useful but unverifiable code walkthrough; desk-reject until the author pins the fork and fixes the inconsistent performance claims. read the letter →

arxiv 2507.04956 v1 pith:6Q45M3CM submitted 2025-07-07 cs.CR cs.DC

Yusei Tanaka This is my paper · ORCID
classification cs.CRcs.DC
keywords DAG-basedconsensusNarwhalmempoolBullsharkByzantinefaulttoleranceAtomicbroadcastSuiblockchainround-basedDAGworkflowanalysis
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

The paper tries to establish a complete implementation-level workflow of Bullshark on Narwhal as it runs in the Sui blockchain, following a single transaction from client submission to committed block. It breaks the path into four functional layers — worker, primary, consensus, and execution — and names the Rust functions, configuration parameters, and message types that carry each step. The motivation is the gap between DAG-based BFT theory and practice: many protocols are analyzed only at the pseudocode level, so the paper aims to show how abstract rounds, anchors, and certificates map onto actual production code. If the mapping is right, the paper gives researchers and practitioners a concrete reference for where latency, throughput, and validation costs come from in a system that is described as achieving 297,000 transactions per second with 2-second latency.

What carries the argument

The central mechanism is the round-based DAG of certificates together with a wave-based anchor-commitment rule. Each validator contributes at most one vertex per round, where a vertex is a header listing batch hashes and referencing n-f certificates from the previous round; a certificate is a header carrying 2f+1 signatures. Bullshark groups four rounds into a wave, selects two steady-state anchor leaders plus a fallback leader, and commits an anchor leader when it gathers f+1 votes. Quorum intersection guarantees that any two quorums share at least one honest validator, which lets the linked() predicate order a later anchor after an earlier one when the earlier anchor appears in its causal history; safe-to-skip lets validators move past an uncommitted anchor without risking safety. The second mechanism is Narwhal's primary-worker split: workers reliably broadcast full transaction batches to each other while primaries exchange only headers and certificates, so consensus ordering traffic stays small and the bottleneck moves away from the ordering layer.

What would settle it

Check out a pinned commit of the canonical Mysten Labs Sui repository, open each cited file and line number (for example, batch_maker.rs, proposer.rs, and bullshark.rs), and compare the function names plus the default values for batch size, maximum header delay, and GC depth; if any cited symbol or default differs, the described workflow does not match the codebase it claims to analyze.

Watch

Extended reading notes

Core claim

The paper's central claim is that a 48-step, code-referenced walkthrough captures the entire path from transaction submission to commitment in Bullshark on Narwhal. In Narwhal's worker layer, transactions are validated, batched, hashed, and reliably disseminated to other workers, so that primaries only handle small batch hashes. In the primary layer, proposers assemble headers from batch hashes and certificates of previous rounds, collect 2f+1 votes to form certificates, and broadcast those certificates back into the DAG. Bullshark then consumes certificates round by round, selects anchor leaders per wave, commits an anchor once it receives f+1 votes, orders the committed anchors using the linked() predicate and quorum intersection, and emits committed sub-DAGs. The execution layer receives these committed sub-DAGs, locks the involved objects, executes the transactions, and commits the results, after which garbage collection can discard old DAG vertices. The paper presents this breakdown as the mechanism by which Bullshark achieves Byzantine atomic broadcast without a separate ordering phase, and by which the worker-primary separation lets throughput scale while keeping consensus communication low.

Load-bearing premise

The entire workflow is anchored to the author's own fork of the Sui repository at github.com/YuseiWhite/sui, labelled as Mysten Labs code with no commit hash, so if that fork differs from the canonical Sui/Narwhal code, the described functions and line references may not be what actually runs in production.

Editorial extensions

If this is right

  • A transaction's path to a committed block passes through four distinct layers, and the dominant latency contribution is Narwhal's maximum header delay of 1,000 ms rather than Bullshark's ordering computation.
  • Because batches are reliably disseminated before ordering, validators do not need to re-validate transaction contents at consensus time, so validation cost is paid once in the worker layer.
  • Bullshark commits an anchor with f+1 votes and uses a fallback leader when the steady-state leader fails, which preserves liveness without a view-change protocol.
  • The worker-primary separation keeps consensus traffic limited to headers and certificates, avoiding the per-leader communication bottleneck that limits leader-based protocols such as HotStuff.
  • Garbage collection removes DAG vertices older than 50 rounds after they have been ordered, bounding memory while preserving the already-committed order.

Reading between the lines

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

  • A reader could test the workflow's fidelity by pinning a commit of the canonical Mysten Labs Sui repository and checking whether each cited file, function, and default parameter (batch size 32, header delay 1,000 ms, GC depth 50) matches the author's fork; the result would confirm or refute that the map describes the production system.
  • The 297,000 tx/s and 2-second latency figures appear to be quoted from the original Bullshark benchmark rather than measured here, so a natural next experiment is to reproduce those numbers with the stated parameters on the current Sui network.
  • The workflow exposes a small set of tuning knobs — batch size, maximum header delay, and garbage-collection depth — that could be simulated independently to predict the latency, throughput, and memory trade-offs before running a full BFT deployment.
  • The paper's CAP-theorem framing is loose: in the standard interpretation, a partition would pause liveness to preserve consistency, so calling the protocol 'Consistency plus Partition Tolerance' obscures the real trade-off between safety and availability.
Share X Bluesky LinkedIn Reddit HN

Editorial analysis

A structured set of objections, weighed in public.

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

Referee Report

3 major / 4 minor

Summary. The paper claims to provide an implementation-level workflow analysis of Bullshark on Narwhal, tracing a transaction from client submission through the worker and primary nodes, the Bullshark consensus protocol, and finally execution and commitment. It decomposes the system into functional layers, presents component diagrams for the worker and primary nodes, gives a 48-step narrative of the data flow, and concludes with performance statements about TPS and latency. The theoretical parts summarize DAG-based consensus, Narwhal's properties, and Bullshark's leader-based ordering, with several informal lemmas.

Significance. If the workflow map is accurate and verifiable, it would be a useful code-level guide for practitioners and researchers trying to connect the Bullshark/Narwhal protocols to the Sui implementation. The paper's strength is its attempt to ground each step in specific Rust components and to separate worker, primary, consensus, and execution concerns. However, the value of the contribution depends entirely on the reliability of the cited code references and on the consistency of the performance claims; both are currently problematic. The paper does not present new theoretical results or new measurements, so its significance is primarily descriptive.

major comments (3)
  1. [§4.3, §6, footnotes 1–15 and 18–92] All code references point to https://github.com/YuseiWhite/sui, labeled 'Mysten Labs' or 'Mysten Labs and Facebook', but no commit hash is given and the repository is not the canonical Mysten Labs/sui repository. For example, footnote 1 cites 'crates/sui-core/src/consensus manager/narwhal manager.rs', a path containing a space that does not match normal Rust file naming and cannot be resolved as printed. Because the central claim is an 'implementation-level' workflow analysis, every step that invokes a specific file, function, or line number must be verifiable. Please replace all citations with pinned URLs from the canonical repository (or clearly document and justify the divergence of the fork), and provide commit hashes and valid paths.
  2. [Abstract; §7] The abstract states that Bullshark achieves 297,000 transactions per second with 2-second latency, while Section 7 reports 130,000 tx/s for 50 validators, 100,000 tx/s in some Byzantine-fault setting, and 60,000 tx/s when 3 of 10 validators are faulty. These numbers are not reconciled, and no benchmark configuration, hardware, transaction size, or measurement methodology is given. Please state one headline performance figure with its exact experimental conditions, or remove the unsubstantiated numbers from the abstract.
  3. [§4.2, Lemmas 1–5] Lemmas 1–5 are presented with very terse informal proofs that contain typos and unclear steps; for instance, Lemma 4's proof does not clearly derive the claimed quorum-intersection bound from the certification rule, and Lemma 5's proof is too compressed to validate the 1/2-chain-quality claim. If these are summaries of known results, cite the original proofs; if they are intended as new proofs, they need complete, precise arguments. As written, they do not support the claim that Narwhal satisfies these five properties.
minor comments (4)
  1. [Footnotes] Footnote 13 is missing from the numbering: footnote 14 follows footnote 12, and several footnotes (e.g., 1 and 2) are duplicates that point to the same URL.
  2. [General] The manuscript contains extensive garbled Japanese text and encoding artifacts, especially around Figures 4–6 and in the conclusion, which makes some passages unreadable; please provide a clean, correctly typeset version.
  3. [References] References [2] and [36] are the same paper (the SoK on DAG-based blockchain systems), and reference [5] is a blog-style performance report; please deduplicate references and replace non-peer-reviewed sources with stable citations where possible.
  4. [§3.2] Figure 3 is difficult to interpret: the caption and the labels inside the figure are not legible in the provided copy, and the relationship between the 'tangle' and 'block-lattice' axes is not explained clearly in the text.

Circularity Check

1 steps flagged · score 2.0 of 10

Self-referential fork citation underlies the code walkthrough; no fitted prediction, so circularity is minor.

  1. self citation load bearing [Footnotes 1-15 and 18-92; Sections 4.3 and 6 workflow steps 1-48]
    "ʢ஫1ʣ ɿMysten Labs, ”Narwhal manager”, GitHub, https://github.com/YuseiWhite/sui /blob/mainnet/crates/sui-core/src/consensus manager/narwhal manager.rs, February 2025."

    Every implementation-level step of the workflow is anchored by footnotes to github.com/YuseiWhite/sui, the author's own fork, while being labeled 'Mysten Labs' or 'Mysten Labs and Facebook'. No commit hash or diff to the canonical Mysten Labs/sui repository is given. The paper's central claim is that this is an implementation-level analysis of Bullshark on Narwhal, but the code-level evidence is a repository the author controls and vouches for, attributed to the external project. Verifying the claim therefore requires trusting that the author's fork matches the production codebase, which is exactly the assertion the paper makes. This is a self-referential evidentiary chain rather than an independent grounding, so the code walkthrough cannot be externally checked as printed.

full rationale

The paper derives no fitted quantity, makes no empirical prediction, and contains no equation that reduces by construction to its inputs. Its conceptual content—round-based DAGs, the Narwhal primary/worker architecture, and Bullshark's anchor-ledger commitment rule—is independently supported by the cited Bullshark and Narwhal papers and Sui documentation. The only circularity burden is evidentiary: the implementation-level footnotes all point to the author's own GitHub fork labeled as Mysten Labs code, with no pinned commit, so the workflow description is self-referential rather than independently verifiable. That is a provenance and verifiability concern, not a mathematical or derivational circularity, and it does not make the central expository claim tautological. A low score is therefore appropriate.

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

No free parameters are fit to data: the paper reports no new benchmarks, and the configuration constants (batch size, header delay, GC depth) are read from code, not fit. No new theoretical entities are introduced. The protocol, the failure detector, and the quorum system are all imported from prior literature.

assumptions (4)
  • domain assumption The system model assumes n = 3f + 1 validators with at most f Byzantine faulty validators.
    Invoked throughout sections 1, 4.2, and 5.3.2; the quorum sizes 2f+1 and the intersection argument depend on this bound.
  • domain assumption Quorum intersection: any two quorums of size 2f+1 among 3f+1 nodes share at least one honest validator.
    Used in Section 5.3.2 to prove ordering of anchors; standard in BFT literature, accepted from prior work.
  • domain assumption Liveness requires a partial synchrony model with an unreliable failure detector ^P that eventually provides strong completeness and eventual strong accuracy.
    Invoked in Section 5.3.4 to guarantee that validators can skip faulty leaders and make progress; the paper assumes this detector exists without proving it.
  • domain assumption Narwhal ensures reliable broadcast properties (integrity, availability, containment, 2/3-causality, 1/2-chain quality) via its worker and primary architecture.
    The paper states these as lemmas but gives only proof sketches; they are inherited from the Narwhal paper rather than proved here.

how reviews work

0 comments
Cite this review

Pith. "Pith review of Bullshark on Narwhal: Implementation-level Workflow Analysis of Round-based DAG Consensus in Theory and Practice." pith.science (2026). https://pith.science/paper/6Q45M3CM

@misc{pith2026250704956,
  author       = {Pith},
  title        = {Pith review of: Bullshark on Narwhal: Implementation-level Workflow Analysis of Round-based DAG Consensus in Theory and Practice},
  year         = {2026},
  howpublished = {\url{https://pith.science/paper/6Q45M3CM}},
  note         = {Machine review of arXiv:2507.04956}
}
read the original abstract

Round-based DAGs enable high-performance Byzantine fault-tolerant consensus, yet their technical advantages remain underutilized due to their short history. While research on consensus protocols is active in both academia and industry, many studies overlook implementation-level algorithms, leaving actual performance unclear - particularly for theoretical protocols whose practical performance cannot often be evaluated. Bullshark, a Round-based DAG BFT protocol on Narwhal mempool, achieves optimal performance: 297,000 transactions per second with 2-second latency. We analyze the algorithm's workflow, from transaction submission to blockchain commitment, breaking it down layer by layer at the functional level and delineating the key features and interactions of the Bullshark and Narwhal components. Future work aims to improve performance in Byzantine fault environments and optimize trade-offs in the CAP theorem.

Discussion (0). Continue with ORCID to comment.

Reference graph

Works this paper leans on

76 extracted references · 69 canonical work pages

  1. [1]

    ং ࿦ Bullshark ͱ͸ɼNarwhalங͞Εͨɼ෦෼ಉ దԽͨ͠ DAG ϕʔεͷ BFT ίϯηϯαεϓϩτίϧͰ ͋ΔɽύϒϦοΫύʔϛογϣϯϨεϒϩοΫνΣʔϯʹ͓͍ ڈ10 ɼϏβϯνϯϑΥʔϧττϨϥϯεੑʢBFTʣ͕஫໨͞Ε ͖ͯͨɽͦͷதͰɼ ϒϩοΫνΣʔϯͷεέϥϏϦςΟ໰୊[1] େ͢ΔͨΊʹBFT ίϯη ϯαεϓϩτίϧʹ Directed Acyclic GraphʢDAGʣτϙϩδʔ — 1 — Λಋೖͨ͠ίϯηϯαε͕ఏҊ͞Εଓ͚͍ͯΔɽ ʢਤ 1ʣ͜Ε ɼετϨʔδͷΦʔόʔϔουΛগͳ͘͢Δ͜ ্ͤ͞Δํ๏ͰɼΑΓଟ͘ͷτϥϯ βΫγϣϯΛॲཧ͢Δ͜ͱΛՄೳʹͨ͠΋ͷͰ͋Δ [2]೦ ͱͯ͠͸ɼ2015 ೥ɼS.D.Lerner ʹΑͬͯɼDAG-chain ...

    work page

  2. [3]

    Directed Acyclic Graph ʢDAGʣ

    work page

  3. [4]

    Ͱɼͦ ͷ DAG͢Δɽ4

    ͰॳΊͯఏҊ͞Εͨɽ Bullsharkଌ ஋ͱͯͦ͠ͷύϑΥʔϚϯε͕ 297000+TPS ͰϒϩοΫνΣʔ ࿥͍ͯ͠Δɽ͜Ε͸ɼύ ͍͜ͱͰ஌ΒΕΔ Solanaେ 65,000 TPS [ 5]͑ΔͱɼϒϩοΫνΣʔϯͷύ · ΔͨΊɼBullsharkͷϒϩοΫνΣʔϯ େՄೳੑʹ͍ͭͯཧ ղ͢Δ͜ͱʹͭͳ͕Δɽ·ͨɼ Bullshark ͱ Narwhal ͸Φʔϓ ૷͞Ε͓ͯΓɼཧ࿦తͳ෼ੳʹͱͲ·Δ͜ͱ͸ͳ Λ௚઀෼ੳ͢Δ͜ͱ͕Ͱ͖Δɽ 0 10 20 30 40 50 2015 2016 2017 2018 2019 2020 2021 2022 2023 ਤ 1: ͜Ε·ͰʹఏҊ͞Εͨ DAG ϕʔεͷίϯηϯαεϓϩτ ίϧͷ૯਺ DAGڀݚ [2], [6]૷ϨϕϧͰͷ ͷϒϩοΫ...

    work page 2015

  4. [5]

    1 DAG ͱ ͸ DAG ͱ͸ɼDirected Acyclic Graphඇ॥ ଄ͷ෼໺ͷάϥ ଄Ͱ ͋Δɽ2 ͭͷ௖఺ʢvertexʣͱลʢedge੒͞Εɼ͜ͷล͸ ͨ ͳ͍ɽ͋ͳ͕ͨΤϯδχΞͰ͋ΔͳΒ͹ GitHub Ͱͷόʔδϣ ཧ͕ DAGΘΕΕ͹ɼΠϝʔ ਤͷΑ͏ʹɼͲͷઌ૆͔ ਎ʹͳΔͱ͍ͬͨ͜ͱΛΠϝʔδ͞Ε͍ͨɽ ਤ 2 ͷྫʹै͑͹ɼaྻత ʹ͸ e෼ʹ౸ୡ͢Δͱ͍͏͜ͱͰ͋Δɽ a b c d e ਤ 2: DAG ͷྫ

    work page

  5. [6]

    2 DAGֱ[29] tangleblock- latticeflat- set blockchain よ り コ ン フ リ ク ト を 低 減 よ り セ キ ュ ア ਤ 3: DAGਤ ͜ͷਤ͸ɼDAG܎ؔ ͨ͠΋ͷͰ͋ΔɽηΩϡϦςΟ ʹύϑΥʔϚϯε ͕ঃʑʹ௿Լ͍ͯ͠ΔͨΊɺTPS୺ͷ flat-set γεςϜͰҰൠ ଄Ͱ͋Γɼӈ୺ͷ blockchainతͳ ͕ͲͪΒ΋ DAG଄Ͱ ͋Δɽblockchain଄͸ɼEthereumங ͢Δɽ͜Ε͸ϝϯϓʔϧʹ͓͍ͯ΋͍͏͜ͱ͕Ͱ͖ɼଟ͘ͷϒ ଄Ͱɼ୯७ʹτϥϯβΫγϣϯ ʹ௥Ճ͞ΕΔ͚ͩͰ͋ΔɽDAG଄Ͱ͋Δ Block-Lattice ͱ Tangle ͸ɼӈ୺ͷ blockchain ͱൺ΂ͯɼτϥϯβΫγϣϯ ͷτϥϯβΫγϣϯͷ͓ ʹτ...

    work page

  6. [7]

    ͷϘτϧωοΫʹͳΔ Ͱ͖ͳ͍͜ͱͰ͋ ͕Ͱ͖ͳ͍ཧ༝͸ɼ blockchain଄ͷΑ͏ʹҰͭ ূ͠ ৽͍ͯ͠Δ͔ΒͰ͋Δɽ (2)͍ϨΠςϯγ

    3 DAG༻͢ΔϕωϑΟοτ DAG͢Δ՝୊͸ɼ(1) ௿εϧʔϓοτɼ(2)͍ϨΠς ϯγɼ(3)ʹΑΔύϑΥʔϚϯεͷେ෯௿ԼͰ͋Δɽ (1) ௿εϧʔϓοτ. ͷϘτϧωοΫʹͳΔ Ͱ͖ͳ͍͜ͱͰ͋ ͕Ͱ͖ͳ͍ཧ༝͸ɼ blockchain଄ͷΑ͏ʹҰͭ ূ͠ ৽͍ͯ͠Δ͔ΒͰ͋Δɽ (2)͍ϨΠςϯγ. ࣍ ͸ɼτϥϯβ ೲ͞ΕΔɽ (3)ʹΑΔύϑΥʔϚϯεͷେ෯௿Լ. ͖ͯ΋γεςϜ͕ϑϦʔζ ͞Ε͍ͯΔ͕ɼ΄ͱΜͲશͯͷίϯ ೳ͕௿Լ͢Δɽྫ͑͹ɼ HS ͸ ϐʔΫੑೳͰ 70,000 tx/s͕ͨ͠ɼ10 ϊʔ υͷ͏ͪɼ3ɼϐʔΫੑೳ͸10 ෼ͷ 1 ఔ౓ ͳ͠ͷ 2 ඵఔ౓͔Β 15 ഒͷ 30 ඵఔ౓·Ͱ૿Ճ͢Δ [22]ɽ ෰͚ͩͰͳ͘ɼDAG ͸ҎԼͷϕωϑΟοτ डͰ͖Δɽ(1...

    work page

  7. [8]

    Narwhal Mempool Protocol

    work page

  8. [9]

    1ཁ Narwhal ϝϯϓʔϧϓϩτίϧͷ໨త͸ɼίϯηϯαεʹఏ ग़͢ΔτϥϯβΫγϣϯͷՄ༻ੑʢ AvailabilityʣΛຬͨ͠ɼ଱ อ͠ͳ͕ΒɼτϥϯβΫγϣϯͷฒྻॱং෇͚ΛՄ ʹॲཧ͢Δ͜ ͱ͕Ͱ͖ΔΑ͏ʹ͢Δ͜ͱ΍ɼτϥϯβΫγϣϯͷ఻೻ͱॱং ෇͚ϝΧχζϜΛ෼͚Δ͜ͱͰɼγεςϜશମͷεϧʔϓοτ ͞Εͳ͍Α͏ ʹ͢Δ͜ͱͰ͋Δɽ ՝୊. Tendermint [17], [33] ͳͲଟ͘ͷίϯηϯαεϓϩτί ϧͰ͸ɼτϥϯβΫγϣϯͷ୅ΘΓʹϒϩοΫΛϒϩʔυΩϟ ετͯ͠ɼ Ϧʔμʔ͸ϒϩοΫͷϋογϡΛఏҊ͍ͯ͠ΔͨΊɼ શੑʢIntegrityʣΛϝϯϓʔϧʹґଘ͍ͯ͠Δɽͭ·Γɼ Ϧʔμʔ͕ఏҊ͢ΔϒϩοΫͷ಺ͷτϥϯβΫγϣϯ͕ਖ਼͍͠ ਎ͷϝϯϓʔϧ Ռɼ ཰ੑ͕ଛͳ...

    work page

Show all 76 references
  1. [10]

    2͕ຬͨ͢ηΩϡϦςΟಛੑ Narwhalͷ 5શੑʢ In- tegrityʣ ͱϒϩοΫͱূ໌ॻͷՄ༻ੑ ʢAvailabilityʣ ͸ɼ ϒϩο ੑʢCon- tainmentʣ ͱ2/3-ҼՌੑ ʢ2/3-Causality͍εϧʔϓο ͍ͯ͠Δɽ1/2-ʢ1/2-Chain Qualityݕ খԽ͍ͯ͠Δɽ ิ୊ 1: Integrity.ҝ͔ ͢ΔͨΊɼσʔλͷॲཧΛ͢Δͱ͖ʹৗʹσʔλͷ಺༰ ͚͕ແ͍͜ͱΛอূ͍ͯ͠Δɽhonest ͳϊʔυʹΑ ͍σʔλΛऔΓѻ͏͜ͱ ্͢ΔɽΫΥʔϥϜΠ ϯλʔηΫγϣϯʢQuorum Inte...

  2. [11]

    3੒ཁૉ: Primary-Worker Architecture バッチ ラ ウ ン ド r クライアント バッチ バッチ ワ ー カ ー ノ ー ド バッチ バッチ バッチ バッチ バッチ バッチ プ ラ イ マ リ ノ ー ド ブロック (r,i) 証明書リスト バッチ i の署名 証明書 (r,i) ブロックハッシュ 2f+1 の署名 ブ ロ ッ ク の デ ー タ 構 造 ブロック (r,i) 証明書リスト バッチ i の署名 ブロック (r,i) 証明書リスト バッチ i の署名 証明書 (r,i) ブロックハッシュ 2f+1 の署名 ...

  3. [12]

    3. 1 ϫʔΧʔϊʔυ ϫʔΧʔ͸ɼΫϥΠΞϯτ͔ΒͷτϥϯβΫγϣϯͷॲཧͱ ূʢValidationͱ σʔλͷόονΛૹ৴͠ଓ͚ɼσʔλͷόοδ͸Ұఆ஝ੵ͞Ε Δͱɼσʔλͷόοδͷϋογϡͱͯ͠ͷμΠδΣετΛό Ϧσʔλ಺ͷϓϥΠϚϦʹసૹ͢Δɽόοδ͸ Sui Ͱ͸ίϨΫ ͢Δͷ͸ɼ ෆཁͳॏෳ௨৴Λආ͚ɼωοτϫʔΫશମͰσʔλ͕ਝ଎ʹ఻ ʹ ্͢ΔͨΊͰ͋Δɽ͜ΕΒҰ ͳ͘ωοτ ͠ଓ͚Δɽͭ·Γɼσʔλͷ఻೻Λ͢Δ ׂ Ͱ͋Δɽ Receiver 自 身 の プ ラ イ マ リ か ら ク ラ イ ア ン ト か ら 他 の ワ...

    2025

  4. [13]

    Batch Maker ͸ෳ਺ͷτϥϯβΫγϣϯΛόονͱͯ͠· ͱΊΔɼ2) ͦΕΛϩʔΧϧ্ʹอଘ͢Δɼ 3) ଞͷόϦσʔλ ਎ͷϓϥΠϚϦϊʔυ΁όονΛૹ৴͢ Δɼ4)఺Ͱɼόονͷ μΠδΣετΛτϥϯβΫγϣϯૹ৴ऀͰ͋ΔΤϯυϢʔβʹ Λ୲͍ͬͯΔɽ - Quorum Waiterʢ஫7ʣ Quorum Waiter ͸৽͍͠όον͕͜ͷνϟωϧΛ௨ͯ͡ड৴ ͞ΕΔͱɼଞͷϫʔΧʔ΁όονΛϒϩʔυΩϟετ͢Δɽૹ ɼଞͷϫʔΧʔ͔Βͷ ACK Λ଴ͪɼACK ΛૹΓฦ͞ΕΔ ֬ ೝͰ͖ΔɽQuorum Λୡ੒͢ΔͨΊʹ͸ϫʔΧʔ͝...

  5. [14]

    2 ϓϥΠϚϦϊʔυ ΛՌͨ͢Ϛ γϯͰ͋Γɼ Bullshark ίϯηϯαεʹ౉͢ϥ΢ϯυϕʔεͷ DAGஙͱͦͷ४උ΍ௐ੔Λ୲͏ɽϓϥΠϚϦϊʔυ͸σʔ λͷ఻ൖ଎౓ʹ੍໿͞Εͳ͍͕ɼϫʔΧʔϊʔυ͸೚ҙͷ਺ͩ ͶϓϥΠ ϚϦͱͳΔɽ ׂ

    3. 2 ϓϥΠϚϦϊʔυ ΛՌͨ͢Ϛ γϯͰ͋Γɼ Bullshark ίϯηϯαεʹ౉͢ϥ΢ϯυϕʔεͷ DAGஙͱͦͷ४උ΍ௐ੔Λ୲͏ɽϓϥΠϚϦϊʔυ͸σʔ λͷ఻ൖ଎౓ʹ੍໿͞Εͳ͍͕ɼϫʔΧʔϊʔυ͸೚ҙͷ਺ͩ ͶϓϥΠ ϚϦͱͳΔɽ ׂ. ʢ஫6ʣ ɿMysten Labs and Facebook, ”Batch maker,” GitHub, https://github.com/Yusei White/sui/blob/mainnet/narwhal/worker/src/batch maker.rs, February 202...

    2025

  6. [15]

    Bullshark Consensus Protocol

  7. [16]

    1ཁ Bullshark ͸ɼNarwhal ϝϯϓʔϧͷ DAGங͞Εͨɼ θϩΦʔόʔϔουͷ BFT ΞϓϩʔνͷϏβϯνϯΞτϛο όʔδϣϯͷ ެ ͨ͠ॳΊͯͷϓϩτίϧͰ͋Δɽ͜ΕʹΑΓ DAG-Rider [34]த தͰൃ ׬ ͖Δ͜ͱ͸ ໓ଟʹແ͍ɽ

  8. [17]

    1 DAG ϕʔείϯηϯαεϓϩτίϧʹ͓͚Δ՝୊ DAG ϕʔεͷίϯηϯαεϓϩτίϧ͸ɼલड़ͨ͠௨Γɼ௿ — 7 — ʹΑΔύϑΥʔϚϯε ૊ΈͰ͋Δ͕ɼͲͷΑ͏ʹ DAGߏ Ή४උΛ͢ ؏ ੑ ʢConsistencyʣ ΛพΖʹ͠ɼ Մ༻ੑ ʢAvailabilityͨ͠ DAG ϕʔεͷίϯηϯαεϓϩτίϧ΋ଟ͍ɽྫ͑͹ɼ IOTA

    2. 1 DAG ϕʔείϯηϯαεϓϩτίϧʹ͓͚Δ՝୊ DAG ϕʔεͷίϯηϯαεϓϩτίϧ͸ɼલड़ͨ͠௨Γɼ௿ — 7 — ʹΑΔύϑΥʔϚϯε ૊ΈͰ͋Δ͕ɼͲͷΑ͏ʹ DAGߏ Ή४උΛ͢ ؏ ੑ ʢConsistencyʣ ΛพΖʹ͠ɼ Մ༻ੑ ʢAvailabilityͨ͠ DAG ϕʔεͷίϯηϯαεϓϩτίϧ΋ଟ͍ɽྫ͑͹ɼ IOTA

  9. [18]

    2. 2 ཧ࿦తͳ DAG-Rider ʹ͓͚Δ՝୊ BullsharkͰূ໌ॻʹΑͬͯೝ ଄Խ͞Εͨ DAG༻͍ͯ͠Δ͕ɼ͜Ε͸ Reliable Broadcast Protocol ʹΑͬͯୡ੒͞Ε͍ͯΔɽReliable ͳϒϩʔ υΩϟετ͸ BEΔͨΊʹɼ௨ ৴ͷΦʔόʔϔου͕ൃੜ͢Δɽ௨৴ͷΦʔόʔϔου͕Ҿ͖ ͜͞ΕΔͱϨΠςϯγ΋૿Ճ͢ΔɽίϯηϯαεϨΠϠʔ΁ ͷαϒ DAG ΁ͷૹ৴͸ Narwhal ͷϓϥΠϚϦϊʔυ͕୲ͬͯ ͍Δɽ͜͜ͰίϯηϯαεϨΠϠʔ͸ωοτϫʔΫͷঢ়ଶʹ ͸ɼ ؀ ͜Γɼ͜Ε͕ཧ૝తͳ TPS͠...

  10. [19]

    2. 3 BAB ໰ ୊ Reliable Broadcast Protocol ͸ɼγεςϜ಺ʹҰఆͷ faulty ͳ ͯ͠΋ reliable ͳϝοηʔδͷ఻೻Λอূ͢Δ͜ ্ͤ͞ɼAgreement, Integrity, Validity Λຬͨ͢͜ͱ͕Ͱ͖Δ͕ɼશॱংʢTotal OrderʣΛอূ ෷ΛՄೳͱ͠ɼτϥϯβΫγϣϯ ੑ΋อূͰ͖ͳ͍ͨΊɼDLT ͏͜ͱʹͭͳ͕Δɽ Reliable Broadcast Protocol ͕ຬͨ͢ Agreement, Integrity, Validity ͚ͩͰ ͳ͘શॱংɼ Tot...

  11. [20]

    2. 4ฏੑͱΨϕʔδίϨΫγϣϯͷτϨʔυΦϑ ฏੑͱ͸ɼBAB ໰୊ͷ ValidityͰ͋Δɽ DAG-Rider [34]ฏੑΛຬ͍ͨͯ͠Δ΋ͷͷɼFLP ෆ Մೳੑ [41]ઃఆʹ͓͍ͯɼϒϩοΫΛϒϩʔ υΩϟετ͠ͳ͍ faulty͍ϥ΢ϯυΛΨϕʔδ ผͰ ͖ͳ͍͜ͱ͔Βɼର৅ʹ͍ͨ͠ύʔςΟ͚ͩΛΨϕʔδίϨΫ ͏͜ͱ͕Ͱ͖ͳ͍ɽલͷϥ΢ϯυͰ·ͩॱং෇͚͞ র͢Δऑ͍ϦϯΫΛར༻͢Δ͜ͱʹ ऴతʹॱং෇͚͞ΕΔ͜ͱΛอ ূ͍ͯ͠Δ͕ɼ͜Ε΋ཧ࿦తͳ΋ͷͰͲͷΑ͏ʹΨϕʔδίϨ ͞Ε͍ͯͳ͍ɽ — 8 — ҰํɽNarwhal૷͠...

  12. [21]

    3 Bullshark Consensus Protocol

  13. [22]

    1 Bullshark ͷಛ௃ ωοτϫʔΫ௨৴ϨΠϠʔͱίϯηϯαεϨΠϠʔͷ෼཭

    3. 1 Bullshark ͷಛ௃ ωοτϫʔΫ௨৴ϨΠϠʔͱίϯηϯαεϨΠϠʔͷ෼཭ . Bullshark ίϯηϯαεϨΠϠʔ͸ɼNarwhal ͰͷωοτϫʔΫ ͍ͯ͠Δɽ͜Ε͸ɼ Reliable Broadcast Protocol ʹΑΔ௨৴ΦʔόʔϔουͷՄೳੑΛίϯη ·ͳ͍ͱ͍͏͜ͱͰ͋Δɽωοτϫʔ ͍ͯ͠ ΔͨΊɼ௨৴ΦʔόϔουθϩͰίϯηϯαεϩδοΫΛਐΊ Δ͜ͱ͕Ͱ͖ɼ ·ͨɼ ந৅Խ͢Δ͜ͱ͕Ͱ͖ΔΑ͏ʹͳΔͨΊɼ ૷ɾอक͕ՄೳͱͳΔɽωοτϫʔΫͷ ͍ͯ͠Δͱ͍͏ͷ͸ɼτϥϯβΫγϣϯͷॱং෇͚ ͷτϥϯβ...

  14. [23]

    3. 2 ϥ΢ϯυϕʔε DAG ίϛοτϓϩηε ਤ 7 Ͱ͸ɼ𝑛 = 4, 𝑏 = 1 Ͱͷ Bullshark ϓϩτίϧͷίϛο τϓϩηεͷঢ়ଶΛද͍ͯ͠ΔɽDAG਺ϥ΢ϯυͰ͸ɼ ͞Εɼબग़͞Εͨ Anchor Leader͠ɼਤ ͞Ε͍ͯΔɽ͜͜Ͱ͸ɼͲͷΞϯΧʔ ఆ͢Δ͜ͱ͕໨తͰ͋Δɽ DAG ͷશͯͷϊʔυΛશॱং෇͚͢Δʢ Total OrderingʣͨΊ ͷཤ ͏ɽ 𝐴2ؔ ͞Ε͍ͯΔɽ A1バ リ デ ー タ 1 バ リ デ ー タ 2 バ リ デ ー タ 3 バ リ デ ー タ 4 ラ ウ ン ド 1 ラ ウ ン ド ...

  15. [24]

    3. 3 ϦʔμʔλΠϓͱϦʔμʔબग़ Bullshark΢Σʔϒ͝ͱʹ 2 ͭͷछྨɼ 3 ͭͷϦʔ ͍ͬͯΔɽ Steady-State Leader ͱ Fallback Leader ͕ 2 ͭͷϦʔμʔλΠϓͰ͋ΔɽSteady-State Leaderத ΢Σʔϒ͝ͱʹίϛοτ͞ΕΔɼઌड़ͷΞϯΧʔϦʔμʔ ͱಉ༷Ͱ͋Δɽ1 ΢Σʔϒ͸ 4 ϥ΢ϯυͰ͋ΔͨΊɼ΢Σʔϒ ͝ͱʹ 2 ͭͷ Steady-State Leader ͕બग़͞ΕΔɽ Bullshark Ͱ ϝΧχζϜ͕ෆཁͰ͋Δͨ Ίɼ ϥ΢ϯυ1 ͷϦʔμʔ͕ honest...

  16. [25]

    3. 4૷ DAG-Rider [34]ฏੑϝΧχζϜͱ Narwhal [20] ͷΨϕʔ ͢ΔɽΑͬͯɼ ͜Εʹରͯ͠ɼ Bullshark૷͠ͳ͕Β΋DAG-Rider [34]͍ͷར఺ ฏੑΛอূ͢Δɽ Hashgraph [37] Ͱ͸ DAG଄Խ͞Ε͍ͯͳ͍ͨΊɼ ৽͍͠ ϒϩοΫͷ validityূ͢ΔͨΊʹ DAG ͷϓϨϑΟοΫε ͢ΔͨΊ ૷͢Δ͜ͱ ͸Ͱ͖ͳ͍ɽ Narwhal [20]ɼDAG-Rider [34]ɼAleph [42] Ͱ͸ɼ ଄Խ͞Εͨ DAGฏੑ ૷ ɼશͯͷ honest͢ Δ͜ͱ͸೉͍ͨ͠ΊɼBu...

    2025

  17. [26]

    ʧ 𝑉 ={𝑣1, 𝑣2,

    ϒϩοΫνΣʔϯίϛοτ·ͰͷΞϧΰϦ ζϜ クライアント A Receiver Batch Maker 4: bA を 生 成 す る dA v1 内 の ワ ー カ ー ノ ー ド Payload Reveiver Proposer 7: hA を 生 成 す る 11: certA を 生 成 し ， 12: ブ ロ ー ド キ ャ ス ト v2 内のプライマリ v3 内のプライマリ v4 内のプライマリ 10: hA に 署 名 し ， 配 信 す る 10: hA に 署 名 し ， 配 信 す る 10: hA に 署 名 し ， 配 ...

    2025

  18. [27]

    Nakai, A

    T. Nakai, A. Sakurai, S. Hironaka, and K. Shudo, ”The blockchain trilemma described by a formula,” the 2023 IEEE International Con- ference on Blockchain, pp.41-46, December 2023

    2023

  19. [28]

    A. Back, M. Corallo, L. Dashjr, M. Friedenbach, G. Maxwell, A. Miller, A. Poelstra, J. Tim ´on, and P . Wuille, ”Enabling blockchain innovations with pegged sidechains,” Blockstream, https://blockstream.com/sidechains.pdf, October 2014

    2014

  20. [29]

    Lerner, ”DagCoin Draft”, Bitslog, https://bitslog.com/wp- content/uploads/2015/09/dagcoin-v41.pdf, September 2015

    S.D. Lerner, ”DagCoin Draft”, Bitslog, https://bitslog.com/wp- content/uploads/2015/09/dagcoin-v41.pdf, September 2015

    2015

  21. [30]

    Sompolinsky and A

    Y . Sompolinsky and A. Zohar, ”Secure high-rate transaction process- ing in bitcoin,” Proceedings of International Conference on Financial Cryptography and Data Security, pp.507–527, Janurary 2015

    2015

  22. [31]

    Solana Foundation, ”Network Performance Report: July 2023,” Solana, https://solana.com/ja/news/network-performance- report-july-2023, July 2023

    2023

  23. [32]

    Raikwar, N

    M. Raikwar, N. Polyanskii, and S. M¨ uller, ”SoK: DAG-based consen- sus protocols,” 2024 IEEE International Conference on Blockchain and Cryptocurrency, pp.1-18, May 2024

    2024

  24. [33]

    Amores-Sesar and C

    I. Amores-Sesar and C. Cachin, ”We will DAG you,” arXiv preprint arXiv:2311.03092, November 2023

    2023 arXiv

  25. [34]

    P . Raju, S. Ponnapalli, E. Kaminsky, G. Oved, Z. Keener, V . Chi- dambaram, and I. Abraham, ”mLSM: making authenticated storage faster in ethereum,” USENIX, https://www.usenix.org/system/files/co nference/hotstorage18/hotstorage18-paper-raju.pdf, 2018

    2018

  26. [35]

    ͸ Tangle༻͓ͯ͠Γɼ͜Ε͸ 1 ͭͷτϥϯβΫ γϣϯ͕਌ͱͳΔ 2܁ ଄ԽͰ DAGτϥ ૊ ΈʹΑΓτϥϯβΫγϣϯσʔλͷվ᜵Λ๷͙͜ͱ͕Ͱ͖͍ͯ Δ΋ͷͷɼ ൒ॱং ʢPatial OrderੑΛอূͰ͖ͳ ҙ͢ΔτϥϯβΫγϣϯ ͢Δτϥϯβ Ϋγϣϯ͕ϒϩοΫνΣʔϯʹ௥Ճ͞ΕΔՄೳੑ͕͋Γɼѱҙ ͢ΔτϥϯβΫγϣϯ͕ૹ৴͞ΕΔ ཰࿦తϑΝ Ͱ͖ ͳ͍ɽDAGڀݚ[6], [36] ͨ͠ϓϩτίϧͷ΄ͱΜͲ͸ɼͨͱ͑ ଄Խ͞Εͨ DAG཰࿦తϑΝΠφϦςΟ͔͠ ͞Ε͍ͯΔɽ HashGraph [ 37] ΍ Cordial ...

  27. [36]

    Pease, R, Shostak, and L

    M. Pease, R, Shostak, and L. Lamport, ”Reaching agreement in the presence of faults,” Journal of the ACM, vol.27, no.2, pp.228-234, April 1980

    1980

  28. [37]

    Lamport, R

    L. Lamport, R. Shostak, and M. Pease, ”The byzantine general’s prob- lem,” ACM Transactions on Programming Languages and Systems, vol.4, no.3, pp.382-401, July 1982

    1982

  29. [38]

    Castro, and B

    M. Castro, and B. Liskov, ”Practical byzantine fault tolerance,” Pro- ceedings of the Third Symposium on Operating Systems Design and Implementation, pp.173-186, February 1999

    1999

  30. [39]

    Nakamoto, ”Bitcoin: A Peer-to-Peer Electronic Cash System”, Bitcoin, https://bitcoin.org/bitcoin.pdf, October 2008

    S. Nakamoto, ”Bitcoin: A Peer-to-Peer Electronic Cash System”, Bitcoin, https://bitcoin.org/bitcoin.pdf, October 2008

    2008

  31. [40]

    Nakamoto, ”Bitcoin P2P e-cash paper”, metzdowd, https://www.me tzdowd.com/pipermail/cryptography/2008-November/014849.html, November 2008

    S. Nakamoto, ”Bitcoin P2P e-cash paper”, metzdowd, https://www.me tzdowd.com/pipermail/cryptography/2008-November/014849.html, November 2008

    2008

  32. [41]

    Gueta, I

    G.G. Gueta, I. Abraham, S. Grossman, D. Malkhi, B. Pinkas, M.K. Reiter, D.A. Seredinschi, O. Tamir, and A. Tomescu, ”SBFT: a scal- able decentralized trust infrastructure for blockchains,” arXiv preprint arXiv:1804.01626, Janurary 2019

    2019 arXiv

  33. [42]

    Stathakopoulou, T

    C. Stathakopoulou, T. David, and M. Vukoli ´c, ”Mir-BFT: high- throughput BFT for blockchains,” arXiv preprint arXiv:1906.05552, Janurary 2021

    1906 arXiv

  34. [43]

    Interchain Foundation, ”Cosmos Whitepaper”, GitHub, https://github .com/cosmos/cosmos/blob/master/WHITEPAPER.md, Janurary 2019

    2019

  35. [44]

    Buchman, J

    E. Buchman, J. Kwon, and Z. Milosevic, ”The last gossip on BFT consensus,” arXiv preprint arXiv:1807.04938, November 2019

    2019 arXiv

  36. [45]

    Bessani, J

    A. Bessani, J. Sousa, and E.E.P . Alchieri, ”State machine replication for the masses with BFT-SMART,” Proceedings of the 44th Annual IEEE/IFIP International Conference on Dependable Systems and Net- works, pp.355-362, June 2014

    2014

  37. [46]

    Kotla, L

    R. Kotla, L. Alvisi, M. Dahlin, A. Clement, and E. Wong, ”Zyzzyva: speculative byzantine fault tolerance,” ACM Transactions on Com- puter Systems, vol.27, no.7, pp.1-39, December 2009

    2009

  38. [47]

    Danezis, E.K

    G. Danezis, E.K. Kogias, A. Sonnino, and A. Spiegelman, ”Narwhal and Tusk: a DAG-based mempool and efficient BFT consensus,” arXiv preprint arXiv:2105.11827, March 2022

    2022 arXiv

  39. [48]

    Y . Yin, D. Malkhi, M.K. Reiter, G. Golan-Gueta, and I. Abraham, ”HotStuff: BFT consensus in the lens of blockchain,” arXiv preprint arXiv:1803.05069, March 2018

    2018 arXiv

  40. [49]

    Spiegelman, N

    A. Spiegelman, N. Giridharan, A. Sonnino, and L. Kokoris-Kogias, ”Bullshark: DAG BFT protocols made practical,” Proceedings of the 2022 ACM SIGSAC Conference on Computer and Communications Security, pp.2705-2718, November 2022

    2022

  41. [50]

    Ethereum Foundation, ”The Merge,” Ethereum, https://ethereum.org/e n/roadmap/merge/, July 2024

    2024

  42. [51]

    C.P . Bar ´o, ”How many transactions can the network handle?,” Ethereum Stack Exchange, https://ethereum.stackexchange.com/questi ons/49484/how-many-transactions-per-second-can-ethereum-currentl y-handle-what-changes-wil, May 2018

    2018

  43. [52]

    S. Bano, M. Baudet, A. Ching, A. Chursin, G. Danezis, F. Garillot, Z. Li, D. Malkhi, O. Naor, D. Perelman, and A. Sonnino, ”State machine replication in the li- bra blockchain”, Diem, https://developers.diem.com/papers/diem- consensus-state-machine-replication-in-the-diem-bloc...

    2019

  44. [53]

    Diem Association, ”State machine replication”, Diem, https://develope rs.diem.com/docs/technical-papers/state-machine-replication-paper/, December 2020

    2020

  45. [54]

    Gudgeon, P

    L. Gudgeon, P . Moreno-Sanchez, S. Roos, P . McCorry, and A. Ger- vais, ”SoK: Layer-two blockchain protocols,” Proceedings of Inter- national Conference on Financial Cryptography and Data Security, pp.201–226, July 2020

    2020

  46. [55]

    Vite Labs, ”Vite: a high performance asynchronous decentralized ap- plication platform,” GitHub, https://github.com/vitelabs/whitepaper/ blob/master/vite en.pdf, November 2024

    2024

  47. [56]

    Sui Foundation, ”Object Model,” Sui, https://docs.sui.io/concepts/obj ect-model, February 2025

    2025

  48. [57]

    Solana Foundation, ”Sealevel-parallel processing thousands of smart contracts,” Solana, https://solana.com/ja/news/sealevelparallel- processing-thousands-of-smart-contracts, September 2019

    2019

  49. [58]

    Gelashvili, A

    R. Gelashvili, A. Spiegelman, Z. Xiang, G. Danezis, Z. Li, D. Malkhi, Y . Xia, and R, Zhou, ”Block-STM: scaling blockchain execution by turning ordering curse to a performance blessing”, arXiv preprint arXiv:2203.06871, August 2022

    2022 arXiv

  50. [59]

    E. Buchman, ”Tendermint: byzantine fault tolerance in the age of blockchains,” University of Guelph, https://atrium.lib.uoguelph.ca/se rver/api/core/bitstreams/0816af2c-5fd4-4d99-86d6-ced4eef2fb52/co ntent, June 2016

    2016

  51. [60]

    Keidar, E

    I. Keidar, E. Kokoris-Kogias, O. Naor, and A. Spiegelman, ”All you need is dag,” arXiv preprint arXiv:2102.08325, June 2022

    2022 arXiv

  52. [61]

    M¨ uller, A

    S. M¨ uller, A. Penzkofer, N. Polyanskii, J. Theis, W. Sanders, and H. Moog, ”Tangle 2.0 leaderless nakamoto consensus on the heaviest dag,” IEEE Access, vol.10, pp.105807-105842, 2022

    2022

  53. [62]

    Q. Wang, J. Yu, S. Chen, and Y . Xiang, ”SoK: diving into DAG- based blockchain systems,” arXiv preprint arXiv:2012.06128, Octo- ber 2022

    2012 arXiv

  54. [63]

    Baird, ”The swirlds hashgraph consensus algorithm: fair, fast, byzantine fault tolerance,” Swirlds, Inc

    L. Baird, ”The swirlds hashgraph consensus algorithm: fair, fast, byzantine fault tolerance,” Swirlds, Inc. Technical Report SWIRLDS- TR-2016-01, https://www.swirlds.com/downloads/SWIRLDS-TR-20 16-01.pdf, May 2016

    2016

  55. [64]

    Keidar, O

    I. Keidar, O. Naor, O. Poupko, and E. Shapiro, ʠCordial Miners: fast and efficient consensus for every eventuality, ʡ arXiv preprint arXiv:2205.09174, September 2023

    2023 arXiv

  56. [65]

    Cachin, K

    C. Cachin, K. Kursawe, F. Petzold, and V . Shoup, ”Secure and effi- cient asynchronous broadcast protocols,” Advances in Cryptology ʕ CRYPTO 2001, LNCS 2139, pp. 524–541, August 2001. — 16 —

    2001

  57. [66]

    Correia, N.F

    M. Correia, N.F. Neves, and P . Ver´ıssimo, ”From consensus to atomic broadcast: time-free byzantine-resistant protocols without signa- tures,” in The Computer Journal, vol.49, no.1, pp.82-96, Janurary 2006

    2006

  58. [67]

    Fischer, N.A

    M.J. Fischer, N.A. Lynch, and M.S. Paterson, ”Impossibility of dis- tributed consensus with one faulty process,” Journal of the ACM, vol.32, no.2, pp.374-382, April 1985

    1985

  59. [68]

    Gagol, D

    A. Gagol, D. Le ´sniak, D. Straszak, and M. ´Swietek, ”Aleph: efficient atomic broadcast in asynchronous networks with byzantine Nodes,” arXiv preprint arXiv:1908.05156, August 2019

    1908 arXiv

  60. [69]

    Chandra and S

    T.D. Chandra and S. Toueg, ”Unreliable failure detectors for reliable distributed systems,” Journal of the ACM, vol.43, no.2, pp.225–267, March 1996

    1996

  61. [70]

    Larrea, A

    M. Larrea, A. Fernandez, and S. Arevalo, ”On the implementation of unreliable failure detectors in partially synchronous systems,” in IEEE Transactions on Computers, vol.53, no.7, pp.815-828, July 2004

    2004

  62. [71]

    Sui Foundation, ”Validator committee,” Sui, https://docs.sui.io/guides /operator/validator-committee, February 2025

    2025

  63. [72]

    Cachin, R

    C. Cachin, R. Guerraoui, and L. Rodrigues, Introduction to Reliable and Secure Distributed Programming, Springer-Verlag, Berlin, 2011

    2011

  64. [73]

    Sui Foundation, ”Epoch,” Sui, https://docs.sui.io/references/sui- api/sui-graphql/reference/types/objects/epoch, February 2025

    2025

  65. [74]

    X. Lu, C. Jiang, and Pan Wang, ”A survey on consensus algorithms of blockchain based on DAG”, 2024 6th Blockchain and Internet of Things Conference, October 2024

    2024

  66. [75]

    S. Bano, A. Sonnino, A. Chursin, D. Perelman, Z. Li, A. Ching, and D. Malkhi, ”T wins: BFT Systems Made Robust,” arXiv preprint arXiv::2004.10617, Janurary 2022

    2004 arXiv

  67. [76]

    Gilbert and N

    S. Gilbert and N. Lynch, ”Brewer’s conjecture and the feasibility of consistent, available, partition-tolerant web services,” ACM SIGACT News, vol.33, no.2, pp.51–59, June 2002

    2002

  68. [77]

    Mysten Labs, ”The sui smart contracts platform,” Sui, https://docs.sui.io/paper/sui.pdf, February 2025. — 17 —

    2025

Pith tools

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