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 (
Yay), 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.
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:
Transaction Optimistic Rollups are implemented using the following manager operations:
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.