[Paper] Sedna: Sharding transactions in multiple concurrent proposer blockchains

Source: arXiv - 2512.17045v1

Overview

Sedna tackles a hidden bottleneck in modern multi‑proposer blockchains: how users should ship their transactions to many concurrent proposers without blowing up bandwidth or exposing transaction data to front‑running (MEV). By replacing blind replication with a clever, verifiable rateless coding scheme, Sedna lets users send small “symbol” fragments to a subset of proposers while still guaranteeing that the transaction will be executed once enough symbols are collected. The result is a protocol that dramatically cuts bandwidth, improves censorship resistance, and reduces MEV exposure—all without touching the underlying consensus engine.

Key Contributions

• Rateless coding for transaction dissemination – Introduces a verifiable, on‑the‑fly coding technique that lets users split a transaction into an unlimited stream of symbols, each of which can be sent to any proposer.
• Until‑decode privacy – Guarantees that transaction contents remain private to the user until the network has gathered enough symbols to reconstruct it, limiting the window for MEV attacks.
• Formal liveness proof – Shows that, under standard network assumptions, Sedna always makes progress (transactions eventually decode and execute).
• Near‑optimal bandwidth overhead – Analytical proof that Sedna’s overhead approaches the information‑theoretic lower bound, achieving a 2‑3× improvement over naïve full‑transaction replication.
• Zero‑change deployment – Designed to sit on top of existing multi‑proposer consensus protocols, requiring no changes to the blockchain’s core consensus logic.

Methodology

1. Transaction Encoding – A user takes a transaction payload and runs a rateless erasure code (e.g., fountain codes) to generate an unbounded sequence of symbols. Each symbol is a small, independent piece that can be verified against a short commitment published on‑chain.
2. Targeted Delivery – Instead of broadcasting the whole transaction to every proposer, the user privately forwards a bundle of symbols to a chosen subset of proposers (e.g., a random 10‑20 % of the total). The selection can be tuned for latency vs. bandwidth.
3. Deterministic Execution Order – Proposers include the received symbols in their blocks. Once the blockchain finalizes enough distinct symbols to satisfy the decoding threshold, any node can reconstruct the original transaction and execute it in a deterministic order agreed by the consensus layer.
4. Verification & Privacy – Each symbol carries a proof (e.g., a Merkle proof) that it belongs to the original transaction commitment. Until the decoding threshold is met, the symbols reveal no useful information, providing until‑decode privacy.

The authors formalize the protocol, model the network as an asynchronous but partially synchronous system, and prove both safety (no double‑spending) and liveness (transactions eventually decode). They also derive the bandwidth overhead analytically and compare it to the optimal bound.

Results & Findings

The simulations confirm that Sedna’s bandwidth savings hold across a range of network sizes and proposer counts, while the privacy guarantees effectively shrink the attack surface for MEV bots.

Practical Implications

• Cost‑effective scaling – Developers building dApps on multi‑proposer chains can reduce transaction fees tied to network bandwidth, especially important for high‑throughput use cases (e.g., gaming, DeFi aggregators).
• Stronger censorship resistance – By allowing users to target only a subset of proposers, Sedna sidesteps the “all‑or‑nothing” replication model, making it harder for a coalition of proposers to block a transaction without colluding with a majority.
• MEV mitigation as a service – Wallet providers could integrate Sedna as a default “privacy‑by‑coding” layer, offering users automatic protection against front‑running without needing separate mixers or rollups.
• Incremental rollout – Since Sedna sits above the consensus layer, existing blockchains can adopt it via a soft‑fork or even an off‑chain client upgrade, avoiding disruptive hard forks.
• Developer ergonomics – The protocol can be exposed through simple SDK calls (encodeTx, sendSymbols, awaitDecode) that abstract away the coding details, making it as easy as a regular transaction submission.

Limitations & Future Work

• Parameter tuning – Choosing the optimal subset size and symbol rate depends on network latency, proposer churn, and desired latency guarantees; misconfiguration could increase confirmation times.
• Prover verification overhead – Each proposer must verify symbol proofs, which adds a modest CPU cost that scales with the number of symbols received.
• Security assumptions – The privacy guarantee holds until the decoding threshold is met; a highly adversarial proposer set that colludes early could still glean partial information.
• Empirical deployment – The paper’s evaluation is simulation‑based; real‑world testing on a live multi‑proposer chain (e.g., Avalanche, Solana) is needed to validate performance under adversarial network conditions.
• Extending to cross‑shard transactions – Future work could explore how Sedna’s coding approach interacts with sharded execution environments, potentially enabling privacy‑preserving cross‑shard communication.

Sedna opens a promising path toward more efficient, private, and censorship‑resistant transaction propagation in the next generation of multi‑proposer blockchains. As developers look for ways to tame MEV and bandwidth costs, integrating a rateless‑coding layer could become a practical, standards‑compatible solution.

Authors

• Alejandro Ranchal‑Pedrosa
• Benjamin Marsh
• Lefteris Kokoris‑Kogias
• Alberto Sonnino

Paper Information

• arXiv ID: 2512.17045v1
• Categories: cs.CR, cs.DC
• Published: December 18, 2025
• PDF: Download PDF