tl;dr

• Finalized: rebranding the blog
• Upgrade your nodes!

Finalized, rebranding the blog

If you’ve read my recent writings or listened to me speak about Ethereum and this grand upgrade that’s in the works, you’ve perhaps noticed that I’m not only shying away from discussing “phases” (instead, referring to a series of independent upgrades), but that I’ve also been attempting to put the terms “eth1” and “eth2” to rest. I’ve spoken about these being terrible terms and wrote about it again in January’s “The State of Eth2”.

What we call “eth2” is a series of major upgrades to Ethereum’s consensus-layer — to ensure the protocol is secure, sustainable, and scalable — while “eth2 clients” are implementations of this proof-of-stake consensus.

And, what we call “eth1” in this context is Ethereum’s rich application-layer, and similarly, “eth1 clients” (after the upgrade to proof-of-stake) are the software that does the heavy lifting in this layer. Ethereum’s application-layer is currently driven by a proof-of-work consensus algorithm but will soon be driven by the beacon chain — the proof-of-stake consensus mechanism that is currently in production and secured by ~3.5M ETH.

Now to follow through on my campaign, I’m rebranding this blog series. From here on out, this series will be known as “Finalized: the Ethereum consensus-layer”, where the name is an homage to the most critical function of the proof-of-stake consensus-layer — finality.

Stakers: Upgrade your nodes

To stay connected, you must be Berlin compatible

The Ethereum PoW chain is undergoing a mainnet upgrade, called Berlin, on April 14, 2021. This is a backwards incompatible fork and thus requires updating your software to continue to follow mainnet. You can read more about this in the EF’s Ethereum Berlin Upgrade Announcement.

As a beacon chain staker, you need an Ethereum PoW endpoint to successfully perform all of your various duties as a validator. This functionality serves as the uni-directional link between the components of the system to allow for new validator deposits.

It follows that, to successfully maintain this link, stakers must upgrade their Ethereum PoW nodes! If you run the Pyrmont testnet, you must upgrade your Goerli nodes before March 17, 2021, and if you validate on mainnet, you must upgrade your mainnet PoW nodes before April 14, 2021.

Also, a good time to upgrade your beacon node

In addition to upgrading your PoW nodes, I highly recommend upgrading your beacon nodes too. There have been many juicy optimizations recently to all mainnet clients. To ensure your validators run with optimal performance (and profitability), pull down the latest release and give it a whirl.

Upgrade your nodes!

tl;dr

Altair pre-release is out

Over the past week, beacon chain Altair pre-release specs — Stargazer v1.1.0-alpha.1 and Half of ’em just look like dots v1.1.0-alpha.2 — were released. These represent the first feature complete releases of the upcoming Altair upgrade to the beacon chain, and give engineering teams something concrete to dig into.

Altair is an upgrade to the beacon chain that brings light client support, minor patches to incentives, per-validator inactivity leak accounting, an increase in slashing severity, and cleanups to validator rewards accounting for simplified state management.

In addition to these various features, Altair also represents a “warm-up upgrade” for the beacon chain and beacon chain clients. Ethereum’s proof-of-stake system has run quite smoothly since genesis, but before performing the high-stakes merge, client teams want to go through the process of a live upgrade to further test and ready their codebases and the live system.

Client teams are currently integrating changes from the pre-release and providing feedback along the way. After this process, we’ll cut a full release and begin the testnet phase.

Open call: Security RfP

Last week, the EF published a beacon chain security+testing RfP. This is an open call for proposals that aim to improve the beacon chain’s security, analysis, and testing. Beyond client engineering, there is plenty to be done to continue to vet, refine, and harden the beacon chain system prior to the merge, and we want to bring in more teams with a wide variety of expertise to dig in.

Check out the RfP’s potential areas of focus for some ideas, but if you are having trouble narrowing down these various domains into a more refined proposal, feel free to email rfp@ethereum.org for some guidance. Provide some background on you or your team’s skillset and experience, along with some basic direction, and we can work together to refine a proposal.

If you know of a team or individual that might be well suited for this RfP, please forward it along!

Merge progress

Merge progress is heating up

What is the merge you ask? It’s the unification of Ethereum’s application-layer (currently supported by proof-of-work) with Ethereum’s proof-of-stake consensus-layer, the beacon chain. Although the beacon chain is already live, it currently only comes to consensus on itself, but after the merge, the beacon chain will be the driver of all the dapps, smart contracts, and accounts that you use today.

Over the past few weeks, merge designs have continued to be refined. Check out Mikhail’s recent spec PR for the latest synthesis of merge plans and structure. We expect these base designs to be integrated into the specs shortly and for engineering teams to begin work on the next wave of demos and testnets.

In addition to our asynchronous research, design, and engineering, we’ve begun a fort-nightly call to increase collaboration across the many teams. You can follow along with progress and participate actively in the Eth R&D discord #merge channel

Steady progress

tl;dr

Altair progress

Altair, the first planned upgrade of the Beacon Chain, continues to make steady progress. Last week, we released Beacon Chain spec v1.1.0-alpha.6 — Protostellar Evolution. While this is an alpha release, barring a security or practical engineering concern, the spec is unlikely to change from here on in.

Client teams are busy as they pass consensus test vectors and stand up short-lived testnets. Teams will make timeline decisions in the next few weeks as Altair code changes stablize and initial multi-client interop is performed.

If you want to learn more about the upgrades coming to the Beacon Chain in Altair, check out Vitalik’s recent release of annotated Altair specs.

Rayonism wrap-up and Merge progress

The Rayonism hackathon wrapped up last week with the Nocturne testnet — a multi-client Merge testnet consisting of 4 consensus-engines and 3 execution-engines for a total of 12 unique client pairs.

Dozens of nodes and thousands of validators built and secured a beacon chain that provided native support for a rich Ethereum application-layer with accounts, contracts, and user transactions.

Huge shoutout to all of the participating client teams and to protolambda and Mikhail for driving the effort

The Rayonism hackathon allowed teams to rapidly prototype core Merge designs and to better understand how this merged system will work in practice. All teams now have a deep familiarity with the structure of the Merge, and a clear visual on how their software will evolve in this coming year.

Client teams are now focused on this summer’s two forks — London and Altair — while researchers are back to Merge spec refinements and testing. After the summer upgrades, teams will shift their focus to the Merge, and begin tackling the production engineering with an eye toward public testnets

tl;dr

Upgrade for London, yes you!

The hotly anticipated upgrade to Ethereum mainnet — London — has a fork block scheduled, and mainnet client releases are out. As mentioned before, to allow for validator deposits, the beacon chain validators come to consensus on the state of the proof-of-work chain and process deposits sequentially from there.

To maintain this link, all mainnet validators must upgrade their proof-of-work nodes (often called the “eth1 endpoint”).

Please see the London announcement for more details.

Warning

Due to an issue uncovered last week on the Ropsten testnet (see restrospective), Go-Ethereum (geth), Nethermind, and Erigon have cut new, critical releases as of late last week. If you upgraded your proof-of-work node prior to these releases, you must upgrade again to remain in consensus after London.

The London fork is expected between August 3-5, 2021. There is no time like the present — upgrade now!

The Merge — checklist and draft EIP

Mikhail, Tim, and I put together a public facing “Merge Mainnet Readiness Checklist”. This documents the various tasks required to get us from here to the Merge, aiding both client team coordination as well as providing a better view into progress for the community. Note that this list is pretty high level, and that it’s meant to serve as an aid. Much of the more nitty gritty organization and communication around each point happens on calls, discord chats, independent repos, etc.

Additionally if you want to get more technical, Mikhail, Vitalik, and I just released a Merge specification for the execution-layer perspective in the form of a draft EIP. This doesn’t contain any major surprises but is a critical step toward the next wave of Merge development!

Altair progress

Altair, the first major upgrade of the Beacon Chain, is making excellent progress after the launch of two small devnets primarily composed of nodes and validators run by client teams. With these first devnets, we moved from alpha to beta releases as the feature-set has been vetted by all teams with all expected refinements now in the spec — v1.1.0-beta.2 Mach’acuay.

This week, we expect to see another devnet launch followed by discussions for picking a date to fork Pyrmont, a long-standing beacon chain testnet. This will bring in many more node operators at much larger scale and set the stage for a final wave of testing and a selection of a mainnet target launch date.

For more background on the what, why, and how of Altair, check out this excellent set of Altair PEEPanEIPs by the Ethereum Cat Herders:

1. #34: Altair – Accounting reform with Alex Stokes
2. #35: Altair Beacon chain upgrade with Vitalik and Danny
3. #38: Altair in Teku with Adrian Sutton

Lastly, prepping the Beacon Chain codebases for their first upgrade has been a fun, yet challenging task. Here’s a huge shoutout for all the excellent work by client teams to get us near this major milestone

Altair is here; the Merge is coming.

tl;dr

Altair upgrade, Oct 27

Altair, the first mainnet upgrade to the Beacon Chain, has been scheduled for epoch 74240 (Oct 27, 2021, 10:56:23am UTC).

A subtle but great advantage of proof-of-stake is that we can precisely time upgrades (Sorry Tim! We’ll be done with proof-of-work soon )

This upgrade brings light-client support to the core consensus, cleans up beacon state incentive accounting, fixes some issues with validator incentives, and steps up the punitive params as per EIP-2982.

Huge shout-out to client teams for their work on this throughout the year

Keep your eyes peeled for another blogpost on Monday, October 4th. This will include all mainnet Altair releases.

And then you can upgrade your nodes!

Merge interop specs and coming devnets

The Merge Interop spec was released on Friday. This “meta-spec” provides stable targets for engineers for an initial wave of testing and devnets.

After a flurry of specification activity over the past few months, Merge specs are near feature complete, and the core logic is stable. In this next phase, engineers will build out the Merge logic and test their software with other teams on short-lived devnets. The engineers will vet the specs as they stand today and provide dynamic feedback into the specs to refine and/or fix issues as they arise.

At the top of the list is to validate and refine the Merge engine API and to prototype and specify various versions of sync under the Merge paradigm.

Proof-of-stake superceding proof-of-work is years in the making, and we’re just as excited as you to see it in action. Much fun coming in October

This issue of Finalized is dedicated to the contextualization of a recently published paper describing three possible attacks on Ethereum’s proof-of-stake algorithm.

tl;dr

These are serious attacks with a formally-analyzed, technically-simple mitigation. A fix will be rolled out prior to the Merge and will not delay Merge timelines.

Forkchoice attacks, mitigations, and timelines

There has recently been quite a bit of chatter around a newly published paper co-authored by a team at Stanford and some EF researchers. This paper made public three liveness and reorg attacks on the beacon chain’s consensus mechanism without providing any mitigations or any contextualization of what this means for Ethereum’s coming Merge upgrade. The paper was released in an effort to better facilitate review and collaboration before introducing fixes on mainnet. It failed however to provide context on impact and mitigations. This left room for uncertainty in ensuing discussions.

Let’s get to the bottom of it.

Yes, these are serious attacks

First of all let us make clear, these are serious issues that, if unmitigated, threaten the stability of the beacon chain. To that end, it is critical that fixes are put in place prior to the beacon chain taking over the security of Ethereum’s execution layer at the point of the Merge.

But with a simple fix

The good news is that two simple fixes to the forkchoice have been proposed — “proposer boosting” and “proposer view synchronization”. Proposer boosting has been formally analyzed by Stanford researchers (write-up to follow shortly), has been spec’d since April, and has even been implemented in at least one client. Proposer view synchronization also looks promising but is earlier in its formal analysis. As of now, researchers expect proposer boosting to land in the specs due to it’s simplicity and maturity in analysis.

At a high level, the attacks from the paper are caused by an over-reliance on the signal from attestations — specifically for a small number of adversarial attestations to tip an honest view in one direction or another. This reliance is for a good reason — attestations almost entirely eliminate ex post block reorgs in the beacon chain — but these attacks demonstrate that this comes at a high cost — ex ante reorgs and other liveness attacks. Intuitively, the solutions mentioned above tune the balance of power between attestations and block proposals rather than living at one end of the extreme or the other.

Caspar did an excellent job succinctly explaining both the attacks and proposed fixes. Check out this twitter thread for the best tl;dr you’ll find.

And what about the Merge?

Ensuring a fix is in place before the Merge is an absolute must. But there is a fix, and it is simple to implement.

This fix targets only the forkchoice and is therefore congruous with the Merge specs as written today. Under normal conditions, the forkchoice is the exact same as it is now, but in the event of attack scenarios the fixed version helps provide chain stability. This means that rolling out a fix does not introduce breaking changes or require a “hard fork”.

Researchers and developers expect that by the end of November, proposer boosting will be integrated formally into the consensus specs, and that it will be live on the Merge testnets by mid-January.

Lastly, I want to give a huge shoutout to Joachim Neu, Nusret Taş, and David Tse — members of the Tse Lab at Stanford — as they have been invaluable in not only identifying, but remedying, the critical issues discussed above

tl;dr

• Merge progress — minor spec updates, engineering full steam ahead
• No progress in client diversity. Be selfish, run a minority client!

Merge update

First of all — fantastic work to all of the engineering teams on the Kintsugi sprint, which culminated in the launch of the Kintsugi Merge testnet. It is incredible to see 3 execution clients and 5 consensus clients for a total of 15 different pairings operating on a unified front.

Kintsugi, the first long-standing Merge testnet, was not without excitement. The #TestingTheMerge effort hammered the testnet with transactions, bad blocks, and a number of other chaotic inputs, bubbling up some bugs in state transition, sync, and more. We expect to find such bugs in early testnets, but with each iteration, clients become more and more stable.

Kiln reboot

Teams identified an important issue a few weeks ago. This was a mismatch in the engine API (how the PoS consensus-layer drives the execution-layer) semantics related to how execution-layer clients actually function in practice. The tl;dr is that, in some contexts, the consensus-layer was accidentally inducing unexpected load on the execution-layer.

Engineers then realized that if the engine API semantics were slightly more flexible, the two layers could work more harmoniously. This led to a subtle, yet critical, modification of the engine API and a related breaking spec release.

Today, the Kiln spec was released, and engineers are busy knocking out 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 making mainnet preparations.

Client diversity metrics

Michael Sproul released a new wave of client diversity metrics using his novel fingerprinting mechanism. Sadly, the client distribution of validating nodes has not budged in the past 6 months.

The diversity of consensus-layer client implementations enables Ethereum and its users to have a unique and robust resilience to software failures and attacks. Users achieve some resiliance by using a minority client regardless of the network makeup, but the network itself gains resiliance at a few key validator distribution thresholds.

If a single client:

• Does not exceed 66.6%, a fault/bug in a single client cannot be finalized
• Does not exceed 50%, a fault/bug in a single client’s forkchoice cannot dominate the head of the chain
• Does not exceed 33.3%, a fault/bug in a single client cannot disrupt finality

From the looks of the fingerprinting mechanism, Prysm still sits above the 66.6% mark.

I want to give a huge shoutout to the teams, individuals, and communities taking client diversity seriously (exhibit A, exhibit B). Running a minority client is not only healthy for the network but is also safer for the individual user’s funds.

Be selfish (rational)! Run a minority client