Reading · Christine D. Kim

Good evening,

Tonight, I’m discussing Ethereum’s post-quantum readiness. Yesterday, developers discussed a proposal to update how randomness is generated so that a cryptographically relevant quantum computer (CRQC) could not predict or manipulate the process.

Regarding the Glamsterdam development, the launch of Devnet-7 revealed several issues and bugs in clients, indicating a high risk of delays to the upgrade timeline I shared last week. Before diving into the main topic of today’s newsletter, I’ll share a quick update on Glamsterdam progress.

A note to subscribers: I’ll be taking a short break from newsletter writing starting next week. I’ll be back August 13 with a fresh new update on all things Ethereum development and governance.

Let’s get into it.

Yours truly,

Christine D. Kim

🌕 To get early access to this week’s ACD After Hours newsletter, make sure you are signed up for a premium subscription:

🌓 Interested in being a featured sponsor of this newsletter? Learn more about sponsorship opportunities available for ACD After Hours:

🌑 I also run a research and advisory firm called Protocol Watch for businesses building on Bitcoin and Ethereum. Learn more about how I can help your business stay ahead of protocol changes:

Protocol Watch

Yesterday, July 23, Ethereum developers gathered for their weekly coordination call, the All Core Developers (ACD) call, and discussed progress on the Glamsterdam and Hegota upgrades.

Developers launched their penultimate developer-focused test network (devnet) last Tuesday, July 14. So far, testing has revealed several issues and bugs in clients that developers are working to fix.

The lack of a stable devnet may cause developers to delay next steps for moving on with testing on Ethereum public testnets.

For now, they have agreed to proceed with the launch of the final Glamsterdam devnet, Devnet-8, sometime in the first week of August. Then, they plan to launch two more testnets: a short-lived public testnet for application developers and a non-finality testnet to see how the protocol behaves under extreme conditions, before moving to upgrade public testnets.

Ethereum Foundation (EF) Developer Operations Engineer Parithosh Jayanthi said the rough target is to start upgrading public testnets by September. He said:

Timeline-wise, we’re still looking at DevNet 8 early August. We would want at least one public-ish DevNet, and a non-finality DevNet, both ideally in August, and that should still allow us to potentially have the first [public testnet upgrade] in September.

On the same call, developers also discussed planning for the upgrade after Glamsterdam called Hegota.

Currently, Hegota is in a planning stage, where developers are proposing different Ethereum Improvement Proposals (EIPs) for consideration in the upgrade. The deadline for Hegota EIP submissions is August 6, after which developers will begin finalizing upgrade scope.

So far, developers have confirmed only one EIP for inclusion in Hegota: EIP-7805, Fork-choice-enforced Inclusion Lists (FOCIL).

On the latest ACD call, they discussed a few other EIPs for Hegota, one of which aimed to improve Ethereum’s post-quantum readiness.

Co-authored by four Ethereum Foundation researchers, Kevaundray Wedderburn, Benedikt Wagner, Tom Wambsgans, and Justin Drake, EIP-8321 seeks to update the part of the Ethereum protocol that generates randomness.

Randomness is used for many functions on Ethereum, but key among these is to randomly select which validators get to propose future blocks and group other validators into committees for other responsibilities such as block attestations.

The way Ethereum generates randomness in a secure and decentralized manner is through a commit-reveal scheme known as Random Decentralized Autonomous Organization (RANDAO). It currently relies on Boneh–Lynn–Shacham (BLS) digital signatures to work. However, this cryptography, such as the elliptic curve digital signature algorithm (ECDSA) used by Ethereum to secure accounts, is considered vulnerable to quantum attacks.

Thus, EIP-8321 proposes a hash-based RANDAO scheme that would remove the need to use BLS signatures to source randomness on-chain. Hash functions like SHA-256 are believed to be secure against quantum computers, so, in short, this proposal swaps out the quantum-vulnerable part of Ethereum’s randomness system for a quantum-resistant one.

In addition to concerns about the overhead that a hash-based RANDAO system would add to validator operations, developers raised concerns about the proposal's maturity.

The proposal does not completely remove validators’ reliance on BLS cryptography. It only addresses its use for RANDAO, and leaves the other ways BLS keys and signatures are still used by validators for their daily operations untouched.

“Potuz,” a Prysm client developer at Offchain Labs, said:

This particular change, changing RANDAO, seems random. … If anyways, we’re gonna keep BLS on the validator keys, the shuffling is still going to be vulnerable. So it doesn’t matter what we do with RANDAO, the validator still can be cracked. So, it seems to me that we’re going to fix RANDAO making it post-quantum resistant, but anyways, the only usage of it is not going to be, safe, so it seems a bit premature.

In response, Wedderburn, one of the authors of the proposal, acknowledged that the EIP does not address all the ways validator operations become unsafe due to their reliance on BLS in the event of a quantum attack; it addresses only one. However, if developers agree that post-quantum readiness should be done iteratively, then the EIP should still be considered as one iterative piece of the broader plan that can be completed in the Hegota upgrade. He said:

I think this is the open question as to whether we should do iterative changes to [post quantum], or if we should try to do it all at once. Yeah, this is a question that it’d be good to get more feedback on it to see how people are thinking about this.

Due to the complexity of Ethereum’s codebase, an iterative strategy is likely the only way that Ethereum can safely prepare for “Q-Day,” the day that cryptographically relevant quantum computers (CRQCs) become a reality, as there are several components of the protocol that currently rely on cryptography that CRQCs could theoretically break.

Knowing this, Matthew Keil, a Lodestar client developer at ChainSafe Systems, recommended alignment first on the broader post-quantum roadmap, which could then inform how developers can best start chipping away at the iterative process of making Ethereum Q-Day ready.

Keil said:

It might make sense to memorialize the strawmap, or whatever the post-quantum vision is from a broader perspective, and that way it can [help] how we kind of finalize and narrow down the iterative components for each iteration. … Do we want to start thinking more broadly about what PQ looks like as a broad perspective, as an ecosystem? And then, using that as an approved, quote-unquote, roadmap, that we can all kind of march to.

Developers agreed to continue discussing EIP-8321 and the broader post-quantum roadmap on Discord.

The discussion on EIP-8321 highlighted a major gap in Ethereum’s post-quantum readiness, and that is the existence of a shared development roadmap to guide decision-making about which code changes should come first.

While developers may have immediate, technically sound measures to prepare for Q-Day, such as EIP-8321, they currently lack consensus on the overarching roadmap to guide decision-making on the relative sequencing and urgency of post-quantum-related EIPs.

Further, while developers may share a high-level development roadmap of Ethereum, the strawmap, it lacks specificity, detail, and sufficient consensus to offer developers the clarity they need to make decisions on the incremental steps needed to prepare for Q-Day.

Thus, until developers align on the broader Q-Day roadmap, they are likely to have difficulty placing and prioritizing narrowly scoped post-quantum changes, such as EIP-8321, in forthcoming upgrades.

All Core Developers Consensus #183 call summary and transcript (Forkcast)
Ethereum Improvement Proposals for consideration in the Hegota upgrade should be submitted as pull requests that update EIP-8081. The deadline for Hegota submissions is August 6. (GitHub)
Galaxy Research estimates reduced odds of 30% for the CLARITY Act, proposed market-structure legislation for regulating cryptocurrencies in the U.S., being signed into law. (Galaxy)
Hester Peirce, Commissioner at the U.S. Securities and Exchange Commission (SEC), publishes a statement warning that decentralized finance vaults and lending strategies may be subject to securities laws and regulations. (SEC)
EthStaker organizes a call on what Ethereum stakers should know about the Glamsterdam upgrade and how they can prepare for it. (YouTube)
Terence Tsao, a Prysm client developer at Offchain Labs, explains the technical details behind how Glamsterdam will change builder selection. (Blog)
Omid Malekan, an adjunct professor at Columbia Business School, argues for why Ethereum’s most valuable, indeed, perhaps only valuable asset, is its decentralization. (X)

🙂 Thank you for reading! What did you think of today’s issue? Please share your feedback by leaving a comment.

Post-Quantum EIPs for Hegota

Comments