Authentication method and device, electronic equipment and storage medium

Abstract

The invention provides an authentication method and device, electronic equipment and a storage medium. The cross-domain and cross-chain authentication method is applied to a cross-domain and cross-chain authentication system based on a block chain, and the cross-domain and cross-chain authentication system comprises a plurality of authentication nodes located in a plurality of domains of a cross-domain cluster; the authentication method comprises the following steps: obtaining a block corresponding to a target write request; sending Q local keys to Q authentication nodes in the plurality of authentication nodes, so that the Q authentication nodes respectively sign the target write request according to the received local keys and store generated local signatures into a block; when the number of the local signatures in the block reaches m, determining a data consistency authentication result of the target write request based on the public key and the m local signatures in the block; m is smaller than Q, and Q is a positive integer larger than 1.

Description

Technical Field

[0001] This application relates to the field of computer technology, and in particular to an authentication method, apparatus, electronic device and storage medium. Background Technology

[0002] With the continuous development of Internet technology, in order to adapt to the increasing scale of business and the rapid growth of data volume, the application of distributed cross-domain data storage technology is becoming more and more widespread. For example, cross-domain data storage technology is used in Internet of Things fields such as smart homes and industrial Internet to store and process data from various sensors.

[0003] Cross-domain data storage technology typically distributes data across multiple domains. This cross-domain storage carries extremely high security risks, making it highly vulnerable to malicious attacks. Malicious nodes can tamper with or delete the data stored on their nodes, leading to severe data security and reliability issues and significantly impacting the availability of the cross-domain cluster. Furthermore, data consistency authentication in cross-domain data storage technology often relies on the reliability of replica nodes within the cross-domain cluster. If all replica nodes for a particular piece of data are maliciously attacked, the data returned by these nodes will no longer be trustworthy. Therefore, ensuring data security and trustworthiness in cross-domain clusters is crucial. Summary of the Invention

[0004] This application provides an authentication method, apparatus, electronic device, and storage medium that can ensure data security and trustworthiness in cross-domain clusters.

[0005] The technical solution of this application embodiment is implemented as follows: This application provides an authentication method applied to a blockchain-based cross-domain and cross-chain authentication system, wherein the cross-domain and cross-chain authentication system includes multiple authentication nodes located in multiple domains of a cross-domain cluster; the method includes: Obtain the block corresponding to the target write request; Q local keys are sent to Q authentication nodes among the plurality of authentication nodes, so that the Q authentication nodes respectively sign the target write request according to the received local keys and store the generated local signatures into the block; where Q is a positive integer greater than 1; When the number of local signatures in the block reaches m, the data consistency authentication result of the target write request is determined based on the public key and the m local signatures in the block; where m is less than Q.

[0006] In some exemplary embodiments, the Q local keys are obtained by key splitting the private key according to the number of replica nodes in the cross-domain cluster and a preset redundancy, wherein the preset redundancy is used to represent the maximum number of faulty nodes that can be tolerated, and m is less than the number of replica nodes in the cross-domain cluster.

[0007] In some exemplary embodiments, each of the multiple domains in the cross-domain cluster includes multiple nodes; the method further includes: selecting a target number of nodes from the multiple nodes in each domain as the authentication nodes and adding them to the cross-domain cross-chain authentication system, wherein the target number is determined based on the number of nodes in each domain and a preset threshold.

[0008] In some exemplary embodiments, the blockchain of the cross-domain cross-chain authentication system is a multi-chain blockchain network based on a Directed Acyclic Graph (DAG); the method further includes: When the data consistency authentication result of the target write request is determined to be passed, the block is added to the blockchain of the cross-domain cross-chain authentication system.

[0009] In some exemplary embodiments, the method further includes: The authentication node that writes a local signature in the block selects a link pointing to the block.

[0010] In some exemplary embodiments, determining the data consistency authentication result of the target write request based on the public key and m local signatures in the block includes: The m local signatures in the block are aggregated to obtain the aggregated signature; Based on the public key, the signature of the aggregate is verified; If the signature verification passes, the data consistency authentication result of the target write request is determined to be passed; or, if the signature verification fails, the data consistency authentication result of the target write request is determined to be failed.

[0011] In some exemplary embodiments, the method further includes: Obtain the target read request; Obtain m local signatures and public keys corresponding to the target read request; wherein, the m local signatures and public keys corresponding to the target read request are generated when performing data consistency authentication for the write request of the data read by the target read request; Based on the m local signatures and public keys corresponding to the target read request, the data consistency authentication result of the target read request is determined.

[0012] This application provides an authentication device applied to a blockchain-based cross-domain and cross-chain authentication system, wherein the cross-domain and cross-chain authentication system includes multiple authentication nodes located in multiple domains of a cross-domain cluster; the device includes: The acquisition unit is used to obtain the block corresponding to the target write request; The sending unit is configured to send Q local keys to Q authentication nodes among the plurality of authentication nodes, so that the Q authentication nodes respectively sign the target write request according to the received local keys and store the generated local signatures into the block; wherein, Q is a positive integer greater than 1; A determining unit is used to determine the data consistency authentication result of the target write request based on the public key and the m local signatures in the block when the number of local signatures in the block reaches m; where m is less than Q.

[0013] This application provides an electronic device, the electronic device comprising: Memory is used to store executable instructions or computer programs. The processor, when executing computer-executable instructions or computer programs stored in the memory, implements the authentication method provided in the embodiments of this application.

[0014] This application provides a computer-readable storage medium storing a computer program or computer-executable instructions, which, when executed by a processor, implement the authentication method provided in this application.

[0015] The embodiments of this application have the following beneficial effects: The authentication method, apparatus, electronic device, and storage medium provided in the embodiments of this application, by setting up a cross-domain cross-chain authentication system including multiple authentication nodes located in multiple domains of a cross-domain cluster, and setting the blockchain of the cross-domain cross-chain authentication system as a multi-chain blockchain network based on a directed acyclic graph, obtains the block corresponding to the target write request, sends Q local keys for signing to Q authentication nodes in the cross-domain cross-chain authentication system, so that the Q authentication nodes in the cross-domain cross-chain authentication system sign the target write request based on the local keys to generate local signatures and store the generated local signatures in the block. When the number of local signatures in the block corresponding to the target write request reaches m, the data consistency of the target write request can be authenticated by using the public key and the m local signatures in the block, and the data consistency authentication result of the target write request can be obtained, thereby ensuring the data security and trustworthiness in the cross-domain cluster. Attached Figure Description

[0016] Figure 1 A schematic diagram of the distributed storage system architecture for an authentication method provided in this application embodiment; Figure 2 This is a first flowchart illustrating an authentication method provided in an embodiment of this application; Figure 3 This is a schematic diagram of the second process of an authentication method provided in an embodiment of this application; Figure 4A schematic diagram of a single-domain, single-authentication node model provided in an embodiment of this application; Figure 5 A schematic diagram of the framework of a cross-domain cross-chain authentication system based on a single-domain single-authentication-node model provided in an embodiment of this application; Figure 6 A schematic diagram of a single-domain multi-authentication node model provided in an embodiment of this application; Figure 7 A schematic diagram of the framework of a cross-domain cross-chain authentication system based on a single-domain multi-authentication node model provided in an embodiment of this application; Figure 8 A schematic diagram of a blockchain connection provided in an embodiment of this application; Figure 9 This is a schematic diagram of the structure of an authentication device provided in an embodiment of this application; Figure 10 This is a schematic diagram of the structure of an electronic device provided in an embodiment of this application.

[0017] It should be noted that the terms "first" and "second" mentioned above are only used to distinguish between different options and do not represent the degree of superiority or inferiority of the options or their priority in the implementation process. Detailed Implementation

[0018] To make the objectives, technical solutions, and advantages of this application clearer, the application will be further described in detail below with reference to the accompanying drawings. The described embodiments should not be regarded as limitations on this application. All other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this application.

[0019] In the following description, references are made to “some embodiments,” which describe a subset of all possible embodiments. However, it is understood that “some embodiments” may be the same subset or different subsets of all possible embodiments and may be combined with each other without conflict.

[0020] In the following description, the terms "first, second, third" are used merely to distinguish similar objects and do not represent a specific ordering of objects. It is understood that "first, second, third" may be interchanged in a specific order or sequence where permitted, so that the embodiments of this application described herein can be implemented in an order other than that illustrated or described herein.

[0021] In this document, the term "one or more" means any combination of at least two of a plurality of elements, such as one or more of A, B, and C, which can mean any one or more elements selected from the set consisting of A, B, and C. The term "one or more" means any one of a plurality of elements or any combination of at least two of a plurality of elements, such as one or more of A, B, and C, which can mean any one or more elements selected from the set consisting of A, B, and C.

[0022] In the embodiments of this application, the terms "module," "unit," or "component" refer to a computer program or part of a computer program that has a predetermined function and works together with other related parts to achieve a predetermined goal, and can be implemented wholly or partially using software, hardware (such as processing circuitry or memory), or a combination thereof. Similarly, a processor (or multiple processors or memory) can be used to implement one or more modules or units. Furthermore, each module or unit can be part of an overall module or unit that includes the functionality of that module or unit.

[0023] Unless otherwise defined, all technical and scientific terms used in the embodiments of this application have the same meaning as commonly understood by one of ordinary skill in the art. The terminology used in the embodiments of this application is for the purpose of describing the embodiments of this application only and is not intended to limit this application.

[0024] In the implementation of this application, the collection and processing of relevant data should strictly comply with the requirements of relevant laws and regulations, obtain the informed consent or separate consent of the personal information subject, and carry out subsequent data use and processing within the scope of laws and regulations and the authorization of the personal information subject.

[0025] Before providing a further detailed description of the embodiments of this application, the nouns and terms involved in the embodiments of this application will be explained below, and the nouns and terms involved in the embodiments of this application shall be interpreted as follows.

[0026] 1. A cluster refers to a pool of computing resources composed of multiple servers connected together via a network. This pool exists as a whole, working collaboratively to complete the same business and providing a set of network resources to users. These individual servers are the nodes of the cluster, and these nodes typically run the same software or services. Cluster nodes can be physical servers, virtual servers, cloud servers, etc.

[0027] 2. Cross-domain clusters, also known as multi-domain clusters, refer to clusters where multiple nodes are deployed in multiple domains. For example, multiple nodes in a cluster may be deployed in multiple resource pools in different geographical regions, or across multiple different hosts in different regions. A resource pool is a collection of virtualized resources (such as servers, storage, and networks) allocated on demand in the cloud computing field.

[0028] 3. In a distributed cluster, node types can be categorized as: master nodes, replica nodes, edge nodes, etc. The master node (also known as the coordinating node) is typically used to coordinate and manage the work of the entire distributed cluster to ensure system stability and high availability. Replica nodes, also known as backup nodes, secondary nodes, data nodes, storage nodes, etc., are typically used to store data copies, maintaining data consistency through asynchronous replication; there can usually be multiple replica nodes.

[0029] With the development of distributed storage technology, and to adapt to the ever-expanding scale of business and the rapid growth of data volume, the application of distributed cross-domain data storage technology is becoming increasingly widespread. For example, it is used in IoT fields such as smart homes and industrial interconnection to store and process data from various sensors. If an attacker were to compromise an IoT device, they could potentially tamper with or delete data, leading to inaccurate data in the database and impacting decision-making. If a cluster deployed at the end-user application faces the failure of most nodes, the consequences would inevitably be catastrophic.

[0030] Cross-domain data storage technology typically distributes data across multiple domains. In the event of a domain-wide failure, data can be recovered from other functioning domain nodes, significantly improving cluster availability and disaster recovery capabilities. However, nodes in cross-domain clusters are often deployed across multiple resource pools. To achieve multi-party backup, data is usually distributed across multiple domains, posing a significant security risk. Cross-domain data storage is highly vulnerable to malicious attacks; malicious nodes can tamper with or delete data stored on nodes, leading to severe data security and reliability issues and significantly impacting the availability of the cross-domain cluster. Data consistency in cross-domain clusters is generally achieved by the master node confirming whether the number of identical data returned reaches a set consistency threshold. If a malicious node is present, data consistency becomes unreliable. Furthermore, data consistency authentication in cross-domain data storage technology often relies on the reliability of replica nodes within the cross-domain cluster. Since all nodes in the cluster are exposed to an edge network, if all replica nodes for a particular data point are maliciously attacked, the data returned by these nodes will no longer be reliable. Therefore, ensuring data security and reliability in cross-domain clusters is crucial.

[0031] This application provides an authentication method, apparatus, electronic device, and storage medium. By setting up a blockchain-based cross-domain cross-chain authentication system including multiple authentication nodes located in multiple domains of a cross-domain cluster, when a block corresponding to a target write request is obtained, Q local keys for signing are sent to Q authentication nodes in the cross-domain cross-chain authentication system. These Q authentication nodes then sign the write request based on the local keys to generate a local signature, which is stored in the block. Since any m local keys among the Q local keys can be aggregated to obtain a private key, when the number of local signatures in the block corresponding to the target write request reaches m, the data consistency authentication result of the target write request can be determined based on the public key and the m local signatures in the block. This ensures the reliability of data consistency authentication in the cross-domain cluster, thereby guaranteeing data storage security and the trustworthiness of data consistency authentication.

[0032] In some exemplary embodiments, the authentication methods provided in the various embodiments of this application, by setting the cross-domain cross-chain authentication system to include multiple authentication nodes located in multiple domains of the cross-domain cluster, and setting the blockchain of the cross-domain cross-chain authentication system to be a multi-chain blockchain network based on a directed acyclic graph, can realize data consistency authentication of cross-domain clusters and are applicable to various cloud service scenarios including cross-domain clusters, such as public cloud service scenarios, private cloud service scenarios, and hybrid cloud service scenarios.

[0033] The following describes an exemplary application of the authentication method provided in the embodiments of this application. Figure 1 This is a schematic diagram of the distributed storage system architecture for an authentication method provided in an embodiment of this application. Figure 1 As shown, the distributed storage system architecture may include: client 10 and cross-domain cluster 20, the cross-domain cluster 20 may include multiple domains ( Figure 1 The following example uses three fields for illustration. Figure 1As shown in the diagram (domains 1, 2, and 3), each domain can include multiple nodes, with every two nodes interconnected. One or more nodes in each domain can act as authentication nodes, joining the cross-domain cross-chain authentication system (also known as a cross-domain cross-chain authentication network). This allows multiple authentication nodes in the cross-domain cross-chain authentication system to be distributed across multiple domains of the cross-domain cluster, enabling cross-domain authentication. Furthermore, a blockchain is deployed in the cross-domain cross-chain authentication system. The immutability of the blockchain ensures cross-domain authentication and guarantees the disaster recovery capabilities of the cross-domain cluster, given the distribution of authentication nodes across multiple domains. For example, when one node in each domain joins the cross-domain cross-chain authentication system as an authentication node, if an authentication node in one domain fails, cross-domain data authentication can be performed by authentication nodes in other domains to ensure the security of cross-domain data. When multiple nodes in each domain join the cross-domain cross-chain authentication system as authentication nodes, its disaster recovery capabilities are even stronger, tolerating not only the failure of some authentication nodes in other domains but also the failure of some authentication nodes in the same domain, ensuring a balanced distribution of authentication nodes.

[0034] As an example, the blockchain deployed in the cross-domain cross-chain authentication system is a multi-chain blockchain network based on a directed acyclic graph (DAG). This allows multiple authentication nodes in the system to maintain multiple blockchains based on the DAG, enabling cross-chain authentication. In other words, authentication nodes in the cross-domain cross-chain authentication system can be used to perform cross-domain cross-chain authentication on the data consistency of data requests. Furthermore, the cross-domain cross-chain authentication system deploys blockchain technology based on proof-of-work, ensuring data security and immutability. Moreover, since cross-domain cross-chain authentication systems are often relatively small in scale, the increase in hash computation difficulty based on proof-of-work tends to be gradual, meeting the real-time needs of industrial internet users in real-world application scenarios. For example, non-authenticated nodes in a distributed storage system architecture can join or leave the cross-domain cross-chain authentication system at any time, while each authenticated node cannot leave.

[0035] In some exemplary embodiments, the authentication nodes in a cross-domain cross-chain authentication system are used to authenticate the data consistency of user-initiated data requests (such as read or write requests). This means that the authentication nodes can be used to authenticate data consistency for read and write requests between different domains, and also for read and write requests within the same domain. The cross-domain cross-chain authentication system is used to authenticate user-initiated read and write requests. For example, authentication nodes in a cross-domain cross-chain authentication system cannot arbitrarily exit the system.

[0036] In some exemplary embodiments, client 10 communicates with nodes of cross-domain cluster 20 via a network. The network can be a wide area network (WAN), a local area network (LAN), or a combination of both. Client 10 can be implemented using various types of terminal devices, such as laptops, tablets, desktop computers, portable computers, smartphones, smart home appliances, in-vehicle terminals, or aircraft, etc., which are not limited in this embodiment.

[0037] In some exemplary embodiments, a cross-domain cluster can be a server cluster consisting of multiple physical servers, a distributed system consisting of multiple physical servers, a cloud server capable of providing cloud computing services, or a collaborative system consisting of edge nodes and cloud servers, etc. Here, the embodiments of this application do not limit this.

[0038] here, Figure 1 The example shown is merely a system architecture example of an authentication method provided by the embodiments of this application, in order to help those skilled in the art understand the technical content of this application, but it does not mean that the embodiments of this application cannot be used in other devices, systems, environments or scenarios.

[0039] Figure 2 This is a schematic diagram of the first process of an authentication method provided in an embodiment of this application. The following will be combined with... Figure 2 This will be explained. For example, the authentication method can be achieved through... Figure 1 The authentication nodes in the cross-domain cluster shown are executed, that is, executed through the authentication nodes in the cross-domain cross-chain authentication system, which is deployed with a blockchain. For example, the blockchain of the cross-domain cross-chain authentication system is a multi-chain blockchain network based on a directed acyclic graph.

[0040] like Figure 2 As shown, an authentication method provided in this application embodiment may include the following steps S201 to S203: Step S201: Obtain the block corresponding to the target write request.

[0041] In this system, the block corresponding to the target write request is created based on the target write request from the client. For example, after a node in the cross-domain cluster receives a target write request from a client, it can send the target write request to any authentication node in the cross-domain cross-chain authentication system. This allows the authentication node to create the block corresponding to the target write request and broadcast it to all authentication nodes in the cross-domain cross-chain authentication system. In this way, upon receiving a target write request, the write request can be introduced into the cross-domain cross-chain authentication system, enabling subsequent authentication of the data consistency of the target write request based on the authentication nodes within the cross-domain cross-chain authentication system and the multi-chain blockchain network based on a directed acyclic graph.

[0042] A write request is used to request data writing operations, such as adding, updating, and deleting. For example, a write request can be used to submit data modifications to a cross-domain cluster, upload data, or insert key-value pairs.

[0043] Step S202: Send Q local keys to Q authentication nodes among the multiple authentication nodes of the cross-domain cross-chain authentication system, so that the Q authentication nodes respectively sign the target write request according to the received local keys and store the generated local signatures into the block. Where Q is a positive integer greater than 1.

[0044] Step S203: When the number of local signatures in the block reaches m, determine the data consistency authentication result of the target write request based on the public key and the m local signatures in the block; where m is less than Q.

[0045] Each local signature is obtained by the authentication node participating in the authentication process signing the write request based on the local key it received.

[0046] In some exemplary embodiments, step S203 may include the following steps: aggregating the m local signatures in the block to obtain an aggregated signature; verifying the aggregated signature based on the public key; determining that the data consistency authentication result of the target write request is passed when the signature verification passes; or determining that the data consistency authentication result of the target write request is failed when the signature verification fails.

[0047] Thus, the authentication method provided in this application embodiment, through a cross-domain cross-chain authentication system including multiple authentication nodes located in multiple domains of a cross-domain cluster, upon receiving a write request, selects Q authentication nodes in the cross-domain cross-chain authentication system to participate in authentication by sending Q local keys for signing, thus avoiding the participation of all authentication nodes. Furthermore, a consistency authentication threshold m is set; only when the number of collected local signatures reaches m can the data consistency of the target write request be authenticated based on the public key and the m local signatures in the block, obtaining a data consistency authentication result for the target write request, thereby ensuring the credibility of the data consistency authentication. This avoids waiting for all local key signatures to be collected, ensuring the efficiency of data consistency authentication and enabling efficient cross-domain cluster data consistency authentication, thereby guaranteeing data security and credibility in the cross-domain cluster. In addition, when the authentication method provided in this application is applied to the industrial Internet of Things (IIoT) field, it can improve the storage security of large-scale data in the IIoT.

[0048] In some exemplary embodiments, Q local keys are obtained by key splitting the private key based on the number M of replica nodes in the cross-domain cluster and a preset redundancy K, where the preset redundancy K represents the maximum number of faulty nodes that can be tolerated. Here, by sending Q local keys for signing to Q authentication nodes in the cross-domain cross-chain authentication system, Q authentication nodes in the cross-domain cross-chain authentication system are selected to participate in authentication. For each write request, the number of generated local signatures is related to the number of replica nodes in the cross-domain cluster and the preset redundancy, not the total number of participating authentication nodes in the cross-domain cross-chain authentication system. Furthermore, since the number of generated local signatures is related to the number of replica nodes in the cross-domain cluster and the preset redundancy, the maximum number of node failures that can be tolerated is the preset redundancy. When a faulty node occurs, authentication can still be performed through the cross-domain cross-chain authentication system, thereby ensuring high reliability of data consistency. In addition, since blockchain technology is deployed in the cross-domain cross-chain authentication system, i.e., the authentication nodes are blockchain nodes, the immutability of blockchain can avoid security risks caused by malicious nodes, ensuring efficient data processing and secure and immutable data storage.

[0049] In some exemplary embodiments, step S202 may include the following steps: sending Q local keys to Q authentication nodes among multiple authentication nodes in the cross-domain cross-chain authentication system, so that the Q authentication nodes respectively sign the target write request according to the received local keys and store the generated local signatures into a block. The Q local keys are obtained by key splitting the private key according to the number of replica nodes in the cross-domain cluster and a preset redundancy, where replica nodes are nodes used to store data replicas.

[0050] In some exemplary embodiments, step S202, which sends Q local keys for signing to Q authentication nodes in the cross-domain cross-chain authentication system, may include the following steps: determining Q based on the current number of replica nodes in the cross-domain cluster and a preset redundancy; performing key segmentation on the private key based on the (Q,m) threshold key sharing algorithm to obtain Q local keys; the (Q,m) threshold means that any m local keys among the Q local keys can be aggregated to obtain a private key, so that the aggregation of m local signatures generated based on any m local keys among the Q local keys can obtain a complete aggregated signature, which can be verified by the public key corresponding to the private key.

[0051] In some exemplary embodiments, Q is the sum of the number of replica nodes M in the cross-domain cluster and a preset redundancy K. The preset redundancy K represents the maximum number of faulty nodes that can be tolerated.

[0052] In some exemplary embodiments, the preset redundancy K can be set according to the number of nodes in the cluster and the actual application scenario. For example, the preset redundancy K is less than or equal to the number of replica nodes M in the cross-domain cluster.

[0053] In some exemplary embodiments, m is a preset consistency authentication threshold. m can be determined based on the number of replica nodes in the cross-domain cluster, i.e., the number of data replicas; for example, m is less than the number of replica nodes in the cross-domain cluster. In practical applications, the preset consistency authentication threshold can be adaptively adjusted according to user requests to ensure the efficiency of data consistency authentication.

[0054] In some exemplary embodiments, each of the multiple domains in the cross-domain cluster includes multiple nodes; the method further includes: selecting a target number of nodes from the multiple nodes in each domain as authentication nodes and adding them to the cross-domain cross-chain authentication system. The target number can be determined based on the number of nodes in each domain and a preset threshold. This allows the number of authentication nodes in each domain to be adjusted according to the number of nodes in each domain and the preset threshold. Thus, the number of authentication nodes can be adaptively adjusted according to the cluster size, thereby ensuring the authentication efficiency of large-scale clusters.

[0055] In some exemplary embodiments, the number of authentication nodes in each domain is adjusted based on the number of nodes in each domain and a preset threshold. This may include the following steps: when the number of nodes in each domain is less than the preset threshold, select one node from all nodes in each domain as an authentication node, such as randomly selecting one node; or, when the number of nodes in each domain is greater than or equal to the preset threshold, select multiple nodes from all nodes in each domain as authentication nodes, such as randomly selecting a preset number of nodes. Thus, since the authentication nodes are distributed across multiple domains, cross-domain authentication can be achieved through the cross-domain cross-chain authentication system, ensuring the disaster recovery function of the cross-domain cluster. For example, when one node in each domain joins the cross-domain cross-chain authentication system as an authentication node, if the authentication node in one domain fails, cross-domain data authentication can be performed through authentication nodes in other domains to ensure the security of cross-domain data. When multiple nodes in each domain join the cross-domain cross-chain authentication system as authentication nodes, its disaster recovery function is more robust, tolerating not only the failure of some authentication nodes in other domains but also the failure of some authentication nodes in the same domain, ensuring the balanced distribution of authentication nodes.

[0056] In some exemplary embodiments, depending on the node role, the authentication node can be a master node or a replica node.

[0057] In some exemplary embodiments, when the number of domains is the same, the number of authentication nodes selected by each domain is the same. Alternatively, domains with different numbers of nodes may select different numbers of authentication nodes.

[0058] In some exemplary embodiments, to facilitate the authentication of write requests initiated by users by authentication nodes, after any node in the cross-domain cluster receives a write request from a client, that node can join the cross-domain cross-chain authentication system as a non-authentication node and create a block corresponding to the target write request based on the write request from the client. After the authentication node creates the block corresponding to the target write request, the authentication node can broadcast the block corresponding to the target write request to all authentication nodes in the cross-domain cross-chain authentication system so that the authentication nodes can sign the received local key into the block corresponding to the target write request.

[0059] In some further exemplary embodiments, to facilitate the authentication of write requests initiated by users by authentication nodes, after any node in the cross-domain cluster receives a write request from a client, it can send the write request to any authentication node in the cross-domain cross-chain authentication system that is in the same domain as the arbitrary node. This allows the authentication node to create a block corresponding to the target write request based on the write request from the client. After the authentication node creates the block corresponding to the target write request, it can broadcast the block to other authentication nodes in the cross-domain cross-chain authentication system so that other authentication nodes can sign the received local key into the block corresponding to the target write request.

[0060] Specifically, the authentication node signs the received local key into the block corresponding to the target write request. This can mean that the authentication node signs the write request based on the received local key to obtain a local signature, and then writes the local signature into the block corresponding to the target write request.

[0061] In some exemplary embodiments, taking the private key obtained by key splitting Q local keys according to the number of replica nodes in the cross-domain cluster and a preset redundancy as an example, step S203 may include the following steps: when the number of local signatures in the block reaches m, the data consistency authentication result of the target write request is determined based on the public key corresponding to the private key and the m local signatures in the block; where m is less than Q. Thus, since any m local keys among the Q local keys can be aggregated to obtain the private key, when the number of local signatures in the block corresponding to the target write request reaches m, the data consistency authentication result of the target write request can be determined based on the public key corresponding to the private key and the m local signatures in the block. This ensures the reliability of data consistency authentication in the cross-domain cluster, thereby guaranteeing data storage security and the trustworthiness of data consistency authentication.

[0062] In some exemplary embodiments, taking the private key obtained by splitting Q local keys according to the number of replica nodes in the cross-domain cluster and a preset redundancy as an example, step S203, based on the public key and m local signatures in the block, determines the data consistency authentication result of the target write request, which may include the following steps: Step S2031: Aggregate the m local signatures in the block to obtain the aggregated signature.

[0063] Step S2032: Verify the aggregated signature based on the public key corresponding to the private key.

[0064] For example, the aggregated signature can be verified by any authentication node in a cross-domain, cross-chain authentication system based on the public key corresponding to the private key.

[0065] Step S2033: If the signature verification passes, determine that the data consistency authentication result of the target write request is passed; or, if the signature verification fails, determine that the data consistency authentication result of the target write request is failed.

[0066] In some exemplary embodiments, step S2032, which verifies the aggregated signature based on the public key corresponding to the private key, may include the following steps: Step S2032-1: Obtain the public key corresponding to the private key.

[0067] For example, in a cross-domain, cross-chain authentication system, any node can obtain the public key.

[0068] Step S2032-2: Decrypt the aggregated signature based on the public key corresponding to the private key; Step S2032-3: If decryption is successful, perform a hash calculation on the target write request to obtain its hash value. Alternatively, if decryption fails, it indicates that the signature verification failed.

[0069] Step S2032-4: Confirm whether the hash value of the target write request is consistent with the data obtained after decryption.

[0070] Step S2032-5: If the hash value of the target write request matches the decrypted data, the signature verification is successful. Alternatively, if the hash value of the write request does not match the decrypted data, the signature verification is unsuccessful.

[0071] In some exemplary embodiments, the blockchain of the cross-domain cross-chain authentication system is a multi-chain blockchain network based on a directed acyclic graph; the authentication method may also include: step S204: when the data consistency authentication result of the target write request is passed, the block is added to the blockchain of the cross-domain cross-chain authentication system.

[0072] In some exemplary embodiments, step S204 may include: when each authentication node in the cross-domain cross-chain authentication system verifies the aggregated signature based on the public key and all verifications are successful, at this time, each authentication node reaches a consensus on the block corresponding to the target write request. The write request has strong data consistency, and a target authentication node can be determined based on a preset consensus mechanism (such as a consensus algorithm based on proof-of-work), and the target authentication node adds the block corresponding to the target write request to the blockchain.

[0073] In some other exemplary embodiments, step S204 may include: since m represents the data consistency threshold, when the signature of the aggregate is verified by at least m authentication nodes in the cross-domain cross-chain authentication system based on the public key and all verifications are successful, a target authentication node can be determined from the at least m authentication nodes based on a preset consensus mechanism (such as a consensus algorithm based on proof-of-work), and the target authentication node adds the block corresponding to the target write request to the blockchain.

[0074] In some exemplary embodiments, the blockchain deployed in the cross-domain cross-chain authentication system adopts a proof-of-work-based consensus mechanism. Thus, since cross-domain cross-chain authentication systems are often relatively small in scale, the increase in hash computation difficulty based on proof-of-work tends to be gradual, which can meet the real-time requirements of industrial internet users in real-world application scenarios.

[0075] In some exemplary embodiments, a private chain is deployed at each authentication node. After sending Q local keys for signing to Q authentication nodes in the cross-domain cross-chain authentication system in step S202, the authentication method may further include the following step: the authentication node participating in the authentication may store the local keys it receives and the local signature generated based on the local keys in the private chain of the authentication node to ensure traceability.

[0076] In some exemplary embodiments, after step S204, the authentication method may further include: step S205: the authentication node that writes a local signature in the block selects a link pointing to the block corresponding to the target write request.

[0077] In some other exemplary embodiments, after step S204, the authentication method may further include: the authentication node that puts the block corresponding to the target write request on the chain selecting a link pointing to the block.

[0078] In this way, for newly added blocks, the authentication node actively selects the link pointing to the block corresponding to the target write request. This ensures efficient processing of new block authentication regardless of whether data traffic is high or low, thus improving authentication efficiency. In contrast, related technologies where the blockchain directly links new blocks to predecessor blocks, causing newly added blocks to wait for the next block to be selected and linked before authentication, solve the problem of slow authentication when the block addition rate is low.

[0079] In some exemplary embodiments, the blockchain deployed in the cross-domain cross-chain authentication system adopts a multi-chain consensus mechanism based on a directed acyclic graph (DAG).

[0080] Figure 3 This is a schematic diagram of the second process of an authentication method provided in an embodiment of this application. The following will be combined with... Figure 2 This will be explained. For example, the authentication method can be achieved through... Figure 1 The nodes in the cross-domain cluster shown are executing.

[0081] like Figure 3 As shown, an authentication method provided in this application embodiment may further include the following steps S301 to S302: Step S301: Obtain the target read request.

[0082] For example, receiving a read request from a client gives you the target read request.

[0083] A read request is a request used to perform data reading operations, such as reading or querying. For example, retrieving data from a cross-domain cluster.

[0084] Step S302: Obtain the m local signatures and public keys corresponding to the target read request.

[0085] Among them, the m local signatures and public keys corresponding to the target read request are generated when performing data consistency authentication for the write request on the data read by the target read request.

[0086] Step S303: Based on the m local signatures and public keys corresponding to the target read request, determine the data consistency authentication result of the target read request.

[0087] Thus, in the authentication method provided in this application, upon receiving a target read request, data consistency authentication is performed on the target read request based on the m local signatures and public keys corresponding to the target read request, thereby ensuring data security.

[0088] In some exemplary embodiments, step S303 may include the following steps: Step S3031: Aggregate the m local signatures corresponding to the target read request to obtain the aggregated signature corresponding to the target read request; Step S3032: Verify the signature of the aggregate corresponding to the target read request based on the public key corresponding to the target read request; Step S3033: When the signature verification passes, determine that the data consistency authentication result of the target read request is passed; or, when the signature verification fails, determine that the data consistency authentication result of the target read request is failed.

[0089] In some exemplary embodiments, the method may further include: when it is determined that the data consistency authentication result of the target read request is passed, returning the data read by the target read request to the client that sent the target read request.

[0090] Thus, in the authentication method provided in this application, upon receiving a read request, after aggregating the m local signatures corresponding to the target read request to obtain the signature of the aggregate corresponding to the target read request, the signature of the aggregate corresponding to the target read request is verified based on the public key corresponding to the target read request. When the signature verification passes, it indicates that the signature of the current aggregate is consistent with the signature of the historical aggregate, and it can be determined that the data read by the read request has high data consistency and trustworthiness in the cross-domain cluster. The data read by the target read request can then be returned to the client. This ensures that the data returned by the node has high trustworthiness. Furthermore, when a malicious node appears, it can avoid the security risks caused by malicious nodes tampering with the data stored on the node, greatly improving the availability of the cluster.

[0091] In some exemplary embodiments, when authenticating a write request for the data read by the target read request, the authentication nodes participating in the authentication can store local signatures in their local private blockchains. Step S302 may include: sending the target read request to the m authentication nodes participating in the data consistency authentication for the write request of the data read by the target read request; and obtaining the local signatures generated during the data consistency authentication for the write request of the data read by the target read request from their respective local private blockchains through the m authentication nodes. Thus, m local signatures corresponding to the target read request are obtained. Furthermore, the public key used for the data consistency authentication for the write request of the data read by the target read request is obtained through any of the m authentication nodes.

[0092] In some exemplary embodiments, when authenticating a write request for the data read by the target read request, the authentication nodes participating in the authentication can store local keys in their local private blockchain. Step S302 may include: sending the target read request to the m authentication nodes participating in the data consistency authentication for the write request of the data read by the target read request; obtaining the m local keys generated during the data consistency authentication for the write request of the data read by the target read request from their respective private blockchains through the m authentication nodes, thus obtaining the m local keys corresponding to the target read request. Based on the data read by the target read request and the m local keys corresponding to the target read request, obtaining the m local signatures corresponding to the target read request.

[0093] In some exemplary embodiments, sending a target read request to m authentication nodes participating in the data consistency authentication of a write request for the data read by the target read request may include the following steps: determining, from the blockchain of the cross-domain cross-chain authentication system, the target block added when authenticating the write request for the data read by the target read request, based on the identification information carried in the target read request indicating the data read; and determining the authentication nodes participating in the on-chaining of the target block based on the target block. In this way, the m authentication nodes participating in the data consistency authentication of the write request for the data read by the target read request can be determined.

[0094] The present application will now be described in further detail with reference to exemplary application embodiments.

[0095] In a cross-domain cluster scenario, assuming a multi-domain cluster's nodes are deployed across R domains, and each domain has n nodes, the total number of nodes N in the multi-domain cluster can be R*n, where R is a positive integer greater than 1 and n is a positive integer greater than or equal to 1. To ensure read efficiency, the multi-domain cluster can be divided into one or more master nodes and M replica nodes, depending on their roles. The master node handles client data operation requests (such as write and read requests) and synchronizes these requests to the replica nodes. The replica nodes are used for backup and failover, and every two nodes are interconnected. M is a positive integer greater than 1. The master node can be forcibly set or dynamically elected. The authentication node can be either a master node or a replica node.

[0096] Clients can connect to the master node in any domain of a multi-domain cluster to communicate with the cluster and perform cross-domain data operations. Typically, write requests are sent to the master node to ensure data consistency. The master node is responsible for synchronizing data to the replica nodes, which can only perform read operations. When the master node fails, the cluster automatically elects a replica node as the new master node. At this time, the client's connection information is updated to ensure the continued operation of the distributed system.

[0097] To address the data storage security and data authentication reliability issues faced in cross-domain cluster systems, this application proposes an application embodiment of a distributed cross-domain multi-chain authentication system, which is exemplarily described in the following two parts: (1) Cross-domain and cross-chain authentication system based on single-domain single-authentication node model To address the data storage security and data authentication reliability issues faced in cross-domain clusters, this application example proposes a cross-domain cluster comprising multiple domains, each domain including multiple nodes, and each domain's nodes including an authentication node. The authentication node is used for cross-domain, cross-chain authentication of data requests based on blockchain technology. Thus, the multiple authentication nodes located in multiple domains constitute a cross-domain, cross-chain authentication system (also known as cross-domain, cross-chain authentication). For example, when the number of nodes in a single domain is less than a threshold β, for a single domain, one node from each domain can be randomly selected as the authentication node.

[0098] This application example proposes, as follows: Figure 4 The diagram shown illustrates the single-domain, single-authentication node model, and as shown below... Figure 5 The diagram shows the framework of a cross-domain, cross-chain authentication system based on a single-domain, single-authentication-node model. Figure 4 The diagram shows the network framework of a single-domain, single-authentication-node model, which includes one authentication node. Figure 4 The diagram shows the network framework of a cross-domain, cross-chain authentication system consisting of three domains based on a single-domain, single-authentication-node model.

[0099] like Figure 4 As shown, taking n=4 as an example, each domain can include 4 nodes. The 4 nodes can be divided into: 1 Authorization Node (Auth Node) and 3 other nodes. The 1 Authorization Node is Authorization Node 1. The 3 other nodes can include Node 1, Node 2 and Node 3. Every two nodes are interconnected. Each Authorization Node can be deployed with a blockchain (such as a private blockchain). Each other node can be without a blockchain.

[0100] like Figure 5 As shown, taking R=3 as an example, the cross-domain cluster includes 3 domains: Domain 1 (denoted as AZ1), Domain 2 (denoted as AZ2), and Domain 3 (denoted as AZ3). Each domain adopts the following... Figure 4The single-domain, single-authentication-node model shown implies that each domain is equipped with one authentication node. Therefore, the cross-domain, cross-chain authentication system can include: Auth Node 1 located in domain 1 (AZ1), Auth Node 2 located in domain 2 (AZ2), and Auth Node 3 located in domain 3 (AZ3). The cross-domain, cross-chain authentication system includes three authentication nodes located in three domains. In other words, the cross-domain, cross-chain authentication system includes multiple authentication nodes located in multiple domains. Each authentication node can perform data consistency authentication for cross-domain data operation requests. The blockchain deployed by the cross-domain, cross-chain authentication system adopts a multi-chain blockchain network based on a directed acyclic graph (DAG) and uses a multi-chain consensus mechanism based on a directed acyclic graph (DAG).

[0101] Thus, since multiple authentication nodes are distributed across multiple domains, cross-domain authentication can be achieved through the cross-domain cross-chain authentication system. Furthermore, because the blockchain deployed by the cross-domain cross-chain authentication system adopts a multi-chain blockchain network based on a directed acyclic graph (DAG), cross-chain authentication can be achieved through the system, ensuring the disaster recovery capabilities of the cross-domain cluster. Moreover, since each domain has one node added as an authentication node to the cross-domain cross-chain authentication system, if an authentication node in one domain fails, cross-domain data security can be ensured by performing cross-domain data authentication through authentication nodes in other domains.

[0102] (2) Cross-domain and cross-chain authentication system based on single-domain multi-authentication node model This application example proposes a cross-domain cluster, comprising multiple domains, each domain including multiple nodes, and each domain's nodes including multiple authentication nodes. These authentication nodes are used for cross-domain, cross-chain authentication of data requests based on blockchain technology. Thus, the multiple authentication nodes located in multiple domains constitute a cross-domain, cross-chain authentication system. For example, to ensure authentication efficiency in a large-scale cluster and reduce the load pressure on authentication nodes under high data traffic, when the number of nodes in each domain is greater than or equal to a threshold β, multiple nodes from each domain are randomly selected to join the cross-domain, cross-chain authentication system as authentication nodes. For example, when the number of nodes in each domain is greater than or equal to β and less than 2β, two nodes from each domain are randomly selected as authentication nodes to join the cross-domain, cross-chain authentication system; when the number of nodes in each domain is greater than or equal to 2β and less than 3β, three nodes from each domain are randomly selected as authentication nodes to join the cross-domain, cross-chain authentication system.

[0103] This application example proposes, as follows: Figure 6 The diagram shown illustrates the single-domain multi-authentication node model, and as shown below... Figure 7 The diagram shows the framework of a cross-domain, cross-chain authentication system based on a single-domain, multi-authentication-node model. Figure 6The diagram shows the network framework of a single-domain multi-authentication node model, which includes two authentication nodes. Figure 7 The diagram shows the network framework of a cross-domain, cross-chain authentication system consisting of three domains based on a single-domain, multi-authentication-node model.

[0104] like Figure 6 As shown, taking n=5 as an example, each domain can include 5 nodes. The 5 nodes can be divided into 2 authentication nodes and 3 other nodes. The 2 authentication nodes can include Authentication Node 1 (Auth Node1) and Authentication Node 2 (Auth Node2). The 3 other nodes can include Node 1, Node 2 and Node 3. Each pair of nodes is interconnected. Each authentication node can be deployed with a blockchain (such as a private blockchain), and each other node can be without a blockchain.

[0105] like Figure 7 As shown, still taking R=3 as an example, the cross-domain cluster includes 3 domains: Domain 1 (denoted as AZ1), Domain 2 (denoted as AZ2), and Domain 3 (denoted as AZ3). Each domain adopts the following... Figure 6 The single-domain multi-authentication node model shown depicts two authentication nodes for each domain. Therefore, the cross-domain cross-chain authentication system can include: Auth Node 1 and Auth Node 2 in domain 1 (AZ1), Auth Node 3 and Auth Node 4 in domain 2 (AZ2), and Auth Node 5 and Auth Node 6 in domain 3 (AZ3). The cross-domain cross-chain authentication system comprises six authentication nodes across three domains. Each authentication node can perform data consistency authentication for cross-domain data operation requests and for same-domain data operation requests. The blockchain deployed in the cross-domain cross-chain authentication system adopts a multi-chain blockchain network based on a Directed Acyclic Graph (DAG) and uses a multi-chain consensus mechanism based on a DAG.

[0106] Thus, since multiple authentication nodes are distributed across multiple domains, cross-domain authentication can be achieved through the cross-domain cross-chain authentication system. Furthermore, because the blockchain deployed by the cross-domain cross-chain authentication system adopts a multi-chain blockchain network based on a directed acyclic graph (DAG), cross-chain authentication can be achieved through the system, ensuring the disaster recovery capabilities of the cross-domain cluster. Moreover, since multiple nodes from each domain join the cross-domain cross-chain authentication system as authentication nodes, the disaster recovery capabilities of the cross-domain cluster are more robust, tolerating not only the failure of some authentication nodes in other domains but also the failure of some authentication nodes within the same domain, ensuring a balanced distribution of authentication nodes.

[0107] This application also proposes an application embodiment, which presents an adjustable K+M redundant signature authentication method based on key sharing for cross-domain and cross-chain authentication systems. The process can include four parts: key generation, key signing, local signature aggregation, and public key authentication. These four parts are described below: (1) Local key generation.

[0108] In cross-domain multi-chain authentication scenarios, through r authentication nodes in the cross-domain cross-chain authentication system, a set of local keys with K redundancy is generated based on the private key S, where r = K + M, M is the number of replica nodes, K is the preset redundancy, and a preset consistency threshold m is set. Then, the K + M authentication nodes can secretly share the private key S based on a (m, K + M) threshold mechanism, that is, the private key S is divided into K + M local keys and distributed to the K + M authentication nodes (i.e., the Q authentication nodes mentioned above). , The reconstructor needs to obtain the local keys stored by at least m authentication nodes to recover the private key S. That is, the reconstructor needs to obtain the local signatures generated by at least m authentication nodes based on their stored local keys to recover the signature of the corresponding aggregate, and then verify the signature of the aggregate based on the public key corresponding to the private key S.

[0109] The process of generating a set of local keys with K redundancy may include: Step 1: Treat the private key S as a constant term of a polynomial; Step 2: Divide the private key S into K+M local keys using the other coefficients of the polynomial; where, ; Step 3: Set a consistency threshold m, which means that a complete private key S can be aggregated from at least m local keys out of K+M local keys. If there are fewer than m local keys, the key S cannot be reconstructed, where m is less than M.

[0110] The key generation formula is as follows: (1); Where S represents the private key. Representing a polynomial m-1 coefficients.

[0111] For example, coefficients a1 to a m-1 It can be a random number to ensure security.

[0112] Randomly select K+M different x values Calculate the value corresponding to each x. By calculating the value, we can obtain K+M scatter pairs. Thus, K+M local keys are obtained.

[0113] K+M authentication nodes are randomly selected, and K+M local keys are sent to each of the K+M authentication nodes, with each authentication node holding one copy of the local key.

[0114] (2) Key signature collection.

[0115] Each write request initiated by a user is recorded as a separate block. The authentication node signs this block using its local key; that is, the authentication node writes a local signature generated based on its local key into the block. Thus, by dividing the private key S into K+M local keys and distributing them to K+M authentication nodes, K redundant local signatures can be achieved. Therefore, the system can tolerate a maximum of K node failures, ensuring high reliability and data consistency.

[0116] (3) Consistency threshold signature aggregation.

[0117] Once the number of local key signatures collected by a node reaches the consistency threshold m, the m local signatures on the block corresponding to the write request initiated by the user can be aggregated to obtain an aggregated signature (which is equivalent to a complete signature generated based on the private key S). In other words, any combination that reaches the signature threshold can be aggregated into a complete signature, and the aggregated signature can be verified based on the public key corresponding to the private key S.

[0118] Similarly, the signature aggregation method is similar to the key aggregation method.

[0119] For example, key aggregation uses polynomials created by Lagrange interpolation. Lagrange interpolation is a mathematical method for polynomial interpolation, given m local keys (…). , For any x, j = 1, ..., m, a polynomial P(x) can be constructed such that... For all It is valid. The Lagrange interpolation polynomial is shown in formula (2), and the Lagrange basis functions are... As shown in formula (3): (2); (3); Where m is the number of local keys, and i and j are variables, ( , ) represents the j-th local key, j=1,…,m.

[0120] Thus, after obtaining m local keys, the private key S can be reconstructed according to formulas (2) and (3).

[0121] (4) Cross-domain public key authentication.

[0122] After obtaining the aggregated signature based on m signatures, each authentication node can verify the aggregated signature using its public key. If the verification is successful, the data consistency of the write request can be considered to have high reliability.

[0123] The public key is used to encrypt information and verify digital signatures, while the private key is used to decrypt received encrypted information and create digital signatures.

[0124] This application also proposes an application embodiment, which provides an authentication method that may include: S1. When a user needs to perform data operations, a data operation request is received from the client.

[0125] S2. Determine whether the data operation request is a write request or a read request.

[0126] S3. When the data operation request sent by the client is a write request, each write request is recorded as a separate block, and the block corresponding to the target write request is obtained.

[0127] S4. Generate K+M local keys and send the K+M local keys to K+M authentication nodes.

[0128] For example, the authentication node stores its corresponding local key in its local private blockchain.

[0129] For example, K represents the preset redundancy, which indicates the maximum number of faulty nodes that can be tolerated. M represents the number of replica nodes in a cross-domain cluster.

[0130] S5. Through the authentication node in the cross-domain cross-chain authentication system, the write request is digitally signed based on the local key held by the authentication node, generating a local signature, and this local signature is appended to the block corresponding to the write request. That is, the block includes: the write request and the local signature. For example, the authentication node stores the generated local signature in its local private blockchain.

[0131] For example, the authentication node uses a hash function to hash the write request, generating a hash value for the write request; the authentication node then uses its stored local key to encrypt the hash value of the write request, generating a local signature. Hash functions include, for example, MD5, SHA, and RIPEMD-160. A key characteristic of hash functions is their ability to convert data of any size into a fixed-length string (e.g., 32-bit or 64-bit), which is called a hash value or digest.

[0132] S6. After collecting m local signatures generated by m authentication nodes in the block corresponding to the write request, each authentication node can obtain m local signatures from the block corresponding to the write operation. These m local signatures are then aggregated to obtain an aggregated signature. The aggregated signature is verified using the public key. If the signature verification passes, the data consistency is considered highly reliable, and the data consistency authentication result of the write request is deemed successful. After successful verification, the block corresponding to the write request can be successfully added to the blockchain, and the link pointing to this block can be actively selected by the authentication node that attached the local signature.

[0133] For example, after a block is added to the blockchain, the newly added block can be actively selected by the certified nodes for linking, such as... Figure 8 As shown, in Authentication Node 1 (indicated by the dashed line), the precursor block is linked by the authentication node, and subsequent blocks are linked by the preceding block of the authentication node. Blocks linked to Authentication Node 1 form the main chain of Authentication Node 1. Other authentication nodes are similar. Compared to related technologies where the blockchain links from newly added blocks to predecessor blocks, causing newly added blocks to wait for the next block to be selected and linked before being authenticated, in this application, for blocks that need to be added to the chain, the authentication node actively selects a link pointing to the block corresponding to the target write request, which improves the authentication efficiency of blocks and solves the problem of slow authentication when the block addition rate is low.

[0134] S7. When the client sends a read request, since each authentication node stores the generated local signature in its local private chain, the m local signatures and public key corresponding to the read request can be obtained from the blockchain. The m local signatures and public key corresponding to the read request are generated when performing data consistency authentication for the write request on the data read by the target read request.

[0135] S8. Aggregate the m local signatures corresponding to the read request to obtain the aggregated signature corresponding to the read request, and verify the aggregated signature corresponding to the target read request based on the public key corresponding to the target read request. S9. When signature verification passes, it indicates that the signature of the current aggregation is consistent with the signature of the historical aggregation, determining that the data consistency has high credibility, and confirming that the data consistency authentication result of the read request is passed. The data read by the read request is then returned to the client. Alternatively, when signature verification fails, it indicates that the signature of the current aggregation is inconsistent with the signature of the historical aggregation, determining that the data consistency authentication has low credibility, and the data read by the read request is refused to be returned to the client.

[0136] Therefore, the authentication method provided in this application selects at least one node from each domain of the cross-domain cluster to join a blockchain-based cross-domain and cross-chain authentication system. Upon receiving a write request, it sends K+M local keys for signing to K+M authentication nodes in the cross-domain and cross-chain authentication system, thus selecting K+M authentication nodes to participate in authentication and avoiding the need for all authentication nodes to participate. Furthermore, a consistency authentication threshold m is set; once m local signatures are collected, verification can be performed on the m local signatures based on the public key, avoiding waiting for all local key signatures to be collected and ensuring the efficiency of data consistency authentication. And, when verification passes, the data consistency authentication is confirmed, and the block corresponding to the target write request is added to the blockchain. This enables efficient cross-domain cluster data consistency authentication, thereby ensuring data security and trustworthiness. Subsequently, upon receiving a read request, data consistency authentication is performed based on the m local signatures and the public key corresponding to the read request. When the signature verification of the aggregated signature obtained from the m local signatures passes using the public key, it can be determined that the data read by the read request has high data consistency and trustworthiness in the cross-domain cluster, and the data read by the read request is returned to the client. This ensures that the data returned by the node has high trustworthiness. Furthermore, in the event of a malicious node, the security risks caused by malicious nodes tampering with the data stored on the node can be avoided, greatly improving the availability of the cluster.

[0137] When the authentication method provided in this application is applied to the field of distributed cross-domain storage, it has the following advantages compared with related distributed cross-domain storage technologies: Distributed cross-domain storage technologies in related fields often face significant security vulnerabilities. If an attacker maliciously tampers with the database, it will severely impact database decision-making. The authentication method provided in this application equips a multi-domain cluster with one or more authentication nodes, offering a cross-domain, cross-chain authentication system for cross-domain storage. The authentication nodes are deployed with blockchain technology, ensuring immutability. Furthermore, the number of authentication nodes can be adaptively adjusted according to the cluster size.

[0138] Related technologies rely on the security and reliability of nodes for cross-domain data, lacking data consistency and trustworthiness verification, and thus risk returning false data. The authentication method provided in this application, based on a cross-domain, cross-chain authentication system, uses distributed, adjustable, redundant signatures to authenticate the data consistency of cross-domain data, enhancing the security and consistency trustworthiness of distributed cross-domain data. Furthermore, when the authentication node signs based on a local key, each local key and local signature can be stored in the authentication node's private chain, ensuring traceability. This method is suitable for industrial internet application scenarios.

[0139] The latency of related technologies is extremely high in scenarios with slow block growth. However, the authentication method provided in this application adopts a method in which the authentication node actively selects the blocks to be added to the chain, which solves the problem of slow authentication when the block addition rate is low and can solve the problem of poor real-time performance in scenarios with slow block growth.

[0140] This application also provides an authentication device applied to a blockchain-based cross-domain and cross-chain authentication system, which includes multiple authentication nodes located in multiple domains of a cross-domain cluster; such as Figure 9 As shown, the device may include: Unit 901 is used to obtain the block corresponding to the target write request; The sending unit 902 is used to send Q local keys to Q authentication nodes among multiple authentication nodes, so that the Q authentication nodes respectively sign the target write request according to the received local keys and store the generated local signatures into the block; where Q is a positive integer greater than 1; The determining unit 903 is used to determine the data consistency authentication result of the target write request based on the public key and the m local signatures in the block when the number of local signatures in the block reaches m; where m is less than Q.

[0141] It should be noted that the descriptions of the above device embodiments are similar to those of the above method embodiments, and have similar beneficial effects. For technical details not disclosed in the device embodiments of this application, those skilled in the art should refer to the descriptions of the method embodiments of this disclosure for understanding. Further details will not be repeated here.

[0142] This application embodiment also provides an electronic device, which may include: Memory is used to store executable instructions or computer programs. When a processor executes computer-executable instructions or computer programs stored in memory, it implements one or more of the authentication methods provided in the embodiments of this application.

[0143] Figure 10 This is a schematic diagram of the structure of an electronic device provided in an embodiment of this application. This electronic device can be applied to... Figure 2 In one authentication method provided in the corresponding embodiment, such as... Figure 10 As shown, the electronic device 1000 may include a processor 1001, a memory 1002, and a bus system 1003. The various components in the electronic device 1000 are coupled together via the bus system 1003. Wherein: Bus system 1003 is used to realize the communication connection between processor 1001 and memory 1002; Memory 1002 is used to store computer-executable instructions or computer programs; The processor 1001 is configured to execute computer-executable instructions or computer programs stored in the memory 1002 to implement the authentication method in one or more of the exemplary embodiments described above.

[0144] In some exemplary embodiments, the bus system 1003 may include, in addition to a data bus, a power bus, a control bus, and a status signal bus, etc. However, for the sake of clarity, in... Figure 10 The general labeled all buses as Bus System 1003.

[0145] In some exemplary embodiments, the electronic device can be a computing device of various forms, such as a server. The server can be a standalone physical server, a server cluster or distributed system consisting of multiple physical servers, or a cloud server that provides cloud computing services.

[0146] In some exemplary embodiments, the processor may be an integrated circuit chip with signal processing capabilities, such as a general-purpose processor, a digital signal processor (DSP), or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, etc., wherein the general-purpose processor may be a microprocessor or any conventional processor, etc.

[0147] This application also provides a computer-readable storage medium storing computer-executable instructions or a computer program. When the computer-executable instructions or the computer program are executed by a processor, the authentication method provided in this application can be implemented. For example, ... Figure 2 The authentication method is shown.

[0148] This application also provides a computer program product, which includes a computer program or computer-executable instructions. When the computer-executable instructions or the computer program are executed by a processor, the authentication method provided in this application can be implemented. For example, ... Figure 2 The authentication method is illustrated. For example, the computer program or computer-executable instructions are stored in a computer-readable storage medium, the processor of the electronic device reads the computer program or computer-executable instructions from the computer-readable storage medium, and the processor executes the computer program or computer-executable instructions, causing the electronic device to perform the authentication method provided in the embodiments of this application.

[0149] In some exemplary embodiments, the aforementioned computer-readable storage medium / memory may be a read-only memory (ROM), a programmable read-only memory (PROM), an erasable programmable read-only memory (EPROM), an electrically erasable programmable read-only memory (EEPROM), a magnetic random access memory (FRAM), a flash memory, a magnetic surface memory, an optical disc, or a compact disc read-only memory (CD-ROM), etc.; or it may be various terminals including one or any combination of the above-mentioned memories, such as mobile phones, computers, tablet devices, personal digital assistants, etc.

[0150] In some embodiments, a computer program or computer-executable instructions may take the form of a program, software, software module, script, or code, written in any form of programming language (including compiled or interpreted languages, or declarative or procedural languages), and may be deployed in any form, including as a standalone program or as a module, component, subroutine, or other unit suitable for use in a computing environment.

[0151] As an example, a computer program or computer-executable instructions may, but not necessarily, correspond to a file in a file system. It may be stored as part of a file that holds other programs or data, for example, in one or more scripts in a Hyper Text Markup Language (HTML) document, in a single file dedicated to the program in question, or in multiple collaborating files (e.g., a file that stores one or more modules, subroutines, or code sections).

[0152] As an example, a computer program or computer-executable instructions may be deployed to execute on one electronic device, or on multiple electronic devices located at one location, or on multiple electronic devices distributed across multiple locations and interconnected by a communication network.

[0153] It should be noted that the descriptions of the above device, storage medium, or product embodiments are similar to the descriptions of the above method embodiments, and have similar beneficial effects. For technical details not disclosed in the device, storage medium, or product embodiments of this application, those skilled in the art should refer to the descriptions of the method embodiments of this disclosure for understanding. Further details will not be repeated here.

[0154] The features disclosed in the several methods, devices, storage media or product embodiments provided in this application can be arbitrarily combined without conflict to obtain new method embodiments, devices, storage media or product embodiments.

[0155] The above description is merely an embodiment of this application and is not intended to limit the scope of protection of this application. Any modifications, equivalent substitutions, and improvements made within the spirit and scope of this application are included within the scope of protection of this application.

Claims

1. An authentication method, characterized in that, An application to a blockchain-based cross-domain, cross-chain authentication system, wherein the cross-domain, cross-chain authentication system includes multiple authentication nodes located in multiple domains of a cross-domain cluster; the method includes: Obtain the block corresponding to the target write request; Q local keys are sent to Q authentication nodes among the plurality of authentication nodes, so that the Q authentication nodes respectively sign the target write request according to the received local keys and store the generated local signatures into the block; where Q is a positive integer greater than 1; When the number of local signatures in the block reaches m, the data consistency authentication result of the target write request is determined based on the public key and the m local signatures in the block; where m is less than Q.

2. The method according to claim 1, characterized in that, The Q local keys are obtained by splitting the private key according to the number of replica nodes in the cross-domain cluster and a preset redundancy. The preset redundancy is used to represent the maximum number of faulty nodes that can be tolerated, and m is less than the number of replica nodes in the cross-domain cluster.

3. The method according to claim 1, characterized in that, Each of the multiple domains in the cross-domain cluster includes multiple nodes; the method further includes: selecting a target number of nodes from the multiple nodes in each domain as the authentication nodes and adding them to the cross-domain cross-chain authentication system, wherein the target number is determined based on the number of nodes in each domain and a preset threshold.

4. The method according to any one of claims 1 to 3, characterized in that, The blockchain of the cross-domain cross-chain authentication system is a multi-chain blockchain network based on a directed acyclic graph; the method further includes: When the data consistency authentication result of the target write request is passed, the block is added to the blockchain of the cross-domain cross-chain authentication system.

5. The method according to claim 4, characterized in that, After adding the block to the blockchain of the cross-domain cross-chain authentication system, the method further includes: The authentication node that writes a local signature in the block selects a link pointing to the block.

6. The method according to any one of claims 1 to 3, characterized in that, The determination of the data consistency authentication result of the target write request based on the public key and m local signatures in the block includes: The m local signatures in the block are aggregated to obtain the aggregated signature; Based on the public key, the signature of the aggregate is verified; If the signature verification passes, the data consistency authentication result of the target write request is determined to be passed; or, if the signature verification fails, the data consistency authentication result of the target write request is determined to be failed.

7. The method according to any one of claims 1 to 3, characterized in that, The method further includes: Obtain the target read request; Obtain m local signatures and public keys corresponding to the target read request; wherein, the m local signatures and public keys corresponding to the target read request are generated when performing data consistency authentication for the write request of the data read by the target read request; Based on the m local signatures and public keys corresponding to the target read request, the data consistency authentication result of the target read request is determined.

8. An authentication device, characterized in that, An application to a blockchain-based cross-domain, cross-chain authentication system, wherein the cross-domain, cross-chain authentication system includes multiple authentication nodes located in multiple domains of a cross-domain cluster; the device includes: The acquisition unit is used to obtain the block corresponding to the target write request; The sending unit is configured to send Q local keys to Q authentication nodes among the plurality of authentication nodes, so that the Q authentication nodes respectively sign the target write request according to the received local keys and store the generated local signatures into the block; wherein, Q is a positive integer greater than 1; A determining unit is used to determine the data consistency authentication result of the target write request based on the public key and the m local signatures in the block when the number of local signatures in the block reaches m; where m is less than Q.

9. An electronic device, characterized in that, The electronic device includes: Memory is used to store executable instructions or computer programs. A processor, when executing computer-executable instructions or computer programs stored in the memory, implements the method as described in any one of claims 1 to 7.

10. A computer-readable storage medium storing a computer program or computer-executable instructions, characterized in that, When the computer program or computer-executable instructions are executed by a processor, the method as described in any one of claims 1 to 7 is implemented.

Images