standardize code snippets
This commit is contained in:
Joe
parent
42c0b33f1d
commit
2d59711d13
|
|
@ -21,7 +21,7 @@ Ethereum smart contracts have a schema that defines its functions and return typ
|
|||
|
||||
Geth includes a source code generator called `abigen` that can convert Ethereum ABI definitions into easy to use, type-safe Go packages. With a valid Go development environment set up and the go-ethereum repository checked out correctly, `abigen` can be built as follows:
|
||||
|
||||
```
|
||||
```sh
|
||||
$ cd $GOPATH/src/github.com/ethereum/go-ethereum
|
||||
$ go build ./cmd/abigen
|
||||
```
|
||||
|
|
@ -86,7 +86,7 @@ The ABI for `Storage.sol` (`Storage.abi`) looks as follows:
|
|||
|
||||
The contract binding can then be generated by passing the ABI to `abigen` as follows:
|
||||
|
||||
```
|
||||
```sh
|
||||
$ abigen --abi Storage.abi --pkg main --type Storage --out Storage.go
|
||||
```
|
||||
|
||||
|
|
@ -158,13 +158,13 @@ In the previous section, the contract ABI was sufficient for generating the cont
|
|||
|
||||
The bytecode is obtained by running the compiler again but this passing the `--bin` flag, e.g.
|
||||
|
||||
```shell
|
||||
```sh
|
||||
solc --bin Storage.sol -o Storage.bin
|
||||
```
|
||||
|
||||
Then `abigen` can be run again, this time passing `Storage.bin`:
|
||||
|
||||
```
|
||||
```sh
|
||||
$ abigen --abi Storage.abi --pkg main --type Storage --out Storage.go --bin Storage.bin
|
||||
```
|
||||
|
||||
|
|
@ -248,7 +248,7 @@ func main() {
|
|||
|
||||
Running this code requests the creation of a brand new `Storage` contract on the Goerli blockchain. The contract functions can be called while the contract is waiting to be included in a block.
|
||||
|
||||
```
|
||||
```sh
|
||||
Contract pending deploy: 0x46506d900559ad005feb4645dcbb2dbbf65e19cc
|
||||
Transaction waiting to be mined: 0x6a81231874edd2461879b7280ddde1a857162a744e3658ca7ec276984802183b
|
||||
|
||||
|
|
@ -465,7 +465,7 @@ In the past, abigen allowed compilation and binding of a Solidity source file di
|
|||
|
||||
The compilation and binding steps can be joined together into a pipeline, for example:
|
||||
|
||||
```
|
||||
```sh
|
||||
solc Storage.sol --combined-json abi,bin | abigen --pkg main --type storage --out Storage.go --combined-json -
|
||||
```
|
||||
|
||||
|
|
@ -475,7 +475,7 @@ The `abigen` command was made in such a way as to integrate easily into existing
|
|||
|
||||
Place the binding generation command into a Go source file before the package definition:
|
||||
|
||||
```
|
||||
```go
|
||||
//go:generate abigen --sol Storage.sol --pkg main --out Storage.go
|
||||
```
|
||||
|
||||
|
|
|
|||
|
|
@ -35,7 +35,7 @@ The canonical import path for Geth is `github.com/ethereum/go-ethereum`, with al
|
|||
|
||||
All the Geth packages can be downloaded using:
|
||||
|
||||
```
|
||||
```sh
|
||||
$ go get -d github.com/ethereum/go-ethereum/...
|
||||
```
|
||||
|
||||
|
|
@ -176,7 +176,7 @@ func sendTransaction(cl *ethclient.Client) error {
|
|||
|
||||
An instance of `gethclient` can be used in exactly the same way as `ethclient`. However, `gethclient` includes Geth-specific API methods. These additional methods are:
|
||||
|
||||
```shell
|
||||
```sh
|
||||
CallContract()
|
||||
CreatAccessList()
|
||||
GCStats()
|
||||
|
|
|
|||
|
|
@ -54,7 +54,7 @@ debug.traceTransaction("0xfc9359e49278b7ba99f59edac0e3de49956e46e530a53c15aa7122
|
|||
|
||||
The same call can also be invoked from outside the node too via HTTP RPC (e.g. using Curl). In this case, the HTTP endpoint must be enabled in Geth using the `--http` command and the `debug` API namespace must be exposed using `--http.api=debug`.
|
||||
|
||||
```
|
||||
```sh
|
||||
$ curl -H "Content-Type: application/json" -d '{"id": 1, "method": "debug_traceTransaction", "params": ["0xfc9359e49278b7ba99f59edac0e3de49956e46e530a53c15aa71226b7aa92c6f"]}' localhost:8545
|
||||
```
|
||||
|
||||
|
|
@ -62,7 +62,7 @@ To follow along with this tutorial, transaction hashes can be found from a local
|
|||
|
||||
It is also possible to configure the trace by passing Boolean (true/false) values for four parameters that tweak the verbosity of the trace. By default, the *EVM memory* and *Return data* are not reported but the *EVM stack* and *EVM storage* are. To report the maximum amount of data:
|
||||
|
||||
```shell
|
||||
```sh
|
||||
enableMemory: true
|
||||
disableStack: false
|
||||
disableStorage: false
|
||||
|
|
@ -79,7 +79,7 @@ The above operation was run on the (now-deprecated) Rinkeby network (with a node
|
|||
|
||||
Alternatively, disabling *EVM Stack*, *EVM Memory*, *Storage* and *Return data* (as demonstrated in the Curl request below) results in the following, much shorter, [trace dump](https://gist.github.com/karalabe/d74a7cb33a70f2af75e7824fc772c5b4).
|
||||
|
||||
```
|
||||
```sh
|
||||
$ curl -H "Content-Type: application/json" -d '{"id": 1, "method": "debug_traceTransaction", "params": ["0xfc9359e49278b7ba99f59edac0e3de49956e46e530a53c15aa71226b7aa92c6f", {"disableStack": true, "disableStorage": true}]}' localhost:8545
|
||||
```
|
||||
|
||||
|
|
|
|||
|
|
@ -29,7 +29,7 @@ Note that the fields `memory`, `stack`, `returnData`, and `storage` have dynamic
|
|||
|
||||
It is also possible to configure the trace by passing Boolean (true/false) values for four parameters that tweak the verbosity of the trace. By default, the _EVM memory_ and _Return data_ are not reported but the _EVM stack_ and _EVM storage_ are. To report the maximum amount of data:
|
||||
|
||||
```shell
|
||||
```sh
|
||||
enableMemory: true
|
||||
disableStack: false
|
||||
disableStorage: false
|
||||
|
|
@ -442,7 +442,6 @@ Returns:
|
|||
DUP13: 2,
|
||||
...
|
||||
}
|
||||
|
||||
```
|
||||
|
||||
## State overrides {#state-overrides}
|
||||
|
|
|
|||
|
|
@ -172,7 +172,7 @@ storage, so here we can't.
|
|||
|
||||
The solution is to have a flag, `afterSload`, which is only true in the opcode right after an `SLOAD`, when we can see the result at the top of the stack.
|
||||
|
||||
```javascript
|
||||
```js
|
||||
tracer = function (tx) {
|
||||
return debug.traceTransaction(tx, {
|
||||
tracer:
|
||||
|
|
@ -204,7 +204,7 @@ tracer = function (tx) {
|
|||
|
||||
The output now contains the result in the line that follows the `SLOAD`.
|
||||
|
||||
```javascript
|
||||
```js
|
||||
[
|
||||
"5921: SLOAD 0",
|
||||
" Result: 1",
|
||||
|
|
|
|||
|
|
@ -16,13 +16,13 @@ Developers should use a recent version of Go for building and testing. We use th
|
|||
|
||||
Switch to the go-ethereum repository root directory. All code can be built using the go tool, placing the resulting binary in `$GOPATH/bin`.
|
||||
|
||||
```text
|
||||
```sh
|
||||
go install -v ./...
|
||||
```
|
||||
|
||||
go-ethereum exectuables can be built individually. To build just geth, use:
|
||||
|
||||
```text
|
||||
```sh
|
||||
go install -v ./cmd/geth
|
||||
```
|
||||
|
||||
|
|
@ -32,13 +32,13 @@ Cross compilation is not recommended, please build Geth for the host architectur
|
|||
|
||||
Testing a package:
|
||||
|
||||
```
|
||||
```sh
|
||||
go test -v ./eth
|
||||
```
|
||||
|
||||
Running an individual test:
|
||||
|
||||
```
|
||||
```sh
|
||||
go test -v ./eth -run TestMethod
|
||||
```
|
||||
|
||||
|
|
@ -46,7 +46,7 @@ go test -v ./eth -run TestMethod
|
|||
|
||||
Running benchmarks, eg.:
|
||||
|
||||
```
|
||||
```sh
|
||||
go test -v -bench . -run BenchmarkJoin
|
||||
```
|
||||
|
||||
|
|
@ -56,7 +56,7 @@ For more information, see the [go test flags](https://golang.org/cmd/go/#hdr-Tes
|
|||
|
||||
A stack trace provides a very detailed look into the current state of the geth node. It helps us to debug issues easier as it contains information about what is currently done by the node. Stack traces can be created by running `debug.stacks()` in the Geth console. If the node was started without the console command or with a script in the background, the following command can be used to dump the stack trace into a file.
|
||||
|
||||
```
|
||||
```sh
|
||||
geth attach <path-to-geth.ipc> --exec "debug.stacks()" > stacktrace.txt
|
||||
```
|
||||
|
||||
|
|
@ -128,7 +128,7 @@ If Geth is started with the `--pprof` option, a debugging HTTP server is made av
|
|||
|
||||
Note that if multiple instances of Geth exist, port `6060` will only work for the first instance that was launched. To generate stacktraces for other instances, they should be started up with alternative pprof ports. Ensure `stderr` is being redirected to a logfile.
|
||||
|
||||
```
|
||||
```sh
|
||||
geth -port=30300 -verbosity 5 --pprof --pprof.port 6060 2>> /tmp/00.glog
|
||||
geth -port=30301 -verbosity 5 --pprof --pprof.port 6061 2>> /tmp/01.glog
|
||||
geth -port=30302 -verbosity 5 --pprof --pprof.port 6062 2>> /tmp/02.glog
|
||||
|
|
@ -136,7 +136,7 @@ geth -port=30302 -verbosity 5 --pprof --pprof.port 6062 2>> /tmp/02.glog
|
|||
|
||||
Alternatively to kill the clients (in case they hang or stalled syncing, etc) and have the stacktrace too, use the `-QUIT` signal with `kill`:
|
||||
|
||||
```
|
||||
```sh
|
||||
killall -QUIT geth
|
||||
```
|
||||
|
||||
|
|
|
|||
|
|
@ -26,7 +26,7 @@ Starting Geth in developer mode is as simple as providing the `--dev` flag. It i
|
|||
|
||||
Remix will be used to deploy a smart contract to the node which requires information to be exchanged externally to Geth's own domain. To permit this, enable `http` and the `net` namespace must be enabled and the Remix URL must be provided to `--http.corsdomain`. For this tutorial some other namespaces will also be enabled. The full command is as follows:
|
||||
|
||||
```shell
|
||||
```sh
|
||||
geth --dev --http --http.api eth,web3,net --http.corsdomain "http://remix.ethereum.org"
|
||||
```
|
||||
|
||||
|
|
@ -71,7 +71,7 @@ INFO [05-09|10:49:03.316] Commit new sealing work number=1 seal
|
|||
|
||||
This terminal must be left running throughout the entire tutorial. In a second terminal, attach a Javascript console. By default the `ipc` file is saved in the `datadir`:
|
||||
|
||||
```shell
|
||||
```sh
|
||||
geth attach <datadir>/geth.ipc
|
||||
```
|
||||
|
||||
|
|
@ -91,7 +91,7 @@ To exit, press ctrl-d or type exit
|
|||
|
||||
For simplicity this tutorial uses Geth's built-in account management. First, the existing accounts can be displayed using `eth.accounts`:
|
||||
|
||||
```shell
|
||||
```sh
|
||||
eth.accounts
|
||||
```
|
||||
|
||||
|
|
@ -104,7 +104,7 @@ true
|
|||
|
||||
The following command can be used to query the balance. The return value is in units of Wei, which is divided by 1<sup>18</sup> to give units of ether. This can be done explicitly or by calling the `web3.FromWei()` function:
|
||||
|
||||
```shell
|
||||
```sh
|
||||
eth.getBalance(eth.coinbase)/1e18
|
||||
|
||||
// or
|
||||
|
|
@ -120,7 +120,7 @@ Using `web3.fromWei()` is less error prone because the correct multiplier is bui
|
|||
|
||||
A new account can be created using Clef. Some of the ether from the coinbase can then be transferred across to it. A new account is generated using the `newaccount` function on the command line:
|
||||
|
||||
```shell
|
||||
```sh
|
||||
clef newaccount --keystore <path-to-keystore>
|
||||
```
|
||||
|
||||
|
|
@ -128,13 +128,13 @@ The terminal will display a request for a password, twice. Once provided, a new
|
|||
|
||||
To reconfirm the account creation, running `eth.accounts` in the Javascript console should display an array containing two account addresses, one being the coinbase and the other being the newly generated address. The following command transfers 50 ETH from the coinbase to the new account:
|
||||
|
||||
```shell
|
||||
```sh
|
||||
eth.sendTransaction({from: eth.coinbase, to: eth.accounts[1], value: web3.toWei(50, "ether")})
|
||||
```
|
||||
|
||||
A transaction hash will be returned to the console. This transaction hash will also be displayed in the logs in the Geth console, followed by logs confirming that a new block was mined (remember in the local development network blocks are mined when transactions are pending). The transaction details can be displayed in the Javascript console by passing the transaction hash to `eth.getTransaction()`:
|
||||
|
||||
```shell
|
||||
```sh
|
||||
eth.getTransaction("0x62044d2cab405388891ee6d53747817f34c0f00341cde548c0ce9834e9718f27")
|
||||
```
|
||||
|
||||
|
|
@ -263,7 +263,7 @@ The transaction hash can be used to retrieve the transaction details using the G
|
|||
|
||||
The `from` address is the account that sent the transaction, the `to` address is the deployment address of the contract. The value entered into Remix is now in storage at that contract address. This can be retrieved using Remix by calling the `retrieve` function - to do this simply click the `retrieve` button. Alternatively, it can be retrieved using `web3.getStorageAt` using the Geth Javascript console. The following command returns the value in the contract storage (replace the given address with the correct one displayed in the Geth logs).
|
||||
|
||||
```shell
|
||||
```sh
|
||||
web3.eth.getStorageAt("0x407d73d8a49eeb85d32cf465507dd71d507100c1", 0)
|
||||
```
|
||||
|
||||
|
|
@ -279,7 +279,7 @@ The returned value is a left-padded hexadecimal value. For example, the return v
|
|||
|
||||
This tutorial used an ephemeral blockchain that is completely destroyed and started afresh during each dev-mode session. However, it is also possible to create persistent blockchain and account data that can be reused across multiple sessions. This is done by providing the `--datadir` flag and a directory name when starting Geth in dev-mode.
|
||||
|
||||
```shell
|
||||
```sh
|
||||
geth --datadir dev-chain --dev --http --http.api web3,eth,net --http.corsdomain "remix.ethereum.org"
|
||||
```
|
||||
|
||||
|
|
@ -287,10 +287,8 @@ geth --datadir dev-chain --dev --http --http.api web3,eth,net --http.corsdomain
|
|||
|
||||
Geth will fail to start in dev-mode if keys have been manually created or imported into the keystore in the `--datadir` directory. This is because the account cannot be automatically unlocked. To resolve this issue, the password defined when the account was created can be saved to a text file and its path passed to the `--password` flag on starting Geth, for example if `password.txt` is saved in the top-level `go-ethereum` directory:
|
||||
|
||||
```shell
|
||||
|
||||
```sh
|
||||
geth --datadir dev-chain --dev --http --http.api web3,eth,net --http.corsdomain "remix.ethereum.org" --password password.txt
|
||||
|
||||
```
|
||||
|
||||
**Note** that this is an edge-case that applies when both the `--datadir` and `--dev` flags are used and a key has been manually created or imported into the keystore.
|
||||
|
|
|
|||
|
|
@ -11,13 +11,13 @@ DNS-based node lists can serve as a fallback option when connectivity to the dis
|
|||
|
||||
`cmd/devp2p` is a developer utility and is not included in the Geth distribution. You can install this command using `go get`:
|
||||
|
||||
```shell
|
||||
```sh
|
||||
go get github.com/ethereum/go-ethereum/cmd/devp2p
|
||||
```
|
||||
|
||||
To create a signing key, the `ethkey` utility is needed.
|
||||
|
||||
```shell
|
||||
```sh
|
||||
go get github.com/ethereum/go-ethereum/cmd/ethkey
|
||||
```
|
||||
|
||||
|
|
@ -25,7 +25,7 @@ go get github.com/ethereum/go-ethereum/cmd/ethkey
|
|||
|
||||
Our first step is to compile a list of all reachable nodes. The DHT crawler in cmd/devp2p is a batch process which runs for a set amount of time. You should should schedule this command to run at a regular interval. To create a node list, run
|
||||
|
||||
```shell
|
||||
```sh
|
||||
devp2p discv4 crawl -timeout 30m all-nodes.json
|
||||
```
|
||||
|
||||
|
|
@ -45,13 +45,13 @@ To create a filtered node set, first create a new directory to hold the output s
|
|||
can use any directory name, though it's good practice to use the DNS domain name as the
|
||||
name of this directory.
|
||||
|
||||
```shell
|
||||
```sh
|
||||
mkdir mainnet.nodes.example.org
|
||||
```
|
||||
|
||||
Then, to create the output set containing Ethereum mainnet nodes only, run
|
||||
|
||||
```shell
|
||||
```sh
|
||||
devp2p nodeset filter all-nodes.json -eth-network mainnet > mainnet.nodes.example.org/nodes.json
|
||||
```
|
||||
|
||||
|
|
@ -67,13 +67,13 @@ The following filter flags are available:
|
|||
|
||||
To turn a node list into a DNS node tree, the list needs to be signed. To do this, a key pair is required. To create the key file in the correct format, the cmd/ethkey utility should be used. Choose a strong password to encrypt the key on disk!
|
||||
|
||||
```shell
|
||||
```sh
|
||||
ethkey generate dnskey.json
|
||||
```
|
||||
|
||||
Now use `devp2p dns sign` to update the signature of the node list. If the list's directory name differs from the name it will be published at,specify the DNS name the using the `-domain` flag. This command will prompt for the key file password and update the tree signature.
|
||||
|
||||
```shell
|
||||
```sh
|
||||
devp2p dns sign mainnet.nodes.example.org dnskey.json
|
||||
```
|
||||
|
||||
|
|
@ -85,7 +85,7 @@ Now that the tree is signed, it can be published to a DNS provider. cmd/devp2p c
|
|||
|
||||
To publish to CloudFlare, first create an API token in the management console. cmd/devp2p expects the API token in the `CLOUDFLARE_API_TOKEN` environment variable. Now use the following command to upload DNS TXT records via the CloudFlare API:
|
||||
|
||||
```shell
|
||||
```sh
|
||||
devp2p dns to-cloudflare mainnet.nodes.example.org
|
||||
```
|
||||
|
||||
|
|
@ -95,6 +95,6 @@ Note that this command uses the domain name specified during signing. Any existi
|
|||
|
||||
Once a tree is available through a DNS name, Geth can use it with the `--discovery.dns` command line flag. Node trees are referenced using the `enrtree://` URL scheme. The URL of the tree can be found in the `enrtree-info.json` file created by `devp2p dns sign`. Pass the URL as an argument to the flag in order to make use of the published tree.
|
||||
|
||||
```shell
|
||||
```sh
|
||||
geth --discovery.dns "enrtree://AMBMWDM3J6UY3M32TMMROUNLX6Y3YTLVC3DC6HN2AVG5NHNSAXDW6@mainnet.nodes.example.org"
|
||||
```
|
||||
|
|
|
|||
|
|
@ -17,7 +17,7 @@ A private network is composed of multiple Ethereum nodes that can only connect t
|
|||
|
||||
Ethereum Mainnet has Network ID = 1. There are also many other networks that Geth can connect to by providing alternative Chain IDs, some are testnets and others are alternative networks built from forks of the Geth source code. Providing a network ID that is not already being used by an existing network or testnet means the nodes using that network ID can only connect to each other, creating a private network. A list of current network IDs is available at [Chainlist.org](https://chainlist.org/). The network ID is controlled using the `networkid` flag, e.g.
|
||||
|
||||
```shell
|
||||
```sh
|
||||
geth --networkid 12345
|
||||
```
|
||||
|
||||
|
|
@ -49,7 +49,7 @@ Below is an example of a `genesis.json` file for a PoA network. The `config` sec
|
|||
|
||||
The signer account keys can be generated using the [geth account](/docs/fundamentals/account-management) command (this command can be run multiple times to create more than one signer key).
|
||||
|
||||
```shell
|
||||
```sh
|
||||
geth account new --datadir data
|
||||
```
|
||||
|
||||
|
|
@ -117,13 +117,13 @@ Since Ethash is the default consensus algorithm, no additional parameters need t
|
|||
|
||||
To create a blockchain node that uses this genesis block, first use `geth init` to import and sets the canonical genesis block for the new chain. This requires the path to `genesis.json` to be passed as an argument.
|
||||
|
||||
```shell
|
||||
```sh
|
||||
geth init --datadir data genesis.json
|
||||
```
|
||||
|
||||
When Geth is started using `--datadir data` the genesis block defined in `genesis.json` will be used. For example:
|
||||
|
||||
```shell
|
||||
```sh
|
||||
geth --datadir data --networkid 12345
|
||||
```
|
||||
|
||||
|
|
@ -143,7 +143,7 @@ The modification to `genesis.json` is as follows:
|
|||
|
||||
The upgrade command is:
|
||||
|
||||
```shell
|
||||
```sh
|
||||
geth init --datadir data genesis.json
|
||||
```
|
||||
|
||||
|
|
@ -155,13 +155,13 @@ To configure a bootstrap node, the IP address of the machine the bootstrap node
|
|||
|
||||
The bootstrap node IP is set using the `--nat` flag (the command below contains an example address - replace it with the correct one).
|
||||
|
||||
```shell
|
||||
```sh
|
||||
geth --datadir data --networkid 15 --nat extip:172.16.254.4
|
||||
```
|
||||
|
||||
The 'node record' of the bootnode can be extracted using the JS console:
|
||||
|
||||
```shell
|
||||
```sh
|
||||
geth attach data/geth.ipc --exec admin.nodeInfo.enr
|
||||
```
|
||||
|
||||
|
|
@ -174,7 +174,7 @@ This command should print a base64 string such as the following example. Other n
|
|||
If the nodes are intended to connect across the Internet, the bootnode and all other nodes must have public IP addresses assigned, and both TCP and UDP traffic can pass their firewalls. If Internet connectivity is not required or all member nodes connect using well-known IPs, Geth should be set up to restrict peer-to-peer connectivity to an IP subnet. Doing so will further isolate the network and prevents cross-connecting with other blockchain networks in case the nodes are reachable from the Internet. Use the
|
||||
`--netrestrict` flag to configure a whitelist of IP networks:
|
||||
|
||||
```shell
|
||||
```sh
|
||||
geth <other-flags> --netrestrict 172.16.254.0/24
|
||||
```
|
||||
|
||||
|
|
@ -186,13 +186,13 @@ Before running a member node, it must be initialized with the same genesis file
|
|||
|
||||
For example, using data directory (example: `data2`) and listening port (example: `30305`):
|
||||
|
||||
```shell
|
||||
```sh
|
||||
geth --datadir data2 --networkid 12345 --port 30305 --bootnodes <bootstrap-node-record>
|
||||
```
|
||||
|
||||
With the member node running, it is possible to check that it is connected to the bootstrap node or any other node in the network by attaching a console and running `admin.peers`. It may take up to a few seconds for the nodes to get connected.
|
||||
|
||||
```shell
|
||||
```sh
|
||||
geth attach data2/geth.ipc --exec admin.peers
|
||||
```
|
||||
|
||||
|
|
@ -200,7 +200,7 @@ geth attach data2/geth.ipc --exec admin.peers
|
|||
|
||||
To set up Geth for signing blocks in Clique, a signer account must be available. The account must already be available as a keyfile in the keystore. To use it for signing blocks, it must be unlocked. The following command, for address `0x7df9a875a174b3bc565e6424a0050ebc1b2d1d82` will prompt for the account password, then start signing blocks:
|
||||
|
||||
```shell
|
||||
```sh
|
||||
geth <other-flags> --unlock 0x7df9a875a174b3bc565e6424a0050ebc1b2d1d82 --mine
|
||||
```
|
||||
|
||||
|
|
@ -210,7 +210,7 @@ Mining can be further configured by changing the default gas limit blocks conver
|
|||
|
||||
For PoW in a simple private network, a single CPU miner instance is enough to create a stable stream of blocks at regular intervals. To start a Geth instance for mining, it can be run with all the usual flags plus the following to configure mining:
|
||||
|
||||
```shell
|
||||
```sh
|
||||
geth <other-flags> --mine --miner.threads=1 --miner.etherbase=0xf41c74c9ae680c1aa78f42e5647a62f353b7bdde
|
||||
```
|
||||
|
||||
|
|
@ -220,13 +220,13 @@ This will start mining bocks and transactions on a single CPU thread, crediting
|
|||
|
||||
This section will run through the commands for setting up a simple private network of two nodes. Both nodes will run on the local machine using the same genesis block and network ID. The data directories for each node will be named `node1` and `node2`.
|
||||
|
||||
```shell
|
||||
```sh
|
||||
`mkdir node1 node2`
|
||||
```
|
||||
|
||||
Each node will have an associated account that will receive some ether at launch. The following command creates an account for Node 1:
|
||||
|
||||
```shell
|
||||
```sh
|
||||
geth --datadir node1 account new
|
||||
```
|
||||
|
||||
|
|
@ -286,7 +286,7 @@ In each data directory save a copy of the following `genesis.json` to the top le
|
|||
|
||||
The nodes can now be set up using `geth init` as follows:
|
||||
|
||||
```shell
|
||||
```sh
|
||||
geth init --datadir node1 genesis.json
|
||||
```
|
||||
|
||||
|
|
@ -308,13 +308,13 @@ INFO [05-13|15:41:47.558] Successfully wrote genesis state database=chai
|
|||
|
||||
The next step is to configure a bootnode. This can be any node, but for this tutorial the developer tool `bootnode` will be used to quickly and easily configure a dedicated bootnode. First the bootnode requires a key, which can be created with the following command, which will save a key to `boot.key`:
|
||||
|
||||
```shell
|
||||
```sh
|
||||
bootnode -genkey boot.key
|
||||
```
|
||||
|
||||
This key can then be used to generate a bootnode as follows:
|
||||
|
||||
```
|
||||
```sh
|
||||
bootnode -nodekey boot.key -addr :30305
|
||||
```
|
||||
|
||||
|
|
@ -329,7 +329,7 @@ INFO [05-13|15:50:03.645] New local node record seq=1,652,453
|
|||
|
||||
The two nodes can now be started. Open separate terminals for each node, leaving the bootnode running in the original terminal. In each terminal, run the following command (replacing `node1` with `node2` where appropriate, and giving each node a different port ID. The account address and password file for node 1 must also be provided:
|
||||
|
||||
```shell
|
||||
```sh
|
||||
./geth --datadir node1 --port 30306 --bootnodes enode://f7aba85ba369923bffd3438b4c8fde6b1f02b1c23ea0aac825ed7eac38e6230e5cadcf868e73b0e28710f4c9f685ca71a86a4911461637ae9ab2bd852939b77f@127.0.0.1:0?discport=30305 --networkid 123454321 --unlock 0xC1B2c0dFD381e6aC08f34816172d6343Decbb12b --password node1/password.txt
|
||||
```
|
||||
|
||||
|
|
@ -434,13 +434,13 @@ This should return the following:
|
|||
|
||||
The account associated with Node 1 was supposed to be funded with some ether at the chain genesis. This can be checked easily using `eth.getBalance()`:
|
||||
|
||||
```shell
|
||||
```sh
|
||||
eth.getBalance(eth.accounts[0])
|
||||
```
|
||||
|
||||
This account can then be unlocked and some ether sent to Node 2, using the following commands:
|
||||
|
||||
```javascript
|
||||
```js
|
||||
// send some Wei
|
||||
eth.sendTransaction({
|
||||
to: '0xc94d95a5106270775351eecfe43f97e8e75e59e8',
|
||||
|
|
|
|||
|
|
@ -66,7 +66,7 @@ Clef will request the new password in the terminal.
|
|||
|
||||
The same can be achieved using raw JSON requests (this example send the request to Clef's exposed HTTP port using curl):
|
||||
|
||||
```shell
|
||||
```sh
|
||||
curl -X POST --data '{"id": 0, "jsonrpc": "2.0", "method": "account_new", "params": []}' http://localhost:8550 -H "Content-Type: application/json"
|
||||
```
|
||||
|
||||
|
|
@ -149,7 +149,7 @@ It is also possible to create an account by importing an existing private key. F
|
|||
|
||||
Geth requires the private key to be stored as a file which contains the private key as unencrypted canonical elliptic curve bytes encoded into hex (i.e. plain text key without leading 0x). The new account is then saved in encrypted format, protected by a passphrase the user provides on request. As always, this passphrase must be securely and safely backed up - there is no way to retrieve or reset it if it is forgotten!
|
||||
|
||||
```shell
|
||||
```sh
|
||||
$ geth account import --datadir /some-dir ./keyfile
|
||||
```
|
||||
|
||||
|
|
@ -166,7 +166,7 @@ This import/export process is **not necessary** for users transferring accounts
|
|||
|
||||
It is also possible to import an account in non-interactive mode by saving the account password as plaintext in a `.txt` file and passing its path with the `--password` flag on startup.
|
||||
|
||||
```shell
|
||||
```sh
|
||||
geth account import --password path/password.txt path/keyfile
|
||||
```
|
||||
|
||||
|
|
@ -198,13 +198,13 @@ This will cause Clef to prompt for a new password, twice, and then the Clef mast
|
|||
|
||||
Geth's `account update` subcommand can also be used to update the account password:
|
||||
|
||||
```shell
|
||||
```sh
|
||||
geth account update a94f5374fce5edbc8e2a8697c15331677e6ebf0b
|
||||
```
|
||||
|
||||
Alternatively, in non-interactive mode the path to a password file containing the account password in unencrypted plaintext can be passed with the `--password` flag:
|
||||
|
||||
```shell
|
||||
```sh
|
||||
geth account update a94f5374fce5edbc8e2a8697c15331677e6ebf0b --password path/password.txt
|
||||
```
|
||||
|
||||
|
|
@ -218,7 +218,7 @@ With Clef, indiscriminate account unlocking is no longer a feature. Instead, Cle
|
|||
|
||||
Transactions can be sent using raw JSON requests to Geth or using `web3js` in the Javascript console. Either way, with Clef acting as the signer the transactions will not get sent until approval is given in Clef. The following code snippet shows how a transaction could be sent between two accounts in the keystore using the Javascript console.
|
||||
|
||||
```shell
|
||||
```sh
|
||||
var tx = {from: eth.accounts[1], to: eth.accounts[2], value: web3.toWei(5, "ether")}
|
||||
|
||||
# this will hang until approval is given in the Clef console
|
||||
|
|
|
|||
|
|
@ -12,7 +12,7 @@ geth --help
|
|||
|
||||
## Commands {#commands}
|
||||
|
||||
```
|
||||
```sh
|
||||
NAME:
|
||||
geth - the go-ethereum command line interface
|
||||
|
||||
|
|
|
|||
|
|
@ -33,7 +33,7 @@ Recent versions of Geth (>`1.9.14`) unindex older transactions to save disk spac
|
|||
|
||||
The whole command for starting Geth with a light server could look as follows:
|
||||
|
||||
```shell
|
||||
```sh
|
||||
geth --light.serve 50 --txlookuplimit 0
|
||||
```
|
||||
|
||||
|
|
@ -41,7 +41,7 @@ geth --light.serve 50 --txlookuplimit 0
|
|||
|
||||
Running a light client simply requires Geth to be started in light mode. It is likely that a user would also want to interact with the light node using, for example, RPC. This can be enabled using the `--http` command.
|
||||
|
||||
```shell
|
||||
```sh
|
||||
geth --syncmode light --http --http.api "eth,debug"
|
||||
```
|
||||
|
||||
|
|
|
|||
|
|
@ -33,7 +33,7 @@ geth --verbosity 5 >> /path/eth.log 2>&1
|
|||
|
||||
When Geth starts up it immediately reports a fairly long page of configuration details and status reports that allow the user to confirm Geth is on the right network and operating in its intended modes. The basic structure of a log message is as follows:
|
||||
|
||||
```
|
||||
```sh
|
||||
MESSAGE_TYPE [MONTH-DAY][TIME] MESSAGE VALUE
|
||||
```
|
||||
|
||||
|
|
@ -41,7 +41,7 @@ Where `MESSAGE_TYPE` can be `INFO`, `WARN`, `ERROR` or `DEBUG`. These tags categ
|
|||
|
||||
The messages displayed on startup break down as follows:
|
||||
|
||||
```
|
||||
```terminal
|
||||
INFO [10-04|10:20:52.028] Starting Geth on Ethereum mainnet...
|
||||
INFO [10-04|10:20:52.028] Bumping default cache on mainnet provided=1024 updated=4096
|
||||
INFO [10-04|10:20:52.030] Maximum peer count ETH=50 LES=0 total=50
|
||||
|
|
@ -59,7 +59,7 @@ 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.
|
||||
|
||||
```
|
||||
```terminal
|
||||
---------------------------------------------------------------------------------------------------------------------------------------------------------
|
||||
INFO [10-04|10:20:52.386] Chain ID: 1 (mainnet)
|
||||
INFO [10-04|10:20:52.386] Consensus: Beacon (proof-of-stake), merged from Ethash (proof-of-work)
|
||||
|
|
@ -83,7 +83,7 @@ INFO [10-04|10:20:52.387] - Gray Glacier: 15050000 (https://gith
|
|||
|
||||
The above block of messages are related to past Ethereum hard forks. The names are the names of the hard forks and the numbers are the blocks at which the hard fork occurs. This means that blocks with numbers that exceed these values have the configuration required by that hard fork. The specification of each hard fork is available at the provided links (and more information is available on [ethereum.org](https://ethereum.org/en/history/)). The message `Consensus: Beacon (proof-of-stake), merged from Ethash (proof-of-work)` indicates that the node requires a Beacon node to follow the canonical chain - Geth cannot participate in consensus on its own.
|
||||
|
||||
```
|
||||
```terminal
|
||||
INFO [10-04|10:20:52.387] Merge configured:
|
||||
INFO [10-04|10:20:52.387] - Hard-fork specification: https://github.com/ethereum/execution-specs/blob/master/network-upgrades/mainnet-upgrades/paris.md
|
||||
INFO [10-04|10:20:52.387] - Network known to be merged: true
|
||||
|
|
@ -97,7 +97,7 @@ WARN [10-04|10:20:52.388] Engine API enabled protocol=eth
|
|||
|
||||
The messages above relate to [The Merge](https://ethereum.org/en/upgrades/merge/). The Merge was Ethereum's transition from proof-of-work to proof-of-stake based consensus. In Geth, The Merge came in the form of the Paris hard fork which was triggered at a [terminal total difficulty](https://ethereum.org/en/glossary/#terminal-total-difficulty) of 58750000000000000000000 instead of a preconfigured block number like previous hard forks. The hard fork specification is linked in the log message. The message `network known to be merged: true` indicates that the node is following a chain that has passed the terminal total difficulty and undergone the Paris hard fork. Since September 15 2022 this will always be true for nodes on Ethereum Mainnet (and the merged testnets Sepolia and Goerli). The warning `Engine API enabled` informs the user that Geth is exposing the set of API methods required for communication with a consensus client.
|
||||
|
||||
```
|
||||
```terminal
|
||||
INFO [10-04|10:20:52.389] Starting peer-to-peer node instance=Geth/v1.11.0-unstable-e004e7d2-20220926/linux-amd64/go1.19.1
|
||||
INFO [10-04|10:20:52.409] New local node record seq=1,664,875,252,408 id=9aa0e5b14ccd75ec ip=127.0.0.1 udp=30303 tcp=30303
|
||||
INFO [10-04|10:20:52.409] Started P2P networking self=enode://1ef45ab610c2893b70483bf1791b550e5a93763058b0abf7c6d9e6201e07212d61c4896d64de07342c9df734650e3b40812c2dc01f894b6c385acd180ed30fc8@127.0.0.1:30303
|
||||
|
|
@ -120,7 +120,7 @@ The default for Geth is to sync in snap mode. This requires a block header to be
|
|||
|
||||
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:
|
||||
|
||||
```
|
||||
```terminal
|
||||
INFO [07-28|10:29:49.681] Block synchronisation started
|
||||
INFO [07-28|10:29:50.427] Imported new block headers count=1 elapsed=253.434ms number=12,914,945 hash=ee1a08..9ce38a
|
||||
INFO [07-28|10:30:00.224] Imported new block receipts count=64 elapsed=13.703s number=12,914,881 hash=fef964..d789fc age=18m5s size=7.69MiB
|
||||
|
|
@ -130,7 +130,7 @@ 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 takea 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 needs 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
|
||||
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 [09-06|01:31:59.885] Rebuilding state snapshot
|
||||
INFO [09-06|01:31:59.910] Resuming state snapshot generation root=bc64d4..fc1edd accounts=0 slots=0 storage=0.00B dangling=0 elapsed=18.838ms
|
||||
|
|
|
|||
|
|
@ -31,19 +31,19 @@ An account to receive block rewards must first be defined. The address of the ac
|
|||
|
||||
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.
|
||||
|
||||
```shell
|
||||
```sh
|
||||
geth --http --miner.etherbase 0xC95767AC46EA2A9162F0734651d6cF17e5BfcF10
|
||||
```
|
||||
|
||||
The progress of the blockchain syncing can be monitored by attaching a JavaScript console in another terminal. More detailed information about the console can be found on the [Javascript Console](/docs/interface/javascript-console) page. To attach and open a console:
|
||||
|
||||
```shell
|
||||
```sh
|
||||
geth attach http://127.0.0.1:8545
|
||||
```
|
||||
|
||||
Then in the console, to check the sync progress:
|
||||
|
||||
```shell
|
||||
```sh
|
||||
eth.syncing
|
||||
```
|
||||
|
||||
|
|
@ -71,12 +71,12 @@ If the sync is progressing correctly the output will look similar to the followi
|
|||
|
||||
Once the blockchain is synced, mining can begin. In order to begin mining, Ethminer must be run and connected to Geth in a new terminal. OpenCL can be used for a wide range of GPUs, CUDA can be used specifically for Nvidia GPUs:
|
||||
|
||||
```shell
|
||||
```sh
|
||||
#OpenCL
|
||||
ethminer -v 9 -G -P http://127.0.0.1:8545
|
||||
```
|
||||
|
||||
```shell
|
||||
```sh
|
||||
#CUDA
|
||||
ethminer -v -U -P http://127.0.0.1:8545
|
||||
```
|
||||
|
|
@ -99,7 +99,7 @@ More verbose logs can be configured using `-v` and a value between 0-9. The Etha
|
|||
|
||||
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).
|
||||
|
||||
```shell
|
||||
```sh
|
||||
geth --mine --miner.threads=4
|
||||
```
|
||||
|
||||
|
|
@ -116,13 +116,13 @@ Note that mining only makes sense if you are in sync with the network (since you
|
|||
|
||||
Like with GPU mining, an etherbase account must be set. This defaults to the primary account in the keystore but can be set to an alternative address using the `--miner.etherbase` command:
|
||||
|
||||
```shell
|
||||
```sh
|
||||
geth --miner.etherbase '0xC95767AC46EA2A9162F0734651d6cF17e5BfcF10' --mine
|
||||
```
|
||||
|
||||
If there is no account available an account wil be created and automatically configured to be the coinbase. The Javascript console can be used to reset the etherbase account at runtime:
|
||||
|
||||
```shell
|
||||
```sh
|
||||
miner.setEtherbase(eth.accounts[2])
|
||||
```
|
||||
|
||||
|
|
@ -130,20 +130,20 @@ Note that your etherbase does not need to be an address of a local account, it j
|
|||
|
||||
There is an option to add extra data (32 bytes only) to the mined blocks. By convention this is interpreted as a unicode string, so it can be used to add a short vanity tag using `miner.setExtra` in the Javascript console.
|
||||
|
||||
```shell
|
||||
```sh
|
||||
miner.setExtra("ΞTHΞЯSPHΞЯΞ")
|
||||
```
|
||||
|
||||
The console can also be used to check the current hashrate in units H/s (Hash operations per second):
|
||||
|
||||
```shell
|
||||
```sh
|
||||
eth.hashrate
|
||||
712000
|
||||
```
|
||||
|
||||
After some blocks have been mined, the etherbase account balance with be >0. Assuming the etherbase is a local account:
|
||||
|
||||
```shell
|
||||
```sh
|
||||
eth.getBalance(eth.coinbase).toNumber();
|
||||
'34698870000000'
|
||||
```
|
||||
|
|
|
|||
|
|
@ -9,7 +9,7 @@ The execution client (Geth) is responsible for transaction handling, transaction
|
|||
|
||||
The relationship between the two Ethereum clients is shown in the schematic below. The two clients each connect to their own respective peer-to-peer (P2P) networks. This is because the execution clients gossip transactions over their P2P network enabling them to manage their local transaction pool. The consensus clients gossip blocks over their P2P network, enabling consensus and chain growth.
|
||||
|
||||
|
||||
|
||||
|
||||
For this two-client structure to work, consensus clients must be able to pass bundles of transactions to Geth to be executed. Executing the transactions locally is how the client validates that the transactions do not violate any Ethereum rules and that the proposed update to Ethereum’s state is correct. Likewise, when the node is selected to be a block producer the consensus client must be able to request bundles of transactions from Geth to include in the new block. This inter-client communication is handled by a local RPC connection using the [engine API](https://github.com/ethereum/execution-apis/blob/main/src/engine/specification.md).
|
||||
|
||||
|
|
|
|||
|
|
@ -12,7 +12,7 @@ These testnets started as proof-of-work and proof-of-authority testnets, but the
|
|||
|
||||
**Note:** Network selection is not persisted from a config file. To connect to a pre-defined network you must always enable it explicitly, even when using the `--config` flag to load other configuration values. For example:
|
||||
|
||||
```shell
|
||||
```sh
|
||||
# Generate desired config file. You must specify testnet here.
|
||||
geth --goerli --syncmode "full" ... dumpconfig > goerli.toml
|
||||
|
||||
|
|
@ -26,7 +26,7 @@ Geth continuously attempts to connect to other nodes on the network until it has
|
|||
|
||||
A new node entering the network for the first time gets introduced to a set of peers by a bootstrap node ("bootnode") whose sole purpose is to connect new nodes to peers. The endpoints for these bootnodes are hardcoded into Geth, but they can also be specified by providing the `--bootnode` flag along with comma-separated bootnode addresses in the form of [enodes](https://ethereum.org/en/developers/docs/networking-layer/network-addresses/#enode) on startup. For example:
|
||||
|
||||
```shell
|
||||
```sh
|
||||
geth --bootnodes enode://pubkey1@ip1:port1,enode://pubkey2@ip2:port2,enode://pubkey3@ip3:port3
|
||||
```
|
||||
|
||||
|
|
@ -48,7 +48,7 @@ There are occasions when Geth simply fails to connect to peers. The common reaso
|
|||
|
||||
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
|
||||
```js
|
||||
> net.listening
|
||||
true
|
||||
|
||||
|
|
@ -58,7 +58,7 @@ true
|
|||
|
||||
Functions in the `admin` module provide more information about the connected peers, including their IP address, port number, supported protocols etc. Calling `admin.peers` returns this information for all connected peers.
|
||||
|
||||
```
|
||||
```sh
|
||||
> admin.peers
|
||||
[{
|
||||
ID: 'a4de274d3a159e10c2c9a68c326511236381b84c9ec52e72ad732eb0b2b1a2277938f78593cdbe734e6002bf23114d434a085d260514ab336d4acdc312db671b',
|
||||
|
|
@ -90,7 +90,7 @@ Functions in the `admin` module provide more information about the connected pee
|
|||
|
||||
The `admin` module also includes functions for gathering information about the local node rather than its peers. For example, `admin.nodeInfo` returns the name and connectivity details for the local node.
|
||||
|
||||
```
|
||||
```sh
|
||||
> admin.nodeInfo
|
||||
{
|
||||
Name: 'Geth/v0.9.14/darwin/go1.4.2',
|
||||
|
|
@ -112,7 +112,7 @@ It is often useful for developers to connect to private test networks rather tha
|
|||
|
||||
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:
|
||||
|
||||
```
|
||||
```sh
|
||||
geth --datadir <datadir> dumpconfig > config.toml
|
||||
```
|
||||
|
||||
|
|
@ -126,7 +126,7 @@ 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
|
||||
```js
|
||||
admin.addPeer(
|
||||
'enode://f4642fa65af50cfdea8fa7414a5def7bb7991478b768e296f5e4a54e8b995de102e0ceae2e826f293c481b5325f89be6d207b003382e18a8ecba66fbaf6416c0@33.4.2.1:30303'
|
||||
);
|
||||
|
|
@ -136,7 +136,7 @@ admin.addPeer(
|
|||
|
||||
It is sometimes desirable to cap the number of peers Geth will connect to in order to limit on the computational and bandwidth cost associated with running a node. By default, the limit is 50 peers, however, this can be updated by passing a value to `--maxpeers`:
|
||||
|
||||
```shell
|
||||
```sh
|
||||
geth <otherflags> --maxpeers 15
|
||||
```
|
||||
|
||||
|
|
@ -146,7 +146,7 @@ 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
|
||||
```js
|
||||
admin.addTrustedPeer(
|
||||
'enode://f4642fa65af50cfdea8fa7414a5def7bb7991478b768e296f5e4a54e8b995de102e0ceae2e826f293c481b5325f89be6d207b003382e18a8ecba66fbaf6416c0@33.4.2.1:30303'
|
||||
);
|
||||
|
|
|
|||
|
|
@ -13,7 +13,7 @@ There are two types of full node that use different mechanisms to sync up to the
|
|||
|
||||
Snap sync starts froma relatively recent block and syncs from there to the head of the chain, keeping only the most recent 128 block states in memory. The block header to sync up to is provided by the consensus client. Between the initial sync block and the 128 most recent blocks, the node stores occasional snapshots that can be used to rebuild any intermediate state "on-the-fly". The difference between the snap-synced node and a full block-by-block synced node is that a snap synced node started from an initial checkpoint that was more recent than the genesis block. Snap sync is much faster than a full block-by-block sync from genesis. To start a node with snap sync pass `--syncmode snap` at startup.
|
||||
|
||||
|
||||
|
||||
_This image shows the state stored by each sync-mode - red indicates stored state. The full width of each line represents origin to present head_
|
||||
|
||||
Snap sync works by first downloading the headers for a chunk of blocks. Once the headers have been verified, the block bodies and receipts for those blocks are downloaded. In parallel, Geth also sync begins state-sync. In state-sync, Geth first downloads the leaves of the state trie for each block without the intermediate nodes along with a range proof. The state trie is then regenerated locally.
|
||||
|
|
@ -48,10 +48,6 @@ A light node syncs very quickly and stores the bare minimum of blockchain data.
|
|||
|
||||
Read more about light nodes on our [LES page](/docs/interface/les).
|
||||
|
||||
The following diagram shows how Geth stores state data in the different sync modes:
|
||||
|
||||
|
||||
|
||||
## Consensus layer syncing {#consensus-layer-syncing}
|
||||
|
||||
Now that Ethereum has switched to proof-of-stake, all consensus logic and block propagation is handled by consensus clients. This means that syncing the blockchain is a process shared between the consensus and execution clients. Blocks are downloaded by the consensus client and verified by the execution client. In order for Geth to sync, it requires a header from its connected consensus client. Geth does not import any data until it is instructed to by the consensus client. **Geth cannot sync without being connected to a consensus client**. This includes block-by-block syncing from genesis. The consensus client is required to provide a header from the tip of the chain that Geth can sync towards - without it, Geth cannot know that it has followed the right sequence of blocks.
|
||||
|
|
|
|||
|
|
@ -17,7 +17,7 @@ The authorization must then be applied to a specific address/port. This is achie
|
|||
|
||||
A complete command to start Geth so that it can connect to a consensus client looks as follows:
|
||||
|
||||
```shell
|
||||
```sh
|
||||
geth --authrpc.addr localhost --authrpc.port 8551 --authrpc.vhosts localhost --authrpc.jwtsecret /tmp/jwtsecret
|
||||
```
|
||||
|
||||
|
|
@ -58,7 +58,7 @@ Please see the pages on [syncing](/docs/fundamentals/sync-modes) for more detail
|
|||
Geth is the portal for users to send transactions to Ethereum. The Geth Javascript console is available for this purpose, and the majority of the [JSON-RPC API](/docs/rpc/server) will remain available via web3js or HTTP requests with commands as json payloads. These options are explained in more detail on the [Javascript Console page](/docs/interface/javascript-console). The Javascript console can be started
|
||||
using the following command in a separate terminal (assuming Geth's IPC file is saved in `datadir`):
|
||||
|
||||
```shell
|
||||
```sh
|
||||
geth attach datadir/geth.ipc
|
||||
```
|
||||
|
||||
|
|
|
|||
|
|
@ -37,7 +37,7 @@ There are several methods for generating accounts in Geth. This tutorial demonst
|
|||
|
||||
An account is a pair of keys (public and private). Clef needs to know where to save these keys to so that they can be retrieved later. This information is passed to Clef as an argument. This is achieved using the following command:
|
||||
|
||||
```shell
|
||||
```sh
|
||||
clef newaccount --keystore geth-tutorial/keystore
|
||||
```
|
||||
|
||||
|
|
@ -82,7 +82,7 @@ The previous commands used Clef's `newaccount` function to add new key pairs to
|
|||
|
||||
To start Clef, run the Clef executable passing as arguments the keystore file location, config directory location and a chain ID. The config directory was automatically created inside the `geth-tutorial` directory during the previous step. The [chain ID](https://chainlist.org/) is an integer that defines which Ethereum network to connect to. Ethereum mainnet has chain ID 1. In this tutorial Chain ID 11155111 is used which is that of the Sepolia testnet. It is very important that this chain ID parameter is set to 11155111 - Clef uses the chain ID to sign messages so it must be correct. The following command starts Clef on Sepolia:
|
||||
|
||||
```shell
|
||||
```sh
|
||||
clef --keystore geth-tutorial/keystore --configdir geth-tutorial/clef --chainid 11155111
|
||||
```
|
||||
|
||||
|
|
@ -115,7 +115,7 @@ Geth is the Ethereum client that will connect the computer to the Ethereum netwo
|
|||
|
||||
The following command should be run in a new terminal, separate to the one running Clef:
|
||||
|
||||
```shell
|
||||
```sh
|
||||
geth --sepolia --datadir geth-tutorial --authrpc.addr localhost --authrpc.port 8551 --authrpc.vhosts localhost --authrpc.jwtsecret geth-tutorial/jwtsecret --http --http.api eth,net --signer=geth-tutorial/clef/clef.ipc --http
|
||||
```
|
||||
|
||||
|
|
@ -153,14 +153,14 @@ INFO [04-29][15:54:19:656] Imported new block receipts count=698 elapsed=4.46
|
|||
|
||||
This message will be displayed periodically until state healing has finished:
|
||||
|
||||
```
|
||||
```sh
|
||||
INFO [10-20|20:20:09.510] State heal in progress accounts=313,309@17.95MiB slots=363,525@28.77MiB codes=7222@50.73MiB nodes=49,616,912@12.67GiB pending=29805
|
||||
```
|
||||
When state healing is finished, the node is in sync and ready to use.
|
||||
|
||||
Sending an empty Curl request to the http server provides a quick way to confirm that this too has been started without any issues. In a third terminal, the following command can be run:
|
||||
|
||||
```shell
|
||||
```sh
|
||||
curl http://localhost:8545
|
||||
```
|
||||
|
||||
|
|
@ -186,7 +186,7 @@ Geth provides a Javascript console that exposes the Web3.js API. This means that
|
|||
|
||||
This tutorial will use the HTTP option. Note that the terminals running Geth and Clef should both still be active. In a new (third) terminal, the following command can be run to start the console and connect it to Geth using the exposed http port:
|
||||
|
||||
```shell
|
||||
```sh
|
||||
geth attach http://127.0.0.1:8545
|
||||
```
|
||||
|
||||
|
|
@ -208,7 +208,7 @@ The console is now active and connected to Geth. It can now be used to interact
|
|||
|
||||
In this tutorial, the accounts are managed using Clef. This means that requesting information about the accounts requires explicit approval in Clef, which should still be running in its own terminal. Earlier in this tutorial, two accounts were created using Clef. The following command will display the addresses of those two accounts and any others that might have been added to the keystore before or since.
|
||||
|
||||
```javascript
|
||||
```js
|
||||
eth.accounts;
|
||||
```
|
||||
|
||||
|
|
@ -245,7 +245,7 @@ It is also possible for this request to time out if the Clef approval took too l
|
|||
|
||||
Having confirmed that the two addresses created earlier are indeed in the keystore and accessible through the Javascript console, it is possible to retrieve information about how much ether they own. The Sepolia faucet should have sent 0.05 ETH to the address provided, meaning that the balance of one of the accounts should be at least 0.05 ether and the other should be 0. There are other faucets available that may dispense more ETH per request, and multipel requests can be made to accumulate more ETH. The following command displays the account balance in the console:
|
||||
|
||||
```javascript
|
||||
```js
|
||||
web3.fromWei(eth.getBalance('0xca57F3b40B42FCce3c37B8D18aDBca5260ca72EC'), 'ether');
|
||||
```
|
||||
|
||||
|
|
@ -265,7 +265,7 @@ Repeating the command for the other (empty) account should yield:
|
|||
|
||||
The command `eth.sendTransaction` can be used to send some ether from one address to another. This command takes three arguments: `from`, `to` and `value`. These define the sender and recipient addresses (as strings) and the amount of Wei to transfer. It is far less error prone to enter the transaction value in units of ether rather than Wei, so the value field can take the return value from the `toWei` function. The following command, run in the Javascript console, sends 0.1 ether from one of the accounts in the Clef keystore to the other. Note that the addresses here are examples - the user must replace the address in the `from` field with the address currently owning 1 ether, and the address in the `to` field with the address currently holding 0 ether.
|
||||
|
||||
```javascript
|
||||
```js
|
||||
eth.sendTransaction({
|
||||
from: '0xca57f3b40b42fcce3c37b8d18adbca5260ca72ec',
|
||||
to: '0xce8dba5e4157c2b284d8853afeeea259344c1653',
|
||||
|
|
@ -335,7 +335,7 @@ It is also advised to check the account balances using Geth by repeating the ins
|
|||
|
||||
The transaction hash is a unique identifier for this specific transaction that can be used later to retrieve the transaction details. For example, the transaction details can be viewed by pasting this hash into the [Sepolia block explorer](https://sepolia.etherscan.io/). The same information can also be retrieved directly from the Geth node. The hash returned in the previous step can be provided as an argument to `eth.getTransaction` to return the transaction information:
|
||||
|
||||
```javascript
|
||||
```js
|
||||
eth.getTransaction('0x99d489d0bd984915fd370b307c2d39320860950666aac3f261921113ae4f95bb');
|
||||
```
|
||||
|
||||
|
|
@ -373,7 +373,7 @@ Up to this point this tutorial has interacted with Geth using the convenience li
|
|||
|
||||
The command below returns the balance of the given account. This is a HTTP POST request to the local port 8545. The `-H` flag is for header information. It is used here to define the format of the incoming payload, which is JSON. The `--data` flag defines the content of the payload, which is a JSON object. That JSON object contains four fields: `jsonrpc` defines the spec version for the JSON-RPC API, `method` is the specific function being invoked, `params` are the function arguments, and `id` is used for ordering transactions. The two arguments passed to `eth_getBalance` are the account address whose balance to check and the block to query (here `latest` is used to check the balance in the most recently mined block).
|
||||
|
||||
```shell
|
||||
```sh
|
||||
curl -X POST http://127.0.0.1:8545 \
|
||||
-H "Content-Type: application/json" \
|
||||
--data '{"jsonrpc":"2.0", "method":"eth_getBalance", "params":["0xca57f3b40b42fcce3c37b8d18adbca5260ca72ec","latest"], "id":1}'
|
||||
|
|
@ -387,7 +387,7 @@ A successful call will return a response like the one below:
|
|||
|
||||
The balance is in the `result` field in the returned JSON object. However, it is denominated in Wei and presented as a hexadecimal string. There are many options for converting this value to a decimal in units of ether, for example by opening a Python console and running:
|
||||
|
||||
```python
|
||||
```py
|
||||
0xc7d54951f87f7c0 / 1e18
|
||||
```
|
||||
|
||||
|
|
@ -401,7 +401,7 @@ This returns the balance in ether:
|
|||
|
||||
The curl command below returns the list of all accounts.
|
||||
|
||||
```shell
|
||||
```sh
|
||||
curl -X POST http://127.0.0.1:8545 \
|
||||
-H "Content-Type: application/json" \
|
||||
--data '{"jsonrpc":"2.0", "method":"eth_accounts","params":[], "id":1}'
|
||||
|
|
@ -417,7 +417,7 @@ This requires approval in Clef. Once approved, the following information is retu
|
|||
|
||||
Sending a transaction between accounts can also be achieved using Curl. Notice that the value of the transaction is a hexadecimal string in units of Wei. To transfer 0.1 ether, it is first necessary to convert this to Wei by multiplying by 10<sup>18</sup> then converting to hex. 0.1 ether is `"0x16345785d8a0000"` in hex. As before, update the `to` and `from` fields with the addresses in the Clef keystore.
|
||||
|
||||
```shell
|
||||
```sh
|
||||
curl -X POST http://127.0.0.1:8545 \
|
||||
-H "Content-Type: application/json" \
|
||||
--data '{"jsonrpc":"2.0", "method":"eth_sendTransaction", "params":[{"from": "0xca57f3b40b42fcce3c37b8d18adbca5260ca72ec","to": "0xce8dba5e4157c2b284d8853afeeea259344c1653","value": "0x16345785d8a0000"}], "id":1}'
|
||||
|
|
|
|||
|
|
@ -11,20 +11,20 @@ There are several ways to install Geth, including via a package manager, downloa
|
|||
|
||||
The easiest way to install go-ethereum is to use the Geth Homebrew tap. The first step is to check that Homebrew is installed. The following command should return a version number.
|
||||
|
||||
```shell
|
||||
```sh
|
||||
brew -v
|
||||
```
|
||||
|
||||
If a version number is returned, then Homebrew is installed. If not, Homebrew can be installed by following the instructions [here](https://brew.sh/). With Homebrew installed, the following commands add the Geth tap and install Geth:
|
||||
|
||||
```shell
|
||||
```sh
|
||||
brew tap ethereum/ethereum
|
||||
brew install ethereum
|
||||
```
|
||||
|
||||
The previous command installs the latest stable release. Developers that wish to install the most up-to-date version can install the Geth repository's master branch by adding the `--devel` parameter to the install command:
|
||||
|
||||
```shell
|
||||
```sh
|
||||
brew install ethereum --devel
|
||||
```
|
||||
|
||||
|
|
@ -32,7 +32,7 @@ These commands install the core Geth software and the following developer tools:
|
|||
|
||||
Updating an existing Geth installation to the latest version can be achieved by stopping the node and running the following commands:
|
||||
|
||||
```shell
|
||||
```sh
|
||||
brew update
|
||||
brew upgrade
|
||||
brew reinstall ethereum
|
||||
|
|
@ -46,20 +46,20 @@ The easiest way to install Geth on Ubuntu-based distributions is with the built-
|
|||
|
||||
The following command enables the launchpad repository:
|
||||
|
||||
```shell
|
||||
```sh
|
||||
sudo add-apt-repository -y ppa:ethereum/ethereum
|
||||
```
|
||||
|
||||
Then, to install the stable version of go-ethereum:
|
||||
|
||||
```shell
|
||||
```sh
|
||||
sudo apt-get update
|
||||
sudo apt-get install ethereum
|
||||
```
|
||||
|
||||
Or, alternatively the develop version:
|
||||
|
||||
```shell
|
||||
```sh
|
||||
sudo apt-get update
|
||||
sudo apt-get install ethereum-unstable
|
||||
```
|
||||
|
|
@ -68,7 +68,7 @@ These commands install the core Geth software and the following developer tools:
|
|||
|
||||
Updating an existing Geth installation to the latest version can be achieved by stopping the node and running the following commands:
|
||||
|
||||
```shell
|
||||
```sh
|
||||
sudo apt-get update
|
||||
sudo apt-get install ethereum
|
||||
sudo apt-get upgrade geth
|
||||
|
|
@ -86,7 +86,7 @@ Updating an existing Geth installation can be achieved by stopping the node, dow
|
|||
|
||||
Geth can be installed on FreeBSD using the package manager `pkg`. The following command downloads and installs Geth:
|
||||
|
||||
```shell
|
||||
```sh
|
||||
pkg install go-ethereum
|
||||
```
|
||||
|
||||
|
|
@ -96,7 +96,7 @@ The full list of command line options can be viewed [here](/docs/fundamentals/Co
|
|||
|
||||
Updating an existing Geth installation to the latest version can be achieved by stopping the node and running the following commands:
|
||||
|
||||
```shell
|
||||
```sh
|
||||
pkg upgrade
|
||||
```
|
||||
|
||||
|
|
@ -106,7 +106,7 @@ When the node is started again, Geth will automatically use all the data from th
|
|||
|
||||
Installing Geth using ports, simply requires navigating to the `net-p2p/go-ethereum` ports directory and running `make install` as root:
|
||||
|
||||
```shell
|
||||
```sh
|
||||
cd /usr/ports/net-p2p/go-ethereum
|
||||
make install
|
||||
```
|
||||
|
|
@ -117,7 +117,7 @@ The full list of command line options can be viewed [here](/docs/fundamentals/Co
|
|||
|
||||
Updating an existing Geth installation can be achieved by stopping the node and running the following command:
|
||||
|
||||
```shell
|
||||
```sh
|
||||
portsnap fetch
|
||||
```
|
||||
|
||||
|
|
@ -127,7 +127,7 @@ When the node is started again, Geth will automatically use all the data from th
|
|||
|
||||
The Geth package is available from the [community repo](https://www.archlinux.org/packages/community/x86_64/geth/). It can be installed by running:
|
||||
|
||||
```shell
|
||||
```sh
|
||||
pacman -S geth
|
||||
```
|
||||
|
||||
|
|
@ -137,7 +137,7 @@ The full list of command line options can be viewed [here](/docs/fundamentals/Co
|
|||
|
||||
Updating an existing Geth installation can be achieved by stopping the node and running the following command:
|
||||
|
||||
```shell
|
||||
```sh
|
||||
sudo pacman -Sy
|
||||
```
|
||||
|
||||
|
|
@ -168,7 +168,7 @@ A Docker image with recent snapshot builds from our `develop` branch is maintain
|
|||
|
||||
Pulling an image and starting a node is achieved by running these commands:
|
||||
|
||||
```shell
|
||||
```sh
|
||||
docker pull ethereum/client-go
|
||||
docker run -it -p 30303:30303 ethereum/client-go
|
||||
```
|
||||
|
|
@ -191,7 +191,7 @@ The image has the following ports automatically exposed:
|
|||
|
||||
Updating Geth to the latest version simply requires stopping the container, pulling the latest version from Docker and running it:
|
||||
|
||||
```shell
|
||||
```sh
|
||||
docker stop ethereum/client-go
|
||||
docker pull ethereum/client-go:latest
|
||||
docker run -it -p 30303:30303 ethereum/client-go
|
||||
|
|
@ -205,25 +205,25 @@ Geth is written in [Go](https://golang.org/), so building from source code requi
|
|||
|
||||
With Go installed, Geth can be downloaded into a `GOPATH` workspace via:
|
||||
|
||||
```shell
|
||||
```sh
|
||||
go get -d github.com/ethereum/go-ethereum
|
||||
```
|
||||
|
||||
You can also install specific versions via:
|
||||
|
||||
```shell
|
||||
```sh
|
||||
go get -d github.com/ethereum/go-ethereum@v1.9.21
|
||||
```
|
||||
|
||||
The above commands do not build any executables. To do that you can either build one specifically:
|
||||
|
||||
```shell
|
||||
```sh
|
||||
go install github.com/ethereum/go-ethereum/cmd/geth
|
||||
```
|
||||
|
||||
Alternatively, the following command, run in the project root directory (`ethereum/go-ethereum`) in the GO workspace, builds the entire project and installs Geth and all the developer tools:
|
||||
|
||||
```shell
|
||||
```sh
|
||||
go install ./...
|
||||
```
|
||||
|
||||
|
|
@ -232,7 +232,7 @@ Another common error is: `go: cannot use path@version syntax in GOPATH mode`. Th
|
|||
|
||||
Updating an existing Geth installation can be achieved using `go get`:
|
||||
|
||||
```shell
|
||||
```sh
|
||||
go get -u github.com/ethereum/go-ethereum
|
||||
```
|
||||
|
||||
|
|
@ -240,7 +240,7 @@ go get -u github.com/ethereum/go-ethereum
|
|||
|
||||
The Chocolatey package manager provides an easy way to install the required build tools. Chocolatey can be installed by following these [instructions](https://chocolatey.org). Then, to install the build tool the following commands can be run in an Administrator command prompt:
|
||||
|
||||
```
|
||||
```sh
|
||||
C:\Windows\system32> choco install git
|
||||
C:\Windows\system32> choco install golang
|
||||
C:\Windows\system32> choco install mingw
|
||||
|
|
@ -248,7 +248,7 @@ C:\Windows\system32> choco install mingw
|
|||
|
||||
Installing these packages sets up the path environment variables. To get the new path a new command prompt must be opened. To install Geth, a Go workspace directory must first be created, then the Geth source code can be created and built.
|
||||
|
||||
```
|
||||
```sh
|
||||
C:\Users\xxx> mkdir src\github.com\ethereum
|
||||
C:\Users\xxx> git clone https://github.com/ethereum/go-ethereum src\github.com\ethereum\go-ethereum
|
||||
C:\Users\xxx> cd src\github.com\ethereum\go-ethereum
|
||||
|
|
@ -260,26 +260,26 @@ C:\Users\xxx\src\github.com\ethereum\go-ethereum> go install -v ./cmd/...
|
|||
|
||||
To build Geth from source code on FreeBSD, the Geth Github repository can be cloned into a local directory.
|
||||
|
||||
```shell
|
||||
```sh
|
||||
git clone https://github.com/ethereum/go-ethereum
|
||||
```
|
||||
|
||||
Then, the Go compiler can be used to build Geth:
|
||||
|
||||
```shell
|
||||
```sh
|
||||
pkg install go
|
||||
```
|
||||
|
||||
If the Go version currently installed is >= 1.5, Geth can be built using the following command:
|
||||
|
||||
```shell
|
||||
```sh
|
||||
cd go-ethereum
|
||||
make geth
|
||||
```
|
||||
|
||||
If the installed Go version is < 1.5 (quarterly packages, for example), the following command can be used instead:
|
||||
|
||||
```shell
|
||||
```sh
|
||||
cd go-ethereum
|
||||
CC=clang make geth
|
||||
```
|
||||
|
|
@ -295,7 +295,7 @@ build/bin/geth
|
|||
Geth can also be built without using Go workspaces. In this case, the repository should be cloned to a local repository. Then, the command
|
||||
`make geth` configures everything for a temporary build and cleans up afterwards. This method of building only works on UNIX-like operating systems, and a Go installation is still required.
|
||||
|
||||
```shell
|
||||
```sh
|
||||
git clone https://github.com/ethereum/go-ethereum.git
|
||||
cd go-ethereum
|
||||
make geth
|
||||
|
|
@ -305,7 +305,7 @@ These commands create a Geth executable file in the `go-ethereum/build/bin` fold
|
|||
|
||||
To update an existing Geth installation simply stop the node, navigate to the project root directory and pull the latest version from the Geth Github repository. then rebuild and restart the node.
|
||||
|
||||
```shell
|
||||
```sh
|
||||
cd go-ethereum
|
||||
git pull
|
||||
make geth
|
||||
|
|
|
|||
|
|
@ -9,7 +9,7 @@ The [Introduction to the Javascript console](/docs/interacting-with-geth/javascr
|
|||
|
||||
First we need a contract to deploy. We can use the well-known `Storage.sol` contract written in Solidity. The following Solidity code can be copied and pasted into a text editor and saved as `go-ethereum/storage-contract/Storage.sol`.
|
||||
|
||||
```Solidity
|
||||
```js
|
||||
// SPDX License-Identifier: GPL 3.0
|
||||
|
||||
pragma solidity ^0.8.0;
|
||||
|
|
|
|||
|
|
@ -5,7 +5,7 @@ description: How to interact with Geth using Javascript
|
|||
|
||||
Geth responds to instructions encoded as JSON objects as defined in the [JSON-RPC-API](/docs/rpc/server). A Geth user can send these instructions directly, for example over HTTP using tools like [Curl](https://github.com/curl/curl). The code snippet below shows a request for an account balance sent to a local Geth node with the HTTP port `8545` exposed.
|
||||
|
||||
```
|
||||
```sh
|
||||
curl --data '{"jsonrpc":"2.0","method":"eth_getBalance", "params": ["0x9b1d35635cc34752ca54713bb99d38614f63c955", "latest"], "id":2}' -H "Content-Type: application/json" localhost:8545
|
||||
```
|
||||
|
||||
|
|
@ -24,7 +24,7 @@ The purpose of Geth's Javascript console is to provide a built-in environment to
|
|||
|
||||
There are two ways to start an interactive session using Geth console. The first is to provide the `console` command when Geth is started up. This starts the node and runs the console in the same terminal. It is therefore convenient to suppress the logs from the node to prevent them from obscuring the console. If the logs are not needed, they can be redirected to the `dev/null` path, effectively muting them. Alternatively, if the logs are required they can be redirected to a text file. The level of detail provided in the logs can be adjusted by providing a value between 1-6 to the `--verbosity` flag as in the example below:
|
||||
|
||||
```shell
|
||||
```sh
|
||||
# to mute logs
|
||||
geth <other flags> console 2> /dev/null
|
||||
|
||||
|
|
@ -34,7 +34,7 @@ geth <other flags> console --verbosity 3 2> geth-logs.log
|
|||
|
||||
Alternatively, a Javascript console can be attached to an existing Geth instance (i.e. one that is running in another terminal or remotely). In this case, `geth attach` can be used to open a Javascript console connected to the Geth node. It is also necessary to define the method used to connect the console to the node. Geth supports websockets, HTTP or local IPC. To use HTTP or Websockets, these must be enabled at the node by providing the following flags at startup:
|
||||
|
||||
```shell
|
||||
```sh
|
||||
# enable websockets
|
||||
geth <other flags> --ws
|
||||
|
||||
|
|
@ -44,7 +44,7 @@ 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:
|
||||
|
||||
```shell
|
||||
```sh
|
||||
# define a custom http adress, custom http port and enable libraries
|
||||
geth <other commands> --http --http.addr 192.60.52.21 --http.port 8552 --http.api eth,web3,admin
|
||||
|
||||
|
|
@ -56,7 +56,7 @@ It is important to note that by default **some functionality, including account
|
|||
|
||||
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:
|
||||
|
||||
```shell
|
||||
```sh
|
||||
geth attach datadir/geth.ipc
|
||||
```
|
||||
|
||||
|
|
@ -99,7 +99,7 @@ It is also possible to load pre-written Javascript files into the console by pas
|
|||
when starting the console. This is useful for setting up complex contract objects or loading frequently-used
|
||||
functions.
|
||||
|
||||
```shell
|
||||
```sh
|
||||
geth console --preload "/my/scripts/folder/utils.js"
|
||||
```
|
||||
|
||||
|
|
@ -114,17 +114,17 @@ to `geth attach` or `geth console`. The result is displayed directly in the term
|
|||
|
||||
For example, to display the accounts in the keystore:
|
||||
|
||||
```shell
|
||||
```sh
|
||||
geth attach --exec eth.accounts
|
||||
```
|
||||
|
||||
```shell
|
||||
```sh
|
||||
geth attach --exec eth.blockNumber
|
||||
```
|
||||
|
||||
The same syntax can be used to execute a local script file with more complex statements on a remote node over http, for example:
|
||||
|
||||
```shell
|
||||
```sh
|
||||
geth attach http://geth.example.org:8545 --exec 'loadScript("/tmp/checkbalances.js")'
|
||||
|
||||
geth attach http://geth.example.org:8545 --jspath "/tmp" --exec 'loadScript("checkbalances.js")'
|
||||
|
|
|
|||
|
|
@ -5,7 +5,7 @@ description: How to make batch requests using JSON-RPC API
|
|||
|
||||
The JSON-RPC [specification](https://www.jsonrpc.org/specification#batch) outlines how clients can send multiple requests at the same time by filling the request objects in an array. This feature is implemented by Geth's API and can be used to cut network delays. Batching offers visible speed-ups specially when used for fetching larger amounts of mostly independent data objects. Below is an example for fetching a list of blocks in JS:
|
||||
|
||||
```javascript
|
||||
```js
|
||||
import fetch from 'node-fetch';
|
||||
|
||||
async function main() {
|
||||
|
|
|
|||
|
|
@ -7,13 +7,13 @@ In addition to the [JSON-RPC APIs](/docs/interacting_with_geth/RPC/server), Geth
|
|||
|
||||
The GraphQL endpoint piggybacks on the HTTP transport used by JSON-RPC. Hence the relevant `--http` flags and the `--graphql` flag should be passed to Geth:
|
||||
|
||||
```bash
|
||||
```sh
|
||||
geth --http --graphql
|
||||
```
|
||||
|
||||
Now queries can be raised against `http://localhost:8545/graphql`. To change the port, provide a custom port number to `--http.port`, e.g.:
|
||||
|
||||
```bash
|
||||
```sh
|
||||
geth --http --http.port 9545 --graphql
|
||||
```
|
||||
|
||||
|
|
@ -46,20 +46,20 @@ Reading out data from Geth is the biggest use-case for GraphQL. In addition to u
|
|||
|
||||
For example, the code snippet below shows how to obtain the latest block number using Curl. Note the use of a JSON object for the data section:
|
||||
|
||||
```bash
|
||||
```sh
|
||||
❯ curl -X POST http://localhost:8545/graphql -H "Content-Type: application/json" --data '{ "query": "query { block { number } }" }'
|
||||
{"data":{"block":{"number":6004069}}}
|
||||
```
|
||||
|
||||
Alternatively store the JSON-ified query in a file (let's call it `block-num.query`) and do:
|
||||
|
||||
```bash
|
||||
```sh
|
||||
❯ curl -X POST http://localhost:8545/graphql -H "Content-Type: application/json" --data '@block-num.query'
|
||||
```
|
||||
|
||||
Executing a simple query in JS looks as follows. Here the lightweight library `graphql-request` is used to perform the request. Note the use of variables instead of hardcoding the block number in the query:
|
||||
|
||||
```javascript
|
||||
```js
|
||||
const { request, gql } = require('graphql-request');
|
||||
|
||||
const query = gql`
|
||||
|
|
|
|||
|
|
@ -19,7 +19,7 @@ The method accepts a single argument, the [`enode`](https://ethereum.org/en/deve
|
|||
|
||||
### Example
|
||||
|
||||
```javascript
|
||||
```js
|
||||
> admin.addPeer("enode://a979fb575495b8d6db44f750317d0f4622bf4c2aa3365d6af7c284339968eef29b69ad0dce72a4d8db5ebb4968de0e3bec910127f134779fbcb0cb6d3331163c@52.16.188.185:30303")
|
||||
true
|
||||
```
|
||||
|
|
@ -45,7 +45,7 @@ The `datadir` administrative property can be queried for the absolute path the r
|
|||
|
||||
### Example
|
||||
|
||||
```javascript
|
||||
```js
|
||||
> admin.datadir
|
||||
"/home/john/.ethereum"
|
||||
```
|
||||
|
|
@ -80,7 +80,7 @@ The `nodeInfo` administrative property can be queried for all the information kn
|
|||
|
||||
### Example
|
||||
|
||||
```javascript
|
||||
```js
|
||||
> admin.nodeInfo
|
||||
{
|
||||
enode: "enode://44826a5d6a55f88a18298bca4773fca5749cdc3a5c9f308aa7d810e9b31123f3e7c5fba0b1d70aac5308426f47df2a128a6747040a3815cc7dd7167d03be320d@[::]:30303",
|
||||
|
|
@ -124,7 +124,7 @@ The `peers` administrative property can be queried for all the information known
|
|||
|
||||
### Example
|
||||
|
||||
```javascript
|
||||
```js
|
||||
> admin.peers
|
||||
[{
|
||||
caps: ["eth/61", "eth/62", "eth/63"],
|
||||
|
|
@ -196,7 +196,7 @@ The method returns a boolean flag specifying whether the HTTP RPC listener was o
|
|||
|
||||
### Example
|
||||
|
||||
```javascript
|
||||
```js
|
||||
> admin.startHTTP("127.0.0.1", 8545)
|
||||
true
|
||||
```
|
||||
|
|
@ -220,7 +220,7 @@ The method returns a boolean flag specifying whether the WebSocket RPC listener
|
|||
|
||||
### Example
|
||||
|
||||
```javascript
|
||||
```js
|
||||
> admin.startWS("127.0.0.1", 8546)
|
||||
true
|
||||
```
|
||||
|
|
@ -237,7 +237,7 @@ The `stopHTTP` administrative method closes the currently open HTTP RPC endpoint
|
|||
|
||||
### Example
|
||||
|
||||
```javascript
|
||||
```js
|
||||
> admin.stopHTTP()
|
||||
true
|
||||
```
|
||||
|
|
@ -254,7 +254,7 @@ The `stopWS` administrative method closes the currently open WebSocket RPC endpo
|
|||
|
||||
### Example
|
||||
|
||||
```javascript
|
||||
```js
|
||||
> admin.stopWS()
|
||||
true
|
||||
```
|
||||
|
|
|
|||
|
|
@ -16,7 +16,7 @@ Retrieves a snapshot of all clique state at a given block.
|
|||
|
||||
Example:
|
||||
|
||||
```javascript
|
||||
```js
|
||||
> clique.getSnapshot(5463755)
|
||||
{
|
||||
hash: "0x018194fc50ca62d973e2f85cffef1e6811278ffd2040a4460537f8dbec3d5efc",
|
||||
|
|
@ -120,7 +120,7 @@ This is a debugging method which returns statistics about signer activity for th
|
|||
|
||||
Example:
|
||||
|
||||
```
|
||||
```js
|
||||
> clique.status()
|
||||
{
|
||||
inturnPercent: 100,
|
||||
|
|
|
|||
|
|
@ -29,7 +29,7 @@ The location is specified as `<filename>:<line>`.
|
|||
|
||||
Example:
|
||||
|
||||
``` javascript
|
||||
``` js
|
||||
> debug.backtraceAt("server.go:443")
|
||||
```
|
||||
|
||||
|
|
@ -120,7 +120,7 @@ Retrieves the state that corresponds to the block number and returns a list of a
|
|||
|
||||
#### Example
|
||||
|
||||
```javascript
|
||||
```js
|
||||
> debug.dumpBlock(10)
|
||||
{
|
||||
fff7ac99c8e4feb60c9750054bdc14ce1857f181: {
|
||||
|
|
@ -385,12 +385,14 @@ When JS-based tracing (see below) was first implemented, the intended usecase wa
|
|||
This means that this method is only 'useful' for callers who control the node -- at least sufficiently to be able to read the artefacts from the filesystem after the fact.
|
||||
|
||||
The method can be used to dump a certain transaction out of a given block:
|
||||
```
|
||||
|
||||
```js
|
||||
> debug.standardTraceBlockToFile("0x0bbe9f1484668a2bf159c63f0cf556ed8c8282f99e3ffdb03ad2175a863bca63", {txHash:"0x4049f61ffbb0747bb88dc1c85dd6686ebf225a3c10c282c45a8e0c644739f7e9", disableMemory:true})
|
||||
["/tmp/block_0x0bbe9f14-14-0x4049f61f-099048234"]
|
||||
```
|
||||
Or all txs from a block:
|
||||
```
|
||||
|
||||
```js
|
||||
> debug.standardTraceBlockToFile("0x0bbe9f1484668a2bf159c63f0cf556ed8c8282f99e3ffdb03ad2175a863bca63", {disableMemory:true})
|
||||
["/tmp/block_0x0bbe9f14-0-0xb4502ea7-409046657", "/tmp/block_0x0bbe9f14-1-0xe839be8f-954614764", "/tmp/block_0x0bbe9f14-2-0xc6e2052f-542255195", "/tmp/block_0x0bbe9f14-3-0x01b7f3fe-209673214", "/tmp/block_0x0bbe9f14-4-0x0f290422-320999749", "/tmp/block_0x0bbe9f14-5-0x2dc0fb80-844117472", "/tmp/block_0x0bbe9f14-6-0x35542da1-256306111", "/tmp/block_0x0bbe9f14-7-0x3e199a08-086370834", "/tmp/block_0x0bbe9f14-8-0x87778b88-194603593", "/tmp/block_0x0bbe9f14-9-0xbcb081ba-629580052", "/tmp/block_0x0bbe9f14-10-0xc254381a-578605923", "/tmp/block_0x0bbe9f14-11-0xcc434d58-405931366", "/tmp/block_0x0bbe9f14-12-0xce61967d-874423181", "/tmp/block_0x0bbe9f14-13-0x05a20b35-267153288", "/tmp/block_0x0bbe9f14-14-0x4049f61f-606653767", "/tmp/block_0x0bbe9f14-15-0x46d473d2-614457338", "/tmp/block_0x0bbe9f14-16-0x35cf5500-411906321", "/tmp/block_0x0bbe9f14-17-0x79222961-278569788", "/tmp/block_0x0bbe9f14-18-0xad84e7b1-095032683", "/tmp/block_0x0bbe9f14-19-0x4bd48260-019097038", "/tmp/block_0x0bbe9f14-20-0x1517411d-292624085", "/tmp/block_0x0bbe9f14-21-0x6857e350-971385904", "/tmp/block_0x0bbe9f14-22-0xbe3ae2ca-236639695"]
|
||||
|
||||
|
|
@ -399,7 +401,7 @@ Files are created in a temp-location, with the naming standard `block_<blockhash
|
|||
|
||||
On the server side, it also adds some more info when regenerating historical state, namely, the reexec-number if `required historical state is not avaiable` is encountered, so a user can experiment with increasing that setting. It also prints out the remaining block until it reaches target:
|
||||
|
||||
```
|
||||
```terminal
|
||||
INFO [10-15|13:48:25.263] Regenerating historical state block=2385959 target=2386012 remaining=53 elapsed=3m30.990537767s
|
||||
INFO [10-15|13:48:33.342] Regenerating historical state block=2386012 target=2386012 remaining=0 elapsed=3m39.070073163s
|
||||
INFO [10-15|13:48:33.343] Historical state regenerated block=2386012 elapsed=3m39.070454362s nodes=10.03mB preimages=652.08kB
|
||||
|
|
@ -409,7 +411,8 @@ INFO [10-15|13:48:34.421] Wrote trace file=/tmp/block_0x14490c57-2-0x3f4263fe-05
|
|||
```
|
||||
|
||||
The `options` is as follows:
|
||||
```
|
||||
|
||||
```js
|
||||
type StdTraceConfig struct {
|
||||
*vm.LogConfig
|
||||
Reexec *uint64
|
||||
|
|
@ -492,7 +495,7 @@ References:
|
|||
|
||||
#### Example
|
||||
|
||||
```javascript
|
||||
```js
|
||||
> debug.traceBlock("0xblock_rlp")
|
||||
{
|
||||
gas: 85301,
|
||||
|
|
@ -580,7 +583,7 @@ The `debug_traceCall` method lets you run an `eth_call` within the context of th
|
|||
|
||||
No specific call options:
|
||||
|
||||
```sh
|
||||
```js
|
||||
> debug.traceCall(null, "0x0")
|
||||
{
|
||||
failed: false,
|
||||
|
|
@ -591,7 +594,7 @@ No specific call options:
|
|||
```
|
||||
Tracing a call with a destination and specific sender, disabling the storage and memory output (less data returned over RPC)
|
||||
|
||||
```sh
|
||||
```js
|
||||
debug.traceCall({
|
||||
"from": "0xdeadbeef29292929192939494959594933929292",
|
||||
"to": "0xde929f939d939d393f939393f93939f393929023",
|
||||
|
|
@ -603,7 +606,7 @@ debug.traceCall({
|
|||
|
||||
It is possible to supply 'overrides' for both state-data (accounts/storage) and block data (number, timestamp etc). In the example below, a call which executes `NUMBER` is performed, and the overridden number is placed on the stack:
|
||||
|
||||
```sh
|
||||
```js
|
||||
> debug.traceCall({
|
||||
from: eth.accounts[0],
|
||||
value:"0x1",
|
||||
|
|
@ -747,25 +750,25 @@ Sets the logging verbosity pattern.
|
|||
|
||||
If you want to see messages from a particular Go package (directory) and all subdirectories, use:
|
||||
|
||||
``` javascript
|
||||
``` js
|
||||
> debug.vmodule("eth/*=6")
|
||||
```
|
||||
|
||||
If you want to restrict messages to a particular package (e.g. p2p) but exclude subdirectories, use:
|
||||
|
||||
``` javascript
|
||||
``` js
|
||||
> debug.vmodule("p2p=6")
|
||||
```
|
||||
|
||||
If you want to see log messages from a particular source file, use
|
||||
|
||||
``` javascript
|
||||
``` js
|
||||
> debug.vmodule("server.go=6")
|
||||
```
|
||||
|
||||
You can compose these basic patterns. If you want to see all output from peer.go in a package below eth (eth/peer.go, eth/downloader/peer.go) as well as output from package p2p at level <= 5, use:
|
||||
|
||||
``` javascript
|
||||
``` js
|
||||
debug.vmodule("eth/*/peer.go=6,p2p=5")
|
||||
```
|
||||
|
||||
|
|
|
|||
|
|
@ -69,7 +69,7 @@ The method returns a single `Binary` consisting the return value of the executed
|
|||
|
||||
With a synced Rinkeby node with RPC exposed on localhost (`geth --rinkeby --http`) we can make a call against the [CheckpointOracle](https://rinkeby.etherscan.io/address/0xebe8efa441b9302a0d7eaecc277c09d20d684540) to retrieve the list of administrators:
|
||||
|
||||
```
|
||||
```sh
|
||||
$ curl --data '{"method":"eth_call","params":[{"to":"0xebe8efa441b9302a0d7eaecc277c09d20d684540","data":"0x45848dfc"},"latest"],"id":1,"jsonrpc":"2.0"}' -H "Content-Type: application/json" -X POST localhost:8545
|
||||
```
|
||||
|
||||
|
|
@ -85,7 +85,7 @@ And the result is an Ethereum ABI encoded list of accounts:
|
|||
|
||||
Just for the sake of completeness, decoded the response is:
|
||||
|
||||
```
|
||||
```sh
|
||||
0xd9c9cd5f6779558b6e0ed4e6acf6b1947e7fa1f3,
|
||||
0x78d1ad571a1a09d60d9bbf25894b44e4c8859595,
|
||||
0x286834935f4a8cfb4ff4c77d5770c2775ae2b0e7,
|
||||
|
|
@ -98,7 +98,7 @@ The above _simple example_ showed how to call a method already exposed by an on-
|
|||
|
||||
We can gut out the [original](https://github.com/ethereum/go-ethereum/blob/master/contracts/checkpointoracle/contract/oracle.sol) checkpoint oracle contract with one that retains the same fields (to retain the same storage layout), but one that includes a different method set:
|
||||
|
||||
```
|
||||
```js
|
||||
pragma solidity ^0.5.10;
|
||||
|
||||
contract CheckpointOracle {
|
||||
|
|
@ -120,7 +120,7 @@ contract CheckpointOracle {
|
|||
With a synced Rinkeby node with RPC exposed on localhost (`geth --rinkeby --http`) we can make a call against the live [Checkpoint Oracle](https://rinkeby.etherscan.io/address/0xebe8efa441b9302a0d7eaecc277c09d20d684540), but override its byte code with our own version that has an accessor for the voting
|
||||
threshold field:
|
||||
|
||||
```
|
||||
```sh
|
||||
$ curl --data '{"method":"eth_call","params":[{"to":"0xebe8efa441b9302a0d7eaecc277c09d20d684540","data":"0x0be5b6ba"}, "latest", {"0xebe8efa441b9302a0d7eaecc277c09d20d684540": {"code":"0x6080604052348015600f57600080fd5b506004361060285760003560e01c80630be5b6ba14602d575b600080fd5b60336045565b60408051918252519081900360200190f35b6007549056fea265627a7a723058206f26bd0433456354d8d1228d8fe524678a8aeeb0594851395bdbd35efc2a65f164736f6c634300050a0032"}}],"id":1,"jsonrpc":"2.0"}' -H "Content-Type: application/json" -X POST localhost:8545
|
||||
```
|
||||
|
||||
|
|
|
|||
|
|
@ -17,7 +17,7 @@ Get information about currently connected and total/individual allowed connectio
|
|||
|
||||
### Example
|
||||
|
||||
```javascript
|
||||
```js
|
||||
> les.serverInfo
|
||||
{
|
||||
freeClientCapacity: 16000,
|
||||
|
|
@ -41,7 +41,7 @@ Get individual client information (connection, balance, pricing) on the specifie
|
|||
|
||||
### Example
|
||||
|
||||
```javascript
|
||||
```js
|
||||
> les.clientInfo([])
|
||||
{
|
||||
37078bf8ea160a2b3d129bb4f3a930ce002356f83b820f467a07c1fe291531ea: {
|
||||
|
|
@ -113,7 +113,7 @@ Get individual client information on clients with a positive balance in the spec
|
|||
|
||||
### Example
|
||||
|
||||
```javascript
|
||||
```js
|
||||
> les.priorityClientInfo("0x0000000000000000000000000000000000000000000000000000000000000000", "0x0000000000000000000000000000000000000000000000000000000000000000", 100)
|
||||
{
|
||||
37078bf8ea160a2b3d129bb4f3a930ce002356f83b820f467a07c1fe291531ea: {
|
||||
|
|
@ -208,7 +208,7 @@ Add signed value to the token balance of the specified client and update its `me
|
|||
|
||||
### Example
|
||||
|
||||
```javascript
|
||||
```js
|
||||
> les.addBalance("0x6a47fe7bb23fd335df52ef1690f37ab44265a537b1d18eb616a3e77f898d9e77", 1000000000, "qwerty")
|
||||
[968379616, 1968379616]
|
||||
```
|
||||
|
|
@ -225,7 +225,7 @@ Set capacity and pricing factors for the specified list of connected clients or
|
|||
|
||||
### Example
|
||||
|
||||
```javascript
|
||||
```js
|
||||
> les.setClientParams(["0x6a47fe7bb23fd335df52ef1690f37ab44265a537b1d18eb616a3e77f898d9e77"], {
|
||||
"capacity": 100000,
|
||||
"pricing/timeFactor": 0,
|
||||
|
|
@ -250,7 +250,7 @@ Set default pricing factors for subsequently connected clients.
|
|||
|
||||
### Example
|
||||
|
||||
```javascript
|
||||
```js
|
||||
> les.setDefaultParams({
|
||||
"pricing/timeFactor": 0,
|
||||
"pricing/capacityFactor": 1000000000,
|
||||
|
|
@ -274,7 +274,7 @@ Get the index and hashes of the latest known checkpoint.
|
|||
|
||||
### Example
|
||||
|
||||
```javascript
|
||||
```js
|
||||
> les.latestCheckpoint
|
||||
["0x110", "0x6eedf8142d06730b391bfcbd32e9bbc369ab0b46ae226287ed5b29505a376164", "0x191bb2265a69c30201a616ae0d65a4ceb5937c2f0c94b125ff55343d707463e5", "0xf58409088a5cb2425350a59d854d546d37b1e7bef8bbf6afee7fd15f943d626a"]
|
||||
```
|
||||
|
|
@ -291,7 +291,7 @@ Get checkpoint hashes by index.
|
|||
|
||||
### Example
|
||||
|
||||
```javascript
|
||||
```js
|
||||
> les.getCheckpoint(256)
|
||||
["0x93eb4af0b224b1097e09181c2e51536fe0a3bf3bb4d93e9a69cab9eb3e28c75f", "0x0eb055e384cf58bc72ca20ca5e2b37d8d4115dce80ab4a19b72b776502c4dd5b", "0xda6c02f7c51f9ecc3eca71331a7eaad724e5a0f4f906ce9251a2f59e3115dd6a"]
|
||||
```
|
||||
|
|
@ -308,7 +308,7 @@ Get the address of the checkpoint oracle contract.
|
|||
|
||||
### Example
|
||||
|
||||
```javascript
|
||||
```js
|
||||
> les.checkpointContractAddress
|
||||
"0x9a9070028361F7AAbeB3f2F2Dc07F82C4a98A02a"
|
||||
```
|
||||
|
|
|
|||
|
|
@ -47,7 +47,7 @@ Returns all the Ethereum account addresses of all keys in the key store.
|
|||
|
||||
### Example
|
||||
|
||||
```javascript
|
||||
```js
|
||||
> personal.listAccounts
|
||||
["0x5e97870f263700f46aa00d967821199b9bc5a120", "0x3d80b31a78c30fc628f20b2c89d7ddbf6e53cedc"]
|
||||
```
|
||||
|
|
@ -63,7 +63,7 @@ Returns a list of wallets this node manages.
|
|||
|
||||
### Example
|
||||
|
||||
```javascript
|
||||
```js
|
||||
> personal.listWallets
|
||||
[{
|
||||
accounts: [{
|
||||
|
|
@ -96,7 +96,7 @@ Returns the address of the new account. At the geth console, `newAccount` will p
|
|||
|
||||
### Example
|
||||
|
||||
```javascript
|
||||
```js
|
||||
> personal.newAccount()
|
||||
Passphrase:
|
||||
Repeat passphrase:
|
||||
|
|
@ -105,7 +105,7 @@ Repeat passphrase:
|
|||
|
||||
The passphrase can also be supplied as a string.
|
||||
|
||||
```javascript
|
||||
```js
|
||||
> personal.newAccount("h4ck3r")
|
||||
"0x3d80b31a78c30fc628f20b2c89d7ddbf6e53cedc"
|
||||
```
|
||||
|
|
@ -136,7 +136,7 @@ The account can be used with `eth_sign` and `eth_sendTransaction` while it is un
|
|||
|
||||
### Examples
|
||||
|
||||
```javascript
|
||||
```js
|
||||
> personal.unlockAccount("0x5e97870f263700f46aa00d967821199b9bc5a120")
|
||||
Unlock account 0x5e97870f263700f46aa00d967821199b9bc5a120
|
||||
Passphrase:
|
||||
|
|
@ -145,14 +145,14 @@ true
|
|||
|
||||
Supplying the passphrase and unlock duration as arguments:
|
||||
|
||||
```javascript
|
||||
```js
|
||||
> personal.unlockAccount("0x5e97870f263700f46aa00d967821199b9bc5a120", "foo", 30)
|
||||
true
|
||||
```
|
||||
|
||||
To type in the passphrase and still override the default unlock duration, pass `null` as the passphrase.
|
||||
|
||||
```
|
||||
```js
|
||||
> personal.unlockAccount("0x5e97870f263700f46aa00d967821199b9bc5a120", null, 30)
|
||||
Unlock account 0x5e97870f263700f46aa00d967821199b9bc5a120
|
||||
Passphrase:
|
||||
|
|
@ -181,7 +181,7 @@ The transaction is the same argument as for `eth_sendTransaction` (i.e. [transac
|
|||
|
||||
### Examples
|
||||
|
||||
```javascript
|
||||
```js
|
||||
> var tx = {from: "0x391694e7e0b0cce554cb130d723a9d27458f9298", to: "0xafa3f8684e54059998bc3a7b0d2b0da075154d66", value: web3.toWei(1.23, "ether")}
|
||||
undefined
|
||||
> personal.sendTransaction(tx, "passphrase")
|
||||
|
|
@ -204,7 +204,7 @@ See ecRecover to verify the signature.
|
|||
|
||||
### Examples
|
||||
|
||||
```javascript
|
||||
```js
|
||||
> personal.sign("0xdeadbeaf", "0x9b2055d370f73ec7d8a03e965129118dc8f5bf83", "")
|
||||
"0xa3f20717a250c2b0b729b7e5becbff67fdaef7e0699da4de7ca5895b02a170a12d887fd3b17bfdce3481f10bea41f45ba9f709d39ce8325427b57afcfc994cee1b"
|
||||
```
|
||||
|
|
@ -229,7 +229,7 @@ SignTransaction will create a transaction from the given arguments and tries to
|
|||
|
||||
### Examples
|
||||
|
||||
```javascript
|
||||
```js
|
||||
> personal.sign("0xdeadbeaf", "0x9b2055d370f73ec7d8a03e965129118dc8f5bf83", "")
|
||||
"0xa3f20717a250c2b0b729b7e5becbff67fdaef7e0699da4de7ca5895b02a170a12d887fd3b17bfdce3481f10bea41f45ba9f709d39ce8325427b57afcfc994cee1b"
|
||||
> personal.ecRecover("0xdeadbeaf", "0xa3f20717a250c2b0b729b7e5becbff67fdaef7e0699da4de7ca5895b02a170a12d887fd3b17bfdce3481f10bea41f45ba9f709d39ce8325427b57afcfc994cee1b")
|
||||
|
|
|
|||
|
|
@ -21,7 +21,7 @@ Please note, there may be multiple transactions associated with the same account
|
|||
|
||||
### Example
|
||||
|
||||
```javascript
|
||||
```js
|
||||
> txpool.content
|
||||
{
|
||||
pending: {
|
||||
|
|
@ -129,7 +129,7 @@ Please note, there may be multiple transactions associated with the same account
|
|||
|
||||
### Example
|
||||
|
||||
```javascript
|
||||
```js
|
||||
> txpool.inspect
|
||||
{
|
||||
pending: {
|
||||
|
|
@ -196,7 +196,7 @@ The result is an object with two fields `pending` and `queued`, each of which is
|
|||
|
||||
### Example
|
||||
|
||||
```javascript
|
||||
```js
|
||||
> txpool.status
|
||||
{
|
||||
pending: 10,
|
||||
|
|
|
|||
|
|
@ -56,7 +56,7 @@ create user geth with password choosepassword
|
|||
|
||||
Verify created entries with:
|
||||
|
||||
```
|
||||
```sh
|
||||
show databases
|
||||
show users
|
||||
```
|
||||
|
|
|
|||
|
|
@ -42,14 +42,14 @@ A gauge is a single int64 value. Its value can increment and decrement - as with
|
|||
|
||||
Geth collects metrics if the `--metrics` flag is provided at startup. Those metrics are available via an HTTP server if the `--metrics.addr` flag is also provided. By default the metrics are served at `127.0.0.1:6060/debug/metrics` but a custom IP address can be provided. A custom port can also be provided to the `--metrics.port` flag. More computationally expensive metrics are toggled on or off by providing or omitting the `--metrics.expensive` flag. For example, to serve all metrics at the default address and port:
|
||||
|
||||
```
|
||||
```sh
|
||||
geth <other commands> --metrics --metrics.addr 127.0.0.1 --metrics.expensive
|
||||
```
|
||||
|
||||
Navigating the browser to the given metrics address displays all the available metrics in the form
|
||||
of JSON data that looks similar to:
|
||||
|
||||
```
|
||||
```sh
|
||||
chain/account/commits.50-percentile: 374072
|
||||
chain/account/commits.75-percentile: 830356
|
||||
chain/account/commits.95-percentile: 1783005.3999976
|
||||
|
|
@ -67,7 +67,7 @@ Any developer is free to add, remove or modify the available metrics as they see
|
|||
|
||||
Geth also supports dumping metrics directly into an influx database. In order to activate this, the `--metrics.influxdb` flag must be provided at startup. The API endpoint,username, password and other influxdb tags can also be provided. The available tags are:
|
||||
|
||||
```
|
||||
```sh
|
||||
--metrics.influxdb.endpoint value InfluxDB API endpoint to report metrics to (default: "http://localhost:8086")
|
||||
--metrics.influxdb.database value InfluxDB database name to push reported metrics to (default: "geth")
|
||||
--metrics.influxdb.username value Username to authorize access to the database (default: "test")
|
||||
|
|
|
|||
|
|
@ -5,7 +5,7 @@ description: Introduction to the Go binding generator tool, Abigen
|
|||
|
||||
Abigen is a binding-generator for easily interacting with Ethereum using Go. Abigen creates easy-to-use, type-safe Go packages from Ethereum smart contract definitions known as ABIs. This abstracts away a lot of the complexity of handling smart contract deployment and interaction in Go native applications such as encoding and decoding smart contracts into EVM bytecode. Abigen comes bundled with Geth. A full Geth installation includes the abigen binary. Abigen can also be built independently by navigating to `go-ethereum/cmd/abigen` and running `go build`, or equivalently:
|
||||
|
||||
```
|
||||
```sh
|
||||
$ cd $GOPATH/src/github.com/ethereum/go-ethereum
|
||||
$ go build ./cmd/abigen
|
||||
```
|
||||
|
|
@ -18,7 +18,7 @@ Ethereum smart contracts have a schema that defines its functions and return typ
|
|||
|
||||
To demonstrate the binding generator a contract is required. The contract `Storage.sol` implements two very simple functions: `store` updates a user-defined `uint256` to the contract's storage, and `retrieve` displays the value stored in the contract to the user. The Solidity code is as follows:
|
||||
|
||||
```solidity
|
||||
```js
|
||||
// SPDX-License-Identifier: GPL-3.0
|
||||
|
||||
pragma solidity >0.7.0 < 0.9.0;
|
||||
|
|
@ -43,7 +43,7 @@ contract Storage {
|
|||
|
||||
This contract can be pasted into a text file and saved as `Storage.sol`. The following code snippet shows how an ABI can be generated for `Storage.sol` using the Solidity compiler `solc`.
|
||||
|
||||
```shell
|
||||
```sh
|
||||
solc --abi Storage.sol -o build
|
||||
```
|
||||
|
||||
|
|
@ -72,7 +72,7 @@ The ABI for `Storage.sol` (`Storage.abi`) looks as follows:
|
|||
|
||||
The contract binding can then be generated by passing the ABI to `abigen` as follows:
|
||||
|
||||
```
|
||||
```sh
|
||||
$ abigen --abi Storage.abi --pkg main --type Storage --out Storage.go
|
||||
```
|
||||
|
||||
|
|
|
|||
|
|
@ -275,7 +275,7 @@ Response
|
|||
|
||||
Bash example:
|
||||
|
||||
```bash
|
||||
```sh
|
||||
> curl -H "Content-Type: application/json" -X POST --data '{"jsonrpc":"2.0","method":"account_signTransaction","params":[{"from":"0x694267f14675d7e1b9494fd8d72fefe1755710fa","gas":"0x333","gasPrice":"0x1","nonce":"0x0","to":"0x07a565b7ed7d7a678680a4c162885bedbb695fe0", "value":"0x0", "data":"0x4401a6e40000000000000000000000000000000000000000000000000000000000000012"},"safeSend(address)"],"id":67}' http://localhost:8550/
|
||||
|
||||
{"jsonrpc":"2.0","id":67,"result":{"raw":"0xf88380018203339407a565b7ed7d7a678680a4c162885bedbb695fe080a44401a6e4000000000000000000000000000000000000000000000000000000000000001226a0223a7c9bcf5531c99be5ea7082183816eb20cfe0bbc322e97cc5c7f71ab8b20ea02aadee6b34b45bb15bc42d9c09de4a6754e7000908da72d48cc7704971491663","tx":{"nonce":"0x0","gasPrice":"0x1","gas":"0x333","to":"0x07a565b7ed7d7a678680a4c162885bedbb695fe0","value":"0x0","input":"0x4401a6e40000000000000000000000000000000000000000000000000000000000000012","v":"0x26","r":"0x223a7c9bcf5531c99be5ea7082183816eb20cfe0bbc322e97cc5c7f71ab8b20e","s":"0x2aadee6b34b45bb15bc42d9c09de4a6754e7000908da72d48cc7704971491663","hash":"0xeba2df809e7a612a0a0d444ccfa5c839624bdc00dd29e3340d46df3870f8a30e"}}}
|
||||
|
|
@ -533,8 +533,7 @@ Invoked when there's a transaction for approval.
|
|||
|
||||
Here's a method invocation:
|
||||
|
||||
```bash
|
||||
|
||||
```sh
|
||||
curl -i -H "Content-Type: application/json" -X POST --data '{"jsonrpc":"2.0","method":"account_signTransaction","params":[{"from":"0x694267f14675d7e1b9494fd8d72fefe1755710fa","gas":"0x333","gasPrice":"0x1","nonce":"0x0","to":"0x07a565b7ed7d7a678680a4c162885bedbb695fe0", "value":"0x0", "data":"0x4401a6e40000000000000000000000000000000000000000000000000000000000000012"},"safeSend(address)"],"id":67}' http://localhost:8550/
|
||||
```
|
||||
|
||||
|
|
@ -579,8 +578,7 @@ Results in the following invocation on the UI:
|
|||
|
||||
The same method invocation, but with invalid data:
|
||||
|
||||
```bash
|
||||
|
||||
```sh
|
||||
curl -i -H "Content-Type: application/json" -X POST --data '{"jsonrpc":"2.0","method":"account_signTransaction","params":[{"from":"0x694267f14675d7e1b9494fd8d72fefe1755710fa","gas":"0x333","gasPrice":"0x1","nonce":"0x0","to":"0x07a565b7ed7d7a678680a4c162885bedbb695fe0", "value":"0x0", "data":"0x4401a6e40000000000000002000000000000000000000000000000000000000000000012"},"safeSend(address)"],"id":67}' http://localhost:8550/
|
||||
```
|
||||
|
||||
|
|
|
|||
|
|
@ -66,8 +66,10 @@ Create a genesis with that account as a sealer:
|
|||
|
||||
Initiate Geth:
|
||||
|
||||
```
|
||||
```sh
|
||||
$ geth --datadir ./ddir init genesis.json
|
||||
```
|
||||
```terminal
|
||||
...
|
||||
INFO [06-16|11:14:54.123] Writing custom genesis block
|
||||
INFO [06-16|11:14:54.125] Persisted trie from memory database nodes=1 size=153.00B time="64.715µs" gcnodes=0 gcsize=0.00B gctime=0s livenodes=1 livesize=0.00B
|
||||
|
|
@ -85,9 +87,10 @@ In order to make use of `clef` for signing:
|
|||
|
||||
These two things are independent of each other. First of all, however, `clef` must be initiated (for this example the password is `clefclefclef`)
|
||||
|
||||
```
|
||||
```sh
|
||||
$ clef --keystore ./ddir/keystore --configdir ./clef --chainid 15 --suppress-bootwarn init
|
||||
|
||||
```
|
||||
```terminal
|
||||
The master seed of clef will be locked with a password.
|
||||
Please specify a password. Do not forget this password!
|
||||
Password:
|
||||
|
|
@ -111,9 +114,10 @@ After this operation, `clef` has it's own vault where it can store secrets and a
|
|||
|
||||
With that done, `clef` can be made aware of the password. To do this `setpw <address>` is invoked to store a password for a given address. `clef` asks for the password, and it also asks for the master-password, in order to update and store the new secrets inside the vault.
|
||||
|
||||
```
|
||||
```sh
|
||||
$ clef --keystore ./ddir/keystore --configdir ./clef --chainid 15 --suppress-bootwarn setpw 0x9CD932F670F7eDe5dE86F756A6D02548e5899f47
|
||||
|
||||
```
|
||||
```terminal
|
||||
Please enter a password to store for this address:
|
||||
Password:
|
||||
Repeat password:
|
||||
|
|
@ -161,7 +165,7 @@ DEBUG[06-16|11:36:42.499] Served account_list reqid=2 durat
|
|||
|
||||
After this, Geth will start asking `clef` to sign things:
|
||||
|
||||
```
|
||||
```terminal
|
||||
-------- Sign data request--------------
|
||||
Account: 0x9CD932F670F7eDe5dE86F756A6D02548e5899f47 [chksum ok]
|
||||
messages:
|
||||
|
|
|
|||
|
|
@ -47,7 +47,7 @@ This is how [Split GPG](https://www.qubes-os.org/doc/split-gpg/) is implemented.
|
|||
|
||||
On the `target` qubes, we need to define the RPC service.
|
||||
|
||||
```bash
|
||||
```sh
|
||||
#!/bin/bash
|
||||
|
||||
SIGNER_BIN="/home/user/tools/clef/clef"
|
||||
|
|
@ -73,7 +73,7 @@ It would have been possible to send data directly to the `/home/user/.clef/.clef
|
|||
|
||||
To enable the service:
|
||||
|
||||
```bash
|
||||
```sh
|
||||
sudo cp qubes.Clefsign /etc/qubes-rpc/
|
||||
sudo chmod +x /etc/qubes-rpc/ qubes.Clefsign
|
||||
```
|
||||
|
|
@ -113,7 +113,7 @@ with socketserver.TCPServer(("",PORT), Dispatcher) as httpd:
|
|||
|
||||
To test the flow, with `debian-work` as the `target`:
|
||||
|
||||
```bash
|
||||
```sh
|
||||
$ cat newaccnt.json
|
||||
{ "id": 0, "jsonrpc": "2.0","method": "account_new","params": []}
|
||||
|
||||
|
|
@ -130,13 +130,13 @@ Followed by a GTK-dialog to approve the operation:
|
|||
|
||||
To test the full flow, start the client wrapper on the `client` qube:
|
||||
|
||||
```
|
||||
```sh
|
||||
[user@work qubes]$ python3 qubes-client.py
|
||||
```
|
||||
|
||||
Make the request over http (`client` qube):
|
||||
|
||||
```
|
||||
```sh
|
||||
[user@work clef]$ cat newaccnt.json | curl -X POST -d @- http://localhost:8550
|
||||
```
|
||||
|
||||
|
|
|
|||
|
|
@ -9,9 +9,10 @@ This page provides a step-by-step walkthrough tutorial demonstrating some common
|
|||
|
||||
First things first, Clef needs to store some data itself. Since that data might be sensitive (passwords, signing rules, accounts), Clef's entire storage is encrypted. To support encrypting data, the first step is to initialize Clef with a random master seed, itself too encrypted with a password:
|
||||
|
||||
```text
|
||||
```sh
|
||||
$ clef init
|
||||
|
||||
```
|
||||
```terminal
|
||||
WARNING!
|
||||
|
||||
Clef is an account management tool. It may, like any software, contain bugs.
|
||||
|
|
@ -193,7 +194,6 @@ Additional HTTP header data, provided by the external caller:
|
|||
---------------------------------------------
|
||||
|
||||
Approve? [y/N]
|
||||
|
||||
```
|
||||
|
||||
Approving this transaction causes Clef to prompt the user to provide the password for the sender account. Providing the password enables the transaction to be signed and sent to Geth for broadcasting to the network. The details of the signed transaction are displayed in the console. Account passwords can also be stored in Clef's encrypted vault so that they do not have to be manually entered - [more on this below](#account-passwords).
|
||||
|
|
@ -305,7 +305,7 @@ clef --keystore go-ethereum/goerli-data/ --configdir go-ethereum/goerli-data/cle
|
|||
|
||||
The following logs will be displayed in the terminal:
|
||||
|
||||
```
|
||||
```terminal
|
||||
INFO [07-01|13:39:49.726] Rule engine configured file=rules.js
|
||||
INFO [07-01|13:39:49.726] Starting signer chainid=5 keystore=$go-ethereum/goerli-data/ light-kdf=false advanced=false
|
||||
DEBUG[07-01|13:39:49.726] FS scan times list=35.15µs set=4.251µs diff=2.766µs
|
||||
|
|
@ -488,14 +488,14 @@ This returns a `Request denied` message as follows:
|
|||
|
||||
Meanwhile, in the output logs in the Clef terminal:
|
||||
|
||||
```text
|
||||
```terminal
|
||||
INFO [02-21|14:42:41] Op approved
|
||||
INFO [02-21|14:42:56] Op rejected
|
||||
```
|
||||
|
||||
The signer also stores all traffic over the external API in a log file. The last 4 lines shows the two requests and their responses:
|
||||
|
||||
```text
|
||||
```terminal
|
||||
$ tail -n 4 audit.log
|
||||
t=2022-07-01T15:52:14+0300 lvl=info msg=SignData api=signer type=request metadata="{\"remote\":\"NA\",\"local\":\"NA\",\"scheme\":\"NA\",\"User-Agent\":\"\",\"Origin\":\"\"}" addr="0xd9c9cd5f6779558b6e0ed4e6acf6b1947e7fa1f3 [chksum INVALID]" data=0x202062617a6f6e6b2062617a2067617a0a content-type=data/plain
|
||||
t=2022-07-01T15:52:14+0300 lvl=info msg=SignData api=signer type=response data=0x636c656664656d6f7465787474686174696e636c7564657377656e2d6d65726765 error=nil
|
||||
|
|
|
|||
|
|
@ -164,7 +164,7 @@ The dashboard can then be viewed by navigating to the node's ip address and the
|
|||
|
||||
Start instances of Geth for each node
|
||||
|
||||
```
|
||||
```sh
|
||||
geth --datadir Node1 --port 30301 --bootnodes <enr> --networkid <testnetwork ID> -unlock <node 1 address> --mine
|
||||
```
|
||||
|
||||
|
|
|
|||
Loading…
Reference in New Issue