Taraxa Consensus (2/5): Block DAG and PoS
By: Steven Pu
Tags: Blockchain, Taraxa Tech, Consensus, Block Dag, Taraxa

No free lunch

It’s great to be inclusive and green, but there are no free lunches in this world, especially not in engineering. Let’s investigate some of the problems we run into while making these design decisions.

Problem #1: Ordering

In a single chain, there is no question of relative ordering between two blocks, since every block is on a linear order each with a clearly defined parent. In a block DAG, we are only sure about relative ordering between a certain subset of blocks, and unsure about others. This is called partial ordering, and in blockchain, that’s simply not acceptable.

Blue: clear relative ordering; Orange: ambiguous relative ordering

In the illustration above, we see that the blue blocks have clear relative ordering, since they are directly or indirectly connected. If block A is pointing to block B, that must mean block A knows about block B at the time of its construction, hence block B must have come before block A. However, in the same illustration, the orange blocks have ambiguous relative ordering, since there are no direct or indirect connections between them.

So now we end up with some of the blocks have clear relative ordering, while others do not.

May I cut in front of you?

But wait a minute, why is ordering so important to begin with? Ordering is important because often, when transactions on the blockchain are processed, processing these transactions in different order could produce very different outcomes. For example, suppose A currently has 1 coin, and we have the following three transactions,

A sends B 1 coin A sends C 1 coin D sends A 1 coin

Processing these transactions in a different order could produce very different outcomes, for example,

Order (1, 2, 3): transaction 1 succeeds, 2 fails since A now has no more money, 3 succeeds

since A now has no more money, 3 succeeds Order (2, 3, 1): transaction 2 succeeds, 3 succeeds, 1 succeeds

In blockchain, ordering is a critically important attribute that the network needs to agree on (see our blockchain primer article), hence having only partial ordering is not acceptable.

Problem #2: Randomness and Delay

By transitioning away from PoW, we lose all its associated functionalities. Here we highlight two of these functionalities: randomness and delay.

Randomness refers to PoW’s process of randomly selecting the next node to produce a block. There is of course no central entity “selecting” the node, it’s simply a matter of luck when and which node will be able to solve the puzzle first (given comparable hashing power).

Why is randomness important? Block producers need to be random because if they weren’t randomly selected and are well-known ahead of block production, they could be targeted for attacks, bribery, and other generally deleterious efforts. Moreover, the block producers themselves would have a heavy incentive to cheat or collude to their own advantage — e.g., inserting their own trades ahead of others, try to create a branch to double-spend. Hence, randomness help make the network fairer and more honest.

Delay refers to the fact that it takes time to solve a PoW puzzle, in BTC for example the average is set ~10 minutes. This delay controls how often blocks are created on the network. With this delay removed along with PoW, we now need to find another way to add in a delay.

But why do we need a delay at all? For one thing, no network can handle infinitely many blocks — each node will run out of bandwidth, or storage, or memory, or CPU — whichever is the first resource to create a bottleneck. There also aren’t an infinite number of transactions to be packed into infinitely number of blocks. The number of blocks produced by the network and the number of transactions contained in each block should be, ideally, adjusted dynamically per network conditions, but in no circumstance will you have a delay of zero.

Problem #3: Block Efficiency

Blocks are created by packing in transactions from a pending transaction queue

When a node is producing a block, it is deciding which transactions the network will process next. At any given time, each node on the network maintains a list of pending transactions which were sent to the network for processing but haven’t made it into a block yet. When a new block is being produced, a node looks at this pending transaction queue and selects a subset to place into the block. Different networks have over time evolved different conventions on how transactions are selected, most of which are driven by economic incentives.

At any given moment, if there aren’t serious problems with the network or its nodes, then each full node on the network should see very similar pending transaction queues. This is because a blockchain system is a peer to peer (P2P) network, whereby critical information such as transactions and blocks are being constantly circulated (gossiped) to every node on the network with typically very short delays (seconds). Hence, between any two given nodes, there may be a few transactions that one has heard about that the other one hasn’t, and vice versa, they should have largely heard about the same set of transactions, with each building very similar pending transaction queues.

If every node sees relatively the same set of pending transactions, then if they were asked to produce blocks, they will produce blocks that contain relatively the same set of transactions, or similar copies of each other. This is obviously not a desirable outcome, since redundant transactions between blocks are simply wasted work — not very green at all.