Recursive public fns in ACIR public simulator #467
Conversation
| @@ -16,6 +16,7 @@ export interface ACIRCallback { | |||
| notifyCreatedNote(params: ACVMField[]): Promise<[ACVMField]>; | |||
| notifyNullifiedNote(params: ACVMField[]): Promise<[ACVMField]>; | |||
| callPrivateFunction(params: ACVMField[]): Promise<ACVMField[]>; | |||
| callPublicFunction(params: ACVMField[]): Promise<ACVMField[]>; | |||
There was a problem hiding this comment.
Just a suggestion but I feel like at this point we could type the callback as a Record with key string and value functions with type (params: ACVMField[]) => Promise<ACVMField[]>
There was a problem hiding this comment.
Unfortunately not all functions have the same signature: we have return types ACVMField[] and [ACVMField]. We could use ACVMField[] for all, but I think it's nice to hace an extra check. And using record with key string means we don't get type checks for the function names. I think I'd stick with the verbose approach for now.
yarn-project/noir-contracts/src/contracts/child_contract/src/main.nr
Outdated
Show resolved
Hide resolved
| private log = createDebugLogger('aztec:simulator:public-executor'), | ||
| ) {} | ||
|
|
||
| public async execute(request: TxRequest): Promise<PublicExecutionResult>; |
There was a problem hiding this comment.
Wouldn't it be clearer if the Executor just handles TxRequests and creates Executions with them? and then executions can create nested executions (similar to the simulator=>execution relationship of the private calls). I'm not sure though :D
There was a problem hiding this comment.
I wanted the execution object to be as dumb as possible, so it just carries the information of the execution itself, while keeping the logic in the executor. Maybe the catch is keeping this execute method simpler, to just handle executions, and have a separate createExecutionFromTxRequest as you suggest? I'll think about it!
There was a problem hiding this comment.
The createExecutionFromTxRequest approach sounds good to me! however I was just being picky about readability, whatever you think is best :D
yarn-project/noir-contracts/src/contracts/child_contract/src/main.nr
Outdated
Show resolved
Hide resolved
spalladino
force-pushed
the
palla/recursive-public-fns
branch
from
475dcdf to
327290c
Compare
…5s wasm time). (#434) * Remove foundation submodule, add build-system * Initial bindgen work. * GPT4 created rust bindgen. * Debug build preset wasm-dbg for stack traces etc. * Async call support. Refactor binds. Common is module. WASM stubs unused wasi. * Move some c_bind to module root and make use new abi. * Initial working pthreads. * Polynomial cache * Custom poly allocator. Prealloc. * Cleanup. Several parallel_for solutions. Might be worth keeping them around until threading work stabilises. * Improve mem usage by slab allocating large parts of pippenger runtime state, and allowing slab reuse by removing from pk. * Don't need binaryen. * Bump alpine to get clang 16 * Backwards compatible cbinds. * Move slab allocator to common. Init slab allocator just before creating pk. * Dont need bleeding edge fork of libc anymore * bb.js is standalone prover that handles noir constraint/witness output. (#471) * format msgpack serialization and excldue msgpack-c from clang-format (#467) * Fix horrific nasty memory bug. --------- Co-authored-by: Suyash Bagad <[email protected]> Co-authored-by: Maxim Vezenov <[email protected]> Co-authored-by: Maddiaa <[email protected]> Co-authored-by: ledwards2225 <[email protected]> Co-authored-by: Innokentii Sennovskii <[email protected]> Co-authored-by: kevaundray <[email protected]> Co-authored-by: zac-williamson <[email protected]> Co-authored-by: codygunton <[email protected]>
callPublicFunctionoracle function in NoirRelated to #430