Enhancing the Efficiency of Blockchain Verification Through Resource-Weighted Node Selection

Abstract

Blockchain technology has emerged as a foundational paradigm for building decentralized, transparent, and secure systems, particularly in environments that operate without centralized authority. At the core of these systems are consensus mechanisms that ensure transaction validity and maintain trust among distributed participants. However, the efficiency of a blockchain network is strongly influenced by how verifier (or validator) nodes are selected, particularly in sharded architectures where transaction processing is distributed across multiple shards. A critical challenge in blockchain design is selecting appropriate nodes for transaction verification in a manner that is efficient, fair, and resilient to adversarial behavior, while also minimizing communication overhead. Existing approaches often rely primarily on resource availability or on the ability to create blocks, particularly in sharded blockchain architectures. Building on these ideas, this paper proposes a Resource Weighted–Block Score selection algorithm, which integrates a node’s block score with its computational resource availability to guide verifier node selection. Simulation-based evaluation demonstrates that the proposed approach significantly reduces transaction verification latency and improves overall node utilization, thereby enhancing network performance and scalability in sharded blockchain systems.

1. Introduction

With the eminent features of blockchain, it has been widely accepted by different application domains to have a secure storage of data, where the data was centrally controlled for decades. It provides a secure and reliable means of data storage, addressing the limitations of traditional systems that have centrally managed information for decades. As a distributed ledger, blockchain ensures that identical copies of data are consistently maintained across all participating nodes in the network, enabling global synchronization and trust without a centralized authority.

1.1. Categories of Blockchain Network

Blockchain technology has two categories: Permissioned and Permissionless. In a Permissioned blockchain, any node can attempt to participate in block creation, whereas in a permissionless blockchain, only trusted nodes can participate. However, success depends on satisfying the consensus protocol’s criteria. Due to the large number of nodes in a permissionless blockchain, there is a high risk of malicious activity within the network. This presents a significant challenge, as it becomes difficult to identify malicious nodes and ensure data consistency.

A Public blockchain can be accessed by anyone and perform transactions on the network without any permission, and it is a fully decentralized, transparent, and so-called permissionless blockchain, for example, Bitcoin [1] and Ethereum [2]. A Private blockchain can be accessed only by the trusted nodes and perform transactions on the network, and it is partially decentralized and not transparent, and called a Permissioned blockchain, for example, Hyperledger [3] and Corda [4]. A Consortium blockchain is managed by many organizations, is partially decentralized, and only a selected subset of nodes participates in the consensus process to validate transactions.

1.2. Consensus

In blockchain systems, consensus is the mechanism by which a distributed network of independent nodes agrees on a single, authoritative version of the ledger without relying on a central authority. In blockchain, reaching consensus in a distributed environment is a major challenge, as nodes maintain separate immutable ledgers, and techniques must be developed to ensure their consistency across all nodes. Consensus models are crucial for adding blocks to the existing blockchain among nodes attempting to add one. After the evolution of Bitcoin and its features, the importance of the backbone on which it is developed, like Blockchain, has been highlighted.

Many Blockchain systems have emerged, each with its own design and procedures (e.g., Bitcoin and Ethereum). These blockchain systems adopt different consensus mechanisms based on their design goals. For example, Bitcoin uses Proof of Work (PoW), where miners compete to solve computationally intensive puzzles to validate transactions and add new blocks. In contrast, Ethereum initially employed PoW but has transitioned to Proof of Stake (PoS), in which validators are selected based on the amount of cryptocurrency they stake in the network. Furthermore, permissioned blockchain platforms such as Hyperledger Fabric utilize consensus protocols like Practical Byzantine Fault Tolerance (PBFT) or its variants, relying on a set of trusted nodes to efficiently reach agreement.

The main goal of distributed consensus is to allow a set of nodes in a network to agree on a common value, with that value proposed by one of the nodes. This ensures reliability, fault tolerance, and security within the distributed network. A consensus algorithm determines which node is authorised to add the next block to the blockchain, and all valid transactions are stored as a chain of blocks. However, scalability remains a fundamental limitation in blockchain systems, where all validated transactions are appended to a continuously growing chain of blocks. As transaction volume increases, this architecture leads to higher latency, reduced throughput, and increased verification overhead. To overcome the above issues, sharding has emerged, in which all nodes are split into multiple groups, known as shards. Each shard is responsible for processing a specific subset of the blockchain’s transactions in parallel. To ensure that every shard operates securely and correctly, each one must reach an agreement called consensus among the nodes within a shard. While sharding improves scalability, it also introduces challenges in efficiently verifying transactions and reaching consensus within each shard.

To ensure that every shard operates securely and correctly, each one must reach an agreement called consensus among the nodes within a shard. For sharded blockchains, there is currently no widely accepted consensus model that effectively balances robust security with low computational and communication overhead. Performance is measured by considering parameters such as latency, transaction verification and validation time, throughput, and scalability [5,6,7]. Some of the authors focused on the security issues to improve the performance of the Blockchain [8,9,10].

This work focuses on efficiency within an assumed secure framework, rather than redesigning the underlying security mechanisms. The paper proposes a resource-weighted node-selection mechanism for transaction verification in the consensus process. In this approach, the responsibility for verifying transactions, creating and validating a block is assigned to the node with the highest availability of computational and network resources.

The main contributions of this paper are summarized as follows:

• The Resource Weighted–Block Score Selection Algorithm (RW-BSSA) is introduced as a theoretical consensus model for selecting transaction verifier nodes. In this model, each node receives a composite weight based on multiple resource dimensions, and the node with the highest weight is chosen to perform transaction verification, block validation, and creation.
• Performance analysis is measured using verification, validation time, and overall latency with the different block sizes for the proposed and existing algorithms.

The remaining sections of this paper are structured as follows. Section 2 reviews the various consensus algorithms in blockchain networks and sharded blockchain networks. Section 3 outlines the proposed algorithm, the Resource-Weighted Block Score Consensus Algorithm, and methodology. Section 4 discusses the performance analysis, and Section 5 concludes the work.

2. Related and Background Work

The consensus algorithm, which is the core of the blockchain, plays an important role in improving network performance. Many researchers have proposed various consensus algorithms, drawing on initial implementations such as Proof of Work, Proof of Stake, and Proof of Byzantine Fault Tolerance. The performance of the blockchain depends on the Consensus models selected. Therefore, the consensus model plays an important role in reducing the platform’s attractiveness. This section discusses the various consensus mechanisms in a blockchain network and in a Sharded blockchain network.

2.1. Various Consensus Mechanisms in a Blockchain Network

In the literature, several Proof-based consensus algorithms have emerged with distinct ideas. The initially and widely used approach in Bitcoin is Proof of Work, proposed by Nakamoto  [1], which is used in a public blockchain where miners must solve a puzzle and have it validated by the remaining miners before adding the block to the blockchain. This mechanism uses the Merkle tree to store data efficiently, but requires high computational power and performs poorly. The Peercoin cryptocurrency King and Nadal [11] uses a Proof of Stake (PoS) consensus mechanism in which all participating nodes hold coins in wallets, and the opportunity to add a block to the existing blockchain is given to the node that holds the most coins for the duration of holding them. If the node holds the coins for a long time, it receives an incentive. When compared with PoW, PoS concentrates on the number of coins instead of the computing power required to solve the puzzle in PoW. Zhuang et al. [12] introduced Proof of Reputation (PoR) that employs a three-step consensus mechanism in each round: reputation-based consensus, reputation updating, and leader selection and block building. The node with the highest reputation rating is chosen as the leader, and the leader is responsible for creating blocks.

In the PBFT consensus process, upon receiving a client request, the master node promptly initiates a consensus. When the number of requests surpasses the server’s capacity, transactions queue up for consensus processing. Castro and Liskov [13] introduced an optimization approach for batch request handling in PBFT. This scheme assigns a sequence number to a batch of requests, streamlining the batch-starting protocol and reducing consensus protocol overhead during high loads. Employing a sliding window mechanism limits parallel transaction processing. As the consensus proceeds, the window advances, enabling queued request processing. However, this solution predefines transaction sizes, limiting flexibility based on system load, also known as batch transaction count. Additionally, it assigns a serial number to a batch without specifying the process for handling failed verification within a batch. Sanober and Anwar [14] introduced a consensus mechanism named Round Robin Proof of Stake (RRPoS) that enhances the performance in terms of security by allowing only valid nodes to participate in the block creation and providing a chance to every valid node to create the block in a round robin mode. However, this method focused on the minimum stake and the round robin method, but not on the resource availability of nodes.

2.2. Various Consensus Mechanisms in a Sharded Blockchain Network

In past years, the entire focus was on consensus for the blockchain network, but scaling has now been achieved using the sharding concept. Nowadays, research has focused on the consensus within a part of a blockchain known as a shard, i.e., where the entire blockchain is divided into different shards. This concept enhances the efficiency of blockchain in terms of throughput and resource utilization. Vote-based or long-chain consensus does not provide efficiency in sharded blockchains.

Xu et al. [15] proposed a new framework that is based on the Multiple Winners Proof of Work (MWPoW) protocol and the vote-based protocol by resolving progress-hindering attacks, and which can tolerate up to f < n/2 adversary nodes. The concept of sharding had mitigated the challenge of the scalability issue, but still, some challenges need to be resolved, such as addressing the problems regarding consensus in the shrinking of the shard and double cross-shard transactions with the increase in shards. To obtain the efficiency of the blockchain in terms of scalability, there should be a large number of tiny shards to achieve parallelism. The author Li et al. [16] resolved one of the challenges in sharding, such as the presence of malicious nodes in the shard. Li et al. [17] proposed a blockchain sharding system known as Cochain that configures the tiny shards securely for enhanced concurrency. This system considers the presence of malicious shards in the network, and the proposed concept is to monitor each shard with the other shards in the network. The efficiency of the blockchain is achieved by the cross-shard consensus. During the process, if any faulty shard is found, that is removed from the network. Tao et al. [10] proposed an approach known as CGSTD, which addresses the security issue within a shard, as the number of nodes is lower, the higher the risk of security. So, if the number of nodes is increased, obviously, the consensus delay is increased, which directly decreases the efficiency of the blockchain. The optimal group is formed based on the transmission delay from each shard. The coordination cost increases and which is not suitable for large-scale transactions. Lu et al. [18] proposed a credit-based consensus IShard to handle a large number of transactions within a shard and focused on scalability in a consortium blockchain. Kumar et al. [19] introduces an innovative consensus algorithm, Shardcon, for public blockchains that organize miners into shards based on their performance. Following the sharding process, the top-performing miner from each shard is selected to form a Super Shard. From this Super Shard, one miner is randomly chosen to mine the next block in the blockchain network. Each miner maintains a record of performance history to facilitate sharding, and periodic re-sharding is implemented to ensure fairness. The proposed performance-based sharding consensus algorithm addresses the scalability challenges faced by public blockchains. Additionally, it promotes fairness, prevents miner starvation, enhances trust among miners, and improves the overall efficiency of the blockchain network.

Zhang and Huang [20] introduced FPoR, a consensus mechanism for permissionless blockchains that combines multiple parameters to increase blockchain efficiency. This protocol includes Collateral to choose the candidate nodes. The one among the candidate pool based on reputation is randomly selected to propose a new block, PBFT is used to verify and approve the addition of a new block, and the block is propagated in the network. Liu et al. [21] proposed Kronos, which offers a flexible and secure consensus model tailored for sharded blockchain systems. It focuses on achieving security, atomic transaction execution, and minimal overhead, particularly for cross-shard transactions, which are traditionally challenging to handle efficiently. This works in any network setting, such as asynchronous, partially synchronous, and synchronous networks, with the following techniques speeding Dumbo and Hotstuff. Wu et al. [22] proposed a dynamic resource allocation for endorsement peers or nodes in Hyperledger. This uses the CRITIC algorithm to calculate the weights of the resources allocated to the endorsement peers. The PROMETHEE algorithm is used to prioritize nodes for validating transactions. The performance is improved by implementing the above algorithms in blockchain.

Zhang et al. [23] introduces a consensus mechanism based on the trust values of the nodes which in turn are divided into three major groups for packing the transactions and validating the transactions. One accounting node is chosen as the active node to pack transactions into a block from the accounting nodes in the accounting node group. However, it introduces additional computational and communication overhead, which can be particularly challenging for nodes with limited physical resources during trust value computation.

Therefore, to address the limitations of the above studies, this research adopts a hybrid selection approach that jointly considers node resource availability and historical block performance, enabling more efficient verifier selection. However, a full formal security proof, comprehensive Byzantine fault tolerance analysis, and real-world deployment evaluation are beyond the scope of this simulation-based study and are left for future work.

3. Resource Weighted–Block Score Selection Algorithm (RW-BSSA)

The main focus is to develop a consensus mechanism based solely on the availability of node resources within a shard. This section discusses how a block is created by the high-availability nodes, and consensus is one of the core concepts for improving blockchain performance.

In this proposed consensus mechanism, a sharded blockchain is considered with a group of nodes such as $n_1,n_2,\dots ,n_k$. To complete the consensus process, the nodes with the highest available resources are selected for the creation of blocks. As every node consists of some resources such as CPU, RAM and Network bandwidth, the availability of current resources A(n) are calculated by finding the difference between the total number of resources T(n) and current consumed resources C(n). That is represented by $A\left(n\right)=T\left(n\right)-C\left(n\right)$. After calculating available resources based on their availability, the highest availability node is given chance for creation of block. If there are multiple nodes with the same availability of resources, then the Block score $S\left(n\right)$ is calculated among them. Block score means the number of successful blocks had created by that particular node in the past. If the block score is the same for multiple nodes, then the nodes follow a round robin fashion for the creation of blocks. The complete node-selection procedure is presented in Algorithm 1.

To ensure optimal performance, we conducted simulations across all possible combinations of resource weight values. The results indicated that the selected configuration $w_{CPU}=0.4$, $w_{RAM}=0.3$, and $w_{Network}=0.3$, consistently produced better results compared to other combinations. Accordingly, these values have been adopted. These weights are system-configurable parameters that can be adjusted based on the resource characteristics of the target deployment environment. According to these values, Node Score $N\left(n\right)$ is calculated for every node as

$$N\left(n\right)=w_{CPU}·CPU\left(n\right)+w_{RAM}·RAM\left(n\right)+w_{Network}·Network\left(n\right).$$

Node that scores the highest Node score value is selected for block creation. Before assigning, the algorithm checks for the other parameters such as limited time for block creation L and processing time frame t to complete block formation. If the particular node meets both the parameters then it is selected for block creation or the next highest node is validated with the parameters.

Algorithm 1: Blockchain consensus algorithm for selecting the node for block creation

4. Performance Analysis

This section presents a detailed simulation environment, analysis of the verification time, validation time, and overall latency distributions across the two consensus methods: Proposed and RRPOS, evaluated under different block size scenarios. Boxplots visually compare the statistical behavior of each metric, showing median, quartiles, and outliers across multiple simulation runs.

4.1. Simulation Environment

To evaluate the effectiveness and performance of the proposed consensus mechanism, we simulated the Blockchain system using a discrete-event simulation framework (SimPy) module in Python. The proposed technique evaluates the verification time, validation time and latency analysis with different Block size ranges for the proposed consensus (RW-BSSA) and the existing method (RRPOS). RRPoS was selected as the baseline due to its deterministic, unbiased validator scheduling and minimal complexity. Its round-robin fashion ensures equal participation, making it a best benchmark for fairness evaluation. This allows performance differences to be attributed directly to the Resource-Weighted Block Score (RWBS) algorithm without confounding factors. The simulation parameters and environment configurations used in the experiments are summarized in Table 1.

Table 1. Simulation Environment Configuration.

Parameter	Specification
Simulation Framework	Discrete-event simulation using SimPy (Python 3.10)
Hardware	Intel Core i7-1355U, 32 GB RAM
Block Size Range	4–32
Consensus Mechanisms	RRPoS and Proposed Model
Performance Metrics	Latency, Verification Time, Validation Time

4.2. Verification Time Analysis

Figure 1 and Figure 2 represents the verification time with 10 and 20 nodes per shard, as the block size increases, the verification time also increases for both the existing and proposed algorithms. The proposed method shows a slightly lower median and a reduced spread compared to RRPOS, due to node selection based on available resources. As the block size grows, the outliers become more prominent due to resource limitations in some simulations.

Figure 1. Verification time for different block sizes (10 nodes/shard).

Figure 2. Verification time for different block sizes (20 nodes/shard).

Across the 5–10 block size range, the proposed method consistently achieves lower verification times than RRPOS. The median verification time of the proposed scheme is approximately 5–8% lower than that of RRPOS, indicating early efficiency gains under lightweight workloads. As the block size increases to 16, the improvement becomes more pronounced, with reductions of approximately 8–12% in median verification time. A similar trend is evident across the broader 5–20 block-size range, where the proposed method consistently outperforms RRPOS in median verification time. The median verification time increases with block size, indicating higher computational demands for processing larger blocks for both RRPOS and the Proposed mechanisms. However, the proposed method exhibits a lower median and a more compact distribution, indicating improved efficiency and stability in verification performance.

4.3. Validation Time Analysis

As shown in Figure 3 and Figure 4, represents the validation time with 10 and 20 nodes per shard, validation time increases along with the increase in the block size, reflecting the added computational workload for larger volumes of data. The Proposed method maintains a lower median and reduced variance, demonstrating that selecting nodes with higher resource availability ensures stable, predictable performance. The RRPOS approach occasionally produces higher outliers, which can be attributed to the resource imbalance inherent in its round-robin scheduling strategy.

Figure 3. Validation time for different block sizes (10 nodes/shard).

Figure 4. Validation time for different block sizes (20 nodes/shard).

As the block size increases, both the median and the variability of validation times rise, reflecting the additional computational effort required. The Proposed approach consistently achieves lower median values and a narrower interquartile range, highlighting its effectiveness in utilizing nodes with greater computational capacity. The existing method suffers from greater dispersion and more frequent extreme values, particularly as the system scales, indicating the impact of using less-optimal nodes for validation.

4.4. Latency Analysis

Figure 5 and Figure 6 show the latency analysis for 10 and 20 nodes per shard, respectively, and the overall latency, which is the comprehensive metric comprising the durations of verification, validation, processing, and transmission. The observed latency distribution exhibits a consistent increase with block size. However, the Proposed method maintains a notably tighter distribution across all block sizes, signifying improved stability and predictability. Conversely, the RRPOS approach shows a broader spread, with more frequent high-latency outliers, particularly at larger block sizes, which may adversely affect system responsiveness under high network load. As the block size increases, latency becomes a decisive factor in determining the upper bound on the transaction finality speed.

Figure 5. Total latency for different block sizes (10 nodes/shard).

Figure 6. Total latency for different block sizes (20 nodes/shard).

The results are averaged across all shard configurations and block sizes to provide an overall performance comparison between RRPOS and RW-BSA. Table 2 presents the average verification time, validation time, and overall latency for both methods. As shown, RW-BSA yields slightly lower values across all three metrics than RRPOS. Specifically, the average verification time decreases from 0.7786 s to 0.7638 s, with validation time and overall latency also marginally reduced.

Table 2. Performance Comparison between RRPOS and RW-BSA.

Method	RRPOS Avg (s)	RW-BSA Avg (s)
Verification time	0.7786 ± 0.5727	0.7638 ± 0.5613
Validation time	0.4751 ± 0.3501	0.4721 ± 0.3473
Latency	1.2750 ± 0.9386	1.2566 ± 0.9239

5. Conclusions

Blockchain enables the development of decentralized, transparent, and secure systems that do not rely on a central authority. Consensus mechanisms ensure transaction validity and foster trust throughout the network. This paper examines the impact of verifier node selection on network performance and security. A novel consensus algorithm, RW-BSSA, is introduced, which selects nodes for block creation based on available resources. Assigning block creation to the node with the greatest resources reduces average processing time across various block sizes. Simulation results indicate that RW-BSSA outperforms RRPOS in verification and validation time and overall latency. Specifically, the proposed method reduces verification time by approximately 5–13% relative to RRPOS across all tested block sizes. These performance gains remain consistent as block size increases, demonstrating the scalability of the approach.

In our future work, we will extend the current framework through formal security analysis and comprehensive evaluation under Byzantine fault scenarios, including adversarially adaptive environments and provable resilience under dynamic attack models. In addition, the model will be extended to support parallel chains and multi-network environments, with a focus on consistency and coordination across concurrent executions to enhance scalability and applicability.