Eth 2.0 Dev Update #57 — “Getting ready for Spadina”
Testnet Updates and Hard Fork Capabilities
Spadina testnet release, genesis event rehearsal:
Spadina testnet has been set to genesis on September 29 at 12pm UTC. (Genesis time: 1601380800) This is a dress rehearsal Testnet for the community to practice sending deposits and launching beacon nodes and validator clients starting from genesis. We all know practice makes perfect, so this will help us become familiar with the process as depositing and genesis are the more difficult and risky parts. This is a small scale testnet with 1024 validators to genesis where the main net spec requires 16384 validators to launch. The Testnet is meant to be short lived (~3 days) and after whoever wants to maintain can continuously maintain it.
Some useful links:
- Launchpad, useful to send Spadina deposits: https://spadina.launchpad.ethereum.org/
- Beacon chain explorer, this is useful to monitor testnet health: https://spadina.beaconcha.in/
- Reddit /r/ethstaker community will be hosting a launch viewing party: https://www.reddit.com/r/ethstaker/comments/iy3c6t/announcing_the_spadina_testnet_launch_viewing/. There WILL be a POAP for viewing the live stream of this call.
Oh! and there’s still time to send your deposits, so don’t miss out on the fun!
Weak subjectivity spec and implementation
Weak subjectivity check is necessary to defend against a problem known as a long range attack. Similar to a genesis block that is finalized and irreversible by definition, a weak subjectivity checkpoint serves the same purpose. A beacon node which uses the weak subjectivity checkpoint will have to ensure that checkpoint is always part of the canonical chain. If a node sees a block conflicting with a weak subjectivity checkpoint, the node will immediately reject the block and exit itself out of the running process.
There has been great analysis done by Aditya Asgaonkar on how long a safe weak subjectivity period should be. For detailed analysis I recommend reading his post. The official eth2 spec repo has a new section on weak subjectivity which will be implemented by the client teams.
In Prysm, we have started our implementation in the following PR. Node operators will be able to try out adding weak subjectivity checkpoint via command line soon. For more background on weak subjectivity, I recommend the following post written by Vitalik
Upgrades & hard forks in ETH2
Ethereum 2.0 is a phased rollout starting with Phase 0. Each phase requires a critical system upgrade, sometimes referred to as a “hard fork”, in which all participants in the system will switch to a different set of rules or parameters at a specific time. The current specification in phase 0 is set up to support critical system upgrades but does not outline exactly how such an upgrade would be performed. This week, our teammate Preston Van Loon investigates a potential implementation for applying upgrades in phase 0. Check out the one page design document here. In a collaborative effort, Danny Ryan responded in another document here.
Merged Code, Pull Requests, and Issues
Process logs streaming via websockets
We now have the ability to subscribe to logs for our beacon node and validator client via a websocket connection, making it easy to display those logs in dashboards or stream them to other processes! Beacon node logs can be accessed at ws://localhost:8080/logs by default and the validator logs at ws://localhost:8081/logs.
Eth2 Standard API definitions complete + implementation started
Our team member Ivan has been working on integrating the standard API for Eth2 into Prysm in order for our API to align with the official standard. Once all clients align with these standards, tooling could be built that is compatible with every client and integrations become much simpler. This can open the door for more block explorers, community tools, and overall more seamless integrations that use multiple clients. We have finished the definitions and are moving forward with the integration.
Voluntary exits implementation ready
After several weeks of work we are happy to announce that voluntary exits are finally complete. Most of the work concentrated on initiating the exit on the validator’s side and sending it over to the beacon node via a gRPC call. This week the last PR has been merged, the documentation has been released and the first validator has exited (big shout-out to our Discord user @Raphael for sacrificing his validator to help us test the feature on Medalla).
As usual, we are encouraging everyone to try out the functionality yourself. This will help us improve user experience and find possible implementation bugs. And it will give you the warm fuzzy feeling that your hard-earned GöETH is finally safe and sound.
Test coverage improvements
In a continuous effort to improve the test coverage of critical components we have landed a number of important commits. The most significant update is related to full coverage of initial synchronization state transition functions (see #7320, #7286, and #7285). The updated test suite handles all state transitions that might occur during initial synchronization, which solidifies the codebase even further, before the mainnet. Another important area that has received more tests is related to attestation proposing mechanisms (see #7267 and #7206).
We will keep up extending our quality assurance infrastructure, making sure that all of the critical paths are fully covered.
Prysm web UI beta testing very soon
We know the community really wants a user interface for their eth2 nodes and validators, and we are planning our first round of beta testing the first week of October! Our web UI has been shaping up nicely and includes a lot of useful functionality for those stakers that are more comfortable on the web than interacting with terminal commands. We designed and built the entire interface ourselves, putting our heart into creating something useful for our stakers.
We believe this interface will add a lot more usability to our client, making it a more appealing choice going into mainnet. Some of the features included at launch are:
- Ability to create a new HD wallet or import keystores
- Ability to see your validators’ recent performance, wallet details, and more.
- Ability to monitor your beacon node and validator logs
- Ability to look at your beacon node’s sync status
- Ability to see the validator queue and your validators’ places on the queue
- Ability to monitor global validator participation
- Back up keys, filter keys, and add more keys to your wallet
Data migration for slashing protection between clients
As part of eth2.0 multi client approach it is important to support easy and safe validator migrations between clients. Making a safe transition of validators between clients consists of both moving public keys safely and moving slashing protection db data between clients. As part of the effort to make the transition safe @sproul from sigma prime team compiled a doc with standardization of the local slashing protection data interchange format. In order to support the full standard we are making changes in our local protection db and adding the import and export features to our codebase. We hope to have the new protection db format running on most nodes in the coming weeks.
Interested in Contributing?
We are always looking for devs interested in helping us out. If you know Go or Angular 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
