status-im/nimbus-eth1
2
0
Fork 0
mirror of https://github.com/status-im/nimbus-eth1.git synced 2025-01-27 04:26:07 +00:00
Code Issues Projects Releases Wiki Activity

update developers guide

Browse Source
This commit is contained in:
andri lim 2020-05-07 22:03:20 +07:00
parent bac4913a5a
commit 36c93aacb1
No known key found for this signature in database
GPG Key ID: 31702AE10541E6B9
1 changed files with 3 additions and 1 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

4
stateless/readme.md
View File

@ -36,6 +36,7 @@ Every time you request a node using a hash key, you'll get one of the 3 types of
* In Yellow Paper, the 17th elem of the `Branch Node` can contains a value. But it always empty in a real Ethereum State trie. * In Yellow Paper, the 17th elem of the `Branch Node` can contains a value. But it always empty in a real Ethereum State trie.
The block witness spec also ignore this 17th elem when encoding or decoding `Branch Node`. The block witness spec also ignore this 17th elem when encoding or decoding `Branch Node`.
This can happen because in Ethereum `Secure Hexary Trie`, every keys have uniform length of 32 bytes or 64 nibbles. This can happen because in Ethereum `Secure Hexary Trie`, every keys have uniform length of 32 bytes or 64 nibbles.
With the absence of 17th element, a `Branch Node` will never contains leaf value.
* When processing a `Branch Node` you need to emit the `hash to next elem` if the elem is not match for the current path nibble. * When processing a `Branch Node` you need to emit the `hash to next elem` if the elem is not match for the current path nibble.
* When processing a `Leaf Node` or an `Extension Node` and you meet no match condition, you'll also emit a hash. * When processing a `Leaf Node` or an `Extension Node` and you meet no match condition, you'll also emit a hash.
@ -144,7 +145,7 @@ Because the match only involve one nibble, we advance the depth only one.
### Multi keys and Leaf Node and Extension Node ### Multi keys and Leaf Node and Extension Node
If you encounter a Leaf Node or Extension Node, they will have the same algorithm to generate groups. If you encounter a `Leaf Node` or `Extension Node`, they will have the same algorithm to generate groups.
For example, we are at `depth: 1`, and we are processing `group 3: [3, 5]`. For example, we are at `depth: 1`, and we are processing `group 3: [3, 5]`.
Using the prefix nibbles from `Leaf Node` or `Extension Node`, we produce two groups if our prefix nibbles is `021`: Using the prefix nibbles from `Leaf Node` or `Extension Node`, we produce two groups if our prefix nibbles is `021`:
@ -164,6 +165,7 @@ At max we will have 3 groups, and every possible combinations will be:
* not match, match, not match(3 groups): a matching group is between two non matching groups. * not match, match, not match(3 groups): a matching group is between two non matching groups.
As you can see, we will only have a single match group or no match at all during constructing these groups. As you can see, we will only have a single match group or no match at all during constructing these groups.
And we only interested in this match group if it exist and ignore all other not matching groups.
#### A matching group for Extension Node #### A matching group for Extension Node