Development Paradigm on Gear

The Gear Protocol is an advanced substrate-based smart contract engine that enables developers to build next-gen Decentralized Applications (dApps) that are faster, more secure, and cheaper for users to operate than if they were deployed on other EVM-based blockchains. In addition to the functionality offered by such networks, Gear’s novel architecture streamlines the process of creating and deploying smart contracts, and allows developers to offer an unparalleled range of new features and functionality in their dApps.

Gear also allows developers to create smart contracts without needing to learn domain-specific languages (DSLs), as is required by other blockchains. This is made possible by Gear’s use of WebAssembly (WASM), which can be compiled from a range of languages, allowing traditional businesses and Web2 developers to create dApps using languages and methodologies familiar to them.

The WebAssembly Virtual Machine is proven to be faster than alternatives. Gear’s use of WebAssembly lets smart contracts compile directly into machine code and run at native speeds, where faster speeds result in lower transaction costs and higher efficiency. In addition, Gear’s use of the Actor communication model enables parallel computing within a Gear network, creating unprecedented scalability.

Contemporary smart contract platforms today limit developers’ freedom and ability to create complex, feature-complete dApps due to one key property — a shared global state, and the necessity for single-threaded processing as a result. This has consequences on the chain’s ability to scale, and limits a developer’s ability to deploy elegant, complete solutions as they would otherwise be able to within a Web2 context.

The Gear Protocol was designed to address this issue, and hopes to enable the next generation of Web3 applications by natively supporting asynchronous messaging and parallel processing within smart contracts. This offers greater composability for developers and allows the creation of complex, fast, and secure dApps that can implement features and design patterns not currently possible using today’s standard smart contract platforms.

To understand how this is possible, we must take a deep dive into how the development paradigm differs on Gear compared to Ethereum or other EVM-based smart contract platforms.

–

This article is broken up into two parts. In Section 1, we explore the distinguishing features and benefits of the Gear Protocol — such as the Actor model, the Persistent memory concept, and Asynchronous message handling — and discuss how these concepts work to simplify and enhance the dApp development process. In Section 2, we will be comparing several practical examples of dApps commonly seen on the Ethereum network today, and how they might be re-architected for greater decentralization, security, and unique additional features when deployed within the Gear ecosystem.

Section 1: Why build on Gear?

Gear was designed to be deployed either as a standalone layer-1 network, such as the first standalone network in the Gear ecosystem, Vara, or as a parachain within a substrate-based blockchain ecosystem such as Polkadot — allowing developers to build decentralized applications that leverage the benefits of the underlying network’s strong security guarantees and its interoperability with other parachains, via the relay chain.

The Gear Protocol, as it sits within (and adjacent to) the Polkadot ecosystem

Either as a parachain or standalone network, Gear helps unlock new use cases and functionality within, and between, smart contracts — offering significant advantages relative to other blockchains and substrate-based smart contract platforms. Let’s explore these advantages now.

Easy onboarding for Web2 and TradFi developers

Developing large-scale applications for today’s popular blockchains is blocked by many significant barriers to entry. Aside from the obvious requirement to learn core blockchain concepts and specialized programming languages — the way in which contemporary smart contract platforms operate exposes the developer to unintuitive design patterns and overloaded functions that can end up rife with bugs and vulnerabilities.

Since Gear utilizes WebAssembly as a virtual machine for operating smart contracts, developers can build highly performant dApps that leverage effective workflows and battle-tested design patterns from the Web2 world. Gear reduces the need for developers to learn blockchain-specific concepts thanks to its comprehensive API for accessing on-chain data and simplifies the process of smart contract development by providing a custom Substrate runtime and native Rust Standard Library — opening the door to non-blockchain specialists and providing them an easy way to start working in Web3

Gear’s Persistent Memory approach also allows developers to create advanced dApps, without needing to learn the intricacies of safe management of storage as in other smart contract platforms like Ethereum. Gear also provides a number of smart contract examples for a majority of modern use cases.

Deploy existing Web2 projects and codebases

Anyone can take an existing codebase and compile it for execution on a Gear network. Currently, Gear supports developers with a native standard library on Rust, and the use of WebAssembly allows for more libraries to be created in the future that support a range of programming languages. This simplifies the process of developing dApps for thousands of existing Web2 developers and significantly increases application inclusivity compared to solutions based on domain-specific languages.

Gear’s unique architecture also allows developers to create dApps that follow a microservices architecture — a well-adopted development framework in the Web2 world for creating complex applications. Usually, a microservice is a relatively small program that implements a specific function and interacts with other microservices via some kind of inter-process communication (IPC).

This allows developers to deploy existing projects to the Gear blockchain with practically zero changes to the underlying codebase, by;

• Splitting complex application logic into several programs, aka smart contracts
• Defining what programs are stateless and what are stateful
• Developing the interaction protocol as a set of messages
• Specifying what are state change conditions of stateful programs

Enabling new design patterns and functionality

Gear utilizes the Actor Model, allowing the use of Asynchronous messaging for smart contracts and enabling the network to perform operations in parallel. While this does come with some additional design considerations, as detailed in Section 2, smart contracts on Gear will generally be more secure and robust as they never share state, and developers are able to define exact rules for communication between users and programs.

The Actor Model is easy to scale and easy to implement. This architecture also enables a feature unique to Gear: contracts can execute their own functions by enqueuing delayed messages to the network to be acted upon later, when a certain condition (like the progression of time) has been met. This offers greater composability for developers, as contracts can recursively call themselves to achieve functionality that would usually be impractical, or could typically only operate with the help of a centralized entity like an oracle or backend server.

Complex dApps like GameFi applications and DeFi protocols can be deployed on Gear and operate in a truly decentralized way, since all communications logic is defined within the smart contract according to the Actor Model. With Gear, developers do not have to rely on permissioned off-chain entities or trusted centralized services to perform delayed tasks.

In Section 2 below, we outline several implementations of dApps on Gear, and describe what new functionality can be added in addition to what would typically be possible on any chain that operates in a synchronous way, like Ethereum and most EVM/WASM-based blockchains.

Section 2: How is it different to develop on Gear, and what use cases does it allow?

Before we explain how smart contracts work on Gear, let’s discuss how smart contracts typically operate within the Ethereum network and other EVM-based blockchains.

Ethereum has 2 types of accounts:

• Externally owned accounts (EOA). An EOA is a private/public key pair that may be linked to a blockchain address.
• Smart contracts accounts, which are controlled by their contract code and have code associated with them.

In Ethereum, smart contracts are executed by a transaction initiated from an EOA. The transaction can consist of multiple operations; an EOA can call a smart contract and this smart contract can call another smart contract and so on. This has the effect of all transactions needing to originate from an EOA.

It is necessary to understand that Ethereum transactions are atomic. By design, all transactions are attempting to mutate the entire global state. We can think of Ethereum as a single-threaded state machine that executes transactions one by one in order to avoid race conditions. In essence, Ethereum achieves concurrency, but not parallelism.

It is not important how many contracts have been called or how these contracts behave while being called. The global state is updated when all executions finish successfully. If execution fails due to an error, all of its effects (changes in state) are “rolled back” just as if this particular transaction had never occurred.

A guarantee of atomicity ensures that updates to the database occur only if all steps were completed successfully. On the Ethereum network, transactions are executed serially, or one by one — so all transactions are atomic by default. Developers don’t need to worry about state inconsistency caused by partially completed transactions, but executing transactions serially is less scalable than Gear’s parallel processing. Let’s explore the implementation differences now in the context of a Decentralized Exchange.

Ethereum vs Gear: Decentralized Exchange Implementation

In a typical Decentralized Exchange on the Ethereum network, an EOA (or a user, in this example) makes a single function call to the swap contract to perform a swap between tokens.

A typical DEX as implemented on the Ethereum Network. A single atomic transaction (swap) is made

Like all transactions on the Ethereum network, Transaction #001 is atomic. When a user calls the swap function on the Swap Contract, the Ethereum Virtual Machine interprets this call and performs all required operations sequentially, only updating the global state when complete. If any of these operations fail, the state is not updated and all progress is lost as if the function was never called at all.

With Gear, private state is held within the contracts themselves, rather than using a global state like Ethereum. This enables the state to be updated simultaneously across the network, allowing all kinds of new features and functionality — but introduces one nuance that developers need to keep in mind: ensuring the consistency of the contract’s state.

Below, we describe how this can be achieved on a Gear network by using different design patterns, like the Saga pattern.

User makes a swap with a DEX using the Saga pattern on a Gear network

In this pattern, we take a different approach by splitting a transaction into multiple steps. The Swap Contract acts as an Orchestrator, defining tasks to be triggered asynchronously:

• Task 1 is to send a transaction to the Token A Contract, instructing it to change its private state (Actor balances of Token A). At the same time, a compensating task Transaction #002b is defined so that the funds can be returned in the case of Task 2 failing.
• Task 2 is only initiated upon successful completion of Task 1 (an asynchronous action), and similarly, instructs the Token B Contract to update its private state. If Task 2 fails, the compensating task Transaction #002b is executed.

With each successful transaction, private contract state is changed. So in this example, if the message to the Token A Contract (Transaction #001) is successful, its state is updated. If then the message to the Token B Contract (Transaction #002a) fails, the state of the Token B contract remains unchanged. In order to avoid state inconsistency, the compensation task is executed (Transaction #002b). This transaction can only fail because of lack of gas, in which case it can be restarted.

With this design pattern (and others), developers can maintain state consistency of their dApps while reaping the performance and scalability benefits of the Gear Protocol and parallel processing.

What new functionality does this allow?

The above example illustrates how a DEX might operate on Gear while ensuring the integrity of the contract’s state. However, this design could be expanded to leverage Gear’s delayed messaging to provide additional features not currently possible to achieve in Ethereum in a decentralized way. For example, enabling advanced trading strategies and financial instruments like short selling and derivatives.

To achieve this kind of functionality on Ethereum today, developers must create centralized systems that take custody of user funds so that a permissioned wallet may perform transactions on their behalf. This requires the user to trust that centralized actor and off-chain infrastructure to perform these transactions accurately, and without bias.

Gear’s delayed messaging is made possible by Gear Protocols’ concept of Gas Reservation, which allows for the creation of gas pools to be used by programs for further execution. These messages can be triggered automatically at a specific time in the future, or under other conditions.

This opens up a wide range of possibilities for the implementation of functional logic related to automation within smart contracts. Delayed messages are similar to cron jobs, which cannot be implemented in smart contracts on other blockchain platforms without the use of external resources. The advantage of this solution is that it eliminates the need for centralized components in dApps, ensuring they function completely on-chain and are fully decentralized and autonomous.

Ethereum vs Gear: Dynamic NFTs for GameFi

GameFi projects on Ethereum currently rely on centralized services to allow an NFT’s properties to be updated with the progression of time, or based on certain conditions.

This requires the user or application to trust a centralized server every time they wish to progress, by, for example, feeding their pet or claiming experience points. Let’s see how this is commonly achieved on the Ethereum blockchain today, in the context of a Tamagotchi-style NFT pet game:

ETH — GameFi application relies on centralized server for time-based updates to NFT properties

Here, a user calls a function to request their pet to be fed once per day for a week (using a separate FeedMyPet function). To perform these steps, an off-chain entity with a special permissioned wallet must read that instruction from the chain, and regularly make transactions to complete these steps. This process is centralized, and relies on the off-chain entity to stay online and available, and to work in the best interests of the user requesting the functionality.

On Gear, this process can be completely decentralized by utilizing delayed messages, allowing an NFT’s properties to be updated over time without the need to rely on trusted parties and off-chain resources.

GEAR — GameFi application uses delayed messages and self-executing smart contracts to allow the game to update itself

In this example, the user sends a similar function call to the contract, where some time-based functionality is requested. Instead of this request being interpreted and acted upon by a centralized entity at a particular time, the contract itself is able to enqueue its own future actions.

This process is automatic and trustless as all actions are scheduled directly within the message queue, where validators are able to dequeue them and execute the instructions when the required time interval has passed.

What new functionality does this allow?

In this model, such applications can be self-sustaining, operating for as long as the gas pool is funded. This is different to how many dApps work on Ethereum and other blockchains, which are forced to rely on off-chain computing and oracles to provide a range of common features.

Self-executing smart contracts have huge implications for the kinds of products and services that can be offered on a Gear network, and not only in GameFi. For example, Gear Protocol could make it possible to distribute NFT qualifications or accreditations that are automatically updated or revoked after a certain time period or other condition has been met.

Similarly, Gear could allow realtors and property owners to create smart contracts that define rental periods — all managed by enqueued tasks that deduct rent payments regularly and automatically modify the on-chain deed to include the new date the tenancy agreement is valid until. Through the use of delayed messaging and self-execution, Gear enables completely new design patterns, and so the full scope of potential use cases for this functionality can be considered to be unchartered territory.

Ethereum vs Gear: Supply Chain Implementation

Supply chains are complex systems that involve a vast number of participants, including manufacturers, suppliers, and vendors. Due to the large number of participants, lack of transparency, and prevalence of fraud, there has been a growing interest in the use of blockchain technology to improve the efficiency and security of global supply chains.

In this example, we explore on-chain supply chain implementations on both Gear and Ethereum. The goal is to create a system that provides an immutable audit trail for physical items as they through the supply chain from one stage to another, which can be traced and verified by all participants.

Supply chain solution on Ethereum

The business logic implies that each next step should be triggered by an operator after confirmation of the previous step. This example shows the implementation of a supply chain for a production line in Ethereum, where manufacturers perform production steps upon materials provided by a supplier, and the result of each step must be manually queried by the manufacturer (i.e was the production step successful?) before the next step can be started.

But thanks to Gear’s self-execution and gas reservation features, this model can be implemented in a trustless way. On a Gear network, smart contracts can send a delayed message to itself (or other programs/users). This allows the automation of various processes.

Supply chain solution on Gear

Here we leverage contract self-execution to verify and approve production steps automatically, and trustlessly, after certain conditions are met. Instead of relying on the manufacturer to manually confirm that a production step was successful and then schedule additional steps, a managing contract (the Manufacturing Contract) is able to check if certain conditions are valid and enqueue the next step in the process automatically.

What new functionality does this allow?

Supply chains and production lines can be incredibly vast and complex but with the automation that Gear enables, much of this complexity can be abstracted away from manual tasks that are prone to human error or manipulation. These tasks could include checking stock levels, current prices, locations of goods, and confirmation checks before initiating further production steps, among others.

Since Gear can be deployed as a parachain in the Polkadot & Kusama ecosystem, a supply chain solution built on a Gear parachain would inherit all of Polkadot’s underlying interoperability and security benefits without the developer needing to operate their own parachain slot or create and secure a standalone network and attract a validator set.

There is also the possibility of configuring your supply chain infrastructure to communicate with external systems in a trustless way. Via the relay chain, dApps built on a Gear parachain can send and receive messages from any other parachain on the underlying network, allowing developers to design inter-operable supply chains that, for example, control automata like manufacturing equipment, or access data from another chain in order to perform or validate any required task.

–

In this article, we’ve explored a number of implementations for common dApps on a Gear Network, and the advantages of these design patterns. We’ve learned how Gear’s architecture affords it numerous benefits for developers and users over contemporary smart contract platforms like Ethereum, and what considerations must be made when building smart contracts on Gear.

In addition to scalability and performance, the network allows for functionality and design patterns that were either not previously possible, or that rely on costly, centralized services to function. The Gear team hopes that this will allow Gear Protocol to foster a new wave of innovation in the Web3 world — led by an army of Web2 developers and TradFi developers building new, decentralized solutions to existing real-world problems.

Visit our Get Started Guide for an overview of writing, compiling, and deploying smart contracts for a Gear network. You can also learn more about the Actor Model, Memory Parallelism, and the WebAssembly Virtual machine in our Whitepaper.

–

💻 Website: https://www.gear-tech.io/

📖 Docs: https://wiki.gear-tech.io/

🐙 GitHub: https://github.com/gear-tech

👾 Discord: https://discord.com/invite/7BQznC9uD9

💬 Telegram: https://t.me/gear_tech

🐦 Twitter: https://twitter.com/gear_techs