Eth 2.0 Dev Update #52 — Onyx testnet launched
V0.12.1 Onyx Testnet is Stable
Since its launch 5 days ago on Sunday, our new Onyx testnet for eth2 phase 0 has been a success! Now with over 20,000 validators, and stable participation, we’re very happy with Onyx’s performance so far. One important feature change in Onyx is that our new state management is default after weeks of work, so knowing with certainty this important functionality is stable enough for production is fantastic!
On top of great stability in our testnet, what makes it more impressive is that we only control <20% of the network! This is great for testing our infrastructure, and really tests the chain’s stability under normal conditions since our unstable changes wouldn’t affect the network nearly as much as when we had the majority of validators.
Merged Code, Pull Requests and Issues
Critical proposer index mismatch bug fixed
Every time we relaunch our testnets we have a unique opportunity to discover consensus breaking bugs or issues that may otherwise not manifest in previous deployments. A new testnet launch entails coordinating many people to prepare for a genesis event of a new chain, often involving unexpected problems. Our teammate Nishant recently fixed a critical bug that has manifested thanks to multiclient testnet experiments here.
Many security patches thanks to the Quantstamp security audit
We have been working very closely with Quantstamp to get Prysm audited for the phase 0 launch. Quantstamp has been doing an excellent job on communicating potential bugs as they discover them. We are lucky to have chosen such a great partner. Here’s a list of potential vulnerability discovered by Quantstamp:
- 6029 — function to return intersection of int or byte slices don’t work if input has more than 2 slices
- 6034 — deletion in db has a potential vulnerability under certain condition
- 6038 — potential overflow vulnerability in pending blocks queue for syncing
- 6103 — edge case scenario where time difference is higher than intended for newly arrived block
- 6049 — potential overflow vulnerability in one of the rpc service
- 6215 — potential dis space exhaustion when finality can not be reached
Quantstamp will be providing us with an initial audit report next week. We look forward to that and can’t wait to share the initial result with the community.
Validator duties streaming
Currently, validators retrieve their assigned duties per epoch via a polling mechanism that requests from a beacon node through RPC. This suffers from several problems in various network conditions such as reorgs in which assignments may change. We want to ensure a validator client is “dumb” in the sense that it relies fully on the beacon node for information. It shouldn’t need to “know” what a reorg is. Instead, it should simply receive new assignments via a push mechanism if they exist or if they changed. We refactored our validator client implementation to use a streaming mechanism for duties. Instead of polling, validators subscribe to a server-side stream which gives them the necessary information to perform their duties. If a reorg occurs, the beacon node simply sends out new duties over the stream in case they change.
Significant slasher resource consumption improvements
Our team members Shay and Ivan have implemented a fantastic improvement to our handling of the slasher database. Previously, historical validator information was stored in a map, meaning saving and writing to the DB required a lot of expensive operations each time the DB was interacted with. Our latest changes have changed this to a much flatter data structure, reducing the disk I/O of the slasher immensely!
Shay also removed some restrictions for the slasher receiving blocks from the beacon node, this is to help with double block detection. Before this change, catching double blocks with the slasher would be very difficult.
Improved p2p peer handling through connection gating
Users that participated in the Sapphire and Topaz testnet likely remember how many noisy logs there were regarding peer disconnections and connection reattempts. Part of Onyx and v0.12.1 of the spec includes better handling of peers through some novel features in the libp2p library. Our teammate Nishant recently merged in a PR that utilizes these new features for connection gating and better management of peers’ lifecycles within Prysm.
Upcoming Work
Revamp of validator account management
One of the largest remaining hurdles for Prysm to be ready for phase 0 mainnet launch is to have a robust, easy-to-use, and safer validator account ecosystem. At the moment, Prysm’s validator accounts utilize “key managers” with confusing or difficult to use input parameters. While these key managers have been working well for early testing, these implementations are not secure enough or easy enough to use for mainnet.
Working design for Prysm’s account management hierarchy
In the last few months, we’ve been listening closely to user feedback around accounts and here are some of the common themes:
- I forgot my password, how do I restore my account?
- Is it possible to have multisig for withdrawal key?
- How can I move around my validator to a different computer? Is there something I need to do to move my withdrawal key to cold storage? (some users don’t even know there is a withdrawal key they need to keep safe)
- I had an account on a different computer I want to move to this computer, but the account had a different password
- How can I list my public keys / private keys?
- How can I regenerate my deposit data for my validator? How can I copy paste it if I’m using a pure terminal environment without a mouse? What is this deposit data?
- How can I make 100+ deposits? How can I manage multiple accounts in the same validator client?
- What is the keymanager? What are keymanager opts? What are all these flags?
- Why does a validator client have a datadir and how do I move it to a different computer?
- How can I specify the password to my validator client as an ENV var or config file?
- How can I delete an inactive key?
- How can I initiate a voluntary exit to stop validating?
- Is there documentation for accounts management? How can I provide a remote signer?
In this new design for Prysm accounts, all of the above issues will be resolved with excellent documentation on par with the Beacon Chain documentation. Subscribe to this github issue for the latest updates and progress on validator account management redesign.
Beacon state representation refactor for improved memory usage
Since we started Prysm, we have used protobufs to represent most critical data structures that are sent via p2p or RPC. In particular, we represented the BeaconState, which is the most critical data structure in eth2, as a protobuf. This is problematic because the state is never sent over p2p and RPC and therefore could be represented by a more optimal data structure, such as a pure Go struct. Protolambda from the Ethereum Foundation shared with us some excellent recommendations on how to refactor our state data structure for this use case. There is a lot of room to do fancy tricks on the beacon state including memory pooling, 0 allocation merkleization, and more. We are excited to start working on this feature very soon as it will be critical for mainnet.
Attestation packing optimizations
For several weeks we have been investigating the best way to optimize attestation packing: both in terms of runtime efficiency and profitability (the more attesters we can include in a block the better). This week we have merged the code of Max k-Cover algorithm (#6205), which will be used for both attestation aggregation and selection of the most profitable attestations to pack within a block. That way we will include more attesters’ votes, in the most efficient manner possible. During the next couple of weeks Victor will wrap up the integration, benchmarking and testing of that newly merged code with our current implementation.
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
