Consensus

Bob could point to Alice’s transaction twice. First by saying that Chris is allowed to spend this coin and second by saying Deborah is allowed to spend this coin.

This means, the network somehow needs to figure out, which transaction is actually the right one. This brings us to the topic consensus.

If Bob creates two rivaling transactions like above, the network needs to decide which transaction is valid and which one is ignored. Therefore, we create a data structure called blockchain.

There are two questions to answer. First, who is allowed to create a block and how are changes in the once created blocks are avoided?

We answer the second question first. If we make even a tiny change to the transaction data, the resulting hash changes completely. This comes from the property of our hash function. How can we apply this to our advantage? We can build a chain of blocks that are connected. Therefore we take the hash of the previous block into our block header of the following block and use it as part of the input in our hash function. It looks like this:

---

So, what would happen, if someone changes the data in block 1?

• The data in the block change and with it the input to our hash function.
• The block hash of block one changes subsequently.
• This would mean that the block header in block 2 changes and
• with it the block hash of block 2.

The link between block 0 and 1 would be broken if block 1 doesn’t get updated. So, this is an easy way to detect changes in the data structure.

In this data structure block 1 points to block 0 by referencing its block hash. And block two would point to block one by using its block hash and so forth. That’s why we call this hash pointer. Usually, it is depicted like this:

And now we say that a transaction is only allowed to reference a transaction that is part of a previous block. Do you remember the section where we said that Debora checks if Chris was allowed to spend Bob’s coin, and Bob was allowed to spend Alice’s coin? That’s the same thing.

Let’s assume Alice created a transaction where she sent a coin to Bob (more precisely his address). Bob can now only spend this coin if Alice’s transaction is in a block that is part of the chain. If it is not in such a block all other nodes would ignore Bob’s transaction to Chris, because they would say that Bob doesn’t own this coin.

But this is only the first step to solving the double-spending problem.

Bob could actually create two chains. One chain with his transaction to Chris and one chain with his transaction to Deborah. Both chains would be actually “technically correct”. Basically, everybody could in this setup create its own chain. So, if anyone can add blocks whenever he likes this leads to no consensus as it is easy to imagine. That’s why we have to restrict adding blocks in some way.

We do this by granting the right to add a block to different users. Ideally, this selection process should choose every time another “block producer” and it should be a random choice. If it could be influenced by the users, some might abuse this. And here our consensus mechanism Proof of Work enters the stage.