EyzDepot WhitePaper

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.

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.