reth_node_api/node.rs
1//! Traits for configuring a node.
2
3use crate::PayloadTypes;
4use alloy_rpc_types_engine::JwtSecret;
5use reth_basic_payload_builder::PayloadBuilder;
6use reth_consensus::FullConsensus;
7use reth_db_api::{database_metrics::DatabaseMetrics, Database};
8use reth_engine_primitives::{ConsensusEngineEvent, ConsensusEngineHandle};
9use reth_evm::{ConfigureEvm, SenderRecoveryCache};
10use reth_network_api::FullNetwork;
11use reth_node_core::node_config::NodeConfig;
12use reth_node_types::{NodeTypes, NodeTypesWithDBAdapter, TxTy};
13use reth_payload_builder::PayloadBuilderHandle;
14use reth_provider::FullProvider;
15use reth_tasks::TaskExecutor;
16use reth_tokio_util::EventSender;
17use reth_transaction_pool::{PoolTransaction, TransactionPool};
18use std::{fmt::Debug, future::Future, marker::PhantomData};
19
20/// A helper trait that is downstream of the [`NodeTypes`] trait and adds stateful
21/// components to the node.
22///
23/// Its types are configured by node internally and are not intended to be user configurable.
24pub trait FullNodeTypes: Clone + Debug + Send + Sync + Unpin + 'static {
25 /// Node's types with the database.
26 type Types: NodeTypes;
27 /// Underlying database type used by the node to store and retrieve data.
28 type DB: Database + DatabaseMetrics + Clone + Unpin + 'static;
29 /// The provider type used to interact with the node.
30 type Provider: FullProvider<NodeTypesWithDBAdapter<Self::Types, Self::DB>>;
31}
32
33/// An adapter type that adds the builtin provider type to the user configured node types.
34#[derive(Clone, Debug)]
35pub struct FullNodeTypesAdapter<Types, DB, Provider>(PhantomData<(Types, DB, Provider)>);
36
37impl<Types, DB, Provider> FullNodeTypes for FullNodeTypesAdapter<Types, DB, Provider>
38where
39 Types: NodeTypes,
40 DB: Database + DatabaseMetrics + Clone + Unpin + 'static,
41 Provider: FullProvider<NodeTypesWithDBAdapter<Types, DB>>,
42{
43 type Types = Types;
44 type DB = DB;
45 type Provider = Provider;
46}
47
48/// Helper trait to bound [`PayloadBuilder`] to the node's engine types.
49pub trait PayloadBuilderFor<N: NodeTypes>:
50 PayloadBuilder<
51 Attributes = <N::Payload as PayloadTypes>::PayloadAttributes,
52 BuiltPayload = <N::Payload as PayloadTypes>::BuiltPayload,
53>
54{
55}
56
57impl<T, N: NodeTypes> PayloadBuilderFor<N> for T where
58 T: PayloadBuilder<
59 Attributes = <N::Payload as PayloadTypes>::PayloadAttributes,
60 BuiltPayload = <N::Payload as PayloadTypes>::BuiltPayload,
61 >
62{
63}
64
65/// Encapsulates all types and components of the node.
66pub trait FullNodeComponents: FullNodeTypes + Clone + 'static {
67 /// The transaction pool of the node.
68 type Pool: TransactionPool<Transaction: PoolTransaction<Consensus = TxTy<Self::Types>>> + Unpin;
69
70 /// The node's EVM configuration, defining settings for the Ethereum Virtual Machine.
71 type Evm: ConfigureEvm<Primitives = <Self::Types as NodeTypes>::Primitives>;
72
73 /// The consensus type of the node.
74 type Consensus: FullConsensus<<Self::Types as NodeTypes>::Primitives> + Clone + Unpin + 'static;
75
76 /// Network API.
77 type Network: FullNetwork;
78
79 /// Returns the transaction pool of the node.
80 fn pool(&self) -> &Self::Pool;
81
82 /// Returns the node's evm config.
83 fn evm_config(&self) -> &Self::Evm;
84
85 /// Returns the node's consensus type.
86 fn consensus(&self) -> &Self::Consensus;
87
88 /// Returns the handle to the network
89 fn network(&self) -> &Self::Network;
90
91 /// Returns the handle to the payload builder service handling payload building requests from
92 /// the engine.
93 fn payload_builder_handle(&self) -> &PayloadBuilderHandle<<Self::Types as NodeTypes>::Payload>;
94
95 /// Returns the provider of the node.
96 fn provider(&self) -> &Self::Provider;
97
98 /// Returns an executor handle to spawn tasks.
99 ///
100 /// This can be used to spawn critical, blocking tasks or register tasks that should be
101 /// terminated gracefully.
102 fn task_executor(&self) -> &TaskExecutor;
103}
104
105/// Context passed to [`NodeAddOns::launch_add_ons`],
106#[derive(Debug, Clone)]
107pub struct AddOnsContext<'a, N: FullNodeComponents> {
108 /// Node with all configured components.
109 pub node: N,
110 /// Node configuration.
111 pub config: &'a NodeConfig<<N::Types as NodeTypes>::ChainSpec>,
112 /// Handle to the beacon consensus engine.
113 pub beacon_engine_handle: ConsensusEngineHandle<<N::Types as NodeTypes>::Payload>,
114 /// Notification channel for engine API events
115 pub engine_events: EventSender<ConsensusEngineEvent<<N::Types as NodeTypes>::Primitives>>,
116 /// JWT secret for the node.
117 pub jwt_secret: JwtSecret,
118 /// Cache of recovered transaction senders shared by node components, if enabled.
119 pub sender_recovery_cache: Option<SenderRecoveryCache>,
120}
121
122/// Customizable node add-on types.
123///
124/// This trait defines the interface for extending a node with additional functionality beyond
125/// the core [`FullNodeComponents`]. It provides a way to launch supplementary services such as
126/// RPC servers, monitoring, external integrations, or any custom functionality that builds on
127/// top of the core node components.
128///
129/// ## Purpose
130///
131/// The `NodeAddOns` trait serves as an extension point in the node builder architecture,
132/// allowing developers to:
133/// - Define custom services that run alongside the main node
134/// - Access all node components and configuration during initialization
135/// - Return a handle for managing the launched services (e.g. handle to rpc server)
136///
137/// ## How it fits into `NodeBuilder`
138///
139/// In the node builder pattern, add-ons are the final layer that gets applied after all core
140/// components are configured and started. The builder flow typically follows:
141///
142/// 1. Configure [`NodeTypes`] (chain spec, database types, etc.)
143/// 2. Build [`FullNodeComponents`] (consensus, networking, transaction pool, etc.)
144/// 3. Launch [`NodeAddOns`] with access to all components via [`AddOnsContext`]
145///
146/// ## Primary Use Case
147///
148/// The primary use of this trait is to launch RPC servers that provide external API access to
149/// the node. For Ethereum nodes, this typically includes two main servers: the regular RPC
150/// server (HTTP/WS/IPC) that handles user requests and the authenticated Engine API server
151/// that communicates with the consensus layer. The returned handle contains the necessary
152/// endpoints and control mechanisms for these servers, allowing the node to serve JSON-RPC
153/// requests and participate in consensus. While RPC is the main use case, the trait is
154/// intentionally flexible to support other kinds of add-ons such as monitoring, indexing, or
155/// custom protocol extensions.
156///
157/// ## Context Access
158///
159/// The [`AddOnsContext`] provides access to:
160/// - All node components via the `node` field
161/// - Node configuration
162/// - Engine API handles for consensus layer communication
163/// - JWT secrets for authenticated endpoints
164///
165/// This ensures add-ons can integrate deeply with the node while maintaining clean separation
166/// of concerns.
167pub trait NodeAddOns<N: FullNodeComponents>: Send {
168 /// Handle to add-ons.
169 ///
170 /// This type is returned by [`launch_add_ons`](Self::launch_add_ons) and represents a
171 /// handle to the launched services. It must be `Clone` to allow multiple components to
172 /// hold references and should provide methods to interact with the running services.
173 ///
174 /// For RPC add-ons, this typically includes:
175 /// - Server handles to access local addresses and shutdown methods
176 /// - RPC module registry for runtime inspection of available methods
177 /// - Configured middleware and transport-specific settings
178 /// - For Engine API implementations, this also includes handles for consensus layer
179 /// communication
180 type Handle: Send + Sync + Clone;
181
182 /// Configures and launches the add-ons.
183 ///
184 /// This method is called once during node startup after all core components are initialized.
185 /// It receives an [`AddOnsContext`] that provides access to:
186 ///
187 /// - The fully configured node with all its components
188 /// - Node configuration for reading settings
189 /// - Engine API handles for consensus layer communication
190 /// - JWT secrets for setting up authenticated endpoints (if any).
191 ///
192 /// The implementation should:
193 /// 1. Use the context to configure the add-on services
194 /// 2. Launch any background tasks using the node's task executor
195 /// 3. Return a handle that allows interaction with the launched services
196 ///
197 /// # Errors
198 ///
199 /// This method may fail if the add-ons cannot be properly configured or launched,
200 /// for example due to port binding issues or invalid configuration.
201 fn launch_add_ons(
202 self,
203 ctx: AddOnsContext<'_, N>,
204 ) -> impl Future<Output = eyre::Result<Self::Handle>> + Send;
205}
206
207impl<N: FullNodeComponents> NodeAddOns<N> for () {
208 type Handle = ();
209
210 async fn launch_add_ons(self, _components: AddOnsContext<'_, N>) -> eyre::Result<Self::Handle> {
211 Ok(())
212 }
213}