Blocks and Operations¶
The content of a Tezos block is made up of operations, which implement and reify different functionalities provided by a Tezos economic protocol: from reaching consensus on the state of the Tezos blockchain, to performing smart contract calls and transactions. Each Tezos economic protocol can specify different kinds of operations.
This entry describes the operations supported by the economic protocol that implement enabled features – that is, those available to end-users on Tezos Mainnet. The complete list of operations, including those corresponding to features in development or available only on test networks, is given in the OCaml Documentation .
The different kinds of operations are grouped into classes. Each class has an associated index, a natural number, also known as a validation pass. There are currently four classes of operations: consensus, voting, anonymous, and manager operations. This order also specifies the validation and application priority of each of these classes. Consensus operations are considered the highest priority ones, and manager operations the lowest.
The current protocol implementation enforces the following invariant:
each kind of operation belongs to at most one validation pass;
operations whose kind does not belong to any validation pass cannot be applied.
In the sequel, we describe the different classes of operations, and the different kinds of operations belonging to each class.
Consensus operations are administrative operations that are necessary to implement the consensus algorithm. There are two kinds of consensus operations, each belonging to the different voting phases required to agree on the next block.
Voting operations are operations related to the on-chain Tezos Amendment process. In this economic protocol, there are two voting operations:
Proposaloperation enables delegates to submit (also known as to “inject”) protocol amendment proposals, or to up-vote previously submitted proposals, during the Proposal period.
Ballotoperation enables delegates to participate in the Exploration and Promotion periods. Delegates use this operation to vote for (
Yea), against (
Nay), or to side with the majority (
Pass), when examining a protocol amendment proposal.
Further details on each operation’s implementation and semantics are provided in the dedicated entry for on-chain governance.
This class groups all operations that do not require a signature from a Tezos account (with an exception, detailed below). They implement different functionalities of the protocol, and their common characteristic is that they allow the account originating these operations to remain anonymous in order to avoid censorship.
Two operations in this class implement functionality pertaining to the protocol’s random seeds generation mechanism:
Seed_nonce_revelationoperation allows a baker to anonymously reveal the nonce seed for the commitment it had included in a previously baked block (in the previous cycle).
Vdf_revelationoperation allows the submission of a solution to, and a proof of correctness of, the VDF challenge corresponding to the VDF revelation period of the randomness generation protocol.
Further details on the latter operation’s implementation and semantics are provided in the random seed generation protocol.
Three operations in this class are used to punish participants which engage in Byzantine behaviour – notably delegates which “double sign” blocks, or emit conflicting consensus operations:
Double_preendorsement_evidenceoperation allows for accusing a delegate of having double-preendorsed – i.e., of having preendorsed two different block candidates, at the same level and at the same round. The bulk of the evidence, the two arguments provided, consists of the two offending preendorsements.
Double_endorsement_evidenceoperation allows for accusing a delegate of having double-endorsed – i.e., of having endorsed two different block candidates at the same level and the same round – by providing the two offending endorsements.
Double_baking_evidenceallows for accusing a delegate of having “double-baked” a block – i.e., of having signed two different blocks at the same level and at same round. The bulk of the evidence consists of the block headers of each of the two offending blocks.
See here for further detail on the semantics of evidence-providing operations.
Activation operation allows users which participated in the
Tezos fundraiser to make their accounts operational.
Drain_delegate operation allows an active
consensus-key account, i.e., an account to which a baker delegated its
consensus-signing responsibility, to empty its delegate
account. This operation is used as a deterrent to ensure that a
delegate secures its consensus key as much as its manager (or main)
Manager operations enable end-users to interact with the Tezos blockchain – e.g., transferring funds or calling smart contracts. A manager operation is issued by a single manager account which signs the operation and pays the fees to the baker for its inclusion in a block. Indeed, manager operations are the only fee-paying and gas-consuming operations.
Revealoperation reveals the public key of the sending manager. Knowing this public key is indeed necessary to check the signature of future operations signed by this manager.
Transactionoperation allows users to either transfer tez between accounts and/or to invoke a smart contract.
Update_consensus_keyoperation allows users to delegate the responsibility of signing blocks and consensus-related operations to another account. Note that consensus keys cannot be BLS public keys.
Originationoperation is used to originate, that is to deploy, smart contracts in the Tezos blockchain.
Set_deposits_limitoperation enables delegates to adjust the amount of stake a delegate has locked in bonds.
Support for registering global constants is implemented with the
Increase_paid_storageoperation allows a sender to increase the paid storage of some previously deployed contract.
Eventoperation enables sending event-like information to external applications from Tezos smart contracts – see Contract Events for further detail.
Moreover, all operations necessary to implement Tezos’ enshrined Layer 2 solutions into the economic protocol are also manager operations.
In particular, smart rollups maintenance is handled with dedicated manager operations.
Smart_rollup_originateoperation is used to originate, that is, to deploy smart rollups in the Tezos blockchain.
Smart_rollup_add_messagesoperation is used to add messages to the inbox shared by all the smart rollups originated in the Tezos blockchain. These messages are interpreted by the smart rollups according to their specific semantics.
Smart_rollup_publishoperation is used to regularly declare what is the new state of a given smart rollup in a so-called “commitment”. To publish commitments, an implicit account has to own at least ꜩ 10,000, which are frozen as long as at least one of their commitments is disputable.
Smart_rollup_cementoperation is used to cement a commitment, if the following requirements are met: it has been published for long enough, and there is no concurrent commitment for the same state update. Once a commitment is cemented, it cannot be disputed anymore.
Smart_rollup_recover_bondoperation is used by an implicit account to unfreeze their ꜩ 10,000. This operation only succeeds if and only if all the commitments published by the implicit account have been cemented.
Smart_rollup_refuteoperation is used to start or pursue a dispute. A dispute is resolved on the Tezos blockchain through a so-called refutation game, where two players seek to prove the correctness of their respective commitment. The game consists in a dissection phase, where the two players narrow down their disagreement to a single execution step, and a resolution, where the players provide a proof sustaining their claims. The looser of a dispute looses their frozen bond: half of it is burned, and the winner receives the other half in compensation.
Smart_rollup_timeoutoperation is used to put an end to a dispute if one of the two players takes too much time to send their next move (with a
Smart_rollup_refuteoperation). It is not necessary to be one of the players to send this operation.
Smart_rollup_execute_outbox_messageoperation is used to enact a transaction from a smart rollup to a smart contract, as authorized by a cemented commitment. The targeted smart contract can determine if it is called by a smart rollup using the
Manager Operation Batches¶
Manager operations can be grouped, forming a so-called batch. Batches enable the inclusion of several manager operations from the same manager in a single block.
Batches satisfy the following properties:
All operations in a batch are issued by the same manager, which provides a single signature for the entire batch.
A batch is applied atomically: all its operations are executed sequentially, without interleaving other operations. Either all the operations in the batch succeed, or none is applied.