{"id":"e03f6480-2f70-4b72-86c0-9f7bc3ae4f2a","arxiv_id":"2505.14437","paper_version":1,"verdict":"CONDITIONAL","confidence":"HIGH","novelty_score":7.0,"correctness_risk":"medium","formal_verification":"none","parameter_count":0,"one_line_summary":"Esuer constructs reuse-sensitive CFGs for EVM bytecode by tainting pre-pushed jump operands and cloning reused basic blocks, improving precision and downstream vulnerability detection.","lead":"This paper builds a control flow graph construction tool for Ethereum smart contracts that detects and clones reused bytecode, yielding fewer infeasible paths and better vulnerability detection. It introduces a dynamic taint-based method to identify code reuse contexts.","discovery_kind":"new_method","skeptic_critique":{"model":"deepseek-v4-flash","headline":"Definition 1 ties code reuse to pre-pushed jump operands; memory/computed jump contexts are excluded, so the unqualified claim that Esuer 'eliminates code reuse' is overbroad and is not measured by the reported F1.","rationale":"The reader's weakest_assumption is the same load-bearing point: the method equates detectable reuse with a difference in pre-pushed jump operands. My reading of the paper confirms this is not a strawman. The algorithm in §V-B2/B3 selects or clones successors purely by comparing tainted values in S_start/S_end, and §VII explicitly concedes that memory-stored and calculated jump targets are outside scope. The two old-Vyper contracts in §VI-A1 are direct evidence that the excluded class occurs in real code, and the 99.94% coverage figure is an average that hides this failure mode. This does not invalidate the core contribution: for the common Solidity/compiler patterns that do push continuation targets onto the stack, Esuer plausibly removes fake joins and fake loops, and the large evaluation, honest limitation section, and downstream detector results support that narrower claim. But the abstract's unqualified 'eliminate code reuse' and the RQ1 statement that Esuer 'successfully eliminates code reuse' are stronger than the evidence. Since the paper already reports the memory-jump limitation and the reader already conditioned the verdict on this assumption, the verdict should remain CONDITIONAL. I would not move it to REJECT because the central mechanism is coherent for its intended class and the evaluation, while proxy-based, is extensive. The concrete test above would sharpen the boundary of the claim: either it confirms the omission behavior (overclaim detected) or, if Esuer somehow handles memory-jump reuse in a minimal case, it would show the limitation is less severe than stated.","tokens_in":22720,"tokens_out":12598,"duration_ms":123421,"concrete_test":"Reproduce the two old-Vyper contracts from §VI-A1, or build a minimal EVM contract whose continuation target is stored in memory (MSTORE/MLOAD before JUMP), and run Esuer. Inspect the output CFG: if the reused block has no outgoing edges or only one edge where the real bytecode has two distinct successors, Esuer omitted the reuse rather than eliminating it. Second, on the full 10k dataset, recompute the code-reuse F1 restricted to instances whose continuation target is a pre-pushed stack value; if the restricted F1 is materially above 97.02%, the reported metric mixes detectability-class coverage with correctness.","verdict_should_be":"UNCHANGED","load_bearing_attack":"The central claim requires that every compiler-introduced code reuse is observable as a difference in the pre-pushed jump operand in a block's S_start (Definition 1, §V). But Definition 1 also defines 'reuse context' as exactly those operands, so any reuse whose continuation target is not a directly comparable pre-pushed stack value is invisible to the detector by construction. §VII admits Esuer cannot handle jumps using memory-stored operands or calculated jump targets, and §VI-A1 reports that two old-Vyper contracts lose 138 execution traces precisely because jump operands are stored in memory. In those cases Esuer does not resolve the reuse; it omits the edge, which is why the CFG shows 'no polymorphic jump targets.' The F1 evaluation in §VI-A2 uses compiler tag-push as ground truth, but tags that are pushed and never executed are counted as FNs and tags for memory/computed jumps are outside the mechanism, so the 97.02% F1 measures only the subclass of reuse patterns that match the detector's own precondition. Thus the headline 'eliminate code reuse' conflates 'resolve all reuse in the supported pattern class' with 'eliminate code reuse in EVM bytecode.' This is a scope limitation rather than an internal contradiction, but it is load-bearing because the abstract and RQ1 answers are unqualified and the completeness claim is achieved partly by dropping unsupported edges.","agreement_with_reader":"agree"},"referee_report":{"model":"deepseek-v4-flash","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.","tokens_in":22894,"tokens_out":6162,"duration_ms":59834,"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":[{"comment":"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.","section":"§V-B2 / Definition 1 / §VII / §VI-A1"},{"comment":"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.","section":"§VI-A2"},{"comment":"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.","section":"Abstract / §VI-B / Table II"},{"comment":"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.","section":"§VI-A1 / Fig. 8"}],"minor_comments":[{"comment":"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.","section":"§VI-A1"},{"comment":"The notation '∥' for the number of TPs/FPs/FNs is nonstandard; use |TP|, |FP|, |FN| or explicit counts.","section":"§VI-A2"},{"comment":"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.","section":"§V-C"},{"comment":"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.","section":"§IV / Fig. 2"},{"comment":"There are minor typos, e.g., 'detectbenign' is missing a space, and 'a execution trace' should be 'an execution trace.'","section":"§I"}],"recommendation":"major_revision","confidential_remarks":"The manuscript presents a useful and well-evaluated tool, but the central scope of the claim ('eliminate code reuse') is narrower than the abstract and RQ1 answers suggest. The paper's own limitations section (§VII) and the reported loss of traces in §VI-A1 make this a fixable scope issue rather than a fundamental contradiction. The comparison of path ratios is also potentially biased by the common-contracts restriction, which deserves explicit discussion. The paper is within the journal's scope and the empirical work is substantial; I believe it can be revised to address these concerns."},"author_rebuttal":null,"desk_editor":{"model":"deepseek-v4-flash","letter":"Esuer is a serious, well-executed systems paper. The core observation is correct: compilers do introduce code reuse in EVM bytecode, and reuse-insensitive CFGs create infeasible paths and spurious control-flow dependencies. The eight reuse patterns are a useful taxonomy, and the dynamic taint-based reuse-context method is a sensible way to decide when to clone a basic block. On a large dataset (10,000 contracts, six tools compared), the reported improvements in path count and execution-trace coverage are consistent with the mechanism, and the downstream vulnerability detection numbers on SolidiFI give the paper practical teeth. No parameter fitting is visible; the comparison to compiler tags and historical traces is legitimate evidence, though proxy evidence.\n\nI agree with the stress-test note: the scope limitation is real and load-bearing. Definition 1 defines reuse context as pre-pushed jump operands, so any reuse that depends on memory-stored or calculated jump targets is invisible to the detector by construction. Section VII admits this, and the two old-Vyper contracts losing 138 traces are the concrete symptom. The paper's unqualified phrasing—'eliminate code reuse'—overstates what is shown. What Esuer actually does is eliminate the reuse patterns that fall inside its stack-operand model, and that is still a meaningful achievement. The F1 of 97.02% measures only the supported pattern class, because the compiler-tag ground truth also excludes memory/computed targets and counts pushed-but-never-executed tags as false negatives. The paper is reasonably honest about this in the discussion, but the abstract and RQ1 answer should carry the same caveat.\n\nMinor issues: the abstract says Esuer 'outpaces tools generating reuse-insensitive CFGs,' but Ethersolve is both reuse-insensitive and faster (0.86s vs 1.06s). The paper does say 'second fastest' in the evaluation, so this is an abstract-level overclaim, not a data fabrication. No code or dataset artifact is provided, which makes independent reproduction harder; given the tool-building nature of the work, I would want that fixed at review.\n\nOverall, the central claim holds for the defined pattern class, and the paper is a solid incremental-to-substantial contribution for people building EVM bytecode analyzers. It deserves a serious peer review, not a desk reject. I would send it to referees with a request to tighten the scope language and, ideally, release the artifact.","headline":"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.","tokens_in":23519,"tokens_out":1328,"would_cite":true,"duration_ms":15340,"reading_group":"maybe","serious_thinker":"yes","would_accept_peer_review":true},"rs_alignment":null,"lean_confirmation":null,"pith_extraction":{"msc":[],"pacs":[],"model":"deepseek-v4-flash","headline":"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.","keywords":["control flow graph","EVM bytecode","code reuse","reuse-sensitive CFG","static analysis","smart contracts","stack emulation","taint analysis"],"falsifier":"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.","tokens_in":22450,"feed_emoji":"🔁","tokens_out":8503,"duration_ms":82469,"temperature":0.7,"pith_summary":"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.","feed_headline":"Clone reused code: EVM CFGs hit 99.94% trace coverage","feed_subtitle":"Esuer spots compiler-introduced code reuse from pre-pushed jump operands and removes fake loops and joins.","key_machinery":"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.","core_discovery":"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.","pith_inferences":["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."],"forward_implications":["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."],"supporting_citations":[{"why":"Supplies the formal EVM opcode and stack semantics used for disassembly and symbolic stack emulation.","marker":"[21]"},{"why":"Baseline CFG construction method that keeps only jump operands in the stack; the paper's comparison shows it produces roughly 30 times as many paths.","marker":"[9]"},{"why":"Extended version of the same baseline, reinforcing the reuse-insensitive comparison point for reduced trace coverage.","marker":"[10]"},{"why":"Decompilation approach that clones blocks during function recovery but, per the evaluation, leaves polymorphic jump targets in 11.17% of generated CFGs.","marker":"[18]"},{"why":"Advanced decompiler that the paper contrasts with Esuer to argue that compiler-version-independent, dynamic reuse identification is needed.","marker":"[19]"},{"why":"Provides the SolidiFI vulnerability-injection dataset and ground truth used to measure downstream effectiveness of Esuer's CFGs.","marker":"[20]"},{"why":"Documents the two jump patterns in the Solidity compiler that motivate the pre-pushed jump operand definition of reuse context.","marker":"[32]"},{"why":"Documents the compiler's tag mechanism used to identify reused code in assembly, serving as the proxy ground truth for reuse detection.","marker":"[33]"},{"why":"The empirical survey of control-flow identification in EVM tools that frames the limitations Esuer sets out to fix.","marker":"[34]"}],"fun_headline_variants":["Esuer clones reused code, EVM CFGs hit 99.94% coverage","Taint-based CFG builder: Esuer beats 6 tools on 10k contracts","Reuse-sensitive EVM CFGs: 99.94% trace coverage, 1.06s avg","How Esuer detects code reuse: jump operand contexts drive CFG precision","EVM bytecode static analysis: Esuer's CFG precision up, execution traces 99.94%"],"cache_read_input_tokens":3200,"weakest_assumption_plain":"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.","fun_headline_variants_meta":{"raw":{"variants":["Esuer clones reused code, EVM CFGs hit 99.94% coverage","Taint-based CFG builder: Esuer beats 6 tools on 10k contracts","Reuse-sensitive EVM CFGs: 99.94% trace coverage, 1.06s avg","How Esuer detects code reuse: jump operand contexts drive CFG precision","EVM bytecode static analysis: Esuer's CFG precision up, execution traces 99.94%"]},"model":"deepseek-v4-flash","effort":"low","cost_usd":0.000198,"raw_usage":{"total_tokens":1391,"prompt_tokens":988,"completion_tokens":403,"prompt_tokens_details":{"cached_tokens":384},"prompt_cache_hit_tokens":384,"prompt_cache_miss_tokens":604,"completion_tokens_details":{"reasoning_tokens":284}},"tokens_in":604,"tokens_out":403,"duration_ms":4700,"temperature":1.0,"reasoning_tokens":284,"cache_read_input_tokens":384,"cache_creation_input_tokens":0},"cache_creation_input_tokens":0},"created_at":"2026-08-07T15:33:27.496466+00:00","model_set":{"reader":"deepseek-v4-flash"},"falsifier":"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.","supporting_citations":[{"cited_title":"Ethereum: A secure decentralised generalised trans- action ledger,","cited_arxiv_id":null,"evidence_quote":"Supplies the formal EVM opcode and stack semantics used for disassembly and symbolic stack emulation."},{"cited_title":"Ethersolve: Computing an accurate control-flow graph from ethereum bytecode,","cited_arxiv_id":null,"evidence_quote":"Baseline CFG construction method that keeps only jump operands in the stack; the paper's comparison shows it produces roughly 30 times as many paths."},{"cited_title":"Enhancing ethereum smart-contracts static analysis by computing a precise control-flow graph of ethereum bytecode,","cited_arxiv_id":null,"evidence_quote":"Extended version of the same baseline, reinforcing the reuse-insensitive comparison point for reduced trace coverage."},{"cited_title":"Gigahorse: thor- ough, declarative decompilation of smart contracts,","cited_arxiv_id":null,"evidence_quote":"Decompilation approach that clones blocks during function recovery but, per the evaluation, leaves polymorphic jump targets in 11.17% of generated CFGs."},{"cited_title":"Elipmoc: Advanced decompilation of ethereum smart contracts,","cited_arxiv_id":null,"evidence_quote":"Advanced decompiler that the paper contrasts with Esuer to argue that compiler-version-independent, dynamic reuse identification is needed."},{"cited_title":"How effective are smart contract analysis tools? evaluating smart contract static analysis tools using bug injection,","cited_arxiv_id":null,"evidence_quote":"Provides the SolidiFI vulnerability-injection dataset and ground truth used to measure downstream effectiveness of Esuer's CFGs."},{"cited_title":"Two jump patterns in solidity com- piler,","cited_arxiv_id":null,"evidence_quote":"Documents the two jump patterns in the Solidity compiler that motivate the pre-pushed jump operand definition of reuse context."},{"cited_title":"Jump patterns for reuse in solidity compiler,","cited_arxiv_id":null,"evidence_quote":"Documents the compiler's tag mechanism used to identify reused code in assembly, serving as the proxy ground truth for reuse detection."},{"cited_title":"A large-scale empirical study on control flow identification of smart contracts,","cited_arxiv_id":null,"evidence_quote":"The empirical survey of control-flow identification in EVM tools that frames the limitations Esuer sets out to fix."}],"review_version":1}