ReshardingV3 memtrie #574
ReshardingV3 memtrie #574
Conversation
neps/nep-0568.md
Outdated
|
|
||
| With ReshardingV3 design, there's no protocol change to the structure of MemTries, however the implementation constraints required us to introduce the concept of a Frozen MemTrie. More details are in the [implementation](#state-storage---memtrie-1) section below. | ||
|
|
||
| Based on the requirements above, we came up with an algorithm to efficiently split the parent trie into two child tries. Trie entries can be divided into three categories based on whether the trie keys have an account_id prefix and based on the total number of such trie keys. Splitting of these keys are handled in different ways. |
There was a problem hiding this comment.
nit: account_id -> account_id
(I guess) Splitting of these keys is handled in different ways.
Sentence above is not crystal clear to me. What about "Each category of keys has its own splitting logic, explained below."?
|
|
||
| #### Singleton TrieKey | ||
|
|
||
| This category includes the trie keys `TrieKey::DelayedReceiptIndices`, `TrieKey::PromiseYieldIndices`, `TrieKey::BufferedReceiptIndices`. Notably, these are just a single entry (or O(num_shard) entries) in the trie and hence are small enough to read and modify for the children tries efficiently. |
There was a problem hiding this comment.
Should we say how these keys are split in practice? Or what happens to them in state witness?
There was a problem hiding this comment.
You mean what exact values do we push into the children for these keys? Yes, we should do that, but I think it would be better as part of the delayed receipts, promise yield and buffered receipts section (which I plan to add soon).
neps/nep-0568.md
Outdated
|
|
||
| #### TrieKey with AccountID prefix | ||
|
|
||
| This category includes most of the trie keys like `TrieKey::Account`, `TrieKey::ContractCode`, `TrieKey::PostponedReceipt`. For these keys, we can efficiently split the trie based on the boundary account trie key. In the example below, "pass" was the split key, note that we only need to read all the intermediate nodes that form a part of the split key and nothing more. The accessed nodes form a part of the state witness. This limits the size of the witness to effectively O(depth) of trie. |
There was a problem hiding this comment.
"note that we only need to read all the intermediate nodes that form a part of the split key"
Is this needed for building the state witness proof? While I understand the idea, it would be great if the purpose can be made more explicit
neps/nep-0568.md
Outdated
| * Cross-Shard Traffic: Receipts and buffered receipts sent to the parent shard may | ||
| need to be reassigned to one of the child shards. |
There was a problem hiding this comment.
The point below already mentions buffered receipts. I think here we can focus on the cross shard receipts (outgoing / incoming) and describe the rest (delayed, buffered, postponed, yield-resume) in a dedicated section.
I added more details about the memory footprint and in-place swap of memtries. |
|
Can you fix the lints on the main NEP PR please? |
Adding memtrie section to resharding