Skip to content
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

Closed
masih opened this issue Aug 10, 2024 · 1 comment · Fixed by #657
Closed

Refactor validation logic for a more pluggable functionality #561

masih opened this issue Aug 10, 2024 · 1 comment · Fixed by #657
Assignees

Comments

@masih
Copy link
Member

masih commented Aug 10, 2024

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
Copy link
Member Author

masih commented Aug 12, 2024

Also see: #560 (comment)

@Stebalien Stebalien self-assigned this Sep 3, 2024
@masih masih assigned masih and unassigned Stebalien Sep 21, 2024
@masih masih moved this from Todo to In progress in F3 Sep 21, 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
@github-project-automation github-project-automation bot moved this from In progress to Done in F3 Sep 23, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
Status: Done
Development

Successfully merging a pull request may close this issue.

2 participants