As always, a lot continues to happen on the eth2 front. In addition to written updates (see the State of Eth2 article below) and other public summaries, customer teams, contributors, and potential community members/validators have been busy!
Today we’ll cover some important news about deposit contracts and the big steps towards implementing specification version v0.12.
tl;dr
Guarantee contract and formal verification
Today we would like to announce a new, more secure version of the eth2 deposit contract written in Solidity! This contract retains the same public interface (with the addition of a PEI 165 supports interface function) and is therefore entirely transparent change for all existing client and development tools. In fact, the Solidity code is primarily a line-by-line translation of the original Vyper contract for ease of review and formal verification.
Over the past few months, the eth2 deposit contract has been rewritten in Solidity by Alex Beregszaszireviewed 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 security of the Vyper compiler as it is today. During the original Vyper bytecode check, several compiler bugs were found (and fixed). In addition to formal verification, Suhabe Bugrara (R&D ConsenSys) carried out a review of the Vyper repository contract and formal verification, leading to numerous refinements in the formal specification (ultimately helping to facilitate re-verification of the Solidity contract). Although the verification was considered strong, Suhabe could not recommend the bytecode as secure as long as he used the Vyper compiler.
Simultaneously, ConsenSys Diligence And Trail of Pieces conducted investigative reports on the security of the Vyper compiler, finding numerous other bugs and raising concerns about systemic problems with the compiler codebase.
Despite these results, Vyper remains a very promising language. The Python-based compiler continues to be developed and a number of contributors seek to formalize the language and investigate alternative compilers.
Although we have confidence in formally verified bytecode, problems found in the Vyper compiler have created a heavy reliance on bytecode verification. It’s better to start with a compiler that is generally considered safe and verify the bytecode from there, rather than starting with a compiler with known issues and verifying that none of those known (or unknown) issues materialize in the bytecode.
For the avoidance of doubt as to the safety of this critical contract, we recommend using the new Solidity contract for the eth2 mainnet, and we invite Solidity contract and EVM bytecode experts to review the contract and associate formal verification. All problems detected are eligible for Eth2 Phase 0 Bounty Program.
A quick note — The new contract has not yet made its way into the submission of specifications. I will integrate the new Solidity contract this week and will release it in minor version very soon. I wanted to announce this immediately so the community could have ample time to review.
Altona v0.12 testnet
Since the release of the spec version v0.12Customer teams have been working hard to update and test their codebases in preparation for the public testnets.
I’ve seen a lot of questions from the community (on Discord, Reddit, etc.) about why what seemed like a relatively small update took a decent amount of time. Although each client code base and associated challenges are different, teams take v0.12 very seriously. While the spec update wasn’t too heavy, extra time was taken to harden security, optimize features, and generally harden clients before releasing them for what is supposed to be the last semi-major version of the specification before launch. .
The time is almost here for the first public, multi-client testnet of v0.12 — Altona with a launch date expected within the next seven days. This network will start fully controlled by the constituent customer teams (planned Lighthouse, Nimbus, Prysm and Teku), Afri and some members of the EF team. After the initial launch, the address of the deposit contract will be published to allow open and public participation.
Like previous multi-client testnets to date, Altona is more of a Devnet than a testnet focused on the end user. In other words, Altona is primarily intended for client teams to verify the integrity v0.12 software in a production environment and for eth2 engineers as a whole to resolve bugs that might arise only in a multi-client environment. That said, we invite you to join Altona and grow it over time. Then the next step (assuming general success with Altona) is a larger, community-focused testnet with a mainnet setup of a minimum of 16,384 validators to start.
Oh! and Altona will use the new Solidity deposit contract discussed above. As I said, this is a 100% seamless change to the eth2 client software because the public interface is the same. However, I can’t wait to test it in production.
Scholarship for Sigma Prime fuzz-tag
We are excited to announce a continuation grant for Sigma Prime’s multi-client differential fuzzing effort — fuzz-tag. To date, this project has already enjoyed enormous success, finding insects In all clients integrated into the system.
You can consult the Sigma Prime Blog to stay informed of progress. Keep your eyes peeled for the planned expansion of “fuzzing at home” fuzz-tag to get involved and maybe find a bug on your personal machine!
My long eth2 blog post
If you haven’t had a chance to read my blog post from a few weeks ago, it’s not too late! Check The State of Eth2, June 2020 to get a high-level overview and understanding of the current status of the eth2 project and how it fits into Ethereum as a whole 🚀
