eth2 quick update no. 12

As always, a lot continues to happen on the eth2 front. Aside from written updates (check out the State of Eth2 post below) and other public summaries, client teams, contributors, and community members/prospective-validators have been busy!

Today, we’ll cover some significant deposit contract news, and big steps toward implementation of spec version v0.12.

tl;dr

Solidity deposit contract and formal verification

Today, we’d like to announce a new and more secure version of the eth2 deposit contract written in Solidity! This contract retains the same public interface (with the addition of an EIP 165 supportsInterface function) and thus is an entirely transparent change for 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 in review and formal verification.

Over the past few months, the eth2 deposit contract was re-written in Solidity by Alex Beregszaszi, reviewed by a small group of Solidity experts, and formally verified by Runtime Verification largely reusing the K-spec originally written for the Vyper version of the contract.

Although the previous Vyper contract was heavily tested, reviewed, and formally verified there are latent concerns about the safety of the Vyper compiler as it stands today. During the original Vyper bytecode verification, multiple compiler bugs were found (and fixed). In addition to the formal verification, Suhabe Bugrara (ConsenSys R&D) conducted a review of the Vyper deposit contract and formal verification, leading to many refinements in the formal specification (ultimately aiding in the ease of re-verification of the Solidity contract). Although the verification was assessed as sound, Suhabe could not recommend the bytecode as secure as long as it used the Vyper compiler.

Simultaneously, ConsenSys Diligence and Trail of Bits did investigative security reports on the Vyper compiler, finding many more bugs and raising concerns about systemic issues with the compiler codebase.

Despite these findings, Vyper is still a very promising language. The python based compiler continues to be developed and a number of contributors are looking into formalizing the language and investigating alternative compilers.

While confident in the formally verified bytecode, the issues found in the Vyper compiler created a heavy reliance on the bytecode verification. It is better to start with a compiler generally agreed upon as safe and to verify bytecode from there, rather than to start with a compiler with known issues and to verify that none of these known (or unknown) issues materialize in the bytecode.

To avoid any shred of doubt in the safety of this critical contract, we recommend using the new Solidity contract for eth2 mainnet, and we welcome Solidity contract and EVM bytecode experts to review the contract and associated formal verification. Any issues found qualify for the Eth2 Phase 0 Bounty Program.

A quick note — The new contract has not yet made its way into the spec repo. I’ll be integrating the new Solidity contract in this week and release it as a minor version release very soon. I wanted to announce immediately so the community can have plenty of time to review.

Altona v0.12 testnet

Ever since the release of spec version v0.12, client teams have been hard at work updating and testing their codebases in preparation for public testnets.

I’ve seen many questions from the community (on discord, reddit, etc) as to why what seemed like a relatively small update has taken a decent amount of time to complete. Although each client codebase and the associated challenges at hand are different, teams are taking v0.12 very seriously. While the update in spec was not too cumbersome, extra time has been taken to tighten up security, optimize functionality, and generally harden the clients before putting them out for what is intended to be the last semi-major version of the spec prior to launch.

The time is almost here for the first public, multi-client testnet of v0.12 — Altona with an expected launch date in the next seven days. This net will start entirely controlled by the constituent client teams (planned Lighthouse, Nimbus, Prysm, and Teku), Afri, and some EF team members. After initial launch, the deposit contract address will be released to allow for open, public participation.

Like the previous multi-client testnets to date, Altona is more of a devnet than an end-user focused testnet. That is, Altona is first and foremost for client teams to sanity check v0.12 software in a production setting and for eth2 engineers as a whole to work through any bugs that might only arise in a multi-client setting. That said, we welcome you to join and grow Altona over time. Then the next step (assuming general success with Altona) is a larger, community focused testnet with the mainnet configuration of a minimum of 16,384 validators to start.

Oh! and Altona will be using the new Solidity deposit contract discussed above. Like I said, this is a 100% transparent change to eth2 client software because the public interface is the same. Excited to test it in production nonetheless.

Grant for Sigma Prime’s beacon-fuzz

We’re excited to announce a continuation grant for Sigma Prime’s multi-client differential fuzzing effort — beacon-fuzz. To date, this project has already been huge success, finding bugs in all of the clients onboarded into the system.

You can check out the Sigma Prime blog to stay up to date on progress. Keep your eyes open for the planned “fuzzing at home” extension of beacon-fuzz to get involved and maybe find a bug on your home machine!

My long-winded eth2 blog post

If you haven’t had a chance to read my blog post from a couple of weeks ago, it’s not too late! Check out The State of Eth2, June 2020 to get a high level overview and understanding of where the eth2 project stands today and how it fits into Ethereum as a whole 🚀