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;
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>::PayloadBuilderAttributes,
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>::PayloadBuilderAttributes,
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. See also [`TaskSpawner`](reth_tasks::TaskSpawner).
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}
119
120/// Customizable node add-on types.
121///
122/// This trait defines the interface for extending a node with additional functionality beyond
123/// the core [`FullNodeComponents`]. It provides a way to launch supplementary services such as
124/// RPC servers, monitoring, external integrations, or any custom functionality that builds on
125/// top of the core node components.
126///
127/// ## Purpose
128///
129/// The `NodeAddOns` trait serves as an extension point in the node builder architecture,
130/// allowing developers to:
131/// - Define custom services that run alongside the main node
132/// - Access all node components and configuration during initialization
133/// - Return a handle for managing the launched services (e.g. handle to rpc server)
134///
135/// ## How it fits into `NodeBuilder`
136///
137/// In the node builder pattern, add-ons are the final layer that gets applied after all core
138/// components are configured and started. The builder flow typically follows:
139///
140/// 1. Configure [`NodeTypes`] (chain spec, database types, etc.)
141/// 2. Build [`FullNodeComponents`] (consensus, networking, transaction pool, etc.)
142/// 3. Launch [`NodeAddOns`] with access to all components via [`AddOnsContext`]
143///
144/// ## Primary Use Case
145///
146/// The primary use of this trait is to launch RPC servers that provide external API access to
147/// the node. For Ethereum nodes, this typically includes two main servers: the regular RPC
148/// server (HTTP/WS/IPC) that handles user requests and the authenticated Engine API server
149/// that communicates with the consensus layer. The returned handle contains the necessary
150/// endpoints and control mechanisms for these servers, allowing the node to serve JSON-RPC
151/// requests and participate in consensus. While RPC is the main use case, the trait is
152/// intentionally flexible to support other kinds of add-ons such as monitoring, indexing, or
153/// custom protocol extensions.
154///
155/// ## Context Access
156///
157/// The [`AddOnsContext`] provides access to:
158/// - All node components via the `node` field
159/// - Node configuration
160/// - Engine API handles for consensus layer communication
161/// - JWT secrets for authenticated endpoints
162///
163/// This ensures add-ons can integrate deeply with the node while maintaining clean separation
164/// of concerns.
165pub trait NodeAddOns<N: FullNodeComponents>: Send {
166 /// Handle to add-ons.
167 ///
168 /// This type is returned by [`launch_add_ons`](Self::launch_add_ons) and represents a
169 /// handle to the launched services. It must be `Clone` to allow multiple components to
170 /// hold references and should provide methods to interact with the running services.
171 ///
172 /// For RPC add-ons, this typically includes:
173 /// - Server handles to access local addresses and shutdown methods
174 /// - RPC module registry for runtime inspection of available methods
175 /// - Configured middleware and transport-specific settings
176 /// - For Engine API implementations, this also includes handles for consensus layer
177 /// communication
178 type Handle: Send + Sync + Clone;
179
180 /// Configures and launches the add-ons.
181 ///
182 /// This method is called once during node startup after all core components are initialized.
183 /// It receives an [`AddOnsContext`] that provides access to:
184 ///
185 /// - The fully configured node with all its components
186 /// - Node configuration for reading settings
187 /// - Engine API handles for consensus layer communication
188 /// - JWT secrets for setting up authenticated endpoints (if any).
189 ///
190 /// The implementation should:
191 /// 1. Use the context to configure the add-on services
192 /// 2. Launch any background tasks using the node's task executor
193 /// 3. Return a handle that allows interaction with the launched services
194 ///
195 /// # Errors
196 ///
197 /// This method may fail if the add-ons cannot be properly configured or launched,
198 /// for example due to port binding issues or invalid configuration.
199 fn launch_add_ons(
200 self,
201 ctx: AddOnsContext<'_, N>,
202 ) -> impl Future<Output = eyre::Result<Self::Handle>> + Send;
203}
204
205impl<N: FullNodeComponents> NodeAddOns<N> for () {
206 type Handle = ();
207
208 async fn launch_add_ons(self, _components: AddOnsContext<'_, N>) -> eyre::Result<Self::Handle> {
209 Ok(())
210 }
211}