Discussion topic for EIP-7966: eth_sendRawTransactionSync Method.
Summary
The traditionally asynchronous transaction submission and confirmation is no longer suitable for blockchains optimized for latency. While Ethereum’s 12s blocktime made async patterns necessary to avoid freezing applications, modern chains with millisecond blocktimes make this approach inefficient. The current two-RPC paradigm (send transaction + poll for receipt) introduces unnecessary network round-trips and complexity when transactions can be processed almost instantly.
The EIP proposes introducing a new synchronous RPC method eth_sendRawTransactionSync that combines eth_sendRawTransaction and eth_getTransactionReceipt into a single yet efficient RPC. It aims to address latency bottlenecks in transaction submission workflows, particularly for blockchains optimized for low latency.
For more detail, please refer to the EIP.
Update Logs
- Initial Draft #9890
FAQs
Q: Why introduce a synchronous method when async patterns are generally preferred?
A: While Ethereum’s 12s blocktime required async patterns to avoid blocking, modern low-latency chains with millisecond blocktimes make synchronous calls practical and beneficial for UX.
Q: What happens if a transaction takes longer than the timeout period?
A: The handler MUST return an error with the transaction hash, allowing fallback to traditional polling. Timeout SHOULD be configurable by node operators.
Q: Is this compatible with existing Ethereum infrastructure?
A: Yes, this is additive. Existing async methods remain unchanged.
Q: How does this affect node resource usage?
A: It reduces overall RPC calls by eliminating repeated eth_getTransactionReceipt polling, but requires managing longer-lived HTTP connections (upto a timeout).
Q: What chains would benefit most from this?
A: Latency-optimized chains like RISE, MegaETH, Base, and chains with 100s (or less) of ms blocktimes.
Q: What about backward-compatibility?
A: Fully backward compatible. Existing applications continue working unchanged. Developers opt-in when beneficial.
Others
- Previous discussion on Ethresearch
- A prototype is being developed in reth: