Prechecking of manager operations¶
The prevalidator of Octez prevents the propagation of non-valid operations by trying to apply them. However, executing manager operations can be time-consuming. To ensure a high throughput of the Tezos protocol, the propagation of operations should be as fast as possible. This calls for a lighter approach.
Prechecking manager operations implements such a lighter approach, by discarding most invalid operations, without executing any of them. This is possible because the validity of a manager operation depends on its solvability – defined further below.
Fortunately, it turns out that deciding whether an operation is solvable can be achieved without applying it.
However, restricting the propagation to solvable operations is not enough to
ensure resilience against DDoS attacks.
It does not ensure their validity in a direct successor of the current
For instance, given two manager operations from the same source and
with the same counter, these operations can be solvable in the same
C, but none of them is solvable in the context
resulting from the application of the other operation on
To mitigate this situation, we further restrict the propagation of
manager operations to at most one manager operation per manager per
Note however that one can still inject successive operations with the
same counter using the
The solvability of a manager operation depends on the content of the Tezos context in which it is applied.
In the following, we consider the context kept by the prevalidator (see The Prevalidator). Checking operation solvability with this context is lighter than with the contexts for block validation or block construction: it can be decided without checking whether the gas announced by the operation is below the remaining gas for the whole block – . Checking solvability consists in verifying that the operation is well-formed and that fees can be paid: no execution of operations (especially of smart-contract code) is done to determine whether they would be applied in the next block with a success or a fail status (as done by operation application).
Roughly, a manager operation is solvable when the following conditions hold:
The manager can afford to pay the operation fees in the current prevalidator context;
the operation’s counter is the successor of the operation counter associated to the manager in the current context;
the gas limit announced is below the gas limit per operation as defined by the economic protocol;
for manager operations with Michelson parameters, the gas cost of deserialisation is under the gas limit announced by the operation; and
the signature of the operation is valid.
Two manager operations are compatible if they correspond to distinct managers.
Two manager operations are co-precheckable in a context if they are compatible and solvable in this context.
Considering two co-precheckable operations in a context, the application of one of them preserves the solvability of the other.
This property extends to a set of manager operations if every pair of distinct operations is co-precheckable. In this case, the operations could be included in the next block in any order, modulo block limits (eg. maximum gas, block size limit, etc).
The precheck of a manager operation, with respect to a context and a set of co-precheckable operations, consists in checking whether adding the operation to the set preserves the operations of the set being co-precheckable.
The prevalidator (see The Prevalidator) aims at propagating operations that could be included in a direct successor block of the current head. It will propagate co-precheckable operations after checking their solvability.
In conclusion, manager operation precheck is a simplification over the real application of operations: the prevalidator checks whether each manager operation would be valid in a direct successor of the current head, as long as gas is available in that block. In other terms, during prechecking of manager operations, they have no effect on the prevalidator context.