Skip to main content

​
Introduction

Many blockchain systems use traditional sequential execution models. The Sei parallelization engine is a core component designed to increase transaction processing throughput beyond the limits of these models. The engine executes non-conflicting transactions in a block concurrently. It uses multi-core processors to improve performance and scalability. This page gives a technical explanation of its architecture and mechanisms.
The parallelization engine lets Sei process transactions concurrently across multiple CPU cores. This significantly increases throughput, and the outcomes stay deterministic and identical to sequential processing.

​
Core mechanism: optimistic concurrency control

The parallelization engine uses an Optimistic Concurrency Control (OCC) strategy. Pessimistic approaches lock state resources before execution. OCC instead lets transactions execute in parallel, based on an initial estimation of the state they will access. Conflicts (for example, two transactions that write to the same state key) are detected during or after this parallel execution phase. When conflicts occur, the engine resolves them, often by re-executing the conflicting transactions. This approach minimizes overhead when conflicts are infrequent and increases overall throughput.

​
System architecture

Sei parallelization engine

Transaction preprocessing

  • Classifier
  • Batch formation
  • Gas estimation

Dependency analysis

  • Access analysis
  • Dependency mapping
  • Contract interaction

Parallel execution

  • Worker pool
  • State transitions
  • Speculative execution

Conflict resolution

  • Conflict detection
  • Sequential re-execution

SeiDB & consensus

  • State Commit
  • MVCC support
This architecture lets Sei process transactions in parallel and keep the results consistent and correct.

​
1. Transaction preprocessing

Before execution can begin, incoming transactions go through preparatory processing. The system converts raw transaction bytes into structured transaction objects. These objects let the system identify message types and transaction characteristics. Initial validation also happens at this stage, through ante handlers that verify signatures, fees, and other prerequisites. The system also identifies certain critical transactions, such as oracle price feed updates. These transactions may need prioritized execution so that their data is processed on time. Based on this initial analysis, the system groups transactions into batches for later processing stages. This step is the basis for parallel execution.

​
2. Dependency analysis (estimation)

This stage is the backbone of the OCC approach. The system estimates potential state accesses for each transaction instead of determining exact dependencies. An access control module analyzes each transaction to predict which state keys it might read or write during execution. Specialized Dependency Generator functions predict potential state access patterns for each transaction type. The precision of this analysis depends on transaction complexity: For simple transactions such as token transfers, the system can determine precisely which account balances the transaction will access. For complex smart contract interactions, it is much harder to predict all potential storage accesses. For these complex cases, the generators give broader estimates that acknowledge areas of uncertainty. For example, a token transfer between accounts A and B generates estimated read-write sets that include:
  • Read access to account A’s balance
  • Read access to account B’s balance
  • Write access to account A’s balance
  • Write access to account B’s balance
  • Read access to any related metadata or configuration
The dependency analyzer might also consider secondary effects such as:
  • Fee payment impacts on the transaction sender’s account
  • Potential interactions with staking or governance mechanisms if the tokens have such properties
For smart contract calls, the analyzer uses heuristic methods that consider these inputs:
  • The contract’s address and storage layout
  • The specific function selectors being called
  • Any parameters passed to the contract functions
  • Historical patterns of state access from previous similar calls
The dependency generator outputs an estimated read-write set for each transaction. These sets contain the state keys that the transaction is expected to access. They also carry metadata for each prediction: the access type (read or write) and a confidence level. The system uses these confidence levels in scheduling decisions to minimize the likelihood of conflicts. The output of this phase is an “estimated writeset” for each transaction. The writeset predicts the transaction’s effect on state. It is an important input for the next phase, execution planning.

​
3. Parallel execution

The system uses the estimated writesets to attempt concurrent execution in these steps:
  1. Batch organization: The system organizes transactions and their associated writesets for processing.
    • Transactions are grouped logically, based on estimated dependencies
    • The system creates execution units with appropriate metadata
    • Priority queues determine processing order for maximum throughput
    • Metadata tags track transaction relationships for later conflict analysis
  2. Worker assignment: A pool of execution workers (typically implemented as goroutines) is ready to process transactions concurrently.
    • The worker pool size adapts dynamically to system resources
    • CPU core allocation strategies optimize for NUMA architectures
    • Specialized workers can execute specific transaction types
    • Load balancing algorithms redistribute work for maximum resource use
  3. Strategic scheduling: The scheduler assigns transactions to workers based on estimated writesets and groups non-conflicting transactions together.
    • Graph-based scheduling algorithms minimize potential conflicts
    • The scheduler includes lookahead capabilities for multi-step dependency chains
    • Execution time estimates prioritize shorter transactions when appropriate
    • Locality-aware scheduling places related transactions on the same worker when beneficial
  4. Buffered execution: Workers execute transactions and write all state modifications to a temporary buffer instead of the main state store.
    • Each worker keeps an isolated transaction context
    • The execution engine applies gas metering and limits
    • Buffered state operations capture all read and write operations
    • Intermediate results remain isolated until conflict detection completes
  5. Runtime tracking: The system monitors which state keys are read and written during execution. This builds an accurate picture of the real (versus estimated) state access patterns.
    • Access tracking captures both direct and indirect state interactions
    • Runtime statistics feed back into the dependency estimation system
    • Execution anomalies trigger adaptive scheduling adjustments
    • Performance metrics identify optimization opportunities
The engine uses these advanced techniques to maximize parallelism:
  • Adaptive batch sizing based on system load and conflict rates
  • Predictive execution of high-probability transaction paths
  • Distributed execution capabilities across multiple physical nodes when available
  • Resource throttling to prevent worker starvation

​
4. Conflict detection & resolution

The system must identify and resolve any conflicts that appear during and after parallel execution. The process has these steps:
  1. Conflict identification: The system compares the actual read-write sets recorded during execution. A conflict exists when one transaction reads state that another concurrent transaction wrote, or when multiple transactions write to the same state key. The conflict detector implements several optimized algorithms:
    • A hash-based data structure tracks state accesses in memory for efficient lookup
    • Bloom filters run fast preliminary conflict checks
    • A deterministic conflict resolution order prevents cyclic dependencies during re-execution
    • Precise timestamp tracking makes sure that sequencing follows arrival order
    Common conflict patterns include:
    • Read-After-Write (RAW): Transaction B reads a key that Transaction A has modified
    • Write-After-Read (WAR): Transaction B modifies a key that Transaction A has read
    • Write-After-Write (WAW): Multiple transactions try to modify the same key
  2. Conflict resolution: When the system detects conflicts, it runs a resolution strategy:
    • It identifies the conflicting transactions as a group
    • It removes their results from the temporary state buffer
    • It re-executes the conflicting set in a deterministic, sequential order to make sure the results are correct
    The deterministic order depends on these transaction prioritization rules:
    • Critical system transactions get the highest priority
    • Oracle updates and price feeds get elevated priority
    • Standard transactions follow their original sequence in the block
    • Gas price and other economic factors may influence the ordering
    The resolution system keeps its isolation guarantees through careful state management:
    • Conflict groups remain isolated from successfully processed transactions
    • The temporary buffer preserves successfully executed state transitions
    • Resolution attempts track their own read-write sets to detect cascading conflicts
This conflict resolution makes the final state after parallel execution identical to the state that sequential processing would produce. This keeps the blockchain consistent.

​
5. Fallback mechanism

The OCC approach includes a safety mechanism for situations where parallel execution cannot succeed:
  1. Failure detection: The system detects a failure condition when parallel execution encounters excessive conflicts or critical errors.
  2. State rollback: The system discards all state changes from the failed parallel attempt.
  3. Sequential reprocessing: As a fallback, the system processes the entire transaction batch sequentially.
This fallback guarantees that the chain can always make progress, even in worst-case scenarios where parallelization is ineffective for a particular block.

​
Interaction with SeiDB

The parallelization engine works closely with SeiDB, Sei’s custom storage layer. SeiDB’s State Commit layer gives the low-latency read and write access that concurrent execution at high transaction volume needs. Its asynchronous commit also lets block state finalize quickly. This creates an efficient pipeline for block processing. SeiDB integration has several technical advantages for parallelization: Performance optimizations:
  • Multi-version concurrency control (MVCC) at the storage level supports multiple execution attempts
  • Lock-free read operations prevent stalls during parallel transaction execution
  • Memory-mapped state caching reduces I/O overhead for frequently accessed keys
  • Batch commit optimizations minimize disk write amplification
Parallelization-specific features:
  • Snapshot isolation gives each transaction execution a consistent view of state
  • Atomic multi-key operations keep multi-part state transitions consistent
  • Versioned state access supports concurrent reads of different state versions
  • Optimized rollback lets the engine discard speculative state changes quickly
Storage architecture alignment:
  • The key-value structure mirrors the state access patterns in the dependency analysis
  • Prefix-based organization aligns with contract and module-based access patterns
  • Hybrid storage tiers optimize for different access patterns across workloads
  • Asynchronous persistence decouples block execution from storage commit latency
The tight integration between the parallelization engine and SeiDB lets the system maintain high throughput. This holds even under challenging workloads with complex dependency patterns or high conflict rates.

​
Performance impact

The parallelization engine improves performance significantly: These improvements scale with CPU core count. Sei can therefore take full advantage of modern server hardware.