PoS Implementers’ Call #77 - 2021-12-02

[Quick contemporaneous notes by Ben Edgington; fka "Eth2 Implementers' Call"]

Agenda: https://github.com/ethereum/pm/issues/429
Livestream: https://youtu.be/1fIg_t6hZ8U

Intro

Note: Arrow Glacier hard fork on Eth1 next Wednesday: update your Eth1 nodes!!

Updates to consensus layer specs: v1.1.6 - fork choice fixes are in.

Kintsugi office hours

v3 of the Merge specs just released. Validation errors are more expressive. Minor updates to Eth1 EIPs. Engine API update to alpha.5. Devnet-3 will target these specs.

Marius has been organising mass Merge testing

Merge-devnet-2

Devnet-0 was broken by running two sister blocks with TTD. Half of consensus clients chose one; half the other. We need to be able to handle this, and be able to override the terminal PoW block hash as well on the consensus layer. [Mikhail] The first PoS block proposer should sort this out - the network should not split over this. However, something went wrong… It's still running and is available for a post-mortem.

Devnet-1 had a bug in Geth.

Devnet-2 is running well. Hit TTD and switched to PoS 2 days ago. Making deposits for new validators is fine, and lots of testers are sending Txs. Things looking fine. Teku joined and is proposing as of yesterday. Lighthouse has a majority, other clients allocated 5% each for now. No blocker to making this equal between clients.

Marius got all 5 consensus clients working with Geth to follow the chain.

Teku–Nethermind is not working currently - Nethermind to investigate.

Devnet-3 next week will target v3 specs.

Kintsugi testnet launch targeted for the 14th, and plan is to run it for a longer period of time.

Updates

Nethermind
Devops team is writing some docs on how to run with various consensus clients. Also testing merge MEV plug-in. Fixing interop with Teku and Nimbus.

Lighthouse
Merged Kintsugi into "unstable" branch today; should migrate to "stable" in a couple of weeks.

Discussion

[Mikhail] Proposal to add engine_getBlockBodies bodies to API. This can be used to de-duplicate the blocks between layers - the Eth1 payloads could be stored only on the execution client side, and the consensus client would fetch (and store) them as necessary.

[AdrianS] What would happen if the execution client is offline? [Mikhail] You would be unable to serve blocks to other clients. This might result in being downscored in gossip, but that's likely not your biggest problem at this stage.

[Mikhail] Optimistic sync: what should a validator do while the sync is in progress? Is it allowed to attest while syncing? Probably should not be attesting in this case. See this issue [Alex] Feels like validators should wait until fully synced, otherwise we are in "lazy validator" territory. [Mikhail] If a block is fully verified, it might make sense to attest to it, and it has some value for FFG, but might open other issues: need to analyse how it affects safety and liveness if we allow it.

[Mikhail] transition edge case scenario. Some execution clients might have changed their fork choice to PoS. Should they be switched back? Recommend not. Action please review the issue and add any thoughts. Mikhail plans to close it next week.

[Dustin] has been looking at optimistic sync. Current descriptions mix general properties and specific implementation details. Would like to see a cleaner separation of concerns around: (1) explanatory material, (2) spec requirements, and (3) implementation details.

[Marius] Noticed when switching between consensus clients, they all try to import all the blocks again (leading to re-execution on the execution layer). Optimistic sync should fix this. Please test opt syncing not only from beginning, and also when switching consensus client. [Mikhail] This should all work out fine. [Marius] Could memoise the execution of the block hash to avoid the overhead.

Spec discussion and AOB

[Hsiao-Wei] There has been a fix to the proposer boost score. This will be in the next spec release (not in the recent one).

[Leo] Want to continue to increase the number of standard metrics across clients. Currently eight are well supported. Will continue discussions with client teams.

[Tim] Call next week around MEV in Eth2 - review of FlashBots' proposal.

[Pooja] PEEPanEIP planning to have a call to explain Merge testnet setup, and another with Mikhail on RANDOM opcode EIP during December (sorry, not swift enough to catch the dates).

[Trent] tomorrow is the Merge Community call.

[Hsiao-Wei] Naming! Opened an issue. Consensus on consensus upgrades is star names; uncertain for execution upgrades. Looking for name starting with "B". Please nominate candidates in the issue. Deadline Dec 13th. Can choose top four and put it to a community vote (as we did for Altair). Or we could just decide in the next call. [Tim] suggest separate breakout room to discuss naming things rather than this call. Also can do async.

---

Chat highlights

From stokes to Everyone 02:07 PM

https://hackmd.io/@n0ble/kintsugi-spec

From parithosh to Everyone 02:19 PM

If anyone wants to start validating from genesis in devnet-3, please do let me know

From Mikhail Kalinin to Everyone 02:22 PM

https://github.com/ethereum/execution-apis/issues/137

From Mikhail Kalinin to Everyone 02:30 PM

https://github.com/ethereum/consensus-specs/issues/2735
https://github.com/ethereum/consensus-specs/issues/2636#issuecomment-960647404

From Dustin Brody to Everyone 02:37 PM

https://hackmd.io/Ic7VpkY3SkKGgYLg2p9pMg#Implementation-requirements

From Hsiao-Wei Wang to Everyone 02:44 PM

naming discussion: https://github.com/ethereum/pm/issues/430

From protolambda to Everyone 02:47 PM

@Marius The replay of blocks you are seeing on start-up might just be the last 2 epochs, some CLs don't persist the unfinalized part in their state db, and instead apply the blocks again.

From Hsiao-Wei Wang to Everyone 02:50 PM

https://github.com/ethereum/consensus-specs/pull/2760
^^^^ fork-choice proposer boost score bugfix

From Tim Beiko to Everyone 02:53 PM

https://github.com/ethereum/pm/issues/423

From Trenton Van Epps to Everyone 02:53 PM

tomorrow is the Merge Community call
https://github.com/ethereum/pm/issues/419
1400 UTC, 9 EST

From Mikhail Kalinin to Everyone 03:00 PM

CL-EL = Star-City after the merge makes sense to me, as there could be pure CL and pure EL upgrades. Having different naming conventions to distinguish the two is good