Ether 2.0 developers: PoS merger plan may be implemented early next year at the latest

What developers say about when Ether will switch from PoW to PoS

Ether 2.0 developers: PoS merger plan may be implemented early next year at the latest

Note: The original article was written by Ben Edgington, a ConsenSys researcher and Ether 2.0 developer, who expects the Ether 1.0 and 2.0 merger phase to be completed by the end of 2021 or early 2022, and that means the Ether system will switch from a proof-of-work (PoW) consensus mechanism to proof-of-stake (PoS).

Beacon Chain
There are currently over 132,000 active verifiers, pledged Ether is at 4.2 million ETH (worth nearly $16 billion as of today), and the rate of new deposits has increased recently.

Since the small shakeout two weeks ago, things have been going well. Here is Prysmatic Labs’ detailed review report of the event.

Unfortunately, after two full months of running without any forfeitures, three isolated incidents occurred last month for which I have no information as to the cause.

For this I was indeed pleased: to see Adrian Sutton syncing Teku from scratch in about a minute. although you can use any beacon node known to be syncing, or you can use a file already downloaded containing that state, the demo was downloading the initial state directly from Infura. This is a game changer for staking services and individual pledgers. When synchronizing beacon nodes is so fast (seconds instead of hours), you can basically forget about maintaining persistent storage and redundancy settings.

If you want to check how well your validator is performing its validation duties, then take a look at Paul Hauner’s spreadsheet tool and instructions. He provides more insight than the single “valid” number provided by

Do you know about the Secret Sharing Validator? If not, now is a good time to catch up. Alon Muroch has authored the recent SSV Phase 1 test round.

Rayonism, also known as a style of Russian abstract art, is an ongoing effort that is being developed in parallel with the Eth1/Eth2 merged test network and slice and dice development efforts. It emerged at the EthGlobal Ether Scaling Hackathon, though it will certainly expand to a broader scope.

Lukasz Rozmej of the Nethermind team produced a very good video tutorial showing how to use Nethermind to build a merged test net for Eth1/execution side and for Eth2/consensus side Teku.

The big news is that the first developer test net, Steklo, survived for just a few hours on Friday, April 30.

Steklo means “glass” in Russian, which means it will be fragile, and it did prove to be so. To be fair, all teams dove into the network without preparing any test vectors, so this was the first blind attempt. Decrypt wrote an article about Steklo with a total of twelve client combinations: Nethermind, Besu, and Geth/Catalyst paired with Teku, Nimbus, Lighthouse, and Prysm, respectively.

Lukasz provided a summary of the Rayonism Discord channel.

Lighthouse had consensus issues and had a fork from the beginning (root of state issue), but all execution engines worked well on this fork.

Prysm had a problem (general or consensus problem, not identified) and got stuck in the genesis founding phase.

Besu or Teku sometimes did not agree with other clients, but eventually they reached consensus. When splitting, splitting into sets (Teku-Geth, Teku-Nethermind) and (Teku-Besu, Nimbus-Geth, Nimbus-Besu, Nimbus-Nethermind)

The Nimbus-Nethermind conversation may have had some issues at the transport layer on the Nimbus side, but it required more investigation by the Nimbus and Nethermind teams and eventually it worked most of the time – some rebooting may have been required.

In short, a lot happened, and a lot went well, and overall the whole exercise was very encouraging. After some fixes, Lighthouse has since come to terms with Teku as well as Nimbus.

Some common test vectors were prepared last week so that clients could be debugged separately before coming together again. The plan is to build a longer-lived merged developer network early next week.

Altair is a relatively small beacon chain update scheduled for a mid-year release.

According to a recent developer conference call, the major client teams are progressing quite well in implementing the Altair specification. We have taken this opportunity to draft a planning schedule (without commitment).

The Altair specification will be frozen around May 21.

Go live with a short-lived joint test network in early June (no testing of fork conversions, only Altair specs)

Try to fork the current test net by the end of June. I think Pyrmont will be the first one, so better migrate to Prater as soon as possible to avoid instability.

Deploy to the beacon chain by late July/early August.

There are still a few things to work out before freezing the specs. In particular, how to deal with this issue (losing an epoch reward during the upgrade).

Currently, most of the merging activity is focused on Rayonism.

Nevertheless, there is still a lot of work to be done after Rayonism, and Mikhail Kalinin summarizes the open topics in the Discord channel post on Rayonism.

First, there is the transition process (aka docking). We need to figure it out, write code in the test/dev network and try it out. Second, the synchronization algorithm; design work is already underway, then implementation and testing. Block proposal optimization techniques, communication channel protocols, either JSON-RPC or REST; JSON-RPC modifications by the user (add finalization of block methods). Write specific EIP describing the implementation layer modifications. solve BLOCKHASH randomness problem. Multiple rounds of various tests. Chain tools to find evidence of their usefulness. Infrastructure updates, with the main question being what the block browser will look like.
We have a lot of things to do, but a highly optimistic view for the merger to be completed by the end of the year, a more cautious view is in Q1 2022, but no one would expect it to be later than that.

My former colleague Mostafa Farghaly released Kotal.

Kotal is a blockchain deployer that makes it super easy to deploy highly available, self-managing, self-healing blockchain infrastructure (network, nodes, storage clusters ……) on any cloud.

It includes support for Teku, Nimbus, Lighthouse and Prysm nodes, as well as IPFS and other Web 3 support.

Posted by:CoinYuppie,Reprinted with attribution to:
Coinyuppie is an open information publishing platform, all information provided is not related to the views and positions of coinyuppie, and does not constitute any investment and financial advice. Users are expected to carefully screen and prevent risks.

Like (0)
Donate Buy me a coffee Buy me a coffee
Previous 2021-05-12 17:32
Next 2021-05-12 17:36

Related articles