An Approach for Blockchain Pool Mining Employing the Consensus Protocol Robust against Block Withholding and Selfish Mining Attacks

Abstract

This paper proposes an approach for pool mining in public blockchain systems based on the employment of a recently reported consensus protocol with the puzzle based on a symmetric encryption that provides an energy–space trade-off and reduces energy consumption. The proposed architecture employs a pseudo-symmetric allocation of the resources for the blockchain consensus protocol and provides protection against certain malicious actions of the pool members, as well as a miner’s opportunity for selecting the resources required for participation in the consensus protocol. Given that the considered consensus protocol employs two resources, the proposed architecture uses this two-dimensional nature to provide resistance against block withholding and selfish mining attacks, as well as a reduction in energy spending as a trade-off with the employment of certain memory resources. The high resistance of the proposed pool mining approach against the considered attacks appears to be a consequence of the success probability of the pool in comparison with the success probability of malicious miners. Assuming appropriate selection of the puzzle hardness, the probability that malicious miners can solve the puzzle without the support of the pool manager can be arbitrarily small. Implementation of the proposed approach on a modified Ethereum platform and experimental evaluation issues have also been reported. The conceptual novelty of the proposed pool mining approach is the following: Instead of separation of the blockchain consensus protocol and control of pool miners honest work, this paper proposes an approach where honest work of miners and pool managers is provided by a dedicated application of the considered consensus protocol. Advantages of the proposal in comparison with the previously reported ones include the following: (i) high resistance against block withholding and selfish mining attacks without an additional security procedure; (ii) reduction in the energy required, and at the same time preservationthe security of the consensus protocol; (iii) flexibility of the pool miners regarding selection of the resources that should be employed providing a trade-off between required energy and memory resources. The proposed architecture was implemented employing a dedicated modification of the Ethereum platform and the performed experiments confirmed the feasibility and effectiveness of the proposal.

1. Introduction

Blockchain technology has been widely recognized as a very important one after its first breakthrough application for cryptocurrency “Bitcoin”. Blockchain technology provides verified updates of a distributed and strictly expanding database in a distributed and immutable manner. This database is called blockchain and it is a decentralized digital ledger. A blockchain system consists of the following two basic classes of entities: ordinary users and the entities that participate in the system operations called miners (they could act as users, as well). One of the key issues is that in blockchain systems the verification is performed without a third trusted party. Instead, the blockchain system provides verification by the miners that participate in the consensus protocol. Regarding the miners, there are two main types of blockchain systems: permissionless or public blockchain and permissioned. In the public blockchain any entity could be a miner, as compared to permissioned blockchain systems where only selected entities play the role of the miners. In public blockchain systems, execution of the consensus protocol mainly requires that the miners solve a computationally hard problem. More details on the blockchain systems and consensus protocols can be learned from [1,2,3], for example. An added functionality of blockchain with an increased importance is smart contracts and a recent illustrative review is given in [4]. Applications of blockchain technology record a huge increase and a recent overview is given in [5].

Pool mining assumes that a miner joins a pool of miners operated by a pool manager instead of acting as a solo miner. Pool mining appears to be the preferable working approach in public blockchain systems based on proof-of-work-like consensus paradigms (see [6], for example). The main objective for miners to join mining pools is to receive regular income, in contrast to solo mining, where the rewards are infrequent and have a low appearance rate. The mining process for miners can be seen as a type of lottery, where the probability that individual miners with small computational power will win the next block proposition is almost negligible. Mining within a mining pool reduces the effects implied by this very low probability.

Motivation for the Work. The blockchain pools of miners are vulnerable to malicious miners who could join the open pools. On the other hand, pool mining is the main mining approach, and accordingly pool miners’ honesty is well recognized as an important issue in order to protect the pool from malicious miners. Although there are a number of proposals for reducing this vulnerability, an interesting open issue is the consideration of advanced pool mining architectures that provide enhanced security against malicious activities. In particular, please note that the hash-based blockchain puzzle has the following two drawbacks: (i) it requires heavy energy consumption, (ii) during the sub-problem solving process, a malicious miner could find a solution to the main puzzle, and it does not disclose it to the pool manager in order to perform block withholding or selfish mining-based attacks. Accordingly, it is interesting to consider Proof-of-Work (PoW) based blockchain consensus protocols that are not based on the hashing problem, and that generically provide a potential for developing a mining framework that yields high security against certain attacks, such as block-withholding attacks and selfish mining against a pool of miners. In particular, an origin for alternative design is that generic approach for solving hard inversion problems (solving certain cryptographic puzzles) is not only an exhaustive search (employed in hash-based PoW), but in certain cases could be the so-called “codebook approach” where instead of an exhaustive search, a pre-specified memory is employed, as well as a combination of these two approaches known as time–memory trade-off. It is well known that the exhaustive search-based PoW requires an amount of energy that limits its applicability.

Summary of the Results. This paper proposes and evaluates security, yields an implementation framework, and experimentally considers an approach for pool mining in public blockchain systems. In particular, a novel architecture for pool mining and the corresponding procedure for interaction between a miner and the pool manager are proposed. The proposed architecture provides (i) miners’ flexibility in selecting the resources required for participation in the consensus protocol and (ii) high resistance against the main attacks that could appear within pool mining, such as block-withholding attacks and selfish mining. The architecture is based on employment of the recently reported blockchain consensus protocol [7], with the puzzle based on symmetric key encryption, and employs energy and space resources and appropriate control of these resources. The architecture separates the energy and memory resources between the miners and pool manager in a quasi-symmetric manner and yields power to the pool manager to control access to the memory resources, i.e., tables, which provide substantial efficiency for solving the consensus protocol puzzle. The success rate of pool mining and robustness against malicious miner attacks are considered. A dedicated protocol for communication between a miner and pool manager is proposed. It is shown that the success probability of malicious miners verifying a block could be made arbitrarily small in comparison with the pool success probability, implying robustness against block-withholding attacks and selfish mining. The implementation framework of the proposed architecture is given based on employment of a modified Ethereum platform, where the proof-of-work (PoW) consensus protocol is replaced by the protocol reported by the one based on the energy–memory trade-off. According to the above, in comparison with the previously reported results, this paper yields the following novelties: (i) A different paradigm is employed for providing resistance against the block-withholding and selfish mining attacks: The resistance is incorporated into the consensus protocol oppositely to the previously reported approaches where the consensus protocol and control against the considered attacks are independent issues. (ii) A novel architecture for pool mining is proposed where the miners and the Pool Manager combine their resources for performing the consensus protocol. (iii) The pool mining employs a consensus protocol that provides flexibility concerning the resource selection required at a miner’s side and reduction in the total pool energy consumption. The reported experimental work was carried out as follows: (i) Implementation of a modified Ethereum platform for the pool mining according to the proposed architecture; (ii) in order to prove the feasibility of the proposed mining approach, the experiments were conducted on a platform with an Ubuntu 20.04 operating 536 system that has an Intel Core i7-10750H CPU @2.60 GHz with 12 cores; (iii) experiments have confirmed the feasibility and effectiveness of the proposal.

Organization of the Paper. Section 2 summarizes the background for this paper. A proposal for a pool mining approach based on a novel pool mining architecture and the corresponding communication procedure between a miner and the pool manager is given in Section 3. An analysis of the proposed pool mining is given in Section 4. Section 5 discusses implementation and experimental evaluation issues. Conclusions are given in Section 6. Finally, Appendix A and Appendix B contain certain technical issues.

2. Background

2.1. Pool Mining

Pool mining is the dominant approach for the participation of a miner in a blockchain system, particularly in public blockchain systems that involve proof-of-work-based consensus protocols. Pool mining provides a miner with a working framework that preserves the return of mining investment because a miner will be rewarded for work efforts even if they do not yield a mining solution. Different issues regarding pool mining are reported in a number of papers beginning with [8] and including recent studies [6,9,10,11,12]. Taking into account difficulty in finding a valid solution of a cryptographic puzzle, the operator of the pool will reward participating miners based on work efforts at solving the subpuzzles distributed to the miners. The difficulty of a subpuzzle is much smaller than the challenging puzzle, and the miners can find the solutions of the sub-puzzles with reasonable effort. The operator of the pool will let its miners submit as many solutions of the subpuzzles as they can and distribute the rewards among its miners according to their submitted solutions. A solution of the subpuzzle has the probability of being the solution of the blockchain puzzle. If the solution found by the miners also satisfies the difficulty of the current blockchain puzzle, it is the complete solution; otherwise, it is a partial solution. Note that only if the pool can find a complete solution can it receive the reward. If the partial solution is not a complete solution, the pool does not receive any reward, but the miners receive compensation for their work. A problem is that a pool of miners, in public blockchains, could contain not only honest but also dishonest miners, which submit to the pool only partial solutions that are incomplete, and they still receive rewards for the pool mining participation. A number of attacks could also appear, including so-called block-withholding and self-mining attacks, which are summarized below.

2.2. Block-Withholding Attack

In a block-withholding attack, dishonest miners will only submit partial solutions to the pool but the complete solutions will be hidden. Block-withholding attacks are disadvantageous for both pools and their miners because they can greatly reduce the winning probability of the pools in the mining games, so the expected rewards for the pools and their miners can be substantially reduced. This attack is possible since each miner can know whether the obtained partial solution is a complete solution or not. Illustrative results regarding the block-withholding attack have been reported in [13,14,15,16].

2.3. Selfish Mining

Selfish mining is a variant of block-withholding attacks, and there are the following two main types of malicious approaches: (i) Block-withholding delay, in which newly mined blocks are released with intentional delay to increase the attacker’s revenue; and (ii) Block-withholding attack, where the withheld blocks are never released to degrade the mining utility of the victim pool and miners.

The selfish mining approach consists of the following: In contrast to an honest miner, one or more attackers do not release a block immediately upon mining it, and instead, selfish miners try to mine more blocks to build a private extension branch of the blockchain. The main goal is to build a blockchain that will be longer than the one mined by honest miners and release it at a suitable time with the goal of wasting honest miner work and gaining larger revenue. Selfish miners not only obtain rewards but also grow in a snowball-like manner to obtain the majority. For an illustration of the reported issues on selfish mining, we point to [17,18].

2.4. Blockchain Consensus Protocol Based on Energy and Memory Resources

The blockchain mining employed in this paper is based on the consensus protocol reported in [7], as well as its reported security evaluation. The consensus protocol proposed in [7] follows the same framework as the traditional consensus protocols for public blockchains based on PoW employed in Bitcoin and Ethereum. Accordingly, each execution of these protocols consists of the following three main phases: The first is construction of a block of transactions. The second phase is the process of solving a puzzle. The final phase is inclusion of the considered block into the blockchain under the assumption that no one transaction from the block has already been included in the blockchain. The main differences of the blockchain consensus protocol reported in [7] and the previously reported protocols are related to the following two issues: (i) the puzzle that has to be solved, and (ii) construction of the challenge for the puzzle and technique for solving the puzzle. The employed puzzle, and the solving method are explained in Appendix A.

3. Proposal for the Pool Mining Approach

This section proposes a pool mining approach that provides (i) high resistance against block-withholding attacks and selfish mining, and (ii) a high reduction in the energy required for the consensus protocol at a suitable trade-off with a requirement for employment of certain space (memory) resources. Consequently, this section yields a novel architecture for the pool mining and corresponding procedure for interaction between a miner and the pool manager.

3.1. Underlying Ideas

We employ the blockchain consensus protocol summarized in Section 2 with the following consensus puzzle: For given ciphertext $\mathbf{c}$ find the encryption key $\mathbf{k}$ such that

$$\mathbf{y}=E_{\mathbf{k}}\left(1^{\ell }\right)$$

(1)

where E is an encryption function and the plaintext is an ℓ dimensional all-ones vector. The considered puzzle problem requires cryptographic inversion and we assume that the most efficient inversion is based on the time–memory trade-off approach. Consequently, for solving the consensus puzzle, two types of resources, energy and memory, should be employed.

A dedicated employment of this “resources two dimensional” consensus protocol in the pool mining scenario is proposed. The main underlying idea is to separate resources required for puzzle solving between the pool manager and the miners to provide resistance against certain attacks and to heavily reduce energy spending on the miners’ side without introducing an additional space overhead, which is moved to the pool manager as displayed in Figure 1.

The main underlying idea is to split execution of the puzzle-solving technique between miners and the pool manager, based on required resources of two-dimensional nature, so that neither the miner nor the pool manager could independently solve the consensus protocol puzzle. We assume the following: (i) The employed puzzle is such that it cannot be solved without employment of a certain amount of energy and involvement of certain memory; (ii) The mining pool energy is associated with the miners; (iii) The memory employed by the pool is associated with the pool manager.

The pool mining is organized as follows:

-

Miners perform computationally extensive iterative re-encryptions, and after each recalculation, send the result to the pool manager;

-

Pool manager performs a table look-up operation to check, as described in Appendix A, whether the current encryption outcome provides the puzzle solution.

An additional underlying idea is to employ direct sampled checking of the data a miner submits to the pool manager instead of employing a reduced puzzle problem to check honest participation in pool mining. We consider public blockchain pool mining where, in addition to honest miners, malicious miners could also be members of the pool. We assume that honest miners do not have, for the relevant protocol, memory resources, but we also admit that there are malicious miners that hide that have certain memory resources allocated for the tables relevant for solving the puzzle.

3.2. Architecture

Following the above underlying ideas, this section proposes the pool mining architecture by specifying:

-

Main architectural components;

-

Role of these components;

-

Architectural design.

3.2.1. Components

Recall that we consider public blockchain pool mining, so we consider the architecture where, in addition to honest miners, malicious miners could exist as well. Consequently, the main architectural elements are

-

Miners with computational power but without memory resources, called Miner Type A (honest miners);

-

Miners with computational power and memory resources, called Miner Type B (potentially malicious miners);

-

A pool manager with memory resources for collection of the tables: the tables are generated by the pool manager; the pool manager possesses computational power for the use of the collection of the tables.

3.2.2. Roles

Miners: We assume that both types of miners, Types A and B, perform iterative re-encryptions to generate candidates for the puzzle solution and to deserve the pool mining award. After recalculation, a miner puts the outcome into the buffer at the communications gate and continues with a new encryption round of iterative recalculation by using the current outcome as the new key for encryption of all-ones binary vectors as specified in the puzzle-solving algorithm. For the described activity, the miners receive pool awards assuming that they pass control of dedicated work. In addition, Miner Type B could perform the following malicious activity: In addition to submitting the outcomes of iterative re-evaluations to the pool manager, a Miner Type B could perform a check, employing its own table and the tables it can access, on whether the current candidate provides a solution for the puzzle to reach the block-mining award independently of the pool.

The Pool Manager: Organizes and operates pool mining, including acceptance of the miners to the pool. During processing, the main roles of the pool manager are the following: (i) To check if the current recalculation result exists in the second column of a table from the collection and to process the comparison outcomes; (ii) To perform a sampled correctness check of the miner’s data submitted as the recalculation outcome, which is a substitution for checking the honest work of a miner employing the reduced puzzle problem. A miner that passes the correctness check obtains the share reward for participation in pool mining.

3.2.3. Design

In the process of forming the pool of miners, pool managers register all miners involved in pool mining. During the registration phase a miner claims the dimension of the sub-table it will support (i.e., virtually rent) and receives information on the miner’s reward for pool mining participation. We assume that the reward of a miner depends on the computational resources associated with pool mining and the size of the rented memory part at the pool manager that the miner supports, but a detailed discussion of these issues is outside the scope of this paper.

The pool manager communicates with the miners employing the communications gate with a buffer for receiving the miners’ outcomes after each iterative re-encryption. Each miner submits the re-encryption outcome to the buffer, and the pool manager picks it up for further processing and deletes it from the buffer. The pool mining algorithm is described in the next section.

By design, the proposed pool mining approach provides the following two levels of security: (i) robustness against malicious miners that would like to launch block-withholding and selfish mining attacks against the pool; and (ii) Protection against malicious pool managers that could have the intention of hiding mining results from the pool members in order to reduce their rewards.

For further consideration, we employ the notation in

Table 1. Table of frequently used notation.

Notation	Definition
$\mathcal{V}=\{v_1,v_2,\dots ,v_N\}$	pool of N miners
${\mathcal{V}}_D$	sub-pool of dishonest miners
$q_i$	computing rate (power) of miner $v_i$, $i=1,2,\dots ,N$
PM	Pool Manager
$m_i$	i-th two-column table at PM, $i=1,2,\dots ,N$
$|m_i|$	number of rows in i-th table, $i=1,2,\dots ,N$
$t_i$	parameter of the puzzle-solving problem (time–memory trade-off parameter)
$\mathbf{b}$	binary vector equivalent of the basic block of transactions
$\mathbf{n}$	binary vector of the nonce
$\mathbf{p}$	public key of PM
$\mathbf{s}$	secret key of PM
$E_{(·)}(·)$	encryption employed in the puzzle
$\delta$	computing (energy) cost of encryption employed in the puzzle
$En{c}_{(·)}(·)$	encryption employed by PM
ℓ	parameter of encryption
$t^{\prime }$, ${\ell }^{″}$	parameter regarding the puzzle problem
$\Delta$	expected time slot for verification of a block
$F_{share}$	flag from PM that a share solution has been detected
$F_{solution}$	flag from PM that a solution of the puzzle has been detected
$F_A$	flag from PM that further mining of the considered block should be aborted

. The architectural framework is proposed in Figure 2.

3.3. Pool Mining Procedure

The pool manager (PM) communicates with each of the miners employing the same protocol. The main input of the protocol is a block that is the subject of verification generated by the PM. All the miners involved in the pool mining process the same block of data. The outputs of the protocol are the flags that inform a miner about outcomes of the performed mining activities. If a miner has provided the image of a puzzle solution and the PM finds the puzzle solution, the flags $F_{solution}$ and $F_{share}$ are raised. The flag $F_{share}$ is raised when PM detects that a miner has honestly performed the mining activities although the activities have not ended with the puzzle solution. The flag $F_A$ informs a miner to abort further processing of the considered block because somebody else has found the puzzle solution.

The interaction of a miner and pool manager during the puzzle-solving process is displayed in Figure 3.

Note that instead of the reduced puzzle problem for controlling the dedicated work of a miner, the proposed pool mining approach employs a sampled correctness check of the recursive evaluation: If the checked evaluations of a miner are correct, the PM grants a share as a reward for the miner’s work regarding the considered block processing.

Table 2. The mining procedure between a miner and pool manager.

1.	Input: block b, public key p, secret key s, and the parameters t, ${\mathit{t}}^{\prime }$, ${\mathit{\ell }}^{\prime }$, ℓ.
2.	Miner: Randomly selects the nonce vector $\mathbf{n}$
3.	Miner: Evaluate $\mathbf{c}=Prefi{x}_{\ell }\left(h\right(\left[\mathbf{b}\right|\left|\mathbf{n}\right]\left)\right)$ and ${\mathbf{c}}^{\left(0\right)}=\mathbf{c}$
4.	PM set the counter $j=0$.
	do $i=1,t$
5.	Miner and PM perform:
	- Miner: ${\mathbf{c}}^{\left(i\right)}=E_{{\mathbf{c}}^{(i-1)}}\left(1^{\ell }\right)$
	- Miner: ${\mathbf{c}}^{\left(enc\right)}=En{c}_{\mathbf{p}}\left({\mathbf{c}}^{\left(i\right)}\right)$
	- Miner: sends ${\mathbf{c}}^{\left(enc\right)}$ to PM for comparison of ${\mathbf{c}}^{\left(i\right)}$ with the second column elements of the tables
	- PM decrypts $En{c}_s^{-1}\left({\mathbf{c}}^{\left(enc\right)}\right)$ recovering ${\mathbf{c}}^{\left(i\right)}$, compares ${\mathbf{c}}^{\left(i\right)}$ with second column elements in all tables ${\mathbf{m}}_{(·)}$,
	and sends the flags to Miner as follows:
	- if $i>1$ with probability $\frac{\Delta }{t^{\prime }}$ decide to check check correctness of Miner’s work as follows:
	- if ${\mathbf{c}}^{\left(i\right)}=E_{{\mathbf{c}}^{(i-1)}}\left(1^{\ell }\right)$ set $j=j+1$,
	- if $j\ge {\ell }^{\prime }$ and $i=t$, output the flag $F_{share}$ and reset $j=0$
	- if ${\mathbf{c}}^{\left(i\right)}$ is equal to an element of the table second column, PM rises the flag $F_{solution}$ requesting
	Miner to submit n, and Miner submits $En{c}_{\mathbf{p}}\left(\mathbf{n}\right)$.
6.	If the flag is $F_{solution}$, PM performs the following: PM decrypts $\mathbf{n}$ by $En{c}_{\mathbf{s}}^{-1}\left(En{c}_{\mathbf{p}}\left(\mathbf{n}\right)\right)$ and evaluate $\mathbf{c}=Prefi{x}_{\ell }\left(h\right(\left[\mathbf{b}\right|\left|\mathbf{n}\right]\left)\right)$; Assuming that the above overlapping in the second column appears in the $k^{*}$-th row, PM sets ${\mathbf{x}}_0$ to value of the first element of the $k^{*}$-th row, and performs iterative re-evaluation ${\mathbf{x}}_k=E_{{\mathbf{x}}_{k-1}}\left(1^{\ell }\right)$, $k=1,2,\dots$, until the reevaluation result is equal to $\mathbf{c}$; PM recovers the puzzle solution as $x_{k-1}$ that yields $\mathbf{c}=E_{{\mathbf{x}}_{k-1}}\left(1^{\ell }\right)$; Go to the step 9: PM outputs the flags $F_{share}$ and $F_A$, and Miner aborts further processing of the block $\mathbf{b}$.
7.	If another Miner from the pool has submitted the solution go to the step 9: PM outputs flag $F_A$, in order to Miner aborts the processing of the current block $\mathbf{b}$.
	end do
8.	Go to step 2 & continue.
9.	Output: Flags from the set $\{F_{share},F_{solution},F_A\}$.

displays the proposed mining procedure. In particular, according to Table 1, note that within a time slot $\tau$, the computing power $q_i$ provides that the miner i could execute $q_i\tau /\delta$ encryptions.

3.4. A Comparison of Energy Consumption

In order to illustrate the reduction in the energy requirements of the pool when the proposed approach is employed in comparison with a traditional PoW, we point to the reports in [7], Section 6. Suppose that the consensus puzzle solution is a point in a space of $\mathcal{N}$ different hypotheses, and that both approaches have the same probability $\mathcal{P}$ of success for solving the corresponding puzzles. Moreover, we suppose that checking each hypothesis in both approaches has the same computational complexity so that it requires the same energy cost. We assume that during the proposed mining process all the miners submit to the pool manager in total D different candidates for a solution and that $D\mathcal{M}=\mathcal{P}\mathcal{N}$, where $\mathcal{M}$ is the total memory employed at the pool manager. Consequently, total computational complexity on the pool miner side is $O(\mathcal{PN}/\mathcal{M})$ which yields the total energy cost, as well, and the energy cost on the pool manager side is $\Delta$, noting that $\Delta <<O(PN/M)$. The illustrative comparison of the resources required for the pool mining employing the proposed approach and a traditional one with hash-based PoW is given in

Table 3. Comparison of the execution complexities assuming that the the expected probability of success is $\mathcal{P}$ and that the complexity of solving the puzzle is determined by $\mathcal{N}$, and $\mathcal{M}$, $\Delta$, are parameters such that $\mathcal{M}<<\mathcal{N}$, $\Delta <<O(\mathcal{PN}/\mathcal{M})$.

	Computational Complexity	Memory Required
traditional
PoW	$O(\mathcal{N}·\mathcal{P})$	$O\left(1\right)$
proposed approach	$O\left(\frac{\mathcal{N}}{\mathcal{M}}\mathcal{P}\right)$ + $\Delta$	$O\left(\mathcal{M}\right)$

.

According to the table, for example, when $\mathcal{M}=2^{30}$ the energy consumption is reduced about $2^{30}$ times in comparison with PoW requirement at the expense of employing a memory of dimension $O\left(2^{30}\right)$.

4. The Probabilities of Success

The resistance against block-withholding attacks and selfish mining depends on the probability that A malicious miner or a group of malicious miners could succeed in the attack in which the goal is solving the puzzle before PM. Consequently, we discuss the probabilities that the pool will win and that a sub-pool of malicious miners could win. Assuming that the parameters are appropriate, it is shown that the probability rate, which implies attack resistance, could be arbitrarily high.

Assumption A1.

Table dimension $|m_i|<<2^{\ell }$ and the parameter $t_i$ show that the repetitions that are consequence of the Birthday paradox do not appear in tables $m_i$, $i=1,2,\dots ,N$.

Lemma 1.

The time–memory-based inversion over the space of dimension $2^{\ell }$ within a time slot Δ, employing a table $\mathbf{m}$ with $t-1$ hidden columns, and the generation of the candidates for inversion based on the power rate q, assuming that required energy for generating a candidate is δ, has the following probability of success:

$$P{r}^{inv}=2^{-\ell }\frac{q\Delta }{\delta }\left|m\right|t.$$

(2)

Proof. 

Each row of the two-column table m is generated based on the following: (i) random selection of the first row element; (ii) iterative re-evaluation of the encryption t times; (iii) setting the second column as the value obtained after t re-evaluations performed in step (ii). Assuming that $\left|m\right|<<2^{\ell }$ and t is such that the repetitions that are a consequence of the Birthday Paradox will not appear, the table m implicitly contains the opportunity for $\left|m\right|t$ inversions. Accordingly, the inversion rate $\alpha$ is:

$$\alpha =2^{-\ell }\left|m\right|t,$$

Consequently, if $\nu$ different candidates are employed, the probability that at least one inversion appears is equal to $\alpha \nu$. When the computation rate is q, the time slot is $\Delta$ and the energy cost for generating a candidate is $\delta$, we have:

$$\nu =\frac{q\Delta }{\delta },$$

and combined with the previous equation, we have a proof of the lemma.    □

Proposition 1.

As a generalization of Lemma 1, we have the following. Assuming that all N pool miners submit correct data to the PM to receive the share-based reward, the probability $P{r}_{pool}^{win}$ that the pool will perform an inversion with the parameter ℓ within the time slot Δ is:

$$P{r}_{pool}^{win}=2^{-\ell }\frac{\Delta {\sum }_{i=1}^N{q}_i}{\delta }\sum _{i=1}^N\left|m_i\right|t_i.$$

(3)

Proof. 

During the $\Delta$ time slot, a miner $v_i$ provides the PM with $q_i/\delta$ candidates, $i=1,2,\dots ,N$. Accordingly, assuming that all miners honestly provide the candidates, the PM obtains a total of $\frac{\Delta {\sum }_{i=1}^N{q}_i}{\delta }$ candidates. Each candidate is subject to the inversion attempt by the PM employing a joint table that implicitly contains ${\sum }_{i=1}^N\left|m_i\right|t$ inversion pairs, implying that the probability of inversion for a candidate is $2^{-\ell }{\sum }_{i=1}^N\left|m_i\right|t$.    □

Proposition 2.

The probability $P{r}_{v_D}^{win}$ that the pool of dishonest miners will perform an inversion with the parameter ℓ within the time slot Δ is:

$$P{r}_{v_D}^{win}=2^{-\ell }\frac{\Delta {\sum }_{v_i\in v_D}{q}_i^{*}}{\delta }\sum _{v_i\in v_D}\left|m_i^{*}\right|t_i^{*},$$

(4)

where $q_i^{*},m_i^{*},t^{*}$ are the parameters of the resources employed by a dishonest miner $v_i\in v_D$ for malicious activities.   

Proof. 

As a generalization of Lemma 1, we have the following. Within the $\Delta$ time slot, a pool of dishonest miners is generated in a total of $\frac{\Delta {\sum }_{v_i\in v_D}{q}_i^{*}}{\delta }$ candidates. The pool of dishonest miners makes all the tables available for the inversion check of each candidate open to all malicious miners and a dishonest miner employs computation power $q_i^{*}$. Consequently, each candidate is subject to the inversion attempt employing the tables that implicitly contain ${\sum }_{v_i\in v_D}\left|m_i^{*}\right|t_i^{*}$ inversion pairs, implying that the probability of successful inversion of a candidate is $2^{-\ell }{\sum }_{v_i\in v_D}\left|m_i^{*}\right|t_i^{*}$.    □

Propositions 1 and 2 directly imply the following corollary.

Corollary 1.

$$\frac{P{r}_{v_D}^{win}}{P{r}_{pool}^{win}}=\frac{{\sum }_{v_i\in v_D}{q}_i^{*}{\sum }_{v_i\in v_D}\left|m_i^{*}\right|t_i^{*}}{{\sum }_{i=1}^N{q}_i{\sum }_{i=1}^N\left|m_i\right|t_i}$$

(5)

Assuming that the parameters are appropriate, Corollary 1 points out that the resistance of the pool against malicious miners could be arbitrarily high.

5. Implementation and Experimental Evaluation

This section provides a toy example implementation of the pool mining design proposed in Section 3 and illustrative experimental evaluation of the considered implementation. The implementation employs a modified Ethereum platform. The given experimental results show the feasibility of the proposal and illustrate the performances.

5.1. Implementation of the Proposed Pool Mining Employing a Modified Ethereum Platform

Architecture of the implemented pool mining is displayed in Figure 4.

Pool manager implementation consists of two interconnected components: Ethereum client and Pool Manager software (Figure 4). Ethereum client is used for maintaining the local blockchain copy, for communicating with the network and for creating blocks that are to be mined by the pool. The Pool Manager software is used for distributing the mining jobs to the miners, receiving values that the miners calculate, for looking for the values in the tables, and for completing the mined blocks. Ethereum client used in this implementation is modified Geth client [19], while the Pool Manager software is based on Open Ethereum Mining Pool [20].

The miners use a newly implemented software that performs needed calculations for the proposed consensus protocol.

5.1.1. Modified Ethereum Platform

Geth is the current up-to-date implementation of the Ethereum protocol written in the Go programming language. One of the principles of Ethereum is modularity, so Geth already has a certain predefined interface that consists of the following modules:

• The Author module returns the Ethereum address of the account that has mined the block with the given header. If the implemented consensus protocol is based on signatures (such as Etherium’s Clique protocol), this address can be differently compared to the address of the coinbase account, which represents the base account of every Ethereum node.
• The VerifyHeader module checks whether the header of the new mined block follows the rules of the consensus algorithm that is implemented. This module may check the validity of the crypto seal if the value of its parameter, seal, is set to true, which can also be done explicitly using the VerifySeal module. The module uses argument chain to read the content of the blockchain.
• The VerifyHeaders module is similar to that of VerifyHeader. The difference is that this module verifies a series of block headers using the chain reader as the VerifyHeader module does. The module returns two go channels as return values: the quit channel that serves to abort the operations of the module and the result channel that is used to asynchronously transfer the results of the verification, following the order of the blocks in the module’s argument list.
• The VerifyUncles module checks the validity of the uncles of the given block. Uncle blocks are blocks that were mined at the same time when the parent of the given block was mined, but have not made it into the blockchain. Those blocks must be valid, as Ethereum protocol stores them and gives some reward to the nodes that mined them. Uncle verification is done in the same way as the verification of other blocks that are part of the blockchain.
• The VerifySeal module verifies that the crypto seal of the given block is valid according to the rules of the implemented consensus protocol.
• The Prepare module is used to initialize the consensus fields of the block header according to the rules of the implemented consensus protocol.
• The Finalize module adds the final values to the block, for example, a reward for finding the block, after the crypto seal value has been added to the block. The result of this module is the block that will be added to the blockchain if the majority of nodes accept it.
• The Seal module generates a new block for a given input block with the local miner’s crypto seal, which depends on the block itself, placed on top of it. This is the main module of the consensus algorithm, as its core is the process of mining.
• The CalcDifficulty module returns the difficulty of the next block. This adjustment ensures that the time that passes until the new block is added to the blockchain stays always the same or as close as possible.
• The APIs module contains RPC API methods that are used by the Pool Manager software to communicate with the client. These methods are used for obtaining mining jobs and sending the newly mined blocks to the client.
• The Close module stops every background thread of the consensus protocol and ends it.

According to the above description, a modular decomposition of the Geth Ethereum client is proposed in Figure 5.

The workflow of Ethereum’s proof-of-work (PoW) algorithm mining procedure is shown in Figure 6, while the workflow of the verification procedure of the algorithm is shown in Figure 7.

Recall that the basic Ethereum employs the consensus protocol based on PoW, which operates within the set of modules denoted as “Consensus Modules” in Figure 5. The main goal is to make the modified Ethereum client employ an alternative consensus protocol that provides flexibility regarding the resources required to execute the protocol. Consequently, framework architecture of the modified Ethereum is proposed which is displayed in Figure 8: The modified Ethereum is obtained by substitution or modification of certain modules of the traditional Ethereum with those that provide flexibility of resources required for participation in the consensus protocol. The main modifications are performed regarding the following three issues: (i) the puzzle employed instead of PoW; (ii) setting the challenge for the puzzle problem and control of the puzzle solving process; (iii) the verification procedure.

According to the above, Figure 9 shows which of Ethereum’s consensus modules were modified compared to Ethereum’s PoW algorithm modules.

5.1.2. Modified Open Ethereum Mining Pool

As mentioned earlier, the Pool Manager software is based on Open Ethereum Mining Pool, and runs two threads called network communication thread and miner communication thread.

Network communication thread is used for communicating with the Ethereum client, and through it with the blockchain network. During the operation of the pool, this software periodically sends eth_getWork messages to the Ethereum client, requesting a new mining job. Once the valid response that contains the job is received, Pool Manager software first checks if the current mining job is the same as the one that was received. In cases where the pool has no current job, the mining job received from the client becomes the current job and is sent to the miners as per their request. It may happen, however, that the current mining job already exists, which leads to two possible cases. In the first case, the current mining job is the same as the one that was received, which means that the miners are already working on the up-to-date job, so the PM does not need to do anything. In the second case, the received job is different from the current one, which occurs when a new block is mined in the blockchain network. In that case, the Pool Manager software stores the newly received job, which becomes the new current job that will be distributed to the miners.

Miner communication thread is used for distributing mining jobs to the miners, and to perform task that are specific to the proposed consensus protocol. This thread expects messages from the miners, and once it receives them, it reacts appropriately, by creating a new thread for each message that will be processed. This thread expects three different types of messages:

• eth_getWork—this represents a miner’s request for the current mining job of the mining pool. Once the PM receives this request, he first checks if the particular miner is blacklisted due to malicious behavior. If a miner is blacklisted, the PM will ignore his message and do nothing. Otherwise, the PM will send a response to the miner that contains the current mining job, or a message informing the miner that there is no current job, depending on the situation.
• tmto_submitValue—this message is used by a miner to send a value that he calculated ($c^{\left(enc\right)}$) in order for the PM to search the tables. Once the PM receives this message, he reads the value that was sent and with a certain probability first checks the correctness of the miner’s work. If the work is found to be correct, the PM checks if the received value can be found in the second column of any of the tables. If the value is found, the PM informs the miner by using the $F_{solution}$ flag and requests the nonce value from the miner in order to complete the block and send it to the network.
• tmto_submitSolution—once a miner receives a request from the PM for the nonce value, he uses this message to send it. Upon receiving the nonce value, the PM uses it to find the puzzle solution in the appropriate table row. Once the solution is found, the block is completed and the PM software sends the block to the Ethereum client, where the validity of the block is once again checked, after which the block is broadcasted to the blockchain network.

5.1.3. Pool Miner Implementation

As mentioned above, the miners use a new mining software implemented using Go programming language. The software runs two parallel threads: communication thread and mining thread.

Communication thread is used to communicate with the PM regarding the mining jobs. This thread sends eth_getWork, which was described earlier, in order to obtain the current mining job. If no job is received, the thread will keep sending this message periodically until a job is received. Once a job is received from the PM, the miner must check if the received job is different from the job that the miner is currently working on. If it is, the miner starts working on the received job and abandons the previous one.

Mining thread is the main thread of the mining software that performs the actual mining work. Once a mining job is received by the miner, this thread first randomly selects a nonce value that is needed for the proposed consensus protocol. Afterwards, the miner starts working on the mining job as described in Table 2. When the miner calculates a new value, he uses the tmto_submitValue message to send the calculated value to the PM for processing. If the sent value is found in one of the tables located at the PM, the miner is notified and must send the nonce value he selected earlier to the PM so that the block can be completed. The miner uses a tmto_submitSolution message to send the nonce value to the PM, which effectively completes the mining process for the current mining job, as the PM will complete the block and broadcast it to the blockchain network.

5.2. Algorithms of Pool Mining

Pool mining is based on the following seven algorithms: Algorithms A1–A7. A summary description of these algorithms is given below, and the pseudo-codes of these algorithms are given in Appendix B. The algorithms are split into two groups: (i) preparation procedure algorithms, Algorithms A1–A3; (ii) mining procedure algorithms, Algorithms A4–A7.

Algorithm  A1. The Pool Manager initializes the time–memory table by initializing needed memory, followed by creation of different random numbers, one for the beginning of every row of the table. Once those numbers are created, subsequent elements of every row are calculated by applying the encoding function on the elements that precede them. Once all of the elements are found, only the first and the last column are stored in the TMTO table.

Algorithm A2. A miner sends a request to join the specific mining pool by selecting and sending dimensions of the table that will be ‘rented’ from the pool manager, along with its credentials and identification.

Algorithm A3. The pool manager first checks if the miner who sent the join request is blacklisted. If he is, he is not allowed to join the pool. Otherwise, the pool manager checks the resources for creation of the TMTO table. If he has enough resources, he initializes a table and appends the miner to the pool’s list of miners.

Algorithm A4. The pool manager initializes a new block that is going to be mined by writing various data to the newly created block. Those data include block number, hash of the block’s parent, hash of block’s uncles, and the block’s gas limit. The pool manager also selects and executes transactions from the transaction pool that will become part of the new block.

Algorithm A5. During the mining process, every miner first obtains the block for mining from the pool manager. Afterwards, the miner randomly selects a nonce value, writes it to the block, obtains the block’s hash value, and applies the $Prefi{x}_l$ function to that hash value. The received value represents the starting point for consecutive application of the $En{c}_p$ function. Every new value is obtained by applying this function to the previously obtained value, starting with the result of the $Prefi{x}_l$ function. Once the miner finds a new value, he sends it to the pool manager, who in return checks his TMTO tables for the value. Based on the manager’s response, the miner may abort the mining of the block (response is $F_A$), the miner may receive a share as his work was verified (response is $F_{share}$), and the miner may need to send a nonce value to the manager because the value he sent to the pool manager is the one needed to mine the block.

Algorithm A6. The pool manager receives a value from a miner and needs to check if that value is contained in one of his tables. First, however, he checks if the mining work on the current block should continue, as some other miners could have already found the block. If they did, current mining work must be discarded, and the pool manager informs the miner. Otherwise, the pool manager looks for the received value in his tables. If the value is found, the manager stores it to the location where the value was found and informs the miner that he found the solution and that he needs to send his nonce value to the manager. The pool manager may also check the correctness of the miner’s work with a certain probability. If the work is correct, the miner receives a share. If no value was found, the manager informs the miner to continue mining.

Algorithm A7. The pool manager receives the nonce from the miner that is needed to complete the block. The manager firsts finds the location that he stored when he located the value that was sent by the miner previously. The manager now has the required nonce and the location of the value, so he can reconstruct the mining solution by a number of consecutive applications on the encoding function. When the miner finds the solution, he completes the block and publishes it.

The above algorithms show the main procedures of the consensus protocol that is based on two different types of resources and at the same time provides: (i) increased resistance against certain attacks as a consequence of suitable separation of the resources (required for the consensus protocol execution) between the miners and PM; (ii) reduction in the total pool energy required for performing the consensus protocol at the expense of the involvement of certain memory resources. An experimental evaluation of the proposed pool mining approach is given in the next section and it shows the feasibility of the approach. In the considered setting, the PM creates a block that will be the subject of pool miners’ validation attempts and includes the validated block in the blockchain, employing the same approach as in traditional blockchain platforms like Ethereum.

5.3. Experimental Evaluation of Implemented Pool Mining

The experiments were conducted on a platform with an Ubuntu 20.04 operating system that has an Intel Core i7-10750H CPU @2.60 GHz with 12 cores. The goal of the experiment was to show that a malicious miner, who is also a member of the mining pool, will not be able to secretly mine a new block by having a table that he created in local memory and then publish it independently from the pool itself when it is suitable for him. For illustrative purposes, as encryption in the consensus puzzle, a well-known DES (Data Encryption Standard) block cipher is employed. The implemented consensus puzzle is displayed in Figure 10. Note that the DES has been employed only as a toy example for the puzzle problem that could be considered, because it was the subject of a time–memory trade-off-based cryptanalysis (see reference [21]). A number of other encryption techniques for which we believe that the time–memory trade-off, or the time–memory-data trade-off are the most efficient attacking approaches can be considered instead of DES. Additionally, we point out that the coding-based encryption schemes discussed in [22,23,24] could be considered as appropriate encryption schemes for the puzzle.

The following conditions were set for execution of the experiments. A private Ethereum network was deployed to measure times needed for mining new blocks. The network ran with only one mining entity active at the same time, which was either the mining pool or the malicious miner. The height of the mining pool table was 11,400,850,688, and its memory size was 17 GiB. The table that the malicious miner kept in secret was the $1/17$th part of the pool’s table. Its height was 67,108,864, while its size was 1 GiB. A malicious miner can have his own table that he keeps in secret, which can either be a part of the mining pool’s table, or a new table constructed by the malicious miner. During the experiment, the malicious miner used his own table that he constructed in secret. Another thing worth noting is that both the mining pool and the malicious user used the same computing power during mining, which represents the worst-case scenario for the mining pool and the best-case scenario for the malicious miner. However, in reality, this case is highly unlikely to occur, as the members of the mining pool will almost certainly have more cumulative computing power than one single member of the pool. Even if the malicious miner withholds his computing power and does not use it for regular mining in the pool, he just reduces the chance that the pool mines a new block, which in turn reduces the revenue that the pool’s members (including the malicious miner) receive. The difficulty parameter of the mining protocol had the same value throughout the experiment, which ensured that the results received for the mining pool and malicious miner were comparable. Both the mining pool and the malicious miner had the same amount of time (56 h) for mining.

Table 4. Experimental results for the mining pool showing experiment parameters, minimum, maximum, average, and median of times, in seconds, needed to mine new blocks.

Mining Pool
Table height	11,400,850,688
Table width	100
Memory size	17 GiB
Number of mined blocks	509
Minimum mining time	0.70919 s
Maximum mining time	2435.46075 s
Average mining time	393.14522 s
Median of mining times	290.51234 s

shows the experimental results for the mining pool obtained after 56 h of mining. During that time, the mining pool mined 509 new blocks, with the average time needed to find a new block being approximately 393 s. However, the median of times needed for mining a new block was significantly shorter, approximately 290 s, as there were few blocks that required much more time for mining. This can be easily seen from Figure 11, which shows the distribution of blocks per time needed to mine them.

The histogram shows that more than half of the mined blocks (264 blocks) were mined for 5 min or less, whereas only 48 blocks required more than 15 min to be mined, from which 24 needed more than 20 min.

Table 5. Experimental results for the malicious miner that is part of the mining pool showing experiment parameters, minimum, maximum, average and median of times, in seconds, needed to mine new blocks.

Malicious Miner
Table height	67,108,864
Table width	100
Memory size	1 GiB
Number of mined blocks	27
Minimum mining time	168.55772 s
Maximum mining time	31191.216 s
Average mining time	5355.43111 s
Median of mining times	3175.074 s

shows the experimental results for the malicious miner obtained after 56 h of mining with the same computing power as the whole mining pool. The first result that is drastically different is the number of blocks mined by the malicious miner, which is only 27. The rest of the results show that the minimum mining time spent finding a block was approximately 168 s, while the average time was approximately 5355 s (close to 1.5 h). It is clear that the malicious miner needed much more mining time to create new blocks than the mining pool. Figure 12 shows the distribution of blocks per time needed to mine them.

Overall, the results clearly show that even if the malicious miner had the same computing power as the whole mining pool, he would still mine drastically fewer nodes in the same time. Moreover, the maximum mining time for a block by the mining pool is much shorter than the average mining time for a block by the malicious miner. This means that it would be practically impossible for the malicious miner to find a new block and keep it for himself to publish when he finds it suitable.

6. Conclusions

This paper proposed a pool mining approach that provides (i) high resistance against block-withholding attacks and selfish mining; (ii) reduction in the energy required by the system in comparison with PoW-based systems, at the expense of employment certain memory. A novel paradigm for the organization of pool mining was shown based on the consensus protocol, which has a two-dimensional nature concerning the resources required for the puzzle solving: The puzzle solving requires employment of energy and space resources. This two-dimensional nature enables splitting of the resources required between the miners and the pool manager so that energy spending is at the side of the miners and the pool manager provides required memory resources. Consequently, assuming appropriate selection of the puzzle hardness, the probability that the miners could solve the puzzle without the support of the pool manager can be arbitrarily small. This directly implies that the proposed approach provides high resistance against block-withholding attack and selfish mining because they are almost not feasible. Nevertheless, because the puzzle solving is based on a trade-off between required energy and space, energy spending at the miners side is heavily reduced in comparison with the requirement of employment traditional PoW-based consensus protocols. An implementation framework is shown based on employment of a modified Ethereum platform where the PoW consensus protocol is replaced with one instance of the consensus protocol reported in [7]. The given experimental results show the feasibility of the proposal and illustrate the performances. Presenting the performance comparison of the proposed pool mining approach with the previously reported ones in detail is an issue of the planned future work.