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 DB-Payload, 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”. We have named the enlisting of these “losers” CR-Payroll (CR stands for computer resource, see this post). Let us now describe who these CR-Payroll enlistees 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 post we have described a KeyBlock-MicroBlock separation idea of Bitcoin-NG. In this post, we have further described a novel use of Bitcoin-NG’s KeyBlock-MicroBlock separation. The separation allows us to formulate a concurrent competition in realtime among a plural number of MicroBlocks which have qualified the competition as the result of their respective KeyBlocks having won in the immediately preceding PoL mining session. The concurrent 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 agreement on a “Confirmed block appended to the blockchain”. Then a concurrent competition takes place among “Non-spam quantity of concurrently competing MicroBlocks”. (As for why and how the concurrently competing MicroBlocks have a non-spam quantity, let that be the topic for a near future post.) These concurrently competing MicroBlocks point to, i.e., they follow by referring to, the “Confirmed block appended to the blockchain”. The dissemination of these concurrently 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 concurrently 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 concurrently 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 concurrently competing KeyBlockTrees will be chosen and certified by a 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 concurrently 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 DB-Payload and CR-Payroll. The CR-Payroll records are public-key addresses which have not won the blockchain extension competition. Let each concurrently competing MicroBlock creator hope that only itself would win the concurrent competition to extend the blockchain. Such an “only-self-to-win-believer” who is in the position of a concurrently competing MicroBlock creator should also write in its MicroBlock the public-key addresses of its fellow concurrent competitors. These public-key addresses have been exposed to all miners by the KeyBlocks to have qualified their creators to participate in the current epoch concurrent competition. Therefore each of the concurrently competing MicroBlock creator as an “only-self-to-win-believer” can indeed write precisely the public-key addresses of all the other “losers”, i.e., its fellow concurrent competitors, into its MicroBlock as CR-Payroll records.

Most of the time in a DaoliCloud epoch, one unique concurrently competing MicroBlock being the root of a KeyBlockTree will be chosen and certified by a majority of the BFT servers. This MicroBlock will exclusively enter its compilation of DB-Payload and CR-Payroll records. These DB records are all immutably documented. The immutability of DB-Payload is due to the correctness and fairness properties of the blockchain. The immutability of the CR-Payroll enlistees, i.e., the public-key addresses of the concurrently competing “losers” are due to the following two facts. (1) The MicroBlock which has won to document the CR-Payroll records is immutably appended to the blockchain history. (2) The public-key addresses as CR-Payroll enlistees 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. A less of the time occasion is when the BFT servers fail to reach a majority agreement on choosing and certifying a unique KeyBlockTree. The blockchain must still run lively in these less of the time occasions. It is in these less of the time occasions that the miners of the lineup public-key addresses as Payroll enlistees will come up to create MicroBlocks and participate in the concurrent competition. With the CR-Payroll enlistees fully lined up in most of the time epochs, the blockchain will always run lively in less of the time epochs. Most of the time lineup CR-Payroll enlistees cannot be used up by less of the time consumption of the enlistees.

Liveness is a non-trivial problem for permissionless blockchains. To really guarantee liveness, we need to be sure that “most of the time” is really more frequent than “less of the time”. In a future post we shall see that this is indeed the case from DaoliCloud’s invention of Incentive BFT (I-BFT) algorithm.

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 concurrently 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”. This randomized algorithm is very simple. Each BFT server shall select a unique KeyBlockTree with the median tree size to certify. All other sized KeyBlockTrees will be discarded. It is possible to have more than trees in the median positions, e.g., either in the case of an even number of KeyBlockTrees in the competition, or for the case of “tie-size”, i.e., more than one KeyBlockTrees have the same median size. Upon encountering these cases, the BFT server shall select and certify “the first median tree”, meaning the first position decided by numerical sorting the MicroBlock roots of these KeyBlockTrees. All the KeyBlockTrees which have not been selected by “Result-Random-Algorithm” are discarded as having lost the current epoch of concurrent competition.

A massive number of amateur miners generate a noisy and random KeyBlocks dissemination traffic which is completely out of control of any node(s) in the network. A batch mining Sybil attacker who attempts to fine tune the sizes of the resultant KeyBlockTrees at the end of the BFT servers faces an uncomputable problem of working out something meaningful from randomness in the short mining time. This does not make sense at all.

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 competing for a mining upper hand has been ever intensifying among professional miners. They mine using ever increasingly more powerful machines, some using purposely designed hardware, e.g., GPUs, FPGA, and ASIC circuits, and some yet even aggregating a massive farm of powerful mining machines, known as farming, in large data centers. Mining in large data centers which are located in places of cheap electricity has become a norm for 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 of concurrent competition. Then the concurrent 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 of concurrent competition. In these less of the time cases, an algorithmically pre-determined number of miners whose public-key addresses have been lineup in stockpile in the blockchain as CR-Payroll records shall qualify to complementarily join the concurrent competition. Thus the next epoch of concurrent competition shall remain healthy and alive.

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 chosen by a majority of the BFT servers because the non-spam size passes the selection by “Result-Random-Algorithm” (review this post for the definition of “Result-Random-Algorithm”). 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 concurrent 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, the non-spam size should suit sufficiently many KeyBlocks to expose the same many public-key addresses to be lineup in the blockchain DB as CR-Payroll 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.

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 agreement on a unique KeyBlockTree. Then there would not be a healthy number of MicroBlocks to participate in the next epoch of concurrent 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 CR-Payroll records shall be the complement qualifiers to join the concurrent competition in the next epoch.

Since every qualified concurrent competitor knows the public-key addresses which have been exposed by the KeyBlocks in the “Result-Random-Algorithm” picked KeyBlockTree, the DB writing action for documenting them as CR-Payroll records is to place these exposed public-key addresses in each of these concurrent competitors created MicroBlocks. In doing so, each concurrent competitor hopes that only itself would uniquely win the concurrent competition and thereby correctly write records to the blockchain DB. Different MicroBlocks creators write different records. The records written in the uniquely chosen 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 concurrent competitors are, but also some of them are complementary competitors for an otherwise inadequately participated concurrent competition. The volume of concurrent 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 (IP-aaS). An IP-aaS 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 IP-aaS 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 IP-aaS gateway.

A simple way to realize such an IP-aaS for the blockchain participants is for with-WAN-IP-address participants to function as a Reverse Proxy Gateways for client-end participants. The IP-aaS 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 IP-aaS server, should use more than one other IP-aaS gateway servers. In particular, an IP-aaS server should avoid directly using its own WAN-IP to face WAN. Instead, all blockchain participant should use indirect, with redundant, IP-aaS gateways to face WAN. This way, broadcasting blocks can reach a participant with a high probability even some of its IP-aaS gateways is under a DDoS attack. DDoS attackers can find no interest in attacking DaoliCloud.

The IP-aaS 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.

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 concurrently 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 (IP-aaS, see an implementation in this post). Using the IP-aaS, 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 blockchain, its miner is free to drop off becoming offline. Maybe someday the miner returns online to spend the coins it has, or better to mine more coins. Maybe it will never show up anymore (after having spent coins). An offline node will no longer be involved in any DBMS maintenance job, just like a quit-job former employee. We notice that in known permissionless blockchains, winners are already much fewer than losers. We also notice that the computing, networking and storage resource suppliers of such blockchains are only the online having won miners, but such low supplied resource is highly demanded by many losers. We consider that the low-supply-high-demand unbalance is responsible for the well-known blockchain poor scalability problem. Ease of free dropping off of the already won miners only makes the poor scalability problem worse.

The DaoliCloud blockchain “employees” include not only the former concurrently 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 CR-Payroll records 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 concurrently competing MicroBlocks. Both of these two kinds of “employees” have a high interest in maintaining the DBMS for it to be 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 find the status of these “employees”, e.g., by pinging to know online responsiveness.

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 IP-aaS 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 IP-aaS 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 IP-aaS 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 (see, e.g., Figure 3.9 in this book), 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. Recall that the DaoliCloud blockchain’s BFT servers work in an incentive induced collaboration (I-BFT, see this post). Thus, the incentive rewarding depends on the result of their collaboration in their refereeing job, i.e., the incentive rewarding can only be materialized after their refereeing job has completed. Clearly, this afterwards collaboration result based coin rewarding should better be performed by a programmable code, i.e., smart contract. In contrast, Bitcoin’s hardwired “coinbase transaction” code being executed by the single won miner can hardly incentivize miners to collaborate.

In the DaoliCloud blockchain’s rendering, many qualified concurrently competing MicroBlock creators shall execute this coin-rewarding smart contract to record the unique execution result in their concurrently competing MicroBlocks. The execution correctness is guaranteed by the concurrent comparison.

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 concurrently competing MicroBlock creators. Therefore, the correctness and fairness of a coin-rewording smart contract in the DaoliCloud blockchain can have its execution result redundantly and reliably checked. This way of concurrent 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 the DB-Payload records such as the payment transactions as Bitcoin and Ethereum doing, the DaoliCloud blockchain also immutably documents and maintain the CR-Payroll 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 CR-Payroll records of KeyBlock mining “losers” mean that the blockchain has enlisted 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.