When Besu is behind the CL head (e.g., during initial sync or after restart),
desync-tolerance=0 prevents maru from sending any fork choice updates to Besu.
This causes Besu to remain stuck at its current block.
Increasing desync-tolerance to 100000 allows maru to continue sending blocks
even when Besu is significantly behind, enabling it to catch up.
Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
When payload-validation-enabled is true, maru validates every block against
Besu before sending fork choice updates. If Besu is in an inconsistent state
(e.g., stuck in SNAP sync), this causes maru to stop sending fork choice
updates entirely, preventing Besu from ever syncing.
The official Linea configuration uses payload-validation-enabled = false,
which allows maru to continue sending fork choice updates regardless of
Besu's current state.
Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
Set payload-validation-enabled=true in Maru config to ensure
payloads are sent to the execution client. Without this, Maru
doesn't send forkchoice/newPayload calls when EL reports synced
status (even at block 0).
Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
