Ethereum 2.0 Development Update #19 — Prysmatic Labs
Our biweekly updates written by the entire Prysmatic Labs team on the Ethereum 2.0 Serenity roadmap
Latest Research Updates
Beacon chain CBC casper
The topic of Casper CBC (Correct by Construction) vs. Casper FFG (Friendly Finality Gadget) have been discussed extensively since they were first introduced. However, it is important to consider they are not exactly two competing proof of stake models, but rather CBC is a way to reason about consensus protocols while FFG is a specific proposal for a Proof of Stake-based consensus protocol implementation. CBC has been criticized in the past for having a very high overhead in complexity and protocol efficiency despite its safety, but Vitalik has done a good job of explaining how Ethereum Serenity clients could add ideas from CBC down the line without sacrificing much efficiency.
The major difference is in the CBC fork choice rule, which can be highly inefficient in time complexity due to the number of validators needing to exchange messages compared to FFG’s model. Vitalik suggested modifying the fork-choice rule by having it run on a pseudorandomly selected subset of validators to cap the overhead of the fork-choice rule while sacrificing a little fault tolerance. In the end, this could give clients the robustness of CBC while making a trade-off that could be well worth it in the end. See more in the original ETHResearch post here.
Validator Deposit Contract Latest Changes
We have made updates to validator deposit contract here to fulfill Solidity 0.51 rules and align with the Vyper sample code in spec 2.0. We discovered by using abi.encodePacked costs less gas than mergeBytes, but the difference was little. The toBytes(), mergeBytes() and getReceiptRoot() operations were optimized and thoroughly tested. On top of that, we added Safemath library to prevent uint underflow/overflow for the deposit timestamps.
Merged Code, Pull Requests, and Issues
Latest Block Processing Operations Complete
In the latest specification, a beacon chain state transition encompasses 3 major scenarios: regular slot processing in which a block is not received, block processing, and epoch processing. That is, even if there is no block for a certain slot, there is still some bookkeeping the beacon chain performs. Some of the most important details of the chain, however, change when blocks are received.
The following happen in order during block processing within a state transition:
- Processing of block RANDAO as part of the RNG of Ethereum Serenity
- Processing of proposer slashings
- Processing of Casper FFG slashings of validators
- Processing of attestations included by validators
- Processing of validator deposits from the PoW chain into the beacon state
- Processing of validator exits
We have completed all of these items exactly according to the spec as can be found here. Our implementation of block processing has reached 100% test coverage, as a best practice for critical code paths in our repo. See the code here.
Latest epoch operations complete with Proof of Stake finality
Epoch processing is the next part of the state transition which happen every 64 slots of time in the beacon chain. At the start of a new epoch, validator rotations occur after applying rewards and penalties to balances, blocks are finalized based on Casper Proof of Stake, and shard crosslinks are processed in full. Our teammate Terence Tsao completed a series of PRs with full coverage such as this one.
State Transition Function Complete
The current changes in the spec involved us having to refactor the majority of our core operations to be up to date with the changes. The biggest changes would be how our state transitions would occur and the impact it would have on our blockchain service. State transitions are now split into two different types of transitions,specifically per-slot transitions and per-epoch transitions. Per-Slot transitions focus on aggregate signature verifications and the saving of temporary records, ex: Attestations. Per-Epoch transitions are responsible for changes in the validator registry and managing block justification and finalization. During epoch transitions, balances are adjusted for rewards/penalties and validators are activated/exited.
With these big changes occurring in the spec we had to refactor the majority of our blockchain service to accommodate them. Our node’s internal clock is now dependent on the block processing, meaning that state transitions will not occur until a block has been received. So the state stays latent for a period where no blocks are received and is only updated to the correct slot until a block is received by the beacon node. Currently. this is how a block would be processed:
- Beacon Node receives block
- Beacon Node validates that the block is of a valid slot before passing it through pre-processing
- Beacon Node then checks if the block passes the pre-processing conditions
Once that has been verified, the block is sent to the state transition function where a whole host of actions take place, namely the per slot transition where the relevant block operations are carried out and the per epoch transition where the validator registry is adjusted and block finalization/justification occurs if the current slot is at the epoch boundary.
Simple Serialize Complete With Tree Hashing Algorithm
Our contributor Jie Hou has completed the full Simple Serialize specification as the serialization format for Ethereum Serenity. In Ethereum 1.0, RLP (Recursive Length Prefix encoding) was used for serialization, and Simple Serialize (SSZ) is its successor. The entire specification for SSZ has been completed by Jie and merged through a series of PRs for an issue thread here.
Additionally, SSZ also specifies a Merkle Tree hashing algorithm which will make light client and state access a lot easier and efficient through proper serialization. Jie has also completed and merged in the tree hashing algorithm here.
Pure State Transition Function End-to-End Tests
Cross-client compatibility is critical for Ethereum. If our code does not conform to what Lighthouse, Pegasys, or Lodestar are doing or vice-versa, we cannot speak the same protocol and therefore our efforts are moot. As such, we are following the tradition of Ethereum 1.0 byrequiring extensive testing in a common format, such as the YAML language. With YAML, one can write up a simple test case for some internal beacon chain logic that can run on all clients to ensure conformity. We call these conformity tests. For example, the following tests a state transition advancing a bunch of slots and verifying the state actually did transition correctly.
We will be writing our entire end-to-end tests in YAML, and making it easy for anyone to play around with state transitions in the beacon chain and verifying they work as expected. We have done this here. We also have a CLI tool that runs these YAML tests easily on Prysm here.
Go-BLS Signatures Project Ready for Use
After a long quarter of work on BLS signature aggregation in which we went down multiple rabbit holes of different implementations, we settled on a library by an ex-dfinity cryptographer known as Herumi, who has put together an excellent pure C/C++ implementation of the project. We have created our own Go wrapper and closed a $1000 bounty for building the project using our build system, Bazel. The project can be found here thanks to all the hard work put together by Robin Thomas, thank you for your help! We will be using this project for all signature aggregation and verification on the beacon chain as per the Ethereum Serenity specification.
Almost every key component of Ethereum Serenity phase 0 that seemed so far away is now wrapped up or in the works, including RANDAO, BLS, Simple Serialize, and others :).
Upcoming Work
Starting Q1 2019
Our plan at Prysmatic is to release an Ethereum Serenity phase 0 testnet this quarter. We are working at full-steam ahead to get you a robust implementation which has almost no missing components from the real thing. Keep an eye out for better documentation and information on how our Prysm client works and information on testnet plan the following weeks.
Completing Validator Rotation
As for rotating validators in the beacon chain every epoch, there is still some small rework and optimization being done in the spec with regards to this, and it is one of the final touches to complete in the spec for us to be fully aligned on core logic. In particular, validator shuffling is impacted a bit by some outstanding research and ideas put together in the spec in pull requests by Vitalik such as this one. Overall, most spec changes are cosmetic in nature or based on optimizations. The key ideas for Serenity Phase 0 have been set with reasonable changes.
Batched Sync Mode for Beacon Blocks
We have merged in a PR which will allow nodes to request blocks in batches instead of one after the other. The advantage of this compared to the previous method is that it is much more efficient as only a single message needs to be broadcast to send multiple blocks, which improves the time that it will take for a node to sync to the current head. Future PRs will also look at methods to validate the received batches and how to handle incomplete batched blocks or handle responses sent by malicious actors.
Testnet Preparation: Service Health Checks
Our teammate Preston Van Loon has been putting together parts of our testnet architecture and has emphasized the importance of having service health checks for all components of a beacon node. Allowing users to know the status of the RPC service, the blockchain service, the p2p of a node, and more will allow for more confidence in running a beacon node. These parts are also critical for scaling our testnet cluster and determining the stability of our architecture. We have opened up a lot of good first issues to add health checks to a variety of Prysm services here.
Validator Client Rework
With the current changes in the spec, it has led us to take another look at our validator client architecture. Here is the design doc illustrating it. The new changes will require validator clients to sign the Proposal data when proposing a block and then send the block to the beacon node. Proposers also will need to request for the state root from the beacon node for block proposals. New RPC methods will be required to send and receive these data structures between the clients . This issue is being worked on in this PR.
Miscellaneous
Gitcoin Grants Program
Special thanks to Hibero, Econoar, tyndallm and wbobeirne and donating to Prysmatic Lab’s Gitcoin Grants, and special shout out to Gitcoin for creating this awesome product to support recurring funding for open source software. These grants will allow us to hire more developers and speed up ETH2.0 implementation progress in 2019!
Beacon Chain Implementers Call, Jan 3, 2019
The last ETH 2.0 implementers call happened today. Check out the stream link and topics of discussion in the issue thread here.
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
