[ad_1]
Strange times. I hope you are all well and continue to take care of yourselves, your families, and your communities.
We’re a bit overdue on a quick update. My apologies. I’ll keep them coming at a regular clip after this one. Eth2 is looking good — Phase 0 is stable, client teams are crushing it, and some promising research was published for our stateless future.
tl;dr
v0.11.0 post-audit release
Spec version v0.11.0 — Lan party — was released last week. This release represents a “post-audit” Phase 0 spec, ready for long-standing multi-client testnets.
It contains limited changes to the core consensus, instead with much of the focus on refining the network protocol — e.g. cleaner sync protocol, DoS hardening, better network/chain separation, etc. Checkout the release notes for more details.
Clients are working hard to incorporate these changes while continuing forward with stability, optimizations, and multi-client experimentation. In fact, client teams are working through March to lay the foundation for the coming multi-client testnets. Today — Teku syncs Prysm, Prysm syncs Lighthouse, and most of the DiscoveryV5 implementations can find eachother.
Release of Combining GHOST and Casper paper
This week, we released Combining GHOST and Casper on arXiv. This work formalizes the core consensus components of eth2 — Casper FFG and LMD-GHOST — showing how they work together to form a safe and live system. This paper builds upon concepts initially presented in the original Casper the Friendly Finality Gadget paper, layering them onto a more concrete Proof-of-Stake, slot-based context (i.e. that of the eth2 beacon chain).
This paper was created in parallel to the development of the Phase 0 specs. It not only influenced the spec design but also highlighted some critical corner cases that had to be addressed. We are excited to release it to the world for public consumption, comment, feedback, and critique.
This work spawned from a “mini-spec” presented by Vitalik, but the lion’s share of work was driven and completed by Yan X. Zhang and his students at San Jose State University. We want to offer a special thanks to Yan and his students — Diego Hernandez, Thor Kamphefner, Khiem Pham, Zhi Qiao, Juhyeok Sin, and Ying Wang — for completing this critical milestone for eth2.
Polynomial commitments promising for statelessness
Vitalik recently published an exciting ethresearch post, Using polynomial commitments to replace state roots. This post proposes the utilization of polynomial commitments as a replacement to the traditional merkle-tree accumulator for blockchain state and data. If this research direction proves fruitful, we could reduce “witnesses” (i.e. proofs about the state required to process a block) from ~0.5MB to on the order of 1 to 10 kB, solving one of the core issues in the Stateless Ethereum research.
To state a bit more clearly — Ethereum is pushing hard to move to a more “stateless” model (see the 1x research and updates. Polynomial commitments could be the major breakthrough we’ve been looking for to make this statelessness a reality by significantly reducing the overhead of statelessness on block size.
Although incredibly promising, some of this research and magic math is very new. We need to spend more time better understanding the complexities and tradeoffs, as well as just getting more eyes on this new and exciting technique.
A bit of IETF BLS instability
The IETF BLS standard recently incorporated a last minute change into the spec based upon external feedback concerning different applications and domains. The previous hash_to_base was not friendly to embedded systems, applications requiring certain types of domain separation, and those utilizing SHA-3 instead of SHA-2.
In light of these concerns, hash_to_base was replaced with the new and improved hash_to_field. Spec maintainers do not expect any more substantive changes to the spec, and this change is to be formally released as a “Draft 6” soon.
As far as cryptographic standards go, we do not want to be in the position of eth1 with the Keccak256 hash function — that is, one of the only major applications using it. Being in a cryptographic island hinders the ease of cross-application interoperability as well as stifles the development of a wide set 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 mainnet deposit contract (which would in-effect lock us into a BLS spec) before there is a target eth2 launch date. We will continually evaluate the stability of the IEFT standard going forward and do not expect this to become a bottleneck for launch.
In other news, we will soon release a deposit interface and deploy a deposit contract for the coming long-standing multi-client testnet, but more on that next time 🚀.
[ad_2]
Source link