How to Launch Your Own Blockchain: Selecting The Right Engines [Part III]

This article continues the series of articles “How to launch your own blockchain” and concentrates on selecting a blockchain engine for your project. 

We will review different engines paying special attention to their features so that you make a conscientious choice between a ready-made solution and a blockchain from scratch (see also my previous article).

Attempts to create a blockchain from scratch are commendable. Thanks to them, many well-known solutions have appeared. Nevertheless, you need to have a clear cut understanding of your team capabilities.

Writing new blockchain node code is like creating a database with a reliable network replication mechanism. If you google the number of such databases, you will hardly find a hundred projects built within a decade. Only a few companies (Oracle, MS SQL Server, MySQL, PostgreSQL) own a huge market share, and core developers of such systems are highly valued.

To develop blockchain nodes, you will have to find a team of cool and rare specialists with experience in multithreading, cryptography, network protocols, complex internal algorithms and solid understanding of modern operating systems.

Testing is an essential stage for any blockchain, since consensus algorithms can perform perfectly on several validators and in a completely different way when there are tens and hundreds of nodes under load. Increasing the number of developers in this case will only lead to team miscommunication.

According to our team experience, enterprise customers rarely choose this path. Creating a blockchain is a task for a group of researchers, enthusiasts who can afford to work freely and without a business plan. Such team should be able to explore any issues without much concern for the project deadlines. Currently, Bitcoin and Ethereum development is carried out by independent developers around the world, from different time zones and shifting schedules. External pressure of business factors can play a cruel trick on your project, forcing you to solve problems faster without thorough thinking about the consequences.

This section is called the “engines” as the term is often used to refer to diverse software complexes designed to solve a specific problem. For example, a “search engine” or a “graphic engine” is not only a code but auxiliary software, additional utilities, descriptions of algorithms and much more. Thus, it will be convenient to call major blockchain cores engines (for example, “built on the Ethereum engine”).

If your blockchain does not have a unique architecture and you want to deliver a solution in a certain period of time, the best option would be to work with existing engines. You can implement custom consensus, transactions, management of network validators. You can use ready-made open source code that has been tested on real networks. You won’t have to change the code of a blockchain node. To implement custom logic, you will need to change only the engine-related part. You will be able to focus on blockchain business logic and avoid vulnerabilities and problems of a network layer.

Let’s analyze the current engines that will help your team launch a blockchain, design and implement its internal economy and organize complex transactions.

This software package is based on the core of the Ethereum public blockchain. Public Ethereum uses Proof-of-Work consensus, whereas its many test networks and their successors use different types of Proof-of-Authority and Proof-of-Stake consensuses. The software meets the most stringent security criteria and has been tested in dozens of working mainnets. In my opinion, it is the most developed software for building blockchains with any kind of consensus and multi-functional smart contracts.

I’d like to highlight the role of the POA Network project - the team have done a great job and launched several fast and reliable networks. POA Network is stable, suitable for any transactions but much faster than the original Ethereum. The role of validators (miners) is played by computers whose honest work is legally certified. This network can be considered the standard for launching corporate Ethereum-based blockchains.

There are two main implementations of the Ethereum node code: in Rust (code, names: poa-parity (old) or openethereum (new)) and in Go (code, name: geth).

For now, when building a PoA network in geth (Go), only Clique consensus will be available to you - this is the simplest consensus  protocol without finalization that can be used only for test purposes.

The consensus implemented in poa-parity (Rust) consists of two algorithms: Aura schedule validators and GRANDPA finality gadget. This secure couple is used in POA networks based on Ethereum. POA Network team is also working on HoneyBadger - a promising implementation of a BFT consensus.

Let’s also pay attention to a new Nethermind blockchain node written in C# for the .NET Core platform. It fully supports Ethereum and a large number of operating systems.

Ethereum POA uses the EVM and smart contracts written in Solidity. EVM has become the standard for virtual machines with a lot of ready-made code and development patterns. The EVM contract code is responsible for large amounts of cryptocurrency, and any vulnerability found causes a strong reaction of the community and the media. Thus, EVM contract security is currently rather high.

The list of validators is managed through smart contracts. You can operate with one or more tokens or even get rid of them. You can simplify the procedure of adding validators or take in an “almighty” account. The benefit of this scheme is that one contract developer is enough to create a highly secure and portable network economy with governance mechanisms, transaction logic, and other properties.

Ethereum allows to use web3.js JavaScript library, regardless of consensus, validators, or its location.

As for Ethereum POA, there is a repository that contains playbooks for automatic network deployment - deployment-playbooks.

If you plan to launch an Ethereum POA network, follow this instruction. It will guide you through the whole process: from creating validator keys to launching the first nodes, deploying system contracts, and running a validator interface and block explorer.

AWS has a ready-made Ethereum POA network, but I still recommend controlling the launch yourself. You must understand what services you run and how they work.

The second secure and stable engine is EOS. “OS” in its name did not appear by chance.

EOS can be launched as a separate PoS or PoA network. Like Ethereum, this software has already been tested and has wide functionality that allows you to run a blockchain with smart contracts and automated transactions. While Ethereum has a simple address system, EOS uses a hierarchical system of accounts and rights to various actions. This makes EOS similar to an operating system - "a program to run other programs."

EOS can be used as a convenient corporate platform with an out-of-the-box account management system and fast consensus. You can also easily integrate almost any functionality using C++ plugins and C++/WebAssembly smart contracts (for example, another cryptography).

EOS consensus design and fast blocks enable you to achieve a very fast user response time, that is extremely important for building decentralized applications with complex functionality (for example, Cyberway and Golos.io projects or Commun.com social network). Cyberway has recently fulfilled complex migration of its business logic from the previous blockchain transparently for users, that adds to EOS flexibility and versatility.

EOS code is written in C++ and developed on the basis of previous working experience with Graphene, Bitshares, Steemit. It uses its own version of DPoS consensus.

Nowadays almost all projects using DPoS build their algorithms like EOS and its ancestors - accounts “vote” for top validators using token balances. Validators sign each block individually at a certain time and according to a schedule. Then they periodically agree on the so-called Last Irreversible Block (LIB) that collects 2/3 + 1 signatures from validators.

Many EOS fork projects are trying to improve this consensus. For example, our Haya uses another finality gadget, RANDPA, to fix the LIB and achieve finality in 2-3 seconds.

The transition to corporate POA consensus is straightforward, as the list of validators is controlled by system smart contracts.

EOS smart contracts are usually written in C++, they use a modified WebAssembly virtual machine and can be created by any account. Writing smart contracts is not difficult as they have a lot in common with Solidity ones.

The main token (or tokens) and transaction types can be implemented in system smart contracts (for example, see this system token). An interesting feature of EOS contracts is the use of table abstraction to store contract data. Ethereum primarily uses mapping (an associative array).

Another feature of EOS smart contracts is upgradeability. The owner of the contract can replace it by updating the logic or correcting an error. This is very different from Ethereum, where contract immutability is an important condition to ensure that the contract logic will never be changed unless hard fork occurs.

In my opinion, changing the code of contracts is an important advantage for corporate blockchains. It’s still difficult to attack contracts and network, since  the code is updated through agreement of the parties, without any participation of validators.

In EOS, "sponsorship" transactions can be paid by the owners of the contract instead of users. This is a powerful opportunity to attract new users. Do you still remember that there are no “free” transactions without security loss in blockchains?

BOSCore, Telos, Haya and a dozen EOS forks prove that this software is in high demand. There are enough tools for EOS, and you don’t have to implement the related software from scratch.

Eosjs is an analogue of web3.js, suitable for working with any applications and contracts of any EOS-based network.

EOSTracker is an open source block explorer with decentralized voting apps for validators.

Unlike POA Network, EOS does not have a large and powerful integrator, and each project is building its own solution. Nevertheless, the main node code is stable and works under serious loads without failures.

Substrate is a child of the Parity team. A huge amount of software has been developed by Parity team for different blockchains: wallets, blockchain nodes, smart contract systems, compilers, virtual machines. I think the most valuable one among them is the Rust implementation of Ethereum node described above.

Parity Substrate allows a developer to easily create his own version of a blockchain from ready-made modules with complex consensus and transaction processing logic. Substrate is a blockchain constructor on top of which you can build even an Ethereum or Bitcoin blockchain node.

Substrate is part of a bigger project called Polkadot - a system that consists of a main chain and many children  - separate chains called parachains, each with individual logic.

The advantage of “connecting” your blockchain to Polkadot is on-chain data exchange with other chains and the ability to use their contracts, accounts, and tokens without additional software.

Substrate code is written in Rust. In my opinion, Substrate architecture reflects solid experience of the blockchain team: all components are well structured, divided into separate modules, and the code contains detailed comments. Substrate-based client for Bitcoin and ZCash networks adds to the flexibility.

As for consensus, you can choose from several ready-made options or write your own. In most cases, this is PoA or DPoS consensus, that in case of Substrate means using Aura and GRANDPA.

Substrate blockchain performance is high. We tested the main Polkadot chain with 99 validators distributed over three continents, and it showed excellent results.

The main advantages of Substrate are well-thought architecture, development stack (Rust), and a huge field for development - you can build solutions of any complexity.

Unlike Ethereum or EOS, Substrate processes transactions using code that is hosted by validators (not users). This code is called “runtime” and is executed by the WebAssembly virtual machine.

In fact, runtime is  a big smart contract that is built from separate modules by a developer and updated by validators. The modules contain the logic of accounts, tokens, transactions of any complexity, etc. This is what makes Substrate a constructor. Usually you just need to combine several ready-made modules or slightly modify one of them to cover your needs. 

I’d also like to mention WASM и EVM - modules that enable users to deploy their smart contracts, like in Ethereum or EOS. Thus, launching a universal Substrate-based blockchain is also possible.

Runtime developers are responsible for transaction execution restrictions. It is possible to charge the same fee for all transactions, take into account every single resource or make everything free and exclude internal cryptocurrency.

There are a number of useful solutions for Substrate, for instance,  Polkascan (a block explorer) and a set of JS programs. You may also need ansible scripts to deploy a Substrate cluster (we used this one to test Polkadot).

Substrate does not have a rich universal software set, wallets or block explorers, like Ethereum or EOS, because parachains can differ a lot. However, the project is actively developing, and many teams simultaneously are building the related software.

Cosmos is a project based on one main chain and many subsidiary blockchains called “zones”. Child chains are built using  Cosmos SDK - a set of software for creating blockchains.

Cosmos is a “continuation” of the Tendermint project. Its key technologies are reliable consensus and the Application concept similar to Substrate runtime. As with Polkadot + Substrate, a blockchain created using the Cosmos SDK can live separately or connect to the Cosmos ecosystem as a child chain.

The entire Cosmos software suite is written in Go, well-structured and actively used. There are several Cosmos-based projects that are already working, including the Binance Chain.

If your developers write code in Go - Cosmos SDK may be your choice. It is under active development in real projects, whose blockchains and transactions can be seen on public networks.

The main concept of Cosmos is called Application. Any blockchain is a state machine, and in Cosmos it is a separate part of the code. In fact, a developer simply sets the rules according to which one data is transformed into another by external influence, programming the so-called state transition function. It sounds complicated, but in fact transaction processing is state transition that changes several balances. This is what Application does — it takes some external influence (transaction) and changes the blockchain state. In the case of Cosmos, the developer does not have to solve the problems of consensus - the network will agree and come to consensus on the results itself.

Cosmos consensus is based on the Tendermint one, which is very close to pBFT. Validator confirmations are collected for each block, which means instant finality as soon as the block is accepted by the network. However, this algorithm requires more messages between validators, and in case of network problems this consensus will slow down the chain finalization.

On the other hand,  it is the most predictable consensus, it is  protected from forks, has formal mathematical proofs of reliability and is the most rigorous and safe solution among all existing solutions.

Cosmos Application can be viewed as a smart contract responsible for processing all types of transactions. Here is an example of the name registration service Application.

Simultaneously with creating code for blockchain nodes, Cosmos SDK creates client code that can generate required transactions.

Cosmos also uses gas to limit transactions. When executing a transaction, validators calculate its value in arbitrary units of gas. When sending a transaction, a user indicates the price that he is willing to pay for a unit of gas and the limit that he is willing to spend. This is the basis for calculating a transaction price.

Cosmos Application requires code determinism, i.e. developed operations should not produce different results at different points of time or in different architecture versions, otherwise the blockchain will not work.

In parallel with Application, Cosmos SDK allows you to immediately get the code that calls necessary functions from client machines. This code can be used on the site working with Cosmos or in the network wallet (client).

I found several useful libraries in JavaScript: js-cosmos, cosmosjs and js-abci that implements the ABCI interface. They are handy if you plan to interact with a blockchain from a browser. ABCI allows you to create Application in different languages, including Java, C ++, and Python. The Lotion project, for example, helps you create a blockchain entirely in Javascript.

Cosmos is rapidly developing, and many different projects are already launched. I advise to pay attention to it if you have expertise in Go and want a reliable working solution.

In the next article we will discuss testing and benchmarking of your blockchain and testnet launch.