Pith. sign in

REVIEW 3 major objections 6 minor 82 references

SoK: Concurrency in Blockchain -- A Systematic Literature Review and the Unveiling of a Misconception

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

Pith's one-line read Ethereum runs transactions sequentially, so race-condition analysis in one major verification line rests on a false premise.

desk verdict A useful survey of blockchain concurrency undermined by a misconception claim that ignores reentrancy and interleaving semantics. read the letter →

arxiv 2506.01885 v2 pith:XPEDJ345 submitted 2025-06-02 cs.CR cs.DCcs.PF

classification cs.CRcs.DCcs.PF
keywords blockchainconcurrencysmartcontractsEthereumraceconditionstransactionorderingdependencyformalverificationshardingsystematicliteraturereview
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

This paper is a systematic literature review of concurrency in blockchain smart contracts, organized into a nine-category taxonomy. Its central correction targets Category 9: a line of formal-verification work assumes that transactions within one Ethereum smart contract can execute concurrently in the shared-memory sense, producing race conditions. The paper argues this premise is false because Ethereum's infrastructure executes transactions sequentially, with state computed only by starting from genesis and applying every transaction in every block in order. If the correction holds, a body of smart-contract race-condition analysis is modeling behavior that cannot occur on Ethereum, and future work should refocus on ordering-dependent phenomena such as transaction ordering dependency and front-running. The survey also maps concurrency mechanisms across consensus, sharding, intra-block execution, DAGs, off-chain, and cross-chain settings, identifying open questions in each.

What carries the argument

The load-bearing mechanism is Ethereum's deterministic sequential state-transition rule, captured in the white-paper statement that state can only be computed by starting from genesis and sequentially applying every transaction in every block. This rule rules out shared-memory-style concurrent execution within a contract, which is exactly the assumption the criticized verification work imports from the contracts-as-concurrent-objects analogy. The survey's supporting machinery is its taxonomy of concurrency levels across consensus, sharding, intra-block processing, DAGs, semi-centralized designs, off-chain execution, cross-chain coordination, transaction ordering dependency, and the alleged concurrent-execution vulnerabilities; this taxonomy is what lets the authors locate the flawed assumption in one specific category.

What would settle it

Replay the Safe Remote Purchase contract on Ethereum with two transactions that change the same state variable and show that the final state is order-dependent while each transaction is executed atomically in sequence; a demonstrated order-dependent outcome would be a race condition under sequential execution, contradicting the paper's claim that such conditions cannot arise.

Watch

Extended reading notes

Core claim

The paper's core discovery is that a prominent concurrency framing of Ethereum smart contracts is built on an invalid assumption. It claims that Ethereum's infrastructure does not support concurrent execution of transactions inside a smart contract: the white paper specifies that state is an abstraction that can only be computed by starting from the genesis state and sequentially applying every transaction in every block. Therefore the race-condition attack analyzed in [51], which follows the contracts-as-concurrent-objects analogy of [57], cannot arise from simultaneous in-contract execution on Ethereum. The paper treats this as a correction of a long-standing misconception and redirects concurrency research toward assumptions that match Ethereum's actual sequential execution model.

Load-bearing premise

The paper's correction rests on identifying a race condition with two or more transactions actually executing at the same time inside one smart contract; if interleaving of sequential transactions, or a reentrant call inside a single transaction, already counts as concurrency, the criticized line of work is not refuted.

Editorial extensions

If this is right

  • Formal verification of Ethereum smart contracts should not model multiple transactions within one contract as concurrently executing shared-memory threads; the sequential state-transition rule is the baseline.
  • Ethereum's real race-like phenomena, transaction ordering dependency and front-running, should be treated as ordering problems rather than as in-contract concurrency and analyzed with that model.
  • Proposals to add concurrency to Ethereum, such as speculative execution, software transactional memory, and block-level scheduling, are additive mechanisms rather than descriptions of existing behavior, and they must preserve the sequential semantics validators rely on.
  • Sharding remains the main route by which true concurrent execution could enter Ethereum-like systems, with cross-shard coordination as the unresolved cost.

Reading between the lines

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

  • A narrower reading of concurrency as interleaving rather than simultaneous overlap would preserve race conditions even under Ethereum's sequential execution, so the correction's reach depends on the definition of concurrency in play.
  • Reentrant calls inside a single transaction create an interleaving of contract operations within one sequential execution, which may generate the same classes of bugs the criticized line of work tried to catch.
  • A testable extension would be to rerun the criticized attack model with transaction-ordering semantics instead of shared-memory semantics and check whether the same vulnerability is still reachable; if it is, the practical finding survives even though the concurrency framing was wrong.
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

3 major / 6 minor

Summary. This SoK paper presents a systematic literature review of concurrency in blockchain systems, organizing the literature into nine categories (consensus, sharding, intra-block execution, DAGs, semi-centralized solutions, off-chain solutions, cross-chain solutions, transaction ordering dependency/front-running, and a newly identified 'misconception' category). The paper's flagship contribution is Section 6, which claims that Ethereum's infrastructure does not support concurrency, so race-condition analyses of Ethereum smart contracts—specifically the line of work represented by Qu et al. [51] and Sergey and Hobor [57]—rest on an invalid assumption. The argument relies on a sentence from the Ethereum white paper stating that state is computed by sequentially applying every transaction in every block.

Significance. The survey portion has real value: it provides a reproducible Scopus query, public GitHub artifacts, and a broad taxonomy that could help researchers navigate the concurrency literature. The paper gives credit to concrete engineering results and includes comparisons of intra-block execution approaches. However, the central correction claim, which is the paper's stated Contribution 4, is not sound. Section 6.1 infers the absence of all concurrency from a statement about block-level sequential recomputation of state, ignoring the interleaving semantics of reentrant calls within a single transaction and the definitions of concurrency used in [51] and [57]. Because that misconception claim is the paper's headline contribution and is load-bearing for the survey's framing, the error cannot be repaired by a local edit; the paper would need to abandon or fundamentally reframe its central thesis.

major comments (3)
  1. [Section 6.1] The quoted white-paper sentence says that state for a block 'can only be computed (securely) for any block starting from the genesis state and sequentially applying every transaction in every block.' That statement constrains the order in which transactions are applied when recomputing state from genesis; it does not describe the internal execution semantics of a single transaction. In the EVM, a CALL instruction creates a nested execution context, and the callee can call back into the caller (reentrancy), interleaving reads and writes of the same contract within one transaction. The paper does not address this mechanism, nor does it cite any EVM specification or execution-layer documentation other than the white-paper quote. The claim that 'Ethereum's infrastructure does not support concurrency' therefore does not follow from the evidence provided.
  2. [Sections 5.9 and 6] The paper asserts that the concurrency assumption in [51] and [57] is flawed, but it never quotes or analyzes the definitions of concurrency or race used in those papers. In CSP, concurrency is modeled as interleaving of sequential processes, and the FDR model checker used in [51] checks refinement over sequences of events; it does not require simultaneous execution. The paper's own Section 3.1 defines a race condition as depending on the 'unpredictable timing of concurrent processes,' which includes interleavings of asynchronous sequential processes. Sequential execution of transactions at the block level therefore does not rule out the race conditions modeled in [51]. The paper's central correction collapses under this definition, which is the one used in the very literature being criticized.
  3. [Sections 5.8 and 6] The paper's own taxonomy is internally inconsistent with the Section 6 claim. Section 5.8, in the discussion of TransRacer, states that 'Transaction races ... can result from the concurrent execution of transactions within the same block' and describes Transaction Ordering Dependency (TOD) as creating state uncertainty akin to read-after-write race dependencies. Section 6 claims that such race conditions cannot occur because transactions are executed sequentially. The authors must reconcile these positions: either the races described in Category 8 are genuine, in which case the Section 6 refutation fails, or the taxonomy's Category 8 also rests on the purported misconception, which the paper does not argue anywhere.
minor comments (6)
  1. [Abstract and Section 5] The abstract and Section 1 say the paper organizes concurrency perspectives into 'three categories,' but Section 5 actually presents nine categories (Sections 5.1 through 5.9). Please correct this inconsistency.
  2. [Section 3.1] The entry for nondeterminism is grammatically garbled: 'A system shows nondeterminism when two identical copies of it can act differently even with the same inputs upon which wins the race that results in an untestable trait of these systems.' Please rewrite for clarity.
  3. [Section 5.6] The paragraph beginning 'In this protocol, concurrency is integrated into the consensus cycle ... PoV, in contrast, is an incentive mechanism...' appears to be a misplaced description of PPoV from Section 5.1 and is not clearly connected to ACE or off-chain execution.
  4. [Section 4.2 and Listing 1] The search query contains the typo 'dependancy' (should be 'dependency'), and the text says the query is applied to 'all repositories' although only Scopus is used. Please align the description with the actual source.
  5. [Table 3] The speedup comparison draws values from different hardware configurations, core counts, conflict rates, and workloads; the headline conclusion that Conthereum outperforms all prior work with fewer cores is not supported by a controlled comparison and should be substantially qualified.
  6. [Section 6.2] Section 6.2 states that sharding 'allow[s] for parallel processing of transactions, potentially enabling true concurrency in smart contracts,' which is difficult to reconcile with the absolute claim in Section 6.1 that Ethereum's infrastructure does not support concurrency. Please clarify the scope of the misconception claim.

Circularity Check

1 steps flagged · score 2.0 of 10

Minor self-citation only; the central misconception claim is grounded in an external white-paper quote and is not derived from the authors' own prior results or fitted parameters.

  1. other [Section 5.3.4, Table 3 (Intra-block Performance Comparison)]
    "The performance trends indicate that Conthereum [71] demonstrates the highest recorded speedup, achieving (2.92, 2.27) with 3 cores, surpassing the results of [22]... This comparative analysis highlights the efficiency of Conthereum in achieving superior speedup with fewer computational resources."

    This is the paper's only self-referential element: the speedup comparison ranks the authors' own Conthereum preprint first in the survey table. It is not load-bearing, however, because the Section 6 misconception argument does not depend on this comparison. It is flagged only as the minor non-load-bearing self-citation that justifies the non-zero score.

full rationale

The paper's central claim in Sections 5.9 and 6 is that Ethereum applies transactions sequentially and therefore does not support the kind of concurrent execution assumed by [51] and [57]. The derivation chain is: Ethereum white paper says state is computed by 'sequentially applying every transaction in every block'; therefore Ethereum infrastructure 'does not support concurrency'. This rests on an external protocol specification, not on a fitted parameter, an equation defined in terms of its own output, or a self-citation chain. No prediction is renamed from a fit, and no uniqueness theorem from the authors' own prior work is imported. The argument's obvious weakness is definitional rather than circular: Section 3.1 defines concurrency as simultaneous execution, while the criticized CSP-based work treats concurrency as interleaving of asynchronous processes, and reentrant EVM calls can create interleavings inside a single transaction. That is a correctness/validity concern about whether the white-paper sentence refutes [51], not a case where the conclusion is presupposed by the premise. The only self-citation is Conthereum in the performance comparison, which is a minor survey element and does not support the Section 6 correction. Hence the score is 2, not higher.

Assumptions & free parameters 0 free parameters · 3 assumptions · 0 invented entities

This survey has no fitted parameters and no invented entities. The main load-bearing premises are definitional: that Ethereum's sequential transaction execution rules out all concurrency effects, and that a race requires parallel in-block execution. These premises are asserted rather than demonstrated, and they drive the paper's central correction.

assumptions (3)
  • domain assumption Ethereum applies transactions sequentially and therefore cannot exhibit any concurrency-related race condition in smart contracts.
    Invoked in Section 6.1 using the Ethereum white paper quote; the paper treats sequential application as an absence of concurrency, but does not consider reentrant calls or interleaved client invocations.
  • ad hoc to paper A meaningful race condition requires literal parallel execution of multiple transactions inside one contract.
    This definition is used to dismiss [57] and [51]; the concurrency literature, including the CSP approach used by [51], treats races as interleavings of asynchronous processes, which can occur under sequential scheduling.
  • domain assumption A single-database search of Scopus is a sufficient systematic review basis.
    Stated in Section 4.2; single-source coverage can undercount permissioned-blockchain and workshop literature, though the query and criteria are explicit.

how reviews work

0 comments
Cite this review

Pith. "Pith review of SoK: Concurrency in Blockchain -- A Systematic Literature Review and the Unveiling of a Misconception." pith.science (2026). https://pith.science/paper/XPEDJ345

@misc{pith2026250601885,
  author       = {Pith},
  title        = {Pith review of: SoK: Concurrency in Blockchain -- A Systematic Literature Review and the Unveiling of a Misconception},
  year         = {2026},
  howpublished = {\url{https://pith.science/paper/XPEDJ345}},
  note         = {Machine review of arXiv:2506.01885}
}
read the original abstract

Smart contracts, the cornerstone of blockchain technology, enable secure, automated distributed execution. Given their role in handling large transaction volumes across clients, miners, and validators, exploring concurrency is critical. This includes concurrent transaction execution or validation within blocks, block processing across shards, and miner competition to select and persist transactions. Concurrency and parallelism are a double-edged sword: while they improve throughput, they also introduce risks like race conditions, non-determinism, and vulnerabilities such as deadlock and livelock. This paper presents the first survey of concurrency in smart contracts, offering a systematic literature review organized into key dimensions. First, it establishes a taxonomy of concurrency levels in blockchain systems and discusses proposed solutions for future adoption. Second, it examines vulnerabilities, attacks, and countermeasures in concurrent operations, emphasizing the need for correctness and security. Crucially, we reveal a flawed concurrency assumption in a major research category, which has led to widespread misinterpretation. This work aims to correct that and guide future research toward more accurate models. Finally, we identify gaps in each category to outline future research directions and support blockchain's advancement.

Figures

Figures reproduced from arXiv: 2506.01885 by the authors.

Figure 1
Figure 1. illustrates the percentage of relevant articles discovered during the screening process. Additionally, a sub-pie chart categorizes the non-relevant papers into different domains, highlighting the areas that were identified and filtered out from the main set of papers under consideration [PITH_FULL_IMAGE:figures/full_fig_p012_1.png] view at source ↗
Figure 2
Figure 2. depicts the total number of citations for the relevant articles, categorized by their year of publication [PITH_FULL_IMAGE:figures/full_fig_p013_2.png] view at source ↗
Figure 3
Figure 3. shows the number of relevant articles published each year [PITH_FULL_IMAGE:figures/full_fig_p013_3.png] view at source ↗

Discussion (0). Sign in to comment.

Reference graph

Works this paper leans on

82 extracted references · 59 canonical work pages

  1. [51]

    Formal verification of smart contracts from the perspective of concurrency

    Meixun Qu, Xin Huang, Xu Chen, Yi Wang, Xiaofeng Ma, and Dawei Liu. Formal verification of smart contracts from the perspective of concurrency. In Meikang Qiu, editor,Smart Blockchain, pages 32–43, Cham, 2018. Springer In- ternational Publishing. ISBN 978-3-030-05764-0

  2. [57]

    A concurrent perspective on smart contracts

    Ilya Sergey and Aquinas Hobor. A concurrent perspective on smart contracts. In Michael Brenner, Kurt Rohloff, Joseph Bonneau, Andrew Miller, Peter Y .A. Ryan, Vanessa Teague, Andrea Bracciali, Massimiliano Sala, Federico Pintore, and Markus Jakobsson, editors,Financial Cryptography and Data Security, pages 478–493, Cham, 2017. Springer International Publi...

  3. [1]

    URLhttps://ethereum.org/en/developers/ docs/consensus-mechanisms/pos/

    Proof-of-stake (pos), 2024. URLhttps://ethereum.org/en/developers/ docs/consensus-mechanisms/pos/

  4. [2]

    URLhttps://www

    Blockchain.com | charts - blockchain size (mb), 2024. URLhttps://www. blockchain.com/explorer/charts/[id]

  5. [3]

    URL https://docs.soliditylang.org/en/latest/solidity-by-example.html# safe-remote-purchase

    Solidity by example â ˘AˇT solidity 0.8.26 documentation, 2024. URL https://docs.soliditylang.org/en/latest/solidity-by-example.html# safe-remote-purchase

  6. [4]

    Scalability of blockchain: Review of cross-sharding with high communication overhead

    Firas Hammoodi Neamah Al-Mutar, Ahmed Ali Talib Al-Khazaali, and Baqar Assam Hataf. Scalability of blockchain: Review of cross-sharding with high communication overhead. InBIO Web of Conferences, volume 97, page 00075. EDP Sciences, 2024

  7. [5]

    Par- blockchain: Leveraging transaction parallelism in permissioned blockchain systems

    Mohammad Javad Amiri, Divyakant Agrawal, and Amr El Abbadi. Par- blockchain: Leveraging transaction parallelism in permissioned blockchain systems. InProceedings - International Conference on Distributed Computing Systems, volume 2019-July, pages 1337–1347, 2019. doi: 10.1109/ICDCS.2019.00134. URLhttps://www.scopus.com/inward/ record.uri?eid=2-s2.0-850748...

  8. [6]

    Efficient parallel execution of block transactions in blockchain

    Parwat Singh Anjana. Efficient parallel execution of block transactions in blockchain. InMiddleware 2021 Doctoral Symposium - Proceedings of the 22nd International Middleware Conference: Doctoral Symposium, pages 8–11,

Show all 82 references
  1. [7]

    An efficient framework for optimistic concurrent execution of smart contracts

    Parwat Singh Anjana, Sweta Kumari, Sathya Peri, Sachin Rathor, and Archit Somani. An efficient framework for optimistic concurrent execution of smart contracts. InProceedings - 27th Euromicro International Conference on Parallel, Distributed and Network-Based Processing, PDP 2...

  2. [8]

    Entitling concurrency to smart contracts using optimistic transactional memory

    Parwat Singh Anjana, Sweta Kumari, Sathya Peri, Sachin Rathor, and Archit Somani. Entitling concurrency to smart contracts using optimistic transactional memory. InACM International Conference Proceeding Series, page 508,

  3. [9]

    Parwat Singh Anjana, Hagit Attiya, Sweta Kumari, Sathya Peri, and Archit Somani. Efficient concurrent execution of smart contracts in blockchains using object-based transactional memory.Lecture Notes in Computer Science (includ- ing subseries Lecture Notes in Artificial Intell...

  4. [10]

    Optsmart: a space efficient optimistic concurrent execution of smart contracts.Distributed and Parallel Databases, 42(2):245–297, 2024

    Parwat Singh Anjana, Sweta Kumari, Sathya Peri, Sachin Rathor, and Archit Somani. Optsmart: a space efficient optimistic concurrent execution of smart contracts.Distributed and Parallel Databases, 42(2):245–297, 2024. doi: 10. 1007/s10619-022-07412-y. URLhttps://www.scopus.com...

  5. [11]

    Fair and trustworthy: Lock- free enhanced tendermint blockchain algorithm.Telkomnika (Telecom- munication Computing Electronics and Control), 18(4):2224 – 2234,

    Basem Assiri and Wazir Zada Khan. Fair and trustworthy: Lock- free enhanced tendermint blockchain algorithm.Telkomnika (Telecom- munication Computing Electronics and Control), 18(4):2224 – 2234,

  6. [12]

    Dipetrans: A framework for distributed parallel execution of transactions of blocks in blockchains.Concurrency and Computation: Practice and Expe- rience, 34(10), 2022

    Shrey Baheti, Parwat Singh Anjana, Sathya Peri, and Yogesh Simmhan. Dipetrans: A framework for distributed parallel execution of transactions of blocks in blockchains.Concurrency and Computation: Practice and Expe- rience, 34(10), 2022. doi: 10.1002/cpe.6804. URLhttps://www.sc...

  7. [13]

    On parallel mechanism of consortium blockchain: Take pov as an exam- ple

    Yongjie Bai, Yang Zhi, Hui Li, Han Wang, Ping Lu, and Chengtao Ma. On parallel mechanism of consortium blockchain: Take pov as an exam- ple. InACM International Conference Proceeding Series, pages 147 – 154,

  8. [14]

    Thomas Hou, and Wenjing Lou

    Md Mohaimin Al Barat, Shaoyu Li, Changlai Du, Y . Thomas Hou, and Wenjing Lou. Sok: Public blockchain sharding. In2024 IEEE International Conference 28 on Blockchain and Cryptocurrency (ICBC), pages 766–783, 2024. doi: 10.1109/ ICBC59979.2024.10634422

  9. [15]

    A survey on blockchain interoperability: Past, present, and future trends.ACM Comput

    Rafael Belchior, André Vasconcelos, Sérgio Guerreiro, and Miguel Correia. A survey on blockchain interoperability: Past, present, and future trends.ACM Comput. Surv., 54(8), October 2021. ISSN 0360-0300. doi: 10.1145/3471140. URLhttps://doi-org.ezp.biblio.unitn.it/10.1145/3471140

  10. [16]

    Ethereum white paper.GitHub repository, 1:22–23, 2013

    Vitalik Buterin et al. Ethereum white paper.GitHub repository, 1:22–23, 2013. URLhttps://github.com/ethereum/wiki/wiki/White-Paper

  11. [17]

    URLhttps://www.scopus.com/ inward/record.uri?eid=2-s2.0-85115674506&doi=10.1145%2f3460537

    doi: 10.1145/3460537.3460560. URLhttps://www.scopus.com/ inward/record.uri?eid=2-s2.0-85115674506&doi=10.1145%2f3460537. 3460560&partnerID=40&md5=f01c2263d7c6e4f9d9a2a06584ab07cb. Cited by: 3

  12. [18]

    worldscientific, 2021

    Long Chen, Lin William Cong, and Yizhou Xiao.A Brief Introduction to Blockchain Economics, chapter Chapter 1, pages 1–40. worldscientific, 2021. doi: 10.1142/9789811220470\_0001. URLhttps://www.worldscientific. com/doi/abs/10.1142/9789811220470_0001

  13. [19]

    Blockchain trilemma solver algorand has dilemma over undecidable messages

    Mauro Conti, Ankit Gangwal, and Michele Todero. Blockchain trilemma solver algorand has dilemma over undecidable messages. InProceedings of the 14th International Conference on Availability, Reliability and Security, ARES ’19, New York, NY , USA, 2019. Association for Computin...

  14. [20]

    Yoda: Enabling com- putationally intensive contracts on blockchains with byzantine and selfish nodes,

    Sourav Das, Vinay Joseph Ribeiro, and Abhijeet Anand. Yoda: Enabling com- putationally intensive contracts on blockchains with byzantine and selfish nodes,

  15. [21]

    A next-generation smart contract and decentralized applica- tion platform.white paper, 3(37):2–1, 2014

    Vitalik Buterin et al. A next-generation smart contract and decentralized applica- tion platform.white paper, 3(37):2–1, 2014

  16. [22]

    Adding concurrency to smart contracts.Distributed Comput- ing, 33(3-4):209–225, 2020

    Thomas Dickerson, Paul Gazzillo, Maurice Herlihy, and Eric Koski- nen. Adding concurrency to smart contracts.Distributed Comput- ing, 33(3-4):209–225, 2020. doi: 10.1007/s00446-019-00357-z. URL https://www.scopus.com/inward/record.uri?eid=2-s2.0-85068876264& doi=10.1007%2fs004...

  17. [23]

    Ethereum full node sync (archive) chart | etherscan, 2024

    etherscan.io. Ethereum full node sync (archive) chart | etherscan, 2024. URL https://etherscan.io/chartsync/chainarchive

  18. [24]

    A survey of blockchain consen- sus algorithms: mechanism, design and applications.Science China Information Sciences, 64:1–15, 2021

    Xiang Fu, Huaimin Wang, and Peichang Shi. A survey of blockchain consen- sus algorithms: mechanism, design and applications.Science China Information Sciences, 64:1–15, 2021. 29

  19. [25]

    Scalable blockchain based smart contract execution

    Zhimin Gao, Lei Xu, Lin Chen, Nolan Shah, Yang Lu, and Weidong Shi. Scalable blockchain based smart contract execution. In2017 IEEE 23rd International Conference on Parallel and Distributed Systems (ICPADS), pages 352–359, 2017. doi: 10.1109/ICPADS.2017.00054

  20. [26]

    Conflict abstractions and shadow speculation for optimistic transactional objects

    Thomas Dickerson, Eric Koskinen, Paul Gazzillo, and Maurice Herlihy. Conflict abstractions and shadow speculation for optimistic transactional objects. In An- thony Widjaja Lin, editor,Programming Languages and Systems, pages 313–331, Cham, 2019. Springer International Publishing

  21. [27]

    A survey on cross-chain technologies.Distrib

    Panpan Han, Zheng Yan, Wenxiu Ding, Shufan Fei, and Zhiguo Wan. A survey on cross-chain technologies.Distrib. Ledger Technol., 2(2), June 2023. doi: 10. 1145/3573896. URLhttps://doi-org.ezp.biblio.unitn.it/10.1145/3573896

  22. [28]

    Sharding for scalable blockchain networks.SN Computer Science, 4(1):2, 2022

    Faiza Hashim, Khaled Shuaib, and Nazar Zaki. Sharding for scalable blockchain networks.SN Computer Science, 4(1):2, 2022

  23. [29]

    Shihab Shahriar Hazari and Qusay H. Mahmoud. A parallel proof of work to improve transaction speed and scalability in blockchain systems. In2019 IEEE 9th Annual Computing and Communication Workshop and Conference, CCWC 2019, pages 916–921, 2019. doi: 10.1109/CCWC.2019.8666535....

  24. [30]

    Shihab Shahriar Hazari and Qusay H. Mahmoud. Improving trans- action speed and scalability of blockchain systems via parallel proof of work.Future Internet, 12(8), 2020. doi: 10.3390/FI12080125. URLhttps://www.scopus.com/inward/record.uri?eid=2-s2. 0-85089548009&doi=10.3390%2f...

  25. [31]

    Block-stm: Scaling blockchain execution by turning ordering curse to a performance blessing

    Rati Gelashvili, Alexander Spiegelman, Zhuolun Xiang, George Danezis, Zekun Li, Dahlia Malkhi, Yu Xia, and Runtian Zhou. Block-stm: Scaling blockchain execution by turning ordering curse to a performance blessing. InProceedings of the 28th ACM SIGPLAN Annual Symposium on Princ...

  26. [32]

    Transactional boosting: a methodology for highly-concurrent transactional objects

    Maurice Herlihy and Eric Koskinen. Transactional boosting: a methodology for highly-concurrent transactional objects. InProceedings of the 13th ACM SIG- PLAN Symposium on Principles and Practice of Parallel Programming, PPoPP ’08, pages 207–216, New York, NY , USA, 2008. Assoc...

  27. [33]

    Maurice Herlihy, Victor Luchangco, Mark Moir, and William N. Scherer. Soft- ware transactional memory for dynamic-sized data structures. InProceedings of the Twenty-Second Annual Symposium on Principles of Distributed Computing, PODC ’03, pages 92–101, New York, NY , USA, 2003...

  28. [34]

    C. A. R. Hoare. Communicating sequential processes.Commun. ACM, 21(8): 666–677, aug 1978. ISSN 0001-0782. doi: 10.1145/359576.359585. URLhttps: //doi.org/10.1145/359576.359585

  29. [35]

    Bdledger: A scalable distributed ledger for large-scale data recording.Communications in Computer and Information Science, 1490 CCIS:87–100, 2021

    Gang Huang, Kaidong Wu, Chaoran Luo, Su Zhang, Huaqian Cai, Xiang Jing, and Yun Ma. Bdledger: A scalable distributed ledger for large-scale data recording.Communications in Computer and Information Science, 1490 CCIS:87–100, 2021. doi: 10.1007/978-981-16-7993-3\_7. URL https:/...

  30. [36]

    Atomic cross-chain swaps

    Maurice Herlihy. Atomic cross-chain swaps. InProceedings of the 2018 ACM Symposium on Principles of Distributed Computing, PODC ’18, page 245â ˘A¸ S254, New York, NY , USA, 2018. Association for Computing Machin- ery. ISBN 9781450357951. doi: 10.1145/3212734.3212736. URLhttps:...

  31. [37]

    A comprehensive review of blockchain con- sensus mechanisms.IEEE Access, 9:43620–43652, 2021

    Bahareh Lashkari and Petr Musilek. A comprehensive review of blockchain con- sensus mechanisms.IEEE Access, 9:43620–43652, 2021. doi: 10.1109/ACCESS. 2021.3065880

  32. [38]

    Proof of vote: A high-performance consensus protocol based on vote mechanism & consortium blockchain

    Kejiao Li, Hui Li, Hanxu Hou, Kedan Li, and Yongle Chen. Proof of vote: A high-performance consensus protocol based on vote mechanism & consortium blockchain. In2017 IEEE 19th International Conference on High Performance Computing and Communications; IEEE 15th International Co...

  33. [39]

    Asokan, and Dawn Song

    Jian Liu, Peilun Li, Raymond Cheng, N. Asokan, and Dawn Song. Par- allel and asynchronous smart contract execution.IEEE Transactions on Parallel and Distributed Systems, 33(5):1097–1108, 2022. doi: 10.1109/TPDS.2021.3095234. URLhttps://www.scopus.com/inward/ record.uri?eid=2-s...

  34. [40]

    A sur- vey on blockchain sharding.ISA Transactions, 141:30–43, 2023

    Xinmeng Liu, Haomeng Xie, Zheng Yan, and Xueqin Liang. A sur- vey on blockchain sharding.ISA Transactions, 141:30–43, 2023. doi: 10.1016/j.isatra.2023.06.029. URLhttps://www.scopus.com/inward/ record.uri?eid=2-s2.0-85164573433&doi=10.1016%2fj.isatra.2023.06. 029&partnerID=40&m...

  35. [41]

    tendermint/tendermint

    Jae Kwon. tendermint/tendermint. URLhttps://github.com/tendermint/ tendermint. original-date: 2014-05-14T23:21:35Z

  36. [42]

    Making smart contracts smarter

    Loi Luu, Duc-Hiep Chu, Hrishi Olickel, Prateek Saxena, and Aquinas Hobor. Making smart contracts smarter. CCS ’16, pages 254–269, New York, NY , USA,

  37. [43]

    A secure sharding protocol for open blockchains

    Loi Luu, Viswesh Narayanan, Chaodong Zheng, Kunal Baweja, Seth Gilbert, and Prateek Saxena. A secure sharding protocol for open blockchains. InProceed- ings of the 2016 ACM SIGSAC Conference on Computer and Communications Security, CCS ’16, pages 17–30, New York, NY , USA, 201...

  38. [44]

    Transracer: Function dependence- guided transaction race detection for smart contracts

    Chenyang Ma, Wei Song, and Jeff Huang. Transracer: Function dependence- guided transaction race detection for smart contracts. InESEC/FSE 2023 - Proceedings of the 31st ACM Joint Meeting European Software Engineering Con- ference and Symposium on the Foundations of Software En...

  39. [45]

    A survey on cross-chain technology: Challenges, development, and prospect.IEEE Access, 11:45527–45546, 2023

    Hanyu Mao, Tiezheng Nie, Hao Sun, Derong Shen, and Ge Yu. A survey on cross-chain technology: Challenges, development, and prospect.IEEE Access, 11:45527–45546, 2023. doi: 10.1109/ACCESS.2022.3228535

  40. [46]

    A survey on consensus algorithms of blockchain based on dag

    Xiaofeng Lu, Cheng Jiang, and Pan Wang. A survey on consensus algorithms of blockchain based on dag. InProceedings of the 2024 6th Blockchain and Internet of Things Conference, BIOTC ’24, pages 50–58, New York, NY , USA,

  41. [47]

    Todler: A transaction or- dering dependency analyzer - for ethereum smart contracts

    Sundas Munir and Christoph Reichenbach. Todler: A transaction or- dering dependency analyzer - for ethereum smart contracts. InPro- ceedings - 2023 IEEE/ACM 6th International Workshop on Emerg- ing Trends in Software Engineering for Blockchain, WETSEB 2023, pages 9–16, 2023. d...

  42. [48]

    Bitcoin: A peer-to-peer electronic cash system

    Satoshi Nakamoto. Bitcoin: A peer-to-peer electronic cash system. 2008

  43. [49]

    An overview on cross-chain: Mechanism, platforms, challenges and advances.Computer Networks, 218:109378, 2022

    Wei Ou, Shiying Huang, Jingjing Zheng, Qionglu Zhang, Guang Zeng, and Wen- bao Han. An overview on cross-chain: Mechanism, platforms, challenges and advances.Computer Networks, 218:109378, 2022. ISSN 1389-1286. doi: https: 32 //doi.org/10.1016/j.comnet.2022.109378. URLhttps://...

  44. [50]

    Manaswini Piduguralla, Saheli Chakraborty, Parwat Singh Anjana, and Sathya Peri. Dag-based efficient parallel scheduler for blockchains: Hyperledger saw- tooth as a case study.Lecture Notes in Computer Science (including subseries Lecture Notes in Artificial Intelligence and L...

  45. [52]

    Recent advances in sharding techniques for scalable blockchain networks: A review.IEEE Access, pages 1–1, 2024

    Brandon Liew Yi Quan, Nur Haliza Abdul Wahab, Arafat Al-Dhaqm, Ahmad Al- shammari, Ali Aqarni, Shukor Abd Razak, and Koh Tieng Wei. Recent advances in sharding techniques for scalable blockchain networks: A review.IEEE Access, pages 1–1, 2024. doi: 10.1109/ACCESS.2024.3523256

  46. [53]

    Front-running-insider trading under the commodity exchange act.Cath

    Jerry W Markham. Front-running-insider trading under the commodity exchange act.Cath. UL Rev., 38:69, 1988

  47. [54]

    The theory and practice of concurrency

    Anthony Roscoe. The theory and practice of concurrency. 1998

  48. [55]

    An empirical study of speculative concur- rency in ethereum smart contracts.arXiv preprint arXiv:1901.01376, 2019

    Vikram Saraph and Maurice Herlihy. An empirical study of speculative concur- rency in ethereum smart contracts.arXiv preprint arXiv:1901.01376, 2019

  49. [56]

    Securities and Exchange Commission

    États-Unis. Securities and Exchange Commission. Special Study of the Op- tions Markets.Report of the Special Study of the Options Markets to the Securities and Exchange Commission. US Government Printing Office, 1979

  50. [58]

    Simulation of front-running attacks and privacy mitigations in ethereum blockchain

    Zachary Stucke, Theodoros Constantinides, and John Cartlidge. Simulation of front-running attacks and privacy mitigations in ethereum blockchain. InEuropean Modeling and Simulation Symposium, EMSS, 2022. doi: 10.46354/i3m.2022.emss.041. URLhttps://www.scopus.com/inward/ record...

  51. [59]

    Scopus content | elsevier, 2024

    Scopus team. Scopus content | elsevier, 2024. URLhttps://www.elsevier. com/products/scopus/content

  52. [60]

    Survey of crosschain communications protocols.Com- puter Networks, 200:108488, 2021

    Peter Robinson. Survey of crosschain communications protocols.Com- puter Networks, 200:108488, 2021. ISSN 1389-1286. doi: https://doi. org/10.1016/j.comnet.2021.108488. URLhttps://www.sciencedirect.com/ science/article/pii/S1389128621004321

  53. [61]

    Rcane: Semi-centralized network of parallel blockchain and apos

    Nguyen Van Toan, Ung Park, and Geunwoong Ryu. Rcane: Semi-centralized network of parallel blockchain and apos. InProceedings of the International Conference on Parallel and Distributed Systems - ICPADS, volume 2018- December, pages 695–700, 2018. doi: 10.1109/PADSW.2018.864457...

  54. [62]

    Sok: Sharding on blockchain

    Gang Wang, Zhijie Jerry Shi, Mark Nixon, and Song Han. Sok: Sharding on blockchain. InProceedings of the 1st ACM Conference on Advances in Financial Technologies, AFT ’19, pages 41–61, New York, NY , USA, 2019. Association for Computing Machinery. ISBN 9781450367325. doi: 10.1...

  55. [63]

    Sok: Dag-based blockchain systems.ACM Comput

    Qin Wang, Jiangshan Yu, Shiping Chen, and Yang Xiang. Sok: Dag-based blockchain systems.ACM Comput. Surv., 55(12), March 2023. ISSN 0360-

  56. [64]

    Re- duction and local search for weighted graph coloring problem.Proceed- ings of the AAAI Conference on Artificial Intelligence, 34(03):2433–2441, Apr

    Yiyuan Wang, Shaowei Cai, Shiwei Pan, Ximing Li, and Monghao Yin. Re- duction and local search for weighted graph coloring problem.Proceed- ings of the AAAI Conference on Artificial Intelligence, 34(03):2433–2441, Apr

  57. [65]

    A survey of blockchain data management systems.ACM Trans

    Qian Wei, Bingzhe Li, Wanli Chang, Zhiping Jia, Zhaoyan Shen, and Zili Shao. A survey of blockchain data management systems.ACM Trans. Embed. Comput. Syst., 21(3), May 2022. ISSN 1539-9087. doi: 10.1145/3502741. URLhttps: //doi-org.ezp.biblio.unitn.it/10.1145/3502741

  58. [66]

    Kan- here

    Huan Yu Wu, Xin Yang, Chentao Yue, Hye-Young Paik, and Salil S. Kan- here. Chain or dag? underlying data structures, architectures, topologies and consensus in distributed ledger technology: A review, taxonomy and research issues.Journal of Systems Architecture, 131:102720, 20...

  59. [67]

    Thulasiraman and M

    K. Thulasiraman and M. N. S. Swamy.Graphs: Theory and Algorithms. John Wiley & Sons. ISBN 978-1-118-03025-7. Google-Books-ID: rFH7eQffQNkC

  60. [68]

    Huahui Xia, Jinchuan Chen, Nabo Ma, Jia Huang, and Xiaoyong Du. Effi- cient execution of blockchain transactions through deterministic concurrency control.Lecture Notes in Computer Science (including subseries Lec- ture Notes in Artificial Intelligence and Lecture Notes in Bio...

  61. [69]

    Slimchain: Scaling blockchain transactions through off-chain storage and parallel process- ing.Proceedings of the VLDB Endowment, 14(11):2314–2326, 2021

    Cheng Xu, Ce Zhang, Jianliang Xu, and Jian Pei. Slimchain: Scaling blockchain transactions through off-chain storage and parallel process- ing.Proceedings of the VLDB Endowment, 14(11):2314–2326, 2021. doi: 10.14778/3476249.3476283. URLhttps://www.scopus.com/ inward/record.uri...

  62. [70]

    Andrew Zhang, and Ren Ping Liu

    Guangsheng Yu, Xu Wang, Kan Yu, Wei Ni, J. Andrew Zhang, and Ren Ping Liu. Survey: Sharding in blockchains.IEEE Access, 8:14155–14181, 2020. doi: 10.1109/ACCESS.2020.2965147

  63. [71]

    Conthereum: Concurrent ethereum optimized transaction scheduling for multi-core execution

    Atefeh Zareh Chahoki, Maurice Herlihy, and Marco Roveri. Conthereum: Concurrent ethereum optimized transaction scheduling for multi-core execution. arXiv preprint arXiv:2504.07280, 2025

  64. [72]

    An Zhang and Kunlong Zhang. Enabling concurrency on smart contracts using multiversion ordering.Lecture Notes in Computer Science (including subseries Lecture Notes in Artificial Intelligence and Lecture Notes in Bioinformatics), 10988 LNCS:425–439, 2018. doi: 10.1007/978-3-31...

  65. [73]

    URLhttps://ojs.aaai.org/index.php/ AAAI/article/view/5624

    doi: 10.1609/aaai.v34i03.5624. URLhttps://ojs.aaai.org/index.php/ AAAI/article/view/5624

  66. [77]

    Ace: Asynchronous and concurrent execution of com- plex smart contracts

    Karl W Ãijst, Sinisa Matetic, Silvan Egli, Kari Kostiainen, and Srd- jan Capkun. Ace: Asynchronous and concurrent execution of com- plex smart contracts. InProceedings of the ACM Conference on Computer and Communications Security, pages 587–600, 2020. doi: 10.1145/3372297.3417...

  67. [83]

    Towards dependable, scalable, and per- vasive distributed ledgers with blockchains

    Kaiwen Zhang and Hans-Arno Jacobsen. Towards dependable, scalable, and per- vasive distributed ledgers with blockchains. InICDCS, pages 1337–1346, 2018. 35 Table 5: Abbreviations AUs Atomic Units BFT Byzantine Fault-Tolerant BG Block Graph CIC Computationally Intensive Contrac...

  68. [300]

    URLhttps://doi-org.ezp.biblio.unitn.it/10

    doi: 10.1145/3576899. URLhttps://doi-org.ezp.biblio.unitn.it/10. 1145/3576899

  69. [2018]

    URLhttps://arxiv.org/abs/1811.03265

  70. [2019]

    URLhttps://www.scopus.com/ inward/record.uri?eid=2-s2.0-85060934158&doi=10.1145%2f3288599

    doi: 10.1145/3288599.3299723. URLhttps://www.scopus.com/ inward/record.uri?eid=2-s2.0-85060934158&doi=10.1145%2f3288599. 27 3299723&partnerID=40&md5=7993743a21a60f85c7159688d1533d58. Cited by: 2

  71. [2020]

    URLhttps: //www.scopus.com/inward/record.uri?eid=2-s2.0-85087566813& doi=10.12928%2fTELKOMNIKA.V18I4.15701&partnerID=40&md5= a3f2ded577d7ecb8b53fd7a5b85f2738

    doi: 10.12928/TELKOMNIKA.V18I4.15701. URLhttps: //www.scopus.com/inward/record.uri?eid=2-s2.0-85087566813& doi=10.12928%2fTELKOMNIKA.V18I4.15701&partnerID=40&md5= a3f2ded577d7ecb8b53fd7a5b85f2738. Cited by: 6; All Open Access, Green Open Access, Hybrid Gold Open Access

  72. [2021]

    URLhttps://www.scopus.com/ inward/record.uri?eid=2-s2.0-85121106502&doi=10.1145%2f3491087

    doi: 10.1145/3491087.3493676. URLhttps://www.scopus.com/ inward/record.uri?eid=2-s2.0-85121106502&doi=10.1145%2f3491087. 3493676&partnerID=40&md5=58bbd83f3256405ca871f41dbda52aa8. Cited by: 3

  73. [2024]

    ISBN 9798400717000

    Association for Computing Machinery. ISBN 9798400717000. doi: 10. 1145/3688225.3688232. URLhttps://doi-org.ezp.biblio.unitn.it/10.1145/ 3688225.3688232

  74. [7621]

    URLhttps://www

    doi: https://doi.org/10.1016/j.sysarc.2022.102720. URLhttps://www. sciencedirect.com/science/article/pii/S1383762122002077

Pith tools

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