Skip to content

Conversation

@ibaryshnikov
Copy link

@ibaryshnikov ibaryshnikov commented Aug 24, 2021

Ready for review now

In this PR I relied on LockedLocators structure a lot, which gives enough information to figure out all the required paths:

pub struct LockedLocators {
    previous_contribution: ContributionLocator,
    current_contribution: ContributionLocator,
    next_contribution: ContributionLocator,
    next_contribution_file_signature: ContributionSignatureLocator,
}

The verifier logic has been simplified a lot. The verifier will download tasks one by one, sequentially. And verifiers will be able to join mid round. This allowed to remove verifier drop logic, and simplify many places where previously we had to handle both verifier and contributor. Now many functions expect either only contributor, or only verifier. The new verifier implementation also does the verification faster.

As a side effect, fixed one StorageLocatorMissing error, when a function was trying to remove a missing file.

@ibaryshnikov ibaryshnikov changed the title [WIP] Updated verifier logic Updated verifier logic Aug 30, 2021
Copy link

@jules jules left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

So far, LGTM. I have tested it locally as well and it all worked out fine - it'll be good to test this on the standby server before merging though.

Copy link

@kellpossible kellpossible left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

looks good to me!

finished_at: None,
contributor_ids,
verifier_ids,
verifier_ids: vec![],

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

does verifier_ids need to be removed entirely from Round?

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This field is still in use when the new round is created

return Err(CoordinatorError::ExpectedVerifier);
}
// Initialize the next challenge file.
storage.initialize(

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think this could benefit from InitializeAction https://github.com/AleoHQ/aleo-setup/blob/01ee29f3ec74ee8a1068633f649f0fbb88149101/phase1-coordinator/src/objects/round.rs#L721 in #367, to avoid mutating storage in this module, we could keep an eye on which one gets merged first and implement it

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is a bit controversial. In #367 do you want to replace a direct call which does the change with an inderect call, which performs the changes somewhat later? I want to see an explicit call here.

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It makes this closer to a pure function, which makes it more predictable and easier to test

phase1-cli = { path = "../phase1-cli", features = ["parallel"] }
phase1-coordinator = { path = "../phase1-coordinator", features = ["operator", "parallel"]}
setup1-shared = { version = "0.1", path = "../setup1-shared" }
setup1-shared = { version = "0.1", path = "../setup1-shared", features = ["twitter"] }

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

is this extra twitter feature flag part of this PR?

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

yes, to reduce the number of dependencies verifier pulls in


Ok(buffer)
}
// ///

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

to be removed?

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

not sure, I intentionally left it here

// Initialize the shutdown listener
let verifier = self.clone();
tokio::task::spawn(async move {
let _ = verifier.shutdown_listener().await;

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

how does the verifier go with shutting down now?

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

That's a great question! As you can see, I've removed the tasks queue from the verifier. It reuses only 3 files now, and clears them when needed. If the verifier is killed there are a few options:

  • it has got a task assigned, but didn't download the files to verify. In this case the assigned task will be cleared from the cache in a minute, and another verifier will pick it up
  • if the verifier goes down after downloading the files, the result will be the same as in a previous case
  • if the verifier is killed in the middle of uploading the files, the coordinator will produce an error and reassign the work if the verifier doesn't show up in time
  • if the verifier is killed after uploading the verification, nothing happens. The coordinator will write the files to disk and call try_verify function

@ibaryshnikov
Copy link
Author

Thanks for the comments, let's have some more tests before merging this.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

6 participants