PoS Implementers’ Call #80 - 2022-01-27

--- tags: eth2devs description: Notes from the regular proof of stake [Eth2] implementers call image: https://benjaminion.xyz/f/favicon-96x96.png --- # PoS Implementers’ Call #80 - 2022-01-27 [Quick contemporaneous notes by Ben Edgington; fka "Eth2 Implementers' Call"] Agenda: https://github.com/ethereum/pm/issues/458 Livestream: https://youtu.be/Bi2qZ2epaPM ## Kintsugi office hours ### Release: engine semantics and auth Release pending, based on Discord discussion 2 weeks ago around semantics of the Engine API. It is a breaking change (but should no be a surprise): [PR-165](https://github.com/ethereum/execution-apis/pull/165), [PR-162](https://github.com/ethereum/execution-apis/issues/162), optimistic sync spec tiny change. Marius has some [test vectors](https://notes.ethereum.org/rmVErCfCRPKGqGkUe89-Kg) ready to go. [Paul H] Optimistic sync: API needs some thought. We need to figure out whether to serve optimistic blocks over the API. Options: (1) never do this; (2) return data and mark it as optimistic. [Mikhail] Do we need to serve optimistic blocks to validator clients to allow them to get duties? [Paul] Could be useful to know the head. [Mikhail] We could supply the minimal optimistic info required to get lookahead. Also info for debugging. Any other reason we need optimistic information? [Danny] Need to make sure that end users do not make bad decisions based on optimistic data. Easier to ensure if we don't serve it. But it would be weird not to have the data available at all (e.g. for debugging). **Action: review [document](https://hackmd.io/iLMSTklNQIGoSnOUoAbdcg) and feed back to Paul** Paul H volunteered to update the optimistic sync API doc to the latest spec. ### Testing updates [Pari] Made a shadow fork of Goerli. The copy of Goerli has been Merged, and all Goerli transactions are replayed on it. This is a good test. What else could we test? **Action: review testing [document](https://notes.ethereum.org/@ExXcnR0-SJGthjz1dwkA1A/S1a3jle0K) and comment** Note that this process is now fairly easy to do on Goerli. We should exercise the Merge weekly. Have we considered doing it for mainnet? Not yet - it's much harder to figure out when the transition will happen (due to hash rate variability). Also takes a day to sync. We don't need a full deposit contract - can just start with Genesis validators pre-populated. ### Next steps Is it beneficial having a non-finalising Merge testnet? Found a few bugs in Kintsugi during non-finality. Also useful for testing tooling. [Danny] Worth postponing until after clients have incorporated the latest spec changes. Would be good to have a chain with exceptional scenarios. Wen Kintsugi successor? Need to get clients updated asap, and after that start new testnet. Two weeks, max three from now. Is Pyrmont still in use? Prysm is doing some performance testing; Lighthouse is exiting; Teku is out; Nimbus is running [a long-range attack](https://ethresear.ch/t/insecura-my-consensus-for-the-pyrmont-network/11833) (Insecura). [Tim] Future of testnets. Want to keep one open testnet (for new validators); one somewhat permissioned. There are some plans around current testnets. Prater/Goerli is a good model. Need to decide what backbone of reliable, long-term validators is ideal for future testnets. [Adrian S] Teams could run a number of validators on the open testnet, and turn them off periodically to create some stress and allow for hardening of tooling etc. Could add some malicious nodes (chaos monkeys) that create many forks. So, at least two testnets would be useful: one stable, one unstable. Can have a PoA testnet with an ERC20 version of the deposit contract. ## Merge Planning [Tim] Difficulty bomb on Eth1 is "looming". Starts to be evident in June; 30s blocks by mid July (becoming unusable). If we are not going to push back the bomb again, we should Merge in 1st-half of June. Working backwards: client releases with final spec by early March for testnet. Then pick TTD for mainnet. Then final client releases. Kintsugi v2 by mid-Feb is in line with this. [Mikhail] This schedule is tight. If something, maybe small, crops up that delays us by a couple of weeks then we end up "between two fires". [Tim] There's enough slack for one, maybe two minor issues, but not three. [Vitalik] How long between Merge fork and terminal block? [Tim] People need to get used to running two clients. Longer notice on consensus side, shorter on Eth1 side is ok (2 weeks?). Will become hard to estimate TTD vs. time beyond that. [Vitalik] The Eth1 Merge fork itself is an opportunity to reset the bomb, which gives some wiggle room. [More timing discussion follows, but not well-ordered enough for me to capture. But no direct answer to "Wen Merge" - apologies to [@Superphiz](https://twitter.com/superphiz/status/1486713240113467411)!] [Adrian S] Concern that there remains a lot of engineering work to do, especially around optimistic sync, and a lot of testing. Is the difficulty bomb dictating terms too much? [Danny] Favours pushing for an aggressive timetable, but having a fallback. ## Other topics [Saulius] Does everyone agree that the polling approach to the Engine API is best (e.g. insert new payload)? Seems that having a blocking call may sometimes be useful for swift operations. [Mikhail] Two cases: (1) a payload from the canonical chain, must return "syncing" if it does not have the parent; (2) a payload not from the canonical chain, response depends on the EL client. It's up to the cient implementation as to whether this call is synchronous or aysnc. These updates are coming in the new spec. [Technical discussion ensues...] [Saulius] The latest updates do not solve the bouncing attack (re-orgs), right? [Danny] If a fork choice bounce could be done at a sufficient depth it could cause performance problems for execution clients (and could be done today by a mining cartel). [Marius] Geth can handle reorg up to 90k blocks, but up to 128 blocks is instant. Maybe a coupld of seconds for 200 block reorg. ## Other client updates [Paul] Question: what's the status of proposer boost? - Prysm has finished and just merged implementation yesterday. Need to cut a release before trying on Prater. - Lighthouse and Teku are currently running it on Prater; would be good to see it on more nodes soon. - Lodestar has merged it but is not running nodes with it yet. * * * # Chat highlights From danny to Everyone 02:02 PM : https://github.com/ethereum/pm/issues/458 From danny to Everyone 02:09 PM : https://hackmd.io/iLMSTklNQIGoSnOUoAbdcg From pari to Everyone 02:12 PM : https://notes.ethereum.org/@ExXcnR0-SJGthjz1dwkA1A/S1a3jle0K From Tim Beiko to Everyone 02:19 PM : Could be cool to have Kintsugi v2 for EthDenver actually! From pari to Everyone 02:19 PM : It starts from 11th feb right? From danny to Everyone 02:19 PM : 11th to 20th or so From Tim Beiko to Everyone 02:20 PM : Yes, the “main event” seems to start on Feb 17th From pari to Everyone 02:21 PM : Cool, that’d be the target date then 🙂 Naming suggestions welcome, the current one to beat is Kintsugi v2 From Mamy to Everyone 02:21 PM : See post on insecura here: https://ethresear.ch/t/insecura-my-consensus-for-the-pyrmont-network/11833 From Marius to Everyone 02:22 PM : Test vectors for new Spec: https://notes.ethereum.org/rmVErCfCRPKGqGkUe89-Kg From Marek Moraczyński to Everyone 02:22 PM : Kintsugi v2 = new semantics + auth? From danny to Everyone 02:22 PM : yes From danny to Everyone 03:01 PM : optimistic sync spec https://github.com/ethereum/consensus-specs/blob/dev/sync/optimistic.md From pari to Everyone 03:11 PM : If you guys want, I can deploy it on Kintsugi nodes. So we can test proposer boosting on a network with it properly deployed.