Move low-level operations to JS #967
Conversation
| setTimeout(async () => { | ||
| await shutdown(); | ||
| }, 0); | ||
| }); | ||
|
|
||
| describe('Inside circuit', () => { |
There was a problem hiding this comment.
can we use the quickcheck generator Gregor made earlier to check some of the algebraic properties for edge cases?
There was a problem hiding this comment.
I was thinking about that as well, however, I think there is no easy way to sample valid Group elements other than brute forcing (or is there?) that's why the existing tests mostly work with the generator and (-1, 2)
There was a problem hiding this comment.
I used to sample public keys (= group elements) by picking a random private key (= scalar) and scaling the group generator with it.
That's not super efficient but good enough.
However, now we have hashToCurve which should be faster, especially if you skip the hash and only do random field element + mapToCurve
There was a problem hiding this comment.
Oh right, I didn't consider that at all 😵💫 I'll add some more tests, just to be sure!
| "rows": 42, | ||
| "digest": "8d5ab248aa4602e6f77a8ab1015615df" |
There was a problem hiding this comment.
can you explain this blowup in Group.equals() constraints @Trivo25?
There was a problem hiding this comment.
is it just caused by the added constraints in check()?
There was a problem hiding this comment.
The Group Primitive.equals check bundles a couple additional equality checks than just a simple equals(), it does the following:
let g1 = Provable.witness(Group, () => Group.generator);
let g2 = Provable.witness(Group, () => Group.generator);
g1.equals(g2).assertTrue();
g1.equals(g2).assertFalse();
g1.equals(g2).assertEquals(true);
g1.equals(g2).assertEquals(false);So its calling equals multiple times, which blows up the constraints a bit more. The single equals constraints aren't that bad, just inflated by the batch. The additional constraints come from zero-related checks (such as .check)
There was a problem hiding this comment.
yeah I understand that it has more, but the only thing that changed in that circuit should be check() and equals(), so I was wondering what explains the increase in circuit size compared to the previous version
There was a problem hiding this comment.
yea, its the change in check
This PR is a follow up to #932. It further reduces dependencies to OCaml by re-using more of the existing clue as well as moving some additional functionality to JavaScript. The PR also addresses handling of the
zero/infinityelement by adding further constraints (it breaks existing smart contracts, whereas the previous PR tried to establish a baseline without any major constraint changes).bindings o1-labs/o1js-bindings#35