Merge branch 'unstable' into prev-randao-rename

README.md

@@ -1,6 +1,6 @@
-# Lighthouse: Ethereum 2.0
+# Lighthouse: Ethereum consensus client
 
-An open-source Ethereum 2.0 client, written in Rust and maintained by Sigma Prime.
+An open-source Ethereum consensus client, written in Rust and maintained by Sigma Prime.
 
 [![Build Status]][Build Link] [![Book Status]][Book Link] [![Chat Badge]][Chat Link]
 
@@ -22,21 +22,21 @@ An open-source Ethereum 2.0 client, written in Rust and maintained by Sigma Prim
 
 Lighthouse is:
 
-- Ready for use on Eth2 mainnet.
+- Ready for use on Ethereum consensus mainnet.
 - Fully open-source, licensed under Apache 2.0.
 - Security-focused. Fuzzing techniques have been continuously applied and several external security reviews have been performed.
 - Built in [Rust](https://www.rust-lang.org), a modern language providing unique safety guarantees and
 	excellent performance (comparable to C++).
 - Funded by various organisations, including Sigma Prime, the
 	Ethereum Foundation, ConsenSys, the Decentralization Foundation and private individuals.
 - Actively involved in the specification and security analysis of the
-	Ethereum 2.0 specification.
+	Ethereum proof-of-stake consensus specification.
 
-## Eth2 Deposit Contract
+## Staking Deposit Contract
 
 The Lighthouse team acknowledges
 [`0x00000000219ab540356cBB839Cbe05303d7705Fa`](https://etherscan.io/address/0x00000000219ab540356cbb839cbe05303d7705fa)
-as the canonical Eth2 deposit contract address.
+as the canonical staking deposit contract address.
 
 ## Documentation
 
@@ -66,7 +66,7 @@ of the Lighthouse book.
 ## Contact
 
 The best place for discussion is the [Lighthouse Discord
-server](https://discord.gg/cyAszAh). 
+server](https://discord.gg/cyAszAh).
 
 Sign up to the [Lighthouse Development Updates](http://eepurl.com/dh9Lvb) mailing list for email
 notifications about releases, network status and other important information.

beacon_node/beacon_chain/src/block_verification.rs

@@ -312,6 +312,8 @@ pub enum ExecutionPayloadError {
     ///
     /// The peer is not necessarily invalid.
     PoWParentMissing(ExecutionBlockHash),
+    /// The execution node is syncing but we fail the conditions for optimistic sync
+    UnverifiedNonOptimisticCandidate,
 }
 
 impl From<execution_layer::Error> for ExecutionPayloadError {
@@ -1128,6 +1130,29 @@ impl<'a, T: BeaconChainTypes> FullyVerifiedBlock<'a, T> {
         // `randao` may change.
         let payload_verification_status = notify_new_payload(chain, &state, block.message())?;
 
+        // If the payload did not validate or invalidate the block, check to see if this block is
+        // valid for optimistic import.
+        if payload_verification_status == PayloadVerificationStatus::NotVerified {
+            let current_slot = chain
+                .slot_clock
+                .now()
+                .ok_or(BeaconChainError::UnableToReadSlot)?;
+
+            if !chain
+                .fork_choice
+                .read()
+                .is_optimistic_candidate_block(
+                    current_slot,
+                    block.slot(),
+                    &block.parent_root(),
+                    &chain.spec,
+                )
+                .map_err(BeaconChainError::from)?
+            {
+                return Err(ExecutionPayloadError::UnverifiedNonOptimisticCandidate.into());
+            }
+        }
+
         // If the block is sufficiently recent, notify the validator monitor.
         if let Some(slot) = chain.slot_clock.now() {
             let epoch = slot.epoch(T::EthSpec::slots_per_epoch());

beacon_node/beacon_chain/src/execution_payload.rs

@@ -141,13 +141,25 @@ pub fn validate_merge_block<T: BeaconChainTypes>(
         }
         .into()),
         None => {
-            debug!(
-                chain.log,
-                "Optimistically accepting terminal block";
-                "block_hash" => ?execution_payload.parent_hash,
-                "msg" => "the terminal block/parent was unavailable"
-            );
-            Ok(())
+            let current_slot = chain
+                .slot_clock
+                .now()
+                .ok_or(BeaconChainError::UnableToReadSlot)?;
+            // Check the optimistic sync conditions. Note that because this is the merge block,
+            // the justified checkpoint can't have execution enabled so we only need to check the
+            // current slot is at least SAFE_SLOTS_TO_IMPORT_OPTIMISTICALLY ahead of the block
+            // https://github.com/ethereum/consensus-specs/blob/v1.1.9/sync/optimistic.md#when-to-optimistically-import-blocks
+            if block.slot() + chain.spec.safe_slots_to_import_optimistically <= current_slot {
+                debug!(
+                    chain.log,
+                    "Optimistically accepting terminal block";
+                    "block_hash" => ?execution_payload.parent_hash,
+                    "msg" => "the terminal block/parent was unavailable"
+                );
+                Ok(())
+            } else {
+                Err(ExecutionPayloadError::UnverifiedNonOptimisticCandidate.into())
+            }
         }
     }
 }

beacon_node/network/src/beacon_processor/worker/gossip_methods.rs

@@ -772,6 +772,7 @@ impl<T: BeaconChainTypes> Worker<T> {
             }
             // TODO(merge): reconsider peer scoring for this event.
             Err(e @BlockError::ExecutionPayloadError(ExecutionPayloadError::RequestFailed(_)))
+            | Err(e @ BlockError::ExecutionPayloadError(ExecutionPayloadError::UnverifiedNonOptimisticCandidate))
             | Err(e @BlockError::ExecutionPayloadError(ExecutionPayloadError::NoExecutionConnection)) => {
                 debug!(self.log, "Could not verify block for gossip, ignoring the block";
                             "error" => %e);

beacon_node/src/cli.rs

@@ -93,7 +93,7 @@ pub fn cli_app<'a, 'b>() -> App<'a, 'b> {
             Arg::with_name("target-peers")
                 .long("target-peers")
                 .help("The target number of peers.")
-                .default_value("50")
+                .default_value("80")
                 .takes_value(true),
         )
         .arg(

book/src/SUMMARY.md

@@ -17,7 +17,7 @@
     * [Create a validator](./validator-create.md)
     * [Key recovery](./key-recovery.md)
 * [Validator Management](./validator-management.md)
-	* [Importing from the Eth2 Launchpad](./validator-import-launchpad.md)
+	* [Importing from the Staking Launchpad](./validator-import-launchpad.md)
     * [Slashing Protection](./slashing-protection.md)
     * [Voluntary Exits](./voluntary-exit.md)
     * [Validator Monitoring](./validator-monitoring.md)

book/src/advanced_networking.md

@@ -46,7 +46,7 @@ still function if it is behind a NAT without any port mappings. Although
 Lighthouse still functions, we recommend that some mechanism is used to ensure
 that your Lighthouse node is publicly accessible. This will typically improve
 your peer count, allow the scoring system to find the best/most favourable
-peers for your node and overall improve the eth2 network.
+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
@@ -63,7 +63,7 @@ settings allow you construct your initial ENR. Their primary intention is for
 setting up boot-like nodes and having a contactable ENR on boot. On normal
 operation of a Lighthouse node, none of these flags need to be set. Setting
 these flags incorrectly can lead to your node being incorrectly added to the
-global DHT which will degrades the discovery process for all Eth2 peers.
+global DHT which will degrades the discovery process for all Ethereum consensus peers.
 
 The ENR of a Lighthouse node is initially set to be non-contactable. The
 in-built discovery mechanism can determine if you node is publicly accessible,

book/src/api-bn.md

@@ -1,6 +1,6 @@
 # Beacon Node API
 
-Lighthouse implements the standard [Eth2 Beacon Node API
+Lighthouse implements the standard [Beacon Node API
 specification][OpenAPI]. Please follow that link for a full description of each API endpoint.
 
 ## Starting the server
@@ -22,7 +22,7 @@ The following CLI flags control the HTTP server:
 - `--http-tls-cert`: specify the path to the certificate file for Lighthouse to use.
 - `--http-tls-key`: specify the path to the private key file for Lighthouse to use.
 
-The schema of the API aligns with the standard Eth2 Beacon Node API as defined
+The schema of the API aligns with the standard Beacon Node API as defined
 at [github.com/ethereum/beacon-APIs](https://github.com/ethereum/beacon-APIs).
 An interactive specification is available [here][OpenAPI].
 
@@ -64,7 +64,7 @@ lighthouse bn --http
 ## HTTP Request/Response Examples
 
 This section contains some simple examples of using the HTTP API via `curl`.
-All endpoints are documented in the [Eth2 Beacon Node API
+All endpoints are documented in the [Beacon Node API
 specification][OpenAPI].
 
 ### View the head of the beacon chain

book/src/api-lighthouse.md

@@ -199,23 +199,23 @@ See [Validator Inclusion APIs](./validator-inclusion.md).
 
 ### `/lighthouse/eth1/syncing`
 
-Returns information regarding the Eth1 network, as it is required for use in
-Eth2
+Returns information regarding execution layer, as it is required for use in
+consensus layer
 
 #### Fields
 
 - `head_block_number`, `head_block_timestamp`: the block number and timestamp
-from the very head of the Eth1 chain. Useful for understanding the immediate
-health of the Eth1 node that the beacon node is connected to.
+from the very head of the execution chain. Useful for understanding the immediate
+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 Eth1 voting this timestamp should be later than the
+	- For correct execution client voting this timestamp should be later than the
 `voting_period_start_timestamp`.
-- `voting_target_timestamp`: The latest timestamp allowed for an eth1 block in this voting period.
+- `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
-	Eth1 node is from the head of the Eth1 chain.
-	- `100.0` indicates a fully synced Eth1 node.
-	- `0.0` indicates an Eth1 node that has not verified any blocks past the
+  execution node is from the head of the execution chain.
+	- `100.0` indicates a fully synced execution node.
+	- `0.0` indicates an execution node that has not verified any blocks past the
 		genesis block.
 - `lighthouse_is_cached_and_ready`: Is set to `true` if the caches in the
 	beacon node are ready for block production.
@@ -248,7 +248,7 @@ curl -X GET "http://localhost:5052/lighthouse/eth1/syncing" -H  "accept: applica
 
 ### `/lighthouse/eth1/block_cache`
 
-Returns a list of all the Eth1 blocks in the Eth1 voting cache.
+Returns a list of all the execution layer blocks in the execution client voting cache.
 
 #### Example
 
@@ -320,7 +320,7 @@ curl -X GET "http://localhost:5052/lighthouse/eth1/deposit_cache" -H  "accept: a
 
 Obtains a `BeaconState` in SSZ bytes. Useful for obtaining a genesis state.
 
-The `state_id` parameter is identical to that used in the [Standard Eth2.0 Beacon Node API
+The `state_id` parameter is identical to that used in the [Standard Beacon Node API
 `beacon/state`
 routes](https://ethereum.github.io/beacon-APIs/#/Beacon/getStateRoot).
 

book/src/api-vc-endpoints.md

@@ -6,7 +6,7 @@ HTTP Path | Description |
 | --- | -- |
 [`GET /lighthouse/version`](#get-lighthouseversion) | Get the Lighthouse software version.
 [`GET /lighthouse/health`](#get-lighthousehealth) | Get information about the host machine.
-[`GET /lighthouse/spec`](#get-lighthousespec) | Get the Eth2 specification used by the validator.
+[`GET /lighthouse/spec`](#get-lighthousespec) | Get the Ethereum proof-of-stake consensus specification used by the validator.
 [`GET /lighthouse/auth`](#get-lighthouseauth) | Get the location of the authorization token.
 [`GET /lighthouse/validators`](#get-lighthousevalidators) | List all validators.
 [`GET /lighthouse/validators/:voting_pubkey`](#get-lighthousevalidatorsvoting_pubkey) | Get a specific validator.
@@ -79,7 +79,7 @@ Typical Responses | 200
 
 ## `GET /lighthouse/spec`
 
-Returns the Eth2 specification loaded for this validator.
+Returns the Ethereum proof-of-stake consensus specification loaded for this validator.
 
 ### HTTP Specification
 

book/src/api.md

@@ -1,6 +1,6 @@
 # APIs
 
-Lighthouse allows users to query the state of Eth2.0 using web-standard,
+Lighthouse allows users to query the state of Ethereum consensus using web-standard,
 RESTful HTTP/JSON APIs.
 
 There are two APIs served by Lighthouse:

book/src/cli.md

@@ -1,6 +1,6 @@
 # Command-Line Interface (CLI)
 
-The `lighthouse` binary provides all necessary Ethereum 2.0 functionality. It
+The `lighthouse` binary provides all necessary Ethereum consensus client functionality. It
 has two primary sub-commands:
 
 - `$ lighthouse beacon_node`: the largest and most fundamental component which connects to
@@ -48,7 +48,7 @@ maintained by Sigma Prime.
 
 However, for developers, testnets can be created by following the instructions
 outlined in [testnets](./testnets.md). The steps listed here will create a
-local database specified to a new testnet. 
+local database specified to a new testnet.
 
 ## Resuming from an existing database
 

book/src/contributing.md

@@ -35,10 +35,10 @@ Lighthouse maintains two permanent branches:
 - [`unstable`][unstable]: Used for development, contains the latest PRs.
   - Developers should base thier PRs on this branch.
 
-## Ethereum 2.0
+## Ethereum consensus client
 
-Lighthouse is an implementation of the Ethereum 2.0 specification, as defined
-in the  [ethereum/eth2.0-specs](https://github.com/ethereum/eth2.0-specs)
+Lighthouse is an implementation of the Ethereum proof-of-stake consensus specification, as defined
+in the  [ethereum/consensus-specs](https://github.com/ethereum/consensus-specs)
 repository.
 
 We recommend reading Danny Ryan's (incomplete) [Phase 0 for