You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I've noticed that we reuse ZK_ROWS in a number of places, and it's not always clear what rows of the domain are here because they're part of the circuit, or part of ZK_ROWS, or part of a boundary/additional constraint.
I'm creating this thread as a "hey maybe that could be a good idea, but I haven't really thought about it". Perhaps each argument could be define such that it's a list of type of constraint. Something like this:
Eventually, we would use this to make sure that some constraints are only applied on some rows (and multiply with lagrange basis automatically), and that we don't pad the circuit with zero gates several times for no good reason (for example, to add ZK_ROWS to multiple arguments, when they can share the same ZK_ROWS).
reacted with thumbs up emoji reacted with thumbs down emoji reacted with laugh emoji reacted with hooray emoji reacted with confused emoji reacted with heart emoji reacted with rocket emoji reacted with eyes emoji
-
WARNING: Random idea
I've noticed that we reuse
ZK_ROWS
in a number of places, and it's not always clear what rows of the domain are here because they're part of the circuit, or part of ZK_ROWS, or part of a boundary/additional constraint.I'm creating this thread as a "hey maybe that could be a good idea, but I haven't really thought about it". Perhaps each argument could be define such that it's a list of type of constraint. Something like this:
Eventually, we would use this to make sure that some constraints are only applied on some rows (and multiply with lagrange basis automatically), and that we don't pad the circuit with zero gates several times for no good reason (for example, to add
ZK_ROWS
to multiple arguments, when they can share the sameZK_ROWS
).Beta Was this translation helpful? Give feedback.
All reactions