An Efficient Cross-Shard Smart Contract Execution Framework Leveraging Off-Chain Computation and Genetic Algorithm-Optimized Migration

Abstract

Blockchain sharding is a promising approach to improving system scalability. However, traditional designs rely on lock-based cross-shard commit protocols, which introduce significant performance bottlenecks due to repeated on-chain communication and consensus. The emergence of complex cross-shard contracts further exacerbates these issues. Although recent off-chain execution models reduce on-chain overhead by decoupling contract execution from consensus, they still incur high communication costs and struggle to maintain state consistency. To address these challenges, this paper presents a sharding framework that seamlessly integrates on-chain and off-chain processing. By leveraging Trusted Execution Environments (TEEs), the framework enables secure and efficient off-chain execution of cross-shard smart contracts. It incorporates an off-chain execution hub for verifiable contract execution and a state-aware cross-shard commit protocol to guarantee correctness. Furthermore, a genetic algorithm-based contract-migration strategy dynamically reduces cross-shard interactions. Prototype evaluations show that the proposed framework significantly outperforms mainstream sharding solutions, achieving at least 2.1× higher throughput and reducing cross-shard transaction latency by over 52.6%.

1. Introduction

Sharding is widely regarded as a key technique for enhancing the scalability of blockchain systems [1,2]. Its core mechanism is to partition the blockchain’s nodes and global state into independent subsets, known as shards, each capable of processing transactions and maintaining its own ledger in parallel [3]. By enabling distributed and concurrent transaction execution, sharding significantly improves overall system throughput. However, with the increasing complexity of blockchain application scenarios and the diversification of transaction types, existing sharding systems face a core challenge: the difficulty of efficient collaborative processing of cross-shard transactions. Since such transactions involve accessing or modifying the states of multiple shards, they cannot be completed independently by a single shard. Instead, they must rely on cross-shard commit protocols (e.g., atomic commit protocols) for coordinated execution to ensure data integrity across shards and transaction atomicity, which inevitably introduces scalability constraints.

Early sharding solutions mainly focused on simple asset-transfer transactions, especially cross-shard transfers of digital assets [4,5,6]. In such solutions, transactions are typically broken down into shard-level atomic operations (e.g., deposits or withdrawals). However, due to the tight coupling of code and state in smart contract execution, smart contracts cannot be further decomposed into independent sub-operations, rendering such solutions unable to support complex cross-shard smart contract calls. To address this issue, some studies have proposed lock-based cross-shard commit protocols [7,8,9,10], ensuring consistency by executing all involved cross-shard contracts in a predetermined order at each relevant shard. Unfortunately, this mechanism imposes three key limitations: (1) state locking inhibits concurrent processing capabilities, leading to throughput degradation; (2) multiple rounds of cross-shard consensus communication exacerbate network overhead; (3) the expansion of security boundaries intensifies potential attack surfaces.

Recent studies [11,12] have leveraged Trusted Execution Environments to migrate cross-shard smart contract execution to off-chain environments. A typical architecture, as illustrated in Figure 1, works as follows: requests from blockchain clients are redirected to the off-chain environment, where cross-shard contract execution is completed under specific strategies. The results are then submitted back on-chain, verified and finalized through consensus, and ultimately returned to the client. This approach effectively avoids the complexity of traditional cross-shard commit protocols, thereby improving execution efficiency. However, existing approaches still face several critical limitations: (i) In some methods, when executing cross-shard contracts off-chain, each execution requires frequent requests to the on-chain environment for state data and contract code. Moreover, after the execution results are submitted on-chain, additional state verification must be performed with the corresponding shards. Such frequent cross-shard state synchronization incurs excessive communication overhead, which significantly reduces system throughput. (ii) Other methods require analyzing the invocation relationships of all contracts in the system during the deployment phase and partitioning them into specific contract groups, which are then deployed to off-chain nodes according to predefined rules. As the number of contracts increases, different contract groups tend to become highly coupled. This not only severely limits the system’s ability to support flexible deployment of large-scale smart contracts but also leads to a sharp increase in communication and state synchronization overhead [12]. Therefore, despite functional progress, existing solutions continue to face pressing bottlenecks in throughput efficiency and system scalability.

Our Solution. This paper proposes an off-chain execution model for cross-shard smart contracts, aiming to enhance the processing capability of sharded blockchain systems under complex transaction scenarios. The core idea of the model is to decouple smart contract execution from the on-chain execution environment: the execution logic is handled by off-chain nodes within an off-chain execution hub, while the blockchain network is only responsible for verifying results and reaching consensus. This design significantly reduces communication overhead and computational burden on the chain. To achieve this, we design a trusted off-chain execution hub composed of parallel-capable secure execution nodes. A remote attestation mechanism is integrated to generate integrity proofs during execution, enabling fast on-chain verification and preventing redundant contract execution. This approach greatly improves overall resource efficiency.

To unify the management of cross-shard contract code and state data, we design a Merkle-proof-enabled data structure based on the Merkle Patricia Trie (MPT) [13]. This structure supports efficient off-chain storage and access, while also providing verifiable state proofs for on-chain validation, thereby enhancing the system’s security and scalability in state management and verification. Building on this, we propose a state-aware cross-shard commit protocol that enables conflict detection and parallel scheduling of dependent transactions. By offloading execution logic to trusted off-chain environments and decoupling state verification from result submission, the protocol significantly reduces on-chain verification overhead and improves overall system throughput.

Furthermore, as the proportion of cross-shard contracts increases over time, the system may face performance bottlenecks. To address this, we introduce a contract-migration mechanism optimized by a genetic algorithm, which continuously refines contract placement to reduce cross-shard communication from the source. We implement a prototype system based on the proposed model and conduct comparative experiments against state-of-the-art solutions. The results demonstrate that our approach achieves superior performance in terms of system throughput and transaction latency, confirming its overall advantages in efficiency, scalability, and resource utilization.

The main contributions of this paper are as follows:

• We propose a cross-shard contract processing architecture that integrates off-chain execution with on-chain verification. By decoupling the cross-shard contract-execution process to the off-chain environment, this architecture effectively reduces on-chain communication and computational loads, significantly enhancing the system’s processing capability in high-concurrency transaction scenarios.
• We construct a remotely verifiable off-chain execution hub based on a trusted execution environment, which supports secure execution and rapid verification of smart contracts. Meanwhile, we put forward a state-aware cross-shard submission protocol to improve execution efficiency while ensuring consistency.
• We design a dynamic migration strategy for cross-shard contracts by combining genetic algorithm, realizing continuous optimization of contract-deployment locations and further alleviating system loads caused by frequent cross-shard interactions.
• We build a prototype system based on ChainMaker and conduct comparative tests with various mainstream solutions. Experimental results show that the proposed scheme increases the average throughput by 2.1 times and reduces the latency of complex cross-shard transactions by more than 52.6%.

The rest of this paper is organized as follows. Section 2 reviews related work. Section 3 introduces the system architecture and adversary model. Section 4 presents the design of key components, including the Off-chain Execution Hub, the state-aware cross-shard commit protocol, and the GA-based contract-migration mechanism. Section 5 analyzes correctness and scalability. Section 6 reports experimental setup, dataset, and evaluation results, followed by discussion. Section 7 concludes with a summary, limitations, and future directions.

2. Related Work

In this section, we provide an overview of key advances in blockchain sharding, off-chain execution models, and smart contract migration, which form the foundation for the framework design and research methodology presented in this work.

2.1. Blockchain Sharding

Blockchain sharding technology is inspired by the distributed architecture of traditional databases. According to current developments, mainstream sharding approaches can be categorized into three types: network sharding, transaction sharding, and state sharding [11,14]. Among them, network sharding serves as the foundational layer, supporting the other two. Transaction sharding partitions the blockchain network into multiple subnets, with different types of transactions assigned to fixed shards for independent execution. This enables parallel processing across shards, improving overall system throughput. However, this approach requires each shard to maintain the global world state, imposing significant storage and synchronization burdens on network nodes. In contrast, state sharding addresses the storage issue by dividing the global ledger state into subsets [10], with each shard responsible only for its assigned portion. This significantly reduces storage demands. To preserve the integrity of the global state, state-sharded systems typically incorporate redundancy mechanisms, such as backing up the entire world state, to prevent data loss and ensure consistency.

Existing sharding blockchain solutions have made notable progress in improving on-chain concurrency. Elastico [14] was the first to implement a sharding blockchain network, leveraging transaction sharding to significantly increase system throughput. However, its ability to support complex transactions involving state changes across multiple shards is limited. As a representative of transaction sharding, it also imposes substantial storage burdens on participating nodes, which must maintain the full global state. Building upon Elastico, Omniledger [6] and RapidChain [9] adopt state sharding to reduce storage overhead by allowing each shard to maintain only a subset of the global state. While this design improves scalability, it primarily supports simple value transfer transactions and lacks the capability to efficiently process complex cross-shard smart contracts.

To address the challenges of complex cross-shard smart contract execution, several solutions have been proposed. Chainspace [7] introduces a structured smart contract model that transforms contracts into transactions resembling standard transfers, thereby simplifying cross-shard execution. RingBFT [10] reduces the number of communication rounds required for coordination by enforcing a predetermined shard-execution order. To guarantee atomicity and consistency in cross-shard transactions, Byshard [8] adopts a two-phase commit protocol. Sharding upgrade proposal of Ethereum [13] seeks to centralize related contract states within a main shard, aiming to minimize communication overhead. Nevertheless, these approaches are generally categorized as lock-based cross-shard commit protocols. While they offer basic support for cross-shard contract execution, they also introduce increased communication rounds and degrade overall performance—issues that become particularly pronounced in complex contract scenarios.

2.2. Off-Chain Execution Model

To address the high latency and low throughput issues of cross-shard smart contracts in sharded blockchain systems, recent studies [15,16,17,18] have explored various off-chain execution models. These models offload the execution logic of smart contracts to trusted off-chain environments, thereby decoupling execution from consensus and significantly improving system performance and scalability. A classic architecture of such off-chain execution models is illustrated in Figure 1.

Representative solutions include FASTKITTEN [16], which leverages TEEs to execute smart contracts off-chain, enhancing execution efficiency. Ekiden [15] establishes a foundational framework that separates execution from consensus, using TEEs to support both privacy-preserving and high-throughput transaction processing. BitContracts [17] adopts a q-of-n trust model, in which execution tasks are distributed to n off-chain executors, and a transaction is considered successful once q consistent results are returned. While these approaches improve contract-execution efficiency, they primarily support single-shard contracts or simple transfers [19] and fall short when it comes to handling complex cross-shard smart contracts.

To extend the applicability of off-chain execution models to cross-shard scenarios, several studies have proposed execution frameworks capable of handling cross-shard smart contracts. For example, ACE [20] designates a group of off-chain executors as the execution set for each contract and temporarily suspends access to involved contract states during cross-shard calls to ensure secure execution. The “contract-execution set” proposed by ACE is extended in ShardCon [12], where both contract code and state are fully migrated to the off-chain environment to improve support for cross-shard transactions. LightCross [11] introduces a lightweight cross-shard commit protocol based on trusted execution environments, where relevant contract code and state are temporarily loaded into the TEE prior to execution to ensure integrity and consistency.

While these solutions provide initial support for cross-shard contract execution in off-chain environments, they still face significant challenges. Frequent synchronization of state data across multiple shards incurs substantial time overhead. The complexity of contract deployment increases communication paths and makes state coordination more difficult, ultimately impacting throughput. Overall, although off-chain execution mechanisms have been widely adopted in single-shard contexts, realizing efficient and communication-friendly support for cross-shard smart contracts remains an open problem. Systematic breakthroughs are urgently needed in areas such as state synchronization protocols, verification structures, and contract-deployment models.These observations are further clarified through a comparative analysis of representative systems, as shown in

Table 1. Comparison of the proposed framework with related systems.

Reference	System	Execution Mechanism	Contract Support	Storage Scalability	Fault Model	Migration Strategy	Protocol Complexity
[6]	Omniledger	Chain-only	Simple	✓	1/3	∘	$O\left(k\right)$
[9]	RapidChain	Chain-only	Simple	✓	1/3	∘	$O\left(k\right)$
[7]	Chainspace	Chain-only	Simple	✓	1/3	∘	$O\left(k\right)$
[21]	Hyperledger	Chain-only	Complex	✓	1/3	∘	$O\left(k\right)$
[8]	ByShard	Chain-only	Complex	✓	1/3	∘	$O\left(k\right)$
[17]	Bicontracts	Chain-only	Simple	x	Majority voting	∘	∘
[20]	ACE	Chain-only	Complex	x	q-of-n	∘	∘
[22]	AHL	TEE-assisted	Simple	✓	1/3	∘	$O\left(k\right)$
[16]	Fastkitten	TEE-assisted	Simple	x	Sharding-relied	∘	∘
[15]	Ekiden	TEE-assisted	Simple	x	TEE-relied	∘	∘
[18]	SlimChain	TEE-assisted	Simple	x	TEE-relied	∘	∘
[12]	ShardCon	TEE-assisted	Complex	x	q-of-n	∘	$O\left(1\right)$
[11]	LightCross	TEE-assisted	Complex	✓	TEE-relied	Static	$O\left(k\right)$
-	Proposed Framework	TEE-assisted	Complex	✓	TEE-relied	Dynamic	$O\left(1\right)$

Legend: ✓ = Satisfaction, x = Dissatisfaction, ∘ = Not Applicable.

.

2.3. Smart Contract Migration

In most sharded blockchain systems, the deployment of smart contracts is typically determined by random assignment. Once a contract is placed within a shard, its location remains fixed throughout system operation. However, as the number of shards increases, the proportion of cross-shard contracts inevitably rises, which significantly degrades system throughput. Several studies have attempted to address this issue, such as BrokerChain [1] and OptChain [23]. BrokerChain reduces cross-shard transactions by controlling the placement of transaction states and associated accounts, while OptChain introduces a lightweight and just-in-time transaction placement method that groups related or potentially related transactions into the same shard to minimize cross-shard overhead. Nevertheless, these approaches are primarily designed for simple value-transfer transactions and lack applicability to complex smart contract scenarios. To overcome this limitation, LightCross models the invocation relationships among contracts as a transaction call graph, reformulating the sharding problem into an offline graph partitioning task with temporal balancing. While this method represents a step forward, it primarily optimizes for a single objective—reducing the number of cross-shard calls—without jointly considering other critical factors such as invocation frequency, communication overhead, and node load distribution.

In summary, existing solutions remain insufficient for optimizing smart contract deployment and migration in sharded systems. A more comprehensive approach is required—one capable of global search and well-suited for nonlinear, multi-objective optimization. Such a method should simultaneously account for communication costs, contract invocation frequency, system load balancing, and migration overhead, thereby enabling a more effective and adaptive strategy for cross-shard contract migration.

3. Overview

In this section, we present the system model and the adversary model, outlining the framework’s core assumptions and potential threats in both on-chain and off-chain environments.

3.1. System Model

We present an overview of the system model and briefly describe its operational workflow. As illustrated in Figure 2, the system consists of four core components: Client, Execution Shards, Coordinator Shard, and the Off-chain Execution Hub.

• Clients: The client initiates smart contracts, handling deployment and invocation based on application needs. The client set is denoted as $\mathcal{U}=\{u_1,u_2,\dots ,u_n\}$, where each $u_i\in \mathcal{U}$ can deploy contract bytecode and submit parameterized transactions to trigger execution.
• Execution Shards: The shard set is denoted as $\mathcal{S}=\{S_1,S_2,\dots ,S_m\}$, where each $S_i\in \mathcal{S}$ consists of blockchain nodes maintaining a local subchain. Intra-shard transactions are processed locally via consensus, while cross-shard invocations are encapsulated and forwarded to the Coordinator Shard.
• Coordinator Shard: Denoted as $S_c$, this shard coordinates cross-shard execution. It determines execution order, manages concurrency, and synchronizes state to ensure semantic correctness and atomicity.
• Off-chain Execution Hub: The hub comprises nodes with trusted execution environments, denoted by $\mathcal{E}=\{{\mathcal{E}}_1,{\mathcal{E}}_2,\dots ,{\mathcal{E}}_k\}$. Each ${\mathcal{E}}_i\in \mathcal{E}$ runs in a secure enclave, maintains a global view of cross-shard contract state, and produces verifiable execution results via remote attestation, which are submitted for on-chain verification.

To enable efficient execution of cross-shard smart contracts and dynamic system optimization, the system operates in three main phases: pre-processing, contract execution, and contract migration.

• Pre-processing phase: Nodes in the off-chain execution hub register on-chain and receive system state snapshots from $S_c$. This process enables them to participate in contract execution. The system supports dynamic node participation, ensuring elasticity and scalability.
• Contract-execution phase: This is the core operational phase of the system. When $u_i$ issues a contract invocation $\tau$, the request is routed to $S_i$ where the contract is deployed. If the contract is intra-shard, it is executed and finalized locally. For cross-shard calls, the system triggers the Cross-Shard Commit Protocol and routes the request to $S_c$. The $S_c$ aggregates and dispatches the request to the off-chain execution hub, where it is executed within a trusted environment. The hub then returns a remotely attested execution result, which the $S_c$ verifies. Once verified, the result is relayed to the relevant execution shards for final consensus, completing the transaction.
• Contract-migration phase: To further optimize throughput and reduce latency, $S_c$ periodically evaluates system performance metrics and uses metaheuristic algorithms to dynamically adjust contract placement. This optimization considers invocation frequency, load balancing, and communication overhead, with the aim of reducing the proportion of cross-shard calls and improving system efficiency at its core. Since migration may disrupt ongoing operations, migration triggers must be carefully selected, such as adopting a fixed scheduling cycle based on system stability.

3.2. Adversary Model

This system encompasses both on-chain and off-chain environments, each facing distinct adversarial threats. We base our analysis on the standard security assumptions for blockchain and Trusted Execution Environments (TEEs), and from both on-chain and off-chain perspectives, we conduct a detailed analysis of the specific threats to each component of the system (client, execution shards, coordinator shard, and off-chain execution hub).

In the on-chain environment, the blockchain environment on the chain adopts a Byzantine Fault Tolerant (BFT) consensus protocol (such as the Practical Byzantine Fault Tolerant (PBFT) algorithm and its variants) [24]. We assume that the proportion of malicious nodes within each shard does not exceed one-third. Adversaries may exhibit full Byzantine behavior, including denial of response, message forgery, or node collusion, with the objective of disrupting the consensus process or tampering with the global system state. For execution shards, we adopt a traditional blockchain architecture where the BFT consensus protocol is sufficient to ensure the security of the consensus process. For the coordinator shard ($S_c$), since it interacts with the off-chain environment, it faces Byzantine behavior from external nodes, and result submission nodes cannot be constrained by the BFT consensus protocol. Therefore, we propose a state-based cross-shard commit protocol, which uses versioned snapshots and Merkle proofs to ensure that the scheduling process can perceive transaction dependencies and ensure atomicity of execution, thus effectively mitigating such threats (see Section 4.2).

In the off-chain environment, the core component—off-chain execution hub—relies on Trusted Execution Environments (TEEs) to ensure the correctness and confidentiality of cross-shard contract execution [22,25]. We adopt the standard security assumption of TEE, where adversaries cannot break the hardware-enforced isolation boundaries of the TEE. Even if some off-chain nodes are maliciously controlled, their attack capabilities are limited to launching denial-of-service attacks, delaying responses, or submitting forged results. With the help of remote attestation mechanisms, we can ensure that the coordinator shard only accepts results submitted by honest nodes. It is important to note that, although we rely on the basic security assumptions of TEE to secure the off-chain execution environment, real-world TEEs may still face threats such as side-channel attacks [26,27], which may compromise their security. Fortunately, numerous studies [28,29,30] have proposed solutions to mitigate these attacks and enhance the security of TEEs.

4. System Design

This section presents the core components of the proposed system. We describe the Off-chain Execution Hub, the State-Aware Cross-shard Commit Protocol, and the Contract-Migration Mechanism, which together enable secure and efficient cross-shard contract execution.

4.1. Off-Chain Execution Hub

Trusted execution nodes form the core of the off-chain execution hub, playing a pivotal role in enabling efficient and trustworthy execution of cross-shard smart contracts. Each node comprises three key components: A Data Storage Module, and a Trusted Execution Engine,. Their design is detailed as follows.

4.1.1. Data Storage Module

To improve the efficiency of cross-shard contract execution and reduce communication overhead, we decouple the world state of cross-shard contracts from the execution shards. This decoupled state is managed collaboratively by the $S_c$ and $\mathcal{E}$. Execution shards $\left\{S_i\right\}$ only retain the transaction logs relevant to them. When necessary, the global state of a contract can be reconstructed from these transaction records.

For managing the decoupled world state, we adopt a Merkle Patricia Trie (MPT) structure, similar to Ethereum, to organize contract code and state data. The use of MPT enables efficient state updates and allows the generation of Merkle proofs to support the correctness and verifiability of contract states when needed.

In our design, each smart contract is uniquely identified by its contract address, which serves as the key for locating the associated data. The corresponding value includes the contract code, state variables, and relevant metadata. This key-value structure forms the basis of the MPT, which is used to maintain the world state of decoupled cross-shard contracts. As MPT is a widely adopted data structure in blockchain systems [21,31,32], we omit its detailed construction in this paper.

4.1.2. Trusted Execution Engine

The Trusted Execution Engine is designed to perform cross-shard smart contract execution off-chain in a secure and efficient manner, while ensuring that results remain verifiable on-chain. To achieve this, we build an execution framework that combines hardware-based Trusted Execution Environments with a remote attestation mechanism, providing strong guarantees of confidentiality and correctness [33].

On top of this framework, we design two core algorithms to enable key functionalities:

• The first algorithm handles a single cross-shard contract invocation, securely and efficiently executing all involved contracts within a trusted environment. Generates preliminary results along with proofs of state integrity to support subsequent verification.
• The second algorithm targets the batch of cross-shard invocation results received by a trusted execution node within a given time window. Produces a unified correctness proof, enabling efficient verification by the coordinating shard and significantly reducing communication and validation overhead.

We take the example of a trusted execution node receiving a cross-shard contract invocation to illustrate how the trusted execution engine operates.

Upon receiving a cross-shard contract invocation request $\tau$, the trusted execution engine initiates a formal legality check as defined in Algorithm 1. This process first verifies the attached signature $\mathtt{Sign}\left(\tau \right)$, and ensures that the referenced world state version $V_{\mathrm{req}}$ matches the current system state $V_{\mathrm{current}}$. The current state is derived as a Merkle commitment over the authenticated state trie, i.e.,

$$\begin{array}{c}\hfill V_i=\mathcal{M}\left({\mathrm{MPT}}_{i-2}\right)\end{array}$$

(1)

where $\mathcal{M}(·)$ denotes the Merkle root computation and ${\mathrm{MPT}}_{i-2}$ is the versioned Merkle Patricia Trie corresponding to snapshot $i-2$, where this snapshot represents the world state snapshot of cross-shard contracts. This validation step prevents the processing of outdated or inconsistent requests.

Algorithm 1 Secure Execution of Cross-Shard Contract Invocation
Require:  Signature Sign, Contract Input Input, Metadata Params Ensure:  isValid (whether the request is valid), result (contract output)
1: isValid ← false	▹ Initialize validity flag
2: result ← null	▹ Initialize result as empty
3: info ← Concat(Input, Params)	▹ Extract essential execution parameters
4: if Crypto.Verify(Sign, info) then	▹ Verify signature authenticity
5:       isValid ← true	▹ Mark request as valid
6:       LoadContractCodeAndState(info)	▹ Load contract code and state
7:       result ← ExecuteContract(info)	▹ Execute contract logic
8:       SignWithRemoteAttestation(result)	▹ Attach remote attestation proof
9: end if
10: return isValid, result	▹ Return validity flag and execution result

Upon passing validation, the engine parses the invocation, extracts the set of involved contracts, and loads both the necessary contract code and associated state data from the shards specified by $\mathtt{shards}\left(\tau \right)$. The engine then performs a local execution of all intra-request contract calls within the secure enclave.

For a given transaction $\tau$, the engine records the access pattern as formal read and write sets:

$$\begin{array}{cc}\hfill R\left(\tau \right)& =\left(\bigcup _{i\in \mathtt{shards}\left(\tau \right)}{R}_{\mathtt{code}}^i\left(\tau \right)\right)\cup \left(\bigcup _{i\in \mathtt{shards}\left(\tau \right)}{R}_{\mathtt{state}}^i\left(\tau \right)\right)\hfill \end{array}$$

(2)

$$\begin{array}{cc}\hfill W\left(\tau \right)& =\bigcup _{i\in \mathtt{shards}\left(\tau \right)}{W}_{\mathtt{state}}^i\left(\tau \right)\hfill \end{array}$$

(3)

where $R_{\mathtt{code}}^i\left(\tau \right)$, $R_{\mathtt{state}}^i\left(\tau \right)$, and $W_{\mathtt{state}}^i\left(\tau \right)$ respectively denote the code access, state read, and state write sets within shard i. shards($\tau$) denotes the shards that support the execution of the transaction $\tau$ (code supply, state management).

After execution, the engine aggregates the return values and the $R\left(\tau \right)$, $W\left(\tau \right)$, and generates a ${\mathrm{Proof}}_i$ using remote attestation. The resulting attested execution record ensures both integrity and verifiability of off-chain processing.

To further guarantee the integrity of the code and state data used during execution, the trusted execution node ${\mathcal{E}}_i$ generates a unified correctness proof ${\mathrm{Proof}}_{{\mathcal{E}}_i}$ covering all cross-shard invocations it has processed within a specific time window, as specified by Algorithm 2. For each transaction ${\tau }_j\in {\mathcal{T}}_{{\mathcal{E}}_i}$, where ${\mathcal{T}}_{{\mathcal{E}}_i}$ denotes the set of transactions processed by ${\mathcal{E}}_i$, the engine extracts its read and write sets, $R\left({\tau }_j\right)$ and $W\left({\tau }_j\right)$, and reconstructs Merkle proofs for each accessed state item within the TEEs. As mentioned earlier, we leverage MPT as the underlying data structure to maintain and verify contract states, which efficiently provides us with Merkle proofs and root consistency checks. These per-transaction proofs are aggregated and signed in batch. The generation process is denoted as:

$$\begin{array}{c}\hfill {\mathrm{Proof}}_{{\mathcal{E}}_i}\leftarrow \mathrm{ProveBatch}({\mathcal{T}}_{{\mathcal{E}}_i},V_{\mathrm{current}})\end{array}$$

(4)

Internally, ProveBatch constructs a Merkle path $\mathcal{M}(R\left({\tau }_j\right)\cup W\left({\tau }_j\right))$ for each ${\tau }_j$, and bundles the results into a single proof package:

$$\begin{array}{c}\hfill {\mathrm{Proof}}_{{\mathcal{E}}_i}={\mathrm{RAttest}}_{{\mathcal{E}}_i}(\mathrm{MerkleProofs}(\bigcup _{\begin{array}{c}\tau \in {\tau }_i\end{array}}\left[R\left(\tau \right)\cup W\left(\tau \right)\right]))\end{array}$$

(5)

The ${\mathrm{Proof}}_{{\mathcal{E}}_i}$ is attested by ${\mathcal{E}}_i$ and submitted to $S_c$ for batch verification.

Algorithm 2 Batch Proof Generation for Cross-Shard Transactions
Require:  Transaction Set ${\mathtt{T}}_{{\mathcal{E}}_i}$, Current State Version ${\mathtt{V}}_{\mathrm{current}}$, Trusted Execution Node ${\mathcal{E}}_i$ Ensure:  Unified Correctness Proof ${\mathtt{Proof}}_{{\mathcal{E}}_i}$
1: $\mathtt{MerkleProofs}\leftarrow \varnothing$	▹ Initialize set for Merkle proofs
2: for all ${\tau }_j\in {\mathtt{T}}_{{\mathcal{E}}_i}$ do	▹ Process each transaction
3:       $R\left({\tau }_j\right)\leftarrow \left({\bigcup }_{i\in \mathtt{shards}\left({\tau }_j\right)}{R}_{\mathtt{code}}^i\left({\tau }_j\right)\right)\cup \left({\bigcup }_{i\in \mathtt{shards}\left({\tau }_j\right)}{R}_{\mathtt{state}}^i\left({\tau }_j\right)\right)$	▹ Read set
4:       $W\left({\tau }_j\right)\leftarrow {\bigcup }_{i\in \mathtt{shards}\left({\tau }_j\right)}{W}_{\mathtt{state}}^i\left({\tau }_j\right)$	▹ Write set
5:       $\mathtt{AccessSet}\leftarrow R\left({\tau }_j\right)\cup W\left({\tau }_j\right)$	▹ Combine read and write sets
6:       ${\mathtt{Path}}_{\mathtt{j}}\leftarrow \mathtt{ComputeMerklePath}(\mathtt{AccessSet},{\mathtt{V}}_{\mathrm{current}})$	▹ Compute Merkle path for code and state access
7:       $\mathtt{MerkleProofs}\leftarrow \mathtt{MerkleProofs}\cup {\mathtt{Path}}_{\mathtt{j}}$	▹ Add to proof set
8: end for
9: ${\mathtt{Proof}}_{{\mathcal{E}}_i}\leftarrow {\mathtt{RAttest}}_{{\mathcal{E}}_i}\left(\mathtt{MerkleProofs}\right)$	▹ Attest combined proofs
10: return ${\mathtt{Proof}}_{{\mathcal{E}}_i}$	▹ Return unified proof for verification

4.2. State-Aware Cross-Shard Commit Protocol

To enhance concurrent execution of cross-shard contracts, we propose the State-Aware Cross-shard Commit Protocol (SACP). SACP tracks transactional dependencies over snapshots—versioned representations of the global cross-shard contract state encoded via Merkle roots (e.g., ${\mathrm{MPT}}_{i-2}$). The protocol proceeds in rounds, each operating on a fixed snapshot maintained by $S_c$. Transactions referencing the same snapshot can be executed in parallel off-chain by $\left\{{\mathcal{E}}_i\right\}$ while ensuring consistency. At the end of each round, $S_c$ finalizes the updated Merkle root, dispatches validated transactions to corresponding shards for on-chain commitment, and synchronizes the updated state with $\left\{{\mathcal{E}}_i\right\}$.

Figure 3 illustrates the overall workflow of SACP in handling cross-shard transactions, which comprises four main stages.

• Transaction Generation and Initial Forwarding. After a client initiates a smart contract invocation, the system generates the corresponding transaction $\tau$ and routes it to the shard $S_i$ where the target contract is deployed. Upon receiving $\tau$, shard $S_i$ performs an initial classification.
  Specifically, we determine the number of shards involved in $\tau$ by evaluating:

  $$\tau :\left\{\begin{array}{cc}\mathrm{Cross-}\mathrm{shard},\hfill & \mathrm{if}\left|\mathtt{shards}\right(\tau \left)\right|>1\hfill \\ \mathrm{Intra-}\mathrm{shard},\hfill & \mathrm{if}\left|\mathtt{shards}\right(\tau \left)\right|=1\hfill \end{array}\right.$$

  (6)

  where $\left|\mathrm{shards}\right(\tau \left)\right|$ denotes the number of shards involved in executing transaction $\tau$.
  If the condition $\left|\mathtt{shards}\right(\tau \left)\right|>1$ holds, $\tau$ is identified as a cross-shard transaction. In this case, it is forwarded to the coordinator shard $S_c$, which subsequently dispatches it to a trusted execution node ${\mathcal{E}}_i$ within the Off-chain Execution Hub. Conversely, if $\left|\mathtt{shards}\right(\tau \left)\right|=1$, $\tau$ is classified as an intra-shard contract invocation, and its execution and consensus are completed locally within $S_i$.
• Batch Scheduling and Epoch Partitioning. $S_c$ maintains a transaction pool for all incoming cross-shard transactions $\tau$. During scheduling round $e_k$, $S_c$ analyzes the transaction pool to detect dependency conflicts, taking into account both read/write sets and arrival time order. Transactions are then partitioned into a collection of batches ${\mathrm{Tx}}_i$, with each element ${\mathrm{Tx}}_i$ denoting the i-th batch of transactions. The partitioning aims to minimize intra-batch dependencies while consistently grouping conflicting transactions. The dependency relation is defined as:

  $$\begin{array}{cc}\hfill \mathrm{Dep}({\tau }_i,{\tau }_j)\iff & \left(W\left({\tau }_i\right)\cap R\left({\tau }_j\right)\ne ⌀\right)\vee \left(W\left({\tau }_j\right)\cap R\left({\tau }_i\right)\ne ⌀\right)\hfill \\ \hfill & \vee \left(W\left({\tau }_i\right)\cap W\left({\tau }_j\right)\ne ⌀\right)\hfill \end{array}$$

  (7)
  As illustrated in Figure 4, each batch is assigned to a specific state snapshot $V_{k-2}$, where k corresponds to the index of the current scheduling round $e_k$, for off-chain execution. Meanwhile, newly arriving transactions are continuously evaluated against ongoing batches. If conflict-free, a transaction $\tau$ is scheduled into the next epoch $e_{k+1}$; otherwise, it is recursively reassigned based on dynamic conflict analysis, ensuring it is grouped into an executable batch once dependency conditions permit.
• Off-chain Execution and Proof Submission.During the off-chain execution phase, each cross-shard transaction $\tau$ is dispatched to a designated trusted execution node ${\mathcal{E}}_i$ according to the scheduling strategy. Following the design of the trusted execution engine, the node sequentially executes Algorithms 1 and 2 and to process the transactions and generate the corresponding correctness proof. Upon completion, ${\mathcal{E}}_i$ submits the batched results and their unified integrity proof to the coordinating shard. The submission is structured as follows:

  $$\begin{array}{cc}\hfill {\mathrm{Pkg}}_{{\mathcal{E}}_i}=& \langle \mathrm{Result}\left({\mathcal{T}}_{{\mathcal{E}}_i}\right),R\left({\mathcal{T}}_{{\mathcal{E}}_i}\right),\hfill \\ \hfill & W\left({\mathcal{T}}_{{\mathcal{E}}_i}\right),V_{i-2},{\mathrm{Proof}}_{{\mathcal{E}}_i}\rangle \hfill \end{array}$$

  (8)
  The $S_c$ can verify the integrity and correctness of all cross-shard transactions processed by ${\mathcal{E}}_i$ through a single validation of the aggregated proof, ensuring that the execution was free from state tampering.
• On-chain Verification and State Update. The coordinating shard $S_c$ verifies the remote attestation signatures associated with the aggregated transaction set ${\mathrm{Tx}}_i$, which comprises all valid execution results submitted by off-chain execution nodes $\left\{{\mathcal{E}}_i\right\}$ during epoch $e_k$. Since each node ${\mathcal{E}}_i$ provides a single batch-level proof, only one signature verification per node is required, significantly reducing the cost of transaction validation. Once verified, the aggregated write set $W\left({\mathrm{Tx}}_i\right)$—comprising all valid write operations in ${\mathrm{Tx}}_i$—is applied to derive the new global snapshot $V_i$, which is then propagated to $\left\{{\mathcal{E}}_i\right\}$ via a dedicated synchronization channel.

  $$V_i=V_{i-2}\oplus W\left({\mathrm{Tx}}_i\right)$$

  (9)
  Importantly, the execution in $e_i$ is based on the snapshot $V_{i-2}$, while the snapshot $V_{i-1}$, produced by $e_{i-1}$, is being finalized and synchronized in parallel across shards. This decoupling between execution and synchronization enables $e_i$ to proceed without waiting for the confirmation and dissemination of $V_{i-1}$.

Protocol Extensions. The proposed protocol allows flexible conflict analysis strategies. Depending on system requirements, different methods—such as static call-graph analysis or dynamic runtime tracking—can be used to identify inter-contract dependencies.

In addition, a lightweight retry mechanism is integrated at the coordinating shard. Failed contract executions may be re-scheduled off-chain if dependencies and deadlines permit; otherwise, a failure response is returned to the user. This improves robustness without increasing on-chain complexity.

4.3. Contract-Migration Mechanism

As a sharded blockchain system operates over time, users continuously deploy various types of smart contracts, including those with cross-shard dependencies. This gradually increases the proportion of cross-shard contracts. The effect becomes more pronounced as the number of shards grows, since additional shard boundaries naturally create more potential interaction points, thereby further elevating the overall fraction of cross-shard contracts in the system [23]. To mitigate this issue, we design a dynamic contract-migration mechanism that adjusts contract placement based on invocation characteristics and system workload. Specifically, we formulate contract placement as a multi-objective combinatorial optimization problem, jointly considering invocation frequency, communication overhead, and load balancing. Leveraging the global search capability of genetic algorithms and their suitability for nonlinear, multi-objective optimization, we determine the optimal migration strategy for cross-shard smart contracts.

4.3.1. Problem Formulation and Objective Function

Let $\mathcal{C}=c_1,c_2,\dots ,c_N$ denote the set of N smart contracts identified from transaction logs within a specific time window, and let $\mathcal{S}=s_1,s_2,\dots ,s_M$ represent the set of M execution shards. A placement solution is represented by a vector $\mathit{x}=(x_1,x_2,\dots ,x_N)$, where each element $x_i\in 1,2,\dots ,M$ indicates that contract $c_i$ is assigned to shard $s_{x_i}$. The objective is to determine the optimal placement vector ${\mathit{x}}^{*}$ that minimizes a given global cost function.

Based on historical invocation data, we define the following metrics:

• Interaction Groups ($\mathcal{G}$): A set of frequent interaction groups $\mathcal{G}=\{g_1,g_2,\dots ,g_K\}$, where each group $g_k\subseteq \mathcal{C}$ contains contracts that frequently interact.
• Contract Load (${\mathsf{\Gamma }}_i$): The invocation frequency of an individual contract $c_i$, representing its computational load.
• Group Communication Intensity ($W_k$): The total invocation frequency within an interaction group $g_k$, reflecting its communication needs.

The overall objective function to be minimized, $F\left(\mathit{x}\right)$, combines two competing goals: minimizing cross-shard communication and balancing the load across shards.

$$F\left(\mathit{x}\right)=F_{\mathrm{comm}}\left(\mathit{x}\right)+\lambda ·F_{\mathrm{balance}}\left(\mathit{x}\right)$$

(10)

The two components are defined as follows:

• Communication Cost ($F_{\mathrm{comm}}$): This term measures the overhead from splitting frequently interacting contracts across different shards.

  $$F_{\mathrm{comm}}\left(\mathit{x}\right)=\sum _{k=1}^K{W}_k·\delta (g_k,\mathit{x})$$

  (11)
  Here, $\delta (g_k,\mathit{x})$ is an indicator function that equals 1 if the contracts in group $g_k$ are assigned to multiple shards under the placement $\mathit{x}$, and 0 otherwise.
• Load Imbalance Penalty ($F_{\mathrm{balance}}$): This term measures the load disparity among shards, calculated as the standard deviation of shard loads.

  $$F_{\mathrm{balance}}\left(\mathit{x}\right)=\sqrt{{\displaystyle \frac{1}{M}}\sum _{j=1}^M{\left(L_j\left(\mathit{x}\right)-L_{\mathrm{avg}}\right)}^2}$$

  (12)
  Here, $L_j\left(\mathit{x}\right)={\sum }_{\{i:x_i=j\}}{\mathsf{\Gamma }}_i$ is the total computational load on shard $s_j$. $L_{\mathrm{avg}}={\displaystyle \frac{1}{M}}{\sum }_{i=1}^N{\mathsf{\Gamma }}_i$ is the average load per shard across the entire system.

The weight parameter $\lambda$ balances the trade-off between minimizing communication costs and ensuring load distribution. To determine an appropriate value for $\lambda$, we conduct empirical tests using historical transaction logs.

4.3.2. Enhanced Genetic Algorithm Design (EGA)

To address the above issues, we adopt an Enhanced Genetic Algorithm (EGA), with the complete workflow presented in Algorithm 3. The algorithm incorporates an interaction-aware heuristic strategy: when constructing the initial population, it does not rely solely on random allocation, but instead leverages the observed contract interaction groups ($\mathcal{G}$) to guide the placement of certain cross-shard contracts. On the one hand, this approach fully exploits interaction information within the time window, thereby improving the quality of the initial shard allocation; on the other hand, probabilistic grouping and random exchanges are introduced to avoid excessive concentration of contracts, thus enhancing both the diversity and efficiency of the search process. In addition, since genetic algorithms are generally designed to maximize fitness, we define the fitness function as the negative of the objective function:

$$\mathrm{Fit}\left(\mathit{x}\right)=-F\left(\mathit{x}\right)$$

(13)

Algorithm 3 Enhanced Genetic Algorithm (EGA) for Contract Placement

Require:  Contract set $\mathcal{C}$, Interaction groups $\mathcal{G}$, Population size $\left|\mathcal{P}\right|$, Shard set $\mathcal{S}$, Maximum generations G Ensure:  Optimal placement ${\mathit{x}}^{*}$   1: Initialize population $\mathcal{P}$ with $\left|\mathcal{P}\right|$ individuals using interaction-aware heuristic:   2: for all interaction group $g_k\in \mathcal{G}$ do   3:       With probability $p=0.7$, assign all $c_i\in g_k$ to the same random shard   4: end for   5: Assign remaining contracts randomly across shards   6: Perform random gene swaps to improve diversity   7: for $t=1$ to G do   8:       for all $\mathit{x}\in \mathcal{P}$ do   9:             Evaluate fitness: $\mathrm{Fit}\left(\mathit{x}\right)=-F\left(\mathit{x}\right)$ 10:       end for 11:       Select parents via tournament selection 12:       Apply segment-based crossover to generate offspring 13:       Compute fitness variance ${\sigma }^2$ using Equation (15) 14:       Adjust mutation rate $p_m$: 15:       if ${\sigma }^2<0.1$ then                                 ▹ Premature convergence 16:             $p_m\leftarrow 0.3$ 17:       else if ${\sigma }^2>0.5$ then                             ▹ High diversity 18:             $p_m\leftarrow 0.05$ 19:       else 20:             $p_m\leftarrow 0.1$ 21:       end if 22:       Mutate offspring by reassigning contracts with rate $p_m$ 23:       Retain elite individual ${\mathit{x}}^{*}$ with highest fitness 24:       Local search: For ${\mathit{x}}^{*}$, generate neighbor $\mathit{x}$ by migrating one contract 25:       if $\mathrm{Fit}\left(\mathit{x}\right)>\mathrm{Fit}\left({\mathit{x}}^{*}\right)$ then 26:             ${\mathit{x}}^{*}\leftarrow \mathit{x}$ 27:       end if 28:       Form new population ${\mathcal{P}}^{\prime }$ using ${\mathit{x}}^{*}$ and best offspring 29:       $\mathcal{P}\leftarrow {\mathcal{P}}^{\prime }$ 30: end for 31: return ${\mathit{x}}^{*}$ as final solution

The main workflow of the algorithm can be summarized as follows:

• Initialization: Each chromosome in the population is a placement vector $\mathit{x}$. We use an interaction-aware strategy to create a high-quality initial population of 100 individuals:
  • With a probability of $p=0.7$, all contracts within a high-frequency interaction group $g_k$ are assigned together to a randomly selected shard.
  • Any remaining contracts are distributed randomly across all shards.
  • To enhance diversity, several rounds of random pairwise gene swaps (reassigning two contracts’ shards) are performed.
• Evolutionary Operators:
  • Selection:
    Candidate solutions are evaluated based on communication cost and load balance. Tournament selection is employed to preserve diversity while ensuring convergence.
  • Crossover: For two parent plans, a segment $[i,j]$ is randomly selected and swapped, transferring shard assignments for contracts $c_i$ through $c_j$. This simulates partial batch migration, enhancing deployment diversity.
  • Mutation: A contract $c_i$ is randomly reassigned from shard $s_{x_i}$ to $s_{x_i^{\prime }}$. The mutation rate $p_{\mathrm{m}}$ is adaptively adjusted based on population variance ${\sigma }^2$:

    $$p_m=\left\{\begin{array}{cc}0.3\hfill & \mathrm{if}{\sigma }^2<0.1\hfill \\ 0.05\hfill & \mathrm{if}{\sigma }^2>0.5\hfill \\ 0.1\hfill & \mathrm{otherwise}\hfill \end{array}\right.$$

    (14)
    The fitness variance is calculated as:

    $${\sigma }^2={\displaystyle \frac{1}{\left|\mathcal{P}\right|}}\sum _{i=1}^{\left|\mathcal{P}\right|}{({\mathrm{Fit}}_i-\overline{\mathrm{Fit}})}^2$$

    (15)

    where ${\mathrm{Fit}}_i$ is the fitness of the i-th individual and $\overline{\mathrm{Fit}}$ is the average fitness of the population $\mathcal{P}$.
• Local Enhancement Mechanisms:
  • Elitism: The best individual ${\mathit{x}}^{*}$ is preserved each generation to prevent loss of optimal strategies.
  • Neighborhood Search: A greedy local search perturbs ${\mathit{x}}^{*}$ by migrating a single contract $c_k$. A refined solution $\mathit{x}\in \mathcal{N}\left({\mathit{x}}^{*}\right)$ is adopted if:

    $$\mathrm{Fit}\left(\mathit{x}\right)>\mathrm{Fit}\left({\mathit{x}}^{*}\right)\Rightarrow {\mathit{x}}^{*}\leftarrow \mathit{x}$$

    (16)
    This lightweight adjustment improves global deployment effectiveness.
• Termination Criteria: The evolutionary process terminates when either:
  • The maximum number of generations (e.g., 500) is reached.
  • The population converges, the best fitness improvement is below a threshold (e.g., 0.01%) for 10 consecutive generations.

To manage cross-shard contract states efficiently, we adopt an MPT-based data structure that supports their modification and migration. Building on this and following [34], we implement asynchronous state migration to further enhance migration efficiency.

5. Analysis and Implementation

This section is organized as follows: we begin with an analysis of the system in terms of correctness, liveness, and scalability, followed by a detailed description of its implementation.

5.1. Analysis

Correctness. We formalize the correctness of the proposed framework from two aspects: conflict-freedom and state consistency.

Let $\mathcal{R}\left(\tau \right)$ and $\mathcal{W}\left(\tau \right)$ denote the read and write sets of a cross-shard contract $\tau$, respectively. We say that two contracts ${\tau }_i$ and ${\tau }_j$ are in conflict, denoted as $\mathrm{Conflict}({\tau }_i,{\tau }_j)$, if and only if the condition in Equation (7) holds. Before execution, the coordinator shard $S_c$ performs dependency analysis over all pending cross-shard contracts and partitions them into a sequence of batches $\left\{V\right\}=\{V_1,V_2,\dots ,V_i\}$. Each batch $V_k\in \left\{V\right\}$ contains a set of transactions that are free of conflicts and thus can be executed in parallel. Furthermore, the partitioning ensures that adjacent batches are also mutually conflict-free, i.e., no transaction in $V_k$ conflicts with any transaction in $V_{k+1}$. Within each batch $V_k$, contracts are deterministically ordered by timestamp. This guarantees:

$$\forall {\tau }_i,{\tau }_j\in V_k,\neg \mathrm{Conflict}({\tau }_i,{\tau }_j)$$

(17)

ensuring conflict-freedom.

For state consistency, intra-shard contracts are maintained by their local shards, while cross-shard contract states are decoupled between $S_c$ and the set of off-chain trusted execution nodes $\left\{{\mathcal{E}}_i\right\}$. We employ a State-Aware Cross-shard Commit Protocol ensuring that no dependency edges exist between two adjacent rounds $V_k$ and $V_{k+1}$. Inspired by Multi-Version Concurrency Control (MVCC), contracts in $V_k$ execute over the stable snapshot $V_{k-2}$, while valid contracts in $V_{k-1}$ update the state through secure state channels between $S_c$ and $\left\{{\mathcal{E}}_i\right\}$, producing $V_{k-1}$.

Assume that for all $j\le k-1$, $V_j$ is consistent and corresponds to some serial execution prefix. Since SACP guarantees that (1) all transactions in $V_k$ are mutually conflict-free, (2) $V_k$ and $V_{k+1}$ have no dependency edges, and (3) $V_k$ reads from a consistent $V_{k-2}$, all transactions in $V_k$ can be executed concurrently and applied in a deterministic order (e.g., the fixed timestamp order maintained by $S_c$), yielding a unique $V_k$. Any write–write conflicts or cyclic dependencies are resolved beforehand by SACP through ordering rules or abort–retry, preventing divergence.

Therefore, $V_k$ is derived from a conflict-free execution over $V_{k-2}$, and $V_k$ is equivalent to some serial execution of all committed transactions up to round k. By induction on k, the global state V evolves without divergence across shards.

Combining SACP with pre-execution conflict prevention, the system guarantees that all committed transactions preserve state invariants and no illegal interleaving can cause inconsistency, thereby satisfying global correctness.

Liveness. We analyze the liveness of the system from both intra-shard and cross-shard levels.

At the intra-shard level, Let ${\mathsf{\Pi }}_s$ denote the shard-local consensus protocol, based on Byzantine Fault Tolerance (BFT). By offloading cross-shard contract execution to off-chain trusted execution environments $\left\{{\mathcal{E}}_i\right\}$, we decouple consensus from inter-shard interactions. Thus, ${\mathsf{\Pi }}_s$ maintains uninterrupted progress regardless of inter-shard-execution delays. The local transaction flow remains non-blocking, ensuring shard-level liveness. At the cross-shard level, we define a cross-shard transaction $\tau$ as live if it is either committed or deterministically rejected within a bounded time window. The system adopts a SACP, which enables deadlock detection and prioritization. Each transaction $\tau$ has a bounded execution window ${\Delta }_{\tau }$. If $\tau$ is not resolved within ${\Delta }_{\tau }$, the system performs:

• Retry: If $\tau$ remains feasible, it is rescheduled at a new position.
• Abort: If infeasible, it is rejected and feedback is returned to the user.

This ensures $\forall \tau$, one of the following holds: $\exists t<T$ (where T is the maximum allowed execution time for $\tau$): $\tau \mapsto \mathtt{commit}$ or $\tau \mapsto \mathtt{abort}$.

Combining asynchronous execution and bounded scheduling guarantees that all valid transactions eventually terminate, satisfying global liveness.

Scalability. The scalability of the system is ensured through asynchronous execution, dynamic contract migration, and optimized cross-shard communication.

First, cross-contract-execution tasks are fully delegated to $\left\{{\mathcal{E}}_i\right\}$, decoupling shard consensus from execution processes. This design enables horizontal scaling by increasing the number of execution nodes, thereby improving overall throughput. Second, to avoid execution hotspots and resource imbalances, a GA-based contract-migration mechanism is implemented. Using a fitness function constructed from call frequency and cross-shard balance, the system periodically converts high-frequency cross-shard calls into intra-shard contracts and relocates contracts to low-load shards. This enhances execution locality and reduces cross-shard invocations. Third, cross-shard communication employs batching strategies. Off-chain nodes $\left\{{\mathcal{E}}_i\right\}$ decouple the world state of cross-shard smart contracts and compress execution results with ${\mathrm{Proof}}_{{\mathcal{E}}_i}$. This prevents exponential growth in communication complexity as shard numbers increase, avoiding throughput limitations while effectively controlling confirmation latency for cross-shard smart contracts. In addition, as a core component of the system, $S_c$ leverages the inherent properties of blockchain to maintain security and avoid single points of failure. In scenarios with a large number of cross-shard transactions, $S_c$ also has the potential to scale through sharding, thereby reducing the risk of becoming a performance bottleneck.

In summary, the system maintains near-linear throughput growth when expanding shard quantity and execution resources, while effectively controlling cross-shard coordination overhead, thus achieving strong scalability.

5.2. Implementation

The prototype implementation of our system is divided into two core components: the on-chain execution environment and the Off-chain Execution Hub. These components are responsible for smart contract coordination and secure execution, respectively.

For the on-chain component, we adopt ChainMaker [31] as the underlying platform. Leveraging its native support for multiple consensus protocols and smart contract languages, we can flexibly deploy the $S_c$ and $\left\{S_i\right\}$ in the system model, providing fundamental support for blockchain functionalities. Furthermore, to build a sharding network that meets the requirements and ensure the correct execution logic of cross-shard transactions, we draw on the core implementation ideas of blockEmulator [1,35] and design a cross-shard transaction routing and execution mechanism adapted to the architecture of this system.

For the off-chain component, we design Off-chain Execution Hub composed of multiple trusted execution nodes. Each node is built on Intel SGX [36], providing hardware-level isolation and protection. Occlum [37] is selected as the runtime environment—a lightweight library OS that leverages SGX-based trusted execution environment to securely load contract code, state data, and runtime context. It ensures the confidentiality and integrity of contract execution. Moreover, Occlum supports remote attestation, allowing each execution to produce verifiable proofs. These proofs can be validated by on-chain verification nodes, establishing a closed-loop trust mechanism between on-chain validation and off-chain execution. For clarity, the key implementation details are summarized in

Table 2. Prototype implementation configurations.

Component	Configuration/Tool
Blockchain Platform	ChainMaker 2.3.3
Consensus Protocols	PBFT, Raft
Sharding Emulator	BlockEmulator v1.0
Coordinator/Shards	$S_c$ (1), $\left\{S_i\right\}$ (4–16)
TEE Runtime	Intel SGX SDK v2.2, Occlum v0.28.0
Programming Language	Solidity (v0.7.5, smart contracts), Go (v1.19, system logic)
Proof Mechanism	Merkle-based correctness proofs

.

6. Performance Evaluation and Discussion

This section presents a comprehensive evaluation of the proposed framework. We first describe the experimental setup, followed by throughput analysis, average confirmation latency, and contract-migration results, and finally provide an overall discussion of the observed trends. All reported results are averaged over 10 independent runs, and error bars represent 95% confidence intervals computed using the Student’s t-distribution.

6.1. Setup

Datasets. We collected historical transaction data and corresponding smart contract code from Etherscan, covering the Ethereum mainnet from June to December 2024. After preprocessing, 500 smart contracts were selected based on diversity in invocation frequency and functional category. To simulate realistic cross-shard workloads, we transformed a subset of intra-shard calls into cross-shard interactions using actual call graphs extracted from the transaction history. These cross-shard contracts account for 45% of the dataset. To provide a clearer understanding, the detailed characteristics of the dataset are presented in

Table 3. Characteristics used for experimental evaluation.

Feature	Value
Data Source	Ethereum Mainnet (Etherscan)
Time Range	June–December 2024
Cross-shard Transactions	45.0%
Smart Contracts (selected)	500 (chosen for diversity)
Selection Criteria	Invocation frequency, functional category
Cross-shard Contract Ratio	45%
Contract Types	intra-shard, cross-shards
Avg. Contract Degree	2.7
Shard Count	4–16
Smart Contract Code	Solidity bytecode
Data Format	CSV (call graphs)

.

Comparisons. We compare our system against two representative sharding frameworks: ByShard [8] and LightCross [11]. Byshard adopts a classical locking-based mechanism where all involved contracts are synchronously locked during cross-shard execution to ensure correctness. LightCross represents a newer TEE-based approach, where contract execution is offloaded from the main chain to secure off-chain components. All three systems were implemented under identical hardware and software environments to ensure fair comparison.

Testbed. Experiments were conducted on a server cluster. Each machine is equipped with 20 Intel(R) Xeon(R) Silver 4210 2.20 GHz CPU cores, 32 GB RAM, and 500 GB SSD. The system leverages Intel SGX SDK v2.2 and Occlum v0.28.0 to deploy the off-chain execution hub. The testbed includes one coordinator shard $S_c$ and multiple execution shards $\left\{S_i\right\}$, enabling performance evaluation under varying shard counts. The off-chain execution hub comprises 16 trusted execution nodes that handle contract-execution tasks. Meanwhile, considering the complexity of real-world networks and in order to approximate wide-area deployment scenarios, we followed the approach of LightCross by dividing the system’s nodes into six groups to emulate distribution across different geographic regions. By assigning differentiated bandwidth constraints to nodes in different regions, we constructed a network environment that more closely resembles real-world conditions, thereby enabling a more realistic evaluation of system performance.

6.2. Throughput

We begin by evaluating the system throughput performance using Transactions Per Second (TPS), a widely adopted metric in blockchain systems. In the context of blockchain, TPS is formally defined as:

$$\mathrm{TPS}={\displaystyle \frac{N_{\mathrm{confirmed}}}{\Delta t}}$$

(18)

where $N_{\mathrm{confirmed}}$ represents the total number of transactions successfully confirmed by the system, and $\Delta t$ denotes the time interval (in seconds) over which these transactions are counted.

The experiments are designed to evaluate system performance under two key dimensions: (1) the total number of execution shards configured in the system, and (2) the average number of distinct shards accessed per cross-shard smart contract, including both read and write operations.

As shown in Figure 5a, all systems exhibit increasing TPS with more shards, highlighting the parallel scalability of sharded architectures. However, under the same shard count, there are significant throughput differences across systems. The proposed framework achieves up to 5.3× and 2.1× higher throughput compared to Byshard and LightCross, respectively. Despite this, linear scalability is not fully achieved due to the additional communication and synchronization overhead introduced by cross-shard contracts. The fundamental divergence in how each system handles cross-shard transactions is a key factor affecting performance.

To further assess the impact of cross-shard complexity, we set the number of execution shards to 6 and gradually increase the number of shards involved per contract (from 2 to 5). As shown in Figure 5b, TPS decreases as the number of involved shards grows, across all systems. Nevertheless, the proposed framework consistently outperforms the baselines, with a notably smaller performance drop. Even under the most demanding scenario involving all six shards ($\left|\mathrm{shards}\right(\tau \left)\right|=6$), it maintains a 1.3× higher TPS than LightCross.

Specifically, Byshard employs a lock-based cross-shard commit protocol, which ensures consistency but severely limits concurrency. LightCross introduces off-chain execution but still requires repeated on-chain synchronization for contract code and state before and after each execution, leading to significant inefficiencies. In contrast, the proposed framework pushes the global state of cross-shard contracts off-chain and enables parallel execution through a state-aware cross-shard commit protocol. This design significantly reduces synchronization overhead between on-chain and off-chain components, resulting in higher throughput under complex cross-shard scenarios.

6.3. Average Confirmation Latency

We further evaluate the confirmation latency of each system during smart contract execution, using Average Confirmation Latency (ACL) as the primary metric. The evaluation is conducted along the same two dimensions as above: (1) the number of execution shards, and (2) the number of shards involved per cross-shard contract, which reflects its execution complexity.

As shown in Figure 6a, the confirmation latency of all three systems increases with the number of on-chain shards. This trend is primarily due to rising communication overhead in scheduling, state synchronization, and consensus during cross-shard execution. Among them, the proposed framework consistently achieves the lowest latency, reducing average delay by up to 51% compared to LightCross under equivalent conditions.

To further assess the impact of cross-shard complexity, we fix the number of shards to 6 and gradually increase the number of shards involved in each contract. As illustrated in Figure 6b, all systems experience a notable increase in latency as contract complexity rises, with divergence becoming more prominent under high-complexity scenarios. ByShard exhibits the highest delay, reaching nearly 20 s, and shows exponential growth as complexity increases. This is primarily due to its lock-based synchronized execution, where contract states across all involved shards are globally locked and contract logic is executed serially, requiring multiple rounds of inter-shard consensus and communication.

In contrast, both the proposed framework and LightCross employ off-chain execution mechanisms that decouple contract execution from on-chain consensus, with only final results committed for verification. This substantially reduces synchronization and communication overhead, keeping average confirmation latency below 3 s in most cases.

Among the two, the proposed framework performs best. Even under the most complex setting ($\left|\mathrm{shard}\right(\tau \left)\right|=6$), it reduces average latency by approximately 40% compared to LightCross. This improvement stems from joint off-chain migration of both contract logic and associated state, effectively mitigating execution blocking and verification delay. In LightCross, although execution occurs off-chain, repeated on-chain access is still required for fetching contract code and state, followed by re-validation, which introduces additional overhead. It should be noted that, despite its advantages, the confirmation latency of our proposed framework still increases with contract complexity. This is because more complex contracts necessitate greater off-chain coordination and communication, limiting the linear scalability of confirmation time.

In addition, we evaluated the performance overhead introduced by remote attestation. The results show that the hardware resources consumed for generating attestations account for only about 5% of the total execution cost at each node, and the impact on the system’s overall throughput and latency remains limited.

6.4. Contract Migration

This section aims to evaluate the impact of contract migration on system performance. Although contract migration inevitably introduces some overhead, we adopt a unified experimental setup to ensure fair comparison: migrations are triggered periodically at fixed time intervals. Each system prototype is configured with six shards, and the initial proportion of cross-shard contracts is set to 30%. During each migration epoch, new contracts are deployed at a uniform rate, gradually increasing the proportion of cross-shard contracts to 45%. The migration strategy targets contracts involved in transactions from the previous epoch, selecting and redistributing them based on the frequency of cross-shard interactions. For systems that do not support contract migration (e.g., Byshard), we simply increase the cross-shard contract ratio from 30% to 45% to observe how throughput changes as cross-shard interactions increase. In contrast, for systems equipped with contract-migration mechanisms (e.g., LightCross), the migration strategy is activated once the cross-shard contract ratio reaches 45%, allowing us to assess the effectiveness of dynamic redistribution in mitigating performance degradation.

Figure 7a illustrates how system throughput evolves over time. As more contracts are deployed, the number of cross-shard contracts increases, resulting in a steady decline in throughput. When the migration mechanism is triggered at the end of each epoch, the proportion of cross-shard contracts drops (up to a minimum of 23%), leading to a recovery in throughput. This “decline–recovery–decline” pattern reveals that contract migration can alleviate performance bottlenecks caused by excessive cross-shard interactions.It is worth noting that as the proportion of cross-shard contracts increases, the throughput of Byshard continues to decline. Due to the lack of a contract-migration mechanism, there is no sign of recovery in its throughput.

However, due to the cumulative growth in the number of contracts over time, some epochs show that overall throughput does not fully return to the previous level. This indicates that the effectiveness of contract migration is highly dependent on the quality of the migration strategy. As shown in Figure 7b, our proposed solution outperforms LightCross in controlling throughput degradation. The main advantage lies in the use of a genetic algorithm-based dynamic migration strategy, which keeps the proportion of cross-shard contracts around 25% and achieves better load balancing—reducing the load on certain hotspots by up to 63% compared to the previous epochs.

Figure 7b presents the contract confirmation latency observed under different solutions across varying numbers of shards. Immediately after migration, the proposed framework achieves significantly lower average confirmation latency compared to LightCross, with a maximum reduction of 52.6%. This improvement is attributed to two key factors: the reduction in cross-shard contract ratio, and the use of SACP that minimizes synchronization overhead, thereby streamlining the confirmation process and enhancing execution efficiency.

6.5. Discussion

As analyzed earlier, the primary bottleneck of existing sharding systems lies in the increasing proportion of cross-shard contracts, which not only incurs significant communication overhead but also ultimately undermines system scalability. In our evaluation, we select throughput and cross-shard latency as the core performance metrics to verify whether this bottleneck can be effectively alleviated. Experimental results demonstrate that, compared with baseline approaches (ByShard [8] and LightCross [11]), our proposed framework achieves a substantial improvement in throughput while simultaneously reducing latency. Furthermore, the proposed cross-shard contract-migration strategy effectively controls the proportion of cross-shard contracts, thereby mitigating the burden of cross-shard interactions. As a result, the system can maintain stable performance even when the number of shards increases or the workload becomes more complex. These findings indicate that the proposed framework provides an effective solution to the key challenges of cross-shard contract execution.

7. Conclusions

This paper proposes a novel sharded blockchain framework that integrates Trusted Execution Environments to address the scalability and efficiency challenges of cross-shard smart contract execution. Specifically, the system introduces off-chain trusted execution nodes and a dedicated state storage module to enable secure and efficient state access. In addition, a state-aware cross-shard commit protocol is designed to reduce on-chain coordination overhead, and a migration mechanism based on Genetic Algorithms (GA) is proposed to optimize contract placement across shards. Experimental results show that, compared with representative baseline schemes, the proposed framework consistently achieves at least a 2.1× improvement in throughput and reduces cross-shard latency by more than 52.6%. Furthermore, the migration strategy reduces the proportion of cross-shard contracts from 45% to below 30%, enabling the system to maintain stable performance even as the number of shards increases or the workload complexity grows.

Nevertheless, this study has certain limitations. The GA-based migration strategy introduces additional computational overhead, which may require fine-grained tuning in large-scale deployments. Moreover, our security analysis follows standard TEE assumptions and does not explicitly address low-level threats such as side-channel attacks. As future work, we plan to explore lightweight alternatives to GA-based migration, incorporate defense mechanisms against TEE-specific vulnerabilities, and evaluate the framework under real-world blockchain workloads. These efforts will further enhance the practicality, security, and robustness of the proposed framework.