crytic
Echidna FAQ
Echidna is having a lot of options and features, and it's difficult to remember where to find everything in the doc. We could have a small summary of the most common question somewhere (building-secure-contract, or Echidna readme]
On the top of my head, the frequent questions can be answered with:
| What | How | Reference |
|---|---|---|
| Enable assertion checking | checkAsserts: true |
How to test assertions |
| Fuzz all contracts | multi-abi: true |
TODO |
Change msg.sender |
sender, psender, |
TODO |
| Filter functions | filterBlacklist / filterFunctions |
Filtering functions to call during a fuzzing campaign |
| See the code explored | corpus-dir |
Collecting and visualizing coverage |
| Benchmark gas usage | estimateGas: true |
Finding transactions with high gas consumption |
| Debug initialization | Run slither on the target | TODO |
| Add Echidna to the CI | Use echidna-action |
See the gh action's documentation |
| Install the latest version | pip install slither-analyzer and, download Echidna static binary from the release page |
What else?
Related
- https://github.com/crytic/building-secure-contracts/issues/74
- https://github.com/crytic/building-secure-contracts/issues/79
Some basic questions I saw in EH:
- Why corpus is collected?
- How coverage is used?
- How transactions are mutated?
- Why echidna won't work with constructors with parameters?
- Why a property will not "finish" testing? (usually when the contracts are large)
- When to use assertions?
I think it would be good to split up sender and psender (not used when in assertion mode). I mix the two up a lot.
As we have frequent questions around those topics, this should be one of our priority, to do before the EOY
If I may join the conversation, as a new user, I had trouble finding the wiki in the first place. Some config options are self-explanatory, and the user experience is much better once you know them. Adding links to the wiki in more areas (like in the exercise section in the building secure smart contracts repo) would benefit the users.
I have found this default.yaml config file first before the wiki.
From a quick look, it contains more config options than the wiki (37 as compared to 28). It gets the job done, but I have found wiki to be much more pleasant to work with, as each option is explained in greater detail there.
I have multiple browser pages open in my current workflow as the resources are scattered across multiple repositories (echidna repo, building secure smart contracts + the wiki). This is just an idea, but it would be cool to have everything in a wiki (even if it would be straight-up copied from other pages).
A downside to this approach is that there is no easy way to create pull requests to the wiki directly (as far as I know), so it would be harder to contribute.