Run your node and every block splits into an EVM lane and a Cosmos lane, each scheduled on its own optimistic concurrency controller. Transactions that touch disjoint state execute at the same time, so block execution is not limited to a single core. The scheduler detects conflicts against a multiversion store and re-executes only the affected transactions. After ten scheduling iterations it finishes the rest sequentially, and an aborted EVM transaction sends the whole block back to the V2 path.

What it does

The Paxeer chain splits every block into EVM entries and non-EVM entries and runs each group through its own Block-STM-style optimistic concurrency control (OCC) scheduler. The EVM group runs first against a discardable cache using the Giga executor, and its writes are committed to the main store before the Cosmos group runs. Conflicts are detected against a multiversion store and the affected transactions are re-executed; after ten scheduling iterations the scheduler stops retrying and finishes the remaining transactions sequentially. If any EVM transaction returns the Giga abort code, every EVM change is discarded and the whole block is re-run through the legacy V2 execution path.

Key capabilities

• Partitions each block into an EVM lane and a Cosmos lane, each scheduled separately.
• Detects read and write conflicts against a multiversion store and re-executes only affected transactions.
• Reverts to sequential execution after ten scheduling iterations on high-conflict blocks.
• Discards the EVM lane and replays the whole block on the V2 path when a transaction aborts.
• Sizes its worker pool from the host CPU count, with an operator override.
• Records conflict counts, retries and fallbacks as node metrics.

Differentiators

Two independent schedulers per block, one per execution lane, with a block-level rollback that discards the parallel EVM results and replays the block on the older sequential engine. Correctness is checked by comparing whole-store state between a sequential run and repeated shuffled parallel runs, not only transaction receipts.

Outcomes

• Disjoint transactions in a block execute at once, not one after another.
• High-conflict blocks fall back to sequential execution after ten iterations.
• Node metrics record conflict counts, retries and fallbacks to V2.

Technical notes

• On by default at both layers: app keys occ-enabled and concurrency-workers (default max(10, min(2 × NumCPU, 128))), engine keys [giga_executor] enabled and occ_enabled.
• Routing order is Giga with OCC, then Giga sequential, then V2 sequential, then V2 with OCC; paxd blocktest forces both Giga keys off so block tests use the reference EVM path.
• All EVM transactions must precede any Cosmos transaction in a block; otherwise the block is routed to the V2 OCC path.
• A block of 64 or more plain value transfers to one recipient is executed synchronously to avoid conflict thrashing; fallbacks to V2 are counted by app_giga_fallback_to_v2.
• The EVM module enforces no block-level gas limit, only per-transaction limits, and allows one hop of writable internal call; self-destruct is not supported on the Giga path and sends the block back to V2.
• The Giga block path builds its executor on go-ethereum. The evmone library is loaded best effort at node start and the block path does not use it. Enabling the Giga executor also turns off last-results-hash validation.

More in Paxeer chain