Try   HackMD

The Merge Spec changes and issues

Some items were moved from Amphora Spec changes and issues

CL specs

  • clarify the communication with EL during the transition, i.e. go through each EE method call and make a note if needed
  • [#2741] remove CLI args to override TTD and TBH
  • [#2728] consider renaming coinbase to fee_recipient in the spec
  • specify how to send forkchoiceUpdated to trigger build process for the first payload ever
    • it's already handled in the validator guide of the Merge spec in consensus-specs repository
  • refine terminal block handling in validator guide: pow_chain vs pow_block_tree, rename PowBlock -> PowAttributes
    • related issue #2636
    • pow_chain shouldn't necessarily contain a block with TERMINAL_BLOCK_HASH as this block might belong to a minority fork to the local observation of EL; consider pow_block_tree vs get_pow_block to query for TBH
      • this is resolved by whitlisting TERMINAL_BLOCK_HASH on EL side
    • renaming might not be necessary
  • Note in the merge p2p-interface that block validation is extended with payload execution extending the semantics of rules based on block validation
    • Optimistic sync relies on propagating blcoks without validation of an execution payload
  • Add get_safe_head as a fork choice rule extension, place it near to /specs folder
  • receipt_root -> receipts_root

EL specs

  • EIP-3675
    • [#4487] revisit EIP-2124 logic, see the concern
    • [#4463] EIP-3675: say that historical blocks are no longer a requisite for the node sync in security considerations
  • EL clients require TTD to be known in advance #2724
    • [#4466] EIP-3675: BRING TTD BACK!!!
    • [#132] Engine API: consider adding meaningful errors if CL tries to do the transition at a TTD value that is unexpected to EL
    • [#4493] EIP-3675: add TERMINAL_BLOCK_HASH (consider picking another name) to whitelist the branch that is used for emergency Merge
  • [EIP-4444] EL client software MAY NOT store data of entire chain history (headers, bodies, receipts) (assigned to: lightclient, george, etc)
  • EIP-4399

Engine API

  • Engine API authentication
    • Consider to use JWT
  • define QoS expectation on return – e.g. 0.5s or SLOTS_PER_SECOND / 30, #91
  • pass SECONDS_PER_SLOT to the execution client (or all of the parameters)?
  • [#146] consider adding getPayloadsByRange to engine API for payload deduplication across CL/EL – see doc for discussion
    • consider the option for BeaconBlocksByRange to replace payloads with their roots
    • consider the option of engine_getBlockBodiesByRange and store ExecutionPayloadHeader on CL side
  • [#148] Refine Message ordering. Take 2
    • Respond with error if the order of forkchoiceUpdated calls coming from CL is incorrect
  • [#133] Refine Message ordering
    • "Execution Layer client software MUST execute calls strictly in the order of request IDs to avoid degenerate race conditions." – potentially opens a DoS vector as a block that takes too long to be executed may brick the client
    • "Consensus Layer client software MUST utilize JSON-RPC request IDs that are strictly increasing." – CL must also send messages respecting order they appear in the system
  • [#130] consider renaming feeRecipient to suggestedFeeRecipient in the API call
  • [#135] send payload validation error to CL #120
  • [#134] Use the same port for HTTP and WebSocket, additional port is redundant

Optimistic sync

  • [#2770] Aim to write a spec
    • Add clear directives that engine_executePayload and engine_forkchoiceUpdated method MUST continue to be called optimistically to give info to EL. To aid sync and avoid deadlocks
    • [solution] non-existing PoW block as a parent of the merge block turns on SYNCING, this must not block validator duties as then the network will get stuck, see no 5. here
    • [ADDED TO THE TEST PLAN] Add a test case checking this scenario

JSON-RPC API

  • consider forkchoiceUpdated and/or executePayload(child_payload) as a confirmation of block's validity wrt PoS rules; i.e. space of "unsafe" blocks could be reduced to leaf blocks that have never been in the canonical chain
  • add warning to web3.eth.getBlockByHash (or similar method) that blocks have not necessarily been corectly validated wtr beacon chain consensus. Point them to beacon API to do so. Probably need web3.beacon.getBeaconBlocksByExecutionPayloadHash to satisfy this. note that this is plural because multiple beacon blocks can include the same exact payload (i.e. sister blocks that have same exec payload contents)
  • update block tags: finalized, safe, unsafe, latest == safe
  • deprecate methods related to PoW, i.e. eth_hashrate, eth_getWork, eth_submitWork etc
  • consider client specific RPC methods, https://geth.ethereum.org/docs/rpc

Release

  • Merge release procedure

Testing

Hive

  • CL simulator
    • covers Engine API implementation by EL and EIP-3675 requirements including:
      • the Networking section (block gossip deprecation)
      • TTD hardcode, TTD and TBH (terminal block hash) overrides
      • fast/snap sync and processing blocks received via gossip MUST respect TTD and TBH
    • relies on the Engine API as a entry point, should have a predefined Engine API calls as a test vector
  • CL+EL fully functional nodes
    • covers transition process with various edge cases that may appear in it
      • network partitioning, involves two nodes; a terminal block is withheld by a node and after some time released to another node; it should be successfully processed
      • passing a terminal block point while syncing; then CL must go back and validate terminal block conditions, finalized and not yet finalized cases should be covered; similar to the case when block is withheld
    • covers Engine API implementation by CL
    • covers consensus specs
    • CL reads pre-loaded list of blocks, need to figure out how to emulate network partitioning
  • Run all tests with all possible client combinations
Last changed by 
 
Mikhail Kalinin
0
151
Published on HackMD