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
{{ message }}
This repository has been archived by the owner on Aug 27, 2021. It is now read-only.
The recent upgrade, which switches the core protocols to xJsnark's, has suggested considerations on a separate metric: density.
Basically, xJsnark's techniques have been developed sophisticatedly toward reducing the number of constraints. However, some of the techniques may not be best for density. As we already found,
Selecting parameters that minimize the number of constraints (smaller limbs) could lead to a high density during the mul_without_reduce.
The linear checking approach used for creating multiplication limbs does not work the best for density.
In addition, it might be worthwhile to see if the old method of reduction (which does not always reduce to the normal form) would result in a much smaller density.
The text was updated successfully, but these errors were encountered:
Sign up for freeto subscribe to this conversation on GitHub.
Already have an account?
Sign in.
The recent upgrade, which switches the core protocols to xJsnark's, has suggested considerations on a separate metric: density.
Basically, xJsnark's techniques have been developed sophisticatedly toward reducing the number of constraints. However, some of the techniques may not be best for density. As we already found,
mul_without_reduce
.In addition, it might be worthwhile to see if the old method of reduction (which does not always reduce to the normal form) would result in a much smaller density.
The text was updated successfully, but these errors were encountered: