Overview & Research Background

At Prysmatic Labs, we started working on Ethereum 2.0 all the way back since Vitalik first had a Sharding FAQ as one of the only reference for the system at the end of 2017. A lot has happened since then, with the specification evolving from a series of ETHResearch blog posts into a minimal viable blueprint for a scalable, secure Ethereum blockchain using Casper Proof of Stake and Sharding at its core.

Now, the plan is to deploy ETH2.0 as a new chain known as a beacon chain, where validators can stake their Ether and participate in consensus to vote on occurrences on shards known as cross-links. This chain is synchronized with the current Proof of Work chain’s latest block hashes. Additionally, a contract will be deployed on the Proof of Work chain where users can deposit 32 of their current ETH for the beacon chain to queue them in as validators of ETH2.0.

Version 0.0.0: Beacon Chain+Validator Demo

We call our Ethereum 2.0 Shasper project Prysm, which will serve as the scaffold for a production-oriented release fully written in Go. We have been working hard to ensure we have a robust implementation of the Ethereum 2.0 specification as created by the Ethereum Research Team along with industry standard approaches to building a large scale application.

We are proud to announce our very first release of Prysm, v0.0.0, which will serve as the building block for all future releases as we get to production. We want to show the community we have a project we have put a lot of work into through careful thought and design decisions that we hope will set a standard for future ETH2.0 developments.

See the README here for instructions.

github.com/prysmaticlabs/prysm

What This Release Encompasses

Why do we call it v0.0.0 and not v0.0.1? There is still work to be done with respect to wrapping up Phase 0 of Shasper, but we wanted to give the community a taste of what a real client will look like. Version 0.0.0 includes a basic beacon-chain+validator demo which can do the following:

Spin up a beacon chain node from a genesis configuration

from a genesis configuration Connect a validator client to the beacon node via RPC

to the beacon node via RPC The validator client gets shuffled into a specific shardID at a given slot every cycle transition

every cycle transition Validators propose/attest to canonical beacon blocks during their assigned slot

blocks during their assigned slot Casper FFG rewards/penalties are included in this release even though they are a constantly evolving area of research

rewards/penalties are included in this release even though they are a constantly evolving area of research Basic, locally networked p2p via libp2p and the mDNS discovery protocol

via libp2p and the mDNS discovery protocol Beacon chain incoming block sync through p2p

through p2p A useful simulator of beacon blocks (this allows us to simulate other beacon nodes relaying info to our node locally)

(this allows us to simulate other beacon nodes relaying info to our node locally) Storing blocks/attestations/states to a levelDB, persistent key-value backend

gRPC public API client/server for querying a beacon node for canonical blocks, states, and latest validator assignments

client/server for querying a beacon node for canonical blocks, states, and latest validator assignments A robust, scalable build system known as Bazel used in production at Google, Pinterest, Dropbox, and other industry giants

known as Bazel used in production at Google, Pinterest, Dropbox, and other industry giants A Web3 Subscription service to listen to latest mainchain blocks and validator registrations

Beacon Chain Node + 2 Validator Clients!

Not Included in the Release

Although a Validator Registration Contract is included, validator rotation, withdrawals, and dynasty transitions are not yet included

is included, validator rotation, withdrawals, and dynasty transitions are yet included Initial beacon chain sync (spinning up a new instance and syncing to the canonical head of another instance) is not fully supported for this demo release

fully supported for this demo release Shards , their associated design, and cross-shard transactions are not included in this release. Validators are simply shuffled into shardIDs but do not actually do anything to validator shard blocks yet.

, their associated design, and cross-shard transactions are included in this release. Validators are simply shuffled into shardIDs but do not actually do anything to validator shard blocks yet. Fork-choice rule for ETH2.0 is not yet included, we use a naive fork choice rule for this release

for ETH2.0 is yet included, we use a naive fork choice rule for this release Signature aggregation and verification are not included in this release

and verification are included in this release Randomness via RANDAO and VDF are not included in this release as they are an active area of research — we use basic block hashes as a stub for now

via RANDAO and VDF are included in this release as they are an active area of research — we use basic block hashes as a stub for now Serialization format for ETH2.0 is still an active area of research and is not included here

format for ETH2.0 is still an active area of research and is not included here Shardp2p and beacon node p2p peer discovery have not yet been designed beyond mDNS

have not yet been designed beyond mDNS Shard state execution is not included as it depends on shard functionality

How to Run the Demo

Curious to see the system working and running a validator client locally? We have put together comprehensive instructions on running our demo in our Github repository! Try it out and see for yourself :)

You’ll be able to spin up a beacon node, connect 1 or more validator clients, and start getting assigned to shards where you will then create beacon blocks or vote on beacon blocks through structures called “attestations”. If you are not quite as familiar with the Ethereum 2.0 Roadmap and Spec, check out the following links:

Even though canonical blocks are created in the demo due to your activity as a validator, you’ll quickly see not much can be done with these blocks until real, state execution comes into play. However, this beacon chain node+validator client system is a critical piece of consensus and coordination for all actors participating in Ethereum 2.0 and will serve as the foundation for a full-fledged, sharding system.

So What’s Next?

Next up, we have a ton to do alongside the rest of the client implementation teams. There is a lot to be done with respect to the randomness generation and signature aggregation on the beacon chain as well as validator rotation. This is all phase 0–1 of the Ethereum 2.0 roadmap, as sharding state execution will not come until phase 1 and 2. In preparation for devcon, we’ll be iterating a lot more on our current release and including some of the key pieces we left out. Follow us on Medium and Twitter to track our biweekly development update threads!

Contributing

We are always looking for devs interested in helping us out. If you know Go 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 As always, follow us on Twitter, drop us a line on our Discord 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