Consensus or Consensus-es
Terminology in the blockchain sphere is way off point.
I already wrote about “smart” contracts which are in no way smart, and about how they should be broken up into at least three different parts: programming controllers, digital agreements and smart laws (digital normative standards).
And I already wrote about decentralisation, which is constantly confused with distribution. And about the decentralisation of decentralisation infighting: there is the technological infighting (about nodes and data); there is consensus infighting (about who has the right to form blocks); and then there is the control infighting (about who really controls the network). For example, in the Bitcoin network, each full node holds the full transaction database and has the right to form blocks, meaning that, on face value, there is fully technological and consensus based decentralisation, but with the real power concentrated in the hands of a few Chinese mining farms. That’s decentralisation for you!
Now I want to talk about consensus: if we look at how a blockchain network works, at all the procedures, actions and operations that can take place in the network, then we must acknowledge that we aren’t talking about one specific consensus — whatever you want to call yours — but about at least four different ones.
The first type of consensus — and here we’re talking about PoW and PoS — is the choice of node which generates the block. This type of consensus applies to public networks with a flexible number of full nodes.
The second type of consensus is necessary for public networks with a fixed amount of validating nodes and is about the voting for the right to become such a node, such is DPoS.
The third type of consensus is about how the network transactions are validated. In essence, the nodes (all or part of them) need to come to an agreement about whether a new transaction is valid before it gets packaged into a block. However, since this takes up a lot of resources, in public networks this verification is done by just one node which forms the block, and the others check the transaction after it has already become part of a new block, and then they either accept it or reject the block in its entirety. What makes forks happen is the forming of several chain in a blockchain. This is where the real voting takes place, with the winner being the longest chain. The nodes which supported the losing chain should then switch back to the chain supported by the majority. In private blockchains where there is a need for strict node synchronisation (meaning no chance for forks), it makes sense to come to a consensus about transaction validity before forming blocks.
The fourth type of consensus is needed for networks in which user programming clients (not supporting full nodes) should receive data from the network. In this case, we need a confirmation of the validity of data received from at least three full nodes.
And so it turns out that when answering the question “what consensus do you have?” there cannot be an unambiguous answer. One thing to bear mind is what we are actually talking about: voting for the right to be a validating node; priority in the generation of blocks by nodes; validation of new network transactions; or verifying data from outside the network.
Alexander is a philosopher, analyst, and member of the Association of Russian Futurologists. His primary areas of interest and research are: global evolutionism, temporal ontology, philosophy of artificial intelligence, and futurology. In recent years, he has worked on the creation of a subject-event approach to complex systems modelling.
Blockchain Business Review from Apla provides high-quality educational material from the world of blockchain to inform the business community of the competitive advantage that can be gained by integrating distributed ledger data storage within organizations. Our mission is to promote knowledge about blockchain and its uses in both the private and public sector and demonstrate the value of blockchain integration.
