Skip to content
On this page

Concept of Transaction Finalization

In the world of blockchain technology, the concept of transaction finalization is pivotal. It refers to the process of confirming and validating transactions within the network, ensuring their immutability and integration into the blockchain. This document aims to delve deeper into the specifics of transaction finalization in the context of TVM-compatible blockchains, which operate based on a pure actor model.

Actor Model & Async Transactions

TVM-compatible blockchains operate based on the pure actor model, an asynchronous and concurrent computational model. Within this system, each contract functions as an independent actor, processing its individual messages. The execution of a smart contract or a transaction within a single contract is a synchronous atomic operation. However, when an operation involves multiple contracts, interactions between them can occur asynchronously.

Image not available

For instance, let's imagine Contract A calling Contract B. In many other blockchain models, if Contract B runs out of gas during execution, the entire transaction would be rolled back, including the state changes in Contract A that occurred prior to the call. However, in the actor model of TVM blockchains, if Contract B encounters an error, the changes Contract A made before calling Contract B would persist. The execution failure of Contract B only rolls back changes related to Contract B's execution. This characteristic ensures a higher degree of reliability and security in transaction processing.

Transaction Flows

Transactions in these blockchains are part of a continuous, asynchronous process where numerous actors interact, process messages, and modify states. Each smart contract (actor) follows a specific behavior pattern, responding to events, executing its code, modifying its own properties, optionally generating outgoing messages, and then going into standby mode until the next event occurs. These sequences form an AccountChain, a chain of transactions for a single account, which is then included in a block without disrupting the sequencing.

When considering multiple accounts, we have multiple AccountChains forming a ShardChain, which can be dynamically split and merged depending on the transaction load. Ultimately, all shards that contain all accounts following a set of rules form a Blockchain, where multiple blockchains can operate simultaneously and interact with each other.

Logical Time in Transactions

Every transaction within the TVM-compatible blockchain is assigned a logical time interval. This logical time serves as a unique identifier for transactions and outbound messages of an account. The logical time intervals of transactions of the same account do not intersect each other, thus ensuring that all outbound messages generated by an account are unique and identifiable.

Components of a Transaction

Each transaction within the TVM-compatible blockchain contains or indirectly refers to the following data:

  • The account to which the transaction belongs.
  • The logical time of the transaction.
  • An inbound message processed by the transaction. Each transaction is always initiated by this message.
  • The number of generated outbound messages.
  • The outbound messages themselves.
  • The initial and final state of the account, including its balance.
  • The total fees collected by the validators.
  • A detailed description of the transaction containing all or some data needed to validate it.

Types of Transactions

There are different types of transactions allowed in the blockchain, each serving a unique purpose:

  • Ordinary transactions: These belong to an account and process exactly one inbound message, compute the new state of the account, and generate several outbound messages.
  • Storage transactions: These transactions do not process any inbound message and do not invoke any code. Their only effect is to collect storage payments from an account, affecting its storage statistics and its balance.
  • Tick and Tock transactions: These are automatically invoked for certain special accounts in the masterchain that have the tick flag set in their state, as the very first transactions in every masterchain block or the very last transactions in every masterchain block.
  • Split and Merge transactions: These are invoked as the last transactions of shardchain blocks immediately preceding a shardchain split event or immediately after a shardchain merge event, if an instance of a large smart contract needs to be merged with another instance of the same smart contract.

Transaction Phases

In the TVM blockchain, transactions are processed through several distinct phases. Each phase plays a critical role in executing and validating transactions. Understanding these phases can provide a more comprehensive view of how transactions function in the blockchain.

Image not available

Storage Phase

The Storage Phase is the initial stage of every transaction. During this phase, the blockchain calculates storage fees accrued by the smart contract due to the occupation of some space in the chain state. This storage fee is calculated based on the amount of storage used by the smart contract, represented in bytes and the duration, in seconds, for which the storage has been used.

The formula for calculating the storage fee is

(cells_count * cell_price + bits_count * bit_price) / 2^16 * time_delta.

If the smart contract did not exist before, the storage phase is absent.

Credit Phase

Following the Storage Phase is the Credit Phase. During this phase, the account balance is calculated with respect to a possible incoming message value and the collected storage fee.

Compute Phase

The Compute Phase is where the TVM executes the smart contract code invoked by a message. In this phase, all computations and state updates of the contract that do not interact with other contracts occur. The Compute Phase is deterministic, and its outcome is solely dependent on the input data and the current state of the smart contract. This phase executes in an isolated environment to ensure the integrity and security of the computations. If an exception occurs during the Compute Phase, such as an out-of-gas error, the entire transaction is aborted, and the subsequent phases do not commence. At the end of this phase, the TVM prepares a set of "output actions" for dispatch during the Action Phase.

Action Phase

The Action Phase is where the output messages created during the Compute Phase are dispatched. Actions that may occur during this phase include calling other smart contracts and any other actions specified in the output messages.

These calls can lead to various outcomes such as token transfers and state changes of the receiving contract. The Action Phase enables the smart contract's interaction with other contracts within the blockchain network. However, the actual state changes only occur if the Action Phase is successfully completed.

Caution

Please note that there's a maximum limit of 255 actions that can be dispatched during the Action Phase. This limit includes internal outbound messages, event messages, rawReserve, setCode. Exceeding this limit will cause the transaction to be aborted.

Bounce Phase

The Bounce Phase occurs if the transaction is aborted, for instance, due to a failure in the Compute or Action phases, and the inbound message has its bounce flag set. In this phase, the inbound message is "bounced" by automatically generating an outbound message to its original sender. Almost all value of the original inbound message is transferred to the generated message, which otherwise has an empty body.

Each of these phases plays a crucial role in ensuring the security, reliability, and efficiency of transactions within the TVM-compatible blockchain. Gaining a thorough understanding of these phases can provide a more complete picture of transaction processing in the blockchain.