Add quick slots (EIP-8198)

[barnabemonnot]

EIP-8198 (quick slots) proposes shortening the slot duration. This PR adds the consensus-layer feature specification under specs/_features/eip8198, built on Heze, so the mechanism can be reviewed and prototyped.

Updates and design decisions

• The slot duration becomes governed by a SLOT_DURATION_SCHEDULE configuration that changes it at a scheduled epoch (the intended mainnet entry is 10 seconds, epoch TBD), making the mapping between wall-clock time and slot number piecewise across the schedule's eras. The schedule does not intend to support BPO-like slot duration changes in-between upgrades: We make the strong assumption here that slot time reductions will always happen during non-BPO-like network upgrades. The schedule is simply a way to loop over historical slot durations in functions that require accumulating this data, such as computing the current slot number given a timestamp.
• Issuance, penalties, and churn limits rescale with the active duration.
• Intra-slot deadlines do not rescale with the active duration, as these may benefit from individual optimisation accounting for fixed overheads in certain slot moments. Choosing the deadlines is deferred until further testing.
• The fork-choice store clock gains millisecond precision
• Gossip slot gates and sidecar retention windows preserve their wall-clock semantics across a duration change. In particular, blobs are kept for the same wall-clock duration as they were before the transition to shorter slots.
• To keep throughput unchanged at the transition, we choose the approach of programmatically reducing the gas limit per block hours before the fork epoch, arriving at the gas limit per block that maintains throughput once the transition is performed.
• Beacon-chain, fork, fork-choice, p2p, validator, and optimistic-sync documents are included, along with unit and fork-choice tests.

Execution layer considerations

We do not require tight coupling with the execution layer. In particular, the execution layer is not expected to consume the slot time from the consensus layer, keeping the separation of concerns. That said, two items require updating:

• The base fee update rule needs a one-time constant update, to maintain the same rate of change per unit of time.
• The blob schedules must be re-parameterised, to maintain constant blob target.

[jihoonsong]

I would appreciate it if the PR authors would review and simplify AI-generated comments.

[jtraglia]

This change needs to exist inside an executable function. See:

consensus-specs/specs/gloas/p2p-interface.md

Lines 942 to 1065 in 566e1eb

	def validate_execution_payload_bid_gossip(
	seen: Seen,
	store: Store,
	signed_execution_payload_bid: SignedExecutionPayloadBid,
	current_time_ms: Uint64,
	) -> None:
	"""
	Validate a SignedExecutionPayloadBid for gossip propagation.
	Raises GossipIgnore or GossipReject on validation failure.
	"""
	bid = signed_execution_payload_bid.message
	# [IGNORE] This is the first bid for this slot, parent, and builder
	bid_key = (bid.slot, bid.parent_block_hash, bid.parent_block_root, bid.builder_index)
	if bid_key in seen.execution_payload_bids:
	raise GossipIgnore("already seen valid bid for this slot, parent, and builder")
	# [IGNORE] This is the highest value bid seen for the slot and parent
	best_bid_key = (bid.slot, bid.parent_block_hash, bid.parent_block_root)
	if best_bid_key in seen.best_execution_payload_bid:
	if bid.value <= seen.best_execution_payload_bid[best_bid_key]:
	raise GossipIgnore("bid is not the highest value bid seen for this slot and parent")
	# [IGNORE] The bid's slot is the current slot or the next slot
	if not is_current_or_next_slot(store, bid.slot, current_time_ms):
	raise GossipIgnore("bid's slot is not the current or next slot")
	# [REJECT] The bid's execution payment is zero
	if bid.execution_payment != 0:
	raise GossipReject("bid's execution payment must be zero")
	# [REJECT] The bid's blob KZG commitment count is within the per-epoch limit
	proposal_epoch = compute_epoch_at_slot(bid.slot)
	max_blobs = get_blob_parameters(proposal_epoch).max_blobs_per_block
	if len(bid.blob_kzg_commitments) > max_blobs:
	raise GossipReject("too many blob kzg commitments")
	# [IGNORE] The bid's parent block root is a known beacon block
	# (MAY be queued until parent is retrieved)
	if bid.parent_block_root not in store.blocks:
	raise GossipIgnore("bid's parent block root is not a known beacon block")
	# [REJECT] The bid is for a higher slot than its parent block
	if bid.slot <= store.blocks[bid.parent_block_root].slot:
	raise GossipReject("bid's slot is not higher than its parent's slot")
	# [IGNORE] The bid's parent block has been imported
	# (MAY be queued until parent is imported)
	if bid.parent_block_root not in store.block_states:
	raise GossipIgnore("bid's parent block post-state is unavailable")
	state = store.block_states[bid.parent_block_root]
	# [IGNORE] The bid's slot is within the parent's proposer lookahead
	if proposal_epoch > get_current_epoch(state) + MIN_SEED_LOOKAHEAD:
	raise GossipIgnore("bid's slot is past the parent's proposer lookahead")
	# [IGNORE] The matching proposer preferences have been seen
	dependent_root = get_shuffling_dependent_root(store, bid.parent_block_root, proposal_epoch)
	prefs_key = (bid.slot, dependent_root)
	if prefs_key not in seen.proposer_preferences:
	raise GossipIgnore("matching proposer preferences have not been seen")
	proposer_preferences = seen.proposer_preferences[prefs_key]
	# [IGNORE] The bid's fee recipient matches the proposer's preference
	if bid.fee_recipient != proposer_preferences.fee_recipient:
	raise GossipIgnore("bid's fee recipient does not match the proposer's preference")
	# [IGNORE] The bid's parent block hash is the hash of a known execution payload
	if bid.parent_block_hash not in seen.execution_payloads:
	raise GossipIgnore("bid's parent block hash is not a known execution payload")
	# [IGNORE] The bid's gas limit is compatible with the proposer's target gas limit
	parent_gas_limit = seen.execution_payloads[bid.parent_block_hash].gas_limit
	if not is_gas_limit_target_compatible(
	parent_gas_limit, bid.gas_limit, proposer_preferences.target_gas_limit
	):
	raise GossipIgnore("bid's gas limit is not compatible with the proposer's target")
	# [IGNORE] The bid is compatible with the current head branch
	if not is_bid_compatible_with_head(store, bid):
	raise GossipIgnore("bid is not compatible with the current head branch")
	# [REJECT] The bid's previous randao is correct
	if bid.prev_randao != get_randao_mix(state, get_current_epoch(state)):
	raise GossipReject("bid's previous randao is incorrect")
	state = state.copy()
	process_slots(state, bid.slot)
	# [REJECT] The builder index is valid
	if bid.builder_index >= len(state.builders):
	raise GossipReject("builder index out of range")
	builder = state.builders[bid.builder_index]
	# [REJECT] The builder is a payload builder
	if builder.version != PAYLOAD_BUILDER_VERSION:
	raise GossipReject("builder is not a payload builder")
	# [REJECT] The builder is active
	if not is_active_builder(state, bid.builder_index):
	raise GossipReject("builder is not active")
	# [IGNORE] The builder can cover the bid
	if not can_builder_cover_bid(state, bid.builder_index, bid.value):
	raise GossipIgnore("builder cannot cover bid value")
	# [IGNORE] The parent's payload does not try to exit the builder
	if bid.parent_block_hash == state.latest_execution_payload_bid.block_hash:
	envelope = store.payloads[bid.parent_block_root]
	for request in envelope.execution_requests.builder_exits:
	if request.pubkey == builder.pubkey:
	if request.source_address == builder.execution_address:
	raise GossipIgnore("builder may exit")
	# [REJECT] The bid signature is valid
	if not verify_execution_payload_bid_signature(state, signed_execution_payload_bid):
	raise GossipReject("invalid bid signature")
	# Mark this bid as seen and update the highest-value bid for this slot/parent
	seen.execution_payload_bids.add(bid_key)
	seen.best_execution_payload_bid[best_bid_key] = bid.value

[jtraglia]

But again, not sure this is a good idea. If this depends on an update in the execution layer (does it?), this EIP becomes way more complicated.

[jtraglia]

I think this could exist as a separate check from is_gas_limit_target_compatible. Eg:

• IGNORE if is_gas_limit_transition_compatible() is False.
• IGNORE if is_gas_limit_target_compatible() is False.

Also, it appears that this forces bids at the fork to use a gas limit based on parent_gas_limit which might not be what they want to do.

[fradamt]

Could make it a bound, within ± 1024 of that value. However, I am also not sure about the necessity for this. We will most likely do more scaling with Hegota, we could just adjust the target gas limit based on the slot time. E.g. if the plan would be to scale from 200M to 300M but slot time reduction implies a 25% reduction in per slot throughput, we could just target 225M instead.

Another reason to take this approach is that simply scaling by (new slot time / old slot time) isn't really accurate in general

[jtraglia]

Nice updates @barnabemonnot! I'll re-review this again early next week.

[barnabemonnot]

Nice updates @barnabemonnot! I'll re-review this again early next week.

Thank you @jtraglia . For reference here is a quick digest of open items I'll try and address by next week:

• Deprecate SLOT_DURATION_MS?
• Prevent leaks with EL => Decide how to handle base fee update rule re-parameterisation
• Handle block gas limit at the fork to maintain constant throughput: either reduce gas progressively before the fork itself, or as @fradamt mentioned, assume that gas will be increased post-fork given scaling gains, and adjust gas per block before the block.
• Should fork digest depend on the slot duration? Only helpful if slot time decreases are done out-of-forks.
• Resolve blob schedule question: keep throughput constant, or keep blob targets/limits integers?

[terencechain]

1. On retention in p2p-interface.md:

this only rescales the data column window. MIN_EPOCHS_FOR_BLOCK_REQUESTS stays an epoch count, so the block serve window shrinks by r in wall clock, while compute_weak_subjectivity_period is driven by per-epoch churn that this PR scales by r, so the WS period in epochs grows by 1/r. Those move in opposite directions and can cross.

2. On gas limit:

Shorter slots at the same per-block gas limit raise throughput by 1/r at the fork, and the usual adjustment rule can only move 1/1024 per block, having proposers to coordinate hours ahead may be prune to bugs. Suggest the schedule entries at or after the duration change are scaled to gas_limit * new_ms // old_ms, so GAS_LIMIT_SCHEDULE stay consistent