-
Notifications
You must be signed in to change notification settings - Fork 17
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
Safrole tiny/full vectors #5
Conversation
any descriptions about the scale file? are they only the output? or final state? or both? but in what exact schema? |
The schema mirrors JSON and is defined by ASN.1. |
I see there is a defination of |
- Use blake2b-256 and not truncated blake2-512 - Safrole gamma_k must contain only the pks commitments (not constant SRS data) - Rename some fields in asn1 and json
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.
Looks good.
We got our FFI to work based on your example (thank you!), but in trying to verify a "tiny" extrinsic ticket signature of
we have not been able to verify. Here is our attempt: https://gist.github.com/sourabhniyogi/4adca06a3a7ccf8a88839fa6c4a49826 Our expectation is that we build:
What did we miss? |
The problem in your example is that you used a ring size of 6 to initialize the static ring context. |
Got it -- I got the new ring_context and am pulling the binary of "zcash-srs-2-11-uncompressed.bin" but still no verification yet: |
That in the meantime I fixed the 1023 vs 6 in the initialization of the context :-) For full: initialize the context with ring_size = 1023 |
You need to set RING_SIZE = 6 |
@davxy We are succeeding with most of the STF successfully thanks to your example, but have a few outstanding cases in "tiny" to address:
and the 2 new tickets are
but we don't see evidence of resubmission (in having the same ticket id) and there i-- what did we miss?
|
This test case is not about submitting "more tickets than allowed" (which is 16).
This test is not supposed to fail. I guess you are referring to Here you reported only:
But there are 3 tickets in the extrinsic ;-)
The knowledge that the duplicate is from authority 0 comes from the fact that I generated the tickets, so I know who the author is :-). But indeed doesn't make much sense to write down who is the author. I removed this "hint" from the README (f030025)
This is a borderline case that we don't really expect in prod. It checks what happens when 1+ epochs are skipped (i.e. no block is produced for some reason) and then we see one from some epochs after the one we imported last. |
Got it, I missed the "2", the README updated description of "Fail: Submit an extrinsic with a bad ticket attempt number." is clear, thank you!
Sorry about that! (I missed that our implementation was blocking the resubmission.)
Thank you -- removing the authority "hints" from the README makes it clearer!
Alright, we have passed all tiny cases now. |
@gavofyork I think we can merge this. I don't have the authority to do that in this repo. |
Thanks for the tests! Just got all the full and tiny test cases passing late last week as well :) |
README
Two vectors flavors:
zkSNARK makes use of Zcash SRS https://zfnd.org/conclusion-of-the-powers-of-tau-ceremony (not anymore zero seeded). Check the README
Fixed validator data order (Bandersnatch key before ed25519 key)
Added SCALE encoded blobs together with json files (same ASN.1 schema)
Use blake2b-256 and not truncated blake2-512
Fix gamma_k to contain only the public keys commitment (remove constant SRS data)
Rename some fields in asn1 and json with same identifiers used in the GP
validate.sh
script: checks validity of json vectors wrt ASN.1 schema (needs Fix jer optional values eerimoq/asn1tools#182)Closes #6