Allow second sync committee message to propagate if first one stale#4015
Allow second sync committee message to propagate if first one stale#4015etan-status wants to merge 17 commits intoethereum:masterfrom
Conversation
The sync committee message signature does not sign over the slot, making it possible for stale messages to be adjusted and replayed, possibly preventing new sync committee messages to propagate. If such a message for an older head is received, allow a second message to propagate that refers to the current head as selected by fork choice, overriding the previous one. Also add a couple sanity checks, as in, disallowing messages referring to unknown or invalid blocks to spread, in line with existing rules for blob sidecars, parent block roots and attestations.
|
Implemented in Nimbus: status-im/nimbus-eth2#4953 |
mkalinin
left a comment
There was a problem hiding this comment.
Looks good to me! But I’d like to see approves from other CL devs before merging
|
If we are changing this, why in altair spec and not in fulu spec? Is this change in a EIP? Seems no more work has happened since December on this, what is the consensus about the likehood of this being approved? |
|
The way how the consensus-specs work is that later forks inherit the logic from earlier forks. This documentation change is documenting currently implemented behaviour.
It has 2 approvals |
The base branch was changed.
|
Hey @etan-status for this to be merged, we need a few approvals from client teams. |
wemeetagain
left a comment
There was a problem hiding this comment.
This is a good addition and makes sense.
We don't currently implement these rules, but we will likely add them.
The sync committee message signature does not sign over the slot, making it possible for stale messages to be adjusted and replayed, possibly preventing new sync committee messages to propagate. If such a message for an older head is received, allow a second message to propagate that refers to the current head as selected by fork choice, overriding the previous one.
Also add a couple sanity checks, as in, disallowing messages referring to unknown or invalid blocks to spread, in line with existing rules for blob sidecars, parent block roots and attestations.