David Banks
1 day ago
Could Noir Tooling (noir.js?) expose a function compute_vk(acir_opcodes)? I know there are functions in barretenberg to compute a VK from constraints, but we are wondering if we can do so from opcodes/bytecode.
Maxim Vezenov
1 day ago
The tooling would just need to include the logic to serialize from acir to bb circuit. We already have existing functions natively for computing pk and vk given a constraint system. However the API right now computes a pk given a constraint system and computes a vk given a pk. Technically you could combine these two methods to do that with what exists now
:pray:
1
Maxim Vezenov
1 day ago
Is there a reason we would need to have a function that does just acir -> vk ?
David Banks
1 day ago
I think the idea is that a user will need to be able to submit ACIR to the private client (now called ARSe?) to get VKs and generate/recreate the function tree. They shouldn't need the original source code to do this, just the bytecode/opcodes.
I might be missing/misunderstanding some reasoning behind the need for this functionality. I can pull mike into this convo tomorrow to supplement my explanation. (edited)
Tom French
1 day ago
They shouldn't need the original source code to do this, just the bytecode/opcodes.
That's currently the case. We currently generate pk/vk at compile time for convenience but this works on the underlying ACIR and doesn't need knowledge of source code.
The nargo preprocess command is basically doing what you say: https://github.com/noir-lang/noir/blob/master/crates/nargo/src/cli/preprocess_cmd.rs
:fire:
1
Alvaro Rodriguez
1 day ago
I think it might be necessary to authenticate code. Opcodes can fetch secret information and expose it to the Dapp. If the dapp tells us that it wants to speak with the DAI contract with this ABI (and the ABI contains the ACIR of the supposed DAI contract), before simulating any function call of that ABI we should validate that the VKs of those functions correspond with the ones deployed on chain.
You can cache that ACIR verification in the ARSe but the step ACIR => VK needs to be available from noir tooling
:+1:
1
Alvaro Rodriguez
1 day ago
Also, i think we'd need ACIR => PK, in order to actually prove execution of private functions (or at least [acir, partialWitness] => proof). (edited)
Joe
1 day ago
We don’t have to call it ARSe haha, just AztecRPCSever. Or ARS.
ARSe is funny but likely poor acronym.
:rolling_on_the_floor_laughing:
3
David Banks
1 day ago
Thanks for chiming in here Alvaro! And thank you Tom for this info :pray: Is there a JS workalike to nargo preprocess? And if not would it be much effort for Noir Tooling team to add this?
Maxim Vezenov
1 day ago
Can we not validate the deployed acir with just an Acir hash? Having to recompute the vk everytime seems especially time consuming for the user and we should avoid it if we can. Although this tooling will still be necessary for other parts of the stack
:+1:
1
Maxim Vezenov
1 day ago
There isn’t yet preprocessing that exists on the JS side yet to my knowledge but it should not be bad to add. We are in the middle of a move to upstream bb so once that is complete it should be simple to include
Alvaro Rodriguez
1 day ago
Yes! It should be possible with just the acir hash, so we don't need the vk to authenticate
David Banks
1 day ago
We are planning to track acir_hash in function leaves too. To be honest I'm blanking at the moment on why we need a function for opcodes=>vk. Even after your first comment last night Maxim I was wondering the same thing and started to doubt my own question lol. I'll check with Mike and report back.
Alvaro Rodriguez
1 day ago
Yep, I also cannot think of examples right now why we need ACIR => vk in JS. If we plan to always use the ABIs and those contain the VKs generated with the compiler...
Tom French
1 day ago
Yep, I also cannot think of examples right now why we need ACIR => vk in JS.
This is useful for the case in which we're compiling Noir in the browser.
:+1:
1
:heavy_plus_sign:
1
Koby
1 day ago
Is there a JS workalike to nargo preprocess? And if not would it be much effort for Noir Tooling team to add this?
I think it's not much effort, this is property of bb itself therefore would be exposed from different package but it would be available in a way Max explained
Tom French
24 hours ago
It depends on how aware of ACIR we want to make BB, currently it always receives what aztec_backend calls ConstraintSystem although it calls it acir_format. We'll probably want to wrap whatever is in BB.js in a helper which accepts ACIR bytecode to hide this so it could be exposed by our package.
Koby
24 hours ago
this would be bb.js or another js wrapper responsibility - probably minor detail
Joss Clifford-Frith
24 hours ago
Seconded. More generally I think we should make nargo more impartial than it is already. I think we don't want to assume the anatomy of proofs, keys, composite proofs etc. Zac's presentation just now painted a picture of a proving architecture that could not be handled by the interfaces that nargo currently supports.
Savio
8 hours ago
JS workalike to nargo preprocess?
Is that sth the A3 team is looking to hack with during offsite? (Or is it more “can it be done down the road”?)
Koby
8 hours ago
can be done down the road
:pray:
1
Joss Clifford-Frith
8 hours ago
The quickstart lib I've put together invokes the equivalent set of responsibilities via prepare
:fire:
3
Joss Clifford-Frith
8 hours ago
The key difference is that it leaves to prover/verifier to decide how to handle keys, rather than forcing a pattern. (It's awkward for nargo to grant that the same freedom because it treats the backend as stateless.)
David Banks 1 day ago Could Noir Tooling (noir.js?) expose a function compute_vk(acir_opcodes)? I know there are functions in barretenberg to compute a VK from constraints, but we are wondering if we can do so from opcodes/bytecode.
Maxim Vezenov 1 day ago The tooling would just need to include the logic to serialize from acir to bb circuit. We already have existing functions natively for computing pk and vk given a constraint system. However the API right now computes a pk given a constraint system and computes a vk given a pk. Technically you could combine these two methods to do that with what exists now :pray: 1
Maxim Vezenov 1 day ago Is there a reason we would need to have a function that does just acir -> vk ?
David Banks 1 day ago I think the idea is that a user will need to be able to submit ACIR to the private client (now called ARSe?) to get VKs and generate/recreate the function tree. They shouldn't need the original source code to do this, just the bytecode/opcodes. I might be missing/misunderstanding some reasoning behind the need for this functionality. I can pull mike into this convo tomorrow to supplement my explanation. (edited)
Tom French 1 day ago They shouldn't need the original source code to do this, just the bytecode/opcodes. That's currently the case. We currently generate pk/vk at compile time for convenience but this works on the underlying ACIR and doesn't need knowledge of source code. The nargo preprocess command is basically doing what you say: https://github.com/noir-lang/noir/blob/master/crates/nargo/src/cli/preprocess_cmd.rs :fire: 1
Alvaro Rodriguez 1 day ago I think it might be necessary to authenticate code. Opcodes can fetch secret information and expose it to the Dapp. If the dapp tells us that it wants to speak with the DAI contract with this ABI (and the ABI contains the ACIR of the supposed DAI contract), before simulating any function call of that ABI we should validate that the VKs of those functions correspond with the ones deployed on chain. You can cache that ACIR verification in the ARSe but the step ACIR => VK needs to be available from noir tooling :+1: 1
Alvaro Rodriguez 1 day ago Also, i think we'd need ACIR => PK, in order to actually prove execution of private functions (or at least [acir, partialWitness] => proof). (edited)
Joe 1 day ago We don’t have to call it ARSe haha, just AztecRPCSever. Or ARS. ARSe is funny but likely poor acronym. :rolling_on_the_floor_laughing: 3
David Banks 1 day ago Thanks for chiming in here Alvaro! And thank you Tom for this info :pray: Is there a JS workalike to nargo preprocess? And if not would it be much effort for Noir Tooling team to add this?
Maxim Vezenov 1 day ago Can we not validate the deployed acir with just an Acir hash? Having to recompute the vk everytime seems especially time consuming for the user and we should avoid it if we can. Although this tooling will still be necessary for other parts of the stack :+1: 1
Maxim Vezenov 1 day ago There isn’t yet preprocessing that exists on the JS side yet to my knowledge but it should not be bad to add. We are in the middle of a move to upstream bb so once that is complete it should be simple to include
Alvaro Rodriguez 1 day ago Yes! It should be possible with just the acir hash, so we don't need the vk to authenticate
David Banks 1 day ago We are planning to track acir_hash in function leaves too. To be honest I'm blanking at the moment on why we need a function for opcodes=>vk. Even after your first comment last night Maxim I was wondering the same thing and started to doubt my own question lol. I'll check with Mike and report back.
Alvaro Rodriguez 1 day ago Yep, I also cannot think of examples right now why we need ACIR => vk in JS. If we plan to always use the ABIs and those contain the VKs generated with the compiler...
Tom French 1 day ago Yep, I also cannot think of examples right now why we need ACIR => vk in JS. This is useful for the case in which we're compiling Noir in the browser. :+1: 1 :heavy_plus_sign: 1
Koby 1 day ago Is there a JS workalike to nargo preprocess? And if not would it be much effort for Noir Tooling team to add this? I think it's not much effort, this is property of bb itself therefore would be exposed from different package but it would be available in a way Max explained
Tom French 24 hours ago It depends on how aware of ACIR we want to make BB, currently it always receives what aztec_backend calls ConstraintSystem although it calls it acir_format. We'll probably want to wrap whatever is in BB.js in a helper which accepts ACIR bytecode to hide this so it could be exposed by our package.
Koby 24 hours ago this would be bb.js or another js wrapper responsibility - probably minor detail
Joss Clifford-Frith 24 hours ago Seconded. More generally I think we should make nargo more impartial than it is already. I think we don't want to assume the anatomy of proofs, keys, composite proofs etc. Zac's presentation just now painted a picture of a proving architecture that could not be handled by the interfaces that nargo currently supports.
Savio 8 hours ago JS workalike to nargo preprocess? Is that sth the A3 team is looking to hack with during offsite? (Or is it more “can it be done down the road”?)
Koby 8 hours ago can be done down the road :pray: 1
Joss Clifford-Frith 8 hours ago The quickstart lib I've put together invokes the equivalent set of responsibilities via prepare :fire: 3
Joss Clifford-Frith 8 hours ago The key difference is that it leaves to prover/verifier to decide how to handle keys, rather than forcing a pattern. (It's awkward for nargo to grant that the same freedom because it treats the backend as stateless.)