Junaeth Series #2 – Novel Timekeeping
July 22, 2021
The Junaeth consensus protocol that powers the Stealth blockchain has a number of innovations that contribute towards a highly robust platform with an excellent user experience and scalability. Among these innovations is a network timekeeping mechanism designed to handle regular, five second block intervals in a heterogeneous environment where computers on the network (network nodes) may not have synchronized clocks, or where adverse conditions can sometimes create latencies of seconds or more.
Cash is Asynchronous
Blockchain was originally conceived as a medium of electronic cash, suggesting that, like cash, the blockchain itself does not necessarily need to be synchronous. To illustrate this idea, consider a transaction wherein Alice pays Bob a $10 bill. For the transaction to be successful, the $10 bill can be given at any time. Alice could pay Bob today, tomorrow, or next Wednesday. In this sense, cash is asynchronous.
— — — — — — —
Synchrony Prevents Double Spending
Blockchain, however, relies on synchrony for reasons that distill to the double-spending problem. Because cash is physical, a particular $10 bill can not be spent twice. If Alice pays Bob with a $10 bill, she no longer has that bill and therefore cannot also pay it to Carol, for example.
Blockchain relies on electronic transactions. Although each spendable blockchain transaction (called a “UTXO”) can be thought of as a bearer instrument, like a $10 bill is a bearer instrument, the electronic nature of blockchain transactions means that it is trivial to create two different transactions that spend the same UTXO.
Let’s consider the case where two different transactions, A and B, spend the same UTXO. Invalidation of transaction B occurs when transaction A is added to the blockchain. Because transaction B spends the same UTXO (bearer instrument) as transaction A, transaction B can never be valid because it attempts to spend money (the UTXO) that is already spent by virtue of being added to the blockchain.
This example demonstrates the most fundamental need for synchrony in a blockchain. Imagine that two blocks, block X and block Y, are incompatible in that block X contains transaction A and block Y has transaction B, both of which spend the same UTXO. Nodes will reject block Y if their blockchains already contain block X, or if the blockchain containing block X is somehow more trustworthy than the blockchain containing block Y. If block Y references block X (symbolized as X->Y), or if block Y references some block that references block X (X->?->Y), then the rejection of block Y is easy because in these cases block X must precede block Y in time. Synchrony arises because blocks are, on the whole, ordered by time.
— — — — — — —
Forks Result in Blockchain Asynchrony
In blockchain, the possibility of forks complicates this decision making process because different branches of the fork have no synchrony requirements. Imagine the case where block X and block Y both reference the same block, W, splitting the chain into a fork with two branches (branch W->X and branch W->Y). How can nodes decide whether to accept the branch W->X or branch W->Y? The answer is that any one node will accept whatever branch all the other nodes accept. This situation is an example of focal point game theory, where the consensus protocol is designed in such a way that it is in the best interest of nodes to make the same choices as they think other nodes will make.
— — — — — — —
Fork Resolution Restores Synchrony
To understand how nodes can eventually decide on the same branch, imagine a network of four validators, named V1, V2, V3, and V4. These validators are shuffled into a queue where each will sign a block, in the order of shuffling. Let’s say they were shuffled into the sequence V1, V2, V3, V4 (which will happen randomly once every 24 shuffles, on average). Let’s further say that V1 produced block X that has a predecessor of W, creating branch W->X. Imagine V2 lost its connection for a few seconds and decided that V1 “missed” it’s opportunity to create a block, and V2 created block Y that also has a predecessor of W, creating branch W->Y. This situation happens about once per day on the Stealth network (about once per 17,000 blocks).
In this example, V1 didn’t actually miss its block, and most likely every other node besides V2 received the block in a timely fashion and chose branch W->X, because W->X did not have a missed block at this position. As a consequence, branch W->X will grow and branch W->Y will terminate at block Y. Here, we can see that both blocks X and Y can spend the same UTXO, but only one block will be valid, preventing a double spend. It is worth mentioning that in this case that validator V2 will actually miss its block if it doesn’t receive block X before it is validator V3’s time to create a block.
— — — — — — —
Blockchain Reorganization and the Isolated
Notice how time was critical in this process. Assuming all validators are honest actors, block Y was only created because block X was late. Importantly, validator V2 had no way to tell whether it was cut off from the rest of the network (isolated) or whether only V1 was isolated. In the absence of this knowledge, validator V2 went ahead and produced a block when it was supposed to, with the understanding that if this block creates a fork, the fork will be resolved according to the protocol, subject to the aforementioned forces of focal point game theory.
The ability for validator V2 to reorganize its blockchain and get on the winning branch is critical to maintaining global consensus. For this reorganization to be possible while also guaranteeing regular production of blocks (every 5 seconds for Stealth), it is necessary that (1) validators continue to produce blocks even when they may be completely isolated and (2) nodes do not reject blocks based on their timestamps.
— — — — — — —
Blockchain Timing Doesn’t Need Timestamps
The latter requirement creates a conundrum that is resolved by the former. This conundrum can be expressed as a question: how can blocks be produced at highly regular intervals yet not be subject to invalidation based on their timestamps? The answer is by abandoning the necessity of a globally synchronous clock, i.e. a clock to which all network nodes, including validator nodes, synchronize their internal clocks. That is, no node polls any other node to establish a consensus on what time it is, because such consensus is actually impossible given that the polling itself is subject to unpredictable latencies.
Instead, time is kept by the blocks themselves. Each block not only carries a timestamp (mostly for the benefit of users) but also a height that must be one greater than the block preceding it and one less than the block following it. In other words, the block heights are ticks of Junaeth’s network clock, and decisions of validity come from (1) the sequential ordering of these blocks and (2) the motivation to agree with the majority of the other validators. This latter motivation comes from focal point game theory: validators do not want to add blocks to a branch that will inevitably terminate because, like validator V2 in the example above, they would end up missing blocks on the branch that eventually wins.
Fast. Secure. Reliable.
Get the Stealthsend Desktop App
