Smart contract fragmentation method

Abstract

The invention discloses an intelligent contract fragmentation method. Comprising the following steps: dividing each fragment into an original fragment (storing a smart contract) and a coded fragment (verifying an execution result of the smart contract of the original fragment) by adopting an information code with a local repair characteristic, and performing on-chip consensus on each transaction for calling the smart contract in the stored original fragment, and the consensus result is verified by a plurality of coding fragments corresponding to the original fragment. On the basis of the architecture, a static region and fine-grained smart contract state lock is provided, and the smart contract state of cross-fragment transaction is managed, so that the execution efficiency of calling the smart contract in another fragment by the smart contract in one fragment can be improved; and the concurrent processing efficiency of calling the smart contract in the same fragment by the smart contracts in multiple fragments can be improved. Meanwhile, when the state of the smart contract on any fragment is damaged, joint decoding operation can be carried out through a plurality of verified smart contract state sets on the fragments associated with the fragment so as to recover the state of the smart contract. The method is especially suitable for a distributed application scene in which a large number of intelligent contract transactions need to be efficiently processed.

Description

Technical Field

[0001] This invention relates to the fields of smart contracts and blockchain technology, and to a smart contract sharding method, which is particularly suitable for distributed application scenarios that require efficient processing of a large number of smart contract call transactions. Background Technology

[0002] Smart contracts, as a core application of blockchain technology, realize decentralized business logic through programmable automated protocols. However, existing smart contract systems face the following key technical bottlenecks under sharding architectures: When smart contracts in different shards call each other, complex cross-shard communication is required for smart contract state synchronization, leading to increased execution latency and reduced throughput; existing sharding schemes use a locking mechanism to manage contract state access, limiting concurrency and reducing throughput when different shards call the same smart contract; smart contracts in different shards are interdependent, potentially forming call chains, allowing failures in the state of a single smart contract to propagate through the contract call path, triggering systemic risks. These issues constrain the actual performance of smart contracts in applications.

[0003] Chinese invention patent CN116545588B discloses a sharded blockchain system based on repairable fountain codes. This system divides shards into original shards and encoded shards, achieving data recovery through the encoded shards. However, this patent fails to address a key issue in the sharded execution of smart contracts.

[0004] Chinese invention patent CN118802949A discloses an asynchronous execution scheme for smart contracts, which separates smart contract execution from the blockchain block generation process, thereby improving transaction processing efficiency. However, this scheme does not consider the atomicity guarantee of cross-shard contract execution and does not resolve the state access conflict problem. Summary of the Invention

[0005] The technical problem to be solved by the present invention is to provide a smart contract sharding system that can achieve efficient smart contract execution.

[0006] To solve the above-mentioned technical problems, the present invention adopts the following technical solution: like Figure 1 As shown, the system architecture of this invention comprises three parts: raw fragments, encoded fragments, and static areas.

[0007] The raw shard is the basic execution unit of the system, responsible for processing transactions involving smart contract calls and storing the smart contract state. Each raw shard can process smart contract call transactions belonging to that shard.

[0008] The coded shard is responsible for verifying the execution results of the original shard. The coded shard stores the verified smart contract state set and encodes the verified smart contract state set using information encoding with local repair characteristics. This encoding method has two important characteristics: (1) Each coded shard only needs to store part of the verification information, reducing storage overhead. (2) When any shard experiences a smart contract state failure, it can be decoded using the encoded data stored in other shards, thereby restoring the smart contract state of the shard.

[0009] The static area refers to the area where a master node is elected from each original shard, and all master nodes from the original shards together form the static area. The static area is responsible for storing the smart contract state that may be read or modified during cross-shard smart contract calls (cross-shard smart contract calls: a smart contract in one shard calling a smart contract in another shard). The design of the static area solves the state synchronization problem during cross-shard smart contract execution. By broadcasting the smart contract state needed in cross-shard smart contract calls to the original shards executing the cross-shard smart contracts, the communication overhead for synchronizing smart contract states between shards can be significantly reduced, thereby increasing the throughput of the smart contract sharding system.

[0010] Fine-grained state locking mechanism: Existing solutions typically require locking the entire smart contract during cross-shard smart contract execution, while this invention refines the locking granularity to the level of individual state variables. When multiple shards call the same smart contract, they can execute concurrently as long as the smart contract variable states they access do not conflict, which further improves the throughput of the smart contract sharding method.

[0011] like Figure 2 As shown, the cross-shard smart contract execution method of the present invention adopts a four-phase design: pre-preparation phase, preparation phase, inspection phase, and submission phase, including the following steps: Step S1, Pre-preparation Phase. The smart contract call transaction is submitted by the user to the master node of its original shard. The master node performs static analysis of the smart contract, resolving dependency variables to determine the smart contract state variables that need to be locked. The static area attempts to lock these smart contract state variables. If the lock is successfully acquired, the preparation phase begins; if the lock is not successfully acquired, all locks are released, and the system re-attempts to acquire locks to avoid deadlock.

[0012] Step S2, Preparation Phase. The static area broadcasts the locked smart contract state variables to the original shard executing the smart contract. The original shard executes the smart contract and performs intra-shard consensus. The original shard sends the execution result of the smart contract call, i.e., the smart contract state set to be verified, to the encoded shard associated with the original shard for verification.

[0013] Step S3, Inspection Phase. Multiple encoded shards associated with the original shard verify the smart contract state set to be verified in parallel. Based on the verification results, it is determined whether there are corrupted shards. If corrupted shards exist, a decoding algorithm with information encoding featuring local repair capabilities is run to restore the smart contract state of the corrupted shards. If no corrupted shards exist, a verified smart contract state set is generated, and the process proceeds to the submission phase.

[0014] Step S4, Submission Phase. All shards involved in this smart contract call undergo consistent smart contract state updates via atomic broadcast protocol. The encoded shard stores the verified smart contract state set. When the encoding conditions for information encoding with local repair characteristics adopted by the system are met, the stored verified smart contract state set is encoded to reduce storage overhead. Attached Figure Description

[0015] Figure 1 This is a schematic diagram of the overall architecture of a smart contract sharding method provided by the present invention.

[0016] Figure 2 This is a phased flowchart of a smart contract sharding method provided by the present invention.

[0017] Figure 3 This is a graph showing how the performance of the patented method changes with the number of slices.

[0018] Figure 4 This is a comparison chart of the throughput of the method in this patent and existing methods.

[0019] Figure 5 This is a comparison chart of transaction confirmation delays between the patented method and existing methods.

[0020] Figure 6 This is a graph showing the impact of the number of smart contract state variables on performance. Detailed Implementation

[0021] The embodiments of the present invention will be described in detail below. These embodiments are for illustrative purposes only and are not intended to limit the scope of protection of the present invention.

[0022] In a typical deployment, the system has a total of 60 shards, with 30 original shards and 30 encoded shards. Each shard consists of 40 nodes. Nodes are assigned to shards using a verifiable random function, and a master node is elected within each shard. The encoded shards use repairable fountain codes as an information encoding scheme with local repair properties. Its generator matrix is ​​configured as a 30×60 sparse matrix, and non-zero elements are determined by random numbers generated using the BLS signature algorithm. Each encoded shard stores an average of approximately ⌈log230⌉≈5 original shards' worth of verification data.

[0023] When deploying smart contracts, a static analysis process is required: after the contract bytecode is parsed by the analyzer, a complete call relationship graph is constructed. For smart contract state variables that may be accessed by cross-shard smart contracts, the system generates metadata descriptions containing variable types and dependencies, and synchronizes them to all master nodes in the static area. The static area consists of master nodes elected by each shard and is specifically used to store the state of smart contracts that may be accessed by cross-shards.

[0024] The cross-shard transaction processing flow specifically includes the following four stages: S1. In the pre-preparation phase, the smart contract call transaction is routed to the target original shard based on the result of the contract address hash value modulo 30. After parsing the transaction content, the original shard node determines the set of dependent state variables through static analysis and initiates a fine-grained locking request to the static area. The locking mechanism adopts an improved two-phase locking protocol (2PL), with locking granularity accurate to the level of individual state variables. If the lock is successful, the preparation phase begins; if not all locks are acquired within 100 milliseconds, the acquired locks are released and the process is retried to avoid deadlock.

[0025] S2, Preparation Phase: Static zone nodes broadcast the locked smart contract state variables to the original shards executing the transactions. The original shards execute the smart contract call transactions and complete intra-shard consensus, generating a set of smart contract states to be verified. This set of states is then sent to the associated encoded shards, with each original shard associated with log(k) encoded shards (k being the total number of original shards).

[0026] S3. During the inspection phase, the associated coded shards verify the state set to be verified in parallel, employing a Byzantine fault-tolerant mechanism (≥3 consistent results are considered valid). If a sharded smart contract state corruption is detected (e.g., response timeout or verification failure), a repair mechanism is triggered: encoded data blocks with repairable fountain codes are obtained from the associated ⌈log230⌉+1≈6 coded shards, and the lost state is reconstructed using a decoding algorithm. If verification passes, a verified smart contract state set is generated.

[0027] S4. During the commit phase, all shards involved in this call perform a consistent update of the verified state set via the atomic broadcast protocol. The encoded shard stores the verified state set, and encodes the data when the verified state set accumulates to k values, reducing storage overhead. All locks are released after the state update is complete.

[0028] To verify the actual performance advantages of the smart contract sharding method described in this invention, a systematic experimental evaluation was conducted under typical encoding parameter configurations. Experimental results show that this invention exhibits significant advantages in throughput, latency, scalability, and effective handling of complex contracts. Specifically: Scalability: as follows Figure 3As shown, with a fixed number of nodes within a shard (40 nodes), the system throughput (TPS) increases nearly linearly as the total number of system nodes increases from 400 (10 shards) to 2000 (50 shards). When the system size doubles, the throughput increases by approximately 1.4 to 1.6 times, while the transaction confirmation latency remains relatively stable.

[0029] Performance advantages: such as Figure 4 , Figure 5 As shown, under the condition of ensuring the same system failure probability (approximately 7.6e-6), the peak throughput of this invention reaches approximately 6000 Txs / s, significantly outperforming existing solutions: approximately 1.7 times higher than the smart contract sharding solution Jenga, and approximately 2.7 to 3 times higher than the basic cross-shard call solution. Simultaneously, transaction confirmation latency is reduced by 52%-61% compared to Cross-Shard Call and by 22%-30% compared to Jenga. This advantage stems from eliminating multi-round cross-shard consensus overhead, reducing cross-shard communication, employing a fine-grained state locking mechanism to improve concurrency, and allowing for smaller shard sizes while maintaining the same level of security, thereby reducing intra-shard consensus costs.

[0030] Advantages of complex contract calls: such as Figure 6 As shown, for complex contracts containing a large number of state variables (the number of state variables increases from 1 to 2k, where k is the total number of shards), the throughput of this invention increases with the number of state variables, and tends to saturate when the number of variables approaches 1.3k. In contrast, the performance of the comparative scheme Jenga is largely unaffected by the increase in the number of state variables. This indicates that this invention can more effectively utilize sharding parallelism to process complex contract calls.

[0031] The above experiments verify the excellent performance of the present invention in achieving high throughput, low latency, scalability, and effective handling of complex contracts.

[0032] The implementation of this invention is not limited to the specific configuration described above. The number of fragments, the number of nodes, and the encoding parameters can all be adjusted according to actual needs. In particular, the repairable fountain code used in the above-described method can be replaced with other encoding methods, as long as an information encoding method with local characteristics is selected. These adjustments and modifications should all be considered within the scope of protection of this invention.

[0033] Although the illustrative specific embodiments of the present invention have been described above to enable those skilled in the art to understand the invention, it should be understood that the invention is not limited to the scope of the specific embodiments. For those skilled in the art, various changes are obvious as long as they are within the spirit and scope of the invention as defined and determined by the appended claims, and all inventions utilizing the concept of the present invention are protected.

Claims

1. A method for sharding smart contracts, characterized in that, Includes the following steps: S1. Sharding. An information encoding mechanism with local repair capabilities is used to divide the sharded network into original shards and encoded shards. S2. Smart Contract Invocation Transaction Processing. When a smart contract invocation transaction is received, the original shard responsible for storing the smart contract executes the smart contract invocation transaction and performs intra-shard consensus. After consensus is reached, the execution result is verified in parallel by multiple coded shards associated with the original shard. S3: Damaged shard recovery. When the smart contract state of any original shard is damaged, a recovery process is executed to restore the smart contract state of the damaged shard.

2. The system according to claim 1, characterized in that, In step S1, the characteristics of the partitioned segments specifically include: The original shard stores the smart contract code and state, and runs the consensus protocol to process smart contract call transactions within that shard. The encoded shard verifies the execution results of the original shard's smart contract and stores the verified smart contract state set. Depending on the selected information encoding rules, one original shard can be associated with multiple encoded shards, and one encoded shard can be associated with multiple original shards.

3. The smart contract sharding method according to claim 1, characterized in that, In step S2, when a cross-shard smart contract call is made, i.e., when a smart contract in one shard calls a smart contract in another shard, the smart contract state is managed through the static area, specifically including: S21. All original shards elect master nodes, and the master nodes of all original shards constitute the static area. S22. During smart contract deployment, the static area nodes perform static analysis on cross-shard smart contract calls, identify all required smart contract state variable sets, and load them into the static area. S23. During the cross-shard smart contract call, the static zone node acquires the lock on the relevant smart contract state variables and broadcasts the locked smart contract state variables to the original shard executing the smart contract. S24. The original shard executes the cross-shard smart contract call.

4. The smart contract sharding method according to claim 1, characterized in that, In step S23, when multiple shards concurrently call the smart contract in the same shard, a fine-grained state lock is used, specifically including: During a smart contract call, only the smart contract state variables that need to be accessed are locked; when multiple shards concurrently access the smart contract state, if they are not accessing the same smart contract state variable, they are allowed to access the smart contract state simultaneously.

5. The smart contract sharding method according to claim 1, characterized in that, The fragment recovery process in step S3 includes: S31. Extract the verified smart contract state set from multiple coded fragments associated with the corrupted fragment. S32. Perform joint decoding based on the adopted information encoding algorithm to restore the state. S33. After the recovery process is completed, the corrupted fragment can continue processing smart contract call transactions.

Images