How to Launch Your Own Blockchain: Scope of Work and Design [Part I]

To help projects avoid such mistakes, I prepared a step-by-step guide with  a technical focus on how to launch a blockchain.

The main role of a blockchain is to accept transactions from users and process them in an accurate and undeniable way. The results of each transaction are recorded in a public database (state database) on each machine of the blockchain network. Any participant can reproduce and double-check this database if he has data on its initial state and a log of all transactions or blocks.

Some transactions require little CPU time (they do not calculate anything), but they can change several balances at once and write a large amount of data to the storage. Other transactions heavily load the processor to perform cryptographic calculations, that will result in a small value recorded in the storage. In the first case, the hard drive and RAM will work more, and in the second case - the CPU. As these parameters can greatly affect the cost of your blockchain servers, understanding transaction types is an important part of technical design.

In addition to transactions, blockchain scenarios are of great importance, i.e. how many transactions from certain accounts the network is able to process. This may be only a dozen accounts, and each of them sends a lot of transactions to the network; or a thousands of new accounts that make one small transaction. Mind that networks for games, fintech applications or cryptographic protocols differ greatly in node load.

Any logic that is more difficult than just an address-to-address token transfer requires certain code (smart contracts, runtime, etc.). Working on a blockchain project, choose a virtual machine that will execute such code:

Examples: EVM (Ethereum), TVM (TON)

As a rule, specialized VMs have a limited functionality and execute smart contracts only of their platform. They are highly secure, produce more predictable results, and calculate all the resources spent on transaction processing.

Examples: Web Assembly in EOS, Parity Substrate (Polkadot)

WebAssembly (WASM) is a web standard used to create client-side code, and it is more productive than JavaScript. Theoretically, smart contracts for WASM can be written in any language, but low-level languages (C, C ++, Rust, etc.) fit blockchains better, otherwise the resulting code will be poorly optimized.

WASM also keeps track of resources spent on execution. Due to more contract functionality, WebAssembly is less secure than a specialized virtual machine.

Examples: Hyperledger Fabric, Cosmos

Native code processing is used when the code processing the transaction is “embedded” in the node. The disadvantage of this option is low level of security and determinism of transaction processing; the advantage is high functionality (developers can use any language features without restrictions).

Another criteria for choosing a blockchain is the way the contract code is updated. System errors will inevitably arise, and you will have to add and change system functionality. In modern blockchains, these tasks can be solved in several ways.

Examples: smart contracts in Ethereum, EOS, TON, Parity Substrate (with WASM or EVM smart contract module)

Any user can create a smart contract or a complex system of smart contracts. Contracts can be deployed and updated without interaction with network validators.

This scheme is the most flexible one. It allows to build a system of contracts of arbitrary complexity but requires a more complex node operation logic as contract code may contain anything. Therefore, a blockchain node must execute such code with extreme caution, limiting its time, requested data, and impact on consensus.

Option 2: runtime code controlled by validators 

Examples: Parity Substrate runtime code, Cosmos Application

This scheme can be represented as a large smart contract that processes all types of transactions. Validators check the code and vote for  necessary changes, then new logic starts working. At the same time, developers can create runtime code from a set of ready-made modules.

Modifying the code that processes transactions is more difficult but there’s no need for additional security checks. Validators are obliged to check the changes and cannot skip vulnerable code, otherwise blockchain won’t operate properly.

Developers of such “runtime” code get much more features and resources at their disposal in comparison to the user contract scheme. Runtime scheme is especially relevant for parachains  (child chains with individual functionality, that are parts of a large blockchain systems).

Without understanding the nature of transactions,  virtual machine features and smart contract logic, you will use blockchain in an extremely inefficient way. For example, support expensive software for the sake of simple operations or carry out risky updates of the main node code for minor logic corrections.

When running your own blockchain, you need to evaluate technical requirements of the client and understand how feasible they are.

One of these requirements is the time of transaction “execution” on the client side. A common mistake is speed estimation based only on tps (number of transactions per second).

Developers typically evaluate tps as the number of transactions in a block to block time. For example, by “1000 tps” we mean that the time between blocks is 1 second, and a block may contain up to 1000 transactions. This does not mean that the blockchain processes one transaction in 0.001 seconds, since transaction processing time depends on block production time.

If block production time is 3 seconds, then processing time of one transaction can reach 3 or even 6 seconds (from the moment the transaction is sent till the next block appears). 3 000 tps (with a maximum of 1 000 transactions per block) can be achieved only by parallel transaction sending from different accounts.

Another important limitation of modern blockchains is the number of validators (servers that produce and confirm blocks). After producing a block, validators must come to an agreement (consensus) on it. Block production time depends on the number of validators and messages that they need to exchange. Any network consensus requires the consent of at least 1/2 N + 1 validators, full security is guaranteed by the consent of 2/3 N + 1 validators. These values ​​are fundamental and ensure the network's tolerance to malicious behavior of participants.

If you plan to launch a blockchain, forget about instant answers to customers and millions of validators. This is achievable only with the advent of full-fledged quantum communication technologies and cryptographic computation.

Suppose you have chosen a blockchain and are about to launch it. What will you do next? 

First of all, it is necessary to choose a specific technology, assess the risks and labor costs for project implementation, and take into account limitations of certain solutions. The solution may have been tested in real conditions or it may be still under development.

In case you are launching your own solution, analyze the closest analogues. Like that you can save time and benefit from previous experience of other teams.

Network testing means checking blockchain performance using the close-to-reality number of validators. If a blockchain has 100 validators, you need to make sure that the network is able to function under load.

Testing involves infrastructure for automatic deployment of a network with several validators, that will be useful at further stages.

Without testing, there is a serious risk that network consensus contains errors or vulnerabilities, especially if it is not a well-known algorithm but a private solution. Gathering information about problems in an already running network will cause some difficulties.

Testnet allows the team and users to try out the solution before the mainnet. All the mainnet functionality should be present in the testnet, and client applications should support both networks. Due to accuracy of smart contracts, product testing can be carried out with 99% accuracy and real balances of real users.

During testnet, you can distribute tokens, check how validators launch their nodes, make first transactions with active users, and use the results later in the mainnet.

Some software (a web interface for validators, monitoring, or a block browser) requires support straight after testnet launch. The information obtained while launching these services in the test network will come in handy for a “smooth” mainnet run.

This stage demonstrates the quality of team work - how stable is the software, how well the documentation is written, how quickly potential validators are able to deploy the required software, etc.

Independent companies usually act as network validators, so it’s almost impossible to get them together and make them perform synchronously. All procedures should allow for an arbitrary order of actions for validators, taking into account their geographical distribution and experience level.

The most popular way of choosing validators is a procedure based on the DPoS algorithm. Token holders vote for validators using their balances. Top validators, who receive the majority of token votes, get the right to produce blocks. In proof-of-authority (POA) networks and corporate blockchains, votes of other validators are used instead of token balances.

Before mainnet launch you need to create an initial list of validators and decide when full-scale block production will begin. Technically, your team can immediately register all validators in the initial network blocks or run your validators first and then gradually replace them with the new ones.

Mainnet launch should involve active monitoring. It is desirable that information from all validators be presented in one service - thus your team will be able to respond to network issues more actively. 

New requirements appeared for a block explorer - the main external network service. It should automatically switch to backup servers in case of failure, as transaction information is extremely important for the project team and users. A backup copy may also be required if the explorer stores user information (for example, contract code verification in Etherscan).

A bridge - software that allows you to transfer tokens from one blockchain to another - can be quite capricious in terms of support as well. The balances of real users depend on its work, so you need to pay special attention to its security.

The team’s work does not stop after the mainnet launch, especially if the blockchain is built on the basis of existing solutions. The codebase is also changing and accumulating important bug fixes and optimizations. These changes must be included in the project, and the blockchain node code must be updated in a timely manner.

At this stage, the developed documentation and procedures (that should have been tested during testnet) are very important. There can’t be any failure during code updates, otherwise validators lose money, time and reputation. During mainnet the pool of validators can change significantly. In case of insufficient support or poor documentation, this can lead to network problems.

There is no serious risks in launching a blockchain basing on already working solutions. As a rule, problems are of economic or organizational nature, they are not related to the internal code of nodes.

Solutions built on the basis of public networks (Ethereum, EOS) are quite reliable software, available to Internet users without restrictions. Centralized financial systems cannot boast of this property: it is impossible to set up a banking API or a database with critical open source information, without registration, a login-password pair and monitoring.

Although blockchain development and launch are quite expensive, its operation may pleasantly surprise participants with high level of security, self-regulation and network ability to maintain accuracy of transactions and remain stable in difficult conditions.