Write state diff to CSV #2
No reviewers
Labels
No Label
bug
critical
duplicate
enhancement
epic
help wanted
in progress
invalid
low priority
question
rebase
v1
v5
wontfix
Copied from Github
Kind/Breaking
Kind/Bug
Kind/Documentation
Kind/Enhancement
Kind/Feature
Kind/Security
Kind/Testing
Priority
Critical
Priority
High
Priority
Low
Priority
Medium
Reviewed
Confirmed
Reviewed
Duplicate
Reviewed
Invalid
Reviewed
Won't Fix
Status
Abandoned
Status
Blocked
Status
Need More Info
No Milestone
No project
No Assignees
2 Participants
Notifications
Due Date
No due date set.
Dependencies
No dependencies set.
Reference: cerc-io/go-ethereum#2
Loading…
Reference in New Issue
Block a user
No description provided.
Delete Branch "ee-state-diff"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
For reference, some sample diff data is here: https://github.com/8thlight/maker-vulcanizedb/pull/133
These changes look awesome. My main focus going forward would be making sure we have both keys and values for data we want to consume (e.g. addresses for accounts and paths for storage values) - and please forgive if I'm overlooking how that's being handled 🙏
Is this used? Not understanding why it would be always set to false here
I'm wondering if there's a way to use variable naming to help reveal what's happening here. I might just be being dense but I'm having trouble understanding why a
NodeIteratorinitialized withmake([]byte, 0)enables us to track down deletions while initializing it withmake([]byte{})yields creations.I may be missing something but it looks like the
creationarg is unused (and I think that's true all the way up to the calls ofbuildDiffEventual), so we may be able to remove itSuper minor but I think this should be
hexToKeyBytesAnd then I think the
_here could be captured to publish the addressI'm a little confused about how this works - isn't
accountDiff.Storagea map? Doeskcapture the key and value? Thinking we probably want both of those so that we can parse the new value and associate it with the corresponding key when consuming the data@ -0,0 +11,4 @@)var (Headers = []string{I think we probably want to include the address (and/or trie key) as a field here
yep, nice call, i don't think that is being used anymore.
Yep, nice catch. Previously we were storing the old value and the new value of each diff, and whether the account was created/deleted affected which value was used as the old. But since removing the old values, we shouldn't need that bool anymore. 🎉
That's a great point, this is confusing. The gist of it is that we're creating iterators from the old and new tries, and when we're creating the iterators we're passing in a starting key, which I think can just be 0. The difference between
make(byte[], 0)and[]byte{}was inadvertent, so I'll switch them both to be the same for consistency.The difference between whether we'e tracking down deletions vs creations is in the order that we're passing the iterators to
collectDiffNodes- where we're either finding nodes in the old trie that aren't in the new trie (deletions) or nodes in the new trie that we're in the old (creations).I feel like there's a way to make this a bit more readable, but it hasn't come to me. Do you have any ideas?
Yep, good call -
kis just capturing the path to the storage value. I think I'll want both the key and the value when I add the storage value to the csv 👌Doesn't look like this needs to return an error at the moment.
This is so so minor I feel silly mentioning it but these extra spaces on line 177 and 1191 are artifacts left over from when I went about inserting statediffing directly into the blockchain.
👍 nice catch