Beginner

 

Operations on Tezos

Welcome to our tutorial on operations on the Tezos blockchain network. In this tutorial, we will explore the various tasks that can be performed on the Tezos network, including creating and managing accounts, transferring tokens, and creating and interacting with smart contracts. We will also cover the basics of the Tezos consensus mechanism, its unique on-chain governance model, and the features that make it different from other blockchain networks. Additionally, we will look at best practices for using the network and the process of creating and deploying smart contracts on Tezos. Whether you are a developer, researcher, or simply a blockchain enthusiast, this tutorial will provide valuable insights and hands-on experience in working with the Tezos blockchain network.

Implicit accounts and originated accounts

Let’s start by talking about the two types of addresses in Tezos [1]:

  • An implicit account is linked to a manager which owns the public key. The hash of the public key outputs an address. Depending on the chosen Digital Signature Algorithm’s elliptic curve (see ECDSA), the latter starts with “tz1” (Ed25519 curve), “tz2” (Secp256k1 curve), or “tz3” (P256 curve)
    A transfer operation to the account’s address creates the account itself.
    Only implicit accounts can be registered as delegates and participate in the baking process.

  • Smart contracts are also called “originated accounts” and are created with an origination operation
    They run their Michelson code each time they receive a transaction.

Tezos operations

An operation is usually a message sent from one address to another.

Message representation:

type operation = {
  amount: amount; // amount being sent
  parameters: data list; // parameters passed to the script
  counter: int; // invoice id to avoid replay attacks
  destination: contract hash;
}

Example of an entry point call:

{
    "branch": "BMXRpSqjJ9HnEeaSXj3YzM9jqB4kqDZemtJBGGqn5Sa9MepV1k7",
    "contents": [
        {
            "kind": "transaction",
            "source": "tz1YWK1gDPQx9N1Jh4JnmVre7xN6xhGGM4uC",
            "fee": "6678",
            "counter": "942780",
            "gas_limit": "63669",
            "storage_limit": "75",
            "amount": "0",
            "destination": "KT1S5hgipNSTFehZo7v81gq6fcLChbRwptqy",
            "parameters": {
                "entrypoint": "sellLand",
                "value": {
                    "prim": "Pair",
                    "args": [
                        {"int": "100000000"},
                        {"int": "11"}
                    ]
                }
            }
        }
    ]
}

Example of a transaction between two implicit accounts:

{
    "branch": "BKkwBsr6hfvj2MfaEydByALrASfCPzFBFSCs3iY7XaBLKRtwWj7",
    "contents": [
        {
            "kind": "transaction",
            "source": "tz1VAugX5LBcF4Anq1gEFr12LmsjqsCgsnPs",
            "fee": "444",
            "counter": "855452",
            "gas_limit": "1527",
            "storage_limit": "0",
            "amount": "100000000",
            "destination": "tz1YWK1gDPQx9N1Jh4JnmVre7xN6xhGGM4uC"
        }
    ]
}

Such an operation can be sent from an implicit account (if signed using the manager’s private key) or programmatically by contract code execution. When the operation is received, and if the destination’s contract code execution is valid, the amount is added to the destination’s contract balance. This code can make use of the arguments passed on to it. It can read and write the contract’s storage or post operations to other contracts.

As the example shows, there is also a counter field, whose purpose is to prevent replay attacks. An operation is only valid if the contract’s counter is equal to the operation’s counter. Once an operation is applied, the counter increases by one, preventing the operation from being reused.

The operation also includes the block hash (“branch” field) of a recent block that the client considers valid. If an attacker ever succeeds in forcing a long reorganization with a fork, he will be unable to include this operation, thereby making the attack detectable.

This last line of defense is named “TAPOS“: a statistical detection of a Long Range Attack based on the fraction of moving coins. This kind of system prevents long reorganizations but is inefficient with short-term double-spending.

Currently, the Tezos network in Lima can process around 170 TPS (transactions per second) and has a deterministic time finality of one minute (2 blocks). This speed may vary with future protocols. Finality is the time it takes for a block to be considered secure. As a comparison, Bitcoin can process 7 TPS and has a probabilistic time finality of 60 minutes (6 valid blocks).

Operation Flow

The diagram below represents the life cycle of an operation:

tezos-operation-flow

Nodes receive operations from clients via RPC or from a peer in the network. Note that this is how a typical Tezos node works on protocol “Alpha

By this, you complete this workshop successfully!!