Exploiting Multi-Core Parallelism in Blockchain Validation and Construction

Blockchain validators can reduce block processing time by exploiting multi-core CPUs, but deterministic execution must preserve a given total order while respecting transaction conflicts and per-block runtime limits. This paper systematically examines how validators can exploit multi-core parallelism during both block construction and execution without violating blockchain semantics. We formalize two validator-side optimization problems: (i) executing an already ordered block on (p) cores to minimize makespan while ensuring equivalence to sequential execution; and (ii) selecting and scheduling a subset of mempool transactions under a runtime limit (B) to maximize validator reward. For both, we develop exact Mixed-Integer Linear Programming (MILP) formulations that capture conflict, order, and capacity constraints, and propose fast deterministic heuristics that scale to realistic workloads. Using Ethereum mainnet traces and including a Solana-inspired declared-access baseline (Sol) for ordered-block scheduling and a simple reward-greedy baseline (RG) for block construction, we empirically quantify the trade-offs between optimality and runtime.

💡 Research Summary

The paper addresses two fundamental optimization challenges that arise for blockchain validators equipped with multi‑core CPUs: (1) how to execute a pre‑ordered block on p identical cores as quickly as possible while preserving the exact transaction order and avoiding conflicts, and (2) how to construct a new block from a mempool under a hard execution‑time budget B so that the validator’s reward is maximized. The first challenge, called Ordered‑Block Scheduling (OBS), is modeled as a precedence‑constrained makespan minimization problem (P|prec|Cmax) where precedence derives from the block’s total order and additional constraints forbid parallel execution of conflicting transactions (conflicts are defined by overlapping read/write sets with at least one write). The authors formulate an exact Mixed‑Integer Linear Program (MILP) that captures ordering, conflict, and core‑capacity constraints. Because MILP solving becomes intractable for realistic block sizes and core counts, they propose a deterministic list‑scheduling heuristic: transactions are sorted by execution time (gas) and placed in the earliest feasible round while respecting the p‑core limit. This heuristic enjoys a proven (2 − 1/p) approximation ratio and, in experiments on Ethereum mainnet traces, yields makespans within 2–3 % of the MILP optimum, delivering 1.57× speed‑up with two cores and 2.3× with eight cores compared to sequential execution.

The second challenge, Parallel‑Block Construction (PBC), combines transaction selection, conflict‑aware scheduling, and reward maximization under a global time bound B. Each mempool transaction τ carries a gas consumption τ.gasU (execution time), a reward τ.reward = τ.gasU · τ.tip, and declared read/write sets. The problem generalizes knapsack with conflict graphs and parallel‑machine scheduling with rejection, and is NP‑hard. An exact MILP is presented that decides which transactions to include, their core assignments, and start times, while enforcing (i) no parallel conflicts, (ii) total makespan ≤ B, and (iii) maximal total reward. The MILP quickly becomes unsolvable for heterogeneous workloads or larger p. Consequently, the authors devise a two‑phase heuristic: (a) greedily select transactions in descending order of reward‑per‑gas until the budget would be exceeded, and (b) schedule the selected set by coloring the conflict graph (each color corresponds to a core) and packing colors into time slots so that each slot’s total gas does not exceed B/p. This approach attains 99–100 % of the MILP optimum on homogeneous workloads and 74–100 % of the LP‑relaxation upper bound on heterogeneous workloads. Moreover, throughput scales almost linearly with p, achieving a 7.9× speed‑up at p = 8.

Experimental evaluation uses real Ethereum transaction traces, a Solana‑style declared‑access baseline (Sol) for OBS, and a simple reward‑greedy baseline (RG) for PBC. Results show that the OBS heuristic consistently produces schedules within a few percent of the MILP optimum while running in milliseconds, and the PBC heuristic matches or exceeds the MILP reward when the latter times out. The study demonstrates that substantial parallelism can be unlocked in both block execution and block construction by explicitly modeling conflicts and reward trade‑offs, bridging the gap between naïve sequential processing and the theoretical potential of multi‑core hardware. The contributions include formal problem definitions, exact MILP models for benchmarking, provably good fast heuristics, and a comprehensive empirical analysis confirming the practical viability of the proposed techniques.