celestiaorg
Full-node blocks execution stalls for 6–7 s while sequencer keeps producing blocks
Version Information
ev-node: v1.0.0-beta.7
System Information
- Network: collect-testnet
- Full-node: ev-reth with DA-sync + p2p-sync enabled
- Sequencer: steady 500ms block-time
- Explorer: blockscout (indexing via full-node RPC)
Network Configuration
No response
Development Environment
No response
Configuration Details
No response
Steps to Reproduce
- Start ev-reth + ev-node full-node with da + p2p sync
- Observe logs: blocks processed in 6–7 s bursts.
- Send any tx via
cast send --rpc-url <full-node>… and measure time until tx-hash is returned.
Expected Result
Full-node should keep up with the sequencer (≤1 s behind) and return a tx-hash within ~1 s.
Actual Result
Full-node falls 1–7 seconds behind and returns tx-hash only after the next “batch” is executed.
- the full-node execute new created blocks only every 6–7 s, although the sequencer keeps producing them every second.
- Sending a tx to the full-node RPC:
- tx submitted at 15:05:40
- tx-hash returned at 15:05:47 (7 s later)
- block-timestamp of the tx is 15:05:41 (inclusion itself is fast)
- blockscout shows the same 6–7 s burst pattern for displaying new created blocks
Observations
- DA and p2p traffic both wake up simultaneously after the stall, so basic connectivity looks fine.
Impacts
- ~7× increase in perceived tx latency for anyone using the full-node RPC instead of the sequencer RPC
- Full-nodes cannot be used for wallets/dApps that need fast feedback.
Relevant Logs
Additional Information
Today the readiness endpoint only checks “blocks behind best-head ≤ X”.
However the result of this metric is tightly coupled to the internal sync-loop implementation;
The goal we should aim for would be that the readiness endpoint can automatically detect an deployment issue from the node operator side, instead of right now, detecting implementation issue from ev-node.
We should think about integrating readiness signal influence inside the sync loop so that it the readiness endpoint will be correctly thought off during the long term process development cycle of sync process.
