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
First, when we look at the main function, we end up calling handle_arg which ends up calling constrain_inputs_to_main. As the name indicates, the latter function makes sure that any argument to the main function gets properly constrained. For example:
fnmain(thing:Bool){/* ... */}
will add a boolean constraint to thing. Without these constraints, the circuit wouldn't be secure!
Note
Interestingly, we add constraints to public inputs as well. I think this is debatable and we should actually remove that
the thing is, if we are dealing with a custom type, we don't do any constraining. This is DANGEROUS. For example imagine a custom type like this:
structUint8(Field);fnUint8.new(val:Field) -> Self{is_uint8(val);// add an important constraint!returnUint8(val);}
as this type is intended to be constructed via its new function, it is supposed to be "secure" if used as intended.
Note
and BTW, we don't have anything in noname to enforce that the type is not constructed directly. In Rust you can write things like struct Uint8(pub Field) to allow direct construction and extraction of the inner value. Maybe we should have something like this
But when passed as argument to the main function, one would have to manually check that it is properly constrained:
fnmain(thing:Uint8){
thing.check();// this would eventually call `is_uint8` on the inner val// ...}
maybe we add this thing.check() call automatically by enforcing that every custom struct is also defined with a check function that enforces that it is properly constrained.
PS: I'm wondering what Noir is doing there, for example
The text was updated successfully, but these errors were encountered:
mimoo
changed the title
enforce a new function for custom types?
enforce a new/check function for custom types? (to properly constrain them)
Aug 23, 2024
There's a few interesting things to discuss here.
First, when we look at the main function, we end up calling
handle_arg
which ends up callingconstrain_inputs_to_main
. As the name indicates, the latter function makes sure that any argument to the main function gets properly constrained. For example:will add a boolean constraint to
thing
. Without these constraints, the circuit wouldn't be secure!Note
Interestingly, we add constraints to public inputs as well. I think this is debatable and we should actually remove that
the thing is, if we are dealing with a custom type, we don't do any constraining. This is DANGEROUS. For example imagine a custom type like this:
as this type is intended to be constructed via its
new
function, it is supposed to be "secure" if used as intended.Note
and BTW, we don't have anything in noname to enforce that the type is not constructed directly. In Rust you can write things like
struct Uint8(pub Field)
to allow direct construction and extraction of the inner value. Maybe we should have something like thisBut when passed as argument to the main function, one would have to manually check that it is properly constrained:
maybe we add this
thing.check()
call automatically by enforcing that every custom struct is also defined with acheck
function that enforces that it is properly constrained.PS: I'm wondering what Noir is doing there, for example
The text was updated successfully, but these errors were encountered: