From e29765e1181b2ed6b632197a9e0abdd9f4a34682 Mon Sep 17 00:00:00 2001 From: Justin Traglia Date: Wed, 27 Jul 2022 00:51:07 +0000 Subject: [PATCH] Reformat tables and add borders (#3377) ## Proposed Changes This PR reformats Markdown tables and ensures all tables have borders. --- book/src/advanced_database.md | 10 +-- book/src/api-vc-endpoints.md | 132 ++++++++++++++-------------- book/src/installation-priorities.md | 8 +- book/src/suggested-fee-recipient.md | 46 +++++----- 4 files changed, 98 insertions(+), 98 deletions(-) diff --git a/book/src/advanced_database.md b/book/src/advanced_database.md index 178936cf6..397d9a28b 100644 --- a/book/src/advanced_database.md +++ b/book/src/advanced_database.md @@ -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 diff --git a/book/src/api-vc-endpoints.md b/book/src/api-vc-endpoints.md index 69cd83db5..9aedf6e24 100644 --- a/book/src/api-vc-endpoints.md +++ b/book/src/api-vc-endpoints.md @@ -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 diff --git a/book/src/installation-priorities.md b/book/src/installation-priorities.md index 69d871c39..0008e327b 100644 --- a/book/src/installation-priorities.md +++ b/book/src/installation-priorities.md @@ -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: diff --git a/book/src/suggested-fee-recipient.md b/book/src/suggested-fee-recipient.md index 35338549e..c401abfb7 100644 --- a/book/src/suggested-fee-recipient.md +++ b/book/src/suggested-fee-recipient.md @@ -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