Skip to content

Conversation

@0xKarl98
Copy link
Contributor

@0xKarl98 0xKarl98 commented Dec 3, 2025

This aims to reoslve this issue #20069 , summerized as below :

  • Implemented the testing_buildBlockV1 RPC namespace (testing-only, default disabled) per spec:
    • Added TestingApi and TestingBuildBlockRequest (camelCase, payloadAttributes+transactions+extraData) in rpc-ap

    • Implemented server-side handler and builder: TestingBlockBuilder trait and EthTestingBlockBuilder execute only the provided raw signed transactions (order preserved), reject blob tx without sidecars, apply payloadAttributes/extraData, and return ExecutionPayloadEnvelopeV4 without touching the canonical chain.

    • Wired conditional registration: hidden CLI flags --http.testing / --ws.testing add testing to module selection, and in Ethereum node we construct EthTestingBlockBuilder and merge TestingApi only when the testing module is explicitly requested. Security note added to API docs

    • Expose a hidden --testing.max-concurrent flag (default 1), and wire testing RPC instantiation to use a semaphore + spawn_blocking so heavy block builds don’t block the async runtime and have bounded concurrency

References :
testing_buildBlockV1.md

cc @mattsse

@0xKarl98 0xKarl98 marked this pull request as draft December 4, 2025 02:57
@0xKarl98 0xKarl98 marked this pull request as ready for review December 4, 2025 04:47
@0xKarl98
Copy link
Contributor Author

0xKarl98 commented Dec 4, 2025

@mattsse Should we support testing blob/sidecar transactions here ?

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.

this looks pretty good already

left some suggestions

Copy link
Collaborator

Choose a reason for hiding this comment

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

these args we can exclude, we can make it so that --http.api also accepts testing

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Yeah we can exclude that and make it more simple

/// Request payload for `testing_buildBlockV1`.
#[derive(Debug, Clone, Serialize, Deserialize)]
#[serde(rename_all = "camelCase")]
pub struct TestingBuildBlockRequest {
Copy link
Collaborator

Choose a reason for hiding this comment

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

let's name this V1

Suggested change
pub struct TestingBuildBlockRequest {
pub struct TestingBuildBlockRequestV1 {

Copy link
Collaborator

Choose a reason for hiding this comment

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

we can exclude this from here, and instead instantiate and install here

container
.modules
.merge_if_module_configured(RethRpcModule::Eth, eth_config.into_rpc())?;

Copy link
Collaborator

Choose a reason for hiding this comment

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

these changes we can all undo because we can instantiate this on demand specifically for eth

similar to flashbots api:

container.modules.merge_if_module_configured(
RethRpcModule::Flashbots,
validation_api.into_rpc(),
)?;

Comment on lines 156 to 159
async fn build_block(
&self,
request: TestingBuildBlockRequest,
) -> RpcResult<ExecutionPayloadEnvelopeV4> {
Copy link
Collaborator

Choose a reason for hiding this comment

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

this entire fn logic we need to spawn as blocking, ideally also add a semaphor for this so we can limit how many requests we allow at the same time

Copy link
Contributor Author

@0xKarl98 0xKarl98 Dec 4, 2025

Choose a reason for hiding this comment

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

In terms of the semaphor , which number do you think is appropriate by default ?

I just set the concurrent number to at least 1 and can be overriten if value provided

@github-project-automation github-project-automation bot moved this from Backlog to In Progress in Reth Tracker Dec 4, 2025
@0xKarl98 0xKarl98 requested a review from mattsse December 5, 2025 03:43
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

Status: In Progress

Development

Successfully merging this pull request may close these issues.

2 participants