Gear's technical advantages


In the previous article, we introduced the newly launched Polkadot/Kusama parachain – Gear, which has a state-of-the-art smart contract engine, and introduced Gear's mission, key features, and team members.
Now, let's dive into the key benefits of GEAR's breakthrough technology.


The key technological innovation of Gear lies in its novel way of communicating across contracts. Gear uses the Actor communication model and the WebAssembly VM, which supports parallel processing and has the advantage of being fast and low-cost.

It turns out that the WebAssembly VM runs faster than any other scheme. Using WebAssembly allows GEAR's smart contracts to be compiled directly into machine code, running at a speed comparable to native ones. Faster speed means lower transaction costs and higher efficiency.


We can take a look at the fundamentals and building blocks to get a better understanding of Gear's technology by knowing the background.

Like other blockchain systems, Gear maintains distributed state. The runtime code will be compiled into WebAssembly and become part of the blockchain storage state.

The storage state includes the following parts:

  • Programs and memory (including program code and private memory)
  • message queue (global message queue for the network)
  • Accounts (web accounts and their balances)

program and memory

Program code is stored as immutable Wasm blobs, each program has a fixed amount of independent memory, which is reserved when the program is initialized and remains unchanged during message processing (the so-called static area). A program can only read and write in its own memory space, and cannot access the memory space of other programs.

Programs can allocate more memory from the memory pool provided by the Gear instance. The program allocates the memory it needs in 64KB units. Each allocated block of memory is scattered across the distributed database backend, but at runtime, Gear nodes construct contiguous runtime memory and allow programs to run on it without reloading.

message queue

Gear instances hold a global message queue. Using Gear nodes, users can send transactions containing one or more messages to a specific program. These messages will populate the message queue. During block construction, messages are dequeued and routed to specific programs.


For public networks, defense against DoS attacks often pays gas/fee when transactions are processed. Gear provides a Balance module that allows to store user and program balances and pay transaction fees.

Regular balance transfers are performed in Substrate's Balances module. Balances are transferred between user, program and validator accounts.

In addition to regular balance transfers, the Gear Network defines gas balance transfers that reward validator nodes for their work and protect the network from DoS attacks.

state transition

Every system follows the rules by which the state of the system evolves. When the network processes new input data, the state advances according to the state transition rules. These input data are packaged in atomically granular pieces of information called transactions.

Gear nodes maintain and synchronize a transaction pool containing all new transactions. When any node (validator node or not) receives a transaction, that node propagates the transaction to all connected nodes.

When Gear validators generate new blocks, some (or all) of the transactions in the pool will be merged into a block through which the network will make state transitions. Unpacked transactions in the previous block will remain in the pool until the next block is generated.

Gear supports the following transaction types:

  1. Create program (user uploads new program – smart contract)
  2. Send a message (the program fills the message queue)
  3. Exit the message queue (validators (or block producers) exit multiple messages, run related programs)
  4. Balance transfer (Gear engine executes user-program-verifier balance transaction)

Actor Communication Model

One of the main challenges of concurrent systems is concurrency control. It defines the correct order of communication between different programs and coordinates access to shared resources. Potential problems include race conditions, deadlocks, and resource starvation.

Concurrent computing systems can be divided into two types of communication modes:

Shared Memory Communication – Concurrent programs communicate by changing the contents of shared memory locations.

Message Passing Communication – Concurrent program communication through message exchange. Message passing concurrency is easier to understand than shared memory concurrency. It is generally considered a more robust form of concurrent programming.

In general, message passing concurrency has better performance than shared memory. In a message passing system, the memory overhead and task switching overhead of each process is lower.

There are many mathematical theories that can be used to understand message passing systems, including the Actor model.

For inter-process communication, Gear uses the Actor model. The actor model is becoming more and more popular, often as an advanced language concept, and now many new programming languages ​​use it. The principle of the actor model is that programs never share any state, just exchange information between each other.

While in a normal Actor model there is no guarantee of message ordering, the Gear additionally guarantees that the ordering of messages between two specific programs remains the same.

Using the Actor model allows us to implement Actor-based concurrency in our program (smart contract) logic. This allows us to take advantage of various language constructs for asynchronous programming (e.g. Futures and async/await in Rust).

Unlike classes, actors only allow one task at a time to access their mutable state, which allows code in multiple tasks to safely interact with the same actor instance.

Async functions greatly simplify concurrency management, but they cannot handle deadlock or state corruption situations. To avoid deadlocks or state corruption, asynchronous functions should avoid calling functions that might block their threads. To achieve this, we choose to use the await expression.

Currently, the lack of support for async/await patterns in typical smart contract code creates a lot of problems for smart contract developers. In fact, by adding manual functions (in Solidity smart contracts), it is possible to achieve better control in the smart contract program flow. But the problem with many functions in contracts is that people can easily get confused about which function should be called at which stage in the contract's life cycle.

Gear provides a generic async/await syntax for programs. This greatly simplifies the development and testing process and reduces the possibility of errors in smart contract development. Gear API also supports synchronous messages if required by program logic.

memory parallelism

Separate memory space for each program allows parallelized message processing on Gear nodes. The number of parallel processing streams is equal to the number of CPU cores. Each stream will process messages for a defined set of programs. It is related to messages sent from other programs or outside (user transactions).

The Gear engine uses a runtime-defined number of streams equal to the number of CPU cores on the validator machine, divides the target program's total by the number of streams, and creates a message pool for each stream.

Programs are distributed into independent streams, and each message appears in the stream of its target program. Therefore, all messages destined for a particular program appear in one processing stream.

In each cycle, a target program can have multiple messages, and a stream will process messages for many programs. After the messages are processed, a new set of messages for each stream is added to the message queue and the cycle repeats. During message processing, the resulting message is usually sent to another address (either back to the origin or the next program).

WebAssembly VM

Gear uses WebAssembly (Wasm for short) under the hood. Any Gear program is in WebAssembly format. WebAssembly is a code format for deploying programs. In the context of Gear, any smart contract is a WebAssembly program.

WebAssembly has the following advantages:

  • Excellent native speed. Because it translates program code into actual hardware instructions. Higher speed means higher efficiency and lower transaction costs.
  • Portability. It can run on any hardware.
  • safety. A properly validated WebAssembly program cannot leave the sandbox (guaranteed by the specification).

WebAssembly is a compelling global industry technology for the following reasons:

  • Co-designed and implemented by all major competitors in the field
  • Design and release with full mathematical and machine formal verification

Please keep an eye on Gear's github for the latest news!

About GearFans

Gear is the computing component of the Polkadot ecosystem, and GearFans is a community of Gear enthusiasts.

  • Official website:
  • Twitter:
  • GitHub:
  • Discord:…
  • Medium:
  • Telegram group:
  • Telegram Chinese group:
  • Telegram Chinese development group: