Parallel Transaction Execution in Public Blockchain Systems
Bibliographic record
Abstract
Public blockchain systems like Ethereum and Bitcoin suffer from poor transaction \nthroughput, leading to delayed transaction execution and high transaction fees. They execute transactions one by one, failing to extract inherent parallelism possible in executing \nthe workload. \n \nWe present Block-X, a parallel transaction processing system with a serializable concurrency control that executes transactions in a block in a serializable order equivalent to \nthe order of transactions in the block for public blockchains. It pre-executes transactions \nthat are waiting to be added to a block. Through this pre-execution, Block-X estimates \nthe keys a transaction wants to read or write. It uses this information to create a parallel \nexecution schedule and run transactions optimistically in parallel following the schedule. \nIt also uses the pre-execution to prefetch data that will be accessed during the critical path \ntransaction execution. If a smart contract transaction accesses data outside of its initially \nestimated read-write set of keys, Block-X detects and resolves any potential conflicts. The \nfinal state is equivalent to the state produced after the sequential execution of transactions \nin the block order. Finally, Block-X also accelerates the process of validating blocks by \nproviding the parallel execution schedule produced in the block execution step to validate \ntransactions in parallel. \n \nWe implemented our system on Ethereum so it is compatible with EVM chains. Our \nevaluation demonstrates that Block-X achieves up to a 2.3× higher throughput than \nEthereum. Moreover, our performance is comparable to other systems that perform pessimistic execution. These systems require predefined read-write set and reject transactions \nthat use data outside of it.
Fetched live from OpenAlex and de-inverted. Abstracts are not stored in this database: the inverted indexes are 8.6 GB of the frame’s 9.3 GB of text, and the host has 13 GB free.
How this classification was reachedexpand
Full frame machine prediction
Teacher imitationNot calibrated prevalence, not ground truth. Human validation pending. The Gemma side is a direct model label for every work in the frame, read from the title-only record. The Codex side is a classifier learned from the 10,348 direct Codex labels and calibrated to design-weighted sample rates; fields without enough sample support carry no Codex call. Candidate is the union of the two sides; consensus is their intersection. These outputs are machine_predicted_unvalidated and are not human labels.
Distilled classifier scores by category (both heads)
| Category | Codex | Gemma |
|---|---|---|
| Metaresearch | 0.003 | 0.006 |
| Meta-epidemiology (narrow) | 0.001 | 0.001 |
| Meta-epidemiology (broad) | 0.001 | 0.000 |
| Bibliometrics | 0.000 | 0.001 |
| Science and technology studies | 0.002 | 0.002 |
| Scholarly communication | 0.002 | 0.004 |
| Open science | 0.001 | 0.002 |
| Research integrity | 0.001 | 0.001 |
| Insufficient payload (model declined to judge) | 0.008 | 0.002 |
Machine scores (provisional)
The two teacher heads of the student model, read on this work. A score orders the frame for review; it never asserts a category, and the validation status ships verbatim with every row.
Baseline scores from an immature model (maturity gate not passed, 7 training rounds). Scores rank; they never assert a category.
score_only:v0-immature-baseline · verbatim from the scoring run: score_only means the number may rank works, and no category label ships from itClassification
machine, unvalidatedMachine predicted; a candidate call from one source (direct Gemma or distilled Codex), not a consensus.
How this classification was reached, model by model and score by score, is at the end of the page under "How this classification was reached".