Pith. sign in

REVIEW 4 major objections 5 minor 67 references

Building Reuse-Sensitive Control Flow Graphs (CFGs) for EVM Bytecode

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

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

Pith's one-line read Compiler-introduced code reuse in EVM bytecode can be detected from pre-pushed jump operands and cloned away, yielding control-flow graphs that cover 99.94% of real execution traces.

desk verdict A well-executed tool paper that delivers a real improvement for EVM bytecode CFG precision, but its headline claim overstates scope: it resolves reuse only for pre-pushed stack jump operands, not memory/computed jumps. read the letter →

arxiv 2505.14437 v1 pith:IFPPQFSH submitted 2025-05-20 cs.SE

Dingding Wang , Jianting He , Yizheng Yang , Lei Wu , Rui Chang , Yajin Zhou This is my paper · ORCID
classification cs.SE
keywords controlflowgraphEVMbytecodereusereuse-sensitiveCFGstaticanalysissmartcontractsstackemulationtaint
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

EVM compilers shrink contract bytecode by reusing identical code snippets, so the same basic block can be reached from unrelated paths with different jump targets. Static analysis tools that ignore this build control-flow graphs full of fake joins, fake loops, and infeasible paths. Esuer, the tool proposed here, detects such reuse dynamically while constructing the CFG: it records the stack before and after each basic block, taints the operands that predecessors push for the eventual jump, and clones a block whenever a different context arrives. On 10,000 popular contracts Esuer covers 99.94% of real execution traces, introduces no polymorphic jump targets, and runs in 1.06 seconds on average, while vulnerability detectors built on its CFGs reach F1-scores of 99.97% and 99.67% for tx.origin and reentrancy. The paper's claim is that compiler-introduced code reuse is identifiable from stack values alone, and that eliminating it makes CFG-based analysis more precise.

What carries the argument

The load-bearing mechanism is the paper's Definition 1: for a basic block, the reuse context is the set of jump operands pushed by predecessors and already on the stack when the block begins. Esuer combines this with SSA-based symbolic stack emulation, snapshot generation before and after each block, and backward taint analysis from the jump target to mark which stack positions belong to the reuse context. Comparisons of these tainted positions between a candidate successor and the current block determine whether to reuse the existing block or generate a clone, with taints transferred between clones so that shared context propagates. This stack-value criterion replaces pattern matching against compiler-specific code shapes, which the paper argues is why it generalizes across compiler versions.

What would settle it

Take a contract whose dispatcher computes the jump target from a memory slot (MLOAD) rather than from a PUSHed constant, run Esuer on it, and inspect whether the resulting CFG contains the corresponding edge and no polymorphic target. The paper's own trace-loss cases, two old Vyper contracts, are ready-made instances: if Esuer's CFG for either contract lacks the real execution edge, the universal claim that Esuer eliminates code reuse and covers 99.94% of traces fails for that input.

Watch

Extended reading notes

Core claim

The central discovery is that a basic block's reuse context, namely the values of jump operands pushed by its predecessors and left on the stack, determines whether an incoming edge is a real control-flow join or a compiler reuse. When two predecessors push the same operand value, they can safely share the successor; when the values differ, the block is being reused and must be cloned. Esuer obtains these contexts by symbolically emulating each basic block, keeping stack snapshots, and propagating taints from the jump operand back through SSA def-use chains. The result is a reuse-sensitive CFG with no polymorphic jump targets and, across 10,000 contracts, execution-trace coverage of 99.94% with fewer paths than six existing tools. This, the paper argues, is why downstream analyses such as reentrancy detection become more accurate on bytecode alone.

Load-bearing premise

Everything rests on the premise that compiler-introduced code reuse is always visible as differing values of jump operands that predecessors push onto the stack; if jump targets are stored in memory or computed in ways that do not leave such a comparable stack value, Esuer will miss the reuse or clone wrongly, and the CFG reverts to a reuse-insensitive shape.

Editorial extensions

If this is right

  • Bytecode-only CFG construction can become reuse-sensitive without source code or compiler-specific patterns: the same stack-value comparison rule works across compiler versions.
  • Path-sensitive downstream analyses get a tractable search space, because the fake edges that reuse introduces disappear; on the reentrancy benchmark this moves the best reported detector F1-score from below 91% to 99.67%.
  • Keeping all stack values, not just jump operands, preserves edges that computation-based jumps would otherwise hide, which is part of how the 99.94% trace coverage is reached.
  • A CFG without polymorphic jump targets becomes a checkable invariant: if an analysis ever sees a polymorphic target in an Esuer CFG, it is a sign of missed reuse rather than normal switch-case code.

Reading between the lines

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

  • Extending beyond the paper, the same context comparison should be tested on other stack-based virtual machines; the evaluation only covers Ethereum mainnet bytecode.
  • Extending beyond the paper, enriching reuse contexts with memory-loaded jump operands would recover the two lost Vyper traces and push coverage from 99.94% toward 100%.
  • Extending beyond the paper, a compiler-independent oracle, checking that every real trace is present and every path is feasible, would validate the stack-value assumption more directly than the assembly-tag proxy.
  • Extending beyond the paper, the results suggest compiler code reuse is a semantic phenomenon of EVM bytecode rather than an optimization detail, which would argue for treating reuse sensitivity as a standard primitive in decompilers and static analyzers.
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

4 major / 5 minor

Summary. The paper studies code reuse in EVM bytecode, a phenomenon where identical basic blocks are executed in different contexts due to compiler optimizations. It identifies eight reuse patterns, proposes a tool called Esuer that constructs reuse-sensitive control flow graphs by comparing 'reuse contexts' (pre-pushed jump operands) and cloning reused blocks, and evaluates Esuer on 10,000 popular smart contracts against six existing tools. The reported results include an execution trace coverage of 99.94%, an F1-score of 97.02% for code reuse identification, a success rate of 99.25%, an average execution time of 1.06 seconds, and high F1-scores for downstream tx.origin and reentrancy vulnerability detection.

Significance. If the claims hold, Esuer is a practically valuable contribution to EVM static analysis: it addresses an under-studied source of CFG imprecision (compiler-introduced code reuse) and the evaluation is large-scale, comparing against multiple state-of-the-art tools. The method is described in algorithmic detail, and the paper provides a public repository for further examples. The central idea of using differences in pre-pushed jump operands as a reuse indicator is simple and potentially effective for compiler-generated code. However, the evaluation metrics and the unqualified scope of the main claim require careful tightening before the contribution can be fully accepted.

major comments (4)
  1. [§V-B2 / Definition 1 / §VII / §VI-A1] The paper's central claim that Esuer 'eliminates code reuse' (abstract and answer to RQ1) is only established for the subclass of code reuse defined by Definition 1, namely reuse with pre-pushed jump operands. As §VII explicitly admits, Esuer cannot handle jumps whose operands are stored in memory or calculated on the fly, and §VI-A1 reports that exactly this limitation causes Esuer to lose 138 execution traces in two Vyper contracts. The claim should be scoped explicitly to 'reuse patterns with pre-pushed jump operands,' and the paper should quantify how representative this class is among the eight identified patterns.
  2. [§VI-A2] The F1-score of 97.02% is computed against assembly tag-push information, but the paper itself notes that tags that are pushed but never executed are counted as false negatives. Moreover, reuse patterns that do not leave a directly comparable pre-pushed stack value (e.g., memory-stored or computed jump targets) are outside Esuer's detection mechanism by construction. Consequently, the reported F1 measures only a tag-based, pre-pushed-operand subclass and cannot support the unqualified statement that Esuer 'successfully eliminates code reuse.' The authors should either restrict the claim to this subclass or supplement the evaluation with a ground truth covering the excluded reuse patterns.
  3. [Abstract / §VI-B / Table II] The abstract states that Esuer is 'outpacing tools generating reuse-insensitive CFGs,' but Table II shows Ethersolve has a lower average execution time (0.86 s vs. 1.06 s). If 'outpacing' refers to overall precision or success rate, that should be stated explicitly; as written, the claim is contradicted by the paper's own performance data.
  4. [§VI-A1 / Fig. 8] The path-ratio comparison in Fig. 8 is restricted to contracts for which both Esuer and the compared tool successfully generate a CFG. Because several comparison tools have substantially lower success rates (e.g., Rattle 59.87%, Octopus 60.57%, Table II), the common subset may systematically exclude contracts with difficult reuse patterns, biasing the path-ratio comparison. The paper should report the size and characteristics of the common subset for each tool pair and discuss how the exclusion might affect the precision conclusions.
minor comments (5)
  1. [§VI-A1] The sentence 'We do not use real execution traces as ground truth' is confusing given that the trace coverage metric is computed from historical transaction traces; please clarify the distinction between using traces for coverage and using them as ground truth for path feasibility.
  2. [§VI-A2] The notation '∥' for the number of TPs/FPs/FNs is nonstandard; use |TP|, |FP|, |FN| or explicit counts.
  3. [§V-C] The footnote mentions a GitHub repository but does not provide a URL or state that the tool is publicly released; please include the repository link and a statement on availability for reproducibility.
  4. [§IV / Fig. 2] The labels 'P X S' and 'P1 P2' in Fig. 2 are not self-explanatory; consider expanding the caption to define the stack contents and instruction roles.
  5. [§I] There are minor typos, e.g., 'detectbenign' is missing a space, and 'a execution trace' should be 'an execution trace.'

Circularity Check

1 steps flagged · score 2.0 of 10

Minor self-definitional invariant in the no-polymorphic-jump-targets evidence; core precision claims are externally benchmarked and not circular.

  1. self definitional [§VI-A2, 'Result' paragraph (code reuse detection)]
    "The root cause of polymorphic jump targets is that multiple predecessors of reused code push different pre-pushed jump operands. ... The result is that there are no polymorphic jump targets in Esuer-generated CFGs. ... The result proves that the method of Esuer can eliminate code reuse in generated CFGs."

    Polymorphic jump targets are defined as the symptom of different pre-pushed jump operands reaching the same block, and Esuer's Code Reuse Handler is explicitly designed to clone any successor whose tainted reuse context differs from a candidate's snapshot. Therefore 'zero polymorphic jump targets' is a logical invariant of the algorithm rather than an independent empirical confirmation. The paper uses this invariant as proof of reuse elimination, which is a mild self-definitional step. The main precision claims (trace coverage, compiler-tag F1, SolidiFI) remain externally benchmarked.

full rationale

The paper's central derivation is not circular. Definition 1 is an analytical characterization of compiler-introduced reuse, not a parameter fitted to the evaluation. The headline precision numbers rest on external evidence: 950,221 historical transaction traces for coverage; compiler tag information as reuse ground truth; and the SolidiFI vulnerability benchmark. The compiler-tag ground truth and Esuer's reuse-context detection both operate on pre-pushed jump operands, but the paper explicitly distinguishes pushed-but-unused tags from executed reuse (yielding FNs), so the F1 is a meaningful agreement measure rather than a tautology. The vulnerability detectors are built on Esuer, which is a standard utility evaluation, and the comparison is against other tools on an external benchmark. The one mild circular element is the 'no polymorphic jump targets' result: because the Code Reuse Handler clones any block whose tainted reuse context differs, the absence of polymorphic jump targets is an invariant of the algorithm, not an independent proof of reuse elimination. This is supplementary to the main externally grounded metrics and does not undermine the core derivation. The §VII memory/computed-jump limitation narrows the scope of the unqualified phrase 'eliminate code reuse,' but that is a scope limitation, not a circularity.

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

No fitted numeric parameters are used; the design choices are algorithmic. Key assumptions include EVM stack semantics for jump resolution, the sufficiency of pre-pushed jump operands as reuse indicators, and the use of compiler assembly tags as ground truth. The invented 'reuse context' notion is validated against compiler tags, which is an external oracle.

assumptions (4)
  • domain assumption EVM jump instructions obtain their target exclusively from the top of the stack, and JUMPDEST marks all valid jump targets.
    Used throughout §II-A and §V-B as the foundation for stack emulation and target resolution.
  • domain assumption Compiler-introduced code reuse always manifests as pre-pushed jump operands, so comparing these operands across visits to a basic block is sufficient to detect reuse.
    Definition 1 in §V states reuse context as pre-pushed jump operands; the paper does not prove this covers all compiler reuse patterns.
  • domain assumption The Solidity compiler's assembly 'tag' information is an accurate ground truth for code reuse.
    §VI-A2 compares Esuer's detections against assembly tags; the paper notes tags can be pushed but not used, so this ground truth is acknowledged to be imperfect.
  • domain assumption Historical transactions on Ethereum are a representative proxy for feasible execution traces and thus for CFG precision.
    §VI-A1 uses execution trace coverage as a precision metric; the authors note real transactions only trigger a small subset of paths, so this is an acknowledged proxy.
invented entities (1)
  • Reuse context independent evidence
    purpose: A stack-based descriptor (pre-pushed jump operands) used to compare execution contexts of a basic block and decide whether to clone it.
    Defined in Definition 1 and validated in §VI-A2 against compiler tag ground truth with F1 97.02%, providing an external handle via the compiler's assembly output.

how reviews work

0 comments
Cite this review

Pith. "Pith review of Building Reuse-Sensitive Control Flow Graphs (CFGs) for EVM Bytecode." pith.science (2026). https://pith.science/paper/IFPPQFSH

@misc{pith2026250514437,
  author       = {Pith},
  title        = {Pith review of: Building Reuse-Sensitive Control Flow Graphs (CFGs) for EVM Bytecode},
  year         = {2026},
  howpublished = {\url{https://pith.science/paper/IFPPQFSH}},
  note         = {Machine review of arXiv:2505.14437}
}
read the original abstract

The emergence of smart contracts brings security risks, exposing users to the threat of losing valuable cryptocurrencies, underscoring the urgency of meticulous scrutiny. Nevertheless, the static analysis of smart contracts in EVM bytecode faces obstacles due to flawed primitives resulting from code reuse introduced by compilers. Code reuse, a phenomenon where identical code executes in diverse contexts, engenders semantic ambiguities and redundant control-flow dependencies within reuse-insensitive CFGs. This work delves into the exploration of code reuse within EVM bytecode, outlining prevalent reuse patterns, and introducing Esuer, a tool that dynamically identifies code reuse when constructing CFGs. Leveraging taint analysis to dynamically identify reuse contexts, Esuer identifies code reuse by comparing multiple contexts for a basic block and replicates reused code for a reuse-sensitive CFG. Evaluation involving 10,000 prevalent smart contracts, compared with six leading tools, demonstrates Esuer's ability to notably refine CFG precision. It achieves an execution trace coverage of 99.94% and an F1-score of 97.02% for accurate identification of reused code. Furthermore, Esuer attains a success rate of 99.25%, with an average execution time of 1.06 seconds, outpacing tools generating reuse-insensitive CFGs. Esuer's efficacy in assisting identifying vulnerabilities such as tx.origin and reentrancy vulnerabilities, achieving F1-scores of 99.97% and 99.67%, respectively.

Figures

Figures reproduced from arXiv: 2505.14437 by the authors.

Figure 1
Figure 1. Reuse-sensitive and reuse-insensitive CFGs and data analysis for the example. The reused BB is in gray background. [PITH_FULL_IMAGE:figures/full_fig_p003_1.png] view at source ↗
Figure 2
Figure 2. Two different jump patterns in EVM bytecode. [PITH_FULL_IMAGE:figures/full_fig_p003_2.png] view at source ↗
Figure 3
Figure 3. Reuse patterns without real control-flow structures. [PITH_FULL_IMAGE:figures/full_fig_p003_3.png] view at source ↗
Figures from the paper (7 more)
Figure 5
Figure 5. Figure 5: High-level architecture of Esuer. TABLE I REFERENCE SYMBOLS Bc The BB processed in current iteration Bp A predecessor of Bc, which has been processed in previous iterations Bs A successor of Bc, which will be processed in following iterations Sstart The state of stack …
Figure 4
Figure 4. Figure 4: Reuse patterns with real control-flow structures. [PITH_FULL_IMAGE:figures/full_fig_p004_4.png]
Figure 6
Figure 6. Figure 6: An example to illustrate the basic idea of Esuer. [PITH_FULL_IMAGE:figures/full_fig_p007_6.png]
Figure 7
Figure 7. Figure 7: The statistics of the dataset. Mythril analyzes EVM bytecode with symbolic execution and constraint solving techniques. We find that Octopus crashes due to unsupported operations and fix them because we are more interested in comparing algorithms in CFG generation than…
Figure 8
Figure 8. Figure 8: The precision of all tools. A higher coverage with fewer paths indicates [PITH_FULL_IMAGE:figures/full_fig_p008_8.png]
Figure 9
Figure 9. Figure 9: The execution results and execution time of smart contracts of different sizes. The red line represents the average execution time for contracts of [PITH_FULL_IMAGE:figures/full_fig_p010_9.png]
Figure 10
Figure 10. Figure 10: Simplified source code and generated CFG for the reentrancy vulnerability in the contract [PITH_FULL_IMAGE:figures/full_fig_p011_10.png]

Discussion (0). Continue with ORCID to comment.

Reference graph

Works this paper leans on

67 extracted references · 60 canonical work pages

  1. [1]

    Attack analysis: How unchecked mapping makes 200m usd losses of nomad bridge,

    “Attack analysis: How unchecked mapping makes 200m usd losses of nomad bridge,” 2022, https://blocksecteam.medium.com/attack- analysis-how-unchecked-mapping-makes-200m-losses-of-nomad- bridge-441336e28924

    work page 2022

  2. [2]

    A new memory overwrite vulnerability discovered in wyvern protocol,

    “A new memory overwrite vulnerability discovered in wyvern protocol,” 2022, https://blocksecteam.medium.com/a-new-memory- overwrite-vulnerability-discovered-in-wyvern-protocol-5285996c297d

    work page 2022

  3. [3]

    How the mirror protocol got exploited,

    “How the mirror protocol got exploited,” 2022, https: //blocksecteam.medium.com/how-the-mirror-protocol-is-exploited- 33b5c1d48322

    work page 2022

  4. [4]

    Attack smart contract of daomaker,

    “Attack smart contract of daomaker,” 2022, https://etherscan.io/address/ 0x1c93290202424902a5e708b95f4ba23a3f2f3cee

    work page 2022

  5. [5]

    Attack smart contract of transitswap,

    “Attack smart contract of transitswap,” 2022, https://bscscan.com/ address/0x8021e721beb839ffdc80502e27014933aa6deaa6

    work page 2022

  6. [6]

    Crypto losses in 2022,

    “Crypto losses in 2022,” 2022, https://techcrunch.com/2023/01/05/ crypto-losses-in-2022-dropped-51-year-on-year-to-4b

    work page 2022

  7. [7]

    Vandal: A scalable security analysis framework for smart contracts,

    L. Brent, A. Jurisevic, M. Kong, E. Liu, F. Gauthier, V . Gramoli, R. Holz, and B. Scholz, “Vandal: A scalable security analysis framework for smart contracts,”arXiv preprint arXiv:1809.03981, 2018

    arXiv 2018

  8. [8]

    “Rattle,” 2022, https://github.com/crytic/rattle

    work page 2022

Show all 67 references
  1. [9]

    Ethersolve: Computing an accurate control-flow graph from ethereum bytecode,

    F. Contro, M. Crosara, M. Ceccato, and M. Dalla Preda, “Ethersolve: Computing an accurate control-flow graph from ethereum bytecode,” in 2021 IEEE/ACM 29th International Conference on Program Compre- hension (ICPC). IEEE, 2021, pp. 127–137

    2021

  2. [10]

    Enhancing ethereum smart-contracts static analysis by computing a precise control-flow graph of ethereum bytecode,

    M. Pasqua, A. Benini, F. Contro, M. Crosara, M. Dalla Preda, and M. Ceccato, “Enhancing ethereum smart-contracts static analysis by computing a precise control-flow graph of ethereum bytecode,”Journal of Systems and Software, vol. 200, p. 111653, 2023

    2023

  3. [11]

    Octopus,

    “Octopus,” 2022, https://github.com/FuzzingLabs/octopus

    2022

  4. [12]

    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, 2016, pp. 254–269

    2016

  5. [13]

    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

  6. [14]

    Ethir: A framework for high-level analysis of ethereum bytecode,

    E. Albert, P. Gordillo, B. Livshits, A. Rubio, and I. Sergey, “Ethir: A framework for high-level analysis of ethereum bytecode,” inInterna- tional symposium on automated technology for verification and analysis. Springer, 2018, pp. 513–520

    2018

  7. [15]

    Erays: reverse engineering ethereum’s opaque smart contracts,

    Y . Zhou, D. Kumar, S. Bakshi, J. Mason, A. Miller, and M. Bailey, “Erays: reverse engineering ethereum’s opaque smart contracts,” in27th USENIX security symposium (USENIX Security 18), 2018, pp. 1371– 1385

    2018

  8. [16]

    Large-scale empirical study of inline assembly on 7.6 million ethereum smart contracts,

    Z. Liao, S. Song, H. Zhu, X. Luo, Z. He, R. Jiang, T. Chen, J. Chen, T. Zhang, and X.-s. Zhang, “Large-scale empirical study of inline assembly on 7.6 million ethereum smart contracts,”IEEE Transactions on Software Engineering, 2022

    2022

  9. [17]

    Etherscan,

    “Etherscan,” 2022, https://etherscan.io/

    2022

  10. [18]

    Gigahorse: thor- ough, declarative decompilation of smart contracts,

    N. Grech, L. Brent, B. Scholz, and Y . Smaragdakis, “Gigahorse: thor- ough, declarative decompilation of smart contracts,” in2019 IEEE/ACM 41st International Conference on Software Engineering (ICSE). IEEE, 2019, pp. 1176–1186

    2019

  11. [19]

    Elipmoc: Advanced decompilation of ethereum smart contracts,

    N. Grech, S. Lagouvardos, I. Tsatiris, and Y . Smaragdakis, “Elipmoc: Advanced decompilation of ethereum smart contracts,”Proceedings of the ACM on Programming Languages, vol. 6, no. OOPSLA1, pp. 1–27, 2022

    2022

  12. [20]

    How effective are smart contract analysis tools? evaluating smart contract static analysis tools using bug injection,

    A. Ghaleb and K. Pattabiraman, “How effective are smart contract analysis tools? evaluating smart contract static analysis tools using bug injection,” inProceedings of the 29th ACM SIGSOFT International Symposium on Software Testing and Analysis, 2020, pp. 415–427

    2020

  13. [21]

    Ethereum: A secure decentralised generalised trans- action ledger,

    G. Woodet al., “Ethereum: A secure decentralised generalised trans- action ledger,”Ethereum project yellow paper, vol. 151, no. 2014, pp. 1–32, 2014

    2014

  14. [22]

    Binance smart chain (bsc),

    “Binance smart chain (bsc),” 2022, https://bscscan.com/

    2022

  15. [23]

    Polygon,

    “Polygon,” 2022, https://polygon.technology/

    2022

  16. [24]

    Jakstab: A static analysis platform for binaries,

    J. Kinder and H. Veith, “Jakstab: A static analysis platform for binaries,” inInternational Conference on Computer Aided Verification. Springer, 2008, pp. 423–427

    2008

  17. [25]

    Static disassembly of obfuscated binaries,

    C. Kruegel, W. Robertson, F. Valeur, and G. Vigna, “Static disassembly of obfuscated binaries,” inUSENIX security Symposium, vol. 13, 2004, pp. 18–18

    2004

  18. [26]

    Disassembly of executable code revisited,

    B. Schwarz, S. Debray, and G. Andrews, “Disassembly of executable code revisited,” inNinth Working Conference on Reverse Engineering,

  19. [27]

    Constructing precise control flow graphs from binaries,

    L. Xu, F. Sun, and Z. Su, “Constructing precise control flow graphs from binaries,”University of California, Davis, Tech. Rep, pp. 14–23, 2009

    2009

  20. [28]

    The optimizer in solidity compiler,

    “The optimizer in solidity compiler,” 2024, https://docs.soliditylang.org/ en/latest/internals/optimizer.html. JOURNAL OF LATEX CLASS FILES, VOL. 14, NO. 8, AUGUST 2021 13

    2024

  21. [29]

    Simple generation of static single- assignment form,

    J. Aycock and N. Horspool, “Simple generation of static single- assignment form,” inInternational Conference on Compiler Construc- tion, 2000, pp. 110–125

    2000

  22. [30]

    Efficiently computing static single assignment form and the control dependence graph,

    R. Cytron, J. Ferrante, B. K. Rosen, M. N. Wegman, and F. K. Zadeck, “Efficiently computing static single assignment form and the control dependence graph,”ACM Transactions on Programming Languages and Systems (TOPLAS), vol. 13, no. 4, pp. 451–490, 1991

    1991

  23. [31]

    Global value numbers and redundant computations,

    B. K. Rosen, M. N. Wegman, and F. K. Zadeck, “Global value numbers and redundant computations,” inProceedings of the 15th ACM SIGPLAN-SIGACT symposium on Principles of programming languages, 1988, pp. 12–27

    1988

  24. [32]

    Two jump patterns in solidity com- piler,

    Ethereum, “Two jump patterns in solidity com- piler,” 2024, https://github.com/ethereum/solidity/blob/ d42f92bd68d76db01b0dc17477cd4c7716059d93/libevmasm/ Assembly.h#L85-L88

    2024

  25. [33]

    Jump patterns for reuse in solidity compiler,

    Ethereum., “Jump patterns for reuse in solidity compiler,” 2024, https://github.com/ethereum/solidity/blob/develop/libsolidity/codegen/ CompilerContext.h#L212-L215

    2024

  26. [34]

    A large-scale empirical study on control flow identification of smart contracts,

    T. Chen, Z. Li, Y . Zhang, X. Luo, T. Wang, T. Hu, X. Xiao, D. Wang, J. Huang, and X. Zhang, “A large-scale empirical study on control flow identification of smart contracts,” in2019 ACM/IEEE International Sym- posium on Empirical Software Engineering and Measurement (ESEM). I...

    2019

  27. [35]

    Solidifi-benchmark,

    D. S. Lab, “Solidifi-benchmark,” 2024, https://github.com/ DependableSystemsLab/SolidiFI-benchmark

    2024

  28. [36]

    Mythril,

    “Mythril,” 2022, https://github.com/ConsenSys/mythril

    2022

  29. [37]

    Analysis of the dao exploit

    P. Daian, “Analysis of the dao exploit.” 2016, https: //hackingdistributed.com/2016/06/18/analysis-of-the-dao-exploit/

    2016

  30. [38]

    Smart contract : Security patterns,

    S. Go, “Smart contract : Security patterns,” 2018, https://medium.com/ returnvalues/smart-contract-securitypatterns-79e03b5a1659

    2018

  31. [39]

    Solidity smart contract security: 4 ways to prevent reentrancy attacks,

    insurgent, “Solidity smart contract security: 4 ways to prevent reentrancy attacks,” 2022, https://betterprogramming.pub/solidity-smart-contract- security-preventing-reentrancy-attacks-fc729339a3ff

    2022

  32. [40]

    “Eveem,” 2022, https://www.eveem.org/about/

    2022

  33. [41]

    Decompiler in etherscan,

    “Decompiler in etherscan,” 2022, https://etherscan.io/bytecode- decompiler

    2022

  34. [42]

    Porosity: A decompiler for blockchain-based smart con- tracts bytecode,

    M. Suiche, “Porosity: A decompiler for blockchain-based smart con- tracts bytecode,”DEF con, vol. 25, no. 11, 2017

    2017

  35. [43]

    Securify: Practical security analysis of smart contracts,

    P. Tsankov, A. Dan, D. Drachsler-Cohen, A. Gervais, F. Buenzli, and M. Vechev, “Securify: Practical security analysis of smart contracts,” inProceedings of the 2018 ACM SIGSAC conference on computer and communications security, 2018, pp. 67–82

    2018

  36. [44]

    Ethainter: a smart contract security analyzer for composite vulner- abilities,

    L. Brent, N. Grech, S. Lagouvardos, B. Scholz, and Y . Smaragdakis, “Ethainter: a smart contract security analyzer for composite vulner- abilities,” inProceedings of the 41st ACM SIGPLAN Conference on Programming Language Design and Implementation, 2020, pp. 454– 469

    2020

  37. [45]

    {ETHBMC}: A bounded model checker for smart contracts,

    J. Frank, C. Aschermann, and T. Holz, “{ETHBMC}: A bounded model checker for smart contracts,” in29th USENIX Security Symposium (USENIX Security 20), 2020, pp. 2757–2774

    2020

  38. [46]

    Manticore: A user-friendly symbolic execution framework for binaries and smart contracts,

    M. Mossberg, F. Manzano, E. Hennenfent, A. Groce, G. Grieco, J. Feist, T. Brunson, and A. Dinaburg, “Manticore: A user-friendly symbolic execution framework for binaries and smart contracts,” in2019 34th IEEE/ACM International Conference on Automated Software Engineer- ing (AS...

    2019

  39. [47]

    Sailfish: Vetting smart contract state-inconsistency bugs in seconds,

    P. Bose, D. Das, Y . Chen, Y . Feng, C. Kruegel, and G. Vigna, “Sailfish: Vetting smart contract state-inconsistency bugs in seconds,” in2022 IEEE Symposium on Security and Privacy (SP). IEEE, 2022, pp. 161– 178

    2022

  40. [48]

    Osiris: Hunting for integer bugs in ethereum smart contracts,

    C. F. Torres, J. Sch ¨utte, and R. State, “Osiris: Hunting for integer bugs in ethereum smart contracts,” inProceedings of the 34th annual computer security applications conference, 2018, pp. 664–676

    2018

  41. [49]

    Demystifying random number in ethereum smart contract: taxonomy, vulnerability identification, and attack detection,

    P. Qian, J. He, L. Lu, S. Wu, Z. Lu, L. Wu, Y . Zhou, and Q. He, “Demystifying random number in ethereum smart contract: taxonomy, vulnerability identification, and attack detection,”IEEE Transactions on Software Engineering, vol. 49, no. 7, pp. 3793–3810, 2023

    2023

  42. [50]

    Effi- ciently detecting reentrancy vulnerabilities in complex smart contracts,

    Z. Wang, J. Chen, Y . Wang, Y . Zhang, W. Zhang, and Z. Zheng, “Effi- ciently detecting reentrancy vulnerabilities in complex smart contracts,” arXiv preprint arXiv:2403.11254, 2024

    2024 arXiv

  43. [51]

    Smartdagger: a bytecode- based static analysis approach for detecting cross-contract vulnerability,

    Z. Liao, Z. Zheng, X. Chen, and Y . Nan, “Smartdagger: a bytecode- based static analysis approach for detecting cross-contract vulnerability,” inProceedings of the 31st ACM SIGSOFT International Symposium on Software Testing and Analysis, 2022, pp. 752–764

    2022

  44. [52]

    Empirical review of automated analysis tools on 47,587 ethereum smart contracts,

    T. Durieux, J. F. Ferreira, R. Abreu, and P. Cruz, “Empirical review of automated analysis tools on 47,587 ethereum smart contracts,” inPro- ceedings of the ACM/IEEE 42nd International conference on software engineering, 2020, pp. 530–541

    2020

  45. [53]

    Smart contract and defi security: Insights from tool evaluations and practitioner surveys,

    S. Chaliasos, M. A. Charalambous, L. Zhou, R. Galanopoulou, A. Ger- vais, D. Mitropoulos, and B. Livshits, “Smart contract and defi security: Insights from tool evaluations and practitioner surveys,”arXiv preprint arXiv:2304.02981, 2023

    2023 arXiv

  46. [54]

    Empirical evaluation of smart contract testing: What is the best choice?

    M. Ren, Z. Yin, F. Ma, Z. Xu, Y . Jiang, C. Sun, H. Li, and Y . Cai, “Empirical evaluation of smart contract testing: What is the best choice?” inProceedings of the 30th ACM SIGSOFT international symposium on software testing and analysis, 2021, pp. 566–579

    2021

  47. [55]

    Smart contract and defi security tools: Do they meet the needs of practitioners?

    S. Chaliasos, M. A. Charalambous, L. Zhou, R. Galanopoulou, A. Ger- vais, D. Mitropoulos, and B. Livshits, “Smart contract and defi security tools: Do they meet the needs of practitioners?” inProceedings of the 46th IEEE/ACM International Conference on Software Engineering, 20...

    2024

  48. [56]

    Static application security testing (sast) tools for smart contracts: How far are we?

    K. Li, Y . Xue, S. Chen, H. Liu, K. Sun, M. Hu, H. Wang, Y . Liu, and Y . Chen, “Static application security testing (sast) tools for smart contracts: How far are we?”arXiv preprint arXiv:2404.18186, 2024

    2024 arXiv

  49. [57]

    Large-scale study of vulnerability scanners for ethereum smart contracts,

    C. Sendner, L. Petzi, J. Stang, and A. Dmitrienko, “Large-scale study of vulnerability scanners for ethereum smart contracts,” in2024 IEEE Symposium on Security and Privacy (SP). IEEE Computer Society, 2024, pp. 220–220

    2024

  50. [58]

    Demystifying the composition and code reuse in solidity smart contracts,

    K. Sun, Z. Xu, C. Liu, K. Li, and Y . Liu, “Demystifying the composition and code reuse in solidity smart contracts,” inProceedings of the 31st ACM Joint European Software Engineering Conference and Symposium on the Foundations of Software Engineering, 2023, pp. 796–807

    2023

  51. [59]

    Code cloning in smart contracts on the ethereum platform: An extended replication study,

    F. Khan, I. David, D. Varro, and S. McIntosh, “Code cloning in smart contracts on the ethereum platform: An extended replication study,” IEEE Transactions on Software Engineering, vol. 49, no. 4, pp. 2006– 2019, 2022

    2006

  52. [60]

    Understanding code reuse in smart contracts,

    X. Chen, P. Liao, Y . Zhang, Y . Huang, and Z. Zheng, “Understanding code reuse in smart contracts,” in2021 IEEE International Conference on Software Analysis, Evolution and Reengineering (SANER). IEEE, 2021, pp. 470–479

    2021

  53. [61]

    Blockscope: Detecting and investigating propagated vulnerabilities in forked blockchain projects,

    X. Yi, Y . Fang, D. Wu, and L. Jiang, “Blockscope: Detecting and investigating propagated vulnerabilities in forked blockchain projects,” arXiv preprint arXiv:2208.00205, 2022

    2022 arXiv

  54. [62]

    Detecting code reuse in android applications using component-based control flow graph,

    X. Sun, Y . Zhongyang, Z. Xin, B. Mao, and L. Xie, “Detecting code reuse in android applications using component-based control flow graph,” inICT Systems Security and Privacy Protection: 29th IFIP TC 11 International Conference, SEC 2014, Marrakech, Morocco, June 2-4,

    2014

  55. [63]

    A survey on software clone detection research,

    C. K. Roy and J. R. Cordy, “A survey on software clone detection research,”Queen’s School of computing TR, vol. 541, no. 115, pp. 64– 68, 2007

    2007

  56. [64]

    No more gotos: Decompilation using pattern-independent control-flow structuring and semantic-preserving transformations

    K. Yakdan, S. Eschweiler, E. Gerhards-Padilla, and M. Smith, “No more gotos: Decompilation using pattern-independent control-flow structuring and semantic-preserving transformations.” inNDSS. Citeseer, 2015

    2015

  57. [65]

    Decompilation of binary programs,

    C. Cifuentes and K. J. Gough, “Decompilation of binary programs,” Software: Practice and Experience, vol. 25, no. 7, pp. 811–829, 1995

    1995

  58. [2002]

    Proceedings.IEEE, 2002, pp. 45–54

    2002

  59. [2014]

    Springer, 2014, pp

    Proceedings 29. Springer, 2014, pp. 142–155

    2014

Pith tools

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