From b08d0ff2ab7980576b8b3d961669ca3a7142230b Mon Sep 17 00:00:00 2001 From: Jacek Sieka Date: Wed, 26 Oct 2022 22:44:45 +0200 Subject: [PATCH] Optimistic mode (#4262) In optimistic mode, Nimbus will sync optimistically even when the execution client is offline / not available. An optimistic node is less secure because it has not validated block transactions via the execution client and can thus not be used for validation duties. --- beacon_chain/conf.nim | 5 ++++ .../gossip_processing/block_processor.nim | 13 ++++++--- beacon_chain/nimbus_beacon_node.nim | 3 ++- docs/the_nimbus_book/mkdocs.yml | 1 + docs/the_nimbus_book/src/eth1.md | 4 +-- .../src/external-block-builder.md | 2 +- docs/the_nimbus_book/src/faq.md | 4 +++ docs/the_nimbus_book/src/keep-an-eye.md | 19 +++++++------ docs/the_nimbus_book/src/optimistic-sync.md | 27 +++++++++++++++++++ docs/the_nimbus_book/src/options.md | 2 ++ 10 files changed, 63 insertions(+), 17 deletions(-) create mode 100644 docs/the_nimbus_book/src/optimistic-sync.md diff --git a/beacon_chain/conf.nim b/beacon_chain/conf.nim index bbb6c553d..6b05dd3df 100644 --- a/beacon_chain/conf.nim +++ b/beacon_chain/conf.nim @@ -179,6 +179,11 @@ type desc: "Force the use of polling when determining the head block of Eth1" name: "web3-force-polling" .}: bool + optimistic* {. + defaultValue: false + desc: "Run the node in optimistic mode, allowing it to optimistically sync without an execution client" + name: "optimistic".}: bool + requireEngineAPI* {. hidden # Deprecated > 22.9 desc: "Require Nimbus to be configured with an Engine API end-point after the Bellatrix fork epoch" diff --git a/beacon_chain/gossip_processing/block_processor.nim b/beacon_chain/gossip_processing/block_processor.nim index fb725a451..450f6f8a7 100644 --- a/beacon_chain/gossip_processing/block_processor.nim +++ b/beacon_chain/gossip_processing/block_processor.nim @@ -85,6 +85,10 @@ type verifier: BatchVerifier + optimistic: bool + ## Run block processor in optimistic mode allowing it to progress even + ## though execution client is offline + NewPayloadStatus {.pure.} = enum valid notValid @@ -109,7 +113,8 @@ proc new*(T: type BlockProcessor, rng: ref HmacDrbgContext, taskpool: TaskPoolPtr, consensusManager: ref ConsensusManager, validatorMonitor: ref ValidatorMonitor, - getBeaconTime: GetBeaconTimeFn): ref BlockProcessor = + getBeaconTime: GetBeaconTimeFn, + optimistic: bool = false): ref BlockProcessor = (ref BlockProcessor)( dumpEnabled: dumpEnabled, dumpDirInvalid: dumpDirInvalid, @@ -118,7 +123,8 @@ proc new*(T: type BlockProcessor, consensusManager: consensusManager, validatorMonitor: validatorMonitor, getBeaconTime: getBeaconTime, - verifier: BatchVerifier(rng: rng, taskpool: taskpool) + verifier: BatchVerifier(rng: rng, taskpool: taskpool), + optimistic: optimistic ) # Sync callbacks @@ -322,7 +328,8 @@ proc storeBlock*( if NewPayloadStatus.invalid == payloadStatus: self.consensusManager.quarantine[].addUnviable(signedBlock.root) return err((BlockError.UnviableFork, BlockProcessingCompleted.completed)) - elif NewPayloadStatus.noResponse == payloadStatus: + + if NewPayloadStatus.noResponse == payloadStatus and not self[].optimistic: # Disallow the `MissingParent` from leaking to the sync/request managers # as it will be descored. However sync and request managers interact via # `processBlock` (indirectly). `validator_duties` does call `storeBlock` diff --git a/beacon_chain/nimbus_beacon_node.nim b/beacon_chain/nimbus_beacon_node.nim index 04bd97fd1..a6c48f56e 100644 --- a/beacon_chain/nimbus_beacon_node.nim +++ b/beacon_chain/nimbus_beacon_node.nim @@ -300,7 +300,8 @@ proc initFullNode( config.defaultFeeRecipient) blockProcessor = BlockProcessor.new( config.dumpEnabled, config.dumpDirInvalid, config.dumpDirIncoming, - rng, taskpool, consensusManager, node.validatorMonitor, getBeaconTime) + rng, taskpool, consensusManager, node.validatorMonitor, getBeaconTime, + optimistic = config.optimistic) blockVerifier = proc(signedBlock: ForkedSignedBeaconBlock): Future[Result[void, BlockError]] = # The design with a callback for block verification is unusual compared diff --git a/docs/the_nimbus_book/mkdocs.yml b/docs/the_nimbus_book/mkdocs.yml index 8526fc995..dd8861857 100644 --- a/docs/the_nimbus_book/mkdocs.yml +++ b/docs/the_nimbus_book/mkdocs.yml @@ -91,6 +91,7 @@ nav: - 'hardware.md' - 'options.md' - 'networking.md' + - 'optimistic-sync.md' - 'logging.md' - 'validator-monitor.md' - 'attestation-performance.md' diff --git a/docs/the_nimbus_book/src/eth1.md b/docs/the_nimbus_book/src/eth1.md index 2305691aa..497dd91cb 100644 --- a/docs/the_nimbus_book/src/eth1.md +++ b/docs/the_nimbus_book/src/eth1.md @@ -1,11 +1,11 @@ # Run an execution client -In order to run a beacon node, you need to also be running an execution client - one for each beacon node. +In order to run a beacon node, you need to also be running an execution client - at least one for each beacon node. Nimbus has been tested all major execution clients - see the [execution client comparison](https://ethereum.org/en/developers/docs/nodes-and-clients/#execution-clients) for more information. !!! warning - You need to run your own execution client - relying on third-party services such as Infura, Alchemy and Pocket will not be possible. + You need to run your own execution client - relying on third-party services such as Infura, Alchemy and Pocket is no longer possible. !!! info Syncing an execution client may take hours or even days, depending on your hardware! The backup providers will be synced only when the primary becomes unavailable, which may lead to a small gap in validation duties - this limitation may be lifted in future versions. diff --git a/docs/the_nimbus_book/src/external-block-builder.md b/docs/the_nimbus_book/src/external-block-builder.md index c6ce74831..be4b205df 100644 --- a/docs/the_nimbus_book/src/external-block-builder.md +++ b/docs/the_nimbus_book/src/external-block-builder.md @@ -1,4 +1,4 @@ -# Set up block builders +# Set up block builders / MEV [Maximal extractable value](https://ethereum.org/en/developers/docs/mev/) involves consensus clients contacting an external block builder which might maximize profit or some other defined metric in ways hindered for a purely local consensus and execution client setup. This external builder network uses the [builder API](https://ethereum.github.io/builder-specs/) which consensus clients use to access external block builder bundles found by searchers. In exchange, such searchers and builders might choose to retain some of the profit gained from such bundles. A builder API relay provides access to multiple searchers via a single URL. diff --git a/docs/the_nimbus_book/src/faq.md b/docs/the_nimbus_book/src/faq.md index 6d8a83b48..99255dbb2 100644 --- a/docs/the_nimbus_book/src/faq.md +++ b/docs/the_nimbus_book/src/faq.md @@ -58,6 +58,10 @@ To add an additional validator, follow [the same steps](./keys.md) as you did wh !!! note Note that a single Nimbus instance is able to handle multiple validators. +### What does `synced/opt` mean, in the "Slot start" message? + +When `/opt` is present in the "Slot start" message, it means the node is [optimistically synced](./optimistic-sync.md) and is waiting for the execution client to finish its syncing process - until that happens, validator duties are disabled. + ## Networking ### How can I improve my peer count? diff --git a/docs/the_nimbus_book/src/keep-an-eye.md b/docs/the_nimbus_book/src/keep-an-eye.md index eb856fe80..5281857c5 100644 --- a/docs/the_nimbus_book/src/keep-an-eye.md +++ b/docs/the_nimbus_book/src/keep-an-eye.md @@ -1,21 +1,18 @@ # Keep an eye on your validator -The best way to keep track of your validator's status is using the `beaconcha.in` explorer (click on the orange magnifying glass at the very top and paste in your validator's public key): +Once your validator has been activated, you can set up [validator monitoring](./validator-monitor.md) together with a [dashboard](./metrics-pretty-pictures.md) to keep track of its performance. - - **Mainnet:** [beaconcha.in](https://beaconcha.in/) - - **Prater:** [prater.beaconcha.in](https://prater.beaconcha.in) +Another way of keeping track is using an online service such as beaconcha.in - [Mainnet](https://beaconcha.in/) or [Prater](https://prater.beaconcha.in). -When you make a deposit, your validator(s) will be put in a queue based on deposit time, and will slowly be inducted into the validator set. Getting through the queue may take up to a few days, depending on the length of the deposit queue. +Both online services and dashboards allow setting up alerts for when the validator is offline. -You can even create an account ([testnet link](https://prater.beaconcha.in/register), [mainnet link](https://beaconcha.in/register)) to add alerts and keep track of your validator's performance ([testnet link](https://prater.beaconcha.in/dashboard), [mainnet link](https://beaconcha.in/dashboard)). +## Troubleshooting -------------------------------- - -## Make sure your validator is attached +### Make sure your validator is attached On startup, you should see a log message that reads `Local validator attached`. This has a `pubkey` field which should the public key of your validator. -## Keep track of your syncing progress +### Keep track of your syncing progress To keep track of your sync progress, pay attention to the `Slot start` messages in your logs: @@ -36,7 +33,9 @@ Where: - `slot` is the current time on the beacon chain, measured in "slots" - `epoch` shows the current epoch - each epoch has 32 slots, and each validator performs one attestation per epoch - `peers` tells you how many peers you're currently connected to - depending on the number of attached validators, you may need anywhere from 10 to 60 peers connected -- `sync` tells you if your client is synced and can perform duties, or how long it will take to get there - in the case of [trusted node sync](./trusted-node-sync.md) it may also show `backfill` in which case duties are being performed but more bandwidth than usual is being used to download historical blocks +- `sync` tells you if your client is synced and can perform duties, or how long it will take to get there + - `/opt` means that the node is [optimistically synced](./optimistic-sync.md) - it is waiting for the execution client to finish syncing + - in the case of [trusted node sync](./trusted-node-sync.md) it may also show `backfill` in which case duties are being performed but more bandwidth than usual is being used to download historical blocks - `head` tells you the most recent block you've synced to so far (`5d59aba3` is the first part of the block hash, `4021234` is the slot number) - `finalized` tells you the most recent finalized epoch you've synced to so far (`125661` is the epoch, `82616f78` is the checkpoint hash) diff --git a/docs/the_nimbus_book/src/optimistic-sync.md b/docs/the_nimbus_book/src/optimistic-sync.md new file mode 100644 index 000000000..25585c3a0 --- /dev/null +++ b/docs/the_nimbus_book/src/optimistic-sync.md @@ -0,0 +1,27 @@ +# Optimistic sync + +Optimistic sync is the process of syncing an execution and consensus client concurrently, without having the consensus client wait for the execution client. During optimistic sync, the consensus client quickly syncs up to the latest conesensus but delays verifying block execution payloads - it continuously informs the execution client of the latest consensus head, allowing the execution client to perform a snapshot sync directly to the latest state. + +Once the execution client has caught up, the consensus and execution clients work in lock-step each validating the block. + +Both execution and consensus clients must be fully synced to perform validation duties - while optimistically synced, validator duties (attestation, sync committee and block production work) are skipped. + +## Identifying optimistic sync + +An optimistically synced node can be identified by examining the "Slot start" log message - when optimistically synced, the `sync` key will have a `/opt` suffix, indicating that it's waiting for the execution client to catch up: + +``` +INF 2022-10-26 18:57:35.000+02:00 Slot start topics="beacnde" slot=4998286 epoch=156196 sync=synced/opt peers=29 head=f21d399e:4998285 finalized=156194:91e2ebaf delay=467us953ns +``` + +## Optimistic mode + +In "optimistic" mode, Nimbus will start syncing optimistically without an execution client present, as normally required: + +```sh +# Start in optimistic mode which allows syncing the beacon chain without an execution client, albeit with reduced security and functionality +./run-mainnet-beacon-node.sh --optimistic +``` + +!!! warning + An optimistically synced node is less secure than a fully synced node: it has not validated that the transactions in blocks received from the network are valid - as such, it is not suitable for validation duties (where block contents have not yet been validated by a supermajority of validators) and may be unsuitable for other uses. diff --git a/docs/the_nimbus_book/src/options.md b/docs/the_nimbus_book/src/options.md index 7892604a9..99b436f64 100644 --- a/docs/the_nimbus_book/src/options.md +++ b/docs/the_nimbus_book/src/options.md @@ -35,6 +35,8 @@ The following options are available: --secrets-dir A directory containing validator keystore passwords. --wallets-dir A directory containing wallet files. --web3-url One or more execution layer Web3 provider URLs. + --optimistic Run the node in optimistic mode, allowing it to optimistically sync without an + execution client [=false]. --non-interactive Do not display interative prompts. Quit on missing configuration. --netkey-file Source of network (secp256k1) private key file (random|) [=random]. --insecure-netkey-password Use pre-generated INSECURE password for network private key file [=false].