Repository navigation
Consensus-layer Call 140 #1129
Description
Activity
I'd like to revisit the name of the F-star for the hard fork after Pectra.
Results integrated from various sources here: https://ethereum-magicians.org/t/f-star-name-for-consensus-layer-upgrade-after-electra/20285
Would suggest we go with
Fuluand use the portmanteauFosakaReacted by Andrew B Coathup, Hsiao-Wei Wang and Mario VegaReacted by Andrew B CoathupI would like to get some feedback on this PR based on @potuz's proposal of moving the execution layer request out of the execution payload.
TLDR: we move
deposit_requests,withdrawal_requests, andconsolidation_requestsinto a new containerExecutionLayerRequests, and make them part ofBeaconBlockBody, removing them fromExecutionPayload. This "restores" the assumption that the full Execution Payload isn't necessary for the CL performing state transition.This issue has more context and some discussion: ethereum/consensus-specs#3856
And this is the PR with the proposed changes: ethereum/consensus-specs#3875
p.s. unfortunately the call isn't at a suitable time for me so please direct any questions/comments to the issue. During the call, maybe @potuz or @mkalinin will be around and can help with more context and answering questions.
Want to give a quick overview of the following change:
I'd like to present a summary of the results that ProbeLab has done on the GossipSub domain. I will present our most relevant findings and the main takeaways from the study.
Of course, all feedback and suggestions for further studies and improvement will be highly appreciated.Updates: I've uploaded the slides to IPFS, feel free to fetch them using the following CID:
QmURBPigXY9LjGuumwRohrXfhhi26RZmWHKQT2RjcUEQAyReacted by Yiannis Psarasblob flexibility in clients -- is the limit a compile-time constant? how easy is it to change?
latest on EL/CL blob uncoupling
Hello can we have a final check on ethereum/execution-apis#565
Not in call myself, but would like to bring up:
- Synchronously check all
transactionsto have non-zero length consensus-specs#3885 --- CLs may not do newPayload on every single block (to avoid engine API overhead), or may even support optimistic syncing without an EL (maintenance etc)
- These CLs still need to do minimal checks on every block that doesn't go through newPayload, to ensure that the execution data in the beacon block is linked with the
body.execution_payload.block_hash(so that it is guaranteed that everything building on thisblock_hashis also INVALID if there are asynchronous errors found later on by the EL). The minimal checks are:- No tx can be
[](the one added in the issue) - EL block hash must match the execution data
blob_kzg_commitmentsmust match theblob_versioned_hashesfrom EIP-4844 blob transactions
- No tx can be
- The empty tx check is already present in most ELs, so no immediate rush. But still advising CLs to check their impls, even though this only affects non-validating clients (validating clients use
newPayloadand therefore have the EL perform the checks already).
- Generally, the pitfalls with
newPayloadabove are prompted by reluctance to move forward with issues such as SSZification. Aligning data formats across CL, EL, and engine API, while not being visible changes externally, are still important to keep complexity from growing. - EIP-7688 CL StableContainer kurtosis config updated for latest Lodestar, would be great to also add grandine, lighthouse, prysm eventually (config @ https://stabilitynow.box)
- EIP-7732 enshrined proposer / builder separation: Personally in support of it (also benefits from SSZ 'optional's)
- Synchronously check all
Podcast (audio only) - https://open.spotify.com/episode/7gPCCsgSq6LCDzt0qHbyFL?si=n40e3HS3T_2KrThfn_bC2w
Reacted by Andrew B Coathup and Akash Kshirsagarclosing in lieu of #1140
Consensus-layer Call 140
prev: call 139
Meeting Date/Time: Thursday 2024/8/22 at 14:00 UTC
Meeting Duration: 1.5 hours
stream
ExecutionPayloadin CL data type