chore: solve merge conflicts
This commit is contained in:
Nicolás Quiroz
parent
3006ec831f
commit
d7c713437b
|
|
@ -39,7 +39,7 @@ export const HomeHero: FC = () => {
|
|||
</Flex>
|
||||
|
||||
<Flex direction='column' alignItems='center'>
|
||||
<NextLink href={`${DOCS_PAGE}/getting-started`} passHref>
|
||||
<NextLink href={DOCS_PAGE} passHref>
|
||||
<Button variant='primary' as='a' mb={1}>
|
||||
<Text textStyle='homepage-primary-label'>Documentation</Text>
|
||||
</Button>
|
||||
|
|
|
|||
|
|
@ -7,7 +7,6 @@ A Geth node continually reports messages to the console allowing users to monito
|
|||
|
||||
Note that there are a large number of log messages covering a wide range of possible scenarios for a Geth node. This page will only address a subset of commonly seen messages. For more, see the [Geth Github](https://github.com/ethereum/go-ethereum), [Discord](https://discord.gg/WHNkYDsAKU) or search on [ethereum.stackexchange](https://ethereum.stackexchange.com/). Log messages are usually sufficiently self-descrining that they do not require additional explanation.
|
||||
|
||||
|
||||
## Configuring log messages
|
||||
|
||||
Log messages are displayed to the console by default. The messages can be tuned to be more or less detailed by passing `--verbosity` and a value between 0 and 6 to Geth at startup:
|
||||
|
|
@ -20,6 +19,7 @@ Log messages are displayed to the console by default. The messages can be tuned
|
|||
4 = debug (all info plus additional messages for debugging)
|
||||
5 = detail (all info plus detailed debugging messages)
|
||||
```
|
||||
|
||||
The default is `--verbosity 3`.
|
||||
|
||||
Log messages can also be redirected so they are saved to a text file instead of being displayed in the console. In Linux the syntax `>> <path> 2>&1` redirects both `stdout` and `stderr` messages to `<path>`. For example:
|
||||
|
|
@ -36,6 +36,7 @@ When Geth starts up it immediately reports a fairly long page of configuration d
|
|||
```
|
||||
MESSAGE_TYPE [MONTH-DAY][TIME] MESSAGE VALUE
|
||||
```
|
||||
|
||||
Where `MESSAGE_TYPE` can be `INFO`, `WARN`, `ERROR` or `DEBUG`. These tags categorize log messages according to their purpose. `INFO` messages inform the user about Geth's current configuration and status. `WARN` messages are for alerting the user to details that affect the way Geth is running. `ERROR` messages are for alerting the user to problems. `DEBUG` is for messages that are relevant to troubleshooting or for developers working on Geth.
|
||||
|
||||
The messages displayed on startup break down as follows:
|
||||
|
|
@ -58,7 +59,6 @@ INFO [10-04|10:20:52.372] Persisted trie from memory database nodes=12356 s
|
|||
|
||||
The logs above show the user that the node is connecting to Ethereum Mainnet and some low level configuration details. The cache size is bumped to the Mainnet default (4096). The maximum peer count is the highest number of peers this node is allowed to connect to and can be used to control the bandwidth requirements of the node. Logs relating to `ethash` are out of date since Ethereum moved to proof-of-stake based consensus and can safely be ignored.
|
||||
|
||||
|
||||
```
|
||||
---------------------------------------------------------------------------------------------------------------------------------------------------------
|
||||
INFO [10-04|10:20:52.386] Chain ID: 1 (mainnet)
|
||||
|
|
@ -114,10 +114,9 @@ INFO [10-04|10:21:03.100] Looking for peers peercount=0 t
|
|||
|
||||
The logs above relate to Geth starting up its peer-to-peer components and seeking other nodes to connect to. The long address reported to `Started P2P networking` is the nodes own enode address. The `IPC Endpoint` is the location of the node's IPC file that can be used to connect a Javascript console. There is a log message confirming that a JWT secret was generated and reporting its path. This is required to authenticate communication between Geth and the consensus client. There are also messages here reporting on the HTTP server that can be used to send requests to Geth. There should be two HTTP servers - one for interacting with Geth (defaults to `localhost:8545`) and one for communication with the consensus client (defaults to `localhost:8551`).
|
||||
|
||||
|
||||
### Syncing
|
||||
|
||||
The default for Geth is to sync in snap mode. This requires a block header to be provided to Geth by the consensus client. The header is then used as a target to sync to. Geth requests block headers from its peers that are parents of the target until there is a continuous chain of sequential headers of sufficient length. Then, Geth requests block bodies and receipts for each header and simultaneously starts downloading state data. This state data is stored in the form of a [Patricia Merkle Trie](https://ethereum.org/en/developers/docs/data-structures-and-encoding/patricia-merkle-trie/). Only the leaves of the trie are downloaded, the full trie structure is then locally regenerated from the leaves up. Meanwhile, the blockchain continues to progress and the target header is updated. This means some of the regenerated state data needs to be updated. This is known as *healing*.
|
||||
The default for Geth is to sync in snap mode. This requires a block header to be provided to Geth by the consensus client. The header is then used as a target to sync to. Geth requests block headers from its peers that are parents of the target until there is a continuous chain of sequential headers of sufficient length. Then, Geth requests block bodies and receipts for each header and simultaneously starts downloading state data. This state data is stored in the form of a [Patricia Merkle Trie](https://ethereum.org/en/developers/docs/data-structures-and-encoding/patricia-merkle-trie/). Only the leaves of the trie are downloaded, the full trie structure is then locally regenerated from the leaves up. Meanwhile, the blockchain continues to progress and the target header is updated. This means some of the regenerated state data needs to be updated. This is known as _healing_.
|
||||
|
||||
Assuming Geth has a synced consensus client and some peers it will start importing headers, block bodies and receipts. The log messages for data downloading look as follows:
|
||||
|
||||
|
|
@ -152,7 +151,6 @@ INFO [10-03|15:34:01.336] Forkchoice requested sync to new head number=15,670
|
|||
|
||||
The message above indicates that the fork choice algorithm, which is run by the consensus client, has identified a new target Geth should sync up to. This redirects the sync to prevent syncing to an outdated target and is a natural part of syncing a live blockchain.
|
||||
|
||||
|
||||
## Transaction logs
|
||||
|
||||
Transactions submitted over local IPC, Websockets or HTTP connections are reported in the console logs. For example, a simple ETH transaction appears in the console logs as follows:
|
||||
|
|
|
|||
|
|
@ -19,7 +19,6 @@ Ethereum mining used an algorithm called ["Ethash"](https://ethereum.org/en/deve
|
|||
|
||||
Regardless of the mining method, the blockchain must be fully synced before mining is started, otherwise the miner will build on an outdated side chain,meaning block rewards will not be recognized by the main network.
|
||||
|
||||
|
||||
## GPU Mining
|
||||
|
||||
### Installing Ethminer
|
||||
|
|
@ -28,7 +27,6 @@ The Ethminer software can be installed from a downloaded binary or built from so
|
|||
|
||||
### Using Ethminer with Geth
|
||||
|
||||
|
||||
An account to receive block rewards must first be defined. The address of the account is all that is required to start mining - the mining rewards will be credited to that address. This can be an existing address or one that is newly created by Geth. More detailed instructions on creating and importing accounts are available on the [Account Management](/docs/interface/managing-your-accounts) page.
|
||||
|
||||
The account address can be provided to `--mining.etherbase` when Geth is started. This instructs Geth to direct any block rewards to this address. Once started, Geth will sync the blockchain. If Geth has not connected to this network before, or if the data directory has been deleted, this can take several days. Also, enable HTTP traffic with the `--http` command.
|
||||
|
|
@ -97,7 +95,6 @@ Note that the Geth command `miner.hashrate` only works for CPU mining - it alway
|
|||
|
||||
More verbose logs can be configured using `-v` and a value between 0-9. The Ethash algorithm is [memory-hard](https://crypto.stackexchange.com/questions/84002/memory-hard-vs-memory-bound-functions) and requires a large dataset to be loaded into memory. Each GPU requires 4-5 GB of RAM. The error message `Error GPU mining. GPU memory fragmentation?` indicates that there is insufficient memory available.
|
||||
|
||||
|
||||
## CPU Mining with Geth
|
||||
|
||||
When Geth is started it is not mining by default. Unless it is specifically instructed to mine, it acts only as a node, not a miner. Geth starts as a (CPU) miner if the `--mine` flag is provided. The `--miner.threads` parameter can be used to set the number parallel mining threads (defaulting to the total number of processor cores).
|
||||
|
|
@ -109,10 +106,10 @@ geth --mine --miner.threads=4
|
|||
CPU mining can also be started and stopped at runtime using the [console](/docs/interface/javascript-console). The command `miner.start` takes an optional parameter for the number of miner threads.
|
||||
|
||||
```js
|
||||
miner.start(8)
|
||||
true
|
||||
miner.stop()
|
||||
true
|
||||
miner.start(8);
|
||||
true;
|
||||
miner.stop();
|
||||
true;
|
||||
```
|
||||
|
||||
Note that mining only makes sense if you are in sync with the network (since you mine on top of the consensus block). Therefore the blockchain downloader/synchroniser will delay mining until syncing is complete, and after that mining automatically starts unless you cancel with `miner.stop()`.
|
||||
|
|
@ -157,22 +154,20 @@ It is also possible to check which blocks were mined by a particular miner (addr
|
|||
function minedBlocks(lastn, addr) {
|
||||
addrs = [];
|
||||
if (!addr) {
|
||||
addr = eth.coinbase
|
||||
addr = eth.coinbase;
|
||||
}
|
||||
limit = eth.blockNumber - lastn
|
||||
limit = eth.blockNumber - lastn;
|
||||
for (i = eth.blockNumber; i >= limit; i--) {
|
||||
if (eth.getBlock(i).miner == addr) {
|
||||
addrs.push(i)
|
||||
addrs.push(i);
|
||||
}
|
||||
}
|
||||
return addrs
|
||||
return addrs;
|
||||
}
|
||||
|
||||
// scans the last 1000 blocks and returns the blocknumbers of blocks mined by your coinbase
|
||||
// (more precisely blocks the mining reward for which is sent to your coinbase).
|
||||
minedBlocks(1000, eth.coinbase)
|
||||
[352708, 352655, 352559]
|
||||
|
||||
minedBlocks(1000, eth.coinbase)[(352708, 352655, 352559)];
|
||||
```
|
||||
|
||||
The etherbase balance will fluctuate if a mined block is re-org'd out of the canonical chain. This means that when the local Geth node includes the mined block
|
||||
|
|
|
|||
|
|
@ -44,12 +44,10 @@ There are occasions when Geth simply fails to connect to peers. The common reaso
|
|||
|
||||
- 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.
|
||||
|
||||
|
||||
## Checking Connectivity
|
||||
|
||||
The `net` module has two attributes that enable checking node connectivity from the [interactive Javascript console](/docs/interface/javascript-console). These are `net.listening` which reports whether the Geth node is listening for inbound requests, and `peerCount` which returns the number of active peers the node is connected to.
|
||||
|
||||
|
||||
```javascript
|
||||
> net.listening
|
||||
true
|
||||
|
|
@ -110,7 +108,6 @@ The `admin` module also includes functions for gathering information about the l
|
|||
|
||||
It is often useful for developers to connect to private test networks rather than public testnets or Etheruem mainnet. These sandbox environments allow block creation without competing against other miners, easy minting of test ether and give freedom to break things without real-world consequences. A private network is started by providing a value to `--networkid` that is not used by any other existing public network ([Chainlist](https://chainlist.org)) and creating a custom `genesis.json` file. Detailed instructions for this are available on the [Private Networks page](/docs/interface/private-network).
|
||||
|
||||
|
||||
## Static nodes
|
||||
|
||||
Geth also supports static nodes. Static nodes are specific peers that are always connected to. Geth reconnects to these peers automatically when it is restarted. Specific nodes are defined to be static nodes by adding their enode addresses to a config file. The easiest way to create this config file is to run:
|
||||
|
|
@ -130,7 +127,9 @@ Ensure the other lines in `config.toml` are also set correctly before starting G
|
|||
Static nodes can also be added at runtime in the Javascript console by passing an enode address to `admin.addPeer()`:
|
||||
|
||||
```javascript
|
||||
admin.addPeer("enode://f4642fa65af50cfdea8fa7414a5def7bb7991478b768e296f5e4a54e8b995de102e0ceae2e826f293c481b5325f89be6d207b003382e18a8ecba66fbaf6416c0@33.4.2.1:30303")
|
||||
admin.addPeer(
|
||||
'enode://f4642fa65af50cfdea8fa7414a5def7bb7991478b768e296f5e4a54e8b995de102e0ceae2e826f293c481b5325f89be6d207b003382e18a8ecba66fbaf6416c0@33.4.2.1:30303'
|
||||
);
|
||||
```
|
||||
|
||||
## Peer limit
|
||||
|
|
@ -148,7 +147,9 @@ Trusted nodes can be added to `config.toml` in the same way as for static nodes.
|
|||
Nodes can be added using the `admin.addTrustedPeer()` call in the Javascript console and removed using `admin.removeTrustedPeer()` call.
|
||||
|
||||
```javascript
|
||||
admin.addTrustedPeer("enode://f4642fa65af50cfdea8fa7414a5def7bb7991478b768e296f5e4a54e8b995de102e0ceae2e826f293c481b5325f89be6d207b003382e18a8ecba66fbaf6416c0@33.4.2.1:30303")
|
||||
admin.addTrustedPeer(
|
||||
'enode://f4642fa65af50cfdea8fa7414a5def7bb7991478b768e296f5e4a54e8b995de102e0ceae2e826f293c481b5325f89be6d207b003382e18a8ecba66fbaf6416c0@33.4.2.1:30303'
|
||||
);
|
||||
```
|
||||
|
||||
## Summary
|
||||
|
|
|
|||
|
|
@ -17,6 +17,7 @@ Snap sync starts by downloading the headers for a chunk of blocks. Once the head
|
|||
The healing has to outpace the growth of the blockchain, otherwise the node will never catch up to the current state. There are some hardware factors that determine the speed of the state healing (speed of disk read/write and internet connection) and also the total gas used in each block (more gas means more changes to the state that have to be handled).
|
||||
|
||||
To summarize, snap sync progresses in the following sequence:
|
||||
|
||||
- download and verify headers
|
||||
- download block bodies and receipts. In parallel, download raw state data and build state trie
|
||||
- heal state trie to account for newly arriving data
|
||||
|
|
|
|||
Loading…
Reference in New Issue