[Bug-Candidate]: Echidna fails to shrink call (revert) + vm.roll + vm.warp into only vm.roll + vm.warp

[aviggiano]

Describe the issue:

Description

In some scenarios, Echidna generates a failing sequence that contains a call, a block roll and a timestamp warp, where the call reverts, but where going forward in time is a pre-requisite for the sequence.

Ideally, the shrank sequence would ditch the call and only keep the roll and warp. In addition to keeping the sequences smaller, this makes it easier to convert the reproducer to Foundry, as we don't need to manually trim the reverting call function

Code example to reproduce the issue:

N/A (closed source)

Version:

Echidna 2.3.0

Relevant log output:

N/A

[aviggiano]

Same as crytic/medusa#752

[elopez]

We should have this in place already; one of the things shrinking does is convert reverted calls to NoCall while keeping the delays

echidna/lib/Echidna/Shrink.hs

Line 62 in 344bcfe

replaceByNoCall tx = tx { call = NoCall }

NoCall would show as *wait* on the traces.

For instance, this contract

contract C {
    uint256 c;

    constructor() { c = 0xffffffffffffffffffffffff; }

    function g() public {
       if (c == 0xffffffffffffffffffffffff) {
         c = block.timestamp;
       }
    }

   function h() public {
      revert();
   }

    function f() public {
      assert (c + 1000000 > block.timestamp);
      revert();
    }
}

shrinks to

(I suppose we could do one additional pass and coalesce the wait to the next call though)

Do you have an example where this doesn't occur?

Related: we have some WIP efforts to refactor the shrinking if you'd like to try them out: #1385

[aviggiano]

I forgot to mention, this is in optimization mode

I'll share a POC soon

[gustavo-grieco]

Do you have some POC around?

[aviggiano]

Yes the repo was made public recently so I can share a POC soon

https://github.com/Recon-Fuzz/aave-v4-scfuzzbench

But before we try to invest time on it, I just wanted to confirm this isn't a false positive:

The echidna.yaml config had specific values for maximum block roll and time warp, since I wanted to minimize assumptions for my finding, while at the same time optimizing for one of the broken invariants (relative difference between borrow and supply). So I suspect echidna was finding that the best way to maximize the metric was to execute no-ops (ie, transactions that reverted), with the pre-defined maximum roll and warp, but this is basically tricking the system. What I wanted was it to keep optimizing the metric while producing non-reverting txs, and the delta between each non reverting tx within the config

Does this make sense? does this behavior I described look like what is implemented?

[aviggiano]

POC here

Recon-Fuzz/aave-v4-scfuzzbench@v0.5.6-recon...poc/echidna-1505-delay-noop-optimization

Relevant files:

• repro setup note: reports/echidna-issue-1505-poc.md
• saved reproducer: reports/echidna-issue-1505-reproducer.txt

What was changed:

• switched echidna.yaml to optimization mode
• large delay bounds enabled (maxTimeDelay: 604800, maxBlockDelay: 60480)
• added an optimization target for borrow-vs-supply in tests/recon/Properties.sol

Run command:

  timeout 3600s echidna tests/recon/CryticTester.sol \
    --contract CryticTester \
    --config echidna.yaml \
    --format text \
    --workers 8 \
    --disable-slither \
    --test-limit 1000000000

In a 1h run, you can see Echidna reproducing the behavior I described: it will optimize through sequences with large time/block delays and many revert calls (effectively no-op calls). The otimization metric will go up but it's a hack