feat(Reth): Explore support for a `ms` timestamp in Emerald

[jmalicevic]

The granularity of block timestamps if right now enforced by Reth and is in seconds.

For chains running on Etherium this is acceptable as the block time is usually multiple seconds. For Emerald, with subsecond blocks we need to see how would supporting this in Emerald look like.

Currently the block timestamp is handled by building a custom version of Reth by accepting blocks with the same timestamp:
#109

[bastienfaivre]

After investigation, I describe here the current status of timestamp usage and potential solutions to migrate to millisecond timestamp support.

Status quo

As mentioned above, Emerald achieves sub-second block production despite using second-level timestamps in block headers. This is accomplished through:

1. Application-level timing: The min_block_time config parameter enforces sub-second interval (such as 500ms).
2. Custom Reth consensus validators: Timestamp validation of Reth is modified to allow multiple blocks within the same second.
3. Standard EVM timestamps: Block headers use the standard second timestamp. The timestamp is created in engine/src/engine.rs.

Before diving into propositions to integrate millisecond timestamps, we need to clarify a few points:

• Primary use case: Why are millisecond timestamps needed? Is there a specific technical module that requires this strict ordering of blocks?
• Smart contract requirement: Would smart contracts (and more generally, EVM-layer actors) need or benefit from reading millisecond timestamps, or is application/RPC access sufficient?

Millisecond Extension Field

The first possible approach is to add optional millisecond precision in the extra_data field of block headers. This technique would allow reconstruction of precise timestamps from chain data, as well as the availability of this info for the smart contracts. Moreover, this approach ensures backward compatibility with Ethereum tooling (standard fields remain unchanged).

However, the implementation of this approach is quite complex. Indeed, the system might modify extra_data to include the precise timestamp after Reth generated the block, invalidating the first computed block_hash. One would need to correctly recompute it using proper RLP encoding.

Moreover, this approach also restricts extra_data usage. Indeed, a few bytes need to be reserved, which might limit other use cases. One would also need non-standard parsing logic and risk from edge cases with Reth integration.

Separate Metadata Timestamp

The second approach stores the millisecond timestamp at the application level, completely separate from EVM blocks. The idea is to use a new table in the application database that stores the millisecond timestamps.

This approach has zero EVM impact and requires no Reth modifications (actual custom Reth remains unchanged). Moreover, it is fully Ethereum compatible. Furthermore, this new storage table is flexible and can be extended with potential other future fields one would need for blocks.

However, this approach leads to a dual timestamp system (one in the application, one in EVM), especially for validation. Moreover, this precise timestamp cannot be read by smart contracts. Finally, note that the application's state might differ between different nodes, which could lead to some issues with precise timestamp egalitarian availability.

Summary

Aspect	Option 1 (Status Quo)	Option 2 (Extra Data)	Option 4 (Metadata)
Ethereum Compatibility	Full	Full	Full
Millisecond Precision	No	Yes (in header)	Yes (application)
extra_data Usage	Unrestricted	2 bytes reserved	Unrestricted
Smart Contract Access	No	Possible (custom)	No
Validation Complexity	Minimal	High	Medium
On-Chain Timestamp	Seconds only	Milliseconds	Seconds only

Remark

Clock Synchronization

It is worth mentioning that all options requiring millisecond precision validation depend on synchronized system clocks across validators! Indeed, if min_block_time is set to a relatively low value, then the delta between validators' clocks might be an issue. One could minimize this risk using clock synchronization with NTP or PTP, but this brings quite heavy requirements for someone who wants to run a node.