eth2 quick update no. 12 | Ethereum News

As always, a lot continues to happen on the eth2 front. In addition to written updates (see the status of the Eth2 post below) and other public summaries, the client team, contributors, and community members/potential-verifiers are busy!

Today, we will cover some important deposit contract news, and the big steps towards the implementation of the specific version v0.12.

tl; Doctor

Solidity Deposit Contract and Formal Verification

Today, we would like to announce a new and more secure version of eth2 deposit contract Written in Solidity! This contract retains the same public interface (with the addition of a EIP 165 supports interface function) and thus is a completely transparent Changes to all existing client and dev tooling. In fact, the Solidity code is primarily a line-by-line translation of the original Vyper contract to aid review and formal verification.

Over the past few months, the eth2 deposit contract has been rewritten by Solidity Alex Beregszaszireviewed by a small group of Solidity experts, and formally verified Reusing the K-Spec originally written for the Viper version of the contract, largely by runtime verification.

Although the previous Vyper contract was heavily tested, reviewed and formally verified, as of today there are lurking concerns about the security of the Vyper compiler. During the original Viper bytecode verification, several compiler bugs were found (and fixed). In addition to formal verification, Suhabe Bugrara (ConsenSys R&D) conducted A review Viper deposit contracts and formal verification, leading to several refinements to the formal specification (ultimately aiding in the ease of re-verification of the Solidity contract). Although the validation was rated as sound, Suhabe could not recommend keeping the bytecode safe as long as it used the Viper compiler.

together, ConsenSys Diligence And trail of bits Investigated security reports on the Viper compiler, finding several more bugs and raising concerns about systemic issues with the compiler codebase.

Despite these findings, Viper is still a very promising language. Development of Python-based compilers continues and many contributors are formalizing the language and investigating alternative compilers.

While believing in formally verified bytecode, the issues found in the Viper compiler led to a heavy reliance on bytecode verification. It is better to start with a compiler that is generally considered safe and from there to verify the bytecode, to start with a compiler with known issues and to verify that none of these are known The (or unknown) problem does not materialize in the bytecode.

To avoid any doubt in the security of this Critical Agreement, we recommend using the new Solidity contract for the eth2 mainnet, and we welcome Solidity Contract and EVM bytecode experts to review. Contract and affiliated formal verification, Any issues found. is eligible for Eth2 Phase 0 Bounty Program,

A quick note — the new contract hasn’t made its way yet specific repo, I’ll be integrating the new solidity contract this week and releasing it as a minor version release very soon. I wanted to announce immediately so that the community would have enough time to review.

Altona v0.12 testnet

Since the release of the spec version v0.12The client team is working hard to update and test their codebase in preparation for the public testnet.

I’ve seen many questions from the community (on discord, reddit, etc.) about why it seems that a relatively small update has taken a long time to complete. Although each client codebase and the associated challenges at hand are different, teams are taking v0.12 very seriously. Although the update to the specification was not too cumbersome, additional time has been taken to strengthen security, optimize functionality, and generally hold them out for the final semi-major version of the spec before launching to customers. has been hardened. ,

The time for the first public, multi-client testnet is almost here v0.12 , Altona With an expected launch date in the next seven days. This net will be controlled entirely by the component client teams (Scheme’s Lighthouse, Nimbus, Prism, and Teku), Afri, and some EF team members. After the initial launch, a deposit contract address will be issued to allow open, public participation.

Like previous multi-client testnets to date, Altona has more than one Devnet Compared to an end-user focused testnet. That is, Altona is first and foremost a sanity check for customer teams. v0.12 To build the software in a production setting and overall for the eth2 engineers to work through any bugs that may have arisen only in a multi-client setting. That said, we welcome you to join us at Altona and grow over time. Then the next step (assuming general success with Altona) is a large, community-focused testnet starting with a mainnet configuration of a minimum of 16,384 validators.

Oh! And Altona will use the new Solidity Deposit contract discussed above. Like I said, this is a 100% transparent change to the eth2 client software as the public interface is the same. Still excited to test it out in production.

Funding for Sigma Prime beacon-fuzz

We are excited to announce continued funding for Sigma Prime’s multi-client differential fuzzing effort – beacon-fuzz, To date, this project has already achieved great success. insects In All Number of clients included in the system.

you can see Sigma Prime Blog To stay up to date on progress. Keep your eyes peeled for the planned “Fuzzing at Home” extension of beacon-fuzz Join in and maybe find a bug on your home machine!

my long eth2 blog post

If you didn’t get a chance to read my blog post from a few weeks ago, it’s not too late! check out Status of Eth2, June 2020 To get a high level overview and understanding of where the eth2 project is today and how it fits into Ethereum as a whole

Leave a Comment