-
Notifications
You must be signed in to change notification settings - Fork 41
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
Aggregator single signatures buffer #1934
Conversation
Test Results 4 files ± 0 54 suites +1 9m 39s ⏱️ -56s Results for commit 5b578c7. ± Comparison against base commit 62dbe88. This pull request removes 16 and adds 45 tests. Note that renamed tests count towards both.
♻️ This comment has been updated with latest results. |
43f9ace
to
d7e9138
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM
...-aggregator/src/database/query/buffered_single_signature/delete_buffered_single_signature.rs
Outdated
Show resolved
Hide resolved
@@ -146,12 +147,45 @@ mod tests { | |||
.unwrap(); | |||
} | |||
|
|||
#[tokio::test] | |||
async fn test_register_signatures_post_ok_202() { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I wonder if it's a good thing to speak about code 202 in test name when we don't see it in the test even if It seems normal that it is like this
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes, it's implicit since in the code and test we use enum variant with the explicit name of the http code.
Until now this is how we have named those tests has it has the benefit of clarity as long as you have some knowledge of the http code numbers. A requirement that can be though as reasonable since this whole part is an http api.
mithril-aggregator/src/services/certifier/buffered_certifier.rs
Outdated
Show resolved
Hide resolved
mithril-aggregator/src/services/certifier/buffered_certifier.rs
Outdated
Show resolved
Hide resolved
mithril-aggregator/tests/create_certificate_with_buffered_signatures.rs
Outdated
Show resolved
Hide resolved
// Todo: Refactor this code to avoid code duplication by making the signable_builder_service | ||
// able to retrieve the next avk by itself. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We should open an issue to plan that refactor
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Overall looks good 👍
I'm a bit worried that signature entities without message will not be buffered.
I also left few comments and questions.
mithril-aggregator/src/database/repository/buffered_single_signature_repository.rs
Show resolved
Hide resolved
mithril-aggregator/src/services/certifier/buffered_certifier.rs
Outdated
Show resolved
Hide resolved
mithril-aggregator/src/services/certifier/buffered_certifier.rs
Outdated
Show resolved
Hide resolved
mithril-aggregator/src/services/certifier/buffered_certifier.rs
Outdated
Show resolved
Hide resolved
mithril-aggregator/tests/create_certificate_with_buffered_signatures.rs
Outdated
Show resolved
Hide resolved
mithril-aggregator/tests/test_extensions/aggregator_observer.rs
Outdated
Show resolved
Hide resolved
335512b
to
b308cc1
Compare
By computing the Signed Entity Type and the protocol message without having to get the current open message. Required to be able to buffer incoming single signatures as an open message is not yet opened.
Since a certifier decorator will be added, this will avoid stacking too much files or too much the certifier file.
- `interface`: contains the trait & error definition - `certifier_service`: the implementation
Straigth to the point for now.
…ssage For the message type, the buffered signatures will be removed from the buffer.
If check using the current one fails, as a signer may detect epoch change before the aggregator and issue single signatures.
This allow caller to know if the signature was registered for immediate use or buffered.
In order to remove the InMemory store. Doing so required to be more precise with the tests signatures used. IE most"register_signature" tests needs a single signature that have a signed message but when reading them from the store the store doesn't keep the signed message leading to problems with some assert_eq.
As it has no more use.
It will be used to know if a single signature can be buffered or not.
Instead of validating their `signed_message` as this will be handled by another component beforehand.
As it has now no more use.
For retrocompatibility with previously stored signatures (with open messages in aggregator).
…ed_message is unauthenticated As there's no value to send it to the certifier since it will reject it anyway.
As we won't be able to always set this value (ie: with the upcoming p2p registration). In order to do so an refactor have to be done in `mithril-signer` so the `RegisterSignatureMessage::signed_message` property can be set.
And the trait method from `message_string` to `to_message`.
* Simpify some code docs. * Enhance `delete_buffered_single_signature` tests * Make some naming more clear
b308cc1
to
ad4d1db
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM 👍
I left minor comments below.
.../src/database/query/buffered_single_signature/insert_or_replace_buffered_single_signature.rs
Outdated
Show resolved
Hide resolved
* Mithril-aggregator from `0.5.63` to `0.5.64` * Mithril-signer from `0.2.183` to `0.2.184` * Mithril-common from `0.4.51` to `0.4.52` * OpenApi from `0.1.29` to `0.1.30`
Content
This PR introduce a buffer mechanism in aggregator to make it able to store signatures that come from signers that are ahead of it, making easier to have signers that handle their signing rhythm themself are they won't need to rely on the aggregator certificate pending to issue single signatures.
When a aggregator receive a single signature it will now:
a. Check the signature against its embedded signed message and the current stake distribution.
b. If check fail check it using next epoch stake distribution (as the signer can already be at the next epoch when crossing epoch boundary).
c. If any of the two previous succeed store the signature in a store, a new table in our main sqlite file, alongside it's associated signed entity discriminant.
When a aggregator create a new open message it will now:
Pre-submit checklist
Comments
Issue(s)
Closes #1900