Consensus Implementers’ Call #98 - 2022-11-17

--- tags: eth2devs description: Notes from the regular proof of stake [Eth2] implementers call image: https://benjaminion.xyz/f/favicon-96x96.png --- # Consensus Implementers’ Call #98 - 2022-11-17 [Quick contemporaneous notes by Ben Edgington; fka "Eth2 Implementers' Call"] Agenda: https://github.com/ethereum/pm/issues/660 Livestream: https://youtu.be/IK1jNCQz5yk ### @metachris mev-boost summary and questions [Summary document](https://hackmd.io/kJQguDvTRXGY4qK0z_j1gA). (Discussion brought forward from later in the agenda.) - Release of MEV-Boost 1.4.0 allows setting minimum bid value - Post coming soon about implications and impact of different values - Replacing types in MEV-Boost with those from Attestant - Helps with changes for Capella and EIP-4844 - Relay news - A [vulnerability](https://hackmd.io/kJQguDvTRXGY4qK0z_j1gA) involving incomplete submission validations could give incorrect timestamps or PREVRANDAO and is now fixed. - Consensus teams, please implement the `getStateRandao` endpoint from the pre-release Beacon API (Teku has it already, Prysm has a pre-release, Lighthouse on unstable). - [Another Relay](https://relayooor.wtf/) is slowly gaining traction. - Builder 0x69 is now the leading builder, ahead of Flashbots. - Open sourced the priority load-balancer. Useful for anyone running the MEV-Boost relay. ## Capella ### Bounded withdrawals sweep See [here](https://github.com/ethereum/consensus-specs/pull/3095). [AlexS] We changed the withdrawals to remove the queue. The spec now says that, in the worst case, we sweep the entire validator set. We may wish to bound this. [Danny] This adds a little complexity for probably small benefit, but I am weakly against. [Lion] Agreed - it feels like it might be needed, but the need for it has not been demonstrated in testing yet. [Danny] It's not a classic DoS vector. [Alex] If the validator set were double the size, would it be an issue to scan the whole thing? [Lion] The risk is having to do a full sweep per block rather than per epoch. [Me] How much extra complexity is involved? [Alex] It's non-trivial if we want to ensure it treats withdrawals fairly. [Danny] "I've kind of changed my mind in this discussion." [Alex] "I was weakly for, but am now weakly against." :joy: Do we care about fairness? If not, then it is very easy. [Danny] Yes, we must advance the pointer if it's bounded else there could be edge cases making validators unwithdrawable. **Action** Alex to keep working on [the PR](https://github.com/ethereum/consensus-specs/pull/3095). ## EIP-4844 ### BlobSideCar mutability issue We previously agreed not to sign the blobs. But that makes them mutable in transit. So, should we sign them or do a full blob verification to avoid this? See [this issue](https://github.com/ethereum/consensus-specs/issues/3103) for discussion and benchmarks A full blob verification looks feasible, [PR here](https://github.com/ethereum/consensus-specs/pull/3108/files). For the signature verification alternative, a flat hash would be much faster than SSZ. Some inconclusive discussion on how blob verification scales... [Proto in chat] Since we need to verify the blobs at some point, this is better - adding signatures adds complexity. Need to investigate the benchmark numbers more. **Decision** We will go ahead with full blob verification for now on the testnets and make sure there is no problem in practice. Implementing this is not a blocker for standing up testnets. ## Research, Spec, Etc. ### @mkalinin's Engine API spec improvement process See [here](https://github.com/ethereum/execution-apis/issues/321). Two main parts: 1. Change to Engine API - add `getCapabilities` method. - Returns the methods supported by the execution client - Allows for flexibility in development 2. Improve specs structure for future work. - Reference table of all methods ever implemented. - Status flags: `final`, `deprecated`, `experimental`... - Layout of spec files for each upgrade - Allow for easier cross-references between versions. [Lightclient] Overloading the use of hardforks makes sense for implementers, but is not a great way to understand the EngineAPI as a whole. This is already a pain point with the consensus specs. [But the [Annotated Spec](https://eth2book.info/latest/annotated-spec/) solves this!] [Mikhail] An advantage of tying the structure to hard forks is that once implemented, the files can be immutable. [Danny] Who is the EngineAPI spec for? Almost entirely for client devs, since it is effectively internal. [LC] A changelist to index into the files would help. [Danny] We have discussed moving to a more functional description like the Beacon APIs, but still using Markdown. [Mikhail] MD is definitely easier to update. [Jacek] The `getCapabilities` API - this kind of thing is not always terribly useful as the info gets stale when the exec client is upgraded. Standardising error codes for deprecated and removed methods may be more useful, and consensus clients can fallback accordingly. [Mikhail] That could also work. Just looks ugly! Except that it multiplies the number of calls, otherwise we cannot detect if the exec client has been upgraded to support new methods. [AndrewA] Strict versioning may be better since data types change at forks. Do we need v2 to be backward compatible to v1? [Jacek] Backwards compatibility is nice in general. Has proved useful around beacon chain upgrades. [Mikhail] Strong view that we should not support more than, say, two forks with one version. Backwards compatibility for one fork would be ok. **Action** Discuss the following on [the issue](https://github.com/ethereum/execution-apis/issues/321): - `getCapabilities` API vs error codes - Structure of documentation. This is not particularly blocking for Shanghai. Comments in the next week for discussion either at ACD next week, or here in two weeks. ## AOB None. * * * # Chat highlights From Chris Hager to Everyone 02:03 PM : don't think it's super important, but i'll have to go at :45, in case there's mev-boost questions. here's the written updates: https://hackmd.io/kJQguDvTRXGY4qK0z_j1gA From Tim Beiko to Everyone 02:04 PM : micDAO From danny to Everyone 02:04 PM : https://github.com/ethereum/pm/issues/660 From Chris Hager to Everyone 02:07 PM : https://hackmd.io/kJQguDvTRXGY4qK0z_j1gA https://collective.flashbots.net/t/post-mortem-for-a-relay-vulnerability-leading-to-proposers-falling-back-to-local-block-production-nov-10-2022/727 https://ethereum.github.io/beacon-APIs/?urls.primaryName=dev#/Beacon/getStateRandao From stokes to Everyone 02:08 PM : Lighthouse has it on unstable Was just looking yesterday From Chris Hager to Everyone 02:10 PM : https://flashbots.github.io/relay-specs/ https://relayooor.wtf/ https://www.relayscan.io/ https://github.com/ethereum/execution-apis/issues/307 From Hsiao-Wei Wang to Everyone 02:12 PM : https://github.com/ethereum/consensus-specs/pull/3095 From danny to Everyone 02:19 PM : it's not just fairness. it's critical From seananderson to Everyone 02:20 PM : Makes sense From Tim Beiko to Everyone 02:20 PM : how does it iterate over the entire set if you don't “move" the pointer? From stokes to Everyone 02:21 PM : The idea is that it would eventually would advance, even just one validator As someone would very likely become withdrawable I want to think more about this point we just discussed about it getting "stuck" From Tim Beiko to Everyone 02:21 PM : ah, got it! From Hsiao-Wei Wang to Everyone 02:22 PM : BlobSidecar mutable in gossip https://github.com/ethereum/consensus-specs/issues/3103 ^^^ PR: https://github.com/ethereum/consensus-specs/pull/3108 From seananderson to Everyone 02:26 PM : +1 From danny to Everyone 02:27 PM : https://github.com/ethereum/consensus-specs/issues/3103 From protolambda to Everyone 02:28 PM : sig verification allows to optimistically propagate at slightly lower cost, but it adds complexity and you would still need to verify the blobs later. So +1 on doing only blob verification if the difference is only a few ms From Mikhail Kalinin to Everyone 02:31 PM : https://github.com/ethereum/execution-apis/issues/321 From lightclient to Everyone 02:38 PM : *curses in CL spec*