Add a guide to partially reconstruct historic states to Lighthouse book

book/src/advanced_builders.md

@@ -114,7 +114,7 @@ Each field is optional.
 ```json
 {
     "builder_proposals": true,
-    "gas_limit": 30000001
+    "gas_limit": 45000001
 }
 ```
 
@@ -127,7 +127,7 @@ curl -X PATCH "http://localhost:5062/lighthouse/validators/0xb0148e6348264131bf4
 -H "Content-Type: application/json" \
 -d '{
     "builder_proposals": true,
-    "gas_limit": 30000001
+    "gas_limit": 45000001
 }' | jq
 ```
 
@@ -161,7 +161,7 @@ You can also directly configure these fields in the `validator_definitions.yml`
   voting_keystore_path: /home/paul/.lighthouse/validators/0x87a580d31d7bc69069b55f5a01995a610dd391a26dc9e36e81057a17211983a79266800ab8531f21f1083d7d84085007/voting-keystore.json
   voting_keystore_password_path: /home/paul/.lighthouse/secrets/0x87a580d31d7bc69069b55f5a01995a610dd391a26dc9e36e81057a17211983a79266800ab8531f21f1083d7d84085007
   suggested_fee_recipient: "0x6cc8dcbca744a6e4ffedb98e1d0df903b10abd21"
-  gas_limit: 30000001
+  gas_limit: 45000001
   builder_proposals: true
   builder_boost_factor: 50
 - enabled: false

book/src/faq.md

@@ -14,6 +14,7 @@
 - [My beacon node logs `WARN Error signalling fork choice waiter`, what should I do?](#bn-fork-choice)
 - [My beacon node logs `ERRO Aggregate attestation queue full`, what should I do?](#bn-queue-full)
 - [My beacon node logs `WARN Failed to finalize deposit cache`, what should I do?](#bn-deposit-cache)
+- [How can I construct only partial state history?](#bn-partial-history)
 
 ## [Validator](#validator-1)
 
@@ -190,6 +191,40 @@ If the node is syncing or downloading historical blocks, the error should disapp
 
 This is a known [bug](https://github.com/sigp/lighthouse/issues/3707) that will fix by itself.
 
+### <a name="bn-partial-history"></a> How can I construct only partial state history?
+
+Lighthouse prunes finalized states by default. Nevertheless, it is quite often that users may be interested in the state history of just a few epochs before finalization. To have access to the pruned states, this typically requires a full reconstruction of states using the flag `--reconstruct-historic-states`, which will usually take one week and is therefore undesirable. Partial state history can be achieved with some "tricks". Here are the general steps:
+
+  1. Delete the current database. You can do so with `--purge-db-force` or manually deleting the database from the data directory `$datadir/beacon`.
+
+  1. If you are interested in the states from the current slot and beyond, perform a checkpoint sync with the flag `--reconstruct-historic-states`, then you can skip the following and jump straight to Step 5 to check the database.
+
+      If you are interested in the states before the current slot, identify the slot to perform a manual checkpoint sync. With the default configuration, this slot should be divisible by 2 **21, as this is where a full state snapshot is stored. With the flag `--reconstruct-historic-states`, the state upper limit will be adjusted to the next full snapshot slot, a slot that satisfies: `slot % 2 ** 21 = 0`. In other words, to have the state history available before the current slot, we have to checkpoint sync 2** 21 slots before the next full snapshot slot.
+
+      Example: Say the current mainnet is at `slot 12000000`. As the next full state snapshot is at `slot 12582912`, the slot that we want is:  `slot 10485760`.
+
+  1. [Export](./advanced_checkpoint_sync.md#manual-checkpoint-sync) the blobs, block and state data for the slot identified in Step 2. This can be done from another beacon node that you have access to, or you could use any available public beacon API, e.g., [QuickNode](https://www.quicknode.com/docs/ethereum).
+
+  1. Perform a [manual checkpoint sync](./advanced_checkpoint_sync.md#manual-checkpoint-sync) together with the flag `--reconstruct-historic-states`.
+
+  1. Check the database:
+
+  ```bash
+  curl "http://localhost:5052/lighthouse/database/info" | jq '.anchor'
+  ```
+
+  and look for the field `state_upper_limit`. It should show:
+
+  ```json
+  "state_upper_limit": "10485760",
+  ```
+
+Lighthouse will now start to reconstruct the historic states from `slot 10485760`. At this point, if you do not want a full state reconstruction, you may remove the flag `--reconstruct-historic-states`. When the process is completed, you will have the state data from `slot 10485760`.
+
+> Note: You may only be interested in very recent historic states. To do so, you may configure the full snapshot to be, for example, every 2 ** 11 slots, see [database configuration](./advanced_database.md#hierarchical-state-diffs) for more details. This can be configured with the flag `--hierarchy-exponents 5,7,11` together with the flag `--reconstruct-historic-states`. This will affect the slot number in Step 2, while other steps remain the same. Note that this comes at the expense of a higher storage requirement.
+
+> With `--hierarchy-exponents 5,7,11`, using the same example as above, the next full state snapshot is at `slot 12001280`. So the slot to checkpoint sync from is: `slot 11999232`.
+
 ## Validator
 
 ### <a name="vc-redundancy"></a> Can I use redundancy in my staking setup?

book/src/installation_homebrew.md

@@ -5,9 +5,6 @@ Lighthouse is available on Linux and macOS via the [Homebrew package manager](ht
 Please note that this installation method is maintained by the Homebrew community.
 It is not officially supported by the Lighthouse team.
 
-> Note: There is a [compilation error](https://github.com/Homebrew/homebrew-core/pull/220922) for Lighthouse v7.0.0 and above that remains unresolved. Users are recommended to download the binary from [the release
-page](https://github.com/sigp/lighthouse/releases) or build from source.
-
 ## Installation
 
 Install the latest version of the [`lighthouse`][formula] formula with:

wordlist.txt

@@ -75,6 +75,7 @@ Proto
 PRs
 Prysm
 QUIC
+QuickNode
 RasPi
 README
 RESTful