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

🆕 New Testnet Updates

Stability and validators balances growing!

Our testnet has become significantly resilient — major network bugs have been squashed, nodes are using less resources, and most importantly, validators are making money.

Despite these improvements, we aren’t complacent at all! There is a long way to go to get rid of bottlenecks, user experience improvements, documentation, build requirements, and more. Memory requirements have drastically reduced, and most of the nodes we run internally hover around the 2Gb mark. Over the coming 2 weeks we’ll be including some massive changes that will revamp how we handle the eth2 beacon state and serialization of our data structures. Expect more orders of magnitude in terms of improvements to running a beacon node very soon.

Consistent progress for the Bitfly block explorer

As usual, the Bitfly team has been killing it with the new features added to their block explorer, https://beaconcha.in, adding in a much requested validator monitoring dashboard, where you can plug in as many validators as you want and track their total and relative performance, proposal history, and more. Additionally, you can now see if your validator went offline and the team is now working on opt-in notifications to let you know if your validator has been away for a long time and is being penalized.

📝 Merged Code, Pull Requests, and Issues

Slasher service functional, first testnet slashing coming soon!

If you’ve kept up with our progress, you’ll know we’ve been working hard on the Hash Slinging Slasher to help detect slashings the moment they occur in the network. We’re proud to announce it is now functional! By recording a validators vote history, and all broadcasted attestations, the slasher is able to determine when a slashable act from any validator had been committed. After it finds the conflicting vote, it creates a slashing object and sends it to the beacon chain, to be put into a block.

We’ve confirmed it to work on local testnets, now we need to get it working in mainnet conditions which will definitely stress it differently. We’re hoping to get a slashing on the public testnet soon!

Cross-compilation functional for Prysm

Thanks to SuburbanDad, Prysm finally has the appropriate tooling in place to build cross compilation for the most common architectures. Why is this a big deal? The golang compiler has built-in cross compilation, but this only works for go code. Given the growing complexity of Prysm and it’s dependencies, we needed to cross compile c++ code, in addition to go code. This issue has been in progress for many months until gitcoin increased the bounty to $1000. Thanks gitcoin and thanks SuburbanDad! Users can expect to see compiled binaries uploaded to regular version releases for Prysm as we continue to improve our QA and continuous integration pipelines. Good news for anyone on Windows or linux ARM64 (like raspberry pi!) that wants to use binary executables without the overhead of running a docker container.

Separating block fetching from block processing in sync

Work has been started on improving the initial synchronization, with the immediate focus on refactoring and better utilization of resources by moving to a more concurrent model. At the moment, block fetching and processing is done sequentially, where fetching and processing occur one after another, in a blocking mode. By decoupling those operations, we will be able to download and process blocks at the same time (concurrently), allowing us a more smooth experience during the initial synchronization.

In case you want to follow the progress, the relevant GitHub issue is #4815. We’ve already implemented the fetching part (#4978), and are currently working on completing the queue/processing part.

🔜 Upcoming work

New serialization library for Prysm: hundreds of times better in speed and 8000 times better in terms of memory usage

Mind = Blown

It is no mystery Golang sucks for generic things such as serialization. That is, if we see some data structure, can we serialize it according to some rules, regardless of the data it contains and what it looks like?

Our current approach is to use our own serialization library called https://github.com/prysmaticlabs/go-ssz for every marshal/unmarshal use case in Prysm. Every time we save a block to the database, save the state, or retrieve the state, we have to use this slow library. A better approach is to instead create a code generator, which when given a set of data structures, outputs code which can marshal/unmarshal the data. Generated code is a great alternative to having generics in Go, and can lead to some of the fastest code you can imagine for a certain use case. We put out a bounty a while back for contributors to create custom marshal/unmarshal functions by hand for our data structures, but one of our contributors simply took the opportunity to write a generator that will work for anything as long as its valid under the serialization rules for eth2.

This new library is currently being wrapped up before we integrate it into Prysm, but the benchmarks for marshaling a mainnet, full beacon block speak for themselves:

We see 8700x improvement in memory and almost 250x better in pure speed. We are really thrilled to use this new code in Prysm, and we believe it will improve the experience of syncing with the testnet significantly. We’ll keep everyone posted as soon as this is included in our master branch.

Latest spec version, v0.10.1 complete, pending testnet restart and ready to work hard on multiclient

Currently we have been running the v0.9.4 version of the spec in our Sapphire Testnet. Along with that there has been a parallel effort to update the repo to the v0.10.1 version of the spec over here. The shift to v0.10.x signifies some major changes with how we sign objects with their respective domains. Also it aligns the spec with the current ietf draft. With this update now completed we can now proceed with our testnet restart and multi-client efforts. Given that the majority of the clients are targeting the v0.10.x version of the spec, this is a good base to start of our interop work with other clients. With the spec now stable and no major changes planned in the future, all client teams can work off a stable base for multi-client.

Miscellaneous

2 project built on Prysm at ETHLondon to help eth2 stakers

Our community is always very keen to find ways of improving how validators function in Prysm, either via improvements to block explorers, enhanced logging/UX for Prysm nodes, or more. At ETHLondon, 2 teams created projects built on Prysm’s tools. The first one is a slashing monitor in eth2 called StakeMon created by Ken Chan: “Staking Monitor monitors the beacon chain for validator pubkeys that have committed double signing (slashable), or are offline. Validators can input their pubkeys into the Staking Monitor interface and get notified immediately via Telegram if their validator pubkey was at risk.”

The other project was a validator coordination and protector which helps prevent slashable offenses, created by Julian Koh here. Julian built a middleware that does the following: “Many node operators run 2 or more instances of a validator. This is for redundancy — if 1 goes offline, the other can still validate blocks and earn rewards. However, this greatly increases the risk of slashing, since the protocol does not allow a validator to publish two different blocks at the same height.

We have built a validator coordinator which, for every block height, picks ONE validator to sign the block, even if the operator is running multiple instances of it. Before signing a block, each validator will ask the coordinator if it is safe to sign or not. If the coordinator has seen a validator already try to sign this same block, it will tell this current validator that it is UNSAFE to sign.”

All of this stuff is super cool and will play a role in aiding people running validators in production with real money at stake. We’ll be looking into further elaborating on these projects as we improve the user experience of running a Prysm node.

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