Architecture · Explanation
Deterministic execution across CPU and GPU lanes
The executor may overlap verification, classify independent work, and use GPU execution, but the result must match the chain's ordered transaction semantics. Hardware completion order is never permission to change which transaction reads or writes an account first.
The useful question is therefore not “does this run in parallel?” It is “which state snapshot does this operation read, and where are its effects ordered?” This chapter follows those boundaries inside TurboExecutor. For an application-level example of staged reads and rollback, start with cross-VM composition.
Establish the block's state before running contracts
The reporter supplies a finalized block height and recorded timestamp. The executor builds deterministic bank sysvar changes, including the clock, from that context. An enabled HILSA interop snapshot is also derived from already-committed state. These changes belong in the common commit path even for an empty transaction block.
The executor resets its per-block cross-VM claim registry and authorized capability-vault draw accumulator before processing the block. These are execution bookkeeping, not independent stores of application truth. Block setup.
Verify once under one acceptance rule
Consensus Ed25519 verification uses the ZIP-215 cofactored rule implemented through ed25519-consensus. Required signature counts, signer positions, key encodings, and signed message bytes are part of that acceptance contract. The CPU batch path uses scalars derived from its input transcript; a failing batch chunk is resolved through individual verification under the same rule.
This avoids a dangerous optimization failure: one machine accepting an edge-case signature through a batch path while another rejects it through a single-signature path. An accelerator must preserve the same acceptance set. Canonical verifier.
Preparation joins verification with transaction classification and declared access-set construction. These operations can run ahead because they depend on transaction bytes. Resolving address lookup tables is different: it reads bank state and must use the correct execution height. A “preverified” entrypoint is a caller contract, not a public bypass for unsigned transactions. Production builds do not enable the benchmark-only verification skip.
Choose a lane without changing dependencies
There are several reasons a transaction takes a particular path:
| Path | What makes it eligible | Important limit |
|---|---|---|
| Lamport transfer fast path | Exact canonical two-account System transfer, one signer/fee payer at the writable source, writable destination | Additional instructions, incompatible account aliases, or a different transfer shape use ordinary dispatch. |
| Independent work | Access analysis proves it can execute ahead without violating earlier reads or writes | Disjoint output keys alone are insufficient. |
| MVCC conflict work | The program supports the per-transaction versioned reader | A direct read of global state would bypass that snapshot. |
| Ordered serial work | Dynamic/shared-state access needs a conservative ordering barrier | Such a barrier can serialize the remainder of the block. |
The strict-transfer decoder deliberately accepts less than the System Program itself. It checks duplicate aliases too: a read-only alias of the source or destination disqualifies the fast path. This is an optimization predicate, not a second transfer authorization policy. Transfer shape.
The classifier tracks both read-after-write and write-after-read dependencies. For example, if transaction A reads X and later transaction B writes X, executing B in an earlier “independent” lane would change A's input even though A writes another key.
A serial tail alone cannot repair that error. When the ordered barrier is present, force_ordered_serial_plan clears the speculative lanes and assigns the remainder in submission order. Cross-VM, WASM, Move, workflow, and bridge paths must not be placed in an MVCC bucket while reading shared state outside its reader. Scheduling, ordering rule.
Bombil enters through its existing ONEBOOK_PROGRAM_ID dispatch. The current path requires a sealed local CUDA runtime and returns a disabled-path error when that runtime is absent. Its financial VM architecture therefore belongs in the shared execution map, with its implementation gate visible. See Bombil. Dispatch and gate.
Speculation needs an explicit owner
Block-STM's versioned memory associates writes with a transaction index and incarnation. A reader sees the highest preceding writer index. An aborted writer leaves an estimate that forces dependent work to wait or revalidate; it must not expose a speculative value as final state. Re-execution is an implementation mechanism, not an extra user transaction or an extra final receipt. Versioned memory.
Cross-runtime calls have another owner: a transaction-scoped journal. Child calls stage effects into that journal, and a parent failure restores its checkpoint. Before successful outer publication, the executor validates deferred components and claims the complete write union. Claim insertion is two-phase so a conflict on a later key cannot strand earlier partial claims. Transaction identity permits intentional rewrites by different VM frames within the same transaction.
Do not confuse those claims with MVCC versions. The claim registry guards conflicting publication; the journal gives atomic lifetime to a transaction's effects. Commit preparation, claim protocol.
Merge once, account once, publish through the common state path
Final accounting must describe the accepted execution result, including failures and fees, rather than intermediate retries. The merged changeset passes the capability-vault ownership/value-conservation backstop before commit. Updates, deletions, sysvars, and relevant transaction effects must reach the same state and durability machinery.
GPU work can complete out of order. The direct-SVM merge coordinator's tests explicitly buffer a later GPU result behind an earlier CPU transaction and verify delete/update ordering. A later GPU completion cannot leap over the block cursor. This is a useful regression target whenever batching or host continuations change. Ordered merge test.
The common commit produces state changes consumed by persistence and replication. Explorer receipt presentation is kept off the main execution path; the hot-path boundary test rejects unintended calls into RPC/indexer/explorer code while documenting its small allow-list. See state and persistence for what happens after application.
Capabilities that should not be confused with the live path
Pre-execution cache machinery exists, but the ordinary reporter finalization path does not become a cache-based consensus engine merely because those methods are present. Cache hits must retain original receipt indices and reach the same state diffs and persistence path as misses.
Preaggregated execution is explicitly disabled: grouped transfer deltas do not retain the exact ordered transactions and signatures needed for replay protection and first-wins semantics. Counting those grouped operations as finalized transactions would overstate both functionality and throughput. Disabled entrypoint.
For changes, select tests for signature equivalence, read/write ordering, rollback, and mixed CPU/GPU merge. For measurements, use benchmark scope and provenance; source comments containing speedup estimates are not end-to-end network measurements.
Consensus & finality
How the Simplex engine orders payloads, how finalized blocks become executed state, and why epoch changes need an execution barrier.
State & persistence
Account views, transaction journals, common state commit, deferred WAL durability, QMDB roots, and authenticated recovery artifacts.