Our biweekly updates written by the entire Prysmatic Labs team on the Ethereum Serenity roadmap.

🆕 Testnet Restart Approaching

https://beaconcha.in has been tracking our testnet since its genesis!

🔹Simple Recap

Our current testnet has been live for an incredible 3 months, marking a significant milestone for our team as we have increased stability of our client and worked closely with block explorers, validators, and the community to make Prysm safer, more reliable, and better documented for folks wanting to interact with eth2 at the cutting-edge. To everyone that participated in this experiment so far, we sincerely thank you, it has been a joy being able to have people trying out our experimental features, improving resource usage of the client, and our documentation significantly.

Starting next week, we are planning on restarting our testnet to match the latest specification for eth2, which includes some important, consensus-breaking improvements. Behind the scenes, the whole team has been working on revamping Prysm to prepare for a testnet restart to spec version v0.11.1. This version is the most important release yet, as it will serve as the multiclient testnet target. That is, clients will interop with each other starting from this upcoming testnet restart. This restart is also the prime release of novel features in our beacon chain that will offer significant reduction in resources used by the nodes, including a critical improvement to network bandwidth usage. Among the changes included are:

Revamped state management:

Instead of saving the beacon state every slot to the database, we only persist states after a certain interval, reducing load significantly when it comes to disk writes and risk reads. Upon reading a historical state, we can replay blocks on top of the closest persisted state and recreate whatever is requested quite efficiently. Users can also configure this feature to write states more often or less often, leading to trade-offs in how slow this feature is vs. how heavy the DB can get. This will be enabled by default in our testnet restart and we believe users will experience a much smoother run with the beacon chain then.

Easier and more efficient slashing detection:

Currently, being able to detect if 1 validator has proposed two blocks with different inner data fields is a daunting task, as we must also know the list of committees at such a slot to figure out who the proposers are. The new spec has instead decided on including the validator block proposer index as a new field in blocks, this way, we can almost instantly detect if someone has committed a slashable block offense with our slasher.

Only subscribing to attestations nodes care about via p2p:

Currently, nodes are bombed with attestation messages from 51000+ validators via p2p every epoch. This has prompted many to ask if the network requirements for eth2 are reasonable and whether there is any work being done to mitigate its weight. The answer is a resounding yes! It turns out, only certain nodes care about all these raw, unaggregated attestations floating around the network for the purposes of aggregating them and packing them into smaller messages. Now, nodes only subscribe to what we call attestation subnets based on their needs. Most nodes, especially nodes with 0 validators attached to them, will see a considerable decrease in bandwidth and memory from this new feature we are thrilled to pilot soon.

Initial sync fully revamped:

Initial chain sync has changed completely since we brought in our new teammate, Victor Farazdagi. Victor has been working for weeks now on ensuring our sync is a smooth experience that is able to intelligently navigate difficult edge cases such as peers going away, long periods without finality, and being able to catch up to the chain head if falling behind for any reason. Previously, our sync model would (a) request for a series of blocks, and then (b) sequentially process them. Victor revamped the system to separate the notion of block downloading and block processing, making the experience feel smooth and uninterrupted.

📝 Merged Code, Pull Requests, and Issues

Beacon State Regeneration Complete

With the completion of new state generator service, a beacon node is now capable of generating an historical state on demand. This is a big feature as a prysm beacon node is now capable to serve awesome data providers such as etherscan historical chain info.

There’s still minor work to route existing RPC calls to the new state generator service but it is not a testnet blocker. These features can gradually roll in as testnet launches. We are super excited to get feedback from the community on what more historical data that daily users and stakers will like to see.

Initial sync batch save blocks

During initial sync, a typical workflow is a syncing node will request a batch of blocks from a serving node with the intention to catch up to head. With the proper response from the serving node, the syncing node will process each individual block in the batch sequentially. As the syncing node processes the blocks and computes the new state, the node will then save the last processed block in the DB sequentially. One of the non negligible bottlenecks is saving objects in the DB, and instead of saving the block sequentially a node could save the blocks in batch. As it turns out, it provided some great performance gain, a node was able to sync 0.8x faster at the worst case. We encourage everyone to try this out as this feature has been rolled out as default.

Proposer Slashing Detection

We are now able to do proposer slashing detection on blocks happening in our chain. Thanks to the latest specification, blocks now contain a ProposerIndex field which we can keep track of in order to figure out if someone committed a slashable offense. Our teammate Shay took charge of this proposer slashing detection feature and it is now available in our slasher codebase. We have already caught a bunch of attester slashing successfully over the last couple of weeks, and are looking forward to policing more evil activity in the network 👿

Fuzz Testing P2P to Detect DoS Vectors

Image credit: embedwise.com

Last update, we mentioned how Prysm is now being fuzz tested under the targets provided by beacon-fuzz by Sigma Prime. We have started experimenting with new potential fuzz testing candidates for randomized input for coverage based testing. Ideally, any external source of input is an ideal candidate for this type of testing. So we started fuzz testing a simple p2p status message and almost immediately found a bug where the test input was a 86 byte message that claimed to have a length of over 9000 petabytes. This clearly crashed the application when it tried to allocate 9000+ petabytes of memory and we learned that Prysm was not enforcing a maximum size of messages. This type of issue was a simple oversight in development but a critical bug of the highest degree. An external user would have been able to crash any prysm node by sending a hello or status message!

Completely New Initial Sync Enabled By Default

The new initial sync is smoother than ever, able to catch tricky edge-cases, and can intelligently deal with common network scenarios such as certain important peers going away and catching up with sync after we have fallen behind. The way it works is thanks to a priority queue that is able to sequence blocks ready for processing and push those that can be processed later down the queue. Using two separate goroutines, one for block downloading and one for block processing those items that are ready from the priority queue. You can read more about the detailed design of the feature, created by our teammate Victor, here.

New, Fast Serialization Enabled by Default

We are now using a lightning fast simple serialize implementation, created by one of our contributors, Ferran, here. His approach was to create a code generator from a set of data structure definitions in Go that uses intelligent approaches to reusing bytes buffers and much fast navigation of structs than any other way we could implement it ourselves in Go. Due to lack of generics in the language, code generation is the next best thing to getting the fastest possible performance for something such as serialization in Go. This is now plugged in by default into Prysm, and we believe it will serve a key purpose in reducing memory/cpu load for nodes serving other peers in the network.

🔜 Upcoming Work

Multiclient Testnet

Both Prysm and other teams such as Lighthouse are on the same boat of needing to restart their testnet to v0.11.1 before focusing fully on multiclient. This will be our full focus after the testnet restart. Most of the initial experiments will involve being able to successfully and comfortably sync to the head of the chain, culminating with being able to successfully have both Prysm validators and Lighthouse validators both producing blocks and attestations for the network. Keep posted here on our medium to track the latest progress after we restart our testnet.

Attestation aggregation optimizations

Currently, aggregating attestations is done in the most naive way possible for the sake of simplicity. However, as the number of validators grows in the network, it quickly becomes a client bottleneck which must be addressed. However, improving this aggregation routine is non-trivial, as it is an NP-hard problem. Our teammate Victor is now looking into incorporating important information to create a heuristic approach towards improving the speed of our aggregation in Prysm. Regarding handling aggregation at the networking layer, there have been some very insightful research pieces posted by the Ethereum research team, such as this one by Hsiao-Wei Wang https://notes.ethereum.org/@hww/aggregation#A-note-on-Ethereum-20-attestation-aggregation-strategies with strategies we are currently using for phase 0.

Prysm External Security Audit

Prysmatic Labs is seeking an external security audit of our Ethereum 2.0 client, Prysm. If you are a security focused team, please review our request for proposal.

Interested in Contributing?

We are always looking for devs interested in helping us out. If you know Go or Solidity and want to contribute to the forefront of research on Ethereum, please drop us a line and we’d be more than happy to help onboard you :).

Check out our contributing guidelines and our open projects on Github. Each task and issue is grouped into the Phase 0 milestone along with a specific project it belongs to.

As always, follow us on Twitter or join our Discord server and let us know what you want to help with.

Official, Prysmatic Labs Ether Donation Address

0x9B984D5a03980D8dc0a24506c968465424c81DbE

Official, Prysmatic Labs ENS Name

prysmatic.eth