Reformat tables and add borders (#3377)
## Proposed Changes This PR reformats Markdown tables and ensures all tables have borders.
This commit is contained in:
parent
0f62d900fe
commit
e29765e118
@ -23,11 +23,11 @@ states to slow down dramatically. A lower _slots per restore point_ value (SPRP)
|
||||
frequent restore points, while a higher SPRP corresponds to less frequent. The table below shows
|
||||
some example values.
|
||||
|
||||
| Use Case | SPRP | Yearly Disk Usage | Load Historical State |
|
||||
| ---------------------- | -------------- | ----------------- | --------------------- |
|
||||
| Block explorer/analysis | 32 | 1.4 TB | 155 ms |
|
||||
| Hobbyist (prev. default) | 2048 | 23.1 GB | 10.2 s |
|
||||
| Validator only (default) | 8192 | 5.7 GB | 41 s |
|
||||
| Use Case | SPRP | Yearly Disk Usage | Load Historical State |
|
||||
|--------------------------|------|-------------------|-----------------------|
|
||||
| Block explorer/analysis | 32 | 1.4 TB | 155 ms |
|
||||
| Hobbyist (prev. default) | 2048 | 23.1 GB | 10.2 s |
|
||||
| Validator only (default) | 8192 | 5.7 GB | 41 s |
|
||||
|
||||
As you can see, it's a high-stakes trade-off! The relationships to disk usage and historical state
|
||||
load time are both linear – doubling SPRP halves disk usage and doubles load time. The minimum SPRP
|
||||
|
@ -24,12 +24,12 @@ Returns the software version and `git` commit hash for the Lighthouse binary.
|
||||
|
||||
### HTTP Specification
|
||||
|
||||
| Property | Specification |
|
||||
| --- |--- |
|
||||
Path | `/lighthouse/version`
|
||||
Method | GET
|
||||
Required Headers | [`Authorization`](./api-vc-auth-header.md)
|
||||
Typical Responses | 200
|
||||
| Property | Specification |
|
||||
|-------------------|--------------------------------------------|
|
||||
| Path | `/lighthouse/version` |
|
||||
| Method | GET |
|
||||
| Required Headers | [`Authorization`](./api-vc-auth-header.md) |
|
||||
| Typical Responses | 200 |
|
||||
|
||||
### Example Response Body
|
||||
|
||||
@ -47,12 +47,12 @@ Returns information regarding the health of the host machine.
|
||||
|
||||
### HTTP Specification
|
||||
|
||||
| Property | Specification |
|
||||
| --- |--- |
|
||||
Path | `/lighthouse/health`
|
||||
Method | GET
|
||||
Required Headers | [`Authorization`](./api-vc-auth-header.md)
|
||||
Typical Responses | 200
|
||||
| Property | Specification |
|
||||
|-------------------|--------------------------------------------|
|
||||
| Path | `/lighthouse/health` |
|
||||
| Method | GET |
|
||||
| Required Headers | [`Authorization`](./api-vc-auth-header.md) |
|
||||
| Typical Responses | 200 |
|
||||
|
||||
*Note: this endpoint is presently only available on Linux.*
|
||||
|
||||
@ -83,12 +83,12 @@ Returns the Ethereum proof-of-stake consensus specification loaded for this vali
|
||||
|
||||
### HTTP Specification
|
||||
|
||||
| Property | Specification |
|
||||
| --- |--- |
|
||||
Path | `/lighthouse/spec`
|
||||
Method | GET
|
||||
Required Headers | [`Authorization`](./api-vc-auth-header.md)
|
||||
Typical Responses | 200
|
||||
| Property | Specification |
|
||||
|-------------------|--------------------------------------------|
|
||||
| Path | `/lighthouse/spec` |
|
||||
| Method | GET |
|
||||
| Required Headers | [`Authorization`](./api-vc-auth-header.md) |
|
||||
| Typical Responses | 200 |
|
||||
|
||||
### Example Response Body
|
||||
|
||||
@ -168,12 +168,12 @@ file may be read by a local user with access rights.
|
||||
|
||||
### HTTP Specification
|
||||
|
||||
| Property | Specification |
|
||||
| --- |--- |
|
||||
Path | `/lighthouse/auth`
|
||||
Method | GET
|
||||
Required Headers | -
|
||||
Typical Responses | 200
|
||||
| Property | Specification |
|
||||
|-------------------|--------------------|
|
||||
| Path | `/lighthouse/auth` |
|
||||
| Method | GET |
|
||||
| Required Headers | - |
|
||||
| Typical Responses | 200 |
|
||||
|
||||
### Example Path
|
||||
|
||||
@ -195,12 +195,12 @@ Lists all validators managed by this validator client.
|
||||
|
||||
### HTTP Specification
|
||||
|
||||
| Property | Specification |
|
||||
| --- |--- |
|
||||
Path | `/lighthouse/validators`
|
||||
Method | GET
|
||||
Required Headers | [`Authorization`](./api-vc-auth-header.md)
|
||||
Typical Responses | 200
|
||||
| Property | Specification |
|
||||
|-------------------|--------------------------------------------|
|
||||
| Path | `/lighthouse/validators` |
|
||||
| Method | GET |
|
||||
| Required Headers | [`Authorization`](./api-vc-auth-header.md) |
|
||||
| Typical Responses | 200 |
|
||||
|
||||
### Example Response Body
|
||||
|
||||
@ -232,12 +232,12 @@ Get a validator by their `voting_pubkey`.
|
||||
|
||||
### HTTP Specification
|
||||
|
||||
| Property | Specification |
|
||||
| --- |--- |
|
||||
Path | `/lighthouse/validators/:voting_pubkey`
|
||||
Method | GET
|
||||
Required Headers | [`Authorization`](./api-vc-auth-header.md)
|
||||
Typical Responses | 200, 400
|
||||
| Property | Specification |
|
||||
|-------------------|--------------------------------------------|
|
||||
| Path | `/lighthouse/validators/:voting_pubkey` |
|
||||
| Method | GET |
|
||||
| Required Headers | [`Authorization`](./api-vc-auth-header.md) |
|
||||
| Typical Responses | 200, 400 |
|
||||
|
||||
### Example Path
|
||||
|
||||
@ -262,12 +262,12 @@ Update some values for the validator with `voting_pubkey`.
|
||||
|
||||
### HTTP Specification
|
||||
|
||||
| Property | Specification |
|
||||
| --- |--- |
|
||||
Path | `/lighthouse/validators/:voting_pubkey`
|
||||
Method | PATCH
|
||||
Required Headers | [`Authorization`](./api-vc-auth-header.md)
|
||||
Typical Responses | 200, 400
|
||||
| Property | Specification |
|
||||
|-------------------|--------------------------------------------|
|
||||
| Path | `/lighthouse/validators/:voting_pubkey` |
|
||||
| Method | PATCH |
|
||||
| Required Headers | [`Authorization`](./api-vc-auth-header.md) |
|
||||
| Typical Responses | 200, 400 |
|
||||
|
||||
### Example Path
|
||||
|
||||
@ -301,12 +301,12 @@ Validators are generated from the mnemonic according to
|
||||
|
||||
### HTTP Specification
|
||||
|
||||
| Property | Specification |
|
||||
| --- |--- |
|
||||
Path | `/lighthouse/validators`
|
||||
Method | POST
|
||||
Required Headers | [`Authorization`](./api-vc-auth-header.md)
|
||||
Typical Responses | 200
|
||||
| Property | Specification |
|
||||
|-------------------|--------------------------------------------|
|
||||
| Path | `/lighthouse/validators` |
|
||||
| Method | POST |
|
||||
| Required Headers | [`Authorization`](./api-vc-auth-header.md) |
|
||||
| Typical Responses | 200 |
|
||||
|
||||
### Example Request Body
|
||||
|
||||
@ -359,12 +359,12 @@ Import a keystore into the validator client.
|
||||
|
||||
### HTTP Specification
|
||||
|
||||
| Property | Specification |
|
||||
| --- |--- |
|
||||
Path | `/lighthouse/validators/keystore`
|
||||
Method | POST
|
||||
Required Headers | [`Authorization`](./api-vc-auth-header.md)
|
||||
Typical Responses | 200
|
||||
| Property | Specification |
|
||||
|-------------------|--------------------------------------------|
|
||||
| Path | `/lighthouse/validators/keystore` |
|
||||
| Method | POST |
|
||||
| Required Headers | [`Authorization`](./api-vc-auth-header.md) |
|
||||
| Typical Responses | 200 |
|
||||
|
||||
### Example Request Body
|
||||
|
||||
@ -433,12 +433,12 @@ generated with the path `m/12381/3600/i/42`.
|
||||
|
||||
### HTTP Specification
|
||||
|
||||
| Property | Specification |
|
||||
| --- |--- |
|
||||
Path | `/lighthouse/validators/mnemonic`
|
||||
Method | POST
|
||||
Required Headers | [`Authorization`](./api-vc-auth-header.md)
|
||||
Typical Responses | 200
|
||||
| Property | Specification |
|
||||
|-------------------|--------------------------------------------|
|
||||
| Path | `/lighthouse/validators/mnemonic` |
|
||||
| Method | POST |
|
||||
| Required Headers | [`Authorization`](./api-vc-auth-header.md) |
|
||||
| Typical Responses | 200 |
|
||||
|
||||
### Example Request Body
|
||||
|
||||
@ -479,12 +479,12 @@ Create any number of new validators, all of which will refer to a
|
||||
|
||||
### HTTP Specification
|
||||
|
||||
| Property | Specification |
|
||||
| --- |--- |
|
||||
Path | `/lighthouse/validators/web3signer`
|
||||
Method | POST
|
||||
Required Headers | [`Authorization`](./api-vc-auth-header.md)
|
||||
Typical Responses | 200, 400
|
||||
| Property | Specification |
|
||||
|-------------------|--------------------------------------------|
|
||||
| Path | `/lighthouse/validators/web3signer` |
|
||||
| Method | POST |
|
||||
| Required Headers | [`Authorization`](./api-vc-auth-header.md) |
|
||||
| Typical Responses | 200, 400 |
|
||||
|
||||
### Example Request Body
|
||||
|
||||
|
@ -4,10 +4,10 @@ When publishing releases, Lighthouse will include an "Update Priority" section i
|
||||
|
||||
The "Update Priority" section will include a table which may appear like so:
|
||||
|
||||
|User Class |Beacon Node | Validator Client|
|
||||
--- | --- | ---
|
||||
|Staking Users| Medium Priority | Low Priority |
|
||||
|Non-Staking Users| Low Priority|---|
|
||||
| User Class | Beacon Node | Validator Client |
|
||||
|-------------------|-----------------|------------------|
|
||||
| Staking Users | Medium Priority | Low Priority |
|
||||
| Non-Staking Users | Low Priority | --- |
|
||||
|
||||
To understand this table, the following terms are important:
|
||||
|
||||
|
@ -10,7 +10,7 @@ coinbase and the recipient of other fees or rewards.
|
||||
|
||||
There is no guarantee that an execution node will use the `suggested_fee_recipient` to collect fees,
|
||||
it may use any address it chooses. It is assumed that an honest execution node *will* use the
|
||||
`suggested_fee_recipient`, but users should note this trust assumption. Check out the
|
||||
`suggested_fee_recipient`, but users should note this trust assumption. Check out the
|
||||
[strict fee recipient](#strict-fee-recipient) section for how to mitigate this assumption.
|
||||
|
||||
The `suggested_fee_recipient` can be provided to the VC, who will transmit it to the BN. The BN also
|
||||
@ -64,10 +64,10 @@ validator client does not transmit a `suggested_fee_recipient` to the BN.
|
||||
|
||||
## Strict Fee Recipient
|
||||
|
||||
If the flag `--strict-fee-recipient` is set in the validator client, Lighthouse will refuse to sign any block whose
|
||||
`fee_recipient` does not match the `suggested_fee_recipient` sent by this validator. This applies to both the normal
|
||||
block proposal flow, as well as block proposals through the builder API. Proposals through the builder API are more likely
|
||||
to have a discrepancy in `fee_recipient` so you should be aware of how your connected relay sends proposer payments before
|
||||
If the flag `--strict-fee-recipient` is set in the validator client, Lighthouse will refuse to sign any block whose
|
||||
`fee_recipient` does not match the `suggested_fee_recipient` sent by this validator. This applies to both the normal
|
||||
block proposal flow, as well as block proposals through the builder API. Proposals through the builder API are more likely
|
||||
to have a discrepancy in `fee_recipient` so you should be aware of how your connected relay sends proposer payments before
|
||||
using this flag. If this flag is used, a fee recipient mismatch in the builder API flow will result in a fallback to the
|
||||
local execution engine for payload construction, where a strict fee recipient check will still be applied.
|
||||
|
||||
@ -79,12 +79,12 @@ for setting the fee recipient dynamically for a given public key. When used, the
|
||||
will be saved in `validator_definitions.yml` so that it persists across restarts of the validator
|
||||
client.
|
||||
|
||||
| Property | Specification |
|
||||
| --- | --- |
|
||||
Path | `/eth/v1/validator/{pubkey}/feerecipient`
|
||||
Method | POST
|
||||
Required Headers | [`Authorization`](./api-vc-auth-header.md)
|
||||
Typical Responses | 202, 404
|
||||
| Property | Specification |
|
||||
|-------------------|--------------------------------------------|
|
||||
| Path | `/eth/v1/validator/{pubkey}/feerecipient` |
|
||||
| Method | POST |
|
||||
| Required Headers | [`Authorization`](./api-vc-auth-header.md) |
|
||||
| Typical Responses | 202, 404 |
|
||||
|
||||
#### Example Request Body
|
||||
```json
|
||||
@ -114,12 +114,12 @@ null
|
||||
|
||||
The same path with a `GET` request can be used to query the fee recipient for a given public key at any time.
|
||||
|
||||
| Property | Specification |
|
||||
| --- | --- |
|
||||
Path | `/eth/v1/validator/{pubkey}/feerecipient`
|
||||
Method | GET
|
||||
Required Headers | [`Authorization`](./api-vc-auth-header.md)
|
||||
Typical Responses | 200, 404
|
||||
| Property | Specification |
|
||||
|-------------------|--------------------------------------------|
|
||||
| Path | `/eth/v1/validator/{pubkey}/feerecipient` |
|
||||
| Method | GET |
|
||||
| Required Headers | [`Authorization`](./api-vc-auth-header.md) |
|
||||
| Typical Responses | 200, 404 |
|
||||
|
||||
```bash
|
||||
DATADIR=$HOME/.lighthouse/mainnet
|
||||
@ -146,12 +146,12 @@ curl -X GET \
|
||||
The same path with a `DELETE` request can be used to remove the fee recipient for a given public key at any time.
|
||||
This is useful if you want the fee recipient to fall back to the validator client (or beacon node) default.
|
||||
|
||||
| Property | Specification |
|
||||
| --- | --- |
|
||||
Path | `/eth/v1/validator/{pubkey}/feerecipient`
|
||||
Method | DELETE
|
||||
Required Headers | [`Authorization`](./api-vc-auth-header.md)
|
||||
Typical Responses | 204, 404
|
||||
| Property | Specification |
|
||||
|-------------------|--------------------------------------------|
|
||||
| Path | `/eth/v1/validator/{pubkey}/feerecipient` |
|
||||
| Method | DELETE |
|
||||
| Required Headers | [`Authorization`](./api-vc-auth-header.md) |
|
||||
| Typical Responses | 204, 404 |
|
||||
|
||||
```bash
|
||||
DATADIR=$HOME/.lighthouse/mainnet
|
||||
|
Loading…
Reference in New Issue
Block a user