Context
Original issue #689
Spec PR #708
What is wrong
When SYNC_LAG_THRESHOLD consecutive validators do not propose a block maliciously, it tricks the network into thinking that it is sync lagged. The next NETWORK_STALL_THRESHOLD - SYNC_LAG_THRESHOLD honest validators do not author the blocks even when they can until the NETWORK_STALL_THRESHOLD is crossed.
This issue can be reproduced with ethlambda when 5 consecutive validators maliciously skip authoring blocks.
Found this issue while working on sync lag in Ream ReamLabs/ream#1385 (comment).
Proposed fix
If the validator is proposer for current slot, they should propose block regardless of sync lagged or not. Only skip attestations when sync lagged. Proposing from a stale view does not cause a lot of pollution (as compared to attestations) because it is very rare that a validator becomes a proposer.
|
if self._is_synced_for_duties(slot, "block"): |
|
await self._maybe_produce_block(slot) |
Context
Original issue #689
Spec PR #708
What is wrong
When
SYNC_LAG_THRESHOLDconsecutive validators do not propose a block maliciously, it tricks the network into thinking that it is sync lagged. The nextNETWORK_STALL_THRESHOLD - SYNC_LAG_THRESHOLDhonest validators do not author the blocks even when they can until theNETWORK_STALL_THRESHOLDis crossed.This issue can be reproduced with ethlambda when 5 consecutive validators maliciously skip authoring blocks.
Found this issue while working on sync lag in Ream ReamLabs/ream#1385 (comment).
Proposed fix
If the validator is proposer for current slot, they should propose block regardless of sync lagged or not. Only skip attestations when sync lagged. Proposing from a stale view does not cause a lot of pollution (as compared to attestations) because it is very rare that a validator becomes a proposer.
leanSpec/src/lean_spec/node/validator/service.py
Lines 125 to 126 in eca701e