Progress Continues!
tldr;
Runtime Verification Audit of Deposit Contracts
Runtime Verification recently concluded an audit. Formal Verification of the eth2 deposit contract bytecode. This marks an important milestone on the path to the eth2 Phase 0 mainnet. I ask for community feedback and review of this formal specification. If you find any inaccuracies or gaps in this formal specification, please submit an issue to the eth2 spec repository.
The Formal Semantics are defined in the Mark K document. It identifies and displays the EVMbytecode behaviors, and also demonstrates how they work. These include input validations, iterative Merkle Register tree updates, and other information. Have a look Here for the full K specification, and here Here for a discussion on drilling down and details at a high level.
Thank you to Daejun Park (Runtime Verification) for leading the effort, and to Carl Beekhuizen and Martin Lundfall for their comments and suggestions.
Now is the time to provide feedback and information regarding formal verification, if that is something you can do.
The Word of the Month is “Optimization”
Optimizations were the main focus last month.
Although there is not as much of a difference between 10x and 100x optimizations, they are essential to reach our goals. We must first complete the phase of community development.
Beacon Chain Optimizations are Crucial
(Why we can’t max out our machines with the beacon chain.
The core of eth2, the beacon chain, is vital to the functioning of the rest. To sync shards, a client must synchronize the beacon chain, even if there are many validators (>300k+). This is why optimizations to lower the resource requirements for phase 1, the beacon network, were a key focus of the eth2 clients team’s efforts over the past month.
We are making amazing progress, I am happy to report. Here’s a quick glance so that you get an idea of the work.
Lighthouse Breezes Through 100k Validators
Last week, a 16k validator testnet was shut down due to an attestation gossip loop causing nodes to go offline. Sigma Prime quickly fixed the bug, and team members moved on to bigger and better things. The last two weeks have been spent optimising this testnet so that it can be used at real-world scale.
A Lighthouse Progressive Testnet was created to ensure that thousands of validators can run on small VPSs equipped with 2 CPUS (8GB RAM) or 8GB RAM (8GB). Initial tests with 100k validators indicated that customers used 8GB RAM consistently. After a few days, optimizations were made, lowering this to 2.5GB. There are ideas to reduce it further. 70% of hash state gains were also documented. BLS signature validation is cited as the primary computational bottleneck of eth2 clientele.
A new Lighthouse Testnet Release is imminent. Keep an eye on their Discord for progress.
Prysmatic’s Testnet Works and Timing is Much Improved
The Prysm testnet celebrated its 100,000th slot with more than 28k validators. Today the testnet has passed slot180k, with more than 35k validators. An open testnet is available to generate optimizations, stability patches, and other updates. It’s quite impressive.
Many tangible advances are underway in Prysm. I have spoken with many validators and they all agree that the client is making remarkable progress. One special feature is the improved sync speed. The Prysmatic team was able to optimize the clients’ timing from 0.3 blocks/second up to more than 20 blocks/second. This greatly improves the
–>
Don’t Believe the Hype: Download It Yourself .
Everyone Loves matrix_proto
The Core Eth2 frequently (knowingly) specifies behavior that’s not optimal. Instead, the spec code was written for ease of understanding rather than performance.
An algorithm is a method to achieve a particular behavior. A specification describes the behavior of a system. The same spec may be implemented differently by different algorithms. This is how it works: The eth2 spec allows for multiple implementations of each part. Teams can make tradeoffs (e.g. computational complexity, memory use, implementation complexity).
An example: Fork Choice. The spec used for locating the head of the chain is naive and clearly shows its edges and moving parts. For example, how do you update your weight after receiving a new certificate? What to do after a block has been completed? If the spec were implemented directly, the production requirements for eth2 would not be met. Instead, clients must examine the implications of computation tradeoffs in the context of their trades, then develop a more complex algorithm to address these needs.
Luckily for customers, Protolambda completed the work 12 months ago. There are many fork-choosing algorithms available, each with their own benefits and drawbacks. Recently, Paul (from Sigma Prime) noticed a major bottleneck in Lighthouse’s branch after choosing an algorithm, so he went looking for something else. He found it: matrix_proto. Here’s a list of protos.
Portability was a priority: Once integrated, it could adapt to the most current specs. matrix_proto was also demonstrated to be “orders of magnitude faster and perform significantly fewer database reads.” After initial integration into Lighthouse, other teams quickly adopted it. Prysmatic has the most recent version. The obvious benefits of this algorithm over other options made it a fan favorite and I look forward to seeing other teams do the same!
Ongoing Phase 2 Research: QuilteWASM, TXRX
Phase 2 of Eth2 is an addition to the state execution within the hard universes of the eth2. Although some basic principles can be fairly clearly described (e.g. Inter-shard communication via Cross-Links, Merkle Test Phase 2 Design), the landscape is still open. Quilt (ConsenSys research group) and eWASM have been working on this open space for the past year, and more specs and developer playgrounds are expected this year.
Recently, there has been a lot more activity around this, including discussions and calls as well as postings to ethersear.ch. There are many great resources to help you understand this terrain. Here’s a selection:
In addition, Quilt and eWASM, the new entity, TXRX. ConsenSys members have dedicated a portion of their time to Phase 2 research. The initial focus was on understanding cross-shard transactions and their implications. Then, prototypes of possible ways to integrate eth1 into eth2 were created.
You can find the Phase 2 R&D, which has a relatively recent history, a great opportunity to make an impact and get in-depth. There are many clients currently testing network protocols, so there are lots of tools to create and experiments to run.
Here are some events featuring a strong representation of eth2:
🚀
