Ethereum 2.0 Development Update #39 — Prysmatic Labs
Our biweekly updates written by the entire Prysmatic Labs team on the Ethereum Serenity roadmap.
Testnet Relaunch
Testnet with v0.9
After a few weeks of down time. We have brought back Prysm ETH2 testnet for public to experience staking, and most importantly to help us run validator clients and beacon nodes. This is one important initiative as we already have collected so much valuable feedback on UX, documentation, workflow from the community. What changed in this testnet relaunch?
- Upgrade to v0.9 of the spec
- Minor sync bug fixes
- Node monitoring improvements
- Code health improvements and clean ups
- and more
We are excited as you are for this testnet relaunch! Please give it a try at our participation page! And hop in our public discord with any feedback! ❤
RPC endpoints fully functional
We have been receiving a ton of valuable feedback from the community regarding our public API for eth2, including all sorts of utilities to retrieve information related to validators, votes, blocks, and the chain information itself. In particular, ensuring we give informative error messages when a request is incorrect or data itself is not found is one of the things we worked on standardizing through proper gRPC error codes.
For those unfamiliar, we have been working on a well-documented, robust set of APIs for Ethereum Serenity, which we maintain in our official prysmaticlabs/ethereumapis repo and ensure we have full parity with its schema in our Prysm project. Our RPC library is the popular gRPC toolkit created by Google and used by major companies around the world, which brings us a ton of utilities built-in. Having our APIs specified in protobufs makes for an unambiguous, standard schema that many are familiar with the industry. Instead of reinventing the wheel, our protobuf definitions allow us to easily generate library Go code from the API definition, create documentation for it automatically using the great Swagger project, and more. Our schema also comes with JSON over HTTP baked in by default, making it trivial to support typical REST-API use-cases in our testnet via gRPC.
You can even try our public API for our testnet today at https://api.prylabs.network
Merged Code, Pull Requests, and Issues
Align to spec v0.9.1
The life in eth2 moves fast! We just relaunched v0.9 testnet, and here we are, almost done with v0.9.1 spec update. v0.9.1 is a minor update that consists of removing custody bits, improving upon fork choice and eth1 data voting resiliences. You can track this update in this tracking issue.
New Proposal for eth1 data
Part of the Ethereum 2.0 protocol requires validators to vote on their view of the Ethereum 1 chain for deposit inclusion. This process is called ETH1Data and every beacon block has an ETH1Data vote. Since April, the Prysm testnet has been using a very simple algorithm for generating votes about ETH1. The validator determines the starting time of the current ETH1 voting period, finds the highest ETH1 block produced before that time, then selects the 1024th ancestor as their vote.
When re-reviewing the ETH2.0 validator guidelines, we noticed some additional complexities in the suggested implementation. Given that ETH1Data has been the most reliable part of the Prysm testnet, we brought up ETH1Data for discussion again to understand the rationale behind the additional complexity. Take a look at our written report on HackMD.
Handling ETH1 Node Failures
In our previous testnet run, we had one instance where Prysm beacon nodes all crashed at once due to the Istanbul hardfork on Goerli testnet. It taught us a lot, and the reason was our beacon node was tightly coupled with connected ETH1 nodes. For the past 2 weeks we have been looking at making our ETH1 service more resilient to such failures in the ETH1 chain. This involved the beacon node gracefully handling any disconnections with our connected ETH1 node and consistently attempt to reconnect with it. We had to modify how block proposals were carried out in the event that beacon node disconnected from the ETH1 node. This involved randomizing our eth1data vote in the event of a failure connecting to the ETH1 node. Tracked in this issue.
End to end test trending towards completion
One very important quality of a production level project is to make sure it’s properly tested all steps of the way. Previously in Prysm, the only way we would know if runtime (as in, starting up a beacon chain with validators) has failed is if it reaches the canary testing segment of our production pipeline. Since canary testing is only reached after new work is merged into our master branch, we would be finding out after the work has been merged into master that it broke runtime.
We will soon be integrating end to end testing into our review process to ensure that PRs submitted to Prysm don’t break runtime. This will allow us to find issues before they affect users on testnet and in general prevents bugs that we might normally not find in our previous review process.
Slashing detection
Last week Proto made a breakthrough in slashing surround detection and he hosted a multi client slashing discussion. This week we have begun with an attestation slashing detection initial implementation, the feature was merged into our slashing server. We are getting nice benchmark results on the detection implementation.
While working on the attestation conversion to indexed attestations we did encounter difficulties in the design of orphaned blocks slashing detection. We have found a few options to mitigate this issue and should have the design ready for our next biweekly update.
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
