Skip to content

Client: make JSON-RPC payload limits configurable for eth and engine servers #3993

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

Open
wants to merge 4 commits into
base: master
Choose a base branch
from

Conversation

ether-wan
Copy link

@ether-wan ether-wan commented Apr 18, 2025

This PR closes Issue #3981 by introducing two new configuration options: rpcEthMaxPayload & rpcEngineMaxPayload

These options allow setting different maximum JSON-RPC payload sizes for the eth/debug and engine RPC server.

What news ?

  • Added rpcEthMaxPayload and rpcEngineMaxPayload fields in the Config class.

  • Extended the CLI options to allow users to configure these payload limits.

  • Updated the RPC server initialization to use different limits depending on the server type.

  • Adjusted REPL and utils accordingly.

Copy link
Member

@jochem-brouwer jochem-brouwer left a comment

Choose a reason for hiding this comment

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

Looks good! Could you point all these constants (which are hardcoded strings in some places) to only one point where this constant is actually defined?

(I know for other options we also hardcode the same string at multiple places, we should also fix that at some point)

@@ -42,6 +42,8 @@ const setupClient = async (
jwtSecret: '',
rpcEngineAuth: false,
rpcCors: '',
rpcEthMaxPayload: args.rpcEthMaxPayload ?? '5mb',
rpcEngineMaxPayload: args.rpcEngineMaxPayload ?? '15mb',
Copy link
Member

Choose a reason for hiding this comment

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

I'm fine with these limits, but could you motivate this choice?

Copy link
Member

Choose a reason for hiding this comment

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

Could you also point these to RPC_ENGINE_MAXPAYLOAD_DEFAULT (also for eth)?

Copy link
Author

Choose a reason for hiding this comment

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

I'm fine with these limits, but could you motivate this choice?

For the eth RPC size limit, I based it on the average block sizes observed on Etherscan. The highest daily average recorded was ~0.25 MB, so I multiplied it by 20 in anticipation of more intensive use of block space.

For the engine RPC size limit, according to EIP-4844 the total maximum blob data per block is ~0.75 MB, and I also multiplied it by 20.

This provides a safety margin while still avoiding excessive resource usage. Maybe that's too much, what do you think? 🤔

Copy link
Member

Choose a reason for hiding this comment

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

So the eth RPC engine is intended to be used by "third parties" and it is OK to expose this port to others. For instance providers like Infura/Quicknode also expose those. Also note that this is the limit of incoming messages, so actual requests. Not the reports. So for eth one could request eth_getBlock and this request itself would be very small (just a block hash or number). But the response will be bigger (block itself).

For engine, this is a trusted RPC endpoint and one can only reach it with authentication. This is also the endpoint from which the consensus layer (CL) will send new payloads (new block-like requests). So we can up that limit.

I'm fine with these limits but just wanted to check your motivation, thanks 😄 👍

Copy link
Author

Choose a reason for hiding this comment

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

Thanks for the clarification!
I’ll make sure to better explain my motivations in future PRs 🫡

@@ -356,7 +366,7 @@ export class Config {
public readonly events: EventEmitter<EventParams>

public static readonly CHAIN_DEFAULT = Mainnet
public static readonly SYNCMODE_DEFAULT = SyncMode.Full
public static readonly SYNCMODE_DEFAULT = SyncMode.None
Copy link
Member

Choose a reason for hiding this comment

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

Why is this changed?

Copy link
Author

Choose a reason for hiding this comment

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

Sorry changed it while testing, fixing it now

.option('rpcEngineMaxPayload', {
describe: 'Define max JSON payload size for engine RPC requests',
string: true,
default: '15mb',
Copy link
Member

Choose a reason for hiding this comment

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

Could you point this to RPC_ENGINE_MAXPAYLOAD_DEFAULT? Also for rpcEthMaxPayload 😄 👍

@@ -74,6 +75,7 @@ describe('[Util/RPC]', () => {
const httpServer = createRPCServerListener({
server,
withEngineMiddleware: { jwtSecret: new Uint8Array(32) },
maxPayload: '15mb',
})
const wsServer = createWsRPCServerListener({
server,
Copy link
Member

Choose a reason for hiding this comment

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

Could you add a test here to verify that for both engine/eth the config is handled correctly? You can likely just set it to some low limit and then try to push more data over the RPC than the limit to verify that it fails.

Copy link
Author

Choose a reason for hiding this comment

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

Done ✅

Copy link

codecov bot commented Apr 18, 2025

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 84.10%. Comparing base (3f0cd29) to head (0eba2ce).
Report is 8 commits behind head on master.

Additional details and impacted files

Impacted file tree graph

Flag Coverage Δ
block 83.34% <ø> (ø)
blockchain 89.32% <ø> (ø)
client ?
common 97.51% <ø> (ø)
devp2p 86.71% <ø> (-0.08%) ⬇️
evm 73.09% <ø> (+0.11%) ⬆️
genesis ?
mpt 89.76% <ø> (ø)
statemanager 69.16% <ø> (ø)
static 99.11% <ø> (?)
tx 90.59% <ø> (ø)
util 89.53% <ø> (+7.65%) ⬆️
vm 57.20% <ø> (ø)
wallet ?

Flags with carried forward coverage won't be shown. Click here to find out more.

🚀 New features to boost your workflow:
  • ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
  • 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Make RPC request limit configurable
3 participants