GoUncle: A Blockchain Of, By, For Modest Computers

GoUncle WhitePaper

GoUncle: A Blockchain Of, By, For Modest Computers

Abstract

GoUncle is a blockchain for permissionless participation by modest computers. As in GHOST (Greedy Heaviest Observed SubTree, successfully implemented by and used in the Ethereum blockchain’s Proofs-of-Work version), GoUncle blocks also record public-key identities of some forking blocks’ finders who are dearly called “uncles” (poorly named “orphans” in Bitcoin). While GHOST uses uncles only for saving PoW mining electricity, GoUncle assigns jobs for uncles to do. In a so-called {\em payload screening} job, uncles choose from earlier payloads only data items complying with the blockchain database (DB) policy to announce for the blockchain’s gossip protocol to diffuse. Now that the blockchain can readily append blocks containing incorrect payloads, each block’s height as a globally known address becomes {\em deterministic} right upon appending the block. The deterministic blockchain addresses can index partition the distributed blockchain DB into small files to store in nowadays low-cost over provisioned external storage, for fast input, output, lookup, insert, update, manage, …, etc., exactly the same as a standard DB management system (DBMS) is operated. It is that the blockchain DB becomes a standard DBMS for fast operable even by a modest computer, that secures the DBMS by a {\em hop-by-hop firewall} among vast {\em semantics gossipers} who each, upon receipting a gossip of the uncles’ screening, looks up its local DBMS and judges to either deposit it in and gossip it on, or discard it. This hop-by-hop firewall works exactly as {\em correctness probability amplification} by repeated execution of a {\em randomized probabilistic} (RP) algorithm, and thus the following becomes newly known:

$$\mbox{Blockchains} \subset \mbox{RP}.$$

Also to be manifested is a more general and methodological use of uncles as No-Spam and No-Single-Point-of-Failure (No-SPOF) set of blockchain servers.

Key Words and Phrases:  Easy Permissionless Blockchain.  Blockchain Uncles as No-Spam and No-SPOF Servers.  Blockchain Addressable Computers for Consensus Computations.  Semantics Gossip as Hop-by-Hop Firewall for Blockchain.  Blockchain as a Randomized Probabilistic (RP) Algorithm.  Permissionless Client-Server Architecture.

1. Introduction

In the Bitcoin paper \cite{Bitcoin}, Nakamoto thought a “one-CPU-one-vote” way for the Bitcoin participating nodes to determine representation in majority decision making, and implemented a Proof-of-Work (PoW) hashing, aka mining, game for the participants to count the CPU votes. Since then Bitcoin has been working correctly for twelve plus years. However, because the PoW mining enthuses competition, the voting game has gradually and eventually turned to “one-X-one-vote” where X stands for massively parallelized CPUs and/or GPUs, specially designed hardware rigs, and even pooling of such into huge farms. What now remains being fortunately valid is that these X’s, though no longer forming a majority of all Bitcoin participants, stay in control for Bitcoin to run correctly, thanks to the following two facts: (1) a majority of these X’s are honest, and (2) the majority of all Bitcoin participants are not functional nodes for Bitcoin anymore, at least not in Nakamoto designed “one-CPU-one-vote” way. Thus, the participants in Bitcoin, who are functionally dependable for lining up blocks need to be computationally powerful, and increasingly so. Bitcoin has an increasingly low utilization of its participants.

Bitcoin’s low utilization of its participants can also be clearly seen from its algorithmic method to diffuse messages. A public blockchain uses a hop-by-hop “gossip” way of communication to distribute data in blocks for the blockchain to log immutably in its public writing database (DB). The use of the word “gossip” as a technology descriptor, although sounding a little graphical, precisely describes how a blockchain DB is robustly and reliably secured by the distributed participants in the blockchain network. Each participant hop-by-hop receives and forwards a block, and deposits the block’s payload logs in its local duplicated copy of the DB. The gossip algorithm for Bitcoin can be referred to as “gossip-on-syntax” in that, a block qualifies gossiping if an easy hash validating returns YES for passing a {\em work} threshold. This easy syntax checking gossip function is serviceable by almost all participants. It instructs gossipers to assist only participants who are computationally powerful. Because a syntax gossip formulation cannot perceive the network topology structure of powerful miners, Bitcoin gossipers are unfortunately responsible helpers for a so-called “one-CPU-51\%-of-the-votes” attacker.

A more resounding manifestation for Bitcoin’s low utilization of its participants is by the well-known slowness to lookup Bitcoin’s ledger. A newly found block extending the Bitcoin blockchain needs a long delay, in specific after having been buried under 7 new blocks extending the chain, for the block to gain confirmed trustworthiness. So a user looking up a new transaction logged in this block must wait that long time of about 70 minutes. In need of a long delay for slowly confirming trustworthiness, Bitcoin’s ledger, i.e., the UTXO Set, has never got a trusted operator to perform any DB management (DBMS) work. Such a no-trusted-operator-to-manage ledger DB, after having grown to a large size, has to keep occupying the RAM as a whole data chunk. To input/output the ledger (which data chunk?) between the RAM and external storage space would take too long time. Consequently, most of the Bitcoin participants and/or users are unable to validate the ledger’s correctness as they cannot afford a huge RAM to conduct the validation job. Nakamoto’s “one-CPU-one-vote” ideal turned out to also necessarily mean “one-hugely-expensive-RAM-one-vote”.

Let surrendering blockchain control to a small fraction of the blockchain participants be a have-to-accept way of life with public blockchain. A so-called Proof-of-Stake (PoS) model of block generation has appeared for improving blockchain efficiency and without wasting mining electricity. The PoS model bases blockchain security on a conventionally meaningful business belief that the richer the more responsible. Let a rich minority criterion qualified node deposit a sum of money, called security stake, in a PoS money staking mechanism. The more amount the participant, aka stakeholder, deposits, the more chance for its turn to generate a block. Thus, the gossip formulation for the PoS model can be referred to as “gossip-on-affluence”, meaning a block qualifies gossiping as long as it origins from a rich stakeholder. The security stake is for punitive confiscation or destroy (in PoS programmers’ jargon, “money slashing”) when a block generator is found responsible for either having composed an erroneous block, or upon a timeout having not conducted its turn of blocking duty. A PoS version of “Ethereum2” \cite{Ethereum2} would be the most eminent PoW-to-PoS switch to take place in a near future of writing this paper.

The job of PoS block generation is easily done by signing a digital signature using a cryptographic (private) key. That of PoS block validation needs also producing a digital signature for proving a permissioned stakeholder’s entitlement. Without these PoS proofs, the communication traffic for PoS blocking and/or validating would spam the network. Long term protection for, and frequent use of, a signature private key form single-point-of-failure (SPOF) challenges for each of the stakeholders. These SPOF points, although being distributed to the stakeholders, combine to amplify the frequency for centralized SPOF states that a PoS blockchain is always in. If a private key can be worth very expensively for a stakeholder who very likely is a business organization investor in a PoS blockchain (venture loving organizations are the targeted participants for a PoS blockchain to recruit), the key has no value for an (in-organization) attacker who maybe managed to access the private key only for to cause disruption to the PoS blockchain. These frequency amplified and centralized SPOF breakdown scenarios for PoS blockchains are at best nothing-at-stake ones, a little bit of irony for PoS’ naming.

There are other disruption complications for a PoS blockchain. E.g., money slashing can hardly be done by a consensus algorithm due to a well-known academic conclusion, named “Fischer-Lynch-Paterson (FLP) Impossibility”~\cite{FLP}, being the following statement. There can never exist a network distributed algorithm for its network distributed executors to input messages and output a consensus decision. If money slashing has ever been in practice by any PoS blockchain, it necessarily is by some unspecified manual operation. Still manual slashers would need to figure out an equitable exchange rate between an “error” and a money amount to slash. The quoted “error” here may well be an alleged one for the money slashers to take pains to discern.

\subsection{Public Blockchain Status Quo Summary}

To this end a summary can be stated as follows. Known public blockchain algorithms for lining up blocks have only used small fractions of the blockchain participants as functional and dependable nodes. The remainder larger fractions of the blockchain participants are only brutally syntax instructed or affluence stipulated to play trivial roles as if they were unintelligent. Low utilization of the blockchain participants has unfortunately wasted the collectively very strong capabilities that a majority of the blockchain participants can aggregate.

\subsection{No Brutal Instruction for Modest Blockchain Participants}

A blockchain should have the following property: A majority set of its participants should not be told, mandated, instructed, stipulated, manipulated, controlled, or even implicitly influenced, by the remainder set, i.e., a minority, of the participants to enter into a collective behavior. This blockchain property motivates intelligent uses of a majority of the blockchain participants. It requires careful algorithmic design. In fact, the PoW formulation of gossip-on-syntax, and the PoS stipulation of gossip-on-affluence, are two examples of brutal mandating a majority of the blockchain participants entering into collective behaviors. The PoW unresourceful nodes are algorithm designed to gossip syntax “correct” blocks, whereas the PoS proletarian nodes are rule stipulated to gossip stakeholders composed blocks. Both suffer undesirable consequences as a result of their unintelligent using a majority of the blockchain participants.

The present paper will take a “gossip-on-semantics” approach to using modest participants in public blockchains. Each modest participant upon receipting a gossip message will perform a calculation using its local information state and reach a semantics decision on whether to update the local information state and forward the gossip message on, or to discard the gossip message.

Without much ado for now, it should already be self-evident that such a local state calculation reached decision can provide a modest blockchain participant with strong resistance to influence, manipulation, control, etc. from computationally powerful and/or monetarily affluent participants.

\subsection{Organization of the Work Presentation}

The remainder of this paper is organized as follows. In Section~2, a novel notion of gossip-on-semantics is formulated to achieve truly honest majority control by most of the blockchain participants. In Section~3, a new blockchain is constructed with reasoning why, how and what it can benefit from the gossip-on-semantics way of honest majority control. In Section~4, a system architecture level of generalization for blockchains is provided with concrete descriptions on its construction. Finally, this paper presentation concludes in Section~5 where a couple of questions regarding well-known blockchain attacks are asked for inviting answers and/or exploration discussions from interested readers.

2. Blockchain as a Randomized Probabilistic Algorithm

A well-known knowledge in the computational complexity theory can be described as follows. A randomized probabilistic (RP) algorithm needn’t be sure about its output correctness if the algorithm is executed only once. The algorithm’s output correctness probability can be amplified quickly by repeating the algorithm execution.

 

Treating a blockchain as an RP algorithm, there is no need to be sure about the trustworthiness of the payload data logs recorded in a block upon the block extending the blockchain. There is also no need to wait a long delay for the block to become trustworthy, as all PoW blockchains slowly do. A blockchain without a need of uncertainly long wait for its blocks to become trustworthy is a deterministically extending blockchain. This blockchain determinism from the RP algorithm formulation can achieve a blockchain job decoupling. Each of these statements is described in detail as follows.

 

The job decoupling is between the job of extending the blockchain with newly found blocks, and that of amplifying the output correctness probability for the payload data logs recorded in the already appended blocks. With the job decoupling, let only the data logs in the untrusted payloads, which have survived semantics gossip enter the blockchain DB (The algorithm to realize a semantics gossiper will be provided in the next section). Thus, any untrusted payload data logs get {\em deterministic} blockchain address, aka block height, right upon the recording block extending the blockchain. The job of semantics gossip screening an untrusted payload provides lookup connections between the deterministic blockchain addresses and the logs’ positions in the blockchain DB. With the deterministic connections, the blockchain DB can be blockchain address indexed, and index partitioned into small files to support fast input, output, lookup, insert, update, manage and the like standard DBMS operations. It is the very fact that a blockchain DB becomes a standard DBMS for fast operations even by modest computers that constitutes not only new knowledge advance, but also quality improvement for the public writing DBs of permissionless blockchains.

 

\subsection{No-SPAM and No-SPOF Servers for Blockchains}

 

There are known algorithmic methods for a blockchain to record not only payload logs but also addresses of computers which can even be permissionless participants in the blockchain network. One of such methods will be described in a moment (Section~\ref{Where}. For now, the following useful properties are available from the blockchain addressable computers. They can form a set of No-Spam and No-SPOF servers. The No-Spam property of such servers is easily achievable using a rarity algorithm, e.g., an easy and hence forking PoW hashing. The No-SPOF property of such servers is to duplicate them in sufficient redundancy, and assign exclusive speaking entitlement to them. Let a blockchain record the addresses of such redundant servers in blockchain lineup sets, and for each set to contain redundantly a plural number of the servers. Let them speak orderly in the blockchain deterministic address.

 

\subsection{Where Are the No-Spam and No-SPOF Servers?}

\label{Where}

 

The evolution of digital computers once arrived at a point of enlightenment owing to von Neumann, that data for a computer to store and process can themselves be computers. This enlightenment has of course also happened to blockchain as a networked computer. Bitcoin’s scripting system, and Ethereum’s smart contracts, are in fact computers having von Neumann addresses stored in these blockchains. These blockchain addressed computers are very useful for processing users’ transactions and/or third parties’ contracts. Therefore Bitcoin and Ethereum blockchains can be regarded as von Neumann computers; they are even in the position of servers. However, so far these blockchain addressable servers are only for solving user space problems, ones in the application layer of the blockchain. The blockchain issues which have been analyzed in the Introduction Section are ones causing poor qualities the kernel space, i.e., the consensus layer, of these popular blockchains. These kernel space problems are in ergent need of solutions.

 

GHOST (Greedy Heaviest Observed SubTree)~\cite{GHOST} is a PoW blockchain algorithm to not only line up lucky blocks found by the PoW game won miners, but also let a lucky block record public key identities of some less lucky blocks’ finders. These less lucky blocks’ finders are dearly called {\em uncles} in Ethereum’s (the PoW version) implementation of the GHOST algorithm. GHOST uncles are blockchain addressable computers, though they have never been so used. Both the GHOST research work and its implementation by Ethereum have only used uncles for saving, otherwise wasted, PoW mining electricity.

 

A novel use of GHOST uncles is to let them be a set of No-Spam and No-SPOF servers and execute some useful operations for a blockchain. By controlling the blocking traffic not to reach a spam level as GHOST doing, we can have a random and No-Spam volume set of uncles whose public-key identities have been exposed to the blockchain as addressable servers.

 

In addition to knowledge contribution, this paper also serves the technical basis for a blockchain realization project. The project is to construct an RP formulated blockchain featuring easy participation, in that most of its participants only need be modest computers, such as personal computers, smartphones, home WIFI routers, cloud containers, etc. Each of such modest computers is a fully functional semantics gossiper, an operator for a hop-by-hop semantics firewall, a capable manager for the blockchain distributed DBMS, and can take part in a set of No-Spam and No-Single-Point-of-Failure (No-SPOF) servers for consensus computations.

 

\subsection{Summary}

 

Now for a summary:

\begin{enumerate}

\item It is an RP formulation for a blockchain that achieves the blockchain having the deterministic addresses in any of its block extending state.

  

\item It is a blockchain having deterministic addresses that enables the blockchain job decoupling.

  

\item It is the blockchain job decoupling that can construct a blockchain DB into an easily, fast and low-cost operable DBMS.

  

\item It is the easily, fast and low-cost operable blockchain DBMS being widely distributed to a majority of the blockchain participants, in particular modest ones, that enables each of them being capable of semantics gossiping.

 

\item The vastly distributed semantics gossipers constitutes a strong hop-by-hop firewall to filter out erroneous and/or attacking logs in the untrusted payloads.

\end{enumerate}

3. PoS Issue of Single Point of Failure (SPOF) Complication

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 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 responsible for either having composed an erroneous ledger entry, or upon a timeout having not conducted its assigned ledger entry job. 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 elegance revealed by Bitcoin can be referred to as PoW having no single point of failure (No-SPOF). A PoW blockchain is always in an alive state of many miners being finding a block. Any race condition soon resolves by prevailing of the longest chain. In the worst case of a PoW won miner writing an erroneous entry to the DB, other miners spotting the error will come to the blockchain point immediately before the error containing block and compete mining to fork the chain. One of these (error correction) miners will soon find a block to override the error containing block since these error correction miners’ combined PoW capability dominates the PoW power of the entire network. However, the very PoS idea is for the system to always designate (elect, assign, appoint, or pick) one block generator for this single point to extend the blockchain. Namely, a PoS blockchain always enters a SPOF state. A money slashing PoS blockchain even suffers from worse SPOF complications, to discuss below.

Money slashing for deterring DB entry error is an easier-said-than-done idea. First, thinking a DB error entry to be something necessarily to do with a DB writer, this is already a naive misunderstanding on the unreliability of a blockchain gossip network. Secondly, it is more absurd to imagine a network distributed algorithm to identify the nature of an error in gossip communicated messages. We know of an academic conclusion, named “Fischer-Lynch-Paterson (FLP) Impossibility” [3], being the following statement. There can never exist a network distributed algorithm for its network distributed executors to input gossip messages and output a consensus decision. Money slashing, if having ever been executed in practice by any PoS blockchain, necessarily is by some unspecified manual operation. Still such manual slashers would need to figure out an equitable exchange rate between an “error” and a money amount to slash.

There is yet another SPOF danger for a PoS blockchain in need of exposition. Since the PoS idea believes in business convention that the richer the more responsible, a PoS blockchain should mainly recruit stakeholder participants from venture loving business sector, and assign them richness weighted responsibilities to generate blocks. To generate a PoS block is merely to sign a digital signature using a private key. The SPOF danger we want to expose is due to this easy operation of block generation. While a private key can be worth extremely dearly for a PoS blockchain stakeholder participant who is most likely a business organization having invested the PoS blockchain heavily for a long term return, it may be worth nothing for an attacker who is quite likely an insider in the organization and has somehow managed accessing the private key. Consider that the probably best case scenario for this key compromise is only for this nothing-at-stake insider attacker to cause service disruption for the PoS blockchain. It may be a short term threat to the stakeholder, and is a serious and long term threat to the PoS blockchain. Although key compromise needn’t be an extremely frequent event for one organization (it does happen from time to time), combined SPOF breakdown at many business stakeholders would amplify nothing-at-stake service disruptions for the PoS blockchain.

A for-profit business participant of a PoS blockchain will have to discover a comfortable profit margin over cost particularly including the money-slashing and nothing-at-stake risks we have discussed above. 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 find a long term sustainability for PoS blockchains.

4. An Architectural Rethinking for Blockchain

The analyses of issues with popular blockchains lead to a common property shared by these blockchains. The common property is that, only a smaller fraction of the blockchain participants are dependable for securing the respective blockchains. For PoW blockchains, these dependable participants need to be computationally very powerful and thereby capable of not only finding syntax correct blocks, but also conducting semantics consistency validation for payloads composed in blocks found by some other dependable participants. For PoS blockchains, these “dependable” participants need to be monetarily very affluent and hence form possibly even a smaller, in comparison with PoW, minority of the participants. They are “trusted” stakeholders and will have the ability to run the blockchain in “good” order. (For why some modifiers for PoS blockchains are quoted, see the analyses in Section~3.)

The poor dependability utilization of popular blockchains may be due to a consequence that the blockchain network so far happens to have been remaining in a pure peer-to-peer structure. The pure peer-to-peer structure is based on the ideal view that all participants are equal, however in reality they are not equal at all. For any software-as-a-service (SaaS) system, blockchain certainly being one, the vast majority of the participants must be modest computers such as personal computers, smartphones, and cloud containers. However, the collectively very powerful computing, networking and storaging capability of these modest computers are not used at all in the pure peer-to-peer organization of the blockchain network. It is reasonable to think that any method to make use of the collective resource of the modest computers for blockchain will likely involve a client-server architectural view as an addition to the current status quo pure peer-to-peer view of the blockchain network structure. That is, the blockchain network is in need of computers which are logically not equal. Some are in servers position to help the others being in clients position.

The evolution of digital computers once arrived at a point of enlightenment owing to von Neumann, that data for a computer to store and process can themselves be computers. This enlightenment has of course also happened to blockchain as a networked computer. Bitcoin’s scripting system, and Ethereum’s smart contracts, are in fact computers having von Neumann addresses stored in these blockchains. These blockchain addressed computers are very useful for processing users’ transactions and/or third parties’ contracts. Therefore Bitcoin and Ethereum blockchains can be regarded as von Neumann computers providing servers function. However, so far these blockchain servers are only for solving user space problems, ones in the application layer. The blockchain issues which have been analyzed in the preceding two sections in fact are responsible for poor qualities in popular blockchains’ kernel space, in the consensus layer of these blockchains.

The von Neumann enlightenment for blockchain can go just one small step further. Let blockchain addressed computers solve problems in not only the user space, but also the kernel space, e.g., blockchain consensus layer algorithms. In-RAM operating blockchain DB for PoW blockchains, SPOF complications for PoS blockchains, syntax gossipers incapable of making semantics judgment, are an example of blockchain kernel-space problems in need to solve.

GHOST (Greedy Heaviest Observed SubTree) [4] is a PoW algorithm to not only line up lucky blocks found by the PoW game won miners, but also store in the lucky blocks public key identities of some less lucky blocks’ finders. These less lucky blocks’ finders are called {\em uncles} in Ethereum’s (the PoW version) implementation of the GHOST algorithm. GHOST uncles are blockchain addressable computers, though they have never been so used. Both the GHOST research work and its implementation by Ethereum only use uncles for saving, otherwise wasted, PoW mining electricity.

We propose a novel use of GHOST uncles. Let them be a set of No-Spam and No-SPOF servers and execute some useful operations for a blockchain. By controlling the blocking traffic not to reach a spam level as GHOST doing, we can have a random and No-Spam volume set of uncles whose public-key identities have been exposed to the blockchain as addressable servers.

5. A Blockchain Of, By, For Modest Computers

Our analyses of the PoW consensus mechanism in Section~2 revealed an issue of delaying trust in reaching a PoW consensus. We regard this issue to be responsible for a PoW blockchain’s DB to keep occupying a huge and ever growing sized RAM. An in-RAM DB, after having grown to a large size, becomes unusable by a modest computer. That is why a Bitcoin wallet cannot know whether or not a transaction crediting it is valid and has to wait a long time for the full-nodes’ to validate for it indirectly and implicitly. Obviously, a majority of the PoW blockchain participants, such as wallets, cannot function as semantics gossipers.

The evolution of digital computers once arrived at a point of enlightenment owing to von Neumann, that data for a computer to store and process can themselves be computers. This enlightenment has of course also happened to blockchain as a computer. Bitcoin’s scripting system, and Ethereum’s smart contracts, are in fact computers having von Neumann addresses stored in these blockchains. These blockchain addressed computers are very useful for processing users’ transactions and/or third parties’ contracts. We therefore regard that Bitcoin and Ethereum blockchains use von Neumann computers for solving the user-space problems.

The von Neumann enlightenment for blockchain can go just one small step further. Let blockchain addressed computers solve problems in not only the user space, but also the kernel space, e.g., blockchain consensus layer algorithms. In-RAM operating blockchain DB for PoW blockchains, SPOF complications for PoS blockchains, syntax gossipers incapable of making semantics judgment, are an example of blockchain kernel-space problems in need to solve.

GHOST (Greedy Heaviest Observed SubTree [4]) is a PoW algorithm to not only line up lucky blocks found by the PoW game won miners, but also store in the lucky blocks public key identities of some less lucky blocks’ finders. These less lucky blocks’ finders are called {\em uncles} in Ethereum’s (the PoW version) implementation of the GHOST algorithm. GHOST uncles are blockchain addressable computers, though they have never been so used. Both the GHOST research work and its implementation by Ethereum only use uncles for saving, otherwise wasted, PoW mining electricity.

We propose a novel use of GHOST uncles. Let them be a set of No-Spam and No-SPOF servers and execute some useful operations for the blockchain. By controlling the blocking traffic not to reach a spam level as GHOST doing, we can have a random and No-Spam volume set of uncles whose public-key identities have been exposed to the blockchain as addressable servers.

Let the blockchain’s lucky blocks include at least three parts of data as follows.

\begin{itemize}

\item $\mathtt{Payload}$: A set of logs which the users, and/or third parties, request to write to the DB. The current block address, aka height, is said to be the {\em logging address} for these logs.

\item $\mathtt{Uncles}$: Public-key identities of some less lucky block finders the lucky block records as GHOST-like uncles. The current block address is said to be the {\em residing address} for $\mathtt{Uncles}$.

\item $\mathtt{DB\_Entries}$: Semantics gossip surviving logs announced by uncles with earlier residing addresses.

\end{itemize}

The following “Uncle Algorithm” assigns the exclusive network broadcasting entitlement for a random set of No-Spam and No-SPOF blockchain addressable servers to announce some payload logs.

\begin{theorem-non}

\rm An $\mathtt{uncle}$ announces a $\mathtt{log}$ if the logging address is earlier than its residing address and it judges that $\mathtt{log}$ is consistent with the blockchain’s DB writing policy.

\end{theorem-non}

The following “Semantics Gossiper Algorithm” is executed by every blockchain participant.

\begin{theorem1-non}

\rm

  Let a blockchain participant upon receiving a $\mathtt{log}$ announced by an $\mathtt{uncle}$:

  \begin{enumerate}

  \item Return if $\mathtt{log}$ is of a third party application’s; else

  \item Discard $\mathtt{log}$ if its logging address is later than the residing address of $\mathtt{uncle}$; else

  \item Discard $\mathtt{log}$ if it has been already gossiped; else

  \item Discard $\mathtt{log}$ if it is inconsistent with the DB writing policy; else

  \item Write $\mathtt{log}$ to the local DB and forward $\mathtt{log}$ to the peer neighbors.

  \end{enumerate}

\end{theorem1-non}

In this semantics gossiper algorithm, Step 1 states the responsibility of a third party’s application; Step 2 prevents overzealous uncles from spamming the network; Step 3 guarantees that uncles’ announcements will be quiet quickly; Step 4 specifies a hop-by-hop firewall securing the blockchain network distributed DB against any semantics attack even from a dishonest uncle; and finally Step 5 guarantees quick writing the DB.

Running these two algorithms, the blockchain has the following two properties.

\begin{enumerate}

\item Every DB-entry-policy consistent log will get some uncles’ dissemination for semantics gossipers to diffuse far and widely, and enter the distributed DB, very quickly.

\item Any DB-entry-policy violating log announced by any uncle will be discarded by the semantics gossipers, also very quickly.

\end{enumerate}

Property 1 holds simply because of the endless supply of future uncles. This also means that the uncles’ service is of No-SPOF quality. Thus we have:

\begin{equation}

  \mbox{Probability}( \; \mbox{Log is written to DB} \; | \; \mbox{Log is correct} \; ) = 1.

\end{equation}

Let us reason Property 2, in particular its quickness. Since the two algorithms even tolerate a dishonest uncle, the blockchain payload logs can remain untrusted. Therefore a lucky block gets a {\em deterministic} address right upon it appending and extending the blockchain. The association between the deterministic block address and correct payload logs in the block becomes immediately usable by the global blockchain participants. Since correct logs will be written to the DB, a distributed DB managing algorithm can use this association to manage the DB into index-partitioned and index-searchable small files. So indexed DB files can be stored in external storage spaces (disk or solid state drives) which are nowadays low-cost over-provisioned to modest computers such as laptop computers, smartphones, home WIFI routers, or cloud containers, for fast DB operations such as input, output, lookup, insert, update, manage, etc., all being standard DBMS operations. Such a modest device can quickly lookup the blockchain DB and judge an entry correctness itself without any delay. Thus, we have:

\begin{equation}

\mbox{Probability}( \; \mbox{Log is written to DB} \; | \; \mbox{Log is incorrect} \; ) = 0.

\end{equation}

Thus, repeated announcements from random uncles can indeed quickly “distill” blockchain payload logs into semantically consistent DB entries, exactly as a {\em randomized probabilistic} (RP) algorithm can amplify the correctness probability for its execution by repeating the algorithm. As contribution to knowledge, we establish

\begin{equation}

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

\end{equation}

Here ZPP stands for Zero-sided-error Probabilistic Polynomial-time. The new blockchain has no completeness-side error, as stated by the conditional probability~(1), and it also has no soundness-side error, as stated by the conditional probability~(2). This RP(ZPP-subclass) formulated blockchain is always correct and always fast, even executed by a modest device with low-cost over provisioned external storage space.

The data part $\mathtt{DB\_Entrie}$ in a block suffices the blockchain’s distributed DB to be diffusion-by-semantics (for terminology and its meaning, review Section~1) influenced by the semantics correct logs. Since a semantics gossiper writes a correct log to its local DB before forwarding it on (Step~5 in Semantics Gossiper Algorithm), the semantics correct logs are written to the distributed DB earlier than they show up explicitly on the blockchain. We can regard that the blockchain and the distributed DB operate on “disk”. In other words, this RP(ZPP) formulated blockchain is a Disk Operating Blockchain (DOB).

With modest devices being capable semantics gossipers, this RP(ZPP) formulated blockchain can attract a large number of modest computers to participate in, to achieve that its hop-by-hop firewall is widely and vastly deployed by a majority of the blockchain participants in effective operation to secure the distributed DB. The new blockchain of GoUncle is of, by and for modest computers.

A common blockchain application of the public writing DB is a public ledger. The DB-entry policy for this application is that coins specified in a user transaction request can be looked up from the relevant DB small files as being currently locked to the transaction specified payer(s). The DBMS operations by the uncles and the semantics gossipers involve to lookup the relevant small DB files, and when the lookup returns YES, further involve to update the small DB file so that these coins become being locked to the transaction specified payee(s). To index partition the DB into small files, the blockchain’s DBMS algorithm can use the blockchain addresses (block heights) to parameterize file names, so that all semantics gossipers know the names of the small files to create, write, lookup and update.

6. Uncles Disseminating Consensus Algorithm Executions

Quick and easy distilling payload logs into semantics consistent DB entries is only one way to use a No-Spam and No-SPOF set of blockchain uncles. These uncles can provide other useful services that a blockchain can and should use. Listed below are a number of blockchain computations in need of a NO-Spam set of blockchain servers to execute as No-SPOF services. An uncle can:

\begin{enumerate}

\item Announce a blockchain state progress, e.g., arrival of a network message, and/or occurrence of a time-out event. In these uses of a No-Spam set of uncles, the uncles’ dissemination not only adds a No-SPOF reliability to the system, but also provides a probability sample space for the global participants to compute statistics formulations, e.g., median, mathematical expectation, variance and deviation. We shall describe a simple time-out formulation to be very useful for our version of the GHOST blocking algorithm.

\item (Having the public-key ID being exposed to the system) Provide the TLS public-key certification authority (CA) server functions for securing communications with peer neighbors, as originally proposed by the work of Cothority [5]. For uncles to play the role of TLS CAs is a very useful security service. With many blockchain uncles available as blockchain CAs and with peer communication encryption being mandatory, a new participant has to register a TLS public key with a plural number of earlier uncles. This anonymously registered TLS public key can be listed by the uncles in the blockchain DB as an entry for {\em Public-Key Defined Network} (PKDN) application. This novel PKDN application can let a mobile blockchain node be always route-able wherever the mobile device travels to and whatever its IP address has changed to.

\item Be a block generator upon the blockchain encountering an unknown liveness exception.

\end{enumerate}

Let us see a use of uncles dissemination as a service in the fashion (1) above. The GHOST work [4] correctly reckons that the unavoidable imperfection of a blockchain network in varying message travelling times will inevitably partition the blockchain network to cause chain forks. It assumes a “delay diameter of the network” and crucially uses it however without a sure way to know it. This is where uncles dissemination can help. In specific, in the GHOST blocking time (Algorithm 1 in [4]), uncles can make echo announcements for a newly broadcast block. The plurality and varied distribution of the uncles can not only lower the probability for the network to split, but also explicitly tell an average value for the time delay diameter of the network since the uncles’ echo announcements for a block must take place after the block broadcast.

The “GHOST” algorithm for GoUncle uses a counter in place of the PoW nonce. The counter has the maximum to deterministically stop valid PoW output. Thus, the counter actually serves the clock ticking function to be explicitly ticked by the uncles for the the global participants. Uncles will disseminate their counters reaching the maximum for the global gossipers to discard further blocking broadcasts. Thus, the blocking traffic will reach a global state of quietness for definitive calculation for the lucky block. Moreover, the deviation calculation for tie-break can be used in case when GHOST outputs encounter a tie.

In the GoUncle counter-replacing-nonce version of the GHOST algorithm, while the counter value is below the maximum setting, every participant has the same lucky probability for finding a valid block, whereas upon the counter reaching the maximum setting, no valid block can be found anymore. Both cases have nothing to do with the computational resource the participant has, however modest or powerful it may be. In particular, after the uncles collective disseminating that they have counted to the maximum setting of the counter, the blocking traffic becomes quiet for all. Therefore the GoUncle blockchain discourages participation using powerful computers.

To see a use of uncles dissemination as a service in the fashion (2) above, let the blockchain require a newly joining participant to bind a wallet identity public key to its TLS key with the peer peer neighbors in that, the wallet key being different from the TLS key. Then the blockchain can prevent the participant, being a PKDN anonymous registrant, from launching a Sybil attack, by discarding blocks generated by an unregistered wallet key.

In a near future we shall report the implementation work for the GoUncle blockchain, where useful collective services from blockchain uncles will be described in detail.

7. Conclusion

The No-Spam and No-SPOF set of blockchain uncles provides a new methodology for permissionless, autonomously organized, redundant, replicated execution and output dissemination of blockchain consensus layer algorithms. The work of this paper has manifested the power of this methodology by: (1) A knowledge revelation that blockchains can be formulated in randomized probabilistic algorithms to run efficiently and reliably, and (2) A construction of a semantics gossiper algorithm running on a large number of modest computers to disperse a hop-by-hop firewall and strongly secure the blockchain’s distributed public writing DBMS. The new blockchain has a robust reliability under distributed, redundant and independent control of a vast number of modest computers, is securely managed and maintained by them, and is for a modest computer, such as a client wallet, to lookup data quickly. Therefore the new blockchain of GoUncle is of, by, for modest computers.

Question:  Let a majority of the participants in a blockchain be semantics gossipers. Can this blockchain accumulate a 51\% Attacker?

Thought:  Being the source of a semantically incorrect message seemingly equals being a non-participant since the message will be discarded in early semantics gossip hops. Hence the remainder of the blockchain’s participants remains to be 100\% of the network.

 

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

References

[1] Satoshi Nakamoto. Bitcoin: A peer-to-peer electronic cash system. Tech. rep. Manubot, 2008.

[2] Cynthia Dwork and Moni Naor. “Pricing via processing or combatting junk mail”. In: Annual International Cryptology Conference. Springer. 1992, pp. 139–147.

[3] M. J. Fischer, N. A. Lynch, and M. S. Paterson. “Impossibility of distributed consensus with one faulty process”. In: Journal of the ACM (JACM) 32.2 (1985), pp. 374–382.

[4] Y. SOMPOLINSKY and A. ZOHAR. “Secure high-rate transaction processing in Bitcoin”. In: International Conference on Financial Cryptography and Data Security. 2015, pp. 507–527.

[5] Cothority, https://github.com/dedis/cothority