docs: update documentation Oct 2024

.wordlist.txt

@@ -13,6 +13,7 @@ Casper
 Chai
 ChainSafe
 Codespaces
+CoinCashew
 Corepack
 Customizations
 DPoS
@@ -29,6 +30,7 @@ ENRs
 ETH
 Edgington
 Erigon
+Esat
 EthStaker
 EtherScan
 Ethereum
@@ -37,15 +39,19 @@ FINDNODE
 FX
 Flamegraph
 Flamegraphs
+GPG
 Geth
 Github
+Goerli
+Golang
 Gossipsub
 Grafana
 Grandine
 HTTPS
 HackMD
 Hashicorp
 Homebrew
+Hyperledger
 IPFS
 IPv
 Infura
@@ -60,15 +66,18 @@ LGPLv
 LMD
 LPoS
 LTS
+LVM
 Lerna
 MEV
 MacOS
 Metamask
+MevBoost
 ModuleNotFoundError
 Monorepo
 NPM
 NVM
 Nethermind
+Nim
 NodeJS
 NodeSource
 OSI
@@ -81,9 +90,11 @@ Quickstart
 RPC
 Reth
 Ryzen
+SFTP
 SHA
 SSD
 SSZ
+Somer
 Stakehouse
 TOC
 TTD
@@ -103,13 +114,15 @@ backfill
 beaconcha
 blockRoot
 blockchain
+blockspace
 blst
 bootnode
 bootnodes
 bundlers
 chainConfig
 chainsafe
 chiado
+chmod
 cli
 cmd
 codebase
@@ -125,6 +138,8 @@ dApp
 dApps
 ddos
 decrypt
+decrypted
+derypted
 deserialization
 dev
 devcontainer
@@ -139,30 +154,38 @@ env
 envs
 ephemery
 ethers
+feeRecipient
 flamegraph
 flamegraphs
 floodsub
+fsSL
 getNetworkIdentity
 gnosis
+gpg
 heapdump
 heaptrack
 holesky
 interop
 js
+keymanager
 keypair
+keyrings
 keystore
 keystores
 libp
 lightclient
 linter
+liveness
 lldb
 llnode
 lockfile
 mainnet
 malloc
+mbps
 mdns
 merkle
 merkleization
+misconfiguration
 mmeshsub
 monorepo
 multiaddr
@@ -199,6 +222,7 @@ ssz
 stakers
 subnet
 subnets
+sudo
 tcp
 testnet
 testnets
@@ -215,6 +239,7 @@ vite
 vitest
 webpack
 wip
+xRelayPubKey
 xcode
 yaml
 yamux

docs/docusaurus.config.ts

@@ -97,29 +97,23 @@ const config: Config = {
       style: "dark",
       links: [
         {
-          title: "Docs",
-          items: [
-            {
-              label: "Introduction",
-              to: "/introduction",
-            },
-          ],
+          label: 'Lodestar Website',
+          href: 'https://lodestar.chainsafe.io',
         },
         {
-          title: "Community",
-          items: [
-            {
-              label: "Discord",
-              href: "https://discord.com/invite/yjyvFRP",
-            },
-            {
-              label: "Twitter",
-              href: "https://twitter.com/lodestar_eth",
-            },
-          ],
+          label: 'Discord',
+          href: 'https://discord.com/invite/yjyvFRP',
+        },
+        {
+          label: 'Twitter/X',
+          href: 'https://x.com/lodestar_eth',
+        },
+        {
+          label: 'Github',
+          href: 'https://github.com/ChainSafe/lodestar',
         },
       ],
-      copyright: `Copyright © ${new Date().getFullYear()} ChainSafe, Inc.`,
+      copyright: `Copyright © ${new Date().getFullYear()} ChainSafe. Built with Docusaurus.` ,
     },
     colorMode: {
       respectPrefersColorScheme: false,

docs/pages/index.md

@@ -4,14 +4,14 @@ title: Home
 
 ![lodestar logo](../../assets/lodestar_icon_text_black_stroke.png)
 
-## Welcome to the Lodestar documentation
+## Welcome to the Lodestar Documentation
 
-> **Lodestar is an open-source Ethereum Consensus client and Typescript ecosystem, maintained by ChainSafe Systems**
+> **Lodestar is an open-source Ethereum Consensus client and TypeScript ecosystem, maintained by ChainSafe Systems**
 
-### Getting started
+### Getting Started
 
 - Follow the instructions for [build from source](./run/getting-started/installation#build-from-source), [binaries](./run/getting-started/installation#binaries), or [Docker](./run/getting-started/installation#docker-installation) to install Lodestar. Or use our [Lodestar Quickstart scripts](https://github.com/ChainSafe/lodestar-quickstart).
-- Use [Lodestar libraries](./supporting-libraries/index.md) in your next Ethereum Typescript project.
+- Use [Lodestar libraries](./supporting-libraries/index.md) in your next Ethereum TypeScript project.
 - Run a beacon node on [mainnet or a public testnet](./run/beacon-management/starting-a-node.md).
 - Utilize the whole stack by [starting a local testnet](./contribution/advanced-topics/setting-up-a-testnet.md).
 - View the Lodestar Beacon [CLI commands and options](./run/beacon-management/beacon-cli.md)
@@ -26,14 +26,18 @@ Hardware specifications minimum / recommended, to run the Lodestar client.
 |           | Minimum                                | Recommended                            |
 | --------- | -------------------------------------- | -------------------------------------- |
 | Processor | Intel Core i3–9100 or AMD Ryzen 5 3450 | Intel Core i7–9700 or AMD Ryzen 7 4700 |
-| Memory    | 16GB RAM                               | 32GB RAM                               |
-| Storage   | 100GB available space SSD              | 1TB available space SSD                |
-| Internet  | Broadband connection                   | Broadband connection                   |
+| Memory    | 8 GB RAM                               | 16 GB RAM                              |
+| Storage   | 130 GB available space SSD             | 200 GB available space SSD             |
+| Internet  | Reliable broadband with 10mbps upload  | Reliable broadband with >10mbps upload |
 
-## About these docs
+### Execution Client
 
-This documentation is open source, contribute at [Github Lodestar repository /docs](https://github.com/ChainSafe/lodestar/tree/unstable/docs).
+If you run the [execution client](https://ethereum.org/en/developers/docs/nodes-and-clients/#execution-clients) on the same host, you will need to check their requirements and add them to the above requirements. Broadly, to run both an execution and a consensus client on the same machine, we recommend a 4 TB SSD and 32 GB RAM.
 
-## Need assistance?
+## About These Docs
+
+This documentation is open source, contribute on our [Github Lodestar repository /docs](https://github.com/ChainSafe/lodestar/tree/unstable/docs).
+
+## Need Assistance?
 
 If you have questions about this documentation, feel free to talk to us on our [ChainSafe Discord](https://discord.gg/yjyvFRP) or [open an issue](https://github.com/ChainSafe/lodestar/issues/new/choose) and a member of the team or our community will be happy to assist you.

docs/pages/introduction.md

@@ -1,29 +1,29 @@
 # Introduction
 
-Ethereum is one of the most profoundly important inventions in recent history. It is a decentralized, open-source blockchain featuring smart contract functionality. It is the second-largest cryptocurrency by market capitalization, after Bitcoin, and is the most actively used blockchain. Ethereum was proposed in 2013 by programmer Vitalik Buterin. Development was crowdfunded in 2014, and the network went live on 30 July 2015, with 72 million coins premined. ChainSafe was founded not too long afterwards and has been actively working in the Ethereum space ever since. We are proud to develop Lodestar and to present this documentation as a resource for the Ethereum community.
+Ethereum is one of the most profoundly important inventions in recent history. It is a decentralized, open-source blockchain featuring smart contract functionality. It is the second-largest cryptocurrency by market capitalization, after Bitcoin, and is the second largest blockchain by market capitalization. Ethereum was proposed in 2013 by programmer Vitalik Buterin. Development was crowdfunded in 2014, and the network went live on 30 July 2015, with 72 million coins premined. ChainSafe was founded not too long afterwards in 2017 and has been actively working in the Ethereum ecosystem ever since. We are proud to develop Lodestar, the only TypeScript based consensus client, and to present this documentation as a resource for the Ethereum community.
 
 ## Proof of Stake
 
-In Ethereum's Proof of Stake (PoS) model, validators replace miners from the Proof of Work (PoW) system. Validators are Ethereum stakeholders who lock up a portion of their Ether as a stake. The protocol randomly selects these validators to propose new blocks. The chance of being chosen is tied to the size of their stake: the more Ether staked, the higher the probability of being selected to propose the block. Proposers receive transaction fees and block rewards as incentives. Validators are also responsible for voting on the validity of blocks proposed by other validators. However, they face penalties, known as slashing, for actions like double-signing, votes on a block that is not in the majority or going offline, ensuring network integrity and reliability. The PoS mechanism significantly reduces energy consumption compared to PoW, because it does not require extensive computational power. Moreover, PoS tends to facilitate faster transaction validations and block creations, enhancing the overall performance and scalability of the network.
+In Ethereum's Proof of Stake (PoS) model, validators replace miners from the Proof of Work (PoW) system. Validators are Ethereum stakeholders who lock up a portion of their Ether as a stake. The protocol randomly selects these validators to propose new blocks. The chance of being chosen is tied to the size of their stake: the more Ether staked, the higher the probability of being selected to propose the block. Proposers receive transaction fees and block rewards as incentives. Validators are also responsible for voting on the validity of blocks proposed by other validators. However, they also face penalties, known as slashing, for actions like signing two different block proposals in the same slot or voting on two different attestations for the same target epoch, which creates conflicting states. The PoS mechanism significantly reduces energy consumption compared to PoW, because it does not require extensive computational power. Moreover, PoS tends to facilitate faster transaction validations and block creations, enhancing the overall performance and scalability of the network.
 
 ## Consensus Clients
 
-In an effort to promote client diversity there are several beacon-nodes being developed. Each is programmed in a different language and by a different team. The following is a list of the current beacon-node clients:
+In an effort to promote client diversity there are several consensus beacon nodes being developed. Each is programmed in a different language and by a different team. The following is a list of the current open source consensus clients in alphabetical order:
 
-- [Lodestar](https://lodestar.chainsafe.io/)
-- [Prysm](https://prysmaticlabs.com/)
-- [Lighthouse](https://lighthouse.sigmaprime.io/)
-- [Teku](https://consensys.net/knowledge-base/ethereum-2/teku/)
-- [Nimbus](https://nimbus.team/)
-- [Grandine](https://grandine.io)
+- [Grandine (Rust)](https://grandine.io)
+- [Lighthouse (Rust)](https://lighthouse.sigmaprime.io/)
+- [Lodestar (TypeScript)](https://lodestar.chainsafe.io/)
+- [Nimbus (Nim)](https://nimbus.team/)
+- [Prysm (Golang)](https://prysmaticlabs.com/)
+- [Teku (Java)](https://consensys.net/knowledge-base/ethereum-2/teku/)
 
 ## Why Client Diversity?
 
-The Ethereum network's robustness is significantly enhanced by its client diversity, whereby multiple, independently-developed clients conforming to a common specification facilitate seamless interaction and function equivalently across nodes. This client variety not only fosters a rich ecosystem but also provides a buffer against network-wide issues stemming from bugs or malicious attacks targeted at particular clients. For instance, during the Shanghai denial-of-service attack in 2016, the diversified client structure enabled the network to withstand the assault, underscoring the resilience afforded by multiple client configurations.
+The Ethereum network's robustness is significantly enhanced by its client diversity, whereby multiple, independently-developed clients conforming to a common specification, facilitating seamless interaction and function equivalently across different nodes. This client variety not only fosters a rich ecosystem but also provides a buffer against network-wide issues stemming from bugs or malicious attacks targeted at particular clients. For instance, during the Shanghai denial-of-service attack in 2016, the diversified client structure enabled the network to withstand the assault, underscoring the resilience afforded by multiple client configurations.
 
-On the consensus layer, client distribution is crucial for maintaining network integrity and finality, ensuring transactions are irreversible once validated. A balanced spread of nodes across various clients helps mitigate risks associated with potential bugs or attacks that could, in extreme cases, derail the consensus process or lead to incorrect chain splits, thereby jeopardizing the network's stability and trust. While the data suggests a dominance of Prysm client on the consensus layer, efforts are ongoing to promote a more even distribution among others like Lighthouse, Teku, Nimbus and Grandine. Encouraging the adoption of minority clients, bolstering their documentation, and leveraging real-time client diversity dashboards are among the strategies being employed to enhance client diversity, which in turn fortifies the Ethereum consensus layer against adversities and fosters a healthier decentralized network ecosystem.
+On the consensus layer, client distribution is crucial for maintaining network integrity and finality, ensuring transactions are irreversible once validated. A balanced spread of nodes across various clients help to mitigate risks associated with potential bugs or attacks that could, in extreme cases, derail the consensus process (liveness failure) or lead to incorrect chain splits (forking), thereby jeopardizing the network's stability and trust. While the data suggests a [dominance of the Prysm and Lighthouse clients](https://clientdiversity.org) on the consensus layer, efforts are ongoing to promote a more even distribution among others clients. Encouraging the adoption of minority clients, bolstering their documentation, and leveraging real-time client diversity dashboards are among the strategies being employed to enhance client diversity, which in turn fortifies the Ethereum consensus layer against adversities and fosters a healthier decentralized network.
 
-The non-finality event in May 2023 on the Ethereum network posed a significant challenge. The issue arose from attestations for a fork, which necessitated state replays to validate the attestations, causing a notable strain on system resources. As a result, nodes fell out of sync, which deterred the accurate tracking of the actual head of the chain. This situation was exacerbated by a decline in attestations during specific epochs, further hampering the consensus mechanism. The Lodestar team noticed late attestations several weeks prior to the event and implemented a feature that attempted to address such challenges by not processing untimely attestations, and thus not requiring expensive state replays​. While it was done for slightly different reasons, the result was the same. Lodestar was able to follow the chain correctly and helped to stabilize the network. This example underscored the importance of client diversity and network resilience against potential forks and replay attacks. These are considered realistic threats, especially in the context of system complexity like in Ethereum's consensus mechanism.
+The [non-finality event of May 2023](https://medium.com/offchainlabs/post-mortem-report-ethereum-mainnet-finality-05-11-2023-95e271dfd8b2) on the Ethereum network posed a significant challenge. The issue arose from attestations for a fork, which necessitated state replays to validate the attestations, causing a notable strain on system resources. As a result, nodes fell out of sync, which deterred the accurate tracking of the actual head of the chain. This situation was exacerbated by a decline in attestations during specific epochs, further hampering the consensus mechanism from reaching finality. The Lodestar team noticed late attestations several weeks prior to the event and implemented a feature that attempted to address such challenges by not processing untimely attestations, and thus not requiring expensive state replays​. While it was done for slightly different reasons, the result was the same. Lodestar was able to follow the chain correctly and helped to stabilize the network. This example underscored the importance of client diversity and network resilience against potential forks and replay attacks. These are considered realistic threats, especially in the context of system complexity like in Ethereum's consensus mechanism.
 
 ## Ethereum Reading List