Method, device and product for fragmented asynchronous execution of blockchain smart contract
By dividing the blockchain system into trusted master shards and using a consistent hashing algorithm, the separation of smart contract consensus and data on-chain is achieved, solving the inefficiency problem caused by serial execution and improving the throughput and execution efficiency of the blockchain system.
Patent Information
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- Filing Date
- 2025-12-30
- Publication Date
- 2026-04-10
AI Technical Summary
The serial synchronous execution of smart contracts in blockchain systems leads to task queuing and execution blockage, which severely restricts throughput and execution efficiency.
By acquiring historical consensus records of blockchain nodes, determining feature vectors based on correlation, dividing the data into multiple trusted main shards, and using a consistent hashing algorithm to allocate target trusted main shards and backup shards, smart contract consensus is quickly completed within the main shards, and consensus results are asynchronously sent to backup shards to complete data on-chain.
It significantly reduces consensus latency, improves system processing capacity and throughput, supports concurrent execution of multiple smart contracts, and significantly improves the overall throughput and resource utilization of the system.
Smart Images

Figure CN121833844A_ABST
Abstract
Description
TECHNICAL FIELD
[0001] The present disclosure relates to the field of blockchain technology, and particularly to a sharded asynchronous execution method, device and product of a blockchain smart contract. BACKGROUND
[0002] As a decentralized and tamper-proof database technology, blockchain is widely used in many fields. As a core component of blockchain, a smart contract is a computer protocol stored on a blockchain, which can automatically execute the preset operations in the contract without human intervention, thereby realizing business logic processing in a decentralized environment.
[0003] In related technologies, a smart contract usually adopts a combination of serial and synchronous execution. Although this execution method can strictly ensure the consistency of the states among nodes, the serial execution mechanism can easily cause task queuing and execution blocking when processing large-scale on-chain data, which seriously restricts the throughput and execution efficiency of the blockchain system. SUMMARY
[0004] Therefore, the present disclosure exemplary embodiments provide a sharded asynchronous execution method, device and product of a blockchain smart contract to solve the problems in related technologies.
[0005] In one aspect of the present disclosure exemplary embodiments, a sharded asynchronous execution method of a blockchain smart contract is provided, which comprises: obtaining historical consensus records of blockchain nodes, and determining a feature vector based on the correlation between each consensus record in the historical consensus records; clustering and dividing the blockchain nodes based on the feature vector to generate a plurality of trusted primary shards; wherein the consensus behavior similarity of the nodes in the trusted primary shard is the highest, and the consensus behavior difference of the nodes between different trusted primary shards is the largest; calculating the attribution degree of each node with respect to each trusted primary shard respectively, and determining the trusted backup shards corresponding to each trusted primary shard based on the attribution degree; allocating target trusted primary shards and target trusted backup shards for the to-be-processed on-chain data shards using a hash algorithm; executing smart contract consensus in the target trusted primary shard, and after the consensus is reached, asynchronously sending the consensus result to the target trusted backup shard to complete data on-chain.
[0006] In another aspect of the present disclosure exemplary embodiments, a computer device is provided, which comprises a memory, a processor and a computer program stored in the memory, wherein the processor executes the computer program to implement the method of the present disclosure exemplary embodiments.
[0007] In yet another aspect of the example embodiments of the present disclosure, a computer readable storage medium is provided, having stored thereon a computer program / instructions which, when executed by a processor, implement the method according to the example embodiments of the present disclosure.
[0008] In yet another aspect of the example embodiments of the present disclosure, a computer program product is provided, comprising computer program / instructions which, when executed by a processor, implement the method according to the example embodiments of the present disclosure.
[0009] As will be described in detail below, according to a method for sharded asynchronous execution of a smart contract of a blockchain according to an embodiment of the present disclosure, a feature vector is determined based on the correlation between each consensus record in the historical consensus records of the blockchain nodes; the blockchain nodes are clustered and divided based on the feature vector to generate a plurality of trusted primary shards; wherein the consensus behavior similarity of the nodes in the trusted primary shard is the highest, and the consensus behavior difference of the nodes between different trusted primary shards is the largest; the attribution of each node to each trusted primary shard is calculated respectively, and the trusted backup shards corresponding to each trusted primary shard are determined based on the attribution; a hash algorithm is used to assign a target trusted primary shard and a target trusted backup shard to the to-be-processed on-chain data shard; the consensus of the smart contract is executed in the target trusted primary shard, and after the consensus is reached, the consensus result is sent to the target trusted backup shard to complete the data on-chain. Therefore, the method for sharded asynchronous execution of a smart contract of a blockchain provided by the present disclosure divides the blockchain nodes into a plurality of trusted primary shards with highly consistent internal consensus behavior according to the historical consensus records of the nodes, so that the consensus process is quickly completed within the trusted primary shard, greatly reducing the consensus delay. At the same time, the consistent hash algorithm is used to realize the balanced distribution and parallel scheduling of on-chain data, so that different smart contracts can be executed in parallel on multiple shards, greatly improving the processing capacity of the system. In addition, the consensus process of the smart contract and the data on-chain process are separated, effectively avoiding the overall delay caused by on-chain blocking in the serial process, so that the system can support concurrent execution of multiple smart contracts, significantly improving the overall throughput and resource utilization of the system. BRIEF DESCRIPTION OF DRAWINGS
[0010] The above and other objects, features and advantages of the present disclosure will become more apparent from the following detailed description when taken in conjunction with the accompanying drawings in which like reference characters refer to like elements throughout. The accompanying drawings provide illustration of the example embodiments of the present disclosure and constitute a part of the specification, together with the description, to explain the example embodiments of the present disclosure and do not limit the present disclosure. In the drawings, like reference numerals refer to like elements throughout.
[0011] Figure 1 A schematic diagram of a serial synchronous execution process of a smart contract provided by an embodiment of the present disclosure is shown in FIG. 1. Figure 2An asynchronous execution flow diagram of a sharded blockchain smart contract provided by an embodiment of the present disclosure is shown in FIG. 1. Figure 3 A flow diagram of a sharded asynchronous execution method of a blockchain smart contract provided by an embodiment of the present disclosure is shown in FIG. 2. Figure 4 A hash ring diagram provided by an embodiment of the present disclosure is shown in FIG. 3. Figure 5 A functional module schematic diagram of a sharded asynchronous execution device of a blockchain smart contract provided by an embodiment of the present disclosure is shown in FIG. 4. Figure 6 A structural block diagram of an electronic device provided by an embodiment of the present disclosure is shown in FIG. 5. Figure 7 A schematic diagram of a computer program product provided by an embodiment of the present disclosure is shown in FIG. 6. DETAILED DESCRIPTION
[0012] Embodiments of the present disclosure will be described in more detail by referring to the drawings. Although certain embodiments of the present disclosure are shown in the drawings, it is understood that the present disclosure can be implemented in various forms, and should not be construed as being limited to the embodiments set forth herein, but rather, these embodiments are provided so as to more completely and thoroughly understand the present disclosure. It is understood that the drawings and embodiments of the present disclosure are for exemplary purposes only, and are not intended to limit the scope of protection of the present disclosure.
[0013] It is understood that each step recited in the method embodiments of the present disclosure can be executed in different orders, and / or in parallel. In addition, the method embodiments can include additional steps and / or omit the execution of the steps shown. The scope of the present disclosure is not limited in this respect.
[0014] The term "comprising" and variations thereof as used herein are open-ended, that is, "including but not limited to". The term "based on" is "based, at least in part, on". The term "one embodiment" means "at least one embodiment"; the term "another embodiment" means "at least one additional embodiment"; the term "some embodiments" means "at least some embodiments". Related definitions are given throughout the description. It is noted that the concepts of "first", "second", etc. mentioned in the present disclosure are only used to distinguish different devices, modules or units, and are not intended to limit the order or interdependence of the functions performed by these devices, modules or units.
[0015] It is noted that the modification of "one", "multiple" mentioned in the present disclosure is illustrative and not limiting, and those skilled in the art should understand that, unless otherwise explicitly indicated in the context, it should be understood as "one or more".
[0016] Names of messages or information exchanged between multiple devices in the embodiments of the present disclosure are only for illustrative purposes, and are not intended to limit the scope of the messages or information.
[0017] It can be understood that, before using the technical solutions disclosed in the embodiments of the present disclosure, the type, use range, use scenario, etc. of personal information involved in the present disclosure should be informed to the user and the authorization of the user should be obtained in accordance with relevant laws and regulations.
[0018] As a decentralized and tamper-proof database technology, blockchain is widely used in many fields. As a core component of blockchain, smart contract is a computer protocol stored on the blockchain, which can automatically execute the preset operations in the contract without human intervention, thereby realizing business logic processing in a decentralized environment.
[0019] In the related art, the smart contract usually adopts a combination of serial and synchronous execution mode. Although this execution mode can strictly ensure the consistency of the state between nodes, the serial execution mechanism can easily cause task queuing and execution blocking when processing large-scale on-chain data, which seriously restricts the throughput and execution efficiency of the blockchain system.
[0020] For example, Figure 1 The serial and synchronous execution flowchart of the smart contract provided by the embodiments of the present disclosure is shown in Figure 1 As shown in the figure, in the process of serial execution of the smart contract, the smart contract scheduler sends the smart contract command to each blockchain node in turn. After each blockchain node receives the command, it verifies the correctness of the smart contract. When more than half of all nodes verify, the smart contract is executed by the blockchain node. After all blockchain nodes are successfully executed, the execution result is returned to the smart contract scheduler. The smart contract scheduler does not start to serially execute the smart contract 2 until it receives the command that all smart contract 1 execution is completed. Figure 1 The upper part of the figure shows that a plurality of blockchain nodes are distributed side by side, and the smart contract scheduler below arranges the task queue of the smart contract 1 and the smart contract 2 in turn.
[0021] Therefore, in order to solve the above problems, the example embodiment of the present disclosure provides a sharded asynchronous execution method of a blockchain smart contract. First, based on the historical consensus data of the nodes in the blockchain system, a feature vector is selected through correlation analysis, and the nodes are divided into a plurality of trusted master shards according to the similarity of the node consensus behaviors. Second, the attribution degree of each node to each trusted master shard is calculated, and the second smallest node set is selected as a trusted backup shard for asynchronous processing of data on-chain tasks. Then, the consistent hashing algorithm is used to map the trusted master shard ID and the data ID to the hash ring, and the corresponding trusted master shard of the smart contract is quickly located through the hash ring to support parallel execution of the smart contract in multiple shards. Finally, the consensus lock mechanism is used to execute the smart contract in the trusted master shard. If the ledger is involved in execution, the contract is suspended and waits, otherwise the consensus process is executed in parallel, and the consensus result is sent to the trusted backup shard asynchronously to complete the data on-chain, thereby realizing the separation of consensus and on-chain and the asynchronous execution of the smart contract, and improving the throughput and execution efficiency of the blockchain system.
[0022] Exemplarily, Figure 2 The sharded asynchronous execution flowchart of the blockchain smart contract provided by the example embodiment of the present disclosure is shown in Figure 2 As shown, the overall architecture of the sharded asynchronous execution method of the blockchain smart contract is provided with a smart contract scheduler for initiating a smart contract scheduling request, and a task queue of smart contract 1, smart contract 2, etc. in sequence. The architecture is provided with a shard proxy server at the middle layer, which is responsible for receiving client requests and forwarding the smart contract request to the corresponding trusted master shard according to the data ID and the trusted shard ID. The bottom layer of the architecture is composed of multiple parallel trusted master shards and corresponding trusted backup shards, and each master shard internally contains multiple nodes such as node 1, node 2 and node 3. The trusted master shard is divided according to the historical consensus of the nodes in the blockchain system, and the system is divided into z trusted master shards to ensure that the nodes in the shard have the most similar consensus behaviors and the consensus behaviors between the shards are maximized, and the consensus process of the smart contract is completed in these master shards. Each trusted master shard is provided with a corresponding trusted backup shard, which is also provided with a plurality of nodes. The function of the trusted backup shard is to separate the on-chain process from the consensus process, to complete the data on-chain asynchronously by reading the consensus result in the consensus queue, thereby improving the execution efficiency of the entire smart contract system.
[0023] Exemplarily, Figure 3 The flowchart of the sharded asynchronous execution method of the blockchain smart contract provided by the example embodiment of the present disclosure is shown in Figure 3 As shown, the flowchart can include the following steps: Step S310: Obtain the historical consensus records of the blockchain nodes, and determine the feature vector based on the correlation between each consensus record in the historical consensus records.
[0024] In an embodiment, first, the behavior records of each node in historical multiple consensus are extracted from the blockchain system to construct a consensus behavior matrix, wherein the rows of the matrix represent nodes, the columns represent each consensus event, and the matrix elements 1 represent consensus correctness and 0 represent consensus error.
[0025] Further, the correlation between any two consensus record columns is analyzed, if the two columns are highly correlated, only one column is retained as a feature vector to avoid feature redundancy and overfitting problem. Finally, the low-correlation consensus columns are screened to constitute the feature vector of the node.
[0026] Step S320: Based on the feature vector, the blockchain nodes are clustered and divided to generate multiple trusted master shards. Among them, the consensus behavior similarity of the nodes in the trusted master shard is the highest, and the consensus behavior difference of the nodes between different trusted master shards is the largest.
[0027] In an embodiment, the clustering algorithm can be used to group the feature vectors of the nodes, and the clustering process aims to achieve the most similar consensus behavior of the nodes within the shard and the largest difference of the consensus behavior of the nodes between the shards.
[0028] Specifically, the initial center point of the first trusted master shard can be assumed first. Then, according to the determined initial center point, the node farthest from the initial center point is selected as the initial center point of the subsequent shard, thereby ensuring the dispersion of each trusted master shard in the feature space.
[0029] Step S330: The belonging degree of each node to each trusted master shard is calculated respectively, and the corresponding trusted backup shards of each trusted master shard are determined based on the belonging degree.
[0030] In an embodiment, the Euclidean distance of each node to the center point of each trusted master shard can be calculated, and the distance is normalized to obtain the belonging degree of the node to each trusted master shard. For each trusted master shard, a node set is selected as the corresponding trusted backup shard according to the belonging degree.
[0031] Step S340: A hash algorithm is used to assign a target trusted master shard and a target trusted backup shard for the to-be-processed on-chain data shard.
[0032] In an embodiment, a consistent hash algorithm can be used to manage the on-chain data shards to obtain the on-chain data shards. According to the identifier of the trusted master shard and the identifier of the on-chain data shard, the target trusted master shard is assigned for the on-chain data shard, and the target trusted backup shard is determined according to the target trusted master shard.
[0033] Step S350: The smart contract consensus is executed in the target trusted master shard, and after the consensus is reached, the consensus result is sent to the target trusted backup shard asynchronously to complete the data on-chain.
[0034] In the embodiment, one node in the target trusted master shard is randomly selected to receive the smart contract request, consensus is completed within the target trusted master shard, and the consensus result is then sent to the corresponding target trusted backup shard for data on-chain.
[0035] Therefore, according to the historical consensus records of the nodes, the blockchain nodes are divided into multiple trusted master shards with high consistency in internal consensus behavior, so that the consensus process is quickly completed within the trusted master shard, greatly reducing the consensus delay. At the same time, the consistent hashing algorithm is used to realize the balanced distribution and parallel scheduling of on-chain data, so that different smart contracts can be executed in parallel on multiple shards, greatly improving the processing capacity of the system. In addition, the consensus process of the smart contract and the data on-chain process are separated, which effectively avoids the overall delay caused by on-chain blocking in the serial process, so that the system can support concurrent execution of multiple smart contracts, significantly improving the overall throughput and resource utilization of the system.
[0036] Based on the above embodiment, in another embodiment provided by the present disclosure, the step S310 can include: obtaining correct consensus records and error consensus records of each node in the historical consensus records, and constructing a consensus behavior matrix; calculating the correlation coefficient between any two columns of consensus records in the consensus behavior matrix in sequence, and determining the consensus records with a correlation coefficient lower than a preset threshold as feature vectors.
[0037] In the embodiment, it is assumed that there are n nodes in the blockchain system, and the historical consensus m times, and the consensus of each node can be represented as Table 1, where “1” represents correct consensus, i.e., the consensus is consistent with the final consensus result; and “0” represents incorrect consensus, i.e., the consensus is inconsistent with the final consensus result.
[0038] Exemplarily, a consensus behavior matrix of n × m can be constructed according to the correct consensus records and the error consensus records.
[0039] Table 1 Consensus of each node in the blockchain system
[0040] In order to effectively extract the representative features of the consensus behavior of the nodes and prevent overfitting phenomenon in the modeling process, the situation between each consensus needs to be screened.
[0041] Exemplarily, the correlation coefficient between any two consensus results can be calculated, and the formula is as follows:
[0042] wherein, , respectively represent two consensus results (columns in Table 1); represent the variance of represent the variance of represent , the covariance between two columns.
[0043] Through the above formula, the correlation coefficient between all consensus result columns is calculated, The larger the correlation coefficient is, the stronger the correlation between the consensus results is. When screening, the consensus columns with a correlation coefficient greater than 0.9 are retained as features, and if the correlation coefficients between multiple columns are all higher than 0.9, only one column is selected, so as to ensure that the selected feature columns have a lower correlation.
[0044] Finally, the consensus columns with a lower correlation are selected to form a feature vector of node consensus behavior, which is used for subsequent shard division and node attribution analysis.
[0045] Based on this, by performing correlation analysis on historical consensus results, highly correlated consensus records are screened out, and a representative low-correlation feature vector is constructed, which can effectively avoid the overfitting problem of the shard model caused by consensus sample redundancy. In addition, the node consensus features extracted by the scheme can more truly reflect the differences in the consensus behavior of nodes, providing a reliable data basis for subsequent node shard based on consensus similarity, thereby improving the consensus efficiency within the shard and the parallel execution capability between shards.
[0046] Based on the above embodiment, in another embodiment provided by the present disclosure, the step S320 can include: taking the mean value of all feature vectors as the initial center point of the first trusted master shard, and taking the determined initial center point to form a center point set; selecting the node farthest from the center point set as the initial center point of the subsequent trusted master shard; calculating the distance from each node to each initial center point, and dividing the node to the trusted master shard to which the closest initial center point belongs.
[0047] In the embodiment, after the selection of the historical consensus feature vector is completed, any two consensus (columns) are not correlated, and it is assumed that the selected feature vectors have m , the consensus of the i th node can be represented by the feature vector , where represents the i th consensus result of the m th node, and 1 represents correct and 0 represents error.
[0048] To improve the efficiency of concurrent execution of smart contracts, all nodes are divided into z main shards, wherein The value is: The sharding process follows the principle that the consensus behavior of nodes within a shard is most similar, and the consensus behavior of nodes between shards is most different. The specific steps can include: First, set the initial center point set of the node center point in each trusted main shard as Take the center vector of all nodes as the initial center point R 1 of the first trusted main shard n , wherein R N is the number of nodes, and the initial center point 1 can be represented as:
[0049] Further, determine the center point of the second trusted main shard. From all n N nodes, select the node farthest from the initial node R 1 as R 2, thereby ensuring that the trusted shards are more dispersed and the difference between shards is maximized.
[0050] For example, the calculation formula of the distance is:
[0051] By analogy, the center points of the remaining trusted main shards are determined in turn. Among them, the initial center point z z of the zth trusted main shard is R z Select the node farthest from the determined center points R 1, R 2, …, R z-1 , thereby ensuring that the distribution of each shard in the feature space is as dispersed as possible.
[0052] Finally, calculate the distance from each node feature vector x i to each center point :
[0053] According to the minimum distance principle, the node is divided into the trusted main shard to which the center point belonging to the nearest distance, and finally forms z trusted main shards with similar internal consensus behavior and significant differences between each other.
[0054] Based on this, through the clustering and slicing mechanism based on the consensus feature vector, reasonable grouping of blockchain nodes is realized, ensuring that the consensus behaviors of nodes in the same slice are highly consistent, significantly reducing the time and communication overhead of consensus reaching in the slice. At the same time, by maximizing the behavior difference between slices, the independence between different slices is enhanced, providing a structural basis for parallel execution of smart contracts in multiple slices, thereby effectively improving the overall concurrent processing capacity and throughput of the system, solving the problem of low efficiency of traditional full-node consensus and inability to support high-concurrency smart contract execution.
[0055] Based on the above embodiments, in another embodiment provided by the present disclosure, the step S330 can include: Based on the distance of the node to the initial center point of each trusted main slice, the belonging degree of the node to each trusted main slice is determined respectively; wherein the belonging degree is inversely proportional to the square of the distance; The node set with the second highest belonging degree is selected to form the trusted backup slice corresponding to the trusted main slice.
[0056] In the embodiment, in order to enhance the parallelism and asynchrony during the execution of the smart contract, the trusted main slice is responsible for receiving the on-chain request and completing the group consensus, and sending the consensus result to the corresponding trusted backup slice, and the backup slice completes the data on-chain operation. In the blockchain system, each node does not belong to only one fixed trusted main slice, but according to the correlation between the node and the center point of each trusted main slice, the belonging degree of any node to any trusted main slice is calculated. Assuming that u ij represents the belonging degree of the i-th node to the j-th trusted main slice, and the calculation formula of the belonging degree can be represented as: i j
[0057] wherein, d ij represents the distance of the node i to the center point of the trusted main slice j. i j After calculating the belonging degree of each node to each trusted main slice
[0058] , the node set with the second smallest distance is selected as the trusted backup slice of the trusted main slice.
[0059] The account data completely consistent with the corresponding trusted main slice is stored in the trusted backup slice, thereby supporting the separation and asynchronous execution of the consensus and on-chain process.
[0060] Based on this, by calculating the attribution of each node and each trusted primary shard, each trusted primary shard has a corresponding trusted backup shard, effectively decoupling the consensus process and the on-chain process, so that the consensus process is completed in the trusted primary shard, and the on-chain operation is executed asynchronously by the backup shard, thereby greatly shortening the overall execution delay of the smart contract, and solving the efficiency bottleneck caused by the serial execution of consensus and on-chain in the traditional smart contract execution.
[0061] Based on the above embodiment, in another embodiment provided by the present disclosure, the step S340 can include: performing a consistent hash operation on the identifier of each trusted primary shard and the identifier of each on-chain data shard, and mapping the identifier of each trusted primary shard and the identifier of each on-chain data shard to a hash ring based on the operation result; based on the position information of the on-chain data shard on the hash ring, allocating a target trusted primary shard; based on the target trusted primary shard, determining a corresponding target trusted backup shard.
[0062] In the embodiment, in order to make the smart contract distributed relatively evenly among the shards and improve the parallel execution capability of the blockchain smart contract, a consistent hash algorithm can be used to perform shard processing on the on-chain data according to the division result of the trusted primary shard and the trusted backup shard. The specific implementation is as follows: First, assume that the unique identifier of the trusted primary shard is PartitionID, and the unique identifier of the on-chain data is dataID. Perform a consistent hash operation on each PartitionID and dataID, and map them to a unique value in the interval.
[0063] Further, map the hash values corresponding to all PartitionID and dataID to a hash ring composed of values. For example, Figure 4 a hash ring diagram provided by the embodiment of the present disclosure.
[0064] Further, attribute each dataID to the PartitionID whose hash value is closest to it in the clockwise direction on the hash ring. As Figure 4 shown, dataID1 belongs to PartitionID1, and dataID2 and dataID3 belong to PartitionID2. Through this shard storage method, on the one hand, due to the global uniqueness of the hash value, the unique attribution of the data on the shard can be ensured, which facilitates quick positioning during query, and on the other hand, by distributing different data to different shards, the overall execution efficiency can be improved in the process of parallel execution of smart contracts.
[0065] Finally, when the shard proxy server receives a smart contract execution request, the trusted master shard to which the data belongs can be quickly determined according to the consistent hash value, and the smart contract instruction is sent to the corresponding trusted master shard. Since there are z trusted master shards in the system, the processing efficiency of the system can be theoretically improved z times through parallel processing of smart contracts.
[0066] Based on this, by introducing a consistent hash mechanism, the balanced distribution of on-chain data among the trusted master shards is realized, effectively solving the problem of uneven distribution that may occur in data sharding. In addition, with the rapid mapping characteristics of the hash ring, the shard to which the data belongs can be efficiently located, shortening the scheduling time of the smart contract. Secondly, by dispersing the smart contracts of different data to multiple shards for parallel processing, the overall concurrent processing capacity and throughput of the system are greatly improved, effectively solving the problem of limited execution efficiency caused by data concentration.
[0067] Based on the above embodiment, in another embodiment provided by the present disclosure, the above step S350 can include: determining whether the ledger involved in the smart contract is in an occupied state through a consensus lock; the consensus lock is stored in a memory key-value pair structure; in the case that the ledger is in an unoccupied state, performing a consensus process in the target trusted master shard; in the case that the ledger is in an occupied state, suspending the smart contract until the ledger is released.
[0068] In the embodiment, after the target trusted master shard receives the smart contract execution request, the consensus process is first completed within the shard. After the consensus is reached, the consensus result is sent to the message queue.
[0069] In the embodiment, a consensus lock mechanism based on a memory key-value pair (Key-Value) structure is also introduced. Before the execution of the smart contract, the consensus lock mechanism is used to check whether the ledger involved is being executed, thereby improving the orderliness and concurrent efficiency of the execution of the smart contract within the shard.
[0070] If the ledger has been locked by the consensus lock, the smart contract is placed in a suspended state until the related ledger execution ends. During the suspension period, any smart contract involving the same ledger cannot perform any operation until the smart contract execution is successful, the consensus lock is released, and other smart contracts involving the node are notified that they can be executed, thereby avoiding data conflicts and state inconsistency problems.
[0071] If the ledger has not been locked by the consensus lock, the nodes within the trusted master shard will synchronize the consensus process of the smart contract, and the subsequent on-chain operation will be executed asynchronously by the trusted backup shard, thereby improving the execution efficiency while ensuring consistency.
[0072] Based on this, by introducing the consensus lock, the competition for the same ledger and the state conflict in concurrent execution are effectively prevented, and the data consistency and execution order are guaranteed.
[0073] Based on the above embodiment, in another embodiment provided by the present disclosure, the step S350 can further include: writing the consensus result into a message queue; the target trusted backup shard reads the consensus result from the message queue and performs the data on-chain operation; after completing the on-chain operation, synchronizing the ledger to the target trusted master shard.
[0074] In the embodiment, after the target trusted master shard completes the consensus process, the consensus result is written into the message queue, the target trusted backup shard reads the consensus result from the message queue, and the data on-chain operation is completed inside the shard, and then the updated ledger state is synchronized to the corresponding target trusted master shard, ensuring that the ledger data of the target trusted master shard and the target trusted backup shard are consistent.
[0075] For example, the message queue can be implemented by using a message queue such as Kafka or ActiveMQ.
[0076] Based on this, the message queue mechanism is introduced to separate the time-consuming on-chain operation from the consensus process, significantly reducing the overall response delay of the smart contract, and solving the problems of throughput bottleneck and low execution efficiency caused by serial execution of consensus and on-chain.
[0077] In one or more technical solutions provided in the exemplary embodiments of the present disclosure, the blockchain nodes are divided into multiple trusted master shards with high consistency of internal consensus behavior according to the historical consensus records of the nodes, so that the consensus process is quickly completed inside the trusted master shard, and the consensus delay is greatly reduced. At the same time, the consistent hashing algorithm is used to realize the balanced distribution and parallel scheduling of on-chain data, so that different smart contracts can be executed in parallel on multiple shards, greatly improving the processing capacity of the system. In addition, the consensus process of the smart contract is separated from the data on-chain process, effectively avoiding the overall delay caused by on-chain blocking in the serial process, so that the system can support concurrent execution of multiple smart contracts, and the overall throughput and resource utilization of the system are significantly improved.
[0078] Therefore, the sharded asynchronous execution method of the blockchain smart contract provided in the exemplary embodiments of the present disclosure solves the technical problems of low execution efficiency, high response delay, and insufficient concurrent processing capacity of smart contracts caused by serial and synchronous execution in the blockchain system.
[0079] The foregoing primarily describes the solutions provided by exemplary embodiments of this disclosure. It is understood that, in order to achieve the above functions, the electronic device includes corresponding hardware structures and / or software modules for performing each function. Those skilled in the art should readily recognize that, based on the units and algorithm steps of the various examples described in conjunction with the embodiments disclosed herein, this disclosure can be implemented in hardware or a combination of hardware and computer software. Whether a function is executed in hardware or by computer software driving hardware depends on the specific application and design constraints of the technical solution. Those skilled in the art can use different methods to implement the described functions for each specific application, but such implementation should not be considered beyond the scope of this disclosure.
[0080] The exemplary embodiments of this disclosure can divide the electronic device into functional units according to the above method examples. For example, each function can be divided into a separate functional module, or two or more functions can be integrated into a single processing module. The integrated module can be implemented in hardware or as a software functional module. It should be noted that the module division in the exemplary embodiments of this disclosure is illustrative and only represents one logical functional division; other division methods may be used in actual implementation.
[0081] By dividing each functional module according to its corresponding function, an exemplary embodiment of this disclosure provides a sharded asynchronous execution device for blockchain smart contracts. This sharded asynchronous execution device for blockchain smart contracts can be a server or a chip applied to a server. Figure 5 This is a schematic block diagram illustrating the functional modules of a sharded asynchronous execution device for blockchain smart contracts provided in an embodiment of this disclosure. Figure 5 As shown, the sharded asynchronous execution device 500 for the blockchain smart contract includes: The data acquisition module 510 is used to acquire the historical consensus records of the blockchain node and determine the feature vector based on the correlation between the consensus records in the historical consensus records; The data processing module 520 is used to cluster and divide the blockchain nodes based on the feature vector to generate multiple trusted master shards; among them, the consensus behavior of nodes within the trusted master shards is the most similar, and the consensus behavior of nodes between different trusted master shards is the most different. The data processing module 520 is also used to calculate the degree of belonging of each node to each trusted primary shard, and to determine the trusted backup shard corresponding to each trusted primary shard based on the degree of belonging. The data processing module 520 is also used to allocate target trusted primary shards and target trusted backup shards to the on-chain data to be processed using a hash algorithm; The data processing module 520 is further configured to perform consensus of the smart contract in the target trusted main shard, and after the consensus is reached, send the consensus result to the target trusted backup shard asynchronously to complete data on-chain.
[0082] In another embodiment provided by the present disclosure, the data acquisition module 510 is further configured to acquire correct consensus records and error consensus records of each node in the historical consensus records, and construct a consensus behavior matrix; calculate correlation coefficients between any two columns of consensus records in the consensus behavior matrix in sequence, and determine the consensus records with correlation coefficients lower than a preset threshold as the feature vectors.
[0083] In another embodiment provided by the present disclosure, the data processing module 520 is further configured to take the mean value of all feature vectors as an initial center point of a first trusted main shard, and form a center point set with the determined initial center point; select nodes farthest from the center point set in sequence as initial center points of subsequent trusted main shards; calculate the distance from each node to each initial center point respectively, and divide the nodes to the trusted main shard to which the closest initial center point belongs.
[0084] In another embodiment provided by the present disclosure, the data processing module 520 is further configured to determine the belonging degree of each node to each trusted main shard based on the distance from the node to the initial center point of each trusted main shard; wherein the belonging degree is inversely proportional to the square of the distance; and select a node set with the second highest belonging degree to form a trusted backup shard corresponding to the trusted main shard.
[0085] In another embodiment provided by the present disclosure, the data processing module 520 is further configured to perform consistency hash operation on the identifiers of each trusted main shard and the identifiers of each on-chain data shard respectively, and map the identifiers of each trusted main shard and the identifiers of each on-chain data shard to a hash ring based on the operation results; based on the position information of the on-chain data shard on the hash ring, allocate a target trusted main shard; and based on the target trusted main shard, determine a corresponding target trusted backup shard.
[0086] In another embodiment provided by the present disclosure, the data processing module 520 is further configured to determine whether the ledger involved in the smart contract is in an occupied state by a consensus lock; the consensus lock is stored in a memory key-value pair structure; in the case that the ledger is in an unoccupied state, perform a consensus process in the target trusted main shard; and in the case that the ledger is in an occupied state, suspend the smart contract until the ledger is released.
[0087] In a further embodiment provided by the present disclosure, the data processing module 520 is further configured to write the consensus result to a message queue; the target trusted backup shard reads the consensus result from the message queue and performs a data chaining operation; and after the chaining operation is completed, the account book is synchronized to the target trusted master shard.
[0088] The exemplary embodiments of the present disclosure further provide an electronic device, including at least one processor, and a memory connected with the at least one processor in communication. The memory stores a computer program capable of being executed by the at least one processor, and the computer program, when executed by the at least one processor, is configured to cause the electronic device to perform the method according to the embodiments of the present disclosure.
[0089] The exemplary embodiments of the present disclosure further provide a non-transitory computer readable storage medium storing a computer program, wherein the computer program, when executed by a processor of a computer, is configured to cause the computer to perform the method according to the embodiments of the present disclosure.
[0090] Figure 6 The structural block diagram of the electronic device provided by the embodiments of the present disclosure will now be described, which is the structural block diagram of the electronic device 600 that can be a server or a client of the present disclosure, and is an example of a hardware device that can be applied to various aspects of the present disclosure. The electronic device is intended to represent a variety of forms of digital electronic computing devices, such as laptop computers, desktop computers, workstations, personal digital assistants, servers, blade servers, mainframes, and other suitable computers. The electronic device can also represent various forms of mobile devices, such as personal digital assistants, cellular phones, smart phones, wearable devices, and other similar computing devices. The components shown herein, their connections, and relationships, and their functions, are meant to be examples only, and are not intended to limit implementations of the present disclosure described and / or claimed in this document.
[0091] As shown in Figure 6 The electronic device 600 includes a computing unit 601 that can perform various appropriate actions and processes in accordance with a computer program stored in a read-only memory (ROM) 602 or a computer program loaded from a storage unit 608 into a random access memory (RAM) 603. Various programs and data required for the operation of the electronic device 600 can also be stored in the RAM 603. The computing unit 601, the ROM 602, and the RAM 603 are connected to each other through a bus 604. An input / output (I / O) interface 605 is also connected to the bus 604.
[0092] A plurality of components in the electronic device 600 are connected to the I / O interface 605, including: an input unit 606, an output unit 607, a storage unit 608, and a communication unit 609. The input unit 606 can be any type of device that can input information to the electronic device 600, and can receive inputted digital or character information, and generate key signal inputs related to user settings and / or function controls of the electronic device. The output unit 607 can be any type of device that can present information, and can include, but is not limited to, a display, a speaker, a video / audio output terminal, a vibrator, and / or a printer. The storage unit 608 can include, but is not limited to, a magnetic disk, an optical disk. The communication unit 609 allows the electronic device 600 to exchange information / data with other devices through a computer network such as the Internet and / or various telecommunication networks, and can include, but is not limited to, a modem, a network card, an infrared communication device, a wireless communication transceiver and / or chipset, such as a Bluetooth TM device, a WiFi device, a WiMax device, a cellular communication device, and / or the like.
[0093] The computing unit 601 can be various general and / or special-purpose processing components with processing and computing capabilities. Some examples of the computing unit 601 include, but are not limited to, a central processing unit (CPU), a graphics processing unit (GPU), various special-purpose artificial intelligence (AI) computing chips, various computing units running machine learning model algorithms, a digital signal processor (DSP), and any appropriate processor, controller, microcontroller, etc. The computing unit 601 performs various methods and processes described above. Each of the methods described above can be implemented as a computer software program, which is tangibly embodied in a machine-readable medium, such as the storage unit 608. In some embodiments, part or all of the computer program can be loaded and / or installed onto the electronic device 600 via the ROM 602 and / or the communication unit 609.
[0094] Figure 7 For a schematic diagram of the computer program product provided by the embodiments of the present disclosure, the example embodiments of the present disclosure also provide a computer program product 700, including a computer program 701, wherein the computer program 701 is used for causing a computer to execute the method according to the embodiments of the present disclosure when the computer program 701 is executed by a processor of the computer.
[0095] Program code for carrying out methods of the present disclosure can be written in any combination of one or more programming languages. The program code can be provided to a processor or controller of a general purpose computer, special purpose computer, or other programmable data processing apparatus to produce a machine, such that the program code, when executed by the processor or controller, produces the functions / operations specified in the flowcharts and / or block diagrams. The program code can be embodied entirely on a machine, partially on a machine, fully on a machine, partially on a machine and partially on a remote machine, or fully on a remote machine or server.
[0096] In the context of the present disclosure, a machine-readable medium can be a tangible medium that contains or stores a program for use by or in connection with an instruction execution system, apparatus, or device. The machine-readable medium can be a machine-readable signal medium or a machine-readable storage medium. A machine-readable medium can include, but is not limited to, an electronic, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, or device, or any suitable combination of the foregoing. More specific examples of the machine-readable storage medium would include a lined-inked electrical connection, a portable computer disk, a hard disk, a random access memory (RAM), a read-only memory (ROM), an erasable programmable read-only memory (EPROM or Flash memory), an optical fiber, a portable compact disc read-only memory (CD-ROM), an optical storage device, a magnetic storage device, or any suitable combination of the foregoing.
[0097] As used in the present disclosure, the terms "machine-readable medium" and "computer-readable medium" refer to any computer program product, apparatus and / or device (e.g., magnetic discs, optical disks, memory, Programmable Logic Devices (PLDs)) used to provide machine instructions and / or data to a programmable processor, including a machine-readable medium that receives machine instructions as a machine-readable signal. The term "machine-readable signal" refers to any signal that can be used to provide machine instructions and / or data to a programmable processor.
[0098] To provide for interaction with a user, the systems and techniques described here can be implemented on a computer having a display device (e.g., a CRT (cathode ray tube) or LCD (liquid crystal display) monitor) for displaying information to the user and a keyboard and a pointing device (e.g., a mouse or a trackball) by which the user can provide input to the computer. Other kinds of devices can be used to provide for interaction with a user as well; for example, feedback provided to the user can be any form of sensory feedback (e.g., visual feedback, auditory feedback, or tactile feedback); and input from the user can be received in any form, including acoustic, speech, or tactile input.
[0099] The systems and techniques described here can be implemented in a computing system that includes a back end component, e.g., as a data server, or that includes a middleware component, e.g., an application server, or that includes a front end component, e.g., a user computer having a graphical user interface or a Web browser through which a user can interact with an implementation of the systems and techniques described here, or any combination of such back end, middleware, or front end components. The components of the system can be interconnected by any form or medium of digital data communication, e.g., a communication network. Examples of communication networks include a local area network (LAN), a wide area network (WAN), and the Internet.
[0100] The computer system can include clients and servers. A client and server are generally remote from each other and typically interact through a communication network. The relationship of client and server arises by virtue of computer programs running on the respective computers and having a client-server relationship to each other.
[0101] In the embodiments described above, all or some of the steps can be implemented by software, hardware or firmware, or any combination thereof. When implemented by software, all or some of the steps can be implemented by one or more computer program or instructions. When loaded on a computer, the computer program or instructions can execute on the computer and perform all or some of the steps described in the embodiments of the present disclosure. The computer can be a general purpose computer, a special purpose computer, a computer network, a terminal, a user device, or other programmable apparatus. The computer program or instructions can be stored in a computer readable storage medium or transmitted from one computer readable storage medium to another, e.g., from a website, a computer, a server or a data center to another website, computer, server or data center through a wired or wireless way. The computer readable storage medium can be any available medium or a combination of one or more of the available media that is accessible by a computer. The available medium can be a magnetic medium, e.g., a floppy diskette, a hard disk, a magnetic tape; an optical medium, e.g., a compact disk (CD), a digital video disk (DVD); a semiconductor medium, e.g., a solid state disk (SSD).
[0102] Although the present disclosure has been described in connection with certain specific features and embodiments thereof, it is to be understood that it is provided as an exemplification of the principles of the present disclosure and the features set forth herein are intended to be illustrative rather than limiting, and that numerous modifications and variations therein can be expected by those skilled in the art. Accordingly, it should be understood that the description and drawings are illustrative of the present disclosure and are not intended to be limiting. It should be understood that various changes can be made to the implementations described and the embodiments presented herein without departing from the spirit and scope of the present disclosure. It is intended that all such changes be considered as within the scope of the present disclosure.
Claims
1. A method for sharded asynchronous execution of blockchain smart contracts, characterized in that, The method includes: Obtain the historical consensus records of the blockchain nodes, and determine the feature vector based on the correlation between the consensus records in the historical consensus records; Based on the feature vectors, the blockchain nodes are clustered and divided to generate multiple trusted master shards; among them, the consensus behavior of nodes within the trusted master shards is the most similar, and the consensus behavior of nodes between different trusted master shards is the most different. Calculate the degree of belonging of each node to each trusted primary shard, and determine the trusted backup shard corresponding to each trusted primary shard based on the degree of belonging; A hash algorithm is used to allocate target trusted primary shards and target trusted backup shards to the on-chain data to be processed. Execute smart contract consensus within the target trusted main shard. Once consensus is reached, the consensus result is asynchronously sent to the target trusted backup shard to complete the data on-chain process.
2. The method according to claim 1, characterized in that, The determination of feature vectors based on the correlation between consensus records in the historical consensus records includes: Obtain the correct and incorrect consensus records of each node from the historical consensus record, and construct a consensus behavior matrix; The correlation coefficient between any two columns of consensus records in the consensus behavior matrix is calculated sequentially, and the consensus records with correlation coefficients lower than a preset threshold are identified as the feature vectors.
3. The method according to claim 1, characterized in that, The process of clustering and dividing blockchain nodes based on the feature vectors to generate multiple trusted master shards includes: The mean of all feature vectors is used as the initial center point of the first reliable principal partition, and the determined initial center points are combined into a center point set; The node that is furthest from the set of center points is selected sequentially as the initial center point of the subsequent trusted master shard; Calculate the distance from each node to each initial center point, and assign each node to the trusted master shard belonging to the nearest initial center point.
4. The method according to claim 3, characterized in that, The step of calculating the affiliation degree of each node relative to each trusted primary shard, and determining the trusted backup shard corresponding to each trusted primary shard based on the affiliation degree, includes: The degree of a node's affiliation to each trusted master shard is determined based on the distance from the node to the initial center point of each trusted master shard; wherein the degree of affiliation is inversely proportional to the square of the distance. The set of nodes ranked second in terms of belonging degree is selected to form the trusted backup shard corresponding to the trusted primary shard.
5. The method according to claim 1, characterized in that, The process of using a hash algorithm to allocate target trusted primary shards and target trusted backup shards to the on-chain data to be processed includes: Perform consistent hashing operations on the identifiers of each trusted master shard and each on-chain data shard, and map the identifiers of each trusted master shard and each on-chain data shard to the hash ring based on the operation results. Based on the location information of the on-chain data shards on the hash ring, a target trusted master shard is allocated; Based on the target trusted primary shard, the corresponding target trusted backup shard is determined.
6. The method according to claim 1, characterized in that, The execution of smart contract consensus within the target trusted master shard includes: The consensus lock determines whether the ledger involved in the smart contract is in an occupied state; the consensus lock is stored in memory key-value pair structure. When the ledger is in an unoccupied state, the consensus process is executed within the target trusted master shard. If the ledger is in a occupied state, the smart contract will be suspended until the ledger is released.
7. The method according to claim 6, characterized in that, The step of asynchronously sending the consensus result to the target trusted backup shard to complete the data on-chain includes: Write the consensus result into the message queue; The target trusted backup shard reads the consensus result from the message queue and performs the data uploading operation; After the on-chain operation is completed, the ledger is synchronized to the target trusted master shard.
8. A computer device, comprising a memory, a processor, and a computer program stored in the memory, characterized in that, The processor executes the computer program to implement the method of claim 1.
9. A computer-readable storage medium having a computer program / instructions stored thereon, characterized in that, When the computer program / instruction is executed by the processor, it implements the method of claim 1.
10. A computer program product comprising a computer program / instructions, characterized in that, When the computer program / instruction is executed by the processor, it implements the method of claim 1.