Strange times. I hope you are all doing well and continuing to take care of yourselves, your families and your communities.
We’re a little late for a quick update. My apologies. I’ll have them come at a regular pace after this one. Eth2 is looking good: phase 0 is stable, customer teams are crushing it, and promising research has been published for our stateless future.
tl;dr
v0.11.0 post-audit version
Specific version v0.11.0 – LAN evening — was released last week. This release represents a “post-audit” Phase 0 specification, ready for long-standing multi-client test networks.
It contains limited changes to the main consensus, but instead focuses on network protocol refinement – for example, a cleaner sync protocol, DoS strengthening, better network/chain separation, etc. release notes for more details.
Customers are working hard to accommodate these changes while continuing stability, optimizations, and multi-customer experimentation. In fact, customer teams are working through March to lay the groundwork for upcoming multi-client test networks. Today Teku syncs Prysm, Prysm syncs Lighthouse and most DiscoveryV5 implementations can be found.
Release of Combine GHOST and Casper paper
This week we published Combine GHOST and Casper on arXiv. This work formalizes the main consensus components of eth2 – Casper FFG and LMD-GHOST – showing how they work together to form a secure and operational system. This article builds on the concepts originally presented in the original Casper the Friendly Purpose Gadget paperby overlaying them on a more concrete, location-based proof of stake context (i.e. that of the eth2 beacon chain).
This document was created alongside the development of the Phase 0 specifications. This not only influenced the design of the specifications, but also highlighted some critical cases that needed to be resolved. We are excited to release it to the world for public consumption, feedback, feedback and reviews.
This work was born from a “mini-spec” presented by Vitalik, but the lion’s share of the work was led and completed by Yan X. Zhang and his students at San Jose State University. We would like to extend a special thanks to Yan and his students – Diego Hernandez, Thor Kamphefner, Khiem Pham, Zhi Qiao, Juhyeok Sin, and Ying Wang – for reaching this critical milestone for eth2.
Promising polynomial commitments for statelessness
Vitalik recently published an exciting article on ethresearch, Use polynomial commitments to replace state roots. This paper proposes the use of polynomial commitments as a replacement for the traditional Merkle-Tree accumulator for blockchain state and data. If this direction of research proves successful, we could reduce the “witnesses” (i.e. evidence about the state required to process a block) from around 0.5 MB to on the order of 1 to 10 KB, thus solving one of the fundamental problems in stateless Ethereum research. .
To put it a little more clearly: Ethereum is working to move to a more “stateless” model (see study 1x). and updates. Polynomial commitments could be the breakthrough we’ve been looking for to make this statelessness a reality by significantly reducing the block size overhead of statelessness.
While incredibly promising, some of this research and magical math is very new. We need to spend more time better understanding the complexities and trade-offs, as well as bringing more attention to this new and exciting technique.
A bit of IETF BLS instability
The IETF BLS standard recently incorporated a last-minute change to the specification based on external comments regarding different applications and domains. The previous hash_to_base was not friendly embedded systems, applications requiring certain types of domain separation, and those using SHA-3 instead of SHA-2.
In the light of these concerns, hash_to_base was replaced by the new and improved hash_to_field. Specification maintainers do not expect any further substantial changes to the specification, and this change will soon be officially released as “Draft 6.”
When it comes to cryptographic standards, we don’t want to be in eth1’s position with the Keccak256 hash function, that is, one of the only major applications that uses it. Being in a crypto island hinders ease of interoperability between applications and stifles the development of a wide range of robust implementations.
We are closely monitoring the development of the IEFT standard, but in light of this recent change, we are not rushing to deploy the deposit contract on mainnet (which would lock us into a BLS specification) before it is released. there is a target eth2 launch date. We will continually evaluate the stability of the IEFT standard in the future and do not expect this to become a bottleneck for launch.
Additionally, we will soon release a repository interface and deploy a repository contract for the next long-running multi-client testnet, but we’ll talk about that next time 🚀.
