Clarifications to docs re validator-client vs validator

README.md

@@ -21,7 +21,7 @@ Currently supported clients:
 
 Currently supported optional components:
 - geth, local eth1 node.
-- nethermind, local eth1 node - appears to work, no long-term test done yet
+- nethermind, local eth1 node - testing only, DB corruption observed on goerli
 - openethereum, local eth1 node - testing only, DB corruption observed on mainnet
 > Use one of the local eth1 node options or a 3rd-party provider of eth1 chain data to "feed"
 > your eth2 beacon node, so you can [propose](https://ethos.dev/beacon-chain/) blocks.
@@ -35,7 +35,7 @@ of validator-import to import keys.
 
 ## Before you start
 
-Warnings about the dangers of running eth2 validators are in [RECOMMENDATIONS.md](RECOMMENDATIONS.md).
+Warnings about the dangers of running eth2 nodes are in [RECOMMENDATIONS.md](RECOMMENDATIONS.md).
 That file also contains a link to SomerEsat's [guide on host security](https://medium.com/@SomerEsat/guide-to-staking-on-ethereum-2-0-ubuntu-medalla-nimbus-5f4b2b0f2d7c), and comments on key security.
 Please take a look.
 
@@ -86,20 +86,25 @@ in phase 2. You need the seed phrase or your eth is gone forever.**
 
 Make sure you're in the project directory, `cd ~/eth2-docker` by default.
 
-Edit the `.env` file to set the number of validators you wish to run. The default
+Edit the `.env` file to set the number of validators you wish to create. The default
 is just one (1) validator.
+> A validator is synonymous to one 32 Ethereum stake. Multiple validators
+> can be imported to a single validator client.
 
 This command will get you ready to deposit eth:<br />
 `sudo docker-compose run --rm deposit-cli`
 
 The created files will be in the directory `.eth2/validator_keys` in this project.
+> eth2.0-deposit-cli shows you a different directory, that's because it has a view
+> from inside the container.
+ 
 This is also where you'd place your own keystore files if you already have some for import.
 
 ### You brought your own keys
 
 They go into `.eth2/validator_keys` in this project directory, not directly under `$HOME`.
 
-## Step 5: Create a validator wallet by importing validator keys
+## Step 5: Create a validator client wallet by importing validator keys
 
 **Warning** Import your validator key(s) to only *one* client.
 
@@ -122,19 +127,19 @@ Import the validator key(s) to the validator client:
 
 If you choose to save the password during import, it'll be available to the client every
 time it starts. If you do not, you'll need to be present to start the
-validator and start it interactively. Determine your own risk profile.
+validator client and start it interactively. Determine your own risk profile.
 
 ## Step 6: Start the client
 
 To start the client:
 ```
 sudo docker-compose up -d eth2
 ```
-> **Nimbus and Teku**: Beacon and validator run in the same process, there is only one container for both
+> **Nimbus and Teku**: Beacon and validator client run in the same process, there is only one container for both
 
-If, however, you chose not to store the wallet password with the validator, you will need
+If, however, you chose not to store the wallet password with the validator client, you will need
 to bring the beacon and, if in use, eth1, up individually instead, then "run"
-the validator so it can prompt you for input:
+the validator client so it can prompt you for input:
 
 ```
 sudo docker-compose up -d eth1 beacon
@@ -243,7 +248,7 @@ Then stop, remove and start eth1:<br />
 
 ### Client
 
-Beacon and validator share the same image for most clients, we only need to rebuild one.
+Beacon and validator client share the same image for most clients, we only need to rebuild one.
 
 If not building from source, run:<br />
 `sudo docker-compose build --pull beacon`
@@ -260,7 +265,7 @@ Or, if building from source:<br />
 Then restart the client:<br />
 `sudo docker-compose down && sudo docker-compose up -d eth2`
 
-If you did not store the wallet password with the validator, come up 
+If you did not store the wallet password with the validator client, come up 
 [more manually](#start-the-client) instead.
 
 ## Addendum: Add or recover validators

RECOMMENDATIONS.md

@@ -5,7 +5,7 @@ and key security.
 
 ## Operation
 
-**Do not run two validators**<br />
+**Do not run two validator clients with the same validator keys imported at the same time**<br />
 You'd get yourself slashed, and no-one wants that. Protecting you from this
 is a work in progress. Choose one client, and one client only, and run that.
 
@@ -58,7 +58,7 @@ files created by eth2.0-deposit-cli.
 
 Use `deposit_data-TIMESTAMP.json` for your initial deposit. After that, it can be disposed of.
 
-Use `keystore-m_ID.json` files to import your validator secret keys into the validator
+Use `keystore-m_ID.json` files to import your validator secret keys into the validator client
 instance of the client you are running. These files need to be secured when you are done
 with the initial import.
 
@@ -69,7 +69,7 @@ is best, on media that cannot be remotely compromised. Keep the password(s) for
 these files secure as well, for example in a local (not cloud-connected) password vault
 on a PC that is not on the network, or at the very least not used for online access.
 
-Once you have the keystore files secure and they've been imported to the validator container
+Once you have the keystore files secure and they've been imported to the validator client container
 on your server, you should delete them from the `.eth2` directory.
 
 These files will be needed in case you need to restore your validator(s).

SETUP.md

@@ -48,8 +48,8 @@ Please choose:
   * Nimbus
 * Your source of eth1 data
   * geth
-  * nethermind - appears to work, no long-term tests done yet
-  * openethereum - testing only, DB corruption observed
+  * nethermind - testing only, DB corruption observed on goerli
+  * openethereum - testing only, DB corruption observed on main net
   * 3rd-party
 * Whether to run a slasher (experimental for Prysm)
 * Whether to run a grafana dashboard for monitoring
@@ -99,8 +99,8 @@ openethereum with `:` between the file names.
 - `teku-base.yml` - Teku
 - `nimbus-base.yml` - Nimbus
 - `geth.yml` - local geth eth1 chain node
-- `nm.yml` - local nethermind eth1 chain node - appears to work, no long-term tests done yet
-- `oe.yml` - local openethereum eth1 chain node - testing only, DB corruption observed
+- `nm.yml` - local nethermind eth1 chain node - testing only, DB corruptionb observed on goerli
+- `oe.yml` - local openethereum eth1 chain node - testing only, DB corruption observed on main net
 - `eth1-shared.yml` - makes the RPC port of the eth1 node available from the host, for using the eth1 node with other nodes or with Metamask. **Not encrypted**, do not expose to Internet.
 - `eth1-standalone.yml` - like eth1-shared but for running *just* eth1, instead of running it alongside a beacon node in the same "stack". Also not encrypted, not meant for a fully distributed setup quite yet.
 - `prysm-slasher.yml` - Prysm experimental Slasher which helps secure the chain and may result in additional earnings. The experimental slasher can lead to missed attestations do to the additional resource demand.
@@ -115,7 +115,7 @@ For example, Lighthouse with local openethereum and grafana:
 
 > See [WEB](WEB.md) for notes on using the experimental Prysm Web UI
 
-In this setup, clients are isolated from each other. Each run their own validator, and if eth1
+In this setup, clients are isolated from each other. Each run their own validator client, and if eth1
 is in use, their own eth1 node. This is perfect for running a single client, or multiple isolated
 clients each in their own directory.
 

geth.yml

@@ -33,7 +33,7 @@ services:
       - /var/lib/goethereum
       - --port
       - ${ETH1_PORT}
-      - --rpcport
+      - --http.port
       - ${ETH1_RPC_PORT}
       - --ws
       - --ws.addr