mirror of
https://github.com/status-im/nimbus-eth2.git
synced 2025-02-02 01:36:06 +00:00
important book updates (#1561)
* book updates * save progress * save progress * work on deposit data section + edits * title edit * minor edits * edits and clarifications * add images, launchpad steps, and a note on expected wait time * add images + edits * restructure, simplify, edits * faq corrections * rework intro: cp * update intro and faq * add note on requestiong goerli eth * typo fix * add numbers to steps in walletstore guide" * chapter 8 title: replace Nimbus with NBC * Update docs/the_nimbus_book/src/medalla.md Co-authored-by: Jacek Sieka <jacek@status.im> Co-authored-by: Jacek Sieka <jacek@status.im>
This commit is contained in:
Sacha Saint-Leger
GitHub
parent
a7a279d615
commit
0edacfef40
@ -1,13 +1,14 @@
|
||||
# Summary
|
||||
|
||||
- [Introduction](./intro.md)
|
||||
- [Installation](./install.md)
|
||||
- [Become a Medalla validator](./medalla.md)
|
||||
- [Run the beacon node](./beacon_node.md)
|
||||
- [Wallet and deposit tools](./create_wallet_and_deposit.md)
|
||||
- [Become a validator (custom)](./validator.md)
|
||||
- [API](./api.md)
|
||||
- [Advanced usage for developers](./advanced.md)
|
||||
- [Setting up a systemd service](./beacon_node_systemd.md)
|
||||
- [FAQs](./faq.md)
|
||||
# Advanced
|
||||
- [For developers](./advanced.md)
|
||||
- [Set up a systemd service](./beacon_node_systemd.md)
|
||||
- [Generate your keys with Nimbus](./create_wallet_and_deposit.md)
|
||||
# Misc
|
||||
- [Windows users]()
|
||||
- [FAQ](./faq.md)
|
||||
- [Contribute](./contribute.md)
|
||||
|
||||
@ -23,9 +23,7 @@ mingw32-make # this first invocation will update the Git submodules
|
||||
mingw32-make fetch-dlls # this will place the right DLLs for your architecture in the "build/" directory
|
||||
```
|
||||
|
||||
> If you were following the Windows testnet instructions, you can jump back to [Connecting to testnets](#connecting-to-testnets) now
|
||||
|
||||
You can now follow those instructions in the previous section by replacing `make` with `mingw32-make` (regardless of your 32-bit or 64-bit architecture):
|
||||
You can now follow the instructions in this this book by replacing `make` with `mingw32-make` (you should run `mingw32` regardless of whether you're running 32-bit or 64-bit architecture):
|
||||
|
||||
```bash
|
||||
mingw32-make test # run the test suite
|
||||
|
||||
@ -1,7 +1,8 @@
|
||||
# APIs
|
||||
|
||||
NBC exposes API:s for querying the state of the application at runtime.
|
||||
NBC exposes a collection of APIs for querying the state of the application at runtime.
|
||||
|
||||
:note: Where applicable, this API mimics https://github.com/ethereum/eth2.0-APIs with the exception that JSON-RPC is used instead of http rest - method names, parameters and results are equivalent except for the encoding / access method.
|
||||
> **Note:** Where applicable, these APIs mimic the [eth2 APIs](https://github.com/ethereum/eth2.0-APIs) with the exception that JSON-RPC is used instead of http rest (the method names, parameters and results are all the same except for the encoding / access method).
|
||||
|
||||
## Introduction
|
||||
|
||||
|
||||
@ -2,17 +2,34 @@
|
||||
|
||||
The beacon node application connects to the eth2 network, manages the blockchain, and provides API's to interact with the beacon chain.
|
||||
|
||||
You can run the beacon node without being a validator - doing so allows you to sync the network and access its latest state.
|
||||
You can **run the beacon node without being a validator** - doing so allows you to sync the network and access its latest state.
|
||||
|
||||
## Prerequisites
|
||||
|
||||
Before compiling and running the application, make sure you've gone through the [installation guidelines](./install.md).
|
||||
Before building and running the application, make sure you've gone through the [installation guidelines](./install.md).
|
||||
|
||||
## Building the node
|
||||
|
||||
To build the beacon run:
|
||||
|
||||
#### 1. Clone the nim beacon chain repository
|
||||
|
||||
```
|
||||
git clone https://github.com/status-im/nim-beacon-chain
|
||||
cd nim-beacon-chain
|
||||
```
|
||||
|
||||
#### 2. Run the beacon node build process
|
||||
|
||||
```
|
||||
make beacon_node
|
||||
```
|
||||
|
||||
## Running the node
|
||||
|
||||
When running the beacon node, you connect to a specific ethereum 2 network - this may be a private network or a public testnet like [Medalla](https://github.com/goerli/medalla/).
|
||||
|
||||
When running the node for the first time, you need to specify network parameters, boot nodes and genesis information. This information can typically be found in the [eth2 testnets](https://github.com/eth2-clients/eth2-testnets) repository. This information is automatically downloaded when using the simplified startup.
|
||||
> **Note:** when running the node for the first time, you may need to specify network parameters, boot nodes and genesis information. This information can typically be found in the [eth2 testnets](https://github.com/eth2-clients/eth2-testnets) repository.
|
||||
|
||||
Once the beacon node is running, it will first connect to the boot nodes in the network, look for more peers and start syncing the chain. Once the sync is complete, it will keep following the head of the chain (you can interact with it through the [API](./api.md).
|
||||
|
||||
@ -23,15 +40,6 @@ Before running the beacon node, it's important that your computer is set to the
|
||||
To start syncing the `medalla` network:
|
||||
|
||||
|
||||
#### 1. Clone the nim beacon chain repository
|
||||
|
||||
```
|
||||
git clone https://github.com/status-im/nim-beacon-chain
|
||||
cd nim-beacon-chain
|
||||
```
|
||||
|
||||
#### 2. Run the build process
|
||||
|
||||
```
|
||||
make medalla
|
||||
|
||||
@ -64,7 +72,7 @@ Time is shown as `epoch:subslot`, starting from the block chain genesis time - o
|
||||
The status bar content may be updated using command line flags.
|
||||
|
||||
### Metrics
|
||||
Nimbus includes metrics support using the Prometheus format. To enable it, you need to enable insecure feature when compiling the application. The http server that exports Prometheus metrics should not be exposed to external parties.
|
||||
Nimbus includes metrics support using the Prometheus format. To enable it, you need to enable the insecure feature when compiling the application. The http server that exports Prometheus metrics should not be exposed to external parties.
|
||||
|
||||
```
|
||||
# Compile with insecure features enabled
|
||||
@ -206,7 +214,3 @@ beacon_node_shared_medalla_0 wallets list
|
||||
|
||||
Lists details about all wallets.
|
||||
```
|
||||
|
||||
## Next steps
|
||||
|
||||
Once you're synced, you can move on to become a [validator](./validator.md).
|
||||
|
||||
@ -1,46 +1,186 @@
|
||||
# Create a walletstore and make a deposit
|
||||
# Generate your keys with NBC
|
||||
|
||||
In this page we'll take you through how to create a walletstore and make a deposit (from now on we'll use the terms wallet and walletstore interchangeably)
|
||||
In this chapter, we'll take you through how to create an [EIP-2386](https://github.com/ethereum/EIPs/blob/4494da0966afa7318ec0157948821b19c4248805/EIPS/eip-2386.md) wallet to help you generate your validator keys (keystores), create a `deposits_data` file compatible with the Ethereum Foundation's [Validator Launchpad](https://medalla.launchpad.ethereum.org/), and use the launchpad to send this data to the eth1 network so that your validator can be registered.
|
||||
|
||||
First, we'll create a wallet.
|
||||
|
||||
> For our purposes, a wallet is the [EIP-2386](https://github.com/ethereum/EIPs/blob/4494da0966afa7318ec0157948821b19c4248805/EIPS/eip-2386.md) JSON file which contains an encrypted seed, a name, and a counter (`nextaccount`) that allows for creating validators (generating keystores) incrementally as outlined in [EIP-2334](https://eips.ethereum.org/EIPS/eip-2334) (Deterministic Account Hierarchy).
|
||||
> **Note:** this page is primarily aimed at users who wish to run multiple validators on several machines. If you simply wish to get one validator up and running with Nimbus, or run several validators on a single machine, we recommend following our [become a Medalla validator](./medalla.md) guide instead.
|
||||
|
||||
The wallet we'll create will be [hierarchical deterministic](https://github.com/ethereum/EIPs/blob/4494da0966afa7318ec0157948821b19c4248805/EIPS/eip-2386.md).
|
||||
|
||||
An HD wallet can create keys from a *seed* and a *path*. The encrypted seed is stored in the wallet (it needs to be accessible to create new keys). Further, HD wallets also have a mechanism (a `nextaccount` index) for maintaining state about which keys have been generated (to ensure keys are not duplicated).
|
||||
For our purposes, a wallet is the [EIP-2386](https://github.com/ethereum/EIPs/blob/4494da0966afa7318ec0157948821b19c4248805/EIPS/eip-2386.md) JSON file which contains an encrypted seed, a name, and a counter (`nextaccount`) that allows for generating validator keystores incrementally as outlined in [EIP-2334](https://eips.ethereum.org/EIPS/eip-2334) (Deterministic Account Hierarchy). It's sometimes referred to as a wallestore.
|
||||
|
||||
## When do I need to use a walletstore?
|
||||
Such a wallet can create (and restore) keys from a *seed* and a *path*. The encrypted seed is stored in the wallet (it needs to be accessible to create new keys). Further, the wallet also has a mechanism (a `nextaccount` index) for maintaining state about which keys have been generated (to help ensure you don't duplicate a key by accident).
|
||||
|
||||
|
||||
|
||||
## When do I need to use a wallet?
|
||||
|
||||
If you're asking yourself this question then you probably don't need to use one :)
|
||||
|
||||
To be clear, the purpose of a walletstore is to generate new validators. But you don't need a walletstore to do this.
|
||||
To be clear, the purpose of such a wallet is to help you generate your keystores (and keep track of how many you've generated). But you don't need a wallet to do this.
|
||||
|
||||
You can use the Ethereum Foundation's [launchpad](https://medalla.launchpad.ethereum.org/) or [deposit-cli](https://github.com/ethereum/eth2.0-deposit-cli) to do this without a walletstore.
|
||||
> **Tip:** You can use tools like the Ethereum Foundation's [deposit-cli](https://github.com/ethereum/eth2.0-deposit-cli) to generate keystores without a wallet. In fact, we recommend this approach if you're not sure whether or not you need a wallet.
|
||||
|
||||
## Prerequisites
|
||||
|
||||
You need to have installed Nimbus' [external dependencies](./install.md#external-dependencies) and [built the beacon node](./beacon_node.md#building-the-node).
|
||||
|
||||
|
||||
## 1. Create a wallet
|
||||
|
||||
Run the following command from the the home directory of the `nim-beacon-chain` repository to launch the command line interface app:
|
||||
|
||||
## Create a wallet
|
||||
```
|
||||
build/beacon_node wallets create
|
||||
```
|
||||
|
||||
*TO BE FILLED*
|
||||
Now follow the instructions presented to you in the terminal window to create your wallet.
|
||||
|
||||
## Create a deposit
|
||||
```
|
||||
build/beacon_node deposits create
|
||||
```bash
|
||||
Wallet id: <YOUR_WALLET_ID>
|
||||
INF 2020-08-18 11:05:47.126+02:00 Wallet file written
|
||||
tid=137382
|
||||
file=keystore_management.nim:404
|
||||
path="<WHERE_YOUR_WALLET_IS_SAVED>"
|
||||
```
|
||||
|
||||
*TO BE FILLED*
|
||||
At the end of the process, you should see the above message printed to the terminal. Make sure to keep track of your wallet id, and path.
|
||||
|
||||
*Creates a deposits_data file that should be compatible with the new Ethereum Launchpad.*
|
||||
### Available options
|
||||
|
||||
- creates wallet
|
||||
- generates deposits
|
||||
- writes to deposit_data file
|
||||
To see a list of the options/flags available, run:
|
||||
```bash
|
||||
build/beacon_node wallets create --help
|
||||
```
|
||||
|
||||
> Note: when you create deposits with `deposits create`, you can reference an existing wallet or you can create a new one which will guide through the standard wallets create procedure.
|
||||
You should see the following:
|
||||
|
||||
## Which keys do i pass to my validator client?
|
||||
```
|
||||
The following options are available:
|
||||
|
||||
--next-account Initial value for the 'nextaccount' property of the wallet.
|
||||
--name An easy-to-remember name for the wallet of your choice.
|
||||
--out Output wallet file.
|
||||
```
|
||||
|
||||
## 2. Create a keystore and signed deposit
|
||||
|
||||
To generate 1 keystore and create a `deposit_data` JSON file using an existing wallet, run:
|
||||
```bash
|
||||
build/beacon_node deposits create --wallet="<YOUR_WALLET_ID>" --count=1
|
||||
```
|
||||
> **Tip:** To find your wallet id, look at your terminal history. You should see it printed right after you created your wallet. It's also saved in the `uuid` field of your wallet (remember your wallet is simply a JSON file).
|
||||
|
||||
Enter your password to unlock your wallet, create your signing keystore, and generate a `deposit_data` file.
|
||||
|
||||
```bash
|
||||
INF 2020-08-19 13:53:24.271+02:00 Generating deposits
|
||||
tid=330637
|
||||
file=keystore_management.nim:143
|
||||
totalValidators=2
|
||||
validatorsDir=validators
|
||||
secretsDir=secrets
|
||||
|
||||
INF 2020-08-19 13:53:24.286+02:00 Deposit data written
|
||||
topics="beacnde" tid=330637
|
||||
file=beacon_node.nim:1406
|
||||
filename=validators/deposit_data-1597838004.284995.json
|
||||
```
|
||||
|
||||
The deposit data file you just created contains a signed deposit (signed by the key you just created). You can find it in the newly created `validators` directory.
|
||||
|
||||
In the `validators` directory you should also see a folder with a name that looks something like `0x8c...3ed3a5052e2d`. The name of this folder is your validator's public key. Inside it you'll find your validator's signing keystore -- `keystore.json`.
|
||||
|
||||
> **Note:** If you wish to create a new wallet from which to make a deposit (simply run `deposits create` with no extra flags).
|
||||
|
||||
### Available options
|
||||
|
||||
To see a list of the options/flags available, run:
|
||||
```bash
|
||||
build/beacon_node deposits create --help
|
||||
```
|
||||
|
||||
You should see the following:
|
||||
```
|
||||
The following options are available:
|
||||
|
||||
--count Number of deposits to generate.
|
||||
--wallet An existing wallet ID. If not specified, a new wallet will be created.
|
||||
--out-validators-dir Output folder for validator keystores.
|
||||
--out-secrets-dir Output folder for randomly generated keystore passphrases.
|
||||
--out-deposits-file The name of generated deposits file.
|
||||
--new-wallet-name An easy-to-remember name for the wallet of your choice.
|
||||
--new-wallet-file Output wallet file.
|
||||
```
|
||||
|
||||
</details>
|
||||
|
||||
## 3. Send your deposit transaction(s)
|
||||
|
||||
You're now ready to upload your `deposit_data` JSON file along with your signing keystore(s) to the EF's [Validator Launchpad](https://medalla.launchpad.ethereum.org/): it will take you through how to create the necessary transaction(s) to make your deposit(s) and register your validator(s).
|
||||
|
||||
>**Note:** Your `deposit_data` file contains a list of all your signed deposits. So even if you have many keystores, you should only have one `deposit_data` file.
|
||||
|
||||
0. Make sure you have enough [Goerli ETH](https://faucet.goerli.mudit.blog/) (32 ETH for each validator you wish to run). See [here](create_wallet_and_deposit.md#a-note-on-acquiring-goerli-eth) for how to request Goerli ETH.
|
||||
|
||||
1. Go to [https://medalla.launchpad.ethereum.org](https://medalla.launchpad.ethereum.org/)
|
||||
|
||||
<img src="https://storage.googleapis.com/ethereum-hackmd/upload_431e6a8ec269404e3f89fec7133482b9.png" width="700">
|
||||
|
||||
2. Click on **Get Started**
|
||||
|
||||
<img src="https://storage.googleapis.com/ethereum-hackmd/upload_cbe2983e3795cfa57b621ae21b6ba165.png" width="700">
|
||||
|
||||
3. Read through the *Overview section* -- making sure you understand the risks and responsibilities involved
|
||||
|
||||
<p>
|
||||
<img width="350" src="https://storage.googleapis.com/ethereum-hackmd/upload_86a7b1e968fe5830cac4a06d4597f221.png">
|
||||
<img width="350" src="https://storage.googleapis.com/ethereum-hackmd/upload_a630e2ad0e9c5e6c3111dd1fba3c9767.png">
|
||||
</p>
|
||||
|
||||
4. Move on to the *Generate Keys* section to choose how many validators you'd like to run (1 per 32 ETH deposited)
|
||||
|
||||
<img src="https://storage.googleapis.com/ethereum-hackmd/upload_0fd4e55870b4b6ce57c80644323b45bd.png" width="700">
|
||||
|
||||
|
||||
5. Scroll to the end of the Key Generation page, tick the box, and click continue
|
||||
|
||||
<img src="https://storage.googleapis.com/ethereum-hackmd/upload_10fcb69be02662e10bc4b62c29d8a074.png" width="700">
|
||||
|
||||
|
||||
|
||||
6. Upload the Deposit data file you generated using Nimbus in the previous step
|
||||
|
||||
<img src="https://storage.googleapis.com/ethereum-hackmd/upload_6db4e4c3715a0a80db53bd5f26eb1ffc.png" width="500">
|
||||
|
||||
*Remember you can find your `deposit_data` JSON file in the `nim-beacon-chain/validators` directory*
|
||||
|
||||
</br>
|
||||
|
||||
The launchpad will then double check you understand the most important things. And help you send the required transaction(s).
|
||||
|
||||
<p>
|
||||
<img width="350" src="https://storage.googleapis.com/ethereum-hackmd/upload_e2c60ad1c9840d0f2fcf5c4ae8ec284a.png">
|
||||
<img width="350" src="https://storage.googleapis.com/ethereum-hackmd/upload_0d3c0a5c8cb421041b6847f0c2d24328.png">
|
||||
</p>
|
||||
|
||||
### A note on acquiring Goerli ETH
|
||||
The easiest way to acquire testnet ETH is to join [Prysmatic Labs' discord](https://discord.com/invite/YMVYzv6) and send a request for ETH in the **#-request-goerli-eth channel**.
|
||||
|
||||
```
|
||||
!send <your metamask goerli network ETH address>
|
||||
```
|
||||
|
||||
You can also use the [Goerli Authenticated Faucet](https://faucet.goerli.mudit.blog/).
|
||||
|
||||
## 4. Connect to Medalla
|
||||
|
||||
Now that you've generated your keys and registered your validator, the final step is to [connect to Medalla](medalla.md#connect-to-medalla).
|
||||
|
||||
|
||||
### A note on expected waiting time (the queue)
|
||||
|
||||
Once you send off your transaction(s), your validator will be put in a queue based on deposit time, and will getting through the queue may take a few hours or days (assuming the chain is finalising).
|
||||
|
||||
More technically: approximately every 3.5 hours the eth2 beacon chain receives an "include until X" eth1 block to vote on: this block must be at least 1024 blocks behind the eth1 head. However, can be made anywhere between the start and the end of a voting period, the time you'll need to wait can fluctuate (within a range of 1 or 2 voting periods).
|
||||
|
||||
Importantly, to run a validator you only need to pass the voting keystore which leaks nothing about the withdrawal key (except perhaps the path that it can be derived with).
|
||||
|
||||
|
||||
@ -1,35 +1,161 @@
|
||||
# Frequently Asked Questions
|
||||
|
||||
## What is Beacon Chain?
|
||||
## Nimbus
|
||||
|
||||
A complete introduction about the beacon chain can be found in the [Ethereum 2.0 blog series](https://our.status.im/two-point-oh-the-beacon-chain/).
|
||||
### Why are metrics not working?
|
||||
|
||||
In short, the beacon chain is a **new type of blockchain** to help the Ethereum blockchain to smoothly transfer its consensus algorithm from PoW (Proof of Work) to PoS (Proof of Stake), aka Ethereum 2.0.
|
||||
|
||||
## Differences Between Beacon Chain and Ethereum 1.0
|
||||
|
||||
In traditional PoW, those that propose new blocks are called **_miners_**, whereas in PoS, they are called **_validators_**. In essence, _miners_ rely on actual hardware (such as some specifically manufactured mining machines), while _validators_ rely on just software and a good network connection.
|
||||
|
||||
## What it is Like to Be a Validator?
|
||||
|
||||
It is obvious that you must have enough computing power or dedicated hardware in order to be a miner, but how about being a validator? Here is a brief overview:
|
||||
|
||||
1. A special smart contract named **_deposit contract_** is deployed on the original Ethereum blockchain. Note that in this case, the new beacon chain and the original blockchain co-exists.
|
||||
2. To "register" as a validator, you have to first deposit **_32 Ether_** from your account to this smart contract.
|
||||
3. Run the beacon node and wait for the network to sync before your validator is activated.
|
||||
4. That's all! Remember to stay connected to the network, or you may lose some of your deposit, as punishment, depending on how long you're offline. :P
|
||||
|
||||
## What is Nimbus?
|
||||
|
||||
In a sentence, Nimbus is an Ethereum 1.0 & 2.0 Client for Resource-Restricted Devices.
|
||||
|
||||
It is open sourced at [github.com/status-im/nimbus](github.com/status-im/nimbus). Development progress and updates can be viewed at the [Nimbus blog](https://our.status.im/tag/nimbus/).
|
||||
|
||||
## Why are metrics not working?
|
||||
|
||||
Metrics are currently implemented using a HTTP server that hasn't been hardened sufficiently that it can be exposed as a public endpoint - it must thus be enabled specifically during build:
|
||||
Metrics are currently implemented using a HTTP server that hasn't been hardened sufficiently (which means it can't be exposed as a public endpoint). It must therefore be enabled specifically during build:
|
||||
|
||||
```
|
||||
make NIMFLAGS="-d:insecure"
|
||||
beacon_node --metrics ...
|
||||
make NIMFLAGS="-d:insecure" beacon_node --metrics ...
|
||||
```
|
||||
|
||||
## Validating
|
||||
|
||||
### What exactly is a validator?
|
||||
|
||||
A validator is an entity that participates in the consensus of the Ethereum 2.0 protocol.
|
||||
|
||||
Or in plain english, a human running a computer process. This process proposes and vouches for new blocks to be added to the blockchain.
|
||||
|
||||
In other words, **you can think of a validator as a voter for new blocks.** The more votes a block gets, the more likely it is to be added to the chain.
|
||||
|
||||
Importantly, a validator's vote is weighted by the amount it has at stake.
|
||||
|
||||
|
||||
### What is the deposit contract?
|
||||
|
||||
You can think of it as a transfer of funds between Ethereum 1.0 accounts and Ethereum 2.0 validators.
|
||||
|
||||
It specifies who is staking, who is validating, how much is being staked, and who can withdraw the funds.
|
||||
|
||||
### Why do validators need to have funds at stake?
|
||||
Validators need to have funds at stake so they can be penalized for behaving dishonestly.
|
||||
|
||||
In other words, to keep them honest, their actions need to have financial consequences.
|
||||
|
||||
### How much ETH does a validator need to stake?
|
||||
|
||||
Before a validator can start to secure the network, he or she needs to stake **32 ETH**. This forms the validator's initial balance.
|
||||
|
||||
### Is there any advantage to having more than 32 ETH at stake?
|
||||
|
||||
No. There is no advantage to having more than 32 ETH staked.
|
||||
|
||||
Limiting the maximum stake to 32 ETH encourages decentralization of power as it prevents any single validator from having an excessively large vote on the state of the chain.
|
||||
|
||||
> Remember that a validator’s vote is weighted by the amount it has at stake.
|
||||
|
||||
### How are validators incentivized to stay active and honest?
|
||||
|
||||
In addition to being penalized for being offline, validators are penalized for behaving maliciously – for example attesting to invalid or contradicting blocks.
|
||||
|
||||
On the other hand, they are rewarded for proposing / attesting to blocks that are included in the chain.
|
||||
|
||||
The key concept is the following:
|
||||
|
||||
- Rewards are given for actions that help the network reach consensus
|
||||
- Minor penalties are given for inadvertant actions (or inactions) that hinder consensus
|
||||
- And major penalities -- or **slashings** -- are given for malicious actions
|
||||
|
||||
In other words, validators that maximize their rewards also provide the greatest benefit to the network as a whole.
|
||||
|
||||
### How are rewards/penalties issued?
|
||||
|
||||
Remember that each validator has its own balance -- with the initial balance outlined in the deposit contract.
|
||||
|
||||
This balance is updated periodically by the Ethereum network rules as the validator carries (or fails to carry) out his or her responsibilities.
|
||||
|
||||
Put another way, rewards and penalties are reflected in the validator's balance over time.
|
||||
|
||||
|
||||
### How often are rewards/penalties issued?
|
||||
|
||||
Approximately every six and a half minutes -- a period of time known as an epoch.
|
||||
|
||||
Every epoch, the network measures the actions of each validator and issues rewards or penalties appropriately.
|
||||
|
||||
|
||||
### How large are the rewards/penalties?
|
||||
|
||||
There is no easy answer to this question as there are many factors that go into this calculation.
|
||||
|
||||
Arguably the most impactful factor on rewards earned for validating transactions is the total amount of stake in the network. In other words, the total amount of validators. Depending on this figure the max annual return rate for a validator can be anywhere between 2 and 20%.
|
||||
|
||||
Given a fixed total number of validators, the rewards/penalties predominantly scale with the balance of the validator -- attesting with a higher balance results in larger rewards/penalties whereas attesting with a lower balance results in lower rewards/penalties.
|
||||
|
||||
>Note however that this scaling mechanism works in a non-obvious way. To understand the precise details of how it works requires understanding a concept called **effective balance**. If you're not yet familiar with this concept, we recommend you read through this [excellent post](https://www.attestant.io/posts/understanding-validator-effective-balance/).
|
||||
|
||||
|
||||
### Why do rewards depend on the total number of validators in the network?
|
||||
|
||||
Block rewards are calculated using a sliding scale based on the total amount of ETH staked on the network.
|
||||
|
||||
In plain english: if the total amount of ETH staked is low, the reward (interest rate) is high, but as the total stake rises, the reward (interest) paid out to each validator starts to fall.
|
||||
|
||||
Why a sliding scale? While we won't get into the gory details here, the basic intution is that there needs to be a minimum number of validators (and hence a minimum amount of ETH staked) for the network to function properly. So, to incentivize more validators to join, it's important that the interest rate remains high until this minimum number is reached.
|
||||
|
||||
Afterwards, validators are still encouraged to join (the more validators the more decentralized the network), but it's not absolutely essential that they do so (so the interest rate can fall).
|
||||
|
||||
### How badly will a validator be penalized for being offline?
|
||||
|
||||
It depends. In addition to [the impact of effective balance](https://www.attestant.io/posts/understanding-validator-effective-balance/#the-impact-of-effective-balance-on-validating) there are two important scenarios to be aware of:
|
||||
|
||||
1. Being offline while a supermajority (2/3) of validators is still online leads to relatively small penalties as there are still enough validators online for the chain to finalize. **This is the expected scenario.**
|
||||
|
||||
2. Being offline at the same time as more than 1/3 of the total number of validators leads to harsher penalties, since blocks do not finalize anymore. **This scenario is very extreme and unlikely to happen.**
|
||||
|
||||
> Note that in the second (unlikely) scenario, validators stand to progressively lose up to 50% (16 ETH) of their stake over 21 days. After 21 days they are ejected out of the validator pool. This ensures that blocks start finalizing again at some point.
|
||||
|
||||
### How great does an honest validator's uptime need to be for it to be net profitable?
|
||||
|
||||
Overall, validators are expected to be net profitable as long as their uptime is [greater than 50%](https://blog.ethereum.org/2020/01/13/validated-staking-on-eth2-1-incentives/).
|
||||
|
||||
This means that validators need not go to extreme lengths with backup clients or redundant internet connections as the repercussions of being offline are not so severe.
|
||||
|
||||
### How much will a validator be penalized for acting maliciously?
|
||||
|
||||
Again, it depends. Behaving maliciously – for example attesting to invalid or contradicting blocks, will lead to a validator's stake being slashed.
|
||||
|
||||
The minimum amount that can be slashed is 1 ETH, but **this number increases if other validators are slashed at the same time.**
|
||||
|
||||
The idea behind this is to minimize the losses from honest mistakes, but strongly disincentivize coordinated attacks.
|
||||
|
||||
### What exactly is slashing?
|
||||
|
||||
Slashing has two purposes: (1) to make it prohibitively expensive to attack eth2, and (2) to stop validators from being lazy by checking that they actually perform their duties. Slashing a validator is to destroy (a portion of) the validator’s stake if they act in a provably destructive manner.
|
||||
|
||||
Validators that are slashed are prevented from participating in the protocol further and are forcibly exited.
|
||||
|
||||
|
||||
### What happens I lose my signing key?
|
||||
|
||||
If the signing key is lost, the validator can no longer propose or attest.
|
||||
|
||||
Over time, the validator's balance will decrease as he or she is punished for not participating in the consensus process. When the validator's balance reaches 16 Eth, he or she will be automatically exited from the validator pool.
|
||||
|
||||
> However, all is not lost. Assuming validators derive their keys using [EIP2334](https://eips.ethereum.org/EIPS/eip-2334) (as per the default onboarding flow)then **validators can always recalculate their signing key from their withdrawal key**.
|
||||
|
||||
The 16 Eth can then be withdrawn -- with the withdrawal key -- after a delay of around a day.
|
||||
|
||||
> Note that this delay can be longer if many others are exiting or being kicked out at the same time.
|
||||
|
||||
### What happens if I lose my withdrawal key?
|
||||
|
||||
If the withdrawal key is lost, there is no way to obtain access to the funds held by the validator.
|
||||
|
||||
As such, it's a good idea to create your keys from mnemonics which act as another backup. This will be the default for validators who join via this site's onboarding process.
|
||||
|
||||
### What happens if my withdrawal key is stolen?
|
||||
|
||||
If the withdrawal key is stolen, the thief can transfer the validator’s balance, but only once the validator has exited.
|
||||
|
||||
If the signing key is not under the thief’s control, the thief cannot exit the validator.
|
||||
|
||||
The user with the signing key could attempt to quickly exit the validator and then transfer the funds -- with the withdrawal key -- before the thief.
|
||||
|
||||
### Why two keys instead of one?
|
||||
|
||||
In a nutshell, security. The signing key must be available at all times. As such, it will need to be held online. Since anything online is vulnerable to being hacked, it's not a good idea to use the same key for withdrawals.
|
||||
|
||||
|
||||
|
||||
@ -14,7 +14,9 @@ We recommended you run a high quality time service on your computer such as:
|
||||
|
||||
At a minimum, you should run an NTP client on the server.
|
||||
|
||||
If that sounds like latin to you, don't worry. For testnet purposes, you should be fine as long as your computer is set to the correct time.
|
||||
> **Note:** Most operating systems (including macOS') automatically sync with NTP by default.
|
||||
|
||||
If the above sounds like latin to you, don't worry. You should be fine as long as you haven't messed around with the time and date settings on your computer (they should be set automatically).
|
||||
|
||||
## External Dependencies
|
||||
|
||||
|
||||
@ -2,12 +2,13 @@
|
||||
|
||||
The Nimbus beacon chain is a research implementation of the Beacon Chain – the core system level chain at the heart of Ethereum 2.0.
|
||||
|
||||
|
||||
- Open sourced at [github.com/status-im/nim-beacon-chain](https://github.com/status-im/nim-beacon-chain/tree/master)
|
||||
|
||||
- Specification described at [ethereum/eth2.0-specs](https://github.com/ethereum/eth2.0-specs/tree/v0.12.2#phase-0)
|
||||
|
||||
|
||||
### Further resources
|
||||
### Helpful resources
|
||||
- [Ben Edgington's annotated spec](https://benjaminion.xyz/eth2-annotated-spec/phase0/beacon-chain/)
|
||||
|
||||
- [Vitalik's annotated spec](https://github.com/ethereum/annotated-spec/blob/master/phase0/beacon-chain.md)
|
||||
@ -18,20 +19,50 @@ The Nimbus beacon chain is a research implementation of the Beacon Chain – the
|
||||
|
||||
In this book, we will cover:
|
||||
|
||||
1. An introduction to the [beacon chain](./faq.md#1-what-is-beacon-chain) and [Nimbus](./faq.md#4-what-is-nimbus) to equip you with some basic knowledge
|
||||
1. An [introduction](./intro.md#introduction) to the beacon chain, eth2, and Nimbus to equip you with some basic knowledge
|
||||
2. [Installation steps](./install.md) outlining the prerequisites to get started
|
||||
3. How to [become a Medalla validator](./medalla.md)
|
||||
3. How to [run the beacon node](./beacon_node.md) software to sync the beacon chain
|
||||
4. How to generate keys, deposit, and [become a validator](./validator.md) in eth2
|
||||
5. The [API](./api.md) for monitoring your node through `http`
|
||||
4. How to [run the beacon node](./beacon_node.md) software to sync the beacon chain
|
||||
5. The [API](./api.md) for monitoring your node
|
||||
6. [Advanced usage](./advanced.md) for developers
|
||||
7. How to [setup up a systemd service](./beacon_node_systemd.md)
|
||||
8. How to [use Nimbus to generate your validator keys](./create_wallet_and_deposit.md)
|
||||
7. Common [questions and answers](./faq.md) to satisfy your curiosity
|
||||
8. How to [contribute](./contribute.md) to this book
|
||||
|
||||
|
||||
## Introduction
|
||||
|
||||
### What's the Beacon Chain?
|
||||
|
||||
In short, the beacon chain is the brain underpinning eth2 -- the next generation of Ethereum. It contains all of the machinery behind eth2's consensus.
|
||||
|
||||
You can find a complete introduction to the beacon chain in our [Ethereum 2.0 blog series](https://our.status.im/two-point-oh-the-beacon-chain/).
|
||||
|
||||
|
||||
|
||||
### Why eth2?
|
||||
|
||||
Eth2 is a multi-year plan to improve the scalability, security, and programmability of Ethereum, without compromising on decentralisation.
|
||||
|
||||
In contrast to the Ethereum chain, as it currently stands, eth2 uses proof-of-stake (PoS) to secure its network. And while Ethereum as you know and love it will continue to exist as its own independent proof-of-work chain for a little while to come, the transition towards PoS starts now.
|
||||
|
||||
In traditional PoW, block proposers are called **_miners_**, whereas in PoS, they are called **_validators_**. In essence, _miners_ rely on actual hardware (such as some specifically manufactured mining machines), while _validators_ rely on software (such as Nimbus) and a good network connection.
|
||||
|
||||
### Why Nimbus?
|
||||
|
||||
In a sentence, Nimbus aims to be an ethereum client for resource-restricted devices.
|
||||
|
||||
Because we believe that the largest deployment of Ethereum will be on embedded systems, Nimbus is being designed to perform well on IoT and personal mobile devices, including older smartphones with resource-restricted hardware.
|
||||
|
||||
Although Nimbus will support full and archival nodes, its main implementation will be as a light client, with a focus on Proof of Stake and sharding.
|
||||
|
||||
All our code is open source; we encourage you to keep track of our activity on [github.com/status-im/nimbus](github.com/status-im/nimbus)) and keep up to date with our progress through the [Nimbus blog](https://our.status.im/tag/nimbus/).
|
||||
|
||||
|
||||
## Get in touch
|
||||
|
||||
Need help with anything? Join us on [Status](https://join.status.im/nimbus-general) or [Discord](https://discord.gg/9dWwPnG)!
|
||||
Need help with anything? Join us on [Status](https://join.status.im/nimbus-general) and [Discord](https://discord.gg/9dWwPnG)!
|
||||
|
||||
|
||||
## Disclaimer
|
||||
|
||||
@ -1,12 +1,11 @@
|
||||
# Become a Medalla validator
|
||||
|
||||
This page will take you through how to become a validator on the eth2 testnet [Medalla](https://github.com/goerli/medalla).
|
||||
This chapter will take you through how to become a validator on the eth2 testnet [Medalla](https://github.com/goerli/medalla).
|
||||
|
||||
If you generated your signing key using the [eth2 launchpad](https://medalla.launchpad.ethereum.org/), and wish to import it into the Nimbus client, this page is for you.
|
||||
|
||||
> If you haven't created your validator key yet, we recommend you do so using the [launchpad](https://medalla.launchpad.ethereum.org/). If you're not sure what the eth2 launchpad is, we recommend reading this [introductory post](https://blog.ethereum.org/2020/07/27/eth2-validator-launchpad/) first.
|
||||
|
||||
For advanced users, [this page](./create_wallet_and_deposit.md) explains how to use Nimbus to create a walletstore to generate your keys.
|
||||
|
||||
## Prerequisites
|
||||
|
||||
@ -143,3 +142,53 @@ You may need to do this if you are running another client.
|
||||
```
|
||||
make medalla-deposit VALIDATORS=2 # default is just 1
|
||||
```
|
||||
|
||||
### Upgrading
|
||||
|
||||
When you restart the beacon node, the software will resume from where it left off, using your previous deposits.
|
||||
|
||||
```
|
||||
cd nim-beacon-chain
|
||||
git pull
|
||||
make update # Update dependencies
|
||||
make medalla # Restart using same keys as last run
|
||||
```
|
||||
|
||||
## Key management
|
||||
|
||||
Keys are stored in the `build/data/[testnet_name]/` folder, under `secrets` and `validators` - make sure you keep these folders backed up.
|
||||
|
||||
The `secrets` folder contains the common secret that gives you access to all your validator keys.
|
||||
|
||||
The `validators` folder contains your keystores. Keystores are used by validators as a method for exchanging keys.
|
||||
|
||||
For more on keys in eth2, see [here](https://blog.ethereum.org/2020/05/21/keys/).
|
||||
|
||||
|
||||
|
||||
|
||||
## Metrics
|
||||
|
||||
Metrics are not included in the binary by default - to enable them, use the following options when starting the client:
|
||||
|
||||
```
|
||||
make NIMFLAGS="-d:insecure" medalla
|
||||
```
|
||||
|
||||
You can then browse the metrics by connecting to:
|
||||
|
||||
http://localhost:8008/metrics
|
||||
|
||||
Make sure this port is protected as the http server used is not considered secure (it should not be used by untrusted peers).
|
||||
|
||||
## Troubleshooting
|
||||
|
||||
1. The directory that stores the blockchain data of the testnet is `build/data/shared_medalla_0` (if you're connecting to another testnet, replace `medalla` with that testnet's name). Delete this folder if you want to start over (for example, if you entered a wrong private key).
|
||||
|
||||
2. Currently, you have to switch to the `devel` branch in order to run the validator node successfully.
|
||||
|
||||
3. Everytime you want to update your node to the latest version, run `git pull`, `make update`, and then `make medalla`.
|
||||
|
||||
4. If `make update` causes the console to hang for too long, try running `make update V=1` or `make update V=2` instead (these will print a more verbose output to the console which may make it easier to diagnose the problem).
|
||||
|
||||
5. If you’re experiencing sync problems, or have been running an old version of medalla, we recommend running `make clean-medalla` to restart your sync (make sure you’ve updated to the latest `devel` branch first though).
|
||||
|
||||
@ -94,50 +94,3 @@ ETH: 0
|
||||
|
||||
You can get a brief estimate of the time remaining until you've synced to the network by comparing `head` with `time` (`time` gives the current epoch, whereas `head` tells you how many epochs you've synced so far). From the above output, we see that the number of epochs synced so far is `285`, and the current epoch is `1405`.
|
||||
|
||||
### Upgrading
|
||||
|
||||
When you restart the beacon node, the software will resume from where it left off, using your previous deposits.
|
||||
|
||||
```
|
||||
cd nim-beacon-chain
|
||||
git pull
|
||||
make update # Update dependencies
|
||||
make altona # Restart using same keys as last run
|
||||
```
|
||||
|
||||
## Key management
|
||||
|
||||
Keys are stored in the `build/data/[testnet_name]/` folder, under `secrets` and `validators` - make sure you keep these folders backed up.
|
||||
|
||||
The `secrets` folder contains the common secret that gives you access to all your validator keys.
|
||||
|
||||
The `validators` folder contains your keystores. Keystores are used by validators as a method for exchanging keys.
|
||||
|
||||
For more on keys in eth2, see [here](https://blog.ethereum.org/2020/05/21/keys/).
|
||||
|
||||
|
||||
|
||||
|
||||
## Metrics
|
||||
|
||||
Metrics are not included in the binary by default - to enable them, use the following options when starting the client:
|
||||
|
||||
```
|
||||
make NIMFLAGS="-d:insecure" altona
|
||||
```
|
||||
|
||||
You can then browse the metrics by connecting to:
|
||||
|
||||
http://localhost:8008/metrics
|
||||
|
||||
Make sure this port is protected as the http server used is not considered secure (it should not be used by untrusted peers).
|
||||
|
||||
## Troubleshooting
|
||||
|
||||
1. The directory that stores the blockchain data of the testnet is `build/data/shared_altona_0` (if you're connecting to another testnet, replace `altona` with that testnet's name). Delete this folder if you want to start over (for example, if you entered a wrong private key).
|
||||
|
||||
2. Currently, you have to switch to the `devel` branch in order to run the validator node successfully.
|
||||
|
||||
3. Everytime you want to update your node to the latest version, run `git pull`, `make update`, and then `make altona`.
|
||||
|
||||
4. If `make update` causes the console to hang for too long, try running `make update V=1` or `make update V=2` instead (these will print a more verbose output to the console which may make it easier to diagnose the problem).
|
||||
|
||||
Loading…
x
Reference in New Issue
Block a user