Blockchain-based request processing method, apparatus, and electronic device

Abstract

The application discloses a blockchain-based request processing method and device and electronic equipment. It is related to the field of blockchain. The method comprises: in the case of change of an authentication node in a cross-chain gateway node cluster, updating the identity document in the identity chain based on the identity document of the changed authentication node; in the case of receiving a cross-chain operation request of a source blockchain, signing the cross-chain operation request through multiple authentication nodes in the cross-chain gateway node cluster to obtain a cross-chain proof; and sending the cross-chain proof to a target blockchain, wherein the target blockchain verifies the compliance of the cross-chain proof based on the identity document in the identity chain. Through the application, the problem of directly registering the public key information of the authentication node to the target chain in the related art in the cross-chain scenario, and the need to redeploy information on the target chain when the authentication node changes, thereby affecting the reliability of cross-chain operation, is solved.

Description

Technical Field

[0001] This application relates to the field of blockchain, and more specifically, to a blockchain-based request processing method, apparatus, and electronic device. Background Technology

[0002] With the rapid development of blockchain technology, the phenomenon of "chain silos" between different blockchain networks has become increasingly prominent, making cross-chain interoperability a key technological requirement for achieving collaborative development of multi-chain ecosystems. In cross-chain communication and asset transfer processes, the notary mechanism has been proposed and widely applied as an important cross-chain technology solution. This mechanism introduces one or more trusted third-party nodes, namely notary nodes (also known as authentication nodes), to listen to, verify, and relay cross-chain events. This mechanism requires cross-chain transactions to be jointly signed and confirmed by a preset number or proportion of notary nodes before the corresponding operations can be executed on the target chain, thereby achieving information transmission and state synchronization between different chains.

[0003] Currently, in related technologies, the list of public keys related to signatures of the notary node is usually hard-coded directly into the verification contract of the target chain. When the notary node changes, the verification contract must be redeployed or upgraded on all target chains. This process has high maintenance costs and creates a security window during contract upgrades—the old key may have been leaked while the new contract has not yet been deployed, thus affecting the reliability of cross-chain operations.

[0004] There is currently no effective solution to the aforementioned problems in the relevant technologies. Summary of the Invention

[0005] The main purpose of this application is to provide a blockchain-based request processing method, device, and electronic device to solve the problem that in cross-chain scenarios, when the public key information of the authentication node is directly registered to the target chain, the information needs to be redeployed on the target chain when the authentication node changes, thus affecting the reliability of cross-chain operations.

[0006] To achieve the above objectives, according to one aspect of this application, a blockchain request processing method is provided. The method includes: when an authentication node in a cross-chain gateway node cluster changes, updating an identity document in an identity chain based on the identity document of the changed authentication node, wherein the identity document describes the public key information of the authentication node, and the identity chain is a blockchain used to store the identity document; upon receiving a cross-chain operation request from a source blockchain, signing the cross-chain operation request through multiple authentication nodes in the cross-chain gateway node cluster to obtain a cross-chain proof, wherein the cross-chain operation request requests a target blockchain to perform a target operation; and sending the cross-chain proof to the target blockchain, wherein the target blockchain performs compliance verification on the cross-chain proof based on the identity document in the identity chain, and if the compliance verification passes, the target blockchain executes the target operation.

[0007] Optionally, the blockchain-based request processing method further includes: registering the identity document of the changed authentication node to the identity chain when the changed authentication node is a newly added authentication node; deregistering the identity document of the changed authentication node from the identity chain when the changed authentication node is a deleted authentication node; and updating the target identity document in the identity chain when the changed authentication node is an authentication node whose identity document has changed, wherein the target identity document refers to the identity document of the changed authentication node.

[0008] Optionally, the blockchain-based request processing method further includes: before updating the target identity document in the identity chain, for the target identity document held by the changed authentication node, adding a verification method entry corresponding to the new public key to the target identity document, and retaining the verification method entry corresponding to the old public key, wherein the verification method entry includes the public key type, public key encoding format, public key value, and entry identifier; updating the field value of the first reference field in the target identity document to the entry identifier corresponding to the new public key, wherein the first reference is used to represent the public key information used when signing the cross-chain operation request.

[0009] Optionally, the blockchain-based request processing method further includes: updating the target identity document held by the changed authentication node to the identity chain; after updating the target identity document held by the changed authentication node to the identity chain, determining the time point at which the target identity document held by the changed authentication node is updated to the identity chain as the target time point; and after the target time interval of the target time point, removing the verification method entry corresponding to the old public key from the target identity document for the target identity document held by the changed authentication node.

[0010] Optionally, the blockchain-based request processing method further includes: for each authentication node, signing the cross-chain operation request using the authentication node's private key to obtain a signature value; generating a signature entry for the authentication node based on the signature value corresponding to the authentication node, the node identifier of the authentication node, the entry identifier corresponding to the authentication node, and the hash value of the authorization credential of the authentication node, wherein the identity document records verification method entries, and the verification method entries include public key type, public key encoding format, public key value, and entry identifier, and the authorization credential is issued to the authentication node by the target management module; if the number of signature entries is greater than or equal to a preset number, determining the cross-chain proof based on the generated signature entries.

[0011] Optionally, the blockchain-based request processing method further includes: validating the signature value in the cross-chain proof based on the identity document in the identity chain; validating the authorization credential hash value if the signature value is valid, wherein the authorization credential is issued to the authentication node by the target management module; validating whether the cross-chain operation request is within the authorization scope of the authorization credential if the authorization credential hash value is valid; validating compliance verification if the cross-chain operation request is within the authorization scope; and validating compliance verification if the signature value is invalid, the authorization credential hash value is invalid, or the cross-chain operation request is outside the authorization scope.

[0012] Optionally, the blockchain-based request processing method also includes: authorizing and authenticating the authentication node through the target management module; issuing an authorization credential to the authentication node through the target management module if the authorization and authentication are successful; and storing the authorization credential in the authentication node and the identity chain.

[0013] To achieve the above objectives, according to another aspect of this application, a blockchain-based request processing system is provided. The system includes: a cross-chain gateway node cluster, comprising multiple authentication nodes, wherein, in the event of a change in the authentication nodes within the cross-chain gateway node cluster, the authentication nodes update an identity document in an identity chain based on the identity document of the changed authentication node, wherein the identity document describes the public key information of the authentication node; upon receiving a cross-chain operation request from a source blockchain, the system signs the cross-chain operation request through the multiple authentication nodes in the cross-chain gateway node cluster, wherein the cross-chain operation request requests a target blockchain to perform a target operation; an identity chain, which is a blockchain used to store identity documents; and a cross-chain proof generation module, used to generate a cross-chain proof based on the signatures of the cross-chain operation request from the multiple authentication nodes, and send the cross-chain proof to the target blockchain, wherein the target blockchain performs compliance verification on the cross-chain proof based on the identity document in the identity chain, and if the compliance verification passes, the target blockchain executes the target operation.

[0014] To achieve the above objectives, according to another aspect of this application, a blockchain-based request processing apparatus is provided. The apparatus includes: an update module, configured to update an identity document in an identity chain based on the identity document of the changed authentication node when a change occurs in the authentication node of the cross-chain gateway node cluster; wherein the identity document describes the public key information of the authentication node, and the identity chain is a blockchain used to store the identity document; a signature module, configured to sign a cross-chain operation request received from a source blockchain by having multiple authentication nodes in the cross-chain gateway node cluster sign the cross-chain operation request to obtain a cross-chain proof; wherein the cross-chain operation request requests a target blockchain to perform a target operation; and a sending module, configured to send the cross-chain proof to the target blockchain, wherein the target blockchain performs compliance verification on the cross-chain proof based on the identity document in the identity chain, and if the compliance verification passes, the target blockchain executes the target operation.

[0015] To achieve the above objectives, according to another aspect of this application, a computer-readable storage medium is provided, the computer-readable storage medium including a stored executable program, wherein, when the executable program is running, it controls the device where the computer-readable storage medium is located to execute the above-described blockchain-based request processing method.

[0016] To achieve the above objectives, according to another aspect of this application, an electronic device is provided, the electronic device including a memory storing an executable program; and a processor for running the program, wherein the program executes the above-described blockchain-based request processing method during runtime.

[0017] To achieve the above objectives, according to another aspect of this application, a computer program product is provided, including computer instructions that, when executed by a processor, implement the steps of the blockchain-based request processing method described above.

[0018] In this embodiment, by setting the identity chain as a blockchain for storing identity documents, the public key of the authentication node no longer needs to be hard-coded in the target chain contract. When the authentication node in the cross-chain gateway node cluster changes, the identity document in the identity chain is updated. When a cross-chain operation request is generated, the target blockchain performs compliance verification on the cross-chain proof corresponding to the cross-chain operation request based on the identity document in the identity chain. This achieves that when a node rotates its key or is added / removed, only the identity document on the identity chain needs to be updated. When the target chain verifies the cross-chain proof, it dynamically obtains the latest public key through the identity chain without redeploying or upgrading the smart contract on each target chain. This helps to achieve seamless key rotation and improve the reliability of cross-chain operations.

[0019] Therefore, the method provided in this application achieves the goal of maintaining the public key information of the authentication node through an identity chain independent of the target chain, thereby improving the reliability of cross-chain operations. It solves the technical problem that in cross-chain scenarios, when the authentication node's public key information is directly registered to the target chain, the information needs to be redeployed on the target chain when the authentication node changes, thus affecting the reliability of cross-chain operations. Attached Figure Description

[0020] The accompanying drawings, which form part of this application, are used to provide a further understanding of this application. The illustrative embodiments and descriptions of this application are used to explain this application and do not constitute an undue limitation of this application. In the drawings:

[0021] Figure 1 This is a hardware structure block diagram of a computer terminal provided according to an embodiment of this application;

[0022] Figure 2 This is a flowchart of a blockchain request processing method provided according to an embodiment of this application;

[0023] Figure 3 This is a schematic diagram of the operation of a blockchain request processing system provided according to an embodiment of this application;

[0024] Figure 4 This is a schematic diagram of a blockchain request processing apparatus provided according to an embodiment of this application;

[0025] Figure 5 This is a structural block diagram of an electronic device according to an embodiment of this application. Detailed Implementation

[0026] To enable those skilled in the art to better understand the present application, the technical solutions in the embodiments of the present application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present application, and not all embodiments. Based on the embodiments in the present application, all other embodiments obtained by those of ordinary skill in the art without creative effort should fall within the scope of protection of the present application.

[0027] It should be noted that the terms "first," "second," etc., in the specification, claims, and accompanying drawings of this application are used to distinguish similar objects and are not necessarily used to describe a specific order or sequence. It should be understood that such data can be interchanged where appropriate so that the embodiments of this application described herein can be implemented in orders other than those illustrated or described herein. Furthermore, the terms "comprising" and "having," and any variations thereof, are intended to cover non-exclusive inclusion; for example, a process, method, system, product, or apparatus that comprises a series of steps or units is not necessarily limited to those steps or units explicitly listed, but may include other steps or units not explicitly listed or inherent to such processes, methods, products, or apparatus.

[0028] It should be noted that the information collected in this application (including but not limited to user device information, user personal information, etc.) and data (including but not limited to data used for display, data used for analysis, etc.) are information and data authorized by the user or fully authorized by all parties. Furthermore, the collection, storage, use, processing, transmission, provision, disclosure, and application of this data all comply with relevant regulations and standards, necessary confidentiality measures have been taken, and they do not violate public order and good morals. Corresponding operation entry points are provided for users to choose to authorize or refuse. For example, interfaces are set up between this system and relevant users or organizations, providing users with corresponding operation entry points for them to choose to agree to or refuse automated decision results; if the user chooses to refuse, the process proceeds to the expert decision-making stage.

[0029] Example 1

[0030] According to an embodiment of this application, an embodiment of a blockchain-based request processing method is also provided. It should be noted that the steps shown in the flowchart in the accompanying drawings can be executed in a computer system such as a set of computer-executable instructions. Furthermore, although a logical order is shown in the flowchart, in some cases, the steps shown or described may be executed in a different order than that shown here.

[0031] The method embodiment provided in Embodiment 1 of this application can be executed on a mobile terminal, computer terminal, or similar computing device. Figure 1 A hardware structure block diagram of a computer terminal (or mobile device) for implementing a blockchain-based request processing method is shown. Figure 1As shown, the computer terminal 10 (or mobile device) may include one or more processors 102 (shown as 102a, 102b, ..., 102n in the figure) 102 (processor 102 may include, but is not limited to, a microprocessor (MCU) or a field-programmable gate array (FPGA), etc.), a memory 104 for storing data, and a transmission device 106 for communication functions. In addition, it may also include: a display, an input / output (I / O) interface, a Universal Serial Bus (USB) port (which may be included as one of the ports of a BUS bus), a network interface, a power supply, and / or a camera. Those skilled in the art will understand that... Figure 1 The structure shown is for illustrative purposes only and does not limit the structure of the aforementioned electronic device. For example, computer terminal 10 may also include... Figure 1 The more or fewer components shown, or having the same Figure 1 The different configurations shown.

[0032] It should be noted that the aforementioned one or more processors 102 and / or other data processing circuits are generally referred to herein as "data processing circuits". These data processing circuits may be embodied, in whole or in part, in software, hardware, firmware, or any other combination thereof. Furthermore, the data processing circuits may be a single, independent processing module, or may be integrated, in whole or in part, into any other element within the computer terminal 10 (or mobile device). As involved in the embodiments of this application, the data processing circuits serve as a processor control mechanism (e.g., selection of a variable resistor termination path connected to an interface).

[0033] The memory 104 can be used to store software programs and modules of application software, such as the program instructions / data storage device corresponding to the blockchain-based request processing method in this embodiment. The processor 102 executes various functional applications and data processing by running the software programs and modules stored in the memory 104, thereby realizing the aforementioned blockchain-based request processing method. The memory 104 may include high-speed random access memory, and may also include non-volatile memory, such as one or more magnetic storage devices, flash memory, or other non-volatile solid-state memory. In some instances, the memory 104 may further include memory remotely located relative to the processor 102, and these remote memories can be connected to the computer terminal 10 via a network. Examples of such networks include, but are not limited to, the Internet, corporate intranets, local area networks, mobile communication networks, and combinations thereof.

[0034] The transmission device 106 is used to receive or send data via a network. Specific examples of the network described above may include a wireless network provided by the communication provider of the computer terminal 10. In one example, the transmission device 106 includes a Network Interface Controller (NIC), which can connect to other network devices via a base station to communicate with the Internet. In another example, the transmission device 106 may be a Radio Frequency (RF) module, used for wireless communication with the Internet.

[0035] The display can be, for example, a touchscreen liquid crystal display (LCD), which allows the user to interact with the user interface of the computer terminal 10 (or mobile device).

[0036] Under the aforementioned operating environment, this application provides the following: Figure 2 The blockchain-based request processing method is shown. Figure 2 This is a flowchart of a blockchain-based request processing method according to Embodiment 1 of this application.

[0037] Step S201: In the event of a change in the authentication node in the cross-chain gateway node cluster, the identity document in the identity chain is updated based on the identity document of the changed authentication node. The identity document is used to describe the public key information of the authentication node, and the identity chain is a blockchain used to store the identity document.

[0038] Optionally, electronic devices, application systems, servers, and other similar devices can be used as the executing entity of this application. In this embodiment, a blockchain-based request processing system is used as the executing entity to execute the aforementioned blockchain-based request processing method. Hereinafter, the blockchain-based request processing system may be simply referred to as the system.

[0039] In some implementations, the system includes a cross-chain gateway node cluster, which comprises multiple authentication nodes, also known as notary nodes. Changes to authentication nodes include: adding authentication nodes, deleting authentication nodes, and modifying the identity documents of authentication nodes.

[0040] An identity document for an authentication node describes the node's public key information. The identity document includes at least the node's public key. In some implementations, the identity document includes a verification method set, a service endpoint set, an authentication reference, and an assertion method reference, used to parse the node's currently valid public key and service information. The verification method set is a collection of one or more verification method entries, each including a verification entry identifier, public key type, public key encoding format, and public key value. The service endpoint set refers to the node's application programming interface address and peer-to-peer network address, used for external service discovery and communication. The authentication reference references the key identifier used for node authentication within the verification method set. The assertion method reference references the key identifier used for cross-chain proof signatures within the verification method set.

[0041] When an authentication node changes within the cross-chain gateway node cluster, the identity document in the identity chain is updated based on the identity document of the changed authentication node. In some implementations, the aforementioned update operation may be one of the following: registering the identity document to the identity chain, deregistering the identity document from the identity chain, or updating the identity document in the identity chain. For example, when an authentication node changes, the changed authentication node may send a relevant update request to the identity chain, and upon receiving the relevant update request, the identity chain will perform the corresponding update operation on the identity document in the identity chain.

[0042] For example, Figure 3 This is a schematic diagram of the operation of a blockchain request processing system provided in the embodiments of this application. Figure 3 This embodiment describes an optional architecture for a blockchain-based request processing system. For example... Figure 3 As shown, a blockchain-based request processing system may include a cross-chain gateway node cluster, an identity chain, an identity resolution service, a cross-chain proof generation module, and a management entity (i.e., a target management module).

[0043] Among them, such as Figure 3 As shown, the cross-chain gateway node cluster includes multiple notary nodes (i.e., authentication nodes); the identity chain includes an identity registration contract, a credential registration / revocation contract, and a compliant public key set digest / historical version repository; the management entity includes a credential issuance module and an audit / revocation module.

[0044] like Figure 3 As shown, this application overlays identity and authorization processing steps onto the event signing-multi-signature aggregation-target chain verification chain, with the following process:

[0045] (1) Identity registration: The notary node generates a key pair and creates a notary node identifier and identity document accordingly, submits it to the identity registration contract, verifies that it holds the private key corresponding to the declared public key and stores it, and includes the public key in the compliant public key set and recalculates the set digest;

[0046] (2) Public key set synchronization: The cross-chain gateway configuration synchronization mechanism pushes the updated public key set digest to the target chain verification contract in all target chains;

[0047] (3) Authorization Issuance: After review by the management entity, cross-chain operation authorization certificates are issued to the notary nodes and stored in the local certificate repository and certificate registration contract.

[0048] The aforementioned steps (1)-(3) are the steps that the notary node needs to perform before signing the cross-chain operation request.

[0049] Step S202: Upon receiving a cross-chain operation request from the source blockchain, the cross-chain operation request is signed by multiple authentication nodes in the cross-chain gateway node cluster to obtain a cross-chain proof. The cross-chain operation request is used to request the target blockchain to perform the target operation.

[0050] The aforementioned source blockchain can be simply referred to as the source chain, and the target blockchain can be simply referred to as the target chain.

[0051] In some implementations, cross-chain operation requests originate from events or transaction data on the source chain and are intended to trigger business logic on the target chain. After receiving an external cross-chain operation request, the cross-chain gateway node cluster independently signs the request content and aggregates these signatures to form a cross-chain proof that demonstrates the consensus of the entire cluster.

[0052] For example, the steps to generate a cross-connect proof are as follows:

[0053] (1) Event Signature: In response to the cross-chain operation request of the source blockchain, each notary node signs the request content with the private key in the key pair. The signature entry is accompanied by the node identifier of the signer and the verification entry identifier (instead of the bare public key), and can also carry the authorization certificate hash reference.

[0054] (2) Multi-signature aggregation: The aggregation of master nodes in the cross-chain gateway node cluster reaches the Byzantine fault tolerance threshold. The signature, n, is the total number of notary nodes. The cross-chain proof is obtained by assembling the signature by the cross-chain proof generation module. The aforementioned master node is elected from multiple notary nodes. Correspondingly, the nodes other than the master node among the multiple notary nodes can be called slave nodes.

[0055] Step S203: The cross-chain proof is sent to the target blockchain, where the target blockchain performs compliance verification on the cross-chain proof based on the identity document in the identity chain. If the compliance verification is successful, the target blockchain executes the target operation.

[0056] In some implementations, the target blockchain refers to the blockchain that receives the cross-chain operation request and executes the final state change. After receiving the cross-chain proof, the target blockchain queries the identity document on the identity chain based on the node identifier in the cross-chain proof, then verifies the signer's identity compliance based on the identity document. If the verification passes, it executes the target operation requested by the cross-chain operation request. The content of the target operation corresponds to specific business logic, such as a fund transfer, and therefore is not specifically limited here.

[0057] For example, the target blockchain verification contract includes an identifier resolution / public key acquisition unit, a public key set verification unit, a multi-signature verification unit, a credential authorization check unit, and a business execution unit. After the target blockchain obtains the cross-chain proof, it can perform the following steps:

[0058] (1) Target chain verification: The target chain verification contract obtains the signer's public key through the identifier resolution / public key acquisition unit, and the public key set verification unit and multi-signature verification unit verify the signature and Byzantine fault tolerance threshold.

[0059] (2) Business execution: After verification, the business execution unit calls the target business contract in the target chain to execute the target operation; if any step fails, it will be rejected and the reason for failure will be returned.

[0060] In some implementations, the following verification may also be performed before step (2):

[0061] Authorization check: The credential authorization check unit verifies that the authorization credential signature is valid, not expired, not revoked, and that the current operation (target chain / contract / method) is within the authorized scope.

[0062] For example, in this application, the blockchain request processing system, based on the cross-chain gateway node cluster, introduces a decentralized identity standard to achieve unified identification and management of notary node identities. The cross-chain notary identity management and identity-aware proof based on decentralized identity can be seen in the following example:

[0063] like Figure 3 As shown, the decentralized identity generation module is deployed in the notary node. This module, also known as the identifier generation / document management module, is configured to generate a node identifier and identity document conforming to the decentralized identity standard for each node in response to the notary node initialization. This includes:

[0064] (1) Node identifier: also known as node identifier, can be in the format did:crosschain:<method-specific identifier>. This identifier can be generated based on the cryptographic hash of the node's initial public key, and is globally unique and cannot be forged.

[0065] (2) Identity Document: Contains the following core fields: Identifier field (used to record node identifier); Verification method set (one or more verification method entries, each entry containing verification entry identifier, public key type, public key encoding format and public key value); Server endpoint set (application programming interface address and peer-to-peer network address of the notary node, used for external services to discover the node and communicate with it); Authentication reference (refers to the key identifier used for node identity authentication in the verification method set); Assertion method reference (refers to the key identifier used for cross-chain proof signature in the verification method set).

[0066] (3) Identity document version number: incremented each time the document is updated, used for version consistency verification during multi-chain synchronization.

[0067] like Figure 3 As shown, the blockchain-based request processing system also includes an identity resolution service, and the identity registration contract handles identity document registration, querying, and version resolution.

[0068] (1) On-chain registration path: The notary node writes the complete content of the identity document or its cryptographic hash into the identity registration contract. The identity registration contract maintains the mapping relationship between node identifiers and identity documents and records the historical versions of the documents;

[0069] (2) Off-chain resolution path: The identity resolution service provides an identity resolution service interface, which queries the identity registration contract based on the node identifier and returns the complete identity document; the identity resolution service supports querying a specified version, which is used to obtain public key information at a historical moment in audit and traceability scenarios;

[0070] (3) Compliant public key set maintenance: The identity registration contract additionally maintains the public key aggregation set of all currently valid notary nodes (stored in the form of Merkle tree or ordered list), and automatically recalculates the public key set digest in response to any change in the identity document of any node (addition, removal of public key or cancellation of node).

[0071] like Figure 3 As shown, the notary node may also include at least a local signature module for signing and at least a credential holding module for storing authorization credentials.

[0072] like Figure 3As shown, the blockchain-based request processing system includes a cross-chain proof generation module, which is used to generate cross-chain proofs. In the signature list of the cross-chain proof, each signature entry contains: the signer's node identifier, the entry identifier used by the signer, and the signature value. The signature entry no longer contains the raw public key; the target chain verification contract obtains the signer's currently valid public key through parsing the node identifier and entry identifier for signature verification. The proof identifier of the cross-chain proof is deterministically generated based on the signer's node identifier list and the cross-chain call payload, ensuring consistency of the proof identifier across nodes.

[0073] like Figure 3 As shown, the blockchain-based request processing system includes a target chain verification contract. This contract is deployed on the target blockchain, replacing the hard-coded public key list verification logic in related technologies, and invoking the target business contract after successful verification.

[0074] (1) Public key set management: The verification contract maintains a compliant public key set digest (Merkel root or public key list hash) that is configured and synchronized, rather than a list of public keys that are hard-coded one by one;

[0075] (2) Signature verification process: In response to receiving cross-chain proof, perform the following for each signature entry: (a) query the local cache based on the node identifier or obtain the signer's public key through the identity resolution service; (b) verify that the public key belongs to the compliant public key set; (c) verify the validity of the signature value; (d) count whether the number of valid signatures reaches the Byzantine fault tolerance threshold.

[0076] (3) Downgrade compatibility mode: In response to the unavailability of the identity resolution service or the absence of identity caching in the target chain, it supports falling back to the bare public key verification mode in the relevant technology.

[0077] For example, the complete process of decentralized identity management includes the following steps:

[0078] (1) When the notary node A is started for the first time, the decentralized identity generation module generates the node identifier did:crosschain:A and the corresponding identity document based on the node's elliptic curve public key;

[0079] (2) Node A submits the identity document to the identity registration contract for registration. The contract verifies that the submitter holds the private key corresponding to the public key declared in the document (through signature verification) and then stores the document.

[0080] (3) The compliant public key set is automatically updated by adding the public key of node A to the set and recalculating the set digest;

[0081] (4) Configure a synchronization mechanism to push the updated public key set digest to all target chain verification contracts;

[0082] (5) In response to the cross-chain operation request of the source blockchain, each notary node signs the event, and the signature entry is accompanied by the node identifier of the signer and the entry identifier;

[0083] (6) After the master node aggregates signatures that reach the Byzantine fault tolerance threshold, the cross-chain proof generation module assembles a cross-chain proof containing the node identifier.

[0084] (7) The target chain verification contract receives the cross-chain proof, obtains the signer's public key through the identity resolution service, and executes the target operation after verifying the validity of the signature and meeting the threshold.

[0085] In this embodiment, by setting the identity chain as a blockchain for storing identity documents, the public key of the authentication node no longer needs to be hard-coded in the target chain contract. When the authentication node in the cross-chain gateway node cluster changes, the identity document in the identity chain is updated. When a cross-chain operation request is generated, the target blockchain performs compliance verification on the cross-chain proof corresponding to the cross-chain operation request based on the identity document in the identity chain. This achieves that when a node rotates its key or is added / removed, only the identity document on the identity chain needs to be updated. When the target chain verifies the cross-chain proof, it dynamically obtains the latest public key through the identity chain without redeploying or upgrading the smart contract on each target chain. This helps to achieve seamless key rotation and improve the reliability of cross-chain operations.

[0086] Therefore, the method provided in this application achieves the goal of maintaining the public key information of the authentication node through an identity chain independent of the target chain, thereby improving the reliability of cross-chain operations. It solves the technical problem that in cross-chain scenarios, when the authentication node's public key information is directly registered to the target chain, the information needs to be redeployed on the target chain when the authentication node changes, thus affecting the reliability of cross-chain operations.

[0087] Optionally, in the blockchain-based request processing method provided in this application embodiment, the identity document in the identity chain is updated based on the identity document of the changed authentication node, including: if the changed authentication node is a newly added authentication node, registering the identity document of the changed authentication node to the identity chain; if the changed authentication node is a deleted authentication node, deregistering the identity document of the changed authentication node from the identity chain; and if the changed authentication node is an authentication node whose identity document has changed, updating the target identity document in the identity chain, wherein the target identity document refers to the identity document of the changed authentication node.

[0088] A newly added authentication node refers to an authentication node newly added to the cross-chain gateway node cluster. When the changed authentication node is a newly added node, its identity document is registered to the identity chain. For example, a newly added notary node B generates a key pair locally and creates a globally unique node identifier (format:did:crosschain:B) and corresponding identity document. This identity document contains nodes B's initial public key, address, and other fields. Node B uses its private key to sign key fields in the identity document to prove it holds the private key. Node B submits the identity document containing the aforementioned signature information to the identity chain through the identity registration contract. The identity registration contract verifies the validity of the signature submitted by node B. After successful verification, node B's identity document is stored on the chain, and node B's public key is added to the compliant public key set, and the compliant public key set digest is recalculated. The master node pushes the updated public key set digest to all slave nodes and the target chain verification contract through a configured synchronization mechanism.

[0089] A deleted authentication node refers to an authentication node that has exited the cross-chain gateway node cluster. When the changed authentication node is a deleted authentication node, the identity document of the changed authentication node is deregistered from the identity chain. For example, before deregistering the identity, the management entity first revokes all verifiable credentials held by the exiting node through the credential revocation module and adds its unique identifier to the credential revocation list. The system waits for all cross-chain transactions (i.e., transactions corresponding to cross-chain operation requests) that the node participated in signing to reach their final state, ensuring that there are no incomplete distributed transactions. The exiting node signs the identity document deregistration transaction using its currently valid private key. This transaction is submitted to the identity registration contract, which marks the node's identity document as deregistered, removes its public key from the compliant public key set, and recalculates the compliant public key set digest. The master node pushes the changes to the public key set (removal of the node's public key) and the changes to the revocation list to all target chain verification contracts through a configured synchronization mechanism.

[0090] An authentication node whose identity document changes refers to a node whose identity information needs to be updated. For example, when an authentication node changes its key, its identity document changes. In some implementations, when a notary node needs to change its signing key, the system does not directly modify the contract on the target chain, but instead updates the identity document on the identity chain. By retaining the coexistence of the old and new public keys (transition period), service continuity is achieved during key rotation.

[0091] In some implementations, a dynamic admission and exit mechanism for authentication nodes based on identity chain registration and configuration synchronization allows new nodes to join the cluster and participate in signing by registering their identity and issuing credentials, while exiting nodes can securely exit by revoking their credentials and canceling their identity. The entire process requires no redeployment or upgrade of the verification contract on the target chain. Decentralized identity separates the authentication identity from the fixed public key. When a node rotates its key, it only needs to update the identity document on the identity chain and push the public key set digest to the target chain verification contract through configuration synchronization. This eliminates the need to redeploy or upgrade the verification contract on each target chain, reducing key management costs and upgrade window risks.

[0092] It should be noted that, through the above methods, this application supports the dynamic addition (registration), exit (cancellation), and key change of authentication nodes, enabling the cross-chain gateway node cluster to flexibly adjust the member size according to business needs without redeploying any smart contracts on the target chain, thereby helping to reduce operational complexity and improve the reliability of cross-chain operations.

[0093] Optionally, in the blockchain-based request processing method provided in this application embodiment, before updating the target identity document in the identity chain, the method further includes: for the target identity document held by the changed authentication node, adding a verification method entry corresponding to the new public key to the target identity document, and retaining the verification method entry corresponding to the old public key, wherein the verification method entry includes a public key type, a public key encoding format, a public key value, and an entry identifier; updating the field value of the first reference field in the target identity document to the entry identifier corresponding to the new public key, wherein the first reference is used to represent the public key information used when signing the cross-chain operation request.

[0094] In some implementations, the identity document of the authentication node that has undergone the change is identified as the target identity document. When updating the target identity document, the verification method entry corresponding to the new key is added as a new verification method entry, while the original verification method entry for the old key is retained.

[0095] In some implementations, the first reference field, also known as the assertion method reference described above, is used to reference the key identifier used for cross-chain proof signatures in the verification method set. The value of the first reference field in the target identity document is updated to the entry identifier corresponding to the new public key, thereby updating the assertion method reference from pointing to the entry identifier of the old public key to pointing to the entry identifier of the new public key.

[0096] It should be noted that by retaining old entries and adding new entries in the target identity document, combined with the update of assertion method references, the parallel existence of old and new keys is achieved. During the transition period, the system can both verify legacy transactions signed using the old key and begin signing new transactions using the new key. This helps to solve the technical bottleneck in related technologies where key rotation requires system downtime or contract upgrades, thus improving the reliability of cross-chain operations.

[0097] Optionally, in the blockchain-based request processing method provided in this application embodiment, updating the target identity document in the identity chain includes: updating the target identity document held by the changed authentication node to the identity chain; after updating the target identity document held by the changed authentication node to the identity chain, the method further includes: determining the time point at which the target identity document held by the changed authentication node is updated to the identity chain as the target time point; after the target time interval of the target time point, removing the verification method entry corresponding to the old public key from the target identity document for the target identity document held by the changed authentication node.

[0098] In some implementations, the authentication node that has undergone the change first updates the target identity document locally, and after the local update is complete, it updates the target identity document it holds to the identity chain.

[0099] After updating the target identity document held by the changed authentication node to the identity chain, the changed authentication node can listen to the transaction receipt returned by the identity registration contract to confirm that the target identity document has been successfully written to the identity chain, obtain the block timestamp (or block height) of the transaction, mark it as the target time point, and then determine the time interval between the current time point and the target time point through a timer. Therefore, after the target time interval from the target time point, for the target identity document held by the changed authentication node, the verification method entry corresponding to the old public key is removed from the target identity document.

[0100] For example, combined Figure 3 This application describes the seamless key rotation and multi-chain synchronization based on multiple authentication method entries in identity documents:

[0101] like Figure 3 As shown, the authentication node in the blockchain-based request processing system includes a key rotation module. This module is configured to support key updates for notary nodes without interrupting cross-chain services, and includes:

[0102] Key generation submodule: In response to key rotation trigger conditions (periodic rotation, security event trigger, or manual trigger), the node locally generates a new elliptic curve key pair;

[0103] Identity Document Update Submodule: Adds the verification method entry corresponding to the new public key to the verification method set of the current identity document, while retaining the verification method entry of the old public key; updates the assertion method reference to the verification entry identifier pointing to the new public key, indicating that subsequent cross-chain signatures will use the new key; the update transaction used to send to the identity chain is signed with the old key to prove the continuity of the document holder's identity;

[0104] Transition Period Management Submodule: Configured to maintain a configurable key transition period (i.e., target time interval). During the transition period, the identity document contains both old and new valid verification method entries. Cross-chain proofs signed using the old key can still be verified. After the transition period ends, nodes submit new identity document update transactions to remove the verification method entries of the old public key.

[0105] Rotation Status Tracking Submodule: Maintains the key rotation state machine (awaiting rotation - new key added - configuration synchronized - in transition - old key removed - rotation complete), used to track rotation progress and handle interruption recovery.

[0106] The authentication node in the blockchain-based request processing system includes a multi-chain public key set synchronization module. This module is configured to synchronize public key set changes caused by key rotation to all target chains, reusing the existing configuration synchronization mechanism of the cross-chain gateway.

[0107] (1) Push path: In response to the change of the public key set in the identity registration contract, the master node publishes a digitally signed public key set synchronization message through a dedicated broadcast topic. The message carries the operation type (public key addition or public key removal), the node identifier of the affected node, the updated public key set digest and the synchronization version number; after the slave node verifies the signature and the node compliance list, it updates the local public key set cache in a monotonically increasing order of version.

[0108] (2) Pull path: The slave node compares the public key set digest of the local node with that of the master node through the internal interface at configurable time intervals. When an inconsistency is detected, it pulls a snapshot of the complete public key set and updates the local cache.

[0109] (3) Target chain contract update: In response to the change of public key set, the master node writes the updated public key set digest into the verification contract of each target chain through cross-chain call. The update operation itself is protected by the currently valid Byzantine fault-tolerant multisignature to ensure the compliance of the public key set update.

[0110] Blockchain-based request processing systems can also be used to implement the following mechanisms to handle signature verification issues that may arise during cross-chain transactions being executed in the course of key rotation:

[0111] (1) Transaction-level key binding: Each cross-chain transaction records the version number of the public key set at the time of creation, and the same public key set version is used for signing and verification throughout the entire phase of the transaction;

[0112] (2) When the target chain verification contract verifies the signature, in response to the inconsistency between the current public key set version and the version marked in the proof, it checks whether the signer's public key exists in any valid version during the transition period, so as to avoid the failure of the ongoing transaction verification due to the update of the public key set.

[0113] (3) Rotation window protection: The key rotation operation is executed first when there is no Try phase transaction being executed on the master node, and is delayed until the current transaction batch is completed if there is an ongoing transaction.

[0114] The complete process of seamless key rotation may include the following steps:

[0115] (1) When the key rotation timer of notary node A expires, the key generation submodule generates a new elliptic curve key pair (new public key PKnew, new private key SKnew).

[0116] (2) Node A uses the old private key SKold to sign the identity document update transaction, sends the update transaction to the identity chain, adds the new verification method entry corresponding to PKnew to the verification method set, and updates the assertion method reference to the new verification entry identifier;

[0117] (3) The updated identity document is written into the identity registration contract, the contract updates the public key set, incorporates PKnew into the compliant public key set and recalculates the digest;

[0118] (4) The master node broadcasts the public key set change (adding PKnew) to all slave nodes and the target chain verification contract by configuring the synchronous push path;

[0119] (5) During the transition period, the identity resolution service returns an identity document containing two valid public keys, PKold and PKnew, to the target chain. Node A uses PKnew to sign a new cross-chain proof, and the incomplete transactions previously signed using PKold can still be verified.

[0120] (6) After the transition period ends, node A uses SKnew to sign the identity document to update the transaction and sends the updated transaction to the identity chain to remove the verification method entry of PKold;

[0121] (7) The contract updates the public key set, removes PKold and recalculates the digest;

[0122] (8) The master node broadcasts the change of the public key set (removal of PKold) to all slave nodes and the target chain verification contract by configuring the synchronous push path, thus completing the key rotation.

[0123] It should be noted that, through the above method, the old and new public keys coexist in the verification method set of the identity document during the transition period. By using the existing configuration synchronization mechanism (a combination of push and pull) of the cross-chain gateway, the public key set is updated and pushed to all target chain verification contracts. This ensures that cross-chain services are not interrupted during the key rotation period and that contracts do not need to be redeployed, thereby improving the reliability of cross-chain operations.

[0124] Optionally, in the blockchain-based request processing method provided in this application embodiment, the cross-chain operation request is signed by multiple authentication nodes in the cross-chain gateway node cluster to obtain a cross-chain proof. This includes: for each authentication node, signing the cross-chain operation request using the authentication node's private key to obtain a signature value; generating a signature entry for the authentication node based on the signature value corresponding to the authentication node, the node identifier of the authentication node, the entry identifier corresponding to the authentication node, and the hash value of the authorization credential of the authentication node, wherein the identity document records a verification method entry, which includes a public key type, a public key encoding format, a public key value, and an entry identifier, and the authorization credential is issued to the authentication node by the target management module; and determining the cross-chain proof based on the generated signature entries when the number of signature entries is greater than or equal to a preset number.

[0125] In some implementations, the authentication node receives cross-chain operation requests via a peer-to-peer network or message queue. The authentication node uses its currently valid private key to sign the request content of the cross-chain operation request, obtaining a signature value.

[0126] After obtaining the signature value, a signature entry for the authentication node is generated based on the signature value corresponding to the authentication node, the node identifier of the authentication node, the entry identifier corresponding to the authentication node, and the hash value of the authorization credential of the authentication node. The authorization credential hash value is the hash value of the authorization credential held by the authentication node, which is issued to the authentication node by the target management module. The authorization credential can include authorization scopes at the chain level, contract level, and method level.

[0127] If the number of signature entries is greater than or equal to a preset number, the generated signature entries are combined to obtain a cross-chain proof. The aforementioned preset number may refer to the Byzantine fault tolerance threshold.

[0128] It's worth noting that by embedding node and entry identifiers into the signature entry, the target chain doesn't need to hardcode the public key list; instead, it can dynamically obtain the valid public key by parsing the identity document. By embedding the authorization credential hash value into the signature entry, the target chain can verify the node's operational permissions while verifying the signature, thereby further improving the reliability of cross-chain operations.

[0129] Optionally, in the blockchain-based request processing method provided in this application embodiment, compliance verification of cross-chain proof based on identity documents in the identity chain includes: validating the signature value in the cross-chain proof based on the identity documents in the identity chain; validating the authorization credential hash value if the signature value is valid, wherein the authorization credential is issued to the authentication node by the target management module; validating the cross-chain operation request within the authorization scope of the authorization credential if the authorization credential hash value is valid; validating the compliance verification if the cross-chain operation request is within the authorization scope; and validating the compliance verification if the signature value is invalid, the authorization credential hash value is invalid, or the cross-chain operation request is outside the authorization scope.

[0130] In some implementations, the signature value in the cross-chain proof is validated based on the identity document in the identity chain. For example, the target chain extracts the node identifier and entry identifier from the signature entries of the cross-chain proof; the target chain verification contract queries the identity registration contract on the identity chain through the identity resolution service to obtain the identity document corresponding to the node identifier. Based on the entry identifier, the corresponding public key value is extracted from the verification method set of the document. The target chain uses the extracted public key to perform a signature verification algorithm operation on the signature value. Simultaneously, it checks whether the public key exists in the currently synchronized compliant public key set digest. If the signature verification is successful and the public key is in the compliant public key set digest, the signature value validity authentication is deemed successful; otherwise, it is deemed unsuccessful.

[0131] In some implementations, after the signature value passes validity authentication, the authorization credential hash value is then validated, where the authorization credential is issued by the target management module to the authentication node. For example, the target chain verifies the validity of the authorization credential corresponding to the authorization credential hash value based on the public key of the management entity.

[0132] If the validity of the authorization credential hash value is verified, the cross-chain operation request is verified to be within the authorization scope of the authorization credential. In some implementations, the authorization credential corresponds to an authorization scope, which refers to the specific operation boundaries allowed for the signed cross-chain operation request. For example, the authorization scope includes a list of allowed source chains, a list of allowed target chains, a list of allowed contracts, a list of allowed methods, and an optional maximum transaction amount. The cross-chain operation request includes the specific context of the target operation to be executed, such as the source chain identifier, target chain identifier, target contract address, target method name, and transaction amount. After determining the authorization scope of the authorization credential, the cross-chain operation request is verified to be within the authorization scope of the authorization credential. For example, it checks whether the target chain identifier is in the list of allowed target chains, whether the target contract identifier is in the list of allowed contracts, whether the target method identifier is in the list of allowed methods, and whether the transaction amount is less than the maximum transaction amount. If all matches conform to the authorization scope, the cross-chain operation request is determined to be within the authorization scope; if any match occurs (such as attempting to call an unauthorized method), it is determined to be outside the authorization scope.

[0133] In some implementations, compliance verification is determined to be successful if the cross-chain operation request is within the authorized scope; compliance verification is determined to be unsuccessful if the validity of the signature value fails to pass, or the validity of the authorization credential hash value fails to pass, or the cross-chain operation request is outside the authorized scope.

[0134] For example, combined Figure 3 This application provides an exemplary illustration of fine-grained authorization for cross-chain operations based on verifiable credentials and dynamic access for notaries:

[0135] The management entity includes a credential issuance module, used to issue cross-chain operation authorization credentials to notary nodes:

[0136] (1) Definition of certificate type: Cross-chain operation authorization certificate, which includes the following declarations: Holder identifier (the node identifier of the authorized notary node); Allowed source chain list (the list of source blockchain identifiers that allow the node to listen to events); Allowed target chain list (the list of target blockchain identifiers that allow the node to participate in signing); Allowed contract list (the list of target contract identifiers that are allowed to be called, supporting wildcard matching); Allowed method list (the list of target method identifiers that are allowed to be called, supporting wildcard matching); Maximum transaction amount (the upper limit of the amount of a single cross-chain transaction, an optional field, if not set, it means there is no limit); Validity start time and validity end time; Certificate unique identifier (used for precise location when the certificate is revoked).

[0137] (2) Credential signing: The management entity uses its private key to sign the credential content;

[0138] (3) Certificate storage: The issued certificate is stored simultaneously in the local certificate repository of the holder node (i.e., the authentication node) and in the certificate registration contract on the identity chain.

[0139] The target chain's target chain verification contract includes a credential verification module (i.e., a credential authorization check unit), which is configured to add an authorization check to the cross-chain proof verification process:

[0140] (1) The cross-chain proof includes a hash reference of the signer’s authorization certificate (instead of the complete certificate, to reduce the amount of on-chain data).

[0141] (2) After the target chain verification contract responds to the Byzantine fault-tolerant multisignature verification, it performs the following additional authorization checks: verify the validity of the credential signature (parse the entity identifier of the management entity to obtain the public key of the management entity, and verify the signature on the credential); verify that the credential has not expired (the start time of the validity period ≤ the timestamp of the current block ≤ the end time of the validity period); verify that the credential has not been revoked (query the credential revocation list and confirm that the unique identifier of the credential is not in the revocation list); verify that the current operation is within the authorized scope (the target chain identifier matches the list of allowed target chains, the target contract identifier matches the list of allowed contracts, and the target method identifier matches the list of allowed methods, all of which include wildcard matching).

[0142] (3) In response to the failure of the authorization check, refuse to perform the cross-chain operation and return an authorization failure error code containing the specific reason for the failure.

[0143] The management entity also includes an audit / revocation module, and the identity chain includes a credential registration / revocation contract. The audit / revocation module and the credential registration / revocation contract are configured to support the immediate revocation of authorized credentials: the credential revocation list is maintained in a smart contract on the identity chain, recording the set of unique identifiers of revoked credentials; it supports two granularities: revoking a single credential by its unique identifier or revoking all credentials of a node by its node identifier; the revocation operation is signed by the management entity's private key, and the revocation list contract is updated after verifying the operator's identity; changes to the revocation list are pushed to the verification contracts of each target chain through a configuration synchronization mechanism, achieving cross-chain immediate credential invalidation.

[0144] In some implementations, the blockchain-based request processing method includes the following dynamic admission phase for notary nodes: identity creation phase (new nodes generate elliptic curve key pairs and node identifiers, creating identity documents); authorization issuance phase (the management entity reviews the qualifications of new nodes and issues authorization certificates); identity registration phase (new nodes register their identity documents to the identity registration contract, and the contract includes their public keys in the compliant public key set); cluster joining phase (joining the cluster through a peer-to-peer network node discovery mechanism and joining the election domain through a distributed consensus election protocol); multi-chain synchronization phase (the master node pushes the updated public key set digest to all target chain verification contracts through a configuration synchronization mechanism); after completing the above steps, new nodes can participate in signing and transaction coordination, and the entire process does not require redeployment or upgrading of verification contracts on any target chain.

[0145] In some implementations, blockchain-based request processing methods include the following notary node dynamic exit phase:

[0146] The process includes the following phases: Credential Revocation Phase (the management entity revokes all authorization credentials of the exiting node; in this embodiment, the exiting node is also the deleted authentication node); Transaction Completion Waiting Phase (waiting for all incomplete transactions signed by the exiting node to reach their final state); Identity Deregistration Phase (the exiting node uses its own private key to sign the identity document deregistration transaction, the identity registration contract marks its document as deregistered and removes its public key from the compliant public key set); Multi-Chain Synchronization Phase (the master node pushes the updated public key set digest and revocation list to all target chain verification contracts through a configured synchronization mechanism); Election Domain Exit Phase (the exiting node is removed from the distributed consensus election domain through a dynamic member management mechanism).

[0147] In some implementations, blockchain-based request processing methods include the following cross-chain audit tracing phases, configured to achieve audit capabilities based on node identifiers, historical version repositories of the identity chain, and cross-chain proofs: identity association query (using the node identifier in the proof to query the identity registration contract to obtain the signer's complete identity information); historical key backtracking (the identity registration contract stores historical versions of the identity document; during auditing, the set of valid public keys at the time of the operation is queried according to the operation timestamp to verify the compliance of historical signatures); authorization scope audit (using the credential registration contract to query the authorization credential held by the signer at the time of the operation to verify whether the historical operation was within the authorization scope); operation tracing chain (DID - identity document version at the time - public key and signature verification - authorization credential and operation scope verification - audit conclusion, forming a complete audit evidence chain).

[0148] In some implementations, the complete process of dynamic admission of notary nodes includes the following steps: (1) New notary node B generates an elliptic curve key pair and a node identifier did:crosschain:B, and creates an identity document; (2) The management entity reviews the qualifications of node B and issues it a cross-chain operation authorization certificate; (3) Node B registers the identity document to the identity registration contract, and the contract includes node B's public key in the compliant public key set and updates the digest; (4) Node B accesses the cluster peer-to-peer network through the bootstrap node list and broadcasts its own node information; (5) The master node pushes the updated public key set digest to all slave nodes and the target chain verification contract through the configuration synchronization mechanism; (6) Node B starts subscribing to source chain events and participating in cross-chain signing, and the target chain verification contract obtains node B's public key through identity resolution to complete the signature verification.

[0149] In some implementations, the complete process of fine-grained authorization verification includes the following steps: (1) The management entity issues an authorization certificate to notary node A, authorizing it to perform a cross-chain operation of method M of contract C from source chain S to target chain T; (2) In response to receiving a cross-chain event (i.e., a cross-chain operation request) on source chain S, node A verifies that the authorization certificate held locally covers the current cross-chain operation (source chain S is in the list of allowed source chains, target chain T is in the list of allowed target chains, contract C matches the list of allowed contracts, and method M matches the list of allowed methods); (3) Node A signs the event. The signature entry includes a node identifier and an authorization credential hash reference; (4) The master node aggregates signatures that reach the Byzantine fault tolerance threshold and then assembles the cross-chain proof; (5) The verification contract of the target chain T is executed: (a) Verify the validity of the signature and that the threshold is met; (b) Verify that the credential signature is valid; (c) Verify that the credential has not expired and has not been revoked; (d) Verify that the current cross-chain operation is within the scope of the credential authorization; (6) After all verifications are passed, the business operation (i.e. the target operation) is executed; In response to the revocation of the credential of node A or the operation exceeding the scope of authorization, the execution is refused and an authorization failure error code is returned.

[0150] It should be noted that the above methods effectively verify the compliance of cross-chain proofs. Furthermore, by verifying the hash value and scope of authorization credentials, fine-grained authorization (chain-level, contract-level, method-level) for cross-chain operations is achieved. Permissions are no longer static contract configurations, but rather dynamic, revocable, and traceable credentials, thereby enhancing the flexibility and security of cross-chain operations.

[0151] Optionally, in the blockchain-based request processing method provided in this application embodiment, the method further includes: authorizing and authenticating the authentication node through the target management module; issuing an authorization certificate to the authentication node through the target management module if the authorization authentication is successful; and storing the authorization certificate in the authentication node and the identity chain.

[0152] In some implementations, the blockchain-based request processing system includes a target management system, which can authorize and authenticate the authentication nodes after the authentication nodes join the cross-chain gateway node cluster. The target management system has preset authorization and authentication methods.

[0153] Once authorization and authentication are successful, the target management module issues authorization credentials to the authentication node. Subsequently, the target management module can store the authorization credentials in the authentication node and the identity chain.

[0154] It should be noted that the above methods enable effective authorization of authentication nodes and effective storage of authorization credentials, which helps to verify the scope of authorization at both the authentication node and target chain stages, thereby improving the reliability of cross-chain operations.

[0155] It should be noted that the steps shown in the flowchart in the accompanying drawings can be executed in a computer system such as a set of computer-executable instructions, and although a logical order is shown in the flowchart, in some cases the steps shown or described may be executed in a different order than that shown here.

[0156] Example 2

[0157] According to an embodiment of this application, a system for implementing the above-described blockchain-based request processing method is also provided, the system comprising:

[0158] The cross-chain gateway node cluster includes multiple authentication nodes. These authentication nodes are used to update the identity document in the identity chain based on the identity document of the changed authentication node when the authentication node in the cross-chain gateway node cluster changes. The identity document describes the public key information of the authentication node. When a cross-chain operation request is received from the source blockchain, the cross-chain operation request is signed by the multiple authentication nodes in the cross-chain gateway node cluster. The cross-chain operation request is used to request the target blockchain to perform the target operation.

[0159] Identity Chain: An identity chain is a blockchain used to store identity documents.

[0160] The cross-chain proof generation module is used to generate cross-chain proofs based on the signatures of cross-chain operation requests from multiple authentication nodes, and send the cross-chain proofs to the target blockchain. The target blockchain performs compliance verification on the cross-chain proofs based on the identity documents in the identity chain. If the compliance verification is successful, the target blockchain executes the target operation.

[0161] For example, Figure 3 This is a schematic diagram of the operation of a blockchain request processing system provided in the embodiments of this application, such as... Figure 3As shown, a blockchain-based request processing system may include a cross-chain gateway node cluster, an identity chain, an identity resolution service, a cross-chain proof generation module, and a management entity (i.e., a target management module). The cross-chain gateway node cluster includes multiple notary nodes (i.e., authentication nodes); the identity chain includes an identity registration contract, a credential registration / revocation contract, and a compliant public key set digest / historical version repository; the management entity includes a credential issuance module and an audit / revocation module.

[0162] Figure 3 The workflow between the various modules shown is as in Example 1, so it will not be repeated here.

[0163] In this embodiment, by setting the identity chain as a blockchain for storing identity documents, the public key of the authentication node no longer needs to be hard-coded in the target chain contract. When the authentication node in the cross-chain gateway node cluster changes, the identity document in the identity chain is updated. When a cross-chain operation request is generated, the target blockchain performs compliance verification on the cross-chain proof corresponding to the cross-chain operation request based on the identity document in the identity chain. This achieves that when a node rotates its key or is added / removed, only the identity document on the identity chain needs to be updated. When the target chain verifies the cross-chain proof, it dynamically obtains the latest public key through the identity chain without redeploying or upgrading the smart contract on each target chain. This helps to achieve seamless key rotation and improve the reliability of cross-chain operations.

[0164] Therefore, the method provided in this application achieves the goal of maintaining the public key information of the authentication node through an identity chain independent of the target chain, thereby improving the reliability of cross-chain operations. It solves the technical problem that in cross-chain scenarios, when the authentication node's public key information is directly registered to the target chain, the information needs to be redeployed on the target chain when the authentication node changes, thus affecting the reliability of cross-chain operations.

[0165] Example 3

[0166] This application also provides a blockchain-based request processing apparatus. It should be noted that the blockchain-based request processing apparatus of this application can be used to execute the blockchain-based request processing method provided in this application. The following describes the blockchain-based request processing apparatus provided in this application.

[0167] According to embodiments of this application, an apparatus for implementing the above-described blockchain-based request processing method is also provided, such as... Figure 4 As shown, the device includes:

[0168] The update module 401 is used to update the identity document in the identity chain based on the identity document of the changed authentication node when the authentication node in the cross-chain gateway node cluster changes. The identity document is used to describe the public key information of the authentication node, and the identity chain is a blockchain used to store the identity document.

[0169] The signature module 402 is used to sign the cross-chain operation request through multiple authentication nodes in the cross-chain gateway node cluster when a cross-chain operation request is received from the source blockchain, so as to obtain a cross-chain proof. The cross-chain operation request is used to request the target blockchain to perform the target operation.

[0170] The sending module 403 is used to send the cross-chain proof to the target blockchain, wherein the target blockchain performs compliance verification on the cross-chain proof based on the identity document in the identity chain, and if the compliance verification is successful, the target blockchain executes the target operation.

[0171] Optionally, in the blockchain-based request processing apparatus provided in this application embodiment, the update module further includes: a first update submodule, configured to register the identity document of the changed authentication node to the identity chain when the changed authentication node is a newly added authentication node; a second update submodule, configured to deregister the identity document of the changed authentication node from the identity chain when the changed authentication node is a deleted authentication node; and a third update submodule, configured to update the target identity document in the identity chain when the changed authentication node is an authentication node whose identity document has changed, wherein the target identity document refers to the identity document of the changed authentication node.

[0172] Optionally, in the blockchain-based request processing device provided in this application embodiment, the blockchain-based request processing device further includes: a first processing submodule, used to add a verification method entry corresponding to the new public key to the target identity document held by the changed authentication node, and retain the verification method entry corresponding to the old public key, wherein the verification method entry includes a public key type, a public key encoding format, a public key value, and an entry identifier; and a second processing submodule, used to update the field value of the first reference field in the target identity document to the entry identifier corresponding to the new public key, wherein the first reference is used to represent the public key information used when signing the cross-chain operation request.

[0173] Optionally, in the blockchain-based request processing apparatus provided in this application embodiment, the third update submodule further includes: an update submodule, used to update the target identity document held by the changed authentication node to the identity chain; the blockchain-based request processing apparatus further includes: a determination module, used to determine the time point at which the target identity document held by the changed authentication node is updated to the identity chain as the target time point; and a first processing module, used to remove the verification method entry corresponding to the old public key from the target identity document for the changed authentication node after the target time point and within the target time interval.

[0174] Optionally, in the blockchain-based request processing apparatus provided in this application embodiment, the signature module further includes: a signature submodule, used to sign the cross-chain operation request using the private key of the authentication node for each authentication node to obtain a signature value; a generation submodule, used to generate a signature entry for the authentication node based on the signature value corresponding to the authentication node, the node identifier of the authentication node, the entry identifier corresponding to the authentication node, and the hash value of the authorization credential of the authentication node, wherein the identity document records a verification method entry, and the verification method entry includes a public key type, a public key encoding format, a public key value, and an entry identifier, and the authorization credential is issued to the authentication node by the target management module; and a first determination submodule, used to determine the cross-chain proof based on the generated signature entries when the number of signature entries is greater than or equal to a preset number.

[0175] Optionally, in the blockchain-based request processing apparatus provided in this application embodiment, the sending module further includes: a first authentication submodule, used to authenticate the signature value in the cross-chain proof based on the identity document in the identity chain; a second authentication submodule, used to authenticate the authorization credential hash value if the signature value is authenticated, wherein the authorization credential is issued to the authentication node by the target management module; a third authentication submodule, used to verify whether the cross-chain operation request is within the authorization scope of the authorization credential if the authorization credential hash value is authenticated; a second determination submodule, used to determine that the compliance verification is passed if the cross-chain operation request is within the authorization scope; and a third determination submodule, used to determine that the compliance verification is failed if the signature value is not authenticated, or the authorization credential hash value is not authenticated, or the cross-chain operation request is outside the authorization scope.

[0176] Optionally, in the blockchain-based request processing device provided in this application embodiment, the blockchain-based request processing device further includes: an authentication module, used to authorize and authenticate the authentication node through the target management module; a second processing module, used to issue an authorization credential to the authentication node through the target management module when the authorization and authentication are passed; and a storage module, used to store the authorization credential in the authentication node and the identity chain.

[0177] It should be noted that the update module 401, signature module 402, and sending module 403 mentioned above correspond to steps S201 to S203 in Embodiment 1. The three modules and their corresponding steps implement the same instances and application scenarios, but are not limited to the content disclosed in Embodiment 1. It should be noted that the above modules or units can be hardware or software components stored in memory (e.g., memory 104) and processed by one or more processors (e.g., processors 102a, 102b, ..., 102n). The above modules can also be part of a device and run in the computer terminal 10 provided in Embodiment 1.

[0178] Example 4

[0179] Embodiments of this application may provide an electronic device. Figure 5 This is a structural block diagram of an electronic device according to an embodiment of this application. Figure 5 As shown, the electronic device may include: one or more ( Figure 5 (Only one is shown) Processor 1002, memory 1004, memory controller, and peripheral interface, wherein the peripheral interface is connected to the radio frequency module, audio module and display.

[0180] The memory can be used to store software programs and modules, such as the program instructions / modules corresponding to the methods and apparatus in the embodiments of this application. The processor executes various functional applications and data processing by running the software programs and modules stored in the memory, thereby implementing the above-described methods. The memory may include high-speed random access memory, and may also include non-volatile memory, such as one or more magnetic storage devices, flash memory, or other non-volatile solid-state memory. In some instances, the memory may further include memory remotely located relative to the processor, and these remote memories can be connected to the terminal via a network. Examples of such networks include, but are not limited to, the Internet, corporate intranets, local area networks, mobile communication networks, and combinations thereof.

[0181] The processor can access the information and application programs stored in the memory via the transmission device to execute the steps described in the above embodiments.

[0182] Those skilled in the art will understand that Figure 5 The structure shown is for illustrative purposes only. Electronic devices can also be smartphones, tablets, handheld computers, mobile internet devices (MIDs), PADs, and other terminal devices. Figure 5 This does not limit the structure of the aforementioned electronic device. For example, electronic devices may also include components that are more... Figure 5The more or fewer components shown (such as network interfaces, display devices, etc.), or having the same Figure 5 The different configurations shown.

[0183] Those skilled in the art will understand that all or part of the steps in the various methods of the above embodiments can be implemented by a program instructing the hardware related to the terminal device. The program can be stored in a computer-readable storage medium, which may include: flash drive, read-only memory (ROM), random access memory (RAM), disk or optical disk, etc.

[0184] Example 5

[0185] Embodiments of this application also provide a storage medium. Optionally, in this embodiment, the storage medium can be used to store the program code executed by the blockchain-based request processing method provided in Embodiment 1.

[0186] Optionally, in this embodiment, the storage medium may be located in any computer terminal in a group of computer terminals in a computer network, or in any mobile terminal in a group of mobile terminals.

[0187] This application also provides a computer program product that, when executed on a data processing device, is suitable for performing blockchain-based request processing method steps.

[0188] The sequence numbers of the embodiments in this application are for descriptive purposes only and do not represent the superiority or inferiority of the embodiments.

[0189] In the above embodiments of this application, the descriptions of each embodiment have different focuses. For parts not described in detail in a certain embodiment, please refer to the relevant descriptions of other embodiments.

[0190] In the several embodiments provided in this application, it should be understood that the disclosed technical content can be implemented in other ways. The device embodiments described above are merely illustrative; for example, the division of units is only a logical functional division, and in actual implementation, there may be other division methods. For example, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. Furthermore, the coupling or direct coupling or communication connection shown or discussed may be through some interfaces; the indirect coupling or communication connection of units or modules may be electrical or other forms.

[0191] The units described as separate components may or may not be physically separate. The components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the units can be selected to achieve the purpose of this embodiment according to actual needs.

[0192] Furthermore, the functional units in the various embodiments of this application can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit. The integrated unit can be implemented in hardware or as a software functional unit.

[0193] If the integrated unit is implemented as a software functional unit and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, or all or part of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the steps of the methods described in the various embodiments of this application. The aforementioned storage medium includes various media capable of storing program code, such as a USB flash drive, read-only memory (ROM), random access memory (RAM), portable hard drive, magnetic disk, or optical disk.

[0194] The above description is only a preferred embodiment of this application. It should be noted that for those skilled in the art, several improvements and modifications can be made without departing from the principle of this application, and these improvements and modifications should also be considered within the scope of protection of this application.

Claims

1. A blockchain-based request processing method, characterized in that, include: In the event of a change in the authentication node in the cross-chain gateway node cluster, the identity document in the identity chain is updated based on the identity document of the changed authentication node. The identity document is used to describe the public key information of the authentication node, and the identity chain is a blockchain used to store the identity document. Upon receiving a cross-chain operation request from the source blockchain, the cross-chain operation request is signed by multiple authentication nodes in the cross-chain gateway node cluster to obtain a cross-chain proof. The cross-chain operation request is used to request the target blockchain to perform the target operation. The cross-chain proof is sent to the target blockchain, whereby the target blockchain performs compliance verification on the cross-chain proof based on the identity document in the identity chain. If the compliance verification passes, the target blockchain executes the target operation.

2. The method according to claim 1, characterized in that, Based on the identity document of the changed authentication node, update the identity documents in the identity chain, including: If the authentication node that has been changed is a newly added authentication node, the identity document of the authentication node that has been changed is registered to the identity chain; If the authentication node that has been changed is a deleted authentication node, the identity document of the authentication node that has been changed shall be removed from the identity chain; If the authentication node that has undergone the change is the authentication node whose identity document has changed, then the target identity document is updated in the identity chain, wherein the target identity document refers to the identity document of the authentication node that has undergone the change.

3. The method according to claim 2, characterized in that, Before updating the target identity document in the identity chain, the method further includes: For the target identity document held by the authentication node that has changed, add a verification method entry corresponding to the new public key to the target identity document, and retain the verification method entry corresponding to the old public key. The verification method entry includes the public key type, public key encoding format, public key value and entry identifier. The field value of the first reference field in the target identity document is updated to the entry identifier corresponding to the new public key, wherein the first reference is used to represent the public key information used when signing the cross-chain operation request.

4. The method according to claim 3, characterized in that, Updating the target identity document in the identity chain includes: Update the target identity document held by the authentication node that has undergone the change to the identity chain; After updating the target identity document held by the changed authentication node to the identity chain, the method further includes: The target time point is determined as the time point at which the target identity document held by the authentication node that has undergone the change is updated to the identity chain; After the target time interval at the target time point, for the target identity document held by the changed authentication node, the verification method entry corresponding to the old public key is removed from the target identity document.

5. The method according to claim 1, characterized in that, The cross-chain operation request is signed by multiple authentication nodes in the cross-chain gateway node cluster to obtain cross-chain proof, including: For each authentication node, the cross-chain operation request is signed using the authentication node's private key to obtain a signature value; The signature entry of the authentication node is generated based on the signature value corresponding to the authentication node, the node identifier of the authentication node, the entry identifier corresponding to the authentication node, and the hash value of the authorization credential of the authentication node. The identity document records the verification method entry, which includes the public key type, public key encoding format, public key value, and entry identifier. The authorization credential is issued to the authentication node by the target management module. If the number of signature entries is greater than or equal to a preset number, the cross-chain proof is determined based on the generated signature entries.

6. The method according to claim 5, characterized in that, Compliance verification of the cross-chain proof based on the identity documents in the identity chain includes: Based on the identity document in the identity chain, the validity of the signature value in the cross-chain proof is verified. If the signature value passes the validity authentication, the authorization credential hash value is then validated, wherein the authorization credential is issued to the authentication node by the target management module. If the validity of the authorization credential hash value is verified, verify whether the cross-chain operation request is within the authorization scope of the authorization credential; If the cross-chain operation request is within the authorized scope, the compliance verification is determined to be successful. If the validity verification of the signature value fails, or the validity verification of the authorization credential hash value fails, or the cross-chain operation request is outside the scope of the authorization, the compliance verification is determined to have failed.

7. The method according to claim 6, characterized in that, The method further includes: The authentication node is authorized and authenticated through the target management module; Upon successful authorization and authentication, the authorization credential is issued to the authentication node through the target management module. The authorization credentials are stored in the authentication node and the identity chain.

8. A blockchain-based request processing system, characterized in that, include: A cross-chain gateway node cluster includes multiple authentication nodes. These authentication nodes are used to update an identity document in the identity chain based on the identity document of the changed authentication node when a change occurs in the cross-chain gateway node cluster. The identity document describes the public key information of the authentication node. Upon receiving a cross-chain operation request from the source blockchain, the multiple authentication nodes in the cross-chain gateway node cluster sign the cross-chain operation request, which requests the target blockchain to perform a target operation. The identity chain is a blockchain used to store the identity documents; A cross-chain proof generation module is used to generate a cross-chain proof based on the signatures of the cross-chain operation request from multiple authentication nodes, and send the cross-chain proof to the target blockchain. The target blockchain performs compliance verification on the cross-chain proof based on the identity document in the identity chain. If the compliance verification is successful, the target blockchain executes the target operation.

9. A blockchain-based request processing device, characterized in that, include: The update module is used to update the identity document in the identity chain based on the identity document of the changed authentication node when the authentication node in the cross-chain gateway node cluster changes. The identity document is used to describe the public key information of the authentication node, and the identity chain is a blockchain used to store the identity document. The signature module is used to sign the cross-chain operation request through multiple authentication nodes in the cross-chain gateway node cluster when a cross-chain operation request is received from the source blockchain, thereby obtaining a cross-chain proof. The cross-chain operation request is used to request the target blockchain to perform the target operation. A sending module is used to send the cross-chain proof to a target blockchain, wherein the target blockchain performs compliance verification on the cross-chain proof based on the identity document in the identity chain, and if the compliance verification is successful, the target blockchain executes the target operation.

10. An electronic device, characterized in that, include: Memory, which stores executable programs; A processor for running the program, wherein the program, when running, executes the blockchain-based request processing method according to any one of claims 1 to 7.

Images