feat(`cheatcodes`): ability to capture and store state diffs

[sakulstra]

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.

vm.startStorageDiff('execution');
contract.doSthAwesome();
vm.startStorageDiff('partial');
contract.doSthElse();
vm.stopStorageDiff('partial');
vm.stopStorageDiff('execution');

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.

[mattsse]

we support id = vm.snapshot which basically record the entire state and can revert via vm.revertTo(id)

rn revertTo(id) also reverts all snapshots taken after the id

is that a start, or what should we add to the snapshot feature?

I guess diffing between snapshots, right?

ref https://book.getfoundry.sh/cheatcodes/snapshots

[wp-lai]

upvote for this snapshot diff feature. It would be better if the state diff could be displayed in the traces of forge test.

[mattsse]

unsure how this would look like when integrating diffs in traces.

but perhaps we could do something like

Diff diff = vm.diffSnapshot(id) console.log(diff)

[mds1]

I think there's two things here that would be useful:

1. Below a trace, showing the decoded state diffs for the full transaction. For forge test it'd be the state changes of that test, and for cast run <tx> you get the state changes of that tx.
2. Within a test, using vm.diffSnapshot(id) (though I'd probably name it vm.stateDiff(uint snapshotId)). We can update console2.sol to support this type and add a forge-std method like [log|print]StateDiff(uint snapshotId, string memory name) (second arg is optional) to simplify the process of snapshotting/logging. I think having it displayed in-line in the trace would be very hard to read and clutter the trace

[sakulstra]

Just noticed that https://github.com/foundry-rs/foundry/pull/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.

[mds1]

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

[sakulstra]

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]

Marking as duplicate of https://github.com/foundry-rs/foundry/issues/6704

I think this will be resolved by https://github.com/foundry-rs/foundry/pull/8571 as a diff can be derived by the recorded state changes, let me know if this PR would sufficiently cover your suggested feature.

[sakulstra]

@zerosnacks , i think it's not a duplicate. At least by reading the pr i don't see how one could extract the storage labels from the recording.

The goal would be to identify changes like:

- _balances[0x1] = 0;
+ _balances[0x1] = 1000;
- _balances[0x2] = 1000;
+ _balances[0x2] = 0;