Evaluating the Performance of a Multi-Organizational E-Government Platform on Hyperledger Fabric with Fuzzy Logic-Enhanced Multi-Channel Connectivity

ABSTRACT


INTRODUCTION
The advent of e-government has transformed governmental interaction with citizens, businesses, and other governmental bodies significantly [1,2].Despite this progress, traditional egovernment systems, often centralized, have been beset with issues such as vulnerability to data manipulation, security breaches, and inefficiencies.In response to these challenges, the evolution towards decentralized multi-organizational systems has been identified as a means to enhance the security and efficiency of e-government services [3].
In the context of Hyperledger Fabric, "multi-organization" refers to the ability of various entities to participate in a collective blockchain network.It is characterized by each organization having autonomous control over its peers, users, and assets, thus facilitating direct inter-organizational transactions, obviating the need for a central intermediary [4].The framework is underpinned by the principles of a consortium blockchain, where members of the consortium maintain individual ledger copies, and consensus on transactions is reached collectively [5].
The burgeoning demand for e-government services has precipitated an upsurge in the volume of transactions due to an increasing number of organizations and clients involved [6].The traditional single-channel connectivity model has shown limitations in handling this surge, often resulting in congestion and prolonged transaction processing times, which could also pose a single point of failure, leading to complete communication disruption in the event of failure [7].
The adoption of multiple channels is posited as a solution, offering redundancy and load distribution advantages.Should one path become compromised, others remain available to sustain communication continuity [8].This multi-channel approach also facilitates load balancing by allocating different traffic types to various channels, optimizing the system's overall performance.
The security benefits are manifold; utilizing multiple channels introduces additional layers of redundancy and resilience against network disruptions or integrity breaches through targeted attacks [9].Furthermore, the flexibility inherent in the multi-channel design allows for customization of network topologies to meet specific organizational needs and to accommodate performance fluctuations The current manuscript delineates the comparative advantages of a multi-organizational framework over traditional centralized e-government systems, with a focus on the implementation of Hyperledger Fabric.This approach heralds a paradigm shift towards enhanced security and transparency, primarily due to the decentralized nature of data management.In such systems, data is disseminated across a network of nodes, significantly impeding the efforts of adversaries seeking to manipulate or compromise data integrity [10,11].
Further, the paradigm of multi-organizational systems offers a reduction in infrastructure costs.Traditional egovernment infrastructures necessitate substantial capital outlays for hardware and software.However, within the context of Hyperledger Fabric, these costs are mitigated by a distributed ledger infrastructure that obviates the need for centralized data repositories [12].
Efficiency, throughput, and scalability of e-government processes are improved concomitantly.The decentralized fabric facilitates expedited transaction processing and obviates the requirement for intermediaries, yielding reductions in time and cost relative to analog processes, such as document verification.
The scalability of this approach is particularly noteworthy, with the capability to accommodate an expanding client base, rendering it suitable for extensive enterprise networks [13].Additionally, the architecture fosters enhanced collaboration among various governmental agencies, commercial entities, and citizens [14].Real-time data accessibility engenders a collaborative environment that is conducive to informed decision-making.
Trust is bolstered through the immutable nature of the blockchain, where data, once recorded, becomes unalterable.This attribute ensures that stakeholders are privy to reliable and accurate information, thereby reinforcing confidence in the system [15,16].
This work aims to elucidate the distinctions between multichannel and single-channel connections within a multiorganizational Hyperledger Fabric context.By establishing four distinct channels connecting six organizations, the research will demonstrate differential impacts on scalability, throughput, and latency.Utilizing fuzzy logic as a heuristic for channel selection, this study leverages the technique's proficiency in control systems and artificial intelligence to ascertain the most efficacious channel based on transactional dynamics.
The remainder of this paper is organized as follows: Section 2 surveys the pertinent literature.Section 3 provides a foundational overview of blockchain technology and Hyperledger Fabric.Section 4 delineates the proposed multiorganizational system, including the multi-channel fuzzy selector.Performance analysis, encompassing diverse tests and scenarios, is expounded in Section 5. Conclusions are drawn in Section 6.

RELATED WORK
In recent years, the confluence of blockchain technology with e-government and multi-organizational systems has garnered considerable attention within the scholarly community.Investigations in these domains have yielded insights into the potential enhancements in security, transparency, and efficiency that blockchain technology may confer upon electronic government services.Geneiatakis et al. [17] assessed the viability of blockchain-based transformations in e-government services within the European Union trade sector.The deployed system was found to satisfy transaction throughput and speed requirements.
Gao et al. [18] pioneered a multiple-channel blockchain architecture, tailored to vehicular density flux.This architecture employed channels fine-tuned for distinct vehicular densities, with channel selection predicated on optimizing transaction throughput and latency based on vehicular density and application demands.Their findings suggested superiority over extant systems in terms of performance.
The influence of electronic voting on Hyperledger Fabric's throughput and latency was scrutinized by Saeed et al. [19].Modulations of block size, timeout, and transaction rates revealed the necessity of augmenting both block size and timeout to maintain high throughput amidst high transaction volumes.
Honar Pajooh et al. [20] presented a detailed performance analysis of scalable fabrics within Hyperledger technology, conducted on an extensive shared network.They recommended a scalable architectural design that facilitates efficient and accurate monitoring of Hyperledger Fabric systems, markedly alleviating the administrative overhead.
A comprehensive performance evaluation of Hyperledger Fabric was undertaken by Guggenberger et al. [21], utilizing an augmented Distributed Ledger Performance Scan (DLPS).The results underscored Fabric's aptitude for diverse industrial applications, meeting key criteria such as resistance to manipulation, accountability, high availability, and scalability.
Swathi et al. [22] addressed the scalability issues of permissioned blockchains by integrating data science techniques.Their research, which utilized the Hyperledger Fabric framework across different transaction volumes, evidenced significant scalability improvements.
The performance of Sawtooth in cloud environments was evaluated by Shi et al. [23], providing insights into optimizing Sawtooth's functionality through adjustments to configuration parameters.Their methodology holds promise for enhancing the performance of various blockchain platforms.
Fan et al. [24] systematically analyzed the methodologies for blockchain performance analysis, resulting in several system-level optimizations and consensus mechanism advancements.These enhancements fall into two categories: analytical and empirical evaluations.
While the research by Gao et al. [18] resonates with the present study in its exploration of multiple channel techniques, the incorporation of fuzzy logic for channel selectionrecognized for its efficacy in control systems and optimization-remains unexplored in their work.
The literature also reveals that single-channel connections in blockchain systems offer suboptimal results with the expansion of the number of organizations beyond three, highlighting a critical area for further research and development.

HYPERLEDGER FABRIC PLATFORM
Blockchain is a distributed digital ledger designed for secure and immutable transaction recording.It operates as a decentralized system, enabling multiple parties to share a database, with each participant maintaining a copy.This eliminates the requirement for a central authority to govern the database, ensuring transparency, security, and accountability in transactions [25].
In a blockchain network, each transaction is verified and added to a block.The block is then linked to the previous block in a chain-like manner, forming a blockchain.After a block has been added to the blockchain, it cannot be altered, giving an immutable record of all past transactions [26].Blockchains are often used in the context of cryptocurrencies such as Bitcoin and Ethereum, but they can also be used in other industries, such as supply chain, voting systems, and healthcare, to provide secure and transparent record-keeping.
Hyperledger Fabric is open-source decentralized ledger.It offers a flexible structure that enables businesses and developers to construct and launch decentralized applications called smart contracts.These smart contracts outline the regulations and operational logic for engaging with the ledger.Within the fabric platform, these smart contracts are referred to as chaincodes, and they are coded in popular programming languages such as Go, JavaScript, or Java.They operate on every peer node within the network and are accountable for executing the transaction logic and verifying transactions [27].
Unlike public blockchains such as Bitcoin or Ethereum, which allow open participation and transaction visibility, Fabric platform is designed for private networks.This means that access to the network is restricted to authorized participants, and transaction visibility is limited to those with the necessary permissions [28].Hyperledger Fabric employs a consensus mechanism that enables multiple parties to reach agreement on the state of the ledger without relying on a single central authority.It offers a high level of flexibility, allowing developers to tailor their applications to meet specific business requirements.Key features of Hyperledger Fabric include a modular architecture for scalability and flexibility, channel partitioning for privacy and confidentiality, support for smart contracts written in multiple programming languages, identity management and access control, and a pluggable consensus mechanism for flexibility and fault tolerance [29].
In hyperledger fabric, multiple organizations can work together to create and manage a blockchain network that is secure, transparent, and scalable.When multiple organizations want to collaborate on a blockchain network in the fabric platform, they first create a consortium.A consortium is a group of organizations that agree to work together on a specific blockchain network.The consortium sets the rules for the network, including the policies for managing access to the network and the types of transactions allowed [30].The IBM Food Trust network is a real-world consortium blockchain implementation using Hyperledger Fabric.It enhances transparency and traceability in the global food supply chain.Participants from different sectors collaborate to ensure food safety.Transactions and events related to the product's journey are recorded on the blockchain, including origin, processing, packaging, and distribution details.
After establishing the consortium, each organization creates its own peer node on the fabric network.These peer nodes, associated with specific organizations, have their unique identities.When a new transaction is submitted, it is initially sent to the endorsing peers designated for that transaction based on the consortium's endorsement policy.The endorsing peers review and validate the transaction using business logic.If the transaction is valid, they create a signature and send it to the ordering service.The ordering service collects endorsed transactions, arranges them into blocks, and distributes these blocks to all channel peers for validation and storage [31].
The orderer node also ensures that the blocks are ordered sequentially and that the order is consistent across all nodes in the network.a single orderer can handle a high transaction throughput, but it can be a single point of failure for the entire network.Therefore, it may be necessary to add more orderers to distribute the load and ensure high performance.
Hyperledger fabric allows clients to interact with the network using (Software Development Kits) SDKs in different programming languages such as Node.js,Java, Python, and Go.Certificate Authority (CA) and Certificate Authority (CA) and Membership Service Provider (MSP) are two important components in hyperledger fabric that are used to secure and manage access to the network.The CA is responsible for issuing and managing digital certificates that are used to authenticate and authorize network participants.The MSP defines the roles and permissions of each participant, and it is responsible for authenticating and authorizing users to access the network.MSP ensures that only authorized users have access to this network and can take part in the consensus process.Anchor peers serve as the entry point into the network for external applications and other organizations.When a new organization joins a hyperledger fabric network, they need to know at least one peer in the network to connect to in order to send and receive transactions.

PROPOSED MULTI-CHANNEL SYSTEM DESIGN
The multiple links system in Hyperledger Fabric provides a flexible and scalable architecture for building blockchain networks.This system enables organizations to participate in multiple channels simultaneously, each with its own set of transactions and privacy settings.
In order to analyze the influence of using multi-channel in the fabric platform that connects multiple organizations, we have proposed four channels blockchain scheme as shown in Figure 1.In this scheme, different block sizes were optimized for different channels according to the different number of clients in the network.The system then will choose the appropriate channel for the transactions dynamically according to the current number of active clients.In this work, fuzzy logic rules have been used as a channel selector to select the best channel among the four.Also, three orderers have been used to maintain load balancing, and fault tolerance.Fuzzy logic is a field within mathematics and computer science.It concentrates on the process of reasoning and decision-making using information that is ambiguous or uncertain.Unlike the conventional logic, which operates on a binary system where statements are either true or false, fuzzy logic takes into accounts several levels of truth.Statements can thus be partially true or partially untrue.In order to accomplish this, fuzzy logic assigns a membership degree ranging from 0 to 1 to a certain collection [32].Fuzzy logic can be used in decision-making in the communication sector, such as appropriate channel selection from a set of channels for transferring data by taking into account many aspects, such as signal strength, available bandwidth, and the number of transactions.A fuzzy logic system, for example, may be constructed to assess each channel depending on the total number of transactions.In this situation, a set of rules will be created to specify how each channel should be evaluated.A channel with a high number of transactions, for instance, would receive a high score, whereas a channel with a low number of transactions would receive a low score [33,34].This work employs a channel selection method specifically designed to support multi-organization transactions.The selection of the most suitable channel is based on the number of active clients, which directly impacts the sending rates.For example, if each client transmits 50 transactions per second, the sending rate can range from a minimum of 50 transactions per second to a maximum of 10,000 transactions per second when the number of clients varies from 1 to 200.The system consists of four channels: ch_1, ch_2, ch_3, and ch_4, with different block sizes of 50, 100, 150, and 200 transactions per block, respectively.The fuzzy channel selector analyzes the transaction data to identify the most appropriate channel using the fuzzy logic rules outlined in Table 1.When the anchor peer sends a transaction to the fuzzy channel selector, it examines the fuzzy rules to determine the optimal channel for transmitting the transaction.

Channel selection criteria
In this work, we have made the assumption that each client transmits 50 tps, resulting in a maximum of 10,000 tps in each round when considering 200 clients in the multi-channel connectivity.This figure is equivalent to the number of transactions achieved in the single channel connection, ensuring a more accurate basis for comparison.

PERFORMANCE ANALYSIS OF THE PROPOSED MULTI-CHANNEL SYSTEM
Performance analysis in Hyperledger Fabric serves several purposes and goals.Firstly, it aids in the identification of bottlenecks and areas for optimization within the Hyperledger Fabric network.By analyzing the system's performance, developers can make informed decisions to enhance the network's efficiency and scalability.Secondly, it provides insights into the capacity of the Hyperledger Fabric network.This analysis helps determine how the network performs under various loads and transaction volumes.Such information is crucial for capacity planning, resource allocation, and scaling the network to meet future demands.Thirdly, it helps identify the limitations and constraints of the Hyperledger Fabric network.This analysis helps determine the maximum throughput, transaction latency, and resource utilization that the network can achieve.Understanding these limitations is essential for setting realistic expectations and guiding decision-making when designing and deploying applications on Hyperledger Fabric.In this work, we have utilized the Hyperledger Fabric platform v2.4 with Long Term Support (LTS) on the Linux Ubuntu v22.4 (LTS) operating system.The software was installed on a PC equipped with an Intel Core i7 1165G7 processor running at up to 4.7 GHz, accompanied by 8GB of RAM and a 512GB solid-state hard drive.For further configuration details, please refer to Table 2.
The performance of the proposed multi-channel system which connects multi-organization and its parameters including (throughput, average latency, and scalability) are verified and tested using hyperledger caliper.The caliper is a benchmarking tool designed to measure the performance of blockchain networks.It allows developers to simulate different workloads and rates to evaluate the performance of a blockchain network under different conditions.The tool generates reports that include metrics such as transaction throughput, latency, and resource utilization.
Six organizations are connected by four channels with multiple predefined clients connected to these organizations, then a series of transactions are initiated among them by the active clients.Then we compared the results of a multichannel connection with the results of a single-channel connection.

Three nodes with Raft Programming languages
Programming languages for smart contracts. Node.js

Endorsement
The peers who must give their consent before it can be added to a block.

AND database
The database that stores transaction logs for the Hyperledger Fabric.

CouchDB
Multiple experiments are performed to show the difference in the transaction throughput, and average latency between a single channel that connects six organizations and four channels which connect these six organizations.We have considered four different transaction sending rates (50 tps, 100 tps, 150 tps, 200 tps).Different ranges of clients are considered (1-25, 26-75, 76-125, and 126-200) clients.Finally, four different block sizes are assigned to those four channels (50, 100, 150, and 200) transactions per block.
In terms of throughput, the experiments conducted, as shown in Figure 2, revealed that when using a single-channel connection at a sending rate of 50 tps, as depicted in Figure 2(a) and 2(b), the throughput was reasonably acceptable with a maximum of 50 tps.However, as the number of organizations increased to six and the number of clients reached 200, the throughput experienced a significant drop to approximately 20 tps.Nonetheless, when a multi-channel connection was employed, the throughput remained acceptable, reaching around 40 tps even with the involvement of six organizations and 200 clients, effectively doubling the results.Figures 2(c), 2(d), 2(e), 2(f), 2(g), and 2(h) demonstrate that as the number of transactions increased to 100, 150, and 200 tps, with all six organizations engaged and 200 clients, the single-channel connection struggled to process a large number of client transactions.Consequently, the throughput plummeted to less than 15 tps at a sending rate of 100 tps, less than 10 tps at a sending rate of 150 tps, and approximately 8 tps at a sending rate of 200 tps.Conversely, when utilizing a multi-channel connection under the same conditions of six organizations and 200 clients, the throughput experienced a significant increase, reaching approximately 58 tps at a sending rate of 100 tps, around 70 tps at a sending rate of 150 tps, and about 90 tps at a sending rate of 200 tps.
The latencies, on the other hand, also showed significant improvement when using a multi-channel connection, as depicted in Figure 3.By considering all six organizations and 200 clients, with a sending rate of 50 tps, as shown in Figure 3(a) and 3(b), the latency in a single-channel connection was approximately 28 seconds.However, with the implementation of a multi-channel connection, the latency decreased to only about 13 seconds.When the sending rate was increased to 100 tps, as illustrated in Figure 3(c) and Figure 3(d), the latency for a single-channel connection exceeded 33 seconds.In contrast, the latency in a multi-channel connection was reduced to approximately 16 seconds.Further increasing the transaction sending rates to 150 tps, as depicted in Figure 3(e) and Figure 3(f), resulted in the latency of the single-channel connection increasing to about 45 seconds.Conversely, the latency in the multi-channel connection remained around 27 seconds.
Finally, at a sending rate of 200 tps, as shown in Figure 3(g) and Figure 3(h), the latency reached over 61 seconds in a single channel, while the multi-channel connection maintained a latency of about 33 seconds.
Table 3. presents the numerical results for throughput and latency under full system load, involving the participation of all the six organizations and 200 clients.

CONCLUSIONS
Using hyperledger fabric platform to implement egovernment services is a promising choice because it offers several benefits including: security, transparency, efficiency, and scalability [35,36].To take the highest benefit from this blockchain-based platform, the organizations of this system should be connected through multi-channel connection.
This work examined how important metrics in the hyperledger fabric platform: transaction throughput, average latency, as well as the scalability of the system, are affected when multiple organizations are connected by multi-channel instead of a single one.by changing some of the configuration parameters like transmit rate (TPS), batch size of the blockchain according to the channel, number of organizations, and number of clients in the network.many experiments have been conducted on the single channel connection and multichannel connection.And the following conclusions are reached: (1) The throughput is increased, and the average latency is decreased by more than a half in most cases when the multichannel connection was used instead of single channel connection as follows: in single channel connection, with having the number of organizations increased or the number of clients increased in the network, the throughput was decreasing from medium to high degree and the latency was increasing to high levels.Also by increasing both of the organizations to six and the number of clients to 200, the drop in the throughput was very high, especially with increasing of the sending rates to 200 tps, which was unacceptable, and the increase in latency was very high which made the system stops in some cases.But when the multi-channel connection is used, there was only a slight drop in throughput and only a slight increase in latency when one parameter was increased (number of organizations or number of clients).Also when both values were increased, the throughput was decreasing by acceptable levels and the increase in latency also was very acceptable even with high sending rates.
(2) The distribution of block sizes among four channels (ch_1, ch_2, ch_3, and ch_4) with varying sizes (50, 100, 150, and 200) respectively for each channel, combined with the utilization of the fuzzy logic technique as a channel selection method, significantly enhances the scalability of the system.This improvement allows for the addition of more clients and organizations while experiencing only a slight decrease in throughput and a minor increase in latency, compared to a single-channel connection.
The scalability of the system is achieved by minimizing the likelihood of congestion through the allocation of larger block sizes to channels with high transaction volumes and smaller block sizes to channels with low transaction volumes.Moreover, this approach enables the optimization of resource utilization for each organization by adjusting block sizes according to their available resources.Organizations with higher computer capacity can efficiently handle larger block sizes, while organizations with fewer resources can effectively process smaller block sizes that align with their processing capabilities.
(3) When using a single channel connection, the first three organizations consistently achieved satisfactory results.However, as the number of organizations increased from four to six, the throughput significantly decreased and the latency increased considerably, particularly when more clients were added to the system.This can be attributed to the increase in endorsements, which had a negative impact on both the latency and the throughput of the entire system.
Endorsements play a crucial role in achieving consensus on transactions.They serve as digital signatures from selected peers, verifying the validity and correctness of a transaction proposal before it can be committed to the ledger.While endorsements are necessary to maintain the integrity and trust of the system, an increase in the number of endorsements can negatively impact throughput and latency.Firstly, when the number of required endorsements rises, it naturally takes more time for a transaction to gather the necessary signatures, thereby reducing the overall transaction processing capacity of the system.Secondly, each additional endorsement prolongs the endorsement phase as the transaction must be sent to more peers for verification and endorsement.Consequently, the overall latency of the system increases.
On the other hand, by utilizing a multi-channel connection, endorsements can be distributed across these channels, thereby limiting the number of endorsements in each channel.This distribution effectively reduces the overall workload.
(4) Our results, as demonstrated in section 5, particularly with the multi-channel architecture, highlight Hyperledger Fabric as a flexible, high-performance, and scalable platform suitable for various future applications, such as supply chain management, financial services, and healthcare.
(5) As we have utilized the Raft consensus mechanism in this work, known for its simplicity, efficiency, and faulttolerant nature, we propose investigating the effects of alternative consensus mechanisms, such as Solo, Kafka, and Practical Byzantine Fault Tolerance (PBFT), on the implementation of Hyperledger Fabric and the broader blockchain domain.Future research endeavors could include conducting case studies to examine the experiences of organizations that have adopted diverse consensus mechanisms, administering surveys to gather data from users of various systems, and employing simulations to explore the impacts of distinct consensus mechanisms in diverse conditions.

Figure 1 .
Figure 1.Multi-channel scheme with fuzzy logic as a channel selector

Figure 2 .
Figure 2. Throughput difference between single channel connection and multi-channel connection

Figure 3 .
Figure 3. Latency difference between single channel connection and multi-channel connection

Table 1 .
Channel mapping table (best channel selection)

Table 2 .
Important configuration parameters

Table 3 .
The numerical results for throughput and latency of single channel connection and multi-channel connection under full system load