Practical Notes from Building ethbacknode
This article is a short technical note based on a real implementation. We are not proposing a “better node” or a framework — just documenting an approach we built after repeatedly hitting the same problems with Ethereum JSON-RPC in backend systems.
Repository: https://github.com/ITProLabDev/ethbacknode
Context
Ethereum nodes are good at:
- block execution
- state validation
- exposing JSON-RPC
They are not designed to be used directly as backend components for:
- payment systems
- custodial flows
- service-to-service integrations
Using a raw node as a backend dependency quickly creates operational gaps.
Problems We Hit in Practice
1. Key Management JSON-RPC assumes the caller…
Practical Notes from Building ethbacknode
This article is a short technical note based on a real implementation. We are not proposing a “better node” or a framework — just documenting an approach we built after repeatedly hitting the same problems with Ethereum JSON-RPC in backend systems.
Repository: https://github.com/ITProLabDev/ethbacknode
Context
Ethereum nodes are good at:
- block execution
- state validation
- exposing JSON-RPC
They are not designed to be used directly as backend components for:
- payment systems
- custodial flows
- service-to-service integrations
Using a raw node as a backend dependency quickly creates operational gaps.
Problems We Hit in Practice
1. Key Management JSON-RPC assumes the caller manages keys correctly.
- In real systems we needed:
- isolated keys per service
- controlled signing
- minimal exposure of private keys
This logic always ended up living outside the node.
2. Transaction Lifecycle From a backend perspective, eth_sendRawTransaction is only the beginning.
We had to track:
- submission
- pending state
- inclusion
- confirmation depth
- replacement / drop cases
RPC does not provide lifecycle guarantees - only snapshots.
3. Monitoring and State Polling RPC endpoints does not give:
- deterministic transaction state
- internal consistency
- idempotent retries
Backend systems require their own source of truth, not just chain data.
What ethbacknode Actually Is
ethbacknode is a stateful backend layer placed between:
- application code
- Ethereum JSON-RPC node
It does not replace a node. It wraps it with backend-oriented logic.
Key Architectural Choices
Language: Go Chosen for:
- predictable concurrency
- long-running service behavior
- simple deployment
Embedded Storage
We intentionally use embedded storage instead of external DBs:
- fewer dependencies
- simpler ops
- easier reproducibility
Trade-off: limited horizontal scalability (accepted).
IPC over HTTP (When Possible)
IPC is preferred for:
- lower latency
- fewer failure modes
- reduced attack surface
HTTP remains available where IPC is not feasible.
What This Design Enables
- explicit transaction states
- controlled signing flow
- backend-friendly APIs
- clearer failure handling
Where It Is Not a Fit
- high-frequency trading
- horizontally scaled stateless services
- generic Web3 SDK usage
- smart contract orchestration frameworks
These were conscious exclusions.
Open Questions
We are interested in technical critique, especially around:
- edge cases in tx lifecycle handling
- reorg scenarios
- alternative designs for state management
- failure modes we might be missing
This is an open-source project, and feedback from engineers who’ve built Ethereum-backed systems is highly appreciated.