Description

This sub-issue is part of the epic issue.

Motivation: Prevent insecure interactions on L2 when the chain component is not up to date.

Currently, after a restart, the hydra-node allows users to interact on L2 even while the chain component is still catching up.

This may result in unsafe L2 transactions that cannot be enforced on L1, for example continuing to interact on L2 after the head has already closed on L1.

To prevent this, the L2 interaction (node component) should not start until the node state is synchronized: that is, when its current slot is confirmed to fall within the contestation period window relative to both the latest tip and/or chain time observed from the chain component and the current wall-clock time.

Suggested solution

Ensure the chain component has reached the latest tip and the node-state ’s current slot is within the contestation period window before enabling any L2 interaction:

• Toggle on/off the Network and API Server components depending on whether the chain component is fully synchronized.

• While unsynchronized, incoming Network and API input requests will be rejected to prevent invalid or stale processing.

• Due to our dependency on etcd for networking, the node must disconnect while unsynchronized to avoid marking incoming messages as delivered.

Note: while the node is connected to etcd, network inputs start being enqueued and marked as delivered. If these inputs are not re-enqueued and processed after resynchronization, any in-flight snapshots may remain unresolved, causing the head to get stuck. See issue #1999 for more details.

Alternative

The node’s head logic must reject both client and network inputs if the node state’s current slot does not fall within the contestation period window relative to the latest tip and/or chain time observed by the chain backend and the current wall-clock time.

• Resume API client inputs only after the chain component has fully synchronized. Until then, reject incoming requests so users can retry later.

• Resume Network client inputs only after the chain component has fully synchronized. While unsynchronized, re-enqueue incoming inputs as they arrive.

Additional context

• If the node detects that the chain component is out of sync with the node state (not within the contestation window), it should:

  • Throw an exception and stop, forcing users to restart rather than risk insecure interactions.

  • Reject client and network inputs, notifying clients via WebSocket that the chain is currently catching up.