crytic
Fix and reorganize shrinking
The current shrinking implementation had a bug/limitation: it always tries to shrink the sender. In other words, if a transaction has a sender that is not minimal, Echidna will try to reduce it. However, the transaction might require a different sender to still cause the assertion failure, and the fact that Echidna will unconditionally try to lower it might cause the shrinking to get 'stuck'.
This commit reworks the shrinking process to try and favor a more incremental shrinking, with multiple passes of smaller changes. The old process consisted of:
- 50% chance of removing one tx
- 50% chance of (reducing sender and shrinking) all txs
The new process consists of, for each transaction independently:
- 35% chance of shrinking the transaction
- 30% chance of removing the transaction
- 30% chance of keeping the transaction as-is
- 5% chance of reducing sender
"wait" calls are treated differently:
- 60% chance of reducing or removing delay
- 40% chance of keeping it as-is
Fixes: #1224
Hi @elopez! Just checking in on this PR. If it’s still on hold, I can give it a shot and see if I can make progress. It would be helpful to have the contract and invariants to reproduce #1224, and to diff-check it before and after #1399.
Hi @BowTiedRadone! We merged https://github.com/crytic/echidna/pull/1399 to fix https://github.com/crytic/echidna/issues/1224 so that's no longer an issue. On the other hand, this is a larger refactor that kind of changes the approach to shrinking and that I feel might lead to better results. But as it is a significant change, it requires more experimentation and testing to find a sweet spot for the different weights and such, and to make sure it doesn't regress shrinking performance. You're more than welcome to play with the weights on some real life shrinking problems and report your observations if you want 😄