TQ Tezos
Published in

TQ Tezos

The Lifecycle of an Operation in Tezos

The lifecycle of an operation in tezos

Types of operations in protocol Alpha

  1. Endorsement: The “endorsement” operation specifies the head of the chain as seen by the endorser of a given slot. The endorser is randomly selected to be included in the block that extends the head of the chain as specified in this operation. A block with more endorsements improves the weight of the chain and increases the likelihood of that chain being the canonical one.
Endorsement operation
Seed Nonce Revelation
Double endorsement evidence
Double baking evidence
Activation
Proposal
Ballot
  • Reveal: This operation is used to reveal the public key associated with a tz1 address (implicit account/public key hash).
manager: reveal
  • Transaction: This is a standard operation used to transfer XTZ (“tez”) to an account (implicit or originated). If the receiver is an originated account (KT1…), then optional parameters may be passed. When an originated account contains parameters/code, it is referred to as a “contract”. A transaction must be signed by the private key associated with the manager account (a tz1 account) of the source account if it is an originated account.
manager: transaction
  • Origination: This operation is used to create originated accounts. Originated accounts have addresses starting with “KT1”, unlike implicit accounts with addresses that start with “tz1”. Originated accounts are used for two reasons: delegation and smart contracts (when an originated account has associated Michelson code to be executed when called). Funds in an originated account can be delegated to a delegate (implicit account registered as a delegate).
manager: origination
  • Delegation: This is used to delegate funds to a delegate (an implicit account registered as a delegate). The source address for delegating XTZ to a delegate must be an originated account (KT1 address).
manager: delegation

Operation Lifecycle

The lifecycle of an operation in tezos

Before Mempool

Inside Mempool

  1. Known_valid: This is a list of operations that are valid to apply to the current context (state) and may be included in a block if requested by a baker. The resulting context after applying these operations on the current context is called the “Pending context”.
  2. Pending: A bounded set of operations which are known to not be invalid for sure and are eligible to be broadcasted to peers. This set contains two kinds of operations:
    i) branch_refused: an operation which could be valid in a different branch
    ii) branch_delayed: an operation which has come too soon (i.e. there’s a gap in the account counter)

Prevalidator and Pending context

Pre_filter

Apply

Post_filter

From Blocks to Blockchain

References

--

--

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store
Amit Panghal

Works @Kaleido | Worked @TQ| NYU Courant and IITB Alumnus | Writes about cryptocurrencies, blockchain and security