[Quick contemporaneous notes by Ben Edgington; fka "Eth2 Implementers' Call"]
Agenda: https://github.com/ethereum/pm/issues/458
Livestream: https://youtu.be/Bi2qZ2epaPM
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, PR-162, optimistic sync spec tiny change.
Marius has some test vectors 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 and feed back to Paul
Paul H volunteered to update the optimistic sync API doc to the latest spec.
[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 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.
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 (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.
[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!]
[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.
[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.
[Paul] Question: what's the status of proposer boost?