-
Notifications
You must be signed in to change notification settings - Fork 324
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
feat: add inclusion proofs txe tests #11711
feat: add inclusion proofs txe tests #11711
Conversation
This stack of pull requests is managed by Graphite. Learn more about stacking. |
93133f7
to
d31fc38
Compare
ae7c789
to
65b3357
Compare
d31fc38
to
3410f84
Compare
65b3357
to
20d86fd
Compare
1abffff
to
282a5bc
Compare
20d86fd
to
aa5d4ba
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.
Why not delete the e2e test?
let owner = env.create_account(); | ||
env.impersonate(owner); | ||
|
||
// Advance a block so we know that at block 2 our contract has not been deployed yet. |
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 don't understand this comment
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.
Yeah reading this back its definitely not thorough enough. Addressed in 85902d8
noir-projects/noir-contracts/contracts/inclusion_proofs_contract/src/test.nr
Show resolved
Hide resolved
} | ||
|
||
#[test(should_fail_with = "Nullifier witness not found for nullifier")] | ||
unconstrained fn test_contract_not_initialized() { |
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.
unconstrained fn test_contract_not_initialized() { | |
unconstrained fn contract_not_initialized() { |
for consistency
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.
Ah very good point thank you 🙏. Have reworked some of the naming in 85902d8
} | ||
|
||
#[test(should_fail_with = "Nullifier witness not found for nullifier")] | ||
unconstrained fn test_contract_not_deployed() { |
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 test seems to be equal to the one above.
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.
Hmm to me it seems to not be equal to the above test, one checks for the fail of initialization, the other for the fail of deployment. But I think it's definitely not clear enough so thank you for pointing that out. Have added some comments to explain this in 85902d8
let NOTE_VALUE = 69; | ||
InclusionProofs::at(contract_address).create_note(owner, NOTE_VALUE).call(&mut env.private()); | ||
|
||
env.advance_block_by(2); |
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.
Why 2?
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'm not sure anymore 😅. Changed to the default (1) in 85902d8
aa5d4ba
to
c96f3fb
Compare
d5127ab
to
f317db5
Compare
c96f3fb
to
bb58c87
Compare
f317db5
to
df09858
Compare
baa69a2
to
edbd170
Compare
df09858
to
0882c5b
Compare
0882c5b
to
353748e
Compare
edbd170
to
3bb2506
Compare
955f6b0
to
a750023
Compare
57bee7d
to
e763b46
Compare
20a0708
to
01742d6
Compare
e763b46
to
35cc0c4
Compare
01742d6
to
b729ebb
Compare
35cc0c4
to
cd72a0e
Compare
cd72a0e
to
69c913c
Compare
b729ebb
to
4ae6c08
Compare
4ae6c08
to
85902d8
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.
😝
env.advance_block_by(1); | ||
|
||
let current_contract_address = get_contract_address(); | ||
cheatcodes::set_contract_address(contract_address); |
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.
Why do we do this?
assert(note.owner.eq(owner)); | ||
assert(note.value.eq(NOTE_VALUE)); | ||
|
||
// Each of these tests (note inclusion, note non-nullification, and validity (inclusion & non-nullification)) check the assertion at the block of creation of note, as well as at the "current" block |
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 see that block with number 0 is used. Is that the current block? That's kinda weird. Also as far as I remember block 0 is not a legitimate block number (we start from 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.
i see that the InclusionProof contract ignores it.
Please nuke the use_block_number
param from InclusionProofs contract and always use the block number.
It used to be there because from TS we don't have a direct control over block numbers (which we do in TXE tests)
} | ||
|
||
#[test] | ||
unconstrained fn note_flow() { |
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.
unconstrained fn note_flow() { | |
unconstrained fn note_validity() { |
I think note_validity is a better name here as it communicates what is being tested.
#[test] | ||
unconstrained fn nullify_note_flow() { | ||
// This test creates a note, nullifies it, and checks certain properties about it, namely its inclusion in the trees, | ||
// the non-inclusion of its nullifier, and its validity (the combination of the previous two). These properties are checked before nullification. |
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 comment is weird. It says that you nullify the note and then you prove that it's not nullified.
} | ||
|
||
#[test] | ||
unconstrained fn nullify_note_flow() { |
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 think this test can be merged with the previous one as both test note validity.
- create note,
- test note validity at current block,
- nullify note,
- test note validity at historical block.
This test is only slightly more strict by checking the the nullifier non-inclusion is handled correctly.
} | ||
|
||
#[test(should_fail_with = "Assertion failed: Proving nullifier non-inclusion failed: low_nullifier.value < nullifier.value check failed")] | ||
unconstrained fn note_not_nullified_after_nullified() { |
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.
unconstrained fn note_not_nullified_after_nullified() { | |
unconstrained fn nullifier_non_inclusion_failure() { |
|
||
InclusionProofs::at(contract_address).create_note(owner, 5).call(&mut env.private()); | ||
|
||
env.advance_block_by(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.
Shouldn't we automine now? And if it's not yet implemente do we have an issue?
If we have an issue would include a todo everywhere here.
} | ||
|
||
#[test(should_fail_with = "Assertion failed: Proving nullifier non-inclusion failed: low_nullifier.value < nullifier.value check failed")] | ||
unconstrained fn note_not_nullified_after_nullified_no_block_number() { |
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 test looks like the same thing as the previous one and hence would merge it. Note that we are not testing the InclusionsProof
contract but the history library and it triggers the same code paths.
Shouldn't we also nuke the inclusion_proofs test in the |
Adding inclusion proof txe tests to hopefully replace
flaky_e2e_inclusion_tests