Static Analysis for Detecting Transaction Conflicts in Ethereum Smart Contracts

Atefeh Zareh Chahoki; Marco Roveri

REVIEW 3 major objections 4 minor 14 references

Static Analysis for Detecting Transaction Conflicts in Ethereum Smart Contracts

T0 review · 3 major / 4 minor · reviewed 2026-08-06 · deepseek-v4-flash

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

Pith's one-line read A static analysis tool claims to detect every read-write, write-write, and function-call conflict between pairs of Ethereum transactions before execution.

desk verdict Useful empirical data, but the paper's advertised zero-false-negative guarantee is refuted by its own algorithm, so the central claim as stated is unsupported. read the letter →

arxiv 2507.04357 v2 pith:IYEEIAXB submitted 2025-07-06 cs.DC cs.CR

Atefeh Zareh Chahoki , Marco Roveri This is my paper · ORCID

classification cs.DCcs.CR

keywords EthereumsmartcontractsstaticanalysistransactionconflictsconcurrencySolidityconflictdetectionblockchainscalability

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 aims to show that the three main ways transactions can interfere on the Ethereum blockchain—reading a value another transaction writes, writing the same slot as another, and clashing indirectly through nested function calls—can all be detected ahead of execution by reading Solidity source code alone. If true, validators and rollup sequencers could group non-conflicting transactions for parallel execution and avoid the expensive rollback-based runtime schemes used today, while developers would see conflict-prone function pairs before deployment. The paper grounds this in a concrete tool that parses contracts, extracts per-function read/write/call sets, and checks every pair of externally callable functions. On 100 real-world contracts the tool flagged conflicts in 78% of them, with read-write conflicts the most common at 58.6%, and a manual review of 50 flagged conflicts put precision at 92%. The authors back the approach with a stated proof of zero false negatives, meaning that whenever the tool reports no conflict between a function pair, that pair is guaranteed conflict-free under the analysis's syntactic model.

What carries the argument

The mechanism is a pair-wise conflict scan over transaction-callable functions, driven by three per-function sets extracted from the Solidity abstract syntax tree: read variables, written variables, and called functions. Recursive closure over the call sets propagates transitive state access, and conflict checks reduce to set intersections: read-write if one function's read set meets another's write set, write-write if write sets intersect, and function-call if recursively closed access sets intersect with at least one write. The zero-false-negative guarantee rests on these extracted sets being exact for the syntactic patterns the parser accepts.

What would settle it

Take a contract whose function writes storage only through an inline assembly block (for example `assembly { sstore(slot, value) }`) and run the tool; if the write set for that function is empty while another function reads the same slot, the tool will miss the read-write conflict, contradicting the claimed zero false negatives. Repeating this on any real contract with assembly or delegatecall would settle the claim's scope.

Watch

Extended reading notes

Core claim

The central discovery is a static, execution-free method that reduces transaction-conflict detection to set algebra over storage accesses. For every function that can start a transaction, the tool computes the set of state variables it reads, the set it writes, and the set of functions it calls; calling it recursively gives the transitive access footprint. Two functions conflict if the read footprint of one intersects the write footprint of the other (read-write), if the write footprints intersect (write-write), or if the recursive footprints intersect with at least one write (function-call). The paper claims this detection is exhaustive: a proof is sketched that any conflict occurring during EVM execution must be mirrored by one of these syntactic intersections, so there are zero false negatives relative to the model, while 92% precision is measured on a sampled ground truth.

Load-bearing premise

The zero-false-negative guarantee rests on the assumption that every storage read and write appears in the source as a variable name directly beside an assignment, arithmetic operator, or increment/decrement operator, and that no access hides behind inline assembly, indirect references, or external calls.

Editorial extensions

If this is right

Ethereum validators could precompute conflicting transaction pairs within a block and dispatch independent pairs to different cores without runtime conflict tracking or rollback.
Rollup and sharding systems that reorder batches could use the same conflict matrix to keep execution deterministic while raising throughput.
Developers could add the check to their CI pipeline: a new function that writes a hot variable is flagged immediately, along with the severity rating, before deployment.
Security analysts could use the conflict matrix to focus formal verification and fuzzing on the function pairs that actually share state, rather than auditing all pairs uniformly.

Reading between the lines

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

A bytecode-level counterpart of this extraction could restore completeness for contracts that use inline assembly or delegatecall, since SLOAD and SSTORE opcodes are the true conflict carriers; the authors list assembly-aware and cross-contract analysis as future work, and our inference is that those extensions are required for the zero-false-negative claim to hold across the full EVM contract pop
The 8% measured false positives, attributed to missing control-flow dependencies, could be cut substantially by ranking conflicts with a lightweight dataflow reachability check, turning the tool into a precise triage rather than a conservative alarm.
The conflict-percentage metric as defined averages over all function pairs and so can be diluted in large contracts; a hotspot-weighted index would better reflect scheduling risk and would be a natural, testable refinement of the evaluation.

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.

Desk Editor's Note

read the letter

Two things to know. First, the evaluation on 100 real contracts gives the community concrete numbers on how common read-write, write-write, and function-call conflicts actually are. That part is fine. Second, the advertised proof of zero false negatives is not just unproven; it is contradicted by the algorithm in the paper. The stress-test note is right.

What is new: a simple syntactic static analyzer for Solidity storage conflicts, an open-source tool, and a dataset-derived picture of conflict prevalence (58.6% RW, 30.2% WW, 11.2% FCC). The taxonomy is standard but clearly laid out. Running the tool on 100 contracts and reporting precision on a 50-conflict manual sample is a reasonable first step, though it only measures precision.

Where it falls apart: the completeness claim. Section I says the paper provides a proof of zero false negatives and low false positives. No proof appears anywhere. More concretely, Algorithm 1's SHOULDSKIP returns true for view functions, yet Section IV-B says view functions are considered for read-write conflicts. That is a direct internal contradiction. And the pattern matcher in Step 2 only catches writes of the form `var = ...` or `var++`. It misses `balances[msg.sender] += amount` and `storageArray.push(_value)`, because the variable name is followed by `[` or `.`, not an assignment operator. Those are common Solidity storage writes, so the zero-false-negative guarantee fails on everyday code. The evaluation never measures recall against any ground truth, so these omissions would go unnoticed.

These are load-bearing flaws for the stated purpose: if the tool is meant to drive conflict-based scheduling, missing conflicts is exactly what matters. But the empirical mapping of conflict types and hotspots could survive if the authors drop the completeness claim, fix the view-function handling, and either use a real Solidity parser or formally justify the pattern matcher's coverage. As written, the paper overstates what it delivers.

This is for researchers working on parallel execution for EVM chains who need a quick, cheap conflict estimate and can tolerate false negatives. It is not safe for scheduling without a proof of coverage. I would send this to peer review, because a good referee can force the authors to correct the record, and the empirical part has some value. Just don't cite the zero-false-negative claim.

Referee Report

3 major / 4 minor

Summary. The paper proposes a static analysis method and open-source tool for detecting potential transaction conflicts in Ethereum smart contracts. It parses Solidity source, identifies state-variable read/write/function-call accesses via pattern matching, and enumerates public/external function pairs to report read-write (RW), write-write (WW), and function-call (FCC) conflicts. The authors claim exhaustive coverage and a proof of zero false negatives and low false positives. They evaluate on 100 mainnet contracts, reporting 423 conflicts, 78% of contracts with at least one conflict, 92% precision on a manually reviewed sample of 50 conflicts, and an average analysis time of 312 ms.

Significance. If the completeness guarantee were sound, the tool would be valuable for conflict-aware transaction scheduling, auditing, and MEV analysis; the paper also contributes a useful conflict taxonomy, an open-source implementation, and a real-contract dataset. However, the central load-bearing claim is a formal 'zero false negatives' guarantee, and the described algorithm does not actually provide such a guarantee: the syntactic pattern matcher misses common Solidity storage accesses, and Algorithm 1 excludes view functions despite the text saying they are considered in RW conflicts. These are concrete false-negative mechanisms, and no proof or recall measurement is provided. The paper's empirical contribution is a limited precision assessment on 50 manually inspected conflicts, which cannot validate completeness.

major comments (3)

[Section IV-B, Algorithm 1] The claimed zero-false-negative guarantee is contradicted by the described access-extraction method. Section IV-B states that read operations are 'variable names that are not followed by assignment operators' and write operations are 'variable names followed by assignment operators (=, +=, -=, etc.) or increment/decrement operators (++, --)'. This pattern matcher does not recognize standard Solidity storage accesses such as `balances[msg.sender] += amount`, `storageArray.push(_value)`, or `mapping[key] = value`, because the variable name is followed by `[` or `.` rather than by the assignment operator. Any RW or WW conflict involving mapping, array, or struct storage is therefore silently omitted. A pessimistic analysis that 'ensures no false negatives' must conservatively over-approximate all storage accesses; this pattern matching is not conservative. The proof promised in Section I (contribution 5) is never supplied, and Section IV's statement about the Turing-complete language making precise prediction impossible does not justify the weaker claim actually implemented.
[Algorithm 1, line 24] Algorithm 1's SHOULDSKIP function returns true for 'private, internal, or pure/view' functions, so all view functions are excluded from conflict enumeration. This directly contradicts Section IV-B, which states that 'View functions can read but not modify state variables, so they are only considered for read-write conflicts.' A read-write conflict between a view function and a non-view function is exactly the case the text says should be detected, yet the algorithm skips it. This is a concrete false-negative mechanism for the most common conflict type reported in the evaluation (58.6% RW conflicts). The contradiction must be resolved, and the completeness claim must be stated for the actual algorithm.
[Section VI-C] The precision and recall evaluation does not measure what the central claim requires. Precision is estimated by manually reviewing 50 detected conflicts (92% true positives), but no confidence interval, sampling procedure, or inter-reviewer agreement is reported. Recall is addressed only by saying the tool 'successfully identified all of them' on 'a subset of contracts with known transaction ordering dependencies', with no list of those contracts, no definition of known truth, and no quantitative result. Since the false-negative mechanisms in Algorithm 1 and Section IV-B would not be visible in a precision-only study, the evaluation cannot support the zero-false-negatives assertion. The paper should either provide a conservative access-extraction method with a correctness argument, or explicitly replace the completeness claim with a weaker soundness statement and evaluate recall against a real ground-truth set.

minor comments (4)

[Algorithm 1 and Algorithm 2] The pseudocode contains typographical and formatting errors that obscure the intended logic: 'fundctions' should be 'functions', the sentence after the algorithm is cut off at 'returns the ordered pair (fi, fj) where', and Algorithm 2 line 21 places `return conflicts` on the same line as the union operation without a newline. These should be cleaned up.
[Section VI-B] The subsection heading 'subsectionResults' is missing a space and is not formatted as a proper subsection; the results section also references figures without showing them after the text, making the reported distributions hard to verify.
[Section II-A2] The description of Solidity state mutability lists 'Non-reentrant and non-payable (default)' as a mutability type. Non-reentrancy is a modifier, not a state mutability; only pure, view, payable, and nonpayable are mutability qualifiers. This is a technical inaccuracy in the background section.
[Listing 1] The code listing is missing spaces and punctuation due to formatting, e.g., 'pragma s o l i d i t y^ 0 . 8 . 0 ;' and 'c o n t r a c tE x a m p l e{'. A reformatted, compilable version would improve reproducibility and clarity.

Circularity Check

0 steps flagged · score 0.0 of 10

No circularity: conflict detection is a direct syntactic set-intersection analysis; the self-citation to Conthereum is an application context, not a load-bearing premise.

full rationale

The paper's method is a straightforward static computation: parse the contract, extract read/write/call sets by pattern matching, and report conflicts when the same state variable appears in a read set of one function and a write set of another (or in two write sets). Section IV-B and Algorithm 2 define conflicts as set intersections of these extracted access sets, so the reported conflicts are literally the output of the algorithm rather than a quantity fitted to the same data under a new name. The claim of 'zero false negatives' is an adequacy claim about the pattern matcher's coverage of Solidity storage accesses; that claim may be unsupported or even contradicted by the tool's syntactic limitations, but being wrong about coverage is a correctness/completeness concern, not circular reasoning. The only self-citation, Conthereum [6], is mentioned as a consumer of conflict information, and the present tool is an input to that system; no derivation in this paper depends on accepting an unverified result from the authors' prior work. The evaluation measures precision and recall against manual review and known ordering dependencies, which are external checks rather than restatements of the paper's own outputs. No circular step could be identified and quoted; the analysis is self-contained in the sense required by the circularity standard.

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

The central claim rests on the assumption that a syntactic pattern matcher can capture every storage read/write, and that every pair of public/external non-pure functions constitutes a potential transaction conflict. No free parameters are fitted and no new entities are introduced.

assumptions (3)

domain assumption All state variable storage accesses are syntactically identifiable by simple variable-name pattern matching.
Section IV-B Step 2 defines read/write detection via pattern matching; misses accesses through dynamic storage references or assembly, threatening the no-false-negatives claim.
domain assumption Only storage variables are sources of cross-transaction conflicts.
Section II-A4 and IV-B argue storage is the only persistent state; logs and memory are excluded, which is standard but assumed.
domain assumption Public and external non-pure functions are the only transaction entry points, and internal/private functions are not directly conflict-relevant.
Algorithm 1 uses SHOULDSKIP to skip private/internal and pure/view functions; this contradicts the text about view functions and could miss read-write conflicts involving view functions.

how reviews work

0 comments

Cite this review

Pith. "Pith review of Static Analysis for Detecting Transaction Conflicts in Ethereum Smart Contracts." pith.science (2026). https://pith.science/paper/IYEEIAXB

@misc{pith2026250704357,
  author       = {Pith},
  title        = {Pith review of: Static Analysis for Detecting Transaction Conflicts in Ethereum Smart Contracts},
  year         = {2026},
  howpublished = {\url{https://pith.science/paper/IYEEIAXB}},
  note         = {Machine review of arXiv:2507.04357}
}

read the original abstract

Ethereum smart contracts operate in a concurrent environment where multiple transactions can be submitted simultaneously. However, the Ethereum Virtual Machine (EVM) enforces sequential execution of transactions within each block to prevent conflicts arising from concurrent access to the same state variables. Although this approach guarantees correct behavior, it limits the ability of validators to leverage multi-core architectures for faster transaction processing, thus restricting throughput. Existing solutions introduce concurrency by allowing simultaneous transaction execution combined with runtime conflict detection and rollback mechanisms to maintain correctness. However, these methods incur significant overhead due to continuous conflict tracking and transaction reversion. Recently, alternative approaches have emerged that aim to predict conflicts statically, before execution, by analyzing smart contract code for potential transaction interactions. Despite their promise, there is a lack of comprehensive studies that examine static conflict detection and its broader implications in specific smart contracts. This paper fills this important gap by proposing a novel static analysis method to detect potential transaction conflicts in Ethereum smart contracts. Our method identifies read-write, write-write, and function call conflicts between transaction pairs by analyzing state variable access patterns in Solidity contracts. We implement a tool that parses contract code and performs conflict detection. Evaluation on a dataset of real-world Ethereum smart contracts demonstrates that our approach achieves high precision in identifying potential conflicts. By enabling proactive conflict detection, our tool supports further design of transaction scheduling strategies that reduce runtime failures, enhance validator throughput, and contribute to blockchain scalability.

Figures

Figures reproduced from arXiv: 2507.04357 by the authors.

**Figure 1.** Distribution of Conflict Types As shown in the figure, read-write conflicts are the most common (58.6%), followed by write-write conflicts (30.2%) and function call conflicts (11.2%). This distribution reflects the typical access patterns in smart contracts, where functions often read and write to shared state variables. 2) Conflict Prevalence We found that 78% of the contracts in our dataset have at least one poten… view at source ↗

**Figure 3.** Heatmap of Average Conflicts by Function Count and State Variable [PITH_FULL_IMAGE:figures/full_fig_p008_3.png] view at source ↗

Figures from the paper (1 more)

**Figure 4.** Figure 4: Analysis Time vs. Number of Conflicts C. Precision and Recall To assess the precision of our approach, we manually reviewed a random sample of 50 detected conflicts. We found that 46 of them (92%) are true positives, where the functions could indeed conflict if called …

Discussion (0). Continue with ORCID to comment.

Reference graph

Works this paper leans on

14 extracted references · 11 canonical work pages

[1]

Making smart contracts smarter,

L. Luu, D.-H. Chu, H. Olickel, P. Saxena, and A. Hobor, “Making smart contracts smarter,” inProceedings of the 2016 ACM SIGSAC Conference on Computer and Communications Security, ser. CCS ’16. New York, NY , USA: Association for Computing Machinery, 2016, p. 254–269. [Online]. Available: https://doi-org.ezp.biblio.unitn.it/10. 1145/2976749.2978309

arXiv 2016
[2]

Smashing ethereum smart contracts for fun and real profit,

B. Mueller, “Smashing ethereum smart contracts for fun and real profit,” HITB SECCONF Amsterdam, vol. 9, no. 54, pp. 4–17, 2018

work page 2018
[3]

Slither: A static analysis framework for smart contracts,

J. Feist, G. Grieco, and A. Groce, “Slither: A static analysis framework for smart contracts,” in2019 IEEE/ACM 2nd International Workshop on Emerging Trends in Software Engineering for Blockchain (WETSEB), 2019, pp. 8–15

work page 2019
[4]

Securify: Practical security analysis of smart contracts,

P. Tsankov, A. Dan, D. Drachsler-Cohen, A. Gervais, F. Bünzli, and M. Vechev, “Securify: Practical security analysis of smart contracts,” inProceedings of the 2018 ACM SIGSAC Conference on Computer and Communications Security, ser. CCS ’18. New York, NY , USA: Association for Computing Machinery, 2018, p. 67–82. [Online]. Available: https://doi-org.ezp.bi...

arXiv 2018
[5]

Adding concurrency to smart contracts,

T. Dickerson, P. Gazzillo, M. Herlihy, and E. Koskinen, “Adding concurrency to smart contracts,”Distributed Computing, vol. 33, no. 3-4, p. 209 – 225, 2020, cited by: 29; All Open Access, Green Open Access. [Online]. Available: https://www.scopus.com/inward/record. uri?eid=2-s2.0-85068876264&doi=10.1007%2fs00446-019-00357-z& partnerID=40&md5=dd7311fa1468b...

work page 2020
[6]

Conthereum: Concurrent Ethereum Optimized Transaction Scheduling for Multi-Core Execution

A. Zareh Chahoki, M. Herlihy, and M. Roveri, “Conthereum: Concurrent ethereum optimized transaction scheduling for multi-core execution,” arXiv preprint arXiv:2504.07280, 2025

work page Pith review arXiv 2025
[7]

Bitcoin: A peer-to-peer electronic cash system,

S. Nakamoto, “Bitcoin: A peer-to-peer electronic cash system,” 2008

2008
[8]

Ethereum white paper,

V . Buterinet al., “Ethereum white paper,”GitHub repository, vol. 1, pp. 22–23, 2013. [Online]. Available: https://github.com/ethereum/wiki/ wiki/White-Paper

work page 2013

Show all 14 references

[9]

Exploiting the laws of order in smart contracts,

A. Kolluri, I. Nikolic, I. Sergey, A. Hobor, and P. Saxena, “Exploiting the laws of order in smart contracts,” inProceedings of the 28th ACM SIGSOFT International Symposium on Software Testing and Analysis. ACM, 2019, pp. 363–373

2019
[10]

The extended utxo model,

M. M. Chakravarty, J. Chapman, K. MacKenzie, O. Melkonian, M. P. Jones, and P. Wadler, “The extended utxo model,” inInternational Conference on Financial Cryptography and Data Security. Springer, 2020, pp. 525–539

2020
[11]

Madmax: Surviving out-of-gas conditions in ethereum smart contracts,

N. Grech, M. Kong, A. Jurisevic, L. Brent, B. Scholz, and Y . Smarag- dakis, “Madmax: Surviving out-of-gas conditions in ethereum smart contracts,”Proceedings of the ACM on Programming Languages, vol. 2, no. OOPSLA, pp. 1–27, 2018

2018
[12]

Smartcheck: Static analysis of ethereum smart contracts,

S. Tikhomirov, E. V oskresenskaya, I. Ivanitskiy, R. Takhaviev, E. Marchenko, and Y . Alexandrov, “Smartcheck: Static analysis of ethereum smart contracts,” inProceedings of the 1st International Workshop on Emerging Trends in Software Engineering for Blockchain. ACM, 2018, pp. 9–16

2018
[13]

Sok: Transparent dishonesty: Front-running attacks on blockchain,

S. Eskandari, S. Moosavi, and J. Clark, “Sok: Transparent dishonesty: Front-running attacks on blockchain,” inInternational Conference on Financial Cryptography and Data Security. Springer, 2020, pp. 170– 189

2020
[14]

High-frequency trading on decentralized exchange markets,

L. Zhou, K. Qin, C. F. Torres, D. V . Le, and A. Gervais, “High-frequency trading on decentralized exchange markets,” inInternational Conference on Financial Cryptography and Data Security. Springer, 2020, pp. 361–380

2020

Pith tools

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

[1] [1]

Making smart contracts smarter,

L. Luu, D.-H. Chu, H. Olickel, P. Saxena, and A. Hobor, “Making smart contracts smarter,” inProceedings of the 2016 ACM SIGSAC Conference on Computer and Communications Security, ser. CCS ’16. New York, NY , USA: Association for Computing Machinery, 2016, p. 254–269. [Online]. Available: https://doi-org.ezp.biblio.unitn.it/10. 1145/2976749.2978309

arXiv 2016

[2] [2]

Smashing ethereum smart contracts for fun and real profit,

B. Mueller, “Smashing ethereum smart contracts for fun and real profit,” HITB SECCONF Amsterdam, vol. 9, no. 54, pp. 4–17, 2018

work page 2018

[3] [3]

Slither: A static analysis framework for smart contracts,

J. Feist, G. Grieco, and A. Groce, “Slither: A static analysis framework for smart contracts,” in2019 IEEE/ACM 2nd International Workshop on Emerging Trends in Software Engineering for Blockchain (WETSEB), 2019, pp. 8–15

work page 2019

[4] [4]

Securify: Practical security analysis of smart contracts,

P. Tsankov, A. Dan, D. Drachsler-Cohen, A. Gervais, F. Bünzli, and M. Vechev, “Securify: Practical security analysis of smart contracts,” inProceedings of the 2018 ACM SIGSAC Conference on Computer and Communications Security, ser. CCS ’18. New York, NY , USA: Association for Computing Machinery, 2018, p. 67–82. [Online]. Available: https://doi-org.ezp.bi...

arXiv 2018

[5] [5]

Adding concurrency to smart contracts,

T. Dickerson, P. Gazzillo, M. Herlihy, and E. Koskinen, “Adding concurrency to smart contracts,”Distributed Computing, vol. 33, no. 3-4, p. 209 – 225, 2020, cited by: 29; All Open Access, Green Open Access. [Online]. Available: https://www.scopus.com/inward/record. uri?eid=2-s2.0-85068876264&doi=10.1007%2fs00446-019-00357-z& partnerID=40&md5=dd7311fa1468b...

work page 2020

[6] [6]

Conthereum: Concurrent Ethereum Optimized Transaction Scheduling for Multi-Core Execution

A. Zareh Chahoki, M. Herlihy, and M. Roveri, “Conthereum: Concurrent ethereum optimized transaction scheduling for multi-core execution,” arXiv preprint arXiv:2504.07280, 2025

work page Pith review arXiv 2025

[7] [7]

Bitcoin: A peer-to-peer electronic cash system,

S. Nakamoto, “Bitcoin: A peer-to-peer electronic cash system,” 2008

2008

[8] [8]

Ethereum white paper,

V . Buterinet al., “Ethereum white paper,”GitHub repository, vol. 1, pp. 22–23, 2013. [Online]. Available: https://github.com/ethereum/wiki/ wiki/White-Paper

work page 2013