diff --git a/index.mdx b/index.mdx index d1fc152..6012de0 100644 --- a/index.mdx +++ b/index.mdx @@ -108,7 +108,7 @@ The first parallelized EVM blockchain delivering unmatched scalability and speed - Next-gen design enabling giga gas execution bandwidth. + Next-gen design enabling gigagas execution bandwidth. Sub-second finality and fast block production. diff --git a/learn/general-brand-kit.mdx b/learn/general-brand-kit.mdx index edca97a..67708a9 100644 --- a/learn/general-brand-kit.mdx +++ b/learn/general-brand-kit.mdx @@ -19,7 +19,7 @@ sidebarTitle: 'Brand Kit' Black and white carry the brand. Maroon and Gold are heritage accents — use them only for emphasis and legacy moments, never as the base palette. -Sei delivers breakthrough performance through the world's first multi-proposer EVM Layer 1, combining unmatched speed, security, and seamless execution. Every design decision communicates speed, trust, and uncompromising quality. +Sei delivers breakthrough performance and is rolling out the world's first multi-proposer EVM Layer 1, combining unmatched speed, security, and seamless execution. Every design decision communicates speed, trust, and uncompromising quality. --- diff --git a/learn/index.mdx b/learn/index.mdx index 5ca4e3e..b3ebcc2 100644 --- a/learn/index.mdx +++ b/learn/index.mdx @@ -128,26 +128,26 @@ The Sei Model Context Protocol (MCP) Server brings blockchain functionality dire -## Sei Giga: Next-Generation Architecture +## Sei Giga: the next-generation architecture -**Engineered for Maximum Throughput & Efficiency** +**The first Multi-concurrent proposer EVM Layer 1** -Sei Giga represents a leap forward in blockchain performance. It combines cutting-edge consensus with novel execution strategies to deliver sub-second finality and massive scalability. +Sei Giga is the next generation of the Sei protocol. It arrives as in-place upgrades to the live network. Every validator proposes concurrently, consensus finalizes only the transaction order, and execution runs asynchronously. On an internal devnet this architecture sustained more than 5 gigagas per second (200,000+ TPS) with ordering finality under 250 ms. - High-speed BFT consensus for sub-second finality. + Multi-concurrent proposer BFT: per-validator lanes, 1.5 round trips, sub-250 ms ordering finality. - Decouples execution to unblock consensus. + Consensus fixes ordering; execution and state attestation follow off the critical path. - - Optimistic concurrency for max throughput. + + Block-STM-style optimistic concurrency across all CPU cores. - Full technical specifications, developer guidance, and upgrade details. + Architecture, roadmap and status, technical specification, and developer guidance. ## Key Use Cases diff --git a/learn/sei-giga-developers.mdx b/learn/sei-giga-developers.mdx index 7f87844..7e187d9 100644 --- a/learn/sei-giga-developers.mdx +++ b/learn/sei-giga-developers.mdx @@ -1,26 +1,89 @@ --- -title: 'Sei Giga Developer Guide' +title: 'Building on Sei Giga: What Changes for Developers' sidebarTitle: 'Developer Guide' -description: 'Key patterns and techniques for building high-performance dApps on Sei Giga' -keywords: ['sei giga development', 'smart contracts', 'dapp development', 'solidity', 'parallel execution'] +description: 'What Sei Giga changes for smart contract and dApp developers: EVM parity with five exceptions, two finality signals, mempool-free submission, socialised priority fees, BUD state proofs, and contract patterns that maximize parallel execution.' +keywords: ['sei giga development', 'giga developer guide', 'ordering finality', 'parallel execution patterns', 'no mempool', 'priority fee', 'eth_getproof', 'solidity', 'evm compatibility'] --- -This is a sneak peek at the patterns and optimizations developers should consider when building on Sei Giga. For current EVM development tutorials, check out the [EVM development guides](/evm/evm-general). -## Why Build on Sei Giga? +import { GigaFinalitySignals, GigaParallelismContrast, GigaFeeSplit } from '/snippets/giga-diagrams.jsx'; -- **Familiar Tools:** Full EVM compatibility—use existing Ethereum tooling -- **Parallel Execution:** Transactions touching different state run simultaneously -- **Lower Costs:** Efficient architecture means cheaper transactions -- **Native Precompiles:** Access to staking, and more from Solidity +Your contracts do not need to change for Sei Giga. The EVM is equivalent to Ethereum mainnet except for five things (EIP-4844 blobs, `PREVRANDAO`, the state root, the block gas limit, and the transaction fee mechanism), and standard Solidity and Vyper tooling keeps working: Foundry, Hardhat, viem, ethers. What changes is the environment around your contracts. Finality comes in two signals, there is no mempool, a priority fee buys a position in the order rather than a proposer's favor, and state proofs work differently. This page covers each change, plus the patterns that get the most out of Giga's parallel execution. -## Key Development Patterns + + Sei Giga rolls out as [phased upgrades to the live network](/learn/sei-giga#how-does-sei-giga-ship); as of July 2026 there is no public Giga testnet yet. Everything on this page describes the Giga architecture from the [whitepaper v2.0](https://arxiv.org/abs/2505.14914) and the shipping [sei-chain](https://github.com/sei-protocol/sei-chain) implementation. For building on Sei today, start with the [EVM development guides](/evm/evm-general). + + +## What stays the same + +- Contract code: Solidity and Vyper compile and behave identically. Opcodes and standard precompiles match Ethereum, and Sei tracks future EVM upgrades to stay near parity. +- Tooling: standard JSON-RPC (`eth_call`, `eth_sendRawTransaction`, `eth_getTransactionReceipt`, `eth_feeHistory`, `eth_subscribe` for new heads), so Foundry, Hardhat, viem, ethers.js, and wagmi work unchanged. +- Accounts and signing: the same `0x` addresses and the same ECDSA flow, with a [post-quantum migration path](/learn/sei-giga-specs#post-quantum-migration) specified for the long term. +- The gas token: SEI stays the native token for gas, staking, and fees. +- The network itself: Giga upgrades the live Sei network in place. There is no regenesis and no new chain to redeploy to. + +## What changes for your application + +| Area | On Ethereum / Sei today | On Sei Giga | What you should do | +| ------------------- | -------------------------------------------------------- | ------------------------------------------------------------------------------------------------ | ------------------------------------------------------------------------------ | +| Finality | One signal (block inclusion / finalized tag) | Two signals: ordering finality (measured <250 ms) and state attestation finality (a few blocks later) | Pick the signal per flow; see [below](#finality-on-giga-which-signal-to-wait-for) | +| Mempool | Public pending pool, gossip, frontrunning games | No mempool; transactions go straight into a validator's lane | Drop pending-pool assumptions; there is no pending stream to watch | +| Priority fee | Paid to the block proposer; buys inclusion favor | Strictly enforced for ordering, then socialised across validators by stake × liveness | Use the tip to express urgency; courting specific proposers buys nothing | +| State proofs | `eth_getProof` against the block state root | No state root; [BUD proofs](/learn/sei-giga-specs#block-update-digests-buds) against attested per-block digests | Don't hard-depend on `eth_getProof`; plan for BUD-based verification | +| Randomness | `PREVRANDAO` (beacon randomness) | `PREVRANDAO` not supported with Ethereum semantics | Use a VRF or oracle for randomness | +| Blob transactions | EIP-4844 type-3 transactions | Not supported (Giga is an L1, not a rollup DA consumer) | Nothing to do unless you post blobs | +| Block gas limit | Fixed per-block constant | No Ethereum-style fixed block gas limit; throughput bounded by lane and consensus parameters | Don't encode assumptions about a specific block gas limit | +| Duplicate submission | Re-broadcasting the same tx is free but useless | Multi-submitting to several validators is a censorship-resistance feature: one copy executes, duplicates pay a distribution fee with a partial tip refund | Optionally multi-submit high-value transactions | + +## Finality on Giga: which signal to wait for + +Giga separates consensus from execution, which gives you two distinct confirmation signals: + +- Ordering finality (measured under 250 ms on the internal devnet): consensus has irrevocably fixed your transaction's position. Execution is deterministic, so the outcome is decided at this moment; every honest node computes the same result. Ordered transactions do not reorg. +- State attestation finality, a bounded number of blocks later: a 2/3 validator quorum has signed the block's [divergence digest](/learn/sei-giga-specs#lattice-hash-divergence-digests). This confirms the executed results, not just the order. + + + +Which signal to wait for depends on the flow: + +| Use case | Wait for | Why | +| --------------------------------------------------- | --------------------------- | ------------------------------------------------------------------------ | +| Trading UX, games, payments UI, most dApp flows | Ordering finality (receipt) | Deterministic outcome; the devnet measured it in under 250 ms | +| Exchange deposits, bridge withdrawals, high-value settlement | State attestation finality | Adds a signed quorum attestation of executed state before you act on it | +| External verification (light clients, cross-chain) | Attested BUD proofs | Proofs anchor to attested digests, which follow the attestation schedule | + +A transaction that reverts stays reverted; a revert is a valid, final outcome and does not invalidate the block. For today's finality behavior, before Giga, see [EVM finality on Sei](/evm/evm-parity/finality). + +## Sending transactions without a mempool + +On Giga there is no shared pending pool. The RPC node forwards your transaction to a validator, which places it directly into its proposal lane; consensus then commits the cut containing it in 1.5 network round trips. In practice: + +- There is no public mempool to scan for victims, and the merged execution order is a [deterministic function](/learn/sei-giga-specs#deterministic-merge-rule) of finalized lane contents, so post-consensus reordering games do not exist. +- Pending semantics change. Don't build features on watching a gossiped pending-transaction stream. Pending-nonce queries are answered by the validator responsible for your sender address; the RPC layer routes this for you. +- You control your own censorship resistance. Submit the identical signed transaction to multiple validators if it matters; only one copy executes, since duplicates are dropped by hash at merge time, and extra copies pay a distribution fee and get part of the tip back. A single submission is the right default for most transactions. +- Each validator includes at most one copy of a given transaction per epoch, so duplicate floods cannot amplify. + +## Fees on Giga + +Giga prices three things separately (full details in the [fee model spec](/learn/sei-giga-specs#fee-model)): -### Pattern 1: User-Isolated State +1. The execution fee: an EIP-1559-style dynamic base fee for gas actually consumed. `eth_feeHistory` and `eth_maxPriorityFeePerGas` remain your estimation tools. +2. The ordering fee, better known as the priority fee. Giga enforces it strictly: lanes in each committed cut are ordered by their highest included tip, so a higher tip buys earlier execution, deterministically. The fee is also socialised (pooled per epoch and distributed to validators by stake and liveness), so tipping a specific proposer for special treatment achieves nothing. +3. The distribution fee, charged per duplicate copy when you multi-submit for censorship resistance. -Sei Giga's parallel execution engine rewards contracts with isolated state. When users' operations don't touch shared state, they execute simultaneously. + + +For gas metering inside the EVM, Sei's existing schedule applies, including Sei's custom `SSTORE` pricing (see [gas and fees](/evm/evm-parity/gas-and-fees)). The whitepaper defers the final Giga fee mechanism to a dedicated paper, so expect parameter-level details to firm up around the Autobahn testnet. + +## Writing parallel-friendly contracts + +Giga executes each block with [Block-STM-style optimistic concurrency](/learn/sei-giga-specs#parallel-execution-block-stm-style-occ): transactions run in parallel and re-execute only when their read/write sets collide. Sei Labs measured that [64.85% of historical Ethereum transactions parallelize](https://blog.sei.io/research-64-85-of-ethereum-transactions-can-be-parallelized/) as-is. Your contract's storage layout decides which side of that statistic it lands on. Transactions touching disjoint storage run simultaneously; transactions contending on one hot slot serialize (the engine retries conflicted transactions and, under sustained contention, falls back to sequential execution, so correctness is never at risk, only speed). + + + +### Pattern 1: isolate state per user ```solidity -// GOOD: Each user has isolated state - transfers can run in parallel +// GOOD: per-user state; transfers between different users run in parallel contract OptimizedToken { mapping(address => uint256) private balances; @@ -31,91 +94,72 @@ contract OptimizedToken { } } -// BAD: Global counter forces sequential execution +// BAD: every transfer writes one global slot, so transfers serialize contract PoorToken { - uint256 public totalTransfers; // Every transfer conflicts! + uint256 public totalTransfers; // every transfer conflicts here function transfer(address to, uint256 amount) public { - totalTransfers++; // Blocks parallelism + totalTransfers++; // hot slot: blocks parallelism for the whole block // ... transfer logic } } ``` -### Pattern 2: Struct Packing - -Pack struct variables to minimize storage slots and reduce gas costs. - -```solidity -contract OptimizedStorage { - // GOOD: Uses 1 storage slot (256 bits total) - struct User { - uint128 balance; // 128 bits - uint64 lastUpdate; // 64 bits - uint64 nonce; // 64 bits - } +Global counters, monolithic `totalSupply` updates on every operation, shared round-robin pointers, and single-slot reward accumulators are the classic hot spots. If you need an aggregate, update it lazily, shard it (per-address buckets aggregated on read), or derive it off-chain from events. - // BAD: Uses 3 storage slots - struct InefficientUser { - uint256 balance; // 256 bits = 1 slot - uint64 lastUpdate; // 64 bits = 1 slot (wastes 192 bits) - uint64 nonce; // 64 bits = 1 slot (wastes 192 bits) - } -} -``` +### Pattern 2: prefer mappings over shared arrays -### Pattern 3: Event-Driven Architecture +`mapping(address => T)` lookups touch one isolated slot per user. Pushing to a shared array touches the array-length slot on every insert, which makes the length slot a hidden global counter. -Store historical data in events instead of storage to reduce costs. +### Pattern 3: emit events instead of storing history ```solidity contract EventDrivenAuction { mapping(uint256 => uint128) public highestBids; - // Bid history stored in events, not storage + // Bid history lives in events, not storage event BidPlaced(uint256 indexed auctionId, address indexed bidder, uint256 amount); function bid(uint256 auctionId) external payable { require(msg.value > highestBids[auctionId], "Bid too low"); highestBids[auctionId] = uint128(msg.value); - emit BidPlaced(auctionId, msg.sender, msg.value); // Cheap! + emit BidPlaced(auctionId, msg.sender, msg.value); } } ``` -## Gas Optimization Tips +Events are a particularly good deal on Giga: receipt generation and log indexing run off the execution hot path in dedicated stores, so keeping history in events trims your write set without losing queryability. - -**Quick Wins:** -- Use `memory` for temporary data, `calldata` for read-only parameters -- Cache array lengths in loops: `uint256 len = arr.length;` -- Use `unchecked { i++; }` in loops where overflow is impossible -- Batch operations to amortize base transaction costs - +### Pattern 4: pack storage you must share -## Native Precompiles +When state is genuinely shared, make it cheap: pack related fields into one slot so a conflicting transaction pays one slot conflict instead of three. -Sei Giga will also provide precompiles for direct access to chain features from Solidity. - -See the [Precompiles documentation](/evm/precompiles) for full details. +```solidity +struct Position { + uint128 size; // 128 bits ┐ + uint64 entryTime; // 64 bits ├─ one storage slot + uint64 nonce; // 64 bits ┘ +} +``` -## Development Checklists +## Sei precompiles under the Giga executor -### Parallel Execution Checklist +The Giga execution engine currently fast-paths pure-EVM transactions. Calls into Sei's custom precompiles (staking, governance, distribution, oracle, bank, and the other [Sei-native precompiles](/evm/precompiles/example-usage)) execute correctly but are routed through the legacy engine as of the sei-chain v6.6 release line: they work, but they sit off the parallel fast path. If you're optimizing a hot path for Giga-scale throughput, keep custom-precompile calls out of it where you can. -- Isolate state by user/entity -- Avoid global counters and shared state -- Use mappings over arrays for lookups +## Prepare your app for Giga today -### Gas Optimization Checklist +- Build EVM-only. [SIP-3](/learn/sip-03-migration) consolidates Sei to a streamlined EVM-only stack ahead of Giga: CosmWasm no longer accepts new deployments, inbound IBC is disabled, and oracles come from standard providers such as Chainlink, API3, and Pyth instead of the native module. +- Audit for hot slots. Per-user state isolation is the single most effective change for parallel throughput, and it pays off now: the Giga executor with OCC ships enabled by default from the sei-chain v6.6 release line. +- Classify your confirmation flows. Decide which flows act on ordering finality and which wait for state attestation, so the two-signal model lands as a config change rather than a redesign. +- Remove fragile dependencies. Anything that relies on `eth_getProof` and state roots ([current behavior](/evm/evm-parity/state-proofs)), `PREVRANDAO` randomness, blob transactions, or watching the public mempool needs a plan. +- Don't wait for a "Giga chain." There isn't one; Giga arrives on the network where you're already deployed, and contracts shipped on Sei today carry over untouched. -- Pack structs to minimize storage slots -- Use events for historical data -- Cache array lengths in loops -- Batch operations when possible +## Related -## Next Steps +- [Sei Giga overview](/learn/sei-giga): architecture and roadmap +- [Sei Giga technical specification](/learn/sei-giga-specs): the full protocol spec and glossary +- [EVM development guides](/evm/evm-general): building on Sei today +- [Differences with Ethereum](/evm/differences-with-ethereum): current-network EVM deltas +- [SIP-3 migration guide](/learn/sip-03-migration): the EVM-only consolidation -1. **Full Tutorials** - Start with the [EVM development guides](/evm/evm-general) -2. **Architecture Details** - Review the [Sei Giga Overview](/learn/sei-giga) -3. **Precompiles** - Explore [native precompiles](/evm/precompiles) for advanced features +_Last updated July 2026, based on the Giga whitepaper v2.0 (June 29, 2026) and the sei-chain v6.6 release line._ diff --git a/learn/sei-giga-specs.mdx b/learn/sei-giga-specs.mdx index 65b9c13..2027afa 100644 --- a/learn/sei-giga-specs.mdx +++ b/learn/sei-giga-specs.mdx @@ -1,194 +1,294 @@ --- -title: 'Sei Giga Technical Specifications' +title: 'Sei Giga Technical Specification' sidebarTitle: 'Technical Specs' -description: 'Comprehensive technical specifications for Sei Giga architecture, consensus protocols, and performance characteristics' -keywords: ['sei giga specs', 'technical specifications', 'autobahn consensus', 'blockchain architecture', 'performance specs'] +description: 'The complete Sei Giga protocol specification: Autobahn consensus with per-validator lanes and f+1 Proofs of Availability, asynchronous execution with divergence-digest attestation, Block-STM parallel EVM, flat lattice-hashed storage, BUD state proofs, MEV-resistant fee design, and the security model.' +keywords: ['sei giga specification', 'autobahn consensus', 'proof of availability', 'ordering finality', 'divergence digest', 'lattice hash', 'block update digest', 'block-stm', 'socialised tips', 'Multi-concurrent proposer bft'] --- -## Introduction - -This document provides comprehensive technical specifications for Sei Giga, covering both current features and upcoming architectural enhancements. - -The specifications are organized to clearly distinguish between what is currently deployed and what is planned for future releases. - - - - Features and specifications that are live on the Sei network today. - - - Planned features and specifications in development. - - - -## Consensus Architecture - -### Current: Twin Turbo Consensus - - - - - | Property | Value | - | --- | --- | - | Base Protocol | Enhanced Tendermint BFT | - | Marketing Name | Twin Turbo Consensus | - | Target Block Time | ~400ms | - | Finality | Instant (1 block) | - | Safety Threshold | ⅔ + 1 validators | - - - - Pipelined block processing - - Optimistic execution - - Aggressive timeouts - - Parallel validation - - - - -### Upcoming: Autobahn Consensus - - - - - | Property | Value | - | --- | --- | - | Architecture | Multi-proposer BFT | - | Target Block Time | Sub-second | - | Proposer Model | Parallel lanes | - | Safety Model | Byzantine Fault Tolerant | - - - - Asynchronous execution - - Data availability lanes - - Consensus/execution separation - - Optimized data dissemination - - - - -## Execution Engine - -### Current: Parallel EVM Execution - - - - - Full Ethereum Virtual Machine compatibility with standard opcodes and gas metering. - - - Optimistic Concurrency Control with multi-worker transaction processing and conflict resolution. - - - Optimized state access patterns with SeiDB storage backend. - - - - **Execution Specifications** - - | Property | Value | - | --- | --- | - | VM Type | Ethereum Virtual Machine | - | Gas Model | Ethereum-compatible | - | Execution Model | Parallel with OCC | - | Supported Languages | Solidity, Vyper, YUL | - | Precompiles | Standard + Sei Native | - | State Model | Account-based | - - -## Storage Architecture - -### Current: SeiDB - - - - - | Property | Value | - | --- | --- | - | Storage Type | Key-Value Store | - | State Storage | MemIAVL (Cosmos) + FlatKV/LtHash (EVM) | - | Caching | Multi-level | - | Concurrency | Thread-safe | - - - - Hot state caching - - Efficient pruning - - Parallel state access - - Optimized serialization - - - - -## Network Specifications - -### Protocol Parameters - -**Network Configuration** - - - - | Property | Value | - | --- | --- | - | Max Validators | 100 | - | Voting Power | Stake-weighted | - | Unbonding Period | 21 days | - | Slashing | Byzantine behavior | - - - | Property | Value | - | --- | --- | - | Max Block Size | 21 MB | - | Max Gas Limit | 12.5 M | - | Base Fee | Dynamic, on-chain param; no burn (validators receive fees) | - | Priority Fee | Supported | - - - -## Performance Targets - -**Engineering Targets**: The following performance specifications represent engineering targets for the upcoming Sei Giga architecture with Autobahn consensus, not current network performance. - -### Upcoming: Target Performance Specifications - - - - - Peak throughput target - - - Transaction confirmation - - - Simple transfers - - - - -## Developer Interface - -### JSON-RPC Compatibility - -**Ethereum JSON-RPC Support** - - - - - `eth_sendRawTransaction` - - `eth_call` - - `eth_getBalance` - - `eth_getTransactionReceipt` - - - - `debug_traceTransaction` - - `eth_feeHistory` - - `eth_maxPriorityFeePerGas` - - - -## Related Resources - - - - High-level introduction to Sei Giga architecture and features. - - - Complete guide for building applications on Sei Giga. - - +import { GigaLanesAndCuts, GigaSlotPipeline, GigaAttestationFlow, GigaOccDiagram, GigaStorageArchitecture, GigaBudWindow, GigaMergeRule } from '/snippets/giga-diagrams.jsx'; + +This page specifies the Sei Giga protocol as defined in the [Giga whitepaper v2.0](https://arxiv.org/abs/2505.14914) (Marsh, Landers, Jog, Ranchal-Pedrosa; June 2026), with implementation notes from the [sei-chain](https://github.com/sei-protocol/sei-chain) codebase as of the v6.6 release line (July 2026). For a conceptual introduction, start with the [Sei Giga overview](/learn/sei-giga); for practical guidance, see the [developer guide](/learn/sei-giga-developers). + +## Protocol at a glance + +| Property | Specification | +| ------------------------- | -------------------------------------------------------------------------------------------------- | +| Chain type | Permissionless Proof-of-Stake EVM Layer 1; SEI is the native gas, fee, and staking asset | +| Fault model | Byzantine, `n = 3f + 1` validators, up to `f` faulty | +| Synchrony assumption | Partial synchrony: safety unconditional, liveness after network stabilization | +| Consensus | Autobahn: per-validator data lanes with leader-driven cut-of-tips ordering | +| Data availability quorum | `f + 1` votes (Proof of Availability) | +| Ordering quorum | `n - f` prepare/commit votes (stake-weighted in the implementation) | +| Consensus latency | 1.5 network round trips (pipelined slow path; Tendermint requires 3 rounds) | +| Execution | Asynchronous, post-ordering; deterministic; Block-STM-style optimistic concurrency control | +| State attestation | 2/3-quorum signatures over per-block lattice-hash divergence digests, included in a later block | +| State commitment | Homomorphic multiset hash (LtHash) over the block write log, with no Merkle state root on the hot path | +| State proofs | Block Update Digests (BUDs) + SuperBUDs, governance-configurable proof window | +| Mempool | None; direct lane inclusion, at most one copy of a transaction per validator per epoch | +| Transaction encoding | Flat, length-prefixed, single-pass zero-copy decoding (not RLP) | +| EVM compatibility | Ethereum-equivalent except EIP-4844, `PREVRANDAO`, state root, block gas limit, fee mechanism | +| Fee model | Three-part: EIP-1559-style execution fee + ordering fee (priority) + distribution fee (duplicates) | +| Measured performance | >5 gigagas/s, sub-250 ms ordering finality (internal devnet: 40 nodes, 20 regions, June 2026) | + +## Network and security model + +Giga assumes `n = 3f + 1` validator replicas, of which at most `f` are Byzantine, communicating over authenticated point-to-point channels with unforgeable cryptographic primitives. The protocol targets the partial synchrony model: safety is unconditional, and liveness requires only that the network eventually stabilizes so message delays respect known upper bounds. + +- Safety: no two conflicting proposals can both obtain a valid commit certificate in the same consensus slot. Attesting to two different divergence digests for the same finalized block is slashable equivocation, because quorum intersection guarantees at least one honest validator would have to sign both. +- Censorship resistance: once a proposal holds `f + 1` availability votes, at least one honest replica stores its data, and a correct leader must include it in a future cut. Faulty proposers cannot disseminate data without it eventually being ordered, which bounds censorship to a finite delay. Users can also submit a transaction to multiple validators at once ([deduplicated at merge](#mev-and-fee-design), with a partial tip refund). +- Execution divergence: if fewer than 1/3 of validators compute a divergent state (hardware fault, software bug), the chain continues while the fault is localized. Divergence beyond the Byzantine threshold pauses the chain, as in any BFT system. +- Staking: validators bond SEI and can be slashed for malicious behavior. The complete slashing schedule, reward functions, and tokenomics for Giga are deferred to future work; today's staking parameters are documented in [Staking](/learn/general-staking). + +## Consensus: Autobahn + +Sei Giga orders transactions with [Autobahn](https://arxiv.org/abs/2401.10369) (Giridharan, Suri-Payer, Abraham, Alvisi, Crooks; 2024), a BFT protocol that decouples data dissemination from ordering. It occupies a deliberate middle ground between view-based protocols (HotStuff, Tendermint), which stall during network "blips," and DAG-based protocols (Narwhal-style), which pay extra latency in the good case. Autobahn pairs an asynchronous data layer with a partially synchronous, low-latency ordering layer; it recovers cleanly after periods of asynchrony and matches DAG-class throughput at roughly half the latency. + +### Data dissemination: lanes and Proofs of Availability + +- Every validator `r` maintains its own lane: an append-only, hash-chained sequence of transaction batches (called cars). A proposal is the tuple `Prop = ⟨pos, batch, parentRef⟩` signed by `r`, where `pos` is the lane sequence number and `parentRef` is the hash of the previous proposal in the same lane. +- Validators that receive a proposal verify it extends the lane correctly and return a signed vote over its digest. Once the proposer collects `f + 1` matching votes, it assembles a Proof of Availability (PoA), a certificate that the data is retrievable. +- `f + 1` is sufficient because any such quorum contains at least one correct replica that held the full data when it voted, and that replica serves it until all correct replicas have it. Giga deliberately keeps the smaller quorum (rather than `2f + 1`) because commitment itself triggers full replication along the execution path; a larger quorum would only add certification latency. +- The latest proposal in a lane holding a PoA is the lane's tip. Lanes are hash-chained, so certifying a tip implicitly attests the availability of every earlier proposal in that lane, and consensus never re-certifies history. + + + +All validators disseminate batches in parallel, continuously, without waiting for consensus. Dissemination is therefore never the bottleneck, and total bandwidth scales with the validator count rather than one leader's uplink. + +### Ordering: cuts of tips + +Consensus periodically fixes a global order by committing a cut, a vector of every lane's current certified tip: + +1. Prepare. The slot's leader (chosen by stake-weighted selection, as in Tendermint) bundles the latest certified tips into a cut proposal; replicas validate the PoAs and broadcast prepare votes, forming a PrepareQC at `n - f` votes. +2. Commit. Replicas exchange commit votes over the PrepareQC; a CommitQC finalizes the cut. If the leader gathers only the minimum `n - f` commit votes, it runs an additional confirm phase, collecting `2f + 1` confirmations before the commit certificate is final. +3. Pipelining. Slots overlap: as soon as replicas see the Prepare message for slot `s`, they can begin slot `s + 1`, and the next leader may start proposing while the previous cut is still in its commit phase. With quadratic communication and pipelining, the effective cost is a 1.5 round-trip slow path, versus 2.5 without pipelining and 3 full rounds in Tendermint. + + + +Committing one cut finalizes every uncommitted proposal in every lane up to the referenced tips. A single consensus decision can therefore commit many blocks' worth of data at once, which is why the whitepaper reports roughly 70 times higher block production than the single-proposer design (180 versus 2.5 blocks per second). Validators vote on compact certificates only; a replica that is missing batch data fetches it after commit, off the critical path. + +### Leader failure and recovery + +If a leader fails to make progress, replicas fall back to a standard view change: a timeout certificate elects a new leader, and the protocol resumes. Data dissemination continues in every lane throughout, so a view change costs some ordering latency but no throughput. The Autobahn paper calls this "seamless" recovery from blips; chained-HotStuff-style protocols instead pay a hangover after asynchrony. + +Two consensus upgrades beyond launch are already specified: + +- Ambulance ([arXiv 2606.25099](https://arxiv.org/abs/2606.25099)) replaces the timeout race with a "protocol-rigged race": non-leader replicas do useful persistence work on candidate cuts built from the same certified tips in parallel, so when a leader is merely slow (I/O contention, garbage collection, routing trouble) the slot can finish from existing recovery state instead of paying a full timeout. Planned as a core part of a future upgrade. +- Hermes, a next-generation consensus protocol on the [official roadmap](https://giga.seilabs.io); its whitepaper has not been published yet. + +## Execution + +### Two finality notions + +Giga separates what consensus decides from what execution produces: + +| Finality | Definition | When it holds | +| --------------------------- | -------------------------------------------------------------------------------------------------------- | ------------------------------------ | +| Ordering finality | Consensus has finalized the unique total order of transactions induced by a committed cut | Sub-250 ms after submission (measured) | +| State attestation finality | A later finalized block includes a valid 2/3-quorum attestation of the block's divergence digest | A bounded number of blocks later (lag `x` depends on execution timing) | + +Unless stated otherwise, latency claims in Giga materials refer to ordering finality. Ordering finality is already irreversible (the transaction sequence can never change); state attestation finality adds a BFT-signed confirmation of the results of execution. + + + +### Deterministic block transition + +For each finalized block, every executor computes the canonical transition `Apply(S_prev, context, block) → (S_new, receipts, gas, writeLog)`. Given the same pre-state, block context, ordered transactions, identical execution semantics, and serializable parallel execution, this transition is unique, so all honest executors derive byte-identical results without communicating. A transaction that reverts stays reverted; it does not invalidate the rest of the block. This determinism is what makes it safe to run execution entirely off the consensus critical path. + +The execution client is deliberately narrow: it processes transactions and nothing else, with no tracing or log search on the hot path. Incoming blocks are pre-processed in parallel (parsing, sender recovery, signature verification), while exactly one block executes at a time. Receipt generation and indexing happen after execution, so block `n + 1` can start while block `n` post-processes. + +### Parallel execution: Block-STM-style OCC + +Within a block, transactions execute concurrently under optimistic concurrency control (the [Block-STM](https://arxiv.org/abs/2203.06871) approach): + +- A later transaction `t_j` depends on an earlier `t_i` when `t_i`'s write set overlaps `t_j`'s read or write set. The block's total order keeps this dependency relation acyclic. +- All transactions start executing in parallel, each buffering its writes privately. A validation phase checks, for each transaction, whether any earlier-ordered transaction committed a write into its read or write set after it began; conflicting transactions are rolled back and re-executed. +- The committed result is provably identical to sequential execution in block order (a "valid parallel schedule"). When contention is low, most transactions commit on their first attempt; under sustained contention the engine may fall back to sequential execution with unchanged semantics. In `sei-chain`, the scheduler retries a transaction up to 10 times before reverting to the sequential path. + + + +Sei Labs measured that [64.85% of historical Ethereum transactions can be parallelized](https://blog.sei.io/research-64-85-of-ethereum-transactions-can-be-parallelized/) under this model. Contract-design guidance for maximizing parallelism is in the [developer guide](/learn/sei-giga-developers#writing-parallel-friendly-contracts). + +### Transaction encoding + +Giga replaces nested RLP with a flat, length-prefixed encoding designed for single-pass, zero-copy decoding: fields (type, chain ID, sender, recipient, value, nonce, gas limit, signature, access list) appear in a fixed order, variable-length fields carry a one-byte length prefix, contract creation is signaled by a marker byte, and all remaining bytes are the calldata. A parser reads each transaction in one pass with no allocation-heavy tree construction, which matters when decoding hundreds of thousands of transactions per second. + +## EVM compatibility + +Sei Giga's EVM is mostly equivalent to mainnet Ethereum. Contracts are written in standard Solidity or Vyper and deployed with standard tooling. + +| Exception | What differs on Giga | +| ---------------------------- | -------------------------------------------------------------------------------------------------------------- | +| EIP-4844 (blob transactions) | Not supported; Giga is an L1 and does not carry rollup blob data | +| `PREVRANDAO` | Not supported with Ethereum semantics (no beacon-chain randomness) | +| State root | Blocks carry no Merkle state root; state is attested via [divergence digests](#lattice-hash-divergence-digests) and proven via [BUDs](#block-update-digests-buds) | +| Block gas limit | Not a fixed Ethereum-style per-block constant; throughput is bounded by lane and consensus parameters | +| Transaction fee mechanism | Three-part model (below) instead of Ethereum's exact EIP-1559 burn semantics | + +### Fee model + +| Component | What it prices | Mechanism | +| -------------------- | ---------------------------------------------------- | ------------------------------------------------------------------ | +| Execution fee | Gas consumed by execution | EIP-1559-style dynamic base fee driven by demand | +| Ordering fee | Position in the merged order | Priority fee, strictly enforced by the [deterministic merge rule](#mev-and-fee-design) | +| Distribution fee | Duplicate copies submitted for censorship resistance | Prices each additional lane slot a duplicate occupies; only one copy ever executes, with a partial tip refund | + + +## Storage + +Giga's storage layer is designed for petabyte-per-year data production at full 5-gigagas load while keeping validator hardware practical. + +### Flat state, RAM-first + +- Every account, storage slot, and global variable maps directly to an entry in a log-structured merge (LSM) tree. Writes skip per-write Merkle path updates entirely, so flushes stay batched and sequential and nothing is re-hashed on the write path. +- Frequently accessed state is held in RAM, and reads are served from memory in the common case. All disk writes are asynchronous and exist for durability only, protected by an append-only write-ahead log (WAL) that is replayed on crash recovery. +- Storage is tiered: recent and hot data sits on local high-performance SSDs, while historical data moves to a distributed columnar store built for analytical queries and audit workloads. + + + +### Lattice-hash divergence digests + +There is no state root, so Giga commits to execution results with a homomorphic multiset hash (LtHash, by Lewi, Kim, Maykov, and Weis): `LH(X) = Σ h(x) mod q`. Its collision resistance rests on lattice assumptions (short integer solution style). For each block `n`: + +- The committed multiset `X_n` contains one record per surviving write (after intra-block last-write-wins resolution), one record per transaction receipt (position-bound), and one gas-accounting record, each domain-separated by type tag and height. +- The block digest is `d_n = LH(X_n)`; validators attest to the compact commitment `D_n = H(enc(n, d_n))`. The full vector `d_n` is exchanged only during disputes. +- Disputes resolve by bisection. The key space partitions into ranges whose chunk digests sum to the write component of `d_n` by construction, so divergent executors compare chunk digests, narrow down, and replay only the affected range to find the first divergent write, receipt, or gas discrepancy. + +The homomorphism is what makes this practical: digests update incrementally as writes commit, in any order, and no tree walk is involved. + +### Block Update Digests (BUDs) + +BUDs restore externally verifiable state proofs (the role `eth_getProof` plays on Ethereum) at a cost proportional to per-block update volume rather than total state size: + +- Every state entry carries an 8-byte last-modified height and a 1-byte serialization version. For each block `n`, the BUD `U_n` is the Merkle root over the lexicographically sorted leaves `(key, newValue, n, prevHeight)` of that block's writes. Validators attest `U_n` on the same delayed 2/3-quorum schedule as the divergence digest. +- A membership proof is a Merkle path to an attested `U_n`, certifying that `key` held `value` immediately after block `n` and recording when it previously changed. Two proofs at heights `a < b` whose `b`-leaf records predecessor `a` prove the key was unmodified throughout `(a, b)`. +- SuperBUDs aggregate BUDs over exponentially growing aligned windows (branching base `e` and maximum level `L_max`, both governance parameters), so provers cover long ranges with logarithmically many digests. The guaranteed proof window is `η = e^L_max` blocks; older claims can be served by archive nodes but fall outside the protocol guarantee. +- Touch transactions rewrite only a key's last-modified metadata, giving long-untouched keys a fresh proof anchor. Deletions leave tombstones, garbage-collected after `η`, which anchor exclusion proofs. +- At the activation height a one-time synthetic write log bootstraps every existing key, and the system reaches steady state after `η` blocks. BUD trees deliberately use a classical hash: the short proof window keeps classical collision resistance sufficient, and the trees fall under the same [post-quantum migration schedule](#post-quantum-migration) as the rest of the protocol. + + + +Light clients, bridges, and any external verifier consume BUD proofs against attested digests instead of Merkle-Patricia proofs against a state root. + +## Networking and transaction ingress + +- Nodes communicate over direct, authenticated point-to-point connections; nothing is gossip-flooded. Consensus messages, lane proposals, votes, and certificates stream over dedicated channels with per-channel rate and size limits. +- There is no mempool. An RPC node forwards each incoming transaction to a validator for immediate lane inclusion, allocated by stake weight. In the current implementation, EVM senders map deterministically to a validator shard, and `eth_sendRawTransaction` plus pending-nonce queries are proxied to that shard's owner. +- Users may submit the same transaction to multiple validators for censorship resistance. Admission is rate-limited: each validator includes at most one copy of a given transaction per epoch, duplicates are dropped deterministically at merge time, only one copy ever executes, and unexecuted duplicates earn a partial tip refund while paying the [distribution fee](#fee-model). +- Four node roles exist: validators (consensus and execution), full nodes (RPC plus execution for the read path), light nodes (RPC only), and data nodes that serve recent data. + +### Sedna: private dissemination (planned) + +[Sedna](https://arxiv.org/abs/2512.17045) is Giga's planned "private mempool" layer, though on Giga there is no mempool to make private; what Sedna makes private is dissemination. Senders encode a committed transaction payload into verifiable rateless coded symbols and send addressed bundles to selected proposer lanes. No lane sees the whole transaction, and executors reconstruct the unique payload only after ordering, once finalized symbols cross the decode threshold ("until-decode privacy"). Compared with threshold-encrypted mempools, this reaches similar pre-execution privacy without an extra decryption round or any trust assumption beyond the existing `f + 1` availability quorum, and with better goodput; coding also cuts per-lane bandwidth to a fraction of the payload size. The companion incentive mechanism [PIVOT-K](https://arxiv.org/abs/2603.17614) concentrates a sender-funded bounty on the bundles that trigger decoding and ratchets away from lanes that withhold, which closes the withholding attack. Sedna ships as its own roadmap milestone after Autobahn reaches mainnet. + +## MEV and fee design + +Multi-concurrent proposer architectures remove the single block-builder's private ordering monopoly but introduce their own MEV (maximal extractable value) channels, formalized in [MEV in Multiple Concurrent Proposer Blockchains](https://arxiv.org/abs/2511.13080): same-tick duplicate stealing (copying a visible transaction into your own lane to win the merge), proposer-to-proposer orderflow deals, and timing races around PoA latency. Giga's countermeasures live at the protocol level. + +### Deterministic merge rule + +For each committed cut, every node derives the executable sequence with the same pure function: + +1. Take each lane's newly committed transactions, meaning those not in any previous cut, in their intra-lane order. +2. Sort lanes by the maximum priority fee among their new transactions, descending; break ties by replica index. +3. Concatenate the lanes and deduplicate by transaction hash; only the first occurrence survives. + + + +The merged order depends only on finalized lane contents, not on arrival timing, wall clocks, or any node's discretion, so there is no post-consensus ordering game to play. + +### Socialised tips + +All priority fees collected in an epoch (net of duplicate refunds) are pooled and distributed to validators pro rata by `stake × liveness`, where liveness is the measured fraction of observable duties performed: consensus votes included in committed QCs, certified lane blocks produced, and signed state attestations, with duty weighting set by governance. Payouts are shared with delegators in the same way as block rewards. + +- Copying a high-tip transaction into your own lane no longer captures its fee, so the duplicate-steal channel loses its revenue motive. +- Validator revenue is independent of orderflow routing, so there is no market for steering users to specific proposers. +- Withholding or lazy participation directly reduces a validator's payout. + +The whitepaper sums it up: the priority fee buys ordering, not a relationship with a particular proposer. Side payments for intra-lane position are out of protocol scope for now and belong to the forthcoming fee-mechanism work. + +## Post-quantum migration + +Giga ships with a survivability path for a sudden ECDSA break ("Q-day") that avoids a chain-wide account reset: + +- Before a governance-set cutoff height, any account may register a post-quantum verification key (scheme identifier, PQ public key, migration nonce, optional activation height), signed with its current classical key. +- During the transition window the chain accepts classical or dual classical+PQ signatures. After the cutoff, verification is table-driven PQ-only: unregistered accounts become invalid, there is no public-key-recovery path, and no new classical EOAs can be created. Onboarding continues through pre-registration, contract wallets, or a later native PQ account format. +- The designated short-term scheme is ML-DSA (FIPS 204). The whitepaper is explicit that this is an emergency path and not fast enough for Giga's throughput; post-quantum cryptography at Giga scale is open research. + +## Performance + +| Metric | Value | Context | Source (date) | +| --------------------------- | ----------------------------------- | --------------------------------------------------------- | ----------------------------------------------- | +| Sustained throughput | >5 gigagas/s | Internal devnet: 40 nodes across 20 regions | Whitepaper v2.0 (June 2026) | +| Ordering finality | <250 ms | Same devnet (whitepaper v1: <400 ms; Feb 2025 devnet: ~700 ms, 4 regions) | Whitepaper v2.0 (June 2026) | +| Transactions per second | 200,000+ | Simple transfers at 5 gigagas/s | Sei Labs roadmap and whitepaper (2025 and 2026) | +| Consensus efficiency | 1.5 round trips vs 3 (2×) | Autobahn vs Tendermint voting rounds | Whitepaper §1.1 (2026) | +| Throughput vs Tendermint | >50× | Multi-concurrent proposer dissemination vs single leader | Whitepaper §1.1 (2026) | +| Block production | ~70× (180 blocks vs 2.5) | All-lanes-at-once commits vs sequential single blocks | Whitepaper §1.1 (2026) | +| Autobahn testnet target | 200,000 TPS at 400 ms finality | Public testnet milestone | [giga.seilabs.io](https://giga.seilabs.io) (May 2026) | + +The whitepaper publishes no fixed block gas limit, block size, or validator hardware specification for Giga; the roadmap's Autobahn testnet milestone includes the final consensus specification. Figures you may see for today's network (block times, gas limits) describe the [current architecture](/learn/twin-turbo-consensus), not Giga. + +## Implementation snapshot (sei-chain v6.6 release line, July 2026) + +Giga is implemented in the open in [sei-protocol/sei-chain](https://github.com/sei-protocol/sei-chain); there is no separate Giga repository. The facts below describe the v6.6 release line and can change before network activation: + +| Area | Current state | +| ----------------- | ------------------------------------------------------------------------------------------------------------------------------------ | +| Giga executor | `giga/` package; enabled by default with OCC (`[giga_executor]` in `app.toml`); EVM engine is Sei's go-ethereum fork (v1.15.7-sei-17), with an optional evmone 0.12.0 interpreter that is not used in production | +| Execution fallback | EVM transactions run through the Giga executor; calls into Sei's custom precompiles, unsupported iterator patterns, and legacy balance migrations fall back to the v2 engine transparently | +| Autobahn | Implemented in `sei-tendermint/autobahn` (lanes, PoAs, prepare/commit QCs, timeout certificates); ships in the binary but disabled by default in all supported environments until network activation; committee capped at 100 validators; PoA quorum is `f + 1` by stake weight | +| Operator surface | `autobahn-config-file` in `config.toml`, committee file generated with `seid tendermint gen-autobahn-config`; consensus state persisted across restarts to prevent double-signing | +| RPC under Autobahn | `eth_sendRawTransaction` and pending-nonce queries proxy to the sender's shard validator; block and status endpoints route through Autobahn; `eth_subscribe` (newHeads) supported | +| Storage | FlatKV state-commitment store with blake3-based LtHash (1024 × 16-bit limbs) for EVM state; composite store routes Cosmos state to memiavl and EVM state to FlatKV; HashVault pins one block-hash commitment per height and halts the node on mismatch; receipts are served from a dedicated Pebble-backed store, with LittDB (an append-only engine built for this workload) shipping in the tree as the intended receipts-and-blocks engine, wired in after v6.6 | +| RPC-node storage | Dedicated EVM state-store split (`evm-ss-split`) targeting ~150k TPS reads; see the [Giga storage migration guide](/node/giga-storage-migration) | +| Testing | Differential Giga-vs-v2 execution across the Ethereum state-test suite; mixed Giga/v2 clusters; Autobahn integration harness | + +Node operators should follow the [node configuration reference](/node/node-operators#giga-storage-and-giga-executor) rather than this page for exact keys and defaults. + +## Glossary + +| Term | Definition | +| ----------------------------- | --------------------------------------------------------------------------------------------------------------- | +| **MCP (multi-concurrent proposer)** | Architecture in which every validator proposes transaction data concurrently; Giga is the first MCP EVM L1 | +| **Lane** | A validator's own append-only, hash-chained sequence of transaction batches | +| **Car** | One batch of transactions in a lane (a lane entry) | +| **Proposal** | Signed lane entry `⟨pos, batch, parentRef⟩` | +| **PoA (Proof of Availability)** | Certificate formed from `f + 1` votes that a proposal's data is retrievable | +| **Tip** | The most recent proposal in a lane that holds a PoA | +| **Cut** | The vector of all lanes' current tips committed by one consensus decision | +| **Slot** | One consensus instance committing one cut; slots are pipelined | +| **PrepareQC / CommitQC** | Quorum certificates from the prepare and commit voting phases | +| **Timeout certificate** | Certificate that triggers a view change when a leader stalls | +| **Blip** | A transient network disruption; Autobahn recovers from blips without throughput loss | +| **Ordering finality** | The transaction order is irrevocably fixed by consensus (the sub-250 ms signal) | +| **State attestation finality** | A 2/3 quorum has attested the block's execution results in a later block | +| **Write log** | A block's canonical key-value write set after last-write-wins resolution | +| **Divergence digest** | Compact lattice-hash commitment over a block's write log, receipts, and gas; this is what validators attest | +| **LtHash** | Homomorphic multiset hash used for divergence digests; updates incrementally, in any order | +| **BUD (Block Update Digest)** | Per-block Merkle root over that block's state updates; the basis of Giga state proofs | +| **SuperBUD** | Aggregated BUD covering an exponentially sized window of blocks | +| **Touch transaction** | Transaction that refreshes a key's last-modified metadata to create a fresh proof anchor | +| **Proof window (η)** | Number of blocks over which BUD proofs are protocol-guaranteed (`η = e^L_max`, governance-set) | +| **Merge rule** | Deterministic function from a committed cut to the executable transaction sequence (tip-priority order plus deduplication) | +| **Socialised tips** | Epoch-pooled priority fees distributed by stake × liveness instead of to the carrying proposer | +| **Distribution fee** | Fee component pricing duplicate submissions made for censorship resistance | +| **Sedna** | Planned private dissemination layer: rateless-coded, addressed bundles with until-decode privacy | +| **PIVOT-K** | Sedna's incentive mechanism: bounties on decode-pivotal bundles plus a sender ratchet against withholding | +| **Ambulance** | Planned consensus upgrade replacing timeout-based leader recovery with a rigged race among replicas | +| **Hermes** | Next-generation consensus protocol after Autobahn (whitepaper forthcoming) | +| **Ares / Eidos** | The execution-client and storage rebuild upgrades currently shipping Giga components to the live network | + +## References + +- [Sei Giga whitepaper v2.0](https://arxiv.org/abs/2505.14914) by Marsh, Landers, Jog, and Ranchal-Pedrosa (arXiv 2505.14914, June 2026) +- [Autobahn: Seamless high speed BFT](https://arxiv.org/abs/2401.10369) by Giridharan, Suri-Payer, Abraham, Alvisi, and Crooks (arXiv 2401.10369) +- [MEV in Multiple Concurrent Proposer Blockchains](https://arxiv.org/abs/2511.13080) by Landers and Marsh (arXiv 2511.13080) +- [Sedna: Sharding transactions in multiple concurrent proposer blockchains](https://arxiv.org/abs/2512.17045) (arXiv 2512.17045) and its mechanism-design companion introducing [PIVOT-K](https://arxiv.org/abs/2603.17614) (arXiv 2603.17614) +- [Ambulance: saving BFT through racing](https://arxiv.org/abs/2606.25099) (arXiv 2606.25099) +- [Block-STM](https://arxiv.org/abs/2203.06871), the parallel execution design Giga follows (arXiv 2203.06871) +- [Sei Giga: Achieving 5 Gigagas with Autobahn Consensus](https://seiresearch.io/articles/sei-giga-achieving-5-gigagas-with-autobahn-consensus), devnet results (Feb 2025) +- [Autobahn: Sei Giga's Multi-concurrent proposer approach to blockchain consensus](https://blog.sei.io/autobahn-sei-gigas-Multi-concurrent proposer-approach-to-blockchain-consensus), explainer post (Apr 2025) +- [The Giga Whitepaper v2](https://blog.sei.io/the-giga-whitepaper-2/), the announcement post (July 2026) +- [sei-protocol/sei-chain](https://github.com/sei-protocol/sei-chain), the open-source implementation + +_Last updated July 2026, based on the Giga whitepaper v2.0 (June 29, 2026) and the sei-chain v6.6 release line._ diff --git a/learn/sei-giga.mdx b/learn/sei-giga.mdx index bd6cbe0..6b9cfed 100644 --- a/learn/sei-giga.mdx +++ b/learn/sei-giga.mdx @@ -1,342 +1,194 @@ --- -title: 'Sei Giga Overview: The Fastest EVM Blockchain' +title: 'What Is Sei Giga?' sidebarTitle: 'Overview' -description: 'A comprehensive technical overview of Sei Giga - a high-performance blockchain platform combining EVM compatibility with groundbreaking consensus, execution, and storage innovations for unprecedented throughput and sub-second finality.' -keywords: ['sei giga', 'evm blockchain', 'autobahn consensus', 'parallel execution', 'blockchain performance', '5 gigagas', 'sub-second finality'] +description: 'Sei Giga is the next-generation Sei protocol and the first Multi-concurrent proposer EVM Layer 1. On an internal 40-node devnet it finalized transaction ordering in under 250 ms and sustained more than 5 gigagas per second. It rolls out as in-place upgrades to the live Sei network.' +keywords: ['sei giga', 'Multi-concurrent proposer blockchain', 'autobahn consensus', 'evm layer 1', 'gigagas', 'asynchronous execution', 'parallel execution', '200000 tps', 'sub-250ms finality'] --- -## Introduction +import { GigaProposerComparison, GigaAsyncPipeline, GigaTxJourney, GigaRoadmapTrack } from '/snippets/giga-diagrams.jsx'; -Sei Giga represents a high-performance blockchain platform designed to address the persistent challenges of the "blockchain trilemma": the difficulty of simultaneously optimizing for security, decentralization, and performance. The platform combines current optimizations with upcoming architectural innovations to achieve exceptional performance while maintaining security guarantees and developer experience. +Sei Giga is the next generation of the Sei protocol and the first Multi-concurrent proposer EVM Layer 1. Every validator proposes transactions at the same time, consensus finalizes only the order of those transactions, and execution and state attestation happen afterwards, off the critical path. On an internal devnet of 40 nodes across 20 regions, Giga sustained more than 5 gigagas per second (5 billion gas per second) with ordering finality under 250 ms, which works out to roughly 200,000 transactions per second. Giga ships as a series of in-place upgrades to the live Sei network rather than as a new chain: there is no regenesis and nothing goes offline. -**Current Features**: Sei operates with Twin Turbo consensus optimizations, parallel execution capabilities, and SeiDB storage, delivering significant performance improvements over traditional blockchains. + + **Status (July 2026):** The [Giga whitepaper v2.0](https://arxiv.org/abs/2505.14914) was published in June 2026. The execution rebuild (Ares), storage rebuild (Eidos), and the EVM-only consolidation ([SIP-3](/learn/sip-03-migration)) are in progress on the live network today; the Autobahn consensus testnet is the next milestone on the [official roadmap](https://giga.seilabs.io). See [How Sei Giga ships](#how-does-sei-giga-ship) below. + -**Upcoming Features**: Advanced features including Autobahn consensus, multi-proposer architecture, and 5 gigagas throughput targets are in development and represent the next evolution of the platform. +## Sei Giga at a glance -## Current Architecture +| Property | Sei Giga | +| -------------------- | -------------------------------------------------------------------------------------------------------------------- | +| Architecture | Multi-concurrent proposer (MCP, multi-concurrent proposer) EVM Layer 1; every validator proposes concurrently | +| Consensus | Autobahn BFT: per-validator data lanes with periodic cut-of-tips ordering | +| Consensus latency | 1.5 network round trips per commit (Tendermint needs 3 full rounds) | +| Finality | Sub-250 ms ordering finality (measured on internal devnet, June 2026) | +| Throughput | More than 5 gigagas/s sustained; 200,000+ TPS | +| Execution | Runs after ordering finality; Block-STM-style parallel EVM with optimistic concurrency control | +| State commitment | Lattice-hash divergence digests over each block's write log (no Merkle state root on the hot path) | +| State proofs | Block Update Digests (BUDs); proof cost scales with per-block updates rather than total state size | +| Mempool | None; transactions go directly into a validator's proposal lane | +| EVM compatibility | Equivalent to Ethereum mainnet except EIP-4844 blobs, `PREVRANDAO`, the state root, the block gas limit, and the fee mechanism | +| Security model | BFT with `n = 3f + 1` validators; safety unconditional, liveness under partial synchrony | +| Delivery | Phased, in-place upgrades of the live Sei network, with no regenesis and no new chain ID | -Sei's current system delivers significant performance improvements through three core components: +## Why does Sei Giga exist? -### 1. Twin Turbo Consensus +Giga's design goal is efficient, fast, and fair on-chain trading, a workload that needs very high throughput, low latency, and bounded censorship and MEV (maximal extractable value) risk. Sei Labs' [Giga announcement](https://blog.sei.io/announcements/giga/) frames the gap: Ethereum mainnet processes on the order of 100 TPS, while comparable web2 systems handle around 100,000 complex transactions per second. Closing that gap on a single decentralized EVM chain means removing three bottlenecks that all single-proposer blockchains share: -The current consensus mechanism achieves ~400ms block times through aggressive optimization of the Tendermint BFT consensus engine. Key features include: +1. One leader per block. In Tendermint-style consensus, a single proposer's bandwidth and connectivity cap the whole network's throughput each round. Giga makes every validator a proposer with its own data lane. +2. Consensus waits for execution. Traditional chains execute transactions and agree on the resulting state root inside the consensus loop, so heavy blocks slow finality. Giga reaches consensus on ordering only and executes asynchronously. +3. Merkle write amplification. Per-write Merkle tree updates multiply disk I/O as state grows. Giga replaces the hot-path Merkle tree with a flat key-value store and homomorphic lattice hashes. -- Pipelined block processing -- Optimistic transaction execution during consensus -- Aggressive timeout configurations -- Parallel transaction decoding and validation +Sei's [current architecture](/learn/twin-turbo-consensus) already pushed the single-proposer model near its limits: ~400 ms blocks, [optimistic parallel execution](/learn/parallelization-engine), and [SeiDB](/learn/seidb). Giga replaces the model instead of tuning it further. -[Learn more about Twin Turbo Consensus →](/learn/twin-turbo-consensus) +## How does Sei Giga work? -### 2. Parallel Execution Engine +Giga separates the work of a blockchain into four decoupled stages: data dissemination, ordering, execution, and state attestation. Each stage runs concurrently rather than blocking the next. -Sei implements Optimistic Concurrency Control (OCC) for parallel transaction execution: +### Autobahn consensus -- Multiple CPU cores process non-conflicting transactions simultaneously -- Automatic conflict detection and resolution -- Maintains deterministic execution order -- Compatible with standard EVM semantics +Giga orders transactions with [Autobahn](https://arxiv.org/abs/2401.10369), a Byzantine Fault Tolerant consensus protocol that separates data dissemination from ordering: -[Learn more about the Parallelization Engine →](/learn/parallelization-engine) +- Each validator continuously streams batches of transactions ("cars") into its own hash-chained lane, in parallel with every other validator. +- A batch is certified by a Proof of Availability (PoA) once `f + 1` validators vote that they hold the data, which is enough to guarantee at least one honest holder. +- Consensus periodically commits a cut: a snapshot of the latest certified tip of every lane. Lanes are hash-chained, so committing a tip implicitly commits everything behind it, and one consensus decision can finalize many blocks of data at once. +- The ordering vote takes 1.5 network round trips with pipelined slots, versus three full rounds for Tendermint, and validators vote on compact certificates instead of downloading full blocks first. -### 3. SeiDB Storage System + -A specialized database optimized for blockchain workloads: +Throughput now scales with the number of validators disseminating data instead of being capped by one leader's connection; Sei Labs cites over 50 times Tendermint's throughput, with standard BFT safety intact. The full protocol is in the [consensus specification](/learn/sei-giga-specs#consensus-autobahn). -- Multi-level caching for hot state data -- Optimized Merkle Patricia Trie structure -- Concurrent state access controls -- Efficient state versioning and pruning +### Asynchronous execution and state attestation -[Learn more about SeiDB →](/learn/seidb) +Giga defines two distinct finality signals: -## Upcoming Sei Giga Architecture +- Ordering finality: consensus has fixed the transaction order irrevocably. This is the sub-250 ms signal, and for most applications it is the moment a transaction is final. +- State attestation finality: validators have executed the block, computed a compact divergence digest over its write log, and a 2/3 quorum has attested to that digest in a later block. -The next evolution of Sei Giga will introduce three key innovations designed to achieve target performance characteristics: + -### 1. Asynchronous Execution Model (Upcoming) +Execution is deterministic, so every honest node that executes the same ordered transactions from the same state computes the identical result, and the chain never pauses ordering while execution catches up. If fewer than 1/3 of validators diverge (a hardware fault or software bug), the chain keeps running while the fault is isolated; a divergence beyond the Byzantine threshold halts the chain, exactly as in any BFT system. Signing two different digests for the same block is slashable equivocation. -A planned architectural enhancement will implement complete separation of consensus and execution. Unlike traditional blockchains where these processes are tightly coupled, the upcoming Sei Giga architecture will reach consensus solely on the ordering of transactions within a block, not the resulting state change. +### Parallel execution -**Asynchronous Execution Architecture** +Once ordering is final, each block executes across all CPU cores using optimistic concurrency control: - - - 1. Order Transactions - 2. Execute & Compute State - 3. Reach Consensus on State - 4. Finalize Block +- All transactions in a block start executing in parallel, buffering their writes privately. +- A validation phase detects conflicts (a transaction read or wrote state that an earlier-ordered transaction wrote) and re-executes only the conflicting transactions. +- The committed result is guaranteed to be identical to sequential execution in block order, and under sustained contention the engine falls back to sequential execution with unchanged semantics. - ⚠️ Execution delays consensus - - - 1. Order Transactions - 2. Consensus on Order - 3. Finalize Block n - - **Parallel Process:** - - Execute Block $n - 1$ - - Commit State in Block $n+x$ - - ✓ Consensus proceeds independently - - - -This approach leverages the key property of deterministic execution: +Sei Labs' research found that [64.85% of historical Ethereum transactions could have been parallelized](https://blog.sei.io/research-64-85-of-ethereum-transactions-can-be-parallelized/) this way. Contract-level guidance for maximizing parallelism is in the [developer guide](/learn/sei-giga-developers#writing-parallel-friendly-contracts). -**Lemma 1 (Deterministic Execution)**: Given the same initial state ($S_{init}$) and the same ordered sequence of transactions (${tx}_1, {tx}_2, ..., {tx}_n$), all honest nodes executing these transactions will arrive at the exact same final state ($S_{final}$). +### Flat storage and lattice hashes -Key benefits of this model: +Giga's storage layer is built for a network that produces petabytes of new data per year at full load: -- **Non-blocking consensus**: Heavy computational blocks don't delay consensus -- **Pipelined processing**: Multiple blocks can be in different stages simultaneously -- **Optimized resource usage**: Consensus and execution use different hardware resources +- Flat key-value store: every account and storage slot maps directly to an entry in a log-structured merge (LSM) tree, with no per-write Merkle path updates. Hot state is served from RAM; disk writes are asynchronous, with a write-ahead log for crash recovery. +- Lattice-hash commitments: instead of a state root, each block's write log is committed with a homomorphic multiset hash (LtHash). Validators attest to this digest, and disputes are resolved by bisecting chunked digests to pinpoint the first divergent write. +- Block Update Digests (BUDs): Merkle proofs over per-block updates replace global state proofs, so proof cost scales with how much a block changed rather than how large total state is. Light clients and bridges consume these attested digests. +- Tiered storage: recent, hot data lives on local high-performance SSDs; historical data moves to a distributed columnar store for analytics and audit workloads. -### 2. Autobahn Consensus Protocol (Upcoming) +The [Eidos upgrade](#how-does-sei-giga-ship) is delivering this storage model to the live network, and its first production pieces (FlatKV with lattice hashing) already ship in `sei-chain`. Details are in the [storage specification](/learn/sei-giga-specs#storage). -**Future Features**: The Autobahn consensus protocol described here represents upcoming enhancements. The current system uses optimized Tendermint consensus (Twin Turbo). +## What changes from today's Sei? -The upcoming Sei Giga will employ Autobahn, a Byzantine Fault Tolerant (BFT) consensus protocol designed for high performance blockchain networks. Unlike traditional single-proposer systems, Autobahn will enable multiple validators to propose blocks simultaneously, targeting significant throughput improvements while maintaining security guarantees. +| Layer | Sei today (v2) | Sei Giga | +| ---------------- | -------------------------------------------------------------------------- | ----------------------------------------------------------------------------------------- | +| Block proposal | One proposer per height | Every validator proposes concurrently in its own lane | +| Consensus | [Twin Turbo](/learn/twin-turbo-consensus) (optimized Tendermint), ~400 ms | Autobahn: PoA-certified lanes with cut-of-tips ordering, 1.5 round trips, sub-250 ms | +| Execution | Interleaved with consensus, optimistically parallel ([OCC](/learn/parallelization-engine)) | Fully asynchronous after ordering finality; Block-STM-style OCC | +| State commitment | Merkle app hash ([SeiDB](/learn/seidb): memiavl + FlatKV) | Lattice-hash divergence digests attested after execution, with no Merkle root on the hot path | +| State proofs | IAVL/Merkle proofs | Block Update Digests (BUDs) with a governance-set proof window | +| Mempool | Gossiped mempool | None; transactions go straight into a validator's lane | +| Fee model | EIP-1559-style base fee + priority fee to the proposer | Three-part fees: 1559-style execution fee, ordering fee, distribution fee; tips socialised across validators | +| Chain surface | EVM + legacy Cosmos modules | Streamlined EVM-only stack (via [SIP-3](/learn/sip-03-migration)) | -**Autobahn Consensus Architecture** +## What happens to a transaction on Sei Giga? - - - - **Lane $\ell_1$**: ${Prop}_1$, ${Prop}_2$, ${Prop}_3$, $Tip$ - - **Lane $\ell_2$**: ${Prop}_1$, ${Prop}_2$, $Tip$, ... - - **Lane $\ell_n$**: ${Prop}_1$, ${Prop}_2$, ${Prop}_3$, $Tip$ +Giga has no mempool: a submitted transaction is immediately included by a validator rather than waiting in a shared pending pool. - Each validator maintains independent lane. - - - $Cut = [{Tip}_1, {Tip}_2, ..., {Tip}_n]$ - - Periodic ordering of lane tips. + - 1. **Prepare Phase** — Leader collects tips, forms Cut - 2. **Fast Path** ($n$ votes) — Immediate commit if all agree - 3. **Slow Path** ($2f+1$ votes) — Additional round if needed +1. You send a signed transaction to an RPC node, which forwards it to a validator. Allocation is stake-weighted, and you can submit the same transaction to several validators for censorship resistance. +2. The validator appends the transaction to its next batch and chains that batch into its lane. +3. Once `f + 1` validators acknowledge the batch, it holds a Proof of Availability and the lane tip advances. +4. The consensus leader commits a cut of all lane tips in 1.5 round trips. Your transaction's position is now fixed. This is ordering finality; on the internal devnet it arrived in under 250 ms. +5. Every node merges the cut into one sequence using the deterministic tip-priority rule, drops duplicates by hash, and executes the result in parallel. Duplicate copies never execute and never pay execution costs twice. +6. Validators attest to the block's divergence digest in a later block. This is state attestation finality. - Global ordering through BFT agreement. - - +Guidance on which finality signal to use for what is in the [developer guide](/learn/sei-giga-developers#finality-on-giga-which-signal-to-wait-for). -**Protocol Properties** +## How does Giga handle MEV and fees? - - - $n = 3f + 1$ replicas - - - Unconditional - - - Eventual synchrony - - +Multi-concurrent proposer chains eliminate the single sequencer's private block-building monopoly, but they create new MEV channels of their own: same-tick duplicate stealing, proposer-to-proposer orderflow deals, and races around PoA latency. Sei Labs formalized these in a [dedicated MEV paper](https://arxiv.org/abs/2511.13080). Giga addresses them at the protocol level: -The protocol operates through two complementary layers: +- The merge rule is deterministic. The order of transactions within a committed cut is a pure function of lane contents: lanes sort by their highest included tip, intra-lane order is preserved, and duplicates are dropped. Arrival timing and proposer discretion play no part. +- Priority fees are socialised. Fees from each epoch are pooled and distributed to validators by stake and measured liveness, not paid to whichever proposer carried the transaction. Copying someone else's high-tip transaction into your own lane earns the copier nothing extra, and there is no revenue in routing deals with specific proposers. A tip pays for position in the order and nothing else. +- Fees come in three parts: an EIP-1559-style execution fee, a strictly enforced ordering fee (the priority fee), and a distribution fee that prices duplicate submissions. Duplicates are deduplicated at merge time, and only one copy executes; the rest are refunded part of their tip. -**Data Dissemination Layer (Lanes)**: +The full mechanism is specified in [MEV and fee design](/learn/sei-giga-specs#mev-and-fee-design). -- Each validator maintains an independent lane for proposing transaction batches -- Three-step certification process: Propose → Vote → Proof of Availability (PoA) -- Chained proposals ensure availability of historical data +## How does Sei Giga ship? -**Consensus Layer (Cut of Tips)**: +Giga arrives as a sequence of named upgrades to the live Sei network, "without regenesis and without taking any element of the network offline" ([Sei Labs, July 2026](https://blog.sei.io/the-giga-whitepaper-2/)). The canonical tracker is [giga.seilabs.io](https://giga.seilabs.io). Status as of July 2026: -- Periodic ordering of latest certified tips from all lanes -- Two-phase BFT agreement with fast and slow paths -- Pipelined slots for minimal latency + -### 3. Advanced Parallel Execution +| Milestone | Scope | Status | +| ---------------------- | ------------------------------------------------------------------------------------------------- | ----------- | +| Giga whitepaper v1 | Initial specification ([arXiv 2505.14914](https://arxiv.org/abs/2505.14914)), MEV formalization ([arXiv 2511.13080](https://arxiv.org/abs/2511.13080)) | Complete | +| Internal devnet | Geo-distributed devnet sustaining [5 gigagas/s with Autobahn](https://seiresearch.io/articles/sei-giga-achieving-5-gigagas-with-autobahn-consensus) | Complete | +| Giga whitepaper v2 | Revised spec (June 2026): sub-250 ms finality, Sedna, BUDs, fee model, post-quantum path | Complete | +| Ares upgrade | Execution client rebuilt for Giga-scale throughput on existing consensus: pipelined parsing, validation, and signature checks; receipts and indexing moved off the commit path; VM efficiency work; live deployment to mainnet | In progress | +| Eidos upgrade | Storage rebuild: Merkle trees replaced by a flat key-value store with lattice hashes; embedded DB for hot state, horizontally scalable cold archive; engines built specifically for receipts, logs, and blocks | In progress | +| SIP-3 | Pre-Giga consolidation to a streamlined EVM-only stack; see the [migration guide](/learn/sip-03-migration) | In progress | +| Autobahn testnet | Multi-concurrent proposer, order-first consensus with asynchronous state on a public testnet, targeting 200,000 TPS with 400 ms finality; a final consensus whitepaper accompanies it | Coming soon | +| Autobahn mainnet | The live Sei network upgrades to Autobahn consensus | Coming soon | +| Sedna upgrade | Private transaction dissemination (the "private mempool" milestone): transaction fragments spread across lanes and are reassembled only after ordering | Coming soon | +| Hermes testnet | Next-generation consensus beyond Autobahn (whitepaper forthcoming) | Coming soon | +| Hermes mainnet | Hermes merges into Sei mainnet | Coming soon | -The parallel execution architecture extends beyond current OCC capabilities to include: +Parts of this are already in the `sei-chain` codebase. As of July 2026 the Giga execution engine ships in [sei-chain](https://github.com/sei-protocol/sei-chain) and runs by default (with OCC) from the v6.6 release line, while Autobahn consensus and the FlatKV/lattice-hash storage stack ship in the same binary behind operator flags, disabled until their network activations. Node operators can review the [Giga executor configuration](/node/node-operators#giga-storage-and-giga-executor) and the [Giga storage migration guide](/node/giga-storage-migration). -**Parallel Execution Pipeline** + + There is no public Giga testnet yet (as of July 2026), and therefore no separate Giga chain ID, RPC endpoint, or faucet. Anything claiming otherwise is not official. Current network endpoints remain those of [Sei mainnet and testnet](/learn/dev-chains). + - - - **Transaction Parsing** +## Measured performance - Parallel decode - - - **Dependency Analysis** +Each row carries its source and date: the devnet figures are Sei Labs' internal measurements, the consensus multipliers are whitepaper claims, and the testnet figures are targets. - Conflict prediction - - - **Parallel Execution** +| Metric | Value | Context | Source (date) | +| ----------------------------- | -------------------------------------- | ------------------------------------------------------ | ----------------------------------------------------------------------------- | +| Throughput | >5 gigagas/s sustained | Internal devnet, 40 nodes across 20 regions | [Whitepaper v2.0](https://arxiv.org/abs/2505.14914) (June 2026) | +| Ordering finality | <250 ms | Same devnet (v1 reported <400 ms; Feb 2025 devnet ~700 ms across 4 regions) | Whitepaper v2.0 (June 2026) | +| Transactions per second | 200,000+ | Simple transfers at 5 gigagas/s (21,000 gas each) | [Roadmap](https://giga.seilabs.io) and whitepaper (2025 and 2026) | +| Consensus round trips | 1.5 (vs 3 in Tendermint) | Autobahn pipelined slow path | Whitepaper §1.1 and §3.4 (2026) | +| Throughput vs Tendermint | >50× | Autobahn vs single-proposer Tendermint | Whitepaper §1.1 (2026); see also the [Autobahn explainer](https://blog.sei.io/autobahn-sei-gigas-Multi-concurrent proposer-approach-to-blockchain-consensus) (Apr 2025) | +| Block production | ~70× (180 blocks vs 2.5) | Multi-concurrent proposer lanes vs single proposer | Whitepaper §1.1 (2026) | +| Parallelizable EVM workload | 64.85% | Historical Ethereum transactions | [Sei research](https://blog.sei.io/research-64-85-of-ethereum-transactions-can-be-parallelized/) (2024) | +| Autobahn testnet target | 200,000 TPS, 400 ms finality | Public testnet milestone | [giga.seilabs.io](https://giga.seilabs.io) (May 2026) | - Multi-core OCC - - - **State Commit** +## Learn more - Batch writes + + + The full protocol spec: Autobahn, asynchronous execution, storage, MEV and fee design, security model, and glossary. - - - - - - Read/Write set tracking - - Optimistic execution - - Automatic re-execution on conflict - - Preserves deterministic ordering + + What changes for contracts and apps: finality semantics, fees, proofs, and parallel-friendly patterns. - - - ~65% of ETH txs parallelizable - - Linear scaling with cores - - Minimal conflict overhead - - Zero-copy transaction handling + + The canonical specification on arXiv (Marsh, Landers, Jog, Ranchal-Pedrosa; June 2026). - - -Key innovations in the execution model: - -- **Flat encoding format**: Length-prefixed layout for fast, zero-copy decoding -- **Predictive conflict analysis**: ML-based prediction of transaction dependencies -- **Semantic understanding**: Special handling for common patterns (ERC-20 transfers) -- **Adaptive parallelism**: Dynamic adjustment based on conflict rates - -## Storage Architecture Evolution - -Beyond the current SeiDB capabilities, the Sei Giga architecture includes advanced storage innovations: - -**Hybrid Storage Architecture** - - - - - **Recent Blocks** — High-speed NVMe SSDs - - **Active State** — Memory-mapped files - - **Access Pattern** — Sub-ms latency + + Live milestone tracker for the Giga upgrade. - - - **Recent History** — Standard SSDs - - **Compressed State** — LZ4 compression - - **Access Pattern** — 1-10ms latency + + The EVM-only consolidation that clears the path to Giga. - - - **Historical Data** — Distributed storage - - **Columnar Format** — Analytics optimized - - **Access Pattern** — Batch queries + + Twin Turbo consensus, the parallelization engine, and SeiDB: the system Giga supersedes. - + -**Cryptographic Layer** - - - - LSM-tree based - - - Compact proofs - - - Durability guarantee - - - -## Economic Model - -Sei operates with a native SEI token that serves multiple functions within the ecosystem: - -### Token Distribution - -- **Total Supply**: 10,000,000,000 (10 billion) SEI -- **Initial Distribution**: Allocated across ecosystem participants, validators, and development - -### Token Utility - -1. **Gas Fees**: All transactions require SEI for execution -2. **Staking**: Validators and delegators stake SEI to secure the network -3. **Governance**: SEI holders participate in protocol governance -4. **Rewards**: Block rewards and fee distribution to validators - -### Staking Mechanics - -**Staking & Validation** - - - - - **Self-Stake Requirement** — Minimum SEI to operate - - **Commission Rate** — Set by validator - - **Responsibilities** — Consensus & execution - - - - **Delegation** — Stake with chosen validators - - **Rewards** — Proportional to stake - - **Unbonding** — 21-day period - - - -**Slashing Conditions** - - - - Penalties for downtime - - - Severe penalties for double-signing - - - -## Developer Experience - -Sei maintains full EVM compatibility while providing enhanced capabilities: - -### Standard EVM Features - -- Complete support for Solidity and Vyper -- Standard JSON-RPC endpoints -- Compatible with existing tools (Hardhat, Foundry, Remix) -- Familiar development workflow - -### Enhanced Capabilities - -- Sub-second transaction finality -- Predictable gas costs -- High throughput for complex applications -- Advanced storage access patterns - -## Implementation Status - -**Current & Upcoming Features** - - - - - ~400ms blocks - - - Multi-core processing - - - Optimized state access - - - - - - - - Multi-proposer protocol - - - Performance target - - - Enhanced execution - - - - -## Learn More - -Explore the technical components that make Sei's performance possible: - -- [Twin Turbo Consensus →](/learn/twin-turbo-consensus) -- [Parallelization Engine →](/learn/parallelization-engine) -- [SeiDB Storage →](/learn/seidb) -- [Developer Guide →](/learn/sei-giga-developers) +_Last updated July 2026_ diff --git a/node/node-operators.mdx b/node/node-operators.mdx index 04e2fc6..3d2dd9b 100644 --- a/node/node-operators.mdx +++ b/node/node-operators.mdx @@ -518,14 +518,14 @@ worker_queue_size = 1000 ############################################################################### [giga_executor] -# enabled controls whether to use the Giga executor (evmone-based) instead of geth's interpreter. -# This is an experimental feature for improved EVM throughput. -# Default: false +# enabled controls whether to use the Giga executor instead of the legacy execution path. +# Improves EVM throughput. +# Default: false through v6.5.x; true from the v6.6 release line. enabled = false # occ_enabled controls whether to use OCC (Optimistic Concurrency Control) with the Giga executor. # When true, transactions are executed in parallel with conflict detection and retry. -# Default: false +# Default: false through v6.5.x; true from the v6.6 release line. occ_enabled = false ############################################################################### @@ -1450,10 +1450,9 @@ ss-keep-recent = 100000 # snapshot creation. ss-prune-interval = 600 -# Optional EVM SS routing — same semantics as the SC modes above. Leave on -# cosmos_only unless you have completed the Giga SS Store migration. -evm-ss-write-mode = "cosmos_only" -evm-ss-read-mode = "cosmos_only" +# EVM state-store split. Leave false unless you have completed the Giga +# SS Store migration (RPC nodes only); see the migration guide. +evm-ss-split = false evm-ss-separate-dbs = false [receipt-store] @@ -1470,45 +1469,33 @@ longer overall, which can cause missed blocks and excessive resync time. ### Giga Storage and Giga Executor -These are two **separate** opt-in features that ship in newer `seid` -releases. Both default to off; only enable them deliberately and after -following the relevant migration guide. +These are two **separate** features that ship in newer `seid` releases. **Giga Storage** repartitions SeiDB so EVM state lives in its own databases at both the SC and SS layers, freeing non-EVM modules from EVM -write amplification. - -For step-by-step instructions — including the full state-sync flow, startup verification, safety checks, and rollback — see the [Giga SS Store Migration Guide](/node/giga-storage-migration). The snippet below is just the resulting `app.toml` shape. - - -```toml -[state-commit] -sc-write-mode = "dual_write" # write EVM data to memiavl AND FlatKV -sc-read-mode = "split_read" # read EVM data from FlatKV -sc-enable-lattice-hash = true # required for split-mode app-hash equality - -[state-store] -evm-ss-write-mode = "split_write" -evm-ss-read-mode = "split_read" -``` - -Enabling Giga Storage requires a fresh state sync — flipping the EVM SS -modes on a node with existing data fails the startup safety checks because -the new EVM SS DB starts empty while Cosmos SS already has history. The -full procedure is in the -[Giga SS Store Migration Guide](/node/giga-storage-migration) and is +write amplification. It is opt-in on every release, and enabling it +requires a fresh state sync: turning on the EVM SS split on a node with +existing data fails the startup safety checks, because the new EVM SS DB +starts empty while Cosmos SS already has history. The full procedure, +including the exact `app.toml` keys, startup verification, safety checks, +and rollback, is in the +[Giga SS Store Migration Guide](/node/giga-storage-migration). It is currently supported on **RPC nodes only**; validators and archive nodes are not yet covered. -**Giga Executor** is independent of Giga Storage. It swaps the EVM -interpreter from go-ethereum's geth to an evmone-based executor for -higher throughput, with optional OCC parallelism on top: +**Giga Executor** is independent of Giga Storage. It routes EVM +transactions through the Giga execution engine, built on Sei's go-ethereum +fork, instead of the legacy execution path, with optional OCC parallelism +on top. It is disabled by default through v6.5.x and enabled by default, +together with OCC, from the v6.6 release line: ```toml [giga_executor] -# Use the evmone-based executor instead of geth's interpreter. Experimental. +# Use the Giga execution engine instead of the legacy path. +# Default: false through v6.5.x; true from the v6.6 release line. enabled = false # Run Giga-executed txs in parallel with Optimistic Concurrency Control. +# Default: false through v6.5.x; true from the v6.6 release line. occ_enabled = false ``` diff --git a/scripts/generate-llms.mjs b/scripts/generate-llms.mjs index c39db95..3d49503 100644 --- a/scripts/generate-llms.mjs +++ b/scripts/generate-llms.mjs @@ -28,7 +28,7 @@ const SEI_LLMS_CONFIG = { blockquote: 'Technical documentation for Sei — a parallelized EVM Layer 1 with sub-second finality, full Ethereum tooling compatibility, and a clear roadmap toward Sei Giga (200K TPS, 5 gigagas/s).', intro: - 'Sei is a parallelized EVM Layer 1 blockchain with 400ms finality, ~100 MGas/s throughput today, and full Ethereum tooling compatibility. Deploy standard Solidity contracts with no modifications. Chain ID: mainnet 1329, testnet 1328. The next major upgrade, Sei Giga, targets 200K TPS via Autobahn multi-proposer BFT consensus and a custom EVM execution engine.', + 'Sei is a parallelized EVM Layer 1 blockchain with 400ms finality, ~100 MGas/s throughput today, and full Ethereum tooling compatibility. Deploy standard Solidity contracts with no modifications. Chain ID: mainnet 1329, testnet 1328. The next major upgrade, Sei Giga, targets 200K TPS via Autobahn Multi-concurrent proposer BFT consensus and a custom EVM execution engine.', constraints: [ 'Prerequisites: Node.js ≥ 18, a wallet (Compass, Rabby, MetaMask, or any EVM-compatible wallet), and SEI tokens for gas.', 'Authentication: No API key is required for public RPC endpoints. Rate limits apply — use a dedicated provider (Ankr, DRPC, Nirvana) for production workloads.', @@ -138,7 +138,7 @@ const LLMS_SECTION_ORDER = [ match: (p) => p.startsWith('/learn'), overview: [ "Sei is a parallelized EVM Layer 1 blockchain. Performance comes from Twin Turbo Consensus (optimistic block processing), parallel EVM execution (concurrent transactions on independent state), and SeiDB (high-throughput storage). Full Ethereum tooling compatibility — deploy standard Solidity contracts with no modifications.", - "Sei Giga is the next major upgrade targeting 200K TPS and 5 gigagas/s via Autobahn multi-proposer BFT consensus and a custom EVM execution engine. For developers, Sei Giga's parallel engine rewards contracts with user-scoped state (mapping per address) over shared global state.", + "Sei Giga is the next major upgrade targeting 200K TPS and 5 gigagas/s via Autobahn Multi-concurrent proposer BFT consensus and a custom EVM execution engine. For developers, Sei Giga's parallel engine rewards contracts with user-scoped state (mapping per address) over shared global state.", 'Mainnet (pacific-1): chain ID 1329. Testnet (atlantic-2): chain ID 1328.', 'SIP-03 migration: inbound/outbound IBC transfers are being disabled. Holders of IBC assets must swap, migrate, or bridge out before the governance proposal activates.' ].join('\n\n') diff --git a/snippets/giga-diagrams.jsx b/snippets/giga-diagrams.jsx new file mode 100644 index 0000000..e9ba7a6 --- /dev/null +++ b/snippets/giga-diagrams.jsx @@ -0,0 +1,732 @@ +export const GigaProposerComparison = () => { + const ink = 'currentColor'; + const accent = 'var(--sei-maroon-50)'; + const box = { fill: ink, fillOpacity: 0.05, stroke: ink, strokeOpacity: 0.35, strokeWidth: 1 }; + const lanes = [0, 1, 2, 3]; + return ( +
+
+ + + + + + + + + + + Single proposer (Tendermint-style) + {lanes.map((i) => ( + + + V{i + 1} + + ))} + leader + {[0, 2, 3].map((i) => ( + + ))} + votes + + + block h + one block per round + + {[0, 1, 2].map((i) => ( + + + {['h-2', 'h-1', 'h'][i]} + + ))} + throughput capped by one leader's bandwidth + + + + Multi-concurrent proposer (Sei Giga) + {lanes.map((i) => ( + + + V{i + 1} + {[0, 1, 2].map((j) => ( + + + {j < 2 ? : null} + + ))} + + ))} + every validator streams its own lane + tips + + + + cut of tips + one consensus slot + commits all lanes + bandwidth scales with the validator count + +
+
One leader per height versus every validator proposing concurrently. In Giga, consensus commits a cut of all lane tips, so a single decision finalizes many blocks of data.
+
+ ); +}; + +export const GigaAsyncPipeline = () => { + const ink = 'currentColor'; + const accent = 'var(--sei-maroon-50)'; + const gold = 'var(--sei-gold-25)'; + const rows = [ + { y: 62, label: 'Ordering' }, + { y: 116, label: 'Execution' }, + { y: 170, label: 'Attestation' } + ]; + return ( +
+
+ + + + + + + {rows.map((r) => ( + + {r.label} + + + ))} + {[0, 1, 2, 3].map((i) => ( + + + order n{i > 0 ? '+' + i : ''} + + ))} + {[0, 1, 2].map((i) => ( + + + execute n{i > 0 ? '+' + i : ''} + + ))} + + attest n: 2/3 sign digest D_n + + + ordering finality for n + + attestation for n lags by x blocks + + state attestation finality for n + + + time + +
+
Consensus keeps ordering new blocks while earlier blocks execute and their divergence digests are attested. Ordering finality is the fast signal; state attestation follows a bounded number of blocks later.
+
+ ); +}; + +export const GigaTxJourney = () => { + const ink = 'currentColor'; + const accent = 'var(--sei-maroon-50)'; + const gold = 'var(--sei-gold-25)'; + const steps = [ + { t: 'submit', s: 'to any RPC node' }, + { t: 'lane', s: 'validator includes it' }, + { t: 'PoA', s: 'f+1 availability votes' }, + { t: 'ordered', s: 'cut committed' }, + { t: 'executed', s: 'merged, run in parallel' }, + { t: 'attested', s: 'digest signed by 2/3' } + ]; + return ( +
+
+ + + + + + + {steps.map((st, i) => { + const x = 76 + i * 150; + const strong = i === 3 || i === 5; + return ( + + {i < steps.length - 1 ? : null} + + {i + 1} + {st.t} + {st.s} + + ); + })} + ordering finality + + state attestation finality + + +
+
The six stops of a Giga transaction. There is no mempool: step 2 happens immediately, and step 4 fixes the order irrevocably.
+
+ ); +}; + +export const GigaRoadmapTrack = () => { + const ink = 'currentColor'; + const done = '#10b981'; + const prog = '#f59e0b'; + const items = [ + { l: 'WP v1', s: 'done' }, + { l: 'Devnet', s: 'done' }, + { l: 'WP v2', s: 'done' }, + { l: 'Ares', s: 'prog' }, + { l: 'Eidos', s: 'prog' }, + { l: 'SIP-3', s: 'prog' }, + { l: 'Autobahn testnet', s: 'next' }, + { l: 'Autobahn mainnet', s: 'next' }, + { l: 'Sedna', s: 'next' }, + { l: 'Hermes testnet', s: 'next' }, + { l: 'Hermes mainnet', s: 'next' } + ]; + return ( +
+
+ + + + + {items.map((it, i) => { + const x = 70 + i * 80; + const above = i % 2 === 0; + const c = it.s === 'done' ? done : it.s === 'prog' ? prog : ink; + return ( + + + {it.s === 'done' ? : null} + {it.s === 'prog' ? : null} + + {it.l} + + ); + })} + + complete + + in progress (July 2026) + + coming soon + +
+
The eleven roadmap milestones from giga.seilabs.io. Ares, Eidos, and SIP-3 are live workstreams on the network today; the Autobahn testnet is next.
+
+ ); +}; + +export const GigaLanesAndCuts = () => { + const ink = 'currentColor'; + const accent = 'var(--sei-maroon-50)'; + const box = { fill: ink, fillOpacity: 0.05, stroke: ink, strokeOpacity: 0.35, strokeWidth: 1 }; + const lanes = [0, 1, 2]; + return ( +
+
+ + + + + + + + + + + committing a tip implicitly commits everything behind it + {lanes.map((i) => ( + + + V{i + 1} + {[0, 1, 2, 3].map((j) => ( + + + pos {j} + batch + {j < 3 ? : null} + + ))} + tip + + ))} + arrows: parentRef hash-chains each proposal to its predecessor + + + + f + 1 votes + Proof of Availability + + + + + cut = [tip 1, tip 2, tip 3] + + + committed in one slot + Prepare, then Commit + + missing batch data is fetched after commit, + off the critical path + +
+
Each validator chains batches into its own lane and certifies them with f + 1 availability votes. Consensus only ever orders the vector of lane tips.
+
+ ); +}; + +export const GigaSlotPipeline = () => { + const ink = 'currentColor'; + const accent = 'var(--sei-maroon-50)'; + const slots = [0, 1, 2]; + return ( +
+
+ + + + + + + {slots.map((i) => { + const x = 130 + i * 105; + const y = 46 + i * 50; + return ( + + slot s{i > 0 ? '+' + i : ''} + + Prepare (PrepareQC) + + Commit (CommitQC) + + ); + })} + + next slot starts once the Prepare message for s is seen + + + 1 round trip + + +0.5 effective + steady state: 1.5 round trips per cut + +
+
Slots overlap: replicas begin slot s+1 as soon as they see the Prepare message for slot s, so the steady-state cost is 1.5 network round trips per committed cut.
+
+ ); +}; + +export const GigaAttestationFlow = () => { + const ink = 'currentColor'; + const accent = 'var(--sei-maroon-50)'; + const gold = 'var(--sei-gold-25)'; + const blocks = ['n-1', 'n', 'n+1', 'n+2', 'n+x']; + return ( +
+
+ + + + + + + + + + {blocks.map((b, i) => ( + + + block {b} + {i < blocks.length - 1 ? : null} + + ))} + ordering final + + + {[ + { x: 96, label: 'execute block n', sub: 'deterministic Apply' }, + { x: 296, label: 'write log', sub: 'last write wins' }, + { x: 496, label: 'd_n = LtHash(...)', sub: 'writes, receipts, gas' } + ].map((s, i) => ( + + + {s.label} + {s.sub} + {i < 2 ? : null} + + ))} + + + digest D_n + compact commitment + + 2/3-signed, included + in block n+x + + + signing two different digests for the same block is slashable equivocation; + divergence under 1/3 of validators isolates the fault, divergence over 1/3 halts the chain + +
+
Execution results are committed as a lattice-hash digest rather than a state root, and validators attest to that digest a bounded number of blocks later.
+
+ ); +}; + +export const GigaOccDiagram = () => { + const ink = 'currentColor'; + const accent = 'var(--sei-maroon-50)'; + const workers = ['worker 1', 'worker 2', 'worker 3']; + return ( +
+
+ + + + + + + {workers.map((w, i) => ( + + {w} + + + ))} + + t1 + + t2 writes k + + t3 + + t4 reads k + + t5 + + conflict + + + t4 re-executes + validation caught the stale read + + + + commit in block order + result identical to + sequential execution + + only conflicting transactions re-run; after 10 retries the implementation falls back to sequential execution + +
+
All transactions in a block start in parallel with private write buffers. Validation re-executes only those whose reads collided with an earlier transaction's writes.
+
+ ); +}; + +export const GigaStorageArchitecture = () => { + const ink = 'currentColor'; + const accent = 'var(--sei-maroon-50)'; + const gold = 'var(--sei-gold-25)'; + return ( +
+
+ + + + + + + state path + + execution: reads served from RAM + + + flat key-value store (LSM tree) + no per-write Merkle updates + + append-only WAL + crash recovery + + async + + + hot tier: local high-performance SSDs + + + cold tier: distributed columnar store + + commitment path + + write log of block n + + + lattice hash d_n (LtHash) + incremental, order-independent + + + D_n attested by 2/3 quorum + + disputes: compare chunk digests, + bisect, replay one range + +
+
The write path never touches a Merkle tree: state lives in a RAM-first flat store with an append-only WAL, while commitments come from a homomorphic lattice hash over each block's write log.
+
+ ); +}; + +export const GigaBudWindow = () => { + const ink = 'currentColor'; + const accent = 'var(--sei-maroon-50)'; + const gold = 'var(--sei-gold-25)'; + const leaves = ['(key a, value, n, prev)', '(key b, value, n, prev)', '(key c, value, n, prev)']; + return ( +
+
+ + + + + + + {leaves.map((l, i) => ( + + + {l} + + + ))} + this block's writes, sorted by key + + root U_n + + + attested with D_n + same 2/3 quorum schedule + + proof = Merkle path to attested U_n; + two proofs bracket an unmodified span + cost scales with the block's updates + + + {Array.from({ length: 17 }, (_, i) => ( + + ))} + blocks + {[0, 1, 2, 3].map((i) => ( + + ))} + SuperBUD, e blocks + + guaranteed proof window: the last e^Lmax blocks (governance-set); older claims need archive nodes + touch transactions refresh a stale key's anchor; deletions leave tombstones for exclusion proofs + +
+
Every block gets a Merkle root over just its own updates. SuperBUDs aggregate those roots over exponentially sized windows so provers cover long ranges with a handful of digests.
+
+ ); +}; + +export const GigaMergeRule = () => { + const ink = 'currentColor'; + const accent = 'var(--sei-maroon-50)'; + const lanesIn = [ + { v: 'V1', max: 12, txs: [{ n: 'a', t: 12 }, { n: 'e', t: 8, dup: true }] }, + { v: 'V2', max: 40, txs: [{ n: 'c', t: 40 }, { n: 'd', t: 9 }] }, + { v: 'V3', max: 20, txs: [{ n: 'f', t: 20 }, { n: 'e', t: 8 }] } + ]; + const sorted = [1, 2, 0]; + return ( +
+
+ + + + + + + new transactions per lane + {lanesIn.map((ln, i) => ( + + {ln.v} + max {ln.max} + {ln.txs.map((tx, j) => ( + + + {tx.n} · tip {tx.t} + + ))} + + ))} + + 1. sort lanes + by max tip + + lane order: V2, V3, V1 + {sorted.map((li, i) => ( + + {i + 1} + {lanesIn[li].txs.map((tx, j) => ( + + + {lanesIn[li].v}: {tx.n} + + ))} + + ))} + 2. intra-lane order preserved + + + 3. dedupe + executable sequence + {['c', 'd', 'f', 'e', 'a', 'e'].map((n, i) => { + const dup = i === 5; + return ( + + + {i + 1}. {n}{dup ? ' (duplicate hash)' : ''} + + ); + })} + dropped copy gets a partial tip refund + +
+
The merged order is a pure function of finalized lane contents: lanes sort by their highest included tip, order inside each lane never changes, and the first occurrence of a hash wins.
+
+ ); +}; + +export const GigaFinalitySignals = () => { + const ink = 'currentColor'; + const accent = 'var(--sei-maroon-50)'; + const gold = 'var(--sei-gold-25)'; + return ( +
+
+ + + + + + + + transaction lands + in a committed cut + + + + ordering finality + receipt available; no reorgs + + + trading UX, games, payments, + most dApp flows + + + + state attestation finality + 2/3-signed digest, x blocks later + + + exchange deposits, bridges, + high-value settlement, BUD proofs + + the outcome is already decided at ordering finality; attestation adds a signed confirmation of it + +
+
Two confirmation signals, two audiences: act on the receipt for interactive flows, and wait for the attested digest when third-party value moves on the result.
+
+ ); +}; + +export const GigaParallelismContrast = () => { + const ink = 'currentColor'; + const accent = 'var(--sei-maroon-50)'; + const users = [0, 1, 2, 3]; + return ( +
+
+ + + + + + + + + + isolated state: one wave + {users.map((i) => ( + + + tx{i + 1} + + + balances[user{i + 1}] + + ))} + disjoint write sets: all four execute simultaneously + + + + hot slot: one at a time + {users.map((i) => ( + + + tx{i + 1} + + + ))} + + totalTransfers++ + every transaction writes this slot, + so they re-run in sequence: 1, 2, 3, 4 + conflicting write sets: parallelism lost for the block + +
+
The same four transfers, two storage layouts. Per-user slots let Block-STM commit everything in one pass; a shared counter forces retries until the transactions run one by one.
+
+ ); +}; + +export const GigaFeeSplit = () => { + const ink = 'currentColor'; + const accent = 'var(--sei-maroon-50)'; + const gold = 'var(--sei-gold-25)'; + const parts = [ + { x: 60, w: 300, label: 'execution fee', sub: '1559-style base fee', to: 'pays for gas actually consumed', c: null }, + { x: 360, w: 240, label: 'ordering fee (tip)', sub: 'buys a position in the order', to: 'socialised: epoch pool, stake x liveness', c: 'accent' }, + { x: 600, w: 200, label: 'distribution fee', sub: 'prices duplicate copies', to: 'only one copy executes; partial refund', c: 'gold' } + ]; + return ( +
+
+ + {parts.map((p) => { + const fill = p.c === 'accent' ? accent : p.c === 'gold' ? gold : ink; + const op = p.c ? 0.16 : 0.06; + return ( + + + {p.label} + {p.sub} + + {p.to} + + ); + })} + one transaction, three priced things + tipping a specific proposer buys nothing: the pool pays validators by stake and measured liveness + +
+
Execution, ordering, and duplicate distribution are priced separately. The tip is strictly enforced for ordering and then socialised across the validator set.
+
+ ); +};