github/prysm
1
1
Fork 0
mirror of https://github.com/OffchainLabs/prysm.git synced 2026-01-10 16:08:26 -05:00
Code Issues Packages Projects Releases Wiki Activity

Update All Our Documentation (#2012)

Browse Source 
* full docs update

* update README

* gofmt and goimports
This commit is contained in:
Raul Jordan
2019-03-17 16:30:46 -06:00
committed by GitHub
parent 8d52c52ea4
commit 6c580e6bf2
18 changed files with 246 additions and 483 deletions
Download Patch File Download Diff File Expand all files Collapse all files

6
CONTRIBUTING.md
View File

@@ -2,9 +2,7 @@
Excited by our work and want to get involved in building out our sharding releases? Or maybe you haven't learned as much about the Ethereum protocol but are a savvy developer? Our [READINGS.md](https://github.com/prysmaticlabs/prysm/blob/master/docs/READINGS.md) doc includes comprehensive information on Ethereum and sharding for both part-time and core contributors to the project.
Additionally, our [Sharding Reference Implementation Doc](https://github.com/prysmaticlabs/prysm/blob/master/validator/README.md) serves source of truth for all things related to our implementation of sharding for Ethereum.
You can explore our [Current Projects](https://github.com/prysmaticlabs/prysm/projects) in-the works for our different releases. Feel free to fork our repo and start creating PR’s after assigning yourself to an issue of interest. We are always chatting on [Discord](https://discord.gg/che9auJ) or [Gitter](https://gitter.im/prysmaticlabs/geth-sharding) drop us a line there if you want to get more involved or have any questions on our implementation!
You can explore our [Open Issues](https://github.com/prysmaticlabs/prysm/issues) in-the works for our different releases. Feel free to fork our repo and start creating PR’s after assigning yourself to an issue of interest. We are always chatting on [Discord](https://discord.gg/che9auJ) or [Gitter](https://gitter.im/prysmaticlabs/geth-sharding) drop us a line there if you want to get more involved or have any questions on our implementation!
## Contribution Steps
@@ -198,7 +196,7 @@ We do not expect all part-time contributors to be experts on all the latest shar
Core contributors are remote contractors of Prysmatic Labs, LLC. and are considered critical team members of our organization. Core devs have all of the responsibilities of part-time contributors plus the majority of the following:
- Stay up to date on the latest sharding posts on ETHResearch
- Stay up to date on the latest beacon chain sepcification
- Monitor github issues and PR’s to make sure owner, labels, descriptions are correct
- Formulate independent ideas, suggest new work to do, point out improvements to existing approaches
- Participate in code review, ensure code quality is excellent, and have ensure high code coverage

7
PULL_REQUEST_TEMPLATE.md
View File

@@ -1,4 +1,3 @@
TODO(you): choose "part of" or "resolves" and the associated github issue #.
[Part of|Resolves] #531
@@ -7,8 +6,8 @@ TODO(you): choose "part of" or "resolves" and the associated github issue #.
# Description
TODO(you): Write why you are making the changes in this pull request.
**Write why you are making the changes in this pull request**
TODO(you): Write a summary of the changes you are making.
**Write a summary of the changes you are making**
TODO(you): Link anything that would be helpful or relevant to the reviewers.
**Link anything that would be helpful or relevant to the reviewers**

163
README.md
View File

@@ -2,21 +2,20 @@
[![Build status](https://badge.buildkite.com/b555891daf3614bae4284dcf365b2340cefc0089839526f096.svg)](https://buildkite.com/prysmatic-labs/prysm)
This is the main repository for the beacon chain and sharding implementation for Ethereum Serenity [Prysmatic Labs](https://prysmaticlabs.com).
This is the main repository for the Go implementation of the Ethereum 2.0 Serenity [Prysmatic Labs](https://prysmaticlabs.com).
Before you begin, check out our [Contribution Guidelines](#contributing) and join our active chat room on Discord or Gitter below:
[![Discord](https://user-images.githubusercontent.com/7288322/34471967-1df7808a-efbb-11e7-9088-ed0b04151291.png)](https://discord.gg/KSA7rPr)
[![Gitter](https://badges.gitter.im/Join%20Chat.svg)](https://gitter.im/prysmaticlabs/geth-sharding?utm_source=badge&utm_medium=badge&utm_campaign=pr-badge)
Also, read our [Sharding Reference Implementation Doc](https://github.com/prysmaticlabs/prysm/blob/master/docs/SHARDING.md). This doc provides a background on the sharding implementation we follow at Prysmatic Labs.
Also, read our [Roadmap Reference Implementation Doc](https://github.com/prysmaticlabs/prysm/blob/master/docs/ROADMAP.md). This doc provides a background on the milestones we aim for the project to achieve.
# Table of Contents
- [Running Our Demo Release](#running-our-demo-release)
- [Installation](#installation)
- [Run Our Pre-Compiled Binaries](#run-our-pre-compiled-binaries)
- [Installation](#installation)
- [Run Via the Go Tool](#run-via-the-go-tool)
- [Run Via Bazel (Recommended)](#run-via-bazel-recommended)
- [Running The Beacon Chain](#running-the-beacon-chain)
- [Running an ETH2.0 Validator Client](#running-an-eth20-validator-client)
@@ -26,28 +25,12 @@ Also, read our [Sharding Reference Implementation Doc](https://github.com/prysma
- [Contributing](#contributing)
- [License](#license)
# Running Our Demo Release
To run our current release, v0.0.0, as a local demo, you'll need to run a beacon chain node and a validator client.
In this local demo, you can start a beacon chain from genesis, connect as a validator client through a public key, and propose/vote on beacon blocks during each cycle. For more information on the full scope of the public demo, see the demo information [here](https://github.com/prysmaticlabs/prysm/blob/master/docs/DEMO_INFORMATION.md).
## Installation
You can either choose to run our system via:
- Downloading our Precompiled Binaries from our latest [release](https://github.com/prysmaticlabs/prysm/releases)
- Use Docker
- Use Our Build Tool, Bazel **(Recommended)**
## Run Our Pre-Compiled Binaries
First, download our latest [release](https://github.com/prysmaticlabs/prysm/releases) for your operating system. Then:
```
chmod +x ./beacon-chain
chmod +x ./validator
```
- Use Docker
## Run Via Bazel (Recommended)
@@ -68,97 +51,87 @@ Bazel manages all of the dependencies for you (including go and necessary compil
### Building
Then, build both parts of our system: a beacon chain node implementation, and a validator client:
You can prepare our entire repo for a local build by simply running:
```
bazel build //beacon-chain:beacon-chain
bazel build //validator:validator
bazel build //...
```
## Deploying a Validator Deposit Contract
If you want to run our system locally, you'll need to have a **Validator Deposit Contract** deployed on the Goerli Ethereum 1.0 [testnet](https://github.com/goerli/testnet). You'll need to acquire some Goerli ETH first and then you can easily deploy our deposit contract with Bazel:
```
bazel run //contracts/deposit-contract/deployContract -- --httpPath=https://goerli.prylabs.net
--privKey=${YOUR_GOERLI_PRIV_KEY}
```
You'll see the deposit contract address printed out, which we'll use when running our Eth 2.0 beacon nodes below:
```bash
INFO: Build completed successfully, 1 total action
[2019-03-17 11:54:27] INFO main: New contract deployed address=0x1be4cbd38AC5b68727dCD2B73fc0553c1832ca42
```
Copy the address, you'll need it in the next step:
## Running The Beacon Chain
To start the system, you will need a special data directory where all the beacon chain data will be persisted to.
Then, you can run the node as follows:
With the binary executable:
To start your beacon node with bazel:
```
./beacon-chain \
--datadir /path/to/your/datadir \
--rpc-port 4000 \
--demo-config \
--p2p-port 9000
bazel run //beacon-chain \
--deposit-contract DEPOSIT_CONTRACT_ADDRESS
```
With bazel:
```
bazel run //beacon-chain --\
--datadir /path/to/your/datadir \
--rpc-port 4000 \
--demo-config \
--p2p-port 9000
```
We also have a `--demo-config` flag that configures some internal parameters for you to run a local demo version of the system.
If you want to see what's happening in the system underneath the hood, add a `--verbosity debug` flag to show every single thing the beacon chain node does during its run time. If you want to rerun the beacon chain, delete and create a new data directory for the system to start from scratch.
![beaconsystem](https://i.imgur.com/vsUfLFu.png)
The chain will then be waiting for the **Validator Deposit Contract** to reach a deposit threshold before it begins! Now, you'll need to spin up enough validator clients that can reach the threshold with the following next steps:
## Running an ETH2.0 Validator Client
Once your beacon node is up, you'll need to attach a validator client as a separate process. This validator is in charge of running Casper+Sharding responsibilities (shard state execution to be designed in phase 2). This validator will listen for incoming beacon blocks and shard assignments and determine when its time to perform attester/proposer responsibilities accordingly.
Once your beacon node is up, you'll need to attach a validator client as a separate process. Each validator represents 32ETH being staked in the system, so you can spin up as many as you want to have more at stake in the network.
To get started, you'll need to use a public key from the initial validator set of the beacon node. Here are a few you can try out:
```
bc36789e7a1e281436464229828f817d6612f7b477d66591ff96a9e064bcc98a
5fe7f977e71dba2ea1a68e21057beebb9be2ac30c6410aa38d4f3fbe41dcffd2
f2ee15ea639b73fa3db9b34a245bdfa015c260c598b211bf05a1ecc4b3e3b4f2
69c322e3248a5dfc29d73c5b0553b0185a35cd5bb6386747517ef7e53b15e287
f343681465b9efe82c933c3e8748c70cb8aa06539c361de20f72eac04e766393
dbb8d0f4c497851a5043c6363657698cb1387682cac2f786c731f8936109d795
d0591206d9e81e07f4defc5327957173572bcd1bca7838caa7be39b0c12b1873
ee2a4bc7db81da2b7164e56b3649b1e2a09c58c455b15dabddd9146c7582cebc
d33e25809fcaa2b6900567812852539da8559dc8b76a7ce3fc5ddd77e8d19a69
b2e7b7a21d986ae84d62a7de4a916f006c4e42a596358b93bad65492d174c4ff
```
Run as follows:
With the binary executable:
```
./validator \
--beacon-rpc-provider http://localhost:4000 \
--datadir /path/to/uniquevalidatordatadir \
--pubkey f2ee15ea639b73fa3db9b34a245bdfa015c260c598b211bf05a1ecc4b3e3b4f2
```
With Bazel:
To get started, you'll need to create a new validator account with a unique password and data directory to store your encrypted private keys:
```
bazel run //validator --\
--beacon-rpc-provider http://localhost:4000 \
--datadir /path/to/uniquevalidatordatadir \
--pubkey f2ee15ea639b73fa3db9b34a245bdfa015c260c598b211bf05a1ecc4b3e3b4f2
accounts create --password YOUR_PASSWORD \
--keystore-path /path/to/validator/keystore/dir
```
Once you create your validator account, you'll see a special piece of information printed out below:
This will connect you to your running beacon node and listen for shard/slot assignments! The beacon node will update you at every cycle transition and shuffle your validator into different shards and slots in order to vote on or propose beacon blocks.
```bash
[2019-03-17 11:57:55] INFO accounts: Account creation complete! Copy and paste the deposit data shown below when issuing a transaction into the ETH1.0 deposit contract to activate your validator client
if you want to run multiple validator clients, **each one needs to have its own data directory where it will persist information, so create a new one each time** and pass it into the validator command with the flag `--datadir /path/to/validatordatadir`.
========================Deposit Data=======================
0xbc00000060000000814eb687f39e9a0be79552cd51711dfb1711274a892e4ccae1e61d0bb28ef82c85e81b68b4911f73ca06e6694133c9610a6677d512df7a6a0289ecd1a218a8b2de29fa298c24c9e17dac4d7fb268992e8d08d74fafa076757d28ffa29ea7a36b30000000996e3494661110bf9c72f1bacee84d1b64039092bf1e6856eaf8d87b1a992999d4bff9c3701ded7714e8421c8ec1fd4520000000001e1ba7155f64eda1d1a87f3ed4eaf0280b86bef90b2cd1d9b905e370650251
===========================================================
```
Keep this deposit data string, as you'll need it in the next section.
```
bazel run //validator --\
--password YOUR_PASSWORD \
--keystore-path /path/to/validator/keystore/dir
```
This will connect you to your running beacon node and listen for validator assignments! The beacon node will update you at every cycle transition and shuffle your validator into different shards and slots in order to vote on or propose beacon blocks. To then run the validator, use the command:
Given this is a local network, you'll need to create and run enough validators to reach the deposit contract threshold so your chain can begin.
## Depositing 32ETH and Starting the Eth 2.0 Network
Once you launch your beacon chain and validators, your nodes won't do much and will simply listen for the deposit contract to reach a valid threshold. You'll need an Eth 1.0 wallet that can send transactions via the Goerli network such as Metamask loaded with enough Ether to make deposits into the contract. Using the deposit contract address from earlier and your validator deposit data from the previous step, send a transactions with the validator deposit data as the `data` parameter in your web3 provider such as Metamask to kick things off. Once you make enough deposits, your beacon node will start and your system will begin running the phase 0 beacon chain!
## Running Via Docker
```
docker run -p 4000:4000 -v gcr.io/prysmaticlabs/prysm/beacon-chain:latest \
--rpc-port 4000 \
--demo-config \
--p2p-port 9000
--deposit-contract DEPOSIT_CONTRACT_ADDRESS
```
Then, to run a validator client, use:
@@ -166,35 +139,27 @@ Then, to run a validator client, use:
```
docker run gcr.io/prysmaticlabs/prysm/validator:latest \
--beacon-rpc-provider http://{YOUR_LOCAL_IP}:4000 \
--pubkey f2ee15ea639b73fa3db9b34a245bdfa015c260c598b211bf05a1ecc4b3e3b4f2
--password YOUR_PASSWORD \
--keystore-path /path/to/your/validator/keystore/dir
```
This will connect you to your running beacon node and listen for shard/slot assignments! The beacon node will update you at every cycle transition and shuffle your validator into different shards and slots in order to vote on or propose beacon blocks.
## Running While Connected to a Mainchain Ethereum 1.0 Node
If you want to run the system with a real Web3 endpoint to listen for incoming Ethereum 1.0 block hashes, follow the instructions on setting up a geth node [here](https://github.com/prysmaticlabs/prysm/blob/master/docs/MAINCHAIN.md).
## Running Under Windows
The best way to run under Windows is to clone the repository and then run the node with go run from the Windows command line. Go 1.10 fails due to documented permission errors so be sure you are running Go 1.11 or later. Go through the source code and resolve any dependencies. Create two empty files for use as data directories by the beacon chain and validator respectively. The contents of these files should be deleted each time you run the software. After cloning the Prsym repository, run the node as follows:
```
go run ./beacon-chain main.go \
--datadir /path/to/your/datadir \
--rpc-port 4000 \
--demo-config \
--p2p-port 9000
--deposit-contract DEPOSIT_CONTRACT_ADDRESS
```
After the beacon chain is up and running, run the validator client as a separate process as follows:
```
go run ./validator/main.go \
--beacon-rpc-provider http://localhost:4000 \
--datadir /path/to/uniquevalidatordatadir \
--pubkey f2ee15ea639b73fa3db9b34a245bdfa015c260c598b211bf05a1ecc4b3e3b4f2
--password YOUR_PASSWORD \
--keystore-path /path/to/your/validator/keystore/dir
```
# Testing

2
docs/DEMO_INFORMATION.md
View File

@@ -1,5 +1,7 @@
# Ethereum Serenity Prysm Demo
**IMPORTANT: This document describes our v0.0.0 demo release from October 2018, which is no longer relevant to our current work and is only here for historical purposes**
## Overview & Research Background
At Prysmatic Labs, we started working on Ethereum Serenity all the way back since Vitalik first had a Sharding FAQ as the only reference for the system at the start of 2018. A lot has happened, with the specification evolving from a series of ETHResearch blog posts into a minimal viable blueprint for how to design a scalable, secure Ethereum blockchain using Casper Proof of Stake and Sharding at its core.

73
docs/MAINCHAIN.md
View File

@@ -1,73 +0,0 @@
# Connecting Ethereum Serenity to a Mainchain, Go-Ethereum Node
In order to test out validator registration and synchronize the Ethereum Serenity beacon chain with a proof-of-work, mainchain node, you'll need to initialize your own private Ethereum blockchain as follows:
## Running a Local Geth Node
To start a local Geth node, you can create your own `genesis.json` file similar to:
```json
{
"config": {
"chainId": 12345,
"homesteadBlock": 0,
"eip155Block": 0,
"eip158Block": 0
},
"difficulty": "200",
"gasLimit": "210000000000",
"alloc": {
"826f3F66dB0416ea82033aE917A611bfBF4D98b6": { "balance": "300000" }
}
}
```
The `alloc` portion specifies account addresses with prefunded ETH when the Ethereum blockchain is created. You can modify this section of the genesis to include your own test address and prefund it with 100ETH.
Then, you can build and init a new instance of a local, Ethereum blockchain as follows:
```
geth init /path/to/genesis.json --datadir /path/to/your/datadir
geth --nodiscover console --datadir /path/to/your/datadir --networkid 12345 --ws --wsaddr=127.0.0.1 --wsport 8546 --wsorigins "*" --rpc
````
It is **important** to note that the `--networkid` flag must match the `chainId` property in the genesis file.
Then, the geth console can start up and you can start a miner as follows:
> personal.newAccount()
> miner.setEtherbase(eth.accounts[0])
> miner.start(1)
Now, save the passphrase you used in the geth node into a text file called password.txt.
## Build Our Beacon-Chain + Validator System
Build the beacon chain and validator projects as follows:
```
bazel build //beacon-chain:beacon-chain
bazel build //validator:validator
```
## Deploy a Validator Registation Contract
Deploy the Validator Registration Contract into the chain of the running geth node by following the instructions [here](https://github.com/prysmaticlabs/prysm/blob/master/contracts/deposit-contract/deployContract/README.md).
## Running a Beacon Node as a Validator
Make sure a geth node is running as a separate process according to the instructions from the previous section. Then, you can run a full beacon node as follows:
```
bazel run //beacon-chain --\
--enable-powchain \
--datadir /path/to/your/datadir \
--genesis-json /path/to/your/genesis.json \
--rpc-port 4000 \
--verbosty debug
```
This will spin up a full beacon node that connects to your running geth node, opens up an RPC connection for sharding validators to connect to it, and begins listening for p2p events. Run the system at debug level log verbosity with `--verbosity debug` to see everything happening underneath the hood.
Now, deposit ETH to become a validator in the contract using instructions [here](https://github.com/prysmaticlabs/prysm/blob/master/docs/VALIDATOR_REGISTRATION.md).

2
docs/BEACON_RESEARCH.md → docs/PRIOR_RESEARCH.md
View File

@@ -1,6 +1,6 @@
# Beacon Chain Research Synopsis
This doc will summarize the latest discussions and roadmap updates around integrating Casper/Sharding through a beacon chain and what it means for Ethereum's end-game.
This doc will summarize some historical discussions and roadmap updates around integrating Casper/Sharding through a beacon chain and what it means for Ethereum's end-game.
### Research Notes Leading Up To This

12
docs/READINGS.md
View File

@@ -1,6 +1,6 @@
# Required Readings
This document serves as an outline of the required readings to catch up with and contribute to the sharding implementation for the Ethereum protocol. Whether you are an expert at Ethereum and want to contribute to sharding, or are a beginner and want to take the time to learn the concepts, this will serve as a comprehensive set of readings and links to get you up to speed.
This document serves as an outline of the required readings to catch up with and contribute to the implementation for of the Ethereum 2.0 (Serenity) protocol. Whether you are an expert at Ethereum and want to contribute, or are a beginner and want to take the time to learn the concepts, this will serve as a comprehensive set of readings and links to help you up to speed.
## Required Blockchain & Ethereum Knowledge
@@ -28,11 +28,11 @@ This document serves as an outline of the required readings to catch up with and
- [What is an Ethereum Token?](https://blockgeeks.com/guides/ethereum-token/)
- [What is Ethereum Gas?](https://blockgeeks.com/guides/ethereum-gas-step-by-step-guide/)
- Ethereum Client Implementations
- [Geth](https://github.com/ethereum/go-ethereum) (known also as go-ethereum) is the Golang implementation of the Ethereum protocol
- [Parity](https://github.com/paritytech/parity) the fastest and most performant implementation - written in Rust
- [Trinity](https://github.com/ethereum/py-evm/tree/master/trinity) new project implements Ethereum in Python
- [Cpp-Ethereum](https://github.com/ethereum/cpp-ethereum) a C++ implementation of Ethereum
**Ethereum Client Implementations**
- [Geth](https://github.com/ethereum/go-ethereum) (known also as go-ethereum) is the Golang implementation of the Ethereum protocol
- [Parity](https://github.com/paritytech/parity) the fastest and most performant implementation - written in Rust
- [Trinity](https://github.com/ethereum/py-evm/tree/master/trinity) new project implements Ethereum in Python
- [Cpp-Ethereum](https://github.com/ethereum/cpp-ethereum) a C++ implementation of Ethereum
**Consensus**

148
docs/ROADMAP.md Normal file
View File

@@ -0,0 +1,148 @@
# Prysmatic Labs Roadmap Reference
This document serves as a main reference for Prysmatic Labs' sharding and beacon chain implementation in Go, along with our roadmap and compilation of active research.
# Table of Contents
- [Sharding Introduction](#sharding-introduction)
- [Basic Sharding Idea and Design](#basic-sharding-idea-and-design)
- [Roadmap Phases](#roadmap-phases)
- [The Ruby Release: Local Network](#the-ruby-release-local-network)
- [The Sapphire Release: Goerli Testnet](#the-sapphire-release-goerli-testnet)
- [The Diamond Release: Ethereum Mainnet](#the-diamond-release-ethereum-mainnet)
- [System Architecture](#system-architecture)
- [Acknowledgements](#acknowledgements)
- [References](#references)
# Sharding Introduction
Currently, every single node running the Ethereum network has to process every single transaction that goes through the network. This gives the blockchain a high amount of security because of how much validation goes into each block, but at the same time it means that an entire blockchain is only as fast as its individual nodes and not the sum of its parts. Currently, transactions on the EVM are non-parallelizable, and every transaction is executed in sequence globally. The scalability problem then has to do with the idea that a blockchain can have at most 2 of these 3 properties: decentralization, security, and scalability.
If we have scalability and security, it would mean that our blockchain is centralized and that would allow it to have a faster throughput. Right now, Ethereum is decentralized and secure, but not scalable.
An approach to solving the scalability trilemma is the idea of blockchain sharding, where we split the entire state of the network into partitions called shards that contain their own independent piece of state and transaction history. In this system, certain nodes would process transactions only for certain shards, allowing the throughput of transactions processed in total across all shards to be much higher than having a single shard do all the work as the main chain does now.
## Basic Sharding Idea and Design
A sharded blockchain system is made possible by having nodes store “signed metadata” in the main chain of latest changes within each shard chain. Through this, we manage to create a layer of abstraction that tells us enough information about the global, synced state of parallel shard chains. These messages are called **cross-links**, which are specific structures that encompass important information about blocks in shards across the network. We coordinate these crosslinks on a chain known as a **beacon-chain**. In this chain, blocks are created by actors known as **proposers** that are tasked with information about cross-links together. These blocks are then voted on by a party of actors known as **attesters**. These attesters are randomly selected for particular periods of time in certain shards and are then tasked into reaching consensus on these chains and on beacon chain blocks via a **proof of stake** system. Attesters and proposers are the names of two different responsibilities a participant in Ethereum 2.0 consensus can have. These participants are known in general as **validators**.
Cross-links are stored in blocks on a full proof of stake chain known as a **beacon chain**, which will be implemented as a sidechain to the Ethereum main chain initially.
We still keep the Ethereum main chain and deploy a smart contract into it known as the **Validator Deposit Contract**, where users can deposit and burn 32 ETH. Beacon chain nodes would listen to deposits in this contract and consequently queue up a user with the associated address as a validator in the beacon chain PoS system. Validators then become part of a registered validator set in the beacon chain, and are committees of validators are selected to become attesters or proposers for a certain period of time on shards until they are ventually reshuffled into different shards.
Given that we are splitting up the global state of the Ethereum blockchain into shards, new types of attacks arise because fewer resources are required to completely dominate a shard. This is why a **source of randomness** and periods are critical components to ensuring the integrity of the system.
The Ethereum Wiki’s [Sharding FAQ](https://github.com/ethereum/wiki/wiki/Sharding-FAQ) suggests pseudorandom sampling of validators on each shard. The goal is so that these attesters will not know which shard they will get in advance. Otherwise, malicious actors could concentrate resources into a single shard and try to overtake it (See: [1% Attack](https://medium.com/@icebearhww/ethereum-sharding-and-finality-65248951f649)).
Sharding revolves around being able to store shard metadata in a full proof of stake chain known as a beacon chain. For pseudorandomness generation, a mechanism known as RANDAO can be used in the beacon chain to shuffle validators securely.
# Roadmap Phases
Prysmatic Labs will implement the official beacon chain specification and the full roadmap for Ethereum 2.0 as written in its official repository [here](https://github.com/ethereum/eth2.0-specs) by the community of core researchers and developers in Ethereum.
To roll out these phases, we will be releasing our implementation in a series of steps:
## The Ruby Release: Local Network
Our current work is focused on creating a localized version of a beacon chain that would include the following:
- A minimal, **beacon chain node** that will interact with an Ethereum 1.0 node via JSON-RPC
- A **Validator Deposit Contract** deployed on an Ethereum 1.0 chain where a beacon node can read logs to check for registered validators
- A minimal, floodsub p2p network
- Ability for proposers/attesters to be selected by the beacon chain's randomness into committees that work on specific shards
- Ability to execute state transitions, apply a fork choice rule, and advance a full proof of stake blockchain through distributed consensus
We released our Ruby release on October 2018
## The Sapphire Release: Goerli Testnet
Part 1 of the **Sapphire Release** will focus around getting the **Ruby Release** polished enough to be live on an Ethereum testnet and manage a a beacon chain system.
Part 2 of the **Sapphire Release** will focus on implementing state execution and defining the State Transition Function for sharding on a local testnet (as outlined in [Beyond Phase 1](#beyond-phase-1)) as an extenstion to the Ruby Release.
ETA: End of Q1 2019
## The Diamond Release: Ethereum Mainnet
The **Diamond Release** will reconcile the best parts of the previous releases and deploy a full-featured, cross-shard transaction system through a beacon chain, casper FFG-enabled, sharding release. As expected, this is the most difficult and time consuming release on the horizon for Prysmatic Labs. We plan on growing our community effort significantly over the first few releases to get all hands-on deck preparing for this.
The Diamond Release should be considered the production release candidate for sharding Ethereum on the mainnet.
ETA: To Be determined
# Beacon Chain Phase 0 Implementation
Prysmatic Labs will begin by focusing its implementation entirely on Phase 0 from the Ethereum 2.0 roadmap. We plan on being as pragmatic as possible to create something that can be locally run by any developer as soon as possible. Our initial deliverable will center around a command line tool that will serve as an entry point into a beacon chain node that allows for users to become validators and earn rewrads for participating in Proof of Stake consensus.
Here is a reference spec explaining how our initial system will function:
## System Architecture
Our implementation revolves around the following core components:
- A **beacon chain** that connects to this main chain node via JSON-RPC
- A **validator client** that connects to a beacon node and allows for users to earn rewards for staking 32ETH to secure the protocol
A basic, end-to-end example of the system is as follows:
1. _**User deposits 32 ETH into a Validator Deposit Contract on the Eth 1.0 chain:**_ the beacon chain listens for the logs in the chain to queue that validator into the beacon chain chain's main event loop
2. _**Registered validator begins PoS process to propose blocks:**_ the PoS validator has the resposibility to participate in the addition of new blocks to the beacon chain
3. _**RANDAO mechanism selects committees of proposers/attesters for shards:**_ the beacon chain node will use its RANDAO mechanism to select committees of proposers, attesters that each have responsibilities within the system.
4. _**Beacon Chain State Advances, Committees are Reshuffled:**_ upon completing responsibilities, the different actors of the system are them reshuffled into new committees on different shards.
## The EVM: What You Need to Know
As an important aside, we’ll take a brief detour into the EVM and what we need to understand before we modify it for a sharded blockchain. At its core, the functionality of the EVM optimizes for _security_ and not for computational power with the following restrictions:
- Every single step must be paid for upfront with gas costs to prevent DDoS
- Programs can't interact with each other without a single byte array
- This also means programs can't access other programs' state
- Sandboxed Execution - the EVM can only modify its internal state and nothing else
- Deterministic execution guarantees
So what exactly is the EVM? The EVM was purposely designed to be a stack based machine with memory-byte arrays and key-value stores that are kept on a trie
- Every single keys and storage values are 32 bytes
- There are 100 total opcodes in the EVM
- The EVM comes with a temporary memory byte-array and storage trie to hold persistent memory.
Cryptographic operations are done using pre-compiled contracts. Aside from that, the EVM provides a bunch of blockchain access-level context that allows certain opcodes to fetch useful information from the external system. For example, LOG opcodes store useful information in the log bloom filter that can be synced with light clients. This can be used as a low-gas form of storage, since LOG does not modify the state.
Additionally, the EVM contains a call-depth limit such that recursive invocations or chains of calls will eventually halt, preventing a drastic use of resources.
It is important to note that the merkle root of an Ethereum account is updated any time an `SSTORE` opcode is executed successfully by a program on the EVM that results in a key or value changing in the state merklix (merkle radix) tree.
How is this relevant to sharding? It is important to note the importance of certain opcodes in our implementation and how we will need to introduce and modify several of them for both security and scalability considerations in a sharded chain.
# Acknowledgements
A special thanks for entire [Prysmatic Labs](https://discord.gg/che9auJ) team for helping put this together and to Ethereum Research (Hsiao-Wei Wang, Vitalik, Justin Drake) for the help and guidance in our approach.
# References
[Sharding FAQ](https://github.com/ethereum/wiki/wiki/Sharding-FAQ)
[Sharding Reference Spec](https://github.com/ethereum/sharding/blob/develop/docs/doc.md)
[Data Availability and Erasure Coding](https://github.com/ethereum/research/wiki/A-note-on-data-availability-and-erasure-coding)
[Proof of Visibility for Data Availability](https://ethresear.ch/t/proof-of-visibility-for-data-availability/1073)
[History, State, and Asynchronous Accumulators in the Stateless Model](https://ethresear.ch/t/history-state-and-asynchronous-accumulators-in-the-stateless-model/287)
[Torus Shaped Sharding Network](https://ethresear.ch/t/torus-shaped-sharding-network/1720)
[Data Availability Proof-friendly State Tree Transitions](https://ethresear.ch/t/data-availability-proof-friendly-state-tree-transitions/1453)
[Safety Attester Pool Size](https://ethresear.ch/t/safe-attester-pool-size/1728)
[Fixed Size Deposits and Rewards Penalties Quadleak](https://ethresear.ch/t/fixed-size-deposits-and-rewards-penalties-quad-leak/2073/7)
[Two Ways To Do Cross Links](https://ethresear.ch/t/two-ways-to-do-cross-links/2074/2)
[Extending Minimal Sharding with Cross Links](https://ethresear.ch/t/two-ways-to-do-cross-links/2074/2)
[Leaderless K of N Random Beacon](https://ethresear.ch/t/leaderless-k-of-n-random-beacon/2046/3)

241
docs/SHARDING.md
View File

@@ -1,241 +0,0 @@
# Prysmatic Labs Main Sharding Reference
This document serves as a main reference for Prysmatic Labs' sharding and beacon chain implementation in Go, along with our roadmap and compilation of active research.
# Table of Contents
- [Sharding Introduction](#sharding-introduction)
- [Basic Sharding Idea and Design](#basic-sharding-idea-and-design)
- [Roadmap Phases](#roadmap-phases)
- [The Ruby Release: Local Network](#the-ruby-release-local-network)
- [The Sapphire Release: Ropsten Testnet](#the-sapphire-release-ropsten-testnet)
- [The Diamond Release: Ethereum Mainnet](#the-diamond-release-ethereum-mainnet)
- [Beacon Chain and Sharding Alpha Implementation](#beacon-chain-and-sharding-alpha-implementation)
- [System Architecture](#system-architecture)
- [System Start and User Entrypoint](#system-start-and-user-entrypoint)
- [Attester Sampling](#attester-sampling)
- [Security Considerations](#security-considerations)
- [Not Included in Ruby Release](#not-included-in-ruby-release)
- [Enforced Windback](#enforced-windback)
- [Active Questions and Research](#active-questions-and-research)
- [Acknowledgements](#acknowledgements)
- [References](#references)
# Sharding Introduction
Currently, every single node running the Ethereum network has to process every single transaction that goes through the network. This gives the blockchain a high amount of security because of how much validation goes into each block, but at the same time it means that an entire blockchain is only as fast as its individual nodes and not the sum of its parts. Currently, transactions on the EVM are non-parallelizable, and every transaction is executed in sequence globally. The scalability problem then has to do with the idea that a blockchain can have at most 2 of these 3 properties: decentralization, security, and scalability.
If we have scalability and security, it would mean that our blockchain is centralized and that would allow it to have a faster throughput. Right now, Ethereum is decentralized and secure, but not scalable.
An approach to solving the scalability trilemma is the idea of blockchain sharding, where we split the entire state of the network into partitions called shards that contain their own independent piece of state and transaction history. In this system, certain nodes would process transactions only for certain shards, allowing the throughput of transactions processed in total across all shards to be much higher than having a single shard do all the work as the main chain does now.
## Basic Sharding Idea and Design
A sharded blockchain system is made possible by having nodes store “signed metadata” in the main chain of latest changes within each shard chain. Through this, we manage to create a layer of abstraction that tells us enough information about the global, synced state of parallel shard chains. These messages are called **cross-links**, which are specific structures that encompass important information about the shard blocks (known as **collations**) of a shard in question. Collations are created by actors known as **proposers** that are tasked with packaging transactions into collation bodies. These collations are then voted on by a party of actors known as **attesters**. These attesters are randomly selected for particular periods of time in certain shards and are then tasked into reaching consensus on these chains via a **proof of stake** system.
Cross-links are stored in blocks on a full proof of stake chain known as a **beacon chain**, which will be implemented as a sidechain to the Ethereum main chain initially.
Cross-links are holistic descriptions of the state and transactions on a certain shard. Transactions in a shard are stored in **collations** which contain both a collation header and collation body A collation header at its most basic, high level summary contains information about who created it, when it was added to a shard, and its internal data stored as serialized blobs.
For detailed information on protocol primitives including collations, see: [Protocol Primitives](#protocol-primitives). We will have 2 types of nodes that do the heavy lifting of our sharding logic: **proposers and attesters**. The basic role of proposers is to fetch pending transactions from the txpool, wrap them into collations, grow the shard chains, and submit cross-links to the beacon chain.
We still keep the Ethereum main chain and deploy a smart contract into it known as the **Validator Registration Contract**, where users can deposit and burn 32 ETH. Beacon chain nodes would listen to deposits in this contract and consequently queue up a user with the associated address as a validator in the beacon chain PoS system. Validators then become part of a registered validator set in the beacon chain, and are committees of validators are selected to become attesters on shard chains in certain periods of blocks until they are ventually reshuffled into different shards.
Attesters are in charge of checking for data availability of such collations and reach consensus on canonical shard chains. So then, are proposers in charge of state execution? The short answer is that phase 1 will contain **no state execution**. Instead, proposers will simply package all types of transactions into collations and later down the line, agents known as executors will download, run, and validate state as they need to through possibly different types of execution engines (potentially TrueBit-style, interactive execution).
This separation of concerns between attesters and proposers allows for more computational efficiency within the system, as attesters will not have to do the heavy lifting of state execution and focus solely on consensus through fork-choice rules. In this scheme, it makes sense that eventually **proposers** will become **executors** in later phases of a sharding spec.
Given that we are splitting up the global state of the Ethereum blockchain into shards, new types of attacks arise because fewer resources are required to completely dominate a shard. This is why a **source of randomness** and periods are critical components to ensuring the integrity of the system.
The Ethereum Wiki’s [Sharding FAQ](https://github.com/ethereum/wiki/wiki/Sharding-FAQ) suggests pseudorandom sampling of attesters on each shard. The goal is so that these attesters will not know which shard they will get in advance. Otherwise, malicious actors could concentrate resources into a single shard and try to overtake it (See: [1% Attack](https://medium.com/@icebearhww/ethereum-sharding-and-finality-65248951f649)).
Sharding revolves around being able to store shard metadata in a full proof of stake chain known as a beacon chain. For pseudorandomness generation, a RANDAO mechanism can be used in the beacon chain to shuffle validators securely.
# Roadmap Phases
Prysmatic Labs will implement the beacon chain spec posted on [ETHResearch](https://ethresear.ch/t/convenience-link-to-full-casper-chain-v2-spec/2332) by the Foundation's research team and roll out a sharding validator that communicates with this beacon.
To concretize these phases, we will be releasing our implementation of sharding and the beacon chain as follows:
## The Ruby Release: Local Network
Our current work is focused on creating a localized version of a beacon chain with a sharding system that would include the following:
- A minimal, **beacon chain node** that will interact with a main chain geth node via JSON-RPC
- A **Validator Registration Contract** deployed on the main chain where a beacon node can read logs to check for registered validators
- A minimal, gossipsub shardp2p network
- Ability for proposers/attesters to be selected by the beacon chain's randomness into committees that work on specific shards
- Ability to serialize blobs into collations on shard chains and advance the growth of the shard chains
We will forego several security considerations that will be critical for testnet and mainnet release for the purposes of demonstration and local network testing as part of the Ruby Release (See: [Security Considerations Not Included in Ruby](#not-included-in-ruby-release)).
ETA: To be determined
## The Sapphire Release: Ropsten Testnet
Part 1 of the **Sapphire Release** will focus around getting the **Ruby Release** polished enough to be live on an Ethereum testnet and manage a a beacon chain + sharding system. This will require a lot more elaborate simulations around the safety of the randomness behind the attester assignments in the SMC. Futhermore we need to pass stress testing against DoS and other sorts of byzantine attacks. Additionally, it will be the first release to have real users proposing collations concurrently with attesters reaching consensus on these collations, alongside beacon node validators producing blocks via PoS.
Part 2 of the **Sapphire Release** will focus on implementing state execution and defining the State Transition Function for sharding on a local testnet (as outlined in [Beyond Phase 1](#beyond-phase-1)) as an extenstion to the Ruby Release.
ETA: To be determined
## The Diamond Release: Ethereum Mainnet
The **Diamond Release** will reconcile the best parts of the previous releases and deploy a full-featured, cross-shard transaction system through a beacon chain, casper FFG-enabled, sharding release. As expected, this is the most difficult and time consuming release on the horizon for Prysmatic Labs. We plan on growing our community effort significantly over the first few releases to get all hands-on deck preparing for this.
The Diamond Release should be considered the production release candidate for sharding Ethereum on the mainnet.
ETA: To Be determined
# Beacon Chain and Sharding Alpha Implementation
Prysmatic Labs will begin by focusing its implementation entirely on the **Ruby Release** from our roadmap. We plan on being as pragmatic as possible to create something that can be locally run by any developer as soon as possible. Our initial deliverable will center around a command line tool that will serve as an entrypoint into a beacon chain node that allows users to become attesters/proposers, and to manage the growth of shard chains.
Here is a reference spec explaining how our initial system will function:
## System Architecture
Our implementation revolves around the following core components:
- A **main chain node** that spins up an instance of the Ethereum blockchain and mines on the Proof of Work chain
- A **beacon chain** that connects to this main chain node via JSON-RPC
- A **shardp2p system** that allows nodes to reshuffle across shard networks
A basic, end-to-end example of the system is as follows:
1. _**User deposits 32 ETH into a Validator Registration Contract on the main chain:**_ the beacon chain listens for the logs in the main chain to queue that validator into the beacon chain's main event loop
2. _**Registered validator begins PoS process to propose blocks:**_ the PoS validator has the resposibility to participate in the addition of new blocks to the beacon chain
3. _**RANDAO mechanism selects committees of proposers/attesters/attesters for shards:**_ the beacon chain node will use its RANDAO mechanism to select committees of proposers and attesters, each with their own responsibilities within the sharding system. Refer to the [Full Casper Chain V2 Doc](https://ethresear.ch/t/convenience-link-to-full-casper-chain-v2-spec/2332) for extensive detail on the different fields in the state of the beacon chain related to sharding
4. _**Beacon Chain State Advances, Committees are Reshuffled:**_ upon completing responsibilities, different actors of the sharding system are then reshuffled into new committees on different shards
## System Start and User Entrypoint
Our Ruby Release requires users to start a local geth node running a localized, private blockchain to deploy the **Validator Registration Contract**. This will kickstart the entire beacon chain sync process and listen for registrations of validators in the main chain VRC. The beacon node starts its main loop, which involves the following steps:
1. _**Sync to the latest block header on the beacon chain:**_ the node will begin a sync process for the beacon chain
2. _**Assign the validator as a proposer/attester/attester based on RANDAO mechanism:**_ on incoming headers, the validator will interact with the SMC to check if the current user is an eligible attester for an upcoming period (only a few minutes notice)
3. _**Process shard cross-links:**_ once an attester node is selected, it has to download subimtted collation headers for the shard in a certain period and check for their data availability
5. _**Reshuffle committees**_ the attester votes on the available collation header that came first in the submissions.
6. _**Propose blocks and finalize incoming blocks via PoS:**_ Once attesters vote, headers that received >=2/3 votes are selected as canonical
## Attester Sampling
The probability of being selected as an attester on a particular shard is being heavily researched in the latest ETHResearch discussions. As specified in the [Sharding FAQ](https://github.com/ethereum/wiki/wiki/Sharding-FAQ) by Vitalik, “if validators [collators] could choose, then attackers with small total stake could concentrate their stake onto one shard and attack it, thereby eliminating the system’s security.”
The idea is that attesters should not be able to figure out which shard they will become attesters of and during which period they will be assigned with anything more than a few minutes notice.
Ideally, we want attesters to shuffle across shards very rapidly and through a source of pseudorandomness built in-protocol.
Despite its benefits, random sampling does not help in a bribing, coordinated attack model. In Vitalik’s own words:
_"Either the attacker can bribe the great majority of the sample to do as the attacker pleases, or the attacker controls a majority of the sample directly and can direct the sample to perform arbitrary actions at low cost (O(c) cost, to be precise).
At that point, the attacker has the ability to conduct 51% attacks against that sample. The threat is further magnified because there is a risk of cross-shard contagion: if the attacker corrupts the state of a shard, the attacker can then start to send unlimited quantities of funds out to other shards and perform other cross-shard mischief. All in all, security in the bribing attacker or coordinated choice model is not much better than that of simply creating O(c) altcoins.”_
However, this problem transcends the sharding scheme itself and goes into the broader problem of fraud detection, which we have yet to comprehensively address.
## The EVM: What You Need to Know
As an important aside, we’ll take a brief detour into the EVM and what we need to understand before we modify it for a sharded blockchain. At its core, the functionality of the EVM optimizes for _security_ and not for computational power with the following restrictions:
- Every single step must be paid for upfront with gas costs to prevent DDoS
- Programs can't interact with each other without a single byte array
- This also means programs can't access other programs' state
- Sandboxed Execution - the EVM can only modify its internal state and nothing else
- Deterministic execution guarantees
So what exactly is the EVM? The EVM was purposely designed to be a stack based machine with memory-byte arrays and key-value stores that are kept on a trie
- Every single key and storage value are 32 bytes
- There are 100 total opcodes in the EVM
- The EVM comes with a temporary memory byte-array and storage trie to hold persistent memory.
Cryptographic operations are done using pre-compiled contracts. Aside from that, the EVM provides a bunch of blockchain access-level context that allows certain opcodes to fetch useful information from the external system. For example, LOG opcodes store useful information in the log bloom filter that can be synced with light clients. This can be used as a low-gas form of storage, since LOG does not modify the state.
Additionally, the EVM contains a call-depth limit such that recursive invocations or call chains will eventually halt, preventing a drastic use of resources.
It is important to note that the merkle root of an Ethereum account is updated any time an `SSTORE` opcode is executed successfully by a program on the EVM that results in a key or value changing in the state merklix (merkle radix) tree.
How is this relevant to sharding? It is important to note the importance of certain opcodes in our implementation and how we will need to introduce and modify several of them for both security and scalability considerations in a sharded chain.
# Security Considerations
## Not Included in Ruby Release
We will not be considering data availability proofs (part of the stateless client model) as part of the Ruby release, we will not be implementing them just yet as they are an area of active research.
Additionally, we will be using simple blockhashes for randomness in committee selections instead of a full RANDAO mechanism.
## Enforced Windback
When attesters are extending shard chains, it is critical that they are able to verify some of the collation headers in the immediate past for security purposes. There have already been instances where mining blindly has led to invalid transactions that forced Bitcoin to undergo a fork (See: [BIP66 Incident](https://bitcoin.stackexchange.com/questions/38437/what-is-spv-mining-and-how-did-it-inadvertently-cause-the-fork-after-bip66-wa)).
This process of checking previous blocks is known as **“windback”**. In a [post](https://ethresear.ch/t/enforcing-windback-validity-and-availability-and-a-proof-of-custody/949) by Justin Drake on ETHResearch, he outlines that this is necessary for security, but is counterintuitive to the end-goal of scalability as this obviously imposes more computational and network constraints on nodes.
One way to enforce **validity** during the windback process is for nodes to produce zero-knowedge proofs of validity that can then be stored in collation headers for quick verification.
On the other hand, to enforce **availability** for the windback process, a possible approach is for nodes to produce “proofs of custody” in collation headers that prove the attester was in possession of the full data of a collation when produced. Drake proposes a constant time, non-interactive zkSNARK method for attesters to check these proofs of custody. In his construction, he mentions splitting up a collation body into “chunks” that are then mixed with the node's private key through a hashing scheme. The security in this relies in the idea that a node would not leak his/her private key without compromising him or herself, so it provides a succinct way of checking if the full data was available when a node processed the collation body and proof was created.
# Active Questions and Research
## Leaderless Random Beacons
In the prevous research on random beacons, committees are able to generate random numbers if a certain number of participants participate correctly. This is similar to the random beacon used in Dfinity without the use of BLS threshold signatures. The scheme is separated into two separate sections.
In the first section, each participant is committed to a secret key and shares the resulting public key.
In the second section, each participant will use their secret key to deterministically build a polynomial and that polynomial is used to to create n shares (where n is the size of the committee) which can then be encrypted with respect to the public keys and then shared publicly.
Then, in the resolution, all participants are then to reveal their private keys, once the key is revealed anyone can check if the participant committed correctly. We can define the random output as the sum of the private keys for which the participants committed correctly.
<https://ethresear.ch/t/leaderless-k-of-n-random-beacon/2046/3>
## Torus-shaped Sharded P2P Network
One recommendation is using a [Torus-shaped sharding network](https://commons.wikimedia.org/wiki/File:Toroidal_coord.png). In this paradigm, there would be a single network that all shards share rather than a network for each shard. Nodes would propagate messages to peers interested in neighboring shards. A node listening on shard 16 would relay messages for shards in range of 11 to 21 (i.e +/-5). Nodes that need to listen on multiple shards can quickly change shards to find peers that may relay necessary messages. A node could potentially have access to messages from all shards with only 10 distinct peers for a 100 shard network. At the same time, we're considering replacing [DEVp2p](https://github.com/ethereum/wiki/wiki/%C3%90%CE%9EVp2p-Wire-Protocol) with [libp2p](https://github.com/libp2p) framework, which is actively maintained, proven to work with IPFS, and comes with client libraries for Go and Javascript.
Active research is on going for moving Ethereum from DEVp2p to libp2p. We are looking into how to map shards to libp2p and how to balance flood/gossipsub progagation vs active connections. Here is the current work of [poc](https://github.com/mhchia/go-libp2p/tree/poc-testing/examples/minimal) on [gossiphub](https://github.com/libp2p/go-floodsub/pull/67/). It utilizies pubsub for propagating messages such as transactions, proposals and sharded collations.
<https://ethresear.ch/t/torus-shaped-sharding-network/1720>
## Sparse Merkle Tree for State Storage
With a sharded network comes sharded state storage. State sync today is difficult for clients. While the blockchain data stored on disk might use ~80gb for a fast sync, less than 5gb of that disk is state data while state sync accounts for the majority of time spent syncing. As the state grows, this issue will also grow. We imagine that it might be difficult to sync effectively when there are 100 shards and 100 different state tries. One recommendation from the Ethereum Research team outlines using [sparse merkle trees].(https://www.links.org/files/RevocationTransparency.pdf)
<https://ethresear.ch/t/data-availability-proof-friendly-state-tree-transitions/1453>
# Acknowledgements
A special thanks for entire [Prysmatic Labs](https://discord.gg/che9auJ) team for helping put this together and to Ethereum Research (Hsiao-Wei Wang, Vitalik, Justin Drake) for the help and guidance in our approach.
# References
[Sharding FAQ](https://github.com/ethereum/wiki/wiki/Sharding-FAQ)
[Sharding Reference Spec](https://github.com/ethereum/sharding/blob/develop/docs/doc.md)
[Data Availability and Erasure Coding](https://github.com/ethereum/research/wiki/A-note-on-data-availability-and-erasure-coding)
[Proof of Visibility for Data Availability](https://ethresear.ch/t/proof-of-visibility-for-data-availability/1073)
[History, State, and Asynchronous Accumulators in the Stateless Model](https://ethresear.ch/t/history-state-and-asynchronous-accumulators-in-the-stateless-model/287)
[Torus Shaped Sharding Network](https://ethresear.ch/t/torus-shaped-sharding-network/1720)
[Data Availability Proof-friendly State Tree Transitions](https://ethresear.ch/t/data-availability-proof-friendly-state-tree-transitions/1453)
[Safety Attester Pool Size](https://ethresear.ch/t/safe-attester-pool-size/1728)
[Fixed Size Deposits and Rewards Penalties Quadleak](https://ethresear.ch/t/fixed-size-deposits-and-rewards-penalties-quad-leak/2073/7)
[Two Ways To Do Cross Links](https://ethresear.ch/t/two-ways-to-do-cross-links/2074/2)
[Extending Minimal Sharding with Cross Links](https://ethresear.ch/t/two-ways-to-do-cross-links/2074/2)
[Leaderless K of N Random Beacon](https://ethresear.ch/t/leaderless-k-of-n-random-beacon/2046/3)

43
docs/VALIDATOR_REGISTRATION.md
View File

@@ -1,43 +0,0 @@
# Validator Registration Workflow
This doc summarizes the work flow of registering to become a validator in the beacon chain. The scope is within Ruby Release.
### Step 1: Deploy Validator Registration Contract on Mainchain
To deploy VRC, we can use [deployVRC](https://github.com/terenc3t/geth-sharding/tree/contract-util/contracts/deployVRC) utility.
Once we get the VRC contract address, we can launch our beacon chain node
```
# Deploy VRC with keystore UTCJSON and password
go run deployVRC.go --UTCPath /path/to/your/keystore/UTCJSON --passwordFile /path/to/your/password.txt
# Deploy VRC with private key
go run deployVRC.go --privKey 8a6db3b30934439c9f71f1fa777019810fd538c9c1e396809bcf9fd5535e20ca
INFO[0039] New contract deployed at 0x559eDab2b5896C2Bc37951325666ed08CD41099d
```
### Step 2: Launch Beacon Chain Node
Launch beacon chain node with account holder's public key and the VRC address we just deployed
```
bazel run //beacon-chain --\
--vrcaddr 0x527580dd995c0ab81d01f9993eb39166796877a1 \
--pubkey aaace816cdab194b4bc6c0de3575ccf917a9b9ecfead263720968e0e1b45739c \
--web3provider ws://127.0.0.1:8546 \
--datadir /path/to/your/datadir \
--rpc-port 4000 \
```
### Step 3: Deposit 32 ETH
Send a transaction to the deposit function in VRC with 32 ETH and beacon chain node account holder's public key as argument.
Since the signature scheme and the logic to do the actual signing and validating isn't there yet, it's ok to use a random byte32 as pub key
as long as pub key matches the one you used to launch beacon chain node. (ex: aaace816cdab194b4bc6c0de3575ccf917a9b9ecfead263720968e0e1b45739c)
### Step 4: Wait for Deposit Tx Block to be Mined
After the deposit transaction gets mined, beacon chain node will report account holder has been registered. Congrats! Now, you are contributing to the security of Ethereum Serenity
```
INFO[0000] Starting beacon node
INFO[0000] Starting web3 PoW chain service at ws://127.0.0.1:8546
INFO[0152] Validator registered in VRC with public key: aaace816cdab194b4bc6c0de3575ccf917a9b9ecfead263720968e0e1b45739c
```

3
proto/beacon/p2p/v1/messages.pb.go generated
View File

@@ -5,9 +5,10 @@ package ethereum_beacon_p2p_v1
import (
fmt "fmt"
proto "github.com/gogo/protobuf/proto"
io "io"
math "math"
proto "github.com/gogo/protobuf/proto"
)
// Reference imports to suppress errors if they are not otherwise used.

5
proto/beacon/p2p/v1/types.pb.go generated
View File

@@ -5,10 +5,11 @@ package ethereum_beacon_p2p_v1
import (
fmt "fmt"
proto "github.com/gogo/protobuf/proto"
_ "github.com/prysmaticlabs/prysm/proto/common"
io "io"
math "math"
proto "github.com/gogo/protobuf/proto"
_ "github.com/prysmaticlabs/prysm/proto/common"
)
// Reference imports to suppress errors if they are not otherwise used.

5
proto/beacon/rpc/v1/services.pb.go generated
View File

@@ -6,12 +6,13 @@ package ethereum_beacon_rpc_v1
import (
context "context"
fmt "fmt"
io "io"
math "math"
proto "github.com/gogo/protobuf/proto"
types "github.com/gogo/protobuf/types"
v1 "github.com/prysmaticlabs/prysm/proto/beacon/p2p/v1"
grpc "google.golang.org/grpc"
io "io"
math "math"
)
// Reference imports to suppress errors if they are not otherwise used.

3
proto/cluster/services.pb.go generated
View File

@@ -6,9 +6,10 @@ package prysm_internal_cluster
import (
context "context"
fmt "fmt"
math "math"
proto "github.com/golang/protobuf/proto"
grpc "google.golang.org/grpc"
math "math"
)
// Reference imports to suppress errors if they are not otherwise used.

3
proto/common/messages.pb.go generated
View File

@@ -5,9 +5,10 @@ package ethereum_common
import (
fmt "fmt"
proto "github.com/gogo/protobuf/proto"
io "io"
math "math"
proto "github.com/gogo/protobuf/proto"
)
// Reference imports to suppress errors if they are not otherwise used.

5
proto/faucet/faucet.pb.go generated
View File

@@ -6,10 +6,11 @@ package faucet
import (
context "context"
fmt "fmt"
proto "github.com/gogo/protobuf/proto"
grpc "google.golang.org/grpc"
io "io"
math "math"
proto "github.com/gogo/protobuf/proto"
grpc "google.golang.org/grpc"
)
// Reference imports to suppress errors if they are not otherwise used.

3
proto/sharding/p2p/v1/messages.pb.go generated
View File

@@ -5,9 +5,10 @@ package ethereum_sharding_p2p_v1
import (
fmt "fmt"
proto "github.com/gogo/protobuf/proto"
io "io"
math "math"
proto "github.com/gogo/protobuf/proto"
)
// Reference imports to suppress errors if they are not otherwise used.

5
proto/testing/test.pb.go generated
View File

@@ -5,10 +5,11 @@ package ethereum_testing
import (
fmt "fmt"
proto "github.com/gogo/protobuf/proto"
types "github.com/gogo/protobuf/types"
io "io"
math "math"
proto "github.com/gogo/protobuf/proto"
types "github.com/gogo/protobuf/types"
)
// Reference imports to suppress errors if they are not otherwise used.