874 lines
97 KiB
Plaintext
874 lines
97 KiB
Plaintext
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
|
||
|