Overview

Operations change the context of the blockchain. This transformation of the state happens at certain intervals, whenever a new block is created. The block holds all operations that are applied at that batch operation.

Types of operations

This is a list of different types of operations1 (how it affects balance2):

  • Baking type
    • Accusations (reward)
    • Endorsements (reward)
  • Voting type
    • Ballot (does not affect)
    • Proposal (does not affect)
  • Anonymous type
    • Activate account (burn)
    • Double baking evidence (reward - loss)
    • Double endorsement evidence (reward - loss)
    • Seed nonce revelation (reward)
  • Manager type
    • Revelation (fee)
    • Delegations (fee)
    • Transactions to transfer tez funds (transfer - fee)
    • Transactions to invoke/interact with smart contracts (transfer - fee)
    • Originations of smart contracts
Good to know

Operations are uniquely identifiable by their hash. In Tezos all operation hashes start with o as defined in the source code.

Operation lifecycle

Below is a simplified transaction diagram of the lifecycle of operations. A node receives new operations in two ways: a user announces the new operation through the RPC or the node receives it from another peer through advertisement. After that the operations are passed to a part of the validation system - the "pre-validator". It decides which operations are allowed to enter the mempool. Reasons for rejection could be that the operation does not have enough gas,the balance (XTZ) is too low, the voting period for the ballot is not correct, to name a few. Valid operations are then added to the mempool. It is important to know that even when receiving operations from other peers, the validation steps are nevertheless applied before proceeding to the mempool.

When the time comes that the baker receives endorsements to bake (produce) a new block, the baker queries for all valid operations from the mempool. A new block gets backed by injecting it in the node. After receiving the block, the protocol checks in another part of the validation system for correctness. We will not get too much into detail of the block and chain validator, but it checks for errors3 such as: too many operations in a block, wrong protocol, expired chain (fork), to name just a few. After successfully passing those, a new block is created and the (block-)chain length increases by one block. Operations that had been baked are flushed from the mempool. The new block is advertised to other peer nodes.

sequenceDiagram autonumber Alice ->> Peer Node: announce operation through RPC Remote Peer ->> Peer Node: announce operation through advertisment Note over Peer Node: Pre-validate Peer Node->Peer Node: add to Mempool Note over Baker: time to bake (produce) a new block Baker -> Peer Node: query all valid operations Peer Node -> Baker: return operations from mempool Note over Baker: bake new block Baker -> Peer Node: inject Note over Peer Node: block-, chain-validator Note over Peer Node: new block created Peer Node -> Peer Node: flush mempool Peer Node -> Remote Peer: advertise new block

In the following overview the block does not get injected by a baker, but is exchanged among nodes. The main difference is that usually when a baker injects the block, all the information is present in the node and respectively in the mempool. In this case however, all the data is shipped to the node. You encounter this frequently when starting a node from scratch (bootstrapping). Another sub-validator called peer validator takes care of fetching the block from the distributed database shared among the p2p nodes.

sequenceDiagram autonumber Remote Peer -> Peer Node: advertise new block Note over Peer Node: peer-, block-, chain-validator Note over Peer Node: new head (leading block) Peer Node -> Peer Node: flush mempool
  1. Source code lib_protocol↩
  2. Online discussion about rewards for operations.↩
  3. Source code lib_shell for block validator errors.↩
Edit this page