cerc-io/ipld-eth-server
18
0
Fork 1
Code Issues 10 Pull Requests 1 Actions Packages Projects Releases 37 Wiki Activity

fix encoding when storage is empty #94

Merged
n0cte merged 14 commits from empty_data_encoder into master 2021-09-28 05:17:43 +00:00
Conversation 3 Commits 14 Files Changed 11 +5
1 changed files with 5 additions and 0 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files
Showing only changes of commit 3a216b2ca3 - Show all commits

5
pkg/eth/ipld_retriever.go
View File

@ -438,9 +438,11 @@ func (r *IPLDRetriever) RetrieveAccountByAddressAndBlockHash(address common.Addr
if err := r.db.Get(accountResult, RetrieveAccountByLeafKeyAndBlockHashPgStr, leafKey.Hex(), hash.Hex()); err != nil {
return "", nil, err
}
i-norden commented 2021-08-20 02:16:39 +00:00
Review
Copy Link

Just to note, we should only ever see a zero value for a node that is not "Removed" if we are at a block height prior to EIP-158 activation (which is when zeroed value pruning begun). Does this make sense, and align with what we are seeing?

Just to note, we should only ever see a zero value for a node that is not "Removed" if we are at a block height prior to EIP-158 activation (which is when zeroed value pruning begun). Does this make sense, and align with what we are seeing?
i-norden commented 2021-08-20 02:19:14 +00:00
Review
Copy Link

I think we need the analogous check in the account retrieval methods above (RetrieveAccountByAddressAndBlockNumber and RetrieveAccountByAddressAndBlockHash) and the other storage retrieval method below (RetrieveStorageAtByAddressAndStorageKeyAndBlockNumber).

I think we need the analogous check in the account retrieval methods above (`RetrieveAccountByAddressAndBlockNumber` and `RetrieveAccountByAddressAndBlockHash`) and the other storage retrieval method below (`RetrieveStorageAtByAddressAndStorageKeyAndBlockNumber`).
ashwinphatak commented 2021-08-20 05:13:34 +00:00 (Migrated from github.com)
Review
Copy Link

We're running a local/private chain for which the value in genesis is "eip158Block": 0,, so this isn't consistent with what we expect?

We're running a local/private chain for which the value in genesis is `"eip158Block": 0,`, so this isn't consistent with what we expect?
ramilexe commented 2021-08-20 07:33:14 +00:00 (Migrated from github.com)
Review
Copy Link

Where is RetrieveAccountByAddressAndBlockNumber function called? I couldn't find it. And how to test account deleting?

Where is `RetrieveAccountByAddressAndBlockNumber` function called? I couldn't find it. And how to test account deleting?
ramilexe commented 2021-08-20 07:40:15 +00:00 (Migrated from github.com)
Review
Copy Link

Does this make sense, and align with what we are seeing?

It makes sense but doesn't align with current behavior. Isn't this misalignment was introduced here in this PR https://github.com/vulcanize/go-ethereum/pull/58 ?

> Does this make sense, and align with what we are seeing? It makes sense but doesn't align with current behavior. Isn't this misalignment was introduced here in this PR https://github.com/vulcanize/go-ethereum/pull/58 ?
i-norden commented 2021-08-23 13:26:18 +00:00
Review
Copy Link

Hmm I need to think about this some more, sorry, let me get back.

Hmm I need to think about this some more, sorry, let me get back.
i-norden commented 2021-08-23 13:26:37 +00:00
Review
Copy Link

I think we want to fix the function even if it isn't currently called. We could test account deleting similar to how we do it here: https://github.com/vulcanize/go-ethereum/blob/v1.10.7-statediff/statediff/builder_test.go#L1318

I think we want to fix the function even if it isn't currently called. We could test account deleting similar to how we do it here: https://github.com/vulcanize/go-ethereum/blob/v1.10.7-statediff/statediff/builder_test.go#L1318
i-norden commented 2021-08-31 18:18:25 +00:00
Review
Copy Link

Does this make sense, and align with what we are seeing?

It makes sense but doesn't align with current behavior. Isn't this misalignment was introduced here in this PR vulcanize/go-ethereum#58 ?

If that is the cause of the misalignment then all we need to do is check that the node isn't a "Removed" type when we query for the latest value at a given path/key, which I think we are already doing?

> > Does this make sense, and align with what we are seeing? > > It makes sense but doesn't align with current behavior. Isn't this misalignment was introduced here in this PR [vulcanize/go-ethereum#58](https://github.com/vulcanize/go-ethereum/pull/58) ? If that is the cause of the misalignment then all we need to do is check that the node isn't a "Removed" type when we query for the latest value at a given path/key, which I think we are already doing?
i-norden commented 2021-08-31 18:27:14 +00:00
Review
Copy Link

@arijitAD is taking over here, to echo what I told him in slack:

First thing to do is verify that we are excluding "Removed" type nodes when we perform those queries.

If we arent doing that then we are actually just seeing null values where they are supposed to be, and need to add a check to filter those out

But I think we are already filtering out "Removed" nodes in those queries, and if we are already doing that then there is some deeper reason as to why we are seeing null values for nodes that are not of the "Removed" type

Another possible lead is how we (and geth) are distinguishing (or not) between true nulls and legitimate zero values

@arijitAD is taking over here, to echo what I told him in slack: First thing to do is verify that we are excluding "Removed" type nodes when we perform those queries. If we arent doing that then we are actually just seeing null values where they are supposed to be, and need to add a check to filter those out But I think we are already filtering out "Removed" nodes in those queries, and if we are already doing that then there is some deeper reason as to why we are seeing null values for nodes that are not of the "Removed" type Another possible lead is how we (and geth) are distinguishing (or not) between true nulls and legitimate zero values
i-norden commented 2021-09-06 18:34:59 +00:00
Review
Copy Link

On the other side of this coin, if 0 values are not showing up when they are supposed to it is likely because the query being made against the database does not properly consider the "Removed" node type entries as indicating a 0 value and instead the query finds the last entry where the node is not "Removed" and returns that latest non-zero value (which is the behavior we want in some cases, but not here).

On the other side of this coin, if 0 values are not showing up when they are supposed to it is likely because the query being made against the database does not properly consider the "Removed" node type entries as indicating a 0 value and instead the query finds the last entry where the node is not "Removed" and returns that latest non-zero value (which is the behavior we want in some cases, but not here).
i-norden commented 2021-09-13 13:43:55 +00:00
Review
Copy Link

Please see https://github.com/vulcanize/ipld-eth-server/issues/95#issuecomment-918202095 there is a much simpler fix now that we have leaf_key for "Removed" nodes

Please see https://github.com/vulcanize/ipld-eth-server/issues/95#issuecomment-918202095 there is a much simpler fix now that we have leaf_key for "Removed" nodes
if accountResult.NodeType == removedNode {
return "", []byte{}, nil
}
var i []interface{}
if err := rlp.DecodeBytes(accountResult.Data, &i); err != nil {
return "", nil, fmt.Errorf("error decoding state leaf node rlp: %s", err.Error())
@ -459,9 +461,11 @@ func (r *IPLDRetriever) RetrieveAccountByAddressAndBlockNumber(address common.Ad
if err := r.db.Get(accountResult, RetrieveAccountByLeafKeyAndBlockNumberPgStr, leafKey.Hex(), number); err != nil {
return "", nil, err
}
if accountResult.NodeType == removedNode {
return "", []byte{}, nil
}
var i []interface{}
if err := rlp.DecodeBytes(accountResult.Data, &i); err != nil {
return "", nil, fmt.Errorf("error decoding state leaf node rlp: %s", err.Error())
@ -502,6 +506,7 @@ func (r *IPLDRetriever) RetrieveStorageAtByAddressAndStorageKeyAndBlockNumber(ad
if err := r.db.Get(storageResult, RetrieveStorageLeafByAddressHashAndLeafKeyAndBlockNumberPgStr, stateLeafKey.Hex(), storageLeafKey.Hex(), number); err != nil {
return "", nil, err
}
if storageResult.NodeType == removedNode {
return "", []byte{}, nil
}