Before developing your own blockchain, your team must clearly understand what the blockchain is for and what budget you can allocate f...
Before developing your own blockchain, your team must clearly understand what the blockchain is for and what budget you can allocate for its maintenance.
Blockchain design and launch has its own nuances. They can be easily overlooked when planning if you misjudge the scope and complexity of the task.
To help projects avoid such mistakes, the head of the MixBytes research department Sergey Prilutsky has prepared a step-by-step guide on how to launch the blockchain.
This article will help you decide on the choice of a consensus algorithm for building your own blockchain, based on its technical properties and limitations.
***
I will assume that the blockchain is designed for fairly complex transactions. All considered solutions are suitable for working with code hosted on the blockchain.
I deliberately did not include in the list solutions that are in the early stages of development, are unknown to a wide range of programmers or do not have important mechanisms to ensure the secure operation of the blockchain: they are unstable to the Byzantine behavior of nodes (non-BFT) or can be successfully attacked from a single account. Without these properties, the blockchain has no value and becomes a slow, expensive and inconvenient database to use.
To decide whether to build a new system or use a ready-made solution, first of all, you need to decide on a consensus - the main algorithm that provides BFT properties to the blockchain.
Consesses: proof-of-work, proof-of-stake, proof-of-authority
First, let's look at the different types of consensus in terms of network launch and operation. Any BFT consensus in blockchains must satisfy at least two important properties of distributed systems: safety and liveness .
Safety ensures that the algorithm never arrives at the wrong consensus as long as the majority of nodes follow the protocol honestly, and liveness ensures that the algorithm never gets stuck with no choice of path.
These properties must be guaranteed to be fulfilled when there are byzantine members in the network that intentionally act in the worst way.
Proof-of-work (PoW)
The advantage of this type of consensus is that there is no need to register validators with the network. Any block that meets the requirements is accepted without confirmation from other participants. This allows you to leave only a part of the logic responsible for changing the mining difficulty.
In theory, this kind of consensus allows any number of validators - after all, as many validators as you want can compete for a block. In real networks, if there are many validators (miners), and the complexity of the network is high, then the chances of receiving a block reward from an individual miner are extremely small. For such a consensus, it is necessary to immediately plan the operation of mining pools that combine mining capacities and the corresponding software.
At the start of the network, validators must immediately set serious computing power. This is often overlooked, hoping for a gradual increase in the complexity of the network and the number of miners. A low hash rate opens the door to inexpensive 51% attacks, when an attacker leases a lot of servers for a very short time to get 51% of the network hash rate and conducts a double spend attack.
Therefore, a PoW network will have to plan a more complex startup procedure. First, the team launches a network with its own validators, and then gradually "yields" the production of blocks to miners, who in this case can gradually increase capacity.
Proof-of-authority (PoA)
PoA consensus is algorithms that use a pre-assigned set of accounts that can produce blocks and vote to accept and exclude new members. This kind of consensus is a natural choice for enterprise blockchains and testnets. There may not be an internal token here at all, and when voting for blocks and when electing validators, 1 validator = 1 vote.
This family of algorithms is represented by the fundamental pBFT algorithm . In a modified form, it is the basis for a large number of consensus, allowing you to agree on any data with all security guarantees.
I mentioned earlier that there is no guaranteed safe consensus that requires less than 2/3 + 1 messages from validators. pBFT proves this mathematically. In different consensus, these messages confirming that the validator accepts the block are collected at different points in time.
The process of collecting confirmations and further recognition of the block as final received a separate name for finalization. Blocks on which a general consensus is reached are called final. To reduce the number of messages in terms of algorithms, finality is achieved not on all blocks, but only on some that "certify" several blocks at once. Thus, the number of messages between validators is greatly reduced and consensus is significantly accelerated.
Due to the separation of block validation and finalization procedures, there is some confusion that makes it difficult to estimate the speed of consensus.
For example, the pBFT algorithm used in the Tendermint (Cosmos) consensus requires consensus per block, i.e. instantly finalizes it, and the EOS algorithm finalizes only one of the many blocks, finalizing the chain immediately.
Aura, a popular algorithm for Ethereum-based POA networks, uses pseudo-random selection of a validator for each block and concurrently negotiates finalized blocks using the GRANDPA algorithm, expecting> 2/3 of the signatures-confirmations from other validators. This parallel finalization algorithm is called the finality gadget.
The EOS consensus works in a similar way, creating a "schedule" for validators for a certain period of time (epoch) and requiring blocks to be finalized at the end of each epoch.
Proof-of-stake (PoS)
Almost all existing implementations of these algorithms include algorithms from POA consensus, which adds to the confusion. Modern PoS algorithms work as follows: using the balances of the validators (stakes) participating in the elections, a list of validators is formed (for example, by voting, freezing deposits, etc.). For some time, until the list of validators is changed, the network works using a PoA algorithm, for example pBFT.
The most common algorithms are called Delegated Proof-of-Stake (DPoS), where accounts on the network vote in various ways with their balances for validators, forming a top of N validators.
When choosing consensus for your blockchain, you should first consider the block finalization process. The time after which the client will receive confirmation of his transactions will depend on it. Tokenomics, the procedure for "selecting" validators, and receiving block rewards are best considered separately. In this part, a large number of different economic mechanisms can be applied.
Note that corporate networks should not neglect economic mechanisms and PoS algorithms, even if there is no economy and no token in the network. Any free transactions are almost always an attack vector on the system from a single account. The presence of the balance of the "technical" token on the account can serve as a convenient limiter when the attacker simply does not have enough funds for a full-scale attack, and will also allow more flexible regulation of access and network load.
Implementation options
When planning your blockchain, you need to understand whether it is possible to use a ready-made solution or whether it is worth creating everything from scratch, fully controlling the code.
Blockchain is an open source world. Closed code is almost impossible in it - cryptographic protocols have long been created at open international competitions, and few people trust closed-source implementations because of the high risks.
Use what programmers have created before you. It is extremely likely that your tasks have already been solved, discussed and tested, so you should not spend extra effort on them.
If you decide to make your own consensus related to network interaction, or you use new cryptographic concepts that architecturally do not fit into the traditional design of blockchains; if you are going to bypass all the existing performance solutions, saving every bit; if the transactions in your blockchain are so specific that nothing like this exists in the world ... Then your way is a blockchain from scratch.
