Reformat tables and add borders (#3377)

## Proposed Changes

This PR reformats Markdown tables and ensures all tables have borders.
This commit is contained in:
Justin Traglia 2022-07-27 00:51:07 +00:00
parent 0f62d900fe
commit e29765e118
4 changed files with 98 additions and 98 deletions

View File

@ -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

View File

@ -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

View File

@ -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:

View File

@ -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