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
Update Lighthouse Book API and Advanced Usage section (#4300)
## Issue Addressed
Update Information in Lighthouse Book
## Proposed Changes
- move Validator Graffiti from Advanced Usage to Validator Management
- update API response and command
- some items that aren't too sure I put it in comment, which can be seen in raw/review format but not live
## Additional Info
Please provide any additional information. For example, future considerations
or information useful for reviewers.
Co-authored-by: chonghe <[email protected]>
From time-to-time, Lighthouse *release candidates* will be published on the [sigp/lighthouse]
10
-
repository. These releases have passed the usual automated testing, however the developers would
10
+
repository. Release candidates are previously known as Pre-Releases. These releases have passed the usual automated testing, however the developers would
11
11
like to see it running "in the wild" in a variety of configurations before declaring it an official,
12
12
stable release. Release candidates are also used by developers to get feedback from users regarding the
13
13
ergonomics of new features or changes.
@@ -36,8 +36,9 @@ Users may wish to try a release candidate for the following reasons:
36
36
- To help detect bugs and regressions before they reach production.
37
37
- To provide feedback on annoyances before they make it into a release and become harder to change or revert.
38
38
39
+
There can also be a scenario that a bug has been found and requires an urgent fix. An example of incidence is [v4.0.2-rc.0](https://github.com/sigp/lighthouse/releases/tag/v4.0.2-rc.0) which contains a hot-fix to address high CPU usage experienced after the [Capella](https://ethereum.org/en/history/#capella) upgrade on 12<sup>th</sup> April 2023. In this scenario, we will announce the release candidate on [Github](https://github.com/sigp/lighthouse/releases) and also on [Discord](https://discord.gg/cyAszAh) to recommend users to update to the release candidate version.
40
+
39
41
## When *not* to use a release candidate
40
42
41
-
It is not recommended to use release candidates for any critical tasks on mainnet (e.g., staking).
42
-
To test critical features, try one of the testnets (e.g., Prater).
43
+
Other than the above scenarios, it is generally not recommended to use release candidates for any critical tasks on mainnet (e.g., staking). To test new release candidate features, try one of the testnets (e.g., Goerli).
| Validator only (default) | 8192 | 8.1 GB | 41 s |
31
33
32
-
As you can see, it's a high-stakes trade-off! The relationships to disk usage and historical state
34
+
*Last update: May 2023.
35
+
36
+
As we can see, it's a high-stakes trade-off! The relationships to disk usage and historical state
33
37
load time are both linear – doubling SPRP halves disk usage and doubles load time. The minimum SPRP
34
38
is 32, and the maximum is 8192.
35
39
@@ -38,9 +42,11 @@ The default value is 8192 for databases synced from scratch using Lighthouse v2.
38
42
39
43
The values shown in the table are approximate, calculated using a simple heuristic: each
40
44
`BeaconState` consumes around 18MB of disk space, and each block replayed takes around 5ms. The
41
-
**Yearly Disk Usage** column shows the approx size of the freezer DB _alone_ (hot DB not included),
42
-
and the **Load Historical State** time is the worst-case load time for a state in the last slot
43
-
before a restore point.
45
+
**Yearly Disk Usage** column shows the approximate size of the freezer DB _alone_ (hot DB not included), calculated proportionally using the total freezer database disk usage.
46
+
The **Load Historical State** time is the worst-case load time for a state in the last slot
47
+
before a restore point.
48
+
49
+
As an example, we use an SPRP of 4096 to calculate the total size of the freezer database until May 2023. It has been about 900 days since the genesis, the total disk usage by the freezer database is therefore: 900/365*26.8 GB = 66 GB.
44
50
45
51
### Defaults
46
52
@@ -68,6 +74,8 @@ The historical state cache size can be specified with the flag `--historic-state
Copy file name to clipboardExpand all lines: book/src/advanced_networking.md
+24-2Lines changed: 24 additions & 2 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -51,7 +51,7 @@ peers for your node and overall improve the Ethereum consensus network.
51
51
Lighthouse currently supports UPnP. If UPnP is enabled on your router,
52
52
Lighthouse will automatically establish the port mappings for you (the beacon
53
53
node will inform you of established routes in this case). If UPnP is not
54
-
enabled, we recommend you manually set up port mappings to both of Lighthouse's
54
+
enabled, we recommend you to manually set up port mappings to both of Lighthouse's
55
55
TCP and UDP ports (9000 by default).
56
56
57
57
> Note: Lighthouse needs to advertise its publicly accessible ports in
@@ -63,6 +63,28 @@ TCP and UDP ports (9000 by default).
63
63
> explicitly specify them using the `--enr-tcp-port` and `--enr-udp-port` as
64
64
> explained in the following section.
65
65
66
+
### How to Open Ports
67
+
68
+
The steps to do port forwarding depends on the router, but the general steps are given below:
69
+
1. Determine the default gateway IP:
70
+
- On Linux: open a terminal and run `ip route | grep default`, the result should look something similar to `default via 192.168.50.1 dev wlp2s0 proto dhcp metric 600`. The `192.168.50.1` is your router management default gateway IP.
71
+
- On MacOS: open a terminal and run `netstat -nr|grep default` and it should return the default gateway IP.
72
+
- On Windows: open a command prompt and run `ipconfig` and look for the `Default Gateway` which will show you the gateway IP.
73
+
74
+
The default gateway IP usually looks like 192.168.X.X. Once you obtain the IP, enter it to a web browser and it will lead you to the router management page.
75
+
76
+
2. Login to the router management page. The login credentials are usually available in the manual or the router, or it can be found on a sticker underneath the router. You can also try the login credentials for some common router brands listed [here](https://www.noip.com/support/knowledgebase/general-port-forwarding-guide/).
77
+
78
+
3. Navigate to the port forward settings in your router. The exact step depends on the router, but typically it will fall under the "Advanced" section, under the name "port forwarding" or "virtual server".
79
+
80
+
4. Configure a port forwarding rule as below:
81
+
- Protocol: select `TCP/UDP` or `BOTH`
82
+
- External port: `9000`
83
+
- Internal port: `9000`
84
+
- IP address: Usually there is a dropdown list for you to select the device. Choose the device that is running Lighthouse
85
+
86
+
5. To check that you have successfully open the ports, go to [yougetsignal](https://www.yougetsignal.com/tools/open-ports/) and enter `9000` in the `port number`. If it shows "open", then you have successfully set up port forwarding. If it shows "closed", double check your settings, and also check that you have allowed firewall rules on port 9000.
87
+
66
88
67
89
### ENR Configuration
68
90
@@ -81,7 +103,7 @@ and if it is, it will update your ENR to the correct public IP and port address
81
103
(meaning you do not need to set it manually). Lighthouse persists its ENR, so
82
104
on reboot it will re-load the settings it had discovered previously.
83
105
84
-
Modifying the ENR settings can degrade the discovery of your node making it
106
+
Modifying the ENR settings can degrade the discovery of your node, making it
85
107
harder for peers to find you or potentially making it harder for other peers to
86
108
find each other. We recommend not touching these settings unless for a more
Copy file name to clipboardExpand all lines: book/src/api-bn.md
+35-21Lines changed: 35 additions & 21 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -5,7 +5,7 @@ specification][OpenAPI]. Please follow that link for a full description of each
5
5
6
6
## Starting the server
7
7
8
-
A Lighthouse beacon node can be configured to expose a HTTP server by supplying the `--http` flag. The default listen address is `127.0.0.1:5052`.
8
+
A Lighthouse beacon node can be configured to expose an HTTP server by supplying the `--http` flag. The default listen address is `http://127.0.0.1:5052`.
9
9
10
10
The following CLI flags control the HTTP server:
11
11
@@ -55,11 +55,8 @@ Additional risks to be aware of include:
55
55
56
56
## CLI Example
57
57
58
-
Start the beacon node with the HTTP server listening on [http://localhost:5052](http://localhost:5052):
58
+
Start a beacon node and an execution node according to [Run a node](./run_a_node.md). Note that since [The Merge](https://ethereum.org/en/roadmap/merge/), an execution client is required to be running along with a beacon node. Hence, the query on Beacon Node APIs requires users to run both. While there are some Beacon Node APIs that you can query with only the beacon node, such as the [node version](https://ethereum.github.io/beacon-APIs/#/Node/getNodeVersion), in general an execution client is required to get the updated information about the beacon chain, such as [state root](https://ethereum.github.io/beacon-APIs/#/Beacon/getStateRoot), [headers](https://ethereum.github.io/beacon-APIs/#/Beacon/getBlockHeaders) and many others, which are dynamically progressing with time.
The `jq` tool is used to format the JSON data properly. If it returns `jq: command not found`, then you can install `jq` with `sudo apt install -y jq`. After that, run the command again, and it should return the head state of the beacon chain.
97
+
97
98
### View the status of a validator
98
99
99
100
Shows the status of validator at index `1` at the `head` state.
100
101
101
102
```bash
102
-
curl -X GET "http://localhost:5052/eth/v1/beacon/states/head/validators/1" -H "accept: application/json"| jq
103
+
curl -X GET "http://localhost:5052/eth/v1/beacon/states/head/validators/1" -H "accept: application/json"
@@ -121,6 +124,7 @@ curl -X GET "http://localhost:5052/eth/v1/beacon/states/head/validators/1" -H "
121
124
}
122
125
}
123
126
```
127
+
You can replace `1` in the above command with the validator index that you would like to query. Other API query can be done similarly by changing the link according to the Beacon API.
124
128
125
129
## Serving the HTTP API over TLS
126
130
> **Warning**: This feature is currently experimental.
Note that currently Lighthouse only accepts keys that are not password protected.
148
152
This means we need to run with the `-nodes` flag (short for 'no DES').
149
153
150
-
Once generated, we can run Lighthouse:
154
+
Once generated, we can run Lighthouse and an execution node according to [Run a node](./run_a_node.md). In addition, add the flags `--http-enable-tls --http-tls-cert cert.pem --http-tls-key key.pem` to Lighthouse, the command should look like:
0 commit comments