HackMD
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. (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 involving incomplete submission validations could give incorrect timestamps or PREVRANDAO and is now fixed.
- Consensus teams, please implement the
getStateRandaoendpoint from the pre-release Beacon API (Teku has it already, Prysm has a pre-release, Lighthouse on unstable). - Another Relay 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.
[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."
- The image file may be corrupted
- The server hosting the image is unavailable
- The image path is incorrect
- The image format is not supported
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.
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 for discussion and benchmarks
A full blob verification looks feasible, PR here. 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.
Two main parts:
- Change to Engine API - add
getCapabilitiesmethod.- Returns the methods supported by the execution client
- Allows for flexibility in development
- Improve specs structure for future work.
- Reference table of all methods ever implemented.
- Status flags:
final,deprecated,experimental…
- Status flags:
- Layout of spec files for each upgrade
- Allow for easier cross-references between versions.
- Reference table of all methods ever implemented.
[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 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:
getCapabilitiesAPI 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
