This repository has been archived by the owner on Apr 9, 2024. It is now read-only.
feat(acir): Add length to BlackBoxFuncCall serialization #285
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Related issue(s)
Works towards resolving #234.
Description
After #269 we moved
BlackBoxFuncCall
to struct variants with explicit function signatures. The inputs are now separated which is a welcome change. However, the way BlackBoxFuncCalls are currently being written still follows the old method when everything was handled in a flattened inputs vector. Now that we are splitting up the inputs into separate input fields this requires us to have hardcoded function signatures when serializing our function inputs. This is fine for our existing blackbox funcs as any current functions that have variable inputs have only one and it can be serialized as the last input of the function signature.For recursion we can have multiple function inputs that all vary in size.
VerifyProof
will require akey
,proof
,public_inputs
,key_hash
, andinput_aggregation_object
. The key hash is a single element that can be computed by the respective backend. Every other function input can vary depending on the proving system. Thus the way we currently read in a flattened vector is not sufficient.Summary of changes
I added a new struct
FunctionInputIO
that stores the length of a given function input. Singular function inputsare not affected as the function signature determines whether we should fetch the first element of a vector when reading in the function inputs or return a vector with a single element.
Dependency additions / changes
(If applicable.)
Test additions / changes
I included one more black box func that has multiple vector based function inputs in the serialization_roundtrip test.
Checklist
cargo fmt
with default settings.Additional context
(If applicable.)