The advantage of Gear technology

In the previous topic we introduced Gear, a new proposed Polkadot/Kusama parachain with the most advanced smart-contract engine, its mission, key features and the team.

Now let’s dig into details about the key advantages of GEAR’s groundbreaking technology.

Summary

The key Gear’s technology innovation lies behind the novel cross-contract communication approach. Gear uses an Actor communication model and WebAssembly VM, which enables parallel processing, exceptional speed and low transaction costs.

WebAssembly VM is proven to be faster than any alternatives. The use of WebAssembly lets GEAR’s smart contracts compile directly into machine code and run at native speeds. A higher speed means lower transaction costs and higher efficiency.

Background

Let’s consider the basic principles and components to form a background for better understanding of Gear technology.

As any blockchain system, Gear maintains distributed state. Runtime code compiled to WebAssembly becomes a part of the blockchain’s storage state.

Storage state includes the following components:

• Programs and memory (includes program’s code and private memory)
• Message queue (global message queue of the network)
• Accounts (network accounts and their balances)

Programs and memory

Program code is stored as an immutable Wasm blob. Each program has a fixed amount of individual memory which is reserved for a program during its initialization and persists between message-handling (so-called static area). A program can read and write only within its own memory space and has no access to the memory space of other programs.

Programs can allocate more memory from the memory pool provided by a Gear instance. A program can allocate the required amount of memory in blocks of 64KB. Each allocated block is stored separately on the distributed database backend, but at the run time, Gear node constructs continuous runtime memory and allows programs to run on it without reloads.

Message queue

Gear instance holds a global message queue. Using Gear node, users can send transactions with one or several messages to a particular program(s). This fills up the message queue. During block construction, messages are dequeued and routed to the particular program.

Accounts

For a public network, protection against DOS attacks always requires gas/fee for transaction processing. Gear provides a balance module that allows to store user and program balances and pay a transaction fee.

Regular balance transfer is performed inside the Substrate Balances module. Balance is transferred between users, program and validator accounts.

In addition to regular balance transfer Gear network defines gas balance transfer that is used to reward validator nodes for their work and allows the network to be protected from DoS attacks.

State transition

Each system follows the rules according to which the state of the system evolves. As the network processes new input data, the state is advanced according to state transition rules. This input data is packed in atomic pieces of information called transactions.

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

When a Gear validator node comes to produce a new block, some (or all) transactions from the pool are merged into a block and the network undergoes a state transition via this block. Transactions that were not taken in the last block remain in the pool until the next block is produced.

Gear supports the following types of transactions:

1. Create a program (user uploads new program(s) — smart-contracts)
2. Send a message (program fills the message queue)
3. Dequeue messages (validators (block producers) dequeue multiple messages, running associated programs)
4. Balance transfers (Gear engine performs user-program-validator balance transfers)

Actor model for communications

One of the main challenges of concurrent systems is concurrency control. It defines the correct sequence of communications 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 communication classes:

Shared memory communication — when concurrent programs communicate via changing the content of shared memory locations.

Message passing communication — implies concurrent programs communication via messages exchanging. Message-passing concurrency is easier to understand than shared-memory concurrency. It is usually considered a more robust form of concurrent programming.

Typically, message passing concurrency has better performance characteristics than shared memory. The per-process memory overhead and task switching overhead is lower in a message passing system.

There are plenty of mathematical theories to understand message-passing systems, including the Actor model.

For inter-process communications, Gear uses the Actor model approach. The popularity of the Actor model has increased and it has been used in many new programming languages, often as first-class language concept. The principles of the Actor model is that programs never share any state and just exchange messages between each other.

While in an ordinary Actor model, there is no guarantee on message ordering, Gear makes some extra guarantees that order of messages between two particular programs is preserved.

Using the Actor model approach gives a way to implement Actor-based concurrency inside programs (smart-contracts) logic. This can utilize various language constructs for asynchronous programming (for example, Futures and async/await in Rust).

Unlike classes, actors allow only one task to access their mutable state at a time, which makes it safe for code in multiple tasks to interact with the same instance of an actor.

Asynchronous functions significantly streamline concurrency management, but they do not handle the possibility of deadlocks or state corruption. To avoid deadlocks or state corruption, async functions should avoid calling functions that may block their thread. To achieve it, they use an await expression.

Currently, the lack of normal support of async/await pattern in the typical smart contracts code brings a lot of problems for smart contract developers. Actually, achieving better control in a smart contract program flow is actually more or less possible by adding handmade functions (in Solidity smart contracts). But the problem with many functions in a contract is that one can easily get confused — which function can be called at which stage in the contract’s lifetime.

Gear natively provides arbitrary async/await syntax for any programs. It greatly simplifies development and testing and reduces the likelihood of errors in smart contract development. Gear API also allows synchronous messages if the logic of the program requires it.

Memory parallelism

Individual isolated memory space per program allows parallelization of message processing on a Gear node. Number of parallel processing streams equals the number of CPU cores. Each stream processes messages intended for a defined set of programs. It relates to messages sent from other programs or from outside (user’s transactions).

Gear engine uses a runtime-defined number of streams equal to number of CPU cores on a typical validator machine, divides total amount of targeted programs to number of streams and creates a message pool for each stream.

Programs are distributed to separate streams and each message appears in a stream where its targeted program is defined. So, all messages addressed to a particular program appear in a single processing stream.

In each cycle a targeted program can have more than one message and one stream processes messages for plenty of programs. The result of message processing is a set of new messages from each stream that is added to the message queue, then the cycle repeats. The resultant messages generated during message processing are usually sent to another address (return to origin or to the next program).

WebAssembly virtual machine

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

WebAssembly has the following advantages:

• Exceptional native speed. As it translates program code to actual hardware instructions. A higher speed means lower transaction costs and higher efficiency.
• Portable. It can run on any actual hardware.
• Safe. Properly validated WebAssembly program cannot leave a sandbox (guaranteed by specification).

WebAssembly is a global industrial technology, remarkable for many reasons:

• It has been designed and implemented in collaboration between all major competitors in its space.
• It has been designed and released along with a complete mathematical, machine-verified formalisation.

Check out Gear’s GitHub and stay up to date.