8

I'm trying to understand the different steps involved in the creation of a transaction operation.

Tezos-client -l shows a number of RPC calls, among them:

chains/main/blocks/head/helpers/scripts/run_operation
chains/main/blocks/head/helpers/preapply/operations
injection/operation?chain=main

What do run_operation and preapply do, and why are they both needed?

Besides, the operation to be injected is binary-encoded, what encoding is used? (one can get the encoding using the /chains/main/blocks/head/helpers/forge/operations, but I'd like encode the operation myself).

7

There are multiple references online which provide material to understand the steps involved in this. You can check this or that. Some elements are also provided in this other question

Basically the steps are

  1. get dependencies
    • branch hash: /chains/main/blocks/head/hash
    • counter: /chains/main/blocks/head/context/contracts/<source_pkh>/counter
    • protocol hash: /protocols
  2. forge operation (/chains/main/blocks/head/helpers/forge/operations) Note sure if it's easy to replicate this logic outside from the native client though
  3. sign bytes (tezos-client sign bytes)
  4. preapply operation (/chains/main/blocks/head/helpers/preapply/operations/)
  5. decode signature to hexadecimal format
  6. inject operation (/inject/operation)
4

helpers/scripts/run_operation is useful to simulate an operation without signing it (you may use zero bytes for the signature), in order to estimate the gas and storage requirements. You will see tezos-client -l setting gas_limit and storage_limit to the maximum values here, and then using the result to set the actual gas_limit and storage_limit (subject to the user's maximum acceptable storage_limit, called "--burn-cap").

To learn how the operation is encoded in binary, you can see tezos-client describe unsigned operation.

  • I noticed my answer does not explain why preapply is needed. Why not just run_operation? – Tom Mar 2 at 19:31
3

Easiest would be checking out how e.g. eztz implements transfers.

Then see how the transfer operations is forged here.

And finally how the forged operation is injected here.

By the looks of it, seems like eztz's forge is done remotely by /helpers/forge/operations.

  • 1
    Actually eztz forges locally, but for the time being we use the remote forge as a way to double check that what we forged locally matches. In future, we will remove the remote forge check :-) – Stephen Andrews Feb 8 at 2:01

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.