Scalability and Efficiency Analysis of Hyperledger Fabric and Private Ethereum in Smart Contract Execution

Abstract

Blockchain technology has emerged as a transformative solution for secure, immutable, and decentralized data management across diverse domains, including economics, healthcare, and supply chain management. Given its soaring adoption, it is crucial to assess the suitability of various blockchain platforms for specific applications. This study evaluates the performance of Hyperledger Fabric (HF) and private Ethereum (Geth) to analyze their scalability (node count), throughput (transactions per second (TPS)), and latency (measured in milliseconds). A benchmarking tool was developed in-house to assess the execution of key smart contract functions—QueryUser, CreateUser, TransferMoney, and IssueMoney—under varying transaction loads (10–1000 transactions) and network sizes (2–16 node count). The results indicate that HF performs significantly better than private Ethereum in terms of invoke functions, achieving up to 5× throughput and up to 26× lower latency. However, private Ethereum excels in query operations because of its account-based ledger model. While Hyperledger Fabric scales efficiently within moderate transaction volumes, it experiences concurrency limitations beyond 1000 transactions, whereas private Ethereum processes up to 10,000 transactions, albeit with performance fluctuations due to gas fees. The findings offer valuable insights into the strengths and tradeoffs of both platforms, informing optimal blockchain selection for enterprise applications that require high transaction efficiency.

1. Introduction

Most traditional systems are based on centralized databases in which a single entity controls the data repository and management. In contrast, distributed ledger technology (DLT) is a decentralized database spread across multiple nodes designed to record, share, and synchronize data across a network [1]. A DLT stores transactions and data immutably and transparently across a decentralized network of participants. Consequently, a shared and distributed database is collectively managed by the network nodes. In a blockchain, data are organized into blocks, and every block contains a list of transactions along with the hashes of the previous block, subsequently creating a chain of blocks [2]. In addition, each block hash depends on its content and the hash of the preceding block; thus, changing a single block changes its hash, affecting the entire chain and ensuring its immutability.

The blockchain market has grown significantly, with its value increasing from USD 4.19 billion in 2020 to USD 26.91 billion in 2023 and projected to reach USD 32.69 billion in the coming years [3]. Despite this expansion, only 3.9% of the global population actively uses blockchain, with over 300 million users worldwide and 85 million relying on the blockchain walls, as shown in Figure 1. Global spending on blockchain solutions is expected to increase to USD 19 billion. The cryptocurrency market has expanded with nearly 20,000 cryptocurrencies in existence, although only 10,025 remain active. Blockchain adoption is evident across industries, with 90% of the surveyed businesses implementing it and 86% believing in its transformative potential [4]. However, challenges remain, as cryptocurrency scams have resulted in USD 5.6 billion in losses for U.S. users, emphasizing the need for stronger security and regulatory oversight. Despite these risks, blockchain continues to drive innovation, reshape industries, and promote a decentralized digital economy.

Blockchain technology can be categorized into different types based on network permissions: private, public, and consortium blockchains [5]. Bitcoin was the first implementation of blockchain [6], wherein peer-to-peer transactions can be executed without requiring centralized authorization to verify the transactions. Ethereum [7] expanded the blockchain capabilities and introduced the concept of smart contracts. Numerous other blockchains have been introduced, such as Cardano, Litecoin, Ripple, Avalanche, Stellar, and Tezos. Ethereum and Bitcoin are defined as public blockchains because any entity can participate in the generation and validation of blocks by joining the network. Hyperledger Fabric [8], which is an enterprise-grade permissioned blockchain framework, along with private Ethereum (Geth; users deploy their private Ethereum network with a Geth client [9]) and Corda are examples of private blockchains.

A smart contract (SC) is a blockchain-based, self-executing program that automatically implements agreement terms when specified conditions are fulfilled [10]. These contracts are coded using programming languages such as Solidity (for the Ethereum platform), and function in a decentralized environment, ensuring transparency and resistance to tampering. Smart contracts eliminate intermediaries such as banking or legal entities, enabling direct transactions between parties. They enhance security, efficiency, and automation by reducing paperwork, fraud potential, and optimizing the processes. The process involves coding the contract, deploying it on a blockchain, and executing authenticated and logged transactions on a distributed ledger. Applications include finance [11], powering DeFi platforms for lending and automated payments, supply chain management, improving product tracking transparency, healthcare [12,13], protecting medical data and real estate, enabling automated property transactions and gaming/NFTs, and facilitating digital asset ownership. By automating agreements with immutability and transparency, smart contracts are revolutionizing industries and becoming crucial in decentralized applications (DApps) and blockchain ecosystems.

Understanding the unique features of each blockchain type is crucial for selecting the most appropriate solution in each scenario. Public blockchains offer openness and transparency that are suitable for decentralized applications and cryptocurrencies, whereas private blockchains provide enhanced privacy and control, making them ideal for enterprise solutions [14]. This study aims to develop a technique for selecting blockchain types using a multi-criteria decision matrix (MCDM). In addition, blockchain performance analysis can provide greater insight into system bottlenecks, network scalability (how well the network under test handles increasing transaction volumes and network growth), and the overall capabilities of different blockchain platforms. Typically, blockchain-based systems lag their traditional counterparts in terms of performance. Pineda et al. [15] identified the following as technical limitations of blockchain-based systems: latency, throughput, bandwidth, volume, security, exhausted resources, reusability, versioning, and hard forks. In essence, benchmarking and comparing the performance of blockchain platforms provides insight to users regarding the suitability of a particular platform for a specific use case [14]. In this study, performance was analyzed by changing the number of peers: two, four, eight, 12, and 16.

Additionally, the transaction batch size was varied, that is, 10, 25, 50, 100, 1000, and 10,000 transactions. However, it was discovered that Hyperledger Fabric networks experienced network failure when 1000+ transactions were sent to the networks simultaneously. Network failure is due to process concurrency and communication overhead between peers in the network. Hence, in this study, the maximum number of transactions in an input batch is restricted to 1000. Moreover, latency, throughput, and scalability were used as performance metrics to evaluate both blockchain platforms. The Hyperledger Fabric version used in this study was v2.5 [16] and private Ethereum was v1.13.5. Both Hyperledger Fabric and private Ethereum require some computational load for processing; therefore, a smart contract emulating a simple banking application was developed. This smart contract was selected as the processing load because it is similar to a cross-border remittance distributed application developed in-house for Habib Bank Limited (HBL). Thus, the results in this study provide an approximation of the performance of cross-border DApps on Hyperledger Fabric and private Ethereum. The smart contract functions are QueryUser, CreateUser, TransferMoney, and IssueMoney, where QueryUser is the only query/read function while the rest of the functions are invoked/write functions. Query functions retrieve data from the ledger, while invoking functions update the state of the ledger. The benchmarking tool used for this analysis was developed in house.

This study makes the following key contributions:

• We developed an in-house benchmarking tool to assess the execution of key smart contract functions (QueryUser, CreateUser, TransferMoney, and IssueMoney) for various transaction loads and network sizes;
• We compared Hyperledger Fabric v2.5, and private Ethereum v1.13.5, with varying network configurations (2–16 peers and batch sizes from 10 to 10,000 transactions);
• We evaluated the impact of the Raft consensus (used in Hyperledger Fabric) and Proof of Stake (PoS) consensus (used in private Ethereum) on transaction processing efficiency;
• We demonstrated that private Ethereum’s account-based model enables faster query operations, making it preferable for applications requiring frequent data retrieval.

2. Related Work

The application of blockchain technology across various domains has been extensively studied in recent years. Researchers have explored its potential for financial transactions, supply chain management, healthcare, and land record management because of its decentralized and immutable nature. Several studies have compared public and private blockchains to determine their suitability in different use cases.

Hyperledger Fabric and Ethereum, two widely used blockchain platforms, have been the focus of multiple performance evaluations. Pongnumkul et al. [17] conducted an early comparative study of Ethereum and Hyperledger Fabric and analyzed their transaction throughput, latency, and resource consumption. However, their scope did not involve smart contract-level benchmarking under various workloads. Their results indicate that Hyperledger Fabric provides better transaction throughput in permissioned environments, whereas Ethereum excels in decentralized applications. Similarly, Baliga et al. [18] examined the security and scalability of private blockchain networks, emphasizing the trade-offs between consensus mechanisms and network efficiencies. However, it lacks empirical analysis of smart contract function performance. Thakkar et al. [19] conducted experiments to analyze the performance of a permissioned blockchain such as HF by changing endorsement policy, channels, block size, state database, and resource allocation. The authors provided six guidelines for configuring these values along with three performance bottlenecks, but did not provide a direct comparison of smart contract execution patterns or cross-platform evaluations under identical workloads. Monrat et al. [20] showed the performance evaluation of different permissioned blockchain platforms, i.e., private Ethereum, Quorum, Corda, and HF. However, the authors did not explore how specific smart contract function types (e.g., query vs. invoke) behave under stress or scaling. Researchers in [21] evaluated the throughput, latency, and error rate, scalability of the HF 2.0 blockchain platform and found it superior to previous versions.

Previous studies have also analyzed blockchain scalability challenges. Zheng et al. [22] provided an extensive review of blockchain performance, identifying transaction-processing speed and network congestion as key bottlenecks. However, they did not experiment with transaction execution complexity or real-time batch size scaling. Their study highlighted the need for efficient consensus mechanisms, such as Proof of Authority (PoA) and Practical Byzantine Fault Tolerance (PBFT), to improve the scalability of private blockchains [13]. In another study, Zheng et al. [23] deployed a continuous-time Markov chain (CTMC) to model the performance of permissioned blockchains with a practical byzantine fault tolerance (PBFT) consensus protocol. Dinh et al. [24] presented an empirical evaluation of permissioned blockchains, highlighting the impact of network configuration and transaction loads on performance. Croman et al. [25] explored blockchain scalability with their analysis focused on Bitcoin. The authors demonstrated that the latency and throughput of Bitcoin can be improved by reparametrizing its block size and interval. The authors demonstrated that increasing the block size and reducing the block intervals alone provides limited scalability benefits owing to network propagation delays and the decentralization of trade-offs. They proposed a set of throughput and latency limits for sustainable scaling, such as restricting block sizes to 4 MB to maintain a 90% effective throughput, and ensuring that block intervals are no shorter than 12 s to prevent network congestion. Koteska et al. [26] analyzed quality-related matters in blockchain implementations and found further blockchain quality attributes. The results indicate that blockchain technology must be improved in many quality attributes, such as latency, scalability, throughput, and cost-effectiveness.

Several studies have explored the transaction throughput and latency of these platforms in order to improve their performance in enterprise applications. Gorenflo et al. [27] critically examined the design of HF and introduced architectural improvements to enhance its transaction throughput from 3000 to 20,000 transactions/s. Unlike previous studies, which primarily focused on optimizing consensus mechanisms, this study identifies and addresses performance bottlenecks beyond consensus, specifically in transaction ordering and validation. The proposed optimizations collectively improve the throughput of Hyperledger Fabric by a factor of nearly seven. Furthermore, the study suggests that future enhancements, such as adopting a Byzantine Fault-Tolerant (BFT) consensus mechanism, such as RCanopus, could further improve performance to match real-world financial transaction systems, such as Visa, which require up to 50,000 transactions per second. This study tested Fabric only without considering its Ethereum counterpart.

Yasaweerasinghelage et al. [28] formulated a predictive model that estimates transaction confirmation time based on network topology, block size, and transaction arrival rates. The authors proposed a simulation-based approach to model blockchain performance, demonstrating that network-propagation delays can be a major bottleneck, particularly in large-scale distributed systems. The authors showed that modifying consensus mechanisms, such as adopting proof of authority (PoA) instead of proof of work (PoW), can significantly reduce latency. Additionally, their results indicate that increasing the number of full nodes can improve reliability but may also introduce additional delays due to synchronization overhead.

Recent research has focused on optimizing blockchain frameworks for enterprise applications. Androulaki et al. [16] introduced Hyperledger Fabric’s modular architecture and demonstrated its advantages in terms of access control and transaction finality. Wüst and Gervais [29] investigated whether blockchain technology is always necessary for enterprise applications and proposed a decision framework for selecting the appropriate blockchain type.

Other comparative studies have evaluated blockchain networks in specific domains. For example, Malik et al. [12] conducted a benchmarking study on HF and Ethereum for healthcare applications and showed that Hyperledger Fabric outperformed Ethereum in private high-throughput scenarios. Similarly, Novo [30] explored blockchain-based IoT security, revealing that private blockchains, such as Hyperledger Fabric, offer enhanced control and efficiency compared with public alternatives. Aniello et al. [31] evaluated the double-layer architecture for blockchain-based databases. The proposed architecture exhibits high performance, preserved data integrity, improved data availability, and mitigated scalability. Megias et al. [32] evaluated the performance analysis of two versions of HF (i.e., v0.6 and v1.0). Vuckolic et al. [33] compared the performance of blockchain platforms grounded on proof of work (PoW) [34] and PBFT [35] consensus mechanisms in terms of scalability.

Despite these efforts, a comprehensive evaluation of Hyperledger Fabric and private Ethereum (Geth) with varying network conditions and workloads remains an ongoing research challenge. Furthermore, although the aforementioned studies offer insights into blockchain performance, a notable gap exists in the comprehensive evaluation of the latest versions of these prominent platforms. Many foundational studies analyze older architectures, and there is a limited focus on performance evaluations specifically tailored to critical financial applications like Funds Transfer, which have unique demands in terms of transaction volume, speed, and security. Although some studies explore varying network conditions and workloads, a systematic analysis in diverse scenarios relevant to real-world financial deployments is still an ongoing research gap. Therefore, a study focusing on the latest versions of Hyperledger Fabric and private Ethereum, specifically evaluating their performance for financial applications like Funds Transfer under varied conditions, is necessary to provide up-to-date and relevant insights for the financial industry’s adoption of blockchain technology. It provides a comparison of write-heavy and read-only workloads across a wide range of transaction loads (10–10,000) and network sizes (2–16 peers). It demonstrates platform-specific strengths by deploying an in-house benchmarking tool for a consistent metric collection. This study builds on previous work by providing a detailed comparative analysis of these platforms using key performance metrics including throughput, latency, and scalability. A comparison of the related studies is provided in

Table 1. Comparison with existing studies.

Studies	Method	Focus Area	Methods	Findings	Limitations
[17]	HF, Ethereum	Throughput, latency.	Small-scale tests.	Fabric is better for permissioned applications; Ethereum for open.	No peer scaling and smart contract differentiation.
[18]	Multiple	Consensus models.	Theoretical analysis.	Trade-offs in consensus.	Empirical performance results missing.
[24]	HF, Ethereum	Benchmark framework (Blockbench).	Empirical analysis.	Framework to benchmark blockchains.	Smart contract types were not analyzed.
[19]	HF	Config tuning.	Parameter tweaking (block size, DB).	Performance guidelines.	Focused only on HF.
[13]	General	Blockchain bottlenecks.	Review.	Identified consensus and network issues.	No real-world performance simulation.
[20]	HF, Ethereum, Corda	Multi-platform comparison.	Throughput and latency.	Overview of pros/cons.	No level or scaling tests.
[27]	HF	Architectural optimization.	System design.	Increased Fabric TPS from 3 K to 20 K.	No Ethereum comparison.
[36]	HF, Ethereum	IoT access control.	Attribute-based access tests.	Platform-specific access strengths.	Did not assess scalability.
Our study	HF v2.5, private Ethereum v1.13.5	Smart Contract Execution, scalability.	Function-level benchmarking (invoke/query) + peer scaling.	Fabric excels in invoke ops; Ethereum in query ops.	Dual-platform comparison with smart contract context.

.

3. Materials and Methods

In this study, Hyperledger Fabric and private Ethereum (Geth client) were selected as blockchain platforms for the performance analysis. The evaluation was conducted using Hyperledger Fabric v2.5, the latest stable release known for its modular architecture and improved transaction processing capabilities. For Ethereum, Geth client version 1.13.5 was used, which provides a private blockchain environment for controlled experimentation. Performance tests were executed on a high-performance HPE server equipped with an Intel Xeon CPU 6430 operating at 2.1 GHz with 32 cores, ensuring the efficient parallel processing of blockchain transactions. The server was configured with 264 GB RAM, offering ample memory resources for handling concurrent blockchain operations. The experiments were performed on Ubuntu 22.04 OS, providing a stable and optimized environment for blockchain deployment. This robust hardware and software setup ensured the accurate measurement of key performance metrics, such as throughput, latency, and scalability, allowing for a detailed comparative analysis of HF and private Ethereum under varying network conditions.

3.1. Blockchain Platforms

Two private blockchain platforms were chosen for this evaluation: Hyperledger Fabric and private Ethereum (Geth) [37]. These platforms were selected because of their popularity, modular architecture, robustness, and applicability to a wide range of use cases. Hyperledger Fabric and private Ethereum (Geth) were the two private blockchain platforms chosen for this evaluation. These platforms are renowned for their modular architecture, robustness, and versatility, which makes them suitable for a variety of applications. Ethereum [38] is an open-source enhancement of Bitcoin blockchain implementation with an Ethereum virtual machine (EVM). It is a distributed state machine that supports the storage and execution of custom smart contracts; contractual agreements are processed through self-executing code. The main Ethereum platform is a public network in which any entity can join the network and contribute to the block generation and validation processes. However, a private Ethereum network can be deployed by initiating a network of Geth clients in which clients with whitelisted IP addresses can join the network. On the other hand, HF is an open-source private development framework established by the Linux Foundation. This framework provides a modular approach to designing permissioned blockchain enterprise applications. The framework also employs container technology (Docker) to implement contracts, known as chain codes. It contains the business logic application of the system. The Hyperledger Fabric framework is a popular choice for enterprise solutions because it offers secure, scalable, and customized blockchain infrastructure, that is, the ability to tailor the blockchain infrastructure to their specific needs, establishing itself as a key player in permissioned blockchain.

3.2. Smart Contracts

In this study, a smart contract with four core functions was deployed to analyze the performance of blockchain platforms, specifically HF and private Ethereum (Geth). These functions were carefully selected because they align with the requirements of a cross-border remittance decentralized application (DApp) developed for HBL Bank (Habib Bank Limited). Smart contract functions mirror key banking operations, making them relevant for evaluating the suitability of blockchain in financial transactions.

The first function, QueryUser, allows for the retrieval of user details from the ledger, enabling efficient data access for account verification and transaction history checks. This function reads data from a mapping that stores the user details indexed by a unique user identifier. The operation involves a single lookup based on the provided key, making it read-intensive and computationally lightweight. This function represents the need to access and verify information stored in the blockchain. It can be used in other industries, such as healthcare, where patient records need to be queried, or within supply chain management to retrieve product provenance details. Similarly, land record applications must access property ownership information or verify user credentials in any identity management use case.

The CreateUser function facilitates the creation of new user accounts, ensuring a seamless onboarding process within the decentralized system. It involves writing a new user record to the ledger and includes creating a new entry and emitting an event. This is a write-intensive operation with moderate complexity involving state modification and indexing. This function mirrors the process of registering new entities or assets in the blockchain. In healthcare, the enrollment of new patients or registering new suppliers in supply chain applications would use a very similar function. The enrollment of new students in the education sector or devices in an IoT network can also be carried out using the same coded logic.

The IssueMoney function enables authorized entities to credit user accounts with funds, similar to a bank that deposits money in a customer’s account. This function credits a specified user account balance and involves reading the current balance, adding the credited amount, and writing the updated balance back to the ledger. This is a read-write operation with moderate complexity, requiring the state modification of a specific user’s balance. This function represents creation/updates for an asset, which essentially represents the issuance of verifiable records for patients in the healthcare sector or the creation of points within a loyalty program for various brands

Finally, the TransferMoney function allows for peer-to-peer (P2P) money transfers to simulate real-time fund movements between accounts. This function facilitates the transfer of funds from one user account to another account. This involves reading the balances of both the sender and receiver, decrementing the sender’s balance, incrementing the receiver’s balance, and writing these updated balances to the ledger. It is a more complex read-write operation that involves multiple state modifications and potentially conditional logic. This transfer of value or information between participants without intermediaries can be useful for other applications, such as in the supply chain sector to represent payments between buyers and suppliers or the sharing of medical data in the healthcare industry.

By implementing these functions, the performance of both HF and private Ethereum was assessed in terms of latency, throughput, and scalability. This comparative analysis provides insights into the efficiency of these blockchain platforms in handling banking transactions and ensuring security, transparency, and speed. The varying levels of state interaction and the computational steps inherent in these functions are expected to influence the observed performance metrics. For instance, the read-intensive nature of QueryUser is anticipated to result in lower latency and higher throughput compared with the more complex TransferMoney function, which involves multiple read and write operations.

The performance characteristics observed for these core functions on Hyperledger Fabric and private Ethereum can also provide valuable insights into the suitability of these platforms for a range of applications beyond the financial sector, where similar data management and transactional requirements exist.

3.3. Evaluation Metrics

In this study, throughput and latency were the key performance evaluation metrics used to analyze the efficiency of Hyperledger Fabric and private Ethereum blockchain platforms [39]. These metrics provide insights into a platform’s ability to efficiently handle transactions under different network conditions.

In blockchain technology, throughput refers to the rate at which a system can successfully process transactions, measured in transactions per second (TPS). This was calculated by measuring the total duration required for a set number of transactions to be confirmed on the blockchain. StartTime (ST) represents the moment when transactions are sent to the blockchain network under test, whereas EndTime (ET) indicates when the transactions are successfully confirmed. The difference between ET and ST provides the total duration of the transaction processing. The formula for throughput is expressed as

$$Throughput={\displaystyle \frac{\mathrm{N}\mathrm{u}\mathrm{m}\mathrm{b}\mathrm{e}\mathrm{r} \mathrm{o}\mathrm{f} \mathrm{t}\mathrm{r}\mathrm{a}\mathrm{n}\mathrm{s}\mathrm{a}\mathrm{c}\mathrm{t}\mathrm{i}\mathrm{o}\mathrm{n}\mathrm{s}}{\mathrm{D}\mathrm{u}\mathrm{r}\mathrm{a}\mathrm{t}\mathrm{i}\mathrm{o}\mathrm{n}(\mathrm{i}\mathrm{n} \mathrm{s}\mathrm{e}\mathrm{c}\mathrm{o}\mathrm{n}\mathrm{d}\mathrm{s})}}$$

where the duration is computed as

$$Duration={\displaystyle \frac{\mathrm{E}\mathrm{T}-\mathrm{S}\mathrm{T}}{1000}}$$

We divided it by 1000 to convert milliseconds into seconds. A higher throughput indicates a more efficient blockchain system that can handle large transaction volumes per second.

On the other hand, latency determines the time difference between submitting a transaction and receiving confirmation on the blockchain. It is defined as the difference between transaction confirmation and submission times for a single transaction. This provides insight into how quickly a blockchain network can process and validate transactions. Lower latency is preferred for real-time applications, such as financial transactions, supply chain tracking, and decentralized applications (DApps), where timely execution is critical. Mathematically, latency is expressed as

$$Duration=\mathrm{C}\mathrm{o}\mathrm{n}\mathrm{f}\mathrm{i}\mathrm{r}\mathrm{m}\mathrm{a}\mathrm{t}\mathrm{i}\mathrm{o}\mathrm{n} \mathrm{T}\mathrm{i}\mathrm{m}\mathrm{e}-\mathrm{S}\mathrm{u}\mathrm{b}\mathrm{m}\mathrm{i}\mathrm{s}\mathrm{s}\mathrm{i}\mathrm{o}\mathrm{n} \mathrm{T}\mathrm{i}\mathrm{m}\mathrm{e}$$

Using these metrics, this study evaluates the comparative efficiency of Hyperledger Fabric and private Ethereum to determine which platform is more appropriate for enterprise applications involving high-speed and scalable blockchain solutions.

3.4. Evaluation Flow

Testing smart contracts is crucial for ensuring their robustness, dependability, and performance before implementing a blockchain [40]. Given the unchangeable nature of deployed smart contracts, comprehensive testing is vital to avoid financial setbacks, security compromises, or unforeseen behaviors, as flaws cannot be easily rectified post-deployment. The testing process aids in uncovering logical flaws, gas inefficiencies, and potential vulnerabilities such as reentrancy attacks, overflow/underflow issues, and unauthorized access attempts. It also verifies that the contract functions as intended across various scenarios, including extreme cases and high-stress conditions. Moreover, testing helps streamline gas usage, thereby reducing transaction expenses and enhancing the overall performance. Developers can leverage platforms like Truffle, Hardhat, and Hyperledger Caliper to emulate blockchain environments, execute unit tests, and examine contract behavior before deployment. Through meticulous testing, developers can bolster confidence, ensure regulatory compliance, and mitigate risks, ultimately making smart contracts more secure and dependable for practical applications.

Figure 2 illustrates the structured workflow for testing smart contracts in a private Ethereum network. The process begins with the creation of a private Ethereum blockchain, where a specified number of peer nodes are configured using an Ethereum client such as Geth. This private network operates independently of the public Ethereum blockchain, allowing controlled experimentation. The setup includes initializing the blockchain with a custom genesis block, configuring peer connections, and enabling a consensus mechanism, such as Proof of Authority (PoA), for efficient validation. Once the network is established, the next step is to deploy a smart contract using its compiled bytecode or Application Binary Interface (ABI). This involves compiling the Solidity code using tools such as Solc or Remix and then deploying it via Web3.js, Web3.py, or frameworks such as Truffle, which send deployment transactions to the private blockchain. After successful deployment, the contract was tested by invoking its functions. The testing phase includes reading the stored data, executing state-changing functions, and interacting with other contracts, if applicable. These interactions can be performed using Web3 libraries, Ethereum clients, such as Remix or Hardhat, or automated testing frameworks, such as Truffle or Foundry. The test results, including transaction logs, execution costs, and gas consumption, were analyzed to ensure the functionality, security, and efficiency of the contract. This structured approach provides a sandboxed environment in which developers can validate smart contract behavior before deploying it in a public blockchain.

Figure 3 illustrates the structured process for deploying and testing the chaincode (smart contract) in a Hyperledger Fabric network. The process begins with creating and joining a channel in which multiple organizations establish a shared communication layer for blockchain transactions. Next, the chaincode is packaged, which involves preparing the smart contract code and the metadata necessary for deployment. Once packaged, chaincode is installed on the peer nodes, allowing each organization to endorse peers to execute the contract. The approval process follows in which the chain code must be explicitly approved by network members based on an agreed-upon endorsement policy. After obtaining the necessary approvals, the chain code is committed to the channel, making it available for execution across the network. Finally, a test is performed by invoking chaincode functions to ensure that the smart contract operates correctly in the expected and edge-case scenarios. This structured workflow ensures that the chain code is securely deployed, properly endorsed, and functionally tested before being utilized in production environments.

4. Results

This section presents the performance evaluation of two private blockchain platforms: Hyperledger Fabric and private Ethereum (Geth). The assessment is based on the key metrics of latency, throughput, and scalability, which are essential for determining the efficiency and suitability of blockchain platforms for enterprise applications, particularly within the banking and financial sectors. To conduct this analysis, four smart contract functions—QueryUser, CreateUser, TransferMoney, and IssueMoney—were deployed and executed on both the blockchain networks. These functions simulate real-world banking operations such as querying user information from a blockchain ledger (QueryUser), creating new user accounts (CreateUser), crediting funds to an account (IssueMoney), and processing peer-to-peer transactions (TransferMoney). The execution of these functions imposes a computational load on the blockchain network, allowing for the assessment of each platform’s capability in handling transaction execution. For scalability analysis and throughput measurements, multiple variables were adjusted, including the number of network peers participating in the blockchain and transaction batch size. These adjustments provide insights into how well each platform scales with increased transaction volume and network expansion.

4.1. Latency Analysis

Figure 3 shows the latency of the four smart contract functions executed on the blockchain network under testing with varying numbers of peers: two, four, eight, 12, and 16. Figure 4a shows the latency measurement for the QueryUser function, which retrieves user details from the blockchain and shows a significantly lower latency than Hyperledger Fabric, outperforming it by a factor of approximately 5×. This suggests that Ethereum handles read operations more efficiently because of its account-based model and ability to quickly retrieve state data. In contrast, Hyperledger Fabric follows a permissioned ledger model, where state validation and access control policies add additional overhead, leading to a higher latency. Figure 4b shows the latency measurement for the CreateUser function, which involves writing new data to the ledger, achieving up to 14× lower latency compared to Ethereum, particularly when the number of peers is less than or equal to eight. As the network grows beyond eight peers, Ethereum’s latency worsens significantly, indicating that Ethereum struggles to handle write-heavy transactions at scale. This degradation occurs because of Ethereum proof of work (PoW)-based transaction processing, which requires each transaction to be validated, mined, and propagated across the network before confirmation. In contrast, Hyperledger Fabric employs an endorsing and ordering service-based model in which transactions are preapproved by peers before being committed, reducing the overall latency. A similar pattern is observed for the IssueMoney function in Figure 4c, where Hyperledger Fabric consistently outperformed Ethereum. Fabric maintains a latency advantage of approximately 17× for up to eight peers, whereas Ethereum’s latency worsens drastically when more peers are added. This is because Ethereum’s block finalization and gas fee mechanics introduce delays, whereas Hyperledger Fabric processes transactions deterministically through its consensus mechanism, leading to faster confirmation. The most significant performance difference was observed in the TransferMoney function, as shown in Figure 4d, where Hyperledger Fabric demonstrates a 26× lower latency than Ethereum. This highlights the inefficiency of Ethereum in handling peer-to-peer fund transfers, which requires mining and network-wide validations. By contrast, Hyperledger Fabric leverages private channels and permissioned access, allowing transactions to be executed faster with reduced computational overhead.

4.2. Throughput Analysis

Throughput analysis for both query and invoke functions was conducted similarly to latency measurements, varying the number of transactions from 10 to 1000, and adjusting the number of network peers from two to 16. Invoke functions that modify the blockchain state lead to the creation of new blocks and ledger updates that require consensus among peers. The invoke functions under consideration include CreateUser for user registration, TransferMoney for monetary transactions, and IssueMoney for issuing digital currency. In contrast, query functions merely retrieve data from the ledger without making modifications, thereby eliminating the need for a consensus. The only query function analyzed is QueryUser, which fetches user details. Because query operations do not involve multiple peers, their throughput is analyzed based only on the number of transactions rather than the number of peers.

4.2.1. Throughput Analysis of Query Function

Figure 5 compares the throughput of the Query function for Hyperledger Fabric and Ethereum as the number of transactions increases from 10 to 1000, measured in transactions per second (TPS). Initially, Ethereum demonstrates a higher throughput than Hyperledger, with a steady linear increase from 86.36 TPS at 10 transactions to 1534.87 TPS at 1000 transactions, suggesting moderate scalability constrained by its consensus mechanism. In contrast, Hyperledger Fabric starts with a lower throughput but surpasses Ethereum significantly at higher transaction volumes, reaching 5968.91 TPS at 1000 transactions. This sharp increase indicates that Hyperledger is highly efficient in handling large transaction loads, likely owing to its permissioned network and optimized consensus mechanisms such as Kafka or Raft. The crossover point around 100 transactions marks the threshold at which Hyperledger overtakes Ethereum in terms of performance, highlighting Ethereum’s higher computational and consensus overhead, which limits its ability to scale efficiently. Although Ethereum may be preferable for small-scale applications, Hyperledger Fabric is the superior choice for high-performance enterprise use cases requiring high throughput, such as financial transactions and supply chain management. The analysis suggests that permissioned blockchains such as Hyperledger are better suited for large-scale applications, whereas Ethereum faces bottlenecks in network consensus and transaction validation at higher loads.

4.2.2. Throughput Analysis of CreateUser Function

Figure 6 illustrates the throughput performance of the CreateUser function in both Hyperledger Fabric and private Ethereum across different batch transaction sizes (10, 25, 50, 100, and 1000), while changing the number of peers from two to 16. The results clearly indicate that Hyperledger Fabric significantly outperformed private Ethereum in all scenarios and consistently achieved higher throughput values. A key trend observed is that the throughput decreases as the number of peers increases for blockchain platforms. This decline in performance is attributed to increased communication and consensus overheads associated with a higher number of peers. However, Hyperledger Fabric maintains a substantially higher throughput than private Ethereum, highlighting its efficiency in handling transaction loads in a permissioned network. Notably, at 1000-batch transactions, Hyperledger Fabric achieved a peak throughput of 1821.23 transactions per second (TPS) at two peers, which gradually declines to 993.06 TPS at 16 peers. By contrast, private Ethereum remains significantly lower, with its highest throughput value at only 78.89 TPS for 16 peers. Moreover, private Ethereum exhibits fluctuations in throughput at certain points, particularly in the 50-batch transaction scenario, where throughput values fluctuate between 7.08 TPS (eight peers), 10.62 TPS (12 peers), and 9.90 TPS (16 peers). These variations suggest potential inefficiencies or inconsistencies in Ethereum’s consensus mechanism when handling a moderate number of transactions with varying peer sizes.

Overall, the analysis demonstrates that Hyperledger Fabric is more scalable and efficient for the CreateUser function, especially as the transaction volume increases, whereas private Ethereum faces significant performance limitations owing to its consensus overhead and fluctuating throughput behavior. The results reinforce the advantage of Hyperledger Fabric for enterprise-level applications requiring high throughput and stable performance across various network configurations.

4.2.3. Throughput Analysis of TransferMoney Function

Figure 7 illustrates the throughput performance of the TransferMoney function for Hyperledger Fabric and private Ethereum with varying batch transaction sizes (10, 25, 50, 100, and 1000) while increasing the number of peers from two to 16. The results demonstrate that, similar to the CreateUser function in Figure 5, Hyperledger Fabric consistently outperforms private Ethereum in terms of throughput across all configurations. However, both platforms exhibited different trends as the number of peers and the batch size increased. A key observation is that Hyperledger Fabric’s throughput decreases as the number of batch transactions and peers increases. This decline is attributed to the growing network communication overhead and increased computational load required for consensus. For instance, in 1000-batch transactions, Hyperledger Fabric achieves a peak throughput of 1619.76 TPS with four peers, but the throughput declines steadily to 718.59 TPS with 16 peers, indicating that adding more peers introduces inefficiencies. By contrast, private Ethereum exhibits a more erratic throughput pattern, particularly for smaller batch sizes. For 10-batch and 25-batch transactions, Ethereum’s throughput fluctuates slightly as the number of peers increases, showing small rises and dips rather than a consistent trend. This inconsistency suggests that Ethereum’s consensus mechanism struggles with transaction processing for different peer configurations. For 50-batch transactions, Ethereum’s throughput oscillates between 12.11 TPS and 19.85 TPS, with specific values at two, four, eight, 12, and 16 peers being 15.57, 19.85, 18.80, 12.97, and 12.11 TPS, respectively. This inconsistency may stem from variations in transaction validation times, network conditions, or smart contract execution overhead. For 100-batch transactions, Ethereum exhibits a minor increase in throughput from eight peers onward, suggesting that, after an initial drop, the network stabilizes slightly. Finally, for 1000-batch transactions, Hyperledger Fabric’s throughput begins to decline significantly after four peers, whereas private Ethereum continues to show minor oscillations at different peer levels, except for two peers, where it reaches its highest value (388.44 TPS). This suggests that Ethereum operates most efficiently with fewer peers, but its performance becomes less predictable as the network size increases.

Overall, Hyperledger Fabric remains a more scalable and efficient platform for handling monetary transactions despite the expected decline in throughput with increasing peers and batch sizes. Conversely, private Ethereum exhibited less stable throughput trends with frequent fluctuations, reinforcing its limitations in effectively handling enterprise-level transaction loads. This comparison further emphasizes Hyperledger Fabric’s suitability for high-throughput financial applications, whereas private Ethereum’s performance remains constrained by its consensus overhead and network inefficiencies.

4.2.4. Throughput Analysis of IssueMoney Function

Figure 8 presents the throughput performance of the IssueMoney function for Hyperledger Fabric and private Ethereum with different batch transaction sizes (10, 25, 50, 100, and 1000) while varying the number of peers from two to 16. These results are consistent with the previous findings in Figure 5 and Figure 6, showing that Hyperledger Fabric consistently achieves a higher throughput than private Ethereum across all configurations. However, both blockchain platforms exhibit distinct trends as batch sizes and network peers increase. A key observation is that Hyperledger Fabric’s throughput decreased as the number of batch transactions and peers increased. This trend is attributed to the increasing communication and consensus overhead required for transaction validation, which slows down the processing rate. For instance, at 1000-batch transactions, Hyperledger Fabric achieves a peak throughput of 1619.76 transactions per second (TPS) at four peers, but throughput progressively declines to 718.59 TPS at 16 peers, indicating that additional peers introduce processing inefficiencies. The overall trend suggests that Hyperledger Fabric performs optimally with a moderate number of peers, but an excessive peer count can negatively impact throughput owing to higher coordination overhead.

By contrast, private Ethereum demonstrates a mixed throughput pattern. For 10-batch and 25-batch transactions, Ethereum’s throughput experiences a slight decline as the number of peers increases, indicating that the additional validation process and consensus mechanism contribute to the drop in performance. However, for 50-batch transactions, Ethereum exhibits a gradual rise and fall in throughput, suggesting that network conditions and consensus delays create minor variations in the transaction-processing efficiency. For 100- and 1000-batch transactions, the throughput of private Ethereum fluctuates significantly across different peer configurations. This fluctuation can be attributed to network congestion, variations in transaction validation time, and inconsistencies in Ethereum’s consensus performance when more peers are introduced. Notably, Ethereum does not exhibit a clear pattern in throughput scalability, unlike Hyperledger Fabric, which consistently trends downward when more peers are added.

Overall, this analysis reinforces the conclusion that Hyperledger Fabric is a more efficient and scalable platform for handling high-volume financial transactions, including digital currency issuances. Its performance remains relatively stable and predictable, despite the expected decline with additional peers and batch sizes. In contrast, private Ethereum’s performance remains inconsistent and unpredictable, with throughput fluctuating at different transaction volumes and peer counts. These findings suggest that Hyperledger Fabric is better suited for enterprise-level applications requiring high throughput and stable performance, whereas private Ethereum faces limitations in handling large-scale transaction loads efficiently.

4.3. Performance Comparison of Hyperledger Fabric and Private Ethereum

The analysis demonstrates that Hyperledger Fabric consistently outperforms private Ethereum in terms of throughput across all smart contract functions except for the QueryUser function. However, Hyperledger Fabric’s throughput declines as the number of batch transactions and peers increase, a trend also observed in private Ethereum, particularly for 10- and 25-batch transactions when executing the CreateUser and IssueMoney functions. Notably, the TransferMoney function in private Ethereum exhibits fluctuations across all transaction batch sizes with varying peer counts. This fluctuating pattern is similarly observed in the other functions, except for CreateUser and IssueMoney with 10- and 25-batch transactions, respectively. Interestingly, private Ethereum achieves a higher throughput than Hyperledger Fabric for lower transaction volumes (10–100 transactions) when executing the QueryUser function. However, beyond this range, Hyperledger Fabric’s throughput significantly surpasses that of private Ethereum, reinforcing its scalability and efficiency for high-volume transactions.

The fluctuations in throughput for private Ethereum are attributed to the generation of blocks via the Proof of Stake consensus mechanism. In Ethereum, time is measured in slots and epochs, where each slot is 12 s and an epoch consists of 32 slots (6.4 min). Each slot provides an opportunity for a node in the validator set to propose a block. The block proposer for a slot is selected pseudo-randomly for two epochs in advance. The amount of stake each node deposits as collateral determines its likelihood of being selected as a block proposer. In each slot, the block proposer is a different node that can experience varying levels of network latency and computational overhead, including block propagation delays and transaction execution times. Consequently, this affects private Ethereum, where the proposer nodes may process transactions under different network conditions, leading to variability in the network’s throughput. In contrast, a dedicated ordering service in Hyperledger Fabric organizes transactions into blocks, effectively minimizing the throughput fluctuations caused by varying network conditions. Another factor that can lead to greater variability in the throughput of private Ethereum is the block gas limit, that is, the maximum amount of gas that all transactions inside a block are allowed to consume. The throughput of private Ethereum is directly related to the number of transactions in a block with a higher transaction count, which leads to a greater throughput. While the Geth client in private Ethereum attempts to include as many transactions as possible, the block gas limit imposes a constraint on the number of transactions that can be grouped in a block. Because the block gas limit is a dynamically adjusted parameter, private Ethereum can experience fluctuations in its throughput when the block gas limit is adjusted in response to changes in the network load.

The performance discrepancies between Hyperledger Fabric and private Ethereum can be attributed to several factors including consensus mechanisms, smart contract execution, and ledger structure [41].

• Consensus Mechanism: Private Ethereum employs the Proof of Stake (PoS) consensus algorithm, where validators are selected based on the cryptocurrency they stake as collateral. This approach involves a complex transaction-validation process that increases latency and reduces throughput. Hyperledger Fabric utilizes the Raft consensus algorithm [42], which follows a leader–follower model, where a leader is elected by ordering peers to handle transaction validation. This streamlined approach results in faster transaction processing and improved throughput compared to private Ethereum;
• Smart Contract Execution: Hyperledger Fabric leverages Docker containers to provide a lightweight and isolated environment for each smart contract. This setup prevents interference between smart contracts, enhances scalability and resource efficiency, and ensures better transaction performance. By contrast, private Ethereum does not use Docker containers, which can lead to higher resource contention, thereby affecting the overall throughput and latency;
• Ledger Model: Private Ethereum follows an account-based model, where each account maintains its balance and state, making it more efficient for querying user data. Hyperledger Fabric employs a world-state model that maintains the current state of the entire blockchain and optimizes its performance in transaction-intensive applications;
• Ordering service: Hyperledger Fabric provides a dedicated ordering service, that is, ordering nodes for ordering transactions into blocks. Ordering nodes then broadcast ordered blocks to network peers for validation and commitment, which reduces the consensus overhead on peer nodes. In contrast, private Ethereum does not have ordering nodes; that is, miners (validators) are responsible for ordering transactions into blocks, and they agree to the order through consensus. Hence, Hyperledger Fabric performs better than private Ethereum because ordering services leads to efficient use of network resources.

Overall, Hyperledger Fabric demonstrates superior throughput and lower latency across most functions except for query-based operations, where private Ethereum’s account-based ledger provides better efficiency. These findings are consistent with those reported in [36]. The findings indicate that Hyperledger Fabric is more suitable for enterprise-grade applications requiring high transaction throughput and scalability, whereas private Ethereum is better optimized for applications that focus on state-based queries and decentralized validation.

4.4. Scalability Analysis

The latency and throughput measurements in Figure 5, Figure 6, Figure 7 and Figure 8 provide insights into the scalability of Hyperledger Fabric and private Ethereum, as the number of peers increases. A common trend observed in both blockchain platforms is that latency increases with the number of peers, with private Ethereum exhibiting fluctuations, whereas throughput decreases because of the higher communication overhead and network congestion. Despite these challenges, Hyperledger Fabric generally outperforms private Ethereum in terms of throughput.

To further improve scalability, a batch size of 10,000 transactions was tested on the blockchain platforms. However, Hyperledger Fabric experienced failures after 1000 transactions owing to concurrency errors. This failure occurs when multiple transactions attempt to modify the same data concurrently, leading to consistency conflicts in the ledger. The increasing number of peers further amplifies this issue as additional communication overhead slows down transaction validation and ordering. In HF, the transaction flow involves multiple steps: clients initiate transactions that are then validated and endorsed by peer nodes before being ordered into blocks by ordering nodes. These blocks were subsequently disseminated to all peers for ledger update. As the number of peers increases, these steps contribute to the increased latency, throughput, and network congestion.

Figure 9 illustrates the scalability of private Ethereum invoke functions for 10,000 transactions. It is evident from the figure that the CreateUser function failed beyond two peers, while the IssueMoney and TransferMoney functions were executed successfully across all peer configurations. The failure of the CreateUser function can be attributed to Ethereum’s dynamic gas fee mechanism, specifically the ether base fee. Ethereum’s transaction fees consist of two primary components [43].

• Gas represents the computational power required for transaction execution;
• Gas Price—further subdivided into
  • Ether Base Fee—A dynamically determined fee that depends on network congestion;
  • Priority Fee—An additional “tip” offered by users to prioritize transaction processing.

As network congestion increases, the ether base fee also increases, making transactions more expensive. Additionally, the computational power required for the CreateUser function is significantly higher compared to IssueMoney” and TransferMoney functions, with respective computational power values of 95,374 units for CreateUser, 27,824 units for IssueMoney, and 33,425 units for TransferMoney. Owing to its high computational cost, the CreateUser function fails when the required gas exceeds the available resources, particularly at transactions 6893 (four peers), 6976 (eight peers), 5073 (12 peers), and 5656 (16 peers). This result demonstrates that highly complex smart contract functions in private Ethereum are more susceptible to gas limitations, particularly under high transaction loads.

This analysis highlights the scalability limitations of both Hyperledger Fabric and private Ethereum for high transaction volumes. Hyperledger Fabric’s concurrency errors prevented it from handling more than 1000 transactions in this experiment, whereas private Ethereum struggled with high gas fees for computationally intensive smart contracts. These findings suggest that Hyperledger Fabric is more suitable for structured enterprise-grade applications, whereas private Ethereum requires optimization to handle high transaction volumes involving complex smart contracts.

5. Limitations and Implications of the Study

This study provides valuable insights into the performance comparison between Hyperledger Fabric and private Ethereum; however, it has several limitations. Scalability constraints were observed, with Hyperledger Fabric experiencing failures beyond 1000 transactions owing to concurrency issues, thus limiting the assessment of higher transaction loads. Private Ethereum has been tested for up to 10,000 transactions; however, its performance fluctuations due to gas fees indicate challenges that require further investigation. The results are also influenced by hardware and network dependencies, meaning that real-world deployments with different computational powers, latencies, and node configurations may exhibit variations in performance. Moreover, the study was limited to private blockchain environments, and the performance of public Ethereum networks under decentralized, permissionless conditions were not analyzed. The smart contract scope was restricted to four functions (QueryUser, CreateUser, TransferMoney, and IssueMoney), excluding more complex operations such as multi-signature transactions, off-chain interactions, and dynamic contract execution. The impact of gas fee variability on private Ethereum has been noted, but a deeper analysis of adaptive gas pricing mechanisms and their effect on transaction finality has not been conducted. In addition, the research did not account for long-term performance trends, including ledger consistency, node failures, and security vulnerabilities. This study also lacks an evaluation of cross-platform integration and blockchain interoperability, which are critical for hybrid blockchain solutions. To address these limitations, future studies should expand scalability testing, evaluate additional consensus algorithms, test real-world large-scale deployments, explore complex smart contract execution, and investigate interoperability solutions to provide a more comprehensive understanding of blockchain performance across different applications.

While our study provides valuable initial insights into the comparative performance of Hyperledger Fabric and private Ethereum for a funds transfer application, the experimental setup on a single machine inherently presents limitations in fully reflecting the behavior of these platforms in real-world distributed enterprise networks. In a truly distributed environment, network latency is a significant factor. The round-trip time for messages between geographically dispersed nodes, influenced by physical distance and network congestion, substantially increases transaction confirmation latency. Our single-machine setup, with minimal interprocess communication overhead, provides an optimistic view of the latency. For instance, the observed low latencies for TransferMoney on Hyperledger Fabric might be considerably higher in a distributed scenario in which endorsements and ordering involve communication across a wide-area network.

Similarly, the throughput in a distributed network is constrained by factors such as network bandwidth and propagation delays. While our single-machine tests allowed for high transaction processing rates by minimizing communication bottlenecks, a distributed setting introduces contention for network resources. The consensus process, which requires agreement across multiple independent nodes, can become a throughput bottleneck, particularly under high transaction loads. For example, even with Raft in Hyperledger Fabric, the leader election process and log replication across distributed followers would introduce delays that are not captured in our local simulation. Scalability analysis, conducted by increasing the number of simulated peers on a single machine, does not fully replicate the challenges of horizontal scaling in a distributed system. Adding physical nodes introduces complexities related to network partitioning and data synchronization across independent ledgers, and the potential for heterogeneous hardware and software configurations. The concurrency limitations observed in Hyperledger Fabric beyond 1000 transactions on our single machine might be exacerbated in a distributed environment owing to increased contention and the complexities of maintaining data consistency across a larger, less controlled network.

To address these limitations and provide a more realistic evaluation for future research, conducting experiments on a testbed comprising multiple physical or virtual machines interconnected via a network that can simulate realistic WAN or LAN conditions is crucial. Cloud-based virtual networks (e.g., AWS and Azure) can also be employed to emulate network latency and bandwidth constraints. Deploying and benchmarking blockchain platforms on a cloud infrastructure offers a scalable and more representative environment for evaluating performance under distributed conditions and varying geographical distributions. Designing and executing benchmark workloads that more accurately reflect the transaction patterns and data access characteristics of real-world cross-border remittance systems, including varying transaction sizes and complexities, is important. Utilizing comprehensive performance monitoring tools at the operating system and blockchain platform levels in a distributed setup is crucial for identifying bottlenecks and understanding resource utilization across different nodes.

This study has significant implications for blockchain scalability, smart-contract execution, and regulatory security. The observed performance degradation in Hyperledger Fabric (owing to concurrency errors) and private Ethereum (owing to gas fee fluctuations and computational overhead) underscores the need for adaptive consensus mechanisms, optimized ledger structures, and efficient transaction processing to handle large-scale blockchain deployments. Additionally, the findings highlight the importance of interoperability, suggesting that hybrid blockchain solutions leveraging both Hyperledger Fabric and Ethereum can enhance efficiency. From a technical perspective, the failure of the CreateUser function in private Ethereum owing to high computational costs and gas fees emphasizes the necessity for optimized smart contract logic, whereas Hyperledger Fabric’s reliance on Docker offers resource efficiency but requires improvements to address concurrency bottlenecks. Furthermore, the USD 5.6 billion in cryptocurrency scam losses calls for stronger security frameworks, fraud detection mechanisms, and regulatory oversight to ensure safe and compliant blockchain adoption. Organizations must carefully balance decentralization, security, and performance to maximize blockchain’s potential in enterprise applications.

6. Conclusions

This paper presents a comparative performance analysis of Hyperledger Fabric and private Ethereum (Geth), focusing on key performance metrics such as throughput, latency, and scalability. By evaluating four core smart contract functions—QueryUser, CreateUser, TransferMoney, and IssueMoney—with varying peer configurations (2–16 peers) and transaction batch sizes (10–10,000 transactions), we provide an in-depth understanding of each platform’s efficiency in processing financial transactions. The results demonstrate that Hyperledger Fabric consistently outperforms private Ethereum in invoke functions, particularly in CreateUser, TransferMoney, and IssueMoney, where it achieves higher throughput and lower latency. However, private Ethereum performs better in query operations because its account-based ledger model enables more efficient state retrieval. Additionally, while Hyperledger Fabric effectively scales up to 1000 transactions, it encounters concurrency issues beyond this threshold, resulting in network failures. In contrast, private Ethereum successfully processes 10,000 transactions but experiences performance instability owing to gas fees and computational overhead, especially in complex smart contract functions such as CreateUser. These findings highlight the trade-offs between Hyperledger Fabric’s structured and deterministic transaction processing and private Ethereum’s flexible but resource-intensive consensus model. Hyperledger Fabric is better suited for enterprise applications requiring high transaction throughput, deterministic finality, and permissioned access, whereas private Ethereum offers better query efficiency but faces scalability constraints in write-heavy workloads. In future work, we will expand this analysis to other private blockchain frameworks, explore hybrid blockchain solutions, and conduct a comparative evaluation of public, private, and traditional database systems for financial applications.