March 28, 2020

Recreating Bitcoin 15:Synchronizing Ledger

Epilogue #

The previous chapter described the synchronization of transactions, but we also need to consider the synchronization of the ledger.

The transaction memory pool represents the present of the system. The account model represented the system’s past.

Three Nodes #

At the café, Bob brought over the computer to Satoshi. Satoshi took over the computer in his arms and thanked him.

Now there are three computers on the table. Due to the lack of space on the table, the third machine is stacked on top of the other two. It looks like a pyramid.

Satoshi said to Gilfoyle, “The existing two nodes are already providing the ledger service. Now let’s connect the third node to the network.”

“Yeah, but I feel that there’s going to a high probability that errors will occur. Let’s test it first and see,” said Gilfoyle.

Satoshi set up the IP for Node 3, deployed the code and restarted the computer. Node 3 successfully connected to Node 1 and Node 2 and started to synchronize the transactions (see graph below).

Node 3 joins the accounting network and starts syncing transactions

After a while, Satoshi discovered a problem, “I forgot that syncing the ledger would be necessary in the case for Node 3, because new nodes have a totally empty ledger.”

He changed the code and redeployed it. The node is relaunched (see graph below).

The synchronization of the ledger lacks transactions in the memory pool

Node 3 completed the synchronization of Node 3.

After a while, Satoshi found out another problem: Node 3 was missing two transaction records. The problem was when Node 3 joined the network, Node 1 and Node 3 had previously already synchronized these two transactions: “Alice to Bob 50” and “Carol to Alice 30.” However, these two transactions were not yet entered into the ledger, which meant that even if Node 3 received the latest ledger, it would not contain these two transaction records.

This is analogous to when a student is late for class, he tries to borrow the notes from the fellow classmate, but his classmate is still processing some information in his head and doesn’t have all the notes written down yet. The student doesn’t care, so he just copies whatever notes his classmate has.

But at the same time, the teacher has started talking about new stuff, so the student has missed the middle and only caught up with the beginning and now had to move on to the new stuff.

The solution to that classroom setting is simple: we let the student wait for his classmate to finish the notes and only start copying it after everything has been written down.

Although in a realistic setting, the solution seems reasonable, it would not meet the airtight standard in a network environment.

Because Node 3 is not confident enough about its own ledger, it wants to find Node 1 to synchronize the ledger for the second time.

But how can Node 1 ensure that its book is perfect? It is possible that Node 1 has experienced issues before and and missed a few transactions.

Therefore, depending on Node 1 would make the system too fragile.

What’s the solution?

Decentralizing the Ledger-Writing (Billing) Authority #

Conventional clockwork systems could withstand imperfections in secondary components, but the center core must be flawless as it is the single point of reliability in the centralized system.

But swarm systems are not threatened by individual imperfections. Perfection in swam systems is achieved through individual collaboration.

Satoshi said, “Since each Node is not sufficiently confident in its ledger, we rotate them to keep the ledger in turn.”

Ten minutes would be a period. The ledger keeping authority rotates to another node every single period. This node then stores the transactions in its mempool in the ledger and broadcasts its ledger to other nodes. Other nodes trust the ledger they received and replace their previous ledger with the new one. At the same time, they compare and contrast the old and new ledgers to delete duplicates, so that in the mempool only transactions that other nodes don’t have would be left. This creates a complementary ledger keeping feature to ensure the distributed ledger’s integrity.

This is the power of the swarm system: very high fault tolerance (see graph below).

Rotation of the ledger-writing assignment

Gilfoyle asked, “How do we implement the random rotation assignment? One thing about the assignment is that the network shouldn’t depend on one point to fulfill the task either. We need to think about that too.”

Timestamp Server #

“That’s indeed a challenge. It’s a very open trap. But let’s add one single point to the assignment before we come up with a solution so that the system could normally operate. We will replace it with a new plan later,” Satoshi said.

A simple way to add the one point for the rotation assignment is to deploy one additional point of service, which randomly chooses a node every ten minutes and notifies the node to keep the ledger, and then the node would broadcast the ledger to the network.

Since this single point acts similarly to a timekeeper, that’s one tick in every ten minutes (assigns the task every ten minutes), so we name it the
Timestamp Server (see graph below).

Adding a new single point for rotation task assignment

The logic behind the Timestamp Server code was very simple. Satoshi finished the program quickly, but he still needed a server.

Satoshi moved his eyes on Bob again, “Boss, we have a new tentative plan, and it requires one more server. I see there’s a computer on the counter that’s rarely used. You think I can deploy a program on it? It’s a very small program. Shouldn’t affect its running at all.”

Bob said, “well, that doesn’t stop me from using it.”

Like that, Satoshi deployed the temporary program on the computer and locked in the IPs of the three nodes in the server.

After the launch of the program, it connected to the three nodes and notified one of them every ten minutes for ledger-writing.

Satoshi soon noticed that the two missing transactions were recovered. This way, the accounting network started operating normally and was able to synchronize both transactions and the ledger.

Dissecting the Ledger #

Gilfoyle said, “There’s one area we can improve: dissecting the ledger. Since the ledger is broadcasted frequently in the network, we can dissect it into one page after another, every ten minutes producing a new page in the ledger. That way, only one page of the ledger needs to be synchronized every ten minutes. We’d end up saving a lot of resources.”

“That’s a great idea. Right now, syncing uses a lot of computing power. But let’s wrap it up today and talk about this more tomorrow.”

“We’ll also work on the rotation assignment solution tomorrow. The tentative plan now doesn’t look good,” added Gilfoyle.