Consensus-layer Call 90

[djrtwo]

Consensus-layer Call 90 Agenda

prev: call 89

Meeting Date/Time: Thursday 2022/6/30 at 14:00 UTC
Meeting Duration 1.5 hours
livestream

1. Merge
2. Other client updates (if any)
3. mev boost
   • adding signature to getHeader
   • anything else?
4. Research, spec, etc
5. Open Discussion/Closing Remarks

[metachris]

I'd like to (briefly) discuss the complexity of adding a signature to the builder-specs getHeader request.

Context: auction - should (header,bid) messages be publicly accessible during the message passing period? mev-boost#112

• With signature, relays could reveal the builder bid only to the proposer, enabling a sealed-bid auction where builders are not aware of each other's bids, leading to bids on the high end. A sealed-bid auction seems strictly superior.
• Without signature, it's an open auction where builders are incentivised to bid low initially, and outbid each other by small amounts. If we try to mitigate this on the relay by allowing only a single bid per builder per slot, then there's a strong first-mover disadvantage.

Questions:

1. What's the amount of work needed?
2. Should we consider adding this now rather than making this breaking change soon after the merge?

After the merge it will require a new API endpoint (version) in the builder-specs (one with and one without signature), and running both endpoints on the relays for some migration period.

[q9f]

I would like to discuss some of the "conveniences" that are baked into the clients (or planned) but should definitely be carefully reviewed now that we move towards merging:

• pulling chain configurations from Github
  • the repositories should merely serve as a reference
  • security implications of pulling specs from a third-party service are hard to gauge
  • (this came up while moving specs to a different repository)
• checkpoint sync from Infura
  • beacon chain should work towards a p2p state sync instead of checkpoint sync
  • instead of providing alternatives to Infura, we should come up with a feasible p2p protocol
  • checkpoint sync is fine as long as it is not the default and users can provide their own checkpoints
  • (this came up during last week's ACD)

I would even argue this should also apply to testnets because if we treat testnets differently from mainnet, we'll eventually face issues on mainnet we are not prepared for,

[djrtwo]

It is requisite to get out of band info to perform sync -- either a checkpoint root or the full checkpoint state. The full checkpoint state is relatively small and bound (e.g. ~50MB) so if a user is already having to get a root out of band, they might as well just get the state and save the p2p complexity (IMO).

To download a state from p2p, a user would still need to provide a root out-of-band. So if state or root, the user needs to get it from some authority (or multiple), some node they trust, or some other source.

That said, just pointing to infura is not the proper end goal and we can and should do better. Some notes on how to do better -- https://notes.ethereum.org/@djrtwo/ws-sync-in-practice

checkpoint sync is fine as long as it is not the default and users can provide their own checkpoints

checkpoint sync (or proving an out of band root at a minimum) is requisite for bootstrapping in a PoS network.

[benjaminion]

Quick notes

[ajsutton]

It's rather frustrating that agenda items get added to these meetings so last minute, and it seems to happen pretty consistently. We need to decide ahead of time who is required on the call and can't because we never know what's going to be discussed.

Of course we can't stop last minute things popping up but could we put out a call for agenda items early and maybe have a cut-off point where if the item wasn't on the agenda then it may still be discussed but won't be decided on except in particularly urgent cases?

[q9f]

Sorry, for some reason I thought the call is today not yesterday. Therefore it was very last minute and I didn't even show up. But maybe something like this can be discussed async elsewhere first?

[timbeiko]

Closed in favour of #566