Skip to content

pallet-revive-eth-rpc: Introduce SubstrateClientT trait abstraction and Asset Hub embedded RPC integration#11297

Open
Nathy-bajo wants to merge 35 commits intoparitytech:masterfrom
Nathy-bajo:pallet_revive_refactor
Open

pallet-revive-eth-rpc: Introduce SubstrateClientT trait abstraction and Asset Hub embedded RPC integration#11297
Nathy-bajo wants to merge 35 commits intoparitytech:masterfrom
Nathy-bajo:pallet_revive_refactor

Conversation

@Nathy-bajo
Copy link
Copy Markdown
Contributor

closes #11221

Removes the revive-dev-node standalone binary and integrates the pallet-revive ETH RPC server directly into the Asset Hub (Omni) node. Introduces a SubstrateClientT trait that abstracts all Substrate node interactions, allowing EthRpcServerImpl to be generic over its backend. A new NativeSubstrateClient implementation backed by sc_client_api traits provides a direct in-process path with no subxt dependency on the hot path. The SubxtClient path is preserved unchanged for the standalone eth-rpc binary. On the node side, BuildAssetHubRpcExtensions is added to polkadot-omni-node-lib behind an opt-in revive-rpc feature, registering the full eth_*/debug_*/net_*/web3_* surface on the standard RPC port alongside existing parachain RPCs.

@Nathy-bajo Nathy-bajo requested a review from a team as a code owner March 6, 2026 13:22
@Nathy-bajo Nathy-bajo requested a review from seunlanlege March 6, 2026 21:09
@Nathy-bajo Nathy-bajo requested a review from seunlanlege March 9, 2026 11:30
@Nathy-bajo Nathy-bajo requested a review from Wizdave97 March 9, 2026 16:11
@Nathy-bajo
Copy link
Copy Markdown
Contributor Author

@Wizdave97 @seunlanlege Ready for review

Copy link
Copy Markdown
Contributor

@pgherveou pgherveou left a comment

Choose a reason for hiding this comment

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

Thanks for putting that together.

Before we can move forward, we need to check with the Node team
if they are ok adding these dependencies to the omninode cc @skunert

One of the reason we didn't do it initially was:

  • 1 so we could move fast and deploy new version without touching the client.
  • 2 so that it's not tied to a client implementation. But I guess since most collator should run the omni -ode and there are no other collator implementation, that doesn't really matter.

The eth server is more stable now so it make sense to remove the requirement for a second binary / host url, and your design allow to keep both the binary inside the client and to build it as a separate binary with subxt.

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

To simplify the review and not scare the reviewer, I would move the dev-node deletion to a follow up

@pgherveou
Copy link
Copy Markdown
Contributor

Also tried to build it locally but seems not to compile yet.
Better to keep the PR in draft mode until CI / build pass and it's actually ready for reviews

@Nathy-bajo
Copy link
Copy Markdown
Contributor Author

Also tried to build it locally but seems not to compile yet. Better to keep the PR in draft mode until CI / build pass and it's actually ready for reviews

Thanks for the review, fixing ci

@Nathy-bajo Nathy-bajo requested a review from a team as a code owner March 11, 2026 12:48
@paritytech-review-bot paritytech-review-bot bot requested review from a team March 11, 2026 12:49
@Nathy-bajo Nathy-bajo marked this pull request as draft March 11, 2026 13:02
@Nathy-bajo Nathy-bajo marked this pull request as ready for review March 11, 2026 15:30
@Nathy-bajo Nathy-bajo requested a review from pgherveou March 17, 2026 14:32
@Nathy-bajo Nathy-bajo requested review from a team as code owners March 20, 2026 13:02
})
}

async fn system_health(&self) -> Result<NodeHealth, ClientError> {
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

Could the network service be passed in so we get real peer count and sync status?

@paritytech-review-bot paritytech-review-bot bot requested a review from a team April 2, 2026 23:14
@Nathy-bajo Nathy-bajo requested a review from marian-radu April 2, 2026 23:15
@Nathy-bajo
Copy link
Copy Markdown
Contributor Author

@marian-radu What's the right way to regenerate revive_chain.scale against the current branch? Now that polkadot-omni-node-lib uses pallet-revive-eth-rpc as a direct runtime dependency. revive-dev-runtime is a dev runtime that conveniently uses the polkadot-sdk umbrella crate, we can't have it as a build dependency in the pallet-revive-eth-rpc anymore

@marian-radu
Copy link
Copy Markdown
Contributor

@marian-radu What's the right way to regenerate revive_chain.scale against the current branch? Now that polkadot-omni-node-lib uses pallet-revive-eth-rpc as a direct runtime dependency. revive-dev-runtime is a dev runtime that conveniently uses the polkadot-sdk umbrella crate, we can't have it as a build dependency in the pallet-revive-eth-rpc anymore

I propose migrating revive-dev-runtime off polkadot-sdk umbrella to individual crate dependencies to break the circular dependency

With that done, revive-dev-runtime can stay as a build dependency (gated behind the subxt feature), and polkadot-omni-node-lib can depend on pallet-revive-eth-rpc with default-features = false — so the native path doesn't need subxt or the .scale file at all.

I pushed a gist with this approach as a reference: (generated with Claude Code, so treat it as a starting point)

The key changes:

  • revive-dev-runtime/Cargo.toml — individual crates instead of umbrella
  • pallet-revive-eth-rpc/Cargo.toml — revive-dev-runtime + sp-io as optional build deps under subxt
  • pallet-revive-eth-rpc/build.rs — restore generate_metadata_file() behind #[cfg(feature = "subxt")]
  • polkadot-omni-node-lib/Cargo.toml — default-features = false for pallet-revive-eth-rpc

@Nathy-bajo
Copy link
Copy Markdown
Contributor Author

/cmd prdoc --audience node_dev --bump patch

@Nathy-bajo
Copy link
Copy Markdown
Contributor Author

@marian-radu What's the right way to regenerate revive_chain.scale against the current branch? Now that polkadot-omni-node-lib uses pallet-revive-eth-rpc as a direct runtime dependency. revive-dev-runtime is a dev runtime that conveniently uses the polkadot-sdk umbrella crate, we can't have it as a build dependency in the pallet-revive-eth-rpc anymore

I propose migrating revive-dev-runtime off polkadot-sdk umbrella to individual crate dependencies to break the circular dependency

With that done, revive-dev-runtime can stay as a build dependency (gated behind the subxt feature), and polkadot-omni-node-lib can depend on pallet-revive-eth-rpc with default-features = false — so the native path doesn't need subxt or the .scale file at all.

I pushed a gist with this approach as a reference: (generated with Claude Code, so treat it as a starting point)

The key changes:

  • revive-dev-runtime/Cargo.toml — individual crates instead of umbrella
  • pallet-revive-eth-rpc/Cargo.toml — revive-dev-runtime + sp-io as optional build deps under subxt
  • pallet-revive-eth-rpc/build.rs — restore generate_metadata_file() behind #[cfg(feature = "subxt")]
  • polkadot-omni-node-lib/Cargo.toml — default-features = false for pallet-revive-eth-rpc

All done and ready for review, thank you!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

T7-smart_contracts This PR/Issue is related to smart contracts.

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Integrate pallet-revive RPC Server into Asset Hub Node (Remove subxt Dependency)

5 participants