Update Lighthouse book (#8284)

Co-Authored-By: Tan Chee Keong <[email protected]>

Co-Authored-By: chonghe <[email protected]>

Author: chong-he

book/src/advanced.md

@@ -19,4 +19,4 @@ tips about how things work under the hood.
 * [Release Candidates](./advanced_release_candidates.md): latest release of Lighthouse to get feedback from users.
 * [Maximal Extractable Value](./advanced_builders.md): use external builders for a potential higher rewards during block proposals
 * [Late Block Re-orgs](./advanced_re-orgs.md): read information about Lighthouse late block re-orgs.
-* [Blobs](./advanced_blobs.md): information about blobs in Deneb upgrade
+* [Blobs](./advanced_blobs.md): information about blobs

book/src/advanced_blobs.md

@@ -1,4 +1,27 @@
-# Blobs
+# Data columns
+
+With the [Fusaka](https://ethereum.org/roadmap/fusaka) upgrade, the main feature [PeerDAS](https://ethereum.org/roadmap/fusaka#peerdas) allows storing only a portion of blob data, known as data columns, thus reducing the storage and bandwidth requirements of a full node. This however also means that a full node will not be able to serve blobs after Fusaka. To continue serving blobs, run the beacon node with `--semi-supernode` or `--supernode`. Note that this comes at a significant increase in storage and bandwidth requirements, see [this blog post about PeerDAS](https://blog.sigmaprime.io/peerdas-distributed-blob-building.html) and [Fusaka bandwidth estimation](https://ethpandaops.io/posts/fusaka-bandwidth-estimation/) for more details.
+
+> Note: the above assumes that the beacon node has no attached validators. If the beacon node has attached validators, then it is required to custody (store) a certain number of data columns which increases with the number of staked ETH. For example, if the staked ETH is `$\geq$` 2048 ETH, then due to custody requirement, it will make the beacon node a semi-supernode ; if `$\geq$` 4096 ETH, the beacon node will be a supernode without needing the flag.
+
+Table below summarizes the role of relevant flags in Lighthouse beacon node:
+
+| | Post-Deneb, Pre-Fulu || Post-Fulu ||
+|-------|----------|----------|-----------|----------|
+| Flag | Usage | Can serve blobs? | Usage | Can serve blobs? |
+| --prune-blobs false | Does not prune blobs since using the flag | Yes, for blobs since using the flag and for the past 18 days | Does not prune data columns since using the flag | No |
+| --semi-supernode | - | - | Store half data columns | Yes, for blobs since using the flag for a max of 18 days |
+| --supernode | - | - | Store all data columns | Yes, for blobs since using the flag for a max of 18 days |
+
+While both `--supernode` and `--semi-supernode` can serve blobs, a supernode will be faster to respond to blobs queries as it skips the blob reconstruction step. Running a supernode also helps the network by serving the data columns to its peers.
+
+Combining `--prune-blobs false` and `--supernode` (or `--semi-supernode`) implies that no data columns will be pruned, and the node will be able to serve blobs since using the flag.
+
+If you want historical blob data beyond the data availability period (18 days), you can backfill blobs or data columns with the experimental flag `--complete-blobs-backfill`. However, do note that this is an experimental feature and it may cause some issues, e.g., the node may block most of its peers.
+
+**⚠️ The following section on Blobs is archived and not maintained as blobs are stored in the form of data columns after the Fulu fork ⚠️**
+
+## Blobs
 
 In the Deneb network upgrade, one of the changes is the implementation of EIP-4844, also known as [Proto-danksharding](https://blog.ethereum.org/2024/02/27/dencun-mainnet-announcement). Alongside with this, a new term named `blob` (binary large object) is introduced. Blobs are "side-cars" carrying transaction data in a block. They are mainly used by Ethereum layer 2 operators. As far as stakers are concerned, the main difference with the introduction of blobs is the increased storage requirement.
 

book/src/advanced_checkpoint_sync.md

@@ -82,7 +82,7 @@ Once backfill is complete, a `INFO Historical block download complete` log will
 1. What if I have an existing database? How can I use checkpoint sync?
 
     The existing beacon database needs to be deleted before Lighthouse will attempt checkpoint sync.
-    You can do this by providing the `--purge-db` flag, or by manually deleting `<DATADIR>/beacon`.
+    You can do this by providing the `--purge-db-force` flag, or by manually deleting `<DATADIR>/beacon`.
 
 1. Why is checkpoint sync faster?
 
@@ -92,7 +92,7 @@ Once backfill is complete, a `INFO Historical block download complete` log will
 
     No, in fact it is more secure! Checkpoint sync guards against long-range attacks that genesis sync does not. This is due to a property of Proof of Stake consensus known as [Weak Subjectivity][weak-subj].
 
-## Reconstructing States
+## How to run an archived node
 
 > This section is only relevant if you are interested in running an archival node for analysis
 > purposes.
@@ -101,7 +101,7 @@ After completing backfill sync the node's database will differ from a genesis-sy
 lack of historic states. _You do not need these states to run a staking node_, but they are required
 for historical API calls (as used by block explorers and researchers).
 
-You can opt-in to reconstructing all of the historic states by providing the
+To run an archived node, you can opt-in to reconstructing all of the historic states by providing the
 `--reconstruct-historic-states` flag to the beacon node at any point (before, during or after sync).
 
 The database keeps track of three markers to determine the availability of historic blocks and
@@ -155,7 +155,7 @@ The command is as following:
 ```bash
 curl -H "Accept: application/octet-stream" "http://localhost:5052/eth/v2/debug/beacon/states/$SLOT" > state.ssz
 curl -H "Accept: application/octet-stream" "http://localhost:5052/eth/v2/beacon/blocks/$SLOT" > block.ssz
-curl -H "Accept: application/octet-stream" "http://localhost:5052/eth/v1/beacon/blob_sidecars/$SLOT" > blobs.ssz
+curl -H "Accept: application/octet-stream" "http://localhost:5052/eth/v1/beacon/blobs/$SLOT" > blobs.ssz
 ```
 
 where `$SLOT` is the slot number. A slot which is an epoch boundary slot (i.e., first slot of an epoch) should always be used for manual checkpoint sync.

book/src/api_lighthouse.md

@@ -445,7 +445,7 @@ For archive nodes, the `anchor` will be:
 
 indicating that all states with slots `>= 0` are available, i.e., full state history. For more information
 on the specific meanings of these fields see the docs on [Checkpoint
-Sync](./advanced_checkpoint_sync.md#reconstructing-states).
+Sync](./advanced_checkpoint_sync.md#how-to-run-an-archived-node).
 
 ## `/lighthouse/merge_readiness`
 

book/src/faq.md

@@ -2,7 +2,6 @@
 
 ## [Beacon Node](#beacon-node-1)
 
-- [I see a warning about "Syncing deposit contract block cache" or an error about "updating deposit contract cache", what should I do?](#bn-deposit-contract)
 - [I see beacon logs showing `WARN: Execution engine called failed`, what should I do?](#bn-ee)
 - [I see beacon logs showing `Error during execution engine upcheck`, what should I do?](#bn-upcheck)
 - [My beacon node is stuck at downloading historical block using checkpoint sync. What should I do?](#bn-download-historical)
@@ -51,31 +50,6 @@
 
 ## Beacon Node
 
-### <a name="bn-deposit-contract"></a> I see a warning about "Syncing deposit contract block cache" or an error about "updating deposit contract cache", what should I do?
-
-The error can be a warning:
-
-```text
-Nov 30 21:04:28.268 WARN Syncing deposit contract block cache   est_blocks_remaining: initializing deposits, service: slot_notifier
-```
-
-or an error:
-
-```text
-ERRO Error updating deposit contract cache   error: Failed to get remote head and new block ranges: EndpointError(FarBehind), retry_millis: 60000, service: deposit_contract_rpc
-```
-
-This log indicates that your beacon node is downloading blocks and deposits
-from your execution node. When the `est_blocks_remaining` is
-`initializing_deposits`, your node is downloading deposit logs. It may stay in
-this stage for several minutes. Once the deposits logs are finished
-downloading, the `est_blocks_remaining` value will start decreasing.
-
-It is perfectly normal to see this log when starting a node for the first time
-or after being off for more than several minutes.
-
-If this log continues appearing during operation, it means your execution client is still syncing and it cannot provide Lighthouse the information about the deposit contract yet. What you need to do is to make sure that the execution client is up and syncing. Once the execution client is synced, the error will disappear.
-
 ### <a name="bn-ee"></a> I see beacon logs showing `WARN: Execution engine called failed`, what should I do?
 
 The `WARN Execution engine called failed` log is shown when the beacon node cannot reach the execution engine. When this warning occurs, it will be followed by a detailed message. A frequently encountered example of the error message is:
@@ -335,7 +309,7 @@ expect, there are a few things to check on:
 
     If you have incoming peers, it should return a lot of data containing information of peers. If the response is empty, it means that you have no incoming peers and there the ports are not open. You may want to double check if the port forward was correctly set up.
 
-1. Check that you do not lower the number of peers using the flag `--target-peers`. The default is 100. A lower value set will lower the maximum number of peers your node can connect to, which may potentially interrupt the validator performance. We recommend users to leave the `--target peers` untouched to keep a diverse set of peers.
+1. Check that you do not lower the number of peers using the flag `--target-peers`. The default is 200. A lower value set will lower the maximum number of peers your node can connect to, which may potentially interrupt the validator performance. We recommend users to leave the `--target peers` untouched to keep a diverse set of peers.
 
 1. Ensure that you have a quality router for the internet connection. For example, if you connect the router to many devices including the node, it may be possible that the router cannot handle all routing tasks, hence struggling to keep up the number of peers. Therefore, using a quality router for the node is important to keep a healthy number of peers.
 

book/src/installation_binaries.md

@@ -6,11 +6,10 @@ on Github](https://github.com/sigp/lighthouse/releases).
 
 ## Platforms
 
-Binaries are supplied for five platforms:
+Binaries are supplied for the following platforms:
 
 - `x86_64-unknown-linux-gnu`: AMD/Intel 64-bit processors (most desktops, laptops, servers)
 - `aarch64-unknown-linux-gnu`: 64-bit ARM processors (Raspberry Pi 4)
-- `x86_64-apple-darwin`: macOS with Intel chips
 - `aarch64-apple-darwin`: macOS with ARM chips
 - `x86_64-windows`: Windows with 64-bit processors
 

book/src/run_a_node.md

@@ -106,7 +106,7 @@ Once the checkpoint is loaded, Lighthouse will sync forwards to the head of the
 
 If a validator client is connected to the beacon node it will be able to start its duties as soon as forwards sync completes, which typically takes 1-2 minutes.
 
-> Note: If you have an existing Lighthouse database, you will need to delete the database by using the `--purge-db` flag or manually delete the database with `sudo rm -r /path_to_database/beacon`. If you do use a `--purge-db` flag, once checkpoint sync is complete, you can remove the flag upon a restart.
+> Note: If you have an existing Lighthouse database, you will need to delete the database by using the `--purge-db-force` flag or manually delete the database with `sudo rm -r /path_to_database/beacon`. If you do use a `--purge-db-force` flag, once checkpoint sync is complete, you can remove the flag upon a restart.
 
 > **Security Note**: You should cross-reference the `block_root` and `slot` of the loaded checkpoint
 > against a trusted source like another [public endpoint](https://eth-clients.github.io/checkpoint-sync-endpoints/),

book/src/ui_faqs.md

@@ -30,9 +30,9 @@ Yes, if you need to access your beacon or validator from an address such as `htt
 
 If your graph is not showing data, it usually means your validator node is still caching data. The application must wait at least 3 epochs before it can render any graphical visualizations. This could take up to 20min.
 
-## 8. How can I connect to Siren using Wallet Connect?
+## 8. How can I connect to Siren using Reown (previously WalletConnect)?
 
-Depending on your configuration, building with Docker or Local, you will need to include the `NEXT_PUBLIC_WALLET_CONNECT_ID` variable in your `.env` file. To obtain your Wallet Connect project ID, please follow the instructions on their [website](https://cloud.walletconnect.com/sign-in). After providing a valid project ID, the Wallet Connect option should appear in the wallet connector dropdown.
+Depending on your configuration, building with Docker or Local, you will need to include the `NEXT_PUBLIC_WALLET_CONNECT_ID` variable in your `.env` file. To obtain your Wallet Connect project ID, please follow the instructions on their [website](https://dashboard.reown.com/sign-in). After providing a valid project ID, the Wallet Connect option should appear in the wallet connector dropdown.
 
 ## 9. I can't log in to Siren even with correct credentials?
 

book/src/ui_installation.md

@@ -13,7 +13,7 @@ Siren requires a connection to both a Lighthouse Validator Client and a Lighthou
 Both the Beacon node and the Validator client need to have their HTTP APIs enabled.
 These ports should be accessible from Siren. This means adding the flag `--http` on both beacon node and validator client.
 
-To enable the HTTP API for the beacon node, utilize the `--gui` CLI flag. This action ensures that the HTTP API can be accessed by other software on the same machine.
+To enable the HTTP API for the beacon node, utilize the `--gui` CLI flag. This action ensures that the HTTP API can be accessed by other software on the same machine. It also enables the validator monitoring.
 
 > The Beacon Node must be run with the `--gui` flag set.
 

book/src/validator_voluntary_exit.md

@@ -120,26 +120,9 @@ There are two types of withdrawal credentials, `0x00` and `0x01`. To check which
 
 - A fixed waiting period of 256 epochs (27.3 hours) for the validator's status to become withdrawable.
 
-- A varying time of "validator sweep" that can take up to _n_ days with _n_ listed in the table below. The "validator sweep" is the process of skimming through all eligible validators by index number for withdrawals (those with type `0x01` and balance above 32ETH). Once the "validator sweep" reaches your validator's index, your staked fund will be fully withdrawn to the withdrawal address set.
+- A varying time of "validator sweep" that take a few days. The "validator sweep" is the process of skimming through all eligible validators by index number for withdrawals (those with type `0x01` and balance above 32ETH). Once the "validator sweep" reaches your validator's index, your staked fund will be fully withdrawn to the withdrawal address set.
 
-<div align="center">
-
-| Number of eligible validators | Ideal scenario _n_ | Practical scenario _n_ |
-|:----------------:|:---------------------:|:----:|
-| 300000  | 2.60 | 2.63 |
-| 400000  | 3.47 | 3.51 |
-| 500000  | 4.34  | 4.38 |
-| 600000  | 5.21 | 5.26 |
-| 700000  | 6.08 | 6.14 |
-| 800000  | 6.94 | 7.01 |
-| 900000  | 7.81 | 7.89 |
-| 1000000 | 8.68 | 8.77 |
-
-</div>
-
-> Note: Ideal scenario assumes no block proposals are missed. This means a total of withdrawals of 7200 blocks/day * 16 withdrawals/block = 115200 withdrawals/day. Practical scenario assumes 1% of blocks are missed per day. As an example, if there are 700000 eligible validators, one would expect a waiting time of slightly more than 6 days.
-
-   The total time taken is the summation of the above 3 waiting periods. After these waiting periods, you will receive the staked funds in your withdrawal address.
+The total time taken is the summation of the above 3 waiting periods. After these waiting periods, you will receive the staked funds in your withdrawal address.
 
 The voluntary exit and full withdrawal process is summarized in the Figure below.