Blog – DaoliCloud

May 2021

Why and How I-BFT Speeding Up Consensus

We have known that the DaoliCloud blockchain uses a Byzantine Fault Tolerance (BFT) algorithm to realize (represent, execute on-behalf, or reflect) the incentive earning enthusiasm of the majority of the miners. This is an open membership BFT algorithm in the formulation of ByzCoin (see this post). In this BFT formulation, the BFT servers are identified by the lineup blocks which have been very recently appended to the blockchain one after another; the latest appended block identifies the youngest aged BFT server. With the BFT servers being lined up, they can work sequentially according to their positions in the lineup order. We can design an incentive rewarding scheme to induce a collaboration behavior out of these BFT servers. We name a so designed BFT algorithm “Incentive-BFT” (I-BFT). Now let us describe the detailed formulation for DaoliCloud’s I-BFT algorithm.

Let the lineup BFT servers be organized into linearly and sequentially ordered groups, and let this order be defined by the same linear sequence of the MicroBlocks to extend the blockchain one after another. Each of these groups contain an odd number of BFT servers. The first to work group, named the quorum-group-1, is the servers who have created the MicroBlocks being most recently appended to the blockchain. The BFT servers in quorum-group-1 initiates the consensus certification process. Each of the quorum-group-1 servers works non-interactively to select a KeyBlockTree using “Result-Random-Algorithm” (see this post), digitally sign the selected KeyBlockTree, and broadcast the signed tree as output. If quorum-group-1 has reached a majority agreement on certifying a unique KeyBlockTree, then the whole I-BFT certification algorithm completes successfully with a valid certification output.

Otherwise, the 2nd to work group, named quorum-group-2, will continue working on the I-BFT certification job. This group is the BFT servers who are immediately older than those in quorum-group-1. In other words, a quorum-group-2 server used to be a quorum-group-1 server some epoch(s) earlier; the youngest server in quorum-group-2 was the oldest server in quorum-group-1 in the previous epoch. Unlike that a server in quorum-group-1 working completely on its own judgement on Payload records’ correctness, fairness, and on chosing the median size KeyBlockTree from the concurrent competitors, a quorum-group-2 server shall work one after another in the order of their age being appended to the blockchain, with the youngest aged starting first. Each server shall also be influenced by the correct and fair signing result from the servers in quorum-group-1. If agreeing to a correct and fair earlier signed result is possible, the server should add its agreement to the earlier result by signing it too towards completing a valid certification consensus. This behavior of a later (older) BFT server agreeing on the earlier correctly signed result is what we designed and named “incentive induced collaboration” behavior. The collaboration decision by a quorum-group-2 server is a sensible one because doing so will increase its probability for, and share of, the incentive reward.

This process can go on. Once upon reaching a majority agreement on a unique KeyBlockTree to certify, the I-BFT algorithm completes. The incentive rewarding policy can be designed to be that the earlier the algorithm completes, the higher incentive reward to a server in helping reaching the agreement. Therefore from the quorum-group-2 onwards, the I-BFT majority agreement on outputting a consensus certification shall quickly be reached. An afterwards smart contract can scan the I-BFT algorithm result to accordingly reward incentive coins to the collaborative servers. The incentive rewarding regime should encourage the selection of most correct and most fair DB-Payload records documentation, and quick formation of the collaboration.

Very rarely, this I-BFT algorithm may not be able to reach a majority agreement certification after having used up the effort of quorum-group-n for a pre-set number n. This is when the I-BFT servers fail to certify a KeyBlockTree from a PoL mining epoch. There can be some reasons for the failure, such as dishonesty of the concurrently competing participation miners, or non-cooperation of these I-BFT servers, etc. At any rate, the blockchain shall keep running lively by the backup workforce thanks to having lined up the “employees” in the CR-Payroll records (see this post). In the next post we shall see why the I-BFT mal-function is a rare event.

Table of Content

Why and How I-BFT Working Non-Interactively

What a conventional Byzantine Fault Tolerance (BFT) algorithm, such as Practical Byzantine Fault Tolerance (PBFT) of Castro-Liskov, is to solve is for a plural number of network distributed computers to function as reliability replicas, which we shall call BFT servers, by them conducting all-to-all communications and reaching a majority agreement on some semantic condition about (a set of) messages. The messages may be of the BFT servers themselves, however in more usefully, meaningfully and usually cases, are from clients for the BFT servers to make fault tolerance computing decision for. Historically, a particular semantic condition about messages, that began the research topic by the 1983 seminal work of Lamport-Shostak-Pease, and has been keeping attracting the most of the research interest and effort so far, is for the BFT servers to agree on a time ordered sequence of messages that the BFT servers have received. Because communications usually have varied latency for varied servers, and also some of the servers may be faulty, it turns out to be very difficult for the BFT servers to agree on an ordered sequence of messages by all-to-all discussions. Some of the BFT servers may even make use of the factual possibility of imperfection to launch an attack in the guise of faults. Since there is no practical way to discern a true fault from a made-up one, a well-known FLP Consensus Impossibility has been established by Fischer-Lynch-Paterson to invalidate any claim for reaching a BFT consensus on time ordered sequence of messages. It is also obvious that for reliability the number of replicas should not be too small. The quadratic communication complexity of all-to-all discussions among BFT servers renders an impractically high cost for conventional BFT algorithms to be practically useful, not probably even for a private setting of BFT servers.

The DaoliCloud blockchain has innovated the I-BFT algorithm. These BFT servers are lined up to work one after another, and for the later-to-work ones to be incentive attracted to collaborate with the earlier-correctly-worked ones. In this way of working, the I-BFT servers can avoid the old tradition of BFT algorithms’ all-to-all communications.

In a PoL KeyBlock mining phase, a KeyBlock that follows, or more to the point, votes for, a concurrently competing MicroBlock is deemed valid if it is both voting valid and time valid. Voting validity is in the same manner as in the Bitcoin PoW validity that the hash function output must be smaller than a specific value. Time validity is that a voting valid KeyBlock must be received before a timeout event.

An I-BFT server is a KeyBlock receiver and verifier, plus with a Certification Authority (CA) function. It counts the number of valid KeyBlocks that have voted for a qualified concurrently competing MicroBlock. It does not time order any sequence for the plural number of valid KeyBlocks that have voted for the same MicroBlock. The votes counting job for the first-to-work I-BFT server is completely a local decision. The later-to-work ones, in addition, collaborate the correct earlier ones. After mining timeout, the network becomes quiet, in fact, silent, for the mining traffic. Each I-BFT server can then make its certification decision and announce the decision one after another with elegance.

Our sizeable experiments have shown that by providing the I-BFT servers with sufficient decision time after the KeyBlock mining timeout event, the votes counting decisions of the I-BFT servers stably and quickly converge. More often the I-BFT servers reach a majority agreement on choosing the same MicroBlock to append to the blockchain, whose creator writes the DB-Payload records with the most correct and fair transactions, plus uniquely ordered lineup public-key addresses as CR-Payroll records which identify the concurrently competing “losers”.

The unconventional I-BFT algorithm of DaoliCloud, the non-interactive working I-BFT servers also play the role of a secure multiparty computation (SMPC).

Table of Content

Randomness of the I-BFT Servers

The formulation to organize the I-BFT servers for DaoliCloud is modified from that of the ByzCoin. ByzCoin’s BFT servers are the latest w Bitcoin PoW mining winners whose blocks have been appended to the blockchain in the sequence of extending the blockchain. The I-BFT servers for DaoliCloud are the latest w MicroBlock creators whose concurrently competing MicroBlocks have been appended to the blockchain, also in the sequence to extend the blockchain. What is the key difference between these two BFT organizations is as follows.

To join the ByzCoin’s group of BFT servers, a miner simply bids for power to compete with the PoW hashrate of Bitcoin mining. Unfortunately, since Bitcoin mining has become extraordinary costly, ByzCoin can have attract few Bitcoin miners to mine ByzCoin.

In this post and this post, we have described algorithmic steps for a DaoliCloud miner to become an I-BFT server. Most of the time, these algorithmic steps form a consecutive number of being lucky events. The first event to be a lucky miner is to have successfully mined a KeyBlock. The second lucky event for this lucky miner to be lucky again is that its successfully mined KeyBlock luckily belongs to a KeyBlockTree with the right median size to pass through the selection by the I-BFT servers using “Result-Random-Algorithm”. The third lucky event for this already-having-been-twice-lucky miner is that it has created a lucky MicroBlock which wins the concurrent competition for its MicroBlock to extend the blockchain. To this end, the three-times-lucky-streak miner becomes an I-BFT server.

An alternative lucky route to the I-BFT servers’ group is for a quite lucky miner to be unlucky in the third strak. In this route, the miner’s public-key address will become a CR-Payroll record to enter the blockchain DB. In this alternative lucky route to I-BFT, the twice lucky miner has to wait for a future less of the time occasion to join a concurrent competition in the complement manner. Upon its turn to participate the concurrent competion, it still needs to be lucky again to win the “Result-Random-Algorithm” selection.

The “Result-Random-Algorithm” is executed by the I-BFT servers after KeyBlock mining in an epoch has finished. Because even being an alternatively lucky “loser” (a CR-Payroll enlistee) can still profit from providing various kinds of cloud resource services, permissionless and profitable KeyBlock mining for the DaoliCloud blockchain will be noisy for most of the time. The noisy and random dissemination of KeyBlocks form the main source of entropy to input to the “Result-Random-Algorithm”. It is an uncomputable problem for any calculative minded miner to somehow control the random input in order for them to output non-random, i.e., computable, results.

DaoliCloud’s organization for its BFT servers is uncontrollably random.

Table of Content

When I-BFT Meeting Immutability

The I-BFT servers in the DaoliCloud blockchain non-interactively certify a concurrently competing MicroBlock. Each of them does so by digitally signing a chosen MicroBlock including its KeyBlockTree. The BFT server group structure takes the formulation of ByzCoin, in which each server can certify at most w MicroBlocks where w is the size of the BFT server group. After an I-BFT server has used its Certification Authority (CA) power w times, it retires and becomes no influence or refereeing power anymore.

The publicly verifiable immutability of blockchain dictates that the I-BFT servers as CAs have their spokespersons’ influence strictly and immutably confined to the context for which and when they were qualified to speak. The public verifiability of this context confinement can prevail long afterwards using the BFT servers’ public keys which have appended to the blockchain. Now we see a completely new understanding that the work of the DaoliCloud blockchain exposes for the first time about the notion of CA: A CA needn’t protect its certificate issuing private key in the conventionally known strong manner. A compromised private key of a blockchain retired CA cannot cause damage to the certificates it has issued. Indeed, this new understanding of CA is only the simple fact that a blockchain can have no failure at any single point in the system.

This new understanding and good use of CA is a very strong motivation for us to work out a low cost blockchain for general purpose cloud applications. Numerously and globally distributed smartphones and/or IoT devices can provide robust and reliable CA services in a very near future.

Table of Content

Why and How I-BFT Removing Consensus Uncertainty

Due to various reasons such as device fault and/or communication channel imperfection, a consensus algorithm usually has inherent system uncertainties. Academic consensus algorithm research efforts, such as PBFT (see this post), have long been remaining in the doctrine of all-to-all communications among replicas for them to agree on some precise semantics of messages, such as a time ordered sequence for messages being uttered or heard. Such algorithms are unfortunately not scalable to large size and open system applications where messages are noisy and replicas need to be many. The quadratic cost for all-to-all communications among many replicas would render their discussion traffic alone a source of uncertainty, not to mention their very job to reduce uncertainty.

If we think of Bitcoin or Ethereum blockchains being unconventional fault tolerance algorithms, they tolerate faults in the following sense. Knowing that “there are a thousand Hamlets in a thousand people’s eyes”, these unconventional fault tolerance algorithms require 999 people who are slow to express their Hamlets accept the only Hamlet that the only quick guy has expressed. Such fault tolerance algorithms use very high PoW difficulties to limit consensus uncertainties. Bitcoin for example uses a prohibitively high PoW difficulty so that most of the time the network has no block dissemination and of course has little uncertainty. Unfortunately, these very high cost methods have caused various problems, some can threaten long term sustainability of these systems.

The DaoliCloud blockchain removes consensus uncertainty with in writing clarity, cryptographically authoritative validity, and sufficient redundancy supported reliability. Let’s describe these properties as follows.

First, there is no sense for luckily mined blocks to be sequentially ordered in their uttering/hearing time. Valid KeyBlocks are abundant for the miners to fully enjoy the high bandwidth of the modern network. As long as valid KeyBlocks are received by the I-BFT servers before timeout, one being uttered or heard before or after another is completely a nonissue. This way, the number of Hamlets that the miners express are greatly reduced at the source of the messages.

Secondly, the use of Incentive-BFT (I-BFT) servers who are divided into small groups means to reduce the number viewers for Hamlet. Moreover, what is uniquely novel in the I-BFT algorithm is that the lineup groups of already small sized BFT servers work in incentive induced collaboration that the later viewers tend to agree to the earlier ones to confirm their correct and fair views. Notice that the miners are also incentive motivated under the same incentive rewarding regime. Therefore the incentive induced collaboration among the I-BFT servers reflect and represent the same incentive earning interest of the miners. The shared same incentive earning interest of these two participants shall quickly remove consensus uncertainty. Therefore most of the time the I-BFT servers shall find no consensus uncertainty for them to agree on a unique KeyBlockTree to extend the blockchain.

Thirdly, most of the time when the I-BFT servers reach a majority agreement on the unique KeyBlockTree, they certify, i.e., digitally sign, the whole tree. This certification on the chosen KeyBlockTree has in writing clarity and unforgeable authority to stipulate not only the MicroBlock root to extend the blockchain, but also the set of the KeyBlock leaves that their finding miners qualify to participate in the concurrent competition for the next epoch. So most of the time there is no uncertainty on who the concurrent competitors are for the next epoch.

Fourthly, most of the time the CR-Payroll records are written to the blockchain DB also with in writing clarity and unforgeable authority. This is because the creators of the qualified concurrently competing MicroBlocks write the competing CR-Payroll records, each of them writes the IDs of its fellow concurrent competitors using the I-BFT certification on the chosen KeyBlockTree. The chosen MicroBlock extending the blockchain writes the CR-Payroll records to the blockchain not only in writing clarity, unforgeable authority, but also immutably lineup. Thus less of the time there will be no any uncertainty on who the complement concurrent competitors are for the next epoch.

Finally, let’s see a unique and important property in the DaoliCloud blockchain: sufficient redundancy sorported reliability for the blockchain to change state. After the I-BFT servers reach a majority agreement on issuing a block appending certificate (or fail to agree, with no certificate), the blockchain will change its state to enter a new epoch. The state change is performed by a not small number of concurrently competing MicroBlocks being broadcast to the P2P network. Most of these broadcast MicroBlocks document the correct I-BFT certificate (most of the time, the MicroBlocks are created and broadcast by the certified KeyBlocks mining winners), or the null certificate (less of the time, the MicroBlocks are created and broadcast by a complement set of the CR-Payroll enlistees). In each of these two cases, the blockchain’s change of state is disseminated to the P2P network with a reliability of the following qualities: sufficient redundancy, in writing clarity, resounding explicitness, cryptographically authorized validity, and repeated confirmations. Therefore, most of the miners in the P2P network can update their local state up to the fresh and same global state of the blockchain. By contrast, blockchain state change in Bitcoin and Ethereum is undesirably too quiet, lack of in writing clarity, and possibly a very long latency for confirmation time.

There is little uncertainty in all and any time when the DaoliCloud blockchain is running.

Table of Content

Why Most of the Time Is More Frequent Than Less of the Time

In our presentations so far we have often used the two phrases of “most of the time” and “less of the time”. In saying so, we have obviously expected that former occasions are more frequent than the latter ones. Clearly only so, the I-BFT servers will more often reach a majority consensus on selecting and certifying the unique KeyBlockTree, and thereby the more often accumulated CR-Payroll “employees” will not be used up by less often consumption of them. Also only so, the concurrently competing MicroBlocks will more often document DB-Payload correctly and fairly.

Notice that it is a reasonable and necessary assumption that a bigger fraction of miners participating in DaoliCloud will honestly follow the prescribed protocol algorithm. More meaningfully in the reality, a majority of the miners, servers and wallets of DaoliCloud will not modify the publicized implementation code of the DaoliCloud blockchain algorithm. With this assumption, we are ready to provide evident reasoning why “most of the time” is indeed more frequent than “less of the time”.

First, in this post we have explained that the I-BFT servers are random. Under the assumption that more often the participants are honest, the random I-BFT servers will more often work in the incentive induced collaboration to quickly reach a majority consensus to select, certify and output a unique KeyBlockTree. Therefore, more often lineup accumulation of the CR-Payroll “employees” into the blockchain will take place than less often popup of them out of the blockchain when the I-BFT fail to agree on a majority consensus.

Secondly, the PoL miners are knowledgeless and have to mine KeyBlocks by randomly following concurrently competing MicroBlocks in which the miners see to have correctly and fairly documented the DB records. The random miners find KeyBlocks in sheer luck. Therefore the lucky KeyBlock finders who qualify the next epoch concurrent competition are also random. The random concurrent competitors will more often create concurrently competing MicroBlocks which document DB records correctly and fairly. This more often occasion is the case whether the concurrent competitors are of ones from the leaf nodes in the selected KeyBlockTree, or of the complement ones from the lineup CR-Payroll “employees”.

In all above reasoning cases, the only supporting basis for us to say “more often” is the simple and necessary assumption that a bigger fraction of participants in the DaoliCloud blockchain are honest and follow the prescribed algorithm. Assuming that “less often” might be caused by some unknown reasons of which the worst case scenario being the dishonest actions of a smaller fraction of the participants. Then indeed, “most of the time” is more frequent than “less of the time”.

Table of Content

Why Unique History

The I-BFT algorithm can only completes certifying a KeyBlockTree (and for its MicroBlock root to extend the blockchain) provided that a majority of the I-BFT servers have digitally signed this KeyBlockTree. This algorithm of counting the number of signatures of course requires that each I-BFT server should only sign one KeyBlockTree. What if some of the I-BFT servers signs more than once?

A simple rule-of-the-game stipulation can prevent an I-BFT server from double signing. If an I-BFT server is seen to have signed different KeyBlockTrees, then the verifiers can reckon that the only tree of the MicroBlock root with the numerical sort in the smallest position is actually signed by the double signer. Therefore, double signing is useless. In this way, an I-BFT majority agreement on their choice and certification of a KeyBlockTree is always unique. The double signing behavior can be deterred by an afterwords running smart contract in terms of incentive rewarding penalization.

The correct compilation of a concurrently competing MicroBlock requires the MicroBlock to include the unique I-BFT certification evidence. Then the chain parser for the DaoliCloud blockchain will always see the unique history written by all of the I-BFT servers who used to be concurrently competing MicroBlocks and have won the right to write the history. The MicroBlocks which are created by less of the time popup complement CR-Payroll enlistees should have their MicroBlocks only to follow, i.e., to extend, an I-BFT majority consensus certified MicroBlock which has not yet been successfully extended. There is no need for the complement concurrently competing MicroBlocks to include CR-Payroll records.

Since most miners are honest, any block extending any unauthenticated history will be ignored (dropping the disseminated blocks) by most of the miners. In the next post we shall further see that such blocks belong to chain forks and will be blacklisted.

Table of Content

The Future Comes One Unique Block At a Time

None of the known blockchains likes a chain to fork. To allow blockchain forking means to allow double spending. Permissionless blockchains avoid chain forking by letting miners compete one another for consuming more resource which has value. For example, the PoW mining algorithms of Bitcoin and Ethereum let miners compete using ASICs, GPUs, and even pooling them, for consuming a huge amount of electricity. For another example, “Proof-of-Storage-Space farmers” in a recent hype of Chia Network blockchain compete on “grinding disks” for consuming, if not damaging, harddrives. For permissioned blockchains, such as Proofs-of-Stake based, chain forking is much worse than double spending, it’s private property robbery. They prevent chain forking in essence with the conventional mechanisms for the governance of privately owned enterprises.

The DaoliCloud blockchain uses cryptography to protect the chain from forking: chain extending, i.e., a block appending, needs co-signatures by a majority of the I-BFT servers. Below let’s analyze the difficulty to fork the chain for a forked block to be cryptographically indistinguishable from the genuine block to lead the chain extension.

We first note that the number of the I-BFT servers is odd. When a block extension is co-signatures certified by a majority of the I-BFT servers via the broadcasting dissemination by these servers, there can have no ambiguity on the block extension for most of the nodes in the P2P network. Therefore, forking blocks cannot take place in realtime when the chain is extending. An forking attacker will have to fork the chain afterwards, better by way of “secret mining” known to be possible in some easy mining PoW blockchains.

A meaningful strategy of a non-realtime forking attacker to fork the chain, e.g., at a target block B, is to collude with a set of nodes whose MicroBlocks are queued ahead of the target block B in the chain because some of them were in the position of the I-BFT servers for refereeing the block B. This set should have a size larger than the default quorum majority size for certifying B, and the attempted collusion result has to be for this set of the colluding servers to co-sign a forking block B’ of this attacker. Such a collusion is obviously very difficult, perhaps needs a very heavy bribe or severe coercion, but should be easier than forging their digital signatures.

This imaginary non-realtime forking attack will not work. This is because B has documented a set of payroll nodes. These payroll nodes have actively worked on the payload to enter the correct transaction records in the payload to the ledger. These payroll activities have also been confirmed by the payload-payroll activities in the blocks that follow B.

It is impossible to fork the DaoliCloud blockchain for a forking block to be cryptographically indistinguishable from the genuine block extending the genuine chain. In the next post we shall see a good application of this property.

Table of Content

Fork It!

In the beginning of the preceding post we discussed that known permissionless blockchains avoid chain forks by letting their miners compete for consuming useful resource. Permissionless and profitable competition for consuming resource easily intensifies for the targeted resource becoming a rarity. Often the targeted resource becomes so rare that can threaten the very sustainability for such permissionless blockchains.

The DaoliCloud blockchain also bases its security on a notion of rarity. This is a rarity of luck. Fortunately, a rarity of luck need not consuming some resource of value in any wasteful manner. The PoL miners in DaoliCloud are general-purpose computer users. In fact the DaoliCloud miners should be amateurs using spare capabilities on mediocre devices. (We shall manifest this fact in a near future post.) It turns out that chain forking is not a problem for the DaoliCloud blockchain. Instead, it’s a feature.

With the analysis in the preceding post we have known the impossibility to fork the DaoliCloud blockchain to pass cryptographically strong authentication. Therefore a forking “attacker” need to be open and frank. Just fork the chain without authentication. Since luck is open to all, the honest forking “attacker” can code a forking program and persuade miners to extend its fork by running its forking program. The persuasion needs to be open since it is easy to detect a fork violating authentication. Secret forking is not possible since a smart contract like parser can automatically discover a fork at once. The correct treatment for a frankly open fork is to blacklist it.

In fact, we have considered that forking is a feature for Proofs-of-Luck based blockchains. Open forks should be allowed, and that’s why we do not want to label an open forking proposer an attacker. An open fork can be very useful for a featured application. For instance, to meet a regional law enforcement requirement that the cloud resource services from the CR-Payroll “employees” in the forked chain are paid at the regional service provisioning rate to be comparable to the regional fiat money would do. This way, the CR-Payroll enlistee servers may be attracted to co-locate in a geographical region to satisfy the region’s data sovereign requirement. In fact, each open fork can and should use the public-key based authentication and the simple blacklisting techniques to invalidate unauthenticated DB records of each of the other forks. This job can be automatically conducted by a smart contract like code.

Mutual exchange for “foreign chain coins” which are minted by other forks can be done in some out-of-chain routes, e.g., via a fiat currency.

Table of Content

Why Professional Mining (Rigs or Pools) Not Working

Mining rigs are defined as one or more computers specially designed for fast cryptocurrency mining. People buy rigs and pay for lots of electricity so they can mine quicker to earn more. For profitable cryptocurrencies such as Bitcoin and Ethereum, people have already aggregated hundreds or even thousands of rigs into mining “pools”. Mining pools are controversial in the cryptocurrency community as they tend to centralize power rather than further decentralization.

An important objective for the DaoliCloud blockchain is to decentralize blockchain mining so that random people around the world should be able to help maintain the blockchain. With this objective, the DaoliCloud blockchain is purposely designed that the majority of the miners should be amateur owners of client computers, such as personal computers, smart phones, and in future more and more IoT device holders. Coin mining is only one way to profit from participating DaoliCloud. Obviously, when amateur miners become crowded, Proof-of-Luck based mining will become less profitable. Our incentive rewarding regime features that professional quality servers should profit much more efficiently from providing cloud resource services, such as IP-aaS (see this post) and Storage-aaS (see this post), to amateur client computers so that a massive number of the latter can mine coins.

Then what if professional quality servers still want to profit from coin mining? Also, will mining rigs, and even pools of such, have some unfair mining advantage over amateur client computer using miners? By unfair advantage, we mean what has turned out to be in the situations of Bitcoin and Ethereum where miners in hashrate arms race have completely expelled amateur miners out of the mining game. Let us analyze as follows.

Notice that mining of KeyBlocks (the leaf nodes in Figure “A DaoliCloud Epoch” in this post) are purposely designed to be very easy. Targeted time for finding a valid KeyBlock is at several seconds level as sheer luck. In fact, when mining is participated by a massive crowd, hash-rate will become completely useless because mining is just computing one hash. Therefore mining rigs will not be a sensible choice for DaoliCloud miners, let alone pooling a massive number of them. Instead, programming some clever software and deploying in it to run in a large scale of datacenter might be a “strategy” for professional miners. To say this a “strategy”, it is merely to expect some efficiency and scale based advantage that business and professional excellence may have over amateurs.

However, increasing mining efficiency misses the point. In the plural number of forky KeyBlockTrees in the bottom part of Figure “A DaoliCloud Epoch”, the BFT servers use “Result Random Algorithms” (see this post) to choose the KeyBlockTree with the median size to be the winner of the concurrent competition. An efficient and wide-scale deployed software would quickly produce a too big sized KeyBlockTree to be discarded. Increasing mining efficiency is clearly a wrong way to play the mining game.

A probably remaining meaningful strategy for an increased winning probability in KeyBlock mining is (for a clever software) to follow each of the concurrently competing MicroBlock and mine similar number of KeyBlocks in the all resultant KeyBlockTrees. This is the only way for the clever software not to unevenly blow up the sizes of some KeyBlockTrees for to be discarded. By luck, one of the evenly blown up sized KeyBlockTrees happens to have the right median size, and still includes a number (i.e., the “similar number” it has been in controlling) of KeyBlocks that the clever software has mined. Unfortunately, this is again not a good way to increase the winning probability. Other professional competitors joining in will easily blow up the mining traffic to a level of a spam volume. The spam control mechanism (see this post) will quickly lower the effectiveness of the competing professional miners. Very soon they will drop out.

A crucial fact for professional quality servers with an intention to mine coins in DaoliCloud is as follows. Business and professional excellence can never expel amateur miners out of the almost no cost mining game. Competing with a massive number of amateur miners will have a very bad return on investment. Professional quality servers should better make serious profits from providing cloud resource services to the amateur miners for each of them to be able to happily play luck.

Table of Content

Incentivizing Servers for Enabling Amateur Miners

Fast and powerful processing hardware, and huge storage spaces, are way too of overkill for to be directly used in the DaoliCloud blockchain’s luck based mining, not to mention to pool farms of such. Instead, servers’ functions to provide client devices with IP-aaS and Storage-aaS are needed to enable a massive number of client devices to participate in the DaoliCloud blockchain as miners and/or as wallets. These functions are better implemented in software running on general-purpose servers. Standard server implementations for reliable IP-aaS can be found, e.g., in this post, and those for reliable Storage-aaS, e.g., in this post.

IP-aaS enables a client device to receive and send blockchain blocks. Storage-aaS enables a client device to update the blockchain state. With these two capabilities, a client device can PoL mine KeyBlocks, which is merely to compute a small number of hashes, compile DB-Payload and CR-Payroll records, digitally sign and verify signatures. None of these jobs need a level of processing power that a nowadays client device is without. Therefore, a humble client device suffices to be a PoL miner participating in the DaoliCloud blockchain.

Also, with IP-aaS and Storage-aaS, a client device becomes a logical server. Therefore, a client device participating in the DaoliCloud blockchain not only becomes a PoL miner, but also can host a personal or private scaled web or social media server. With encryption being the default capability for even a wallet node having point-to-point encryption quality, secure access control can be implemented for the users of such personal and private scale servers to enjoy privacy protected and/or surveillance avoidance communications.

Of course professional quality servers can directly participate in PoL mining. When the number of client device miners become larger and larger, the probability to win PoL mining becomes lower and lower. Sensible servers will drop out of mining when return on investment becomes too bad. Thus, the right incentive regime for motivating professional quality servers to participate in the DaoliCloud blockchain is for them to profit from providing client devices with services of distributed IP connections and storage spaces. Smart contracts are very suitable for attracting servers to switch from mining to service provisioning. A server can be rewarded coins which are proportional to metered quantities for bandwidth/storage/quality, and to timed duration of online connections.

Table of Content

Blockchain: All Things to All People

Bitcoin began the era of open source peer-to-peer (P2P) money. It also initiated a new area of study: blockchain for P2P computing. The work of DaoliCloud—Decentralized Autonomy of Lineup Cloud Servers—is motivated by a number of issues we have observed in the area of P2P computing for a while. These issues provoke thoughts and invite solutions. Let us now provide a summary for our technology blogs posted so far as how we see, and what we would like to work on, blockchain in specific, and P2P computing in general.

A widely thought over issue for us to discuss first is about blockchain’s scalability. Bitcoin is a very slow blockchain to suit being an exotic payment instrument (e.g., ransom payment). The very confined liquidity may be responsible for the value of this P2P money to be usually in radical fluctuations. Since Bitcoin, numerous proposals have appeared for improving blockchain scalability. For a permissionless blockchain being autonomously maintained by competing miners, we would like to attribute the poor scalability status que to an inefficient method to line up competing blocks. Competing miners are used in a “winner-takes-all” and “losers-have-no-use” manner. However, as mining winners are much fewer than losers, only having the winners to supply the system resource can hardly meet the demand from the users, almost all of whom are losers. A “loser-have-no-use” blockchain has an obvious supply-not-meet-demand problem.

Our approach to the blockchain scalability is to ledger document a large number of mining losers, their names of course, for them to also be able to supply the system resource, in fact, the main part of it. This supply-meet-demand thought is a “bring a dish to a feast” solution. No matter how many people come to eat, nobody will be hungry. The DaoliCloud blockchain is designed to make use of mining competition losers as the main suppliers for the system resource. This design is originally thought for guaranteeing blockchain liveness, and it turns out to find a more important use in blockchain scalability. It may be expected that early use of the losers’ resource supply would mainly be meeting the demand of the blockchain itself. This low-cost organization of huge resource supply would more and more turn to general use by applications that the blockchain enabled cloud hosts.

The second issue for our discussion is on Bitcoin’s astonishing invention of incentive enabled system reliability. Its evident demonstration that a consensus algorithm can run lively has renewed research interests in Byzantine Fault Tolerance (BFT). The BFT area of study has a well-known FLP Impossibility which basically concludes that a consensus algorithm cannot run lively. The renewed BFT research, and applications to blockchain, have not been very fruitfal. Most of the renewal remain in the old BFT convention of all-to-all communications for the BFT replicas to agree on some time ordered sequence for messages being uttered or heard. With the quadratic communication complexity and network latency, a large number of over-the-network-distributed BFT replicas may not often reach any agreement, more likely, heated discussions would add a larger part of the noise to the system, even possibly in a live-lock fashion.

Thinking over why Bitcoin has liveness, it is evidently from incentivization. A new thought on “Incentive-BFT” (I-BFT) is shaping up. Let the BFT replicas be collectively incentivized for them to have a tendency to collaborate one another as good team players. In the BFT formulation of ByzCoin (see this post), BFT replicas are linearly queued for them to be able to work orderly. Fortunately, there is a reliable formulation for orderly working BFT replicas to be collectively incentivized with collaboration behavior. Then for most of the time, so incentivized I-BFT replicas can quickly reach a majority agreement. As in our above discussion on the blockchain scalability issue, these most-of-the-time occasions can have the blockchain to ledger document a large number of lineup mining losers. When the I-BFT replicas encounter a less-of-the-time occasion, let thse in-blockchain lineup mining losers work to keep the blockchain running lively. Obviously, the most-of-the-time lineup stockpile of mining losers guarantees that the liveness workforce cannot be used up by the less-of-the-time consumption. The notion of I-BFT constitutes a contribution to the refreshed BFT area of study: liveness for a BFT algorithm.

Observations on some blockchains’ use of cryptography in specific, and on a generally common high cost for constructing permissionless blockchains after Bitcoin (also on a phenomenon of giving up permissionless blockchain to a Proof-of-Stake club membership qualification) give rise to an issue for us to discuss thirdly. Bitcoin, as also being called a cryptocurrency, has led to a needed prosperity in the area of cryptography. Before Bitcoin, the use of cryptography has always been to impose unequal difficulties to its uses. Cryptography should be a prohibitively hard problem for an attacker, and an easy treat for the users who behave. However, Bitcoin’s and the afterwards blockchains’ use of cryptography is equally harsh for all. Behaving users are forced to solve a prohibitively hard problem as if they are attackers too. We believe that this indifferently harsh use of cryptography has been responsible for these blockchains to have shown a shared sign of being unsustainable. The lack of sustainability has not only been reflected in specific in these P2P moneys’ unstable value fluctuation, but also raised a general concern on their detriment to the environment. It is our understanding that this indifferently harsh use of cryptography, at least by Bitcoin, is in fact only to achieve a rarity for finding blocks. A level of rarity for block finding is needed to suit Bitcoin’s simple race condition resolution (i.e., the longest fork prevails).

We however consider that a race to extend the blockchain by a non-spam volume of miners is desirable and healthy for selecting the correct and fair documenting out of the concurrently competing ones. Luck is a good means for spam control. The DaoliCloud blockchain’s mining is purposely designed for a non-spam volume of miners to win a lucky lottery and qualify a concurrent competition for extending the blockchain. As for “there are a thousand Hamlets in a thousand people’s eyes” race Hamlets, the I-BFT servers can usually reach a majority agreement on seeing a single Hamlet. They use public-key cryptography, digital signatures in specific, to authenticate their single Hamlet, and impose it on for the 999 people to accept. The indifferently harsh difficulty use of cryptography for miners to extend blocks in several previous blockchains is corrected. The correct use of cryptography in DaoliCloud lets miners extend the blockchain with resounding, reliable, and authentication confidence, and imposes a prohibitively high deviation cost on any attacker.

Table of Content

An Open Programming Platform for P2P Computing

First of all, the permissionless luck based mining is open to all client and server device possessors to become DaoliCloud miners. This is the openness for mining participation. The openness for mining participation is very important. It is the basis for DaoliCloud to become a truly open programming platform with endless supply of resource for hosting applications that are to be programmed by open programmers.

When mining participation becomes more and more popular, the I-BFT route to extend the blockchain becomes less and less profitable. Nevertheless, the CR-Payroll route for participants to providing the blockchain with resource can become more and more profitable. Programmers can use CR-Payroll enlistees’ supply of resource to code and host various applications. Therefore, the CR-Payroll enlistees can choose for their enlisted devices to participate in providing CPU-processing, networking and storage resources for applications, in exchange of receiving incentive rewards.

In fact, the following might be more likely cases for a large volume of computer resource owners to participate in DaoliCloud. It is the applications that attract a vast number of device possessing users to use the applications. It is in the use of the applications that the vast number of device possessing users are participating in DaoliCloud for mining and for resource supplying.

Table of Content