NEP-568: Resharding V3

neps/nep-0568.md

@@ -205,6 +205,46 @@ The change we propose is to move the initial state download point to one in the
 
 ### Cross Shard Traffic
 
+When the shard layout changes, it is crucial to handle cross-shard traffic
+correctly, especially in the presence of missing chunks. Care must be taken to
+ensure that no receipt is lost or duplicated. There are two important receipt
+types that need to be considered - the outgoing receipts and the incoming
+receipts.
+
+Note - this proposal reuses the approach taken by ReshardingV2. 
+
+#### Outgoing Receipts
+
+Each new chunk in a shard contains a list of outgoing receipts generated during
+the processing of the previous chunk in that shard.
+
+In cases where chunks are missing at the resharding boundary, both child shards
+could theoretically include the outgoing receipts from their shared ancestor
+chunk. However, this naive approach would lead to the duplication of receipts,
+which must be avoided.
+
+The proposed solution is to reassign the outgoing receipts from the parent chunk
+to only one of the child shards. Specifically, the child shard with the lower
+shard ID will claim all outgoing receipts from the parent, while the other child
+will receive none. This ensures that all receipts are processed exactly once. 
+
+#### Incoming Receipts
+
+To process a chunk in a shard, it is necessary to gather all outgoing receipts
+from other shards that are targeted at this shard. These receipts must then be
+included as incoming receipts.
+
+In the presence of missing chunks, the new chunk must collect receipts from all
+previous blocks, spanning the period since the last new chunk in this shard.
+This range may cross the resharding boundary.
+
+When this occurs, the chunk must also consider receipts that were previously
+targeted at its parent shard. However, it must filter these receipts to include
+only those where the recipient lies within the current shard, discarding those
+where the recipient belongs to the sibling shard in the new shard layout. This
+filtering process ensures that every receipt is processed exactly once and in
+the correct shard. 
+
 ### Delayed Receipt Handling
 
 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.