Stable EVM
Future Roadmap 1: Optimistic Parallel Execution
Historically, blockchain systems have relied on sequential execution, where each transaction is processed one after another to ensure deterministic state across all nodes. While this design guarantees consistency, it also creates a severe limitation in throughput and scalability, especially as modern blockchains aim to support tens of thousands of transactions per second. To overcome this constraint, Stable is adopting Block-STM, a proven parallel execution engine that enables Optimistic Parallel Execution (OPE). This allows transactions to be executed in parallel while preserving determinism, significantly enhancing performance.How Block-STM Works
Block-STM utilizes an optimistic concurrency control mechanism: transactions are first executed in parallel under the assumption that they won’t conflict. Then, during a validation phase, any conflicts are detected and handled through re-execution. The process relies on the following five key techniques: 1. Multi-Version Memory Structure Block-STM stores multiple versions of each memory key:- Each transaction reads the latest version committed by prior transactions.
- During execution, both reads and writes are versioned.
- Later, during validation, these versions are checked for consistency to detect conflicts.
- During execution, each transaction logs the keys and versions it reads in a Read-Set.
- At the end of execution, it records its Write-Set into the multi-version memory.
- During validation, if another transaction has modified any key in the Read-Set, the transaction is considered to have conflicted, is aborted, and then re-executed with an incremented incarnation number.
- When a transaction fails, its Write-Set is marked with an ESTIMATE flag.
- If another transaction reads an ESTIMATE-marked value, it immediately halts and waits for re-execution (triggered by a
READ_ERROR). - This helps reduce overhead by quickly identifying dependencies without re-executing the full transaction set.
- All transactions within a block are executed according to a preset, deterministic order.
- Validation and commit stages also follow this same order.
- This ensures that even with parallel execution, all nodes reach the same final state.
- A Collaborative Scheduler distributes tasks between execution and validation workers in a thread-safe manner.
- It prioritizes lower-index transactions to accelerate early commits and minimize re-execution.
- The scheduler manages transaction incarnations for repeated attempts until they commit successfully.
Key Benefits of Block-STM
- Parallelism Without Locks: By leveraging MVCC (Multi-Version Concurrency Control), Block-STM allows multiple transactions to read and write concurrently without the need for mutex locks. Conflicts are only checked after execution, allowing maximum throughput during the initial processing phase.
- Minimal Overhead via ESTIMATE Markers: Failed transactions flag their Write-Sets with ESTIMATE markers, signaling dependent transactions to pause early, avoiding wasted execution. This results in faster convergence on valid execution paths.
- Efficient Scheduling and Prioritized Commits: Using the Collaborative Scheduler, the system minimizes retries by committing lower-index transactions first. This improves overall throughput and shortens execution cycles.
- Determinism and Consensus Compatibility: Because every transaction adheres to a fixed order, even re-executed transactions ultimately commit in the same sequence. This ensures safe and deterministic state agreement across all nodes, preserving consensus integrity even in a parallelized environment.
OPE on Stable
About OBP
- OBP is not about parallelism, but about execution timing.
- During the
ProcessProposalstage, Stable pre-executes blocks while they are being gossiped to other nodes. - The resulting state is cached in memory and reused during
FinalizeBlock, saving time and reducing duplicate computation.