You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: CHANGELOG.md
+76-1Lines changed: 76 additions & 1 deletion
Original file line number
Diff line number
Diff line change
@@ -1,3 +1,78 @@
1
+
2023-03-11 v23.3.0
2
+
==================
3
+
4
+
Nimbus `v23.3.0` is `low-urgency` upgrade bringing full support for the upcoming Capella hard-fork on the Goerli testnet. Keep an eye out for future mainnet releases!
5
+
6
+
### Improvements
7
+
8
+
* You can now increase the resilience of your setup and eliminate any downtime during upgrade procedures of the execution client software by allowing your beacon node to manage multiple execution clients. To enable this mode, just specify multiple URLs through the `--el` option (alias of `--web3-url`) when starting your beacon node:
9
+
10
+
```sh
11
+
./run-mainnet-beacon-node.sh \
12
+
--el=http://127.0.0.1:8551 \
13
+
--el=ws://other:8551 \
14
+
--jwt-secret=/tmp/jwtsecret
15
+
```
16
+
17
+
As long as only one of execution clients remains operational and fully synced, Nimbus will keep performing all validator duties.
18
+
19
+
If you use this mode with different execution client implementations, Nimbus will act as an execution layer consensus violation detector, preventing the publishing of blocks that may trigger a catastrophic partitioning in the network.
* The metrics `engine_api_responses`, `engine_api_request_duration_seconds` and `engine_api_timeouts` provide statistics about latency and response status codes for all requests sent to each individual execution layer URL:
* Nimbus will now attempt to connect to a locally running execution client even when the options `--el` and `--jwt-secret` are not specified. This is made possible by the following proposed standard:
* Improved diagnostic messages and more spec-compliant behavior of the Nimbus validator client when being paired with a non-synced or optimistically synced beacon nodes:
* Nimbus now downloads a longer range of recent execution blocks in order to avoid potential situations where our `Eth1Data` votes fail to agree with the honest majority in the network:
Copy file name to clipboardExpand all lines: docs/the_nimbus_book/src/eth1.md
+32-28Lines changed: 32 additions & 28 deletions
Original file line number
Diff line number
Diff line change
@@ -8,7 +8,7 @@ Nimbus has been tested all major execution clients - see the [execution client c
8
8
You need to run your own execution client - relying on third-party services such as Infura, Alchemy and Pocket is no longer possible. Sharing the same execution client between multiple beacon nodes is not supported.
9
9
10
10
!!! info
11
-
Syncing an execution client may take hours or even days, depending on your hardware! The backup providers will be synced only when the primary becomes unavailable, which may lead to a small gap in validation duties - this limitation may be lifted in future versions.
11
+
Syncing an execution client may take hours or even days, depending on your hardware!
12
12
13
13
## Steps
14
14
@@ -28,7 +28,7 @@ Select an execution client and install it, configuring it such that that the aut
28
28
29
29
#### 2. Start Geth
30
30
31
-
Once you have geth installed, make sure to enable the JSON-RPC WebSocket interface when running geth, along with the options for creating an [autheticated RPC endpoint](https://geth.ethereum.org/docs/interface/consensus-clients):
31
+
Once you have geth installed, make sure to enable the [authenticated JSON-RPC interface](https://geth.ethereum.org/docs/getting-started/consensus-clients) when running geth:
32
32
33
33
=== "Mainnet"
34
34
```
@@ -40,21 +40,6 @@ Select an execution client and install it, configuring it such that that the aut
Let it syns - it may take anywhere between a few hours and a couple of days.
46
-
47
-
You'll know Geth has finished syncing, when you start seeing logs that look like the following:
48
-
49
-
```
50
-
INFO [05-29|01:16:05] Imported new chain segment blocks=1 txs=3 mgas=0.065 elapsed=5.885ms mgasps=11.038 number=3785445 hash=553d9e…fc4547
51
-
INFO [05-29|01:16:10] Imported new chain segment blocks=1 txs=0 mgas=0.000 elapsed=5.447ms mgasps=0.000 number=3785446 hash=5e3e7d…bd4afd
52
-
INFO [05-29|01:16:10] Imported new chain segment blocks=1 txs=1 mgas=0.021 elapsed=7.382ms mgasps=2.845 number=3785447 hash=39986c…dd2a01
53
-
INFO [05-29|01:16:14] Imported new chain segment blocks=1 txs=11 mgas=1.135 elapsed=22.281ms mgasps=50.943 number=3785444 hash=277bb9…623d8c
54
-
```
55
-
56
-
Geth accepts connections from the localhost interface (`127.0.0.1`), with default authenticated RPC port `8551`. This means that your default Web3 provider URL should be: `http://127.0.0.1:8551`
57
-
58
43
=== "Nethermind"
59
44
60
45
See the [Getting started](https://docs.nethermind.io/nethermind/first-steps-with-nethermind/getting-started) guide to set up Nethermind.
@@ -81,30 +66,49 @@ It is safe to start the beacon node even if the execution client is not yet full
81
66
82
67
### 3. Pass the URL and JWT secret to Nimbus
83
68
84
-
The `--web3-url` option informs the beacon node how to connect to the execution client - both `http://` and `ws://` URLs are supported.
69
+
The `--el` option informs the beacon node how to connect to the execution client - both `http://` and `ws://` URLs are supported.
70
+
71
+
!!! info
72
+
By default, the execution client accepts connections on the localhost interface (`127.0.0.1`), with default authenticated RPC port `8551`. When the `--el` option is not explicitly specified, Nimbus will assume that the execution client is running on the same machine with such default settings.
85
73
86
74
Once started, the execution client will create a file containing a JWT secret token. The token file is needed for Nimbus to authenticate itself with the execution client and perform trusted operations. You will need to pass the path to the token file to Nimbus together with the web3 URL.
87
75
88
76
=== "Mainnet"
89
77
```sh
90
78
./run-mainnet-beacon-node.sh \
91
-
--web3-url=http://127.0.0.1:8551\
79
+
--el=http://127.0.0.1:8551\
92
80
--jwt-secret=/tmp/jwtsecret
93
81
```
94
82
95
83
=== "Prater"
96
84
```sh
97
85
./run-prater-beacon-node.sh \
98
-
--web3-url=http://127.0.0.1:8551\
86
+
--el=http://127.0.0.1:8551\
99
87
--jwt-secret=/tmp/jwtsecret
100
88
```
101
89
102
-
!!! tip "Multiple execution clients"
103
-
You can pass one or more `--web3-url` parameters to the node as long as they share JWT secret. Any additional web3 URLs will be used for backup, should the first one become unavailable:
90
+
!!! info
91
+
When the `--jwt-secret` option is not specified and the execution client is running on the same machine under default setting, Nimbus may be able to connect successfully to it by using the default secret value `0xd4e56740f876aef8c010b86a40d5f56745a118d0906a34e69aec8c0db1cb8fa3`. This is a [proposed standard protocol](https://github.com/ethereum/execution-apis/pull/302) that aims to simplify the required user configuration, but it's not yet adopted by all execution clients.
104
92
105
-
```sh
106
-
./run-mainnet-beacon-node.sh \
107
-
--web3-url=http://127.0.0.1:8551 \
108
-
--web3-url=ws://other:8551 \
109
-
--jwt-secret=/tmp/jwtsecret
110
-
```
93
+
## Advanced setups
94
+
95
+
### Running multiple execution clients
96
+
97
+
You can increase the resilience of your setup and eliminate any downtime during upgrade procedure of the execution client software by allowing your beacon node to manage multiple execution clients. To enable this mode, just specify multiple URLs through the `--el` option when starting your beacon node:
98
+
99
+
```sh
100
+
./run-mainnet-beacon-node.sh \
101
+
--el=http://127.0.0.1:8551 \
102
+
--el=ws://other:8551 \
103
+
--jwt-secret=/tmp/jwtsecret
104
+
```
105
+
106
+
!!! tip
107
+
You can use a different secret for each connection by specifying `jwtSecret` or `jwtSecretFile` as a query parameter in the anchor section of the URL (e.g. `http://127.0.0.1:8551/#jwtSecret=0x12345...` or `http://127.0.0.1:8551/#jwtSecretFile=/tmp/jwtsecret`).
108
+
109
+
As long as only one of execution clients remains operational and fully synced, Nimbus will keep performing all validator duties.
110
+
111
+
!!! tip
112
+
To carry out an upgrade procedure without any downtime, just restart the execution clients one by one, waiting for each instance to re-sync before moving to the next one.
113
+
114
+
If you use this mode with different execution client implementations, Nimbus will act as an execution layer consensus violation detector, preventing the publishing of blocks that may trigger a catastrophic partitioning in the network.
0 commit comments