There is always a lot happening on the Ethereum 2.0 front. Aside from writing updates (see also the State of Eth2 post below), and other public summaries, customer teams, contributors, community members, and validators are all trying their best.

In this article, we will be discussing some important news regarding deposit contracts and the steps that are being taken towards implementing specification Version v0.12.

tl. dr

Solidity Deposit Contract and Formal Verification

Today, we are pleased to announce the release of a more secure version of the Ethereum 2.0 deposit contract written in Solidity! This contract maintains the same public interface, with the addition of a FOOT 165 SupportInterface function, and is therefore a transparent change for all clients and development tools. In fact, Solidity’s code is primarily a line to line translation of an original Vyper Contract to assist in formal review and verification.

Over the past few months, the Ethereum 2.0 deposit contract has been rewritten by Alex Beregszaszi and reviewed by a small group of Solidity experts. It has also been formally verified by Runtime Verification and largely reuses the K specification that was originally written for this purpose. The Vyper version of the contract was also reviewed and formal verification of the repository’s contract led to many refinements to the formal specification, which ultimately helped to facilitate reverification of the Solidity contract.

Despite the formal verification of the bytecode, issues found within the Vyper compiler resulted in Suhabe not being able to recommend the bytecode as safe as long as the Vyper compiler is used. Simultaneously, ConsenSys due diligence and Bit Trail investigative security reports were conducted on the Vyper compiler, finding more bugs and raising concerns about the compiler’s codebase.

Despite these results, Vyper is still a promising language. The python compiler-based compiler is still being developed, and contributors are interested in formalizing the language and looking into alternative compilers.

We believe the safest way to go is to start with a widely-accepted-as-safe compiler and test the bytecode using it, rather than using a compiler with known problems and verify that there are no known or unknown issues in the bytecode. Therefore, we recommend using our new Solidity contract for the Ethereum 2.0 mainnet, and we welcome Solidity EVM bytecode and contract experts to review the contract and formal verification. Any problem solved qualifies for the Ethereum 2.0 phase zero bounty.

Quick note: The new contract has not yet been signed into the spec repository. I will be integrating it into the repository as a minor release this week, but wanted to make it public immediately so there is plenty of time for review.

Altona Testnet v0.12

Since the release of specification version v0.12, customer teams have been busy testing and updating their codebases in preparation for public testnets. There have been a lot of questions from the community about what seemed to be a minor update taking quite some time. Each customer’s codebase is unique and so are the challenges, but teams are working together to solve them.

The first multi-client public testnet is nearing completion for version v0.12 — Altona, with a release date expected in the next seven working days. This network will begin fully controlled and managed by the client teams (Lighthouse, Nimbus, Prysm, and Teku), with several members of the EF team. After the initial launch, the address for the deposit contract will be made