From 744b1950e54a4cf80c91e1f3a8dc26128deab062 Mon Sep 17 00:00:00 2001 From: Eitan Seri-Levi Date: Tue, 30 May 2023 01:38:45 +0000 Subject: [PATCH 01/18] Keep payload cache idempotent (#4256) ## Issue Addressed [#4239](https://github.com/sigp/lighthouse/issues/4239) ## Proposed Changes keep the payload cache entry intact after fetching it ## Additional Info --- beacon_node/execution_layer/src/lib.rs | 2 +- beacon_node/execution_layer/src/payload_cache.rs | 4 ++++ 2 files changed, 5 insertions(+), 1 deletion(-) diff --git a/beacon_node/execution_layer/src/lib.rs b/beacon_node/execution_layer/src/lib.rs index 19fa91b12..51b681b21 100644 --- a/beacon_node/execution_layer/src/lib.rs +++ b/beacon_node/execution_layer/src/lib.rs @@ -380,7 +380,7 @@ impl ExecutionLayer { /// Attempt to retrieve a full payload from the payload cache by the payload root pub fn get_payload_by_root(&self, root: &Hash256) -> Option> { - self.inner.payload_cache.pop(root) + self.inner.payload_cache.get(root) } pub fn executor(&self) -> &TaskExecutor { diff --git a/beacon_node/execution_layer/src/payload_cache.rs b/beacon_node/execution_layer/src/payload_cache.rs index 60a8f2a95..1722edff4 100644 --- a/beacon_node/execution_layer/src/payload_cache.rs +++ b/beacon_node/execution_layer/src/payload_cache.rs @@ -30,4 +30,8 @@ impl PayloadCache { pub fn pop(&self, root: &Hash256) -> Option> { self.payloads.lock().pop(&PayloadCacheId(*root)) } + + pub fn get(&self, hash: &Hash256) -> Option> { + self.payloads.lock().get(&PayloadCacheId(*hash)).cloned() + } } From 02ef7ae01699433542a56713e72049c0ef57beff Mon Sep 17 00:00:00 2001 From: Philippe Schommers Date: Tue, 30 May 2023 01:38:46 +0000 Subject: [PATCH 02/18] chore: Bellatrix occurred for Gnosis (#4301) ## Issue Addressed None ## Proposed Changes Tiny change to the documentation: Bellatrix happened for Gnosis so also needs a merge-ready config. ## Additional Info None --- book/src/merge-migration.md | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/book/src/merge-migration.md b/book/src/merge-migration.md index ec9aeaaee..08107695f 100644 --- a/book/src/merge-migration.md +++ b/book/src/merge-migration.md @@ -26,8 +26,7 @@ engine to a merge-ready version. You must configure your node to be merge-ready before the Bellatrix fork occurs on the network on which your node is operating. -* **Gnosis**: the Bellatrix fork has not yet been scheduled. -* **Mainnet**, **Goerli (Prater)**, **Ropsten**, **Sepolia**, **Kiln**: the Bellatrix fork has +* **Mainnet**, **Goerli (Prater)**, **Ropsten**, **Sepolia**, **Kiln**, **Gnosis**: the Bellatrix fork has already occurred. You must have a merge-ready configuration right now. ## Connecting to an execution engine From 10318fa34b909e4665a243bcc6843ab1932ecca3 Mon Sep 17 00:00:00 2001 From: Jimmy Chen Date: Tue, 30 May 2023 01:38:47 +0000 Subject: [PATCH 03/18] Update blog link in README (#4322) ## Issue Addressed Update blog link in README.md Co-authored-by: Jimmy Chen --- README.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/README.md b/README.md index 3565882d6..ade3bc2ab 100644 --- a/README.md +++ b/README.md @@ -10,7 +10,7 @@ An open-source Ethereum consensus client, written in Rust and maintained by Sigm [Book Link]: https://lighthouse-book.sigmaprime.io [stable]: https://github.com/sigp/lighthouse/tree/stable [unstable]: https://github.com/sigp/lighthouse/tree/unstable -[blog]: https://lighthouse.sigmaprime.io +[blog]: https://lighthouse-blog.sigmaprime.io [Documentation](https://lighthouse-book.sigmaprime.io) From 88abaaae05cc08ff8151054a162b575e1072b74c Mon Sep 17 00:00:00 2001 From: Jimmy Chen Date: Tue, 30 May 2023 01:38:48 +0000 Subject: [PATCH 04/18] Add `db inspect --output values` option to support dumping raw db values (#4324) ## Issue Addressed Add a new `--output values` option to `db inspect` for dumping raw database values to SSZ files. This could be useful for inspecting the database when we're unable to start the beacon node. Example usage: ``` # Output the `ForkChoice` column to an SSZ file lighthouse db inspect --column frk --output values ``` By default, it stores the output files in the current directory, and can be overriden with `--ouput-dir`. List of columns can be found here: https://github.com/sigp/lighthouse/blob/c547a11b0da48db6fdd03bca2c6ce2448bbcc3a9/beacon_node/store/src/lib.rs#L169-L216 --- database_manager/src/lib.rs | 73 +++++++++++++++++++++++++++++++------ 1 file changed, 61 insertions(+), 12 deletions(-) diff --git a/database_manager/src/lib.rs b/database_manager/src/lib.rs index 33accfc05..ce0b094b7 100644 --- a/database_manager/src/lib.rs +++ b/database_manager/src/lib.rs @@ -6,6 +6,9 @@ use beacon_node::{get_data_dir, get_slots_per_restore_point, ClientConfig}; use clap::{App, Arg, ArgMatches}; use environment::{Environment, RuntimeContext}; use slog::{info, Logger}; +use std::fs; +use std::io::Write; +use std::path::PathBuf; use store::{ errors::Error, metadata::{SchemaVersion, CURRENT_SCHEMA_VERSION}, @@ -57,6 +60,13 @@ pub fn inspect_cli_app<'a, 'b>() -> App<'a, 'b> { .default_value("sizes") .possible_values(InspectTarget::VARIANTS), ) + .arg( + Arg::with_name("output-dir") + .long("output-dir") + .value_name("DIR") + .help("Base directory for the output files. Defaults to the current directory") + .takes_value(true), + ) } pub fn prune_payloads_app<'a, 'b>() -> App<'a, 'b> { @@ -154,18 +164,27 @@ pub enum InspectTarget { ValueSizes, #[strum(serialize = "total")] ValueTotal, + #[strum(serialize = "values")] + Values, } pub struct InspectConfig { column: DBColumn, target: InspectTarget, + /// Configures where the inspect output should be stored. + output_dir: PathBuf, } fn parse_inspect_config(cli_args: &ArgMatches) -> Result { let column = clap_utils::parse_required(cli_args, "column")?; let target = clap_utils::parse_required(cli_args, "output")?; - - Ok(InspectConfig { column, target }) + let output_dir: PathBuf = + clap_utils::parse_optional(cli_args, "output-dir")?.unwrap_or_else(PathBuf::new); + Ok(InspectConfig { + column, + target, + output_dir, + }) } pub fn inspect_db( @@ -173,7 +192,7 @@ pub fn inspect_db( client_config: ClientConfig, runtime_context: &RuntimeContext, log: Logger, -) -> Result<(), Error> { +) -> Result<(), String> { let spec = runtime_context.eth2_config.spec.clone(); let hot_path = client_config.get_db_path(); let cold_path = client_config.get_freezer_db_path(); @@ -185,12 +204,19 @@ pub fn inspect_db( client_config.store, spec, log, - )?; + ) + .map_err(|e| format!("{:?}", e))?; let mut total = 0; + let base_path = &inspect_config.output_dir; + + if let InspectTarget::Values = inspect_config.target { + fs::create_dir_all(base_path) + .map_err(|e| format!("Unable to create import directory: {:?}", e))?; + } for res in db.hot_db.iter_column(inspect_config.column) { - let (key, value) = res?; + let (key, value) = res.map_err(|e| format!("{:?}", e))?; match inspect_config.target { InspectTarget::ValueSizes => { @@ -200,11 +226,32 @@ pub fn inspect_db( InspectTarget::ValueTotal => { total += value.len(); } + InspectTarget::Values => { + let file_path = + base_path.join(format!("{}_{}.ssz", inspect_config.column.as_str(), key)); + + let write_result = fs::OpenOptions::new() + .create(true) + .write(true) + .open(&file_path) + .map_err(|e| format!("Failed to open file: {:?}", e)) + .map(|mut file| { + file.write_all(&value) + .map_err(|e| format!("Failed to write file: {:?}", e)) + }); + if let Err(e) = write_result { + println!("Error writing values to file {:?}: {:?}", file_path, e); + } else { + println!("Successfully saved values to file: {:?}", file_path); + } + + total += value.len(); + } } } match inspect_config.target { - InspectTarget::ValueSizes | InspectTarget::ValueTotal => { + InspectTarget::ValueSizes | InspectTarget::ValueTotal | InspectTarget::Values => { println!("Total: {} bytes", total); } } @@ -292,21 +339,23 @@ pub fn run(cli_args: &ArgMatches<'_>, env: Environment) -> Result let client_config = parse_client_config(cli_args, &env)?; let context = env.core_context(); let log = context.log().clone(); + let format_err = |e| format!("Fatal error: {:?}", e); match cli_args.subcommand() { - ("version", Some(_)) => display_db_version(client_config, &context, log), + ("version", Some(_)) => { + display_db_version(client_config, &context, log).map_err(format_err) + } ("migrate", Some(cli_args)) => { let migrate_config = parse_migrate_config(cli_args)?; - migrate_db(migrate_config, client_config, &context, log) + migrate_db(migrate_config, client_config, &context, log).map_err(format_err) } ("inspect", Some(cli_args)) => { let inspect_config = parse_inspect_config(cli_args)?; inspect_db(inspect_config, client_config, &context, log) } - ("prune_payloads", Some(_)) => prune_payloads(client_config, &context, log), - _ => { - return Err("Unknown subcommand, for help `lighthouse database_manager --help`".into()) + ("prune_payloads", Some(_)) => { + prune_payloads(client_config, &context, log).map_err(format_err) } + _ => Err("Unknown subcommand, for help `lighthouse database_manager --help`".into()), } - .map_err(|e| format!("Fatal error: {:?}", e)) } From 2a7e54d8bdfad9d05997660d5ad5ee81a4291821 Mon Sep 17 00:00:00 2001 From: Eitan Seri-Levi Date: Tue, 30 May 2023 01:38:49 +0000 Subject: [PATCH 05/18] swap unnecessary write lock to read lock in block_verification (#4340) ## Issue Addressed [#4334](https://github.com/sigp/lighthouse/issues/4334) ## Proposed Changes swap unnecessary write lock to read lock ## Additional Info N/A Co-authored-by: Michael Sproul --- beacon_node/beacon_chain/src/block_verification.rs | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/beacon_node/beacon_chain/src/block_verification.rs b/beacon_node/beacon_chain/src/block_verification.rs index ca4df864d..dba38af9b 100644 --- a/beacon_node/beacon_chain/src/block_verification.rs +++ b/beacon_node/beacon_chain/src/block_verification.rs @@ -747,7 +747,7 @@ impl GossipVerifiedBlock { // We check this *before* we load the parent so that we can return a more detailed error. check_block_is_finalized_checkpoint_or_descendant( chain, - &chain.canonical_head.fork_choice_write_lock(), + &chain.canonical_head.fork_choice_read_lock(), &block, )?; From a7da331f6a459c574cfe601b61da6903d68c3a22 Mon Sep 17 00:00:00 2001 From: Pawan Dhananjay Date: Tue, 30 May 2023 01:38:50 +0000 Subject: [PATCH 06/18] Fix geth scripts (#4342) ## Issue Addressed N/A ## Proposed Changes Geth's latest release breaks our CI with the following message ``` Fatal: Failed to register the Ethereum service: ethash is only supported as a historical component of already merged networks Shutting down ``` Latest geth version has removed support for PoW networks. Hence, we need to add an extra `terminalTotalDifficultyPassed ` parameter in the genesis config to start from a merged network. --- scripts/local_testnet/genesis.json | 3 ++- scripts/tests/genesis.json | 3 ++- 2 files changed, 4 insertions(+), 2 deletions(-) diff --git a/scripts/local_testnet/genesis.json b/scripts/local_testnet/genesis.json index f92a5f5d0..3ac553e55 100644 --- a/scripts/local_testnet/genesis.json +++ b/scripts/local_testnet/genesis.json @@ -13,7 +13,8 @@ "londonBlock": 0, "mergeNetsplitBlock": 0, "shanghaiTime": 0, - "terminalTotalDifficulty": 0 + "terminalTotalDifficulty": 0, + "terminalTotalDifficultyPassed": true }, "alloc": { "0xa94f5374fce5edbc8e2a8697c15331677e6ebf0b": { diff --git a/scripts/tests/genesis.json b/scripts/tests/genesis.json index 985bb9cef..ec3cd1e81 100644 --- a/scripts/tests/genesis.json +++ b/scripts/tests/genesis.json @@ -12,7 +12,8 @@ "berlinBlock": 0, "londonBlock": 0, "mergeForkBlock": 0, - "terminalTotalDifficulty": 0 + "terminalTotalDifficulty": 0, + "terminalTotalDifficultyPassed": true }, "alloc": { "0x0000000000000000000000000000000000000000": { From baad729fa7afb637af750b04ea005aa3f22eb1ee Mon Sep 17 00:00:00 2001 From: Michael Sproul Date: Tue, 30 May 2023 01:38:51 +0000 Subject: [PATCH 07/18] Fix Rust 1.71.0 warnings (#4348) ## Issue Addressed The Rust 1.70 release is imminent, so CI is using 1.71 for the Beta compiler, which is failing with a warning. --- beacon_node/lighthouse_network/src/peer_manager/mod.rs | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/beacon_node/lighthouse_network/src/peer_manager/mod.rs b/beacon_node/lighthouse_network/src/peer_manager/mod.rs index b2096013b..c6c737cae 100644 --- a/beacon_node/lighthouse_network/src/peer_manager/mod.rs +++ b/beacon_node/lighthouse_network/src/peer_manager/mod.rs @@ -1266,7 +1266,7 @@ impl PeerManager { ); } - let mut score_peers: &mut (f64, usize) = avg_score_per_client + let score_peers: &mut (f64, usize) = avg_score_per_client .entry(peer_info.client().kind.to_string()) .or_default(); score_peers.0 += peer_info.score().score(); From d150ccbee53c55b582d82bec6d8011167d22a93a Mon Sep 17 00:00:00 2001 From: Daniel Ramirez Chiquillo Date: Tue, 30 May 2023 06:15:54 +0000 Subject: [PATCH 08/18] Add `libpq-dev` and `docker` to the to the list of additional requirements for developers in the Book (#4282) ## Issue Addressed Realized this was missing while discussing #4280 ## Proposed Changes Add an Item to the list of additional requirements for developers. --- book/src/setup.md | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/book/src/setup.md b/book/src/setup.md index 62580ac1b..ea3c5664a 100644 --- a/book/src/setup.md +++ b/book/src/setup.md @@ -18,7 +18,9 @@ The additional requirements for developers are: the networking stack. - [`java 11 runtime`](https://openjdk.java.net/projects/jdk/). 11 is the minimum, used by web3signer_tests. - +- [`libpq-dev`](https://www.postgresql.org/docs/devel/libpq.html). Also know as + `libpq-devel` on some systems. +- [`docker`](https://www.docker.com/). Some tests need docker installed and **running**. ## Using `make` Commands to run the test suite are available via the `Makefile` in the From fdea8f2b27c2e682029eea1ae374ebd54b578ecf Mon Sep 17 00:00:00 2001 From: Age Manning Date: Tue, 30 May 2023 06:15:56 +0000 Subject: [PATCH 09/18] Shift subnet backbone structure (attnets revamp) (#4304) This PR address the following spec change: https://github.com/ethereum/consensus-specs/pull/3312 Instead of subscribing to a long-lived subnet for every attached validator to a beacon node, all beacon nodes will subscribe to `SUBNETS_PER_NODE` long-lived subnets. This is currently set to 2 for mainnet. This PR does not include any scoring or advanced discovery mechanisms. A future PR will improve discovery and we can implement scoring after the next hard fork when we expect all client teams and all implementations to respect this spec change. This will be a significant change in the subnet network structure for consensus clients and we will likely have to monitor and tweak our peer management logic. --- beacon_node/network/Cargo.toml | 6 +- beacon_node/network/src/service.rs | 3 +- .../src/subnet_service/attestation_subnets.rs | 388 +++--------------- .../network/src/subnet_service/tests/mod.rs | 157 ++++--- .../gnosis/config.yaml | 4 + .../mainnet/config.yaml | 4 + .../prater/config.yaml | 4 + .../sepolia/config.yaml | 4 + consensus/types/src/chain_spec.rs | 38 +- consensus/types/src/config_and_preset.rs | 4 - consensus/types/src/subnet_id.rs | 93 ++++- 11 files changed, 277 insertions(+), 428 deletions(-) diff --git a/beacon_node/network/Cargo.toml b/beacon_node/network/Cargo.toml index a234165d1..c99172899 100644 --- a/beacon_node/network/Cargo.toml +++ b/beacon_node/network/Cargo.toml @@ -46,8 +46,4 @@ derivative = "2.2.0" delay_map = "0.3.0" ethereum-types = { version = "0.14.1", optional = true } operation_pool = { path = "../operation_pool" } -execution_layer = { path = "../execution_layer" } - -[features] -deterministic_long_lived_attnets = [ "ethereum-types" ] -# default = ["deterministic_long_lived_attnets"] +execution_layer = { path = "../execution_layer" } \ No newline at end of file diff --git a/beacon_node/network/src/service.rs b/beacon_node/network/src/service.rs index edc1d5c2e..2c919233f 100644 --- a/beacon_node/network/src/service.rs +++ b/beacon_node/network/src/service.rs @@ -317,8 +317,7 @@ impl NetworkService { // attestation subnet service let attestation_service = AttestationService::new( beacon_chain.clone(), - #[cfg(feature = "deterministic_long_lived_attnets")] - network_globals.local_enr().node_id().raw().into(), + network_globals.local_enr().node_id(), config, &network_log, ); diff --git a/beacon_node/network/src/subnet_service/attestation_subnets.rs b/beacon_node/network/src/subnet_service/attestation_subnets.rs index e46a52cfb..b4f52df39 100644 --- a/beacon_node/network/src/subnet_service/attestation_subnets.rs +++ b/beacon_node/network/src/subnet_service/attestation_subnets.rs @@ -3,7 +3,6 @@ //! determines whether attestations should be aggregated and/or passed to the beacon node. use super::SubnetServiceMessage; -#[cfg(any(test, feature = "deterministic_long_lived_attnets"))] use std::collections::HashSet; use std::collections::{HashMap, VecDeque}; use std::pin::Pin; @@ -14,10 +13,8 @@ use std::time::Duration; use beacon_chain::{BeaconChain, BeaconChainTypes}; use delay_map::{HashMapDelay, HashSetDelay}; use futures::prelude::*; -use lighthouse_network::{NetworkConfig, Subnet, SubnetDiscovery}; -#[cfg(not(feature = "deterministic_long_lived_attnets"))] -use rand::seq::SliceRandom; -use slog::{debug, error, o, trace, warn}; +use lighthouse_network::{discv5::enr::NodeId, NetworkConfig, Subnet, SubnetDiscovery}; +use slog::{debug, error, info, o, trace, warn}; use slot_clock::SlotClock; use types::{Attestation, EthSpec, Slot, SubnetId, ValidatorSubscription}; @@ -27,10 +24,6 @@ use crate::metrics; /// slot is less than this number, skip the peer discovery process. /// Subnet discovery query takes at most 30 secs, 2 slots take 24s. pub(crate) const MIN_PEER_DISCOVERY_SLOT_LOOK_AHEAD: u64 = 2; -/// The time (in slots) before a last seen validator is considered absent and we unsubscribe from -/// the random gossip topics that we subscribed to due to the validator connection. -#[cfg(not(feature = "deterministic_long_lived_attnets"))] -const LAST_SEEN_VALIDATOR_TIMEOUT_SLOTS: u32 = 150; /// The fraction of a slot that we subscribe to a subnet before the required slot. /// /// Currently a whole slot ahead. @@ -67,30 +60,23 @@ pub struct AttestationService { /// Subnets we are currently subscribed to as short lived subscriptions. /// /// Once they expire, we unsubscribe from these. + /// We subscribe to subnets when we are an aggregator for an exact subnet. short_lived_subscriptions: HashMapDelay, /// Subnets we are currently subscribed to as long lived subscriptions. /// /// We advertise these in our ENR. When these expire, the subnet is removed from our ENR. - #[cfg(feature = "deterministic_long_lived_attnets")] + /// These are required of all beacon nodes. The exact number is determined by the chain + /// specification. long_lived_subscriptions: HashSet, - #[cfg(not(feature = "deterministic_long_lived_attnets"))] - long_lived_subscriptions: HashMapDelay, - /// Short lived subscriptions that need to be done in the future. + /// Short lived subscriptions that need to be executed in the future. scheduled_short_lived_subscriptions: HashSetDelay, /// A collection timeouts to track the existence of aggregate validator subscriptions at an /// `ExactSubnet`. aggregate_validators_on_subnet: Option>, - /// A collection of seen validators. These dictate how many random subnets we should be - /// subscribed to. As these time out, we unsubscribe for the required random subnets and update - /// our ENR. - /// This is a set of validator indices. - #[cfg(not(feature = "deterministic_long_lived_attnets"))] - known_validators: HashSetDelay, - /// The waker for the current thread. waker: Option, @@ -100,16 +86,10 @@ pub struct AttestationService { /// We are always subscribed to all subnets. subscribe_all_subnets: bool, - /// For how many slots we subscribe to long lived subnets. - #[cfg(not(feature = "deterministic_long_lived_attnets"))] - long_lived_subnet_subscription_slots: u64, - /// Our Discv5 node_id. - #[cfg(feature = "deterministic_long_lived_attnets")] - node_id: ethereum_types::U256, + node_id: NodeId, /// Future used to manage subscribing and unsubscribing from long lived subnets. - #[cfg(feature = "deterministic_long_lived_attnets")] next_long_lived_subscription_event: Pin>, /// Whether this node is a block proposer-only node. @@ -122,62 +102,22 @@ pub struct AttestationService { impl AttestationService { /* Public functions */ - #[cfg(not(feature = "deterministic_long_lived_attnets"))] + /// Establish the service based on the passed configuration. pub fn new( beacon_chain: Arc>, + node_id: NodeId, config: &NetworkConfig, log: &slog::Logger, ) -> Self { let log = log.new(o!("service" => "attestation_service")); - // Calculate the random subnet duration from the spec constants. - let spec = &beacon_chain.spec; let slot_duration = beacon_chain.slot_clock.slot_duration(); - let long_lived_subnet_subscription_slots = spec - .epochs_per_random_subnet_subscription - .saturating_mul(T::EthSpec::slots_per_epoch()); - let long_lived_subscription_duration = Duration::from_millis( - slot_duration.as_millis() as u64 * long_lived_subnet_subscription_slots, - ); - // Panics on overflow. Ensure LAST_SEEN_VALIDATOR_TIMEOUT_SLOTS is not too large. - let last_seen_val_timeout = slot_duration - .checked_mul(LAST_SEEN_VALIDATOR_TIMEOUT_SLOTS) - .expect("LAST_SEEN_VALIDATOR_TIMEOUT must not be ridiculously large"); - - let track_validators = !config.import_all_attestations; - let aggregate_validators_on_subnet = - track_validators.then(|| HashSetDelay::new(slot_duration)); - AttestationService { - events: VecDeque::with_capacity(10), - beacon_chain, - short_lived_subscriptions: HashMapDelay::new(slot_duration), - long_lived_subscriptions: HashMapDelay::new(long_lived_subscription_duration), - scheduled_short_lived_subscriptions: HashSetDelay::default(), - aggregate_validators_on_subnet, - known_validators: HashSetDelay::new(last_seen_val_timeout), - waker: None, - discovery_disabled: config.disable_discovery, - proposer_only: config.proposer_only, - subscribe_all_subnets: config.subscribe_all_subnets, - long_lived_subnet_subscription_slots, - log, + if config.subscribe_all_subnets { + slog::info!(log, "Subscribing to all subnets"); + } else { + slog::info!(log, "Deterministic long lived subnets enabled"; "subnets_per_node" => beacon_chain.spec.subnets_per_node, "subscription_duration_in_epochs" => beacon_chain.spec.epochs_per_subnet_subscription); } - } - - #[cfg(feature = "deterministic_long_lived_attnets")] - pub fn new( - beacon_chain: Arc>, - node_id: ethereum_types::U256, - config: &NetworkConfig, - log: &slog::Logger, - ) -> Self { - let log = log.new(o!("service" => "attestation_service")); - - // Calculate the random subnet duration from the spec constants. - let slot_duration = beacon_chain.slot_clock.slot_duration(); - - slog::info!(log, "Deterministic long lived subnets enabled"; "subnets_per_node" => beacon_chain.spec.subnets_per_node); let track_validators = !config.import_all_attestations; let aggregate_validators_on_subnet = @@ -198,9 +138,15 @@ impl AttestationService { // value with a smarter timing Box::pin(tokio::time::sleep(Duration::from_secs(1))) }, + proposer_only: config.proposer_only, log, }; - service.recompute_long_lived_subnets(); + + // If we are not subscribed to all subnets, handle the deterministic set of subnets + if !config.subscribe_all_subnets { + service.recompute_long_lived_subnets(); + } + service } @@ -210,20 +156,12 @@ impl AttestationService { if self.subscribe_all_subnets { self.beacon_chain.spec.attestation_subnet_count as usize } else { - #[cfg(feature = "deterministic_long_lived_attnets")] let count = self .short_lived_subscriptions .keys() .chain(self.long_lived_subscriptions.iter()) .collect::>() .len(); - #[cfg(not(feature = "deterministic_long_lived_attnets"))] - let count = self - .short_lived_subscriptions - .keys() - .chain(self.long_lived_subscriptions.keys()) - .collect::>() - .len(); count } } @@ -236,20 +174,20 @@ impl AttestationService { subscription_kind: SubscriptionKind, ) -> bool { match subscription_kind { - #[cfg(feature = "deterministic_long_lived_attnets")] SubscriptionKind::LongLived => self.long_lived_subscriptions.contains(subnet_id), - #[cfg(not(feature = "deterministic_long_lived_attnets"))] - SubscriptionKind::LongLived => self.long_lived_subscriptions.contains_key(subnet_id), SubscriptionKind::ShortLived => self.short_lived_subscriptions.contains_key(subnet_id), } } + #[cfg(test)] + pub(crate) fn long_lived_subscriptions(&self) -> &HashSet { + &self.long_lived_subscriptions + } + /// Processes a list of validator subscriptions. /// /// This will: /// - Register new validators as being known. - /// - Subscribe to the required number of random subnets. - /// - Update the local ENR for new random subnets due to seeing new validators. /// - Search for peers for required subnets. /// - Request subscriptions for subnets on specific slots when required. /// - Build the timeouts for each of these events. @@ -267,18 +205,17 @@ impl AttestationService { // Maps each subnet_id subscription to it's highest slot let mut subnets_to_discover: HashMap = HashMap::new(); + + // Registers the validator with the attestation service. for subscription in subscriptions { metrics::inc_counter(&metrics::SUBNET_SUBSCRIPTION_REQUESTS); - // Registers the validator with the attestation service. - // This will subscribe to long-lived random subnets if required. trace!(self.log, "Validator subscription"; "subscription" => ?subscription, ); - #[cfg(not(feature = "deterministic_long_lived_attnets"))] - self.add_known_validator(subscription.validator_index); + // Compute the subnet that is associated with this subscription let subnet_id = match SubnetId::compute_subnet::( subscription.slot, subscription.attestation_committee_index, @@ -316,7 +253,7 @@ impl AttestationService { if subscription.is_aggregator { metrics::inc_counter(&metrics::SUBNET_SUBSCRIPTION_AGGREGATOR_REQUESTS); - if let Err(e) = self.subscribe_to_subnet(exact_subnet) { + if let Err(e) = self.subscribe_to_short_lived_subnet(exact_subnet) { warn!(self.log, "Subscription to subnet error"; "error" => e, @@ -347,14 +284,13 @@ impl AttestationService { Ok(()) } - #[cfg(feature = "deterministic_long_lived_attnets")] fn recompute_long_lived_subnets(&mut self) { // Ensure the next computation is scheduled even if assigning subnets fails. let next_subscription_event = self .recompute_long_lived_subnets_inner() .unwrap_or_else(|_| self.beacon_chain.slot_clock.slot_duration()); - debug!(self.log, "Recomputing deterministic long lived attnets"); + debug!(self.log, "Recomputing deterministic long lived subnets"); self.next_long_lived_subscription_event = Box::pin(tokio::time::sleep(next_subscription_event)); @@ -365,14 +301,13 @@ impl AttestationService { /// Gets the long lived subnets the node should be subscribed to during the current epoch and /// the remaining duration for which they remain valid. - #[cfg(feature = "deterministic_long_lived_attnets")] fn recompute_long_lived_subnets_inner(&mut self) -> Result { let current_epoch = self.beacon_chain.epoch().map_err( |e| error!(self.log, "Failed to get the current epoch from clock"; "err" => ?e), )?; let (subnets, next_subscription_epoch) = SubnetId::compute_subnets_for_epoch::( - self.node_id, + self.node_id.raw().into(), current_epoch, &self.beacon_chain.spec, ) @@ -396,17 +331,12 @@ impl AttestationService { Ok(next_subscription_event) } - #[cfg(all(test, feature = "deterministic_long_lived_attnets"))] - pub fn update_long_lived_subnets_testing(&mut self, subnets: HashSet) { - self.update_long_lived_subnets(subnets) - } - /// Updates the long lived subnets. /// /// New subnets are registered as subscribed, removed subnets as unsubscribed and the Enr /// updated accordingly. - #[cfg(feature = "deterministic_long_lived_attnets")] fn update_long_lived_subnets(&mut self, mut subnets: HashSet) { + info!(self.log, "Subscribing to long-lived subnets"; "subnets" => ?subnets.iter().collect::>()); for subnet in &subnets { // Add the events for those subnets that are new as long lived subscriptions. if !self.long_lived_subscriptions.contains(subnet) { @@ -430,28 +360,15 @@ impl AttestationService { } } - // Check for subnets that are being removed + // Update the long_lived_subnets set and check for subnets that are being removed std::mem::swap(&mut self.long_lived_subscriptions, &mut subnets); for subnet in subnets { if !self.long_lived_subscriptions.contains(&subnet) { - if !self.short_lived_subscriptions.contains_key(&subnet) { - debug!(self.log, "Unsubscribing from subnet"; "subnet" => ?subnet, "subscription_kind" => ?SubscriptionKind::LongLived); - self.queue_event(SubnetServiceMessage::Unsubscribe(Subnet::Attestation( - subnet, - ))); - } - - self.queue_event(SubnetServiceMessage::EnrRemove(Subnet::Attestation(subnet))); + self.handle_removed_subnet(subnet, SubscriptionKind::LongLived); } } } - /// Overwrites the long lived subscriptions for testing. - #[cfg(all(test, feature = "deterministic_long_lived_attnets"))] - pub fn set_long_lived_subscriptions(&mut self, subnets: HashSet) { - self.long_lived_subscriptions = subnets - } - /// Checks if we have subscribed aggregate validators for the subnet. If not, checks the gossip /// verification, re-propagates and returns false. pub fn should_process_attestation( @@ -535,7 +452,7 @@ impl AttestationService { } // Subscribes to the subnet if it should be done immediately, or schedules it if required. - fn subscribe_to_subnet( + fn subscribe_to_short_lived_subnet( &mut self, ExactSubnet { subnet_id, slot }: ExactSubnet, ) -> Result<(), &'static str> { @@ -564,12 +481,7 @@ impl AttestationService { // immediately. if time_to_subscription_start.is_zero() { // This is a current or past slot, we subscribe immediately. - self.subscribe_to_subnet_immediately( - subnet_id, - #[cfg(not(feature = "deterministic_long_lived_attnets"))] - SubscriptionKind::ShortLived, - slot + 1, - )?; + self.subscribe_to_short_lived_subnet_immediately(subnet_id, slot + 1)?; } else { // This is a future slot, schedule subscribing. trace!(self.log, "Scheduling subnet subscription"; "subnet" => ?subnet_id, "time_to_subscription_start" => ?time_to_subscription_start); @@ -580,79 +492,6 @@ impl AttestationService { Ok(()) } - /// Updates the `known_validators` mapping and subscribes to long lived subnets if required. - #[cfg(not(feature = "deterministic_long_lived_attnets"))] - fn add_known_validator(&mut self, validator_index: u64) { - let previously_known = self.known_validators.contains_key(&validator_index); - // Add the new validator or update the current timeout for a known validator. - self.known_validators.insert(validator_index); - if !previously_known { - // New validator has subscribed. - // Subscribe to random topics and update the ENR if needed. - self.subscribe_to_random_subnets(); - } - } - - /// Subscribe to long-lived random subnets and update the local ENR bitfield. - /// The number of subnets to subscribe depends on the number of active validators and number of - /// current subscriptions. - #[cfg(not(feature = "deterministic_long_lived_attnets"))] - fn subscribe_to_random_subnets(&mut self) { - if self.subscribe_all_subnets { - // This case is not handled by this service. - return; - } - - let max_subnets = self.beacon_chain.spec.attestation_subnet_count; - // Calculate how many subnets we need, - let required_long_lived_subnets = { - let subnets_for_validators = self - .known_validators - .len() - .saturating_mul(self.beacon_chain.spec.random_subnets_per_validator as usize); - subnets_for_validators // How many subnets we need - .min(max_subnets as usize) // Capped by the max - .saturating_sub(self.long_lived_subscriptions.len()) // Minus those we have - }; - - if required_long_lived_subnets == 0 { - // Nothing to do. - return; - } - - // Build a list of the subnets that we are not currently advertising. - let available_subnets = (0..max_subnets) - .map(SubnetId::new) - .filter(|subnet_id| !self.long_lived_subscriptions.contains_key(subnet_id)) - .collect::>(); - - let subnets_to_subscribe: Vec<_> = available_subnets - .choose_multiple(&mut rand::thread_rng(), required_long_lived_subnets) - .cloned() - .collect(); - - // Calculate in which slot does this subscription end. - let end_slot = match self.beacon_chain.slot_clock.now() { - Some(slot) => slot + self.long_lived_subnet_subscription_slots, - None => { - return debug!( - self.log, - "Failed to calculate end slot of long lived subnet subscriptions." - ) - } - }; - - for subnet_id in &subnets_to_subscribe { - if let Err(e) = self.subscribe_to_subnet_immediately( - *subnet_id, - SubscriptionKind::LongLived, - end_slot, - ) { - debug!(self.log, "Failed to subscribe to long lived subnet"; "subnet" => ?subnet_id, "err" => e); - } - } - } - /* A collection of functions that handle the various timeouts */ /// Registers a subnet as subscribed. @@ -662,11 +501,9 @@ impl AttestationService { /// out the appropriate events. /// /// On determinist long lived subnets, this is only used for short lived subscriptions. - fn subscribe_to_subnet_immediately( + fn subscribe_to_short_lived_subnet_immediately( &mut self, subnet_id: SubnetId, - #[cfg(not(feature = "deterministic_long_lived_attnets"))] - subscription_kind: SubscriptionKind, end_slot: Slot, ) -> Result<(), &'static str> { if self.subscribe_all_subnets { @@ -685,25 +522,12 @@ impl AttestationService { return Err("Time when subscription would end has already passed."); } - #[cfg(feature = "deterministic_long_lived_attnets")] let subscription_kind = SubscriptionKind::ShortLived; // We need to check and add a subscription for the right kind, regardless of the presence // of the subnet as a subscription of the other kind. This is mainly since long lived // subscriptions can be removed at any time when a validator goes offline. - #[cfg(not(feature = "deterministic_long_lived_attnets"))] - let (subscriptions, already_subscribed_as_other_kind) = match subscription_kind { - SubscriptionKind::ShortLived => ( - &mut self.short_lived_subscriptions, - self.long_lived_subscriptions.contains_key(&subnet_id), - ), - SubscriptionKind::LongLived => ( - &mut self.long_lived_subscriptions, - self.short_lived_subscriptions.contains_key(&subnet_id), - ), - }; - #[cfg(feature = "deterministic_long_lived_attnets")] let (subscriptions, already_subscribed_as_other_kind) = ( &mut self.short_lived_subscriptions, self.long_lived_subscriptions.contains(&subnet_id), @@ -738,57 +562,19 @@ impl AttestationService { subnet_id, ))); } - - // If this is a new long lived subscription, send out the appropriate events. - #[cfg(not(feature = "deterministic_long_lived_attnets"))] - if SubscriptionKind::LongLived == subscription_kind { - let subnet = Subnet::Attestation(subnet_id); - // Advertise this subnet in our ENR. - self.long_lived_subscriptions.insert_at( - subnet_id, - end_slot, - time_to_subscription_end, - ); - self.queue_event(SubnetServiceMessage::EnrAdd(subnet)); - - if !self.discovery_disabled { - self.queue_event(SubnetServiceMessage::DiscoverPeers(vec![ - SubnetDiscovery { - subnet, - min_ttl: None, - }, - ])) - } - } } } Ok(()) } - /// A random subnet has expired. - /// - /// This function selects a new subnet to join, or extends the expiry if there are no more - /// available subnets to choose from. - #[cfg(not(feature = "deterministic_long_lived_attnets"))] - fn handle_random_subnet_expiry(&mut self, subnet_id: SubnetId) { - self.handle_removed_subnet(subnet_id, SubscriptionKind::LongLived); - - // Remove the ENR bitfield bit and choose a new random on from the available subnets - // Subscribe to a new random subnet. - self.subscribe_to_random_subnets(); - } - // Unsubscribes from a subnet that was removed if it does not continue to exist as a // subscription of the other kind. For long lived subscriptions, it also removes the // advertisement from our ENR. fn handle_removed_subnet(&mut self, subnet_id: SubnetId, subscription_kind: SubscriptionKind) { let exists_in_other_subscriptions = match subscription_kind { SubscriptionKind::LongLived => self.short_lived_subscriptions.contains_key(&subnet_id), - #[cfg(feature = "deterministic_long_lived_attnets")] SubscriptionKind::ShortLived => self.long_lived_subscriptions.contains(&subnet_id), - #[cfg(not(feature = "deterministic_long_lived_attnets"))] - SubscriptionKind::ShortLived => self.long_lived_subscriptions.contains_key(&subnet_id), }; if !exists_in_other_subscriptions { @@ -806,48 +592,6 @@ impl AttestationService { ))); } } - - /// A known validator has not sent a subscription in a while. They are considered offline and the - /// beacon node no longer needs to be subscribed to the allocated random subnets. - /// - /// We don't keep track of a specific validator to random subnet, rather the ratio of active - /// validators to random subnets. So when a validator goes offline, we can simply remove the - /// allocated amount of random subnets. - #[cfg(not(feature = "deterministic_long_lived_attnets"))] - fn handle_known_validator_expiry(&mut self) { - // Calculate how many subnets should we remove. - let extra_subnet_count = { - let max_subnets = self.beacon_chain.spec.attestation_subnet_count; - let subnets_for_validators = self - .known_validators - .len() - .saturating_mul(self.beacon_chain.spec.random_subnets_per_validator as usize) - .min(max_subnets as usize); - - self.long_lived_subscriptions - .len() - .saturating_sub(subnets_for_validators) - }; - - if extra_subnet_count == 0 { - // Nothing to do - return; - } - - let advertised_subnets = self - .long_lived_subscriptions - .keys() - .cloned() - .collect::>(); - let to_remove_subnets = advertised_subnets - .choose_multiple(&mut rand::thread_rng(), extra_subnet_count) - .cloned(); - - for subnet_id in to_remove_subnets { - self.long_lived_subscriptions.remove(&subnet_id); - self.handle_removed_subnet(subnet_id, SubscriptionKind::LongLived); - } - } } impl Stream for AttestationService { @@ -868,37 +612,34 @@ impl Stream for AttestationService { return Poll::Ready(Some(event)); } - // Process first any known validator expiries, since these affect how many long lived - // subnets we need. - #[cfg(not(feature = "deterministic_long_lived_attnets"))] - match self.known_validators.poll_next_unpin(cx) { - Poll::Ready(Some(Ok(_validator_index))) => { - self.handle_known_validator_expiry(); + // If we aren't subscribed to all subnets, handle the deterministic long-lived subnets + if !self.subscribe_all_subnets { + match self.next_long_lived_subscription_event.as_mut().poll(cx) { + Poll::Ready(_) => { + self.recompute_long_lived_subnets(); + // We re-wake the task as there could be other subscriptions to process + self.waker + .as_ref() + .expect("Waker has been set") + .wake_by_ref(); + } + Poll::Pending => {} } - Poll::Ready(Some(Err(e))) => { - error!(self.log, "Failed to check for random subnet cycles"; "error"=> e); - } - Poll::Ready(None) | Poll::Pending => {} - } - - #[cfg(feature = "deterministic_long_lived_attnets")] - match self.next_long_lived_subscription_event.as_mut().poll(cx) { - Poll::Ready(_) => self.recompute_long_lived_subnets(), - Poll::Pending => {} } // Process scheduled subscriptions that might be ready, since those can extend a soon to // expire subscription. match self.scheduled_short_lived_subscriptions.poll_next_unpin(cx) { Poll::Ready(Some(Ok(ExactSubnet { subnet_id, slot }))) => { - if let Err(e) = self.subscribe_to_subnet_immediately( - subnet_id, - #[cfg(not(feature = "deterministic_long_lived_attnets"))] - SubscriptionKind::ShortLived, - slot + 1, - ) { + if let Err(e) = + self.subscribe_to_short_lived_subnet_immediately(subnet_id, slot + 1) + { debug!(self.log, "Failed to subscribe to short lived subnet"; "subnet" => ?subnet_id, "err" => e); } + self.waker + .as_ref() + .expect("Waker has been set") + .wake_by_ref(); } Poll::Ready(Some(Err(e))) => { error!(self.log, "Failed to check for scheduled subnet subscriptions"; "error"=> e); @@ -910,6 +651,11 @@ impl Stream for AttestationService { match self.short_lived_subscriptions.poll_next_unpin(cx) { Poll::Ready(Some(Ok((subnet_id, _end_slot)))) => { self.handle_removed_subnet(subnet_id, SubscriptionKind::ShortLived); + // We re-wake the task as there could be other subscriptions to process + self.waker + .as_ref() + .expect("Waker has been set") + .wake_by_ref(); } Poll::Ready(Some(Err(e))) => { error!(self.log, "Failed to check for subnet unsubscription times"; "error"=> e); @@ -917,18 +663,6 @@ impl Stream for AttestationService { Poll::Ready(None) | Poll::Pending => {} } - // Process any random subnet expiries. - #[cfg(not(feature = "deterministic_long_lived_attnets"))] - match self.long_lived_subscriptions.poll_next_unpin(cx) { - Poll::Ready(Some(Ok((subnet_id, _end_slot)))) => { - self.handle_random_subnet_expiry(subnet_id) - } - Poll::Ready(Some(Err(e))) => { - error!(self.log, "Failed to check for random subnet cycles"; "error"=> e); - } - Poll::Ready(None) | Poll::Pending => {} - } - // Poll to remove entries on expiration, no need to act on expiration events. if let Some(tracked_vals) = self.aggregate_validators_on_subnet.as_mut() { if let Poll::Ready(Some(Err(e))) = tracked_vals.poll_next_unpin(cx) { diff --git a/beacon_node/network/src/subnet_service/tests/mod.rs b/beacon_node/network/src/subnet_service/tests/mod.rs index a407fe1bc..3b8c89a44 100644 --- a/beacon_node/network/src/subnet_service/tests/mod.rs +++ b/beacon_node/network/src/subnet_service/tests/mod.rs @@ -126,10 +126,7 @@ fn get_attestation_service( AttestationService::new( beacon_chain, - #[cfg(feature = "deterministic_long_lived_attnets")] - lighthouse_network::discv5::enr::NodeId::random() - .raw() - .into(), + lighthouse_network::discv5::enr::NodeId::random(), &config, &log, ) @@ -179,9 +176,6 @@ async fn get_events + Unpin>( mod attestation_service { - #[cfg(feature = "deterministic_long_lived_attnets")] - use std::collections::HashSet; - #[cfg(not(windows))] use crate::subnet_service::attestation_subnets::MIN_PEER_DISCOVERY_SLOT_LOOK_AHEAD; @@ -192,8 +186,8 @@ mod attestation_service { attestation_committee_index: CommitteeIndex, slot: Slot, committee_count_at_slot: u64, + is_aggregator: bool, ) -> ValidatorSubscription { - let is_aggregator = true; ValidatorSubscription { validator_index, attestation_committee_index, @@ -203,11 +197,11 @@ mod attestation_service { } } - #[cfg(not(feature = "deterministic_long_lived_attnets"))] fn get_subscriptions( validator_count: u64, slot: Slot, committee_count_at_slot: u64, + is_aggregator: bool, ) -> Vec { (0..validator_count) .map(|validator_index| { @@ -216,6 +210,7 @@ mod attestation_service { validator_index, slot, committee_count_at_slot, + is_aggregator, ) }) .collect() @@ -229,6 +224,7 @@ mod attestation_service { // Keep a low subscription slot so that there are no additional subnet discovery events. let subscription_slot = 0; let committee_count = 1; + let subnets_per_node = MainnetEthSpec::default_spec().subnets_per_node as usize; // create the attestation service and subscriptions let mut attestation_service = get_attestation_service(None); @@ -243,6 +239,7 @@ mod attestation_service { committee_index, current_slot + Slot::new(subscription_slot), committee_count, + true, )]; // submit the subscriptions @@ -266,16 +263,19 @@ mod attestation_service { // Wait for 1 slot duration to get the unsubscription event let events = get_events( &mut attestation_service, - Some(5), + Some(subnets_per_node * 3 + 2), (MainnetEthSpec::slots_per_epoch() * 3) as u32, ) .await; matches::assert_matches!( - events[..3], + events[..6], [ SubnetServiceMessage::Subscribe(_any1), SubnetServiceMessage::EnrAdd(_any3), SubnetServiceMessage::DiscoverPeers(_), + SubnetServiceMessage::Subscribe(_), + SubnetServiceMessage::EnrAdd(_), + SubnetServiceMessage::DiscoverPeers(_), ] ); @@ -284,10 +284,10 @@ mod attestation_service { if !attestation_service .is_subscribed(&subnet_id, attestation_subnets::SubscriptionKind::LongLived) { - assert_eq!(expected[..], events[3..]); + assert_eq!(expected[..], events[subnets_per_node * 3..]); } - // Should be subscribed to only 1 long lived subnet after unsubscription. - assert_eq!(attestation_service.subscription_count(), 1); + // Should be subscribed to only subnets_per_node long lived subnet after unsubscription. + assert_eq!(attestation_service.subscription_count(), subnets_per_node); } /// Test to verify that we are not unsubscribing to a subnet before a required subscription. @@ -297,6 +297,7 @@ mod attestation_service { // subscription config let validator_index = 1; let committee_count = 1; + let subnets_per_node = MainnetEthSpec::default_spec().subnets_per_node as usize; // Makes 2 validator subscriptions to the same subnet but at different slots. // There should be just 1 unsubscription event for the later slot subscription (subscription_slot2). @@ -318,6 +319,7 @@ mod attestation_service { com1, current_slot + Slot::new(subscription_slot1), committee_count, + true, ); let sub2 = get_subscription( @@ -325,6 +327,7 @@ mod attestation_service { com2, current_slot + Slot::new(subscription_slot2), committee_count, + true, ); let subnet_id1 = SubnetId::compute_subnet::( @@ -366,16 +369,22 @@ mod attestation_service { let expected = SubnetServiceMessage::Subscribe(Subnet::Attestation(subnet_id1)); - // Should be still subscribed to 1 long lived and 1 short lived subnet if both are + // Should be still subscribed to 2 long lived and up to 1 short lived subnet if both are // different. if !attestation_service.is_subscribed( &subnet_id1, attestation_subnets::SubscriptionKind::LongLived, ) { - assert_eq!(expected, events[3]); - assert_eq!(attestation_service.subscription_count(), 2); + // The index is 3*subnets_per_node (because we subscribe + discover + enr per long lived + // subnet) + 1 + let index = 3 * subnets_per_node; + assert_eq!(expected, events[index]); + assert_eq!( + attestation_service.subscription_count(), + subnets_per_node + 1 + ); } else { - assert_eq!(attestation_service.subscription_count(), 1); + assert!(attestation_service.subscription_count() == subnets_per_node); } // Get event for 1 more slot duration, we should get the unsubscribe event now. @@ -395,17 +404,17 @@ mod attestation_service { ); } - // Should be subscribed to only 1 long lived subnet after unsubscription. - assert_eq!(attestation_service.subscription_count(), 1); + // Should be subscribed 2 long lived subnet after unsubscription. + assert_eq!(attestation_service.subscription_count(), subnets_per_node); } - #[cfg(not(feature = "deterministic_long_lived_attnets"))] #[tokio::test] - async fn subscribe_all_random_subnets() { + async fn subscribe_all_subnets() { let attestation_subnet_count = MainnetEthSpec::default_spec().attestation_subnet_count; - let subscription_slot = 10; + let subscription_slot = 3; let subscription_count = attestation_subnet_count; let committee_count = 1; + let subnets_per_node = MainnetEthSpec::default_spec().subnets_per_node as usize; // create the attestation service and subscriptions let mut attestation_service = get_attestation_service(None); @@ -419,6 +428,7 @@ mod attestation_service { subscription_count, current_slot + subscription_slot, committee_count, + true, ); // submit the subscriptions @@ -426,42 +436,52 @@ mod attestation_service { .validator_subscriptions(subscriptions) .unwrap(); - let events = get_events(&mut attestation_service, None, 3).await; + let events = get_events(&mut attestation_service, Some(131), 10).await; let mut discover_peer_count = 0; let mut enr_add_count = 0; let mut unexpected_msg_count = 0; + let mut unsubscribe_event_count = 0; for event in &events { match event { SubnetServiceMessage::DiscoverPeers(_) => discover_peer_count += 1, SubnetServiceMessage::Subscribe(_any_subnet) => {} SubnetServiceMessage::EnrAdd(_any_subnet) => enr_add_count += 1, + SubnetServiceMessage::Unsubscribe(_) => unsubscribe_event_count += 1, _ => unexpected_msg_count += 1, } } + // There should be a Subscribe Event, and Enr Add event and a DiscoverPeers event for each + // long-lived subnet initially. The next event should be a bulk discovery event. + let bulk_discovery_index = 3 * subnets_per_node; // The bulk discovery request length should be equal to validator_count - let bulk_discovery_event = events.last().unwrap(); + let bulk_discovery_event = &events[bulk_discovery_index]; if let SubnetServiceMessage::DiscoverPeers(d) = bulk_discovery_event { assert_eq!(d.len(), attestation_subnet_count as usize); } else { panic!("Unexpected event {:?}", bulk_discovery_event); } - // 64 `DiscoverPeer` requests of length 1 corresponding to random subnets + // 64 `DiscoverPeer` requests of length 1 corresponding to deterministic subnets // and 1 `DiscoverPeer` request corresponding to bulk subnet discovery. - assert_eq!(discover_peer_count, subscription_count + 1); - assert_eq!(attestation_service.subscription_count(), 64); - assert_eq!(enr_add_count, 64); + assert_eq!(discover_peer_count, subnets_per_node + 1); + assert_eq!(attestation_service.subscription_count(), subnets_per_node); + assert_eq!(enr_add_count, subnets_per_node); + assert_eq!( + unsubscribe_event_count, + attestation_subnet_count - subnets_per_node as u64 + ); assert_eq!(unexpected_msg_count, 0); // test completed successfully } - #[cfg(not(feature = "deterministic_long_lived_attnets"))] #[tokio::test] - async fn subscribe_all_random_subnets_plus_one() { + async fn subscribe_correct_number_of_subnets() { let attestation_subnet_count = MainnetEthSpec::default_spec().attestation_subnet_count; let subscription_slot = 10; + let subnets_per_node = MainnetEthSpec::default_spec().subnets_per_node as usize; + // the 65th subscription should result in no more messages than the previous scenario let subscription_count = attestation_subnet_count + 1; let committee_count = 1; @@ -478,6 +498,7 @@ mod attestation_service { subscription_count, current_slot + subscription_slot, committee_count, + true, ); // submit the subscriptions @@ -506,12 +527,12 @@ mod attestation_service { } else { panic!("Unexpected event {:?}", bulk_discovery_event); } - // 64 `DiscoverPeer` requests of length 1 corresponding to random subnets + // subnets_per_node `DiscoverPeer` requests of length 1 corresponding to long-lived subnets // and 1 `DiscoverPeer` request corresponding to the bulk subnet discovery. - // For the 65th subscription, the call to `subscribe_to_random_subnets` is not made because we are at capacity. - assert_eq!(discover_peer_count, 64 + 1); - assert_eq!(attestation_service.subscription_count(), 64); - assert_eq!(enr_add_count, 64); + + assert_eq!(discover_peer_count, subnets_per_node + 1); + assert_eq!(attestation_service.subscription_count(), subnets_per_node); + assert_eq!(enr_add_count, subnets_per_node); assert_eq!(unexpected_msg_count, 0); } @@ -521,6 +542,7 @@ mod attestation_service { // subscription config let validator_index = 1; let committee_count = 1; + let subnets_per_node = MainnetEthSpec::default_spec().subnets_per_node as usize; // Makes 2 validator subscriptions to the same subnet but at different slots. // There should be just 1 unsubscription event for the later slot subscription (subscription_slot2). @@ -542,6 +564,7 @@ mod attestation_service { com1, current_slot + Slot::new(subscription_slot1), committee_count, + true, ); let sub2 = get_subscription( @@ -549,6 +572,7 @@ mod attestation_service { com2, current_slot + Slot::new(subscription_slot2), committee_count, + true, ); let subnet_id1 = SubnetId::compute_subnet::( @@ -596,11 +620,10 @@ mod attestation_service { &subnet_id1, attestation_subnets::SubscriptionKind::LongLived, ) { - assert_eq!(expected_subscription, events[3]); - // fourth is a discovery event - assert_eq!(expected_unsubscription, events[5]); + assert_eq!(expected_subscription, events[subnets_per_node * 3]); + assert_eq!(expected_unsubscription, events[subnets_per_node * 3 + 2]); } - assert_eq!(attestation_service.subscription_count(), 1); + assert_eq!(attestation_service.subscription_count(), 2); println!("{events:?}"); let subscription_slot = current_slot + subscription_slot2 - 1; // one less do to the @@ -633,40 +656,44 @@ mod attestation_service { } #[tokio::test] - #[cfg(feature = "deterministic_long_lived_attnets")] async fn test_update_deterministic_long_lived_subnets() { let mut attestation_service = get_attestation_service(None); - let new_subnet = SubnetId::new(1); - let maintained_subnet = SubnetId::new(2); - let removed_subnet = SubnetId::new(3); + let subnets_per_node = MainnetEthSpec::default_spec().subnets_per_node as usize; + let current_slot = attestation_service + .beacon_chain + .slot_clock + .now() + .expect("Could not get current slot"); + + let subscriptions = get_subscriptions(20, current_slot, 30, false); + + // submit the subscriptions attestation_service - .set_long_lived_subscriptions(HashSet::from([removed_subnet, maintained_subnet])); - // clear initial events - let _events = get_events(&mut attestation_service, None, 1).await; + .validator_subscriptions(subscriptions) + .unwrap(); - attestation_service - .update_long_lived_subnets_testing(HashSet::from([maintained_subnet, new_subnet])); - - let events = get_events(&mut attestation_service, None, 1).await; - let new_subnet = Subnet::Attestation(new_subnet); - let removed_subnet = Subnet::Attestation(removed_subnet); + // There should only be the same subscriptions as there are in the specification, + // regardless of subscriptions assert_eq!( - events, + attestation_service.long_lived_subscriptions().len(), + subnets_per_node + ); + + let events = get_events(&mut attestation_service, None, 4).await; + + // Check that we attempt to subscribe and register ENRs + matches::assert_matches!( + events[..6], [ - // events for the new subnet - SubnetServiceMessage::Subscribe(new_subnet), - SubnetServiceMessage::EnrAdd(new_subnet), - SubnetServiceMessage::DiscoverPeers(vec![SubnetDiscovery { - subnet: new_subnet, - min_ttl: None - }]), - // events for the removed subnet - SubnetServiceMessage::Unsubscribe(removed_subnet), - SubnetServiceMessage::EnrRemove(removed_subnet), + SubnetServiceMessage::Subscribe(_), + SubnetServiceMessage::EnrAdd(_), + SubnetServiceMessage::DiscoverPeers(_), + SubnetServiceMessage::Subscribe(_), + SubnetServiceMessage::EnrAdd(_), + SubnetServiceMessage::DiscoverPeers(_), ] ); - println!("{events:?}") } } diff --git a/common/eth2_network_config/built_in_network_configs/gnosis/config.yaml b/common/eth2_network_config/built_in_network_configs/gnosis/config.yaml index ca1d1e88a..95ca9d010 100644 --- a/common/eth2_network_config/built_in_network_configs/gnosis/config.yaml +++ b/common/eth2_network_config/built_in_network_configs/gnosis/config.yaml @@ -86,3 +86,7 @@ PROPOSER_SCORE_BOOST: 40 DEPOSIT_CHAIN_ID: 100 DEPOSIT_NETWORK_ID: 100 DEPOSIT_CONTRACT_ADDRESS: 0x0B98057eA310F4d31F2a452B414647007d1645d9 + +# Network +# --------------------------------------------------------------- +SUBNETS_PER_NODE: 4 \ No newline at end of file diff --git a/common/eth2_network_config/built_in_network_configs/mainnet/config.yaml b/common/eth2_network_config/built_in_network_configs/mainnet/config.yaml index 0bbf873a3..7b26b30a6 100644 --- a/common/eth2_network_config/built_in_network_configs/mainnet/config.yaml +++ b/common/eth2_network_config/built_in_network_configs/mainnet/config.yaml @@ -86,3 +86,7 @@ PROPOSER_SCORE_BOOST: 40 DEPOSIT_CHAIN_ID: 1 DEPOSIT_NETWORK_ID: 1 DEPOSIT_CONTRACT_ADDRESS: 0x00000000219ab540356cBB839Cbe05303d7705Fa + +# Network +# --------------------------------------------------------------- +SUBNETS_PER_NODE: 2 \ No newline at end of file diff --git a/common/eth2_network_config/built_in_network_configs/prater/config.yaml b/common/eth2_network_config/built_in_network_configs/prater/config.yaml index 69d65ca8f..63b3d45db 100644 --- a/common/eth2_network_config/built_in_network_configs/prater/config.yaml +++ b/common/eth2_network_config/built_in_network_configs/prater/config.yaml @@ -86,3 +86,7 @@ DEPOSIT_CHAIN_ID: 5 DEPOSIT_NETWORK_ID: 5 # Prater test deposit contract on Goerli Testnet DEPOSIT_CONTRACT_ADDRESS: 0xff50ed3d0ec03aC01D4C79aAd74928BFF48a7b2b + +# Network +# --------------------------------------------------------------- +SUBNETS_PER_NODE: 2 \ No newline at end of file diff --git a/common/eth2_network_config/built_in_network_configs/sepolia/config.yaml b/common/eth2_network_config/built_in_network_configs/sepolia/config.yaml index 294657289..8489f085f 100644 --- a/common/eth2_network_config/built_in_network_configs/sepolia/config.yaml +++ b/common/eth2_network_config/built_in_network_configs/sepolia/config.yaml @@ -74,3 +74,7 @@ PROPOSER_SCORE_BOOST: 40 DEPOSIT_CHAIN_ID: 11155111 DEPOSIT_NETWORK_ID: 11155111 DEPOSIT_CONTRACT_ADDRESS: 0x7f02C3E3c98b133055B8B348B2Ac625669Ed295D + +# Network +# --------------------------------------------------------------- +SUBNETS_PER_NODE: 2 \ No newline at end of file diff --git a/consensus/types/src/chain_spec.rs b/consensus/types/src/chain_spec.rs index 2b25cc1d5..5253dcc4b 100644 --- a/consensus/types/src/chain_spec.rs +++ b/consensus/types/src/chain_spec.rs @@ -168,11 +168,9 @@ pub struct ChainSpec { pub maximum_gossip_clock_disparity_millis: u64, pub target_aggregators_per_committee: u64, pub attestation_subnet_count: u64, - pub random_subnets_per_validator: u64, - pub epochs_per_random_subnet_subscription: u64, pub subnets_per_node: u8, pub epochs_per_subnet_subscription: u64, - attestation_subnet_extra_bits: u8, + pub attestation_subnet_extra_bits: u8, /* * Application params @@ -455,17 +453,7 @@ impl ChainSpec { #[allow(clippy::integer_arithmetic)] pub const fn attestation_subnet_prefix_bits(&self) -> u32 { - // maybe use log2 when stable https://github.com/rust-lang/rust/issues/70887 - - // NOTE: this line is here simply to guarantee that if self.attestation_subnet_count type - // is changed, a compiler warning will be raised. This code depends on the type being u64. - let attestation_subnet_count: u64 = self.attestation_subnet_count; - let attestation_subnet_count_bits = if attestation_subnet_count == 0 { - 0 - } else { - 63 - attestation_subnet_count.leading_zeros() - }; - + let attestation_subnet_count_bits = self.attestation_subnet_count.ilog2(); self.attestation_subnet_extra_bits as u32 + attestation_subnet_count_bits } @@ -625,13 +613,11 @@ impl ChainSpec { network_id: 1, // mainnet network id attestation_propagation_slot_range: 32, attestation_subnet_count: 64, - random_subnets_per_validator: 1, - subnets_per_node: 1, + subnets_per_node: 2, maximum_gossip_clock_disparity_millis: 500, target_aggregators_per_committee: 16, - epochs_per_random_subnet_subscription: 256, epochs_per_subnet_subscription: 256, - attestation_subnet_extra_bits: 6, + attestation_subnet_extra_bits: 0, /* * Application specific @@ -852,13 +838,11 @@ impl ChainSpec { network_id: 100, // Gnosis Chain network id attestation_propagation_slot_range: 32, attestation_subnet_count: 64, - random_subnets_per_validator: 1, - subnets_per_node: 1, + subnets_per_node: 4, // Make this larger than usual to avoid network damage maximum_gossip_clock_disparity_millis: 500, target_aggregators_per_committee: 16, - epochs_per_random_subnet_subscription: 256, epochs_per_subnet_subscription: 256, - attestation_subnet_extra_bits: 6, + attestation_subnet_extra_bits: 0, /* * Application specific @@ -946,6 +930,9 @@ pub struct Config { shard_committee_period: u64, #[serde(with = "serde_utils::quoted_u64")] eth1_follow_distance: u64, + #[serde(default = "default_subnets_per_node")] + #[serde(with = "serde_utils::quoted_u8")] + subnets_per_node: u8, #[serde(with = "serde_utils::quoted_u64")] inactivity_score_bias: u64, @@ -1002,6 +989,10 @@ fn default_safe_slots_to_import_optimistically() -> u64 { 128u64 } +fn default_subnets_per_node() -> u8 { + 2u8 +} + impl Default for Config { fn default() -> Self { let chain_spec = MainnetEthSpec::default_spec(); @@ -1084,6 +1075,7 @@ impl Config { min_validator_withdrawability_delay: spec.min_validator_withdrawability_delay, shard_committee_period: spec.shard_committee_period, eth1_follow_distance: spec.eth1_follow_distance, + subnets_per_node: spec.subnets_per_node, inactivity_score_bias: spec.inactivity_score_bias, inactivity_score_recovery_rate: spec.inactivity_score_recovery_rate, @@ -1130,6 +1122,7 @@ impl Config { min_validator_withdrawability_delay, shard_committee_period, eth1_follow_distance, + subnets_per_node, inactivity_score_bias, inactivity_score_recovery_rate, ejection_balance, @@ -1162,6 +1155,7 @@ impl Config { min_validator_withdrawability_delay, shard_committee_period, eth1_follow_distance, + subnets_per_node, inactivity_score_bias, inactivity_score_recovery_rate, ejection_balance, diff --git a/consensus/types/src/config_and_preset.rs b/consensus/types/src/config_and_preset.rs index b10ad7557..01f86d348 100644 --- a/consensus/types/src/config_and_preset.rs +++ b/consensus/types/src/config_and_preset.rs @@ -86,10 +86,6 @@ pub fn get_extra_fields(spec: &ChainSpec) -> HashMap { "domain_application_mask".to_uppercase()=> u32_hex(spec.domain_application_mask), "target_aggregators_per_committee".to_uppercase() => spec.target_aggregators_per_committee.to_string().into(), - "random_subnets_per_validator".to_uppercase() => - spec.random_subnets_per_validator.to_string().into(), - "epochs_per_random_subnet_subscription".to_uppercase() => - spec.epochs_per_random_subnet_subscription.to_string().into(), "domain_contribution_and_proof".to_uppercase() => u32_hex(spec.domain_contribution_and_proof), "domain_sync_committee".to_uppercase() => u32_hex(spec.domain_sync_committee), diff --git a/consensus/types/src/subnet_id.rs b/consensus/types/src/subnet_id.rs index b885f89f7..6793fe557 100644 --- a/consensus/types/src/subnet_id.rs +++ b/consensus/types/src/subnet_id.rs @@ -80,15 +80,26 @@ impl SubnetId { epoch: Epoch, spec: &ChainSpec, ) -> Result<(impl Iterator, Epoch), &'static str> { + // Simplify the variable name + let subscription_duration = spec.epochs_per_subnet_subscription; + let node_id_prefix = (node_id >> (256 - spec.attestation_subnet_prefix_bits() as usize)).as_usize(); - let subscription_event_idx = epoch.as_u64() / spec.epochs_per_subnet_subscription; + // NOTE: The as_u64() panics if the number is larger than u64::max_value(). This cannot be + // true as spec.epochs_per_subnet_subscription is a u64. + let node_offset = (node_id % ethereum_types::U256::from(subscription_duration)).as_u64(); + + // Calculate at which epoch this node needs to re-evaluate + let valid_until_epoch = epoch.as_u64() + + subscription_duration + .saturating_sub((epoch.as_u64() + node_offset) % subscription_duration); + + let subscription_event_idx = (epoch.as_u64() + node_offset) / subscription_duration; let permutation_seed = ethereum_hashing::hash(&int_to_bytes::int_to_bytes8(subscription_event_idx)); let num_subnets = 1 << spec.attestation_subnet_prefix_bits(); - let permutated_prefix = compute_shuffled_index( node_id_prefix, num_subnets, @@ -107,7 +118,6 @@ impl SubnetId { let subnet_set_generator = (0..subnets_per_node).map(move |idx| { SubnetId::new((permutated_prefix + idx as u64) % attestation_subnet_count) }); - let valid_until_epoch = (subscription_event_idx + 1) * spec.epochs_per_subnet_subscription; Ok((subnet_set_generator, valid_until_epoch.into())) } } @@ -149,3 +159,80 @@ impl AsRef for SubnetId { subnet_id_to_string(self.0) } } + +#[cfg(test)] +mod tests { + use super::*; + + /// A set of tests compared to the python specification + #[test] + fn compute_subnets_for_epoch_unit_test() { + // Randomized variables used generated with the python specification + let node_ids = [ + "0", + "88752428858350697756262172400162263450541348766581994718383409852729519486397", + "18732750322395381632951253735273868184515463718109267674920115648614659369468", + "27726842142488109545414954493849224833670205008410190955613662332153332462900", + "39755236029158558527862903296867805548949739810920318269566095185775868999998", + "31899136003441886988955119620035330314647133604576220223892254902004850516297", + "58579998103852084482416614330746509727562027284701078483890722833654510444626", + "28248042035542126088870192155378394518950310811868093527036637864276176517397", + "60930578857433095740782970114409273483106482059893286066493409689627770333527", + "103822458477361691467064888613019442068586830412598673713899771287914656699997", + ] + .into_iter() + .map(|v| ethereum_types::U256::from_dec_str(v).unwrap()) + .collect::>(); + + let epochs = [ + 54321u64, 1017090249, 1827566880, 846255942, 766597383, 1204990115, 1616209495, + 1774367616, 1484598751, 3525502229, + ] + .into_iter() + .map(Epoch::from) + .collect::>(); + + // Test mainnet + let spec = ChainSpec::mainnet(); + + // Calculated by hand + let expected_valid_time: Vec = [ + 54528, 1017090371, 1827567108, 846256076, 766597570, 1204990135, 1616209582, + 1774367723, 1484598953, 3525502371, + ] + .into(); + + // Calculated from pyspec + let expected_subnets = vec![ + vec![4u64, 5u64], + vec![61, 62], + vec![23, 24], + vec![38, 39], + vec![53, 54], + vec![39, 40], + vec![48, 49], + vec![39, 40], + vec![34, 35], + vec![37, 38], + ]; + + for x in 0..node_ids.len() { + println!("Test: {}", x); + println!( + "NodeId: {}\n Epoch: {}\n, expected_update_time: {}\n, expected_subnets: {:?}", + node_ids[x], epochs[x], expected_valid_time[x], expected_subnets[x] + ); + + let (computed_subnets, valid_time) = SubnetId::compute_subnets_for_epoch::< + crate::MainnetEthSpec, + >(node_ids[x], epochs[x], &spec) + .unwrap(); + + assert_eq!(Epoch::from(expected_valid_time[x]), valid_time); + assert_eq!( + expected_subnets[x], + computed_subnets.map(SubnetId::into).collect::>() + ); + } + } +} From f5369329351d17658595f4fd50003b85ae056aa3 Mon Sep 17 00:00:00 2001 From: chonghe Date: Tue, 30 May 2023 06:15:57 +0000 Subject: [PATCH 10/18] Add SSH tunneling in Lighthouse UI Siren (#4328) ## Issue Addressed - ## Proposed Changes Add information to use SSH to connect to Siren beyond the local computer ## Additional Info Please provide any additional information. For example, future considerations or information useful for reviewers. Co-authored-by: chonghe <44791194+chong-he@users.noreply.github.com> Co-authored-by: Michael Sproul --- book/src/ui-configuration.md | 19 +++++++++++++++---- book/src/ui-faqs.md | 6 +++--- book/src/ui-usage.md | 2 +- 3 files changed, 19 insertions(+), 8 deletions(-) diff --git a/book/src/ui-configuration.md b/book/src/ui-configuration.md index 5b67b03b3..98f304139 100644 --- a/book/src/ui-configuration.md +++ b/book/src/ui-configuration.md @@ -12,9 +12,20 @@ following configuration screen. This allows you to enter the address and ports of the associated Lighthouse Beacon node and Lighthouse Validator client. -> The Beacon Node must be run with the `--gui` flag set. To allow the browser -> to access the node beyond your local computer you also need to allow CORS in -> the http API. This can be done via `--http-allow-origin "*"`. +> The Beacon Node must be run with the `--gui` flag set. + +If you run Siren in the browser (by entering `localhost` in the browser), you will need to allow CORS in the HTTP API. This can be done by adding the flag `--http-allow-origin "*"` for both beacon node and validator client. If you would like to access Siren beyond the local computer, we recommend using an SSH tunnel. This requires a tunnel for 3 ports: `80` (assuming the port is unchanged as per the [installation guide](./ui-installation.md#docker-recommended), `5052` (for beacon node) and `5062` (for validator client). You can use the command below to perform SSH tunneling: +```bash +ssh -N -L 80:127.0.0.1:80 -L 5052:127.0.0.1:5052 -L 5062:127.0.0.1:5062 username@local_ip +``` + +where `username` is the username of the server and `local_ip` is the local IP address of the server. Note that with the `-N` option in an SSH session, you will not be able to execute commands in the CLI to avoid confusion with ordinary shell sessions. The connection will appear to be "hung" upon a successful connection, but that is normal. Once you have successfully connected to the server via SSH tunneling, you should be able to access Siren by entering `localhost` in a web browser. + +You can also access Siren using the app downloaded in the [Siren release page](https://github.com/sigp/siren/releases). To access Siren beyond the local computer, you can use SSH tunneling for ports `5052` and `5062` using the command: + +```bash +ssh -N -L 5052:127.0.0.1:5052 -L 5062:127.0.0.1:5062 username@local_ip +``` A green tick will appear once Siren is able to connect to both clients. You can specify different ports for each client by clicking on the advanced tab. @@ -33,7 +44,7 @@ The token is located in the default data directory of the validator client. The default path is `~/.lighthouse//validators/api-token.txt`. -The contents of this file for the desired valdiator client needs to be +The contents of this file for the desired validator client needs to be entered. ## Name diff --git a/book/src/ui-faqs.md b/book/src/ui-faqs.md index 51aa9385a..d2e60d42d 100644 --- a/book/src/ui-faqs.md +++ b/book/src/ui-faqs.md @@ -4,13 +4,13 @@ Yes, Siren requires Lighthouse v3.5.1 or higher to function properly. These releases can be found on the [releases](https://github.com/sigp/lighthouse/releases) page of the Lighthouse repository. ## 2. Where can I find my API token? -The required Api token may be found in the default data directory of the validator client. For more information please refer to the lighthouse ui configuration [`api token section`](./ui-configuration.md#api-token). +The required Api token may be found in the default data directory of the validator client. For more information please refer to the lighthouse ui configuration [`api token section`](./api-vc-auth-header.md). ## 3. How do I fix the Node Network Errors? -If you recieve a red notification with a BEACON or VALIDATOR NODE NETWORK ERROR you can refer to the lighthouse ui configuration and [`connecting to clients section`](./ui-configuration.md#connecting-to-the-clients). +If you receive a red notification with a BEACON or VALIDATOR NODE NETWORK ERROR you can refer to the lighthouse ui configuration and [`connecting to clients section`](./ui-configuration.md#connecting-to-the-clients). ## 4. How do I change my Beacon or Validator address after logging in? -Once you have successfully arrived to the main dashboard, use the sidebar to access the settings view. In the top right hand corner there is a `Configurtion` action button that will redirect you back to the configuration screen where you can make appropriate changes. +Once you have successfully arrived to the main dashboard, use the sidebar to access the settings view. In the top right hand corner there is a `Configuration` action button that will redirect you back to the configuration screen where you can make appropriate changes. ## 5. Why doesn't my validator balance graph show any data? 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. diff --git a/book/src/ui-usage.md b/book/src/ui-usage.md index e88c4677a..010f5d491 100644 --- a/book/src/ui-usage.md +++ b/book/src/ui-usage.md @@ -10,7 +10,7 @@ Siren's dashboard view provides a summary of all performance and key validator m The account earnings component accumulates reward data from all registered validators providing a summation of total rewards earned while staking. Given current conversion rates, this component also converts your balance into your selected fiat currency. -Below in the earning section, you can also view your total earnings or click the adjacent buttons to view your estimated earnings given a specific timeframe based on current device and network conditions. +Below in the earning section, you can also view your total earnings or click the adjacent buttons to view your estimated earnings given a specific time frame based on current device and network conditions. ![](imgs/ui-account-earnings.png) From e6deaad91e83cce70b5b57a91428acc88d91df95 Mon Sep 17 00:00:00 2001 From: Jimmy Chen Date: Tue, 30 May 2023 06:15:58 +0000 Subject: [PATCH 11/18] Remove unused crate publishing Github action and script (#4347) ## Issue Addressed `publish-crate` action and its script no longer used after https://github.com/sigp/lighthouse/pull/3890. --- .github/workflows/publish-crate.yml | 66 ----------------- scripts/ci/publish.sh | 109 ---------------------------- 2 files changed, 175 deletions(-) delete mode 100644 .github/workflows/publish-crate.yml delete mode 100755 scripts/ci/publish.sh diff --git a/.github/workflows/publish-crate.yml b/.github/workflows/publish-crate.yml deleted file mode 100644 index 736057f78..000000000 --- a/.github/workflows/publish-crate.yml +++ /dev/null @@ -1,66 +0,0 @@ -name: Publish Crate - -on: - push: - tags: - - tree-hash-v* - - tree-hash-derive-v* - - eth2-ssz-v* - - eth2-ssz-derive-v* - - eth2-ssz-types-v* - - eth2-serde-util-v* - - eth2-hashing-v* - -env: - CARGO_API_TOKEN: ${{ secrets.CARGO_API_TOKEN }} - -jobs: - extract-tag: - runs-on: ubuntu-latest - steps: - - name: Extract tag - run: echo "TAG=$(echo ${GITHUB_REF#refs/tags/})" >> $GITHUB_OUTPUT - id: extract_tag - outputs: - TAG: ${{ steps.extract_tag.outputs.TAG }} - - publish-crate: - runs-on: ubuntu-latest - needs: [extract-tag] - env: - TAG: ${{ needs.extract-tag.outputs.TAG }} - steps: - - uses: actions/checkout@v3 - - name: Update Rust - run: rustup update stable - - name: Cargo login - run: | - echo "${CARGO_API_TOKEN}" | cargo login - - name: publish eth2 ssz derive - if: startsWith(env.TAG, 'eth2-ssz-derive-v') - run: | - ./scripts/ci/publish.sh consensus/ssz_derive eth2_ssz_derive "$TAG" - - name: publish eth2 ssz - if: startsWith(env.TAG, 'eth2-ssz-v') - run: | - ./scripts/ci/publish.sh consensus/ssz eth2_ssz "$TAG" - - name: publish eth2 hashing - if: startsWith(env.TAG, 'eth2-hashing-v') - run: | - ./scripts/ci/publish.sh crypto/eth2_hashing eth2_hashing "$TAG" - - name: publish tree hash derive - if: startsWith(env.TAG, 'tree-hash-derive-v') - run: | - ./scripts/ci/publish.sh consensus/tree_hash_derive tree_hash_derive "$TAG" - - name: publish tree hash - if: startsWith(env.TAG, 'tree-hash-v') - run: | - ./scripts/ci/publish.sh consensus/tree_hash tree_hash "$TAG" - - name: publish ssz types - if: startsWith(env.TAG, 'eth2-ssz-types-v') - run: | - ./scripts/ci/publish.sh consensus/ssz_types eth2_ssz_types "$TAG" - - name: publish serde util - if: startsWith(env.TAG, 'eth2-serde-util-v') - run: | - ./scripts/ci/publish.sh consensus/serde_utils eth2_serde_utils "$TAG" diff --git a/scripts/ci/publish.sh b/scripts/ci/publish.sh deleted file mode 100755 index f2cea95b7..000000000 --- a/scripts/ci/publish.sh +++ /dev/null @@ -1,109 +0,0 @@ -#!/usr/bin/env bash - -# Based on: https://github.com/tokio-rs/tokio/blob/master/bin/publish - -set -e -USAGE="Publish a new release of a lighthouse crate -USAGE: - $(basename "$0") [OPTIONS] [CRATE_PATH] [CRATE] [TAG_NAME] -OPTIONS: - -v, --verbose Use verbose Cargo output - -d, --dry-run Perform a dry run (do not publish the release) - -h, --help Show this help text and exit - --allow-dirty Allow dirty working directories to be packaged" - -DRY_RUN="" -DIRTY="" -VERBOSE="" - -verify() { - echo "Verifying if $CRATE v$VERSION can be released" - - # `cargo pkgid` has different formats based on whether the `[lib]` name and `[package]` name - # are the same, necessitating the following logic. - # - # Try to match on `#` - ACTUAL=$(cargo pkgid | sed -n 's/.*#\([0-9]\)/\1/p' ) - if [ -z "$ACTUAL" ]; then - # Match on the final `:` - ACTUAL=$(cargo pkgid | sed -n 's/.*:\(.*\)/\1/p') - fi - - if [ "$ACTUAL" != "$VERSION" ]; then - echo "expected to release version $VERSION, but Cargo.toml contained $ACTUAL" - exit 1 - fi -} - -release() { - echo "Releasing $CRATE v$VERSION" - cargo package $VERBOSE $DIRTY - cargo publish $VERBOSE $DRY_RUN $DIRTY -} - -while [[ $# -gt 0 ]] -do - -case "$1" in - -h|--help) - echo "$USAGE" - exit 0 - ;; - -v|--verbose) - VERBOSE="--verbose" - set +x - shift - ;; - --allow-dirty) - DIRTY="--allow-dirty" - shift - ;; - -d|--dry-run) - DRY_RUN="--dry-run" - shift - ;; - -*) - echo "unknown flag \"$1\"" - echo "$USAGE" - exit 1 - ;; - *) # crate, crate path, or version - if [ -z "$CRATE_PATH" ]; then - CRATE_PATH="$1" - elif [ -z "$CRATE" ]; then - CRATE="$1" - elif [ -z "$TAG_NAME" ]; then - TAG_NAME="$1" - VERSION=$(sed -e 's#.*-v\([0-9]\)#\1#' <<< "$TAG_NAME") - else - echo "unknown positional argument \"$1\"" - echo "$USAGE" - exit 1 - fi - shift - ;; -esac -done -# set -- "${POSITIONAL[@]}" - -if [ -z "$VERSION" ]; then - echo "no version specified!" - HELP=1 -fi - -if [ -z "$CRATE" ]; then - echo "no crate specified!" - HELP=1 -fi - -if [ -n "$HELP" ]; then - echo "$USAGE" - exit 1 -fi - -if [ -d "$CRATE_PATH" ]; then - (cd "$CRATE_PATH" && verify && release ) -else - echo "no such dir \"$CRATE_PATH\"" - exit 1 -fi From 7b1a0d4bba4d6ad8c85273745e273fd8cdf74cc6 Mon Sep 17 00:00:00 2001 From: Jimmy Chen Date: Wed, 31 May 2023 07:16:20 +0000 Subject: [PATCH 12/18] Fix `libpq` typo in beacon.watch README (#4356) ## Issue Addressed Fix README typo (`libpg` -> `libpq`). Co-authored-by: Jimmy Chen --- watch/README.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/watch/README.md b/watch/README.md index 18bf39394..34519e52e 100644 --- a/watch/README.md +++ b/watch/README.md @@ -12,7 +12,7 @@ data which is: ### Requirements - `git` - `rust` : https://rustup.rs/ -- `libpg` : https://www.postgresql.org/download/ +- `libpq` : https://www.postgresql.org/download/ - `diesel_cli` : ``` cargo install diesel_cli --no-default-features --features postgres From 749a242b0f983963068aff8c1fa5529f9f601dea Mon Sep 17 00:00:00 2001 From: chonghe Date: Fri, 2 Jun 2023 03:17:35 +0000 Subject: [PATCH 13/18] Addition to Lighthouse Book faq.md (#4273) ## Issue Addressed Added some frequently asked questions in the Lighthouse Book ## Proposed Changes Created another file faqV2.md which categorises the FAQs into different sections for better organisation. For review purpose, a review on faq.md will suffice. Then, if faqV2.md looks better, can delete faq.md; otherwise if the changes to the faqV2.md is too much, can keep faq.md and delete faqv2.md. ## Additional Info Please provide any additional information. For example, future considerations or information useful for reviewers. Co-authored-by: chonghe <44791194+chong-he@users.noreply.github.com> --- book/src/faq.md | 535 +++++++++++++++++++++++++++++++++++------------- 1 file changed, 394 insertions(+), 141 deletions(-) diff --git a/book/src/faq.md b/book/src/faq.md index b42e197a0..404ae2667 100644 --- a/book/src/faq.md +++ b/book/src/faq.md @@ -1,29 +1,184 @@ # Frequently Asked Questions -- [Why does it take so long for a validator to be activated?](#why-does-it-take-so-long-for-a-validator-to-be-activated) -- [Do I need to set up any port mappings?](#do-i-need-to-set-up-any-port-mappings) -- [I have a low peer count and it is not increasing](#i-have-a-low-peer-count-and-it-is-not-increasing) -- [What should I do if I lose my slashing protection database?](#what-should-i-do-if-i-lose-my-slashing-protection-database) -- [How do I update lighthouse?](#how-do-i-update-lighthouse) -- [I can't compile lighthouse](#i-cant-compile-lighthouse) -- [What is "Syncing deposit contract block cache"?](#what-is-syncing-deposit-contract-block-cache) -- [Can I use redundancy in my staking setup?](#can-i-use-redundancy-in-my-staking-setup) -- [How can I monitor my validators?](#how-can-i-monitor-my-validators) -- [I see beacon logs showing `WARN: Execution engine called failed`, what should I do?](#i-see-beacon-logs-showing-warn-execution-engine-called-failed-what-should-i-do) -- [How do I check or update my withdrawal credentials?](#how-do-i-check-or-update-my-withdrawal-credentials) -- [I am missing attestations. Why?](#i-am-missing-attestations-why) -- [Sometimes I miss the attestation head vote, resulting in penalty. Is this normal?](#sometimes-i-miss-the-attestation-head-vote-resulting-in-penalty-is-this-normal) -- [My beacon node is stuck at downloading historical block using checkpoing sync. What can I do?](#my-beacon-node-is-stuck-at-downloading-historical-block-using-checkpoing-sync-what-can-i-do) +## [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) +- [My beacon node is stuck at downloading historical block using checkpoint sync. What should I do?](#bn-download-historical) +- [I proposed a block but the beacon node shows `could not publish message` with error `duplicate` as below, should I be worried?](#bn-duplicate) +- [I see beacon node logs `Head is optimistic` and I am missing attestations. What should I do?](#bn-optimistic) +- [My beacon node logs `CRIT Beacon block processing error error: ValidatorPubkeyCacheLockTimeout`, what should I do?](#bn-timeout) +- [My beacon node logs `WARN BlockProcessingFailure outcome: MissingBeaconBlock`, what should I do?](#bn-missing-beacon) +- [After checkpoint sync, the progress of `downloading historical blocks` is slow. Why?](#bn-download-slow) +- [My beacon node logs `WARN Error processing HTTP API request`, what should I do?](#bn-http) -### Why does it take so long for a validator to be activated? +## [Validator](#validator-1) +- [Why does it take so long for a validator to be activated?](#vc-activation) +- [Can I use redundancy in my staking setup?](#vc-redundancy) +- [I am missing attestations. Why?](#vc-missed-attestations) +- [Sometimes I miss the attestation head vote, resulting in penalty. Is this normal?](#vc-head-vote) +- [Can I submit a voluntary exit message without a beacon node?](#vc-exit) +- [Does increasing the number of validators increase the CPU and other computer resources used?](#vc-resource) +- [I want to add new validators. Do I have to reimport the existing keys?](#vc-reimport) +- [Do I have to stop `lighthouse vc` the when importing new validator keys?](#vc-import) + + +## [Network, Monitoring and Maintenance](#network-monitoring-and-maintenance-1) +- [I have a low peer count and it is not increasing](#net-peer) +- [How do I update lighthouse?](#net-update) +- [Do I need to set up any port mappings (port forwarding)?](#net-port) +- [How can I monitor my validators?](#net-monitor) +- [My beacon node and validator client are on different servers. How can I point the validator client to the beacon node?](#net-bn-vc) +- [Should I do anything to the beacon node or validator client settings if I have a relocation of the node / change of IP address?](#net-ip) + + +## [Miscellaneous](#miscellaneous-1) +- [What should I do if I lose my slashing protection database?](#misc-slashing) +- [I can't compile lighthouse](#misc-compile) +- [How do I check the version of Lighthouse that is running?](#misc-version) +- [Does Lighthouse have pruning function like the execution client to save disk space?](#misc-prune) +- [Can I use a HDD for the freezer database and only have the hot db on SSD?](#misc-freezer) + +## Beacon Node + + + +### 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: + +``` +Nov 30 21:04:28.268 WARN Syncing deposit contract block cache est_blocks_remaining: initializing deposits, service: slot_notifier +``` + +or an error: + +``` +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. + +### 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: + +`error: Reqwest(reqwest::Error { kind: Request, url: Url { scheme: "http", cannot_be_a_base: false, username: "", password: None, host: Some(Ipv4(127.0.0.1)), port: Some(8551), path: "/", query: None, fragment: None }, source: TimedOut }), service: exec` + +which says `TimedOut` at the end of the message. This means that the execution engine has not responded in time to the beacon node. One option is to add the flag `--execution-timeout-multiplier 3` to the beacon node. However, if the error persists, it is worth digging further to find out the cause. There are a few reasons why this can occur: +1. The execution engine is not synced. Check the log of the execution engine to make sure that it is synced. If it is syncing, wait until it is synced and the error will disappear. You will see the beacon node logs `INFO Execution engine online` when it is synced. +1. The computer is overloaded. Check the CPU and RAM usage to see if it has overloaded. You can use `htop` to check for CPU and RAM usage. +1. Your SSD is slow. Check if your SSD is in "The Bad" list [here](https://gist.github.com/yorickdowne/f3a3e79a573bf35767cd002cc977b038). If your SSD is in "The Bad" list, it means it cannot keep in sync to the network and you may want to consider upgrading to a better SSD. + +If the reason for the error message is caused by no. 1 above, you may want to look further. If the execution engine is out of sync suddenly, it is usually caused by ungraceful shutdown. The common causes for ungraceful shutdown are: +- Power outage. If power outages are an issue at your place, consider getting a UPS to avoid ungraceful shutdown of services. +- The service file is not stopped properly. To overcome this, make sure that the process is stopped properly, e.g., during client updates. +- Out of memory (oom) error. This can happen when the system memory usage has reached its maximum and causes the execution engine to be killed. When this occurs, the log file will show `Main process exited, code=killed, status=9/KILL`. You can also run `sudo journalctl -a --since "18 hours ago" | grep -i "killed process` to confirm that the execution client has been killed due to oom. If you are using geth as the execution client, a short term solution is to reduce the resources used. For example, you can reduce the cache by adding the flag `--cache 2048`. If the oom occurs rather frequently, a long term solution is to increase the memory capacity of the computer. + +### My beacon node is stuck at downloading historical block using checkpoint sync. What should I do? + +After checkpoint forwards sync completes, the beacon node will start to download historical blocks. The log will look like: + +```bash +INFO Downloading historical blocks est_time: --, distance: 4524545 slots (89 weeks 5 days), service: slot_notifier +``` + +If the same log appears every minute and you do not see progress in downloading historical blocks, you can try one of the followings: + + - Check the number of peers you are connected to. If you have low peers (less than 50), try to do port forwarding on the port 9000 TCP/UDP to increase peer count. + - Restart the beacon node. + + +### I proposed a block but the beacon node shows `could not publish message` with error `duplicate` as below, should I be worried? + +``` +INFO Block from HTTP API already known` +WARN Could not publish message error: Duplicate, service: libp2p +``` + +This error usually happens when users are running mev-boost. The relay will publish the block on the network before returning it back to you. After the relay published the block on the network, it will propagate through nodes, and it happens quite often that your node will receive the block from your connected peers via gossip first, before getting the block from the relay, hence the message `duplicate`. + +In short, it is nothing to worry about. + +### I see beacon node logs `Head is optimistic`, and I am missing attestations. What should I do? + +The log looks like: + +``` +WARN Head is optimistic execution_block_hash: 0x47e7555f1d4215d1ad409b1ac188b008fcb286ed8f38d3a5e8078a0af6cbd6e1, info: chain not fully verified, block and attestation production disabled until execution engine syncs, service: slot_notifier +``` + +It means the beacon node will follow the chain, but it will not be able to attest or produce blocks. This is because the execution client is not synced, so the beacon chain cannot verify the authenticity of the chain head, hence the word `optimistic`. 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. + +### My beacon node logs `CRIT Beacon block processing error error: ValidatorPubkeyCacheLockTimeout, service: beacon`, what should I do? + +An example of the log is shown below: + +``` +CRIT Beacon block processing error error: ValidatorPubkeyCacheLockTimeout, service: beacon +WARN BlockProcessingFailure outcome: ValidatorPubkeyCacheLockTimeout, msg: unexpected condition in processing block. +``` + +A `Timeout` error suggests that the computer may be overloaded at the moment, for example, the execution client is still syncing. You may use the flag `--disable-lock-timeouts` to silence this error, although it will not fix the underlying slowness. Nevertheless, this is a relatively harmless log, and the error should go away once the resources used are back to normal. + +### My beacon node logs `WARN BlockProcessingFailure outcome: MissingBeaconBlock`, what should I do? + +An example of the full log is shown below: + +``` +WARN BlockProcessingFailure outcome: MissingBeaconBlock(0xbdba211f8d72029554e405d8e4906690dca807d1d7b1bc8c9b88d7970f1648bc), msg: unexpected condition in processing block. +``` + +`MissingBeaconBlock` suggests that the database has corrupted. You should wipe the database and use [Checkpoint Sync](./checkpoint-sync.md) to resync the beacon chain. + +### After checkpoint sync, the progress of `downloading historical blocks` is slow. Why? + +This is a normal behaviour. Since [v4.1.0](https://github.com/sigp/lighthouse/releases/tag/v4.1.0), Lighthouse implements rate-limited backfill sync to mitigate validator performance issues after a checkpoint sync. This is not something to worry about since backfill sync / historical data is not required for staking. However, if you opt to sync the chain as fast as possible, you can add the flag `--disable-backfill-rate-limiting` to the beacon node. + +### My beacon node logs `WARN Error processing HTTP API request`, what should I do? + +This warning usually comes with an http error code. Some examples are given below: + +1. The log shows: + +``` +WARN Error processing HTTP API request method: GET, path: /eth/v1/validator/attestation_data, status: 500 Internal Server Error, elapsed: 305.65µs +``` + +The error is `500 Internal Server Error`. This suggests that the execution client is not synced. Once the execution client is synced, the error will disappear. + +2. The log shows: + +``` +WARN Error processing HTTP API request method: POST, path: /eth/v1/validator/duties/attester/199565, status: 503 Service Unavailable, elapsed: 96.787µs +``` + +The error is `503 Service Unavailable`. This means that the beacon node is still syncing. When this happens, the validator client will log: + +``` +ERRO Failed to download attester duties err: FailedToDownloadAttesters("Some endpoints failed, num_failed: 2 http://localhost:5052/ => Unavailable(NotSynced), http://localhost:5052/ => RequestFailed(ServerMessage(ErrorMessage { code: 503, message: \"SERVICE_UNAVAILABLE: beacon node is syncing +``` + +This means that the validator client is sending requests to the beacon node. However, as the beacon node is still syncing, it is therefore unable to fulfil the request. The error will disappear once the beacon node is synced. + +## Validator + +### Why does it take so long for a validator to be activated? After validators create their execution layer deposit transaction there are two waiting periods before they can start producing blocks and attestations: 1. Waiting for the beacon chain to recognise the execution layer block containing the - deposit (generally 4 to 7.4 hours). -1. Waiting in the queue for validator activation (generally 6.4 minutes for - every 4 validators in the queue). + deposit (generally takes ~13.6 hours). +1. Waiting in the queue for validator activation. Detailed answers below: @@ -32,33 +187,33 @@ Detailed answers below: Since the beacon chain uses the execution layer for validator on-boarding, beacon chain validators must listen to event logs from the deposit contract. Since the latest blocks of the execution chain are vulnerable to re-orgs due to minor network -partitions, beacon nodes follow the execution chain at a distance of 1,024 blocks -(~4 hours) (see -[`ETH1_FOLLOW_DISTANCE`](https://github.com/ethereum/consensus-specs/blob/v0.12.1/specs/phase0/validator.md#misc)). +partitions, beacon nodes follow the execution chain at a distance of 2048 blocks +(~6.8 hours) (see +[`ETH1_FOLLOW_DISTANCE`](https://github.com/ethereum/consensus-specs/blob/v1.3.0/specs/phase0/validator.md#process-deposit)). This follow distance protects the beacon chain from on-boarding validators that are likely to be removed due to an execution chain re-org. -Now we know there's a 4 hours delay before the beacon nodes even _consider_ an +Now we know there's a 6.8 hours delay before the beacon nodes even _consider_ an execution layer block. Once they _are_ considering these blocks, there's a voting period where beacon validators vote on which execution block hash to include in the beacon chain. This -period is defined as 32 epochs (~3.4 hours, see -[`ETH1_VOTING_PERIOD`](https://github.com/ethereum/consensus-specs/blob/v0.12.1/specs/phase0/beacon-chain.md#time-parameters)). +period is defined as 64 epochs (~6.8 hours, see +[`ETH1_VOTING_PERIOD`](https://github.com/ethereum/consensus-specs/blob/v1.3.0/specs/phase0/beacon-chain.md#time-parameters)). During this voting period, each beacon block producer includes an -[`Eth1Data`](https://github.com/ethereum/consensus-specs/blob/v0.12.1/specs/phase0/beacon-chain.md#eth1data) +[`Eth1Data`](https://github.com/ethereum/consensus-specs/blob/v1.3.0/specs/phase0/beacon-chain.md#eth1data) in their block which counts as a vote towards what that validator considers to be the head of the execution chain at the start of the voting period (with respect to `ETH1_FOLLOW_DISTANCE`, of course). You can see the exact voting logic -[here](https://github.com/ethereum/consensus-specs/blob/v0.12.1/specs/phase0/validator.md#eth1-data). +[here](https://github.com/ethereum/consensus-specs/blob/v1.3.0/specs/phase0/validator.md#eth1-data). These two delays combined represent the time between an execution layer deposit being included in an execution data vote and that validator appearing in the beacon chain. -The `ETH1_FOLLOW_DISTANCE` delay causes a minimum delay of ~4 hours and +The `ETH1_FOLLOW_DISTANCE` delay causes a minimum delay of ~6.8 hours and `ETH1_VOTING_PERIOD` means that if a validator deposit happens just _before_ the start of a new voting period then they might not notice this delay at all. However, if the validator deposit happens just _after_ the start of the new -voting period the validator might have to wait ~3.4 hours for next voting -period. In times of very, very severe network issues, the network may even fail -to vote in new execution layer blocks, stopping all new validator deposits! +voting period the validator might have to wait ~6.8 hours for next voting +period. In times of very severe network issues, the network may even fail +to vote in new execution layer blocks, thus stopping all new validator deposits and causing the wait to be longer. #### 2. Waiting for a validator to be activated @@ -68,30 +223,144 @@ They will simply be forgotten by the beacon chain! But, if those parameters were correct, once the execution layer delays have elapsed and the validator appears in the beacon chain, there's _another_ delay before the validator becomes "active" (canonical definition -[here](https://github.com/ethereum/consensus-specs/blob/v0.12.1/specs/phase0/beacon-chain.md#is_active_validator)) and can start producing blocks and attestations. +[here](https://github.com/ethereum/consensus-specs/blob/v1.3.0/specs/phase0/beacon-chain.md#is_active_validator)) and can start producing blocks and attestations. Firstly, the validator won't become active until their beacon chain balance is equal to or greater than -[`MAX_EFFECTIVE_BALANCE`](https://github.com/ethereum/consensus-specs/blob/v0.12.1/specs/phase0/beacon-chain.md#gwei-values) +[`MAX_EFFECTIVE_BALANCE`](https://github.com/ethereum/consensus-specs/blob/v1.3.0/specs/phase0/beacon-chain.md#gwei-values) (32 ETH on mainnet, usually 3.2 ETH on testnets). Once this balance is reached, the validator must wait until the start of the next epoch (up to 6.4 minutes) for the -[`process_registry_updates`](https://github.com/ethereum/consensus-specs/blob/v0.12.1/specs/phase0/beacon-chain.md#registry-updates) +[`process_registry_updates`](https://github.com/ethereum/consensus-specs/blob/v1.3.0/specs/phase0/beacon-chain.md#registry-updates) routine to run. This routine activates validators with respect to a [churn -limit](https://github.com/ethereum/consensus-specs/blob/v0.12.1/specs/phase0/beacon-chain.md#get_validator_churn_limit); +limit](https://github.com/ethereum/consensus-specs/blob/v1.3.0/specs/phase0/beacon-chain.md#get_validator_churn_limit); it will only allow the number of validators to increase (churn) by a certain -amount. Up until there are about 330,000 validators this churn limit is set to -4 and it starts to very slowly increase as the number of validators increases -from there. - -If a new validator isn't within the churn limit from the front of the queue, +amount. If a new validator isn't within the churn limit from the front of the queue, they will need to wait another epoch (6.4 minutes) for their next chance. This -repeats until the queue is cleared. +repeats until the queue is cleared. The churn limit is summarised in the table below: -Once a validator has been activated, there's no more waiting! It's time to +
+ +| Number of active validators | Validators activated per epoch | Validators activated per day | +|-------------------|--------------------------------------------|----| +| 327679 or less | 4 | 900 | +| 327680-393215 | 5 | 1125 | +| 393216-458751 | 6 | 1350 +| 458752-524287 | 7 | 1575 +| 524288-589823 | 8| 1800 | +| 589824-655359 | 9| 2025 | +| 655360-720895 | 10 | 2250| +| 720896-786431 | 11 | 2475 | +| 786432-851967 | 12 | 2700 | +| 851968-917503 | 13 | 2925 | +| 917504-983039 | 14 | 3150 | +| 983040-1048575 | 15 | 3375 | + +
+ +For example, the number of active validators on Mainnet is about 574000 on May 2023. This means that 8 validators can be activated per epoch or 1800 per day (it is noted that the same applies to the exit queue). If, for example, there are 9000 validators waiting to be activated, this means that the waiting time can take up to 5 days. + +Once a validator has been activated, congratulations! It's time to produce blocks and attestations! -### Do I need to set up any port mappings? +### Can I use redundancy in my staking setup? + +You should **never** use duplicate/redundant validator keypairs or validator clients (i.e., don't +duplicate your JSON keystores and don't run `lighthouse vc` twice). This will lead to slashing. + +However, there are some components which can be configured with redundancy. See the +[Redundancy](./redundancy.md) guide for more information. + +### I am missing attestations. Why? +The first thing is to ensure both consensus and execution clients are synced with the network. If they are synced, there may still be some issues with the node setup itself that is causing the missed attestations. Check the setup to ensure that: +- the clock is synced +- the computer has sufficient resources and is not overloaded +- the internet is working well +- you have sufficient peers + +You can see more information on the [Ethstaker KB](https://ethstaker.gitbook.io/ethstaker-knowledge-base/help/missed-attestations). Once the above points are good, missing attestation should be a rare occurrence. + +### Sometimes I miss the attestation head vote, resulting in penalty. Is this normal? + +In general, it is unavoidable to have some penalties occasionally. This is particularly the case when you are assigned to attest on the first slot of an epoch and if the proposer of that slot releases the block late, then you will get penalised for missing the target and head votes. Your attestation performance does not only depend on your own setup, but also on everyone elses performance. + +### Can I submit a voluntary exit message without running a beacon node? + +Yes. Beaconcha.in provides the tool to broadcast the message. You can create the voluntary exit message file with [ethdo](https://github.com/wealdtech/ethdo/releases/tag/v1.30.0) and submit the message via the [beaconcha.in](https://beaconcha.in/tools/broadcast) website. A guide on how to use `ethdo` to perform voluntary exit can be found [here](https://github.com/eth-educators/ethstaker-guides/blob/main/voluntary-exit.md). + +It is also noted that you can submit your BLS-to-execution-change message to update your withdrawal credentials from type `0x00` to `0x01` using the same link. + +If you would like to still use Lighthouse to submit the message, you will need to run a beacon node and an execution client. For the beacon node, you can use checkpoint sync to quickly sync the chain under a minute. On the other hand, the execution client can be syncing and *needs not be synced*. This implies that it is possible to broadcast a voluntary exit message within a short time by quickly spinning up a node. + +### Does increasing the number of validators increase the CPU and other computer resources used? + +A computer with hardware specifications stated in the [Recommended System Requirements](./installation.md#recommended-system-requirements) can run hundreds validators with only marginal increase in cpu usage. When validators are active, there is a bit of an increase in resources used from validators 0-64, because you end up subscribed to more subnets. After that, the increase in resources plateaus when the number of validators go from 64 to ~500. + +### I want to add new validators. Do I have to reimport the existing keys? + +No. You can just import new validator keys to the destination directory. If the `validator_keys` folder contains existing keys, that's fine as well because Lighthouse will skip importing existing keys. + +### Do I have to stop `lighthouse vc` when importing new validator keys? + +Generally yes. + +If you do not want to stop `lighthouse vc`, you can use the [key manager API](./api-vc-endpoints.md) to import keys. + +## Network, Monitoring and Maintenance + +### I have a low peer count and it is not increasing + +If you cannot find *ANY* peers at all, it is likely that you have incorrect +network configuration settings. Ensure that the network you wish to connect to +is correct (the beacon node outputs the network it is connecting to in the +initial boot-up log lines). On top of this, ensure that you are not using the +same `datadir` as a previous network, i.e., if you have been running the +`Goerli` testnet and are now trying to join a new network but using the same +`datadir` (the `datadir` is also printed out in the beacon node's logs on +boot-up). + +If you find yourself with a low peer count and it's not reaching the target you +expect, there are a few things to check on: + +1. Ensure that port forward was correctly set up as described [here](./advanced_networking.md#nat-traversal-port-forwarding). + +To check that the ports are forwarded, run the command: + + ```bash + curl http://localhost:5052/lighthouse/nat + ``` + +It should return `{"data":true}`. If it returns `{"data":false}`, you may want to double check if the port forward was correctly set up. + +If the ports are open, you should have incoming peers. To check that you have incoming peers, run the command: + + ```bash + curl localhost:5052/lighthouse/peers | jq '.[] | select(.peer_info.connection_direction=="Incoming")' + ``` + +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. + +2. Check that you do not lower the number of peers using the flag `--target-peers`. The default is 80. 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. + +3. 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. + + +### How do I update lighthouse? + +If you are updating to new release binaries, it will be the same process as described [here.](./installation-binaries.md) + +If you are updating by rebuilding from source, see [here.](./installation-source.md#update-lighthouse) + +If you are running the docker image provided by Sigma Prime on Dockerhub, you can update to specific versions, for example: + +```bash +$ docker pull sigp/lighthouse:v1.0.0 +``` + +If you are building a docker image, the process will be similar to the one described [here.](./docker.md#building-the-docker-image) +You just need to make sure the code you have checked out is up to date. + +### Do I need to set up any port mappings (port forwarding)? It is not strictly required to open any ports for Lighthouse to connect and participate in the network. Lighthouse should work out-of-the-box. However, if @@ -116,121 +385,105 @@ peers to join and degrades the overall connectivity of the global network. For these reasons, we recommend that you make your node publicly accessible. Lighthouse supports UPnP. If you are behind a NAT with a router that supports -UPnP you can simply ensure UPnP is enabled (Lighthouse will inform you in its -initial logs if a route has been established). You can also manually set up -port mappings in your router to your local Lighthouse instance. By default, +UPnP, you can simply ensure UPnP is enabled (Lighthouse will inform you in its +initial logs if a route has been established). You can also manually [set up port mappings](./advanced_networking.md) in your router to your local Lighthouse instance. By default, Lighthouse uses port 9000 for both TCP and UDP. Opening both these ports will make your Lighthouse node maximally contactable. -### I have a low peer count and it is not increasing - -If you cannot find *ANY* peers at all. It is likely that you have incorrect -testnet configuration settings. Ensure that the network you wish to connect to -is correct (the beacon node outputs the network it is connecting to in the -initial boot-up log lines). On top of this, ensure that you are not using the -same `datadir` as a previous network. I.e if you have been running the -`prater` testnet and are now trying to join a new testnet but using the same -`datadir` (the `datadir` is also printed out in the beacon node's logs on -boot-up). - -If you find yourself with a low peer count and it's not reaching the target you -expect. Try setting up the correct port forwards as described -[here](./advanced_networking.md#nat-traversal-port-forwarding). - -### What should I do if I lose my slashing protection database? - -See [here](./slashing-protection.md#misplaced-slashing-database). - -### How do I update lighthouse? - -If you are updating to new release binaries, it will be the same process as described [here.](./installation-binaries.md) - -If you are updating by rebuilding from source, see [here.](./installation-source.md#update-lighthouse) - -If you are running the docker image provided by Sigma Prime on Dockerhub, you can update to specific versions, for example: - -```bash -$ docker pull sigp/lighthouse:v1.0.0 -``` - -If you are building a docker image, the process will be similar to the one described [here.](./docker.md#building-the-docker-image) -You will just also need to make sure the code you have checked out is up to date. - -### I can't compile lighthouse - -See [here.](./installation-source.md#troubleshooting) - -### What is "Syncing deposit contract block cache"? - -``` -Nov 30 21:04:28.268 WARN Syncing deposit contract block cache est_blocks_remaining: initializing deposits, service: slot_notifier -``` - -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 sporadically during operation, there may be an -issue with your execution client endpoint. - -### Can I use redundancy in my staking setup? - -You should **never** use duplicate/redundant validator keypairs or validator clients (i.e., don't -duplicate your JSON keystores and don't run `lighthouse vc` twice). This will lead to slashing. - -However, there are some components which can be configured with redundancy. See the -[Redundancy](./redundancy.md) guide for more information. - -### How can I monitor my validators? +### How can I monitor my validators? Apart from using block explorers, you may use the "Validator Monitor" built into Lighthouse which provides logging and Prometheus/Grafana metrics for individual validators. See [Validator Monitoring](./validator-monitoring.md) for more information. Lighthouse has also developed Lighthouse UI (Siren) to monitor performance, see [Lighthouse UI (Siren)](./lighthouse-ui.md). -### I see beacon logs showing `WARN: Execution engine called failed`, what should I do? +### My beacon node and validator client are on different servers. How can I point the validator client to the beacon node? + +The settings are as follows: + +1. On the beacon node: + + Specify `lighthouse bn --http-address local_IP` so that the beacon node is listening on the local network rather than on the `localhost`. + +1. On the validator client: + + Use the flag `--beacon-nodes` to point to the beacon node. For example, `lighthouse vc --beacon-nodes http://local_IP:5052` where `local_IP` is the local IP address of the beacon node and `5052` is the default `http-port` of the beacon node. + + You can test that the setup is working with by running the following command on the validator client host: + + ```bash + curl "http://local_IP:5052/eth/v1/node/version" + ``` + + You can refer to [Redundancy](./redundancy.md) for more information. + + It is also worth noting that the `--beacon-nodes` flag can also be used for redundancy of beacon nodes. For example, let's say you have a beacon node and a validator client running on the same host, and a second beacon node on another server as a backup. In this case, you can use `lighthouse vc --beacon-nodes http://localhost:5052, http://local_IP:5052` on the validator client. + +### Should I do anything to the beacon node or validator client settings if I have a relocation of the node / change of IP address? +No. Lighthouse will auto-detect the change and update your Ethereum Node Record (ENR). You just need to make sure you are not manually setting the ENR with `--enr-address` (which, for common use cases, this flag is not used). + +## Miscellaneous + +### What should I do if I lose my slashing protection database? + +See [here](./slashing-protection.md#misplaced-slashing-database). + +### I can't compile lighthouse + +See [here.](./installation-source.md#troubleshooting) + +### How do I check the version of Lighthouse that is running? + +If you build Lighthouse from source, run `lighthouse --version`. Example of output: + +```bash +Lighthouse v4.1.0-693886b +BLS library: blst-modern +SHA256 hardware acceleration: false +Allocator: jemalloc +Specs: mainnet (true), minimal (false), gnosis (true) +``` + +If you download the binary file, navigate to the location of the directory, for example, the binary file is in `/usr/local/bin`, run `/usr/local/bin/lighthouse --version`, the example of output is the same as above. + +Alternatively, if you have Lighthouse running, on the same computer, you can run: +```bash +curl "http://127.0.0.1:5052/eth/v1/node/version" +``` + +Example of output: +```bash +{"data":{"version":"Lighthouse/v4.1.0-693886b/x86_64-linux"}} +``` +which says that the version is v4.1.0. + +### Does Lighthouse have pruning function like the execution client to save disk space? + +There is no pruning of Lighthouse database for now. However, since v4.2.0, a feature to only sync back to the weak subjectivity point (approximately 5 months) when syncing via a checkpoint sync was added. This will help to save disk space since the previous behaviour will sync back to the genesis by default. + +### Can I use a HDD for the freezer database and only have the hot db on SSD? + +Yes, you can do so by using the flag `--freezer-dir /path/to/freezer_db` in the beacon node. + + + + + + + + + + + + + -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: -`error: Reqwest(reqwest::Error { kind: Request, url: Url { scheme: "http", cannot_be_a_base: false, username: "", password: None, host: Some(Ipv4(127.0.0.1)), port: Some(8551), path: "/", query: None, fragment: None }, source: TimedOut }), service: exec` -which says `TimedOut` at the end of the message. This means that the execution engine has not responded in time to the beacon node. There are a few reasons why this can occur: -1. The execution engine is not synced. Check the log of the execution engine to make sure that it is synced. If it is syncing, wait until it is synced and the error will disappear. You will see the beacon node logs `INFO Execution engine online` when it is synced. -1. The computer is overloaded. Check the CPU and RAM usage to see if it has overloaded. You can use `htop` to check for CPU and RAM usage. -1. Your SSD is slow. Check if your SSD is in "The Bad" list [here](https://gist.github.com/yorickdowne/f3a3e79a573bf35767cd002cc977b038). If your SSD is in "The Bad" list, it means it cannot keep in sync to the network and you may want to consider upgrading to a better SSD. -If the reason for the error message is caused by no. 1 above, you may want to look further. If the execution engine is out of sync suddenly, it is usually caused by ungraceful shutdown. The common causes for ungraceful shutdown are: -- Power outage. If power outages are an issue at your place, consider getting a UPS to avoid ungraceful shutdown of services. -- The service file is not stopped properly. To overcome this, make sure that the process is stop properly, e.g., during client updates. -- Out of memory (oom) error. This can happen when the system memory usage has reached its maximum and causes the execution engine to be killed. When this occurs, the log file will show `Main process exited, code=killed, status=9/KILL`. You can also run `sudo journalctl -a --since "18 hours ago" | grep -i "killed process` to confirm that the execution client has been killed due to oom. If you are using geth as the execution client, a short term solution is to reduce the resources used, for example: (1) reduce the cache by adding the flag `--cache 2048` (2) connect to less peers using the flag `--maxpeers 10`. If the oom occurs rather frequently, a long term solution is to increase the memory capacity of the computer. -### How do I check or update my withdrawal credentials? -Withdrawals will be available after the Capella/Shanghai upgrades on 12th April 2023. To check that if you are eligible for withdrawals, go to [Staking launchpad](https://launchpad.ethereum.org/en/withdrawals), enter your validator index and click `verify on mainnet`: -- `withdrawals enabled` means you will automatically receive withdrawals to the withdrawal address that you set. -- `withdrawals not enabled` means you will need to update your withdrawal credentials from `0x00` type to `0x01` type. The common way to do this is using `Staking deposit CLI` or `ethdo`, with the instructions available [here](https://launchpad.ethereum.org/en/withdrawals#update-your-keys). - -For the case of `withdrawals not enabled`, you can update your withdrawal credentials **anytime**, and there is no deadline for that. The catch is that as long as you do not update your withdrawal credentials, your rewards in the beacon chain will continue to be locked in the beacon chain. Only after you update the withdrawal credentials, will the rewards be withdrawn to the withdrawal address. -### I am missing attestations. Why? -The first thing is to ensure both consensus and execution clients are synced with the network. If they are synced, there may still be some issues with the node setup itself that is causing the missed attestations. Check the setup to ensure that: -- the clock is synced -- the computer has sufficient resources and is not overloaded -- the internet is working well -- you have sufficient peers - -You can see more information on the [Ethstaker KB](https://ethstaker.gitbook.io/ethstaker-knowledge-base/help/missed-attestations). Once the above points are good, missing attestation should be a rare occurance. - -### Sometimes I miss the attestation head vote, resulting in penalty. Is this normal? - -In general it is unavoiadable to have some penalties occasionally. This is particularly the case when you are assigned to attest on the first slot of an epoch and if the proposer of that slot releases the block late, then you will get penalised for missing the target and head votes. Your attestation performance does not only depend on your own setup, but also on everyone else's performance. -### My beacon node is stuck at downloading historical block using checkpoing sync. What can I do? -Check the number of peers you are connected to. If you have low peers (less than 50), try to do port forwarding on the port 9000 TCP/UDP to increase peer count. \ No newline at end of file From 6c769ed86c4512e72f27ac60a62c0805e2c2dab4 Mon Sep 17 00:00:00 2001 From: chonghe Date: Fri, 2 Jun 2023 03:17:36 +0000 Subject: [PATCH 14/18] Update Lighthouse Book API and Advanced Usage section (#4300) ## Issue Addressed Update Information in Lighthouse Book ## Proposed Changes - move Validator Graffiti from Advanced Usage to Validator Management - update API response and command - some items that aren't too sure I put it in comment, which can be seen in raw/review format but not live ## Additional Info Please provide any additional information. For example, future considerations or information useful for reviewers. Co-authored-by: chonghe <44791194+chong-he@users.noreply.github.com> --- book/src/SUMMARY.md | 9 +- book/src/advanced-pre-releases.md | 4 - book/src/advanced-release-candidates.md | 7 +- book/src/advanced.md | 16 +- book/src/advanced_database.md | 26 +- book/src/advanced_networking.md | 26 +- book/src/api-bn.md | 56 ++-- book/src/api-lighthouse.md | 290 +++++++++++------ book/src/api-vc-endpoints.md | 400 ++++++++++++++++++------ book/src/api-vc.md | 6 +- book/src/builders.md | 37 ++- book/src/checkpoint-sync.md | 6 +- book/src/database-migrations.md | 25 +- book/src/key-management.md | 2 +- book/src/merge-migration.md | 35 ++- book/src/redundancy.md | 12 +- book/src/slasher.md | 9 +- book/src/suggested-fee-recipient.md | 10 + book/src/validator-inclusion.md | 4 +- book/src/validator-web3signer.md | 4 +- 20 files changed, 706 insertions(+), 278 deletions(-) delete mode 100644 book/src/advanced-pre-releases.md diff --git a/book/src/SUMMARY.md b/book/src/SUMMARY.md index bfd5a02a6..8fc2c2f83 100644 --- a/book/src/SUMMARY.md +++ b/book/src/SUMMARY.md @@ -18,10 +18,11 @@ * [Validator Monitoring](./validator-monitoring.md) * [Doppelganger Protection](./validator-doppelganger.md) * [Suggested Fee Recipient](./suggested-fee-recipient.md) + * [Validator Graffiti](./graffiti.md) * [APIs](./api.md) * [Beacon Node API](./api-bn.md) - * [/lighthouse](./api-lighthouse.md) - * [Validator Inclusion APIs](./validator-inclusion.md) + * [Lighthouse API](./api-lighthouse.md) + * [Validator Inclusion APIs](./validator-inclusion.md) * [Validator Client API](./api-vc.md) * [Endpoints](./api-vc-endpoints.md) * [Authorization Header](./api-vc-auth-header.md) @@ -36,7 +37,6 @@ * [Advanced Usage](./advanced.md) * [Checkpoint Sync](./checkpoint-sync.md) * [Custom Data Directories](./advanced-datadir.md) - * [Validator Graffiti](./graffiti.md) * [Proposer Only Beacon Nodes](./advanced-proposer-only.md) * [Remote Signing with Web3Signer](./validator-web3signer.md) * [Database Configuration](./advanced_database.md) @@ -46,9 +46,8 @@ * [Advanced Networking](./advanced_networking.md) * [Running a Slasher](./slasher.md) * [Redundancy](./redundancy.md) - * [Pre-Releases](./advanced-pre-releases.md) * [Release Candidates](./advanced-release-candidates.md) - * [MEV and Lighthouse](./builders.md) + * [Maximal Extractable Value (MEV)](./builders.md) * [Merge Migration](./merge-migration.md) * [Late Block Re-orgs](./late-block-re-orgs.md) * [Contributing](./contributing.md) diff --git a/book/src/advanced-pre-releases.md b/book/src/advanced-pre-releases.md deleted file mode 100644 index f3f4a5230..000000000 --- a/book/src/advanced-pre-releases.md +++ /dev/null @@ -1,4 +0,0 @@ -# Pre-Releases - -Pre-releases are now referred to as [Release Candidates](./advanced-release-candidates.md). The terms may -be used interchangeably. diff --git a/book/src/advanced-release-candidates.md b/book/src/advanced-release-candidates.md index 842bc4840..b2ff02136 100644 --- a/book/src/advanced-release-candidates.md +++ b/book/src/advanced-release-candidates.md @@ -7,7 +7,7 @@ [`v1.4.0`]: https://github.com/sigp/lighthouse/releases/tag/v1.4.0 From time-to-time, Lighthouse *release candidates* will be published on the [sigp/lighthouse] -repository. These releases have passed the usual automated testing, however the developers would +repository. Release candidates are previously known as Pre-Releases. These releases have passed the usual automated testing, however the developers would like to see it running "in the wild" in a variety of configurations before declaring it an official, stable release. Release candidates are also used by developers to get feedback from users regarding the ergonomics of new features or changes. @@ -36,8 +36,9 @@ Users may wish to try a release candidate for the following reasons: - To help detect bugs and regressions before they reach production. - To provide feedback on annoyances before they make it into a release and become harder to change or revert. +There can also be a scenario that a bug has been found and requires an urgent fix. An example of incidence is [v4.0.2-rc.0](https://github.com/sigp/lighthouse/releases/tag/v4.0.2-rc.0) which contains a hot-fix to address high CPU usage experienced after the [Capella](https://ethereum.org/en/history/#capella) upgrade on 12th April 2023. In this scenario, we will announce the release candidate on [Github](https://github.com/sigp/lighthouse/releases) and also on [Discord](https://discord.gg/cyAszAh) to recommend users to update to the release candidate version. + ## When *not* to use a release candidate -It is not recommended to use release candidates for any critical tasks on mainnet (e.g., staking). -To test critical features, try one of the testnets (e.g., Prater). +Other than the above scenarios, it is generally not recommended to use release candidates for any critical tasks on mainnet (e.g., staking). To test new release candidate features, try one of the testnets (e.g., Goerli). diff --git a/book/src/advanced.md b/book/src/advanced.md index d46cae699..51416a3b7 100644 --- a/book/src/advanced.md +++ b/book/src/advanced.md @@ -6,4 +6,18 @@ elsewhere? This section provides detailed information about configuring Lighthouse for specific use cases, and tips about how things work under the hood. -* [Advanced Database Configuration](./advanced_database.md): understanding space-time trade-offs in the database. +* [Checkpoint Sync](./checkpoint-sync.md): quickly sync the beacon chain to perform validator duties. +* [Custom Data Directories](./advanced-datadir.md): modify the data directory to your preferred location. +* [Proposer Only Beacon Nodes](./advanced-proposer-only.md): beacon node only for proposer duty for increased anonymity. +* [Remote Signing with Web3Signer](./validator-web3signer.md): don't want to store your keystore in local node? Use web3signer. +* [Database Configuration](./advanced_database.md): understanding space-time trade-offs in the database. +* [Database Migrations](./database-migrations.md): have a look at all previous Lighthouse database scheme versions. +* [Key Management](./key-management.md): explore how to generate wallet with Lighthouse. +* [Key Recovery](./key-recovery.md): explore how to recover wallet and validator with Lighthouse. +* [Advanced Networking](./advanced_networking.md): open your ports to have a diverse and healthy set of peers. +* [Running a Slasher](./slasher.md): contribute to the health of the network by running a slasher. +* [Redundancy](./redundancy.md): want to have more than one beacon node as backup? This is for you. +* [Release Candidates](./advanced-release-candidates.md): latest release of Lighthouse to get feedback from users. +* [Maximal Extractable Value](./builders.md): use external builders for a potential higher rewards during block proposals +* [Merge Migration](./merge-migration.md): look at what you need to do during a significant network upgrade: The Merge +* [Late Block Re-orgs](./late-block-re-orgs.md): read information about Lighthouse late block re-orgs. diff --git a/book/src/advanced_database.md b/book/src/advanced_database.md index 57e49531c..f9996ec65 100644 --- a/book/src/advanced_database.md +++ b/book/src/advanced_database.md @@ -23,13 +23,17 @@ states to slow down dramatically. A lower _slots per restore point_ value (SPRP) frequent restore points, while a higher SPRP corresponds to less frequent. The table below shows some example values. -| Use Case | SPRP | Yearly Disk Usage | Load Historical State | -|--------------------------|------|-------------------|-----------------------| -| Block explorer/analysis | 32 | 1.4 TB | 155 ms | -| Hobbyist (prev. default) | 2048 | 23.1 GB | 10.2 s | -| Validator only (default) | 8192 | 5.7 GB | 41 s | +| Use Case | SPRP | Yearly Disk Usage* | Load Historical State | +|----------------------------|------|-------------------|-----------------------| +| Research | 32 | 3.4 TB | 155 ms | +| Block explorer/analysis | 128 | 851 GB | 620 ms | +| Enthusiast (prev. default) | 2048 | 53.6 GB | 10.2 s | +| EHobbyist | 4096 | 26.8 GB | 20.5 s | +| Validator only (default) | 8192 | 8.1 GB | 41 s | -As you can see, it's a high-stakes trade-off! The relationships to disk usage and historical state +*Last update: May 2023. + +As we can see, it's a high-stakes trade-off! The relationships to disk usage and historical state load time are both linear – doubling SPRP halves disk usage and doubles load time. The minimum SPRP is 32, and the maximum is 8192. @@ -38,9 +42,11 @@ The default value is 8192 for databases synced from scratch using Lighthouse v2. The values shown in the table are approximate, calculated using a simple heuristic: each `BeaconState` consumes around 18MB of disk space, and each block replayed takes around 5ms. The -**Yearly Disk Usage** column shows the approx size of the freezer DB _alone_ (hot DB not included), -and the **Load Historical State** time is the worst-case load time for a state in the last slot -before a restore point. +**Yearly Disk Usage** column shows the approximate size of the freezer DB _alone_ (hot DB not included), calculated proportionally using the total freezer database disk usage. +The **Load Historical State** time is the worst-case load time for a state in the last slot +before a restore point. + +As an example, we use an SPRP of 4096 to calculate the total size of the freezer database until May 2023. It has been about 900 days since the genesis, the total disk usage by the freezer database is therefore: 900/365*26.8 GB = 66 GB. ### Defaults @@ -68,6 +74,8 @@ The historical state cache size can be specified with the flag `--historic-state lighthouse beacon_node --historic-state-cache-size 4 ``` +> Note: This feature will cause high memory usage. + ## Glossary * _Freezer DB_: part of the database storing finalized states. States are stored in a sparser diff --git a/book/src/advanced_networking.md b/book/src/advanced_networking.md index 08d276ba3..59f3da376 100644 --- a/book/src/advanced_networking.md +++ b/book/src/advanced_networking.md @@ -51,7 +51,7 @@ peers for your node and overall improve the Ethereum consensus network. Lighthouse currently supports UPnP. If UPnP is enabled on your router, Lighthouse will automatically establish the port mappings for you (the beacon node will inform you of established routes in this case). If UPnP is not -enabled, we recommend you manually set up port mappings to both of Lighthouse's +enabled, we recommend you to manually set up port mappings to both of Lighthouse's TCP and UDP ports (9000 by default). > Note: Lighthouse needs to advertise its publicly accessible ports in @@ -63,6 +63,28 @@ TCP and UDP ports (9000 by default). > explicitly specify them using the `--enr-tcp-port` and `--enr-udp-port` as > explained in the following section. +### How to Open Ports + +The steps to do port forwarding depends on the router, but the general steps are given below: +1. Determine the default gateway IP: +- On Linux: open a terminal and run `ip route | grep default`, the result should look something similar to `default via 192.168.50.1 dev wlp2s0 proto dhcp metric 600`. The `192.168.50.1` is your router management default gateway IP. +- On MacOS: open a terminal and run `netstat -nr|grep default` and it should return the default gateway IP. +- On Windows: open a command prompt and run `ipconfig` and look for the `Default Gateway` which will show you the gateway IP. + + The default gateway IP usually looks like 192.168.X.X. Once you obtain the IP, enter it to a web browser and it will lead you to the router management page. + +2. Login to the router management page. The login credentials are usually available in the manual or the router, or it can be found on a sticker underneath the router. You can also try the login credentials for some common router brands listed [here](https://www.noip.com/support/knowledgebase/general-port-forwarding-guide/). + +3. Navigate to the port forward settings in your router. The exact step depends on the router, but typically it will fall under the "Advanced" section, under the name "port forwarding" or "virtual server". + +4. Configure a port forwarding rule as below: +- Protocol: select `TCP/UDP` or `BOTH` +- External port: `9000` +- Internal port: `9000` +- IP address: Usually there is a dropdown list for you to select the device. Choose the device that is running Lighthouse + +5. To check that you have successfully open the ports, go to [yougetsignal](https://www.yougetsignal.com/tools/open-ports/) and enter `9000` in the `port number`. If it shows "open", then you have successfully set up port forwarding. If it shows "closed", double check your settings, and also check that you have allowed firewall rules on port 9000. + ### ENR Configuration @@ -81,7 +103,7 @@ and if it is, it will update your ENR to the correct public IP and port address (meaning you do not need to set it manually). Lighthouse persists its ENR, so on reboot it will re-load the settings it had discovered previously. -Modifying the ENR settings can degrade the discovery of your node making it +Modifying the ENR settings can degrade the discovery of your node, making it harder for peers to find you or potentially making it harder for other peers to find each other. We recommend not touching these settings unless for a more advanced use case. diff --git a/book/src/api-bn.md b/book/src/api-bn.md index b86e593bf..11a006493 100644 --- a/book/src/api-bn.md +++ b/book/src/api-bn.md @@ -5,7 +5,7 @@ specification][OpenAPI]. Please follow that link for a full description of each ## Starting the server -A Lighthouse beacon node can be configured to expose a HTTP server by supplying the `--http` flag. The default listen address is `127.0.0.1:5052`. +A Lighthouse beacon node can be configured to expose an HTTP server by supplying the `--http` flag. The default listen address is `http://127.0.0.1:5052`. The following CLI flags control the HTTP server: @@ -55,11 +55,8 @@ Additional risks to be aware of include: ## CLI Example -Start the beacon node with the HTTP server listening on [http://localhost:5052](http://localhost:5052): +Start a beacon node and an execution node according to [Run a node](./run_a_node.md). Note that since [The Merge](https://ethereum.org/en/roadmap/merge/), an execution client is required to be running along with a beacon node. Hence, the query on Beacon Node APIs requires users to run both. While there are some Beacon Node APIs that you can query with only the beacon node, such as the [node version](https://ethereum.github.io/beacon-APIs/#/Node/getNodeVersion), in general an execution client is required to get the updated information about the beacon chain, such as [state root](https://ethereum.github.io/beacon-APIs/#/Beacon/getStateRoot), [headers](https://ethereum.github.io/beacon-APIs/#/Beacon/getBlockHeaders) and many others, which are dynamically progressing with time. -```bash -lighthouse bn --http -``` ## HTTP Request/Response Examples @@ -77,40 +74,46 @@ curl -X GET "http://localhost:5052/eth/v1/beacon/headers/head" -H "accept: appl ```json { + "execution_optimistic": false, + "finalized": false, "data": { - "root": "0x4381454174fc28c7095077e959dcab407ae5717b5dca447e74c340c1b743d7b2", + "root": "0x9059bbed6b8891e0ba2f656dbff93fc40f8c7b2b7af8fea9df83cfce5ee5e3d8", "canonical": true, "header": { "message": { - "slot": "3199", - "proposer_index": "19077", - "parent_root": "0xf1934973041c5896d0d608e52847c3cd9a5f809c59c64e76f6020e3d7cd0c7cd", - "state_root": "0xe8e468f9f5961655dde91968f66480868dab8d4147de9498111df2b7e4e6fe60", - "body_root": "0x6f183abc6c4e97f832900b00d4e08d4373bfdc819055d76b0f4ff850f559b883" + "slot": "6271829", + "proposer_index": "114398", + "parent_root": "0x1d2b4fa8247f754a7a86d36e1d0283a5e425491c431533716764880a7611d225", + "state_root": "0x2b48adea290712f56b517658dde2da5d36ee01c41aebe7af62b7873b366de245", + "body_root": "0x6fa74c995ce6f397fa293666cde054d6a9741f7ec280c640bee51220b4641e2d" }, - "signature": "0x988064a2f9cf13fe3aae051a3d85f6a4bca5a8ff6196f2f504e32f1203b549d5f86a39c6509f7113678880701b1881b50925a0417c1c88a750c8da7cd302dda5aabae4b941e3104d0cf19f5043c4f22a7d75d0d50dad5dbdaf6991381dc159ab" + "signature": "0x8258e64fea426033676a0045c50543978bf173114ba94822b12188e23cbc8d8e89e0b5c628a881bf3075d325bc11341105a4e3f9332ac031d89a93b422525b79e99325928a5262f17dfa6cc3ddf84ca2466fcad86a3c168af0d045f79ef52036" } } } ``` +The `jq` tool is used to format the JSON data properly. If it returns `jq: command not found`, then you can install `jq` with `sudo apt install -y jq`. After that, run the command again, and it should return the head state of the beacon chain. + ### View the status of a validator Shows the status of validator at index `1` at the `head` state. ```bash -curl -X GET "http://localhost:5052/eth/v1/beacon/states/head/validators/1" -H "accept: application/json" | jq +curl -X GET "http://localhost:5052/eth/v1/beacon/states/head/validators/1" -H "accept: application/json" ``` ```json { + "execution_optimistic": false, + "finalized": false, "data": { "index": "1", - "balance": "63985937939", - "status": "Active", + "balance": "32004587169", + "status": "active_ongoing", "validator": { - "pubkey": "0x873e73ee8b3e4fcf1d2fb0f1036ba996ac9910b5b348f6438b5f8ef50857d4da9075d0218a9d1b99a9eae235a39703e1", - "withdrawal_credentials": "0x00b8cdcf79ba7e74300a07e9d8f8121dd0d8dd11dcfd6d3f2807c45b426ac968", + "pubkey": "0xa1d1ad0714035353258038e964ae9675dc0252ee22cea896825c01458e1807bfad2f9969338798548d9858a571f7425c", + "withdrawal_credentials": "0x01000000000000000000000015f4b914a0ccd14333d850ff311d6dafbfbaa32b", "effective_balance": "32000000000", "slashed": false, "activation_eligibility_epoch": "0", @@ -121,6 +124,7 @@ curl -X GET "http://localhost:5052/eth/v1/beacon/states/head/validators/1" -H " } } ``` +You can replace `1` in the above command with the validator index that you would like to query. Other API query can be done similarly by changing the link according to the Beacon API. ## Serving the HTTP API over TLS > **Warning**: This feature is currently experimental. @@ -147,9 +151,18 @@ openssl req -x509 -nodes -newkey rsa:4096 -keyout key.pem -out cert.pem -days 36 Note that currently Lighthouse only accepts keys that are not password protected. This means we need to run with the `-nodes` flag (short for 'no DES'). -Once generated, we can run Lighthouse: +Once generated, we can run Lighthouse and an execution node according to [Run a node](./run_a_node.md). In addition, add the flags `--http-enable-tls --http-tls-cert cert.pem --http-tls-key key.pem` to Lighthouse, the command should look like: + ```bash -lighthouse bn --http --http-enable-tls --http-tls-cert cert.pem --http-tls-key key.pem +lighthouse bn \ + --network mainnet \ + --execution-endpoint http://localhost:8551 \ + --execution-jwt /secrets/jwt.hex \ + --checkpoint-sync-url https://mainnet.checkpoint.sigp.io \ + --http \ + --http-enable-tls \ + --http-tls-cert cert.pem \ + --http-tls-key key.pem ``` Note that the user running Lighthouse must have permission to read the certificate and key. @@ -159,6 +172,7 @@ The API is now being served at `https://localhost:5052`. To test connectivity, you can run the following: ```bash curl -X GET "https://localhost:5052/eth/v1/node/version" -H "accept: application/json" --cacert cert.pem | jq + ``` ### Connecting a validator client In order to connect a validator client to a beacon node over TLS, the validator @@ -201,13 +215,13 @@ Ensure the `--http` flag has been supplied at the CLI. You can quickly check that the HTTP endpoint is up using `curl`: ```bash -curl -X GET "http://localhost:5052/eth/v1/node/version" -H "accept: application/json" | jq +curl -X GET "http://localhost:5052/eth/v1/node/version" -H "accept:application/json" ``` The beacon node should respond with its version: ```json -{"data":{"version":"Lighthouse/v0.2.9-6f7b4768a/x86_64-linux"}} +{"data":{"version":"Lighthouse/v4.1.0-693886b/x86_64-linux"} ``` If this doesn't work, the server might not be started or there might be a diff --git a/book/src/api-lighthouse.md b/book/src/api-lighthouse.md index 47fe62f50..7626d6401 100644 --- a/book/src/api-lighthouse.md +++ b/book/src/api-lighthouse.md @@ -1,8 +1,8 @@ # Lighthouse Non-Standard APIs Lighthouse fully supports the standardization efforts at -[github.com/ethereum/beacon-APIs](https://github.com/ethereum/beacon-APIs), -however sometimes development requires additional endpoints that shouldn't +[github.com/ethereum/beacon-APIs](https://github.com/ethereum/beacon-APIs). +However, sometimes development requires additional endpoints that shouldn't necessarily be defined as a broad-reaching standard. Such endpoints are placed behind the `/lighthouse` path. @@ -16,10 +16,12 @@ Although we don't recommend that users rely on these endpoints, we document them briefly so they can be utilized by developers and researchers. + + ### `/lighthouse/health` +*Note: This endpoint is presently only available on Linux.* -*Presently only available on Linux.* - +Returns information regarding the health of the host machine. ```bash curl -X GET "http://localhost:5052/lighthouse/health" -H "accept: application/json" | jq ``` @@ -63,7 +65,7 @@ curl -X GET "http://localhost:5052/lighthouse/health" -H "accept: application/j ``` ### `/lighthouse/ui/health` - +Returns information regarding the health of the host machine. ```bash curl -X GET "http://localhost:5052/lighthouse/ui/health" -H "accept: application/json" | jq @@ -83,24 +85,24 @@ curl -X GET "http://localhost:5052/lighthouse/ui/health" -H "accept: applicatio "global_cpu_frequency": 3.4, "disk_bytes_total": 502390845440, "disk_bytes_free": 9981386752, - "network_name": "wlp0s20f3", - "network_bytes_total_received": 14105556611, - "network_bytes_total_transmit": 3649489389, - "nat_open": true, - "connected_peers": 80, - "sync_state": "Synced", "system_uptime": 660706, "app_uptime": 105, "system_name": "Arch Linux", "kernel_version": "5.19.13-arch1-1", "os_version": "Linux rolling Arch Linux", "host_name": "Computer1" + "network_name": "wlp0s20f3", + "network_bytes_total_received": 14105556611, + "network_bytes_total_transmit": 3649489389, + "nat_open": true, + "connected_peers": 80, + "sync_state": "Synced", } } ``` ### `/lighthouse/ui/validator_count` - +Returns an overview of validators. ```bash curl -X GET "http://localhost:5052/lighthouse/ui/validator_count" -H "accept: application/json" | jq ``` @@ -121,9 +123,9 @@ curl -X GET "http://localhost:5052/lighthouse/ui/validator_count" -H "accept: ap } ``` + ### `/lighthouse/ui/validator_metrics` -Re-exposes certain metrics from the validator monitor to the HTTP API. -Will only return metrics for the validators currently being monitored and are present in the POST data. +Re-exposes certain metrics from the validator monitor to the HTTP API. This API requires that the beacon node to have the flag `--validator-monitor-auto`. This API will only return metrics for the validators currently being monitored and present in the POST data, or the validators running in the validator client. ```bash curl -X POST "http://localhost:5052/lighthouse/ui/validator_metrics" -d '{"indices": [12345]}' -H "Content-Type: application/json" | jq ``` @@ -148,24 +150,40 @@ curl -X POST "http://localhost:5052/lighthouse/ui/validator_metrics" -d '{"indic } } ``` +Running this API without the flag `--validator-monitor-auto` in the beacon node will return null: +```json +{ + "data": { + "validators": {} + } +} +``` ### `/lighthouse/syncing` - +Returns the sync status of the beacon node. ```bash curl -X GET "http://localhost:5052/lighthouse/syncing" -H "accept: application/json" | jq ``` -```json -{ - "data": { - "SyncingFinalized": { - "start_slot": 3104, - "head_slot": 343744, - "head_root": "0x1b434b5ed702338df53eb5e3e24336a90373bb51f74b83af42840be7421dd2bf" +There are two possible outcomes, depending on whether the beacon node is syncing or synced. + +1. Syncing: + ```json + { + "data": { + "SyncingFinalized": { + "start_slot": "5478848", + "target_slot": "5478944" + } + } } - } -} -``` + ``` +1. Synced: + ```json + { + "data": "Synced" + } + ``` ### `/lighthouse/peers` @@ -173,96 +191,137 @@ curl -X GET "http://localhost:5052/lighthouse/syncing" -H "accept: application/ curl -X GET "http://localhost:5052/lighthouse/peers" -H "accept: application/json" | jq ``` + ```json [ { - "peer_id": "16Uiu2HAmA9xa11dtNv2z5fFbgF9hER3yq35qYNTPvN7TdAmvjqqv", + "peer_id": "16Uiu2HAm2ZoWQ2zkzsMFvf5o7nXa7R5F7H1WzZn2w7biU3afhgov", "peer_info": { - "_status": "Healthy", "score": { - "score": 0 + "Real": { + "lighthouse_score": 0, + "gossipsub_score": -18371.409037358582, + "ignore_negative_gossipsub_score": false, + "score": -21.816048231863316 + } }, "client": { "kind": "Lighthouse", - "version": "v0.2.9-1c9a055c", - "os_version": "aarch64-linux", - "protocol_version": "lighthouse/libp2p", - "agent_string": "Lighthouse/v0.2.9-1c9a055c/aarch64-linux" + "version": "v4.1.0-693886b", + "os_version": "x86_64-linux", + "protocol_version": "eth2/1.0.0", + "agent_string": "Lighthouse/v4.1.0-693886b/x86_64-linux" }, "connection_status": { "status": "disconnected", "connections_in": 0, "connections_out": 0, - "last_seen": 1082, + "last_seen": 9028, "banned_ips": [] }, "listening_addresses": [ - "/ip4/80.109.35.174/tcp/9000", - "/ip4/127.0.0.1/tcp/9000", - "/ip4/192.168.0.73/tcp/9000", - "/ip4/172.17.0.1/tcp/9000", - "/ip6/::1/tcp/9000" + "/ip4/212.102.59.173/tcp/23452", + "/ip4/23.124.84.197/tcp/23452", + "/ip4/127.0.0.1/tcp/23452", + "/ip4/192.168.0.2/tcp/23452", + "/ip4/192.168.122.1/tcp/23452" + ], + "seen_addresses": [ + "23.124.84.197:23452" ], "sync_status": { - "Advanced": { + "Synced": { "info": { - "status_head_slot": 343829, - "status_head_root": "0xe34e43efc2bb462d9f364bc90e1f7f0094e74310fd172af698b5a94193498871", - "status_finalized_epoch": 10742, - "status_finalized_root": "0x1b434b5ed702338df53eb5e3e24336a90373bb51f74b83af42840be7421dd2bf" + "head_slot": "5468141", + "head_root": "0x7acc017a199c0cf0693a19e0ed3a445a02165c03ea6f46cb5ffb8f60bf0ebf35", + "finalized_epoch": "170877", + "finalized_root": "0xbbc3541637976bd03b526de73e60a064e452a4b873b65f43fa91fefbba140410" } } }, "meta_data": { - "seq_number": 160, - "attnets": "0x0000000800000080" - } + "V2": { + "seq_number": 501, + "attnets": "0x0000020000000000", + "syncnets": "0x00" + } + }, + "subnets": [], + "is_trusted": false, + "connection_direction": "Outgoing", + "enr": "enr:-L64QI37ReMIki2Uqln3pcgQyAH8Y3ceSYrtJp1FlDEGSM37F7ngCpS9k-SKQ1bOHp0zFCkNxpvFlf_3o5OUkBRw0qyCAfqHYXR0bmV0c4gAAAIAAAAAAIRldGgykGKJQe8DABAg__________-CaWSCdjSCaXCEF3xUxYlzZWNwMjU2azGhAmoW921eIvf8pJhOvOwuxLSxKnpLY2inE_bUILdlZvhdiHN5bmNuZXRzAIN0Y3CCW5yDdWRwgluc" } } ] ``` ### `/lighthouse/peers/connected` - +Returns information about connected peers. ```bash curl -X GET "http://localhost:5052/lighthouse/peers/connected" -H "accept: application/json" | jq ``` + + ```json [ - { - "peer_id": "16Uiu2HAkzJC5TqDSKuLgVUsV4dWat9Hr8EjNZUb6nzFb61mrfqBv", + { + "peer_id": "16Uiu2HAmCAvpoYE6ABGdQJaW4iufVqNCTJU5AqzyZPB2D9qba7ZU", "peer_info": { - "_status": "Healthy", "score": { - "score": 0 + "Real": { + "lighthouse_score": 0, + "gossipsub_score": 0, + "ignore_negative_gossipsub_score": false, + "score": 0 + } }, "client": { "kind": "Lighthouse", - "version": "v0.2.8-87181204+", + "version": "v3.5.1-319cc61", "os_version": "x86_64-linux", - "protocol_version": "lighthouse/libp2p", - "agent_string": "Lighthouse/v0.2.8-87181204+/x86_64-linux" + "protocol_version": "eth2/1.0.0", + "agent_string": "Lighthouse/v3.5.1-319cc61/x86_64-linux" }, "connection_status": { "status": "connected", - "connections_in": 1, - "connections_out": 0, - "last_seen": 0, - "banned_ips": [] + "connections_in": 0, + "connections_out": 1, + "last_seen": 0 }, "listening_addresses": [ - "/ip4/34.204.178.218/tcp/9000", + "/ip4/144.91.92.17/tcp/9000", "/ip4/127.0.0.1/tcp/9000", - "/ip4/172.31.67.58/tcp/9000", - "/ip4/172.17.0.1/tcp/9000", - "/ip6/::1/tcp/9000" + "/ip4/172.19.0.3/tcp/9000" ], - "sync_status": "Unknown", + "seen_addresses": [ + "144.91.92.17:9000" + ], + "sync_status": { + "Synced": { + "info": { + "head_slot": "5468930", + "head_root": "0x25409073c65d2f6f5cee20ac2eff5ab980b576ca7053111456063f8ff8f67474", + "finalized_epoch": "170902", + "finalized_root": "0xab59473289e2f708341d8e5aafd544dd88e09d56015c90550ea8d16c50b4436f" + } + } + }, "meta_data": { - "seq_number": 1819, - "attnets": "0xffffffffffffffff" - } + "V2": { + "seq_number": 67, + "attnets": "0x0000000080000000", + "syncnets": "0x00" + } + }, + "subnets": [ + { + "Attestation": "39" + } + ], + "is_trusted": false, + "connection_direction": "Outgoing", + "enr": "enr:-Ly4QHd3RHJdkuR1iE6MtVtibC5S-aiWGPbwi4cG3wFGbqxRAkAgLDseTzPFQQIehQ7LmO7KIAZ5R1fotjMQ_LjA8n1Dh2F0dG5ldHOIAAAAAAAQAACEZXRoMpBiiUHvAwAQIP__________gmlkgnY0gmlwhJBbXBGJc2VjcDI1NmsxoQL4z8A7B-NS29zOgvkTX1YafKandwOtrqQ1XRnUJj3se4hzeW5jbmV0cwCDdGNwgiMog3VkcIIjKA" } } ] @@ -297,7 +356,8 @@ health of the execution node that the beacon node is connected to. - `latest_cached_block_number` & `latest_cached_block_timestamp`: the block number and timestamp of the latest block we have in our block cache. - For correct execution client voting this timestamp should be later than the -`voting_period_start_timestamp`. +`voting_target_timestamp`. + - `voting_target_timestamp`: The latest timestamp allowed for an execution layer block in this voting period. - `eth1_node_sync_status_percentage` (float): An estimate of how far the head of the execution node is from the head of the execution chain. @@ -420,11 +480,11 @@ curl -X GET "http://localhost:5052/lighthouse/beacon/states/0/ssz" | jq ### `/lighthouse/liveness` POST request that checks if any of the given validators have attested in the given epoch. Returns a list -of objects, each including the validator index, epoch, and `is_live` status of a requested validator. +of objects, each including the validator index, epoch, and `is_live` status of a requested validator. -This endpoint is used in doppelganger detection, and will only provide accurate information for the -current, previous, or next epoch. +This endpoint is used in doppelganger detection, and can only provide accurate information for the current, previous, or next epoch. +> Note that for this API, if you insert an arbitrary epoch other than the previous, current or next epoch of the network, it will return `"code:400"` and `BAD_REQUEST`. ```bash curl -X POST "http://localhost:5052/lighthouse/liveness" -d '{"indices":["0","1"],"epoch":"1"}' -H "content-type: application/json" | jq @@ -442,6 +502,8 @@ curl -X POST "http://localhost:5052/lighthouse/liveness" -d '{"indices":["0","1" } ``` + + ### `/lighthouse/database/info` Information about the database's split point and anchor info. @@ -450,26 +512,29 @@ Information about the database's split point and anchor info. curl "http://localhost:5052/lighthouse/database/info" | jq ``` + ```json { - "schema_version": 5, + "schema_version": 16, "config": { - "slots_per_restore_point": 2048, + "slots_per_restore_point": 8192, + "slots_per_restore_point_set_explicitly": false, "block_cache_size": 5, "historic_state_cache_size": 1, "compact_on_init": false, - "compact_on_prune": true + "compact_on_prune": true, + "prune_payloads": true }, "split": { - "slot": "2034912", - "state_root": "0x11c8516aa7d4d1613e84121e3a557ceca34618b4c1a38f05b66ad045ff82b33b" + "slot": "5485952", + "state_root": "0xcfe5d41e6ab5a9dab0de00d89d97ae55ecaeed3b08e4acda836e69b2bef698b4" }, "anchor": { - "anchor_slot": "2034720", - "oldest_block_slot": "1958881", - "oldest_block_parent": "0x1fd3d855d03e9df28d8a41a0f9cb9d4c540832b3ca1c3e1d7e09cd75b874cc87", - "state_upper_limit": "2035712", - "state_lower_limit": "0" + "anchor_slot": "5414688", + "oldest_block_slot": "0", + "oldest_block_parent": "0x0000000000000000000000000000000000000000000000000000000000000000", + "state_upper_limit": "5414912", + "state_lower_limit": "8192" } } ``` @@ -504,12 +569,12 @@ Manually provide `SignedBeaconBlock`s to backfill the database. This is intended for use by Lighthouse developers during testing only. ### `/lighthouse/merge_readiness` - +Returns the current difficulty and terminal total difficulty of the network. Before [The Merge](https://ethereum.org/en/roadmap/merge/) on 15th September 2022, you will see that the current difficulty is less than the terminal total difficulty, An example is shown below: ```bash curl -X GET "http://localhost:5052/lighthouse/merge_readiness" | jq ``` -``` +```json { "data":{ "type":"ready", @@ -521,6 +586,21 @@ curl -X GET "http://localhost:5052/lighthouse/merge_readiness" | jq } ``` +As all testnets and Mainnet have been merged, both values will be the same after The Merge. An example of response on the Goerli testnet: + +```json +{ + "data": { + "type": "ready", + "config": { + "terminal_total_difficulty": "10790000" + }, + "current_difficulty": "10790000" + } +} +``` + + ### `/lighthouse/analysis/attestation_performance/{index}` Fetch information about the attestation performance of a validator index or all validators for a @@ -611,20 +691,35 @@ Two query parameters are required: Example: ```bash -curl -X GET "http://localhost:5052/lighthouse/analysis/block_rewards?start_slot=1&end_slot=32" | jq +curl -X GET "http://localhost:5052/lighthouse/analysis/block_rewards?start_slot=1&end_slot=1" | jq ``` + +The first few lines of the response would look like: + ```json [ { - "block_root": "0x51576c2fcf0ab68d7d93c65e6828e620efbb391730511ffa35584d6c30e51410", - "attestation_rewards": { - "total": 4941156, + "total": 637260, + "block_root": "0x4a089c5e390bb98e66b27358f157df825128ea953cee9d191229c0bcf423a4f6", + "meta": { + "slot": "1", + "parent_slot": "0", + "proposer_index": 93, + "graffiti": "EF #vm-eth2-raw-iron-prater-101" }, - .. - }, - .. -] + "attestation_rewards": { + "total": 637260, + "prev_epoch_total": 0, + "curr_epoch_total": 637260, + "per_attestation_rewards": [ + { + "50102": 780, + } + ] + } + } +] ``` Caveats: @@ -653,6 +748,8 @@ Two query parameters are required: curl -X GET "http://localhost:5052/lighthouse/analysis/block_packing_efficiency?start_epoch=1&end_epoch=1" | jq ``` +An excerpt of the response looks like: + ```json [ { @@ -707,3 +804,16 @@ Should provide an output that emits log events as they occur: } } ``` + +### `/lighthouse/nat` +Checks if the ports are open. + +```bash +curl -X GET "http://localhost:5052/lighthouse/nat" | jq +``` + +An open port will return: +```json +{ + "data": true +} \ No newline at end of file diff --git a/book/src/api-vc-endpoints.md b/book/src/api-vc-endpoints.md index d5d76e4ef..406c5b1f0 100644 --- a/book/src/api-vc-endpoints.md +++ b/book/src/api-vc-endpoints.md @@ -17,8 +17,11 @@ HTTP Path | Description | [`POST /lighthouse/validators/mnemonic`](#post-lighthousevalidatorsmnemonic) | Create a new validator from an existing mnemonic. [`POST /lighthouse/validators/web3signer`](#post-lighthousevalidatorsweb3signer) | Add web3signer validators. +The query to Lighthouse API endpoints requires authorization, see [Authorization Header](./api-vc-auth-header.md). + In addition to the above endpoints Lighthouse also supports all of the [standard keymanager APIs](https://ethereum.github.io/keymanager-APIs/). + ## `GET /lighthouse/version` Returns the software version and `git` commit hash for the Lighthouse binary. @@ -32,15 +35,28 @@ Returns the software version and `git` commit hash for the Lighthouse binary. | Required Headers | [`Authorization`](./api-vc-auth-header.md) | | Typical Responses | 200 | -### Example Response Body +Command: +```bash +DATADIR=/var/lib/lighthouse +curl -X GET "http://localhost:5062/lighthouse/version" -H "Authorization: Bearer $(cat ${DATADIR}/validators/api-token.txt)" | jq +``` + +Example Response Body: + ```json { "data": { - "version": "Lighthouse/v0.2.11-fc0654fbe+/x86_64-linux" + "version": "Lighthouse/v4.1.0-693886b/x86_64-linux" } } ``` +> Note: The command provided in this documentation links to the API token file. In this documentation, it is assumed that the API token file is located in `/var/lib/lighthouse/validators/API-token.txt`. If your database is saved in another directory, modify the `DATADIR` accordingly. If you are having permission issue with accessing the API token file, you can modify the header to become `-H "Authorization: Bearer $(sudo cat ${DATADIR}/validators/api-token.txt)"`. + +> As an alternative, you can also provide the API token directly, for example, `-H "Authorization: Bearer api-token-0x02dc2a13115cc8c83baf170f597f22b1eb2930542941ab902df3daadebcb8f8176`. In this case, you obtain the token from the file `API token.txt` and the command becomes: +```bash +curl -X GET "http://localhost:5062/lighthouse/version" -H "Authorization: Bearer api-token-0x02dc2a13115cc8c83baf170f597f22b1eb2930542941ab902df3daadebcb8f8176" | jq +``` ## `GET /lighthouse/health` @@ -57,24 +73,48 @@ Returns information regarding the health of the host machine. *Note: this endpoint is presently only available on Linux.* -### Example Response Body +Command: +```bash +DATADIR=/var/lib/lighthouse +curl -X GET "http://localhost:5062/lighthouse/health" -H "Authorization: Bearer $(cat ${DATADIR}/validators/api-token.txt)" | jq +``` + +Example Response Body: ```json { - "data": { - "pid": 1476293, - "pid_num_threads": 19, - "pid_mem_resident_set_size": 4009984, - "pid_mem_virtual_memory_size": 1306775552, - "sys_virt_mem_total": 33596100608, - "sys_virt_mem_available": 23073017856, - "sys_virt_mem_used": 9346957312, - "sys_virt_mem_free": 22410510336, - "sys_virt_mem_percent": 31.322334, - "sys_loadavg_1": 0.98, - "sys_loadavg_5": 0.98, - "sys_loadavg_15": 1.01 - } + "data": { + "sys_virt_mem_total": 8184274944, + "sys_virt_mem_available": 1532280832, + "sys_virt_mem_used": 6248341504, + "sys_virt_mem_free": 648790016, + "sys_virt_mem_percent": 81.27775, + "sys_virt_mem_cached": 1244770304, + "sys_virt_mem_buffers": 42373120, + "sys_loadavg_1": 2.33, + "sys_loadavg_5": 2.11, + "sys_loadavg_15": 2.47, + "cpu_cores": 4, + "cpu_threads": 8, + "system_seconds_total": 103095, + "user_seconds_total": 750734, + "iowait_seconds_total": 60671, + "idle_seconds_total": 3922305, + "cpu_time_total": 4794222, + "disk_node_bytes_total": 982820896768, + "disk_node_bytes_free": 521943703552, + "disk_node_reads_total": 376287830, + "disk_node_writes_total": 48232652, + "network_node_bytes_total_received": 143003442144, + "network_node_bytes_total_transmit": 185348289905, + "misc_node_boot_ts_seconds": 1681740973, + "misc_os": "linux", + "pid": 144072, + "pid_num_threads": 27, + "pid_mem_resident_set_size": 15835136, + "pid_mem_virtual_memory_size": 2179018752, + "pid_process_seconds_total": 54 + } } ``` @@ -91,7 +131,13 @@ Returns information regarding the health of the host machine. | Required Headers | [`Authorization`](./api-vc-auth-header.md) | | Typical Responses | 200 | -### Example Response Body +Command: +```bash +DATADIR=/var/lib/lighthouse +curl -X GET "http://localhost:5062/lighthouse/ui/health" -H "Authorization: Bearer $(cat ${DATADIR}/validators/api-token.txt)" | jq + ``` + +Example Response Body ```json { @@ -130,7 +176,12 @@ Returns the graffiti that will be used for the next block proposal of each valid | Required Headers | [`Authorization`](./api-vc-auth-header.md) | | Typical Responses | 200 | -### Example Response Body +Command: +```bash +DATADIR=/var/lib/lighthouse +curl -X GET "http://localhost:5062/lighthouse/ui/graffiti" -H "Authorization: Bearer $(cat ${DATADIR}/validators/api-token.txt)" | jq + ``` +Example Response Body ```json { @@ -155,71 +206,115 @@ Returns the Ethereum proof-of-stake consensus specification loaded for this vali | Required Headers | [`Authorization`](./api-vc-auth-header.md) | | Typical Responses | 200 | -### Example Response Body +Command: + +```bash +DATADIR=/var/lib/lighthouse +curl -X GET "http://localhost:5062/lighthouse/spec" -H "Authorization: Bearer $(cat ${DATADIR}/validators/api-token.txt)" | jq +``` + +Example Response Body ```json { - "data": { - "CONFIG_NAME": "mainnet", - "MAX_COMMITTEES_PER_SLOT": "64", - "TARGET_COMMITTEE_SIZE": "128", - "MIN_PER_EPOCH_CHURN_LIMIT": "4", - "CHURN_LIMIT_QUOTIENT": "65536", - "SHUFFLE_ROUND_COUNT": "90", - "MIN_GENESIS_ACTIVE_VALIDATOR_COUNT": "1024", - "MIN_GENESIS_TIME": "1601380800", - "GENESIS_DELAY": "172800", - "MIN_DEPOSIT_AMOUNT": "1000000000", - "MAX_EFFECTIVE_BALANCE": "32000000000", - "EJECTION_BALANCE": "16000000000", - "EFFECTIVE_BALANCE_INCREMENT": "1000000000", - "HYSTERESIS_QUOTIENT": "4", - "HYSTERESIS_DOWNWARD_MULTIPLIER": "1", - "HYSTERESIS_UPWARD_MULTIPLIER": "5", - "PROPORTIONAL_SLASHING_MULTIPLIER": "3", - "GENESIS_FORK_VERSION": "0x00000002", - "BLS_WITHDRAWAL_PREFIX": "0x00", - "SECONDS_PER_SLOT": "12", - "MIN_ATTESTATION_INCLUSION_DELAY": "1", - "MIN_SEED_LOOKAHEAD": "1", - "MAX_SEED_LOOKAHEAD": "4", - "MIN_EPOCHS_TO_INACTIVITY_PENALTY": "4", - "MIN_VALIDATOR_WITHDRAWABILITY_DELAY": "256", - "SHARD_COMMITTEE_PERIOD": "256", - "BASE_REWARD_FACTOR": "64", - "WHISTLEBLOWER_REWARD_QUOTIENT": "512", - "PROPOSER_REWARD_QUOTIENT": "8", - "INACTIVITY_PENALTY_QUOTIENT": "16777216", - "MIN_SLASHING_PENALTY_QUOTIENT": "32", - "SAFE_SLOTS_TO_UPDATE_JUSTIFIED": "8", - "DOMAIN_BEACON_PROPOSER": "0x00000000", - "DOMAIN_BEACON_ATTESTER": "0x01000000", - "DOMAIN_RANDAO": "0x02000000", - "DOMAIN_DEPOSIT": "0x03000000", - "DOMAIN_VOLUNTARY_EXIT": "0x04000000", - "DOMAIN_SELECTION_PROOF": "0x05000000", - "DOMAIN_AGGREGATE_AND_PROOF": "0x06000000", - "DOMAIN_APPLICATION_MASK": "0x00000001", - "MAX_VALIDATORS_PER_COMMITTEE": "2048", - "SLOTS_PER_EPOCH": "32", - "EPOCHS_PER_ETH1_VOTING_PERIOD": "32", - "SLOTS_PER_HISTORICAL_ROOT": "8192", - "EPOCHS_PER_HISTORICAL_VECTOR": "65536", - "EPOCHS_PER_SLASHINGS_VECTOR": "8192", - "HISTORICAL_ROOTS_LIMIT": "16777216", - "VALIDATOR_REGISTRY_LIMIT": "1099511627776", - "MAX_PROPOSER_SLASHINGS": "16", - "MAX_ATTESTER_SLASHINGS": "2", - "MAX_ATTESTATIONS": "128", - "MAX_DEPOSITS": "16", - "MAX_VOLUNTARY_EXITS": "16", - "ETH1_FOLLOW_DISTANCE": "1024", - "TARGET_AGGREGATORS_PER_COMMITTEE": "16", - "RANDOM_SUBNETS_PER_VALIDATOR": "1", - "EPOCHS_PER_RANDOM_SUBNET_SUBSCRIPTION": "256", - "SECONDS_PER_ETH1_BLOCK": "14", - "DEPOSIT_CONTRACT_ADDRESS": "0x48b597f4b53c21b48ad95c7256b49d1779bd5890" - } + "data": { + "CONFIG_NAME": "prater", + "PRESET_BASE": "mainnet", + "TERMINAL_TOTAL_DIFFICULTY": "10790000", + "TERMINAL_BLOCK_HASH": "0x0000000000000000000000000000000000000000000000000000000000000000", + "TERMINAL_BLOCK_HASH_ACTIVATION_EPOCH": "18446744073709551615", + "SAFE_SLOTS_TO_IMPORT_OPTIMISTICALLY": "128", + "MIN_GENESIS_ACTIVE_VALIDATOR_COUNT": "16384", + "MIN_GENESIS_TIME": "1614588812", + "GENESIS_FORK_VERSION": "0x00001020", + "GENESIS_DELAY": "1919188", + "ALTAIR_FORK_VERSION": "0x01001020", + "ALTAIR_FORK_EPOCH": "36660", + "BELLATRIX_FORK_VERSION": "0x02001020", + "BELLATRIX_FORK_EPOCH": "112260", + "CAPELLA_FORK_VERSION": "0x03001020", + "CAPELLA_FORK_EPOCH": "162304", + "SECONDS_PER_SLOT": "12", + "SECONDS_PER_ETH1_BLOCK": "14", + "MIN_VALIDATOR_WITHDRAWABILITY_DELAY": "256", + "SHARD_COMMITTEE_PERIOD": "256", + "ETH1_FOLLOW_DISTANCE": "2048", + "INACTIVITY_SCORE_BIAS": "4", + "INACTIVITY_SCORE_RECOVERY_RATE": "16", + "EJECTION_BALANCE": "16000000000", + "MIN_PER_EPOCH_CHURN_LIMIT": "4", + "CHURN_LIMIT_QUOTIENT": "65536", + "PROPOSER_SCORE_BOOST": "40", + "DEPOSIT_CHAIN_ID": "5", + "DEPOSIT_NETWORK_ID": "5", + "DEPOSIT_CONTRACT_ADDRESS": "0xff50ed3d0ec03ac01d4c79aad74928bff48a7b2b", + "MAX_COMMITTEES_PER_SLOT": "64", + "TARGET_COMMITTEE_SIZE": "128", + "MAX_VALIDATORS_PER_COMMITTEE": "2048", + "SHUFFLE_ROUND_COUNT": "90", + "HYSTERESIS_QUOTIENT": "4", + "HYSTERESIS_DOWNWARD_MULTIPLIER": "1", + "HYSTERESIS_UPWARD_MULTIPLIER": "5", + "SAFE_SLOTS_TO_UPDATE_JUSTIFIED": "8", + "MIN_DEPOSIT_AMOUNT": "1000000000", + "MAX_EFFECTIVE_BALANCE": "32000000000", + "EFFECTIVE_BALANCE_INCREMENT": "1000000000", + "MIN_ATTESTATION_INCLUSION_DELAY": "1", + "SLOTS_PER_EPOCH": "32", + "MIN_SEED_LOOKAHEAD": "1", + "MAX_SEED_LOOKAHEAD": "4", + "EPOCHS_PER_ETH1_VOTING_PERIOD": "64", + "SLOTS_PER_HISTORICAL_ROOT": "8192", + "MIN_EPOCHS_TO_INACTIVITY_PENALTY": "4", + "EPOCHS_PER_HISTORICAL_VECTOR": "65536", + "EPOCHS_PER_SLASHINGS_VECTOR": "8192", + "HISTORICAL_ROOTS_LIMIT": "16777216", + "VALIDATOR_REGISTRY_LIMIT": "1099511627776", + "BASE_REWARD_FACTOR": "64", + "WHISTLEBLOWER_REWARD_QUOTIENT": "512", + "PROPOSER_REWARD_QUOTIENT": "8", + "INACTIVITY_PENALTY_QUOTIENT": "67108864", + "MIN_SLASHING_PENALTY_QUOTIENT": "128", + "PROPORTIONAL_SLASHING_MULTIPLIER": "1", + "MAX_PROPOSER_SLASHINGS": "16", + "MAX_ATTESTER_SLASHINGS": "2", + "MAX_ATTESTATIONS": "128", + "MAX_DEPOSITS": "16", + "MAX_VOLUNTARY_EXITS": "16", + "INACTIVITY_PENALTY_QUOTIENT_ALTAIR": "50331648", + "MIN_SLASHING_PENALTY_QUOTIENT_ALTAIR": "64", + "PROPORTIONAL_SLASHING_MULTIPLIER_ALTAIR": "2", + "SYNC_COMMITTEE_SIZE": "512", + "EPOCHS_PER_SYNC_COMMITTEE_PERIOD": "256", + "MIN_SYNC_COMMITTEE_PARTICIPANTS": "1", + "INACTIVITY_PENALTY_QUOTIENT_BELLATRIX": "16777216", + "MIN_SLASHING_PENALTY_QUOTIENT_BELLATRIX": "32", + "PROPORTIONAL_SLASHING_MULTIPLIER_BELLATRIX": "3", + "MAX_BYTES_PER_TRANSACTION": "1073741824", + "MAX_TRANSACTIONS_PER_PAYLOAD": "1048576", + "BYTES_PER_LOGS_BLOOM": "256", + "MAX_EXTRA_DATA_BYTES": "32", + "MAX_BLS_TO_EXECUTION_CHANGES": "16", + "MAX_WITHDRAWALS_PER_PAYLOAD": "16", + "MAX_VALIDATORS_PER_WITHDRAWALS_SWEEP": "16384", + "DOMAIN_DEPOSIT": "0x03000000", + "BLS_WITHDRAWAL_PREFIX": "0x00", + "RANDOM_SUBNETS_PER_VALIDATOR": "1", + "DOMAIN_SYNC_COMMITTEE": "0x07000000", + "TARGET_AGGREGATORS_PER_SYNC_SUBCOMMITTEE": "16", + "DOMAIN_BEACON_ATTESTER": "0x01000000", + "DOMAIN_VOLUNTARY_EXIT": "0x04000000", + "DOMAIN_SYNC_COMMITTEE_SELECTION_PROOF": "0x08000000", + "DOMAIN_CONTRIBUTION_AND_PROOF": "0x09000000", + "EPOCHS_PER_RANDOM_SUBNET_SUBSCRIPTION": "256", + "TARGET_AGGREGATORS_PER_COMMITTEE": "16", + "DOMAIN_APPLICATION_MASK": "0x00000001", + "DOMAIN_AGGREGATE_AND_PROOF": "0x06000000", + "DOMAIN_RANDAO": "0x02000000", + "DOMAIN_SELECTION_PROOF": "0x05000000", + "DOMAIN_BEACON_PROPOSER": "0x00000000", + "SYNC_COMMITTEE_SUBNET_COUNT": "4" + } } ``` @@ -240,13 +335,13 @@ file may be read by a local user with access rights. | Required Headers | - | | Typical Responses | 200 | -### Example Path +Command: -``` -localhost:5062/lighthouse/auth +```bash +curl http://localhost:5062/lighthouse/auth | jq ``` -### Example Response Body +Example Response Body ```json { @@ -267,7 +362,14 @@ Lists all validators managed by this validator client. | Required Headers | [`Authorization`](./api-vc-auth-header.md) | | Typical Responses | 200 | -### Example Response Body +Command: + +```bash +DATADIR=/var/lib/lighthouse +curl -X GET "http://localhost:5062/lighthouse/validators/" -H "Authorization: Bearer $(cat ${DATADIR}/validators/api-token.txt)" | jq +``` + +Example Response Body ```json { @@ -304,13 +406,14 @@ Get a validator by their `voting_pubkey`. | Required Headers | [`Authorization`](./api-vc-auth-header.md) | | Typical Responses | 200, 400 | -### Example Path +Command: -``` -localhost:5062/lighthouse/validators/0xb0148e6348264131bf47bcd1829590e870c836dc893050fd0dadc7a28949f9d0a72f2805d027521b45441101f0cc1cde +```bash +DATADIR=/var/lib/lighthouse +curl -X GET "http://localhost:5062/lighthouse/validators/0xb0148e6348264131bf47bcd1829590e870c836dc893050fd0dadc7a28949f9d0a72f2805d027521b45441101f0cc1cde" -H "Authorization: Bearer $(cat ${DATADIR}/validators/api-token.txt)" | jq ``` -### Example Response Body +Example Response Body ```json { @@ -323,7 +426,7 @@ localhost:5062/lighthouse/validators/0xb0148e6348264131bf47bcd1829590e870c836dc8 ## `PATCH /lighthouse/validators/:voting_pubkey` -Update some values for the validator with `voting_pubkey`. +Update some values for the validator with `voting_pubkey`. The following example updates a validator from `enabled: true` to `enabled: false` ### HTTP Specification @@ -334,13 +437,8 @@ Update some values for the validator with `voting_pubkey`. | Required Headers | [`Authorization`](./api-vc-auth-header.md) | | Typical Responses | 200, 400 | -### Example Path -``` -localhost:5062/lighthouse/validators/0xb0148e6348264131bf47bcd1829590e870c836dc893050fd0dadc7a28949f9d0a72f2805d027521b45441101f0cc1cde -``` - -### Example Request Body +Example Request Body ```json { @@ -348,12 +446,29 @@ localhost:5062/lighthouse/validators/0xb0148e6348264131bf47bcd1829590e870c836dc8 } ``` +Command: + +```bash +DATADIR=/var/lib/lighthouse +curl -X PATCH "http://localhost:5062/lighthouse/validators/0xb0148e6348264131bf47bcd1829590e870c836dc893050fd0dadc7a28949f9d0a72f2805d027521b45441101f0cc1cde" \ +-H "Authorization: Bearer $(cat ${DATADIR}/validators/api-token.txt)" \ +-H "Content-Type: application/json" \ +-d "{\"enabled\":false}" | jq +``` ### Example Response Body ```json null ``` +A `null` response indicates that the request is successful. At the same time, `lighthouse vc` will log: + +``` +INFO Disabled validator voting_pubkey: 0xb0148e6348264131bf47bcd1829590e870c836dc893050fd0dadc7a28949f9d0a72f2805d027521b45441101f0cc1cde +INFO Modified key_cache saved successfully +``` + + ## `POST /lighthouse/validators/` Create any number of new validators, all of which will share a common mnemonic @@ -392,6 +507,28 @@ Validators are generated from the mnemonic according to ] ``` +Command: +```bash +DATADIR=/var/lib/lighthouse +curl -X POST http://localhost:5062/lighthouse/validators \ +-H "Authorization: Bearer $(cat ${DATADIR}/validators/api-token.txt)" \ +-H "Content-Type: application/json" \ +-d '[ + { + "enable": true, + "description": "validator_one", + "deposit_gwei": "32000000000", + "graffiti": "Mr F was here", + "suggested_fee_recipient": "0xa2e334e71511686bcfe38bb3ee1ad8f6babcc03d" + }, + { + "enable": false, + "description": "validator two", + "deposit_gwei": "34000000000" + } +]' | jq +``` + ### Example Response Body ```json @@ -416,6 +553,14 @@ Validators are generated from the mnemonic according to ] } } +``` + + `lighthouse vc` will log: + +``` +INFO Enabled validator voting_pubkey: 0x8ffbc881fb60841a4546b4b385ec5e9b5090fd1c4395e568d98b74b94b41a912c6101113da39d43c101369eeb9b48e50, signing_method: local_keystore +INFO Modified key_cache saved successfully +INFO Disabled validator voting_pubkey: 0xa9fadd620dc68e9fe0d6e1a69f6c54a0271ad65ab5a509e645e45c6e60ff8f4fc538f301781193a08b55821444801502 ``` ## `POST /lighthouse/validators/keystore` @@ -474,6 +619,19 @@ Import a keystore into the validator client. } ``` +We can use [JSON to String Converter](https://jsontostring.com/) so that the above data can be properly presented as a command. The command is as below: + +Command: +```bash +DATADIR=/var/lib/lighthouse +curl -X POST http://localhost:5062/lighthouse/validators/keystore \ +-H "Authorization: Bearer $(cat ${DATADIR}/validators/api-token.txt)" \ +-H "Content-Type: application/json" \ +-d "{\"enable\":true,\"password\":\"mypassword\",\"keystore\":{\"crypto\":{\"kdf\":{\"function\":\"scrypt\",\"params\":{\"dklen\":32,\"n\":262144,\"r\":8,\"p\":1,\"salt\":\"445989ec2f332bb6099605b4f1562c0df017488d8d7fb3709f99ebe31da94b49\"},\"message\":\"\"},\"checksum\":{\"function\":\"sha256\",\"params\":{},\"message\":\"abadc1285fd38b24a98ac586bda5b17a8f93fc1ff0778803dc32049578981236\"},\"cipher\":{\"function\":\"aes-128-ctr\",\"params\":{\"iv\":\"65abb7e1d02eec9910d04299cc73efbe\"},\"message\":\"6b7931a4447be727a3bb5dc106d9f3c1ba50671648e522f213651d13450b6417\"}},\"uuid\":\"5cf2a1fb-dcd6-4095-9ebf-7e4ee0204cab\",\"path\":\"m/12381/3600/0/0/0\",\"pubkey\":\"b0d2f05014de27c6d7981e4a920799db1c512ee7922932be6bf55729039147cf35a090bd4ab378fe2d133c36cbbc9969\",\"version\":4,\"description\":\"\"}}" | jq +``` + +As this is an example for demonstration, the above command will return `InvalidPassword`. However, with a keystore file and correct password, running the above command will import the keystore to the validator client. An example of a success message is shown below: + ### Example Response Body ```json { @@ -484,6 +642,13 @@ Import a keystore into the validator client. } } +``` + + `lighthouse vc` will log: + +```bash +INFO Enabled validator voting_pubkey: 0xb0d2f05014de27c6d7981e4a920799db1c512ee7922932be6bf55729039147cf35a090bd4ab378fe2d133c36cbb, signing_method: local_keystore +INFO Modified key_cache saved successfully ``` ## `POST /lighthouse/validators/mnemonic` @@ -521,6 +686,16 @@ generated with the path `m/12381/3600/i/42`. } ``` +Command: + +```bash +DATADIR=/var/lib/lighthouse +curl -X POST http://localhost:5062/lighthouse/validators/mnemonic \ +-H "Authorization: Bearer $(cat ${DATADIR}/validators/api-token.txt)" \ +-H "Content-Type: application/json" \ +-d '{"mnemonic":" theme onion deal plastic claim silver fancy youth lock ordinary hotel elegant balance ridge web skill burger survey demand distance legal fish salad cloth","key_derivation_path_offset":0,"validators":[{"enable":true,"description":"validator_one","deposit_gwei":"32000000000"}]}' | jq +``` + ### Example Response Body ```json @@ -537,6 +712,13 @@ generated with the path `m/12381/3600/i/42`. } ``` +`lighthouse vc` will log: + +``` +INFO Enabled validator voting_pubkey: 0xa062f95fee747144d5e511940624bc6546509eeaeae9383257a9c43e7ddc58c17c2bab4ae62053122184c381b90db380, signing_method: local_keystore +INFO Modified key_cache saved successfully +``` + ## `POST /lighthouse/validators/web3signer` Create any number of new validators, all of which will refer to a @@ -575,9 +757,29 @@ The following fields may be omitted or nullified to obtain default values: - `root_certificate_path` - `request_timeout_ms` +Command: +```bash +DATADIR=/var/lib/lighthouse +curl -X POST http://localhost:5062/lighthouse/validators/web3signer \ +-H "Authorization: Bearer $(cat ${DATADIR}/validators/api-token.txt)" \ +-H "Content-Type: application/json" \ +-d "[{\"enable\":true,\"description\":\"validator_one\",\"graffiti\":\"Mr F was here\",\"suggested_fee_recipient\":\"0xa2e334e71511686bcfe38bb3ee1ad8f6babcc03d\",\"voting_public_key\":\"0xa062f95fee747144d5e511940624bc6546509eeaeae9383257a9c43e7ddc58c17c2bab4ae62053122184c381b90db380\",\"url\":\"http://path-to-web3signer.com\",\"request_timeout_ms\":12000}]" +``` + + ### Example Response Body -*No data is included in the response body.* + +```json +null +``` + +A `null` response indicates that the request is successful. At the same time, `lighthouse vc` will log: + +``` +INFO Enabled validator voting_pubkey: 0xa062f95fee747144d5e511940624bc6546509eeaeae9383257a9c43e7ddc58c17c2bab4ae62053122184c381b90db380, signing_method: remote_signer +``` + ## `GET /lighthouse/logs` @@ -607,4 +809,4 @@ logs emitted are INFO level or higher. "total": 1 } } -``` \ No newline at end of file +``` diff --git a/book/src/api-vc.md b/book/src/api-vc.md index 74c493ebe..a3400016e 100644 --- a/book/src/api-vc.md +++ b/book/src/api-vc.md @@ -14,13 +14,13 @@ signers. It also includes some Lighthouse-specific endpoints which are described ## Starting the server -A Lighthouse validator client can be configured to expose a HTTP server by supplying the `--http` flag. The default listen address is `127.0.0.1:5062`. +A Lighthouse validator client can be configured to expose a HTTP server by supplying the `--http` flag. The default listen address is `http://127.0.0.1:5062`. The following CLI flags control the HTTP server: - `--http`: enable the HTTP server (required even if the following flags are provided). -- `--http-address`: specify the listen address of the server. It is almost always unsafe to use a non-default HTTP listen address. Use with caution. See the **Security** section below for more information. +- `--http-address`: specify the listen address of the server. It is almost always unsafe to use a non-default HTTP listen address. Use this with caution. See the **Security** section below for more information. - `--http-port`: specify the listen port of the server. - `--http-allow-origin`: specify the value of the `Access-Control-Allow-Origin` header. The default is to not supply a header. @@ -28,7 +28,7 @@ The following CLI flags control the HTTP server: ## Security The validator client HTTP server is **not encrypted** (i.e., it is **not HTTPS**). For -this reason, it will listen by default on `127.0.0.1`. +this reason, it will listen by default on `http://127.0.0.1`. It is unsafe to expose the validator client to the public Internet without additional transport layer security (e.g., HTTPS via nginx, SSH tunnels, etc.). diff --git a/book/src/builders.md b/book/src/builders.md index fc42f9b74..8d727ef2c 100644 --- a/book/src/builders.md +++ b/book/src/builders.md @@ -1,4 +1,4 @@ -# MEV and Lighthouse +# Maximal Extractable Value (MEV) Lighthouse is able to interact with servers that implement the [builder API](https://github.com/ethereum/builder-specs), allowing it to produce blocks without having @@ -103,11 +103,31 @@ Each field is optional. } ``` +Command: + +```bash +DATADIR=/var/lib/lighthouse +curl -X PATCH "http://localhost:5062/lighthouse/validators/0xb0148e6348264131bf47bcd1829590e870c836dc893050fd0dadc7a28949f9d0a72f2805d027521b45441101f0cc1cde" \ +-H "Authorization: Bearer $(sudo cat ${DATADIR}/validators/api-token.txt)" \ +-H "Content-Type: application/json" \ +-d '{ + "builder_proposals": true, + "gas_limit": 30000001 +}' | jq +``` + #### Example Response Body ```json null ``` + +A `null` response indicates that the request is successful. At the same time, `lighthouse vc` will show a log which looks like: + +``` +INFO Published validator registrations to the builder network, count: 3, service: preparation +``` + ### Fee Recipient Refer to [suggested fee recipient](suggested-fee-recipient.md) documentation. @@ -167,9 +187,18 @@ consider using it for the chance of out-sized rewards, this flag may be useful: The number provided indicates the minimum reward that an external payload must provide the proposer for it to be considered for inclusion in a proposal. For example, if you'd only like to use an external payload for a reward of >= 0.25 ETH, you would provide your beacon node with `--builder-profit-threshold 250000000000000000`. If it's your turn to propose and the -most valuable payload offered by builders is only 0.1 ETH, the local execution engine's payload will be used. Currently, -this threshold just looks at the value of the external payload. No comparison to the local payload is made, although -this feature will likely be added in the future. +most valuable payload offered by builders is only 0.1 ETH, the local execution engine's payload will be used. + +Since the [Capella](https://ethereum.org/en/history/#capella) upgrade, a comparison of the external payload and local payload will be made according to the [engine_getPayloadV2](https://github.com/ethereum/execution-apis/blob/main/src/engine/shanghai.md#engine_getpayloadv2) API. The logic is as follows: + +``` +if local payload value >= builder payload value: + use local payload +else if builder payload value >= builder_profit_threshold or builder_profit_threshold == 0: + use builder payload +else: + use local payload +``` ## Checking your builder config diff --git a/book/src/checkpoint-sync.md b/book/src/checkpoint-sync.md index 47dc03b20..d5c8b18e5 100644 --- a/book/src/checkpoint-sync.md +++ b/book/src/checkpoint-sync.md @@ -34,7 +34,7 @@ INFO Loaded checkpoint block and state state_root: 0xe8252c68784a8d5cc7e54 ``` > **Security Note**: You should cross-reference the `block_root` and `slot` of the loaded checkpoint -> against a trusted source like a friend's node, or a block explorer. +> against a trusted source like a friend's node, a block explorer or some [public endpoints](https://eth-clients.github.io/checkpoint-sync-endpoints/). Once the checkpoint is loaded Lighthouse will sync forwards to the head of the chain. @@ -62,6 +62,10 @@ INFO Downloading historical blocks est_time: 5 hrs 0 mins, speed: 111.96 slots/ Once backfill is complete, a `INFO Historical block download complete` log will be emitted. +> Note: Since [v4.1.0](https://github.com/sigp/lighthouse/releases/tag/v4.1.0), Lighthouse implements rate-limited backfilling to mitigate validator performance issues after a recent checkpoint sync. This means that the speed at which historical blocks are downloaded is limited, typically to less than 20 slots/sec. This will not affect validator performance. However, if you would still prefer to sync the chain as fast as possible, you can add the flag `--disable-backfill-rate-limiting` to the beacon node. + +> Note: Since [v4.2.0](https://github.com/sigp/lighthouse/releases/tag/v4.2.0), Lighthouse limits the backfill sync to only sync backwards to the weak subjectivity point (approximately 5 months). This will help to save disk space. However, if you would like to sync back to the genesis, you can add the flag `--genesis-backfill` to the beacon node. + ## FAQ 1. What if I have an existing database? How can I use checkpoint sync? diff --git a/book/src/database-migrations.md b/book/src/database-migrations.md index 5e0b89635..9b60ca2e1 100644 --- a/book/src/database-migrations.md +++ b/book/src/database-migrations.md @@ -29,6 +29,7 @@ validator client or the slasher**. | v3.4.0 | Jan 2023 | v13 | yes | | v3.5.0 | Feb 2023 | v15 | yes before Capella | | v4.0.1 | Mar 2023 | v16 | yes before Capella | +| v4.2.0 | May 2023 | v17 | yes | > **Note**: All point releases (e.g. v2.3.1) are schema-compatible with the prior minor release > (e.g. v2.3.0). @@ -82,24 +83,36 @@ on downgrades above. To check the schema version of a running Lighthouse instance you can use the HTTP API: ```bash -curl "http://localhost:5052/lighthouse/database/info" +curl "http://localhost:5052/lighthouse/database/info" | jq ``` ```json { - "schema_version": 8, + "schema_version": 16, "config": { "slots_per_restore_point": 8192, - "slots_per_restore_point_set_explicitly": true, + "slots_per_restore_point_set_explicitly": false, "block_cache_size": 5, "historic_state_cache_size": 1, "compact_on_init": false, - "compact_on_prune": true + "compact_on_prune": true, + "prune_payloads": true + }, + "split": { + "slot": "5485952", + "state_root": "0xcfe5d41e6ab5a9dab0de00d89d97ae55ecaeed3b08e4acda836e69b2bef698b4" + }, + "anchor": { + "anchor_slot": "5414688", + "oldest_block_slot": "0", + "oldest_block_parent": "0x0000000000000000000000000000000000000000000000000000000000000000", + "state_upper_limit": "5414912", + "state_lower_limit": "8192" } } ``` -The `schema_version` key indicates that this database is using schema version 8. +The `schema_version` key indicates that this database is using schema version 16. Alternatively, you can check the schema version with the `lighthouse db` command. @@ -118,7 +131,7 @@ Several conditions need to be met in order to run `lighthouse db`: 2. The command must run as the user that owns the beacon node database. If you are using systemd then your beacon node might run as a user called `lighthousebeacon`. 3. The `--datadir` flag must be set to the location of the Lighthouse data directory. -4. The `--network` flag must be set to the correct network, e.g. `mainnet`, `prater` or `sepolia`. +4. The `--network` flag must be set to the correct network, e.g. `mainnet`, `goerli` or `sepolia`. The general form for a `lighthouse db` command is: diff --git a/book/src/key-management.md b/book/src/key-management.md index 084b1fbe4..cebd84649 100644 --- a/book/src/key-management.md +++ b/book/src/key-management.md @@ -3,7 +3,7 @@ [launchpad]: https://launchpad.ethereum.org/ > -> **Note: While Lighthouse is able to generate the validator keys and the deposit data file to submit to the deposit contract, we strongly recommend using the [staking-deposit-cli](https://github.com/ethereum/staking-deposit-cli) to create validators keys and the deposit data file. This is because the [staking-deposit-cli](https://github.com/ethereum/staking-deposit-cli) which has the option to assign a withdrawal address during the key generation process, while Lighthouse wallet will always generate keys with withdrawal credentials of type 0x00. This means that users who created keys using Lighthouse will have to update their withdrawal credentials in the future to enable withdrawals. In addition, Lighthouse generates the deposit data file in the form of `*.rlp`, which cannot be uploaded to the [Staking launchpad][launchpad] that accepts only `*.json` file. This means that users have to directly interact with the deposit contract to be able to submit the deposit if they were to generate the files using Lighthouse.** +> **Note: While Lighthouse is able to generate the validator keys and the deposit data file to submit to the deposit contract, we strongly recommend using the [staking-deposit-cli](https://github.com/ethereum/staking-deposit-cli) to create validators keys and the deposit data file. This is because the [staking-deposit-cli](https://github.com/ethereum/staking-deposit-cli) has the option to assign a withdrawal address during the key generation process, while Lighthouse wallet will always generate keys with withdrawal credentials of type 0x00. This means that users who created keys using Lighthouse will have to update their withdrawal credentials in the future to enable withdrawals. In addition, Lighthouse generates the deposit data file in the form of `*.rlp`, which cannot be uploaded to the [Staking launchpad][launchpad] that accepts only `*.json` file. This means that users have to directly interact with the deposit contract to be able to submit the deposit if they were to generate the files using Lighthouse.** Lighthouse uses a _hierarchical_ key management system for producing validator keys. It is hierarchical because each validator key can be _derived_ from a diff --git a/book/src/merge-migration.md b/book/src/merge-migration.md index 08107695f..acca0bbeb 100644 --- a/book/src/merge-migration.md +++ b/book/src/merge-migration.md @@ -1,15 +1,13 @@ # Merge Migration -This document provides detail for users who want to run a Lighthouse node on post-merge Ethereum. - -> The merge occurred on mainnet in September 2022. +[The Merge](https://ethereum.org/en/roadmap/merge/) has occurred on mainnet on 15th September 2022. This document provides detail of what users need to do in the past (before The Merge) to run a Lighthouse node on a post-merge Ethereum network. This document now serves as a record of the milestone upgrade. ## Necessary Configuration There are two configuration changes required for a Lighthouse node to operate correctly throughout the merge: -1. You *must* run your own execution engine such as Geth or Nethermind alongside Lighthouse. +1. You *must* run your own execution engine such as Besu, Erigon, Geth or Nethermind alongside Lighthouse. You *must* update your `lighthouse bn` configuration to connect to the execution engine using new flags which are documented on this page in the [Connecting to an execution engine](#connecting-to-an-execution-engine) section. @@ -23,11 +21,19 @@ engine to a merge-ready version. ## When? -You must configure your node to be merge-ready before the Bellatrix fork occurs on the network -on which your node is operating. +All networks (**Mainnet**, **Goerli (Prater)**, **Ropsten**, **Sepolia**, **Kiln**, **Gnosis**) have successfully undergone the Bellatrix fork and transitioned to a post-merge Network. Your node must have a merge-ready configuration to continue operating. Table below lists the date at which Bellatrix and The Merge occurred: -* **Mainnet**, **Goerli (Prater)**, **Ropsten**, **Sepolia**, **Kiln**, **Gnosis**: the Bellatrix fork has - already occurred. You must have a merge-ready configuration right now. +
+ +| Network | Bellatrix | The Merge | Remark | +|-------------------|--------------------------------------------|----|----| +| Ropsten | 2nd June 2022 | 8th June 2022 | Deprecated +| Sepolia | 20th June 2022 | 6th July 2022 | | +| Goerli | 4th August 2022 | 10th August 2022 | Previously named `Prater`| +| Mainnet | 6th September 2022 | 15th September 2022 | +| Gnosis| 30th November 2022 | 8th December 2022 + +
## Connecting to an execution engine @@ -41,7 +47,7 @@ present in post-merge blocks. Two new flags are used to configure this connectio If you set up an execution engine with `--execution-endpoint` then you *must* provide a JWT secret using `--execution-jwt`. This is a mandatory form of authentication that ensures that Lighthouse -has authority to control the execution engine. +has the authority to control the execution engine. > Tip: the --execution-jwt-secret-key flag can be used instead of --execution-jwt . > This is useful, for example, for users who wish to inject the value into a Docker container without @@ -88,7 +94,7 @@ lighthouse \ beacon_node \ --http \ --execution-endpoint http://localhost:8551 - --execution-jwt ~/.ethereum/geth/jwtsecret + --execution-jwt /path/to/jwtsecret ``` The changes here are: @@ -104,8 +110,7 @@ The changes here are: not be `8551`, see their documentation for details. 3. Add the `--execution-jwt` flag. - This is the path to a file containing a 32-byte secret for authenticating the BN with the - execution engine. In this example our execution engine is Geth, so we've chosen the default - location for Geth. Your execution engine might have a different path. It is critical that both + execution engine. It is critical that both the BN and execution engine reference a file with the same value, otherwise they'll fail to communicate. @@ -117,7 +122,7 @@ a deprecation warning will be logged and Lighthouse *may* remove these flags in ### The relationship between `--eth1-endpoints` and `--execution-endpoint` Pre-merge users will be familiar with the `--eth1-endpoints` flag. This provides a list of Ethereum -"eth1" nodes (e.g., Geth, Nethermind, etc). Each beacon node (BN) can have multiple eth1 endpoints +"eth1" nodes (Besu, Erigon, Geth or Nethermind). Each beacon node (BN) can have multiple eth1 endpoints and each eth1 endpoint can have many BNs connection (many-to-many relationship). The eth1 node provides a source of truth for the [deposit contract](https://ethereum.org/en/staking/deposit-contract/) and beacon chain proposers include this @@ -128,7 +133,7 @@ achieve this. To progress through the Bellatrix upgrade nodes will need a *new* connection to an "eth1" node; `--execution-endpoint`. This connection has a few different properties. Firstly, the term "eth1 node" has been deprecated and replaced with "execution engine". Whilst "eth1 node" and "execution -engine" still refer to the same projects (Geth, Nethermind, etc) the former refers to the pre-merge +engine" still refer to the same projects (Besu, Erigon, Geth or Nethermind), the former refers to the pre-merge versions and the latter refers to post-merge versions. Secondly, there is a strict one-to-one relationship between Lighthouse and the execution engine; only one Lighthouse node can connect to one execution engine. Thirdly, it is impossible to fully verify the post-merge chain without an @@ -138,7 +143,7 @@ impossible to reliably *propose* blocks without it. Since an execution engine is a hard requirement in the post-merge chain and the execution engine contains the transaction history of the Ethereum chain, there is no longer a need for the `--eth1-endpoints` flag for information about the deposit contract. The `--execution-endpoint` can -be used for all such queries. Therefore we can say that where `--execution-endpoint` is included +be used for all such queries. Therefore we can say that where `--execution-endpoint` is included, `--eth1-endpoints` should be omitted. ## FAQ diff --git a/book/src/redundancy.md b/book/src/redundancy.md index dcd2ecdea..77cec3253 100644 --- a/book/src/redundancy.md +++ b/book/src/redundancy.md @@ -8,7 +8,7 @@ There are three places in Lighthouse where redundancy is notable: 1. ❌ NOT SUPPORTED: Using a redundant execution node in `lighthouse bn --execution-endpoint` 1. ☠️ BAD: Running redundant `lighthouse vc` instances with overlapping keypairs. -I mention (3) since it is unsafe and should not be confused with the other two +We mention (3) since it is unsafe and should not be confused with the other two uses of redundancy. **Running the same validator keypair in more than one validator client (Lighthouse, or otherwise) will eventually lead to slashing.** See [Slashing Protection](./slashing-protection.md) for more information. @@ -49,6 +49,7 @@ There are a few interesting properties about the list of `--beacon-nodes`: > provided (if it is desired). It will only be used as default if no `--beacon-nodes` flag is > provided at all. + ### Configuring a redundant Beacon Node In our previous example, we listed `http://192.168.1.1:5052` as a redundant @@ -56,10 +57,9 @@ node. Apart from having sufficient resources, the backup node should have the following flags: - `--http`: starts the HTTP API server. -- `--http-address 0.0.0.0`: this allows *any* external IP address to access the - HTTP server (a firewall should be configured to deny unauthorized access to port - `5052`). This is only required if your backup node is on a different host. -- `--execution-endpoint`: see [Merge Migration](./merge-migration.md). +- `--http-address local_IP`: where `local_IP` is the private IP address of the computer running the beacon node. This is only required if your backup beacon node is on a different host. + > Note: You could also use `--http-address 0.0.0.0`, but this allows *any* external IP address to access the HTTP server. As such, a firewall should be configured to deny unauthorized access to port `5052`. + - `--execution-endpoint`: see [Merge Migration](./merge-migration.md). - `--execution-jwt`: see [Merge Migration](./merge-migration.md). For example one could use the following command to provide a backup beacon node: @@ -67,7 +67,7 @@ For example one could use the following command to provide a backup beacon node: ```bash lighthouse bn \ --http \ - --http-address 0.0.0.0 \ + --http-address local_IP \ --execution-endpoint http://localhost:8551 \ --execution-jwt /secrets/jwt.hex ``` diff --git a/book/src/slasher.md b/book/src/slasher.md index 61dc4b327..ecf9d34ef 100644 --- a/book/src/slasher.md +++ b/book/src/slasher.md @@ -8,10 +8,9 @@ extra income for your validators. However it is currently only recommended for e of the immaturity of the slasher UX and the extra resources required. ## Minimum System Requirements - * Quad-core CPU * 16 GB RAM -* 256 GB solid state storage (in addition to space for the beacon node DB) +* 256 GB solid state storage (in addition to the space requirement for the beacon node DB) ## How to Run @@ -28,7 +27,7 @@ messages are filtered for relevancy, and all relevant messages are checked for s to the slasher database. You **should** run with debug logs, so that you can see the slasher's internal machinations, and -provide logs to the devs should you encounter any bugs. +provide logs to the developers should you encounter any bugs. ## Configuration @@ -97,7 +96,7 @@ Both database backends LMDB and MDBX place a hard limit on the size of the datab file. You can use the `--slasher-max-db-size` flag to set this limit. It can be adjusted after initialization if the limit is reached. -By default the limit is set to accommodate the default history length and around 300K validators but +By default the limit is set to accommodate the default history length and around 600K validators (with about 30% headroom) but you can set it lower if running with a reduced history length. The space required scales approximately linearly in validator count and history length, i.e. if you halve either you can halve the space required. @@ -108,7 +107,7 @@ If you want an estimate of the database size you can use this formula: 4.56 GB * (N / 256) * (V / 250000) ``` -where `V` is the validator count and `N` is the history length. +where `N` is the history length and `V` is the validator count. You should set the maximum size higher than the estimate to allow room for growth in the validator count. diff --git a/book/src/suggested-fee-recipient.md b/book/src/suggested-fee-recipient.md index f3ece8506..44accbd14 100644 --- a/book/src/suggested-fee-recipient.md +++ b/book/src/suggested-fee-recipient.md @@ -103,6 +103,8 @@ client. } ``` +Command: + ```bash DATADIR=$HOME/.lighthouse/mainnet PUBKEY=0xa9735061c84fc0003657e5bd38160762b7ef2d67d280e00347b1781570088c32c06f15418c144949f5d736b1d3a6c591 @@ -115,11 +117,15 @@ curl -X POST \ http://localhost:5062/eth/v1/validator/${PUBKEY}/feerecipient | jq ``` +Note that an authorization header is required to interact with the API. This is specified with the header `-H "Authorization: Bearer $(cat ${DATADIR}/validators/api-token.txt)"` which read the API token to supply the authentication. Refer to [Authorization Header](./api-vc-auth-header.md) for more information. If you are having permission issue with accessing the API token file, you can modify the header to become `-H "Authorization: Bearer $(sudo cat ${DATADIR}/validators/api-token.txt)"`. + #### Successful Response (202) ```json null ``` +A `null` response indicates that the request is successful. + ### Querying the fee recipient The same path with a `GET` request can be used to query the fee recipient for a given public key at any time. @@ -131,6 +137,8 @@ The same path with a `GET` request can be used to query the fee recipient for a | Required Headers | [`Authorization`](./api-vc-auth-header.md) | | Typical Responses | 200, 404 | +Command: + ```bash DATADIR=$HOME/.lighthouse/mainnet PUBKEY=0xa9735061c84fc0003657e5bd38160762b7ef2d67d280e00347b1781570088c32c06f15418c144949f5d736b1d3a6c591 @@ -163,6 +171,8 @@ This is useful if you want the fee recipient to fall back to the validator clien | Required Headers | [`Authorization`](./api-vc-auth-header.md) | | Typical Responses | 204, 404 | +Command: + ```bash DATADIR=$HOME/.lighthouse/mainnet PUBKEY=0xa9735061c84fc0003657e5bd38160762b7ef2d67d280e00347b1781570088c32c06f15418c144949f5d736b1d3a6c591 diff --git a/book/src/validator-inclusion.md b/book/src/validator-inclusion.md index 0793af20d..ef81b2b75 100644 --- a/book/src/validator-inclusion.md +++ b/book/src/validator-inclusion.md @@ -8,6 +8,8 @@ These endpoints are not stable or included in the Ethereum consensus standard AP they are subject to change or removal without a change in major release version. +In order to apply these APIs, you need to have historical states information in the database of your node. This means adding the flag `--reconstruct-historic-states` in the beacon node or using the [/lighthouse/database/reconstruct API](./api-lighthouse.md#lighthousedatabasereconstruct). Once the state reconstruction process is completed, you can apply these APIs to any epoch. + ## Endpoints HTTP Path | Description | @@ -29,7 +31,7 @@ is not the case for attestations from the _previous_ epoch. ``` `epoch` query parameter | - | --------- values are calcuated here + | --------- values are calculated here | | v v Epoch: |---previous---|---current---|---next---| diff --git a/book/src/validator-web3signer.md b/book/src/validator-web3signer.md index 103f1ccb3..00ef9a6b5 100644 --- a/book/src/validator-web3signer.md +++ b/book/src/validator-web3signer.md @@ -5,7 +5,7 @@ [Teku]: https://github.com/consensys/teku [Web3Signer] is a tool by Consensys which allows *remote signing*. Remote signing is when a -Validator Client (VC) out-sources the signing of messages to remote server (e.g., via HTTPS). This +Validator Client (VC) out-sources the signing of messages to a remote server (e.g., via HTTPS). This means that the VC does not hold the validator private keys. ## Warnings @@ -47,7 +47,7 @@ remote signer: client_identity_password: "password" ``` -When using this file, the Lighthouse VC will perform duties for the `0xa5566..` validator and defer +When using this file, the Lighthouse VC will perform duties for the `0xa5566..` validator and refer to the `https://my-remote-signer.com:1234` server to obtain any signatures. It will load a "self-signed" SSL certificate from `/home/paul/my-certificates/my-remote-signer.pem` (on the filesystem of the VC) to encrypt the communications between the VC and Web3Signer. It will use From 04386cfabb94d5e645441dd856f527bf05dcc3dc Mon Sep 17 00:00:00 2001 From: Michael Sproul Date: Fri, 2 Jun 2023 03:17:37 +0000 Subject: [PATCH 15/18] Expose execution block hash calculation (#4326) ## Proposed Changes This is a light refactor of the execution layer's block hash calculation logic making it easier to use externally. e.g. in `eleel` (https://github.com/sigp/eleel/pull/18). A static method is preferable to a method because the calculation doesn't actually need any data from `self`, and callers may want to compute block hashes without constructing an `ExecutionLayer` (`eleel` only constructs a simpler `Engine` struct). --- beacon_node/execution_layer/src/block_hash.rs | 25 ++++++++++++++----- 1 file changed, 19 insertions(+), 6 deletions(-) diff --git a/beacon_node/execution_layer/src/block_hash.rs b/beacon_node/execution_layer/src/block_hash.rs index e9b7dcc17..c889fead0 100644 --- a/beacon_node/execution_layer/src/block_hash.rs +++ b/beacon_node/execution_layer/src/block_hash.rs @@ -12,12 +12,13 @@ use types::{ }; impl ExecutionLayer { - /// Verify `payload.block_hash` locally within Lighthouse. + /// Calculate the block hash of an execution block. /// - /// No remote calls to the execution client will be made, so this is quite a cheap check. - pub fn verify_payload_block_hash(&self, payload: ExecutionPayloadRef) -> Result<(), Error> { - let _timer = metrics::start_timer(&metrics::EXECUTION_LAYER_VERIFY_BLOCK_HASH); - + /// Return `(block_hash, transactions_root)`, where `transactions_root` is the root of the RLP + /// transactions. + pub fn calculate_execution_block_hash( + payload: ExecutionPayloadRef, + ) -> (ExecutionBlockHash, Hash256) { // Calculate the transactions root. // We're currently using a deprecated Parity library for this. We should move to a // better alternative when one appears, possibly following Reth. @@ -46,7 +47,19 @@ impl ExecutionLayer { // Hash the RLP encoding of the block header. let rlp_block_header = rlp_encode_block_header(&exec_block_header); - let header_hash = ExecutionBlockHash::from_root(keccak256(&rlp_block_header)); + ( + ExecutionBlockHash::from_root(keccak256(&rlp_block_header)), + rlp_transactions_root, + ) + } + + /// Verify `payload.block_hash` locally within Lighthouse. + /// + /// No remote calls to the execution client will be made, so this is quite a cheap check. + pub fn verify_payload_block_hash(&self, payload: ExecutionPayloadRef) -> Result<(), Error> { + let _timer = metrics::start_timer(&metrics::EXECUTION_LAYER_VERIFY_BLOCK_HASH); + + let (header_hash, rlp_transactions_root) = Self::calculate_execution_block_hash(payload); if header_hash != payload.block_hash() { return Err(Error::BlockHashMismatch { From d399961e6e45a76cc90a1b0ede839df1cdecb176 Mon Sep 17 00:00:00 2001 From: Pawan Dhananjay Date: Fri, 2 Jun 2023 03:17:38 +0000 Subject: [PATCH 16/18] Add an option to disable inbound rate limiter (#4327) ## Issue Addressed On deneb devnetv5, lighthouse keeps rate limiting peers which makes it harder to bootstrap new nodes as there are very few peers in the network. This PR adds an option to disable the inbound rate limiter for testnets. Added an option to configure inbound rate limits as well. Co-authored-by: Diva M --- beacon_node/lighthouse_network/src/config.rs | 6 +- .../lighthouse_network/src/rpc/config.rs | 51 ++++++-- beacon_node/lighthouse_network/src/rpc/mod.rs | 123 +++++++++--------- .../src/rpc/rate_limiter.rs | 47 +++---- .../src/rpc/self_limiter.rs | 23 +--- .../lighthouse_network/src/service/mod.rs | 1 + beacon_node/src/cli.rs | 18 ++- beacon_node/src/config.rs | 18 ++- lighthouse/tests/beacon_node.rs | 20 +++ 9 files changed, 189 insertions(+), 118 deletions(-) diff --git a/beacon_node/lighthouse_network/src/config.rs b/beacon_node/lighthouse_network/src/config.rs index 5a11890a2..01bb8569d 100644 --- a/beacon_node/lighthouse_network/src/config.rs +++ b/beacon_node/lighthouse_network/src/config.rs @@ -1,5 +1,5 @@ use crate::listen_addr::{ListenAddr, ListenAddress}; -use crate::rpc::config::OutboundRateLimiterConfig; +use crate::rpc::config::{InboundRateLimiterConfig, OutboundRateLimiterConfig}; use crate::types::GossipKind; use crate::{Enr, PeerIdSerialized}; use directory::{ @@ -148,6 +148,9 @@ pub struct Config { /// Configures if/where invalid blocks should be stored. pub invalid_block_storage: Option, + + /// Configuration for the inbound rate limiter (requests received by this node). + pub inbound_rate_limiter_config: Option, } impl Config { @@ -333,6 +336,7 @@ impl Default for Config { enable_light_client_server: false, outbound_rate_limiter_config: None, invalid_block_storage: None, + inbound_rate_limiter_config: None, } } } diff --git a/beacon_node/lighthouse_network/src/rpc/config.rs b/beacon_node/lighthouse_network/src/rpc/config.rs index bea0929fb..a0f3acaf7 100644 --- a/beacon_node/lighthouse_network/src/rpc/config.rs +++ b/beacon_node/lighthouse_network/src/rpc/config.rs @@ -58,18 +58,41 @@ impl FromStr for ProtocolQuota { } } -/// Configurations for the rate limiter applied to outbound requests (made by the node itself). +#[derive(Clone, Serialize, Deserialize, PartialEq, Eq, Debug, Default)] +pub struct OutboundRateLimiterConfig(pub RateLimiterConfig); + +#[derive(Clone, Serialize, Deserialize, PartialEq, Eq, Debug, Default)] +pub struct InboundRateLimiterConfig(pub RateLimiterConfig); + +impl FromStr for OutboundRateLimiterConfig { + type Err = &'static str; + + fn from_str(s: &str) -> Result { + RateLimiterConfig::from_str(s).map(Self) + } +} + +impl FromStr for InboundRateLimiterConfig { + type Err = &'static str; + + fn from_str(s: &str) -> Result { + RateLimiterConfig::from_str(s).map(Self) + } +} + +/// Configurations for the rate limiter. #[derive(Clone, Serialize, Deserialize, PartialEq, Eq)] -pub struct OutboundRateLimiterConfig { +pub struct RateLimiterConfig { pub(super) ping_quota: Quota, pub(super) meta_data_quota: Quota, pub(super) status_quota: Quota, pub(super) goodbye_quota: Quota, pub(super) blocks_by_range_quota: Quota, pub(super) blocks_by_root_quota: Quota, + pub(super) light_client_bootstrap_quota: Quota, } -impl OutboundRateLimiterConfig { +impl RateLimiterConfig { pub const DEFAULT_PING_QUOTA: Quota = Quota::n_every(2, 10); pub const DEFAULT_META_DATA_QUOTA: Quota = Quota::n_every(2, 5); pub const DEFAULT_STATUS_QUOTA: Quota = Quota::n_every(5, 15); @@ -77,22 +100,24 @@ impl OutboundRateLimiterConfig { pub const DEFAULT_BLOCKS_BY_RANGE_QUOTA: Quota = Quota::n_every(methods::MAX_REQUEST_BLOCKS, 10); pub const DEFAULT_BLOCKS_BY_ROOT_QUOTA: Quota = Quota::n_every(128, 10); + pub const DEFAULT_LIGHT_CLIENT_BOOTSTRAP_QUOTA: Quota = Quota::one_every(10); } -impl Default for OutboundRateLimiterConfig { +impl Default for RateLimiterConfig { fn default() -> Self { - OutboundRateLimiterConfig { + RateLimiterConfig { ping_quota: Self::DEFAULT_PING_QUOTA, meta_data_quota: Self::DEFAULT_META_DATA_QUOTA, status_quota: Self::DEFAULT_STATUS_QUOTA, goodbye_quota: Self::DEFAULT_GOODBYE_QUOTA, blocks_by_range_quota: Self::DEFAULT_BLOCKS_BY_RANGE_QUOTA, blocks_by_root_quota: Self::DEFAULT_BLOCKS_BY_ROOT_QUOTA, + light_client_bootstrap_quota: Self::DEFAULT_LIGHT_CLIENT_BOOTSTRAP_QUOTA, } } } -impl Debug for OutboundRateLimiterConfig { +impl Debug for RateLimiterConfig { fn fmt(&self, f: &mut std::fmt::Formatter<'_>) -> std::fmt::Result { macro_rules! fmt_q { ($quota:expr) => { @@ -104,7 +129,7 @@ impl Debug for OutboundRateLimiterConfig { }; } - f.debug_struct("OutboundRateLimiterConfig") + f.debug_struct("RateLimiterConfig") .field("ping", fmt_q!(&self.ping_quota)) .field("metadata", fmt_q!(&self.meta_data_quota)) .field("status", fmt_q!(&self.status_quota)) @@ -119,7 +144,7 @@ impl Debug for OutboundRateLimiterConfig { /// the default values. Protocol specified more than once use only the first given Quota. /// /// The expected format is a ';' separated list of [`ProtocolQuota`]. -impl FromStr for OutboundRateLimiterConfig { +impl FromStr for RateLimiterConfig { type Err = &'static str; fn from_str(s: &str) -> Result { @@ -129,6 +154,8 @@ impl FromStr for OutboundRateLimiterConfig { let mut goodbye_quota = None; let mut blocks_by_range_quota = None; let mut blocks_by_root_quota = None; + let mut light_client_bootstrap_quota = None; + for proto_def in s.split(';') { let ProtocolQuota { protocol, quota } = proto_def.parse()?; let quota = Some(quota); @@ -139,10 +166,12 @@ impl FromStr for OutboundRateLimiterConfig { Protocol::BlocksByRoot => blocks_by_root_quota = blocks_by_root_quota.or(quota), Protocol::Ping => ping_quota = ping_quota.or(quota), Protocol::MetaData => meta_data_quota = meta_data_quota.or(quota), - Protocol::LightClientBootstrap => return Err("Lighthouse does not send LightClientBootstrap requests. Quota should not be set."), + Protocol::LightClientBootstrap => { + light_client_bootstrap_quota = light_client_bootstrap_quota.or(quota) + } } } - Ok(OutboundRateLimiterConfig { + Ok(RateLimiterConfig { ping_quota: ping_quota.unwrap_or(Self::DEFAULT_PING_QUOTA), meta_data_quota: meta_data_quota.unwrap_or(Self::DEFAULT_META_DATA_QUOTA), status_quota: status_quota.unwrap_or(Self::DEFAULT_STATUS_QUOTA), @@ -151,6 +180,8 @@ impl FromStr for OutboundRateLimiterConfig { .unwrap_or(Self::DEFAULT_BLOCKS_BY_RANGE_QUOTA), blocks_by_root_quota: blocks_by_root_quota .unwrap_or(Self::DEFAULT_BLOCKS_BY_ROOT_QUOTA), + light_client_bootstrap_quota: light_client_bootstrap_quota + .unwrap_or(Self::DEFAULT_LIGHT_CLIENT_BOOTSTRAP_QUOTA), }) } } diff --git a/beacon_node/lighthouse_network/src/rpc/mod.rs b/beacon_node/lighthouse_network/src/rpc/mod.rs index 31569b820..4f7af95cf 100644 --- a/beacon_node/lighthouse_network/src/rpc/mod.rs +++ b/beacon_node/lighthouse_network/src/rpc/mod.rs @@ -17,7 +17,6 @@ use slog::{crit, debug, o}; use std::marker::PhantomData; use std::sync::Arc; use std::task::{Context, Poll}; -use std::time::Duration; use types::{EthSpec, ForkContext}; pub(crate) use handler::HandlerErr; @@ -32,7 +31,7 @@ pub use methods::{ pub(crate) use outbound::OutboundRequest; pub use protocol::{max_rpc_size, Protocol, RPCError}; -use self::config::OutboundRateLimiterConfig; +use self::config::{InboundRateLimiterConfig, OutboundRateLimiterConfig}; use self::self_limiter::SelfRateLimiter; pub(crate) mod codec; @@ -112,7 +111,7 @@ type BehaviourAction = /// logic. pub struct RPC { /// Rate limiter - limiter: RateLimiter, + limiter: Option, /// Rate limiter for our own requests. self_limiter: Option>, /// Queue of events to be processed. @@ -127,32 +126,24 @@ impl RPC { pub fn new( fork_context: Arc, enable_light_client_server: bool, + inbound_rate_limiter_config: Option, outbound_rate_limiter_config: Option, log: slog::Logger, ) -> Self { let log = log.new(o!("service" => "libp2p_rpc")); - let limiter = RateLimiter::builder() - .n_every(Protocol::MetaData, 2, Duration::from_secs(5)) - .n_every(Protocol::Ping, 2, Duration::from_secs(10)) - .n_every(Protocol::Status, 5, Duration::from_secs(15)) - .one_every(Protocol::Goodbye, Duration::from_secs(10)) - .one_every(Protocol::LightClientBootstrap, Duration::from_secs(10)) - .n_every( - Protocol::BlocksByRange, - methods::MAX_REQUEST_BLOCKS, - Duration::from_secs(10), - ) - .n_every(Protocol::BlocksByRoot, 128, Duration::from_secs(10)) - .build() - .expect("Configuration parameters are valid"); + let inbound_limiter = inbound_rate_limiter_config.map(|config| { + debug!(log, "Using inbound rate limiting params"; "config" => ?config); + RateLimiter::new_with_config(config.0) + .expect("Inbound limiter configuration parameters are valid") + }); let self_limiter = outbound_rate_limiter_config.map(|config| { SelfRateLimiter::new(config, log.clone()).expect("Configuration parameters are valid") }); RPC { - limiter, + limiter: inbound_limiter, self_limiter, events: Vec::new(), fork_context, @@ -242,50 +233,60 @@ where event: ::OutEvent, ) { if let Ok(RPCReceived::Request(ref id, ref req)) = event { - // check if the request is conformant to the quota - match self.limiter.allows(&peer_id, req) { - Ok(()) => { - // send the event to the user - self.events - .push(NetworkBehaviourAction::GenerateEvent(RPCMessage { - peer_id, - conn_id, - event, - })) - } - Err(RateLimitedErr::TooLarge) => { - // we set the batch sizes, so this is a coding/config err for most protocols - let protocol = req.protocol(); - if matches!(protocol, Protocol::BlocksByRange) { - debug!(self.log, "Blocks by range request will never be processed"; "request" => %req); - } else { - crit!(self.log, "Request size too large to ever be processed"; "protocol" => %protocol); + if let Some(limiter) = self.limiter.as_mut() { + // check if the request is conformant to the quota + match limiter.allows(&peer_id, req) { + Ok(()) => { + // send the event to the user + self.events + .push(NetworkBehaviourAction::GenerateEvent(RPCMessage { + peer_id, + conn_id, + event, + })) } - // send an error code to the peer. - // the handler upon receiving the error code will send it back to the behaviour - self.send_response( - peer_id, - (conn_id, *id), - RPCCodedResponse::Error( - RPCResponseErrorCode::RateLimited, - "Rate limited. Request too large".into(), - ), - ); - } - Err(RateLimitedErr::TooSoon(wait_time)) => { - debug!(self.log, "Request exceeds the rate limit"; + Err(RateLimitedErr::TooLarge) => { + // we set the batch sizes, so this is a coding/config err for most protocols + let protocol = req.protocol(); + if matches!(protocol, Protocol::BlocksByRange) { + debug!(self.log, "Blocks by range request will never be processed"; "request" => %req); + } else { + crit!(self.log, "Request size too large to ever be processed"; "protocol" => %protocol); + } + // send an error code to the peer. + // the handler upon receiving the error code will send it back to the behaviour + self.send_response( + peer_id, + (conn_id, *id), + RPCCodedResponse::Error( + RPCResponseErrorCode::RateLimited, + "Rate limited. Request too large".into(), + ), + ); + } + Err(RateLimitedErr::TooSoon(wait_time)) => { + debug!(self.log, "Request exceeds the rate limit"; "request" => %req, "peer_id" => %peer_id, "wait_time_ms" => wait_time.as_millis()); - // send an error code to the peer. - // the handler upon receiving the error code will send it back to the behaviour - self.send_response( - peer_id, - (conn_id, *id), - RPCCodedResponse::Error( - RPCResponseErrorCode::RateLimited, - format!("Wait {:?}", wait_time).into(), - ), - ); + // send an error code to the peer. + // the handler upon receiving the error code will send it back to the behaviour + self.send_response( + peer_id, + (conn_id, *id), + RPCCodedResponse::Error( + RPCResponseErrorCode::RateLimited, + format!("Wait {:?}", wait_time).into(), + ), + ); + } } + } else { + // No rate limiting, send the event to the user + self.events + .push(NetworkBehaviourAction::GenerateEvent(RPCMessage { + peer_id, + conn_id, + event, + })) } } else { self.events @@ -303,7 +304,9 @@ where _: &mut impl PollParameters, ) -> Poll> { // let the rate limiter prune. - let _ = self.limiter.poll_unpin(cx); + if let Some(limiter) = self.limiter.as_mut() { + let _ = limiter.poll_unpin(cx); + } if let Some(self_limiter) = self.self_limiter.as_mut() { if let Poll::Ready(event) = self_limiter.poll_ready(cx) { diff --git a/beacon_node/lighthouse_network/src/rpc/rate_limiter.rs b/beacon_node/lighthouse_network/src/rpc/rate_limiter.rs index a1f7b89a2..1fdc6cce3 100644 --- a/beacon_node/lighthouse_network/src/rpc/rate_limiter.rs +++ b/beacon_node/lighthouse_network/src/rpc/rate_limiter.rs @@ -1,3 +1,4 @@ +use super::config::RateLimiterConfig; use crate::rpc::Protocol; use fnv::FnvHashMap; use libp2p::PeerId; @@ -141,29 +142,6 @@ impl RPCRateLimiterBuilder { self } - /// Allow one token every `time_period` to be used for this `protocol`. - /// This produces a hard limit. - pub fn one_every(self, protocol: Protocol, time_period: Duration) -> Self { - self.set_quota( - protocol, - Quota { - replenish_all_every: time_period, - max_tokens: 1, - }, - ) - } - - /// Allow `n` tokens to be use used every `time_period` for this `protocol`. - pub fn n_every(self, protocol: Protocol, n: u64, time_period: Duration) -> Self { - self.set_quota( - protocol, - Quota { - max_tokens: n, - replenish_all_every: time_period, - }, - ) - } - pub fn build(self) -> Result { // get our quotas let ping_quota = self.ping_quota.ok_or("Ping quota not specified")?; @@ -232,6 +210,29 @@ impl RateLimiterItem for super::OutboundRequest { } } impl RPCRateLimiter { + pub fn new_with_config(config: RateLimiterConfig) -> Result { + // Destructure to make sure every configuration value is used. + let RateLimiterConfig { + ping_quota, + meta_data_quota, + status_quota, + goodbye_quota, + blocks_by_range_quota, + blocks_by_root_quota, + light_client_bootstrap_quota, + } = config; + + Self::builder() + .set_quota(Protocol::Ping, ping_quota) + .set_quota(Protocol::MetaData, meta_data_quota) + .set_quota(Protocol::Status, status_quota) + .set_quota(Protocol::Goodbye, goodbye_quota) + .set_quota(Protocol::BlocksByRange, blocks_by_range_quota) + .set_quota(Protocol::BlocksByRoot, blocks_by_root_quota) + .set_quota(Protocol::LightClientBootstrap, light_client_bootstrap_quota) + .build() + } + /// Get a builder instance. pub fn builder() -> RPCRateLimiterBuilder { RPCRateLimiterBuilder::default() diff --git a/beacon_node/lighthouse_network/src/rpc/self_limiter.rs b/beacon_node/lighthouse_network/src/rpc/self_limiter.rs index 451c6206f..6748a1947 100644 --- a/beacon_node/lighthouse_network/src/rpc/self_limiter.rs +++ b/beacon_node/lighthouse_network/src/rpc/self_limiter.rs @@ -52,28 +52,7 @@ impl SelfRateLimiter { /// Creates a new [`SelfRateLimiter`] based on configration values. pub fn new(config: OutboundRateLimiterConfig, log: Logger) -> Result { debug!(log, "Using self rate limiting params"; "config" => ?config); - // Destructure to make sure every configuration value is used. - let OutboundRateLimiterConfig { - ping_quota, - meta_data_quota, - status_quota, - goodbye_quota, - blocks_by_range_quota, - blocks_by_root_quota, - } = config; - - let limiter = RateLimiter::builder() - .set_quota(Protocol::Ping, ping_quota) - .set_quota(Protocol::MetaData, meta_data_quota) - .set_quota(Protocol::Status, status_quota) - .set_quota(Protocol::Goodbye, goodbye_quota) - .set_quota(Protocol::BlocksByRange, blocks_by_range_quota) - .set_quota(Protocol::BlocksByRoot, blocks_by_root_quota) - // Manually set the LightClientBootstrap quota, since we use the same rate limiter for - // inbound and outbound requests, and the LightClientBootstrap is an only inbound - // protocol. - .one_every(Protocol::LightClientBootstrap, Duration::from_secs(10)) - .build()?; + let limiter = RateLimiter::new_with_config(config.0)?; Ok(SelfRateLimiter { delayed_requests: Default::default(), diff --git a/beacon_node/lighthouse_network/src/service/mod.rs b/beacon_node/lighthouse_network/src/service/mod.rs index f815e3bd3..34d5a5631 100644 --- a/beacon_node/lighthouse_network/src/service/mod.rs +++ b/beacon_node/lighthouse_network/src/service/mod.rs @@ -266,6 +266,7 @@ impl Network { let eth2_rpc = RPC::new( ctx.fork_context.clone(), config.enable_light_client_server, + config.inbound_rate_limiter_config.clone(), config.outbound_rate_limiter_config.clone(), log.clone(), ); diff --git a/beacon_node/src/cli.rs b/beacon_node/src/cli.rs index 59a5f4b2e..10d9ffafd 100644 --- a/beacon_node/src/cli.rs +++ b/beacon_node/src/cli.rs @@ -282,7 +282,23 @@ pub fn cli_app<'a, 'b>() -> App<'a, 'b> { for a beacon node being referenced by validator client using the --proposer-node flag. This configuration is for enabling more secure setups.") .takes_value(false), ) - + .arg( + Arg::with_name("inbound-rate-limiter") + .long("inbound-rate-limiter") + .help( + "Configures the inbound rate limiter (requests received by this node).\ + \ + Rate limit quotas per protocol can be set in the form of \ + :/. To set quotas for multiple protocols, \ + separate them by ';'. If the inbound rate limiter is enabled and a protocol is not \ + present in the configuration, the default quotas will be used. \ + \ + This is enabled by default, using default quotas. To disable rate limiting pass \ + `disabled` to this option instead." + ) + .takes_value(true) + .hidden(true) + ) .arg( Arg::with_name("disable-backfill-rate-limiting") .long("disable-backfill-rate-limiting") diff --git a/beacon_node/src/config.rs b/beacon_node/src/config.rs index 6f626bee8..92e822819 100644 --- a/beacon_node/src/config.rs +++ b/beacon_node/src/config.rs @@ -1232,6 +1232,7 @@ pub fn set_network_config( // Light client server config. config.enable_light_client_server = cli_args.is_present("light-client-server"); + // The self limiter is disabled by default. // This flag can be used both with or without a value. Try to parse it first with a value, if // no value is defined but the flag is present, use the default params. config.outbound_rate_limiter_config = clap_utils::parse_optional(cli_args, "self-limiter")?; @@ -1252,7 +1253,22 @@ pub fn set_network_config( config.proposer_only = true; warn!(log, "Proposer-only mode enabled"; "info"=> "Do not connect a validator client to this node unless via the --proposer-nodes flag"); } - + // The inbound rate limiter is enabled by default unless `disabled` is passed to the + // `inbound-rate-limiter` flag. Any other value should be parsed as a configuration string. + config.inbound_rate_limiter_config = match cli_args.value_of("inbound-rate-limiter") { + None => { + // Enabled by default, with default values + Some(Default::default()) + } + Some("disabled") => { + // Explicitly disabled + None + } + Some(config_str) => { + // Enabled with a custom configuration + Some(config_str.parse()?) + } + }; Ok(()) } diff --git a/lighthouse/tests/beacon_node.rs b/lighthouse/tests/beacon_node.rs index 75bcccc9d..73520dd6b 100644 --- a/lighthouse/tests/beacon_node.rs +++ b/lighthouse/tests/beacon_node.rs @@ -1451,6 +1451,26 @@ fn empty_self_limiter_flag() { ) }); } + +#[test] +fn empty_inbound_rate_limiter_flag() { + CommandLineTest::new() + .run_with_zero_port() + .with_config(|config| { + assert_eq!( + config.network.inbound_rate_limiter_config, + Some(lighthouse_network::rpc::config::InboundRateLimiterConfig::default()) + ) + }); +} +#[test] +fn disable_inbound_rate_limiter_flag() { + CommandLineTest::new() + .flag("inbound-rate-limiter", Some("disabled")) + .run_with_zero_port() + .with_config(|config| assert_eq!(config.network.inbound_rate_limiter_config, None)); +} + #[test] fn http_allow_origin_flag() { CommandLineTest::new() From 4af4e98c829ce3d27db22dc02842c7b48f22c217 Mon Sep 17 00:00:00 2001 From: Michael Sproul Date: Fri, 2 Jun 2023 03:17:39 +0000 Subject: [PATCH 17/18] Update Nethermind (#4361) ## Issue Addressed Nethermind integration tests are failing with a compilation error: https://github.com/sigp/lighthouse/actions/runs/5138586473/jobs/9248079945 This PR updates Nethermind to the latest release to hopefully fix that --- testing/execution_engine_integration/src/nethermind.rs | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/testing/execution_engine_integration/src/nethermind.rs b/testing/execution_engine_integration/src/nethermind.rs index 485485c6f..8925f1cc8 100644 --- a/testing/execution_engine_integration/src/nethermind.rs +++ b/testing/execution_engine_integration/src/nethermind.rs @@ -11,7 +11,7 @@ use unused_port::unused_tcp4_port; /// We've pinned the Nethermind version since our method of using the `master` branch to /// find the latest tag isn't working. It appears Nethermind don't always tag on `master`. /// We should fix this so we always pull the latest version of Nethermind. -const NETHERMIND_BRANCH: &str = "release/1.17.1"; +const NETHERMIND_BRANCH: &str = "release/1.18.2"; const NETHERMIND_REPO_URL: &str = "https://github.com/NethermindEth/nethermind"; fn build_result(repo_dir: &Path) -> Output { From d07c78bccf20795de89ed9ba3aae9c4dc81d9e32 Mon Sep 17 00:00:00 2001 From: Paul Hauner Date: Fri, 2 Jun 2023 03:17:40 +0000 Subject: [PATCH 18/18] Appease clippy in Rust 1.70 (#4365) ## Issue Addressed NA ## Proposed Changes Fixes some new clippy lints raised after updating to Rust 1.70. ## Additional Info NA --- beacon_node/client/src/builder.rs | 2 +- beacon_node/http_metrics/tests/tests.rs | 2 +- .../lighthouse_network/src/discovery/subnet_predicate.rs | 2 +- common/lru_cache/src/time.rs | 2 +- validator_client/src/lib.rs | 4 ++-- 5 files changed, 6 insertions(+), 6 deletions(-) diff --git a/beacon_node/client/src/builder.rs b/beacon_node/client/src/builder.rs index 215244b9b..e05b92a27 100644 --- a/beacon_node/client/src/builder.rs +++ b/beacon_node/client/src/builder.rs @@ -742,7 +742,7 @@ where runtime_context .executor - .spawn_without_exit(async move { server.await }, "http-metrics"); + .spawn_without_exit(server, "http-metrics"); Some(listen_addr) } else { diff --git a/beacon_node/http_metrics/tests/tests.rs b/beacon_node/http_metrics/tests/tests.rs index 89fde3237..b88a790af 100644 --- a/beacon_node/http_metrics/tests/tests.rs +++ b/beacon_node/http_metrics/tests/tests.rs @@ -38,7 +38,7 @@ async fn returns_200_ok() { }; let (listening_socket, server) = http_metrics::serve(ctx, server_shutdown).unwrap(); - tokio::spawn(async { server.await }); + tokio::spawn(server); let url = format!( "http://{}:{}/metrics", diff --git a/beacon_node/lighthouse_network/src/discovery/subnet_predicate.rs b/beacon_node/lighthouse_network/src/discovery/subnet_predicate.rs index e324532f7..f79ff8daf 100644 --- a/beacon_node/lighthouse_network/src/discovery/subnet_predicate.rs +++ b/beacon_node/lighthouse_network/src/discovery/subnet_predicate.rs @@ -1,4 +1,4 @@ -///! The subnet predicate used for searching for a particular subnet. +//! The subnet predicate used for searching for a particular subnet. use super::*; use crate::types::{EnrAttestationBitfield, EnrSyncCommitteeBitfield}; use slog::trace; diff --git a/common/lru_cache/src/time.rs b/common/lru_cache/src/time.rs index 7b8e9ba9a..966741ca4 100644 --- a/common/lru_cache/src/time.rs +++ b/common/lru_cache/src/time.rs @@ -1,4 +1,4 @@ -///! This implements a time-based LRU cache for fast checking of duplicates +//! This implements a time-based LRU cache for fast checking of duplicates use fnv::FnvHashSet; use std::collections::VecDeque; use std::time::{Duration, Instant}; diff --git a/validator_client/src/lib.rs b/validator_client/src/lib.rs index 3dde49f22..6e4a8da6a 100644 --- a/validator_client/src/lib.rs +++ b/validator_client/src/lib.rs @@ -146,7 +146,7 @@ impl ProductionValidatorClient { context .clone() .executor - .spawn_without_exit(async move { server.await }, "metrics-api"); + .spawn_without_exit(server, "metrics-api"); Some(ctx) } else { @@ -590,7 +590,7 @@ impl ProductionValidatorClient { self.context .clone() .executor - .spawn_without_exit(async move { server.await }, "http-api"); + .spawn_without_exit(server, "http-api"); Some(listen_addr) } else {