Pith. sign in

REVIEW 4 major objections 8 minor 3 references

Sei Giga

T0 review · 4 major / 8 minor · reviewed 2026-08-07 · deepseek-v4-flash

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

Pith's one-line read Sei Giga claims that a blockchain can reach consensus over transaction ordering alone, then execute asynchronously, reaching over 5 gigagas per second with sub-250ms finality.

desk verdict A well-written system blueprint whose central performance claim is unsupported and whose data-availability layer has a real liveness gap. read the letter →

arxiv 2505.14914 v3 pith:OSKBTSVS submitted 2025-05-20 cs.DC cs.CR

Benjamin Marsh , Steven Landers , Jayendra Jog This is my paper · ORCID
classification cs.DCcs.CR
keywords blockchainconsensusEVMlayer1dataavailabilityProofofparalleltransactionexecutionasynchronousstatecommitmentAutobahn
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

This paper is a design proposal and internal-testnet report for Sei Giga, an EVM layer-1 blockchain whose central move is to take execution out of consensus. Instead of agreeing on the state a block produces, the validators agree only on the contents and ordering of a block, then execute it asynchronously after finality and attest to the resulting state in a later block. Because EVM execution is deterministic, every honest node that applies the same ordered transactions to the same starting state arrives at the same final state, so the authors argue ordering alone is enough to keep the chain safe. On an internal testnet they report over 5 gigagas per second of throughput and sub-250ms finality, with the speed coming from a multi-proposer consensus protocol, a rewritten EVM client, parallel execution, and a storage layer built around an accumulator instead of Merkle trees. If true, this separates the problem of agreeing on order from the problem of computing state, so each can be optimized independently.

What carries the argument

The load-bearing mechanism is Autobahn, a BFT consensus protocol whose data-dissemination layer is split into per-replica lanes; each lane proposes batches ('cars') and a batch is certified by an f+1 Proof-of-Availability, meaning at least one correct replica can serve the data. The consensus layer periodically commits a 'tip cut'—a compact snapshot collecting the latest certified tip of every lane—so many proposals are ordered in one pipelined 1.5-round consensus instance. Because a tip references its whole lane history, ordering a tip implicitly orders everything before it. This is what lets the chain finalize order without executing, and the paper's Claim 1 (deterministic execution) is what guarantees the asynchronously computed state will match.

What would settle it

Commit a batch whose availability certificate contains exactly the minimum number of voters, take the one honest voter offline before any other node downloads the batch, then have a fresh node attempt to retrieve it; if retrieval fails, the data-availability guarantee is violated. A second check is to measure finality when the designated leader fails and compare with the paper's own prediction of over 11 seconds degradation.

Watch

Extended reading notes

Core claim

The central claim is stated directly as Claim 1: for a fixed initial EVM state and an ordered list of transactions, all honest nodes that apply them in the same order arrive at an identical final state, assuming a majority-honest network. From this, the paper concludes that consensus needs to finalize only ordering, and Sei Giga is built around that conclusion: blocks are finalized on order first, execution happens asynchronously, and the state root is later agreed on in a future block once a two-thirds quorum attests it. The authors report 5+ gigagas per second and sub-250ms finality on an internal testnet, and identify the mechanism as Autobahn's multi-proposer lanes with Proof-of-Availability certificates and tip-cut ordering, combined with a from-scratch EVM client, optimistic parallel execution, and accumulator-based storage.

Load-bearing premise

The load-bearing premise is that among the minimal set of nodes that certify a batch as available, at least one honest node will stay online long enough for any other honest node to download the batch; the paper specifies no redundancy or liveness mechanism that guarantees this.

Editorial extensions

If this is right

  • Consensus latency and execution latency decouple: a transaction's order can be final while its state effects are still being computed, so finality is set by the 1.5-round pipelined tip cut rather than by EVM execution time.
  • Block production can jump from 2.5 blocks per unit time to 180, because a single cut commits many lane tips rather than one block per consensus round.
  • State divergence is handled outside the critical path: deviations affecting less than a third of the network do not halt the chain, while larger divergences pause it as in standard BFT, and state roots are attested by quorum signatures in later blocks.
  • Parallel execution with rollback and retry preserves the logical order, so the final state after optimistic concurrency is identical to sequential execution.
  • Storage verification shifts from per-write Merkle re-hashing to batched constant-time accumulator updates, which is what keeps disk I/O from becoming the next throughput ceiling.

Reading between the lines

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

  • The paper does not say this, but the f+1 Proof-of-Availability guarantee would be more robust with erasure coding or requiring votes from more than f+1 nodes, so a batch remains retrievable even if some of its certifiers go offline.
  • The paper does not say this, but the ordering-first, state-later split should transfer to any deterministic execution environment, not just the EVM, so the design pattern is broader than this chain.
  • The paper does not say this, but a public testnet with malicious validators and a failed tip-cut leader would directly test the predicted latency degradation (from 0.25s p50 to over 11s) and the claimed tolerance for offline lanes.
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

4 major / 8 minor

Summary. The manuscript describes Sei Giga, an EVM layer-1 blockchain claiming to use multi-proposer consensus (Autobahn) to finalize transaction ordering before execution, with asynchronous block execution and later state commitments. The abstract claims >5 gigagas/sec throughput and sub-250ms finality on an internal testnet, while the introduction says sub-400ms finality. The paper gives architecture sketches: lanes with f+1 Proof-of-Availability certificates, tip cuts, an evmone-based execution client, Block-STM-style parallel execution, flat LSM storage, and a pairing-based accumulator. No benchmark methodology, dataset, or code is provided; the only performance citation is a self-authored blog post.

Significance. If fully supported, the ordering-without-execution design and multi-proposer consensus could be an interesting systems contribution, since execution is usually in the critical path of finality. The paper names concrete components (evmone, Block-STM, HotStuff-style consensus) and states falsifiable performance targets. However, the central empirical claim is not backed by any released data, reproducible benchmarks, or independent evaluation, and the DA layer as specified contains a liveness hole that breaks the ordering-without-execution pipeline. The paper currently reads as a design/position statement rather than a verified systems result.

major comments (4)
  1. [Abstract; §1] The headline performance claim is unsupported and internally inconsistent. The abstract states '>5 gigagas/sec throughput and sub 250ms finality,' while §1 says '5 gigagas throughput ... and sub 400ms finality.' No experimental setup, workload, hardware, measurement methodology, or released code/data is included; the only citation for the number is the self-authored blog post [Mar25]. Since the paper's central contribution is these performance numbers, the manuscript cannot be evaluated as a systems paper without this evidence.
  2. [§3.2; §3.3] Section 3.2 states that the DA layer's sole job is to guarantee that every batch committed in a cut can later be downloaded by any honest node, but the f+1 Proof-of-Availability does not provide this guarantee. With n=3f+1, a PoA with f+1 votes can be collected from f Byzantine replicas and one correct replica; the paper itself reads this as 'at least one correct replica can serve the proposal data on request.' That correct replica may later crash, be partitioned, or go offline; §3.3 says a missing batch is fetched 'from a replica within the PoA set,' and in the scenario just described no responsive correct replica may remain in that set. No erasure coding, replication factor, or re-dissemination rule is specified to make committed batches recoverable from the f+1-set after the fact. Thus a finalized batch can become permanently unavailable to honest nodes, preventing async execution and the 2/3 state-commitment quorum of §2.1. This is a protocol-level liveness hole in the central ordering-without-execution claim, independent of benchmark issues.
  3. [§3.6] The unqualified finality claim is further undermined by the paper's own §3.6, which reports that with f Byzantine nodes and five two-second timeouts p50 latency degrades to over 11s, and that the single tip-cut leader is a single point of failure that stalls finality if the leader goes offline. The abstract presents sub-250ms finality as a property of the system, but no condition is attached; the paper ultimately acknowledges a failure mode where finality is orders of magnitude worse. Any future revision should state the exact conditions under which the finality number holds and provide empirical latency distributions, including Byzantine and crash cases.
  4. [§2; §2.1] The proof sketch of Claim 1 establishes EVM determinism, not consensus security. The step from deterministic execution to 'consensus can be reached over just the contents and ordering of a block without execution' requires that every finalized block's contents are retrievable and that every honest node can execute them; this is exactly what the DA layer must provide, and it is not established. Moreover, Claim 1's phrase 'assuming a majority honest network' is too weak for the n=3f+1 model used in §3.5, where safety and liveness require at least 2f+1 honest replicas.
minor comments (8)
  1. [Abstract; §1] The finality numbers in the abstract (sub-250ms) and introduction (sub-400ms) should be reconciled.
  2. [§3.2] There is a stray ']' after the Figure 5 caption, and several figure captions are missing or inconsistent.
  3. [§3.3] The text refers to 'Prop. 1' while the statement is labeled Claim 1 in §2; fix the cross-reference.
  4. [§3.4] The protocol is described both as two-phase and as having three phases (Prepare, Commit, Confirm); clarify the relationship between these phases and the claimed 1.5-round-trip latency.
  5. [§6] The block-reward formula r = Σ_{b∈e} b_r / |V| uses b both for a block and for a block reward; define each variable explicitly.
  6. [§5] The statement that the network processes 'petabytes of new data each year under a 5 gigagas load' is presented without any calculation or source; add a derivation or remove the estimate.
  7. [§1.1] The comparisons '50x higher throughput than Tendermint' and '200k TPS compared to the previous 5k TPS' are asserted without a definition of the workloads or measurement conditions; these should be supported if kept.
  8. [References] The performance claim rests on [Mar25], a blog post by one of the authors; if the claim remains, it should be supported by a proper technical report or benchmark artifact.

Circularity Check

1 steps flagged · score 6.0 of 10

Headline throughput/finality rests on the first author's own blog citation; architecture otherwise self-contained.

  1. self citation load bearing [Section 1 (Introduction) and reference [Mar25]]
    "Sei Giga uses Autobahn [Gir+25] as a consensus protocol to allow for 5 gigagas throughput [Mar25] and sub 400ms finality under standard BFT-style security assumptions."

    The paper's headline performance claim, >5 gigagas/sec and sub-250ms finality, is supported only by [Mar25], a blog post authored by Ben Marsh, the first author of this same paper, hosted on Sei's own blog. The paper includes no benchmark methodology, no reproducible data, and no independent audit, so the central empirical claim is imported from the authors' own prior write-up rather than derived or independently demonstrated. This makes the throughput/finality claim load-bearing on a self-citation.

full rationale

The derivation chain is mostly self-contained: Claim 1 gives a valid conditional argument for ordering-only consensus, the async state-commit mechanism is specified in terms of the protocol, and the Block-STM ordering is defined from read/write dependencies without smuggling in its conclusion. The f+1 PoA passage in §3.2 is a genuine liveness/correctness gap—a PoA certifies only that at least one correct replica held the data at vote time, not that the data remains retrievable later—but this is not circularity under the required standard, because no definition or equation makes 'later downloadable by any honest node' identical to 'has f+1 votes.' The one clear circularity is the headline performance number: the abstract and introduction assert >5 gigagas/sec and sub-250ms finality, and the only citation offered for that figure is [Mar25], a blog post by this paper's first author. Since the central empirical claim rests on a self-citation while the architectural contributions are presented independently, the paper is partially, rather than wholly, circular.

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

The central claims rest on four domain assumptions that are not established inside the paper: EVM determinism across client versions, f+1 PoA sufficiency for later data retrieval, Block-STM correctness under Sei Giga semantics, and soundness of the asynchronous accumulator integration. The only support for the headline throughput is the authors' own unpublished benchmark.

assumptions (5)
  • domain assumption EVM execution is deterministic across all honest nodes and client versions, so ordering-only consensus is sufficient.
    Claim 1 in Section 2 treats Exec(S,tx_i) as a pure function, but determinism depends on identical client bytecode, the same fork and version semantics, and identical block metadata. The paper offers no mechanism to enforce version uniformity, and Section 3.3 introduces a second reordering by tip that could alter the order.
  • domain assumption An f+1 proof of availability certifies that every committed proposal can later be downloaded by any honest node.
    Sections 3.2 and 3.3 guarantee data availability with an f+1 PoA, relying on at least one correct replica having and serving the data. There is no erasure coding, redundancy factor, or liveness proof ensuring that the serving replica remains available.
  • domain assumption Block-STM optimistic concurrency control preserves the sequential order and produces the same final state on all nodes.
    Section 4 assumes the dependency and validation rules from Block-STM [Gel+22] and prior analyses [And24] hold under Sei Giga's EVM semantics; no proof is given in this paper.
  • domain assumption The pairing-based dynamic accumulator from [VB20] remains sound when asynchronously updated in the described storage layer.
    Section 5.1 invokes [VB20] as an external primitive but does not specify the update protocol, aggregation rules, or how light clients obtain and verify batched proofs against state commitments.
  • domain assumption Partial synchrony, authenticated point-to-point channels, and n=3f+1 with up to f faulty replicas.
    Section 3.5 adopts the HotStuff-style BFT system model; the paper does not prove Autobahn's properties, citing [Gir+25] instead.

how reviews work

0 comments
Cite this review

Pith. "Pith review of Sei Giga." pith.science (2026). https://pith.science/paper/OSKBTSVS

@misc{pith2026250514914,
  author       = {Pith},
  title        = {Pith review of: Sei Giga},
  year         = {2026},
  howpublished = {\url{https://pith.science/paper/OSKBTSVS}},
  note         = {Machine review of arXiv:2505.14914}
}
read the original abstract

We introduce the Sei Giga, a multi-concurrent producer parallelized execution EVM layer one blockchain. In an internal testnet Giga has achieved >5 gigagas/sec throughput and sub 250ms finality. Giga uses Autobahn for consensus with separate DA and consensus layers requiring f+1 votes for a PoA on the DA layer before consensus. Giga reaches consensus over ordering and uses async block execution and state agreement to remove execution from the consensus bottleneck.

Figures

Figures reproduced from arXiv: 2505.14914 by the authors.

Figure 1
Figure 1. v2 vs Giga 1.1 Comparison to Sei v2 Autobahn achieves over 50× higher throughput than Tendermint by funda￾mentally rethinking how consensus and data availability are managed in a dis￾2 [PITH_FULL_IMAGE:figures/full_fig_p002_1.png] view at source ↗
Figure 2
Figure 2. Async block execution 2.1 State consensus Given the lack of need for execution to reach consensus Sei Giga is able to re￾move execution as a bottleneck and asynchronously execute finalized blocks in parallel to the block production process. Once a block has been finalized the executor node will execute the block and commit to the state of block n along with others as a batch in a later block n + x for some x ∈ Z, x … view at source ↗
Figure 3
Figure 3. Giga Client 2.3 Pipelining and encoding The execution process is fully pipelined with parsing, address recovery, and sig￾nature verification happening in parallel to avoid bottlenecks in the execution process by ensuring these otherwise potentially blocking processes. A flat encoding format is also utilized to ensure cheaper transaction decod￾ing. The transaction encoding is a flat, length-prefixed layout. Each fiel… view at source ↗
Figures from the paper (10 more)
Figure 4
Figure 4. Figure 4: Multi-producer 3.2 Data Dissemination Layer (Lanes) and PoA The DA layer’s sole job is to guarantee that every batch committed in a cut can later be downloaded by any honest node. We achieve this with an f+1 Proof-of-Availability certificate (PoA). Lane Structure and P…
Figure 5
Figure 5. Figure 5: Prepare This certifies that at least one correct replica can serve the proposal data on request. ] [PITH_FULL_IMAGE:figures/full_fig_p009_5.png]
Figure 6
Figure 6. Figure 6: Proposal Instant Referencing. Because proposals in lane ℓr are chained, referencing the tip (i.e., the most recent proposal with a PoA) implicitly attests that all previous proposals in that lane are available. This transitive guarantee reduces synchronization overhead…
Figure 7
Figure 7. Figure 7: DA and consensus stages with vote reqs 3.3 Data Availability and Final Execution Data Synchronization (DA) and Asynchronous Retrieval. Since each lane’s tip carries a PoA, any replica missing a batch can retrieve it asyn￾chronously from a replica within the PoA set. Wh…
Figure 8
Figure 8. Figure 8: Tip cut 3. Confirm: If the leader gathers only (n − f) votes, it enters a confirm phase and waits for additional acknowledgments until a commit certificate is achieved with 2f + 1 confirm messages. Pipelining Benefit. Through the use of quadratic communication and pipe…
Figure 9
Figure 9. Figure 9: Async block execution 4 Block-STM-Style Parallel Execution [PITH_FULL_IMAGE:figures/full_fig_p013_9.png]
Figure 10
Figure 10. Figure 10: STM Let { t1, t2, . . . , tn} be the transactions in a finalized block B, arranged in the total order determined by that block. Each transaction ti reads some set of addresses, storage slots, or global variables, collectively denoted by Ri , and writes a set of addres…
Figure 11
Figure 11. Figure 11: Sequential tx execution By allowing for parallel, rather than sequential transaction processing, as shown in figure 11 and figure 12 it is trivial to see how execution times can be reduced. 14 [PITH_FULL_IMAGE:figures/full_fig_p014_11.png]
Figure 12
Figure 12. Figure 12: Parallel tx execution 5 Storage Sei Giga adopts a storage strategy that departs from conventional Merkle-tree￾based designs in order to reduce overhead and improve parallelism under ex￾treme throughput. By default the state of Sei Giga is stored in RAM. Instead of mai…
Figure 13
Figure 13. Figure 13: Storage 6 Economics Sei Giga has a native coin called SEI with a total supply of 10 billion, 10 000 000 000. The Sei coin is used to pay for gas and other associated transaction and usage costs, as well as for staking and validator rewards. Each block receives a block…

Discussion (0). Continue with ORCID to comment.

Reference graph

Works this paper leans on

3 extracted references · 3 linked inside Pith

  1. [2019]

    [VB20] Giuseppe Vitto and Alex Biryukov.Dynamic Universal Accumulator with Batch Update over Bilinear Groups

    arXiv:1803.05069 [cs.DC].url:https://arxiv.org/abs/ 1803.05069. [VB20] Giuseppe Vitto and Alex Biryukov.Dynamic Universal Accumulator with Batch Update over Bilinear Groups. Cryptology ePrint Archive, Paper 2020/777. 2020.url:https://eprint.iacr.org/2020/777. [Gel+22] Rati Gelashvili et al.Block-STM

    arXiv 2020

  2. [2022]

    [And24] Vangelis Andrikopoulos.64.85 of Ethereum Transactions Can Be Parallelized

    eprint:2203.06871v3.url: https://arxiv.org/pdf/2203.06871. [And24] Vangelis Andrikopoulos.64.85 of Ethereum Transactions Can Be Parallelized. 2024.url:https://blog.sei.io/research-64-85- of-ethereum-transactions-can-be-parallelized/. [Eth25] Ethereum.evmone. 2025.url:https://github.com/ethereum/ evmone. [Gir+25] Neil Giridharan et al.Autobahn: Seamless hi...

    arXiv 2024

  3. [2025]

    arXiv:2401.10369 [cs.DC].url:https://arxiv.org/abs/2401. 10369. [Mar25] Ben Marsh.Sei Giga: Achieving 5 Gigagas with Autobahn Consen- sus. 2025.url:https://blog.sei.io/sei- giga- achieving- 5- gigagas-with-autobahn-consensus/. 18

    arXiv 2025

Pith tools

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