# Juvix - Anoma: Generate TX Candidate **URL:** \ **Category:** Protocol Design\ **Created:** [September 13, 2024, 11:16am UTC](https://forum.anoma.net/t/juvix-anoma-generate-tx-candidate/763 "2024-09-13T11:16:55Z")\ **Posts on this page:** 12\ **Page:** 1
**Author:** ![alberto](https://dub1.discourse-cdn.com/flex013/user_avatar/forum.anoma.net/alberto/32/59_2.png) [@alberto](https://forum.anoma.net/u/alberto)\ **Post date:** [September 13, 2024, 11:16am UTC](https://forum.anoma.net/t/juvix-anoma-generate-tx-candidate/763/1 "2024-09-13T11:16:55Z")
**Goal: Describe the user’s steps to submit a transaction candidate to Anoma using the Cairo backend**. (These are notes taken from Juvix ↔ Anoma session at HHH on 13-Sep-24 with @xuyang @camofu and led by @Lukasz ). This process represents the first transition of the [Anoma Node Transaction Code Lifecycle](https://forum.anoma.net/t/anoma-node-transaction-code-lifecycle/750): ![Untitled-2024-09-04-1524 (1)](https://europe1.discourse-cdn.com/flex013/uploads/anoma1/original/1X/8b7b41bd9a54e0707157184ddde82e0f13b2327a.jpeg) 1. **Compile Juvix to Cairo** bytecode. 2. **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 3. **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. 4. **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 - Encode into Nock Transaction Candidate ---
**Author:** ![alberto](https://dub1.discourse-cdn.com/flex013/user_avatar/forum.anoma.net/alberto/32/59_2.png) [@alberto](https://forum.anoma.net/u/alberto)\ **Post date:** [September 13, 2024, 11:20am UTC](https://forum.anoma.net/t/juvix-anoma-generate-tx-candidate/763/2 "2024-09-13T11:20:54Z")
I wonder if step 3, **Generate compliance proof** , can be hidden from the user using the Anoma API. The user would still need to provide the necessary inputs such as quantity, but I would not expose the user to the compliance proof. ---
**Author:** ![Lukasz](https://avatars.discourse-cdn.com/v4/letter/l/0ea827/32.png) [@Lukasz](https://forum.anoma.net/u/Lukasz)\ **Post date:** [September 13, 2024, 12:08pm UTC](https://forum.anoma.net/t/juvix-anoma-generate-tx-candidate/763/3 "2024-09-13T12:08:34Z")
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. ---
**Author:** ![Lukasz](https://avatars.discourse-cdn.com/v4/letter/l/0ea827/32.png) [@Lukasz](https://forum.anoma.net/u/Lukasz)\ **Post date:** [September 13, 2024, 12:16pm UTC](https://forum.anoma.net/t/juvix-anoma-generate-tx-candidate/763/4 "2024-09-13T12:16:43Z")
Here are photos of the blackboard. ![20240913_120902](https://europe1.discourse-cdn.com/flex013/uploads/anoma1/original/1X/91b94db54b99f02a35deb5e65791aff8677259a8.jpeg) ![20240913_124538](https://europe1.discourse-cdn.com/flex013/uploads/anoma1/original/1X/213a694e9c9946f9183556250de603fc390c7e15.jpeg) ---
**Author:** ![Lukasz](https://avatars.discourse-cdn.com/v4/letter/l/0ea827/32.png) [@Lukasz](https://forum.anoma.net/u/Lukasz)\ **Post date:** [September 13, 2024, 12:25pm UTC](https://forum.anoma.net/t/juvix-anoma-generate-tx-candidate/763/5 "2024-09-13T12:25:18Z")
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: ```auto compliance1.json: { "input": { "logic": ... }, "output": { "logic": ... } } compliance2.json: { "input": { "logic": ... }, "output": { "logic": ... } } ``` Would the partial transaction then always be: ```auto logic_proofs = [logic1A_proof, logic1B_proof, logic2A_proof, logic2B_proof] compliance_proofs = [compliance1_proof, compliance2_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? ---
**Author:** ![Lukasz](https://avatars.discourse-cdn.com/v4/letter/l/0ea827/32.png) [@Lukasz](https://forum.anoma.net/u/Lukasz)\ **Post date:** [September 14, 2024, 2:09pm UTC](https://forum.anoma.net/t/juvix-anoma-generate-tx-candidate/763/6 "2024-09-14T14:09:04Z")
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? ---
**Author:** ![alberto](https://dub1.discourse-cdn.com/flex013/user_avatar/forum.anoma.net/alberto/32/59_2.png) [@alberto](https://forum.anoma.net/u/alberto)\ **Post date:** [September 14, 2024, 2:36pm UTC](https://forum.anoma.net/t/juvix-anoma-generate-tx-candidate/763/7 "2024-09-14T14:36:45Z")
> [@Lukasz](#): > > 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? The compliance\_input.json “logic” field always corresponds to the hash of the resource proof binary generated in step 2. > [@Lukasz](#): > > 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? 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. > [@Lukasz](#): > > From the Elixir code it seems that `ComplianceInput` always has two shielded resources with resource logics inside: `input` and `output`. Is this correct? Yes > [@Lukasz](#): > > Or can compliance inputs contain other shielded resources? No ---
**Author:** ![Lukasz](https://avatars.discourse-cdn.com/v4/letter/l/0ea827/32.png) [@Lukasz](https://forum.anoma.net/u/Lukasz)\ **Post date:** [September 14, 2024, 2:52pm UTC](https://forum.anoma.net/t/juvix-anoma-generate-tx-candidate/763/8 "2024-09-14T14:52:50Z")
> 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 ---
**Author:** ![Lukasz](https://avatars.discourse-cdn.com/v4/letter/l/0ea827/32.png) [@Lukasz](https://forum.anoma.net/u/Lukasz)\ **Post date:** [September 14, 2024, 2:56pm UTC](https://forum.anoma.net/t/juvix-anoma-generate-tx-candidate/763/9 "2024-09-14T14:56:22Z")
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. ---
**Author:** ![Lukasz](https://avatars.discourse-cdn.com/v4/letter/l/0ea827/32.png) [@Lukasz](https://forum.anoma.net/u/Lukasz)\ **Post date:** [September 17, 2024, 1:46pm UTC](https://forum.anoma.net/t/juvix-anoma-generate-tx-candidate/763/10 "2024-09-17T13:46:27Z")
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. ---
**Author:** ![xuyang](https://avatars.discourse-cdn.com/v4/letter/x/c68b51/32.png) [@xuyang](https://forum.anoma.net/u/xuyang)\ **Post date:** [September 18, 2024, 6:44am UTC](https://forum.anoma.net/t/juvix-anoma-generate-tx-candidate/763/11 "2024-09-18T06:44:15Z")
The API we have can generate the hash of resource logic. You can find it in this example.[aarm-cairo/test/cairo\_logic\_test.exs at base · anoma/aarm-cairo · GitHub](https://github.com/anoma/aarm-cairo/blob/base/test/cairo_logic_test.exs) All the APIs are available in Anoma. Let me know if you have any questions about generating the hash. @Lukasz ---
**Author:** ![xuyang](https://avatars.discourse-cdn.com/v4/letter/x/c68b51/32.png) [@xuyang](https://forum.anoma.net/u/xuyang)\ **Post date:** [September 18, 2024, 6:47am UTC](https://forum.anoma.net/t/juvix-anoma-generate-tx-candidate/763/12 "2024-09-18T06:47:28Z")
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.