March 28, 2020

Recreating Bitcoin 16:Block chain

Epilogue #

Bitcoin in its peer-to-peer architecture has realized the synchronization of transactions and ledger. Although the synchronization of the ledger still relied on a centralized Timestamp Server, we will leave it for now and shift focus to a new idea Gilfoyle just came up with: the dissection of the ledger.

“Out-of-Control” Improvisation #

Gilfoyle was waiting for Satoshi when he came into the store. Before he even sat down, Satoshi started talking to Gilfoyle, “Come on, let’s continue to discuss the idea of dissecting the ledger you mentioned yesterday.”

“Well, wait for me to have a cup of coffee.”

Boss Bob brought the coffee over: “Recently, you two brothers have been drinking coffee quite a bit. Got inspiration? Hurry up and upgrade, let Bitcoin go online soon!”

Satoshi said: “Ok, we are working hard! It is almost done!”

Although he said that it was almost finished, he didn’t have a clue how it’d go.

This time, the evolution of the system can be described as the qualitative change of Bitcoin, like that of the transformation of the clock system into a complex system.

Satoshi and Gilfoyle are like two explorers, moving through a primeval jungle without a map. Everything has to be chosen impromptu, depending on the situation. Neither could predict if the next step would lead somewhere.

The experience is like free solo climbing on a cliff, with only subtle control over the body, like a gecko attached to a mirrored wall, tasting the edge of life and death, that is the true feeling alive.

To be or not to be that is a question

Kill Two Birds with One Stone #

Knowing that the network had been offline for a while, Satoshi understood that he had to press on, despite the fact that he had no idea what he was doing. He and Gilfoyle were like two jungle adventurers, moving through the forest without a map, forging a path as they went.

“As I was saying, currently the ledger is a big file: transaction.txt. Broadcasting it throughout the network was computationally expensive. We could dissect the file into multiple smaller files, as in pages in a book, connected to each other through their page numbers. This way, every broadcast only updates the latest page in the ledger,” Gilfoyle continued.

“But I came back yesterday with a new understanding.”

“What is the nature of a ledger?”

“The essence of a ledger is the sum of past transaction data in the system.
So the ledger represent the past of the system.”

“The data in the memory pool is the real-time behavior of the system, so the memory pool represents the present of the system.”

“To write this action into the ledger essentially is backing up the data.”

“Since the entire network is dependent on this data backup, the node with ledger-writing authority is heavily responsible. In this ten-minute period, it carries the state of the system.”

“At the same time, the act of writing into the ledger should also be recorded in the system, so that the ledger writer can be held accountable. Of course, in addition to accountability, the ledger writer can also receive some benefits, such as to give the ledger writer several Bitcoins as a reward. It all depends on the record.”

“So where is the record?” Satoshi asked.

“The design idea of the traditional system is to write the ledger-writing behavior into a log file independently, and the log file is associated with the ledger.”

“But I had a sudden realization last night: we can dissect the ledger into different pieces to achieve the record of ledge-writing behavior.”

In other words, ledger dissection kills two birds with one stone.

The first bird: it can avoid the resource waste of full data transmission.

The Second bird: we can target the accountability and rewards associated with ledger-writing.

Connecting the Ledger “Pages” #

“That’s a brilliant idea! So how do we connect these ‘pages’ of the ledger?” Satoshi was very happy with the idea.

Gilfoyle went in-depth into the solution:

We call each page of the ledger a “Block”: a physically independent file called block.txt.

Every Block contains specific transactions. We abstract these transactions into what we call “Items” (see graph below).

A block

What we want to do is to connect these blocks in chronological order like pearls into a necklace. We call this series of connected blocks a “Chain.”

How do we connect the blocks? #

Naturally, the first thought would be to assign the ID of the previous block to the beginning of the current block file. That way, each block is connected to the previous block all the way up to the first-ever block: META-BLOCK.

How do we get a unique Block ID? #

This brings us back to a previous concept: Hash.

The Hash algorithm is a publicly available algorithm that anyone can use in any programming language. Any data as a parameter that is run through the function produces a unique Hash Value. In the case of Block ID, the formula looks like this: HashID = FuncHash (Block).

HashID can be regarded as the unique coordinate of chunk of data in the universe, or as the unique id number in the universe, or as the unique fingerprint of the data.

In addition, Hash function goes only in one direction. What dose that mean?

That means we can only derive HashID from the data, we can’t derive

HashID from the data.

It’s like we can’t create a body from a person’s fingerprint. But if this person is standing in front of us, we can get his fingerprint instantly by Hash function. So, a person can be verified by anyone as to whether or not a fingerprint belongs to him. For example, the person has his or her fingerprints on a property contract so that the house is connected to the person’s entity. Because fingerprints can map the universe to unique individuals. Therefore, in the world of character symbols, fingerprint is the equivalent agent of entity in law.

So this gives the HashID associated with an entity a unique legal equivalent to what it represents.

Now let’s take a look at how to implement all this.

Steps to Construct a Block chain:

A full node gets the ledger-writing task
The node uses the Hash function to calculate the previous block’s HashID. Specifically, it takes in the file of the previous block (Block1.txt for example) and puts it in the function to get the HashID.
The node creates a new block file (Block2.txt) and wrote the HashID from the last step into the current block file (Block2.txt).
The node adds in the transaction data starting at the second line in the file.
After all transactions are recorded, the current block is broadcasted to the whole network.

Through rotating the ledger-writing task, the network constructs a Block chain (see graph below).

Block chain

Block Reward #

Satoshi shouted, “Brilliant! Now let’s talk about ‘the second bird’, where we record the ledger-writing itself.”

“We can borrow it from accounting system in the real world,” Gilfoyle said.

In accounting, every page in the ledger is separated into two parts:

Usually, the top half of the page reserves room to record the ledger writer’s name and the writing time, as well as the stamp.

In the bottom half of the page is service data.

We can design the Block file in a similar way:

The first part is called the Block Header, created to record non-service data: system data.

The second part is called the Transactions, created to record transactions records (see graph below).

Block

Gilfoyle said, “Transaction data are all very similar. They are just transaction records. The data in the Header still needs some work. What kind of data do we put in there?”

Satoshi said, “We put in there HashID from the previous Block.”

Gilfoyle responded, “Yes, as long as it’s non-transaction data, we can put in the Header.”

Satoshi said, “And also the transaction-related data such as transaction time, and the Node IP.” (note: note: the real world Bitcoin does not have Node IP)

Gilfoyle said, “That’s right. I’m also thinking, how to describe the reward for the for the ledger-writer.”

If there is a reward mechanism in place, then the Bitcoin network could attract more nodes to join and Bitcoin could become a “perpetual machine.”

Satoshi said, “This is exactly what Bob was asking me about. The benefit of running a node on the network would be rewards in Bitcoin.”

So how do nodes receive Bitcoin?

Right now only IP addresses represent the identity of the nodes, but only public addresses could receive Bitcoin.

Satoshi suddenly had an idea, “If we let every node have their own public address and create a transaction record to transfer 50 Bitcoins to itself for every ledger-writing period. The problem is solved.”

“Absolutely. Not only does this solve the reward issue, but also the issuance of new Bitcoin. Classic killing two birds with one stone, again!” Gilfoyle concurred with Satoshi.

Satoshi said, “Yes, we have had a lot of luck today!”

This way, the minting of Bitcoin would no longer depend on the locked-in code in Satoshi’s address. With the block reward feature, the discovery of coins evolved from single point to distributed.

“So how do we associate a node with a public key address?” Gilfoyle asked.

“We add a setup file in the code so that the deployer of the node can manually insert into their public key address before deploying the code. After the launch, the node will treat the address as its own,” Satoshi said after some thought.

“And do we add this particular transaction into the Block Header?” Gilfoyle followed up.

“I’m not that comfortable with writing it in the Header,” said Satoshi.

“Although it is a reward, it’s essentially still a transaction, which belongs to service data and therefore in the transactions section.”

Satoshi continued, “Now, what we can do is to create a 50 Bitcoin block reward transaction to the node’s public key upfront in the transactions section.”

(Note: the 21,000,000 Bitcoin limit and the halfings of block reward won’t be discussed in this book, as many of the readers should already be familiar. It is highly recommended to look them up if you are not familiar with the concepts.)

“Hm. This sounds very good. Another thing is that the transaction fees should also go to the node. Otherwise, the Bitcoin transaction fee payments will be lost forever and we can see the loss in the total circulation,” Gilfoyle added.

“That’s a great mention. We should also include the transaction fees in that first transaction together with the 50 Bitcoins,” Satoshi said.

Specifically, the texts in the block is shown in the graph below.

Block texts

The Header part:

Previous Block Hash.
Time: Timestamp for ledger-writing.
IP: IP of node (note: the real world Bitcoin does not have this field)

The Transactions:

The first transaction is a block award. The transaction record does not refer to the past UTXO, but adds a field COINBASE in the in section to indicate that the UTXO is a coin created out of nothing.
After article two, it is the normal transaction record.

Epilogue #

We finally introduced the concept of Block chain in this chapter. We can see that so far into the Bitcoin journey, the concept of block chain is but a small part in the whole design.

Precisely because of the dissection of the ledger, we have the opportunity to reward ledger-writing actions. This feature will encourage more nodes to join. However, as we shall discover, malicious acts will become a new issue because of the joining of these new nodes.

Next chapter ：Recreating Bitcoin 17:Network Flexibility