Add builtin serialize and deserialize functions
#2240
Assignees
Labels
enhancement
New feature or request
Comments
spalladino
added a commit
to AztecProtocol/aztec-packages
that referenced
this issue
Aug 14, 2023
… contracts (#1487) Builds on @iAmMichaelConnor work to generate a contract interface for simplifying calling function in other contracts. Uses only information present in the ABI. For each function in the target contract, creates a wrapper function that receives the same arguments, serialises them based on the standard ABI encoding format (see [here](https://github.com/AztecProtocol/aztec-packages/blob/49d272159f1b27521ad34081c7f1622ccac19dff/yarn-project/foundation/src/abi/encoder.ts)), and uses the `call_private_function` from the `context` to call into them. To handle custom structs, we're re-defining them in the contract interface. Until we get struct type names in the ABI (see noir-lang/noir#2238), we are autogenerating the name as well, based on the function name and param name where they are used. Serialisation is done manually in the code, but we may want to replace it with a Noir intrinsic when available (see noir-lang/noir#2240). See [this file](https://github.com/AztecProtocol/aztec-packages/blob/49d272159f1b27521ad34081c7f1622ccac19dff/yarn-project/noir-contracts/src/contracts/test_contract/src/test_contract_interface.nr) for example output. Fixes #1237 --------- Co-authored-by: iAmMichaelConnor <[email protected]>
|
Alternative names would be |
|
Superseded by #3379. |
superstar0402
added a commit
to superstar0402/aztec-nr
that referenced
this issue
Aug 16, 2024
… contracts (#1487) Builds on @iAmMichaelConnor work to generate a contract interface for simplifying calling function in other contracts. Uses only information present in the ABI. For each function in the target contract, creates a wrapper function that receives the same arguments, serialises them based on the standard ABI encoding format (see [here](https://github.com/AztecProtocol/aztec-packages/blob/49d272159f1b27521ad34081c7f1622ccac19dff/yarn-project/foundation/src/abi/encoder.ts)), and uses the `call_private_function` from the `context` to call into them. To handle custom structs, we're re-defining them in the contract interface. Until we get struct type names in the ABI (see noir-lang/noir#2238), we are autogenerating the name as well, based on the function name and param name where they are used. Serialisation is done manually in the code, but we may want to replace it with a Noir intrinsic when available (see noir-lang/noir#2240). See [this file](https://github.com/AztecProtocol/aztec-packages/blob/49d272159f1b27521ad34081c7f1622ccac19dff/yarn-project/noir-contracts/src/contracts/test_contract/src/test_contract_interface.nr) for example output. Fixes #1237 --------- Co-authored-by: iAmMichaelConnor <[email protected]>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Problem
It can be useful for TS tools to have a canonical serialization order for types and a builtin function that automatically converts to this order.
Happy Case
We should add a
serialize<T>(x: T) -> [Field]builtin to serialize every type to a canonical serialization order. This will use the user-defined field order for structs and should issue an error message for types that cannot be serialized such as functions.A pairing
deserialize<T>(fields: [Field]) -> Option<T>function would also be useful.Alternatives Considered
Once traits are added the need for this function isn't entirely obviated since a user-defined
Serializeimpl may not adhere to the canonical serialization order. Can we make this distinction more clear and avoid name conflicts in any way? Or should we not worry about this issue since every type would already be able to be serialized via this builtin and we thus wouldn't need a Serialize trait?Additional Context
No response
Would you like to submit a PR for this Issue?
No
Support Needs
No response
The text was updated successfully, but these errors were encountered: