Eth 2.0 Dev Update #56— “Road to Mainnet”
🆕 Road to Launch
🔹 Mainnet release public checklist
A public checklist for the eth2 phase 0 mainnet launch has finally been created and released to the public here. If you’re curious about the progress towards mainnet and when we might launch without resorting to speculating about dates, this project board is a great way to do so. To give a more granular perspective of our team’s focus before mainnet:
- Second security audit
- Implementing the eth2.0-apis standard in Prysm for client interoperability
- Wrapping up voluntary exits in Prysm
- A comprehensive web UI for Prysm!
- Fuzz testing and resolving important bugs before we go to mainnet
- Slasher improvements
- Common slashing protection format for transporting keys between eth2 clients
- Weak subjectivity sync
Out of these, only a few are features, which means that we can likely perform a feature freeze by mid October, allowing us to only work on security improvements and UX before going live. If all goes well, November is still looking good for a launch from our perspective.
🔹 Audit by Trail of Bits
We are pleased to announce the Prysm project is being audited by security firm Trail of Bits. Going into mainnet, having 2 full code audits for our eth2 client is critical for the safety of our stakers and in order for us to also identify ways of improving our client with code best practices. Having two separate organizations, Quantstamp and Trail of Bits, review our code independently is also beneficial because Trail of Bits can already start looking at the code in the context of the previous audit and identify places where the code may have changed since then or places where it would benefit from further review. In particular, this new audit is focusing a lot on slasher, slashing protection, and core specification attack vectors. For the sake of optimization, sometimes we diverge from the spec in certain places and this audit will help determine the safety of our approach.
📝 Merged Code, Pull Requests, and Issues
🔹 Significant security improvements to denial of service attacks
Ethereum Foundation researcher Protolambda has helped us a lot over the past 2 weeks with security analysis for denial of service in Prysm. He has shared with us multiple places where we failed to perform proper checks on inputs to prevent the node from being overwhelmed by data coming from the outside world. We have been tightening up this code recently with many bug fixes merged in recently that would help prevent any catastrophic scenarios in mainnet. We are looking forward to this upcoming audit to further analyze potential issues.
🔹 Removal of hosted eth1 node support, to closer simulate what mainnet will resemble
As many node operators are aware, Prysmatic Labs has been offering their own hosted eth1 nodes to people running Prysm beacon nodes for a long time now. For participating in the testnet over the previous months, stakers didn’t need to run their own eth1 node because their beacon nodes would connect by default to https://goerli.prylabs.network. However, as mainnet gets closer, we will not be hosting eth1 nodes for the public to use. The expectation is that you must either run your own eth1 node, or use a third party provider such as Infura or Alchemy. Running an eth1 node is important if you are running validators because validators include the latest eth1 block root and other information in their blocks to use in a voting process within the beacon chain. To add your own eth1 node, you can follow our instructions in our documentation portal here. As of the last few weeks, Prysm beacon nodes do not connect to our hosted eth1 nodes by default.
🔹 Voluntary exits implemented, with the ability to submit an exit from the Prysm CLI
Our teammate Radek took ownership of the voluntary exits feature in Prysm. We have promised our users for a while that we would allow simple voluntary exits from the command line with Prysm, and we decided to prioritize that as we get closer to mainnet launch. Radek implemented a command: `prysm.sh validator accounts-v2 exit` which guides stakers through an interactive process in which they can submit an exit to their beacon node. Given exits are irreversible, a lot of steps are in place to ensure users know what they are doing before they successfully complete the process. You can see the implementation here.
🔜 Upcoming Work
🔹 Advanced peer scoring added to our p2p routing
Enabling peer scoring and evaluation in Prysm nodes is an ongoing effort which eventually will result in beacon nodes favoring well-behaved peers, while restricting less useful ones.
The problem is being tackled from two sides: scoring peers’ behavior on an application level invariants, and, then, descending to a lower network level invariants too. Application level scoring allows us to restrict peers based on some higher level scenarios (e.g. restricting peers that happen to return less than average number of blocks consistently during two consecutive epochs). Network level invariants help nodes build a healthy network mesh, based on network performance of surrounding peers.
Application level peer scorer has been added in #6579 and #6709, and is still highly experimental, and therefore will sit behind the ` — dev` flag for quite some time (still once we sort out the network mesh scoring, extending it to the app level is just a matter of injecting our scoring function into GossipSub params list).
When it comes to enabling network level scoring, it was blocked by an issue in the upstream protocol, which has recently got resolved (GossipSub support for dynamically setting topic scoring parameters was merged in just a couple of days ago, see this PR in go-libp2p-pubsub). So, with this update to GossipSub, we have been able to progress with introducing network level peer scoring into our p2p routing. If you wish to follow the development, please, refer to issue #6043, which has a corresponding PR#6943. That PR is still a work in progress, but we hope to merge it into the master in the upcoming weeks.
🔹 Weak subjectivity sync
One of the beautiful aspects of eth2 is the concept of “chain finality”, which means that given the consensus voting rules, there exists a certain checkpoint of blocks in which the chain cannot be reverted at all as defined in the protocol. Proof of work chains can always be reverted if an attacker has enough mining power to force the majority to switch to their chain. However, given how fork choice works in proof of stake along with the rules of consensus, proof of stake defines explicit finality in which the protocol itself makes it impossible to revert past a certain checkpoint.
An obvious example is the genesis block, which by definition is meant to be irreversible and is agreed upon by all participants as the starting point of chain sync. However, given enough time and finality, we can pick another checkpoint which is not the genesis block from which it is safe for nodes to sync while having significant validation of the blockchain. This sort of sync is known as “weak subjectivity sync” and has been subject of much research by the Ethereum Foundation over the past years. Before we go to mainnet, implementing weak subjectivity sync is important to mitigate certain attacks on the chain and also avoid having to hard fork in the future to add such a feature. The official write-up on how weak subjectivity will work on eth2 is located here and our teammate Terence has already started on incorporating this into Prysm.
🔹 Common slashing protection format for client interoperability
Exporting keystores from Prysm and importing them into Lighthouse or vice versa is not enough to protect users during a catastrophe. During the Medalla testnet incident, we saw several validators get slashed when they transitioned from Prysm to another client. The reason this happened was because Prysm implements a slashing protection feature but it is not compatible with other clients and the slashing protection summary does not get exported when a user exports their keystores to another client. As we get closer to mainnet, having this protection become a common format between clients is critical, as well as having clearly documented migration paths between clients that keep users safe. Michael Sproul from the Sigma Prime (Lighthouse) started an initiative for slashing protection compatibility, and our teammate Shay has been working with him and other eth2 implementers to ensure we include this feature in Prysm.
🔹 Implementing the standard, eth2.0-apis in Prysm
Our teammate Ivan has been working on a standard implementation of https://github.com/ethereum/eth2.0-APIs which has been decided as the REST API standard for eth2 clients. Over the past year, we have maintained our own API under the repository https://github.com/prysmaticlabs/ethereumapis which has powered Prysm through multiple testnets and served block explorers such as https://beaconcha.in and https://beaconscan.com.
However, it is really critical all teams align to a standard as much as possible before a mainnet launch. In eth1, the two major clients, geth and parity, had certain huge mismatches in API endpoints which made interoperability difficult and a pain for many node operators, block explorers, and companies. Post mainnet, teams will likely be a lot busier with maintenance and improvements to implement such a radical overhaul of their API. This is why we aim to finish our compatibility with eth2.0-APIs before mainnet launch. Ivan has been working on defining all of these protobuf definitions necessary for the API standard here:
https://github.com/prysmaticlabs/ethereumapis/pull/184 and over the course of the coming two weeks we will start implementing them in Prysm. It is important to note we will still support ethereumapis for those who wish to use it.
Miscellaneous
🔹 Awesome project built for Prysm: Typescript Remote Signer Server!
We want to highlight an awesome project by one of our stakers this past week for Prysm. Sven from our discord server recently published https://github.com/ethpos/remote-signer-ts which is a remote signer implementation compatible with Prysm written in Typescript! Remote signers are the most secure kind of wallet setup for anyone participating in eth2 as they completely separate the validating keys from the beacon node via an Internet connection. You can connect Sven’s remote signer to your prysm validator client to perform signing of data and block proposals remotely. For reference, we have a dedicated page in our docs portal towards remote signers here. This page includes all information regarding how a remote signer works, what it takes to build a remote signer, and how to use this as your wallet in Prysm. Check out Sven’s project :).
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
