Modern blockchains, which predominantly function as networks of distributed computations, typically rely on virtual machines to execute arbitrary code underpinned by a security protocol. The fragments of arbitrary code dispatched to virtual machines for execution are referred to as smart contracts. It can, therefore, be inferred that if a decentralized network is founded upon interactions between smart contracts, it necessitates the use of a virtual machine.
In Everscale, every component is a smart contract, whether it is an address containing coins, a trading pair on a decentralized exchange or a relayer of a decentralized bridge. As a result, these networks are compelled to depend on a virtual machine, specifically the Threaded Virtual Machine (TVM).
Before we delve deeper into the intricacies of TVM, it is pertinent to revisit the evolutionary trajectory of the blockchain industry in its adoption of virtual machines atop security protocols.
The advent of virtual machines: how they became an indispensable part of a blockchain protocol
From 2008 to 2015, the operational logic of cryptocurrency was encapsulated within the source code of the corresponding blockchain. Fundamental tenets, such as the prohibition against transferring a quantity of cryptocurrency exceeding one's holdings, were integral to the protocol layer of the blockchain.
Ethereum pioneered the utilization of smart contracts, which are arbitrary programs executed by a virtual machine in accordance with the rudimentary principles of the protocol. Presently, the Ethereum blockchain facilitates the implementation of diverse business logic programs through the innovative concept of smart contracts.
Owing to the nature of smart contracts as arbitrary programs, the machine responsible for storing and managing the blockchain's data, referred to as nodes in the context of blockchains, must interpret programs written in a high-level programming language that is more comprehensible to humans.
Solidity is the high-level programming language employed for the development of smart contracts on the Ethereum blockchain. During the deployment of a smart contract, it undergoes a compilation process. In its compiled state, the smart contract is translated into a lower-level language to facilitate communication of data with the virtual machine and to delineate the instructions that the virtual machine must execute with respect to the data. These instructions are referred to as opcodes. Subsequent to the deployment of a smart contract to the network, its functions can be invoked by other entities within the blockchain ecosystem, such as web3 applications, end-users and other smart contracts.
In essence, the adoption of virtual machines has facilitated the introduction of an additional layer of abstraction to the business logic of the blockchain, thereby distancing it from the protocol level. Consequently, the capabilities of the blockchain are constrained by the foundational principles of the protocol and the functional capacity of virtual machines, as defined in the list of extant opcodes. Today, thanks to the advent of smart contracts, individuals can leverage a plethora of decentralized solutions directly on the blockchain. These solutions encompass decentralized exchanges and trading platforms, the sharing of computational power or storage space, the aggregation of blockchain information and much more.
What is TVM?
The Threaded Virtual Machine (TVM) is a successor of the Telegram Open Network Virtual Machine, designed in 2017 by Nikolay Durov, which is still used as the virtual machine in the TON (The Open Network) blockchain today. After it was upgraded, TVM received new opcodes that broadened its capabilities, establishing it as a next iteration of the TON Virtual Machine, namely the Threaded Virtual Machine.
TVM was meant to lay the foundation necessary to resolve the problem that had been looming over the blockchain industry, namely the blockchain trilemma. Distributed networks must be decentralized, secure and scalable. The trilemma stipulates that developing one of the attributes mentioned above will lead your network to drift away from reaching the other two.
To overcome the scalability limits, it is necessary to have a mechanism of computation sharding, i.e. allocating more computational resources (adding more nodes) capable of processing transactions and updating the network state independently of each other. Such a mechanism is implemented in the Venom blockchain and the Everscale blockchain both built upon TVM.
How does TVM work?
TVM is what uses the computational resources of a machine that has an Everscale or Venom (two popular TVM-based blockchains) node client installed. It receives serialized blockchain data, adds it to the stack, transforms it according to the instructions obtained from the smart contract code and returns a new state to the smart contract that is to be recorded to the blockchain after validation of the transaction.
The Threaded Virtual Machine works with cells, intrinsic data structures that are sets of 1023 bits of data and up to 4 references to other cells. Every piece of data used in transaction execution is serialized to cells or, to be more precise, to the Tree of Cells structure.
Smart contracts, compatible with the TVM, are written in Threaded Solidity (which uses the .tsol file extension). Such smart contracts can be smaller parts of blockchain actions that are rendered whole by the end-user.
The translation of .tsol code to Tree of Cells is conducted with TL-B (Typed Language — Binary). This is used to describe the scheme of deserialization of objects to cells. The compilation to .boc file (bag of cells) is performed by the Solidity compiler. This .boc containing cells is everything that TVM needs to perform smart code instructions. It is the .boc files that are hosted in the blockchain instead of the .tsol contracts.
Features brought by TVM
The capabilities of the Threaded Virtual Machine allow building distributed networks that own numerous unique features: smart contracts similar to those described in the actor model, asynchronous computing, heterogeneity and modular fee structures.
State
Unlike simpler older blockchains that are actually distributed ledgers with a security protocol built upon them, Everscale and Venom have a state which is updated by every operation of TVM. Validators download the state, perform operations on TVM and then send out updated states to other validators, thus taking part in the consensus algorithm. In other words, TVM is also a state machine, apart from it being a stack machine and partially a register machine.
You can see how TVM treats smart contracts: when a smart contract gets a message from another contract, it executes a code and updates the state of the second smart contract:
Smart contracts are the only network actors
As we mentioned earlier, everything in Everscale and Venom is a smart contract. Smart contracts are independent of each other and they can receive and send messages. Message reception may call the smart contract code. Execution of smart contract code generates a transaction, which is a hash representation of the changes made to the persisting state.
Account abstraction
As smart contract code may contain any instruction that can be invoked by a message sent by another contract, smart contracts themselves are very flexible. This opens a way to implement any logic in, say, a smart contract that must perform the function of a wallet. In Everscale and Venom, wallets are nothing more than smart contracts with balances and functions that allow their owners to manage this balance. Modifying these functions to your specific needs and allowing these functions to be called by other smart contracts actually brings you to account abstraction. What is more, Everscale and Venom networks contain no Externally Owned Accounts at all. This is why TVM-compatible networks have built-in abstract accounts that can be programmed in any way.
Asynchrony
Recall that smart contracts do not depend on each other; TVM is a state machine, and smart contracts do nothing more than just execute the code inscribed inside as they receive a message. All this means that TVM-compatible networks have an architecture very akin to a microservice one. In a well built microservice environment, microservices do not block each others’ operations. Smart contracts behave in the same manner in TVM-compatible networks.
Initially, smart contracts are allocated to one group, called a “processing thread”. All of the transactions generated by the execution of the code from these contracts are actually the computations done on the machines (validator nodes) of one group. This group is designated to validate transactions from this particular thread.
As the workload grows, these processing threads start splitting and every new thread receives a whole new group of validators. In other words, Everscale and Venom networks dispatch more machines to handle higher workloads.
Smart contracts from different threads can still exchange messages with each other, thus calling functions. All of the dispatched groups of validators do not need to wait until the others finish validating this or that transaction. This means that the computing is sharded to several groups of machines, which in turn is a true computational parallelism, or asynchrony.
Heterogeneity
TVM knows not only about what a message or a processing thread is, but also facilitates building systems of heterogeneous blockchains orchestrated by a single masterchain.
The masterchain stores the configuration of the whole network, as well as the hashed headers of the state of every workchain (we also call the latter shardchains or processing chains). The masterchain can handle up to 232 workchains. Some smart contracts deployed to the masterchain cannot be accessed by smart contracts from workchains. Smart contracts constituents of decentralized applications are not normally deployed into the masterchain, as it requires much more gas to perform a transaction
Workchains are environments for hosting smart contracts. It is workchain validators that are divided into validating groups and designated to different processing threads. The total number of threads can climb up to 256 units, and in theory can reach 65536. Workchains are flexibly configurable. One can even build a workchain upon not a TVM but any other virtual machine.
Workchains do not fully share the state. Nevertheless, smart contracts from different workchains can still exchange messages with each other.
Modular fee structure
The complexity of TVM-compatible networks dictates the implementation of a sophisticated system of network fees that ensures the fair compensation of validation costs. The other side of the coin is that the asynchrony and heterogeneity realized with the help of TVM eliminate the necessity of regulating the demand on computation resources (validator services) by screwing up the network fees. The fee structure in Everscale and Venom is the following:
- Forwarding fee: every message (internal/external, inbounding/outbounding) is subject to this fee. It is calculated according to message size and, depending on the message type, it can be further divided and transferred to the validators as compensation for their work or it can be used as a constituent in total action fee calculations;
- Storage fee: every second of storing each bit of data in a smart-contract is subject to this fee. This fee allows preserving the state compact, by wiping smart contracts that have less than -0.1 EVER on their balance. Pruned contracts can still be restored by re-deployment;
- A compute fee is taken if smart-contract execution commits the work of TVM;
- Total action fee: this fee is calculated for every message sent as a result of smart-contract execution. This is equal to zero if no outbounding message is sent.
How is TVM different from other blockchain virtual machines?
Let us discuss why anyone would need a new virtual machine and whether it can have advantages over the first introduced — Ethereum Virtual Machine (EVM). Indeed, EVM made Ethereum the first distributed network running on smart contracts. It was a major breakthrough back in 2015, but as years passed, more and more obstacles arose that impeded Ethereum’s functionality.
One major vulnerability of the Ethereum Virtual Machine is that it cannot operate data in a concurrent manner. Every transaction is executed on the already existing data and the awaited result is well-known. For transactions compliant with the protocol rules, there is no possibility that they can unexpectedly fail due to a lack of a necessary piece of data. On paper, this is a solid approach to data orchestration, but it leads to scalability problems.
Every transaction in Ethereum is put into the mempool. Block validators pick the transactions with the highest gas value applied. If you want your transaction to be 100% included in the upcoming block, you need to pay a bit more than all other users. This competition has no limits, consequently, the higher the demand, the higher the fees. This situation is not only obviously unfair, but also leads to poor user experience with decentralized applications deployed in the Ethereum network.
Venom and Everscale networks that use TVM, and consequently, utilize such features like asynchrony and heterogeneity, are able to move away from the competitive model. It does not really matter if the workload is low or high, the architecture of TVM-compatible blockchains allows appending the list of running validators to the extent that will be sufficient even for a situation when billions of users utilize thousands of decentralized services.
What blockchains are TVM-compatible?
Built upon Threaded Virtual Machine, Everscale and Venom blockchains leverage all the features made possible by the utilization of TVM. The built-in functionalities and unique attributes of these networks include:
- Heterogeneity. One network can consist of 232 separately configured workchains with direct workchain-to-workchain interoperability;
- Asynchrony. Every workchain can implement the dynamic sharding mechanism. Smart contracts are allocated to processing threads that have their own validator sets. Validation of transactions from one thread does not block validation processes in other threads. Each thread produces a separate workchain block;
- Native account abstraction. Smart contracts are arbitrarily programmable and can implement any logic;
- Fees. No competition among actors for pushing transactions into new blocks. Transactions are generated according to message queues with strict sorting rules.
- Finite state. The storage fee ensures that the network state does not grow indefinitely as smart contracts that are no longer in use get frozen and deleted;
Using TVM in scalable decentralized applications
In TVM-compatible networks, concepts of fungible (TIP-3) and non-fungible (TIP-4) tokens were implemented according to the concept of distributed programming and asynchrony. These implementations allowed creating numerous decentralized finance applications on the Everscale and Venom networks:
- Octus Bridge: decentralized crypto bridge;
- FlatQube: DAO-governed decentralized exchange;
- Gravix: decentralized perpetual platform;
- TokStock: NFT marketplace.
Apart from decentralized finance, other web3 applications have been introduced. All of them leverage unique features brought by TVM:
- Ever Name: Everscale-based web3 domain name system;
- AML Crypto: AI-powered solution for tracking asset sources;
- Ever Surf: all-in-one wallet for interacting with Everscale and its users;
- Ever Wallet: browser extension serving as a wallet and a doorway to Everscale web3 applications;
- Qamon: first blockchain-based mail service.
Developer tools
TVM-compatible networks may have stricter requirements for blockchain developers, as asynchronous blockchain development is not an easy task. Nevertheless, there are tools that make the development process more pleasant and less complex.
- Locklift: framework for developing, testing, debugging and deploying smart contracts. Emulates an empty state in RAM eliminating the need for running a local node;
- Nodekeeper: CLI tool for running and managing a node;
- Everscale Inpage Provider: powerful library for frontend development;
- Nekoton: SDK for mobile development of web3 applications;
- Everscale Web Tools: web proxy for smart contract testing;
- Highlighting of code written in Threaded Solidity: extension for VS Code and IntelliJ plugin.
![Threaded Virtual Machine (TVM) as the basis of an asynchronous blockchain [Deep Tech]](https://everscale.fra1.digitaloceanspaces.com/prod/blog/articles/header/258/a42bc7d1-f1d9-449d-a107-6f0327103613.jpg)
