Actor model in Everscale

Actor model in Everscale

First, what is the actor model?

The actor model is a computing model with the actor as a central entity in concurrent computation. Initially, the model was designed for cluster computing with many of the same basic computing objectives as the cloud. As of today, multi-cloud application developers utilize it as a microservice model to meet the needs of modern, distributed systems. It's worth mentioning that although the actor model made its appearance before cloud computing, back then, it already met all the necessary requirements for multi-cloud applications, such as, scaling, concurrency, and failover.

But what exactly are actors?

In a nutshell, they are small, executable code units that receive messages and then, depending on the message’s logic, respond to them by making local decisions, sending messages to other actors, creating more actors, or determining what to do with the next message. 

Two of the key characteristics of actors are their simplicity and intuitiveness. Add to that the fact that they can be easily assembled together, and you have ideal building blocks for easily creating high-load multi-cloud applications. 

Moreover, actors are thread-safe – so an operation can safely be performed from multiple threads; and reentrant – so operations can be performed even if they are already in progress (e.g. in another instance). This removes the need for locks, and, as a result, the possibility of any deadlocks. Thanks to communication through message-passing, concurrency applications are thus easily managed. Through actors, failover execution and scalability become possible, and both pseudo-synchronous (request-response) and asynchronous (event) messaging are supported.

When we speak about the actor model, we’re not considering the frontend of apps; rather, we’re essentially talking about microservices that handle an application’s different parts under the hood.

Meanwhile, the frontend concerns UI/UX tech which we see used in smartphone, desktop, and browser apps. As only one user at a time engages with them, scalability is not an issue for these apps themselves, but when it comes to the servers they connect to, low scalability and reliability can create serious limitations. This is where the actor model comes in.


Concurrency should not be considered the same as parallelism. Concurrency is about dealing with lots of things at once, while parallelism is about actual performing lots of things at once.Let’s see the differences:An application is considered concurrent when it processes more than one request at the same time, but no two requests are processed at the same time.

An application is considered parallel when it processes a large number of sub-tasks relating to a request in a multi-core CPU at the same time.

An application is considered neither parallel nor concurrent when it processes all requests one by one, in sequence.

An application is considered both parallel and concurrent when it processes a large number of requests concurrently in a multi-core CPU at the same time.You can see an illustration highlighting the differences between concurrency and parallelism below.


In Everscale, everything is a smart contract, which can also be called an actor in the context of actor model theory. In practice, a smart contract is an entity with properties such as address, code, data, and balance. It has storage capabilities and behaves in accordance with instructions received from other smart contracts. After a contract gets a message and processes it by executing its code in the TVM, the following scenarios can occur:

  • the contract modifies its own properties (code, data, balance)
  • the contract generates outgoing messages (creates another smart contract)
  • the contract goes into standby mode until the next event occurs

You can see how it actually works in the animation below.

The outcome of the above scenarios creates a transaction. It is important to mention that events are processed one by one, ensuring that transactions are ordered and do not interfere with each other. What’s next? 


A sequence of transactions forms a chain. It can also be called an account chain in order to highlight that it is the chain of a single account of transactions.

To reach a consensus about the state, nodes that process transactions need to coordinate the state of the smart contract from time to time. Therefore, the transactions are packaged. It should be mentioned that packaging does not intervene in sequencing. Each transaction still has only one previous tx and one next tx. The transaction sequence is grouped into blocks.

The queues of incoming and outgoing messages are also included in blocks. A block will thus contain complete information describing what happened to the smart contract it holds.

Many chains create shards​

Now let's consider many accounts. We can get several chains and store them together; such a set of chains is called a shard. In the same vein, we can divide shards into blocks, which are an aggregation of individual account blocks.

Chain split and chain merge

Note that since a shard consists of easily distinguished chains, we can easily split it. That way, if we have one shard handling the transactions for one million accounts, and there are too many TPS to be processed, we just divide or split that chain into two smaller shards or Threads. Each chain would then account for half a million accounts and they would both be processed on a separate subset of nodes.

Likewise, if the pressure on some shards reduces, they can be merged into one bigger shard.

There are only two cases when it is not possible. Namely, when the shard contains only one account and thus cannot be split further, and when the shard contains all accounts.

Accounts interact with each other via message-sending. There is a special routing mechanism which directs messages from outgoing queues to corresponding incoming queues and ensures that all messages will be delivered one after another.Blockchain

In Everscale, the collection of all shards which contains all accounts behaving by one set of rules is called a workchain.

Moreover, there can be many sets of rules and thus many workchains. These can operate simultaneously and interact with each other by sending messages cross-chain in the same way that accounts of one chain can interact with each other.

Main Workchain

The main Workchain is used for everyday transactions between actors. When there are a lot of user messages (high network activity) the Workchain may be split into shards (Threads). Each shard, in turn, is assigned to a random sub-group of validators from the global validator set. The sub-groups are selected for a relatively short period of time (round). At any given time, the respective sub-group is responsible for executing transactions in a given shard. At the same time, it constantly downloads blocks from all other shards of its Workchain.

More Workchains are possible

Everscale’s architecture allows for creating up to 232 Workchains, each subdivided into up to 256 shards or Threads to be able to process a high number of transactions in times of heightened activity. Owing to this, any use case (enterprise solution) can exist and function perfectly well in a separate Workchain. The respective Worckchain can have its own Virtual Machine, configuration, fee structure and internal currency. You can see how Workchains can coexist in Everscale in the animation below. For illustrative purposes, we provide three different instances:

  1. Exchange platform - handling a constantly increasing number of transactions. 
  2. Social Media app - handling both an increasing then decreasing number of messages. 
  3. Food Delivery app - handling a constant number of requests.


Everscale’s architectural construct requires synchronization of message routing and transaction execution. To put it simply, network nodes need to reach a consensus about the state. This is exactly where the Masterchain comes into play. Masterchain blocks contain the latest block hashes related to all other chains in the network. Any observer can thus determine the state of all multi-chain systems by a single Masterchain block.

Read More