feat: Add Do-not-Track link (#26833)
* chore: prettier * chore: update .env.local.example * feat: add dnt link to Footer
This commit is contained in:
Nicolás Quiroz
GitHub
parent
db99892edc
commit
00597017a5
@ -10,3 +10,4 @@ GITHUB_TOKEN_READ_ONLY=
|
||||
# Matomo
|
||||
NEXT_PUBLIC_MATOMO_URL=
|
||||
NEXT_PUBLIC_MATOMO_SITE_ID=
|
||||
NEXT_PUBLIC_MATOMO_OPT_OUT_URL=
|
||||
|
||||
@ -3,11 +3,10 @@ title: Config files
|
||||
description: How to configure geth using config files
|
||||
---
|
||||
|
||||
There are many flags and commands that can be provided to Geth on startup to influence how your node will behave. It is often convenient to configure these options in a file rather than typing them out on the command line every time you start your node. This can be done using a simple shell script to start Geth.
|
||||
There are many flags and commands that can be provided to Geth on startup to influence how your node will behave. It is often convenient to configure these options in a file rather than typing them out on the command line every time you start your node. This can be done using a simple shell script to start Geth.
|
||||
|
||||
There are also other configuration options that are not accessible from the command line but can be adjusted by providing Geth with a config file. This gives access to lower level configuration that influences how some of Geth's internal components behave.
|
||||
|
||||
|
||||
## Shell scripts
|
||||
|
||||
The benefit of writing a shell script for starting a Geth node is that it is more easily repeatable and you don't have to remember lots of syntax for making a node behave in a certain way. This is especially useful for running multiple nodes with their own specific configurations.
|
||||
@ -162,4 +161,4 @@ InfluxDBTags = "host=localhost"
|
||||
InfluxDBToken = "test"
|
||||
InfluxDBBucket = "geth"
|
||||
InfluxDBOrganization = "geth"
|
||||
```
|
||||
```
|
||||
|
||||
@ -53,7 +53,6 @@ If Geth stops unexpectedly the database can be corrupted. This is known as an "u
|
||||
|
||||
If an unexpected shutdown does occur, the `removedb` subcommand can be used to delete the state database and resync it from the ancient database. This should get the database back up and running.
|
||||
|
||||
|
||||
## Pebble
|
||||
|
||||
It is possible to configure Geth to use [Pebble](https://www.cockroachlabs.com/blog/pebble-rocksdb-kv-store/) instead of LevelDB for recent data. The main reason to include the alternative database is that the Go implementation of LevelDB is not actively maintained; Pebble is an actively maintained replacement that should offer a better long term option. There is no urgent reason to switch the database type yet - LevelDB works well and Pebble is still being evaluated for potentially replacing LevelDB as the default option some time in the future. However, if you wish to experiment with running Geth with Pebble, add the following flag to your Geth startup commands:
|
||||
@ -62,4 +61,4 @@ It is possible to configure Geth to use [Pebble](https://www.cockroachlabs.com/b
|
||||
--db.engine=pebble
|
||||
```
|
||||
|
||||
This also requires resyncing from scratch in a fresh data directory, because if an existing LevelDB database is detected on startup, Geth will default to using that, overriding the `--db.engine=pebble` flag. Pebble only works on 64 bit systems.
|
||||
This also requires resyncing from scratch in a fresh data directory, because if an existing LevelDB database is detected on startup, Geth will default to using that, overriding the `--db.engine=pebble` flag. Pebble only works on 64 bit systems.
|
||||
|
||||
@ -3,8 +3,8 @@ title: Batch requests
|
||||
description: How to make batch requests using JSON-RPC API
|
||||
---
|
||||
|
||||
The JSON-RPC [specification](https://www.jsonrpc.org/specification#batch) outlines how clients can send multiple requests at the same time by filling the request objects in an array. This feature is implemented by Geth's API and can be used to cut network delays. Batching offers visible speed-ups specially when used for fetching larger amounts of mostly independent data objects.
|
||||
|
||||
The JSON-RPC [specification](https://www.jsonrpc.org/specification#batch) outlines how clients can send multiple requests at the same time by filling the request objects in an array. This feature is implemented by Geth's API and can be used to cut network delays. Batching offers visible speed-ups specially when used for fetching larger amounts of mostly independent data objects.
|
||||
|
||||
Below is an example for fetching a list of blocks in JS:
|
||||
|
||||
```js
|
||||
@ -38,10 +38,10 @@ main()
|
||||
.catch(err => console.log(err));
|
||||
```
|
||||
|
||||
In this case there's no dependency between the requests. Often the retrieved data from one request is needed to issue a second one. Let's take the example of fetching all the receipts for a range of blocks. The JSON-RPC API provides `eth_getTransactionReceipt` which takes in a transaction hash and returns the corresponding receipt object, but no method to fetch receipt objects for a whole block. We need to get the list of transactions in a block and then call `eth_getTransactionReceipt` for each of them.
|
||||
|
||||
In this case there's no dependency between the requests. Often the retrieved data from one request is needed to issue a second one. Let's take the example of fetching all the receipts for a range of blocks. The JSON-RPC API provides `eth_getTransactionReceipt` which takes in a transaction hash and returns the corresponding receipt object, but no method to fetch receipt objects for a whole block. We need to get the list of transactions in a block and then call `eth_getTransactionReceipt` for each of them.
|
||||
|
||||
We can break this into 2 batch requests:
|
||||
|
||||
|
||||
- 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
|
||||
|
||||
|
||||
@ -3,7 +3,6 @@ title: personal Namespace
|
||||
description: Documentation for the JSON-RPC API "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 has **now been 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. The first section on this page shows the suggested replacement for each method in `personal`. The second section shows the deprecated methods for archival purposes.
|
||||
|
||||
## Method replacements
|
||||
@ -225,8 +224,6 @@ Unpair deletes a pairing between some specific types of smartcard wallet and Get
|
||||
|
||||
InitializeWallet is for initializing some specific types of smartcard wallet at a provided URL. There is not yet a corresponding method in Clef.
|
||||
|
||||
|
||||
|
||||
## Deprecated method documentation
|
||||
|
||||
The personal API managed private keys in the key store. It is now deprecated in favour of using [Clef](/docs/tools/clef/introduction) for interacting with accounts. The following documentation should be treated as archive information and users should migrate to using Clef for account interactions.
|
||||
|
||||
@ -34,11 +34,8 @@ to cancel the subscription:
|
||||
## Considerations {#considerations}
|
||||
|
||||
1. Notifications are sent for current events and not for past events. For use cases that cannot afford to miss any notifications, subscriptions are probably not the best option.
|
||||
|
||||
2. Subscriptions require a full duplex connection. Geth offers such connections in the form of WebSocket and IPC (enabled by default).
|
||||
|
||||
3. Subscriptions are coupled to a connection. If the connection is closed all subscriptions that are created over this connection are removed.
|
||||
|
||||
4. Notifications are stored in an internal buffer and sent from this buffer to the client. If the client is unable to keep up and the number of buffered notifications reaches a limit (currently 10k) the connection is closed. Keep in mind that subscribing to some events can cause a flood of notifications, e.g. listening for all logs/blocks when the node starts to synchronize.
|
||||
|
||||
## Create subscription {#create-subscriptions}
|
||||
|
||||
@ -29,7 +29,7 @@ The CPU panel shows how much CPU is being used as a percentage of one processing
|
||||
|
||||
|
||||
|
||||
Memory tracks the amount of RAM being used by Geth. Three metrics are plotted: the cache size, i.e. the total RAM reserved for Geth (default 1024 MB) is plotted as `held`; the amount of the cache actually being used by Geth is plotted as `used`; the number of bytes being allocated by the system per second is plotted as `alloc`.
|
||||
Memory tracks the amount of RAM being used by Geth. Three metrics are plotted: the cache size, i.e. the total RAM reserved for Geth (default 1024 MB) is plotted as `held`; the amount of the cache actually being used by Geth is plotted as `used`; the number of bytes being allocated by the system per second is plotted as `alloc`.
|
||||
|
||||
#### Disk
|
||||
|
||||
@ -39,7 +39,7 @@ Disk tracks the rate that data is written to (plotted as `write`) or read from (
|
||||
|
||||
#### Goroutines
|
||||
|
||||
Tracks the total number of active goroutines being used by Geth. Goroutines are lighweight threads managed by the Go runtime, they allow processes to
|
||||
Tracks the total number of active goroutines being used by Geth. Goroutines are lighweight threads managed by the Go runtime, they allow processes to
|
||||
execute concurrently.
|
||||
|
||||
|
||||
@ -105,7 +105,7 @@ Geth has a capacity for pending transactions defined by `--txpool.globalslots` (
|
||||
The block processing panel tracks the time taken to complete the various tasks involved in processing each block, measured in microseconds or nanoseconds. Specifically, this includes:
|
||||
|
||||
- **execution**: time taken to execute the transactions in the block
|
||||
- **validation**: time taken to validate that the information in a received block body matches what is described in the block header.
|
||||
- **validation**: time taken to validate that the information in a received block body matches what is described in the block header.
|
||||
- **commit**: time taken to write the new block to the chain data
|
||||
- **account read**: time taken to access account information from the state trie
|
||||
- **account update**: time taken to incorporate dirty account objects into the state trie (account trie)
|
||||
@ -142,7 +142,6 @@ The transaction processing panel tracks the time taken to complete the various t
|
||||
|
||||
#### Block propagation
|
||||
|
||||
|
||||
<Note>
|
||||
Block propagation was disabled in Geth at The Merge. Block propagation is now the responsibility of the consensus client. Included here for archival interest.
|
||||
</Note>
|
||||
@ -156,15 +155,14 @@ Block propagation metrics track the rate that the local node hears about, receiv
|
||||
- **known broadcasts**: counts all blocks that have been broadcast by peers including those that are too far behind the head to be downloaded.
|
||||
- **malicious broadcasts**: the number of blocks which are determined to be malicious per second
|
||||
|
||||
|
||||
#### Transaction propagation
|
||||
|
||||
Transaction propagation tracks the sending and receiving of transactions on the peer-to-peer network. This includes:
|
||||
|
||||
- **ingress announcements**: inbound announcements (notifications of a transaction's availability) per second
|
||||
- **known announcements**: announcements that are ignored because the local node is already aware of them, per second
|
||||
- **underpriced announcements**: announcements per second that do not get fetched because they pay too little gas
|
||||
- **malicious announcements**: announcements per second that are dropped because they appear malicious
|
||||
- **underpriced announcements**: announcements per second that do not get fetched because they pay too little gas
|
||||
- **malicious announcements**: announcements per second that are dropped because they appear malicious
|
||||
- **ingress broadcasts**: number of transactions propagated from peers per second
|
||||
- **known broadcasts**: transactions per second that are ignored because they duplicate transactions that the local node already knows about
|
||||
- **underpriced broadcasts**: all fetched transactions that are dropped due to paying insufficient gas, per second
|
||||
@ -181,7 +179,7 @@ Transaction propagation tracks the sending and receiving of transactions on the
|
||||
|
||||
#### Block forwarding
|
||||
|
||||
The block forwarding panel counts the announcements and the blocks that the local node receives that it should pass on to its peers.
|
||||
The block forwarding panel counts the announcements and the blocks that the local node receives that it should pass on to its peers.
|
||||
|
||||
#### Transaction fetcher peers
|
||||
|
||||
@ -209,10 +207,10 @@ measures the rate that data is written to, or read from, the levelDB and ancient
|
||||
- **ancient write**: Rate that data is written to the freezer (the database storing older data)
|
||||
- **compaction read**: Rate that data is written to the levelDb database while it is being compacted (i.e. free space is reclaimed by deleting uneccessary data)
|
||||
- **compaction write**: Rate that data is read from to the levelDB database while it is being compacted (i.e. free space is reclaimed by deleting uneccessary data)
|
||||
|
||||
|
||||
#### Session totals
|
||||
|
||||
Instead of the *rate* that data is read from, and written to, the levelDB and ancients databases (as per `Data rate`), this panel tracks the total amount of data read and written across the entire time Geth is running.
|
||||
Instead of the _rate_ that data is read from, and written to, the levelDB and ancients databases (as per `Data rate`), this panel tracks the total amount of data read and written across the entire time Geth is running.
|
||||
|
||||
#### Persistent size
|
||||
|
||||
@ -226,7 +224,6 @@ These panels show the amount of time spent compacting the levelDB database, dura
|
||||
The current default Geth Grafana dashboard includes panels for light nodes. Light nodes are not currently functional since Ethereum moved to proof-of-stake.
|
||||
</Note>
|
||||
|
||||
|
||||
## Creating new dashboards
|
||||
|
||||
If the default dashboard isn't right for you, you can update it in the browser. Remove panels by clicking on their titles and selectign `remove`. Add a new panel by clicking the "plus" icon in the upper right of the browser window. There, you will have to define an InfluxDB query for the metric you want to display. The endpoints for the various metrics that Geth reports are listed by Geth at the address/port combination passed to `--metrics.addr` and `metrics.port` on startup - by default `127.0.0.1:6060/debug/metrics`. It is also possible to configure a panel by providing a JSON configuration model. Individial components are defined using the following syntax (the example below is for the CPU panel):
|
||||
@ -294,9 +291,7 @@ If the default dashboard isn't right for you, you can update it in the browser.
|
||||
"format": "time_series",
|
||||
"groupBy": [
|
||||
{
|
||||
"params": [
|
||||
"$interval"
|
||||
],
|
||||
"params": ["$interval"],
|
||||
"type": "time"
|
||||
}
|
||||
],
|
||||
@ -310,9 +305,7 @@ If the default dashboard isn't right for you, you can update it in the browser.
|
||||
"select": [
|
||||
[
|
||||
{
|
||||
"params": [
|
||||
"value"
|
||||
],
|
||||
"params": ["value"],
|
||||
"type": "field"
|
||||
},
|
||||
{
|
||||
@ -339,9 +332,7 @@ If the default dashboard isn't right for you, you can update it in the browser.
|
||||
"format": "time_series",
|
||||
"groupBy": [
|
||||
{
|
||||
"params": [
|
||||
"$interval"
|
||||
],
|
||||
"params": ["$interval"],
|
||||
"type": "time"
|
||||
}
|
||||
],
|
||||
@ -355,9 +346,7 @@ If the default dashboard isn't right for you, you can update it in the browser.
|
||||
"select": [
|
||||
[
|
||||
{
|
||||
"params": [
|
||||
"value"
|
||||
],
|
||||
"params": ["value"],
|
||||
"type": "field"
|
||||
},
|
||||
{
|
||||
@ -384,9 +373,7 @@ If the default dashboard isn't right for you, you can update it in the browser.
|
||||
"format": "time_series",
|
||||
"groupBy": [
|
||||
{
|
||||
"params": [
|
||||
"$interval"
|
||||
],
|
||||
"params": ["$interval"],
|
||||
"type": "time"
|
||||
}
|
||||
],
|
||||
@ -400,9 +387,7 @@ If the default dashboard isn't right for you, you can update it in the browser.
|
||||
"select": [
|
||||
[
|
||||
{
|
||||
"params": [
|
||||
"value"
|
||||
],
|
||||
"params": ["value"],
|
||||
"type": "field"
|
||||
},
|
||||
{
|
||||
|
||||
@ -133,7 +133,12 @@ export const Footer: FC = () => {
|
||||
borderColor='primary'
|
||||
flex={1}
|
||||
>
|
||||
<Text textStyle='footer-text'>{`© 2013–${new Date().getFullYear()}. The go-ethereum Authors.`}</Text>
|
||||
<Text textStyle='footer-text'>
|
||||
{`© 2013–${new Date().getFullYear()}. The go-ethereum Authors`} |{' '}
|
||||
<Link isExternal variant='light' href={process.env.NEXT_PUBLIC_MATOMO_OPT_OUT_URL}>
|
||||
Do-not-Track
|
||||
</Link>
|
||||
</Text>
|
||||
</Center>
|
||||
</Flex>
|
||||
);
|
||||
|
||||
Loading…
Reference in New Issue
Block a user