The current validation logic is encapsulated at a package-level function that takes a number of arguments to validate a given message. This is useful for users whom are just interested in validating a given gpbft message but does require Host to be passed in. Host is a heavy struct; but in validation it is only used to marshal payload.
Separately, it is desirable to cache the computationally expensive parts of validation specially if the rate of duplicates in the live network is high. The two computationally expensive parts are: message signature validation and justification aggregated signature validation. The work in #557 and #560 introduces caching for validation purposes. But the API can be refined further to make future extensions easier while making modifications less error-prone since message validation is highly critical.
Consider:
separating validator into its own struct that is then plugged into Participant
ideally making Participant oblivious of caching in validator in favour of a swappable validation cache mechanism.
masih
commented
2 months ago
The current validation logic is encapsulated at a package-level function that takes a number of arguments to validate a given message. This is useful for users whom are just interested in validating a given gpbft message but does require
Hostto be passed in.Hostis a heavy struct; but in validation it is only used to marshal payload.Separately, it is desirable to cache the computationally expensive parts of validation specially if the rate of duplicates in the live network is high. The two computationally expensive parts are: message signature validation and justification aggregated signature validation. The work in #557 and #560 introduces caching for validation purposes. But the API can be refined further to make future extensions easier while making modifications less error-prone since message validation is highly critical.
Consider:
ParticipantParticipantoblivious of caching in validator in favour of a swappable validation cache mechanism.