search for validator indices backwards while processing deposits (#5914)

beacon_chain/spec/state_transition_block.nim

@@ -269,9 +269,23 @@ func findValidatorIndex*(state: ForkyBeaconState, pubkey: ValidatorPubKey):
   # given that each block can hold no more than 16 deposits, it's slower to
   # build the table and use it for lookups than to scan it like this.
   # Once we have a reusable, long-lived cache, this should be revisited
-  for vidx in state.validators.vindices:
+  #
-    if state.validators.asSeq[vidx].pubkey == pubkey:
+  # For deposit processing purposes, two broad cases exist, either
-      return Opt[ValidatorIndex].ok(vidx)
+  #
+  # (a) someone has deposited all 32 required ETH as a single transaction,
+  #     in which case the index doesn't yet exist so the search order does
+  #     not matter so long as it's generally in an order memory controller
+  #     prefetching can predict; or
+  #
+  # (b) the deposit has been split into multiple parts, typically not far
+  #     apart from each other, such that on average one would expect this
+  #     validator index to be nearer the maximal than minimal index.
+  #
+  # countdown() infinite-loops if the lower bound with uint32 is 0, so
+  # shift indices by 1, which avoids triggering unsigned wraparound.
+  for vidx in countdown(state.validators.len.uint32, 1):
+    if state.validators.asSeq[vidx - 1].pubkey == pubkey:
+      return Opt[ValidatorIndex].ok((vidx - 1).ValidatorIndex)
 
 proc process_deposit*(cfg: RuntimeConfig,
                       state: var ForkyBeaconState,