Document publishing (#2)

* add development branch for preview releases

* updated tls

* updates

* update

* updates and corrections

* added staking to minimal node

* updated Polygon quicknode page

* updated Gnosis Chain quick node

* Gnosis quicknode formatting error correction

* updated disclaimer on welcome page

* updated disclaimer on welcome page

* updated disclaimer on welcome page

* typo correction

* typo correction on welcome page

* typo correction on welcome page

* updates and corrections

* updates and correction

* updates

* updates

* updates

* update

* updated

* restructured and improved Windows
installation documentation

* updated sentry and rpc_daemon

* updated full node by default, staking, alpha6 etc.

---------

Co-authored-by: Michele Modolo <michele@nospam.nospam>
Co-authored-by: bloxster <bloxster@proton.me>

.github/workflows/pages-deployment.yaml

@@ -1,8 +1,10 @@
-name: Pages Deployment
+name: Erigon Docs Deployment
 
 on:
   push:
     branches:
+      - development
+      - main
       - testmichele
 
 env:
@@ -14,6 +16,7 @@ jobs:
     permissions:
       contents: read
       deployments: write
+    environment: ${{ github.ref == 'refs/heads/main' && 'production' || 'preview' }}
     steps:
       - name: Checkout
         uses: actions/checkout@v4

src/SUMMARY.md

@@ -10,6 +10,8 @@
 - [Installation](installation.md)
     - [Linux and MacOS](installation/linux.md)
     - [Windows](installation/windows.md)
+        - [Build executable binaries natively for Windows](installation/build_exec_win.md)
+        - [Windows Subsystem for Linux (WSL)](installation/wsl.md)
     - [Docker](installation/docker.md)
     - [Upgrading from a previous version](installation/upgrading-md)
 
@@ -47,7 +49,7 @@
  ---
 
 - [Tools](tools.md)
-    - [Diagnostic Tool](tools/introduction.md)
+    - [Dagnostic Tools](tools/introduction.md)
         - [Installation](tools/installation.md)
         - [Setup](tools/setup.md)
         - [User Interface](tools/user_interface.md)

src/about.md

@@ -1,4 +1,8 @@
 # About
 
-This is the official Erigon 3 documentation, built on [mdbook](https://rust-lang.github.io/mdBook/).
+This book is open source, contribute at <https://github.com/erigontech/docs>.
+
+The Erigon CI/CD system maintains a hosted version of the `unstable` branch at <https://development.erigon-documentation-preview.pages.dev/>.
+
+This book is built on [mdbook](https://rust-lang.github.io/mdBook/).
 

src/about/contributing.md

@@ -1,4 +1,4 @@
-# Contributing
+# Contributing to Erigon 3
 
 ## Development
 
@@ -11,32 +11,33 @@ Begin by exploring the comprehensive [Programmer's Guide](https://github.com/led
 ### Dive Deeper into the Architecture
 
 For those interested in gaining a deeper understanding of Erigon's underlying architecture, visit the following resources:
-- **DB Walk-through**: This document provides a detailed walk-through of Erigon's database structure. It explains how Erigon organizes persistent data into tables like PlainState for accounts and storage, History Of Accounts for tracking account changes, and Change Sets for optimized binary searches on changes. It contrasts Erigon's approach with go-ethereum's use of the Merkle Patricia Trie.
-- **Database FAQ**: The Database FAQ addresses common questions and concerns related to Erigon's database design. It covers how to directly read the database via gRPC or while Erigon is running, details on the MDBX storage engine and RAM usage model, and points to further resources on the database interface rationale and architecture.
+- **[DB Walk-through](https://github.com/erigontech/erigon/blob/release/2.60/docs/programmers_guide/db_walkthrough.MD)**: This document provides a detailed walk-through of Erigon's database structure. It explains how Erigon organizes persistent data into tables like PlainState for accounts and storage, History Of Accounts for tracking account changes, and Change Sets for optimized binary searches on changes. It contrasts Erigon's approach with go-ethereum's use of the Merkle Patricia Trie.
+- **[Database FAQ](https://github.com/erigontech/erigon/blob/release/2.60/docs/programmers_guide/db_faq.md)**: The Database FAQ addresses common questions and concerns related to Erigon's database design. It covers how to directly read the database via gRPC or while Erigon is running, details on the MDBX storage engine and RAM usage model, and points to further resources on the database interface rationale and architecture.
+
 
 ### Feature Exploration
 Erigon introduces several innovative features that contributors may find interesting to explore and contribute to:
-- **DupSort Feature Explanation**: Erigon's DupSort feature optimizes storage and retrieval of duplicate data by utilizing prefixes for keys in databases without the concept of "Buckets/Tables/Collections" or by creating tables for efficient storage with named "Buckets/Tables/Collections."
-- **/EVM without Opcodes** (Ether Transfers Only): Erigon explores a simplified version of the Ethereum Virtual Machine (EVM) focusing solely on ether transfers, offering an efficient execution environment for specific use cases.
+- **[DupSort Feature Explanation](https://github.com/erigontech/erigon/blob/release/2.60/docs/programmers_guide/dupsort.md)**: Erigon's DupSort feature optimizes storage and retrieval of duplicate data by utilizing prefixes for keys in databases without the concept of "Buckets/Tables/Collections" or by creating tables for efficient storage with named "Buckets/Tables/Collections."
+- **[EVM without Opcodes](https://github.com/erigontech/erigon/blob/release/2.60/docs/evm_semantics.md)** (Ether Transfers Only): Erigon explores a simplified version of the Ethereum Virtual Machine (EVM) focusing solely on ether transfers, offering an efficient execution environment for specific use cases.
 
 ## Wiki
 
 Visit also Erigon's [Wiki](https://github.com/ledgerwatch/erigon/wiki) to gain more important insights:
-• Caplin downloader sync
-• Choice of storage engine
-• Consensus Engine separation
-• Criteria for transitioning from Alpha to Beta
-• Erigon Beta 1 announcement
-• Erigon2 prototype
-• EVM with abstract interpretation and backtracking
-• Header downloader
-• LMDB freelist
-• LMDB freelist illustrated guide
-• State sync design
-• TEVM Trans-piled EVM: accelerate EVM improvement R&D, but learning from eWASM
-• Transaction Pool Design
-• Using Postman to test RPC.
+- Caplin downloader sync
+- Choice of storage engine
+- Consensus Engine separation
+- Criteria for transitioning from Alpha to Beta
+- Erigon Beta 1 announcement
+- Erigon2 prototype
+- EVM with abstract interpretation and backtracking
+- Header downloader
+- LMDB freelist
+- LMDB freelist illustrated guide
+- State sync design
+- TEVM Trans-piled EVM: accelerate EVM improvement R&D, but learning from eWASM
+- Transaction Pool Design
+- Using Postman to test RPC.
 
 # Documentation
 
-To contribute to this documentation, commit your change to Github. You might want to run it locally to verify the output before committing.
+To contribute to this documentation, commit your change to the development branch on [Github](https://github.com/erigontech/docs/tree/development). You might want to run it locally to verify the output before committing, see how MdBook works [here](https://rust-lang.github.io/mdBook/index.html).

src/about/donate.md

@@ -1,3 +1,15 @@
 # Donate
 
-To support our work you can donate to [0x8BFBB529A9E85fDC4b70A4FCdC0D68Bb298B8816](https://etherscan.io/address/0x8BFBB529A9E85fDC4b70A4FCdC0D68Bb298B8816#multichain-portfolio).
+*Driving Ethereum progress through community-supported research and development*
+
+Erigon Technologies AG is a non-profit project dedicated to advancing Ethereum technology for the public good. Our work is funded entirely by grants from blockchain companies and donations from our community.
+
+Your contribution will help us to:
+
+- Advance the Ethereum protocol for a more secure, efficient, and user-friendly experience
+- Foster innovation, collaboration, and open-source development
+- Empower individuals and organizations to harness blockchain technology
+
+Every donation brings us closer to a more decentralized, equitable, and connected world. 
+
+Support Erigon's mission today and help shape the future of Ethereum by donating to our Gitcoin grant address [0x8BFBB529A9E85fDC4b70A4FCdC0D68Bb298B8816](https://etherscan.io/address/0x8BFBB529A9E85fDC4b70A4FCdC0D68Bb298B8816).

src/about/reachus.md

@@ -1,13 +1,14 @@
 # How to reach us
 
-Erigon office is located in the CV Labs in Zug
+The Erigon Technologies AG office is located in the CV Labs in Zug:
 
 
-Erigon Ag / Damstrasse 16
-
+```
+Erigon Technologies AG 
+Damstrasse 16
 6300 Zug
-
 Switzerland
+```
 
 ## Erigon Discord Server
 

src/advanced.md

@@ -2,16 +2,12 @@
 
 Erigon is by default an "all-in-one" binary solution, but it's possible start any internal component as a separated processes:
 
-- RPCDaemon, the JSON RPC layer
-- TxPool, the transaction pool
-- Sentry, the p2p layer
-- Downloader, the history download layer
-- Caplin, the novel Consensus Layer
+- [RPCDaemon](./advanced/rpc_daemon.md), the JSON RPC layer
+- [TxPool](./advanced/txpool.md), the transaction pool
+- [Sentry](./advanced/sentry.md), the p2p layer
+- [Downloader](./advanced/downloader.md), the history download layer
+- [Caplin](./advanced/caplin.md), the novel Consensus Layer
 
 This may be for security, scalability, decentralisation, resource limitation, custom implementation, or any other reason you/your team deems appropriate. See the appropriate section to understand how to start each service separately.
 
-<div class="warning">
-
-Don't start services as separated processes unless you have clear reason for it.
-
-</div>
+> Don't start services as separated processes unless you have clear reason for it.

src/advanced/block-prod.md

@@ -1,48 +1,117 @@
 # Block production
 
-How to propose and validate blockswith Erigon
+*How to propose and validate blocks with Erigon*
 
-Only remote miners are supported.
+Both remote miners and Caplin are supported.
 
-To enable, add
+# Using remote miners
+
+To enable remote miners , add the flags:
 
 ```bash
 --mine --miner.etherbase=...
 ```
 or
 
 ```bash
---mine --miner.miner.sigkey=... flags
+--mine --miner.miner.sigkey=...
 ```
 
-Other supported options: `--miner.extradata`, `--miner.notify`, `--miner.gaslimit`, `--miner.gasprice` , `--miner.gastarget`
-
-JSON-RPC supports methods: eth_coinbase , eth_hashrate, eth_mining, eth_getWork, eth_submitWork, eth_submitHashrate
+Other supported options are:
+- `--miner.notify`: Comma separated HTTP URL list to notify of new work packages
+- `--miner.gaslimit`: Target gas limit for mined blocks (default: `36000000`)
+- `--miner.etherbase`: Public address for block mining rewards (default: "`0`")
+- `--miner.extradata`: Block extra data set by the miner (default: `client version`)
+- `--miner.noverify`: Disable remote sealing verification (default: `false`)
+- `--miner.noverify`: Disable remote sealing verification (default: `false`)
+- `--miner.sigfile`: Private key to sign blocks with
+- `--miner.recommit`: Time interval to recreate the block being mined (default: `3s`)
+- `--miner.gasprice`: This option sets the minimum gas price for mined transactions
+- `--miner.gastarget`: This option sets the maximum amount of gas that could be spent during a transaction.
 
-JSON-RPC supports websocket methods: newPendingTransaction
+Erigon supports [standard JSON-RPC methods](https://ethereum.org/en/developers/docs/apis/json-rpc/).
 
 # Using Caplin as validator
+*Running Erigon with Caplin and Lighthouse Validator*
+
+Caplin is also suitable for staking, however, you will need to utilize either Lighthouse, Teku, or another validator client as your key manager, since Caplin does not offer a native key management solution.
 
-Only Lighthouse, Lodestar and Teku are supported as Validator Clients.
+This guide explains how to use Erigon with its embedded Caplin consensus layer and Lighthouse as the validator client for staking on Ethereum.
 
-To enable block production and Caplin's beacon API when using Caplin as the Consensus Layer (CL) engine, the flag --beacon.api must be added. For example:
+## 1. Start Erigon with Caplin
+Run the following command to start Erigon with the embedded Caplin consensus layer with the beacon API on:
 
 ```bash
---beacon.api=beacon,builder,config,debug,node,validator,lighthouse
+erigon \
+  --datadir=/data/erigon \
+  --chain=mainnet \
+  --prune.mode=full \
+  --http \
+  --http.addr=0.0.0.0 \
+  --http.port=8545 \
+  --http.api=engine,eth,net,web3 \
+  --ws \
+  --ws.port=8546 \
+  --caplin.enable-upnp \
+  --caplin.discovery.addr=0.0.0.0 \
+  --caplin.discovery.port=4000 \
+  --caplin.discovery.tcpport=4001 \
+  --chain=<NETWORK>
+  --beacon.api=beacon,validator,builder,config,debug,events,node,lighthouse 
 ```
 
-Enabling the Beacon API will lead to a 6 GB higher RAM usage.
+**Flags Explanation**:
+
+- Execution Layer:
+    - `--http.api=engine,eth,net,web3`: enables the necessary APIs for external clients and Caplin.
+    - `--ws`: enables WebSocket-based communication (optional).
+- Consensus Layer (Caplin):
+    - `--caplin.discovery.addr` and `--caplin.discovery.port`: configures Caplin's gossip and discovery layer.
+    - `--beacon.api=beacon,validator,builder,config,debug,events,node,lighthouse`: enables all possible API endpoints for the validator client.
+
+## 2. Set Up Lighthouse Validator Client
+
+### 2.1 Install Lighthouse
+
+Download the latest Lighthouse binary:
+
+```
+curl -LO https://github.com/sigp/lighthouse/releases/latest/download/lighthouse
+chmod +x lighthouse
+sudo mv lighthouse /usr/local/bin/
+```
 
-For example, if you want to run Erigon + Caplin as a validator here following is the Erigon command:
+Or, use Docker:
 
 ```bash
-./build/bin/erigon --chain=holesky --prune.mode=full --beacon.api=beacon,builder,config,debug,node,validator,lighthouse
+docker pull sigp/lighthouse:latest
 ```
 
-While here the command for Lighthouse would look like*:
+### 2.2. Create Lighthouse Validator Key Directory
+
+```bash
+mkdir -p ~/.lighthouse/validators
+```
+
+### 2.3. Run Lighthouse Validator Client
+
+Start the validator client and connect it to the Caplin consensus layer:
+```bash
+lighthouse vc \
+  --network mainnet \
+  --beacon-nodes http://127.0.0.1:5555 \
+  --suggested-fee-recipient=<your_eth_address>
+```
+**Flags Explanation**:
+- `--network mainnet`: Specifies the Ethereum mainnet.
+- `--beacon-nodes`: Points to the Caplin beacon API at `http://127.0.0.1:5555`.
+- `--suggested-fee-recipient`: Specifies your Ethereum address for block rewards.
+
+### 2.4. Import Validator Keys
+
+If you have existing validator keys, import them:
 
 ```bash
-lighthouse validator_client --network holesky --beacon-nodes http://localhost:5555
+lighthouse account validator import --directory <path_to_validator_keys>
 ```
 
-*For adding validators and specific command syntax, refer to the documentation of your chosen Validator Client.

src/advanced/caplin.md

@@ -16,4 +16,4 @@ Caplin is enabled by default, at which point an external consensus layer is no l
 
 Caplin also has an archive mode for historical states and blocks, which can be enabled with the `--caplin.archive` flag.
 
-Caplin can also be used for [block production](/advanced/block-prod.md).
+Caplin can also be used for [block production](/advanced/block-prod.md#using-caplin-as-validator), aka **staking**.