HackMD
London Retrospective Takeaways
After speaking with the various client teams, here are some of the reccuring thoughts that came up about how London went, how we can improve for the merge, and their priority in the next ~6 months.
Testnet deployment
One issue that was highlighted by most teams was the speed and lack of clear success metrics for the various testnet deployments. Specifically, the time from the various testnets to mainnet felt quick to teams (somewhat forced due to the difficulty bomb), and there was uncertainty about how to react when issues came up. Some suggestions of improvements were:
- Pre-defining criteria on testnets (e.g. N weeks running smoothly) that are required before setting mainnet blocks;
- Pre-defining the default path if an issue is found on a testnet (e.g. M more weeks of running smoothly after a fix is released);
- Having a checklist of required infrastructure for testnet forks (e.g. forkmon, ethstats, a set of transactions, including edge cases, to send to test the upgrade, etc.);
- Have automated alerting in case any issues are found on testnets.
Consensus vs. Non-Consensus changes
Another issue that was highlighted by most client teams (and several infratructure/tooling projects) was that changes were still being done to the JSON RPC API for London close to, or even after, the fork's mainnet activation. Similarly, it was hard for projects to quickly see what changes had actually been implemented outside of the consensus ones (described in EIPs). Some suggestions of improvements were:
- Allocating time, once the consensus changes are finalized, for tooling/infrastructure integration. Some tools noted that having the consensus changes live on a pre-existing testnet is a must have for them to begin working on support;
- Using branches/diffs/versioning on things like execution-APIs to highlight the various changes introduced by a network upgrade.
Roadmap for next ~6 months
Every team mentioned that, in addition to the consensus changes introduced by the merge, they have a lot of work to do on their clients to improve performance, modularize their architecture to support proof of stake, and onboard new developers.
When asked about whether they would like to have a "feature fork" in December (e.g. anything outside of the difficulty bomb pushback and, possibly, some constants adjustments for EIP-1559), all teams except one would rather not have it. 2 teams were explicitly against, one had people for and people against, but still needs to finalize London support, and one was in favor as long as it was done fully separate from the merge.
Given this, it seems reasonable to not have a feature fork in December, and instead point current EIP champions to the first post-merge fork (and likely push new EIPs to the fork beyond that).
