WO2022105565A1 - 一种跨链的区块链通信方法及装置 - Google Patents

一种跨链的区块链通信方法及装置 Download PDF

Info

Publication number
WO2022105565A1
WO2022105565A1 PCT/CN2021/126988 CN2021126988W WO2022105565A1 WO 2022105565 A1 WO2022105565 A1 WO 2022105565A1 CN 2021126988 W CN2021126988 W CN 2021126988W WO 2022105565 A1 WO2022105565 A1 WO 2022105565A1
Authority
WO
WIPO (PCT)
Prior art keywords
cross
chain
node
proxy node
ciphertext
Prior art date
Application number
PCT/CN2021/126988
Other languages
English (en)
French (fr)
Inventor
季一木
肖小英
吴飞
刘尚东
陈飞
王舒
顾惟恒
梅芬
张开翔
范瑞彬
宋一波
Original Assignee
深圳前海微众银行股份有限公司
南京邮电大学
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by 深圳前海微众银行股份有限公司, 南京邮电大学 filed Critical 深圳前海微众银行股份有限公司
Publication of WO2022105565A1 publication Critical patent/WO2022105565A1/zh

Links

Images

Classifications

    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00Network architectures or network communication protocols for network security
    • H04L63/20Network architectures or network communication protocols for network security for managing network security; network security policies in general
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00Network architectures or network communication protocols for network security
    • H04L63/04Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks
    • H04L63/0428Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks wherein the data content is protected, e.g. by encrypting or encapsulating the payload
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00Network architectures or network communication protocols for network security
    • H04L63/12Applying verification of the received information
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00Network arrangements or protocols for supporting network services or applications
    • H04L67/50Network services
    • H04L67/56Provisioning of proxy services
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00Network arrangements or protocols for supporting network services or applications
    • H04L67/50Network services
    • H04L67/56Provisioning of proxy services
    • H04L67/562Brokering proxy services
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/08Key distribution or management, e.g. generation, sharing or updating, of cryptographic keys or passwords
    • H04L9/0816Key establishment, i.e. cryptographic processes or cryptographic protocols whereby a shared secret becomes available to two or more parties, for subsequent use
    • H04L9/0838Key agreement, i.e. key establishment technique in which a shared key is derived by parties as a function of information contributed by, or associated with, each of these
    • H04L9/0847Key agreement, i.e. key establishment technique in which a shared key is derived by parties as a function of information contributed by, or associated with, each of these involving identity based encryption [IBE] schemes
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • H04L9/3236Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials using cryptographic hash functions
    • H04L9/3239Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials using cryptographic hash functions involving non-keyed hash functions, e.g. modification detection codes [MDCs], MD5, SHA or RIPEMD
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • H04L9/3247Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials involving digital signatures
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/50Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols using hash chains, e.g. blockchains or hash trees
    • YGENERAL TAGGING OF NEW TECHNOLOGICAL DEVELOPMENTS; GENERAL TAGGING OF CROSS-SECTIONAL TECHNOLOGIES SPANNING OVER SEVERAL SECTIONS OF THE IPC; TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
    • Y02TECHNOLOGIES OR APPLICATIONS FOR MITIGATION OR ADAPTATION AGAINST CLIMATE CHANGE
    • Y02DCLIMATE CHANGE MITIGATION TECHNOLOGIES IN INFORMATION AND COMMUNICATION TECHNOLOGIES [ICT], I.E. INFORMATION AND COMMUNICATION TECHNOLOGIES AIMING AT THE REDUCTION OF THEIR OWN ENERGY USE
    • Y02D30/00Reducing energy consumption in communication networks
    • Y02D30/50Reducing energy consumption in communication networks in wire-line communication networks, e.g. low power modes or reduced link rate

Definitions

  • Embodiments of the present invention relate to the field of financial technology (Fintech), and in particular, to a cross-chain blockchain communication method and device.
  • Fetech financial technology
  • the access mechanism for CA (Certificate Authority) is used for cross-chain communication between various blockchain platforms in the IoT environment (ie, multiple IoT devices are distributed on different blockchain platforms).
  • IoT device users in each blockchain platform will send a certificate request file to their management node before cross-chain communication, and obtain an identity certificate after their management node signs the certificate request file with their own private key.
  • identity certificate In order to use the identity certificate for identity authentication during cross-chain communication.
  • this processing method needs to consume a lot of computing resources and storage resources because the CA-oriented admission mechanism needs to manage and maintain the generation, issuance, and revocation of a large number of user certificates, resulting in low efficiency of cross-chain communication.
  • Embodiments of the present invention provide a cross-chain block chain communication method and device, so as to ensure the security of cross-chain communication and save computing resources and storage resources.
  • an embodiment of the present invention provides a cross-chain blockchain communication method, which is suitable for a blockchain system with proxy nodes; the proxy nodes are used for cross-connection of nodes in the blockchain system.
  • the chain message is forwarded and received; the method includes:
  • the cross-chain verification node receives the first cross-chain ciphertext sent by the first proxy node; the first cross-chain ciphertext is generated by the first proxy node after consensus on the first cross-chain request initiated by the local chain node;
  • the cross-chain verification node decrypts the first cross-chain ciphertext to obtain a second cross-chain request and verifies the second cross-chain request;
  • the cross-chain verification node After verifying that the second cross-chain request is passed, the cross-chain verification node triggers the blockchain system where the second proxy node is located to process the second cross-chain request.
  • the second cross-chain request is obtained by decrypting the first cross-chain ciphertext and the second cross-chain request is verified. After the second cross-chain request is verified, the blockchain system where the second proxy node is located can be triggered to process. The second cross-chain request.
  • the technical solution is used to forward and receive cross-chain messages of nodes in the blockchain system through the proxy node, and the first cross-chain ciphertext is the first cross-chain request initiated by the first proxy node to the node of this chain It is generated after consensus, and after the second cross-chain request is verified, the blockchain system where the second proxy node is located is triggered to process the second cross-chain request, so the security of cross-chain communication can be ensured.
  • the technical solution does not need to manage and maintain the generation, issuance, revocation, etc. of a large number of user certificates, so it can save computing resources and storage resources, so as to solve the problem of the existing CA-oriented access mechanism in the existing technology, which needs to manage and maintain a large number of user certificates generation, issuance, revocation, etc., resulting in the problem of consuming a lot of computing resources and storage resources.
  • the first cross-chain ciphertext is the IBE ciphertext generated by the first proxy node based on the IBE algorithm; the IBE ciphertext is that the first proxy node encrypts the first concatenated message by using the IBE algorithm. obtained; the first splicing message includes the first cross-chain request, the first digest of the first cross-chain request, and the first signature of the first digest;
  • the cross-chain verification node decrypts the first cross-chain ciphertext to obtain a second cross-chain request and verifies the second cross-chain request, including:
  • the cross-chain verification node decrypts the first cross-chain ciphertext through the IBE algorithm to obtain a second splicing message;
  • the second splicing message includes the second cross-chain request, the first digest and the first sign;
  • the cross-chain verification node determines whether the second digest is consistent with the first digest
  • the cross-chain verification node generates a second signature according to the second digest
  • the cross-chain verification node determines whether the second signature is consistent with the first signature.
  • the first signature of the first digest is a signature generated based on bilinear mapping performed by using the private key of the first proxy node; the first signature is generated in the following manner:
  • the public key and private key of the first agent node have the following relationship:
  • the first signature satisfies the following form:
  • e( ⁇ Q j , d 1 ) is the first signature
  • Q 1 is the public key of the first proxy node
  • is the first digest
  • ⁇ 1 is the second digest
  • Q j is the The public key of the second proxy node or the notary node
  • d 1 is the private key of the first proxy node
  • s is the master key of the third-party PKG.
  • the signature of the digest is generated based on the property of bilinear mapping pairing, which can ensure the immutability and verifiability of the generated signature, and can provide support for the subsequent verification of the authenticity of the identity information of the proxy node.
  • the cross-chain verification node is a notary node
  • the cross-chain verification node After verifying that the second cross-chain request is passed, the cross-chain verification node triggers the blockchain system where the second proxy node is located to process the second cross-chain request, including:
  • the notary node generates a second cross-chain ciphertext according to the second cross-chain request after verifying that the second cross-chain request is passed;
  • the notary node sends the second cross-chain ciphertext to the second proxy node, so that the second cross-chain ciphertext is processed by the blockchain system where the second proxy node is located.
  • the notary node can generate a second cross-chain ciphertext according to the second cross-chain request after passing the second cross-chain request, and send the second cross-chain ciphertext to the second cross-chain request.
  • the chain ciphertext is sent to the second proxy node, so that the identity of the first proxy node can be verified based on the notary node, and the secure communication between the first proxy node and the second proxy node can be realized through the notary node, thereby ensuring cross-chain interaction. Security of data in the process.
  • the generating the second cross-chain ciphertext according to the second cross-chain request includes:
  • the notary node determines whether the blockchain system where the first proxy node is located and the blockchain system where the second proxy node is located have the same configuration
  • the second cross-chain ciphertext is generated according to the second cross-chain request
  • the notary node determines that it does not have the same configuration, it adjusts the second cross-chain request to a third cross-chain request according to the configuration of the blockchain system where the second proxy node is located, and according to the The third cross-chain request generates the second cross-chain ciphertext.
  • the configuration of the blockchain system where the second proxy node is located is adjusted according to the configuration of the blockchain system where the second proxy node is located.
  • the second cross-chain request so as to ensure that the adjusted data format of the second cross-chain request matches the configuration of the blockchain system where the second proxy node is located. Secure communication between two proxy nodes.
  • the cross-chain verification node is a second proxy node
  • the method further includes:
  • the second proxy node and the first proxy node perform mutual identity confirmation; the identity confirmation is initiated by the first proxy node after receiving the configuration consistency indication sent by the notary node; the configuration consistency indication is Sent by the notary node when it is determined that the blockchain system where the first proxy node is located has the same configuration as the blockchain system where the second proxy node is located.
  • the cross-chain verification node is the second proxy node
  • the first proxy node and the second proxy node perform mutual identity confirmation after receiving the configuration consistency instruction, so that the first proxy node, The authenticity of the identity information of the second proxy node in order to ensure the security of subsequent cross-chain communication, and to provide support for message non-repudiation when a dispute over message authenticity occurs between subsequent proxy nodes.
  • the mutual identity confirmation between the second proxy node and the first proxy node includes:
  • the second proxy node generates first authentication information based on the first random number and sends it to the first proxy node; the first authentication information is used by the first proxy node to perform identity authentication on the second proxy node ;
  • the second proxy node receives the second authentication information sent by the first proxy node and verifies the second authentication information; the second authentication message is generated by the first proxy node based on the second random number .
  • the second proxy node generates the first authentication information based on the first random number and sends it to the first proxy node, and the first proxy node generates the second authentication information based on the second random number and sends it to the second proxy node.
  • the technical solution can accurately verify the authenticity of the identity information of the first proxy node and the second proxy node by verifying the first authentication information and the second authentication information.
  • the cross-chain verification node is a notary node
  • the first cross-chain ciphertext is a signed ciphertext generated by the first proxy node through a signature mechanism; the signed ciphertext includes a signature for the first cross-chain request and the first cross-chain request;
  • the cross-chain verification node After verifying that the second cross-chain request is passed, the cross-chain verification node triggers the blockchain system where the second proxy node is located to process the second cross-chain request, including:
  • the notary node determines that the blockchain system where the first proxy node is located does not have the same configuration as the blockchain system where the second proxy node is located, according to the block where the second proxy node is located The configuration of the chain system, adjusting the second cross-chain request to a third cross-chain request, and generating the second cross-chain ciphertext according to the third cross-chain request;
  • the notary node sends the second cross-chain ciphertext to the second proxy node.
  • the cross-chain verification node is a notary node
  • the notary node determines that the blockchain system where the first proxy node is located does not have the same configuration as the blockchain system where the second proxy node is located
  • the The configuration of the blockchain system where the second proxy node is located adjusts the second cross-chain request, so as to ensure that the adjusted data format of the second cross-chain request matches the configuration of the blockchain system where the second proxy node is located, so that the This can help to realize the secure communication between the first proxy node and the second proxy node.
  • an embodiment of the present invention provides a cross-chain blockchain communication method, which is suitable for a blockchain system with proxy nodes; the proxy nodes are used for cross-connection of nodes in the blockchain system.
  • the chain message is forwarded and received; the method includes:
  • the first proxy node generates a first cross-chain ciphertext based on the first cross-chain request after consensus on the first cross-chain request initiated by the local chain node;
  • the first proxy node sends the first cross-chain ciphertext to the cross-chain verification node; the cross-chain verification node is used to decrypt the first cross-chain ciphertext to obtain the second cross-chain request and pass the verification.
  • the blockchain system where the second proxy node is located is triggered to process the second cross-chain request.
  • the first proxy node can generate the first cross-chain ciphertext based on the first cross-chain request after consensus on the first cross-chain request initiated by the local chain node, and send the first cross-chain ciphertext to Cross-chain verification node, so that the cross-chain verification node decrypts the first cross-chain ciphertext to obtain the second cross-chain request, and after passing the second cross-chain request, triggers the blockchain system where the second proxy node is located to process the second cross-chain request ask.
  • the technical solution is used to forward and receive cross-chain messages of nodes in the blockchain system through the proxy node, and the first cross-chain ciphertext is the first cross-chain request initiated by the first proxy node to the node of this chain It is generated after consensus, and after the cross-chain verification node verifies that the second cross-chain request is passed, the blockchain system where the second proxy node is located is triggered to process the second cross-chain request, so the security of cross-chain communication can be ensured.
  • the technical solution does not need to manage and maintain the generation, issuance, revocation, etc. of a large number of user certificates, so computing resources and storage resources can be saved.
  • the first proxy node after the first proxy node reaches a consensus on the first cross-chain request initiated by the local chain node, generates a first cross-chain ciphertext based on the first cross-chain request, including:
  • a signed ciphertext is generated based on the first cross-chain request
  • the method further includes:
  • the first proxy node receives the configuration consistency indication sent by the cross-chain verification node; the configuration consistency indication is that the cross-chain verification node passes the verification of the signed ciphertext and the first proxy node is located in the area. Sent when the blockchain system and the blockchain system where the second agent node is located have the same configuration;
  • the first proxy node encrypts the first splicing message through the IBE algorithm to obtain an IBE ciphertext;
  • the first splicing message includes the first cross-chain request, the first digest of the first cross-chain request, and the The first signature of the first digest;
  • the first proxy node sends the IBE ciphertext to the second proxy node.
  • the IBE ciphertext is obtained by encrypting the first concatenated message through the IBE algorithm, and the IBE ciphertext is sent to the second proxy node, so that the proxy can be avoided.
  • the first proxy node after the first proxy node reaches a consensus on the first cross-chain request initiated by the local chain node, generates a first cross-chain ciphertext based on the first cross-chain request, including:
  • the first proxy node After the first proxy node reaches a consensus on the first cross-chain request initiated by the local chain node, it encrypts the first splicing message through the IBE algorithm to obtain the IBE ciphertext; the first splicing message includes the first cross-chain request, the The first digest of the first cross-chain request and the first signature of the first digest.
  • the IBE ciphertext is obtained by encrypting the first concatenated message based on the IBE algorithm, so that the risk of leakage of the generated cross-chain ciphertext can be avoided, thereby ensuring the security of the generated cross-chain ciphertext.
  • the first proxy node is determined according to the following manner:
  • each node in the blockchain system based on a preset election rule, determine the local density of each node;
  • the node corresponding to the maximum local density and the maximum distance is determined as the first proxy node.
  • the local density of each node and the distance between nodes are determined through the preset election rules, and the local density of each node and the distance between nodes are processed, so that the proxy node can be accurately and efficiently determined, and The random fairness of the selection of proxy nodes can be ensured.
  • an embodiment of the present invention provides a cross-chain blockchain communication device, which is suitable for a blockchain system with proxy nodes; the proxy nodes are used for cross-connection of nodes in the blockchain system.
  • the chain message is forwarded and received; the device includes:
  • a receiving unit configured to receive the first cross-chain ciphertext sent by the first proxy node; the first cross-chain ciphertext is generated after the first proxy node agrees on the first cross-chain request initiated by the local chain node;
  • the first processing unit is used for decrypting the first cross-chain ciphertext to obtain a second cross-chain request and verifying the second cross-chain request; after verifying the second cross-chain request, triggering the location of the second proxy node
  • the blockchain system processes the second cross-chain request.
  • an embodiment of the present invention provides a cross-chain blockchain communication device, which is suitable for a blockchain system with proxy nodes; the proxy nodes are used for cross-connection of nodes in the blockchain system.
  • the chain message is forwarded and received; the device includes:
  • a generating unit configured to generate a first cross-chain ciphertext based on the first cross-chain request after consensus is reached on the first cross-chain request initiated by the node of the local chain;
  • the second processing unit is configured to send the first cross-chain ciphertext to the cross-chain verification node; the cross-chain verification node is configured to decrypt the first cross-chain ciphertext to obtain a second cross-chain request and pass the verification After the second cross-chain request, the blockchain system where the second proxy node is located is triggered to process the second cross-chain request.
  • an embodiment of the present invention provides a computing device, including:
  • the processor is used to call the computer program stored in the memory, and execute the cross-chain blockchain communication method according to the obtained program.
  • an embodiment of the present invention provides a computer-readable storage medium, where the computer-readable storage medium stores a computer-executable program, and the computer-executable program is used to enable a computer to execute a cross-chain blockchain communication method .
  • FIG. 1 is a schematic diagram of a system architecture for cross-chain communication according to an embodiment of the present invention
  • FIG. 2 is a schematic flowchart of a cross-chain blockchain communication method provided by an embodiment of the present invention
  • FIG. 3 is a schematic diagram of determining a public key and a private key of an agent node according to an embodiment of the present invention
  • FIG. 4 is a schematic structural diagram of a cross-chain blockchain communication device according to an embodiment of the present invention.
  • FIG. 5 is a schematic structural diagram of another cross-chain blockchain communication device provided by an embodiment of the present invention.
  • Bilinear mapping Let G 1 be an additive cyclic group whose generator is P, the order is p, G 2 is a multiplicative cyclic group with the same order as G 1 , and a, b are Z p * (p-order prime numbers elements in a cyclic group). Suppose the discrete logarithm problem for G1 and G2 is intractable. Then a bilinear map is defined as a map e that satisfies the following relation: G 1 ⁇ G 1 ⁇ G 2 . a. Bilinearity:
  • PKG Principal Key Generator
  • PKG is a trusted third party with built-in initialization algorithm that can generate system parameters.
  • the system parameters include the bilinear map e on the elliptic curve, the order q of the elliptic curve, the q-order additive cyclic group G 1 on the elliptic curve, the q-order multiplication cyclic group G 2 on the elliptic curve, and the generator P of the elliptic curve , the system master key s, the system public key P pub . Specifically, it can be shown in Table 1.
  • PKG needs to choose three hash functions, namely H 1 : ⁇ 0,1 ⁇ * ⁇ G 1 , H 2 :G 2 ⁇ 0,1 ⁇ n , H 3 : ⁇ 0,1 ⁇ n ⁇ Z p * .
  • system parameters q, G 1 , G 2 , P, e, P pub , H 1 , H 2 , H 3
  • master key s is kept by PKG.
  • IBE Identity-Based Encryption, Identity-Based Encryption: a public key encryption scheme that uses any string data (such as an email address) that can uniquely identify a user as an encrypted public key.
  • the IBE algorithm is composed of four algorithms: system initialization, key extraction, encryption, and decryption.
  • a System initialization algorithm input a security parameter 1 k , run the system initialization algorithm, and generate system parameters params and master key s.
  • the system parameters params are disclosed to the user, and the master key s is stored in the private key generator PKG;
  • G 1 be a p-order additive cyclic group generated by a generator P
  • G 2 be a p-order multiplication cyclic group
  • bilinear mapping e G 1 ⁇ G 1 ⁇ G 2 .
  • PKG selects the random number s as the master key, s ⁇ Zp * .
  • the public key P pub s ⁇ P is then calculated.
  • public params ⁇ G 1 , G 2 , n, p, e, P, P pub , H 1 , H 2 ⁇ .
  • Key extraction algorithm Input the user identity ID, public parameters params and master key s, run the key extraction algorithm, generate the user private key d ID , and return the corresponding private key.
  • Encryption algorithm Enter the identity ID, system parameters params and plaintext m, run the encryption algorithm, and generate the ciphertext c.
  • d Decryption algorithm: input ciphertext c, user identity ID, private key d ID corresponding to the ID, and system parameters params. Run the decryption algorithm, if the output m indicates that the decryption is successful, otherwise the output ⁇ indicates that the decryption fails.
  • the specific process is: the receiver calculates after receiving the ciphertext get plaintext.
  • the IBE algorithm satisfies the consistency requirement.
  • CA Certificate Authority
  • Consortium chain refers to a blockchain jointly managed by several institutions, which belongs to a type of hybrid blockchain between public and private chains; each institution runs and manages the chain
  • the data of one or more nodes can only be read and written by institutions in the alliance, and transactions can be sent between institutions and jointly record transaction data.
  • Consensus algorithm A consensus algorithm is a program through which all nodes of the blockchain network can reach a consensus on the current state of the distributed ledger. In this way, consensus algorithms enable reliability in blockchain networks and build trust among unknown nodes in a distributed computing environment. Essentially, the consensus protocol ensures that each new block added to the blockchain is the only version that all nodes in the blockchain agree on.
  • PBFT Practical Byzantine Fault Tolerance, Practical Byzantine Fault Tolerance
  • Notary mechanism When the two parties across the chain do not trust each other and the information is asymmetric, the easiest way is to find an intermediary that both parties trust.
  • the notary mechanism is to elect one or a group of trusted nodes as notaries to verify whether a specific event has occurred on blockchain Y, and to prove to the nodes on blockchain X. A group of notaries reaches a consensus on whether an event occurs through a specific consensus algorithm.
  • the notary model is currently the most widely used model.
  • the notary mechanism is one of the easier solutions to achieve interoperability between blockchains. It does not require complex workload proof or equity proof, and is easy to connect to existing blockchain systems.
  • the system architecture shown in FIG. 1 is used as an example to describe the system architecture applicable to the cross-chain communication in the embodiments of the present invention.
  • the system architecture of the cross-chain communication can be applied to the cross-chain communication of each system platform of the Internet of Things in the Internet of Things environment (that is, the Internet of Things devices are distributed in different Internet of Things platforms). limited.
  • the system architecture may include at least two blockchains (blockchain 1 , blockchain 2 , etc.) and a cross-chain notary 102 . Wherein, each blockchain is connected with the cross-chain notary 102, for example, it can be connected in a wired manner, or in a wireless manner, which is not specifically limited.
  • blockchain 1 or blockchain 2 elects its own proxy node through an election algorithm, and uses the elected proxy node as a node for external communication.
  • the proxy node of the blockchain will confirm the cross-chain request through the blockchain consensus module, and then check the cross-chain request.
  • cross-chain information or cross-chain ciphertext is generated based on cross-chain requests according to different application requirements.
  • the proxy node Before sending the cross-chain request, the proxy node first sends the proxy node ID and the system configuration information of the blockchain to which it belongs to the cross-chain notary.
  • the cross-chain notary 102 is responsible for recording the mapping relationship between the proxy node ID and the system configuration information of the blockchain to which it belongs, and sends the proxy node ID to PKG.
  • PKG calculates the private key corresponding to the cross-chain notary and proxy node ID through the IBE algorithm, and returns it to the cross-chain notary and proxy node in a secure manner.
  • the cross-chain notary 102 will verify the cross-chain information or cross-chain ciphertext sent by the proxy node, and perform subsequent communication processing only after the verification is successful.
  • FIG. 1 the structure shown in FIG. 1 above is only an example, which is not limited in this embodiment of the present invention.
  • FIG. 2 exemplarily shows a flow of a cross-chain blockchain communication method provided by an embodiment of the present invention, and the flow may be executed by a cross-chain blockchain communication device.
  • the process specifically includes:
  • Step 201 after the first proxy node agrees on the first cross-chain request initiated by the local chain node, generates a first cross-chain ciphertext based on the first cross-chain request.
  • Step 202 the first proxy node sends the first cross-chain ciphertext to the cross-chain verification node.
  • Step 203 the cross-chain verification node decrypts the first cross-chain ciphertext to obtain a second cross-chain request and verifies the second cross-chain request.
  • Step 204 after the cross-chain verification node has passed the second cross-chain request, triggers the blockchain system where the second proxy node is located to process the second cross-chain request.
  • the first proxy node needs to be determined through a preset election algorithm. Specifically, for each node in the blockchain system, the local density of each node is determined based on the preset election rules. And for each node, determine whether the local density of the node is the largest; if the local density of the node is the largest, determine the maximum distance between the node and other nodes; if the local density of the node is not the largest, then determine Find the minimum distance between this node and other nodes.
  • the first proxy node by processing the local density, maximum distance, and minimum distance of each node, the node with the largest local density and the largest distance is determined as the first proxy node, so that the proxy node can be determined accurately and efficiently. Then, after the first proxy node is determined, the first proxy node can act as a proxy to process the cross-chain request initiated by the local chain node. For example, the first proxy node generates a first cross-chain ciphertext based on the first cross-chain request after consensus on the first cross-chain request initiated by the local chain node. Wherein, for a cross-chain request initiated by any node in the blockchain system where the first proxy node is located, the first proxy node will perform consensus confirmation on the cross-chain request.
  • the cross-chain request is processed according to the hash algorithm or the IBE algorithm, and the first cross-chain ciphertext is generated. Then, the first cross-chain ciphertext is sent to the cross-chain verification node.
  • the first cross-chain ciphertext may be a signed ciphertext generated based on the private key of the proxy node, or may be an IBE ciphertext generated based on an IBE algorithm.
  • the cross-chain verification node receives the first cross-chain ciphertext sent by the first proxy node. If the first cross-chain ciphertext is the IBE ciphertext generated by the first proxy node based on the IBE algorithm, the cross-chain verification node decrypts the first cross-chain ciphertext through the IBE algorithm to obtain a second splicing message, where the second splicing message includes The second cross-chain request, the first digest and the first signature. Then generate a second digest of the second cross-chain request based on the second cross-chain request, and determine whether the second digest is consistent with the first digest.
  • a second signature is generated according to the second digest, and it is determined whether the second signature is consistent with the first signature.
  • the IBE ciphertext generated based on the IBE algorithm is obtained by the first proxy node encrypting the first splicing message through the IBE algorithm; wherein, the first splicing message includes the first cross-chain request and the first digest of the first cross-chain request and the first signature of the first digest.
  • the first signature of the first digest is a signature generated based on bilinear mapping using the private key of the first proxy node; the first signature is generated in the following manner:
  • the public key and private key of the first agent node have the following relationship:
  • e( ⁇ Q j , d 1 ) is the first signature
  • Q 1 is the public key of the first proxy node
  • is the first digest
  • ⁇ 1 is the second digest
  • Q j is the second proxy node or notary node
  • d 1 is the private key of the first proxy node
  • s is the master key of the third-party PKG.
  • the first cross-chain ciphertext is the IBE ciphertext generated by the first proxy node based on the IBE algorithm
  • the cross-chain verification node is a notary node
  • the notary node will verify the second cross-chain request successfully, according to the second cross-chain request.
  • the chain request generates the second cross-chain ciphertext. That is, the notary node determines whether the blockchain system where the first proxy node is located has the same configuration as the blockchain system where the second proxy node is located.
  • the second cross-chain ciphertext is generated according to the second cross-chain request; if it is determined not to have the same configuration, the second cross-chain ciphertext is generated according to the configuration of the blockchain system where the second proxy node is located
  • the request is adjusted to the third cross-chain request, and the second cross-chain ciphertext is generated according to the third cross-chain request, so as to ensure that the adjusted data format of the second cross-chain request is the same as that of the blockchain system where the second proxy node is located.
  • the configurations are matched to enable secure communication between the first proxy node and the second proxy node.
  • the second cross-chain ciphertext is sent to the second proxy node, so that the second cross-chain ciphertext is processed by the blockchain system where the second proxy node is located.
  • the cross-chain verification node is the second proxy node, before receiving the first cross-chain ciphertext sent by the first proxy node, The second proxy node and the first proxy node perform identity confirmation with each other. That is, the second proxy node receives the first identifier sent by the first proxy node, generates first authentication information based on the first random number, and then sends the first authentication information to the first proxy node, where the first authentication information is used for the first authentication information. The proxy node performs identity authentication on the second proxy node.
  • the second authentication information sent by the first proxy node is received and the second authentication information is verified, and the second authentication message is generated by the first proxy node based on the second random number.
  • the first proxy node may generate a second cross-chain ciphertext based on the IBE algorithm and the second cross-chain request, and send the second cross-chain ciphertext to the second proxy node to pass the second proxy
  • the blockchain system where the node is located processes the second cross-chain ciphertext.
  • the identity confirmation is initiated by the first proxy node after receiving the configuration consistency instruction sent by the notary node; Sent when the blockchain systems have the same configuration; the first identifier is used by the notary node to record the mapping relationship between the first identifier of the first proxy node and the configuration of the blockchain system where the first proxy node is located; the first identifier also The third-party PKG can be used to generate the public key and the private key of the first proxy node based on the first identifier.
  • the cross-chain verification node is a notary node.
  • the notary node decrypts the signed ciphertext with its own private key, and obtains the signature of the cross-chain request and the digest of the cross-chain request. Then use the public key of the first proxy node to verify the signature to determine whether the signed ciphertext comes from the first proxy node, so that the authenticity of the signed ciphertext sent by the first proxy node can be verified.
  • the notary node verifies the signature successfully, it determines whether the blockchain system where the first proxy node is located and the blockchain system where the second proxy node is located have the same configuration.
  • the blockchain system where the second proxy node is located has the same configuration, then the signature and ciphertext verification is passed and the blockchain system where the first proxy node is located has the same configuration as the blockchain system where the second proxy node is located. Sent to the first proxy node. Mutual identity authentication is performed between the first proxy node and the second proxy node, and after determining that the identity authentication is successful, the first proxy node generates a second cross-chain ciphertext based on the IBE algorithm and the second cross-chain request, and sends the second cross-chain ciphertext to the second proxy node. The cross-chain ciphertext is sent to the second proxy node to process the second cross-chain ciphertext through the blockchain system where the second proxy node is located.
  • the second cross-chain request is adjusted according to the configuration of the blockchain system where the second proxy node is located. Generate the second cross-chain ciphertext for the third cross-chain request based on the IBE algorithm and the third cross-chain request, so as to ensure that the adjusted data format of the second cross-chain request is consistent with the blockchain system where the second proxy node is located.
  • the configuration of the first proxy node matches the configuration of the second proxy node, so as to realize the secure communication between the first proxy node and the second proxy node.
  • the second cross-chain ciphertext is sent to the second proxy node, so that the second cross-chain ciphertext is processed by the blockchain system where the second proxy node is located.
  • the cross-chain communication scheme based on the IBE algorithm can directly use a string that can uniquely identify user identity information as a public key, thus eliminating the need for public key infrastructure authentication and management of user certificates in the CA-oriented access mechanism. process, and help save a lot of computing and storage resources. Therefore, the embodiment of the present invention adopts the cross-chain communication scheme based on the IBE algorithm, which can be well applied to the Internet of Things environment with a large number of users and limited device resources.
  • Step1 The blockchain elects a proxy node.
  • the election of blockchain proxy nodes will adopt different strategies according to specific applications, and there are many factors to be considered. Different blockchain networks will accept computing nodes with high computing power and high-speed access to the blockchain network according to the different needs of service capacity and transaction efficiency.
  • the selection of the blockchain proxy node in the embodiment of the present invention can be realized by using an election algorithm.
  • the election algorithm adopted in the embodiment of the present invention is a clustering algorithm based on density peaks. In practical application scenarios, other elections can also be used.
  • algorithm which is not limited in this embodiment of the present invention. That is, the corresponding parameters calculated in the nodes with high computing power are compared and selected, and finally the proxy nodes of each blockchain are obtained.
  • This clustering algorithm is based on the assumption that the cluster centers are surrounded by neighbor nodes with lower local densities and that their distance from any node with higher local densities is relatively large, defining the cluster centers as the density of data points the local maximum of . Based on this, proxy nodes can be selected according to the density of nodes in different blockchains.
  • the smaller the E value the smaller the network transmission cost.
  • the network transmission cost can be minimized and optimized through reasonable settings of consensus service nodes and cross-chain exchange nodes, and the efficiency of transactions and consensus in the blockchain network will also be maximized.
  • the local density of blockchain nodes is defined as:
  • d ij is the distance from node i to node j
  • d c is the cutoff distance.
  • ⁇ i is equal to the number of nodes that are closer to node i than dc .
  • the parameters can be set according to the scale of different blockchain network nodes.
  • ⁇ i is obtained by computing the minimum distance between node i and any other node with a higher density.
  • the formula for calculating the minimum distance is:
  • a decision graph can be constructed, and based on the decision graph, a node with a larger distance ⁇ i and a larger local density ⁇ i at the same time is defined as the cluster center (surrogate node) .
  • the optimal exchange node proxy node
  • the calculated optimal exchange node will minimize the cost sum of other nodes and cross-chain exchange nodes exchanging data, Minimize the network transmission cost of cross-chain exchanges.
  • Step2 The proxy node sends the ID of the proxy node and the system configuration information of the blockchain to which it belongs to the cross-chain notary, so that the cross-chain notary can generate the public key and private key of the proxy node based on the ID of the proxy node through the third-party PKG.
  • the ID of each proxy node and the system configuration information of the blockchain to which it belongs are sent to the cross-chain notary, so that the cross-chain notary can send the ID of each proxy node to the third-party PKG,
  • the third-party PKG calculates the public key and private key of each proxy node based on the ID of each proxy node.
  • the public key and private key of each proxy node are used for each proxy node to perform secure communication.
  • FIG. 3 is a schematic diagram of determining a public key and a private key of an agent node according to an embodiment of the present invention. The following describes the implementation process of determining the public key and the private key of the proxy node in the embodiment of the present invention with reference to FIG. 3 .
  • Step a PKG generates system parameters (partially public) and master key (secret) according to the IBE initialization algorithm.
  • Step b. PKG receives the identity information (such as ID) sent by the cross-chain notary, and calculates the cross-chain notary’s private key according to the cross-chain notary’s identity information, system parameters and master key, and then transfers the cross-chain notary’s private key through the secure channel.
  • the private key of the chain notary is sent to the cross-chain notary.
  • the cross-chain notary receives the ID sent by each proxy node and the system configuration information of the blockchain to which it belongs, and records the mapping relationship between the ID of each proxy node and the system configuration information of the blockchain to which it belongs, and then converts the ID of each proxy node to the system configuration information of the blockchain to which it belongs.
  • the ID is sent to the PKG, so that the PKG can calculate the public key and private key of each proxy node according to the ID, system parameters and master key of each proxy node.
  • the system configuration information of the blockchain to which it belongs may include the underlying architecture, data structure, interface protocol, security mechanism and other information of the blockchain system.
  • the private key is sent to each proxy node through a secure channel, and the public key of each proxy node is sent to the cross-chain notary through a secure channel.
  • Step e The cross-chain notary publicizes the public keys of each proxy node, so that each blockchain can conduct cross-chain secure communication through the proxy node and the cross-chain notary.
  • Step 3 Any node in the blockchain initiates a cross-chain request, and the proxy node confirms the cross-chain request initiated by the node in this chain through a consensus algorithm.
  • any node in each blockchain can initiate a cross-chain request for the target proxy node.
  • the cross-chain request initiated by the local chain node needs to be confirmed through the consensus algorithm. The consensus process for cross-chain requests is described below.
  • the embodiment of the present invention takes the PBFT consensus algorithm as an example to describe the consensus process of the cross-chain request.
  • the PBFT consensus algorithm mainly has 2 threads, namely the PBFT sealer thread and the PBFT consensus thread.
  • the PBFT sealer thread takes the transaction (such as a cross-chain request) from the txPool, packs the transaction into a block, packs the sealed block into the PBFT Prepare package, and sends the package to the PBFT consensus thread.
  • the PBFT consensus thread receives the PBFT consensus message packet from the PBFT sealer or P2P network, and the block executor Blockverifier module responds to execute the block. After the consensus process is completed, the transactions that have been on the chain will be deleted from the txPool.
  • the PBFT consensus process includes three stages, namely pre-preparation, preparation and submission.
  • the pre-preparation stage is: the node executes the program block, generates the signature package and broadcasts the signature package to other nodes;
  • the preparation stage is: the node collects the signature package, and when (2 ⁇ f+1) signature packages are collected, it will declare The commit block is ready and starts to broadcast Commit packets and enters the commit phase;
  • the commit phase is: the node collects Commit packets, and when (2 ⁇ f+1) Commit packets are collected, it will submit the latest locally cached block to the database .
  • the proxy node will confirm the cross-chain request through the PBFT consensus algorithm, and after the consensus is successful, the proxy node will complete the subsequent work for the cross-chain request.
  • Step4 After the cross-chain notary receives the cross-chain request sent by the proxy node, it verifies the cross-chain request, and after successful verification, triggers the cross-chain communication between the proxy node and the target proxy node.
  • the proxy node After the proxy node confirms the cross-chain request initiated by the local chain node through the consensus algorithm, it sends the cross-chain request to the cross-chain notary for verification, so as to realize the cross-chain communication between the proxy node and the target proxy node.
  • the following describes the implementation process of the cross-chain communication between the proxy node and the target proxy node.
  • Step a The proxy node uses the SHA256 algorithm to process the cross-chain request, obtains the digest of the cross-chain request, signs the digest with its own private key, and then encrypts the signature and the cross-chain request with the public key of the cross-chain notary. , and send the encrypted signature and cross-chain request to the cross-chain notary.
  • the cross-chain request may include the ID of the proxy node, the ID of the target proxy node, etc.; the cross-chain request means that a node on one blockchain (such as blockchain 1) wants to communicate with another blockchain (such as A request initiated by a node on blockchain 2) for cross-chain interaction needs to be completed through cross-chain communication between the proxy node on blockchain 1 and the proxy node on blockchain 2.
  • Step b After the cross-chain notary receives the encrypted signature and cross-chain request sent by the proxy node, it decrypts the encrypted signature and cross-chain request with its own private key to obtain the signature and cross-chain request, and performs the signature. verify.
  • Step c After the cross-chain notary determines that the signature verification has passed, based on the ID of the proxy node and the ID of the target proxy node, the proxy is queried from the stored mapping relationship between the ID of each proxy node and the system configuration information of the blockchain to which it belongs.
  • the first case is that the system configuration information is consistent.
  • the proxy node and the target proxy node can communicate directly across the chain.
  • the specific process of the cross-chain communication is as follows:
  • Step 1 The proxy node receives the message that the cross-chain notary sends the signature verification and the system configuration information is consistent.
  • Step 2 The identity authentication module is used to complete the identity authentication between the proxy node and the target proxy node. That is, before the proxy node and the target proxy node perform cross-chain communication, the identities of the proxy node and the target proxy node also need to be mutually authenticated. The following describes the implementation process of identity authentication between the proxy node and the target proxy node.
  • Proxy nodes of different blockchains need to be authenticated before communicating. After the verification is passed, cross-chain communication can be carried out.
  • the IBE identity authentication algorithm needs to be executed, and the communication can only be performed after the two parties have passed the identity authentication.
  • the proxy node 1 may be the proxy node, and the proxy node 2 may be the target proxy node; or, the proxy node 1 may be the target proxy node, and the proxy node 2 may be the proxy node, which is not limited in the implementation of the present invention.
  • the proxy node 1 sends its own identity information (such as ID) to the proxy node 2. That is, based on the ID of the proxy node 1, the message msg 1-1 : ⁇ ID 1 ⁇ is constructed.
  • T 0 , and use the one-way hash function to calculate the digest ⁇ H 3 (X), and use its own private key to perform a bilinear-based digest on the digest.
  • the mapped signature is then sent to proxy node 1 along with the digest ⁇ , signature and X. That is, msg 2 : ⁇ X, ⁇ , e( ⁇ Q 1 , d 2 ) ⁇ . Among them, Q 1 is the public key of the proxy node 1, and d 2 is the private key of the proxy node 2.
  • the proxy node 1 generates a timestamp T 1 when it receives the message msg 2 sent by the proxy node 2 . In order to ensure that the message received this time is not malicious, the timestamp needs to be verified.
  • the proxy node 1 checks whether the time interval between T 1 and T 0 is less than or equal to ⁇ T. If not, it is determined that the message comes from a malicious attacker, and the proxy node 1 will reject the message and interrupt the authentication. If so, further verify the integrity of the message to avoid tampering with the message.
  • the implementation process of the proxy node 1 verifying the integrity of the message will be described below.
  • Step C After checking the integrity of the message, calculate e(sQ 1 , ⁇ 1 Q 2 ) based on the bilinear mapping, compare it with e( ⁇ Q 1 , d 2 ), and verify the signature of the proxy node 2 . If they are equal, the signature verification of the proxy node 2 passes, indicating that the message really comes from the proxy node 2, so it can be verified once again that the message X has not been tampered with.
  • T 1 , and use the digest ⁇ 2 H 3 (X 1 ) calculated by the one-way hash function, and use your own private key to sign the digest based on bilinear mapping, and then convert the digest ⁇ 2 , the signature and X 1 is sent to the proxy node 2 together. That is, msg 1-2 : ⁇ X 1 , ⁇ 2 , e( ⁇ 2 Q 2 , d 1 ) ⁇ . Among them, Q 2 is the public key of the proxy node 2, and d 1 is the private key of the proxy node 1.
  • the proxy node 2 generates a timestamp T 2 when it receives the message msg 1-2 sent by the proxy node 1 . And check whether the time interval between T 2 and T 1 is less than or equal to ⁇ T. If not, it is determined that the message comes from a malicious attacker, and the proxy node 2 will reject the message and interrupt the authentication process. If so, further verify the integrity of the message to avoid tampering with the message.
  • the implementation process of the proxy node 2 verifying the integrity of the message will be described below.
  • Step C After checking the integrity of the message, calculate e(sQ 2 , ⁇ 3 Q 1 ) based on the bilinear mapping, compare it with e( ⁇ 2 Q 2 , d 1 ), and verify the signature of the proxy node 1 . If they are equal, the signature verification of the proxy node 1 passes, indicating that the message really comes from the proxy node 1, so it can be verified once again that the message X 1 has not been tampered with.
  • the user's public-private key pair in the IBE algorithm is a pair of points on the elliptic curve.
  • the public key is mapped from the user identity information to a point on the elliptic curve through the hash function H1, and the private key is obtained by the point product of the point mapped by the public key and the master key s of the PKG. Therefore, the public key Q i and the PKG master key s can be obtained.
  • the private key d i There is a relationship between the private key d i :
  • Q 1 is the public key of the proxy node 1
  • Q j is the public key of the proxy node 2 or the notary node.
  • the messages in the identity authentication module are not sent in plain text, but the hash value is first calculated by the hash function, and then the hash value is signed with the sender's private key, and the signed ciphertext is sent to the receiver. . All tampered messages will get a completely different hash value through the hash function. Moreover, after comparing with the original hash value, it can be verified whether the message has been altered. If the message is tampered with during transmission, the receiver can easily detect it.
  • data integrity means that the data has not been tampered with in the process from sending to receiving, so that the correctness of the data can be guaranteed.
  • the commonly used way to ensure data integrity is to use a hash function to process the message and then sign the processed message.
  • the identity authentication module will sign the message at each step, so that the sender of the message cannot deny the identity of the source of the message, which provides non-repudiation of the message.
  • Step 3 The proxy node encrypts the cross-chain request message m to be sent based on the encryption algorithm of the IBE algorithm, generates the cross-chain ciphertext corresponding to the cross-chain request message m, and sends the cross-chain ciphertext to the target proxy node (such as the target
  • Step 4 After the target proxy node receives the ciphertext, the decryption algorithm based on the IBE algorithm decrypts the ciphertext, and calculates The cross-chain request message m can be obtained, and the cross-chain request is extracted from the cross-chain request message m, and then the cross-chain request is further processed.
  • the proxy node has cross-chain communication with the target proxy node.
  • d 2 is the private key of the target proxy node.
  • the second case is that the system configuration information is inconsistent. If the system configuration information is inconsistent, the cross-chain notary will adjust the data format of the cross-chain request based on the differences in the underlying architecture, data structure, interface protocol, security mechanism, etc. of the blockchain system in the heterogeneous system. And after adjustment, the cross-chain communication between the proxy node and the target proxy node is realized based on the cross-chain notary.
  • the specific process of the cross-chain communication is as follows:
  • Step 1 The cross-chain notary sends a message to the proxy node that the signature verification has passed and the system configuration information is inconsistent.
  • Step 2 The cross-chain notary adjusts the data format of the cross-chain request according to the system configuration information of the blockchain to which the target proxy node belongs, and uses the private key of the cross-chain notary to sign the adjusted cross-chain request, and then signs the adjusted cross-chain request.
  • the signed and adjusted cross-chain request is concatenated into a new message m' waiting to be sent.
  • Step 4 After the target proxy node receives the ciphertext, the decryption algorithm based on the IBE algorithm decrypts the ciphertext, and calculates The cross-chain request message m' can be obtained, and the cross-chain notary's public key is used to verify the cross-chain notary's signature. After the verification is passed, the cross-chain request is extracted from m', and then the cross-chain request is further processed. In view of this, the proxy node has cross-chain communication with the target proxy node. Among them, d 2 is the private key of the target proxy node.
  • the embodiment of the present invention can also use another method to realize the cross-chain communication between the proxy node and the target proxy node. Another implementation manner of cross-chain communication between the proxy node and the target proxy node is described below.
  • Q mid is the public key of the cross-chain notary
  • d 1 is the private key of the proxy node.
  • Step c After the cross-chain notary receives the ciphertext, the decryption algorithm based on the IBE algorithm decrypts the ciphertext, and calculates The cross-chain request message n can be obtained, and the cross-chain request y' is extracted from the cross-chain request message n. Among them, d mid is the private key of the cross-chain notary.
  • Step f The cross-chain notary extracts the cross-chain related information from the cross-chain request y, and queries two of the cross-chain requests from the stored mapping relationship between the ID of each proxy node and the system configuration information of the blockchain to which it belongs. Whether the system configuration information of the blockchain to which the agent node belongs matches.
  • the cross-chain notary will adjust the data format of the cross-chain request based on the differences in the underlying architecture, data structure, interface protocol, security mechanism, etc. of the blockchain system in the heterogeneous system. And generate a new cross-chain request y new .
  • Q 2 is the public key of the target agent node
  • d mid is the private key of the cross-chain notary.
  • Step i After the target agent node receives the ciphertext c', the decryption algorithm based on the IBE algorithm decrypts the ciphertext c', and calculates In other words, the cross-chain request message n' can be obtained, and the cross-chain request y new ' can be extracted from the cross-chain request message n'.
  • d 2 is the private key of the target proxy node.
  • Step 1 The target proxy node extracts the cross-chain related information from the cross-chain request y new , and then further processes the cross-chain related information.
  • FIG. 4 exemplarily shows a cross-chain blockchain communication device provided by an embodiment of the present invention, and the device can execute the flow of the cross-chain blockchain communication method.
  • the device is suitable for a blockchain system with proxy nodes; the proxy nodes are used to forward and receive cross-chain messages of nodes in the blockchain system.
  • the device includes:
  • the receiving unit 401 is configured to receive a first cross-chain ciphertext sent by a first proxy node; the first cross-chain ciphertext is generated by the first proxy node after consensus on the first cross-chain request initiated by the local chain node ;
  • the first processing unit 402 is configured to decrypt the first cross-chain ciphertext to obtain a second cross-chain request and verify the second cross-chain request; after passing the verification of the second cross-chain request, trigger the second proxy node
  • the blockchain system where it is located processes the second cross-chain request.
  • the first cross-chain ciphertext is the IBE ciphertext generated by the first proxy node based on the IBE algorithm; the IBE ciphertext is that the first proxy node encrypts the first concatenated message by using the IBE algorithm. obtained; the first splicing message includes the first cross-chain request, the first digest of the first cross-chain request, and the first signature of the first digest;
  • the first processing unit 402 is also used for:
  • the second splicing message includes the second cross-chain request, the first digest, and the first signature;
  • the first signature of the first digest is a signature generated based on bilinear mapping by using the private key of the first proxy node;
  • the first processing unit 402 is specifically configured to:
  • the public key and private key of the first agent node have the following relationship:
  • the first signature satisfies the following form:
  • e( ⁇ Q j , d 1 ) is the first signature
  • Q 1 is the public key of the first proxy node
  • is the first digest
  • ⁇ 1 is the second digest
  • Q j is the The public key of the second proxy node or the notary node
  • d 1 is the private key of the first proxy node
  • s is the master key of the third-party PKG.
  • the cross-chain verification node is a notary node
  • the first processing unit 402 is specifically configured to:
  • the first processing unit 402 is specifically configured to:
  • the second cross-chain request is adjusted to a third cross-chain request according to the configuration of the blockchain system where the second proxy node is located, and according to the third cross-chain request
  • the second cross-chain ciphertext is generated.
  • the cross-chain verification node is a second proxy node
  • the first processing unit 402 is also used for:
  • the identity confirmation is initiated by the first proxy node after receiving the configuration consistency indication sent by the notary node; the configuration consistency indication is that the notary node is in the Sent when it is determined that the blockchain system where the first proxy node is located has the same configuration as the blockchain system where the second proxy node is located.
  • the first processing unit 402 is specifically configured to:
  • first authentication information based on the first random number and send it to the first proxy node; the first authentication information is used by the first proxy node to perform identity authentication on the second proxy node;
  • the second authentication message is generated by the first proxy node based on a second random number.
  • the cross-chain verification node is a notary node
  • the first cross-chain ciphertext is a signed ciphertext generated by the first proxy node through a signature mechanism; the signed ciphertext includes a signature for the first cross-chain request and the first cross-chain request;
  • the first processing unit 402 is specifically configured to:
  • FIG. 5 exemplarily shows a cross-chain blockchain communication device provided by an embodiment of the present invention, and the device can execute the flow of the cross-chain blockchain communication method.
  • the device is suitable for a blockchain system with proxy nodes; the proxy nodes are used to forward and receive cross-chain messages of nodes in the blockchain system.
  • the device includes:
  • the generating unit 501 is configured to generate a first cross-chain ciphertext based on the first cross-chain request after a consensus is reached on the first cross-chain request initiated by the local chain node;
  • the second processing unit 502 is configured to send the first cross-chain ciphertext to a cross-chain verification node; the cross-chain verification node is configured to decrypt the first cross-chain ciphertext to obtain a second cross-chain request and verify the After passing the second cross-chain request, the blockchain system where the second proxy node is located is triggered to process the second cross-chain request.
  • the second processing unit 502 is specifically configured to:
  • the method further includes:
  • the configuration consistency indication is that the cross-chain verification node has passed the verification of the signed ciphertext and the blockchain system where the first proxy node is located is the same as the second Sent when the blockchain system where the proxy node is located has the same configuration;
  • the IBE ciphertext is obtained by encrypting the first concatenated message through the IBE algorithm;
  • the first concatenated message includes the first cross-chain request, the first digest of the first cross-chain request, and the first digest of the first digest sign;
  • the second processing unit 502 is specifically configured to:
  • the IBE ciphertext is obtained by encrypting the first splicing message through the IBE algorithm; the first splicing message includes the first cross-chain request, the first cross-chain request and the A first digest of the request and a first signature of the first digest.
  • the second processing unit 502 is specifically configured to:
  • each node in the blockchain system based on a preset election rule, determine the local density of each node;
  • the node corresponding to the maximum local density and the maximum distance is determined as the first proxy node.
  • an embodiment of the present invention provides a computing device, including:
  • the processor is used to call the computer program stored in the memory, and execute the cross-chain blockchain communication method according to the obtained program.
  • an embodiment of the present invention provides a computer-readable storage medium, where the computer-readable storage medium stores a computer-executable program, and the computer-executable program is used to enable a computer to execute a cross-chain blockchain communication method.
  • embodiments of the present invention may be provided as a method, system, or computer program product. Accordingly, the present invention may take the form of an entirely hardware embodiment, an entirely software embodiment, or an embodiment combining software and hardware aspects. Furthermore, the present invention may take the form of a computer program product embodied on one or more computer-usable storage media (including, but not limited to, disk storage, CD-ROM, optical storage, etc.) having computer-usable program code embodied therein.
  • computer-usable storage media including, but not limited to, disk storage, CD-ROM, optical storage, etc.

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Computer Hardware Design (AREA)
  • Computing Systems (AREA)
  • General Engineering & Computer Science (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)
  • Financial Or Insurance-Related Operations Such As Payment And Settlement (AREA)

Abstract

本发明实施例提供了一种跨链的区块链通信方法及装置,该方法包括跨链验证节点接收第一代理节点发送的第一跨链密文,解密第一跨链密文得到第二跨链请求并验证第二跨链请求,在验证通过第二跨链请求后,触发第二代理节点所在的区块链系统处理第二跨链请求。由于代理节点用于对区块链系统内的节点的跨链消息进行转收发,且第一跨链密文是第一代理节点对本链节点发起的第一跨链请求进行共识后生成的,并在验证通过第二跨链请求后触发第二代理节点所在的区块链系统处理第二跨链请求,如此可以确保跨链通信的安全性。此外,该技术方案无需管理和维护大量用户证书的生成、颁发、撤销等,因此可以节约计算资源和存储资源。

Description

一种跨链的区块链通信方法及装置
相关申请的交叉引用
本申请要求在2020年11月18日提交中国专利局、申请号为202011294886.7、申请名称为“一种跨链的区块链通信方法及装置”的中国专利申请的优先权,其全部内容通过引用结合在本申请中。
技术领域
本发明实施例涉及金融科技(Fintech)领域,尤其涉及一种跨链的区块链通信方法及装置。
背景技术
随着计算机技术的发展,越来越多的技术应用在金融领域,传统金融业正在逐步向金融科技转变,但由于金融行业的安全性、实时性要求,也对技术提出的更高的要求。
现阶段,采用面向CA(Certificate Authority,证书颁发机构)的准入机制用于物联网环境中各区块链平台(即多个物联网设备分布在不同的区块链平台)之间的跨链通信。具体地,各区块链平台中的物联网设备用户在进行跨链通信前都会向所属管理节点发送证书请求文件,并在所属管理节点使用自己的私钥对证书请求文件进行签发后获取身份证书,以便在进行跨链通信时利用身份证书进行身份认证。然而,这种处理方式由于面向CA的准入机制需要管理和维护大量用户证书的生成、颁发、撤销等,因此需要消耗大量的计算资源和存储资源,导致跨链通信的效率低。
综上,目前亟需一种跨链的区块链通信方法,用以确保跨链通信的安全性,并可以节约计算资源和存储资源。
发明内容
本发明实施例提供了一种跨链的区块链通信方法及装置,用以确保跨链通信的安全性,并可以节约计算资源和存储资源。
第一方面,本发明实施例提供了一种跨链的区块链通信方法,适用于具有代理节点的区块链系统;所述代理节点用于对所述区块链系统内的节点的跨链消息进行转收发;所述方法包括:
跨链验证节点接收第一代理节点发送的第一跨链密文;所述第一跨链密文是所述第一代理节点对本链节点发起的第一跨链请求进行共识后生成的;
所述跨链验证节点解密所述第一跨链密文得到第二跨链请求并验证所述第二跨链请求;
所述跨链验证节点在验证通过所述第二跨链请求后,触发第二代理节点所在的区块链系统处理所述第二跨链请求。
上述技术方案中,通过解密第一跨链密文得到第二跨链请求并验证第二跨链请求,在 验证通过第二跨链请求后即可触发第二代理节点所在的区块链系统处理第二跨链请求。如此,由于该技术方案是通过代理节点用于对区块链系统内的节点的跨链消息进行转收发,且第一跨链密文是第一代理节点对本链节点发起的第一跨链请求进行共识后生成的,并在验证通过第二跨链请求后才触发第二代理节点所在的区块链系统处理第二跨链请求,因此可以确保跨链通信的安全性。此外,该技术方案无需管理和维护大量用户证书的生成、颁发、撤销等,因此可以节约计算资源和存储资源,从而可以解决现有技术中存在面向CA的准入机制需要管理和维护大量用户证书的生成、颁发、撤销等,导致消耗大量的计算资源和存储资源的问题。
可选地,所述第一跨链密文是所述第一代理节点基于IBE算法生成的IBE密文;所述IBE密文为所述第一代理节点通过IBE算法对第一拼接消息进行加密得到的;所述第一拼接消息包括所述第一跨链请求、所述第一跨链请求的第一摘要和所述第一摘要的第一签名;
所述跨链验证节点解密所述第一跨链密文得到第二跨链请求并验证所述第二跨链请求,包括:
所述跨链验证节点通过IBE算法解密所述第一跨链密文,得到第二拼接消息;所述第二拼接消息包括所述第二跨链请求、所述第一摘要和所述第一签名;
所述跨链验证节点生成所述第二跨链请求的第二摘要;
所述跨链验证节点确定所述第二摘要与所述第一摘要是否一致;
所述跨链验证节点根据所述第二摘要生成第二签名;
所述跨链验证节点确定所述第二签名与所述第一签名是否一致。
上述技术方案中,通过确定第二摘要与第一摘要是否一致,以及确定第二签名与第一签名是否一致,如此可以验证代理节点发送的消息是否真实,以此确保代理节点所发送的消息的真实性,并可以避免消息在发送过程中存在篡改的风险,从而可以验证代理节点的身份信息的真实性。
可选地,所述第一摘要的第一签名是利用所述第一代理节点的私钥进行的基于双线性映射生成的签名;通过下述方式生成所述第一签名:
所述第一代理节点的公钥、私钥存在如下关系:
d 1=sQ 1
根据双线性映射配对的性质,得到e(sQ j1Q 1)=e(μ 1Q j,sQ 1),并基于所述第一代理节点的私钥,生成所述第一签名;所述第一签名满足如下形式:
e(sQ j1Q 1)=e(μ 1Q j,sQ 1)=e(μQ j,d 1)
其中,e(μQ j,d 1)为所述第一签名,Q 1为所述第一代理节点的公钥,μ为所述第一摘要,μ 1为所述第二摘要,Q j为第二代理节点或公证人节点的公钥,d 1为所述第一代理节点的私钥,s为第三方PKG的主密钥。
上述技术方案中,通过基于双线性映射配对的性质,生成摘要的签名,如此可以确保生成的签名的不可篡改性、可验证性,并可以为后续验证代理节点的身份信息的真实性提供支持。
可选地,所述跨链验证节点为公证人节点;
所述跨链验证节点在验证通过所述第二跨链请求后,触发第二代理节点所在的区块链系统处理所述第二跨链请求,包括:
所述公证人节点在验证通过所述第二跨链请求后,根据所述第二跨链请求生成第二跨 链密文;
所述公证人节点将所述第二跨链密文发送至所述第二代理节点,以使通过所述第二代理节点所在的区块链系统处理所述第二跨链密文。
上述技术方案中,若跨链验证节点为公证人节点,则公证人节点在验证通过第二跨链请求后,即可根据第二跨链请求生成第二跨链密文,并将第二跨链密文发送至第二代理节点,如此可以基于公证人节点验证第一代理节点的身份,并通过公证人节点可以实现第一代理节点与第二代理节点的安全通信,从而可以确保跨链交互过程中数据的安全性。
可选地,所述根据所述第二跨链请求生成第二跨链密文,包括:
所述公证人节点确定所述第一代理节点所在的区块链系统与所述第二代理节点所在的区块链系统是否具有相同的配置;
所述公证人节点若确定具有相同的配置,则根据所述第二跨链请求生成所述第二跨链密文;
所述公证人节点若确定不具有相同的配置,则根据所述第二代理节点所在的区块链系统的配置,将所述第二跨链请求调整为第三跨链请求,并根据所述第三跨链请求生成所述第二跨链密文。
上述技术方案中,通过在确定第一代理节点所在的区块链系统与第二代理节点所在的区块链系统不具有相同的配置时,根据第二代理节点所在的区块链系统的配置调整第二跨链请求,如此可以确保调整后的第二跨链请求的数据格式与第二代理节点所在的区块链系统的配置相匹配,以此即可有助于实现第一代理节点与第二代理节点的安全通信。
可选地,所述跨链验证节点为第二代理节点;
在所述跨链验证节点接收第一代理节点发送的第一跨链密文之前,还包括:
所述第二代理节点与所述第一代理节点相互进行身份确认;所述身份确认是所述第一代理节点在接收到公证人节点发送的配置一致指示后发起的;所述配置一致指示是所述公证人节点在确定所述第一代理节点所在的区块链系统与所述第二代理节点所在的区块链系统具有相同的配置时发送的。
上述技术方案中,若跨链验证节点为第二代理节点,则第一代理节点在接收到配置一致指示后,与第二代理节点相互进行身份确认,如此可以准确地验证出第一代理节点、第二代理节点的身份信息的真实性,以便确保后续跨链通信的安全性,并为后续代理节点间发生消息真实性的争议时提供消息不可否认性的支持。
可选地,所述第二代理节点与所述第一代理节点相互进行身份确认,包括:
所述第二代理节点接收所述第一代理节点发送的第一标识;
所述第二代理节点基于第一随机数生成第一认证信息并发送给所述第一代理节点;所述第一认证信息用于所述第一代理节点对所述第二代理节点进行身份认证;
所述第二代理节点接收所述第一代理节点发送的第二认证信息并对所述第二认证信息进行验证;所述第二认证消息是所述第一代理节点基于第二随机数生成的。
上述技术方案中,第二代理节点基于第一随机数生成第一认证信息并发送给第一代理节点,以及第一代理节点基于第二随机数生成第二认证信息并发送给第二代理节点。如此,该技术方案通过验证第一认证信息、第二认证信息,可以准确地验证出第一代理节点、第二代理节点的身份信息的真实性。
可选地,所述跨链验证节点为公证人节点;
所述第一跨链密文是所述第一代理节点通过签名机制生成的签名密文;所述签名密文包括对所述第一跨链请求的签名和所述第一跨链请求;
所述跨链验证节点在验证通过所述第二跨链请求后,触发第二代理节点所在的区块链系统处理所述第二跨链请求,包括:
所述公证人节点在确定所述第一代理节点所在的区块链系统与所述第二代理节点所在的区块链系统不具有相同的配置时,根据所述第二代理节点所在的区块链系统的配置,将所述第二跨链请求调整为第三跨链请求,并根据所述第三跨链请求生成所述第二跨链密文;
所述公证人节点将所述第二跨链密文发送给所述第二代理节点。
上述技术方案中,若跨链验证节点为公证人节点,则公证人节点在确定第一代理节点所在的区块链系统与第二代理节点所在的区块链系统不具有相同的配置时,根据第二代理节点所在的区块链系统的配置调整第二跨链请求,如此可以确保调整后的第二跨链请求的数据格式与第二代理节点所在的区块链系统的配置相匹配,以此即可有助于实现第一代理节点与第二代理节点的安全通信。
第二方面,本发明实施例提供了一种跨链的区块链通信方法,适用于具有代理节点的区块链系统;所述代理节点用于对所述区块链系统内的节点的跨链消息进行转收发;所述方法包括:
第一代理节点对本链节点发起的第一跨链请求进行共识后,基于所述第一跨链请求生成第一跨链密文;
所述第一代理节点将所述第一跨链密文发送给跨链验证节点;所述跨链验证节点用于解密所述第一跨链密文得到第二跨链请求并在验证通过所述第二跨链请求后,触发第二代理节点所在的区块链系统处理所述第二跨链请求。
上述技术方案中,第一代理节点通过对本链节点发起的第一跨链请求进行共识后,即可基于第一跨链请求生成第一跨链密文,并将第一跨链密文发送给跨链验证节点,以便跨链验证节点解密第一跨链密文得到第二跨链请求并在验证通过第二跨链请求后,触发第二代理节点所在的区块链系统处理第二跨链请求。如此,由于该技术方案是通过代理节点用于对区块链系统内的节点的跨链消息进行转收发,且第一跨链密文是第一代理节点对本链节点发起的第一跨链请求进行共识后生成的,并在跨链验证节点验证通过第二跨链请求后触发第二代理节点所在的区块链系统处理第二跨链请求,因此可以确保跨链通信的安全性。此外,该技术方案无需管理和维护大量用户证书的生成、颁发、撤销等,因此可以节约计算资源和存储资源。
可选地,所述第一代理节点对本链节点发起的第一跨链请求进行共识后,基于所述第一跨链请求生成第一跨链密文,包括:
第一代理节点对本链节点发起的第一跨链请求进行共识后,基于所述第一跨链请求生成签名密文;
所述第一代理节点将所述第一跨链密文发送给跨链验证节点之后,还包括:
所述第一代理节点接收所述跨链验证节点发送的配置一致指示;所述配置一致指示是所述跨链验证节点在对所述签名密文验证通过且所述第一代理节点所在的区块链系统与第二代理节点所在的区块链系统具有相同的配置时发送的;
所述第一代理节点通过IBE算法对第一拼接消息进行加密得到IBE密文;所述第一拼 接消息包括所述第一跨链请求、所述第一跨链请求的第一摘要和所述第一摘要的第一签名;
所述第一代理节点将所述IBE密文发送给所述第二代理节点。
上述技术方案中,在接收到跨链验证节点发送的配置一致指示后,通过IBE算法对第一拼接消息进行加密得到IBE密文,并将IBE密文发送给第二代理节点,如此可以避免代理节点间进行跨链通信时存在作恶的风险,从而可以确保代理节点间跨链通信的安全性。
可选地,所述第一代理节点对本链节点发起的第一跨链请求进行共识后,基于所述第一跨链请求生成第一跨链密文,包括:
第一代理节点对本链节点发起的第一跨链请求进行共识后,通过IBE算法对第一拼接消息进行加密得到IBE密文;所述第一拼接消息包括所述第一跨链请求、所述第一跨链请求的第一摘要和所述第一摘要的第一签名。
上述技术方案中,通过基于IBE算法对第一拼接消息进行加密得到IBE密文,如此可以避免生成的跨链密文存在泄漏的风险,从而可以确保生成的跨链密文的安全性。
可选地,根据下述方式确定所述第一代理节点:
针对所述区块链系统内的各节点,基于预设的选举规则,确定出所述各节点的局部密度;
针对每个节点,确定所述节点的局部密度是否为最大;若所述节点的局部密度为最大,则确定出所述节点与其它节点间的最大距离;若所述节点的局部密度不为最大,则确定出所述节点与其它节点间的最小距离;
通过对所述各节点的局部密度、最大距离、最小距离进行处理,将局部密度最大且距离最大对应的节点确定为所述第一代理节点。
上述技术方案中,通过预设的选举规则,确定出每个节点的局部密度、节点间距离,并对各节点的局部密度、节点间距离进行处理,如此可以准确高效地确定出代理节点,并可以确保代理节点的选取的随机公平性。
第三方面,本发明实施例提供了一种跨链的区块链通信装置,适用于具有代理节点的区块链系统;所述代理节点用于对所述区块链系统内的节点的跨链消息进行转收发;所述装置包括:
接收单元,用于接收第一代理节点发送的第一跨链密文;所述第一跨链密文是所述第一代理节点对本链节点发起的第一跨链请求进行共识后生成的;
第一处理单元,用于解密所述第一跨链密文得到第二跨链请求并验证所述第二跨链请求;在验证通过所述第二跨链请求后,触发第二代理节点所在的区块链系统处理所述第二跨链请求。
第四方面,本发明实施例提供了一种跨链的区块链通信装置,适用于具有代理节点的区块链系统;所述代理节点用于对所述区块链系统内的节点的跨链消息进行转收发;所述装置包括:
生成单元,用于对本链节点发起的第一跨链请求进行共识后,基于所述第一跨链请求生成第一跨链密文;
第二处理单元,用于将所述第一跨链密文发送给跨链验证节点;所述跨链验证节点用于解密所述第一跨链密文得到第二跨链请求并在验证通过所述第二跨链请求后,触发第二代理节点所在的区块链系统处理所述第二跨链请求。
第五方面,本发明实施例提供一种计算设备,包括:
存储器,用于存储计算机程序;
处理器,用于调用所述存储器中存储的计算机程序,按照获得的程序执行跨链的区块链通信方法。
第六方面,本发明实施例提供一种计算机可读存储介质,所述计算机可读存储介质存储有计算机可执行程序,所述计算机可执行程序用于使计算机执行跨链的区块链通信方法。
附图说明
为了更清楚地说明本发明实施例中的技术方案,下面将对实施例描述中所需要使用的附图作简要介绍,显而易见地,下面描述中的附图仅仅是本发明的一些实施例,对于本领域的普通技术人员来讲,在不付出创造性劳动的前提下,还可以根据这些附图获得其他的附图。
图1为本发明实施例提供的一种跨链通信的系统架构的示意图;
图2为本发明实施例提供的一种跨链的区块链通信方法的流程示意图;
图3为本发明实施例提供的一种确定代理节点公钥、私钥的示意图;
图4为本发明实施例提供的一种跨链的区块链通信装置的结构示意图;
图5为本发明实施例提供的另一种跨链的区块链通信装置的结构示意图。
具体实施方式
为了使本发明的目的、技术方案和优点更加清楚,下面将结合附图对本发明作进一步地详细描述,显然,所描述的实施例仅仅是本发明的一部分实施例,而不是全部的实施例。基于本发明中的实施例,本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其它实施例,都属于本发明保护的范围。
下面首先对本发明实施例中涉及的部分用语进行解释说明,以便于本领域技术人员进行理解。
(1)双线性映射:设G 1是生成元为P的加法循环群,阶为p,G 2是与G 1具有相同阶的乘法循环群,a,b是Z p *(p阶素数循环群)中的元素。假设G 1和G 2的离散对数问题是难解的。则双线性映射定义为满足以下关系的映射e:G 1×G 1→G 2。a、双线性(bilinearity):
对于任意的a,b∈Z p *,e(aP,bQ)=e(P,Q) ab成立,P、Q是G 1的任意点。b、非退化性(non-degeneracy):若P是G 1的生成元,则e(P,P)是G 2的生成元。c、可计算性(computability):对于任意的a,b∈G 1,存在有效的算法计算e(P,Q);通过在椭圆曲线上计算Tate配对或者Weil配对可以得出双线性映射。IBE系统就是建立在有限域上超奇异椭圆曲线上的Weil配对来构造的。Weil配对e:G 1×G 1→G 2满足以下性质:对于任意a∈Z p *和的倍点aP,有e(aP,Q)=e(P,Q) a=e(P,aQ)。
(2)PKG(Private Key Generator,私钥生成器):一个可信的第三方实体,负责生成系统参数,根据用户提供的身份信息生成私钥并通过安全信道发送给用户。PKG是一个可信第三方,内置初始化算法,可以生成系统参数。系统参数包括椭圆曲线上的双线性映射e、椭圆曲线的阶数q、椭圆曲线上的q阶加法循环群G 1、椭圆曲线上的q阶乘法循环群G 2、椭圆曲线的生成元P、系统主密钥s、系统公钥P pub。具体地可以如表1所示。
表1
符号 含义
q 椭圆曲线的阶数,是质数
e 双线性映射,G 1×G 1→G 2
G 1 q阶加法循环群
G 2 q阶乘法循环群
P G 1的生成元
s PKG主密钥,s∈Z p *
P pub PKG公钥,P pub=s×P
然后,PKG需要选择三个哈希函数,分别是H 1:{0,1} *→G 1,H 2:G 2→{0,1} n,H 3:{0,1} n→Z p *。系统参数初始化完成后,PKG公开系统参数(q,G 1,G 2,P,e,P pub,H 1,H 2,H 3),主密钥s由PKG保管。
(3)IBE(Identity-Based Encryption,基于身份的加密):一种公钥加密方案,将可以唯一标识用户身份的任意字符串数据(比如Email地址)当作加密的公钥使用。
其中,IBE算法是由系统初始化、密钥提取、加密、解密这四个算法构成的。
a系统初始化算法:输入一个安全参数1 k,运行系统初始化算法,生成系统参数params和主密钥s。系统参数params向用户公开,主密钥s保存在私钥生成器PKG上;
具体过程为:设G 1是由生成元P生成的p阶加法循环群,G 2是p阶乘法循环群,双线性映射e:G 1×G 1→G 2。选取两个哈希函数H 1:{0,1} *→G 1,H 2:G 2→{0,1} n,其中n表示消息长度。然后,PKG选取随机数s作为主密钥,s∈Z p *。然后计算公钥P pub=s×P。最后,保密私钥,公开params={G 1,G 2,n,p,e,P,P pub,H 1,H 2}。
b密钥提取算法:输入用户身份ID、公共参数params和主密钥s,运行密钥提取算法,生成用户私钥d ID,并且返回相对应的私钥。
具体过程为:通信方将自己的身份信息ID i发送给PKG,然后PKG计算对应公钥Q i=H 1(ID i),私钥d i=s×Q i
c加密算法:输入身份ID、系统参数params和明文m,运行加密算法,生成密文c。
具体过程为:假设发送方要发送消息m给接收者的身份ID B。首先,随机选取r∈Z p *;然后,计算
Figure PCTCN2021126988-appb-000001
最后发送密文c=(V,W)。其中,P为加法循环群G 1的生成元,哈希函数H 2:G 2→{0,1} n,P pub为PKG的公钥P pub=s×P。
d解密算法:输入密文c、用户身份ID、ID对应的私钥d ID和系统参数params。运行解密算法,输出m则为解密成功,否则输出⊥则表示解密失败。
具体过程为:接收者收到密文后计算
Figure PCTCN2021126988-appb-000002
得到明文。
IBE算法满足一致性要求,对公钥为ID的用户运行密钥提取算法生成其用户私钥d ID时,对于在明文空间的任意m来说,等式Decrypt(params,ID,d ID,c)=m成立,其中,密文c=Encrypt(params,ID,m)。
(4)CA(Certificate Authority,证书颁发机构):一个可信的第三方实体,负责颁发数字证书和管理公钥证书,确保用户收到可以有效验证身份的唯一证书。
(5)联盟链:联盟链是指由若干个机构共同参与管理的区块链,属于一类介于公有链和私有链之间的混合式区块链;其中每个机构运行并管理着链上一个或多个节点,其数据只允许联盟内各机构进行读写,各机构间可发送交易,并共同来记录交易数据。
(6)共识算法:共识算法是一种程序,通过该程序区块链网络的所有节点都可以就 分布式账本的当前状态达成共识。这样,共识算法可在区块链网络中实现可靠性,并在分布式计算环境中的未知节点之间建立信任。本质上,共识协议确保添加到区块链中的每个新区块都是区块链中所有节点都同意的唯一版本。
(7)PBFT(Practical Byzantine Fault Tolerance,实用拜占庭容错)共识算法:可容忍不超过三分之一的故障节点和作恶节点,在少数节点作恶(如伪造消息)场景中达成共识。
(8)公证人机制:当跨链双方互不信任且信息不对称时,最简单的方法是寻找双方都信任的中介。公证人机制是通过选举一个或一组可信节点作为公证人,对区块链Y上是否发生了特定事件进行验证,并向区块链X上的节点进行证明。公证人群体通过特定的共识算法对事件是否发生达成共识。公证人模式是目前应用最广泛的一种模式。公证人机制是实现区块链之间互操作性的方案中较易实现的一种,无需进行复杂的工作量证明或权益证明,易于对接现有的区块链系统。
如上介绍了本发明实施例中涉及的部分用语,下面对本发明实施例涉及的技术特征进行介绍。
为了便于理解本发明实施例,首先以图1中示出的系统架构为例说明适用于本发明实施例跨链通信的系统架构。该跨链通信的系统架构可以应用于物联网环境下的物联网各系统平台(即物联网设备分布在不同的物联网平台)的跨链通信,在实际应用场景中,本发明对此并不作限定。如图1所示,该系统架构可以包括至少两个区块链(区块链1、区块链2等)、跨链公证人102。其中,每一个区块链与跨链公证人102进行连接,比如可以通过有线方式连接,或者通过无线方式连接,具体不作限定。
其中,区块链1或区块链2等通过选举算法选举出自己的代理节点,并将选举出的代理节点作为对外通信的节点。对于任一区块链上的跨链请求,则由该区块链的代理节点统一处理,并由该区块链的代理节点通过区块链共识模块对跨链请求进行确认,然后在对跨链请求共识确认后,根据不同的应用需求,并基于跨链请求生成跨链信息或跨链密文。在发送跨链请求之前,代理节点首先将代理节点ID以及所属区块链的系统配置信息一起发送给跨链公证人。
跨链公证人102负责记录代理节点ID和所属区块链的系统配置信息的映射关系,并将代理节点ID发送给PKG。PKG通过IBE算法计算出跨链公证人和代理节点ID对应的私钥,通过安全方式返还给跨链公证人和代理节点。此外,跨链公证人102会对代理节点发送的跨链信息或跨链密文进行验证,并在验证成功后才进行后续通信处理。
需要说明的是,上述图1所示的结构仅是一种示例,本发明实施例对此不做限定。
基于上述描述,图2示例性的示出了本发明实施例提供的一种跨链的区块链通信方法的流程,该流程可以由跨链的区块链通信装置执行。
如图2所示,该流程具体包括:
步骤201,第一代理节点对本链节点发起的第一跨链请求进行共识后,基于所述第一跨链请求生成第一跨链密文。
步骤202,所述第一代理节点发送所述第一跨链密文给跨链验证节点。
步骤203,所述跨链验证节点解密所述第一跨链密文得到第二跨链请求并验证所述第二跨链请求。
步骤204,所述跨链验证节点在验证通过所述第二跨链请求后,触发第二代理节点所在的区块链系统处理所述第二跨链请求。
上述步骤201和步骤202中,在第一代理节点对本链节点发起的第一跨链请求进行共识之前,需要通过预设的选举算法确定出第一代理节点。具体地,针对区块链系统内的各节点,基于预设的选举规则,确定出各节点的局部密度。并针对每个节点,确定该节点的局部密度是否为最大;若该节点的局部密度为最大,则确定出该节点与其它节点间的最大距离;若该节点的局部密度不为最大,则确定出该节点与其它节点间的最小距离。再通过对各节点的局部密度、最大距离、最小距离进行处理,将局部密度最大且距离最大对应的节点确定为第一代理节点,如此可以准确高效地确定出代理节点。然后在确定出第一代理节点后,第一代理节点可以代理处理本链节点发起的跨链请求。例如,第一代理节点对本链节点发起的第一跨链请求进行共识后,基于第一跨链请求生成第一跨链密文。其中,针对第一代理节点所在的区块链系统中任一节点发起的跨链请求,第一代理节点都会对该跨链请求进行共识确认。并在确定该跨链请求共识成功后,根据哈希算法或IBE算法对跨链请求进行处理,生成第一跨链密文。然后,将第一跨链密文发送给跨链验证节点。如此,通过对跨链请求进行共识确认以及哈希算法或IBE算法对跨链请求进行处理,可以确保生成的第一跨链密文的安全性。其中,需要说明的是,该第一跨链密文可以是基于代理节点的私钥生成的签名密文,也可以是基于IBE算法生成的IBE密文。
上述步骤203和步骤204中,跨链验证节点接收第一代理节点发送的第一跨链密文。若第一跨链密文是第一代理节点基于IBE算法生成的IBE密文,则跨链验证节点通过IBE算法解密第一跨链密文,得到第二拼接消息,其中,第二拼接消息包括所述第二跨链请求、第一摘要和第一签名。再基于第二跨链请求生成第二跨链请求的第二摘要,并确定第二摘要与第一摘要是否一致。同时,根据第二摘要生成第二签名,并确定第二签名与第一签名是否一致。如此,通过确定第二摘要与第一摘要是否一致,以及确定第二签名与第一签名是否一致,如此可以验证代理节点发送的消息是否真实,以此确保代理节点所发送的消息的真实性,并可以避免消息在发送过程中存在篡改的风险,从而可以验证代理节点的身份信息的真实性。其中,基于IBE算法生成的IBE密文为第一代理节点通过IBE算法对第一拼接消息进行加密得到的;其中,第一拼接消息包括第一跨链请求、第一跨链请求的第一摘要和第一摘要的第一签名。
其中,第一摘要的第一签名是利用第一代理节点的私钥进行的基于双线性映射生成的签名;通过下述方式生成所述第一签名:
第一代理节点的公钥、私钥存在如下关系:
d 1=sQ 1
根据双线性映射配对的性质,得到e(sQ j1Q 1)=e(μ 1Q j,sQ 1),并基于第一代理节点的私钥,生成第一签名;第一签名满足如下形式:
e(sQ j1Q 1)=e(μ 1Q j,sQ 1)=e(μQ j,d 1)
其中,e(μQ j,d 1)为第一签名,Q 1为第一代理节点的公钥,μ为第一摘要,μ 1为第二摘要,Q j为第二代理节点或公证人节点的公钥,d 1为第一代理节点的私钥,s为第三方PKG的主密钥。
在第一跨链密文是第一代理节点基于IBE算法生成的IBE密文时,若跨链验证节点为公证人节点,则公证人节点在验证第二跨链请求成功后,根据第二跨链请求生成第二跨链密文。即,公证人节点确定第一代理节点所在的区块链系统与第二代理节点所在的区块链系统是否具有相同的配置。若确定具有相同的配置,则根据第二跨链请求生成第二跨链密 文;若确定不具有相同的配置,则根据第二代理节点所在的区块链系统的配置,将第二跨链请求调整为第三跨链请求,并根据第三跨链请求生成第二跨链密文,如此可以确保调整后的第二跨链请求的数据格式与第二代理节点所在的区块链系统的配置相匹配,以便实现第一代理节点与第二代理节点的安全通信。然后将第二跨链密文发送至第二代理节点,以使通过第二代理节点所在的区块链系统处理第二跨链密文。
在第一跨链密文是第一代理节点基于IBE算法生成的IBE密文时,若跨链验证节点为第二代理节点,则在接收第一代理节点发送的第一跨链密文之前,第二代理节点与第一代理节点相互进行身份确认。即,第二代理节点接收第一代理节点发送的第一标识,并基于第一随机数生成第一认证信息,之后将第一认证信息发送给第一代理节点,第一认证信息用于第一代理节点对第二代理节点进行身份认证。同时,接收第一代理节点发送的第二认证信息并对第二认证信息进行验证,第二认证消息是第一代理节点基于第二随机数生成的。如此,通过验证第一认证信息、第二认证信息,就可以准确地验证出第一代理节点、第二代理节点的身份信息的真实性。然后,在确定身份认证成功后,第一代理节点可以基于IBE算法和第二跨链请求生成第二跨链密文,并将第二跨链密文发送给第二代理节点以通过第二代理节点所在的区块链系统处理第二跨链密文。其中,身份确认是第一代理节点在接收到公证人节点发送的配置一致指示后发起的;配置一致指示是公证人节点在确定第一代理节点所在的区块链系统与第二代理节点所在的区块链系统具有相同的配置时发送的;第一标识用于公证人节点记录第一代理节点的第一标识与第一代理节点所在的区块链系统的配置的映射关系;第一标识还可用于第三方PKG基于第一标识生成第一代理节点的公钥、私钥。
若第一跨链密文是基于代理节点的私钥生成的签名密文,跨链验证节点为公证人节点。公证人节点使用自己的私钥对签名密文进行解密,得到跨链请求以及跨链请求的摘要的签名。再使用第一代理节点的公钥对该签名进行验签,以确定该签名密文是否来自于第一代理节点,如此可以验证第一代理节点发送的签名密文的真实性。公证人节点在验证签名成功后,确定第一代理节点所在的区块链系统与第二代理节点所在的区块链系统是否具有相同的配置,若确定第一代理节点所在的区块链系统与第二代理节点所在的区块链系统具有相同的配置,则将签名密文验证通过且第一代理节点所在的区块链系统与第二代理节点所在的区块链系统具有相同的配置的消息发送给第一代理节点。第一代理节点与第二代理节点之间进行相互身份认证,并在在确定身份认证成功后,第一代理节点基于IBE算法和第二跨链请求生成第二跨链密文,并将第二跨链密文发送给第二代理节点以通过第二代理节点所在的区块链系统处理第二跨链密文。若确定第一代理节点所在的区块链系统与第二代理节点所在的区块链系统不具有相同的配置,则根据第二代理节点所在的区块链系统的配置将第二跨链请求调整为第三跨链请求,并基于IBE算法和第三跨链请求生成第二跨链密文,如此可以确保调整后的第二跨链请求的数据格式与第二代理节点所在的区块链系统的配置相匹配,以便实现第一代理节点与第二代理节点的安全通信。然后将第二跨链密文发送至第二代理节点,以使通过第二代理节点所在的区块链系统处理第二跨链密文。
由于面向CA的准入机制需要管理和维护大量用户证书的生成、颁发、撤销等行为,这将消耗大量计算资源和存储资源,因此不适合应用于用户数量庞大、设备资源受限的物联网环境中。而基于IBE算法的跨链通信方案可以将能够唯一标识用户身份信息的某个字符串直接当作公钥使用,如此可以省去面向CA的准入机制中公钥基础设施认证和管理用 户证书的过程,并有助于节约大量计算资源和存储资源。因此,本发明实施例采用基于IBE算法的跨链通信方案,能很好地适用于用户数量庞大,设备资源受限的物联网环境。
鉴于此,下面对本发明实施例中跨链通信的实施过程进行具体描述。
Step1:区块链选举代理节点。
在不同的应用场景下,区块链代理节点的选举会依据具体应用而采取不同的策略,有很多需要考虑的因素。不同的区块链网络,会根据服务容量、交易效率的不同需求,接纳具有高算力并能高速接入区块链网络的计算节点。本发明实施例对于区块链代理节点的选取,可以通过采用选举算法来实现,比如本发明实施例采用的选举算法是基于密度峰值的聚类算法,在实际应用场景中,也可以采用其它选举算法,本发明实施例对此并不作限定。即,对具有高算力的节点中计算相应的参数进行对比选择,最后得到各区块链的代理节点。该聚类算法基于以下假设:聚类中心被具有较低局部密度的邻居节点包围,并且它们与具有较高局部密度的任何节点之间的距离都比较大,将聚类中心定义为数据点密度的局部最大值。基于此,可以根据不同区块链中节点的密集程度来选择代理节点。
示例性地,给定样本应用节点D={x 1,x 2,…,x m},共识服务节点集合为C={C 1,C 2,…,C k},k为共识服务节点数,跨链交换的网络传输代价为:
Figure PCTCN2021126988-appb-000003
其中,
Figure PCTCN2021126988-appb-000004
是簇C i的均值向量。
基于上述公式可知,E值越小则网络传输代价越小。如此,在应用节点固定的情况下,可以通过对共识服务节点和跨链交换节点的合理设置使网络传输代价最小达到最优,同时区块链网络中交易和共识的效率也将达到最高。
对于每个满足性能要求的区块链节点i,计算出两个参数,即,局部密度ρ i和该节点与具有更高密度的节点的距离δ i。这两个参数仅取决于区块链节点(假定满足三角不等式)之间的距离d ij。其中,区块链节点的局部密度定义为:
Figure PCTCN2021126988-appb-000005
其中,当x<0,χ(x)=1;x≥0,χ(x)=0。d ij是节点i到节点j之间的距离,d c是截断距离。基本上,ρ i等于比d c更靠近节点i的节点数量。并可以根据不同区块链网络节点规模对参数进行设置。
通过计算节点i与密度更高的任何其它节点之间的最小距离得到δ i。该最小距离的计算公式为:
Figure PCTCN2021126988-appb-000006
对于密度最高的节点i,则通过下述公式计算出节点i与其它节点之间的最大距离:
Figure PCTCN2021126988-appb-000007
基于此,只有对于密度为局部或全局最大值的节点,δ i的值远远大于典型的最近邻距离。因此,根据局部密度ρ i和距离δ i,可以构造出决策图,并基于决策图,将具有较大距离δ i且同时具有较大局部密度ρ i的节点定义为聚类中心(代理节点)。如此,通过这两个参 数(ρ i和δ i)的计算可以得到最优交换节点(代理节点),计算得到的最优交换节点会使其它节点与跨链交换节点交换数据的代价和最小,使跨链交换的网络传输代价最小。
Step2:代理节点将代理节点的ID以及所属区块链的系统配置信息发送给跨链公证人,以使跨链公证人通过第三方PKG基于代理节点的ID生成代理节点的公钥、私钥。
在确定出各区块链的代理节点之后,将各代理节点的ID、所属区块链的系统配置信息发送给跨链公证人,以便跨链公证人将各代理节点的ID发送给第三方PKG,第三方PKG基于各代理节点的ID计算出各代理节点的公钥、私钥。其中,各代理节点的公钥、私钥用于各代理节点进行安全通信。
示例性地,图3为本发明实施例提供的一种确定代理节点公钥、私钥的示意图。下面结合图3对本发明实施例中确定代理节点公钥、私钥的实施过程进行描述。
步骤a、PKG根据IBE初始化算法,生成系统参数(部分公开)和主密钥(保密)。
步骤b、PKG接收跨链公证人发送的身份信息(比如ID),并根据跨链公证人的身份信息、系统参数以及主密钥计算出跨链公证人的私钥,然后通过安全信道将跨链公证人的私钥发送给跨链公证人。
步骤c、跨链公证人接收各代理节点发送的ID以及所属区块链的系统配置信息,并记录各代理节点的ID和所属区块链的系统配置信息的映射关系,然后将各代理节点的ID发送给PKG,以使PKG根据各代理节点的ID、系统参数以及主密钥计算出各代理节点的公钥、私钥。其中,所属区块链的系统配置信息可以包括区块链系统底层架构、数据结构、接口协议、安全机制等信息。
步骤d、PKG注册各代理节点的ID,并根据各代理节点的ID计算各代理节点的公钥Q ID=H 1(ID)以及私钥d ID=s×Q ID,然后将各代理节点的私钥通过安全信道发送给各代理节点,并将各代理节点的公钥通过安全信道发送给跨链公证人。
步骤e、跨链公证人公开各代理节点的公钥,以便各区块链可通过代理节点和跨链公证人进行跨链安全通信。
Step3:区块链中任一节点发起跨链请求,代理节点通过共识算法确认本链节点发起的跨链请求。
在确定出各代理节点的公钥、私钥后,各区块链中任一节点可发起针对目标代理节点的跨链请求。在由代理节点发送跨链请求之前,需要通过共识算法对本链节点发起的跨链请求进行确认。下面对跨链请求的共识过程进行描述。
示例性地,本发明实施例以PBFT共识算法为例,对跨链请求的共识过程进行描述。
首先,对PBFT共识算法的共识过程进行介绍。该PBFT共识算法主要有2个线程,即PBFT密封器线程和PBFT共识线程。PBFT密封器线程从txPool中取出事务(比如跨链请求),并将事务打包成区块,将密封的区块封装到PBFT Prepare程序包中,然后将程序包发送给PBFT共识线程。PBFT共识线程从PBFT封闭器或P2P网络接收PBFT共识消息包,区块执行器Blockverifier模块响应执行区块,在共识过程完成后,已上链的事务将从txPool中删除。
具体地,PBFT共识过程包括三个阶段,即预先准备、准备和提交。其中,预先准备阶段为:节点执行程序块,生成签名包并将签名包广播到其它节点;准备阶段为:节点收集签名包,当收集(2×f+1)个签名包时,它将声明已从提交块准备就绪并开始广播Commit包进入提交阶段;提交阶段为:节点收集Commit包,当收集(2×f+1)个Commit 包时,它将把本地缓存的最新区块提交到数据库。
需要说明的是,在基于PBFT共识机制的联盟链中,参与共识的所有区块链节点不会直接同步来自其它节点的状态数据,而是先下载来自其它节点的区块,验证区块中的PBFT共识签名,然后执行区块中的所有交易,根据交易的执行结果来更新状态数据,保证所有需要上链的数据都经过签名的校验和执行的验证。
基于此,针对区块链中任一节点发起跨链请求,代理节点会通过PBFT共识算法对跨链请求进行共识确认,并在共识成功后,由代理节点完成后续的针对跨链请求的工作。
Step4:跨链公证人接收代理节点发送的跨链请求后,对跨链请求进行验证,并在验证成功后,触发代理节点与目标代理节点的跨链通信。
在代理节点通过共识算法确认本链节点发起的跨链请求后,发送跨链请求给跨链公证人进行验证,以便实现代理节点与目标代理节点的跨链通信。下面对代理节点与目标代理节点进行跨链通信的实施过程进行描述。
步骤a、代理节点利用SHA256算法对跨链请求进行处理,得到跨链请求的摘要,并使用自己的私钥对摘要进行签名,然后使用跨链公证人的公钥对签名和跨链请求进行加密,并将加密后的签名和跨链请求发送给跨链公证人。其中,跨链请求可以包括代理节点的ID、目标代理节点的ID等;跨链请求是指一个区块链(比如区块链1)上的某个节点想要与另一个区块链(比如区块链2)上的某个节点进行跨链交互所发起的请求,需要通过区块链1上的代理节点与区块链2上的代理节点进行跨链通信来完成。
步骤b、跨链公证人收到代理节点发送的加密后的签名和跨链请求后,使用自己的私钥对加密后的签名和跨链请求进行解密得到签名和跨链请求,并对签名进行验证。
步骤c、跨链公证人在确定签名验证通过后,基于代理节点的ID和目标代理节点的ID,从存储的各代理节点的ID和所属区块链的系统配置信息的映射关系中查询出代理节点所属区块链的系统配置信息和目标代理节点所属区块链的系统配置信息。并确定代理节点所属区块链的系统配置信息和目标代理节点所属区块链的系统配置信息是否匹配。如此,在进行系统配置信息匹配时,会出现两种情况,一种情况是系统配置信息一致;另一种情况是系统配置信息不一致。下面对出现的两种情况进行描述。
第一种情况为系统配置信息一致。此时代理节点与目标代理节点可以直接进行跨链通信。该跨链通信的具体过程为:
步骤1:代理节点接收跨链公证人发送签名验证通过以及系统配置信息一致的消息。
步骤2:代理节点和目标代理节点之间利用身份认证模块完成身份认证。即,在代理节点与目标代理节点进行跨链通信前,还需要对代理节点与目标代理节点的身份进行相互认证。下面对代理节点与目标代理节点进行身份认证的实施过程进行描述。
不同区块链的代理节点在通信前,需要进行身份认证。验证通过后才可以进行跨链通信。示例性地,在区块链1的代理节点1与区块链2的代理节点2开始通信前需要执行IBE身份认证算法,待双方通过身份认证后方可进行通信。其中,代理节点1可以为代理节点,代理节点2可以为目标代理节点;或者,代理节点1可以为目标代理节点,代理节点2可以为代理节点,本发明实施对此并不作限定。
1、代理节点1将自己的身份信息(比如ID)发送给代理节点2。即,基于代理节点1的ID,构建消息msg 1-1:{ID 1}。
2、代理节点2生成一个临时随机数nonce,记为N 1,并生成收到代理节点1发送的消 息msg 1时的时间戳T 0。再将N 1与T 0串联成X=N 1||T 0,并利用单向哈希函数计算出的摘要μ=H 3(X),并使用自己的私钥对摘要进行基于双线性映射的签名,然后将摘要μ、签名以及X一起发送给代理节点1。即,msg 2:{X,μ,e(μQ 1,d 2)}。其中,Q 1为代理节点1的公钥,d 2为代理节点2的私钥。
3、代理节点1生成收到代理节点2发送的消息msg 2时的时间戳T 1。为了确保本次收到的消息不是恶意消息,需要对时间戳进行校验。代理节点1校验T 1与T 0的时间间隔是否小于等于ΔT,如果不是,则确定消息来自于恶意攻击者,代理节点1会拒收该消息,并中断此次认证。如果是,则对消息的完整性做进一步验证,以避免消息被篡改。下面对代理节点1验证消息的完整性的实施过程进行描述。
步骤A、代理节点1从msg 2中提取出X、μ、e(μQ 1,d 2),并计算X的摘要μ 1=H 3(X)。
步骤B、判断消息完整性:若此时计算出的μ 1=μ,则确定X未被篡改;若不相等,则确定X被篡改过,然后终止认证。
步骤C、在检查消息保持完整性后,基于双线性映射,计算出e(sQ 11Q 2),与e(μQ 1,d 2)进行对比,验证代理节点2的签名。如果相等,则代理节点2的签名验证通过,说明消息确实来源于代理节点2,如此可以再一次验证消息X未被篡改。
需要说明的是,在代理节点1生成时间戳T 1的时候,代理节点1也会生成一个临时随机数nonce,记为N 2,并将N 2与T 1串联成X 1=N 2||T 1,并利用单向哈希函数计算出的摘要μ 2=H 3(X 1),并使用自己的私钥对摘要进行基于双线性映射的签名,然后将摘要μ 2、签名以及X 1一起发送给代理节点2。即,msg 1-2:{X 12,e(μ 2Q 2,d 1)}。其中,Q 2为代理节点2的公钥,d 1为代理节点1的私钥。
代理节点2生成收到代理节点1发送的消息msg 1-2时的时间戳T 2。并校验T 2与T 1的时间间隔是否小于等于ΔT,如果不是,则确定消息来自恶意攻击者,代理节点2会拒收消息,并中断认证过程。如果是,则对消息的完整性做进一步验证,以避免消息被篡改。下面对代理节点2验证消息的完整性的实施过程进行描述。
步骤A、代理节点2从msg 1-2中提取出X 1、μ 2、e(μ 2Q 2,d 1),并计算X 1的摘要μ 3=H 3(X 1)。
步骤B、判断消息完整性:若此时计算出的μ 3=μ 2,则确定X 1未被篡改;若不相等,则确定X 1被篡改过,然后终止认证。
步骤C、在检查消息保持完整性后,基于双线性映射,计算出e(sQ 23Q 1),与e(μ 2Q 2,d 1)进行对比,验证代理节点1的签名。如果相等,则代理节点1的签名验证通过,说明消息确实来源于代理节点1,如此可以再一次验证消息X 1未被篡改。
此外,需要说明的是,IBE算法中用户的公私钥对是椭圆曲线上的一对点。公钥由用户身份信息经过哈希函数H 1映射到椭圆曲线上的一个点,私钥由公钥映射的点与PKG的主密钥s进行点乘所得,因此,可以得到公钥Q i与私钥d i存在关系:
d i=sQ i
根据双线性映射配对的性质,可以得到e(sQ j1Q 1)=e(μ 1Q j,sQ 1),将d 1=sQ 1带入,则可以得到:
e(sQ j1Q 1)=e(μ 1Q j,sQ 1)=e(μQ j,d 1)
其中,Q 1为代理节点1的公钥,Q j为代理节点2或公证人节点的公钥。
如果发送过程中消息未被篡改,则代理节点2对消息X利用相同单向哈希函数计算得 到的μ 1满足等式μ 1=μ;当等式e(sQ 11Q 2)=e(μQ 1,d 2)成立时,可以证明该消息是由代理节点2发送给代理节点1的,由此确认身份认证成功;同理等式e(sQ 23Q 1)=e(μ 2Q 2,d 1)成立时,可以证明该消息是由代理节点1发送给代理节点2的,则确认身份认证成功。
另外,身份认证模块中的消息都不是明文发送,而是先通过哈希函数计算出哈希值,再用发送方的私钥对哈希值进行签名,将签名后的密文发送给接收方。所有经过篡改的消息,通过哈希函数都将得到完全不同的哈希值。而且,在与原哈希值比对后,可以验证消息是否被改动过。若消息在发送途中被篡改,接收方就可以很容易的侦察到。
其中,数据完整性是指数据从发出到接收的过程中未经篡改,如此,可以保证数据的正确性。目前常用的保证数据完整性的方式是使用哈希函数处理消息然后对处理后的消息进行签名。当然,身份认证模块在每个步骤都会对消息进行签名,使得消息发送者不可否认其是消息来源者的身份,提供了消息不可否认性。
步骤3:代理节点基于IBE算法的加密算法对要发送的跨链请求消息m进行加密,生成跨链请求消息m对应的跨链密文,并将跨链密文发送给目标代理节点(比如目标代理节点的ID为ID 2)。即,首先,随机选取r∈Z p *,然后,计算V=r×P,
Figure PCTCN2021126988-appb-000008
最后发送密文c=(V,W)给目标代理节点。
步骤4:目标代理节点收到密文后,基于IBE算法的解密算法对密文进行解密,计算
Figure PCTCN2021126988-appb-000009
可以得到跨链请求消息m,并从跨链请求消息m中提取出跨链请求,然后对跨链请求进行进一步处理。鉴于此,代理节点与目标代理节点进行了跨链通信。其中,d 2为目标代理节点的私钥。
第二种情况为系统配置信息不一致。若系统配置信息不一致,则由跨链公证人基于异构系统中区块链系统底层架构、数据结构、接口协议、安全机制等存在的差异情况对跨链请求的数据格式进行调整。并在调整后,基于跨链公证人来实现代理节点与目标代理节点的跨链通信。该跨链通信的具体过程为:
步骤1:跨链公证人向代理节点发送签名验证通过以及系统配置信息不一致的消息。
步骤2:跨链公证人根据目标代理节点所属区块链的系统配置信息对跨链请求的数据格式进行调整,并使用跨链公证人的私钥对调整过的跨链请求进行签名,然后将签名和调整过的跨链请求串联成新的消息m′等待发送。
步骤3:跨链公证人基于IBE算法的加密算法对要发送的跨链请求消息m′进行加密,生成跨链请求消息m′对应的跨链密文,并将跨链密文发送给目标代理节点(比如目标代理节点的ID为ID 2)。即,首先,随机选取r∈Z p *,然后,计算V=r×P,
Figure PCTCN2021126988-appb-000010
Figure PCTCN2021126988-appb-000011
最后发送密文c=(V,W)给目标代理节点。
步骤4:目标代理节点收到密文后,基于IBE算法的解密算法对密文进行解密,计算
Figure PCTCN2021126988-appb-000012
可以得到跨链请求消息m′,并使用跨链公证人的公钥验证跨链公证人的签名,在验证通过后从m′中提取出跨链请求,然后对跨链请求进行进一步处理。鉴于此,代理节点与目标代理节点进行了跨链通信。其中,d 2为目标代理节点的私钥。
需要说明的是,除了利用Step4的跨链通信方式可以实现代理节点与目标代理节点的跨链通信,本发明实施例还可以采用另一种方式实现代理节点与目标代理节点的跨链通信。下面对代理节点与目标代理节点进行跨链通信的另一实现方式进行描述。
步骤a、代理节点利用SHA256算法对跨链请求y进行处理,得到跨链请求y的摘要 μ=SHA256(y),并使用自己的私钥d 1对摘要进行签名,然后将签名和跨链请求合并成跨链请求消息,即跨链请求消息n=y||μ||e(μQ mid,d 1)。其中,Q mid为跨链公证人的公钥,d 1为代理节点的私钥。
步骤b、代理节点基于IBE算法的加密算法对要发送的跨链请求消息n进行加密,生成跨链请求消息n对应的跨链密文,并将跨链密文发送给跨链公证人(比如跨链公证人的ID为ID mid)。即,首先,随机选取r∈Z p *,然后,计算V=r×P,
Figure PCTCN2021126988-appb-000013
最后发送密文c=(V,W)给跨链公证人。
步骤c、跨链公证人收到密文后,基于IBE算法的解密算法对密文进行解密,计算
Figure PCTCN2021126988-appb-000014
可以得到跨链请求消息n,并从跨链请求消息n中提取出跨链请求y′。其中,d mid为跨链公证人的私钥。
步骤d、跨链公证人利用SHA256算法对跨链请求y′进行处理,得到跨链请求y′的摘要μ 1=SHA256(y′),若等式μ 1=μ成立,则证明消息在发送过程中未被篡改,即y′=y。若等式μ 1=μ不成立,则终止跨链过程,并返回失败信息给代理节点。
步骤e、跨链公证人基于双线性映射,计算出e(d mid1Q 1),若等式e(d mid1Q 1)=e(μQ mid,d 1)成立,则签名验证通过,证明该消息来自于代理节点,若等式e(d mid1Q 1)=e(μQ mid,d 1)不成立,则终止跨链过程,并返回失败信息给代理节点。
步骤f、跨链公证人从跨链请求y中提取出跨链相关信息,并从存储的各代理节点的ID和所属区块链的系统配置信息的映射关系中查询出跨链请求中两个代理节点所属区块链的系统配置信息是否匹配。
(1)若系统配置信息不一致,则由跨链公证人基于异构系统中区块链系统底层架构、数据结构、接口协议、安全机制等存在的差异情况对跨链请求的数据格式进行调整,并生成新的跨链请求y new
(2)若系统配置信息一致,则直接使用原来的跨链请求y new=y。
步骤g、跨链公证人利用SHA256算法对跨链请求y new进行处理,得到跨链请求y new的摘要μ 2=SHA256(y new),并使用自己的私钥d mid对摘要进行签名,然后将签名和跨链请求合并成跨链请求消息,即跨链请求消息n′=y new||μ 2||e(μ 2Q 2,d mid)。其中,Q 2为目标代理节点的公钥,d mid为跨链公证人的私钥。
步骤h、跨链公证人基于IBE算法的加密算法对要发送的跨链请求消息n′进行加密,生成跨链请求消息n′对应的跨链密文,并将跨链密文发送给目标代理节点(比如目标代理节点的ID为ID 2)。也即是,首先随机选取r∈Z p *,再计算V=r×P,
Figure PCTCN2021126988-appb-000015
然后发送密文c′=(V,W)给目标代理节点。
步骤i、目标代理节点收到密文c′后,基于IBE算法的解密算法对密文c′进行解密,计算出
Figure PCTCN2021126988-appb-000016
也就可以得到跨链请求消息n′,并可以从跨链请求消息n′中提取出跨链请求y new′。其中,d 2为目标代理节点的私钥。
步骤j、目标代理节点利用SHA256算法对跨链请求y new′进行处理,即可得到跨链请求y new′的摘要μ 3=SHA256(y new′),若等式μ 3=μ 2成立,则证明消息在发送过程中未被篡改,即y new′=y new。若等式μ 3=μ 2不成立,则终止跨链过程,并返回失败信息给跨链公证人。
步骤k、目标代理节点基于双线性映射,计算出e(d 23Q mid),若等式e(d 23Q mid)=e(μ 2Q 2,d mid)成立,则签名验证通过,证明该消息来自于跨链公证人,若等式 e(d 23Q mid)=e(μ 2Q 2,d mid)不成立,则终止跨链过程,并返回失败信息给跨链公证人。
步骤l、目标代理节点从跨链请求y new中提取出跨链相关信息,然后对跨链相关信息进行进一步处理。
基于相同的技术构思,图4示例性的示出了本发明实施例提供的一种跨链的区块链通信装置,该装置可以执行跨链的区块链通信方法的流程。其中,该装置适用于具有代理节点的区块链系统;所述代理节点用于对所述区块链系统内的节点的跨链消息进行转收发。
如图4所示,该装置包括:
接收单元401,用于接收第一代理节点发送的第一跨链密文;所述第一跨链密文是所述第一代理节点对本链节点发起的第一跨链请求进行共识后生成的;
第一处理单元402,用于解密所述第一跨链密文得到第二跨链请求并验证所述第二跨链请求;在验证通过所述第二跨链请求后,触发第二代理节点所在的区块链系统处理所述第二跨链请求。
可选地,所述第一跨链密文是所述第一代理节点基于IBE算法生成的IBE密文;所述IBE密文为所述第一代理节点通过IBE算法对第一拼接消息进行加密得到的;所述第一拼接消息包括所述第一跨链请求、所述第一跨链请求的第一摘要和所述第一摘要的第一签名;
所述第一处理单元402还用于:
通过IBE算法解密所述第一跨链密文,得到第二拼接消息;所述第二拼接消息包括所述第二跨链请求、所述第一摘要和所述第一签名;
生成所述第二跨链请求的第二摘要;
确定所述第二摘要与所述第一摘要是否一致;
根据所述第二摘要生成第二签名;
确定所述第二签名与所述第一签名是否一致。
可选地,所述第一摘要的第一签名是利用所述第一代理节点的私钥进行的基于双线性映射生成的签名;
所述第一处理单元402具体用于:
所述第一代理节点的公钥、私钥存在如下关系:
d 1=sQ 1
根据双线性映射配对的性质,得到e(sQ j1Q 1)=e(μ 1Q j,sQ 1),并基于所述第一代理节点的私钥,生成所述第一签名;所述第一签名满足如下形式:
e(sQ j1Q 1)=e(μ 1Q j,sQ 1)=e(μQ j,d 1)
其中,e(μQ j,d 1)为所述第一签名,Q 1为所述第一代理节点的公钥,μ为所述第一摘要,μ 1为所述第二摘要,Q j为第二代理节点或公证人节点的公钥,d 1为所述第一代理节点的私钥,s为第三方PKG的主密钥。
可选地,所述跨链验证节点为公证人节点;
所述第一处理单元402具体用于:
在验证通过所述第二跨链请求后,根据所述第二跨链请求生成第二跨链密文;
将所述第二跨链密文发送至所述第二代理节点,以使通过所述第二代理节点所在的区块链系统处理所述第二跨链密文。
可选地,所述第一处理单元402具体用于:
确定所述第一代理节点所在的区块链系统与所述第二代理节点所在的区块链系统是 否具有相同的配置;
若确定具有相同的配置,则根据所述第二跨链请求生成所述第二跨链密文;
若确定不具有相同的配置,则根据所述第二代理节点所在的区块链系统的配置,将所述第二跨链请求调整为第三跨链请求,并根据所述第三跨链请求生成所述第二跨链密文。
可选地,所述跨链验证节点为第二代理节点;
所述第一处理单元402还用于:
与所述第一代理节点相互进行身份确认;所述身份确认是所述第一代理节点在接收到公证人节点发送的配置一致指示后发起的;所述配置一致指示是所述公证人节点在确定所述第一代理节点所在的区块链系统与所述第二代理节点所在的区块链系统具有相同的配置时发送的。
可选地,所述第一处理单元402具体用于:
接收所述第一代理节点发送的第一标识;
基于第一随机数生成第一认证信息并发送给所述第一代理节点;所述第一认证信息用于所述第一代理节点对所述第二代理节点进行身份认证;
接收所述第一代理节点发送的第二认证信息并对所述第二认证信息进行验证;所述第二认证消息是所述第一代理节点基于第二随机数生成的。
可选地,所述跨链验证节点为公证人节点;
所述第一跨链密文是所述第一代理节点通过签名机制生成的签名密文;所述签名密文包括对所述第一跨链请求的签名和所述第一跨链请求;
所述第一处理单元402具体用于:
在确定所述第一代理节点所在的区块链系统与所述第二代理节点所在的区块链系统不具有相同的配置时,根据所述第二代理节点所在的区块链系统的配置,将所述第二跨链请求调整为第三跨链请求,并根据所述第三跨链请求生成所述第二跨链密文;
将所述第二跨链密文发送给所述第二代理节点。
基于相同的技术构思,图5示例性的示出了本发明实施例提供的一种跨链的区块链通信装置,该装置可以执行跨链的区块链通信方法的流程。其中,该装置适用于具有代理节点的区块链系统;所述代理节点用于对所述区块链系统内的节点的跨链消息进行转收发。
如图5所示,该装置包括:
生成单元501,用于对本链节点发起的第一跨链请求进行共识后,基于所述第一跨链请求生成第一跨链密文;
第二处理单元502,用于将所述第一跨链密文发送给跨链验证节点;所述跨链验证节点用于解密所述第一跨链密文得到第二跨链请求并在验证通过所述第二跨链请求后,触发第二代理节点所在的区块链系统处理所述第二跨链请求。
可选地,所述第二处理单元502具体用于:
对本链节点发起的第一跨链请求进行共识后,基于所述第一跨链请求生成签名密文;
将所述第一跨链密文发送给跨链验证节点之后,还包括:
接收所述跨链验证节点发送的配置一致指示;所述配置一致指示是所述跨链验证节点在对所述签名密文验证通过且所述第一代理节点所在的区块链系统与第二代理节点所在的区块链系统具有相同的配置时发送的;
通过IBE算法对第一拼接消息进行加密得到IBE密文;所述第一拼接消息包括所述第 一跨链请求、所述第一跨链请求的第一摘要和所述第一摘要的第一签名;
将所述IBE密文发送给所述第二代理节点。
可选地,所述第二处理单元502具体用于:
对本链节点发起的第一跨链请求进行共识后,通过IBE算法对第一拼接消息进行加密得到IBE密文;所述第一拼接消息包括所述第一跨链请求、所述第一跨链请求的第一摘要和所述第一摘要的第一签名。
可选地,所述第二处理单元502具体用于:
针对所述区块链系统内的各节点,基于预设的选举规则,确定出所述各节点的局部密度;
针对每个节点,确定所述节点的局部密度是否为最大;若所述节点的局部密度为最大,则确定出所述节点与其它节点间的最大距离;若所述节点的局部密度不为最大,则确定出所述节点与其它节点间的最小距离;
通过对所述各节点的局部密度、最大距离、最小距离进行处理,将局部密度最大且距离最大对应的节点确定为所述第一代理节点。
基于相同的技术构思,本发明实施例提供一种计算设备,包括:
存储器,用于存储计算机程序;
处理器,用于调用所述存储器中存储的计算机程序,按照获得的程序执行跨链的区块链通信方法。
基于相同的技术构思,本发明实施例提供一种计算机可读存储介质,所述计算机可读存储介质存储有计算机可执行程序,所述计算机可执行程序用于使计算机执行跨链的区块链通信方法。
本领域内的技术人员应明白,本发明的实施例可提供为方法、系统、或计算机程序产品。因此,本发明可采用完全硬件实施例、完全软件实施例、或结合软件和硬件方面的实施例的形式。而且,本发明可采用在一个或多个其中包含有计算机可用程序代码的计算机可用存储介质(包括但不限于磁盘存储器、CD-ROM、光学存储器等)上实施的计算机程序产品的形式。
本发明是参照根据本发明的方法、设备(系统)、和计算机程序产品的流程图和/或方框图来描述的。应理解可由计算机程序指令实现流程图和/或方框图中的每一流程和/或方框、以及流程图和/或方框图中的流程和/或方框的结合。可提供这些计算机程序指令到通用计算机、专用计算机、嵌入式处理机或其他可编程数据处理设备的处理器以产生一个机器,使得通过计算机或其他可编程数据处理设备的处理器执行的指令产生用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的装置。
显然,本领域的技术人员可以对本发明进行各种改动和变型而不脱离本发明的精神和范围。这样,倘若本发明的这些修改和变型属于本申请权利要求及其等同技术的范围之内,则本发明也意图包含这些改动和变型在内。

Claims (14)

  1. 一种跨链的区块链通信方法,其特征在于,适用于具有代理节点的区块链系统;所述代理节点用于对所述区块链系统内的节点的跨链消息进行转收发;所述方法包括:
    跨链验证节点接收第一代理节点发送的第一跨链密文;所述第一跨链密文是所述第一代理节点对本链节点发起的第一跨链请求进行共识后生成的;
    所述跨链验证节点解密所述第一跨链密文得到第二跨链请求并验证所述第二跨链请求;
    所述跨链验证节点在验证通过所述第二跨链请求后,触发第二代理节点所在的区块链系统处理所述第二跨链请求。
  2. 如权利要求1所述的方法,其特征在于,所述第一跨链密文是所述第一代理节点基于IBE算法生成的IBE密文;所述IBE密文为所述第一代理节点通过IBE算法对第一拼接消息进行加密得到的;所述第一拼接消息包括所述第一跨链请求、所述第一跨链请求的第一摘要和所述第一摘要的第一签名;
    所述跨链验证节点解密所述第一跨链密文得到第二跨链请求并验证所述第二跨链请求,包括:
    所述跨链验证节点通过IBE算法解密所述第一跨链密文,得到第二拼接消息;所述第二拼接消息包括所述第二跨链请求、所述第一摘要和所述第一签名;
    所述跨链验证节点生成所述第二跨链请求的第二摘要;
    所述跨链验证节点确定所述第二摘要与所述第一摘要是否一致;
    所述跨链验证节点根据所述第二摘要生成第二签名;
    所述跨链验证节点确定所述第二签名与所述第一签名是否一致。
  3. 如权利要求2所述的方法,其特征在于,所述第一摘要的第一签名是利用所述第一代理节点的私钥进行的基于双线性映射生成的签名;
    通过下述方式生成所述第一签名:
    所述第一代理节点的公钥、私钥存在如下关系:
    d 1=sQ 1
    根据双线性映射配对的性质,得到e(sQ j1Q 1)=e(μ 1Q j,sQ 1),并基于所述第一代理节点的私钥,生成所述第一签名;所述第一签名满足如下形式:
    e(sQ j1Q 1)=e(μ 1Q j,sQ 1)=e(μQ j,d 1)
    其中,e(μQ j,d 1)为所述第一签名,Q 1为所述第一代理节点的公钥,μ为所述第一摘要,μ 1为所述第二摘要,Q j为第二代理节点或公证人节点的公钥,d 1为所述第一代理节点的私钥,s为第三方PKG的主密钥。
  4. 如权利要求1至3任一项所述的方法,其特征在于,所述跨链验证节点为公证人节点;
    所述跨链验证节点在验证通过所述第二跨链请求后,触发第二代理节点所在的区块链系统处理所述第二跨链请求,包括:
    所述公证人节点在验证通过所述第二跨链请求后,根据所述第二跨链请求生成第二跨链密文;
    所述公证人节点将所述第二跨链密文发送至所述第二代理节点,以使通过所述第二代 理节点所在的区块链系统处理所述第二跨链密文。
  5. 如权利要求4所述的方法,其特征在于,所述根据所述第二跨链请求生成第二跨链密文,包括:
    所述公证人节点确定所述第一代理节点所在的区块链系统与所述第二代理节点所在的区块链系统是否具有相同的配置;
    所述公证人节点若确定具有相同的配置,则根据所述第二跨链请求生成所述第二跨链密文;
    所述公证人节点若确定不具有相同的配置,则根据所述第二代理节点所在的区块链系统的配置,将所述第二跨链请求调整为第三跨链请求,并根据所述第三跨链请求生成所述第二跨链密文。
  6. 如权利要求1至3任一项所述的方法,其特征在于,所述跨链验证节点为第二代理节点;
    在所述跨链验证节点接收第一代理节点发送的第一跨链密文之前,还包括:
    所述第二代理节点与所述第一代理节点相互进行身份确认;所述身份确认是所述第一代理节点在接收到公证人节点发送的配置一致指示后发起的;所述配置一致指示是所述公证人节点在确定所述第一代理节点所在的区块链系统与所述第二代理节点所在的区块链系统具有相同的配置时发送的。
  7. 如权利要求1所述的方法,其特征在于,所述第二代理节点与所述第一代理节点相互进行身份确认,包括:
    所述第二代理节点接收所述第一代理节点发送的第一标识;
    所述第二代理节点基于第一随机数生成第一认证信息并发送给所述第一代理节点;所述第一认证信息用于所述第一代理节点对所述第二代理节点进行身份认证;
    所述第二代理节点接收所述第一代理节点发送的第二认证信息并对所述第二认证信息进行验证;所述第二认证消息是所述第一代理节点基于第二随机数生成的。
  8. 如权利要求1所述的方法,其特征在于,所述跨链验证节点为公证人节点;
    所述第一跨链密文是所述第一代理节点通过签名机制生成的签名密文;所述签名密文包括对所述第一跨链请求的签名和所述第一跨链请求;
    所述跨链验证节点在验证通过所述第二跨链请求后,触发第二代理节点所在的区块链系统处理所述第二跨链请求,包括:
    所述公证人节点在确定所述第一代理节点所在的区块链系统与所述第二代理节点所在的区块链系统不具有相同的配置时,根据所述第二代理节点所在的区块链系统的配置,将所述第二跨链请求调整为第三跨链请求,并根据所述第三跨链请求生成所述第二跨链密文;
    所述公证人节点将所述第二跨链密文发送给所述第二代理节点。
  9. 一种跨链的区块链通信方法,其特征在于,适用于具有代理节点的区块链系统;所述代理节点用于对所述区块链系统内的节点的跨链消息进行转收发;所述方法包括:
    第一代理节点对本链节点发起的第一跨链请求进行共识后,基于所述第一跨链请求生成第一跨链密文;
    所述第一代理节点将所述第一跨链密文发送给跨链验证节点;所述跨链验证节点用于解密所述第一跨链密文得到第二跨链请求并在验证通过所述第二跨链请求后,触发第二代 理节点所在的区块链系统处理所述第二跨链请求。
  10. 如权利要求9所述的方法,其特征在于,所述第一代理节点对本链节点发起的第一跨链请求进行共识后,基于所述第一跨链请求生成第一跨链密文,包括:
    第一代理节点对本链节点发起的第一跨链请求进行共识后,基于所述第一跨链请求生成签名密文;
    所述第一代理节点将所述第一跨链密文发送给跨链验证节点之后,还包括:
    所述第一代理节点接收所述跨链验证节点发送的配置一致指示;所述配置一致指示是所述跨链验证节点在对所述签名密文验证通过且所述第一代理节点所在的区块链系统与第二代理节点所在的区块链系统具有相同的配置时发送的;
    所述第一代理节点通过IBE算法对第一拼接消息进行加密得到IBE密文;所述第一拼接消息包括所述第一跨链请求、所述第一跨链请求的第一摘要和所述第一摘要的第一签名;
    所述第一代理节点将所述IBE密文发送给所述第二代理节点。
  11. 如权利要求9所述的方法,其特征在于,所述第一代理节点对本链节点发起的第一跨链请求进行共识后,基于所述第一跨链请求生成第一跨链密文,包括:
    第一代理节点对本链节点发起的第一跨链请求进行共识后,通过IBE算法对第一拼接消息进行加密得到IBE密文;所述第一拼接消息包括所述第一跨链请求、所述第一跨链请求的第一摘要和所述第一摘要的第一签名。
  12. 如权利要求9所述的方法,其特征在于,根据下述方式确定所述第一代理节点:
    针对所述区块链系统内的各节点,基于预设的选举规则,确定出所述各节点的局部密度;
    针对每个节点,确定所述节点的局部密度是否为最大;若所述节点的局部密度为最大,则确定出所述节点与其它节点间的最大距离;若所述节点的局部密度不为最大,则确定出所述节点与其它节点间的最小距离;
    通过对所述各节点的局部密度、最大距离、最小距离进行处理,将局部密度最大且距离最大对应的节点确定为所述第一代理节点。
  13. 一种跨链的区块链通信装置,其特征在于,适用于具有代理节点的区块链系统;所述代理节点用于对所述区块链系统内的节点的跨链消息进行转收发;所述装置包括:
    接收单元,用于接收第一代理节点发送的第一跨链密文;所述第一跨链密文是所述第一代理节点对本链节点发起的第一跨链请求进行共识后生成的;
    第一处理单元,用于解密所述第一跨链密文得到第二跨链请求并验证所述第二跨链请求;在验证通过所述第二跨链请求后,触发第二代理节点所在的区块链系统处理所述第二跨链请求。
  14. 一种跨链的区块链通信装置,其特征在于,适用于具有代理节点的区块链系统;所述代理节点用于对所述区块链系统内的节点的跨链消息进行转收发;所述装置包括:
    生成单元,用于对本链节点发起的第一跨链请求进行共识后,基于所述第一跨链请求生成第一跨链密文;
    第二处理单元,用于将所述第一跨链密文发送给跨链验证节点;所述跨链验证节点用于解密所述第一跨链密文得到第二跨链请求并在验证通过所述第二跨链请求后,触发第二代理节点所在的区块链系统处理所述第二跨链请求。
PCT/CN2021/126988 2020-11-18 2021-10-28 一种跨链的区块链通信方法及装置 WO2022105565A1 (zh)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
CN202011294886.7 2020-11-18
CN202011294886.7A CN112491846B (zh) 2020-11-18 2020-11-18 一种跨链的区块链通信方法及装置

Publications (1)

Publication Number Publication Date
WO2022105565A1 true WO2022105565A1 (zh) 2022-05-27

Family

ID=74931384

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/CN2021/126988 WO2022105565A1 (zh) 2020-11-18 2021-10-28 一种跨链的区块链通信方法及装置

Country Status (2)

Country Link
CN (1) CN112491846B (zh)
WO (1) WO2022105565A1 (zh)

Cited By (12)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN115150057A (zh) * 2022-06-30 2022-10-04 南京航空航天大学 一种区块链跨链交互数据计算结果的完整性验证方法
CN115174204A (zh) * 2022-07-01 2022-10-11 京东科技控股股份有限公司 数据传输方法、装置和系统
CN115189965A (zh) * 2022-09-06 2022-10-14 浙江数秦科技有限公司 一种区块链的跨链管理系统及跨链操作方法
CN115277110A (zh) * 2022-07-04 2022-11-01 河北嘉朗科技有限公司 一种在云原生环境下解决区块链节点跨网通信问题的方法
CN115396122A (zh) * 2022-10-27 2022-11-25 聚梦创新(北京)软件技术有限公司 消息处理方法、装置、电子设备及存储介质
CN115967563A (zh) * 2022-12-23 2023-04-14 四川启睿克科技有限公司 一种基于区块链的能源数据采集上链系统及方法
CN116170158A (zh) * 2023-02-15 2023-05-26 北京邮电大学 基于多链架构的跨域安全审查方法及装置
CN116506104A (zh) * 2023-06-25 2023-07-28 天津市城市规划设计研究总院有限公司 基于跨链区块链的不同部门信息安全交互的方法及系统
CN116866009A (zh) * 2023-06-15 2023-10-10 蚂蚁区块链科技(上海)有限公司 基于认证网络的跨链身份验证方法及装置
CN117319083A (zh) * 2023-11-27 2023-12-29 人民法院信息技术服务中心 一种异构隐私数据的跨链共享方法、装置、系统及设备
CN117527183A (zh) * 2023-11-14 2024-02-06 济南大学 一种面向电力数据的去中心化共享与跨链计算方法及系统
CN117879785A (zh) * 2024-03-08 2024-04-12 人民法院信息技术服务中心 基于跨链的司法数据共享系统、方法及计算机设备

Families Citing this family (11)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN112491846B (zh) * 2020-11-18 2023-04-18 深圳前海微众银行股份有限公司 一种跨链的区块链通信方法及装置
CN112637127B (zh) * 2020-11-23 2022-05-13 北京邮电大学 一种跨区块链通信方法及装置
CN112804354B (zh) * 2021-03-19 2021-07-06 腾讯科技(深圳)有限公司 跨链进行数据传输的方法、装置、计算机设备和存储介质
CN112732800B (zh) * 2021-03-30 2021-07-13 支付宝(杭州)信息技术有限公司 提供跨链消息的方法和装置
CN113507364B (zh) * 2021-07-14 2023-02-28 中国建设银行股份有限公司 一种交易账本的处理方法、装置、电子设备和存储介质
CN113904869B (zh) * 2021-11-10 2024-04-19 深圳前海微众银行股份有限公司 一种区块链中恶意节点的检测方法及区块链
CN114297680B (zh) * 2021-12-27 2024-05-17 广州大学 一种用于物联网环境的区块链跨链共识方法和系统
CN114760288B (zh) * 2022-03-18 2024-02-06 国网四川省电力公司天府新区供电公司 一种基于区块链的文件跨链传输方法
CN115378942B (zh) * 2022-10-10 2022-12-20 北京理工大学 一种区块链的信息跨链交互方法和交互装置
CN115941354B (zh) * 2022-12-31 2024-04-19 广州市鑫澳康科技有限公司 基于区块链的跨链交互身份认证方法、装置及计算机可读介质
CN116321159B (zh) * 2023-01-14 2024-01-02 国网湖北省电力有限公司荆门供电公司 一种基于北斗通信服务的分散场站数据传输方法

Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN110266655A (zh) * 2019-05-30 2019-09-20 中国工商银行股份有限公司 一种基于区块链的跨链互联方法、设备以及系统
US20190340267A1 (en) * 2018-05-01 2019-11-07 International Business Machines Corporation Blockchain implementing cross-chain transactions
CN111416808A (zh) * 2020-03-13 2020-07-14 财付通支付科技有限公司 跨区块链的数据互存方法、装置、设备及存储介质
CN111770102A (zh) * 2020-07-01 2020-10-13 中国建设银行股份有限公司 一种区块链跨链方法、装置、计算机设备及存储介质
CN112491846A (zh) * 2020-11-18 2021-03-12 深圳前海微众银行股份有限公司 一种跨链的区块链通信方法及装置

Family Cites Families (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN108900585A (zh) * 2018-06-15 2018-11-27 浙江华信区块链科技服务有限公司 跨链事务一致性实现方法
CN109559227A (zh) * 2018-11-29 2019-04-02 咪咕文化科技有限公司 一种跨区块链网络的交易方法、装置及存储介质
CN111080449B (zh) * 2019-12-03 2023-12-19 深圳前海微众银行股份有限公司 区块链的跨链交易方法、管理节点、区块链网络
CN111769948B (zh) * 2020-06-15 2023-06-02 布比(北京)网络技术有限公司 基于区块链的链间交互方法、系统、装置和计算机设备
CN111741114B (zh) * 2020-06-24 2023-05-16 陈鹏 基于区块链的可监管跨链交互系统、方法及设备
CN111681003B (zh) * 2020-07-07 2021-06-25 腾讯科技(深圳)有限公司 资源跨链转移方法、装置、计算机设备以及存储介质

Patent Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20190340267A1 (en) * 2018-05-01 2019-11-07 International Business Machines Corporation Blockchain implementing cross-chain transactions
CN110266655A (zh) * 2019-05-30 2019-09-20 中国工商银行股份有限公司 一种基于区块链的跨链互联方法、设备以及系统
CN111416808A (zh) * 2020-03-13 2020-07-14 财付通支付科技有限公司 跨区块链的数据互存方法、装置、设备及存储介质
CN111770102A (zh) * 2020-07-01 2020-10-13 中国建设银行股份有限公司 一种区块链跨链方法、装置、计算机设备及存储介质
CN112491846A (zh) * 2020-11-18 2021-03-12 深圳前海微众银行股份有限公司 一种跨链的区块链通信方法及装置

Cited By (18)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN115150057A (zh) * 2022-06-30 2022-10-04 南京航空航天大学 一种区块链跨链交互数据计算结果的完整性验证方法
CN115174204A (zh) * 2022-07-01 2022-10-11 京东科技控股股份有限公司 数据传输方法、装置和系统
CN115277110A (zh) * 2022-07-04 2022-11-01 河北嘉朗科技有限公司 一种在云原生环境下解决区块链节点跨网通信问题的方法
CN115277110B (zh) * 2022-07-04 2023-07-28 河北嘉朗科技有限公司 一种在云原生环境下解决区块链节点跨网通信问题的方法
CN115189965A (zh) * 2022-09-06 2022-10-14 浙江数秦科技有限公司 一种区块链的跨链管理系统及跨链操作方法
CN115396122A (zh) * 2022-10-27 2022-11-25 聚梦创新(北京)软件技术有限公司 消息处理方法、装置、电子设备及存储介质
CN115967563A (zh) * 2022-12-23 2023-04-14 四川启睿克科技有限公司 一种基于区块链的能源数据采集上链系统及方法
CN115967563B (zh) * 2022-12-23 2024-05-28 四川启睿克科技有限公司 一种基于区块链的能源数据采集上链方法
CN116170158A (zh) * 2023-02-15 2023-05-26 北京邮电大学 基于多链架构的跨域安全审查方法及装置
CN116866009B (zh) * 2023-06-15 2024-03-26 蚂蚁区块链科技(上海)有限公司 基于认证网络的跨链身份验证方法、装置、电子设备及存储介质
CN116866009A (zh) * 2023-06-15 2023-10-10 蚂蚁区块链科技(上海)有限公司 基于认证网络的跨链身份验证方法及装置
CN116506104A (zh) * 2023-06-25 2023-07-28 天津市城市规划设计研究总院有限公司 基于跨链区块链的不同部门信息安全交互的方法及系统
CN116506104B (zh) * 2023-06-25 2023-08-29 天津市城市规划设计研究总院有限公司 基于跨链区块链的不同部门信息安全交互的方法及系统
CN117527183A (zh) * 2023-11-14 2024-02-06 济南大学 一种面向电力数据的去中心化共享与跨链计算方法及系统
CN117319083B (zh) * 2023-11-27 2024-02-27 人民法院信息技术服务中心 一种异构隐私数据的跨链共享方法、装置、系统及设备
CN117319083A (zh) * 2023-11-27 2023-12-29 人民法院信息技术服务中心 一种异构隐私数据的跨链共享方法、装置、系统及设备
CN117879785A (zh) * 2024-03-08 2024-04-12 人民法院信息技术服务中心 基于跨链的司法数据共享系统、方法及计算机设备
CN117879785B (zh) * 2024-03-08 2024-05-24 人民法院信息技术服务中心 基于跨链的司法数据共享系统、方法及计算机设备

Also Published As

Publication number Publication date
CN112491846A (zh) 2021-03-12
CN112491846B (zh) 2023-04-18

Similar Documents

Publication Publication Date Title
WO2022105565A1 (zh) 一种跨链的区块链通信方法及装置
US10841295B1 (en) Extensions for using a digital certificate with multiple cryptosystems
CN110535628B (zh) 通过证书签发进行多方安全计算的方法及装置
Wang et al. Security analysis of a single sign-on mechanism for distributed computer networks
Zhang et al. Efficient ID-based public auditing for the outsourced data in cloud storage
US9800416B2 (en) Distributed validation of digitally signed electronic documents
US11223486B2 (en) Digital signature method, device, and system
Toorani et al. LPKI-a lightweight public key infrastructure for the mobile environments
CN114710275B (zh) 物联网环境下基于区块链的跨域认证和密钥协商方法
CN110677240A (zh) 通过证书签发提供高可用计算服务的方法及装置
US11038699B2 (en) Method and apparatus for performing multi-party secure computing based-on issuing certificate
CN113630248B (zh) 一种会话密钥协商方法
WO2019110018A1 (zh) 通信网络系统的消息验证方法、通信方法和通信网络系统
CN113612610B (zh) 一种会话密钥协商方法
Bao et al. A lightweight privacy‐preserving scheme with data integrity for smart grid communications
WO2023184858A1 (zh) 一种时间戳生成方法、装置、电子设备及存储介质
Zhang et al. NDN-MPS: supporting multiparty authentication over named data networking
WO2023010688A1 (zh) 一种密钥管理方法及装置
Albasheer et al. Enhanced model for PKI certificate validation in the mobile banking
Tian et al. Cryptanalysis and improvement of a certificateless multi-proxy signature scheme
Luo et al. An Efficient Consensus Algorithm for Blockchain-Based Cross-Domain Authentication in Bandwidth-Constrained Wide Area IoT Networks
Zhang et al. Shared group session key-based conditional privacy-preserving authentication protocol for VANETs
Zhong et al. CD-BASA: An Efficient Cross-Domain Batch Authentication Scheme Based on Blockchain With Accumulator for VANETs
Chai et al. BSCDA: Blockchain-Based Secure Cross-Domain Data Access Scheme for Internet of Things
CN117081869B (zh) 智能电网安全数据聚合方法、装置、存储介质及相关设备

Legal Events

Date Code Title Description
NENP Non-entry into the national phase

Ref country code: DE

32PN Ep: public notification in the ep bulletin as address of the adressee cannot be established

Free format text: NOTING OF LOSS OF RIGHTS PURSUANT TO RULE 112(1) EPC (EPO FORM 1205A DATED 24/08/2023)

122 Ep: pct application non-entry in european phase

Ref document number: 21893713

Country of ref document: EP

Kind code of ref document: A1