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
implement new assignment algorithm and lazy issuance #68
Conversation
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.
this is a first stage review. Please fix the mentioned comments before I continue to review
overall, the code looks clean. nice work
I'll test and merge this AFTER we release 0.7.0. Can you please bump the crate versions to 0.8.0 in this PR? |
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.
Since you showed interest in the code(-quality) review, I reviewed your code with some remarks. The code is readable and is consistent in its type of writing. (nearly) all variables have meaningful and descriptive names.
ceremonies/src/lib.rs
Outdated
&Self::attestation_index((cid, cindex), &other_participant), | ||
); | ||
if attestees_from_other.contains(&p) { | ||
was_attested_count += 1; | ||
} |
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.
nested loops have high potential of confusion.. the operation you're doing here is a good use case for the iter() api..
pseudo-code:
let was_attested_count = meetup_participants.iter()
.filter(o -> p!=o)
.map(o -> Self::attestation_index(...))
.map(o -> Self::attestation_registry(...))
.filter(o -> attestees_from_other(p))
.count();
fa8aee7
to
12c817c
Compare
e748d72
to
635acd7
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.
subject to approval by @clangenb
ceremonies/src/lib.rs
Outdated
@@ -523,28 +523,11 @@ impl<T: Config> Module<T> { | |||
} | |||
|
|||
fn find_coprime_below(upper_bound: u64) -> u64 { |
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.
@NicJak i just stumbled upon this. if you always take n-1
the algorithm becomes predictable. s1 is supposed to be random and coprime, that's the whole point of the algorithm. but it is my bad, i was not explicit about that when i explained it to you, sorry!
This reverts commit 47282e2.
c9abcc0
to
cbddd13
Compare
cbddd13
to
33f3879
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.
Finally, I managed to look at the code. :) It looks very good, but I also have some comments. I reckon this is the essence of my comments.
- I tested that it does indeed not compile with the no due to no_std issues
- Some math stuff I want to see in a dedicated module in
primitives/core
- Some rust technicalities
General impression:
- it is very technical code, more docs would be really helpful
- I have not double-checked yet, but I think some functions are not unit-tested, and as it's quite complex sometimes. Therefore, I created [ceremonies] double check if we test well enough #89. Additions are welcome, but I don't think we need to do that in this PR. I would like to merge this soon.
primitives/src/ceremonies.rs
Outdated
pub m: u64, | ||
pub s1: u64, | ||
pub s2: u64, |
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.
Can you add some doc here? I don't understand what these fields mean.
|
||
let meetups: Vec<Vec<AccountId>> = get_meetups(cid); | ||
assert_eq!(meetups.len(), 2); | ||
// whitepaper III-B Rule 3: no more than 1/3 participants without reputation |
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.
dito
#[rstest(n_bootstrappers, n_reputables, n_endorsees, n_newbies, n_locations, exp_meetups, | ||
case(8,0,0,4,3, vec![12]), | ||
case(9,0,0,4,3, vec![7,6]), | ||
case(3,7,3,3,3, vec![8,8]), | ||
case(3,7,4,3,3, vec![9,8]), | ||
case::do_not_assign_more_meetups_than_locations(3,7,50,0,3, vec![12,12,12]), | ||
case::do_not_assign_more_meetups_than_there_are_experienced_participants(3,1,49,0,10, vec![12,12,12,12]), | ||
case(12,48,12*AMOUNT_NEWBIE_TICKETS as usize,0,55, [12; 55].to_vec()), | ||
)] | ||
fn assigning_meetup_works( | ||
n_bootstrappers: usize, | ||
n_reputables: usize, | ||
n_endorsees: usize, | ||
n_newbies: usize, | ||
n_locations: u32, | ||
exp_meetups: Vec<usize>, | ||
) { |
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.
Do we not test that anymore?
// TODO: whitepaper III-B Rule 1: minimize the number of participants that have met at previous ceremony | ||
// TODO: whitepaper III-B Rule 2: maximize number of participants per meetup within 3<=N<=12 |
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.
Track this in #88
67de92b
to
4e93b0d
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.
I did some cleanup:
- fixed no_std,
- fixed meetup assignment randomization
- some rust best practices
Follow-ups:
Tested that it compiles successfully with the node.
No description provided.