website: fix typos
This commit is contained in:
parent
f0d0184b2b
commit
3c41789451
|
@ -187,7 +187,7 @@ Things to note about the call tracer:
|
|||
- `onlyTopCall: true` instructs the tracer to only process the main (top-level) call and none of the sub-calls. This avoids extra processing for each call frame if only the top-level call info are required.
|
||||
- `withLog: true` instructs the tracer to also collect the logs emitted during each call.
|
||||
|
||||
Example invokation with the `onlyTopCall` flag:
|
||||
Example invocation with the `onlyTopCall` flag:
|
||||
|
||||
```terminal
|
||||
> debug.traceTransaction('0xc73e70f6d60e63a71dabf90b9983f2cdd56b0cb7bcf1a205f638d630a95bba73', { tracer: 'callTracer', tracerConfig: { onlyTopCall: true } })
|
||||
|
|
|
@ -19,7 +19,7 @@ Vulnerabilities typically take two forms:
|
|||
|
||||
In most cases so far, vulnerabilities in Geth have been of the second type, where the health of the network is a concern, rather than individual node operators. For such issues, Geth reserves the right to silently patch and ship fixes in new releases.
|
||||
|
||||
### Why silent patches {#why-slient-patches}
|
||||
### Why silent patches {#why-silent-patches}
|
||||
|
||||
In the case of Ethereum, it takes a lot of time (weeks, months) to get node operators to update even to a scheduled hard fork. If we were to highlight that a release contains important consensus or DoS fixes, there is always a risk of someone trying to beat node operators to the punch, and exploit the vulnerability. Delaying a potential attack sufficiently to make the majority of node operators immune may be worth the temporary loss of transparency.
|
||||
|
||||
|
@ -43,7 +43,7 @@ In keeping with this policy, we have taken inspiration from [Solidity bug disclo
|
|||
|
||||
There is a JSON-formatted list ([`vulnerabilities.json`](/docs/vulnerabilities/vulnerabilities.json)) of some of the known security-relevant vulnerabilities concerning Geth.
|
||||
|
||||
As of version `1.9.25`, Geth has a built-in command to check whether it is affected by any publically disclosed vulnerability, using the command `geth version-check`. This command will fetch the latest json file (and the accompanying [signature-file](/docs/vulnerabilities/vulnerabilities.json.minisig), and cross-check the data against its own version number.
|
||||
As of version `1.9.25`, Geth has a built-in command to check whether it is affected by any publicly disclosed vulnerability, using the command `geth version-check`. This command will fetch the latest json file (and the accompanying [signature-file](/docs/vulnerabilities/vulnerabilities.json.minisig), and cross-check the data against its own version number.
|
||||
|
||||
The list of vulnerabilities was started in November 2020, and covers mainly `v1.9.7` and forward.
|
||||
|
||||
|
|
|
@ -24,4 +24,4 @@ Note also that there is a page explaining common log messages that are often que
|
|||
- [Pruning](/docs/fundamentals/pruning): read about Geth's data pruning options
|
||||
- [Private networks](/docs/fundamentals/private-network): learn hoe to set up a private network of multiple Geth nodes
|
||||
- [Light clients](/docs/fundamentals/les): read about Geth's light mode.
|
||||
- [Mining](/docs/fundamentals/mining): read about the minign algorithms Geth used to use to secure Ethereum before the network switched to proof-of-stake.
|
||||
- [Mining](/docs/fundamentals/mining): read about the mining algorithms Geth used to use to secure Ethereum before the network switched to proof-of-stake.
|
||||
|
|
|
@ -40,7 +40,7 @@ There are occasions when Geth simply fails to connect to peers. The common reaso
|
|||
|
||||
- Some firewall configurations can prohibit UDP traffic. The static nodes feature or `admin.addPeer()` on the console can be used to configure connections manually.
|
||||
|
||||
- Running Geth in [light mode](/docs/fundamentals/les) often leads to connectivity issues because there are few nodes running light servers. There is no easy fix for this except to switch Geth out of light mode. **Note that light mode does not curently work on proof-of-stake networks**.
|
||||
- Running Geth in [light mode](/docs/fundamentals/les) often leads to connectivity issues because there are few nodes running light servers. There is no easy fix for this except to switch Geth out of light mode. **Note that light mode does not currently work on proof-of-stake networks**.
|
||||
|
||||
- The public test network Geth is connecting to might be deprecated or have a low number of active nodes that are hard to find. In this case, the best action is to switch to an alternative test network.
|
||||
|
||||
|
|
|
@ -31,7 +31,7 @@ Geth's PoW algorithm, [Ethash](https://ethereum.org/en/developers/docs/consensus
|
|||
|
||||
#### Clique {#clique}
|
||||
|
||||
Clique consensus is a PoA system where new blocks can be created by authorized 'signers' only. The clique consenus protocol is specified in [EIP-225](https://eips.ethereum.org/EIPS/eip-225). The initial set of authorized signers is configured in the genesis block. Signers can be authorized and de-authorized using a voting mechanism, thus allowing the set of signers to change while the blockchain operates. Clique can be configured to target any block time (within reasonable limits) since it isn't tied to the difficulty adjustment.
|
||||
Clique consensus is a PoA system where new blocks can be created by authorized 'signers' only. The clique consensus protocol is specified in [EIP-225](https://eips.ethereum.org/EIPS/eip-225). The initial set of authorized signers is configured in the genesis block. Signers can be authorized and de-authorized using a voting mechanism, thus allowing the set of signers to change while the blockchain operates. Clique can be configured to target any block time (within reasonable limits) since it isn't tied to the difficulty adjustment.
|
||||
|
||||
### Creating The Genesis Block {#creating-genesis-block}
|
||||
|
||||
|
@ -151,7 +151,7 @@ geth init --datadir data genesis.json
|
|||
|
||||
With the node configured and initialized, the next step is to set up a peer-to-peer network. This requires a bootstrap node. The bootstrap node is a normal node that is designated to be the entry point that other nodes use to join the network. Any node can be chosen to be the bootstrap node.
|
||||
|
||||
To configure a bootstrap node, the IP address of the machine the bootstrap node will run on must be known. The bootsrap node needs to know its own IP address so that it can broadcast it to other nodes. On a local machine this can be found using tools such as `ifconfig` and on cloud instances such as Amazon EC2 the IP address of the virtual machine can be found in the management console. Any firewalls must allow UDP and TCP traffic on port 30303.
|
||||
To configure a bootstrap node, the IP address of the machine the bootstrap node will run on must be known. The bootstrap node needs to know its own IP address so that it can broadcast it to other nodes. On a local machine this can be found using tools such as `ifconfig` and on cloud instances such as Amazon EC2 the IP address of the virtual machine can be found in the management console. Any firewalls must allow UDP and TCP traffic on port 30303.
|
||||
|
||||
The bootstrap node IP is set using the `--nat` flag (the command below contains an example address - replace it with the correct one).
|
||||
|
||||
|
@ -233,7 +233,7 @@ geth --datadir node1 account new
|
|||
This command returns a request for a password. Once a password has been provided the following information is returned to the terminal:
|
||||
|
||||
```terminal
|
||||
Your new account is locked with a password. Please give a password. Do not foget this password.
|
||||
Your new account is locked with a password. Please give a password. Do not forget this password.
|
||||
Password:
|
||||
Repeat password:
|
||||
|
||||
|
|
|
@ -50,7 +50,7 @@ The outputs look as follows:
|
|||
|
||||
These are all the data required to deploy the contract using the Geth Javascript console. Open the Javascript console using `./geth attach geth.ipc`.
|
||||
|
||||
Now, for convenice we can store the abi and bytecode in variables in the console:
|
||||
Now, for convenience we can store the abi and bytecode in variables in the console:
|
||||
|
||||
```js
|
||||
var abi = [
|
||||
|
|
|
@ -45,14 +45,14 @@ geth <other flags> --http
|
|||
The commands above use default HTTP/WS endpoints and only enables the default JSON-RPC libraries. To update the Websockets or HTTP endpoints used, or to add support for additional libraries, the `.addr` `.port` and `.api` flags can be used as follows:
|
||||
|
||||
```sh
|
||||
# define a custom http adress, custom http port and enable libraries
|
||||
# define a custom http address, custom http port and enable libraries
|
||||
geth <other commands> --http --http.addr 192.60.52.21 --http.port 8552 --http.api eth,web3,admin
|
||||
|
||||
# define a custom Websockets address and enable libraries
|
||||
geth <other commands> --ws --ws.addr 192.60.52.21 --ws.port 8552 --ws.api eth,web3,admin
|
||||
```
|
||||
|
||||
It is important to note that by default **some functionality, including account unlocking is forbidden when HTTP or Websockets access is enabled**. This is because an attacker that manages to access the node via the externally-exposed HTTP/WS port then control the unlocked account. This is not a hypothetical risk: **there are bots that continually scan for http-enabled Ethereum nodes to attack**"
|
||||
It is important to note that by default **some functionality, including account unlocking is forbidden when HTTP or Websockets access is enabled**. This is because an attacker that manages to access the node via the externally-exposed HTTP/WS port then control the unlocked account. This is not a hypothetical risk: **there are bots that continually scan for http-enabled Ethereum nodes to attack**
|
||||
|
||||
The Javascript console can also be connected to a Geth node using IPC. When Geth is started, a `geth.ipc` file is automatically generated and saved to the data directory. This file, or a custom path to a specific ipc file can be passed to `geth attach` as follows:
|
||||
|
||||
|
|
|
@ -7,7 +7,7 @@ The JSON-RPC API's `personal` namespace has historically been used to manage acc
|
|||
|
||||
## Method replacements
|
||||
|
||||
The following list shows each method from the `personal` namespace and the intended method in Clef that supercedes it.
|
||||
The following list shows each method from the `personal` namespace and the intended method in Clef that supersedes it.
|
||||
|
||||
### personal_listAccounts
|
||||
|
||||
|
@ -62,7 +62,7 @@ clef list-wallets
|
|||
|
||||
### personal_newAccount
|
||||
|
||||
`personal_newAccount` was used to create a new accoutn and save it in the keystore. Clef has an equivalent method, `account_new`. It can be accessed on the terminal using an http request or using a Clef command:
|
||||
`personal_newAccount` was used to create a new account and save it in the keystore. Clef has an equivalent method, `account_new`. It can be accessed on the terminal using an http request or using a Clef command:
|
||||
|
||||
Example call (curl):
|
||||
|
||||
|
@ -80,7 +80,7 @@ Both require manual approval in Clef unless a custom ruleset is in place.
|
|||
|
||||
### personal_openWallet
|
||||
|
||||
`personal_OpenWallet` initiates a hardware wallet opening procedure by establishing a USB connection and then attempting to authenticate via the provided passphrase. Note, the method may return an extra challenge requiring a second open (e.g. the Trezor PIN matrix challenge). `personal_openWallet` is identical to `clef_openWallet`. The Clef method is not externally eposed, meaning it must be called via a UI.
|
||||
`personal_OpenWallet` initiates a hardware wallet opening procedure by establishing a USB connection and then attempting to authenticate via the provided passphrase. Note, the method may return an extra challenge requiring a second open (e.g. the Trezor PIN matrix challenge). `personal_openWallet` is identical to `clef_openWallet`. The Clef method is not externally exposed, meaning it must be called via a UI.
|
||||
|
||||
### personal_sendTransaction
|
||||
|
||||
|
@ -206,7 +206,7 @@ curl --data '{"id": 2, "jsonrpc": "2.0", "method": "account_signTransaction", "p
|
|||
|
||||
## Methods without replacements
|
||||
|
||||
Thjere 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` namepsace that have been deprecated without replacements. These are:
|
||||
|
||||
### personal_unlockAccount
|
||||
|
||||
|
@ -392,7 +392,7 @@ Deletes a pairing between wallet and Geth.
|
|||
|
||||
Validate the given passphrase and submit transaction.
|
||||
|
||||
The transaction is the same argument as for `eth_sendTransaction` (i.e. [transaction object](/docs/interacting-with-geth/rpc/objects#transaction-call-object)) and contains the `from` address. If the passphrase can be used to decrypt the private key belogging to `tx.from` the transaction is verified, signed and send onto the network. The account is not unlocked globally in the node and cannot be used in other RPC calls.
|
||||
The transaction is the same argument as for `eth_sendTransaction` (i.e. [transaction object](/docs/interacting-with-geth/rpc/objects#transaction-call-object)) and contains the `from` address. If the passphrase can be used to decrypt the private key belonging to `tx.from` the transaction is verified, signed and send onto the network. The account is not unlocked globally in the node and cannot be used in other RPC calls.
|
||||
|
||||
| Client | Method invocation |
|
||||
| :------ | ---------------------------------------------------------------- |
|
||||
|
|
|
@ -11,7 +11,7 @@ The `content` inspection property can be queried to list the exact details of al
|
|||
|
||||
The result is an object with two fields `pending` and `queued`. Each of these fields are associative arrays, in which each entry maps an origin-address to a batch of scheduled transactions. These batches themselves are maps associating nonces with actual transactions.
|
||||
|
||||
Please note, there may be multiple transactions associated with the same account and nonce. This can happen if the user broadcast mutliple ones with varying gas allowances (or even completely different transactions).
|
||||
Please note, there may be multiple transactions associated with the same account and nonce. This can happen if the user broadcast multiple ones with varying gas allowances (or even completely different transactions).
|
||||
|
||||
| Client | Method invocation |
|
||||
| :-----: | --------------------------------------------------------------------- |
|
||||
|
@ -119,7 +119,7 @@ The `inspect` inspection property can be queried to list a textual summary of al
|
|||
|
||||
The result is an object with two fields `pending` and `queued`. Each of these fields are associative arrays, in which each entry maps an origin-address to a batch of scheduled transactions. These batches themselves are maps associating nonces with transactions summary strings.
|
||||
|
||||
Please note, there may be multiple transactions associated with the same account and nonce. This can happen if the user broadcast mutliple ones with varying gas allowances (or even completely different transactions).
|
||||
Please note, there may be multiple transactions associated with the same account and nonce. This can happen if the user broadcast multiple ones with varying gas allowances (or even completely different transactions).
|
||||
|
||||
| Client | Method invocation |
|
||||
| :-----: | ------------------------------------------------------------ |
|
||||
|
|
|
@ -10,7 +10,7 @@ There are several ways to monitor the performance of a Geth node. Insights into
|
|||
To follow along with the instructions on this page it will be useful to have:
|
||||
|
||||
- a running Geth instance.
|
||||
- basic working knowlegde of bash/terminal.
|
||||
- basic working knowledge of bash/terminal.
|
||||
|
||||
[This video](https://www.youtube.com/watch?v=cOBab8IJMYI) provides an excellent introduction to Geth monitoring.
|
||||
|
||||
|
@ -80,7 +80,7 @@ docker run \
|
|||
prom/prometheus:latest
|
||||
```
|
||||
|
||||
Here a example directoy of `/path/to/promethus`:
|
||||
Here a example directory of `/path/to/prometheus`:
|
||||
|
||||
```sh
|
||||
prometheus/
|
||||
|
|
|
@ -9,7 +9,7 @@ The goal of the Geth metrics system is that - similar to logs - arbitrary metric
|
|||
|
||||
## Metric types {#metric-types}
|
||||
|
||||
Geth's metrics can be classified into four types: meters, timers, counters and guages.
|
||||
Geth's metrics can be classified into four types: meters, timers, counters and gauges.
|
||||
|
||||
### Meters {#meters}
|
||||
|
||||
|
@ -34,7 +34,7 @@ Timers are extensions of _meters_, the _duration_ of an event is collected along
|
|||
|
||||
A counter is a single int64 value that can be incremented and decremented. The current value of the counter can be queried.
|
||||
|
||||
### Gauges {#guages}
|
||||
### Gauges {#gauges}
|
||||
|
||||
A gauge is a single int64 value. Its value can increment and decrement - as with a counter - but can also be set arbitrarily.
|
||||
|
||||
|
|
|
@ -205,8 +205,8 @@ Measures the rate that data is written to, or read from, the LevelDB and ancient
|
|||
- **leveldb write**: Rate that data is written to the fast-access LevelDB database that stores recent data.
|
||||
- **ancient read**: Rate that data is read from the freezer (the database storing older data).
|
||||
- **ancient write**: Rate that data is written to the freezer (the database storing older data)
|
||||
- **compaction read**: Rate that data is read from the LevelDB database while it is being compacted (i.e. free space is reclaimed by deleting uneccessary data)
|
||||
- **compaction write**: Rate that data is written to the LevelDB database while it is being compacted (i.e. free space is reclaimed by deleting uneccessary data)
|
||||
- **compaction read**: Rate that data is read from the LevelDB database while it is being compacted (i.e. free space is reclaimed by deleting unnecessary data)
|
||||
- **compaction write**: Rate that data is written to the LevelDB database while it is being compacted (i.e. free space is reclaimed by deleting unnecessary data)
|
||||
|
||||
#### Session totals
|
||||
|
||||
|
@ -226,7 +226,7 @@ The current default Geth Grafana dashboard includes panels for light nodes. Ligh
|
|||
|
||||
## Creating new dashboards
|
||||
|
||||
If the default dashboard isn't right for you, you can update it in the browser. Remove panels by clicking on their titles and selectign `remove`. Add a new panel by clicking the "plus" icon in the upper right of the browser window. There, you will have to define an InfluxDB query for the metric you want to display. The endpoints for the various metrics that Geth reports are listed by Geth at the address/port combination passed to `--metrics.addr` and `metrics.port` on startup - by default `127.0.0.1:6060/debug/metrics`. It is also possible to configure a panel by providing a JSON configuration model. Individial components are defined using the following syntax (the example below is for the CPU panel):
|
||||
If the default dashboard isn't right for you, you can update it in the browser. Remove panels by clicking on their titles and selecting `remove`. Add a new panel by clicking the "plus" icon in the upper right of the browser window. There, you will have to define an InfluxDB query for the metric you want to display. The endpoints for the various metrics that Geth reports are listed by Geth at the address/port combination passed to `--metrics.addr` and `metrics.port` on startup - by default `127.0.0.1:6060/debug/metrics`. It is also possible to configure a panel by providing a JSON configuration model. Individual components are defined using the following syntax (the example below is for the CPU panel):
|
||||
|
||||
```json
|
||||
{
|
||||
|
|
|
@ -17,11 +17,11 @@ Here are more resources for a deeper understanding of Geth and related topics.
|
|||
|
||||
[Sina's EVM tracing workshop at Devcon 6, Bogota](https://youtu.be/b8RdmGsilfU)
|
||||
|
||||
[Péter at ETH Prage 2022: Ethereum in numbers: where TPS meets physics](https://www.youtube.com/watch?v=TdsaVoJiy3g)
|
||||
[Péter at ETH Prague 2022: Ethereum in numbers: where TPS meets physics](https://www.youtube.com/watch?v=TdsaVoJiy3g)
|
||||
|
||||
[Marius at ETH Amsterdam 2022: Deep dive into Geth](https://www.youtube.com/watch?v=c4N79UXZqSc)
|
||||
|
||||
[Péter interview at ETH Prage 2022:](https://www.youtube.com/watch?v=cfxGzZZ_uOI)
|
||||
[Péter interview at ETH Prague 2022:](https://www.youtube.com/watch?v=cfxGzZZ_uOI)
|
||||
|
||||
[Guillame at Devconnect 2022: Stateless Ethereum](https://www.youtube.com/watch?v=XkzJncPYj0M&list=PLJijNYoOwnsuqDH9ITSvbqDOaUdA1vp2O&index=9)
|
||||
|
||||
|
@ -33,7 +33,7 @@ Here are more resources for a deeper understanding of Geth and related topics.
|
|||
|
||||
[Marius interview at ETH Prague 2022](https://www.youtube.com/watch?v=QKr3KHTjbjQ)
|
||||
|
||||
[Marius at ETHOnline 2021: The Megre from the perspective of the execution layer](https://www.youtube.com/watch?v=3DDjfUvQ2TE)
|
||||
[Marius at ETHOnline 2021: The Merge from the perspective of the execution layer](https://www.youtube.com/watch?v=3DDjfUvQ2TE)
|
||||
|
||||
[Péter's 2020 online Geth AMA](https://www.youtube.com/watch?v=gVMDw66atr4)
|
||||
|
||||
|
|
|
@ -283,7 +283,7 @@ To create an extremely trustless ruleset, the `raw_data` could be verified to en
|
|||
]
|
||||
```
|
||||
|
||||
However, `messages` could also be used. They do not come from the external caller, but are generated inernally: `clef` parsed the incoming request and verified the Clique wellformedness of the content. The following simply checks for such a message:
|
||||
However, `messages` could also be used. They do not come from the external caller, but are generated internally: `clef` parsed the incoming request and verified the Clique wellformedness of the content. The following simply checks for such a message:
|
||||
|
||||
```js
|
||||
function OnSignerStartup(info) {}
|
||||
|
|
|
@ -110,7 +110,7 @@ Since the user has complete freedom to write custom rules, it is plausible that
|
|||
|
||||
Javascript is very flexible but also easy to write incorrectly. For example, users might assume that javascript can handle large integers natively rather than explicitly using `bigInt`. This is an error commonly encountered in the Ethereum context when users attempt to multiply `gas` by `gasCost`.
|
||||
|
||||
It’s unclear whether any other language would be more secure - there is alwas the possibility of implementing an insecure rule.
|
||||
It’s unclear whether any other language would be more secure - there is always the possibility of implementing an insecure rule.
|
||||
|
||||
### Credential security {#credential-security}
|
||||
|
||||
|
@ -238,4 +238,4 @@ function OnApprovedTx(resp) {
|
|||
|
||||
## Summary {#summary}
|
||||
|
||||
Rules are sets of conditions encoded in Javascript files that enable certain actions to be auto-approved by Clef. This page outlined the implementation details and security considerations that will help to build suitrable ruleset files. See the [Clef GitHub](https://github.com/ethereum/go-ethereum/tree/master/cmd/clef) for further reading.
|
||||
Rules are sets of conditions encoded in Javascript files that enable certain actions to be auto-approved by Clef. This page outlined the implementation details and security considerations that will help to build suitable ruleset files. See the [Clef GitHub](https://github.com/ethereum/go-ethereum/tree/master/cmd/clef) for further reading.
|
||||
|
|
Loading…
Reference in New Issue