book updates (min viable changes prior to release) (#3283)

* min viable changes

* make clear keymanager api is not ready for mainnet

* Update docs/the_nimbus_book/src/keymanager-api.md

Co-authored-by: Jacek Sieka <jacek@status.im>

* Update docs/the_nimbus_book/src/keymanager-api.md

Co-authored-by: zah <zahary@gmail.com>

Co-authored-by: Jacek Sieka <jacek@status.im>
Co-authored-by: zah <zahary@gmail.com>
This commit is contained in:
sacha 2022-01-14 13:37:21 +01:00 committed by GitHub
parent bef13b6cce
commit df8d744a47
No known key found for this signature in database
GPG Key ID: 4AEE18F83AFDEB23
2 changed files with 21 additions and 9 deletions

View File

@ -1,17 +1,27 @@
# Keymanager API
The standardized [Keymanager API](https://ethereum.github.io/keymanager-APIs/) can be used to add, remove or migrate validators on the fly on a running beacon node.
> ⚠️ This feature is currently in BETA - we are still testing it and implementation details may change in response to community feedback. **We strongly advise against using it on mainnet** - your validators may get slashed
The standardized [Keymanager API](https://ethereum.github.io/keymanager-APIs/) can be used to add, remove, or [migrate](./migration.md) validators on the fly while the beacon node is running.
## Configuration
By default, the Keymanager API is disabled. To enable it, start the beacon node with the `--keymanager` option, then access the API from http://localhost:5052/. All requests must be authorized through the `Authorization: Bearer` scheme with a token matching the contents of a file provided at the start of the node through the `--keymanager-token-file` parameter.
By default, we disable the Keymanager API. To enable it, start the beacon node with the `--keymanager` option enabled:
By default, only connections from the same machine are entertained. The port and listening address can be further configured through the options `--keymanager-port` and `--keymanager-address`.
```
./run-prater-beacon-node.sh --keymanager
```
> **Warning:** The Keymanager API port SHOULD be exposed through a secure channel, such as with HTTPs, an SSH tunnel, a VPN, etc.
Once the node is running, you'll be able to access the API from [http://localhost:5052/](http://localhost:5052/)
### Authorization: Bearer scheme
All requests must be authorized through the `Authorization: Bearer` scheme with a token matching the contents of a file provided at the start of the node through the `--keymanager-token-file` parameter.
### Enabling connections from outside machines
By default, only connections from the same machine are entertained. If you wish to change this you can configure the port and listening address with the `--keymanager-port` and `--keymanager-address` options respectively.
> ⚠️ The Keymanager API port should only be exposed through a secure channel (e.g. HTTPS, an SSH tunnel, a VPN, etc.)
## Specification
The specification is documented [here](https://ethereum.github.io/keymanager-APIs/).
See the Readme [here](https://github.com/ethereum/keymanager-APIs/).
The specification is documented [here](https://ethereum.github.io/keymanager-APIs/). The README is also extremely useful and is documented [here](https://github.com/ethereum/keymanager-APIs/).

View File

@ -1,8 +1,10 @@
# Validator monitoring
> ⚠️ This feature is currently in BETA - the details of its implementation may change in response to community feedback.
> ⚠️ This feature is currently in BETA - implementation details may change in response to community feedback.
The validator monitoring feature allows for tracking the life-cycle and performance of one or more validators in detail. Monitoring can be carried out for any validator, with slightly more detail for validators that are running through the same beacon node.
The validator monitoring feature allows for tracking the life-cycle and performance of one or more validators in detail.
Monitoring can be carried out for any validator, with slightly more detail for validators that are running through the same beacon node.
Every time the validator performs a duty, the duty is recorded and the monitor keeps track of the reward-related events for having performed it. For example: