Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Fine-tune shrinking behavior #1276

Open
aviggiano opened this issue Jun 18, 2024 · 1 comment
Open

Fine-tune shrinking behavior #1276

aviggiano opened this issue Jun 18, 2024 · 1 comment

Comments

@aviggiano
Copy link

Describe the desired feature

Description

In most cases, shrinking a transaction input is not necessary to understand why a property broke.

This is especially true when bounding the input parameters since what Echidna sees as a maximum/minimum value may differ from what the clamping algorithm considers the valid range.

In some cases, such as in external testing, addresses are often mapped to Echidna's default list of actors (address(0x10000), address(0x20000), address(0x30000)), so converting from address(0x1fffffffe) to address(0xdeadbeef) is even more pointless.

Feature Request

This is a feature request to add additional configuration parameters to fine-tune the shrinking behavior.

Currently, as I understand it, the fuzzer tries to minimize both the number of calls that led to a broken property and each call's inputs.

By splitting the shrinkLimit value into shrinkLimitCalls and shrinkLimitValues, for example, we would allow developers to select which behavior they want from the fuzzer.

@rappie
Copy link

rappie commented Jul 16, 2024

I would like to have rudimentary support for tweaking the weights of different shrinking behaviours such as reducing variables vs. removing transactions.

Having this would be very useful in scenarios where many small transactions with opposite effects can be shrunk away to one or two single transactions.

Example:
image

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants