gnosis/lighthouse
1
0
Fork 0
mirror of https://github.com/sigp/lighthouse.git synced 2026-05-07 16:55:46 +00:00
Code Issues Packages Projects Releases Wiki Activity

Reformat tables and add borders (#3377)

Browse Source 
## 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
Download Patch File Download Diff File Expand all files Collapse all files

10
book/src/advanced_database.md
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 frequent restore points, while a higher SPRP corresponds to less frequent. The table below shows
some example values. some example values.
| Use Case | SPRP | Yearly Disk Usage | Load Historical State | | Use Case | SPRP | Yearly Disk Usage | Load Historical State |
| ---------------------- | -------------- | ----------------- | --------------------- | |--------------------------|------|-------------------|-----------------------|
| Block explorer/analysis | 32 | 1.4 TB | 155 ms | | Block explorer/analysis | 32 | 1.4 TB | 155 ms |
| Hobbyist (prev. default) | 2048 | 23.1 GB | 10.2 s | | Hobbyist (prev. default) | 2048 | 23.1 GB | 10.2 s |
| Validator only (default) | 8192 | 5.7 GB | 41 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 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 load time are both linear – doubling SPRP halves disk usage and doubles load time. The minimum SPRP

132
book/src/api-vc-endpoints.md
View File

@@ -24,12 +24,12 @@ Returns the software version and `git` commit hash for the Lighthouse binary.
### HTTP Specification ### HTTP Specification
| Property | Specification | | Property | Specification |
| --- |--- | |-------------------|--------------------------------------------|
Path | `/lighthouse/version` | Path | `/lighthouse/version` |
Method | GET | Method | GET |
Required Headers | [`Authorization`](./api-vc-auth-header.md) | Required Headers | [`Authorization`](./api-vc-auth-header.md) |
Typical Responses | 200 | Typical Responses | 200 |
### Example Response Body ### Example Response Body
@@ -47,12 +47,12 @@ Returns information regarding the health of the host machine.
### HTTP Specification ### HTTP Specification
| Property | Specification | | Property | Specification |
| --- |--- | |-------------------|--------------------------------------------|
Path | `/lighthouse/health` | Path | `/lighthouse/health` |
Method | GET | Method | GET |
Required Headers | [`Authorization`](./api-vc-auth-header.md) | Required Headers | [`Authorization`](./api-vc-auth-header.md) |
Typical Responses | 200 | Typical Responses | 200 |
*Note: this endpoint is presently only available on Linux.* *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 ### HTTP Specification
| Property | Specification | | Property | Specification |
| --- |--- | |-------------------|--------------------------------------------|
Path | `/lighthouse/spec` | Path | `/lighthouse/spec` |
Method | GET | Method | GET |
Required Headers | [`Authorization`](./api-vc-auth-header.md) | Required Headers | [`Authorization`](./api-vc-auth-header.md) |
Typical Responses | 200 | Typical Responses | 200 |
### Example Response Body ### Example Response Body
@@ -168,12 +168,12 @@ file may be read by a local user with access rights.
### HTTP Specification ### HTTP Specification
| Property | Specification | | Property | Specification |
| --- |--- | |-------------------|--------------------|
Path | `/lighthouse/auth` | Path | `/lighthouse/auth` |
Method | GET | Method | GET |
Required Headers | - | Required Headers | - |
Typical Responses | 200 | Typical Responses | 200 |
### Example Path ### Example Path
@@ -195,12 +195,12 @@ Lists all validators managed by this validator client.
### HTTP Specification ### HTTP Specification
| Property | Specification | | Property | Specification |
| --- |--- | |-------------------|--------------------------------------------|
Path | `/lighthouse/validators` | Path | `/lighthouse/validators` |
Method | GET | Method | GET |
Required Headers | [`Authorization`](./api-vc-auth-header.md) | Required Headers | [`Authorization`](./api-vc-auth-header.md) |
Typical Responses | 200 | Typical Responses | 200 |
### Example Response Body ### Example Response Body
@@ -232,12 +232,12 @@ Get a validator by their `voting_pubkey`.
### HTTP Specification ### HTTP Specification
| Property | Specification | | Property | Specification |
| --- |--- | |-------------------|--------------------------------------------|
Path | `/lighthouse/validators/:voting_pubkey` | Path | `/lighthouse/validators/:voting_pubkey` |
Method | GET | Method | GET |
Required Headers | [`Authorization`](./api-vc-auth-header.md) | Required Headers | [`Authorization`](./api-vc-auth-header.md) |
Typical Responses | 200, 400 | Typical Responses | 200, 400 |
### Example Path ### Example Path
@@ -262,12 +262,12 @@ Update some values for the validator with `voting_pubkey`.
### HTTP Specification ### HTTP Specification
| Property | Specification | | Property | Specification |
| --- |--- | |-------------------|--------------------------------------------|
Path | `/lighthouse/validators/:voting_pubkey` | Path | `/lighthouse/validators/:voting_pubkey` |
Method | PATCH | Method | PATCH |
Required Headers | [`Authorization`](./api-vc-auth-header.md) | Required Headers | [`Authorization`](./api-vc-auth-header.md) |
Typical Responses | 200, 400 | Typical Responses | 200, 400 |
### Example Path ### Example Path
@@ -301,12 +301,12 @@ Validators are generated from the mnemonic according to
### HTTP Specification ### HTTP Specification
| Property | Specification | | Property | Specification |
| --- |--- | |-------------------|--------------------------------------------|
Path | `/lighthouse/validators` | Path | `/lighthouse/validators` |
Method | POST | Method | POST |
Required Headers | [`Authorization`](./api-vc-auth-header.md) | Required Headers | [`Authorization`](./api-vc-auth-header.md) |
Typical Responses | 200 | Typical Responses | 200 |
### Example Request Body ### Example Request Body
@@ -359,12 +359,12 @@ Import a keystore into the validator client.
### HTTP Specification ### HTTP Specification
| Property | Specification | | Property | Specification |
| --- |--- | |-------------------|--------------------------------------------|
Path | `/lighthouse/validators/keystore` | Path | `/lighthouse/validators/keystore` |
Method | POST | Method | POST |
Required Headers | [`Authorization`](./api-vc-auth-header.md) | Required Headers | [`Authorization`](./api-vc-auth-header.md) |
Typical Responses | 200 | Typical Responses | 200 |
### Example Request Body ### Example Request Body
@@ -433,12 +433,12 @@ generated with the path `m/12381/3600/i/42`.
### HTTP Specification ### HTTP Specification
| Property | Specification | | Property | Specification |
| --- |--- | |-------------------|--------------------------------------------|
Path | `/lighthouse/validators/mnemonic` | Path | `/lighthouse/validators/mnemonic` |
Method | POST | Method | POST |
Required Headers | [`Authorization`](./api-vc-auth-header.md) | Required Headers | [`Authorization`](./api-vc-auth-header.md) |
Typical Responses | 200 | Typical Responses | 200 |
### Example Request Body ### Example Request Body
@@ -479,12 +479,12 @@ Create any number of new validators, all of which will refer to a
### HTTP Specification ### HTTP Specification
| Property | Specification | | Property | Specification |
| --- |--- | |-------------------|--------------------------------------------|
Path | `/lighthouse/validators/web3signer` | Path | `/lighthouse/validators/web3signer` |
Method | POST | Method | POST |
Required Headers | [`Authorization`](./api-vc-auth-header.md) | Required Headers | [`Authorization`](./api-vc-auth-header.md) |
Typical Responses | 200, 400 | Typical Responses | 200, 400 |
### Example Request Body ### Example Request Body

8
book/src/installation-priorities.md
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: The "Update Priority" section will include a table which may appear like so:
|User Class |Beacon Node | Validator Client| | User Class | Beacon Node | Validator Client |
--- | --- | --- |-------------------|-----------------|------------------|
|Staking Users| Medium Priority | Low Priority | | Staking Users | Medium Priority | Low Priority |
|Non-Staking Users| Low Priority|---| | Non-Staking Users | Low Priority | --- |
To understand this table, the following terms are important: To understand this table, the following terms are important:

46
book/src/suggested-fee-recipient.md
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, 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 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. [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 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 ## Strict Fee Recipient
If the flag `--strict-fee-recipient` is set in the validator client, Lighthouse will refuse to sign any block whose 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 `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 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 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 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. 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 will be saved in `validator_definitions.yml` so that it persists across restarts of the validator
client. client.
| Property | Specification | | Property | Specification |
| --- | --- | |-------------------|--------------------------------------------|
Path | `/eth/v1/validator/{pubkey}/feerecipient` | Path | `/eth/v1/validator/{pubkey}/feerecipient` |
Method | POST | Method | POST |
Required Headers | [`Authorization`](./api-vc-auth-header.md) | Required Headers | [`Authorization`](./api-vc-auth-header.md) |
Typical Responses | 202, 404 | Typical Responses | 202, 404 |
#### Example Request Body #### Example Request Body
```json ```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. 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 | | Property | Specification |
| --- | --- | |-------------------|--------------------------------------------|
Path | `/eth/v1/validator/{pubkey}/feerecipient` | Path | `/eth/v1/validator/{pubkey}/feerecipient` |
Method | GET | Method | GET |
Required Headers | [`Authorization`](./api-vc-auth-header.md) | Required Headers | [`Authorization`](./api-vc-auth-header.md) |
Typical Responses | 200, 404 | Typical Responses | 200, 404 |
```bash ```bash
DATADIR=$HOME/.lighthouse/mainnet 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. 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. This is useful if you want the fee recipient to fall back to the validator client (or beacon node) default.
| Property | Specification | | Property | Specification |
| --- | --- | |-------------------|--------------------------------------------|
Path | `/eth/v1/validator/{pubkey}/feerecipient` | Path | `/eth/v1/validator/{pubkey}/feerecipient` |
Method | DELETE | Method | DELETE |
Required Headers | [`Authorization`](./api-vc-auth-header.md) | Required Headers | [`Authorization`](./api-vc-auth-header.md) |
Typical Responses | 204, 404 | Typical Responses | 204, 404 |
```bash ```bash
DATADIR=$HOME/.lighthouse/mainnet DATADIR=$HOME/.lighthouse/mainnet