Write state diff to CSV #2
@ -204,7 +204,7 @@ func (sdb *builder) buildDiffIncremental(creations map[common.Address]*state.Acc
|
|||||||
|
|
|||||||
return updatedAccounts, nil
|
return updatedAccounts, nil
|
||||||
}
|
}
|
||||||
|
|
||||||
func (sdb *builder) buildStorageDiffsEventual(sr common.Hash) (map[string]DiffString, error) {
|
func (sdb *builder) buildStorageDiffsEventual(sr common.Hash) (map[string]DiffStorage, error) {
|
||||||
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 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 `NodeIterator` initialized with `make([]byte, 0)` enables us to track down deletions while initializing it with `make([]byte{})` yields creations.
I may be missing something but it looks like the I may be missing something but it looks like the `creation` arg is unused (and I think that's true all the way up to the calls of `buildDiffEventual`), so we may be able to remove it
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. 🎉 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 The difference between whether we'e tracking down deletions vs creations is in the order that we're passing the iterators to 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? 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?
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 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 `NodeIterator` initialized with `make([]byte, 0)` enables us to track down deletions while initializing it with `make([]byte{})` yields creations.
I may be missing something but it looks like the I may be missing something but it looks like the `creation` arg is unused (and I think that's true all the way up to the calls of `buildDiffEventual`), so we may be able to remove it
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. 🎉 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 The difference between whether we'e tracking down deletions vs creations is in the order that we're passing the iterators to 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? 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?
|
|||||||
log.Debug("Storage Root For Eventual Diff", "root", sr.Hex())
|
log.Debug("Storage Root For Eventual Diff", "root", sr.Hex())
|
||||||
sTrie, err := trie.New(sr, sdb.trieDB)
|
sTrie, err := trie.New(sr, sdb.trieDB)
|
||||||
if err != nil {
|
if err != nil {
|
||||||
@ -212,14 +212,14 @@ func (sdb *builder) buildStorageDiffsEventual(sr common.Hash) (map[string]DiffSt
|
|||||||
|
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 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 `NodeIterator` initialized with `make([]byte, 0)` enables us to track down deletions while initializing it with `make([]byte{})` yields creations.
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 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 `NodeIterator` initialized with `make([]byte, 0)` enables us to track down deletions while initializing it with `make([]byte{})` yields creations.
I may be missing something but it looks like the I may be missing something but it looks like the `creation` arg is unused (and I think that's true all the way up to the calls of `buildDiffEventual`), so we may be able to remove it
I may be missing something but it looks like the I may be missing something but it looks like the `creation` arg is unused (and I think that's true all the way up to the calls of `buildDiffEventual`), so we may be able to remove it
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. 🎉 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. 🎉
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. 🎉 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 The difference between whether we'e tracking down deletions vs creations is in the order that we're passing the iterators to 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? 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?
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 The difference between whether we'e tracking down deletions vs creations is in the order that we're passing the iterators to 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? 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?
|
|||||||
return nil, err
|
return nil, err
|
||||||
}
|
}
|
||||||
it := sTrie.NodeIterator(make([]byte, 0))
|
it := sTrie.NodeIterator(make([]byte, 0))
|
||||||
storageDiffs := make(map[string]DiffString)
|
storageDiffs := make(map[string]DiffStorage)
|
||||||
|
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 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 `NodeIterator` initialized with `make([]byte, 0)` enables us to track down deletions while initializing it with `make([]byte{})` yields creations.
I may be missing something but it looks like the I may be missing something but it looks like the `creation` arg is unused (and I think that's true all the way up to the calls of `buildDiffEventual`), so we may be able to remove it
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. 🎉 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 The difference between whether we'e tracking down deletions vs creations is in the order that we're passing the iterators to 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? 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?
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 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 `NodeIterator` initialized with `make([]byte, 0)` enables us to track down deletions while initializing it with `make([]byte{})` yields creations.
I may be missing something but it looks like the I may be missing something but it looks like the `creation` arg is unused (and I think that's true all the way up to the calls of `buildDiffEventual`), so we may be able to remove it
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. 🎉 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 The difference between whether we'e tracking down deletions vs creations is in the order that we're passing the iterators to 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? 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?
|
|||||||
for {
|
for {
|
||||||
log.Debug("Iterating over state at path ", "path", pathToStr(it))
|
log.Debug("Iterating over state at path ", "path", pathToStr(it))
|
||||||
if it.Leaf() {
|
if it.Leaf() {
|
||||||
log.Debug("Found leaf in storage", "path", pathToStr(it))
|
log.Debug("Found leaf in storage", "path", pathToStr(it))
|
||||||
path := pathToStr(it)
|
path := pathToStr(it)
|
||||||
value := hexutil.Encode(it.LeafBlob())
|
value := hexutil.Encode(it.LeafBlob())
|
||||||
storageDiffs[path] = DiffString{Value: &value}
|
storageDiffs[path] = DiffStorage{Value: &value}
|
||||||
|
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 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 `NodeIterator` initialized with `make([]byte, 0)` enables us to track down deletions while initializing it with `make([]byte{})` yields creations.
I may be missing something but it looks like the I may be missing something but it looks like the `creation` arg is unused (and I think that's true all the way up to the calls of `buildDiffEventual`), so we may be able to remove it
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. 🎉 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 The difference between whether we'e tracking down deletions vs creations is in the order that we're passing the iterators to 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? 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?
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 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 `NodeIterator` initialized with `make([]byte, 0)` enables us to track down deletions while initializing it with `make([]byte{})` yields creations.
I may be missing something but it looks like the I may be missing something but it looks like the `creation` arg is unused (and I think that's true all the way up to the calls of `buildDiffEventual`), so we may be able to remove it
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. 🎉 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 The difference between whether we'e tracking down deletions vs creations is in the order that we're passing the iterators to 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? 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?
|
|||||||
}
|
}
|
||||||
cont := it.Next(true)
|
cont := it.Next(true)
|
||||||
if !cont {
|
if !cont {
|
||||||
@ -229,7 +229,7 @@ func (sdb *builder) buildStorageDiffsEventual(sr common.Hash) (map[string]DiffSt
|
|||||||
|
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 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 `NodeIterator` initialized with `make([]byte, 0)` enables us to track down deletions while initializing it with `make([]byte{})` yields creations.
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 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 `NodeIterator` initialized with `make([]byte, 0)` enables us to track down deletions while initializing it with `make([]byte{})` yields creations.
I may be missing something but it looks like the I may be missing something but it looks like the `creation` arg is unused (and I think that's true all the way up to the calls of `buildDiffEventual`), so we may be able to remove it
I may be missing something but it looks like the I may be missing something but it looks like the `creation` arg is unused (and I think that's true all the way up to the calls of `buildDiffEventual`), so we may be able to remove it
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. 🎉 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. 🎉
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. 🎉 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 The difference between whether we'e tracking down deletions vs creations is in the order that we're passing the iterators to 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? 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?
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 The difference between whether we'e tracking down deletions vs creations is in the order that we're passing the iterators to 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? 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?
|
|||||||
return storageDiffs, nil
|
return storageDiffs, nil
|
||||||
}
|
}
|
||||||
|
|
||||||
func (sdb *builder) buildStorageDiffsIncremental(oldSR common.Hash, newSR common.Hash) (map[string]DiffString, error) {
|
func (sdb *builder) buildStorageDiffsIncremental(oldSR common.Hash, newSR common.Hash) (map[string]DiffStorage, error) {
|
||||||
|
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 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 `NodeIterator` initialized with `make([]byte, 0)` enables us to track down deletions while initializing it with `make([]byte{})` yields creations.
I may be missing something but it looks like the I may be missing something but it looks like the `creation` arg is unused (and I think that's true all the way up to the calls of `buildDiffEventual`), so we may be able to remove it
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. 🎉 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 The difference between whether we'e tracking down deletions vs creations is in the order that we're passing the iterators to 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? 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?
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 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 `NodeIterator` initialized with `make([]byte, 0)` enables us to track down deletions while initializing it with `make([]byte{})` yields creations.
I may be missing something but it looks like the I may be missing something but it looks like the `creation` arg is unused (and I think that's true all the way up to the calls of `buildDiffEventual`), so we may be able to remove it
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. 🎉 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 The difference between whether we'e tracking down deletions vs creations is in the order that we're passing the iterators to 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? 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?
|
|||||||
log.Debug("Storage Roots for Incremental Diff", "old", oldSR.Hex(), "new", newSR.Hex())
|
log.Debug("Storage Roots for Incremental Diff", "old", oldSR.Hex(), "new", newSR.Hex())
|
||||||
oldTrie, err := trie.New(oldSR, sdb.trieDB)
|
oldTrie, err := trie.New(oldSR, sdb.trieDB)
|
||||||
if err != nil {
|
if err != nil {
|
||||||
@ -243,13 +243,15 @@ func (sdb *builder) buildStorageDiffsIncremental(oldSR common.Hash, newSR common
|
|||||||
|
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 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 `NodeIterator` initialized with `make([]byte, 0)` enables us to track down deletions while initializing it with `make([]byte{})` yields creations.
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 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 `NodeIterator` initialized with `make([]byte, 0)` enables us to track down deletions while initializing it with `make([]byte{})` yields creations.
I may be missing something but it looks like the I may be missing something but it looks like the `creation` arg is unused (and I think that's true all the way up to the calls of `buildDiffEventual`), so we may be able to remove it
I may be missing something but it looks like the I may be missing something but it looks like the `creation` arg is unused (and I think that's true all the way up to the calls of `buildDiffEventual`), so we may be able to remove it
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. 🎉 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. 🎉
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. 🎉 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 The difference between whether we'e tracking down deletions vs creations is in the order that we're passing the iterators to 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? 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?
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 The difference between whether we'e tracking down deletions vs creations is in the order that we're passing the iterators to 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? 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?
|
|||||||
oldIt := oldTrie.NodeIterator(make([]byte, 0))
|
oldIt := oldTrie.NodeIterator(make([]byte, 0))
|
||||||
newIt := newTrie.NodeIterator(make([]byte, 0))
|
newIt := newTrie.NodeIterator(make([]byte, 0))
|
||||||
it, _ := trie.NewDifferenceIterator(oldIt, newIt)
|
it, _ := trie.NewDifferenceIterator(oldIt, newIt)
|
||||||
storageDiffs := make(map[string]DiffString)
|
storageDiffs := make(map[string]DiffStorage)
|
||||||
|
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 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 `NodeIterator` initialized with `make([]byte, 0)` enables us to track down deletions while initializing it with `make([]byte{})` yields creations.
I may be missing something but it looks like the I may be missing something but it looks like the `creation` arg is unused (and I think that's true all the way up to the calls of `buildDiffEventual`), so we may be able to remove it
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. 🎉 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 The difference between whether we'e tracking down deletions vs creations is in the order that we're passing the iterators to 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? 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?
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 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 `NodeIterator` initialized with `make([]byte, 0)` enables us to track down deletions while initializing it with `make([]byte{})` yields creations.
I may be missing something but it looks like the I may be missing something but it looks like the `creation` arg is unused (and I think that's true all the way up to the calls of `buildDiffEventual`), so we may be able to remove it
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. 🎉 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 The difference between whether we'e tracking down deletions vs creations is in the order that we're passing the iterators to 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? 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?
|
|||||||
for {
|
for {
|
||||||
if it.Leaf() {
|
if it.Leaf() {
|
||||||
log.Debug("Found leaf in storage", "path", pathToStr(it))
|
log.Debug("Found leaf in storage", "path", pathToStr(it))
|
||||||
path := pathToStr(it)
|
path := pathToStr(it)
|
||||||
value := hexutil.Encode(it.LeafBlob())
|
storageValue := hexutil.Encode(it.LeafBlob())
|
||||||
|
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 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 `NodeIterator` initialized with `make([]byte, 0)` enables us to track down deletions while initializing it with `make([]byte{})` yields creations.
I may be missing something but it looks like the I may be missing something but it looks like the `creation` arg is unused (and I think that's true all the way up to the calls of `buildDiffEventual`), so we may be able to remove it
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. 🎉 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 The difference between whether we'e tracking down deletions vs creations is in the order that we're passing the iterators to 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? 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?
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 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 `NodeIterator` initialized with `make([]byte, 0)` enables us to track down deletions while initializing it with `make([]byte{})` yields creations.
I may be missing something but it looks like the I may be missing something but it looks like the `creation` arg is unused (and I think that's true all the way up to the calls of `buildDiffEventual`), so we may be able to remove it
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. 🎉 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 The difference between whether we'e tracking down deletions vs creations is in the order that we're passing the iterators to 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? 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?
|
|||||||
storageDiffs[path] = DiffString{Value: &value}
|
storageDiffs[path] = DiffStorage{
|
||||||
|
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 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 `NodeIterator` initialized with `make([]byte, 0)` enables us to track down deletions while initializing it with `make([]byte{})` yields creations.
I may be missing something but it looks like the I may be missing something but it looks like the `creation` arg is unused (and I think that's true all the way up to the calls of `buildDiffEventual`), so we may be able to remove it
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. 🎉 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 The difference between whether we'e tracking down deletions vs creations is in the order that we're passing the iterators to 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? 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?
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 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 `NodeIterator` initialized with `make([]byte, 0)` enables us to track down deletions while initializing it with `make([]byte{})` yields creations.
I may be missing something but it looks like the I may be missing something but it looks like the `creation` arg is unused (and I think that's true all the way up to the calls of `buildDiffEventual`), so we may be able to remove it
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. 🎉 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 The difference between whether we'e tracking down deletions vs creations is in the order that we're passing the iterators to 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? 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?
|
|||||||
|
Value: &storageValue,
|
||||||
|
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 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 `NodeIterator` initialized with `make([]byte, 0)` enables us to track down deletions while initializing it with `make([]byte{})` yields creations.
I may be missing something but it looks like the I may be missing something but it looks like the `creation` arg is unused (and I think that's true all the way up to the calls of `buildDiffEventual`), so we may be able to remove it
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. 🎉 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 The difference between whether we'e tracking down deletions vs creations is in the order that we're passing the iterators to 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? 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?
|
|||||||
|
}
|
||||||
|
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 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 `NodeIterator` initialized with `make([]byte, 0)` enables us to track down deletions while initializing it with `make([]byte{})` yields creations.
I may be missing something but it looks like the I may be missing something but it looks like the `creation` arg is unused (and I think that's true all the way up to the calls of `buildDiffEventual`), so we may be able to remove it
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. 🎉 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 The difference between whether we'e tracking down deletions vs creations is in the order that we're passing the iterators to 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? 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?
|
|||||||
}
|
}
|
||||||
|
|
||||||
cont := it.Next(true)
|
cont := it.Next(true)
|
||||||
|
|||||||
|
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 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 `NodeIterator` initialized with `make([]byte, 0)` enables us to track down deletions while initializing it with `make([]byte{})` yields creations.
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 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 `NodeIterator` initialized with `make([]byte, 0)` enables us to track down deletions while initializing it with `make([]byte{})` yields creations.
I may be missing something but it looks like the I may be missing something but it looks like the `creation` arg is unused (and I think that's true all the way up to the calls of `buildDiffEventual`), so we may be able to remove it
I may be missing something but it looks like the I may be missing something but it looks like the `creation` arg is unused (and I think that's true all the way up to the calls of `buildDiffEventual`), so we may be able to remove it
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. 🎉 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. 🎉
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. 🎉 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 The difference between whether we'e tracking down deletions vs creations is in the order that we're passing the iterators to 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? 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?
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 The difference between whether we'e tracking down deletions vs creations is in the order that we're passing the iterators to 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? 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?
|
|||||||
@ -115,14 +115,14 @@ func TestBuilder(t *testing.T) {
|
|||||||
Balance: b.DiffBigInt{Value: big.NewInt(balanceChange10000)},
|
Balance: b.DiffBigInt{Value: big.NewInt(balanceChange10000)},
|
||||||
CodeHash: "0xc5d2460186f7233c927e7db2dcc703c0e500b653ca82273b7bfad8045d85a470",
|
CodeHash: "0xc5d2460186f7233c927e7db2dcc703c0e500b653ca82273b7bfad8045d85a470",
|
||||||
ContractRoot: b.DiffString{Value: &originalContractRoot},
|
ContractRoot: b.DiffString{Value: &originalContractRoot},
|
||||||
Storage: map[string]b.DiffString{},
|
Storage: map[string]b.DiffStorage{},
|
||||||
},
|
},
|
||||||
burnAddress: {
|
burnAddress: {
|
||||||
Nonce: b.DiffUint64{Value: &nonce0},
|
Nonce: b.DiffUint64{Value: &nonce0},
|
||||||
Balance: b.DiffBigInt{Value: big.NewInt(miningReward)},
|
Balance: b.DiffBigInt{Value: big.NewInt(miningReward)},
|
||||||
CodeHash: "0xc5d2460186f7233c927e7db2dcc703c0e500b653ca82273b7bfad8045d85a470",
|
CodeHash: "0xc5d2460186f7233c927e7db2dcc703c0e500b653ca82273b7bfad8045d85a470",
|
||||||
ContractRoot: b.DiffString{Value: &originalContractRoot},
|
ContractRoot: b.DiffString{Value: &originalContractRoot},
|
||||||
Storage: map[string]b.DiffString{},
|
Storage: map[string]b.DiffStorage{},
|
||||||
},
|
},
|
||||||
},
|
},
|
||||||
DeletedAccounts: emptyAccountDiffEventualMap,
|
DeletedAccounts: emptyAccountDiffEventualMap,
|
||||||
@ -132,7 +132,7 @@ func TestBuilder(t *testing.T) {
|
|||||||
Balance: b.DiffBigInt{Value: big.NewInt(testBankFunds.Int64() - balanceChange10000)},
|
Balance: b.DiffBigInt{Value: big.NewInt(testBankFunds.Int64() - balanceChange10000)},
|
||||||
CodeHash: "0xc5d2460186f7233c927e7db2dcc703c0e500b653ca82273b7bfad8045d85a470",
|
CodeHash: "0xc5d2460186f7233c927e7db2dcc703c0e500b653ca82273b7bfad8045d85a470",
|
||||||
ContractRoot: b.DiffString{Value: &originalContractRoot},
|
ContractRoot: b.DiffString{Value: &originalContractRoot},
|
||||||
Storage: map[string]b.DiffString{},
|
Storage: map[string]b.DiffStorage{},
|
||||||
},
|
},
|
||||||
},
|
},
|
||||||
},
|
},
|
||||||
@ -156,14 +156,14 @@ func TestBuilder(t *testing.T) {
|
|||||||
Balance: b.DiffBigInt{Value: big.NewInt(balanceChange1000)},
|
Balance: b.DiffBigInt{Value: big.NewInt(balanceChange1000)},
|
||||||
CodeHash: "0xc5d2460186f7233c927e7db2dcc703c0e500b653ca82273b7bfad8045d85a470",
|
CodeHash: "0xc5d2460186f7233c927e7db2dcc703c0e500b653ca82273b7bfad8045d85a470",
|
||||||
ContractRoot: b.DiffString{Value: &originalContractRoot},
|
ContractRoot: b.DiffString{Value: &originalContractRoot},
|
||||||
Storage: map[string]b.DiffString{},
|
Storage: map[string]b.DiffStorage{},
|
||||||
},
|
},
|
||||||
contractAddr: {
|
contractAddr: {
|
||||||
Nonce: b.DiffUint64{Value: &nonce1},
|
Nonce: b.DiffUint64{Value: &nonce1},
|
||||||
Balance: b.DiffBigInt{Value: big.NewInt(0)},
|
Balance: b.DiffBigInt{Value: big.NewInt(0)},
|
||||||
CodeHash: "0x1c671ee4ae8abbacab7da59d6f8785cce8295eb086551ce7ac266a2e93666c0f",
|
CodeHash: "0x1c671ee4ae8abbacab7da59d6f8785cce8295eb086551ce7ac266a2e93666c0f",
|
||||||
ContractRoot: b.DiffString{Value: &originalContractRoot},
|
ContractRoot: b.DiffString{Value: &originalContractRoot},
|
||||||
Storage: map[string]b.DiffString{},
|
Storage: map[string]b.DiffStorage{},
|
||||||
},
|
},
|
||||||
},
|
},
|
||||||
DeletedAccounts: emptyAccountDiffEventualMap,
|
DeletedAccounts: emptyAccountDiffEventualMap,
|
||||||
@ -173,21 +173,21 @@ func TestBuilder(t *testing.T) {
|
|||||||
Balance: b.DiffBigInt{Value: big.NewInt(block1BankBalance - balanceChange1000)},
|
Balance: b.DiffBigInt{Value: big.NewInt(block1BankBalance - balanceChange1000)},
|
||||||
CodeHash: "0xc5d2460186f7233c927e7db2dcc703c0e500b653ca82273b7bfad8045d85a470",
|
CodeHash: "0xc5d2460186f7233c927e7db2dcc703c0e500b653ca82273b7bfad8045d85a470",
|
||||||
ContractRoot: b.DiffString{Value: &originalContractRoot},
|
ContractRoot: b.DiffString{Value: &originalContractRoot},
|
||||||
Storage: map[string]b.DiffString{},
|
Storage: map[string]b.DiffStorage{},
|
||||||
},
|
},
|
||||||
account1Addr: {
|
account1Addr: {
|
||||||
Nonce: b.DiffUint64{Value: &nonce2},
|
Nonce: b.DiffUint64{Value: &nonce2},
|
||||||
Balance: b.DiffBigInt{Value: big.NewInt(block1Account1Balance - balanceChange1000 + balanceChange1000)},
|
Balance: b.DiffBigInt{Value: big.NewInt(block1Account1Balance - balanceChange1000 + balanceChange1000)},
|
||||||
CodeHash: "0xc5d2460186f7233c927e7db2dcc703c0e500b653ca82273b7bfad8045d85a470",
|
CodeHash: "0xc5d2460186f7233c927e7db2dcc703c0e500b653ca82273b7bfad8045d85a470",
|
||||||
ContractRoot: b.DiffString{Value: &originalContractRoot},
|
ContractRoot: b.DiffString{Value: &originalContractRoot},
|
||||||
Storage: map[string]b.DiffString{},
|
Storage: map[string]b.DiffStorage{},
|
||||||
},
|
},
|
||||||
burnAddress: {
|
burnAddress: {
|
||||||
Nonce: b.DiffUint64{Value: &nonce0},
|
Nonce: b.DiffUint64{Value: &nonce0},
|
||||||
Balance: b.DiffBigInt{Value: big.NewInt(miningReward + miningReward)},
|
Balance: b.DiffBigInt{Value: big.NewInt(miningReward + miningReward)},
|
||||||
CodeHash: "0xc5d2460186f7233c927e7db2dcc703c0e500b653ca82273b7bfad8045d85a470",
|
CodeHash: "0xc5d2460186f7233c927e7db2dcc703c0e500b653ca82273b7bfad8045d85a470",
|
||||||
ContractRoot: b.DiffString{Value: &originalContractRoot},
|
ContractRoot: b.DiffString{Value: &originalContractRoot},
|
||||||
Storage: map[string]b.DiffString{},
|
Storage: map[string]b.DiffStorage{},
|
||||||
},
|
},
|
||||||
},
|
},
|
||||||
},
|
},
|
||||||
@ -213,14 +213,14 @@ func TestBuilder(t *testing.T) {
|
|||||||
Balance: b.DiffBigInt{Value: big.NewInt(block2Account2Balance + miningReward)},
|
Balance: b.DiffBigInt{Value: big.NewInt(block2Account2Balance + miningReward)},
|
||||||
CodeHash: "0xc5d2460186f7233c927e7db2dcc703c0e500b653ca82273b7bfad8045d85a470",
|
CodeHash: "0xc5d2460186f7233c927e7db2dcc703c0e500b653ca82273b7bfad8045d85a470",
|
||||||
ContractRoot: b.DiffString{Value: &originalContractRoot},
|
ContractRoot: b.DiffString{Value: &originalContractRoot},
|
||||||
Storage: map[string]b.DiffString{},
|
Storage: map[string]b.DiffStorage{},
|
||||||
},
|
},
|
||||||
contractAddr: {
|
contractAddr: {
|
||||||
Nonce: b.DiffUint64{Value: &nonce1},
|
Nonce: b.DiffUint64{Value: &nonce1},
|
||||||
Balance: b.DiffBigInt{Value: big.NewInt(0)},
|
Balance: b.DiffBigInt{Value: big.NewInt(0)},
|
||||||
CodeHash: "0x1c671ee4ae8abbacab7da59d6f8785cce8295eb086551ce7ac266a2e93666c0f",
|
CodeHash: "0x1c671ee4ae8abbacab7da59d6f8785cce8295eb086551ce7ac266a2e93666c0f",
|
||||||
ContractRoot: b.DiffString{Value: &newContractRoot},
|
ContractRoot: b.DiffString{Value: &newContractRoot},
|
||||||
Storage: map[string]b.DiffString{
|
Storage: map[string]b.DiffStorage{
|
||||||
"0x405787fa12a823e0f2b7631cc41b3ba8828b3321ca811111fa75cd3aa3bb5ace": {
|
"0x405787fa12a823e0f2b7631cc41b3ba8828b3321ca811111fa75cd3aa3bb5ace": {
|
||||||
Value: &newStorageValue},
|
Value: &newStorageValue},
|
||||||
},
|
},
|
||||||
@ -230,7 +230,7 @@ func TestBuilder(t *testing.T) {
|
|||||||
Balance: b.DiffBigInt{Value: big.NewInt(99989000)},
|
Balance: b.DiffBigInt{Value: big.NewInt(99989000)},
|
||||||
CodeHash: "0xc5d2460186f7233c927e7db2dcc703c0e500b653ca82273b7bfad8045d85a470",
|
CodeHash: "0xc5d2460186f7233c927e7db2dcc703c0e500b653ca82273b7bfad8045d85a470",
|
||||||
ContractRoot: b.DiffString{Value: &originalContractRoot},
|
ContractRoot: b.DiffString{Value: &originalContractRoot},
|
||||||
Storage: map[string]b.DiffString{},
|
Storage: map[string]b.DiffStorage{},
|
||||||
},
|
},
|
||||||
},
|
},
|
||||||
},
|
},
|
||||||
|
|||||||
@ -60,9 +60,12 @@ type AccountDiff struct {
|
|||||||
Balance DiffBigInt `json:"balance" gencodec:"required"`
|
Balance DiffBigInt `json:"balance" gencodec:"required"`
|
||||||
CodeHash string `json:"codeHash" gencodec:"required"`
|
CodeHash string `json:"codeHash" gencodec:"required"`
|
||||||
ContractRoot DiffString `json:"contractRoot" gencodec:"required"`
|
ContractRoot DiffString `json:"contractRoot" gencodec:"required"`
|
||||||
Storage map[string]DiffString `json:"storage" gencodec:"required"`
|
Storage map[string]DiffStorage `json:"storage" gencodec:"required"`
|
||||||
}
|
}
|
||||||
|
|
||||||
|
type DiffStorage struct {
|
||||||
|
Value *string `json:"value" gencodec:"optional"`
|
||||||
|
}
|
||||||
type DiffString struct {
|
type DiffString struct {
|
||||||
Value *string `json:"value" gencodec:"optional"`
|
Value *string `json:"value" gencodec:"optional"`
|
||||||
}
|
}
|
||||||
|
|||||||
@ -16,7 +16,7 @@ var (
|
|||||||
ContractRoot = "0x56e81f171bcc55a6ff8345e692c0f86e5b48e01b996cadc001622fb5e363b421"
|
ContractRoot = "0x56e81f171bcc55a6ff8345e692c0f86e5b48e01b996cadc001622fb5e363b421"
|
||||||
StoragePath = "0xc5d2460186f7233c927e7db2dcc703c0e500b653ca82273b7bfad8045d85a470"
|
StoragePath = "0xc5d2460186f7233c927e7db2dcc703c0e500b653ca82273b7bfad8045d85a470"
|
||||||
StorageValue = "0x03"
|
StorageValue = "0x03"
|
||||||
storage = map[string]builder.DiffString{StoragePath: {Value: &StorageValue}}
|
storage = map[string]builder.DiffStorage{StoragePath: {Value: &StorageValue}}
|
||||||
address = common.HexToAddress("0xaE9BEa628c4Ce503DcFD7E305CaB4e29E7476592")
|
address = common.HexToAddress("0xaE9BEa628c4Ce503DcFD7E305CaB4e29E7476592")
|
||||||
ContractAddress = address.String()
|
ContractAddress = address.String()
|
||||||
CreatedAccountDiffs = map[common.Address]builder.AccountDiff{address: {
|
CreatedAccountDiffs = map[common.Address]builder.AccountDiff{address: {
|
||||||
|
|||||||
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'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 itI 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 itYep, 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. 🎉
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?
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?