Status: Future Work (Not Active)

[AlphaB135]

This is a long-term roadmap item for BitQuan's evolution.

Current Status: ON HOLD - waiting for:

• v1.0.0 mainnet stable (6+ months runtime)
• Security audits complete (x2 minimum)
• P0/P1 tasks finished (wallet encryption, TLS, JWT)
• Community feedback collected

Timeline: Earliest start date: 2027 Q4 (depends on prerequisites)

Prerequisites:

• Issue Epic: Smart Contract Capability #59 (WASM Smart Contracts) must be complete and stable
• Issue Epic: State Management & Pruning #60 (State Pruning) must be deployed to mainnet
• Mainnet must demonstrate sustained load (1000+ TPS) that justifies parallelization

Contribute:

• Discuss design tradeoffs in comments
• Research similar implementations (Aptos Block-STM, Solana Sealevel, Sui parallel execution)
• Prototype proof-of-concepts in separate branch
• Write specs/RFCs for review

DO NOT: Start implementation yet - premature optimization kills projects.

---

Research Notes

Implementations to Study:

• Aptos Block-STM (Rust)
  • Repo: https://github.com/aptos-labs/aptos-core
  • Paper: https://arxiv.org/abs/2203.06871
• Solana Sealevel VM (Rust)
  • Parallel execution via account locks
  • Lesson: determinism issues in past
• Sui Move Parallel Execution
  • Object-centric model (different from UTXO)

Open Questions:

1. How to handle WASM contract calls in parallel?
   • Aptos uses Move (deterministic by design)
   • BitQuan uses WASM (needs sandboxing)
2. Determinism testing strategy?
   • Need CI infrastructure for multi-arch testing (x86_64, ARM64, different CPU counts)
3. Dependency analysis for UTXO vs Account model?
   • UTXO easier (explicit dependencies)
   • Account model needs speculation

Potential Blockers:

• WASM VM not thread-safe - need instance pooling
• Reorg with parallel state - complex rollback logic
• Cost of re-execution if too many conflicts
• Non-determinism sources: thread scheduling, hashmap iteration, floating point

Success Criteria:

• Determinism: 10,000+ runs produce identical block hash on different hardware
• Performance: 4x+ speedup on 8-core CPU (50%+ parallel efficiency)
• Safety: 1,000+ hours fuzzing with zero panics
• Reorg safety: parallel blocks can be reverted cleanly
• External audit: 0 critical, 0 high findings

---

Contributors: Add links, papers, or ideas below

---

Original Task List

Goal: Transform the transaction execution model from sequential to concurrent, aiming for 50,000+ TPS using all available CPU cores.

Core Concept: Adopt Block-STM (Optimistic Concurrency Control) as the foundational model.
Tech Stack: Rust, Rayon, DashMap/ArcSwap

Task List (to break into separate issues):

• Refactor the main execution loop to use par_iter() (Rayon Parallel Iterator) instead of a standard for loop.
• Implement temporary MVCC (Multi-Version Concurrency Control) memory structure so each thread can read/write state without immediate conflicts.
• Build a Dependency Analyzer to detect transaction conflicts (e. g., multiple transfers to the same recipient in parallel).
• Implement logic to re-execute only conflicting transactions after the initial execution round.
• Write determinism test cases to ensure that 100 rounds on different hardware always yield the same block hash.