{"id":18400,"date":"2026-03-18T02:44:44","date_gmt":"2026-03-18T02:44:44","guid":{"rendered":"https:\/\/cryptoted.net\/index.php\/2026\/03\/18\/eth2-quick-update-no-5\/"},"modified":"2026-03-18T02:44:44","modified_gmt":"2026-03-18T02:44:44","slug":"eth2-quick-update-no-5","status":"publish","type":"post","link":"https:\/\/cryptoted.net\/index.php\/2026\/03\/18\/eth2-quick-update-no-5\/","title":{"rendered":"eth2 quick update no. 5"},"content":{"rendered":"


\n
<\/p>\n

\n

Welcome to this week’s eth2 quick update<\/em>!<\/p>\n

tldr;<\/p>\n

<\/g><\/svg><\/a>Shasper joins Prysmatic’s testnet<\/h2>\n

Parity’s eth2 client, Shasper<\/a>, successfully joined<\/a> Prysmatic’s Sapphire Testnet marking the first public<\/em> multi-client eth2 testnet. This is the exciting start of many<\/em> multi-client testnets to come in the next month.<\/p>\n

You can now pull down the Shasper codebase and with a few commands, and connect to the Sapphire testnet. If you want to give it a shot, follow the instructions here<\/a>.<\/p>\n

<\/g><\/svg><\/a>Eth2 block explorers launch<\/h2>\n

Not one<\/a> but two<\/a> (!) eth2 block explorers recently launched. Both of these block explorers currently monitor Prysmatic Labs’ Sapphire Testnet<\/a>, providing slot-by-slot info as validators build the beacon chain.<\/p>\n

Bitfly launched their beaconcha.in<\/a> block explorer a couple of weeks ago and continue to add exciting features<\/a> by the day. Etherscan just launched their block explorer<\/a> yesterday, and it, too, looks packed with cool features and data. Both will be great options to monitor Prysmatic’s and other testnets as they come online.<\/p>\n

We’re excited to see more and more user\/developer tooling being built around eth2 clients and testnets \ud83d\ude42<\/p>\n

<\/g><\/svg><\/a>First eth2 networking call<\/h2>\n

Up until this point, we’ve relied upon github issues\/pull-requests, adhoc chats, the main eth2 call, and in person meetings to organize the networking components of the eth2 spec. This has largely worked well enough<\/em>, but researching and architecting a network to support a sharded blockchain protocol is an issue that increasingly deserves some more specific attention and resources.<\/p>\n

To this end, we had our first eth2 networking-specific call<\/a> this week. Although this call is not live-streamed like the general eth2 call, it is public and open to all contributors. Thank you to the p2p networking experts across the various eth2 teams that pushed for this call. I was originally resistant due to the additional coordination overhead, but the first call proved very fruitful and I look forward the next.<\/p>\n

As always Ben Edgington (call notes<\/a>) and Mamy Ratsimbazafy (call notes<\/a>) took excellent notes. We still have plenty to dig into, and our next call will be in approximately 2 weeks time.<\/p>\n

Thank you Will Villanueva from the Quilt team for organizing the first eth2 phase2 community call<\/a>. Similar to the new networking and light client calls, phase 2 has enough going on to warrant a regular call to keep the research and development more organized.<\/p>\n

This first call acted as a general update and survey of the various on-going threads across the many teams and individuals involved. You can read up on the notes here<\/a>. Subsequent calls are intended to be deeper work sessions on specific technical issues.<\/p>\n

A major goal for Phase 2 is to get through the initial wave of stateless protocol research and to use the findings to narrow the scope into a more concrete plan to execute in 2020. These calls are an excellent step forward toward this goal.<\/p>\n

<\/g><\/svg><\/a>Forkchoice state fix<\/h2>\n

Researchers at San Jose State University led by Yan X Zhang have been diligently working to formalize the joint properties of eth2’s consensus mechanics (Casper FFG) and fork choice rule (LMD GHOST). Before publishing their work, they found a corner case in the interworkings of FFG+GHOST in which a branch of the block tree might include the latest justified\/finalized blocks but not<\/em> actually show those blocks as justified\/finalized in the on-chain state. To leave such “non-viable” branches in the fork choice can lead to situations in which a validator’s vote might not be coherent with local finality info and might, in certain scenarios, lead to liveness failures. You can read more about this particular scenario and the proposed solution here<\/a>.<\/p>\n

To address this scenario, we have a fix under review<\/a> in the specs repo. We expect this fix to be released within the week.<\/p>\n

<\/g><\/svg><\/a>Specification and implementation of the new BLS standards<\/h2>\n

The long-awaited BLS standards were recently presented for public comment at the IETF Meeting 106<\/a>. You can check out the presentation<\/a> and slides<\/a> for yourself. The presentation went as planned and the standard is expected to be adopted by a number of blockchain projects and (eventually<\/em>) into IETF. To more semi-officially enshrine this standard before the long IETF process finsihes, I expect the EF and many other projects to more officially announce intended usage soon.<\/p>\n

There are two draft pull-requests ([1<\/a>] [2<\/a>]) under review in the specs repo, as well as an implementation of the new standard under review in py_ecc<\/span><\/a>. Once review is complete, we will generate the new BLS test vectors for general consumption by eth2 clients. The intention is to switch testnets over to the modified BLS scheme come January.<\/p>\n

The BLS standards also remove one of the final blockers for launching the eth2 deposit contract. Runtime Verification is currently finishing up their report on the formal verification and analysis of the deposit contract bytecode. This report is expected to be published by the end of the month for public review, after which we can finally<\/em> launch this thing \ud83d\ude80.<\/p>\n<\/div>\n