parallel

func (*BlockSTMExecutor) ExecuteBlock ¶ added in v0.8.46

func (e *BlockSTMExecutor) ExecuteBlock(
	config *ethparams.ChainConfig,
	header *types.Header,
	txs types.Transactions,
	statedb *state.StateDB,
	vmCfg vm.Config,
) ([]*types.Receipt, error)

ExecuteBlock processes all transactions in the block using Block-STM.

Returns (nil, nil) when:

• The block has fewer than 2 transactions (no benefit from parallelism).
• No apply function was configured.

func (*SettlementExecutor) SettleBatch ¶ added in v1.99.22

func (e *SettlementExecutor) SettleBatch(base *state.StateDB, fills []Fill) (int, error)

SettleBatch settles fills against a single state in deterministic index order and returns the conflict count (for observability). It does NOT copy state per fill: a DEX fill is a ~3-account balance mutation (sub-microsecond), so the optimistic copy-the-world-per-item model the EVM block path uses (where each tx is heavy enough to amortise a StateDB.Copy) is catastrophically wrong for fine-grained fills -- measured 311x SLOWER than sequential on this host.

MEASURED FINDING (M1 Max, 10k fills): per-fill StateDB.Copy() => 750 fills/s (70 GB allocated); sequential apply on the shared state => 233k fills/s. The conflict-detection kernel itself is cheap (2.2M fills/s) -- so the right shape is "detect cheaply, then settle without per-item world-copies".

Single-state parallelism is impossible here: geth's StateDB.stateObjects is a plain map mutated even on reads (getOrNewStateObject), so concurrent goroutines touching DISJOINT accounts still race the map and panic. The parallelism for DEX settlement therefore lives ONE level up -- across independent state shards (SettleSharded), which is also the LAN / multi-node story. On one state, the correct, fastest path is the deterministic sequential apply this method does.

fills MUST be ordered by their matcher sequence; the order is preserved so the committed state is identical for every validator.

func (*SettlementExecutor) SettleSharded ¶ added in v1.99.22

func (e *SettlementExecutor) SettleSharded(
	base *state.StateDB,
	shardStates []*state.StateDB,
	fills []Fill,
) (ShardResult, error)

SettleSharded settles a fill batch by partitioning accounts across N independent state shards and settling each shard CONCURRENTLY. This is the real parallelism for DEX settlement: each shard is its own *state.StateDB (no shared map), so the goroutines never race. It is also the in-process model of the LAN multi-node settlement -- a node == a shard, the merge == cross-shard reconciliation.

Contract:

• shardStates[i] is an independent state holding the accounts that trade ONLY in markets assigned to shard i; the caller seeds each such account into that shard, and cross-shard accounts into base (see seedSharded).
• base is the authoritative state for fills touching a cross-shard account (an account that trades in markets on >1 shard) and the merge target. After this returns, the canonical post-batch state = the union of the shard states + the cross-shard fills applied to base, exactly as a single sequential settlement would produce (TestSettleShardedEqualsSequential).

Partition: fills are sharded BY MARKET (fillShard), so a fill is always intra-shard for its market. The hazard is an ACCOUNT trading across markets that landed on different shards -- two shard goroutines would mutate it concurrently. SettleSharded detects those cross-shard accounts up front and routes every fill touching one to the serial base tail, so the concurrent shard phase only ever touches shard-local accounts -- race-free WITHOUT locks.

Determinism: a shard's fills apply in ascending Index; shards are disjoint by construction so their relative order is irrelevant; the cross-shard tail applies last in ascending Index. Every validator runs the same shardOf, so the partition and the final state are identical everywhere.