ZK circuits tools in the Aptos ecosystem

[khemiriwalid]

Discord user ID

No response

Describe your question in detail.

Hello, I'm looking at https://github.com/aptos-labs/keyless-zk-proofs. Is there a circom verification key generator in Move?
Is there any framework or ZK circuit language where I can program a circuit, generate a proving key, and a verification key generator in Move?

What error, if any, are you getting?

No response

What have you tried or looked at? Or how can we reproduce the error?

No response

Which operating system are you using?

N/A

Which SDK or tool are you using? (if any)

N/A

Describe your environment or tooling in detail

No response

[zjma]

@khemiriwalid if you have compiled your circom circuit and use snarkjs to generate the proving key and the verification key (assuming the underlying curve is bn254), you can then use our snarkjs-to-aptos converter to get an verifier move module that can be (almost) directly used in your dapp contract.

[alinush]

@zjma, should we move this tool to the https://github.com/aptos-labs/keyless-zk-proofs repo? I think you've mentioned it several times and it seems useful. (There is also the vk-diff tool there that may have overlapping functionality!)

[khemiriwalid]

Awesome!
I need to use snarkjs to generate the proof and include it in the same format in the transaction?
Is there any full example or guide?

[alinush]

Hi @khemiriwalid, can you clarify what are you trying to do? Give more context?

In principle, you can compile our circuit with snarkjs and get a VK. Then you can convert it to a format for Move via the tool @zjma included. But what do you hope to achieve? We'd be able to help you better if we understand.

[khemiriwalid]

Hello @alinush , more context :
Today, most blockchain user accounts are secured and controlled by different types of signers(ECDSA signature, webauthn, multi-sig, MPC, etc). Blockchains and smart contracts are only programmed to trust signers, validating transactions solely through signature verification. They are a good solution, but not enough to secure smart accounts.
The Blockchain has no idea of the intended on-chain behavior of end-users. It will accept any transaction(even a malicious one, like a Bybit attack) based only on providing a valid signature.

Our solution involves building smart accounts with predefined capabilities at different granularity levels(each key or sub-key is configured to do a very specific set of on-chain actions/permissions). We need to secure and control the on-chain behavior of normal users' on-chain accounts by defining the allowed on-chain actions.

Our goal is to build an off-chain trust-minimized/trustless engine that secures and controls the account's on-chain behavior based on the user's preferences and intended behavior using ZKPs. We define and configure the on-chain behavior of a smart account in advance(Scope). Then, we prove via ZK that the transaction behavior is compliant and aligned with the defined on-chain behavior of a smart account. We’re checking the technical feasibility of such a concept within account abstraction(AA) in the Aptos Blockchain.

So, I'm asking about the proof generation in JavaScript and, more precisely, "const { proof, publicSignals } = await snarkjs.groth16.fullProve(circuitInputs, witnessGenerationPath, provingKeyPath);" is this proof transmitted in the transaction to be verified in the move module generated by your snarkjs-to-aptos converter, or does it need some transformation?

[alinush]

I see: you want to implement keyless signature verification in Move / in AA.

I don't think we can assist you in the engineering part at this low level of a detail.

Sure, the Groth16 proof is currently included in transactions for keyless accounts (you can see this here: $\sigma_\mathsf{txn}$ includes the Groth16 ZKP $\pi$).

Yes, you will need your Move module to verify this proof (amongst many other things). I don't know how much of the Groth16 verification code snarkjs-to-aptos will generate for you but, judging by the README, it should generate all of it.

Nonetheless, I would say: proceed slowly, with great caution! In particular, make sure you understand the keyless design fully:

• the need for a pepper service
• the need for a prover service with training wheels to mitigate against bugs in the circom circuit code
• the need for a secure JWK oracle

All of these are covered in AIP-61.

There are also a lot of resources on my personal page.

[khemiriwalid]

Thanks for your response