package tezos-protocol-016-PtMumbai

  1. Overview
  2. Docs
package tezos-protocol-016-PtMumbai
Legend:
Library
Module
Module type
Parameter
Class
Class type

apply_batch ctxt parameters batch interprets the batch Tx_rollup_l2_batch.V1.t.

By construction, a failing transaction will not affect the ctxt and other transactions will still be interpreted. That is, this function can only fail because of internals errors. Otherwise, the errors that caused the transactions to fail can be observed in the result (see Message_result.Batch_V1.t).

The counters are incremented when the operation is part of a transaction that is correctly signed and whose every operations have the expected counter. In particular, the result of the application is not important (i.e. the counters are updated even if the transaction failed).

In addition, the list of withdrawals resulting from each layer2-to-layer1 transfer message in the batch is returned.

check_signature ctxt batch asserts that batch is correctly signed.

We recall that batch may contain indexes, that is integers which replace larger values. The signer field of the Tx_rollup_l2_batch.operation type is concerned. This field is either the public key to be used to check the signature, or an index. In case of the public key, check_signature will check whether or not the related Tx_rollup_l2_address.t has already an index assigned, and allocate one if not.

Overall, check_signature returns the revised context, the list of newly allocated indexes, and an updated version of the batches where all signer field have been replaced by valid indexes.

Note: What a user is expected to sign is the version of the operation it sends to the network. This is potentially unsafe, because it means the user signs indexes, not addresses nor ticket hashes. This poses two threats: Tezos reorganization, and malicious provider of indexes. A Tezos reorganization may imply that an index allocated to one address in a given branch is allocated to another address in another branch. We deal with this issue by making the rollup node aware of the Tezos level at each time an index is allocated. This allows to implement a RPC that can safely tell a client to use either the full value or the index, thanks to Tenderbake finality. To prevent the rollup node to lie, we will make the rollup node provide Merkle proofs that allows the client to verify that the index is correct.

OCaml

Innovation. Community. Security.

GitHub Discord Twitter Peertube RSS
About
Changelog Releases Industrial Users Academic Users Why OCaml
Ecosystem
Packages Community Events OCaml Planet Jobs
Resources
Install OCaml Get Started Platform Tools Language Manual Standard Library API Books Exercises Papers OCaml Playground Logo
Policies
Carbon Footprint Governance Privacy Code of Conduct