---
tags: newineth2
description: The latest update on Ethereum 2.0 development
image: https://benjaminion.xyz/f/favicon-96x96.png
---

<style>
a {text-decoration: underline;}
a {color: #0000ee;}
a:visited {color: #551a8b;}
.ui-infobar {visibility: hidden; padding-top: 0;}
.community-button {visibility: hidden;}
.markdown-body {padding-top: 0;}
</style>

# What's New in Eth2 - 24 September 2021

 Ben Edgington (Eth2 at [ConsenSys](https://consensys.net/) — all views expressed are my own)

Edition 78 at [eth2.news](https://eth2.news/)

## Top picks

The [staking onboarding survey](https://docs.google.com/forms/d/e/1FAIpQLScxNDWegcIIL9ogSL5yhRZgl3_fQclDnMic5wVSRyLfXeohEw/viewform) is quick to complete. Please take a look if you are running your own validators (on your own hardware or in the cloud): we want to hear about your experience of getting up and running.

## The Beacon Chain

Lodestar has not only [joined](https://twitter.com/gregthegreek/status/1420079211998547968) the mainnet party, but is [killing it](https://twitter.com/dapplion/status/1438882897260425217) :tada:

### Altair

On this week's [devs call](#Implementers) we gave the Altair upgrade the green light for deployment. As a reminder, Altair introduces sync committees and some accounting changes, but is not The Merge.

Protolambda, king of the visuals, did some [fantastic work](https://twitter.com/protolambda/status/1440799521047412739) to clear the way to the green light. The last remaining blocker was that sync committee participation on the testnets was low (down around 70%), and we didn't understand why. Proto's analysis revealed a bunch of issues that were easily fixed, the most significant being that Nimbus's sync committee participation was not working at all. This turned out to be for a pretty [funny reason](https://hackmd.io/@benjaminion/rJ8ddAY7t#Sync-committee-performance).

So, we've set a date of Wednesday, 27th of October for the upgrade/fork. And we're [settling on](https://github.com/ethereum/consensus-specs/pull/2625/files) epoch 74240, which will be 10:56:23 UTC on the 27th. We toyed with the palindromic 74247, but the earlier epoch is preferred for technical reasons (it's a boundary for batching historical state roots).

Client teams will be making mainnet releases for Altair by the end of September, and there will be some blog posts and publicity from the 4th of October. Please plan to update your client during the first weeks of October.

In other news, the excellent Pintail has done a [very nice analysis](https://pintail.xyz/posts/modelling-the-impact-of-altair/) of how validator incomes can be expected to change after the Altair fork. The main takeaways are that penalties for attesting late will be much more severe, and there will be a wider variance in rewards earned, even for perfectly performing validators. The latter is due to randomly-assigned duties -- block proposals and sync committees -- making up a larger proportion of rewards than they do now.

### The Merge

Most Merge updates were discussed on the [All Core Devs](#All-Core-Devs) call.

The cat is [out of the bag](https://hackmd.io/@benjaminion/rJ8ddAY7t#Spec-discussion-and-AOB) that a bunch of Eth1 and Eth2 teams will be meeting up in early October to get some Merge devnets running. It's round 2 of the [interop event](https://twitter.com/benjaminion_xyz/status/1435706236612272129) we did two years ago.

## Staking

Client diversity is once again topic of the week. The latest outbreak was prompted by an [ingenious analysis](https://twitter.com/sproulM_/status/1440512518242197516) by Michael Sproul of Sigma Prime.

<p style="text-align:center">
<a href="https://benjaminion.xyz/images/210924_sproul_diversity.jpg"><img width="540" height="334" alt="A list of missing blocks." src="https://benjaminion.xyz/images/210924_sproul_diversity.jpg"></a><br>
<i>Validator distribution by block fingerprinting. By <a href="https://twitter.com/sproulM_/status/1440512518242197516">Michael Sproul</a>.</i>
</p>

Previously there were only two known ways to assess the distribution of the network among client types.

First is graffiti analysis, which allows you to count the number of blocks produced by each client type. This gives you the distribution of validators, and therefore stake, between clients. However, most stakers (~70%) change their graffiti from the default, so the error-bars are enormous, and the results hugely unreliable.

Second is crawling the network to try to connect to beacon nodes. As part of the handshake, beacon nodes report their client type, so you can assess the distribution. There are several issues with this, some of which we [previously discussed](https://hackmd.io/@benjaminion/wnie2_210730#Analytics). But even if we could get an accurate picture of the node distribution, that doesn't necessarily tell us the validator/stake distribution, as each node can host between zero and thousands of validators. We see this in Miga Labs' [crawler dashboard](http://migalabs.es/crawler/dashboard) which overstates Prysm's proportion of the network in most locations, perhaps because Prysm nodes tend to host fewer validators due to having more solo-stakers, and understates Teku, which is more often used by staking services. (Note that Miga [reckon](https://twitter.com/miga_labs/status/1440638113508851712) that their Singapore based crawler gives pretty similar results to Sproul's. Would like to see percentages on the Miga charts!)

[Sproul's analysis](https://twitter.com/sproulM_/status/1440512518242197516) uses a completely new technique, which is to "fingerprint" blocks. Clients include up to 128 attestations when they construct a block. The ordering of these attestations is arbitrary and has no impact on the protocol. It turns out that different clients tend to use characteristic orderings, and with some analysis you can tell with some confidence which client created which block. This is brilliant, and gives us our first ever somewhat accurate insight into the distribution of stake across clients. There are limitations: for example, Teku and Nimbus blocks can look similar, so it's not always possible to distinguish them. However, this analysis is so useful that I anticipate client teams actually agreeing to encode different behaviours in their clients to make the results robust.

### Follow-up

Sproul's results confirm that Prysm continues to dominate, with almost two-thirds of the validators. This sparked some lively discussion. That number is down since the April [block production incident](https://hackmd.io/@benjaminion/wnie2_210424#The-Beacon-Chain) revealed that over 70% of the validators were Prysm, but only fractionally.

The concern is that two-thirds of the validators is a very scary number to have on a single client. If there were an incident that took Prysm onto a different fork (it's happened on testnets), it is hard to see how the beacon chain network could reasonably recover without _massive losses for people staking with Prysm_. Adrian Sutton explains why in [What Happens If Beacon Chain Consensus Fails?](https://www.symphonious.net/2021/09/23/what-happens-if-beacon-chain-consensus-fails/). Also discussed on [Reddit](https://www.reddit.com/r/ethstaker/comments/ptm04i/the_financial_incentive_to_run_a_minority_client/).

The level of heat around this issue is rising: a [thread](https://twitter.com/dankrad/status/1440788036594192386) with great points from Dankrad; Superphiz is [building a campaign](https://twitter.com/superphiz/status/1441223393831895041) to promote greater client diversity; Jonny Rhea comes with [the memes](https://twitter.com/JonnyRhea/status/1441214498128338950); Evan Van Ness says [scary things](https://twitter.com/evan_van_ness/status/1441144615101366273). [^fn1]

[^fn1]: As I've said to Evan, if I were not PM of one of the minority clients I would be a lot more energetically engaged in this discussion. But I fear that it appears self-serving to be too vigorously promoting client diversity myself. Nonetheless: use a minority client, people! It doesn't have to be mine :wink:

If you want to do your bit as a solo staker, here's how to switch from Prysm to [Teku or Nimbus](https://old.reddit.com/r/ethstaker/comments/pu30fa/short_guide_to_migrate_from_prysm_to_teku_or/). Note my [additional comments](https://old.reddit.com/r/ethstaker/comments/pu30fa/short_guide_to_migrate_from_prysm_to_teku_or/he0bu82/). Nimbus also has a [migration guide](https://nimbus.guide/migration.html).

If you are staking with a service, then badger them about this and don't let up until they have either diversified their client usage, migrated to a minority client, or at a very minimum stopped adding new validators on the majority client.

You _will not lose out_ by using a minority client! I'll reveal that, in [this analysis](https://consensys.net/blog/codefi/the-state-of-staking-in-august-2021/), Client C is actually Nimbus. Teku has consistently been the best performer on the network since genesis, and Nimbus is not far behind. In fact, the current majority client turns out to be earning the lowest rewards :man-shrugging:

## The Great Explainers

Reminder that the much-anticipated Rocket Pool mainnet launch happens on the 6th of October. Here's LogicBeach with a one minute [video explainer](https://www.youtube.com/watch?v=Kax5sqF2SKo) on the launch. While we're on Rocket Pool, the good folk at Beaconcha.in have added [Rocket Pool reporting](https://twitter.com/etherchain_org/status/1441385524854497282) with a [dashboard](https://prater.beaconcha.in/pools/rocketpool) and [validator info](https://prater.beaconcha.in/validator/230425#rocketpool).

Not your usual [explainer](https://alinush.github.io//2021/06/17/Feist-Khovratovich-technique-for-computing-KZG-proofs-fast.html): "Feist-Khovratovich technique for computing KZG proofs fast" by Alin Tomescu. This unpacks (a little) the [paper](https://github.com/khovratovich/Kate/blob/master/Kate_amortized.pdf) by Dankrad Feist and Dmitry Khovratovich on doing super-fast polynomial commitments. I mention it here as this technique is what makes the planned data availability sampling scheme for shard chains practical. You can see [my implementation](https://github.com/benjaminion/c-kzg) in C, which is based on [Proto's implementation](https://github.com/protolambda/go-kzg) in Go, which is based on [Dankrad's implementation](https://github.com/ethereum/research/tree/master/kzg_data_availability) in Python. Anton Nashatyrev is doing some work to [integrate this](https://github.com/Nashatyrev/artemis/tree/rayonism/das) into Teku as an Eth2 sharding prototype.

## Media and stuff

Sina Habibian has a [new podcast](https://bytecode.substack.com/). In [Episode 2](https://share.transistor.fm/s/5071af0e) Danny Ryan and Tim Beiko "go deep on the future of the Ethereum protocol". I haven't had a chance to listen yet, but I have every reason to expect that it will be brilliant.

## Research

On Ethresear.ch:
- A discussion of the [Security of BLS batch verification](https://ethresear.ch/t/security-of-bls-batch-verification/10748?u=benjaminion) with practical implementation hints.
- An analysis of what Ethereum's stated goal of "[minimum viable issuance](https://ethresear.ch/t/circulating-supply-equilibrium-for-ethereum-and-minimum-viable-issuance-under-proof-of-stake/10636?u=benjaminion)" looks like under proof of stake, with some interesting observations.

## Regular Calls

### Implementers

Call #73 took place on the 23rd of September.

* [Agenda](https://github.com/ethereum/eth2.0-pm/issues/237)
* [Video](https://youtu.be/Pes_OaMJeDc?t=156)
* My [quick notes](https://hackmd.io/@benjaminion/rJ8ddAY7t).

Includes planning for Altair, the regular client team updates, discussion of APIs for The Merge, and some talk about client diversity metrics.

### All Core Devs

Ethereum ACD call 122 was on the 17th of September. Tim Beiko [took notes](https://twitter.com/TimBeiko/status/1438916709000253440), and here's the [agenda](https://github.com/ethereum/pm/issues/384).

Among other things, there were some Merge-related discussions.
- It was [agreed](https://twitter.com/TimBeiko/status/1438917654815772680) that message ordering on the consensus layer would be synchronous initially, possibly moving towards async in future.
- It was [more or less agreed](https://twitter.com/TimBeiko/status/1438918166483066880) that the terminal total difficulty of the PoW chain would be [hard coded](https://github.com/ethereum/consensus-specs/pull/2605). This reduces complexity and [increases safety](https://github.com/ethereum/consensus-specs/issues/2603), but comes with tradeoffs that were discussed on the call and [summarised](https://twitter.com/TimBeiko/status/1438919213347860486) in the notes.
- [Raising](https://twitter.com/TimBeiko/status/1438922138862309377) of an issue around [transaction type representation](https://github.com/ethereum/consensus-specs/issues/2608) that's too subtle for me to understand.
- Client team Merge implementation progress [updates](https://twitter.com/TimBeiko/status/1438922452923416579).

### Stakehouse

StakeHouse is focused on building tools that lower the technical bar to staking and promote the health of the beacon chain.

Community Call 7 was on the 15th of September. There's a summary [thread](https://twitter.com/StakeHouseCMTY/status/1438272435732758533), and call [video](https://www.youtube.com/watch?v=AZ6kocnouCw&t=391s).

On the call, there was a nice [demo](https://youtu.be/AZ6kocnouCw?t=917) of [Stereum](https://stereum.net/ethereum-node-setup/), a free graphical environment for setting up and monitoring staking nodes. They have a version of fast-sync enabled for all clients.

Also a [demo](https://youtu.be/AZ6kocnouCw?t=1484) of [Wagyu Keygen](https://github.com/stake-house/wagyu-key-gen), a graphical tool for generating keys and registering deposits for staking. The first version of Wagyu Keygen [has been launched](https://twitter.com/wagyutools/status/1440381746688643089), with testnet support. They are looking for [feedback](https://twitter.com/StakeHouseCMTY/status/1438272442703794179) from testers - there is a POAP.

As ever, StakeHouse maintains project [updates](https://github.com/stake-house/stakehouse/wiki/Updates-from-the-Teams) and a project [ideas list](https://github.com/stake-house/stakehouse/wiki/Project-Ideas-List).

## In other news

If you are a [BrightID](https://www.brightid.org/) user there is an ongoing ["fairdrop"](https://fairdrop.brightid.org/) of their [`$BRIGHT`](https://www.coingecko.com/en/coins/bright-token) token. For example, if you previously set up BrightID for GitCoin verification you may be eligible to claim some tokenz. In addition (hence mentioning it here) holders of some Eth2 beacon chain genesis staking POAPs are also [eligible](https://brightid.gitbook.io/brightid/bright/getting-bright/fairdrop/eligibility#participated-in-ethereum-communities) to claim some `$BRIGHT`. TBH, I found the whole process a bit fiddly, but eventually managed to claim a small chunk. Ymmv.

* * *

[![[Twitter]](https://benjaminion.xyz/newineth2/img/twitter.svg =40x40)](https://twitter.com/benjaminion_xyz) Follow me on [Twitter](https://twitter.com/benjaminion_xyz) to hear when the next edition is out 🙌.

[![[RSS]](https://benjaminion.xyz/newineth2/img/rss.svg =32x32)](https://benjaminion.xyz/newineth2/rss_feed.xml) We also have an [RSS feed](https://benjaminion.xyz/newineth2/rss_feed.xml).

[Advertising](https://hackmd.io/@benjaminion/eth2_news/https%3A%2F%2Fhackmd.io%2F%40benjaminion%2Fadvertising) on this newsletter.

[Give Feedback](https://docs.google.com/forms/d/e/1FAIpQLSfkESc4CmNfRGHHjWfNeF3ceLwrXDvynetda4sKfJFJ71Oabw/viewform).