cerc-io/lighthouse
16
0
Fork 0
Code Issues 1 Pull Requests Packages Projects Releases Wiki Activity

Correct typos book (#3099)

Browse Source 
## Issue Addressed

No issue

## Proposed Changes

Correct typos in book

## Additional Info

Nothing to add


Co-authored-by: Emilia Hane <58548332+emhane@users.noreply.github.com>
This commit is contained in:
Emilia Hane 2022-03-20 22:48:15 +00:00
parent ae5b141dc4
commit 2aabcaaaed
5 changed files with 6 additions and 6 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

4
book/src/advanced_database.md
View File

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

2
book/src/api-bn.md
View File

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

2
book/src/suggested-fee-recipient.md
View File

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

2
book/src/validator-web3signer.md
View File

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

2
book/src/voluntary-exit.md
View File

@ -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 <https://ethereum.org/en/upgrades/#roadmap>.
To understand the phased rollout strategy for Ethereum upgrades, please visit <https://ethereum.org/en/upgrades/#roadmap>.