Pith. sign in

REVIEW 5 major objections 6 minor 22 references

Anthemius: Efficient & Modular Block Assembly for Concurrent Execution

T0 review · 5 major / 6 minor · reviewed 2026-08-07 · deepseek-v4-flash

Challenge this review Re-run · record.json Download PDF Read on arXiv ↗

Pith's one-line read Block assembly can more than double parallel blockchain execution throughput.

desk verdict Smart idea, real code, but the headline speedup may be a measurement artifact. read the letter →

arxiv 2502.10074 v1 pith:DNGTPNCE submitted 2025-02-14 cs.DC

Ray Neiheiser , Eleftherios Kokoris-Kogias This is my paper · ORCID
classification cs.DC
keywords blockchainparallelexecutionblockconstructiontransactionschedulingsmartcontractsresourcecontentionoptimisticguided
verification ladder T0 review T1 audit T2 compute T3 formal

The pith

A machine-rendered reading of the paper's core claim, the machinery that carries it, and where it could break.

The reading

Anthemius is a block-construction algorithm for blockchains that execute transactions in parallel. It claims that by reordering transactions during block assembly, delaying those that repeatedly touch the same hot resources, a parallel execution engine can process more than twice as many transactions per second. The paper demonstrates this with two engines, the optimistic Block-STM and the guided Chiron, on realistic workloads derived from Ethereum and Solana data, achieving speedups up to 240%. The significance is that a single popular application, such as an NFT or a traded token, no longer has to bottleneck the whole chain, and the fix requires no changes to consensus or the execution engine itself.

What carries the argument

The load-bearing object is the resource map (resmap) that records, for every written resource, the cumulative gas cost of the longest chain of dependent transactions ending at that resource. The batch scheduler computes each transaction's chaincost as the maximum resmap value over its read set and includes the transaction only if chaincost plus the transaction gas is at most seqlimit, where seqlimit is maxgas divided by the number of cores. Reads whose resmap value already exceeds the per-core gas limit are counted as hot, and a transaction touching more than maxhotr hot reads is skipped unless it falls in the first or last 10% of the block. This gives an O(N times k) greedy schedule, linear in the number of transactions times the average number of resource accesses, which the authors argue is fast enough to run even on the critical path of consensus.

What would settle it

Run Anthemius on a workload where every transaction reads many resources but writes are rare and evenly spread, so that the resmap write-chains stay short while validation conflicts are frequent; if the throughput advantage drops below 20% or becomes negative, the gas-chain proxy is insufficient for optimistic engines. The paper's own NFT workload, where high-frequency users reappear across batches, already shows little gain and provides a natural test case.

Watch

Extended reading notes

Core claim

Anthemius's central claim is that block assembly, not the execution engine, should be the place where transaction dependencies are managed. The paper constructs blocks under a two-dimensional budget: total gas (execution complexity) and a per-core sequential-path limit of maxgas/c. Its scheduler tracks, for each resource, the cost of the longest write-chain leading to it, and admits a transaction only if that chain cost plus the transaction's gas stays under the per-core limit. Transactions that read too many hot resources are deliberately deferred to later blocks. Over the Chiron benchmarks, this yields over 240% higher throughput on decentralized-exchange workloads and over 200% on a mixed workload compared with vanilla Chiron; with Block-STM the gains are smaller but still reach 200% on the mixed workload.

Load-bearing premise

The whole scheme rests on treating the heaviest per-resource write-chain gas cost as the true serial bottleneck; if that proxy misses the real cost driver, such as validation-triggered re-executions, the measured speedup may shrink or vanish on other workloads.

Editorial extensions

If this is right

  • A blockchain that adopts Anthemius can more than double the throughput of its existing parallel execution engine without modifying consensus or the engine itself.
  • A single popular application, an NFT drop or a hot trading pair, no longer caps system throughput because hot-resource transactions are spread across blocks instead of being stacked.
  • Transaction fees begin to reflect true resource contention: users who must access hot resources can pay to be fast-tracked, while ordinary users enjoy lower latency on uncongested paths.
  • The technique applies to both optimistic and hint-based guided engines, with larger gains on guided engines; on mixed workloads even the optimistic engine sees a 200% improvement.
  • Because Anthemius is stateless and sits between the mempool and consensus, individual validators can adopt it without a hard fork or a change to the block format.

Reading between the lines

Editorial extensions of the paper, not claims the author makes directly.

  • Beyond the paper's measurements, the write-chain gas model likely underestimates conflict costs in optimistic engines, since validation-triggered re-executions are not captured; augmenting resmap with a count of conflicting reads or validation cost could close the gap between the Chiron and Block-STM results.
  • The hot-read threshold and the first/last 10% inclusion window are fixed parameters; adapting them to the observed workload, for example raising maxhotr when few resources are genuinely hot, could recover throughput on the NFT-like workloads where the paper shows little gain.
  • The latency results imply a two-tier service model; combining Anthemius with a fee market would make hot-resource access explicitly priced, but it also means censorship-resistant or fair-ordering protocols must bound how long a leader may delay a transaction, a tradeoff the paper acknowledges.
  • For guided engines that abort transactions with invalid hints, Anthemius's benefit may be partly due to avoiding aborts; measuring abort rates with and without Anthemius on Sui- or Solana-style workloads would test this.
Share X Bluesky LinkedIn Reddit HN

Editorial analysis

A structured set of objections, weighed in public.

Desk editor's note, referee report, and a circularity audit.

Referee Report

5 major / 6 minor

Summary. The paper proposes Anthemius, a block-assembly layer that constructs blocks from mempool transactions using read/write set hints and gas estimates. The algorithm uses a two-stage heuristic: a batch handler that relaxes a per-core gas limit based on inclusion rate, and a batch scheduler that greedily adds transactions while tracking the maximum write-chain cost per resource. The authors integrate Anthemius with Chiron and Block-STM and evaluate on five Chiron workloads, reporting up to 240% throughput improvement with Chiron and 200% with Block-STM on MIXED. The paper argues that Anthemius is modular, stateless, and does not require changes to consensus or execution engines.

Significance. If the throughput claims hold, Anthemius would be a practical, low-overhead way to improve parallel blockchain execution by moving scheduling earlier to block construction. The main strengths are the linear-time heuristic, the modular design, the open-source implementation, and the honest discussion of limitations (NFT workload, tail latency, malicious leaders). However, the reported speedups rest on a measurement protocol that does not compare like-for-like transaction sets, and the parameters appear tuned to the evaluation workloads. The central claim is therefore not yet established.

major comments (5)
  1. [Section 4.2 (Throughput)] The throughput comparison is not normalized to the same transaction set. Anthemius is fed several batches of 10,000 transactions and run until all transactions from the first batch are executed, so the number of transactions counted in the numerator includes later batches; the baselines execute exactly one block of 10,000 transactions. Consequently, the reported speedup ratios (e.g., over 240%) may result from counting more than 10,000 transactions in the Anthemius numerator rather than from executing the same 10,000 transactions faster. The evaluation should compare the time to execute a fixed transaction set (or report throughput per completed transaction) for both Anthemius and the baseline engines to support the abstract's claim.
  2. [Section 4.1 (Benchmark)] The scheduler hyperparameters (maxhotr=4, lim=1000, maxrelaxnum=2, maxrelaxrate=100, targetincrate=2maxlen/c) are fixed based on observations on the same Chiron workloads, and no sensitivity analysis is presented. Without such analysis or a principled selection argument, the reported speedups could be an artifact of tuning to the evaluation set. Please provide a sensitivity study or demonstrate that the results are robust across a range of parameter values.
  3. [Algorithm 2, lines 7-22] The resmap model uses the maximum per-resource write-chain gas cost as a proxy for the critical path, but this ignores the extra work caused by validation-triggered re-execution in optimistic engines such as Block-STM. The evaluation indeed shows limited or negative gains for Block-STM in most workloads (Figure 2b), which is consistent with this limitation. The abstract's claim that Anthemius 'enables the underlying parallel execution engine to process over twice as many transactions' is too broad; the current evidence supports it only for Chiron on specific workloads. Please qualify the claim or add experiments that explicitly account for re-execution overhead.
  4. [Algorithm 2, line 13] The condition for skipping transactions with many hot reads is written as 'hotresources >= maxhotr AND (|block| > lim OR |block| < maxlen - lim)' but the text states that transactions in the first and last lim positions are allowed freely. The correct logical composition is AND, not OR; as written, the pseudocode would skip transactions in the protected prefix and suffix. Please correct the pseudocode or clarify if the implementation differs from the printed algorithm.
  5. [Algorithm 1, line 11] The relaxation formula 'seqlimit = maxgas/c * min(maxrelaxrate, incrate/targetincrate)' appears inverted. When incrate is below targetincrate, the factor incrate/targetincrate is less than 1, which would tighten rather than relax the gas limit. The text says the limit should be relaxed, which would require multiplying by targetincrate/incrate (capped by maxrelaxrate). Please correct the formula or verify that the implementation does not use this expression.
minor comments (6)
  1. [Section 3.2] The definition of a 'hot read' as a resource 'accessed significantly more often than other resources' does not match the code in Algorithm 2, line 11, which uses a gas-cost threshold (resmap[readres] > block.gas/c). Please align the terminology with the actual condition.
  2. [Section 1] The claim that Anthemius can be integrated 'without the need for a hard fork or modifications to the execution engine or consensus mechanism' is qualified by the need for read/write set hints; for blockchains without such hints (e.g., Ethereum) a pre-execution step is required, which the paper does not discuss in terms of overhead or security. Please soften this claim or provide a detailed feasibility discussion.
  3. [Section 4.2] Please use consistent phrasing for the results: 'over 240% performance boost' versus 'almost twice the initial throughput' are different characterizations that could confuse the reader.
  4. [Section 4.3] There is a typo: 'chracteristics' should be 'characteristics'.
  5. [Section 5] The sentence beginning 'In comparison, Finally, Solana [21] also offers parallel execution' has a misplaced 'Finally'; please revise.
  6. [Algorithms 1 and 2] The notation 'block.gas' is not defined; please define it as the cumulative gas of transactions in the current block.

Circularity Check

1 steps flagged · score 3.0 of 10

No derivation-level circularity; one mild evaluation circularity from a hyperparameter tuned on the same benchmark set.

  1. fitted input called prediction [Section 4.1 (Benchmark), batch-handler parameter configuration (Algorithm 1); also affects Algorithm 2 scheduling.]
    "Furthermore, we permit up to maxrelaxnum = 2 relaxations of the inclusion rate as we observed diminishing returns from additional relaxations and large scheduling costs beyond this point."

    The value of maxrelaxnum is chosen after observing the algorithm's performance on the Chiron benchmark workloads ('we observed diminishing returns...'), and the same workloads are then used to report the throughput speedups in Section 4.2. Thus the evaluated configuration is fitted to the test set: the up-to-240% gains are not produced by a fully parameter-free method. This is a mild evaluation circularity, not a derivation-level tautology—the scheduler in Algorithm 2 is an independent greedy heuristic and the measured speedups could have been negative.

full rationale

The paper does not derive its speedups from a formal model; the contribution is an empirical evaluation of a greedy scheduler. No equation defines the result in terms of the claim, and no 'prediction' is computed from a fitted parameter in the derivation chain. The only circularity burden is the hyperparameter maxrelaxnum being set after inspecting the same benchmark set used for evaluation, which makes the headline speedups partially in-sample. Use of the Chiron benchmarks [14] is a self-citation, but the workloads are derived from real Ethereum/Solana data and are externally grounded, so it is not load-bearing. The Section 4.2 protocol feeds Anthemius multiple blocks and the baseline one block; this is an asymmetric comparison, but since throughput is transactions per second and the extra transactions take extra time, the multi-block numerator does not by itself force a 2x ratio. That concern is a measurement/correctness risk rather than circularity. Overall, the core algorithm and its evaluation have independent content, with a modest circularity score.

Assumptions & free parameters 7 free parameters · 4 assumptions · 0 invented entities

No new physical or mathematical entities are postulated; Anthemius is an algorithm and system layer. The free parameters are hand-chosen and the evaluation does not test sensitivity to them, so they are counted as inputs fitted to the benchmark rather than derived from theory.

free parameters (7)
  • maxhotr = 4
    Maximum number of hot reads a transaction may access before being delayed; set to 4 to 'avoid uniting too many critical paths' with no sensitivity analysis (Sec 4.1).
  • lim = 1000
    First/last transactions exempt from hot-read delay; set to 1000 to 'minimize tail latency' (Sec 4.1).
  • maxrelaxnum = 2
    Maximum number of inclusion-rate relaxations; chosen because 'we observed diminishing returns from additional relaxations' (Sec 4.1).
  • maxrelaxrate = 100
    Cap on relaxed seqlimit factor; hand-set, no justification beyond 'maximum' (Sec 4.1).
  • targetincrate = 2*maxlen/c
    Target transaction inclusion rate; chosen by authors to account for concurrency, no independent justification (Sec 4.1).
  • batch size = 10000
    Batches sized to match target block size; says smaller increase overhead, larger reduce flexibility (Sec 4.1).
  • maxlen = 10000
    Block size sweet spot for both engines; empirical choice (Sec 4.1).
assumptions (4)
  • domain assumption Transaction read/write sets and gas estimates are available to the block producer before block construction (via client hints or pre-execution).
    Stated in System Model (Section 2); without hints the dependency map cannot be built.
  • ad hoc to paper The longest write-chain cost in gas per resource is a good proxy for the sequential execution path of a block.
    Algorithm 2 computes chaincost only from resmap values; it ignores re-execution, validation overhead, and machine-specific costs, so the speedup claim depends on this approximation.
  • domain assumption Chiron workloads are representative of production blockchain workloads and the tuned parameters generalize.
    Evaluation uses five Chiron workloads derived from Ethereum/Solana data; no held-out or real-time workload is tested (Section 4.1).
  • domain assumption Block-STM/Chiron correctly handle incomplete or incorrect hints via validation/re-execution.
    System Model says hints are not assumed exhaustive or correct; safety relies on the underlying engine.

how reviews work

0 comments
Cite this review

Pith. "Pith review of Anthemius: Efficient & Modular Block Assembly for Concurrent Execution." pith.science (2026). https://pith.science/paper/DNGTPNCE

@misc{pith2026250210074,
  author       = {Pith},
  title        = {Pith review of: Anthemius: Efficient & Modular Block Assembly for Concurrent Execution},
  year         = {2026},
  howpublished = {\url{https://pith.science/paper/DNGTPNCE}},
  note         = {Machine review of arXiv:2502.10074}
}
read the original abstract

Many blockchains such as Ethereum execute all incoming transactions sequentially significantly limiting the potential throughput. A common approach to scale execution is parallel execution engines that fully utilize modern multi-core architectures. Parallel execution is then either done optimistically, by executing transactions in parallel and detecting conflicts on the fly, or guided, by requiring exhaustive client transaction hints and scheduling transactions accordingly. However, recent studies have shown that the performance of parallel execution engines depends on the nature of the underlying workload. In fact, in some cases, only a 60% speed-up compared to sequential execution could be obtained. This is the case, as transactions that access the same resources must be executed sequentially. For example, if 10% of the transactions in a block access the same resource, the execution cannot meaningfully scale beyond 10 cores. Therefore, a single popular application can bottleneck the execution and limit the potential throughput. In this paper, we introduce Anthemius, a block construction algorithm that optimizes parallel transaction execution throughput. We evaluate Anthemius exhaustively under a range of workloads, and show that Anthemius enables the underlying parallel execution engine to process over twice as many transactions.

Figures

Figures reproduced from arXiv: 2502.10074 by the authors.

Figure 1
Figure 1. Anthemius is inserted between the Mempool and Consensus [PITH_FULL_IMAGE:figures/full_fig_p005_1.png] view at source ↗
Figure 2
Figure 2. Throughput per Second the results for Block-STM vary more as the high contention within each block re￾sults in a large re-execution overhead. As such, even when we build better blocks with Anthemius, the contention in the block is still so high, that Block-STM struggles to take advantage of that. We can still see the largest disadvantage in the NFT workload, due to the user distribution preventing us from build￾ing … view at source ↗
Figure 3
Figure 3. Tail Latency for Chiron and Block-STM where the yellow line indicates the 50th percentile (median), the box represents the 25th and 75th percentiles (interquartile range), and the whiskers denote the 10th and 90th percentiles. The results mirror what we saw in the throughput evaluation where in almost all workloads and configurations where Anthemius shows a significant speedup the average transaction latency is sign… view at source ↗

Discussion (0). Continue with ORCID to comment.

Reference graph

Works this paper leans on

22 extracted references · 13 canonical work pages

  1. [1]

    In: 2018 IEEE 26th International Conference on Network Protocols (ICNP)

    Asayag, A., Cohen, G., Grayevsky, I., Leshkowitz, M., Rottenstreich, O., Tamari, R., Yakira, D.: A Fair Consensus Protocol for Transaction Ordering. In: 2018 IEEE 26th International Conference on Network Protocols (ICNP). pp. 55–65 (2018). https://doi.org/10.1109/ICNP.2018.00016

    arXiv 2018

  2. [2]

    Theoreti- cal Computer Science 162(2), 225–243 (1996)

    Baker, B.S., Coffman, E.G.: Mutual exclusion scheduling. Theoreti- cal Computer Science 162(2), 225–243 (1996). https://doi.org/https: //doi.org/10.1016/0304-3975(96)00031-X, https://www.sciencedirect.com/ science/article/pii/030439759600031X

    arXiv 1996

  3. [3]

    Buterin, V.: Ethereum Whitepaper

    work page

  4. [4]

    In: Proceedings of the Sev- enteenth European Conference on Computer Systems

    Danezis, G., Kokoris-Kogias, L., Sonnino, A., Spiegelman, A.: Narwhal and Tusk: A DAG-Based Mempool and Efficient BFT Consensus. In: Proceedings of the Sev- enteenth European Conference on Computer Systems. p. 34–50. EuroSys ’22, As- sociation for Computing Machinery, New York, NY, USA (2022).https://doi. org/10.1145/3492321.3519594, https://doi.org/10.11...

    arXiv 2022

  5. [5]

    https://aptos.dev/assets/files/ Aptos-Whitepaper-47099b4b907b432f81fc0effd34f3b6a.pdf (2023), accessed on 12.04.2023

    Foundation, A.: Aptos Whitepaper. https://aptos.dev/assets/files/ Aptos-Whitepaper-47099b4b907b432f81fc0effd34f3b6a.pdf (2023), accessed on 12.04.2023

    work page 2023

  6. [6]

    Fuel Labs: GitHub - FuelLabs/fuel-specs: Specifications for the Fuel protocol, https://github.com/FuelLabs/fuel-specs

    work page

  7. [7]

    In: Anthemius: Efficient & Modular Block Assembly for Concurrent Execution 17 Proceedings of the 44th International Conference on Software Engineering

    Garamvölgyi, P., Liu, Y., Zhou, D., Long, F., Wu, M.: Utilizing parallelism in smart contracts on decentralized blockchains by taming application-inherent conflicts. In: Anthemius: Efficient & Modular Block Assembly for Concurrent Execution 17 Proceedings of the 44th International Conference on Software Engineering. ACM (may 2022).https://doi.org/10.1145/...

    arXiv 2022

  8. [8]

    https://doi.org/10.48550/ARXIV.2203.06871, https://arxiv.org/abs/2203.06871

    Gelashvili, R., Spiegelman, A., Xiang, Z., Danezis, G., Li, Z., Malkhi, D., Xia, Y., Zhou, R.: Block-STM: Scaling Blockchain Execution by Turning Ordering Curse to a Performance Blessing (2022). https://doi.org/10.48550/ARXIV.2203.06871, https://arxiv.org/abs/2203.06871

    arXiv doi:10.48550/arxiv.2203.06871 2022

Show all 22 references
  1. [9]

    In: 10th USENIX Symposium on Operating Systems Design and Implementation (OSDI 12)

    Kapritsos, M., Wang, Y., Quema, V., Clement, A., Alvisi, L., Dahlin, M.: All about Eve: Execute-Verify Replication for Multi-Core Servers. In: 10th USENIX Symposium on Operating Systems Design and Implementation (OSDI 12). pp. 237–250. USENIX Association, Hollywood, CA (Oct 20...

    2012

  2. [10]

    In: Proceedings of the 9th ACM on ASIA Public-Key Cryptography Work- shop

    Kelkar, M., Deb, S., Kannan, S.: Order-Fair Consensus in the Permissionless Set- ting. In: Proceedings of the 9th ACM on ASIA Public-Key Cryptography Work- shop. p. 3–14. APKC ’22, Association for Computing Machinery, New York, NY, USA(2022). https://doi.org/10.1145/3494105.35...

    2022

  3. [11]

    In: 2018 IEEE Symposium on Security and Privacy (SP)

    Kokoris-Kogias, E., Jovanovic, P., Gasser, L., Gailly, N., Syta, E., Ford, B.: OmniLedger: A Secure, Scale-Out, Decentralized Ledger via Sharding. In: 2018 IEEE Symposium on Security and Privacy (SP). pp. 583–598 (2018). https: //doi.org/10.1109/SP.2018.000-5

    2018 doi

  4. [12]

    Lu,Y.,Yu,X.,Cao,L.,Madden,S.:Aria:AFastandPracticalDeterministicOLTP Database. Proc. VLDB Endow.13(12), 2047–2060 (jul 2020).https://doi.org/ 10.14778/3407790.3407808, https://doi.org/10.14778/3407790.3407808

    2020

  5. [13]

    Nakamoto, S.: Bitcoin: A Peer-to-Peer Electronic Cash System (2008)

    2008

  6. [14]

    Neiheiser, R., Babaei, A., Alexopoulos, G., Kogias, M., Kogias, E.K.: CHIRON: Accelerating Node Synchronization without Security Trade-offs in Distributed Ledgers (2024)

    2024

  7. [15]

    In: Proceedings of the ACM SIGOPS 28th Symposium on Operating Systems Principles

    Neiheiser, R., Matos, M., Rodrigues, L.: Kauri: Scalable BFT Consensus with Pipelined Tree-Based Dissemination and Aggregation. In: Proceedings of the ACM SIGOPS 28th Symposium on Operating Systems Principles. p. 35–48. SOSP ’21, Association for Computing Machinery, New York, ...

    2021

  8. [16]

    Sergey, I., Hobor, A.: A Concurrent Perspective on Smart Contracts (2017).https: //doi.org/10.48550/ARXIV.1702.05511, https://arxiv.org/abs/1702.05511

    2017 doi arXiv

  9. [17]

    In: Proceedings of the 2019 International Conference on Management of Data

    Sharma, A., Schuhknecht, F.M., Agrawal, D., Dittrich, J.: Blurring the Lines be- tween Blockchains and Database Systems: the Case of Hyperledger Fabric. In: Proceedings of the 2019 International Conference on Management of Data. p. 105–122. SIGMOD ’19, Association for Computin...

    2019

  10. [18]

    https://polygon.technology/blog/ innovating-the-main-chain-a-polygon-pos-study-in-parallelization (2022), accessed on 05.12.2022

    Team, P.: Innovating the Main Chain: a Polygon PoS Study in Parallelization. https://polygon.technology/blog/ innovating-the-main-chain-a-polygon-pos-study-in-parallelization (2022), accessed on 05.12.2022

    2022

  11. [19]

    Team, T.M.: The Sui Smart Contracts Platform.https://docs.sui.io/paper/ sui.pdf (2023), accessed on 15.01.2024

    2023

  12. [20]

    Xue, B., Deb, S., Kannan, S.: BigDipper: A hyperscale BFT system with short term censorship resistance (2023)

    2023

  13. [21]

    Yakovenko, A.: Solana: A new architecture for a high performance blockchain v0. 8.13. Whitepaper (2018) 18 R. Neiheiser, E. Kokoris-Kogias

    2018

  14. [22]

    In: 14th USENIX Symposium on Operating Systems Design and Implementation (OSDI 20)

    Zhang, Y., Setty, S., Chen, Q., Zhou, L., Alvisi, L.: Byzantine ordered consensus without byzantine oligarchy. In: 14th USENIX Symposium on Operating Systems Design and Implementation (OSDI 20). pp. 633–649 (2020)

    2020

Pith tools

Reviewed August 7, 2026 · model on record in the stance chip above.