Nonce as Non-Replayable Submission Token #209
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
hayesgm
force-pushed
the
hayesgm/nonce-as-non-replayable-token
branch
from
2a9db50 to
67a2f63
Compare
fluffywaffles
approved these changes
Sep 11, 2024
|
|
||
| assertEq(counter.number(), 1); | ||
|
|
||
| // Not sure why this revert isn't showing up-- it's reverting, nonetheless. |
There was a problem hiding this comment.
I know this is crazy but is it because you didn't do new bytes[](0) (inline in the call to execute on 264) above the expectRevert?
I mean... the constructor execution succeeds, so I wonder if the expect revert accidentally targets this nested call.
There was a problem hiding this comment.
Nah, doesn't make it work. Though that change is probably for the better for clarity, so I moved that construction to a var above anyway, thanks.
Merged
hayesgm
force-pushed
the
hayesgm/nonce-as-non-replayable-token
branch
2 times, most recently
from
dacc7de to
c28c310
Compare
kevincheng96
approved these changes
Sep 11, 2024
hayesgm
force-pushed
the
hayesgm/nonce-as-non-replayable-token
branch
from
c28c310 to
6037dc0
Compare
Previously in `QuarkNonceManager`, we used `submissionToken=EXHAUSTED` for non-replayable submissions and `submissionToken=nonce` for the first play of replayable submissions. Overall, this behavior was inconsistent (though otherwise fine) and generally unobservable. With the addition of `getActiveSubmissionToken`, this behavior became obervable and showed its inconsistencies. This patch changes the defined behavior making it where we submit `submissionToken=nonce` for the first play or a single-use or replayable quark operation, but still retain the behavior that `submissions[nonce]=EXHAUSTED` for non-replayables. This ends up as a reduction in the overall code complexity. The only true behavior this changes is that we must (and should) ban `nonce=bytes32(0)` (and for the sake of consistency also `nonce=bytes32(uint_max)`). This is because we would be submitting with `submissionToken=FREE` for that nonce and overall it isn't worth the risk of allowing that (since it wouldn't, but _could_ lead to unlimited replays if other code isn't implemented correctly). Overall, I think this change is a net benefit in reduction of code complexity and better understandability from the end-user's perspective. Patches: * Add a test where we check what values a user can submit for submission tokens * Addressed some #205 comments
hayesgm
force-pushed
the
hayesgm/nonce-as-non-replayable-token
branch
from
6037dc0 to
4c11215
Compare
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Previously in
QuarkNonceManager, we usedsubmissionToken=EXHAUSTEDfor non-replayable submissions andsubmissionToken=noncefor the first play of replayable submissions. Overall, this behavior was inconsistent (though otherwise fine) and generally unobservable. With the addition ofgetActiveSubmissionToken, this behavior became obervable and showed its inconsistencies. This patch changes the defined behavior making it where we submitsubmissionToken=noncefor the first play or a single-use or replayable quark operation, but still retain the behavior thatsubmissions[nonce]=EXHAUSTEDfor non-replayables. This ends up as a reduction in the overall code complexity.The only true behavior this changes is that we must (and should) ban
nonce=bytes32(0)(and for the sake of consistency alsononce=bytes32(uint_max)). This is because we would be submitting withsubmissionToken=FREEfor that nonce and overall it isn't worth the risk of allowing that (since it wouldn't, but could lead to unlimited replays if other code isn't implemented correctly).Overall, I think this change is a net benefit in reduction of code complexity and better understandability from the end-user's perspective.