-
Notifications
You must be signed in to change notification settings - Fork 1.8k
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
feat(cheatcodes
): ability to capture and store state diffs
#2846
Comments
we support rn is that a start, or what should we add to the I guess diffing between snapshots, right? |
upvote for this snapshot diff feature. It would be better if the state diff could be displayed in the traces of forge test. |
unsure how this would look like when integrating diffs in traces. but perhaps we could do something like
|
I think there's two things here that would be useful:
|
Just noticed that #6310 was merged which is quite close to what I originally requested here. As far as i can tell it currently does not support decoding which would be insanely cool, anyhow feel free to close this one as the original issue is solved. |
Perhaps we close this one and create a new issue to track a decoded state diff similar to what tenderly does? Not sure if this is tracked anywhere else offhand since I know it's been mentioned, deferring to @Evalir for how to handle |
Yah the issue with tenderly and phalcon is that they only support a small subset of chains. Also it's a bit cumbersome to mix the tools. |
@zerosnacks , i think it's not a duplicate. The goal would be to identify changes like: - _balances[0x1] = 0;
+ _balances[0x1] = 1000;
- _balances[0x2] = 1000;
+ _balances[0x2] = 0; |
cheatcodes
): ability to capture and store state diffs
adding it in 1.0 to be discussed ref https://twitter.com/msolomon44/status/1859021021984289220 |
for cast run, proposed solution in PR #9013 is to add a |
Component
Forge
Describe the feature you would like
For certain transactions (especially related to DAO governance processes) it makes sense to diff the chain state from before and after a certain tx execution to have a reasonable preview of what the outcome/side effects of a certain action are.
I'm aware this feature can grow to infinite complexity when trying to decode the stateDiffs accross proxy implementations or similar, so for a first iteration i'd suggest to keep it as simple as possible and just track
address.key.before/after
values and see where we can go from there.Not quite sure if diffs over multiple txn or overlapping diffs are needed.
A simple api could be sth like
vm.diff(identifier)
which would track state changes of the next txn executed. The identifier could be the file to log to.As for a more complex api I would imagine sth similar to startPrank api but allowing overlaps.
Additional context
tenderly
has a great feature called "State changes" used in aave/unswap seatbelt, which does exactly that (diff the state between before and after a simulation). Would be cool if sth similar or a slimmed down version of this could exist within foundry as foundry & tenderly don't work very well together. For complex scenarios tenderly would probably still be the go-to as they solved state decoding in a relatively reliable way, but for more simple cases it would be cool if one could resort to foundry.The text was updated successfully, but these errors were encountered: