Module Evm_node_lib_dev.Tezlink_prevalidation

This module provides functions pertaining to the validation of Tezlink operations. Validity is checked in several steps: before adding the operation in the tx_queue, and then before adding the operation to a blueprint.

To be added to the tx_queue, an operation must be valid on its own (independently of other operations), but it can be valid "in the future". We check that each field of the operation is valid, in particular:

In addition, for a batch:

To be added to a blueprint, an operation must be valid when taking into account the operations already included in the blueprint:

Contrary to L1 *we don't enforce the 1M constrait* (applying any subset of validated operations should always succeed, even if they are not applied in the same order as they were validated). The L2 uses a queue and a single sequencer, instead of having a mempool in which bakers can choose operations to add. We follow instead the approach taken by Etherlink: the queue orders operations. In particular, for a given source the operations are ordered using the counter. When creating a blueprint the operation are poped in order, and are dropped if they are not valid for the blueprint.

The errors sent by the functions in this module are taken from the protocol as much as possible. This helps with consistency with external tooling, e.g. octez-client.

val parse_and_validate_for_queue : ?check_signature:bool -> read:(string -> bytes option Tezos_base.TzPervasives.tzresult Lwt.t) -> string -> (Evm_node_lib_dev_tezlink.Tezos_types.Operation.t, string) Stdlib.result Tezos_base.TzPervasives.tzresult Lwt.t

parse_and_validate_for_queue read raw_op parses raw_op into an operation, and checks that the operation is valid on its own. read is used to check information about the source in the current context (counter, balance, public key). This first validation pass should be done at insertion in the tx_queue.

At this point operations are valid if they could be inserted into a future blueprint, i.e. it is either valid or could be valid in the future. For example, the counter provided in the operation is either the next counter (it is valid as the next operation from the source) or a counter further away in the future. However the source must be able to pay the fees in the current context.

Another pass of validation will be done at insertion into a blueprint (see in this module validate_for_blueprint).

The optionnal check_signature is used to bypass signature verifications during simulation.

The value returned, of type Tezos_types.Operation.t, contains more information than just the parsed operation, used by the node notably at insertion into a blueprint to validate the transaction in the context of the blueprint. In particular, the total fee, the length of the operation (one, unless it's a batch) etc. Therefore, any Tezos_types.Operation.t value should be created and validated at the same time.

gas_limit_could_fit state operation returns true if the operationb, fits into the blueprint being created. Can lead to a new blueprint.

val init_blueprint_validation : (string -> bytes option Tezos_base.TzPervasives.tzresult Lwt.t) -> unit -> Validation_types.validation_state

init_blueprint_validation read () creates a empty validation state, from the context the read returns info about.

validate_for_blueprint state operation finishes the validation of operation and checks that it can it be added to the blueprint. Returns either the update validation state, or an error if the operation is now invalid.

Supposes that the operation was first pre-validated at insertion into the tx_queue.

Returns validation errors as string, following Etherlink convention, to make it easier to insert that part of the validation in the current control flow.