diff --git a/docs/Concepts/AlethioOverview.md b/docs/Concepts/AlethioOverview.md index ff64bae27e2..3b6ca5e2813 100644 --- a/docs/Concepts/AlethioOverview.md +++ b/docs/Concepts/AlethioOverview.md @@ -1,17 +1,16 @@ -description: Alethio Lite Block Explorer And EthStats Lite Network Monitor Overview +description: Alethio Lite Block Explorer And EthStats Lite Network Monitor overview # Alethio -Alethio offers a set of tools including the [Block Explorer](https://aleth.io/) and -[EthStats Network Monitor](https://ethstats.io/). The Alethio tools are developed by [Alethio](https://company.aleth.io/). +[Alethio](https://company.aleth.io/) develops a set of tools, including +[Block Explorer](https://aleth.io/) and [EthStats Network Monitor](https://ethstats.io/), which +give a comprehensive view into the activity in a public or private Enterprise Ethereum network. +The statistics are at the network level and the block, transaction, and account level. -The Block Explorer and EthStats provide a comprehensive view into the activity in a -public or private Enterprise Ethereum network. The statistics are at the network level -and the block, transaction, and account level. +To use Block Explorer and EthStats for testing and private networks, run the the +[Lite Block Explorer](../HowTo/Deploy/Lite-Block-Explorer.md) and +[EthStats Lite](../HowTo/Deploy/Lite-Network-Monitor.md). -To use the Block Explorer and EthStats for testing and private networks, run the the [Lite Block -Explorer](../HowTo/Deploy/Lite-Block-Explorer.md) and [EthStats Lite](../HowTo/Deploy/Lite-Network-Monitor.md). - -Contact [Alethio](https://company.aleth.io/) at [contact@aleth.io](mailto:contact@aleth.io) for -details about the full versions and enterprise solutions. +For more information about the full versions of these products and other enterprise solutions, +contact [Alethio](https://company.aleth.io/) at [contact@aleth.io](mailto:contact@aleth.io). diff --git a/docs/Concepts/ArchitectureOverview.md b/docs/Concepts/ArchitectureOverview.md index ab28c39ac1b..a70d5c62435 100644 --- a/docs/Concepts/ArchitectureOverview.md +++ b/docs/Concepts/ArchitectureOverview.md @@ -1,11 +1,11 @@ -description: Hyperledger Besu Architecture +description: Hyperledger Besu architecture -# Hyperledger Besu Architecture +# Hyperledger Besu architecture -The high-level architecture of Hyperledger Besu is: +The following diagram outlines the Hyperledger Besu high-level architecture. ![Architecture](../images/Architecture.png) -If you've got questions about the architecture of Hyperledger Besu, -contact us on [Hyperledger Besu chat](https://chat.hyperledger.org/channel/besu). \ No newline at end of file +For more information about the Hyperledger Besu architecture, contact us on +[Hyperledger Besu chat](https://chat.hyperledger.org/channel/besu). \ No newline at end of file diff --git a/docs/Concepts/Client-Libraries.md b/docs/Concepts/Client-Libraries.md index cafeca626b5..e3ff64e43f6 100644 --- a/docs/Concepts/Client-Libraries.md +++ b/docs/Concepts/Client-Libraries.md @@ -1,16 +1,23 @@ -description: Hyperledger Besu client libraries +description: Hyperledger Besu client libraries -# Client Libraries +# Client libraries -Client libraries such as [web3.js](https://github.com/ethereum/web3.js/), [web3j](https://github.com/web3j/web3j), or [ethereumj](https://github.com/ethereum/ethereumj) are used by Dapps to forward JSON-RPC requests to Hyperledger Besu. Any -client library that implements core Ethereum RPC methods can be used with Besu. +Dapps use client libraries, such as [web3.js](https://github.com/ethereum/web3.js/), +[web3j](https://github.com/web3j/web3j), or [ethereumj](https://github.com/ethereum/ethereumj), to +forward JSON-RPC requests to Hyperledger Besu. Any client library implementing core Ethereum RPC +methods works with Besu. -Use the [web3.js-eea library](../HowTo/Interact/Client-Libraries/eeajs.md) with Besu for [privacy features](../Concepts/Privacy/Privacy-Overview.md). +Use the [web3.js-eea library](../HowTo/Interact/Client-Libraries/eeajs.md) with Besu for +[privacy features](../Concepts/Privacy/Privacy-Overview.md). ![Client Libraries](../images/Hyperledger-Besu-Client-Libraries.png) Use client libraries to: -* [create signed transactions](../HowTo/Develop-Dapps/Use-web3js.md) -* [create and send private transactions](../HowTo/Send-Transactions/Creating-Sending-Private-Transactions.md). +* [Create signed transactions](../HowTo/Develop-Dapps/Use-web3js.md) +* [Create and send private transactions]. + + +[Create and send private transactions]: ../HowTo/Send-Transactions/Creating-Sending-Private-Transactions.md + diff --git a/docs/Concepts/Events-and-Logs.md b/docs/Concepts/Events-and-Logs.md index 411950e58db..56c6425a28e 100644 --- a/docs/Concepts/Events-and-Logs.md +++ b/docs/Concepts/Events-and-Logs.md @@ -1,25 +1,28 @@ -# Events and Logs +# Events and logs -When a transaction is mined, smart contracts emit events and write logs to the blockchain. +Transaction mining causes smart contracts to emit events and write logs to the blockchain. -Logs are associated with the contract address and included in the blockchain but logs are not accessible -from within contracts. Log storage is cheaper than contract storage (that is, it costs less gas) so if the required data can -be stored in and accessed from logs, the cost is reduced. For example, you can use logs to display all -transfers made using a specific contract but not the current state of the contract. +The smart contract address is the link to the logs and the blockchain includes the logs, but +contracts cannot access logs. Log storage is cheaper than contract storage (that is, it costs less +gas) so storing and accessing the required data in logs reduces the cost. For example, use logs to +display all transfers made using a specific contract, but not the current state of the contract. -A Dapp front end can either request logs using the [JSON-RPC API filter methods](../HowTo/Interact/Filters/Accessing-Logs-Using-JSON-RPC.md) -or subscribe to logs using the [RPC Pub/Sub API](../HowTo/Interact/APIs/RPC-PubSub.md#logs). +A Dapp front end can either access logs using the +[JSON-RPC API filter methods](../HowTo/Interact/Filters/Accessing-Logs-Using-JSON-RPC.md) or +subscribe to logs using the [RPC Pub/Sub API](../HowTo/Interact/APIs/RPC-PubSub.md#logs). Use [`admin_generateLogBloomCache`](../Reference/API-Methods.md#admin_generatelogbloomcache) to improve log retrieval performance. ## Topics -Log entries contain up to four topics. The first topic is the [event signature hash](#event-signature-hash) and up to three topics -are the indexed [event parameters](#event-parameters). +Log entries contain up to four topics. The first topic is the +[event signature hash](#event-signature-hash) and up to three topics are the indexed +[event parameters](#event-parameters). !!! example - Log entry for an event with one indexed parameter: + + A log entry for an event with one indexed parameter: ```json { @@ -38,38 +41,41 @@ are the indexed [event parameters](#event-parameters). } ``` -## Event Parameters +## Event parameters -Up to three event parameters can have the `indexed` attribute. Indexed parameters are stored as `topics` -in the logs. Indexed parameters can be searched and filtered. +Up to three event parameters can have the `indexed` attribute. Logs store these indexed parameters +as `topics`. Indexed parameters are searchable and filterable. Topics are 32 bytes. If an indexed argument is an array (including `string` and `byte` datatypes), -the keccak-256 hash of the paramater is stored as a topic. +the log stores the the keccak-256 hash of the paramater as a topic. -Non-indexed parameters are included in the logs `data` but cannot be easily searched or filtered. +Log `data` includes non-indexed parameters but is difficult to search or filter. !!! example - A Solidity contract that stores one indexed and one non-indexed parameter and has an event that emits the value of each parameter: + A Solidity contract storing one indexed and one non-indexed parameter and has an event emitting + the value of each parameter: ```solidity pragma solidity ^0.5.1; contract Storage { - uint256 public valueIndexed; - uint256 public valueNotIndexed; + uint256 public valueIndexed; + uint256 public valueNotIndexed; - event Event1(uint256 indexed valueIndexed, uint256 valueNotIndexed); + event Event1(uint256 indexed valueIndexed, uint256 valueNotIndexed); - function setValue(uint256 _valueIndexed, uint256 _valueNotIndexed) public { - valueIndexed = _valueIndexed; - valueNotIndexed = _valueNotIndexed; - emit Event1(_valueIndexed, _valueNotIndexed); - } + function setValue(uint256 _valueIndexed, uint256 _valueNotIndexed) public { + valueIndexed = _valueIndexed; + valueNotIndexed = _valueNotIndexed; + emit Event1(_valueIndexed, _valueNotIndexed); + } } ``` -!!! example - Log entry created by invoking the contract above with `valueIndexed` set to 5 and `valueNotIndexed` set to 7: +!!! example + + A log entry created by invoking the contract in the previous example with `valueIndexed` set to + 5 and `valueNotIndexed` set to 7: ```json { @@ -88,100 +94,106 @@ Non-indexed parameters are included in the logs `data` but cannot be easily sear } ``` -## Event Signature Hash +## Event signature hash -The first topic in a log entry is always the the event signature hash. The event signature hash is a keccak-256 -hash of the event name and input argument types. Argument names are ignored. For example, the event `Hello(uint256 worldId)` -has the signature hash `keccak('Hello(uint256)')`. The signature identifies to which event log topics belong. +The first topic in a log entry is always the the event signature hash. The event signature hash is +a keccak-256 hash of the event name and input argument types, with argument names ignored. For +example, the event `Hello(uint256 worldId)` has the signature hash `keccak('Hello(uint256)')`. The +signature identifies to which event log topics belong. !!! example A Solidity contract with two different events: ``` solidity - pragma solidity ^0.5.1; + pragma solidity ^0.5.1; contract Storage { - uint256 public valueA; + uint256 public valueA; uint256 public valueB; - event Event1(uint256 indexed valueA); - event Event2(uint256 indexed valueB); + event Event1(uint256 indexed valueA); + event Event2(uint256 indexed valueB); - function setValue(uint256 _valueA) public { - valueA = _valueA; - emit Event1(_valueA); - } + function setValue(uint256 _valueA) public { + valueA = _valueA; + emit Event1(_valueA); + } - function setValueAgain(uint256 _valueB) public { - valueB = _valueB; - emit Event2(_valueB); - } + function setValueAgain(uint256 _valueB) public { + valueB = _valueB; + emit Event2(_valueB); + } } ``` -The event signature hash for event 1 is `keccak('Event1(uint256)')` and the event signature hash for event -2 is `keccak('Event2(uint256)')`. The hashes are: +The event signature hash for event 1 is `keccak('Event1(uint256)')` and the event signature hash +for event 2 is `keccak('Event2(uint256)')`. The hashes are: -* `04474795f5b996ff80cb47c148d4c5ccdbe09ef27551820caa9c2f8ed149cce3` for event 1 -* `06df6fb2d6d0b17a870decb858cc46bf7b69142ab7b9318f7603ed3fd4ad240e` for event 2 +* `04474795f5b996ff80cb47c148d4c5ccdbe09ef27551820caa9c2f8ed149cce3` for event 1 +* `06df6fb2d6d0b17a870decb858cc46bf7b69142ab7b9318f7603ed3fd4ad240e` for event 2. !!! tip - You can use a library keccak (sha3) hash function such as provided in [Web3.js](https://github.com/ethereum/wiki/wiki/JavaScript-API#web3sha3) - or an an online tool such as https://emn178.github.io/online-tools/keccak_256.html to generate event signature hashes. + + You can use a library keccak (sha3) hash function, such as provided in + [Web3.js](https://github.com/ethereum/wiki/wiki/JavaScript-API#web3sha3), or an an online tool, + such as https://emn178.github.io/online-tools/keccak_256.html, to generate event signature + hashes. !!! example - Log entries from invoking the Solidity contract above: + + Log entries from invoking the Solidity contract in the previous example: ```json [ - { - "logIndex": "0x0", - "removed": false, - "blockNumber": "0x84", - "blockHash": "0x5fc573d76ec48ec80cbc43f299ebc306a8168112e3a4485c23e84e9a40f5d336", - "transactionHash": "0xcb52f02342c2498df82c49ac26b2e91e182155c8b2a2add5b6dc4c249511f85a", - "transactionIndex": "0x0", - "address": "0x42699a7612a82f1d9c36148af9c77354759b210b", - "data": "0x", - "topics": [ - "0x04474795f5b996ff80cb47c148d4c5ccdbe09ef27551820caa9c2f8ed149cce3", - "0x0000000000000000000000000000000000000000000000000000000000000001" - ] - }, - { - "logIndex": "0x0", - "removed": false, - "blockNumber": "0x87", - "blockHash": "0x6643a1e58ad857f727552e4572b837a85b3ca64c4799d085170c707e4dad5255", - "transactionHash": "0xa95295fcea7df3b9e47ab95d2dadeb868145719ed9cc0e6c757c8a174e1fcb11", - "transactionIndex": "0x0", - "address": "0x42699a7612a82f1d9c36148af9c77354759b210b", - "data": "0x", - "topics": [ - "0x06df6fb2d6d0b17a870decb858cc46bf7b69142ab7b9318f7603ed3fd4ad240e", - "0x0000000000000000000000000000000000000000000000000000000000000002" - ] - } + { + "logIndex": "0x0", + "removed": false, + "blockNumber": "0x84", + "blockHash": "0x5fc573d76ec48ec80cbc43f299ebc306a8168112e3a4485c23e84e9a40f5d336", + "transactionHash": "0xcb52f02342c2498df82c49ac26b2e91e182155c8b2a2add5b6dc4c249511f85a", + "transactionIndex": "0x0", + "address": "0x42699a7612a82f1d9c36148af9c77354759b210b", + "data": "0x", + "topics": [ + "0x04474795f5b996ff80cb47c148d4c5ccdbe09ef27551820caa9c2f8ed149cce3", + "0x0000000000000000000000000000000000000000000000000000000000000001" + ] + }, + { + "logIndex": "0x0", + "removed": false, + "blockNumber": "0x87", + "blockHash": "0x6643a1e58ad857f727552e4572b837a85b3ca64c4799d085170c707e4dad5255", + "transactionHash": "0xa95295fcea7df3b9e47ab95d2dadeb868145719ed9cc0e6c757c8a174e1fcb11", + "transactionIndex": "0x0", + "address": "0x42699a7612a82f1d9c36148af9c77354759b210b", + "data": "0x", + "topics": [ + "0x06df6fb2d6d0b17a870decb858cc46bf7b69142ab7b9318f7603ed3fd4ad240e", + "0x0000000000000000000000000000000000000000000000000000000000000002" + ] + } ] ``` -## Topic Filters +## Topic filters -[Filter options objects](../Reference/API-Objects.md#filter-options-object) have a `topics` key to filter logs by topics. +[Filter options objects](../Reference/API-Objects.md#filter-options-object) have a `topics` key to +filter logs by topics. -Topics are order-dependent. A transaction with a log containing topics `[A, B]` is matched with the following topic filters: +Topics are order-dependent. A transaction with a log containing topics `[A, B]` matches with the +following topic filters: * `[]` - Match any topic * `[A]` - Match A in first position * `[[null], [B]]` - Match any topic in first position AND B in second position * `[[A],[B]]` - Match A in first position AND B in second position -* `[[A, C], [B, D]]` - Match (A OR C) in first position AND (B OR D) in second position - - +* `[[A, C], [B, D]]` - Match (A OR C) in first position AND (B OR D) in second position. !!! example - The following filter option object returns log entries for the [Event Parameters example contract](#event-parameters) where `valueIndexed` is set to - 5 or 9: + + The following filter option object returns log entries for the + [Event Parameters example contract](#event-parameters) with `valueIndexed` set to 5 or 9: ```json { diff --git a/docs/Concepts/Mining.md b/docs/Concepts/Mining.md index 728576eb377..01df946d96f 100644 --- a/docs/Concepts/Mining.md +++ b/docs/Concepts/Mining.md @@ -1,9 +1,11 @@ description: Mining overview -Hyperledger Besu supports CPU and GPU mining which are [configured using command line options](../HowTo/Configure/Configure-Mining.md). +Hyperledger Besu supports CPU and GPU mining, which are +[configured using command line options](../HowTo/Configure/Configure-Mining.md). -Besu supports GPU mining and has been tested using [Ethminer](https://github.com/ethereum-mining/ethminer) with the `stratum+tcp` and `getwork` schemes. +GPU mining support testing used [Ethminer](https://github.com/ethereum-mining/ethminer) with +the `stratum+tcp` and `getwork` schemes. !!! note - The `getwork` scheme is supported as the `http` scheme in certain mining software. \ No newline at end of file + Some mining software supports the `getwork` scheme as the `http` scheme. \ No newline at end of file diff --git a/docs/Concepts/Monitoring.md b/docs/Concepts/Monitoring.md index 0117eb2f6a2..f81efe14677 100644 --- a/docs/Concepts/Monitoring.md +++ b/docs/Concepts/Monitoring.md @@ -1,12 +1,14 @@ -description: Monitoring using metrics and logging +description: Monitoring using metrics and logging -# Monitoring +# Monitoring -Monitoring enables identification of node and network issues. Specifically, configuring metrics and logging enables: +Monitoring enables identification of node and network issues. Specifically, configuring metrics and +logging enables: -* [Visual representation of declining node or network performance](../HowTo/Monitor/Metrics.md) -* [Collection of log files to enable issue diagnosis](../HowTo/Monitor/Logging.md). +* [Visual representation of declining node or network performance](../HowTo/Monitor/Metrics.md) +* [Collection of log files to enable issue diagnosis](../HowTo/Monitor/Logging.md). -[This recording](https://www.youtube.com/watch?v=7BuutRe0I28&feature=youtu.be) gives an overview of monitoring Hyperledger Besu. +For an overview of monitoring Hyperledger Besu, view +[this recording](https://www.youtube.com/watch?v=7BuutRe0I28&feature=youtu.be). diff --git a/docs/Concepts/Network-vs-Node.md b/docs/Concepts/Network-vs-Node.md index 166d6b5fb80..1af9405b6e0 100644 --- a/docs/Concepts/Network-vs-Node.md +++ b/docs/Concepts/Network-vs-Node.md @@ -1,13 +1,15 @@ -description: Configuring Besu at the network level compared to the node level +description: Configuring Besu at the network level compared to the node level -# Network vs Node Configuration +# Network vs node configuration -Besu is configured at the network level and the node level. +You can configure Besu at the network level and the node level. -Network wide settings are specified in the [genesis file](../Reference/Config-Items.md). Examples include `evmStackSize` and the -[consensus mechanism](Consensus-Protocols/Overview-Consensus.md). +Specify network-wide settings in the [genesis file](../Reference/Config-Items.md). For example, +include `evmStackSize` or specify the +[consensus mechanism](Consensus-Protocols/Overview-Consensus.md). -Node settings are specified on the command line or in the [node configuration file](../HowTo/Configure/Using-Configuration-File.md). -For example, the [JSON-RPC API methods to enable](../Reference/API-Methods.md) or the -[data directory](../Reference/CLI/CLI-Syntax.md#data-path) for the node. \ No newline at end of file +Specify node settings on the command line or in the +[node configuration file](../HowTo/Configure/Using-Configuration-File.md). For example, enable +[JSON-RPC API methods](../Reference/API-Methods.md) or specify the +[data directory](../Reference/CLI/CLI-Syntax.md#data-path) for the node. \ No newline at end of file diff --git a/docs/Concepts/NetworkID-And-ChainID.md b/docs/Concepts/NetworkID-And-ChainID.md index c1d498e338a..facde082edb 100644 --- a/docs/Concepts/NetworkID-And-ChainID.md +++ b/docs/Concepts/NetworkID-And-ChainID.md @@ -1,12 +1,13 @@ description: Besu network ID and chain ID implementation -# Network ID and Chain ID +# Network ID and chain ID -Ethereum networks have a network ID and a chain ID. The network ID defaults to the chain ID specified -in the genesis file. +Ethereum networks have a network ID and a chain ID. The network ID defaults to the chain ID +specified in the genesis file. !!! example "Chain ID in Genesis File" + ```json { "config": { @@ -18,11 +19,12 @@ in the genesis file. } ``` -For most networks including MainNet and the public testnets, the network ID and the chain ID are the -same and are specified in the genesis file. +For most networks, including MainNet and the public testnets, the network ID and the chain ID are +the same and specified in the genesis file. -The network ID and chain ID are automatically defined by Besu when connecting to networks specified -using the [`--network`](../Reference/CLI/CLI-Syntax.md#network) option: +The network ID and chain ID are automatically defined by Besu when connecting to networks specified +using the [`--network`](../Reference/CLI/CLI-Syntax.md#network) option. The following table lists +the available networks and their network and chain IDs. | Network | Chain | Chain ID | Network ID | Type | |-----------|-------|----------|------------|-------------| @@ -35,7 +37,6 @@ using the [`--network`](../Reference/CLI/CLI-Syntax.md#network) option: | `mordor` | ETC | 63 | 7 | Test | | `kotti` | ETC | 6 | 6 | Test | -When using the [`--network=dev`](../Reference/CLI/CLI-Syntax.md#network) or -[`--genesis-file`](../Reference/CLI/CLI-Syntax.md#genesis-file) options, you can override the -network ID using the [`--network-id`](../Reference/CLI/CLI-Syntax.md#network-id) option. - +When using the [`--network=dev`](../Reference/CLI/CLI-Syntax.md#network) or +[`--genesis-file`](../Reference/CLI/CLI-Syntax.md#genesis-file) options, you can override the +network ID using the [`--network-id`](../Reference/CLI/CLI-Syntax.md#network-id) option. diff --git a/docs/Concepts/Node-Keys.md b/docs/Concepts/Node-Keys.md index 713d9816111..c7116fceb6b 100644 --- a/docs/Concepts/Node-Keys.md +++ b/docs/Concepts/Node-Keys.md @@ -1,59 +1,71 @@ description: Besu private and public key used to identify node -# Node Keys +# Node keys -Each node has a node key pair consisting of a node private key and node public key. +Each node has a node key pair consisting of a node private key and a node public key. -## Node Private Key +## Node private key -If a `key` file does not exist in the data directory and the [`--node-private-key-file`](../Reference/CLI/CLI-Syntax.md#node-private-key-file) -option is not specified when Besu is started, a node private key is generated and written to the `key` file. -If Besu is stopped and restarted without deleting the `key` file, the same private key is used when Besu is restarted. +If a `key` file does not exist in the data directory and the +[`--node-private-key-file`](../Reference/CLI/CLI-Syntax.md#node-private-key-file) option is not +specified when starting Besu, Besu generates a node private key and writes it to the `key` file. +Stopping and restarting Besu without deleting the `key` file causes Besu to reuse the same private +key when restarting. -If a `key` file exists in the data directory when Besu is started, the node is started with the private key in the `key` file. +If a `key` file exists in the data directory when starting Besu, the node starts with the private +key in the `key` file. !!!info The private key is not encrypted. -## Node Public Key +## Node public key -The node public key is displayed in the log after starting Besu. Use the [`public-key`](../Reference/CLI/CLI-Subcommands.md#public-key) subcommand to export the public key to a file. +The node public key displays in the log after starting Besu. Use the +[`public-key`](../Reference/CLI/CLI-Subcommands.md#public-key) subcommand to export the public key +to a file. -The node public key is also referred to as the node ID. The node ID forms part of the enode URL for a node. +The node public key is also referred to as the node ID. The node ID forms part of the enode URL of +a node. ## Enode URL -Nodes are identified by their enode URL. For example, the `--bootnodes` option and `perm_addNodesToWhitelist` method specify nodes by the enode URL. +The enode URL identifies a node. For example, the `--bootnodes` option and the +`perm_addNodesToWhitelist` method specify nodes by enode URL. -The enode URL is `enode://@` where: +The enode URL format is `enode://@` where: -* `` is the node public key excluding the initial 0x. -* `` is the host and port the bootnode is listening on for P2P peer discovery. -Specified by the [`--p2p-host`](../Reference/CLI/CLI-Syntax.md#p2p-host) and -[`--p2p-port`](../Reference/CLI/CLI-Syntax.md#p2p-port) options -(default host is `127.0.0.1` and port is `30303`). +* `` is the node public key, excluding the initial 0x. +* `` is the host and port the bootnode is listening on for P2P peer discovery. This is +specified by the [`--p2p-host`](../Reference/CLI/CLI-Syntax.md#p2p-host) and +[`--p2p-port`](../Reference/CLI/CLI-Syntax.md#p2p-port) options (the default host is `127.0.0.1` +and the default port is `30303`). !!! example - If the [`--p2p-host`](../Reference/CLI/CLI-Syntax.md#p2p-host) or [`--p2p-port`](../Reference/CLI/CLI-Syntax.md#p2p-port) options are not specified and the node public key is `0xc35c3ec90a8a51fd5703594c6303382f3ae6b2ecb9589bab2c04b3794f2bc3fc2631dabb0c08af795787a6c004d8f532230ae6e9925cbbefb0b28b79295d615f` - - The enode URL is: - `enode://c35c3ec90a8a51fd5703594c6303382f3ae6b2ecb9589bab2c04b3794f2bc3fc2631dabb0c08af795787a6c004d8f532230ae6e9925cbbefb0b28b79295d615f@127.0.0.1:30303` -The enode is displayed when starting a Besu node and can be obtained using the [`net_enode`](../Reference/API-Methods.md#net_enode) -JSON-RPC API method. + If the [`--p2p-host`](../Reference/CLI/CLI-Syntax.md#p2p-host) or + [`--p2p-port`](../Reference/CLI/CLI-Syntax.md#p2p-port) options are not specified and the node + public key is `0xc35c3ec90a8a51fd5703594c6303382f3ae6b2ecb9589bab2c04b3794f2bc3fc2631dabb0c08af795787a6c004d8f532230ae6e9925cbbefb0b28b79295d615f`, + then the enode URL is + `enode://c35c3ec90a8a51fd5703594c6303382f3ae6b2ecb9589bab2c04b3794f2bc3fc2631dabb0c08af795787a6c004d8f532230ae6e9925cbbefb0b28b79295d615f@127.0.0.1:30303` + +The enode URL displays when starting a Besu node. Use the +[`net_enode`](../Reference/API-Methods.md#net_enode) JSON-RPC API method to obtain the enode URL +for the node. The enode advertised to other nodes during discovery is the external IP address and port, as defined by [`--nat-method`](../HowTo/Find-and-Connect/Specifying-NAT.md). -## Specifying a Custom Node Private Key File +## Specifying a custom node private key file -Use the [`--node-private-key-file`](../Reference/CLI/CLI-Syntax.md#node-private-key-file) option to specify a custom `key` file in any location. +Use the [`--node-private-key-file`](../Reference/CLI/CLI-Syntax.md#node-private-key-file) option to +specify a custom `key` file in any location. -If the `key` file exists, the node is started with the private key in the custom `key` file. If the custom `key` file does not exist, -a node private key is generated and written to the custom `key` file. +If the `key` file exists, the node starts with the private key in the `key` file. If the `key` file +does not exist, Besu generates a node private key and writes it to the `key` file. -For example, the following command either reads the node private key from the `privatekeyfile` or writes the generated private key to the `privatekeyfile`: +For example, the following command either reads the node private key from `privatekeyfile` or +writes a generated private key to `privatekeyfile`. !!! example ```bash diff --git a/docs/Concepts/Protocol-Upgrades.md b/docs/Concepts/Protocol-Upgrades.md index 683c1d0d1af..a33edcfad97 100644 --- a/docs/Concepts/Protocol-Upgrades.md +++ b/docs/Concepts/Protocol-Upgrades.md @@ -1,26 +1,29 @@ -description: Protocol Upgrades +description: Protocol upgrades -# Network upgrades in private networks +# Network upgrades in private networks -Network upgrades are the mechanism for upgrading the Ethereum protocol. The point in time at -which the protocol upgrade is applied is the network upgrade. +Network upgrades are the mechanism for upgrading the Ethereum protocol. The point in time at which +the protocol upgrade occurs is the network upgrade. -For the Ethereum mainnet and public testnets (for example, Rinkeby) the milestone blocks are defined in -Hyperledger Besu. Upgrading your Besu client applies the network upgrade. +For the Ethereum mainnet and public testnets (for example, Rinkeby), the milestone block +definitions are in Hyperledger Besu. Upgrading your Besu client applies the network upgrade. -For private networks, protocol upgrades must be agreed on and the network upgrade co-ordinated with all network participants. -The [milestone block](../Reference/Config-Items.md#milestone-blocks) at which to apply the protocol upgrade -[is specified in the genesis file](../HowTo/Upgrade/Upgrade-Protocol.md). +For private networks, all network participants must agree on the protocol upgrades and then +coordinate the network upgrades. The genesis file specifies the +[milestone block](../Reference/Config-Items.md#milestone-blocks) at which to apply the +[protocol upgrade](../HowTo/Upgrade/Upgrade-Protocol.md). -## Backwards Compatibility +## Backwards compatibility -Some protocol upgrades include changes that may break existing contracts (for example, gas cost changes). -Before upgrading your protocol, review included EIPs for possible impact. A [meta EIP](https://eips.ethereum.org/meta) -for each protocol upgrade lists included EIPs. For example, [Istanbul](https://eips.ethereum.org/EIPS/eip-1679). +Some protocol upgrades include changes that might break existing contracts (for example, gas cost +changes). Before upgrading your protocol, review included EIPs for possible impact. A +[meta EIP](https://eips.ethereum.org/meta) for each protocol upgrade lists included EIPs. For +example, [Istanbul](https://eips.ethereum.org/EIPS/eip-1679). -!!! tip - To maintain compatibility with future protocol upgrades, do not hardcode any gas price assumptions. - - Implementing upgradeable contracts enables contracts to be upgraded if a protocol upgrade does include - breaking changes. \ No newline at end of file +!!! tip + + For compatibility with future protocol upgrades, do not hardcode any gas price assumptions. + + Implementing upgradeable contracts enables contracts to be upgraded if a protocol upgrade does + include breaking changes. \ No newline at end of file diff --git a/docs/Concepts/Pruning.md b/docs/Concepts/Pruning.md index e65f2a7e487..76301a5f60c 100644 --- a/docs/Concepts/Pruning.md +++ b/docs/Concepts/Pruning.md @@ -3,11 +3,15 @@ description: Pruning # Pruning -Use pruning to reduce storage required for the world state. Pruning removes state trie nodes that aren't required. +Use pruning to reduce storage required for the world state. Pruning removes state trie nodes that +are not required. !!! Important Using pruning with [private transactions](Privacy/Privacy-Overview.md) is not supported. -To run a full sync to the Ethereum Mainnet with pruning enabled, we recommend approximately 700GB of available disk space. To enable pruning, use the [`--pruning-enabled`](../Reference/CLI/CLI-Syntax.md#pruning-enabled) option. +Running a full sync to the Ethereum Mainnet with pruning enabled requires about 700GB of available +disk space. To enable pruning, use the +[`--pruning-enabled`](../Reference/CLI/CLI-Syntax.md#pruning-enabled) option. -Pruning might increase block import times, but it does not affect the ability of nodes to stay in sync. +Pruning might increase block import times, but it does not affect the ability of nodes to stay in +sync.