Merge branch 'master' into algolia
This commit is contained in:
Paul Wackerow
commit
50eb37ae2f
|
|
@ -49,3 +49,11 @@ You can check out [the Next.js GitHub repository](https://github.com/vercel/next
|
|||
The easiest way to deploy your Next.js app is to use the [Vercel Platform](https://vercel.com/new?utm_medium=default-template&filter=next.js&utm_source=create-next-app&utm_campaign=create-next-app-readme) from the creators of Next.js.
|
||||
|
||||
Check out our [Next.js deployment documentation](https://nextjs.org/docs/deployment) for more details.
|
||||
|
||||
## Adding a new documentation page
|
||||
|
||||
Documentation pages are located in the `/docs` folder in the root directory of the project.
|
||||
|
||||
When you want to add a new page, add the new file in the appropriate folder in the `/docs` page. `index.md` files will be the default page for a directory, and `{pagename}.md` will define subpages for a directory.
|
||||
|
||||
After adding this page, you will need to add it `/src/data/documentation-links.yaml` which adds documentation structure which you will see on the left sidebar in the documentation pages.
|
||||
|
|
|
|||
|
|
@ -7,7 +7,7 @@ We welcome contributions from anyone on the internet, and are grateful for even
|
|||
|
||||
## Contributing to the Geth source code {#contributing-to-source-code}
|
||||
|
||||
If you'd like to contribute to the Geth source code, please fork the [Github repository](https://github.com/ethereum/go-ethereum), fix, commit and send a pull request for the maintainers to review and merge into the main code base. If you wish to submit more complex changes though, please check up with the core devs first on our Discord Server to ensure those changes are in line with the general philosophy of the project and/or get some early feedback which can make both your efforts much lighter as well as our review and merge procedures quick and simple.
|
||||
If you'd like to contribute to the Geth source code, please fork the [GitHub repository](https://github.com/ethereum/go-ethereum), fix, commit and send a pull request for the maintainers to review and merge into the main code base. If you wish to submit more complex changes though, please check up with the core devs first on our Discord Server to ensure those changes are in line with the general philosophy of the project and/or get some early feedback which can make both your efforts much lighter as well as our review and merge procedures quick and simple.
|
||||
|
||||
Please make sure your contributions adhere to our coding guidelines:
|
||||
|
||||
|
|
@ -25,7 +25,7 @@ We encourage an early pull request approach, meaning pull requests are created a
|
|||
|
||||
## Contributing to the Geth website {#contributing-to-website}
|
||||
|
||||
The Geth website is hosted separately from Geth itself. The contribution guidelines are the same. Please for the Geth website Github repository and raise pull requests for the maintainers to review and merge.
|
||||
The Geth website is hosted separately from Geth itself. The contribution guidelines are the same. Please for the Geth website GitHub repository and raise pull requests for the maintainers to review and merge.
|
||||
|
||||
## License {#license}
|
||||
|
||||
|
|
|
|||
|
|
@ -54,7 +54,7 @@ Similarly to the reusable [Go libraries](/docs/developers/dapp-developer/native-
|
|||
- Contract interactions through auto-generated bindings
|
||||
|
||||
The Geth mobile API is broadly equivalent to the [Go API](/docs/developers/dapp-developer/native-accounts). The source code can be found in the `mobile` section of Geth's
|
||||
[Github](https://github.com/ethereum/go-ethereum/tree/master/mobile).
|
||||
[GitHub](https://github.com/ethereum/go-ethereum/tree/master/mobile).
|
||||
|
||||
## Mobile Account Management {#mobile-account-management}
|
||||
|
||||
|
|
|
|||
|
|
@ -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
|
||||
|
|
|
|||
|
|
@ -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
|
||||
```
|
||||
|
||||
|
|
@ -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.
|
||||
|
|
@ -248,7 +249,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 +466,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 +476,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
|
||||
```
|
||||
|
||||
|
|
|
|||
|
|
@ -21,7 +21,7 @@ Geth's reusable Go libraries focus on three main usage areas:
|
|||
- Remote node interfacing via different transports
|
||||
- Contract interactions through auto-generated bindings
|
||||
|
||||
The libraries are updated synchronously with the Geth Github repository. The Go libraries can be viewed in full at [Go Packages](https://pkg.go.dev/github.com/ethereum/go-ethereum#section-directories).
|
||||
The libraries are updated synchronously with the Geth GitHub repository. The Go libraries can be viewed in full at [Go Packages](https://pkg.go.dev/github.com/ethereum/go-ethereum#section-directories).
|
||||
|
||||
Péter Szilágyi (@karalabe) gave a high level overview of the Go libraries in a talk at DevCon2 in Shanghai in 2016. The slides are still a useful resource ([available here](https://ethereum.karalabe.com/talks/2016-devcon.html)) and the talk itself can be viewed by clicking the image below (it is also archived on [IPFS](https://ipfs.io/ipfs/QmQRuKPKWWJAamrMqAp9rytX6Q4NvcXUKkhvu3kuREKqXR)).
|
||||
|
||||
|
|
@ -35,11 +35,11 @@ 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/...
|
||||
```
|
||||
|
||||
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}
|
||||
|
||||
|
|
@ -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()
|
||||
|
|
@ -189,7 +189,7 @@ SubscribePendingTransactions()
|
|||
|
||||
_Note that both `ethclient` and `gethclient` have a `CallContract()` function - the difference is that the `gethclient` version includes an `overrides` argument._
|
||||
|
||||
Details relating to these endpoints can be found at [pkg.go.dev](https://pkg.go.dev/github.com/ethereum/go-ethereum@v1.10.19/ethclient/gethclient) or the Geth [Github](https://github.com/ethereum/go-ethereum/tree/master/ethclient). The code snippets in this tutorial were adapted from a more more in-depth set of examples available on [Github](https://github.com/MariusVanDerWijden/web3go).
|
||||
Details relating to these endpoints can be found at [pkg.go.dev](https://pkg.go.dev/github.com/ethereum/go-ethereum@v1.10.19/ethclient/gethclient) or the Geth [GitHub](https://github.com/ethereum/go-ethereum/tree/master/ethclient). The code snippets in this tutorial were adapted from a more more in-depth set of examples available on [GitHub](https://github.com/MariusVanDerWijden/web3go).
|
||||
|
||||
## Summary {#summary}
|
||||
|
||||
|
|
|
|||
|
|
@ -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:
|
||||
|
|
@ -53,15 +53,15 @@ 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
|
||||
```
|
||||
|
||||
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:
|
||||
|
||||
```shell
|
||||
```sh
|
||||
enableMemory: true
|
||||
disableStack: false
|
||||
disableStorage: false
|
||||
|
|
@ -83,7 +83,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
|
||||
```
|
||||
|
||||
|
|
@ -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}
|
||||
|
||||
|
|
@ -28,7 +28,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
|
||||
|
|
@ -177,6 +177,7 @@ 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
|
||||
|
|
@ -472,7 +473,6 @@ Returns:
|
|||
DUP13: 2,
|
||||
...
|
||||
}
|
||||
|
||||
```
|
||||
|
||||
## State overrides {#state-overrides}
|
||||
|
|
|
|||
|
|
@ -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.
|
||||
|
||||
|
||||
|
||||
|
||||
_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
|
||||
{
|
||||
|
|
@ -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
|
||||
```
|
||||
|
||||
|
|
|
|||
|
|
@ -16,7 +16,7 @@ This configuration enables developers to experiment with Geth's source code or d
|
|||
|
||||
## 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.
|
||||
|
||||
|
|
@ -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")
|
||||
```
|
||||
|
||||
|
|
@ -170,7 +170,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{
|
||||
|
|
@ -220,7 +220,7 @@ INFO [05-09|12:27:09.681] 🔨 mined potential block number=2 h
|
|||
|
||||
## Interact with contract using Remix {#interact-with-contract}
|
||||
|
||||
The contract is now deployed on a local testnet version of the Etheruem blockchain. This means there is a contract address that contains executable bytecode that can be invoked by sending transactions with instructions, also in bytecode, to that address. Again, this can all be achieved by constructing transactions directly in the Geth console or even by making external http requests using tools such as Curl. Here, Remix is used to retrieve the value, then the same action is taken using the Javascript console.
|
||||
The contract is now deployed on a local testnet version of the Ethereum blockchain. This means there is a contract address that contains executable bytecode that can be invoked by sending transactions with instructions, also in bytecode, to that address. Again, this can all be achieved by constructing transactions directly in the Geth console or even by making external http requests using tools such as Curl. Here, Remix is used to retrieve the value, then the same action is taken using the Javascript console.
|
||||
|
||||
After deploying the contract in Remix, the `Deployed Contracts` tab in the sidebar automatically populates with the public functions exposed by `Storage.sol`. To send a value to the contract storage, type a number in the field adjacent to the `store` button, then click the button.
|
||||
|
||||
|
|
@ -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.
|
||||
|
|
|
|||
|
|
@ -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.
|
||||
|
||||
|
|
@ -74,11 +74,11 @@ The JSON file of known vulnerabilities below is a list of objects, one for each
|
|||
- `CVE`
|
||||
- The assigned `CVE` identifier, if available (optional)
|
||||
|
||||
### What about Github security advisories {#github-security-advisories}
|
||||
### What about GitHub security advisories {#github-security-advisories}
|
||||
|
||||
We prefer to not rely on Github as the only/primary publishing protocol for security advisories, but we plan to use the Github-advisory process as a second channel for disseminating vulnerability-information.
|
||||
We prefer to not rely on GitHub as the only/primary publishing protocol for security advisories, but we plan to use the GitHub-advisory process as a second channel for disseminating vulnerability-information.
|
||||
|
||||
Advisories published via Github can be accessed [here](https://github.com/ethereum/go-ethereum/security/advisories?state=published).
|
||||
Advisories published via GitHub can be accessed [here](https://github.com/ethereum/go-ethereum/security/advisories?state=published).
|
||||
|
||||
## Bug Bounties {#bug-bounties}
|
||||
|
||||
|
|
|
|||
|
|
@ -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"
|
||||
```
|
||||
|
|
|
|||
|
|
@ -1,6 +1,6 @@
|
|||
---
|
||||
title: Issue Handling Workflow
|
||||
description: Instructions for managing Github issues
|
||||
description: Instructions for managing GitHub issues
|
||||
---
|
||||
|
||||
## Draft proposal {#draft-proposal}
|
||||
|
|
|
|||
|
|
@ -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}
|
||||
|
||||
|
|
@ -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',
|
||||
|
|
|
|||
10
docs/faq.md
10
docs/faq.md
|
|
@ -3,9 +3,9 @@ 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).
|
||||
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 server](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).
|
||||
|
||||
The Geth team have also recently started to run AMA's on Reddit:
|
||||
|
||||
|
|
@ -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}
|
||||
|
||||
|
|
@ -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"
|
||||
```
|
||||
|
||||
|
|
@ -78,7 +78,7 @@ The console will hang because Clef is waiting for manual approval. Switch to the
|
|||
|
||||
It is critical to backup the account password safely and securely as it cannot be retrieved or reset.
|
||||
|
||||
{% include note.html content=" If the password provided on account creation is lost or forgotten, there is no way to retrive it and the account will simply stay locked forever. The password MUST be backed up safely and securely! **IT IS CRITICAL TO BACKUP THE KEYSTORE AND REMEMBER PASSWORDS**" %}
|
||||
<Note>If the password provided on account creation is lost or forgotten, there is no way to retrive it and the account will simply stay locked forever. The password MUST be backed up safely and securely! **IT IS CRITICAL TO BACKUP THE KEYSTORE AND REMEMBER PASSWORDS**</Note>
|
||||
|
||||
The newly generated key files can be viewed in `<datadir>/keystore/`. The file naming format is `UTC--<date>--<address>` where `date` is the date and time of key creation formatted according to [UTC 8601](https://www.iso.org/iso-8601-date-and-time-format.html) with zero time offset and seconds precise to eight decimal places. `address` is the 40 hexadecimal characters that make up the account address without a leading `0x`, for example:
|
||||
|
||||
|
|
@ -145,11 +145,11 @@ which returns:
|
|||
|
||||
### Import a keyfile {#importing-a-keyfile}
|
||||
|
||||
It is also possible to create an account by importing an existing private key. For example, a user might already have some ether at an address they created using a browser wallet and now wish to use a new Geth node to interact with their funds. In this case, the private key can be exported from the browser wallet and imported into Geth. It is possible to do this using Clef, but currently the method is not externally exposed and requires implementing a UI. There is a Python UI on the Geth Github that could be used as an example or it can be done using the default console UI. However, for now the most straightforward way to import an accoutn from a private key is to use Geth's `account import`.
|
||||
It is also possible to create an account by importing an existing private key. For example, a user might already have some ether at an address they created using a browser wallet and now wish to use a new Geth node to interact with their funds. In this case, the private key can be exported from the browser wallet and imported into Geth. It is possible to do this using Clef, but currently the method is not externally exposed and requires implementing a UI. There is a Python UI on the Geth GitHub that could be used as an example or it can be done using the default console UI. However, for now the most straightforward way to import an accoutn from a private key is to use Geth's `account import`.
|
||||
|
||||
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
|
||||
|
||||
|
|
|
|||
|
|
@ -11,4 +11,4 @@ This is where you will find information about how to manage a Geth node and unde
|
|||
|
||||
For example, the pages here will help you to understand the underlying architecture of your Geth node, how to start it in different configurations using command line options, how to sync the blockchain and how to manage accounts. There is a page on security practices that will help you to keep your Geth node safe from adversaries.
|
||||
|
||||
Note also that there is a page explaining common log messages that are often queried on the Geth discord and Github - this will help users to interpret the messages displayed to the console and know what actions to take.
|
||||
Note also that there is a page explaining common log messages that are often queried on the Geth discord and GitHub - this will help users to interpret the messages displayed to the console and know what actions to take.
|
||||
|
|
|
|||
|
|
@ -3,13 +3,13 @@ title: Light client
|
|||
description: Introduction to Geth's light sync mode
|
||||
---
|
||||
|
||||
{% include note.html content="Light nodes do not currently work on proof-of-stake Ethereum, but new proof-of-stake light clients are expected to ship soon!" %}
|
||||
<Note>Light nodes do not currently work on proof-of-stake Ethereum, but new proof-of-stake light clients are expected to ship soon!</Note>
|
||||
|
||||
Running a full node is the most trustless, private, decentralized and censorship resistant way to interact with Ethereum. It is also the best choice for the health of the network, because a decentralized network relies on having many individual nodes that independently verify the head of the chain. In a full node a copy of the blockchain is stored locally enabling users to verify incoming data against a local source of truth. However, running a full node requires a lot of disk space and non-negligible CPU allocation and takes hours (for snap sync) or days (for full sync) to sync the blockchain from genesis. Geth also offers a light mode that overcomes these issues and provides some of the benefits of running a node but requires only a fraction of the resources.
|
||||
|
||||
Read more about the reasons to run nodes on [ethereum.org](https://ethereum.org/en/run-a-node/).
|
||||
|
||||
{% include note.html content=" Geth light clients **do not currently work** on proof-of-stake Ethereum. New light clients that work with the proof-of-stake consensus engine are expected to ship soon!" %}
|
||||
<Note>Geth light clients **do not currently work** on proof-of-stake Ethereum. New light clients that work with the proof-of-stake consensus engine are expected to ship soon!</Note>
|
||||
|
||||
## Light node vs full node {#light-node-vs-full-node}
|
||||
|
||||
|
|
@ -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,11 +41,11 @@ 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"
|
||||
```
|
||||
|
||||
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.
|
||||
|
||||
|
|
|
|||
|
|
@ -5,7 +5,7 @@ description: Geth's log messages explained
|
|||
|
||||
A Geth node continually reports messages to the console allowing users to monitor Geth's current status in real-time. The logs indicate when Geth is running normally and indicates when some attention is required. However, reading these logs can be difficult for new users. This page will help to interpret the log messages to better understand what Geth is doing.
|
||||
|
||||
Note that there are a large number of log messages covering a wide range of possible scenarios for a Geth node. This page will only address a subset of commonly seen messages. For more, see the [Geth Github](https://github.com/ethereum/go-ethereum), [Discord](https://discord.gg/WHNkYDsAKU) or search on [ethereum.stackexchange](https://ethereum.stackexchange.com/). Log messages are usually sufficiently self-descrining that they do not require additional explanation.
|
||||
Note that there are a large number of log messages covering a wide range of possible scenarios for a Geth node. This page will only address a subset of commonly seen messages. For more, see the [Geth GitHub](https://github.com/ethereum/go-ethereum), [Discord](https://discord.gg/WHNkYDsAKU) or search on [ethereum.stackexchange](https://ethereum.stackexchange.com/). Log messages are usually sufficiently self-descrining that they do not require additional explanation.
|
||||
|
||||
## Configuring log messages {#configuring-log-messages}
|
||||
|
||||
|
|
@ -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
|
||||
|
|
@ -128,9 +128,9 @@ INFO [07-28|10:30:18.658] Imported new block headers count=1 el
|
|||
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.
|
||||
For state sync, Geth reports when the state heal is in progress. This can take a 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
|
||||
|
|
@ -186,7 +186,7 @@ Other user actions have similar log messages that are displayed to the console.
|
|||
|
||||
## Common warnings {#common-warnings}
|
||||
|
||||
There are many warnings that can be emitted by Geth as part of its normal operation. However, some are asked about especially frequently on the [Geth Github](https://github.com/ethereum/go-ethereum) and [Discord](https://discord.gg/WHNkYDsAKU) channel.
|
||||
There are many warnings that can be emitted by Geth as part of its normal operation. However, some are asked about especially frequently on the [Geth GitHub](https://github.com/ethereum/go-ethereum) and [Discord](https://discord.gg/WHNkYDsAKU) channel.
|
||||
|
||||
```sh
|
||||
WARN [10-03|18:00:40.413] Unexpected trienode heal packet peer=9f0e8fbf reqid=6,915,308,639,612,522,441
|
||||
|
|
@ -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!
|
||||
|
|
@ -214,4 +214,4 @@ This message indicates that a peer is being dropped because it is not fully sync
|
|||
|
||||
## Summary {#summary}
|
||||
|
||||
There are a wide range of log messages that are emitted while Geth is running. The level of detail in the logs can be configured using the `verbosity` flag at startup. This page has outlined some of the common messages users can expect to see when Geth is run with default verbosity, without attempting to be comprehensive. For more, please see the [Geth Github](https://github.com/ethereum/go-ethereum) and [Discord](https://discord.gg/WHNkYDsAKU).
|
||||
There are a wide range of log messages that are emitted while Geth is running. The level of detail in the logs can be configured using the `verbosity` flag at startup. This page has outlined some of the common messages users can expect to see when Geth is run with default verbosity, without attempting to be comprehensive. For more, please see the [Geth GitHub](https://github.com/ethereum/go-ethereum) and [Discord](https://discord.gg/WHNkYDsAKU).
|
||||
|
|
|
|||
|
|
@ -3,7 +3,7 @@ title: Proof-of-work mining with Ethash
|
|||
description: Introduction to proof-of-work mining with Geth
|
||||
---
|
||||
|
||||
{% include note.html content=" Proof-of-work mining is no longer used to secure Ethereum Mainnet. The information below is included because the Ethash code is still part of Geth and it could be used to create a private proof-of-work network or testnet." %}
|
||||
<Note>Proof-of-work mining is no longer used to secure Ethereum Mainnet. The information below is included because the Ethash code is still part of Geth and it could be used to create a private proof-of-work network or testnet.</Note>
|
||||
|
||||
Blockchains grow when individual nodes create valid blocks and distribute them to their peers who check the blocks and add them to their own local databases.
|
||||
Nodes that add blocks are rewarded with ether payouts. On Ethereum Mainnet, the proof-of-stake consensus engine randomly selects a node to produce each block.
|
||||
|
|
@ -23,27 +23,27 @@ Regardless of the mining method, the blockchain must be fully synced before mini
|
|||
|
||||
### Installing Ethminer {#installing-ethminer}
|
||||
|
||||
The Ethminer software can be installed from a downloaded binary or built from source. The relevant downloads and installation instructions are available from the [Ethminer Github](https://github.com/ethereum-mining/ethminer/#build). Standalone executables are available for Linux, macOS and Windows.
|
||||
The Ethminer software can be installed from a downloaded binary or built from source. The relevant downloads and installation instructions are available from the [Ethminer GitHub](https://github.com/ethereum-mining/ethminer/#build). Standalone executables are available for Linux, macOS and Windows.
|
||||
|
||||
### 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.
|
||||
|
||||
```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:
|
||||
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:
|
||||
|
||||
```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,11 +99,11 @@ 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
|
||||
```
|
||||
|
||||
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);
|
||||
|
|
@ -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'
|
||||
```
|
||||
|
|
|
|||
|
|
@ -5,11 +5,11 @@ description: Introduction to how Ethereum nodes are organized and where Geth fit
|
|||
|
||||
An Ethereum node is composed of two clients: an [execution client](https://ethereum.org/en/developers/docs/nodes-and-clients/#execution-clients) and a [consensus client](https://ethereum.org/en/developers/docs/nodes-and-clients/#consensus-clients). Geth is an [execution client](https://ethereum.org/en/developers/docs/nodes-and-clients/#execution-clients). Originally, an execution client alone was enough to run a full Ethereum node. However, ever since Ethereum turned off [proof-of-work](https://ethereum.org/en/developers/docs/consensus-mechanisms/pow/) and implemented [proof-of-stake](https://ethereum.org/en/developers/docs/consensus-mechanisms/pow/), Geth has needed to be coupled to another piece of software called a [“consensus client”](https://ethereum.org/en/developers/docs/nodes-and-clients/#consensus-clients) in order to keep track of the Ethereum blockchain.
|
||||
|
||||
The execution client (Geth) is responsible for transaction handling, transaction gossip, state management and supporting the Ethereum Virtual Machine ([EVM])(https://ethereum.org/en/developers/docs/evm/). However, Geth is **not** responsible for block building, block gossiping or handling consensus logic. These are in the remit of the consensus client.
|
||||
The execution client (Geth) is responsible for transaction handling, transaction gossip, state management and supporting the Ethereum Virtual Machine [EVM](https://ethereum.org/en/developers/docs/evm/). However, Geth is **not** responsible for block building, block gossiping or handling consensus logic. These are in the remit of the consensus client.
|
||||
|
||||
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).
|
||||
|
||||
|
|
@ -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,16 +3,16 @@ 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) 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:
|
||||
|
||||
```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
|
||||
```
|
||||
|
||||
|
|
@ -40,15 +40,15 @@ 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.
|
||||
|
||||
```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',
|
||||
|
|
@ -106,13 +106,13 @@ 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 Ethereum 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}
|
||||
|
||||
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'
|
||||
);
|
||||
|
|
|
|||
|
|
@ -3,7 +3,7 @@ title: Pruning
|
|||
description: Instructions for pruning a Geth node
|
||||
---
|
||||
|
||||
{% include note.html content="Offline pruning is only for the hash-based state scheme. Soon, we will have a path-based state scheme which enables the pruning by default. Once the hash-based state scheme is no longer supported, offline pruning will be deprecated." %}
|
||||
<Note>Offline pruning is only for the hash-based state scheme. Soon, we will have a path-based state scheme which enables the pruning by default. Once the hash-based state scheme is no longer supported, offline pruning will be deprecated.</Note>
|
||||
|
||||
A snap-sync'd Geth node currently requires more than 650 GB of disk space to store the historic blockchain data. With default cache size the database grows by about 14 GB/week. This means that Geth users will rapidly run out of space on 1TB hard drives. To solve this problem without needing to purchase additional hardware, Geth can be pruned. Pruning is the process of erasing older data to save disk space. Since Geth `v1.10`, users have been able to trigger a snapshot offline prune to bring the total storage back down to the original ~650 GB in about 4-5 hours. This has to be done periodically to keep the total disk storage
|
||||
within the bounds of the local hardware (e.g. every month or so for a 1TB disk).
|
||||
|
|
|
|||
|
|
@ -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.
|
||||
|
|
@ -46,11 +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).
|
||||
|
||||
The following diagram shows how Geth stores state data in the different sync modes:
|
||||
|
||||
|
||||
Read more about light nodes on our [LES page](/docs/fundamentals/les).
|
||||
|
||||
## Consensus layer syncing {#consensus-layer-syncing}
|
||||
|
||||
|
|
@ -70,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.
|
||||
|
||||
|
|
@ -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
|
||||
```
|
||||
|
||||
|
|
@ -55,10 +55,10 @@ 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`):
|
||||
|
||||
```shell
|
||||
```sh
|
||||
geth attach datadir/geth.ipc
|
||||
```
|
||||
|
||||
|
|
|
|||
|
|
@ -18,7 +18,7 @@ It is recommended to use at least 16GB RAM.
|
|||
Disk space is usually the primary bottleneck for node operators. At the time of writing (September 2022) a 2TB SSD is recommended for a full node running Geth and a consensus client. Geth itself requires >650GB of disk space for a snap-synced full node and, with the default cache size, grows about 14GB/week. Pruning brings the total storage back down to the original 650GB.
|
||||
Archive nodes require additional space. A "full" archive node that keeps all state back to genesis requires more than 12TB of space. Partial archive nodes can also be created by turning off the garbage collector after some initial sync - the storage requirement depends how much state is saved.
|
||||
|
||||
As well as storage capacity, Geth nodes rely on fast read and write operations. This means HDDs and cheaper HDDS can sometimes struggle to sync the blockchain. A list of SSD models that users report being able and unable to sync Geth is available in this [Github Gist](https://gist.github.com/yorickdowne/f3a3e79a573bf35767cd002cc977b038). Please note that the list has _not_ been verified by the Geth team.
|
||||
As well as storage capacity, Geth nodes rely on fast read and write operations. This means HDDs and cheaper HDDS can sometimes struggle to sync the blockchain. A list of SSD models that users report being able and unable to sync Geth is available in this [GitHub Gist](https://gist.github.com/yorickdowne/f3a3e79a573bf35767cd002cc977b038). Please note that the list has _not_ been verified by the Geth team.
|
||||
|
||||
## Bandwidth {#bandwidth}
|
||||
|
||||
|
|
|
|||
|
|
@ -5,7 +5,7 @@ description: Guide to getting up and running with Geth using Clef.
|
|||
|
||||
This page explains how to set up Geth and execute some basic tasks using the command line tools. In order to use Geth, the software must first be installed. There are several ways Geth can be installed depending on the operating system and the user's choice of installation method, for example using a package manager, container or building from source. Instructions for installing Geth can be found on the ["Install and Build"](/docs/getting_started/Installing-Geth) pages.
|
||||
|
||||
Geth also needs to be connected to a [consensus client](docs/getting-started/consensus-clients.md) in order to function as an Ethereum node. The tutorial on this page assumes Geth and a consensus client have been installed successfully and that a firewall has been configured to block external traffic to the JSON-RPC port `8545` see [Security](/docs/fundamentals/security).
|
||||
Geth also needs to be connected to a [consensus client](docs/getting-started/consensus-clients) in order to function as an Ethereum node. The tutorial on this page assumes Geth and a consensus client have been installed successfully and that a firewall has been configured to block external traffic to the JSON-RPC port `8545` see [Security](/docs/fundamentals/security).
|
||||
|
||||
This page provides step-by-step instructions covering the fundamentals of using Geth. This includes generating accounts, joining an Ethereum network, syncing the blockchain and sending ether between accounts. This tutorial uses [Clef](/docs/tools/Clef/Tutorial). Clef is an account management tool external to Geth itself that allows users to sign transactions. It is developed and maintained by the Geth team.
|
||||
|
||||
|
|
@ -21,7 +21,7 @@ In order to get the most value from the tutorials on this page, the following sk
|
|||
Users that need to revisit these fundamentals can find helpful resources relating to the command line [here](https://developer.mozilla.org/en-US/docs/Learn/Tools_and_testing/Understanding_client-side_tools/Command_line), Ethereum and its testnets [here](https://ethereum.org/en/developers/tutorials/), http [here](https://developer.mozilla.org/en-US/docs/Web/HTTP) and Javascript [here](https://www.javascript.com/learn). Information on node architecture can be found [here](/docs/fundamentals/node-architecture) and our guide for configuring Geth to connect to a
|
||||
consensus client is [here](/docs/getting_started/consensus-clients).
|
||||
|
||||
{% include note.html content="If Geth was installed from source on Linux, `make` saves the binaries for Geth and the associated tools in `/build/bin`. To run these programs it is convenient to move them to the top level project directory (e.g. running `mv ./build/bin/* ./`) from `/go-ethereum`. Then `./` must be prepended to the commands in the code snippets in order to execute a particular program, e.g. `./geth` instead of simply `geth`. If the executables are not moved then either navigate to the `bin` directory to run them (e.g. `cd ./build/bin` and `./geth`) or provide their path (e.g. `./build/bin/geth`). These instructions can be ignored for other installations." %}
|
||||
<Note>If Geth was installed from source on Linux, `make` saves the binaries for Geth and the associated tools in `/build/bin`. To run these programs it is convenient to move them to the top level project directory (e.g. running `mv ./build/bin/* ./`) from `/go-ethereum`. Then `./` must be prepended to the commands in the code snippets in order to execute a particular program, e.g. `./geth` instead of simply `geth`. If the executables are not moved then either navigate to the `bin` directory to run them (e.g. `cd ./build/bin` and `./geth`) or provide their path (e.g. `./build/bin/geth`). These instructions can be ignored for other installations.</Note>
|
||||
|
||||
## Background {#background}
|
||||
|
||||
|
|
@ -33,11 +33,11 @@ Read more about Ethereum accounts [here](https://ethereum.org/en/developers/docs
|
|||
|
||||
## Step 1: Generating accounts {#generating-accounts}
|
||||
|
||||
There are several methods for generating accounts in Geth. This tutorial demonstrates how to generate accounts using Clef, as this is considered best practice, largely because it decouples the users' key management from Geth, making it more modular and flexible. It can also be run from secure USB sticks or virtual machines, offering security benefits. For convenience, this tutorial will execute Clef on the same computer that will also run Geth, although more secure options are available (see [here](https://github.com/ethereum/go-ethereum/blob/master/cmd/clef/docs/setup.md)).
|
||||
There are several methods for generating accounts in Geth. This tutorial demonstrates how to generate accounts using Clef, as this is considered best practice, largely because it decouples the users' key management from Geth, making it more modular and flexible. It can also be run from secure USB sticks or virtual machines, offering security benefits. For convenience, this tutorial will execute Clef on the same computer that will also run Geth, although more secure options are available (see [here](/docs/tools/clef/setup)).
|
||||
|
||||
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,13 +115,13 @@ 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
|
||||
```
|
||||
|
||||
Running the above command starts Geth. Geth will not sync the blockchain correctly unless there is also a consensus client that can pass Geth a valid head to sync up to. In a separate terminal, start a consensus client. Once the consensus client gets in sync, Geth will start to sync too.
|
||||
|
||||
The terminal should rapidly fill with status updates that look similar to those below. To check the meaning of the logs, refer to the [logs page](docs/fundamentals/logs.md).
|
||||
The terminal should rapidly fill with status updates that look similar to those below. To check the meaning of the logs, refer to the [logs page](/docs/fundamentals/logs).
|
||||
|
||||
```terminal
|
||||
INFO [02-10|13:59:06.649] Starting Geth on sepolia testnet...
|
||||
|
|
@ -153,7 +153,7 @@ 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
|
||||
```
|
||||
|
||||
|
|
@ -161,7 +161,7 @@ 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
|
||||
|
|
@ -258,28 +258,28 @@ C:\Users\xxx\src\github.com\ethereum\go-ethereum> go install -v ./cmd/...
|
|||
|
||||
### FreeBSD {#freeBSD}
|
||||
|
||||
To build Geth from source code on FreeBSD, the Geth Github repository can be cloned into a local directory.
|
||||
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
|
||||
|
|
@ -303,9 +303,9 @@ make geth
|
|||
|
||||
These commands create a Geth executable file in the `go-ethereum/build/bin` folder that can be moved and run from another directory if required. The binary is standalone and doesn't require any additional files.
|
||||
|
||||
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.
|
||||
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;
|
||||
|
|
|
|||
|
|
@ -3,9 +3,9 @@ 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,13 +18,13 @@ 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)." %}
|
||||
<Note>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).</Note>
|
||||
|
||||
## Starting the console {#starting-the-console}
|
||||
|
||||
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
|
||||
```
|
||||
|
||||
|
|
@ -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,11 +93,9 @@ 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.
|
||||
|
||||
```shell
|
||||
```sh
|
||||
geth console --preload "/my/scripts/folder/utils.js"
|
||||
```
|
||||
|
||||
|
|
@ -109,29 +105,27 @@ 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:
|
||||
|
||||
```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")'
|
||||
```
|
||||
|
||||
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}
|
||||
|
||||
|
|
|
|||
|
|
@ -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() {
|
||||
|
|
@ -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.
|
||||
|
|
|
|||
|
|
@ -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`
|
||||
|
|
|
|||
|
|
@ -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
|
||||
|
|
@ -78,7 +78,7 @@ geth --ws --ws.origins http://myapp.example.com
|
|||
|
||||
As with `--http.corsdomain`, using the wildcard `--ws.origins '*'` allows access from any origin.
|
||||
|
||||
{% include note.html content=" By default, **account unlocking is forbidden when HTTP or Websocket access is enabled** (i.e. by passing `--http` or `ws` flag). This is because an attacker that manages to access the node via the externally-exposed HTTP/WS port can then control the unlocked account. It is possible to force account unlock by including the `--allow-insecure-unlock` flag but this is unsafe and **not recommended** except for expert users that completely understand how it can be used safely. This is not a hypothetical risk: **there are bots that continually scan for http-enabled Ethereum nodes to attack**" %}
|
||||
<Note>By default, **account unlocking is forbidden when HTTP or Websocket access is enabled** (i.e. by passing `--http` or `ws` flag). This is because an attacker that manages to access the node via the externally-exposed HTTP/WS port can then control the unlocked account. It is possible to force account unlock by including the `--allow-insecure-unlock` flag but this is unsafe and **not recommended** except for expert users that completely understand how it can be used safely. This is not a hypothetical risk: **there are bots that continually scan for http-enabled Ethereum nodes to attack**</Note>
|
||||
|
||||
### IPC Server {#ipc-server}
|
||||
|
||||
|
|
@ -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).
|
||||
|
||||
|
|
|
|||
|
|
@ -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",
|
||||
|
|
@ -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
|
||||
|
|
@ -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"],
|
||||
|
|
@ -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`)
|
||||
|
|
@ -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")
|
||||
```
|
||||
|
||||
|
|
@ -114,7 +114,7 @@ Retrieves the state that corresponds to the block number and returns a list of a
|
|||
|
||||
#### Example
|
||||
|
||||
```javascript
|
||||
```js
|
||||
> debug.dumpBlock(10)
|
||||
{
|
||||
fff7ac99c8e4feb60c9750054bdc14ce1857f181: {
|
||||
|
|
@ -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
|
||||
|
||||
|
|
@ -369,14 +369,14 @@ This means that this method is only 'useful' for callers who control the node --
|
|||
|
||||
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"]
|
||||
|
||||
|
|
@ -386,7 +386,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
|
||||
|
|
@ -397,7 +397,7 @@ 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
|
||||
|
|
@ -475,11 +475,11 @@ 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
|
||||
|
||||
```javascript
|
||||
```js
|
||||
> debug.traceBlock("0xblock_rlp")
|
||||
{
|
||||
gas: 85301,
|
||||
|
|
@ -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 |
|
||||
| :-----: | --------------------------------------------------------------------------------------------------------------------------- |
|
||||
|
|
@ -566,7 +566,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,
|
||||
|
|
@ -578,19 +578,22 @@ 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
|
||||
debug.traceCall({
|
||||
"from": "0xdeadbeef29292929192939494959594933929292",
|
||||
"to": "0xde929f939d939d393f939393f93939f393929023",
|
||||
"gas": "0x7a120",
|
||||
"data": "0xf00d4b5d00000000000000000000000001291230982139282304923482304912923823920000000000000000000000001293123098123928310239129839291010293810"
|
||||
```js
|
||||
debug.traceCall(
|
||||
{
|
||||
from: '0xdeadbeef29292929192939494959594933929292',
|
||||
to: '0xde929f939d939d393f939393f93939f393929023',
|
||||
gas: '0x7a120',
|
||||
data: '0xf00d4b5d00000000000000000000000001291230982139282304923482304912923823920000000000000000000000001293123098123928310239129839291010293810'
|
||||
},
|
||||
"latest", {"disableStorage": true, "disableMemory": true})
|
||||
'latest',
|
||||
{ disableStorage: true, disableMemory: true }
|
||||
);
|
||||
```
|
||||
|
||||
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",
|
||||
|
|
@ -638,7 +641,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 +670,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
|
||||
|
||||
|
|
@ -731,25 +734,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');
|
||||
```
|
||||
|
||||
|
|
|
|||
|
|
@ -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`
|
||||
|
||||
|
|
@ -41,6 +41,7 @@ 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:
|
||||
|
|
@ -69,7 +70,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 +86,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 +99,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 +121,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
|
||||
```
|
||||
|
||||
|
|
@ -138,7 +139,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
|
||||
|
||||
|
|
|
|||
|
|
@ -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"
|
||||
```
|
||||
|
|
|
|||
|
|
@ -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
|
||||
|
||||
|
|
@ -3,9 +3,9 @@ title: personal Namespace
|
|||
description: Documentation for the JSON-RPC API "personal" namespace
|
||||
---
|
||||
|
||||
{% include note.html content="The personal namespace will be deprecated in the very near future." %}
|
||||
<Note>The personal namespace will be deprecated in the very near future.</Note>
|
||||
|
||||
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}
|
||||
|
||||
|
|
@ -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:
|
||||
|
|
@ -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 |
|
||||
| :------ | ---------------------------------------------------------------- |
|
||||
|
|
@ -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,14 +204,14 @@ See ecRecover to verify the signature.
|
|||
|
||||
### Examples
|
||||
|
||||
```javascript
|
||||
```js
|
||||
> personal.sign("0xdeadbeaf", "0x9b2055d370f73ec7d8a03e965129118dc8f5bf83", "")
|
||||
"0xa3f20717a250c2b0b729b7e5becbff67fdaef7e0699da4de7ca5895b02a170a12d887fd3b17bfdce3481f10bea41f45ba9f709d39ce8325427b57afcfc994cee1b"
|
||||
```
|
||||
|
||||
## 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 |
|
||||
| :------ | ---------------------------------------------------------------- |
|
||||
|
|
@ -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
|
||||
```
|
||||
|
|
@ -130,7 +130,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:
|
||||
|
||||
|
||||
|
||||
|
||||
## 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
|
||||
|
|
|
|||
|
|
@ -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")
|
||||
|
|
|
|||
|
|
@ -1,5 +1,5 @@
|
|||
---
|
||||
title: resources
|
||||
title: Resources
|
||||
description: Read, watch and listen more about Geth and Ethereum
|
||||
---
|
||||
|
||||
|
|
|
|||
|
|
@ -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
|
||||
```
|
||||
|
||||
|
|
@ -137,4 +137,4 @@ type Storage struct {
|
|||
|
||||
`Storage.go` contains all the bindings required to interact with `Storage.sol` from a Go application.
|
||||
|
||||
For instructions on how to deploy this contract to Ethereum from a Go native application read our [Go bindings page](/docs/developers/dapp-developer/native). To browse the Abigen source code visit the Geth [Github repository](https://github.com/ethereum/go-ethereum/tree/master/cmd/abigen).
|
||||
For instructions on how to deploy this contract to Ethereum from a Go native application read our [Go bindings page](/docs/developers/dapp-developer/native). To browse the Abigen source code visit the Geth [GitHub repository](https://github.com/ethereum/go-ethereum/tree/master/cmd/abigen).
|
||||
|
|
|
|||
|
|
@ -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,11 @@ 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 +88,11 @@ 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 +116,11 @@ 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 +168,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:
|
||||
|
|
|
|||
|
|
@ -25,7 +25,7 @@ The ruleset engine acts as a gatekeeper to the command line interface - it auto-
|
|||
|
||||
|
||||
|
||||
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) {
|
||||
|
|
@ -238,4 +238,4 @@ function OnApprovedTx(resp) {
|
|||
|
||||
## Summary {#summary}
|
||||
|
||||
Rules are sets of conditions encoded in Javascript files that enable certain actions to be auto-approved by Clef. This page outlined the implementation details and security considerations that will help to build suitrable ruleset files. See the [Clef Github](https://github.com/ethereum/go-ethereum/tree/master/cmd/clef) for further reading.
|
||||
Rules are sets of conditions encoded in Javascript files that enable certain actions to be auto-approved by Clef. This page outlined the implementation details and security considerations that will help to build suitrable ruleset files. See the [Clef GitHub](https://github.com/ethereum/go-ethereum/tree/master/cmd/clef) for further reading.
|
||||
|
|
|
|||
|
|
@ -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,11 @@ 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.
|
||||
|
|
@ -48,7 +50,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:
|
||||
|
||||
|
|
@ -76,7 +78,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
|
||||
|
|
@ -193,7 +195,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).
|
||||
|
|
@ -208,7 +209,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)
|
||||
|
|
@ -305,7 +306,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 +489,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
|
||||
|
|
@ -503,7 +504,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 +569,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}
|
||||
|
||||
|
|
@ -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
|
||||
```
|
||||
|
||||
|
|
@ -172,4 +172,4 @@ geth --datadir Node1 --port 30301 --bootnodes <enr> --networkid <testnetwork ID>
|
|||
|
||||
Puppeth is a command line wizard that guides a user through the various stages of setting up a private network using proof-of-authority or proof-of-work consensus engine. Various network components can be added that optimize the network or enable network monitoring.
|
||||
|
||||
[Github repository](https://github.com/ethereum/go-ethereum/tree/master/cmd/puppeth)
|
||||
[GitHub repository](https://github.com/ethereum/go-ethereum/tree/master/cmd/puppeth)
|
||||
|
|
|
|||
|
|
@ -32,6 +32,7 @@
|
|||
"react-dom": "18.2.0",
|
||||
"react-markdown": "^8.0.3",
|
||||
"react-syntax-highlighter": "^15.5.0",
|
||||
"rehype-raw": "^6.1.1",
|
||||
"remark-gfm": "^3.0.1"
|
||||
},
|
||||
"devDependencies": {
|
||||
|
|
|
|||
|
|
@ -135,7 +135,7 @@
|
|||
"name": "DoS via malicious `snap/1` request",
|
||||
"uid": "GETH-2021-03",
|
||||
"summary": "A vulnerable node is susceptible to crash when processing a maliciously crafted message from a peer, via the snap/1 protocol. The crash can be triggered by sending a malicious snap/1 GetTrieNodes package.",
|
||||
"description": "The `snap/1` protocol handler contains two vulnerabilities related to the `GetTrieNodes` packet, which can be exploited to crash the node. Full details are available at the Github security [advisory](https://github.com/ethereum/go-ethereum/security/advisories/GHSA-59hh-656j-3p7v)",
|
||||
"description": "The `snap/1` protocol handler contains two vulnerabilities related to the `GetTrieNodes` packet, which can be exploited to crash the node. Full details are available at the GitHub security [advisory](https://github.com/ethereum/go-ethereum/security/advisories/GHSA-59hh-656j-3p7v)",
|
||||
"links": [
|
||||
"https://github.com/ethereum/go-ethereum/security/advisories/GHSA-59hh-656j-3p7v",
|
||||
"https://geth.ethereum.org/docs/vulnerabilities/vulnerabilities",
|
||||
|
|
@ -152,7 +152,7 @@
|
|||
"name": "DoS via malicious p2p message",
|
||||
"uid": "GETH-2022-01",
|
||||
"summary": "A vulnerable node can crash via p2p messages sent from an attacker node, if running with non-default log options.",
|
||||
"description": "A vulnerable node, if configured to use high verbosity logging, can be made to crash when handling specially crafted p2p messages sent from an attacker node. Full details are available at the Github security [advisory](https://github.com/ethereum/go-ethereum/security/advisories/GHSA-wjxw-gh3m-7pm5)",
|
||||
"description": "A vulnerable node, if configured to use high verbosity logging, can be made to crash when handling specially crafted p2p messages sent from an attacker node. Full details are available at the GitHub security [advisory](https://github.com/ethereum/go-ethereum/security/advisories/GHSA-wjxw-gh3m-7pm5)",
|
||||
"links": [
|
||||
"https://github.com/ethereum/go-ethereum/security/advisories/GHSA-wjxw-gh3m-7pm5",
|
||||
"https://geth.ethereum.org/docs/vulnerabilities/vulnerabilities",
|
||||
|
|
|
|||
|
Before Width: | Height: | Size: 299 KiB After Width: | Height: | Size: 299 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 500 KiB |
|
|
@ -1,114 +0,0 @@
|
|||
import {
|
||||
Flex,
|
||||
Heading,
|
||||
Link,
|
||||
ListItem,
|
||||
OrderedList,
|
||||
Stack,
|
||||
Table,
|
||||
Text,
|
||||
UnorderedList
|
||||
} from '@chakra-ui/react';
|
||||
import NextLink from 'next/link';
|
||||
|
||||
import { Code } from './UI/docs';
|
||||
import { textStyles } from '../theme/foundations';
|
||||
|
||||
const { header1, header2, header3, header4 } = textStyles;
|
||||
|
||||
const MDXComponents = {
|
||||
// paragraphs
|
||||
p: ({ children }: any) => {
|
||||
return (
|
||||
<Text mb={7} lineHeight={1.5}>
|
||||
{children}
|
||||
</Text>
|
||||
);
|
||||
},
|
||||
// links
|
||||
a: ({ children, href }: any) => {
|
||||
return (
|
||||
<NextLink href={href} passHref>
|
||||
<Link
|
||||
isExternal={href.startsWith('http') && !href.includes('geth.ethereum.org')}
|
||||
variant='light'
|
||||
>
|
||||
{children}
|
||||
</Link>
|
||||
</NextLink>
|
||||
);
|
||||
},
|
||||
// headings
|
||||
h1: ({ children }: any) => {
|
||||
return (
|
||||
<Heading as='h1' textAlign='start' mb={5} {...header1}>
|
||||
{children}
|
||||
</Heading>
|
||||
);
|
||||
},
|
||||
h2: ({ children }: any) => {
|
||||
return (
|
||||
<Heading as='h2' textAlign='start' mt='16 !important' mb={4} {...header2}>
|
||||
{children}
|
||||
</Heading>
|
||||
);
|
||||
},
|
||||
h3: ({ children }: any) => {
|
||||
return (
|
||||
<Heading as='h3' mt={5} mb={2.5} {...header3}>
|
||||
{children}
|
||||
</Heading>
|
||||
);
|
||||
},
|
||||
h4: ({ children }: any) => {
|
||||
return (
|
||||
<Heading as='h4' mb={2.5} {...header4}>
|
||||
{children}
|
||||
</Heading>
|
||||
);
|
||||
},
|
||||
// tables
|
||||
table: ({ children }: any) => (
|
||||
<Flex maxW='min(100%, 100vw)' overflowX='scroll'>
|
||||
<Table
|
||||
variant='striped'
|
||||
colorScheme='greenAlpha'
|
||||
border='1px'
|
||||
borderColor='blackAlpha.50'
|
||||
my={6}
|
||||
size={{ base: 'sm', lg: 'md' }}
|
||||
w='auto'
|
||||
>
|
||||
{children}
|
||||
</Table>
|
||||
</Flex>
|
||||
),
|
||||
// pre
|
||||
pre: ({ children }: any) => (
|
||||
<Stack mb={5}>
|
||||
<pre>{children}</pre>
|
||||
</Stack>
|
||||
),
|
||||
// code
|
||||
code: ({ children, ...props }: any) => <Code {...props}>{children}</Code>,
|
||||
// list
|
||||
ul: ({ children }: any) => {
|
||||
return (
|
||||
<UnorderedList mb={7} px={4}>
|
||||
{children}
|
||||
</UnorderedList>
|
||||
);
|
||||
},
|
||||
ol: ({ children }: any) => {
|
||||
return (
|
||||
<OrderedList mb={7} px={4}>
|
||||
{children}
|
||||
</OrderedList>
|
||||
);
|
||||
},
|
||||
li: ({ children }: any) => {
|
||||
return <ListItem color='primary'>{children}</ListItem>;
|
||||
}
|
||||
};
|
||||
|
||||
export default MDXComponents;
|
||||
|
|
@ -1,15 +1,19 @@
|
|||
import { Link, Table, Thead, Tr, Th, TableContainer, Text, Tbody, Td } from '@chakra-ui/react';
|
||||
import { FC } from 'react';
|
||||
import { ReleaseData } from '../../types';
|
||||
import { OpenPGPSignaturesData, ReleaseData } from '../../types';
|
||||
import { getParsedDate } from '../../utils';
|
||||
|
||||
interface Props {
|
||||
columnHeaders: string[];
|
||||
// TODO: update data type
|
||||
data: any;
|
||||
}
|
||||
|
||||
export const DataTable: FC<Props> = ({ columnHeaders, data }) => {
|
||||
// {} is a backup object for initial render where data is still undefined, to avoid errors
|
||||
const dataType = Object.keys(data[0] || {})?.includes('release')
|
||||
? 'Releases'
|
||||
: 'OpenPGP Signatures';
|
||||
|
||||
return (
|
||||
<TableContainer
|
||||
// Note: This wont work on firefox, we are ok with this.
|
||||
|
|
@ -46,7 +50,8 @@ export const DataTable: FC<Props> = ({ columnHeaders, data }) => {
|
|||
</Thead>
|
||||
|
||||
<Tbody>
|
||||
{data.map((r: ReleaseData, idx: number) => {
|
||||
{dataType === 'Releases' &&
|
||||
data.map((r: ReleaseData, idx: number) => {
|
||||
return (
|
||||
<Tr
|
||||
key={idx}
|
||||
|
|
@ -79,6 +84,38 @@ export const DataTable: FC<Props> = ({ columnHeaders, data }) => {
|
|||
);
|
||||
}
|
||||
|
||||
return (
|
||||
<Td key={idx} px={4} textStyle='hero-text-small'>
|
||||
<Text>{item[1]}</Text>
|
||||
</Td>
|
||||
);
|
||||
})}
|
||||
</Tr>
|
||||
);
|
||||
})}
|
||||
|
||||
{dataType === 'OpenPGP Signatures' &&
|
||||
data.map((o: OpenPGPSignaturesData, idx: number) => {
|
||||
return (
|
||||
<Tr
|
||||
key={idx}
|
||||
transition={'all 0.5s'}
|
||||
_hover={{ background: 'button-bg', transition: 'all 0.5s' }}
|
||||
>
|
||||
{Object.entries(o).map((item, idx) => {
|
||||
if (item[0] === 'openpgp key') {
|
||||
const label = item[1].label;
|
||||
const url = item[1].url;
|
||||
|
||||
return (
|
||||
<Td key={idx} px={4} textStyle='hero-text-small'>
|
||||
<Link _hover={{ textDecoration: 'none' }} href={url} isExternal>
|
||||
<Text color='primary'>{label}</Text>
|
||||
</Link>
|
||||
</Td>
|
||||
);
|
||||
}
|
||||
|
||||
return (
|
||||
<Td key={idx} px={4} textStyle='hero-text-small'>
|
||||
<Text>{item[1]}</Text>
|
||||
|
|
|
|||
|
|
@ -30,7 +30,7 @@ export const Header: FC = () => {
|
|||
>
|
||||
<NextLink href={'/'} passHref>
|
||||
<Link _hover={{ textDecoration: 'none' }}>
|
||||
<Text textStyle='header-font'>go-ethereum</Text>
|
||||
<Text textStyle='header-font' whiteSpace='nowrap'>go-ethereum</Text>
|
||||
</Link>
|
||||
</NextLink>
|
||||
</Stack>
|
||||
|
|
|
|||
|
|
@ -0,0 +1,33 @@
|
|||
import { Breadcrumb, BreadcrumbItem, BreadcrumbLink, Stack } from '@chakra-ui/react';
|
||||
import NextLink from 'next/link';
|
||||
import { useRouter } from 'next/router';
|
||||
import { FC } from 'react';
|
||||
|
||||
export const Breadcrumbs: FC = () => {
|
||||
const router = useRouter();
|
||||
|
||||
let pathSplit = router.asPath.split('/');
|
||||
pathSplit = pathSplit.splice(1, pathSplit.length);
|
||||
|
||||
return (
|
||||
<>
|
||||
{router.asPath !== '/docs' ? (
|
||||
<Breadcrumb>
|
||||
{pathSplit.map((path: string, idx: number) => {
|
||||
return (
|
||||
<BreadcrumbItem key={path}>
|
||||
<NextLink href={`/${pathSplit.slice(0, idx + 1).join('/')}`} passHref>
|
||||
<BreadcrumbLink color={idx + 1 === pathSplit.length ? 'body' : 'primary'}>
|
||||
{path}
|
||||
</BreadcrumbLink>
|
||||
</NextLink>
|
||||
</BreadcrumbItem>
|
||||
);
|
||||
})}
|
||||
</Breadcrumb>
|
||||
) : (
|
||||
<Stack h='24px'></Stack>
|
||||
)}
|
||||
</>
|
||||
);
|
||||
};
|
||||
|
|
@ -73,5 +73,11 @@ export const Code: React.FC<Props> = ({ className, children, inline }) => {
|
|||
{content}
|
||||
</SyntaxHighlighter>
|
||||
);
|
||||
return <Stack>{content}</Stack>;
|
||||
return (
|
||||
<Stack>
|
||||
<ChakraCode overflow='auto' p={6} background='terminal-bg' color='terminal-text'>
|
||||
{content}
|
||||
</ChakraCode>
|
||||
</Stack>
|
||||
);
|
||||
};
|
||||
|
|
|
|||
|
|
@ -0,0 +1,81 @@
|
|||
import { FC } from 'react';
|
||||
import {
|
||||
Accordion,
|
||||
AccordionButton,
|
||||
AccordionItem,
|
||||
AccordionPanel,
|
||||
Center,
|
||||
Link,
|
||||
Stack,
|
||||
Text
|
||||
} from '@chakra-ui/react';
|
||||
import { AddIcon, MinusIcon } from '@chakra-ui/icons';
|
||||
import NextLink from 'next/link';
|
||||
|
||||
import { LinksList } from './';
|
||||
|
||||
import { NavLink } from '../../../types';
|
||||
|
||||
interface Props {
|
||||
navLinks: NavLink[];
|
||||
}
|
||||
|
||||
export const DocsLinks: FC<Props> = ({ navLinks }) => (
|
||||
<Stack border='2px' borderColor='primary'>
|
||||
{navLinks.map(({ id, to, items }, idx) => {
|
||||
return (
|
||||
<Accordion key={id} allowToggle mt='0 !important' defaultIndex={[0]}>
|
||||
<AccordionItem border='none'>
|
||||
{({ isExpanded }) => (
|
||||
<>
|
||||
<AccordionButton
|
||||
borderBottom={navLinks.length - 1 === idx ? 'none' : '2px'}
|
||||
p={0}
|
||||
borderColor='primary'
|
||||
justifyContent='space-between'
|
||||
placeContent='flex-end'
|
||||
bg='button-bg'
|
||||
>
|
||||
<Stack
|
||||
p={4}
|
||||
borderRight={items ? '2px' : 'none'}
|
||||
borderColor='primary'
|
||||
w='100%'
|
||||
bg='bg'
|
||||
>
|
||||
{to ? (
|
||||
<NextLink href={to} passHref>
|
||||
<Link>
|
||||
<Text textStyle='docs-nav-dropdown'>{id}</Text>
|
||||
</Link>
|
||||
</NextLink>
|
||||
) : (
|
||||
<Text textStyle='docs-nav-dropdown'>{id}</Text>
|
||||
)}
|
||||
</Stack>
|
||||
|
||||
{items && (
|
||||
<Stack minW='61px'>
|
||||
<Center>
|
||||
{isExpanded ? (
|
||||
<MinusIcon w='20px' h='20px' color='primary' />
|
||||
) : (
|
||||
<AddIcon w='20px' h='20px' color='primary' />
|
||||
)}
|
||||
</Center>
|
||||
</Stack>
|
||||
)}
|
||||
</AccordionButton>
|
||||
{items && (
|
||||
<AccordionPanel borderBottom='2px solid' borderColor='primary' px={0} py={4}>
|
||||
<LinksList links={items} />
|
||||
</AccordionPanel>
|
||||
)}
|
||||
</>
|
||||
)}
|
||||
</AccordionItem>
|
||||
</Accordion>
|
||||
);
|
||||
})}
|
||||
</Stack>
|
||||
);
|
||||
|
|
@ -0,0 +1,59 @@
|
|||
import { FC } from 'react';
|
||||
import {
|
||||
Accordion,
|
||||
AccordionButton,
|
||||
AccordionIcon,
|
||||
AccordionItem,
|
||||
AccordionPanel,
|
||||
Stack,
|
||||
Text
|
||||
} from '@chakra-ui/react';
|
||||
import { DocsLinks } from './DocsLinks';
|
||||
|
||||
import { NavLink } from '../../../types';
|
||||
|
||||
interface Props {
|
||||
navLinks: NavLink[];
|
||||
}
|
||||
|
||||
export const DocsNav: FC<Props> = ({ navLinks }) => {
|
||||
return (
|
||||
<Stack w={{ base: '100%', lg: 72 }}>
|
||||
<Stack display={{ base: 'none', lg: 'block' }}>
|
||||
<DocsLinks navLinks={navLinks} />
|
||||
</Stack>
|
||||
|
||||
<Stack display={{ base: 'block', lg: 'none' }}>
|
||||
<Accordion allowToggle>
|
||||
<AccordionItem border='none'>
|
||||
<AccordionButton
|
||||
display='flex'
|
||||
py={4}
|
||||
px={8}
|
||||
border='2px'
|
||||
borderColor='primary'
|
||||
placeContent='space-between'
|
||||
bg='button-bg'
|
||||
_hover={{
|
||||
bg: 'primary',
|
||||
color: 'bg'
|
||||
}}
|
||||
_expanded={{
|
||||
bg: 'primary',
|
||||
color: 'bg'
|
||||
}}
|
||||
>
|
||||
<Text as='h4' textStyle='docs-nav-dropdown'>
|
||||
Documentation
|
||||
</Text>
|
||||
<AccordionIcon />
|
||||
</AccordionButton>
|
||||
<AccordionPanel p={0}>
|
||||
<DocsLinks navLinks={navLinks} />
|
||||
</AccordionPanel>
|
||||
</AccordionItem>
|
||||
</Accordion>
|
||||
</Stack>
|
||||
</Stack>
|
||||
);
|
||||
};
|
||||
|
|
@ -0,0 +1,44 @@
|
|||
import { FC } from 'react';
|
||||
import { Divider, Link, Stack, Text } from '@chakra-ui/react';
|
||||
import NextLink from 'next/link';
|
||||
|
||||
import { parseHeadingId } from '../../../utils/parseHeadingId';
|
||||
import { useActiveHash } from '../../../hooks/useActiveHash';
|
||||
|
||||
interface Props {
|
||||
content: string;
|
||||
}
|
||||
|
||||
export const DocumentNav: FC<Props> = ({ content }) => {
|
||||
const parsedHeadings = content
|
||||
.split('\n\n')
|
||||
.map(item => item.replace(/[\n\r]/g, ''))
|
||||
.filter(item => item.startsWith('#'))
|
||||
.map(item => parseHeadingId([item]))
|
||||
.filter(item => item);
|
||||
|
||||
const activeHash = useActiveHash(parsedHeadings.map(heading => heading!.headingId));
|
||||
|
||||
return (
|
||||
<Stack position='sticky' top='4'>
|
||||
<Text as='h5' textStyle='document-nav-title'>
|
||||
on this page
|
||||
</Text>
|
||||
<Divider borderColor='primary' my={`4 !important`} />
|
||||
{parsedHeadings.map((heading, idx) => {
|
||||
return (
|
||||
<NextLink key={`${idx} ${heading?.title}`} href={`#${heading?.headingId}`}>
|
||||
<Link m={0}>
|
||||
<Text
|
||||
color={activeHash === heading?.headingId ? 'body' : 'primary'}
|
||||
textStyle='document-nav-link'
|
||||
>
|
||||
{heading?.title}
|
||||
</Text>
|
||||
</Link>
|
||||
</NextLink>
|
||||
);
|
||||
})}
|
||||
</Stack>
|
||||
);
|
||||
};
|
||||
|
|
@ -0,0 +1,35 @@
|
|||
import { FC } from 'react';
|
||||
import { Link, Stack, Text } from '@chakra-ui/react';
|
||||
import NextLink from 'next/link';
|
||||
|
||||
import { NavLink } from '../../../types';
|
||||
|
||||
interface LinksListProps {
|
||||
links: NavLink[];
|
||||
}
|
||||
|
||||
export const LinksList: FC<LinksListProps> = ({ links }) => (
|
||||
<Stack px={4}>
|
||||
{links.map(({ id, to, items }) => {
|
||||
return to ? (
|
||||
<Stack key={id}>
|
||||
<NextLink href={to} passHref key={id}>
|
||||
<Link>
|
||||
<Text textStyle='docs-nav-links' color={items ? 'primary' : 'body'}>
|
||||
{id}
|
||||
</Text>
|
||||
</Link>
|
||||
</NextLink>
|
||||
{items && <LinksList links={items} />}
|
||||
</Stack>
|
||||
) : (
|
||||
<Stack key={id}>
|
||||
<Text textStyle='docs-nav-links' color={items ? 'primary' : 'body'}>
|
||||
{id}
|
||||
</Text>
|
||||
{items && <LinksList links={items} />}
|
||||
</Stack>
|
||||
);
|
||||
})}
|
||||
</Stack>
|
||||
);
|
||||
|
|
@ -0,0 +1,153 @@
|
|||
import {
|
||||
Flex,
|
||||
Heading,
|
||||
Link,
|
||||
ListItem,
|
||||
OrderedList,
|
||||
Stack,
|
||||
Table,
|
||||
Text,
|
||||
UnorderedList
|
||||
} from '@chakra-ui/react';
|
||||
import NextLink from 'next/link';
|
||||
|
||||
import { Code, Note } from '.';
|
||||
import { textStyles } from '../../../theme/foundations';
|
||||
import { parseHeadingId } from '../../../utils/parseHeadingId';
|
||||
|
||||
const { header1, header2, header3, header4 } = textStyles;
|
||||
|
||||
const MDComponents = {
|
||||
// paragraphs
|
||||
p: ({ children }: any) => {
|
||||
return (
|
||||
<Text mb='7 !important' lineHeight={1.5}>
|
||||
{children}
|
||||
</Text>
|
||||
);
|
||||
},
|
||||
// links
|
||||
a: ({ children, href }: any) => {
|
||||
return (
|
||||
<NextLink href={href} passHref>
|
||||
<Link
|
||||
isExternal={href.startsWith('http') && !href.includes('geth.ethereum.org')}
|
||||
variant='light'
|
||||
>
|
||||
{children}
|
||||
</Link>
|
||||
</NextLink>
|
||||
);
|
||||
},
|
||||
// headings
|
||||
h1: ({ children }: any) => {
|
||||
const heading = parseHeadingId(children);
|
||||
|
||||
return heading ? (
|
||||
<Heading as='h1' textAlign='start' mb='5 !important' {...header1} id={heading.headingId}>
|
||||
{heading.children}
|
||||
</Heading>
|
||||
) : (
|
||||
<Heading as='h1' textAlign='start' mb='5 !important' {...header1}>
|
||||
{children}
|
||||
</Heading>
|
||||
);
|
||||
},
|
||||
h2: ({ children }: any) => {
|
||||
const heading = parseHeadingId(children);
|
||||
|
||||
return heading ? (
|
||||
<Heading
|
||||
as='h2'
|
||||
textAlign='start'
|
||||
mt='16 !important'
|
||||
mb='4 !important'
|
||||
{...header2}
|
||||
id={heading.headingId}
|
||||
>
|
||||
{heading.children}
|
||||
</Heading>
|
||||
) : (
|
||||
<Heading as='h2' textAlign='start' mt='16 !important' mb='4 !important' {...header2}>
|
||||
{children}
|
||||
</Heading>
|
||||
);
|
||||
},
|
||||
h3: ({ children }: any) => {
|
||||
const heading = parseHeadingId(children);
|
||||
|
||||
return heading ? (
|
||||
<Heading as='h3' mt='5 !important' mb='2.5 !important' {...header3} id={heading.headingId}>
|
||||
{heading.children}
|
||||
</Heading>
|
||||
) : (
|
||||
<Heading as='h3' mt='5 !important' mb='2.5 !important' {...header3}>
|
||||
{children}
|
||||
</Heading>
|
||||
);
|
||||
},
|
||||
h4: ({ children }: any) => {
|
||||
const heading = parseHeadingId(children);
|
||||
|
||||
return heading ? (
|
||||
<Heading as='h4' mb='2.5 !important' {...header4} id={heading.headingId}>
|
||||
{heading.children}
|
||||
</Heading>
|
||||
) : (
|
||||
<Heading as='h4' mb='2.5 !important' {...header4}>
|
||||
{children}
|
||||
</Heading>
|
||||
);
|
||||
},
|
||||
// tables
|
||||
table: ({ children }: any) => (
|
||||
<Flex maxW='min(100%, 100vw)' overflowX='auto'>
|
||||
<Table
|
||||
variant='striped'
|
||||
colorScheme='greenAlpha'
|
||||
border='1px'
|
||||
borderColor='blackAlpha.50'
|
||||
my='6 !important'
|
||||
size={{ base: 'sm', lg: 'md' }}
|
||||
w='auto'
|
||||
>
|
||||
{children}
|
||||
</Table>
|
||||
</Flex>
|
||||
),
|
||||
// pre
|
||||
pre: ({ children }: any) => (
|
||||
<Stack mb={5}>
|
||||
<pre>{children}</pre>
|
||||
</Stack>
|
||||
),
|
||||
// code
|
||||
code: ({ children, ...props }: any) => <Code {...props}>{children}</Code>,
|
||||
// list
|
||||
ul: ({ children }: any) => {
|
||||
return (
|
||||
<Stack>
|
||||
<UnorderedList mb={7} px={4}>
|
||||
{children}
|
||||
</UnorderedList>
|
||||
</Stack>
|
||||
);
|
||||
},
|
||||
ol: ({ children }: any) => {
|
||||
return (
|
||||
<Stack>
|
||||
<OrderedList mb={7} px={4}>
|
||||
{children}
|
||||
</OrderedList>
|
||||
</Stack>
|
||||
);
|
||||
},
|
||||
li: ({ children }: any) => {
|
||||
return <ListItem color='primary'>{children}</ListItem>;
|
||||
},
|
||||
note: ({ children }: any) => {
|
||||
return <Note>{children}</Note>;
|
||||
}
|
||||
};
|
||||
|
||||
export default MDComponents;
|
||||
|
|
@ -0,0 +1,17 @@
|
|||
import { FC } from 'react';
|
||||
import { Stack, Text } from '@chakra-ui/react';
|
||||
|
||||
interface Props {
|
||||
children: string[];
|
||||
}
|
||||
|
||||
export const Note: FC<Props> = ({ children }) => {
|
||||
return (
|
||||
<Stack w='100%' bg='button-bg' border='2px' borderColor='primary' p={4}>
|
||||
<Text as='h4' textStyle='header4'>
|
||||
Note
|
||||
</Text>
|
||||
<Text textStyle='note-text'>{children}</Text>
|
||||
</Stack>
|
||||
);
|
||||
};
|
||||
|
|
@ -0,0 +1,8 @@
|
|||
export * from './Breadcrumbs';
|
||||
export * from './Code';
|
||||
export * from './DocsLinks';
|
||||
export * from './DocsNav';
|
||||
export * from './DocumentNav';
|
||||
export * from './LinkList';
|
||||
export * from './Note';
|
||||
export { default } from './MDComponents';
|
||||
|
|
@ -1 +0,0 @@
|
|||
export * from './Code';
|
||||
|
|
@ -1,4 +1,4 @@
|
|||
import { Box, Button, Center, Grid, HStack, Image, Link, Stack, Text } from '@chakra-ui/react';
|
||||
import { Box, Button, Center, Grid, HStack, Link, Stack, Text } from '@chakra-ui/react';
|
||||
import { FC } from 'react';
|
||||
import NextLink from 'next/link';
|
||||
|
||||
|
|
@ -32,7 +32,7 @@ export const DownloadsHero: FC<DownloadsHero> = ({
|
|||
|
||||
return (
|
||||
<Grid
|
||||
border='3px solid'
|
||||
border='2px solid'
|
||||
borderColor='primary'
|
||||
p={4}
|
||||
templateColumns={{ base: 'repeat(1, 1fr)', lg: '1fr 430px' }}
|
||||
|
|
|
|||
|
|
@ -1,27 +0,0 @@
|
|||
import { Breadcrumb, BreadcrumbItem, BreadcrumbLink } from '@chakra-ui/react';
|
||||
import NextLink from 'next/link';
|
||||
import { useRouter } from 'next/router';
|
||||
import { FC } from 'react';
|
||||
|
||||
export const Breadcrumbs: FC = () => {
|
||||
const router = useRouter();
|
||||
|
||||
let pathSplit = router.asPath.split('/');
|
||||
pathSplit = pathSplit.splice(1, pathSplit.length);
|
||||
|
||||
return (
|
||||
<Breadcrumb>
|
||||
{pathSplit.map((path: string, idx: number) => {
|
||||
return (
|
||||
<BreadcrumbItem key={path}>
|
||||
<NextLink href={`/${pathSplit.slice(0, idx + 1).join('/')}`} passHref>
|
||||
<BreadcrumbLink color={idx + 1 === pathSplit.length ? 'body' : 'primary'}>
|
||||
{path}
|
||||
</BreadcrumbLink>
|
||||
</NextLink>
|
||||
</BreadcrumbItem>
|
||||
);
|
||||
})}
|
||||
</Breadcrumb>
|
||||
);
|
||||
};
|
||||
|
|
@ -1 +0,0 @@
|
|||
export * from './Breadcrumbs';
|
||||
|
|
@ -1 +0,0 @@
|
|||
export { default } from './MDXComponents';
|
||||
|
|
@ -12,7 +12,7 @@ interface Props {
|
|||
|
||||
export const Layout: FC<Props> = ({ children }) => {
|
||||
return (
|
||||
<Container maxW={{ base: 'container.sm', md: 'container.2xl' }} my={{ base: 4, md: 7 }}>
|
||||
<Container maxW={{ base: 'full', md: 'container.2xl' }} my={{ base: 4, md: 7 }}>
|
||||
<Header />
|
||||
|
||||
{children}
|
||||
|
|
|
|||
|
|
@ -71,6 +71,83 @@ export const DOWNLOADS_OPENPGP_BUILD_HEADERS = [
|
|||
'OpenPGP Key',
|
||||
'Fingerprint'
|
||||
];
|
||||
export const DOWNLOADS_OPENPGP_SIGNATURES = [
|
||||
{
|
||||
'build server': 'Android Builder',
|
||||
'unique id': 'Go Ethereum Android Builder <geth-ci@ethereum.org>',
|
||||
'openpgp key': {
|
||||
label: 'F9585DE6',
|
||||
url: 'https://keyserver.ubuntu.com/pks/lookup?op=get&search=0x70AD154BF9585DE6'
|
||||
},
|
||||
fingerprint: '8272 1824 F4D7 46E0 B5A7 AB95 70AD 154B F958 5DE6'
|
||||
},
|
||||
{
|
||||
'build server': 'iOS Builder',
|
||||
'unique id': 'Go Ethereum iOS Builder <geth-ci@ethereum.org>',
|
||||
'openpgp key': {
|
||||
label: 'C2FF8BBF',
|
||||
url: 'https://keyserver.ubuntu.com/pks/lookup?op=get&search=0xF29DEFAFC2FF8BBF'
|
||||
},
|
||||
fingerprint: '70AD EB8F 3BC6 6F69 0256 4D88 F29D EFAF C2FF 8BBF'
|
||||
},
|
||||
{
|
||||
'build server': 'Linux Builder',
|
||||
'unique id': 'Go Ethereum Linux Builder <geth-ci@ethereum.org>',
|
||||
'openpgp key': {
|
||||
label: '9BA28146',
|
||||
url: 'https://keyserver.ubuntu.com/pks/lookup?op=get&search=0xA61A13569BA28146'
|
||||
},
|
||||
fingerprint: 'FDE5 A1A0 44FA 13D2 F7AD A019 A61A 1356 9BA2 8146'
|
||||
},
|
||||
{
|
||||
'build server': 'macOS Builder',
|
||||
'unique id': 'Go Ethereum macOS Builder <geth-ci@ethereum.org>',
|
||||
'openpgp key': {
|
||||
label: '7B9E2481',
|
||||
url: 'https://keyserver.ubuntu.com/pks/lookup?op=get&search=0x558915E17B9E2481'
|
||||
},
|
||||
fingerprint: '6D1D AF5D 0534 DEA6 1AA7 7AD5 5589 15E1 7B9E 2481'
|
||||
},
|
||||
{
|
||||
'build server': 'Windows Builder',
|
||||
'unique id': 'Go Ethereum Windows Builder <geth-ci@ethereum.org>',
|
||||
'openpgp key': {
|
||||
label: 'D2A67EAC',
|
||||
url: 'https://keyserver.ubuntu.com/pks/lookup?op=get&search=0x9417309ED2A67EAC'
|
||||
},
|
||||
fingerprint: 'C4B3 2BB1 F603 4241 A9E6 50A1 9417 309E D2A6 7EAC'
|
||||
}
|
||||
];
|
||||
export const DOWNLOADS_DEVELOPERS_DATA = [
|
||||
{
|
||||
developer: 'Felix Lange',
|
||||
'unique id': 'Felix Lange <fjl@ethereum.org>',
|
||||
'openpgp key': {
|
||||
label: 'E058A81C',
|
||||
url: 'https://keyserver.ubuntu.com/pks/lookup?op=get&search=0x337E68FCE058A81C'
|
||||
},
|
||||
fingerprint: '6047 0B71 5865 392D E43D 75A3 337E 68FC E058 A81C'
|
||||
},
|
||||
{
|
||||
developer: 'Martin Holst Swende',
|
||||
'unique id': 'Martin Holst Swende <martin.swende@ethereum.org>',
|
||||
'openpgp key': {
|
||||
label: '05A5DDF0',
|
||||
url: 'https://keyserver.ubuntu.com/pks/lookup?op=get&search=0x683B438C05A5DDF0'
|
||||
},
|
||||
fingerprint: 'CA99 ABB5 B36E 24AD 5DA0 FD40 683B 438C 05A5 DDF0'
|
||||
},
|
||||
{
|
||||
developer: 'Péter Szilágyi',
|
||||
'unique id': 'Péter Szilágyi <peter@ethereum.org>',
|
||||
'openpgp key': {
|
||||
label: '1CCB7DD2',
|
||||
url: 'https://keyserver.ubuntu.com/pks/lookup?op=get&search=0x119A76381CCB7DD2'
|
||||
},
|
||||
fingerprint: '4948 43FC E822 1C4C 86AB 5E2F 119A 7638 1CCB 7DD2'
|
||||
}
|
||||
];
|
||||
|
||||
export const DOWNLOADS_OPENPGP_DEVELOPER_HEADERS = [
|
||||
'Developer',
|
||||
'Unique ID',
|
||||
|
|
|
|||
|
|
@ -0,0 +1,149 @@
|
|||
- id: Getting started
|
||||
to: /docs/getting-started
|
||||
items:
|
||||
- id: Hardware requirements
|
||||
to: /docs/getting-started/hardware-requirements
|
||||
- id: Installing Geth
|
||||
to: /docs/getting-started/installing-geth
|
||||
- id: Consensus clients
|
||||
to: /docs/getting-started/consensus-clients
|
||||
- id: Fundamentals
|
||||
to: /docs/fundamentals
|
||||
items:
|
||||
- id: Node architecture
|
||||
to: /docs/fundamentals/node-architecture
|
||||
- id: Command-line options
|
||||
to: /docs/fundamentals/command-line-options
|
||||
- id: Security
|
||||
to: /docs/fundamentals/security
|
||||
- id: Sync-modes
|
||||
to: /docs/fundamentals/sync-modes
|
||||
- id: Account management
|
||||
to: /docs/fundamentals/account-management
|
||||
- id: Backup restore
|
||||
to: /docs/fundamentals/backup-restore
|
||||
- id: Logs
|
||||
to: /docs/fundamentals/logs
|
||||
- id: Peer-to-peer
|
||||
to: /docs/fundamentals/peer-to-peer
|
||||
- id: Pruning
|
||||
to: /docs/fundamentals/pruning
|
||||
- id: Light client
|
||||
to: /docs/fundamentals/les
|
||||
- id: Mining
|
||||
to: /docs/fundamentals/mining
|
||||
- id: Interacting with Geth
|
||||
items:
|
||||
- id: JSON-RPC Server
|
||||
to: /docs/interacting-with-geth/rpc
|
||||
items:
|
||||
- id: Batch requests
|
||||
to: /docs/interacting-with-geth/rpc/batch
|
||||
- id: GraphQL server
|
||||
to: /docs/interacting-with-geth/rpc/graphql
|
||||
- id: admin Namespace
|
||||
to: /docs/interacting-with-geth/rpc/ns-admin
|
||||
- id: clique Namespace
|
||||
to: /docs/interacting-with-geth/rpc/ns-clique
|
||||
- id: debug Namespace
|
||||
to: /docs/interacting-with-geth/rpc/ns-debug
|
||||
- id: eth Namespace
|
||||
to: /docs/interacting-with-geth/rpc/ns-eth
|
||||
- id: les Namespace
|
||||
to: /docs/interacting-with-geth/rpc/ns-les
|
||||
- id: miner Namespace
|
||||
to: /docs/interacting-with-geth/rpc/ns-miner
|
||||
- id: net Namespace
|
||||
to: /docs/interacting-with-geth/rpc/ns-net
|
||||
- id: Personal namespace deprecation notes
|
||||
to: /docs/interacting-with-geth/rpc/ns-personal-deprecation
|
||||
- id: Personal Namespace
|
||||
to: /docs/interacting-with-geth/rpc/ns-personal
|
||||
- id: txpool Namespace
|
||||
to: /docs/interacting-with-geth/rpc/ns-txpool
|
||||
- id: Objects
|
||||
to: /docs/interacting-with-geth/rpc/objects
|
||||
- id: Real-time Events
|
||||
to: /docs/interacting-with-geth/rpc/pubsub
|
||||
- id: JavaScript Console
|
||||
to: /docs/interacting-with-geth/javascript-console
|
||||
- id: 'JavaScript Console 2: Contracts'
|
||||
to: /docs/interacting-with-geth/javascript-console-contracts
|
||||
- id: Developers
|
||||
to: /docs/developers
|
||||
items:
|
||||
- id: Dapp developers
|
||||
items:
|
||||
- id: Go API
|
||||
to: /docs/developers/dapp-developer/native
|
||||
- id: Go Account Management
|
||||
to: /docs/developers/dapp-developer/native-accounts
|
||||
- id: Go Contract Bindings
|
||||
to: /docs/developers/dapp-developer/native-bindings
|
||||
- id: Geth for Mobile
|
||||
to: /docs/developers/dapp-developer/mobile
|
||||
- id: EVM tracing
|
||||
to: /docs/developers/evm-tracing
|
||||
items:
|
||||
- id: Basic traces
|
||||
to: /docs/developers/evm-tracing/basic-traces
|
||||
- id: Built-in tracers
|
||||
to: /docs/developers/evm-tracing/built-in-tracers
|
||||
- id: Custom EVM tracer
|
||||
to: /docs/developers/evm-tracing/custom-tracer
|
||||
- id: Tutorial for Javascript tracing
|
||||
to: /docs/developers/evm-tracing/javascript-tutorial
|
||||
- id: Geth developer
|
||||
items:
|
||||
- id: Developer guide
|
||||
to: /docs/developers/geth-developer/dev-guide
|
||||
- id: Developer mode
|
||||
to: /docs/developers/geth-developer/dev-mode
|
||||
- id: Disclosures
|
||||
to: /docs/developers/geth-developer/disclosures
|
||||
- id: Issue handling workflow
|
||||
to: /docs/developers/geth-developer/issue-handling-workflow
|
||||
- id: DNS discovery setup guide
|
||||
to: /docs/developers/geth-developer/dns-discovery-setup
|
||||
- id: Code review guidelines
|
||||
to: /docs/developers/geth-developer/code-review-guidelines
|
||||
- id: Private networks
|
||||
to: /docs/developers/geth-developer/private-network
|
||||
- id: Contributing
|
||||
to: /docs/developers/contributing
|
||||
- id: Monitoring
|
||||
items:
|
||||
- id: Dashboards
|
||||
to: /docs/monitoring/dashboards
|
||||
- id: Ethstats
|
||||
to: /docs/monitoring/ethstats
|
||||
- id: Metrics
|
||||
to: /docs/monitoring/metrics
|
||||
- id: Tools
|
||||
items:
|
||||
- id: Clef
|
||||
items:
|
||||
- id: Introduction
|
||||
to: /docs/tools/clef/introduction
|
||||
- id: APIs
|
||||
to: /docs/tools/clef/apis
|
||||
- id: Rules
|
||||
to: /docs/tools/clef/rules
|
||||
- id: Setup
|
||||
to: /docs/tools/clef/setup
|
||||
- id: Datatypes
|
||||
to: /docs/tools/clef/datatypes
|
||||
- id: Tutorial
|
||||
to: /docs/tools/clef/tutorial
|
||||
- id: Clique-signing
|
||||
to: /docs/tools/clef/clique-signing
|
||||
- id: puppeth
|
||||
to: /docs/tools/puppeth
|
||||
- id: Abigen
|
||||
to: /docs/tools/abigen
|
||||
- id: devp2p
|
||||
to: /docs/tools/devp2p
|
||||
- id: FAQs
|
||||
to: /docs/faq
|
||||
- id: Resources
|
||||
to: /docs/resources
|
||||
|
|
@ -1,32 +0,0 @@
|
|||
export const pgpBuildTestData = [
|
||||
{
|
||||
'build server': 'Android Builder',
|
||||
'unique id': 'Go Ethereum Android Builder <geth-ci@ethereum.org>',
|
||||
'openpgp key': 'F9585DE6',
|
||||
fingerprint: '8272 1824 F4D7 46E0 B5A7 AB95 70AD 154B F958 5DE6'
|
||||
},
|
||||
{
|
||||
'build server': 'iOS Builder',
|
||||
'unique id': 'Go Ethereum iOS Builder <geth-ci@ethereum.org>',
|
||||
'openpgp key': 'F9585DE6',
|
||||
fingerprint: '8272 1824 F4D7 46E0 B5A7 AB95 70AD 154B F958 5DE6'
|
||||
},
|
||||
{
|
||||
'build server': 'Linux Builder',
|
||||
'unique id': 'Go Ethereum Linux Builder <geth-ci@ethereum.org>',
|
||||
'openpgp key': 'F9585DE6',
|
||||
fingerprint: '8272 1824 F4D7 46E0 B5A7 AB95 70AD 154B F958 5DE6'
|
||||
},
|
||||
{
|
||||
'build server': 'macOS Builder',
|
||||
'unique id': 'Go Ethereum macOS Builder <geth-ci@ethereum.org>',
|
||||
'openpgp key': 'F9585DE6',
|
||||
fingerprint: '8272 1824 F4D7 46E0 B5A7 AB95 70AD 154B F958 5DE6'
|
||||
},
|
||||
{
|
||||
'build server': 'Windows Builder',
|
||||
'unique id': 'Go Ethereum Windows Builder <geth-ci@ethereum.org>',
|
||||
'openpgp key': 'F9585DE6',
|
||||
fingerprint: '8272 1824 F4D7 46E0 B5A7 AB95 70AD 154B F958 5DE6'
|
||||
}
|
||||
];
|
||||
|
|
@ -1,20 +0,0 @@
|
|||
export const pgpDeveloperTestData = [
|
||||
{
|
||||
developer: 'Felix Lange',
|
||||
'unique id': 'Felix Lange <fjl@ethereum.org>',
|
||||
'openpgp key': 'F9585DE6',
|
||||
fingerprint: '8272 1824 F4D7 46E0 B5A7 AB95 70AD 154B F958 5DE6'
|
||||
},
|
||||
{
|
||||
developer: 'Martin Holst Swende',
|
||||
'unique id': 'Martin Holst Swende <martin.swende@ethereum.org>',
|
||||
'openpgp key': 'F9585DE6',
|
||||
fingerprint: '8272 1824 F4D7 46E0 B5A7 AB95 70AD 154B F958 5DE6'
|
||||
},
|
||||
{
|
||||
developer: 'Péter Szilágyi',
|
||||
'unique id': 'Péter Szilágyi <peter@ethereum.org>',
|
||||
'openpgp key': 'F9585DE6',
|
||||
fingerprint: '8272 1824 F4D7 46E0 B5A7 AB95 70AD 154B F958 5DE6'
|
||||
}
|
||||
];
|
||||
|
|
@ -0,0 +1,42 @@
|
|||
import { useState, useEffect } from 'react';
|
||||
|
||||
/**
|
||||
* A hook to determine which section of the page is currently in the viewport.
|
||||
* @param {*} itemIds Array of document ids to observe
|
||||
* @param {*} rootMargin
|
||||
* @returns id of the element currently in viewport
|
||||
*/
|
||||
export const useActiveHash = (itemIds: Array<string>, rootMargin = `0% 0% -80% 0%`): string => {
|
||||
const [activeHash, setActiveHash] = useState(``);
|
||||
|
||||
useEffect(() => {
|
||||
const observer = new IntersectionObserver(
|
||||
entries => {
|
||||
entries.forEach(entry => {
|
||||
if (entry.isIntersecting) {
|
||||
setActiveHash(`${entry.target.id}`);
|
||||
}
|
||||
});
|
||||
},
|
||||
{ rootMargin }
|
||||
);
|
||||
|
||||
itemIds?.forEach(id => {
|
||||
const element = document.getElementById(id);
|
||||
if (element !== null) {
|
||||
observer.observe(element);
|
||||
}
|
||||
});
|
||||
|
||||
return () => {
|
||||
itemIds?.forEach(id => {
|
||||
const element = document.getElementById(id);
|
||||
if (element !== null) {
|
||||
observer.unobserve(element);
|
||||
}
|
||||
});
|
||||
};
|
||||
}, [itemIds, rootMargin]);
|
||||
|
||||
return activeHash;
|
||||
};
|
||||
|
|
@ -1,17 +1,26 @@
|
|||
import fs from 'fs';
|
||||
import matter from 'gray-matter';
|
||||
import yaml from 'js-yaml';
|
||||
import { Stack, Heading } from '@chakra-ui/react';
|
||||
import { Flex, Stack, Heading, Text } from '@chakra-ui/react';
|
||||
import ChakraUIRenderer from 'chakra-ui-markdown-renderer';
|
||||
import ReactMarkdown from 'react-markdown';
|
||||
import { useRouter } from 'next/router';
|
||||
import { useEffect } from 'react';
|
||||
import gfm from 'remark-gfm';
|
||||
import rehypeRaw from 'rehype-raw';
|
||||
import { ParsedUrlQuery } from 'querystring';
|
||||
import type { GetStaticPaths, GetStaticProps, NextPage } from 'next';
|
||||
|
||||
import MDXComponents from '../components/';
|
||||
import { Breadcrumbs } from '../components/docs';
|
||||
import MDComponents from '../components/UI/docs';
|
||||
import { Breadcrumbs, DocsNav, DocumentNav } from '../components/UI/docs';
|
||||
import { PageMetadata } from '../components/UI';
|
||||
|
||||
import { NavLink } from '../types';
|
||||
|
||||
import { getFileList } from '../utils/getFileList';
|
||||
|
||||
import { textStyles } from '../theme/foundations';
|
||||
import { getParsedDate } from '../utils';
|
||||
|
||||
const MATTER_OPTIONS = {
|
||||
engines: {
|
||||
|
|
@ -21,21 +30,6 @@ const MATTER_OPTIONS = {
|
|||
|
||||
// This method crawls for all valid docs paths
|
||||
export const getStaticPaths: GetStaticPaths = () => {
|
||||
const getFileList = (dirName: string) => {
|
||||
let files: string[] = [];
|
||||
const items = fs.readdirSync(dirName, { withFileTypes: true });
|
||||
|
||||
for (const item of items) {
|
||||
if (item.isDirectory()) {
|
||||
files = [...files, ...getFileList(`${dirName}/${item.name}`)];
|
||||
} else {
|
||||
files.push(`/${dirName}/${item.name}`);
|
||||
}
|
||||
}
|
||||
|
||||
return files.map(file => file.replace('.md', '')).map(file => file.replace('/index', ''));
|
||||
};
|
||||
|
||||
const paths: string[] = getFileList('docs'); // This is folder that get crawled for valid docs paths. Change if this path changes.
|
||||
|
||||
return {
|
||||
|
|
@ -49,11 +43,16 @@ export const getStaticProps: GetStaticProps = async context => {
|
|||
const { slug } = context.params as ParsedUrlQuery;
|
||||
const filePath = (slug as string[])!.join('/');
|
||||
let file;
|
||||
let lastModified;
|
||||
|
||||
const navLinks = yaml.load(fs.readFileSync('src/data/documentation-links.yaml', 'utf8'));
|
||||
|
||||
try {
|
||||
file = fs.readFileSync(`${filePath}.md`, 'utf-8');
|
||||
lastModified = fs.statSync(`${filePath}.md`);
|
||||
} catch {
|
||||
file = fs.readFileSync(`${filePath}/index.md`, 'utf-8');
|
||||
lastModified = fs.statSync(`${filePath}/index.md`);
|
||||
}
|
||||
|
||||
const { data: frontmatter, content } = matter(file, MATTER_OPTIONS);
|
||||
|
|
@ -61,7 +60,13 @@ export const getStaticProps: GetStaticProps = async context => {
|
|||
return {
|
||||
props: {
|
||||
frontmatter,
|
||||
content
|
||||
content,
|
||||
navLinks,
|
||||
lastModified: getParsedDate(lastModified.mtime, {
|
||||
month: 'numeric',
|
||||
day: 'numeric',
|
||||
year: 'numeric'
|
||||
})
|
||||
}
|
||||
};
|
||||
};
|
||||
|
|
@ -71,24 +76,62 @@ interface Props {
|
|||
[key: string]: string;
|
||||
};
|
||||
content: string;
|
||||
navLinks: NavLink[];
|
||||
lastModified: string;
|
||||
}
|
||||
|
||||
const DocPage: NextPage<Props> = ({ frontmatter, content }) => {
|
||||
const DocPage: NextPage<Props> = ({ frontmatter, content, navLinks, lastModified }) => {
|
||||
const router = useRouter();
|
||||
|
||||
useEffect(() => {
|
||||
const id = router.asPath.split('#')[1];
|
||||
const element = document.getElementById(id);
|
||||
|
||||
if (!element) {
|
||||
return;
|
||||
}
|
||||
|
||||
element.scrollIntoView({ behavior: 'smooth', block: 'start' });
|
||||
}, [router.asPath]);
|
||||
|
||||
return (
|
||||
<>
|
||||
<PageMetadata title={frontmatter.title} description={frontmatter.description} />
|
||||
|
||||
<main>
|
||||
<Flex direction={{ base: 'column', lg: 'row' }} gap={{ base: 4, lg: 8 }}>
|
||||
<Stack>
|
||||
<DocsNav navLinks={navLinks} />
|
||||
</Stack>
|
||||
|
||||
<Stack pb={4} width='100%'>
|
||||
<Stack mb={16}>
|
||||
<Breadcrumbs />
|
||||
<Heading as='h1' mt='4 !important' mb={0} {...textStyles.header1}>
|
||||
{frontmatter.title}
|
||||
</Heading>
|
||||
{/* <Text as='span' mt='0 !important'>last edited {TODO: get last edited date}</Text> */}
|
||||
<Text as='span' mt='0 !important'>
|
||||
last edited {lastModified}
|
||||
</Text>
|
||||
</Stack>
|
||||
<ReactMarkdown remarkPlugins={[gfm]} components={ChakraUIRenderer(MDXComponents)}>
|
||||
|
||||
<Flex width='100%' placeContent='space-between'>
|
||||
<Stack maxW='768px' sx={{ "*:first-child": { marginTop: '0 !important' } }}>
|
||||
<ReactMarkdown
|
||||
remarkPlugins={[gfm]}
|
||||
rehypePlugins={[rehypeRaw]}
|
||||
components={ChakraUIRenderer(MDComponents)}
|
||||
>
|
||||
{content}
|
||||
</ReactMarkdown>
|
||||
</Stack>
|
||||
|
||||
<Stack display={{ base: 'none', xl: 'block' }} w={48}>
|
||||
<DocumentNav content={content} />
|
||||
</Stack>
|
||||
</Flex>
|
||||
</Stack>
|
||||
</Flex>
|
||||
</main>
|
||||
</>
|
||||
);
|
||||
|
|
|
|||
|
|
@ -1,22 +1,21 @@
|
|||
import { ChakraProvider } from '@chakra-ui/react';
|
||||
import { AppProps } from 'next/app';
|
||||
import { MDXProvider } from '@mdx-js/react';
|
||||
|
||||
import { Layout } from '../components/layouts';
|
||||
|
||||
import MDComponents from '../components/UI/docs';
|
||||
|
||||
import 'focus-visible/dist/focus-visible';
|
||||
|
||||
import theme from '../theme';
|
||||
|
||||
import { MDXProvider } from '@mdx-js/react';
|
||||
import MDXComponents from '../components/';
|
||||
|
||||
// Algolia search css styling
|
||||
import '../theme/search.css';
|
||||
|
||||
export default function App({ Component, pageProps }: AppProps) {
|
||||
return (
|
||||
<ChakraProvider theme={theme}>
|
||||
<MDXProvider components={MDXComponents}>
|
||||
<MDXProvider components={MDComponents}>
|
||||
<Layout>
|
||||
<Component {...pageProps} />
|
||||
</Layout>
|
||||
|
|
|
|||
|
|
@ -1,4 +1,4 @@
|
|||
import { Center, Code, Flex, Link, ListItem, Stack, Text, UnorderedList } from '@chakra-ui/react';
|
||||
import { Code, Flex, Link, ListItem, Stack, Text, UnorderedList } from '@chakra-ui/react';
|
||||
import type { GetStaticProps, NextPage } from 'next';
|
||||
import { useState } from 'react';
|
||||
import { XMLParser } from 'fast-xml-parser';
|
||||
|
|
@ -18,12 +18,11 @@ import {
|
|||
GETH_REPO_URL,
|
||||
METADATA,
|
||||
LATEST_SOURCES_BASE_URL,
|
||||
RELEASE_NOTES_BASE_URL
|
||||
RELEASE_NOTES_BASE_URL,
|
||||
DOWNLOADS_OPENPGP_SIGNATURES,
|
||||
DOWNLOADS_DEVELOPERS_DATA
|
||||
} from '../constants';
|
||||
|
||||
import { pgpBuildTestData } from '../data/test/pgpbuild-testdata';
|
||||
import { pgpDeveloperTestData } from '../data/test/pgpdeveloper-testdata';
|
||||
|
||||
import {
|
||||
fetchLatestReleaseCommit,
|
||||
fetchLatestReleaseVersionAndName,
|
||||
|
|
@ -483,16 +482,17 @@ const DownloadsPage: NextPage<Props> = ({ data }) => {
|
|||
}
|
||||
sectionTitle='OpenPGP Signatures'
|
||||
>
|
||||
{/* TODO: swap for real data */}
|
||||
<Stack borderBottom='2px solid' borderColor='primary'>
|
||||
<DataTable columnHeaders={DOWNLOADS_OPENPGP_BUILD_HEADERS} data={pgpBuildTestData} />
|
||||
<DataTable
|
||||
columnHeaders={DOWNLOADS_OPENPGP_BUILD_HEADERS}
|
||||
data={DOWNLOADS_OPENPGP_SIGNATURES}
|
||||
/>
|
||||
</Stack>
|
||||
|
||||
{/* TODO: swap for real data */}
|
||||
<Stack>
|
||||
<DataTable
|
||||
columnHeaders={DOWNLOADS_OPENPGP_DEVELOPER_HEADERS}
|
||||
data={pgpDeveloperTestData}
|
||||
data={DOWNLOADS_DEVELOPERS_DATA}
|
||||
/>
|
||||
</Stack>
|
||||
</DownloadsSection>
|
||||
|
|
@ -504,6 +504,7 @@ const DownloadsPage: NextPage<Props> = ({ data }) => {
|
|||
borderColor='primary'
|
||||
gap={4}
|
||||
flexDirection={{ base: 'column', md: 'row' }}
|
||||
alignItems='center'
|
||||
>
|
||||
<Stack flex={1}>
|
||||
<Text textStyle='quick-link-text'>
|
||||
|
|
@ -513,8 +514,9 @@ const DownloadsPage: NextPage<Props> = ({ data }) => {
|
|||
</Stack>
|
||||
|
||||
<Stack flex={1} w={'100%'}>
|
||||
{/* TODO: These keys depends on the binary */}
|
||||
<Code p={4}>gpg --recv-keys F9585DE6 C2FF8BBF 9BA28146 7B9E2481 D2A67EAC</Code>
|
||||
<Code p={4} bg='code-bg'>
|
||||
gpg --recv-keys F9585DE6 C2FF8BBF 9BA28146 7B9E2481 D2A67EAC
|
||||
</Code>
|
||||
</Stack>
|
||||
</Flex>
|
||||
|
||||
|
|
@ -524,6 +526,8 @@ const DownloadsPage: NextPage<Props> = ({ data }) => {
|
|||
borderColor='primary'
|
||||
gap={4}
|
||||
flexDirection={{ base: 'column', md: 'row' }}
|
||||
alignItems='center'
|
||||
sx={{ mt: '0 !important' }}
|
||||
>
|
||||
<Stack flex={1}>
|
||||
<Text textStyle='quick-link-text'>
|
||||
|
|
@ -533,17 +537,19 @@ const DownloadsPage: NextPage<Props> = ({ data }) => {
|
|||
</Stack>
|
||||
|
||||
<Stack flex={1} w={'100%'}>
|
||||
{/* TODO: These are developer keys, do we need to change? */}
|
||||
<Code p={4}>gpg --recv-keys E058A81C 05A5DDF0 1CCB7DD2</Code>
|
||||
<Code p={4} bg='code-bg'>
|
||||
gpg --recv-keys E058A81C 05A5DDF0 1CCB7DD2
|
||||
</Code>
|
||||
</Stack>
|
||||
</Flex>
|
||||
|
||||
<Flex
|
||||
p={4}
|
||||
borderBottom='2px'
|
||||
borderColor='primary'
|
||||
gap={4}
|
||||
flexDirection={{ base: 'column', md: 'row' }}
|
||||
alignItems='center'
|
||||
sx={{ mt: '0 !important' }}
|
||||
>
|
||||
<Stack flex={1}>
|
||||
<Text textStyle='quick-link-text'>
|
||||
|
|
@ -554,8 +560,9 @@ const DownloadsPage: NextPage<Props> = ({ data }) => {
|
|||
</Stack>
|
||||
|
||||
<Stack flex={1} w={'100%'}>
|
||||
{/* TODO: These keys depends on the binary */}
|
||||
<Code p={4}>gpg --verify geth-linux-amd64-1.5.0-d0c820ac.tar.gz.asc</Code>
|
||||
<Code p={4} bg='code-bg'>
|
||||
gpg --verify geth-linux-amd64-1.5.0-d0c820ac.tar.gz.asc
|
||||
</Code>
|
||||
</Stack>
|
||||
</Flex>
|
||||
</DownloadsSection>
|
||||
|
|
|
|||
|
|
@ -55,7 +55,7 @@ const HomePage: NextPage = ({}) => {
|
|||
</Text>
|
||||
|
||||
<Text textStyle='quick-link-text'>
|
||||
Geth has been a core part of Etheruem since the very beginning. Geth was one of
|
||||
Geth has been a core part of Ethereum since the very beginning. Geth was one of
|
||||
the original Ethereum implementations making it the most battle-hardened and
|
||||
tested client.
|
||||
</Text>
|
||||
|
|
@ -119,7 +119,7 @@ const HomePage: NextPage = ({}) => {
|
|||
the smallest of fixes! If you'd like to contribute to the Geth source code,
|
||||
please fork the{' '}
|
||||
<Link href={GETH_REPO_URL} isExternal variant='light'>
|
||||
Github repository
|
||||
GitHub repository
|
||||
</Link>
|
||||
, fix, commit and send a pull request for the maintainers to review and merge into
|
||||
the main code base.
|
||||
|
|
|
|||
|
|
@ -4,7 +4,7 @@ export const textStyles = {
|
|||
fontWeight: 700,
|
||||
fontSize: '2.75rem',
|
||||
lineHeight: '3.375rem',
|
||||
letterSpacing: '0.05em',
|
||||
letterSpacing: { base: '0.03rem', md: '0.04rem' },
|
||||
color: 'body'
|
||||
},
|
||||
h2: {
|
||||
|
|
@ -12,55 +12,56 @@ export const textStyles = {
|
|||
fontWeight: 400,
|
||||
fontSize: { base: '1.5rem', md: '1.75rem' },
|
||||
lineHeight: 'normal',
|
||||
letterSpacing: '0.04em',
|
||||
letterSpacing: { base: '0.03rem', md: '0.04rem' },
|
||||
color: 'body'
|
||||
},
|
||||
header1: {
|
||||
fontFamily: 'heading',
|
||||
fontWeight: 700,
|
||||
fontSize: { base: '1.875rem', md: '2.125rem' },
|
||||
letterSpacing: '0.04em',
|
||||
letterSpacing: { base: '0.03rem', md: '0.04rem' },
|
||||
lineHeight: 'normal',
|
||||
color: 'body'
|
||||
},
|
||||
header2: {
|
||||
fontFamily: 'heading',
|
||||
fontSize: { base: '1.5rem', md: '1.75rem' },
|
||||
letterSpacing: '0.04em',
|
||||
letterSpacing: { base: '0.03rem', md: '0.04rem' },
|
||||
lineHeight: 'normal',
|
||||
color: 'body'
|
||||
},
|
||||
header3: {
|
||||
fontFamily: 'heading',
|
||||
fontSize: { base: '1.25rem', md: '1.375rem' },
|
||||
letterSpacing: '0.04em',
|
||||
letterSpacing: { base: '0.03rem', md: '0.04rem' },
|
||||
lineHeight: 'normal',
|
||||
color: 'body'
|
||||
},
|
||||
header4: {
|
||||
fontFamily: 'heading',
|
||||
fontSize: '1.125rem',
|
||||
letterSpacing: '0.04em',
|
||||
letterSpacing: { base: '0.03rem', md: '0.04rem' },
|
||||
lineHeight: 'normal',
|
||||
color: 'body'
|
||||
},
|
||||
header5: {
|
||||
fontFamily: 'heading',
|
||||
fontSize: '1rem',
|
||||
letterSpacing: '0.02em',
|
||||
letterSpacing: '0.02rem',
|
||||
lineHeight: 'normal',
|
||||
color: 'body'
|
||||
},
|
||||
header6: {
|
||||
fontFamily: 'heading',
|
||||
fontSize: '0.875rem',
|
||||
letterSpacing: '0.02em',
|
||||
letterSpacing: '0.02rem',
|
||||
lineHeight: 'normal',
|
||||
color: 'body'
|
||||
},
|
||||
'header-font': {
|
||||
fontFamily: 'heading',
|
||||
fontWeight: 700,
|
||||
letterSpacing: '0.04rem',
|
||||
fontSize: { base: '0.86rem', sm: '1rem' },
|
||||
color: 'body'
|
||||
},
|
||||
|
|
@ -68,7 +69,7 @@ export const textStyles = {
|
|||
fontFamily: 'heading',
|
||||
fontWeight: 700,
|
||||
lineHeight: '21px',
|
||||
letterSpacing: '0.05em',
|
||||
letterSpacing: '0.05rem',
|
||||
textAlign: { base: 'center', md: 'left' },
|
||||
color: 'body'
|
||||
},
|
||||
|
|
@ -106,11 +107,11 @@ export const textStyles = {
|
|||
color: 'body'
|
||||
},
|
||||
'footer-link-label': {
|
||||
fontFamily: '"JetBrains Mono", monospace',
|
||||
fontFamily: 'heading',
|
||||
fontWeight: 700,
|
||||
textTransform: 'uppercase',
|
||||
lineHeight: '21.12px',
|
||||
letterSpacing: '0.02em'
|
||||
letterSpacing: '0.02rem'
|
||||
},
|
||||
'footer-text': {
|
||||
fontFamily: 'body',
|
||||
|
|
@ -138,13 +139,28 @@ export const textStyles = {
|
|||
textAlign: 'center',
|
||||
fontSize: 'sm'
|
||||
},
|
||||
'docs-nav-dropdown': {
|
||||
fontFamily: 'heading',
|
||||
fontWeight: 400,
|
||||
fontSize: '18px',
|
||||
lineHeight: 6,
|
||||
letterSpacing: '4%',
|
||||
textAlign: 'left'
|
||||
},
|
||||
'docs-nav-links': {
|
||||
fontFamily: 'heading',
|
||||
weight: 400,
|
||||
fontSize: 'md',
|
||||
lineHeight: 8,
|
||||
letterSpacing: '0.01em'
|
||||
},
|
||||
'header-button': {
|
||||
fontFamily: '"JetBrains Mono", monospace',
|
||||
fontFamily: 'heading',
|
||||
fontWeight: 700,
|
||||
fontSize: { base: '0.86rem', sm: '1rem' }
|
||||
},
|
||||
'header-mobile-button': {
|
||||
fontFamily: '"JetBrains Mono", monospace',
|
||||
fontFamily: 'heading',
|
||||
textTransform: 'uppercase',
|
||||
fontSize: '2xl'
|
||||
},
|
||||
|
|
@ -153,17 +169,34 @@ export const textStyles = {
|
|||
fontWeight: 400,
|
||||
fontSize: 'md',
|
||||
lineHeight: 4,
|
||||
letterSpacing: '0.01em'
|
||||
letterSpacing: '0.01rem'
|
||||
},
|
||||
'code-block': {
|
||||
fontFamily: 'heading',
|
||||
fontWeight: 400,
|
||||
fontSize: 'md',
|
||||
lineHeight: '21.12px',
|
||||
letterSpacing: '0.01em'
|
||||
letterSpacing: '0.01rem'
|
||||
},
|
||||
// TODO: refactor w/ semantic tokens for light/dark mode
|
||||
'link-light': {},
|
||||
// TODO: refactor w/ semantic tokens for light/dark mode
|
||||
'text-light': {}
|
||||
'document-nav-title': {
|
||||
fontFamily: 'heading',
|
||||
fontWeight: 400,
|
||||
fontSize: 'md',
|
||||
lineHeight: '21.12px',
|
||||
letterSpacing: '2%'
|
||||
},
|
||||
'document-nav-link': {
|
||||
fontFamily: 'body',
|
||||
fontWeight: 400,
|
||||
fontSize: '13px',
|
||||
lineHeight: 5,
|
||||
letterSpacing: '1%',
|
||||
mb: 4
|
||||
},
|
||||
'note-text': {
|
||||
fontFamily: 'body',
|
||||
fontWeight: 400,
|
||||
fontSize: 'md',
|
||||
lineHeight: '26px'
|
||||
}
|
||||
};
|
||||
|
|
|
|||
|
|
@ -31,7 +31,7 @@ const overrides = {
|
|||
secondary: { _light: 'green.800', _dark: 'green.600' },
|
||||
'button-bg': { _light: 'green.50', _dark: 'green.900' },
|
||||
body: { _light: 'gray.800', _dark: 'yellow.50' },
|
||||
'code-bg': { _light: 'gray.200', _dark: 'gray.700' },
|
||||
'code-bg': { _light: 'gray.200', _dark: 'gray.900' },
|
||||
'terminal-bg': { _light: 'gray.800', _dark: 'gray.900' },
|
||||
'terminal-text': { _light: 'green.50', _dark: 'green.200' },
|
||||
bg: { _light: 'yellow.50', _dark: 'gray.800' }
|
||||
|
|
|
|||
16
src/types.ts
16
src/types.ts
|
|
@ -34,3 +34,19 @@ export interface ReleaseParams {
|
|||
blobsList: string[];
|
||||
isStableRelease: boolean;
|
||||
}
|
||||
|
||||
export interface NavLink {
|
||||
id: string;
|
||||
to?: string;
|
||||
items?: NavLink[];
|
||||
}
|
||||
|
||||
export interface OpenPGPSignaturesData {
|
||||
'build server': string;
|
||||
'unique id': string;
|
||||
'openpgp key': {
|
||||
label: string;
|
||||
url: string;
|
||||
};
|
||||
fingerprint: string;
|
||||
}
|
||||
|
|
|
|||
|
|
@ -0,0 +1,16 @@
|
|||
import fs from 'fs';
|
||||
|
||||
export const getFileList = (dirName: string) => {
|
||||
let files: string[] = [];
|
||||
const items = fs.readdirSync(dirName, { withFileTypes: true });
|
||||
|
||||
for (const item of items) {
|
||||
if (item.isDirectory()) {
|
||||
files = [...files, ...getFileList(`${dirName}/${item.name}`)];
|
||||
} else {
|
||||
files.push(`/${dirName}/${item.name}`);
|
||||
}
|
||||
}
|
||||
|
||||
return files.map(file => file.replace('.md', '')).map(file => file.replace('/index', ''));
|
||||
};
|
||||
|
|
@ -1,12 +1,13 @@
|
|||
export const getParsedDate = (date: string) => {
|
||||
const dateOptions = {
|
||||
export const getParsedDate = (
|
||||
date: string | Date,
|
||||
dateOptions: Intl.DateTimeFormatOptions = {
|
||||
year: 'numeric',
|
||||
month: 'long',
|
||||
day: 'numeric',
|
||||
hour: '2-digit',
|
||||
minute: '2-digit',
|
||||
timeZone: 'UTC'
|
||||
} as const;
|
||||
|
||||
} as const
|
||||
) => {
|
||||
return new Date(date).toLocaleDateString('en', dateOptions);
|
||||
};
|
||||
|
|
|
|||
|
|
@ -0,0 +1,18 @@
|
|||
const check = '{#';
|
||||
|
||||
export const parseHeadingId = (children: string[]) => {
|
||||
if (children[children.length - 1].includes(check)) {
|
||||
const temp = children[children.length - 1].split(check);
|
||||
const headingId = temp[temp.length - 1].split('}')[0];
|
||||
|
||||
children[children.length - 1] = temp[0];
|
||||
|
||||
return {
|
||||
children,
|
||||
title: temp[0].replaceAll('#', ''),
|
||||
headingId
|
||||
};
|
||||
}
|
||||
|
||||
return null;
|
||||
};
|
||||
103
yarn.lock
103
yarn.lock
|
|
@ -1407,6 +1407,11 @@
|
|||
resolved "https://registry.npmjs.org/@types/parse-json/-/parse-json-4.0.0.tgz"
|
||||
integrity sha512-//oorEZjL6sbPcKUaCdIGlIUeH26mgzimjBB77G6XRgnDl/L5wOnpyBGRe/Mmf5CVW3PwEBE1NjiMZ/ssFh4wA==
|
||||
|
||||
"@types/parse5@^6.0.0":
|
||||
version "6.0.3"
|
||||
resolved "https://registry.yarnpkg.com/@types/parse5/-/parse5-6.0.3.tgz#705bb349e789efa06f43f128cef51240753424cb"
|
||||
integrity sha512-SuT16Q1K51EAVPz1K29DJ/sXjhSQ0zjvsypYJ6tlwVsRV9jwW5Adq2ch8Dq8kDBCkYnELS7N7VNCSB5nC56t/g==
|
||||
|
||||
"@types/prop-types@*", "@types/prop-types@^15.0.0":
|
||||
version "15.7.5"
|
||||
resolved "https://registry.npmjs.org/@types/prop-types/-/prop-types-15.7.5.tgz"
|
||||
|
|
@ -2585,11 +2590,62 @@ has@^1.0.3:
|
|||
dependencies:
|
||||
function-bind "^1.1.1"
|
||||
|
||||
hast-to-hyperscript@^10.0.0:
|
||||
version "10.0.1"
|
||||
resolved "https://registry.yarnpkg.com/hast-to-hyperscript/-/hast-to-hyperscript-10.0.1.tgz#3decd7cb4654bca8883f6fcbd4fb3695628c4296"
|
||||
integrity sha512-dhIVGoKCQVewFi+vz3Vt567E4ejMppS1haBRL6TEmeLeJVB1i/FJIIg/e6s1Bwn0g5qtYojHEKvyGA+OZuyifw==
|
||||
dependencies:
|
||||
"@types/unist" "^2.0.0"
|
||||
comma-separated-tokens "^2.0.0"
|
||||
property-information "^6.0.0"
|
||||
space-separated-tokens "^2.0.0"
|
||||
style-to-object "^0.3.0"
|
||||
unist-util-is "^5.0.0"
|
||||
web-namespaces "^2.0.0"
|
||||
|
||||
hast-util-from-parse5@^7.0.0:
|
||||
version "7.1.0"
|
||||
resolved "https://registry.yarnpkg.com/hast-util-from-parse5/-/hast-util-from-parse5-7.1.0.tgz#c129dd3a24dd8a867ab8a029ca47e27aa54864b7"
|
||||
integrity sha512-m8yhANIAccpU4K6+121KpPP55sSl9/samzQSQGpb0mTExcNh2WlvjtMwSWFhg6uqD4Rr6Nfa8N6TMypQM51rzQ==
|
||||
dependencies:
|
||||
"@types/hast" "^2.0.0"
|
||||
"@types/parse5" "^6.0.0"
|
||||
"@types/unist" "^2.0.0"
|
||||
hastscript "^7.0.0"
|
||||
property-information "^6.0.0"
|
||||
vfile "^5.0.0"
|
||||
vfile-location "^4.0.0"
|
||||
web-namespaces "^2.0.0"
|
||||
|
||||
hast-util-parse-selector@^2.0.0:
|
||||
version "2.2.5"
|
||||
resolved "https://registry.npmjs.org/hast-util-parse-selector/-/hast-util-parse-selector-2.2.5.tgz"
|
||||
integrity sha512-7j6mrk/qqkSehsM92wQjdIgWM2/BW61u/53G6xmC8i1OmEdKLHbk419QKQUjz6LglWsfqoiHmyMRkP1BGjecNQ==
|
||||
|
||||
hast-util-parse-selector@^3.0.0:
|
||||
version "3.1.0"
|
||||
resolved "https://registry.yarnpkg.com/hast-util-parse-selector/-/hast-util-parse-selector-3.1.0.tgz#a519e27e8b61bd5a98fad494ed06131ce68d9c3f"
|
||||
integrity sha512-AyjlI2pTAZEOeu7GeBPZhROx0RHBnydkQIXlhnFzDi0qfXTmGUWoCYZtomHbrdrheV4VFUlPcfJ6LMF5T6sQzg==
|
||||
dependencies:
|
||||
"@types/hast" "^2.0.0"
|
||||
|
||||
hast-util-raw@^7.2.0:
|
||||
version "7.2.2"
|
||||
resolved "https://registry.yarnpkg.com/hast-util-raw/-/hast-util-raw-7.2.2.tgz#1974360b2d7f15b5ce26c2a4bac892d5d8185a18"
|
||||
integrity sha512-0x3BhhdlBcqRIKyc095lBSDvmQNMY3Eulj2PLsT5XCyKYrxssI5yr3P4Kv/PBo1s/DMkZy2voGkMXECnFCZRLQ==
|
||||
dependencies:
|
||||
"@types/hast" "^2.0.0"
|
||||
"@types/parse5" "^6.0.0"
|
||||
hast-util-from-parse5 "^7.0.0"
|
||||
hast-util-to-parse5 "^7.0.0"
|
||||
html-void-elements "^2.0.0"
|
||||
parse5 "^6.0.0"
|
||||
unist-util-position "^4.0.0"
|
||||
unist-util-visit "^4.0.0"
|
||||
vfile "^5.0.0"
|
||||
web-namespaces "^2.0.0"
|
||||
zwitch "^2.0.0"
|
||||
|
||||
hast-util-to-estree@^2.0.0:
|
||||
version "2.1.0"
|
||||
resolved "https://registry.npmjs.org/hast-util-to-estree/-/hast-util-to-estree-2.1.0.tgz"
|
||||
|
|
@ -2611,6 +2667,18 @@ hast-util-to-estree@^2.0.0:
|
|||
unist-util-position "^4.0.0"
|
||||
zwitch "^2.0.0"
|
||||
|
||||
hast-util-to-parse5@^7.0.0:
|
||||
version "7.0.0"
|
||||
resolved "https://registry.yarnpkg.com/hast-util-to-parse5/-/hast-util-to-parse5-7.0.0.tgz#a39808e69005d10afeed1866029a1fb137df3f7c"
|
||||
integrity sha512-YHiS6aTaZ3N0Q3nxaY/Tj98D6kM8QX5Q8xqgg8G45zR7PvWnPGPP0vcKCgb/moIydEJ/QWczVrX0JODCVeoV7A==
|
||||
dependencies:
|
||||
"@types/hast" "^2.0.0"
|
||||
"@types/parse5" "^6.0.0"
|
||||
hast-to-hyperscript "^10.0.0"
|
||||
property-information "^6.0.0"
|
||||
web-namespaces "^2.0.0"
|
||||
zwitch "^2.0.0"
|
||||
|
||||
hast-util-whitespace@^2.0.0:
|
||||
version "2.0.0"
|
||||
resolved "https://registry.npmjs.org/hast-util-whitespace/-/hast-util-whitespace-2.0.0.tgz"
|
||||
|
|
@ -2627,6 +2695,17 @@ hastscript@^6.0.0:
|
|||
property-information "^5.0.0"
|
||||
space-separated-tokens "^1.0.0"
|
||||
|
||||
hastscript@^7.0.0:
|
||||
version "7.1.0"
|
||||
resolved "https://registry.yarnpkg.com/hastscript/-/hastscript-7.1.0.tgz#e402ed48f46161cf2f093badbff30583a5c3c315"
|
||||
integrity sha512-uBjaTTLN0MkCZxY/R2fWUOcu7FRtUVzKRO5P/RAfgsu3yFiMB1JWCO4AjeVkgHxAira1f2UecHK5WfS9QurlWA==
|
||||
dependencies:
|
||||
"@types/hast" "^2.0.0"
|
||||
comma-separated-tokens "^2.0.0"
|
||||
hast-util-parse-selector "^3.0.0"
|
||||
property-information "^6.0.0"
|
||||
space-separated-tokens "^2.0.0"
|
||||
|
||||
hey-listen@^1.0.8:
|
||||
version "1.0.8"
|
||||
resolved "https://registry.npmjs.org/hey-listen/-/hey-listen-1.0.8.tgz"
|
||||
|
|
@ -2644,6 +2723,11 @@ hoist-non-react-statics@^3.3.1:
|
|||
dependencies:
|
||||
react-is "^16.7.0"
|
||||
|
||||
html-void-elements@^2.0.0:
|
||||
version "2.0.1"
|
||||
resolved "https://registry.yarnpkg.com/html-void-elements/-/html-void-elements-2.0.1.tgz#29459b8b05c200b6c5ee98743c41b979d577549f"
|
||||
integrity sha512-0quDb7s97CfemeJAnW9wC0hw78MtW7NU3hqtCD75g2vFlDLt36llsYD7uB7SUzojLMP24N5IatXf7ylGXiGG9A==
|
||||
|
||||
ignore@^5.2.0:
|
||||
version "5.2.0"
|
||||
resolved "https://registry.npmjs.org/ignore/-/ignore-5.2.0.tgz"
|
||||
|
|
@ -3775,6 +3859,11 @@ parse-json@^5.0.0:
|
|||
json-parse-even-better-errors "^2.3.0"
|
||||
lines-and-columns "^1.1.6"
|
||||
|
||||
parse5@^6.0.0:
|
||||
version "6.0.1"
|
||||
resolved "https://registry.yarnpkg.com/parse5/-/parse5-6.0.1.tgz#e1a1c085c569b3dc08321184f19a39cc27f7c30b"
|
||||
integrity sha512-Ofn/CTFzRGTTxwpNEs9PP93gXShHcTq255nzRYSKe8AkVpZY7e1fpmTfOyoIvjP5HG7Z2ZM7VS9PPhQGW2pOpw==
|
||||
|
||||
path-exists@^4.0.0:
|
||||
version "4.0.0"
|
||||
resolved "https://registry.npmjs.org/path-exists/-/path-exists-4.0.0.tgz"
|
||||
|
|
@ -4025,6 +4114,15 @@ regexpp@^3.2.0:
|
|||
resolved "https://registry.npmjs.org/regexpp/-/regexpp-3.2.0.tgz"
|
||||
integrity sha512-pq2bWo9mVD43nbts2wGv17XLiNLya+GklZ8kaDLV2Z08gDCsGpnKn9BFMepvWuHCbyVvY7J5o5+BVvoQbmlJLg==
|
||||
|
||||
rehype-raw@^6.1.1:
|
||||
version "6.1.1"
|
||||
resolved "https://registry.yarnpkg.com/rehype-raw/-/rehype-raw-6.1.1.tgz#81bbef3793bd7abacc6bf8335879d1b6c868c9d4"
|
||||
integrity sha512-d6AKtisSRtDRX4aSPsJGTfnzrX2ZkHQLE5kiUuGOeEoLpbEulFF4hj0mLPbsa+7vmguDKOVVEQdHKDSwoaIDsQ==
|
||||
dependencies:
|
||||
"@types/hast" "^2.0.0"
|
||||
hast-util-raw "^7.2.0"
|
||||
unified "^10.0.0"
|
||||
|
||||
remark-gfm@^3.0.1:
|
||||
version "3.0.1"
|
||||
resolved "https://registry.yarnpkg.com/remark-gfm/-/remark-gfm-3.0.1.tgz#0b180f095e3036545e9dddac0e8df3fa5cfee54f"
|
||||
|
|
@ -4547,6 +4645,11 @@ vfile@^5.0.0:
|
|||
unist-util-stringify-position "^3.0.0"
|
||||
vfile-message "^3.0.0"
|
||||
|
||||
web-namespaces@^2.0.0:
|
||||
version "2.0.1"
|
||||
resolved "https://registry.yarnpkg.com/web-namespaces/-/web-namespaces-2.0.1.tgz#1010ff7c650eccb2592cebeeaf9a1b253fd40692"
|
||||
integrity sha512-bKr1DkiNa2krS7qxNtdrtHAmzuYGFQLiQ13TsorsdT6ULTkPLKuu5+GsFpDlg6JFjUTwX2DyhMPG2be8uPrqsQ==
|
||||
|
||||
which-boxed-primitive@^1.0.2:
|
||||
version "1.0.2"
|
||||
resolved "https://registry.npmjs.org/which-boxed-primitive/-/which-boxed-primitive-1.0.2.tgz"
|
||||
|
|
|
|||
Loading…
Reference in New Issue