{"id":7803,"date":"2025-01-26T21:54:04","date_gmt":"2025-01-26T20:54:04","guid":{"rendered":"https:\/\/wsj-crypto.com\/?p=7803"},"modified":"2025-01-26T21:54:04","modified_gmt":"2025-01-26T20:54:04","slug":"ethereum-2-0-the-latest-developments-explained","status":"publish","type":"post","link":"https:\/\/wsj-crypto.com\/index.php\/2025\/01\/26\/ethereum-2-0-the-latest-developments-explained\/","title":{"rendered":"Ethereum 2.0: The Latest Developments Explained"},"content":{"rendered":"\n
\n

Greetings to this week’s eth2 brief overview<\/em>!<\/p>\n

<\/p>\n

In summary;<\/p>\n


\n<\/p>\n

Shasper integrates into Prysmatic’s testnet<\/h2>\n

<\/p>\n

Parity’s eth2 client, Shasper<\/a>, has successfully joined<\/a> Prysmatic’s Sapphire Testnet, marking the first publicly accessible<\/em> multi-client eth2 testnet. This marks an exhilarating beginning for numerous<\/em> multi-client testnets set to emerge in the coming month.<\/p>\n

<\/p>\n

You can now download the Shasper codebase, and with just a few commands, connect to the Sapphire testnet. If you’re interested in trying it out, follow the guidelines here<\/a>.<\/p>\n

<\/p>\n

Launch of Eth2 block explorers<\/h2>\n

<\/p>\n

Not just one<\/a> but two<\/a> (!) eth2 block explorers were recently introduced. Both of these explorers currently track Prysmatic Labs’ Sapphire Testnet<\/a>, offering slot-by-slot details as validators construct the beacon chain.<\/p>\n

<\/p>\n

Bitfly launched their beaconcha.in<\/a> block explorer a few weeks ago and continuously add exciting features<\/a> daily. Etherscan just debuted their block explorer<\/a> yesterday, and it too appears filled with interesting features and data. Both will serve as excellent choices to oversee Prysmatic’s and other testnets as they come online.<\/p>\n

<\/p>\n

We are thrilled to witness the growing number of user\/developer tools being created around eth2 clients and testnets \ud83d\ude42<\/p>\n

<\/p>\n

Initial eth2 networking call<\/h2>\n

<\/p>\n

Up to this moment, we have depended on GitHub issues\/pull-requests, informal chats, the main eth2 call, and in-person meetings to coordinate the networking elements of the eth2 specification. This has generally been effective sufficiently<\/em>, but evaluating and designing a network to support a sharded blockchain protocol requires increasing specificity and resources.<\/p>\n

<\/p>\n

With this in mind, we conducted our first eth2 networking-specific call<\/a> this week. Although this call was not live-streamed like the general eth2 call, it is public and accessible to all contributors. Thanks to the p2p networking specialists from various eth2 teams who advocated for this call. I was initially hesitant due to the added coordination burden, but the inaugural call turned out to be quite productive, and I am eager for the next.<\/p>\n

<\/p>\n

As per usual, Ben Edgington (call notes<\/a>) and Mamy Ratsimbazafy (call notes<\/a>) took remarkable notes. We still have a lot to explore, and our next call will be in about 2 weeks.<\/p>\n


\n<\/p>\n

A big thank you to Will Villanueva from the Quilt team for coordinating the first eth2 phase2 community call<\/a>. Similar to the new networking and light client calls, Phase 2 has enough activities to necessitate a regular call to maintain research and development organization.<\/p>\n

<\/p>\n

This initial call served as a general update and a survey of the ongoing discussions among various teams and participants. You can read the notes here<\/a>. Upcoming calls aim to be more focused work sessions on specific technical challenges.<\/p>\n

<\/p>\n

A major objective for Phase 2 is to navigate through the initial phase of stateless protocol research and leverage the findings to refine the approach into a more definitive strategy for execution in 2020. These calls represent a significant forward movement toward this aim.<\/p>\n

<\/p>\n

Correction of forkchoice state<\/h2>\n

<\/p>\n

Researchers at San Jose State University, guided by Yan X Zhang, have been tirelessly working to systematize the joint properties of eth2’s consensus mechanics (Casper FFG) and the fork choice rule (LMD GHOST). Prior to publishing their findings, they identified a corner case within the interactions of FFG+GHOST wherein a branch of the block tree could contain the latest justified\/finalized blocks but not<\/em> accurately display those blocks as justified\/finalized in the on-chain state. Allowing such “non-viable” branches in the fork choice could lead to scenarios where a validator’s vote might conflict with local finality information and potentially, in certain cases, trigger liveness failures. More details on this specific situation and the proposed resolution can be found here<\/a>.<\/p>\n

<\/p>\n

To remedy this situation, we have a fix under consideration<\/a> in the specifications repository. We anticipate this fix will be implemented within the week.<\/p>\n

<\/p>\n

Specification and implementation of new BLS standards<\/h2>\n

<\/p>\n

The long-anticipated BLS standards were recently revealed for public commentary at the IETF Meeting 106<\/a>. You can view the presentation<\/a> and slides<\/a> at your convenience. The presentation proceeded as intended, and the standard is projected to be adopted by several blockchain initiatives and (eventually<\/em>) by the IETF. To somewhat officially cement this standard before the lengthy IETF process concludes, I expect the EF and numerous other projects to announce their intended usage soon.<\/p>\n

<\/p>\n

There are two draft pull-requests ([1<\/a>] [2<\/a>]) pending review in the specifications repository, along with an implementation of the new standard being reviewed in py_ecc<\/span><\/a>. Once the review process is finalized, we will generate the new BLS test vectors for general use by eth2 clients. The plan is to transition testnets over to the revised BLS scheme by January.<\/p>\n

<\/p>\n

The BLS standards also eliminate one of the last barriers to launching the eth2 deposit contract. Runtime Verification is currently wrapping up their report on the formal verification and analysis of the deposit contract bytecode. This report is anticipated to be released by the month’s end for public assessment, after which we can finally<\/em> deploy this contract \ud83d\ude80.<\/p>\n<\/div>\n