-
Notifications
You must be signed in to change notification settings - Fork 7
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Refactor validation logic for a more pluggable functionality #561
Milestone
Comments
masih
added this to the Milestone 2: Harderning and Mainnet Deployment Readiness milestone
Aug 10, 2024
Also see: #560 (comment) |
Stebalien
removed this from the Milestone 2: Harderning and Mainnet Deployment Readiness milestone
Aug 30, 2024
Stebalien
added this to the Milestone 2: Harderning and Mainnet Deployment Readiness milestone
Sep 3, 2024
masih
added a commit
that referenced
this issue
Sep 22, 2024
Refactor the `Chain` interface into two separate smaller interfaces for a more pluggable committee caching. Refactor committee cache out of participant. This work is part of a larger refactor of validation mechanism and is separated into its own commit for easier review. Part of #561
masih
added a commit
that referenced
this issue
Sep 22, 2024
Refactor the `Chain` interface into two separate smaller interfaces for a more pluggable committee caching. Refactor committee cache out of participant. This work is part of a larger refactor of validation mechanism and is separated into its own commit for easier review. Part of #561
masih
added a commit
that referenced
this issue
Sep 22, 2024
Refactor the `Chain` interface into two separate smaller interfaces for a more pluggable committee caching. Refactor committee cache out of participant. This work is part of a larger refactor of validation mechanism and is separated into its own commit for easier review. Part of #561
masih
added a commit
that referenced
this issue
Sep 22, 2024
Refactor the `Chain` interface into two separate smaller interfaces for a more pluggable committee caching. Refactor committee cache out of participant. This work is part of a larger refactor of validation mechanism and is separated into its own commit for easier review. Part of #561
masih
added a commit
that referenced
this issue
Sep 22, 2024
Refactor the `Chain` interface into two separate smaller interfaces for a more pluggable committee caching. Refactor committee cache out of participant. This work is part of a larger refactor of validation mechanism and is separated into its own commit for easier review. Part of #561
masih
added a commit
that referenced
this issue
Sep 23, 2024
Refactor the `Chain` interface into two separate smaller interfaces for a more pluggable committee caching. Refactor committee cache out of participant. This work is part of a larger refactor of validation mechanism and is separated into its own commit for easier review. Part of #561
github-merge-queue bot
pushed a commit
that referenced
this issue
Sep 23, 2024
Refactor the `Chain` interface into two separate smaller interfaces for a more pluggable committee caching. Refactor committee cache out of participant. This work is part of a larger refactor of validation mechanism and is separated into its own commit for easier review. Part of #561
masih
added a commit
that referenced
this issue
Sep 23, 2024
Refactor the validation logic out of `Participant` and into its own dedicated struct that is mutex-free and listens to the progress made by the participant to infer the correct validation path. The change above significantly reduces the need for mutex control over current instance, which makes it easier to plug in extra conditional behaviour, e.g. #583. Fixes #561
masih
added a commit
that referenced
this issue
Sep 23, 2024
Refactor the validation logic out of `Participant` and into its own dedicated struct that is mutex-free and listens to the progress made by the participant to infer the correct validation path. The change above significantly reduces the need for mutex control over current instance, which makes it easier to plug in extra conditional behaviour, e.g. #583. Fixes #561
masih
added a commit
that referenced
this issue
Sep 23, 2024
Refactor the validation logic out of `Participant` and into its own dedicated struct that is mutex-free and listens to the progress made by the participant to infer the correct validation path. The change above significantly reduces the need for mutex control over current instance, which makes it easier to plug in extra conditional behaviour, e.g. #583. Fixes #561
masih
added a commit
that referenced
this issue
Sep 23, 2024
Refactor the validation logic out of `Participant` and into its own dedicated struct that is mutex-free and listens to the progress made by the participant to infer the correct validation path. The change above significantly reduces the need for mutex control over current instance, which makes it easier to plug in extra conditional behaviour, e.g. #583. Fixes #561
masih
added a commit
that referenced
this issue
Sep 23, 2024
Refactor the validation logic out of `Participant` and into its own dedicated struct that is mutex-free and listens to the progress made by the participant to infer the correct validation path. The change above significantly reduces the need for mutex control over current instance, which makes it easier to plug in extra conditional behaviour, e.g. #583. Fixes #561
masih
added a commit
that referenced
this issue
Sep 23, 2024
Refactor the validation logic out of `Participant` and into its own dedicated struct that is mutex-free and listens to the progress made by the participant to infer the correct validation path. The change above significantly reduces the need for mutex control over current instance, which makes it easier to plug in extra conditional behaviour, e.g. #583. Fixes #561
masih
added a commit
that referenced
this issue
Sep 23, 2024
Refactor the validation logic out of `Participant` and into its own dedicated struct that is mutex-free and listens to the progress made by the participant to infer the correct validation path. The change above significantly reduces the need for mutex control over current instance, which makes it easier to plug in extra conditional behaviour, e.g. #583. Fixes #561
masih
added a commit
that referenced
this issue
Sep 23, 2024
Refactor the validation logic out of `Participant` and into its own dedicated struct that is mutex-free and listens to the progress made by the participant to infer the correct validation path. The change above significantly reduces the need for mutex control over current instance, which makes it easier to plug in extra conditional behaviour, e.g. #583. Fixes #561
masih
added a commit
that referenced
this issue
Sep 23, 2024
Refactor the validation logic out of `Participant` and into its own dedicated struct that is mutex-free and listens to the progress made by the participant to infer the correct validation path. The change above significantly reduces the need for mutex control over current instance, which makes it easier to plug in extra conditional behaviour, e.g. #583. Fixes #561
github-merge-queue bot
pushed a commit
that referenced
this issue
Sep 23, 2024
Refactor the validation logic out of `Participant` and into its own dedicated struct that is mutex-free and listens to the progress made by the participant to infer the correct validation path. The change above significantly reduces the need for mutex control over current instance, which makes it easier to plug in extra conditional behaviour, e.g. #583. Fixes #561
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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:
Participant
Participant
oblivious of caching in validator in favour of a swappable validation cache mechanism.The text was updated successfully, but these errors were encountered: