tl;dr
- Fusion Progress: Minor spec updates, engineering full steam ahead 🚂
- No progress in customer diversity. Be selfish, manage a minority client!
Merge update
First of all, fantastic work by all the engineering teams on the Kintsugi sprint, which resulted in the launch of the Kintsugi Merge testnet. It’s amazing to see 3 execution clients and 5 consensus clients for a total of 15 different couples operating on a unified front.
Kintsugi🍵the long-running first Merge testnet, was not without enthusiasm. THE #TestTheMerge The effort hammered the testnet with transactions, bad blocks, and a number of other chaotic inputs, causing bugs in state transition, timing, and more. We expect to find such bugs in the first testnets, but with each iteration the clients become more and more stable.
Restarting the oven 🔥🧱
The teams identified an important issue a few weeks ago. It was a discrepancy in the Engine API (how the PoS consensus layer drives the execution layer) semantics related to how execution layer clients actually work in practice. The problem is that in some contexts the consensus layer accidentally induced an unexpected load on the execution layer.
The engineers then realized that if the semantics of the engine API were slightly more flexible, the two layers could work more harmoniously. This led to a subtle, but crucial, change in the Engine API and a related breakup version of the specifications.
Today, the Oven Specifications🔥🧱 has been released and engineers are busy making the changes. At the end of this sprint, teams aim to bring production-ready implementations to a new testnet for public consumption. Keep your eyes peeled for how to participate.
From there, teams will transition public testnets to proof-of-stake before proceeding with mainnet preparations.
Customer Diversity Metrics
Michael Sproul launched a new wave of customer diversity measures using its new fingerprint mechanism. Unfortunately, the distribution of validator node clients has not changed over the last 6 months.
The diversity of consensus layer client implementations allows Ethereum and its users to have unique and robust resilience to software outages and attacks. Users gain some resilience by using a minority client, regardless of network composition, but the network itself gains resilience at a few key validator distribution thresholds.
If only one customer:
- Does not exceed 66.6%, a defect/bug in a single customer cannot be finalized
- Does not exceed 50%, a defect/bug in the choice of a single customer can’t dominate the top of the channel
- Does not exceed 33.3%, a defect/bug in a single customer cannot disrupt the purpose
From the looks of the fingerprint mechanism, Prysm is still above the 66.6% mark.
I want to congratulate the teams, individuals and communities who take customer diversity seriously (exhibit A, exhibit B). Managing a minority customer is not only healthy for the network, but also safer for the individual user’s funds.
Be selfish (rational)! Manage a minority client 🚀
