On Proof-of-Accuracy Consensus Protocols

Abstract

Consensus protocols are a fundamental part of any blockchain; although several protocols have been in operation for several years, they still have drawbacks. For instance, some may be susceptible to a 51% attack, also known as a majority attack, which may suppose a high risk to the trustworthiness of the blockchains. Although this attack is theoretically possible, executing it in practice is often regarded as arduous because of the premise that, with sufficiently active members, it is not ’straightforward’ to have much computing power. Since it represents a possible vulnerability, the community has made efforts to solve this and other blockchain problems, which has resulted in the birth of alternative consensus protocols, e.g., the proof of accuracy protocol. This paper presents a detailed proposal of a proof-of-accuracy protocol. It aims to democratize the miners’ participation within a blockchain, control the miners’ computing power, and mitigate the majority attacks.

1. Introduction

Blockchain technology is considered one of the most prominent post-internet disruptive computing paradigms [1,2], featuring unique attributes that make it an ideal set of techniques to register, verify, and manage transactions [3]. A blockchain network performs the secure administration of the shared ledger, where transactions are verified and stored in a network without a central authority [4]. Applications that use blockchain, such as cryptocurrencies, decentralized finance applications, video games, and many others, trust that blockchain will prevent problems such as fraud, thanks to the integrated cryptographic mechanisms provided by the data structure and the consensus protocol [5].

Since blockchain is an emerging technology, its applicability to new domains and challenges is constantly growing. The paper [6] presented a taxonomy of blockchain-based applications and an analysis of blockchain challenges regarding security and performance. Its study covered 96 papers categorized into 7 application domains: finance (e.g., [7]), achievement records (e.g., [8]), energy (e.g., [9]), healthcare (e.g., [10]), manufacturing (e.g., [11]), supply chain (e.g., [11]), shipping and delivery (e.g., [12]), and sustainability (e.g., [13]). Regarding security challenges, they highlighted majority attacks [5], DDoS attacks, selfish mining, and others [6]. Concerning performance challenges, they focused on throughput and latency in some blockchains, as well as resource and energy management issues [6].

The 51% attack (also called majority attack) is categorized into hash-based vulnerabilities (“hash-based attack”). It entails one or more miners taking control of at least 51% of the mined hash or computation in the blockchain network [14]. Due to this vulnerability, an attacker can perform attacks that involve canceling transactions, creating forks in the blockchain, selfish mining, and double-spending virtual currency [15].

Consensus protocols are at the core of the inner-working of any blockchain. Proof-of-work (PoW) and proof-of-stake (PoS) protocols are the most popular; however, they still have drawbacks. In particular, the consensus mechanism PoW is inefficient regarding energy consumed by its participants [16]. As a result of the efforts to improve the PoW and PoS protocols, the so-called alternative consensus protocols were born [17].

As evinced in Section 2, there is little research on proof-of-accuracy consensus protocols. In particular, its study and development have been theoretical and are part of the so-called blockchain consensus alternative protocols. According to [18], realizing it requires some components, such as selection of a coordinator, generation of a secret, generation and distribution in the network of parts of the secret, and competition between the participants to find the parts and reconstruct the secret. However, no proposal has presented a concrete protocol so far. Hence, this paper aims to present a detailed proposal for the formalization of what is called a proof-of-accuracy protocol.

The main contribution of this paper is to introduce a proof-of-accuracy protocol. We present our proposed protocol progressively, starting with an initial blueprint (based on different components described in [18] and its drawbacks), which is improved further concerning security. Earlier versions of our protocol feature the following phases: selection of a coordinator, generation of a secret, generation and distribution of parts of the shared secret in the network, and competition between the participants to find the shares to reconstruct the secret (proof of work component). However, our last version (see Section 3.7) removes the need for a coordinator and combines the proof-of-work feature with access to random locations to improve the protocol’s resistance to majority attacks.

The remainder of the article is structured as follows: Section 2 presents an overview of consensus algorithms. Section 3 presents our protocol proposal, introducing it progressively from earlier versions. This section presents the notation we use to describe our protocol and its earlier designs, a general description of a proof-accuracy protocol, our assumptions, and the description of our proposed protocol (and its earlier versions). Section 4 presents an analysis of our proposed protocol. In particular, we present a deep analysis of its mining process, computational costs, and security. Section 5 presents a proof-of-concept implementation of our proposed protocol. Section 6 presents a qualitative comparison between our protocol and other consensus protocols proposed in the literature. In Section 7, we draw our conclusions and describe future research directions.

2. Consensus Protocols

2.1. Original Proof of Work

The nodes must agree when/if a node may add a new block to a blockchain. The PoW consensus algorithm requires the nodes to solve a puzzle, then the first node to solve the puzzle wins the right to add the new block to the chain. This node is named miner, and the effort of solving the puzzle is named mining. Furthermore, the puzzle’s difficulty may be modified each time that a fixed number of blocks is added to the chain [19].

2.2. PoS-Based

The algorithms based on proof of stake (PoS) are based on the idea of betting to determine the node that wins the right to mine the next block in the chain. Employing participation (as proof) is favorable: whatever node that has previous participation is more trustworthy. Therefore, it is expected that a node having a large portion of its gains on the chain will not execute some dishonest move to attack the same chain. Furthermore, the use of PoS indicates that there has to be at least $51\%$ of all betting in the network to execute a double-spend attack, which is very difficult [19].

2.3. Hybrid form of PoW and PoS

“Coin age” is a new concept  [20]; it is calculated for each miner as a product of his/her stake by the time that the miner owns it. The node that has the right to mine a new block in the chain must create a special block named a coin stake; it contains multiple transactions and a special transaction from that miner to itself. The quantity of money expended on the transaction offers the miner additional possibilities to solve the puzzle and add a new block, as in PoW. If a miner spends more money on the transaction, the miner has more of a chance to solve the puzzle. If a node solves a puzzle, it obtains $1\%$ of the coins that they have spent in the transaction, and the accumulated coin age by these coins is reset to zero [19].

Another different proposal [21] does not utilize the coinage because it is supposed that, using the coinage, the attacker can be given the opportunity to collect sufficient value to fool the network. Furthermore, another possible problem occurs when some miners save their stakes until they have a considerable number of coins. During this period they stay outside of the verification system. Thus, the proposal by Vasin [21] consists in utilizing pure participation instead of the coin age to offer the miners the possibility of adding a new block.

2.4. Other Kinds of Proof-Based Consensus Algorithms

The excessive energy demand that needs PoW protocols to find the nonce value is possibly their main drawback. Moreover, such a calculation may not offer any benefit to the user as pinpointed by Blocki and Zhou in [22] and by King in [23]. To solve this problem, Blocki and Zhou [22] suggested using some types of puzzles for education and social activities; these puzzles are challenging for people but easy to solve for computers. This proposal is more for miners because not all have modern hardware [19].

Various authors have presented other evidence-based consensus protocols that do not utilize the ideas of PoW and PoS. Examples of these protocols are proof of burn [24], proof of space [25], proof-of-QoS (PoQ) [26], and a fair selection protocol [27]. These and other consensus protocols are presented in [16].

2.5. Alternative Protocols

Alternative consensus protocols have originated as responses to different efforts to improve the traditional consensus protocols. The works carried out on these alternative protocols are little known. We can evidence this by the number of recent scientific publications. For example, when consulting the number of publications related to alternative consensus protocols and blockchain in Scopus, IEEE Xplore, and Web of Science, we found only two publications, both made in the year 2021.

In [17], they made a general description of alternative consensus protocols proposed between 2019 and 2021. They classified the alternative consensus protocols according to how the winner node was selected as follows: consensus protocol based on effort or work (CPE), consensus protocol based on wealth or resources (CPW), consensus protocol based on past behavior or reputation (CPPB), and consensus protocol based on representation (CPR). Furthermore, the authors of [28] presented a modular version of PoS-based blockchain systems called e-PoS, which resisted the centralization of network resources by expanding mining opportunities to a more extensive set of participants. In addition to the few publications on the subject, the interest in studying these protocols lies in their design features, which can guide future research.

2.6. Proof of Accuracy Protocol

The authors of [18] presented novel ideas for creating new consensus protocols, introducing two possible protocols: protocol simple tickets and proof of accuracy consensus protocol (PoAc); these ideas are theoretical with no concrete implementation.

PoAc features an effort or work (CPE) component since the selection of the node that wins the right to add the new block to the network is not only based on calculating the solution of a problem with a certain threshold of computational complexity but also should include a proof that the winning node has the necessary data pieces for the calculation of the solution of the problem.

These data pieces must be correctly defined and follow a random distribution to ensure that the task of collecting these pieces is stochastic and feasible in a given interval of time, which may be increased by adding some decoy pieces and distributing them with the genuine data pieces on the network [17].

The network participants vie for accessing the data pieces needed to solve the mining problem, which helps participants with little computing skills have the opportunity to win the proof-of-work and add a new block to the chain. Figure 1 shows the flow of the proof of accuracy consensus protocol, which features a random selection of a coordinator, who generates a secret, divides it into shares, and distributes them among participants; the mining process then starts and consists of accessing these shareholders to reconstruct the secret. The mining party reconstructing the secret will acquire the right to add a new block to the blockchain.

Figure 1. Proof of accuracy flowchart.

A recent paper [29] proposed a delegated proof of accessibility (DPoAC) protocol, mostly based on the previous idea. It employed secret sharing, PoS with random selection, and an interplanetary file system (IPFS). This protocol is similar to our initial design presented in Section 3.5 and follows a similar flow as shown in Figure 1. The main difference is that the coordinator stores the n shares of the secret in different n nodes on the IPFS network. For a mining party to acquire block creation rights, the party has to access these shareholders to reconstruct the secret.

As analyzed in Section 3.5.1, this approach has a drawback in that it heavily relies on the coordinator, meaning this node gains too much knowledge of the secret and may take advantage of it to favor any mining party.

3. Proposed Protocol

In this section, we introduce our proposed protocol. In Section 3.1, we introduce the notation that we will use throughout the section. In Section 3.5 and Section 3.6, we describe earlier versions of our proposed protocol, highlighting their weaknesses and disadvantages. These earlier versions serve as a base to introduce our proposed protocol. Finally, we present our proposed protocol in Section 3.7.

3.1. Notation

We introduce the notation that we will use throughout the section. Specifically, Table 1 summarizes our notation.

Table 1. Summary of notation.

Symbol	Description
$t\in \mathbb{N}$	A positive integer.
$n\in \mathbb{N}$	A positive integer.
$m\in \mathbb{N}$	A positive integer.
$m_0\in \mathbb{N}$	A positive integer.
$m_1\in \mathbb{N}$	A positive integer.
$\mathbb{G}\in \mathbb{N}$	Denotes a cyclic group of order q
$q\in \mathbb{N}$	A prime number
$p=2q+1$	A safe prime number
$g\in \mathbb{G}$	A public generator of $\mathbb{G}$
${\mathbb{Z}}_p$	The ring of integers modulo p
${\mathbb{ID}}_m=\{1,2,\dots ,m\}$	The set of m identifiers
$i\in {\mathbb{ID}}_m$	An identifier in ${\mathbb{ID}}_m$
$s_i\left(j\right):{\mathbb{ID}}_m\setminus \left\{i\right\}\stackrel{}{\to }\{1,-1\}\subseteq {\mathbb{Z}}_q$  [30]	$$s_i\left(j\right)=\left\{\begin{array}{c}1ifi>j\\ -1ifi<j\end{array}\right.$$ (1)
${\mathcal{H}}_0:{\{0,1\}}^{*}\to {\{0,1\}}^{m_0}$	Denotes a cryptographic hash function
${\mathcal{H}}_1:{\{0,1\}}^{*}\to {\{0,1\}}^{m_1}$	Denotes a cryptographic hash function
$0\le p_{min}\le 1\in \mathbb{R}$	Denotes a probability (protocol parameter)

3.2. General Description

The progressive versions of our protocol are built upon the cryptographic components required to compose a proof-of-accuracy (PoAc) protocol described by [18]. In particular, according to [18], a proof-of-accuracy (PoAc) protocol features the selection of a coordinator among all the participants, the joint generation of a secret by all the participants, the generation of shares of the generated secret, decoy shares, the distribution of all of them over the network participants, the mining process among the mining parties to reconstruct the generated secret, and the proof of recovering the secret by the winning party. We next describe the cryptographic tools we used.

3.2.1. Single Broadcast-Based Joint Random Number Generation Protocol

Our proposed protocol uses a joint random number generation protocol as described in [30,31]. According to their designers, these protocols do not require a secure network and need one transmission per network node. The protocol [30] features additive aggregation instead of a multiplicative aggregation as in the protocol presented in [31].

The arithmetic carried out by m participants in the protocol  [30] works over a cyclic group $\mathbb{G}\subseteq {\mathbb{Z}}_p$ generated by g with order q, where q and $p=2q+1$ are prime numbers. Each participant generates a Diffie–Hellman-like key pair $({\kappa }_i,p{k}_i=g^{{\kappa }_i})$ and shares its public key with the other network participants. With the set of public keys, the participant i computes $R_i={\sum }_{j=1,j\ne i}^m{s}_i\left(j\right)p{k}_j^{{\kappa }_i}\in {\mathbb{Z}}_p$, generates $c_i\in {\mathbb{Z}}_p$, and calculates ${\gamma }_i=c_i+R_i$. At the last step, a randomly chosen coordinator takes the role of the combiner and collects all the ${\gamma }_i$ values, and computes $\alpha ={\sum }_{i=1}^m{\gamma }_i={\sum }_{i=1}^m{c}_i+{\sum }_{i=1}^m{R}_i={\sum }_{i=1}^m{c}_i,$ since ${\sum }_{i=1}^m{R}_i=0$, which will be the input secret passed to the next sub-protocol.

3.2.2. Shamir’s Secret Sharing Scheme

Shamir’s secret sharing scheme aims to divide a secret $\alpha$ in s parts (${\alpha }_1$,${\alpha }_2$ …${\alpha }_s$) so that with any t of the s parts, $\alpha$ can be reconstructed, but every set of $t-1$ reveals nothing about $\alpha$ [32]. Shamir’s secret sharing scheme stems from a general fact of polynomial interpolation; A polynomial of maximum degree $t-1$ defined over a field is fully determined by t points of the polynomial. In our particular case, we work it over ${\mathbb{Z}}_q$, which is a field when q is a prime number [32].

We call the s parts the genuine parts, the valid ones to reconstruct the secret; Also, $n-s$ non-genuine parts are generated and distributed among the participants. Combining genuine and non-genuine parts allows for adjusting the difficulty in collecting t genuine parts to recover the secret. Algorithms 1 and 2 describe the inner workings of Shamir’s secret sharing scheme.

Algorithm 1 generates the t-out-of-s sharing of $\alpha$

1: function ${\mathtt{G}}_{sh}$($s,t,\alpha$)

2:     choose $a_1,\dots ,a_{t-1}\leftarrow {\mathbb{Z}}_q$ at random and define a polynomial $$f\left(x\right):=a_{t-1}{x}^{t-1}+a_{t-2}{x}^{t-2}+\dots +a_{1}x+\alpha \in {\mathbb{Z}}_q.$$

3:     for $i\leftarrow 1$ to s do

4:         select $x_i$ randomly from ${\mathbb{Z}}_q$, such that $x_i\ne x_j$ for all $j\in \{1,\dots ,i-1\}$

5:         $y_i\leftarrow f\left(x_i\right)$

6:         ${\alpha }_i\leftarrow (x_i,y_i)$

7:     end for

8:     return $({\alpha }_1,{\alpha }_2,\dots ,{\alpha }_s)$

9: end function

Algorithm 2 recovers $\alpha$ given t genuine shares

1: function ${\mathtt{C}}_{sh}$(${\alpha }_1=(x_1,y_1),\dots ,{\alpha }_t=(x_t,y_t)$)

2:     $\alpha \leftarrow 0\in {\mathbb{Z}}_q$

3:     for $i\leftarrow 1$ to t do

4:         ${\lambda }_i\leftarrow 1\in {\mathbb{Z}}_q$

5:         for $j\leftarrow 1$ to t do

6:            if $i\ne j$ then

7:                ${\lambda }_i\leftarrow {\lambda }_i·\frac{-x_j}{x_i-x_j}$

8:            end if

9:         end for

10:         $\alpha \leftarrow \alpha +y_i·{\lambda }_i$

11:     end for

12:     return $\alpha$

13: end function

3.2.3. Schnorr Non-Interactive Zero-Knowledge Scheme

Schnorr non-interactive zero-knowledge (NIZK) scheme is a non-interactive variant of the three-pass Schnorr identification scheme. The Schnorr NIZK scheme allows a prover to prove to any verifier their knowledge of a discrete logarithm without leaking any information about its value [32]. Algorithm 3 shows how a proof gets generated, while Algorithm 4 shows how a proof gets verified.

Algorithm 3 generates a proof

1: function $\mathtt{genProof}$($\alpha ,u,id$)

2:     ${\alpha }_t\stackrel{R}{\leftarrow }{\mathbb{Z}}_q$

3:     $u_t\leftarrow g^{{\alpha }_t}$

4:     $c\leftarrow {\mathcal{H}}_0(g,u_t,u,id)$.

5:     ${\alpha }_z\leftarrow {\alpha }_t+c·\alpha$

6:     return $(id,u_t,{\alpha }_z)$

7: end function

Algorithm 4 verifies a proof

1: function $\mathtt{verifyProof}$($id,u_t,{\alpha }_z,u)$)

2:     $c^{\prime }\leftarrow {\mathcal{H}}_0(g,u_t,u,id)$.

3:     $u_z\leftarrow g^{{\alpha }_z}.$

4:     if $u_z=u_t{u}^{c^{\prime }}$ then

5:         return 1

6:     else

7:         return 0

8:     end if

9: end function

3.2.4. Digital Signatures

A digital signature scheme $\mathtt{SS}$ consists of the following algorithms [32].

• $\mathtt{G}$ is a probabilistic algorithm that takes a security parameter. It outputs a pair $(\mathtt{vk},\mathtt{sk})$, where $\mathtt{sk}$ is a secret signing key, and $\mathtt{vk}$ is a public verification key.
• $\mathtt{sign}$ is a probabilistic algorithm that is invoked as $\sigma \leftarrow \mathtt{sign}(\mathtt{sk},m)$, where $\mathtt{sk}$ is a secret key (as output by the key generation algorithm) and m is a message. The algorithm outputs a signature $\sigma$.
• $\mathtt{verify}$ is a deterministic algorithm invoked as $\mathtt{b}\leftarrow \mathtt{verify}(\mathtt{vk},m,\sigma ),$ where b is a bit. If $\mathtt{b}=1$, then it means the signature is accepted, or else it is rejected.

3.3. Threat Model

We assume a semi-honest adversary, i.e., one who corrupts parties but follows the protocol as specified. Under this threat model, the corrupt parties follow the rules of the protocol honestly but they may attempt to learn as much as possible from the messages they receive from other parties to control the creation of blocks in the chain. Furthermore, there may be several colluding corrupt parties combining their partial views to learn information. Semi-honest adversaries are regarded as passive since they do not take any active actions other than attempting to learn private information by observing a view of the protocol execution. Semi-honest adversaries are also commonly called honest-but-curious.

We regard the view of a party as its private inputs, its memory data, and the list of all messages received during the protocol. In this sense, the view of an adversary is composed of the combined views of all corrupt parties. Therefore, under this threat model, any information the adversary learns from the run of the protocol must be a computable function on the input of its combined view [33].

3.4. Initial Assumptions

We assume that each participant has access to a long-term key pair $(\mathtt{sk},\mathtt{vk})$ generated by a signature scheme $\mathtt{SS}$. Furthermore, each participant has access to a digital certificate that proves the validity of the corresponding public verification key $\mathtt{vk}$. Additionally, when two participants want to communicate, a secure channel is established between them via a protocol such as transport layer security (TLS) [32].

3.5. Initial Design

Here, we present our first attempt to build a proof of accuracy protocol. In particular, this initial design is a proof-of-concept based on the cryptographic components required to compose a proof-of-accuracy (PoAc) protocol described by [18]. Specifically, [18] presents the main cryptographic constituents to build such a protocol, but they do not present a concrete cryptographic construction of the protocol.

Let us assume that there are $m+1$ participants. One of them assumes the role of coordinator with identifier 0. Additionally, each m remaining participant is given a unique identifier $i\in {\mathbb{ID}}_m$. The arithmetic works over a cyclic group $\mathbb{G}\subseteq {\mathbb{Z}}_p$ generated by g and whose order is a prime number q with $p=2q+1$ (p a prime number). The initial design runs as follows.

• Participant i generates an ephemeral key pair by selecting the private key ${\kappa }_i\in {\mathbb{Z}}_q$ at random and computing the public key $p{k}_i\leftarrow g^{{\kappa }_i}\in \mathbb{G}$
• Participant i sends the ephemeral public key $p{k}_i$ to the other $m-1$ participants.
• Once participant i receives other participants’ ephemeral public keys, the participant computes $R_i$ as $R_i={\sum }_{j=1,j\ne i}^m{s}_i\left(j\right)p{k}_j^{{\kappa }_i},$ where s is the function defined in Equation (2).
• Each participant i selects $c_i\in {\mathbb{Z}}_q$ at random and computes ${\gamma }_i=c_i+R_i$. The participant then sends its ${\gamma }_i$ to the coordinator.
• Once the coordinator receives ${\gamma }_i$’s from all participants, the coordinator will compute the secret $\alpha$ as

  $$\alpha =\sum _{i=1}^m{\gamma }_i=\sum _{i=1}^m{c}_i+\sum _{i=1}^m{R}_i=\sum _{i=1}^m{c}_i,$$

  since ${\sum }_{i=1}^m{R}_i=0$.
• The coordinator generates s shares of $\alpha$, $({\alpha }_1,\dots ,{\alpha }_s)\leftarrow {\mathtt{G}}_{sh}(s,t,\alpha ),$ and $n-s$ random points ${\alpha }_{s+1},{\alpha }_{s+2},\dots {\alpha }_n$ from ${\mathbb{Z}}_q\times {\mathbb{Z}}_q.$ The coordinator then computes $u=g^{\alpha }$ and shuffles the genuine and non-genuine points, forming the list $A=[{\alpha }_{i_1},{\alpha }_{i_2},\dots ,{\alpha }_{i_n}]$, with $1\le i_1,i_2,\dots ,i_n\le n$. The coordinator now computes ${\sigma }_0=\mathtt{sign}({\mathtt{sk}}_0,{\mathcal{H}}_1(A\Vert u\Vert {\mathtt{B}}_l\left)\right)$ where ${\mathtt{B}}_l$ is the last block in the blockchain. The coordinator now makes $A,u,{\sigma }_0$ publicly accessible to all participants.
• At this point, the mining process begins. A mining party will attempt to reconstruct the secret $\alpha$ by finding t genuine points from A. In particular, the participant first collects $A,u,{\sigma }_0$ from the coordinator, and may check whether ${\sigma }_0$ is a valid signature for ${\mathcal{H}}_1(A\Vert u\Vert {\mathtt{B}}_l)$. The participant then selects t points ${\alpha }_1,\dots ,{\alpha }_t$, computes ${\alpha }^{\prime }\leftarrow {\mathtt{C}}_{sh}({\alpha }_1,\dots ,{\alpha }_t)$, and checks whether u is equal to $g^{{\alpha }^{\prime }}$. Once the participant finds t suitable points, the participant will proceed with step 8. Otherwise, the participant will attempt to find t genuine points.
• A mining party with identifier $id$ proves its knowledge of the correct ${\alpha }^{\prime }$ to other participants by using the Schnorr non-interactive zero-knowledge scheme. Specifically,

  (a)

  The participant computes $\mathtt{proof}=(id,u_t,{\alpha }_z)\leftarrow \mathtt{genProof}({\alpha }^{\prime },u,id)$. He then publishes $(m_{id},{\sigma }_{id})$ to the network, where

  $$m_{id}\leftarrow (\mathtt{proof},A,u,{\sigma }_0)$$

  and ${\sigma }_{id}\leftarrow \mathtt{sign}({\mathtt{sk}}_{id},{\mathcal{H}}_1\left(m_{id}\right))$.

  (b)

  Any verifier can check a solution $(m_{id},{\sigma }_{id})$ by calling the function check shown by Algorithm 5.  

Algorithm 5 checks a solution

1: function check($m_{id},{\sigma }_{id},{\mathtt{vk}}_{id},{\mathtt{vk}}_0,{\mathtt{B}}_l$)

2:     $b_0\leftarrow \mathtt{verify}({\mathtt{vk}}_{id},{\mathcal{H}}_1\left(m_{id}\right),{\sigma }_{id})$

3:     if $b_0=1$ then

4:         $(\mathtt{proof},A,u,{\sigma }_0)\leftarrow m_{id}$

5:         $b_1\leftarrow \mathtt{verify}({\mathtt{vk}}_0,{\mathcal{H}}_1(A\Vert u\Vert {\mathtt{B}}_l),{\sigma }_0)$

6:         $(id,u_t,{\alpha }_z)\leftarrow \mathtt{proof}$

7:         $b_2\leftarrow \mathtt{verifyProof}(id,u_t,{\alpha }_z,u)$

8:         if $b_1=1$ and $b_2=1$ then

9:            return Accept

10:         else

11:            return Reject

12:         end if

13:     else

14:         return Reject

15:     end if

16: end function

3.5.1. Analysis of the Initial Design

Here, we analyze the initial design.

Correctness

We analyze step 7 of the initial design. Note that what the coordinator does is to call ${\mathtt{G}}_{sh}(s,t,\alpha )$, creating s genuine shares for $\alpha$, any t of which serves to reconstruct $\alpha$. Hence, any mining party that finds t genuine shares among the n entries in A will successfully reconstruct the secret.

Drawbacks

The major drawback of the initial design is that it heavily relies on the coordinator since this coordinator aggregates all ${\gamma }_i$ to obtain the secret $\alpha$ and then computes the s shares of $\alpha$ and $n-s$ random points, which means the coordinator gains too much knowledge of $\alpha$ and, hence, may take advantage of this knowledge to favor any mining party.

Ideally, this coordinator must not know $\alpha$, neither the s genuine shares of $\alpha$ nor the $n-s$ random points, i.e., the coordinator only should serve as an aggregator of data. The following design improves upon the initial one by exploiting further the aggregating protocols [30,31] to compute the genuine and non-genuine shares securely.

3.6. An Improved Design

Let us assume that there are t participants. One of them assumes the role of the coordinator with identifier 0. Each participant other than the coordinator has a unique identifier $i\in {\mathbb{ID}}_{t-1}$. The arithmetic works over a cyclic group $\mathbb{G}\subseteq {\mathbb{Z}}_p$ generated by g, whose order is a prime number q with $p=2q+1$ (p a prime number). The improved design runs as follows:

• Participant i generates $n+1$ ephemeral key pairs

  $$({\kappa }_{i,0},g^{{\kappa }_{i,0}}),({\kappa }_{i,1},g^{{\kappa }_{i,1}}),\dots ,({\kappa }_{i,n},g^{{\kappa }_{i,n}})$$

  by randomly selecting ${\kappa }_{i,k}\in {\mathbb{Z}}_q$ and computing $g^{{\kappa }_{i,k}}$ for each $k\in \{0,1,\dots ,n\}$.
• Participant i sends its ephemeral public keys

  $$(g^{{\kappa }_{i,0}},g^{{\kappa }_{i,1}},g^{{\kappa }_{i,2}},\dots ,g^{{\kappa }_{i,n}})$$

  to all other participants.
• After receiving the ephemeral public keys from each other participant, the participant i computes the following vector

  $$R_i=(R_{i,0},R_{i,1},\dots ,R_{i,n}),$$

  where

  $$R_{i,0}=\prod _{j=1,j\ne i}^{t-1}{\left(g^{{\kappa }_{j,0}}\right)}^{s_i\left(j\right){\kappa }_{i,0}}$$

  and

  $$R_{i,k}=\sum _{j=1,j\ne i}^{t-1}{s}_i\left(j\right){\left(g^{{\kappa }_{j,k}}\right)}^{{\kappa }_{i,k}}$$

  for each $k\in \{1,2,\dots ,n\}$.
• Participant i selects ${\gamma }_i,c_i\stackrel{R}{\leftarrow }{\mathbb{Z}}_q$ and a probability $p_i\stackrel{R}{\leftarrow }[p_{min},1]$. This participant computes the vector $C_i=(g^{{\gamma }_i}{R}_{i,0},e_{i,1}+R_{i,1},\dots ,e_{i,n}+R_{i,n})$, where

  $$e_{i,k}=\left\{\begin{array}{c}{c}_i{k}^i+{\gamma }_i\mathrm{mod}q\mathrm{with}\mathrm{probability}{p}_i\\ z\stackrel{R}{\leftarrow }{\mathbb{Z}}_q\mathrm{with}\mathrm{probability}1-{\mathrm{p}}_{\mathrm{i}}\end{array}\right.$$

  and sends $C_i$ to the coordinator
• Once the coordinator receives each $C_i$ for $i=1,\dots ,t-1$, the coordinator will compute

  $$A=\left(\prod _{i=1}^{t-1}{C}_{i,0},\sum _{i=1}^{t-1}{C}_{i,1},\dots ,\sum _{i=1}^{t-1}{C}_{i,n}\right)$$

  (2)
  The coordinator now computes ${\sigma }_0=\mathtt{sign}({\mathtt{sk}}_0,{\mathcal{H}}_1(A\Vert {\mathtt{B}}_l))$, where ${\mathtt{B}}_l$ is the last block in the blockchain. The coordinator now makes $A,{\sigma }_0$ publicly accessible to all participants.
• At this point, the mining process begins. A mining party first collects A and ${\sigma }_0$ from the coordinator, and may check whether ${\sigma }_0$ is a valid signature for ${\mathcal{H}}_1(A\Vert {\mathtt{B}}_l)$. It then will attempt to find t unique indices $1\le k_1,k_2,\dots ,k_t\le n$, such that $A_0=g^{{\alpha }^{\prime }}$, where

  $${\alpha }^{\prime }\leftarrow {\mathtt{C}}_{sh}((k_1,A_{k_1}),(k_2,A_{k_2}),(k_3,A_{k_3}),\dots ,(k_t,A_{k_t})).$$
  Once the participants find t suitable points, they will proceed with step 7. Otherwise, they will attempt to find t genuine points.
• A mining party with identifier $id$ proves its knowledge of the correct ${\alpha }^{\prime }$ to other participants by using the Schnorr non-interactive zero-knowledge scheme. Specifically,

  (a)

  The participant computes $\mathtt{proof}=(id,u_t,{\alpha }_z)\leftarrow \mathtt{genProof}({\alpha }^{\prime },A_0,id)$. He then publishes $(m_{id},{\sigma }_{id})$ to the network, where $m_{id}\leftarrow (\mathtt{proof},A,{\sigma }_0)$ and ${\sigma }_{id}\leftarrow \mathtt{sign}({\mathtt{sk}}_{id},{\mathcal{H}}_1\left(m_{id}\right))$.

  (b)

  Any verifier can check a solution $(m_{id},{\sigma }_{id})$ by calling the function check shown by Algorithm 6.

Algorithm 6 checks a solution

1: function check($m_{id},{\sigma }_{id},{\mathtt{vk}}_{id},{\mathtt{vk}}_0,{\mathtt{B}}_l$)

2:     $b_0\leftarrow \mathtt{verify}({\mathtt{vk}}_{id},{\mathcal{H}}_1\left(m_{id}\right),{\sigma }_{id})$

3:     if $b_0=1$ then

4:         $(\mathtt{proof},A,{\sigma }_0)\leftarrow m_{id}$

5:         $b_1\leftarrow \mathtt{verify}({\mathtt{vk}}_0,{\mathcal{H}}_1(A\Vert {\mathtt{B}}_l),{\sigma }_0)$

6:         $(id,u_t,{\alpha }_z)\leftarrow \mathtt{proof}$

7:         $b_2\leftarrow \mathtt{verifyProof}(id,u_t,{\alpha }_z,A_0)$

8:         if $b_1=1$ and $b_2=1$ then

9:            return Accept

10:         else

11:            return Reject

12:         end if

13:     else

14:         return Reject

15:     end if

16: end function

3.6.1. Analysis of the Improved Design

Here, we analyze the improved design.

Correctness

We analyze steps 5 and 6 of the improved design. Let us assume that each $C_i$ obtained from participant i was created with a fixed probability $p_i$. Note that since ${\prod }_{i=1}^{t-1}{R}_{i,0}=1,$

$$A_0=\prod _{i=1}^{t-1}{\mathtt{C}}_{i,0}=\prod _{i=1}^{t-1}{g}^{{\gamma }_i}{R}_{i,0}=\prod _{i=1}^{t-1}{g}^{{\gamma }_i}\prod _{i=1}^{t-1}{R}_{i,0}=\prod _{i=1}^{t-1}{g}^{{\gamma }_i}=g^{{\sum }_{i=1}^{t-1}{\gamma }_i}=g^{\alpha }=u$$

where $\alpha ={\sum }_{i=1}^{t-1}{\gamma }_i\mathrm{mod}q$.

Let us fix a k with $1\le k\le n$. Let us assume that $C_{i,k}=c_i{k}^i+{\gamma }_i+R_{i,k}\mathrm{mod}q$ for all $1\le i\le t-1$. By construction, this occurs with probability $\rho =p_1{p}_2\dots p_{t-1}$. Since ${\sum }_{i=1}^{t-1}{R}_{i,k}=0,$ then

$$A_k=\sum _{i=1}^{t-1}{C}_{i,k}=\sum _{i=1}^{t-1}{c}_i{k}^i+\sum _{i=1}^{t-1}{\gamma }_i+\sum _{i=1}^{t-1}{R}_{i,k}=P\left(k\right)$$

where $P\left(x\right)=c_{t-1}{x}^{t-1}+c_{t-2}{x}^{t-2}+\dots +c_{1}x+\alpha$.

If the mining party finds t suitable $k_1,k_2,\dots ,k_t$, then

$$A_{k_1}=P\left(k_1\right),A_{k_2}=P\left(k_2\right)\dots ,A_{k_t}=P\left(k_t\right).$$

Therefore, $A_0=g^{{\alpha }^{\prime }}$, where

$${\alpha }^{\prime }={\mathtt{C}}_{sh}((k_1,A_{k_1}),(k_2,A_{k_2}),\dots ,(k_t,A_{k_t})).$$

Drawbacks

The improved design still relies on a coordinator, but now this coordinator does not know $\alpha$, neither the s genuine shares of $\alpha$ nor the $n-s$ random points, i.e., the coordinator only serves as an aggregator of data; if the coordinator wants to know the secret $\alpha$, it will have to perform step 6 of the improved design as any other mining party would. However, having a coordinator still presents a unique point of failure for this approach; Also, it solely relies on the proof of work (which may not have a solution) performed by a mining party at step 6. To reduce power concentration (hence, the $51\%$ attack [5]) and increase the fairness of the mining process, a new version should complement the proof of work with other approaches, for example, access to random locations (similar to PoC) [17].

Another drawback is that any mining party will attempt to recover $\alpha$ from A at step 6. Ideally, any mining party should only know how to reconstruct $g^{\alpha }$ rather than $\alpha$. Another issue may arise if the cyclic group $\mathbb{G}$ is set to another one (e.g., a subgroup of the points of an elliptic curve). If that is the case, a mapping to associate each element of $\mathbb{G}$ with an element of ${\mathbb{Z}}_q$ will be required. In this version, this is not a problem since we are assuming the arithmetic works over a cyclic group $\mathbb{G}\subseteq {\mathbb{Z}}_p$ generated by g with order q, where $p=2q+1$ and p, q are prime numbers. Hence, the computation of

$$R_{i,k}=\sum _{j=1,j\ne i}^{t-1}{s}_i\left(j\right){\left(g^{{\kappa }_{j,k}}\right)}^{{\kappa }_{i,k}}$$

for each $k\in \{1,2,\dots ,n\}$ does not present any inconvenient.

Our final version deals with the drawbacks of the improved design by introducing the following features:

• Permit a mining party to access $C_i$ at different locations and compute a new vector A independently with the collected $C_i$’s.
• Use only the multiplicative version of the aggregating protocol [31] to compute the ciphertexts of the shares.
• Exploit the homomorphic properties of ElGamal-based cryptographic schemes to allow any mining party to reconstruct $g^{\alpha }$ from the ciphertexts of the shares.

3.7. Our Proposed Protocol

Let us assume that there are $t-1$ participants. Each participant has a unique identifier $i\in {\mathbb{ID}}_{t-1}$. The arithmetic works over a cyclic group $\mathbb{G}$ generated by g and whose order is a prime number q. Our proposed protocol runs as follows.

• Participant i generates $n+1$ ephemeral key pairs

  $$({\kappa }_{i,0},g^{{\kappa }_{i,0}}),({\kappa }_{i,1},g^{{\kappa }_{i,1}}),\dots ,({\kappa }_{i,n},g^{{\kappa }_{i,n}})$$

  by selecting ${\kappa }_{i,k}\in {\mathbb{Z}}_q$ at random and computing $g^{{\kappa }_{i,k}}$ for each $k\in \{0,1,\dots ,n\}$.
• Participant i sends its ephemeral public keys

  $$(g^{{\kappa }_{i,0}},g^{{\kappa }_{i,1}},g^{{\kappa }_{i,2}},\dots ,g^{{\kappa }_{i,n}})$$

  to all other participants.
• After receiving the ephemeral public keys from the other $t-2$ participants, participant i computes the following vector

  $$R_i=(R_{i,0},R_{i,1},\dots ,R_{i,n}),$$

  where

  $$R_{i,k}=\prod _{j=1,j\ne i}^{t-1}{\left(g^{{\kappa }_{j,k}}\right)}^{s_i\left(j\right){\kappa }_{i,k}}$$

  for each $k\in \{0,1,\dots ,n\}$
• At this point, the mining process begins. A mining party will have to contact each participant i and request a ${\mathtt{C}}_i$ from it. Specifically, upon request, the participant i executes $({\mathtt{C}}_i,{\sigma }_i)\leftarrow \mathtt{generateC}({\mathtt{sk}}_i,R_i,{\mathtt{B}}_l)$, shown by Algorithm 7, where ${\mathtt{B}}_l$ is the last block in the blockchain.

  Algorithm 7 generates the pair $({\mathtt{C}}_i,{\sigma }_i)$

  1: function $\mathtt{generateC}$(${\mathtt{sk}}_i,R_i,{\mathtt{B}}_l$)

  2:     $p_i\stackrel{R}{\leftarrow }[p_{min},1]$.

  3:     $c_i\stackrel{R}{\leftarrow }{\mathbb{Z}}_q$

  4:     ${\gamma }_i\stackrel{R}{\leftarrow }{\mathbb{Z}}_q$

  5:     ${\mathtt{C}}_{i,0}\leftarrow g^{{\gamma }_i}{R}_{i,0}$

  6:     for $k\leftarrow 1$ to n do

  7:         $p\stackrel{R}{\leftarrow }[0,1]$

  8:         if $p\le p_i$ then

  9:            $e_{i,k}\leftarrow c_i{k}^i+{\gamma }_i\mathrm{mod}q$

  10:         else

  11:            $e_{i,k}\stackrel{R}{\leftarrow }{\mathbb{Z}}_q$

  12:         end if

  13:          ${\mathtt{C}}_{i,k}\leftarrow g^{e_{i,k}}{R}_{i,k}$

  14:     end for

  15:     ${\sigma }_i\leftarrow \mathtt{sign}({\mathtt{sk}}_i,{\mathcal{H}}_1({\mathtt{C}}_i\Vert {\mathtt{B}}_l))$.

  16:     return $({\mathtt{C}}_i,{\sigma }_i)$

  17: end function

  The participant i then sends $({\mathtt{C}}_i,{\sigma }_i)$ to the requesting mining party. Note that the mining party may check whether ${\sigma }_i$ is a valid signature for ${\mathcal{H}}_1({\mathtt{C}}_i\Vert {\mathtt{B}}_l)$. Once the mining party contacts each participant i and collects the corresponding ${\mathtt{C}}_i$, the party then computes A as

  $$A=\left(\prod _{i=1}^{t-1}{\mathtt{C}}_{i,0},\prod _{i=1}^{t-1}{\mathtt{C}}_{i,1},\dots ,\prod _{i=1}^{t-1}{\mathtt{C}}_{i,n}\right).$$
  The mining party’s goal is to find unique indices $1\le k_1,k_2,\dots ,k_t\le n$, such that

  $$A_0=w$$

  with

  $$w={\left(A_{k_1}\right)}^{{\lambda }_{k_1}}·{\left(A_{k_2}\right)}^{{\lambda }_{k_2}}\dots ·{\left(A_{k_t}\right)}^{{\lambda }_{k_t}}$$

  and

  $${\lambda }_{k_j}=\prod _{\begin{array}{c}r=1\\ r\ne j\end{array}}^t\frac{-k_r}{k_j-k_r}\mathrm{for}1\le j\le t.$$
  Once the participant finds t unique indices, the participant will proceed with step 5. Otherwise, this mining party may attempt step 4 again.
• When a mining party with identifier $id$ reconstructs w, i.e., finds suitable unique indices $1\le k_1,k_2,\dots ,k_t\le n$, it will publish $(m_{id},{\sigma }_{id})$ to the network, where

  $$m_{id}=(id,k_1,k_2,\dots ,k_t,({\mathtt{C}}_1,{\sigma }_1),({\mathtt{C}}_2,{\sigma }_2),\dots ,({\mathtt{C}}_{t-1},{\sigma }_{t-1})),$$

  and

  $${\sigma }_{id}=\mathtt{sign}({\mathtt{sk}}_{id},{\mathcal{H}}_1\left(m_{id}\right)).$$
• Any verifier can check a solution $(m_{id},{\sigma }_{id})$ by calling the function check shown by Algorithm 8.

  Algorithm 8 checks a solution

  1: function check($m_i,{\sigma }_{id},{\mathtt{vk}}_{id},{\mathtt{vk}}_1,{\mathtt{vk}}_2,\dots ,{\mathtt{vk}}_{t-1},{\mathtt{B}}_l$)

  2:     $b_0\leftarrow \mathtt{verify}({\mathtt{vk}}_{id},{\mathcal{H}}_1\left(m_{id}\right),{\sigma }_{id})$.

  3:     if $b_0=1$ then

  4:         $(id,k_1,k_2,\dots ,k_t,({\mathtt{C}}_1,{\sigma }_1),({\mathtt{C}}_2,{\sigma }_2),\dots$ $({\mathtt{C}}_{t-1},{\sigma }_{t-1}))\leftarrow m_{id}$

  5:         for $i\leftarrow 1$ to $t-1$ do

  6:            if $\mathtt{verify}({\mathtt{vk}}_i,{\mathcal{H}}_1({\mathtt{C}}_i\Vert {\mathtt{B}}_l),{\sigma }_i)=0$ then

  7:                return Reject

  8:            end if

  9:         end for

  10:         Compute $$A=\left(\prod _{i=1}^{t-1}{\mathtt{C}}_{i,0},\prod _{i=1}^{t-1}{\mathtt{C}}_{i,1},\dots ,\prod _{i=1}^{t-1}{\mathtt{C}}_{i,n}\right).$$

  11:         With the given indices $1\le k_1,k_2,\dots ,k_t\le n$, compute ${\lambda }_{k_j}={\prod }_{\begin{array}{c}r=1r\ne j\end{array}}^t\frac{-k_r}{k_j-k_r}\mathrm{for}1\le j\le t.$

  12:         Compute $w={\left(A_{k_1}\right)}^{{\lambda }_{k_1}}·{\left(A_{k_2}\right)}^{{\lambda }_{k_2}}\dots ·{\left(A_{k_t}\right)}^{{\lambda }_{k_t}}$

  13:         if $w=A_0$ then

  14:            return Accept

  15:         else

  16:            return Reject

  17:         end if

  18:     else

  19:         return Reject

  20:     end if

  21: end function

4. Protocol Analysis

In this section, we will make a deeper analysis of our proposed protocol.

4.1. Correctness of Our Proposed Protocol

We now analyze step 4 of our proposed protocol. Let us assume that each ${\mathtt{C}}_i$ obtained from participant i was created with a fixed probability $p_i$. Note that ${\prod }_{i=1}^{t-1}{R}_{i,k}=1$ for any $0\le k<n$, then

$$A_0=\prod _{i=1}^{t-1}{\mathtt{C}}_{i,0}=\prod _{i=1}^{t-1}{g}^{{\gamma }_i}{R}_{i,0}=\prod _{i=1}^{t-1}{g}^{{\gamma }_i}\prod _{i=1}^{t-1}{R}_{i,0}=\prod _{i=1}^{t-1}{g}^{{\gamma }_i}=g^{{\sum }_{i=1}^{t-1}{\gamma }_i}=g^{\alpha }=u$$

where $\alpha ={\sum }_{i=1}^{t-1}{\gamma }_i\mathrm{mod}q$.

Let us fix a k with $1\le k\le n$. Let us assume that ${\mathtt{C}}_{i,k}=g^{e_{i,k}}{R}_{i,k}$ with $e_{i,k}=c_i{k}^i+{\gamma }_i\mathrm{mod}q$ for all $1\le i\le t-1$. By construction, this occurs with probability $\rho =p_1{p}_2\dots p_{t-1}$. Therefore,

$$A_k=\prod _{i=1}^{t-1}{\mathtt{C}}_{i,k}=\prod _{i=1}^{t-1}{g}^{e_{i,k}}{R}_{i,k}=\prod _{i=1}^{t-1}{g}^{e_{i,k}}\prod _{i=1}^{t-1}{R}_{i,k}=g^{{\sum }_{i=1}^{t-1}{c}_i{k}^i+{\sum }_{i=1}^{t-1}{\gamma }_i}=g^{P\left(k\right)}$$

where $P\left(X\right)=c_{t-1}{X}^{t-1}+c_{t-2}{X}^{t-2}+\dots +c_{1}x+\alpha$ with $\alpha ={\sum }_{i=1}^{t-1}{\gamma }_i.$

If the mining party finds t suitable $k_1,k_2,\dots ,k_t$, then

$$A_{k_1}=g^{P\left(k_1\right)},A_{k_2}=g^{P\left(k_2\right)}\dots ,A_{k_t}=g^{P\left(k_t\right)}.$$

Hence,

$$A_0=g^{\alpha }=g^{P\left(0\right)}={\left(A_{k_1}\right)}^{{\lambda }_{k_1}}·{\left(A_{k_2}\right)}^{{\lambda }_{k_2}}\dots ·{\left(A_{k_t}\right)}^{{\lambda }_{k_t}},$$

where

$${\lambda }_{k_j}=\prod _{\begin{array}{c}r=1\\ r\ne j\end{array}}^t\frac{-k_r}{k_j-k_r}\mathrm{with}1\le j\le t.$$

In Section 4.2, we extend our analysis of this mining process.

4.2. Mining Process

We here further analyze step  4 of our proposed protocol.

4.2.1. Estimating n and s

Let us suppose t is fixed. Let ${\mathtt{C}}_i$ be the array obtained from participant i at step 4 of our proposed protocol for $1\le i\le t-1$. Assume that ${\mathtt{C}}_{i,k}$ for $1\le k\le n$ has been created with probability $p_i$ by the participant i. Note that the value $A_k$ depends on ${\mathtt{C}}_{i,k}$ for $1\le i\le t-1$. Therefore, $\rho ={\prod }_{i=1}^{t-1}{p}_i$ is the probability of obtaining a genuine entry $A_k$ in A. If we define the random variable X as the number of genuine $A_k$’s in the sequence of values $A_1,A_2,A_3,\dots ,A_n$, then X follows a binomial distribution with success probability $\rho$ in the sequence of n independent trials. Therefore, the expected number of genuine $A_k$’s is given by $E\left[X\right]=n·\rho$. By choosing n, such that $E\left[X\right]\ge t$, s is expected to be greater than t. Since $p_{min}$ is known and $0\le p_{min}\le p_1,p_2,\dots ,p_{t-1}\le 1$, then $n·p_{min}^{t-1}\le n·\rho =E\left[X\right]$, and so

$$E\left[X\right]\ge s_{min}=n·p_{min}^{t-1}\ge t$$

when $n\ge \frac{t}{p_{min}^{t-1}}$.

4.2.2. Expected Number of Attempts for Recovering $A_0$

We want to estimate the expected number of attempts to solve the proof of work assuming that the number of genuine $A_i$’s is at least t, i.e., $s\ge t$ (otherwise, the PoW cannot be solved). Let $\mathcal{Z}$ be the set of all combinations $[k_1,k_2,\dots ,k_t]$ out of $[1,2,\dots ,n]$.

A first strategy by the miner is to select $\Omega \subseteq \mathcal{Z}$ and call ${\mathtt{mining}}_0(\Omega ,A)$ as shown by Algorithm 9. We call $\omega$ a genuine combination if the reconstructed w is equal to $A_0$ (i.e., line 7 of the function ${\mathtt{mining}}_0$ satisfies). Otherwise, $\omega$ is a non-genuine combination.

Algorithm 9 describes the first mining strategy

1: function ${\mathtt{mining}}_0$($\Omega ,A$)

2:     while $\mathtt{True}$ do

3:         $\omega \stackrel{R}{\leftarrow }\Omega$

4:         $[k_1,k_2,\dots ,k_t]\leftarrow \omega$

5:         Compute ${\lambda }_{k_j}={\prod }_{\begin{array}{c}r=1\\ r\ne j\end{array}}^t\frac{-k_r}{k_j-k_r}\mathrm{for}1\le j\le t.$

6:         Compute $w={\left(A_{k_1}\right)}^{{\lambda }_{k_1}}·{\left(A_{k_2}\right)}^{{\lambda }_{k_2}}\dots ·{\left(A_{k_t}\right)}^{{\lambda }_{k_t}}$

7:         if $w=A_0$ then

8:            return $\omega$

9:         end if

10:     end while

11: end function

Let $N=|\Omega |$ be the total number of combinations in $\Omega$. Let $K_1$ be the number of genuine combinations in $\Omega$. Therefore, $K_2=N-K_1$ is the number of non-genuine combinations in $\Omega$. When $\Omega =\mathcal{Z}$, $N=\left(\genfrac{}{}{0pt}{}{n}{t}\right)$ and $K_1=\left(\genfrac{}{}{0pt}{}{s}{t}\right)$

Let $Y_0$ be the random variable that counts the number of iterations to find a genuine combination in $\Omega$ using the strategy ${\mathtt{mining}}_0$. Therefore, $Y_0$ follows a geometric distribution with success probability $\frac{K_1}{N}$. Hence,

$$Pr[Y_0=y_0]={(1-\frac{K_1}{N})}^{y_0-1}\frac{K_1}{N}$$

for $y_0=1,2,3,\dots$ and $=E\left[Y_0\right]=N/K_1.$

Note that at any iteration of ${\mathtt{mining}}_0$, nothing is learned about a particular $A_i$, i.e., it does not learn whether $A_i$ is genuine or non-genuine, but instead, it does learn whether a particular combination $\omega$ is genuine or not.

A seemingly better strategy is to pick $\Omega \subseteq \mathcal{Z}$ and call ${\mathtt{mining}}_1(\Omega ,A)$ as shown by Algorithm 10. Furthermore, if the mining party has access to computational resources, the party then may make a partition of $\mathcal{Z}$, i.e., pick ${\Omega }_1,{\Omega }_2,\dots ,{\Omega }_{n_p}$ with ${\Omega }_i\cap {\Omega }_j=\varnothing$ for $1\le i,j\le n_p$ with $i\ne j$, and $\mathcal{Z}={\bigcup }_{i=1}^{n_p}{\Omega }_i$; and sets and runs $n_p$ parallel processing tasks, where the processing task i searches over ${\Omega }_i$, viz. executes ${\mathtt{mining}}_1({\Omega }_i,A)$.

Algorithm 10 describes the second mining strategy strategy

1: function ${\mathtt{mining}}_1$($\Omega ,A$)

2:     for each $\omega \in \Omega$ do

3:         $[k_1,k_2,\dots ,k_t]\leftarrow \omega$

4:         Compute ${\lambda }_{k_j}={\prod }_{\begin{array}{c}r=1\\ r\ne j\end{array}}^t\frac{-k_r}{k_j-k_r}\mathrm{for}1\le j\le t.$

5:         Compute $w={\left(A_{k_1}\right)}^{{\lambda }_{k_1}}·{\left(A_{k_2}\right)}^{{\lambda }_{k_2}}\dots ·{\left(A_{k_t}\right)}^{{\lambda }_{k_t}}$

6:         if $w=A_0$ then

7:            return $\omega$

8:         end if

9:     end for

10:     return ⊥

11: end function

Let $Y_1$ be the random variable that counts the number of iterations to find a genuine combination in $\Omega$ using the strategy ${\mathtt{mining}}_1$. According to [34],

$$Pr[Y_1=y_1]=\frac{\left(\genfrac{}{}{0pt}{}{N-y_1+1}{K_1}\right)}{\left(\genfrac{}{}{0pt}{}{N}{K_1}\right)}\frac{K_1}{N-y_1+1}$$

for any $y_1\in \{1,\dots ,K_2+1\}$. Hence, $E_{Y_1}=E\left[Y_1\right]={\sum }_{y_1=1}^{K_2+1}{y}_{1}Pr[Y=y_1]=\frac{N+1}{K_1+1}$. Since $K_1\le N$, then $K_{1}N+K_1\le K_{1}N+N$ and, therefore, $E_{Y_1}=\frac{N+1}{K_1+1}\le \frac{N}{K_1}=E_{Y_0}.$

4.2.3. Experimental Results

Let $\mathcal{P}$ be the set $\{0.9,0.93,0.95,0.98,1\}$ and $\mathcal{T}$ be the set $\{20,30,40,50,60\}$. We carry out the following experiment, in which a trial consists of the following steps.

• Choose $p_{min}\in \mathcal{P}$, $t\in \mathcal{T}$. For the selected pair $(p_{min},t)$, choose a value for n, such that $n\ge \frac{t}{p_{min}^{t-1}}$.
• For the selected three-tuple $(p_{min},t,n)$, perform 100 runs of a modified mining phase (step 5 of our proposed protocol). At each run, the corresponding A is constructed; the numbers of genuine $A_i$ (i.e., the value of s), $E\left[X\right]$, and $s_{min}$ are computed. Moreover, $E\left[Y_0\right]$ and $E\left[Y_1\right]$ are computed, assuming $\Omega =\mathcal{Z}$.
• At the end of the trial, the means of all values s, $E\left[X\right]$, $s_{min}$, $E\left[Y_0\right]$, and $E\left[Y_1\right]$ are respectively computed.

Figure 2, Figure 3, Figure 4, Figure 5 and Figure 6 show the results obtained for $p_{min}\in \mathcal{P}$, $t\in \mathcal{T}$, and proper values of n.

Figure 2. Results obtained for $p_{min}=0.90\in \mathcal{P}$, $t\in \mathcal{T}$, and proper values of n.

Figure 3. Results obtained for $p_{min}=0.93\in \mathcal{P}$, $t\in \mathcal{T}$, and proper values of n.

Figure 4. Results obtained for $p_{min}=0.95\in \mathcal{P}$, $t\in \mathcal{T}$, and proper values of n.

Figure 5. Results obtained for $p_{min}=0.98\in \mathcal{P}$, $t\in \mathcal{T}$, and proper values of n.

Figure 6. Results obtained for $p_{min}=1\in \mathcal{P}$, $t\in \mathcal{T}$, and proper values of n.

4.3. Computational Cost Analysis

In this section, we analyze the computation costs related to some critical steps of our protocol. Let ${\mathtt{C}}_{GO}$ denote the cost of a group operation, and let ${\mathtt{C}}_{FA}$, ${\mathtt{C}}_{FM}$, and ${\mathtt{C}}_{FI}$ denote the costs of a field addition, field multiplication, and field inversion, respectively. We denote by ${\mathtt{C}}_{GE}$ the cost of an exponentiation in the group, i.e., $a^m$ with $a\in \mathbb{G}$. Using a generic fast exponentiation algorithm, then ${\mathtt{C}}_{GE}$ will have a cost of, at most, $r·{\mathtt{C}}_{GO}$, where $r=\lceil {log}_2\left(m\right)\rceil$.

Computational Costs of Step 4

Once a participant collects all $C_i$, the participant needs to compute $A_k={\prod }_{i=1}^{t-1}{C}_{i,k}$ for $k=0,\dots ,1,\dots n$. Note that computing $A_j$ has a cost of $(t-2){\mathtt{C}}_{GO}$; hence, computing A has a cost of $(n+1)(t-2){\mathtt{C}}_{GO}$.

Once the participant computes A, the mining process begins. Until completing the challenge, the participant will keep on selecting t distinct indices $1\le k_1,k_2,\dots ,k_t\le n$ out of $\{1,2,\dots ,n\}$, computing $w={\left(A_{k_1}\right)}^{{\lambda }_{k_1}}·{\left(A_{k_2}\right)}^{{\lambda }_{k_2}}\dots ·{\left(A_{k_t}\right)}^{{\lambda }_{k_t}}$ with ${\lambda }_{k_j}={\prod }_{\begin{array}{c}r=1\\ r\ne j\end{array}}^t\frac{-k_r}{k_j-k_r}\mathrm{for}1\le j\le t$, and checking whether $A_0=w$.

So the cost of computing w, denoted as ${\mathtt{C}}_w$, is ${\mathtt{C}}_w=t·{\mathtt{C}}_{GE}+(t-1)·{\mathtt{C}}_{GO}+t(t-1)(2·{\mathtt{C}}_{FM}+{\mathtt{C}}_{FI})$. Therefore, the whole mining process cost is roughly $E_{Y_1}({\mathtt{C}}_w+\delta )$ with $\delta$ being a constant.

4.4. Security Analysis

The goal of the adversary is to gain control over the creation of new blocks in the chain. To that end, he must generate solutions to the proof of works of the protocol and prove their validity to the other participants of the network. Since we assume the adversary is semi-honest, he follows the rules of the protocol but may want to learn as much as possible from the messages he receives from other parties to gain control over the creation of blocks in the chain.

First, note that our proposed protocol in steps 1–3 uses the joint random number generation protocol in parallel. At step 3 of our proposed protocol, what participant $1\le i\le t-1$ does is to create $n+1$ ElGamal public keys $R_{i,k},0\le k\le n$ from the other participant’s public $g^{{\kappa }_{j,k}}$ for $1\le j\le t-1$. Since the $R_{i,k}$ values are constructed from random Diffie–Hellman public-key and cannot be distinguished from random R’s, the security of this protocol can be reduced to the decisional Diffie–Hellman problem on the group $\mathbb{G}$ [30]. Furthermore, note that the private key associated with the public key $R_{i,k}$ is given by ${\sum }_{j=1,j\ne i}^{t-1}{\kappa }_{j,k}·s_i\left(j\right)·{\kappa }_{i,k}\mathrm{mod}q$ for each $k\in \{1,2,\dots ,n\}$ and is unknown to any participant, even colluding corrupt parties.

At step 4 of the protocol, a participant, say i, will send back ${\mathtt{C}}_i$ with the corresponding signature ${\sigma }_i$ to any requesting mining party. Note that each ${\mathtt{C}}_{i,k}$ is of the form $g^{ϵ}{R}_{i,k}$ for some $ϵ\in {\mathbb{Z}}_q$, i.e., ${\mathtt{C}}_{i,k}$ represents the ElGamal ciphertext of the message $g^{ϵ}$ under the public key $R_{i,k}$.

Claim 1.

A mining party can obtain a proper and fresh $A=[A_0,A_1,A_2,\dots ,A_n]$ if and only if the mining party has access to the corresponding $t-1$${\mathtt{C}}_i$ and computes

$$A=\left(\prod _{i=1}^{t-1}{\mathtt{C}}_{i,0},\prod _{i=1}^{t-1}{\mathtt{C}}_{i,1},\dots ,\prod _{i=1}^{t-1}{\mathtt{C}}_{i,n}\right).$$

Proof. 

In a direction (only if), we proved it in Section 4.1. In the other direction, if the requesting mining party has access to $l_0$ different ${\mathtt{C}}_{i,k}$ (possibly previous ones) with $l_0\ne t-1$, then the computed $A_k={\prod }_{i=1}^{l_0}{\mathtt{C}}_{i,k}$ will be of the form $g^{\beta }$ for some random $\beta \in {\mathbb{Z}}_q$. Hence, the adversary only learns $g^{\beta }$ and nothing else. □

Claim 2.

A mining party cannot reuse a ${\mathtt{C}}_i$ for future challenges.

Proof. 

Upon request to participant i at step 4, a mining party obtains $({\mathtt{C}}_i,{\sigma }_i)$, where ${\sigma }_i\leftarrow \mathtt{sign}({\mathtt{sk}}_i,{\mathcal{H}}_1({\mathtt{C}}_i\Vert {\mathtt{B}}_l))$, with ${\mathtt{B}}_l$ being the last block. Hence, the mining party cannot reuse any $({\mathtt{C}}_i,{\sigma }_i)$ as part of a solution to a future challenge. In particular, by calling the function $\mathtt{check}\left(\right)$, as shown by Algorithm 8, any verifier can discover any cheater. □

Moreover, the mining proccess is fair. Let us now assume a mining party (possibly an attacker) constructs a proper and fresh A, then such a party may start the mining process. By construction, such a party does not know whether he will find t suitable $k_1,k_2,\dots ,k_t$ in such A, with

$$A_{k_1}=g^{P\left(k_1\right)},A_{k_2}=g^{P\left(k_2\right)}\dots ,A_{k_t}=g^{P\left(k_t\right)}.$$

such that

$$A_0=g^{\alpha }=g^{P\left(0\right)}={\left(A_{k_1}\right)}^{{\lambda }_{k_1}}·{\left(A_{k_2}\right)}^{{\lambda }_{k_2}}\dots ·{\left(A_{k_t}\right)}^{{\lambda }_{k_t}},$$

where

$${\lambda }_{k_j}=\prod _{\begin{array}{c}r=1\\ r\ne j\end{array}}^t\frac{-k_r}{k_j-k_r}\mathrm{for}1\le j\le t.$$

If the mining party does not find suitable indices in A, the mining party may contact any of the $t-1$ participants to construct a proper and fresh A and start the mining process again. Furthermore, the party may request multiple $C_i$’s from a participant i, and then pick only a $C_i$ from the available ones for each i to obtain proper and fresh A’s, and finally search suitable indices in each created A.

From the previous analysis, we conclude that our proposed protocol can be regarded as secure and fair, assuming a semi-honest adversary.

5. Implementation

A proof-of-concept implementation of our proposed protocol was coded in the Python programming language. To simulate the protocol’s behavior on a peer-to-peer network, we used the implementation of a decentralized peer-to-peer network [35]. The protocol code was adjusted and some framework classes were modified for the correct implementation of the protocol and its peer-to-peer simulation. After making adjustments to the decentralized peer-to-peer network implementation, we wrote the logic of the proposed protocol in the following python classes:

• Generator class contains methods to create generators for $\mathbb{G}$.
• Zq class contains methods to carry out operations in ${\mathbb{Z}}_q$.
• MyRsa class contains methods for generating and validating RSA digital signatures.
• Participant class encloses the logic of the proposed protocol. It internally makes calls to P2P methods to send and receive messages over a P2P network.
• Protocol class contains the main method. It deals with instantiating the participants and calling functions for each protocol’s phase.

The protocol code was published on GitHub [36] and can be executed in a Google Colab notebook [37].

6. Comparison with Other Approaches

Following a similar approach as in [16], we carried out a qualitative comparison between our proposed protocol and the following proof-based consensus protocols: Pure PoW [38], Cuckoo hash function-based PoW [39], Prime number finding-based PoW [23], Double puzzles-based PoW [40], Non-outsourceable puzzles [41], Bitcoin-NG [42], GHOST strategy [43], Generalized PoW [44], Pure PoS (Nextcoin) [45], State of the block-based PoS [19], PoS by coin flipping from many nodes [46], Delegated PoS [47], Coin age-based PoW difficulty re-designation (Ppcoin) [20], Stake-based PoW difficulty re-designation (Blackcoin) [21], Coin age with an exponential decay function [48], Combining PoW and PoS to append blocks sequentially [49], with difficulty adjustment [50], Proof of activity [51], Puzzles designed for human PoW [22], Proof of burn [24], Proof of space [25], Proof of elapsed time [52], Proof of luck [53], Multichain [54]; and the following Vote-based consensus protocols: Hyperledger with practical Byzantine fault tolerance [55], Symbiont, R3 Corda with BFT-SMaRt [56,57], Iroha with Sumeragi [58,59], Ripple [60], Stellar [61], Quorum with Raft [62], Chain [63].

To perform our qualitative comparison, we defined a set of features that all of these protocols shared. Additionally, for each feature, we defined a rank of values with their corresponding numeric values. Table 2 shows the defined features with the values they can assume.

Table 2. Features and values used to cluster.

Feature	Description	Value
Energy efficiency	Efficient energy used to perform the tasks of the protocol	Yes = 0
		No = 1
		No need = 0
Modern hardware	Modern hardware requirements	Low need = 1
		Need = 2
		High = 3
		Never = 0
		Very difficult = 1
Forking	Possibility to perform a forking of the main chain	Difficult = 2
		Probably = 3
		Very Probably = 4
		Never = 0
Double-spending attack	Possibility of a double-spending attack	Difficult = 1
		More or less = 2
		Easy = 3
		Very fast = 0
		Fast = 1
Block creation speed	Speed to create a block	Low = 2
		Very low = 3
		Never = 0
		Very difficult = 1
Mining Pool	Amenable to mining pool creation	Can be prevented = 2
		Difficult to prevent = 3
		It occurs = 4
Number of participants	Number of participants in the protocol	Mostly unlimited = 0
		Limited = 1
Decentralization	Decentralization of participants	Mostly high = 0
		Low = 1
Trust	Trust of the network	More trustful = 0
		Less trustful = 1
Node Identities	Node identity management	No = 0
		Yes = 1
Security threat	Security threat to network	More serious = 0
		Less serious = 1
Award-giving	Award-giving to miner nodes	Yes = 0
		Mostly no = 1

Based on what is found in the literature, we assigned a value per feature per protocol, creating a dataset whose rows represent the names of protocols and columns represent the features. We then applied hierarchical clustering over the dataset to group the protocols; we worked with the method of least variance (Ward’s method); which seeks to obtain the least variability intra-cluster to ensure that each group is the most homogeneous possible. We finally identified the group (and, hence, the features) in which the proposed protocol (PoAc) was located. Figure 7 shows the groups created by the clustering algorithm.

Figure 7. Hierarchical clustering dendrogram.

As a result of the hierarchical clustering, we identified that PoAc is part of a group made up of proof of space, proof of burn, and puzzle designed for human PoW; using as reference the previously defined features, we can say that these protocols share the following features:

• Non-energy-efficient.
• Their need for modern hardware for its execution is low.
• They may present forking.
• Resistant to double-spending attack.
• Strategies may be deployed to prevent mining pools.
• High decentralization.
• Trustful
• Award-giving to a node adding a block to the chain.

We consider that our proposed protocol may be implemented and deployed in any blockchain, which decides the selection of the winning participant (that is, who wins the right to add a new block to the main chain) through a proof of work-based protocol (PoW). Additionally, our proposed protocol does not require the participants to have any particular hardware, making it implementable in blockchains where the hardware of the participants features any computing power.

A particular use case can be a decentralized application for registering anonymous touristic information where each participant in the network corresponds to a touristic operator. For this application, the integrity and availability of the data are crucial, and so there must be a control on registering data in the blockchain (making a consensus necessary). The touristic operators feature pieces of hardware that may not be homogeneous and typically present a low level of computation.

Additionally, this scenario may use its cryptocurrency for the consortium of touristic operators. A tourist can use it to carry out monetary transactions with the different operators, requiring trust between the participants. In addition to the touristic operators and their resources, tourists would participate in the network (even in the protocol) with mobile devices featuring varying computing power.

7. Conclusions and Future Work

Although the study of alternative consensus protocols has taken an interest in the scientific blockchain community recently, most of the related works are still theoretical ideas. Proof-of-accuracy protocols are a particular case since there are few papers about them in the literature, presenting neither concrete proof-of-accuracy protocols nor implementations.

This paper introduced a proof-of-accuracy protocol, starting with an initial and insecure design, which we progressively improved regarding security. Our proposed protocol removed the need for a coordinator and combined the proof of work component with access to random locations to improve the protocol’s resistance to majority attacks. Our analysis pointed out that it is secure and fair assuming a semi-honest adversary.

In future work, we would like to analyze and improve our proposed protocol in a scenario with dishonest participants, where they may not follow its rules or carry out attacks that may compromise its secret information. Another research topic is to make the protocol quantum-resistant since it is a Diffie-Hellman-like cryptographic construction, which is not quantum-resistant.