![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)
Learn about the revolutionary Everscale blockchain powered by the Threaded Virtual Machine (TVM) and the actor model. See how its asynchronous architecture enables unmatched scalability and solves key issues faced by synchronous blockchains like Ethereum. Explore Everscale’s unique ecosystem development and a wide range of ready-made solutions, making it a powerful contender among blockchains.
In previous articles, we covered some of the key features of the Everscale blockchain. Today, we will be diving a little deeper into Everscale’s blockchain mechanics and how its asynchronous nature has led to its unmatched scalability. By comparing Everscale with the synchronous Ethereum we will highlight the issues that can be solved with asynchronous programming. Additionally, we will also describe the peculiarities of Everscale ecosystem development.
Everscale is an asynchronous blockchain primarily due to its use of:
1. The Threaded Virtual Machine (TVM);
2. An actor model.
Actor model architecture
The parallel computing model, devised by Carl Hewitt in 1973, has been utilized in many parallel computing systems, for example, email. The author of the model was inspired by LISP and the Simula programming language. After the model was introduced, it laid the foundation for designing new languages like the scala programming language and the Erlang programming language.
In the actor model, an actor is the main and only computing unit type that is capable of sending and receiving messages, and changing its state according to the messages received. Actors can also create other actors. In Everscale, every unit of the blockchain is a smart-contract. As actors in the actor model, smart-contracts can interact with each other by sending and receiving internal messages, can interact with off-chain applications by receiving external messages and can deploy new smart-contracts by sending internal messages to other smart-contracts. And of course, the smart contract state can change after a message is received.
The animation below demonstrates some of the scenarios of actor-to-actor interaction in the Everscale blockchain:
- A smart-contract sends an internal message to convey tokens to another smart-contract;
- A smart-contract calls the method of another smart-contract and then receives the results of the executed code;
- A smart-contract deploys a new smart-contract with a particular state.
Threaded Virtual Machine
The Threaded Virtual Machine is responsible for processing the smart-contract code in the Everscale network. This virtual machine is based upon The Open Network Virtual Machine devised by Nikolai Durov.
The animation below shows how the virtual machine treats smart-contracts: as smart-contract 2 receives a message from smart-contract 1, the code is executed and the second smart-contract state is updated.
The Threaded Virtual Machine is the key to Everscale’s asynchronous architecture, which is completely different from that of EVM-based blockchains, in which state is updated synchronously.
In EVM-based blockchains, the state is updated through the execution of a function that is called by a user or a smart-contract. The data required for the calculations is present in the state prior to the function call. That is why the finalization of a single block cannot be shared among several blockchain nodes.
In TVM-based blockchains, state is first updated on the lower level, i.e. every smart-contract has its own state that is changed in the course of contract-to-contract interaction through the sending of messages. The states of all smart-contracts are updated asynchronously. Every time the smart-contract code is executed, a transaction is generated. And the transaction must be validated by one of the blockchain nodes responsible for validating transactions from smart-contracts within its thread.
A thread, to put it simply, is a set of smart-contracts with a group of nodes, dedicated to validating transactions generated by the smart-contracts within the set. If there is a large influx of transactions, each requiring computational resources, the set can be divided into two threads. When the set of smart-contracts is divided into two threads, each thread receives its own group of validating nodes. In addition to that, it is necessary to mention that every action in the Everscale blockchain is a contract-to-contract interaction, and an action that is deemed single and whole for an end-user can consist of dozens of such interactions. As smart-contracts can interact with the contracts from other threads, the load from complex resource-consuming tasks can be divided between several validating nodes, which is the key to the network’s scalability.
The animation below demonstrates how the mechanism of parallel transaction validation is activated: unlike EVM-based blockchains where transactions are batched into a block that is validated by a single node, TVM validators share the workload and broadcast block proofs concurrently.
Blockchain of Blockchains
The threading mechanism described above is now utilized in workchain 0 and masterchain -1. A worckchain is an environment for smart-contract execution and interaction, while the masterchain is used to store the state of the whole blockchain, where up to 232 workchains can exist at once.
Every newly deployed workchain will support asynchronous computation, moreover, all the workchains share the same masterchain, which means that smart-contracts from different workchains are capable of interacting with each other. In addition to that, workchains can be individually tweaked to meet particular requirements.
Stable crypto transaction Fees
According to the EIP-1559, Ethereum gas fees are still subject to fluctuations dependent on the Ethereum block size. But what is a block size? It is the total sum of gas attached to the transactions included in a block. If block size exceeds the target value, the base fee for the next block is increased by 12.5%. The incremental increase of base fees will continue unless the block size value returns to the target value. The described mechanism and the ability of validators to pick transactions with the highest gas attached to them are the reasons why blockchain gas fee spikes occur during high workload periods in the Ethereum network.
And the mechanism of block size deterioration cannot be changed, as it prevents a situation from occuring in which less performant nodes dedicated to the validation process become incapable of validating blocks within 12 seconds.
In Ton Virtual Machine (TVM) based networks, workload can be shared among several validating nodes, which means that the mechanism of controlling demand through fee adjustment is redundant.
The animation below demonstrates how workload can affect fees in EVM and TVM networks:
Modular Fees
The nature of asynchronous blockchains and smart-contracts designed as independent computing units has allowed for the implementation of a complex system of network fees that ensures the fair compensation of validation costs and that users only pay for the actions they have committed on-chain. The fee structure is the following (you can read more in the Everscale docs):
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;
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.
No uncontrolled redundant blockchain data storage
In one of his articles, Vitalik Buterin drew attention to the issue of storing the whole state of the blockchain, which is resource-intensive and makes newer users pay for redundant blockchain data storage. With the introduction of Storage Fees, TVM-based blockchains have solved this issue. With TVM, used smart-contracts no longer have to continue to pay Storage Fees until their balance reaches -0.1 EVER. After the threshold is passed, the contract is frozen and later erased from the network.
Intrinsic Abstract Accounts
As we noted earlier, everything in Everscale is a smart-contract. As a result, the concept of the Externally Owned Account (EOA) cannot exist in the network. Instead, every account in Everscale is an abstract account. Even a wallet is a smart-contract with a balance that is governed by external messages.
Ethereum is working to integrate abstract accounts into its existing protocol, which is more complicated than account abstraction available right out of the box.
Intrinsic account abstraction enables realization of the following features in Everscale:
- Restoration of access to a user’s balance;
- Flexible limiting of outgoing funds;
- Blacklisting addresses;
- The use of one wallet by several parties.
Flexible tuning of the responsibility for network fee payments
To dive deeper into abstract accounts, it is necessary to specify that the backend of any application can be designed to adapt to specific needs and determine the moment when blockchain network fees are to be paid. As any interaction with a blockchain in the TVM-based networks is initiated with an external message that cannot carry any value, the backend of an application can indicate that the blockchain network fees will be paid from a particular address. Thus, you can create an application, in which the initial user interaction does not require paying EVER to start using an application. The fees will be deducted over the course of the execution of the business-logic on-chain. Moreover, developers will not be required to store some EVER on some smart-contract to cover the blockchain network fees, which eases the support of the application and ensures its continuous service.
Reading the whole state locally
The state of the Everscale network becomes available in one HTTP request. To use read-only methods, you can launch a node locally with Evernode Simple Emulator. After the node is launched locally, you can call any smart-contract method that returns data and use it for your local calculations. In EVM-based networks, reading data read-only methods requires making a separate call to the RPC URL endpoint.
Transparent mechanisms for upgrading smart-contract functionality
In EVM-based networks, upgrading smart-contracts requires adhering to the complicated algorithm that includes the use of delegate calls to proxy smart-contracts. Moreover, there are several standards for upgrading smart-contract code: Transparent Proxy, UUPS Proxy, Multi-Facet Proxy (diamond), and OpenZeppelin framework for secure smart-contract development.
Such code-upgrade mechanisms are quite removed from the practices most backend developers are accustomed to, which consist of two simple steps: uploading a new version of the code to the server and re-deploying the application.
TVM-networks offer a more akin way of upgrading smart-contract logic: new code can be sent in an internal message which is then used to upgrade current code by using setcode opcode.
Upgrading a smart-contract can be done with several lines of code:
// If owner knows that RootContract has been upgraded, they can
// request an upgrade for their own contract.
function upgrade(address remainingGasTo) override external onlyOwner {
ITokenRootUpgradeable(root_).requestUpgradeWallet{ value: 0, flag: TokenMsgFlag.REMAINING_GAS, bounce: false }(
version_,
owner_
);
}
// New version of the code is returned
function acceptUpgrade(TvmCell newCode, uint32 newVersion) override external onlyRoot {
if (version_ != newVersion) {
// Encode contract state into TvmCell + new code version
TvmCell state = abi.encode(root_, owner_, balance_, version_, newVersion);
// Set contract to execute new code
// from the next transaction
tvm.setcode(newCode);
// To set new code in the current transaction, call:
tvm.setCurrentCode(newCode);
// Calling onCodeUpgrade with the upgraded code
onCodeUpgrade(state);
}
}
}
// After setCurrentCode is called, only onCodeUpgrade can be
// called in the new contract version.
function onCodeUpgrade(TvmCell data) private {
// Resetting contract storage to zero
// If failed to do so, the storage structure is changed
// This call does not affect auxiliary attributes
// _pubkey, _replayTs, _constructorFlag,
// other attributes from temporary register c7
// are initialized as zeroes.
tvm.resetStorage();
// decoding the state
(address root, address owner, uint128 balance, uint32 fromVersion, uint32 newVersion) =
abi.decode(data, (address, address, uint128, uint32, uint32));
// initializing the state
root_ = root;
owner_ = owner;
balance_ = balance;
version_ = newVersion;
}
Familiar development tools
The TVM ecosystem offers blockchain development tools that are similar to the ones used for development in EVM-based networks:
Locklift — similar to Hardhat:
1) Network management for working with any networks (main, test, local);
2) Automated contract testing with Mocha;
3)Keys management;
4)External script runner that executes scripts within a specified environment.
Everscale Inpage Provider — similar to web3.js:
1) API familiar for EVM frontend developers;
2) Used to develop browser extensions.
Ready-made solutions for blockchain indexing
Unlike Ethereum, where indexing is performed with third-party projects like Infura or The Graph, Everscale offers its own solutions for blockchain indexing.
One way to index and analyze blockchain data is to install a node package with indexer and GraphQL API with public endpoints. This solution is capable of satisfying the needs of both entry-level users and those who need deeper blockchain data scraping.
Another, more flexible, way is to create your own blockchain indexer that will convey the data from the blockchain through Kafka streams to any database of your choice. To do that, you will need a duo from Broxus consisting of Light Node and ton-kafka-producer.
TVM ecosystem
Today, there are more than 40 native Everscale applications built on the model of asynchronous computing and developed with the instruments covered above. Among them, there are a number of solutions that have been operating for more than 3 years that implement the functionality essential for unconstrained use of the blockchain, including:
Octus Bridge — decentralized bridge (git);
Ever Name — Everscale based Web3 domains;
TokStock — NFT marketplace;
Qamon — secure mail service on the Everscale blockchain.
And there are many more! To learn about all the crypto products built on Everscale, be sure to peruse the network’s site.
