[ad_1]
There are many ways to reach consensus and different methods are used on different blockchains. A very successful consensus algorithm is known as Proof of Stake. In this text, I’ll cover how proof-of-stake works, potential challenges it faces, and who is using it.
Proof-of-stake is a consensus algorithm that seeks to reach consensus by voting for those who participate. Stake, in this case, means those who make the biggest investment in a positive outcome for this system. These users are considered the most likely to vote to make a positive impact or improve the system. How does proof of participation work?
In the proof of participation consensus protocol, there are no miners. Instead, there are validators. These validators do not need to invest in computing equipment to mine the blocks that create coins because all coins exist from the start. Instead, the purpose of these validators, also known as stakeholders, is to determine which block goes into the blockchain.
To validate transactions and create blocks, validators place their own coins as a bet. You can think of it as if they were making a bet. If they validate a fraudulent transaction, they lose their possessions as well as their right to participate as a validator in the future. In theory, this check encourages the system to validate only true transactions.
In proof of bet, the greater the fraction of the total coins a validator has, the greater the chances of being chosen to create the next block because they have a higher bet. A validator node with 400 coins will be four times as likely to be chosen compared to a node that has only 100 coins. If a validator block is added. The validator receives a coin proportional to the value of his bet.
With that said this begs the question, isn’t it possible for a bad acting validator not to lose anything by betting on multiple blocks so they always win in the end? Very good. You have stumbled upon what is referred to as the nothing at stake problem for proof of play.
There’s something about blockchains that I haven’t mentioned before, the possibility of this single chain forking. When a blockchain is extending under the proof-of-stake paradigm it is possible that a fork in the blockchain could accidentally occur.
For example, if some nodes receive information to add a block while others receive an update to add another block, or because there is a malicious attempt to rewrite history and roll back a transaction. In other words, if there are multiple competing block options, isn’t it possible for a bad acting validator to just place bets on all blocks so they always come out on top?
It is true. These are possibilities, but proof-of-stake advocates have strategies against these types of attacks. A strategy is a Slasher solution. Which implies penalizing validators if they simultaneously create blocks in several chains. Alternatively, some protocols use a strategy that punishes validators for creating blocks in the wrong chain. In this method, validators must be selective and conscientious about which blockchain they bet on. Who uses the proof of participation?
Ethereum has switched from proof-of-work, to proof-of-stake in a project codenamed casper. Digital Money, or Dash is one of the pioneers of the proof-of-stake algorithm. It is built on Bitcoin’s core platform, but with added privacy and fast transaction features like PrivateSend and InstantSend. There is also Lisk. Designed to allow developers to build their own decentralized apps. Similar in function to Ethereum or NEO, but allowing developers to use JavaScript. Lisk uses a custom form of proof-of-stake called delegated proof-of-stake. This just means that only the top 101 delegates can have memberships on the network, and those delegates are voted on continuously by the community. One Lisk equals one vote. Now, that ends the proof of participation. The next consensus method I will cover is Delegated Byzantine Fault Tolerance, DBFT for short.
Delegated Byzantine Fault Tolerance
In this section, I’ll try to cover another consensus algorithm, what’s known as the Delegated Byzantine Fault Tolerance. I’ll discuss how it works, potential challenges with it and who’s using it. The Delegated Byzantine Fault Tolerance or DBFT is a consensus algorithm based on assigning roles to different nodes to coordinate consensus. Now, how does the Byzantine Fault Tolerance work?
DBFT does not have miners. Instead, it has nodes that are split into ordinary nodes and consensus nodes. The majority of nodes in the network are just ordinary citizen nodes that can transfer or exchange assets but they don’t participate in validating blocks. Consensus nodes have the power to verify each block written to the blockchain. Consensus nodes act as a representative for the other nodes in the network, similar to how an elected government official would represent the majority of its constituents. For an ordinary node to become a consensus node, it usually needs to meet certain criteria which differ from platform to platform. So these may involve owning some special equipment, having dedicated internet connection or having a certain stake in the network.
Consensus nodes keep track of proposed blocks that could be added to the blockchain. When it’s time to decide which block should be added next, a consensus node is randomly selected from the pool of all consensus nodes. In the neo blockchain, this chosen node is called a speaker and all the other consensus nodes are called delegates.
The speaker creates a new block and proposes it to the delegates. Two-thirds of all the delegates need to prove this block before it’s passed. If it doesn’t pass, the chosen speaker returns to being a normal delegate and another speaker is chosen. This new speaker proposes their truth, which block should be added, and this block is put up to vote. If it passes, the new block is added to the blockchain. DBFT is said to be much faster than proof of work and it requires less resources because there are no complicated cryptographic puzzles to solve.
Additionally, it’s resistant to forking, because at any given moment, there’s only one version of truth. With that said, DBFT is not immune to problems. Let’s take a look at two potential scenarios. First, let’s assume there’s a dishonest speaker. There’s always a chance that the speaker who is randomly selected from the delegates could be dishonest or malfunction, and if this occurs, the network needs to rely on honest delegates to vote the proposed block down so it doesn’t reach the two-thirds approval rate. Since users of the protocol vote on delegates and the speaker is randomly selected from the group of delegates, it’s up to the users to find out which delegates are trustworthy and vote them into power.
Let’s take a look at our second scenario. It is up to users who vote on delegates to do their due diligence to only vote honest delegates into power so that dishonest delegates are in the minority. If a minority of delegates are dishonest, the honest majority can vote the block down and the block will make it into the blockchain. To help with this, some blockchain platforms release data about the honesty and functioning of each delegate for voters to review. So, who uses the Delegated Byzantine Fault Tolerance? Well, NEO has been one of the biggest advocates for this protocol. It is a blockchain platform in cryptocurrency designed to build a scalable network of decentralized applications. While proof of work and proof of stake are definitely the more popular choices, newer mechanisms continually pop up and prove themselves. Remember that a consensus algorithm gets its reputation from being safe for a long period of time. For example, Bitcoin has stayed a safe network since its inception in 2009. With that said, there is no perfect consensus mechanism and chances are there never will be, but it’s interesting to see newer blockchains coming up with their own mechanisms, and it’s equally interesting to understand their pros and cons.
New to trading? Try crypto trading bots or copy trading
[ad_2]
Source link