introduction
Fuzzing is essential for testing secure smart contracts, but it comes with challenges. Test execution is often slow and analyzing errors may require more time and effort.
Zooming out will fix this problem. If fuzzing discovers a bug during stateful testing, the reduction algorithm minimizes the sequence of operations required to reproduce it. This makes debugging faster and more efficient by turning complex errors into simpler ones.
Modern fuzzers such as Foundry, Echidna, and Wake support reduction, but each uses a different approach. This article compares the algorithms and pros and cons of each design.
Reduction Algorithm for Foundry Invariant Testing
Source: foundryshrink.rs
Foundry supports reduction during immutability testing using a top-down approach. Try removing the transaction at the beginning of the sequence and see if the error still occurs.
process:
- Starting from above, we remove one transaction at a time.
- Rerun the sequence to see if the fixation error persists.
- If the failure continues, leave the transaction in the removed state.
- Restore the transaction when it no longer fails.
- Repeat until you reach your limit of contraction or cannot reduce any further.
- It returns the shortest sequence that still causes a failure.
This method maintains failure invariance but does not attempt to reproduce other bugs. It also does not simplify function call parameters.
Of the three tools, Foundry uses the simplest minification strategy.
Echidna’s reduction algorithm
Source: Echidna Shrink.hs
Echidna combines structural reduction and parameter simplification to systematically reduce failed test cases to the minimum reproducible example.
- Replace the revert transaction with:
NoCall
Placeholders (except the final transaction, which is always maintained) - remove unnecessary
NoCall
Transactions that do not advance time or block numbers. - Apply one of two randomly selected strategies.
- “Shorten”: Removes one randomly selected transaction.
- “Minimize”: Simplify every transaction by:
- Reduce argument values (e.g. to smaller numbers or simpler addresses)
- Reduce ETH amount, gas price, time or block delay
- Replace sender with a simpler address
- Get rid of new useless things.
NoCall
Transactions resulting from downsizing. - Rerun the sequence to see if the error is still reproducible.
- Repeat until you reach your limit of contraction or cannot reduce any further.
Echidna supports both transaction and parameter reduction, allowing you to significantly reduce test cases for efficient debugging.
reduction parameter
Echidna also simplifies function input by reducing values to smaller numbers and replacing addresses with simpler numbers.
This ensures that bugs remain reproducible while progressively simplifying failure cases, making debugging faster and easier for developers.
Wake’s Reduction Algorithm
Source: Wake fuzz_shrink.py
Step 0: Collect flow status
Rerun the fuzzing sequence to collect initial state data and detailed error context from failed tests.
Step 1: Remove by flow type
- Lists all flow function types and their call counts.
- Start with the most frequent call type and try removing all calls of that kind.
- Rerun the sequence to see if the error still occurs.
Step 2: Step-by-step removal
We proceed through the sequence from top to bottom, removing individual flow features one at a time.
- If the error is still reproducible, keep the removal.
- If not, restore the removed currency.
Snapshots allow you to skip re-executing previously reduced portions of a sequence.
Wake is also supported shortcut key During contractions. If the same error occurs early in the sequence, it replaces the original with an earlier instance, often leading to a large reduction.
The main differences between the three
The fuzzing strategy used by Foundry, Echidna, and Wake directly shapes how each tool implements reduction.
Foundry takes the simplest approach. Purge by calling functions randomly and checking for invariants. The reduction algorithm only removes transactions and does not simplify parameters.
Echidna systematically explores execution paths by running for longer periods of time in shorter sequences. This often results in simpler failure cases by default. Reduction combines transaction elimination with parameter simplification. NoCall
Placeholder and randomization strategies to minimize failed inputs.
Wake applies differential fuzzing by reimplementing the contract logic in Python and checking the expected state. This allows precise targeting of attack vectors and internal inspections. However, Wake tends to produce longer sequences and therefore requires more aggressive reduction. The algorithm is in Python deepcopy
EVM state snapshots to support flexible test configurations. Unlike Echidna, it does not use failed transaction removal for testing flexibility.
conclusion
The best fuzzing tool depends on your testing goals and workflow. Foundry prioritizes simplicity and speed. Echidna focuses on radical minimization. Wake provides flexible state-aware differential testing.
Choosing the right approach means balancing reduced efficiency, execution time, and debugging clarity. This balance is important for efficiently finding and fixing bugs.