Generate the proofs for the resource logics using the Anoma API (e.g. CLI) in a local environment.
Inputs:
Resource logic Cairo bytecode (from step 1)
Resource logic inputs in a .json file
Outputs:
Program proof binary
Generate compliance proof
Inputs:
compliance.json file, where the “logic” field points to the path to the proof binary field. The Juvix API computes the hash of the file under the hood. This reduces the cognitive burden from the user.
Submit transaction to Anoma
Create partial transaction(s)
Inputs:
Some number of resource proof binaries (generated by step 2)
Some number of compliance proof binaries (generated by step 3)
Create final transaction
Inputs:
Partial transactions
Delta: List of “rcv” fields in the compliance_input.json files corresponding to the provided compliance proofs
Yes, I think step 3 can be merged into step 4. The user would provide compliance_input.json files for each compliance proof, and then the system would create compliance proof binaries and extract the “rvc” fields without user intervention.
Question: do resource proof binaries in step 3 always correspond to the resource logics in the compliance_input.json files, and should always just be submitted in the order in which they occur in the json files?
For example, we have two compliance files:
compliance1.json:
{
"input": {
"logic": <hash of logic1A_proof>
...
},
"output": {
"logic": <hash of logic1B_proof>
...
}
}
compliance2.json:
{
"input": {
"logic": <hash of logic2A_proof>
...
},
"output": {
"logic": <hash of logic2B_proof>
...
}
}
In other words, is the partial transaction always uniquely determined from compliance1.json and compliance2.json in this way, or can the user, e.g., add some other unrelated proofs to logic_proofs, or the order may be different, etc?
From the Elixir code it seems that ComplianceInput always has two shielded resources with resource logics inside: input and output. Is this correct? Or can compliance inputs contain other shielded resources?
The compliance_input.json “logic” field always corresponds to the hash of the resource proof binary generated in step 2.
I would stick to an order, like the one you suggested. Maybe in the future the use may add some other data (e.g. there was some discussion on adding “hints”) but we can completely forget about that.
The compliance_input.json “logic” field always corresponds to the hash of the resource proof binary generated in step 2.
Sorry, I meant step 4 not 3, but I assume from the above that the answer is yes.
I think that then we can merge steps 2-4 into one step from the user perspective. Because if the partial transaction is uniquely determined from the compliance files, then we could take as input:
compliance_input.json files with paths to compiled Cairo bytecode in the “logic” fields,
json files storing inputs for the resource logics.
Then we can automatically do the following without user intervention:
generate proofs for resource logics (step 2 above)
generate the compliance proof using the compliance_input.json files provided, but with the “logic” fields substituted with hashes of the generated resource logic proofs (step 3)
create a partial transaction which is uniquely determined from the resource and compliance proofs that we’ve generated
create a final transaction
submit nock-encoded transaction candidate
So the user wouldn’t see any proofs – everything happens under the hood. They only need to provide compliance circuit input files with “logic” fields pointing to compiled cairo bytecode for the resource logics, and files storing inputs for each resource logic
This assumes that the final transaction contains only one partial transaction, which if I remember correctly is the case for now. In the future, we might need to have a command to generate each partial transaction separately.
Can someone (@xuyang ?) explain again how to hash a resource logic proof? Because I didn’t note this down. I forgot which hash function to use and now I’m getting some errors.
The final transaction contains a bunch of partial transactions. The number depends on the applications or intents as long as we can balance the final transaction.
