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.

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

Access to BeaconConsensusEngine API #14241

Closed
Dinonard opened this issue Feb 5, 2025 · 4 comments · Fixed by #14348
Closed

Access to BeaconConsensusEngine API #14241

Dinonard opened this issue Feb 5, 2025 · 4 comments · Fixed by #14348
Assignees
Labels
A-sdk Related to reth's use as a library C-enhancement New feature or request S-needs-design This issue requires design work to think about how it would best be accomplished

Comments

@Dinonard
Copy link

Dinonard commented Feb 5, 2025

Describe the feature

Description

Right now it's possible to get access to RethAPi from the code, as in custom-dev-node example

let eth_api = node.rpc_registry.eth_api();
let hash = eth_api.send_raw_transaction(raw_tx.into()).await?;

However, it's not possible to do the same for the EngineApi, as far as I could find.
E.g. I cannot (easily?) get access to EthBeaconConsensus.

The reason I'd like to have this is to be able to send consensus messages directly to the Reth node from the code.

Something like this:

let engine_api = node.rpc_registry.engine_api();
engine_api.fork_choice_update_v3(...);

Example

Perhaps it's easiest approach to demonstrate via an example.
But please note that I'm not advocating this as a "solution", just showcasing a local workaround I did, as an example.

I've modified the DefaultNodeLauncher to look like this:

/// The default launcher for a node.
#[derive(Debug)]
pub struct DefaultNodeLauncher<Types: NodeTypesWithEngine + NodeTypesForTree> {
    /// The task executor for the node.
    pub ctx: LaunchContext,
    pub tx_rx_consensus: (
        UnboundedSender<BeaconEngineMessage<Types::Engine>>,
        UnboundedReceiver<BeaconEngineMessage<Types::Engine>>,
    ),
}

impl<Types> DefaultNodeLauncher<Types>
where
    Types: NodeTypesWithEngine + NodeTypesForTree,
{
    /// Create a new instance of the default node launcher.
    pub const fn new(
        task_executor: TaskExecutor,
        data_dir: ChainPath<DataDirPath>,
        tx_rx_consensus: (
            UnboundedSender<BeaconEngineMessage<Types::Engine>>,
            UnboundedReceiver<BeaconEngineMessage<Types::Engine>>,
        ),
    ) -> Self {
        Self {
            ctx: LaunchContext::new(task_executor, data_dir),
            tx_rx_consensus,
        }
    }
}

Injection of tx_rx_consensus allows me to get access to the consensus engine, which is exactly what I want.

tx_consensus.send(BeaconEngineMessage::ForkchoiceUpdated {...});

Request

If this is already possible, I was not able to find it.
If not, it'd be great if this could be added!

I don't mind trying to make a PR for this.

Additional context

No response

@Dinonard Dinonard added C-enhancement New feature or request S-needs-triage This issue needs to be labelled labels Feb 5, 2025
@mattsse
Copy link
Collaborator

mattsse commented Feb 5, 2025

this is similar to #14097 at least for the events

are you looking interested in receiving incoming BeaconEngineMessage or triggering those?

because for triggering those, a workaround would be sending it via rpc

@mattsse mattsse added S-needs-design This issue requires design work to think about how it would best be accomplished A-sdk Related to reth's use as a library and removed S-needs-triage This issue needs to be labelled labels Feb 5, 2025
@Dinonard
Copy link
Author

Dinonard commented Feb 6, 2025

are you looking interested in receiving incoming BeaconEngineMessage or triggering those?

because for triggering those, a workaround would be sending it via rpc

Triggering, e.g. like in the example:

let engine_api = node.rpc_registry.engine_api();
engine_api.fork_choice_update_v3(...);

I could use RPC, but then it's not directly from the code.
At least not without RPC overhead.

E.g. from the example I linked, this is supposed to be possible:

let eth_api = node.rpc_registry.eth_api();
let hash = eth_api.send_raw_transaction(raw_tx.into()).await?;

It'd be good if alongside all the APIs that are already exposed, the one for engine would be as well.

@mattsse
Copy link
Collaborator

mattsse commented Feb 6, 2025

I see,

we can likely make this work, althought the rpc overhead is probably negligible we also use it like this for testing, because this also contains a few additional validations

@mattsse
Copy link
Collaborator

mattsse commented Feb 6, 2025

actually, adding these into the launcher isn't a bad idea

will think about how to approach this, ty

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-sdk Related to reth's use as a library C-enhancement New feature or request S-needs-design This issue requires design work to think about how it would best be accomplished
Projects
Archived in project
Development

Successfully merging a pull request may close this issue.

2 participants