Allow opting out of beacon engine timestamp check

[emostov]

Describe the feature

To support sub second block times, it would be helpful to disable the timestamp check here

reth/crates/consensus/beacon/src/engine/mod.rs

Lines 1174 to 1176 in 1ba631b

	if attrs.timestamp() <= head.timestamp {
	return OnForkChoiceUpdated::invalid_payload_attributes()
	}

The Ethereum engine api spec enforces that the timestamp on new execution block must be greater then the previous block. Execution block timestamps are denominated in seconds, so if blocks are being requested within a second of each other they are likely to have the exact same timestamp and Reth will not create/validate the block.

To quickly fix this I propose allowing a way to opt out of the timestamp check - either with a runtime configuration or compilation feature gate. @mattsse mentioned here that they have some pointers on how to tackle this.

Additional context

No response

Tasks

Beta Give feedback

No tasks being tracked yet.

[nadtech-hub]

Do you mind me working on this one?

[mattsse]

the way this should be done is by extending

reth/crates/engine/primitives/src/lib.rs

Line 45 in 0dbc374

pub trait EngineValidator<Types: EngineTypes>: Clone + Send + Sync + Unpin + 'static {

with checks for payload against header and then plugged into the engine impl

[emostov]

@mattsse thanks for the response! I think I might be missing something. From my read, implementing EngineValidator will allow me to add custom validation at the RPC level but will not allow me bypass the timestamp validation done by the engine.

Specifically in the case of forkchoice updated, the ensure_well_formed_attributes is called here

reth/crates/rpc/rpc-engine-api/src/engine_api.rs

Line 601 in 0dbc374

self.inner.validator.ensure_well_formed_attributes(version, attrs);

which then uses the consensus engine handle to normally call the new engine-tree logic here:

reth/crates/rpc/rpc-engine-api/src/engine_api.rs

Line 617 in 0dbc374

let fcu_res = self.inner.beacon_consensus.fork_choice_updated(state, None).await?;

In the engine-tree logic it appears the payload is still unconditionally subject to the timestamp check here

reth/crates/engine/tree/src/tree/mod.rs

Line 2491 in 0dbc374

if attrs.timestamp() <= head.timestamp {

Which is executed by the BeaconEngineMessage::ForkchoiceUpdated request handler

reth/crates/engine/tree/src/tree/mod.rs

Line 970 in 0dbc374

fn on_forkchoice_updated(

Is my understanding correct here?

EDIT: rereading your comment again, is your suggestion to create a PR that adds a method to the EngineValidator trait for checking the payload against the header and then calling that new method in process_payload_attributes instead of doing the timestamp check? If so, I can work on that

[mattsse]

ereading your comment again, is your suggestion to create a PR that adds a method to the EngineValidator trait for

I thought about this a bit, and I think we could start introducing a different trait for this entirely like a new validator trait or similar

[emostov]

Makes sense. I will try and work on something later this week. Feel free to assign it to me

[github-actions]

This issue is stale because it has been open for 21 days with no activity.