diff --git a/book/src/advanced_database.md b/book/src/advanced_database.md index b562b31dd..02a344c74 100644 --- a/book/src/advanced_database.md +++ b/book/src/advanced_database.md @@ -36,8 +36,8 @@ is 32, and the maximum is 8192. The values shown in the table are approximate, calculated using a simple heuristic: each `BeaconState` consumes around 18MB of disk space, and each block replayed takes around 5ms. The **Yearly Disk Usage** column shows the approx size of the freezer DB _alone_ (hot DB not included), -and the **Load Historical State** time is the worst-case load time for a state in the last slot of -an epoch. +and the **Load Historical State** time is the worst-case load time for a state in the last slot +before a restore point. To configure your Lighthouse node's database with a non-default SPRP, run your Beacon Node with the `--slots-per-restore-point` flag: diff --git a/book/src/api-bn.md b/book/src/api-bn.md index f806f8783..481c00169 100644 --- a/book/src/api-bn.md +++ b/book/src/api-bn.md @@ -137,7 +137,7 @@ However, even when serving the HTTP API server over TLS, it should not be exposed publicly without one of the security measures suggested in the [Security](#security) section. -Below is an simple example serving the HTTP API over TLS using a +Below is a simple example serving the HTTP API over TLS using a self-signed certificate on Linux: ### Enabling TLS on a beacon node diff --git a/book/src/suggested-fee-recipient.md b/book/src/suggested-fee-recipient.md index 6513495fe..3ff71ec7d 100644 --- a/book/src/suggested-fee-recipient.md +++ b/book/src/suggested-fee-recipient.md @@ -12,7 +12,7 @@ There is no guarantee that an execution node will use the `suggested_fee_recipie 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. -The `suggested_fee_recipient` can be provided to the VC, who will transmit it to the BN. The also BN +The `suggested_fee_recipient` can be provided to the VC, who will transmit it to the BN. The BN also has a choice regarding the fee recipient it passes to the execution node, creating another noteworthy trust assumption. diff --git a/book/src/validator-web3signer.md b/book/src/validator-web3signer.md index e65504095..2de641d48 100644 --- a/book/src/validator-web3signer.md +++ b/book/src/validator-web3signer.md @@ -52,5 +52,5 @@ filesystem of the VC) to encrypt the communications between the VC and Web3Signe > The `request_timeout_ms` key can also be specified. Use this key to override the default timeout > with a new timeout in milliseconds. This is the timeout before requests to Web3Signer are -> considered to be failures. Setting a value that it too-long may create contention and late duties +> considered to be failures. Setting a value that is too long may create contention and late duties > in the VC. Setting it too short will result in failed signatures and therefore missed duties. diff --git a/book/src/voluntary-exit.md b/book/src/voluntary-exit.md index 0a26cbac1..69c2d7598 100644 --- a/book/src/voluntary-exit.md +++ b/book/src/voluntary-exit.md @@ -15,7 +15,7 @@ This number can be much higher depending on how many other validators are queued Even though users can perform a voluntary exit in phase 0, they **cannot withdraw their exited funds at this point in time**. This implies that the staked funds are effectively **frozen** until withdrawals are enabled in future phases. -To understand the phased rollout strategy for Ethereum upgrages, please visit . +To understand the phased rollout strategy for Ethereum upgrades, please visit .