-
Notifications
You must be signed in to change notification settings - Fork 45
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
Rethink the zk circuits architecture #50
Comments
Still potentially relevant: optimized shuffling approaches. |
Some preliminary discovery: so I played around with hashing the whole array instead of computing merkle root (though I haven't tried byte packing). For the There are still some area for optimization for the circuits, including trying out the byte packing approach, just writing my findings here to show that hashing array instead of computing merkle root might be more expensive for Code changes: master...byte-packing |
Nice! I'm not super surprised by the numbers: if you think about it, the DrawHand circuit did ~63 hashes of two field elements each, and now we're doing one hash of 64 elements, so about 50% reduction seems about right. Packing the bytes means we need to do one hash of only 4 elements (salt + 3 elements to pack 64 cards), so looking forward to that :p Hopefully, the same logic applies to the Draw circuit where again instead of checking log2(64)=6 hashes of two fields elements for every Merkel branch, we get to do one hash of 4 elements for the each of (oldHand, newHand, oldDeck, newDeck) — (I think we had to check more than one Merkle proof for each of those on average, so hopefully we end up with a win!). |
Our previous approach to circuits works, but has really high proving time when compiled to wasm (proving a Merkle root computed over a 64 field element arrays takes 60+s and requires downloading a 3GB zkey to the client).
Fortunately, we think it's possible to do much better:
However, doing this means we need to change the circuits to do a combination of indexing and shifts instead of straightforward indexing.
We're also investigating some other optimizations.
Assigning this to Kai Jun as he's likely to rewrite this in Circom, but the investigation here will be relevant for the direction of #48 and #49
The text was updated successfully, but these errors were encountered: