Alternative Blockchain Consensus Mechanisms

Mechanisms other than proof of work and proof of stake

A blockchain consensus mechanism is the protocol used to agree on the “truth” when the blockchain is receiving data from many independent nodes that may be faulty or otherwise untruthful. There exist many different types of consensus mechanisms used in distributed systems, but we will focus on some well-known ones used for blockchains. In the context of adding to a blockchain’s distributed ledger, a simple way to think of the different kinds of mechanisms is by separating them by what participants may sacrifice in order to contribute.

The two most common consensus mechanisms are proof of work and proof of stake. In proof of work, a network participants sacrifices computational work in order to participate in the network; bad actors are discouraged by the extreme amount of computation required to attack the network. In proof of stake, participants pledge tokens holding monetary value on the validity of their choice of chain; ideally, bad actors are discouraged by a monetary penalty (loss of tokens) for bad behavior. Besides these two protocols, there exist others that are less common. These provide unique perspectives that do not necessarily fall on the proof of work — proof of stake spectrum.

Proof of burn

Proof of burn is somewhat similar to proof of stake in the sense that they both use a system based on monetary cost to achieve consensus. However, while proof of stake only results in losses for bad actors in the network, proof of burn requires all participants, truthful or not, to sacrifice tokens. In order to mine a block, the miner must send tokens to a “burner” address that cannot send tokens — these tokens are thus “burned” in the sense that they are no longer in circulation and are inaccessible. Generally, the more coins that a user burns, the more likely they are to mine the next block. So, as more and more miners want to mine, one would need to consistently burn more and more tokens to stay competitive as your initial burnt amount declines in proportion. This burning mechanism may also be used to switch from one token to another (for example, by burning token X and having mining rewards be in token Y). Proof of burn has many of the same criticisms as proof of stake — that consensus is determined by the richest nodes in the network.

You can go here for a more in-depth explanation.

Proof of capacity

Proof of capacity is similar to proof of work, but uses storage instead of computation. First, your hard drive is plotted, in which a very slow hash function is computed and stored. In the process, you fill your hard drives with nonces, or groups of the precomputed hashes, and each nonce contains 4096 pairs, or scoops. Then, when mining, you compute a deadline time from a specific scoop number for each nonce on your hard drive. This deadline time represents the time you must wait to mine another block after the last block on the network has been mined. Finally, you pick your lowest deadline time, and you can then mine a block if no one has mined a block within that amount of time after the last block. Proof of capacity presents an environmentally-friendly alternative to proof of work, and is less vulnerable to specialized hardware allowing mining groups to centralize the network. Although a mining group could still outspend miners and hoard storage, it is unlikely they will be able to obtain the storage at a price that is significantly different from the price that the average person would pay. This contrasts with ASIC miners that are 1,000x+ more effective than a high-end CPU at similar prices.

You can go here for a more in-depth explanation.

Proof of elapsed time

In proof of elapsed time, you are given a random amount of time to wait, and the first person to be done waiting gets to determine the next block. The lottery-like selection is accomplished using Intel SGX, which allows applications to run trusted code in a protected environment; this ensures that the wait times are created fairly and that the participants actually wait the required amount of time. Trusted code can be verified using specialized hardware and is separated from the rest of the application, so it can be proved that a network participant is running the correct code. Proof of elapsed time does not require any valuable token or specialized equipment, so it supports very large, decentralized networks where virtually anyone can participate. However, it is reliant on the company that creates the architecture that executes the “trusted code”, which in this case, is Intel. This may result in centralization as a single company is responsible for making and distributing the equipment used in the network.

You can go here for a more in-depth explanation.

Bonus: Hashgraph Protocol

This is a new distributed ledger technology that is not implemented using a blockchain, but it uses an interesting consensus mechanism, so I decided to add it here anyway. Broadly, Hashgraph uses a gossip protocol to spread information throughout the network, and a virtual voting mechanism to achieve consensus. Each node forwards information on new transactions, transactions witnessed by others, to a random set of nodes that are its neighbors. These neighbors do the same, and spread information to their neighbors. Each node maintains its own copy of the Hashgraph, which is stored as a directed graph representing sequences of forwarders and witnesses for each transaction. With this gossip protocol, information can travel very quickly, allowing the network to very quickly become synced-up on new information. In order to create consensus, the network uses virtual voting. Since each node can determine what information other nodes have, they can determine what another node’s “vote” would be without actually having a formal vote. This follows from the fact that any node can view the world from the perspective of any other node, since it has access to an ordered history of that node’s received information. Each node can determine if a given set of information or transactions is valid by checking if at least two-thirds of the network’s nodes have witnessed this transaction (and would therefore have voted for it).

You can go here for a more in-depth explanation.

Make sure you give this post 50 claps and follow me if you enjoyed this post and want to see more!

Devin Soni — Medium_Read writing from Devin Soni on Medium. crypto markets, data science ☞ twitter @devin_soni ☞ website…_medium.com

You can also follow me on Twitter!

Devin Soni (@devin_soni) | Twitter_The latest Tweets from Devin Soni (@devin_soni). https://t.co/Q3YFB0nWiL_twitter.com