Skip to content

Conversation

@eserilev
Copy link
Member

@eserilev eserilev commented Nov 13, 2025

Issue Addressed

RPCBlock, within the context of range sync, is always available. The availability checks in process_chain_segment are therefore superfluous and make the code difficult to reason about. If RPCBlock is always available, that enables strong type safety guarantees in downstream chain segment processing.

The only place outside of range sync where RPCBlock is used is in block lookup. During block lookup, the RPCBlock is not guaranteed to be available. Therefore it makes sense to introduce a new type for block lookup e.g. MaybeAvailableRpcBlock so that the construction of an RPCBlock has type-level availability guarantees.

Proposed Changes

Split process_block into process_sync_block and the existing process_block. The RPCBlock code path will use process_sync_block which removes all availability checks, as the RpcBlock type already guarantees availability.

New Types Introduced

  • AvailableExecutionPendingBlock: Similar to ExecutionPendingBlock, but instead of having a MaybeAvailableBlock it contains an AvailableBlock

New traits introduced

  • BlockWithAvailabilityStatus: Used as a generic across AvailableBlock and MaybeAvailableBlock to expose helper functions needed for process_block and process_sync_block.
  • GenericExecutionPendingBlock: Used as a generic across AvailableExecutionPendingBlock and ExecutionPendingBlock. Allows for code reuse for fn from_signature_verified_components across the two types.

Type changes

  • SignatureVerifiedBlock: the block field is now a generic BlockWithAvailabilityStatus. This allows for code reuse across AvailableBlock and MaybeAvailableBlock

TODOs

More info soon

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant