You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Describe the bug findstates RPC handler introduced in #638 seems to have a bug in the results filtering logic when the fourth argument (key to start the search from) is specified. The bug happens due to invalid MPTTrie.Find behaviour:
After that, we start the traversal process from this new path with an offset equals to the length of this path. Here's the place where the bug occurs. If the new path is longer than prefix, then we do not perform the comparison of path's extra bytes with from argument like it is done in step 1. We just start searching from the offset.
For example, we want to find all storage items with prefix abc starting from abcdef. Let's suppose that Extension node is located at the path ab and has the Key equal to cc. Then Seek with abc prefix will give us path=abcc and the start node equals the Extension's Next. After that we'll start the traversal process with abcc path, from abcdef and 4 offset. I.e. we'll traverse from the start node with the ef path and will probably find some suitable MPT nodes. That's not correct, because this algorithm doesn't take into account new abcc path which is less than the abcdef at the fourth byte (c < d). So we shouldn't return anything from that query.
To Reproduce
I found the described situation in the current testnet, so to reproduce this bug send findstates RPC call to the v3.0.3 testnet C# node with the following arguments:
So you can see that the single storage item with key FJKznHeqYPKbV8FzztkX8X/TIabr (1492b39c77aa60f29b57c173ced917f17fd321a6eb in hex) was found. It has the requested 1492 prefix, but it shouldn't be included in the result, because we ask to start from the 1492b4 path and this item is located at the 1492b3... path.
Expected behavior
We should check the path returned after Seek against from argument.
Describe the bug
findstates
RPC handler introduced in #638 seems to have a bug in the results filtering logic when the fourth argument (key
to start the search from) is specified. The bug happens due to invalidMPTTrie.Find
behaviour:from
starts with the specified prefix - that's OK.path
to thestart
node is returned fromSeek
method. Thispath
can be the same as the prefix passed toSeek
, or it can also be longer than the prefix in case if the last node found by that prefix is an extension. And that's also OK.path
with anoffset
equals to the length of this path. Here's the place where the bug occurs. If the newpath
is longer than prefix, then we do not perform the comparison ofpath
's extra bytes withfrom
argument like it is done in step 1. We just start searching from the offset.For example, we want to find all storage items with prefix
abc
starting fromabcdef
. Let's suppose that Extension node is located at the pathab
and has the Key equal tocc
. ThenSeek
withabc
prefix will give uspath
=abcc
and thestart
node equals the Extension's Next. After that we'll start the traversal process withabcc
path, fromabcdef
and4
offset. I.e. we'll traverse from thestart
node with theef
path and will probably find some suitable MPT nodes. That's not correct, because this algorithm doesn't take into account newabcc
path which is less than theabcdef
at the fourth byte (c
<d
). So we shouldn't return anything from that query.To Reproduce
I found the described situation in the current testnet, so to reproduce this bug send
findstates
RPC call to the v3.0.3 testnet C# node with the following arguments:FJI=
prefix (1492
in hex)FJK0
(1492b4
in hex)The result is:
So you can see that the single storage item with key
FJKznHeqYPKbV8FzztkX8X/TIabr
(1492b39c77aa60f29b57c173ced917f17fd321a6eb
in hex) was found. It has the requested1492
prefix, but it shouldn't be included in the result, because we ask to start from the1492b4
path and this item is located at the1492b3...
path.Expected behavior
We should check the
path
returned afterSeek
againstfrom
argument.You can see the way how this case is handled in the Go implementation: https://github.com/nspcc-dev/neo-go/blob/40dfca3edae9d99dd79f7884584a241fe382387c/pkg/core/mpt/trie.go#L549.
Platform:
The text was updated successfully, but these errors were encountered: