Focus: Blockchain Validation vs Consensus, Explained by BitSong

Written by BitSong

How Are Blockchain Transactions Validated? Is it done via the Consensus Method? Or does a Blockchain Validator Do It?

“Consensus” is a key aspect in blockchain. It’s imperative that all participants in the network come to an agreement on the state of the ledger.

But what exactly are we trying to achieve consensus on? Are we simply trying to agree that each transaction is “valid”? Or is it more than that? We believe that this is where a lot of people steer the wrong way.

Blockchain Validators
​A Blockchain Validator is someone who is responsible for verifying transactions within a blockchain. In the Bitcoin Blockchain, any participant can be a blockchain validator by running a full-node. However, the primary incentive to run a full node is that it increases security. Unfortunately, since this is an intangible incentive, it is not enough to prompt someone to run a full node. As such, Blockchain Validators comprise primarily of miners and mining pools that run full nodes.

Blockchain Validation Explained
Blockchain Validation vs Blockchain Consensus
It’s important to note that “validation” and “consensus” aren’t the same thing. A Blockchain Validator performs validation by verifying that transactions are legal (not malicious, double spends etc).

However, Consensus involves determining the ordering of events in the blockchain — and coming to agreement on that order.

Essentially, Consensus involves agreeing on the ordering of validated transactions.

The validation precedes the Consensus. We may very well have something that is “valid” that the network does not “agree” upon. How? Let’s go over an example.

Validation Without Consensus

How Are Blockchain Transactions Validated?

Each time a transaction is made, it’s broadcasted to the entire network. Upon hearing the broadcasts, miners take a bunch of transactions, validate that they are “legitimate” — and put them into a block. (More on how in another post)
But miners “hear” about different transactions at different times (due to latency issues etc). Furthermore, they may simply choose different transactions to include in their block based on transaction fees. So essentially, each miner is building his own block. His block may be completely different from the rest of the miners in the network.
At this point, you’re probably thinking:
“What the hell? Everyone is building different blocks? Then how will we agree upon a single common ledger!?”

And that’s one of the beautiful things about the protocol. Miners don’t need to build the same global block. They can each build their own block — consisting of entirely different transactions. And the participants will come to “consensus” on which block is included next.
A miner may have a block consisting of completely valid transactions, but his block may still fail to achieve consensus by the network. If someone else is picked, he will simply create a new block and try again.

Let’s run through a simplified example of two miners with different blocks.

A Simple Bitcoin Transaction Example
Miner Roger & Miner Andy

Let’s say Roger and Andy are two miners on our network. Neither of them are up to any mischief. They are listening to the network and creating blocks with only valid transactions that have not already been spent.

Miner Roger creates a block consisting of “Transaction A , Transaction B, Transaction C”
Miner Andy creates a block consisting of “Transaction Z, Transaction Y, Transaction B”
Both of these blocks consist of valid transactions. Great. But we still need to come to “consensus” on who’s block to include onto the chain. Remember, a reward is given out to whoever gets to add their block to the chain. So should Roger get it? Or should Andy? How about both of them?

Adding both of them would be ideal, right? They both get rewards. And all the transactions get included onto the chain. Everybody wins! — But wait…Note that they both contain “Transaction B” in their blocks.

Let’s suppose that Transaction B is — “Serena pays 10 bitcoin to Venus”

If we let Roger and Andy both include their blocks, Serena will end up paying Venus 20 bitcoins (two transactions of 10 btc each) when she intended to pay her only 10! Furthermore, Serena may only have 10 bitcoin — so the second payment would be invalid.

As you can see, we can add only one of the blocks. And we need to agree upon which one. But how do we do that?
This is where consensus methods like “Proof Of Work” or “Proof Of Stake” comes into play — Enter Consensus Methods

Using Proof of Work (PoW) for Picking Blocks
Miner Roger and Miner Andy both want their blocks included in the chain — they both want the reward. But only one of them can be picked. To “win” the right to include their block, they go through a consensus process — usually either “Proof Of Work” or “Proof Of Stake”

In Proof Of Work, Miner Roger and Miner Andy compete against each other to solve a cryptographic puzzle. Whoever solves it first, gets to add their block to the chain.

Food For Thought: What if they solve it at the same time — or around the same time? That’s how a ‘fork’ can occur. And the bitcoin protocol resolves these occurrences as well. More on that later

Using Proof Of Stake (PoS) for Picking Blocks
Proof Of Stake involves Roger and Andy putting up their coins into a “jar”. A coin is randomly picked from the jar. If it belongs to Roger, Roger gets to add his block. If it belongs to Andy, Andy gets to add his block instead.

Once the block is added, the process repeats. Both miners will listen to the network for pending transactions and create a new block. The competition goes on and on.

(Don’t worry, miners aren’t trying to solve the PoW puzzles themselves. Their computers are doing most of the work)

There are two types of widely known POS — Delegated Proof Of Stake (dPoS) and Leasing Proof Of Stake (LPoS). dPoS allows for participants to vote for a delegate that will maintain the integrity of the system. LPoS is similar but allows for participants to lease out their coins in order to share in the rewards of verifying a block.

In BitSong, we have choosen Tendermint, which is a software for securely and consistently replicating an application on many machines. By securely, we mean that Tendermint works even if up to 1/3 of machines fail in arbitrary ways. By consistently, we mean that every non-faulty machine sees the same transaction log and computes the same state. Secure and consistent replication is a fundamental problem in distributed systems; it plays a critical role in the fault tolerance of a broad range of applications, from currencies, to elections, to infrastructure orchestration, and beyond.

Wrapping Up — Blockchain Validators vs Miners
As you can see, Consensus methods are primarily concerned with coming to an agreement on the ordering of events/transactions (and who gets to add them). Validation of the transactions is initially handled by the miner before they are added to the block. And then once more by the rest of the Blockchain Validators when a block winner is picked. The miners add the block, and the Blockchain Validators verify that the block is valid. If Consensus is reached, then the network successfully moves on to the next block.

BitSong’s Blockchain Validators minimum requirements:

– 500.000–1.000.000 BTST (Testnet Coin)
— Cloud Server
— Great server-level hardware
In any case, you can find all the requirements and features of our Blockchain at the following link: http://docs.bitsong.network/

For more info, feel free to contact Iulian Anghelin