Source-linked AI summary
ItyFuzz: Snapshot-Based Fuzzer for Smart Contract
Chaofan Shou, Shangyin Tan, Koushik Sen
TL;DR
Stateful smart-contract fuzzing incurs re-execution overhead and can take hours or days, limiting real-time on-chain auditing. ItyFuzz snapshots states and uses waypoints to guide exploration; it reports high code and state coverage in seconds and supports on-chain auditing.
Problem
Method
ItyFuzz stores intermediate state snapshots and singleton transactions, using dataflow and other waypoints to prioritize interesting states for exploration.
Source: §1 · p. 2, §4.2 · p. 4, §4.3 · p. 5Results
ItyFuzz reports high code and state coverage in just a few seconds, supporting on-chain auditing of smart contracts.
Source: §1 · p. 1Takeaways & Limitations
The authors report using ItyFuzz for on-chain auditing to identify and prevent exploits in real-world smart-contract applications.
Source: §8 · p. 11ItyFuzz-DF can time out when dataflow bucketing excludes a crucial state needed to build the vulnerable final state.
Source: §6.2 · p. 8
Abstract
from arXiv · showhide
Smart contracts are critical financial instruments, and their security is of utmost importance. However, smart contract programs are difficult to fuzz due to the persistent blockchain state behind all transactions. Mutating sequences of transactions are complex and often lead to a suboptimal exploration for both input and program spaces. In this paper, we introduce a novel snapshot-based fuzzer ItyFuzz for testing smart contracts. In ItyFuzz, instead of storing sequences of transactions and mutating from them, we snapshot states and singleton transactions. To explore interesting states, ItyFuzz introduces a dataflow waypoint mechanism to identify states with more potential momentum. ItyFuzz also incorporates comparison waypoints to prune the space of states. By maintaining snapshots of the states, ItyFuzz can synthesize concrete exploits like reentrancy attacks quickly. Because ItyFuzz has second-level response time to test a smart contract, it can be used for on-chain testing, which has many benefits compared to local development testing. Finally, we evaluate ItyFuzz on real-world smart contracts and some hacked on-chain DeFi projects. ItyFuzz outperforms existing fuzzers in terms of instructional coverage and can find and generate realistic exploits for on-chain projects quickly.
1 INTRODUCTION
Smart contracts are difficult to fuzz because transactions change persistent state, while sequence-based tools incur re-execution costs and lack feedback for selecting promising states. ItyFuzz stores snapshots and uses state-focused waypoints to support faster exploration, including on-chain auditing.
1 INTRODUCTION
- ItyFuzz achieves high code and state coverage in seconds, supporting on-chain auditing that requires second-level response time.The paper identifies dynamically changing blockchain state and the need to test states reachable only on-chain as reasons for on-chain auditing.Source: §1 · p. 1
- Sequence-based fuzzers repeatedly rebuild prior states, with re-execution costs that grow as deeper states require longer transaction sequences.Existing tools also provide feedback on transactions but not on states, although the paper argues that state interestingness matters for stateful fuzzing.Source: §1 · p. 1
- ItyFuzz stores selected intermediate states as snapshots, enabling constant-complexity time travel and reducing the need to re-execute transactions.The paper notes that storing every snapshot is impractical because snapshot volume can grow to several gigabytes within seconds, motivating waypoints and corpus pruning.Source: §1 · pp. 1–2
- The authors propose applying snapshot fuzzing beyond smart contracts, where programs have efficiently represented states that can be observed during execution.Modern hardware designs are given as an example of another stateful domain.Source: §1 · p. 2
- ItyFuzz combines dataflow and comparison waypoints to prioritize interesting states and prune the state corpus.Dataflow waypoints use future memory loads; comparison waypoints use probabilistic sampling and hard comparison feedback.Source: §1 · p. 2
2 BACKGROUND
The background introduces coverage-guided fuzzing, generalized waypoint feedback, and the persistent state that makes smart-contract fuzzing require transaction sequences.
2.1 Fuzzing
- Coverage-guided fuzzers mutate corpus inputs and retain executions that reach new coverage points for future mutation.The simplified algorithm selects an input, generates mutations, executes them, and adds interesting inputs to the corpus.Source: §2.1 · p. 2
- Smart-contract fuzzers must generate transaction sequences because each transaction operates on persistent blockchain state.The section contrasts this with individually constructed inputs, which are ineffective for testing a contract in a given persistent state.Source: §2.1 · p. 2, §2.3 · p. 3
2.2 Waypoints
- Waypoints generalize feedback beyond coverage, and ItyFuzz uses dataflow and comparison waypoints to judge whether resulting states merit exploration.Other waypoint examples include execution time, memory usage, and distance between compared values.Source: §2.2 · pp. 2–3
2.3 Smart Contract
- Solidity programs are compiled to EVM bytecode to run on Ethereum, while smart-contract transactions create immutable, persistent state changes on the blockchain.Smart contracts are deployed on the blockchain and receive transactions as inputs.Source: §2.3 · p. 3
3 MOTIVATING EXAMPLE
The motivating example shows how state-building sequences make bugs harder to find as their required depth grows. Re-execution dominates SMARTIAN's time on the example, motivating ItyFuzz's use of interesting-state snapshots.
3 MOTIVATING EXAMPLE
- Real-world bug-triggering sequences can be long; Team Finance attackers used six transactions averaging 40 function calls each to build the vulnerable state.Source: §3 · p. 3
- As T increases, SMARTIAN fails to quickly find the bug because testing a transaction requires re-executing the sequence that reaches its state.The contract's buggy function triggers when the counter reaches T, and a larger T requires a longer sequence to build that state.Source: §3 · p. 3, Figure 3 · p. 3
- More than 90 percent of SMARTIAN's total fuzzing time on SimpleState with T = 10 is spent re-executing seen state-transaction pairs.The experiment distinguishes re-execution from exploration time.Source: §3 · p. 3, Figure 4 · p. 4
- ItyFuzz stores selected interesting states as snapshots so it can explore from them without re-executing the full preceding sequence.The paper describes snapshot selection as using waypoint ideas; it distinguishes storing interesting states from memoizing every intermediate state.Source: §3 · pp. 3–4
4 METHODOLOGY
ItyFuzz fuzzes state–transaction pairs and saves promising resulting states as snapshots, avoiding transaction re-execution. Dataflow and comparison waypoints identify states for future exploration and help manage the resulting state corpus.
4.1 ItyFuzz Architecture
- The EVM executor processes mutated state–transaction pairs, while execution waypoints guide the input corpus and state waypoints determine which resulting states to snapshot.The architecture treats the contract as part of the initial state and models execution as mapping a state and transaction to a new state.Source: §4.1 · p. 4
4.2 Snapshot-Based Fuzzing
- ItyFuzz stores state–transaction pairs and maintains a separate infant state corpus for promising post-execution states, avoiding re-execution to revisit them.Mutations can change either the transaction or the state selected from the infant corpus; resulting pairs and states are added according to their respective waypoint feedback.Source: §4.2 · p. 4
4.3 Dataflow Waypoint
- The dataflow waypoint treats a state as interesting when execution writes a new abstract value to a memory location previously observed by a load.Dynamic instrumentation observes loads and stores; locations and values are abstracted into a small address space and value buckets to reduce storage and evaluation costs.Source: §4.3 · pp. 5–6
4.4 Comparison Waypoint
- Fine-grained value buckets can retain intermediate states needed to reach a target, but can make the infant corpus consume substantial memory.Comparison waypoints also consider states interesting when comparison operands move closer, helping address the state-corpus overhead associated with fine-grained partitioning.Source: §4.4 · p. 6
- Comparison waypoints mark executions interesting when they reduce a recorded distance between comparison operands, and use votes to prioritize promising states.ItyFuzz alternates probabilistic and random sampling; when the infant corpus reaches a threshold, it prunes states with low votes relative to visits.Source: §4.4 · pp. 6–7
5 IMPLEMENTATION
ItyFuzz is built on LibAFL and uses revm for EVM execution and interpreter-hook instrumentation. Its modular design supports starting from blockchain states and extending the fuzzer to other chains or feedback mechanisms.
5 IMPLEMENTATION
- ItyFuzz uses LibAFL as its backbone and implements a separate state corpus for snapshotting.Customized feedback incorporates the dataflow and comparison waypoints.Source: §5 · p. 7
- Written in Rust, ItyFuzz uses revm as its EVM executor and interpreter hooks for dynamic instrumentation and fast snapshotting.The hooks collect dataflow and comparison information.Source: §5 · p. 7
- ItyFuzz can start from a state pulled from a specific block on blockchains that support a Geth client.Source: §5 · p. 7
- Its modular design allows additional chain executors and domain-specific feedback or waypoints to be added.The paper gives Solana as an example of another chain.Source: §5 · p. 7
6 EVALUATION
ItyFuzz is evaluated for instruction coverage, exploit discovery, state-storage overhead, and on-chain auditing. It improves coverage over SMARTIAN, finds concrete exploits in real projects, and can identify vulnerabilities from live chain states, though some attacks remain difficult to find offline.
6.2 Vulnerabilities
- ItyFuzz found concrete exploits in 36 of 42 previously exploited projects, averaging 13.8 seconds, and generated exploits in 21 projects among 45,000 projects fuzzed for five minutes each.The 21 projects had assets valued at over $500k; it also found arbitrary external-call and arbitrary ERC20-token-burning vulnerabilities in 1,384 projects holding over $8M.Source: §6.2 · pp. 7–8
6.1 Coverage
- On B1, B2, and B3, ItyFuzz achieves higher instruction coverage over time than SMARTIAN; on B1 it covers almost all instructions after 10 seconds, while SMARTIAN does not in one minute.The comparison uses instruction coverage over time; the figures show the total instruction count, with higher coverage better.Source: §6.1 · p. 7, Figure 7 · p. 8, Figure 8 · p. 8
6.2 Vulnerabilities
- For most tested vulnerabilities, ItyFuzz outperforms its ablations, especially on contracts with complex, deep state spaces where ItyFuzz-Rand and ItyFuzz-DF time out after one hour.Rarely, the dataflow-only ablation times out while the random-sampling ablation does not, because dataflow bucketing can omit distinct states that share a bucket.Source: §6.2 · p. 8
6.3 State Overhead
- ItyFuzz's infant-state corpus converges to a constant size, whereas ItyFuzz-Rand runs out of memory after approximately three seconds for most contracts.The dataflow-only ablation's corpus grows gradually for 20 seconds and then approximately stabilizes; ItyFuzz prunes the corpus to limit its size.Source: §6.3 · p. 9, Figure 10 · p. 9
6.4 On-Chain Auditing
- From the Nomad attack's starting block, ItyFuzz identified the vulnerability in 0.3 seconds, while the Team Finance vulnerability could not be found offline within one hour.For Nomad, the exploit finalized 1 hour 7 minutes after it began; the Team Finance attack required building a state satisfying several conditions and generating a correct sqrtPriceX96.Source: §6.4 · pp. 9–10
- ItyFuzz-On-chain can analyze contracts using real-time oracle prices when prices become skewed, a capability the authors say can prevent oracle-manipulation vulnerabilities.The authors note that no EVM-chain attack manipulating a price oracle had yet occurred at the time of writing.Source: §6.4 · p. 10
7 RELATED WORK
The related work describes limits in feedback for stateful contracts, state reuse, and existing security tools. ItyFuzz addresses these gaps with customized waypoints and snapshots built from concrete transactions.
7.1 Feedback-driven Fuzzing
- Coverage feedback can reach all instructions in increment and decrement functions yet fail to progress past a hard stateful guard hiding a bug.Source: §7.1 · p. 10
- Prior feedback mechanisms and waypoints target traditional software, while ItyFuzz proposes two feedback mechanisms tailored to stateful smart contracts.Source: §7.1 · p. 10
7.2 Stateful Fuzzing
- ItyFuzz stores only waypoint-selected interesting states and builds each state from concrete transactions, so each can be reproduced by a transaction sequence.Source: §7.2 · p. 11
7.3 Smart Contract Security Tools
- Existing smart-contract fuzzers, including ContractFuzzer, Echidna, Harvey, and SMARTIAN, have substantial re-execution overhead because they do not effectively reuse intermediate states.Source: §7.3 · p. 11
- Symbolic execution, verification, and static-analysis tools commonly require human involvement, whereas ItyFuzz is described as fully automated and able to detect bugs in seconds.Source: §7.3 · p. 11
8 CONCLUSION
The conclusion presents ItyFuzz as a snapshot-based smart-contract fuzzer that reduces re-execution overhead and uses customized waypoints to select interesting states. It reports fast reentrancy-exploit synthesis and low-response-time on-chain auditing.
8 CONCLUSION
- ItyFuzz stores intermediate states to reduce re-execution overhead when fuzzing smart contracts.Source: §8 · p. 11
- Customized waypoint mechanisms categorize and store interesting states to support program exploration.Source: §8 · p. 11
- State snapshots enable fast synthesis of reentrancy exploits, and the authors report low-response-time on-chain auditing to identify and prevent exploits.Source: §8 · p. 11