Repository navigation
EL: optional second IPC socket so consensus eth_call is not starved by public RPC #457
Description
Problem
Public HTTP/WS and arc-consensus share one Reth EthApi, so they share one eth_call semaphore (--rpc.max-blocking-io-requests, default 256).
When client eth_call fills that queue, consensus get_signing_validator_set waits, then ETH_DEFAULT_TIMEOUT (1s) kills the CL. A second IPC path on the same EthApi does not help: the semaphore is per API, not per socket.
Proposal
Add --consensus-ipcpath. When set, execution opens a second jsonrpsee IPC on its own EthApi (16 blocking-io permits) and serves eth_* plus reth_subscribePersistedBlock there. Consensus points --eth-socket at that path. The Engine API on --auth-ipc.path is unchanged.
Leave the flag unset and consensus keeps using --ipcpath. Default behavior does not change.
A reference implementation is on the closed pull request #456 (closed by the contribution gate before review). I will resubmit it with Closes: #<this issue> only after assignment.
Request
Please assign this issue to me so I can open that pull request under the contribution policy.
Activity
sergio-mena commentedon Sep 23, 2026
@MitkoTschimev thanks for your contribution. An internal ticket was raised on this: how to make queries coming from
arc-consensusfunctional in the presence of a flood of external queries toarc-execution. We are discussing internally and will post any updates on this issue.