DB Content Lineup
A blockchain DB has its records in a lineup organization so that the records once entered in the DB are immutable. As a matter of fact, along the way of lining up usual records such as payment transactions, a mining based public blockchain also lines up the public-key addresses of the won miners in its entire histry. The DaoliCloud blockchain is a little unusual in lining up public-key addresses of miners: it lines up not only those of the mining competing winners, but also very importantly, many of the “losers”. Let the importance of “losers” be topics for another day. In this post, let us see how “losers” are lined up immutably in DaoliCloud. Immutability is a very important security property. Thus, the algorithm to correctly lineup “losers” needs a clear exposition.
In a previous post we have described DaoliCloud’s innovative application of the KeyBlocks and MicroBlocks in Bitcoin-NG for parallel competition enabled fair maintenance, and more importantly the liveness property, of the DaoliCloud DBMS. The following figure depicts an epoch of the blockchain DB record entering process which begins with a competition among “Non-spam quantity of parallel competing MicroBlocks”. These competing MicroBlocks points to, i.e., follows, the “Confirmed block appended to the blockchain” (the confirmation is due to a certification process of the BFT group). The parallel dissemination of these MicroBlocks will initiate the miners to PoL mine KeyBlocks. Each KeyBlock mining follows a MicroBlock.
Since KeyBlock mining in DaoliCloud is permissionless, the mining output constructs a plural number trees, each tree to fork a parallel competing MicroBlock as its root node with a plural number of valid PoL KeyBlocks as its leaf nodes in the bottom part of the figure above. One of these trees will then be consensus selected and certified by the majority of the BFT group for its MicroBlock root to be appended to the blockchain. To this end, the epoch of the blockchain DB record entering process completes.
In each parallel competing MicroBlock, its creator shall input usual DB records, such as payment transactions. These MicroBlocks are competing to enter records most correctly and most fairly. In addition to entering the usual records, the DaoliCloud blockchain also records the “losers” which are named by their public-key addresses. Let each parallel competitor hope that itself will win the parallel competition. It therefore should input the public-key IDs of its PoL KeyBlock siblings in the tree it belongs to. Thus, the only tree to be selected by the BFT group enters not only usual DB records, but also a plural number of immutable public-key IDs of the parallel competing “losers”. Here, the immutability is in two ways: (1) That of the lining up the won MicroBlocks being appended to the blockchain history. (2) That of the public-key IDs of the parallel competing “losers” inside one MicroBlock in a sorted sequence.
DaoliCloud block dissemination is broadcast to the entire network of the miners. The uniquely correct and fair lineup DB records, including the public-key IDs of the parallel competing “losers”, are known to all miners, no quibble.
Sybil Attack Prevention
Sybil is a 1973 book by Flora Rheta Schreiber about the treatment of Sybil Dorsett (a pseudonym for Shirley Ardell Mason) for dissociative identity disorder (then referred to as multiple personality disorder) by her psychoanalyst, Cornelia B. Wilbur.
In computer security, Sybil attack refers to a type of attack wherein a reputation system is subverted by creating multiple identities. This name is coined after this book of Schreiber. Evidence showed that large-scale Sybil attacks could be carried out in a very cheap and efficient way in extant realistic systems such as BitTorrent. Also see here for a survey of Sybil attacks in social networks.
Sybil attacks are avoided in Bitcoin by requiring block generation ability to be proportional to computational power available through the PoW mechanism. To make an influence in the Bitcoin network, a node has to mine a valid PoW block. The more blocks can an adversary mine, the more influential can it be. Soon after Bitcoin mining profitability became widely known, its PoW difficulty entered a vicious cycle of no-return ramp up, and quickly the mining cost reached a prohibitive height. It turned out that using many copies of special purpose expensive mining hardware plus electricity to gain an advantage in reputation influence is too costly to be worth the gain. We can regard that in Bitcoin, Sybil attacks are prevented by shere muscle than intelligence. This unfortunately is an abnormal and undesirable way of using cryptography by Bitcoin: to prevent an attack, non-attackers and attackers are all forced to pay a high cost; the normal and desirable way of using cryptography should force only attackers so.
In DaoliCloud, a miner follows one of a plural number of parallel competing MicroBlocks to try luck mining KeyBlocks in PoL manner (following a MicroBlock means to input the MicroBlock to the mining hash function, see the DB record entering figure in the preceding post). A powerfully muscular and influence obsessing miner can of course use some virtualization-technicalities-made Sybil fake IDs to mine KeyBlocks by following more than one of these parallel competing MicroBlocks, and can even mine many Sybil KeyBlocks after each of the parallel competing MicroBlocks. Then the BFT certification group will see big-sized forky trees, even possibly many such. What a BFT member shall certify is not a big-sized, but a middle-sized, tree. The best strategy for a Sybil miner is to mine one KeyBlock only after each parallel competing MicroBlock. In this strategy with best of the luck one of the resultant trees among all the trees that the Sybil by luck has not wasted its contributing effort to construct may happen to have the right middle size. Thus, a Sybil by luck can make 1 influence, exactly equals that of even an amateur IoT device. Very soon, a sane muscular Bybil shall drop out for the return on invest being too bad.
Might is not right.
Profitable Mining in Need of Spam Control
A permissionless blockchain with a profitable coin mining scheme when gaining a householder name will attract enthusiastic miners to join in. The more miners joining coin mining, the noisier the mining dissemination traffic the blockchain network will hear. If the blockchain does not control its mining traffic, then sooner or later it would find itself being jammed by the announcements of mining successful blocks, exactly like being under a Distributed-Denial-of-Service (DDoS) attack (also called spam in the case of receiving junk email). Bitcoin has two ways to deflate its mining dissemination traffic for “DDoS attack” prevention.
The first one is a designed algorithmic method. In anticipation of a growing enthusiasm of joining in miners, Nakamoto designed a parameterizable cost for finding a block. The way that’s accomplished is that all the nodes in the Bitcoin peer‐to‐peer network will automatically recalculate the target, that is the size of the target space as a fraction of the output space, every 2016 blocks. Each Bitcoin miner recalculates the target in such a way that the average time between successive blocks produced in the Bitcoin network is about 10 minutes. With a 10‐minute average time between blocks, 2016 blocks works out to two weeks. In other words, the recalculation of the target happens roughly every two weeks. The exact formula for this parameterized mining cost increase can be seen in, e.g., Chapter 5 of this highly recommended book on Bitcoin by Narayanan-Bonneau-Felten-Miller-Goldfeder, 2016. We can see that in Nakamoto’s original anticipated parameterizable mining cost control, Bitcoin mining dissemination traffic is extraordinarily quiet, so quiet that nothing is heard in every other 10 minutes.
The second way to have deflated Bitcoin mining traffic from endangering “DDoS attack” is completely unanticipated by Nakamoto. Since Bitcoin mining became a householder name for permissionless and high profitability, an arms race of using ever increasingly more powerful, with some being purposely designed, e.g., GPUs, FPGA hardware, and ASIC circuits, and even aggregating a mass number of such, mining machines (aka farming), to compete Bitcoin mining against one another. Large professional mining data centers have taken over the business of Bitcoin mining. As professional competition can usually arrive at a business standard of excellence, Bitcoin mining “DDoS attack” prevention has fortunately arrived at a professionally excellent status quo: the mining dissemination traffic has been remaining quietly in good order under a stable control.
Unfortunately, a severe centralization for Bitcoin mining has resulted. Only can fewer and fewer miners, and each being more and more powerful, stay surviving the game. The highly centralized Bitcoin miners are factually demanding very strong trust over them, and thereby undermining security, reliability, fairness, service stability, and threatening the very sustainability, of Bitcoin. Moreover, with its infamously low transaction processing throughput and long conformation latency, Bitcoin is not suitable for global online commerce transactions applications. Even for its few exhibited successful applications, e.g., financial investment, Bitcoin has also taken the blame for tremendous wastage of electricity.
DaoliCloud Mining Traffic Control
PoL mining for KeyBlocks in DaoliCloud, although has a much eased PoW difficulty than that for Bitcoin mining, must be finished within an algorithmic prespecified time interval. This time interval is expressed in the Global Clock that is the most basic consensus among all the miners in DaoliCloud. In this blog and this blog we have described DaoliCloud’s Global Clock consensus. In this blog we presented that the mining time spent on outputting a valid PoL KeyBlock must be honestly claimed as an input to the mining hash function. It is a computationally hard problem to cheat forging a falsely claimed KeyBlock mining time.
Therefore, by algorithmic adjusting the PoL mining time interval length, DaoliCloud can dynamically control the number of valid KeyBlocks output from a PoL mining phase. A shorter/longer time interval shall output a smaller/larger number of KeyBlocks in a PoL mining phase. It is desirable for a KeyBlock mining phase to output a sufficiently many, but not a spam quantity of, valid KeyBlocks as the leaf blocks of the trees in the DB entering epoch figure (see the first blog post of this month). One of these trees will be BFT group consensus selected for its MicroBlock root to append to the blockchain. The miners of the leaf KeyBlocks of this selected tree will qualify parallel competing by creating and disseminating MicroBlocks in the next epoch. Here, “sufficiently many” has the following two meanings. (1) For fair parallel competition among sufficiently many MicroBlocks so that fair and correct maintenance of the DBMS can be achieved. (2) For sufficiently many parallel competing “losers” (their public-key addresses, i.e., IDs) to enter the blockchain DB in lineup stockpile to guarantee the very important property of liveness for the blockchain. The lineup stockpile of the parallel competing “losers” to enter the blockchain DB is the action of the only winner in the subsequent parallel competition. Every qualified parallel-competing MicroBlock creator who is a miner of a leaf KeyBlock in a BFT selected tree places the public-key IDs of its siblings in the MicroBlock it creates, in hope of only itself winning the parallel competition.
Occasionally, this spam prevention control algorithm may not work very smoothly. A too quiet traffic or a too noisy traffic may be possible from a PoL KeyBlock mining phase. In a too quiet case, there would be too few, even none of, MicroBlocks to join the parallel competition and so the competition won’t be healthy. Then an algorithm pre-determined number of lineup “losers” shall qualify to join the competition by issuing MicroBlocks, so that the parallel competition shall maintain healthy. In a too noisy case, the BFT members may be spammed not even able to output a valid certification. Then again, an algorithm pre-determined number of lineup “losers” shall qualify to join the competition by issuing MicroBlocks, so that the blockchain remains running lively and the parallel competition remains healthy. For the so-called lineup “losers” having been in the blockchain DB, see this blog and this blog.