Unusual times. I trust you are all doing well and continue to look after yourselves, your families, and your communities.
It’s been a while since our last brief update. I apologize for that. I will ensure they come more frequently after this. Eth2 appears to be progressing well — Phase 0 is stable, client teams are excelling, and some encouraging research has been made public concerning our stateless future.
tl;dr
v0.11.0 post-audit release
Spec version v0.11.0 — Lan party — was launched last week. This release signifies a “post-audit” Phase 0 specification, prepared for enduring multi-client testnets.
It includes minimal alterations to the core consensus; instead, much emphasis is placed on fine-tuning the network protocol — e.g. clearer sync protocol, DoS fortification, improved network/chain separation, and more. Refer to the release notes for further information.
Clients are diligently working to integrate these modifications while continuing to enhance stability, optimizations, and multi-client experiments. Indeed, client teams are collaborating until March to establish the groundwork for the upcoming multi-client testnets. Currently — Teku synchronizes with Prysm, Prysm synchronizes with Lighthouse, and most DiscoveryV5 implementations can locate one another.
Launch of Combining GHOST and Casper paper
This week, we launched Combining GHOST and Casper on arXiv. This document formalizes the core consensus components of eth2 — Casper FFG and LMD-GHOST — illustrating how they cooperate to create a safe and live system. This paper extends upon notions initially introduced in the original Casper the Friendly Finality Gadget paper, building them onto a more tangible Proof-of-Stake, slot-based context (i.e. that of the eth2 beacon chain).
This paper was developed concurrently with the Phase 0 specs. Not only did it influence the design of the specifications, but it also brought to light several crucial corner cases that required attention. We are thrilled to make it available to the public for comments, feedback, and critique.
This initiative originated from a “mini-spec” presented by Vitalik, but the majority of the effort was driven and accomplished by Yan X. Zhang and his students at San Jose State University. We extend our special gratitude to Yan and his students — Diego Hernandez, Thor Kamphefner, Khiem Pham, Zhi Qiao, Juhyeok Sin, and Ying Wang — for reaching this important milestone for eth2.
Polynomial commitments hold promise for statelessness
Vitalik recently shared a fascinating ethresearch post, Using polynomial commitments to replace state roots. This post advocates for the adoption of polynomial commitments as an alternative to the conventional merkle-tree accumulator for blockchain state and data. Should this research pathway prove successful, we could reduce “witnesses” (i.e. proofs about the state required to process a block) from ~0.5MB to approximately 1 to 10 kB, addressing one of the core challenges in the Stateless Ethereum research.
To clarify — Ethereum is striving to transition to a more “stateless” framework (see the 1x research and updates. Polynomial commitments could be the significant advancement we’ve been seeking to actualize this statelessness by considerably minimizing the burden of statelessness on block size.
While exceedingly promising, some of this research and complicated mathematics are quite new. We need to dedicate more time to better grasp the intricacies and trade-offs, as well as allow more individuals to examine this novel and thrilling technique.
A touch of IETF BLS instability
The IETF BLS standard recently adopted a last-minute modification into the specification based on external feedback regarding varying applications and domains. The former hash_to_base was not compatible with embedded systems, applications requiring specific types of domain separation, and those utilizing SHA-3 instead of SHA-2.
In response to these issues, hash_to_base was substituted with the refined hash_to_field. Specification maintainers do not foresee any further substantial alterations to the specification, and this adjustment is set to be officially released as a “Draft 6” soon.
When it comes to cryptographic standards, we do not wish to find ourselves in a situation like eth1 with the Keccak256 hash function — that is, one of the few significant applications that utilizes it. Being in a cryptographic island complicates the ease of cross-application interoperability and hampers the development of a diverse array of robust implementations.
We are closely tracking the progress of the IETF standard, but in light of this recent modification, we are not hurrying to deploy the mainnet deposit contract (which would effectively commit us to a BLS specification) until there is a targeted eth2 launch date. We will continuously assess the stability of the IETF standard moving forward and do not anticipate this becoming a constraint for launch.
In other updates, we will soon introduce a deposit interface and implement a deposit contract for the forthcoming long-lasting multi-client testnet, but more on that later 🚀.
