[resharding] Add sections for receipt handling #578
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Trisfald
approved these changes
Nov 21, 2024
Both have the receiver_id/account_id so should be trivial to split. I don't think we need to mention them explicitly as there's no special handling but can check with the rest of the team for their thoughts |
github-merge-queue bot
pushed a commit
to near/nearcore
that referenced
this pull request
Nov 28, 2024
This PR is the core of delayed receipt handling for resharding V3.
## Writeup from NEP
The delayed receipts queue contains all incoming receipts that could not
be executed as part of a block due to resource constraints like compute
cost, gas limits etc. The entries in the delayed receipt queue can
belong to any of the accounts as part of the shard. During a resharding
event, we ideally need to split the delayed receipts across both the
child shards according to the associated account_id with the receipt.
The singleton trie key DelayedReceiptIndices holds the start_index and
end_index associated with the delayed receipt entries for the shard. The
trie key DelayedReceipt { index } contains the actual delayed receipt
associated with some account_id. These are processed in a fifo queue
order during chunk execution.
Note that the delayed receipt trie keys do not have the account_id
prefix. In ReshardingV2, we followed the trivial solution of iterating
through all the delayed receipt queue entries and assigning them to the
appropriate child shard, however due to constraints on the state witness
size limits and instant resharding, this approach is no longer feasible
for ReshardingV3.
For ReshardingV3, we decided to handle the resharding by duplicating the
entries of the delayed receipt queue across both the child shards. This
is great from the perspective of state witness size and instant
resharding as we only need to access the delayed receipt queue root
entry in the trie, however it breaks the assumption that all delayed
receipts in a shard belong to the accounts within that shard.
To resolve this, with the new protocol version, we changed the
implementation of runtime to discard executing delayed receipts that
don't belong to the account_id on that shard.
Note that no delayed receipts are lost during resharding as all receipts
get executed exactly once based on which of the child shards does the
associated account_id belong to.
Source NEP [receipt handling
section](near/NEPs#578).
## Changes in this PR
- We change the implementation of `DelayedReceiptQueueWrapper` to add a
new filter function that filters out all delayed receipts that do not
belong to the current shard.
- `peek_iter` functions is updated appropriately to filter out delayed
receipts as well to ensure compatibility with pipelining.
- Main loop in `process_delayed_receipts` as updated from "while
processing_state.delayed_receipts.len() > 0" to something like "loop
while Some(delayed_receipt) in queue" as we no longer have a precise
count of the number of delayed receipts to process.
## Next steps
- Change memtrie split function to include delayed receipts in child
shards
- Testloop test.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This is complete except for section
Handling buffered receipts that target parent shardwhich is still being discussed.