Ethereum 2.0 Serenity Testnet Update — Closer Than Ever
Our Ethereum 2.0 Phase 0 testnet is coming out soon! Here’s all you need to know before our official announcement.
Scope & Release Plans
After a long sprint of work, we are now on the brink of our public testnet release. This post details where the Prysm client currently stands, what we’re missing before we finally invite the community to participate in our public testnet, and the scope of features we are targeting at release and beyond.
Our plan is to release a public, single-client testnet for Phase 0 of the Ethereum 2.0 roadmap. We are currently targeting the v0.4 release of the official specification detailed here. The goal of this testnet is to have a highly available network that is resilient to forks, validator inactivity, and allows new validators to join the network to participate in Proof of Stake consensus according to the rules of the protocol.
The testnet also highlights how current holders of ETH can stake and deposit their coins into Ethereum 2.0 to become validators. We are deploying a Validator Deposit Contract onto the Goerli testnet, which will be used for this purpose. Users can deposit 3.2 Goerli testnet ETH into this contract with their Ethereum 2.0 private key credentials, run a Prysm node, and then be queued into becoming an active, proof-of-stake validator in the network. Deposits are one-way, that is, the test ETH cannot be sent back to the Ethereum 1.0 Goerli testnet chain.
Throughout the lifecycle of each validator, rewards will be accrued and penalties applied based their behavior. The protocol favors liveness, that is, the chain can continue even if a large amount of validators are offline, although being offline will cause deposits to eventually become penalized and for those affected individuals to lose capital. In short, we want our testnet to accomplish the following steps:
- Kickstart Ethereum 2.0 from Goerli testnet ETH into a Validator Deposit Contract
- Run the Phase 0 Proof of Stake beacon chain protocol with validators producing and attesting to blocks via distributed consensus on the Prysm client
- Apply a fork-choice rule (Latest Message Driven GHOST) that is resilient to network partitions due to latency or malicious actors
- Allow anyone to sync with the network via p2p and to activate new validators into the system
- Allow anyone running validators to see rewards over time as well as any penalties that may be applied depending on each validator’s uptime and activity
Our testnet will be a gradually evolving project that we hope the community uses as an opportunity to test how Ethereum 2.0’s beacon chain fares in practice out in the wild. We will include a monitoring portal for our cloud cluster anyone can see to inspect the health of the network as well as important documentation and instructions to participate.
It is important to note we are targeting this release as a single-client testnet, compared to the current Ethereum 1.0 mainnet and its testnets which currently support multiple clients such as geth, parity, trinity, and others. Ensuring we are compliant with the core protocol as well as having a long-running testnet is important to use before we work on client interoperability, but it is one of our priorities for the rest of the year as our and other implementation efforts mature in test networks.
Public Network, Cloud Cluster Running
Our team will be hosting a medium sized deployment of beacon chain nodes and validators. At the moment, we have configuration to quickly deploy and scale out the deployment with ease. We’ve tested multiple small configurations with deployments of 32 validators and we’re confident in the infrastructure to scale out to larger deployments of hundreds or thousands of validators. These cluster nodes will be publicly accessible to external peers such that anyone can join the network to observe or participate as a new validator.
Advanced Monitoring and Tracing Tools
One of our major goals of the test network is to observe the behavior of the clients as the scale increases. We’ve added a large suite of metrics monitoring and request tracing to help us understand where the bottlenecks are and how to improve. Additionally, we are monitoring the health of the system. As we introduce updates to the cluster, we’ll gradually roll out the new features and closely monitor the health of the nodes. If the update is clearly causing a regression, we’ll roll back the update and resolve the problem.
Feature List
Features Included
So far, we have implemented a client with a whole suite of tools to run the Ethereum 2.0 Phase 0 protocol in a peer-to-peer network. Our first release is NOT a simulation, but a real system that will give users a good idea of what to expect at mainnet.
Here is the full list of features contained in our first testnet release:
- Users can deposit Goerli ETH into a Validator Deposit Contract to become active validators in the Prysm testnet
- Users can run a beacon node and validator client which listens to a threshold of deposits being reached in the validator deposit contract
- Casper proof of stake consensus is applied in order to finalize block checkpoints which have received a consistent amount of votes over time
- Beacon nodes sync blocks and other information in real time with each other via Protocol Labs’ libp2p networking library
- Nodes can peer with others via Kademlia-based DHT discovery through the Internet
- New nodes joining the network can fully sync efficiently within seconds with the canonical head of the network
- Beacon nodes run the Casper Proof of Stake fork-choice rule called Latest Message Driven GHOST to decide on the canonical head and resolve potential network forks
- Validators use RANDAO through BLS cryptography to create a distributed source of pseudorandomness, this randomness is used to shuffle validators into committees and shards at every new epoch in the protocol
- Users can run validator clients which listen for assignments from a beacon node to propose or attest to blocks at a given timestamp
- The network can handle skip slots in which validators are inactive and the chain can still proceed as normal
- The protocol penalizes validators if there have been more than 4 epochs since a last finalized block, creating an incentive to vote correctly and on time
- The beacon node stores data through persistent disk storage using an embedded key-value store called BoltDB, which is a large improvement from Ethereum 1.0’s LevelDB
- New validators can be inducted via a voting mechanism built into the protocol or ejected if their balance drops below a safe threshold due to penalties
- We include production-grade monitoring via Prometheus and spanning tools to analyze the performance of a beacon node and a cluster of nodes as a whole running over a real p2p network
- We provide a public RPC API using Google’s gRPC library and protocol buffers for the fastest process-to-process communication from beacon node to validator client and vice versa
- We provide leveled-logging using logrus to understand every event happening underneath the hood in the beacon node’s runtime
- Our protocol contains extensive code coverage throughout — we never merge code without writing tests for its behavior first
Features Excluded
There are certain features we decided to exclude for this testnet release in the interest of time that are indeed critical for a secure mainnet release. These features will be released into our testnet via rolling upgrades on a scheduled basis:
- We have disabled signature verification from our first public release, as we are still in the process of finding a more efficient BLS signature library that can meet the needs of a large number of validators participating in the network
- We have disabled the use of the Simple Serialize (SSZ) We are targeting a single-client release and are using protocol buffers for p2p wire communication
- We have disabled beacon chain transfers between validator accounts
- We currently do not have a mechanism for validators to slash other validators and earn a whistleblower reward as we are assuming an honest majority testnet in its first iteration
- We have disabled shard crosslink processing as it is mostly a feature that will allow Phase 1 to flow in seamlessly, but our testnet is only targeting Phase 0 at present
- We have disabled voluntary validator exits as our testnet ETH does not have real value and will be re-enabling it in a future update
Final Steps Before Going Live
At Prysmatic Labs, we want to bring the community the best quality work we can produce. As such, we need to ensure resilience of our testnet before we encourage community participation in it.
We’re not a fan of releasing something for the sake of hype or merely giving the community a simulation — we want to give you the real thing. Here is a comprehensive list of the last details and bug fixes we need to address before we do a full release:
- Fix a race condition in newly inducted validators receiving assignments from the beacon node as to when they need to propose or attest to new blocks
- Address an issue in our initial sync when a chain goes through multiple reorgs and our nodes replay the reorg history when instead they should simply request blocks from the last finalized state to the canonical current state
- Allow a validator client to manage multiple private keys, as that will allow users who hold a large amount of ETH to easily run our infrastructure
- Ensure longevity and liveness of our testnet with new validators being inducted and others being ejected throughout
- Ensure edge-conditions in forking can be effectively handled by any node
- Cache validator assignments to prevent expensive computations from occurring at every requested slot throughout an epoch — this will bring a radical efficiency improvement to our nodes
- Wrap up our testnet information and onboarding website with comprehensive instructions on how to participate
As you can see from above, we’re closer than ever before :)
After the Release
After our release, we will freeze our master branch and schedule monthly releases with improvements to our testnet and new feature additions that bring us closer to a multi-client environment. These improvements will be both feature and bug fixes as well as any new ideas that are contained in the latest official specification. We will be communicating any updates extensively to the community to make sure no one is behind on when nodes should be upgraded. We have a lot more work to do, and ensuring client integrity and long-running chain will be our priorities for the next few weeks and months.
Our team is also attending EDCON in Sydney this April! Come find us to chat about ETH 2.0 and our plans for the rest of the year with respect to our releases, tools, and implementation efforts — we’d love to see you there!
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, drop us a line here or on 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
