DaoliCloud: Decentralized Autonomy of Lineup Cloud Servers

Blog

April 2021

DB Records Lineup

A blockchain DB has its records in a lineup organization so that the records once entered the DB are immutable. As a matter of fact, along the way of lining up usual records such as payment transactions, any known PoW mining based permissionless blockchain lines up the public-key addresses of the won miners to form its immutable history. The DaoliCloud blockchain is a little unusual in lining up public-key addresses of miners. It lines up not only those of the mining winners, but also very importantly, those of many “losers”. Let us now describe who these “losers” are and how their public-key addresses can be lined up immutably. Immutability is a very important security property for a blockchain. Therefore, the algorithms to correctly lineup mining winners and “losers” need to be clearly described.

In this previous post we have described a KeyBlock-MicroBlock separation idea of Bitcoin-NG. In this previous post, we have further described a novel use of Bitcoin-NG’s KeyBlock-MicroBlock separation. The separation allows us to formulate a parallel competition in realtime among a plural number of MicroBlocks which have qualified the competition as the result of their respective KeyBlocks having won in an immediately previous PoL mining session. The parallel competition can enable not only fair and correct maintenance of the DBMS, but also an important property of blockchain liveness, for a permissionless blockchain. Figure “A DaoliCloud Epoch” below illustrates an epoch of the blockchain DB record entering in the DaoliCloud blockchain.

A DaoliCloud Epoch

A DaoliCloud Epoch begins immediately after the BFT servers reach a majority consensus to have agreed on a “Confirmed block appended to the blockchain”. Then a parallel competition takes place among “Non-spam quantity of parallel competing MicroBlocks”. (As for why and how the parallel competing MicroBlocks have a non-spam quantity, let that be the topic for a near future post.) These parallel competing MicroBlocks point to, i.e., they follow by referring to, the “Confirmed block appended to the blockchain”. The dissemination of these parallel competing MicroBlocks will initiate (ignite) all miners to PoL mine another non-spam quantity set of KeyBlocks, with each of these new KeyBlocks to follow by referring to hashing one of these parallel competing MicroBlocks.

DaoliCloud’s KeyBlock mining is permissionless, with the mining output forming a plural number trees as the bottom part of Figure “A DaoliCloud Epoch” depicts. Let such a tree be named a KeyBlockTree. The root of a KeyBlockTree is one of the “Non-spam quantity of parallel competing MicroBlocks” in the figure, and the leaves of a KeyBlockTree are some newly mined “Proof-of-Luck KeyBlocks” in the figure. Most of the time in DaoliCloud epochs, one unique KeyBlockTree among these parallel competing KeyBlockTrees will be chosen and certified by a consensus majority of the BFT servers for its MicroBlock root to be appended to the blockchain. Less of the time (i.e., other than most of the time) in DaoliCloud epochs, the BFT servers fail to choose and certify a KeyBlockTree, i.e., an epoch with no output. To this end of whichever of these two cases, the current DaoliCloud Epoch completes.

In the current epoch, the creators of the parallel competing MicroBlocks are competing for each of them to be the solely winner for exclusive right to enter records to the blockchain DB. Each competing MicroBlock creator shall therefore write in its MicroBlock conventional DB records such as payment transactions. This part of the conventional DB records are parallel competing for the records’ correctness and fairness. In addition to entering the conventional DB records, the DaoliCloud blockchain also features to document a set of unconventional DB records. These unconventional DB records are public-key addresses which have not won the blockchain extension competition. Let each parallel competing MicroBlock creator hope that only itself would win the parallel competition to extend the blockchain. Such a only-self-to-win believer who is in the position of a parallel competing MicroBlock creator should also write in its MicroBlock the public-key addresses which have been exposed by some KeyBlocks. These KeyBlocks have followed, i.e., referred to, a known parallel competing MicroBlock “loser”. The exact algorithms for selecting the unique winner and the “loser” will be clearly specified in the next post.

Most of the time in DaoliCloud epochs, a unique MicroBlock being the root of a KeyBlockTree will be chosen and certified by a consensus majority of the BFT servers. This MicroBlock will exclusively enter the DB not only conventional records, but also a set of public-key addresses as unconventional records. As blockchain conventional DB records are immutable, these unconventional records are also immutably. The immutability of the lineup public-key addresses are a result of the following two actions. (1) The chosen MicroBlock is immutably appended to the blockchain history. (2) The public-key addresses inside each of the chained MicroBlocks are numerically sorted so that their order of sequence is immutably defined.

These immutably lineup public-key addresses of miners enter the blockchain DB in most of the time in DaoliCloud epochs. They will play a very important role in less of the time in DaoliCloud epochs. Less of the time is when the BFT servers fail to reach a majority consensus on choosing and certifying a unique KeyBlockTree. This is when the blockchain still needs to run lively. It is in these occasions that the miners of these lineup public-key addresses will come up to create parallel competing MicroBlocks, for the blockchain to continue running lively. With this unconventional DB records lineup, the DaoliCloud blockchain pioneers a unique novelty for permissionless blockchains: guaranteed liveness.

The block dissemination in DaoliCloud is broadcast to the entire network of the miners. The uniquely correct and fair lineup DB records, conventional and unconventional ones, are known to all miners, no quibble.

Copyright © 2020-2021 DaoliCloud Company. All rights reserved.

Sybil Attack Prevention

Quoting Wikipedia on Sybil:

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 sheer 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, KeyBlock mining is about voting. A number of KeyBlock miners follow, i.e., refer to, a MicroBlock among all of the parallel competing MicroBlocks, for the being followed MicroBlock to be appended to the chain.

An influence obsessing miner, i.e., a Sybil attacker, if it is targeting to have its influence attacking the current epoch, it then needs to aim at a particular MicroBlock of its own interest, and try to use its mining effort to have the targeted MicroBlock to be appended to the chain. However, the voting scheme in DaoliCloud is what we name “Result-Random-Algorithm-1”. This randomized algorithm is very simple. Each BFT server shall select a unique KeyBlockTree with the uniquely middle size to certify. (Almost) All other sized KeyBlockTrees will be discarded for the current epoch. In the tie case of encountering more than one KeyBlockTrees having the same middle size, the BFT server shall certify the tree in the middle position among the tie sized trees. Here, “in the middle position” means the position of numerical sorting the MicroBlock roots of the tie sized trees.

Thus, a Sybil attacker might instead want to try to add influence in some unspecific future epochs. We shall later know that it is impossible for a Sybil attacker to target influencing any specific future epoch. Again, to the Sybil’s dismay, DaoliCloud uses a “Result-Random-Algorithm-2” to select some KeyBlocks for them to qualify parallel competitions in some unspecific future epochs. This randomized algorithm is to select a “loser” KeyBlockTree. In the preceding post we have discussed the very important use of some unconventional DB records for a permissionless blockchain to have a liveness property in any less of the time occasion. The “Result-Random-Algorithm-2” for selecting some KeyBlocks is the same simple as the “Result-Random-Algorithm-1”. It selects the unique KeyBlockTree which has “the next middle size” to the uniquely middle sized KeyBlockTree that has been selected by “Result-Random-Algorithm-1” as we have described in the preceding paragraph. The KeyBlocks in this KeyBlockTree, in fact, the public-key addresses exposed by the KeyBlocks, will be lineup documented by the MicroBlock which is created by the unique winner of the current epoch, for liveness uses for some unspecific future epochs. All other KeyBlockTrees which have not been selected by either of these two randomized algorithms are of the real losers for the current epoch, and are discarded. Sybil attackers are most prone to generating to-be-discarded KeyBlockTrees since it is a very difficult problem to batch mine KeyBlocks while at the same time to fine tune the sizes of resultant KeyBlockTrees.

For a Proof-of-Luck mining blockchain, cheating is hard and might is not right.

Copyright © 2020-2021 DaoliCloud Company. All rights reserved.

Profitable Mining in Need of Spam Control

A permissionless miners managed blockchain with profitable coin mining when gaining a householder name will attract enthusiastic miners to join in. The more miners join in, the noisier the block dissemination traffic in the blockchain network will be. If the blockchain does not control the volume of its block dissemination traffic, sooner or later it would find its network getting jammed by the announcements of 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 block dissemination traffic. One is designed and unfortunately has been loophole bypassed. The other is undesigned but has turned out to be surprisingly effective.

Let’s first describe the designed method. In anticipation of a growing enthusiasm of joining in miners, Nakamoto designed a function to increase the computational cost for finding a Bitcoin block. All miners in the Bitcoin peer‐to‐peer network will algorithmically increase the block finding cost to keep targeting the ever increased number of miners. The cost increasement algorithm that Nakamoto designed can be described as follows in specific. For finding of every 2016 blocks, the block searching space, i.e., the input variable space, of the PoW hash function is enlarged according to a global consensus algorithm. With Bitcoin’s block finding time being stably at one block in an average of every 10 minutes, time for finding 2016 blocks works out to two weeks. In other words, the mining cost increasement happens roughly every two weeks. The exact formula for this controlling algorithm can be seen in, e.g., Chapter 5 of this highly recommended book on Bitcoin by Narayanan-Bonneau-Felten-Miller-Goldfeder. We however know that the enlargement of a bruteforce searching space has an exponential speed in time variable. Therefore, the spam control method designed by Nakamoto is rebustly effective. This robust effectiveness has an amusement of being loophole bypassed. We shall come back to see it after having described an undesigned method for Bitcoin mining spam control.

The second way to have deflated Bitcoin mining traffic from endangering DDoS-attack-like volume is completely unanticipated by Nakamoto. Since Bitcoin mining became a householder name for a high profitability, an arms race of using ever increasingly more powerful, with some being purposely designed, e.g., GPUs, FPGA hardware, and even ASIC circuits, and yet still an aggregation of massive batch of such 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 achieve a business standard of excellence, Bitcoin mining spam prevention has fortunately achieved a professionally excellent status quo: the block 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 Bitcoin mining business. The highly centralized Bitcoin miners are factually demanding the very idea of placing 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.

Copyright © 2020-2021 DaoliCloud Company. All rights reserved.

DaoliCloud Mining Traffic Flow Control

PoL mining for KeyBlocks in DaoliCloud has a much eased PoW difficulty than that for Bitcoin mining, and therefore can output a plural number of blocks which are the leaf nodes of the forky trees in Figure “A DaoliCloud Epoch” (in this post). As the preceding post envisions, so much eased KeyBlock mining is in need of spam control. Let us now describe a consensus algorithmic method for KeyBlocks spam control.

Let QUIET and NOISY denote two experiment determined constants with QUIET < NOISY and let the interval (QUIET, NOISY) be named Mining Difficulty Interval. A KeyBlock mining DIFFICULTY should be adjustable in such a manner that the number of valid KeyBlocks output from a KeyBlock mining phase be inside the interval (QUIET, NOISY). If in a mining phase the number of valid KeyBlocks is smaller than QUIET, then the miners and/or block forwarding/validating nodes should lower DIFFICULTY by a pre-specified percentage for the next mining phase. Likewise for the opposite case of valid KeyBlocks’ number being larger than NOISY, the global nodes should higher DIFFICULTY by a pre-specified percentage for the next mining phase. Thus, by algorithmically adjusting DIFFICULTY, the traffic flow for KeyBlocks mining can be dynamically controlled to be within the interval (QUIET, NOISY).

Our experiments have shown that a small value of percentage for lowering/highering DIFFICULTY is desirable in order to tolerate nodes with different sensitivities in response to the global consensus on DIFFICULTY. With a mild tuning, this traffic flow control algorithm may sometimes find itself not swift enough. It may happen that the tuning is too microscopic to catch up quickly the dynamic change of the mining traffic flow. Then KeyBlock mining may temporarily have a too quiet or too noisy traffic to require a number of tuning steps for the mining traffic flow to become inside the interval (QUIET, NOISY). In the too quiet case, the BFT certified KeyBlockTree will have a too small size to qualify too few MicroBlocks to join the next epoch parallel competition. Then the parallel competition won’t be sufficiently healthy. In the too noisy case, the BFT servers may be simply spammed and not able to certify a KeyBlockTree. Then there would be no MicroBlock at all for the next epoch parallel competition. In these cases, an algorithmically pre-determined number of miners whose public-key addresses have been lineup in stockpile in the blockchain as unconventional DB records shall qualify to complementarily join the parallel competition. Thus the next epoch parallel competition shall remain healthy and live.

Modern network has a rather large bandwidth and a usually quick response. The forky KeyBlockTrees in the bottom part of Figure “A DaoliCloud Epoch” (see this post) can have their sizes be controlled by a mining difficulty consensus algorithm not to often reach a spam level.

Most of the time, exactly and uniquely one of these non-spam sized KeyBlockTrees will be majority consensus chosen by the BFT servers because the non-spam size passes the selection by “Result-Random-Algorithm-1”. This non-spam size of the KeyBlockTree should suit not only the tree’s MicroBlock root to be appended to the blockchain, but also sufficiently many miners who have won the KeyBlock mining by luckily following the correct MicroBlock root. These sufficiently many miners qualify to generate new MicroBlocks to participate the parallel competition for the next epoch. Their qualifications to generate new MicroBlocks are that these MicroBlocks are digitally signed and are verifiable using the public keys which are exposed by the newly won KeyBlocks in the selected KeyBlockTree.

Also most of the time, another uniquely one of these non-spam sized KeyBlockTrees will be majority consensus chosen by the BFT servers because the non-spam size passes the selection by “Result-Random-Algorithm-2”. This non-spam size should suit sufficiently many KeyBlocks to expose the same many public-key addresses to be lineup in the blockchain DB as the unconventional records. This second lot of sufficiently many lineup public-key addresses will stockpile sufficient supply of workforce for less of the time occasions when the blockchain shall remain running lively. Review this post for these two “Result-Random-Algorithms”.

Here let’s explain a little more about the less of the time occasion. Less of the time, the BFT servers chosen and certified KeyBlockTree may have too few KeyBlocks being leaves, or even worse, the BFT servers have not reached a majority consensus to agree on a unique KeyBlockTree. Then there would not be a healthy number of MicroBlocks to participate in the next epoch parallel competition. Upon such a less of the time occasion, a number of miners whose public-key addresses have been in stockpile and lineup in the blockchain as unconventional DB records shall be the complement qualifiers to join the parallel competition in the next epoch.

Since every qualified parallel competitor knows the public-key addresses which have been exposed by the KeyBlocks in the “Result-Random-Algorithm-2” picked KeyBlockTree, the DB writing action for documenting these unconventional blockchain DB records is to place these exposed public-key addresses in each of these parallel competitors created MicroBlocks. In doing so, each parallel competitor hopes that only itself would uniquely win the parallel competition and thereby correctly write records to the blockchain DB. Different creators of different MicroBlocks may write different records. The records written in the uniquely won MicroBlock become the correct history which is immutably documented by the blockchain DB.

To this end, we know that all miners in the DaoliCloud blockchain always know not only who the parallel competitors are, but also some of them are complementary competitors for an otherwise inadequately participated parallel competition. The volume of parallel competitors is always controlled at a sufficiently many and non-spam level.

Copyright © 2020-2021 DaoliCloud Company. All rights reserved.

Denial of Service Attack Avoidance

For spam and Sybil attacks, as they play the rules of the blockchain game, algorithmic measures are suitable for their prevention. However, for Denial of Service (DoS) attacks, including more powerful versions of Distributed DoS (DDoS), as they simply and brutally flood the targeting IP addresses with a mass number of mundane or invalid network packets, the correct approach to such attacks is not prevention, but avoidance.

The DaoliCloud blockchain is a cloud platform to have in stockpile of a mass number of permissionless participants to provide cloud services. One of such cloud services is what we name IP-Address-as-a-Service (IPaaS). An IPaaS server should be an always online computer with public IP address. A server side (such as datacenter server, a cloud virtual machine or a container) computer can play the role of an IPaaS server gateway by interfacing in-between its public wide-area-network (WAN) IP address and the not-publicize-able-IP-address of a client side (such a home PC, a smartphone or an IoT device) computer. In this interfacing gateway function, the not-publicize-able-IP-addressed client can be viewed as a local-area-network (LAN) computer inside the IPaaS gateway.

A simple way to realize such an IPaaS for the blockchain participants is for with-WAN-IP-address participants to function as a Reverse Proxy Gateways for client-end participants. The IPaaS participants can advertise their WAN-IP addresses on the cloud platform, for the client-end participants to connect as reverse proxy gateways. Having the blockchain DB recorded lineup both of these participants in stockpile, they can be easily found and managed by the application software to provide useful applications for the cloud users.

Now to avoid DDoS attacks, each blockchain participant, even an IPaaS server, should use more than one other IPaaS gateway servers. In particular, an IPaaS server should avoid directly using its own WAN-IP to face WAN. Instead, all blockchain participant should use indirect, with redundant, IPaaS gateways to face WAN. This way, broadcasting blocks can reach a participant with a high probability even some of its IPaaS gateways is under a DDoS attack. DDoS attackers can find no interest in attacking DaoliCloud.

The IPaaS is in fact a network virtualization technology. Virtualization, whether for CPUs, networking or storage, is about adding a layer of indirection. In computer science, indirectness is usually better than directness.

Copyright © 2020-2021 DaoliCloud Company. All rights reserved.

Why and How for BFT to Work 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 consensus 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 an unconventional BFT algorithm. It avoids dealing with any time ordered sequence of messages.

In a PoL KeyBlock mining phase, a KeyBlock that follows, or votes for, a parallel 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 by a validator before a timeout event after the dissemination time of the MicroBlock that the KeyBlock votes for.

A BFT server in DaoliCloud is a KeyBlock validator with a Certification Authority (CA) function. It counts the number of valid KeyBlocks that have voted for a valid parallel competing MicroBlock. It does not time order a sequence for the plural number of valid KeyBlocks that vote for the same MicroBlock. The votes counting job for a BFT server is completely a local decision. After mining timeout, the network becomes quiet, in fact, silent, for the mining traffic. Each BFT server can then make its local certification decision and announce the decision with elegance.

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

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

Copyright © 2020-2021 DaoliCloud Company. All rights reserved.

When BFT Meeting Immutability

The BFT servers in the DaoliCloud blockchain non-interactively certify a parallel 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 a BFT server has used its Certification Authority (CA) power w times, it retires and becomes no influence any more for the DBMS maintenance job.

The publicly verifiable immutability of blockchain dictates that the 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.

Copyright © 2020-2021 DaoliCloud Company. All rights reserved.

Low Cost Cloud from Permissionless Blockchain

A network connected computer, be it a high-end server in a datacenter, a virtual machine from a commercial cloud provider, a container dividing a cloud virtual machine, a PC, a laptop, a smartphone, or an IoT device, has CPUs, storage space and network connection, and therefore is a useful piece of IT resource. If there is a good way to organize such computers to work in coordination, they collectively can form a huge cloud of the most powerful CPUs, the largest storage space, and the best network quality of service.

The novel construction to lineup in stockpile a large number of parallel competing “losers” in the DaoliCloud blockchain provides a concrete methodology to build such a “every little helps” aggregated huge cloud. In the construction of this cloud, server nodes such as datacenter servers, cloud virtual machines and containers, can provide, in addition to CPUs and storage spaces, IP addresses as a service (IPaaS, see an implementation in this post). Using the IPaaS, client nodes such as PCs, smartphones, and IoT devices then become useful for aggregating their CPUs and storage spaces to piece together a hugely powerful general purpose cloud.

Having the blockchain lined up both of these nodes in stockpile in the blockchain DB, they can be easily found and managed by the application software to provide useful applications for the cloud users. For example, user data can be stored in reliable redundant duplication, like Redundant Array of Inexpensive Disks (RAID), and in case when a lineup storage node for a user data is found not responsive, the storage management software can find a replacement storage node in the lineup stockpile to backup the user data for it to remain in a reliably redundant state.

This permissionless blockchain aggregated cloud should be a low cost one because it is constructed by a huge number of amateur redundant computers which have redundant resource otherwise not being used. Amateur resource owners bring their redundant unused resource to participate the permissionless blockchain, and by providing cloud resource servers to mine cryptocurrency coins, and/or earn service payments, they become small business vendors.

Copyright © 2020-2021 DaoliCloud Company. All rights reserved.

Sufficiently Redundant Stockpile of "Employees"

A permissionless blockchain must tolerate a high “employee attrition rate”. After a block is appended to the chain, its miner is free to drop off becoming offline. Maybe someday the miner will return online to spend coins it has or better to mine more coins. Maybe it will never show up anymore. An offline node does not provide the DBMS maintenance service, just like a quit-job former employee. Because the previously successful miners have a better financial interest in maintaining the DBMS in good order, it is not desirable for a permissionless blockchain to have a very high “employee attrition rate”.

The DaoliCloud blockchain “employees” include not only the former parallel competing winners who have been appended to the chain, and hence let them be named “chained employees”, but also a much bigger number of “losers” whose public-key addressed IDs have also been entered the DB as data in stockpile, and hence let them be named “stockpiled employees”. The “stockpiled employees” is a much bigger labor force than the “chained employees” since each epoch only chooses one winner out of many parallel competing MicroBlocks. Both of these two kinds of “employees” have a high interest in maintaining the DBMS in good order. Therefore, the DaoliCloud blockchain can tolerate a really high “employee attrition rate” to still function sufficiently redundantly widely distributed.

With the “stockpiled employees” linearly lined up as DB records, it is very easy to manage their online status. Since many of them should also keen to provide cloud resource service, a smart contract like maintenance software which runs for the interest of the resource users can manage their quality of service, even for the purpose of paying for their service provisioning. A service demand-supply match making software can also know the online status of the “employees”, e.g., by pinging them to know their availability for service provisioning.

Copyright © 2020-2021 DaoliCloud Company. All rights reserved.

When Blockchain Becoming an Operating System

To this end, we have seen that the DaoliCloud blockchain is in fact an operating system to manage permissionless resource for a general purpose computer. Using this OS, users can easily manage their CPUs, storage spaces and networking connections. Below, let us provide several usecase examples for the blockchain OS usage.

For an example, let a user want a web server to be hosted in, and managed by, the blockchain OS. It can disseminate a request transaction for, e.g., a WordPress platform like service. When one or more nodes respond for the request, the user can choose a configuration, e.g., a few IPaaS providers and a few storage hosting providers. Here, “a few” means a normal case of using a number of providers as redundant replicas in case some of them permissionless dropping off without causing service stoppage.

For another example, a Domain Name Server (DNS) can also has be hosted by the blockchain OS. Then the web server user can also register a unique domain name for its website, and manage the mapping between its registered domain name and the IP addresses which are provided by the IPaaS providers. In this usecase, the uniqueniss of the domain name by a unique root domain name to postfix a name string. The blockchain immutability property can guarantee the uniqueness of any name which is submitted for registration. With a fee payment which not only prevents domain name squatting, a blockchain wallet user may buy an unregistered name to be associated with its wallet public-key address. It is easy for the BFT servers to check the registration status of a name given the immutability property of the blockchain. Then a registered name owner can manage RR records, such as an A record for mapping a name to an IPv4 address, an AAAA record for mapping a name to an IPv6 address, or an MX record for mapping a name to an email address, for its registered name to lookup IP addresses that the user is using from its IPaaS servers.

For yet another example, consider a user’s web server is in need of SSL cryptographic security. Recall that the DaoliCloud blockchain uses BFT servers to function for immutable Certification Authorities (CAs). Upon receipt a public-key certificate issuance application as a user transaction, the BFT servers can conduct on-chain validation, e.g., by a challenge-response mechanism, to see if a user is capable of making consistent connections between a registered name ownership, an IP, and its wallet public-key address. A challenge can be a random text string TXT to send to the applicant user’s wallet, for it to place as an RR TXT record in the domail name server. Afterwards, the BFT servers can conduct an on-chain validation to see if the challenge TXT record, the registered name, and the requesting wallet’s signatures prove the name ownership. If the proof returns YES, the BFT servers can issue an immutable certificate to the users to secure its website.

Being able to conduct on-chain validation is a great usefulness that a blockchain becomes an OS to manage IT resources for general purpose computing.

Copyright © 2020-2021 DaoliCloud Company. All rights reserved.

Storage as a Service

Juels and Kaliski initiated an interesting research topic in 2007 with the name “Proofs-of-Retrievability” (PoR). A PoR scheme enables an archive or back-up service, as a prover (in the position of “Cloud Servers” in the title figure) to produce a concise proof that a verifier (in the position of “Third Party Auditor” in the title figure) can retrieve a target file F, that is, that the archive retains and reliably transmits file data sufficient for the user (in the position of a client device in the title figure) to recover F in its entirety. Obviously, for PoR to make sense, a proof-verification transcript between the prover and verifier need to have a much smaller size than the size of F.

Briefly described, a POR protocol in the original work of Juels and Kaliski encrypts F and randomly embeds a set of randomly-valued check blocks called sentinels. The use of encryption renders the sentinels indistinguishable from other file blocks. The verifier challenges the prover by specifying the positions of a collection of sentinels and asking the prover to return the associated sentinel values. If the prover has modified or deleted a substantial portion of F, then with high probability it will also have suppressed a number of sentinels. It is therefore unlikely to respond correctly to the verifier. The beginning of the PoR notion coincided with the rise of cloud computing for which cloud storage is an easily understandable usecase scenario. Since the original work of Juels-Kaliski, research and development in PoR have flourished to a hot area of study. Many interesting research topics have been proposed, and some useful applications have been implemented.

Cloud storage is an obvious application for making a good use of the sufficiently redundant stockpile of “employees” in the DaoliCloud blockchain. Since an “employee” working for a permissionless blockchain is free to quit job, a PoR scheme would be very useful for a permissionless blockchain based cloud storage service to be able to guarantee that the user’s data stored in the blockchain cloud must always be available. It is useful to notice that such a PoR protocol should run in decentralization as a blockchain offered functional service. The service can be coded in a smart contract running in the blockchain for a “Third Party Auditor” to automatically and often send auditing data to the user. It is also desirable for the proof-verification transcripts to be used as evidence for the PoR smart contract to make cryptocurrency payments to the storage servers for their service provisioning.

As a zero-knowledge proof protocol, using a hash function to output a computationally uncontrollable challenge, a PoR proof interaction can transformed into a non-interactive proof transcript. Such a transcript is publicly verifiable, exactly in the same manner of a publicly inspectable legally binding evidence. PoR in non-interactive proof enables a smart contract implementation for DaoliCloud’s Storage-as-a-Service to have a PoR quality. In the next post let us exemplify a smart contract coded PoR usecase.

Copyright © 2020-2021 DaoliCloud Company. All rights reserved.

Smart Contracts

Quoting Wikipedia, a Smart Contract can be briefly described as follows:

A smart contract is a computer program or a transaction protocol which is intended to automatically execute, control or document legally relevant events and actions according to the terms of a contract or an agreement. The objectives of smart contracts are the reduction of need in trusted intermediators, arbitrations and enforcement costs, fraud losses, as well as the reduction of malicious and accidental exceptions.

Vending machines are mentioned as the oldest piece of technology equivalent to smart contract implementation. 2014’s white paper about the cryptocurrency Ethereum describes the Bitcoin protocol as a weak version of the smart contract concept …

Indeed, a valid block output from Bitcoin PoW mining is a vending-machine-like smart contract which is implemented by a hardwired code called a “coinbase transaction” in the block, to agree on rewarding some coins to the block miner. The coinbase transaction in a Bitcoin block is a valid coin-rewarding contract binding between the block miner and the rest of all other miners. Since the 2015 launch of the Ethereum blockchain, the term “smart contract” has been more specifically applied toward the notion of general purpose computation that takes place on a blockchain. It is whether or not a smart contract is programmable that makes the only and valuable difference between smart contracts in the general purpose computation version of Ethereum and in “a weak version” of Bitcoin. This difference makes Ethereum a blockchain computer, although with the block mining remaining one-way arms race to a prohibitively high cost.

Let us use coin rewarding as a usecase to expose the usefulness of smart contract being programmable. The BFT servers in the DaoliCloud blockchain should be rewarded with coins for their correct and fair choosing and certifying a parallel competing MicroBlock. Recall that a non-interactive working BFT server in DaoliCloud uses its local decision on a MicroBlock creator’s DBMS maintenance correctness and fairness, and on a criterion on KeyBlocks voting for the MicroBlock, to choose a MicroBlock from a plural number of parallel competing MicroBlocks, certify the chosen MicroBlock and announce its certification. Some time after the BFT servers have completed the certification, an on-chain program can be executed to parse each BFT certification output, and reward cryptocurrency coins to those BFT servers who were members of a consensus majority group to have output consistent certificates for the same MicroBlock.

As a function to compute on some inputting data, this coin-rewarding program can only be executed (possibly long after) when the inputting data become available as the BFT servers’ certification result. Also, for redundancy reliability, this coin-rewording program should be executed independently by a plural number of nodes for the execution correctness to be redundantly and in consensus majority confirmed through parallel comparison. Clearly, this programmable method of DaoliCloud’s coin-rewarding contract works much smarter than that of the Bitcoin hardwired coinbase code in a miner’s block does, since in the latter contract, the single miner has not got the full knowledge of the blockchain state yet.

In the DaoliCloud blockchain, letting the qualified parallel competing MicroBlock creators in a subsequent epoch execute this coin-rewarding smart contract and record the unique execution result in their parallel competing MicroBlocks is a sound rendering.

Copyright © 2020-2021 DaoliCloud Company. All rights reserved.

Smart Contract as Secure MultiParty Computation

Ethereum as a programmable blockchain computer, smart contracts are executed by competing miners. As Bitcoin, each mining competition phase in Ethereum can only have one miner to win the DB writing right by having its block appended to the blockchain. In speak of a smart contract being executed by competing miners, it is only this won miner whose execution of the smart contract that matters. In fact, usually an Ethereum smart contract requires to pay a transaction fee, called “gas”, to execute, and it is the only won miner who completes the execution of a smart contract and collects the gas. Therefore in general, an Ethereum smart contract is executed by a single node.

In the preceding post we have described a rendering for the DaoliCloud blockchain to execute a coin-rewarding usecase of smart contract: such a smart contract is executed by a plural of qualified parallel competing MicroBlock creators. Therefore, the correctness and fairness of a coin-rewording smart contract in the DaoliCloud blockchain can have its execution result redundant reliably checked. This way of parallel computing execution of smart contract can be viewed as a secure multiparty computation (SMPC) in a sense of fault tolerance quality. However, SMPC has a more important and orthogonal usefulness. Let us describe a standard usecase of SMPC as follows.

The private key of a blockchain wallet is the only credential for authenticating the ownership of the wallet and the money it holds. Therefore, to secure the private key of a wallet is all important. To our knowledge, well-known blockchains, e.g., Bitcoin and Ethereum, do not differentiate a private key for a mining machine and that for a wallet. However, it should not be very difficult to observe a fact that private keys can have differences. Here we can point out an obvious difference. The private key of a mining node needs to be in the memory of the mining machine in the mining time; however, the private key of a wallet needn’t be usually in the memory because a wallet may even never have a need to mine. As a matter of fact, it is more secure for a wallet to stay offline when it is not involved in a payment transaction.

Different functions for blockchain wallets can be identified and separated. Here are a few: “mining-wallet”, “transaction-wallet”, “joint-wallets”, and even “threshold-wallets”. By programming smart contracts, a miner can express to the blockchain that wallets with different names suggesting different functions actually have the same ownership of itself. The ownership is strongly established through cryptographic authentication. Moreover, using smart contracts, the miner with the ownership of different wallets can express role-based authorization in that, different wallets are authorized to have different functions. For instance, a mining-wallet can only earn coins for some other pre-specified wallets to spend. For another instance, a threshold-wallet needs to produce a threshold number of different signatures to enable a payment transaction.

What is in essence here is that smart contracts can enable programming various functions of secure multiparty computation.

Copyright © 2020-2021 DaoliCloud Company. All rights reserved.

Blockchain as a General-Purpose Computer

Ethereum’s smart contracts are stored programs in the Ethereum blockchain. It is for this reason there exists optimistic statements to say that Ethereum is a general-purpose computer, or even “the world computer” (e.g., a book of Gavin Wood). However, as in Bitcoin, Ethereum’s storage is append only, and everything once stored is permanent; even data deletion is achieved by appending an deletion instruction. Therefore Ethereum as a stored-program computer is a very high cost one, perhaps too high the cost for the computer to be sustainable for the very name’s sake of general-purpose.

In a general-purpose computer, some data, e.g., in particular those for OS kernel functions, should have more or less a permanent lifetime for storage, retrieval, modification and management. A payment system’s “OS kernel” function does have this lifetime property. However, for most applications related data, their lifetimes depend on the lifecycles of the applications. Storing applications data permanently is obviously not a wise design for a general-purpose computer.

In addition to immutably documenting and maintaining conventional blockchain DB records such as the payment transactions as Bitcoin and Ethereum doing, the DaoliCloud blockchain also immutably documents and maintain unconventional blockchain DB records such as a large number of public-key addresses, i.e., identities, of the same large number of miners who we quote as KeyBlock mining “losers”. Immutably documenting unconventional blockchain DB records of KeyBlock mining “losers” mean that the blockchain has prepared a large number of miners in lineup stockpile to be ready working for less of the time when the blockchain encounters liveness breakdown.

There is a yet another usefulness for having a large number of known addressed miners being prepared to work. They form an abundant volume of IT resource for providing cloud services. With the large volume of known addressed cloud service providers under the blockchain management, the DaoliCloud blockchain can play the role of an OS kernel to manage a very large resource pool. Although such a miner is a general purpose computer to be able to store applications and data, we however do not think that such miners’ stored applications and data are not part of the blockchain DB records. It will be the applications’ users decisions for how ephemeral or how permanent for the applications data.

The DaoliCloud blockchain is the first blockchain as a practical general-purpose computer.

Copyright © 2020-2021 DaoliCloud Company. All rights reserved.

Randomness of the BFT Servers

The formulation to organize the 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 BFT servers for DaoliCloud are the latest w MicroBlock creators whose parallel competing MicroBlocks have been appended to the blockchain, also in the sequence of extending 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 the first two blog posts for this month (April 2021), we have described algorithmic steps for a miner to become a BFT server in DaoliCloud. These algorithmic steps form a sequence of being lucky events. The first event for a miner is to be lucky to have successfully mined a KeyBlock. The second lucky event for this miner is that its successfully mined KeyBlock luckily belongs to a KeyBlockTree with a right middle size to pass through the selection by “Result-Random-Algorithm-1”. The third lucky event for this miner is that it has created a lucky MicroBlock to have won the parallel competition for its MicroBlock to be append to the chain. An alternative lucky route for this miner is that its successfully mined KeyBlock luckily belongs to a different KeyBlockTree with another right middle size to pass through the selection by “Result-Random-Algorithm-2”. Then this alternative lucky route for this miner is to join the “losers” lineup queue and wait for a future less of the time occasion to join a parallel competition in the complement manner. This alternative route of luck is designed for the blockchain to run lively.

The two “Result-Random-Algorithms” are executed after KeyBlock mining in an epoch has finished. Because even being an alternatively lucky “loser” can still be profitable by 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 these two “Result-Random-Algorithms”. It is an uncomputable problem for any calculative minded miner to somehow control these random input functions in order for them to output non-random, i.e., computable, results.

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

Copyright © 2020-2021 DaoliCloud Company. All rights reserved.