Some items were moved from Amphora Spec changes and issues
coinbase
to fee_recipient
in the specforkchoiceUpdated
to trigger build process for the first payload ever
consensus-specs
repositorypow_chain
vs pow_block_tree
, rename PowBlock -> PowAttributes
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
TERMINAL_BLOCK_HASH
on EL sideget_safe_head
as a fork choice rule extension, place it near to /specs
folderreceipt_root
-> receipts_root
RANDOM
security consideration: biasability/predictabilitySLOTS_PER_SECOND / 30
, #91SECONDS_PER_SLOT
to the execution client (or all of the parameters)?getPayloadsByRange
to engine API for payload deduplication across CL/EL โ see doc for discussion
BeaconBlocksByRange
to replace payloads with their rootsengine_getBlockBodiesByRange
and store ExecutionPayloadHeader
on CL sideforkchoiceUpdated
calls coming from CL is incorrectfeeRecipient
to suggestedFeeRecipient
in the API callengine_executePayload
and engine_forkchoiceUpdated
method MUST continue to be called optimistically to give info to EL. To aid sync and avoid deadlocksSYNCING
, this must not block validator duties as then the network will get stuck, see no 5. hereforkchoiceUpdated
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 chainweb3.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)finalized
, safe
, unsafe
, latest == safe
eth_hashrate
, eth_getWork
, eth_submitWork
etc