status-im
/
nimbus-eth2
mirror of https://github.com/status-im/nimbus-eth2.git
2
0
Fork 0
Code Issues Projects Releases Wiki Activity

docs: fix typos (#5571)

This commit is contained in:
xiaolou86 2023-11-06 11:56:07 +08:00 committed by GitHub
parent e4dacc30c4
commit 40196b75d0
No known key found for this signature in database
GPG Key ID: 4AEE18F83AFDEB23
4 changed files with 4 additions and 4 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

2
beacon_chain/sync/README.md
View File

@ -21,7 +21,7 @@ Blocks are received by batch:
- in case of failure:
- `push(SyncQueue, SyncRequest)` is called to reschedule the sync request.
Every second when sync is not in progress, the beacon node will ask the RequestManager to download all missing blocks currently in quarantaine.
Every second when sync is not in progress, the beacon node will ask the RequestManager to download all missing blocks currently in quarantine.
- via `handleMissingBlocks`
- which calls `fetchAncestorBlocks`
- which asynchronously enqueue the request in the SharedBlockQueue `AsyncQueue[BlockEntry]`.

2
docs/e2store.md
View File

@ -327,7 +327,7 @@ An era is typically `8192` slots (in the mainnet configuration), or roughly 27.3
## What happens after the merge?
Era files will store execution block contents, but not execution states (these are too large) - a full era history thus gives the full ethereum history from the merge onwards for convenient cold storage. Work is underway to similarily cover the rest of history.
Era files will store execution block contents, but not execution states (these are too large) - a full era history thus gives the full ethereum history from the merge onwards for convenient cold storage. Work is underway to similarly cover the rest of history.
## Which state should be stored in the era file?

2
docs/the_nimbus_book/src/web3signer.md
View File

@ -40,7 +40,7 @@ The fields have the following semantics:
5. `remote` - An URL of a remote signing server.
6. `remotes` - A [distributed keystore](#distributed-keystores) configuration including two or more remote signing servers.
7. `ignore_ssl_verification` - An optional boolean flag allowing the use of self-signed certificates by the signing server.
8. `proven_block_properties` - When the `verifying-web3signer` type is used, this is a list of locations withing the SSZ block body for which the block signing requests will contain additional Merkle proofs, allowing the signer to verify certain details about the signed blocks (e.g. the `fee_recipient` value).
8. `proven_block_properties` - When the `verifying-web3signer` type is used, this is a list of locations within the SSZ block body for which the block signing requests will contain additional Merkle proofs, allowing the signer to verify certain details about the signed blocks (e.g. the `fee_recipient` value).
!!! info
The current version of the remote keystore format is `3` which adds support for the experimental [verifying web3signer setups](#verifying-web3signer).

2
ncli/README.md
View File

@ -1,6 +1,6 @@
# Introduction
`ncli` is a set of low level / debugging tools to interact with the nimbus [beacon chain specification](https://github.com/ethereum/consensus-specs/tree/dev/specs) implementation, simliar to [zcli](https://github.com/protolambda/zcli). With it, you explore SSZ, make state transitions and compute hash tree roots.
`ncli` is a set of low level / debugging tools to interact with the nimbus [beacon chain specification](https://github.com/ethereum/consensus-specs/tree/dev/specs) implementation, similar to [zcli](https://github.com/protolambda/zcli). With it, you explore SSZ, make state transitions and compute hash tree roots.
# Tools