As always, a lot continues to happen in the eth2 space. In addition to written updates (check out the Eth2 status post below) and other public summaries, our client team, contributors, and community members/prospective validators have been busy!
Today we’ll cover some important deposit contract news and the big strides we’ve made towards implementing specification version v0.12.
tl;dr
Solidity deposit contract and formal verification
Today we’d like to announce a new, more secure version. eth2 deposit contract Written in Solidity! This agreement maintains the same public interface ( EIP 165 Support interface function) and therefore completely transparent Changes all existing clients and development tools. In reality, 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 in Solidity. Alex BeregzasjiReview by a small group of Solidity experts and officially confirmed With Runtime Verification, we reused much of the K-spec written for the contract in the original Vyper version.
Although previous Vyper contracts have been thoroughly tested, reviewed, and officially verified, there are potential concerns about the safety of the current Vyper compiler. During the original Vyper bytecode verification, several compiler bugs were discovered and fixed. In addition to formal verification Suhabe Buglara (ConsenSys R&D) performed review The formal specifications have been greatly improved with the Vyper deposit contract and formal verification (ultimately facilitating revalidation of Solidity contracts). Although the verification was assessed as sound, Suhabe could not recommend that the bytecode was safe as long as the Vyper compiler was used.
at the same time, ConsenSys Due Diligence and traces of beats We wrote an investigative security report on the Vyper compiler, uncovering more bugs and raising concerns about systemic issues in the compiler codebase.
Despite these discoveries, Vyper is still a very promising language. Python-based compilers continue to be developed, with many contributors formalizing the language and investigating alternative compilers.
While we have confidence in officially verified bytecode, issues discovered in the Vyper compiler have increased our reliance on bytecode verification. It is better to start with a compiler that is generally agreed to be safe and check the bytecode from there, than to start with a compiler that has known problems and check that these known (or unknown) problems do not materialize in the bytecode.
To avoid any doubts about the safety of this critical If you are entering into a contract, we recommend using the new Solidity contract for the eth2 mainnet. We welcome reviews from Solidity contract and EVM bytecode experts. contract and related formal verification. Any problems found Eth2 Phase 0 Bounty Program.
A quick note – the new contract is not yet available. spec store. We are integrating a new Solidity contract this week and will release it as a minor version release soon. We wanted to announce it right away so the community would have enough time to review it.
Altona v0.12 testnet
Since the release of the spec version v0.12The client team has been hard at work updating and testing the codebase in preparation for the public testnet.
I’ve seen many questions in the community (discord, reddit, etc.) about why what seemed like a relatively small update took a significant amount of time to complete. Although each client codebase and associated challenges are different, the team v0.12 very Earnestly. The updates to the spec weren’t all that cumbersome, but they did take extra time to improve security, optimize functionality, and generally harden the client to release what was supposed to be the last semi-major version of the spec before release. .
The time for the first public multi-client testnet is almost here. v0.12 — Altona The expected release date is within the next 7 days. This net will begin to be fully controlled by the constituent client teams (Lighthouse, Nimbus, Prysm and Teku plans), Afri and some EF team members. After initial launch, deposit contract addresses will be made public to enable public participation.
Like previous multi-client testnets to date, Altona devnet Rather than an end-user-centric testnet, Altona is first and foremost about ensuring the client team is intact. v0.12 Have a full team of software and eth2 engineers in your production setup work out bugs that can only occur in a multi-client setup. That said, we welcome you to join Altona and grow over time. The next step (assuming general success for Altona) will then be a larger, community-driven testnet with a mainnet configuration of at least 16,384 validators.
oh! Altona will use the new Solidity deposit contract discussed above. As I said, this is a 100% transparent change to the eth2 client software because the public interface is the same. Nonetheless, I’m excited to test it in production.
Subsidy for Sigma Prime beacon fuzz
We are pleased to announce ongoing grants for Sigma Prime’s multi-client differential fuzzing efforts. beacon fuzz. To date, the project has already been a huge success. bug In ~ every Number of clients onboarded to the system.
you can check Sigma Prime Blog Stay up to date on progress. Keep an eye out for the planned “fuzzing at home” expansion. beacon fuzz Join us and find bugs on your home computer!
My lengthy eth2 blog post
If you haven’t had a chance to read my blog post a few weeks ago, it’s not too late! Please confirm Status of Eth2, June 2020 To get a high-level overview and understanding of where the eth2 project stands today and how it applies to Ethereum as a whole 🚀