Autobahn Consensus

Autobahn is a high-throughput consensus protocol built around multiple concurrent proposers and a Proof of Availability (POA) mechanism that decouples data dissemination from consensus ordering. It is the consensus engine powering Sei Giga (next-generation Sei chain), the first claimed production deployment of Autobahn as of August 2025. (→ NoConsensus.wtf 2025 — Overview)

Core Design

Problem with single-proposer consensus: one validator gathers all transactions, assembles a block, and broadcasts it. This is a bottleneck: the proposer’s bandwidth is the system’s bandwidth ceiling, and broadcasting a large block consumes much of the consensus time budget.

Autobahn’s solution: multiple concurrent proposers, each operating their own independent lane.

Key Mechanism: Proof of Availability (POA)

  1. Each proposer broadcasts their block to all validators.
  2. Proposer collects f+1 signed votes attesting that at least one honest validator received the full block data.
  3. This POA proof guarantees the block is retrievable — someone honest has it and can serve it on request.
  4. Consensus proceeds on tip cuts (collections of block hashes from all lanes) — only hashes and votes, not full blocks.
  5. Execution is async: happens after consensus commits, can be pipelined.

Why this matters: block data (expensive to transmit) and consensus ordering (requires only hashes) are handled independently. The consensus protocol sees only small messages; data propagation scales horizontally with the number of validators.

Pipeline

[Propose] → [POA: F+1 votes on full block] → [Aggregate tip cuts] 
         → [1.5 RTT consensus on hashes only] → [Commit snapshot]
         → [Async execution]

Each stage can be pipelined: tip cut aggregation begins before POA completes. Block execution begins before the next consensus round’s POA.

Sei Giga: Production Deployment

Sei Labs (Kartik, founding engineer) deployed Autobahn in Sei Giga — their claim is it’s the first chain to battle-test Autobahn in a real network.

Published specs for Sei Giga:

  • Throughput: 5 Ggas / 200,000 TPS.
  • Finality: <400 ms.
  • Consensus: Autobahn with async execution.

Caveat: The benchmark used mocked execution — the 200k TPS figure reflects consensus + data throughput only, not full EVM execution. Real-world throughput with live execution is unknown.

Benchmark setup (load test, August 2025):

  • 30 geo-distributed validators across 15 AWS regions.
  • Workload: ~180k ERC-20 transactions, ~5 Ggas.
  • Block size: 1,500–3,000 transactions/block.
  • Execution mocked — focus purely on data and consensus path.
  • Fault injection: 10%, 20%, 30% offline validators.

Roundtrip latency (time to disseminate blocks to 2/3 of honest validators):

  • 0% faults: ~150 ms.
  • 30% faults: ~246 ms.
  • Theoretical model from the Autobahn paper matches empirical results within ~10% error.

Bandwidth: ~400 Mbps egress per validator during the benchmark. This is intentionally limited — the execution throughput ceiling was hit first. Theoretical: up to ~10 Gbps if execution is negligible and hardware is scaled.

Latency scaling anomaly: past ~100 validators, end-to-end latency increases for unknown reasons. Under investigation (Sei + Sui research collaboration). Current hypothesis unknown — the 1.5 RTT consensus or the POA step may have sublinear scaling issues.

Bandwidth Analysis

Bandwidth per validator scales with:

  • Block distribution (POA phase): O(N) blocks to distribute, O(N) validator signatures to collect = O(N²) total work.
  • Tip cut consensus: O(N²) in hashes and votes only (not full blocks) — much smaller.

More validators = more total bandwidth consumed by the system, but also more concurrent block producers, so throughput scales proportionally. The tradeoff is per-node bandwidth (400 Mbps) stays roughly constant as you add validators.

MEV Implications

Multi-proposer introduces new MEV vectors compared to single-proposer:

  • Within a lane: ordering is sequential, similar to single-proposer.
  • Across lanes: no defined canonical ordering until the tip cut is finalized. Transactions landing in different lanes can interact in undefined order.
  • Privacy-preserving DA: encrypted blocks are a future direction to mitigate MEV at the data layer — proposers wouldn’t reveal transaction contents until after ordering is committed.

The multi-proposer model doesn’t eliminate MEV; it changes its structure. Research ongoing.

Connection to Probabilistic Censorship Resistance

With multiple concurrent proposers, a user can send their transaction to multiple proposers simultaneously. The probability that all of them censor the transaction (required for the censorship to succeed) decreases with the number of honest proposers. This is probabilistic censorship resistance — weaker than the leaderless attestation primitive discussed in Censorship Resistance in Consensus Protocols but structurally better than single-proposer protocols.

Connections

Open Questions

  • Why does end-to-end latency degrade past ~100 validators? Is it the POA step, the tip cut aggregation, or something in the execution pipeline?
  • How do MEV interactions across lanes get resolved? Does the tip cut ordering create exploitable ordering games?
  • Is 5 Ggas / 200k TPS the actual throughput of Sei Giga with real execution, or only with mocked execution?
  • Does Autobahn’s probabilistic censorship resistance meet the STCR requirements for on-chain auctions?