{"id":7426,"date":"2025-01-17T02:54:56","date_gmt":"2025-01-17T01:54:56","guid":{"rendered":"https:\/\/wsj-crypto.com\/?p=7426"},"modified":"2025-01-17T02:54:56","modified_gmt":"2025-01-17T01:54:56","slug":"ethereum-2-0-update-the-latest-developments-you-need-to-know","status":"publish","type":"post","link":"https:\/\/wsj-crypto.com\/index.php\/2025\/01\/17\/ethereum-2-0-update-the-latest-developments-you-need-to-know\/","title":{"rendered":"Ethereum 2.0 Update: The Latest Developments You Need to Know"},"content":{"rendered":"\n
\n

As always, numerous developments are occurring on the eth2 front. Beyond written communication (take a look at the State of Eth2 article below) and various public summaries, client teams, contributors, and community members\/potential validators have been quite occupied!<\/p>\n

<\/p>\n

Today, we will delve into some noteworthy deposit contract updates, alongside major advances toward the deployment of spec version v0.12.<\/p>\n

<\/p>\n

tl;dr<\/p>\n


\n<\/p>\n

Solidity deposit contract and formal validation<\/h2>\n

<\/p>\n

Today, we are excited to announce a new, more secure iteration of the eth2 deposit contract<\/a> crafted in Solidity! This contract preserves the same public interface (with the addition of an EIP 165<\/a> supportsInterface<\/span> function) thus making it an entirely transparent<\/em> transition for all current client and developer tools. In fact, the Solidity code is mainly a line-by-line conversion of the original Vyper contract designed to facilitate review and formal verification.<\/p>\n

<\/p>\n

In recent months, the eth2 deposit contract was restructured in Solidity by Alex Beregszaszi<\/a>, evaluated by a small group of Solidity professionals, and formally verified<\/a> by Runtime Verification largely employing the K-spec that was originally created for the Vyper edition of the contract.<\/p>\n

<\/p>\n

Although the prior Vyper contract underwent extensive testing, reviews, and formal verification, concerns linger regarding the reliability of the Vyper compiler as it currently stands. During the initial Vyper bytecode verification process, numerous compiler bugs were identified (and resolved). In addition to the formal verification, Suhabe Bugrara<\/a> (ConsenSys R&D) performed a review<\/a> of the Vyper deposit contract and formal verification, which led to several enhancements in the formal specification (ultimately aiding the re-verification process of the Solidity contract). Although the verification was deemed sound, Suhabe could not endorse the bytecode as secure while it relied on the Vyper compiler.<\/p>\n

<\/p>\n

At the same time, ConsenSys Diligence<\/a> and Trail of Bits<\/a> conducted investigative security assessments on the Vyper compiler, uncovering a multitude of additional bugs and raising alarms about underlying issues within the compiler codebase.<\/p>\n

<\/p>\n

Despite these discoveries, Vyper remains a highly promising language.<\/em> The compiler, based on Python, continues to evolve, and several contributors are focused on formalizing the language and exploring alternative compilers.<\/p>\n

<\/p>\n

While we are confident in the formally verified bytecode, the challenges identified in the Vyper compiler fostered a substantial dependency on the bytecode verification process. It is preferable to begin with a compiler that is widely accepted as secure and to verify bytecode from that point onward, rather than starting with a compiler known to have issues and subsequently verifying that none of those aforementioned (or unforeseen) problems manifest in the bytecode.<\/p>\n

<\/p>\n

To eliminate any doubt regarding the safety of this critical<\/em> contract, we recommend utilizing the new Solidity contract for the eth2 mainnet, and we invite Solidity contract and EVM bytecode experts to review the contract<\/a> and corresponding formal verification<\/a>. Any issues uncovered will be eligible for the Eth2 Phase 0 Bounty Program<\/a>.<\/p>\n

<\/p>\n

\n<\/p>\n

A brief note — The new contract has not yet been integrated into the spec repository<\/a>. I will be incorporating the new Solidity contract this week and releasing it as a minor version update shortly. I felt it necessary to announce immediately so the community could have ample time for review.<\/p>\n

<\/p><\/blockquote>\n

<\/p>\n

Altona v0.12 testnet<\/h2>\n

<\/p>\n

Since the launch of spec version v0.12<\/span>, client teams have been diligently updating and testing their codebases in anticipation of public testnets.<\/p>\n

<\/p>\n

I\u2019ve observed numerous enquiries from the community (on Discord, Reddit, etc.) asking why what seemed to be a relatively minor update has required a significant amount of time to finalize. While each client\u2019s codebase and associated challenges vary, teams are approaching v0.12<\/span> very<\/em> earnestly. Even though the update in specification was not excessively burdensome, additional time has been dedicated to enhancing security, optimizing functionality, and generally fortifying the clients ahead of what is intended to be the final significant version of the spec prior to launch.<\/p>\n

<\/p>\n

The moment is nearly upon us for the inaugural public, multi-client testnet of v0.12<\/span> — Altona<\/a>, expected to launch within the next week. This network will commence entirely under the management of the constituent client teams (planned Lighthouse, Nimbus, Prysm, and Teku), Afri, and select EF team members. Following the initial launch, the deposit contract address will be disclosed to permit open, public participation.<\/p>\n

<\/p>\n

Similar to the previous multi-client testnets, Altona is designed more as a devnet<\/em> than a user-centric testnet. To clarify, Altona is primarily for client teams to verify v0.12<\/span> software in a live environment and for eth2 engineers in general to resolve any issues that may surface exclusively in a multi-client context. Nonetheless, we invite you to engage and enhance Altona over time. Following that, the subsequent phase (given the overall success of Altona) is a larger, community-oriented testnet featuring the mainnet configuration of at least 16,384 validators to kick off.<\/p>\n

<\/p>\n

\n<\/p>\n

Oh! and Altona will implement the new Solidity deposit contract mentioned earlier. As I stated, this is a fully transparent modification to eth2 client software since the public interface remains unchanged. Eager to trial it in a production environment nonetheless.<\/p>\n

<\/p><\/blockquote>\n

<\/p>\n

Grant for Sigma Prime’s beacon-fuzz<\/span><\/h2>\n

<\/p>\n

We’re thrilled to announce an ongoing grant for Sigma Prime’s multi-client differential fuzzing initiative — beacon-fuzz<\/span><\/a>. Thus far, this endeavor has already achieved significant success, identifying bugs<\/a> in all<\/em> clients involved in the system.<\/p>\n

<\/p>\n

You can visit the Sigma Prime blog<\/a> to keep updated on progress. Stay alert for the anticipated “fuzzing at home” extension of beacon-fuzz<\/span> to participate and potentially discover a bug on your own machine!<\/p>\n

<\/p>\n

My lengthy eth2 blog article<\/h2>\n

<\/p>\n

If you haven’t had the opportunity to check out my blog article from a few weeks back, it\u2019s not too late! Take a look at The State of Eth2, June 2020<\/em><\/a> to gain a comprehensive overview and insight into the current status of the eth2 project and its relation to Ethereum as a whole \ud83d\ude80<\/p>\n<\/div>\n