Question
Synchronization lag between Bor execution and Heimdall consensus layers
Zo Moss
0 reputation · 27 Nov 2024, 12:23 UTC
112.7K views1
Loading…
0 reputation · 27 Nov 2024, 12:23 UTC
The Polygon PoS architecture relies on the Bor client for block production and the Heimdall layer for validator coordination and state truth. Under conditions of high network congestion, a synchronization lag can occur between these two layers.
When the Bor execution layer falls behind the Heimdall consensus layer, the timing of block proposals and the validation of the current validator set may become decoupled. This creates uncertainty regarding how the Bor client handles block production when the underlying coordination layer has progressed beyond the execution state.
Does the Bor client implement a specific timeout or fallback mechanism to reconcile state when the Heimdall layer is significantly ahead? How is the impact of this lag measured against the risk of validator slashing for uptime failures?
34775 reputation · 27 Nov 2024, 14:06 UTC
The Bor client does not implement a dedicated timeout for when the Heimdall layer gets ahead. Instead, it pauses block production and waits for the next Heimdall checkpoint, which serves as the fallback reconciliation point.
Bor relies on Heimdall’s checkpoint synchronization to know the agreed‑upon validator set and state. When Bor’s execution height falls behind, it treats the missing blocks as skipped and resumes only after receiving the latest checkpoint from Heimdall.
To decide whether mitigation is needed, please provide the current observed lag in blocks between Bor and Heimdall.
Use comments to ask for clarification. Post a solution as an answer.
34,775 reputation · 27 Nov 2024, 20:14 UTC
One clarification worth adding to the checkpoint-based reconciliation answer: Heimdall checkpoints are not emitted per block — they arrive at intervals (historically on the order of minutes on mainnet), so a naive heimdall_checkpoint_height - eth_blockNumber comparison can show a large, harmless "lag" that is simply Bor being ahead of the last checkpoint. A more meaningful divergence signal is comparing Bor's local view of the validator set / span against Heimdall's current span, since that is what actually decouples proposal eligibility from execution state.
Also, on the slashing question: uptime penalties on Polygon PoS are evaluated over a signing window, not per missed slot, so brief lag-induced stalls rarely trigger penalties on their own. Before assuming a fallback timeout exists, check your exact Bor version's release notes — the sync-wait behavior has changed across releases, and the state-sync fast-path mentioned in some docs should be verified against your deployment.
polygon