How to Launch Your Own Blockchain: Mainnet Launch [Part VI]

I II III IV V

It’s time for mainnet launch. Development, testing, testnet launch and validator selection are already in the past. Distribution of real token balances to participants and responsibility for security of funds are on the way.

The most important steps for the team (testnet launch and the game of validators) are over, and the network should be technically ready by now. Unfortunately, a “decentralized network” does not mean that everything will start automatically. It is the team that is in charge of the blockchain code that will actively engage in mainnet launch.

Genesis block is the first block of the main network. Simply put, it contains all the information about balances, initial  smart contracts’ code, and a list of  initial validators.

Any node of the main network must start the chain with this data, otherwise the entire blockchain will be invalid.

At the beginning, the team knows the code of the main contracts and a list of addresses or public keys of those who will receive tokens on their balances. The list can change before the launch, so it is sensible to make a script that creates an initial state from the list of address balances (genesis block and other must-have). The script displays all the addresses and information about the initial state, and its launch can be broadcast live on Youtube. Thus, any user who doubts honest distribution of initial balances or contract data can repeat this procedure.

Several validators are required to start block production. Some of them may run into problems: confuse configurations of the test and the main networks, use the outdated initial state or incorrectly evaluate server resources. Therefore, don’t panic if you don’t see new blocks right away.

Be patient or design the launch so that new validators could be gradually connected. For example, run the network on your servers  “giving way” to new validators little by little or connect a few of validators while running the network and increase the number of the newly-added ones. I recommend to prepare scripts that display a list of working validators and a checklist for them in advance.

Each network validator has an account that is used to sign blocks, vote for other validators and other important functions. Private keys are located on the validator’s server.

The server can be attacked in several ways (e.g. an attack on validator software, devops accounts, etc.),  so you need to use the keys that, if stolen, will not allow the hacker to control validator funds. For example, there is no cryptocurrency on the validator’s address, but another address from a separate machine “votes” for it. In case of a compromised validator, you can simply add another validator with a new address  and vote for him. Validation rewards should be transferred to an independent external address.

Multisig addresses deserve special attention. They are mandatory since hacking any multisig address will not be fatal anymore. You will need to access several (at least two) private keys instead of one (the number of required confirmations can vary) to get full access to funds.

Validator “elections” can serve as a good example of a multisig activity: it is required to stake funds on a smart contract that selects validators. The validator’s server sends a request transaction once a day but it is invalid unless a confirmation transaction is sent from another address. Confirmation is sent from any validator-independent machine that will not provide full access to the validator's funds even if it’s hacked.

Despite the powerful protection, many validators do not like multisig logic, as it involves additional services that require monitoring. Scripts suit well for such activity as they automatically monitor the required addresses and confirm transactions.

Such “autoconfirmation” scripts must check at least the address that will receive a confirmed transaction or the type of the called smart contract function. Without such verification, an attacker can create a transaction that withdraws funds from the validator’s address, and the script will automatically confirm and sign it with an additional key - in this case, multi-signature protection loses its meaning.

You can’t always be sure that blockchain launch will go off without a hitch. You may want to change the system smart contracts during first months of the network operation or to modify it on the go due to business requirements without validators’ approval.

If you want to avoid complicated approval procedures, then building a special “almighty” account is allowed. It can change the code of system contracts and have access to participants' accounts. Also, you can include publicly verifiable logic that will disable this functionality after a certain time and increase the level of trust in the network.

It is not recommended to keep such accounts for a long time, especially after the network token is available on crypto exchanges or for exchange - attacks are highly likely at this moment and they can completely undermine the network capitalization.

Project tokens are often issued on the Ethereum network, and it takes a few simple steps in the browser to create your own token. Token holders usually transfer their balances from other blockchains (mostly Ethereum) to the main network after launch. The software used to transfer tokens from one blockchain to another is called bridges. This service monitors two networks simultaneously. When a user wants to transfer tokens, the bridge “picks them up” in the source network and “issues” them in the target one.

Bridges can be unidirectional (move tokens from one network to another), or bidirectional (move tokens in both directions). The mechanics of bridges may vary depending on smart contract types supported by both networks.

In most cases, bridge operators are network validators. They accept your project tokens in a specific Ethereum smart contract and (as soon as they confirm the receipt) issue the required amount of tokens in your blockchain and on the other side.

There are universal bridge implementations (see an example) and proven action algorithms for Ethereum-based networks, EOS and others with full multifunctional smart contracts. 

A bridge with bitcoin-like networks is a more complicated task due to UTXO-based address design.

Bridges must be designed and tested in advance.

Validators are responsible for monitoring and performance tracking of their servers. The project team spends resources on supporting its validators only. Should you collect monitoring data from all network validators and pay for server support?

It’s up to you to decide. However, mainnet monitoring requires a couple of extra servers for the centralized collection of validator metrics, and the benefits are huge - all participants will be able to receive general  aggregated information on network performance.

Your team will receive a large number of questions during launch. Which validators are active? Do they work correctly? What is their performance compared to their colleagues’ one? The cost of these extra servers may cover working time of your specialists.

The service doesn’t demand constant support - you can turn it off at any time, while validators will just run their own copy and change a couple of addresses to start monitoring.

Without any doubt, this is the most important blockchain service that displays information about blocks and transactions. However, transactions and addresses are very few in number during launch. Compared to the testnet or the game of validators, the block explorer is not very interesting to participants at the beginning. Most active accounts are validators and developers who prefer to use specialized utilities to get the necessary data.

Development of a high-quality and convenient block explorer is based primarily on user experience that is still very limited. 

Web-interface for validators is extremely important for validators during first weeks after mainnet launch, so I recommend adding at least the simplest data aggregation. For example, uptime validators, the number of produced blocks, and staking, voting and rewards statistics.

If participants are able to test and control themselves, you will quickly spot potential problems and answer any questions regarding the network economy more accurately.

If you want validators to automate basic tasks from the very beginning, identify problems and respond to them, you should take care of utilities allowing to vote, find out the validator status, and confirm multisig transactions.

It seems that ensuring such software quality is much easier than making a good block explorer or wallet. However, in practice, frequent code changes will break automation schemes on the side of validators. This can lead to unpleasant failure and conflicts in the network.

Pay attention to these tools, do not rename the parameters and their format after launch, and strictly follow the standards adopted in the free software development community. The quality of this software is a criterion for validators to assess your team level.

Blockchain was meant for this software. By the time of mainnet launch, any wallet or dapp code updates should be quick. To do this, you need to test the required code deployment procedures during testnet, add monitoring, and make good logging to retain maximum  users.