feat(cheatcodes): add vm.getStateDiff to get state diffs as string

[grandizzy]

Motivation

Closes #2846 by adding

    function getStateDiff() external view returns (string memory diff);
    function getStateDiffJson() external view returns (string memory diff);

• returns diffs recorded by startStateDiffRecording() cheatcode as string (can be printed with console.log or written in file), at the moment of cheatcode call (can be called multiple times between start / stop state diff)
• diffs contains only storage changes, initial value when start diff called to current (intermediary storage changes are not displayed)

E.g.

    vm.startStateDiffRecording();
    // do work, change state of Counter contract
    console.log(":::: diff 1 ::::");
    console.log(vm.getStateDiff());
    // more work, change state of Counter and AnotherCounter contracts
    console.log(":::: diff 2 ::::");
    console.log(vm.getStateDiff());
    // more work, change state of AnotherCounter contract
    console.log(":::: diff 3 ::::");
    console.log(vm.getStateDiff());

Json format vm.getStateDiffJson()

{
   "0x2e234dae75c793f67a35089c9d99245e1c58470b":{
      "label":"NestedStorer",
      "changes":{
         "31391530734884398925509096751136955997235046655136458338700630915422204365175":{
            "previousValue":"0x0000000000000000000000000000000000000000000000000000000000000000",
            "newValue":"0x0000000000000000000000000000000000000000000000000000000000000001"
         },
         "86546418208203448386783321347074308435724792809315873744194221534962779865098":{
            "previousValue":"0x0000000000000000000000000000000000000000000000000000000000000000",
            "newValue":"0x0000000000000000000000000000000000000000000000000000000000000001"
         },
         "89735575844917174604881245405098157398514761457822262993733937076486162048205":{
            "previousValue":"0x0000000000000000000000000000000000000000000000000000000000000000",
            "newValue":"0x0000000000000000000000000000000000000000000000000000000000000001"
         },
         "99655811014363889343382125167956395016210879868288374279890486979400290732814":{
            "previousValue":"0x0000000000000000000000000000000000000000000000000000000000000000",
            "newValue":"0x0000000000000000000000000000000000000000000000000000000000000001"
         }
      }
   }
}

Solution

[zerosnacks]

lgtm

[sakulstra]

I'm honestly a bit conflicted with this api / feature.

With primitive type storage in incremental slots what is proposed here is definitely useful, although I think for us would be more useful in an easier-to-consume & post-process format (e.g. json).

Currently I lack the imagination though to see how i could understand that a change in slot 0x9fe9e472df24c0973d55f45ce8b645fa4fb021df9b3c6db994a661dfb284cb67is a _balances change of some user.
What I originally hoped for when opening #2846 was something closer to evm.storage or tenderly state diff - a state diff including some decoded storage slot description.

[grandizzy]

I'm honestly a bit conflicted with this api / feature.

With primitive type storage in incremental slots what is proposed here is definitely useful, although I think for us would be more useful in an easier-to-consume & post-process format (e.g. json).

can add a flag to cheatcode to return plain text or json formatted

Currently I lack the imagination though to see how i could understand that a change in slot 0x9fe9e472df24c0973d55f45ce8b645fa4fb021df9b3c6db994a661dfb284cb67is a _balances change of some user. What I originally hoped for when opening #2846 was something closer to evm.storage or tenderly state diff - a state diff including some decoded storage slot description.

I think this would imply leveraging of storage layout but probably more complex, will have a look at but most probably feasible to add post v1.

[sakulstra]

@grandizzy just had another look at the structure & was wondering it could make sense to change it so sth like:
{<address>: {label: <label>, changes: {<slot>: {from, to}}}} or sth similar.

My thinking is that it's a bit weird that if a label is supplied, the address is lost on the diff.
By providing changes as an object instead of an array, I feel like this might open up the possibility of adding things in the future (like the decoded storage location, or some other meta), without introducing a breaking change on the structure.

[grandizzy]

@grandizzy just had another look at the structure & was wondering it could make sense to change it so sth like: {<address>: {label: <label>, changes: {<slot>: {from, to}}}} or sth similar.

My thinking is that it's a bit weird that if a label is supplied, the address is lost on the diff. By providing changes as an object instead of an array, I feel like this might open up the possibility of adding things in the future (like the decoded storage location, or some other meta), without introducing a breaking change on the structure.

thank you, makes sense, will structure the output this way

[grandizzy]

@grandizzy just had another look at the structure & was wondering it could make sense to change it so sth like: {<address>: {label: <label>, changes: {<slot>: {from, to}}}} or sth similar.
My thinking is that it's a bit weird that if a label is supplied, the address is lost on the diff. By providing changes as an object instead of an array, I feel like this might open up the possibility of adding things in the future (like the decoded storage location, or some other meta), without introducing a breaking change on the structure.

thank you, makes sense, will structure the output this way

@sakulstra I formatted it as below in d46080c

{
   "0x2e234dae75c793f67a35089c9d99245e1c58470b":{
      "label":"NestedStorer",
      "changes":{
         "31391530734884398925509096751136955997235046655136458338700630915422204365175":{
            "original":"0x0000000000000000000000000000000000000000000000000000000000000000",
            "dirty":"0x0000000000000000000000000000000000000000000000000000000000000001"
         },
         "86546418208203448386783321347074308435724792809315873744194221534962779865098":{
            "original":"0x0000000000000000000000000000000000000000000000000000000000000000",
            "dirty":"0x0000000000000000000000000000000000000000000000000000000000000001"
         },
         "89735575844917174604881245405098157398514761457822262993733937076486162048205":{
            "original":"0x0000000000000000000000000000000000000000000000000000000000000000",
            "dirty":"0x0000000000000000000000000000000000000000000000000000000000000001"
         },
         "99655811014363889343382125167956395016210879868288374279890486979400290732814":{
            "original":"0x0000000000000000000000000000000000000000000000000000000000000000",
            "dirty":"0x0000000000000000000000000000000000000000000000000000000000000001"
         }
      }
   }
}

[sakulstra]

@grandizzy looks good to me.

I personally find the new naming not so optimal, but i think is just taste.
Checked the naming on other tooling and e.g. tenderly is using original & dirty instead of previousValue and newValue - in the end doesn't matter though.

[grandizzy]

@grandizzy looks good to me.

I personally find the new working not so optimal, but i think is just taste. Checked the naming on other tooling and e.g. tenderly is using original & dirty instead of previousValue and newValue - in the end doesn't matter though.

changed in 1536119 and updated comment above

rerequesting review as there were several changes (json output)

[zerosnacks]

Nice! Lgtm