Full-node blocks execution stalls for 6–7 s while sequencer keeps producing blocks

[auricom]

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

[auricom]

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.