2021-08-06 00:47:31 +00:00
|
|
|
use crate::common::{create_api_server, ApiServer};
|
2021-09-25 07:53:58 +00:00
|
|
|
use beacon_chain::test_utils::RelativeSyncCommittee;
|
2020-09-29 03:46:54 +00:00
|
|
|
use beacon_chain::{
|
2020-10-19 05:58:39 +00:00
|
|
|
test_utils::{AttestationStrategy, BeaconChainHarness, BlockStrategy, EphemeralHarnessType},
|
Use the forwards iterator more often (#2376)
## Issue Addressed
NA
## Primary Change
When investigating memory usage, I noticed that retrieving a block from an early slot (e.g., slot 900) would cause a sharp increase in the memory footprint (from 400mb to 800mb+) which seemed to be ever-lasting.
After some investigation, I found that the reverse iteration from the head back to that slot was the likely culprit. To counter this, I've switched the `BeaconChain::block_root_at_slot` to use the forwards iterator, instead of the reverse one.
I also noticed that the networking stack is using `BeaconChain::root_at_slot` to check if a peer is relevant (`check_peer_relevance`). Perhaps the steep, seemingly-random-but-consistent increases in memory usage are caused by the use of this function.
Using the forwards iterator with the HTTP API alleviated the sharp increases in memory usage. It also made the response much faster (before it felt like to took 1-2s, now it feels instant).
## Additional Changes
In the process I also noticed that we have two functions for getting block roots:
- `BeaconChain::block_root_at_slot`: returns `None` for a skip slot.
- `BeaconChain::root_at_slot`: returns the previous root for a skip slot.
I unified these two functions into `block_root_at_slot` and added the `WhenSlotSkipped` enum. Now, the caller must be explicit about the skip-slot behaviour when requesting a root.
Additionally, I replaced `vec![]` with `Vec::with_capacity` in `store::chunked_vector::range_query`. I stumbled across this whilst debugging and made this modification to see what effect it would have (not much). It seems like a decent change to keep around, but I'm not concerned either way.
Also, `BeaconChain::get_ancestor_block_root` is unused, so I got rid of it :wastebasket:.
## Additional Info
I haven't also done the same for state roots here. Whilst it's possible and a good idea, it's more work since the fwds iterators are presently block-roots-specific.
Whilst there's a few places a reverse iteration of state roots could be triggered (e.g., attestation production, HTTP API), they're no where near as common as the `check_peer_relevance` call. As such, I think we should get this PR merged first, then come back for the state root iters. I made an issue here https://github.com/sigp/lighthouse/issues/2377.
2021-05-31 04:18:20 +00:00
|
|
|
BeaconChain, StateSkipConfig, WhenSlotSkipped, MAXIMUM_GOSSIP_CLOCK_DISPARITY,
|
2020-09-29 03:46:54 +00:00
|
|
|
};
|
|
|
|
|
use environment::null_logger;
|
2021-10-28 01:18:04 +00:00
|
|
|
use eth2::{
|
|
|
|
|
mixin::{RequestAccept, ResponseForkName, ResponseOptional},
|
|
|
|
|
reqwest::RequestBuilder,
|
|
|
|
|
types::*,
|
|
|
|
|
BeaconNodeHttpClient, Error, StatusCode, Timeouts,
|
|
|
|
|
};
|
2020-12-04 00:18:58 +00:00
|
|
|
use futures::stream::{Stream, StreamExt};
|
2021-02-10 23:29:49 +00:00
|
|
|
use futures::FutureExt;
|
Rename eth2_libp2p to lighthouse_network (#2702)
## Description
The `eth2_libp2p` crate was originally named and designed to incorporate a simple libp2p integration into lighthouse. Since its origins the crates purpose has expanded dramatically. It now houses a lot more sophistication that is specific to lighthouse and no longer just a libp2p integration.
As of this writing it currently houses the following high-level lighthouse-specific logic:
- Lighthouse's implementation of the eth2 RPC protocol and specific encodings/decodings
- Integration and handling of ENRs with respect to libp2p and eth2
- Lighthouse's discovery logic, its integration with discv5 and logic about searching and handling peers.
- Lighthouse's peer manager - This is a large module handling various aspects of Lighthouse's network, such as peer scoring, handling pings and metadata, connection maintenance and recording, etc.
- Lighthouse's peer database - This is a collection of information stored for each individual peer which is specific to lighthouse. We store connection state, sync state, last seen ips and scores etc. The data stored for each peer is designed for various elements of the lighthouse code base such as syncing and the http api.
- Gossipsub scoring - This stores a collection of gossipsub 1.1 scoring mechanisms that are continuously analyssed and updated based on the ethereum 2 networks and how Lighthouse performs on these networks.
- Lighthouse specific types for managing gossipsub topics, sync status and ENR fields
- Lighthouse's network HTTP API metrics - A collection of metrics for lighthouse network monitoring
- Lighthouse's custom configuration of all networking protocols, RPC, gossipsub, discovery, identify and libp2p.
Therefore it makes sense to rename the crate to be more akin to its current purposes, simply that it manages the majority of Lighthouse's network stack. This PR renames this crate to `lighthouse_network`
Co-authored-by: Paul Hauner <paul@paulhauner.com>
2021-10-19 00:30:39 +00:00
|
|
|
use lighthouse_network::{Enr, EnrExt, PeerId};
|
2020-09-29 03:46:54 +00:00
|
|
|
use network::NetworkMessage;
|
2021-05-04 01:59:51 +00:00
|
|
|
use sensitive_url::SensitiveUrl;
|
2021-03-29 23:42:35 +00:00
|
|
|
use slot_clock::SlotClock;
|
2020-09-29 03:46:54 +00:00
|
|
|
use state_processing::per_slot_processing;
|
|
|
|
|
use std::convert::TryInto;
|
|
|
|
|
use std::sync::Arc;
|
2021-07-09 06:15:32 +00:00
|
|
|
use tokio::sync::{mpsc, oneshot};
|
2020-12-04 00:18:58 +00:00
|
|
|
use tokio::time::Duration;
|
2020-09-29 03:46:54 +00:00
|
|
|
use tree_hash::TreeHash;
|
2022-06-30 00:49:21 +00:00
|
|
|
use types::application_domain::ApplicationDomain;
|
2020-09-29 03:46:54 +00:00
|
|
|
use types::{
|
2021-10-14 02:58:10 +00:00
|
|
|
AggregateSignature, BeaconState, BitList, Domain, EthSpec, Hash256, Keypair, MainnetEthSpec,
|
|
|
|
|
RelativeEpoch, SelectionProof, SignedRoot, Slot,
|
2020-09-29 03:46:54 +00:00
|
|
|
};
|
|
|
|
|
|
|
|
|
|
type E = MainnetEthSpec;
|
|
|
|
|
|
2021-07-12 01:47:48 +00:00
|
|
|
const SECONDS_PER_SLOT: u64 = 12;
|
2020-09-29 03:46:54 +00:00
|
|
|
const SLOTS_PER_EPOCH: u64 = 32;
|
|
|
|
|
const VALIDATOR_COUNT: usize = SLOTS_PER_EPOCH as usize;
|
2020-12-04 00:18:58 +00:00
|
|
|
const CHAIN_LENGTH: u64 = SLOTS_PER_EPOCH * 5 - 1; // Make `next_block` an epoch transition
|
2020-09-29 03:46:54 +00:00
|
|
|
const JUSTIFIED_EPOCH: u64 = 4;
|
|
|
|
|
const FINALIZED_EPOCH: u64 = 3;
|
2020-11-09 04:01:03 +00:00
|
|
|
const EXTERNAL_ADDR: &str = "/ip4/0.0.0.0/tcp/9000";
|
2020-09-29 03:46:54 +00:00
|
|
|
|
|
|
|
|
/// Skipping the slots around the epoch boundary allows us to check that we're obtaining states
|
|
|
|
|
/// from skipped slots for the finalized and justified checkpoints (instead of the state from the
|
|
|
|
|
/// block that those roots point to).
|
|
|
|
|
const SKIPPED_SLOTS: &[u64] = &[
|
|
|
|
|
JUSTIFIED_EPOCH * SLOTS_PER_EPOCH - 1,
|
|
|
|
|
JUSTIFIED_EPOCH * SLOTS_PER_EPOCH,
|
|
|
|
|
FINALIZED_EPOCH * SLOTS_PER_EPOCH - 1,
|
|
|
|
|
FINALIZED_EPOCH * SLOTS_PER_EPOCH,
|
|
|
|
|
];
|
|
|
|
|
|
|
|
|
|
struct ApiTester {
|
Use async code when interacting with EL (#3244)
## Overview
This rather extensive PR achieves two primary goals:
1. Uses the finalized/justified checkpoints of fork choice (FC), rather than that of the head state.
2. Refactors fork choice, block production and block processing to `async` functions.
Additionally, it achieves:
- Concurrent forkchoice updates to the EL and cache pruning after a new head is selected.
- Concurrent "block packing" (attestations, etc) and execution payload retrieval during block production.
- Concurrent per-block-processing and execution payload verification during block processing.
- The `Arc`-ification of `SignedBeaconBlock` during block processing (it's never mutated, so why not?):
- I had to do this to deal with sending blocks into spawned tasks.
- Previously we were cloning the beacon block at least 2 times during each block processing, these clones are either removed or turned into cheaper `Arc` clones.
- We were also `Box`-ing and un-`Box`-ing beacon blocks as they moved throughout the networking crate. This is not a big deal, but it's nice to avoid shifting things between the stack and heap.
- Avoids cloning *all the blocks* in *every chain segment* during sync.
- It also has the potential to clean up our code where we need to pass an *owned* block around so we can send it back in the case of an error (I didn't do much of this, my PR is already big enough :sweat_smile:)
- The `BeaconChain::HeadSafetyStatus` struct was removed. It was an old relic from prior merge specs.
For motivation for this change, see https://github.com/sigp/lighthouse/pull/3244#issuecomment-1160963273
## Changes to `canonical_head` and `fork_choice`
Previously, the `BeaconChain` had two separate fields:
```
canonical_head: RwLock<Snapshot>,
fork_choice: RwLock<BeaconForkChoice>
```
Now, we have grouped these values under a single struct:
```
canonical_head: CanonicalHead {
cached_head: RwLock<Arc<Snapshot>>,
fork_choice: RwLock<BeaconForkChoice>
}
```
Apart from ergonomics, the only *actual* change here is wrapping the canonical head snapshot in an `Arc`. This means that we no longer need to hold the `cached_head` (`canonical_head`, in old terms) lock when we want to pull some values from it. This was done to avoid deadlock risks by preventing functions from acquiring (and holding) the `cached_head` and `fork_choice` locks simultaneously.
## Breaking Changes
### The `state` (root) field in the `finalized_checkpoint` SSE event
Consider the scenario where epoch `n` is just finalized, but `start_slot(n)` is skipped. There are two state roots we might in the `finalized_checkpoint` SSE event:
1. The state root of the finalized block, which is `get_block(finalized_checkpoint.root).state_root`.
4. The state root at slot of `start_slot(n)`, which would be the state from (1), but "skipped forward" through any skip slots.
Previously, Lighthouse would choose (2). However, we can see that when [Teku generates that event](https://github.com/ConsenSys/teku/blob/de2b2801c89ef5abf983d6bf37867c37fc47121f/data/beaconrestapi/src/main/java/tech/pegasys/teku/beaconrestapi/handlers/v1/events/EventSubscriptionManager.java#L171-L182) it uses [`getStateRootFromBlockRoot`](https://github.com/ConsenSys/teku/blob/de2b2801c89ef5abf983d6bf37867c37fc47121f/data/provider/src/main/java/tech/pegasys/teku/api/ChainDataProvider.java#L336-L341) which uses (1).
I have switched Lighthouse from (2) to (1). I think it's a somewhat arbitrary choice between the two, where (1) is easier to compute and is consistent with Teku.
## Notes for Reviewers
I've renamed `BeaconChain::fork_choice` to `BeaconChain::recompute_head`. Doing this helped ensure I broke all previous uses of fork choice and I also find it more descriptive. It describes an action and can't be confused with trying to get a reference to the `ForkChoice` struct.
I've changed the ordering of SSE events when a block is received. It used to be `[block, finalized, head]` and now it's `[block, head, finalized]`. It was easier this way and I don't think we were making any promises about SSE event ordering so it's not "breaking".
I've made it so fork choice will run when it's first constructed. I did this because I wanted to have a cached version of the last call to `get_head`. Ensuring `get_head` has been run *at least once* means that the cached values doesn't need to wrapped in an `Option`. This was fairly simple, it just involved passing a `slot` to the constructor so it knows *when* it's being run. When loading a fork choice from the store and a slot clock isn't handy I've just used the `slot` that was saved in the `fork_choice_store`. That seems like it would be a faithful representation of the slot when we saved it.
I added the `genesis_time: u64` to the `BeaconChain`. It's small, constant and nice to have around.
Since we're using FC for the fin/just checkpoints, we no longer get the `0x00..00` roots at genesis. You can see I had to remove a work-around in `ef-tests` here: b56be3bc2. I can't find any reason why this would be an issue, if anything I think it'll be better since the genesis-alias has caught us out a few times (0x00..00 isn't actually a real root). Edit: I did find a case where the `network` expected the 0x00..00 alias and patched it here: 3f26ac3e2.
You'll notice a lot of changes in tests. Generally, tests should be functionally equivalent. Here are the things creating the most diff-noise in tests:
- Changing tests to be `tokio::async` tests.
- Adding `.await` to fork choice, block processing and block production functions.
- Refactor of the `canonical_head` "API" provided by the `BeaconChain`. E.g., `chain.canonical_head.cached_head()` instead of `chain.canonical_head.read()`.
- Wrapping `SignedBeaconBlock` in an `Arc`.
- In the `beacon_chain/tests/block_verification`, we can't use the `lazy_static` `CHAIN_SEGMENT` variable anymore since it's generated with an async function. We just generate it in each test, not so efficient but hopefully insignificant.
I had to disable `rayon` concurrent tests in the `fork_choice` tests. This is because the use of `rayon` and `block_on` was causing a panic.
Co-authored-by: Mac L <mjladson@pm.me>
2022-07-03 05:36:50 +00:00
|
|
|
harness: Arc<BeaconChainHarness<EphemeralHarnessType<E>>>,
|
2020-10-19 05:58:39 +00:00
|
|
|
chain: Arc<BeaconChain<EphemeralHarnessType<E>>>,
|
2020-09-29 03:46:54 +00:00
|
|
|
client: BeaconNodeHttpClient,
|
|
|
|
|
next_block: SignedBeaconBlock<E>,
|
2021-06-17 02:10:46 +00:00
|
|
|
reorg_block: SignedBeaconBlock<E>,
|
2020-09-29 03:46:54 +00:00
|
|
|
attestations: Vec<Attestation<E>>,
|
2021-09-25 07:53:58 +00:00
|
|
|
contribution_and_proofs: Vec<SignedContributionAndProof<E>>,
|
2020-09-29 03:46:54 +00:00
|
|
|
attester_slashing: AttesterSlashing<E>,
|
|
|
|
|
proposer_slashing: ProposerSlashing,
|
|
|
|
|
voluntary_exit: SignedVoluntaryExit,
|
|
|
|
|
_server_shutdown: oneshot::Sender<()>,
|
|
|
|
|
network_rx: mpsc::UnboundedReceiver<NetworkMessage<E>>,
|
2020-10-22 02:59:42 +00:00
|
|
|
local_enr: Enr,
|
|
|
|
|
external_peer_id: PeerId,
|
2020-09-29 03:46:54 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
impl ApiTester {
|
2021-10-11 02:45:06 +00:00
|
|
|
pub async fn new() -> Self {
|
2021-08-06 00:47:31 +00:00
|
|
|
// This allows for testing voluntary exits without building out a massive chain.
|
|
|
|
|
let mut spec = E::default_spec();
|
|
|
|
|
spec.shard_committee_period = 2;
|
2021-10-11 02:45:06 +00:00
|
|
|
Self::new_from_spec(spec).await
|
2021-09-25 07:53:58 +00:00
|
|
|
}
|
2021-08-06 00:47:31 +00:00
|
|
|
|
2021-10-11 02:45:06 +00:00
|
|
|
pub async fn new_from_spec(spec: ChainSpec) -> Self {
|
Use async code when interacting with EL (#3244)
## Overview
This rather extensive PR achieves two primary goals:
1. Uses the finalized/justified checkpoints of fork choice (FC), rather than that of the head state.
2. Refactors fork choice, block production and block processing to `async` functions.
Additionally, it achieves:
- Concurrent forkchoice updates to the EL and cache pruning after a new head is selected.
- Concurrent "block packing" (attestations, etc) and execution payload retrieval during block production.
- Concurrent per-block-processing and execution payload verification during block processing.
- The `Arc`-ification of `SignedBeaconBlock` during block processing (it's never mutated, so why not?):
- I had to do this to deal with sending blocks into spawned tasks.
- Previously we were cloning the beacon block at least 2 times during each block processing, these clones are either removed or turned into cheaper `Arc` clones.
- We were also `Box`-ing and un-`Box`-ing beacon blocks as they moved throughout the networking crate. This is not a big deal, but it's nice to avoid shifting things between the stack and heap.
- Avoids cloning *all the blocks* in *every chain segment* during sync.
- It also has the potential to clean up our code where we need to pass an *owned* block around so we can send it back in the case of an error (I didn't do much of this, my PR is already big enough :sweat_smile:)
- The `BeaconChain::HeadSafetyStatus` struct was removed. It was an old relic from prior merge specs.
For motivation for this change, see https://github.com/sigp/lighthouse/pull/3244#issuecomment-1160963273
## Changes to `canonical_head` and `fork_choice`
Previously, the `BeaconChain` had two separate fields:
```
canonical_head: RwLock<Snapshot>,
fork_choice: RwLock<BeaconForkChoice>
```
Now, we have grouped these values under a single struct:
```
canonical_head: CanonicalHead {
cached_head: RwLock<Arc<Snapshot>>,
fork_choice: RwLock<BeaconForkChoice>
}
```
Apart from ergonomics, the only *actual* change here is wrapping the canonical head snapshot in an `Arc`. This means that we no longer need to hold the `cached_head` (`canonical_head`, in old terms) lock when we want to pull some values from it. This was done to avoid deadlock risks by preventing functions from acquiring (and holding) the `cached_head` and `fork_choice` locks simultaneously.
## Breaking Changes
### The `state` (root) field in the `finalized_checkpoint` SSE event
Consider the scenario where epoch `n` is just finalized, but `start_slot(n)` is skipped. There are two state roots we might in the `finalized_checkpoint` SSE event:
1. The state root of the finalized block, which is `get_block(finalized_checkpoint.root).state_root`.
4. The state root at slot of `start_slot(n)`, which would be the state from (1), but "skipped forward" through any skip slots.
Previously, Lighthouse would choose (2). However, we can see that when [Teku generates that event](https://github.com/ConsenSys/teku/blob/de2b2801c89ef5abf983d6bf37867c37fc47121f/data/beaconrestapi/src/main/java/tech/pegasys/teku/beaconrestapi/handlers/v1/events/EventSubscriptionManager.java#L171-L182) it uses [`getStateRootFromBlockRoot`](https://github.com/ConsenSys/teku/blob/de2b2801c89ef5abf983d6bf37867c37fc47121f/data/provider/src/main/java/tech/pegasys/teku/api/ChainDataProvider.java#L336-L341) which uses (1).
I have switched Lighthouse from (2) to (1). I think it's a somewhat arbitrary choice between the two, where (1) is easier to compute and is consistent with Teku.
## Notes for Reviewers
I've renamed `BeaconChain::fork_choice` to `BeaconChain::recompute_head`. Doing this helped ensure I broke all previous uses of fork choice and I also find it more descriptive. It describes an action and can't be confused with trying to get a reference to the `ForkChoice` struct.
I've changed the ordering of SSE events when a block is received. It used to be `[block, finalized, head]` and now it's `[block, head, finalized]`. It was easier this way and I don't think we were making any promises about SSE event ordering so it's not "breaking".
I've made it so fork choice will run when it's first constructed. I did this because I wanted to have a cached version of the last call to `get_head`. Ensuring `get_head` has been run *at least once* means that the cached values doesn't need to wrapped in an `Option`. This was fairly simple, it just involved passing a `slot` to the constructor so it knows *when* it's being run. When loading a fork choice from the store and a slot clock isn't handy I've just used the `slot` that was saved in the `fork_choice_store`. That seems like it would be a faithful representation of the slot when we saved it.
I added the `genesis_time: u64` to the `BeaconChain`. It's small, constant and nice to have around.
Since we're using FC for the fin/just checkpoints, we no longer get the `0x00..00` roots at genesis. You can see I had to remove a work-around in `ef-tests` here: b56be3bc2. I can't find any reason why this would be an issue, if anything I think it'll be better since the genesis-alias has caught us out a few times (0x00..00 isn't actually a real root). Edit: I did find a case where the `network` expected the 0x00..00 alias and patched it here: 3f26ac3e2.
You'll notice a lot of changes in tests. Generally, tests should be functionally equivalent. Here are the things creating the most diff-noise in tests:
- Changing tests to be `tokio::async` tests.
- Adding `.await` to fork choice, block processing and block production functions.
- Refactor of the `canonical_head` "API" provided by the `BeaconChain`. E.g., `chain.canonical_head.cached_head()` instead of `chain.canonical_head.read()`.
- Wrapping `SignedBeaconBlock` in an `Arc`.
- In the `beacon_chain/tests/block_verification`, we can't use the `lazy_static` `CHAIN_SEGMENT` variable anymore since it's generated with an async function. We just generate it in each test, not so efficient but hopefully insignificant.
I had to disable `rayon` concurrent tests in the `fork_choice` tests. This is because the use of `rayon` and `block_on` was causing a panic.
Co-authored-by: Mac L <mjladson@pm.me>
2022-07-03 05:36:50 +00:00
|
|
|
let harness = Arc::new(
|
|
|
|
|
BeaconChainHarness::builder(MainnetEthSpec)
|
|
|
|
|
.spec(spec.clone())
|
|
|
|
|
.deterministic_keypairs(VALIDATOR_COUNT)
|
|
|
|
|
.fresh_ephemeral_store()
|
|
|
|
|
.mock_execution_layer()
|
|
|
|
|
.build(),
|
|
|
|
|
);
|
2020-09-29 03:46:54 +00:00
|
|
|
|
|
|
|
|
harness.advance_slot();
|
|
|
|
|
|
|
|
|
|
for _ in 0..CHAIN_LENGTH {
|
|
|
|
|
let slot = harness.chain.slot().unwrap().as_u64();
|
|
|
|
|
|
|
|
|
|
if !SKIPPED_SLOTS.contains(&slot) {
|
Use async code when interacting with EL (#3244)
## Overview
This rather extensive PR achieves two primary goals:
1. Uses the finalized/justified checkpoints of fork choice (FC), rather than that of the head state.
2. Refactors fork choice, block production and block processing to `async` functions.
Additionally, it achieves:
- Concurrent forkchoice updates to the EL and cache pruning after a new head is selected.
- Concurrent "block packing" (attestations, etc) and execution payload retrieval during block production.
- Concurrent per-block-processing and execution payload verification during block processing.
- The `Arc`-ification of `SignedBeaconBlock` during block processing (it's never mutated, so why not?):
- I had to do this to deal with sending blocks into spawned tasks.
- Previously we were cloning the beacon block at least 2 times during each block processing, these clones are either removed or turned into cheaper `Arc` clones.
- We were also `Box`-ing and un-`Box`-ing beacon blocks as they moved throughout the networking crate. This is not a big deal, but it's nice to avoid shifting things between the stack and heap.
- Avoids cloning *all the blocks* in *every chain segment* during sync.
- It also has the potential to clean up our code where we need to pass an *owned* block around so we can send it back in the case of an error (I didn't do much of this, my PR is already big enough :sweat_smile:)
- The `BeaconChain::HeadSafetyStatus` struct was removed. It was an old relic from prior merge specs.
For motivation for this change, see https://github.com/sigp/lighthouse/pull/3244#issuecomment-1160963273
## Changes to `canonical_head` and `fork_choice`
Previously, the `BeaconChain` had two separate fields:
```
canonical_head: RwLock<Snapshot>,
fork_choice: RwLock<BeaconForkChoice>
```
Now, we have grouped these values under a single struct:
```
canonical_head: CanonicalHead {
cached_head: RwLock<Arc<Snapshot>>,
fork_choice: RwLock<BeaconForkChoice>
}
```
Apart from ergonomics, the only *actual* change here is wrapping the canonical head snapshot in an `Arc`. This means that we no longer need to hold the `cached_head` (`canonical_head`, in old terms) lock when we want to pull some values from it. This was done to avoid deadlock risks by preventing functions from acquiring (and holding) the `cached_head` and `fork_choice` locks simultaneously.
## Breaking Changes
### The `state` (root) field in the `finalized_checkpoint` SSE event
Consider the scenario where epoch `n` is just finalized, but `start_slot(n)` is skipped. There are two state roots we might in the `finalized_checkpoint` SSE event:
1. The state root of the finalized block, which is `get_block(finalized_checkpoint.root).state_root`.
4. The state root at slot of `start_slot(n)`, which would be the state from (1), but "skipped forward" through any skip slots.
Previously, Lighthouse would choose (2). However, we can see that when [Teku generates that event](https://github.com/ConsenSys/teku/blob/de2b2801c89ef5abf983d6bf37867c37fc47121f/data/beaconrestapi/src/main/java/tech/pegasys/teku/beaconrestapi/handlers/v1/events/EventSubscriptionManager.java#L171-L182) it uses [`getStateRootFromBlockRoot`](https://github.com/ConsenSys/teku/blob/de2b2801c89ef5abf983d6bf37867c37fc47121f/data/provider/src/main/java/tech/pegasys/teku/api/ChainDataProvider.java#L336-L341) which uses (1).
I have switched Lighthouse from (2) to (1). I think it's a somewhat arbitrary choice between the two, where (1) is easier to compute and is consistent with Teku.
## Notes for Reviewers
I've renamed `BeaconChain::fork_choice` to `BeaconChain::recompute_head`. Doing this helped ensure I broke all previous uses of fork choice and I also find it more descriptive. It describes an action and can't be confused with trying to get a reference to the `ForkChoice` struct.
I've changed the ordering of SSE events when a block is received. It used to be `[block, finalized, head]` and now it's `[block, head, finalized]`. It was easier this way and I don't think we were making any promises about SSE event ordering so it's not "breaking".
I've made it so fork choice will run when it's first constructed. I did this because I wanted to have a cached version of the last call to `get_head`. Ensuring `get_head` has been run *at least once* means that the cached values doesn't need to wrapped in an `Option`. This was fairly simple, it just involved passing a `slot` to the constructor so it knows *when* it's being run. When loading a fork choice from the store and a slot clock isn't handy I've just used the `slot` that was saved in the `fork_choice_store`. That seems like it would be a faithful representation of the slot when we saved it.
I added the `genesis_time: u64` to the `BeaconChain`. It's small, constant and nice to have around.
Since we're using FC for the fin/just checkpoints, we no longer get the `0x00..00` roots at genesis. You can see I had to remove a work-around in `ef-tests` here: b56be3bc2. I can't find any reason why this would be an issue, if anything I think it'll be better since the genesis-alias has caught us out a few times (0x00..00 isn't actually a real root). Edit: I did find a case where the `network` expected the 0x00..00 alias and patched it here: 3f26ac3e2.
You'll notice a lot of changes in tests. Generally, tests should be functionally equivalent. Here are the things creating the most diff-noise in tests:
- Changing tests to be `tokio::async` tests.
- Adding `.await` to fork choice, block processing and block production functions.
- Refactor of the `canonical_head` "API" provided by the `BeaconChain`. E.g., `chain.canonical_head.cached_head()` instead of `chain.canonical_head.read()`.
- Wrapping `SignedBeaconBlock` in an `Arc`.
- In the `beacon_chain/tests/block_verification`, we can't use the `lazy_static` `CHAIN_SEGMENT` variable anymore since it's generated with an async function. We just generate it in each test, not so efficient but hopefully insignificant.
I had to disable `rayon` concurrent tests in the `fork_choice` tests. This is because the use of `rayon` and `block_on` was causing a panic.
Co-authored-by: Mac L <mjladson@pm.me>
2022-07-03 05:36:50 +00:00
|
|
|
harness
|
|
|
|
|
.extend_chain(
|
|
|
|
|
1,
|
|
|
|
|
BlockStrategy::OnCanonicalHead,
|
|
|
|
|
AttestationStrategy::AllValidators,
|
|
|
|
|
)
|
|
|
|
|
.await;
|
2020-09-29 03:46:54 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
harness.advance_slot();
|
|
|
|
|
}
|
|
|
|
|
|
Use async code when interacting with EL (#3244)
## Overview
This rather extensive PR achieves two primary goals:
1. Uses the finalized/justified checkpoints of fork choice (FC), rather than that of the head state.
2. Refactors fork choice, block production and block processing to `async` functions.
Additionally, it achieves:
- Concurrent forkchoice updates to the EL and cache pruning after a new head is selected.
- Concurrent "block packing" (attestations, etc) and execution payload retrieval during block production.
- Concurrent per-block-processing and execution payload verification during block processing.
- The `Arc`-ification of `SignedBeaconBlock` during block processing (it's never mutated, so why not?):
- I had to do this to deal with sending blocks into spawned tasks.
- Previously we were cloning the beacon block at least 2 times during each block processing, these clones are either removed or turned into cheaper `Arc` clones.
- We were also `Box`-ing and un-`Box`-ing beacon blocks as they moved throughout the networking crate. This is not a big deal, but it's nice to avoid shifting things between the stack and heap.
- Avoids cloning *all the blocks* in *every chain segment* during sync.
- It also has the potential to clean up our code where we need to pass an *owned* block around so we can send it back in the case of an error (I didn't do much of this, my PR is already big enough :sweat_smile:)
- The `BeaconChain::HeadSafetyStatus` struct was removed. It was an old relic from prior merge specs.
For motivation for this change, see https://github.com/sigp/lighthouse/pull/3244#issuecomment-1160963273
## Changes to `canonical_head` and `fork_choice`
Previously, the `BeaconChain` had two separate fields:
```
canonical_head: RwLock<Snapshot>,
fork_choice: RwLock<BeaconForkChoice>
```
Now, we have grouped these values under a single struct:
```
canonical_head: CanonicalHead {
cached_head: RwLock<Arc<Snapshot>>,
fork_choice: RwLock<BeaconForkChoice>
}
```
Apart from ergonomics, the only *actual* change here is wrapping the canonical head snapshot in an `Arc`. This means that we no longer need to hold the `cached_head` (`canonical_head`, in old terms) lock when we want to pull some values from it. This was done to avoid deadlock risks by preventing functions from acquiring (and holding) the `cached_head` and `fork_choice` locks simultaneously.
## Breaking Changes
### The `state` (root) field in the `finalized_checkpoint` SSE event
Consider the scenario where epoch `n` is just finalized, but `start_slot(n)` is skipped. There are two state roots we might in the `finalized_checkpoint` SSE event:
1. The state root of the finalized block, which is `get_block(finalized_checkpoint.root).state_root`.
4. The state root at slot of `start_slot(n)`, which would be the state from (1), but "skipped forward" through any skip slots.
Previously, Lighthouse would choose (2). However, we can see that when [Teku generates that event](https://github.com/ConsenSys/teku/blob/de2b2801c89ef5abf983d6bf37867c37fc47121f/data/beaconrestapi/src/main/java/tech/pegasys/teku/beaconrestapi/handlers/v1/events/EventSubscriptionManager.java#L171-L182) it uses [`getStateRootFromBlockRoot`](https://github.com/ConsenSys/teku/blob/de2b2801c89ef5abf983d6bf37867c37fc47121f/data/provider/src/main/java/tech/pegasys/teku/api/ChainDataProvider.java#L336-L341) which uses (1).
I have switched Lighthouse from (2) to (1). I think it's a somewhat arbitrary choice between the two, where (1) is easier to compute and is consistent with Teku.
## Notes for Reviewers
I've renamed `BeaconChain::fork_choice` to `BeaconChain::recompute_head`. Doing this helped ensure I broke all previous uses of fork choice and I also find it more descriptive. It describes an action and can't be confused with trying to get a reference to the `ForkChoice` struct.
I've changed the ordering of SSE events when a block is received. It used to be `[block, finalized, head]` and now it's `[block, head, finalized]`. It was easier this way and I don't think we were making any promises about SSE event ordering so it's not "breaking".
I've made it so fork choice will run when it's first constructed. I did this because I wanted to have a cached version of the last call to `get_head`. Ensuring `get_head` has been run *at least once* means that the cached values doesn't need to wrapped in an `Option`. This was fairly simple, it just involved passing a `slot` to the constructor so it knows *when* it's being run. When loading a fork choice from the store and a slot clock isn't handy I've just used the `slot` that was saved in the `fork_choice_store`. That seems like it would be a faithful representation of the slot when we saved it.
I added the `genesis_time: u64` to the `BeaconChain`. It's small, constant and nice to have around.
Since we're using FC for the fin/just checkpoints, we no longer get the `0x00..00` roots at genesis. You can see I had to remove a work-around in `ef-tests` here: b56be3bc2. I can't find any reason why this would be an issue, if anything I think it'll be better since the genesis-alias has caught us out a few times (0x00..00 isn't actually a real root). Edit: I did find a case where the `network` expected the 0x00..00 alias and patched it here: 3f26ac3e2.
You'll notice a lot of changes in tests. Generally, tests should be functionally equivalent. Here are the things creating the most diff-noise in tests:
- Changing tests to be `tokio::async` tests.
- Adding `.await` to fork choice, block processing and block production functions.
- Refactor of the `canonical_head` "API" provided by the `BeaconChain`. E.g., `chain.canonical_head.cached_head()` instead of `chain.canonical_head.read()`.
- Wrapping `SignedBeaconBlock` in an `Arc`.
- In the `beacon_chain/tests/block_verification`, we can't use the `lazy_static` `CHAIN_SEGMENT` variable anymore since it's generated with an async function. We just generate it in each test, not so efficient but hopefully insignificant.
I had to disable `rayon` concurrent tests in the `fork_choice` tests. This is because the use of `rayon` and `block_on` was causing a panic.
Co-authored-by: Mac L <mjladson@pm.me>
2022-07-03 05:36:50 +00:00
|
|
|
let head = harness.chain.head_snapshot();
|
2020-09-29 03:46:54 +00:00
|
|
|
|
|
|
|
|
assert_eq!(
|
|
|
|
|
harness.chain.slot().unwrap(),
|
|
|
|
|
head.beacon_block.slot() + 1,
|
|
|
|
|
"precondition: current slot is one after head"
|
|
|
|
|
);
|
|
|
|
|
|
Use async code when interacting with EL (#3244)
## Overview
This rather extensive PR achieves two primary goals:
1. Uses the finalized/justified checkpoints of fork choice (FC), rather than that of the head state.
2. Refactors fork choice, block production and block processing to `async` functions.
Additionally, it achieves:
- Concurrent forkchoice updates to the EL and cache pruning after a new head is selected.
- Concurrent "block packing" (attestations, etc) and execution payload retrieval during block production.
- Concurrent per-block-processing and execution payload verification during block processing.
- The `Arc`-ification of `SignedBeaconBlock` during block processing (it's never mutated, so why not?):
- I had to do this to deal with sending blocks into spawned tasks.
- Previously we were cloning the beacon block at least 2 times during each block processing, these clones are either removed or turned into cheaper `Arc` clones.
- We were also `Box`-ing and un-`Box`-ing beacon blocks as they moved throughout the networking crate. This is not a big deal, but it's nice to avoid shifting things between the stack and heap.
- Avoids cloning *all the blocks* in *every chain segment* during sync.
- It also has the potential to clean up our code where we need to pass an *owned* block around so we can send it back in the case of an error (I didn't do much of this, my PR is already big enough :sweat_smile:)
- The `BeaconChain::HeadSafetyStatus` struct was removed. It was an old relic from prior merge specs.
For motivation for this change, see https://github.com/sigp/lighthouse/pull/3244#issuecomment-1160963273
## Changes to `canonical_head` and `fork_choice`
Previously, the `BeaconChain` had two separate fields:
```
canonical_head: RwLock<Snapshot>,
fork_choice: RwLock<BeaconForkChoice>
```
Now, we have grouped these values under a single struct:
```
canonical_head: CanonicalHead {
cached_head: RwLock<Arc<Snapshot>>,
fork_choice: RwLock<BeaconForkChoice>
}
```
Apart from ergonomics, the only *actual* change here is wrapping the canonical head snapshot in an `Arc`. This means that we no longer need to hold the `cached_head` (`canonical_head`, in old terms) lock when we want to pull some values from it. This was done to avoid deadlock risks by preventing functions from acquiring (and holding) the `cached_head` and `fork_choice` locks simultaneously.
## Breaking Changes
### The `state` (root) field in the `finalized_checkpoint` SSE event
Consider the scenario where epoch `n` is just finalized, but `start_slot(n)` is skipped. There are two state roots we might in the `finalized_checkpoint` SSE event:
1. The state root of the finalized block, which is `get_block(finalized_checkpoint.root).state_root`.
4. The state root at slot of `start_slot(n)`, which would be the state from (1), but "skipped forward" through any skip slots.
Previously, Lighthouse would choose (2). However, we can see that when [Teku generates that event](https://github.com/ConsenSys/teku/blob/de2b2801c89ef5abf983d6bf37867c37fc47121f/data/beaconrestapi/src/main/java/tech/pegasys/teku/beaconrestapi/handlers/v1/events/EventSubscriptionManager.java#L171-L182) it uses [`getStateRootFromBlockRoot`](https://github.com/ConsenSys/teku/blob/de2b2801c89ef5abf983d6bf37867c37fc47121f/data/provider/src/main/java/tech/pegasys/teku/api/ChainDataProvider.java#L336-L341) which uses (1).
I have switched Lighthouse from (2) to (1). I think it's a somewhat arbitrary choice between the two, where (1) is easier to compute and is consistent with Teku.
## Notes for Reviewers
I've renamed `BeaconChain::fork_choice` to `BeaconChain::recompute_head`. Doing this helped ensure I broke all previous uses of fork choice and I also find it more descriptive. It describes an action and can't be confused with trying to get a reference to the `ForkChoice` struct.
I've changed the ordering of SSE events when a block is received. It used to be `[block, finalized, head]` and now it's `[block, head, finalized]`. It was easier this way and I don't think we were making any promises about SSE event ordering so it's not "breaking".
I've made it so fork choice will run when it's first constructed. I did this because I wanted to have a cached version of the last call to `get_head`. Ensuring `get_head` has been run *at least once* means that the cached values doesn't need to wrapped in an `Option`. This was fairly simple, it just involved passing a `slot` to the constructor so it knows *when* it's being run. When loading a fork choice from the store and a slot clock isn't handy I've just used the `slot` that was saved in the `fork_choice_store`. That seems like it would be a faithful representation of the slot when we saved it.
I added the `genesis_time: u64` to the `BeaconChain`. It's small, constant and nice to have around.
Since we're using FC for the fin/just checkpoints, we no longer get the `0x00..00` roots at genesis. You can see I had to remove a work-around in `ef-tests` here: b56be3bc2. I can't find any reason why this would be an issue, if anything I think it'll be better since the genesis-alias has caught us out a few times (0x00..00 isn't actually a real root). Edit: I did find a case where the `network` expected the 0x00..00 alias and patched it here: 3f26ac3e2.
You'll notice a lot of changes in tests. Generally, tests should be functionally equivalent. Here are the things creating the most diff-noise in tests:
- Changing tests to be `tokio::async` tests.
- Adding `.await` to fork choice, block processing and block production functions.
- Refactor of the `canonical_head` "API" provided by the `BeaconChain`. E.g., `chain.canonical_head.cached_head()` instead of `chain.canonical_head.read()`.
- Wrapping `SignedBeaconBlock` in an `Arc`.
- In the `beacon_chain/tests/block_verification`, we can't use the `lazy_static` `CHAIN_SEGMENT` variable anymore since it's generated with an async function. We just generate it in each test, not so efficient but hopefully insignificant.
I had to disable `rayon` concurrent tests in the `fork_choice` tests. This is because the use of `rayon` and `block_on` was causing a panic.
Co-authored-by: Mac L <mjladson@pm.me>
2022-07-03 05:36:50 +00:00
|
|
|
let (next_block, _next_state) = harness
|
|
|
|
|
.make_block(head.beacon_state.clone(), harness.chain.slot().unwrap())
|
|
|
|
|
.await;
|
2020-09-29 03:46:54 +00:00
|
|
|
|
2021-06-17 02:10:46 +00:00
|
|
|
// `make_block` adds random graffiti, so this will produce an alternate block
|
Use async code when interacting with EL (#3244)
## Overview
This rather extensive PR achieves two primary goals:
1. Uses the finalized/justified checkpoints of fork choice (FC), rather than that of the head state.
2. Refactors fork choice, block production and block processing to `async` functions.
Additionally, it achieves:
- Concurrent forkchoice updates to the EL and cache pruning after a new head is selected.
- Concurrent "block packing" (attestations, etc) and execution payload retrieval during block production.
- Concurrent per-block-processing and execution payload verification during block processing.
- The `Arc`-ification of `SignedBeaconBlock` during block processing (it's never mutated, so why not?):
- I had to do this to deal with sending blocks into spawned tasks.
- Previously we were cloning the beacon block at least 2 times during each block processing, these clones are either removed or turned into cheaper `Arc` clones.
- We were also `Box`-ing and un-`Box`-ing beacon blocks as they moved throughout the networking crate. This is not a big deal, but it's nice to avoid shifting things between the stack and heap.
- Avoids cloning *all the blocks* in *every chain segment* during sync.
- It also has the potential to clean up our code where we need to pass an *owned* block around so we can send it back in the case of an error (I didn't do much of this, my PR is already big enough :sweat_smile:)
- The `BeaconChain::HeadSafetyStatus` struct was removed. It was an old relic from prior merge specs.
For motivation for this change, see https://github.com/sigp/lighthouse/pull/3244#issuecomment-1160963273
## Changes to `canonical_head` and `fork_choice`
Previously, the `BeaconChain` had two separate fields:
```
canonical_head: RwLock<Snapshot>,
fork_choice: RwLock<BeaconForkChoice>
```
Now, we have grouped these values under a single struct:
```
canonical_head: CanonicalHead {
cached_head: RwLock<Arc<Snapshot>>,
fork_choice: RwLock<BeaconForkChoice>
}
```
Apart from ergonomics, the only *actual* change here is wrapping the canonical head snapshot in an `Arc`. This means that we no longer need to hold the `cached_head` (`canonical_head`, in old terms) lock when we want to pull some values from it. This was done to avoid deadlock risks by preventing functions from acquiring (and holding) the `cached_head` and `fork_choice` locks simultaneously.
## Breaking Changes
### The `state` (root) field in the `finalized_checkpoint` SSE event
Consider the scenario where epoch `n` is just finalized, but `start_slot(n)` is skipped. There are two state roots we might in the `finalized_checkpoint` SSE event:
1. The state root of the finalized block, which is `get_block(finalized_checkpoint.root).state_root`.
4. The state root at slot of `start_slot(n)`, which would be the state from (1), but "skipped forward" through any skip slots.
Previously, Lighthouse would choose (2). However, we can see that when [Teku generates that event](https://github.com/ConsenSys/teku/blob/de2b2801c89ef5abf983d6bf37867c37fc47121f/data/beaconrestapi/src/main/java/tech/pegasys/teku/beaconrestapi/handlers/v1/events/EventSubscriptionManager.java#L171-L182) it uses [`getStateRootFromBlockRoot`](https://github.com/ConsenSys/teku/blob/de2b2801c89ef5abf983d6bf37867c37fc47121f/data/provider/src/main/java/tech/pegasys/teku/api/ChainDataProvider.java#L336-L341) which uses (1).
I have switched Lighthouse from (2) to (1). I think it's a somewhat arbitrary choice between the two, where (1) is easier to compute and is consistent with Teku.
## Notes for Reviewers
I've renamed `BeaconChain::fork_choice` to `BeaconChain::recompute_head`. Doing this helped ensure I broke all previous uses of fork choice and I also find it more descriptive. It describes an action and can't be confused with trying to get a reference to the `ForkChoice` struct.
I've changed the ordering of SSE events when a block is received. It used to be `[block, finalized, head]` and now it's `[block, head, finalized]`. It was easier this way and I don't think we were making any promises about SSE event ordering so it's not "breaking".
I've made it so fork choice will run when it's first constructed. I did this because I wanted to have a cached version of the last call to `get_head`. Ensuring `get_head` has been run *at least once* means that the cached values doesn't need to wrapped in an `Option`. This was fairly simple, it just involved passing a `slot` to the constructor so it knows *when* it's being run. When loading a fork choice from the store and a slot clock isn't handy I've just used the `slot` that was saved in the `fork_choice_store`. That seems like it would be a faithful representation of the slot when we saved it.
I added the `genesis_time: u64` to the `BeaconChain`. It's small, constant and nice to have around.
Since we're using FC for the fin/just checkpoints, we no longer get the `0x00..00` roots at genesis. You can see I had to remove a work-around in `ef-tests` here: b56be3bc2. I can't find any reason why this would be an issue, if anything I think it'll be better since the genesis-alias has caught us out a few times (0x00..00 isn't actually a real root). Edit: I did find a case where the `network` expected the 0x00..00 alias and patched it here: 3f26ac3e2.
You'll notice a lot of changes in tests. Generally, tests should be functionally equivalent. Here are the things creating the most diff-noise in tests:
- Changing tests to be `tokio::async` tests.
- Adding `.await` to fork choice, block processing and block production functions.
- Refactor of the `canonical_head` "API" provided by the `BeaconChain`. E.g., `chain.canonical_head.cached_head()` instead of `chain.canonical_head.read()`.
- Wrapping `SignedBeaconBlock` in an `Arc`.
- In the `beacon_chain/tests/block_verification`, we can't use the `lazy_static` `CHAIN_SEGMENT` variable anymore since it's generated with an async function. We just generate it in each test, not so efficient but hopefully insignificant.
I had to disable `rayon` concurrent tests in the `fork_choice` tests. This is because the use of `rayon` and `block_on` was causing a panic.
Co-authored-by: Mac L <mjladson@pm.me>
2022-07-03 05:36:50 +00:00
|
|
|
let (reorg_block, _reorg_state) = harness
|
|
|
|
|
.make_block(head.beacon_state.clone(), harness.chain.slot().unwrap())
|
|
|
|
|
.await;
|
2021-06-17 02:10:46 +00:00
|
|
|
|
2021-03-17 05:09:57 +00:00
|
|
|
let head_state_root = head.beacon_state_root();
|
2020-09-29 03:46:54 +00:00
|
|
|
let attestations = harness
|
|
|
|
|
.get_unaggregated_attestations(
|
|
|
|
|
&AttestationStrategy::AllValidators,
|
|
|
|
|
&head.beacon_state,
|
2021-03-17 05:09:57 +00:00
|
|
|
head_state_root,
|
2020-09-29 03:46:54 +00:00
|
|
|
head.beacon_block_root,
|
|
|
|
|
harness.chain.slot().unwrap(),
|
|
|
|
|
)
|
|
|
|
|
.into_iter()
|
2022-05-16 01:59:47 +00:00
|
|
|
.flat_map(|vec| vec.into_iter().map(|(attestation, _subnet_id)| attestation))
|
2020-09-29 03:46:54 +00:00
|
|
|
.collect::<Vec<_>>();
|
|
|
|
|
|
|
|
|
|
assert!(
|
|
|
|
|
!attestations.is_empty(),
|
|
|
|
|
"precondition: attestations for testing"
|
|
|
|
|
);
|
|
|
|
|
|
2021-09-25 07:53:58 +00:00
|
|
|
let current_epoch = harness
|
|
|
|
|
.chain
|
|
|
|
|
.slot()
|
|
|
|
|
.expect("should get current slot")
|
|
|
|
|
.epoch(E::slots_per_epoch());
|
|
|
|
|
let is_altair = spec
|
|
|
|
|
.altair_fork_epoch
|
|
|
|
|
.map(|epoch| epoch <= current_epoch)
|
|
|
|
|
.unwrap_or(false);
|
|
|
|
|
let contribution_and_proofs = if is_altair {
|
|
|
|
|
harness
|
|
|
|
|
.make_sync_contributions(
|
|
|
|
|
&head.beacon_state,
|
|
|
|
|
head_state_root,
|
|
|
|
|
harness.chain.slot().unwrap(),
|
|
|
|
|
RelativeSyncCommittee::Current,
|
|
|
|
|
)
|
|
|
|
|
.into_iter()
|
|
|
|
|
.filter_map(|(_, contribution)| contribution)
|
|
|
|
|
.collect::<Vec<_>>()
|
|
|
|
|
} else {
|
|
|
|
|
vec![]
|
|
|
|
|
};
|
|
|
|
|
|
2020-09-29 03:46:54 +00:00
|
|
|
let attester_slashing = harness.make_attester_slashing(vec![0, 1]);
|
|
|
|
|
let proposer_slashing = harness.make_proposer_slashing(2);
|
|
|
|
|
let voluntary_exit = harness.make_voluntary_exit(3, harness.chain.epoch().unwrap());
|
|
|
|
|
|
2021-08-06 00:47:31 +00:00
|
|
|
let chain = harness.chain.clone();
|
2020-09-29 03:46:54 +00:00
|
|
|
|
|
|
|
|
assert_eq!(
|
Use async code when interacting with EL (#3244)
## Overview
This rather extensive PR achieves two primary goals:
1. Uses the finalized/justified checkpoints of fork choice (FC), rather than that of the head state.
2. Refactors fork choice, block production and block processing to `async` functions.
Additionally, it achieves:
- Concurrent forkchoice updates to the EL and cache pruning after a new head is selected.
- Concurrent "block packing" (attestations, etc) and execution payload retrieval during block production.
- Concurrent per-block-processing and execution payload verification during block processing.
- The `Arc`-ification of `SignedBeaconBlock` during block processing (it's never mutated, so why not?):
- I had to do this to deal with sending blocks into spawned tasks.
- Previously we were cloning the beacon block at least 2 times during each block processing, these clones are either removed or turned into cheaper `Arc` clones.
- We were also `Box`-ing and un-`Box`-ing beacon blocks as they moved throughout the networking crate. This is not a big deal, but it's nice to avoid shifting things between the stack and heap.
- Avoids cloning *all the blocks* in *every chain segment* during sync.
- It also has the potential to clean up our code where we need to pass an *owned* block around so we can send it back in the case of an error (I didn't do much of this, my PR is already big enough :sweat_smile:)
- The `BeaconChain::HeadSafetyStatus` struct was removed. It was an old relic from prior merge specs.
For motivation for this change, see https://github.com/sigp/lighthouse/pull/3244#issuecomment-1160963273
## Changes to `canonical_head` and `fork_choice`
Previously, the `BeaconChain` had two separate fields:
```
canonical_head: RwLock<Snapshot>,
fork_choice: RwLock<BeaconForkChoice>
```
Now, we have grouped these values under a single struct:
```
canonical_head: CanonicalHead {
cached_head: RwLock<Arc<Snapshot>>,
fork_choice: RwLock<BeaconForkChoice>
}
```
Apart from ergonomics, the only *actual* change here is wrapping the canonical head snapshot in an `Arc`. This means that we no longer need to hold the `cached_head` (`canonical_head`, in old terms) lock when we want to pull some values from it. This was done to avoid deadlock risks by preventing functions from acquiring (and holding) the `cached_head` and `fork_choice` locks simultaneously.
## Breaking Changes
### The `state` (root) field in the `finalized_checkpoint` SSE event
Consider the scenario where epoch `n` is just finalized, but `start_slot(n)` is skipped. There are two state roots we might in the `finalized_checkpoint` SSE event:
1. The state root of the finalized block, which is `get_block(finalized_checkpoint.root).state_root`.
4. The state root at slot of `start_slot(n)`, which would be the state from (1), but "skipped forward" through any skip slots.
Previously, Lighthouse would choose (2). However, we can see that when [Teku generates that event](https://github.com/ConsenSys/teku/blob/de2b2801c89ef5abf983d6bf37867c37fc47121f/data/beaconrestapi/src/main/java/tech/pegasys/teku/beaconrestapi/handlers/v1/events/EventSubscriptionManager.java#L171-L182) it uses [`getStateRootFromBlockRoot`](https://github.com/ConsenSys/teku/blob/de2b2801c89ef5abf983d6bf37867c37fc47121f/data/provider/src/main/java/tech/pegasys/teku/api/ChainDataProvider.java#L336-L341) which uses (1).
I have switched Lighthouse from (2) to (1). I think it's a somewhat arbitrary choice between the two, where (1) is easier to compute and is consistent with Teku.
## Notes for Reviewers
I've renamed `BeaconChain::fork_choice` to `BeaconChain::recompute_head`. Doing this helped ensure I broke all previous uses of fork choice and I also find it more descriptive. It describes an action and can't be confused with trying to get a reference to the `ForkChoice` struct.
I've changed the ordering of SSE events when a block is received. It used to be `[block, finalized, head]` and now it's `[block, head, finalized]`. It was easier this way and I don't think we were making any promises about SSE event ordering so it's not "breaking".
I've made it so fork choice will run when it's first constructed. I did this because I wanted to have a cached version of the last call to `get_head`. Ensuring `get_head` has been run *at least once* means that the cached values doesn't need to wrapped in an `Option`. This was fairly simple, it just involved passing a `slot` to the constructor so it knows *when* it's being run. When loading a fork choice from the store and a slot clock isn't handy I've just used the `slot` that was saved in the `fork_choice_store`. That seems like it would be a faithful representation of the slot when we saved it.
I added the `genesis_time: u64` to the `BeaconChain`. It's small, constant and nice to have around.
Since we're using FC for the fin/just checkpoints, we no longer get the `0x00..00` roots at genesis. You can see I had to remove a work-around in `ef-tests` here: b56be3bc2. I can't find any reason why this would be an issue, if anything I think it'll be better since the genesis-alias has caught us out a few times (0x00..00 isn't actually a real root). Edit: I did find a case where the `network` expected the 0x00..00 alias and patched it here: 3f26ac3e2.
You'll notice a lot of changes in tests. Generally, tests should be functionally equivalent. Here are the things creating the most diff-noise in tests:
- Changing tests to be `tokio::async` tests.
- Adding `.await` to fork choice, block processing and block production functions.
- Refactor of the `canonical_head` "API" provided by the `BeaconChain`. E.g., `chain.canonical_head.cached_head()` instead of `chain.canonical_head.read()`.
- Wrapping `SignedBeaconBlock` in an `Arc`.
- In the `beacon_chain/tests/block_verification`, we can't use the `lazy_static` `CHAIN_SEGMENT` variable anymore since it's generated with an async function. We just generate it in each test, not so efficient but hopefully insignificant.
I had to disable `rayon` concurrent tests in the `fork_choice` tests. This is because the use of `rayon` and `block_on` was causing a panic.
Co-authored-by: Mac L <mjladson@pm.me>
2022-07-03 05:36:50 +00:00
|
|
|
chain
|
|
|
|
|
.canonical_head
|
|
|
|
|
.cached_head()
|
|
|
|
|
.finalized_checkpoint()
|
|
|
|
|
.epoch,
|
2020-12-04 00:18:58 +00:00
|
|
|
2,
|
2020-09-29 03:46:54 +00:00
|
|
|
"precondition: finality"
|
|
|
|
|
);
|
|
|
|
|
assert_eq!(
|
|
|
|
|
chain
|
Use async code when interacting with EL (#3244)
## Overview
This rather extensive PR achieves two primary goals:
1. Uses the finalized/justified checkpoints of fork choice (FC), rather than that of the head state.
2. Refactors fork choice, block production and block processing to `async` functions.
Additionally, it achieves:
- Concurrent forkchoice updates to the EL and cache pruning after a new head is selected.
- Concurrent "block packing" (attestations, etc) and execution payload retrieval during block production.
- Concurrent per-block-processing and execution payload verification during block processing.
- The `Arc`-ification of `SignedBeaconBlock` during block processing (it's never mutated, so why not?):
- I had to do this to deal with sending blocks into spawned tasks.
- Previously we were cloning the beacon block at least 2 times during each block processing, these clones are either removed or turned into cheaper `Arc` clones.
- We were also `Box`-ing and un-`Box`-ing beacon blocks as they moved throughout the networking crate. This is not a big deal, but it's nice to avoid shifting things between the stack and heap.
- Avoids cloning *all the blocks* in *every chain segment* during sync.
- It also has the potential to clean up our code where we need to pass an *owned* block around so we can send it back in the case of an error (I didn't do much of this, my PR is already big enough :sweat_smile:)
- The `BeaconChain::HeadSafetyStatus` struct was removed. It was an old relic from prior merge specs.
For motivation for this change, see https://github.com/sigp/lighthouse/pull/3244#issuecomment-1160963273
## Changes to `canonical_head` and `fork_choice`
Previously, the `BeaconChain` had two separate fields:
```
canonical_head: RwLock<Snapshot>,
fork_choice: RwLock<BeaconForkChoice>
```
Now, we have grouped these values under a single struct:
```
canonical_head: CanonicalHead {
cached_head: RwLock<Arc<Snapshot>>,
fork_choice: RwLock<BeaconForkChoice>
}
```
Apart from ergonomics, the only *actual* change here is wrapping the canonical head snapshot in an `Arc`. This means that we no longer need to hold the `cached_head` (`canonical_head`, in old terms) lock when we want to pull some values from it. This was done to avoid deadlock risks by preventing functions from acquiring (and holding) the `cached_head` and `fork_choice` locks simultaneously.
## Breaking Changes
### The `state` (root) field in the `finalized_checkpoint` SSE event
Consider the scenario where epoch `n` is just finalized, but `start_slot(n)` is skipped. There are two state roots we might in the `finalized_checkpoint` SSE event:
1. The state root of the finalized block, which is `get_block(finalized_checkpoint.root).state_root`.
4. The state root at slot of `start_slot(n)`, which would be the state from (1), but "skipped forward" through any skip slots.
Previously, Lighthouse would choose (2). However, we can see that when [Teku generates that event](https://github.com/ConsenSys/teku/blob/de2b2801c89ef5abf983d6bf37867c37fc47121f/data/beaconrestapi/src/main/java/tech/pegasys/teku/beaconrestapi/handlers/v1/events/EventSubscriptionManager.java#L171-L182) it uses [`getStateRootFromBlockRoot`](https://github.com/ConsenSys/teku/blob/de2b2801c89ef5abf983d6bf37867c37fc47121f/data/provider/src/main/java/tech/pegasys/teku/api/ChainDataProvider.java#L336-L341) which uses (1).
I have switched Lighthouse from (2) to (1). I think it's a somewhat arbitrary choice between the two, where (1) is easier to compute and is consistent with Teku.
## Notes for Reviewers
I've renamed `BeaconChain::fork_choice` to `BeaconChain::recompute_head`. Doing this helped ensure I broke all previous uses of fork choice and I also find it more descriptive. It describes an action and can't be confused with trying to get a reference to the `ForkChoice` struct.
I've changed the ordering of SSE events when a block is received. It used to be `[block, finalized, head]` and now it's `[block, head, finalized]`. It was easier this way and I don't think we were making any promises about SSE event ordering so it's not "breaking".
I've made it so fork choice will run when it's first constructed. I did this because I wanted to have a cached version of the last call to `get_head`. Ensuring `get_head` has been run *at least once* means that the cached values doesn't need to wrapped in an `Option`. This was fairly simple, it just involved passing a `slot` to the constructor so it knows *when* it's being run. When loading a fork choice from the store and a slot clock isn't handy I've just used the `slot` that was saved in the `fork_choice_store`. That seems like it would be a faithful representation of the slot when we saved it.
I added the `genesis_time: u64` to the `BeaconChain`. It's small, constant and nice to have around.
Since we're using FC for the fin/just checkpoints, we no longer get the `0x00..00` roots at genesis. You can see I had to remove a work-around in `ef-tests` here: b56be3bc2. I can't find any reason why this would be an issue, if anything I think it'll be better since the genesis-alias has caught us out a few times (0x00..00 isn't actually a real root). Edit: I did find a case where the `network` expected the 0x00..00 alias and patched it here: 3f26ac3e2.
You'll notice a lot of changes in tests. Generally, tests should be functionally equivalent. Here are the things creating the most diff-noise in tests:
- Changing tests to be `tokio::async` tests.
- Adding `.await` to fork choice, block processing and block production functions.
- Refactor of the `canonical_head` "API" provided by the `BeaconChain`. E.g., `chain.canonical_head.cached_head()` instead of `chain.canonical_head.read()`.
- Wrapping `SignedBeaconBlock` in an `Arc`.
- In the `beacon_chain/tests/block_verification`, we can't use the `lazy_static` `CHAIN_SEGMENT` variable anymore since it's generated with an async function. We just generate it in each test, not so efficient but hopefully insignificant.
I had to disable `rayon` concurrent tests in the `fork_choice` tests. This is because the use of `rayon` and `block_on` was causing a panic.
Co-authored-by: Mac L <mjladson@pm.me>
2022-07-03 05:36:50 +00:00
|
|
|
.canonical_head
|
|
|
|
|
.cached_head()
|
|
|
|
|
.justified_checkpoint()
|
2020-09-29 03:46:54 +00:00
|
|
|
.epoch,
|
2020-12-04 00:18:58 +00:00
|
|
|
3,
|
2020-09-29 03:46:54 +00:00
|
|
|
"precondition: justification"
|
|
|
|
|
);
|
|
|
|
|
|
|
|
|
|
let log = null_logger().unwrap();
|
|
|
|
|
|
2021-08-06 00:47:31 +00:00
|
|
|
let ApiServer {
|
|
|
|
|
server,
|
|
|
|
|
listening_socket,
|
|
|
|
|
shutdown_tx,
|
|
|
|
|
network_rx,
|
|
|
|
|
local_enr,
|
|
|
|
|
external_peer_id,
|
2021-10-11 02:45:06 +00:00
|
|
|
} = create_api_server(chain.clone(), log).await;
|
2020-09-29 03:46:54 +00:00
|
|
|
|
2022-05-16 08:35:59 +00:00
|
|
|
harness.runtime.task_executor.spawn(server, "api_server");
|
2020-09-29 03:46:54 +00:00
|
|
|
|
|
|
|
|
let client = BeaconNodeHttpClient::new(
|
2021-05-04 01:59:51 +00:00
|
|
|
SensitiveUrl::parse(&format!(
|
2020-09-29 03:46:54 +00:00
|
|
|
"http://{}:{}",
|
|
|
|
|
listening_socket.ip(),
|
|
|
|
|
listening_socket.port()
|
|
|
|
|
))
|
|
|
|
|
.unwrap(),
|
2021-07-12 01:47:48 +00:00
|
|
|
Timeouts::set_all(Duration::from_secs(SECONDS_PER_SLOT)),
|
2020-09-29 03:46:54 +00:00
|
|
|
);
|
|
|
|
|
|
|
|
|
|
Self {
|
Use async code when interacting with EL (#3244)
## Overview
This rather extensive PR achieves two primary goals:
1. Uses the finalized/justified checkpoints of fork choice (FC), rather than that of the head state.
2. Refactors fork choice, block production and block processing to `async` functions.
Additionally, it achieves:
- Concurrent forkchoice updates to the EL and cache pruning after a new head is selected.
- Concurrent "block packing" (attestations, etc) and execution payload retrieval during block production.
- Concurrent per-block-processing and execution payload verification during block processing.
- The `Arc`-ification of `SignedBeaconBlock` during block processing (it's never mutated, so why not?):
- I had to do this to deal with sending blocks into spawned tasks.
- Previously we were cloning the beacon block at least 2 times during each block processing, these clones are either removed or turned into cheaper `Arc` clones.
- We were also `Box`-ing and un-`Box`-ing beacon blocks as they moved throughout the networking crate. This is not a big deal, but it's nice to avoid shifting things between the stack and heap.
- Avoids cloning *all the blocks* in *every chain segment* during sync.
- It also has the potential to clean up our code where we need to pass an *owned* block around so we can send it back in the case of an error (I didn't do much of this, my PR is already big enough :sweat_smile:)
- The `BeaconChain::HeadSafetyStatus` struct was removed. It was an old relic from prior merge specs.
For motivation for this change, see https://github.com/sigp/lighthouse/pull/3244#issuecomment-1160963273
## Changes to `canonical_head` and `fork_choice`
Previously, the `BeaconChain` had two separate fields:
```
canonical_head: RwLock<Snapshot>,
fork_choice: RwLock<BeaconForkChoice>
```
Now, we have grouped these values under a single struct:
```
canonical_head: CanonicalHead {
cached_head: RwLock<Arc<Snapshot>>,
fork_choice: RwLock<BeaconForkChoice>
}
```
Apart from ergonomics, the only *actual* change here is wrapping the canonical head snapshot in an `Arc`. This means that we no longer need to hold the `cached_head` (`canonical_head`, in old terms) lock when we want to pull some values from it. This was done to avoid deadlock risks by preventing functions from acquiring (and holding) the `cached_head` and `fork_choice` locks simultaneously.
## Breaking Changes
### The `state` (root) field in the `finalized_checkpoint` SSE event
Consider the scenario where epoch `n` is just finalized, but `start_slot(n)` is skipped. There are two state roots we might in the `finalized_checkpoint` SSE event:
1. The state root of the finalized block, which is `get_block(finalized_checkpoint.root).state_root`.
4. The state root at slot of `start_slot(n)`, which would be the state from (1), but "skipped forward" through any skip slots.
Previously, Lighthouse would choose (2). However, we can see that when [Teku generates that event](https://github.com/ConsenSys/teku/blob/de2b2801c89ef5abf983d6bf37867c37fc47121f/data/beaconrestapi/src/main/java/tech/pegasys/teku/beaconrestapi/handlers/v1/events/EventSubscriptionManager.java#L171-L182) it uses [`getStateRootFromBlockRoot`](https://github.com/ConsenSys/teku/blob/de2b2801c89ef5abf983d6bf37867c37fc47121f/data/provider/src/main/java/tech/pegasys/teku/api/ChainDataProvider.java#L336-L341) which uses (1).
I have switched Lighthouse from (2) to (1). I think it's a somewhat arbitrary choice between the two, where (1) is easier to compute and is consistent with Teku.
## Notes for Reviewers
I've renamed `BeaconChain::fork_choice` to `BeaconChain::recompute_head`. Doing this helped ensure I broke all previous uses of fork choice and I also find it more descriptive. It describes an action and can't be confused with trying to get a reference to the `ForkChoice` struct.
I've changed the ordering of SSE events when a block is received. It used to be `[block, finalized, head]` and now it's `[block, head, finalized]`. It was easier this way and I don't think we were making any promises about SSE event ordering so it's not "breaking".
I've made it so fork choice will run when it's first constructed. I did this because I wanted to have a cached version of the last call to `get_head`. Ensuring `get_head` has been run *at least once* means that the cached values doesn't need to wrapped in an `Option`. This was fairly simple, it just involved passing a `slot` to the constructor so it knows *when* it's being run. When loading a fork choice from the store and a slot clock isn't handy I've just used the `slot` that was saved in the `fork_choice_store`. That seems like it would be a faithful representation of the slot when we saved it.
I added the `genesis_time: u64` to the `BeaconChain`. It's small, constant and nice to have around.
Since we're using FC for the fin/just checkpoints, we no longer get the `0x00..00` roots at genesis. You can see I had to remove a work-around in `ef-tests` here: b56be3bc2. I can't find any reason why this would be an issue, if anything I think it'll be better since the genesis-alias has caught us out a few times (0x00..00 isn't actually a real root). Edit: I did find a case where the `network` expected the 0x00..00 alias and patched it here: 3f26ac3e2.
You'll notice a lot of changes in tests. Generally, tests should be functionally equivalent. Here are the things creating the most diff-noise in tests:
- Changing tests to be `tokio::async` tests.
- Adding `.await` to fork choice, block processing and block production functions.
- Refactor of the `canonical_head` "API" provided by the `BeaconChain`. E.g., `chain.canonical_head.cached_head()` instead of `chain.canonical_head.read()`.
- Wrapping `SignedBeaconBlock` in an `Arc`.
- In the `beacon_chain/tests/block_verification`, we can't use the `lazy_static` `CHAIN_SEGMENT` variable anymore since it's generated with an async function. We just generate it in each test, not so efficient but hopefully insignificant.
I had to disable `rayon` concurrent tests in the `fork_choice` tests. This is because the use of `rayon` and `block_on` was causing a panic.
Co-authored-by: Mac L <mjladson@pm.me>
2022-07-03 05:36:50 +00:00
|
|
|
harness,
|
2020-09-29 03:46:54 +00:00
|
|
|
chain,
|
|
|
|
|
client,
|
|
|
|
|
next_block,
|
2021-06-17 02:10:46 +00:00
|
|
|
reorg_block,
|
2020-09-29 03:46:54 +00:00
|
|
|
attestations,
|
2021-09-25 07:53:58 +00:00
|
|
|
contribution_and_proofs,
|
2020-09-29 03:46:54 +00:00
|
|
|
attester_slashing,
|
|
|
|
|
proposer_slashing,
|
|
|
|
|
voluntary_exit,
|
|
|
|
|
_server_shutdown: shutdown_tx,
|
|
|
|
|
network_rx,
|
2021-08-06 00:47:31 +00:00
|
|
|
local_enr,
|
|
|
|
|
external_peer_id,
|
2020-09-29 03:46:54 +00:00
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
2021-10-11 02:45:06 +00:00
|
|
|
pub async fn new_from_genesis() -> Self {
|
Use async code when interacting with EL (#3244)
## Overview
This rather extensive PR achieves two primary goals:
1. Uses the finalized/justified checkpoints of fork choice (FC), rather than that of the head state.
2. Refactors fork choice, block production and block processing to `async` functions.
Additionally, it achieves:
- Concurrent forkchoice updates to the EL and cache pruning after a new head is selected.
- Concurrent "block packing" (attestations, etc) and execution payload retrieval during block production.
- Concurrent per-block-processing and execution payload verification during block processing.
- The `Arc`-ification of `SignedBeaconBlock` during block processing (it's never mutated, so why not?):
- I had to do this to deal with sending blocks into spawned tasks.
- Previously we were cloning the beacon block at least 2 times during each block processing, these clones are either removed or turned into cheaper `Arc` clones.
- We were also `Box`-ing and un-`Box`-ing beacon blocks as they moved throughout the networking crate. This is not a big deal, but it's nice to avoid shifting things between the stack and heap.
- Avoids cloning *all the blocks* in *every chain segment* during sync.
- It also has the potential to clean up our code where we need to pass an *owned* block around so we can send it back in the case of an error (I didn't do much of this, my PR is already big enough :sweat_smile:)
- The `BeaconChain::HeadSafetyStatus` struct was removed. It was an old relic from prior merge specs.
For motivation for this change, see https://github.com/sigp/lighthouse/pull/3244#issuecomment-1160963273
## Changes to `canonical_head` and `fork_choice`
Previously, the `BeaconChain` had two separate fields:
```
canonical_head: RwLock<Snapshot>,
fork_choice: RwLock<BeaconForkChoice>
```
Now, we have grouped these values under a single struct:
```
canonical_head: CanonicalHead {
cached_head: RwLock<Arc<Snapshot>>,
fork_choice: RwLock<BeaconForkChoice>
}
```
Apart from ergonomics, the only *actual* change here is wrapping the canonical head snapshot in an `Arc`. This means that we no longer need to hold the `cached_head` (`canonical_head`, in old terms) lock when we want to pull some values from it. This was done to avoid deadlock risks by preventing functions from acquiring (and holding) the `cached_head` and `fork_choice` locks simultaneously.
## Breaking Changes
### The `state` (root) field in the `finalized_checkpoint` SSE event
Consider the scenario where epoch `n` is just finalized, but `start_slot(n)` is skipped. There are two state roots we might in the `finalized_checkpoint` SSE event:
1. The state root of the finalized block, which is `get_block(finalized_checkpoint.root).state_root`.
4. The state root at slot of `start_slot(n)`, which would be the state from (1), but "skipped forward" through any skip slots.
Previously, Lighthouse would choose (2). However, we can see that when [Teku generates that event](https://github.com/ConsenSys/teku/blob/de2b2801c89ef5abf983d6bf37867c37fc47121f/data/beaconrestapi/src/main/java/tech/pegasys/teku/beaconrestapi/handlers/v1/events/EventSubscriptionManager.java#L171-L182) it uses [`getStateRootFromBlockRoot`](https://github.com/ConsenSys/teku/blob/de2b2801c89ef5abf983d6bf37867c37fc47121f/data/provider/src/main/java/tech/pegasys/teku/api/ChainDataProvider.java#L336-L341) which uses (1).
I have switched Lighthouse from (2) to (1). I think it's a somewhat arbitrary choice between the two, where (1) is easier to compute and is consistent with Teku.
## Notes for Reviewers
I've renamed `BeaconChain::fork_choice` to `BeaconChain::recompute_head`. Doing this helped ensure I broke all previous uses of fork choice and I also find it more descriptive. It describes an action and can't be confused with trying to get a reference to the `ForkChoice` struct.
I've changed the ordering of SSE events when a block is received. It used to be `[block, finalized, head]` and now it's `[block, head, finalized]`. It was easier this way and I don't think we were making any promises about SSE event ordering so it's not "breaking".
I've made it so fork choice will run when it's first constructed. I did this because I wanted to have a cached version of the last call to `get_head`. Ensuring `get_head` has been run *at least once* means that the cached values doesn't need to wrapped in an `Option`. This was fairly simple, it just involved passing a `slot` to the constructor so it knows *when* it's being run. When loading a fork choice from the store and a slot clock isn't handy I've just used the `slot` that was saved in the `fork_choice_store`. That seems like it would be a faithful representation of the slot when we saved it.
I added the `genesis_time: u64` to the `BeaconChain`. It's small, constant and nice to have around.
Since we're using FC for the fin/just checkpoints, we no longer get the `0x00..00` roots at genesis. You can see I had to remove a work-around in `ef-tests` here: b56be3bc2. I can't find any reason why this would be an issue, if anything I think it'll be better since the genesis-alias has caught us out a few times (0x00..00 isn't actually a real root). Edit: I did find a case where the `network` expected the 0x00..00 alias and patched it here: 3f26ac3e2.
You'll notice a lot of changes in tests. Generally, tests should be functionally equivalent. Here are the things creating the most diff-noise in tests:
- Changing tests to be `tokio::async` tests.
- Adding `.await` to fork choice, block processing and block production functions.
- Refactor of the `canonical_head` "API" provided by the `BeaconChain`. E.g., `chain.canonical_head.cached_head()` instead of `chain.canonical_head.read()`.
- Wrapping `SignedBeaconBlock` in an `Arc`.
- In the `beacon_chain/tests/block_verification`, we can't use the `lazy_static` `CHAIN_SEGMENT` variable anymore since it's generated with an async function. We just generate it in each test, not so efficient but hopefully insignificant.
I had to disable `rayon` concurrent tests in the `fork_choice` tests. This is because the use of `rayon` and `block_on` was causing a panic.
Co-authored-by: Mac L <mjladson@pm.me>
2022-07-03 05:36:50 +00:00
|
|
|
let harness = Arc::new(
|
|
|
|
|
BeaconChainHarness::builder(MainnetEthSpec)
|
|
|
|
|
.default_spec()
|
|
|
|
|
.deterministic_keypairs(VALIDATOR_COUNT)
|
|
|
|
|
.fresh_ephemeral_store()
|
|
|
|
|
.build(),
|
|
|
|
|
);
|
2020-12-04 00:18:58 +00:00
|
|
|
|
|
|
|
|
harness.advance_slot();
|
|
|
|
|
|
Use async code when interacting with EL (#3244)
## Overview
This rather extensive PR achieves two primary goals:
1. Uses the finalized/justified checkpoints of fork choice (FC), rather than that of the head state.
2. Refactors fork choice, block production and block processing to `async` functions.
Additionally, it achieves:
- Concurrent forkchoice updates to the EL and cache pruning after a new head is selected.
- Concurrent "block packing" (attestations, etc) and execution payload retrieval during block production.
- Concurrent per-block-processing and execution payload verification during block processing.
- The `Arc`-ification of `SignedBeaconBlock` during block processing (it's never mutated, so why not?):
- I had to do this to deal with sending blocks into spawned tasks.
- Previously we were cloning the beacon block at least 2 times during each block processing, these clones are either removed or turned into cheaper `Arc` clones.
- We were also `Box`-ing and un-`Box`-ing beacon blocks as they moved throughout the networking crate. This is not a big deal, but it's nice to avoid shifting things between the stack and heap.
- Avoids cloning *all the blocks* in *every chain segment* during sync.
- It also has the potential to clean up our code where we need to pass an *owned* block around so we can send it back in the case of an error (I didn't do much of this, my PR is already big enough :sweat_smile:)
- The `BeaconChain::HeadSafetyStatus` struct was removed. It was an old relic from prior merge specs.
For motivation for this change, see https://github.com/sigp/lighthouse/pull/3244#issuecomment-1160963273
## Changes to `canonical_head` and `fork_choice`
Previously, the `BeaconChain` had two separate fields:
```
canonical_head: RwLock<Snapshot>,
fork_choice: RwLock<BeaconForkChoice>
```
Now, we have grouped these values under a single struct:
```
canonical_head: CanonicalHead {
cached_head: RwLock<Arc<Snapshot>>,
fork_choice: RwLock<BeaconForkChoice>
}
```
Apart from ergonomics, the only *actual* change here is wrapping the canonical head snapshot in an `Arc`. This means that we no longer need to hold the `cached_head` (`canonical_head`, in old terms) lock when we want to pull some values from it. This was done to avoid deadlock risks by preventing functions from acquiring (and holding) the `cached_head` and `fork_choice` locks simultaneously.
## Breaking Changes
### The `state` (root) field in the `finalized_checkpoint` SSE event
Consider the scenario where epoch `n` is just finalized, but `start_slot(n)` is skipped. There are two state roots we might in the `finalized_checkpoint` SSE event:
1. The state root of the finalized block, which is `get_block(finalized_checkpoint.root).state_root`.
4. The state root at slot of `start_slot(n)`, which would be the state from (1), but "skipped forward" through any skip slots.
Previously, Lighthouse would choose (2). However, we can see that when [Teku generates that event](https://github.com/ConsenSys/teku/blob/de2b2801c89ef5abf983d6bf37867c37fc47121f/data/beaconrestapi/src/main/java/tech/pegasys/teku/beaconrestapi/handlers/v1/events/EventSubscriptionManager.java#L171-L182) it uses [`getStateRootFromBlockRoot`](https://github.com/ConsenSys/teku/blob/de2b2801c89ef5abf983d6bf37867c37fc47121f/data/provider/src/main/java/tech/pegasys/teku/api/ChainDataProvider.java#L336-L341) which uses (1).
I have switched Lighthouse from (2) to (1). I think it's a somewhat arbitrary choice between the two, where (1) is easier to compute and is consistent with Teku.
## Notes for Reviewers
I've renamed `BeaconChain::fork_choice` to `BeaconChain::recompute_head`. Doing this helped ensure I broke all previous uses of fork choice and I also find it more descriptive. It describes an action and can't be confused with trying to get a reference to the `ForkChoice` struct.
I've changed the ordering of SSE events when a block is received. It used to be `[block, finalized, head]` and now it's `[block, head, finalized]`. It was easier this way and I don't think we were making any promises about SSE event ordering so it's not "breaking".
I've made it so fork choice will run when it's first constructed. I did this because I wanted to have a cached version of the last call to `get_head`. Ensuring `get_head` has been run *at least once* means that the cached values doesn't need to wrapped in an `Option`. This was fairly simple, it just involved passing a `slot` to the constructor so it knows *when* it's being run. When loading a fork choice from the store and a slot clock isn't handy I've just used the `slot` that was saved in the `fork_choice_store`. That seems like it would be a faithful representation of the slot when we saved it.
I added the `genesis_time: u64` to the `BeaconChain`. It's small, constant and nice to have around.
Since we're using FC for the fin/just checkpoints, we no longer get the `0x00..00` roots at genesis. You can see I had to remove a work-around in `ef-tests` here: b56be3bc2. I can't find any reason why this would be an issue, if anything I think it'll be better since the genesis-alias has caught us out a few times (0x00..00 isn't actually a real root). Edit: I did find a case where the `network` expected the 0x00..00 alias and patched it here: 3f26ac3e2.
You'll notice a lot of changes in tests. Generally, tests should be functionally equivalent. Here are the things creating the most diff-noise in tests:
- Changing tests to be `tokio::async` tests.
- Adding `.await` to fork choice, block processing and block production functions.
- Refactor of the `canonical_head` "API" provided by the `BeaconChain`. E.g., `chain.canonical_head.cached_head()` instead of `chain.canonical_head.read()`.
- Wrapping `SignedBeaconBlock` in an `Arc`.
- In the `beacon_chain/tests/block_verification`, we can't use the `lazy_static` `CHAIN_SEGMENT` variable anymore since it's generated with an async function. We just generate it in each test, not so efficient but hopefully insignificant.
I had to disable `rayon` concurrent tests in the `fork_choice` tests. This is because the use of `rayon` and `block_on` was causing a panic.
Co-authored-by: Mac L <mjladson@pm.me>
2022-07-03 05:36:50 +00:00
|
|
|
let head = harness.chain.head_snapshot();
|
2020-12-04 00:18:58 +00:00
|
|
|
|
Use async code when interacting with EL (#3244)
## Overview
This rather extensive PR achieves two primary goals:
1. Uses the finalized/justified checkpoints of fork choice (FC), rather than that of the head state.
2. Refactors fork choice, block production and block processing to `async` functions.
Additionally, it achieves:
- Concurrent forkchoice updates to the EL and cache pruning after a new head is selected.
- Concurrent "block packing" (attestations, etc) and execution payload retrieval during block production.
- Concurrent per-block-processing and execution payload verification during block processing.
- The `Arc`-ification of `SignedBeaconBlock` during block processing (it's never mutated, so why not?):
- I had to do this to deal with sending blocks into spawned tasks.
- Previously we were cloning the beacon block at least 2 times during each block processing, these clones are either removed or turned into cheaper `Arc` clones.
- We were also `Box`-ing and un-`Box`-ing beacon blocks as they moved throughout the networking crate. This is not a big deal, but it's nice to avoid shifting things between the stack and heap.
- Avoids cloning *all the blocks* in *every chain segment* during sync.
- It also has the potential to clean up our code where we need to pass an *owned* block around so we can send it back in the case of an error (I didn't do much of this, my PR is already big enough :sweat_smile:)
- The `BeaconChain::HeadSafetyStatus` struct was removed. It was an old relic from prior merge specs.
For motivation for this change, see https://github.com/sigp/lighthouse/pull/3244#issuecomment-1160963273
## Changes to `canonical_head` and `fork_choice`
Previously, the `BeaconChain` had two separate fields:
```
canonical_head: RwLock<Snapshot>,
fork_choice: RwLock<BeaconForkChoice>
```
Now, we have grouped these values under a single struct:
```
canonical_head: CanonicalHead {
cached_head: RwLock<Arc<Snapshot>>,
fork_choice: RwLock<BeaconForkChoice>
}
```
Apart from ergonomics, the only *actual* change here is wrapping the canonical head snapshot in an `Arc`. This means that we no longer need to hold the `cached_head` (`canonical_head`, in old terms) lock when we want to pull some values from it. This was done to avoid deadlock risks by preventing functions from acquiring (and holding) the `cached_head` and `fork_choice` locks simultaneously.
## Breaking Changes
### The `state` (root) field in the `finalized_checkpoint` SSE event
Consider the scenario where epoch `n` is just finalized, but `start_slot(n)` is skipped. There are two state roots we might in the `finalized_checkpoint` SSE event:
1. The state root of the finalized block, which is `get_block(finalized_checkpoint.root).state_root`.
4. The state root at slot of `start_slot(n)`, which would be the state from (1), but "skipped forward" through any skip slots.
Previously, Lighthouse would choose (2). However, we can see that when [Teku generates that event](https://github.com/ConsenSys/teku/blob/de2b2801c89ef5abf983d6bf37867c37fc47121f/data/beaconrestapi/src/main/java/tech/pegasys/teku/beaconrestapi/handlers/v1/events/EventSubscriptionManager.java#L171-L182) it uses [`getStateRootFromBlockRoot`](https://github.com/ConsenSys/teku/blob/de2b2801c89ef5abf983d6bf37867c37fc47121f/data/provider/src/main/java/tech/pegasys/teku/api/ChainDataProvider.java#L336-L341) which uses (1).
I have switched Lighthouse from (2) to (1). I think it's a somewhat arbitrary choice between the two, where (1) is easier to compute and is consistent with Teku.
## Notes for Reviewers
I've renamed `BeaconChain::fork_choice` to `BeaconChain::recompute_head`. Doing this helped ensure I broke all previous uses of fork choice and I also find it more descriptive. It describes an action and can't be confused with trying to get a reference to the `ForkChoice` struct.
I've changed the ordering of SSE events when a block is received. It used to be `[block, finalized, head]` and now it's `[block, head, finalized]`. It was easier this way and I don't think we were making any promises about SSE event ordering so it's not "breaking".
I've made it so fork choice will run when it's first constructed. I did this because I wanted to have a cached version of the last call to `get_head`. Ensuring `get_head` has been run *at least once* means that the cached values doesn't need to wrapped in an `Option`. This was fairly simple, it just involved passing a `slot` to the constructor so it knows *when* it's being run. When loading a fork choice from the store and a slot clock isn't handy I've just used the `slot` that was saved in the `fork_choice_store`. That seems like it would be a faithful representation of the slot when we saved it.
I added the `genesis_time: u64` to the `BeaconChain`. It's small, constant and nice to have around.
Since we're using FC for the fin/just checkpoints, we no longer get the `0x00..00` roots at genesis. You can see I had to remove a work-around in `ef-tests` here: b56be3bc2. I can't find any reason why this would be an issue, if anything I think it'll be better since the genesis-alias has caught us out a few times (0x00..00 isn't actually a real root). Edit: I did find a case where the `network` expected the 0x00..00 alias and patched it here: 3f26ac3e2.
You'll notice a lot of changes in tests. Generally, tests should be functionally equivalent. Here are the things creating the most diff-noise in tests:
- Changing tests to be `tokio::async` tests.
- Adding `.await` to fork choice, block processing and block production functions.
- Refactor of the `canonical_head` "API" provided by the `BeaconChain`. E.g., `chain.canonical_head.cached_head()` instead of `chain.canonical_head.read()`.
- Wrapping `SignedBeaconBlock` in an `Arc`.
- In the `beacon_chain/tests/block_verification`, we can't use the `lazy_static` `CHAIN_SEGMENT` variable anymore since it's generated with an async function. We just generate it in each test, not so efficient but hopefully insignificant.
I had to disable `rayon` concurrent tests in the `fork_choice` tests. This is because the use of `rayon` and `block_on` was causing a panic.
Co-authored-by: Mac L <mjladson@pm.me>
2022-07-03 05:36:50 +00:00
|
|
|
let (next_block, _next_state) = harness
|
|
|
|
|
.make_block(head.beacon_state.clone(), harness.chain.slot().unwrap())
|
|
|
|
|
.await;
|
2020-12-04 00:18:58 +00:00
|
|
|
|
2021-06-17 02:10:46 +00:00
|
|
|
// `make_block` adds random graffiti, so this will produce an alternate block
|
Use async code when interacting with EL (#3244)
## Overview
This rather extensive PR achieves two primary goals:
1. Uses the finalized/justified checkpoints of fork choice (FC), rather than that of the head state.
2. Refactors fork choice, block production and block processing to `async` functions.
Additionally, it achieves:
- Concurrent forkchoice updates to the EL and cache pruning after a new head is selected.
- Concurrent "block packing" (attestations, etc) and execution payload retrieval during block production.
- Concurrent per-block-processing and execution payload verification during block processing.
- The `Arc`-ification of `SignedBeaconBlock` during block processing (it's never mutated, so why not?):
- I had to do this to deal with sending blocks into spawned tasks.
- Previously we were cloning the beacon block at least 2 times during each block processing, these clones are either removed or turned into cheaper `Arc` clones.
- We were also `Box`-ing and un-`Box`-ing beacon blocks as they moved throughout the networking crate. This is not a big deal, but it's nice to avoid shifting things between the stack and heap.
- Avoids cloning *all the blocks* in *every chain segment* during sync.
- It also has the potential to clean up our code where we need to pass an *owned* block around so we can send it back in the case of an error (I didn't do much of this, my PR is already big enough :sweat_smile:)
- The `BeaconChain::HeadSafetyStatus` struct was removed. It was an old relic from prior merge specs.
For motivation for this change, see https://github.com/sigp/lighthouse/pull/3244#issuecomment-1160963273
## Changes to `canonical_head` and `fork_choice`
Previously, the `BeaconChain` had two separate fields:
```
canonical_head: RwLock<Snapshot>,
fork_choice: RwLock<BeaconForkChoice>
```
Now, we have grouped these values under a single struct:
```
canonical_head: CanonicalHead {
cached_head: RwLock<Arc<Snapshot>>,
fork_choice: RwLock<BeaconForkChoice>
}
```
Apart from ergonomics, the only *actual* change here is wrapping the canonical head snapshot in an `Arc`. This means that we no longer need to hold the `cached_head` (`canonical_head`, in old terms) lock when we want to pull some values from it. This was done to avoid deadlock risks by preventing functions from acquiring (and holding) the `cached_head` and `fork_choice` locks simultaneously.
## Breaking Changes
### The `state` (root) field in the `finalized_checkpoint` SSE event
Consider the scenario where epoch `n` is just finalized, but `start_slot(n)` is skipped. There are two state roots we might in the `finalized_checkpoint` SSE event:
1. The state root of the finalized block, which is `get_block(finalized_checkpoint.root).state_root`.
4. The state root at slot of `start_slot(n)`, which would be the state from (1), but "skipped forward" through any skip slots.
Previously, Lighthouse would choose (2). However, we can see that when [Teku generates that event](https://github.com/ConsenSys/teku/blob/de2b2801c89ef5abf983d6bf37867c37fc47121f/data/beaconrestapi/src/main/java/tech/pegasys/teku/beaconrestapi/handlers/v1/events/EventSubscriptionManager.java#L171-L182) it uses [`getStateRootFromBlockRoot`](https://github.com/ConsenSys/teku/blob/de2b2801c89ef5abf983d6bf37867c37fc47121f/data/provider/src/main/java/tech/pegasys/teku/api/ChainDataProvider.java#L336-L341) which uses (1).
I have switched Lighthouse from (2) to (1). I think it's a somewhat arbitrary choice between the two, where (1) is easier to compute and is consistent with Teku.
## Notes for Reviewers
I've renamed `BeaconChain::fork_choice` to `BeaconChain::recompute_head`. Doing this helped ensure I broke all previous uses of fork choice and I also find it more descriptive. It describes an action and can't be confused with trying to get a reference to the `ForkChoice` struct.
I've changed the ordering of SSE events when a block is received. It used to be `[block, finalized, head]` and now it's `[block, head, finalized]`. It was easier this way and I don't think we were making any promises about SSE event ordering so it's not "breaking".
I've made it so fork choice will run when it's first constructed. I did this because I wanted to have a cached version of the last call to `get_head`. Ensuring `get_head` has been run *at least once* means that the cached values doesn't need to wrapped in an `Option`. This was fairly simple, it just involved passing a `slot` to the constructor so it knows *when* it's being run. When loading a fork choice from the store and a slot clock isn't handy I've just used the `slot` that was saved in the `fork_choice_store`. That seems like it would be a faithful representation of the slot when we saved it.
I added the `genesis_time: u64` to the `BeaconChain`. It's small, constant and nice to have around.
Since we're using FC for the fin/just checkpoints, we no longer get the `0x00..00` roots at genesis. You can see I had to remove a work-around in `ef-tests` here: b56be3bc2. I can't find any reason why this would be an issue, if anything I think it'll be better since the genesis-alias has caught us out a few times (0x00..00 isn't actually a real root). Edit: I did find a case where the `network` expected the 0x00..00 alias and patched it here: 3f26ac3e2.
You'll notice a lot of changes in tests. Generally, tests should be functionally equivalent. Here are the things creating the most diff-noise in tests:
- Changing tests to be `tokio::async` tests.
- Adding `.await` to fork choice, block processing and block production functions.
- Refactor of the `canonical_head` "API" provided by the `BeaconChain`. E.g., `chain.canonical_head.cached_head()` instead of `chain.canonical_head.read()`.
- Wrapping `SignedBeaconBlock` in an `Arc`.
- In the `beacon_chain/tests/block_verification`, we can't use the `lazy_static` `CHAIN_SEGMENT` variable anymore since it's generated with an async function. We just generate it in each test, not so efficient but hopefully insignificant.
I had to disable `rayon` concurrent tests in the `fork_choice` tests. This is because the use of `rayon` and `block_on` was causing a panic.
Co-authored-by: Mac L <mjladson@pm.me>
2022-07-03 05:36:50 +00:00
|
|
|
let (reorg_block, _reorg_state) = harness
|
|
|
|
|
.make_block(head.beacon_state.clone(), harness.chain.slot().unwrap())
|
|
|
|
|
.await;
|
2021-06-17 02:10:46 +00:00
|
|
|
|
2021-03-17 05:09:57 +00:00
|
|
|
let head_state_root = head.beacon_state_root();
|
2020-12-04 00:18:58 +00:00
|
|
|
let attestations = harness
|
|
|
|
|
.get_unaggregated_attestations(
|
|
|
|
|
&AttestationStrategy::AllValidators,
|
|
|
|
|
&head.beacon_state,
|
2021-03-17 05:09:57 +00:00
|
|
|
head_state_root,
|
2020-12-04 00:18:58 +00:00
|
|
|
head.beacon_block_root,
|
|
|
|
|
harness.chain.slot().unwrap(),
|
|
|
|
|
)
|
|
|
|
|
.into_iter()
|
2022-05-16 01:59:47 +00:00
|
|
|
.flat_map(|vec| vec.into_iter().map(|(attestation, _subnet_id)| attestation))
|
2020-12-04 00:18:58 +00:00
|
|
|
.collect::<Vec<_>>();
|
|
|
|
|
|
|
|
|
|
let attester_slashing = harness.make_attester_slashing(vec![0, 1]);
|
|
|
|
|
let proposer_slashing = harness.make_proposer_slashing(2);
|
|
|
|
|
let voluntary_exit = harness.make_voluntary_exit(3, harness.chain.epoch().unwrap());
|
|
|
|
|
|
2021-08-06 00:47:31 +00:00
|
|
|
let chain = harness.chain.clone();
|
2020-12-04 00:18:58 +00:00
|
|
|
|
|
|
|
|
let log = null_logger().unwrap();
|
|
|
|
|
|
2021-08-06 00:47:31 +00:00
|
|
|
let ApiServer {
|
|
|
|
|
server,
|
|
|
|
|
listening_socket,
|
|
|
|
|
shutdown_tx,
|
|
|
|
|
network_rx,
|
|
|
|
|
local_enr,
|
|
|
|
|
external_peer_id,
|
2021-10-11 02:45:06 +00:00
|
|
|
} = create_api_server(chain.clone(), log).await;
|
2020-12-04 00:18:58 +00:00
|
|
|
|
2022-05-16 08:35:59 +00:00
|
|
|
harness.runtime.task_executor.spawn(server, "api_server");
|
2020-12-04 00:18:58 +00:00
|
|
|
|
|
|
|
|
let client = BeaconNodeHttpClient::new(
|
2021-05-04 01:59:51 +00:00
|
|
|
SensitiveUrl::parse(&format!(
|
2020-12-04 00:18:58 +00:00
|
|
|
"http://{}:{}",
|
|
|
|
|
listening_socket.ip(),
|
|
|
|
|
listening_socket.port()
|
|
|
|
|
))
|
|
|
|
|
.unwrap(),
|
2021-07-12 01:47:48 +00:00
|
|
|
Timeouts::set_all(Duration::from_secs(SECONDS_PER_SLOT)),
|
2020-12-04 00:18:58 +00:00
|
|
|
);
|
|
|
|
|
|
|
|
|
|
Self {
|
Use async code when interacting with EL (#3244)
## Overview
This rather extensive PR achieves two primary goals:
1. Uses the finalized/justified checkpoints of fork choice (FC), rather than that of the head state.
2. Refactors fork choice, block production and block processing to `async` functions.
Additionally, it achieves:
- Concurrent forkchoice updates to the EL and cache pruning after a new head is selected.
- Concurrent "block packing" (attestations, etc) and execution payload retrieval during block production.
- Concurrent per-block-processing and execution payload verification during block processing.
- The `Arc`-ification of `SignedBeaconBlock` during block processing (it's never mutated, so why not?):
- I had to do this to deal with sending blocks into spawned tasks.
- Previously we were cloning the beacon block at least 2 times during each block processing, these clones are either removed or turned into cheaper `Arc` clones.
- We were also `Box`-ing and un-`Box`-ing beacon blocks as they moved throughout the networking crate. This is not a big deal, but it's nice to avoid shifting things between the stack and heap.
- Avoids cloning *all the blocks* in *every chain segment* during sync.
- It also has the potential to clean up our code where we need to pass an *owned* block around so we can send it back in the case of an error (I didn't do much of this, my PR is already big enough :sweat_smile:)
- The `BeaconChain::HeadSafetyStatus` struct was removed. It was an old relic from prior merge specs.
For motivation for this change, see https://github.com/sigp/lighthouse/pull/3244#issuecomment-1160963273
## Changes to `canonical_head` and `fork_choice`
Previously, the `BeaconChain` had two separate fields:
```
canonical_head: RwLock<Snapshot>,
fork_choice: RwLock<BeaconForkChoice>
```
Now, we have grouped these values under a single struct:
```
canonical_head: CanonicalHead {
cached_head: RwLock<Arc<Snapshot>>,
fork_choice: RwLock<BeaconForkChoice>
}
```
Apart from ergonomics, the only *actual* change here is wrapping the canonical head snapshot in an `Arc`. This means that we no longer need to hold the `cached_head` (`canonical_head`, in old terms) lock when we want to pull some values from it. This was done to avoid deadlock risks by preventing functions from acquiring (and holding) the `cached_head` and `fork_choice` locks simultaneously.
## Breaking Changes
### The `state` (root) field in the `finalized_checkpoint` SSE event
Consider the scenario where epoch `n` is just finalized, but `start_slot(n)` is skipped. There are two state roots we might in the `finalized_checkpoint` SSE event:
1. The state root of the finalized block, which is `get_block(finalized_checkpoint.root).state_root`.
4. The state root at slot of `start_slot(n)`, which would be the state from (1), but "skipped forward" through any skip slots.
Previously, Lighthouse would choose (2). However, we can see that when [Teku generates that event](https://github.com/ConsenSys/teku/blob/de2b2801c89ef5abf983d6bf37867c37fc47121f/data/beaconrestapi/src/main/java/tech/pegasys/teku/beaconrestapi/handlers/v1/events/EventSubscriptionManager.java#L171-L182) it uses [`getStateRootFromBlockRoot`](https://github.com/ConsenSys/teku/blob/de2b2801c89ef5abf983d6bf37867c37fc47121f/data/provider/src/main/java/tech/pegasys/teku/api/ChainDataProvider.java#L336-L341) which uses (1).
I have switched Lighthouse from (2) to (1). I think it's a somewhat arbitrary choice between the two, where (1) is easier to compute and is consistent with Teku.
## Notes for Reviewers
I've renamed `BeaconChain::fork_choice` to `BeaconChain::recompute_head`. Doing this helped ensure I broke all previous uses of fork choice and I also find it more descriptive. It describes an action and can't be confused with trying to get a reference to the `ForkChoice` struct.
I've changed the ordering of SSE events when a block is received. It used to be `[block, finalized, head]` and now it's `[block, head, finalized]`. It was easier this way and I don't think we were making any promises about SSE event ordering so it's not "breaking".
I've made it so fork choice will run when it's first constructed. I did this because I wanted to have a cached version of the last call to `get_head`. Ensuring `get_head` has been run *at least once* means that the cached values doesn't need to wrapped in an `Option`. This was fairly simple, it just involved passing a `slot` to the constructor so it knows *when* it's being run. When loading a fork choice from the store and a slot clock isn't handy I've just used the `slot` that was saved in the `fork_choice_store`. That seems like it would be a faithful representation of the slot when we saved it.
I added the `genesis_time: u64` to the `BeaconChain`. It's small, constant and nice to have around.
Since we're using FC for the fin/just checkpoints, we no longer get the `0x00..00` roots at genesis. You can see I had to remove a work-around in `ef-tests` here: b56be3bc2. I can't find any reason why this would be an issue, if anything I think it'll be better since the genesis-alias has caught us out a few times (0x00..00 isn't actually a real root). Edit: I did find a case where the `network` expected the 0x00..00 alias and patched it here: 3f26ac3e2.
You'll notice a lot of changes in tests. Generally, tests should be functionally equivalent. Here are the things creating the most diff-noise in tests:
- Changing tests to be `tokio::async` tests.
- Adding `.await` to fork choice, block processing and block production functions.
- Refactor of the `canonical_head` "API" provided by the `BeaconChain`. E.g., `chain.canonical_head.cached_head()` instead of `chain.canonical_head.read()`.
- Wrapping `SignedBeaconBlock` in an `Arc`.
- In the `beacon_chain/tests/block_verification`, we can't use the `lazy_static` `CHAIN_SEGMENT` variable anymore since it's generated with an async function. We just generate it in each test, not so efficient but hopefully insignificant.
I had to disable `rayon` concurrent tests in the `fork_choice` tests. This is because the use of `rayon` and `block_on` was causing a panic.
Co-authored-by: Mac L <mjladson@pm.me>
2022-07-03 05:36:50 +00:00
|
|
|
harness,
|
2020-12-04 00:18:58 +00:00
|
|
|
chain,
|
|
|
|
|
client,
|
|
|
|
|
next_block,
|
2021-06-17 02:10:46 +00:00
|
|
|
reorg_block,
|
2020-12-04 00:18:58 +00:00
|
|
|
attestations,
|
2021-09-25 07:53:58 +00:00
|
|
|
contribution_and_proofs: vec![],
|
2020-12-04 00:18:58 +00:00
|
|
|
attester_slashing,
|
|
|
|
|
proposer_slashing,
|
|
|
|
|
voluntary_exit,
|
|
|
|
|
_server_shutdown: shutdown_tx,
|
|
|
|
|
network_rx,
|
2021-08-06 00:47:31 +00:00
|
|
|
local_enr,
|
|
|
|
|
external_peer_id,
|
2020-12-04 00:18:58 +00:00
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
Use async code when interacting with EL (#3244)
## Overview
This rather extensive PR achieves two primary goals:
1. Uses the finalized/justified checkpoints of fork choice (FC), rather than that of the head state.
2. Refactors fork choice, block production and block processing to `async` functions.
Additionally, it achieves:
- Concurrent forkchoice updates to the EL and cache pruning after a new head is selected.
- Concurrent "block packing" (attestations, etc) and execution payload retrieval during block production.
- Concurrent per-block-processing and execution payload verification during block processing.
- The `Arc`-ification of `SignedBeaconBlock` during block processing (it's never mutated, so why not?):
- I had to do this to deal with sending blocks into spawned tasks.
- Previously we were cloning the beacon block at least 2 times during each block processing, these clones are either removed or turned into cheaper `Arc` clones.
- We were also `Box`-ing and un-`Box`-ing beacon blocks as they moved throughout the networking crate. This is not a big deal, but it's nice to avoid shifting things between the stack and heap.
- Avoids cloning *all the blocks* in *every chain segment* during sync.
- It also has the potential to clean up our code where we need to pass an *owned* block around so we can send it back in the case of an error (I didn't do much of this, my PR is already big enough :sweat_smile:)
- The `BeaconChain::HeadSafetyStatus` struct was removed. It was an old relic from prior merge specs.
For motivation for this change, see https://github.com/sigp/lighthouse/pull/3244#issuecomment-1160963273
## Changes to `canonical_head` and `fork_choice`
Previously, the `BeaconChain` had two separate fields:
```
canonical_head: RwLock<Snapshot>,
fork_choice: RwLock<BeaconForkChoice>
```
Now, we have grouped these values under a single struct:
```
canonical_head: CanonicalHead {
cached_head: RwLock<Arc<Snapshot>>,
fork_choice: RwLock<BeaconForkChoice>
}
```
Apart from ergonomics, the only *actual* change here is wrapping the canonical head snapshot in an `Arc`. This means that we no longer need to hold the `cached_head` (`canonical_head`, in old terms) lock when we want to pull some values from it. This was done to avoid deadlock risks by preventing functions from acquiring (and holding) the `cached_head` and `fork_choice` locks simultaneously.
## Breaking Changes
### The `state` (root) field in the `finalized_checkpoint` SSE event
Consider the scenario where epoch `n` is just finalized, but `start_slot(n)` is skipped. There are two state roots we might in the `finalized_checkpoint` SSE event:
1. The state root of the finalized block, which is `get_block(finalized_checkpoint.root).state_root`.
4. The state root at slot of `start_slot(n)`, which would be the state from (1), but "skipped forward" through any skip slots.
Previously, Lighthouse would choose (2). However, we can see that when [Teku generates that event](https://github.com/ConsenSys/teku/blob/de2b2801c89ef5abf983d6bf37867c37fc47121f/data/beaconrestapi/src/main/java/tech/pegasys/teku/beaconrestapi/handlers/v1/events/EventSubscriptionManager.java#L171-L182) it uses [`getStateRootFromBlockRoot`](https://github.com/ConsenSys/teku/blob/de2b2801c89ef5abf983d6bf37867c37fc47121f/data/provider/src/main/java/tech/pegasys/teku/api/ChainDataProvider.java#L336-L341) which uses (1).
I have switched Lighthouse from (2) to (1). I think it's a somewhat arbitrary choice between the two, where (1) is easier to compute and is consistent with Teku.
## Notes for Reviewers
I've renamed `BeaconChain::fork_choice` to `BeaconChain::recompute_head`. Doing this helped ensure I broke all previous uses of fork choice and I also find it more descriptive. It describes an action and can't be confused with trying to get a reference to the `ForkChoice` struct.
I've changed the ordering of SSE events when a block is received. It used to be `[block, finalized, head]` and now it's `[block, head, finalized]`. It was easier this way and I don't think we were making any promises about SSE event ordering so it's not "breaking".
I've made it so fork choice will run when it's first constructed. I did this because I wanted to have a cached version of the last call to `get_head`. Ensuring `get_head` has been run *at least once* means that the cached values doesn't need to wrapped in an `Option`. This was fairly simple, it just involved passing a `slot` to the constructor so it knows *when* it's being run. When loading a fork choice from the store and a slot clock isn't handy I've just used the `slot` that was saved in the `fork_choice_store`. That seems like it would be a faithful representation of the slot when we saved it.
I added the `genesis_time: u64` to the `BeaconChain`. It's small, constant and nice to have around.
Since we're using FC for the fin/just checkpoints, we no longer get the `0x00..00` roots at genesis. You can see I had to remove a work-around in `ef-tests` here: b56be3bc2. I can't find any reason why this would be an issue, if anything I think it'll be better since the genesis-alias has caught us out a few times (0x00..00 isn't actually a real root). Edit: I did find a case where the `network` expected the 0x00..00 alias and patched it here: 3f26ac3e2.
You'll notice a lot of changes in tests. Generally, tests should be functionally equivalent. Here are the things creating the most diff-noise in tests:
- Changing tests to be `tokio::async` tests.
- Adding `.await` to fork choice, block processing and block production functions.
- Refactor of the `canonical_head` "API" provided by the `BeaconChain`. E.g., `chain.canonical_head.cached_head()` instead of `chain.canonical_head.read()`.
- Wrapping `SignedBeaconBlock` in an `Arc`.
- In the `beacon_chain/tests/block_verification`, we can't use the `lazy_static` `CHAIN_SEGMENT` variable anymore since it's generated with an async function. We just generate it in each test, not so efficient but hopefully insignificant.
I had to disable `rayon` concurrent tests in the `fork_choice` tests. This is because the use of `rayon` and `block_on` was causing a panic.
Co-authored-by: Mac L <mjladson@pm.me>
2022-07-03 05:36:50 +00:00
|
|
|
fn validator_keypairs(&self) -> &[Keypair] {
|
|
|
|
|
&self.harness.validator_keypairs
|
|
|
|
|
}
|
|
|
|
|
|
2020-09-29 03:46:54 +00:00
|
|
|
fn skip_slots(self, count: u64) -> Self {
|
|
|
|
|
for _ in 0..count {
|
|
|
|
|
self.chain
|
|
|
|
|
.slot_clock
|
|
|
|
|
.set_slot(self.chain.slot().unwrap().as_u64() + 1);
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
self
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
fn interesting_state_ids(&self) -> Vec<StateId> {
|
|
|
|
|
let mut ids = vec![
|
|
|
|
|
StateId::Head,
|
|
|
|
|
StateId::Genesis,
|
|
|
|
|
StateId::Finalized,
|
|
|
|
|
StateId::Justified,
|
|
|
|
|
StateId::Slot(Slot::new(0)),
|
|
|
|
|
StateId::Slot(Slot::new(32)),
|
|
|
|
|
StateId::Slot(Slot::from(SKIPPED_SLOTS[0])),
|
|
|
|
|
StateId::Slot(Slot::from(SKIPPED_SLOTS[1])),
|
|
|
|
|
StateId::Slot(Slot::from(SKIPPED_SLOTS[2])),
|
|
|
|
|
StateId::Slot(Slot::from(SKIPPED_SLOTS[3])),
|
|
|
|
|
StateId::Root(Hash256::zero()),
|
|
|
|
|
];
|
Use async code when interacting with EL (#3244)
## Overview
This rather extensive PR achieves two primary goals:
1. Uses the finalized/justified checkpoints of fork choice (FC), rather than that of the head state.
2. Refactors fork choice, block production and block processing to `async` functions.
Additionally, it achieves:
- Concurrent forkchoice updates to the EL and cache pruning after a new head is selected.
- Concurrent "block packing" (attestations, etc) and execution payload retrieval during block production.
- Concurrent per-block-processing and execution payload verification during block processing.
- The `Arc`-ification of `SignedBeaconBlock` during block processing (it's never mutated, so why not?):
- I had to do this to deal with sending blocks into spawned tasks.
- Previously we were cloning the beacon block at least 2 times during each block processing, these clones are either removed or turned into cheaper `Arc` clones.
- We were also `Box`-ing and un-`Box`-ing beacon blocks as they moved throughout the networking crate. This is not a big deal, but it's nice to avoid shifting things between the stack and heap.
- Avoids cloning *all the blocks* in *every chain segment* during sync.
- It also has the potential to clean up our code where we need to pass an *owned* block around so we can send it back in the case of an error (I didn't do much of this, my PR is already big enough :sweat_smile:)
- The `BeaconChain::HeadSafetyStatus` struct was removed. It was an old relic from prior merge specs.
For motivation for this change, see https://github.com/sigp/lighthouse/pull/3244#issuecomment-1160963273
## Changes to `canonical_head` and `fork_choice`
Previously, the `BeaconChain` had two separate fields:
```
canonical_head: RwLock<Snapshot>,
fork_choice: RwLock<BeaconForkChoice>
```
Now, we have grouped these values under a single struct:
```
canonical_head: CanonicalHead {
cached_head: RwLock<Arc<Snapshot>>,
fork_choice: RwLock<BeaconForkChoice>
}
```
Apart from ergonomics, the only *actual* change here is wrapping the canonical head snapshot in an `Arc`. This means that we no longer need to hold the `cached_head` (`canonical_head`, in old terms) lock when we want to pull some values from it. This was done to avoid deadlock risks by preventing functions from acquiring (and holding) the `cached_head` and `fork_choice` locks simultaneously.
## Breaking Changes
### The `state` (root) field in the `finalized_checkpoint` SSE event
Consider the scenario where epoch `n` is just finalized, but `start_slot(n)` is skipped. There are two state roots we might in the `finalized_checkpoint` SSE event:
1. The state root of the finalized block, which is `get_block(finalized_checkpoint.root).state_root`.
4. The state root at slot of `start_slot(n)`, which would be the state from (1), but "skipped forward" through any skip slots.
Previously, Lighthouse would choose (2). However, we can see that when [Teku generates that event](https://github.com/ConsenSys/teku/blob/de2b2801c89ef5abf983d6bf37867c37fc47121f/data/beaconrestapi/src/main/java/tech/pegasys/teku/beaconrestapi/handlers/v1/events/EventSubscriptionManager.java#L171-L182) it uses [`getStateRootFromBlockRoot`](https://github.com/ConsenSys/teku/blob/de2b2801c89ef5abf983d6bf37867c37fc47121f/data/provider/src/main/java/tech/pegasys/teku/api/ChainDataProvider.java#L336-L341) which uses (1).
I have switched Lighthouse from (2) to (1). I think it's a somewhat arbitrary choice between the two, where (1) is easier to compute and is consistent with Teku.
## Notes for Reviewers
I've renamed `BeaconChain::fork_choice` to `BeaconChain::recompute_head`. Doing this helped ensure I broke all previous uses of fork choice and I also find it more descriptive. It describes an action and can't be confused with trying to get a reference to the `ForkChoice` struct.
I've changed the ordering of SSE events when a block is received. It used to be `[block, finalized, head]` and now it's `[block, head, finalized]`. It was easier this way and I don't think we were making any promises about SSE event ordering so it's not "breaking".
I've made it so fork choice will run when it's first constructed. I did this because I wanted to have a cached version of the last call to `get_head`. Ensuring `get_head` has been run *at least once* means that the cached values doesn't need to wrapped in an `Option`. This was fairly simple, it just involved passing a `slot` to the constructor so it knows *when* it's being run. When loading a fork choice from the store and a slot clock isn't handy I've just used the `slot` that was saved in the `fork_choice_store`. That seems like it would be a faithful representation of the slot when we saved it.
I added the `genesis_time: u64` to the `BeaconChain`. It's small, constant and nice to have around.
Since we're using FC for the fin/just checkpoints, we no longer get the `0x00..00` roots at genesis. You can see I had to remove a work-around in `ef-tests` here: b56be3bc2. I can't find any reason why this would be an issue, if anything I think it'll be better since the genesis-alias has caught us out a few times (0x00..00 isn't actually a real root). Edit: I did find a case where the `network` expected the 0x00..00 alias and patched it here: 3f26ac3e2.
You'll notice a lot of changes in tests. Generally, tests should be functionally equivalent. Here are the things creating the most diff-noise in tests:
- Changing tests to be `tokio::async` tests.
- Adding `.await` to fork choice, block processing and block production functions.
- Refactor of the `canonical_head` "API" provided by the `BeaconChain`. E.g., `chain.canonical_head.cached_head()` instead of `chain.canonical_head.read()`.
- Wrapping `SignedBeaconBlock` in an `Arc`.
- In the `beacon_chain/tests/block_verification`, we can't use the `lazy_static` `CHAIN_SEGMENT` variable anymore since it's generated with an async function. We just generate it in each test, not so efficient but hopefully insignificant.
I had to disable `rayon` concurrent tests in the `fork_choice` tests. This is because the use of `rayon` and `block_on` was causing a panic.
Co-authored-by: Mac L <mjladson@pm.me>
2022-07-03 05:36:50 +00:00
|
|
|
ids.push(StateId::Root(
|
|
|
|
|
self.chain.canonical_head.cached_head().head_state_root(),
|
|
|
|
|
));
|
2020-09-29 03:46:54 +00:00
|
|
|
ids
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
fn interesting_block_ids(&self) -> Vec<BlockId> {
|
|
|
|
|
let mut ids = vec![
|
|
|
|
|
BlockId::Head,
|
|
|
|
|
BlockId::Genesis,
|
|
|
|
|
BlockId::Finalized,
|
|
|
|
|
BlockId::Justified,
|
|
|
|
|
BlockId::Slot(Slot::new(0)),
|
|
|
|
|
BlockId::Slot(Slot::new(32)),
|
|
|
|
|
BlockId::Slot(Slot::from(SKIPPED_SLOTS[0])),
|
|
|
|
|
BlockId::Slot(Slot::from(SKIPPED_SLOTS[1])),
|
|
|
|
|
BlockId::Slot(Slot::from(SKIPPED_SLOTS[2])),
|
|
|
|
|
BlockId::Slot(Slot::from(SKIPPED_SLOTS[3])),
|
|
|
|
|
BlockId::Root(Hash256::zero()),
|
|
|
|
|
];
|
Use async code when interacting with EL (#3244)
## Overview
This rather extensive PR achieves two primary goals:
1. Uses the finalized/justified checkpoints of fork choice (FC), rather than that of the head state.
2. Refactors fork choice, block production and block processing to `async` functions.
Additionally, it achieves:
- Concurrent forkchoice updates to the EL and cache pruning after a new head is selected.
- Concurrent "block packing" (attestations, etc) and execution payload retrieval during block production.
- Concurrent per-block-processing and execution payload verification during block processing.
- The `Arc`-ification of `SignedBeaconBlock` during block processing (it's never mutated, so why not?):
- I had to do this to deal with sending blocks into spawned tasks.
- Previously we were cloning the beacon block at least 2 times during each block processing, these clones are either removed or turned into cheaper `Arc` clones.
- We were also `Box`-ing and un-`Box`-ing beacon blocks as they moved throughout the networking crate. This is not a big deal, but it's nice to avoid shifting things between the stack and heap.
- Avoids cloning *all the blocks* in *every chain segment* during sync.
- It also has the potential to clean up our code where we need to pass an *owned* block around so we can send it back in the case of an error (I didn't do much of this, my PR is already big enough :sweat_smile:)
- The `BeaconChain::HeadSafetyStatus` struct was removed. It was an old relic from prior merge specs.
For motivation for this change, see https://github.com/sigp/lighthouse/pull/3244#issuecomment-1160963273
## Changes to `canonical_head` and `fork_choice`
Previously, the `BeaconChain` had two separate fields:
```
canonical_head: RwLock<Snapshot>,
fork_choice: RwLock<BeaconForkChoice>
```
Now, we have grouped these values under a single struct:
```
canonical_head: CanonicalHead {
cached_head: RwLock<Arc<Snapshot>>,
fork_choice: RwLock<BeaconForkChoice>
}
```
Apart from ergonomics, the only *actual* change here is wrapping the canonical head snapshot in an `Arc`. This means that we no longer need to hold the `cached_head` (`canonical_head`, in old terms) lock when we want to pull some values from it. This was done to avoid deadlock risks by preventing functions from acquiring (and holding) the `cached_head` and `fork_choice` locks simultaneously.
## Breaking Changes
### The `state` (root) field in the `finalized_checkpoint` SSE event
Consider the scenario where epoch `n` is just finalized, but `start_slot(n)` is skipped. There are two state roots we might in the `finalized_checkpoint` SSE event:
1. The state root of the finalized block, which is `get_block(finalized_checkpoint.root).state_root`.
4. The state root at slot of `start_slot(n)`, which would be the state from (1), but "skipped forward" through any skip slots.
Previously, Lighthouse would choose (2). However, we can see that when [Teku generates that event](https://github.com/ConsenSys/teku/blob/de2b2801c89ef5abf983d6bf37867c37fc47121f/data/beaconrestapi/src/main/java/tech/pegasys/teku/beaconrestapi/handlers/v1/events/EventSubscriptionManager.java#L171-L182) it uses [`getStateRootFromBlockRoot`](https://github.com/ConsenSys/teku/blob/de2b2801c89ef5abf983d6bf37867c37fc47121f/data/provider/src/main/java/tech/pegasys/teku/api/ChainDataProvider.java#L336-L341) which uses (1).
I have switched Lighthouse from (2) to (1). I think it's a somewhat arbitrary choice between the two, where (1) is easier to compute and is consistent with Teku.
## Notes for Reviewers
I've renamed `BeaconChain::fork_choice` to `BeaconChain::recompute_head`. Doing this helped ensure I broke all previous uses of fork choice and I also find it more descriptive. It describes an action and can't be confused with trying to get a reference to the `ForkChoice` struct.
I've changed the ordering of SSE events when a block is received. It used to be `[block, finalized, head]` and now it's `[block, head, finalized]`. It was easier this way and I don't think we were making any promises about SSE event ordering so it's not "breaking".
I've made it so fork choice will run when it's first constructed. I did this because I wanted to have a cached version of the last call to `get_head`. Ensuring `get_head` has been run *at least once* means that the cached values doesn't need to wrapped in an `Option`. This was fairly simple, it just involved passing a `slot` to the constructor so it knows *when* it's being run. When loading a fork choice from the store and a slot clock isn't handy I've just used the `slot` that was saved in the `fork_choice_store`. That seems like it would be a faithful representation of the slot when we saved it.
I added the `genesis_time: u64` to the `BeaconChain`. It's small, constant and nice to have around.
Since we're using FC for the fin/just checkpoints, we no longer get the `0x00..00` roots at genesis. You can see I had to remove a work-around in `ef-tests` here: b56be3bc2. I can't find any reason why this would be an issue, if anything I think it'll be better since the genesis-alias has caught us out a few times (0x00..00 isn't actually a real root). Edit: I did find a case where the `network` expected the 0x00..00 alias and patched it here: 3f26ac3e2.
You'll notice a lot of changes in tests. Generally, tests should be functionally equivalent. Here are the things creating the most diff-noise in tests:
- Changing tests to be `tokio::async` tests.
- Adding `.await` to fork choice, block processing and block production functions.
- Refactor of the `canonical_head` "API" provided by the `BeaconChain`. E.g., `chain.canonical_head.cached_head()` instead of `chain.canonical_head.read()`.
- Wrapping `SignedBeaconBlock` in an `Arc`.
- In the `beacon_chain/tests/block_verification`, we can't use the `lazy_static` `CHAIN_SEGMENT` variable anymore since it's generated with an async function. We just generate it in each test, not so efficient but hopefully insignificant.
I had to disable `rayon` concurrent tests in the `fork_choice` tests. This is because the use of `rayon` and `block_on` was causing a panic.
Co-authored-by: Mac L <mjladson@pm.me>
2022-07-03 05:36:50 +00:00
|
|
|
ids.push(BlockId::Root(
|
|
|
|
|
self.chain.canonical_head.cached_head().head_block_root(),
|
|
|
|
|
));
|
2020-09-29 03:46:54 +00:00
|
|
|
ids
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
fn get_state(&self, state_id: StateId) -> Option<BeaconState<E>> {
|
|
|
|
|
match state_id {
|
Use async code when interacting with EL (#3244)
## Overview
This rather extensive PR achieves two primary goals:
1. Uses the finalized/justified checkpoints of fork choice (FC), rather than that of the head state.
2. Refactors fork choice, block production and block processing to `async` functions.
Additionally, it achieves:
- Concurrent forkchoice updates to the EL and cache pruning after a new head is selected.
- Concurrent "block packing" (attestations, etc) and execution payload retrieval during block production.
- Concurrent per-block-processing and execution payload verification during block processing.
- The `Arc`-ification of `SignedBeaconBlock` during block processing (it's never mutated, so why not?):
- I had to do this to deal with sending blocks into spawned tasks.
- Previously we were cloning the beacon block at least 2 times during each block processing, these clones are either removed or turned into cheaper `Arc` clones.
- We were also `Box`-ing and un-`Box`-ing beacon blocks as they moved throughout the networking crate. This is not a big deal, but it's nice to avoid shifting things between the stack and heap.
- Avoids cloning *all the blocks* in *every chain segment* during sync.
- It also has the potential to clean up our code where we need to pass an *owned* block around so we can send it back in the case of an error (I didn't do much of this, my PR is already big enough :sweat_smile:)
- The `BeaconChain::HeadSafetyStatus` struct was removed. It was an old relic from prior merge specs.
For motivation for this change, see https://github.com/sigp/lighthouse/pull/3244#issuecomment-1160963273
## Changes to `canonical_head` and `fork_choice`
Previously, the `BeaconChain` had two separate fields:
```
canonical_head: RwLock<Snapshot>,
fork_choice: RwLock<BeaconForkChoice>
```
Now, we have grouped these values under a single struct:
```
canonical_head: CanonicalHead {
cached_head: RwLock<Arc<Snapshot>>,
fork_choice: RwLock<BeaconForkChoice>
}
```
Apart from ergonomics, the only *actual* change here is wrapping the canonical head snapshot in an `Arc`. This means that we no longer need to hold the `cached_head` (`canonical_head`, in old terms) lock when we want to pull some values from it. This was done to avoid deadlock risks by preventing functions from acquiring (and holding) the `cached_head` and `fork_choice` locks simultaneously.
## Breaking Changes
### The `state` (root) field in the `finalized_checkpoint` SSE event
Consider the scenario where epoch `n` is just finalized, but `start_slot(n)` is skipped. There are two state roots we might in the `finalized_checkpoint` SSE event:
1. The state root of the finalized block, which is `get_block(finalized_checkpoint.root).state_root`.
4. The state root at slot of `start_slot(n)`, which would be the state from (1), but "skipped forward" through any skip slots.
Previously, Lighthouse would choose (2). However, we can see that when [Teku generates that event](https://github.com/ConsenSys/teku/blob/de2b2801c89ef5abf983d6bf37867c37fc47121f/data/beaconrestapi/src/main/java/tech/pegasys/teku/beaconrestapi/handlers/v1/events/EventSubscriptionManager.java#L171-L182) it uses [`getStateRootFromBlockRoot`](https://github.com/ConsenSys/teku/blob/de2b2801c89ef5abf983d6bf37867c37fc47121f/data/provider/src/main/java/tech/pegasys/teku/api/ChainDataProvider.java#L336-L341) which uses (1).
I have switched Lighthouse from (2) to (1). I think it's a somewhat arbitrary choice between the two, where (1) is easier to compute and is consistent with Teku.
## Notes for Reviewers
I've renamed `BeaconChain::fork_choice` to `BeaconChain::recompute_head`. Doing this helped ensure I broke all previous uses of fork choice and I also find it more descriptive. It describes an action and can't be confused with trying to get a reference to the `ForkChoice` struct.
I've changed the ordering of SSE events when a block is received. It used to be `[block, finalized, head]` and now it's `[block, head, finalized]`. It was easier this way and I don't think we were making any promises about SSE event ordering so it's not "breaking".
I've made it so fork choice will run when it's first constructed. I did this because I wanted to have a cached version of the last call to `get_head`. Ensuring `get_head` has been run *at least once* means that the cached values doesn't need to wrapped in an `Option`. This was fairly simple, it just involved passing a `slot` to the constructor so it knows *when* it's being run. When loading a fork choice from the store and a slot clock isn't handy I've just used the `slot` that was saved in the `fork_choice_store`. That seems like it would be a faithful representation of the slot when we saved it.
I added the `genesis_time: u64` to the `BeaconChain`. It's small, constant and nice to have around.
Since we're using FC for the fin/just checkpoints, we no longer get the `0x00..00` roots at genesis. You can see I had to remove a work-around in `ef-tests` here: b56be3bc2. I can't find any reason why this would be an issue, if anything I think it'll be better since the genesis-alias has caught us out a few times (0x00..00 isn't actually a real root). Edit: I did find a case where the `network` expected the 0x00..00 alias and patched it here: 3f26ac3e2.
You'll notice a lot of changes in tests. Generally, tests should be functionally equivalent. Here are the things creating the most diff-noise in tests:
- Changing tests to be `tokio::async` tests.
- Adding `.await` to fork choice, block processing and block production functions.
- Refactor of the `canonical_head` "API" provided by the `BeaconChain`. E.g., `chain.canonical_head.cached_head()` instead of `chain.canonical_head.read()`.
- Wrapping `SignedBeaconBlock` in an `Arc`.
- In the `beacon_chain/tests/block_verification`, we can't use the `lazy_static` `CHAIN_SEGMENT` variable anymore since it's generated with an async function. We just generate it in each test, not so efficient but hopefully insignificant.
I had to disable `rayon` concurrent tests in the `fork_choice` tests. This is because the use of `rayon` and `block_on` was causing a panic.
Co-authored-by: Mac L <mjladson@pm.me>
2022-07-03 05:36:50 +00:00
|
|
|
StateId::Head => Some(
|
|
|
|
|
self.chain
|
|
|
|
|
.head_snapshot()
|
|
|
|
|
.beacon_state
|
|
|
|
|
.clone_with_only_committee_caches(),
|
|
|
|
|
),
|
2020-09-29 03:46:54 +00:00
|
|
|
StateId::Genesis => self
|
|
|
|
|
.chain
|
|
|
|
|
.get_state(&self.chain.genesis_state_root, None)
|
|
|
|
|
.unwrap(),
|
|
|
|
|
StateId::Finalized => {
|
|
|
|
|
let finalized_slot = self
|
|
|
|
|
.chain
|
Use async code when interacting with EL (#3244)
## Overview
This rather extensive PR achieves two primary goals:
1. Uses the finalized/justified checkpoints of fork choice (FC), rather than that of the head state.
2. Refactors fork choice, block production and block processing to `async` functions.
Additionally, it achieves:
- Concurrent forkchoice updates to the EL and cache pruning after a new head is selected.
- Concurrent "block packing" (attestations, etc) and execution payload retrieval during block production.
- Concurrent per-block-processing and execution payload verification during block processing.
- The `Arc`-ification of `SignedBeaconBlock` during block processing (it's never mutated, so why not?):
- I had to do this to deal with sending blocks into spawned tasks.
- Previously we were cloning the beacon block at least 2 times during each block processing, these clones are either removed or turned into cheaper `Arc` clones.
- We were also `Box`-ing and un-`Box`-ing beacon blocks as they moved throughout the networking crate. This is not a big deal, but it's nice to avoid shifting things between the stack and heap.
- Avoids cloning *all the blocks* in *every chain segment* during sync.
- It also has the potential to clean up our code where we need to pass an *owned* block around so we can send it back in the case of an error (I didn't do much of this, my PR is already big enough :sweat_smile:)
- The `BeaconChain::HeadSafetyStatus` struct was removed. It was an old relic from prior merge specs.
For motivation for this change, see https://github.com/sigp/lighthouse/pull/3244#issuecomment-1160963273
## Changes to `canonical_head` and `fork_choice`
Previously, the `BeaconChain` had two separate fields:
```
canonical_head: RwLock<Snapshot>,
fork_choice: RwLock<BeaconForkChoice>
```
Now, we have grouped these values under a single struct:
```
canonical_head: CanonicalHead {
cached_head: RwLock<Arc<Snapshot>>,
fork_choice: RwLock<BeaconForkChoice>
}
```
Apart from ergonomics, the only *actual* change here is wrapping the canonical head snapshot in an `Arc`. This means that we no longer need to hold the `cached_head` (`canonical_head`, in old terms) lock when we want to pull some values from it. This was done to avoid deadlock risks by preventing functions from acquiring (and holding) the `cached_head` and `fork_choice` locks simultaneously.
## Breaking Changes
### The `state` (root) field in the `finalized_checkpoint` SSE event
Consider the scenario where epoch `n` is just finalized, but `start_slot(n)` is skipped. There are two state roots we might in the `finalized_checkpoint` SSE event:
1. The state root of the finalized block, which is `get_block(finalized_checkpoint.root).state_root`.
4. The state root at slot of `start_slot(n)`, which would be the state from (1), but "skipped forward" through any skip slots.
Previously, Lighthouse would choose (2). However, we can see that when [Teku generates that event](https://github.com/ConsenSys/teku/blob/de2b2801c89ef5abf983d6bf37867c37fc47121f/data/beaconrestapi/src/main/java/tech/pegasys/teku/beaconrestapi/handlers/v1/events/EventSubscriptionManager.java#L171-L182) it uses [`getStateRootFromBlockRoot`](https://github.com/ConsenSys/teku/blob/de2b2801c89ef5abf983d6bf37867c37fc47121f/data/provider/src/main/java/tech/pegasys/teku/api/ChainDataProvider.java#L336-L341) which uses (1).
I have switched Lighthouse from (2) to (1). I think it's a somewhat arbitrary choice between the two, where (1) is easier to compute and is consistent with Teku.
## Notes for Reviewers
I've renamed `BeaconChain::fork_choice` to `BeaconChain::recompute_head`. Doing this helped ensure I broke all previous uses of fork choice and I also find it more descriptive. It describes an action and can't be confused with trying to get a reference to the `ForkChoice` struct.
I've changed the ordering of SSE events when a block is received. It used to be `[block, finalized, head]` and now it's `[block, head, finalized]`. It was easier this way and I don't think we were making any promises about SSE event ordering so it's not "breaking".
I've made it so fork choice will run when it's first constructed. I did this because I wanted to have a cached version of the last call to `get_head`. Ensuring `get_head` has been run *at least once* means that the cached values doesn't need to wrapped in an `Option`. This was fairly simple, it just involved passing a `slot` to the constructor so it knows *when* it's being run. When loading a fork choice from the store and a slot clock isn't handy I've just used the `slot` that was saved in the `fork_choice_store`. That seems like it would be a faithful representation of the slot when we saved it.
I added the `genesis_time: u64` to the `BeaconChain`. It's small, constant and nice to have around.
Since we're using FC for the fin/just checkpoints, we no longer get the `0x00..00` roots at genesis. You can see I had to remove a work-around in `ef-tests` here: b56be3bc2. I can't find any reason why this would be an issue, if anything I think it'll be better since the genesis-alias has caught us out a few times (0x00..00 isn't actually a real root). Edit: I did find a case where the `network` expected the 0x00..00 alias and patched it here: 3f26ac3e2.
You'll notice a lot of changes in tests. Generally, tests should be functionally equivalent. Here are the things creating the most diff-noise in tests:
- Changing tests to be `tokio::async` tests.
- Adding `.await` to fork choice, block processing and block production functions.
- Refactor of the `canonical_head` "API" provided by the `BeaconChain`. E.g., `chain.canonical_head.cached_head()` instead of `chain.canonical_head.read()`.
- Wrapping `SignedBeaconBlock` in an `Arc`.
- In the `beacon_chain/tests/block_verification`, we can't use the `lazy_static` `CHAIN_SEGMENT` variable anymore since it's generated with an async function. We just generate it in each test, not so efficient but hopefully insignificant.
I had to disable `rayon` concurrent tests in the `fork_choice` tests. This is because the use of `rayon` and `block_on` was causing a panic.
Co-authored-by: Mac L <mjladson@pm.me>
2022-07-03 05:36:50 +00:00
|
|
|
.canonical_head
|
|
|
|
|
.cached_head()
|
|
|
|
|
.finalized_checkpoint()
|
2020-09-29 03:46:54 +00:00
|
|
|
.epoch
|
|
|
|
|
.start_slot(E::slots_per_epoch());
|
|
|
|
|
|
|
|
|
|
let root = self
|
|
|
|
|
.chain
|
|
|
|
|
.state_root_at_slot(finalized_slot)
|
|
|
|
|
.unwrap()
|
|
|
|
|
.unwrap();
|
|
|
|
|
|
|
|
|
|
self.chain.get_state(&root, Some(finalized_slot)).unwrap()
|
|
|
|
|
}
|
|
|
|
|
StateId::Justified => {
|
|
|
|
|
let justified_slot = self
|
|
|
|
|
.chain
|
Use async code when interacting with EL (#3244)
## Overview
This rather extensive PR achieves two primary goals:
1. Uses the finalized/justified checkpoints of fork choice (FC), rather than that of the head state.
2. Refactors fork choice, block production and block processing to `async` functions.
Additionally, it achieves:
- Concurrent forkchoice updates to the EL and cache pruning after a new head is selected.
- Concurrent "block packing" (attestations, etc) and execution payload retrieval during block production.
- Concurrent per-block-processing and execution payload verification during block processing.
- The `Arc`-ification of `SignedBeaconBlock` during block processing (it's never mutated, so why not?):
- I had to do this to deal with sending blocks into spawned tasks.
- Previously we were cloning the beacon block at least 2 times during each block processing, these clones are either removed or turned into cheaper `Arc` clones.
- We were also `Box`-ing and un-`Box`-ing beacon blocks as they moved throughout the networking crate. This is not a big deal, but it's nice to avoid shifting things between the stack and heap.
- Avoids cloning *all the blocks* in *every chain segment* during sync.
- It also has the potential to clean up our code where we need to pass an *owned* block around so we can send it back in the case of an error (I didn't do much of this, my PR is already big enough :sweat_smile:)
- The `BeaconChain::HeadSafetyStatus` struct was removed. It was an old relic from prior merge specs.
For motivation for this change, see https://github.com/sigp/lighthouse/pull/3244#issuecomment-1160963273
## Changes to `canonical_head` and `fork_choice`
Previously, the `BeaconChain` had two separate fields:
```
canonical_head: RwLock<Snapshot>,
fork_choice: RwLock<BeaconForkChoice>
```
Now, we have grouped these values under a single struct:
```
canonical_head: CanonicalHead {
cached_head: RwLock<Arc<Snapshot>>,
fork_choice: RwLock<BeaconForkChoice>
}
```
Apart from ergonomics, the only *actual* change here is wrapping the canonical head snapshot in an `Arc`. This means that we no longer need to hold the `cached_head` (`canonical_head`, in old terms) lock when we want to pull some values from it. This was done to avoid deadlock risks by preventing functions from acquiring (and holding) the `cached_head` and `fork_choice` locks simultaneously.
## Breaking Changes
### The `state` (root) field in the `finalized_checkpoint` SSE event
Consider the scenario where epoch `n` is just finalized, but `start_slot(n)` is skipped. There are two state roots we might in the `finalized_checkpoint` SSE event:
1. The state root of the finalized block, which is `get_block(finalized_checkpoint.root).state_root`.
4. The state root at slot of `start_slot(n)`, which would be the state from (1), but "skipped forward" through any skip slots.
Previously, Lighthouse would choose (2). However, we can see that when [Teku generates that event](https://github.com/ConsenSys/teku/blob/de2b2801c89ef5abf983d6bf37867c37fc47121f/data/beaconrestapi/src/main/java/tech/pegasys/teku/beaconrestapi/handlers/v1/events/EventSubscriptionManager.java#L171-L182) it uses [`getStateRootFromBlockRoot`](https://github.com/ConsenSys/teku/blob/de2b2801c89ef5abf983d6bf37867c37fc47121f/data/provider/src/main/java/tech/pegasys/teku/api/ChainDataProvider.java#L336-L341) which uses (1).
I have switched Lighthouse from (2) to (1). I think it's a somewhat arbitrary choice between the two, where (1) is easier to compute and is consistent with Teku.
## Notes for Reviewers
I've renamed `BeaconChain::fork_choice` to `BeaconChain::recompute_head`. Doing this helped ensure I broke all previous uses of fork choice and I also find it more descriptive. It describes an action and can't be confused with trying to get a reference to the `ForkChoice` struct.
I've changed the ordering of SSE events when a block is received. It used to be `[block, finalized, head]` and now it's `[block, head, finalized]`. It was easier this way and I don't think we were making any promises about SSE event ordering so it's not "breaking".
I've made it so fork choice will run when it's first constructed. I did this because I wanted to have a cached version of the last call to `get_head`. Ensuring `get_head` has been run *at least once* means that the cached values doesn't need to wrapped in an `Option`. This was fairly simple, it just involved passing a `slot` to the constructor so it knows *when* it's being run. When loading a fork choice from the store and a slot clock isn't handy I've just used the `slot` that was saved in the `fork_choice_store`. That seems like it would be a faithful representation of the slot when we saved it.
I added the `genesis_time: u64` to the `BeaconChain`. It's small, constant and nice to have around.
Since we're using FC for the fin/just checkpoints, we no longer get the `0x00..00` roots at genesis. You can see I had to remove a work-around in `ef-tests` here: b56be3bc2. I can't find any reason why this would be an issue, if anything I think it'll be better since the genesis-alias has caught us out a few times (0x00..00 isn't actually a real root). Edit: I did find a case where the `network` expected the 0x00..00 alias and patched it here: 3f26ac3e2.
You'll notice a lot of changes in tests. Generally, tests should be functionally equivalent. Here are the things creating the most diff-noise in tests:
- Changing tests to be `tokio::async` tests.
- Adding `.await` to fork choice, block processing and block production functions.
- Refactor of the `canonical_head` "API" provided by the `BeaconChain`. E.g., `chain.canonical_head.cached_head()` instead of `chain.canonical_head.read()`.
- Wrapping `SignedBeaconBlock` in an `Arc`.
- In the `beacon_chain/tests/block_verification`, we can't use the `lazy_static` `CHAIN_SEGMENT` variable anymore since it's generated with an async function. We just generate it in each test, not so efficient but hopefully insignificant.
I had to disable `rayon` concurrent tests in the `fork_choice` tests. This is because the use of `rayon` and `block_on` was causing a panic.
Co-authored-by: Mac L <mjladson@pm.me>
2022-07-03 05:36:50 +00:00
|
|
|
.canonical_head
|
|
|
|
|
.cached_head()
|
|
|
|
|
.justified_checkpoint()
|
2020-09-29 03:46:54 +00:00
|
|
|
.epoch
|
|
|
|
|
.start_slot(E::slots_per_epoch());
|
|
|
|
|
|
|
|
|
|
let root = self
|
|
|
|
|
.chain
|
|
|
|
|
.state_root_at_slot(justified_slot)
|
|
|
|
|
.unwrap()
|
|
|
|
|
.unwrap();
|
|
|
|
|
|
|
|
|
|
self.chain.get_state(&root, Some(justified_slot)).unwrap()
|
|
|
|
|
}
|
|
|
|
|
StateId::Slot(slot) => {
|
|
|
|
|
let root = self.chain.state_root_at_slot(slot).unwrap().unwrap();
|
|
|
|
|
|
|
|
|
|
self.chain.get_state(&root, Some(slot)).unwrap()
|
|
|
|
|
}
|
|
|
|
|
StateId::Root(root) => self.chain.get_state(&root, None).unwrap(),
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
pub async fn test_beacon_genesis(self) -> Self {
|
|
|
|
|
let result = self.client.get_beacon_genesis().await.unwrap().data;
|
|
|
|
|
|
Use async code when interacting with EL (#3244)
## Overview
This rather extensive PR achieves two primary goals:
1. Uses the finalized/justified checkpoints of fork choice (FC), rather than that of the head state.
2. Refactors fork choice, block production and block processing to `async` functions.
Additionally, it achieves:
- Concurrent forkchoice updates to the EL and cache pruning after a new head is selected.
- Concurrent "block packing" (attestations, etc) and execution payload retrieval during block production.
- Concurrent per-block-processing and execution payload verification during block processing.
- The `Arc`-ification of `SignedBeaconBlock` during block processing (it's never mutated, so why not?):
- I had to do this to deal with sending blocks into spawned tasks.
- Previously we were cloning the beacon block at least 2 times during each block processing, these clones are either removed or turned into cheaper `Arc` clones.
- We were also `Box`-ing and un-`Box`-ing beacon blocks as they moved throughout the networking crate. This is not a big deal, but it's nice to avoid shifting things between the stack and heap.
- Avoids cloning *all the blocks* in *every chain segment* during sync.
- It also has the potential to clean up our code where we need to pass an *owned* block around so we can send it back in the case of an error (I didn't do much of this, my PR is already big enough :sweat_smile:)
- The `BeaconChain::HeadSafetyStatus` struct was removed. It was an old relic from prior merge specs.
For motivation for this change, see https://github.com/sigp/lighthouse/pull/3244#issuecomment-1160963273
## Changes to `canonical_head` and `fork_choice`
Previously, the `BeaconChain` had two separate fields:
```
canonical_head: RwLock<Snapshot>,
fork_choice: RwLock<BeaconForkChoice>
```
Now, we have grouped these values under a single struct:
```
canonical_head: CanonicalHead {
cached_head: RwLock<Arc<Snapshot>>,
fork_choice: RwLock<BeaconForkChoice>
}
```
Apart from ergonomics, the only *actual* change here is wrapping the canonical head snapshot in an `Arc`. This means that we no longer need to hold the `cached_head` (`canonical_head`, in old terms) lock when we want to pull some values from it. This was done to avoid deadlock risks by preventing functions from acquiring (and holding) the `cached_head` and `fork_choice` locks simultaneously.
## Breaking Changes
### The `state` (root) field in the `finalized_checkpoint` SSE event
Consider the scenario where epoch `n` is just finalized, but `start_slot(n)` is skipped. There are two state roots we might in the `finalized_checkpoint` SSE event:
1. The state root of the finalized block, which is `get_block(finalized_checkpoint.root).state_root`.
4. The state root at slot of `start_slot(n)`, which would be the state from (1), but "skipped forward" through any skip slots.
Previously, Lighthouse would choose (2). However, we can see that when [Teku generates that event](https://github.com/ConsenSys/teku/blob/de2b2801c89ef5abf983d6bf37867c37fc47121f/data/beaconrestapi/src/main/java/tech/pegasys/teku/beaconrestapi/handlers/v1/events/EventSubscriptionManager.java#L171-L182) it uses [`getStateRootFromBlockRoot`](https://github.com/ConsenSys/teku/blob/de2b2801c89ef5abf983d6bf37867c37fc47121f/data/provider/src/main/java/tech/pegasys/teku/api/ChainDataProvider.java#L336-L341) which uses (1).
I have switched Lighthouse from (2) to (1). I think it's a somewhat arbitrary choice between the two, where (1) is easier to compute and is consistent with Teku.
## Notes for Reviewers
I've renamed `BeaconChain::fork_choice` to `BeaconChain::recompute_head`. Doing this helped ensure I broke all previous uses of fork choice and I also find it more descriptive. It describes an action and can't be confused with trying to get a reference to the `ForkChoice` struct.
I've changed the ordering of SSE events when a block is received. It used to be `[block, finalized, head]` and now it's `[block, head, finalized]`. It was easier this way and I don't think we were making any promises about SSE event ordering so it's not "breaking".
I've made it so fork choice will run when it's first constructed. I did this because I wanted to have a cached version of the last call to `get_head`. Ensuring `get_head` has been run *at least once* means that the cached values doesn't need to wrapped in an `Option`. This was fairly simple, it just involved passing a `slot` to the constructor so it knows *when* it's being run. When loading a fork choice from the store and a slot clock isn't handy I've just used the `slot` that was saved in the `fork_choice_store`. That seems like it would be a faithful representation of the slot when we saved it.
I added the `genesis_time: u64` to the `BeaconChain`. It's small, constant and nice to have around.
Since we're using FC for the fin/just checkpoints, we no longer get the `0x00..00` roots at genesis. You can see I had to remove a work-around in `ef-tests` here: b56be3bc2. I can't find any reason why this would be an issue, if anything I think it'll be better since the genesis-alias has caught us out a few times (0x00..00 isn't actually a real root). Edit: I did find a case where the `network` expected the 0x00..00 alias and patched it here: 3f26ac3e2.
You'll notice a lot of changes in tests. Generally, tests should be functionally equivalent. Here are the things creating the most diff-noise in tests:
- Changing tests to be `tokio::async` tests.
- Adding `.await` to fork choice, block processing and block production functions.
- Refactor of the `canonical_head` "API" provided by the `BeaconChain`. E.g., `chain.canonical_head.cached_head()` instead of `chain.canonical_head.read()`.
- Wrapping `SignedBeaconBlock` in an `Arc`.
- In the `beacon_chain/tests/block_verification`, we can't use the `lazy_static` `CHAIN_SEGMENT` variable anymore since it's generated with an async function. We just generate it in each test, not so efficient but hopefully insignificant.
I had to disable `rayon` concurrent tests in the `fork_choice` tests. This is because the use of `rayon` and `block_on` was causing a panic.
Co-authored-by: Mac L <mjladson@pm.me>
2022-07-03 05:36:50 +00:00
|
|
|
let state = &self.chain.head_snapshot().beacon_state;
|
2020-09-29 03:46:54 +00:00
|
|
|
let expected = GenesisData {
|
2021-07-09 06:15:32 +00:00
|
|
|
genesis_time: state.genesis_time(),
|
|
|
|
|
genesis_validators_root: state.genesis_validators_root(),
|
2020-09-29 03:46:54 +00:00
|
|
|
genesis_fork_version: self.chain.spec.genesis_fork_version,
|
|
|
|
|
};
|
|
|
|
|
|
|
|
|
|
assert_eq!(result, expected);
|
|
|
|
|
|
|
|
|
|
self
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
pub async fn test_beacon_states_root(self) -> Self {
|
|
|
|
|
for state_id in self.interesting_state_ids() {
|
|
|
|
|
let result = self
|
|
|
|
|
.client
|
|
|
|
|
.get_beacon_states_root(state_id)
|
|
|
|
|
.await
|
|
|
|
|
.unwrap()
|
|
|
|
|
.map(|res| res.data.root);
|
|
|
|
|
|
|
|
|
|
let expected = match state_id {
|
Use async code when interacting with EL (#3244)
## Overview
This rather extensive PR achieves two primary goals:
1. Uses the finalized/justified checkpoints of fork choice (FC), rather than that of the head state.
2. Refactors fork choice, block production and block processing to `async` functions.
Additionally, it achieves:
- Concurrent forkchoice updates to the EL and cache pruning after a new head is selected.
- Concurrent "block packing" (attestations, etc) and execution payload retrieval during block production.
- Concurrent per-block-processing and execution payload verification during block processing.
- The `Arc`-ification of `SignedBeaconBlock` during block processing (it's never mutated, so why not?):
- I had to do this to deal with sending blocks into spawned tasks.
- Previously we were cloning the beacon block at least 2 times during each block processing, these clones are either removed or turned into cheaper `Arc` clones.
- We were also `Box`-ing and un-`Box`-ing beacon blocks as they moved throughout the networking crate. This is not a big deal, but it's nice to avoid shifting things between the stack and heap.
- Avoids cloning *all the blocks* in *every chain segment* during sync.
- It also has the potential to clean up our code where we need to pass an *owned* block around so we can send it back in the case of an error (I didn't do much of this, my PR is already big enough :sweat_smile:)
- The `BeaconChain::HeadSafetyStatus` struct was removed. It was an old relic from prior merge specs.
For motivation for this change, see https://github.com/sigp/lighthouse/pull/3244#issuecomment-1160963273
## Changes to `canonical_head` and `fork_choice`
Previously, the `BeaconChain` had two separate fields:
```
canonical_head: RwLock<Snapshot>,
fork_choice: RwLock<BeaconForkChoice>
```
Now, we have grouped these values under a single struct:
```
canonical_head: CanonicalHead {
cached_head: RwLock<Arc<Snapshot>>,
fork_choice: RwLock<BeaconForkChoice>
}
```
Apart from ergonomics, the only *actual* change here is wrapping the canonical head snapshot in an `Arc`. This means that we no longer need to hold the `cached_head` (`canonical_head`, in old terms) lock when we want to pull some values from it. This was done to avoid deadlock risks by preventing functions from acquiring (and holding) the `cached_head` and `fork_choice` locks simultaneously.
## Breaking Changes
### The `state` (root) field in the `finalized_checkpoint` SSE event
Consider the scenario where epoch `n` is just finalized, but `start_slot(n)` is skipped. There are two state roots we might in the `finalized_checkpoint` SSE event:
1. The state root of the finalized block, which is `get_block(finalized_checkpoint.root).state_root`.
4. The state root at slot of `start_slot(n)`, which would be the state from (1), but "skipped forward" through any skip slots.
Previously, Lighthouse would choose (2). However, we can see that when [Teku generates that event](https://github.com/ConsenSys/teku/blob/de2b2801c89ef5abf983d6bf37867c37fc47121f/data/beaconrestapi/src/main/java/tech/pegasys/teku/beaconrestapi/handlers/v1/events/EventSubscriptionManager.java#L171-L182) it uses [`getStateRootFromBlockRoot`](https://github.com/ConsenSys/teku/blob/de2b2801c89ef5abf983d6bf37867c37fc47121f/data/provider/src/main/java/tech/pegasys/teku/api/ChainDataProvider.java#L336-L341) which uses (1).
I have switched Lighthouse from (2) to (1). I think it's a somewhat arbitrary choice between the two, where (1) is easier to compute and is consistent with Teku.
## Notes for Reviewers
I've renamed `BeaconChain::fork_choice` to `BeaconChain::recompute_head`. Doing this helped ensure I broke all previous uses of fork choice and I also find it more descriptive. It describes an action and can't be confused with trying to get a reference to the `ForkChoice` struct.
I've changed the ordering of SSE events when a block is received. It used to be `[block, finalized, head]` and now it's `[block, head, finalized]`. It was easier this way and I don't think we were making any promises about SSE event ordering so it's not "breaking".
I've made it so fork choice will run when it's first constructed. I did this because I wanted to have a cached version of the last call to `get_head`. Ensuring `get_head` has been run *at least once* means that the cached values doesn't need to wrapped in an `Option`. This was fairly simple, it just involved passing a `slot` to the constructor so it knows *when* it's being run. When loading a fork choice from the store and a slot clock isn't handy I've just used the `slot` that was saved in the `fork_choice_store`. That seems like it would be a faithful representation of the slot when we saved it.
I added the `genesis_time: u64` to the `BeaconChain`. It's small, constant and nice to have around.
Since we're using FC for the fin/just checkpoints, we no longer get the `0x00..00` roots at genesis. You can see I had to remove a work-around in `ef-tests` here: b56be3bc2. I can't find any reason why this would be an issue, if anything I think it'll be better since the genesis-alias has caught us out a few times (0x00..00 isn't actually a real root). Edit: I did find a case where the `network` expected the 0x00..00 alias and patched it here: 3f26ac3e2.
You'll notice a lot of changes in tests. Generally, tests should be functionally equivalent. Here are the things creating the most diff-noise in tests:
- Changing tests to be `tokio::async` tests.
- Adding `.await` to fork choice, block processing and block production functions.
- Refactor of the `canonical_head` "API" provided by the `BeaconChain`. E.g., `chain.canonical_head.cached_head()` instead of `chain.canonical_head.read()`.
- Wrapping `SignedBeaconBlock` in an `Arc`.
- In the `beacon_chain/tests/block_verification`, we can't use the `lazy_static` `CHAIN_SEGMENT` variable anymore since it's generated with an async function. We just generate it in each test, not so efficient but hopefully insignificant.
I had to disable `rayon` concurrent tests in the `fork_choice` tests. This is because the use of `rayon` and `block_on` was causing a panic.
Co-authored-by: Mac L <mjladson@pm.me>
2022-07-03 05:36:50 +00:00
|
|
|
StateId::Head => Some(self.chain.canonical_head.cached_head().head_state_root()),
|
2020-09-29 03:46:54 +00:00
|
|
|
StateId::Genesis => Some(self.chain.genesis_state_root),
|
|
|
|
|
StateId::Finalized => {
|
|
|
|
|
let finalized_slot = self
|
|
|
|
|
.chain
|
Use async code when interacting with EL (#3244)
## Overview
This rather extensive PR achieves two primary goals:
1. Uses the finalized/justified checkpoints of fork choice (FC), rather than that of the head state.
2. Refactors fork choice, block production and block processing to `async` functions.
Additionally, it achieves:
- Concurrent forkchoice updates to the EL and cache pruning after a new head is selected.
- Concurrent "block packing" (attestations, etc) and execution payload retrieval during block production.
- Concurrent per-block-processing and execution payload verification during block processing.
- The `Arc`-ification of `SignedBeaconBlock` during block processing (it's never mutated, so why not?):
- I had to do this to deal with sending blocks into spawned tasks.
- Previously we were cloning the beacon block at least 2 times during each block processing, these clones are either removed or turned into cheaper `Arc` clones.
- We were also `Box`-ing and un-`Box`-ing beacon blocks as they moved throughout the networking crate. This is not a big deal, but it's nice to avoid shifting things between the stack and heap.
- Avoids cloning *all the blocks* in *every chain segment* during sync.
- It also has the potential to clean up our code where we need to pass an *owned* block around so we can send it back in the case of an error (I didn't do much of this, my PR is already big enough :sweat_smile:)
- The `BeaconChain::HeadSafetyStatus` struct was removed. It was an old relic from prior merge specs.
For motivation for this change, see https://github.com/sigp/lighthouse/pull/3244#issuecomment-1160963273
## Changes to `canonical_head` and `fork_choice`
Previously, the `BeaconChain` had two separate fields:
```
canonical_head: RwLock<Snapshot>,
fork_choice: RwLock<BeaconForkChoice>
```
Now, we have grouped these values under a single struct:
```
canonical_head: CanonicalHead {
cached_head: RwLock<Arc<Snapshot>>,
fork_choice: RwLock<BeaconForkChoice>
}
```
Apart from ergonomics, the only *actual* change here is wrapping the canonical head snapshot in an `Arc`. This means that we no longer need to hold the `cached_head` (`canonical_head`, in old terms) lock when we want to pull some values from it. This was done to avoid deadlock risks by preventing functions from acquiring (and holding) the `cached_head` and `fork_choice` locks simultaneously.
## Breaking Changes
### The `state` (root) field in the `finalized_checkpoint` SSE event
Consider the scenario where epoch `n` is just finalized, but `start_slot(n)` is skipped. There are two state roots we might in the `finalized_checkpoint` SSE event:
1. The state root of the finalized block, which is `get_block(finalized_checkpoint.root).state_root`.
4. The state root at slot of `start_slot(n)`, which would be the state from (1), but "skipped forward" through any skip slots.
Previously, Lighthouse would choose (2). However, we can see that when [Teku generates that event](https://github.com/ConsenSys/teku/blob/de2b2801c89ef5abf983d6bf37867c37fc47121f/data/beaconrestapi/src/main/java/tech/pegasys/teku/beaconrestapi/handlers/v1/events/EventSubscriptionManager.java#L171-L182) it uses [`getStateRootFromBlockRoot`](https://github.com/ConsenSys/teku/blob/de2b2801c89ef5abf983d6bf37867c37fc47121f/data/provider/src/main/java/tech/pegasys/teku/api/ChainDataProvider.java#L336-L341) which uses (1).
I have switched Lighthouse from (2) to (1). I think it's a somewhat arbitrary choice between the two, where (1) is easier to compute and is consistent with Teku.
## Notes for Reviewers
I've renamed `BeaconChain::fork_choice` to `BeaconChain::recompute_head`. Doing this helped ensure I broke all previous uses of fork choice and I also find it more descriptive. It describes an action and can't be confused with trying to get a reference to the `ForkChoice` struct.
I've changed the ordering of SSE events when a block is received. It used to be `[block, finalized, head]` and now it's `[block, head, finalized]`. It was easier this way and I don't think we were making any promises about SSE event ordering so it's not "breaking".
I've made it so fork choice will run when it's first constructed. I did this because I wanted to have a cached version of the last call to `get_head`. Ensuring `get_head` has been run *at least once* means that the cached values doesn't need to wrapped in an `Option`. This was fairly simple, it just involved passing a `slot` to the constructor so it knows *when* it's being run. When loading a fork choice from the store and a slot clock isn't handy I've just used the `slot` that was saved in the `fork_choice_store`. That seems like it would be a faithful representation of the slot when we saved it.
I added the `genesis_time: u64` to the `BeaconChain`. It's small, constant and nice to have around.
Since we're using FC for the fin/just checkpoints, we no longer get the `0x00..00` roots at genesis. You can see I had to remove a work-around in `ef-tests` here: b56be3bc2. I can't find any reason why this would be an issue, if anything I think it'll be better since the genesis-alias has caught us out a few times (0x00..00 isn't actually a real root). Edit: I did find a case where the `network` expected the 0x00..00 alias and patched it here: 3f26ac3e2.
You'll notice a lot of changes in tests. Generally, tests should be functionally equivalent. Here are the things creating the most diff-noise in tests:
- Changing tests to be `tokio::async` tests.
- Adding `.await` to fork choice, block processing and block production functions.
- Refactor of the `canonical_head` "API" provided by the `BeaconChain`. E.g., `chain.canonical_head.cached_head()` instead of `chain.canonical_head.read()`.
- Wrapping `SignedBeaconBlock` in an `Arc`.
- In the `beacon_chain/tests/block_verification`, we can't use the `lazy_static` `CHAIN_SEGMENT` variable anymore since it's generated with an async function. We just generate it in each test, not so efficient but hopefully insignificant.
I had to disable `rayon` concurrent tests in the `fork_choice` tests. This is because the use of `rayon` and `block_on` was causing a panic.
Co-authored-by: Mac L <mjladson@pm.me>
2022-07-03 05:36:50 +00:00
|
|
|
.canonical_head
|
|
|
|
|
.cached_head()
|
|
|
|
|
.finalized_checkpoint()
|
2020-09-29 03:46:54 +00:00
|
|
|
.epoch
|
|
|
|
|
.start_slot(E::slots_per_epoch());
|
|
|
|
|
|
|
|
|
|
self.chain.state_root_at_slot(finalized_slot).unwrap()
|
|
|
|
|
}
|
|
|
|
|
StateId::Justified => {
|
|
|
|
|
let justified_slot = self
|
|
|
|
|
.chain
|
Use async code when interacting with EL (#3244)
## Overview
This rather extensive PR achieves two primary goals:
1. Uses the finalized/justified checkpoints of fork choice (FC), rather than that of the head state.
2. Refactors fork choice, block production and block processing to `async` functions.
Additionally, it achieves:
- Concurrent forkchoice updates to the EL and cache pruning after a new head is selected.
- Concurrent "block packing" (attestations, etc) and execution payload retrieval during block production.
- Concurrent per-block-processing and execution payload verification during block processing.
- The `Arc`-ification of `SignedBeaconBlock` during block processing (it's never mutated, so why not?):
- I had to do this to deal with sending blocks into spawned tasks.
- Previously we were cloning the beacon block at least 2 times during each block processing, these clones are either removed or turned into cheaper `Arc` clones.
- We were also `Box`-ing and un-`Box`-ing beacon blocks as they moved throughout the networking crate. This is not a big deal, but it's nice to avoid shifting things between the stack and heap.
- Avoids cloning *all the blocks* in *every chain segment* during sync.
- It also has the potential to clean up our code where we need to pass an *owned* block around so we can send it back in the case of an error (I didn't do much of this, my PR is already big enough :sweat_smile:)
- The `BeaconChain::HeadSafetyStatus` struct was removed. It was an old relic from prior merge specs.
For motivation for this change, see https://github.com/sigp/lighthouse/pull/3244#issuecomment-1160963273
## Changes to `canonical_head` and `fork_choice`
Previously, the `BeaconChain` had two separate fields:
```
canonical_head: RwLock<Snapshot>,
fork_choice: RwLock<BeaconForkChoice>
```
Now, we have grouped these values under a single struct:
```
canonical_head: CanonicalHead {
cached_head: RwLock<Arc<Snapshot>>,
fork_choice: RwLock<BeaconForkChoice>
}
```
Apart from ergonomics, the only *actual* change here is wrapping the canonical head snapshot in an `Arc`. This means that we no longer need to hold the `cached_head` (`canonical_head`, in old terms) lock when we want to pull some values from it. This was done to avoid deadlock risks by preventing functions from acquiring (and holding) the `cached_head` and `fork_choice` locks simultaneously.
## Breaking Changes
### The `state` (root) field in the `finalized_checkpoint` SSE event
Consider the scenario where epoch `n` is just finalized, but `start_slot(n)` is skipped. There are two state roots we might in the `finalized_checkpoint` SSE event:
1. The state root of the finalized block, which is `get_block(finalized_checkpoint.root).state_root`.
4. The state root at slot of `start_slot(n)`, which would be the state from (1), but "skipped forward" through any skip slots.
Previously, Lighthouse would choose (2). However, we can see that when [Teku generates that event](https://github.com/ConsenSys/teku/blob/de2b2801c89ef5abf983d6bf37867c37fc47121f/data/beaconrestapi/src/main/java/tech/pegasys/teku/beaconrestapi/handlers/v1/events/EventSubscriptionManager.java#L171-L182) it uses [`getStateRootFromBlockRoot`](https://github.com/ConsenSys/teku/blob/de2b2801c89ef5abf983d6bf37867c37fc47121f/data/provider/src/main/java/tech/pegasys/teku/api/ChainDataProvider.java#L336-L341) which uses (1).
I have switched Lighthouse from (2) to (1). I think it's a somewhat arbitrary choice between the two, where (1) is easier to compute and is consistent with Teku.
## Notes for Reviewers
I've renamed `BeaconChain::fork_choice` to `BeaconChain::recompute_head`. Doing this helped ensure I broke all previous uses of fork choice and I also find it more descriptive. It describes an action and can't be confused with trying to get a reference to the `ForkChoice` struct.
I've changed the ordering of SSE events when a block is received. It used to be `[block, finalized, head]` and now it's `[block, head, finalized]`. It was easier this way and I don't think we were making any promises about SSE event ordering so it's not "breaking".
I've made it so fork choice will run when it's first constructed. I did this because I wanted to have a cached version of the last call to `get_head`. Ensuring `get_head` has been run *at least once* means that the cached values doesn't need to wrapped in an `Option`. This was fairly simple, it just involved passing a `slot` to the constructor so it knows *when* it's being run. When loading a fork choice from the store and a slot clock isn't handy I've just used the `slot` that was saved in the `fork_choice_store`. That seems like it would be a faithful representation of the slot when we saved it.
I added the `genesis_time: u64` to the `BeaconChain`. It's small, constant and nice to have around.
Since we're using FC for the fin/just checkpoints, we no longer get the `0x00..00` roots at genesis. You can see I had to remove a work-around in `ef-tests` here: b56be3bc2. I can't find any reason why this would be an issue, if anything I think it'll be better since the genesis-alias has caught us out a few times (0x00..00 isn't actually a real root). Edit: I did find a case where the `network` expected the 0x00..00 alias and patched it here: 3f26ac3e2.
You'll notice a lot of changes in tests. Generally, tests should be functionally equivalent. Here are the things creating the most diff-noise in tests:
- Changing tests to be `tokio::async` tests.
- Adding `.await` to fork choice, block processing and block production functions.
- Refactor of the `canonical_head` "API" provided by the `BeaconChain`. E.g., `chain.canonical_head.cached_head()` instead of `chain.canonical_head.read()`.
- Wrapping `SignedBeaconBlock` in an `Arc`.
- In the `beacon_chain/tests/block_verification`, we can't use the `lazy_static` `CHAIN_SEGMENT` variable anymore since it's generated with an async function. We just generate it in each test, not so efficient but hopefully insignificant.
I had to disable `rayon` concurrent tests in the `fork_choice` tests. This is because the use of `rayon` and `block_on` was causing a panic.
Co-authored-by: Mac L <mjladson@pm.me>
2022-07-03 05:36:50 +00:00
|
|
|
.canonical_head
|
|
|
|
|
.cached_head()
|
|
|
|
|
.justified_checkpoint()
|
2020-09-29 03:46:54 +00:00
|
|
|
.epoch
|
|
|
|
|
.start_slot(E::slots_per_epoch());
|
|
|
|
|
|
|
|
|
|
self.chain.state_root_at_slot(justified_slot).unwrap()
|
|
|
|
|
}
|
|
|
|
|
StateId::Slot(slot) => self.chain.state_root_at_slot(slot).unwrap(),
|
|
|
|
|
StateId::Root(root) => Some(root),
|
|
|
|
|
};
|
|
|
|
|
|
|
|
|
|
assert_eq!(result, expected, "{:?}", state_id);
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
self
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
pub async fn test_beacon_states_fork(self) -> Self {
|
|
|
|
|
for state_id in self.interesting_state_ids() {
|
|
|
|
|
let result = self
|
|
|
|
|
.client
|
|
|
|
|
.get_beacon_states_fork(state_id)
|
|
|
|
|
.await
|
|
|
|
|
.unwrap()
|
|
|
|
|
.map(|res| res.data);
|
|
|
|
|
|
2021-07-09 06:15:32 +00:00
|
|
|
let expected = self.get_state(state_id).map(|state| state.fork());
|
2020-09-29 03:46:54 +00:00
|
|
|
|
|
|
|
|
assert_eq!(result, expected, "{:?}", state_id);
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
self
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
pub async fn test_beacon_states_finality_checkpoints(self) -> Self {
|
|
|
|
|
for state_id in self.interesting_state_ids() {
|
|
|
|
|
let result = self
|
|
|
|
|
.client
|
|
|
|
|
.get_beacon_states_finality_checkpoints(state_id)
|
|
|
|
|
.await
|
|
|
|
|
.unwrap()
|
|
|
|
|
.map(|res| res.data);
|
|
|
|
|
|
|
|
|
|
let expected = self
|
|
|
|
|
.get_state(state_id)
|
|
|
|
|
.map(|state| FinalityCheckpointsData {
|
2021-07-09 06:15:32 +00:00
|
|
|
previous_justified: state.previous_justified_checkpoint(),
|
|
|
|
|
current_justified: state.current_justified_checkpoint(),
|
|
|
|
|
finalized: state.finalized_checkpoint(),
|
2020-09-29 03:46:54 +00:00
|
|
|
});
|
|
|
|
|
|
|
|
|
|
assert_eq!(result, expected, "{:?}", state_id);
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
self
|
|
|
|
|
}
|
|
|
|
|
|
2020-11-09 23:13:56 +00:00
|
|
|
pub async fn test_beacon_states_validator_balances(self) -> Self {
|
|
|
|
|
for state_id in self.interesting_state_ids() {
|
|
|
|
|
for validator_indices in self.interesting_validator_indices() {
|
|
|
|
|
let state_opt = self.get_state(state_id);
|
|
|
|
|
let validators: Vec<Validator> = match state_opt.as_ref() {
|
2021-07-09 06:15:32 +00:00
|
|
|
Some(state) => state.validators().clone().into(),
|
2020-11-09 23:13:56 +00:00
|
|
|
None => vec![],
|
|
|
|
|
};
|
|
|
|
|
let validator_index_ids = validator_indices
|
|
|
|
|
.iter()
|
|
|
|
|
.cloned()
|
|
|
|
|
.map(|i| ValidatorId::Index(i))
|
|
|
|
|
.collect::<Vec<ValidatorId>>();
|
|
|
|
|
let validator_pubkey_ids = validator_indices
|
|
|
|
|
.iter()
|
|
|
|
|
.cloned()
|
|
|
|
|
.map(|i| {
|
|
|
|
|
ValidatorId::PublicKey(
|
|
|
|
|
validators
|
|
|
|
|
.get(i as usize)
|
|
|
|
|
.map_or(PublicKeyBytes::empty(), |val| val.pubkey.clone()),
|
|
|
|
|
)
|
|
|
|
|
})
|
|
|
|
|
.collect::<Vec<ValidatorId>>();
|
|
|
|
|
|
|
|
|
|
let result_index_ids = self
|
|
|
|
|
.client
|
|
|
|
|
.get_beacon_states_validator_balances(
|
|
|
|
|
state_id,
|
|
|
|
|
Some(validator_index_ids.as_slice()),
|
|
|
|
|
)
|
|
|
|
|
.await
|
|
|
|
|
.unwrap()
|
|
|
|
|
.map(|res| res.data);
|
|
|
|
|
let result_pubkey_ids = self
|
|
|
|
|
.client
|
|
|
|
|
.get_beacon_states_validator_balances(
|
|
|
|
|
state_id,
|
|
|
|
|
Some(validator_pubkey_ids.as_slice()),
|
|
|
|
|
)
|
|
|
|
|
.await
|
|
|
|
|
.unwrap()
|
|
|
|
|
.map(|res| res.data);
|
|
|
|
|
|
|
|
|
|
let expected = state_opt.map(|state| {
|
|
|
|
|
let mut validators = Vec::with_capacity(validator_indices.len());
|
|
|
|
|
|
|
|
|
|
for i in validator_indices {
|
2021-07-09 06:15:32 +00:00
|
|
|
if i < state.balances().len() as u64 {
|
2020-11-09 23:13:56 +00:00
|
|
|
validators.push(ValidatorBalanceData {
|
|
|
|
|
index: i as u64,
|
2021-07-09 06:15:32 +00:00
|
|
|
balance: state.balances()[i as usize],
|
2020-11-09 23:13:56 +00:00
|
|
|
});
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
validators
|
|
|
|
|
});
|
|
|
|
|
|
|
|
|
|
assert_eq!(result_index_ids, expected, "{:?}", state_id);
|
|
|
|
|
assert_eq!(result_pubkey_ids, expected, "{:?}", state_id);
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
self
|
|
|
|
|
}
|
|
|
|
|
|
2020-09-29 03:46:54 +00:00
|
|
|
pub async fn test_beacon_states_validators(self) -> Self {
|
|
|
|
|
for state_id in self.interesting_state_ids() {
|
2020-10-29 05:13:04 +00:00
|
|
|
for statuses in self.interesting_validator_statuses() {
|
|
|
|
|
for validator_indices in self.interesting_validator_indices() {
|
|
|
|
|
let state_opt = self.get_state(state_id);
|
|
|
|
|
let validators: Vec<Validator> = match state_opt.as_ref() {
|
2021-07-09 06:15:32 +00:00
|
|
|
Some(state) => state.validators().clone().into(),
|
2020-10-29 05:13:04 +00:00
|
|
|
None => vec![],
|
|
|
|
|
};
|
|
|
|
|
let validator_index_ids = validator_indices
|
|
|
|
|
.iter()
|
|
|
|
|
.cloned()
|
|
|
|
|
.map(|i| ValidatorId::Index(i))
|
|
|
|
|
.collect::<Vec<ValidatorId>>();
|
|
|
|
|
let validator_pubkey_ids = validator_indices
|
|
|
|
|
.iter()
|
|
|
|
|
.cloned()
|
|
|
|
|
.map(|i| {
|
|
|
|
|
ValidatorId::PublicKey(
|
|
|
|
|
validators
|
|
|
|
|
.get(i as usize)
|
|
|
|
|
.map_or(PublicKeyBytes::empty(), |val| val.pubkey.clone()),
|
|
|
|
|
)
|
|
|
|
|
})
|
|
|
|
|
.collect::<Vec<ValidatorId>>();
|
|
|
|
|
|
|
|
|
|
let result_index_ids = self
|
|
|
|
|
.client
|
|
|
|
|
.get_beacon_states_validators(
|
|
|
|
|
state_id,
|
|
|
|
|
Some(validator_index_ids.as_slice()),
|
|
|
|
|
None,
|
|
|
|
|
)
|
|
|
|
|
.await
|
|
|
|
|
.unwrap()
|
|
|
|
|
.map(|res| res.data);
|
2020-09-29 03:46:54 +00:00
|
|
|
|
2020-10-29 05:13:04 +00:00
|
|
|
let result_pubkey_ids = self
|
|
|
|
|
.client
|
|
|
|
|
.get_beacon_states_validators(
|
|
|
|
|
state_id,
|
|
|
|
|
Some(validator_pubkey_ids.as_slice()),
|
|
|
|
|
None,
|
|
|
|
|
)
|
|
|
|
|
.await
|
|
|
|
|
.unwrap()
|
|
|
|
|
.map(|res| res.data);
|
|
|
|
|
|
|
|
|
|
let expected = state_opt.map(|state| {
|
|
|
|
|
let epoch = state.current_epoch();
|
|
|
|
|
let far_future_epoch = self.chain.spec.far_future_epoch;
|
2020-09-29 03:46:54 +00:00
|
|
|
|
2020-10-29 05:13:04 +00:00
|
|
|
let mut validators = Vec::with_capacity(validator_indices.len());
|
2020-09-29 03:46:54 +00:00
|
|
|
|
2020-10-29 05:13:04 +00:00
|
|
|
for i in validator_indices {
|
2021-07-09 06:15:32 +00:00
|
|
|
if i >= state.validators().len() as u64 {
|
2020-10-29 05:13:04 +00:00
|
|
|
continue;
|
|
|
|
|
}
|
2021-07-09 06:15:32 +00:00
|
|
|
let validator = state.validators()[i as usize].clone();
|
2020-10-29 05:13:04 +00:00
|
|
|
let status = ValidatorStatus::from_validator(
|
2021-02-24 04:15:13 +00:00
|
|
|
&validator,
|
2020-10-29 05:13:04 +00:00
|
|
|
epoch,
|
|
|
|
|
far_future_epoch,
|
|
|
|
|
);
|
2021-02-24 04:15:13 +00:00
|
|
|
if statuses.contains(&status)
|
|
|
|
|
|| statuses.is_empty()
|
|
|
|
|
|| statuses.contains(&status.superstatus())
|
|
|
|
|
{
|
2020-10-29 05:13:04 +00:00
|
|
|
validators.push(ValidatorData {
|
|
|
|
|
index: i as u64,
|
2021-07-09 06:15:32 +00:00
|
|
|
balance: state.balances()[i as usize],
|
2020-10-29 05:13:04 +00:00
|
|
|
status,
|
|
|
|
|
validator,
|
|
|
|
|
});
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
validators
|
|
|
|
|
});
|
|
|
|
|
|
|
|
|
|
assert_eq!(result_index_ids, expected, "{:?}", state_id);
|
|
|
|
|
assert_eq!(result_pubkey_ids, expected, "{:?}", state_id);
|
|
|
|
|
}
|
|
|
|
|
}
|
2020-09-29 03:46:54 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
self
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
pub async fn test_beacon_states_validator_id(self) -> Self {
|
|
|
|
|
for state_id in self.interesting_state_ids() {
|
|
|
|
|
let state_opt = self.get_state(state_id);
|
|
|
|
|
let validators = match state_opt.as_ref() {
|
2021-07-09 06:15:32 +00:00
|
|
|
Some(state) => state.validators().clone().into(),
|
2020-09-29 03:46:54 +00:00
|
|
|
None => vec![],
|
|
|
|
|
};
|
|
|
|
|
|
|
|
|
|
for (i, validator) in validators.into_iter().enumerate() {
|
|
|
|
|
let validator_ids = &[
|
|
|
|
|
ValidatorId::PublicKey(validator.pubkey.clone()),
|
|
|
|
|
ValidatorId::Index(i as u64),
|
|
|
|
|
];
|
|
|
|
|
|
|
|
|
|
for validator_id in validator_ids {
|
|
|
|
|
let result = self
|
|
|
|
|
.client
|
|
|
|
|
.get_beacon_states_validator_id(state_id, validator_id)
|
|
|
|
|
.await
|
|
|
|
|
.unwrap()
|
|
|
|
|
.map(|res| res.data);
|
|
|
|
|
|
|
|
|
|
if result.is_none() && state_opt.is_none() {
|
|
|
|
|
continue;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
let state = state_opt.as_ref().expect("result should be none");
|
|
|
|
|
|
|
|
|
|
let expected = {
|
|
|
|
|
let epoch = state.current_epoch();
|
|
|
|
|
let far_future_epoch = self.chain.spec.far_future_epoch;
|
|
|
|
|
|
|
|
|
|
ValidatorData {
|
|
|
|
|
index: i as u64,
|
2021-07-09 06:15:32 +00:00
|
|
|
balance: state.balances()[i],
|
2020-09-29 03:46:54 +00:00
|
|
|
status: ValidatorStatus::from_validator(
|
2021-02-24 04:15:13 +00:00
|
|
|
&validator,
|
2020-09-29 03:46:54 +00:00
|
|
|
epoch,
|
|
|
|
|
far_future_epoch,
|
|
|
|
|
),
|
|
|
|
|
validator: validator.clone(),
|
|
|
|
|
}
|
|
|
|
|
};
|
|
|
|
|
|
|
|
|
|
assert_eq!(result, Some(expected), "{:?}, {:?}", state_id, validator_id);
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
self
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
pub async fn test_beacon_states_committees(self) -> Self {
|
|
|
|
|
for state_id in self.interesting_state_ids() {
|
|
|
|
|
let mut state_opt = self.get_state(state_id);
|
|
|
|
|
|
2020-11-18 23:31:39 +00:00
|
|
|
let epoch_opt = state_opt.as_ref().map(|state| state.current_epoch());
|
2020-09-29 03:46:54 +00:00
|
|
|
let results = self
|
|
|
|
|
.client
|
2020-11-18 23:31:39 +00:00
|
|
|
.get_beacon_states_committees(state_id, None, None, epoch_opt)
|
2020-09-29 03:46:54 +00:00
|
|
|
.await
|
|
|
|
|
.unwrap()
|
|
|
|
|
.map(|res| res.data);
|
|
|
|
|
|
|
|
|
|
if results.is_none() && state_opt.is_none() {
|
|
|
|
|
continue;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
let state = state_opt.as_mut().expect("result should be none");
|
2020-11-18 23:31:39 +00:00
|
|
|
|
2020-09-29 03:46:54 +00:00
|
|
|
state.build_all_committee_caches(&self.chain.spec).unwrap();
|
|
|
|
|
let committees = state
|
2020-11-18 23:31:39 +00:00
|
|
|
.get_beacon_committees_at_epoch(RelativeEpoch::Current)
|
2020-09-29 03:46:54 +00:00
|
|
|
.unwrap();
|
|
|
|
|
|
|
|
|
|
for (i, result) in results.unwrap().into_iter().enumerate() {
|
|
|
|
|
let expected = &committees[i];
|
|
|
|
|
|
|
|
|
|
assert_eq!(result.index, expected.index, "{}", state_id);
|
|
|
|
|
assert_eq!(result.slot, expected.slot, "{}", state_id);
|
|
|
|
|
assert_eq!(
|
|
|
|
|
result
|
|
|
|
|
.validators
|
|
|
|
|
.into_iter()
|
|
|
|
|
.map(|i| i as usize)
|
|
|
|
|
.collect::<Vec<_>>(),
|
|
|
|
|
expected.committee.to_vec(),
|
|
|
|
|
"{}",
|
|
|
|
|
state_id
|
|
|
|
|
);
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
self
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
fn get_block_root(&self, block_id: BlockId) -> Option<Hash256> {
|
|
|
|
|
match block_id {
|
Use async code when interacting with EL (#3244)
## Overview
This rather extensive PR achieves two primary goals:
1. Uses the finalized/justified checkpoints of fork choice (FC), rather than that of the head state.
2. Refactors fork choice, block production and block processing to `async` functions.
Additionally, it achieves:
- Concurrent forkchoice updates to the EL and cache pruning after a new head is selected.
- Concurrent "block packing" (attestations, etc) and execution payload retrieval during block production.
- Concurrent per-block-processing and execution payload verification during block processing.
- The `Arc`-ification of `SignedBeaconBlock` during block processing (it's never mutated, so why not?):
- I had to do this to deal with sending blocks into spawned tasks.
- Previously we were cloning the beacon block at least 2 times during each block processing, these clones are either removed or turned into cheaper `Arc` clones.
- We were also `Box`-ing and un-`Box`-ing beacon blocks as they moved throughout the networking crate. This is not a big deal, but it's nice to avoid shifting things between the stack and heap.
- Avoids cloning *all the blocks* in *every chain segment* during sync.
- It also has the potential to clean up our code where we need to pass an *owned* block around so we can send it back in the case of an error (I didn't do much of this, my PR is already big enough :sweat_smile:)
- The `BeaconChain::HeadSafetyStatus` struct was removed. It was an old relic from prior merge specs.
For motivation for this change, see https://github.com/sigp/lighthouse/pull/3244#issuecomment-1160963273
## Changes to `canonical_head` and `fork_choice`
Previously, the `BeaconChain` had two separate fields:
```
canonical_head: RwLock<Snapshot>,
fork_choice: RwLock<BeaconForkChoice>
```
Now, we have grouped these values under a single struct:
```
canonical_head: CanonicalHead {
cached_head: RwLock<Arc<Snapshot>>,
fork_choice: RwLock<BeaconForkChoice>
}
```
Apart from ergonomics, the only *actual* change here is wrapping the canonical head snapshot in an `Arc`. This means that we no longer need to hold the `cached_head` (`canonical_head`, in old terms) lock when we want to pull some values from it. This was done to avoid deadlock risks by preventing functions from acquiring (and holding) the `cached_head` and `fork_choice` locks simultaneously.
## Breaking Changes
### The `state` (root) field in the `finalized_checkpoint` SSE event
Consider the scenario where epoch `n` is just finalized, but `start_slot(n)` is skipped. There are two state roots we might in the `finalized_checkpoint` SSE event:
1. The state root of the finalized block, which is `get_block(finalized_checkpoint.root).state_root`.
4. The state root at slot of `start_slot(n)`, which would be the state from (1), but "skipped forward" through any skip slots.
Previously, Lighthouse would choose (2). However, we can see that when [Teku generates that event](https://github.com/ConsenSys/teku/blob/de2b2801c89ef5abf983d6bf37867c37fc47121f/data/beaconrestapi/src/main/java/tech/pegasys/teku/beaconrestapi/handlers/v1/events/EventSubscriptionManager.java#L171-L182) it uses [`getStateRootFromBlockRoot`](https://github.com/ConsenSys/teku/blob/de2b2801c89ef5abf983d6bf37867c37fc47121f/data/provider/src/main/java/tech/pegasys/teku/api/ChainDataProvider.java#L336-L341) which uses (1).
I have switched Lighthouse from (2) to (1). I think it's a somewhat arbitrary choice between the two, where (1) is easier to compute and is consistent with Teku.
## Notes for Reviewers
I've renamed `BeaconChain::fork_choice` to `BeaconChain::recompute_head`. Doing this helped ensure I broke all previous uses of fork choice and I also find it more descriptive. It describes an action and can't be confused with trying to get a reference to the `ForkChoice` struct.
I've changed the ordering of SSE events when a block is received. It used to be `[block, finalized, head]` and now it's `[block, head, finalized]`. It was easier this way and I don't think we were making any promises about SSE event ordering so it's not "breaking".
I've made it so fork choice will run when it's first constructed. I did this because I wanted to have a cached version of the last call to `get_head`. Ensuring `get_head` has been run *at least once* means that the cached values doesn't need to wrapped in an `Option`. This was fairly simple, it just involved passing a `slot` to the constructor so it knows *when* it's being run. When loading a fork choice from the store and a slot clock isn't handy I've just used the `slot` that was saved in the `fork_choice_store`. That seems like it would be a faithful representation of the slot when we saved it.
I added the `genesis_time: u64` to the `BeaconChain`. It's small, constant and nice to have around.
Since we're using FC for the fin/just checkpoints, we no longer get the `0x00..00` roots at genesis. You can see I had to remove a work-around in `ef-tests` here: b56be3bc2. I can't find any reason why this would be an issue, if anything I think it'll be better since the genesis-alias has caught us out a few times (0x00..00 isn't actually a real root). Edit: I did find a case where the `network` expected the 0x00..00 alias and patched it here: 3f26ac3e2.
You'll notice a lot of changes in tests. Generally, tests should be functionally equivalent. Here are the things creating the most diff-noise in tests:
- Changing tests to be `tokio::async` tests.
- Adding `.await` to fork choice, block processing and block production functions.
- Refactor of the `canonical_head` "API" provided by the `BeaconChain`. E.g., `chain.canonical_head.cached_head()` instead of `chain.canonical_head.read()`.
- Wrapping `SignedBeaconBlock` in an `Arc`.
- In the `beacon_chain/tests/block_verification`, we can't use the `lazy_static` `CHAIN_SEGMENT` variable anymore since it's generated with an async function. We just generate it in each test, not so efficient but hopefully insignificant.
I had to disable `rayon` concurrent tests in the `fork_choice` tests. This is because the use of `rayon` and `block_on` was causing a panic.
Co-authored-by: Mac L <mjladson@pm.me>
2022-07-03 05:36:50 +00:00
|
|
|
BlockId::Head => Some(self.chain.canonical_head.cached_head().head_block_root()),
|
2020-09-29 03:46:54 +00:00
|
|
|
BlockId::Genesis => Some(self.chain.genesis_block_root),
|
Use async code when interacting with EL (#3244)
## Overview
This rather extensive PR achieves two primary goals:
1. Uses the finalized/justified checkpoints of fork choice (FC), rather than that of the head state.
2. Refactors fork choice, block production and block processing to `async` functions.
Additionally, it achieves:
- Concurrent forkchoice updates to the EL and cache pruning after a new head is selected.
- Concurrent "block packing" (attestations, etc) and execution payload retrieval during block production.
- Concurrent per-block-processing and execution payload verification during block processing.
- The `Arc`-ification of `SignedBeaconBlock` during block processing (it's never mutated, so why not?):
- I had to do this to deal with sending blocks into spawned tasks.
- Previously we were cloning the beacon block at least 2 times during each block processing, these clones are either removed or turned into cheaper `Arc` clones.
- We were also `Box`-ing and un-`Box`-ing beacon blocks as they moved throughout the networking crate. This is not a big deal, but it's nice to avoid shifting things between the stack and heap.
- Avoids cloning *all the blocks* in *every chain segment* during sync.
- It also has the potential to clean up our code where we need to pass an *owned* block around so we can send it back in the case of an error (I didn't do much of this, my PR is already big enough :sweat_smile:)
- The `BeaconChain::HeadSafetyStatus` struct was removed. It was an old relic from prior merge specs.
For motivation for this change, see https://github.com/sigp/lighthouse/pull/3244#issuecomment-1160963273
## Changes to `canonical_head` and `fork_choice`
Previously, the `BeaconChain` had two separate fields:
```
canonical_head: RwLock<Snapshot>,
fork_choice: RwLock<BeaconForkChoice>
```
Now, we have grouped these values under a single struct:
```
canonical_head: CanonicalHead {
cached_head: RwLock<Arc<Snapshot>>,
fork_choice: RwLock<BeaconForkChoice>
}
```
Apart from ergonomics, the only *actual* change here is wrapping the canonical head snapshot in an `Arc`. This means that we no longer need to hold the `cached_head` (`canonical_head`, in old terms) lock when we want to pull some values from it. This was done to avoid deadlock risks by preventing functions from acquiring (and holding) the `cached_head` and `fork_choice` locks simultaneously.
## Breaking Changes
### The `state` (root) field in the `finalized_checkpoint` SSE event
Consider the scenario where epoch `n` is just finalized, but `start_slot(n)` is skipped. There are two state roots we might in the `finalized_checkpoint` SSE event:
1. The state root of the finalized block, which is `get_block(finalized_checkpoint.root).state_root`.
4. The state root at slot of `start_slot(n)`, which would be the state from (1), but "skipped forward" through any skip slots.
Previously, Lighthouse would choose (2). However, we can see that when [Teku generates that event](https://github.com/ConsenSys/teku/blob/de2b2801c89ef5abf983d6bf37867c37fc47121f/data/beaconrestapi/src/main/java/tech/pegasys/teku/beaconrestapi/handlers/v1/events/EventSubscriptionManager.java#L171-L182) it uses [`getStateRootFromBlockRoot`](https://github.com/ConsenSys/teku/blob/de2b2801c89ef5abf983d6bf37867c37fc47121f/data/provider/src/main/java/tech/pegasys/teku/api/ChainDataProvider.java#L336-L341) which uses (1).
I have switched Lighthouse from (2) to (1). I think it's a somewhat arbitrary choice between the two, where (1) is easier to compute and is consistent with Teku.
## Notes for Reviewers
I've renamed `BeaconChain::fork_choice` to `BeaconChain::recompute_head`. Doing this helped ensure I broke all previous uses of fork choice and I also find it more descriptive. It describes an action and can't be confused with trying to get a reference to the `ForkChoice` struct.
I've changed the ordering of SSE events when a block is received. It used to be `[block, finalized, head]` and now it's `[block, head, finalized]`. It was easier this way and I don't think we were making any promises about SSE event ordering so it's not "breaking".
I've made it so fork choice will run when it's first constructed. I did this because I wanted to have a cached version of the last call to `get_head`. Ensuring `get_head` has been run *at least once* means that the cached values doesn't need to wrapped in an `Option`. This was fairly simple, it just involved passing a `slot` to the constructor so it knows *when* it's being run. When loading a fork choice from the store and a slot clock isn't handy I've just used the `slot` that was saved in the `fork_choice_store`. That seems like it would be a faithful representation of the slot when we saved it.
I added the `genesis_time: u64` to the `BeaconChain`. It's small, constant and nice to have around.
Since we're using FC for the fin/just checkpoints, we no longer get the `0x00..00` roots at genesis. You can see I had to remove a work-around in `ef-tests` here: b56be3bc2. I can't find any reason why this would be an issue, if anything I think it'll be better since the genesis-alias has caught us out a few times (0x00..00 isn't actually a real root). Edit: I did find a case where the `network` expected the 0x00..00 alias and patched it here: 3f26ac3e2.
You'll notice a lot of changes in tests. Generally, tests should be functionally equivalent. Here are the things creating the most diff-noise in tests:
- Changing tests to be `tokio::async` tests.
- Adding `.await` to fork choice, block processing and block production functions.
- Refactor of the `canonical_head` "API" provided by the `BeaconChain`. E.g., `chain.canonical_head.cached_head()` instead of `chain.canonical_head.read()`.
- Wrapping `SignedBeaconBlock` in an `Arc`.
- In the `beacon_chain/tests/block_verification`, we can't use the `lazy_static` `CHAIN_SEGMENT` variable anymore since it's generated with an async function. We just generate it in each test, not so efficient but hopefully insignificant.
I had to disable `rayon` concurrent tests in the `fork_choice` tests. This is because the use of `rayon` and `block_on` was causing a panic.
Co-authored-by: Mac L <mjladson@pm.me>
2022-07-03 05:36:50 +00:00
|
|
|
BlockId::Finalized => Some(
|
|
|
|
|
self.chain
|
|
|
|
|
.canonical_head
|
|
|
|
|
.cached_head()
|
|
|
|
|
.finalized_checkpoint()
|
|
|
|
|
.root,
|
|
|
|
|
),
|
2020-09-29 03:46:54 +00:00
|
|
|
BlockId::Justified => Some(
|
|
|
|
|
self.chain
|
Use async code when interacting with EL (#3244)
## Overview
This rather extensive PR achieves two primary goals:
1. Uses the finalized/justified checkpoints of fork choice (FC), rather than that of the head state.
2. Refactors fork choice, block production and block processing to `async` functions.
Additionally, it achieves:
- Concurrent forkchoice updates to the EL and cache pruning after a new head is selected.
- Concurrent "block packing" (attestations, etc) and execution payload retrieval during block production.
- Concurrent per-block-processing and execution payload verification during block processing.
- The `Arc`-ification of `SignedBeaconBlock` during block processing (it's never mutated, so why not?):
- I had to do this to deal with sending blocks into spawned tasks.
- Previously we were cloning the beacon block at least 2 times during each block processing, these clones are either removed or turned into cheaper `Arc` clones.
- We were also `Box`-ing and un-`Box`-ing beacon blocks as they moved throughout the networking crate. This is not a big deal, but it's nice to avoid shifting things between the stack and heap.
- Avoids cloning *all the blocks* in *every chain segment* during sync.
- It also has the potential to clean up our code where we need to pass an *owned* block around so we can send it back in the case of an error (I didn't do much of this, my PR is already big enough :sweat_smile:)
- The `BeaconChain::HeadSafetyStatus` struct was removed. It was an old relic from prior merge specs.
For motivation for this change, see https://github.com/sigp/lighthouse/pull/3244#issuecomment-1160963273
## Changes to `canonical_head` and `fork_choice`
Previously, the `BeaconChain` had two separate fields:
```
canonical_head: RwLock<Snapshot>,
fork_choice: RwLock<BeaconForkChoice>
```
Now, we have grouped these values under a single struct:
```
canonical_head: CanonicalHead {
cached_head: RwLock<Arc<Snapshot>>,
fork_choice: RwLock<BeaconForkChoice>
}
```
Apart from ergonomics, the only *actual* change here is wrapping the canonical head snapshot in an `Arc`. This means that we no longer need to hold the `cached_head` (`canonical_head`, in old terms) lock when we want to pull some values from it. This was done to avoid deadlock risks by preventing functions from acquiring (and holding) the `cached_head` and `fork_choice` locks simultaneously.
## Breaking Changes
### The `state` (root) field in the `finalized_checkpoint` SSE event
Consider the scenario where epoch `n` is just finalized, but `start_slot(n)` is skipped. There are two state roots we might in the `finalized_checkpoint` SSE event:
1. The state root of the finalized block, which is `get_block(finalized_checkpoint.root).state_root`.
4. The state root at slot of `start_slot(n)`, which would be the state from (1), but "skipped forward" through any skip slots.
Previously, Lighthouse would choose (2). However, we can see that when [Teku generates that event](https://github.com/ConsenSys/teku/blob/de2b2801c89ef5abf983d6bf37867c37fc47121f/data/beaconrestapi/src/main/java/tech/pegasys/teku/beaconrestapi/handlers/v1/events/EventSubscriptionManager.java#L171-L182) it uses [`getStateRootFromBlockRoot`](https://github.com/ConsenSys/teku/blob/de2b2801c89ef5abf983d6bf37867c37fc47121f/data/provider/src/main/java/tech/pegasys/teku/api/ChainDataProvider.java#L336-L341) which uses (1).
I have switched Lighthouse from (2) to (1). I think it's a somewhat arbitrary choice between the two, where (1) is easier to compute and is consistent with Teku.
## Notes for Reviewers
I've renamed `BeaconChain::fork_choice` to `BeaconChain::recompute_head`. Doing this helped ensure I broke all previous uses of fork choice and I also find it more descriptive. It describes an action and can't be confused with trying to get a reference to the `ForkChoice` struct.
I've changed the ordering of SSE events when a block is received. It used to be `[block, finalized, head]` and now it's `[block, head, finalized]`. It was easier this way and I don't think we were making any promises about SSE event ordering so it's not "breaking".
I've made it so fork choice will run when it's first constructed. I did this because I wanted to have a cached version of the last call to `get_head`. Ensuring `get_head` has been run *at least once* means that the cached values doesn't need to wrapped in an `Option`. This was fairly simple, it just involved passing a `slot` to the constructor so it knows *when* it's being run. When loading a fork choice from the store and a slot clock isn't handy I've just used the `slot` that was saved in the `fork_choice_store`. That seems like it would be a faithful representation of the slot when we saved it.
I added the `genesis_time: u64` to the `BeaconChain`. It's small, constant and nice to have around.
Since we're using FC for the fin/just checkpoints, we no longer get the `0x00..00` roots at genesis. You can see I had to remove a work-around in `ef-tests` here: b56be3bc2. I can't find any reason why this would be an issue, if anything I think it'll be better since the genesis-alias has caught us out a few times (0x00..00 isn't actually a real root). Edit: I did find a case where the `network` expected the 0x00..00 alias and patched it here: 3f26ac3e2.
You'll notice a lot of changes in tests. Generally, tests should be functionally equivalent. Here are the things creating the most diff-noise in tests:
- Changing tests to be `tokio::async` tests.
- Adding `.await` to fork choice, block processing and block production functions.
- Refactor of the `canonical_head` "API" provided by the `BeaconChain`. E.g., `chain.canonical_head.cached_head()` instead of `chain.canonical_head.read()`.
- Wrapping `SignedBeaconBlock` in an `Arc`.
- In the `beacon_chain/tests/block_verification`, we can't use the `lazy_static` `CHAIN_SEGMENT` variable anymore since it's generated with an async function. We just generate it in each test, not so efficient but hopefully insignificant.
I had to disable `rayon` concurrent tests in the `fork_choice` tests. This is because the use of `rayon` and `block_on` was causing a panic.
Co-authored-by: Mac L <mjladson@pm.me>
2022-07-03 05:36:50 +00:00
|
|
|
.canonical_head
|
|
|
|
|
.cached_head()
|
|
|
|
|
.justified_checkpoint()
|
2020-09-29 03:46:54 +00:00
|
|
|
.root,
|
|
|
|
|
),
|
Use the forwards iterator more often (#2376)
## Issue Addressed
NA
## Primary Change
When investigating memory usage, I noticed that retrieving a block from an early slot (e.g., slot 900) would cause a sharp increase in the memory footprint (from 400mb to 800mb+) which seemed to be ever-lasting.
After some investigation, I found that the reverse iteration from the head back to that slot was the likely culprit. To counter this, I've switched the `BeaconChain::block_root_at_slot` to use the forwards iterator, instead of the reverse one.
I also noticed that the networking stack is using `BeaconChain::root_at_slot` to check if a peer is relevant (`check_peer_relevance`). Perhaps the steep, seemingly-random-but-consistent increases in memory usage are caused by the use of this function.
Using the forwards iterator with the HTTP API alleviated the sharp increases in memory usage. It also made the response much faster (before it felt like to took 1-2s, now it feels instant).
## Additional Changes
In the process I also noticed that we have two functions for getting block roots:
- `BeaconChain::block_root_at_slot`: returns `None` for a skip slot.
- `BeaconChain::root_at_slot`: returns the previous root for a skip slot.
I unified these two functions into `block_root_at_slot` and added the `WhenSlotSkipped` enum. Now, the caller must be explicit about the skip-slot behaviour when requesting a root.
Additionally, I replaced `vec![]` with `Vec::with_capacity` in `store::chunked_vector::range_query`. I stumbled across this whilst debugging and made this modification to see what effect it would have (not much). It seems like a decent change to keep around, but I'm not concerned either way.
Also, `BeaconChain::get_ancestor_block_root` is unused, so I got rid of it :wastebasket:.
## Additional Info
I haven't also done the same for state roots here. Whilst it's possible and a good idea, it's more work since the fwds iterators are presently block-roots-specific.
Whilst there's a few places a reverse iteration of state roots could be triggered (e.g., attestation production, HTTP API), they're no where near as common as the `check_peer_relevance` call. As such, I think we should get this PR merged first, then come back for the state root iters. I made an issue here https://github.com/sigp/lighthouse/issues/2377.
2021-05-31 04:18:20 +00:00
|
|
|
BlockId::Slot(slot) => self
|
|
|
|
|
.chain
|
|
|
|
|
.block_root_at_slot(slot, WhenSlotSkipped::None)
|
|
|
|
|
.unwrap(),
|
2020-09-29 03:46:54 +00:00
|
|
|
BlockId::Root(root) => Some(root),
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
Separate execution payloads in the DB (#3157)
## Proposed Changes
Reduce post-merge disk usage by not storing finalized execution payloads in Lighthouse's database.
:warning: **This is achieved in a backwards-incompatible way for networks that have already merged** :warning:. Kiln users and shadow fork enjoyers will be unable to downgrade after running the code from this PR. The upgrade migration may take several minutes to run, and can't be aborted after it begins.
The main changes are:
- New column in the database called `ExecPayload`, keyed by beacon block root.
- The `BeaconBlock` column now stores blinded blocks only.
- Lots of places that previously used full blocks now use blinded blocks, e.g. analytics APIs, block replay in the DB, etc.
- On finalization:
- `prune_abanonded_forks` deletes non-canonical payloads whilst deleting non-canonical blocks.
- `migrate_db` deletes finalized canonical payloads whilst deleting finalized states.
- Conversions between blinded and full blocks are implemented in a compositional way, duplicating some work from Sean's PR #3134.
- The execution layer has a new `get_payload_by_block_hash` method that reconstructs a payload using the EE's `eth_getBlockByHash` call.
- I've tested manually that it works on Kiln, using Geth and Nethermind.
- This isn't necessarily the most efficient method, and new engine APIs are being discussed to improve this: https://github.com/ethereum/execution-apis/pull/146.
- We're depending on the `ethers` master branch, due to lots of recent changes. We're also using a workaround for https://github.com/gakonst/ethers-rs/issues/1134.
- Payload reconstruction is used in the HTTP API via `BeaconChain::get_block`, which is now `async`. Due to the `async` fn, the `blocking_json` wrapper has been removed.
- Payload reconstruction is used in network RPC to serve blocks-by-{root,range} responses. Here the `async` adjustment is messier, although I think I've managed to come up with a reasonable compromise: the handlers take the `SendOnDrop` by value so that they can drop it on _task completion_ (after the `fn` returns). Still, this is introducing disk reads onto core executor threads, which may have a negative performance impact (thoughts appreciated).
## Additional Info
- [x] For performance it would be great to remove the cloning of full blocks when converting them to blinded blocks to write to disk. I'm going to experiment with a `put_block` API that takes the block by value, breaks it into a blinded block and a payload, stores the blinded block, and then re-assembles the full block for the caller.
- [x] We should measure the latency of blocks-by-root and blocks-by-range responses.
- [x] We should add integration tests that stress the payload reconstruction (basic tests done, issue for more extensive tests: https://github.com/sigp/lighthouse/issues/3159)
- [x] We should (manually) test the schema v9 migration from several prior versions, particularly as blocks have changed on disk and some migrations rely on being able to load blocks.
Co-authored-by: Paul Hauner <paul@paulhauner.com>
2022-05-12 00:42:17 +00:00
|
|
|
async fn get_block(&self, block_id: BlockId) -> Option<SignedBeaconBlock<E>> {
|
|
|
|
|
let root = self.get_block_root(block_id)?;
|
|
|
|
|
self.chain.get_block(&root).await.unwrap()
|
2020-09-29 03:46:54 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
pub async fn test_beacon_headers_all_slots(self) -> Self {
|
|
|
|
|
for slot in 0..CHAIN_LENGTH {
|
|
|
|
|
let slot = Slot::from(slot);
|
|
|
|
|
|
|
|
|
|
let result = self
|
|
|
|
|
.client
|
|
|
|
|
.get_beacon_headers(Some(slot), None)
|
|
|
|
|
.await
|
|
|
|
|
.unwrap()
|
|
|
|
|
.map(|res| res.data);
|
|
|
|
|
|
Use the forwards iterator more often (#2376)
## Issue Addressed
NA
## Primary Change
When investigating memory usage, I noticed that retrieving a block from an early slot (e.g., slot 900) would cause a sharp increase in the memory footprint (from 400mb to 800mb+) which seemed to be ever-lasting.
After some investigation, I found that the reverse iteration from the head back to that slot was the likely culprit. To counter this, I've switched the `BeaconChain::block_root_at_slot` to use the forwards iterator, instead of the reverse one.
I also noticed that the networking stack is using `BeaconChain::root_at_slot` to check if a peer is relevant (`check_peer_relevance`). Perhaps the steep, seemingly-random-but-consistent increases in memory usage are caused by the use of this function.
Using the forwards iterator with the HTTP API alleviated the sharp increases in memory usage. It also made the response much faster (before it felt like to took 1-2s, now it feels instant).
## Additional Changes
In the process I also noticed that we have two functions for getting block roots:
- `BeaconChain::block_root_at_slot`: returns `None` for a skip slot.
- `BeaconChain::root_at_slot`: returns the previous root for a skip slot.
I unified these two functions into `block_root_at_slot` and added the `WhenSlotSkipped` enum. Now, the caller must be explicit about the skip-slot behaviour when requesting a root.
Additionally, I replaced `vec![]` with `Vec::with_capacity` in `store::chunked_vector::range_query`. I stumbled across this whilst debugging and made this modification to see what effect it would have (not much). It seems like a decent change to keep around, but I'm not concerned either way.
Also, `BeaconChain::get_ancestor_block_root` is unused, so I got rid of it :wastebasket:.
## Additional Info
I haven't also done the same for state roots here. Whilst it's possible and a good idea, it's more work since the fwds iterators are presently block-roots-specific.
Whilst there's a few places a reverse iteration of state roots could be triggered (e.g., attestation production, HTTP API), they're no where near as common as the `check_peer_relevance` call. As such, I think we should get this PR merged first, then come back for the state root iters. I made an issue here https://github.com/sigp/lighthouse/issues/2377.
2021-05-31 04:18:20 +00:00
|
|
|
let root = self
|
|
|
|
|
.chain
|
|
|
|
|
.block_root_at_slot(slot, WhenSlotSkipped::None)
|
|
|
|
|
.unwrap();
|
2020-09-29 03:46:54 +00:00
|
|
|
|
|
|
|
|
if root.is_none() && result.is_none() {
|
|
|
|
|
continue;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
let root = root.unwrap();
|
Use the forwards iterator more often (#2376)
## Issue Addressed
NA
## Primary Change
When investigating memory usage, I noticed that retrieving a block from an early slot (e.g., slot 900) would cause a sharp increase in the memory footprint (from 400mb to 800mb+) which seemed to be ever-lasting.
After some investigation, I found that the reverse iteration from the head back to that slot was the likely culprit. To counter this, I've switched the `BeaconChain::block_root_at_slot` to use the forwards iterator, instead of the reverse one.
I also noticed that the networking stack is using `BeaconChain::root_at_slot` to check if a peer is relevant (`check_peer_relevance`). Perhaps the steep, seemingly-random-but-consistent increases in memory usage are caused by the use of this function.
Using the forwards iterator with the HTTP API alleviated the sharp increases in memory usage. It also made the response much faster (before it felt like to took 1-2s, now it feels instant).
## Additional Changes
In the process I also noticed that we have two functions for getting block roots:
- `BeaconChain::block_root_at_slot`: returns `None` for a skip slot.
- `BeaconChain::root_at_slot`: returns the previous root for a skip slot.
I unified these two functions into `block_root_at_slot` and added the `WhenSlotSkipped` enum. Now, the caller must be explicit about the skip-slot behaviour when requesting a root.
Additionally, I replaced `vec![]` with `Vec::with_capacity` in `store::chunked_vector::range_query`. I stumbled across this whilst debugging and made this modification to see what effect it would have (not much). It seems like a decent change to keep around, but I'm not concerned either way.
Also, `BeaconChain::get_ancestor_block_root` is unused, so I got rid of it :wastebasket:.
## Additional Info
I haven't also done the same for state roots here. Whilst it's possible and a good idea, it's more work since the fwds iterators are presently block-roots-specific.
Whilst there's a few places a reverse iteration of state roots could be triggered (e.g., attestation production, HTTP API), they're no where near as common as the `check_peer_relevance` call. As such, I think we should get this PR merged first, then come back for the state root iters. I made an issue here https://github.com/sigp/lighthouse/issues/2377.
2021-05-31 04:18:20 +00:00
|
|
|
let block = self
|
|
|
|
|
.chain
|
|
|
|
|
.block_at_slot(slot, WhenSlotSkipped::Prev)
|
|
|
|
|
.unwrap()
|
|
|
|
|
.unwrap();
|
2020-09-29 03:46:54 +00:00
|
|
|
let header = BlockHeaderData {
|
|
|
|
|
root,
|
|
|
|
|
canonical: true,
|
|
|
|
|
header: BlockHeaderAndSignature {
|
2021-07-09 06:15:32 +00:00
|
|
|
message: block.message().block_header(),
|
|
|
|
|
signature: block.signature().clone().into(),
|
2020-09-29 03:46:54 +00:00
|
|
|
},
|
|
|
|
|
};
|
|
|
|
|
let expected = vec![header];
|
|
|
|
|
|
|
|
|
|
assert_eq!(result.unwrap(), expected, "slot {:?}", slot);
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
self
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
pub async fn test_beacon_headers_all_parents(self) -> Self {
|
|
|
|
|
let mut roots = self
|
|
|
|
|
.chain
|
2021-07-06 02:38:53 +00:00
|
|
|
.forwards_iter_block_roots(Slot::new(0))
|
2020-09-29 03:46:54 +00:00
|
|
|
.unwrap()
|
|
|
|
|
.map(Result::unwrap)
|
|
|
|
|
.map(|(root, _slot)| root)
|
|
|
|
|
.collect::<Vec<_>>();
|
|
|
|
|
|
|
|
|
|
// The iterator natively returns duplicate roots for skipped slots.
|
|
|
|
|
roots.dedup();
|
|
|
|
|
|
|
|
|
|
for i in 1..roots.len() {
|
|
|
|
|
let parent_root = roots[i - 1];
|
|
|
|
|
let child_root = roots[i];
|
|
|
|
|
|
|
|
|
|
let result = self
|
|
|
|
|
.client
|
|
|
|
|
.get_beacon_headers(None, Some(parent_root))
|
|
|
|
|
.await
|
|
|
|
|
.unwrap()
|
|
|
|
|
.unwrap()
|
|
|
|
|
.data;
|
|
|
|
|
|
|
|
|
|
assert_eq!(result.len(), 1, "i {}", i);
|
|
|
|
|
assert_eq!(result[0].root, child_root, "i {}", i);
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
self
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
pub async fn test_beacon_headers_block_id(self) -> Self {
|
|
|
|
|
for block_id in self.interesting_block_ids() {
|
|
|
|
|
let result = self
|
|
|
|
|
.client
|
|
|
|
|
.get_beacon_headers_block_id(block_id)
|
|
|
|
|
.await
|
|
|
|
|
.unwrap()
|
|
|
|
|
.map(|res| res.data);
|
|
|
|
|
|
|
|
|
|
let block_root_opt = self.get_block_root(block_id);
|
|
|
|
|
|
2021-04-25 03:59:59 +00:00
|
|
|
if let BlockId::Slot(slot) = block_id {
|
|
|
|
|
if block_root_opt.is_none() {
|
|
|
|
|
assert!(SKIPPED_SLOTS.contains(&slot.as_u64()));
|
|
|
|
|
} else {
|
|
|
|
|
assert!(!SKIPPED_SLOTS.contains(&slot.as_u64()));
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
Separate execution payloads in the DB (#3157)
## Proposed Changes
Reduce post-merge disk usage by not storing finalized execution payloads in Lighthouse's database.
:warning: **This is achieved in a backwards-incompatible way for networks that have already merged** :warning:. Kiln users and shadow fork enjoyers will be unable to downgrade after running the code from this PR. The upgrade migration may take several minutes to run, and can't be aborted after it begins.
The main changes are:
- New column in the database called `ExecPayload`, keyed by beacon block root.
- The `BeaconBlock` column now stores blinded blocks only.
- Lots of places that previously used full blocks now use blinded blocks, e.g. analytics APIs, block replay in the DB, etc.
- On finalization:
- `prune_abanonded_forks` deletes non-canonical payloads whilst deleting non-canonical blocks.
- `migrate_db` deletes finalized canonical payloads whilst deleting finalized states.
- Conversions between blinded and full blocks are implemented in a compositional way, duplicating some work from Sean's PR #3134.
- The execution layer has a new `get_payload_by_block_hash` method that reconstructs a payload using the EE's `eth_getBlockByHash` call.
- I've tested manually that it works on Kiln, using Geth and Nethermind.
- This isn't necessarily the most efficient method, and new engine APIs are being discussed to improve this: https://github.com/ethereum/execution-apis/pull/146.
- We're depending on the `ethers` master branch, due to lots of recent changes. We're also using a workaround for https://github.com/gakonst/ethers-rs/issues/1134.
- Payload reconstruction is used in the HTTP API via `BeaconChain::get_block`, which is now `async`. Due to the `async` fn, the `blocking_json` wrapper has been removed.
- Payload reconstruction is used in network RPC to serve blocks-by-{root,range} responses. Here the `async` adjustment is messier, although I think I've managed to come up with a reasonable compromise: the handlers take the `SendOnDrop` by value so that they can drop it on _task completion_ (after the `fn` returns). Still, this is introducing disk reads onto core executor threads, which may have a negative performance impact (thoughts appreciated).
## Additional Info
- [x] For performance it would be great to remove the cloning of full blocks when converting them to blinded blocks to write to disk. I'm going to experiment with a `put_block` API that takes the block by value, breaks it into a blinded block and a payload, stores the blinded block, and then re-assembles the full block for the caller.
- [x] We should measure the latency of blocks-by-root and blocks-by-range responses.
- [x] We should add integration tests that stress the payload reconstruction (basic tests done, issue for more extensive tests: https://github.com/sigp/lighthouse/issues/3159)
- [x] We should (manually) test the schema v9 migration from several prior versions, particularly as blocks have changed on disk and some migrations rely on being able to load blocks.
Co-authored-by: Paul Hauner <paul@paulhauner.com>
2022-05-12 00:42:17 +00:00
|
|
|
let block_opt = if let Some(root) = block_root_opt {
|
|
|
|
|
self.chain.get_block(&root).await.unwrap()
|
|
|
|
|
} else {
|
|
|
|
|
None
|
|
|
|
|
};
|
2020-09-29 03:46:54 +00:00
|
|
|
|
|
|
|
|
if block_opt.is_none() && result.is_none() {
|
|
|
|
|
continue;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
let result = result.unwrap();
|
|
|
|
|
let block = block_opt.unwrap();
|
|
|
|
|
let block_root = block_root_opt.unwrap();
|
|
|
|
|
let canonical = self
|
|
|
|
|
.chain
|
Use the forwards iterator more often (#2376)
## Issue Addressed
NA
## Primary Change
When investigating memory usage, I noticed that retrieving a block from an early slot (e.g., slot 900) would cause a sharp increase in the memory footprint (from 400mb to 800mb+) which seemed to be ever-lasting.
After some investigation, I found that the reverse iteration from the head back to that slot was the likely culprit. To counter this, I've switched the `BeaconChain::block_root_at_slot` to use the forwards iterator, instead of the reverse one.
I also noticed that the networking stack is using `BeaconChain::root_at_slot` to check if a peer is relevant (`check_peer_relevance`). Perhaps the steep, seemingly-random-but-consistent increases in memory usage are caused by the use of this function.
Using the forwards iterator with the HTTP API alleviated the sharp increases in memory usage. It also made the response much faster (before it felt like to took 1-2s, now it feels instant).
## Additional Changes
In the process I also noticed that we have two functions for getting block roots:
- `BeaconChain::block_root_at_slot`: returns `None` for a skip slot.
- `BeaconChain::root_at_slot`: returns the previous root for a skip slot.
I unified these two functions into `block_root_at_slot` and added the `WhenSlotSkipped` enum. Now, the caller must be explicit about the skip-slot behaviour when requesting a root.
Additionally, I replaced `vec![]` with `Vec::with_capacity` in `store::chunked_vector::range_query`. I stumbled across this whilst debugging and made this modification to see what effect it would have (not much). It seems like a decent change to keep around, but I'm not concerned either way.
Also, `BeaconChain::get_ancestor_block_root` is unused, so I got rid of it :wastebasket:.
## Additional Info
I haven't also done the same for state roots here. Whilst it's possible and a good idea, it's more work since the fwds iterators are presently block-roots-specific.
Whilst there's a few places a reverse iteration of state roots could be triggered (e.g., attestation production, HTTP API), they're no where near as common as the `check_peer_relevance` call. As such, I think we should get this PR merged first, then come back for the state root iters. I made an issue here https://github.com/sigp/lighthouse/issues/2377.
2021-05-31 04:18:20 +00:00
|
|
|
.block_root_at_slot(block.slot(), WhenSlotSkipped::None)
|
2020-09-29 03:46:54 +00:00
|
|
|
.unwrap()
|
|
|
|
|
.map_or(false, |canonical| block_root == canonical);
|
|
|
|
|
|
|
|
|
|
assert_eq!(result.canonical, canonical, "{:?}", block_id);
|
|
|
|
|
assert_eq!(result.root, block_root, "{:?}", block_id);
|
|
|
|
|
assert_eq!(
|
|
|
|
|
result.header.message,
|
2021-07-09 06:15:32 +00:00
|
|
|
block.message().block_header(),
|
2020-09-29 03:46:54 +00:00
|
|
|
"{:?}",
|
|
|
|
|
block_id
|
|
|
|
|
);
|
|
|
|
|
assert_eq!(
|
|
|
|
|
result.header.signature,
|
2021-07-09 06:15:32 +00:00
|
|
|
block.signature().clone().into(),
|
2020-09-29 03:46:54 +00:00
|
|
|
"{:?}",
|
|
|
|
|
block_id
|
|
|
|
|
);
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
self
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
pub async fn test_beacon_blocks_root(self) -> Self {
|
|
|
|
|
for block_id in self.interesting_block_ids() {
|
|
|
|
|
let result = self
|
|
|
|
|
.client
|
|
|
|
|
.get_beacon_blocks_root(block_id)
|
|
|
|
|
.await
|
|
|
|
|
.unwrap()
|
|
|
|
|
.map(|res| res.data.root);
|
|
|
|
|
|
|
|
|
|
let expected = self.get_block_root(block_id);
|
2021-04-25 03:59:59 +00:00
|
|
|
if let BlockId::Slot(slot) = block_id {
|
|
|
|
|
if expected.is_none() {
|
|
|
|
|
assert!(SKIPPED_SLOTS.contains(&slot.as_u64()));
|
|
|
|
|
} else {
|
|
|
|
|
assert!(!SKIPPED_SLOTS.contains(&slot.as_u64()));
|
|
|
|
|
}
|
|
|
|
|
}
|
2020-09-29 03:46:54 +00:00
|
|
|
assert_eq!(result, expected, "{:?}", block_id);
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
self
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
pub async fn test_post_beacon_blocks_valid(mut self) -> Self {
|
|
|
|
|
let next_block = &self.next_block;
|
|
|
|
|
|
|
|
|
|
self.client.post_beacon_blocks(next_block).await.unwrap();
|
|
|
|
|
|
|
|
|
|
assert!(
|
2021-02-10 23:29:49 +00:00
|
|
|
self.network_rx.recv().await.is_some(),
|
2020-09-29 03:46:54 +00:00
|
|
|
"valid blocks should be sent to network"
|
|
|
|
|
);
|
|
|
|
|
|
|
|
|
|
self
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
pub async fn test_post_beacon_blocks_invalid(mut self) -> Self {
|
|
|
|
|
let mut next_block = self.next_block.clone();
|
2021-07-09 06:15:32 +00:00
|
|
|
*next_block.message_mut().proposer_index_mut() += 1;
|
2020-09-29 03:46:54 +00:00
|
|
|
|
|
|
|
|
assert!(self.client.post_beacon_blocks(&next_block).await.is_err());
|
|
|
|
|
|
|
|
|
|
assert!(
|
2021-02-10 23:29:49 +00:00
|
|
|
self.network_rx.recv().await.is_some(),
|
2020-09-29 03:46:54 +00:00
|
|
|
"invalid blocks should be sent to network"
|
|
|
|
|
);
|
|
|
|
|
|
|
|
|
|
self
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
pub async fn test_beacon_blocks(self) -> Self {
|
|
|
|
|
for block_id in self.interesting_block_ids() {
|
Separate execution payloads in the DB (#3157)
## Proposed Changes
Reduce post-merge disk usage by not storing finalized execution payloads in Lighthouse's database.
:warning: **This is achieved in a backwards-incompatible way for networks that have already merged** :warning:. Kiln users and shadow fork enjoyers will be unable to downgrade after running the code from this PR. The upgrade migration may take several minutes to run, and can't be aborted after it begins.
The main changes are:
- New column in the database called `ExecPayload`, keyed by beacon block root.
- The `BeaconBlock` column now stores blinded blocks only.
- Lots of places that previously used full blocks now use blinded blocks, e.g. analytics APIs, block replay in the DB, etc.
- On finalization:
- `prune_abanonded_forks` deletes non-canonical payloads whilst deleting non-canonical blocks.
- `migrate_db` deletes finalized canonical payloads whilst deleting finalized states.
- Conversions between blinded and full blocks are implemented in a compositional way, duplicating some work from Sean's PR #3134.
- The execution layer has a new `get_payload_by_block_hash` method that reconstructs a payload using the EE's `eth_getBlockByHash` call.
- I've tested manually that it works on Kiln, using Geth and Nethermind.
- This isn't necessarily the most efficient method, and new engine APIs are being discussed to improve this: https://github.com/ethereum/execution-apis/pull/146.
- We're depending on the `ethers` master branch, due to lots of recent changes. We're also using a workaround for https://github.com/gakonst/ethers-rs/issues/1134.
- Payload reconstruction is used in the HTTP API via `BeaconChain::get_block`, which is now `async`. Due to the `async` fn, the `blocking_json` wrapper has been removed.
- Payload reconstruction is used in network RPC to serve blocks-by-{root,range} responses. Here the `async` adjustment is messier, although I think I've managed to come up with a reasonable compromise: the handlers take the `SendOnDrop` by value so that they can drop it on _task completion_ (after the `fn` returns). Still, this is introducing disk reads onto core executor threads, which may have a negative performance impact (thoughts appreciated).
## Additional Info
- [x] For performance it would be great to remove the cloning of full blocks when converting them to blinded blocks to write to disk. I'm going to experiment with a `put_block` API that takes the block by value, breaks it into a blinded block and a payload, stores the blinded block, and then re-assembles the full block for the caller.
- [x] We should measure the latency of blocks-by-root and blocks-by-range responses.
- [x] We should add integration tests that stress the payload reconstruction (basic tests done, issue for more extensive tests: https://github.com/sigp/lighthouse/issues/3159)
- [x] We should (manually) test the schema v9 migration from several prior versions, particularly as blocks have changed on disk and some migrations rely on being able to load blocks.
Co-authored-by: Paul Hauner <paul@paulhauner.com>
2022-05-12 00:42:17 +00:00
|
|
|
let expected = self.get_block(block_id).await;
|
2021-02-24 04:15:14 +00:00
|
|
|
|
2021-04-25 03:59:59 +00:00
|
|
|
if let BlockId::Slot(slot) = block_id {
|
|
|
|
|
if expected.is_none() {
|
|
|
|
|
assert!(SKIPPED_SLOTS.contains(&slot.as_u64()));
|
|
|
|
|
} else {
|
|
|
|
|
assert!(!SKIPPED_SLOTS.contains(&slot.as_u64()));
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
2021-10-28 01:18:04 +00:00
|
|
|
// Check the JSON endpoint.
|
2021-08-06 00:47:31 +00:00
|
|
|
let json_result = self.client.get_beacon_blocks(block_id).await.unwrap();
|
|
|
|
|
|
|
|
|
|
if let (Some(json), Some(expected)) = (&json_result, &expected) {
|
|
|
|
|
assert_eq!(json.data, *expected, "{:?}", block_id);
|
|
|
|
|
assert_eq!(
|
|
|
|
|
json.version,
|
|
|
|
|
Some(expected.fork_name(&self.chain.spec).unwrap())
|
|
|
|
|
);
|
|
|
|
|
} else {
|
|
|
|
|
assert_eq!(json_result, None);
|
|
|
|
|
assert_eq!(expected, None);
|
|
|
|
|
}
|
2020-09-29 03:46:54 +00:00
|
|
|
|
2021-10-28 01:18:04 +00:00
|
|
|
// Check the SSZ endpoint.
|
2021-07-09 06:15:32 +00:00
|
|
|
let ssz_result = self
|
|
|
|
|
.client
|
|
|
|
|
.get_beacon_blocks_ssz(block_id, &self.chain.spec)
|
|
|
|
|
.await
|
|
|
|
|
.unwrap();
|
2021-02-24 04:15:14 +00:00
|
|
|
assert_eq!(ssz_result, expected, "{:?}", block_id);
|
2021-08-06 00:47:31 +00:00
|
|
|
|
|
|
|
|
// Check that the legacy v1 API still works but doesn't return a version field.
|
|
|
|
|
let v1_result = self.client.get_beacon_blocks_v1(block_id).await.unwrap();
|
|
|
|
|
if let (Some(v1_result), Some(expected)) = (&v1_result, &expected) {
|
|
|
|
|
assert_eq!(v1_result.version, None);
|
|
|
|
|
assert_eq!(v1_result.data, *expected);
|
|
|
|
|
} else {
|
|
|
|
|
assert_eq!(v1_result, None);
|
|
|
|
|
assert_eq!(expected, None);
|
|
|
|
|
}
|
2021-10-28 01:18:04 +00:00
|
|
|
|
|
|
|
|
// Check that version headers are provided.
|
|
|
|
|
let url = self.client.get_beacon_blocks_path(block_id).unwrap();
|
|
|
|
|
|
|
|
|
|
let builders: Vec<fn(RequestBuilder) -> RequestBuilder> = vec![
|
|
|
|
|
|b| b,
|
|
|
|
|
|b| b.accept(Accept::Ssz),
|
|
|
|
|
|b| b.accept(Accept::Json),
|
|
|
|
|
|b| b.accept(Accept::Any),
|
|
|
|
|
];
|
|
|
|
|
|
|
|
|
|
for req_builder in builders {
|
|
|
|
|
let raw_res = self
|
|
|
|
|
.client
|
|
|
|
|
.get_response(url.clone(), req_builder)
|
|
|
|
|
.await
|
|
|
|
|
.optional()
|
|
|
|
|
.unwrap();
|
|
|
|
|
if let (Some(raw_res), Some(expected)) = (&raw_res, &expected) {
|
|
|
|
|
assert_eq!(
|
|
|
|
|
raw_res.fork_name_from_header().unwrap(),
|
|
|
|
|
Some(expected.fork_name(&self.chain.spec).unwrap())
|
|
|
|
|
);
|
|
|
|
|
} else {
|
|
|
|
|
assert!(raw_res.is_none());
|
|
|
|
|
assert_eq!(expected, None);
|
|
|
|
|
}
|
|
|
|
|
}
|
2020-09-29 03:46:54 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
self
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
pub async fn test_beacon_blocks_attestations(self) -> Self {
|
|
|
|
|
for block_id in self.interesting_block_ids() {
|
|
|
|
|
let result = self
|
|
|
|
|
.client
|
|
|
|
|
.get_beacon_blocks_attestations(block_id)
|
|
|
|
|
.await
|
|
|
|
|
.unwrap()
|
|
|
|
|
.map(|res| res.data);
|
|
|
|
|
|
|
|
|
|
let expected = self
|
|
|
|
|
.get_block(block_id)
|
Separate execution payloads in the DB (#3157)
## Proposed Changes
Reduce post-merge disk usage by not storing finalized execution payloads in Lighthouse's database.
:warning: **This is achieved in a backwards-incompatible way for networks that have already merged** :warning:. Kiln users and shadow fork enjoyers will be unable to downgrade after running the code from this PR. The upgrade migration may take several minutes to run, and can't be aborted after it begins.
The main changes are:
- New column in the database called `ExecPayload`, keyed by beacon block root.
- The `BeaconBlock` column now stores blinded blocks only.
- Lots of places that previously used full blocks now use blinded blocks, e.g. analytics APIs, block replay in the DB, etc.
- On finalization:
- `prune_abanonded_forks` deletes non-canonical payloads whilst deleting non-canonical blocks.
- `migrate_db` deletes finalized canonical payloads whilst deleting finalized states.
- Conversions between blinded and full blocks are implemented in a compositional way, duplicating some work from Sean's PR #3134.
- The execution layer has a new `get_payload_by_block_hash` method that reconstructs a payload using the EE's `eth_getBlockByHash` call.
- I've tested manually that it works on Kiln, using Geth and Nethermind.
- This isn't necessarily the most efficient method, and new engine APIs are being discussed to improve this: https://github.com/ethereum/execution-apis/pull/146.
- We're depending on the `ethers` master branch, due to lots of recent changes. We're also using a workaround for https://github.com/gakonst/ethers-rs/issues/1134.
- Payload reconstruction is used in the HTTP API via `BeaconChain::get_block`, which is now `async`. Due to the `async` fn, the `blocking_json` wrapper has been removed.
- Payload reconstruction is used in network RPC to serve blocks-by-{root,range} responses. Here the `async` adjustment is messier, although I think I've managed to come up with a reasonable compromise: the handlers take the `SendOnDrop` by value so that they can drop it on _task completion_ (after the `fn` returns). Still, this is introducing disk reads onto core executor threads, which may have a negative performance impact (thoughts appreciated).
## Additional Info
- [x] For performance it would be great to remove the cloning of full blocks when converting them to blinded blocks to write to disk. I'm going to experiment with a `put_block` API that takes the block by value, breaks it into a blinded block and a payload, stores the blinded block, and then re-assembles the full block for the caller.
- [x] We should measure the latency of blocks-by-root and blocks-by-range responses.
- [x] We should add integration tests that stress the payload reconstruction (basic tests done, issue for more extensive tests: https://github.com/sigp/lighthouse/issues/3159)
- [x] We should (manually) test the schema v9 migration from several prior versions, particularly as blocks have changed on disk and some migrations rely on being able to load blocks.
Co-authored-by: Paul Hauner <paul@paulhauner.com>
2022-05-12 00:42:17 +00:00
|
|
|
.await
|
2021-07-09 06:15:32 +00:00
|
|
|
.map(|block| block.message().body().attestations().clone().into());
|
2020-09-29 03:46:54 +00:00
|
|
|
|
2021-04-25 03:59:59 +00:00
|
|
|
if let BlockId::Slot(slot) = block_id {
|
|
|
|
|
if expected.is_none() {
|
|
|
|
|
assert!(SKIPPED_SLOTS.contains(&slot.as_u64()));
|
|
|
|
|
} else {
|
|
|
|
|
assert!(!SKIPPED_SLOTS.contains(&slot.as_u64()));
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
2020-09-29 03:46:54 +00:00
|
|
|
assert_eq!(result, expected, "{:?}", block_id);
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
self
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
pub async fn test_post_beacon_pool_attestations_valid(mut self) -> Self {
|
2020-11-18 23:31:39 +00:00
|
|
|
self.client
|
|
|
|
|
.post_beacon_pool_attestations(self.attestations.as_slice())
|
|
|
|
|
.await
|
|
|
|
|
.unwrap();
|
2020-09-29 03:46:54 +00:00
|
|
|
|
2020-11-18 23:31:39 +00:00
|
|
|
assert!(
|
2021-02-10 23:29:49 +00:00
|
|
|
self.network_rx.recv().await.is_some(),
|
2020-11-18 23:31:39 +00:00
|
|
|
"valid attestation should be sent to network"
|
|
|
|
|
);
|
2020-09-29 03:46:54 +00:00
|
|
|
|
|
|
|
|
self
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
pub async fn test_post_beacon_pool_attestations_invalid(mut self) -> Self {
|
2020-11-18 23:31:39 +00:00
|
|
|
let mut attestations = Vec::new();
|
2020-09-29 03:46:54 +00:00
|
|
|
for attestation in &self.attestations {
|
2020-11-18 23:31:39 +00:00
|
|
|
let mut invalid_attestation = attestation.clone();
|
|
|
|
|
invalid_attestation.data.slot += 1;
|
2020-09-29 03:46:54 +00:00
|
|
|
|
2020-11-18 23:31:39 +00:00
|
|
|
// add both to ensure we only fail on invalid attestations
|
|
|
|
|
attestations.push(attestation.clone());
|
|
|
|
|
attestations.push(invalid_attestation);
|
|
|
|
|
}
|
2020-09-29 03:46:54 +00:00
|
|
|
|
2020-11-18 23:31:39 +00:00
|
|
|
let err = self
|
|
|
|
|
.client
|
|
|
|
|
.post_beacon_pool_attestations(attestations.as_slice())
|
|
|
|
|
.await
|
|
|
|
|
.unwrap_err();
|
|
|
|
|
|
|
|
|
|
match err {
|
|
|
|
|
Error::ServerIndexedMessage(IndexedErrorMessage {
|
|
|
|
|
code,
|
|
|
|
|
message: _,
|
|
|
|
|
failures,
|
|
|
|
|
}) => {
|
|
|
|
|
assert_eq!(code, 400);
|
|
|
|
|
assert_eq!(failures.len(), self.attestations.len());
|
|
|
|
|
}
|
|
|
|
|
_ => panic!("query did not fail correctly"),
|
2020-09-29 03:46:54 +00:00
|
|
|
}
|
|
|
|
|
|
2020-11-18 23:31:39 +00:00
|
|
|
assert!(
|
2021-02-10 23:29:49 +00:00
|
|
|
self.network_rx.recv().await.is_some(),
|
2020-11-18 23:31:39 +00:00
|
|
|
"if some attestations are valid, we should send them to the network"
|
|
|
|
|
);
|
|
|
|
|
|
2020-09-29 03:46:54 +00:00
|
|
|
self
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
pub async fn test_get_beacon_pool_attestations(self) -> Self {
|
|
|
|
|
let result = self
|
|
|
|
|
.client
|
2020-11-18 23:31:39 +00:00
|
|
|
.get_beacon_pool_attestations(None, None)
|
2020-09-29 03:46:54 +00:00
|
|
|
.await
|
|
|
|
|
.unwrap()
|
|
|
|
|
.data;
|
|
|
|
|
|
|
|
|
|
let mut expected = self.chain.op_pool.get_all_attestations();
|
|
|
|
|
expected.extend(self.chain.naive_aggregation_pool.read().iter().cloned());
|
|
|
|
|
|
|
|
|
|
assert_eq!(result, expected);
|
|
|
|
|
|
|
|
|
|
self
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
pub async fn test_post_beacon_pool_attester_slashings_valid(mut self) -> Self {
|
|
|
|
|
self.client
|
|
|
|
|
.post_beacon_pool_attester_slashings(&self.attester_slashing)
|
|
|
|
|
.await
|
|
|
|
|
.unwrap();
|
|
|
|
|
|
|
|
|
|
assert!(
|
2021-02-10 23:29:49 +00:00
|
|
|
self.network_rx.recv().await.is_some(),
|
2020-09-29 03:46:54 +00:00
|
|
|
"valid attester slashing should be sent to network"
|
|
|
|
|
);
|
|
|
|
|
|
|
|
|
|
self
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
pub async fn test_post_beacon_pool_attester_slashings_invalid(mut self) -> Self {
|
|
|
|
|
let mut slashing = self.attester_slashing.clone();
|
|
|
|
|
slashing.attestation_1.data.slot += 1;
|
|
|
|
|
|
|
|
|
|
self.client
|
|
|
|
|
.post_beacon_pool_attester_slashings(&slashing)
|
|
|
|
|
.await
|
|
|
|
|
.unwrap_err();
|
|
|
|
|
|
|
|
|
|
assert!(
|
2021-02-10 23:29:49 +00:00
|
|
|
self.network_rx.recv().now_or_never().is_none(),
|
2020-09-29 03:46:54 +00:00
|
|
|
"invalid attester slashing should not be sent to network"
|
|
|
|
|
);
|
|
|
|
|
|
|
|
|
|
self
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
pub async fn test_get_beacon_pool_attester_slashings(self) -> Self {
|
|
|
|
|
let result = self
|
|
|
|
|
.client
|
|
|
|
|
.get_beacon_pool_attester_slashings()
|
|
|
|
|
.await
|
|
|
|
|
.unwrap()
|
|
|
|
|
.data;
|
|
|
|
|
|
|
|
|
|
let expected = self.chain.op_pool.get_all_attester_slashings();
|
|
|
|
|
|
|
|
|
|
assert_eq!(result, expected);
|
|
|
|
|
|
|
|
|
|
self
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
pub async fn test_post_beacon_pool_proposer_slashings_valid(mut self) -> Self {
|
|
|
|
|
self.client
|
|
|
|
|
.post_beacon_pool_proposer_slashings(&self.proposer_slashing)
|
|
|
|
|
.await
|
|
|
|
|
.unwrap();
|
|
|
|
|
|
|
|
|
|
assert!(
|
2021-02-10 23:29:49 +00:00
|
|
|
self.network_rx.recv().await.is_some(),
|
2020-09-29 03:46:54 +00:00
|
|
|
"valid proposer slashing should be sent to network"
|
|
|
|
|
);
|
|
|
|
|
|
|
|
|
|
self
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
pub async fn test_post_beacon_pool_proposer_slashings_invalid(mut self) -> Self {
|
|
|
|
|
let mut slashing = self.proposer_slashing.clone();
|
|
|
|
|
slashing.signed_header_1.message.slot += 1;
|
|
|
|
|
|
|
|
|
|
self.client
|
|
|
|
|
.post_beacon_pool_proposer_slashings(&slashing)
|
|
|
|
|
.await
|
|
|
|
|
.unwrap_err();
|
|
|
|
|
|
|
|
|
|
assert!(
|
2021-02-10 23:29:49 +00:00
|
|
|
self.network_rx.recv().now_or_never().is_none(),
|
2020-09-29 03:46:54 +00:00
|
|
|
"invalid proposer slashing should not be sent to network"
|
|
|
|
|
);
|
|
|
|
|
|
|
|
|
|
self
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
pub async fn test_get_beacon_pool_proposer_slashings(self) -> Self {
|
|
|
|
|
let result = self
|
|
|
|
|
.client
|
|
|
|
|
.get_beacon_pool_proposer_slashings()
|
|
|
|
|
.await
|
|
|
|
|
.unwrap()
|
|
|
|
|
.data;
|
|
|
|
|
|
|
|
|
|
let expected = self.chain.op_pool.get_all_proposer_slashings();
|
|
|
|
|
|
|
|
|
|
assert_eq!(result, expected);
|
|
|
|
|
|
|
|
|
|
self
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
pub async fn test_post_beacon_pool_voluntary_exits_valid(mut self) -> Self {
|
|
|
|
|
self.client
|
|
|
|
|
.post_beacon_pool_voluntary_exits(&self.voluntary_exit)
|
|
|
|
|
.await
|
|
|
|
|
.unwrap();
|
|
|
|
|
|
|
|
|
|
assert!(
|
2021-02-10 23:29:49 +00:00
|
|
|
self.network_rx.recv().await.is_some(),
|
2020-09-29 03:46:54 +00:00
|
|
|
"valid exit should be sent to network"
|
|
|
|
|
);
|
|
|
|
|
|
|
|
|
|
self
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
pub async fn test_post_beacon_pool_voluntary_exits_invalid(mut self) -> Self {
|
|
|
|
|
let mut exit = self.voluntary_exit.clone();
|
|
|
|
|
exit.message.epoch += 1;
|
|
|
|
|
|
|
|
|
|
self.client
|
|
|
|
|
.post_beacon_pool_voluntary_exits(&exit)
|
|
|
|
|
.await
|
|
|
|
|
.unwrap_err();
|
|
|
|
|
|
|
|
|
|
assert!(
|
2021-02-10 23:29:49 +00:00
|
|
|
self.network_rx.recv().now_or_never().is_none(),
|
2020-09-29 03:46:54 +00:00
|
|
|
"invalid exit should not be sent to network"
|
|
|
|
|
);
|
|
|
|
|
|
|
|
|
|
self
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
pub async fn test_get_beacon_pool_voluntary_exits(self) -> Self {
|
|
|
|
|
let result = self
|
|
|
|
|
.client
|
|
|
|
|
.get_beacon_pool_voluntary_exits()
|
|
|
|
|
.await
|
|
|
|
|
.unwrap()
|
|
|
|
|
.data;
|
|
|
|
|
|
|
|
|
|
let expected = self.chain.op_pool.get_all_voluntary_exits();
|
|
|
|
|
|
|
|
|
|
assert_eq!(result, expected);
|
|
|
|
|
|
|
|
|
|
self
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
pub async fn test_get_config_fork_schedule(self) -> Self {
|
|
|
|
|
let result = self.client.get_config_fork_schedule().await.unwrap().data;
|
|
|
|
|
|
2021-08-24 01:36:27 +00:00
|
|
|
let expected: Vec<Fork> = ForkName::list_all()
|
|
|
|
|
.into_iter()
|
|
|
|
|
.filter_map(|fork| self.chain.spec.fork_for_name(fork))
|
|
|
|
|
.collect();
|
2020-09-29 03:46:54 +00:00
|
|
|
|
|
|
|
|
assert_eq!(result, expected);
|
|
|
|
|
|
|
|
|
|
self
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
pub async fn test_get_config_spec(self) -> Self {
|
|
|
|
|
let result = self.client.get_config_spec().await.unwrap().data;
|
|
|
|
|
|
2021-07-09 06:15:32 +00:00
|
|
|
let mut expected = ConfigAndPreset::from_chain_spec::<E>(&self.chain.spec);
|
|
|
|
|
expected.make_backwards_compat(&self.chain.spec);
|
2020-09-29 03:46:54 +00:00
|
|
|
|
|
|
|
|
assert_eq!(result, expected);
|
|
|
|
|
|
|
|
|
|
self
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
pub async fn test_get_config_deposit_contract(self) -> Self {
|
|
|
|
|
let result = self
|
|
|
|
|
.client
|
|
|
|
|
.get_config_deposit_contract()
|
|
|
|
|
.await
|
|
|
|
|
.unwrap()
|
|
|
|
|
.data;
|
|
|
|
|
|
|
|
|
|
let expected = DepositContractData {
|
|
|
|
|
address: self.chain.spec.deposit_contract_address,
|
2021-10-01 06:32:38 +00:00
|
|
|
chain_id: self.chain.spec.deposit_chain_id,
|
2020-09-29 03:46:54 +00:00
|
|
|
};
|
|
|
|
|
|
|
|
|
|
assert_eq!(result, expected);
|
|
|
|
|
|
|
|
|
|
self
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
pub async fn test_get_node_version(self) -> Self {
|
|
|
|
|
let result = self.client.get_node_version().await.unwrap().data;
|
|
|
|
|
|
|
|
|
|
let expected = VersionData {
|
|
|
|
|
version: lighthouse_version::version_with_platform(),
|
|
|
|
|
};
|
|
|
|
|
|
|
|
|
|
assert_eq!(result, expected);
|
|
|
|
|
|
|
|
|
|
self
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
pub async fn test_get_node_syncing(self) -> Self {
|
|
|
|
|
let result = self.client.get_node_syncing().await.unwrap().data;
|
Use async code when interacting with EL (#3244)
## Overview
This rather extensive PR achieves two primary goals:
1. Uses the finalized/justified checkpoints of fork choice (FC), rather than that of the head state.
2. Refactors fork choice, block production and block processing to `async` functions.
Additionally, it achieves:
- Concurrent forkchoice updates to the EL and cache pruning after a new head is selected.
- Concurrent "block packing" (attestations, etc) and execution payload retrieval during block production.
- Concurrent per-block-processing and execution payload verification during block processing.
- The `Arc`-ification of `SignedBeaconBlock` during block processing (it's never mutated, so why not?):
- I had to do this to deal with sending blocks into spawned tasks.
- Previously we were cloning the beacon block at least 2 times during each block processing, these clones are either removed or turned into cheaper `Arc` clones.
- We were also `Box`-ing and un-`Box`-ing beacon blocks as they moved throughout the networking crate. This is not a big deal, but it's nice to avoid shifting things between the stack and heap.
- Avoids cloning *all the blocks* in *every chain segment* during sync.
- It also has the potential to clean up our code where we need to pass an *owned* block around so we can send it back in the case of an error (I didn't do much of this, my PR is already big enough :sweat_smile:)
- The `BeaconChain::HeadSafetyStatus` struct was removed. It was an old relic from prior merge specs.
For motivation for this change, see https://github.com/sigp/lighthouse/pull/3244#issuecomment-1160963273
## Changes to `canonical_head` and `fork_choice`
Previously, the `BeaconChain` had two separate fields:
```
canonical_head: RwLock<Snapshot>,
fork_choice: RwLock<BeaconForkChoice>
```
Now, we have grouped these values under a single struct:
```
canonical_head: CanonicalHead {
cached_head: RwLock<Arc<Snapshot>>,
fork_choice: RwLock<BeaconForkChoice>
}
```
Apart from ergonomics, the only *actual* change here is wrapping the canonical head snapshot in an `Arc`. This means that we no longer need to hold the `cached_head` (`canonical_head`, in old terms) lock when we want to pull some values from it. This was done to avoid deadlock risks by preventing functions from acquiring (and holding) the `cached_head` and `fork_choice` locks simultaneously.
## Breaking Changes
### The `state` (root) field in the `finalized_checkpoint` SSE event
Consider the scenario where epoch `n` is just finalized, but `start_slot(n)` is skipped. There are two state roots we might in the `finalized_checkpoint` SSE event:
1. The state root of the finalized block, which is `get_block(finalized_checkpoint.root).state_root`.
4. The state root at slot of `start_slot(n)`, which would be the state from (1), but "skipped forward" through any skip slots.
Previously, Lighthouse would choose (2). However, we can see that when [Teku generates that event](https://github.com/ConsenSys/teku/blob/de2b2801c89ef5abf983d6bf37867c37fc47121f/data/beaconrestapi/src/main/java/tech/pegasys/teku/beaconrestapi/handlers/v1/events/EventSubscriptionManager.java#L171-L182) it uses [`getStateRootFromBlockRoot`](https://github.com/ConsenSys/teku/blob/de2b2801c89ef5abf983d6bf37867c37fc47121f/data/provider/src/main/java/tech/pegasys/teku/api/ChainDataProvider.java#L336-L341) which uses (1).
I have switched Lighthouse from (2) to (1). I think it's a somewhat arbitrary choice between the two, where (1) is easier to compute and is consistent with Teku.
## Notes for Reviewers
I've renamed `BeaconChain::fork_choice` to `BeaconChain::recompute_head`. Doing this helped ensure I broke all previous uses of fork choice and I also find it more descriptive. It describes an action and can't be confused with trying to get a reference to the `ForkChoice` struct.
I've changed the ordering of SSE events when a block is received. It used to be `[block, finalized, head]` and now it's `[block, head, finalized]`. It was easier this way and I don't think we were making any promises about SSE event ordering so it's not "breaking".
I've made it so fork choice will run when it's first constructed. I did this because I wanted to have a cached version of the last call to `get_head`. Ensuring `get_head` has been run *at least once* means that the cached values doesn't need to wrapped in an `Option`. This was fairly simple, it just involved passing a `slot` to the constructor so it knows *when* it's being run. When loading a fork choice from the store and a slot clock isn't handy I've just used the `slot` that was saved in the `fork_choice_store`. That seems like it would be a faithful representation of the slot when we saved it.
I added the `genesis_time: u64` to the `BeaconChain`. It's small, constant and nice to have around.
Since we're using FC for the fin/just checkpoints, we no longer get the `0x00..00` roots at genesis. You can see I had to remove a work-around in `ef-tests` here: b56be3bc2. I can't find any reason why this would be an issue, if anything I think it'll be better since the genesis-alias has caught us out a few times (0x00..00 isn't actually a real root). Edit: I did find a case where the `network` expected the 0x00..00 alias and patched it here: 3f26ac3e2.
You'll notice a lot of changes in tests. Generally, tests should be functionally equivalent. Here are the things creating the most diff-noise in tests:
- Changing tests to be `tokio::async` tests.
- Adding `.await` to fork choice, block processing and block production functions.
- Refactor of the `canonical_head` "API" provided by the `BeaconChain`. E.g., `chain.canonical_head.cached_head()` instead of `chain.canonical_head.read()`.
- Wrapping `SignedBeaconBlock` in an `Arc`.
- In the `beacon_chain/tests/block_verification`, we can't use the `lazy_static` `CHAIN_SEGMENT` variable anymore since it's generated with an async function. We just generate it in each test, not so efficient but hopefully insignificant.
I had to disable `rayon` concurrent tests in the `fork_choice` tests. This is because the use of `rayon` and `block_on` was causing a panic.
Co-authored-by: Mac L <mjladson@pm.me>
2022-07-03 05:36:50 +00:00
|
|
|
let head_slot = self.chain.canonical_head.cached_head().head_slot();
|
2020-09-29 03:46:54 +00:00
|
|
|
let sync_distance = self.chain.slot().unwrap() - head_slot;
|
|
|
|
|
|
|
|
|
|
let expected = SyncingData {
|
|
|
|
|
is_syncing: false,
|
|
|
|
|
head_slot,
|
|
|
|
|
sync_distance,
|
|
|
|
|
};
|
|
|
|
|
|
|
|
|
|
assert_eq!(result, expected);
|
|
|
|
|
|
|
|
|
|
self
|
|
|
|
|
}
|
|
|
|
|
|
2020-10-22 02:59:42 +00:00
|
|
|
pub async fn test_get_node_identity(self) -> Self {
|
|
|
|
|
let result = self.client.get_node_identity().await.unwrap().data;
|
|
|
|
|
|
|
|
|
|
let expected = IdentityData {
|
|
|
|
|
peer_id: self.local_enr.peer_id().to_string(),
|
|
|
|
|
enr: self.local_enr.clone(),
|
|
|
|
|
p2p_addresses: self.local_enr.multiaddr_p2p_tcp(),
|
|
|
|
|
discovery_addresses: self.local_enr.multiaddr_p2p_udp(),
|
|
|
|
|
metadata: eth2::types::MetaData {
|
|
|
|
|
seq_number: 0,
|
|
|
|
|
attnets: "0x0000000000000000".to_string(),
|
2021-08-04 01:44:57 +00:00
|
|
|
syncnets: "0x00".to_string(),
|
2020-10-22 02:59:42 +00:00
|
|
|
},
|
|
|
|
|
};
|
|
|
|
|
|
|
|
|
|
assert_eq!(result, expected);
|
|
|
|
|
|
|
|
|
|
self
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
pub async fn test_get_node_health(self) -> Self {
|
|
|
|
|
let status = self.client.get_node_health().await.unwrap();
|
|
|
|
|
assert_eq!(status, StatusCode::OK);
|
|
|
|
|
|
|
|
|
|
self
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
pub async fn test_get_node_peers_by_id(self) -> Self {
|
|
|
|
|
let result = self
|
|
|
|
|
.client
|
|
|
|
|
.get_node_peers_by_id(self.external_peer_id.clone())
|
|
|
|
|
.await
|
|
|
|
|
.unwrap()
|
|
|
|
|
.data;
|
|
|
|
|
|
|
|
|
|
let expected = PeerData {
|
|
|
|
|
peer_id: self.external_peer_id.to_string(),
|
|
|
|
|
enr: None,
|
2020-11-13 02:02:41 +00:00
|
|
|
last_seen_p2p_address: EXTERNAL_ADDR.to_string(),
|
2020-10-22 02:59:42 +00:00
|
|
|
state: PeerState::Connected,
|
|
|
|
|
direction: PeerDirection::Inbound,
|
|
|
|
|
};
|
|
|
|
|
|
|
|
|
|
assert_eq!(result, expected);
|
|
|
|
|
|
|
|
|
|
self
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
pub async fn test_get_node_peers(self) -> Self {
|
2020-11-13 02:02:41 +00:00
|
|
|
let peer_states: Vec<Option<&[PeerState]>> = vec![
|
|
|
|
|
Some(&[PeerState::Connected]),
|
|
|
|
|
Some(&[PeerState::Connecting]),
|
|
|
|
|
Some(&[PeerState::Disconnected]),
|
|
|
|
|
Some(&[PeerState::Disconnecting]),
|
|
|
|
|
None,
|
|
|
|
|
Some(&[PeerState::Connected, PeerState::Connecting]),
|
|
|
|
|
];
|
|
|
|
|
let peer_dirs: Vec<Option<&[PeerDirection]>> = vec![
|
|
|
|
|
Some(&[PeerDirection::Outbound]),
|
|
|
|
|
Some(&[PeerDirection::Inbound]),
|
|
|
|
|
Some(&[PeerDirection::Inbound, PeerDirection::Outbound]),
|
|
|
|
|
None,
|
|
|
|
|
];
|
2020-10-22 02:59:42 +00:00
|
|
|
|
2020-11-13 02:02:41 +00:00
|
|
|
for states in peer_states {
|
|
|
|
|
for dirs in peer_dirs.clone() {
|
|
|
|
|
let result = self.client.get_node_peers(states, dirs).await.unwrap();
|
|
|
|
|
let expected_peer = PeerData {
|
|
|
|
|
peer_id: self.external_peer_id.to_string(),
|
|
|
|
|
enr: None,
|
|
|
|
|
last_seen_p2p_address: EXTERNAL_ADDR.to_string(),
|
|
|
|
|
state: PeerState::Connected,
|
|
|
|
|
direction: PeerDirection::Inbound,
|
|
|
|
|
};
|
|
|
|
|
|
|
|
|
|
let state_match =
|
|
|
|
|
states.map_or(true, |states| states.contains(&PeerState::Connected));
|
|
|
|
|
let dir_match = dirs.map_or(true, |dirs| dirs.contains(&PeerDirection::Inbound));
|
2020-10-22 02:59:42 +00:00
|
|
|
|
2020-11-13 02:02:41 +00:00
|
|
|
let mut expected_peers = Vec::new();
|
|
|
|
|
if state_match && dir_match {
|
|
|
|
|
expected_peers.push(expected_peer);
|
|
|
|
|
}
|
2020-10-22 02:59:42 +00:00
|
|
|
|
2020-11-13 02:02:41 +00:00
|
|
|
assert_eq!(
|
|
|
|
|
result,
|
|
|
|
|
PeersData {
|
|
|
|
|
meta: PeersMetaData {
|
|
|
|
|
count: expected_peers.len() as u64
|
|
|
|
|
},
|
|
|
|
|
data: expected_peers,
|
|
|
|
|
}
|
|
|
|
|
);
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
self
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
pub async fn test_get_node_peer_count(self) -> Self {
|
|
|
|
|
let result = self.client.get_node_peer_count().await.unwrap().data;
|
|
|
|
|
assert_eq!(
|
|
|
|
|
result,
|
|
|
|
|
PeerCount {
|
|
|
|
|
connected: 1,
|
|
|
|
|
connecting: 0,
|
|
|
|
|
disconnected: 0,
|
|
|
|
|
disconnecting: 0,
|
|
|
|
|
}
|
|
|
|
|
);
|
2020-10-22 02:59:42 +00:00
|
|
|
self
|
|
|
|
|
}
|
|
|
|
|
|
2020-09-29 03:46:54 +00:00
|
|
|
pub async fn test_get_debug_beacon_states(self) -> Self {
|
|
|
|
|
for state_id in self.interesting_state_ids() {
|
2021-08-06 00:47:31 +00:00
|
|
|
let result_json = self.client.get_debug_beacon_states(state_id).await.unwrap();
|
|
|
|
|
|
|
|
|
|
let mut expected = self.get_state(state_id);
|
|
|
|
|
expected.as_mut().map(|state| state.drop_all_caches());
|
|
|
|
|
|
|
|
|
|
if let (Some(json), Some(expected)) = (&result_json, &expected) {
|
|
|
|
|
assert_eq!(json.data, *expected, "{:?}", state_id);
|
|
|
|
|
assert_eq!(
|
|
|
|
|
json.version,
|
|
|
|
|
Some(expected.fork_name(&self.chain.spec).unwrap())
|
|
|
|
|
);
|
|
|
|
|
} else {
|
|
|
|
|
assert_eq!(result_json, None);
|
|
|
|
|
assert_eq!(expected, None);
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
// Check SSZ API.
|
2021-01-06 03:01:46 +00:00
|
|
|
let result_ssz = self
|
|
|
|
|
.client
|
2021-07-09 06:15:32 +00:00
|
|
|
.get_debug_beacon_states_ssz(state_id, &self.chain.spec)
|
2021-01-06 03:01:46 +00:00
|
|
|
.await
|
|
|
|
|
.unwrap();
|
2021-08-06 00:47:31 +00:00
|
|
|
assert_eq!(result_ssz, expected, "{:?}", state_id);
|
|
|
|
|
|
|
|
|
|
// Check legacy v1 API.
|
|
|
|
|
let result_v1 = self
|
2020-09-29 03:46:54 +00:00
|
|
|
.client
|
2021-08-06 00:47:31 +00:00
|
|
|
.get_debug_beacon_states_v1(state_id)
|
2020-09-29 03:46:54 +00:00
|
|
|
.await
|
2021-08-06 00:47:31 +00:00
|
|
|
.unwrap();
|
2020-09-29 03:46:54 +00:00
|
|
|
|
2021-08-06 00:47:31 +00:00
|
|
|
if let (Some(json), Some(expected)) = (&result_v1, &expected) {
|
|
|
|
|
assert_eq!(json.version, None);
|
|
|
|
|
assert_eq!(json.data, *expected, "{:?}", state_id);
|
|
|
|
|
} else {
|
|
|
|
|
assert_eq!(result_v1, None);
|
|
|
|
|
assert_eq!(expected, None);
|
|
|
|
|
}
|
2021-10-28 01:18:04 +00:00
|
|
|
|
|
|
|
|
// Check that version headers are provided.
|
|
|
|
|
let url = self.client.get_debug_beacon_states_path(state_id).unwrap();
|
|
|
|
|
|
|
|
|
|
let builders: Vec<fn(RequestBuilder) -> RequestBuilder> =
|
|
|
|
|
vec![|b| b, |b| b.accept(Accept::Ssz)];
|
|
|
|
|
|
|
|
|
|
for req_builder in builders {
|
|
|
|
|
let raw_res = self
|
|
|
|
|
.client
|
|
|
|
|
.get_response(url.clone(), req_builder)
|
|
|
|
|
.await
|
|
|
|
|
.optional()
|
|
|
|
|
.unwrap();
|
|
|
|
|
if let (Some(raw_res), Some(expected)) = (&raw_res, &expected) {
|
|
|
|
|
assert_eq!(
|
|
|
|
|
raw_res.fork_name_from_header().unwrap(),
|
|
|
|
|
Some(expected.fork_name(&self.chain.spec).unwrap())
|
|
|
|
|
);
|
|
|
|
|
} else {
|
|
|
|
|
assert!(raw_res.is_none());
|
|
|
|
|
assert_eq!(expected, None);
|
|
|
|
|
}
|
|
|
|
|
}
|
2020-09-29 03:46:54 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
self
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
pub async fn test_get_debug_beacon_heads(self) -> Self {
|
|
|
|
|
let result = self
|
|
|
|
|
.client
|
|
|
|
|
.get_debug_beacon_heads()
|
|
|
|
|
.await
|
|
|
|
|
.unwrap()
|
|
|
|
|
.data
|
|
|
|
|
.into_iter()
|
|
|
|
|
.map(|head| (head.root, head.slot))
|
|
|
|
|
.collect::<Vec<_>>();
|
|
|
|
|
|
|
|
|
|
let expected = self.chain.heads();
|
|
|
|
|
|
|
|
|
|
assert_eq!(result, expected);
|
|
|
|
|
|
|
|
|
|
self
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
fn validator_count(&self) -> usize {
|
Use async code when interacting with EL (#3244)
## Overview
This rather extensive PR achieves two primary goals:
1. Uses the finalized/justified checkpoints of fork choice (FC), rather than that of the head state.
2. Refactors fork choice, block production and block processing to `async` functions.
Additionally, it achieves:
- Concurrent forkchoice updates to the EL and cache pruning after a new head is selected.
- Concurrent "block packing" (attestations, etc) and execution payload retrieval during block production.
- Concurrent per-block-processing and execution payload verification during block processing.
- The `Arc`-ification of `SignedBeaconBlock` during block processing (it's never mutated, so why not?):
- I had to do this to deal with sending blocks into spawned tasks.
- Previously we were cloning the beacon block at least 2 times during each block processing, these clones are either removed or turned into cheaper `Arc` clones.
- We were also `Box`-ing and un-`Box`-ing beacon blocks as they moved throughout the networking crate. This is not a big deal, but it's nice to avoid shifting things between the stack and heap.
- Avoids cloning *all the blocks* in *every chain segment* during sync.
- It also has the potential to clean up our code where we need to pass an *owned* block around so we can send it back in the case of an error (I didn't do much of this, my PR is already big enough :sweat_smile:)
- The `BeaconChain::HeadSafetyStatus` struct was removed. It was an old relic from prior merge specs.
For motivation for this change, see https://github.com/sigp/lighthouse/pull/3244#issuecomment-1160963273
## Changes to `canonical_head` and `fork_choice`
Previously, the `BeaconChain` had two separate fields:
```
canonical_head: RwLock<Snapshot>,
fork_choice: RwLock<BeaconForkChoice>
```
Now, we have grouped these values under a single struct:
```
canonical_head: CanonicalHead {
cached_head: RwLock<Arc<Snapshot>>,
fork_choice: RwLock<BeaconForkChoice>
}
```
Apart from ergonomics, the only *actual* change here is wrapping the canonical head snapshot in an `Arc`. This means that we no longer need to hold the `cached_head` (`canonical_head`, in old terms) lock when we want to pull some values from it. This was done to avoid deadlock risks by preventing functions from acquiring (and holding) the `cached_head` and `fork_choice` locks simultaneously.
## Breaking Changes
### The `state` (root) field in the `finalized_checkpoint` SSE event
Consider the scenario where epoch `n` is just finalized, but `start_slot(n)` is skipped. There are two state roots we might in the `finalized_checkpoint` SSE event:
1. The state root of the finalized block, which is `get_block(finalized_checkpoint.root).state_root`.
4. The state root at slot of `start_slot(n)`, which would be the state from (1), but "skipped forward" through any skip slots.
Previously, Lighthouse would choose (2). However, we can see that when [Teku generates that event](https://github.com/ConsenSys/teku/blob/de2b2801c89ef5abf983d6bf37867c37fc47121f/data/beaconrestapi/src/main/java/tech/pegasys/teku/beaconrestapi/handlers/v1/events/EventSubscriptionManager.java#L171-L182) it uses [`getStateRootFromBlockRoot`](https://github.com/ConsenSys/teku/blob/de2b2801c89ef5abf983d6bf37867c37fc47121f/data/provider/src/main/java/tech/pegasys/teku/api/ChainDataProvider.java#L336-L341) which uses (1).
I have switched Lighthouse from (2) to (1). I think it's a somewhat arbitrary choice between the two, where (1) is easier to compute and is consistent with Teku.
## Notes for Reviewers
I've renamed `BeaconChain::fork_choice` to `BeaconChain::recompute_head`. Doing this helped ensure I broke all previous uses of fork choice and I also find it more descriptive. It describes an action and can't be confused with trying to get a reference to the `ForkChoice` struct.
I've changed the ordering of SSE events when a block is received. It used to be `[block, finalized, head]` and now it's `[block, head, finalized]`. It was easier this way and I don't think we were making any promises about SSE event ordering so it's not "breaking".
I've made it so fork choice will run when it's first constructed. I did this because I wanted to have a cached version of the last call to `get_head`. Ensuring `get_head` has been run *at least once* means that the cached values doesn't need to wrapped in an `Option`. This was fairly simple, it just involved passing a `slot` to the constructor so it knows *when* it's being run. When loading a fork choice from the store and a slot clock isn't handy I've just used the `slot` that was saved in the `fork_choice_store`. That seems like it would be a faithful representation of the slot when we saved it.
I added the `genesis_time: u64` to the `BeaconChain`. It's small, constant and nice to have around.
Since we're using FC for the fin/just checkpoints, we no longer get the `0x00..00` roots at genesis. You can see I had to remove a work-around in `ef-tests` here: b56be3bc2. I can't find any reason why this would be an issue, if anything I think it'll be better since the genesis-alias has caught us out a few times (0x00..00 isn't actually a real root). Edit: I did find a case where the `network` expected the 0x00..00 alias and patched it here: 3f26ac3e2.
You'll notice a lot of changes in tests. Generally, tests should be functionally equivalent. Here are the things creating the most diff-noise in tests:
- Changing tests to be `tokio::async` tests.
- Adding `.await` to fork choice, block processing and block production functions.
- Refactor of the `canonical_head` "API" provided by the `BeaconChain`. E.g., `chain.canonical_head.cached_head()` instead of `chain.canonical_head.read()`.
- Wrapping `SignedBeaconBlock` in an `Arc`.
- In the `beacon_chain/tests/block_verification`, we can't use the `lazy_static` `CHAIN_SEGMENT` variable anymore since it's generated with an async function. We just generate it in each test, not so efficient but hopefully insignificant.
I had to disable `rayon` concurrent tests in the `fork_choice` tests. This is because the use of `rayon` and `block_on` was causing a panic.
Co-authored-by: Mac L <mjladson@pm.me>
2022-07-03 05:36:50 +00:00
|
|
|
self.chain.head_snapshot().beacon_state.validators().len()
|
2020-09-29 03:46:54 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
fn interesting_validator_indices(&self) -> Vec<Vec<u64>> {
|
|
|
|
|
let validator_count = self.validator_count() as u64;
|
|
|
|
|
|
|
|
|
|
let mut interesting = vec![
|
|
|
|
|
vec![],
|
|
|
|
|
vec![0],
|
|
|
|
|
vec![0, 1],
|
|
|
|
|
vec![0, 1, 3],
|
|
|
|
|
vec![validator_count],
|
|
|
|
|
vec![validator_count, 1],
|
|
|
|
|
vec![validator_count, 1, 3],
|
|
|
|
|
vec![u64::max_value()],
|
|
|
|
|
vec![u64::max_value(), 1],
|
|
|
|
|
vec![u64::max_value(), 1, 3],
|
|
|
|
|
];
|
|
|
|
|
|
|
|
|
|
interesting.push((0..validator_count).collect());
|
|
|
|
|
|
|
|
|
|
interesting
|
|
|
|
|
}
|
|
|
|
|
|
2020-10-29 05:13:04 +00:00
|
|
|
fn interesting_validator_statuses(&self) -> Vec<Vec<ValidatorStatus>> {
|
|
|
|
|
let interesting = vec![
|
|
|
|
|
vec![],
|
|
|
|
|
vec![ValidatorStatus::Active],
|
|
|
|
|
vec![
|
2021-02-24 04:15:13 +00:00
|
|
|
ValidatorStatus::PendingInitialized,
|
|
|
|
|
ValidatorStatus::PendingQueued,
|
|
|
|
|
ValidatorStatus::ActiveOngoing,
|
|
|
|
|
ValidatorStatus::ActiveExiting,
|
|
|
|
|
ValidatorStatus::ActiveSlashed,
|
|
|
|
|
ValidatorStatus::ExitedUnslashed,
|
2020-10-29 05:13:04 +00:00
|
|
|
ValidatorStatus::ExitedSlashed,
|
2021-02-24 04:15:13 +00:00
|
|
|
ValidatorStatus::WithdrawalPossible,
|
|
|
|
|
ValidatorStatus::WithdrawalDone,
|
|
|
|
|
ValidatorStatus::Active,
|
|
|
|
|
ValidatorStatus::Pending,
|
|
|
|
|
ValidatorStatus::Exited,
|
|
|
|
|
ValidatorStatus::Withdrawal,
|
2020-10-29 05:13:04 +00:00
|
|
|
],
|
|
|
|
|
];
|
|
|
|
|
interesting
|
|
|
|
|
}
|
|
|
|
|
|
2020-09-29 03:46:54 +00:00
|
|
|
pub async fn test_get_validator_duties_attester(self) -> Self {
|
|
|
|
|
let current_epoch = self.chain.epoch().unwrap().as_u64();
|
|
|
|
|
|
|
|
|
|
let half = current_epoch / 2;
|
|
|
|
|
let first = current_epoch - half;
|
|
|
|
|
let last = current_epoch + half;
|
|
|
|
|
|
|
|
|
|
for epoch in first..=last {
|
|
|
|
|
for indices in self.interesting_validator_indices() {
|
|
|
|
|
let epoch = Epoch::from(epoch);
|
|
|
|
|
|
|
|
|
|
// The endpoint does not allow getting duties past the next epoch.
|
|
|
|
|
if epoch > current_epoch + 1 {
|
|
|
|
|
assert_eq!(
|
|
|
|
|
self.client
|
2020-11-09 23:13:56 +00:00
|
|
|
.post_validator_duties_attester(epoch, indices.as_slice())
|
2020-09-29 03:46:54 +00:00
|
|
|
.await
|
|
|
|
|
.unwrap_err()
|
|
|
|
|
.status()
|
|
|
|
|
.map(Into::into),
|
|
|
|
|
Some(400)
|
|
|
|
|
);
|
|
|
|
|
continue;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
let results = self
|
|
|
|
|
.client
|
2020-11-09 23:13:56 +00:00
|
|
|
.post_validator_duties_attester(epoch, indices.as_slice())
|
2020-09-29 03:46:54 +00:00
|
|
|
.await
|
2020-12-04 00:18:58 +00:00
|
|
|
.unwrap();
|
|
|
|
|
|
|
|
|
|
let dependent_root = self
|
|
|
|
|
.chain
|
Use the forwards iterator more often (#2376)
## Issue Addressed
NA
## Primary Change
When investigating memory usage, I noticed that retrieving a block from an early slot (e.g., slot 900) would cause a sharp increase in the memory footprint (from 400mb to 800mb+) which seemed to be ever-lasting.
After some investigation, I found that the reverse iteration from the head back to that slot was the likely culprit. To counter this, I've switched the `BeaconChain::block_root_at_slot` to use the forwards iterator, instead of the reverse one.
I also noticed that the networking stack is using `BeaconChain::root_at_slot` to check if a peer is relevant (`check_peer_relevance`). Perhaps the steep, seemingly-random-but-consistent increases in memory usage are caused by the use of this function.
Using the forwards iterator with the HTTP API alleviated the sharp increases in memory usage. It also made the response much faster (before it felt like to took 1-2s, now it feels instant).
## Additional Changes
In the process I also noticed that we have two functions for getting block roots:
- `BeaconChain::block_root_at_slot`: returns `None` for a skip slot.
- `BeaconChain::root_at_slot`: returns the previous root for a skip slot.
I unified these two functions into `block_root_at_slot` and added the `WhenSlotSkipped` enum. Now, the caller must be explicit about the skip-slot behaviour when requesting a root.
Additionally, I replaced `vec![]` with `Vec::with_capacity` in `store::chunked_vector::range_query`. I stumbled across this whilst debugging and made this modification to see what effect it would have (not much). It seems like a decent change to keep around, but I'm not concerned either way.
Also, `BeaconChain::get_ancestor_block_root` is unused, so I got rid of it :wastebasket:.
## Additional Info
I haven't also done the same for state roots here. Whilst it's possible and a good idea, it's more work since the fwds iterators are presently block-roots-specific.
Whilst there's a few places a reverse iteration of state roots could be triggered (e.g., attestation production, HTTP API), they're no where near as common as the `check_peer_relevance` call. As such, I think we should get this PR merged first, then come back for the state root iters. I made an issue here https://github.com/sigp/lighthouse/issues/2377.
2021-05-31 04:18:20 +00:00
|
|
|
.block_root_at_slot(
|
|
|
|
|
(epoch - 1).start_slot(E::slots_per_epoch()) - 1,
|
|
|
|
|
WhenSlotSkipped::Prev,
|
|
|
|
|
)
|
2020-09-29 03:46:54 +00:00
|
|
|
.unwrap()
|
Use async code when interacting with EL (#3244)
## Overview
This rather extensive PR achieves two primary goals:
1. Uses the finalized/justified checkpoints of fork choice (FC), rather than that of the head state.
2. Refactors fork choice, block production and block processing to `async` functions.
Additionally, it achieves:
- Concurrent forkchoice updates to the EL and cache pruning after a new head is selected.
- Concurrent "block packing" (attestations, etc) and execution payload retrieval during block production.
- Concurrent per-block-processing and execution payload verification during block processing.
- The `Arc`-ification of `SignedBeaconBlock` during block processing (it's never mutated, so why not?):
- I had to do this to deal with sending blocks into spawned tasks.
- Previously we were cloning the beacon block at least 2 times during each block processing, these clones are either removed or turned into cheaper `Arc` clones.
- We were also `Box`-ing and un-`Box`-ing beacon blocks as they moved throughout the networking crate. This is not a big deal, but it's nice to avoid shifting things between the stack and heap.
- Avoids cloning *all the blocks* in *every chain segment* during sync.
- It also has the potential to clean up our code where we need to pass an *owned* block around so we can send it back in the case of an error (I didn't do much of this, my PR is already big enough :sweat_smile:)
- The `BeaconChain::HeadSafetyStatus` struct was removed. It was an old relic from prior merge specs.
For motivation for this change, see https://github.com/sigp/lighthouse/pull/3244#issuecomment-1160963273
## Changes to `canonical_head` and `fork_choice`
Previously, the `BeaconChain` had two separate fields:
```
canonical_head: RwLock<Snapshot>,
fork_choice: RwLock<BeaconForkChoice>
```
Now, we have grouped these values under a single struct:
```
canonical_head: CanonicalHead {
cached_head: RwLock<Arc<Snapshot>>,
fork_choice: RwLock<BeaconForkChoice>
}
```
Apart from ergonomics, the only *actual* change here is wrapping the canonical head snapshot in an `Arc`. This means that we no longer need to hold the `cached_head` (`canonical_head`, in old terms) lock when we want to pull some values from it. This was done to avoid deadlock risks by preventing functions from acquiring (and holding) the `cached_head` and `fork_choice` locks simultaneously.
## Breaking Changes
### The `state` (root) field in the `finalized_checkpoint` SSE event
Consider the scenario where epoch `n` is just finalized, but `start_slot(n)` is skipped. There are two state roots we might in the `finalized_checkpoint` SSE event:
1. The state root of the finalized block, which is `get_block(finalized_checkpoint.root).state_root`.
4. The state root at slot of `start_slot(n)`, which would be the state from (1), but "skipped forward" through any skip slots.
Previously, Lighthouse would choose (2). However, we can see that when [Teku generates that event](https://github.com/ConsenSys/teku/blob/de2b2801c89ef5abf983d6bf37867c37fc47121f/data/beaconrestapi/src/main/java/tech/pegasys/teku/beaconrestapi/handlers/v1/events/EventSubscriptionManager.java#L171-L182) it uses [`getStateRootFromBlockRoot`](https://github.com/ConsenSys/teku/blob/de2b2801c89ef5abf983d6bf37867c37fc47121f/data/provider/src/main/java/tech/pegasys/teku/api/ChainDataProvider.java#L336-L341) which uses (1).
I have switched Lighthouse from (2) to (1). I think it's a somewhat arbitrary choice between the two, where (1) is easier to compute and is consistent with Teku.
## Notes for Reviewers
I've renamed `BeaconChain::fork_choice` to `BeaconChain::recompute_head`. Doing this helped ensure I broke all previous uses of fork choice and I also find it more descriptive. It describes an action and can't be confused with trying to get a reference to the `ForkChoice` struct.
I've changed the ordering of SSE events when a block is received. It used to be `[block, finalized, head]` and now it's `[block, head, finalized]`. It was easier this way and I don't think we were making any promises about SSE event ordering so it's not "breaking".
I've made it so fork choice will run when it's first constructed. I did this because I wanted to have a cached version of the last call to `get_head`. Ensuring `get_head` has been run *at least once* means that the cached values doesn't need to wrapped in an `Option`. This was fairly simple, it just involved passing a `slot` to the constructor so it knows *when* it's being run. When loading a fork choice from the store and a slot clock isn't handy I've just used the `slot` that was saved in the `fork_choice_store`. That seems like it would be a faithful representation of the slot when we saved it.
I added the `genesis_time: u64` to the `BeaconChain`. It's small, constant and nice to have around.
Since we're using FC for the fin/just checkpoints, we no longer get the `0x00..00` roots at genesis. You can see I had to remove a work-around in `ef-tests` here: b56be3bc2. I can't find any reason why this would be an issue, if anything I think it'll be better since the genesis-alias has caught us out a few times (0x00..00 isn't actually a real root). Edit: I did find a case where the `network` expected the 0x00..00 alias and patched it here: 3f26ac3e2.
You'll notice a lot of changes in tests. Generally, tests should be functionally equivalent. Here are the things creating the most diff-noise in tests:
- Changing tests to be `tokio::async` tests.
- Adding `.await` to fork choice, block processing and block production functions.
- Refactor of the `canonical_head` "API" provided by the `BeaconChain`. E.g., `chain.canonical_head.cached_head()` instead of `chain.canonical_head.read()`.
- Wrapping `SignedBeaconBlock` in an `Arc`.
- In the `beacon_chain/tests/block_verification`, we can't use the `lazy_static` `CHAIN_SEGMENT` variable anymore since it's generated with an async function. We just generate it in each test, not so efficient but hopefully insignificant.
I had to disable `rayon` concurrent tests in the `fork_choice` tests. This is because the use of `rayon` and `block_on` was causing a panic.
Co-authored-by: Mac L <mjladson@pm.me>
2022-07-03 05:36:50 +00:00
|
|
|
.unwrap_or(self.chain.head_beacon_block_root());
|
2020-12-04 00:18:58 +00:00
|
|
|
|
|
|
|
|
assert_eq!(results.dependent_root, dependent_root);
|
|
|
|
|
|
|
|
|
|
let result_duties = results.data;
|
2020-09-29 03:46:54 +00:00
|
|
|
|
|
|
|
|
let mut state = self
|
|
|
|
|
.chain
|
|
|
|
|
.state_at_slot(
|
|
|
|
|
epoch.start_slot(E::slots_per_epoch()),
|
|
|
|
|
StateSkipConfig::WithStateRoots,
|
|
|
|
|
)
|
|
|
|
|
.unwrap();
|
|
|
|
|
state
|
|
|
|
|
.build_committee_cache(RelativeEpoch::Current, &self.chain.spec)
|
|
|
|
|
.unwrap();
|
|
|
|
|
|
|
|
|
|
let expected_len = indices
|
|
|
|
|
.iter()
|
2021-07-09 06:15:32 +00:00
|
|
|
.filter(|i| **i < state.validators().len() as u64)
|
2020-09-29 03:46:54 +00:00
|
|
|
.count();
|
|
|
|
|
|
2020-12-04 00:18:58 +00:00
|
|
|
assert_eq!(result_duties.len(), expected_len);
|
2020-09-29 03:46:54 +00:00
|
|
|
|
|
|
|
|
for (indices_set, &i) in indices.iter().enumerate() {
|
|
|
|
|
if let Some(duty) = state
|
|
|
|
|
.get_attestation_duties(i as usize, RelativeEpoch::Current)
|
|
|
|
|
.unwrap()
|
|
|
|
|
{
|
|
|
|
|
let expected = AttesterData {
|
2021-07-09 06:15:32 +00:00
|
|
|
pubkey: state.validators()[i as usize].pubkey.clone().into(),
|
2020-09-29 03:46:54 +00:00
|
|
|
validator_index: i,
|
|
|
|
|
committees_at_slot: duty.committees_at_slot,
|
|
|
|
|
committee_index: duty.index,
|
|
|
|
|
committee_length: duty.committee_len as u64,
|
|
|
|
|
validator_committee_index: duty.committee_position as u64,
|
|
|
|
|
slot: duty.slot,
|
|
|
|
|
};
|
|
|
|
|
|
2020-12-04 00:18:58 +00:00
|
|
|
let result = result_duties
|
2020-09-29 03:46:54 +00:00
|
|
|
.iter()
|
|
|
|
|
.find(|duty| duty.validator_index == i)
|
|
|
|
|
.unwrap();
|
|
|
|
|
|
|
|
|
|
assert_eq!(
|
|
|
|
|
*result, expected,
|
|
|
|
|
"epoch: {}, indices_set: {}",
|
|
|
|
|
epoch, indices_set
|
|
|
|
|
);
|
|
|
|
|
} else {
|
|
|
|
|
assert!(
|
2020-12-04 00:18:58 +00:00
|
|
|
!result_duties.iter().any(|duty| duty.validator_index == i),
|
2020-09-29 03:46:54 +00:00
|
|
|
"validator index should not exist in response"
|
|
|
|
|
);
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
self
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
pub async fn test_get_validator_duties_proposer(self) -> Self {
|
|
|
|
|
let current_epoch = self.chain.epoch().unwrap();
|
|
|
|
|
|
2022-02-18 05:32:00 +00:00
|
|
|
for epoch in 0..=self.chain.epoch().unwrap().as_u64() + 1 {
|
2021-03-17 05:09:57 +00:00
|
|
|
let epoch = Epoch::from(epoch);
|
2020-12-04 00:18:58 +00:00
|
|
|
|
2021-03-17 05:09:57 +00:00
|
|
|
let dependent_root = self
|
|
|
|
|
.chain
|
Use the forwards iterator more often (#2376)
## Issue Addressed
NA
## Primary Change
When investigating memory usage, I noticed that retrieving a block from an early slot (e.g., slot 900) would cause a sharp increase in the memory footprint (from 400mb to 800mb+) which seemed to be ever-lasting.
After some investigation, I found that the reverse iteration from the head back to that slot was the likely culprit. To counter this, I've switched the `BeaconChain::block_root_at_slot` to use the forwards iterator, instead of the reverse one.
I also noticed that the networking stack is using `BeaconChain::root_at_slot` to check if a peer is relevant (`check_peer_relevance`). Perhaps the steep, seemingly-random-but-consistent increases in memory usage are caused by the use of this function.
Using the forwards iterator with the HTTP API alleviated the sharp increases in memory usage. It also made the response much faster (before it felt like to took 1-2s, now it feels instant).
## Additional Changes
In the process I also noticed that we have two functions for getting block roots:
- `BeaconChain::block_root_at_slot`: returns `None` for a skip slot.
- `BeaconChain::root_at_slot`: returns the previous root for a skip slot.
I unified these two functions into `block_root_at_slot` and added the `WhenSlotSkipped` enum. Now, the caller must be explicit about the skip-slot behaviour when requesting a root.
Additionally, I replaced `vec![]` with `Vec::with_capacity` in `store::chunked_vector::range_query`. I stumbled across this whilst debugging and made this modification to see what effect it would have (not much). It seems like a decent change to keep around, but I'm not concerned either way.
Also, `BeaconChain::get_ancestor_block_root` is unused, so I got rid of it :wastebasket:.
## Additional Info
I haven't also done the same for state roots here. Whilst it's possible and a good idea, it's more work since the fwds iterators are presently block-roots-specific.
Whilst there's a few places a reverse iteration of state roots could be triggered (e.g., attestation production, HTTP API), they're no where near as common as the `check_peer_relevance` call. As such, I think we should get this PR merged first, then come back for the state root iters. I made an issue here https://github.com/sigp/lighthouse/issues/2377.
2021-05-31 04:18:20 +00:00
|
|
|
.block_root_at_slot(
|
|
|
|
|
epoch.start_slot(E::slots_per_epoch()) - 1,
|
|
|
|
|
WhenSlotSkipped::Prev,
|
|
|
|
|
)
|
2021-03-17 05:09:57 +00:00
|
|
|
.unwrap()
|
Use async code when interacting with EL (#3244)
## Overview
This rather extensive PR achieves two primary goals:
1. Uses the finalized/justified checkpoints of fork choice (FC), rather than that of the head state.
2. Refactors fork choice, block production and block processing to `async` functions.
Additionally, it achieves:
- Concurrent forkchoice updates to the EL and cache pruning after a new head is selected.
- Concurrent "block packing" (attestations, etc) and execution payload retrieval during block production.
- Concurrent per-block-processing and execution payload verification during block processing.
- The `Arc`-ification of `SignedBeaconBlock` during block processing (it's never mutated, so why not?):
- I had to do this to deal with sending blocks into spawned tasks.
- Previously we were cloning the beacon block at least 2 times during each block processing, these clones are either removed or turned into cheaper `Arc` clones.
- We were also `Box`-ing and un-`Box`-ing beacon blocks as they moved throughout the networking crate. This is not a big deal, but it's nice to avoid shifting things between the stack and heap.
- Avoids cloning *all the blocks* in *every chain segment* during sync.
- It also has the potential to clean up our code where we need to pass an *owned* block around so we can send it back in the case of an error (I didn't do much of this, my PR is already big enough :sweat_smile:)
- The `BeaconChain::HeadSafetyStatus` struct was removed. It was an old relic from prior merge specs.
For motivation for this change, see https://github.com/sigp/lighthouse/pull/3244#issuecomment-1160963273
## Changes to `canonical_head` and `fork_choice`
Previously, the `BeaconChain` had two separate fields:
```
canonical_head: RwLock<Snapshot>,
fork_choice: RwLock<BeaconForkChoice>
```
Now, we have grouped these values under a single struct:
```
canonical_head: CanonicalHead {
cached_head: RwLock<Arc<Snapshot>>,
fork_choice: RwLock<BeaconForkChoice>
}
```
Apart from ergonomics, the only *actual* change here is wrapping the canonical head snapshot in an `Arc`. This means that we no longer need to hold the `cached_head` (`canonical_head`, in old terms) lock when we want to pull some values from it. This was done to avoid deadlock risks by preventing functions from acquiring (and holding) the `cached_head` and `fork_choice` locks simultaneously.
## Breaking Changes
### The `state` (root) field in the `finalized_checkpoint` SSE event
Consider the scenario where epoch `n` is just finalized, but `start_slot(n)` is skipped. There are two state roots we might in the `finalized_checkpoint` SSE event:
1. The state root of the finalized block, which is `get_block(finalized_checkpoint.root).state_root`.
4. The state root at slot of `start_slot(n)`, which would be the state from (1), but "skipped forward" through any skip slots.
Previously, Lighthouse would choose (2). However, we can see that when [Teku generates that event](https://github.com/ConsenSys/teku/blob/de2b2801c89ef5abf983d6bf37867c37fc47121f/data/beaconrestapi/src/main/java/tech/pegasys/teku/beaconrestapi/handlers/v1/events/EventSubscriptionManager.java#L171-L182) it uses [`getStateRootFromBlockRoot`](https://github.com/ConsenSys/teku/blob/de2b2801c89ef5abf983d6bf37867c37fc47121f/data/provider/src/main/java/tech/pegasys/teku/api/ChainDataProvider.java#L336-L341) which uses (1).
I have switched Lighthouse from (2) to (1). I think it's a somewhat arbitrary choice between the two, where (1) is easier to compute and is consistent with Teku.
## Notes for Reviewers
I've renamed `BeaconChain::fork_choice` to `BeaconChain::recompute_head`. Doing this helped ensure I broke all previous uses of fork choice and I also find it more descriptive. It describes an action and can't be confused with trying to get a reference to the `ForkChoice` struct.
I've changed the ordering of SSE events when a block is received. It used to be `[block, finalized, head]` and now it's `[block, head, finalized]`. It was easier this way and I don't think we were making any promises about SSE event ordering so it's not "breaking".
I've made it so fork choice will run when it's first constructed. I did this because I wanted to have a cached version of the last call to `get_head`. Ensuring `get_head` has been run *at least once* means that the cached values doesn't need to wrapped in an `Option`. This was fairly simple, it just involved passing a `slot` to the constructor so it knows *when* it's being run. When loading a fork choice from the store and a slot clock isn't handy I've just used the `slot` that was saved in the `fork_choice_store`. That seems like it would be a faithful representation of the slot when we saved it.
I added the `genesis_time: u64` to the `BeaconChain`. It's small, constant and nice to have around.
Since we're using FC for the fin/just checkpoints, we no longer get the `0x00..00` roots at genesis. You can see I had to remove a work-around in `ef-tests` here: b56be3bc2. I can't find any reason why this would be an issue, if anything I think it'll be better since the genesis-alias has caught us out a few times (0x00..00 isn't actually a real root). Edit: I did find a case where the `network` expected the 0x00..00 alias and patched it here: 3f26ac3e2.
You'll notice a lot of changes in tests. Generally, tests should be functionally equivalent. Here are the things creating the most diff-noise in tests:
- Changing tests to be `tokio::async` tests.
- Adding `.await` to fork choice, block processing and block production functions.
- Refactor of the `canonical_head` "API" provided by the `BeaconChain`. E.g., `chain.canonical_head.cached_head()` instead of `chain.canonical_head.read()`.
- Wrapping `SignedBeaconBlock` in an `Arc`.
- In the `beacon_chain/tests/block_verification`, we can't use the `lazy_static` `CHAIN_SEGMENT` variable anymore since it's generated with an async function. We just generate it in each test, not so efficient but hopefully insignificant.
I had to disable `rayon` concurrent tests in the `fork_choice` tests. This is because the use of `rayon` and `block_on` was causing a panic.
Co-authored-by: Mac L <mjladson@pm.me>
2022-07-03 05:36:50 +00:00
|
|
|
.unwrap_or(self.chain.head_beacon_block_root());
|
2020-09-29 03:46:54 +00:00
|
|
|
|
2021-03-17 05:09:57 +00:00
|
|
|
// Presently, the beacon chain harness never runs the code that primes the proposer
|
|
|
|
|
// cache. If this changes in the future then we'll need some smarter logic here, but
|
|
|
|
|
// this is succinct and effective for the time being.
|
|
|
|
|
assert!(
|
|
|
|
|
self.chain
|
|
|
|
|
.beacon_proposer_cache
|
|
|
|
|
.lock()
|
|
|
|
|
.get_epoch::<E>(dependent_root, epoch)
|
|
|
|
|
.is_none(),
|
|
|
|
|
"the proposer cache should miss initially"
|
|
|
|
|
);
|
2020-09-29 03:46:54 +00:00
|
|
|
|
2021-03-17 05:09:57 +00:00
|
|
|
let result = self
|
|
|
|
|
.client
|
|
|
|
|
.get_validator_duties_proposer(epoch)
|
|
|
|
|
.await
|
|
|
|
|
.unwrap();
|
2020-09-29 03:46:54 +00:00
|
|
|
|
2021-03-17 05:09:57 +00:00
|
|
|
// Check that current-epoch requests prime the proposer cache, whilst non-current
|
|
|
|
|
// requests don't.
|
|
|
|
|
if epoch == current_epoch {
|
|
|
|
|
assert!(
|
|
|
|
|
self.chain
|
|
|
|
|
.beacon_proposer_cache
|
|
|
|
|
.lock()
|
|
|
|
|
.get_epoch::<E>(dependent_root, epoch)
|
|
|
|
|
.is_some(),
|
|
|
|
|
"a current-epoch request should prime the proposer cache"
|
|
|
|
|
);
|
|
|
|
|
} else {
|
|
|
|
|
assert!(
|
|
|
|
|
self.chain
|
|
|
|
|
.beacon_proposer_cache
|
|
|
|
|
.lock()
|
|
|
|
|
.get_epoch::<E>(dependent_root, epoch)
|
|
|
|
|
.is_none(),
|
|
|
|
|
"a non-current-epoch request should not prime the proposer cache"
|
|
|
|
|
);
|
|
|
|
|
}
|
2020-09-29 03:46:54 +00:00
|
|
|
|
2021-03-17 05:09:57 +00:00
|
|
|
let mut state = self
|
|
|
|
|
.chain
|
|
|
|
|
.state_at_slot(
|
|
|
|
|
epoch.start_slot(E::slots_per_epoch()),
|
|
|
|
|
StateSkipConfig::WithStateRoots,
|
|
|
|
|
)
|
|
|
|
|
.unwrap();
|
2020-09-29 03:46:54 +00:00
|
|
|
|
2021-03-17 05:09:57 +00:00
|
|
|
state
|
|
|
|
|
.build_committee_cache(RelativeEpoch::Current, &self.chain.spec)
|
|
|
|
|
.unwrap();
|
2020-09-29 03:46:54 +00:00
|
|
|
|
2021-03-17 05:09:57 +00:00
|
|
|
let expected_duties = epoch
|
|
|
|
|
.slot_iter(E::slots_per_epoch())
|
|
|
|
|
.map(|slot| {
|
|
|
|
|
let index = state
|
|
|
|
|
.get_beacon_proposer_index(slot, &self.chain.spec)
|
|
|
|
|
.unwrap();
|
2021-07-09 06:15:32 +00:00
|
|
|
let pubkey = state.validators()[index].pubkey.clone().into();
|
2021-03-17 05:09:57 +00:00
|
|
|
|
|
|
|
|
ProposerData {
|
|
|
|
|
pubkey,
|
|
|
|
|
validator_index: index as u64,
|
|
|
|
|
slot,
|
|
|
|
|
}
|
|
|
|
|
})
|
|
|
|
|
.collect::<Vec<_>>();
|
2020-12-04 00:18:58 +00:00
|
|
|
|
2021-03-17 05:09:57 +00:00
|
|
|
let expected = DutiesResponse {
|
|
|
|
|
data: expected_duties,
|
|
|
|
|
dependent_root,
|
|
|
|
|
};
|
|
|
|
|
|
|
|
|
|
assert_eq!(result, expected);
|
|
|
|
|
|
|
|
|
|
// If it's the current epoch, check the function with a primed proposer cache.
|
|
|
|
|
if epoch == current_epoch {
|
|
|
|
|
// This is technically a double-check, but it's defensive.
|
|
|
|
|
assert!(
|
|
|
|
|
self.chain
|
|
|
|
|
.beacon_proposer_cache
|
|
|
|
|
.lock()
|
|
|
|
|
.get_epoch::<E>(dependent_root, epoch)
|
|
|
|
|
.is_some(),
|
|
|
|
|
"the request should prime the proposer cache"
|
|
|
|
|
);
|
|
|
|
|
|
|
|
|
|
let result = self
|
|
|
|
|
.client
|
|
|
|
|
.get_validator_duties_proposer(epoch)
|
|
|
|
|
.await
|
|
|
|
|
.unwrap();
|
|
|
|
|
|
|
|
|
|
assert_eq!(result, expected);
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
2022-02-18 05:32:00 +00:00
|
|
|
// Requests to the epochs after the next epoch should fail.
|
2021-03-17 05:09:57 +00:00
|
|
|
self.client
|
2022-02-18 05:32:00 +00:00
|
|
|
.get_validator_duties_proposer(current_epoch + 2)
|
2021-03-17 05:09:57 +00:00
|
|
|
.await
|
|
|
|
|
.unwrap_err();
|
2020-09-29 03:46:54 +00:00
|
|
|
|
|
|
|
|
self
|
|
|
|
|
}
|
|
|
|
|
|
2021-03-29 23:42:35 +00:00
|
|
|
pub async fn test_get_validator_duties_early(self) -> Self {
|
|
|
|
|
let current_epoch = self.chain.epoch().unwrap();
|
|
|
|
|
let next_epoch = current_epoch + 1;
|
|
|
|
|
let current_epoch_start = self
|
|
|
|
|
.chain
|
|
|
|
|
.slot_clock
|
|
|
|
|
.start_of(current_epoch.start_slot(E::slots_per_epoch()))
|
|
|
|
|
.unwrap();
|
|
|
|
|
|
|
|
|
|
self.chain.slot_clock.set_current_time(
|
|
|
|
|
current_epoch_start - MAXIMUM_GOSSIP_CLOCK_DISPARITY - Duration::from_millis(1),
|
|
|
|
|
);
|
|
|
|
|
|
2022-02-18 05:32:00 +00:00
|
|
|
let dependent_root = self
|
|
|
|
|
.chain
|
|
|
|
|
.block_root_at_slot(
|
|
|
|
|
current_epoch.start_slot(E::slots_per_epoch()) - 1,
|
|
|
|
|
WhenSlotSkipped::Prev,
|
|
|
|
|
)
|
|
|
|
|
.unwrap()
|
Use async code when interacting with EL (#3244)
## Overview
This rather extensive PR achieves two primary goals:
1. Uses the finalized/justified checkpoints of fork choice (FC), rather than that of the head state.
2. Refactors fork choice, block production and block processing to `async` functions.
Additionally, it achieves:
- Concurrent forkchoice updates to the EL and cache pruning after a new head is selected.
- Concurrent "block packing" (attestations, etc) and execution payload retrieval during block production.
- Concurrent per-block-processing and execution payload verification during block processing.
- The `Arc`-ification of `SignedBeaconBlock` during block processing (it's never mutated, so why not?):
- I had to do this to deal with sending blocks into spawned tasks.
- Previously we were cloning the beacon block at least 2 times during each block processing, these clones are either removed or turned into cheaper `Arc` clones.
- We were also `Box`-ing and un-`Box`-ing beacon blocks as they moved throughout the networking crate. This is not a big deal, but it's nice to avoid shifting things between the stack and heap.
- Avoids cloning *all the blocks* in *every chain segment* during sync.
- It also has the potential to clean up our code where we need to pass an *owned* block around so we can send it back in the case of an error (I didn't do much of this, my PR is already big enough :sweat_smile:)
- The `BeaconChain::HeadSafetyStatus` struct was removed. It was an old relic from prior merge specs.
For motivation for this change, see https://github.com/sigp/lighthouse/pull/3244#issuecomment-1160963273
## Changes to `canonical_head` and `fork_choice`
Previously, the `BeaconChain` had two separate fields:
```
canonical_head: RwLock<Snapshot>,
fork_choice: RwLock<BeaconForkChoice>
```
Now, we have grouped these values under a single struct:
```
canonical_head: CanonicalHead {
cached_head: RwLock<Arc<Snapshot>>,
fork_choice: RwLock<BeaconForkChoice>
}
```
Apart from ergonomics, the only *actual* change here is wrapping the canonical head snapshot in an `Arc`. This means that we no longer need to hold the `cached_head` (`canonical_head`, in old terms) lock when we want to pull some values from it. This was done to avoid deadlock risks by preventing functions from acquiring (and holding) the `cached_head` and `fork_choice` locks simultaneously.
## Breaking Changes
### The `state` (root) field in the `finalized_checkpoint` SSE event
Consider the scenario where epoch `n` is just finalized, but `start_slot(n)` is skipped. There are two state roots we might in the `finalized_checkpoint` SSE event:
1. The state root of the finalized block, which is `get_block(finalized_checkpoint.root).state_root`.
4. The state root at slot of `start_slot(n)`, which would be the state from (1), but "skipped forward" through any skip slots.
Previously, Lighthouse would choose (2). However, we can see that when [Teku generates that event](https://github.com/ConsenSys/teku/blob/de2b2801c89ef5abf983d6bf37867c37fc47121f/data/beaconrestapi/src/main/java/tech/pegasys/teku/beaconrestapi/handlers/v1/events/EventSubscriptionManager.java#L171-L182) it uses [`getStateRootFromBlockRoot`](https://github.com/ConsenSys/teku/blob/de2b2801c89ef5abf983d6bf37867c37fc47121f/data/provider/src/main/java/tech/pegasys/teku/api/ChainDataProvider.java#L336-L341) which uses (1).
I have switched Lighthouse from (2) to (1). I think it's a somewhat arbitrary choice between the two, where (1) is easier to compute and is consistent with Teku.
## Notes for Reviewers
I've renamed `BeaconChain::fork_choice` to `BeaconChain::recompute_head`. Doing this helped ensure I broke all previous uses of fork choice and I also find it more descriptive. It describes an action and can't be confused with trying to get a reference to the `ForkChoice` struct.
I've changed the ordering of SSE events when a block is received. It used to be `[block, finalized, head]` and now it's `[block, head, finalized]`. It was easier this way and I don't think we were making any promises about SSE event ordering so it's not "breaking".
I've made it so fork choice will run when it's first constructed. I did this because I wanted to have a cached version of the last call to `get_head`. Ensuring `get_head` has been run *at least once* means that the cached values doesn't need to wrapped in an `Option`. This was fairly simple, it just involved passing a `slot` to the constructor so it knows *when* it's being run. When loading a fork choice from the store and a slot clock isn't handy I've just used the `slot` that was saved in the `fork_choice_store`. That seems like it would be a faithful representation of the slot when we saved it.
I added the `genesis_time: u64` to the `BeaconChain`. It's small, constant and nice to have around.
Since we're using FC for the fin/just checkpoints, we no longer get the `0x00..00` roots at genesis. You can see I had to remove a work-around in `ef-tests` here: b56be3bc2. I can't find any reason why this would be an issue, if anything I think it'll be better since the genesis-alias has caught us out a few times (0x00..00 isn't actually a real root). Edit: I did find a case where the `network` expected the 0x00..00 alias and patched it here: 3f26ac3e2.
You'll notice a lot of changes in tests. Generally, tests should be functionally equivalent. Here are the things creating the most diff-noise in tests:
- Changing tests to be `tokio::async` tests.
- Adding `.await` to fork choice, block processing and block production functions.
- Refactor of the `canonical_head` "API" provided by the `BeaconChain`. E.g., `chain.canonical_head.cached_head()` instead of `chain.canonical_head.read()`.
- Wrapping `SignedBeaconBlock` in an `Arc`.
- In the `beacon_chain/tests/block_verification`, we can't use the `lazy_static` `CHAIN_SEGMENT` variable anymore since it's generated with an async function. We just generate it in each test, not so efficient but hopefully insignificant.
I had to disable `rayon` concurrent tests in the `fork_choice` tests. This is because the use of `rayon` and `block_on` was causing a panic.
Co-authored-by: Mac L <mjladson@pm.me>
2022-07-03 05:36:50 +00:00
|
|
|
.unwrap_or(self.chain.head_beacon_block_root());
|
2022-02-18 05:32:00 +00:00
|
|
|
|
|
|
|
|
self.client
|
|
|
|
|
.get_validator_duties_proposer(current_epoch)
|
|
|
|
|
.await
|
|
|
|
|
.expect("should get proposer duties for the next epoch outside of tolerance");
|
|
|
|
|
|
|
|
|
|
assert!(
|
|
|
|
|
self.chain
|
|
|
|
|
.beacon_proposer_cache
|
|
|
|
|
.lock()
|
|
|
|
|
.get_epoch::<E>(dependent_root, current_epoch)
|
|
|
|
|
.is_none(),
|
|
|
|
|
"should not prime the proposer cache outside of tolerance"
|
2021-03-29 23:42:35 +00:00
|
|
|
);
|
|
|
|
|
|
|
|
|
|
assert_eq!(
|
|
|
|
|
self.client
|
|
|
|
|
.post_validator_duties_attester(next_epoch, &[0])
|
|
|
|
|
.await
|
|
|
|
|
.unwrap_err()
|
|
|
|
|
.status()
|
|
|
|
|
.map(Into::into),
|
|
|
|
|
Some(400),
|
|
|
|
|
"should not get attester duties outside of tolerance"
|
|
|
|
|
);
|
|
|
|
|
|
|
|
|
|
self.chain
|
|
|
|
|
.slot_clock
|
|
|
|
|
.set_current_time(current_epoch_start - MAXIMUM_GOSSIP_CLOCK_DISPARITY);
|
|
|
|
|
|
|
|
|
|
self.client
|
|
|
|
|
.get_validator_duties_proposer(current_epoch)
|
|
|
|
|
.await
|
|
|
|
|
.expect("should get proposer duties within tolerance");
|
2022-02-18 05:32:00 +00:00
|
|
|
|
|
|
|
|
assert!(
|
|
|
|
|
self.chain
|
|
|
|
|
.beacon_proposer_cache
|
|
|
|
|
.lock()
|
|
|
|
|
.get_epoch::<E>(dependent_root, current_epoch)
|
|
|
|
|
.is_some(),
|
|
|
|
|
"should prime the proposer cache inside the tolerance"
|
|
|
|
|
);
|
|
|
|
|
|
2021-03-29 23:42:35 +00:00
|
|
|
self.client
|
|
|
|
|
.post_validator_duties_attester(next_epoch, &[0])
|
|
|
|
|
.await
|
|
|
|
|
.expect("should get attester duties within tolerance");
|
|
|
|
|
|
|
|
|
|
self
|
|
|
|
|
}
|
|
|
|
|
|
2020-09-29 03:46:54 +00:00
|
|
|
pub async fn test_block_production(self) -> Self {
|
Use async code when interacting with EL (#3244)
## Overview
This rather extensive PR achieves two primary goals:
1. Uses the finalized/justified checkpoints of fork choice (FC), rather than that of the head state.
2. Refactors fork choice, block production and block processing to `async` functions.
Additionally, it achieves:
- Concurrent forkchoice updates to the EL and cache pruning after a new head is selected.
- Concurrent "block packing" (attestations, etc) and execution payload retrieval during block production.
- Concurrent per-block-processing and execution payload verification during block processing.
- The `Arc`-ification of `SignedBeaconBlock` during block processing (it's never mutated, so why not?):
- I had to do this to deal with sending blocks into spawned tasks.
- Previously we were cloning the beacon block at least 2 times during each block processing, these clones are either removed or turned into cheaper `Arc` clones.
- We were also `Box`-ing and un-`Box`-ing beacon blocks as they moved throughout the networking crate. This is not a big deal, but it's nice to avoid shifting things between the stack and heap.
- Avoids cloning *all the blocks* in *every chain segment* during sync.
- It also has the potential to clean up our code where we need to pass an *owned* block around so we can send it back in the case of an error (I didn't do much of this, my PR is already big enough :sweat_smile:)
- The `BeaconChain::HeadSafetyStatus` struct was removed. It was an old relic from prior merge specs.
For motivation for this change, see https://github.com/sigp/lighthouse/pull/3244#issuecomment-1160963273
## Changes to `canonical_head` and `fork_choice`
Previously, the `BeaconChain` had two separate fields:
```
canonical_head: RwLock<Snapshot>,
fork_choice: RwLock<BeaconForkChoice>
```
Now, we have grouped these values under a single struct:
```
canonical_head: CanonicalHead {
cached_head: RwLock<Arc<Snapshot>>,
fork_choice: RwLock<BeaconForkChoice>
}
```
Apart from ergonomics, the only *actual* change here is wrapping the canonical head snapshot in an `Arc`. This means that we no longer need to hold the `cached_head` (`canonical_head`, in old terms) lock when we want to pull some values from it. This was done to avoid deadlock risks by preventing functions from acquiring (and holding) the `cached_head` and `fork_choice` locks simultaneously.
## Breaking Changes
### The `state` (root) field in the `finalized_checkpoint` SSE event
Consider the scenario where epoch `n` is just finalized, but `start_slot(n)` is skipped. There are two state roots we might in the `finalized_checkpoint` SSE event:
1. The state root of the finalized block, which is `get_block(finalized_checkpoint.root).state_root`.
4. The state root at slot of `start_slot(n)`, which would be the state from (1), but "skipped forward" through any skip slots.
Previously, Lighthouse would choose (2). However, we can see that when [Teku generates that event](https://github.com/ConsenSys/teku/blob/de2b2801c89ef5abf983d6bf37867c37fc47121f/data/beaconrestapi/src/main/java/tech/pegasys/teku/beaconrestapi/handlers/v1/events/EventSubscriptionManager.java#L171-L182) it uses [`getStateRootFromBlockRoot`](https://github.com/ConsenSys/teku/blob/de2b2801c89ef5abf983d6bf37867c37fc47121f/data/provider/src/main/java/tech/pegasys/teku/api/ChainDataProvider.java#L336-L341) which uses (1).
I have switched Lighthouse from (2) to (1). I think it's a somewhat arbitrary choice between the two, where (1) is easier to compute and is consistent with Teku.
## Notes for Reviewers
I've renamed `BeaconChain::fork_choice` to `BeaconChain::recompute_head`. Doing this helped ensure I broke all previous uses of fork choice and I also find it more descriptive. It describes an action and can't be confused with trying to get a reference to the `ForkChoice` struct.
I've changed the ordering of SSE events when a block is received. It used to be `[block, finalized, head]` and now it's `[block, head, finalized]`. It was easier this way and I don't think we were making any promises about SSE event ordering so it's not "breaking".
I've made it so fork choice will run when it's first constructed. I did this because I wanted to have a cached version of the last call to `get_head`. Ensuring `get_head` has been run *at least once* means that the cached values doesn't need to wrapped in an `Option`. This was fairly simple, it just involved passing a `slot` to the constructor so it knows *when* it's being run. When loading a fork choice from the store and a slot clock isn't handy I've just used the `slot` that was saved in the `fork_choice_store`. That seems like it would be a faithful representation of the slot when we saved it.
I added the `genesis_time: u64` to the `BeaconChain`. It's small, constant and nice to have around.
Since we're using FC for the fin/just checkpoints, we no longer get the `0x00..00` roots at genesis. You can see I had to remove a work-around in `ef-tests` here: b56be3bc2. I can't find any reason why this would be an issue, if anything I think it'll be better since the genesis-alias has caught us out a few times (0x00..00 isn't actually a real root). Edit: I did find a case where the `network` expected the 0x00..00 alias and patched it here: 3f26ac3e2.
You'll notice a lot of changes in tests. Generally, tests should be functionally equivalent. Here are the things creating the most diff-noise in tests:
- Changing tests to be `tokio::async` tests.
- Adding `.await` to fork choice, block processing and block production functions.
- Refactor of the `canonical_head` "API" provided by the `BeaconChain`. E.g., `chain.canonical_head.cached_head()` instead of `chain.canonical_head.read()`.
- Wrapping `SignedBeaconBlock` in an `Arc`.
- In the `beacon_chain/tests/block_verification`, we can't use the `lazy_static` `CHAIN_SEGMENT` variable anymore since it's generated with an async function. We just generate it in each test, not so efficient but hopefully insignificant.
I had to disable `rayon` concurrent tests in the `fork_choice` tests. This is because the use of `rayon` and `block_on` was causing a panic.
Co-authored-by: Mac L <mjladson@pm.me>
2022-07-03 05:36:50 +00:00
|
|
|
let fork = self.chain.canonical_head.cached_head().head_fork();
|
2020-09-29 03:46:54 +00:00
|
|
|
let genesis_validators_root = self.chain.genesis_validators_root;
|
|
|
|
|
|
|
|
|
|
for _ in 0..E::slots_per_epoch() * 3 {
|
|
|
|
|
let slot = self.chain.slot().unwrap();
|
|
|
|
|
let epoch = self.chain.epoch().unwrap();
|
|
|
|
|
|
|
|
|
|
let proposer_pubkey_bytes = self
|
|
|
|
|
.client
|
|
|
|
|
.get_validator_duties_proposer(epoch)
|
|
|
|
|
.await
|
|
|
|
|
.unwrap()
|
|
|
|
|
.data
|
|
|
|
|
.into_iter()
|
|
|
|
|
.find(|duty| duty.slot == slot)
|
|
|
|
|
.map(|duty| duty.pubkey)
|
|
|
|
|
.unwrap();
|
|
|
|
|
let proposer_pubkey = (&proposer_pubkey_bytes).try_into().unwrap();
|
|
|
|
|
|
|
|
|
|
let sk = self
|
Use async code when interacting with EL (#3244)
## Overview
This rather extensive PR achieves two primary goals:
1. Uses the finalized/justified checkpoints of fork choice (FC), rather than that of the head state.
2. Refactors fork choice, block production and block processing to `async` functions.
Additionally, it achieves:
- Concurrent forkchoice updates to the EL and cache pruning after a new head is selected.
- Concurrent "block packing" (attestations, etc) and execution payload retrieval during block production.
- Concurrent per-block-processing and execution payload verification during block processing.
- The `Arc`-ification of `SignedBeaconBlock` during block processing (it's never mutated, so why not?):
- I had to do this to deal with sending blocks into spawned tasks.
- Previously we were cloning the beacon block at least 2 times during each block processing, these clones are either removed or turned into cheaper `Arc` clones.
- We were also `Box`-ing and un-`Box`-ing beacon blocks as they moved throughout the networking crate. This is not a big deal, but it's nice to avoid shifting things between the stack and heap.
- Avoids cloning *all the blocks* in *every chain segment* during sync.
- It also has the potential to clean up our code where we need to pass an *owned* block around so we can send it back in the case of an error (I didn't do much of this, my PR is already big enough :sweat_smile:)
- The `BeaconChain::HeadSafetyStatus` struct was removed. It was an old relic from prior merge specs.
For motivation for this change, see https://github.com/sigp/lighthouse/pull/3244#issuecomment-1160963273
## Changes to `canonical_head` and `fork_choice`
Previously, the `BeaconChain` had two separate fields:
```
canonical_head: RwLock<Snapshot>,
fork_choice: RwLock<BeaconForkChoice>
```
Now, we have grouped these values under a single struct:
```
canonical_head: CanonicalHead {
cached_head: RwLock<Arc<Snapshot>>,
fork_choice: RwLock<BeaconForkChoice>
}
```
Apart from ergonomics, the only *actual* change here is wrapping the canonical head snapshot in an `Arc`. This means that we no longer need to hold the `cached_head` (`canonical_head`, in old terms) lock when we want to pull some values from it. This was done to avoid deadlock risks by preventing functions from acquiring (and holding) the `cached_head` and `fork_choice` locks simultaneously.
## Breaking Changes
### The `state` (root) field in the `finalized_checkpoint` SSE event
Consider the scenario where epoch `n` is just finalized, but `start_slot(n)` is skipped. There are two state roots we might in the `finalized_checkpoint` SSE event:
1. The state root of the finalized block, which is `get_block(finalized_checkpoint.root).state_root`.
4. The state root at slot of `start_slot(n)`, which would be the state from (1), but "skipped forward" through any skip slots.
Previously, Lighthouse would choose (2). However, we can see that when [Teku generates that event](https://github.com/ConsenSys/teku/blob/de2b2801c89ef5abf983d6bf37867c37fc47121f/data/beaconrestapi/src/main/java/tech/pegasys/teku/beaconrestapi/handlers/v1/events/EventSubscriptionManager.java#L171-L182) it uses [`getStateRootFromBlockRoot`](https://github.com/ConsenSys/teku/blob/de2b2801c89ef5abf983d6bf37867c37fc47121f/data/provider/src/main/java/tech/pegasys/teku/api/ChainDataProvider.java#L336-L341) which uses (1).
I have switched Lighthouse from (2) to (1). I think it's a somewhat arbitrary choice between the two, where (1) is easier to compute and is consistent with Teku.
## Notes for Reviewers
I've renamed `BeaconChain::fork_choice` to `BeaconChain::recompute_head`. Doing this helped ensure I broke all previous uses of fork choice and I also find it more descriptive. It describes an action and can't be confused with trying to get a reference to the `ForkChoice` struct.
I've changed the ordering of SSE events when a block is received. It used to be `[block, finalized, head]` and now it's `[block, head, finalized]`. It was easier this way and I don't think we were making any promises about SSE event ordering so it's not "breaking".
I've made it so fork choice will run when it's first constructed. I did this because I wanted to have a cached version of the last call to `get_head`. Ensuring `get_head` has been run *at least once* means that the cached values doesn't need to wrapped in an `Option`. This was fairly simple, it just involved passing a `slot` to the constructor so it knows *when* it's being run. When loading a fork choice from the store and a slot clock isn't handy I've just used the `slot` that was saved in the `fork_choice_store`. That seems like it would be a faithful representation of the slot when we saved it.
I added the `genesis_time: u64` to the `BeaconChain`. It's small, constant and nice to have around.
Since we're using FC for the fin/just checkpoints, we no longer get the `0x00..00` roots at genesis. You can see I had to remove a work-around in `ef-tests` here: b56be3bc2. I can't find any reason why this would be an issue, if anything I think it'll be better since the genesis-alias has caught us out a few times (0x00..00 isn't actually a real root). Edit: I did find a case where the `network` expected the 0x00..00 alias and patched it here: 3f26ac3e2.
You'll notice a lot of changes in tests. Generally, tests should be functionally equivalent. Here are the things creating the most diff-noise in tests:
- Changing tests to be `tokio::async` tests.
- Adding `.await` to fork choice, block processing and block production functions.
- Refactor of the `canonical_head` "API" provided by the `BeaconChain`. E.g., `chain.canonical_head.cached_head()` instead of `chain.canonical_head.read()`.
- Wrapping `SignedBeaconBlock` in an `Arc`.
- In the `beacon_chain/tests/block_verification`, we can't use the `lazy_static` `CHAIN_SEGMENT` variable anymore since it's generated with an async function. We just generate it in each test, not so efficient but hopefully insignificant.
I had to disable `rayon` concurrent tests in the `fork_choice` tests. This is because the use of `rayon` and `block_on` was causing a panic.
Co-authored-by: Mac L <mjladson@pm.me>
2022-07-03 05:36:50 +00:00
|
|
|
.validator_keypairs()
|
2020-09-29 03:46:54 +00:00
|
|
|
.iter()
|
|
|
|
|
.find(|kp| kp.pk == proposer_pubkey)
|
|
|
|
|
.map(|kp| kp.sk.clone())
|
|
|
|
|
.unwrap();
|
|
|
|
|
|
|
|
|
|
let randao_reveal = {
|
|
|
|
|
let domain = self.chain.spec.get_domain(
|
|
|
|
|
epoch,
|
|
|
|
|
Domain::Randao,
|
|
|
|
|
&fork,
|
|
|
|
|
genesis_validators_root,
|
|
|
|
|
);
|
|
|
|
|
let message = epoch.signing_root(domain);
|
|
|
|
|
sk.sign(message).into()
|
|
|
|
|
};
|
|
|
|
|
|
|
|
|
|
let block = self
|
|
|
|
|
.client
|
2022-03-31 07:52:23 +00:00
|
|
|
.get_validator_blocks::<E, FullPayload<E>>(slot, &randao_reveal, None)
|
2020-09-29 03:46:54 +00:00
|
|
|
.await
|
|
|
|
|
.unwrap()
|
|
|
|
|
.data;
|
|
|
|
|
|
|
|
|
|
let signed_block = block.sign(&sk, &fork, genesis_validators_root, &self.chain.spec);
|
|
|
|
|
|
|
|
|
|
self.client.post_beacon_blocks(&signed_block).await.unwrap();
|
|
|
|
|
|
Use async code when interacting with EL (#3244)
## Overview
This rather extensive PR achieves two primary goals:
1. Uses the finalized/justified checkpoints of fork choice (FC), rather than that of the head state.
2. Refactors fork choice, block production and block processing to `async` functions.
Additionally, it achieves:
- Concurrent forkchoice updates to the EL and cache pruning after a new head is selected.
- Concurrent "block packing" (attestations, etc) and execution payload retrieval during block production.
- Concurrent per-block-processing and execution payload verification during block processing.
- The `Arc`-ification of `SignedBeaconBlock` during block processing (it's never mutated, so why not?):
- I had to do this to deal with sending blocks into spawned tasks.
- Previously we were cloning the beacon block at least 2 times during each block processing, these clones are either removed or turned into cheaper `Arc` clones.
- We were also `Box`-ing and un-`Box`-ing beacon blocks as they moved throughout the networking crate. This is not a big deal, but it's nice to avoid shifting things between the stack and heap.
- Avoids cloning *all the blocks* in *every chain segment* during sync.
- It also has the potential to clean up our code where we need to pass an *owned* block around so we can send it back in the case of an error (I didn't do much of this, my PR is already big enough :sweat_smile:)
- The `BeaconChain::HeadSafetyStatus` struct was removed. It was an old relic from prior merge specs.
For motivation for this change, see https://github.com/sigp/lighthouse/pull/3244#issuecomment-1160963273
## Changes to `canonical_head` and `fork_choice`
Previously, the `BeaconChain` had two separate fields:
```
canonical_head: RwLock<Snapshot>,
fork_choice: RwLock<BeaconForkChoice>
```
Now, we have grouped these values under a single struct:
```
canonical_head: CanonicalHead {
cached_head: RwLock<Arc<Snapshot>>,
fork_choice: RwLock<BeaconForkChoice>
}
```
Apart from ergonomics, the only *actual* change here is wrapping the canonical head snapshot in an `Arc`. This means that we no longer need to hold the `cached_head` (`canonical_head`, in old terms) lock when we want to pull some values from it. This was done to avoid deadlock risks by preventing functions from acquiring (and holding) the `cached_head` and `fork_choice` locks simultaneously.
## Breaking Changes
### The `state` (root) field in the `finalized_checkpoint` SSE event
Consider the scenario where epoch `n` is just finalized, but `start_slot(n)` is skipped. There are two state roots we might in the `finalized_checkpoint` SSE event:
1. The state root of the finalized block, which is `get_block(finalized_checkpoint.root).state_root`.
4. The state root at slot of `start_slot(n)`, which would be the state from (1), but "skipped forward" through any skip slots.
Previously, Lighthouse would choose (2). However, we can see that when [Teku generates that event](https://github.com/ConsenSys/teku/blob/de2b2801c89ef5abf983d6bf37867c37fc47121f/data/beaconrestapi/src/main/java/tech/pegasys/teku/beaconrestapi/handlers/v1/events/EventSubscriptionManager.java#L171-L182) it uses [`getStateRootFromBlockRoot`](https://github.com/ConsenSys/teku/blob/de2b2801c89ef5abf983d6bf37867c37fc47121f/data/provider/src/main/java/tech/pegasys/teku/api/ChainDataProvider.java#L336-L341) which uses (1).
I have switched Lighthouse from (2) to (1). I think it's a somewhat arbitrary choice between the two, where (1) is easier to compute and is consistent with Teku.
## Notes for Reviewers
I've renamed `BeaconChain::fork_choice` to `BeaconChain::recompute_head`. Doing this helped ensure I broke all previous uses of fork choice and I also find it more descriptive. It describes an action and can't be confused with trying to get a reference to the `ForkChoice` struct.
I've changed the ordering of SSE events when a block is received. It used to be `[block, finalized, head]` and now it's `[block, head, finalized]`. It was easier this way and I don't think we were making any promises about SSE event ordering so it's not "breaking".
I've made it so fork choice will run when it's first constructed. I did this because I wanted to have a cached version of the last call to `get_head`. Ensuring `get_head` has been run *at least once* means that the cached values doesn't need to wrapped in an `Option`. This was fairly simple, it just involved passing a `slot` to the constructor so it knows *when* it's being run. When loading a fork choice from the store and a slot clock isn't handy I've just used the `slot` that was saved in the `fork_choice_store`. That seems like it would be a faithful representation of the slot when we saved it.
I added the `genesis_time: u64` to the `BeaconChain`. It's small, constant and nice to have around.
Since we're using FC for the fin/just checkpoints, we no longer get the `0x00..00` roots at genesis. You can see I had to remove a work-around in `ef-tests` here: b56be3bc2. I can't find any reason why this would be an issue, if anything I think it'll be better since the genesis-alias has caught us out a few times (0x00..00 isn't actually a real root). Edit: I did find a case where the `network` expected the 0x00..00 alias and patched it here: 3f26ac3e2.
You'll notice a lot of changes in tests. Generally, tests should be functionally equivalent. Here are the things creating the most diff-noise in tests:
- Changing tests to be `tokio::async` tests.
- Adding `.await` to fork choice, block processing and block production functions.
- Refactor of the `canonical_head` "API" provided by the `BeaconChain`. E.g., `chain.canonical_head.cached_head()` instead of `chain.canonical_head.read()`.
- Wrapping `SignedBeaconBlock` in an `Arc`.
- In the `beacon_chain/tests/block_verification`, we can't use the `lazy_static` `CHAIN_SEGMENT` variable anymore since it's generated with an async function. We just generate it in each test, not so efficient but hopefully insignificant.
I had to disable `rayon` concurrent tests in the `fork_choice` tests. This is because the use of `rayon` and `block_on` was causing a panic.
Co-authored-by: Mac L <mjladson@pm.me>
2022-07-03 05:36:50 +00:00
|
|
|
assert_eq!(self.chain.head_beacon_block().as_ref(), &signed_block);
|
2020-09-29 03:46:54 +00:00
|
|
|
|
|
|
|
|
self.chain.slot_clock.set_slot(slot.as_u64() + 1);
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
self
|
|
|
|
|
}
|
|
|
|
|
|
2022-03-28 07:14:13 +00:00
|
|
|
pub async fn test_block_production_no_verify_randao(self) -> Self {
|
|
|
|
|
for _ in 0..E::slots_per_epoch() {
|
|
|
|
|
let slot = self.chain.slot().unwrap();
|
|
|
|
|
|
|
|
|
|
let block = self
|
|
|
|
|
.client
|
2022-03-31 07:52:23 +00:00
|
|
|
.get_validator_blocks_with_verify_randao::<E, FullPayload<E>>(
|
|
|
|
|
slot,
|
|
|
|
|
None,
|
|
|
|
|
None,
|
|
|
|
|
Some(false),
|
|
|
|
|
)
|
2022-03-28 07:14:13 +00:00
|
|
|
.await
|
|
|
|
|
.unwrap()
|
|
|
|
|
.data;
|
|
|
|
|
assert_eq!(block.slot(), slot);
|
|
|
|
|
self.chain.slot_clock.set_slot(slot.as_u64() + 1);
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
self
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
pub async fn test_block_production_verify_randao_invalid(self) -> Self {
|
Use async code when interacting with EL (#3244)
## Overview
This rather extensive PR achieves two primary goals:
1. Uses the finalized/justified checkpoints of fork choice (FC), rather than that of the head state.
2. Refactors fork choice, block production and block processing to `async` functions.
Additionally, it achieves:
- Concurrent forkchoice updates to the EL and cache pruning after a new head is selected.
- Concurrent "block packing" (attestations, etc) and execution payload retrieval during block production.
- Concurrent per-block-processing and execution payload verification during block processing.
- The `Arc`-ification of `SignedBeaconBlock` during block processing (it's never mutated, so why not?):
- I had to do this to deal with sending blocks into spawned tasks.
- Previously we were cloning the beacon block at least 2 times during each block processing, these clones are either removed or turned into cheaper `Arc` clones.
- We were also `Box`-ing and un-`Box`-ing beacon blocks as they moved throughout the networking crate. This is not a big deal, but it's nice to avoid shifting things between the stack and heap.
- Avoids cloning *all the blocks* in *every chain segment* during sync.
- It also has the potential to clean up our code where we need to pass an *owned* block around so we can send it back in the case of an error (I didn't do much of this, my PR is already big enough :sweat_smile:)
- The `BeaconChain::HeadSafetyStatus` struct was removed. It was an old relic from prior merge specs.
For motivation for this change, see https://github.com/sigp/lighthouse/pull/3244#issuecomment-1160963273
## Changes to `canonical_head` and `fork_choice`
Previously, the `BeaconChain` had two separate fields:
```
canonical_head: RwLock<Snapshot>,
fork_choice: RwLock<BeaconForkChoice>
```
Now, we have grouped these values under a single struct:
```
canonical_head: CanonicalHead {
cached_head: RwLock<Arc<Snapshot>>,
fork_choice: RwLock<BeaconForkChoice>
}
```
Apart from ergonomics, the only *actual* change here is wrapping the canonical head snapshot in an `Arc`. This means that we no longer need to hold the `cached_head` (`canonical_head`, in old terms) lock when we want to pull some values from it. This was done to avoid deadlock risks by preventing functions from acquiring (and holding) the `cached_head` and `fork_choice` locks simultaneously.
## Breaking Changes
### The `state` (root) field in the `finalized_checkpoint` SSE event
Consider the scenario where epoch `n` is just finalized, but `start_slot(n)` is skipped. There are two state roots we might in the `finalized_checkpoint` SSE event:
1. The state root of the finalized block, which is `get_block(finalized_checkpoint.root).state_root`.
4. The state root at slot of `start_slot(n)`, which would be the state from (1), but "skipped forward" through any skip slots.
Previously, Lighthouse would choose (2). However, we can see that when [Teku generates that event](https://github.com/ConsenSys/teku/blob/de2b2801c89ef5abf983d6bf37867c37fc47121f/data/beaconrestapi/src/main/java/tech/pegasys/teku/beaconrestapi/handlers/v1/events/EventSubscriptionManager.java#L171-L182) it uses [`getStateRootFromBlockRoot`](https://github.com/ConsenSys/teku/blob/de2b2801c89ef5abf983d6bf37867c37fc47121f/data/provider/src/main/java/tech/pegasys/teku/api/ChainDataProvider.java#L336-L341) which uses (1).
I have switched Lighthouse from (2) to (1). I think it's a somewhat arbitrary choice between the two, where (1) is easier to compute and is consistent with Teku.
## Notes for Reviewers
I've renamed `BeaconChain::fork_choice` to `BeaconChain::recompute_head`. Doing this helped ensure I broke all previous uses of fork choice and I also find it more descriptive. It describes an action and can't be confused with trying to get a reference to the `ForkChoice` struct.
I've changed the ordering of SSE events when a block is received. It used to be `[block, finalized, head]` and now it's `[block, head, finalized]`. It was easier this way and I don't think we were making any promises about SSE event ordering so it's not "breaking".
I've made it so fork choice will run when it's first constructed. I did this because I wanted to have a cached version of the last call to `get_head`. Ensuring `get_head` has been run *at least once* means that the cached values doesn't need to wrapped in an `Option`. This was fairly simple, it just involved passing a `slot` to the constructor so it knows *when* it's being run. When loading a fork choice from the store and a slot clock isn't handy I've just used the `slot` that was saved in the `fork_choice_store`. That seems like it would be a faithful representation of the slot when we saved it.
I added the `genesis_time: u64` to the `BeaconChain`. It's small, constant and nice to have around.
Since we're using FC for the fin/just checkpoints, we no longer get the `0x00..00` roots at genesis. You can see I had to remove a work-around in `ef-tests` here: b56be3bc2. I can't find any reason why this would be an issue, if anything I think it'll be better since the genesis-alias has caught us out a few times (0x00..00 isn't actually a real root). Edit: I did find a case where the `network` expected the 0x00..00 alias and patched it here: 3f26ac3e2.
You'll notice a lot of changes in tests. Generally, tests should be functionally equivalent. Here are the things creating the most diff-noise in tests:
- Changing tests to be `tokio::async` tests.
- Adding `.await` to fork choice, block processing and block production functions.
- Refactor of the `canonical_head` "API" provided by the `BeaconChain`. E.g., `chain.canonical_head.cached_head()` instead of `chain.canonical_head.read()`.
- Wrapping `SignedBeaconBlock` in an `Arc`.
- In the `beacon_chain/tests/block_verification`, we can't use the `lazy_static` `CHAIN_SEGMENT` variable anymore since it's generated with an async function. We just generate it in each test, not so efficient but hopefully insignificant.
I had to disable `rayon` concurrent tests in the `fork_choice` tests. This is because the use of `rayon` and `block_on` was causing a panic.
Co-authored-by: Mac L <mjladson@pm.me>
2022-07-03 05:36:50 +00:00
|
|
|
let fork = self.chain.canonical_head.cached_head().head_fork();
|
2022-03-28 07:14:13 +00:00
|
|
|
let genesis_validators_root = self.chain.genesis_validators_root;
|
|
|
|
|
|
|
|
|
|
for _ in 0..E::slots_per_epoch() {
|
|
|
|
|
let slot = self.chain.slot().unwrap();
|
|
|
|
|
let epoch = self.chain.epoch().unwrap();
|
|
|
|
|
|
|
|
|
|
let proposer_pubkey_bytes = self
|
|
|
|
|
.client
|
|
|
|
|
.get_validator_duties_proposer(epoch)
|
|
|
|
|
.await
|
|
|
|
|
.unwrap()
|
|
|
|
|
.data
|
|
|
|
|
.into_iter()
|
|
|
|
|
.find(|duty| duty.slot == slot)
|
|
|
|
|
.map(|duty| duty.pubkey)
|
|
|
|
|
.unwrap();
|
|
|
|
|
let proposer_pubkey = (&proposer_pubkey_bytes).try_into().unwrap();
|
|
|
|
|
|
|
|
|
|
let sk = self
|
Use async code when interacting with EL (#3244)
## Overview
This rather extensive PR achieves two primary goals:
1. Uses the finalized/justified checkpoints of fork choice (FC), rather than that of the head state.
2. Refactors fork choice, block production and block processing to `async` functions.
Additionally, it achieves:
- Concurrent forkchoice updates to the EL and cache pruning after a new head is selected.
- Concurrent "block packing" (attestations, etc) and execution payload retrieval during block production.
- Concurrent per-block-processing and execution payload verification during block processing.
- The `Arc`-ification of `SignedBeaconBlock` during block processing (it's never mutated, so why not?):
- I had to do this to deal with sending blocks into spawned tasks.
- Previously we were cloning the beacon block at least 2 times during each block processing, these clones are either removed or turned into cheaper `Arc` clones.
- We were also `Box`-ing and un-`Box`-ing beacon blocks as they moved throughout the networking crate. This is not a big deal, but it's nice to avoid shifting things between the stack and heap.
- Avoids cloning *all the blocks* in *every chain segment* during sync.
- It also has the potential to clean up our code where we need to pass an *owned* block around so we can send it back in the case of an error (I didn't do much of this, my PR is already big enough :sweat_smile:)
- The `BeaconChain::HeadSafetyStatus` struct was removed. It was an old relic from prior merge specs.
For motivation for this change, see https://github.com/sigp/lighthouse/pull/3244#issuecomment-1160963273
## Changes to `canonical_head` and `fork_choice`
Previously, the `BeaconChain` had two separate fields:
```
canonical_head: RwLock<Snapshot>,
fork_choice: RwLock<BeaconForkChoice>
```
Now, we have grouped these values under a single struct:
```
canonical_head: CanonicalHead {
cached_head: RwLock<Arc<Snapshot>>,
fork_choice: RwLock<BeaconForkChoice>
}
```
Apart from ergonomics, the only *actual* change here is wrapping the canonical head snapshot in an `Arc`. This means that we no longer need to hold the `cached_head` (`canonical_head`, in old terms) lock when we want to pull some values from it. This was done to avoid deadlock risks by preventing functions from acquiring (and holding) the `cached_head` and `fork_choice` locks simultaneously.
## Breaking Changes
### The `state` (root) field in the `finalized_checkpoint` SSE event
Consider the scenario where epoch `n` is just finalized, but `start_slot(n)` is skipped. There are two state roots we might in the `finalized_checkpoint` SSE event:
1. The state root of the finalized block, which is `get_block(finalized_checkpoint.root).state_root`.
4. The state root at slot of `start_slot(n)`, which would be the state from (1), but "skipped forward" through any skip slots.
Previously, Lighthouse would choose (2). However, we can see that when [Teku generates that event](https://github.com/ConsenSys/teku/blob/de2b2801c89ef5abf983d6bf37867c37fc47121f/data/beaconrestapi/src/main/java/tech/pegasys/teku/beaconrestapi/handlers/v1/events/EventSubscriptionManager.java#L171-L182) it uses [`getStateRootFromBlockRoot`](https://github.com/ConsenSys/teku/blob/de2b2801c89ef5abf983d6bf37867c37fc47121f/data/provider/src/main/java/tech/pegasys/teku/api/ChainDataProvider.java#L336-L341) which uses (1).
I have switched Lighthouse from (2) to (1). I think it's a somewhat arbitrary choice between the two, where (1) is easier to compute and is consistent with Teku.
## Notes for Reviewers
I've renamed `BeaconChain::fork_choice` to `BeaconChain::recompute_head`. Doing this helped ensure I broke all previous uses of fork choice and I also find it more descriptive. It describes an action and can't be confused with trying to get a reference to the `ForkChoice` struct.
I've changed the ordering of SSE events when a block is received. It used to be `[block, finalized, head]` and now it's `[block, head, finalized]`. It was easier this way and I don't think we were making any promises about SSE event ordering so it's not "breaking".
I've made it so fork choice will run when it's first constructed. I did this because I wanted to have a cached version of the last call to `get_head`. Ensuring `get_head` has been run *at least once* means that the cached values doesn't need to wrapped in an `Option`. This was fairly simple, it just involved passing a `slot` to the constructor so it knows *when* it's being run. When loading a fork choice from the store and a slot clock isn't handy I've just used the `slot` that was saved in the `fork_choice_store`. That seems like it would be a faithful representation of the slot when we saved it.
I added the `genesis_time: u64` to the `BeaconChain`. It's small, constant and nice to have around.
Since we're using FC for the fin/just checkpoints, we no longer get the `0x00..00` roots at genesis. You can see I had to remove a work-around in `ef-tests` here: b56be3bc2. I can't find any reason why this would be an issue, if anything I think it'll be better since the genesis-alias has caught us out a few times (0x00..00 isn't actually a real root). Edit: I did find a case where the `network` expected the 0x00..00 alias and patched it here: 3f26ac3e2.
You'll notice a lot of changes in tests. Generally, tests should be functionally equivalent. Here are the things creating the most diff-noise in tests:
- Changing tests to be `tokio::async` tests.
- Adding `.await` to fork choice, block processing and block production functions.
- Refactor of the `canonical_head` "API" provided by the `BeaconChain`. E.g., `chain.canonical_head.cached_head()` instead of `chain.canonical_head.read()`.
- Wrapping `SignedBeaconBlock` in an `Arc`.
- In the `beacon_chain/tests/block_verification`, we can't use the `lazy_static` `CHAIN_SEGMENT` variable anymore since it's generated with an async function. We just generate it in each test, not so efficient but hopefully insignificant.
I had to disable `rayon` concurrent tests in the `fork_choice` tests. This is because the use of `rayon` and `block_on` was causing a panic.
Co-authored-by: Mac L <mjladson@pm.me>
2022-07-03 05:36:50 +00:00
|
|
|
.validator_keypairs()
|
2022-03-28 07:14:13 +00:00
|
|
|
.iter()
|
|
|
|
|
.find(|kp| kp.pk == proposer_pubkey)
|
|
|
|
|
.map(|kp| kp.sk.clone())
|
|
|
|
|
.unwrap();
|
|
|
|
|
|
|
|
|
|
let bad_randao_reveal = {
|
|
|
|
|
let domain = self.chain.spec.get_domain(
|
|
|
|
|
epoch,
|
|
|
|
|
Domain::Randao,
|
|
|
|
|
&fork,
|
|
|
|
|
genesis_validators_root,
|
|
|
|
|
);
|
|
|
|
|
let message = (epoch + 1).signing_root(domain);
|
|
|
|
|
sk.sign(message).into()
|
|
|
|
|
};
|
|
|
|
|
|
|
|
|
|
// Check failure with no `verify_randao` passed.
|
|
|
|
|
self.client
|
2022-03-31 07:52:23 +00:00
|
|
|
.get_validator_blocks::<E, FullPayload<E>>(slot, &bad_randao_reveal, None)
|
2022-03-28 07:14:13 +00:00
|
|
|
.await
|
|
|
|
|
.unwrap_err();
|
|
|
|
|
|
|
|
|
|
// Check failure with `verify_randao=true`.
|
|
|
|
|
self.client
|
2022-03-31 07:52:23 +00:00
|
|
|
.get_validator_blocks_with_verify_randao::<E, FullPayload<E>>(
|
2022-03-28 07:14:13 +00:00
|
|
|
slot,
|
|
|
|
|
Some(&bad_randao_reveal),
|
|
|
|
|
None,
|
|
|
|
|
Some(true),
|
|
|
|
|
)
|
|
|
|
|
.await
|
|
|
|
|
.unwrap_err();
|
|
|
|
|
|
|
|
|
|
// Check failure with no randao reveal provided.
|
|
|
|
|
self.client
|
2022-03-31 07:52:23 +00:00
|
|
|
.get_validator_blocks_with_verify_randao::<E, FullPayload<E>>(
|
|
|
|
|
slot, None, None, None,
|
|
|
|
|
)
|
2022-03-28 07:14:13 +00:00
|
|
|
.await
|
|
|
|
|
.unwrap_err();
|
|
|
|
|
|
|
|
|
|
// Check success with `verify_randao=false`.
|
|
|
|
|
let block = self
|
|
|
|
|
.client
|
2022-03-31 07:52:23 +00:00
|
|
|
.get_validator_blocks_with_verify_randao::<E, FullPayload<E>>(
|
2022-03-28 07:14:13 +00:00
|
|
|
slot,
|
|
|
|
|
Some(&bad_randao_reveal),
|
|
|
|
|
None,
|
|
|
|
|
Some(false),
|
|
|
|
|
)
|
|
|
|
|
.await
|
|
|
|
|
.unwrap()
|
|
|
|
|
.data;
|
|
|
|
|
|
|
|
|
|
assert_eq!(block.slot(), slot);
|
|
|
|
|
self.chain.slot_clock.set_slot(slot.as_u64() + 1);
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
self
|
|
|
|
|
}
|
|
|
|
|
|
2020-09-29 03:46:54 +00:00
|
|
|
pub async fn test_get_validator_attestation_data(self) -> Self {
|
Use async code when interacting with EL (#3244)
## Overview
This rather extensive PR achieves two primary goals:
1. Uses the finalized/justified checkpoints of fork choice (FC), rather than that of the head state.
2. Refactors fork choice, block production and block processing to `async` functions.
Additionally, it achieves:
- Concurrent forkchoice updates to the EL and cache pruning after a new head is selected.
- Concurrent "block packing" (attestations, etc) and execution payload retrieval during block production.
- Concurrent per-block-processing and execution payload verification during block processing.
- The `Arc`-ification of `SignedBeaconBlock` during block processing (it's never mutated, so why not?):
- I had to do this to deal with sending blocks into spawned tasks.
- Previously we were cloning the beacon block at least 2 times during each block processing, these clones are either removed or turned into cheaper `Arc` clones.
- We were also `Box`-ing and un-`Box`-ing beacon blocks as they moved throughout the networking crate. This is not a big deal, but it's nice to avoid shifting things between the stack and heap.
- Avoids cloning *all the blocks* in *every chain segment* during sync.
- It also has the potential to clean up our code where we need to pass an *owned* block around so we can send it back in the case of an error (I didn't do much of this, my PR is already big enough :sweat_smile:)
- The `BeaconChain::HeadSafetyStatus` struct was removed. It was an old relic from prior merge specs.
For motivation for this change, see https://github.com/sigp/lighthouse/pull/3244#issuecomment-1160963273
## Changes to `canonical_head` and `fork_choice`
Previously, the `BeaconChain` had two separate fields:
```
canonical_head: RwLock<Snapshot>,
fork_choice: RwLock<BeaconForkChoice>
```
Now, we have grouped these values under a single struct:
```
canonical_head: CanonicalHead {
cached_head: RwLock<Arc<Snapshot>>,
fork_choice: RwLock<BeaconForkChoice>
}
```
Apart from ergonomics, the only *actual* change here is wrapping the canonical head snapshot in an `Arc`. This means that we no longer need to hold the `cached_head` (`canonical_head`, in old terms) lock when we want to pull some values from it. This was done to avoid deadlock risks by preventing functions from acquiring (and holding) the `cached_head` and `fork_choice` locks simultaneously.
## Breaking Changes
### The `state` (root) field in the `finalized_checkpoint` SSE event
Consider the scenario where epoch `n` is just finalized, but `start_slot(n)` is skipped. There are two state roots we might in the `finalized_checkpoint` SSE event:
1. The state root of the finalized block, which is `get_block(finalized_checkpoint.root).state_root`.
4. The state root at slot of `start_slot(n)`, which would be the state from (1), but "skipped forward" through any skip slots.
Previously, Lighthouse would choose (2). However, we can see that when [Teku generates that event](https://github.com/ConsenSys/teku/blob/de2b2801c89ef5abf983d6bf37867c37fc47121f/data/beaconrestapi/src/main/java/tech/pegasys/teku/beaconrestapi/handlers/v1/events/EventSubscriptionManager.java#L171-L182) it uses [`getStateRootFromBlockRoot`](https://github.com/ConsenSys/teku/blob/de2b2801c89ef5abf983d6bf37867c37fc47121f/data/provider/src/main/java/tech/pegasys/teku/api/ChainDataProvider.java#L336-L341) which uses (1).
I have switched Lighthouse from (2) to (1). I think it's a somewhat arbitrary choice between the two, where (1) is easier to compute and is consistent with Teku.
## Notes for Reviewers
I've renamed `BeaconChain::fork_choice` to `BeaconChain::recompute_head`. Doing this helped ensure I broke all previous uses of fork choice and I also find it more descriptive. It describes an action and can't be confused with trying to get a reference to the `ForkChoice` struct.
I've changed the ordering of SSE events when a block is received. It used to be `[block, finalized, head]` and now it's `[block, head, finalized]`. It was easier this way and I don't think we were making any promises about SSE event ordering so it's not "breaking".
I've made it so fork choice will run when it's first constructed. I did this because I wanted to have a cached version of the last call to `get_head`. Ensuring `get_head` has been run *at least once* means that the cached values doesn't need to wrapped in an `Option`. This was fairly simple, it just involved passing a `slot` to the constructor so it knows *when* it's being run. When loading a fork choice from the store and a slot clock isn't handy I've just used the `slot` that was saved in the `fork_choice_store`. That seems like it would be a faithful representation of the slot when we saved it.
I added the `genesis_time: u64` to the `BeaconChain`. It's small, constant and nice to have around.
Since we're using FC for the fin/just checkpoints, we no longer get the `0x00..00` roots at genesis. You can see I had to remove a work-around in `ef-tests` here: b56be3bc2. I can't find any reason why this would be an issue, if anything I think it'll be better since the genesis-alias has caught us out a few times (0x00..00 isn't actually a real root). Edit: I did find a case where the `network` expected the 0x00..00 alias and patched it here: 3f26ac3e2.
You'll notice a lot of changes in tests. Generally, tests should be functionally equivalent. Here are the things creating the most diff-noise in tests:
- Changing tests to be `tokio::async` tests.
- Adding `.await` to fork choice, block processing and block production functions.
- Refactor of the `canonical_head` "API" provided by the `BeaconChain`. E.g., `chain.canonical_head.cached_head()` instead of `chain.canonical_head.read()`.
- Wrapping `SignedBeaconBlock` in an `Arc`.
- In the `beacon_chain/tests/block_verification`, we can't use the `lazy_static` `CHAIN_SEGMENT` variable anymore since it's generated with an async function. We just generate it in each test, not so efficient but hopefully insignificant.
I had to disable `rayon` concurrent tests in the `fork_choice` tests. This is because the use of `rayon` and `block_on` was causing a panic.
Co-authored-by: Mac L <mjladson@pm.me>
2022-07-03 05:36:50 +00:00
|
|
|
let mut state = self.chain.head_beacon_state_cloned();
|
2021-07-09 06:15:32 +00:00
|
|
|
let slot = state.slot();
|
2020-09-29 03:46:54 +00:00
|
|
|
state
|
|
|
|
|
.build_committee_cache(RelativeEpoch::Current, &self.chain.spec)
|
|
|
|
|
.unwrap();
|
|
|
|
|
|
|
|
|
|
for index in 0..state.get_committee_count_at_slot(slot).unwrap() {
|
|
|
|
|
let result = self
|
|
|
|
|
.client
|
|
|
|
|
.get_validator_attestation_data(slot, index)
|
|
|
|
|
.await
|
|
|
|
|
.unwrap()
|
|
|
|
|
.data;
|
|
|
|
|
|
|
|
|
|
let expected = self
|
|
|
|
|
.chain
|
|
|
|
|
.produce_unaggregated_attestation(slot, index)
|
|
|
|
|
.unwrap()
|
|
|
|
|
.data;
|
|
|
|
|
|
|
|
|
|
assert_eq!(result, expected);
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
self
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
pub async fn test_get_validator_aggregate_attestation(self) -> Self {
|
|
|
|
|
let attestation = self
|
|
|
|
|
.chain
|
|
|
|
|
.head_beacon_block()
|
2021-07-09 06:15:32 +00:00
|
|
|
.message()
|
|
|
|
|
.body()
|
|
|
|
|
.attestations()[0]
|
2020-09-29 03:46:54 +00:00
|
|
|
.clone();
|
|
|
|
|
|
|
|
|
|
let result = self
|
|
|
|
|
.client
|
|
|
|
|
.get_validator_aggregate_attestation(
|
|
|
|
|
attestation.data.slot,
|
|
|
|
|
attestation.data.tree_hash_root(),
|
|
|
|
|
)
|
|
|
|
|
.await
|
|
|
|
|
.unwrap()
|
|
|
|
|
.unwrap()
|
|
|
|
|
.data;
|
|
|
|
|
|
|
|
|
|
let expected = attestation;
|
|
|
|
|
|
|
|
|
|
assert_eq!(result, expected);
|
|
|
|
|
|
|
|
|
|
self
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
pub async fn get_aggregate(&mut self) -> SignedAggregateAndProof<E> {
|
|
|
|
|
let slot = self.chain.slot().unwrap();
|
|
|
|
|
let epoch = self.chain.epoch().unwrap();
|
|
|
|
|
|
Use async code when interacting with EL (#3244)
## Overview
This rather extensive PR achieves two primary goals:
1. Uses the finalized/justified checkpoints of fork choice (FC), rather than that of the head state.
2. Refactors fork choice, block production and block processing to `async` functions.
Additionally, it achieves:
- Concurrent forkchoice updates to the EL and cache pruning after a new head is selected.
- Concurrent "block packing" (attestations, etc) and execution payload retrieval during block production.
- Concurrent per-block-processing and execution payload verification during block processing.
- The `Arc`-ification of `SignedBeaconBlock` during block processing (it's never mutated, so why not?):
- I had to do this to deal with sending blocks into spawned tasks.
- Previously we were cloning the beacon block at least 2 times during each block processing, these clones are either removed or turned into cheaper `Arc` clones.
- We were also `Box`-ing and un-`Box`-ing beacon blocks as they moved throughout the networking crate. This is not a big deal, but it's nice to avoid shifting things between the stack and heap.
- Avoids cloning *all the blocks* in *every chain segment* during sync.
- It also has the potential to clean up our code where we need to pass an *owned* block around so we can send it back in the case of an error (I didn't do much of this, my PR is already big enough :sweat_smile:)
- The `BeaconChain::HeadSafetyStatus` struct was removed. It was an old relic from prior merge specs.
For motivation for this change, see https://github.com/sigp/lighthouse/pull/3244#issuecomment-1160963273
## Changes to `canonical_head` and `fork_choice`
Previously, the `BeaconChain` had two separate fields:
```
canonical_head: RwLock<Snapshot>,
fork_choice: RwLock<BeaconForkChoice>
```
Now, we have grouped these values under a single struct:
```
canonical_head: CanonicalHead {
cached_head: RwLock<Arc<Snapshot>>,
fork_choice: RwLock<BeaconForkChoice>
}
```
Apart from ergonomics, the only *actual* change here is wrapping the canonical head snapshot in an `Arc`. This means that we no longer need to hold the `cached_head` (`canonical_head`, in old terms) lock when we want to pull some values from it. This was done to avoid deadlock risks by preventing functions from acquiring (and holding) the `cached_head` and `fork_choice` locks simultaneously.
## Breaking Changes
### The `state` (root) field in the `finalized_checkpoint` SSE event
Consider the scenario where epoch `n` is just finalized, but `start_slot(n)` is skipped. There are two state roots we might in the `finalized_checkpoint` SSE event:
1. The state root of the finalized block, which is `get_block(finalized_checkpoint.root).state_root`.
4. The state root at slot of `start_slot(n)`, which would be the state from (1), but "skipped forward" through any skip slots.
Previously, Lighthouse would choose (2). However, we can see that when [Teku generates that event](https://github.com/ConsenSys/teku/blob/de2b2801c89ef5abf983d6bf37867c37fc47121f/data/beaconrestapi/src/main/java/tech/pegasys/teku/beaconrestapi/handlers/v1/events/EventSubscriptionManager.java#L171-L182) it uses [`getStateRootFromBlockRoot`](https://github.com/ConsenSys/teku/blob/de2b2801c89ef5abf983d6bf37867c37fc47121f/data/provider/src/main/java/tech/pegasys/teku/api/ChainDataProvider.java#L336-L341) which uses (1).
I have switched Lighthouse from (2) to (1). I think it's a somewhat arbitrary choice between the two, where (1) is easier to compute and is consistent with Teku.
## Notes for Reviewers
I've renamed `BeaconChain::fork_choice` to `BeaconChain::recompute_head`. Doing this helped ensure I broke all previous uses of fork choice and I also find it more descriptive. It describes an action and can't be confused with trying to get a reference to the `ForkChoice` struct.
I've changed the ordering of SSE events when a block is received. It used to be `[block, finalized, head]` and now it's `[block, head, finalized]`. It was easier this way and I don't think we were making any promises about SSE event ordering so it's not "breaking".
I've made it so fork choice will run when it's first constructed. I did this because I wanted to have a cached version of the last call to `get_head`. Ensuring `get_head` has been run *at least once* means that the cached values doesn't need to wrapped in an `Option`. This was fairly simple, it just involved passing a `slot` to the constructor so it knows *when* it's being run. When loading a fork choice from the store and a slot clock isn't handy I've just used the `slot` that was saved in the `fork_choice_store`. That seems like it would be a faithful representation of the slot when we saved it.
I added the `genesis_time: u64` to the `BeaconChain`. It's small, constant and nice to have around.
Since we're using FC for the fin/just checkpoints, we no longer get the `0x00..00` roots at genesis. You can see I had to remove a work-around in `ef-tests` here: b56be3bc2. I can't find any reason why this would be an issue, if anything I think it'll be better since the genesis-alias has caught us out a few times (0x00..00 isn't actually a real root). Edit: I did find a case where the `network` expected the 0x00..00 alias and patched it here: 3f26ac3e2.
You'll notice a lot of changes in tests. Generally, tests should be functionally equivalent. Here are the things creating the most diff-noise in tests:
- Changing tests to be `tokio::async` tests.
- Adding `.await` to fork choice, block processing and block production functions.
- Refactor of the `canonical_head` "API" provided by the `BeaconChain`. E.g., `chain.canonical_head.cached_head()` instead of `chain.canonical_head.read()`.
- Wrapping `SignedBeaconBlock` in an `Arc`.
- In the `beacon_chain/tests/block_verification`, we can't use the `lazy_static` `CHAIN_SEGMENT` variable anymore since it's generated with an async function. We just generate it in each test, not so efficient but hopefully insignificant.
I had to disable `rayon` concurrent tests in the `fork_choice` tests. This is because the use of `rayon` and `block_on` was causing a panic.
Co-authored-by: Mac L <mjladson@pm.me>
2022-07-03 05:36:50 +00:00
|
|
|
let mut head = self.chain.head_snapshot().as_ref().clone();
|
2020-09-29 03:46:54 +00:00
|
|
|
while head.beacon_state.current_epoch() < epoch {
|
|
|
|
|
per_slot_processing(&mut head.beacon_state, None, &self.chain.spec).unwrap();
|
|
|
|
|
}
|
|
|
|
|
head.beacon_state
|
|
|
|
|
.build_committee_cache(RelativeEpoch::Current, &self.chain.spec)
|
|
|
|
|
.unwrap();
|
|
|
|
|
|
|
|
|
|
let committee_len = head.beacon_state.get_committee_count_at_slot(slot).unwrap();
|
2021-07-09 06:15:32 +00:00
|
|
|
let fork = head.beacon_state.fork();
|
2020-09-29 03:46:54 +00:00
|
|
|
let genesis_validators_root = self.chain.genesis_validators_root;
|
|
|
|
|
|
2020-11-09 23:13:56 +00:00
|
|
|
let duties = self
|
|
|
|
|
.client
|
|
|
|
|
.post_validator_duties_attester(
|
|
|
|
|
epoch,
|
Use async code when interacting with EL (#3244)
## Overview
This rather extensive PR achieves two primary goals:
1. Uses the finalized/justified checkpoints of fork choice (FC), rather than that of the head state.
2. Refactors fork choice, block production and block processing to `async` functions.
Additionally, it achieves:
- Concurrent forkchoice updates to the EL and cache pruning after a new head is selected.
- Concurrent "block packing" (attestations, etc) and execution payload retrieval during block production.
- Concurrent per-block-processing and execution payload verification during block processing.
- The `Arc`-ification of `SignedBeaconBlock` during block processing (it's never mutated, so why not?):
- I had to do this to deal with sending blocks into spawned tasks.
- Previously we were cloning the beacon block at least 2 times during each block processing, these clones are either removed or turned into cheaper `Arc` clones.
- We were also `Box`-ing and un-`Box`-ing beacon blocks as they moved throughout the networking crate. This is not a big deal, but it's nice to avoid shifting things between the stack and heap.
- Avoids cloning *all the blocks* in *every chain segment* during sync.
- It also has the potential to clean up our code where we need to pass an *owned* block around so we can send it back in the case of an error (I didn't do much of this, my PR is already big enough :sweat_smile:)
- The `BeaconChain::HeadSafetyStatus` struct was removed. It was an old relic from prior merge specs.
For motivation for this change, see https://github.com/sigp/lighthouse/pull/3244#issuecomment-1160963273
## Changes to `canonical_head` and `fork_choice`
Previously, the `BeaconChain` had two separate fields:
```
canonical_head: RwLock<Snapshot>,
fork_choice: RwLock<BeaconForkChoice>
```
Now, we have grouped these values under a single struct:
```
canonical_head: CanonicalHead {
cached_head: RwLock<Arc<Snapshot>>,
fork_choice: RwLock<BeaconForkChoice>
}
```
Apart from ergonomics, the only *actual* change here is wrapping the canonical head snapshot in an `Arc`. This means that we no longer need to hold the `cached_head` (`canonical_head`, in old terms) lock when we want to pull some values from it. This was done to avoid deadlock risks by preventing functions from acquiring (and holding) the `cached_head` and `fork_choice` locks simultaneously.
## Breaking Changes
### The `state` (root) field in the `finalized_checkpoint` SSE event
Consider the scenario where epoch `n` is just finalized, but `start_slot(n)` is skipped. There are two state roots we might in the `finalized_checkpoint` SSE event:
1. The state root of the finalized block, which is `get_block(finalized_checkpoint.root).state_root`.
4. The state root at slot of `start_slot(n)`, which would be the state from (1), but "skipped forward" through any skip slots.
Previously, Lighthouse would choose (2). However, we can see that when [Teku generates that event](https://github.com/ConsenSys/teku/blob/de2b2801c89ef5abf983d6bf37867c37fc47121f/data/beaconrestapi/src/main/java/tech/pegasys/teku/beaconrestapi/handlers/v1/events/EventSubscriptionManager.java#L171-L182) it uses [`getStateRootFromBlockRoot`](https://github.com/ConsenSys/teku/blob/de2b2801c89ef5abf983d6bf37867c37fc47121f/data/provider/src/main/java/tech/pegasys/teku/api/ChainDataProvider.java#L336-L341) which uses (1).
I have switched Lighthouse from (2) to (1). I think it's a somewhat arbitrary choice between the two, where (1) is easier to compute and is consistent with Teku.
## Notes for Reviewers
I've renamed `BeaconChain::fork_choice` to `BeaconChain::recompute_head`. Doing this helped ensure I broke all previous uses of fork choice and I also find it more descriptive. It describes an action and can't be confused with trying to get a reference to the `ForkChoice` struct.
I've changed the ordering of SSE events when a block is received. It used to be `[block, finalized, head]` and now it's `[block, head, finalized]`. It was easier this way and I don't think we were making any promises about SSE event ordering so it's not "breaking".
I've made it so fork choice will run when it's first constructed. I did this because I wanted to have a cached version of the last call to `get_head`. Ensuring `get_head` has been run *at least once* means that the cached values doesn't need to wrapped in an `Option`. This was fairly simple, it just involved passing a `slot` to the constructor so it knows *when* it's being run. When loading a fork choice from the store and a slot clock isn't handy I've just used the `slot` that was saved in the `fork_choice_store`. That seems like it would be a faithful representation of the slot when we saved it.
I added the `genesis_time: u64` to the `BeaconChain`. It's small, constant and nice to have around.
Since we're using FC for the fin/just checkpoints, we no longer get the `0x00..00` roots at genesis. You can see I had to remove a work-around in `ef-tests` here: b56be3bc2. I can't find any reason why this would be an issue, if anything I think it'll be better since the genesis-alias has caught us out a few times (0x00..00 isn't actually a real root). Edit: I did find a case where the `network` expected the 0x00..00 alias and patched it here: 3f26ac3e2.
You'll notice a lot of changes in tests. Generally, tests should be functionally equivalent. Here are the things creating the most diff-noise in tests:
- Changing tests to be `tokio::async` tests.
- Adding `.await` to fork choice, block processing and block production functions.
- Refactor of the `canonical_head` "API" provided by the `BeaconChain`. E.g., `chain.canonical_head.cached_head()` instead of `chain.canonical_head.read()`.
- Wrapping `SignedBeaconBlock` in an `Arc`.
- In the `beacon_chain/tests/block_verification`, we can't use the `lazy_static` `CHAIN_SEGMENT` variable anymore since it's generated with an async function. We just generate it in each test, not so efficient but hopefully insignificant.
I had to disable `rayon` concurrent tests in the `fork_choice` tests. This is because the use of `rayon` and `block_on` was causing a panic.
Co-authored-by: Mac L <mjladson@pm.me>
2022-07-03 05:36:50 +00:00
|
|
|
(0..self.validator_keypairs().len() as u64)
|
2020-11-09 23:13:56 +00:00
|
|
|
.collect::<Vec<u64>>()
|
|
|
|
|
.as_slice(),
|
2020-09-29 03:46:54 +00:00
|
|
|
)
|
2020-11-09 23:13:56 +00:00
|
|
|
.await
|
|
|
|
|
.unwrap()
|
|
|
|
|
.data;
|
2020-09-29 03:46:54 +00:00
|
|
|
|
|
|
|
|
let (i, kp, duty, proof) = self
|
Use async code when interacting with EL (#3244)
## Overview
This rather extensive PR achieves two primary goals:
1. Uses the finalized/justified checkpoints of fork choice (FC), rather than that of the head state.
2. Refactors fork choice, block production and block processing to `async` functions.
Additionally, it achieves:
- Concurrent forkchoice updates to the EL and cache pruning after a new head is selected.
- Concurrent "block packing" (attestations, etc) and execution payload retrieval during block production.
- Concurrent per-block-processing and execution payload verification during block processing.
- The `Arc`-ification of `SignedBeaconBlock` during block processing (it's never mutated, so why not?):
- I had to do this to deal with sending blocks into spawned tasks.
- Previously we were cloning the beacon block at least 2 times during each block processing, these clones are either removed or turned into cheaper `Arc` clones.
- We were also `Box`-ing and un-`Box`-ing beacon blocks as they moved throughout the networking crate. This is not a big deal, but it's nice to avoid shifting things between the stack and heap.
- Avoids cloning *all the blocks* in *every chain segment* during sync.
- It also has the potential to clean up our code where we need to pass an *owned* block around so we can send it back in the case of an error (I didn't do much of this, my PR is already big enough :sweat_smile:)
- The `BeaconChain::HeadSafetyStatus` struct was removed. It was an old relic from prior merge specs.
For motivation for this change, see https://github.com/sigp/lighthouse/pull/3244#issuecomment-1160963273
## Changes to `canonical_head` and `fork_choice`
Previously, the `BeaconChain` had two separate fields:
```
canonical_head: RwLock<Snapshot>,
fork_choice: RwLock<BeaconForkChoice>
```
Now, we have grouped these values under a single struct:
```
canonical_head: CanonicalHead {
cached_head: RwLock<Arc<Snapshot>>,
fork_choice: RwLock<BeaconForkChoice>
}
```
Apart from ergonomics, the only *actual* change here is wrapping the canonical head snapshot in an `Arc`. This means that we no longer need to hold the `cached_head` (`canonical_head`, in old terms) lock when we want to pull some values from it. This was done to avoid deadlock risks by preventing functions from acquiring (and holding) the `cached_head` and `fork_choice` locks simultaneously.
## Breaking Changes
### The `state` (root) field in the `finalized_checkpoint` SSE event
Consider the scenario where epoch `n` is just finalized, but `start_slot(n)` is skipped. There are two state roots we might in the `finalized_checkpoint` SSE event:
1. The state root of the finalized block, which is `get_block(finalized_checkpoint.root).state_root`.
4. The state root at slot of `start_slot(n)`, which would be the state from (1), but "skipped forward" through any skip slots.
Previously, Lighthouse would choose (2). However, we can see that when [Teku generates that event](https://github.com/ConsenSys/teku/blob/de2b2801c89ef5abf983d6bf37867c37fc47121f/data/beaconrestapi/src/main/java/tech/pegasys/teku/beaconrestapi/handlers/v1/events/EventSubscriptionManager.java#L171-L182) it uses [`getStateRootFromBlockRoot`](https://github.com/ConsenSys/teku/blob/de2b2801c89ef5abf983d6bf37867c37fc47121f/data/provider/src/main/java/tech/pegasys/teku/api/ChainDataProvider.java#L336-L341) which uses (1).
I have switched Lighthouse from (2) to (1). I think it's a somewhat arbitrary choice between the two, where (1) is easier to compute and is consistent with Teku.
## Notes for Reviewers
I've renamed `BeaconChain::fork_choice` to `BeaconChain::recompute_head`. Doing this helped ensure I broke all previous uses of fork choice and I also find it more descriptive. It describes an action and can't be confused with trying to get a reference to the `ForkChoice` struct.
I've changed the ordering of SSE events when a block is received. It used to be `[block, finalized, head]` and now it's `[block, head, finalized]`. It was easier this way and I don't think we were making any promises about SSE event ordering so it's not "breaking".
I've made it so fork choice will run when it's first constructed. I did this because I wanted to have a cached version of the last call to `get_head`. Ensuring `get_head` has been run *at least once* means that the cached values doesn't need to wrapped in an `Option`. This was fairly simple, it just involved passing a `slot` to the constructor so it knows *when* it's being run. When loading a fork choice from the store and a slot clock isn't handy I've just used the `slot` that was saved in the `fork_choice_store`. That seems like it would be a faithful representation of the slot when we saved it.
I added the `genesis_time: u64` to the `BeaconChain`. It's small, constant and nice to have around.
Since we're using FC for the fin/just checkpoints, we no longer get the `0x00..00` roots at genesis. You can see I had to remove a work-around in `ef-tests` here: b56be3bc2. I can't find any reason why this would be an issue, if anything I think it'll be better since the genesis-alias has caught us out a few times (0x00..00 isn't actually a real root). Edit: I did find a case where the `network` expected the 0x00..00 alias and patched it here: 3f26ac3e2.
You'll notice a lot of changes in tests. Generally, tests should be functionally equivalent. Here are the things creating the most diff-noise in tests:
- Changing tests to be `tokio::async` tests.
- Adding `.await` to fork choice, block processing and block production functions.
- Refactor of the `canonical_head` "API" provided by the `BeaconChain`. E.g., `chain.canonical_head.cached_head()` instead of `chain.canonical_head.read()`.
- Wrapping `SignedBeaconBlock` in an `Arc`.
- In the `beacon_chain/tests/block_verification`, we can't use the `lazy_static` `CHAIN_SEGMENT` variable anymore since it's generated with an async function. We just generate it in each test, not so efficient but hopefully insignificant.
I had to disable `rayon` concurrent tests in the `fork_choice` tests. This is because the use of `rayon` and `block_on` was causing a panic.
Co-authored-by: Mac L <mjladson@pm.me>
2022-07-03 05:36:50 +00:00
|
|
|
.validator_keypairs()
|
2020-09-29 03:46:54 +00:00
|
|
|
.iter()
|
|
|
|
|
.enumerate()
|
|
|
|
|
.find_map(|(i, kp)| {
|
|
|
|
|
let duty = duties[i].clone();
|
|
|
|
|
|
|
|
|
|
let proof = SelectionProof::new::<E>(
|
|
|
|
|
duty.slot,
|
|
|
|
|
&kp.sk,
|
|
|
|
|
&fork,
|
|
|
|
|
genesis_validators_root,
|
|
|
|
|
&self.chain.spec,
|
|
|
|
|
);
|
|
|
|
|
|
|
|
|
|
if proof
|
|
|
|
|
.is_aggregator(committee_len as usize, &self.chain.spec)
|
|
|
|
|
.unwrap()
|
|
|
|
|
{
|
|
|
|
|
Some((i, kp, duty, proof))
|
|
|
|
|
} else {
|
|
|
|
|
None
|
|
|
|
|
}
|
|
|
|
|
})
|
|
|
|
|
.expect("there is at least one aggregator for this epoch")
|
|
|
|
|
.clone();
|
|
|
|
|
|
|
|
|
|
if duty.slot > slot {
|
|
|
|
|
self.chain.slot_clock.set_slot(duty.slot.into());
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
let attestation_data = self
|
|
|
|
|
.client
|
|
|
|
|
.get_validator_attestation_data(duty.slot, duty.committee_index)
|
|
|
|
|
.await
|
|
|
|
|
.unwrap()
|
|
|
|
|
.data;
|
|
|
|
|
|
|
|
|
|
let mut attestation = Attestation {
|
|
|
|
|
aggregation_bits: BitList::with_capacity(duty.committee_length as usize).unwrap(),
|
|
|
|
|
data: attestation_data,
|
|
|
|
|
signature: AggregateSignature::infinity(),
|
|
|
|
|
};
|
|
|
|
|
|
|
|
|
|
attestation
|
|
|
|
|
.sign(
|
|
|
|
|
&kp.sk,
|
|
|
|
|
duty.validator_committee_index as usize,
|
|
|
|
|
&fork,
|
|
|
|
|
genesis_validators_root,
|
|
|
|
|
&self.chain.spec,
|
|
|
|
|
)
|
|
|
|
|
.unwrap();
|
|
|
|
|
|
|
|
|
|
SignedAggregateAndProof::from_aggregate(
|
|
|
|
|
i as u64,
|
|
|
|
|
attestation,
|
|
|
|
|
Some(proof),
|
|
|
|
|
&kp.sk,
|
|
|
|
|
&fork,
|
|
|
|
|
genesis_validators_root,
|
|
|
|
|
&self.chain.spec,
|
|
|
|
|
)
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
pub async fn test_get_validator_aggregate_and_proofs_valid(mut self) -> Self {
|
|
|
|
|
let aggregate = self.get_aggregate().await;
|
|
|
|
|
|
|
|
|
|
self.client
|
2020-11-09 23:13:56 +00:00
|
|
|
.post_validator_aggregate_and_proof::<E>(&[aggregate])
|
2020-09-29 03:46:54 +00:00
|
|
|
.await
|
|
|
|
|
.unwrap();
|
|
|
|
|
|
2021-02-10 23:29:49 +00:00
|
|
|
assert!(self.network_rx.recv().await.is_some());
|
2020-09-29 03:46:54 +00:00
|
|
|
|
|
|
|
|
self
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
pub async fn test_get_validator_aggregate_and_proofs_invalid(mut self) -> Self {
|
|
|
|
|
let mut aggregate = self.get_aggregate().await;
|
|
|
|
|
|
|
|
|
|
aggregate.message.aggregate.data.slot += 1;
|
|
|
|
|
|
|
|
|
|
self.client
|
2020-11-09 23:13:56 +00:00
|
|
|
.post_validator_aggregate_and_proof::<E>(&[aggregate])
|
2020-09-29 03:46:54 +00:00
|
|
|
.await
|
|
|
|
|
.unwrap_err();
|
|
|
|
|
|
2021-02-10 23:29:49 +00:00
|
|
|
assert!(self.network_rx.recv().now_or_never().is_none());
|
2020-09-29 03:46:54 +00:00
|
|
|
|
|
|
|
|
self
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
pub async fn test_get_validator_beacon_committee_subscriptions(mut self) -> Self {
|
|
|
|
|
let subscription = BeaconCommitteeSubscription {
|
|
|
|
|
validator_index: 0,
|
|
|
|
|
committee_index: 0,
|
|
|
|
|
committees_at_slot: 1,
|
|
|
|
|
slot: Slot::new(1),
|
|
|
|
|
is_aggregator: true,
|
|
|
|
|
};
|
|
|
|
|
|
|
|
|
|
self.client
|
|
|
|
|
.post_validator_beacon_committee_subscriptions(&[subscription])
|
|
|
|
|
.await
|
|
|
|
|
.unwrap();
|
|
|
|
|
|
2021-02-10 23:29:49 +00:00
|
|
|
self.network_rx.recv().now_or_never().unwrap();
|
2020-09-29 03:46:54 +00:00
|
|
|
|
|
|
|
|
self
|
|
|
|
|
}
|
|
|
|
|
|
2022-06-30 00:49:21 +00:00
|
|
|
pub async fn test_post_validator_register_validator(self) -> Self {
|
|
|
|
|
let mut registrations = vec![];
|
|
|
|
|
let mut fee_recipients = vec![];
|
|
|
|
|
|
Use async code when interacting with EL (#3244)
## Overview
This rather extensive PR achieves two primary goals:
1. Uses the finalized/justified checkpoints of fork choice (FC), rather than that of the head state.
2. Refactors fork choice, block production and block processing to `async` functions.
Additionally, it achieves:
- Concurrent forkchoice updates to the EL and cache pruning after a new head is selected.
- Concurrent "block packing" (attestations, etc) and execution payload retrieval during block production.
- Concurrent per-block-processing and execution payload verification during block processing.
- The `Arc`-ification of `SignedBeaconBlock` during block processing (it's never mutated, so why not?):
- I had to do this to deal with sending blocks into spawned tasks.
- Previously we were cloning the beacon block at least 2 times during each block processing, these clones are either removed or turned into cheaper `Arc` clones.
- We were also `Box`-ing and un-`Box`-ing beacon blocks as they moved throughout the networking crate. This is not a big deal, but it's nice to avoid shifting things between the stack and heap.
- Avoids cloning *all the blocks* in *every chain segment* during sync.
- It also has the potential to clean up our code where we need to pass an *owned* block around so we can send it back in the case of an error (I didn't do much of this, my PR is already big enough :sweat_smile:)
- The `BeaconChain::HeadSafetyStatus` struct was removed. It was an old relic from prior merge specs.
For motivation for this change, see https://github.com/sigp/lighthouse/pull/3244#issuecomment-1160963273
## Changes to `canonical_head` and `fork_choice`
Previously, the `BeaconChain` had two separate fields:
```
canonical_head: RwLock<Snapshot>,
fork_choice: RwLock<BeaconForkChoice>
```
Now, we have grouped these values under a single struct:
```
canonical_head: CanonicalHead {
cached_head: RwLock<Arc<Snapshot>>,
fork_choice: RwLock<BeaconForkChoice>
}
```
Apart from ergonomics, the only *actual* change here is wrapping the canonical head snapshot in an `Arc`. This means that we no longer need to hold the `cached_head` (`canonical_head`, in old terms) lock when we want to pull some values from it. This was done to avoid deadlock risks by preventing functions from acquiring (and holding) the `cached_head` and `fork_choice` locks simultaneously.
## Breaking Changes
### The `state` (root) field in the `finalized_checkpoint` SSE event
Consider the scenario where epoch `n` is just finalized, but `start_slot(n)` is skipped. There are two state roots we might in the `finalized_checkpoint` SSE event:
1. The state root of the finalized block, which is `get_block(finalized_checkpoint.root).state_root`.
4. The state root at slot of `start_slot(n)`, which would be the state from (1), but "skipped forward" through any skip slots.
Previously, Lighthouse would choose (2). However, we can see that when [Teku generates that event](https://github.com/ConsenSys/teku/blob/de2b2801c89ef5abf983d6bf37867c37fc47121f/data/beaconrestapi/src/main/java/tech/pegasys/teku/beaconrestapi/handlers/v1/events/EventSubscriptionManager.java#L171-L182) it uses [`getStateRootFromBlockRoot`](https://github.com/ConsenSys/teku/blob/de2b2801c89ef5abf983d6bf37867c37fc47121f/data/provider/src/main/java/tech/pegasys/teku/api/ChainDataProvider.java#L336-L341) which uses (1).
I have switched Lighthouse from (2) to (1). I think it's a somewhat arbitrary choice between the two, where (1) is easier to compute and is consistent with Teku.
## Notes for Reviewers
I've renamed `BeaconChain::fork_choice` to `BeaconChain::recompute_head`. Doing this helped ensure I broke all previous uses of fork choice and I also find it more descriptive. It describes an action and can't be confused with trying to get a reference to the `ForkChoice` struct.
I've changed the ordering of SSE events when a block is received. It used to be `[block, finalized, head]` and now it's `[block, head, finalized]`. It was easier this way and I don't think we were making any promises about SSE event ordering so it's not "breaking".
I've made it so fork choice will run when it's first constructed. I did this because I wanted to have a cached version of the last call to `get_head`. Ensuring `get_head` has been run *at least once* means that the cached values doesn't need to wrapped in an `Option`. This was fairly simple, it just involved passing a `slot` to the constructor so it knows *when* it's being run. When loading a fork choice from the store and a slot clock isn't handy I've just used the `slot` that was saved in the `fork_choice_store`. That seems like it would be a faithful representation of the slot when we saved it.
I added the `genesis_time: u64` to the `BeaconChain`. It's small, constant and nice to have around.
Since we're using FC for the fin/just checkpoints, we no longer get the `0x00..00` roots at genesis. You can see I had to remove a work-around in `ef-tests` here: b56be3bc2. I can't find any reason why this would be an issue, if anything I think it'll be better since the genesis-alias has caught us out a few times (0x00..00 isn't actually a real root). Edit: I did find a case where the `network` expected the 0x00..00 alias and patched it here: 3f26ac3e2.
You'll notice a lot of changes in tests. Generally, tests should be functionally equivalent. Here are the things creating the most diff-noise in tests:
- Changing tests to be `tokio::async` tests.
- Adding `.await` to fork choice, block processing and block production functions.
- Refactor of the `canonical_head` "API" provided by the `BeaconChain`. E.g., `chain.canonical_head.cached_head()` instead of `chain.canonical_head.read()`.
- Wrapping `SignedBeaconBlock` in an `Arc`.
- In the `beacon_chain/tests/block_verification`, we can't use the `lazy_static` `CHAIN_SEGMENT` variable anymore since it's generated with an async function. We just generate it in each test, not so efficient but hopefully insignificant.
I had to disable `rayon` concurrent tests in the `fork_choice` tests. This is because the use of `rayon` and `block_on` was causing a panic.
Co-authored-by: Mac L <mjladson@pm.me>
2022-07-03 05:36:50 +00:00
|
|
|
let fork = self.chain.head_snapshot().beacon_state.fork();
|
2022-06-30 00:49:21 +00:00
|
|
|
|
Use async code when interacting with EL (#3244)
## Overview
This rather extensive PR achieves two primary goals:
1. Uses the finalized/justified checkpoints of fork choice (FC), rather than that of the head state.
2. Refactors fork choice, block production and block processing to `async` functions.
Additionally, it achieves:
- Concurrent forkchoice updates to the EL and cache pruning after a new head is selected.
- Concurrent "block packing" (attestations, etc) and execution payload retrieval during block production.
- Concurrent per-block-processing and execution payload verification during block processing.
- The `Arc`-ification of `SignedBeaconBlock` during block processing (it's never mutated, so why not?):
- I had to do this to deal with sending blocks into spawned tasks.
- Previously we were cloning the beacon block at least 2 times during each block processing, these clones are either removed or turned into cheaper `Arc` clones.
- We were also `Box`-ing and un-`Box`-ing beacon blocks as they moved throughout the networking crate. This is not a big deal, but it's nice to avoid shifting things between the stack and heap.
- Avoids cloning *all the blocks* in *every chain segment* during sync.
- It also has the potential to clean up our code where we need to pass an *owned* block around so we can send it back in the case of an error (I didn't do much of this, my PR is already big enough :sweat_smile:)
- The `BeaconChain::HeadSafetyStatus` struct was removed. It was an old relic from prior merge specs.
For motivation for this change, see https://github.com/sigp/lighthouse/pull/3244#issuecomment-1160963273
## Changes to `canonical_head` and `fork_choice`
Previously, the `BeaconChain` had two separate fields:
```
canonical_head: RwLock<Snapshot>,
fork_choice: RwLock<BeaconForkChoice>
```
Now, we have grouped these values under a single struct:
```
canonical_head: CanonicalHead {
cached_head: RwLock<Arc<Snapshot>>,
fork_choice: RwLock<BeaconForkChoice>
}
```
Apart from ergonomics, the only *actual* change here is wrapping the canonical head snapshot in an `Arc`. This means that we no longer need to hold the `cached_head` (`canonical_head`, in old terms) lock when we want to pull some values from it. This was done to avoid deadlock risks by preventing functions from acquiring (and holding) the `cached_head` and `fork_choice` locks simultaneously.
## Breaking Changes
### The `state` (root) field in the `finalized_checkpoint` SSE event
Consider the scenario where epoch `n` is just finalized, but `start_slot(n)` is skipped. There are two state roots we might in the `finalized_checkpoint` SSE event:
1. The state root of the finalized block, which is `get_block(finalized_checkpoint.root).state_root`.
4. The state root at slot of `start_slot(n)`, which would be the state from (1), but "skipped forward" through any skip slots.
Previously, Lighthouse would choose (2). However, we can see that when [Teku generates that event](https://github.com/ConsenSys/teku/blob/de2b2801c89ef5abf983d6bf37867c37fc47121f/data/beaconrestapi/src/main/java/tech/pegasys/teku/beaconrestapi/handlers/v1/events/EventSubscriptionManager.java#L171-L182) it uses [`getStateRootFromBlockRoot`](https://github.com/ConsenSys/teku/blob/de2b2801c89ef5abf983d6bf37867c37fc47121f/data/provider/src/main/java/tech/pegasys/teku/api/ChainDataProvider.java#L336-L341) which uses (1).
I have switched Lighthouse from (2) to (1). I think it's a somewhat arbitrary choice between the two, where (1) is easier to compute and is consistent with Teku.
## Notes for Reviewers
I've renamed `BeaconChain::fork_choice` to `BeaconChain::recompute_head`. Doing this helped ensure I broke all previous uses of fork choice and I also find it more descriptive. It describes an action and can't be confused with trying to get a reference to the `ForkChoice` struct.
I've changed the ordering of SSE events when a block is received. It used to be `[block, finalized, head]` and now it's `[block, head, finalized]`. It was easier this way and I don't think we were making any promises about SSE event ordering so it's not "breaking".
I've made it so fork choice will run when it's first constructed. I did this because I wanted to have a cached version of the last call to `get_head`. Ensuring `get_head` has been run *at least once* means that the cached values doesn't need to wrapped in an `Option`. This was fairly simple, it just involved passing a `slot` to the constructor so it knows *when* it's being run. When loading a fork choice from the store and a slot clock isn't handy I've just used the `slot` that was saved in the `fork_choice_store`. That seems like it would be a faithful representation of the slot when we saved it.
I added the `genesis_time: u64` to the `BeaconChain`. It's small, constant and nice to have around.
Since we're using FC for the fin/just checkpoints, we no longer get the `0x00..00` roots at genesis. You can see I had to remove a work-around in `ef-tests` here: b56be3bc2. I can't find any reason why this would be an issue, if anything I think it'll be better since the genesis-alias has caught us out a few times (0x00..00 isn't actually a real root). Edit: I did find a case where the `network` expected the 0x00..00 alias and patched it here: 3f26ac3e2.
You'll notice a lot of changes in tests. Generally, tests should be functionally equivalent. Here are the things creating the most diff-noise in tests:
- Changing tests to be `tokio::async` tests.
- Adding `.await` to fork choice, block processing and block production functions.
- Refactor of the `canonical_head` "API" provided by the `BeaconChain`. E.g., `chain.canonical_head.cached_head()` instead of `chain.canonical_head.read()`.
- Wrapping `SignedBeaconBlock` in an `Arc`.
- In the `beacon_chain/tests/block_verification`, we can't use the `lazy_static` `CHAIN_SEGMENT` variable anymore since it's generated with an async function. We just generate it in each test, not so efficient but hopefully insignificant.
I had to disable `rayon` concurrent tests in the `fork_choice` tests. This is because the use of `rayon` and `block_on` was causing a panic.
Co-authored-by: Mac L <mjladson@pm.me>
2022-07-03 05:36:50 +00:00
|
|
|
for (val_index, keypair) in self.validator_keypairs().iter().enumerate() {
|
2022-06-30 00:49:21 +00:00
|
|
|
let pubkey = keypair.pk.compress();
|
|
|
|
|
let fee_recipient = Address::from_low_u64_be(val_index as u64);
|
|
|
|
|
|
|
|
|
|
let data = ValidatorRegistrationData {
|
|
|
|
|
fee_recipient,
|
|
|
|
|
gas_limit: 0,
|
|
|
|
|
timestamp: 0,
|
|
|
|
|
pubkey,
|
|
|
|
|
};
|
|
|
|
|
let domain = self.chain.spec.get_domain(
|
|
|
|
|
Epoch::new(0),
|
|
|
|
|
Domain::ApplicationMask(ApplicationDomain::Builder),
|
|
|
|
|
&fork,
|
|
|
|
|
Hash256::zero(),
|
|
|
|
|
);
|
|
|
|
|
let message = data.signing_root(domain);
|
|
|
|
|
let signature = keypair.sk.sign(message);
|
|
|
|
|
|
|
|
|
|
fee_recipients.push(fee_recipient);
|
|
|
|
|
registrations.push(SignedValidatorRegistrationData {
|
|
|
|
|
message: data,
|
|
|
|
|
signature,
|
|
|
|
|
});
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
self.client
|
|
|
|
|
.post_validator_register_validator(®istrations)
|
|
|
|
|
.await
|
|
|
|
|
.unwrap();
|
|
|
|
|
|
|
|
|
|
for (val_index, (_, fee_recipient)) in self
|
|
|
|
|
.chain
|
Use async code when interacting with EL (#3244)
## Overview
This rather extensive PR achieves two primary goals:
1. Uses the finalized/justified checkpoints of fork choice (FC), rather than that of the head state.
2. Refactors fork choice, block production and block processing to `async` functions.
Additionally, it achieves:
- Concurrent forkchoice updates to the EL and cache pruning after a new head is selected.
- Concurrent "block packing" (attestations, etc) and execution payload retrieval during block production.
- Concurrent per-block-processing and execution payload verification during block processing.
- The `Arc`-ification of `SignedBeaconBlock` during block processing (it's never mutated, so why not?):
- I had to do this to deal with sending blocks into spawned tasks.
- Previously we were cloning the beacon block at least 2 times during each block processing, these clones are either removed or turned into cheaper `Arc` clones.
- We were also `Box`-ing and un-`Box`-ing beacon blocks as they moved throughout the networking crate. This is not a big deal, but it's nice to avoid shifting things between the stack and heap.
- Avoids cloning *all the blocks* in *every chain segment* during sync.
- It also has the potential to clean up our code where we need to pass an *owned* block around so we can send it back in the case of an error (I didn't do much of this, my PR is already big enough :sweat_smile:)
- The `BeaconChain::HeadSafetyStatus` struct was removed. It was an old relic from prior merge specs.
For motivation for this change, see https://github.com/sigp/lighthouse/pull/3244#issuecomment-1160963273
## Changes to `canonical_head` and `fork_choice`
Previously, the `BeaconChain` had two separate fields:
```
canonical_head: RwLock<Snapshot>,
fork_choice: RwLock<BeaconForkChoice>
```
Now, we have grouped these values under a single struct:
```
canonical_head: CanonicalHead {
cached_head: RwLock<Arc<Snapshot>>,
fork_choice: RwLock<BeaconForkChoice>
}
```
Apart from ergonomics, the only *actual* change here is wrapping the canonical head snapshot in an `Arc`. This means that we no longer need to hold the `cached_head` (`canonical_head`, in old terms) lock when we want to pull some values from it. This was done to avoid deadlock risks by preventing functions from acquiring (and holding) the `cached_head` and `fork_choice` locks simultaneously.
## Breaking Changes
### The `state` (root) field in the `finalized_checkpoint` SSE event
Consider the scenario where epoch `n` is just finalized, but `start_slot(n)` is skipped. There are two state roots we might in the `finalized_checkpoint` SSE event:
1. The state root of the finalized block, which is `get_block(finalized_checkpoint.root).state_root`.
4. The state root at slot of `start_slot(n)`, which would be the state from (1), but "skipped forward" through any skip slots.
Previously, Lighthouse would choose (2). However, we can see that when [Teku generates that event](https://github.com/ConsenSys/teku/blob/de2b2801c89ef5abf983d6bf37867c37fc47121f/data/beaconrestapi/src/main/java/tech/pegasys/teku/beaconrestapi/handlers/v1/events/EventSubscriptionManager.java#L171-L182) it uses [`getStateRootFromBlockRoot`](https://github.com/ConsenSys/teku/blob/de2b2801c89ef5abf983d6bf37867c37fc47121f/data/provider/src/main/java/tech/pegasys/teku/api/ChainDataProvider.java#L336-L341) which uses (1).
I have switched Lighthouse from (2) to (1). I think it's a somewhat arbitrary choice between the two, where (1) is easier to compute and is consistent with Teku.
## Notes for Reviewers
I've renamed `BeaconChain::fork_choice` to `BeaconChain::recompute_head`. Doing this helped ensure I broke all previous uses of fork choice and I also find it more descriptive. It describes an action and can't be confused with trying to get a reference to the `ForkChoice` struct.
I've changed the ordering of SSE events when a block is received. It used to be `[block, finalized, head]` and now it's `[block, head, finalized]`. It was easier this way and I don't think we were making any promises about SSE event ordering so it's not "breaking".
I've made it so fork choice will run when it's first constructed. I did this because I wanted to have a cached version of the last call to `get_head`. Ensuring `get_head` has been run *at least once* means that the cached values doesn't need to wrapped in an `Option`. This was fairly simple, it just involved passing a `slot` to the constructor so it knows *when* it's being run. When loading a fork choice from the store and a slot clock isn't handy I've just used the `slot` that was saved in the `fork_choice_store`. That seems like it would be a faithful representation of the slot when we saved it.
I added the `genesis_time: u64` to the `BeaconChain`. It's small, constant and nice to have around.
Since we're using FC for the fin/just checkpoints, we no longer get the `0x00..00` roots at genesis. You can see I had to remove a work-around in `ef-tests` here: b56be3bc2. I can't find any reason why this would be an issue, if anything I think it'll be better since the genesis-alias has caught us out a few times (0x00..00 isn't actually a real root). Edit: I did find a case where the `network` expected the 0x00..00 alias and patched it here: 3f26ac3e2.
You'll notice a lot of changes in tests. Generally, tests should be functionally equivalent. Here are the things creating the most diff-noise in tests:
- Changing tests to be `tokio::async` tests.
- Adding `.await` to fork choice, block processing and block production functions.
- Refactor of the `canonical_head` "API" provided by the `BeaconChain`. E.g., `chain.canonical_head.cached_head()` instead of `chain.canonical_head.read()`.
- Wrapping `SignedBeaconBlock` in an `Arc`.
- In the `beacon_chain/tests/block_verification`, we can't use the `lazy_static` `CHAIN_SEGMENT` variable anymore since it's generated with an async function. We just generate it in each test, not so efficient but hopefully insignificant.
I had to disable `rayon` concurrent tests in the `fork_choice` tests. This is because the use of `rayon` and `block_on` was causing a panic.
Co-authored-by: Mac L <mjladson@pm.me>
2022-07-03 05:36:50 +00:00
|
|
|
.head_snapshot()
|
2022-06-30 00:49:21 +00:00
|
|
|
.beacon_state
|
|
|
|
|
.validators()
|
|
|
|
|
.into_iter()
|
|
|
|
|
.zip(fee_recipients.into_iter())
|
|
|
|
|
.enumerate()
|
|
|
|
|
{
|
|
|
|
|
let actual = self
|
|
|
|
|
.chain
|
|
|
|
|
.execution_layer
|
|
|
|
|
.as_ref()
|
|
|
|
|
.unwrap()
|
|
|
|
|
.get_suggested_fee_recipient(val_index as u64)
|
|
|
|
|
.await;
|
|
|
|
|
assert_eq!(actual, fee_recipient);
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
self
|
|
|
|
|
}
|
|
|
|
|
|
2020-09-29 03:46:54 +00:00
|
|
|
#[cfg(target_os = "linux")]
|
|
|
|
|
pub async fn test_get_lighthouse_health(self) -> Self {
|
|
|
|
|
self.client.get_lighthouse_health().await.unwrap();
|
|
|
|
|
|
|
|
|
|
self
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
#[cfg(not(target_os = "linux"))]
|
|
|
|
|
pub async fn test_get_lighthouse_health(self) -> Self {
|
|
|
|
|
self.client.get_lighthouse_health().await.unwrap_err();
|
|
|
|
|
|
|
|
|
|
self
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
pub async fn test_get_lighthouse_syncing(self) -> Self {
|
|
|
|
|
self.client.get_lighthouse_syncing().await.unwrap();
|
|
|
|
|
|
|
|
|
|
self
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
pub async fn test_get_lighthouse_proto_array(self) -> Self {
|
|
|
|
|
self.client.get_lighthouse_proto_array().await.unwrap();
|
|
|
|
|
|
|
|
|
|
self
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
pub async fn test_get_lighthouse_validator_inclusion_global(self) -> Self {
|
|
|
|
|
let epoch = self.chain.epoch().unwrap() - 1;
|
|
|
|
|
self.client
|
|
|
|
|
.get_lighthouse_validator_inclusion_global(epoch)
|
|
|
|
|
.await
|
|
|
|
|
.unwrap();
|
|
|
|
|
|
|
|
|
|
self
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
pub async fn test_get_lighthouse_validator_inclusion(self) -> Self {
|
|
|
|
|
let epoch = self.chain.epoch().unwrap() - 1;
|
|
|
|
|
self.client
|
|
|
|
|
.get_lighthouse_validator_inclusion(epoch, ValidatorId::Index(0))
|
|
|
|
|
.await
|
|
|
|
|
.unwrap();
|
|
|
|
|
|
|
|
|
|
self
|
|
|
|
|
}
|
2020-10-22 06:05:49 +00:00
|
|
|
|
2020-11-02 00:37:30 +00:00
|
|
|
pub async fn test_get_lighthouse_eth1_syncing(self) -> Self {
|
|
|
|
|
self.client.get_lighthouse_eth1_syncing().await.unwrap();
|
|
|
|
|
|
|
|
|
|
self
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
pub async fn test_get_lighthouse_eth1_block_cache(self) -> Self {
|
|
|
|
|
let blocks = self.client.get_lighthouse_eth1_block_cache().await.unwrap();
|
|
|
|
|
|
|
|
|
|
assert!(blocks.data.is_empty());
|
|
|
|
|
|
|
|
|
|
self
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
pub async fn test_get_lighthouse_eth1_deposit_cache(self) -> Self {
|
|
|
|
|
let deposits = self
|
|
|
|
|
.client
|
|
|
|
|
.get_lighthouse_eth1_deposit_cache()
|
|
|
|
|
.await
|
|
|
|
|
.unwrap();
|
|
|
|
|
|
|
|
|
|
assert!(deposits.data.is_empty());
|
|
|
|
|
|
|
|
|
|
self
|
|
|
|
|
}
|
|
|
|
|
|
2020-10-22 06:05:49 +00:00
|
|
|
pub async fn test_get_lighthouse_beacon_states_ssz(self) -> Self {
|
|
|
|
|
for state_id in self.interesting_state_ids() {
|
|
|
|
|
let result = self
|
|
|
|
|
.client
|
2021-07-09 06:15:32 +00:00
|
|
|
.get_lighthouse_beacon_states_ssz(&state_id, &self.chain.spec)
|
2020-10-22 06:05:49 +00:00
|
|
|
.await
|
|
|
|
|
.unwrap();
|
|
|
|
|
|
|
|
|
|
let mut expected = self.get_state(state_id);
|
|
|
|
|
expected.as_mut().map(|state| state.drop_all_caches());
|
|
|
|
|
|
|
|
|
|
assert_eq!(result, expected, "{:?}", state_id);
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
self
|
|
|
|
|
}
|
2020-11-23 01:00:22 +00:00
|
|
|
|
|
|
|
|
pub async fn test_get_lighthouse_staking(self) -> Self {
|
|
|
|
|
let result = self.client.get_lighthouse_staking().await.unwrap();
|
|
|
|
|
|
|
|
|
|
assert_eq!(result, self.chain.eth1_chain.is_some());
|
|
|
|
|
|
|
|
|
|
self
|
|
|
|
|
}
|
2020-12-04 00:18:58 +00:00
|
|
|
|
2021-09-22 00:37:28 +00:00
|
|
|
pub async fn test_get_lighthouse_database_info(self) -> Self {
|
|
|
|
|
let info = self.client.get_lighthouse_database_info().await.unwrap();
|
|
|
|
|
|
|
|
|
|
assert_eq!(info.anchor, self.chain.store.get_anchor_info());
|
|
|
|
|
assert_eq!(info.split, self.chain.store.get_split_info());
|
|
|
|
|
assert_eq!(
|
|
|
|
|
info.schema_version,
|
|
|
|
|
store::metadata::CURRENT_SCHEMA_VERSION.as_u64()
|
|
|
|
|
);
|
|
|
|
|
|
|
|
|
|
self
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
pub async fn test_post_lighthouse_database_reconstruct(self) -> Self {
|
|
|
|
|
let response = self
|
|
|
|
|
.client
|
|
|
|
|
.post_lighthouse_database_reconstruct()
|
|
|
|
|
.await
|
|
|
|
|
.unwrap();
|
|
|
|
|
assert_eq!(response, "success");
|
|
|
|
|
self
|
|
|
|
|
}
|
|
|
|
|
|
2021-07-31 03:50:52 +00:00
|
|
|
pub async fn test_post_lighthouse_liveness(self) -> Self {
|
|
|
|
|
let epoch = self.chain.epoch().unwrap();
|
Use async code when interacting with EL (#3244)
## Overview
This rather extensive PR achieves two primary goals:
1. Uses the finalized/justified checkpoints of fork choice (FC), rather than that of the head state.
2. Refactors fork choice, block production and block processing to `async` functions.
Additionally, it achieves:
- Concurrent forkchoice updates to the EL and cache pruning after a new head is selected.
- Concurrent "block packing" (attestations, etc) and execution payload retrieval during block production.
- Concurrent per-block-processing and execution payload verification during block processing.
- The `Arc`-ification of `SignedBeaconBlock` during block processing (it's never mutated, so why not?):
- I had to do this to deal with sending blocks into spawned tasks.
- Previously we were cloning the beacon block at least 2 times during each block processing, these clones are either removed or turned into cheaper `Arc` clones.
- We were also `Box`-ing and un-`Box`-ing beacon blocks as they moved throughout the networking crate. This is not a big deal, but it's nice to avoid shifting things between the stack and heap.
- Avoids cloning *all the blocks* in *every chain segment* during sync.
- It also has the potential to clean up our code where we need to pass an *owned* block around so we can send it back in the case of an error (I didn't do much of this, my PR is already big enough :sweat_smile:)
- The `BeaconChain::HeadSafetyStatus` struct was removed. It was an old relic from prior merge specs.
For motivation for this change, see https://github.com/sigp/lighthouse/pull/3244#issuecomment-1160963273
## Changes to `canonical_head` and `fork_choice`
Previously, the `BeaconChain` had two separate fields:
```
canonical_head: RwLock<Snapshot>,
fork_choice: RwLock<BeaconForkChoice>
```
Now, we have grouped these values under a single struct:
```
canonical_head: CanonicalHead {
cached_head: RwLock<Arc<Snapshot>>,
fork_choice: RwLock<BeaconForkChoice>
}
```
Apart from ergonomics, the only *actual* change here is wrapping the canonical head snapshot in an `Arc`. This means that we no longer need to hold the `cached_head` (`canonical_head`, in old terms) lock when we want to pull some values from it. This was done to avoid deadlock risks by preventing functions from acquiring (and holding) the `cached_head` and `fork_choice` locks simultaneously.
## Breaking Changes
### The `state` (root) field in the `finalized_checkpoint` SSE event
Consider the scenario where epoch `n` is just finalized, but `start_slot(n)` is skipped. There are two state roots we might in the `finalized_checkpoint` SSE event:
1. The state root of the finalized block, which is `get_block(finalized_checkpoint.root).state_root`.
4. The state root at slot of `start_slot(n)`, which would be the state from (1), but "skipped forward" through any skip slots.
Previously, Lighthouse would choose (2). However, we can see that when [Teku generates that event](https://github.com/ConsenSys/teku/blob/de2b2801c89ef5abf983d6bf37867c37fc47121f/data/beaconrestapi/src/main/java/tech/pegasys/teku/beaconrestapi/handlers/v1/events/EventSubscriptionManager.java#L171-L182) it uses [`getStateRootFromBlockRoot`](https://github.com/ConsenSys/teku/blob/de2b2801c89ef5abf983d6bf37867c37fc47121f/data/provider/src/main/java/tech/pegasys/teku/api/ChainDataProvider.java#L336-L341) which uses (1).
I have switched Lighthouse from (2) to (1). I think it's a somewhat arbitrary choice between the two, where (1) is easier to compute and is consistent with Teku.
## Notes for Reviewers
I've renamed `BeaconChain::fork_choice` to `BeaconChain::recompute_head`. Doing this helped ensure I broke all previous uses of fork choice and I also find it more descriptive. It describes an action and can't be confused with trying to get a reference to the `ForkChoice` struct.
I've changed the ordering of SSE events when a block is received. It used to be `[block, finalized, head]` and now it's `[block, head, finalized]`. It was easier this way and I don't think we were making any promises about SSE event ordering so it's not "breaking".
I've made it so fork choice will run when it's first constructed. I did this because I wanted to have a cached version of the last call to `get_head`. Ensuring `get_head` has been run *at least once* means that the cached values doesn't need to wrapped in an `Option`. This was fairly simple, it just involved passing a `slot` to the constructor so it knows *when* it's being run. When loading a fork choice from the store and a slot clock isn't handy I've just used the `slot` that was saved in the `fork_choice_store`. That seems like it would be a faithful representation of the slot when we saved it.
I added the `genesis_time: u64` to the `BeaconChain`. It's small, constant and nice to have around.
Since we're using FC for the fin/just checkpoints, we no longer get the `0x00..00` roots at genesis. You can see I had to remove a work-around in `ef-tests` here: b56be3bc2. I can't find any reason why this would be an issue, if anything I think it'll be better since the genesis-alias has caught us out a few times (0x00..00 isn't actually a real root). Edit: I did find a case where the `network` expected the 0x00..00 alias and patched it here: 3f26ac3e2.
You'll notice a lot of changes in tests. Generally, tests should be functionally equivalent. Here are the things creating the most diff-noise in tests:
- Changing tests to be `tokio::async` tests.
- Adding `.await` to fork choice, block processing and block production functions.
- Refactor of the `canonical_head` "API" provided by the `BeaconChain`. E.g., `chain.canonical_head.cached_head()` instead of `chain.canonical_head.read()`.
- Wrapping `SignedBeaconBlock` in an `Arc`.
- In the `beacon_chain/tests/block_verification`, we can't use the `lazy_static` `CHAIN_SEGMENT` variable anymore since it's generated with an async function. We just generate it in each test, not so efficient but hopefully insignificant.
I had to disable `rayon` concurrent tests in the `fork_choice` tests. This is because the use of `rayon` and `block_on` was causing a panic.
Co-authored-by: Mac L <mjladson@pm.me>
2022-07-03 05:36:50 +00:00
|
|
|
let head_state = self.chain.head_beacon_state_cloned();
|
2021-07-31 03:50:52 +00:00
|
|
|
let indices = (0..head_state.validators().len())
|
|
|
|
|
.map(|i| i as u64)
|
|
|
|
|
.collect::<Vec<_>>();
|
|
|
|
|
|
|
|
|
|
// Construct the expected response
|
|
|
|
|
let expected: Vec<LivenessResponseData> = head_state
|
|
|
|
|
.validators()
|
|
|
|
|
.iter()
|
|
|
|
|
.enumerate()
|
|
|
|
|
.map(|(index, _)| LivenessResponseData {
|
|
|
|
|
index: index as u64,
|
|
|
|
|
is_live: false,
|
|
|
|
|
epoch,
|
|
|
|
|
})
|
|
|
|
|
.collect();
|
|
|
|
|
|
|
|
|
|
let result = self
|
|
|
|
|
.client
|
|
|
|
|
.post_lighthouse_liveness(indices.as_slice(), epoch)
|
|
|
|
|
.await
|
|
|
|
|
.unwrap()
|
|
|
|
|
.data;
|
|
|
|
|
|
|
|
|
|
assert_eq!(result, expected);
|
|
|
|
|
|
|
|
|
|
// Attest to the current slot
|
|
|
|
|
self.client
|
|
|
|
|
.post_beacon_pool_attestations(self.attestations.as_slice())
|
|
|
|
|
.await
|
|
|
|
|
.unwrap();
|
|
|
|
|
|
|
|
|
|
let result = self
|
|
|
|
|
.client
|
|
|
|
|
.post_lighthouse_liveness(indices.as_slice(), epoch)
|
|
|
|
|
.await
|
|
|
|
|
.unwrap()
|
|
|
|
|
.data;
|
|
|
|
|
|
|
|
|
|
let committees = head_state
|
|
|
|
|
.get_beacon_committees_at_slot(self.chain.slot().unwrap())
|
|
|
|
|
.unwrap();
|
|
|
|
|
let attesting_validators: Vec<usize> = committees
|
|
|
|
|
.into_iter()
|
2022-05-16 01:59:47 +00:00
|
|
|
.flat_map(|committee| committee.committee.iter().cloned())
|
2021-07-31 03:50:52 +00:00
|
|
|
.collect();
|
|
|
|
|
// All attesters should now be considered live
|
|
|
|
|
let expected = expected
|
|
|
|
|
.into_iter()
|
|
|
|
|
.map(|mut a| {
|
|
|
|
|
if attesting_validators.contains(&(a.index as usize)) {
|
|
|
|
|
a.is_live = true;
|
|
|
|
|
}
|
|
|
|
|
a
|
|
|
|
|
})
|
|
|
|
|
.collect::<Vec<_>>();
|
|
|
|
|
|
|
|
|
|
assert_eq!(result, expected);
|
|
|
|
|
|
|
|
|
|
self
|
|
|
|
|
}
|
|
|
|
|
|
2020-12-04 00:18:58 +00:00
|
|
|
pub async fn test_get_events(self) -> Self {
|
|
|
|
|
// Subscribe to all events
|
|
|
|
|
let topics = vec![
|
|
|
|
|
EventTopic::Attestation,
|
|
|
|
|
EventTopic::VoluntaryExit,
|
|
|
|
|
EventTopic::Block,
|
|
|
|
|
EventTopic::Head,
|
|
|
|
|
EventTopic::FinalizedCheckpoint,
|
|
|
|
|
];
|
|
|
|
|
let mut events_future = self
|
|
|
|
|
.client
|
|
|
|
|
.get_events::<E>(topics.as_slice())
|
|
|
|
|
.await
|
|
|
|
|
.unwrap();
|
|
|
|
|
|
|
|
|
|
let expected_attestation_len = self.attestations.len();
|
|
|
|
|
|
|
|
|
|
self.client
|
|
|
|
|
.post_beacon_pool_attestations(self.attestations.as_slice())
|
|
|
|
|
.await
|
|
|
|
|
.unwrap();
|
|
|
|
|
|
|
|
|
|
let attestation_events = poll_events(
|
|
|
|
|
&mut events_future,
|
|
|
|
|
expected_attestation_len,
|
|
|
|
|
Duration::from_millis(10000),
|
|
|
|
|
)
|
|
|
|
|
.await;
|
|
|
|
|
assert_eq!(
|
|
|
|
|
attestation_events.as_slice(),
|
|
|
|
|
self.attestations
|
|
|
|
|
.clone()
|
|
|
|
|
.into_iter()
|
2021-12-03 04:44:30 +00:00
|
|
|
.map(|attestation| EventKind::Attestation(Box::new(attestation)))
|
2020-12-04 00:18:58 +00:00
|
|
|
.collect::<Vec<_>>()
|
|
|
|
|
.as_slice()
|
|
|
|
|
);
|
|
|
|
|
|
|
|
|
|
// Produce a voluntary exit event
|
|
|
|
|
self.client
|
|
|
|
|
.post_beacon_pool_voluntary_exits(&self.voluntary_exit)
|
|
|
|
|
.await
|
|
|
|
|
.unwrap();
|
|
|
|
|
|
|
|
|
|
let exit_events = poll_events(&mut events_future, 1, Duration::from_millis(10000)).await;
|
|
|
|
|
assert_eq!(
|
|
|
|
|
exit_events.as_slice(),
|
|
|
|
|
&[EventKind::VoluntaryExit(self.voluntary_exit.clone())]
|
|
|
|
|
);
|
|
|
|
|
|
|
|
|
|
// Submit the next block, which is on an epoch boundary, so this will produce a finalized
|
|
|
|
|
// checkpoint event, head event, and block event
|
|
|
|
|
let block_root = self.next_block.canonical_root();
|
|
|
|
|
|
|
|
|
|
// current_duty_dependent_root = block root because this is the first slot of the epoch
|
Use async code when interacting with EL (#3244)
## Overview
This rather extensive PR achieves two primary goals:
1. Uses the finalized/justified checkpoints of fork choice (FC), rather than that of the head state.
2. Refactors fork choice, block production and block processing to `async` functions.
Additionally, it achieves:
- Concurrent forkchoice updates to the EL and cache pruning after a new head is selected.
- Concurrent "block packing" (attestations, etc) and execution payload retrieval during block production.
- Concurrent per-block-processing and execution payload verification during block processing.
- The `Arc`-ification of `SignedBeaconBlock` during block processing (it's never mutated, so why not?):
- I had to do this to deal with sending blocks into spawned tasks.
- Previously we were cloning the beacon block at least 2 times during each block processing, these clones are either removed or turned into cheaper `Arc` clones.
- We were also `Box`-ing and un-`Box`-ing beacon blocks as they moved throughout the networking crate. This is not a big deal, but it's nice to avoid shifting things between the stack and heap.
- Avoids cloning *all the blocks* in *every chain segment* during sync.
- It also has the potential to clean up our code where we need to pass an *owned* block around so we can send it back in the case of an error (I didn't do much of this, my PR is already big enough :sweat_smile:)
- The `BeaconChain::HeadSafetyStatus` struct was removed. It was an old relic from prior merge specs.
For motivation for this change, see https://github.com/sigp/lighthouse/pull/3244#issuecomment-1160963273
## Changes to `canonical_head` and `fork_choice`
Previously, the `BeaconChain` had two separate fields:
```
canonical_head: RwLock<Snapshot>,
fork_choice: RwLock<BeaconForkChoice>
```
Now, we have grouped these values under a single struct:
```
canonical_head: CanonicalHead {
cached_head: RwLock<Arc<Snapshot>>,
fork_choice: RwLock<BeaconForkChoice>
}
```
Apart from ergonomics, the only *actual* change here is wrapping the canonical head snapshot in an `Arc`. This means that we no longer need to hold the `cached_head` (`canonical_head`, in old terms) lock when we want to pull some values from it. This was done to avoid deadlock risks by preventing functions from acquiring (and holding) the `cached_head` and `fork_choice` locks simultaneously.
## Breaking Changes
### The `state` (root) field in the `finalized_checkpoint` SSE event
Consider the scenario where epoch `n` is just finalized, but `start_slot(n)` is skipped. There are two state roots we might in the `finalized_checkpoint` SSE event:
1. The state root of the finalized block, which is `get_block(finalized_checkpoint.root).state_root`.
4. The state root at slot of `start_slot(n)`, which would be the state from (1), but "skipped forward" through any skip slots.
Previously, Lighthouse would choose (2). However, we can see that when [Teku generates that event](https://github.com/ConsenSys/teku/blob/de2b2801c89ef5abf983d6bf37867c37fc47121f/data/beaconrestapi/src/main/java/tech/pegasys/teku/beaconrestapi/handlers/v1/events/EventSubscriptionManager.java#L171-L182) it uses [`getStateRootFromBlockRoot`](https://github.com/ConsenSys/teku/blob/de2b2801c89ef5abf983d6bf37867c37fc47121f/data/provider/src/main/java/tech/pegasys/teku/api/ChainDataProvider.java#L336-L341) which uses (1).
I have switched Lighthouse from (2) to (1). I think it's a somewhat arbitrary choice between the two, where (1) is easier to compute and is consistent with Teku.
## Notes for Reviewers
I've renamed `BeaconChain::fork_choice` to `BeaconChain::recompute_head`. Doing this helped ensure I broke all previous uses of fork choice and I also find it more descriptive. It describes an action and can't be confused with trying to get a reference to the `ForkChoice` struct.
I've changed the ordering of SSE events when a block is received. It used to be `[block, finalized, head]` and now it's `[block, head, finalized]`. It was easier this way and I don't think we were making any promises about SSE event ordering so it's not "breaking".
I've made it so fork choice will run when it's first constructed. I did this because I wanted to have a cached version of the last call to `get_head`. Ensuring `get_head` has been run *at least once* means that the cached values doesn't need to wrapped in an `Option`. This was fairly simple, it just involved passing a `slot` to the constructor so it knows *when* it's being run. When loading a fork choice from the store and a slot clock isn't handy I've just used the `slot` that was saved in the `fork_choice_store`. That seems like it would be a faithful representation of the slot when we saved it.
I added the `genesis_time: u64` to the `BeaconChain`. It's small, constant and nice to have around.
Since we're using FC for the fin/just checkpoints, we no longer get the `0x00..00` roots at genesis. You can see I had to remove a work-around in `ef-tests` here: b56be3bc2. I can't find any reason why this would be an issue, if anything I think it'll be better since the genesis-alias has caught us out a few times (0x00..00 isn't actually a real root). Edit: I did find a case where the `network` expected the 0x00..00 alias and patched it here: 3f26ac3e2.
You'll notice a lot of changes in tests. Generally, tests should be functionally equivalent. Here are the things creating the most diff-noise in tests:
- Changing tests to be `tokio::async` tests.
- Adding `.await` to fork choice, block processing and block production functions.
- Refactor of the `canonical_head` "API" provided by the `BeaconChain`. E.g., `chain.canonical_head.cached_head()` instead of `chain.canonical_head.read()`.
- Wrapping `SignedBeaconBlock` in an `Arc`.
- In the `beacon_chain/tests/block_verification`, we can't use the `lazy_static` `CHAIN_SEGMENT` variable anymore since it's generated with an async function. We just generate it in each test, not so efficient but hopefully insignificant.
I had to disable `rayon` concurrent tests in the `fork_choice` tests. This is because the use of `rayon` and `block_on` was causing a panic.
Co-authored-by: Mac L <mjladson@pm.me>
2022-07-03 05:36:50 +00:00
|
|
|
let current_duty_dependent_root = self.chain.head_beacon_block_root();
|
2020-12-04 00:18:58 +00:00
|
|
|
let current_slot = self.chain.slot().unwrap();
|
|
|
|
|
let next_slot = self.next_block.slot();
|
|
|
|
|
let finalization_distance = E::slots_per_epoch() * 2;
|
|
|
|
|
|
|
|
|
|
let expected_block = EventKind::Block(SseBlock {
|
|
|
|
|
block: block_root,
|
|
|
|
|
slot: next_slot,
|
|
|
|
|
});
|
|
|
|
|
|
|
|
|
|
let expected_head = EventKind::Head(SseHead {
|
|
|
|
|
block: block_root,
|
|
|
|
|
slot: next_slot,
|
|
|
|
|
state: self.next_block.state_root(),
|
|
|
|
|
current_duty_dependent_root,
|
|
|
|
|
previous_duty_dependent_root: self
|
|
|
|
|
.chain
|
Use the forwards iterator more often (#2376)
## Issue Addressed
NA
## Primary Change
When investigating memory usage, I noticed that retrieving a block from an early slot (e.g., slot 900) would cause a sharp increase in the memory footprint (from 400mb to 800mb+) which seemed to be ever-lasting.
After some investigation, I found that the reverse iteration from the head back to that slot was the likely culprit. To counter this, I've switched the `BeaconChain::block_root_at_slot` to use the forwards iterator, instead of the reverse one.
I also noticed that the networking stack is using `BeaconChain::root_at_slot` to check if a peer is relevant (`check_peer_relevance`). Perhaps the steep, seemingly-random-but-consistent increases in memory usage are caused by the use of this function.
Using the forwards iterator with the HTTP API alleviated the sharp increases in memory usage. It also made the response much faster (before it felt like to took 1-2s, now it feels instant).
## Additional Changes
In the process I also noticed that we have two functions for getting block roots:
- `BeaconChain::block_root_at_slot`: returns `None` for a skip slot.
- `BeaconChain::root_at_slot`: returns the previous root for a skip slot.
I unified these two functions into `block_root_at_slot` and added the `WhenSlotSkipped` enum. Now, the caller must be explicit about the skip-slot behaviour when requesting a root.
Additionally, I replaced `vec![]` with `Vec::with_capacity` in `store::chunked_vector::range_query`. I stumbled across this whilst debugging and made this modification to see what effect it would have (not much). It seems like a decent change to keep around, but I'm not concerned either way.
Also, `BeaconChain::get_ancestor_block_root` is unused, so I got rid of it :wastebasket:.
## Additional Info
I haven't also done the same for state roots here. Whilst it's possible and a good idea, it's more work since the fwds iterators are presently block-roots-specific.
Whilst there's a few places a reverse iteration of state roots could be triggered (e.g., attestation production, HTTP API), they're no where near as common as the `check_peer_relevance` call. As such, I think we should get this PR merged first, then come back for the state root iters. I made an issue here https://github.com/sigp/lighthouse/issues/2377.
2021-05-31 04:18:20 +00:00
|
|
|
.block_root_at_slot(current_slot - E::slots_per_epoch(), WhenSlotSkipped::Prev)
|
2020-12-04 00:18:58 +00:00
|
|
|
.unwrap()
|
|
|
|
|
.unwrap(),
|
|
|
|
|
epoch_transition: true,
|
|
|
|
|
});
|
|
|
|
|
|
Use async code when interacting with EL (#3244)
## Overview
This rather extensive PR achieves two primary goals:
1. Uses the finalized/justified checkpoints of fork choice (FC), rather than that of the head state.
2. Refactors fork choice, block production and block processing to `async` functions.
Additionally, it achieves:
- Concurrent forkchoice updates to the EL and cache pruning after a new head is selected.
- Concurrent "block packing" (attestations, etc) and execution payload retrieval during block production.
- Concurrent per-block-processing and execution payload verification during block processing.
- The `Arc`-ification of `SignedBeaconBlock` during block processing (it's never mutated, so why not?):
- I had to do this to deal with sending blocks into spawned tasks.
- Previously we were cloning the beacon block at least 2 times during each block processing, these clones are either removed or turned into cheaper `Arc` clones.
- We were also `Box`-ing and un-`Box`-ing beacon blocks as they moved throughout the networking crate. This is not a big deal, but it's nice to avoid shifting things between the stack and heap.
- Avoids cloning *all the blocks* in *every chain segment* during sync.
- It also has the potential to clean up our code where we need to pass an *owned* block around so we can send it back in the case of an error (I didn't do much of this, my PR is already big enough :sweat_smile:)
- The `BeaconChain::HeadSafetyStatus` struct was removed. It was an old relic from prior merge specs.
For motivation for this change, see https://github.com/sigp/lighthouse/pull/3244#issuecomment-1160963273
## Changes to `canonical_head` and `fork_choice`
Previously, the `BeaconChain` had two separate fields:
```
canonical_head: RwLock<Snapshot>,
fork_choice: RwLock<BeaconForkChoice>
```
Now, we have grouped these values under a single struct:
```
canonical_head: CanonicalHead {
cached_head: RwLock<Arc<Snapshot>>,
fork_choice: RwLock<BeaconForkChoice>
}
```
Apart from ergonomics, the only *actual* change here is wrapping the canonical head snapshot in an `Arc`. This means that we no longer need to hold the `cached_head` (`canonical_head`, in old terms) lock when we want to pull some values from it. This was done to avoid deadlock risks by preventing functions from acquiring (and holding) the `cached_head` and `fork_choice` locks simultaneously.
## Breaking Changes
### The `state` (root) field in the `finalized_checkpoint` SSE event
Consider the scenario where epoch `n` is just finalized, but `start_slot(n)` is skipped. There are two state roots we might in the `finalized_checkpoint` SSE event:
1. The state root of the finalized block, which is `get_block(finalized_checkpoint.root).state_root`.
4. The state root at slot of `start_slot(n)`, which would be the state from (1), but "skipped forward" through any skip slots.
Previously, Lighthouse would choose (2). However, we can see that when [Teku generates that event](https://github.com/ConsenSys/teku/blob/de2b2801c89ef5abf983d6bf37867c37fc47121f/data/beaconrestapi/src/main/java/tech/pegasys/teku/beaconrestapi/handlers/v1/events/EventSubscriptionManager.java#L171-L182) it uses [`getStateRootFromBlockRoot`](https://github.com/ConsenSys/teku/blob/de2b2801c89ef5abf983d6bf37867c37fc47121f/data/provider/src/main/java/tech/pegasys/teku/api/ChainDataProvider.java#L336-L341) which uses (1).
I have switched Lighthouse from (2) to (1). I think it's a somewhat arbitrary choice between the two, where (1) is easier to compute and is consistent with Teku.
## Notes for Reviewers
I've renamed `BeaconChain::fork_choice` to `BeaconChain::recompute_head`. Doing this helped ensure I broke all previous uses of fork choice and I also find it more descriptive. It describes an action and can't be confused with trying to get a reference to the `ForkChoice` struct.
I've changed the ordering of SSE events when a block is received. It used to be `[block, finalized, head]` and now it's `[block, head, finalized]`. It was easier this way and I don't think we were making any promises about SSE event ordering so it's not "breaking".
I've made it so fork choice will run when it's first constructed. I did this because I wanted to have a cached version of the last call to `get_head`. Ensuring `get_head` has been run *at least once* means that the cached values doesn't need to wrapped in an `Option`. This was fairly simple, it just involved passing a `slot` to the constructor so it knows *when* it's being run. When loading a fork choice from the store and a slot clock isn't handy I've just used the `slot` that was saved in the `fork_choice_store`. That seems like it would be a faithful representation of the slot when we saved it.
I added the `genesis_time: u64` to the `BeaconChain`. It's small, constant and nice to have around.
Since we're using FC for the fin/just checkpoints, we no longer get the `0x00..00` roots at genesis. You can see I had to remove a work-around in `ef-tests` here: b56be3bc2. I can't find any reason why this would be an issue, if anything I think it'll be better since the genesis-alias has caught us out a few times (0x00..00 isn't actually a real root). Edit: I did find a case where the `network` expected the 0x00..00 alias and patched it here: 3f26ac3e2.
You'll notice a lot of changes in tests. Generally, tests should be functionally equivalent. Here are the things creating the most diff-noise in tests:
- Changing tests to be `tokio::async` tests.
- Adding `.await` to fork choice, block processing and block production functions.
- Refactor of the `canonical_head` "API" provided by the `BeaconChain`. E.g., `chain.canonical_head.cached_head()` instead of `chain.canonical_head.read()`.
- Wrapping `SignedBeaconBlock` in an `Arc`.
- In the `beacon_chain/tests/block_verification`, we can't use the `lazy_static` `CHAIN_SEGMENT` variable anymore since it's generated with an async function. We just generate it in each test, not so efficient but hopefully insignificant.
I had to disable `rayon` concurrent tests in the `fork_choice` tests. This is because the use of `rayon` and `block_on` was causing a panic.
Co-authored-by: Mac L <mjladson@pm.me>
2022-07-03 05:36:50 +00:00
|
|
|
let finalized_block_root = self
|
|
|
|
|
.chain
|
|
|
|
|
.block_root_at_slot(next_slot - finalization_distance, WhenSlotSkipped::Prev)
|
|
|
|
|
.unwrap()
|
|
|
|
|
.unwrap();
|
|
|
|
|
let finalized_block = self
|
|
|
|
|
.chain
|
|
|
|
|
.get_blinded_block(&finalized_block_root)
|
|
|
|
|
.unwrap()
|
|
|
|
|
.unwrap();
|
|
|
|
|
let finalized_state_root = finalized_block.state_root();
|
|
|
|
|
|
2020-12-04 00:18:58 +00:00
|
|
|
let expected_finalized = EventKind::FinalizedCheckpoint(SseFinalizedCheckpoint {
|
Use async code when interacting with EL (#3244)
## Overview
This rather extensive PR achieves two primary goals:
1. Uses the finalized/justified checkpoints of fork choice (FC), rather than that of the head state.
2. Refactors fork choice, block production and block processing to `async` functions.
Additionally, it achieves:
- Concurrent forkchoice updates to the EL and cache pruning after a new head is selected.
- Concurrent "block packing" (attestations, etc) and execution payload retrieval during block production.
- Concurrent per-block-processing and execution payload verification during block processing.
- The `Arc`-ification of `SignedBeaconBlock` during block processing (it's never mutated, so why not?):
- I had to do this to deal with sending blocks into spawned tasks.
- Previously we were cloning the beacon block at least 2 times during each block processing, these clones are either removed or turned into cheaper `Arc` clones.
- We were also `Box`-ing and un-`Box`-ing beacon blocks as they moved throughout the networking crate. This is not a big deal, but it's nice to avoid shifting things between the stack and heap.
- Avoids cloning *all the blocks* in *every chain segment* during sync.
- It also has the potential to clean up our code where we need to pass an *owned* block around so we can send it back in the case of an error (I didn't do much of this, my PR is already big enough :sweat_smile:)
- The `BeaconChain::HeadSafetyStatus` struct was removed. It was an old relic from prior merge specs.
For motivation for this change, see https://github.com/sigp/lighthouse/pull/3244#issuecomment-1160963273
## Changes to `canonical_head` and `fork_choice`
Previously, the `BeaconChain` had two separate fields:
```
canonical_head: RwLock<Snapshot>,
fork_choice: RwLock<BeaconForkChoice>
```
Now, we have grouped these values under a single struct:
```
canonical_head: CanonicalHead {
cached_head: RwLock<Arc<Snapshot>>,
fork_choice: RwLock<BeaconForkChoice>
}
```
Apart from ergonomics, the only *actual* change here is wrapping the canonical head snapshot in an `Arc`. This means that we no longer need to hold the `cached_head` (`canonical_head`, in old terms) lock when we want to pull some values from it. This was done to avoid deadlock risks by preventing functions from acquiring (and holding) the `cached_head` and `fork_choice` locks simultaneously.
## Breaking Changes
### The `state` (root) field in the `finalized_checkpoint` SSE event
Consider the scenario where epoch `n` is just finalized, but `start_slot(n)` is skipped. There are two state roots we might in the `finalized_checkpoint` SSE event:
1. The state root of the finalized block, which is `get_block(finalized_checkpoint.root).state_root`.
4. The state root at slot of `start_slot(n)`, which would be the state from (1), but "skipped forward" through any skip slots.
Previously, Lighthouse would choose (2). However, we can see that when [Teku generates that event](https://github.com/ConsenSys/teku/blob/de2b2801c89ef5abf983d6bf37867c37fc47121f/data/beaconrestapi/src/main/java/tech/pegasys/teku/beaconrestapi/handlers/v1/events/EventSubscriptionManager.java#L171-L182) it uses [`getStateRootFromBlockRoot`](https://github.com/ConsenSys/teku/blob/de2b2801c89ef5abf983d6bf37867c37fc47121f/data/provider/src/main/java/tech/pegasys/teku/api/ChainDataProvider.java#L336-L341) which uses (1).
I have switched Lighthouse from (2) to (1). I think it's a somewhat arbitrary choice between the two, where (1) is easier to compute and is consistent with Teku.
## Notes for Reviewers
I've renamed `BeaconChain::fork_choice` to `BeaconChain::recompute_head`. Doing this helped ensure I broke all previous uses of fork choice and I also find it more descriptive. It describes an action and can't be confused with trying to get a reference to the `ForkChoice` struct.
I've changed the ordering of SSE events when a block is received. It used to be `[block, finalized, head]` and now it's `[block, head, finalized]`. It was easier this way and I don't think we were making any promises about SSE event ordering so it's not "breaking".
I've made it so fork choice will run when it's first constructed. I did this because I wanted to have a cached version of the last call to `get_head`. Ensuring `get_head` has been run *at least once* means that the cached values doesn't need to wrapped in an `Option`. This was fairly simple, it just involved passing a `slot` to the constructor so it knows *when* it's being run. When loading a fork choice from the store and a slot clock isn't handy I've just used the `slot` that was saved in the `fork_choice_store`. That seems like it would be a faithful representation of the slot when we saved it.
I added the `genesis_time: u64` to the `BeaconChain`. It's small, constant and nice to have around.
Since we're using FC for the fin/just checkpoints, we no longer get the `0x00..00` roots at genesis. You can see I had to remove a work-around in `ef-tests` here: b56be3bc2. I can't find any reason why this would be an issue, if anything I think it'll be better since the genesis-alias has caught us out a few times (0x00..00 isn't actually a real root). Edit: I did find a case where the `network` expected the 0x00..00 alias and patched it here: 3f26ac3e2.
You'll notice a lot of changes in tests. Generally, tests should be functionally equivalent. Here are the things creating the most diff-noise in tests:
- Changing tests to be `tokio::async` tests.
- Adding `.await` to fork choice, block processing and block production functions.
- Refactor of the `canonical_head` "API" provided by the `BeaconChain`. E.g., `chain.canonical_head.cached_head()` instead of `chain.canonical_head.read()`.
- Wrapping `SignedBeaconBlock` in an `Arc`.
- In the `beacon_chain/tests/block_verification`, we can't use the `lazy_static` `CHAIN_SEGMENT` variable anymore since it's generated with an async function. We just generate it in each test, not so efficient but hopefully insignificant.
I had to disable `rayon` concurrent tests in the `fork_choice` tests. This is because the use of `rayon` and `block_on` was causing a panic.
Co-authored-by: Mac L <mjladson@pm.me>
2022-07-03 05:36:50 +00:00
|
|
|
block: finalized_block_root,
|
|
|
|
|
state: finalized_state_root,
|
2020-12-04 00:18:58 +00:00
|
|
|
epoch: Epoch::new(3),
|
|
|
|
|
});
|
|
|
|
|
|
|
|
|
|
self.client
|
|
|
|
|
.post_beacon_blocks(&self.next_block)
|
|
|
|
|
.await
|
|
|
|
|
.unwrap();
|
|
|
|
|
|
|
|
|
|
let block_events = poll_events(&mut events_future, 3, Duration::from_millis(10000)).await;
|
|
|
|
|
assert_eq!(
|
|
|
|
|
block_events.as_slice(),
|
Use async code when interacting with EL (#3244)
## Overview
This rather extensive PR achieves two primary goals:
1. Uses the finalized/justified checkpoints of fork choice (FC), rather than that of the head state.
2. Refactors fork choice, block production and block processing to `async` functions.
Additionally, it achieves:
- Concurrent forkchoice updates to the EL and cache pruning after a new head is selected.
- Concurrent "block packing" (attestations, etc) and execution payload retrieval during block production.
- Concurrent per-block-processing and execution payload verification during block processing.
- The `Arc`-ification of `SignedBeaconBlock` during block processing (it's never mutated, so why not?):
- I had to do this to deal with sending blocks into spawned tasks.
- Previously we were cloning the beacon block at least 2 times during each block processing, these clones are either removed or turned into cheaper `Arc` clones.
- We were also `Box`-ing and un-`Box`-ing beacon blocks as they moved throughout the networking crate. This is not a big deal, but it's nice to avoid shifting things between the stack and heap.
- Avoids cloning *all the blocks* in *every chain segment* during sync.
- It also has the potential to clean up our code where we need to pass an *owned* block around so we can send it back in the case of an error (I didn't do much of this, my PR is already big enough :sweat_smile:)
- The `BeaconChain::HeadSafetyStatus` struct was removed. It was an old relic from prior merge specs.
For motivation for this change, see https://github.com/sigp/lighthouse/pull/3244#issuecomment-1160963273
## Changes to `canonical_head` and `fork_choice`
Previously, the `BeaconChain` had two separate fields:
```
canonical_head: RwLock<Snapshot>,
fork_choice: RwLock<BeaconForkChoice>
```
Now, we have grouped these values under a single struct:
```
canonical_head: CanonicalHead {
cached_head: RwLock<Arc<Snapshot>>,
fork_choice: RwLock<BeaconForkChoice>
}
```
Apart from ergonomics, the only *actual* change here is wrapping the canonical head snapshot in an `Arc`. This means that we no longer need to hold the `cached_head` (`canonical_head`, in old terms) lock when we want to pull some values from it. This was done to avoid deadlock risks by preventing functions from acquiring (and holding) the `cached_head` and `fork_choice` locks simultaneously.
## Breaking Changes
### The `state` (root) field in the `finalized_checkpoint` SSE event
Consider the scenario where epoch `n` is just finalized, but `start_slot(n)` is skipped. There are two state roots we might in the `finalized_checkpoint` SSE event:
1. The state root of the finalized block, which is `get_block(finalized_checkpoint.root).state_root`.
4. The state root at slot of `start_slot(n)`, which would be the state from (1), but "skipped forward" through any skip slots.
Previously, Lighthouse would choose (2). However, we can see that when [Teku generates that event](https://github.com/ConsenSys/teku/blob/de2b2801c89ef5abf983d6bf37867c37fc47121f/data/beaconrestapi/src/main/java/tech/pegasys/teku/beaconrestapi/handlers/v1/events/EventSubscriptionManager.java#L171-L182) it uses [`getStateRootFromBlockRoot`](https://github.com/ConsenSys/teku/blob/de2b2801c89ef5abf983d6bf37867c37fc47121f/data/provider/src/main/java/tech/pegasys/teku/api/ChainDataProvider.java#L336-L341) which uses (1).
I have switched Lighthouse from (2) to (1). I think it's a somewhat arbitrary choice between the two, where (1) is easier to compute and is consistent with Teku.
## Notes for Reviewers
I've renamed `BeaconChain::fork_choice` to `BeaconChain::recompute_head`. Doing this helped ensure I broke all previous uses of fork choice and I also find it more descriptive. It describes an action and can't be confused with trying to get a reference to the `ForkChoice` struct.
I've changed the ordering of SSE events when a block is received. It used to be `[block, finalized, head]` and now it's `[block, head, finalized]`. It was easier this way and I don't think we were making any promises about SSE event ordering so it's not "breaking".
I've made it so fork choice will run when it's first constructed. I did this because I wanted to have a cached version of the last call to `get_head`. Ensuring `get_head` has been run *at least once* means that the cached values doesn't need to wrapped in an `Option`. This was fairly simple, it just involved passing a `slot` to the constructor so it knows *when* it's being run. When loading a fork choice from the store and a slot clock isn't handy I've just used the `slot` that was saved in the `fork_choice_store`. That seems like it would be a faithful representation of the slot when we saved it.
I added the `genesis_time: u64` to the `BeaconChain`. It's small, constant and nice to have around.
Since we're using FC for the fin/just checkpoints, we no longer get the `0x00..00` roots at genesis. You can see I had to remove a work-around in `ef-tests` here: b56be3bc2. I can't find any reason why this would be an issue, if anything I think it'll be better since the genesis-alias has caught us out a few times (0x00..00 isn't actually a real root). Edit: I did find a case where the `network` expected the 0x00..00 alias and patched it here: 3f26ac3e2.
You'll notice a lot of changes in tests. Generally, tests should be functionally equivalent. Here are the things creating the most diff-noise in tests:
- Changing tests to be `tokio::async` tests.
- Adding `.await` to fork choice, block processing and block production functions.
- Refactor of the `canonical_head` "API" provided by the `BeaconChain`. E.g., `chain.canonical_head.cached_head()` instead of `chain.canonical_head.read()`.
- Wrapping `SignedBeaconBlock` in an `Arc`.
- In the `beacon_chain/tests/block_verification`, we can't use the `lazy_static` `CHAIN_SEGMENT` variable anymore since it's generated with an async function. We just generate it in each test, not so efficient but hopefully insignificant.
I had to disable `rayon` concurrent tests in the `fork_choice` tests. This is because the use of `rayon` and `block_on` was causing a panic.
Co-authored-by: Mac L <mjladson@pm.me>
2022-07-03 05:36:50 +00:00
|
|
|
&[expected_block, expected_head, expected_finalized]
|
2020-12-04 00:18:58 +00:00
|
|
|
);
|
|
|
|
|
|
2021-06-17 02:10:46 +00:00
|
|
|
// Test a reorg event
|
|
|
|
|
let mut chain_reorg_event_future = self
|
|
|
|
|
.client
|
|
|
|
|
.get_events::<E>(&[EventTopic::ChainReorg])
|
|
|
|
|
.await
|
|
|
|
|
.unwrap();
|
|
|
|
|
|
|
|
|
|
let expected_reorg = EventKind::ChainReorg(SseChainReorg {
|
|
|
|
|
slot: self.next_block.slot(),
|
|
|
|
|
depth: 1,
|
|
|
|
|
old_head_block: self.next_block.canonical_root(),
|
|
|
|
|
old_head_state: self.next_block.state_root(),
|
|
|
|
|
new_head_block: self.reorg_block.canonical_root(),
|
|
|
|
|
new_head_state: self.reorg_block.state_root(),
|
|
|
|
|
epoch: self.next_block.slot().epoch(E::slots_per_epoch()),
|
|
|
|
|
});
|
|
|
|
|
|
|
|
|
|
self.client
|
|
|
|
|
.post_beacon_blocks(&self.reorg_block)
|
|
|
|
|
.await
|
|
|
|
|
.unwrap();
|
|
|
|
|
|
|
|
|
|
let reorg_event = poll_events(
|
|
|
|
|
&mut chain_reorg_event_future,
|
|
|
|
|
1,
|
|
|
|
|
Duration::from_millis(10000),
|
|
|
|
|
)
|
|
|
|
|
.await;
|
|
|
|
|
assert_eq!(reorg_event.as_slice(), &[expected_reorg]);
|
|
|
|
|
|
2020-12-04 00:18:58 +00:00
|
|
|
self
|
|
|
|
|
}
|
|
|
|
|
|
2021-09-25 07:53:58 +00:00
|
|
|
pub async fn test_get_events_altair(self) -> Self {
|
|
|
|
|
let topics = vec![EventTopic::ContributionAndProof];
|
|
|
|
|
let mut events_future = self
|
|
|
|
|
.client
|
|
|
|
|
.get_events::<E>(topics.as_slice())
|
|
|
|
|
.await
|
|
|
|
|
.unwrap();
|
|
|
|
|
|
|
|
|
|
let expected_contribution_len = self.contribution_and_proofs.len();
|
|
|
|
|
|
|
|
|
|
self.client
|
|
|
|
|
.post_validator_contribution_and_proofs(self.contribution_and_proofs.as_slice())
|
|
|
|
|
.await
|
|
|
|
|
.unwrap();
|
|
|
|
|
|
|
|
|
|
let contribution_events = poll_events(
|
|
|
|
|
&mut events_future,
|
|
|
|
|
expected_contribution_len,
|
|
|
|
|
Duration::from_millis(10000),
|
|
|
|
|
)
|
|
|
|
|
.await;
|
|
|
|
|
assert_eq!(
|
|
|
|
|
contribution_events.as_slice(),
|
|
|
|
|
self.contribution_and_proofs
|
|
|
|
|
.clone()
|
|
|
|
|
.into_iter()
|
|
|
|
|
.map(|contribution| EventKind::ContributionAndProof(Box::new(contribution)))
|
|
|
|
|
.collect::<Vec<_>>()
|
|
|
|
|
.as_slice()
|
|
|
|
|
);
|
|
|
|
|
|
|
|
|
|
self
|
|
|
|
|
}
|
|
|
|
|
|
2020-12-04 00:18:58 +00:00
|
|
|
pub async fn test_get_events_from_genesis(self) -> Self {
|
|
|
|
|
let topics = vec![EventTopic::Block, EventTopic::Head];
|
|
|
|
|
let mut events_future = self
|
|
|
|
|
.client
|
|
|
|
|
.get_events::<E>(topics.as_slice())
|
|
|
|
|
.await
|
|
|
|
|
.unwrap();
|
|
|
|
|
|
|
|
|
|
let block_root = self.next_block.canonical_root();
|
|
|
|
|
let next_slot = self.next_block.slot();
|
|
|
|
|
|
|
|
|
|
let expected_block = EventKind::Block(SseBlock {
|
|
|
|
|
block: block_root,
|
|
|
|
|
slot: next_slot,
|
|
|
|
|
});
|
|
|
|
|
|
|
|
|
|
let expected_head = EventKind::Head(SseHead {
|
|
|
|
|
block: block_root,
|
|
|
|
|
slot: next_slot,
|
|
|
|
|
state: self.next_block.state_root(),
|
|
|
|
|
current_duty_dependent_root: self.chain.genesis_block_root,
|
|
|
|
|
previous_duty_dependent_root: self.chain.genesis_block_root,
|
|
|
|
|
epoch_transition: false,
|
|
|
|
|
});
|
|
|
|
|
|
|
|
|
|
self.client
|
|
|
|
|
.post_beacon_blocks(&self.next_block)
|
|
|
|
|
.await
|
|
|
|
|
.unwrap();
|
|
|
|
|
|
|
|
|
|
let block_events = poll_events(&mut events_future, 2, Duration::from_millis(10000)).await;
|
|
|
|
|
assert_eq!(block_events.as_slice(), &[expected_block, expected_head]);
|
|
|
|
|
|
|
|
|
|
self
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
async fn poll_events<S: Stream<Item = Result<EventKind<T>, eth2::Error>> + Unpin, T: EthSpec>(
|
|
|
|
|
stream: &mut S,
|
|
|
|
|
num_events: usize,
|
|
|
|
|
timeout: Duration,
|
|
|
|
|
) -> Vec<EventKind<T>> {
|
|
|
|
|
let mut events = Vec::new();
|
|
|
|
|
|
|
|
|
|
let collect_stream_fut = async {
|
|
|
|
|
loop {
|
|
|
|
|
if let Some(result) = stream.next().await {
|
|
|
|
|
events.push(result.unwrap());
|
|
|
|
|
if events.len() == num_events {
|
|
|
|
|
return;
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
};
|
|
|
|
|
|
|
|
|
|
tokio::select! {
|
2021-06-18 05:58:01 +00:00
|
|
|
_ = collect_stream_fut => {events}
|
2020-12-04 00:18:58 +00:00
|
|
|
_ = tokio::time::sleep(timeout) => { return events; }
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
#[tokio::test(flavor = "multi_thread", worker_threads = 2)]
|
|
|
|
|
async fn get_events() {
|
2021-10-11 02:45:06 +00:00
|
|
|
ApiTester::new().await.test_get_events().await;
|
2020-12-04 00:18:58 +00:00
|
|
|
}
|
|
|
|
|
|
2021-09-25 07:53:58 +00:00
|
|
|
#[tokio::test(flavor = "multi_thread", worker_threads = 2)]
|
|
|
|
|
async fn get_events_altair() {
|
|
|
|
|
let mut spec = E::default_spec();
|
|
|
|
|
spec.altair_fork_epoch = Some(Epoch::new(0));
|
|
|
|
|
ApiTester::new_from_spec(spec)
|
2021-10-11 02:45:06 +00:00
|
|
|
.await
|
2021-09-25 07:53:58 +00:00
|
|
|
.test_get_events_altair()
|
|
|
|
|
.await;
|
|
|
|
|
}
|
|
|
|
|
|
2020-12-04 00:18:58 +00:00
|
|
|
#[tokio::test(flavor = "multi_thread", worker_threads = 2)]
|
|
|
|
|
async fn get_events_from_genesis() {
|
|
|
|
|
ApiTester::new_from_genesis()
|
2021-10-11 02:45:06 +00:00
|
|
|
.await
|
2020-12-04 00:18:58 +00:00
|
|
|
.test_get_events_from_genesis()
|
|
|
|
|
.await;
|
2020-09-29 03:46:54 +00:00
|
|
|
}
|
|
|
|
|
|
2020-11-28 05:30:57 +00:00
|
|
|
#[tokio::test(flavor = "multi_thread", worker_threads = 2)]
|
2020-10-29 22:25:20 +00:00
|
|
|
async fn beacon_get() {
|
2021-02-10 23:29:49 +00:00
|
|
|
ApiTester::new()
|
2021-10-11 02:45:06 +00:00
|
|
|
.await
|
2021-02-10 23:29:49 +00:00
|
|
|
.test_beacon_genesis()
|
|
|
|
|
.await
|
|
|
|
|
.test_beacon_states_root()
|
|
|
|
|
.await
|
|
|
|
|
.test_beacon_states_fork()
|
|
|
|
|
.await
|
|
|
|
|
.test_beacon_states_finality_checkpoints()
|
|
|
|
|
.await
|
|
|
|
|
.test_beacon_states_validators()
|
|
|
|
|
.await
|
|
|
|
|
.test_beacon_states_validator_balances()
|
|
|
|
|
.await
|
|
|
|
|
.test_beacon_states_committees()
|
|
|
|
|
.await
|
|
|
|
|
.test_beacon_states_validator_id()
|
|
|
|
|
.await
|
|
|
|
|
.test_beacon_headers_all_slots()
|
|
|
|
|
.await
|
|
|
|
|
.test_beacon_headers_all_parents()
|
|
|
|
|
.await
|
|
|
|
|
.test_beacon_headers_block_id()
|
|
|
|
|
.await
|
|
|
|
|
.test_beacon_blocks()
|
|
|
|
|
.await
|
|
|
|
|
.test_beacon_blocks_attestations()
|
|
|
|
|
.await
|
|
|
|
|
.test_beacon_blocks_root()
|
|
|
|
|
.await
|
|
|
|
|
.test_get_beacon_pool_attestations()
|
|
|
|
|
.await
|
|
|
|
|
.test_get_beacon_pool_attester_slashings()
|
|
|
|
|
.await
|
|
|
|
|
.test_get_beacon_pool_proposer_slashings()
|
|
|
|
|
.await
|
|
|
|
|
.test_get_beacon_pool_voluntary_exits()
|
|
|
|
|
.await;
|
2020-09-29 03:46:54 +00:00
|
|
|
}
|
|
|
|
|
|
2020-11-28 05:30:57 +00:00
|
|
|
#[tokio::test(flavor = "multi_thread", worker_threads = 2)]
|
2020-09-29 03:46:54 +00:00
|
|
|
async fn post_beacon_blocks_valid() {
|
2021-10-11 02:45:06 +00:00
|
|
|
ApiTester::new().await.test_post_beacon_blocks_valid().await;
|
2020-09-29 03:46:54 +00:00
|
|
|
}
|
|
|
|
|
|
2020-11-28 05:30:57 +00:00
|
|
|
#[tokio::test(flavor = "multi_thread", worker_threads = 2)]
|
2020-09-29 03:46:54 +00:00
|
|
|
async fn post_beacon_blocks_invalid() {
|
2021-10-11 02:45:06 +00:00
|
|
|
ApiTester::new()
|
|
|
|
|
.await
|
|
|
|
|
.test_post_beacon_blocks_invalid()
|
|
|
|
|
.await;
|
2020-09-29 03:46:54 +00:00
|
|
|
}
|
|
|
|
|
|
2020-11-28 05:30:57 +00:00
|
|
|
#[tokio::test(flavor = "multi_thread", worker_threads = 2)]
|
2020-09-29 03:46:54 +00:00
|
|
|
async fn beacon_pools_post_attestations_valid() {
|
|
|
|
|
ApiTester::new()
|
2021-10-11 02:45:06 +00:00
|
|
|
.await
|
2020-09-29 03:46:54 +00:00
|
|
|
.test_post_beacon_pool_attestations_valid()
|
|
|
|
|
.await;
|
|
|
|
|
}
|
|
|
|
|
|
2020-11-28 05:30:57 +00:00
|
|
|
#[tokio::test(flavor = "multi_thread", worker_threads = 2)]
|
2020-09-29 03:46:54 +00:00
|
|
|
async fn beacon_pools_post_attestations_invalid() {
|
|
|
|
|
ApiTester::new()
|
2021-10-11 02:45:06 +00:00
|
|
|
.await
|
2020-09-29 03:46:54 +00:00
|
|
|
.test_post_beacon_pool_attestations_invalid()
|
|
|
|
|
.await;
|
|
|
|
|
}
|
|
|
|
|
|
2020-11-28 05:30:57 +00:00
|
|
|
#[tokio::test(flavor = "multi_thread", worker_threads = 2)]
|
2020-09-29 03:46:54 +00:00
|
|
|
async fn beacon_pools_post_attester_slashings_valid() {
|
|
|
|
|
ApiTester::new()
|
2021-10-11 02:45:06 +00:00
|
|
|
.await
|
2020-09-29 03:46:54 +00:00
|
|
|
.test_post_beacon_pool_attester_slashings_valid()
|
|
|
|
|
.await;
|
|
|
|
|
}
|
|
|
|
|
|
2020-11-28 05:30:57 +00:00
|
|
|
#[tokio::test(flavor = "multi_thread", worker_threads = 2)]
|
2020-09-29 03:46:54 +00:00
|
|
|
async fn beacon_pools_post_attester_slashings_invalid() {
|
|
|
|
|
ApiTester::new()
|
2021-10-11 02:45:06 +00:00
|
|
|
.await
|
2020-09-29 03:46:54 +00:00
|
|
|
.test_post_beacon_pool_attester_slashings_invalid()
|
|
|
|
|
.await;
|
|
|
|
|
}
|
|
|
|
|
|
2020-11-28 05:30:57 +00:00
|
|
|
#[tokio::test(flavor = "multi_thread", worker_threads = 2)]
|
2020-09-29 03:46:54 +00:00
|
|
|
async fn beacon_pools_post_proposer_slashings_valid() {
|
|
|
|
|
ApiTester::new()
|
2021-10-11 02:45:06 +00:00
|
|
|
.await
|
2020-09-29 03:46:54 +00:00
|
|
|
.test_post_beacon_pool_proposer_slashings_valid()
|
|
|
|
|
.await;
|
|
|
|
|
}
|
|
|
|
|
|
2020-11-28 05:30:57 +00:00
|
|
|
#[tokio::test(flavor = "multi_thread", worker_threads = 2)]
|
2020-09-29 03:46:54 +00:00
|
|
|
async fn beacon_pools_post_proposer_slashings_invalid() {
|
|
|
|
|
ApiTester::new()
|
2021-10-11 02:45:06 +00:00
|
|
|
.await
|
2020-09-29 03:46:54 +00:00
|
|
|
.test_post_beacon_pool_proposer_slashings_invalid()
|
|
|
|
|
.await;
|
|
|
|
|
}
|
|
|
|
|
|
2020-11-28 05:30:57 +00:00
|
|
|
#[tokio::test(flavor = "multi_thread", worker_threads = 2)]
|
2020-09-29 03:46:54 +00:00
|
|
|
async fn beacon_pools_post_voluntary_exits_valid() {
|
|
|
|
|
ApiTester::new()
|
2021-10-11 02:45:06 +00:00
|
|
|
.await
|
2020-09-29 03:46:54 +00:00
|
|
|
.test_post_beacon_pool_voluntary_exits_valid()
|
|
|
|
|
.await;
|
|
|
|
|
}
|
|
|
|
|
|
2020-11-28 05:30:57 +00:00
|
|
|
#[tokio::test(flavor = "multi_thread", worker_threads = 2)]
|
2020-09-29 03:46:54 +00:00
|
|
|
async fn beacon_pools_post_voluntary_exits_invalid() {
|
|
|
|
|
ApiTester::new()
|
2021-10-11 02:45:06 +00:00
|
|
|
.await
|
2020-09-29 03:46:54 +00:00
|
|
|
.test_post_beacon_pool_voluntary_exits_invalid()
|
|
|
|
|
.await;
|
|
|
|
|
}
|
|
|
|
|
|
2020-11-28 05:30:57 +00:00
|
|
|
#[tokio::test(flavor = "multi_thread", worker_threads = 2)]
|
2020-09-29 03:46:54 +00:00
|
|
|
async fn config_get() {
|
|
|
|
|
ApiTester::new()
|
2021-10-11 02:45:06 +00:00
|
|
|
.await
|
2020-09-29 03:46:54 +00:00
|
|
|
.test_get_config_fork_schedule()
|
|
|
|
|
.await
|
|
|
|
|
.test_get_config_spec()
|
|
|
|
|
.await
|
|
|
|
|
.test_get_config_deposit_contract()
|
|
|
|
|
.await;
|
|
|
|
|
}
|
|
|
|
|
|
2020-11-28 05:30:57 +00:00
|
|
|
#[tokio::test(flavor = "multi_thread", worker_threads = 2)]
|
2020-09-29 03:46:54 +00:00
|
|
|
async fn debug_get() {
|
|
|
|
|
ApiTester::new()
|
2021-10-11 02:45:06 +00:00
|
|
|
.await
|
2020-09-29 03:46:54 +00:00
|
|
|
.test_get_debug_beacon_states()
|
|
|
|
|
.await
|
|
|
|
|
.test_get_debug_beacon_heads()
|
|
|
|
|
.await;
|
|
|
|
|
}
|
|
|
|
|
|
2020-11-28 05:30:57 +00:00
|
|
|
#[tokio::test(flavor = "multi_thread", worker_threads = 2)]
|
2020-09-29 03:46:54 +00:00
|
|
|
async fn node_get() {
|
|
|
|
|
ApiTester::new()
|
2021-10-11 02:45:06 +00:00
|
|
|
.await
|
2020-09-29 03:46:54 +00:00
|
|
|
.test_get_node_version()
|
|
|
|
|
.await
|
|
|
|
|
.test_get_node_syncing()
|
2020-10-22 02:59:42 +00:00
|
|
|
.await
|
|
|
|
|
.test_get_node_identity()
|
|
|
|
|
.await
|
|
|
|
|
.test_get_node_health()
|
|
|
|
|
.await
|
|
|
|
|
.test_get_node_peers_by_id()
|
|
|
|
|
.await
|
|
|
|
|
.test_get_node_peers()
|
2020-11-13 02:02:41 +00:00
|
|
|
.await
|
|
|
|
|
.test_get_node_peer_count()
|
2020-09-29 03:46:54 +00:00
|
|
|
.await;
|
|
|
|
|
}
|
|
|
|
|
|
2021-03-29 23:42:35 +00:00
|
|
|
#[tokio::test(flavor = "multi_thread", worker_threads = 2)]
|
|
|
|
|
async fn get_validator_duties_early() {
|
2021-10-11 02:45:06 +00:00
|
|
|
ApiTester::new()
|
|
|
|
|
.await
|
|
|
|
|
.test_get_validator_duties_early()
|
|
|
|
|
.await;
|
2021-03-29 23:42:35 +00:00
|
|
|
}
|
|
|
|
|
|
2020-11-28 05:30:57 +00:00
|
|
|
#[tokio::test(flavor = "multi_thread", worker_threads = 2)]
|
2020-09-29 03:46:54 +00:00
|
|
|
async fn get_validator_duties_attester() {
|
2021-10-11 02:45:06 +00:00
|
|
|
ApiTester::new()
|
|
|
|
|
.await
|
|
|
|
|
.test_get_validator_duties_attester()
|
|
|
|
|
.await;
|
2020-09-29 03:46:54 +00:00
|
|
|
}
|
|
|
|
|
|
2020-11-28 05:30:57 +00:00
|
|
|
#[tokio::test(flavor = "multi_thread", worker_threads = 2)]
|
2020-09-29 03:46:54 +00:00
|
|
|
async fn get_validator_duties_attester_with_skip_slots() {
|
|
|
|
|
ApiTester::new()
|
2021-10-11 02:45:06 +00:00
|
|
|
.await
|
2020-09-29 03:46:54 +00:00
|
|
|
.skip_slots(E::slots_per_epoch() * 2)
|
|
|
|
|
.test_get_validator_duties_attester()
|
|
|
|
|
.await;
|
|
|
|
|
}
|
|
|
|
|
|
2020-11-28 05:30:57 +00:00
|
|
|
#[tokio::test(flavor = "multi_thread", worker_threads = 2)]
|
2020-09-29 03:46:54 +00:00
|
|
|
async fn get_validator_duties_proposer() {
|
2021-10-11 02:45:06 +00:00
|
|
|
ApiTester::new()
|
|
|
|
|
.await
|
|
|
|
|
.test_get_validator_duties_proposer()
|
|
|
|
|
.await;
|
2020-09-29 03:46:54 +00:00
|
|
|
}
|
|
|
|
|
|
2020-11-28 05:30:57 +00:00
|
|
|
#[tokio::test(flavor = "multi_thread", worker_threads = 2)]
|
2020-09-29 03:46:54 +00:00
|
|
|
async fn get_validator_duties_proposer_with_skip_slots() {
|
|
|
|
|
ApiTester::new()
|
2021-10-11 02:45:06 +00:00
|
|
|
.await
|
2020-09-29 03:46:54 +00:00
|
|
|
.skip_slots(E::slots_per_epoch() * 2)
|
|
|
|
|
.test_get_validator_duties_proposer()
|
|
|
|
|
.await;
|
|
|
|
|
}
|
|
|
|
|
|
2020-11-28 05:30:57 +00:00
|
|
|
#[tokio::test(flavor = "multi_thread", worker_threads = 2)]
|
2020-09-29 03:46:54 +00:00
|
|
|
async fn block_production() {
|
2021-10-11 02:45:06 +00:00
|
|
|
ApiTester::new().await.test_block_production().await;
|
2020-09-29 03:46:54 +00:00
|
|
|
}
|
|
|
|
|
|
2020-11-28 05:30:57 +00:00
|
|
|
#[tokio::test(flavor = "multi_thread", worker_threads = 2)]
|
2020-09-29 03:46:54 +00:00
|
|
|
async fn block_production_with_skip_slots() {
|
|
|
|
|
ApiTester::new()
|
2021-10-11 02:45:06 +00:00
|
|
|
.await
|
2020-09-29 03:46:54 +00:00
|
|
|
.skip_slots(E::slots_per_epoch() * 2)
|
|
|
|
|
.test_block_production()
|
|
|
|
|
.await;
|
|
|
|
|
}
|
|
|
|
|
|
2022-03-28 07:14:13 +00:00
|
|
|
#[tokio::test(flavor = "multi_thread", worker_threads = 2)]
|
|
|
|
|
async fn block_production_no_verify_randao() {
|
|
|
|
|
ApiTester::new()
|
|
|
|
|
.await
|
|
|
|
|
.test_block_production_no_verify_randao()
|
|
|
|
|
.await;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
#[tokio::test(flavor = "multi_thread", worker_threads = 2)]
|
|
|
|
|
async fn block_production_verify_randao_invalid() {
|
|
|
|
|
ApiTester::new()
|
|
|
|
|
.await
|
|
|
|
|
.test_block_production_verify_randao_invalid()
|
|
|
|
|
.await;
|
|
|
|
|
}
|
|
|
|
|
|
2020-11-28 05:30:57 +00:00
|
|
|
#[tokio::test(flavor = "multi_thread", worker_threads = 2)]
|
2020-09-29 03:46:54 +00:00
|
|
|
async fn get_validator_attestation_data() {
|
2021-10-11 02:45:06 +00:00
|
|
|
ApiTester::new()
|
|
|
|
|
.await
|
|
|
|
|
.test_get_validator_attestation_data()
|
|
|
|
|
.await;
|
2020-09-29 03:46:54 +00:00
|
|
|
}
|
|
|
|
|
|
2020-11-28 05:30:57 +00:00
|
|
|
#[tokio::test(flavor = "multi_thread", worker_threads = 2)]
|
2020-09-29 03:46:54 +00:00
|
|
|
async fn get_validator_attestation_data_with_skip_slots() {
|
|
|
|
|
ApiTester::new()
|
2021-10-11 02:45:06 +00:00
|
|
|
.await
|
2020-09-29 03:46:54 +00:00
|
|
|
.skip_slots(E::slots_per_epoch() * 2)
|
|
|
|
|
.test_get_validator_attestation_data()
|
|
|
|
|
.await;
|
|
|
|
|
}
|
|
|
|
|
|
2020-11-28 05:30:57 +00:00
|
|
|
#[tokio::test(flavor = "multi_thread", worker_threads = 2)]
|
2020-09-29 03:46:54 +00:00
|
|
|
async fn get_validator_aggregate_attestation() {
|
|
|
|
|
ApiTester::new()
|
2021-10-11 02:45:06 +00:00
|
|
|
.await
|
2020-09-29 03:46:54 +00:00
|
|
|
.test_get_validator_aggregate_attestation()
|
|
|
|
|
.await;
|
|
|
|
|
}
|
|
|
|
|
|
2020-11-28 05:30:57 +00:00
|
|
|
#[tokio::test(flavor = "multi_thread", worker_threads = 2)]
|
2020-09-29 03:46:54 +00:00
|
|
|
async fn get_validator_aggregate_attestation_with_skip_slots() {
|
|
|
|
|
ApiTester::new()
|
2021-10-11 02:45:06 +00:00
|
|
|
.await
|
2020-09-29 03:46:54 +00:00
|
|
|
.skip_slots(E::slots_per_epoch() * 2)
|
|
|
|
|
.test_get_validator_aggregate_attestation()
|
|
|
|
|
.await;
|
|
|
|
|
}
|
|
|
|
|
|
2020-11-28 05:30:57 +00:00
|
|
|
#[tokio::test(flavor = "multi_thread", worker_threads = 2)]
|
2020-09-29 03:46:54 +00:00
|
|
|
async fn get_validator_aggregate_and_proofs_valid() {
|
|
|
|
|
ApiTester::new()
|
2021-10-11 02:45:06 +00:00
|
|
|
.await
|
2020-09-29 03:46:54 +00:00
|
|
|
.test_get_validator_aggregate_and_proofs_valid()
|
|
|
|
|
.await;
|
|
|
|
|
}
|
|
|
|
|
|
2020-11-28 05:30:57 +00:00
|
|
|
#[tokio::test(flavor = "multi_thread", worker_threads = 2)]
|
2020-09-29 03:46:54 +00:00
|
|
|
async fn get_validator_aggregate_and_proofs_valid_with_skip_slots() {
|
|
|
|
|
ApiTester::new()
|
2021-10-11 02:45:06 +00:00
|
|
|
.await
|
2020-09-29 03:46:54 +00:00
|
|
|
.skip_slots(E::slots_per_epoch() * 2)
|
|
|
|
|
.test_get_validator_aggregate_and_proofs_valid()
|
|
|
|
|
.await;
|
|
|
|
|
}
|
|
|
|
|
|
2020-11-28 05:30:57 +00:00
|
|
|
#[tokio::test(flavor = "multi_thread", worker_threads = 2)]
|
2020-09-29 03:46:54 +00:00
|
|
|
async fn get_validator_aggregate_and_proofs_invalid() {
|
|
|
|
|
ApiTester::new()
|
2021-10-11 02:45:06 +00:00
|
|
|
.await
|
2020-09-29 03:46:54 +00:00
|
|
|
.test_get_validator_aggregate_and_proofs_invalid()
|
|
|
|
|
.await;
|
|
|
|
|
}
|
|
|
|
|
|
2020-11-28 05:30:57 +00:00
|
|
|
#[tokio::test(flavor = "multi_thread", worker_threads = 2)]
|
2020-09-29 03:46:54 +00:00
|
|
|
async fn get_validator_aggregate_and_proofs_invalid_with_skip_slots() {
|
|
|
|
|
ApiTester::new()
|
2021-10-11 02:45:06 +00:00
|
|
|
.await
|
2020-09-29 03:46:54 +00:00
|
|
|
.skip_slots(E::slots_per_epoch() * 2)
|
|
|
|
|
.test_get_validator_aggregate_and_proofs_invalid()
|
|
|
|
|
.await;
|
|
|
|
|
}
|
|
|
|
|
|
2020-11-28 05:30:57 +00:00
|
|
|
#[tokio::test(flavor = "multi_thread", worker_threads = 2)]
|
2020-09-29 03:46:54 +00:00
|
|
|
async fn get_validator_beacon_committee_subscriptions() {
|
|
|
|
|
ApiTester::new()
|
2021-10-11 02:45:06 +00:00
|
|
|
.await
|
2020-09-29 03:46:54 +00:00
|
|
|
.test_get_validator_beacon_committee_subscriptions()
|
|
|
|
|
.await;
|
|
|
|
|
}
|
|
|
|
|
|
2022-06-30 00:49:21 +00:00
|
|
|
#[tokio::test(flavor = "multi_thread", worker_threads = 2)]
|
|
|
|
|
async fn post_validator_register_validator() {
|
|
|
|
|
ApiTester::new()
|
|
|
|
|
.await
|
|
|
|
|
.test_post_validator_register_validator()
|
|
|
|
|
.await;
|
|
|
|
|
}
|
|
|
|
|
|
2020-11-28 05:30:57 +00:00
|
|
|
#[tokio::test(flavor = "multi_thread", worker_threads = 2)]
|
2020-09-29 03:46:54 +00:00
|
|
|
async fn lighthouse_endpoints() {
|
|
|
|
|
ApiTester::new()
|
2021-10-11 02:45:06 +00:00
|
|
|
.await
|
2020-09-29 03:46:54 +00:00
|
|
|
.test_get_lighthouse_health()
|
|
|
|
|
.await
|
|
|
|
|
.test_get_lighthouse_syncing()
|
|
|
|
|
.await
|
|
|
|
|
.test_get_lighthouse_proto_array()
|
|
|
|
|
.await
|
|
|
|
|
.test_get_lighthouse_validator_inclusion()
|
|
|
|
|
.await
|
|
|
|
|
.test_get_lighthouse_validator_inclusion_global()
|
2020-10-22 06:05:49 +00:00
|
|
|
.await
|
2020-11-02 00:37:30 +00:00
|
|
|
.test_get_lighthouse_eth1_syncing()
|
|
|
|
|
.await
|
|
|
|
|
.test_get_lighthouse_eth1_block_cache()
|
|
|
|
|
.await
|
|
|
|
|
.test_get_lighthouse_eth1_deposit_cache()
|
|
|
|
|
.await
|
2020-10-22 06:05:49 +00:00
|
|
|
.test_get_lighthouse_beacon_states_ssz()
|
2020-11-23 01:00:22 +00:00
|
|
|
.await
|
|
|
|
|
.test_get_lighthouse_staking()
|
2021-07-31 03:50:52 +00:00
|
|
|
.await
|
2021-09-22 00:37:28 +00:00
|
|
|
.test_get_lighthouse_database_info()
|
|
|
|
|
.await
|
|
|
|
|
.test_post_lighthouse_database_reconstruct()
|
|
|
|
|
.await
|
2021-07-31 03:50:52 +00:00
|
|
|
.test_post_lighthouse_liveness()
|
2020-09-29 03:46:54 +00:00
|
|
|
.await;
|
|
|
|
|
}
|
