fix links and typos
This commit is contained in:
parent
d4c57f9174
commit
394f1b07e6
|
@ -12,8 +12,11 @@ If you'd like to contribute to the Geth source code, please fork the [Github rep
|
|||
Please make sure your contributions adhere to our coding guidelines:
|
||||
|
||||
- Code must adhere to the official Go formatting guidelines (i.e. uses gofmt).
|
||||
|
||||
- Code must be documented adhering to the official Go commentary guidelines.
|
||||
|
||||
- Pull requests need to be based on and opened against the master branch.
|
||||
|
||||
- Commit messages should be prefixed with the package(s) they modify.
|
||||
E.g. "eth, rpc: make trace configs optional"
|
||||
|
||||
|
|
|
@ -5,7 +5,7 @@ description: Introduction to account management in Go native applications.
|
|||
|
||||
Geth provides a simple, yet thorough accounts package that includes all the tools developers need to leverage all the security of Geth's crypto implementation in a Go native application. The account management is done client side with all sensitive data held inside the application. This gives the user control over access permissions without relying on any third party.
|
||||
|
||||
**Note Geth's built-in account management is convenient and straightforward to use, but best practise is to use the external tool _Clef_ for key management.**
|
||||
**Note: Geth's built-in account management is convenient and straightforward to use, but best practise is to use the external tool _Clef_ for key management.**
|
||||
|
||||
## Encrypted keystores {#encrypted-keystores}
|
||||
|
||||
|
@ -93,7 +93,7 @@ There are a few different ways to authorize the account manager to execute signi
|
|||
|
||||
Assuming an instance of an [`accounts.Manager`](https://godoc.org/github.com/ethereum/go-ethereum/accounts#Manager) called `am` exists, a new account can be created to sign transactions using [`NewAccount`](https://godoc.org/github.com/ethereum/go-ethereum/accounts#Manager.NewAccount). Creating transactions is out of scope for this page so instead a random [`common.Hash`](https://godoc.org/github.com/ethereum/go-ethereum/common#Hash) will be signed instead.
|
||||
|
||||
For information on creating transactions in Go native applications see the [Go API page](/docs/dapp/native).
|
||||
For information on creating transactions in Go native applications see the [Go API page](/docs/developers/dapp-developer/native).
|
||||
|
||||
```go
|
||||
// Create a new account to sign transactions with
|
||||
|
|
|
@ -193,7 +193,8 @@ View the full file [here](https://gist.github.com/jmcook1186/91124cfcbc7f22dcd3b
|
|||
|
||||
The new `DeployStorage()` function can be used to deploy the contract to an Ethereum testnet from a Go application. To do this requires incorporating the bindings into a Go application that also handles account management, authorization and Ethereum backend to deploy the contract through. Specifically, this requires:
|
||||
|
||||
1. A running Geth node connected to an Ethereum testnet (recommended Goerli)
|
||||
1. A running Geth node connected to an Ethereum testnet
|
||||
|
||||
2. An account in the keystore prefunded with enough ETH to cover gas costs for deploying and interacting with the contract
|
||||
|
||||
Assuming these prerequisites exist, a new `ethclient` can be instantiated with the local Geth node's ipc file, providing access to the testnet from the Go application. The key can be instantiated as a variable in the application by copying the JSON object from the keyfile in the keystore.
|
||||
|
|
|
@ -39,7 +39,7 @@ All the Geth packages can be downloaded using:
|
|||
$ go get -d github.com/ethereum/go-ethereum/...
|
||||
```
|
||||
|
||||
More Go API support for dapp developers can be found on the [Go Contract Bindings](/docs/developers/dapp-developer/native-bindings) and [Go Account Management](/docs/dapp/native-accounts) pages.
|
||||
More Go API support for dapp developers can be found on the [Go Contract Bindings](/docs/developers/dapp-developer/native-bindings) and [Go Account Management](/docs/developers/dapp-developer/native-accounts) pages.
|
||||
|
||||
## Tutorial {#tutorial}
|
||||
|
||||
|
|
|
@ -42,7 +42,7 @@ An example log for a single opcode entry has the following format:
|
|||
|
||||
### Generating basic traces {#generating-basic-traces}
|
||||
|
||||
To generate a raw EVM opcode trace, Geth provides a few [RPC API endpoints](/docs/rpc/ns-debug). The most commonly used is [`debug_traceTransaction`](/docs/rpc/ns-debug#debug_tracetransaction).
|
||||
To generate a raw EVM opcode trace, Geth provides a few [RPC API endpoints](/docs/interacting-with-geth/rpc/ns-debug). The most commonly used is [`debug_traceTransaction`](/docs/interacting-with-geth/rpc/ns-debug#debug_tracetransaction).
|
||||
|
||||
In its simplest form, `traceTransaction` accepts a transaction hash as its only argument. It then traces the transaction, aggregates all the generated
|
||||
data and returns it as a **large** JSON object. A sample invocation from the Geth console would be:
|
||||
|
@ -57,7 +57,7 @@ The same call can also be invoked from outside the node too via HTTP RPC (e.g. u
|
|||
$ curl -H "Content-Type: application/json" -d '{"id": 1, "method": "debug_traceTransaction", "params": ["0xfc9359e49278b7ba99f59edac0e3de49956e46e530a53c15aa71226b7aa92c6f"]}' localhost:8545
|
||||
```
|
||||
|
||||
To follow along with this tutorial, transaction hashes can be found from a local Geth node (e.g. by attaching a [Javascript console](/docs/interface/javascript-console) and running `eth.getBlock('latest')` then passing a transaction hash from the returned block to `debug.traceTransaction()`) or from a block explorer (for [Mainnet](https://etherscan.io/) or a [testnet](https://goerli.etherscan.io/)).
|
||||
To follow along with this tutorial, transaction hashes can be found from a local Geth node (e.g. by attaching a [Javascript console](/docs/interacting-with-geth/javascript-console) and running `eth.getBlock('latest')` then passing a transaction hash from the returned block to `debug.traceTransaction()`) or from a block explorer (for [Mainnet](https://etherscan.io/) or a [testnet](https://goerli.etherscan.io/)).
|
||||
|
||||
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:
|
||||
|
||||
|
@ -98,4 +98,4 @@ To avoid those issues, Geth supports running custom JavaScript tracers _within_
|
|||
|
||||
This page described how to do basic traces in Geth. Basic traces are very low level and can generate lots of data that might not all be useful. Therefore, it is also possible to use a set of built-in tracers or write custom ones in Javascript or Go.
|
||||
|
||||
Read more about [built-in](/docs/evm-tracing/builtin-tracers) and [custom](/docs/evm-tracing/custom-tracer) traces.
|
||||
Read more about [built-in](/docs/developers/evm-tracing/built-in-tracers) and [custom](/docs/developers/evm-tracing/custom-tracer) traces.
|
||||
|
|
|
@ -3,7 +3,7 @@ title: Built-in tracers
|
|||
description: Explanation of the tracers that come bundled in Geth as part of the tracing API.
|
||||
---
|
||||
|
||||
Geth comes bundled with a choice of tracers that can be invoked via the [tracing API](/docs/rpc/ns-debug). Some of these built-in tracers are implemented natively in Go, and others in Javascript. The default tracer is the opcode logger (otherwise known as struct logger) which is the default tracer for all the methods. Other tracers have to be specified by passing their name to the `tracer` parameter in the API call.
|
||||
Geth comes bundled with a choice of tracers that can be invoked via the [tracing API](/docs/interacting-with-geth/rpc/ns-debug). Some of these built-in tracers are implemented natively in Go, and others in Javascript. The default tracer is the opcode logger (otherwise known as struct logger) which is the default tracer for all the methods. Other tracers have to be specified by passing their name to the `tracer` parameter in the API call.
|
||||
|
||||
## Struct/opcode logger {#struct-opcode-logger}
|
||||
|
||||
|
@ -176,7 +176,9 @@ Return:
|
|||
Things to note about the call tracer:
|
||||
|
||||
- Calls to precompiles are also included in the result
|
||||
|
||||
- In case a frame reverts, the field `output` will contain the raw return data
|
||||
|
||||
- In case the top level frame reverts, its `revertReason` field will contain the parsed reason of revert as returned by the Solidity contract
|
||||
|
||||
#### Config
|
||||
|
@ -184,6 +186,7 @@ Things to note about the call tracer:
|
|||
`callTracer` accepts two options:
|
||||
|
||||
- `onlyTopCall: true` instructs the tracer to only process the main (top-level) call and none of the sub-calls. This avoids extra processing for each call frame if only the top-level call info are required.
|
||||
|
||||
- `withLog: true` instructs the tracer to also collect the logs emitted during each call.
|
||||
|
||||
Example invokation with the `onlyTopCall` flag:
|
||||
|
|
|
@ -9,7 +9,7 @@ In addition to the default opcode tracer and the built-in tracers, Geth offers t
|
|||
|
||||
Custom tracers can also be made more performant by writing them in Go. The gain in performance mostly comes from the fact that Geth doesn't need to interpret JS code and can execute native functions. Geth comes with several built-in [native tracers](https://github.com/ethereum/go-ethereum/tree/master/eth/tracers/native) which can serve as examples. Please note that unlike JS tracers, Go tracing scripts cannot be simply passed as an argument to the API. They will need to be added to and compiled with the rest of the Geth source code.
|
||||
|
||||
In this section a simple native tracer that counts the number of opcodes will be covered. First follow the instructions to [clone and build](/content/docs/getting_started/Installing-Geth.md) Geth from source code. Next save the following snippet as a `.go` file and add it to `eth/tracers/native`:
|
||||
In this section a simple native tracer that counts the number of opcodes will be covered. First follow the instructions to [clone and build](/docs/getting-started/installing-geth) Geth from source code. Next save the following snippet as a `.go` file and add it to `eth/tracers/native`:
|
||||
|
||||
```go
|
||||
package native
|
||||
|
@ -113,7 +113,7 @@ To test out this tracer the source is first compiled with `make geth`. Then in t
|
|||
|
||||
Transaction traces include the complete status of the EVM at every point during the transaction execution, which can be a very large amount of data. Often, users are only interested in a small subset of that data. Javascript trace filters are available to isolate the useful information.
|
||||
|
||||
Specifying the `tracer` option in one of the tracing methods (see list in [reference](/docs/rpc/ns-debug)) enables JavaScript-based tracing. In this mode, `tracer` is interpreted as a JavaScript expression that is expected to evaluate to an object which must expose the `result` and `fault` methods. There exist 4 additional methods, namely: `setup`, `step`, `enter`, and `exit`. `enter` and `exit` must be present or omitted together.
|
||||
Specifying the `tracer` option in one of the tracing methods (see list in [reference](/docs/interacting-with-geth/rpc/ns-debug)) enables JavaScript-based tracing. In this mode, `tracer` is interpreted as a JavaScript expression that is expected to evaluate to an object which must expose the `result` and `fault` methods. There exist 4 additional methods, namely: `setup`, `step`, `enter`, and `exit`. `enter` and `exit` must be present or omitted together.
|
||||
|
||||
### Setup
|
||||
|
||||
|
@ -266,11 +266,7 @@ debug.traceTransaction(txhash, {
|
|||
|
||||
## Other traces
|
||||
|
||||
This tutorial has focused on `debug_traceTransaction()` which reports information
|
||||
about individual transactions. There are also RPC endpoints that provide different
|
||||
information, including tracing the EVM execution within a block, between two blocks,
|
||||
for specific `eth_call`s or rejected blocks. The full list of trace functions can
|
||||
be explored in the [reference documentation](/content/docs/interacting_with_geth/RPC/ns-debug.md).
|
||||
This tutorial has focused on `debug_traceTransaction()` which reports information about individual transactions. There are also RPC endpoints that provide different information, including tracing the EVM execution within a block, between two blocks, for specific `eth_call`s or rejected blocks. The full list of trace functions can be explored in the [reference documentation](/docs/interacting-with-geth/rpc/ns-debug).
|
||||
|
||||
## Summary
|
||||
|
||||
|
|
|
@ -28,11 +28,11 @@ This means there are limits on the transactions that can be traced imposed by th
|
|||
|
||||
- A **light synced** node retrieving data **on demand** can in theory trace transactions for which all required historical state is readily available in the network. This is because the data required to generate the trace is requested from an les-serving full node. In practice, data availability **cannot** be reasonably assumed.
|
||||
|
||||
![state pruning options](/public/images/docs/state-pruning.png)
|
||||
![state pruning options](/images/docs/state-pruning.png)
|
||||
|
||||
_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_
|
||||
|
||||
More detailed information about syncing is available on the [sync modes page](/docs/interface/sync-modes).
|
||||
More detailed information about syncing is available on the [sync modes page](/docs/fundamentals/sync-modes).
|
||||
|
||||
When a trace of a specific transaction is executed, the state is prepared by fetching the state of the parent block from the database. If it is not available, Geth will crawl backwards in time to find the next available state but only up to a limit defined in the `reexec` parameter which defaults to 128 blocks. If no state is available within the `reexec` window then the trace fails with `Error: required historical state unavailable` and the `reexec` parameter must be increased. If a valid state _is_ found in the `reexec` window, then Geth sequentially re-executes the transcations in each block between the last available state and the target block. The greater the value of `reexec` the longer the tracing will take because more blocks have to be re-executed to regenerate the target state.
|
||||
|
||||
|
@ -48,20 +48,20 @@ _There are exceptions to the above rules when running batch traces of entire blo
|
|||
|
||||
The simplest type of transaction trace that Geth can generate are raw EVM opcode traces. For every EVM instruction the transaction executes, a structured log entry is emitted, containing all contextual metadata deemed useful. This includes the _program counter_, _opcode name_, _opcode cost_, _remaining gas_, _execution depth_ and any _occurred error_. The structured logs can optionally also contain the content of the _execution stack_, _execution memory_ and _contract storage_.
|
||||
|
||||
Read more about Geth's basic traces on the [basic traces page](/docs/evm-tracing/basic-traces).
|
||||
Read more about Geth's basic traces on the [basic traces page](/docs/developers/evm-tracing/basic-traces).
|
||||
|
||||
### Built-in tracers {#built-in-tracers}
|
||||
|
||||
The tracing API accepts an optional `tracer` parameter that defines how the data returned to the API call should be processed. If this parameter is ommitted the default tracer is used. The default is the struct (or 'opcode') logger. These raw opcode traces are sometimes useful, but the returned data is very low level and can be too extensive and awkward to read for many use-cases. A full opcode trace can easily go into the hundreds of megabytes, making them very resource intensive to get out of the node and process externally. For these reasons, there are a set of non-default built-in tracers that can be named in the API call to return different data from the method. Under the hood, these tracers are Go or Javascript
|
||||
functions that do some specific preprocessing on the trace data before it is returned.
|
||||
|
||||
More information about Geth's built-in tracers is available on the [built-in tracers](/docs/evm-tracing/builtin-tracers) page.
|
||||
More information about Geth's built-in tracers is available on the [built-in tracers](/docs/developers/evm-tracing/builtin-tracers) page.
|
||||
|
||||
### Custom tracers {#custom-tracers}
|
||||
|
||||
In addition to built-in tracers, it is possible to provide custom code that hooks to events in the EVM to process and return data in a consumable format. Custom tracers can be written either in Javascript or Go. JS tracers are good for quick prototyping and experimentation as well as for less intensive applications. Go tracers are performant but require the tracer to be compiled together with the Geth source code. This means developers only have to gather the data they actually need, and do any processing at the source.
|
||||
|
||||
More information about custom tracers is available on the [custom tracers](/docs/evm-tracing/custom-tracer) page.
|
||||
More information about custom tracers is available on the [custom tracers](/docs/developers/evm-tracing/custom-tracer) page.
|
||||
|
||||
## Summary {#summary}
|
||||
|
||||
|
|
|
@ -3,7 +3,7 @@ title: Tutorial for Javascript tracing
|
|||
description: Javascript tracing tutorial
|
||||
---
|
||||
|
||||
Geth supports tracing via [custom Javascript tracers](/docs/evm-tracing/custom-tracer#custom-javascript-tracing). This document provides a tutorial with examples on how to achieve this.
|
||||
Geth supports tracing via [custom Javascript tracers](/docs/developers/evm-tracing/custom-tracer#custom-javascript-tracing). This document provides a tutorial with examples on how to achieve this.
|
||||
|
||||
### A simple filter
|
||||
|
||||
|
@ -25,16 +25,16 @@ tracer = function (tx) {
|
|||
}; // tracer = function ...
|
||||
```
|
||||
|
||||
2. Run the [JavaScript console](https://geth.ethereum.org/docs/interface/javascript-console).
|
||||
3. Get the hash of a recent transaction from a node or block explorer.
|
||||
1. Run the [JavaScript console](/docs/interacting-with-geth/javascript-console).
|
||||
2. Get the hash of a recent transaction from a node or block explorer.
|
||||
|
||||
4. Run this command to run the script:
|
||||
3. Run this command to run the script:
|
||||
|
||||
```js
|
||||
loadScript('filterTrace_1.js');
|
||||
```
|
||||
|
||||
5. Run the tracer from the script. Be patient, it could take a long time.
|
||||
4. Run the tracer from the script. Be patient, it could take a long time.
|
||||
|
||||
```js
|
||||
tracer('<hash of transaction>');
|
||||
|
@ -48,7 +48,7 @@ tracer = function (tx) {
|
|||
"1375:MLOAD", "1376:DUP1", "1377:SWAP2", "1378:SUB", "1379:SWAP1", "1380:RETURN"
|
||||
```
|
||||
|
||||
6. Run this line to get a more readable output with each string in its own line.
|
||||
5. Run this line to get a more readable output with each string in its own line.
|
||||
|
||||
```js
|
||||
console.log(JSON.stringify(tracer('<hash of transaction>'), null, 2));
|
||||
|
@ -56,7 +56,7 @@ tracer = function (tx) {
|
|||
|
||||
More information about the `JSON.stringify` function is available [here](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/JSON/stringify).
|
||||
|
||||
The commands above worked by calling the same `debug.traceTransaction` function that was previously explained in [basic traces](https://geth.ethereum.org/docs/dapp/tracing), but with a new parameter, `tracer`. This parameter takes the JavaScript object formated as a string. In the case of the trace above, it is:
|
||||
The commands above worked by calling the same `debug.traceTransaction` function that was previously explained in [basic traces](/docs/developers/evm-tracing/basic-traces), but with a new parameter, `tracer`. This parameter takes the JavaScript object formated as a string. In the case of the trace above, it is:
|
||||
|
||||
```js
|
||||
{
|
||||
|
|
|
@ -6,17 +6,22 @@ description: Instructions for setting up Geth in developer mode
|
|||
It is often convenient for developers to work in an environment where changes to client or application software can be deployed and tested rapidly and without putting real-world users or assets at risk. For this purpose, Geth has a `--dev` flag that spins up Geth in "developer mode". This creates a single-node Ethereum test network with no connections to any external peers. It exists solely on the local machine. Starting Geth in developer mode does the following:
|
||||
|
||||
- Initializes the data directory with a testing genesis block
|
||||
|
||||
- Sets max peers to 0 (meaning Geth does not search for peers)
|
||||
|
||||
- Turns off discovery by other nodes (meaning the node is invisible to other nodes)
|
||||
|
||||
- Sets the gas price to 0 (no cost to send transactions)
|
||||
|
||||
- Uses the Clique proof-of-authority consensus engine which allows blocks to be mined as-needed without excessive CPU and memory consumption
|
||||
|
||||
- Uses on-demand block generation, producing blocks when transactions are waiting to be mined
|
||||
|
||||
This configuration enables developers to experiment with Geth's source code or develop new applications without having to sync to a pre-existing public network. Blocks are only mined when there are pending transactions. Developers can break things on this network without affecting other users. This page will demonstrate how to spin up a local Geth testnet and a simple smart contract will be deployed to it using the Remix online integrated development environment (IDE).
|
||||
|
||||
## Prerequisites {#prerequisites}
|
||||
|
||||
It is assumed that the user has a working Geth installation (see [installation guide](/docs/install-and-build/installing-geth)).
|
||||
It is assumed that the user has a working Geth installation (see [installation guide](/docs/getting-started/installing-geth)).
|
||||
It would also be helpful to have basic knowledge of Geth and the Geth console. See [Getting Started](/docs/getting-started).
|
||||
Some basic knowledge of [Solidity](https://docs.soliditylang.org/) and [smart contract deployment](https://ethereum.org/en/developers/tutorials/deploying-your-first-smart-contract/) would be useful.
|
||||
|
||||
|
@ -170,7 +175,7 @@ Now that the user account is funded with ether, a contract can be created ready
|
|||
|
||||
This tutorial will make use of a classic example smart contract, `Storage.sol`. This contract exposes two public functions, one to add a value to the contract storage and one to view the stored value. The contract, written in Solidity, is provided below:
|
||||
|
||||
```solidity
|
||||
```javascript
|
||||
pragma solidity >=0.7.0;
|
||||
|
||||
contract Storage{
|
||||
|
|
|
@ -41,9 +41,9 @@ In keeping with this policy, we have taken inspiration from [Solidity bug disclo
|
|||
|
||||
## Disclosed vulnerabilities {#disclosed-vulnerabilities}
|
||||
|
||||
There is a JSON-formatted list ([`vulnerabilities.json`](/vulnerabilities.json)) of some of the known security-relevant vulnerabilities concerning Geth.
|
||||
There is a JSON-formatted list ([`vulnerabilities.json`](/public/docs/vulnerabilities/vulnerabilities.json)) of some of the known security-relevant vulnerabilities concerning Geth.
|
||||
|
||||
As of version `1.9.25`, Geth has a built-in command to check whether it is affected by any publically disclosed vulnerability, using the command `geth version-check`. This command will fetch the latest json file (and the accompanying [signature-file](vulnerabilities.json.minisig), and cross-check the data against it's own version number.
|
||||
As of version `1.9.25`, Geth has a built-in command to check whether it is affected by any publically disclosed vulnerability, using the command `geth version-check`. This command will fetch the latest json file (and the accompanying [signature-file](/public/docs/vulnerabilities/vulnerabilities.json.minisig), and cross-check the data against it's own version number.
|
||||
|
||||
The list of vulnerabilities was started in November 2020, and covers mainly `v1.9.7` and forward.
|
||||
|
||||
|
|
|
@ -7,7 +7,7 @@ This guide explains how to set up a private network of multiple Geth nodes. An E
|
|||
|
||||
## Prerequisites {#prerequisites}
|
||||
|
||||
To follow the tutorial on this page it is necessary to have a working Geth installation (instructions [here](/docs/getting_started/Installing-Geth)). It is also helpful to understand Geth fundamentals (see [Getting Started](/docs/getting_started/getting_started)).
|
||||
To follow the tutorial on this page it is necessary to have a working Geth installation (instructions [here](/docs/getting-started/installing-geth)). It is also helpful to understand Geth fundamentals (see [Getting Started](/docs/getting-started)).
|
||||
|
||||
## Private Networks {#private-networks}
|
||||
|
||||
|
|
|
@ -3,7 +3,7 @@ title: FAQ
|
|||
description: Frequently asked questions related to Geth
|
||||
---
|
||||
|
||||
### Where can I get more information? {#where-can-i-get-more-information}
|
||||
## Where can I get more information? {#where-can-i-get-more-information}
|
||||
|
||||
This page contains answers to common questions about Geth. Source code and README documentation can be found on the Geth [Github](https://github.com/ethereum/go-ethereum). You can also ask questions on Geth's [Discord channel](https://discord.gg/WHNkYDsAKU) or keep up to date with Geth on [Twitter](https://twitter.com/go_ethereum). Information about Ethereum in general can be found at [ethereum.org](https://ethereum.org).
|
||||
|
||||
|
@ -20,7 +20,7 @@ RPC stands for Remote Procedure Call. RPC is a mode of communication between pro
|
|||
|
||||
## What is `jwtsecret`? {#what-is-jwtsecret}
|
||||
|
||||
The `jwtsecret` file is required to create an authenticated connection between Geth and a consensus client. JWT stands for JSON Web Token - it is signed using a secret key. The signed token acts as a shared secret used to check that information is sent to and received from the correct peer. Read about how to create `jwt-secret` in Geth on our [Connecting to consensus clients](/docs/getting_started/consensus-clients) page.
|
||||
The `jwtsecret` file is required to create an authenticated connection between Geth and a consensus client. JWT stands for JSON Web Token - it is signed using a secret key. The signed token acts as a shared secret used to check that information is sent to and received from the correct peer. Read about how to create `jwt-secret` in Geth on our [consensus clients](/docs/getting-started/consensus-clients) page.
|
||||
|
||||
## I noticed my peercount slowly decreasing, and now it is at 0. Restarting doesn't get any peers. {#where-are-my-peers}
|
||||
|
||||
|
@ -32,7 +32,7 @@ sudo ntpdate -s time.nist.gov
|
|||
|
||||
## I would like to run multiple Geth instances but got the error "Fatal: blockchain db err: resource temporarily unavailable". {#multiple-geth-instances}
|
||||
|
||||
Geth uses a datadir to store the blockchain, accounts and some additional information. This directory cannot be shared between running instances. If you would like to run multiple instances follow [these](/docs/developers/geth-developer/Private-Network) instructions.
|
||||
Geth uses a datadir to store the blockchain, accounts and some additional information. This directory cannot be shared between running instances. If you would like to run multiple instances follow [these](/docs/developers/geth-developer/private-network) instructions.
|
||||
|
||||
## When I try to use the --password command line flag, I get the error "Could not decrypt key with given passphrase" but the password is correct. Why does this error appear? {#could-not-decrypt-key}
|
||||
|
||||
|
@ -94,4 +94,4 @@ These docs mainly cover how to set up Geth, but since the switch to proof-of-sta
|
|||
|
||||
## How do I update Geth? {#how-to-update-geth}
|
||||
|
||||
Updating Geth to the latest version simply requires stopping the node, downloading the latest release and restarting the node. Precisely how to download the latest software depends on the installation method - please refer to our [Installation pages](/docs/install-and-build/Installing-Geth).
|
||||
Updating Geth to the latest version simply requires stopping the node, downloading the latest release and restarting the node. Precisely how to download the latest software depends on the installation method - please refer to our [Installation pages](/docs/getting-started/installing-geth).
|
||||
|
|
|
@ -3,7 +3,7 @@ title: Account Management with Clef
|
|||
description: Guide to basic account management using Geth's built-in tools
|
||||
---
|
||||
|
||||
Geth uses an external signer called [Clef](/docs/clef/introduction) to manage accounts. This is a standalone piece of software that runs independently of - but connects to - a Geth instance. Clef handles account creation, key management and signing transactions/data. This page explains how to use Clef to create and manage accounts for use with Geth. More information about Clef, including advanced setup options, are available in our dedicated Clef docs.
|
||||
Geth uses an external signer called [Clef](/docs/tools/clef/introduction) to manage accounts. This is a standalone piece of software that runs independently of - but connects to - a Geth instance. Clef handles account creation, key management and signing transactions/data. This page explains how to use Clef to create and manage accounts for use with Geth. More information about Clef, including advanced setup options, are available in our dedicated Clef docs.
|
||||
|
||||
## Initialize Clef {#initializing-clef}
|
||||
|
||||
|
|
|
@ -45,7 +45,7 @@ Running a light client simply requires Geth to be started in light mode. It is l
|
|||
geth --syncmode light --http --http.api "eth,debug"
|
||||
```
|
||||
|
||||
Data can be requested from this light Geth instance in the same way as for a full node (i.e. using the [JSON-RPC-API](/docs/rpc/server) using tools such as [Curl](https://curl.se/) or Geth's [Javascript console](/docs/interface/javascript-console)). Instead of fetching the data from a local database as in a full node, the light Geth instance requests the data from full-node peers.
|
||||
Data can be requested from this light Geth instance in the same way as for a full node (i.e. using the [JSON-RPC-API](/docs/interacting-with-geth/rpc/) using tools such as [Curl](https://curl.se/) or Geth's [Javascript console](/docs/interacting-with-geth/javascript-console)). Instead of fetching the data from a local database as in a full node, the light Geth instance requests the data from full-node peers.
|
||||
|
||||
It's also possible to send transactions. However, light clients are not connected directly to Ethereum Mainnet but to a network of light servers that connect to Ethereum Mainnet. This means a transaction submitted by a light client is received first by a light server that then propagates it to full-node peers on the light-client's behalf. This reliance on honest light-servers is one of the trust compromises that comes along with running a light node instead of a full node.
|
||||
|
||||
|
|
|
@ -198,7 +198,7 @@ The above is often seen and misinterpreted as a problem with snap sync. In reali
|
|||
WARN [10-03|13:10:26.441] Post-merge network, but no beacon client seen. Please launch one to follow the chain!
|
||||
```
|
||||
|
||||
The above message is emitted when Geth is run without a consensus client on a post-merge proof-of-stake network. Since Ethereum moved to proof-of-stake Geth alone is not enough to follow the chain because the consensus logic is now implemented by a separate piece of software called a consensus client. This log message is displayed when the consensus client is missing. Read more about this on our [consensus clients](/docs/interface/consensus-clients) page.
|
||||
The above message is emitted when Geth is run without a consensus client on a post-merge proof-of-stake network. Since Ethereum moved to proof-of-stake Geth alone is not enough to follow the chain because the consensus logic is now implemented by a separate piece of software called a consensus client. This log message is displayed when the consensus client is missing. Read more about this on our [consensus clients](/docs/getting-started/consensus-clients) page.
|
||||
|
||||
```sh
|
||||
WARN [10-03 |13:10:26.499] Beacon client online, but never received consensus updates. Please ensure your beacon client is operational to follow the chain!
|
||||
|
|
|
@ -27,7 +27,7 @@ The Ethminer software can be installed from a downloaded binary or built from so
|
|||
|
||||
### Using Ethminer with Geth {#using-ethminer}
|
||||
|
||||
An account to receive block rewards must first be defined. The address of the account is all that is required to start mining - the mining rewards will be credited to that address. This can be an existing address or one that is newly created by Geth. More detailed instructions on creating and importing accounts are available on the [Account Management](/docs/interface/managing-your-accounts) page.
|
||||
An account to receive block rewards must first be defined. The address of the account is all that is required to start mining - the mining rewards will be credited to that address. This can be an existing address or one that is newly created by Geth. More detailed instructions on creating and importing accounts are available on the [Account Management](/docs/fundamentals/account-management) page.
|
||||
|
||||
The account address can be provided to `--mining.etherbase` when Geth is started. This instructs Geth to direct any block rewards to this address. Once started, Geth will sync the blockchain. If Geth has not connected to this network before, or if the data directory has been deleted, this can take several days. Also, enable HTTP traffic with the `--http` command.
|
||||
|
||||
|
@ -35,7 +35,7 @@ The account address can be provided to `--mining.etherbase` when Geth is started
|
|||
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:
|
||||
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/interacting-with-geth/javascript-console) page. To attach and open a console:
|
||||
|
||||
```sh
|
||||
geth attach http://127.0.0.1:8545
|
||||
|
@ -103,7 +103,7 @@ When Geth is started it is not mining by default. Unless it is specifically inst
|
|||
geth --mine --miner.threads=4
|
||||
```
|
||||
|
||||
CPU mining can also be started and stopped at runtime using the [console](/docs/interface/javascript-console). The command `miner.start` takes an optional parameter for the number of miner threads.
|
||||
CPU mining can also be started and stopped at runtime using the [console](/docs/interacting-with-geth/javascript-console). The command `miner.start` takes an optional parameter for the number of miner threads.
|
||||
|
||||
```js
|
||||
miner.start(8);
|
||||
|
|
|
@ -17,7 +17,7 @@ For this two-client structure to work, consensus clients must be able to pass bu
|
|||
|
||||
As an execution client, Geth is responsible for creating the execution payloads - the list of transactions, updated state trie plus other execution related data - that consensus clients include in their blocks. Geth is also responsible for re-executing transactions that arrive in new blocks to ensure they are valid. Executing transactions is done on Geth's embedded computer, known as the Ethereum Virtual Machine (EVM).
|
||||
|
||||
Geth also offers a user-interface to Ethereum by exposing a set of [RPC methods](/developers/docs/apis/json-rpc) that enable users to query the Ethereum blockchain, submit transactions and deploy smart contracts. Often, the RPC calls are abstracted by a library such as [Web3js](https://web3js.readthedocs.io/en/v1.8.0/) or [Web3py](https://web3py.readthedocs.io/en/v5/) for example in Geth's built-in Javascript console, development frameworks or web-apps.
|
||||
Geth also offers a user-interface to Ethereum by exposing a set of [RPC methods](/docs/interacting-with-geth/rpc/) that enable users to query the Ethereum blockchain, submit transactions and deploy smart contracts. Often, the RPC calls are abstracted by a library such as [Web3js](https://web3js.readthedocs.io/en/v1.8.0/) or [Web3py](https://web3py.readthedocs.io/en/v5/) for example in Geth's built-in Javascript console, development frameworks or web-apps.
|
||||
|
||||
## What does the consensus client do? {#consensus-client}
|
||||
|
||||
|
|
|
@ -3,12 +3,12 @@ title: Connecting To The Network
|
|||
description: Guide to connecting Geth to a peer-to-peer network
|
||||
---
|
||||
|
||||
The default behaviour for Geth is to connect to Ethereum Mainnet. However, Geth can also connect to public testnets, [private networks](/docs/getting-started/private-net) and [local testnets](/docs/getting-started/dev-mode). For convenience, the two public testnets with long term support, Goerli and Sepolia, have their own command line flag. Geth can connect to these testnets simpyl by passing:
|
||||
The default behaviour for Geth is to connect to Ethereum Mainnet. However, Geth can also connect to public testnets, [private networks](/docs/developers/geth-developer/private-network.md) and [local testnets](/docs/developers/geth-developer/dev-mode). For convenience, the two public testnets with long term support, Goerli and Sepolia, have their own command line flag. Geth can connect to these testnets simpyl by passing:
|
||||
|
||||
- `--goerli`, Goerli proof-of-authority test network
|
||||
- `--sepolia` Sepolia proof-of-work test network
|
||||
|
||||
These testnets started as proof-of-work and proof-of-authority testnets, but they were transitioned to proof-of-stake in 2022 in preparation for doing the same to Ethereum Mainnet. This means that to run a node on Goerli or Sepolia it is now necessary to run a consensus client connected to Geth. This is also true for Ethereum Mainnet. **Geth does not work on proof-of-stake networks without a consensus client**! The remainder of this page will assume that Geth is connected to a consensus client that is synced to the desired network. For instructions on how to set up a consensus client please see the [Consensus Clients](/docs/interface/consensus-clients) page.
|
||||
These testnets started as proof-of-work and proof-of-authority testnets, but they were transitioned to proof-of-stake in 2022 in preparation for doing the same to Ethereum Mainnet. This means that to run a node on Goerli or Sepolia it is now necessary to run a consensus client connected to Geth. This is also true for Ethereum Mainnet. **Geth does not work on proof-of-stake networks without a consensus client**! The remainder of this page will assume that Geth is connected to a consensus client that is synced to the desired network. For instructions on how to set up a consensus client please see the [Consensus Clients](/docs/getting-started/consensus-clients) page.
|
||||
|
||||
**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:
|
||||
|
||||
|
@ -40,13 +40,13 @@ There are occasions when Geth simply fails to connect to peers. The common reaso
|
|||
|
||||
- Some firewall configurations can prohibit UDP traffic. The static nodes feature or `admin.addPeer()` on the console can be used to configure connections manually.
|
||||
|
||||
- Running Geth in [light mode](/docs/interface/les) often leads to connectivity issues because there are few nodes running light servers. There is no easy fix for this except to switch Geth out of light mode. **Note that light mode does not curently work on proof-of-stake networks**.
|
||||
- Running Geth in [light mode](/docs/fundamentals/les) often leads to connectivity issues because there are few nodes running light servers. There is no easy fix for this except to switch Geth out of light mode. **Note that light mode does not curently work on proof-of-stake networks**.
|
||||
|
||||
- The public test network Geth is connecting to might be deprecated or have a low number of active nodes that are hard to find. In this case, the best action is to switch to an alternative test network.
|
||||
|
||||
## Checking Connectivity {#checking-connectivity}
|
||||
|
||||
The `net` module has two attributes that enable checking node connectivity from the [interactive Javascript console](/docs/interface/javascript-console). These are `net.listening` which reports whether the Geth node is listening for inbound requests, and `peerCount` which returns the number of active peers the node is connected to.
|
||||
The `net` module has two attributes that enable checking node connectivity from the [interactive Javascript console](/docs/interacting-with-geth/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.
|
||||
|
||||
```js
|
||||
> net.listening
|
||||
|
@ -106,7 +106,7 @@ The `admin` module also includes functions for gathering information about the l
|
|||
|
||||
## Custom Networks {#custom-networks}
|
||||
|
||||
It is often useful for developers to connect to private test networks rather than public testnets or Etheruem mainnet. These sandbox environments allow block creation without competing against other miners, easy minting of test ether and give freedom to break things without real-world consequences. A private network is started by providing a value to `--networkid` that is not used by any other existing public network ([Chainlist](https://chainlist.org)) and creating a custom `genesis.json` file. Detailed instructions for this are available on the [Private Networks page](/docs/interface/private-network).
|
||||
It is often useful for developers to connect to private test networks rather than public testnets or Etheruem mainnet. These sandbox environments allow block creation without competing against other miners, easy minting of test ether and give freedom to break things without real-world consequences. A private network is started by providing a value to `--networkid` that is not used by any other existing public network ([Chainlist](https://chainlist.org)) and creating a custom `genesis.json` file. Detailed instructions for this are available on the [Private Networks page](/docs/developers/geth-developer/private-network).
|
||||
|
||||
## Static nodes {#static-nodes}
|
||||
|
||||
|
|
|
@ -13,9 +13,13 @@ To prune a Geth node at least 40 GB of free disk space is recommended. This mean
|
|||
## Pruning rules {#pruning-rules}
|
||||
|
||||
1. Do not try to prune an archive node. Archive nodes need to maintain ALL historic data by definition.
|
||||
|
||||
2. Ensure there is at least 40 GB of storage space still available on the disk that will be pruned. Failures have been reported with ~25GB of free space.
|
||||
|
||||
3. Geth is at least `v1.10` ideally > `v1.10.3`
|
||||
|
||||
4. Geth is fully sync'd
|
||||
|
||||
5. Geth has finished creating a snapshot that is at least 128 blocks old. This is true when "state snapshot generation" is no longer reported in the logs.
|
||||
|
||||
With these rules satisfied, Geth's database can be pruned.
|
||||
|
|
|
@ -46,7 +46,7 @@ It is also possible to create a partial/recent archive node where the node was s
|
|||
|
||||
A light node syncs very quickly and stores the bare minimum of blockchain data. Light nodes only process block headers, not entire blocks. This greatly reduces the computation time, storage and bandwidth required relative to a full node. This means light nodes are suitable for resource-constrained devices and can catch up to the head of the chain much faster when they are new or have been offline for a while. The trade-off is that light nodes rely heavily on data served by altruistic full nodes. A light client can be used to query data from Ethereum and submit transactions, acting as a locally-hosted Ethereum wallet. However, because they don't keep local copies of the Ethereum state, light nodes can't validate blocks in the same way as full nodes - they receive a proof from the full node and verify it against their local header chain. To start a node in light mode, pass `--syncmode light`. Be aware that full nodes serving light data are relative scarce so light nodes can struggle to find peers. **Light nodes are not currently working on proof-of-stake Ethereum**.
|
||||
|
||||
Read more about light nodes on our [LES page](/docs/interface/les).
|
||||
Read more about light nodes on our [LES page](/docs/fundamentals/les).
|
||||
|
||||
## Consensus layer syncing {#consensus-layer-syncing}
|
||||
|
||||
|
@ -66,7 +66,7 @@ Read more in the [optimistic sync specs](https://github.com/ethereum/consensus-s
|
|||
|
||||
Alternatively, the consensus client can grab a checkpoint from a trusted source which provides a target state to sync up to, before switching to full sync and verifying each block in turn. In this mode, the node trusts that the checkpoint is correct. There are many possible sources for this checkpoint - the gold standard would be to get it out-of-band from another trusted friend, but it could also come from block explorers or [public APIs/web apps](https://eth-clients.github.io/checkpoint-sync-endpoints/). Checkpoint sync is very fast - a consensus cleint should be able to sync in a few minutes using this method.
|
||||
|
||||
For troubleshooting, please see the `Syncing` section on the [console log messages](/docs/interface/logs) page.
|
||||
For troubleshooting, please see the `Syncing` section on the [console log messages](/docs/fundamentals/logs) page.
|
||||
|
||||
## Summary {#summary}
|
||||
|
||||
|
|
|
@ -9,7 +9,7 @@ There are five consensus clients available, all of which connect to Geth in the
|
|||
|
||||
## Configuring Geth {#configuring-geth}
|
||||
|
||||
Geth can be downloaded and installed according to the instructions on the [Installing Geth](/docs/install-and-build/installing-geth) page. In order to connect to a consensus client, Geth must expose a port for the inter-client RPC connection.
|
||||
Geth can be downloaded and installed according to the instructions on the [Installing Geth](/docs/getting-started/installing-geth) page. In order to connect to a consensus client, Geth must expose a port for the inter-client RPC connection.
|
||||
|
||||
The RPC connection must be authenticated using a `jwtsecret` file. This is created and saved to `<datadir>/geth/jwtsecret` by default but can also be created and saved to a custom location or it can be self-generated and provided to Geth by passing the file path to `--authrpc.jwtsecret`. The `jwtsecret` file is required by both Geth and the consensus client.
|
||||
|
||||
|
@ -55,7 +55,7 @@ Please see the pages on [syncing](/docs/fundamentals/sync-modes) for more detail
|
|||
|
||||
## Using Geth {#using-geth}
|
||||
|
||||
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
|
||||
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/interacting-with-geth/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`):
|
||||
|
||||
```sh
|
||||
|
|
|
@ -3,7 +3,7 @@ title: JavaScript Console
|
|||
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.
|
||||
Geth responds to instructions encoded as JSON objects as defined in the [JSON-RPC-API](/docs/interacting-with-geth/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
|
||||
|
@ -18,7 +18,7 @@ This returns a result which is also a JSON object, with values expressed as hexa
|
|||
This is a low level and rather error-prone way to interact with Geth. Most developers prefer to use convenience libraries that abstract away some of the more tedious and awkward tasks such as converting values from hexadecimal strings into numbers, or converting between denominations of ether (Wei, Gwei, etc). One such library is [Web3.js](https://web3js.readthedocs.io/en/v1.7.3/).
|
||||
The purpose of Geth's Javascript console is to provide a built-in environment to use a subset of the Web3.js libraries to interact with a Geth node.
|
||||
|
||||
{% include note.html content="The web3.js version that comes bundled with Geth is not up to date with the official Web3.js documentation. There are several Web3.js libraries that are not available in the Geth Javascript Console. There are also administrative APIs included in the Geth console that are not documented in the Web3.js documentation. The full list of libraries available in the Geth console is available on the [JSON-RPC API page](/docs/rpc/server)." %}
|
||||
{% include note.html content="The web3.js version that comes bundled with Geth is not up to date with the official Web3.js documentation. There are several Web3.js libraries that are not available in the Geth Javascript Console. There are also administrative APIs included in the Geth console that are not documented in the Web3.js documentation. The full list of libraries available in the Geth console is available on the [JSON-RPC API page](/docs/interacting-with-geth/rpc/server)." %}
|
||||
|
||||
## Starting the console {#starting-the-console}
|
||||
|
||||
|
@ -77,9 +77,7 @@ To exit, press ctrl-d or type exit
|
|||
|
||||
## Interactive use {#interactive-use}
|
||||
|
||||
Once the console has been started, it can be used to interact with Geth. The console supports Javascript and the full Geth [JSON-RPC API](/docs/rpc/server). For example:
|
||||
|
||||
To check the balance of the first account already existing in the keystore:
|
||||
Once the console has been started, it can be used to interact with Geth. The console supports Javascript and the full Geth [JSON-RPC API](/docs/interacting-with-geth/rpc/server). For example, to check the balance of the first account already existing in the keystore:
|
||||
|
||||
```js
|
||||
eth.getBalance(eth.accounts[0]);
|
||||
|
@ -95,9 +93,7 @@ eth.sendTransaction({
|
|||
});
|
||||
```
|
||||
|
||||
It is also possible to load pre-written Javascript files into the console by passing the `--preload` flag
|
||||
when starting the console. This is useful for setting up complex contract objects or loading frequently-used
|
||||
functions.
|
||||
It is also possible to load pre-written Javascript files into the console by passing the `--preload` flag when starting the console. This is useful for setting up complex contract objects or loading frequently-used functions.
|
||||
|
||||
```sh
|
||||
geth console --preload "/my/scripts/folder/utils.js"
|
||||
|
@ -109,8 +105,7 @@ Remember that interactions that touch accounts need approval in Clef - either ma
|
|||
|
||||
## Non-interactive Use: Script Mode {#non-interactive-use}
|
||||
|
||||
It is also possible to execute JavaScript code non-interactively by passing the `--exec` and a JSON-RPC-API endpoint
|
||||
to `geth attach` or `geth console`. The result is displayed directly in the terminal rather than in an interactive Javascript console.
|
||||
It is also possible to execute JavaScript code non-interactively by passing the `--exec` and a JSON-RPC-API endpoint to `geth attach` or `geth console`. The result is displayed directly in the terminal rather than in an interactive Javascript console.
|
||||
|
||||
For example, to display the accounts in the keystore:
|
||||
|
||||
|
@ -130,8 +125,7 @@ geth attach http://geth.example.org:8545 --exec 'loadScript("/tmp/checkbalances.
|
|||
geth attach http://geth.example.org:8545 --jspath "/tmp" --exec 'loadScript("checkbalances.js")'
|
||||
```
|
||||
|
||||
The `--jspath` flag is used to set a library directory for the Javascript scripts. Any parameters passed to `loadScript()`
|
||||
that do not explicitly define an absolute path will be interpreted relative to the `jspath` directory.
|
||||
The `--jspath` flag is used to set a library directory for the Javascript scripts. Any parameters passed to `loadScript()` that do not explicitly define an absolute path will be interpreted relative to the `jspath` directory.
|
||||
|
||||
## Timers {#timers}
|
||||
|
||||
|
|
|
@ -41,4 +41,4 @@ In this case there's no dependency between the requests. Often the retrieved dat
|
|||
- First to download the list of transaction hashes for all of the blocks in our desired range
|
||||
- And then to download the list of receipts objects for all of the transaction hashes
|
||||
|
||||
For use-cases which depend on several JSON-RPC endpoints the batching approach can get easily complicated. In that case Geth offers a [GraphQL API](./graphql) which is more suitable.
|
||||
For use-cases which depend on several JSON-RPC endpoints the batching approach can get easily complicated. In that case Geth offers a [GraphQL API](/docs/interacting-with-geth/rpc/graphql) which is more suitable.
|
||||
|
|
|
@ -60,7 +60,7 @@ The `--http.corsdomain` command also acceptsd wildcards that enable access to th
|
|||
|
||||
Websocket is a bidirectional transport protocol. A Websocket connection is maintained by client and server until it is explicitly terminated by one. Most modern browsers support Websocket which means it has good tooling.
|
||||
|
||||
Because Websocket is bidirectional, servers can push events to clients. That makes Websocket a good choice for use-cases involving [event subscription](/docs/rpc/pubsub). Another benefit of Websocket is that after the handshake procedure, the overhead of individual messages is low,
|
||||
Because Websocket is bidirectional, servers can push events to clients. That makes Websocket a good choice for use-cases involving [event subscription](/docs/interacting-with-geth/rpc/pubsub). Another benefit of Websocket is that after the handshake procedure, the overhead of individual messages is low,
|
||||
making it good for sending high number of requests.
|
||||
|
||||
Configuration of the WebSocket endpoint in Geth follows the same pattern as the HTTP transport. WebSocket access can be enabled using the `--ws` flag. If no additional information is provided, Geth falls back to its default behaviour which is to establish the Websocket on port 8546. The `--ws.addr`, `--ws.port` and `--ws.api` flags can be used to customize settings for the WebSocket server. For example, to start Geth with a Websocket connection for RPC using
|
||||
|
@ -116,7 +116,7 @@ to subscribe to events. HTTP is a familiar and idempotent transport that closes
|
|||
|
||||
## Engine-API {#engine-api}
|
||||
|
||||
The Engine-API is a set of RPC methods that enable communication between Geth and the [consensus client](/docs/getting_started/consensus-clients). These are not designed to be exposed to the user - instead they are called automatically by the clients when they need to exchange information. The Engine API is enabled by default - the user is not required to pass any instruction to Geth to enable these methods.
|
||||
The Engine-API is a set of RPC methods that enable communication between Geth and the [consensus client](/docs/getting-started/consensus-clients). These are not designed to be exposed to the user - instead they are called automatically by the clients when they need to exchange information. The Engine API is enabled by default - the user is not required to pass any instruction to Geth to enable these methods.
|
||||
|
||||
Read more in the [Engine API spec](https://github.com/ethereum/execution-apis/blob/main/src/engine/specification.md).
|
||||
|
||||
|
|
|
@ -105,7 +105,7 @@ The `nodeInfo` administrative property can be queried for all the information kn
|
|||
|
||||
## admin_peerEvents {#admin-peerevents}
|
||||
|
||||
PeerEvents creates an [RPC subscription](/docs/rpc/pubsub) which receives peer events from the node's p2p server. The type of events emitted by the server are as follows:
|
||||
PeerEvents creates an [RPC subscription](/docs/interacting-with-geth/rpc/pubsub) which receives peer events from the node's p2p server. The type of events emitted by the server are as follows:
|
||||
|
||||
- `add`: emitted when a peer is added
|
||||
- `drop`: emitted when a peer is dropped
|
||||
|
@ -179,7 +179,7 @@ Removes a remote node from the trusted peer set, but it does not disconnect it a
|
|||
|
||||
## admin_startHTTP {#admin-starthttp}
|
||||
|
||||
The `startHTTP` administrative method starts an HTTP based JSON-RPC [API](/docs/rpc/server) webserver to handle client requests. All the parameters are optional:
|
||||
The `startHTTP` administrative method starts an HTTP based JSON-RPC [API](/docs/interacting-with-geth/rpc/server) webserver to handle client requests. All the parameters are optional:
|
||||
|
||||
- `host`: network interface to open the listener socket on (defaults to `"localhost"`)
|
||||
- `port`: network port to open the listener socket on (defaults to `8545`)
|
||||
|
|
|
@ -199,7 +199,7 @@ Retrieves and returns the RLP encoded block by number.
|
|||
| Console | `debug.getBlockRlp(number, [options])` |
|
||||
| RPC | `{"method": "debug_getBlockRlp", "params": [number]}` |
|
||||
|
||||
References: [RLP](https://github.com/ethereum/wiki/wiki/RLP)
|
||||
References: [RLP](https://ethereum.org/en/developers/docs/data-structures-and-encoding/rlp/)
|
||||
|
||||
### debug_getHeaderRlp
|
||||
|
||||
|
@ -334,7 +334,7 @@ Sets the current head of the local chain by block number. **Note**, this is a de
|
|||
| RPC | `{"method": "debug_setHead", "params": [number]}` |
|
||||
|
||||
References:
|
||||
[Ethash](https://eth.wiki/en/concepts/ethash/ethash)
|
||||
[Ethash](https://ethereum.org/en/developers/docs/consensus-mechanisms/pow/mining-algorithms/ethash/)
|
||||
|
||||
### debug_setMutexProfileFraction
|
||||
|
||||
|
@ -475,7 +475,7 @@ The `traceBlock` method will return a full stack trace of all invoked opcodes of
|
|||
| RPC | `{"method": "debug_traceBlock", "params": [blockRlp, {}]}` |
|
||||
|
||||
References:
|
||||
[RLP](https://github.com/ethereum/wiki/wiki/RLP)
|
||||
[RLP](https://ethereum.org/en/developers/docs/data-structures-and-encoding/rlp/)
|
||||
|
||||
#### Example
|
||||
|
||||
|
@ -524,7 +524,7 @@ Similar to [debug_traceBlock](#debug_traceblock), `traceBlockByNumber` accepts a
|
|||
| RPC | `{"method": "debug_traceBlockByNumber", "params": [number, {}]}` |
|
||||
|
||||
References:
|
||||
[RLP](https://github.com/ethereum/wiki/wiki/RLP)
|
||||
[RLP](https://ethereum.org/en/developers/docs/data-structures-and-encoding/rlp/)
|
||||
|
||||
### debug_traceBlockByHash
|
||||
|
||||
|
@ -537,7 +537,7 @@ Similar to [debug_traceBlock](#debug_traceblock), `traceBlockByHash` accepts a b
|
|||
| RPC | `{"method": "debug_traceBlockByHash", "params": [hash {}]}` |
|
||||
|
||||
References:
|
||||
[RLP](https://github.com/ethereum/wiki/wiki/RLP)
|
||||
[RLP](https://ethereum.org/en/developers/docs/data-structures-and-encoding/rlp/)
|
||||
|
||||
### debug_traceBlockFromFile
|
||||
|
||||
|
@ -550,11 +550,11 @@ Similar to [debug_traceBlock](#debug_traceblock), `traceBlockFromFile` accepts a
|
|||
| RPC | `{"method": "debug_traceBlockFromFile", "params": [fileName, {}]}` |
|
||||
|
||||
References:
|
||||
[RLP](https://github.com/ethereum/wiki/wiki/RLP)
|
||||
[RLP](https://ethereum.org/en/developers/docs/data-structures-and-encoding/rlp/)
|
||||
|
||||
### debug_traceCall
|
||||
|
||||
The `debug_traceCall` method lets you run an `eth_call` within the context of the given block execution using the final state of parent block as the base. The first argument (just as in `eth_call`) is a [transaction object](/docs/rpc/objects#transaction-call-object). The block can be specified either by hash or by number as the second argument. The trace can be configured similar to `debug_traceTransaction`, see [TraceConfig](#traceconfig). The method returns the same output as `debug_traceTransaction`.
|
||||
The `debug_traceCall` method lets you run an `eth_call` within the context of the given block execution using the final state of parent block as the base. The first argument (just as in `eth_call`) is a [transaction object](/docs/interacting-with-geth/rpc/objects#transaction-call-object). The block can be specified either by hash or by number as the second argument. The trace can be configured similar to `debug_traceTransaction`, see [TraceConfig](#traceconfig). The method returns the same output as `debug_traceTransaction`.
|
||||
|
||||
| Client | Method invocation |
|
||||
| :-----: | --------------------------------------------------------------------------------------------------------------------------- |
|
||||
|
@ -638,7 +638,7 @@ Returns the structured logs created during the execution of EVM between two bloc
|
|||
const res = provider.send('debug_subscribe', ['traceChain', '0x3f3a2a', '0x3f3a2b'])`
|
||||
```
|
||||
|
||||
please refer to the [subscription page](https://geth.ethereum.org/docs/rpc/pubsub) for more details.
|
||||
please refer to the [subscription page](/docs/interacting-with-geth/rpc/pubsub) for more details.
|
||||
|
||||
### debug_traceTransaction
|
||||
|
||||
|
@ -667,9 +667,9 @@ If set, the previous four arguments will be ignored.
|
|||
|
||||
- `timeout`: `STRING`. Overrides the default timeout of 5 seconds for JavaScript-based tracing calls.
|
||||
Valid values are described [here](https://golang.org/pkg/time/#ParseDuration).
|
||||
- `tracerConfig`: Config for the specified `tracer`. For example see callTracer's [config](/docs/evm-tracing/builtin-tracers#config).
|
||||
- `tracerConfig`: Config for the specified `tracer`. For example see callTracer's [config](/docs/developers/evm-tracing/built-in-tracers#config).
|
||||
|
||||
Geth comes with a bundle of [built-in tracers](/docs/evm-tracing/builtin-tracers), each providing various data about a transaction. This method defaults to the [struct logger](/docs/evm-tracing/builtin-tracers#structopcode-logger). The `tracer` field of the second parameter can be set to use any of the other tracers. Alternatively a [custom tracer](/docs/evm-tracing/custom-tracer) can be implemented in either Go or Javascript.
|
||||
Geth comes with a bundle of [built-in tracers](/docs/developers/evm-tracing//built-in-tracers), each providing various data about a transaction. This method defaults to the [struct logger](/docs/developers/evm-tracing/built-in-tracers#structopcode-logger). The `tracer` field of the second parameter can be set to use any of the other tracers. Alternatively a [custom tracer](/docs/developers/evm-tracing/custom-tracer) can be implemented in either Go or Javascript.
|
||||
|
||||
#### Example
|
||||
|
||||
|
|
|
@ -7,7 +7,7 @@ Documentation for the API methods in the `eth` namespace can be found on [ethere
|
|||
|
||||
### eth_subscribe, eth_unsubscribe {#eth-subscribe-unsubscribe}
|
||||
|
||||
These methods are used for real-time events through subscriptions. See the [subscription documentation](/docs/interacting_with_geth/RPC/pubsub) for more information.
|
||||
These methods are used for real-time events through subscriptions. See the [subscription documentation](/docs/interacting-with-geth/rpc/pubsub) for more information.
|
||||
|
||||
### eth_call {#eth-call}
|
||||
|
||||
|
@ -19,7 +19,7 @@ The method takes 3 parameters: an unsigned transaction object to execute in read
|
|||
|
||||
##### 1. `Object` - Transaction call object
|
||||
|
||||
The _transaction call object_ is mandatory. Please see [here](/docs/interacting_with_geth/RPC/objects) for details.
|
||||
The _transaction call object_ is mandatory. Please see [here](/docs/interacting-with-geth/rpc/objects) for details.
|
||||
|
||||
##### 2. `Quantity | Tag` - Block number or the string `latest` or `pending`
|
||||
|
||||
|
@ -40,7 +40,9 @@ The _state override set_ is an optional address-to-state mapping, where each ent
|
|||
The goal of the _state override set_ is manyfold:
|
||||
|
||||
- It can be used by DApps to reduce the amount of contract code needed to be deployed on chain. Code that simply returns internal state or does pre-defined validations can be kept off chain and fed to the node on-demand.
|
||||
|
||||
- It can be used for smart contract analysis by extending the code deployed on chain with custom methods and invoking them. This avoids having to download and reconstruct the entire state in a sandbox to run custom code against.
|
||||
|
||||
- It can be used to debug smart contracts in an already deployed large suite of contracts by selectively overriding some code or state and seeing how execution changes. Specialized tooling will probably be necessary.
|
||||
|
||||
Example:
|
||||
|
@ -138,7 +140,7 @@ Just for the sake of completeness, decoded the response is: `2`.
|
|||
|
||||
### eth_createAccessList {#eth-createaccesslist}
|
||||
|
||||
This method creates an [EIP2930](https://eips.ethereum.org/EIPS/eip-2930) type `accessList` based on a given `Transaction`. The `accessList` contains all storage slots and addresses read and written by the transaction, except for the sender account and the precompiles. This method uses the same `transaction` call [object](/docs/rpc/objects#transaction-call-object) and `blockNumberOrTag` object as `eth_call`. An `accessList` can be used to unstuck contracts that became inaccessible due to gas cost increases.
|
||||
This method creates an [EIP2930](https://eips.ethereum.org/EIPS/eip-2930) type `accessList` based on a given `Transaction`. The `accessList` contains all storage slots and addresses read and written by the transaction, except for the sender account and the precompiles. This method uses the same `transaction` call [object](/docs/interacting-with-geth/rpc/objects#transaction-call-object) and `blockNumberOrTag` object as `eth_call`. An `accessList` can be used to unstuck contracts that became inaccessible due to gas cost increases.
|
||||
|
||||
#### Parameters
|
||||
|
||||
|
|
|
@ -5,7 +5,7 @@ description: Documentation for the JSON-RPC API "personal" namespace
|
|||
|
||||
{% include note.html content="The personal namespace will be deprecated in the very near future." %}
|
||||
|
||||
The personal API managed private keys in the key store. It is deprecated in favour of using [Clef](/docs/tools/clef/Introduction.md) for interacting with accounts Please refer to the [ns_personal deprecation page](/docs/interacting-with-geth/rpc/ns_personal_deprecation.md) to see the equivalent methods. The following documentation should be treated as archive information and users should migrate tousing Clef for account interactions.
|
||||
The personal API managed private keys in the key store. It is deprecated in favour of using [Clef](/docs/tools/clef/Introduction) for interacting with accounts Please refer to the [ns_personal deprecation page](/docs/interacting-with-geth/rpc/ns_personal_deprecation) to see the equivalent methods. The following documentation should be treated as archive information and users should migrate tousing Clef for account interactions.
|
||||
|
||||
## personal_deriveAccount {#personal-deriveaccount}
|
||||
|
||||
|
@ -172,7 +172,7 @@ Deletes a pairing between wallet and Geth.
|
|||
|
||||
Validate the given passphrase and submit transaction.
|
||||
|
||||
The transaction is the same argument as for `eth_sendTransaction` (i.e. [transaction object](/docs/rpc/objects#transaction-call-object)) and contains the `from` address. If the passphrase can be used to decrypt the private key belogging to `tx.from` the transaction is verified, signed and send onto the network. The account is not unlocked globally in the node and cannot be used in other RPC calls.
|
||||
The transaction is the same argument as for `eth_sendTransaction` (i.e. [transaction object](/docs/interacting-with-geth/rpc/objects#transaction-call-object)) and contains the `from` address. If the passphrase can be used to decrypt the private key belogging to `tx.from` the transaction is verified, signed and send onto the network. The account is not unlocked globally in the node and cannot be used in other RPC calls.
|
||||
|
||||
| Client | Method invocation |
|
||||
| :------ | ---------------------------------------------------------------- |
|
||||
|
@ -211,7 +211,7 @@ See ecRecover to verify the signature.
|
|||
|
||||
## personal_signTransaction {#personal-signtransaction}
|
||||
|
||||
SignTransaction will create a transaction from the given arguments and tries to sign it with the key associated with `tx.from`. If the given passwd isn't able to decrypt the key it fails. The transaction is returned in RLP-form, not broadcast to other nodes. The first argument is a [transaction object](/docs/interacting_with_geth/RPC/objects) and the second argument is the password, similar to `personal_sendTransaction`.
|
||||
SignTransaction will create a transaction from the given arguments and tries to sign it with the key associated with `tx.from`. If the given passwd isn't able to decrypt the key it fails. The transaction is returned in RLP-form, not broadcast to other nodes. The first argument is a [transaction object](/docs/interacting-with-geth/rpc/objects) and the second argument is the password, similar to `personal_sendTransaction`.
|
||||
|
||||
| Client | Method invocation |
|
||||
| :------ | ---------------------------------------------------------------- |
|
||||
|
|
|
@ -3,7 +3,7 @@ title: Personal namespace deprecation notes
|
|||
description: Alternatives to the methods in the deprecated personal namespace
|
||||
---
|
||||
|
||||
The JSON-RPC API's `personal` namespace has historically been used to manage accounts and sign transactions and data over RPC. However, it is being deprecated in favour of using [Clef](/docs/tools/clef/Introduction.md) as an external signer and account manager. One of the major changes is moving away from indiscriminate locking and unlocking of accounts and instead using Clef to explicitly approve or deny specific actions. This page shows the suggested replacement for each method in `personal`.
|
||||
The JSON-RPC API's `personal` namespace has historically been used to manage accounts and sign transactions and data over RPC. However, it is being deprecated in favour of using [Clef](/docs/tools/clef/Introduction) as an external signer and account manager. One of the major changes is moving away from indiscriminate locking and unlocking of accounts and instead using Clef to explicitly approve or deny specific actions. This page shows the suggested replacement for each method in `personal`.
|
||||
|
||||
## Methods without replacements
|
||||
|
||||
|
|
|
@ -34,8 +34,11 @@ to cancel the subscription:
|
|||
## Considerations {#considerations}
|
||||
|
||||
1. Notifications are sent for current events and not for past events. For use cases that depend on not to miss any notifications subscriptions are probably not the best option.
|
||||
|
||||
2. Subscriptions require a full duplex connection. Geth offers such connections in the form of WebSocket and IPC (enabled by default).
|
||||
|
||||
3. Subscriptions are coupled to a connection. If the connection is closed all subscriptions that are created over this connection are removed.
|
||||
|
||||
4. Notifications are stored in an internal buffer and sent from this buffer to the client. If the client is unable to keep up and the number of buffered notifications reaches a limit (currently 10k) the connection is closed. Keep in mind that subscribing to some events can cause a flood of notifications, e.g. listening for all logs/blocks when the node starts to synchronize.
|
||||
|
||||
## Create subscription {#create-subscriptions}
|
||||
|
|
|
@ -10,6 +10,7 @@ There are several ways to monitor the performance of a Geth node. Insights into
|
|||
To follow along with the instructions on this page it will be useful to have:
|
||||
|
||||
- a running Geth instance.
|
||||
|
||||
- basic working knowlegde of bash/terminal.
|
||||
|
||||
[This video](https://www.youtube.com/watch?v=cOBab8IJMYI) provides an excellent introduction to Geth monitoring.
|
||||
|
@ -130,7 +131,7 @@ Grafana is now set up to read data from InfluxDB. Now a dashboard can be created
|
|||
|
||||
For a Geth monitoring dashboard, copy the URL of [this dashboard](https://grafana.com/grafana/dashboards/13877/) and paste it in the "Import page" in Grafana. After saving the dashboard, it should look like this:
|
||||
|
||||
![Grafana 1](/public/images/docs/grafana.png)
|
||||
![Grafana 1](/images/docs/grafana.png)
|
||||
|
||||
## Customization {#customization}
|
||||
|
||||
|
|
|
@ -29,7 +29,9 @@ Ethstats has three components:
|
|||
|
||||
- a server that consumes data sent to it by each individual node on a network and serves
|
||||
statistics generated from that data.
|
||||
|
||||
- a client that queries a node and sends its data to the server
|
||||
|
||||
- a dashboard that displays the statistics generated by the server
|
||||
|
||||
The summary dashboard for Ethereum Mainnet can be viewed at [ethstats.net](https://ethstats.net/).
|
||||
|
@ -48,8 +50,11 @@ each with detailed installation instructions. They all share the common trait th
|
|||
started with a specific URL that can be passed to Geth.
|
||||
|
||||
[EthNetStats "Classic"](https://github.com/ethereum/eth-netstats)
|
||||
|
||||
[EthNet Intelligence API](https://github.com/ethereum/eth-net-intelligence-api)
|
||||
|
||||
[Goerli Ethstats client](https://github.com/goerli/ethstats-client)
|
||||
|
||||
[Goerli Ethstats server](https://github.com/goerli/ethstats-server)
|
||||
|
||||
If enabled, Geth spins up a minimal Ethstats reporting daemon that pushes statistics about the
|
||||
|
|
|
@ -1,5 +1,5 @@
|
|||
---
|
||||
title: resources
|
||||
title: Resources
|
||||
description: Read, watch and listen more about Geth and Ethereum
|
||||
---
|
||||
|
||||
|
|
|
@ -25,7 +25,7 @@ The ruleset engine acts as a gatekeeper to the command line interface - it auto-
|
|||
|
||||
![Clef ruleset logic](/images/docs/clef_ruleset.png)
|
||||
|
||||
When Clef receives a request, the ruleset engine evaluates a Javascript file for each method defined in the internal [UI API docs](/docs/tools/Clef/apis). For example the code snippet below is an example ruleset that calls the function `ApproveTx`. The call to `ApproveTx` is invoking the `ui_approveTx` [JSON_RPC API endpoint](/docs/tools/Clef/apis). Every time an RPC method is invoked the Javascript code is executed in a freshly instantiated virtual machine.
|
||||
When Clef receives a request, the ruleset engine evaluates a Javascript file for each method defined in the internal [UI API docs](/docs/tools/clef/apis). For example the code snippet below is an example ruleset that calls the function `ApproveTx`. The call to `ApproveTx` is invoking the `ui_approveTx` [JSON_RPC API endpoint](/docs/tools/clef/apis). Every time an RPC method is invoked the Javascript code is executed in a freshly instantiated virtual machine.
|
||||
|
||||
```js
|
||||
function asBig(str) {
|
||||
|
|
|
@ -49,7 +49,7 @@ _For readability purposes, we'll remove the WARNING printout, user confirmation
|
|||
|
||||
## Remote interactions {#remote-interactions}
|
||||
|
||||
This tutorial will use Clef with Geth on the Goerli testnet. The accounts used will be in the Goerli keystore with the path `~/go-ethereum/goerli-data/keystore`. The tutorial assumes there are two accounts in this keystore. Instructions for creating accounts can be found on the [Account managament page](/docs/interface/managing-your-accounts). Note that Clef can also interact with hardware wallets, although that is not demonstrated here.
|
||||
This tutorial will use Clef with Geth on the Goerli testnet. The accounts used will be in the Goerli keystore with the path `~/go-ethereum/goerli-data/keystore`. The tutorial assumes there are two accounts in this keystore. Instructions for creating accounts can be found on the [Account managament page](/docs/fundamentals/account-management). Note that Clef can also interact with hardware wallets, although that is not demonstrated here.
|
||||
|
||||
Clef should be started before Geth, otherwise Geth will complain that it cannot find a Clef instance to connect to. Clef should be started with the correct `chainid` for Goerli. Clef itself does not connect to a blockchain, but the `chainID` parameter is included in the data that is aggregated to form a signature. Clef also needs a path to the correct keystore passed to the `--keystore` command. A custom path to the config directory can also be provided. This is where the `ipc` file will be saved which is needed to connect Clef to Geth:
|
||||
|
||||
|
@ -77,7 +77,7 @@ INFO [07-01|11:00:46.392] IPC endpoint opened url=go-ethere
|
|||
|
||||
Clef starts up in CLI (Command Line Interface) mode by default. Arbitrary remote processes may _request_ account interactions (e.g. sign a transaction), which the user can individually _confirm_ or _deny_.
|
||||
|
||||
The code snippet below shows a request made to Clef via its _External API endpoint_ using [NetCat](http://netcat.sourceforge.net/). The request invokes the ["account_list"](/docs/tools/Clef/apis#accountlist) endpoint which lists the accounts in the keystore. This command should be run in a new terminal.
|
||||
The code snippet below shows a request made to Clef via its _External API endpoint_ using [NetCat](http://netcat.sourceforge.net/). The request invokes the ["account_list"](/docs/tools/clef/apis#accountlist) endpoint which lists the accounts in the keystore. This command should be run in a new terminal.
|
||||
|
||||
```sh
|
||||
echo '{"id": 1, "jsonrpc": "2.0", "method": "account_list"}' | nc -U ~/.clef/clef.ipc
|
||||
|
@ -134,7 +134,7 @@ geth attach goerli-data/geth.ipc
|
|||
A simple request to list the accounts in the keystore will cause the Javascript console to hang.
|
||||
|
||||
```js
|
||||
eth.accounts;
|
||||
eth.accounts
|
||||
```
|
||||
|
||||
Switching to the Clef terminal reveals that this is because the request is awaiting explicit confirmation from the user. The log is identical to the one shown above, when the same request for account information was made to Clef via Netcat:
|
||||
|
@ -208,7 +208,7 @@ For example, well defined rules such as:
|
|||
|
||||
### Rule files {#rule-files}
|
||||
|
||||
Rules are implemented as Javascript code in `js` files. The ruleset engine includes the same methods as the JSON_RPC defined in the [UI Protocol](/docs/_clef/datatypes). The following code snippet demonstrates a rule file that approves a transaction if it satisfies the following conditions:
|
||||
Rules are implemented as Javascript code in `js` files. The ruleset engine includes the same methods as the JSON_RPC defined in the [UI Protocol](/docs/tools/clef/datatypes). The following code snippet demonstrates a rule file that approves a transaction if it satisfies the following conditions:
|
||||
|
||||
- the recipient is `0xae967917c465db8578ca9024c205720b1a3651a9`
|
||||
- the value is less than 50000000000000000 wei (0.05 ETH)
|
||||
|
@ -503,7 +503,7 @@ t=2022-07-01T15:52:23+0300 lvl=info msg=SignData api=signer type=request meta
|
|||
t=2022-07-01T15:52:23+0300 lvl=info msg=SignData api=signer type=response data= error="Request denied"
|
||||
```
|
||||
|
||||
More examples, including a ruleset for a rate-limited window, are available on the [Clef Github](https://github.com/ethereum/go-ethereum/blob/master/cmd/clef/rules.md#example-1-ruleset-for-a-rate-limited-window) and on the [Rules page](/docs/tools/Clef/rules).
|
||||
More examples, including a ruleset for a rate-limited window, are available on the [Clef Github](https://github.com/ethereum/go-ethereum/blob/master/cmd/clef/rules.md#example-1-ruleset-for-a-rate-limited-window) and on the [Rules page](/docs/tools/clef/rules).
|
||||
|
||||
## Under the hood {#under-the-hood}
|
||||
|
||||
|
@ -568,9 +568,9 @@ cat ~/.clef/02f90c0603f4f2f60188/config.json
|
|||
This tutorial has bounced back and forth between demonstrating Clef as a standalone tool by making 'manual` JSON RPC requests from the terminal and integrating it as a backend singer for Geth. Using Clef for account management is considered best practise for Geth users because of the additional
|
||||
security benefits it offers over and above what it offered by Geth's built-in accounts module. Clef is far more flexible and composable than Geth's built-in account management tool and can interface directly with hardware wallets, while Apps and wallets can request signatures directly from Clef.
|
||||
|
||||
Ultimately, the goal is to deprecate Geth's account management tools completely and replace them with Clef. Until then, users are simply encouraged to choose to use Clef as an optional backend signer for Geth. In addition to the examples on this page, the [Getting started tutorial](/docs/_getting-started/index) also demonstrates Clef/Geth integration.
|
||||
Ultimately, the goal is to deprecate Geth's account management tools completely and replace them with Clef. Until then, users are simply encouraged to choose to use Clef as an optional backend signer for Geth. In addition to the examples on this page, the [Getting started tutorial](/docs/getting-started) also demonstrates Clef/Geth integration.
|
||||
|
||||
## Summary {#summary}
|
||||
|
||||
This page includes step-by-step instructions for basic and intermediate uses of Clef, including using it as a standalone app and a backend signer for Geth. Further information is available on our other Clef pages, including [Introduction](/docs/clef/introduction), [Setup](/docs/clef/setup),
|
||||
[Rules](/docs/clef/rules), [Communication Datatypes](/docs/clef/datatypes) and [Communication APIs](/docs/clef/apis). Also see the [Clef Github](https://github.com/ethereum/go-ethereum/tree/master/cmd/clef) for further reading.
|
||||
This page includes step-by-step instructions for basic and intermediate uses of Clef, including using it as a standalone app and a backend signer for Geth. Further information is available on our other Clef pages, including [Introduction](/docs/clef/introduction), [Setup](/docs/tools/clef/setup),
|
||||
[Rules](/docs/tools/clef/rules), [Communication Datatypes](/docs/clef/datatypes) and [Communication APIs](/docs/tools/clef/apis). Also see the [Clef Github](https://github.com/ethereum/go-ethereum/tree/master/cmd/clef) for further reading.
|
||||
|
|
|
@ -65,7 +65,7 @@ Run `devp2p dns to-cloudflare <directory>` to publish a tree to CloudFlare DNS.
|
|||
|
||||
Run `devp2p dns to-route53 <directory>` to publish a tree to Amazon Route53.
|
||||
|
||||
More information about these commands can be found in the [DNS Discovery Setup Guide](/docs/developers/dns-discovery-setup).
|
||||
More information about these commands can be found in the [DNS Discovery Setup Guide](/docs/developers/geth-developer/dns-discovery-setup).
|
||||
|
||||
## Node Set Utilities {#node-set-utilities}
|
||||
|
||||
|
|
|
@ -148,7 +148,7 @@ Puppeth will display the details of each node in a table in the terminal.
|
|||
|
||||
### Explorer {#explorer}
|
||||
|
||||
For proof-of-work networks a block explorer akin to [etherscan](etherscan.io) can be created using the Puppeth wizard.
|
||||
For proof-of-work networks a block explorer akin to [etherscan](https://etherscan.io/) can be created using the Puppeth wizard.
|
||||
|
||||
### Faucet {#faucet}
|
||||
|
||||
|
|
Before Width: | Height: | Size: 299 KiB After Width: | Height: | Size: 299 KiB |
Loading…
Reference in New Issue