Skip to main content

​
The Challenge: Sequential Execution as a Bottleneck

In traditional blockchains, transactions are executed one by one in strict order. This model is simple and safe, but severely limits throughput. Even with many CPU cores available, only one is used for transaction execution, so block execution time grows linearly with the number of transactions.

​
The Solution: Optimistic Parallelization

OpenGDP overcomes this limitation with a parallel execution engine inspired by Block-STM. The engine assumes that most transactions will not conflict and executes them concurrently across all available CPU cores. The fixed block transaction order for conflicting transactions is maintained through the process of parallelization. The final state always matches what a purely sequential execution would have produced, but this process is significantly faster.

​
How It Works: The Three-Phase Model

The protocol automatically manages execution through a repeating cycle of three phases. Developers do not need to handle this process manually.
  • Phase 1: Optimistic Execution
    • Transactions are dispatched to multiple threads and executed concurrently.
    • Writes are handled with a multi-version data store. Each write creates a new temporary version tagged with the transaction ID, rather than overwriting the old value.
    • Reads always fetch the latest version created by a prior transaction in the block order, ensuring consistency with sequential semantics.
  • Phase 2: Validation
    • After execution, the transaction’s read-set is checked against earlier writes in the block order.
    • If a transaction reads stale data, such as reading a value that is later updated by an earlier transaction, the transaction’s validation fails.
  • Phase 3: Re-execution and Commit
    • Transactions that fail validation are re-executed, and any dependent transactions are re-validated.
    • If a transaction failed earlier, its write-set is stored in memory so as to minimize the number of re-executions.
    • Once validated, and after all preceding transactions have also been validated, the results are committed to the final block state.
This cycle repeats until all transactions are validated and committed. Only conflicting transactions are re-executed, restricting wasted work to a minimum.
Parallel execution works transparently with no changes required to smart contracts. EVM compatibility remains complete. However, developers can design more efficient applications by minimizing contention on shared state. Transactions that operate on disjoint data sets will never conflict, reducing the chance of re-execution and maximizing throughput.