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:
parent
bef13b6cce
commit
df8d744a47
|
@ -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/).
|
||||
|
|
|
@ -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:
|
||||
|
||||
|
|
Loading…
Reference in New Issue