EzyDepot: An Easy Public-Writing Database

EyzDepot WhitePaper

EzyDepot: An Easy Public-Writing Database

Abstract

EzyDepot is a permissionless blockchain to have security, scalability and decentralization properties together plus greenness. Its block extending algorithm involves a noisy drawing-lots Proof-of-Luck (PoL) game to select a lucky block out of many contending blocks. Let the lucky block record, not only a payload chunk for inputting users’ writing entries to the blockchain database (DB), but also the public key identities of some “unlucky” blocks’ finders, just as recording “uncle block miners” by the GHOST (Greedy Heaviest Observed SubTree) algorithm in Ethereum’s Proofs-of-Work (PoW) version. As in GHOST, these “unlucky” blocks finders in EzyDepot are also dearly called “uncles”. A novel use of the uncles is for them to have the exclusive entitlement to announce correctness verdicts on the user entries to write the DB. By controlling the PoL traffic not to reach a spam level as GHOST doing for its uncles, the uncles’ verdicts spread the peer-to-peer (P2P) gossip network in good order. With uncles in endless supply, the correct user entries are approved by the uncles’ dissemination to saturate the distributed public-writing DB with the efficiency of an epidemic algorithm, and the incorrect ones are discarded in early gossip hops. Thus, the uncles can guarantee the correctness for the public-writing DB in the same function of probability amplification guaranteeing for randomized probabilistic (RP) algorithms. In fact, the uncles’ probability amplification function can prevent concentration of attacking power for a so-called “51% Attack”. As contribution to knowledge, the work of EzyDepot establishes:

$$ \mbox{Blockchains} \subset \mbox{RP(ZPP)} $$

In addition to improving permissionless blockchain for the open ledger usecase, EzyDepot also lines up uncle nodes as an unbound supply of IT resource to organize an open cloud hosting general-purpose P2P applications.

Key Words and Phrases:  Secure, Scalable, Decentralized and Green Permissionless Blockchain.  Proofs-of-Luck (PoL).  Novel Use of GHOST Uncles.  Probability Amplification for Blockchain as a Randomized Probabilistic (RP) Algorithm.  Blockchain as a Fair and Efficient Epidemic Algorithm.  Non-Append-Only Structure for Blockchain Database.  No 51% Attack.  P2P Cloud.

Introduction

Bitcoin \cite{Bitcoin} began the era of open source peer-to-peer (P2P) money and inspired the blockchain technology. The work of EzyDepot taps the potential of the blockchain technology to contruct a secure, public-writing, scalable, easy and quick searching database (DB) for applications ranging from a public ledger to general purpose DB applications. We begin the work presentation with discussions on a number of issues in the blockchain area of study.

PoW Issue of DB Structure as Append Only Untrusted Logs  For Bitcoin to record users’ transactions automatically, Nakamoto made an ingenious use of a Proofs-of-Work (PoW) mechanism of Dwork and Naor for email spam prevention~\cite{DworkNaorSpam}. Nakamoto’s novel use invented the notion for a permissionless written DB to be correct. The PoW mechanism can enthuse permissionless participants in a blockchain to compete one another for composing “correct” blocks to lengthen the blockchain lively. One winner’s block will be selected in each round of competition, and the contend of the winner’s block contains users’ transaction requests as “correct” entries to enter the ledger. The reason why we place the word correct inside the quotation mark is because of a low quality of the correctness. A permissionless competition usually and easily goes into a vicious cycle of quality deterioration. It has become an established belief that a permissionless blockchain using Nakamoto’s PoW competition cannot avoid limitations of inefficiency, slowness, and high cost of use. We shall analyze a likely technical reason behind these limitations. Our analysis pays attention to a low-quality attribute for a permissionless blockchain ledger constructed by the PoW competitors. The attribute is that such a ledger has a one-dimension monolithic structure of append only untrusted logs. Two most popular PoW blockchains, Bitcoin and Ethereum (Ethereum 1.0, the PoW version), stipulate time lengths for their ledgers’ append logs being untrusted as follows. A block, more to the point, its content for the ledger entry, remains untrusted until it has been buried under 7 new blocks appending it.

Using the number 7 to instantiate $n$ in the $n$-blocks-delayed-trust stipulation has a strong stopgap taste as an algorithm specification. This stopgap has fortunately been able to bless only a few PoW blockchains running correctly. The PoW competition in these few fortunate blockchains is formulated to be extremely severe, that finding several blocks in a winning streak by one block generator is such a hard problem to be practically impossible. Assuming that these few fortunate PoW blockchains will forever have this PoW hardness based blessing (and so let us not discuss consequences of this blessing, i.e., inefficiency, slowness, and high cost of use), the delayed trust stipulation has some issues for us to discuss below.

A PoW blockchain’s DB being written only by untrusted parties means that the DB has the structure of appending logs at the end of it as a one-dimension monolithic data chunk. There is never a trusted operator to conduct any DB management job, such as to divide the DB into index addressable small file organization for fast output/input between the internal memory and the external non-volatile storage. Therefore the DB as a one-dimension monolithic data chunk has to forever occupy the RAM at it grows larger and larger. As a result, most of the P2P gossip epidemic network participants in a PoW blockchain soon become no longer affordable for such a large RAM that is necessary to validate the trustworthiness of the DB entries. Their gossip function diminishes to relaying forwarding a syntax level of “correct” block. In our view, the allegedly “51% attack” that a PoW blockchain has to suffer is the direct consequence that most of the participants in the blockchain cannot make contribution to the DB correctness using their P2P gossip function. As an unfortunate matter of fact, the PoW algorithm explicitly instructs the majority of the P2P participants who are low-end device holders to assist few powerful ones by forwarding syntax level of “correct” blocks of the latter to possibly influence the distributed DB with “51% attacking” entries.

To conclude with a fact from our above discussion: the PoW mechanism unfortunately nullifies the very important security function that an epidemic algorithm in a P2P gossip network can efficiently prevent data logs from being entered with any error.

PoS Issue of Single Point of Failure (SPOF) Complexity  In frustration of PoW blockchains’ inefficiency, a so-called “Proofs-of-Stake” (PoS) blocking model emerged. Let a blockchain participant wishing to generate blocks deposit a sum of money, called security stake, in a PoS money lock-up mechanism. The more amount of lock-up money a participant stakes, the more chance for its turn to generate a block. The security stake is for punitive confiscation or destroy (in PoS programmers’ jargon, “money slashing”) when a block generator is found to have either written an error ledger entry, or upon timeout not done its ledger writing duty. A PoS version of “Ethereum 2.0” would be the most eminent PoW-to-PoS switch to take place in a near future of writing this paper.

An elegant property manifested by Bitcoin is as follows. A correctly designed PoW blockchain can never encounter a single point of failure (SPOF). As a sharp contrast, the PoS idea is that the blockchain is always in a state of relying on a consensus algorithm designated (elected, assigned, appointed, or picked by whatever and however means) participant to generate a block for extending the chain and for composing users’ transactions to enter the ledger. Therefore we may regard that a PoS blockchain is always in a SPOF state. As a matter of fact, some PoS blockchains even suffer from rather complex SPOF problems. Below let us discuss a consensus layer issue with some PoS blockchains.

PoS money slashing as a mechanism for deterring DB entry error is an easier-said-than-done idea. First of all, for a network distributed DB, thinking an entry error to be something necessarily to do with the designated block generating participant is already a rather naive understanding on the unreliability of the blockchain network. Secondly, for a group of participants distributed over the P2P network to identify the nature of a DB entry error, this indeed is an absurd idea. We know of an academic conclusion, named “Fischer-Lynch-Paterson (FLP) Impossibility”~\cite{FischerLynchPaterson}. The FLP Impossibility is the following statement. There can never exist a network distributed algorithm, inputting network gossip messages to a group of network distributed participants, for them to output a consensus on a yes/no decision. If designating one participant to generate a block is already a naive SPOF design, this FLP Impossibility issue would add a much more unpleasant SPOF complexity to the system. So far known method to slash money is by manual operations. Even for a manual slashing action, the slasher would still first need to figure out an equitable fungibility exchange rate between an “error” and a money amount to slash. Given that the PoS idea for improving blockchain efficiency is something about a business belief on the richer the more responsible, a PoS blockchain should mainly rely on venture investors’ participation from the business sector. A for-profit business participant will have to discover a comfortable profit margin over cost including the risk of its staking money being mistakenly slashed. Such business participation costs will translate to service fees chargeable to the blockchain users. A number of PoS blockchains, e.g., Peercoin, Myriad, Blackcoin, VeriCoin, NXT, Algorand, have appeared. They serve pre-echos for new PoS blockchains to come, e.g., Ethereum 2.0, Solana, Cardano, for the blockchain industry to try-and-error learn how the PoS idea shall actually work.

Rethinking Blockchain Security  The limitations we discussed above with some established public blockchains are in fact consequences of centralization in their consensus layer algorithms. With PoW consensus, centralization is in terms of concentrated possession of computing resource. Competition in computing resource consentration not only causes tremendous waste of energy, but also is responsible for the ever-growing-larger-size blockchain ledger to have prevented low-end computers from participating in validating ledger entry correctness. Both problems have entered vicious cycles to deteriorate. Another centralization induced limitation with PoW consensus is that power showdown is demonstrated in terms of syntax correctness, e.g., in hashrate, syntax correctness is shown by how small a hash function output value is. Syntax correctness means that power, instead of rationale, influences farther and wider in the P2P relay network. Such primitive level of correctness is why PoW blockchains is vulnerable to a so-called 51% attack, where an owner of more than half fractions of the network’s computing resource can totally destroy trust in the system. With PoS consensus, centralization is crudely simpler an idea of the richer the more control. However the blockchain industry is in fact not very confident nor comfortable with this simple idea, since any manual slashing method would worsen centralization to arbitration, very likely over to programmers. We remark the PoS idea being crude, also because letting the blockchain enter a state when a (rich) participant is assigned to extend a block, and/or one when a commitee need to work on an “error” correction, mean that the blockchain is frequently vulnerable to single point of failures (SPOFs).

Although the status quo PoW/PoS blockchains’ consensus layer technologies have the above identified centralization limitations, their P2P hop-by-hop relay method for message transmission is strongly decentralized to be able to effectively absorb or deflate powerful shocks from computing-resource-rich and/or monetary-affluent participants in the blockchains. Suppose that an algorithm for validating DB entry correctness involves trivially easy computation steps to be quickly completed by a low-end device such as a smartphone or even an IoT device. Then a very large number of low-end devices can participate in and become an overwhelming portion of a blockchain P2P network task force. They can not only relay correct DB entries afar and widely throughout the network, but also discard incorrect data attempting to enter the DB, even if the latter origin from computing-resource-rich and/or monetary-affluent participants. Therefore, the key to absorb or deflate centralization of power for blockchain technology is to ease the computational complexity for block consensus layer algorithms. Notice that, since with an easy consensus layer algorithm makes a blockchain network to be able to stifle incorrect influence, any attacker attempting to influence the network distributed DB with incorrect entry is announcing a self quitting message and therefore it is in fact not an attacker at all. Such a blockchain has no sense of a so-called “51% attack” since upon a quit-attack announcement by an error influencing attacker, the rest of the network remains to be 100%. Likewise, such a blockchain would obviously resist a so-called “nothing-at-stake attack” because no participant has any stake, or a so-called “Sybil attack” because a non-attacking Sybil is only a positive contributor.

Let us devise a blockchain and a DB entry validating algorithm for the blockchain. The former should be able to attract a large number of low-end computer devices to participate in. The latter should be able to quickly validate the correctness of DB entries, even running on a low-end device.

Decoupling Between DB Writing and Block Extending  EzyDepot’s approach to an easy DB entry correctness validation is to decouple the job of DB writing away from that of blockchain extending. Let permissionless participants race to generate blocks noisily. Let a draw-on-lots race winner document, not only payload data as all blockchains to date conventionally do, but also the public keys of many (of course a non-spam volume of) the race losers. This part of the block data is named the uncle item. The block address, i.e., the chain height, of the race winner’s block specifies a number of DB writing requests in the payload for the uncle nodes to exame and disseminate the correct ones to the network for a ledger entry influence. Thus, the already lineup uncle nodes are specifically and accountably assigned to process the deterministic in-writing payload rather than to do some nondeterministic in-hearing ones. In speaking of “deterministic in-writing”, we mean for all distributed nodes in the network to process whatever the lucky race winner has heard and written in the block payload it generates. In speaking of “nondeterministic in-hearing”, we mean the nature of the input to the cases in the current status-quo blockchain DB writing algorithms, or to all Byzantine Fault Tolerance (BFT) discussion algorithms; such in-hearing input to distributed nodes in various corners of the network is non-deterministic and inconsistent, and can cause these nodes in uncertainly long discussions, more likely for them to disagree on, various messages individually heard by each of the nodes. The nondeterministic in-hearing input computation, discussion or disagreement has unfortunately been responsible for slowness with PoW blockchains, for the reason why BFT has the FLP-Impossibility, and perhaps will also render a money-slashing algorithm in a future PoS blockchain to be executed manually.

Of course a deterministic in-writing payload may contain errors, especially considering that the payload is composed in a race. However, for the in-writing specified, accountable and non-spam volume of the uncle nodes to process the deterministic in-writing payload, their computational influence in the propagation network is easily error-free. In speaking of “easily error-free”, we mean that any error caused by a network imperfection is easily distinguishable from that of a malicious attack, even considering the attacker being the draw winner or some uncle nodes. Any attacking traffic can be easily discarded during the P2P propagation relay and cannot cause an errorsome influence to DB writing.

Why and How Easy for DB Writing Validation  The explicit assignment of the deterministic payload data to a specific set of accountable uncle nodes means that the DB writing requests, i.e., the user transactions in the ledger usecase, in the assigned block payload can be immutably indexed to the block address right at the time of the block extending. Being able to index the DB writing requests enables a clear partition on the resultant ledger set. Partitioned ledger subsets can be created and DB-maintained in a sorted order. The current Bitcoin’s linear-space complexity DB writing correctness tracking algorithm on input a very large and ever growing size UTXO set, now in EzyDepot, is drastically reduced to a logarithmic complexity on input much smaller indexed subsets. With the much eased DB-management for the partitioned smaller ledger sets, the job of DB writing, and the distributed job of correctness validation on a DB writing enry result in propagation, in the EzyDepot blockchain can indeed be quickly executed by a majority of client quality devices.

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