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.
nashqueue
commented
8 months ago
Right now, we have the concept of
SoftFailurewhich 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.