Blockchain Mining: Understanding Its Difficulty in Terms of Hashing Algorithm Efficiency

Abstract

This study systematically evaluates the performance of the hashing algorithms SHA-2 and SHA-3 (in both 256-bit and 512-bit variants), as well as MD5, in generating and verifying a thousand-block chain to understand the computational costs associated with blockchain mining. Java-specific source code was developed to simulate key aspects of a blockchain back-end environment, focusing on block creation and validation. The five distinct hashing algorithm configurations were tested at varying levels of complexity, with performance measured by the duration of each test. The study reveals that SHA-3, despite producing stronger hash values, is slower than MD5 and SHA-2. An optimal balance between security and calculation time was achieved at a four-character complexity level. While higher complexity levels enhance security, they significantly reduce performance, deeming them suitable for systems with lower data processing needs. These findings can guide small and medium-sized businesses in understanding the computational costs of employing blockchain technologies.

1. Introduction

Blockchain technology, transcending its initial role in cryptocurrencies, is now emerging as a versatile agent of change in the modern digital age. Its decentralized, transparent, and immutable characteristics are expected to significantly influence numerous sectors. For instance, blockchain technology has been proposed to be implemented in African nations to increase voter trust and reduce electoral violence [1]. Other possible applications are: facilitating data exchange, medication administration, biomedical research, remote patient monitoring, health data analytics, and log management [2]. Furthermore, recent studies highlight that smart contracts, based on blockchain programming interfaces, have the potential to transform several established industries, including healthcare, energy, and banking [3].

The present study examines the computational requirements imposed on blockchain systems by extensive mining activities while also providing important insights to alleviate their respective workloads. It thoroughly evaluates the algorithms of Message-Digest version 5 (MD5), as well as Secure Hash Algorithm versions 2 (SHA-2) and 3 (SHA-3), in both their 256-bit and 512-bit forms. The focus is on assessing the effectiveness of these algorithms in generating and validating blockchains. The primary goal of this research is to achieve a balance between hash strength, which directly impacts system security, and computing time, which significantly affects overall performance.

2. Theoretical framework

The core of the blockchain mining process is the calculation of the hash value for each block, but this requires significant computational power and direct and indirect costs of these technologies. The complexity of designing a balanced solution has led to the development of a number of specialized technologies, such as a proposed decentralized agent-oriented modeling (DAOM) framework [4] for designing and developing blockchain-decentralized applications to facilitate secure and efficient interorganizational collaborations. Additionally, there are proposals for the implementation of Bloom filters on GPUs, utilizing special frameworks to enhance hashing performance [5]. However, utilizing trustworthy digest algorithms to calculate hash values is fundamental for maintaining the integrity of the network, its security and efficiency. In this context, the National Institute of Standards and Technology (NIST) of the USA recommends the SHA hashing algorithms, including the SHA-2 family and SHA-3 in their 224, 256, 384, and 512-bit modalities [6]. These algorithms have been subjected to extensive scrutiny and cryptographic analysis, validating their security for a variety of applications. The previous SHA-1 algorithm was deemed insufficient and was removed from the Secure Hash Standard in March 2023 [6].

The Java programming language, known for its platform independence, robustness, and extensive ecosystem, is widely used to develop and test blockchain-related algorithms. Numerous blockchain platforms, frameworks, and libraries, such as Ethereum, Hyperledger Fabric, and Corda, provide Java SDKs and automation support for creating blockchain back-end applications [7]. Regarding the hashing process, the MessageDigest class from the java.security library supports various algorithms, including MD5, which is based on the RFC 1321 standard [8]. The information to be hashed with this algorithm is initially padded so that its length conforms to a 448 modulus of 512. Padding consists of appending a single ‘1’ bit, followed by ‘0’ bits, until the desired length is reached. A 64-bit representation of the original message length is subsequently appended. If the length is greater than 264 bits, only the lowest 64 bits are considered. The resulting 512-bit message is split into 32-bit words. A four-word buffer (A, B, C, and D) is initialized with specific hexadecimal values to compute the message digest. Subsequent cycles of transformations on the buffer and message words generate the final message digest. Despite MD5 being considered as insecure in recent years [9], its high performance in blockchain mining continues to attract interest, as evidenced by [10].

SHA-2 is implemented in Java in compliance with the standard outlined in [6]. According to the official documentation of the programming language [11], there are two primary configurations: 256-bit and 512-bit, and all other possible bit lengths are just variations of these. Both configurations consist of the text being split into eight 32-bit words. To prepare these strings for processing, a single ‘1’ bit is appended, followed by ‘k’ zero bits. The value of ‘k’ is chosen so that the entire length of the message is a multiple of 512 bits minus 64. Then, a 64-bit block representing the original binary length is appended. The then-padded message is parsed into multiple 512-bit segments. Each block is subdivided into 32-bit words (for SHA-256) or 64-bit words (for SHA-512), depending on the algorithm. Then, a main loop is executed on each word performing calculations with constants, rotations, and shifts of quantities. The entire procedure returns the final hash value.

SHA-3 is a family of cryptographic hash functions derived from the Keccak algorithm [12], which utilizes mathematical permutations on the width of the strings. The number of internal transformation iterations, or rounds, allow transformations on a state array of bits. This process enables the conversion of binary strings into state arrays and vice versa, following certain predefined rules. In addition, SHA-3 uses a framework known as Sponge construction, which uses a function on fixed-length strings, a rate parameter, and a padding rule in order to processes a series of input blocks and then integrate them with the internal state of the hash function through XOR operations. This design makes SHA-3 a robust and versatile cryptographic instrument.

In a comparative analysis of various cryptographic algorithms, Gupta et al. [13] stated that while MD5 offers speed due to its relatively simpler calculations, it falls short in providing robust security against collision attacks. Collision resistance is a characteristic of cryptographic hash functions that makes it extremely difficult to find two different inputs that result in the same output. MD5 is considered less collision resistant than the SHA family because of vulnerabilities that make it easier to find two distinct inputs that produce the same hash value [14]. This vulnerability compromises the security of systems that depend on MD5 for data integrity or authentication. SHA-2 and SHA-3 are meant to provide much stronger collision resistance, making them better suited for protecting digital data and communications across various applications [15].

SHA-2, specifically its 256- and 512-bit variants, demonstrated significant resistance against cryptographic attacks [16] because of its more complex hash calculations. However, the enhanced security offered by SHA-2 comes at the cost of computational speed, especially when dealing with large datasets. Similarly, Chandran and Manuel [17] noted that SHA-3, the successor to SHA-2, provides even stronger security features but with increased demands on computational efficiency. Despite this limitation, the authors emphasized the resistance of SHA-3 to known cryptographic vulnerabilities, making it a preferable choice for applications requiring high-security measures. However, these findings contrast with those of Sailaja and Vucha [18], who indicated that the performance and security of hashing algorithms depend mostly on the nature and volume of the data being processed. In the latter study, SHA-3 was found to be more efficient than SHA-2 for smaller datasets, while SHA-2 outperformed SHA-3 with larger data volumes. For similar reasons, Quist-Aphetsi and Blankson [19] proposed a hybrid approach, suggesting the combined use of MD5 and SHA-2 of 256 bit for a balance between security and computational efficiency, mitigating the vulnerabilities associated with MD5 and the performance drawbacks of SHA-2.

The choice between these hashing algorithms should therefore hinge on the specific needs of the application regarding security and performance.

Table 1 scrutinizes 10 recent studies, each delivering insights into the efficacy of hashing algorithms within the realm of blockchain mining. Despite the consistent approach to hashing algorithms, their computational costs, and their impact on blockchain mining across these studies, the current research distinguishes itself by specifically concentrating on the exhaustive evaluation of the MD5, SHA-2, and SHA-3 algorithms in the particular context of blockchain mining, utilizing the Java programming language as a back-end software platform. This refocusing of the surveyed studies is highlighted to underscore the relevance of the present research.

Year, study	Approach	Comparative analysis with present article
2023, [20]	Using the Modified Merkle Hash Tree algorithm as a foundation, this study investigated a framework for identity management in decentralized IoT blockchain networks. Multiple encryption techniques and hash functions were included, such as RIPEMD, Whirlpool, Tiger, Gost, Shake, SHA1, and SHA2 in 256, 384, and 512 bits. The study indicated that a combination of the SHA3 function and AES-128 encryption reduced execution time by 36% compared to other combinations in regards of identity threat protection and network protection.	The study does not specify the software platform used for conducting the test, thereby eliminating the possibility of reproducibility. Moreover, the performance results are obtained by first encrypting each block and then calculating the hash value using a cross-combination of algorithms instead of directly evaluating the mining process efficiency itself.
2022, [21]	Given the vulnerabilities of blockchain systems to quantum attacks, the study explored the performance of various post-quantum signature algorithms, such as the ECDSA, Dilithium, and Falcon, in a blockchain environment. The study identified that the main weakness is related more to the large sizes of the keys than to the signatures produced by cryptographic methods.	Post-quantum algorithms and hashing algorithms are distinct in purpose and design. Post-quantum algorithms are designed to secure information against the potential capabilities of quantum computers, which are not yet commonly used in current blockchain applications.
2022, [22]	This article introduces ALDER, a method developed to augment the efficiency of blockchain systems by utilizing multiplexed execution of the consensus protocol. It enacts a two-phase strategy: a reduction phase that utilizes a voting mechanism to achieve consensus on a specific block hash and a binary Byzantine agreement phase that finalizes consensus anchored on hash values. Alongside these phases, ALDER integrates cryptographic hashing into the construction of macroblocks, thereby enhancing throughput and reducing latency.	Although the ALDER method uses cryptographic hashing to construct macroblocks, it does not evaluate the relative efficacy compared to other available hashing algorithms.
2022, [23]	The article contrasted the performance of SHA-256 and BLAKE2b in a Proof of Work (PoW) architecture, specifically in a Bitcoin-like mining scenario. It addressed the need for efficient hash algorithms in blockchain applications, considering power consumption and environmental concerns. The results indicated that BLAKE2b was faster for single plaintext hashing, while SHA-256 outperformed in PoW architectures.	The article focused solely on two hashing algorithms: SHA-2 in 256-bit mode and BLAKE2b. Additionally, Python was used for developing the blockchain framework, as it possesses several commendable characteristics. However, this language is frequently outperformed by Java in large-scale back-end operations.
2022, [24]	It offers performance indicators, trade-offs, trends, drawbacks, and proposed solutions for blockchain consensus algorithms in decentralized architectures. The study assesses performance metrics, including fairness for smaller clients, and discusses the potential influence of quantum computation on blockchain technology.	An algorithm was developed for evaluating SHA-2 in 256-bit mode, taking precedence over other potentially more efficient algorithms. The findings are presented predominantly through qualitative assessments rather than quantitative measurements.
2021, [25]	Using queuing models, this study analyzes Bitcoin’s transaction confirmation time, revealing a non-work conserving mechanism that may exclude lower-fee transactions. It also specifies a nonhomogeneous Poisson process as an appropriate model for simulating block generation, providing accurate estimates for transaction confirmation time, particularly for larger block sizes.	The study used one single hashing technique. The performance analysis of the blockchain is primarily based on the implementation of independent Bernoulli trials for hashing calculations, recommending the creation of mini pools consisting of multiple nodes for enhanced performance.
2020, [26]	The study systematically evaluates blockchain efficacy using theoretical analysis, a literature review, and performance experiments using frameworks such as Blockbench, DAGbench, and Hyperledger Caliper. It also tested the performance of several Distributed Layer Technologies (DLTs), such as HLF, Ethereum Geth, Parity, and Quorum, among others. The survey identifies bottlenecks of those technologies and outlines future directions for blockchain system optimization research.	This study is comprehensive and offers significant comparisons among various Blockchain frameworks and DLTs. However, it lacks quantitative evidence about blockchain mining performance.
2019, [27]	This study assesses the efficacy of hash calculation in the Parity and Multichain blockchain frameworks by evaluating transaction validation time, transaction mining time, transaction-seek time, and block-seek time. The results indicate that Multichain outperformed Parity in the evaluated metrics. However, it should be noted that Multichain only supports transactions for asset exchange between pairs. On the other hand, Parity requires more time for computations but offers support for complex transactions, including the execution of smart contracts.	The study presented results on transaction-mining time for the evaluated frameworks and explored the efficiency of storing and retrieving blocks from the blockchain. However, it did not provide specific details about the mining strategy employed or the efficiency of the hashing algorithms used in the frameworks.
2018, [28]	The study examines the use of a blockchain proof-of-work mechanism and SHA3-256 cryptographic hashing to enhance the security of mobile commerce. This paper demonstrates how these blockchain techniques can be adapted for mobile platforms, providing effective security solutions for future m-commerce.	It is not specified which programming platforms were used to develop the described blockchain framework, limiting the insight into technology performance. Only the performance of SHA3-256 was evaluated.
2016, [29]	This study presents a new framework for quantitatively analyzing security and performance in proof-of-work blockchains, considering real-world factors. The framework enabled optimal comparison of performance and security trade-offs in various blockchain scenarios, including configuration of the block size, generation intervals, and propagation mechanisms.	The security evaluation of the software was based solely on Markov Decision Processes (MDP). The results focused on measuring the mining power of hypothetical adversaries to analyze competition in “selfish mining” techniques, rather than evaluating the computational performance of various ciphering algorithms

Table 1.

Comparative analysis of the literature on blockchain mining performance.

The balance between security and performance in blockchain technology was based on the technical methods used to maintain network integrity and operational effectiveness. Pillai et al. [30] were investigated regarding the trade-offs related to blockchain interoperability, where the aim of smooth transactions between various blockchain systems might lead to increased complexity that could compromise security and performance; therefore, a modular approach to interoperability was suggested, utilizing dedicated protocols to fulfill security and performance needs for secure and efficient cross-chain interactions, without overly burdening the participating blockchains. Also, Gervais et al. [31] offered a technical examination of how Proof of Work (PoW) techniques, which aim to protect blockchain by demanding computationally difficult tasks for block validation, naturally restricted transaction throughput and raised latency. To address this trade-off, they proposed using other consensus mechanisms like Proof of Stake (PoS) or hybrid models that combine different consensus techniques to enhance both security and performance while reducing computational complexity. In a more recent trend, Dinh and Thai [32] indicated that AI enhanced blockchain by optimizing decision-making across security, performance, and governance. It automated parameter adjustments for improved efficiency and introduced advanced mechanisms for data confidentiality. Machine learning algorithms within blockchain could detect and neutralize threats, ensuring component isolation during attacks. These measures could contribute to enhancing security and reducing the computational costs of hashing.

3. Methodology

In this study, a systematic approach was adopted to evaluate the performance of MD5, SHA-2, and SHA-3 (the two latter in 256-bit and 512-bit variants) in the generation and verification of a thousand-block chain. The testing environment utilized Ubuntu Linux version 22.04 as a virtual machine [33], equipped with a 1.8 GHz processor and 4 GB of RAM. The software was developed using Java Development Kit (JDK) version 18 and served both as a blockchain framework and a testing application, providing a controlled environment for comparing the performance of the hashing algorithms. The framework simulated basic aspects of a blockchain network, such as block creation, transaction processing, and blockchain validation, ensuring repeatable and consistent performance measurements and serializable network transmission capabilities [34]. A procedure was used to generate and populate the blocks [35], filled with hypothetical monetary transactions. The configurations of each hashing algorithm were tested four times at six different levels of complexity: from one to six characters used in the hash value as proof-of-work. Therefore, in this study, the mining process executed to verify a hash value with a substring of two zeros (‘00’) was named Complexity Level #2, or simply “C-2,” and so on. The highest level of complexity evaluated, consisting of six zeros (‘000000’), was named “C-6”.

The performance was determined based on the duration of each test, which was recorded in seconds [36] by the same software that conducted the tests. After the mining process, blockchain validation consisted of a routine that recalculated each block hash and verified the integrity of the nonce values and precedent hash in the chain, also recording performance data such as time, CPU, and memory load. While Linux memory caching and sharing subsystems can distort actual usage, ‘meminfo’ command provided a general load estimate.

After conducting the tests, an inflection point in mining complexity was identified, where increased nonce calculation iterations began to significantly extend computational time, thereby negatively impacting performance. This point marked a threshold beyond which further increases in complexity no longer yielded proportional security benefits, as the additional security gains did not justify the heightened calculation time. This criterion was used to determine the most appropriate level of complexity for practical applications in regular real-life organizations.

4. Development of testing software

In the developed source code, each block represented a class instance with six attributes and a non-limited list for storing transaction objects. Only the most basic information was included in the declaration of the Block and Transaction classes to reduce the possibility of creating unnecessary bottlenecks while calculating the hashes in order to focus mostly on the performance of the algorithms. The pseudocode is as follows:

Class Block

Declare integer id

Declare integer nonce

Declare long timeStamp

Declare string hash

Declare string previousHash

Declare List of Transaction objects, named lTransactions

EndClass

Class Transaction

Declare integer id

Declare long timeStamp

Declare string sender

Declare string receiver

Declare double amount

EndClass

The BlockChain class was designed to manage the blockchain’s business logic, holding all blocks in a dynamically allocated structure. Upon initialization as BCManager, the class required inputs for the mining complexity level, a character for the proof of work, and the hashing algorithm’s name. The genesis block was created initially, and the number of iterations (nonces) needed to meet the complexity requirements was recorded. For demonstration, a loop was executed to create and add a predetermined number of blocks, each with a sample transaction. After mining each block, the cumulative number of iterations required was updated, serving as a key metric for evaluating the hashing algorithm’s efficiency. The Java code was:

this.BCManager = new BlockChain(pComplexity, "0", pHashingAlgName);

this.BCManager.createGenesis();

this.iterationCount=this.BCManager.getBlock(0).getNonce();

for(int i=0; i<RequestedBlocks; i++)

{

BCManager.createBlock();

BCManager.getLastBlock().setTransaction(“Wallet_ID_1”, 100.8,"Wallet_ID_2");

this.iterationCount +=BCManager .mineBlock();

}

The BCManager class contained a function called createBlock that was responsible for appending a new block to the blockchain. The method entailed obtaining the hash of the most recent block in the blockchain to serve as the previous hash for the new block. Subsequently, the new block was initialized with its index set to the current size of the blockchain and its prior hash set to that of the last block. In the Block class, a method named setTransaction was created to add a new transaction to a block at the same time. The method utilized the sender’s identity, transaction amount, and receiver’s identity as inputs to generate a new transaction object. This object included the aforementioned details and an index based on the current number of transactions in the block. Subsequently, the transaction was appended to the block’s transaction list. The hashing process was executed inside of BCManager.mineBlock(), so the last block was mined. The method made use of the plain String version of every block, generated by the toString() method. Then, using a MessageDigest object configured with the provided parametrized hash method, the String was converted into a byte array. This conversion was done according to a specific encryption method. The byte array was then converted into a readable hexadecimal string, as presented in the following Java code snippet:

MessageDigest digest =

MessageDigest.getInstance(hashMethod.toString());

byte[] hash = digest.digest(Block.toString().getBytes("UTF-8"));

StringBuffer hexadecimalString = new StringBuffer();

for (int i = 0; i < hash.length; i++)

{

String hexadecimal = Integer.toHexString(0xff & hash[i]);

if (hexadecimal.length()==1) hexadecimalString.append('0');

hexadecimalString.append(hexadecimal);

}

return hexadecimalString.toString();

The mining method was coded inside BCManager, and no business logic was provided within the block objects. The method created a hash value from the plaintext, composed of the String representation of each attribute in a block, plus a nonce, until achieving the desired proof of work, as specified in PoW_String. The complexity level was indicated by the variable complexity_Str. The blockchain management object, BCManager, provided access to the last block available for mining. It also recorded the nonce and calculated hash in a manner consistent with the fundamental rules of blockchain. The code is presented below:

String str= BCManager.getLastBlock().toString();

int nonce=0;

String sHash="";

while(true)

{

sHash=this.generateHash(str+Integer.toString(nonce));

if (sHash.subSequence(0, complexity_Str).equals(PoW_String))

{

BCManager.getLastBlock().register(nonce, sHash);

break;

}

nonce++;

}

return nonce;

After block generation, a validation procedure was performed on each mined block to confirm the integrity of the blockchain. This procedure was also part of the managing class and involved the recalculation of every hash using the previously stored nonce and then comparing against the stored hash. If both hashes matched, the proof of work was considered valid; if not, the blockchain was deemed compromised. The code snippet is presented below. The full source code is available in the repository [37].

String sHash= BCManager.generateHash(Block.toString()+

Block.getNonceString());

return sHash.equals(BCManager.getBlock(blockID).getHash());

5. Results and discussion

Each algorithm configuration produced different lengths of hashes, as shown in Table 2. MD5 created the smallest hashes, which were also the easiest to calculate in terms of computational resources. Hashing algorithms operating in the 256-bit modality returned hashes of 64 bytes, while those in the 512-bit mode returned hashes of 128 bytes. Both SHA2 and SHA3 in 512-bit mode showed more security potential, as they were more computationally challenging.

Hashing method	Resulting length (Bytes)
MD5	32
SHA2-256 bits	64
SHA2-512 bits	128
SHA3-256 bits	64
SHA3-512 bits	128

Table 2.

Byte length of the calculated hash values.

Table 3 illustrates the maximum average random access memory (RAM) used during the creation of the test blockchain. With increasing complexity, RAM usage also increased. Notably, “C-5” and “C-6” levels required extensive resources, implying substantial computational costs for real-life applications. Such expenses could be justified only in high-revenue businesses that prioritize extreme security demands over cost.

Complexity level	RAM peak (mega bytes)
C-2	21.9
C-3	52.3
C-4	251.9
C-5	538.7
C-6	1474.56

Table 3.

Maximum memory usage while mining.

Figure 1 illustrates the exponential memory usage increase with rising complexity levels. These results suggest that enhancing server RAM capacity becomes necessary when hardening the proof-of-work method for security purposes. After generating the test blockchain, a separate revalidation was performed, which involved recreating the hash of every block using its converted plain String and nonce value. This process was significantly lighter than the intensive mining required for new blocks during the initial blockchain construction. Figure 2 reveals that verification times for complexity levels C-2 through C-5 are relatively consistent but markedly increases for C-6 across all algorithms. In a real-world implementation, enhancing the CPU and RAM of a multicore server, together with utilizing Java’s concurrency utilities such as the Fork/Join framework and the Executor framework, greatly improves blockchain efficiency and security. These Java solutions utilize multicore processors to accelerate the blockchain mining process and data management chores, hence decreasing the time required to solve cryptographic challenges. Upgraded RAM guarantees efficient processing of extensive datasets and intricate procedures. These enhancements utilize the capabilities of Java for parallel processing capabilities to speed up the performance of complex proof-of-work tasks, thus improving speed and scalability efficiently.

Figure 1.

Peak memory usage during processing for each complexity level.

Figure 2.

Proof of work (PoW) calculation time for each complexity level.

While generating the test blockchain, the process with C-2 proved to be the fastest, and therefore the least secure, needing about 250,000 iterations and up to 5 ms of processing for each block (Table 4). The process with C-3 required approximately 4 million iterations, with block mining times ranging from 13 to 52 ms (Table 5), offering improved security. For C-4, over 60 million iterations were necessary, resulting in mining times from 183 to 838 ms per block (Table 6). With C-5, security further improved, requiring nearly a billion iterations for the test and mining times from 2.5 to 17.5 seconds per block. In the case of SHA3-256 (Table 7), the most secure encryption method tested, generating a thousand-block test took more than 4 hours. However, it is notable that the mining times varied significantly depending on the hashing method used. Lastly, for C-6 (Table 8), the tests were considerably more time-consuming, requiring more than 10 billion iterations and several minutes per block. Specifically, the time to generate a single block ranged from 2.5 seconds using MD5 to 175 seconds using SHA3-512. Consequently, the creation of a thousand blocks under C-6 complexity varied significantly depending on the hashing algorithm: for MD5, it took approximately 42 minutes, while for SHA3-512, it extended to over 48 hours, demonstrating a substantial increase in both time and computational effort.

Method	Iterations	PoW (ms)	Mining time per block (ms)
MD5	259,060	17	2
SHA2-256	235,921	13	3
SHA2-512	254,267	13	3
SHA3-256	242,535	14	3
SHA3-512	263,058	20	5

Table 4.

Mining test results, using complexity level of 2 characters (C-2).

Method	Iterations	PoW (ms)	Mining time per block (ms)
MD5	4,242,809	13	13
SHA2-256	4,163,061	17	30
SHA2-512	4,217,957	16	26
SHA3-256	3,979,857	14	32
SHA3-512	4,081,028	21	52

Table 5.

Mining test results, using complexity level of 3 characters (C-3).

Method	Iterations	PoW (ms)	Mining time per block (ms)
MD5	67,948,703	12	183
SHA2-256	65,845,949	16	443
SHA2-512	67,982,908	12	347
SHA3-256	65,054,242	14	476
SHA3-512	66,335,940	21	838

Table 6.

Mining test results, using complexity level of 4 characters (C-4).

Method	Iterations	PoW (ms)	Mining time per block (ms)
MD5	995,404,013	10	2456
SHA2-256	1,019,771,696	13	5673
SHA2-512	1,033,485,474	13	5931
SHA3-256	1,012,483,152	17	9711
SHA3-512	1,055,056,190	28	17,480

Table 7.

Mining test results, using complexity level of 5 characters (C-5).

Method	Iterations	PoW (ms)	Mining time per block (ms)
MD5	12,329,239,600	124	36,154
SHA2-256	13,764,806,500	175	90,388
SHA2-512	11,346,805,800	143	66,695
SHA3-256	15,032,843,700	252	137,983
SHA3-512	14,349,920,600	381	248,370

Table 8.

Mining test results, using complexity level of 6 characters (C-6).

Figure 3 depicts the average elapsed time for processing various complexity levels using five different methods. The simplest level, C-2, showed the shortest processing time, while C-6 had the longest, indicating an exponential increase in processing load with each additional character in the proof of work. MD5, the simplest algorithm, was notably faster at C-5. In contrast, the more robust SHA3-256 required significantly more resources, especially from C-5 onward. SHA2-256 maintained similar efficiency up to C-4, compared to SHA2-512 and SHA3-256, while SHA3-512 was only slightly slower. When considering the cost of complexity, measured by the average number of iterations needed for a new block, MD5 and SHA2-256 were the most efficient at C-5. However, SHA-512, SHA3-256, and SHA3-512 showed peak efficiency at C-4. Despite MD5 and SHA2–256’s higher efficiency at more complex levels, C-5 demanded substantially more iterations than C-4, suggesting that C-4 is a more optimal balance of security and resource use.

Figure 3.

Block mining time versus level of complexity (in logarithmic scale).

Validation of the test blockchain was achieved by executing a new proof of work to recalculate the hash of every block in a single process. Results depicted in Figure 4 revealed that MD5, SHA2-256, SHA2-512, and SHA3-256 performed similarly, with low validation costs for C-2, C-3, and C-4. However, C-5 and especially C-6 had high computation costs and were much slower, affirming C-4 as the most cost-effective option. In the case of MD5, the time duration for C-5 was 833.3 times longer than for C-4, and for C-6, it was 12.4 times longer than C-5. This suggests that the most substantial inflection point is reached starting from C-5. Similarly, for SHA2-256, the duration for C-5 was 812.5 times longer than for C-4, and for C-6, it was 13.5 times longer than C-5. In the case of SHA2-512, the increase was even more pronounced: C-5 took 1083.3 times longer than C-4, and C-6 took 11.0 times longer than C-5. The pattern for SHA3-256 was comparable, with C-5 taking 1214.3 times longer than C-4 and C-6 taking 14.8 times longer than C-5. For SHA3-512, the increase was the most significant: C-5 took 1333.3 times longer than C-4, and C-6 took 13.6 times longer than C-5.

Figure 4.

Elapsed time of Proof of Work (PoW) versus level of complexity in the test blockchain (in logarithmic scale).

Given that the mining process consists of finding a specific hash value through repetitive iterations, the average number of iterations for each algorithm was calculated against each level of complexity. The results of this respective test, illustrated in Table 9, show that MD5, which produces the shortest byte length in hash values, executed more iterations for hash calculations per second. This suggests that while MD5 is less secure, it is the fastest in terms of operations per second. At complexity level C-4, SHA2-256 and SHA3-256 yielded a similar number of iterations per second; however, SHA3-256 demonstrated a reduction in operation count starting from C-5. In comparison, at C-5, SHA2-512 generated approximately 2.5 times more iterations. This study offers a novel perspective on the comparative performance of MD5, SHA-2, and SHA-3 hashing algorithms against varying levels of mining complexity in a Java-based blockchain framework. The results highlight the trade-off between security and computational efficiency, with the four-character complexity level providing an optimal balance for the aforementioned algorithms. Small and medium-sized enterprises seeking to understand the computational costs associated with blockchain technologies will find these findings particularly useful. The selection of a hashing algorithm and complexity level should be tailored to the specific requirements of the system, balancing security needs with performance capabilities. Additionally, investigating the impact of data size and hardware specifications on hashing algorithm performance would be valuable. As the field of cryptography continues to evolve, ongoing research is essential to keep pace with technological advancements and to deepen our understanding of blockchain technologies. Excluding MD5, SHA2-256 proved to be the most efficient in single hashing operations at C-5 compared to the other algorithms at C-4, although it exhibited noticeably less robustness in hash calculation. Across all evaluated complexity levels, SHA2-512, SHA3-256, and SHA3-512 outperformed in the aforementioned order.

Complexity	MD5	SHA2-256	SHA2-512	SHA3-256	SHA3-512
C-2	160,608	91,442	97,720	82,327	54,964
C-3	332,665	139,485	161,936	122,631	78,507
C-4	370,676	148,637	195,916	136,562	79,170
C-5	405,329	179,762	174,251	104,263	60,359
C-6	341,025	152,285	170,131	108,947	57,776

Table 9.

Hash calculations per second.

Considering these findings for the implementation of a new blockchain system in an actual organizational setting, the computational capacity required for executing complexity levels of two to four characters is similar. Therefore, as C-4 provides the best level of security, it emerges as the most suitable option. It is evident in this case that all hashing algorithms showed a similar trend. However, if a more demanding proof of work is required, increasing the complexity level to five characters, a significant expansion in computational capacity is necessary, and even more so for six characters. However, the incremental demand from five to six characters is approximately just over 10 times, which might imply that scaling between these levels is somewhat more manageable, but it remains substantially costly compared to performing a four-character hash as proof of work.

Every test carried out for this study was done on blocks of 250 bytes. With C-4 being determined to be the most appropriate option for most applications, several block sizes were evaluated at this complexity level (Figure 5). Although the MD5 algorithm was the fastest—completing a 250-byte block in 2456 ms and a 1 MB block in 23,378 ms—it is only suitable for non-sensitive applications due to well-documented security flaws. The mining time for SHA2-256 and SHA2-512 increased significantly from 250-byte blocks to 1 MB blocks, although SHA2-256 performed better overall, finishing at 54,455 ms for the larger blocks as opposed to SHA2-512's 67,320 ms. This demonstrated that, among the SHA2 family, SHA2-256 was a more effective choice, particularly for greater data processing requirements. The highest mining times were reported by SHA3 algorithms, which provided increased security. SHA3-512, for example, reached 132,162 ms for a 1 MB block, highlighting its computational intensity. These findings shed light on the trade-off between security and performance that usually exists in cryptographic processes. A balance between the quick but unreliable MD5 and the safe but slow SHA3 versions was offered by SHA2-256.

Figure 5.

Mining times for blocks of different sizes, by algorithm.

The results about the efficiency of different hashing algorithms are generally applicable to Proof of Work (PoW) and Proof of Stake (PoS) systems in a broad range of blockchain applications. Although PoS presents a model in which the stakes of validators are important for transaction validation, it does not necessarily outperform PoW [38]. While PoS emphasizes less on energy usage and instead offers possible advances in network governance and decentralization, PoW is well known for its computation-based security capabilities. Blockchain framework architecture is significantly impacted by hashing algorithm efficiency, as demonstrated by Ethereum, Hyperledger Fabric, and Corda. Ethereum made the switch to proof-of-stake (PoS) in an effort to increase security and scalability through more effective consensus. The adaptability of Hyperledger Fabric’s consensus processes highlights how effective hashing may improve transaction privacy and productivity for businesses [39]. With an emphasis on the financial sector, Corda emphasizes how crucial it is to select effective hashing algorithms in order to guarantee privacy and finality [7]. When combined, these frameworks show how hashing efficiency plays a key role in maximizing the security, performance, and adaptability of blockchain applications.

While this study examines the efficiency of various mining configurations, energy consumption can be inferred by analyzing their computational expenses and effectiveness. Higher complexity levels result in more computational work and longer processing durations, indicating a likelihood of increased energy usage. Differences in algorithm performance suggest variations in energy efficiency, where certain algorithms may operate more quickly yet potentially consume higher amounts of energy. These findings underscore the importance of considering the environmental effects of hashing algorithms and mining operations for sustainable computing in blockchain technology.

In the blockchain industry, the effectiveness and safety of mining activities are greatly impacted by the selected hashing algorithm and its level of complexity. Public blockchains, benefiting from decentralization and open access over the Internet, find a balanced solution in choosing an algorithm such as SHA2-256 with a complexity level of C-4. This level guarantees efficient transaction processing essential for user interaction while maintaining high security standards. Private blockchains, limited to certain businesses, can focus on security rather than speed. SHA3-256 is preferred for complexity levels C-4 or C-5 because of its strong security characteristics. Private networks can benefit from improved security without incurring excessive computational costs due to their lower computational requirements. Therefore, carefully choosing hashing algorithms and their complexity levels is crucial for enhancing the efficiency of blockchain networks based on their specific needs and operational environments.

In the dynamic realm of blockchain technology, the integration of newer but promising hashing algorithms presents significant advantages. BLAKE3 [40] offers enhanced security through its resistance to modern cryptographic attacks, while KangarooTwelve [41] boasts improved collision resistance and computational efficiency. Argon2 prioritizes memory hardness, making it ideal for password hashing and key derivation functions. Additionally, RandomX introduces a novel approach by leveraging random code execution [42], which enhances resistance to ASIC mining and promotes a more equitable distribution of mining rewards. By adopting these cutting-edge algorithms, blockchain systems can bolster their security, efficiency, and resilience in the face of evolving threats and technological advancements.

6. Conclusion and future work

This study offers a novel perspective on the comparative performance of MD5, SHA-2, and SHA-3 hashing algorithms against varying levels of mining complexity in a Java-based blockchain framework. The results highlight the trade-off between security and computational efficiency, with the four-character complexity level providing an optimal balance for the aforementioned algorithms. Small and medium-sized enterprises seeking to understand the computational costs associated with blockchain technologies will find these findings particularly useful. The selection of a hashing algorithm and complexity level should be tailored to the specific requirements of the system, balancing security needs with performance capabilities. Future research could further explore these dynamics in emerging programming environments, new hashing algorithms, and blockchain networks. Additionally, investigating the impact of data size and hardware specifications on hashing algorithm performance would be valuable. As the field of cryptography continues to evolve, ongoing research is essential to keep pace with technological advancements and to deepen our understanding of blockchain technologies.

Future works should also include testing the hashing efficiency of blockchain systems using different block sizes. While smaller blocks could jeopardize security, larger blocks might lead to increased computing overhead and longer mining times. Optimizing security and performance requires an understanding of this relationship.

Conflict of interest

The author declares no conflict of interest.

Appendices and nomenclature

MD5	Message-Digest algorithm version 5
SHA2-256	Secure Hash Algorithm version 2, with a 256-bit length
SHA2-512	Secure Hash Algorithm version 2, with a 512-bit length
SHA3-256	Secure Hash Algorithm version 3, with a 256-bit length
SHA3-512	Secure Hash Algorithm version 4, with a 512-bit length
PoW	Proof of Work process
C-2	complexity level of 2 characters in a hash string
C-3	complexity level of 3 characters in a hash string
C-4	complexity level of 4 characters in a hash string
C-5	complexity level of 5 characters in a hash string
C-6	complexity level of 6 characters in a hash string