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
Right now, we have the concept of SoftFailure which is used primarily when a header cannot be verified fully against a non-adjacent header (meaning the header could still be valid when applied during adjacent verification). All other failures are treated equally as hard failures. The problem with this is that this verification logic is used by different components (syncer, exchange). What is considered a hard failure for the syncer (incomingNetHead) is different from the exchange (when requesting Head). Therefore, we need an ability to distinguish in VerifyError whether the error was intentionally malicious or not so that the caller knows whether to ignore / drop the header or to punish the peer.
The text was updated successfully, but these errors were encountered:
Right now, we have the concept of
SoftFailure
which is used primarily when a header cannot be verified fully against a non-adjacent header (meaning the header could still be valid when applied during adjacent verification). All other failures are treated equally as hard failures. The problem with this is that this verification logic is used by different components (syncer, exchange). What is considered a hard failure for the syncer (incomingNetHead) is different from the exchange (when requesting Head). Therefore, we need an ability to distinguish in VerifyError whether the error was intentionally malicious or not so that the caller knows whether to ignore / drop the header or to punish the peer.The text was updated successfully, but these errors were encountered: