You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
List of differences, that I found, between fork choice/attestation spec and our implementation. This doesn't necessarily mean it's a bug.
1 Attestations are delayed until referenced block arrives, but not delayed until a proper slot starts.
Spec says
# Attestations cannot be from future epochs. If they are, delay consideration until the epoch arrives
And also
# Attestations can only affect the fork choice of subsequent slots.
# Delay consideration in the fork choice until their slot is in the past.
2 Time checks are different
As written above, the spec assumes the epoch should arrive and a consequent slot should start. However, current Harmony implementation uses different checks regarding the time (see TimeFramFilter).
3 Checks are more restrictive in general
That partially seems to be the spec problem, but in general attestation assertions that are verified by Harmony implementation differ from the specification and they are more restrictive (ignoring the time issue above). E.g. a proper attestation according to fork choice spec may be rejected by Harmony. However, it's likely won't be included in the chain, because of process_attestation checks.
Still, according to the fork choice spec it should (or may) affect LMD GHOST decisions.
List of differences, that I found, between fork choice/attestation spec and our implementation. This doesn't necessarily mean it's a bug.
1 Attestations are delayed until referenced block arrives, but not delayed until a proper slot starts.
Spec says
And also
2 Time checks are different
As written above, the spec assumes the epoch should arrive and a consequent slot should start. However, current Harmony implementation uses different checks regarding the time (see TimeFramFilter).
3 Checks are more restrictive in general
That partially seems to be the spec problem, but in general attestation assertions that are verified by Harmony implementation differ from the specification and they are more restrictive (ignoring the time issue above). E.g. a proper attestation according to fork choice spec may be rejected by Harmony. However, it's likely won't be included in the chain, because of process_attestation checks.
Still, according to the fork choice spec it should (or may) affect LMD GHOST decisions.
A similar problem is discussed here ethereum/consensus-specs#1406
The text was updated successfully, but these errors were encountered: