EIP-4788: Beacon block root in the EVM

[lorenzogentile404]

Impact

Notes

From the Block processing section

Clients may decide to omit an explicit EVM call and directly set the storage values. Note: While this is a valid optimization for Ethereum mainnet, it could be problematic on non-mainnet situations in case a different contract is used.

So this means we could do this as a special operation at the start of every block

From The Beacon Chain Ethereum 2.0 explainer you need to read first

A slot is a chance for a block to be added to the Beacon Chain. Every 12 seconds, one block is added when the system is running optimally. Validators do need to be roughly synchronized with time.

A slot is like the block time, but slots can be empty. The Beacon Chain genesis block is at Slot 0

It seems that one way to do this would be to have a new TX_BCNRT (better: BLK_BCNRT) phase which would consist of

• a MISC/OOB row where we perform something like t ≡ TIMESTAMP mod 8191
• a STORAGE row where we insert the TIMESTAMP at t, and BEACON_ROOT at t + 8191
• maybe we need a TXN root and we must insert the BEACON_ROOT into the TXN_DATA module

Question: how do you initially deploy the SMC ?

Test vectors

Issues

This EIP presents issues to implementation on Linea:

• Linea's BLOCK_PERIOD isn't precisely set (in theory we propose a block every 3 seconds (soon to be 2)) but it doesn't have to be precisely BLOCK_PERIOD nor a multiple of it
• IIUC L1 produces a block precisely every 12 seconds
• Linea would thus update the SMC 4 to 6 times more often than L1
• this means we can't guarantee that the SMC will behave as expected, in particular the property of having 8191 past BEACON_ROOT's available at any point in time (possibly with gaps)
• also the TIMESTAMP of Linea blocks has bear any correlation with that of the L1

There is one workaround where in the public data we provide an time ordered list of pairs (time_stamp, beacon_root), where the time_stamp's are that of L1, and whenever a Linea block's time_stamp exceeds a new time_stamp we include all the missing beacon_root's in the storage of the relevant SMC.

@FlorianHuc What's your opinion on the above ?