Merge remote-tracking branch 'origin/unstable' into das

Author: michaelsproul

Cargo.lock

@@ -12,7 +12,6 @@ AARCH64_TAG = "aarch64-unknown-linux-gnu"
 BUILD_PATH_AARCH64 = "target/$(AARCH64_TAG)/release"
 
 PINNED_NIGHTLY ?= nightly
-CLIPPY_PINNED_NIGHTLY=nightly-2022-05-19
 
 # List of features to use when cross-compiling. Can be overridden via the environment.
 CROSS_FEATURES ?= gnosis,slasher-lmdb,slasher-mdbx,slasher-redb,jemalloc
@@ -222,13 +221,6 @@ lint:
 lint-fix:
 	EXTRA_CLIPPY_OPTS="--fix --allow-staged --allow-dirty" $(MAKE) lint
 
-nightly-lint:
-	cp .github/custom/clippy.toml .
-	cargo +$(CLIPPY_PINNED_NIGHTLY) clippy --workspace --tests --release -- \
-		-A clippy::all \
-		-D clippy::disallowed_from_async
-	rm clippy.toml
-
 # Runs the makefile in the `ef_tests` repo.
 #
 # May download and extract an archive of test vectors from the ethereum

Makefile

@@ -17,7 +17,7 @@ ethereum_serde_utils = { workspace = true }
 serde_json = { workspace = true }
 serde = { workspace = true }
 warp = { workspace = true }
-jsonwebtoken = "8"
+jsonwebtoken = "9"
 bytes = { workspace = true }
 task_executor = { workspace = true }
 hex = { workspace = true }

beacon_node/execution_layer/Cargo.toml

@@ -9,10 +9,10 @@ HTTP header:
 - Value: `Bearer <api-token>`
 
 Where `<api-token>` is a string that can be obtained from the validator client
-host. Here is an example `Authorization` header:
+host. Here is an example of the `Authorization` header:
 
 ```text
-Authorization: Bearer api-token-0x03eace4c98e8f77477bb99efb74f9af10d800bd3318f92c33b719a4644254d4123
+Authorization: Bearer hGut6B8uEujufDXSmZsT0thnxvdvKFBvh
 ```
 
 ## Obtaining the API token
@@ -24,7 +24,7 @@ text editor will suffice:
 
 ```bash
 cat api-token.txt
-api-token-0x03eace4c98e8f77477bb99efb74f9af10d800bd3318f92c33b719a4644254d4123
+hGut6B8uEujufDXSmZsT0thnxvdvKFBvh
 ```
 
 When starting the validator client it will output a log message containing the path
@@ -54,7 +54,7 @@ Response:
 Here is an example `curl` command using the API token in the `Authorization` header:
 
 ```bash
-curl localhost:5062/lighthouse/version -H "Authorization: Bearer api-token-0x03eace4c98e8f77477bb99efb74f9af10d800bd3318f92c33b719a4644254d4123"
+curl localhost:5062/lighthouse/version -H "Authorization: Bearer hGut6B8uEujufDXSmZsT0thnxvdvKFBvh"
 ```
 
 The server should respond with its version:

book/src/api-vc-auth-header.md

@@ -53,12 +53,12 @@ Example Response Body:
 }
 ```
 
-> 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)"`.
+> 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:
+> As an alternative, you can also provide the API token directly, for example, `-H "Authorization: Bearer hGut6B8uEujufDXSmZsT0thnxvdvKFBvh`. 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
+curl -X GET "http://localhost:5062/lighthouse/version" -H "Authorization: Bearer hGut6B8uEujufDXSmZsT0thnxvdvKFBvh" | jq
 ```
 
 ## `GET /lighthouse/health`

book/src/api-vc-endpoints.md

@@ -116,7 +116,7 @@ location of the file varies, but it is located in the "validator directory" of y
 alongside validator keystores. For example: `~/.lighthouse/mainnet/validators/api-token.txt`. If you are unsure of the `api-token.txt` path, you can run `curl http://localhost:5062/lighthouse/auth` which will show the path.
 
 Copy the contents of that file into a new file on the **destination host** at `~/src-token.txt`. The
-API token should be similar to `api-token-0x03eace4c98e8f77477bb99efb74f9af10d800bd3318f92c33b719a4644254d4123`.
+API token is a random string, e.g., `hGut6B8uEujufDXSmZsT0thnxvdvKFBvh`.
 
 ### 4. Create an SSH Tunnel
 

book/src/api-vc-sig-header.md

@@ -811,6 +811,7 @@ impl PendingBalanceDepositsContext {
             .deposit_balance_to_consume()?
             .safe_add(state.get_activation_exit_churn_limit(spec)?)?;
         let current_epoch = state.current_epoch();
+        let next_epoch = state.next_epoch()?;
         let mut processed_amount = 0;
         let mut next_deposit_index = 0;
         let mut validator_deposits_to_process = HashMap::new();
@@ -827,17 +828,20 @@ impl PendingBalanceDepositsContext {
             // does not happen until after this (but in the spec happens before). However it's not
             // hard to work out: we don't need to know exactly what value the `exit_epoch` will
             // take, just whether it is non-default. Nor do we need to know the value of
-            // `withdrawable_epoch`, because `current_epoch <= withdrawable_epoch` will evaluate to
+            // `withdrawable_epoch`, because `next_epoch <= withdrawable_epoch` will evaluate to
             // `true` both for the actual value & the default placeholder value (`FAR_FUTURE_EPOCH`).
             let validator = state.get_validator(deposit.index as usize)?;
             let already_exited = validator.exit_epoch < spec.far_future_epoch;
             // In the spec process_registry_updates is called before process_pending_balance_deposits
             // so we must account for process_registry_updates ejecting the validator for low balance
-            // and setting the exit_epoch to < far_future_epoch
+            // and setting the exit_epoch to < far_future_epoch. Note that in the spec the effective
+            // balance update does not happen until *after* the registry update, so we don't need to
+            // account for changes to the effective balance that would push it below the ejection
+            // balance here.
             let will_be_exited = validator.is_active_at(current_epoch)
                 && validator.effective_balance <= spec.ejection_balance;
             if already_exited || will_be_exited {
-                if state.current_epoch() <= validator.withdrawable_epoch {
+                if next_epoch <= validator.withdrawable_epoch {
                     deposits_to_postpone.push(deposit.clone());
                 } else {
                     // Deposited balance will never become active. Increase balance but do not
@@ -906,7 +910,7 @@ fn process_pending_consolidations<E: EthSpec>(
     spec: &ChainSpec,
 ) -> Result<(), Error> {
     let mut next_pending_consolidation: usize = 0;
-    let current_epoch = state.current_epoch();
+    let next_epoch = state.next_epoch()?;
     let pending_consolidations = state.pending_consolidations()?.clone();
 
     let mut affected_validators = BTreeSet::new();
@@ -919,7 +923,7 @@ fn process_pending_consolidations<E: EthSpec>(
             next_pending_consolidation.safe_add_assign(1)?;
             continue;
         }
-        if source_validator.withdrawable_epoch > current_epoch {
+        if source_validator.withdrawable_epoch > next_epoch {
             break;
         }
 

book/src/validator-manager-move.md

@@ -1,4 +1,4 @@
-TESTS_TAG := v1.5.0-alpha.3
+TESTS_TAG := v1.5.0-alpha.5
 TESTS = general minimal mainnet
 TARBALLS = $(patsubst %,%-$(TESTS_TAG).tar.gz,$(TESTS))
 

consensus/state_processing/src/per_epoch_processing/single_pass.rs

@@ -28,9 +28,9 @@
     "tests/.*/.*/ssz_static/Eth1Block/",
     "tests/.*/.*/ssz_static/PowBlock/",
     # light_client
-    # "tests/.*/.*/light_client",
     "tests/.*/.*/light_client/single_merkle_proof",
     "tests/.*/.*/light_client/sync",
+    "tests/.*/electra/light_client/update_ranking",
     # LightClientStore
     "tests/.*/.*/ssz_static/LightClientStore",
     # LightClientSnapshot
@@ -40,7 +40,7 @@
     # Unused kzg methods
     "tests/.*/.*/kzg/verify_cell_kzg_proof",
     # One of the EF researchers likes to pack the tarballs on a Mac
-    ".*/.DS_Store.*",
+    ".*\\.DS_Store.*",
     # More Mac weirdness.
     "tests/mainnet/bellatrix/operations/deposit/pyspec_tests/deposit_with_previous_fork_version__valid_ineffective/._meta.yaml",
     "tests/mainnet/eip7594/networking/get_custody_columns/pyspec_tests/get_custody_columns__short_node_id/._meta.yaml",
@@ -56,7 +56,8 @@
     # TODO(electra) re-enable once https://github.com/sigp/lighthouse/issues/6002 is resolved
     "tests/.*/electra/ssz_static/LightClientUpdate",
     "tests/.*/electra/ssz_static/LightClientFinalityUpdate",
-    "tests/.*/electra/ssz_static/LightClientBootstrap"
+    "tests/.*/electra/ssz_static/LightClientBootstrap",
+    "tests/.*/electra/merkle_proof",
 ]