Request processing method and device, computer device, storage medium and program product

Abstract

The application relates to a request processing method and device, computer equipment, a storage medium and a program product. The method comprises the following steps: acquiring a cross-shard event corresponding to a cross-shard processing request sent by a request end; acquiring a first signature information set corresponding to the cross-shard event; sending the cross-shard event and the first signature information set to the request end, so that the request end generates an associated cross-shard processing request based on the cross-shard event and the first signature information set, and sends the associated cross-shard processing request to a second shard; the second shard is used for checking the first signature information set by using the cross-shard event, obtaining a first check result, executing the associated cross-shard processing request based on the first check result, and returning a request operation result corresponding to the associated cross-shard processing request to the request end; and obtaining a target processing result of the cross-shard processing request based on the request operation result returned by the request end. By adopting the method, the cross-shard processing security can be improved.

Description

Technical Field

[0001] This application relates to the field of blockchain technology, and in particular to a request processing method, apparatus, computer equipment, computer-readable storage medium, and computer program product. Background Technology

[0002] With the development of blockchain technology, sharding technology has emerged. Different shards maintain their own ledgers and can process data in parallel, but cross-shard business needs to be coordinated between multiple shards.

[0003] In traditional technologies, when performing cross-shard processing, the sharding SDK (Software Development Kit) typically converts the acquired cross-shard events into corresponding cross-shard transactions and sends these transactions to the target shard for processing. However, the sharding SDK may tamper with the content of the cross-shard events after acquiring them, causing errors in the parameters of the cross-shard transactions sent to the target shard, resulting in low security in cross-shard processing. Summary of the Invention

[0004] Therefore, it is necessary to provide a request processing method, apparatus, computer device, computer-readable storage medium, and computer program product that can improve the security of cross-shard processing in response to the above-mentioned technical problems.

[0005] In a first aspect, this application provides a request processing method applied to nodes in a first shard of a blockchain network; the blockchain network includes multiple shards, each shard representing a sub-blockchain network within the blockchain network, the method comprising:

[0006] Obtain the cross-shard event corresponding to the cross-shard processing request sent by the requesting end; the cross-shard event is used to characterize the event generated by the first shard after executing the cross-shard processing request;

[0007] Obtain the first signature information set corresponding to the cross-shard event; the first signature information set includes the first signature information of each node in the first shard for the cross-shard event;

[0008] The cross-shard event and the first signature information set are sent to the requesting end, causing the requesting end to generate an associated cross-shard processing request based on the cross-shard event and the first signature information set. The associated cross-shard processing request is then sent to the corresponding second shard in the blockchain network. The second shard is used to verify the first signature information set using the cross-shard event, obtain a first verification result of the associated cross-shard processing request, execute the associated cross-shard processing request based on the first verification result, and return the request operation result corresponding to the associated cross-shard processing request to the requesting end.

[0009] Based on the request calculation result returned by the requesting end, the target processing result of the cross-shard processing request is obtained.

[0010] Secondly, this application also provides another request processing method, applied to nodes in a second shard of a blockchain network; the blockchain network includes multiple shards, each shard representing a sub-blockchain network within the blockchain network; the method includes:

[0011] The receiving end sends an associated cross-shard processing request; the receiving end is used to receive a cross-shard event corresponding to the cross-shard processing request sent by the requesting end and a first signature information set corresponding to the cross-shard event sent by a node in the first shard; and generates the associated cross-shard processing request based on the cross-shard event and the first signature information set; the cross-shard event is used to characterize the event generated by the first shard after executing the cross-shard processing request; the first signature information set includes the first signature information of each node in the first shard for the cross-shard event;

[0012] The first signature information set is verified using the cross-shard event to obtain the first verification result of the associated cross-shard processing request;

[0013] Based on the first verification result, the associated cross-shard processing request is executed, and the request calculation result corresponding to the associated cross-shard processing request is returned to the requesting end, so that the requesting end sends the request calculation result to the first shard; the nodes in the first shard are used to obtain the target processing result of the cross-shard processing request based on the request calculation result.

[0014] In one embodiment, obtaining the first verification result of the associated cross-shard processing request based on the first number of correct signatures includes:

[0015] If the number of correct signatures is greater than or equal to the first number, the cross-shard processing request verification is confirmed to be successful; the first number is used to represent the number of associated nodes in the first shard.

[0016] If the number of the first correct signatures is less than the first number, the verification of the associated cross-shard processing request is confirmed to have failed.

[0017] In one embodiment, executing the associated cross-shard processing request based on the first verification result includes:

[0018] If the first verification result indicates that the associated cross-shard processing request has passed verification, the associated cross-shard processing request is executed to obtain the request operation result corresponding to the associated cross-shard processing request;

[0019] The method further includes:

[0020] If the first verification result indicates that the associated cross-shard processing request fails verification, the associated cross-shard processing request is deleted, and an error message is returned to the requesting end.

[0021] In one embodiment, before returning the request calculation result corresponding to the associated cross-shard processing request to the requesting end, the method further includes:

[0022] Obtain the second signature information set corresponding to the request operation result; the second signature information set includes the second signature information of each node in the second slice for the request operation result;

[0023] The step of returning the request calculation result corresponding to the associated cross-shard processing request to the requesting end includes:

[0024] The request operation result and the second signature information set are returned to the requesting end, enabling the requesting end to generate cross-shard submission information based on the request operation result and the second signature information set, and send the cross-shard submission information to the first shard; the nodes in the first shard are used to verify the second signature information set using the request operation result to obtain a second verification result of the cross-shard submission information, and based on the second verification result, obtain the target processing result of the cross-shard processing request.

[0025] In one embodiment, obtaining the second signature information set corresponding to the request operation result includes:

[0026] Obtain the second signature information of each node in the second slice for the request operation result; each node in the second slice is used to serialize the result content in the request operation result to obtain the serialized data of the request operation result, and use the corresponding private key to sign the serialized data of the request operation result to obtain the corresponding second signature information;

[0027] If consensus is reached on the result of the request operation, a second signature information set corresponding to the result of the request operation is obtained based on the second signature information of each node on the result of the request operation.

[0028] In one embodiment, each node in the second slice is used to serialize the result content in the request operation result to obtain the serialized data of the request operation result, including:

[0029] Each node in the second segment is used to perform importance identification processing on the result content in the request operation result to obtain the second importance corresponding to the result content in the request operation result. Based on the second importance, key result content is extracted from the result content in the request operation result, and the key result content is serialized to obtain the serialized data of the request operation result.

[0030] Thirdly, this application also provides a request processing apparatus, applied to a node in a first shard of a blockchain network; the blockchain network includes multiple shards, each shard representing a sub-blockchain network within the blockchain network, including:

[0031] The first acquisition module is used to acquire cross-shard events corresponding to the cross-shard processing request sent by the requesting end; the cross-shard events are used to characterize the events generated by the first shard after executing the cross-shard processing request;

[0032] The second acquisition module is used to acquire the first signature information set corresponding to the cross-shard event; the first signature information set includes the first signature information of each node in the first shard for the cross-shard event;

[0033] A first sending module is configured to send the cross-shard event and the first signature information set to the requesting end, causing the requesting end to generate an associated cross-shard processing request based on the cross-shard event and the first signature information set, and send the associated cross-shard processing request to the corresponding second shard in the blockchain network; the second shard is configured to use the cross-shard event to verify the first signature information set, obtain a first verification result of the associated cross-shard processing request, execute the associated cross-shard processing request based on the first verification result, and return the request operation result corresponding to the associated cross-shard processing request to the requesting end;

[0034] The result determination module is used to obtain the target processing result of the cross-shard processing request based on the request calculation result returned by the requesting end.

[0035] Fourthly, this application also provides another request processing apparatus, applied to a node in a second shard of a blockchain network; the blockchain network includes multiple shards, each shard representing a sub-blockchain network within the blockchain network, including:

[0036] A request receiving module is used to receive an associated cross-shard processing request sent by a requesting end. The requesting end is used to receive a cross-shard event sent by a node in the first shard corresponding to the cross-shard processing request sent by the requesting end, and a first signature information set corresponding to the cross-shard event. Based on the cross-shard event and the first signature information set, the associated cross-shard processing request is generated. The cross-shard event is used to characterize an event generated by the first shard after executing the cross-shard processing request. The first signature information set includes the first signature information of each node in the first shard for the cross-shard event.

[0037] The signature verification module is used to verify the first signature information set using the cross-shard event to obtain the first verification result of the associated cross-shard processing request.

[0038] The result sending module is used to execute the associated cross-shard processing request based on the first verification result, return the request calculation result corresponding to the associated cross-shard processing request to the requesting end, and enable the requesting end to send the request calculation result to the first shard; the nodes in the first shard are used to obtain the target processing result of the cross-shard processing request based on the request calculation result.

[0039] Fifthly, this application also provides a computer device, including a memory and a processor, wherein the memory stores a computer program, and the processor executes the computer program to perform the following steps:

[0040] Obtain the cross-shard event corresponding to the cross-shard processing request sent by the requesting end; the cross-shard event is used to characterize the event generated by the first shard after executing the cross-shard processing request;

[0041] Obtain the first signature information set corresponding to the cross-shard event; the first signature information set includes the first signature information of each node in the first shard for the cross-shard event;

[0042] The cross-shard event and the first signature information set are sent to the requesting end, causing the requesting end to generate an associated cross-shard processing request based on the cross-shard event and the first signature information set. The associated cross-shard processing request is then sent to the corresponding second shard in the blockchain network. The second shard is used to verify the first signature information set using the cross-shard event, obtain a first verification result of the associated cross-shard processing request, execute the associated cross-shard processing request based on the first verification result, and return the request operation result corresponding to the associated cross-shard processing request to the requesting end.

[0043] Based on the request calculation result returned by the requesting end, the target processing result of the cross-shard processing request is obtained.

[0044] Sixthly, this application also provides a computer-readable storage medium having a computer program stored thereon, which, when executed by a processor, performs the following steps:

[0045] Obtain the cross-shard event corresponding to the cross-shard processing request sent by the requesting end; the cross-shard event is used to characterize the event generated by the first shard after executing the cross-shard processing request;

[0046] Obtain the first signature information set corresponding to the cross-shard event; the first signature information set includes the first signature information of each node in the first shard for the cross-shard event;

[0047] The cross-shard event and the first signature information set are sent to the requesting end, causing the requesting end to generate an associated cross-shard processing request based on the cross-shard event and the first signature information set. The associated cross-shard processing request is then sent to the corresponding second shard in the blockchain network. The second shard is used to verify the first signature information set using the cross-shard event, obtain a first verification result of the associated cross-shard processing request, execute the associated cross-shard processing request based on the first verification result, and return the request operation result corresponding to the associated cross-shard processing request to the requesting end.

[0048] Based on the request calculation result returned by the requesting end, the target processing result of the cross-shard processing request is obtained.

[0049] In a seventh aspect, this application also provides a computer program product, including a computer program that, when executed by a processor, performs the following steps:

[0050] Obtain the cross-shard event corresponding to the cross-shard processing request sent by the requesting end; the cross-shard event is used to characterize the event generated by the first shard after executing the cross-shard processing request;

[0051] Obtain the first signature information set corresponding to the cross-shard event; the first signature information set includes the first signature information of each node in the first shard for the cross-shard event;

[0052] The cross-shard event and the first signature information set are sent to the requesting end, causing the requesting end to generate an associated cross-shard processing request based on the cross-shard event and the first signature information set. The associated cross-shard processing request is then sent to the corresponding second shard in the blockchain network. The second shard is used to verify the first signature information set using the cross-shard event, obtain a first verification result of the associated cross-shard processing request, execute the associated cross-shard processing request based on the first verification result, and return the request operation result corresponding to the associated cross-shard processing request to the requesting end.

[0053] Based on the request calculation result returned by the requesting end, the target processing result of the cross-shard processing request is obtained.

[0054] The aforementioned request processing method, apparatus, computer device, computer-readable storage medium, and computer program product first acquire a cross-sharding event corresponding to the cross-sharding processing request sent by the requesting end; the cross-sharding event is used to characterize the event generated by the first shard after executing the cross-sharding processing request; then, the first signature information set corresponding to the cross-sharding event is acquired; the first signature information set includes the first signature information of each node in the first shard for the cross-sharding event; then, the cross-sharding event and the first signature information set are sent to the requesting end, causing the requesting end to generate an associated cross-sharding processing request based on the cross-sharding event and the first signature information set, and send the associated cross-sharding processing request to the corresponding second shard in the blockchain network; the second shard uses the cross-sharding event to verify the first signature information set, obtains a first verification result of the associated cross-sharding processing request, executes the associated cross-sharding processing request based on the first verification result, and returns the request operation result corresponding to the associated cross-sharding processing request to the requesting end; finally, based on the request operation result returned by the requesting end, the target processing result of the cross-sharding processing request is obtained. In this way, during cross-shard processing, based on the first signature information of each node in the first shard for the cross-shard event, a first signature information set corresponding to the cross-shard event is obtained, achieving the purpose of multi-node signing of the cross-shard event, which is beneficial to improving the security of subsequent cross-shard processing. Moreover, based on the cross-shard event and the first signature information set, an associated cross-shard processing request is generated and sent to the corresponding second shard. This allows the second shard to verify the first signature information set using the cross-shard event before executing the associated cross-shard processing request, obtaining the first verification result of the associated cross-shard processing request. This achieves the purpose of verifying the associated cross-shard processing request before execution, and it verifies multiple first signature information for the cross-shard event, which helps to avoid the defect of the associated cross-shard processing request being tampered with, resulting in low security of cross-shard processing, and further improves the security of cross-shard processing. Attached Figure Description

[0055] To more clearly illustrate the technical solutions in the embodiments of this application or related technologies, the drawings used in the description of the embodiments of this application or related technologies will be briefly introduced below. Obviously, the drawings described below are only some embodiments of this application. For those skilled in the art, other related drawings can be obtained based on these drawings without creative effort.

[0056] Figure 1 This is an application environment diagram of a request processing method in one embodiment;

[0057] Figure 2 This is a flowchart illustrating a request processing method in one embodiment;

[0058] Figure 3 This is a schematic diagram of the overall architecture of a cross-shard implementation method in one embodiment;

[0059] Figure 4 This is a flowchart illustrating a cross-shard implementation method in one embodiment;

[0060] Figure 5 This is a schematic diagram illustrating the signature processing of cross-shard events by each node in the first shard in one embodiment.

[0061] Figure 6 This is a flowchart illustrating a blockchain sharding security processing method in one embodiment;

[0062] Figure 7 This is a flowchart illustrating the steps for obtaining the cross-shard event corresponding to a cross-shard processing request in one embodiment.

[0063] Figure 8 This is a flowchart illustrating the steps for identifying cross-shard events in one embodiment;

[0064] Figure 9 This is a schematic diagram illustrating the format of cross-shard events in one embodiment;

[0065] Figure 10 This is a schematic diagram illustrating the signing of cross-shard events in one embodiment;

[0066] Figure 11 This is a schematic diagram illustrating the signature processing of the request computation result by each node in the second shard in one embodiment;

[0067] Figure 12 This is a flowchart illustrating the steps for obtaining a second verification result of cross-shard submission information in one embodiment;

[0068] Figure 13 This is a schematic diagram of the format for submitting transactions across shards in one embodiment;

[0069] Figure 14 This is a flowchart illustrating the steps of input parameter parsing and signature verification in one embodiment;

[0070] Figure 15 This is a flowchart illustrating the request processing method in another embodiment;

[0071] Figure 16 This is a schematic diagram of the format of a cross-shard transaction in one embodiment;

[0072] Figure 17 This is a schematic diagram of the pre-signature verification process for the sharding chain in one embodiment;

[0073] Figure 18 This is a schematic diagram of the result signing process in one embodiment;

[0074] Figure 19 This is a schematic diagram illustrating the signing of the execution result of a cross-shard transaction in one embodiment;

[0075] Figure 20 This is a flowchart illustrating the request processing method in yet another embodiment;

[0076] Figure 21 This is a structural block diagram of a request processing device in one embodiment;

[0077] Figure 22 This is a structural block diagram of a request processing device in another embodiment;

[0078] Figure 23 This is an internal structural diagram of a computer device in one embodiment. Detailed Implementation

[0079] To make the objectives, technical solutions, and advantages of this application clearer, the following detailed description is provided in conjunction with the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are merely illustrative and not intended to limit the scope of this application.

[0080] It should be noted that the terms "first," "second," etc., used in this application can be used to describe various elements, but these elements are not limited by these terms. These terms are only used to distinguish the first element from the second element. The terms "comprising" and "having," and any variations thereof, used in this application, are intended to cover non-exclusive inclusion. The term "multiple" used in this application refers to two or more. The term "and / or" used in this application refers to one of the embodiments, or any combination of multiple embodiments.

[0081] As blockchain businesses expand, the performance bottleneck of a single chain becomes increasingly apparent, making sharding technology a crucial direction for improving throughput and parallel processing capabilities. In a sharding architecture, different shards maintain their own ledgers and can process transactions in parallel. However, cross-shard transactions (such as asset transfers and cross-shard contract calls) require coordination between the main shard and multiple shards.

[0082] A typical cross-shard implementation relies on a sharding SDK, and its overall architecture is as follows: Figure 3 As shown (where each shard is an independent blockchain network, and each blockchain network includes multiple nodes, such as Node1, Node2, etc.; where Node1 represents node 1; Node2 represents node 2), the corresponding processing flow is as follows: Figure 4 As shown, the specific steps include: 1. The sharding SDK sends the main transaction to the main shard chain; 2. The main shard chain executes the main transaction and generates cross-shard events (via logs or event bus); 3. The sharding SDK subscribes to and retrieves cross-shard events; 4. The sharding SDK parses the events, generates the corresponding cross-shard transactions, and sends them to the target shard chain; 5. The sharding SDK collects the execution results from each shard chain, aggregates them into a commit transaction, and sends it back to the main shard chain to complete the transaction commit.

[0083] This model achieves automated driving of cross-shard business, but it has significant shortcomings in security mechanisms. The main drawbacks of existing cross-shard solutions are as follows: 1. Event content can be tampered with: After obtaining a cross-shard event, the shard SDK can modify parameters to generate incorrect cross-shard transactions. The target shard chain does not have the original event signature as a reliable basis, making it difficult to identify tampering. That is, the shard SDK may tamper with the content of the cross-shard event after obtaining it, causing the parameters of the cross-shard transaction sent to the target shard to be incorrect, and the target shard lacks effective means to identify the authenticity. 2. Event acquisition competition and preemption: Cross-shard events are usually broadcast and can be obtained by multiple shard SDKs. Malicious SDKs can preemptively send forged transactions, affecting the business order and even causing state conflicts. That is, the broadcast of cross-shard events can be obtained by multiple shard SDKs, and malicious SDKs can preemptively send forged transactions, disrupting the business timing and consistency. 3. SDK Inaction Leading to Execution Crashes: If the sharding SDK chooses to ignore a certain event due to a malfunction or attack, cross-shard transactions cannot continue, lacking automatic fault tolerance or alternative execution mechanisms; that is, the sharding SDK can directly ignore a certain cross-shard event without processing, causing the entire cross-shard transaction to freeze. 4. Lack of Pre-Execution Trusted Verification: Existing solutions mostly check the results after transaction execution. If the transaction itself is malicious or erroneous, it has already consumed on-chain computing and storage resources.

[0084] Based on this, in order to solve the above problems, this application proposes a request processing method, specifically a blockchain sharding security processing method. Without introducing additional complex consensus layer modifications, it solves the above problems through node signature endorsement, shard chain signature verification, transaction submission signature verification, and distributed deployment. Moreover, it does not rely on the assumption that "all SDKs are trustworthy", has practical feasibility and deployability, and is conducive to improving the security of cross-sharding processing.

[0085] The request processing method provided in this application embodiment can be applied to, for example, Figure 1 In the application environment shown, the requesting end 103 is connected to the first shard 101 and the second shard 102 in the blockchain network. The blockchain network includes multiple shards (such as the first shard and the second shard), each shard representing a sub-blockchain network within the blockchain network, and each shard includes multiple nodes. Different shards maintain their respective ledgers. It should be noted that the number of nodes included in each shard can be the same or different; this application does not impose any specific limitations. Specifically, refer to... Figure 1 The requesting end 103 receives a cross-shard processing request and sends it to the first shard 101. The first shard 101 obtains the cross-shard event corresponding to the cross-shard processing request; the cross-shard event represents the event generated by the first shard 101 after executing the cross-shard processing request; it obtains the first signature information set corresponding to the cross-shard event; the first signature information set includes the first signature information of each node in the first shard 101 for the cross-shard event; and sends the cross-shard event and the first signature information set to the requesting end 103. The requesting end 103 generates a related cross-shard processing request based on the cross-shard event and the first signature information set, and sends the related cross-shard processing request to the corresponding second shard 102 in the blockchain network. The second shard 102 uses the cross-shard event to verify the first signature information set, obtains the first verification result of the related cross-shard processing request, executes the related cross-shard processing request based on the first verification result, and returns the request operation result corresponding to the related cross-shard processing request to the requesting end 103. The requesting end 103 sends the request calculation result corresponding to the cross-shard processing request to the first shard 101. The first shard 101 obtains the target processing result of the cross-shard processing request based on the request calculation result returned by the requesting end 103.

[0086] In this application, the first shard 101 can refer to an independent sub-blockchain network within the blockchain network, comprising multiple nodes. Each node can be an independent physical server or a cloud server providing cloud computing services. The second shard 102 can refer to another independent sub-blockchain network within the blockchain network, also comprising multiple nodes. The requesting end 103 can refer to a business system that includes the sharding SDK; the business system can be deployed on a terminal or on a server. It should be noted that this application can be applied to blockchain networks, to the actual development of underlying blockchain software, and also as a means of external promotion.

[0087] Before introducing the specific embodiments of this application, the technical terms involved in this application will be explained:

[0088] Sharding: In a blockchain system, a global ledger is divided into multiple independently operating partitions according to certain rules. Each partition is called a shard, which is used to process transactions in parallel to improve throughput.

[0089] Sharding SDK: A software development kit used to interact with multiple sharded chains at the application layer, enabling functions such as cross-shard business logic calls, event retrieval, transaction construction and submission.

[0090] Main Shard: A shard chain that is responsible for initiating the main transaction and converging the final result in a cross-shard scenario. It usually stores the global state or the control logic of cross-shard transactions.

[0091] Cross-shard event: Event data generated by the main shard chain during the execution of the main transaction, used to notify each relevant shard to execute the corresponding cross-shard business logic.

[0092] Cross-shard transaction: A transaction constructed by the sharding SDK based on cross-shard events and sent to the target shard chain for execution, used to complete the specific operations of cross-shard business.

[0093] Cross-shard Commit Transaction: After the sharding SDK collects and signs all cross-shard transaction execution results, it sends the final confirmation transaction to the main shard chain to complete the commit of the cross-shard transaction and the global state update.

[0094] Endorsement: Blockchain nodes digitally sign specific data (such as cross-shard events or execution results) to prove the legality and credibility of the data. It is often used for permission verification and consensus processes.

[0095] Signature Verification: The process by which the recipient uses a public key to decrypt and verify the signed data to confirm that the data has not been tampered with and that its source is trustworthy.

[0096] Distributed Deployment: Runs services with the same function (such as sharding SDK) on multiple nodes or instances simultaneously, improving availability and resistance to malicious attacks through redundancy and collaboration.

[0097] TxID (Transaction ID): A unique identifier for a transaction, typically using a specific encoding format to distinguish between different types of transactions, such as regular transactions and cross-shard transactions.

[0098] In one exemplary embodiment, such as Figure 2 As shown, a request processing method is provided, which is applied to Figure 1 Taking a node in the first slice as an example, the explanation includes the following steps S201 to S204. Wherein:

[0099] Step S201: Obtain the cross-shard event corresponding to the cross-shard processing request sent by the requesting end; the cross-shard event is used to characterize the event generated by the first shard after executing the cross-shard processing request.

[0100] Cross-shard processing requests refer to requests that require coordination between at least two shards. Specifically, these are processing requests corresponding to cross-shard businesses, such as asset transfer requests, cross-shard contract call requests, and resource transfer requests; for example, account A transferring M yuan to account B, or account A transferring N yuan to both account B and account C. In practical scenarios, cross-shard processing requests can refer to the current transaction processing main transaction or the main transaction itself. It should be noted that different shards maintain their own ledgers, and different shards correspond to different accounts. For example, the first shard corresponds to accounts 1 to 10, the second shard to accounts 11 to 20, and the third shard to accounts 21 to 30.

[0101] The first shard refers to the shard among multiple shards in the blockchain network that is responsible for handling cross-shard processing request access, cross-shard event generation, and final result aggregation. Specifically, it refers to the main shard, such as the shard containing the sending account in a cross-shard processing request. The second shard refers to the shard among multiple shards in the blockchain network that is responsible for executing cross-shard events. Specifically, it refers to the shard corresponding to the cross-shard event, such as the shard containing the receiving account in a cross-shard processing request.

[0102] Cross-shard events refer to events generated by the first shard after executing a cross-shard processing request. These events notify relevant shards to execute corresponding cross-shard business logic. Specifically, they are events that require coordination with other shards (such as shards other than the first shard), such as an increase of M yuan in account B's balance (account B is located in the second shard) and an increase of N yuan in account C's balance (account C is located in the third shard). The entire cross-shard processing request needs to be coordinated between the first shard and other shards (such as the second shard). The first shard executes the main events in the cross-shard processing request (such as resource transfer operations, such as a decrease of M yuan in account A's balance), and the second shard executes the cross-shard events corresponding to the cross-shard processing request. A cross-shard processing request can correspond to one or more cross-shard events, determined based on the specific cross-shard processing request. For example, suppose a cross-shard processing request is for account A to transfer M yuan to account B, where account A is in shard 1 and account B is in shard 2. Then, shard 1 executes the main business operation in the cross-shard processing request, "account A's balance decreases by M yuan," and generates a cross-shard event, "account B's balance increases by M yuan," which needs to be executed in shard 2. Suppose a cross-shard processing request is for account A to transfer N yuan to both account B and account C, where account A is in shard 1, account B is in shard 2, and account C is in shard 3. Then, shard 1 executes the main business operation in the cross-shard processing request, "account A's balance decreases by 2N yuan," and generates a cross-shard event, "account B's balance increases by N yuan," which needs to be executed in shard 2, and a cross-shard event, "account C's balance increases by N yuan," which needs to be executed in shard 3.

[0103] For example, the terminal obtains a cross-shard processing request and sends it to the requesting end (which includes the sharding SDK). The requesting end calls the sharding contract, determines that the shard corresponding to the cross-shard processing request is the first shard, and then sends the cross-shard processing request to the first shard; for example, if the shard where the sending account in the cross-shard processing request is located is the first shard, then the shard corresponding to the cross-shard processing request is determined to be the first shard. Next, the nodes in the first shard execute the cross-shard processing request, obtaining the state change log corresponding to the cross-shard processing request. Based on the state change log, a cross-shard event corresponding to the cross-shard processing request is generated. For example, after executing the cross-shard processing request, the nodes in the first shard obtain the request identifier corresponding to the cross-shard processing request. If the request identifier meets the cross-shard processing request identifier format, the log generated by the first shard after executing the cross-shard processing request is obtained as the state change log corresponding to the cross-shard processing request. For example, the generated log is preprocessed to obtain the state change log corresponding to the cross-shard processing request. Then, using the event extraction instruction, the event set corresponding to the cross-shard processing request is extracted from the state change log. Next, the event identifiers corresponding to the events in the event set are obtained. From the event set, candidate events whose event identifiers meet the preset cross-shard event identifiers are determined. Finally, the candidate events are validated to obtain the validation results. From the candidate events, the candidate events whose validation results indicate that the validation has passed are determined as the cross-shard events corresponding to the cross-shard processing request.

[0104] Step S202: Obtain the first signature information set corresponding to the cross-shard event; the first signature information set includes the first signature information of each node in the first shard for the cross-shard event.

[0105] The first signature information refers to the digital signature information of the nodes in the first shard for cross-shard events. This involves calculating the digest value (such as a hash value) of the cross-shard event or its serialized data, and then using the private key of each node in the first shard to encrypt the digest value of the cross-shard event or its serialized data to obtain the corresponding first signature information. It should be noted that each node in the first shard uses its corresponding private key to sign the cross-shard event, obtaining the corresponding first signature information. It should also be noted that the signature algorithm used can be any signature algorithm involved in blockchain technology, such as ECDSA (Elliptic Curve Digital Signature Algorithm) or EdDSA (Edwards-curve Digital Signature Algorithm).

[0106] The first signature information set includes the first signature information of each node in the first shard for cross-shard events; for example, refer to Figure 5 The first signature information set S501 includes the first signature information of node 11 for cross-shard events, the first signature information of node 12 for cross-shard events, the first signature information of node 13 for cross-shard events, ... the first signature information of node 1n for cross-shard events.

[0107] For example, after obtaining a cross-shard event, each node in the first shard performs importance identification processing on the event content of the cross-shard event to obtain the first importance corresponding to the event content of the cross-shard event. Key event content with a first importance greater than a first preset importance is extracted from the event content of the cross-shard event. The key event content is then serialized to obtain the serialized data of the cross-shard event. The serialized data of the cross-shard event is then signed using the corresponding private key to obtain the corresponding first signature information. For example, a hash algorithm is used to calculate the digest value of the serialized data of the cross-shard event, and then the digest value is encrypted using the corresponding private key to obtain the corresponding first signature information. Next, consensus processing is performed on the cross-shard event. If consensus on the cross-shard event is passed, the first signature information set corresponding to the cross-shard event is obtained based on the first signature information of the cross-shard event by each node in the first shard.

[0108] Step S203: Send the cross-shard event and the first signature information set to the requesting end, so that the requesting end generates an associated cross-shard processing request based on the cross-shard event and the first signature information set, and sends the associated cross-shard processing request to the corresponding second shard in the blockchain network.

[0109] The second shard is used to verify the first signature information set using cross-shard events, obtain the first verification result of the associated cross-shard processing request, execute the associated cross-shard processing request based on the first verification result, and return the request operation result corresponding to the associated cross-shard processing request to the requesting end.

[0110] Among them, the cross-shard processing request refers to a request that includes cross-shard events and the first signature information set. Specifically, it refers to a cross-shard business request that needs to be executed in the second shard, such as a cross-shard transaction.

[0111] Verifying the first signature information set means determining the number of correct signatures corresponding to the first signature information set, such as determining the number of correct signatures in the first signature information set.

[0112] The first verification result of the associated cross-shard processing request is used to indicate whether the associated cross-shard processing request passes or fails verification. For example, if the first number of correct signatures is greater than or equal to the first number, the associated cross-shard processing request is confirmed to have passed verification; if the first number of correct signatures is less than the first number, the associated cross-shard processing request is confirmed to have failed verification.

[0113] The request calculation result refers to the calculation result corresponding to the cross-shard processing request, specifically the cross-shard transaction execution result, such as account B's balance should increase by M yuan and account C's balance should increase by N yuan. It should be noted that when executing a cross-shard processing request, only the calculation result is calculated, such as account B's balance should increase by M yuan and account C's balance should increase by N yuan; at this time, the balances of account B and account C are not actually updated, i.e., no on-chain operation is performed.

[0114] For example, nodes in the first shard send cross-shard events and a first signature information set to the requesting end. The requesting end generates a corresponding associated cross-shard processing request identifier based on the cross-shard events, and generates an associated cross-shard processing request according to the associated cross-shard processing request format, based on the cross-shard events, the first signature information set, and the associated cross-shard processing request identifier. This associated cross-shard processing request is then sent to the corresponding second shard in the blockchain network. Upon receiving the associated cross-shard processing request, the second shard determines whether the associated cross-shard processing request identifier in the associated cross-shard processing request meets the associated cross-shard processing request identifier format. If so, it uses the public key corresponding to the node identifier of the first signature information in the first signature information set, along with the cross-shard events, to verify the first signature information, obtaining a verification result. For example, it uses the public key corresponding to the node identifier of the first signature information to decrypt the first signature information, obtaining the original digest value, and calculates the digest value corresponding to the serialized data of the cross-shard events. The original digest value is compared with the digest value corresponding to the serialized data of the cross-shard events. If they are the same, the first signature information is confirmed to be correct; otherwise, the first signature is confirmed to be correct. The information is incorrect. Next, based on the verification results of each first signature, the total number of correct first signatures is determined as the first correct signature count. Based on this first correct signature count, the first verification result of the associated cross-shard processing request is obtained. For example, if the first correct signature count is greater than or equal to the first count (i.e., the number of associated nodes in the first shard), the associated cross-shard processing request verification is confirmed to be successful; if the first correct signature count is less than the first count, the associated cross-shard processing request verification is confirmed to be unsuccessful. Then, if the first verification result indicates that the associated cross-shard processing request verification is successful, the associated cross-shard processing request is executed, the request operation result corresponding to the associated cross-shard processing request is obtained, and the request operation result is returned to the requesting end. The requesting end sends the request operation result to the first shard.

[0115] Step S204: Based on the request calculation result returned by the requesting end, obtain the target processing result of the cross-shard processing request.

[0116] The target processing result of the cross-shard processing request is used to indicate whether the cross-shard processing request was successfully processed or failed.

[0117] For example, the requesting end receives the second signature information set corresponding to the request operation result returned by the second shard; the second signature information set includes the second signature information of each node in the second shard for the request operation result; for example, after obtaining the request operation result, each node in the second shard is used to perform importance identification processing on the result content in the request operation result to obtain the second importance corresponding to the result content in the request operation result, extract the key result content whose second importance is greater than the second preset importance from the result content in the request operation result, perform serialization processing on the key result content to obtain the serialized data of the request operation result, and use the corresponding private key to sign the serialized data of the request operation result to obtain the corresponding second signature information; for example, a hash algorithm is used to calculate the digest value of the serialized data of the request operation result, and then the digest value is encrypted using the corresponding private key to obtain the corresponding second signature information; then, consensus processing is performed on the request operation result, and if the consensus on the request operation result is passed, the second signature information set corresponding to the request operation result is obtained based on the second signature information of each node in the second shard for the request operation result, and the second signature information set is sent to the requesting end.

[0118] Next, the requesting end generates a corresponding cross-shard submission information identifier based on the request operation result. Following the cross-shard submission information format, it generates cross-shard submission information based on the request operation result, the second signature information set, and the cross-shard submission information identifier, and sends the cross-shard submission information to the first shard. After receiving the cross-shard submission information, the first shard determines whether the cross-shard submission information identifier in the cross-shard submission information meets the cross-shard submission information identifier format. If so, it obtains the target parameters in the cross-shard submission information. The target parameters include the requested operation result and the second signature information set. Next, it determines whether the target parameters meet the preset parameter format. If so, it uses the public key corresponding to the node identifier of the second signature information in the second signature information set, as well as the requested operation result, to verify the second signature information and obtain the verification result of the second signature information. For example, it uses the public key corresponding to the node identifier of the second signature information to decrypt the second signature information to obtain the original digest value, and calculates the digest value corresponding to the serialized data of the requested operation result. It compares the original digest value with the digest value corresponding to the serialized data of the requested operation result. If they are the same, the second signature information is confirmed to be correct; if they are different, the second signature information is confirmed to be incorrect. Then, based on each of the first shards... The verification results of the two signatures determine the total number of correct second signatures, which is taken as the second correct signature count. Based on the second correct signature count, the second verification result of the cross-shard submission information is obtained. For example, if the second correct signature count is greater than or equal to the second count (i.e., the number of associated nodes in the second shard), the cross-shard submission information verification is confirmed to be successful; if the second correct signature count is less than the second count, the cross-shard submission information verification is confirmed to be unsuccessful. Finally, if the second verification result indicates that the cross-shard submission information verification is successful, the cross-shard processing request is confirmed to be successful based on the request operation result and other request operation results obtained after the first shard executes the cross-shard processing request, and a success message is returned to the requesting end, and the request operation result is written to the corresponding block; if the second verification result indicates that the cross-shard submission information verification is unsuccessful, the cross-shard processing request is confirmed to be unsuccessful, the cross-shard submission information is deleted, and an error message is returned to the requesting end.

[0119] For example, see reference. Figure 6This application also provides a blockchain security processing method, including the following steps: 1. The sharding SDK calls the sharding contract to obtain the shard where the main transaction is currently processed; 2. The sharding SDK sends the main transaction to the main shard; 3. Shard 1 signs the transaction event during the block consensus process; 4. The sharding SDK obtains the cross-shard event generated by the main transaction; 5. The sharding SDK generates a cross-shard transaction based on the content of the cross-shard event, attaches the corresponding signature, and sends it to the corresponding sub-shard chain (such as shard 2, shard n); 6. Shard 2 verifies the cross-shard transaction; 7. Shard 2 signs the transaction execution result during the block consensus process; 8. The sharding SDK aggregates the executed transaction results; 9. The sharding SDK generates a submission transaction, attaches the corresponding signature, and sends it to the main shard; 10. Shard 1 verifies the submission transaction.

[0120] In the above request processing method, firstly, the cross-shard event corresponding to the cross-shard processing request sent by the requesting end is obtained; the cross-shard event is used to characterize the event generated by the first shard after executing the cross-shard processing request; then, the first signature information set corresponding to the cross-shard event is obtained; the first signature information set includes the first signature information of each node in the first shard for the cross-shard event; then, the cross-shard event and the first signature information set are sent to the requesting end, so that the requesting end generates an associated cross-shard processing request based on the cross-shard event and the first signature information set, and sends the associated cross-shard processing request to the corresponding second shard in the blockchain network; the second shard uses the cross-shard event to verify the first signature information set, obtains the first verification result of the associated cross-shard processing request, executes the associated cross-shard processing request based on the first verification result, and returns the request operation result corresponding to the associated cross-shard processing request to the requesting end; finally, based on the request operation result returned by the requesting end, the target processing result of the cross-shard processing request is obtained. In this way, during cross-shard processing, based on the first signature information of each node in the first shard for the cross-shard event, a first signature information set corresponding to the cross-shard event is obtained, achieving the purpose of multi-node signing of the cross-shard event, which is beneficial to improving the security of subsequent cross-shard processing. Moreover, based on the cross-shard event and the first signature information set, an associated cross-shard processing request is generated and sent to the corresponding second shard. This allows the second shard to verify the first signature information set using the cross-shard event before executing the associated cross-shard processing request, obtaining the first verification result of the associated cross-shard processing request. This achieves the purpose of verifying the associated cross-shard processing request before execution, and it verifies multiple first signature information for the cross-shard event, which helps to avoid the defect of the associated cross-shard processing request being tampered with, resulting in low security of cross-shard processing, and further improves the security of cross-shard processing.

[0121] In one exemplary embodiment, such as Figure 7As shown, step S201 above, obtaining the cross-shard event corresponding to the cross-shard processing request sent by the requesting end, includes the following steps S701 to S703. Wherein:

[0122] Step S701: Obtain the target execution log corresponding to the cross-shard processing request sent by the requesting end.

[0123] Step S702: Extract the event set corresponding to the cross-shard processing request from the target execution log.

[0124] Step S703: Obtain the cross-sharding event corresponding to the cross-sharding processing request from the event set.

[0125] The target execution log refers to the state change log generated by the first shard after executing the cross-shard processing request, which includes the event set corresponding to the cross-shard processing request.

[0126] The event set corresponding to the cross-shard processing request includes events generated by the first shard after executing the cross-shard processing request, such as cross-shard events.

[0127] For example, a node in the first shard obtains the state change log corresponding to the cross-shard processing request sent by the requesting end, and uses it as the target execution log. Then, according to the log parsing instructions, the target execution log is parsed to obtain the log parsing result, and the event corresponding to the cross-shard processing request is obtained from the log parsing result. The obtained events are summarized to obtain the event set corresponding to the cross-shard processing request. Finally, from the event set, the events whose corresponding event identifiers meet the preset cross-shard event identifiers and whose corresponding legality verification results indicate that the legality verification has passed are determined as the cross-shard events corresponding to the cross-shard processing request.

[0128] In this embodiment, the target execution log corresponding to the cross-shard processing request sent by the requesting end is first obtained. Then, the event set corresponding to the cross-shard processing request is extracted from the target execution log. Finally, the cross-shard event corresponding to the cross-shard processing request is obtained from the event set. In this way, the purpose of obtaining the cross-shard event corresponding to the cross-shard processing request from the target execution log is achieved, which helps to ensure the accurate extraction of cross-shard events and thus improves the accuracy of cross-shard event determination.

[0129] In an exemplary embodiment, step S701 above, obtaining the target execution log corresponding to the cross-shard processing request sent by the requesting end, specifically includes the following: obtaining the request identifier corresponding to the cross-shard processing request; if the request identifier meets the cross-shard processing request identifier format, obtaining the state change log corresponding to the cross-shard processing request; the state change log is used to characterize the log generated by the first shard after executing the cross-shard processing request; based on the state change log, obtaining the target execution log corresponding to the cross-shard processing request.

[0130] Among them, the request identifier corresponding to the cross-shard processing request refers to the identifier corresponding to the cross-shard processing request.

[0131] The cross-fragment processing request identifier format is used to indicate that the cross-fragment processing request identifier has a specific identifier prefix or identifier bit, such as 123, ABC, etc.

[0132] The state change log refers to the log generated by the first shard after executing the cross-shard processing request. The target execution log corresponding to the cross-shard processing request is the state change log.

[0133] For example, a node in the first shard obtains the request identifier corresponding to the cross-shard processing request by obtaining the request identifier instruction; then, it determines whether the format of the request identifier corresponding to the cross-shard processing request meets the cross-shard processing request identifier format, such as whether a specific identifier prefix or identifier bit is set in the cross-shard processing request identifier. If so, it confirms that the cross-shard processing request is a real cross-shard processing request, and obtains the log generated by the first shard after executing the cross-shard processing request as the state change log corresponding to the cross-shard processing request; finally, it uses the state change log corresponding to the cross-shard processing request as the target execution log corresponding to the cross-shard processing request.

[0134] In this embodiment, if the request identifier corresponding to the cross-shard processing request meets the cross-shard processing request identifier format, the state change log corresponding to the cross-shard processing request is obtained, and the target execution log corresponding to the cross-shard processing request is obtained based on the state change log. In this way, verifying the request identifier corresponding to the cross-shard processing request first can ensure the accuracy of the obtained target execution log, thereby improving the accuracy of obtaining the target execution log, and further improving the accuracy of the cross-shard events obtained based on the target execution log.

[0135] In an exemplary embodiment, step S703 above, obtaining the cross-sharding event corresponding to the cross-sharding processing request from the event set, includes: obtaining the event identifier corresponding to the event in the event set; determining candidate events from the event set whose event identifiers satisfy the preset cross-sharding event identifier; obtaining the legality verification result of the candidate events; determining candidate events from the candidate events whose legality verification result indicates that the legality verification has passed, thereby obtaining the cross-sharding event corresponding to the cross-sharding processing request.

[0136] The event identifier is used to indicate the event type corresponding to the event.

[0137] Among them, the preset cross-shard event identifier refers to the cross-shard event type, such as cross-shard topic.

[0138] Among them, a candidate event refers to an event in the event set whose corresponding event identifier satisfies the preset cross-shard event identifier.

[0139] The validity verification result of the candidate event is used to indicate whether the content of the candidate event is valid, such as whether the validity verification passes or fails.

[0140] Among them, the cross-shard processing request corresponding to the cross-shard event refers to the event in the candidate event whose legality verification result indicates that the legality verification has passed.

[0141] For example, the first node in the first shard obtains the event identifier corresponding to the event in the event set by obtaining the instruction through the event identifier; then, it determines the event whose corresponding event identifier satisfies the preset cross-shard event identifier from the event set as a candidate event; next, it performs legality verification on the event content of the candidate event to obtain the legality verification result of the candidate event; finally, it determines the candidate event whose legality verification result indicates that the legality verification has passed from the candidate events as the cross-shard event corresponding to the cross-shard processing request.

[0142] In this embodiment, when the cross-sharding event corresponding to the cross-sharding processing request is obtained, the event identifier and legality verification result corresponding to the event in the event set are comprehensively considered, which makes the determined cross-sharding event more accurate and further improves the accuracy of cross-sharding event determination.

[0143] In an exemplary embodiment, step S202 above, obtaining the first signature information set corresponding to the cross-shard event, specifically includes the following: obtaining the first signature information of each node in the first shard for the cross-shard event; each node in the first shard is used to serialize the event content in the cross-shard event to obtain the serialized data of the cross-shard event, and to sign the serialized data of the cross-shard event using the corresponding private key to obtain the corresponding first signature information; if the consensus on the cross-shard event is passed, the first signature information set corresponding to the cross-shard event is obtained based on the first signature information of each node for the cross-shard event.

[0144] A cross-shard event contains multiple event components, such as the user information that generated the cross-shard transaction, the cross-shard ID (identifier), the sequence number, the shard ID (identifier), the contract name, the contract method, and the input parameters. The user information that generated the cross-shard transaction refers to the user information that triggered the cross-shard processing request; the cross-shard ID is the request identifier for the cross-shard processing request; the sequence number is the sequence number corresponding to the cross-shard event; and the shard ID is the shard identifier corresponding to the cross-shard event, used to indicate which shard needs to process the cross-shard event. For example, the format of a cross-shard event can be found by referring to... Figure 9 .

[0145] Serialization of event content across shards refers to sorting the event content across shards according to a preset order.

[0146] Among them, the serialized data of cross-shard events refers to the structured data of cross-shard events, specifically the event content after the cross-shard events are arranged, such as (user information for generating cross-shard transactions; cross-shard ID; sequence number; shard ID; contract name; contract method; input parameters).

[0147] For example, after receiving a cross-shard event, each node in the first shard serializes the event content to obtain serialized data of the cross-shard event. A hash algorithm (such as SHA-256) is used to calculate a digest value (such as a hash value) of the serialized data, and the digest value is encrypted using the corresponding private key to obtain the corresponding first signature information. Next, each node in the first shard performs consensus processing on the cross-shard event. For instance, each node in the first shard votes on the cross-shard event to obtain corresponding voting information. This voting information is then aggregated, and the total number of votes in favor is counted. If the total number of votes is greater than a preset number, the consensus on the cross-shard event is confirmed to be passed. Finally, if the consensus on the cross-shard event is passed, the first signature information of each node in the first shard is aggregated to obtain the first signature information set corresponding to the cross-shard event.

[0148] For example, after receiving a cross-shard event, each node in the first shard is used to serialize the event content of the cross-shard event according to the serialization instructions, obtaining serialized data of the cross-shard event. Different hash algorithms (such as SHA-256, SHA-3, SM3) are then used to process the serialized data of the cross-shard event, obtaining different digest values ​​(such as different hash values). The corresponding private keys are then used to encrypt the different digest values, obtaining corresponding different sub-signature information, such as sub-signature information 1, sub-signature information 2, and sub-signature information 3. Next, the corresponding different sub-signature information is summarized to obtain the corresponding first signature information, i.e., each first signature information includes the corresponding different sub-signature information. Following this method, the first signature information of each node in the first shard for the cross-shard event can be obtained, such as node 1. The first signature information for the cross-shard event is (sub-signature information 1; sub-signature information 2; sub-signature information 3) for node 11, (sub-signature information 4; sub-signature information 5; sub-signature information 6) for node 12, and (sub-signature information 7; sub-signature information 8; sub-signature information 9) for node 13. Next, each node in the first shard performs consensus processing on the cross-shard event. For example, each node in the first shard votes on the cross-shard event, obtaining corresponding voting information. These voting information are then aggregated, and the total number of votes in favor is counted. If the total number of votes is greater than a preset number, the consensus on the cross-shard event is confirmed to have passed. Finally, if the consensus on the cross-shard event has passed, the first signature information of each node in the first shard for the cross-shard event is aggregated to obtain the first signature information set corresponding to the cross-shard event.

[0149] In this embodiment, the first signature information of each node in the first shard for the cross-shard event is obtained, and based on the first signature information of each node for the cross-shard event, the first signature information set corresponding to the cross-shard event is obtained. This facilitates the subsequent verification of the first signature information set using the cross-shard event before executing the associated cross-shard processing request, thereby obtaining the first verification result of the associated cross-shard processing request. This achieves the purpose of verifying the associated cross-shard processing request before execution, which is beneficial to improving the security of cross-shard processing.

[0150] In an exemplary embodiment, each node in the first shard is used to serialize the event content in the cross-shard event to obtain serialized data of the cross-shard event. This includes: each node in the first shard is used to perform importance identification processing on the event content in the cross-shard event to obtain a first importance corresponding to the event content in the cross-shard event; extracting key event content from the event content in the cross-shard event based on the first importance; and performing serialization processing on the key event content to obtain serialized data of the cross-shard event.

[0151] The first importance is used to characterize the importance of the event content across fragmented events.

[0152] Among them, key event content refers to event content with a first importance greater than the first preset importance, such as shard ID, contract name, contract method, and input parameters.

[0153] The serialized data for cross-shard events includes the key event content within the cross-shard events.

[0154] For example, after obtaining a cross-shard event, each node in the first shard inputs the event content of the cross-shard event into an importance recognition model (such as a convolutional neural network model or a deep learning model). The importance recognition model performs importance recognition processing on the event content of the cross-shard event to obtain the first importance corresponding to the event content of the cross-shard event. Then, event content with a first importance greater than a first preset importance is extracted from the event content of the cross-shard event as key event content. The key event content is then serialized according to serialization instructions to obtain the serialized data of the cross-shard event. Next, a hash algorithm is used to calculate the digest value of the serialized data of the cross-shard event, and the digest value is then encrypted using the corresponding private key to obtain the corresponding first signature information, thereby obtaining the first signature information of each node in the first shard for the cross-shard event. Then, consensus processing is performed on the cross-shard event. If the consensus on the cross-shard event is passed, the first signature information of each node in the first shard for the cross-shard event is summarized to obtain the first signature information set corresponding to the cross-shard event.

[0155] For example, the process for processing cross-shard master transactions is as follows:

[0156] 1. Main Transaction Execution and Event Extraction: After the main shard node executes the cross-shard main transaction, it iterates through the state change logs generated by the transaction execution to identify all cross-shard events (using predefined event identifiers or log structure fields). For example, refer to... Figure 8The specific process is as follows: S801, after all transactions in the block have been executed, initialize i=0, the transaction set txs, and the signature set signs; S802, obtain transaction tx=txs[i], that is, obtain the i-th transaction; S803, obtain the event set events in transaction tx; S804, determine whether tx.ID (i.e., the identifier of the i-th transaction) is the main shard transaction ID (e.g., determine whether it meets the cross-shard processing request identifier format); S805, if yes, then determine whether events contains a cross-shard topic (e.g., determine whether it is a cross-shard event type); S806, if yes, then determine whether the event content of the corresponding topic is valid; S807, if yes, then split the event content, sign each segment of the split content, and save the signed content to signs. Here, len(txs) refers to the total number of transactions in the transaction set txs.

[0157] 2. Event Signing: Serialize the content (including event type, parameters, target shard ID, etc.) of each cross-shard event, and generate a digital signature for the serialized data using the node's private key. The signature algorithm can be a commonly used blockchain algorithm such as ECDSA or EdDSA. The format of cross-shard events can be found in [reference needed]. Figure 9 S901 represents the event content of a cross-shard event, such as shard ID, contract name, contract method, and input parameters. For the first signature information of a cross-shard event, please refer to [reference needed]. Figure 10 S1001 represents the serialized data of the cross-shard event, and S1002 represents the corresponding first signature information.

[0158] 3. Signature broadcast with consensus vote: Nodes attach their signatures to the voting message for the transaction block and participate in the consensus process; when the block proposal reaches consensus, the vote and signature information are written to the node's local storage (but do not participate in the block hash calculation to avoid affecting the block's determinism).

[0159] 4. Sharding SDK obtains signatures: The sharding SDK obtains cross-shard event data containing signatures from multiple nodes by querying the node status or event log interface of the main shard chain; in this way, the events held by the sharding SDK are accompanied by trusted endorsements from multiple nodes.

[0160] In this embodiment, the importance of event content in cross-shard events is identified to obtain the first importance of the event content in the cross-shard event. Then, key event content is extracted from the event content in the cross-shard event based on the first importance. Finally, the key event content is serialized to obtain the serialized data of the cross-shard event. In this way, by filtering event content based on the first importance, only key event content is retained and irrelevant event content is discarded, which helps to reduce the amount of serialized data of the cross-shard event, thereby improving the efficiency of subsequent generation of first signature information and the accuracy of verification of first signature information.

[0161] In an exemplary embodiment, sending the cross-shard event and the first signature information set to the requesting end specifically includes the following: in the event of an anomaly at the requesting end, identifying normal requesting ends other than the requesting end from the requesting end cluster to which the requesting end belongs; sending the cross-shard event and the first signature information set to the normal requesting end; or, sending the cross-shard event and the first signature information set to the load balancing server, so that the load balancing server sends the cross-shard event and the first signature information set to the target requesting end in the requesting end cluster.

[0162] An anomaly on the request end can refer to a server crash or attack, indicating that the request end is unable to handle cross-shard events, causing service interruption. A request end cluster includes multiple request ends, and any one of them can process a cross-shard event upon receiving it. A normal request end refers to a request end that functions correctly.

[0163] Here, a load balancer server refers to a server with load balancing capabilities. The target request end refers to the request end with the lowest load in the request end cluster.

[0164] For example, if a node in the first shard encounters an anomaly at the current requesting end, it determines candidate requesting ends other than the current requesting end from the requesting end cluster to which the current requesting end belongs. Then, it determines any one of the candidate requesting ends that is functioning normally as the determined normal requesting end and sends the cross-shard event and the first signature information set to the normal requesting end.

[0165] For example, nodes in the first shard send the cross-shard event and the first signature information set to the load balancer. After receiving the cross-shard event and the first signature information set, the load balancer determines the requesting end with the lowest load from the requesting end cluster as the target requesting end, or determines candidate requesting ends with a load lower than a preset load from the requesting end cluster, and randomly selects one requesting end from the candidate requesting ends as the target requesting end, and finally sends the cross-shard event and the first signature information set to the target requesting end in the requesting end cluster.

[0166] For example, the distributed deployment proposed in this application includes the following: 1. Multi-instance deployment: The sharding SDK is deployed on multiple physical or virtual nodes to form a cluster; it can be broadcast to all instances through load balancing or event subscription. 2. Event processing contention and redundancy: Any instance can process an event, but because the signature verification mechanism is executed on-chain, even if multiple instances send transactions simultaneously, only those that meet the endorsement conditions will be accepted, avoiding double-spending. 3. Failure tolerance: If an instance fails to process a certain event (due to downtime or attack), other instances can still process it normally and complete the cross-sharding process, ensuring business continuity.

[0167] In this embodiment, when an anomaly occurs at the requesting end, normal requesting ends other than the requesting end are identified from the requesting end cluster to which the requesting end belongs. The cross-shard event and the first signature information set are then sent to the normal requesting ends. This achieves automatic fault tolerance or alternative execution when an anomaly occurs at the requesting end, avoiding the defect of request not being processed and causing request stagnation, thereby ensuring business continuity and improving availability. Furthermore, sending the cross-shard event and the first signature information set to the load balancer server enables the load balancer server to forward the cross-shard event and the first signature information set to the target requesting ends in the requesting end cluster, achieving load balancing and preventing the defect of a single requesting end receiving a large number of cross-shard events, leading to cross-shard event processing failure.

[0168] In an exemplary embodiment, the requesting end is further configured to receive a second signature information set corresponding to the request operation result returned by the second shard, generate cross-shard submission information based on the request operation result and the second signature information set, and send the cross-shard submission information to the first shard; the second signature information set includes the second signature information of each node in the second shard for the request operation result.

[0169] Step S204 above, based on the request calculation result returned by the requesting end, obtains the target processing result of the cross-shard processing request, specifically including the following: using the request calculation result to verify the second signature information set, obtaining the second verification result of the cross-shard submission information; based on the second verification result, obtaining the target processing result of the cross-shard processing request.

[0170] The second signature information refers to the digital signature information of the node in the second shard for the requested computation result. This involves calculating the digest value (such as a hash value) of the requested computation result or its serialized data, and then using the private key of the node in the second shard to encrypt the digest value of the requested computation result or its serialized data to obtain the corresponding second signature information. It should be noted that each node in the second shard signs the requested computation result using its corresponding private key to obtain the corresponding second signature information. Furthermore, the signature algorithm used for the requested computation result can be any signature algorithm used in blockchain technology, such as ECDSA or EdDSA.

[0171] The second signature information set includes the second signature information of each node in the second slice for the requested computation result; for example, refer to Figure 11 The second signature information set S1101 includes the second signature information of node 21 on the request operation result, the second signature information of node 22 on the request operation result, the second signature information of node 23 on the request operation result, ... the second signature information of node 2m on the request operation result.

[0172] The cross-shard submission information includes the request computation result and the second signature information set, specifically referring to cross-shard submission transactions.

[0173] The second verification result is used to indicate whether the cross-shard submission information passes or fails verification.

[0174] For example, after obtaining the requested computation result, each node in the second shard is used to serialize the result content in the requested computation result according to the serialization instruction, obtaining serialized data of the requested computation result. The node then uses its corresponding private key to sign the serialized data of the requested computation result, obtaining the corresponding second signature information. For example, a hash algorithm is used to calculate the digest value of the serialized data of the requested computation result, and then the digest value is encrypted using the corresponding private key to obtain the corresponding second signature information. Next, consensus processing is performed on the requested computation result. If consensus on the requested computation result is passed, the second signature information of the requested computation result from each node in the second shard is summarized to obtain the second signature information set corresponding to the requested computation result, and the second signature information set is sent to the requesting end. The requesting end generates cross-shard submission information based on the requested computation result and the second signature information set, according to the cross-shard submission information format, and sends the cross-shard submission information to the first shard. After receiving the cross-shard submission information, the first shard uses the public key corresponding to the node identifier of the second signature information in the second signature information set, as well as the request operation result, to verify the second signature information and obtain the verification result. For example, it uses the public key corresponding to the node identifier of the second signature information to decrypt the second signature information to obtain the original digest value, and calculates the digest value corresponding to the serialized data of the request operation result. It compares the original digest value with the digest value corresponding to the serialized data of the request operation result. If they are the same, the second signature information is confirmed to be correct; if they are different, the second signature information is confirmed to be incorrect. Next, based on the verification results of each second signature information, the total number of correct second signature information is determined as the second correct signature count, and based on the second correct signature count, the second verification result of the cross-shard submission information is obtained. Finally, based on the second verification result, the target processing result of the cross-shard processing request is obtained. For example, if the second verification result indicates that the cross-shard submission information verification is successful, based on the request operation result and other request operation results obtained after the first shard executes the cross-shard processing request, the cross-shard processing request is confirmed to be successfully processed, and a success message is returned to the requesting end, and the request operation result is written to the corresponding block.

[0175] In this embodiment, the second signature information set is verified using the request calculation result to obtain the second verification result of the cross-shard submission information. Based on the second verification result, the target processing result of the cross-shard processing request is obtained, thus realizing the purpose of re-verifying the cross-shard processing and further improving the security of cross-shard processing.

[0176] In an exemplary embodiment, the requesting end is further configured to generate a corresponding cross-shard submission information identifier based on the request operation result, and generate cross-shard submission information according to the cross-shard submission information format, based on the request operation result, the second signature information set and the cross-shard submission information identifier.

[0177] like Figure 12 As shown, the second signature information set is verified using the request calculation result to obtain the second verification result of the cross-shard submission information, including the following steps S1201 to S1204. Wherein:

[0178] Step S1201: If the cross-shard submission information identifier meets the cross-shard submission information identifier format, obtain the target parameters in the cross-shard submission information; the target parameters include the request calculation result and the second signature information set.

[0179] Step S1202: If the target parameters meet the preset parameter format, the public key corresponding to the node identifier of the second signature information in the second signature information set and the request operation result are used to verify the second signature information to obtain the verification result of the second signature information; the verification result of the second signature information is used to characterize whether the second signature information is correct.

[0180] Step S1203: Determine the number of second correct signatures based on the verification results of each second signature information.

[0181] Step S1204: Based on the second number of correct signatures, obtain the second verification result of the cross-shard submission information.

[0182] Among them, the cross-shard commit information identifier refers to the identifier corresponding to the cross-shard commit information.

[0183] Among them, the cross-shard submission information format refers to the information format for submitting information across shards.

[0184] The cross-fragment submission information identifier format is used to indicate that the cross-fragment submission information identifier has a specific identifier prefix or identifier bit, such as 123, ABC, etc.

[0185] The target parameter in the cross-shard submission message refers to the first input parameter in the cross-shard submission message, which specifically includes the request operation result and the second signature information set.

[0186] Among them, the preset parameter format refers to the parameter format that is set in advance, such as the subResults format.

[0187] The verification result of the second signature information is used to indicate whether the second signature information is correct or incorrect.

[0188] The second correct signature count refers to the total number of correct second signature information in the second signature information set.

[0189] The second verification result of the cross-shard submission information is used to indicate whether the cross-shard submission information verification passes or fails. For example, if the number of second correct signatures is greater than or equal to the second number (i.e., the number of associated nodes in the second shard), the cross-shard submission information verification is confirmed to have passed; if the number of second correct signatures is less than the second number, the cross-shard submission information verification is confirmed to have failed.

[0190] For example, the requesting end generates a corresponding cross-shard submission information identifier based on the request operation result. Following the cross-shard submission information format, it generates cross-shard submission information based on the request operation result, the second signature information set, and the cross-shard submission information identifier, and sends the cross-shard submission information to the first shard. Upon receiving the cross-shard submission information, the first shard determines whether the cross-shard submission information identifier in the cross-shard submission information meets the cross-shard submission information identifier format. If so, it obtains the target parameter from the cross-shard submission information; the target parameter includes the request operation result and the second signature information set. Next, it determines whether the target parameter meets the preset parameter format. If so, it uses the public key corresponding to the node identifier of the second signature information in the second signature information set, along with the request operation result, to verify the second signature information and obtain the verification result. For example, it uses the public key corresponding to the node identifier of the second signature information to decrypt the second signature information, obtains the original digest value, and uses a hash algorithm to calculate the request operation result. The digest value corresponding to the serialized data of the result is compared with the digest value corresponding to the serialized data of the requested operation result. If they are the same, the second signature information is confirmed to be correct; if they are different, the second signature information is confirmed to be incorrect. Next, based on the verification results of each second signature information, the total number of correct second signature information is determined as the second correct signature count. Finally, based on the second correct signature count, the second verification result of the cross-shard submission information is obtained. For example, if the second correct signature count is greater than or equal to the second count (i.e., the number of associated nodes in the second shard), the cross-shard submission information verification is confirmed to be successful; if the second correct signature count is less than the second count, the cross-shard submission information verification is confirmed to be unsuccessful.

[0191] In this embodiment, when obtaining the second verification result of cross-shard submission information, the cross-shard submission information identifier, target parameters, and the number of second correct signatures are comprehensively considered, making the obtained second verification result more accurate, thereby improving the determination accuracy of the second verification result, and thus improving the verification accuracy of cross-shard submission information, which is conducive to further improving the security of cross-shard processing.

[0192] In an exemplary embodiment, the second signature information includes multiple sub-signature information obtained by using the private key corresponding to the node identifier of the second signature information to sign multiple different first digest values ​​of the request operation result.

[0193] Step S1202 above, using the public key corresponding to the node identifier of the second signature information in the second signature information set, and the request operation result, verifies the second signature information to obtain the verification result of the second signature information. Specifically, it includes the following: using the public key corresponding to the node identifier of the second signature information, designing multiple sub-signature information in the second signature information to obtain multiple first digest values ​​of the request operation result; obtaining multiple second digest values ​​of the request operation result; and obtaining the verification result of the second signature information based on the comparison results between the multiple first digest values ​​and the multiple second digest values ​​of the request operation result.

[0194] The multiple different first digest values ​​of the requested operation result can refer to multiple different hash values ​​of the requested operation result, which are obtained by hashing the requested operation result using different hash algorithms.

[0195] The second signature information includes multiple sub-signature information obtained by signing multiple different first digest values ​​of the request operation result using the corresponding private key, such as sub-signature information 1, sub-signature information 2, and sub-signature information 3.

[0196] Among them, the multiple first digest values ​​of the requested operation result refer to the multiple original digest values ​​of the requested operation result, specifically the multiple original hash values ​​of the requested operation result.

[0197] Among them, the multiple second digest values ​​of the request operation result refer to the multiple different digest values ​​calculated for the current request operation result, specifically the multiple different hash values ​​calculated for the current request operation result.

[0198] For example, after obtaining the requested computation result, each node in the second shard is used to serialize the result content in the requested computation result according to the serialization instruction, to obtain the serialized data of the requested computation result, and to process the serialized data of the requested computation result using different hash algorithms (such as SHA-256, SHA-3, SM3) to obtain different digest values ​​(such as different hash values) of the serialized data of the requested computation result, and to encrypt the different digest values ​​using the corresponding private key to obtain the corresponding different sub-signature information, such as sub-signature information 1, sub-signature information 2, and sub-signature information 3; then, The corresponding different sub-signature information is summarized to obtain the corresponding second signature information, that is, each second signature information includes the corresponding different sub-signature information; following this method, the second signature information of each node in the second shard for the requested operation result can be obtained. For example, the second signature information of node 21 for the requested operation result is (sub-signature information 1; sub-signature information 2; sub-signature information 3), the second signature information of node 22 for the requested operation result is (sub-signature information 4; sub-signature information 5; sub-signature information 6), and the second signature information of node 23 for the requested operation result is (sub-signature information 7; sub-signature information 8; sub-signature information 9).

[0199] Next, the second segment uses the public key corresponding to the node identifier of the second signature information to design (e.g., decrypt) multiple sub-signature information in the second signature information, obtaining multiple first digest values ​​of the requested operation result; and uses different hash algorithms to process the serialized data of the requested operation result, obtaining different digest values ​​(e.g., different hash values) of the serialized data of the requested operation result, which serve as multiple second digest values ​​of the requested operation result; finally, the multiple first digest values ​​and multiple second digest values ​​of the requested operation result are compared. If each first digest value of the requested operation result is the same as its corresponding second digest value, the second signature information is confirmed to be correct; otherwise, the second signature information is confirmed to be incorrect.

[0200] In this embodiment, the public key corresponding to the node identifier of the second signature information is first used to design multiple sub-signature information in the second signature information to obtain multiple first digest values ​​of the requested operation result. Then, multiple second digest values ​​of the requested operation result are obtained. Finally, based on the comparison results between the multiple first digest values ​​and the multiple second digest values ​​of the requested operation result, the verification result of the second signature information is obtained. In this way, by comprehensively considering the comparison results between the multiple first digest values ​​and the multiple second digest values ​​of the requested operation result, the verification accuracy of the second signature information can be improved.

[0201] In an exemplary embodiment, step S1204, based on the second number of correct signatures, obtains a second verification result for the cross-shard submission information, specifically including the following: if the second number of correct signatures is greater than or equal to the second number, the cross-shard submission information verification is confirmed to be successful; the second number is used to characterize the number of associated nodes in the second shard; if the second number of correct signatures is less than the second number, the cross-shard submission information verification is confirmed to be unsuccessful.

[0202] The above step S1201, after obtaining the target parameter in the cross-shard submission information, also includes the following: if the target parameter does not meet the preset parameter format, confirm that the cross-shard submission information verification fails.

[0203] The second quantity refers to the associated quantity of nodes in the second shard, specifically a portion of the total number of nodes in the second shard, such as 2 / 3 of the total number of nodes in the second shard. For example, if the second shard has 6 nodes, then the second quantity is 4.

[0204] For example, the first shard obtains the number of associated nodes of the second shard as the second quantity, and compares the second number of correct signatures with the second quantity. If the second number of correct signatures is greater than or equal to the second quantity, the cross-shard submission information verification is confirmed to be successful; if the second number of correct signatures is less than the second quantity, the cross-shard submission information verification is confirmed to be unsuccessful. Furthermore, after obtaining the target parameter in the cross-shard submission information, if the first shard identifies that the target parameter does not meet the preset parameter format, the cross-shard submission information verification is confirmed to be unsuccessful.

[0205] For example, the process of submitting and processing a transaction on the main shard chain is as follows:

[0206] 1. Transaction Construction: The sharding SDK uses the collected signature results and execution results as the first input parameter of the transaction (which can be designed as a structured object or hash reference), and sets the transaction as a cross-shard submission transaction type (identified by TxID). The format of a cross-shard submission transaction can be found in [reference needed]. Figure 13 S1301 (i.e., subResults) represents the first input parameter of the cross-shard transaction submission, otherParams represents other parameters; shardTxResult represents the request operation result, and Signature1 represents the second signature information corresponding to node 1 in shard 1.

[0207] 2. Transaction Submission Identification: After receiving a transaction, the main shard chain node identifies it as a cross-shard submission transaction through TxID.

[0208] 3. Input Parameter Parsing and Signature Verification: Parse the first input parameter, reconstruct the execution result and node signature list, and verify the signature using the corresponding node's public key to ensure the result has not been tampered with and originates from a trusted node. For example, refer to... Figure 14 The specific process is as follows: S1401, obtain the transaction ID (identifier), contract name, and input parameter information; S1402, determine whether it is a cross-shard submission transaction based on the TXID (e.g., determine whether it meets the cross-shard submission transaction identifier format). If not, proceed to step S1410; if yes, proceed to step S1403; S1403, obtain the first input parameter of the transaction; S1404, determine whether this input parameter meets the subResults format. If not, proceed to step S1405; if yes, proceed to step S1406; S1405, the format is invalid, discard the transaction, and return an error. S1406: Parse the first input parameter `subResults` to obtain the processing result for each shard; S1407: Restore the signature result based on `txResult` (requested computation result), `TxID` (e.g., cross-shard submission transaction ID), and sequence number; S1408: Determine if the signatures in the `txResult` endorsement are sufficient and correct. If not, proceed to step S1409; if yes, proceed to step S1410; S1409: If the number of endorsements in a cross-shard transaction is insufficient, discard the transaction and return an error; S1410: Process the judgment logic for other transactions (i.e., normal processing). It should be noted that `f` equals the floor value of [(total number of shard nodes - 1) / 3], where the total number of shard nodes refers to the total number of nodes in the corresponding shard (e.g., the second shard).

[0209] 4. Trustworthiness condition judgment: Similarly, a signature validity threshold is set. If the condition is met, the global state of the primary shard is allowed to be updated and the transaction is committed; otherwise, it is discarded.

[0210] In this embodiment, the second verification result of the cross-shard submission information is obtained based on the second number of correct signatures. In this way, when obtaining the second verification result of the cross-shard submission information, the second number of correct signatures is taken into account, which helps to improve the verification accuracy of the cross-shard submission information and further improves the security of cross-shard processing.

[0211] In an exemplary embodiment, based on the second verification result, the target processing result of the cross-shard processing request is obtained, specifically including the following: if the second verification result indicates that the cross-shard submission information verification is successful, based on the request calculation result and other request calculation results obtained after the first shard executes the cross-shard processing request, if the cross-shard processing request is confirmed to be successfully processed, a success message is returned to the requesting end, and the request calculation result is written to the corresponding block; if the second verification result indicates that the cross-shard submission information verification is unsuccessful, if the cross-shard processing request is confirmed to be unsuccessful, the cross-shard submission information is deleted, and an error message is returned to the requesting end.

[0212] Among them, other request operation results refer to the request operation results obtained after the first shard executes the main events in the cross-shard processing request, such as the account A balance should be reduced by M yuan, or the account A balance should be reduced by 2N yuan.

[0213] Successful cross-shard processing can refer to the successful processing of a request corresponding to a cross-shard business function, such as a successful cross-shard resource transfer request. Conversely, failure to process a cross-shard processing request can refer to the failure of a request corresponding to a cross-shard business function, such as a failed cross-shard resource transfer request.

[0214] Successful information can refer to successful request processing information for cross-shard services, specifically successful cross-shard resource transfer request processing information, such as a resource transfer success notification message. Failure information can refer to failed request processing information for cross-shard services, specifically failed cross-shard resource transfer request processing information, such as a resource transfer failure notification message.

[0215] Writing the request calculation result to the corresponding block means notifying the second shard to upload the request calculation result to the blockchain, thereby updating the account status, such as increasing the balance of account B by M yuan.

[0216] For example, if the second verification result indicates that the cross-shard submission information verification passed, a node in the first shard obtains the other request operation results obtained after the first shard executed the cross-shard processing request. Based on the request operation results and other request operation results, it determines whether the cross-shard processing request was successfully processed (e.g., whether the decrease in account A is equal to the increase in account B). If not, it deletes the cross-shard submission information and returns an error message to the requesting end, which then returns the error message to the corresponding terminal. If yes, it returns a success message to the requesting end, which then returns the error message to the corresponding terminal. It also writes the other request operation results into the corresponding block to update the corresponding account status, such as decreasing account A's balance by M yuan, and notifies the second shard to write the request operation results into the corresponding block to update the corresponding account status, such as increasing account B's balance by M yuan. If the second verification result indicates that the cross-shard submission information verification failed, it confirms that the cross-shard processing request failed, deletes the cross-shard submission information, and returns an error message to the requesting end, which then returns the error message to the corresponding terminal.

[0217] In this embodiment, by verifying the cross-shard submission information and executing the corresponding target processing result based on the second verification result of the cross-shard submission information, the obtained target processing result can be more accurate, further improving the security of cross-shard processing.

[0218] In an exemplary embodiment, a cross-shard processing request is a cross-shard resource transfer request; a cross-shard event is a cross-shard resource transfer event.

[0219] Step S203 above, sending the cross-shard event and the first signature information set to the requesting end, specifically includes the following: sending the cross-shard resource transfer event and the first signature information set to the requesting end, causing the requesting end to generate an associated cross-shard resource transfer request based on the cross-shard resource transfer event and the first signature information set, and sending the associated cross-shard resource transfer request to the second shard; the second shard is used to verify the first signature information set using the cross-shard resource transfer event, obtain the first verification result of the associated cross-shard resource transfer request, execute the associated cross-shard resource transfer request based on the first verification result, and return the resource transfer request calculation result corresponding to the associated cross-shard resource transfer request to the requesting end.

[0220] Step S204 above, based on the request calculation result returned by the requesting end, obtains the target processing result of the cross-shard processing request, specifically including the following: based on the resource transfer request calculation result and the other resource transfer request calculation results obtained after the first shard executes the cross-shard resource transfer request, determine the target processing result of the cross-shard resource transfer request; the target processing result is used to characterize whether the cross-shard resource transfer request is successfully processed.

[0221] Among them, cross-shard resource transfer request refers to a request to transfer resources across shards, specifically a cross-shard transfer request, such as a request for account A to transfer M yuan to account B.

[0222] Among them, cross-shard resource transfer events refer to events in which resources are transferred across shards, specifically cross-shard transfer events, such as the event where account A transfers M yuan to account B.

[0223] Among them, a cross-shard resource transfer request refers to a resource transfer request that needs to be executed by other shards, such as a request to increase the balance of account B by M yuan.

[0224] Among them, the resource transfer request operation result refers to the request operation result corresponding to the cross-shard resource transfer request, such as the account B balance should increase by M yuan. Other resource transfer request operation results refer to the request operation result obtained after the first shard executes the main event in the cross-shard resource transfer request, such as the account A balance should decrease by M yuan.

[0225] The target processing result of a cross-shard resource transfer request refers to whether the cross-shard resource transfer request is processed successfully or fails, such as a cross-shard transfer request being processed successfully or failing.

[0226] For example, in a cross-shard resource transfer scenario, such as a cross-shard transfer scenario, the terminal obtains a cross-shard resource transfer request, such as a request for account A to transfer M yuan to account B, and sends the cross-shard resource transfer request to the requesting end (including the sharding SDK). The requesting end calls the sharding contract, determines that the shard corresponding to the cross-shard resource transfer request is the first shard, and then sends the cross-shard resource transfer request to the first shard. Next, the nodes in the first shard execute the cross-shard resource transfer request, obtain the state change log corresponding to the cross-shard resource transfer request, and generate a cross-shard resource transfer event corresponding to the cross-shard resource transfer request based on the state change log, such as an event that the balance of account B increases by M yuan. After receiving a cross-shard resource transfer event, each node in the first shard serializes the event content to obtain serialized data. They then use their respective private keys to sign this serialized data, obtaining the corresponding first signature information. For example, they might use a hash algorithm to calculate a digest of the serialized data and encrypt it using their private keys to obtain the first signature information. Next, consensus is reached on the cross-shard resource transfer event. If consensus is reached, a first signature information set corresponding to the cross-shard resource transfer event is obtained based on the first signature information from each node in the first shard. Finally, the nodes in the first shard send the cross-shard resource transfer event and the first signature information set to the requesting node. The requesting end generates a corresponding associated cross-shard resource transfer request identifier based on the cross-shard resource transfer event. According to the associated cross-shard resource transfer request format, it generates an associated cross-shard resource transfer request based on the cross-shard resource transfer event, the first signature information set, and the associated cross-shard resource transfer request identifier, and sends the associated cross-shard resource transfer request to the corresponding second shard in the blockchain network.After receiving the associated cross-shard resource transfer request, the second shard determines whether the associated cross-shard resource transfer request identifier in the request conforms to the associated cross-shard resource transfer request identifier format. If so, it uses the public key corresponding to the node identifier of the first signature information in the first signature information set, along with the cross-shard resource transfer event, to verify the first signature information and obtain the verification result. For example, it uses the public key corresponding to the node identifier of the first signature information to decrypt the first signature information, obtains the original digest value, and calculates the digest value corresponding to the serialized data of the cross-shard resource transfer event. It compares the original digest value with the digest value corresponding to the serialized data of the cross-shard event. If they are the same, the first signature information is confirmed to be correct; otherwise, the first signature information is confirmed to be incorrect. Then, based on each... The verification result of the first signature information determines the total number of correct first signatures, which is taken as the first correct signature count. Based on the first correct signature count, the first verification result of the associated cross-shard resource transfer request is obtained. For example, if the first correct signature count is greater than or equal to the first count (i.e., the associated number of nodes in the first shard), the associated cross-shard resource transfer request is confirmed to have passed verification; if the first correct signature count is less than the first count, the associated cross-shard resource transfer request is confirmed to have failed verification. Then, if the first verification result indicates that the associated cross-shard resource transfer request has passed verification, the associated cross-shard resource transfer request is executed, and the resource transfer request calculation result corresponding to the associated cross-shard resource transfer request is obtained, such as the calculation result of increasing the balance of account B by M yuan. The resource transfer request calculation result is returned to the requesting end. The requesting end sends the resource transfer request calculation result to the first shard.

[0227] The requesting end also receives the second signature information set corresponding to the resource transfer request calculation result returned by the second shard. The second signature information set includes the second signature information of each node in the second shard for the resource transfer request calculation result. For example, after obtaining the resource transfer request calculation result, each node in the second shard serializes the result content in the resource transfer request calculation result to obtain serialized data of the resource transfer request calculation result, and signs the serialized data of the resource transfer request calculation result using the corresponding private key to obtain the corresponding second signature information. For example, a hash algorithm is used to calculate the digest value of the serialized data of the resource transfer request calculation result, and then the digest value is encrypted using the corresponding private key to obtain the corresponding second signature information. Next, consensus processing is performed on the resource transfer request calculation result. If the consensus on the resource transfer request calculation result is passed, the second signature information set corresponding to the resource transfer request calculation result is obtained based on the second signature information of each node in the second shard for the resource transfer request calculation result, and the second signature information set is sent to the requesting end.

[0228] Next, the requesting end generates a corresponding cross-shard resource transfer submission information identifier based on the resource transfer request calculation result. According to the cross-shard resource transfer submission information format, based on the resource transfer request calculation result, the second signature information set, and the cross-shard resource transfer submission information identifier, it generates cross-shard resource transfer submission information and sends the cross-shard resource transfer submission information to the first shard.After receiving the cross-shard resource transfer commit message, the first shard determines whether the cross-shard resource transfer commit message identifier in the message conforms to the cross-shard resource transfer commit message identifier format. If so, it obtains the target parameters from the message. The target parameters include the resource transfer request calculation result and the second signature information set. Next, it determines whether the target parameters conform to the preset parameter format. If so, it uses the public key corresponding to the node identifier of the second signature information in the second signature information set, along with the request calculation result, to verify the second signature information and obtain the verification result. For example, it can use the public key corresponding to the node identifier of the second signature information to decrypt the second signature information. Obtain the original digest value and calculate the digest value corresponding to the serialized data of the resource transfer request operation result. Compare the original digest value with the digest value corresponding to the serialized data of the resource transfer request operation result. If they are the same, the second signature information is confirmed to be correct; if they are different, the second signature information is confirmed to be incorrect. Next, based on the verification results of each second signature information, determine the total number of correct second signature information as the second correct signature count, and based on the second correct signature count, obtain the second verification result of the cross-shard resource transfer submission information. For example, if the second correct signature count is greater than or equal to the second count (i.e., the number of associated nodes in the second shard), the cross-shard resource transfer submission information verification is confirmed to be successful; if the second... If the number of correct signatures is less than the second number, the cross-shard resource transfer submission information verification fails. Finally, if the second verification result indicates that the cross-shard resource transfer submission information verification passed, then based on the resource transfer request calculation result and the other resource transfer request calculation results obtained after the first shard executes the cross-shard resource transfer request (such as the calculation result of account A's balance decreasing by M yuan), it is determined whether the cross-shard resource transfer processing request was successfully processed (such as determining whether the decrease in account A's balance is equal to the increase in account B's balance). If not, it indicates that the cross-shard transfer request processing failed, and the cross-shard resource transfer submission information is deleted, and an error message is returned to the requesting end, which then returns the error message to the corresponding terminal. If yes, it indicates that the cross-shard transfer request processing failed. If a shard transfer request is successfully processed, a success message is returned to the requesting end. The requesting end then returns an error message to the corresponding terminal and writes the results of other resource transfer requests to the corresponding block, thus updating the corresponding account status (e.g., reducing account A's balance by M yuan). The second shard is also notified to write its resource transfer request results to the corresponding block, updating the corresponding account status (e.g., increasing account B's balance by M yuan). If the second verification result indicates that the cross-shard resource transfer submission information fails verification, the cross-shard processing request is confirmed to have failed, i.e., the cross-shard transfer request has failed. The cross-shard resource transfer submission information is deleted, and an error message is returned to the requesting end, which then returns the error message to the corresponding terminal.

[0229] For example, in a cross-shard account transaction processing scenario, such as a cross-shard account migration scenario, if an account is migrated from the first shard to the second shard, the source shard cancels the account status, and the target shard creates a new account ledger; the terminal obtains a cross-shard account transaction processing request and sends it to the requesting end (including the sharding SDK). The requesting end calls the sharding contract, determines that the shard corresponding to the cross-shard account transaction processing request is the first shard, and then sends the cross-shard account transaction processing request to the first shard. The first shard obtains the cross-shard account event corresponding to the cross-shard account transaction processing request sent by the requesting end; the cross-shard account event is used to characterize the event generated by the first shard after executing the cross-shard account transaction processing request; it obtains the first signature information set corresponding to the cross-shard account event; the first signature information set includes the first signature information of each node in the first shard for the cross-shard account event; and sends the cross-shard account event and the first signature information set to the requesting end. The requesting end generates a related cross-shard account transaction processing request based on cross-shard account events and a first signature information set, and sends the related cross-shard account transaction processing request to the corresponding second shard in the blockchain network. The second shard uses the cross-shard account events to verify the first signature information set, obtains a first verification result for the related cross-shard account transaction processing request, executes the related cross-shard account transaction processing request based on the first verification result, obtains the request operation result corresponding to the related cross-shard account transaction processing request, and returns the request operation result corresponding to the related cross-shard account transaction processing request to the requesting end. The requesting end sends the request operation result to the first shard. The nodes in the first shard obtain the target processing result of the cross-shard account transaction processing request based on the request operation result returned by the requesting end, such as the account successfully migrating from the first shard to the second shard (i.e., account migration successful); or the account failing to migrate from the first shard to the second shard (i.e., account migration failed).

[0230] In this embodiment, before executing the associated cross-shard resource transfer request, the second shard verifies the first signature information set using the cross-shard resource transfer event to obtain the first verification result of the associated cross-shard resource transfer request. This achieves the purpose of verifying the associated cross-shard resource transfer request before execution, and verifies multiple first signature information for the cross-shard resource transfer event. This helps to avoid the defect of low security in cross-shard resource transfer processing caused by the tampering of the associated cross-shard resource transfer request, thereby improving the security of cross-shard resource transfer processing.

[0231] In one exemplary embodiment, such as Figure 15 As shown, another request handling method is provided, which can be applied to... Figure 1 Taking a node in the second slice as an example, the explanation includes the following steps S1501 to S1503. Wherein:

[0232] Step S1501: Receive the cross-shard processing request sent by the requesting end.

[0233] The requesting end is used to receive cross-shard events sent by nodes in the first shard corresponding to the cross-shard processing request sent by the requesting end, as well as a first signature information set corresponding to the cross-shard events. It generates associated cross-shard processing requests based on the cross-shard events and the first signature information set. The cross-shard events are used to characterize events generated in the first shard after executing the cross-shard processing request. The first signature information set includes the first signature information of each node in the first shard for the cross-shard events.

[0234] Step S1502: Verify the first signature information set using the cross-shard event to obtain the first verification result associated with the cross-shard processing request.

[0235] Step S1503: Execute the associated cross-shard processing request based on the first verification result, and return the request calculation result corresponding to the associated cross-shard processing request to the requesting end, so that the requesting end sends the request calculation result to the first shard; the nodes in the first shard are used to obtain the target processing result of the cross-shard processing request based on the request calculation result.

[0236] For example, the terminal obtains a cross-shard processing request and sends it to the requesting end (which includes the sharding SDK). The requesting end invokes the sharding contract, determines that the shard corresponding to the cross-shard processing request is the first shard, and then sends the cross-shard processing request to the first shard. The first shard obtains the cross-shard event corresponding to the cross-shard processing request sent by the requesting end; the cross-shard event is used to characterize the event generated by the first shard after executing the cross-shard processing request; it obtains the first signature information set corresponding to the cross-shard event; the first signature information set includes the first signature information of each node in the first shard for the cross-shard event; and sends the cross-shard event and the first signature information set to the requesting end. The requesting end generates an associated cross-shard processing request based on the cross-shard event and the first signature information set, and sends the associated cross-shard processing request to the corresponding second shard in the blockchain network. The second shard uses cross-shard events to verify the first signature information set, obtaining a first verification result for the associated cross-shard processing request. Based on this first verification result, it executes the associated cross-shard processing request, obtains the corresponding request computation result, and returns it to the requesting end. The requesting end then sends the request computation result to the first shard. Nodes in the first shard obtain the target processing result for the cross-shard processing request based on the request computation result returned by the requesting end.

[0237] It should be noted that specific embodiments of the request processing method applied to nodes in the second shard can be found in the relevant embodiments of the request processing method applied to nodes in the first shard, and will not be repeated here.

[0238] In the above request processing method, when performing cross-shard processing, a first signature information set corresponding to the cross-shard event is obtained based on the first signature information of each node in the first shard for the cross-shard event. This achieves the purpose of multi-node signing of the cross-shard event, which is beneficial to improving the security of subsequent cross-shard processing. Moreover, an associated cross-shard processing request is generated based on the cross-shard event and the first signature information set, and the associated cross-shard processing request is sent to the corresponding second shard. This allows the second shard to verify the first signature information set using the cross-shard event before executing the associated cross-shard processing request, and obtain the first verification result of the associated cross-shard processing request. This achieves the purpose of verifying the associated cross-shard processing request before execution, and verifies multiple first signature information for the cross-shard event. This helps to avoid the defect of the associated cross-shard processing request being tampered with, resulting in low security of cross-shard processing, and further improves the security of cross-shard processing.

[0239] In an exemplary embodiment, the requesting end is further configured to generate a corresponding associated cross-shard processing request identifier based on the cross-shard event, and generate an associated cross-shard processing request according to the associated cross-shard processing request format, based on the cross-shard event, the first signature information set, and the associated cross-shard processing request identifier.

[0240] Step S1502 above, which verifies the first signature information set using cross-shard events to obtain a first verification result for the associated cross-shard processing request, specifically includes the following: If the associated cross-shard processing request identifier satisfies the associated cross-shard processing request identifier format, the first signature information is verified using the public key corresponding to the node identifier of the first signature information in the first signature information set, and the cross-shard events, to obtain a verification result for the first signature information; the verification result of the first signature information is used to characterize whether the first signature information is correct; based on the verification results of each first signature information, the first number of correct signatures is determined; based on the first number of correct signatures, the first verification result for the associated cross-shard processing request is obtained.

[0241] Among them, the associated cross-shard processing request identifier refers to the identifier corresponding to the associated cross-shard processing request.

[0242] Among them, the associated cross-shard processing request format refers to the request format of the associated cross-shard processing request.

[0243] The associated cross-shard processing request identifier format is used to indicate that the associated cross-shard processing request identifier has a specific identifier prefix or identifier bit, such as 123, ABC, etc.

[0244] The verification result of the first signature information is used to indicate whether the first signature information is correct or incorrect.

[0245] The first correct signature count refers to the total number of correct first signature information in the first signature information set.

[0246] The first verification result of the associated cross-shard processing request is used to indicate whether the associated cross-shard processing request verification is successful or unsuccessful.

[0247] For example, the requesting end generates a corresponding associated cross-shard processing request identifier based on the cross-shard event. Following the associated cross-shard processing request format, it generates an associated cross-shard processing request based on the cross-shard event, the first signature information set, and the associated cross-shard processing request identifier. For example, the format of a cross-shard transaction can be referenced. Figure 16 The associated cross-shard processing request is then sent to the second shard. Upon receiving the associated cross-shard processing request, the second shard determines whether the associated cross-shard processing request identifier in the request conforms to the associated cross-shard processing request identifier format. If so, it uses the public key corresponding to the node identifier of the first signature information in the first signature information set, along with the cross-shard event, to verify the first signature information and obtain the verification result. For example, it uses the public key corresponding to the node identifier of the first signature information to decrypt the first signature information, obtaining the original digest value, and then uses a hash algorithm to calculate the digest value corresponding to the serialized data of the cross-shard event. The original digest value is then compared with the serialized data of the cross-shard event. The digest values ​​corresponding to the data are compared. If they are the same, the first signature information is confirmed to be correct; if they are different, the first signature information is confirmed to be incorrect. Next, based on the verification results of each first signature information, the total number of correct first signature information is determined as the first correct signature count. Finally, based on the first correct signature count, the first verification result of the associated cross-shard processing request is obtained. For example, if the first correct signature count is greater than or equal to the first count (i.e., the number of associated nodes in the first shard), the associated cross-shard processing request is confirmed to have passed verification; if the first correct signature count is less than the first count, the associated cross-shard processing request is confirmed to have failed verification.

[0248] In this embodiment, when obtaining the first verification result of the associated cross-shard processing request, the associated cross-shard processing request identifier and the number of first correct signatures are comprehensively considered, making the obtained first verification result more accurate, thereby improving the determination accuracy of the first verification result, and thus improving the verification accuracy of the associated cross-shard processing request, which is conducive to further improving the security of cross-shard processing.

[0249] In an exemplary embodiment, a first verification result for the associated cross-shard processing request is obtained based on a first number of correct signatures, specifically including the following: if the first number of correct signatures is greater than or equal to a first number, the associated cross-shard processing request is confirmed to have passed verification; the first number is used to characterize the number of associated nodes in the first shard; if the first number of correct signatures is less than the first number, the associated cross-shard processing request is confirmed to have failed verification.

[0250] The first quantity refers to the number of associated nodes in the first shard, specifically a portion of the total number of nodes in the first shard, such as 2 / 3 of the total number of nodes in the first shard. For example, if the first shard has 9 nodes, then the second quantity is 6.

[0251] For example, the second shard obtains the number of associated nodes of the first shard as the first number, and compares the first number of correct signatures with the first number. If the first number of correct signatures is greater than or equal to the first number, the cross-shard processing request verification is confirmed to be successful; if the first number of correct signatures is less than the first number, the cross-shard processing request verification is confirmed to be unsuccessful.

[0252] In this embodiment, the first verification result of the associated cross-shard processing request is obtained based on the first number of correct signatures. In this way, when obtaining the first verification result of the associated cross-shard processing request, the first number of correct signatures is taken into account, which helps to improve the verification accuracy of the associated cross-shard processing request and further improves the security of cross-shard processing.

[0253] In an exemplary embodiment, step S1503 above, which executes the associated cross-shard processing request based on the first verification result, specifically includes the following: if the first verification result indicates that the associated cross-shard processing request has passed verification, the associated cross-shard processing request is executed to obtain the request operation result corresponding to the associated cross-shard processing request.

[0254] The request processing method provided in this application also includes the following: if the first verification result indicates that the cross-shard processing request verification fails, the cross-shard processing request is deleted and an error message is returned to the requesting end.

[0255] For example, if the first verification result indicates that the cross-shard processing request has passed verification, the node in the first shard executes the cross-shard processing request, obtains the request operation result corresponding to the cross-shard processing request, and returns the request operation result corresponding to the cross-shard processing request to the requesting end; if the first verification result indicates that the cross-shard processing request has failed verification, the node deletes the cross-shard processing request and returns error information (such as a cross-shard processing request failure reminder) to the requesting end, which then sends the error information to the corresponding terminal.

[0256] In this embodiment, if the first verification result indicates that the cross-shard processing request has passed the verification, then the cross-shard processing request is executed. This makes the obtained request calculation result more accurate and further improves the security of cross-shard processing.

[0257] In an exemplary embodiment, before returning the request operation result corresponding to the associated cross-shard processing request to the requesting end, step S1503 above further includes the following: obtaining the second signature information set corresponding to the request operation result; the second signature information set includes the second signature information of each node in the second shard for the request operation result.

[0258] Step S1503 above returns the request calculation result corresponding to the associated cross-shard processing request to the requesting end, specifically including the following: returning the request calculation result and the second signature information set to the requesting end, enabling the requesting end to generate cross-shard submission information based on the request calculation result and the second signature information set, and sending the cross-shard submission information to the first shard; the nodes in the first shard use the request calculation result to verify the second signature information set, obtain the second verification result of the cross-shard submission information, and obtain the target processing result of the cross-shard processing request based on the second verification result.

[0259] For example, after obtaining the requested computation result, each node in the second shard serializes the result content in the requested computation result to obtain serialized data of the requested computation result. They then use their corresponding private keys to sign the serialized data of the requested computation result, obtaining the corresponding second signature information. For instance, they use a hash algorithm to calculate the digest value of the serialized data of the requested computation result, and then use the corresponding private key to encrypt the digest value to obtain the corresponding second signature information. Next, they perform consensus processing on the requested computation result. If the consensus on the requested computation result is passed, based on the second signature information of the requested computation result from each node in the second shard, they obtain the second signature information set corresponding to the requested computation result and send the second signature information set to the requesting end. The requesting end generates a corresponding cross-shard submission information identifier based on the requested computation result. Following the cross-shard submission information format, based on the requested computation result, the second signature information set, and the cross-shard submission information identifier, it generates cross-shard submission information and sends the cross-shard submission information to the first shard. After receiving the cross-shard submission information, the first shard determines whether the cross-shard submission information identifier in the cross-shard submission information meets the cross-shard submission information identifier format. If so, it obtains the target parameters from the cross-shard submission information. The target parameters include the requested computation result and the second signature information set. Next, it determines whether the target parameters meet the preset parameter format. If so, it uses the public key corresponding to the node identifier of the second signature information in the second signature information set, as well as the requested computation result, to verify the second signature information and obtain the verification result of the second signature information. For example, it uses the public key corresponding to the node identifier of the second signature information to decrypt the second signature information to obtain the original digest value, and calculates the digest value corresponding to the serialized data of the requested computation result. It compares the original digest value with the digest value corresponding to the serialized data of the requested computation result. If they are the same, it confirms that the first shard... If the two signatures are correct, and they are not identical, then the second signature is considered incorrect. Next, based on the verification results of each second signature, the total number of correct second signatures is determined as the second correct signature count. Based on this second correct signature count, the second verification result of the cross-shard submission information is obtained. Finally, if the second verification result indicates that the cross-shard submission information verification passed, the cross-shard processing request is confirmed to have been successfully processed based on the request operation result and the other request operation results obtained after the first shard executed the cross-shard processing request. A success message is returned to the requesting end, the other request operation results are written to the corresponding blocks, and the second shard is notified to write its request operation result to the corresponding block. If the second verification result indicates that the cross-shard submission information verification failed, the cross-shard processing request is confirmed to have failed, the cross-shard submission information is deleted, and an error message is returned to the requesting end.

[0260] In this embodiment, the second signature information set is first verified using the request calculation result to obtain the second verification result of the cross-shard submission information. Then, based on the second verification result, the target processing result of the cross-shard processing request is obtained, thus realizing the purpose of re-verifying the cross-shard processing and further improving the security of cross-shard processing.

[0261] In an exemplary embodiment, obtaining the second signature information set corresponding to the requested computation result specifically includes the following: obtaining the second signature information of each node in the second shard for the requested computation result; each node in the second shard is used to serialize the result content in the requested computation result to obtain serialized data of the requested computation result, and to sign the serialized data of the requested computation result using the corresponding private key to obtain the corresponding second signature information; if the consensus on the requested computation result is passed, the second signature information set corresponding to the requested computation result is obtained based on the second signature information of each node for the requested computation result.

[0262] The request calculation result contains multiple result contents, such as output status, event identifier, execution timestamp, etc.

[0263] Serialization of the result content in the request operation result refers to sorting the result content in the request operation result according to a preset order.

[0264] The serialized data of the requested operation result refers to the structured data of the requested operation result, specifically the content of the result after the request operation result is arranged, such as (cross-shard transaction user; cross-shard ID; sequence number; transaction execution result).

[0265] For example, after obtaining the requested computation result, each node in the second shard serializes the result content in the requested computation result to obtain serialized data of the requested computation result. It then calculates a digest value (e.g., hash value) of the serialized data using a hash algorithm (e.g., SHA-256) and encrypts the digest value using its corresponding private key to obtain the corresponding second signature information. Next, each node in the second shard performs consensus processing on the requested computation result. For instance, each node in the second shard votes on the requested computation result to obtain corresponding voting information. This voting information is then aggregated, and the total number of votes in favor is counted. If the total number of votes is greater than a preset number, the consensus on the requested computation result is confirmed. Finally, if the consensus on the requested computation result is passed, the second signature information of the requested computation result from each node in the second shard is aggregated to obtain the second signature information set corresponding to the requested computation result.

[0266] For example, after obtaining the requested computation result, each node in the second shard is used to serialize the result content in the requested computation result according to the serialization instruction, to obtain the serialized data of the requested computation result. Different hash algorithms (such as SHA-256, SHA-3, SM3) are then used to process the serialized data of the requested computation result to obtain different digest values ​​(such as different hash values). The corresponding private keys are then used to encrypt the different digest values ​​to obtain corresponding different sub-signature information, such as sub-signature information 1, sub-signature information 2, and sub-signature information 3. Next, the corresponding different sub-signature information is summarized to obtain the corresponding second signature information, i.e., each second signature information includes the corresponding different sub-signature information. Referring to this method, the second signature information of each node in the second shard for the requested computation result can be obtained, such as node 21. The second signature information for the requested computation result is (sub-signature information 1; sub-signature information 2; sub-signature information 3), the second signature information for the requested computation result of node 22 is (sub-signature information 4; sub-signature information 5; sub-signature information 6), and the second signature information for the requested computation result of node 23 is (sub-signature information 7; sub-signature information 8; sub-signature information 9). Next, each node in the second shard performs consensus processing on the requested computation result. For example, each node in the first shard votes on cross-shard events to obtain corresponding voting information. These voting information are summarized, and the total number of votes in agreement is counted. If the total number of votes is greater than the preset number of votes, the consensus on the requested computation result is confirmed to be passed. Finally, if the consensus on the requested computation result is passed, the second signature information of each node in the second shard for the requested computation result is summarized to obtain the second signature information set corresponding to the requested computation result.

[0267] In this embodiment, the second signature information of each node in the second shard for the request operation result is obtained, and based on the second signature information of each node for the request operation result, the second signature information set corresponding to the request operation result is obtained. This facilitates the subsequent use of the request operation result to verify the second signature information set and obtain the second verification result of the cross-shard submission information. This achieves the purpose of re-verifying the cross-shard processing and is conducive to further improving the security of cross-shard processing.

[0268] In an exemplary embodiment, each node in the second slice is used to serialize the result content in the requested operation result to obtain serialized data of the requested operation result. Specifically, this includes the following: each node in the second slice is used to perform importance identification processing on the result content in the requested operation result to obtain the second importance corresponding to the result content in the requested operation result, extract key result content from the result content in the requested operation result based on the second importance, and serialize the key result content to obtain serialized data of the requested operation result.

[0269] The second importance is used to characterize the importance of the result content in the request operation result.

[0270] Among them, key result content refers to result content with a second importance greater than the second preset importance, such as transaction execution result and execution timestamp.

[0271] The serialized data of the requested operation result includes the key result content in the requested operation result.

[0272] For example, after obtaining the requested computation result, each node in the second shard is used to input the result content of the requested computation result into a pre-trained importance recognition model (such as a convolutional neural network model or a deep learning model). The pre-trained importance recognition model performs importance recognition processing on the result content of the requested computation result to obtain the second importance corresponding to the result content of the requested computation result. Then, the result content with a second importance greater than a second preset importance is extracted from the result content of the requested computation result as key result content. The key result content is serialized according to the serialization instruction to obtain the serialized data of the requested computation result. Then, a hash algorithm is used to calculate the digest value of the serialized data of the requested computation result, and the digest value is encrypted using the corresponding private key to obtain the corresponding second signature information, thereby obtaining the second signature information of each node in the second shard for the requested computation result. Next, consensus processing is performed on the requested computation result. If the consensus on the requested computation result is passed, the second signature information of each node in the second shard for the requested computation result is summarized to obtain the second signature information set corresponding to the requested computation result.

[0273] For example, the process for handling cross-shard transactions is as follows:

[0274] 1. Transaction Identification: When constructing cross-shard transactions, the sharding SDK sets a specific TxID prefix or identifier in the transaction structure so that the target shard chain can quickly identify it as a cross-shard transaction. The format of cross-shard transactions generated by the sharding SDK can be found in [reference needed]. Figure 16 S1601 indicates cross-fragment endorsement; cross-fragment endorsement can specifically refer to the first signature information set.

[0275] 2. Endorsement Information Embedding: The list of signatures of the primary shard nodes is written as the "endorsement" field of the transaction; this field contains information such as the node ID, signature value, and corresponding event content hash of each signature.

[0276] 3. Shard Chain Pre-Signature Verification Process: After receiving a transaction, a shard chain node first checks the TxID to determine the transaction type. If it is a cross-shard transaction, it parses the "endorsement" field to extract the event content and signature. It then verifies the signature one by one using the public key of the corresponding node to ensure the signature matches the event content. A threshold (e.g., ≥2 / 3 of the nodes' signatures are valid) is set as a trust condition; only transactions meeting this condition enter the execution queue, otherwise, they are discarded. For example, refer to... Figure 17 The specific process is as follows: S1701, obtain the transaction ID (identifier), contract name, endorsement, and input parameter information; S1702, determine whether it is a cross-shard transaction based on the TXID (i.e., transaction identifier) ​​(e.g., determine whether it meets the format of the associated cross-shard processing request identifier). If not, proceed to step S1703; if yes, proceed to step S1704; S1703, process the judgment logic for other transactions; S1704, restore the corresponding event content based on the transaction input parameters; S1705, determine whether the signature of the event content in the transaction endorsement is sufficient and correct. If yes, proceed to step S1703; if not, proceed to step S1706; S1706, if the number of endorsements in the cross-shard transaction is insufficient, discard the transaction and return an error. It should be noted that f is equal to the floor value of [(total number of shard nodes - 1) / 3], and the total number of shard nodes refers to the total number of nodes in the corresponding shard (e.g., the first shard).

[0277] 4. Anti-preemptive design: Since the signature information is generated by the main shard node and is publicly verifiable, even if a malicious SDK sends a forged transaction first, it will be rejected by the shard chain because it lacks a sufficiently valid signature.

[0278] 5. Result Signing: After a cross-shard transaction is executed on the target shard chain, the executing node serializes the execution result (including output status, event identifier, execution timestamp, etc.) and signs it using its private key. (Reference) Figure 18 The specific process for signing the result is as follows: S1801, all transactions in the block have been executed, initialize i=0, transaction set txs, signature set signs; S1802, obtain transaction tx=txs[i], that is, obtain the i-th transaction; S1803, determine whether tx.ID (i.e., the identifier of the i-th transaction) is a cross-shard transaction ID (identifier), if so, jump to step S1804; S1804, obtain the transaction execution result txResult; S1805, sign the execution result txResult, and save the signed content to signs. It should be noted that len(txs) represents the total number of transactions in the transaction set txs. For the second signature information of the request operation result (such as the execution result txResult), please refer to Figure 19 S1901 represents the serialized data requesting the operation result, and S1902 represents the corresponding second signature information.

[0279] 6. Signature Broadcast and SDK Collection: Similar to the main transaction signing process, the execution node broadcasts the signature along with the consensus vote, and the sharding SDK collects the signature results of all relevant nodes.

[0280] In this embodiment, the result content is filtered based on the second importance, retaining only the key result content and discarding irrelevant result content. This helps to reduce the amount of serialized data of the request calculation result, thereby improving the efficiency of subsequent second signature information generation and the accuracy of second signature information verification.

[0281] In one exemplary embodiment, such as Figure 20 As shown, another request handling method is provided, which can be applied to Figure 1 The nodes in the first slice are described, including the following steps S2001 to S2015. Wherein:

[0282] Step S2001: Obtain the request identifier corresponding to the cross-shard processing request sent by the requesting end.

[0283] Step S2002: If the request identifier meets the cross-shard processing request identifier format, obtain the state change log corresponding to the cross-shard processing request; the state change log is used to characterize the log generated by the first shard after executing the cross-shard processing request.

[0284] Step S2003: Based on the state change log, obtain the target execution log corresponding to the cross-shard processing request.

[0285] Step S2004: Extract the event set corresponding to the cross-shard processing request from the target execution log.

[0286] Step S2005: Obtain the event identifier corresponding to the event in the event set; from the event set, determine the candidate events whose event identifiers satisfy the preset cross-segment event identifiers.

[0287] Step S2006: Obtain the legality verification result of the candidate events; from the candidate events, determine the candidate events whose legality verification results indicate that the legality verification has passed, and obtain the cross-sharding event corresponding to the cross-sharding processing request.

[0288] Among them, cross-shard events are used to characterize the events generated after the first shard executes the cross-shard processing request.

[0289] Step S2007: Obtain the first signature information of each node in the first shard for cross-shard events.

[0290] In the first shard, each node is used to serialize the event content in the cross-shard event to obtain the serialized data of the cross-shard event, and to sign the serialized data of the cross-shard event using the corresponding private key to obtain the corresponding first signature information.

[0291] Step S2008: If consensus on the cross-shard event is passed, obtain the first signature information set corresponding to the cross-shard event based on the first signature information of each node for the cross-shard event.

[0292] Step S2009: Send the cross-shard event and the first signature information set to the requesting end.

[0293] The requesting end is used to generate a related cross-shard processing request based on the cross-shard event and the first signature information set, and send the related cross-shard processing request to the corresponding second shard in the blockchain network; the second shard is used to verify the first signature information set using the cross-shard event, obtain the first verification result of the related cross-shard processing request, execute the related cross-shard processing request based on the first verification result, and return the request operation result corresponding to the related cross-shard processing request to the requesting end.

[0294] The requesting end is also used to receive the second signature information set corresponding to the request operation result returned by the second shard, generate the corresponding cross-shard submission information identifier based on the request operation result, generate cross-shard submission information according to the cross-shard submission information format, based on the request operation result, the second signature information set and the cross-shard submission information identifier, and send the cross-shard submission information to the first shard; the second signature information set includes the second signature information of each node in the second shard for the request operation result.

[0295] Step S2010: If the cross-shard submission information identifier meets the cross-shard submission information identifier format, obtain the target parameters in the cross-shard submission information; the target parameters include the request calculation result and the second signature information set.

[0296] Step S2011: If the target parameters meet the preset parameter format, the public key corresponding to the node identifier of the second signature information in the second signature information set and the request operation result are used to verify the second signature information to obtain the verification result of the second signature information; the verification result of the second signature information is used to characterize whether the second signature information is correct.

[0297] Step S2012: Determine the number of second correct signatures based on the verification results of each second signature information.

[0298] Step S2013: Based on the second number of correct signatures, obtain the second verification result of the cross-shard submission information.

[0299] Specifically, if the number of second correct signatures is greater than or equal to the second number, the cross-shard submission information verification is confirmed to be successful; the second number is used to represent the number of associated nodes in the second shard; if the number of second correct signatures is less than the second number, the cross-shard submission information verification is confirmed to be unsuccessful.

[0300] In step S2014, if the second verification result indicates that the cross-shard submission information verification is successful, based on the request calculation result and other request calculation results obtained after the first shard executes the cross-shard processing request, the cross-shard processing request is confirmed to be successfully processed. Then, a success message is returned to the requesting end, and the request calculation result is written to the corresponding block.

[0301] In step S2015, if the second verification result indicates that the cross-shard submission information verification fails, the cross-shard processing request is confirmed to have failed, the cross-shard submission information is deleted, and an error message is returned to the requesting end.

[0302] In this embodiment, during cross-shard processing, a first signature information set corresponding to the cross-shard event is obtained based on the first signature information of each node in the first shard for the cross-shard event. This achieves the purpose of multi-node signing of the cross-shard event, which is beneficial to improving the security of subsequent cross-shard processing. Moreover, an associated cross-shard processing request is generated based on the cross-shard event and the first signature information set, and the associated cross-shard processing request is sent to the corresponding second shard. This allows the second shard to verify the first signature information set using the cross-shard event before executing the associated cross-shard processing request, and obtain the first verification result of the associated cross-shard processing request. This achieves the purpose of verifying the associated cross-shard processing request before execution, and verifies multiple first signature information for the cross-shard event. This helps to avoid the defect of low security in cross-shard processing caused by the tampering of the associated cross-shard processing request, and further improves the security of cross-shard processing.

[0303] To more clearly illustrate the request processing method provided in the embodiments of this application, the following describes the request processing method in detail with a specific embodiment. In an exemplary embodiment, such as Figure 6As shown, this application also provides a blockchain sharding security processing method, specifically for cross-sharding processing mechanisms implemented based on sharding SDKs. Addressing three major security issues in existing cross-sharding solutions—malicious tampering of event content by the sharding SDK, malicious pre-emptive acquisition of cross-sharding events leading to the sending of erroneous transactions, and business stagnation caused by the sharding SDK's failure to process events—this application proposes a multi-layered security solution combining node signature endorsement, sharding chain pre-signature verification, transaction submission signature verification, and distributed deployment redundancy. This method involves multiple processing steps: cross-sharding main transaction processing, cross-sharding transaction processing, main sharding chain transaction submission processing, and distributed deployment; the specific execution process can be found in [reference needed]. Figure 6 This will not be elaborated upon here.

[0304] Furthermore, the key points of this solution are as follows: 1. After executing a cross-shard main transaction, the main shard node signs each cross-shard event and broadcasts the signature information along with the consensus vote; the shard SDK can obtain multiple node signatures as endorsements. 2. When sending a cross-shard transaction, the shard SDK writes the node signature as endorsement information into the transaction. The target shard chain parses the event and verifies the signature before transaction execution, and only accepts the transaction if a sufficient number of correct signatures are obtained. 3. After the cross-shard transaction is completed, the executing node signs the result and broadcasts it. The shard SDK collects signatures and carries them to the main shard chain in the submitted transaction. The main shard chain also verifies the signatures before allowing submission. 4. To address the issue of the shard SDK not handling the transaction, multiple shard SDK instances are deployed in a distributed manner to ensure that at least one instance processes the event normally, and double-spending and duplicate execution are avoided through transaction ID standardization.

[0305] The above embodiments can achieve the following technical effects: (1) Preventing event tampering: Multi-node signature endorsement provides an unforgeable source of event credibility, and pre-signature verification of the sharded chain blocks tampering of transactions; (2) Preventing preemptive and forgery: Signatures are publicly verifiable, and malicious SDKs cannot construct valid endorsements, so preemptive transactions are directly discarded; (3) Preventing deadlock caused by non-malicious behavior: Distributed deployment and redundant acquisition ensure that at least one instance can complete the processing of cross-shard events, improving availability; (4) Reducing waste of on-chain resources: Signature verification is performed before execution, and invalid or malicious transactions do not enter the execution stage; (5) Compatible with existing sharded architecture: Signature information is extended only in the transaction structure and node voting, without significantly changing the consensus and storage model; (6) Enhancing the atomicity awareness of cross-sharded transactions: Signature verification of submitted transactions ensures the credibility of the final result and avoids inconsistencies in the global state caused by partial success.

[0306] It should be understood that although the steps in the flowcharts of the embodiments described above are shown sequentially according to the arrows, these steps are not necessarily executed in the order indicated by the arrows. Unless explicitly stated herein, there is no strict order restriction on the execution of these steps, and they can be executed in other orders. Moreover, at least some steps in the flowcharts of the embodiments described above may include multiple steps or multiple stages. These steps or stages are not necessarily completed at the same time, but can be executed at different times. The execution order of these steps or stages is not necessarily sequential, but can be performed alternately or in turn with other steps or at least some of the steps or stages in other steps. It is understood that the steps in different embodiments can be freely combined as needed, and all non-contradictory solutions formed by such combinations are within the scope of protection of this application.

[0307] Based on the same inventive concept, this application also provides a request processing apparatus for implementing the request processing method described above. The solution provided by this apparatus is similar to the implementation described in the above method; therefore, the specific limitations in one or more request processing apparatus embodiments provided below can be found in the limitations of the request processing method described above, and will not be repeated here.

[0308] In one exemplary embodiment, such as Figure 21 As shown, a request processing device 2100 is provided, applied to a node in a first shard of a blockchain network; the blockchain network includes multiple shards, each shard representing a sub-blockchain network within the blockchain network; the device includes: a first acquisition module 2101, a second acquisition module 2102, a first sending module 2103, and a result determination module 2104, wherein:

[0309] The first acquisition module 2101 is used to acquire the cross-shard event corresponding to the cross-shard processing request sent by the requesting end; the cross-shard event is used to characterize the event generated by the first shard after executing the cross-shard processing request.

[0310] The second acquisition module 2102 is used to acquire the first signature information set corresponding to the cross-shard event; the first signature information set includes the first signature information of each node in the first shard for the cross-shard event.

[0311] The first sending module 2103 is used to send the cross-shard event and the first signature information set to the requesting end, so that the requesting end generates an associated cross-shard processing request based on the cross-shard event and the first signature information set, and sends the associated cross-shard processing request to the corresponding second shard in the blockchain network; the second shard is used to verify the first signature information set using the cross-shard event, obtain the first verification result of the associated cross-shard processing request, execute the associated cross-shard processing request based on the first verification result, and return the request operation result corresponding to the associated cross-shard processing request to the requesting end.

[0312] The result determination module 2104 is used to obtain the target processing result of the cross-shard processing request based on the request calculation result returned by the requesting end.

[0313] In an exemplary embodiment, the first acquisition module 2101 is further configured to acquire the target execution log corresponding to the cross-shard processing request sent by the requesting end; extract the event set corresponding to the cross-shard processing request from the target execution log; and acquire the cross-shard event corresponding to the cross-shard processing request from the event set.

[0314] In an exemplary embodiment, the first acquisition module 2101 is further configured to acquire a request identifier corresponding to the cross-shard processing request; if the request identifier meets the cross-shard processing request identifier format, acquire a state change log corresponding to the cross-shard processing request; the state change log is used to characterize the log generated by the first shard after executing the cross-shard processing request; and based on the state change log, obtain the target execution log corresponding to the cross-shard processing request.

[0315] In an exemplary embodiment, the first acquisition module 2101 is further configured to acquire the event identifier corresponding to the event in the event set; determine the candidate events whose event identifiers satisfy the preset cross-shard event identifiers from the event set; acquire the legality verification result of the candidate events; determine the candidate events whose legality verification result indicates that the legality verification has passed from the candidate events, and obtain the cross-shard event corresponding to the cross-shard processing request.

[0316] In an exemplary embodiment, the second acquisition module 2102 is further configured to acquire the first signature information of each node in the first shard for the cross-shard event; each node in the first shard is configured to serialize the event content in the cross-shard event to obtain the serialized data of the cross-shard event, and to sign the serialized data of the cross-shard event using the corresponding private key to obtain the corresponding first signature information; if the consensus on the cross-shard event is passed, the first signature information set corresponding to the cross-shard event is obtained based on the first signature information of each node for the cross-shard event.

[0317] In an exemplary embodiment, each node in the first shard is used to perform importance identification processing on the event content in the cross-shard event to obtain the first importance corresponding to the event content in the cross-shard event. Based on the first importance, key event content is extracted from the event content in the cross-shard event, and the key event content is serialized to obtain the serialized data of the cross-shard event.

[0318] In an exemplary embodiment, the first sending module 2103 is further configured to, in the event of an anomaly at the requesting end, determine, from the requesting end cluster to which the requesting end belongs, a normal requesting end other than the requesting end; send the cross-shard event and the first signature information set to the normal requesting end; or, send the cross-shard event and the first signature information set to the load balancing server, so that the load balancing server sends the cross-shard event and the first signature information set to the target requesting end in the requesting end cluster.

[0319] In an exemplary embodiment, the requesting end is further configured to receive a second signature information set corresponding to the request operation result returned by the second shard, generate cross-shard submission information based on the request operation result and the second signature information set, and send the cross-shard submission information to the first shard; the second signature information set includes the second signature information of each node in the second shard for the request operation result.

[0320] The result determination module 2104 is also used to verify the second signature information set using the request operation result to obtain the second verification result of the cross-shard submission information; and based on the second verification result, to obtain the target processing result of the cross-shard processing request.

[0321] In an exemplary embodiment, the requesting end is further configured to generate a corresponding cross-shard submission information identifier based on the request operation result, and generate cross-shard submission information according to the cross-shard submission information format, based on the request operation result, the second signature information set and the cross-shard submission information identifier.

[0322] The result determination module 2104 is further configured to: obtain target parameters in the cross-shard submission information if the cross-shard submission information identifier meets the cross-shard submission information identifier format; the target parameters include the request operation result and the second signature information set; if the target parameters meet the preset parameter format, verify the second signature information using the public key corresponding to the node identifier of the second signature information in the second signature information set and the request operation result, and obtain the verification result of the second signature information; the verification result of the second signature information is used to characterize whether the second signature information is correct; determine the number of second correct signatures based on the verification results of each second signature information; and obtain the second verification result of the cross-shard submission information based on the number of second correct signatures.

[0323] In an exemplary embodiment, the second signature information includes multiple sub-signature information obtained by using the private key corresponding to the node identifier of the second signature information to sign multiple different first digest values ​​of the request operation result.

[0324] The result determination module 2104 is further configured to use the public key corresponding to the node identifier of the second signature information to design multiple sub-signature information in the second signature information to obtain multiple first digest values ​​of the requested operation result; obtain multiple second digest values ​​of the requested operation result; and obtain the verification result of the second signature information based on the comparison result between the multiple first digest values ​​and the multiple second digest values ​​of the requested operation result.

[0325] In an exemplary embodiment, the result determination module 2104 is further configured to confirm that the cross-shard submission information verification is successful if the second number of correct signatures is greater than or equal to the second number; the second number is used to characterize the number of associated nodes of the second shard; and to confirm that the cross-shard submission information verification is unsuccessful if the second number of correct signatures is less than the second number.

[0326] The result determination module 2104 is also used to confirm that the cross-shard submission information verification fails when the target parameters do not meet the preset parameter format.

[0327] In an exemplary embodiment, the result determination module 2104 is further configured to, if the second verification result indicates that the cross-shard submission information verification has passed, confirm the successful processing of the cross-shard processing request based on the request calculation result and other request calculation results obtained after the first shard executes the cross-shard processing request, return success information to the requesting end, and write the request calculation result into the corresponding block; if the second verification result indicates that the cross-shard submission information verification has failed, confirm the failure of the cross-shard processing request, delete the cross-shard submission information, and return error information to the requesting end.

[0328] In an exemplary embodiment, a cross-shard processing request is a cross-shard resource transfer request; a cross-shard event is a cross-shard resource transfer event.

[0329] The first sending module 2103 is further configured to send the cross-shard resource transfer event and the first signature information set to the requesting end, so that the requesting end generates an associated cross-shard resource transfer request based on the cross-shard resource transfer event and the first signature information set, and sends the associated cross-shard resource transfer request to the second shard; the second shard is configured to use the cross-shard resource transfer event to verify the first signature information set, obtain the first verification result of the associated cross-shard resource transfer request, execute the associated cross-shard resource transfer request based on the first verification result, and return the resource transfer request calculation result corresponding to the associated cross-shard resource transfer request to the requesting end.

[0330] The result determination module 2104 is also used to determine the target processing result of the cross-shard resource transfer request based on the resource transfer request calculation result and the other resource transfer request calculation results obtained after the first shard executes the cross-shard resource transfer request; the target processing result is used to characterize whether the cross-shard resource transfer request is successfully processed.

[0331] In one exemplary embodiment, such as Figure 22 As shown, another request processing device 2200 is provided, applied to a node in a second shard of a blockchain network; the blockchain network includes multiple shards, each shard representing a sub-blockchain network within the blockchain network; the device includes: a request receiving module 2201, a signature verification module 2202, and a result sending module 2203, wherein:

[0332] The request receiving module 2201 is used to receive the associated cross-shard processing request sent by the requesting end; the requesting end is used to receive the cross-shard event sent by the node in the first shard corresponding to the cross-shard processing request sent by the requesting end, and the first signature information set corresponding to the cross-shard event, and generate the associated cross-shard processing request based on the cross-shard event and the first signature information set; the cross-shard event is used to characterize the event generated after the first shard executes the cross-shard processing request; the first signature information set includes the first signature information of each node in the first shard for the cross-shard event.

[0333] The signature verification module 2202 is used to verify the first signature information set using cross-shard events to obtain the first verification result associated with the cross-shard processing request.

[0334] The result sending module 2203 is used to execute the associated cross-shard processing request based on the first verification result, and return the request calculation result corresponding to the associated cross-shard processing request to the requesting end, so that the requesting end sends the request calculation result to the first shard; the nodes in the first shard are used to obtain the target processing result of the cross-shard processing request based on the request calculation result.

[0335] In an exemplary embodiment, the requesting end is further configured to generate a corresponding associated cross-shard processing request identifier based on the cross-shard event, and generate an associated cross-shard processing request according to the associated cross-shard processing request format, based on the cross-shard event, the first signature information set, and the associated cross-shard processing request identifier.

[0336] The signature verification module 2202 is further configured to, when the associated cross-shard processing request identifier satisfies the associated cross-shard processing request identifier format, use the public key corresponding to the node identifier of the first signature information in the first signature information set, and the cross-shard event, to verify the first signature information and obtain the verification result of the first signature information; the verification result of the first signature information is used to characterize whether the first signature information is correct; based on the verification result of each first signature information, the first number of correct signatures is determined; based on the first number of correct signatures, the first verification result of the associated cross-shard processing request is obtained.

[0337] In an exemplary embodiment, the signature verification module 2202 is further configured to confirm that the associated cross-shard processing request verification passes if the first number of correct signatures is greater than or equal to the first number; the first number is used to characterize the number of associated nodes of the first shard; and to confirm that the associated cross-shard processing request verification fails if the first number of correct signatures is less than the first number.

[0338] In an exemplary embodiment, the result sending module 2203 is further configured to execute the associated cross-shard processing request and obtain the request operation result corresponding to the associated cross-shard processing request if the first verification result indicates that the verification of the associated cross-shard processing request has passed.

[0339] The request processing device 2200 also includes an information return module, which is used to delete the associated cross-shard processing request and return error information to the requesting end if the first verification result indicates that the verification of the associated cross-shard processing request fails.

[0340] In an exemplary embodiment, the request processing device 2200 further includes a signature acquisition module for acquiring a second signature information set corresponding to the request operation result; the second signature information set includes the second signature information of each node in the second slice for the request operation result.

[0341] The result sending module 2203 is also used to return the request calculation result and the second signature information set to the requesting end, so that the requesting end can generate cross-shard submission information based on the request calculation result and the second signature information set, and send the cross-shard submission information to the first shard; the nodes in the first shard are used to verify the second signature information set using the request calculation result, to obtain the second verification result of the cross-shard submission information, and to obtain the target processing result of the cross-shard processing request based on the second verification result.

[0342] In an exemplary embodiment, the signature acquisition module is further configured to acquire the second signature information of each node in the second shard for the requested computation result; each node in the second shard is configured to serialize the result content in the requested computation result to obtain serialized data of the requested computation result, and to sign the serialized data of the requested computation result using the corresponding private key to obtain the corresponding second signature information; if the consensus on the requested computation result is passed, a second signature information set corresponding to the requested computation result is obtained based on the second signature information of each node for the requested computation result.

[0343] In an exemplary embodiment, each node in the second slice is used to perform importance identification processing on the result content in the request operation result to obtain the second importance corresponding to the result content in the request operation result, extract key result content from the result content in the request operation result based on the second importance, and perform serialization processing on the key result content to obtain serialized data of the request operation result.

[0344] Each module in the aforementioned request processing device can be implemented entirely or partially through software, hardware, or a combination thereof. These modules can be embedded in or independent of the processor in a computer device in hardware form, or stored in the memory of a computer device in software form, so that the processor can invoke and execute the operations corresponding to each module.

[0345] In one exemplary embodiment, a computer device is provided, which may be a server, and its internal structure diagram may be as follows: Figure 23 As shown, this computer device includes a processor, memory, input / output interfaces (I / O), and a communication interface. The processor, memory, and I / O interfaces are connected via a system bus, and the communication interface is also connected to the system bus via the I / O interfaces. The processor provides computational and control capabilities. The memory includes non-volatile storage media and internal memory. The non-volatile storage media stores the operating system, computer programs, and a database. The internal memory provides the environment for the operation of the operating system and computer programs stored in the non-volatile storage media. The database stores data such as cross-shard events and first signature information sets. The I / O interfaces are used for exchanging information between the processor and external devices. The communication interface is used for communicating with external terminals via a network connection. When executed by the processor, the computer program implements a request processing method.

[0346] Those skilled in the art will understand that Figure 23The structure shown is merely a block diagram of a portion of the structure related to the present application and does not constitute a limitation on the computer device to which the present application is applied. Specific computer devices may include more or fewer components than those shown in the figure, or combine certain components, or have different component arrangements.

[0347] In one exemplary embodiment, a computer device is also provided, including a memory and a processor, wherein the memory stores a computer program, and the processor executes the computer program to implement the steps in the above-described method embodiments.

[0348] In one exemplary embodiment, a computer-readable storage medium is provided having a computer program stored thereon that, when executed by a processor, implements the steps in the above-described method embodiments.

[0349] In one exemplary embodiment, a computer program product is provided, including a computer program that, when executed by a processor, implements the steps in the above-described method embodiments.

[0350] It should be noted that the user information (including but not limited to user device information, user personal information, etc.) and data (including but not limited to data used for analysis, data stored, data displayed, etc.) involved in this application are all information and data authorized by the user or fully authorized by all parties, and the collection, use and processing of the relevant data must comply with relevant regulations.

[0351] Those skilled in the art will understand that all or part of the processes in the methods of the above embodiments can be implemented by a computer program instructing related hardware. The computer program can be stored in a non-volatile computer-readable storage medium, and when executed, it can include the processes of the embodiments of the above methods. Any references to memory, databases, or other media used in the embodiments provided in this application can include at least one of non-volatile memory and volatile memory. Non-volatile memory can include read-only memory (ROM), magnetic tape, floppy disk, flash memory, optical memory, high-density embedded non-volatile memory, resistive random access memory (ReRAM), magnetic random access memory (MRAM), ferroelectric random access memory (FRAM), phase change memory (PCM), graphene memory, etc. Volatile memory can include random access memory (RAM) or external cache memory, etc. By way of illustration and not limitation, RAM can take many forms, such as Static Random Access Memory (SRAM) or Dynamic Random Access Memory (DRAM). The databases involved in the embodiments provided in this application may include at least one type of relational database and non-relational database. Non-relational databases may include, but are not limited to, blockchain-based distributed databases. The processors involved in the embodiments provided in this application may be general-purpose processors, central processing units, graphics processing units, digital signal processors, programmable logic devices, data processing logic devices, artificial intelligence (AI) processors, etc., and are not limited to these.

[0352] The technical features of the above embodiments can be combined in any way. For the sake of brevity, not all possible combinations of the technical features in the above embodiments are described. However, as long as there is no contradiction in the combination of these technical features, they should be considered to be within the scope of this application.

[0353] The embodiments described above are merely illustrative of several implementation methods of this application, and while the descriptions are specific and detailed, they should not be construed as limiting the scope of this patent application. It should be noted that those skilled in the art can make various modifications and improvements without departing from the concept of this application, and these all fall within the protection scope of this application. Therefore, the protection scope of this application should be determined by the appended claims.

Claims

1. A request processing method, characterized in that, The method is applied to nodes in the first shard of a blockchain network; the blockchain network includes multiple shards, each shard representing a sub-blockchain network within the blockchain network; the method includes: Obtain the cross-shard event corresponding to the cross-shard processing request sent by the requesting end; the cross-shard event is used to characterize the event generated by the first shard after executing the cross-shard processing request; Obtain the first signature information set corresponding to the cross-shard event; the first signature information set includes the first signature information of each node in the first shard for the cross-shard event; The cross-shard event and the first signature information set are sent to the requesting end, causing the requesting end to generate an associated cross-shard processing request based on the cross-shard event and the first signature information set. The associated cross-shard processing request is then sent to the corresponding second shard in the blockchain network. The second shard is used to verify the first signature information set using the cross-shard event, obtain a first verification result of the associated cross-shard processing request, execute the associated cross-shard processing request based on the first verification result, and return the request operation result corresponding to the associated cross-shard processing request to the requesting end. Based on the request calculation result returned by the requesting end, the target processing result of the cross-shard processing request is obtained.

2. The method according to claim 1, characterized in that, The acquisition of the cross-sharding event corresponding to the cross-sharding processing request sent by the requesting end includes: Retrieve the target execution log corresponding to the cross-shard processing request sent by the requesting end; Extract the event set corresponding to the cross-shard processing request from the target execution log; Obtain the cross-shard event corresponding to the cross-shard processing request from the event set.

3. The method according to claim 2, characterized in that, The acquisition of the target execution log corresponding to the cross-shard processing request sent by the requesting end includes: Obtain the request identifier corresponding to the cross-shard processing request; If the request identifier meets the cross-shard processing request identifier format, obtain the status change log corresponding to the cross-shard processing request; the status change log is used to characterize the log generated by the first shard after executing the cross-shard processing request; Based on the state change log, the target execution log corresponding to the cross-shard processing request is obtained.

4. The method according to claim 2, characterized in that, The step of obtaining the cross-sharding event corresponding to the cross-sharding processing request from the event set includes: Obtain the event identifier corresponding to the event in the event set; From the event set, candidate events whose event identifiers satisfy the preset cross-segment event identifiers are determined; Obtain the legality verification result of the candidate event; From the candidate events, the candidate events whose legality verification results indicate that the legality verification has passed are determined, and the cross-shard event corresponding to the cross-shard processing request is obtained.

5. The method according to claim 1, characterized in that, The step of obtaining the first signature information set corresponding to the cross-shard event includes: Obtain the first signature information of each node in the first shard for the cross-shard event; each node in the first shard is used to serialize the event content in the cross-shard event to obtain the serialized data of the cross-shard event, and use the corresponding private key to sign the serialized data of the cross-shard event to obtain the corresponding first signature information. If consensus is reached on the cross-shard event, a first signature information set corresponding to the cross-shard event is obtained based on the first signature information of each node for the cross-shard event.

6. The method according to claim 5, characterized in that, Each node in the first shard is used to serialize the event content in the cross-shard event to obtain the serialized data of the cross-shard event, including: Each node in the first shard is used to perform importance identification processing on the event content in the cross-shard event to obtain the first importance corresponding to the event content in the cross-shard event. Based on the first importance, key event content is extracted from the event content in the cross-shard event, and the key event content is serialized to obtain the serialized data of the cross-shard event.

7. The method according to claim 1, characterized in that, Sending the cross-shard event and the first signature information set to the requesting end includes: In the event of an anomaly at the requesting end, identify the normal requesting ends other than the requesting end from the requesting end cluster to which the requesting end belongs; Send the cross-shard event and the first signature information set to the normal request client; or, The cross-shard event and the first signature information set are sent to the load balancer server, which then sends the cross-shard event and the first signature information set to the target requester in the requester cluster.

8. The method according to claim 1, characterized in that, The requesting end is also used to receive the second signature information set corresponding to the request operation result returned by the second shard, generate cross-shard submission information based on the request operation result and the second signature information set, and send the cross-shard submission information to the first shard. The second signature information set includes the second signature information of each node in the second slice for the result of the request operation; The process of obtaining the target processing result of the cross-shard processing request based on the request calculation result returned by the requesting end includes: The second signature information set is verified using the result of the request operation to obtain the second verification result of the cross-shard submission information; Based on the second verification result, the target processing result of the cross-shard processing request is obtained.

9. The method according to claim 8, characterized in that, The requesting end is also used to generate a corresponding cross-shard submission information identifier based on the request operation result, and generate the cross-shard submission information according to the cross-shard submission information format, based on the request operation result, the second signature information set and the cross-shard submission information identifier; The step of verifying the second signature information set using the request calculation result to obtain the second verification result of the cross-shard submission information includes: If the cross-shard submission information identifier meets the cross-shard submission information identifier format, the target parameter in the cross-shard submission information is obtained; the target parameter includes the request calculation result and the second signature information set; If the target parameters meet the preset parameter format, the public key corresponding to the node identifier of the second signature information in the second signature information set and the request operation result are used to verify the second signature information to obtain the verification result of the second signature information; the verification result of the second signature information is used to characterize whether the second signature information is correct. Based on the verification results of each of the second signature information, the number of second correct signatures is determined; Based on the second number of correct signatures, a second verification result of the cross-shard submission information is obtained.

10. The method according to claim 9, characterized in that, The second signature information includes multiple sub-signature information obtained by using the private key corresponding to the node identifier of the second signature information to sign multiple different first digest values ​​of the request operation result; The step of verifying the second signature information using the public key corresponding to the node identifier of the second signature information in the second signature information set, and the result of the request operation, to obtain the verification result of the second signature information, includes: Using the public key corresponding to the node identifier of the second signature information, the multiple sub-signature information in the second signature information is designed to obtain multiple first digest values ​​of the request operation result; Obtain multiple second digest values ​​of the request operation result, and based on the comparison results between multiple first digest values ​​and multiple second digest values ​​of the request operation result, obtain the verification result of the second signature information.

11. The method according to claim 9, characterized in that, The second verification result of the cross-shard submission information, based on the second number of correct signatures, includes: If the second number of correct signatures is greater than or equal to the second number, the cross-shard submission information verification is confirmed to be successful; the second number is used to characterize the number of associated nodes in the second shard. If the number of the second correct signatures is less than the second number, it is confirmed that the cross-shard submission information verification fails. After obtaining the target parameters from the cross-shard submission information, the process also includes: If the target parameters do not meet the preset parameter format, it is confirmed that the cross-shard submission information verification fails.

12. The method according to claim 8, characterized in that, The step of obtaining the target processing result of the cross-shard processing request based on the second verification result includes: If the second verification result indicates that the cross-shard submission information has passed verification, based on the request calculation result and other request calculation results obtained after the first shard executes the cross-shard processing request, the cross-shard processing request is confirmed to have been successfully processed. Then, a success message is returned to the requesting end, and the request calculation result is written to the corresponding block. If the second verification result indicates that the cross-shard submission information verification fails, the cross-shard processing request is confirmed to have failed, the cross-shard submission information is deleted, and an error message is returned to the requesting end.

13. The method according to claim 1, characterized in that, The cross-shard processing request is a cross-shard resource transfer request; The cross-shard event is a cross-shard resource transfer event; Sending the cross-shard event and the first signature information set to the requesting end includes: The cross-shard resource transfer event and the first signature information set are sent to the requesting end, causing the requesting end to generate an associated cross-shard resource transfer request based on the cross-shard resource transfer event and the first signature information set, and send the associated cross-shard resource transfer request to the second shard; the second shard is used to verify the first signature information set using the cross-shard resource transfer event, obtain a first verification result of the associated cross-shard resource transfer request, execute the associated cross-shard resource transfer request based on the first verification result, and return the resource transfer request calculation result corresponding to the associated cross-shard resource transfer request to the requesting end; The process of obtaining the target processing result of the cross-shard processing request based on the request calculation result returned by the requesting end includes: Based on the resource transfer request calculation result and the other resource transfer request calculation results obtained after the first shard executes the cross-shard resource transfer request, the target processing result of the cross-shard resource transfer request is determined; the target processing result is used to characterize whether the cross-shard resource transfer request is successfully processed.

14. A request processing method, characterized in that, The method is applied to nodes in a second shard of a blockchain network; the blockchain network includes multiple shards, each shard representing a sub-blockchain network within the blockchain network; the method includes: The receiving end sends an associated cross-shard processing request; the receiving end is used to receive a cross-shard event corresponding to the cross-shard processing request sent by the requesting end and a first signature information set corresponding to the cross-shard event sent by a node in the first shard; and generates the associated cross-shard processing request based on the cross-shard event and the first signature information set; the cross-shard event is used to characterize the event generated by the first shard after executing the cross-shard processing request; the first signature information set includes the first signature information of each node in the first shard for the cross-shard event; The first signature information set is verified using the cross-shard event to obtain the first verification result of the associated cross-shard processing request; Based on the first verification result, the associated cross-shard processing request is executed, and the request calculation result corresponding to the associated cross-shard processing request is returned to the requesting end, so that the requesting end sends the request calculation result to the first shard; the nodes in the first shard are used to obtain the target processing result of the cross-shard processing request based on the request calculation result.

15. The method according to claim 14, characterized in that, The requesting end is also used to generate a corresponding associated cross-shard processing request identifier based on the cross-shard event, and generate the associated cross-shard processing request according to the associated cross-shard processing request format, based on the cross-shard event, the first signature information set and the associated cross-shard processing request identifier; The step of verifying the first signature information set using the cross-shard event to obtain the first verification result of the associated cross-shard processing request includes: If the associated cross-shard processing request identifier satisfies the associated cross-shard processing request identifier format, the first signature information is verified using the public key corresponding to the node identifier of the first signature information in the first signature information set, and the cross-shard event, to obtain the verification result of the first signature information; the verification result of the first signature information is used to characterize whether the first signature information is correct. Based on the verification results of each of the first signature information, the first number of correct signatures is determined; Based on the first number of correct signatures, the first verification result of the associated cross-shard processing request is obtained.

16. A request processing apparatus, characterized in that, A node applied to a first shard in a blockchain network; the blockchain network includes multiple shards, each shard representing a sub-blockchain network within the blockchain network; the device includes: The first acquisition module is used to acquire cross-shard events corresponding to the cross-shard processing request sent by the requesting end; the cross-shard events are used to characterize the events generated by the first shard after executing the cross-shard processing request; The second acquisition module is used to acquire the first signature information set corresponding to the cross-shard event; the first signature information set includes the first signature information of each node in the first shard for the cross-shard event; A first sending module is configured to send the cross-shard event and the first signature information set to the requesting end, causing the requesting end to generate an associated cross-shard processing request based on the cross-shard event and the first signature information set, and send the associated cross-shard processing request to the corresponding second shard in the blockchain network; the second shard is configured to use the cross-shard event to verify the first signature information set, obtain a first verification result of the associated cross-shard processing request, execute the associated cross-shard processing request based on the first verification result, and return the request operation result corresponding to the associated cross-shard processing request to the requesting end; The result determination module is used to obtain the target processing result of the cross-shard processing request based on the request calculation result returned by the requesting end.

17. A request processing apparatus, characterized in that, A node applied in a second shard of a blockchain network; the blockchain network includes multiple shards, each shard representing a sub-blockchain network within the blockchain network; the apparatus includes: A request receiving module is used to receive an associated cross-shard processing request sent by a requesting end. The requesting end is used to receive a cross-shard event sent by a node in the first shard corresponding to the cross-shard processing request sent by the requesting end, and a first signature information set corresponding to the cross-shard event. Based on the cross-shard event and the first signature information set, the associated cross-shard processing request is generated. The cross-shard event is used to characterize an event generated by the first shard after executing the cross-shard processing request. The first signature information set includes the first signature information of each node in the first shard for the cross-shard event. The signature verification module is used to verify the first signature information set using the cross-shard event to obtain the first verification result of the associated cross-shard processing request. The result sending module is used to execute the associated cross-shard processing request based on the first verification result, return the request calculation result corresponding to the associated cross-shard processing request to the requesting end, and enable the requesting end to send the request calculation result to the first shard; the nodes in the first shard are used to obtain the target processing result of the cross-shard processing request based on the request calculation result.

18. A computer device comprising a memory and a processor, wherein the memory stores a computer program, characterized in that, When the processor executes the computer program, it implements the steps of the method according to any one of claims 1 to 15.

19. A computer-readable storage medium having a computer program stored thereon, characterized in that, When the computer program is executed by a processor, it implements the steps of the method according to any one of claims 1 to 15.

20. A computer program product, comprising a computer program, characterized in that, When the computer program is executed by a processor, it implements the steps of the method according to any one of claims 1 to 15.

Images