fix command mistake and enable geth websocket server for beacon node
7.1 KiB
Prysmatic Labs Ethereum 2.0 Implementation
This is the main repository for the beacon chain and sharding implementation for Ethereum 2.0 Prysmatic Labs.
Before you begin, check out our Contribution Guidelines and join our active chat room on Discord or Gitter below:
Also, read our Sharding Reference Implementation Doc. This doc provides a background on the sharding implementation we follow at Prysmatic Labs.
Table of Contents
Installation
Create a folder in your $GOPATH
and navigate to it
mkdir -p $GOPATH/src/github.com/prysmaticlabs && cd $GOPATH/src/github.com/prysmaticlabs
Note: it is not necessary to clone to the gopath if you're only building with Bazel.
Clone our repository:
git clone https://github.com/prysmaticlabs/prysm
Download the Bazel build tool by Google here and ensure it works by typing
bazel version
Bazel manages all of the dependencies for you (including go and necessary compilers) so you are all set to build prysm.
Instructions
To get started with running the project, follow the instructions to initialize your own private Ethereum blockchain and geth node, as they will be required to run before you can begin running our system
Running a Local Geth Node
To start a local Geth node, you can create your own genesis.json
file similar to:
{
"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 "*"
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. Then, once you have this private geth node running on your local network, we will need to generate test, pending transactions that can then be processed into collations by proposers. For this, we have created an in-house transaction generator CLI tool.
Running Ethereum 2.0
NOTE: This section is in flux, much of this will likely change as the beacon chain spec evolves.
Build our system first
bazel build //...
Step 1: Deploy a Validator Registation Contract
Deploy the Validator Registration Contract into the chain of the running geth node by following the instructions here.
Step 2: Running a Beacon Node
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 --\
--web3provider ws://127.0.0.1:8546 \
--datadir /path/to/your/datadir \
--rpc-port 4000
This will spin up a full beacon node that connects to your running geth node, opens up an RPC connection for sharding clients to connect to it, and begins listening for p2p events.
To try out the beacon node in development by simulating incoming blocks, run the same command above but enable the --simulator
and a debug level, log verbosity with --verbosity debug
to see everything happening underneath the hood.
bazel run //beacon-chain --\
--web3provider ws://127.0.0.1:8546 \
--datadir /path/to/your/datadir \
--rpc-port 4000 \
--simulator \
--verbosity debug
Now, deposit ETH to become a validator in the contract using instructions here
Step 3: Running a Sharding Client
Once your beacon node is up, you'll need to attach a sharding client as a separate process. This client is in charge of running attester/proposer responsibilities and handling shards (shards to be designed in phase 2). This client will listen for incoming beacon blocks and crystallized states and determine when its time to perform attester/proposer responsibilities accordingly.
Run as follows:
bazel run //client --\
--beacon-rpc-provider http://localhost:4000 \
--verbosity debug
Then, the beacon node will update this client with new blocks + crystallized states in order for the client to act as an attester or proposer.
Running via Docker
To run the client within a docker container, use the //client:image
target.
bazel run //client:image
INFO: Build options have changed, discarding analysis cache.
INFO: Analysed target //client:image (306 packages loaded).
INFO: Found 1 target...
Target //client:image up-to-date:
bazel-bin/client/image-layer.tar
INFO: Elapsed time: 8.568s, Critical Path: 0.22s
INFO: 0 processes.
INFO: Build completed successfully, 1 total action
INFO: Build completed successfully, 1 total action
37fd88e7190b: Loading layer 22.42MB/22.42MB
Loaded image ID: sha256:89b233de1a026eddeeff010fa1ef596ce791cb3f26488150aac72a91b80734c1
Tagging 89b233de1a026eddeeff010fa1ef596ce791cb3f26488150aac72a91b80734c1 as bazel/client:image
...
TODO: Add container_push targets for the container images such that they can be pulled from GCR or dockerhub.
Testing
To run the unit tests of our system do:
bazel test //...
To run our linter, make sure you have gometalinter installed and then run
gometalinter ./...
Contributing
We have put all of our contribution guidelines into CONTRIBUTING.md! Check it out to get started.