From 1d86cd0b26741e84a14d819715ca1e4526973702 Mon Sep 17 00:00:00 2001 From: Nico Flaig Date: Mon, 25 Mar 2024 19:27:50 +0000 Subject: [PATCH] docs: review docs (#6590) * fix broken CLI references * update link to lodestar website * some auto formatting changes --- docs/babel.config.js | 2 +- docs/docusaurus.config.ts | 2 +- docs/pages/beacon-management/networking.md | 40 +++++++++---------- docs/pages/beacon-management/syncing.md | 10 ++--- docs/pages/data-retention.md | 2 +- docs/pages/getting-started/starting-a-node.md | 2 +- docs/pages/introduction.md | 2 +- .../validator-management/vc-configuration.md | 2 +- docs/sidebars.ts | 4 +- 9 files changed, 33 insertions(+), 33 deletions(-) diff --git a/docs/babel.config.js b/docs/babel.config.js index e00595dae7d6..bfd75dbdfc72 100644 --- a/docs/babel.config.js +++ b/docs/babel.config.js @@ -1,3 +1,3 @@ module.exports = { - presets: [require.resolve('@docusaurus/core/lib/babel/preset')], + presets: [require.resolve("@docusaurus/core/lib/babel/preset")], }; diff --git a/docs/docusaurus.config.ts b/docs/docusaurus.config.ts index c687a566ccfa..dce5504c54cf 100644 --- a/docs/docusaurus.config.ts +++ b/docs/docusaurus.config.ts @@ -39,7 +39,7 @@ const config: Config = { routeBasePath: "/", }, gtag: { - trackingID: 'G-N21J5PWW5X', + trackingID: "G-N21J5PWW5X", anonymizeIP: true, }, theme: { diff --git a/docs/pages/beacon-management/networking.md b/docs/pages/beacon-management/networking.md index 579fbdef8fe0..9f423a218716 100644 --- a/docs/pages/beacon-management/networking.md +++ b/docs/pages/beacon-management/networking.md @@ -6,29 +6,29 @@ Lodestar will automatically connect to peers on the network. Peers are found thr Some of the important Lodestar flags related to networking are: -- [`--discv5`](./beacon-cli.md#-discv5) -- [`--listenAddress`](./beacon-cli.md#-listenaddress) -- [`--port`](./beacon-cli.md#-port) -- [`--discoveryPort`](./beacon-cli.md#-discoveryport) -- [`--listenAddress6`](./beacon-cli.md#-listenaddress6) -- [`--port6`](./beacon-cli.md#-port6) -- [`--discoveryPort6`](./beacon-cli.md#-discoveryport6) -- [`--bootnodes`](./beacon-cli.md#-bootnodes) -- [`--deterministicLongLivedAttnets`](./beacon-cli.md#-deterministiclonglivedattnets) -- [`--subscribeAllSubnets`](./beacon-cli.md#-subscribeallsubnets) -- [`--disablePeerScoring`](./beacon-cli.md#-disablepeerscoring) -- [`--enr.ip`](./beacon-cli.md#-enrip) -- [`--enr.tcp`](./beacon-cli.md#-enrtcp) -- [`--enr.udp`](./beacon-cli.md#-enrudp) -- [`--enr.ip6`](./beacon-cli.md#-enrip6) -- [`--enr.tcp6`](./beacon-cli.md#-enrtcp6) -- [`--enr.udp6`](./beacon-cli.md#-enrudp6) -- [`--nat`](./beacon-cli.md#-nat) -- [`--private`](./beacon-cli.md#`-private`) +- [`--discv5`](./beacon-cli#--discv5) +- [`--listenAddress`](./beacon-cli#--listenaddress) +- [`--port`](./beacon-cli#--port) +- [`--discoveryPort`](./beacon-cli#--discoveryport) +- [`--listenAddress6`](./beacon-cli#--listenaddress6) +- [`--port6`](./beacon-cli#--port6) +- [`--discoveryPort6`](./beacon-cli#--discoveryport6) +- [`--bootnodes`](./beacon-cli#--bootnodes) +- [`--deterministicLongLivedAttnets`](./beacon-cli#--deterministiclonglivedattnets) +- [`--subscribeAllSubnets`](./beacon-cli#--subscribeallsubnets) +- [`--disablePeerScoring`](./beacon-cli#--disablepeerscoring) +- [`--enr.ip`](./beacon-cli#--enrip) +- [`--enr.tcp`](./beacon-cli#--enrtcp) +- [`--enr.udp`](./beacon-cli#--enrudp) +- [`--enr.ip6`](./beacon-cli#--enrip6) +- [`--enr.tcp6`](./beacon-cli#--enrtcp6) +- [`--enr.udp6`](./beacon-cli#--enrudp6) +- [`--nat`](./beacon-cli#--nat) +- [`--private`](./beacon-cli#--private) ## Peer Discovery (Discv5) -In Ethereum, discv5 plays a pivotal role in the peer discovery process, facilitating nodes to find and locate each other in order to form the peer-to-peer network​. The process begins with an interaction between new nodes and bootnodes at start-up. Bootnodes are nodes with hard-coded addresses, or can be overridden via the cli flag [`--bootnodes`](./beacon-cli.md#-bootnodes), to bootstrap the discovery process​. Through a method called FINDNODE-NODES, a new node establishes a bond with each bootnode, and it returns a list of peers for the new node to connect to. Following this trail, the new node engages through FINDNODE-NODES with the provided peers to further establish a web of connections​. +In Ethereum, discv5 plays a pivotal role in the peer discovery process, facilitating nodes to find and locate each other in order to form the peer-to-peer network​. The process begins with an interaction between new nodes and bootnodes at start-up. Bootnodes are nodes with hard-coded addresses, or can be overridden via the cli flag [`--bootnodes`](./beacon-cli#--bootnodes), to bootstrap the discovery process​. Through a method called FINDNODE-NODES, a new node establishes a bond with each bootnode, and it returns a list of peers for the new node to connect to. Following this trail, the new node engages through FINDNODE-NODES with the provided peers to further establish a web of connections​. Discv5 operates as a peer advertisement medium in this network, where nodes can act as both providers and consumers of data. Every participating node in the Discv5 protocol discovers peer data from other nodes and later relays it, making the discovery process dynamic and efficient​. diff --git a/docs/pages/beacon-management/syncing.md b/docs/pages/beacon-management/syncing.md index 40b5b4ba96b5..7dd05c4b4338 100644 --- a/docs/pages/beacon-management/syncing.md +++ b/docs/pages/beacon-management/syncing.md @@ -2,7 +2,7 @@ Syncing an Ethereum node involves obtaining a copy of the blockchain data from other peers in the network to reach a consistent state. This process is crucial for new nodes or nodes that have been offline and need to catch up with the network's current state. Syncing can be performed for both the execution layer and the beacon chain, although the focus here will be primarily on the beacon chain. -Lodestar allows for several methods of syncing however the recommended method is `checkpoint sync` as it is the fastest and least resource intensive. It is generally a good idea to sync via a [`--checkpointSyncUrl`](./beacon-cli.md#-checkpointsyncurl). If starting at a specific point is necessary specify the [`--checkpointState`](./beacon-cli.md#-checkpointstate) that should be where the sync begins. +Lodestar allows for several methods of syncing however the recommended method is `checkpoint sync` as it is the fastest and least resource intensive. It is generally a good idea to sync via a [`--checkpointSyncUrl`](./beacon-cli#--checkpointsyncurl). If starting at a specific point is necessary specify the [`--checkpointState`](./beacon-cli#--checkpointstate) that should be where the sync begins. ## Weak Subjectivity @@ -36,7 +36,7 @@ The implementation of the different syncing styles in Lodestar are actually one There are several flags that can be used to configure the sync process. -- [`--checkpointSyncUrl`](./beacon-cli.md#-checkpointsyncurl) -- [`--checkpointState`](./beacon-cli.md#-checkpointstate) -- [`--wssCheckpoint`](./beacon-cli.md#-wsscheckpoint) -- [`--forceCheckpointSync`](./beacon-cli.md#-forcecheckpointsync) +- [`--checkpointSyncUrl`](./beacon-cli#--checkpointsyncurl) +- [`--checkpointState`](./beacon-cli#--checkpointstate) +- [`--wssCheckpoint`](./beacon-cli#--wsscheckpoint) +- [`--forceCheckpointSync`](./beacon-cli#--forcecheckpointsync) diff --git a/docs/pages/data-retention.md b/docs/pages/data-retention.md index 41daa8dc458d..6ccdda68af5e 100644 --- a/docs/pages/data-retention.md +++ b/docs/pages/data-retention.md @@ -51,4 +51,4 @@ Configuring your node to store and prune data is key to success. On average you Logs can also become quite large so please check out the section on [log management](./logging-and-metrics/log-management.md) for more information. -There is really only one flag that is needed to manage the data for Lodestar, [`--dataDir`](./beacon-management/beacon-cli.md#-datadir). Other than that handling log management is really the heart of the data management story. Beacon node data is what it is. Depending on the execution client that is chosen, there may be flags to help with data storage growth but that is outside the scope of this document. +There is really only one flag that is needed to manage the data for Lodestar, [`--dataDir`](./beacon-management/beacon-cli#--datadir). Other than that handling log management is really the heart of the data management story. Beacon node data is what it is. Depending on the execution client that is chosen, there may be flags to help with data storage growth but that is outside the scope of this document. diff --git a/docs/pages/getting-started/starting-a-node.md b/docs/pages/getting-started/starting-a-node.md index f67acb1a9f05..7b5c132e305c 100644 --- a/docs/pages/getting-started/starting-a-node.md +++ b/docs/pages/getting-started/starting-a-node.md @@ -70,7 +70,7 @@ In case execution-layer clients are available at different locations, use `--exe Immediately you should see confirmation that the node has started ```txt -pr-20 15:12:45.274[] info: Lodestar network=mainnet, version=v1.7.2, commit= +Apr-20 15:12:45.274[] info: Lodestar network=mainnet, version=v1.7.2, commit= Apr-20 15:12:45.327[] info: Connected to LevelDB database path=/data/mt1/chain-db Apr-20 15:12:57.747[] info: Initializing beacon from a valid db state slot=6264480, epoch=195765, stateRoot=0x8133cd4d0be59c3e94405f902fe0ad68ffaa5013b525dddb6285b91ad79716f6, isWithinWeakSubjectivityPeriod=true Apr-20 15:13:18.077[network] info: PeerId 16Uiu2HAmDsGet67va6VCnaW2Tu1Ae2yujiDMnmURMMWNvssER7ZQ, Multiaddrs /ip4/127.0.0.1/tcp/9000/p2p/16Uiu2HAmDsGet67va6VCnaW2Tu1Ae2yujiDMnmURMMWNvssER7ZQ,/ip4/10.244.0.199/tcp/9000/p2p/16Uiu2HAmDsGet67va6VCnaW2Tu1Ae2yujiDMnmURMMWNvssER7ZQ diff --git a/docs/pages/introduction.md b/docs/pages/introduction.md index 776b018641b8..12b00dacf0a5 100644 --- a/docs/pages/introduction.md +++ b/docs/pages/introduction.md @@ -10,7 +10,7 @@ In Ethereum's Proof of Stake (PoS) model, validators replace miners from the Pro 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: -- [Lodestar](https://chainsafe.io/lodestar.html) +- [Lodestar](https://lodestar.chainsafe.io/) - [Prysm](https://prysmaticlabs.com/) - [Lighthouse](https://lighthouse.sigmaprime.io/) - [Teku](https://consensys.net/knowledge-base/ethereum-2/teku/) diff --git a/docs/pages/validator-management/vc-configuration.md b/docs/pages/validator-management/vc-configuration.md index 186d7435ebeb..c62d7e133696 100644 --- a/docs/pages/validator-management/vc-configuration.md +++ b/docs/pages/validator-management/vc-configuration.md @@ -94,7 +94,7 @@ To calculate the builder boost factor setting, you need to know what percentage Example 1: I will only accept a builder block with 25% more value than the local execution block. -``` +```ts 10000/(100+25) = 80 ``` diff --git a/docs/sidebars.ts b/docs/sidebars.ts index 7c19318d4e30..c64e39b8b5f2 100644 --- a/docs/sidebars.ts +++ b/docs/sidebars.ts @@ -1,4 +1,4 @@ -import type { SidebarsConfig } from '@docusaurus/plugin-content-docs'; +import type {SidebarsConfig} from "@docusaurus/plugin-content-docs"; const sidebars: SidebarsConfig = { tutorialSidebar: [ @@ -70,7 +70,7 @@ const sidebars: SidebarsConfig = { label: "Advanced Topics", items: ["advanced-topics/setting-up-a-testnet"], }, - "faqs" + "faqs", ], };