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

@@ -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"

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`

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

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'

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.

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.
 

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?

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)
 

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.

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|<path>) [=random].
      --insecure-netkey-password  Use pre-generated INSECURE password for network private key file [=false].