Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

feat: wire components in EthService #9621

Merged
merged 4 commits into from
Jul 19, 2024
Merged

feat: wire components in EthService #9621

merged 4 commits into from
Jul 19, 2024

Conversation

fgimenez
Copy link
Member

@fgimenez fgimenez commented Jul 18, 2024 •
edited
Loading

Closes: #9576

@fgimenez fgimenez marked this pull request as ready for review July 18, 2024 19:28
fgimenez
fgimenez commented Jul 18, 2024
View reviewed changes
crates/engine/tree/src/tree/mod.rs
use tracing::*;

mod memory_overlay;
pub use memory_overlay::MemoryOverlayStateProvider;

/// Maximum number of blocks to be kept only in memory without triggering persistence.
const PERSISTENCE_THRESHOLD: u64 = 256;
/// Number of pending blocks that cannot be executed due to missing parent and
/// are kept in cache.
const DEFAULT_BLOCK_BUFFER_LIMIT: u32 = 256;
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

These constants are defined to be able to instantiate EngineApiTreeState when building the tree, lmk wdyt

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think this makes sense, given how the block buffer works rn

crates/engine/tree/src/tree/mod.rs
provider: P,
executor_provider: E,
consensus: Arc<dyn Consensus>,
payload_validator: ExecutionPayloadValidator,
incoming: Receiver<FromEngine<BeaconEngineMessage<T>>>,
state: EngineApiTreeState,
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

state and header are initialized in the constructor, is there any case when we want to inject them?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm thinking we should have the header as an argument, or initialize it differently. For example we probably want to set it as the highest persisted block on node startup

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

makes sense, done here 7881e2e

crates/ethereum/node/src/launch.rs
@@ -159,22 +158,17 @@ where

let pruner_events = pruner.events();
info!(target: "reth::cli", prune_config=?ctx.prune_config().unwrap_or_default(), "Pruner initialized");
hooks.add(PruneHook::new(pruner, Box::new(ctx.task_executor().clone())));
Copy link
Member Author

@fgimenez fgimenez Jul 18, 2024 •
edited
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

instead of in hooks, pruner is consumed when creating the service, otherwise we should be able to clone it or have different pruners, wdyt?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Making the service consume the pruner makes sense to me imo, since we will do things with the pruner in the eth service

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I like this

Rjected
Rjected approved these changes Jul 18, 2024
View reviewed changes
Copy link
Member

@Rjected Rjected left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This looks good to me, note the comment about the header

crates/ethereum/node/src/launch.rs
@@ -159,22 +158,17 @@ where

let pruner_events = pruner.events();
info!(target: "reth::cli", prune_config=?ctx.prune_config().unwrap_or_default(), "Pruner initialized");
hooks.add(PruneHook::new(pruner, Box::new(ctx.task_executor().clone())));
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Making the service consume the pruner makes sense to me imo, since we will do things with the pruner in the eth service

crates/engine/tree/src/tree/mod.rs
use tracing::*;

mod memory_overlay;
pub use memory_overlay::MemoryOverlayStateProvider;

/// Maximum number of blocks to be kept only in memory without triggering persistence.
const PERSISTENCE_THRESHOLD: u64 = 256;
/// Number of pending blocks that cannot be executed due to missing parent and
/// are kept in cache.
const DEFAULT_BLOCK_BUFFER_LIMIT: u32 = 256;
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think this makes sense, given how the block buffer works rn

crates/engine/tree/src/tree/mod.rs
provider: P,
executor_provider: E,
consensus: Arc<dyn Consensus>,
payload_validator: ExecutionPayloadValidator,
incoming: Receiver<FromEngine<BeaconEngineMessage<T>>>,
state: EngineApiTreeState,
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm thinking we should have the header as an argument, or initialize it differently. For example we probably want to set it as the highest persisted block on node startup

mattsse
mattsse approved these changes Jul 19, 2024
View reviewed changes
Copy link
Collaborator

@mattsse mattsse left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

lgtm

crates/ethereum/node/src/launch.rs
@@ -159,22 +158,17 @@ where

let pruner_events = pruner.events();
info!(target: "reth::cli", prune_config=?ctx.prune_config().unwrap_or_default(), "Pruner initialized");
hooks.add(PruneHook::new(pruner, Box::new(ctx.task_executor().clone())));
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I like this

crates/ethereum/engine/src/service.rs
incoming_requests: UnboundedReceiverStream<BeaconEngineMessage<EthEngineTypes>>,
pipeline: Pipeline<DB>,
pipeline_task_spawner: Box<dyn TaskSpawner>,
provider: ProviderFactory<DB>,
blockchain_db: BlockchainProvider<DB>,
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

mental note here, that this type will change,
we could also operate on the provider traits here, but for now these seems easier
The inmemory state could then be obtained from this provider as well

@fgimenez fgimenez force-pushed the fgimenez/ethservice-integrate-tree-and-persistence branch from 7881e2e to 45ab518 Compare July 19, 2024 08:39
@fgimenez fgimenez enabled auto-merge July 19, 2024 08:49
@fgimenez fgimenez added this pull request to the merge queue Jul 19, 2024
Merged via the queue into main with commit 2b3047f Jul 19, 2024
33 checks passed
@fgimenez fgimenez deleted the fgimenez/ethservice-integrate-tree-and-persistence branch July 19, 2024 09:05
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Reviewers

@mattsse mattsse mattsse approved these changes

@Rjected Rjected Rjected approved these changes

@rkrasiuk rkrasiuk Awaiting requested review from rkrasiuk rkrasiuk is a code owner

@gakonst gakonst Awaiting requested review from gakonst gakonst is a code owner

Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

Successfully merging this pull request may close these issues.

Integrate tree and persistence setup in EthService
3 participants
@fgimenez @Rjected @mattsse