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
We currently have no limits when deserializing compiled circuits, keys and proofs. But it would be beneficial to allow having some limits when gnark is run as a service with input coming externally to be able to bound the sizes of circuits etc.
There are several approaches:
add some options to the ReadFrom interfaces (max circuit size etc.). But the problem with this approach is that we would like to use io.ReaderFrom which doesn't allow to use options. Maybe we could have a wrapper option instead e.g. gnarkio.LimitSize(io.ReaderFrom) io.ReaderFrom etc.
implement io.LimitReader instead. But this would prevent having different limits and only limit on the file (or in-memory?) size.
We currently have no limits when deserializing compiled circuits, keys and proofs. But it would be beneficial to allow having some limits when gnark is run as a service with input coming externally to be able to bound the sizes of circuits etc.
There are several approaches:
ReadFrom
interfaces (max circuit size etc.). But the problem with this approach is that we would like to useio.ReaderFrom
which doesn't allow to use options. Maybe we could have a wrapper option instead e.g.gnarkio.LimitSize(io.ReaderFrom) io.ReaderFrom
etc.io.LimitReader
instead. But this would prevent having different limits and only limit on the file (or in-memory?) size.cc @gbotrel
The text was updated successfully, but these errors were encountered: