Merge branch 'master' of github.com:ethereum/geth-website
This commit is contained in:
Nicolás Quiroz
commit
969ad78eb3
@ -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
|
||||
|
||||
@ -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.
|
||||
|
||||
@ -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)).
|
||||
|
||||
@ -39,7 +39,7 @@ All the Geth packages can be downloaded using:
|
||||
$ go get -d github.com/ethereum/go-ethereum/...
|
||||
```
|
||||
|
||||
More Go API support for dapp developers can be found on the [Go Contract Bindings](/docs/developers/dapp-developer/native-bindings) and [Go Account Management](/docs/dapp/native-accounts) pages.
|
||||
More Go API support for dapp developers can be found on the [Go Contract Bindings](/docs/developers/dapp-developer/native-bindings) and [Go Account Management](/docs/developers/dapp-developer/native-accounts) pages.
|
||||
|
||||
## Tutorial {#tutorial}
|
||||
|
||||
@ -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:
|
||||
@ -57,7 +57,7 @@ The same call can also be invoked from outside the node too via HTTP RPC (e.g. u
|
||||
$ curl -H "Content-Type: application/json" -d '{"id": 1, "method": "debug_traceTransaction", "params": ["0xfc9359e49278b7ba99f59edac0e3de49956e46e530a53c15aa71226b7aa92c6f"]}' localhost:8545
|
||||
```
|
||||
|
||||
To follow along with this tutorial, transaction hashes can be found from a local Geth node (e.g. by attaching a [Javascript console](/docs/interface/javascript-console) and running `eth.getBlock('latest')` then passing a transaction hash from the returned block to `debug.traceTransaction()`) or from a block explorer (for [Mainnet](https://etherscan.io/) or a [testnet](https://goerli.etherscan.io/)).
|
||||
To follow along with this tutorial, transaction hashes can be found from a local Geth node (e.g. by attaching a [Javascript console](/docs/interacting-with-geth/javascript-console) and running `eth.getBlock('latest')` then passing a transaction hash from the returned block to `debug.traceTransaction()`) or from a block explorer (for [Mainnet](https://etherscan.io/) or a [testnet](https://goerli.etherscan.io/)).
|
||||
|
||||
It is also possible to configure the trace by passing Boolean (true/false) values for four parameters that tweak the verbosity of the trace. By default, the _EVM memory_ and _Return data_ are not reported but the _EVM stack_ and _EVM storage_ are. To report the maximum amount of data:
|
||||
|
||||
@ -98,4 +98,4 @@ To avoid those issues, Geth supports running custom JavaScript tracers _within_
|
||||
|
||||
This page described how to do basic traces in Geth. Basic traces are very low level and can generate lots of data that might not all be useful. Therefore, it is also possible to use a set of built-in tracers or write custom ones in Javascript or Go.
|
||||
|
||||
Read more about [built-in](/docs/evm-tracing/builtin-tracers) and [custom](/docs/evm-tracing/custom-tracer) traces.
|
||||
Read more about [built-in](/docs/developers/evm-tracing/built-in-tracers) and [custom](/docs/developers/evm-tracing/custom-tracer) traces.
|
||||
|
||||
@ -3,7 +3,7 @@ title: Built-in tracers
|
||||
description: Explanation of the tracers that come bundled in Geth as part of the tracing API.
|
||||
---
|
||||
|
||||
Geth comes bundled with a choice of tracers that can be invoked via the [tracing API](/docs/rpc/ns-debug). Some of these built-in tracers are implemented natively in Go, and others in Javascript. The default tracer is the opcode logger (otherwise known as struct logger) which is the default tracer for all the methods. Other tracers have to be specified by passing their name to the `tracer` parameter in the API call.
|
||||
Geth comes bundled with a choice of tracers that can be invoked via the [tracing API](/docs/interacting-with-geth/rpc/ns-debug). Some of these built-in tracers are implemented natively in Go, and others in Javascript. The default tracer is the opcode logger (otherwise known as struct logger) which is the default tracer for all the methods. Other tracers have to be specified by passing their name to the `tracer` parameter in the API call.
|
||||
|
||||
## Struct/opcode logger {#struct-opcode-logger}
|
||||
|
||||
@ -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
|
||||
|
||||
@ -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
|
||||
{
|
||||
|
||||
@ -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.
|
||||
|
||||
@ -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.
|
||||
|
||||
|
||||
@ -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}
|
||||
|
||||
|
||||
@ -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}
|
||||
|
||||
|
||||
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}
|
||||
|
||||
@ -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,7 +145,7 @@ 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!
|
||||
|
||||
|
||||
@ -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}
|
||||
|
||||
@ -45,7 +45,7 @@ Running a light client simply requires Geth to be started in light mode. It is l
|
||||
geth --syncmode light --http --http.api "eth,debug"
|
||||
```
|
||||
|
||||
Data can be requested from this light Geth instance in the same way as for a full node (i.e. using the [JSON-RPC-API](/docs/rpc/server) using tools such as [Curl](https://curl.se/) or Geth's [Javascript console](/docs/interface/javascript-console)). Instead of fetching the data from a local database as in a full node, the light Geth instance requests the data from full-node peers.
|
||||
Data can be requested from this light Geth instance in the same way as for a full node (i.e. using the [JSON-RPC-API](/docs/interacting-with-geth/rpc/) using tools such as [Curl](https://curl.se/) or Geth's [Javascript console](/docs/interacting-with-geth/javascript-console)). Instead of fetching the data from a local database as in a full node, the light Geth instance requests the data from full-node peers.
|
||||
|
||||
It's also possible to send transactions. However, light clients are not connected directly to Ethereum Mainnet but to a network of light servers that connect to Ethereum Mainnet. This means a transaction submitted by a light client is received first by a light server that then propagates it to full-node peers on the light-client's behalf. This reliance on honest light-servers is one of the trust compromises that comes along with running a light node instead of a full node.
|
||||
|
||||
|
||||
@ -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}
|
||||
|
||||
@ -128,7 +128,7 @@ 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
|
||||
@ -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,11 +23,11 @@ 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.
|
||||
|
||||
@ -35,7 +35,7 @@ The account address can be provided to `--mining.etherbase` when Geth is started
|
||||
geth --http --miner.etherbase 0xC95767AC46EA2A9162F0734651d6cF17e5BfcF10
|
||||
```
|
||||
|
||||
The progress of the blockchain syncing can be monitored by attaching a JavaScript console in another terminal. More detailed information about the console can be found on the [Javascript Console](/docs/interface/javascript-console) page. To attach and open a console:
|
||||
The progress of the blockchain syncing can be monitored by attaching a JavaScript console in another terminal. More detailed information about the console can be found on the [Javascript Console](/docs/interacting-with-geth/javascript-console) page. To attach and open a console:
|
||||
|
||||
```sh
|
||||
geth attach http://127.0.0.1:8545
|
||||
@ -103,7 +103,7 @@ When Geth is started it is not mining by default. Unless it is specifically inst
|
||||
geth --mine --miner.threads=4
|
||||
```
|
||||
|
||||
CPU mining can also be started and stopped at runtime using the [console](/docs/interface/javascript-console). The command `miner.start` takes an optional parameter for the number of miner threads.
|
||||
CPU mining can also be started and stopped at runtime using the [console](/docs/interacting-with-geth/javascript-console). The command `miner.start` takes an optional parameter for the number of miner threads.
|
||||
|
||||
```js
|
||||
miner.start(8);
|
||||
|
||||
@ -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,12 +3,12 @@ title: Connecting To The Network
|
||||
description: Guide to connecting Geth to a peer-to-peer network
|
||||
---
|
||||
|
||||
The default behaviour for Geth is to connect to Ethereum Mainnet. However, Geth can also connect to public testnets, [private networks](/docs/getting-started/private-net) and [local testnets](/docs/getting-started/dev-mode). For convenience, the two public testnets with long term support, Goerli and Sepolia, have their own command line flag. Geth can connect to these testnets simpyl by passing:
|
||||
The default behaviour for Geth is to connect to Ethereum Mainnet. However, Geth can also connect to public testnets, [private networks](/docs/developers/geth-developer/private-network.md) and [local testnets](/docs/developers/geth-developer/dev-mode). For convenience, the two public testnets with long term support, Goerli and Sepolia, have their own command line flag. Geth can connect to these testnets simpyl by passing:
|
||||
|
||||
- `--goerli`, Goerli proof-of-authority test network
|
||||
- `--sepolia` Sepolia proof-of-work test network
|
||||
|
||||
These testnets started as proof-of-work and proof-of-authority testnets, but they were transitioned to proof-of-stake in 2022 in preparation for doing the same to Ethereum Mainnet. This means that to run a node on Goerli or Sepolia it is now necessary to run a consensus client connected to Geth. This is also true for Ethereum Mainnet. **Geth does not work on proof-of-stake networks without a consensus client**! The remainder of this page will assume that Geth is connected to a consensus client that is synced to the desired network. For instructions on how to set up a consensus client please see the [Consensus Clients](/docs/interface/consensus-clients) page.
|
||||
These testnets started as proof-of-work and proof-of-authority testnets, but they were transitioned to proof-of-stake in 2022 in preparation for doing the same to Ethereum Mainnet. This means that to run a node on Goerli or Sepolia it is now necessary to run a consensus client connected to Geth. This is also true for Ethereum Mainnet. **Geth does not work on proof-of-stake networks without a consensus client**! The remainder of this page will assume that Geth is connected to a consensus client that is synced to the desired network. For instructions on how to set up a consensus client please see the [Consensus Clients](/docs/getting-started/consensus-clients) page.
|
||||
|
||||
**Note:** Network selection is not persisted from a config file. To connect to a pre-defined network you must always enable it explicitly, even when using the `--config` flag to load other configuration values. For example:
|
||||
|
||||
@ -40,13 +40,13 @@ There are occasions when Geth simply fails to connect to peers. The common reaso
|
||||
|
||||
- Some firewall configurations can prohibit UDP traffic. The static nodes feature or `admin.addPeer()` on the console can be used to configure connections manually.
|
||||
|
||||
- Running Geth in [light mode](/docs/interface/les) often leads to connectivity issues because there are few nodes running light servers. There is no easy fix for this except to switch Geth out of light mode. **Note that light mode does not curently work on proof-of-stake networks**.
|
||||
- Running Geth in [light mode](/docs/fundamentals/les) often leads to connectivity issues because there are few nodes running light servers. There is no easy fix for this except to switch Geth out of light mode. **Note that light mode does not curently work on proof-of-stake networks**.
|
||||
|
||||
- The public test network Geth is connecting to might be deprecated or have a low number of active nodes that are hard to find. In this case, the best action is to switch to an alternative test network.
|
||||
|
||||
## Checking Connectivity {#checking-connectivity}
|
||||
|
||||
The `net` module has two attributes that enable checking node connectivity from the [interactive Javascript console](/docs/interface/javascript-console). These are `net.listening` which reports whether the Geth node is listening for inbound requests, and `peerCount` which returns the number of active peers the node is connected to.
|
||||
The `net` module has two attributes that enable checking node connectivity from the [interactive Javascript console](/docs/interacting-with-geth/javascript-console). These are `net.listening` which reports whether the Geth node is listening for inbound requests, and `peerCount` which returns the number of active peers the node is connected to.
|
||||
|
||||
```js
|
||||
> net.listening
|
||||
@ -106,7 +106,7 @@ The `admin` module also includes functions for gathering information about the l
|
||||
|
||||
## Custom Networks {#custom-networks}
|
||||
|
||||
It is often useful for developers to connect to private test networks rather than public testnets or Etheruem mainnet. These sandbox environments allow block creation without competing against other miners, easy minting of test ether and give freedom to break things without real-world consequences. A private network is started by providing a value to `--networkid` that is not used by any other existing public network ([Chainlist](https://chainlist.org)) and creating a custom `genesis.json` file. Detailed instructions for this are available on the [Private Networks page](/docs/interface/private-network).
|
||||
It is often useful for developers to connect to private test networks rather than public testnets or 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}
|
||||
|
||||
|
||||
@ -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).
|
||||
|
||||
@ -46,7 +46,7 @@ It is also possible to create a partial/recent archive node where the node was s
|
||||
|
||||
A light node syncs very quickly and stores the bare minimum of blockchain data. Light nodes only process block headers, not entire blocks. This greatly reduces the computation time, storage and bandwidth required relative to a full node. This means light nodes are suitable for resource-constrained devices and can catch up to the head of the chain much faster when they are new or have been offline for a while. The trade-off is that light nodes rely heavily on data served by altruistic full nodes. A light client can be used to query data from Ethereum and submit transactions, acting as a locally-hosted Ethereum wallet. However, because they don't keep local copies of the Ethereum state, light nodes can't validate blocks in the same way as full nodes - they receive a proof from the full node and verify it against their local header chain. To start a node in light mode, pass `--syncmode light`. Be aware that full nodes serving light data are relative scarce so light nodes can struggle to find peers. **Light nodes are not currently working on proof-of-stake Ethereum**.
|
||||
|
||||
Read more about light nodes on our [LES page](/docs/interface/les).
|
||||
Read more about light nodes on our [LES page](/docs/fundamentals/les).
|
||||
|
||||
## Consensus layer syncing {#consensus-layer-syncing}
|
||||
|
||||
@ -66,7 +66,7 @@ Read more in the [optimistic sync specs](https://github.com/ethereum/consensus-s
|
||||
|
||||
Alternatively, the consensus client can grab a checkpoint from a trusted source which provides a target state to sync up to, before switching to full sync and verifying each block in turn. In this mode, the node trusts that the checkpoint is correct. There are many possible sources for this checkpoint - the gold standard would be to get it out-of-band from another trusted friend, but it could also come from block explorers or [public APIs/web apps](https://eth-clients.github.io/checkpoint-sync-endpoints/). Checkpoint sync is very fast - a consensus cleint should be able to sync in a few minutes using this method.
|
||||
|
||||
For troubleshooting, please see the `Syncing` section on the [console log messages](/docs/interface/logs) page.
|
||||
For troubleshooting, please see the `Syncing` section on the [console log messages](/docs/fundamentals/logs) page.
|
||||
|
||||
## Summary {#summary}
|
||||
|
||||
|
||||
@ -9,7 +9,7 @@ There are five consensus clients available, all of which connect to Geth in the
|
||||
|
||||
## Configuring Geth {#configuring-geth}
|
||||
|
||||
Geth can be downloaded and installed according to the instructions on the [Installing Geth](/docs/install-and-build/installing-geth) page. In order to connect to a consensus client, Geth must expose a port for the inter-client RPC connection.
|
||||
Geth can be downloaded and installed according to the instructions on the [Installing Geth](/docs/getting-started/installing-geth) page. In order to connect to a consensus client, Geth must expose a port for the inter-client RPC connection.
|
||||
|
||||
The RPC connection must be authenticated using a `jwtsecret` file. This is created and saved to `<datadir>/geth/jwtsecret` by default but can also be created and saved to a custom location or it can be self-generated and provided to Geth by passing the file path to `--authrpc.jwtsecret`. The `jwtsecret` file is required by both Geth and the consensus client.
|
||||
|
||||
@ -55,7 +55,7 @@ Please see the pages on [syncing](/docs/fundamentals/sync-modes) for more detail
|
||||
|
||||
## Using Geth {#using-geth}
|
||||
|
||||
Geth is the portal for users to send transactions to Ethereum. The Geth Javascript console is available for this purpose, and the majority of the [JSON-RPC API](/docs/rpc/server) will remain available via web3js or HTTP requests with commands as json payloads. These options are explained in more detail on the [Javascript Console page](/docs/interface/javascript-console). The Javascript console can be started
|
||||
Geth is the portal for users to send transactions to Ethereum. The Geth Javascript console is available for this purpose, and the majority of the [JSON-RPC API](/docs/rpc/server) will remain available via web3js or HTTP requests with commands as json payloads. These options are explained in more detail on the [Javascript Console page](/docs/interacting-with-geth/javascript-console). The Javascript console can be started
|
||||
using the following command in a separate terminal (assuming Geth's IPC file is saved in `datadir`):
|
||||
|
||||
```sh
|
||||
|
||||
@ -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}
|
||||
|
||||
|
||||
@ -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}
|
||||
|
||||
|
||||
@ -258,7 +258,7 @@ 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.
|
||||
|
||||
```sh
|
||||
git clone https://github.com/ethereum/go-ethereum
|
||||
@ -303,7 +303,7 @@ 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.
|
||||
|
||||
```sh
|
||||
cd go-ethereum
|
||||
|
||||
@ -3,7 +3,7 @@ title: JavaScript Console
|
||||
description: How to interact with Geth using Javascript
|
||||
---
|
||||
|
||||
Geth responds to instructions encoded as JSON objects as defined in the [JSON-RPC-API](/docs/rpc/server). A Geth user can send these instructions directly, for example over HTTP using tools like [Curl](https://github.com/curl/curl). The code snippet below shows a request for an account balance sent to a local Geth node with the HTTP port `8545` exposed.
|
||||
Geth responds to instructions encoded as JSON objects as defined in the [JSON-RPC-API](/docs/interacting-with-geth/rpc/server). A Geth user can send these instructions directly, for example over HTTP using tools like [Curl](https://github.com/curl/curl). The code snippet below shows a request for an account balance sent to a local Geth node with the HTTP port `8545` exposed.
|
||||
|
||||
```sh
|
||||
curl --data '{"jsonrpc":"2.0","method":"eth_getBalance", "params": ["0x9b1d35635cc34752ca54713bb99d38614f63c955", "latest"], "id":2}' -H "Content-Type: application/json" localhost:8545
|
||||
@ -18,7 +18,7 @@ This returns a result which is also a JSON object, with values expressed as hexa
|
||||
This is a low level and rather error-prone way to interact with Geth. Most developers prefer to use convenience libraries that abstract away some of the more tedious and awkward tasks such as converting values from hexadecimal strings into numbers, or converting between denominations of ether (Wei, Gwei, etc). One such library is [Web3.js](https://web3js.readthedocs.io/en/v1.7.3/).
|
||||
The purpose of Geth's Javascript console is to provide a built-in environment to use a subset of the Web3.js libraries to interact with a Geth node.
|
||||
|
||||
{% include note.html content="The web3.js version that comes bundled with Geth is not up to date with the official Web3.js documentation. There are several Web3.js libraries that are not available in the Geth Javascript Console. There are also administrative APIs included in the Geth console that are not documented in the Web3.js documentation. The full list of libraries available in the Geth console is available on the [JSON-RPC API page](/docs/rpc/server)." %}
|
||||
<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}
|
||||
|
||||
@ -77,9 +77,7 @@ To exit, press ctrl-d or type exit
|
||||
|
||||
## Interactive use {#interactive-use}
|
||||
|
||||
Once the console has been started, it can be used to interact with Geth. The console supports Javascript and the full Geth [JSON-RPC API](/docs/rpc/server). For example:
|
||||
|
||||
To check the balance of the first account already existing in the keystore:
|
||||
Once the console has been started, it can be used to interact with Geth. The console supports Javascript and the full Geth [JSON-RPC API](/docs/interacting-with-geth/rpc/server). For example, to check the balance of the first account already existing in the keystore:
|
||||
|
||||
```js
|
||||
eth.getBalance(eth.accounts[0]);
|
||||
@ -95,9 +93,7 @@ eth.sendTransaction({
|
||||
});
|
||||
```
|
||||
|
||||
It is also possible to load pre-written Javascript files into the console by passing the `--preload` flag
|
||||
when starting the console. This is useful for setting up complex contract objects or loading frequently-used
|
||||
functions.
|
||||
It is also possible to load pre-written Javascript files into the console by passing the `--preload` flag when starting the console. This is useful for setting up complex contract objects or loading frequently-used functions.
|
||||
|
||||
```sh
|
||||
geth console --preload "/my/scripts/folder/utils.js"
|
||||
@ -109,8 +105,7 @@ Remember that interactions that touch accounts need approval in Clef - either ma
|
||||
|
||||
## Non-interactive Use: Script Mode {#non-interactive-use}
|
||||
|
||||
It is also possible to execute JavaScript code non-interactively by passing the `--exec` and a JSON-RPC-API endpoint
|
||||
to `geth attach` or `geth console`. The result is displayed directly in the terminal rather than in an interactive Javascript console.
|
||||
It is also possible to execute JavaScript code non-interactively by passing the `--exec` and a JSON-RPC-API endpoint to `geth attach` or `geth console`. The result is displayed directly in the terminal rather than in an interactive Javascript console.
|
||||
|
||||
For example, to display the accounts in the keystore:
|
||||
|
||||
@ -130,8 +125,7 @@ geth attach http://geth.example.org:8545 --exec 'loadScript("/tmp/checkbalances.
|
||||
geth attach http://geth.example.org:8545 --jspath "/tmp" --exec 'loadScript("checkbalances.js")'
|
||||
```
|
||||
|
||||
The `--jspath` flag is used to set a library directory for the Javascript scripts. Any parameters passed to `loadScript()`
|
||||
that do not explicitly define an absolute path will be interpreted relative to the `jspath` directory.
|
||||
The `--jspath` flag is used to set a library directory for the Javascript scripts. Any parameters passed to `loadScript()` that do not explicitly define an absolute path will be interpreted relative to the `jspath` directory.
|
||||
|
||||
## Timers {#timers}
|
||||
|
||||
|
||||
@ -41,4 +41,4 @@ In this case there's no dependency between the requests. Often the retrieved dat
|
||||
- First to download the list of transaction hashes for all of the blocks in our desired range
|
||||
- And then to download the list of receipts objects for all of the transaction hashes
|
||||
|
||||
For use-cases which depend on several JSON-RPC endpoints the batching approach can get easily complicated. In that case Geth offers a [GraphQL API](./graphql) which is more suitable.
|
||||
For use-cases which depend on several JSON-RPC endpoints the batching approach can get easily complicated. In that case Geth offers a [GraphQL API](/docs/interacting-with-geth/rpc/graphql) which is more suitable.
|
||||
|
||||
@ -60,7 +60,7 @@ The `--http.corsdomain` command also acceptsd wildcards that enable access to th
|
||||
|
||||
Websocket is a bidirectional transport protocol. A Websocket connection is maintained by client and server until it is explicitly terminated by one. Most modern browsers support Websocket which means it has good tooling.
|
||||
|
||||
Because Websocket is bidirectional, servers can push events to clients. That makes Websocket a good choice for use-cases involving [event subscription](/docs/rpc/pubsub). Another benefit of Websocket is that after the handshake procedure, the overhead of individual messages is low,
|
||||
Because Websocket is bidirectional, servers can push events to clients. That makes Websocket a good choice for use-cases involving [event subscription](/docs/interacting-with-geth/rpc/pubsub). Another benefit of Websocket is that after the handshake procedure, the overhead of individual messages is low,
|
||||
making it good for sending high number of requests.
|
||||
|
||||
Configuration of the WebSocket endpoint in Geth follows the same pattern as the HTTP transport. WebSocket access can be enabled using the `--ws` flag. If no additional information is provided, Geth falls back to its default behaviour which is to establish the Websocket on port 8546. The `--ws.addr`, `--ws.port` and `--ws.api` flags can be used to customize settings for the WebSocket server. For example, to start Geth with a Websocket connection for RPC using
|
||||
@ -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).
|
||||
|
||||
|
||||
@ -105,7 +105,7 @@ The `nodeInfo` administrative property can be queried for all the information kn
|
||||
|
||||
## admin_peerEvents {#admin-peerevents}
|
||||
|
||||
PeerEvents creates an [RPC subscription](/docs/rpc/pubsub) which receives peer events from the node's p2p server. The type of events emitted by the server are as follows:
|
||||
PeerEvents creates an [RPC subscription](/docs/interacting-with-geth/rpc/pubsub) which receives peer events from the node's p2p server. The type of events emitted by the server are as follows:
|
||||
|
||||
- `add`: emitted when a peer is added
|
||||
- `drop`: emitted when a peer is dropped
|
||||
@ -179,7 +179,7 @@ Removes a remote node from the trusted peer set, but it does not disconnect it a
|
||||
|
||||
## admin_startHTTP {#admin-starthttp}
|
||||
|
||||
The `startHTTP` administrative method starts an HTTP based JSON-RPC [API](/docs/rpc/server) webserver to handle client requests. All the parameters are optional:
|
||||
The `startHTTP` administrative method starts an HTTP based JSON-RPC [API](/docs/interacting-with-geth/rpc/server) webserver to handle client requests. All the parameters are optional:
|
||||
|
||||
- `host`: network interface to open the listener socket on (defaults to `"localhost"`)
|
||||
- `port`: network port to open the listener socket on (defaults to `8545`)
|
||||
|
||||
@ -29,7 +29,7 @@ The location is specified as `<filename>:<line>`.
|
||||
|
||||
Example:
|
||||
|
||||
``` js
|
||||
```js
|
||||
> debug.backtraceAt("server.go:443")
|
||||
```
|
||||
|
||||
@ -199,7 +199,7 @@ Retrieves and returns the RLP encoded block by number.
|
||||
| Console | `debug.getBlockRlp(number, [options])` |
|
||||
| RPC | `{"method": "debug_getBlockRlp", "params": [number]}` |
|
||||
|
||||
References: [RLP](https://github.com/ethereum/wiki/wiki/RLP)
|
||||
References: [RLP](https://ethereum.org/en/developers/docs/data-structures-and-encoding/rlp/)
|
||||
|
||||
### debug_getHeaderRlp
|
||||
|
||||
@ -334,7 +334,7 @@ Sets the current head of the local chain by block number. **Note**, this is a de
|
||||
| RPC | `{"method": "debug_setHead", "params": [number]}` |
|
||||
|
||||
References:
|
||||
[Ethash](https://eth.wiki/en/concepts/ethash/ethash)
|
||||
[Ethash](https://ethereum.org/en/developers/docs/consensus-mechanisms/pow/mining-algorithms/ethash/)
|
||||
|
||||
### debug_setMutexProfileFraction
|
||||
|
||||
@ -475,7 +475,7 @@ The `traceBlock` method will return a full stack trace of all invoked opcodes of
|
||||
| RPC | `{"method": "debug_traceBlock", "params": [blockRlp, {}]}` |
|
||||
|
||||
References:
|
||||
[RLP](https://github.com/ethereum/wiki/wiki/RLP)
|
||||
[RLP](https://ethereum.org/en/developers/docs/data-structures-and-encoding/rlp/)
|
||||
|
||||
#### Example
|
||||
|
||||
@ -524,7 +524,7 @@ Similar to [debug_traceBlock](#debug_traceblock), `traceBlockByNumber` accepts a
|
||||
| RPC | `{"method": "debug_traceBlockByNumber", "params": [number, {}]}` |
|
||||
|
||||
References:
|
||||
[RLP](https://github.com/ethereum/wiki/wiki/RLP)
|
||||
[RLP](https://ethereum.org/en/developers/docs/data-structures-and-encoding/rlp/)
|
||||
|
||||
### debug_traceBlockByHash
|
||||
|
||||
@ -537,7 +537,7 @@ Similar to [debug_traceBlock](#debug_traceblock), `traceBlockByHash` accepts a b
|
||||
| RPC | `{"method": "debug_traceBlockByHash", "params": [hash {}]}` |
|
||||
|
||||
References:
|
||||
[RLP](https://github.com/ethereum/wiki/wiki/RLP)
|
||||
[RLP](https://ethereum.org/en/developers/docs/data-structures-and-encoding/rlp/)
|
||||
|
||||
### debug_traceBlockFromFile
|
||||
|
||||
@ -550,11 +550,11 @@ Similar to [debug_traceBlock](#debug_traceblock), `traceBlockFromFile` accepts a
|
||||
| RPC | `{"method": "debug_traceBlockFromFile", "params": [fileName, {}]}` |
|
||||
|
||||
References:
|
||||
[RLP](https://github.com/ethereum/wiki/wiki/RLP)
|
||||
[RLP](https://ethereum.org/en/developers/docs/data-structures-and-encoding/rlp/)
|
||||
|
||||
### debug_traceCall
|
||||
|
||||
The `debug_traceCall` method lets you run an `eth_call` within the context of the given block execution using the final state of parent block as the base. The first argument (just as in `eth_call`) is a [transaction object](/docs/rpc/objects#transaction-call-object). The block can be specified either by hash or by number as the second argument. The trace can be configured similar to `debug_traceTransaction`, see [TraceConfig](#traceconfig). The method returns the same output as `debug_traceTransaction`.
|
||||
The `debug_traceCall` method lets you run an `eth_call` within the context of the given block execution using the final state of parent block as the base. The first argument (just as in `eth_call`) is a [transaction object](/docs/interacting-with-geth/rpc/objects#transaction-call-object). The block can be specified either by hash or by number as the second argument. The trace can be configured similar to `debug_traceTransaction`, see [TraceConfig](#traceconfig). The method returns the same output as `debug_traceTransaction`.
|
||||
|
||||
| Client | Method invocation |
|
||||
| :-----: | --------------------------------------------------------------------------------------------------------------------------- |
|
||||
@ -579,13 +579,16 @@ No specific call options:
|
||||
Tracing a call with a destination and specific sender, disabling the storage and memory output (less data returned over RPC)
|
||||
|
||||
```js
|
||||
debug.traceCall({
|
||||
"from": "0xdeadbeef29292929192939494959594933929292",
|
||||
"to": "0xde929f939d939d393f939393f93939f393929023",
|
||||
"gas": "0x7a120",
|
||||
"data": "0xf00d4b5d00000000000000000000000001291230982139282304923482304912923823920000000000000000000000001293123098123928310239129839291010293810"
|
||||
},
|
||||
"latest", {"disableStorage": true, "disableMemory": true})
|
||||
debug.traceCall(
|
||||
{
|
||||
from: '0xdeadbeef29292929192939494959594933929292',
|
||||
to: '0xde929f939d939d393f939393f93939f393929023',
|
||||
gas: '0x7a120',
|
||||
data: '0xf00d4b5d00000000000000000000000001291230982139282304923482304912923823920000000000000000000000001293123098123928310239129839291010293810'
|
||||
},
|
||||
'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:
|
||||
@ -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,26 +734,26 @@ Sets the logging verbosity pattern.
|
||||
|
||||
If you want to see messages from a particular Go package (directory) and all subdirectories, use:
|
||||
|
||||
``` js
|
||||
```js
|
||||
> debug.vmodule("eth/*=6")
|
||||
```
|
||||
|
||||
If you want to restrict messages to a particular package (e.g. p2p) but exclude subdirectories, use:
|
||||
|
||||
``` js
|
||||
```js
|
||||
> debug.vmodule("p2p=6")
|
||||
```
|
||||
|
||||
If you want to see log messages from a particular source file, use
|
||||
|
||||
``` js
|
||||
```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:
|
||||
|
||||
``` js
|
||||
debug.vmodule("eth/*/peer.go=6,p2p=5")
|
||||
```js
|
||||
debug.vmodule('eth/*/peer.go=6,p2p=5');
|
||||
```
|
||||
|
||||
### debug_writeBlockProfile
|
||||
|
||||
@ -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:
|
||||
@ -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
|
||||
|
||||
|
||||
@ -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}
|
||||
|
||||
@ -172,7 +172,7 @@ Deletes a pairing between wallet and Geth.
|
||||
|
||||
Validate the given passphrase and submit transaction.
|
||||
|
||||
The transaction is the same argument as for `eth_sendTransaction` (i.e. [transaction object](/docs/rpc/objects#transaction-call-object)) and contains the `from` address. If the passphrase can be used to decrypt the private key belogging to `tx.from` the transaction is verified, signed and send onto the network. The account is not unlocked globally in the node and cannot be used in other RPC calls.
|
||||
The transaction is the same argument as for `eth_sendTransaction` (i.e. [transaction object](/docs/interacting-with-geth/rpc/objects#transaction-call-object)) and contains the `from` address. If the passphrase can be used to decrypt the private key belogging to `tx.from` the transaction is verified, signed and send onto the network. The account is not unlocked globally in the node and cannot be used in other RPC calls.
|
||||
|
||||
| Client | Method invocation |
|
||||
| :------ | ---------------------------------------------------------------- |
|
||||
@ -211,7 +211,7 @@ See ecRecover to verify the signature.
|
||||
|
||||
## personal_signTransaction {#personal-signtransaction}
|
||||
|
||||
SignTransaction will create a transaction from the given arguments and tries to sign it with the key associated with `tx.from`. If the given passwd isn't able to decrypt the key it fails. The transaction is returned in RLP-form, not broadcast to other nodes. The first argument is a [transaction object](/docs/interacting_with_geth/RPC/objects) and the second argument is the password, similar to `personal_sendTransaction`.
|
||||
SignTransaction will create a transaction from the given arguments and tries to sign it with the key associated with `tx.from`. If the given passwd isn't able to decrypt the key it fails. The transaction is returned in RLP-form, not broadcast to other nodes. The first argument is a [transaction object](/docs/interacting-with-geth/rpc/objects) and the second argument is the password, similar to `personal_sendTransaction`.
|
||||
|
||||
| Client | Method invocation |
|
||||
| :------ | ---------------------------------------------------------------- |
|
||||
|
||||
@ -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
|
||||
|
||||
@ -1,5 +1,5 @@
|
||||
---
|
||||
title: resources
|
||||
title: Resources
|
||||
description: Read, watch and listen more about Geth and Ethereum
|
||||
---
|
||||
|
||||
|
||||
@ -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).
|
||||
|
||||
@ -69,6 +69,7 @@ Initiate Geth:
|
||||
```sh
|
||||
$ geth --datadir ./ddir init genesis.json
|
||||
```
|
||||
|
||||
```terminal
|
||||
...
|
||||
INFO [06-16|11:14:54.123] Writing custom genesis block
|
||||
@ -90,6 +91,7 @@ These two things are independent of each other. First of all, however, `clef` mu
|
||||
```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!
|
||||
@ -117,6 +119,7 @@ With that done, `clef` can be made aware of the password. To do this `setpw <add
|
||||
```sh
|
||||
$ clef --keystore ./ddir/keystore --configdir ./clef --chainid 15 --suppress-bootwarn setpw 0x9CD932F670F7eDe5dE86F756A6D02548e5899f47
|
||||
```
|
||||
|
||||
```terminal
|
||||
Please enter a password to store for this address:
|
||||
Password:
|
||||
|
||||
@ -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.
|
||||
|
||||
@ -12,6 +12,7 @@ First things first, Clef needs to store some data itself. Since that data might
|
||||
```sh
|
||||
$ clef init
|
||||
```
|
||||
|
||||
```terminal
|
||||
WARNING!
|
||||
|
||||
@ -49,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:
|
||||
|
||||
@ -77,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
|
||||
@ -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)
|
||||
@ -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}
|
||||
|
||||
@ -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)
|
||||
|
||||
@ -30,6 +30,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 |
BIN
public/images/docs/node-architecture-text-background.png
Normal file
BIN
public/images/docs/node-architecture-text-background.png
Normal file
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,48 +50,81 @@ export const DataTable: FC<Props> = ({ columnHeaders, data }) => {
|
||||
</Thead>
|
||||
|
||||
<Tbody>
|
||||
{data.map((r: ReleaseData, idx: number) => {
|
||||
return (
|
||||
<Tr
|
||||
key={idx}
|
||||
transition={'all 0.5s'}
|
||||
_hover={{ background: 'button-bg', transition: 'all 0.5s' }}
|
||||
>
|
||||
{Object.entries(r).map((item, idx) => {
|
||||
const objectItems = ['release', 'commit', 'signature'];
|
||||
{dataType === 'Releases' &&
|
||||
data.map((r: ReleaseData, idx: number) => {
|
||||
return (
|
||||
<Tr
|
||||
key={idx}
|
||||
transition={'all 0.5s'}
|
||||
_hover={{ background: 'button-bg', transition: 'all 0.5s' }}
|
||||
>
|
||||
{Object.entries(r).map((item, idx) => {
|
||||
const objectItems = ['release', 'commit', 'signature'];
|
||||
|
||||
if (objectItems.includes(item[0])) {
|
||||
const label = item[1].label;
|
||||
const url = item[1].url;
|
||||
if (objectItems.includes(item[0])) {
|
||||
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'>
|
||||
{item[0] === 'commit' ? `${label}...` : label}
|
||||
</Text>
|
||||
</Link>
|
||||
</Td>
|
||||
);
|
||||
}
|
||||
|
||||
if (item[0] === 'published') {
|
||||
return (
|
||||
<Td key={idx} px={4} textStyle='hero-text-small'>
|
||||
<Text>{getParsedDate(item[1])}</Text>
|
||||
</Td>
|
||||
);
|
||||
}
|
||||
|
||||
return (
|
||||
<Td key={idx} px={4} textStyle='hero-text-small'>
|
||||
<Link _hover={{ textDecoration: 'none' }} href={url} isExternal>
|
||||
<Text color='primary'>
|
||||
{item[0] === 'commit' ? `${label}...` : label}
|
||||
</Text>
|
||||
</Link>
|
||||
<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>
|
||||
);
|
||||
}
|
||||
|
||||
if (item[0] === 'published') {
|
||||
return (
|
||||
<Td key={idx} px={4} textStyle='hero-text-small'>
|
||||
<Text>{getParsedDate(item[1])}</Text>
|
||||
<Text>{item[1]}</Text>
|
||||
</Td>
|
||||
);
|
||||
}
|
||||
|
||||
return (
|
||||
<Td key={idx} px={4} textStyle='hero-text-small'>
|
||||
<Text>{item[1]}</Text>
|
||||
</Td>
|
||||
);
|
||||
})}
|
||||
</Tr>
|
||||
);
|
||||
})}
|
||||
})}
|
||||
</Tr>
|
||||
);
|
||||
})}
|
||||
</Tbody>
|
||||
</Table>
|
||||
</TableContainer>
|
||||
|
||||
33
src/components/UI/docs/Breadcrumbs.tsx
Normal file
33
src/components/UI/docs/Breadcrumbs.tsx
Normal file
@ -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>
|
||||
);
|
||||
};
|
||||
|
||||
81
src/components/UI/docs/DocsLinks.tsx
Normal file
81
src/components/UI/docs/DocsLinks.tsx
Normal file
@ -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>
|
||||
);
|
||||
59
src/components/UI/docs/DocsNav.tsx
Normal file
59
src/components/UI/docs/DocsNav.tsx
Normal file
@ -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>
|
||||
);
|
||||
};
|
||||
44
src/components/UI/docs/DocumentNav.tsx
Normal file
44
src/components/UI/docs/DocumentNav.tsx
Normal file
@ -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>
|
||||
);
|
||||
};
|
||||
35
src/components/UI/docs/LinkList.tsx
Normal file
35
src/components/UI/docs/LinkList.tsx
Normal file
@ -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>
|
||||
);
|
||||
153
src/components/UI/docs/MDComponents.tsx
Normal file
153
src/components/UI/docs/MDComponents.tsx
Normal file
@ -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;
|
||||
17
src/components/UI/docs/Note.tsx
Normal file
17
src/components/UI/docs/Note.tsx
Normal file
@ -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>
|
||||
);
|
||||
};
|
||||
8
src/components/UI/docs/index.ts
Normal file
8
src/components/UI/docs/index.ts
Normal file
@ -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,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';
|
||||
@ -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',
|
||||
|
||||
149
src/data/documentation-links.yaml
Normal file
149
src/data/documentation-links.yaml
Normal file
@ -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'
|
||||
}
|
||||
];
|
||||
42
src/hooks/useActiveHash.ts
Normal file
42
src/hooks/useActiveHash.ts
Normal file
@ -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>
|
||||
<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> */}
|
||||
</Stack>
|
||||
<ReactMarkdown remarkPlugins={[gfm]} components={ChakraUIRenderer(MDXComponents)}>
|
||||
{content}
|
||||
</ReactMarkdown>
|
||||
<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 {lastModified}
|
||||
</Text>
|
||||
</Stack>
|
||||
|
||||
<Flex width='100%' placeContent='space-between'>
|
||||
<Stack maxW='768px'>
|
||||
<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,19 +1,18 @@
|
||||
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/';
|
||||
|
||||
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>
|
||||
@ -512,9 +512,10 @@ const DownloadsPage: NextPage<Props> = ({ data }) => {
|
||||
</Text>
|
||||
</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>
|
||||
<Stack flex={1} w={'100%'} bg='terminal-bg'>
|
||||
<Code p={4} bg='code-bg'>
|
||||
gpg --recv-keys F9585DE6 C2FF8BBF 9BA28146 7B9E2481 D2A67EAC
|
||||
</Code>
|
||||
</Stack>
|
||||
</Flex>
|
||||
|
||||
@ -532,9 +533,10 @@ const DownloadsPage: NextPage<Props> = ({ data }) => {
|
||||
</Text>
|
||||
</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>
|
||||
<Stack flex={1} w={'100%'} bg='terminal-bg'>
|
||||
<Code p={4} bg='code-bg'>
|
||||
gpg --recv-keys E058A81C 05A5DDF0 1CCB7DD2
|
||||
</Code>
|
||||
</Stack>
|
||||
</Flex>
|
||||
|
||||
@ -554,8 +556,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.
|
||||
|
||||
@ -107,7 +107,7 @@ export const textStyles = {
|
||||
color: 'body'
|
||||
},
|
||||
'footer-link-label': {
|
||||
fontFamily: '"JetBrains Mono", monospace',
|
||||
fontFamily: 'heading',
|
||||
fontWeight: 700,
|
||||
textTransform: 'uppercase',
|
||||
lineHeight: '21.12px',
|
||||
@ -139,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'
|
||||
},
|
||||
@ -163,8 +178,25 @@ export const textStyles = {
|
||||
lineHeight: '21.12px',
|
||||
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;
|
||||
}
|
||||
|
||||
16
src/utils/getFileList.ts
Normal file
16
src/utils/getFileList.ts
Normal file
@ -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);
|
||||
};
|
||||
|
||||
18
src/utils/parseHeadingId.ts
Normal file
18
src/utils/parseHeadingId.ts
Normal file
@ -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
@ -1269,6 +1269,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"
|
||||
@ -2427,11 +2432,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"
|
||||
@ -2453,6 +2509,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"
|
||||
@ -2469,6 +2537,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"
|
||||
@ -2486,6 +2565,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"
|
||||
@ -3617,6 +3701,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"
|
||||
@ -3867,6 +3956,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"
|
||||
@ -4389,6 +4487,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
Block a user