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

✨ Disallow new commits during reveal stage (after replication factor is met) #107

Merged
merged 2 commits into from
Dec 20, 2023

Conversation

jamesondh
Copy link
Contributor

Motivation

Once the replication factor is met, new commits should not be allowed to avoid freeloading revealed answers from data request executors.

Explanation of Changes

Created new error and add it to commit_result function, trigger it if replication factor is met

Testing

Updated integration test to check the condition. Without the updated contract code, the test fails.

Related PRs and Issues

Closes #104

@jamesondh jamesondh requested a review from a team November 28, 2023 21:23
@@ -49,6 +49,13 @@ pub mod data_request_results {
if dr.commits.contains_key(&sender.to_string()) {
return Err(AlreadyCommitted);
}

// error if reveal stage has started (replication factor reached)
if u16::try_from(dr.commits.len()).unwrap() >= dr.replication_factor {
Copy link
Collaborator

Choose a reason for hiding this comment

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

This unwrap scares me a bit. Although Ig, in that case, the contract crashes, it doesn't impact the chain.

Copy link
Member

Choose a reason for hiding this comment

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

Does it make sense to replace the unwrap with an if let/match or at least with an except(message)?

Copy link
Collaborator

Choose a reason for hiding this comment

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

We could write our own message. Or I think we use anyhow to have every function return an anyhow::Result and use the ? operator. Anyhow, IMO, is acceptable in non-user-facing applications or in instances where the user is technically sufficient.

@jamesondh jamesondh force-pushed the feat/disallow-commits-after-reveal branch from 6d05782 to 4b242cd Compare December 20, 2023 20:32
@jamesondh jamesondh merged commit 402e176 into testnet-2 Dec 20, 2023
4 checks passed
@gluax gluax deleted the feat/disallow-commits-after-reveal branch May 2, 2024 16:02
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.

4 participants