website: proofreading (#28988)

pull/29096/head
Kugo 9 months ago committed by GitHub
parent 1e299c07d0
commit 9f6b056195
No known key found for this signature in database
GPG Key ID: B5690EEEBB952194
  1. 2
      README.md
  2. 2
      docs/fundamentals/logs.md
  3. 2
      docs/interacting-with-geth/rpc/ns-personal.md
  4. 2
      docs/monitoring/understanding-dashboards.md
  5. 2
      docs/tools/clef/tutorial.md

@ -40,7 +40,7 @@ After adding a page, you will also need to list it in `/src/data/documentation-l
#### Adding notes to a doc #### Adding notes to a doc
Notes in documentation pages are highlighted boxes (color depend on the current set dark/light theme). To add a note, wrap the note text in `<Note>` tage as follows: Notes in documentation pages are highlighted boxes (color depend on the current set dark/light theme). To add a note, wrap the note text in `<Note>` tag as follows:
```markdown ```markdown
<Note>text to include in note</Note> <Note>text to include in note</Note>

@ -128,7 +128,7 @@ INFO [07-28|10:30:18.658] Imported new block headers count=1 el
INFO [07-28|10:30:21.665] Imported new state entries INFO [07-28|10:30:21.665] Imported new state entries
``` ```
For state sync, Geth reports when the state heal is in progress. This can take a long time. The log message includes values for the number of `accounts`, `slots`, `codes` and `nodes` that were downloaded in the current healing phase, and the pending field is the number of state entires waiting to be downloaded. The `pending` value is not necessarily the number of state entries remaining until the healing is finished. As the blockchain progresses the state trie is updated and therefore the data that need to be downloaded to heal the trie can increase as well as decrease over time. Ultimately, the state should heal faster than the blockchain progresses so the node can get in sync. When the state healing is finished there is a post-sync snapshot generation phase. The node is not in sync until the state healing phase is over. If the node is still regularly reporting `State heal in progress` it is not yet in sync - the state healing is still ongoing. For state sync, Geth reports when the state heal is in progress. This can take a long time. The log message includes values for the number of `accounts`, `slots`, `codes` and `nodes` that were downloaded in the current healing phase, and the pending field is the number of state entries waiting to be downloaded. The `pending` value is not necessarily the number of state entries remaining until the healing is finished. As the blockchain progresses the state trie is updated and therefore the data that need to be downloaded to heal the trie can increase as well as decrease over time. Ultimately, the state should heal faster than the blockchain progresses so the node can get in sync. When the state healing is finished there is a post-sync snapshot generation phase. The node is not in sync until the state healing phase is over. If the node is still regularly reporting `State heal in progress` it is not yet in sync - the state healing is still ongoing.
```terminal ```terminal
INFO [07-28|10:30:21.965] State heal in progress accounts=169,633@7.48MiB slots=57314@4.17MiB codes=4895@38.14MiB nodes=43,293,196@11.70GiB pending=112,626 INFO [07-28|10:30:21.965] State heal in progress accounts=169,633@7.48MiB slots=57314@4.17MiB codes=4895@38.14MiB nodes=43,293,196@11.70GiB pending=112,626

@ -208,7 +208,7 @@ curl --data '{"id": 2, "jsonrpc": "2.0", "method": "account_signTransaction", "p
## Methods without replacements ## Methods without replacements
There are a few methods that were available in the `personal` namepsace that have been deprecated without replacements. These are: There are a few methods that were available in the `personal` namespace that have been deprecated without replacements. These are:
### personal_unlockAccount ### personal_unlockAccount

@ -132,7 +132,7 @@ The transaction processing panel tracks the time taken to complete the various t
- **executable discard**: rate that valid transactions are dropped from the transaction pool, e.g. because it is already known. - **executable discard**: rate that valid transactions are dropped from the transaction pool, e.g. because it is already known.
- **executable replace**: rate that valid transactions are replaced with a new one from same sender with same nonce but higher gas - **executable replace**: rate that valid transactions are replaced with a new one from same sender with same nonce but higher gas
- **executable ratelimit**: rate that valid transactions are dropped due to rate-limiting - **executable ratelimit**: rate that valid transactions are dropped due to rate-limiting
- **executable nofunds**: rate that valid transations are dropped due to running out of ETH to pay gas - **executable nofunds**: rate that valid transactions are dropped due to running out of ETH to pay gas
- **gapped discard**: rate that queued transactions are discarded from the transaction pool - **gapped discard**: rate that queued transactions are discarded from the transaction pool
- **gapped replace**: rate that queued transactions are replaced with a new one from same sender with same nonce but higher gas - **gapped replace**: rate that queued transactions are replaced with a new one from same sender with same nonce but higher gas
- **gapped ratelimit**: rate that queued transactions are dropped due to rate limiting - **gapped ratelimit**: rate that queued transactions are dropped due to rate limiting

@ -50,7 +50,7 @@ _For readability purposes, we'll remove the WARNING printout, user confirmation
## Remote interactions {#remote-interactions} ## Remote interactions {#remote-interactions}
This tutorial will use Clef with Geth on the Goerli testnet. The accounts used will be in the Goerli keystore with the path `~/go-ethereum/goerli-data/keystore`. The tutorial assumes there are two accounts in this keystore. Instructions for creating accounts can be found on the [Account managament page](/docs/fundamentals/account-management). Note that Clef can also interact with hardware wallets, although that is not demonstrated here. This tutorial will use Clef with Geth on the Goerli testnet. The accounts used will be in the Goerli keystore with the path `~/go-ethereum/goerli-data/keystore`. The tutorial assumes there are two accounts in this keystore. Instructions for creating accounts can be found on the [Account management page](/docs/fundamentals/account-management). Note that Clef can also interact with hardware wallets, although that is not demonstrated here.
Clef should be started before Geth, otherwise Geth will complain that it cannot find a Clef instance to connect to. Clef should be started with the correct `chainid` for Goerli. Clef itself does not connect to a blockchain, but the `chainID` parameter is included in the data that is aggregated to form a signature. Clef also needs a path to the correct keystore passed to the `--keystore` command. A custom path to the config directory can also be provided. This is where the `ipc` file will be saved which is needed to connect Clef to Geth: Clef should be started before Geth, otherwise Geth will complain that it cannot find a Clef instance to connect to. Clef should be started with the correct `chainid` for Goerli. Clef itself does not connect to a blockchain, but the `chainID` parameter is included in the data that is aggregated to form a signature. Clef also needs a path to the correct keystore passed to the `--keystore` command. A custom path to the config directory can also be provided. This is where the `ipc` file will be saved which is needed to connect Clef to Geth:

Loading…
Cancel
Save