Skip to content

A runtime execution model that allows blockchain transactions to be executed in parallel speculatively, while ensuring a deterministic final order. It reduces lock contention, adapts throughput dynamically to network conditions, and improves stability under high load without sacrificing consensus safety.

Notifications You must be signed in to change notification settings

xKal3b/DSS---Deterministic-Speculative-Scheduling

Repository files navigation

DSS---Deterministic-Speculative-Scheduling for Solana

A runtime execution model that allows blockchain transactions to be executed in parallel speculatively, while ensuring a deterministic final order. It reduces lock contention, adapts throughput dynamically to network conditions, and improves stability under high load without sacrificing consensus safety.

............................................

Deterministic Speculative Scheduling (DSS)

Deterministic Speculative Scheduling (DSS) is a new runtime model for Solana-style blockchains. It improves throughput and stability by executing transactions speculatively in parallel, while committing results in a deterministic final order.

Problems and bottlenecks in Solana

Solana’s Sealevel runtime already supports parallel execution, but in practice it runs into bottlenecks because:

  1. Lock contention • Transactions that access the same account can’t run in parallel. • When contention spikes (NFT mints, liquidations, meme coin rushes), throughput drops sharply.

  2. Static batching / slot sizing • The runtime schedules transactions in fixed-size “windows” (slots). • If the window is too small → wasted capacity during high load. • If it’s too large → validators choke on validation and execution.

  3. Non-deterministic ordering risks • Parallelism introduces race conditions: two validators might produce different final orderings if execution isn’t tightly controlled. • Solana solves this today by being conservative → which reduces parallel efficiency.

Why DSS?

  1. Speculative parallel execution • Transactions are allowed to run in parallel even if they might conflict. • If a conflict is detected, DSS rolls back only the colliding transactions (not the whole batch). • This reduces idle cores and wasted cycles from waiting.

  2. Adaptive window sizing • Instead of a one-size-fits-all slot, DSS dynamically adjusts batch size based on: • Network conditions (latency, congestion) • Validator hardware capacity (fast nodes can do bigger windows) • Transaction type mix (DeFi vs. NFTs vs. payments) • This keeps the pipeline “right-sized” → smooths out throughput, avoids sudden congestion cliffs.

  3. Deterministic ordering preserved • Even with speculation, DSS enforces a canonical order in the final ledger. • All validators converge to the same state → no consensus breaks.

Benefits of DSS 🚀

  • +15–20% throughput under stress (NFT mints, liquidation cascades).
  • Lower latency variance → smoother p95/p99.
  • Adaptive scaling based on hardware + network conditions.

📌 Key Features

  • Speculative parallel execution.
  • Deterministic final ordering.
  • Adaptive execution window sizing.

📬 Contact

Author: Kaleb Barnhart X (@xkal3b)
💬 Telegram: @kb441


⚠️ Disclaimer: DSS is experimental. Results are based on synthetic simulations; real-world validator performance may vary.

About

A runtime execution model that allows blockchain transactions to be executed in parallel speculatively, while ensuring a deterministic final order. It reduces lock contention, adapts throughput dynamically to network conditions, and improves stability under high load without sacrificing consensus safety.

Topics

Resources

Stars

Watchers

Forks

Releases

No releases published

Packages

No packages published