Ethereum Sharding Biweekly Development Update # 9 — Prysmatic Labs
Rebranding as an Ethereum 2.0 Team
When we first started Prysmatic Labs, we envisioned ourselves building a big feature within Geth that could launch a sharding client connected to a running mainchain node, leveraging functionality already baked into Ethereum 1.0. As the sharding spec changed, however, it became more clear that Ethereum 2.0 would merge both casper and sharding not through a smart contract on the mainchain, but instead through a sidechain. This sidechain construct, also known as a random beacon chain, serves as a full Proof-of-Stake coordination device for Ethereum 2.0. The Proof-of-Work chain, in this case, serves only for a deployment of a contract that registers sidechain validators by having them deposit and burn 32 mainchain ETH. The sidechain would then only require read-only access to Geth in order to check for registered validators.
Initially we decided to begin our system as a fork of geth with the intention of being a subcommand of go-ethereum that leverages much of its functionality. Given the sharding system will work as a sidechain through a random beacon chain construct, the only reason we would need geth is for the one-time deployment of a validator registration contract. This process can easily be done via an RPC connection to a remote geth node.
As such, breaking away from the go-ethereum project gives us the flexibility to have a better test suite, a leaner architecture, and allows us to work with a clean slate from the start. As a team, our task is not only to implement sharding for Ethereum 2.0, but to implement Ethereum 2.0 itself, with a random beacon sidechain, great tooling, and comprehensive tests in a way that maximizes the power of using Go for a production system.
Renaming Geth-Sharding to Prysm
Given the decisions outlined above and following in the steps of giants such as Google, we have opted to turn our previous geth-sharding repo into an independent monorepo owned by Prysmatic Labs known as Prysm using a GPLv3 license where we contain all of our projects as subpackages.
This allows for maximum project separation and modularity, which will allow other teams that want to use our projects, such as the beacon-chain, to do so with minimal effort on dependency management.
Our documentation has been updated to match our new build environment and tooling, check it out in repo today here.
Merged Code, Pull Requests, and Issues
At Prysmatic Labs, we are building a production project. As such, we take preliminary designs and tests very seriously. Here are some of the latest major features we have checked into our repo.
Local Networked P2P Merged
This addition of libp2p for Prysm clients to communicate is critical for a meaningful sharding demonstration. Pull request #222 brings basic peer to peer communication via protocol buffer messages in a gossipsub. This PR introduces local discovery via multicast so that processes on the same machine or network can discover and communicate with each other. We decided to use protocol buffers for now, but we understand that having unordered fields is not great for consistent hashing across different languages and machines. As such, we are further exploring other message types or using the canonical serialization mechanism: RLP encoding. This p2p module currently resides in the Client but is likely to be abstracted and shared with the Beacon Chain since both of these need some form of peer to peer communications.
Validator Registration Contract and Deployment Tool Complete
We have developed a useful utility to make the validator registration contract deployment easy. Please check out the VRC deployment tool here . A user can deploy VRC via private key or a password file to unlock key json file. As for web3, user can use IPC or RPC to interact with a main chain node. Let us know if there’s any questions, we’d love to hear feedback on this.
Beacon State Transition Function & Validator Shuffling
We have started work on beacon chain’s state transition function, and a shuffling function to sample validators into a committee. We began working on the state transition function in regards to per-block processing. It affects the active state only, and focuses on verifying aggregate signatures, saving temporary records relating to in-block activity in the active state. Lastly, we are working on a helper function to hash the current active state so node can store the hash to current beacon block.
Proof-of-Work Mainchain Interactions for Beacon Chain Node
As mentioned in our introduction and in the sharding+casper v2 spec, Ethereum 2.0 will work through a sidechain known as a random beacon chain. The main Proof-of-Work chain will be used for synchronization, with each beacon block having a corresponding mainchain reference hash, and for reading logs from the validator registration contract and checking for registrations.
We have completed the mainchain web3 service that subscribes to chain events from a PoW node that will be used throughout the beacon-chain project. Our implemented package also includes all necessary utilities to subscribe to logs for registered validators on the mainchain.
See more in the merged PR here.
Updated Documentation Including Bazel
Our documentation and contribution guidelines have all been updated for everyone to use our new build environment, Bazel and run our tests accordingly. See our current top-level README here as well as the research notes that led up to the proposal of the random beacon chain here.
Upcoming Work
Block Proposals & Processing
For an incoming beacon block to be processed by a node before going through the fork choice rule, the following conditions need to be met:
- The parent pointed to by the parent_hash has already been processed and accepted
- The main chain block pointed to by the main_chain_ref has already been processed and accepted
- The node’s local clock time is greater than or equal to the minimum timestamp as computed by GENESIS_TIME + block.slot_number * SLOT_LENGTH
The validity conditions are being implemented here.
Beacon Chain Sync
The logic for beacon-chain syncing will be as follows:
- Listens for incoming blocks
- Checks if the node can process each
- Run updateActiveState for each
- Stores the updated state and processed block inside of a trie structure
- Persists the trie structure in local storage
Then, chain service will also run an UpdateHead goroutine that applies the forkchoice rule on this trie structure to create a canonical head+state, handles reorgs, and then persist these canonical structures to the DB.
You can follow the issue thread for this feature here.
PoS Slashing Mechanism and Rewards
The beacon-chain is the POS main chain in the new Casper/Sharding system. It is responsible for namely storing and maintaining a set of active,queued and exited validators. For participating in the system validators are appropriately rewarded while those who do not are penalised. During an epoch Transition rewards for FFG votes are computed. The online reward and offline penalties are computed according to the Casper FFG incentives where validators who participated in the last epoch are rewarded while those who did not and were offline will have their stake slashed.
Private Key Management of Beacon Node
One of the items that not been well-discussed with respect to security in the initial roll-out of Ethereum 2.0 is private key management. Given we rely on users depositing 32ETH into a mainchain contract, but ALSO require those users to run a beacon chain node, this has opened up a discussion of how a beacon chian node will have access to the mainchain user’s signing credentials (namely, their private key). We have opened an issue thread to discuss this here.
Integrating Beacon Chain With Our Previous Sharding Client Code
Our original code was an implementation of the minimal sharding protocol, which encompasses the different actors in a sharded Ethereum blockchain within a locally-running testnet. Our current focus is on creating a minimal random beacon chain, which will then be used to replace instances of the sharding manager contract in our old code, essentially tying back into a fully functioning system!
We have yet to update our product release requirements for our local testnet release, the Ruby Release, but we will tying all our work together soon. Our current sharding code is still fully functioning and now has p2p functionality built-in. You can access it here.
New Grant!
We are honored to have received a $200,000 grant from Wanxiang Blockchain Labs, a leading organization in China’s blockchain ecosystem, to be used towards our sharding work for Ethereum 2.0. In their own words:
Wanxiang Blockchain Labs is a non-profit research institution focusing on Blockchain technology. The organization provides support for the research, entrepreneurship, developments and applications in the industry. It will also provide reference information for regulatory bodies. Overall, Wanxiang Blockchain Labs dedicates itself to the promotion and application of Blockchain industry, and to explore how the technology will be contributing to the development of the economy and the society.
Please check out our contribution guidelines to see how you can get involved. It includes comprehensive information on beacon chain and sharding for both part-time and core contributors to the project.
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 1 milestone along with a specific project it belongs to (smart contract related tasks, notary node tasks, etc.).
As always, follow us on Twitter, drop us a line here or on our Gitter chat and let us know what you want to help with — we need all the collaboration we can get 🎉
Official, Prysmatic Labs Ether Donation Address
0x9B984D5a03980D8dc0a24506c968465424c81DbE
Official, Prysmatic Labs ENS Name
prysmatic.eth
