[go: up one dir, main page]

EVM Node: Initial support for the `finalized` block parameter

Thomas Letanrequested to merge
lthms@etherlink--finalized into master

According to the JSON RPC API (at the very least according to some JSON RPC API specification), finalized is valid block parameter. For instance, on the Ethereum official website, the full list of block parameters does mention finalized.

The following options are possible for the defaultBlock parameter:

 -  HEX String - an integer block number
 -  String "earliest" for the earliest/genesis block
 -  String "latest" - for the latest mined block
 -  String "safe" - for the latest safe head block
 -  String "finalized" - for the latest finalized block
 -  String "pending" - for the pending state/transactions

It turns out that supporting this is actually quite straightforward. The proxy and sequencer modes already keeps track of the “confirmed” level (another name for finalized) for the metrics. We just have to store it in the session type of the Evm context to be able to retreived it when needs be. The current implementation has an obvious shortcoming, in that the value of the finalized level is not initialized at startup time. For the EVM node to return the expected value, it needs to see a new block being applied by a remote rollup node. Considering it is something that is happening very regularly on our networks (both Mainnet and Testnet), this is an acceptable compromise to make the patch simpler. Obviously, we will need to fix this in the future.

Additionally, the Rollup node also supports the finalized block id, which we can use instead of head. This is basically the hidden perl that we needed to quickly implement this future for the proxy.

Manually testing the MR

; dune exec -- etherlink/tezt/tests/main.exe  --title 'Alpha: The finalized block parameter is correctly interpreted by the EVM node (sequencer, latest) (without dal)' --verbose

Checklist

  • Document the interface of any function added or modified (see the coding guidelines)
  • Document any change to the user interface, including configuration parameters (see node configuration)
  • Provide automatic testing (see the testing guide).
  • For new features and bug fixes, add an item in the appropriate changelog (docs/protocols/alpha.rst for the protocol and the environment, CHANGES.rst at the root of the repository for everything else).
  • Select suitable reviewers using the Reviewers field below.
  • Select as Assignee the next person who should take action on that MR

Merge request reports