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}