Conversation
| self.logger.info("peer {s}{} is ahead (peer_finalized_slot={d} > our_head_slot={d}), initiating sync by requesting head block 0x{s}", .{ | ||
| status_ctx.peer_id, | ||
| self.node_registry.getNodeNameFromPeerId(status_ctx.peer_id), | ||
| status_resp.finalized_slot, | ||
| info.head_slot, | ||
| std.fmt.fmtSliceHexLower(&status_resp.head_root), | ||
| }); | ||
| const roots = [_]types.Root{status_resp.head_root}; | ||
| self.fetchBlockByRoots(&roots, 0) catch |err| { | ||
| self.logger.warn("failed to initiate sync by fetching head block from peer {s}{}: {any}", .{ |
There was a problem hiding this comment.
Up here we have peer_finalized_slot > our_finalized_slot , But the log says "our_head_slot" and prints info.head_slot.
self.chain.forkChoice.fcStore.latest_finalized.slot , // ← Use finalized, not head root
There was a problem hiding this comment.
so syncStatus makes the comparison between the current finalized and highest finalized slot amongst the peer. I don't exactly understand what modification you expect here
There was a problem hiding this comment.
The log says our_head_slot but we're comparing finalized slots.
| if (self.network.fetched_blocks.count() >= constants.MAX_CACHED_BLOCKS) { | ||
| self.logger.warn("Cache full ({d} blocks), rejecting block 0x{s} at slot {d}", .{ | ||
| self.network.fetched_blocks.count(), | ||
| std.fmt.fmtSliceHexLower(block_root[0..]), | ||
| block_slot, | ||
| }); | ||
| return CacheBlockError.CachingFailed; |
There was a problem hiding this comment.
Is there a reason we are doing a hard rejection when the cache structures are full?
Can't we do a slot based cache eviction, where the slot farthest from the
current canonical tip can be evicted.
There was a problem hiding this comment.
I had suggested this in the issue but I cannot think of situation which leads us to this , unless we stop having finalization. And even when finalization is delayed we have good buffer of 1024 blocks. On finalization pruning occurs and removes all the blocks behind latest finalized slot
There was a problem hiding this comment.
My concern is a peer spamming orphan blocks to fill the cache these won't be pruned by finalization since they're not connected to the canonical chain.
There was a problem hiding this comment.
validateBlock should reject most of the blocks doing that, I intentionally avoided signature verification here so that it is an inexpensive validation. We have additional checks in cacheBlockAndFetchParent to prevent spams
3 participants
closes #528