Computer Standards & Interfaces 97 (2026) 104123 Contents lists available at ScienceDirect Computer Standards & Interfaces journal homepage: www.elsevier.com/locate/csi V-Bridge: A dynamic cross-shard blockchain protocol based on off-chain payment channel Xueting Huang a , Xiangwei Meng a,c,b , Kai Zhang a,c,b , Ce Yang a,c,b , Wei Liang a,c,b ,∗, Kuan-Ching Li a,c,b ,∗ a College of Computer Science and Engineering, Hunan University of Science and Technology, XiangTan 411201, China b Hunan University of Science and Technology Sanya Research Institute, SanYa 572000, China c Hunan Key Laboratory for Service Computing and Novel Software Technology, XiangTan 411201, China ARTICLE INFO ABSTRACT Keywords: Sharding technology effectively improves system throughput by distributing the blockchain transaction Blockchain load to multiple shards for parallel processing, and it is the core solution to the scalability problem of Sharding blockchain. However, as the number of shards increases, the frequency of cross-shard transactions increases Cross-shard significantly, leading to increased communication and computational overhead, transaction delays, uneven Off-chain payment channel resource allocation, and load imbalance, which becomes a key bottleneck for performance expansion. To this end, this article proposes the cross-shard transaction protocol V-Bridge, which draws on the concept of off-chain payment channels to establish distributed virtual fund channels between Trustors in different shards, convert cross-shard transactions into off-chain transactions and realize the logical flow of funds. To further enhance cross-shard transaction performance, our V-Bridge integrates an intelligent sharding adjustment mechanism, and a cross-shard optimized critical path protection algorithm (CSOCPPA) to dynamically balance shard loads, alleviate resource allocation issues, and minimize performance bottlenecks. Experimental results show that compared with existing state-of-the-art protocols, our proposed V-Bridge’s average throughput is increased by 26% to 46%, and transaction delays are reduced by 15% to 24%. 1. Introduction overhead, introduces complex synchronization issues, and creates po- tential performance bottlenecks—diminishing the efficiency gains of Blockchain [1,2], as a decentralized, transparent, and tamper-proof sharding [14]. technology, has great potential in various fields such as privacy protec- Various cross-shard transaction protocols have been proposed to address these challenges to enhance processing efficiency and reduce tion, medical applications, and the Internet of Things [3–5]. In cross- synchronization overhead. For instance, Monoxide [15] employs an border payments, for example, it offers an alternative to traditional asynchronous consensus mechanism to minimize inter-shard waiting banking systems, enabling fast and cost-effective transactions [6]. How- times. However, while transactions are processed in parallel, the sys- ever, blockchain systems face significant scalability challenges during tem struggles to ensure state consistency and communication over- high transaction volumes [7–9]. For instance, Ethereum [10] often ex- head remains significant in large-scale sharding environments. Broker- periences network congestion during peak usage, leading to transaction Chain [16] introduces brokers to coordinate cross-shard transaction delays and increased GAS fees. Addressing scalability has become a processing, but its approach appears impractical in real-world appli- critical priority. Sharding [11,12] technology offers a promising solu- cations. The system relies heavily on securing sufficient intermediary tion by partitioning the blockchain network into independent shards, nodes to stabilize cross-shard transactions. However, such nodes are enabling parallel transaction processing and faster confirmations [13]. challenging to acquire in decentralized networks, especially under However, the benefits of sharding are hindered by challenges posed by heavy transaction loads. This reliance amplifies dependence on individ- cross-shard transactions. These transactions require data synchroniza- ual nodes, increasing the risk of centralization and limiting scalability. tion and state validation across shards, which increases communication Consequently, BrokerChain [16] struggles to address complex scenarios ∗ Correspondence to: College of Computer Science and Engineering, Hunan University of Science and Technology, No. 2 Taoyuan Road, Yuhu District, Xiangtan 411201, Hunan Province, China. E-mail addresses: wliang@hnust.edu.cn (W. Liang), aliric@hnust.edu.cn (K.-C. Li). https://doi.org/10.1016/j.csi.2025.104123 Received 17 December 2024; Received in revised form 27 October 2025; Accepted 26 December 2025 Available online 31 December 2025 0920-5489/© 2026 Elsevier B.V. All rights are reserved, including those for text and data mining, AI training, and similar technologies. X. Huang et al. Computer Standards & Interfaces 97 (2026) 104123 involving dynamic node allocation and shard optimization, exposing 2. Related work key weaknesses in its design’s practicality and adaptability. To ad- dress shard distribution, BrokerChain [16] employs epoch, where the 2.1. Cross-shard transaction Metis algorithm [17] optimizes user account partitioning to prevent related transactions from being spread across shards in subsequent To address the challenges of cross-shard transactions, a variety of protocols have been developed [22–24], with a focus on enhanc- epochs. This strategy is similarly adopted in protocols like X-Shard [18]. ing performance, scalability, and consistency. Monoxide [15] uses an However, in practice, the Metis algorithm [17] suffers from partition asynchronous consensus mechanism and temporary payment chan- imbalance and fragmentation of critical nodes. This fragmentation can nels to decompose cross-shard transactions into intra-shard operations, distribute high-frequency transaction paths across multiple shards, in- boosting throughput. However, the complexity of state synchronization creasing cross-shard communication overhead and processing latency. and consistency verification across shards increases communication Ultimately, this undermines system performance and scalability. In con- overhead, impacting large-scale system performance. OmniLedger [25] clusion, significant challenges remain while both BrokerChain [16] and employs the Atomix protocol to ensure the atomicity of cross-shard X-Shard [18] offer innovative approaches to cross-shard transaction transactions. Through a client-driven two-phase commit process, it optimization. Improvements are needed in node allocation, security freezes the UTXO of the input shard and then releases the UTXO management, and performance optimization to realize the full potential of the output shard, maintaining consistent transaction state updates. of cross-shard systems. RapidChain [26] improves system throughput by reducing commu- To address the shortcomings of existing cross-shard transaction nication rounds through parallel verification. However, it struggles with performance bottlenecks when handling cross-shard transactions protocols, we propose the V-Bridge, a novel solution leveraging the with long dependency chains due to prolonged waiting times. Bro- off-chain transaction model of bidirectional payment channels. The V- kerChain [16] simplifies cross-shard communication by introducing Bridge facilitates logical fund interactions across shards by constructing third-party intermediary nodes that convert cross-shard transactions virtual channels. To reduce reliance on single nodes in decentralized into intra-shard transactions. However, this approach introduces risks environments, the V-Bridge introduces trustee groups as relay nodes related to decentralization and trust management. Pyramid [27] im- within each shard. These groups, supported by a flexible and ro- plements a hierarchical sharding protocol where BridgeShard processes bust management framework, ensure seamless cross-shard transactions transactions across multiple shards in a single consistency round, sig- while distributing the load effectively. Virtual fund channels between nificantly reducing confirmation latency. However, it increases system trustees are settled on-chain only upon closure, which significantly management complexity. CHERUBIM [28] leverages pipeline process- reduces on-chain synchronization overhead and enhances transaction ing based on the 2PC protocol to enhance cross-shard transaction efficiency. Additionally, the V-Bridge incorporates an intelligent shard throughput but falls short in mitigating long transaction latencies. adjustment mechanism based on a Consistent Hashing Ring [19,20] Building on these advancements, we propose the V-Bridge protocol, and GINI coefficients [21], integrated with the Cross-Shard Optimized offering an efficient and flexible solution to the challenges of cross- shard transactions. V-Bridge supports seamless operation in complex Critical Path Protection Algorithm (CSOCPPA). This combination im- transaction scenarios, ensuring the efficient functioning of blockchain proves the coordination of dynamic shard adjustments and cross-shard systems. transactions, further enhancing system performance. The main contributions of this article are summarized as follows: 2.2. Payment channel • Blockchain Sharding Protocol Based on Virtual Fund Payment Channels Payment channels are off-chain mechanisms that improve blockchain (V-Bridge): We propose a virtual channel solution inspired by off- performance by optimizing transaction processing, reducing network chain payment channels to facilitate cross-shard transactions. This load, delays, and fees. Users lock funds via smart contracts, enabling approach minimizes direct interactions between shards, significantly multiple off-chain transactions without recording each one on the reducing communication overhead and transaction delays. Conse- blockchain. The mechanism defines rules for initial fund allocation and quently, V-Bridge enhances system throughput and overall perfor- status updates. Users can update the status off-chain, with each update mance. verified by signed certificates from both parties. When the channel closes, the final status is submitted to the blockchain to settle the fund • Cross-shard Optimization and Dynamic Shard Adjustment Mechanism: distribution. By minimizing on-chain interactions, payment channels The V-Bridge Protocol integrates the Cross-Shard Optimized Crit- reduce blockchain resource use. A key feature is the dynamic adjustment ical Path Protection Algorithm (CSOCPPA) and a dynamic shard of participant balances while maintaining total fund immutability. This adjustment mechanism to improve system performance. CSOCPPA improves transaction efficiency and ensures security. Payment channels enhances the Metis algorithm [17] for better account allocation, re- leverage cryptographic tools like digital signatures to ensure transaction ducing cross-shard assignments. The dynamic adjustment mechanism integrity and reduce the costs and delays of on-chain operations, uses Consistent Hashing and GINI coefficient analysis to optimize especially during congestion. shard splitting and merging for balanced load distribution. In recent years, payment channels have been widely used in many • System Implementation: We implemented the V-Bridge protocol and fields, such as privacy protection [29], network scalability [30] and evaluated its performance on Ubuntu 20.04.1. Experimental results cross-chain interoperability [31], Internet of Things expansion [32] demonstrate that, compared to BrokerChain and X-Shard, V-Bridge and other directions. In the sharding architecture of this article, the outperforms in terms of throughput, transaction confirmation la- off-chain payment channel also provides an efficient solution for pro- tency, workload balancing, and consensus success rate under identical cessing cross-shard transactions. By transferring transactions between shards to off-chain, payment channels effectively reduce the complexity conditions. of cross-shard communications, significantly improve the throughput and performance of the sharding system, and provide important support The remainder of this paper is organized as follows. Section 2 for the further development of sharding technology. reviews related work. Section 3 presents an overview of the V-Bridge system. Section 4 details the protocol design. Section 5 introduces cross- 3. Overview shard optimization and dynamic shard adjustment. Section 6 provides a security analysis. Section 7 reports experimental results, and Section 8 This section introduces the V-Bridge system model and its workflow, concludes the paper. followed by the deployment process of Trustor. 2 X. Huang et al. Computer Standards & Interfaces 97 (2026) 104123 3.1. System architecture and workflow 3.2. Trustor deployment Similar to BrokerChain [16], V-Bridge is also executed in epoch, and In our V-Bridge, we introduce the concept of the Trustor. Before V-Bridge includes two types of shards: settlement and account shards, delving into the specifics of the Trustor, it is essential to understand of which there are S settlement shards and 1 status shard. The specific the concept of a trust group. A trust group consists of nodes selected by definitions are as follows: the system to facilitate the transfer of funds across shards. These nodes provide liquidity through staking or contributing resources like funds • Settle shard (S-Shard): Generates transaction blocks by packaging or computing power, creating a bridge for cross-shard transactions. transactions and achieves intra-shard consistency at the beginning of In return, they earn commissions as incentives. By ensuring sufficient each epoch. liquidity, these nodes establish virtual transaction channels between • Account Shard (A-shard): A-shard optimizes account allocation based shards, enabling successful cross-shard payments for users both inside on the user’s transaction history data to alleviate the problem of load and outside the shards. The node performing this critical role is the imbalance in the shard system. During the system startup phase, A- Trustor. The process for participating in system transactions involves shard collects user transaction data from S-shard, uses this data to the following key steps: build a user transaction network, and optimizes user status distribu- Step1 Trustor application: At the start of each epoch, nodes from tion through the CSOCPPA. After the optimization, A-shard generates various shards may apply to serve as Trustors by submitting collateral, a status block and sends it to S-shard to update the user account status undergoing a credit assessment (excluding low-reputation nodes with distribution. poor historical performance), and providing proof of sufficient liquidity Other Settings: We adopt a Byzantine fault-tolerant adversarial model to meet the minimum funding threshold. [33], assuming the presence of malicious actors capable of compromis- Step2 Qualification verification: The system assesses applicant ing specific shard nodes and performing arbitrary dishonest actions, nodes based on their collateral, computational capacity, credit score, such as data tampering, delayed messaging, or refusing to submit re- and liquidity. Each node is assigned an initial credit score that re- quired information. These adversaries are slow-adaptive, meaning they flects its resources and historical performance. The system prioritizes cannot frequently rotate the compromised nodes within a single epoch. selecting Trustors from nodes with higher credit scores. However, to The system assumes a partially synchronous communication model, mitigate the risk of excessive centralization, a probabilistic selection where messages may experience delays but are guaranteed eventual mechanism is employed. Specifically, high-reputation nodes (Top 30%) delivery. are assigned a 60% probability of selection, while medium-reputation Building upon this adversarial model, the V-Bridge mechanism is nodes (Top 30%–60%) are allocated a 40% probability. Even if there designed to ensure resilience against such malicious actors. The system are enough high-reputation candidates, there remains a 40% chance architecture is structured into three key layers: the Network Initializa- of selecting a medium-reputation node, thus distributing power within tion Layer, the Account State Reconstruction Layer, and the Transaction the system and reducing centralization risks. In the event that there Processing and Consensus Layer. are insufficient qualified candidates, the system will randomly select additional well-performing nodes to supplement the trust set. The • Network Initialization Layer (NIL): This layer is the core foundation of trusted set is dynamically maintained: nodes with significantly reduced V-Bridge and is responsible for the reasonable sharding of nodes and liquidity or credit scores are automatically removed. transaction loads in the system to form multiple independent sharding Step3 Leader election: For each shard’s trust set, the system des- structures. ignates the Trustor node with the highest credit score as the leader, • Transaction Processing and Consensus Layer (TPCL): According to the with the leader’s term being tied to the current epoch. The leader is distribution of accounts and transactions, this layer optimizes and re- not allowed to serve consecutive terms in two consecutive epochs. Each constructs the account status within the shard through the CSOCPPA, Trustor generates a unique identifier 𝑇id , defined as: generates a dynamic state reconfiguration plan, and improves system performance. 𝑇id = hash(ShardID ∥ Rep ∥ Deposit ∥ Value ∥ Relate) • Account State Reconstruction Layer (ASRL): This layer is responsible where Rep is the credit score, Deposit is the collateral, Value is the for transaction verification and consensus, ensuring the security and remaining balance, Relate indicates the cross-shard relationships. consistency of all transactions. The Relate variable is defined as: { Based on the above architecture, each layer works together to real- 0 if no channel with other shards; Relate = ize each epoch process from node identity authentication to transaction ShardID if a channel with another shard exists. processing. As shown in Fig. 1, the workflow can be divided into the following five steps: Each 𝑇id is stored within the shard. The leader can query these 𝑇id Step1 PoW verification: Nodes verify their identity using PoW [34] values to execute cross-shard transactions and select the most suitable (via public key and IP) to prevent Sybil attacks. Verified nodes are executor from the trusted set. evenly distributed across shards in a round-robin fashion. Step2 Select Trustor: After shard assignment, nodes apply to serve 4. V-Bridge protocol design as Trustors in this epoch. Each shard forms a trust group to support subsequent transactions. In this section, we introduced the core modules of the V-Brige pro- Step3 Transaction consensus: The settlement shard validates tocol, including the new Merkle tree, the solution of cross-shard trans- transactions and adds them to the pool. Consensus is reached via actions based on virtual payment channels, and the final transaction PBFT [33]. For cross-shard cases, virtual channels (Section 4.2) manage settlement. interactions; failed verifications trigger rollback (Section 4.3). Step4 State optimization: The CSOCPPA algorithm (Section 5.1) 4.1. New Merkle Patricia Tree adjusts account placement based on access patterns. A consensus- derived state block is distributed to shards for the next epoch. To support efficient user state queries and cross-shard transaction Step5 Epoch sharding: In the new epoch, PBFT [33] guides account routing, we design a shard management framework that combines a migration and transaction routing based on the latest state diagram, Consistent Hashing Ring with a New Merkle Patricia Tree (NMPT) (see ensuring consistency and performance. Fig. 2). 3 X. Huang et al. Computer Standards & Interfaces 97 (2026) 104123 Fig. 1. Workflow diagram of V-Bridge for an Epoch. Fig. 2. The data structure and mapping of NMPT. When a user initiates a query or transaction request that requires the first shard whose assigned range contains 𝐻𝑢 , thereby determining locating their associated shard, the system first computes the user’s the user’s query shard. Each shard maintains a uniquely assigned hash hash value 𝐻𝑢 = Hash(ID𝑢 ) using the SHA-256 algorithm [35]. It then interval and dynamically records the user–shard mappings within that performs a clockwise search on the consistent hash ring [19] to identify range to support efficient user lookup and cross-shard routing. 4 X. Huang et al. Computer Standards & Interfaces 97 (2026) 104123 Fig. 3. Example of cross-shard Tx processing. The NMPT serves as the core of state storage and improves on the This message is signed by Alice with Sig𝐴 and sent to the leader of the traditional Merkle Patricia Tree by: trust group in her shard, denoted as 𝑀leader . Upon receiving the message, the leader verifies whether Alice’s bal- • Separating ordinary and Trustor user states into independent ance is sufficient to cover the transaction fee and ensures no duplicate branches; transactions with the same timestamp, thereby preventing double- • Embedding a Shard Range module to explicitly encode shard spending. Once verification is complete, the leader selects 𝑇 𝑟𝑢𝑠𝑡𝑜𝑟𝑀 positions on the hash ring; with sufficient financial reserves based on the transaction requirements • Enabling parallel updates, fast redirection, and reduced state and then sends the verification results and the 𝑇id information of the conflicts. 𝑇 𝑟𝑢𝑠𝑡𝑜𝑟𝑀 responsible for this transaction to other Trustor nodes for confirmation. Suppose 2/3 of the Trustors agree to the transaction. These enhancements ensure consistency and rapid verification in In that case, the leader will record the transaction, send 𝑇 𝑟𝑢𝑠𝑡𝑜𝑟𝑀 ’s dynamic, cross-shard environments. The usage of this framework in information to Alice for confirmation, and then 𝑇 𝑟𝑢𝑠𝑡𝑜𝑟𝑀 will begin transaction execution is elaborated in the next section. processing the transaction. Step2 Trustor coordination and locking: When the 𝑇 𝑟𝑢𝑠𝑡𝑜𝑟𝑀 4.2. The specific implementation process of V-brige protocol receives the transaction request 𝑇 𝑋request , it extracts the recipient Bob’s user ID and uses a Hash Ring to locate his shard (e.g., Shard3). It then generates and sends a query message: We establish a channel contract (ChannelContract) between two {{ } } shards via a Trustor, converting most transactions into intra-shard op- 𝑄𝑀 = 𝑇 𝑋request , Inform, Sig𝑀 erations. Fund transfers between channel participants occur off-chain, with on-chain interactions limited to channel creation and final set- Upon receiving 𝑄𝑀 , Shard3 verifies the transaction and retrieves Al- tlement. This approach significantly reduces the on-chain overhead of ice’s account by checking her signature. It consults the Dynamic Map- ping Table to determine the shard locations of both Alice and Bob cross-shard transactions and enhances system performance. The proto- (e.g., Shard1 and Shard2), then forwards the query to Shard2 and col involves four main steps: Initial Fund Locking, Trustor Coordination broadcasts the involved shard locations. and Locking, 𝑇 𝑟𝑢𝑠𝑡𝑜𝑟𝑁 Payment Execution, and HTLC (Hashed Time- Afterward, 𝑇 𝑋request is submitted to Shard1 for verification. Simul- lock Contract) Unlocking [36,37]. To illustrate the protocol’s operation, taneously, the leader node 𝑁leader in Shard2 analyzes the transaction we present a cross-shard transaction case that demonstrates how it and trust-related metrics to select a 𝑇 𝑟𝑢𝑠𝑡𝑜𝑟𝑁 to handle execution. ensures the seamless completion of cross-shard transactions (see Fig. This proactive selection validates the transaction without waiting for 3). Alice, a user in Shard1, wants to initiate a cross-shard transaction Shard1’s response, reducing delay. to transfer an amount 𝑣 to Bob, a user in Shard2. The process unfolds The selected 𝑇 𝑟𝑢𝑠𝑡𝑜𝑟𝑁 in Shard2 extracts 𝑇 𝑟𝑢𝑠𝑡𝑜𝑟𝑀 ’s address from as follows: Sig𝑀 and deploys a contract 𝐶𝐵 , which locks the specified funds. The Step1 Initial fund locking: First, Alice must locate Bob’s shard contract enforces mutual agreement between sender’s and receiver’s position through the Hash Ring. Therefore, Alice will create a message Trustor to release funds. If consensus is not reached, the funds remain containing the transaction information, structured as follows: locked. 𝐶𝐵 also includes timeout and fallback mechanisms to ensure 𝑇 𝑋request = {Property𝐴 , ToUser𝐵 , Time𝐴 , 𝑣, 𝑇lock , Sig𝐴 } progress under adverse conditions. Once completed, the verifier in Shard2 broadcasts the result to confirm transaction integrity. where 𝑇lock is the preset lock time for the funds, Time𝐴 is the timestamp In parallel, upon confirmation of 𝑇 𝑋request in Shard1, 𝑇 𝑟𝑢𝑠𝑡𝑜𝑟𝑀 for creating the transaction, and 𝑣 represents the transaction amount. creates another contract 𝐶𝐴 and locks funds under rules similar to 𝐶𝐵 . 5 X. Huang et al. Computer Standards & Interfaces 97 (2026) 104123 Table 1 Symbol explanations for algorithms. Symbol Explanation G Graph structure, containing nodes (accounts) and edges (transactions). u, v Account nodes in the graph, representing any two accounts. a, b Account nodes involved in matching or merging operations. degree(a) The degree of account 𝑎, representing the number of neighbors (transactions) it has. maxDepth Maximum depth of a node, used to prioritize high-frequency trading nodes. neighbor(a) The neighboring accounts of account 𝑎, connected in the graph. edge(u, v) Edge between accounts 𝑢 and 𝑣, representing the transaction connection. edge_weight(u, v) Weight of the edge between accounts 𝑢 and 𝑣. target_size Target size for the coarsened network, representing the desired scale. threshold Threshold value for merging or retaining nodes based on transaction volume. region Region formed by the depth-priority growing algorithm, containing multiple accounts. sorted_accounts List of accounts sorted by degree (transaction volume). When 𝐶𝐴 is finalized, its details are shared with Shard2 for synchro- 4.3. Transaction settlement and failure handling nization. Alice then sends the funds 𝑣 and a message 𝜁 to 𝐶𝐴 , where 𝜁 = The transaction settlement process follows a standard payment {𝑣, Timenow , ToUser𝐵 , 𝑇lock }. The contract’s unlocking condition channel model, addressing both cooperative and exceptional scenarios. requires that the corresponding transfer occurs within the time window In the cooperative case, 𝑇 𝑟𝑢𝑠𝑡𝑜𝑟𝑀 and 𝑇 𝑟𝑢𝑠𝑡𝑜𝑟𝑁 mutually agree to 𝑇lock , avoiding conflicts or double-spending. This ensures that the close the channel. 𝑇 𝑟𝑢𝑠𝑡𝑜𝑟𝑀 generates and signs a closure message locked funds are correctly routed to 𝑇 𝑟𝑢𝑠𝑡𝑜𝑟𝑀 . containing the final balance and fund allocation, then forwards it to Step3 TrustorN payment execution: In Shard2, after the contract 𝑇 𝑟𝑢𝑠𝑡𝑜𝑟𝑁 for verification and co-signature. The jointly signed message is is established, the 𝑇 𝑟𝑢𝑠𝑡𝑜𝑟𝑁 creates an intra-shard transaction message broadcast to the blockchain, where Shard 1 and Shard 2 verify the sig- as follows: natures and release the allocated funds. If residual funds remain locked, the inter-shard smart contract redistributes them to the appropriate 𝑇 𝑋second = {Property𝑁 , toUser𝐵 , Time𝑁 , 𝑣, Sig𝑁 } addresses, finalizing the settlement. This transaction is sent to the verifier nodes within the shard for In the uncooperative case, 𝑇 𝑟𝑢𝑠𝑡𝑜𝑟𝑀 may unilaterally broadcast validation. Meanwhile, Bob generates a random number 𝑅 and creates the most recent transaction state, initiating a challenge period during the following message: which 𝑇 𝑟𝑢𝑠𝑡𝑜𝑟𝑁 can dispute outdated information. If no challenge is made, the transaction is settled according to the submitted state. 𝜁 ′ = {H(𝑅), Sig𝐵 , {𝑇 𝑋second }} In the event of abnormal failures, recovery mechanisms safeguard This message is sent to 𝑇 𝑟𝑢𝑠𝑡𝑜𝑟𝑀 . Upon receiving the message, the both fund security and system liveness. If 𝑇 𝑟𝑢𝑠𝑡𝑜𝑟𝑁 maliciously with- 𝑇 𝑟𝑢𝑠𝑡𝑜𝑟𝑀 forwards H(𝑅) to contract 𝐶𝐴 , which automatically initiates holds the required secret 𝑅, and 𝐶𝐴 fails to receive it within the time- the HTLC [36]. According to the rules of 𝐶𝐴 , only when 𝑇 𝑟𝑢𝑠𝑡𝑜𝑟𝑀 out, a rollback is triggered: funds are refunded to 𝑇 𝑟𝑢𝑠𝑡𝑜𝑟𝑀 , 𝑇 𝑟𝑢𝑠𝑡𝑜𝑟𝑁 provides the value of 𝑅 corresponding to H(𝑅) within the specified forfeits their deposit, and suffers a reputation penalty. Repeated of- time 𝑇1 (𝑇1 < 𝑇lock ), 𝑇 𝑟𝑢𝑠𝑡𝑜𝑟𝑀 can start the next transaction smoothly. fenses may result in disqualification. Otherwise, when the time 𝑇lock for Alice to lock the funds ends, the If failure occurs due to force majeure, 𝑇 𝑟𝑢𝑠𝑡𝑜𝑟𝑁 submits a failure funds will return to Alice’s account, and the system will start to query proof the initiator of the transaction failure and punish him (Section 4.3). 𝜇 = {Sig𝑁 , 𝑇 𝑋request , 𝑇 𝑋second , Tablenow } Once 𝑇 𝑋second is included in the block, 𝑇 𝑟𝑢𝑠𝑡𝑜𝑟𝑁 will transfer the funds 𝑠 = 𝑣 to contract 𝐶𝐵 , locking them for the time period 𝑇2 (𝑇2 < to Shard 1 and Shard 2. Once validated that the transfer could not be 𝑇1 ). Bob is then notified that the funds are ready to be claimed. Once completed within the lock time 𝑇1 , the locked funds in 𝐶𝐵 are refunded Bob provides the correct 𝑅 within the specified time window, the to 𝑇 𝑟𝑢𝑠𝑡𝑜𝑟𝑁 , and Shard 1 returns funds to 𝑇 𝑟𝑢𝑠𝑡𝑜𝑟𝑀 , ensuring proper locked funds will be released to Bob. recovery and termination (see Table 1). Step4 HTLC unlocking: The 𝑇 𝑟𝑢𝑠𝑡𝑜𝑟𝑁 completes the payment, yet the funds remain locked unless the process is correctly finalized within 5. Cross-shard optimization and dynamic shard adjustment mech- the designated time window 𝑇2 . To initiate the release, Bob must submit anism the correct value of 𝑅 along with his digital signature, which enables public verification. Upon receiving and verifying 𝑅, 𝑇 𝑟𝑢𝑠𝑡𝑜𝑟𝑁 generates 5.1. CSOCPPA a channel message: Traditional Metis algorithms [17] coarsen transaction graphs using 𝜃1 = {Sig𝑁 , Tablenow , 𝑅} random or edge-weighted matching but often overlook critical paths Here, Tablenow represents the latest balance allocation table, which is and high-transaction nodes in cross-shard transactions. These elements then sent to the 𝑇 𝑟𝑢𝑠𝑡𝑜𝑟𝑀 . The 𝑇 𝑟𝑢𝑠𝑡𝑜𝑟𝑀 provides𝑅 to the contract 𝐶𝐴 are essential for throughput and latency, and mishandling them can for verification. If H(𝑅) matches, the contract notifies 𝑇 𝑟𝑢𝑠𝑡𝑜𝑟𝑀 that increase cross-shard communication and cause load imbalance [38]. To the match is successful. At this time, 𝑇 𝑟𝑢𝑠𝑡𝑜𝑟𝑀 forwards the message to address this, we propose CSOCPPA, a coarsening-phase optimization al- other idle Trustors in shard1 to jointly verify the allocation table and gorithm that identifies and preserves critical paths and high-transaction version number. If 2∕3 of the Trustors verify that it is correct, 𝑇 𝑟𝑢𝑠𝑡𝑜𝑟𝑀 nodes during graph compression (The key symbols and notations used will generate the following channel message: in our algorithms are summarized in Table 1). CSOCPPA effectively alleviates load imbalance, improves system throughput, and optimizes 𝜃2 = {Sig𝑀 , {𝜃1 }} overall resource utilization. and sends it back to 𝑇 𝑟𝑢𝑠𝑡𝑜𝑟𝑁 . The idle Trustor group in Shard2 verifies (1) Adjustment during the coarsening stage: Consider a directed the updated balance table and ensures that the latest channel states weighted graph 𝐺 = (𝑇 , 𝐸), where 𝑇 represents the transaction nodes are properly recorded. Through this coordinated process, the updated and 𝐸 represents the transaction edges. Each node 𝑡 ∈ 𝑇 represents a balances are securely synchronized, and the final signed states preserve user account or contract, and each directed edge 𝑒 = (𝑡𝑖 , 𝑡𝑗 ) ∈ 𝐸 denotes the integrity and consistency of the transaction. a transaction from 𝑡𝑖 to 𝑡𝑗 with associated cost or weight 𝑤𝑒 (𝑒). 6 X. Huang et al. Computer Standards & Interfaces 97 (2026) 104123 To evaluate transaction chain structure during coarsening, we de- Algorithm 1: Network Coarsening with Isolation Prevention fine the longest path 𝑃 as the path with the highest cumulative trans- Input: 𝐺 , target_size , threshold action cost or weight from the starting node to the terminal node. To Output: 𝐺𝑐𝑜𝑎𝑟𝑠𝑒𝑛𝑒𝑑 capture the depth and height of such a chain, we introduce two metrics: 1 foreach 𝑎 ∈ 𝐺.𝑎𝑐𝑐𝑜𝑢𝑛𝑡𝑠 do Depth(𝑡), which represents the maximum cumulative weight of any 2 𝑑𝑒𝑔𝑟𝑒𝑒(𝑎) ← count(neighbor (𝑎))// Init node degree path ending at node 𝑡, and Height(𝑡), which represents the maximum 3 𝑠𝑜𝑟𝑡𝑒𝑑_𝑎𝑐𝑐𝑜𝑢𝑛𝑡𝑠 ← Sort 𝐺.𝑎𝑐𝑐𝑜𝑢𝑛𝑡𝑠, cumulative weight of any path starting from node 𝑡. 4 by degree // Sort by degree We define the cumulative transaction cost along a path 𝑃 from 𝑡𝑖 to 5 while |𝐺| > 𝑡𝑎𝑟𝑔𝑒𝑡_𝑠𝑖𝑧𝑒 do 𝑡𝑗 as: 6 foreach 𝑎 ∈ 𝐺.𝑎𝑐𝑐𝑜𝑢𝑛𝑡𝑠 do ∑ 𝑛 7 𝑏 ← Select neighbor(𝑎), min_degree // Select 𝛾(𝑡𝑖 , 𝑡𝑗 ) = 𝑤𝑒 (𝑒𝑘 ) (1) 𝑘=1 low-degree neighbor 8 Merge 𝑎, 𝑏 // Merge nodes where 𝑒𝑘 are the edges along the path 𝑃 . 9 Update 𝐺, 𝑎, 𝑏 // Update graph The weight 𝜔(𝑡) of a node 𝑡 denotes the sum of all weights of 10 if degree(𝑎) < threshold then incoming and outgoing edges connected to 𝑡, representing the total 11 Merge low-volume accounts into transaction volume related to that account. 12 super accounts // Group small nodes Based on this, Depth and Height can be recursively computed as: 13 Update connect super accounts to ( ) Depth(𝑡) = max Depth(𝑡𝑖 ) + 𝜔(𝑡𝑖 ) + 𝛾(𝑡𝑖 , 𝑡) (2) 14 neighbors // Reconnect 𝑡𝑖 ∈Predecessors(𝑡) ( ) 15 foreach (𝑢, 𝑣) ∈ 𝐺.𝑒𝑑𝑔𝑒𝑠 do Height(𝑡) = max Height(𝑡𝑗 ) + 𝜔(𝑡𝑗 ) + 𝛾(𝑡, 𝑡𝑗 ) (3) 16 𝑒𝑑𝑔𝑒_𝑤𝑒𝑖𝑔ℎ𝑡(𝑢, 𝑣) ← calculate_weight(𝑢, 𝑣) 𝑡𝑗 ∈Successors(𝑡) // Reweight edges These metrics allow us to identify high-impact paths in the transac- 17 if edge_weight(𝑢, 𝑣) > threshold then tion graph for partitioning and optimization purposes. 18 Merge strongly connected accounts ; // Preserve The formula for the longest path maxPath(𝑒) can be adjusted as strong links follows: maxPath(𝑒) = Depth(source(𝑒)) + 𝑤𝑒 (𝑒) + Height(target(𝑒)) (4) 19 return 𝐺𝑐𝑜𝑎𝑟𝑠𝑒𝑛𝑒𝑑 ; This formula calculates the longest path of transaction edge𝑒 within the system. Here, source(𝑒) represents the starting node of transaction edge𝑒, and target(𝑒) represents the terminal node of transaction edge𝑒. increasing the cost of cross-shard transactions and communication. To If the maxPath(𝑒) value of a path is high, it indicates that the accounts address this issue, we propose the Depth-Priority Growing Algorithm and transactions on the path have a significant influence or frequent (DPGA). This algorithm prioritizes accounts with high transaction fre- transaction records. In the state partitioning process, such high-weight quency and network importance (i.e., nodes with larger maxDepth) as paths should not be fragmented; instead, the transactions on these paths starting points. Through a region-growing strategy, eligible neighboring should be assigned to the same partition to reduce communication nodes are merged into the same region until no more neighbors can be and synchronization costs associated with cross-partition transactions. added. This approach reduces the dispersion of high-frequency trans- After completing the calculation of maxPath(𝑒), we also need to address action accounts and lowers the complexity of cross-shard transactions. issues such as reducing the likelihood of transaction account isolation. The pseudocode is presented in Algorithm 2. Therefore, to further improve the partitioning process, the following steps are executed, as shown in Algorithm 1. 5.2. Dynamic sharding adjustment mechanism Step 1: Degree calculation and initial matching Calculate the degrees of all accounts and sort them in ascending By adjusting account allocation, the overall load of the sharding order. Select the account with the lowest degree from the set of un- system can be significantly improved. To further ensure the system’s matched accounts and match it with its adjacent accounts. Prioritize the performance, we incorporate a dynamic sharding mechanism combined reduction of isolated accounts and prevent the spread of low-frequency with the CSOCPPA to maintain load stability across the system. The trading accounts across shards to minimize cross-shard transactions. dynamic sharding adjustment mechanism monitors the GINI coefficient Step 2: Multi-Edge matching phase to assess load balance and evaluates transaction patterns to dynamically Match adjacent accounts in descending order of edge weight. If split or merge shards. This approach optimizes both load balancing and multiple accounts share the same weight, prioritize accounts with fewer cross-shard transaction performance. The following sections provide merged edges to preserve high-frequency trading paths and minimize a detailed explanation of shard load definitions, the GINI coefficient cutting critical paths. measurement criteria, and the dynamic adjustment mechanism. Step 3: Network update and simplification After each match, update the network’s connections. If the network (1) Definition and algorithm of shard load: In a distributed reaches the target size, proceed to the next step; otherwise, return to system, shard load is a key indicator for measuring the workload of Step 2 and continue simplifying the network. shards. The calculation of shard load should comprehensively consider Step 4: Load balancing and super account creation various factors, including the number of users stored within a shard, After coarsening, merge low-transaction accounts into super ac- the transaction volume processed, and the frequency of cross-shard counts. Ensure these super accounts remain connected to their original interactions. To ensure the comprehensiveness of the load indicator, neighbors, accumulate all edge weights, and retain full transaction the following load calculation methods are defined: data. The user count load of shard 𝑆𝑖 is defined as the number of users (2) Initialization phased optimization: In the context of cross- managed by the shard, expressed as: shard transactions, the initial partitioning is critical for subsequent 𝑙𝑗𝑢 = 𝑈𝑗 (5) optimizations. The traditional Metis algorithm [17] grows regions by randomly selecting starting points, which may lead to high-frequency The transaction volume load of shard 𝑆𝑖 is defined as the total trans- transaction accounts being distributed across different shards, thereby action volume processed by the shard within a unit of time, expressed 7 X. Huang et al. Computer Standards & Interfaces 97 (2026) 104123 Algorithm 2: Depth-Priority Growing Algorithm for Cross-Shard • 𝐺 ∈ (0.3, 0.5]: The system load is basically balanced, and load Transaction Optimization differences are within an acceptable range. Input: 𝐺, target_size, threshold, maxDepth • 𝐺 > 0.5: The system load is imbalanced, requiring redistribution Output: 𝐺𝑐𝑜𝑎𝑟𝑠𝑒𝑛𝑒𝑑 of high-load shards or merging of low-load shards. 1 foreach 𝑎 ∈ 𝐺.𝑎𝑐𝑐𝑜𝑢𝑛𝑡𝑠 do (3) Dynamic sharding adjustment: In a distributed shard system, 2 𝑑𝑒𝑔𝑟𝑒𝑒(𝑎) ← count(neighbor (𝑎)) ; load balancing operations, including shard splitting and shard merging, // Initialize degree are triggered based on specific conditions to maintain system efficiency 3 𝑠𝑜𝑟𝑡𝑒𝑑_𝑎𝑐𝑐𝑜𝑢𝑛𝑡𝑠 ← Sort 𝐺.𝑎𝑐𝑐𝑜𝑢𝑛𝑡𝑠, by and fairness. When the load of a shard significantly exceeds that of 4 Priority, then by maxDepth ; others or the GINI coefficient surpasses a predefined threshold, the 5 while |𝐺| > 𝑡𝑎𝑟𝑔𝑒𝑡_𝑠𝑖𝑧𝑒 do system triggers shard splitting. The shard with the highest load, 𝑆max , 6 foreach 𝑎 ∈ 𝐺.𝑎𝑐𝑐𝑜𝑢𝑛𝑡𝑠 do is identified based on the condition: 7 if maxDepth(𝑎) > threshold then // Prioritize high-frequency nodes 𝑙max > 𝜇 + 𝛾 ⋅ 𝜎 (9) 8 𝑏 ← Select neighbor(𝑎), 1 ∑𝑚 where 𝜇 = 𝑚 𝑗=1 𝑙𝑗 is the average load of all shards, 𝜎 = 9 max_degree ; √ ∑ 1 𝑚 2 10 Merge 𝑎, 𝑏 ; 𝑚 𝑗=1 (𝑙𝑗 − 𝜇) is the standard deviation, and 𝛾 is an adjustment 11 Update 𝐺, 𝑎, 𝑏 ; coefficient. For users in the split shard, the system employs consistency 12 if degree(𝑎) < threshold then hashing to find corresponding storage shards and updates the // Identify low-volume nodes mapping to ensure query consistency. Conversely, when certain shards 13 Merge low-volume accounts into experience prolonged low load below a predefined threshold, the 14 super accounts ; system triggers shard merging. The set of candidate shards for merging, 15 Update connect super accounts 𝑆low , is identified based on the condition: 16 to neighbors ; 𝑙𝑗 < 𝜃 (10) 17 foreach (𝑢, 𝑣) ∈ 𝐺.𝑒𝑑𝑔𝑒𝑠 do where 𝜃 is the minimum load threshold, during the merging process, the 18 𝑒𝑑𝑔𝑒_𝑤𝑒𝑖𝑔ℎ𝑡(𝑢, 𝑣) ← system updates the user-to-shard mapping and ensures synchronization 19 calculate_weight(𝑢, 𝑣) ; of query positions for affected users. These mechanisms collectively 20 if edge_weight(𝑢, 𝑣) > threshold then enhance system load distribution and ensure balanced utilization of 21 Merge strongly connected resources. 22 accounts ; // Merge strong connections 6. Security analysis 23 return 𝐺𝑐𝑜𝑎𝑟𝑠𝑒𝑛𝑒𝑑 ; 6.1. Atomicity of transactions V-Bridge uses a hypergeometric distribution to calculate the prob- as: ability of failure in each epoch. In V-Bridge, atomicity depends on ∑ whether multiple shards can complete state verification and fund con- 𝑙𝑗𝑡 = 𝑡𝑘 (6) firmation within a specified time window while maintaining a secure 𝑘∈𝑇𝑗 state. If any shard’s consensus committee includes more than 1∕3 where 𝑇𝑖 represents the set of all transactions related to shard 𝑆𝑖 , and malicious nodes, the shard is considered failed, potentially causing 𝑡𝑘 represents the transaction volume of transaction 𝑘. transaction abortion or triggering exceptional rollbacks. By combining these factors, the comprehensive load is defined as: Assume that the current epoch includes 𝑁 valid registered nodes, 𝑙𝑗 = 𝛼 ⋅ 𝑙𝑗𝑢 + 𝛽 ⋅ 𝑙𝑗𝑡 (7) with 𝑡 = 𝑓 ⋅ 𝑁 being malicious. Each shard randomly selects 𝑛 nodes to ⌊ ⌋ its consensus group. The probability that a shard contains at least form where 𝛼 and 𝛽 are weighting coefficients used to balance the contribu- 𝑛 3 malicious nodes is: tion of different load sources to the shard’s pressure, this comprehen- sive load indicator can better reflect the actual pressure of the shard ( 𝑡 ) (𝑁−𝑡) ∑ 𝑛 𝑥 ⋅ 𝑛−𝑥 and provide a reference for continuous adjustment. 𝑃shard-fail = (𝑁 ) (11) ⌊ ⌋ (2) Load Balancing measurement based on GINI coefficient: 𝑥= 3𝑛 𝑛 This study introduces the GINI coefficient as a measure to evaluate the load distribution state among shards. The GINI coefficient is a classical Here, 𝑁 is the total number of registered nodes, 𝑡 = 𝑓 ⋅ 𝑁 is the indicator of distribution inequality, with a range of [0, 1]. A value closer number of malicious nodes, 𝑛 is the number of consensus nodes per to 0 indicates a more balanced distribution, while a value closer to 1 shard, and 𝑥 denotes the number of malicious nodes in a single shard. indicates a more imbalanced distribution. If a transaction spans 𝑆txn shards, the upper bound on the atomicity In the shard load scenario, the calculation formula for the GINI failure probability is: coefficient is as follows: ∑𝑚 ∑𝑚 𝑃 𝑟[Atomicity Failure] < 𝑆txn ⋅ 𝑃shard-fail (12) 𝑗=1 𝑘=1 |𝑙𝑗 − 𝑙𝑘 | 𝐺= ∑ (8) 2𝑚 𝑚 𝑗=1 𝑙𝑗 As long as the proportion of malicious nodes in each shard does not exceed 1∕3 (i.e., 𝑓 < 1∕3), V-Bridge can guarantee atomicity. In where 𝑚 represents the number of shards, and 𝑙𝑗 represents the load of the subsequent analysis, we demonstrate how V-Bridge ensures atomic shard 𝑆𝑗 . Based on the calculated GINI coefficient, the current balance cross-shard transactions. of system shard loads can be directly judged. The specific judgment rules are as follows: Theorem 1. If a cross-shard transaction completes within the HTLC window • 𝐺 < 0.3: The system load is completely balanced, and all shard 𝑇1 and submits a valid 𝑅, V-Bridge guarantees atomicity without requiring loads are identical. rollback. 8 X. Huang et al. Computer Standards & Interfaces 97 (2026) 104123 Proof. Assume the transaction involves shards 𝑆1 , 𝑆2 , . . . , 𝑆𝑘 , where 7. Experimental evaluation the funds in each shard are locked using HTLC contracts. The unlocking condition requires the receipt of a correct 𝑅 that satisfies a predeter- 7.1. Setting mined hash value H(𝑅) within the window 𝑇1 , fulfilling the release condition. We developed a prototype of V-Bridge in Golang and evaluated its performance on Ubuntu 20.04.1. The testbed was configured with an Once the receiver Bob submits the correct 𝑅 within 𝑇1 , all con- 8-core AMD Ryzen 6000 processor, 16 GB LPDDR5-6400 memory, and tracts are deemed releasable. Trustor nodes in each shard immediately a 1TB PCIe 4.0 SSD. To emulate real-world conditions, we introduced execute the fund release and update the balance state as Tablenow . random network latency between 50–100 ms and limited the band- This updated state is signed by both Trustors and broadcast across all width to 500 Mbps. Each block accommodates up to 3000 transactions, involved shards for chain-level finalization. Since valid release requires with each transaction fixed at 512 bytes. The number of C-Shards was the correct 𝑅 and consistent co-signatures, the final state is valid only set as 𝑆 ∈ {2, 4, 8, 16, 32, 64, 100} to evaluate system scalability. under mutual agreement. Therefore, if the transaction succeeds, all The dataset was extracted from the Ethereum blockchain using contracts release simultaneously; otherwise, if any contract fails to Python scripts from the XBlock-ETH project, including sender/receiver trigger, it indicates that 𝑅 was not submitted, and the transaction is addresses, amounts, and timestamps. The preprocessed data was used entirely aborted without partial execution. In conclusion, as long as 𝑅 as input for V-Bridge. is submitted within 𝑇1 , the HTLC conditions ensure atomicity across all In dynamic load regulation, we assigned weight factors 𝛼 = 0.4 and shards without the need for rollback logic. 𝛽 = 0.6 to user count and transaction volume. The GINI coefficient was used to evaluate shard imbalance. A split is triggered when GINI > 0.5, Theorem 2. If a cross-shard transaction misses the HTLC deadline 𝑇1 , V- and merging is triggered when the condition 𝑙𝑗 < 𝜃 = 0.3𝜇 is met, Bridge ensures a consistent rollback across all shards, preventing fund loss where 𝜇 is the average load. To reduce over-sensitivity, the adjustment or double spending. factor was set to 𝛾 = 1.5. In the CSOCPPA module, all transaction edges and node weights were set to 1 to simplify computation, representing Proof. The HTLC contract in V-Bridge is equipped with a unified a uniform transaction cost. timeout parameter 𝑇1 . If the correct random secret 𝑅 is not submitted For comparison, we implemented two additional load-balancing within this time frame, the contract automatically triggers a rollback schemes: BrokerChain and X-Shard. BrokerChain utilizes a partitioning mechanism, returning the locked funds to the original accounts. Since algorithm based on user account relationships, grouping frequently the funds remain unreleased throughout the process, the state in each interacting accounts within the same shard to reduce cross-shard trans- shard remains unchanged, and the system proceeds to restore consis- actions and enhance throughput. X-Shard employs an optimistic cross- tency. There is no partial commitment or state divergence, and the shard transaction strategy, processing transactions in parallel on input design inherently prevents double spending. Therefore, even in the shards and verifying them via gate accounts to minimize delays. All event of transaction failure, atomicity and consistency of the system solutions were tested under identical conditions using the PBFT [33] are preserved. This completes the proof. intra-shard consensus protocol. 6.2. Trustor security 7.2. System throughput To address potential malicious or faulty behavior among Trustors, Fig. 4 illustrates how throughput varies with the number of shards the system employs a dynamic reputation mechanism that continuously (𝑆) using a combination of boxplots, kernel density estimation curves, monitors node performance. Actions such as refusing to sign, forward- and scatter plots. The boxplot shows the quartile throughput range, ing delays, or failing to submit HTLC secrets are penalized. Nodes with white dots marking the median. The smooth kernel density curve whose reputation scores fall below a defined threshold are demoted, highlights data concentration, while the scatter plot visually represents stripped of execution privileges, and forfeit their staked collateral. In individual data points. As 𝑆 increases from 4 to 100, V-Bridge consis- the event of partial trust failure, the system ensures continuity through tently demonstrates superior throughput, with values stabilizing around leader re-election or transaction rollback. All critical operations require 3k to 3.5k TPS across different shard counts. This is evident in the tight co-signatures from at least 2∕3 of the shard’s Trustors, providing re- interquartile ranges and smooth density curves. BrokerChain’s through- silience against Byzantine behavior. We assume a majority of Trustors put remains relatively stable but lower, hovering around 2k to 2.5k are honest in each round and that HTLC secrets are submitted within TPS, while X-Shard’s performance lags behind, stabilizing just above 2k a bounded timeframe. Otherwise, contracts automatically roll back to TPS. Moreover, X-Shard exhibits more variability, with wider boxplots preserve state consistency. and more scattered data points, highlighting its lower reliability in These assumptions are realistic in practice: Trustors must stake comparison to V-Bridge. These trends highlight V-Bridge’s scalability collateral and earn reputation over time through consistent, verifiable and stability as the number of shards increases. actions, making large-scale compromises both economically prohibitive Fig. 5 examines throughput under varying transaction arrival rates and statistically improbable. The HTLC mechanism incorporates ex- (40–180 TX/s). Similar to Fig. 4, the boxplot depicts throughput dis- plicit timeouts and fallback logic, including automated rollback, which tribution, while the kernel density curve and scatter plot highlight enables the system to function correctly without relying on perfect data concentration and individual variations. V-Bridge consistently synchrony. achieves nearly 3k TPS across all arrival rates with minimal fluctua- Execution rights are assigned dynamically based on reputation: tions, confirming its robust performance. BrokerChain maintains steady high-reputation nodes are prioritized, while low-reputation nodes are throughput around 2k TPS, though fluctuations slightly increase at sidelined to prevent abuse of authority. Even in cases of collusion, higher arrival rates. X-sharp again underperforms, with throughput the co-signature requirement significantly raises the threshold for suc- consistently below 2k TPS and significant variability at high arrival cessful misconduct. Collectively, these mechanisms mitigate the risks rates. These results reinforce the performance and stability advantages associated with partial Trustor failures and HTLC disruptions. Rather of V-Bridge under heavy transaction loads, while BrokerChain and X- than relying on idealized assumptions, the system maintains robustness sharp struggle to adapt. The detailed visualizations further validate the through built-in safeguards such as incentive alignment, role rotation, reliability of the data, providing a strong foundation for comparing and protocol-level fallback strategies. system performance. 9 X. Huang et al. Computer Standards & Interfaces 97 (2026) 104123 Fig. 4. The impact of the number of shards on throughput. Fig. 5. Impact of transaction arrival rate on throughput. 7.3. Transaction processing delays As the number of shards increases, the average transaction delay of all systems shows a gradual downward trend. This indicates that Fig. 6 depicts the transaction delay under different protocols as a more shards can effectively distribute transaction processing workloads result of factors such as the number of shards, transaction arrival rate, and improve system performance. V-Bridge demonstrates significant and cross-shard ratio. From the observed trends, these experimental optimization at higher shard counts (e.g., 32 shards) with delays re- results reveal key factors affecting delay and highlight the performance duced to around 1400 ms, outperforming BrokerChain and X-Shard. differences of various protocols in distributed environments. This reflects V-Bridge’s superior cross-shard processing efficiency. By (1) Impact of the number of shards (Fig. 6(a)) contrast, BrokerChain and X-Shard show only slight delay reductions 10 X. Huang et al. Computer Standards & Interfaces 97 (2026) 104123 Fig. 6. Comparison of transaction delays. Fig. 7. Consensus and load comparison. with more shards, and the overall delay remains higher than V-Bridge, approximately 1400 ms, demonstrating excellent cross-shard processing with the gap further widening at 32 shards. capabilities. By contrast, BrokerChain and X-Shard experience signifi- cant delay increases, particularly when the cross-shard ratio exceeds (2) Impact of transaction arrival rate (Fig. 6(b)) 80%. Their delays surpass those of V-Bridge, highlighting the ineffi- Increasing the transaction arrival rate leads to an apparent rise ciency of their cross-shard communication and the more significant in transaction delay. All protocols exhibit relatively low delays at impact of high cross-shard traffic. lower arrival rates (40 TX/s). However, as the arrival rate increases, delays grow significantly. V-Bridge maintains stable performance even 7.4. Consensus and load comparison at higher arrival rates (e.g., 180 TX/s), showing good scalability. In contrast, BrokerChain and X-Shard experience rapidly increasing delays Consensus success rate is a critical indicator in distributed systems at higher arrival rates (e.g., above 120 TX/s), indicating their lim- that measures the proportion of successfully completed consensus pro- ited capacity to handle higher loads and reflecting their performance cesses within a given time. It reflects the system’s ability to synchronize bottlenecks in high-load environments. and process transactions efficiently while maintaining data consistency. (3) Impact of cross-shard ratio (Fig. 6(c)) A higher success rate directly correlates with better system performance At a lower cross-shard ratio (20%), delays across all protocols are and reliability. Conversely, a lower success rate can lead to transaction relatively close. However, as the cross-shard ratio increases, inter- failures, increased delays, or even system reconfiguration. Optimizing protocol differences become apparent. V-Bridge maintains stable per- consensus protocols enhances the system’s stability, performance, and formance even at an 80% cross-shard ratio, with an average delay of cross-shard transaction processing capabilities. 11 X. Huang et al. Computer Standards & Interfaces 97 (2026) 104123 Fig. 7 illustrates the consensus success rate and transaction effi- Acknowledgments ciency of three protocols (V-Bridge, BrokerChain, and X-Shard) under varying conditions, such as the number of shards, transaction arrival This work was partially supported by the Key Program of the Joint rates, and cross-shard ratios. V-Bridge consistently outperforms the Funds of the National Natural Science Foundation of China under other protocols across all conditions. In Fig. 7(a), as the number of Grant U2468205, the National Natural Science Foundation of China shards increases, the consensus success rate and transaction efficiency under Grants 62472168, 62072170 and 61976087, the Hunan Provin- for all protocols decline due to higher cross-shard communication cial Natural Science Foundation of China under Grants 2021JJ30141 overhead. However, V-Bridge maintains a high success rate (close and 2024JJ6066, the Key Research and Development Program of Hu- to 95%) even with 32 shards, demonstrating excellent scalability. In nan Province under Grant 2022GK2015, the Science and Technology contrast, BrokerChain and X-Shard experience significant performance Project of the Department of Communications of Hunan Province under degradation as the number of shards increases. Fig. 7(b) examines the Grant 202101, and the Research Projects of the Hunan Provincial impact of transaction arrival rates. V-Bridge maintains stable consensus Department of Education under Grants 23B0449 and 23B0288. success rates and efficiency even at high arrival rates (e.g., 180 TX/s). In contrast, BrokerChain and X-Shard exhibit significant declines in Data availability performance under heavy transaction loads, reflecting their processing limitations. Fig. 7(c) highlights the impact of cross-shard ratios. V- Data will be made available on request. Bridge demonstrates strong performance, maintaining a stable success rate even at an 80% cross-shard ratio. Meanwhile, the success rates of BrokerChain and X-Shard drop sharply under high cross-shard ratios, References revealing their weaknesses in handling intensive cross-shard scenarios. [1] J. Xu, C. Wang, X. Jia, A survey of blockchain consensus protocols, ACM Comput. Finally, the comparison of load balancing across different shard Surv. 55 (13s) (2023) 1–35. numbers shows that V-Bridge achieves the most balanced load distribu- [2] S. Zhang, Z. Yan, W. Liang, K.-C. Li, B. Di Martino, BCAE: A blockchain-based tion. Its variance remains minimal as the number of shards increases, cross domain authentication scheme for edge computing, IEEE Internet Things approaching the ‘‘Optimal Load Balance’’ standard. In contrast, the load J. 11 (13) (2024) 24035–24048. [3] W. Liang, Y. Yang, C. Yang, Y. Hu, S. Xie, K.-C. Li, J. Cao, PDPChain: A variance for BrokerChain and X-Shard is significantly higher, indicating consortium blockchain-based privacy protection scheme for personal data, IEEE poorer load balancing capabilities. Trans. Reliab. 72 (2) (2022) 586–598. [4] W. Liang, S. Xie, K.-C. Li, X. Li, X. Kui, A.Y. Zomaya, MC-DSC: A dynamic 8. Conclusion and future work secure resource configuration scheme based on medical consortium blockchain, IEEE Trans. Inf. Forensics Secur. 19 (2024) 3525–3538. [5] J. Cai, W. Liang, X. Li, K. Li, Z. Gui, M.K. Khan, GTxChain: A secure IoT smart We propose a novel virtual off-chain cross-shard transaction mech- blockchain architecture based on graph neural network, IEEE Internet Things J. anism that employs logical fund interactions instead of actual currency 10 (24) (2023) 21502–21514. transfers. This approach eliminates delays caused by continuous up- [6] M.M. Islam, M.K. Islam, M. Shahjalal, M.Z. Chowdhury, Y.M. Jang, A low-cost cross-border payment system based on auditable cryptocurrency with consortium loading and significantly enhances throughput. By integrating an intel- blockchain: Joint digital currency, IEEE Trans. Serv. Comput. 16 (3) (2022) ligent sharding adjustment mechanism with the CSOCPPA, we address 1616–1629. the limitations of traditional account optimization and mitigate load [7] Y. Lu, The blockchain: State-of-the-art and research challenges, J. Ind. Inf. Integr. imbalance. Experimental results show that, compared to BrokerChain 15 (2019) 80–90. and X-Shard, V-Bridge achieves up to 50% higher average throughput [8] H. Jin, J. Xiao, Towards trustworthy blockchain systems in the era of ‘‘internet of value’’: development, challenges, and future trends, Sci. China Inf. Sci. 65 and reduces transaction latency by at least 15%. Additionally, its (153101) (2022) 1–11. consensus success rate consistently exceeds 90%. Across varying shard [9] X. Meng, W. Liang, Z. Xu, K. Li, M.K. Khan, X. Kui, An anonymous authenticated counts, V-Bridge demonstrates a progressively decreasing load, which group key agreement scheme for transfer learning edge services systems, ACM remains consistently lower than those of the other two protocols. These Trans. Sen. Netw. 20 (2024). [10] T. Chen, Z. Li, Y. Zhu, J. Chen, X. Luo, J.C.-S. Lui, X. Lin, X. Zhang, results underscore V-Bridge’s superior performance, scalability, and Understanding ethereum via graph analysis, ACM Trans. Internet Technol. (TOIT) reliability as a solution for cross-shard transactions. 20 (2) (2020) 1–32. In future work, we plan to establish virtual fund channels among [11] L. Luu, V. Narayanan, C. Zheng, K. Baweja, S. Gilbert, P. Saxena, A secure multiple Trustors to achieve interoperability across the entire shard net- sharding protocol for open blockchains, in: Proceedings of the 2016 ACM SIGSAC Conference on Computer and Communications Security, ACM SIGSAC, 2016, pp. work. Additionally, we will explore advanced optimization strategies 17–30. for dynamic shard management to reduce communication further over- [12] Z. Hong, S. Guo, P. Li, Scaling blockchain via layered sharding, IEEE J. Sel. head. Meanwhile, we aim to incorporate zero-knowledge proofs and Areas Commun. 40 (12) (2022) 3575–3588. other cryptographic techniques into security management to enhance [13] F. Cheng, J. Xiao, C. Liu, S. Zhang, Y. Zhou, B. Li, B. Li, H. Jin, Shardag: Scaling system security. dag-based blockchains via adaptive sharding, in: 2024 IEEE 40th International Conference on Data Engineering, ICDE, IEEE, 2024, pp. 2068–2081. [14] P. Zheng, Q. Xu, Z. Zheng, Z. Zhou, Y. Yan, H. Zhang, Meepo: Multiple execution CRediT authorship contribution statement environments per organization in sharded consortium blockchain, IEEE J. Sel. Areas Commun. 40 (12) (2022) 3562–3574. Xueting Huang: Writing – original draft, Software, Methodology, [15] J. Wang, H. Wang, Monoxide: Scale out blockchains with asynchronous con- sensus zones, in: 16th USENIX Symposium on Networked Systems Design and Conceptualization. Xiangwei Meng: Writing – review & editing, Val- Implementation, NSDI 19, USENIX Association, 2019, pp. 95–112. idation, Supervision. Kai Zhang: Formal analysis, Conceptualization. [16] H. Huang, X. Peng, J. Zhan, S. Zhang, Y. Lin, Z. Zheng, S. Guo, Brokerchain: Ce Yang: Methodology, Formal analysis. Wei Liang: Writing – review A cross-shard blockchain protocol for account/balance-based state sharding, in: & editing, Funding acquisition, Formal analysis, Conceptualization. IEEE INFOCOM 2022-IEEE Conference on Computer Communications, IEEE, 2022, pp. 1968–1977. Kuan-Ching Li: Writing – review & editing, Supervision. [17] G. Karypis, V. Kumar, A fast and high quality multilevel scheme for partitioning irregular graphs, SIAM J. Sci. Comput. 20 (1) (1998) 359–392. Declaration of competing interest [18] J. Xu, Y. Ming, Z. Wu, C. Wang, X. Jia, X-Shard: Optimistic cross-shard transac- tion processing for sharding-based blockchains, IEEE Trans. Parallel Distrib. Syst. 35 (4) (2024) 548–559. The authors declare that they have no known competing finan- [19] Y. Levi, I. Keslassy, Beyond the ring: Quantized heterogeneous consistent hashing, cial interests or personal relationships that could have appeared to in: 2023 IEEE 31st International Conference on Network Protocols, ICNP, IEEE, influence the work reported in this paper. 2023, pp. 1–12. 12 X. Huang et al. Computer Standards & Interfaces 97 (2026) 104123 [20] G. Mendelson, S. Vargaftik, K. Barabash, D.H. Lorenz, I. Keslassy, A. Orda, [29] X. Wang, C. Lin, X. Huang, D. He, Anonymity-enhancing multi-hop locks for Anchorhash: A scalable consistent hash, IEEE/ACM Trans. Netw. 29 (2) (2020) monero-enabled payment channel networks, IEEE Trans. Inf. Forensics Secur. 19 517–528. (2023) 2438–2453. [21] B. Hou, D. Wang, T. Xia, L. Xi, Z. Peng, K.-L. Tsui, Generalized Gini indices: [30] T. Cai, W. Chen, K.E. Psannis, S.K. Goudos, Y. Yu, Z. Zheng, S. Wan, Scalable Complementary sparsity measures to Box–Cox sparsity measures for machine on-chain and off-chain blockchain for sharing economy in large-scale wireless condition monitoring, Mech. Syst. Signal Process. 169 (2022) 108751. networks, IEEE Wirel. Commun. 29 (3) (2022) 32–38. [22] X. Qi, Y. Li, LightCross: Sharding with lightweight cross-shard execution [31] X. Jia, Z. Yu, J. Shao, R. Lu, G. Wei, Z. Liu, Cross-chain virtual payment channels, for smart contracts, in: IEEE INFOCOM 2024-IEEE Conference on Computer IEEE Trans. Inf. Forensics Secur. 18 (2023) 3401–3413. Communications, IEEE, 2024, pp. 1681–1690. [32] Z. Li, W. Su, M. Xu, R. Yu, D. Niyato, S. Xie, Compact learning model for dynamic [23] S. Jiang, J. Cao, C.L. Tung, Y. Wang, S. Wang, SHARON: Secure and efficient off-chain routing in blockchain-based IoT, IEEE J. Sel. Areas Commun. 40 (12) cross-shard transaction processing via shard rotation, in: Proceedings of the IEEE (2022) 3615–3630. International Conference on Computer Communications, INFOCOM, IEEE, 2024, [33] W. Li, C. Feng, L. Zhang, H. Xu, B. Cao, M.A. Imran, A scalable multi-layer pp. 20–23. PBFT consensus for blockchain, IEEE Trans. Parallel Distrib. Syst. 32 (5) (2020) [24] Y. Zhang, S. Pan, J. Yu, Txallo: Dynamic transaction allocation in sharded 1146–1160. blockchain systems, in: 2023 IEEE 39th International Conference on Data [34] H. Azimy, A.A. Ghorbani, E. Bagheri, Preventing proof-of-work mining attacks, Engineering, ICDE, IEEE, 2023, pp. 721–733. Inform. Sci. 608 (2022) 1503–1523. [25] E. Kokoris-Kogias, P. Jovanovic, L. Gasser, N. Gailly, E. Syta, B. Ford, Om- [35] A. Hosoyamada, Y. Sasaki, Quantum collision attacks on reduced SHA-256 and niledger: A secure, scale-out, decentralized ledger via sharding, in: 2018 IEEE SHA-512, in: Annual International Cryptology Conference, Springer, 2021, pp. Symposium on Security and Privacy, SP, IEEE, 2018, pp. 583–598. 616–646. [26] M. Zamani, M. Movahedi, M. Raykova, Rapidchain: Scaling blockchain via full [36] C. Boyd, K. Gjøsteen, S. Wu, A blockchain model in tamarin and formal analysis sharding, in: Proceedings of the 2018 ACM SIGSAC Conference on Computer and of hash time lock contract, in: 2nd Workshop on Formal Methods for Blockchains, Communications Security, ACM SIGSAC, 2018, pp. 931–948. FMBC 2020, Schloss-Dagstuhl-Leibniz Zentrum für Informatik, 2020, p. 13. [27] Z. Hong, S. Guo, P. Li, W. Chen, Pyramid: A layered sharding blockchain system, [37] Y. Liu, W. Liang, K. Xie, S. Xie, K. Li, W. Meng, LightPay: A lightweight and in: IEEE INFOCOM 2021-IEEE Conference on Computer Communications, IEEE, secure off-chain multi-path payment scheme based on adapter signatures, IEEE 2021, pp. 1–10. Trans. Serv. Comput. 17 (4) (2023) 1503–1523. [28] A. Liu, Y. Liu, Q. Wu, B. Zhao, D. Li, Y. Lu, R. Lu, W. Susilo, CHERUBIM: [38] J. Herrmann, J. Kho, B. Uçar, K. Kaya, Ü.V. Çatalyürek, Acyclic partitioning of A secure and highly parallel cross-shard consensus using quadruple pipelined large directed acyclic graphs, in: 2017 17th IEEE/ACM International Symposium two-phase commit for sharding blockchains, IEEE Trans. Inf. Forensics Secur. 19 on Cluster, Cloud and Grid Computing, CCGRID, IEEE, 2017, pp. 371–380. (2024) 3178–3193. 13