Blockchain Consensus Formation while Solving Optimization Problems

by   Naoki Shibata, et al.

This paper proposes a new decentralized consensus protocol for a blockchain.


page 1

page 2

page 3

page 4


Feasibility of Proof of Authority as a Consensus Protocol Model

Blockchain is a type of decentralized distributed network which acts as ...

SightSteeple: Agreeing to Disagree with Functional Blockchain Consensus

Classical and contemporary distributed consensus protocols, may they be ...

Analysis of LFT2

For a decentralized and transparent society, blockchain technology has b...

The Shutdown Problem: How Does a Blockchain System End?

We define and examine the shutdown problem for blockchain systems: how t...

Capivara: A decentralized package version control using Blockchain

Distributed consensus and Blockchains are popular among the cryptocurren...

Blockchain for Decentralization of Internet: Prospects, Trends, and Challenges

Blockchain has made an impact on today's technology by revolutionizing t...

SG-PBFT: a Secure and Highly Efficient Blockchain PBFT Consensus Algorithm for Internet of Vehicles

The Internet of Vehicles (IoV) is an application of the Internet of thin...

I Introduction

Since the introduction of Bitcoin[16]

, there have been many cryptocurrencies built on distributed public ledgers called blockchains. A blockchain is a growing list of blocks of data items, which is designed to be resistant to modification of the data. In a cryptocurrency, each transaction is registered as an item in a block. Bitcoin uses a Proof-of-work(PoW) system to decide which is the correct outcome of the latest transactions, and prevent double-spending of the coins. In a PoW system, the participating nodes are asked to do some computational task to make a majority decision on a one-CPU-one-vote basis. While PoW works very robustly against misbehaving and malicious participants on the network where impersonation is easy, the huge amount of electricity expended for PoW is becoming a problem. The estimated energy consumed by Bitcoin is at least 2.55 gigawatts in 2018, which is comparable to the electricity consumed in countries such as Ireland (3.1 gigawatts)


In order to address this problem of huge wasted energy, various alternatives to PoW and distributed public ledgers based on different working principles have been proposed. Although many of the alternative methods exhibits better energy efficiency, some of these methods introduce a single point of failure or they have to trust an external party. The main advantage of PoW is that it does not need to trust anything except that it requires a majority of CPU power to be controlled by honest nodes. There are only a few alternative methods that satisfy this condition. Bitcoin and cryptocurrencies based on PoW are still predominant because of unparalleled security and robustness.

In this paper, we propose a consensus protocol for blockchains, named Proof-of-search(PoS), in which the computation for making a consensus can be used to search for a good approximate solution of an instance of any optimization problem. Any user, called a client, can implement and submit a program called an evaluator that evaluates a solution candidate of a problem to be solved. In our protocol, a concatenation of a solution candidate and its evaluation value is used as a nonce, instead of an integer. In order to generate a valid nonce, a node has to execute the evaluator to evaluate some solution candidate. Since a large number of nonces have to be generated in the consensus process, a large number of solution candidates have to be evaluated. Our protocol also allows a client to provide a search program that implements any randomized search algorithm that finds a good solution by evaluating a large number of solution candidates. Our protocol has built-in functionalities for submitting problem instances and receiving the results. Effectively, a block chain with PoS can be used as a batch processing system. Clients can just submit a job without mining, and miners are not required to submit any job. If no job is submitted to the system, the system automatically adds an empty job that is equivalent to PoW. The nodes that succeeded in adding a new block and finding the best solution are rewarded in two different ways. The former node is rewarded in the same way as PoW. The latter node is rewarded only by the client. In this way, collusion between a client and a miner can be prevented.

Our protocol makes nodes search for good approximate solutions of multiple problems in parallel. This has secondary effect of lowering the probability of a fork and the variance of a block time. We show our results of analysis indicating that the probability of a fork and the variance of block time are lower with our protocol than with the PoW system.

The rest of this paper is organized as follows. Section II introduces related work. Section III explains our consensus protocol. In Section IV, we discuss properties of our protocol. In Section V, the conclusions are presented.

Ii Related Work

Ii-a Bitcoin and Proof-of-Work

Fig. 1: Distributed timestamp server in Bitcoin[16]

Bitcoin[16] is a robust, secure and decentralized cryptocurrency. It is built on a peer-to-peer distributed timestamp server to generate computational proof of the chronological order of transactions. This proof is provided by a PoW system. The idea of PoW was first proposed as a way to deter SPAM e-mails[6, 11]. In Bitcoin, PoW is used in majority decision making on a one-CPU-one-vote basis on peer-to-peer networks where a user can allocate many IP addresses and one-IP-address-one-vote does not work.

The distributed timestamp server in Bitcoin works by forming a linked list of blocks of data items to be timestamped(Fig. 1). Each block contains the hash value of last block and data items. Each time a new block is added to the chain, a hash value of the new block is computed and widely published. The PoW in Bitcoin involves finding a value whose hash value begins with a required number of zero bits. Each block has an entry for integer value called a nonce, and only a block that have a nonce that makes the block’s hash value begin with the required number of zero bits is accepted as a valid block. An incentive is provided to nodes to support the network by giving a new coin to the node that succeed in adding a new block. Network nodes that try to add a block are called miners. Honest miners try to add a new block to the longest chain. As long as a majority of CPU power is controlled by honest miners, the honest chain will grow the fastest, and in this way a majority decision is made. The time for a block to be added is called a block time. The required number of zero bits is automatically adjusted in order to make the expected block time 10 minutes.

Bitcoin is not a mere online payment system, but it aims at substituting a currency. For this purpose, the system has to be extremely robust. It does not depend on any party or computing node. The entity of Bitcoin is the data in the network. It will never vanish into nothing as long as there are enough honest nodes. Bitcoin has properties listed below.

  • Decentralized and self-regulated

  • No need to trust any node or any party

  • Hard to modify the data in blocks

  • Immune to Sybil attacks

  • The winning probability for each miner is proportional to its computation power

  • Legitimacy of blocks can be quickly verified anytime by any node

  • Any node can join anytime without pre-registration

However, Bitcoin requires miners to use their computation resources for PoW, which is basically repeated calculation of hash values. This is waste of computation resources and electricity.

Ii-B Alternatives to Proof-of-Work

To address the wasted computation resources and energy by Bitcoin, various alternative consensus protocols for blockchains have been proposed.

Proof-of-space[7] is a protocol between a prover and a verifier where the prover is supposed to store some large amount of data. A verifier asks a prover to send a piece of data in order to check if it still stores its data. The protocol is designed to make the computation, storage requirement and communication complexity of the verifier small. In order to use Proof-of-space in a decentralized blockchain, a way of determining the winning node and a way for each miner to know how likely it will win are required. The probability of winning should be proportional to the space allocated by each node. These practical considerations are discussed in [8]. As mentioned in the paper, Proof-of-space has its own weaknesses. One of the problems is that nodes can mine on multiple chains simultaneously. Miners can also try creating many different blocks with a single proof-of-space by altering the block contents slightly, and announce the most favorable one.

In Permacoin[14], mining resources are used for distributed storage of archival data. Successfully minting money requires random access to a local copy of a file. To mine coins, a miner needs to prove that the archive file is intact with a Proof-of-retrievability, which is an interactive protocol for cryptographically proving the retrievability of data.

In Proof-of-useful-work[2] and Primecoin[12]

, the computation for making a consensus is used for more meaningful purposes than calculation of hash values. The former enables the computation to be used for solving Orthogonal Vectors problems, while the latter makes a consensus by searching for chains of prime numbers. However, it is not clear how much public demand there is to find solutions of such problems.

Proof-of-stake, which is first implemented in Peercoin[18], is a consensus protocol that chooses the creator of the next block based on combinations of random selection and wealth or age. With this protocol, the one who has more coins will create blocks more often, and thus more coins are granted. In this protocol, the designated creator of the next block has to be trusted. Richest nodes are more likely to be selected, and thus they have control of the network.

Proof-of-activity[3] is a combination of PoW and Proof-of-stake. In this scheme, miners work on PoW to add an empty block header. In this header, a random group of validators are designated in the same way as in Proof-of-stake. These validators are asked to sign the new block. If the new block is signed by all the chosen validators, it is added to the chain. The advantage of Proof-of-activity is that it requires both a majority of CPU power and a majority of coins to take control of the cryptocurrency.

Proof-of-burn[17], is a consensus protocol that gives a right to vote to a node if it sends its coin to a special address where the coin cannot be redeemed. Obviously, nodes that have rights to vote have to be trusted in this scheme. There is another interesting use of Proof-of-burn, which is to move coins from a cryptocurrency to another cryptocurrency. In order to do this, the coins are sent to the address specific to the destination cryptocurrency, where the coins cannot be redeemed with the original cryptocurrency. Then, a new transaction is added to the destination cryptocurrency indicating that the user received the equivalent amount of coins, referring to the transaction in the original cryptocurrency.

Gridcoin[9] implements a Proof-of-research scheme, which rewards miners who perform computations on the Berkeley Open Infrastructure for Network Computing (BOINC)[1]. Although the computation for consensus protocol is used for scientific computations and thus the energy is used for very meaningful purposes, the cryptocurrency system has to depend on the BOINC system.

Proof-of-luck[15] and Proof-of-elapsed-time[10] utilize a trusted execution environment(TEE) to form a consensus. A TEE is special hardware that executes software securely with respect to confidentiality and integrity. With this kind of hardware, user’s interference to the consensus process can be avoided, and thus a consensus protocol can be realized relatively easily. However, only software signed by a trusted party can be executed on a TEE.

Tendermint[4] is a consensus protocol for blockchains without mining. In this protocol, a Byzantine fault tolerance algorithm is utilized to form a consensus among a known set of participants, and it is resilient up to of Byzantine participants. This protocol uses a Proof-of-stake approach in order to prevent Sybil attacks.

Nano[13] utilizes distributed acyclic graphs(DAG) to store transactions. In a DAG, transactions are stored in nodes, where each node corresponds to a single transaction. A conflict is resolved by a majority vote among representatives chosen by the participants. Each vote has a weight calculated as the sum of all balances of the participants who chose this representative.

Iii Proposed Protocol

We propose a new consensus protocol for blockchains, called Proof-of-search(PoS), which have all the advantages of Proof-of-work explained in II-A. PoS allows the computation power wasted in Proof-of-work to be used for searching for an approximate solution of an instance of optimization problem. It allows any node to submit a problem instance to be solved.

In this paper, a solution means an approximate solution. To solve a problem is to find an approximate solution of the problem.

Iii-a Key idea

Fig. 2: Distributed timestamp server in a minimal PoS scheme

We first introduce the concept of an evaluator, a searcher, a client and a job. An evaluator is a computer program that deterministically computes the evaluation value of a given solution candidate of an instance of an optimization problem. An evaluator has to always output the same value if the same input is given, regardless of the platform it is running on. An evaluator includes an instance of a problem. A job is data that represent an execution request of a search for a solution of an optimization problem. A job includes an evaluator and all necessary information regarding to the search request. Any node can submit a job to the system, and the node submitted a job is called a client. A job can be submitted to the system by registering the job on the blockchain. The ID of the client is also included in a job. For example, a client can implement an evaluator to evaluate a solution candidate of an instance of the traveling salesman problem(TSP). In this case, an order of visiting cities is an input of for the evaluator, and it outputs the total length of the tour.

In PoS, a concatenation of a solution candidate and its evaluation value is used as a nonce. The system chooses an evaluator from submitted jobs, and specifies which evaluator is used to generate a valid nonce to add the next block. In order to add a new block, a mining node has to find a nonce that makes the block’s hash value begin with a required number of zero bits, in the same way as in PoW. Unlike PoW, not every nonce is valid. In order to generate a valid nonce, a node executes the specified evaluator to evaluate some solution candidate. A valid nonce has to contain a solution candidate and its evaluation value. Since miners have to generate a large number of hash values to add a new block, we can enforce miners to evaluate a large number of solution candidates. By showing a valid nonce that makes the block’s hash value begin with a required number of zero bits, the system provides a probabilistic proof that the miners have carried out evaluations of a large number of solution candidates. Verification of a hash value is to execute the evaluator with the solution candidate in the nonce and confirm that the resulting evaluation value matches the one included in the nonce. Then, the hash value of the block is checked if it begins with the specified number of zero bits. In order to make verification quick, evaluation has to be quick.

There are two objectives of evaluation. One is to find a nonce that begins with a required number of zero bits. Another objective is to find a good solution with a good evaluation. In PoS, it is assumed that a large number of solution candidates have to be evaluated in order to find a good solution. A node that succeeds in finding the best solution among all nodes will be rewarded by the client. In order to make this search efficient, a client provides a computer program called a searcher

that implements a randomized search algorithm like a genetic algorithm. A searcher is included in a job, and executed by miners. It internally calls the evaluator many times. Each time an evaluation is made inside the searcher, it automatically calculates the hash value of the block to check if it begins with a required number of zero bits, and broadcast it if it does. The search continues until a new block is added.

In PoW, there is no need to prepare for a reuse of the results of computation in the past. This is because the only way to obtain a hash value is to compute the hash function, and the ID of miner and the last block are associated with the hash value. In PoS, we need to guarantee that an evaluation is made each time a block’s hash value is generated. Because the amount of computation in an evaluation can be substantially larger than that for calculating a hash value, miners would try to reuse the results of evaluations by sharing them among different nodes. In order to prevent this, we have to associate each result of evaluation to the ID of miner and other stuff. In order for this, we make an evaluator take the hash value of all the items in a block except the nonce itself, as the second argument. A tiny amount of error is introduced to the output of an evaluator in order to make the output depend on the second argument. This algorithm of introducing error has to be devised and implemented differently by each client. This is like using an evaluator as a substitute of a hash function, but such a property is not strictly required for an evaluator. If an evaluator is executed twice with the same solution candidate given for the first argument, and different values for the second argument, then it should be infrequent that the same value is returned, but this is not strictly prohibited. This will be further discussed in IV-A.

The data structure of blockchain with a minimal PoS scheme is shown in Fig. 2. This minimal scheme works with a single fixed evaluator, and it does not have a functionality to search for a good solution. A blockchain with this scheme works in a similar way as a blockchain with PoW. We are going to enhance this minimal scheme to add functionalities for submission of jobs, payment and execution of multiple jobs.

Iii-B Placing a job request

We want the following three properties in PoS.

  • A miner has a financial incentive to find and provide a good solution.

  • A node is not incentivized to submit a problem instance for which it already knows a good solution.

  • Submitting a problem instance that is not worth solving is financially discouraged.

Especially, we need to prepare for the case where a client knows a good solution for its job. Possible motivation for submitting such a job is listed below.

  1. It is advantageous in adding a block.

  2. It is rewarded by minted coin.

  3. The node can make a profit by finding a good solution.

We need to give honest miners a financial incentive to find a good solution, while preventing malicious miners from making a profit. In PoS, this is realized by making a client pay the charge for its job. Finding the solution with the best evaluation is only rewarded by this charge, and in this way, PoS has all the properties listed above. For item 1, knowing or finding a good solution is not advantageous in adding a block, as explained in III-A. For item 2, finding a good solution is not rewarded by minted coins. For item 3, a client cannot make a profit by finding a good solution with the job it submitted. Since a client has to pay the charge for its job, it only submits a problem instance that is worth paying the charge.

We want to make the payment process fully automated without trusting any node. In order to ensure the charge to be paid, it is collected before execution of a job. A client first submits a job including the charge. Then, the system automatically deducts the charge before execution of the job, and pays it to the winner after completion of the job.

The found solution has to be sent to the client. If a node simply broadcasts its solution to the network, this solution can be stolen by another node. If a node encrypts the solution with the public key of the client, the corresponding private key has to be published afterward, and the client has to be trusted to do that. In order to make sure that the node that found the best solution is paid automatically without having the solution stolen by other nodes or trusting any node, each node first registers the evaluation value of the found solution and the hash value of a concatenation of its ID and the solution on the blockchain. Then, in the next block time, each node checks if its solution is the best. The winning node registers its solution on the blockchain, and then the charge is paid to the winning node after confirming that the solution is genuine.

Iii-C Simultaneous execution of multiple jobs

Fig. 3: Distributed timestamp server in the proposed method

In order to make the charge reasonable, we make miners execute multiple jobs at a time. We also want to make the winning probability of each node proportional to the computation power spent for the job. In order for this, we add mini-blocks between blocks, where each mini-block corresponds to a job. A mini-block consists of only a nonce, the ID of mining node, and the hash value of the last block, as shown in Fig. 3. Miners try to find a valid nonce of any mini-block that makes the mini-block’s hash value begin with the required number of zero bits. As explained in III-A, a valid nonce contains a solution candidate of the corresponding job and its evaluation value. Each time such a nonce is found, the node adds the corresponding mini-block by broadcasting the mini-block with that nonce. A block is added when all the mini-blocks are added for all the jobs specified by the system. New coins are rewarded to all the nodes that add the mini-blocks. Verification of hash values is to repeat the process explained in III-A for each mini-block.

Because of message delivery delay in a network, there could be a difference in the sets of messages received by two different nodes. Consequently, two mining nodes may have different sets of items to be included in a new block. Thus, two different nodes may be executing the jobs to add different blocks. In other words, these nodes are executing their jobs to add mini-blocks that contain the hash values of different blocks. In order to prevent a mini-fork and make a larger number of nodes work to add the same block, we make miners execute jobs on the longest chain whenever possible. Here, one chain is longer than another if it has more blocks. If two chains have the same number of blocks, the chain with more mini-blocks after the last block is longer. When a node receives a new mini-block added by another node, it checks if the chain associated with the new mini-block is longer. If this chain is valid and longer, the node immediately starts executing jobs on it. When a node adds a new mini-block, it also broadcasts the corresponding block and all the added mini-blocks that come after the block.

We make the expected amount of computation for each job proportional to the charge. It is fairly straightforward to realize this by making the system adjust the required numbers of zero bits in the hash values according to the charge. We now assume that the same amount of computation is required in an evaluation for each job. The system knows the average total charge of incoming job requests per block time, by scanning the requests placed in the past. The system also knows the average number of evaluations made by all miners per block time, by checking the block times and the numbers of zero bits of the past mini-blocks. Let denote the charge for job . The system should choose the combination of jobs to satisfy . Then, the number of zero bits for job should be set to satisfy .

Iii-D Execution environment

In order to implement PoS, an execution environment is needed for evaluators and searchers. In order to make the amount of computation for each job proportional to the charge, we need to compensate for the difference in the amount of computation of evaluation for each job. For example, if the evaluator for job takes two times of execution time compared to the evaluator for job , then 1 more zero bits should be required in the hash value with . Since execution of evaluator has to be deterministic, we need a platform-independent way of counting the number of steps. The number of steps can be, for example, the number of bytecode instructions executed on a virtual machine. The execution environment has to have a functionality to count the number of steps in execution of an evaluator. The required number of zero bits for each mini-block has to be adjusted according to the measured number of steps in execution.

Since any user can submit a job, an evaluator can be inappropriately implemented. In case evaluator takes too many steps for execution, there must be a way to terminate this execution after a specified number of steps. In order to make execution of evaluator deterministic, this step count has to be exact. If an evaluator crashes or is terminated, it is regarded as returning the worst evaluation.

It is possible that a searcher takes too much computation compared to the evaluator. This can be easily detected by checking the number of steps. In this case, a miner is allowed to switch the search algorithm to a simple random search. By doing this, the node can increase its hash rate while it would be less likely to find the best solution.

In summary, the execution environment has to satisfy the following conditions.

  • It allows safe execution of untrusted code.

  • It provides a way to guarantee that an evaluator runs deterministically.

  • It counts the number of steps of execution in a platform-independent way.

  • It returns the number of steps after execution.

  • It terminates execution after a specified number of steps.

Implementing an interpreter-based virtual machine for the execution environment satisfying all the above conditions should be straightforward. Execution can be made deterministic by not providing APIs that make execution non-deterministic.

Iii-E Compacting blockchain

With the method explained above, all the evaluators recorded in a blockchain have to be executed in order to verify a chain. However, the size of an evaluator would be significantly larger than a hash value, and the storage space for keeping all the evaluators can become a heavy burden in managing a blockchain. The required storage size can be reduced by relaxing the requirements in verification of a chain. If the participants think it is sufficient to verify a certain number of blocks, then the information regarding to the jobs recorded in the older blocks can be discarded. In Fig. 3, only the hash value above the dotted line is checked during verification of old blocks, and therefore the information below the dotted line can be discarded for old blocks. Even with this relaxed way of verification, it is very hard to modify the items in the old blocks without redoing all the PoS for the new blocks.

0:  Job request
0:  Best found solution
1:  Register to the blockchain.
2:  Wait until a solution is received.
3:  return  
Algorithm 1 Place a job execution request
1:  Wait until a new block is added.
2:  Set to the added block.
3:  while true do
4:     {Process for the jobs that will be executed in the next block time}
5:     Create the list of valid unexecuted jobs.
6:     Choose the jobs that will be executed in the next block time.
7:     Deduct the charge of these jobs from the client.
8:     Include these jobs in the block being added.
9:     {Process for the jobs that is executed in the current block time}
10:     Verify newly received items(transactions) and put them in the block being added.
11:     {Process for the jobs that were executed two block times before}
12:     Check the blockchain to see if the solutions found two block times before were the best solutions, as explained in III-B. Register the solutions to the blockchain if they were the best.
13:     {Process for the jobs that were executed three block times before}
14:     Check if the registered solutions are genuine. Process payment of the corresponding charge.
15:     repeat
16:        Execute one of unfinished jobs listed in the previous block, until a new mini-block is received.
17:        Register the hash value of found solution to the blockchain(see III-B). This hash value will be included in the next block.
18:        Verify the chain associated with the received mini-block by calling Algorithm 3.
19:        if the mini-block is valid and the corresponding chain is longer then
20:           Change to the chain with the mini-block.
21:           Move the items in orphaned blocks to the list of newly received items.
22:        end if
23:     until a new block is added
24:  end while
Algorithm 2 Mine
0:  Mini-block
0:  Verify the chain corresponding to and returns iff it succeeds.
1:  for all blocks in the chain pointed by in chronological order do
2:     if the same block as is included in a previously verified chain then
3:        continue
4:     end if
5:     Check all the transactions in , return if it fails.
6:     if  is old then
7:        Do relaxed verification explained in III-E and return if it fails.
8:     else
9:        for all mini-blocks between and the next block do
10:           if the same mini-block as is included in a previously verified chain then
11:              continue
12:           end if
13:           Execute the evaluator and check if the nonce and all the hash values satisfy the corresponding requirements, return if it fails.
14:        end for
15:     end if
16:  end for
17:  return  
Algorithm 3 Verify
0:  Hash of the block to be added, node ID , evaluator
0:  The best solution candidate found in the search
2:  repeat
3:     Generate a random solution candidate .
5:     if  is better than  then
7:     end if
9:     if  begins with the required number of zero bits then
10:        broadcast the mini-block.
11:        break
12:     end if
13:  until a new mini-block is received
14:  return  
Algorithm 4 Random search

Iii-F Putting them all together

Our protocol is an enhancement of PoW, and thus it uses techniques common with PoW. A blockchain with our protocol is structured as a peer-to-peer network. The entire network is loosely connected without a fixed topology. In order for a node to join a network, it has to know one of the nodes that is already a part of the network. Each node connects to several random nodes. A message is broadcast with a gossip protocol. Each node retains a copy of the entire information of a blockchain.

Our protocol allows any client to submit a job and receive the solution. This is very simple from the point of view of a client, as shown in Algorithm 1.

In order for a job to be executed and the resulting payment to be made, it takes at least 4 block times. The following is how a job is processed in the fastest scenario.

Block time 0 A job is broadcast by the client.

Block time 1 Validity of the job is inspected. The charge is deducted from the client’s account. This job is chosen for execution in block time 2.

Block time 2 The job is executed.

Block time 3 Each node broadcasts the hash value of found solution. These hash values are registered on the blockchain.

Block time 4 The charge is paid to the node that found the best solution.

Job execution and payments are all processed by miners. Miners process jobs in a pipelined manner. Algorithm 2 shows how they are processed from the miner’s point of view.

There are two threads running in parallel, and Algorithm 2 runs on one of them. In the other thread, the received items are enqueued in the list of newly received items. In order to register an item on the blockchain, it has to be broadcast to the network. When these items are received by a miner, they are enqueued in the list.

After Algorithm 2 starts, the miner first choose the chain to work on(line 1-2). There can be multiple valid chains, and they all begin with the same block. One specific sequence of block, or a chain, can be specified by the last block. The miner starts working on the chain associated with the first block received.

At line 5, the balance of the client’s account is checked.

At line 8, in order to make all the miners work on the same set of jobs, a consensus has to be made on the set of jobs and the corresponding numbers of zero bits before the miners start working on them.

At line 16, a searcher is executed in the execution environment explained in III-D. As an example of a searcher, a random search algorithm is shown in Algorithm 4. As explained in III-A, this searcher internally calls the corresponding evaluator. Each time an evaluator is called, it automatically creates the nonce with the result of evaluation, and checks the hash value if it begins with the required number of zero bits. If it does, the new mini-block is broadcast, and the execution of searcher is terminated. The execution of searcher also terminates if a new mini-block is added by another mining node. Please note that when a new block is added, the last mini-block for that block is also added.

At line 18, the chain associated with a mini-block is verified. This procedure is shown in Algorithm 3. This algorithm works as explained in III-C and III-E. There is no need to verify blocks and mini-blocks if exactly the same blocks or mini-blocks are included in a chain previously verified by that node.

At line 21, the items contained in orphaned blocks are moved to the list of newly received items. An orphaned block is a block that was a part of the chain worked on by the miner, but no more because the miner is working on another chain now.

Iv Consideration

Iv-a Requirements for evaluator

The whole scheme of PoS depends on the way it enforces an evaluation each time a hash value is generated.

We now consider an attack where one of the items in Fig. 2 is altered by a miner. Altering an item in a block is not always easy, but here we assume a pessimistic scenario in which the miner can alter an item freely. Suppose that an evaluator returns the same value at a rate of once per times if the same first argument and a different second argument are given. The miner could try calculating the hash value of a block faster than it should be in the following way.

  1. The miner alters the item.

  2. Calculate the hash value of the block assuming that the evaluator returns the same value.

  3. Check if the hash value begins with the required number of zero bits.

  4. If it does, then execute the evaluator to check if it returns the assumed value.

The above attempt succeeds at a rate of once per times. The rate of generating the valid hash value of a block is higher with this method if evaluation is very slow and is small. In order to prevent it from paying off, the following condition has to be satisfied.

Iv-B Probability of fork

Fig. 4: Probability of a fork after a block is added, with mini-blocks

A fork in blockchain is a situation where there are two or more valid chains with the same length. In Bitcoin, a fork happens when a mining node adds a block before knowing that another node has already added a block. This can happen because of message delivery delay in a network.

Now we discuss how the probability of fork is affected by introducing mini-blocks. For the sake of simplicity, we suppose that there are only two mining nodes in the network. A communication channel with a constant delay connects them. We can model block creation as a Poisson process. Now, suppose that node has created a block right now. Then, the probability of a fork within time is the probability that the other node creates another block within this time period, while does not create a block in this period.

where is the average number of block creation per interval node.

We now assume that all mini-blocks require the same expected amount of computation to be added. The probability of a fork with length after a creation of some block is the probability of this event to happen times in succession.


In the proposed method, mini-blocks are required to be added before adding a new block. Therefore, the above event has to succeed times in order for a fork to happen.

We now assume that all mini-blocks have the same creation rate , where is the number of mini-blocks required to add a block. Equation 1 is plotted in Fig. 4. It is shown that the probability of a fork can be significantly lowered by increasing the number of mini-blocks.

Iv-C Variance of block time

Fig. 5: Probability of a block to be added within a time period, with mini-blocks

Now we discuss how the variance of a block time is affected by introducing mini-blocks. The probability of a block to be added within time period is the probability of or more mini-blocks are added within this period. We have mini-block creation per interval in average, and then,


Fig. 5 shows the probability of a block to be added within a time period. The expected block time is 1, and the variance is . This means that the variance of block time decreases as the number of mini-blocks increases.

Iv-D Winning probability of a node

In Bitcoin, the winning probability for each miner is proportional to its computation power. This is because when a block is added, the probability for each node to be the node that added the block is proportional to the number of hash values generated by that node.

Now we discuss the winning probability of each node to add each mini-block. Suppose that there is no message delivery delay, and all nodes share the latest information. When a new block is added, the total computation for adding all the corresponding mini-blocks is the same as the total computation power spent by miners in that block time. The probability for node to add mini-block is as follows.

Iv-E Properties of PoS

The following is the list of properties that PoS has.

  • All the properties of PoW listed in II-A are preserved.

  • Any node can submit a job and become a client.

  • A client can specify any instance of an optimization problem in a job.

  • A client can implement any search algorithm for any optimization problem for a job.

  • A client pays a charge for its job.

  • Miners have a financial incentive to find a good solution for the instance in a job.

  • Miners have a financial incentive to provide the best found solution to the client.

  • The charge is automatically paid to the node who provides the best solution to the client.

  • A probabilistic proof that the miners have evaluated a large number of solution candidates is provided.

  • Multiple jobs can be executed at a time.

  • The winning probability for each miner to find the best solution is proportional to the computation power spent by the miner for the job.

  • The expected amount of computation for a job is proportional to the charge paid for the job.

  • The variance of block time is lower than that with PoW.

  • The probability of a fork is lower than that with PoW.

  • The storage capacity required to manage a blockchain based on PoS is not too large.

  • A blockchain based on PoS accepts jobs that run on computers with different architectures.

PoS has built-in countermeasures against the following cases.

  • A node submits a problem instance which the node already knows a good solution.

  • A node has very effective way of searching for a solution of some specific problems.

  • A node tries to steal a solution found by another node.

The requirements for an evaluator are as follows.

  • It takes a solution candidate for the first argument, and a hash value for the second argument.

  • It returns the evaluation of the solution candidate with a tiny amount of error depending on both the arguments.

  • It has to satisfy the condition explained in IV-A.

Iv-F Security consideration

Irrespective of search strategies, there is no difference in difficulty of generating a valid nonce. Thus, the following items are allowed for nodes.

  • Using its own search method, instead of the provided searcher.

  • Sharing intermediate results of a search among other nodes.

  • Participating in a search for only a particular job, instead of trying to add a whole block.

  • Starting the search right after a job is submitted.

There is always possibility for an evaluator to be reverse-engineered. If some malicious party comes to know how error is introduced in some specific evaluator, they would try to quickly compute the output of evaluator with a different second argument by reusing the result of previous evaluation. This is a potential flaw of PoS, but can be prevented by introducing error in an early stage of evaluation, rather than the last step. For example, an evaluator for TSP could be implemented to introduce error by slightly changing the positions of cities.

When a mini-block is added, the corresponding nonce with a hash value beginning with a required number of zero bits is broadcast to the network. A solution candidate is included in this nonce, and we can think of a cheat where a miner tries to find a better solution by taking advantage of this solution candidate. There is about one block time to carry out a search after a nonce is received, before the deadline of registering a hash value of the found solution. However, such an attempt would be hardly advantageous because this solution candidate is found in the middle of a search, and therefore it is unlikely to be the best solution found by the node that added the mini-block. It is also not very likely that the node that adds the block also finds the best solution among all nodes.

We can think of another cheat where a malicious client implements an evaluator in such a way that it returns unfairly high evaluation when a special solution candidate is given. The client would implement the searcher in such a way that it does not evaluate such a solution candidate. By submitting a job with such an evaluator, the client can almost always find the best solution, and collect the charge. However, this client cannot obtain the solutions found by other nodes, because a node publishes its solution only if it is the winning node. The client is still be able to obtain the solution candidate contained in the nonce. However, this would not be a very good solution candidate, as explained above. Such a cheat can be financially discouraged by giving a part of charge to the node that added the new block.

There are several ways of making a denial-of-service(DoS) attack that prevents execution or payment for jobs, although most of them are not very effective. We can think of a DoS attack where a malicious node registers a false good evaluation with a false hash value on the blockchain when the best found solution is chosen and provided to the client. This prevents the client from receiving the true solution. If there is a node that makes such an attack, that node has to be banned from the network and the payment process has to be started over.

V Conclusion

We have proposed a consensus protocol for blockchains with which the wasted energy in the Proof-of-work system can be used for solving optimization problems submitted by any users. We showed that the probability of a fork and the variance of block time can be lowered with the proposed protocol.

A blockchain with our protocol can be viewed as a grid computing infrastructure. The computation service provided by such a blockchain would be beneficial for computation tasks whose intermediate results can be published. We expect that there is a large public demand for such a computation service, considering popularity of the BOINC projects and public clouds.

The computation in our protocol is ASIC resistant. This will make mining with ordinary CPUs more profittable. Unlike cloud computing, computers used in mining need not be reliable. Since the computation resources are not wasted anymore, public organizations and more general users are expected to join. This would make the blockchain with our protocol more decentralized than existing ones.


  • [1] D. P. Anderson (2004) BOINC: a system for public-resource computing and storage. In Proceedings of the 5th IEEE/ACM International Workshop on Grid Computing, GRID ’04, Washington, DC, USA, pp. 4–10. External Links: ISBN 0-7695-2256-4, Document Cited by: §II-B.
  • [2] M. Ball, A. Rosen, M. Sabin, and P. N. Vasudevan (2017) Proofs of useful work. IACR Cryptology ePrint Archive 2017, pp. 203. Note: Accessed: 2017-06-29 Cited by: §II-B.
  • [3] I. Bentov, C. Lee, A. Mizrahi, and M. Rosenfeld (2014) Proof of activity: extending bitcoin’s proof of work via proof of stake. ACM SIGMETRICS Performance Evaluation Review 42 (3), pp. 34–37. Cited by: §II-B.
  • [4] E. Buchman (2016-06) Tendermint: byzantine fault tolerance in the age of blockchains. Master’s Thesis at University of Guelph, Ontario. Note: Accessed: 2017-02-06 Cited by: §II-B.
  • [5] A. de Vries (2018-05)(Website) External Links: Link Cited by: §I.
  • [6] C. Dwork and M. Naor (1992) Pricing via processing or combatting junk mail. In Annual International Cryptology Conference, pp. 139–147. Cited by: §II-A.
  • [7] S. Dziembowski, S. Faust, V. Kolmogorov, and K. Pietrzak (2015) Proofs of space. In Advances in Cryptology – CRYPTO 2015, R. Gennaro and M. Robshaw (Eds.), Berlin, Heidelberg, pp. 585–605. Cited by: §II-B.
  • [8] G. Fuchsbauer (2015) Spacemint: a cryptocurrency based on proofs of space. ERCIM News 2017. Cited by: §II-B.
  • [9] R. Halford (2014-05) Gridcoin: crypto-currency using berkeley open infrastructure network computing grid as a proof of work. External Links: Link Cited by: §II-B.
  • [10] Intel Corporation (2017)(Website) External Links: Link Cited by: §II-B.
  • [11] M. Jakobsson and A. Juels (1999) Proofs of work and bread pudding protocols. In Secure Information Networks, pp. 258–272. Cited by: §II-A.
  • [12] S. King (2013-07) Primecoin: cryptocurrency with prime number proof-of-work. External Links: Link Cited by: §II-B.
  • [13] C. LeMahieu (2008)(Website) External Links: Link Cited by: §II-B.
  • [14] A. Miller, A. Juels, E. Shi, B. Parno, and J. Katz (2014) Permacoin: repurposing bitcoin work for data preservation. In Security and Privacy (SP), 2014 IEEE Symposium on, pp. 475–490. Cited by: §II-B.
  • [15] M. Milutinovic, W. He, H. Wu, and M. Kanwal (2016) Proof of luck: an efficient blockchain consensus protocol. In SysTEX ’16 Proceedings of the 1st Workshop on System Software for Trusted Execution, pp. 2:1–2:6. Cited by: §II-B.
  • [16] S. Nakamoto (2008-12) Bitcoin: a peer-to-peer electronic cash system. Note: Accessed: 2015-07-01 External Links: Link Cited by: §I, Fig. 1, §II-A.
  • [17] P4Titan (2014)(Website) External Links: Link Cited by: §II-B.
  • [18] N. Popper (2013-11) In Bitcoin’s orbit: rival virtual currencies vie for acceptance. External Links: Link Cited by: §II-B.