WO2023078123A1 - 区块链中继通信网络的中立性验证 - Google Patents

区块链中继通信网络的中立性验证 Download PDF

Info

Publication number
WO2023078123A1
WO2023078123A1 PCT/CN2022/127236 CN2022127236W WO2023078123A1 WO 2023078123 A1 WO2023078123 A1 WO 2023078123A1 CN 2022127236 W CN2022127236 W CN 2022127236W WO 2023078123 A1 WO2023078123 A1 WO 2023078123A1
Authority
WO
WIPO (PCT)
Prior art keywords
node
message
blockchain
verification
block chain
Prior art date
Application number
PCT/CN2022/127236
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
Priority claimed from CN202111306181.7A external-priority patent/CN114095499B/zh
Application filed by 支付宝(杭州)信息技术有限公司, 蚂蚁区块链科技(上海)有限公司 filed Critical 支付宝(杭州)信息技术有限公司
Publication of WO2023078123A1 publication Critical patent/WO2023078123A1/zh

Links

Images

Classifications

    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00Network arrangements or protocols for supporting network services or applications
    • H04L67/01Protocols
    • H04L67/10Protocols in which an application is distributed across nodes in the network
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L43/00Arrangements for monitoring or testing data switching networks
    • H04L43/08Monitoring or testing based on specific metrics, e.g. QoS, energy consumption or environmental parameters
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L43/00Arrangements for monitoring or testing data switching networks
    • H04L43/08Monitoring or testing based on specific metrics, e.g. QoS, energy consumption or environmental parameters
    • H04L43/0852Delays
    • H04L43/0864Round trip delays
    • 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
    • H04L63/045Network 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 wherein the sending and receiving network entities apply hybrid encryption, i.e. combination of symmetric and asymmetric encryption
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00Network architectures or network communication protocols for network security
    • H04L63/08Network architectures or network communication protocols for network security for authentication of entities
    • 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

Definitions

  • the embodiment of this specification relates to the field of blockchain technology, and in particular to a neutrality verification method and device for a blockchain relay communication network.
  • the blockchain network contains several blockchain nodes, and communication operations such as consensus, transaction transmission, and block synchronization need to be implemented between blockchain nodes.
  • P2P Peer to Peer, point-to-point
  • the communication delay is high, The stability is poor and cannot meet the application requirements.
  • a blockchain communication technology based on a blockchain relay communication network is proposed in the related art.
  • the blockchain nodes in the blockchain network can be respectively connected to the blockchain relay communication network, so that the blockchain nodes can communicate through the blockchain relay communication network.
  • the blockchain relay communication network is a backbone relay communication network for real-time transmission of the blockchain, each relay node can communicate and interact through high-quality bandwidth guaranteed by high QoS, so it is taken over by the blockchain relay communication network
  • the middle mile of communication between blockchain nodes can reduce communication delay and improve stability, thereby significantly improving the communication quality between blockchain nodes.
  • the embodiments of this specification provide a neutrality verification method and device for a blockchain relay communication network.
  • a neutrality verification method of a blockchain relay communication network including: the source blockchain node sends a neutrality verification method to the target blockchain node through the blockchain relay communication network
  • the neutral verification message includes the first encrypted message content generated by encrypting the first message content with the first symmetric key and the identity private key of the source blockchain node as the first
  • the digital signature generated by the encrypted message content, the first message content contains the neutrality verification message type identification
  • the target blockchain node receives the interactive message according to the identity public key of the source blockchain node verify the digital signature, and use the first symmetric key to decrypt the encrypted message content contained in the interaction message, and include the neutrality verification message in the message content obtained by successful signature verification and decryption
  • the target blockchain node responds to the The source block chain node’s identity public key verification successful interaction message performs data volume statistics to obtain the received data volume
  • a neutrality verification method of a blockchain relay communication network which is applied to a source blockchain node, and the method includes: obtaining a neutrality verification message, the neutrality
  • the verification message includes the first encrypted message content generated by encrypting the first message content with the first symmetric key and the digital signature generated for the first encrypted message content by the identity private key of the source blockchain node , the content of the first message includes a neutrality verification message type identifier; the neutrality verification message is sent to the target blockchain node through the blockchain relay communication network, so that the target blockchain node: according to the source
  • the identity public key of the blockchain node verifies the digital signature contained in the received interaction message, and uses the first symmetric key to decrypt the encrypted message content contained in the interaction message, and If the signing is successful and the decrypted message content contains the neutrality verification message type identifier, return a receipt confirmation message to the source blockchain node through the blockchain relay communication network; and, for the preset Perform data volume statistics on the interactive messages received
  • a neutral verification method of a blockchain relay communication network which is applied to a target blockchain node, and the method includes: receiving the source blockchain node through the blockchain
  • the neutrality verification message sent by the relay communication network the neutrality verification message includes the first encrypted message content generated by encrypting the first message content with the first symmetric key and the identity of the source block chain node
  • the private key is the digital signature generated by the first encrypted message content
  • the first message content contains the neutral verification message type identification
  • the received interactive message contains verify the digital signature, and use the first symmetric key to decrypt the encrypted message content contained in the interaction message, and include the neutrality verification message in the message content obtained by successful signature verification and decryption
  • return a receipt confirmation message to the source blockchain node through the blockchain relay communication network so that the source blockchain node can verify the sending time of the message according to the neutrality and the receiving confirmation message.
  • the sent data volume of the interactive message sent out is compared; wherein, the condition for judging that the blockchain relay communication network is neutral includes that the round-trip delay matches the source blockchain node and the target block The actual environment between the chain nodes, and the amount of received data is consistent with the amount of sent data.
  • a neutral verification system for a blockchain relay communication network including: a source blockchain node and a target blockchain node; wherein: the source blockchain node Send a neutrality verification message to the target blockchain node through the block chain relay communication network, the neutrality verification message includes the first encrypted message content generated by encrypting the first message content with the first symmetric key and the digital signature generated by the identity private key of the source block chain node for the first encrypted message content, the first message content includes a neutral verification message type identifier; the target block chain node according to the Verify the digital signature contained in the received interactive message with the identity public key of the source blockchain node, and use the first symmetric key to decrypt the encrypted message content contained in the interactive message, and If the signature verification is successful and the decrypted message content contains the neutrality verification message type identifier, return a receipt confirmation message to the source blockchain node through the blockchain relay communication network; and, the The target blockchain node performs data volume statistics on the interactive messages received within the
  • a neutrality verification device for a blockchain relay communication network which is applied to a source blockchain node, and includes: an acquisition unit, configured to acquire a neutrality verification message, the The neutrality verification message includes the first encrypted message content generated by encrypting the first message content with the first symmetric key and the first encrypted message content generated by the identity private key of the source blockchain node for the first encrypted message content Digital signature, the content of the first message includes a neutrality verification message type identification; a sending unit is used to send the neutrality verification message to the target block chain node through the block chain relay communication network, so that the target block Chain node: verify the digital signature contained in the received interaction message according to the identity public key of the source blockchain node, and use the first symmetric key to encrypt the encrypted message contained in the interaction message
  • the content is decrypted, and when the signature verification is successful and the decrypted message content contains the neutrality verification message type identifier, a receipt confirmation message is returned to the source blockchain node through
  • a neutrality verification device for a blockchain relay communication network which is applied to a target blockchain node, including: a message receiving unit for receiving the information passed by the source blockchain node
  • the neutrality verification message sent by the block chain relay communication network includes the first encrypted message content generated by encrypting the first message content with the first symmetric key and the content generated by the source block chain
  • the identity private key of the node is the digital signature generated by the first encrypted message content
  • the first message content includes the neutrality verification message type identification
  • the message processing unit is used to publicize the identity according to the source block chain node key to verify the digital signature contained in the received interaction message, and use the first symmetric key to decrypt the encrypted message content contained in the interaction message, and after the signature verification is successful and the decrypted message
  • the content contains the neutrality verification message type identification
  • return a confirmation message to the source blockchain node through the blockchain relay communication network so that the source blockchain node can The sending moment of the verification
  • the data volume of the interactive message sent by the block chain relay communication network to the target block chain node is compared, and the conditions for determining the neutrality of the block chain relay communication network include the round-trip delay matching
  • the actual environment between the source block chain node and the target block chain node, and the amount of received data is consistent with the amount of sent data.
  • an electronic device including a processor and a memory for storing instructions executable by the processor.
  • the processor implements the method as described in the second aspect or the third aspect by running the executable instruction.
  • a computer-readable storage medium on which computer instructions are stored, and when the instructions are executed by a processor, the steps of the method described in the second aspect or the third aspect are implemented.
  • Fig. 1 is a flowchart of a neutrality verification method for a blockchain relay communication network provided by an exemplary embodiment.
  • Fig. 2 is a schematic diagram of a block chain node interacting through a block chain relay communication network provided by an exemplary embodiment.
  • Fig. 3 is a flow chart of a neutrality verification method based on the blockchain relay communication network on the source blockchain node side provided by an exemplary embodiment.
  • Fig. 4 is a flowchart of a neutrality verification method based on a blockchain relay communication network on the target blockchain node side provided by an exemplary embodiment.
  • Fig. 5 is an interactive flowchart of neutrality verification provided by an exemplary embodiment.
  • Fig. 6 is a schematic diagram of a neutral verification system for a blockchain relay communication network provided by an exemplary embodiment.
  • Fig. 7 is a schematic structural diagram of a device provided by an exemplary embodiment.
  • Fig. 8 is a block diagram of a neutral verification device based on a blockchain relay communication network on the source blockchain node side provided by an exemplary embodiment.
  • Fig. 9 is a block diagram of a neutral verification device based on a blockchain relay communication network on the target blockchain node side provided by an exemplary embodiment.
  • the steps of the corresponding methods are not necessarily performed in the order shown and described in this specification.
  • the method may include more or less steps than those described in this specification.
  • a single step described in this specification may be decomposed into multiple steps for description in other embodiments; multiple steps described in this specification may also be combined into a single step in other embodiments describe.
  • the blockchain relay communication network can be applied to various types of blockchain networks, including public chains, private chains, and alliance chains.
  • the blockchain relay communication network applied to the public chain mainly includes Falcon, Fast Bitcoin Relay Network (FBRN), Fast Internet Bitcoin Relay Engine (FIBRE), etc.
  • the blockchain relay communication network applied to the alliance chain mainly Including BloXRoute, Blockchain Transmission Network (BTN), etc. This specification does not limit the blockchain relay communication network used.
  • the blockchain relay communication network has several advantages as mentioned above, when the blockchain nodes use the blockchain relay communication network for message transmission, they need to determine that the blockchain relay communication network is neutral. No negative impact on message delivery. Therefore, this specification proposes a neutrality verification scheme of the blockchain relay communication network, which can effectively verify the neutrality of the blockchain relay communication network.
  • Fig. 1 is a flowchart of a neutrality verification method for a blockchain relay communication network provided by an exemplary embodiment.
  • the method may include: step 102, the source block chain node sends a neutrality verification message to the target block chain node through the block chain relay communication network, and the neutrality verification message includes The first encrypted message content generated by encrypting the first message content with the key and the digital signature generated by the identity private key of the source block chain node for the first encrypted message content, and the first message content Contains a neutral authentication message type identifier.
  • a corresponding node instance By running the blockchain platform code (ie chain code) on a physical device, a corresponding node instance can be formed on the physical device. If the other functions realized by the physical device are not considered, the physical device and the node instance may not be distinguished. At this time, the physical device or the node instance can be called a blockchain node. If other functions implemented by the physical device are taken into consideration, such as running other business instances besides the node instance, the physical device can be called a node device, and the node instance can be called a blockchain node. In short, the blockchain node can be a concept at the physical device level or at the logical level, which needs to be determined according to the actual situation.
  • the blockchain platform code ie chain code
  • the relay node in the blockchain relay communication network can be not only a physical device, but also a logical device.
  • the blockchain relay communication network can be a backbone communication network built on a cloud processing platform.
  • the relay node can be a virtual device created for the virtualization of cloud processing resources on the cloud processing platform. .
  • the functional logic related to neutrality verification can belong to a part of the above-mentioned block chain platform code, then the source block chain node and the target block chain node can be corresponding node instances, or can be The physical device where the node instance resides.
  • the functional logic related to neutrality verification can also belong to a business instance, and the business instance is on the same physical device as the node instance, so the source block chain node and target block chain node can be corresponding physical devices.
  • the functional logic related to neutrality verification in this specification can come from the same developer as other functional logic implemented by blockchain nodes, or they can come from different developers.
  • the functional logic related to neutrality verification can be implemented based on the form of SDK (Software Development Kit, software development kit), so as to facilitate the collaboration between different developers.
  • Both the source blockchain node and the target blockchain node are any blockchain nodes connected to the blockchain relay communication network.
  • each blockchain node that has been connected to the blockchain relay communication network can be used as a source blockchain node or as a target blockchain node.
  • the number of corresponding target blockchain nodes can be one or more, for example, the target blockchain node at this time can be all Part or all of the other blockchain nodes.
  • all blockchain nodes that have access to the blockchain relay communication network can participate in the neutrality verification process at the same time: each blockchain node acts as a source blockchain node, and at the same time as other The target blockchain node corresponding to the blockchain node, so that all blockchain nodes can achieve neutrality verification for the blockchain relay communication network they are connected to.
  • a digital signature needs to be generated through the identity private key of the source blockchain node, and the identity private key is usually maintained by the source blockchain node itself, so the source blockchain node is usually active Generate a neutral verification message.
  • the identity private key of the source blockchain node can be maintained by other trusted objects, then the trusted object can also generate a neutral verification message and provide it to the source blockchain node.
  • the source blockchain node and the target blockchain node can respectively maintain a list of blockchain nodes.
  • the blockchain node list maintained by a certain blockchain node is usually used to record the information of all blockchain nodes in the blockchain network where the blockchain node is located.
  • the blockchain node list can also maintain the information of blockchain nodes in other blockchain networks. Therefore, the source blockchain node and the target blockchain node may belong to the same blockchain network, or may belong to different blockchain networks respectively.
  • the information of the blockchain nodes maintained in the blockchain node list may include, for example, the node identifier of the blockchain node, the identity public key of the node on the chain, node IP and port information, etc.
  • the node identity on the chain is generated based on an asymmetric encryption algorithm, and the node identity on the chain of each blockchain node includes the public key of the node identity on the chain and the private key of the node identity on the chain.
  • the node identity on the chain belongs to the trust basis for realizing the interaction on the chain between the blockchain nodes
  • the node identity on the chain of the blockchain node can be used to realize the generation and verification of the digital signature in this specification, such as the source blockchain
  • the node generates the above-mentioned digital signature through its own on-chain node identity private key, and the target blockchain node verifies the digital signature through the on-chain node identity public key of the source blockchain node.
  • the source blockchain node and the target blockchain node can use other public-private key pairs, for example, the source blockchain node and the target blockchain node negotiate through the blockchain relay communication network
  • the dynamic identity public-private key pair, the dynamic identity public-private key pair can be specially used for neutrality verification to realize the generation and verification of digital signatures, which is not limited in this manual.
  • the neutrality verification message also includes the first encrypted message content.
  • the source blockchain node may encrypt the first message content with the first symmetric key to generate the above-mentioned first encrypted message content.
  • the trusted object can also generate the first encrypted message content and provide it to the source blockchain node.
  • the first symmetric key is maintained by the source block chain node and the target block chain node respectively, and this description does not limit the generation method of the first symmetric key.
  • the first symmetric key may be generated by a key management server (Key Management Server, KMS) and distributed to the source blockchain node and the target blockchain node.
  • KMS Key Management Server
  • the first symmetric key can be obtained by negotiating between the source block chain node and the target block chain node through the key agreement technology in the related art.
  • the key agreement technology here can include, for example, DH (Diffie-Hellman ) algorithm, etc.
  • the first symmetric key may be generated by any one of the source blockchain node and the target blockchain node, and then distributed to the other of the source blockchain node and the target blockchain node.
  • All blockchain nodes connected to the blockchain relay communication network can jointly maintain a unified first symmetric key; or, when there are groups of these blockchain nodes (for example, nodes in the same blockchain network belong to the same group, Another example is when dividing groups based on business requirements, etc.), the blockchain nodes in the same group can maintain a unified first symmetric key, and the first symmetric keys of different groups are different; or, each blockchain node uses The first symmetric keys can vary.
  • first symmetric key to implement the decryption operation can ensure the smooth completion of the neutral verification scheme in this specification.
  • the source block chain node sends a key distribution message to the target block chain node through the block chain relay communication network.
  • the key distribution message contains the key ciphertext encrypted by the identity public key of the target blockchain node on the first symmetric key, and the digital signature generated by the identity private key of the source blockchain node for the key ciphertext ;
  • the target blockchain node verifies the digital signature in the key distribution message according to the identity public key of the source blockchain node, and uses its own identity private key to verify the key
  • the ciphertext is decrypted, and the symmetric key obtained through decryption is determined as the first symmetric key if the signature verification is successful.
  • the key distribution message includes the above-mentioned key ciphertext and a digital signature for the key ciphertext.
  • the key distribution message may be generated by the source blockchain node, or provided to the source blockchain node after being generated by other trusted objects, which is not limited in this description. If the key distribution message is generated by another trusted object, the source blockchain node can entrust its own identity private key to the trusted object, so that the trusted object can generate corresponding digital signatures for the key ciphertext . Among them, the source blockchain node obtains the identity public key of the target blockchain node, and uses the identity public key to encrypt the first symmetric key to be distributed based on an asymmetric encryption algorithm, thereby generating the corresponding key encryption key. arts.
  • the key ciphertext can only be decrypted by the identity private key maintained by the target blockchain node, it can be safely transmitted through the blockchain relay communication network without worrying about the first symmetric key being lost in the zone. Exposure in the block chain relay communication network. Further, a digital signature can be generated for the above-mentioned key ciphertext through the identity private key of the source blockchain node, and the target blockchain node can verify the digital signature according to the identity public key of the source blockchain node, thereby determining Whether the key ciphertext is missing or replaced during the transmission process to prevent security problems caused by man-in-the-middle attacks.
  • the identity public-private key pair involved can be the blockchain node’s on-chain node identity public-private key pair, or It may be a negotiated public-private key pair, such as a dynamic identity, which is not limited in this specification.
  • the above-mentioned first message content includes a neutral verification message type identifier, which is used to indicate that the interaction message in which it is located is a neutral verification message, rather than other interaction messages sent by the source blockchain node. Therefore, in the process of implementing neutral verification, the source blockchain node can still send other interactive messages to the target blockchain node normally, such as consensus messages, block synchronization messages and other business messages, without interrupting the blockchain business. Thereby reducing the impact of neutral verification on the blockchain business. In addition to the neutrality verification message type identification, whether the content of the first message contains other information and what kind of information it contains will not affect the implementation of the neutrality verification scheme in this specification.
  • the source blockchain node sends a neutral verification message through the blockchain relay communication network, it is no different from the process of message transmission through the blockchain relay communication network in related technologies.
  • the source blockchain node is Node A
  • the target blockchain node is Node B
  • Node A and the relay node in the blockchain relay communication network a is connected
  • Node B is connected to relay node b in the blockchain relay communication network.
  • Node A can send the neutrality verification message to relay node a, after relay node a routes the neutrality verification message to relay node b, relay node b further sends the neutrality verification message to Node B .
  • the blockchain relay communication network can broadcast the message to be transmitted, so that all blockchain nodes connected to the blockchain relay communication network can receive the message.
  • the relay node a broadcasts the neutrality verification message in the blockchain relay communication network, and further the neutrality verification message received by each relay node Forward to the blockchain node connected to itself, for example, the relay node c will receive the neutrality verification message and forward it to the blockchain node Node C.
  • the relay node c will receive the neutrality verification message and forward it to the blockchain node Node C.
  • a certain blockchain node does not participate in the neutral verification, even if the blockchain node receives the neutral verification message, it does not need to do anything, for example, it can be discarded directly.
  • the neutrality verification message may include receiver node indication information, so that the blockchain relay communication network sends the neutrality verification message to the blockchain node corresponding to the receiver node indication information. At this time, the forwarding of the neutrality verification message by the blockchain relay communication network will be targeted, and will not be sent to relay nodes that have nothing to do with the target blockchain node.
  • the receiver node indication information may include the node identification of the target blockchain node. If there are multiple target blockchain nodes: In one case, the receiver node indication information in each neutrality verification message can be only the node identification of one target blockchain node.
  • each target block needs to be The chain nodes send a neutral verification message respectively; in another case, the receiver node indication information in a neutral verification message can include node identities of multiple target blockchain nodes, and only a neutral verification message needs to be sent at this time information.
  • the receiver node indication information may include the set identification of the block chain node set to which the target block chain node belongs, especially when multiple target block chain nodes belong to the same block chain node set, the set identification can reduce The recipient node indicates the length of the message.
  • the blockchain node set here can be formed by pre-registering with the blockchain relay communication network, and the blockchain nodes in the same blockchain node set can be all or part of the blockchain nodes in the same blockchain network. It can also include blockchain nodes from multiple blockchain networks at the same time, which can be registered according to business requirements, and the blockchain nodes contained in the blockchain node set can be added or deleted according to requirements.
  • Each relay node in the blockchain relay communication network can maintain: the connection relationship between each relay node, and the connection relationship between each relay node and the blockchain node. Based on the above information maintained, the relay node can generate a corresponding routing policy for message transmission. For example, when relay node a reads the receiver node indication information in the neutrality verification message, it determines that the target blockchain node is Node B, and the relay node a will determine itself and the relay node connected to the Node B b, and forward the neutrality verification message to relay node b through the forwarding path.
  • relay node a-relay node b If there is a direct link between relay node a and relay node b, the above forwarding path is "relay node a-relay node b", that is, relay node a can directly send the neutrality verification message to Relay node b, but not to relay node c.
  • the above forwarding path can be "relay node a-relay node c-relay node b", then relay node a can forward the neutrality verification message to relay node c; similar to relay node a, after relay node c determines that the target blockchain node is Node B, it will also determine The forwarding path between itself and the relay node b connected to the Node B, and forward the neutrality verification message to the relay node b through the forwarding path, for example, the determined forwarding path is "relay node c-zhong The relay node b", that is, the relay node c can directly send the neutrality verification message to the relay node b.
  • each relay node can also maintain the information of each block chain node set, including set identification, contained block chain nodes, and so on. For example, when relay node a reads the receiver node indication information in the neutrality verification message, it determines that the receiver node indication information is the set identifier SID1, and determines that the blockchain nodes contained in SID1 are Node B and Node C , then relay node a determines Node B and Node C as target blockchain nodes respectively, and routes the neutrality verification message to relay node b connected to Node B and node C connected to The relay node c will not be described in detail here.
  • the transmission process of the key distribution message can refer to the above implementation
  • the transmission process of the neutrality verification message in the example will not be repeated here.
  • the key distribution message should contain data sets corresponding to each target blockchain node: each data set includes The key ciphertext and corresponding digital signature generated by the identity public key of the corresponding target blockchain node.
  • the key distribution message includes the data set M1 corresponding to Node B and the data set M2 corresponding to Node C, where: M1 includes the identity of Node B
  • M2 includes the key ciphertext enc_key_C and the corresponding digital signature enc_key_C_sign generated by the identity public key of Node C.
  • each target blockchain node needs to find its corresponding data set in order to realize the decryption and signature verification mentioned above.
  • Each data set may contain the node identification of the corresponding target blockchain node, so that each target blockchain node can accurately find its corresponding data set; or, the data set may not contain the node identification of the corresponding target blockchain node , each target blockchain node needs to try each data set separately until it finds its own corresponding data set.
  • the blockchain nodes that have access to the blockchain relay communication network can regularly implement the neutrality verification scheme of this specification, so as to perform neutrality verification for the blockchain relay communication network.
  • each blockchain node can initiate neutrality verification for the blockchain relay network at any time, for example, a certain blockchain node has just connected to the blockchain relay communication network, or a certain When the blockchain nodes have doubts about the neutrality of the blockchain relay communication network during operation, they can initiate the above-mentioned neutrality verification.
  • the blockchain node can switch from the normal mode to the neutral verification mode, so as to operate as the source blockchain node in this specification.
  • the source blockchain node can send a neutral verification request to the target blockchain node through the blockchain relay communication network, and realize other functions related to the source blockchain node in this manual.
  • the target blockchain node switches from the normal mode to the neutral verification mode according to the neutral verification request received, so as to respond to the neutral verification message sent by the source blockchain node.
  • the blockchain node when running in the neutral verification mode, can not only continue to complete the message interaction and processing functions in the normal mode, such as the sending and receiving and processing of consensus messages and block synchronization messages, etc., but also realize this Neutrality verification scheme in specification.
  • blockchain nodes can choose whether to participate in neutral verification according to the actual situation, for example, they can avoid participating in neutral verification to reduce the impact on their own business. Impact.
  • the selection of the above operation mode may be unnecessary, for example, all blockchain nodes can run in the neutral verification mode by default, so as to realize the neutral verification of the blockchain relay communication network at any time.
  • Step 104 the target blockchain node verifies the digital signature contained in the received interaction message according to the identity public key of the source blockchain node, and uses the first symmetric key to authenticate the interaction message.
  • the encrypted message content contained in the message is decrypted, and when the signature verification is successful and the decrypted message content contains the neutrality verification message type identifier, it sends the message to the source area through the blockchain relay communication network.
  • the block chain node returns a receipt confirmation message; and, the target block chain node performs data volume statistics on the interaction messages received within the preset time period and successfully verified by the identity public key of the source block chain node, Get the amount of received data.
  • the target blockchain node After receiving the neutrality verification message, the target blockchain node can respectively obtain the encrypted message content and digital signature contained in the neutrality verification message. As mentioned above, the target blockchain node can obtain the on-chain node identity public key of the source blockchain node from the blockchain node list maintained by itself according to the node identification of the source blockchain node, or the source blockchain node Other types of identity public keys such as the dynamic identity public key of the chain node are used to verify the above-mentioned digital signature. Since it is defined in the neutrality verification message that the digital signature is generated for the encrypted message content, the target blockchain node will complete the verification of the digital signature according to the encrypted message content.
  • the verification If the verification is successful, it indicates that the neutral verification message does come from the source blockchain node, and there is no data loss or man-in-the-middle attack during transmission. If the verification fails, it indicates that at least one of the encrypted message content and the digital signature is abnormal, and the target blockchain node can discard or return a warning message.
  • the neutrality verification message may contain sender node identification information, and the sender node identification information is used to record the node identification of the block chain node as the sender. Therefore, in the neutrality verification message sent by the source blockchain node, the value of the sender node identification information is the node identification of the source blockchain node.
  • the target blockchain node can extract the node identifier of the source blockchain node from the sender node identifier information, and determine the identity public key corresponding to the source blockchain node according to the extracted node identifier, and then according to the determined identity public key The key is used to verify the digital signature in the neutral verification message.
  • the sender node identification information in the neutrality verification message is only a way to indicate the identity of the sender node, and the target blockchain node can also obtain the identity of the sender node through other means, which is not limited in this specification.
  • the blockchain relay communication network After the blockchain relay communication network obtains the neutrality verification message, it can encapsulate the neutrality verification message into a relay message, and transmit the relay message in the blockchain relay communication network.
  • the node identification of the active blockchain node can be encapsulated in the relay message, and the node identification of the source blockchain node can be unpacked from the relay message by the blockchain relay communication network and then notified to the target blockchain node.
  • relay node a after receiving the neutrality verification message sent by Node A, relay node a encapsulates the neutrality verification message into a relay message. Add the node identification of Node A in the relay message.
  • the relay node b after receiving the relay message, the relay node b can obtain the node ID of Node A by decapsulating it, and send the node ID together with the neutrality verification message to Node B, so that Node B knows the neutrality
  • the verification message is from Node A.
  • the target blockchain node can decrypt the encrypted message content through the first symmetric key maintained by itself. As mentioned above, if all blockchain nodes connected to the blockchain relay communication network maintain a unified first symmetric key, then the target blockchain node can directly use the first symmetric key to encrypt the encrypted message The content is decrypted. If the first symmetric keys maintained by all blockchain nodes connected to the blockchain relay communication network are not unified, then the target blockchain node needs to determine the node identity of the source blockchain node through the aforementioned method, and according to This determines the first symmetric key corresponding to the source blockchain node and decrypts the above-mentioned encrypted message content.
  • the target blockchain node may maintain the correspondence between the node identifier and the first symmetric key in advance, so as to determine the required first symmetric key according to the node identifier of the source blockchain node.
  • the target blockchain node can pre-maintain the corresponding relationship between the set ID and the first symmetric key, so as to determine the set ID to which the source blockchain node belongs according to the node ID of the source blockchain node, and then determine according to the set ID Find the first symmetric key to be used.
  • the target blockchain node can always accurately obtain the required first symmetric key, so as to realize the decryption operation of the above-mentioned encrypted message content.
  • the source blockchain node sends other types of interaction messages at the same time as the neutrality verification message. If other types of interaction messages are also sent encrypted, the target blockchain node will not be able to directly determine whether the interaction message is a neutral verification message or other types of interaction messages after receiving the interaction message. Therefore, the target blockchain node needs to use the first symmetric key to decrypt the encrypted message content in the received interaction message, and when the decrypted message content contains the neutral verification message type identifier, determine The received interaction message is the neutrality verification message mentioned above. If the decrypted message content does not contain the neutral verification message type identifier, the target blockchain node confirms that the received interaction message is not a neutral verification message. Of course, for an interaction message that is not a neutral verification message, the target blockchain node can respond to the interaction message according to related technologies, which will not be repeated here.
  • the target blockchain node can consider that it has received the neutral verification message from the source blockchain node, so it sends The source blockchain node returns a receipt confirmation message.
  • the transmission process of the receipt confirmation message you can refer to the transmission process of the neutrality verification message above, but the exchange occurs between the sender and the receiver, but it does not affect the transmission principle, so it will not be repeated here.
  • a plain text message may be used for the receipt confirmation message.
  • the receipt confirmation message may include the second encrypted message content generated by encrypting the second message content with the second symmetric key and the digital signature generated for the second encrypted message content by the identity private key of the target blockchain node , and the content of the second message includes the message type identifier of the receipt confirmation message.
  • the source blockchain node receives the interaction message from the target blockchain node, it verifies the digital signature contained in the received interaction message according to the identity public key of the target blockchain node. If passed, it is confirmed that the interaction message comes from the target blockchain node.
  • the target blockchain node also sends business messages or other types of interaction messages such as those mentioned above at the same time, and these interaction messages also use private transmission
  • the source blockchain node needs to use the second symmetric key pair to interact
  • the encrypted message content contained in the message is decrypted. If the decrypted message content contains the above-mentioned reception confirmation message type identifier, it can be confirmed that the received interactive message is the above-mentioned reception confirmation message. It can be seen that in the scenario of private transmission, the source blockchain node can confirm that it has received the receipt confirmation message sent by the target blockchain node when the signature verification is successful and the decrypted message content contains the type identifier of the confirmation message.
  • the receiving moment of the interaction message can be confirmed as the receiving moment of the confirmation message, which is used to calculate the round-trip delay (Round-Trip Time, RTT) of the blockchain relay communication network in the following.
  • RTT Round-Trip Time
  • the target blockchain node can immediately return the receipt confirmation message after confirming that it has received the neutral verification message from the source blockchain node, that is, the target blockchain node will not actively cause unnecessary waiting Or delay, in order to return the receipt confirmation message as soon as possible.
  • the second symmetric key may be the same as the first symmetric key.
  • the second symmetric key can also be different from the first symmetric key, but the generation method of the second symmetric key can refer to the generation method of the first symmetric key mentioned above, for example, the source block chain node and the target Blockchain node negotiation, distribution by the key management server, distribution from the target blockchain node to the source blockchain node, etc., will not be repeated here, and this specification does not limit it.
  • the target blockchain node may receive interaction messages sent by multiple blockchain nodes at the same time. By verifying the digital signature contained in the interactive message, the target block chain node can distinguish and confirm the sender of the interactive message, and conduct an interactive message received within the preset time period and the sender is the source block chain node. Statistics of the data volume to obtain the received data volume. If the neutrality verification is periodic, then the statistics of the amount of data received by the target blockchain node can also be periodic, and the above-mentioned preset time period can be each statistical period. If the neutral verification is aperiodic, such as initiated by the trigger of the source blockchain node, then the target blockchain node can confirm that the neutral verification has been initiated or receive the first neutrality verification from the source blockchain node.
  • the counting is started when the verification message is received, and the preset time period is defined by the time when the counting is started (that is, the start time) and the preset duration.
  • the above-mentioned "first article” refers to the first article in the current neutrality verification process, not just the first article in history.
  • the interaction message sent by the source blockchain node to the target blockchain node may contain other types of messages in addition to the neutrality verification message.
  • the target blockchain node can either conduct statistics on neutral verification messages or all types of interactive messages, which is not limited in this manual. If only neutrality verification messages are counted, the source block chain node can appropriately increase the number of neutrality verification messages sent, so that the amount of received data counted for the neutrality verification messages has statistical significance.
  • the source blockchain node does not need to send a lot of neutral verification messages, so that on the one hand, other types of interaction messages can provide enough data to make the statistics of received data On the other hand, it can avoid too many neutral verification messages from causing great impact on other types of interaction messages, that is, reduce the impact of neutral verification on normal business.
  • Step 106 the source block chain node calculates the round-trip delay of the block chain relay communication network according to the sending time of the neutrality verification message and the receiving time of the receiving confirmation message, and transfers the received data to The amount is compared with the data amount of the interaction message sent by itself to the target blockchain node through the blockchain relay communication network within the preset time period.
  • the conditions for determining the neutrality of the blockchain relay communication network include: the round-trip delay matches the actual environment between the source blockchain node and the target blockchain node, and the The amount of received data is the same as the amount of sent data.
  • the above-mentioned multiple neutrality verification messages can be periodically sent by the source blockchain node within the aforementioned preset time period, so that the transmission of multiple neutrality verification messages can be allocated at different times within the preset time period, It can not only avoid the adverse impact of centralized transmission on normal business, but also know the delay of the blockchain relay communication network at different times, which is conducive to improving the accuracy of the calculated round-trip delay.
  • the source blockchain node can wait for the receipt returned by the target blockchain node after each sending a neutrality verification message. Confirm the message, and then send the next neutral verification message, so as to avoid confusing the correspondence between the neutral verification message and the receipt confirmation message, such as the sending time of the previous neutral verification message and the receiving time of the next reception confirmation message Jointly calculate the round-trip delay, etc., to prevent miscalculation of the round-trip delay.
  • the message content of the neutrality verification message may contain a message number
  • the message content of the reception confirmation message may also contain the same message number , so that the source blockchain node can accurately identify the correspondence between the neutral verification message and the receipt confirmation message according to the message number, so that the source blockchain node can send the neutral verification message at any time without waiting for the receipt confirmation message.
  • the normal delay in message transmission between the two can be known. Therefore, when the round-trip delay determined by the source blockchain node matches the normal delay, it indicates that the blockchain relay communication network does not intentionally cause a delay to the transmitted message, which satisfies the rationality of the delay. At the same time, when the amount of transmitted data counted by the source blockchain node within the preset time period is consistent with the amount of received data counted by the target blockchain node within the preset time period, it indicates that the blockchain relay communication network is No data is intentionally discarded during transmission, ensuring data integrity.
  • this manual verifies the blockchain relay communication network from multiple dimensions such as data privacy, data correctness, data integrity, and delay rationality, so as to fully and reasonably determine the blockchain Neutrality of the relay communication network.
  • Fig. 3 is a flow chart of a neutrality verification method based on the blockchain relay communication network on the source blockchain node side provided by an exemplary embodiment. As shown in Fig. 3, the method may include the following steps.
  • Step 302 obtain a neutral verification message, the neutral verification message includes the first encrypted message content generated by encrypting the first message content with the first symmetric key and the identity private key of the source blockchain node A digital signature generated for the first encrypted message content, where the first message content includes a neutral verification message type identifier.
  • Step 304 send the neutrality verification message to the target blockchain node through the blockchain relay communication network, so that the target blockchain node: according to the identity public key pair of the source blockchain node received verifying the digital signature contained in the interaction message, and decrypting the encrypted message content contained in the interaction message with the first symmetric key, and including the In the case of neutrality verification message type identification, return a receipt confirmation message to the source blockchain node through the blockchain relay communication network; The interactive messages of the chain node's identity public key signature verification are successful, and the data volume is counted to obtain the received data volume.
  • Step 306 Calculate the round-trip delay of the blockchain relay communication network according to the sending time of the neutrality verification message and the receiving time of the receipt confirmation message, and compare the amount of received data with itself in the predetermined It is assumed that the data volume of the interaction message sent to the target blockchain node through the blockchain relay communication network within a time period is compared.
  • the conditions for determining the neutrality of the blockchain relay communication network include: the round-trip delay matches the actual environment between the source blockchain node and the target blockchain node, and the The amount of received data is the same as the amount of sent data.
  • the method further includes: obtaining a key distribution message, the key distribution message includes the encryption key of the first symmetric key encrypted by the identity public key of the target blockchain node.
  • key ciphertext, and the digital signature generated for the key ciphertext by the identity private key of the source block chain node send the target block chain node through the block chain relay communication network A key distribution message, so that the target blockchain node: after receiving the key distribution message, verifies the digital signature in the key distribution message according to the identity public key of the source blockchain node , and decrypt the key ciphertext with its own identity private key, and determine the decrypted symmetric key as the first symmetric key if the signature verification is successful.
  • the identity public-private key pair of the source block chain node and the target block chain node includes any of the following: the source block chain node, the on-chain node of the target block chain node An identity public-private key pair; a dynamic identity public-private key pair negotiated between the source blockchain node and the target blockchain node through the blockchain relay communication network.
  • the receipt confirmation message includes the second encrypted message content generated by encrypting the second message content with the second symmetric key and the identity private key of the target blockchain node for the second A digital signature generated from encrypted message content, where the second message content includes a receipt confirmation message type identifier.
  • the method further includes: the source blockchain node verifies the digital signature contained in the received interaction message according to the identity public key of the target blockchain node, and uses the second symmetric key to The encrypted message content contained in the interaction message is decrypted, and if the signature verification is successful and the decrypted message content contains the type identifier of the reception confirmation message, confirm the reception time of the interaction message as the receipt The moment of receipt of the acknowledgment message.
  • sending a neutral verification message to the target blockchain node through the blockchain relay communication network includes: sending a plurality of messages to the target blockchain node through the blockchain relay communication network Neutrality verification message; the calculation of the round-trip delay of the block chain relay communication network according to the sending moment of the neutrality verification message and the receiving moment of the reception confirmation message includes: calculating the plurality of neutrality The average round-trip delay of the verification message is used as the round-trip delay of the blockchain relay communication network.
  • the multiple neutrality verification messages are periodically sent by the source blockchain node within the preset time period.
  • the neutrality verification message includes receiver node indication information; the receiver node indication information includes the node identification of the target blockchain node, or the block to which the target blockchain node belongs The set ID of the set of chain nodes.
  • the method further includes: sending a neutrality verification request to the target blockchain node through the blockchain relay communication network, so that the target blockchain node
  • the neutrality verification request is switched from the normal mode to the neutrality verification mode, so as to respond to the neutrality verification message.
  • Fig. 4 is a flowchart of a neutrality verification method based on a blockchain relay communication network on the target blockchain node side provided by an exemplary embodiment.
  • the method may include: step 402, receiving a neutrality verification message sent by the source block chain node through the block chain relay communication network, the neutrality verification message including the first symmetric key pair A first encrypted message content generated by encrypting a message content and a digital signature generated for the first encrypted message content by the identity private key of the source block chain node, the first message content includes a neutral verification Message type identification; step 404, verify the digital signature contained in the received interactive message according to the identity public key of the source blockchain node, and use the first symmetric key to verify the digital signature contained in the interactive message
  • the encrypted message content is decrypted, and when the signature verification is successful and the decrypted message content contains the neutrality verification message type identifier, the source blockchain node is sent to the source blockchain node through the blockchain relay communication network.
  • step 406 Perform data volume statistics on the interactive messages received within the preset time period and successfully verified by the identity public key of the source blockchain node to obtain the received data volume, so that the source blockchain node will receive the received The data volume is compared with the data volume of the interaction message sent by itself to the target blockchain node through the blockchain relay communication network within the preset time period.
  • the conditions for determining the neutrality of the blockchain relay communication network include: the round-trip delay matches the actual environment between the source blockchain node and the target blockchain node, and the The amount of received data is the same as the amount of sent data.
  • the method further includes: receiving a key distribution message sent by the source block chain node through the block chain relay communication network, the key distribution message includes The identity public key of the chain node encrypts the key ciphertext of the first symmetric key, and the digital signature generated by the identity private key of the source block chain node for the key ciphertext; according to the The identity public key of the source blockchain node verifies the digital signature in the key distribution message, and uses its own identity private key to decrypt the key ciphertext, and if the signature verification is successful Determine the symmetric key obtained through decryption as the first symmetric key.
  • the identity public-private key pair of the source block chain node and the target block chain node includes any of the following: the source block chain node, the on-chain node of the target block chain node An identity public-private key pair; a dynamic identity public-private key pair negotiated between the source blockchain node and the target blockchain node through the blockchain relay communication network.
  • the receipt confirmation message includes the second encrypted message content generated by encrypting the second message content with the second symmetric key and the identity private key of the target blockchain node for the second
  • the digital signature generated by the encrypted message content, the second message content includes the type identification of the receiving confirmation message;
  • the receiving confirmation message is used to make the source block chain node: according to the identity public key of the target block chain node Verifying the digital signature contained in the received interaction message, and using the second symmetric key to decrypt the encrypted message content contained in the interaction message, and verifying the signature successfully and decrypting the message content If the type identifier of the reception confirmation message is included in , confirm the reception time of the interactive message as the reception time of the reception confirmation message.
  • receiving the neutrality verification message sent by the source blockchain node through the blockchain relay communication network includes: receiving the neutrality verification message sent by the source blockchain node through the blockchain relay communication network A plurality of neutral verification messages; the source block chain node calculates the round-trip delay of the block chain relay communication network according to the sending moment of the neutrality verification message and the receiving moment of the receipt confirmation message, including: The source blockchain node calculates the average round-trip delay of the multiple neutrality verification messages as the round-trip delay of the blockchain relay communication network.
  • the multiple neutrality verification messages are periodically sent by the source blockchain node within the preset time period.
  • the neutrality verification message includes receiver node indication information; the receiver node indication information includes the node identification of the target blockchain node, or the block to which the target blockchain node belongs The set ID of the set of chain nodes.
  • the method also includes: receiving the neutrality verification request sent by the source block chain node through the block chain relay communication network; switching from the normal mode according to the received neutrality verification request to neutral verification mode to respond to the neutral verification message.
  • FIG. 5 is an interactive flowchart of neutrality verification provided by an exemplary embodiment.
  • Node A wants to verify the neutrality of the blockchain relay communication network it is connected to
  • Node B is any other blockchain node that has connected to the blockchain relay communication network.
  • the NodeB cooperates with the NodeA to complete the verification process.
  • the interaction between NodeA and NodeB is realized through the blockchain relay communication network, then the interaction process between the blockchain nodes Node A and Node B may include the following steps.
  • Step 501 Node A distributes private_key to NodeB.
  • Node A can generate a symmetric key as the above-mentioned private_key through any key generation algorithm in related technologies.
  • the private_key can be temporarily generated when Node A wants to distribute the key, or it can be selected by Node A from the previously generated key set, which is not limited in this specification.
  • Node A can complete key distribution by sending a key distribution message to NodeB, and the key distribution message can be, for example, the following PrivateKeyMsg.
  • the key distribution message can be, for example, the following PrivateKeyMsg.
  • Node A determines to distribute the above private_key to Node B, it can obtain Node B's on-chain node identity public key Pub_key_B from the blockchain node list maintained by itself, and asymmetrically encrypt the private_key through Pub_key_B to obtain the corresponding Key ciphertext enc_private_key.
  • Node A can sign enc_private_key with its own on-chain node identity private key Pri_key_A to generate a corresponding digital signature enc_private_key_sign.
  • Node A can also determine the corresponding version number private_key_ver for the private_key distributed this time, so as to distinguish it from other keys distributed by Node A. It should be pointed out that in addition to encryption, decryption and signature verification through Node A and Node B's on-chain node identity information, it can also be implemented through other public-private key pairs, such as the dynamic public-private key pair negotiated between Node A and Node B. key pair, which is not limited in this manual.
  • Node A can generate a neutral verification message PrivateKeyMsg, which can contain the following fields:
  • the node_id_from field is used to fill in the node ID of Node A
  • the node_id_to field is used to fill in the node ID of Node B.
  • the encrypted_symetric_private_key field is used to fill in the key ciphertext, that is, the above enc_private_key.
  • the enc_private_key_sign field is used to fill in the digital signature for the key ciphertext.
  • the private_key_ver field is used to fill in the version number of the key private_key.
  • Node A sends PrivateKeyMsg to Node B through the blockchain relay communication network.
  • Node A first sends the PrivateKeyMsg to the relay node a it is connected to, and the relay node a directly or indirectly sends the PrivateKeyMsg to the relay node b based on the routing policy, and then the relay node b sends the PrivateKeyMsg to Node B. Since enc_private_key is always in the ciphertext state, and only Node B maintains the decryption key (Node B's on-chain node identity private key Pri_key_B), the relay node a, relay node b and the blockchain relay communication network No other relay node can know the private_key in plaintext.
  • Node B verifies enc_private_key_sign in PrivateKeyMsg and decrypts enc_private_key. For example, after receiving the PrivateKeyMsg, Node B obtains the on-chain node identity public key corresponding to the node ID from the blockchain node list maintained by itself according to the node ID extracted from the node_id_from field, so as to verify the signature of enc_private_key_sign .
  • Node B will extract the node ID of Node A from the node_id_from field, and then obtain the public key Pub_key_A of the node identity on the chain, and then verify the enc_private_key_sign according to the Pub_key_A and enc_private_key in PrivateKeyMsg.
  • Node B can decrypt enc_private_key according to its own on-chain node identity private key Pri_key_B during the signature verification process. Node B can also perform the decryption operation only after the signature verification is successful, which is not limited in this specification. Of course, even if signature verification and decryption are implemented in parallel, Node B will only recognize the private_key obtained by decryption when the signature verification is successful.
  • Node B When Node B successfully verifies enc_private_key_sign, it determines that the private_key obtained through decryption is the symmetric key distributed by Node A, and associates the private_key with Node A. For example, Node B can associate and store the private_key, private_key_ver and the node ID of Node A. And, Node B returns a PrivateKeyRespMsg message to Node A through the blockchain relay communication network, indicating to Node A that it has successfully obtained the distributed key private_key. Among them, PrivateKeyRespMsg can contain the following fields:
  • the node_id_from field is used to fill in the node ID of Node B
  • the node_id_to field is used to fill in the node ID of Node A.
  • node_id_from_sign is a digital signature generated by Node B through its own on-chain node identity private key Pri_key_B to sign the content of the node_id_from field (that is, the node ID of Node B).
  • the private_key_ver field is the version number information of the private_key recorded by Node B.
  • Node B first sends PrivateKeyRespMsg to relay node b to which it is connected, and relay node b directly or indirectly sends PrivateKeyRespMsg to relay node a based on the routing policy, and then relay node a sends PrivateKeyRespMsg to Node A.
  • Node A After receiving the PrivateKeyRespMsg, Node A obtains the on-chain node identity public key corresponding to the node ID from the blockchain node list maintained by itself according to the node ID extracted from the node_id_from field, and uses it to verify the node_id_from_sign signature. If there is no abnormality in the transmission process of PrivateKeyRespMsg, Node A will extract the node ID of Node B from the node_id_from field, and then obtain the public key Pub_key_B of the node identity on the chain, and then verify the node_id_from_sign according to the Pub_key_B and node_id_from in PrivateKeyRespMsg. In the case of successful signature verification, Node A can determine that the PrivateKeyRespMsg comes from Node B, thereby confirming that the private_key has been successfully distributed to Node B.
  • Step 502a Node A records the amount of data sent and the time of sending.
  • Step 502b Node A sends a neutrality verification message to Node B.
  • step 502a the sequence between step 502a and step 502b can be reversed without affecting the implementation of the solution.
  • Node A and Node B can switch to the neutral verification mode, so that Node A and Node B can perform operations related to neutral verification.
  • Node A generates a neutral verification message NeutralVerifyMsg, which may contain the following fields, for example:
  • the node_id_from field is used to fill in the node ID of Node A
  • the node_id_to field is used to fill in the node ID of Node B.
  • the encrypted_raw_data field is used to fill in the encrypted message content enc_raw_data
  • encrypted_raw_data_sign is the signature for the encrypted message content enc_raw_data.
  • Node A When generating the above-mentioned NeutralVerifyMsg, Node A first obtains the plaintext message content raw_data, and the message content raw_data contains at least the neutrality verification message type identifier. Then, Node A can encrypt the message content raw_data through the aforementioned symmetric key private_key to generate the above-mentioned encrypted message content enc_raw_data. Further, Node A uses its own identity private key to sign the encrypted message content enc_raw_data to generate a corresponding digital signature encrypted_raw_data_sign.
  • the sending time recorded by Node A is the time when Node A sends NeutralVerifyMsg.
  • the amount of sent data recorded by Node A can be the sum of the amount of data sent by Node A to Node B within a preset period of time.
  • the interactive messages here include the above-mentioned NeutralVerifyMsg, consensus messages, and block synchronization messages and other types of business messages, it can ensure that the amount of data sent is large enough to be comparable.
  • Node A's record of the amount of data sent is persistent. Therefore, the action of Node A to record the amount of sent data is not only to record the data amount of NeutralVerifyMsg, but to accumulate the data amount of all interactive messages within the above preset time period until the preset time period is finally obtained The sum of the data volumes of all interaction messages in the message.
  • Step 503 Node B performs signature verification and decryption on the received interaction message.
  • Node B When Node B receives an interaction message from the blockchain relay communication network, it cannot directly determine whether the interaction message is NeutralVerifyMsg because the message content of the interaction message is in an encrypted state. At the same time, although the node_id_from field contains Node A's node ID, Node B needs to verify this.
  • Node B first obtains the identity public key of Node A, and uses the identity public key to verify the digital signature encrypted_raw_data_sign contained in the interaction message. If the verification is successful, Node B can confirm that the interaction message comes from Node A, and the content of the interaction message is complete and correct. Furthermore, Node B decrypts the encrypted message content enc_raw_data according to the aforementioned symmetric key private_key: if the decryption is successful, and the decrypted message content contains the aforementioned neutral verification message type identifier, then Node B confirms that the interactive message is neutral authentication message. Combined with the results of signature verification and decryption, Node B can confirm whether the received interaction message is the NeutralVerifyMsg sent by Node A.
  • Step 504a Node B sends a reception confirmation message to Node A.
  • Step 504b Node B counts the amount of received data.
  • step 504a the sequence between step 504a and step 504b can be reversed without affecting the implementation of the solution.
  • Node B After Node B determines to receive the NeutralVerifyMsg from Node A, it can immediately return the receipt confirmation message NeutralVerifyRespMsg to Node A, for example, it can contain the following fields:
  • the node_id_from field is used to fill in the node ID of Node B
  • the node_id_to field is used to fill in the node ID of Node A.
  • the encrypted_raw_data_Resp field is used to fill in the encrypted message content enc_raw_data_Resp
  • encrypted_raw_data_Resp_sign is the signature for the encrypted message content enc_raw_data_Resp.
  • the Node B When generating the above-mentioned NeutralVerifyRespMsg, the Node B first obtains the plaintext message content raw_data_Resp, and the message content raw_data_Resp includes at least the type identifier of the confirmation message. Then, the Node B can encrypt the message content raw_data_Resp with the aforementioned symmetric key private_key to generate the aforementioned encrypted message content enc_raw_data_Resp. Further, Node B signs the encrypted message content enc_raw_data_Resp with its own identity private key to generate a corresponding digital signature encrypted_raw_data_Resp_sign.
  • Node A When Node A receives an interaction message from the blockchain relay communication network, since the content of the interaction message is encrypted, it cannot directly determine whether the interaction message is NeutralVerifyRespMsg. At the same time, although the node_id_from field contains the node ID of Node B, Node A needs to verify this. Therefore, Node A first obtains the identity public key of Node B, and uses the identity public key to verify the digital signature encrypted_raw_data_Resp_sign contained in the interaction message. If the verification is successful, Node A can confirm that the interaction message comes from Node B, and the content of the interaction message is complete and correct.
  • Node A decrypts the encrypted message content enc_raw_data_Resp according to the aforementioned symmetric key private_key: if the decryption is successful, and the decrypted message content contains the aforementioned reception confirmation message type identifier, Node A confirms that the interactive message is a reception confirmation information. Combined with the results of signature verification and decryption, Node A can confirm whether the received interaction message is the NeutralVerifyRespMsg sent by Node B.
  • Node A After confirming the receipt of the NeutralVerifyRespMsg from Node B, Node A confirms the time to receive the NeutralVerifyRespMsg. In fact, Node A can record the corresponding receiving time when receiving each interactive message, and then confirm the corresponding receiving time of the NeutralVerifyRespMsg when an interactive message is confirmed to be NeutralVerifyRespMsg through signature verification and decryption operations.
  • the amount of sent data recorded by Node B can be the sum of the amount of data received by Node B from all interaction messages from Node A within the preset time period.
  • the interaction messages here include the above-mentioned NeutralVerifyMsg, consensus messages, block
  • NeutralVerifyMsg consensus messages
  • block For other types of business messages such as synchronous messages, you can ensure that the calculated amount of sent data is large enough to be comparable.
  • Node B keeps records of the amount of data sent. Therefore, the action of Node B to record the amount of sent data is not only to record the data amount of NeutralVerifyMsg, but to accumulate the data amount of all interactive messages within the above preset time period until the preset time period is finally obtained The sum of the data volumes of all interaction messages in the message.
  • Step 505 Node B sends and receives data volume to Node A.
  • Step 506 Node A calculates the RTT and compares the amount of data.
  • Node B can send the statistically obtained amount of received data to Node A at any time after the end of the above-mentioned preset time period.
  • Node A may also initiate an acquisition request to Node B, so that Node B returns the above-mentioned amount of received data in response to the acquisition request. Therefore, in some cases, the step of calculating the RTT by Node A in step 506 may be earlier than step 505, which can be adjusted according to actual conditions.
  • Node A can count the data volume of the interactive messages sent by itself within a preset time period. At the same time, Node A can obtain the amount of received data counted by Node B through step 505. Therefore, Node A can compare the amount of sent data with the amount of received data: if the two are consistent, it indicates that the blockchain relay communication network has not discarded data during message transmission; otherwise, it indicates that the blockchain relay communication network There are situations where data is discarded, and it is judged not to be neutral.
  • Node A can determine the RTT formed by the blockchain relay communication network when transmitting NeutralVerifyMsg and NeutralVerifyRespMsg according to the difference between the sending time and the receiving time mentioned above. If Node A sends multiple NeutralVerifyMsgs within the preset time period, Node A can obtain multiple sets of sending time and receiving time, and can calculate the average value of the RTT calculated from these time data as the final blockchain relay RTT of the communication network. When the value of RTT is not greater than the preset delay, Node A can determine that the delay of the blockchain relay communication network is reasonable; Not neutral.
  • the use of encryption and decryption technology can ensure that the blockchain relay communication network cannot obtain the content of the message and avoid fraud
  • the use of digital signature technology can ensure that Node B can accurately identify the interaction message from Node A and verify whether the message is transmitted during message transmission.
  • blockchain nodes can verify the blockchain relay communication network from multiple dimensions such as data privacy, data correctness, data integrity, and delay rationality, so that The neutrality of the blockchain relay communication network can be fully and reasonably determined.
  • Fig. 6 is a schematic diagram of a neutral verification system for a blockchain relay communication network provided by an exemplary embodiment.
  • the system may include: a source block chain node 601 and a target block chain node 602;
  • the chain node 602 sends a neutrality verification message, and the neutrality verification message includes the first encrypted message content generated by encrypting the first message content with the first symmetric key and the identity private key of the source block chain node 601.
  • the key is the digital signature generated by the first encrypted message content, and the first message content contains a neutral verification message type identifier;
  • the target blockchain node 602 can publicize the identity of the source blockchain node 601 key to verify the digital signature contained in the received interaction message, and use the first symmetric key to decrypt the encrypted message content contained in the interaction message, and after the signature verification is successful and the decrypted message
  • the content contains the neutral verification message type identification
  • the target blockchain node 602 can target The interactive message received within the preset time period and successfully verified by the identity public key of the source block chain node 601 performs data volume statistics to obtain the received data volume;
  • the source block chain node 601 can according to the The sending moment of the neutrality verification message and the receiving moment of the receipt confirmation message calculate the round-trip delay of the blockchain relay communication network, and compare the amount of received data with itself within the preset time period through the The data volume of the interactive message sent by the block
  • the source block chain node 601 may send a key distribution message to the target block chain node 602 through the block chain relay communication network, and the key distribution message includes The key ciphertext after the identity public key of the blockchain node 602 encrypts the first symmetric key, and the digital key ciphertext generated by the identity private key of the source blockchain node 601 Signature; after the target blockchain node 602 receives the key distribution message, it can verify the digital signature in the key distribution message according to the identity public key of the source blockchain node 601, and Decrypt the key ciphertext with its own identity private key, and determine the decrypted symmetric key as the first symmetric key if the signature verification is successful.
  • the identity public-private key pair of the source block chain node 601 and the target block chain node 602 includes any of the following: the source block chain node 601, the target block chain node 602 On-chain node identity public-private key pair; the dynamic identity public-private key pair negotiated by the source block chain node 601 and the target block chain node 602 through the block chain relay communication network.
  • the receipt confirmation message includes the second encrypted message content generated by encrypting the second message content with the second symmetric key and the identity private key of the target blockchain node 602 as the second
  • the digital signature generated by the encrypted message content, the second message content contains the type identification of the confirmation message;
  • the source blockchain node 601 can pair the received interactive message according to the identity public key of the target blockchain node 602 verifying the contained digital signature, and using the second symmetric key to decrypt the encrypted message content contained in the interaction message, and including the reception confirmation in the message content obtained by successful signature verification and decryption
  • the message type identifier confirm the receiving time of the interaction message as the receiving time of the receiving confirmation message.
  • the source block chain node 601 may send a neutral verification message to the target block chain node 602 through the block chain relay communication network, including: the source block chain node 601 passes the block chain
  • the relay communication network sends a plurality of neutrality verification messages to the target blockchain node 602; the source blockchain node 601 can calculate according to the sending time of the neutrality verification message and the receiving time of the receipt confirmation message
  • the round-trip delay of the blockchain relay communication network includes: the source blockchain node 601 calculates the average round-trip delay of the plurality of neutrality verification messages to serve as the round-trip delay of the blockchain relay communication network round-trip delay.
  • the multiple neutrality verification messages are periodically sent by the source blockchain node 601 within the preset time period.
  • the neutrality verification message includes receiver node indication information; the receiver node indication information includes the node identification of the target blockchain node 602, or the zone to which the target blockchain node 602 belongs The set ID of the block chain node set.
  • the source block chain node 601 can send a neutrality verification request to the target block chain node 602 through the block chain relay communication network; the target block chain node 602 can receive The neutrality verification request is switched from the normal mode to the neutrality verification mode, so as to respond to the neutrality verification message.
  • Fig. 7 is a schematic structural diagram of a device provided by an exemplary embodiment.
  • the device includes a processor 702 , an internal bus 704 , a network interface 706 , a memory 708 and a non-volatile memory 710 , and of course it may also include hardware required by other services.
  • the embodiment of this specification can be implemented based on software, for example, the processor 702 reads the corresponding computer program from the non-volatile memory 710 into the memory 708 and then runs it.
  • the embodiment of this specification does not exclude other implementations, such as logic devices or the combination of software and hardware, etc., that is to say, the execution subject of the following processing flow is not limited to each logic unit, and also Can be a hardware or logic device.
  • the neutrality verification device of the blockchain relay communication network can be applied to the device shown in Figure 7, for example, the device can be the source blockchain node to implement the technical solution of this specification.
  • the neutrality verification device of the block chain relay communication network may include: an acquisition unit 801, configured to obtain a neutrality verification message, and the neutrality verification message includes encrypting the first message content by the first symmetric key The generated first encrypted message content and the digital signature generated for the first encrypted message content by the identity private key of the source block chain node, the first message content includes neutrality verification message type identification; sending Unit 802, configured to send the neutrality verification message to the target blockchain node through the blockchain relay communication network, so that the target blockchain node: receives according to the identity public key pair of the source blockchain node Verify the digital signature contained in the interaction message received, and use the first symmetric key to decrypt the encrypted message content contained in the interaction message, and include in the message content obtained by successful signature verification and decryption
  • the neutrality verification message type identification return a receipt
  • the acquiring unit 801 is further configured to: acquire a key distribution message, the key distribution message includes the first symmetric key encrypted by the identity public key of the target blockchain node key ciphertext, and the digital signature generated for the key ciphertext by the identity private key of the source block chain node; the sending unit 802 is also used to: relay the communication network through the block chain Send the key distribution message to the target blockchain node, so that the target blockchain node: after receiving the key distribution message, pair the Verify the digital signature in the key distribution message, and decrypt the key ciphertext with its own identity private key, and determine the decrypted symmetric key as the first Symmetric key.
  • the identity public-private key pair of the source blockchain node and the target blockchain node includes any of the following: the on-chain node identity of the source blockchain node and the target blockchain node A public-private key pair; a dynamic identity public-private key pair negotiated between the source blockchain node and the target blockchain node through the blockchain relay communication network.
  • the receipt confirmation message includes the second encrypted message content generated by encrypting the second message content with the second symmetric key and the second encrypted message content is encrypted by the identity private key of the target blockchain node.
  • the content of the second message includes the type identification of the confirmation message; verify the digital signature contained in the received interactive message, and use the second symmetric key to decrypt the encrypted message content contained in the interactive message, and include in the message content obtained by successful signature verification and decryption If the type of the reception confirmation message is identified, confirm the reception time of the interaction message as the reception time of the reception confirmation message.
  • sending the neutrality verification message to the target blockchain node through the blockchain relay communication network includes: sending a plurality of neutrality verification messages to the target blockchain node through the blockchain relay communication network.
  • neutrality verification message; the calculation of the round-trip delay of the block chain relay communication network according to the sending moment of the neutrality verification message and the receiving moment of the reception confirmation message includes: calculating the plurality of neutrality verification messages The average round-trip delay of the message is used as the round-trip delay of the blockchain relay communication network.
  • the multiple neutrality verification messages are periodically sent by the source blockchain node within the preset time period.
  • the neutrality verification message includes receiver node indication information; the receiver node indication information includes the node identification of the target blockchain node, or the blockchain to which the target blockchain node belongs The collection ID of the node collection.
  • the sending unit 802 is further configured to: send a neutrality verification request to the target blockchain node through the blockchain relay communication network, so that the target blockchain node The neutral verification request is switched from the normal mode to the neutral verification mode, so as to respond to the neutral verification message.
  • the neutrality verification device of the blockchain relay communication network can be applied to the device shown in Figure 7, for example, the device can be a target blockchain node to implement the technical solution of this specification.
  • the neutrality verification device of the blockchain relay communication network may include: a message receiving unit 901, configured to receive the neutrality verification message sent by the source blockchain node through the blockchain relay communication network, the neutrality The verification message includes the first encrypted message content generated by encrypting the first message content with the first symmetric key and the digital signature generated for the first encrypted message content by the identity private key of the source blockchain node , the first message content includes a neutral verification message type identifier;
  • the message processing unit 902 is configured to verify the digital signature contained in the received interaction message according to the identity public key of the source blockchain node, and Decrypt the encrypted message content contained in the interaction message with the first symmetric key, and pass the neutral verification message type identifier under the condition that the signature verification is successful and the decrypted message content contains the neutrality verification message type identifier.
  • the block chain relay communication network returns the receiving confirmation message to the source block chain node, so that the source block chain node calculates the The round-trip delay of the blockchain relay communication network;
  • the data volume statistics unit 903 is used to collect data for the interactive messages received within the preset time period and successfully verified by the identity public key of the source blockchain node Volume statistics to obtain the amount of received data, so that the source block chain node will share the amount of received data with itself to the target block chain node through the block chain relay communication network within the preset time period Compared with the sent data volume of the interaction message sent.
  • the conditions for determining the neutrality of the blockchain relay communication network include: the round-trip delay matches the actual environment between the source blockchain node and the target blockchain node, and the The amount of received data is the same as the amount of sent data.
  • the message receiving unit 901 is further configured to: receive a key distribution message sent by the source blockchain node through the blockchain relay communication network, the key distribution message includes the The key ciphertext obtained by encrypting the first symmetric key with the identity public key of the target blockchain node, and the digital signature generated for the key ciphertext by the identity private key of the source blockchain node ;
  • the message processing unit 902 is also used to: verify the digital signature in the key distribution message according to the identity public key of the source block chain node, and verify the key with its own identity private key
  • the ciphertext is decrypted, and if the signature verification is successful, the symmetric key obtained through decryption is determined as the first symmetric key.
  • the identity public-private key pair of the source blockchain node and the target blockchain node includes any of the following: the on-chain node identity of the source blockchain node and the target blockchain node A public-private key pair; a dynamic identity public-private key pair negotiated between the source blockchain node and the target blockchain node through the blockchain relay communication network.
  • the receipt confirmation message includes the second encrypted message content generated by encrypting the second message content with the second symmetric key and the second encrypted message content is encrypted by the identity private key of the target blockchain node.
  • the content of the second message contains the type identification of the confirmation message; the confirmation message is used to make the source block chain node: according to the identity public key pair of the target block chain node Verifying the digital signature contained in the received interaction message, and using the second symmetric key to decrypt the encrypted message content contained in the interaction message, and in the message content obtained by successful signature verification and decryption If the type identifier of the reception confirmation message is included, confirm the reception time of the interactive message as the reception time of the reception confirmation message.
  • the message receiving unit 901 is specifically configured to: receive multiple neutrality verification messages sent by the source blockchain node through the blockchain relay communication network; the message processing unit 902 is specifically configured to: : Calculate the round-trip delay of the blockchain relay communication network according to the sending time of the neutrality verification message and the receiving time of the receiving confirmation message, including: the source blockchain node calculates the plurality of neutral The average round-trip delay of the validity verification message is used as the round-trip delay of the blockchain relay communication network.
  • the multiple neutrality verification messages are periodically sent by the source blockchain node within the preset time period.
  • the neutrality verification message includes receiver node indication information; the receiver node indication information includes the node identification of the target blockchain node, or the blockchain to which the target blockchain node belongs The collection ID of the node collection.
  • the message receiving unit 901 is also used to receive the neutrality verification request sent by the source block chain node through the block chain relay communication network; the message processing unit 902 is also used to receive The neutrality verification request is switched from the normal mode to the neutrality verification mode, so as to respond to the neutrality verification message.
  • a typical implementing device is a computer, which may take the form of a personal computer, laptop computer, cellular phone, camera phone, smart phone, personal digital assistant, media player, navigation device, e-mail device, game control device, etc. desktops, tablets, wearables, or any combination of these.
  • a computer includes one or more processors (CPUs), input/output interfaces, network interfaces and memory.
  • processors CPUs
  • input/output interfaces network interfaces
  • memory volatile and non-volatile memory
  • Memory may include non-permanent storage in computer-readable media, in the form of random access memory (RAM) and/or nonvolatile memory such as read-only memory (ROM) or flash RAM. Memory is an example of computer readable media.
  • RAM random access memory
  • ROM read-only memory
  • flash RAM flash random access memory
  • Computer-readable media including both permanent and non-permanent, removable and non-removable media, can be implemented by any method or technology for storage of information.
  • Information may be computer readable instructions, data structures, modules of a program, or other data.
  • Examples of computer storage media include, but are not limited to, phase change memory (PRAM), static random access memory (SRAM), dynamic random access memory (DRAM), other types of random access memory (RAM), read only memory (ROM), Electrically Erasable Programmable Read-Only Memory (EEPROM), Flash memory or other memory technology, Compact Disc Read-Only Memory (CD-ROM), Digital Versatile Disc (DVD) or other optical storage, Magnetic cassettes, disk storage, quantum memory, graphene-based storage media or other magnetic storage devices or any other non-transmission media that can be used to store information that can be accessed by computing devices.
  • computer-readable media excludes transitory computer-readable media, such as modulated data signals and carrier waves.
  • first, second, and third may use terms such as first, second, and third to describe various information, such information should not be limited to these terms. These terms are only used to distinguish information of the same type from one another. For example, without departing from the scope of the embodiments of this specification, first information may also be called second information, and similarly, second information may also be called first information. Depending on the context, the word “if” as used herein may be interpreted as “at” or “when” or "in response to a determination.”

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Computer Security & Cryptography (AREA)
  • Environmental & Geological Engineering (AREA)
  • Computer Hardware Design (AREA)
  • Computing Systems (AREA)
  • General Engineering & Computer Science (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)

Abstract

本说明书提供一种区块链中继通信网络的中立性验证方法及装置。该方法可以包括:源区块链节点通过区块链中继通信网络向目标区块链节点发送中立性验证消息,该消息包括加密后消息内容和数字签名,消息内容包含中立性验证消息类型标识;目标区块链节点对数字签名进行验签,用对称密钥对加密后消息内容进行解密,在验签成功且解密得到中立性验证消息类型标识时返回接收确认消息;目标区块链节点统计接收数据量;源区块链节点根据中立性验证消息的发送时刻和接收确认消息的接收时刻计算往返时延,将接收数据量与自身的发送数据量进行比较。其中,判定区块链中继通信网络具有中立性的条件包括往返时延匹配于实际环境,且接收数据量与发送数据量一致。

Description

区块链中继通信网络的中立性验证 技术领域
本说明书实施例涉及区块链技术领域,尤其涉及一种区块链中继通信网络的中立性验证方法及装置。
背景技术
区块链网络中包含若干区块链节点,区块链节点之间的需要实现诸如共识、交易传输、区块同步等通信操作。在传统的区块链技术中,各个区块链节点之间直接采用P2P(Peer to Peer,点对点)技术进行通信,以传输交易、区块等,但由于各种网络因素导致通信时延高、稳定性差,无法满足应用需求。
因此,相关技术中提出了基于区块链中继通信网络的区块链通信技术。区块链网络中的区块链节点可以分别接入区块链中继通信网络,使得区块链节点之间就可以通过区块链中继通信网络来实现通信。由于区块链中继通信网络是面向区块链实时传输的骨干中继通信网络,各个中继节点之间能够通过高QoS保障的优质带宽进行通信交互,因而由区块链中继通信网络接管区块链节点之间通信的中间链路(middle mile),能够降低通信时延、提高稳定性,从而显著提升区块链节点之间的通信质量。
发明内容
有鉴于此,本说明书实施例提供一种区块链中继通信网络的中立性验证方法及装置。
为实现上述目的,本说明书一个或多个实施例提供技术方案如下。
根据本说明书实施例的第一方面,提出了一种区块链中继通信网络的中立性验证方法,包括:源区块链节点通过区块链中继通信网络向目标区块链节点发送中立性验证消息,所述中立性验证消息包括由第一对称密钥对第一消息内容进行加密生成的第一加密后消息内容和由所述源区块链节点的身份私钥为所述第一加密后消息内容生成的数字签名,所述第一消息内容包含中立性验证消息类型标识;所述目标区块链节点根据所述源区块链节点的身份公钥对接收到的交互消息所含的数字签名进行验签,以及用所述第一对称密钥对所述交互消息所含的加密后消息内容进行解密,并在验签成功且解密得到的消息内容中包含所述中立性验证消息类型标识的情况下通过所述区块链中继通信网络向所述源区块链节点返回接收确认消息;以及,所述目标区块链节点针对在预设时间段内接收到且由所述源区块链节点的身份公钥验签成功的交互消息进行数据量统计,得到接收数据量;所述源区块链节点根据所述中立性验证消息的发送时刻和所述接收确认消息的接收时刻计算所述区块链中继通信网络的往返时延,以及将所述接收数据量与自身在所述预设时间段内通过所述区块链中继通信网络向所述目标区块链节点所发出的交互消息的发送数据量进行比较;其中,判定所述区块链中继通信网络具有中立性的条件包括所述往返时延匹配于所述源区块链节点与所述目标区块链节点之间的实际环境、且所述接收数据量与所述发送数据量一致。
根据本说明书实施例的第二方面,提出了一种区块链中继通信网络的中立性验证方法,应用于源区块链节点,所述方法包括:获取中立性验证消息,所述中立性验证消息包括由第一对称密钥对第一消息内容进行加密生成的第一加密后消息内容和由所述源区块链节点的身份私钥为所述第一加密后消息内容生成的数字签名,所述第一消息内容包含中立性验证消息类型标识;通过区块链中继通信网络向目标区块链节点发送所述中立性验证消息,使所述目标区块链节点:根据所述源区块链节点的身份公钥对接收到的交互消息所含的数字签名进行验签,以及用所述第一对称密钥对所述交互消息所含的加密后消息内容进行解密,并在验签成功且解密得到的消息内容中包含所述中立性验证消息类型标识的情况下通过所述区块链中继通信网络向所述源区块链节点返回接收确认消息;以及,针对在预设时间段内接收到且由所述源区块链节点的身份公钥验签成功的交互消息进行数据量统计,得到接收数据量;根据所述中立性验证消息的发送时刻和所述接收确认消息的接收时刻计算所述区块链中继通信网络的往返时延,以及将所述接收数据量与自身在所述预设时间段内通过所述区块链中继通信网络向所述目标区块链节点所发出的交互消息的发送数据量进行比较;其中,判定所述区块链中继通信网络具有中立性的条件包括所述往返时延匹配于所述源区块链节点与所述目标区块链节点之间的实际环境、且所述接收数据量与所述发送数据量一致。
根据本说明书实施例的第三方面,提出了一种区块链中继通信网络的中立性验证方法,应用于目标区块链节点,所述方法包括:接收源区块链节点通过区块链中继通信网络发送的中立性验证消息,所述中立性验证消息包括由第一对称密钥对第一消息内容进行加密生成的第一加密后消息内容和由所述源区块链节点的身份私钥为所述第一加密 后消息内容生成的数字签名,所述第一消息内容包含中立性验证消息类型标识;根据所述源区块链节点的身份公钥对接收到的交互消息所含的数字签名进行验签,以及用所述第一对称密钥对所述交互消息所含的加密后消息内容进行解密,并在验签成功且解密得到的消息内容中包含所述中立性验证消息类型标识的情况下通过所述区块链中继通信网络向所述源区块链节点返回接收确认消息,使所述源区块链节点根据所述中立性验证消息的发送时刻和所述接收确认消息的接收时刻计算所述区块链中继通信网络的往返时延;针对在预设时间段内接收到且由所述源区块链节点的身份公钥验签成功的交互消息进行数据量统计,得到接收数据量,使所述源区块链节点将所述接收数据量与自身在所述预设时间段内通过所述区块链中继通信网络向所述目标区块链节点所发出的交互消息的发送数据量进行比较;其中,判定所述区块链中继通信网络具有中立性的条件包括所述往返时延匹配于所述源区块链节点与所述目标区块链节点之间的实际环境、且所述接收数据量与所述发送数据量一致。
根据本说明书实施例的第四方面,提出了一种区块链中继通信网络的中立性验证系统,包括:源区块链节点和目标区块链节点;其中:所述源区块链节点通过区块链中继通信网络向所述目标区块链节点发送中立性验证消息,所述中立性验证消息包括由第一对称密钥对第一消息内容进行加密生成的第一加密后消息内容和由所述源区块链节点的身份私钥为所述第一加密后消息内容生成的数字签名,所述第一消息内容包含中立性验证消息类型标识;所述目标区块链节点根据所述源区块链节点的身份公钥对接收到的交互消息所含的数字签名进行验签,以及用所述第一对称密钥对所述交互消息所含的加密后消息内容进行解密,并在验签成功且解密得到的消息内容中包含所述中立性验证消息类型标识的情况下通过所述区块链中继通信网络向所述源区块链节点返回接收确认消息;以及,所述目标区块链节点针对在预设时间段内接收到且由所述源区块链节点的身份公钥验签成功的交互消息进行数据量统计,得到接收数据量;所述源区块链节点根据所述中立性验证消息的发送时刻和所述接收确认消息的接收时刻计算所述区块链中继通信网络的往返时延,以及将所述接收数据量与自身在所述预设时间段内通过所述区块链中继通信网络向所述目标区块链节点所发出的交互消息的发送数据量进行比较,判定所述区块链中继通信网络具有中立性的条件包括所述往返时延匹配于所述源区块链节点与所述目标区块链节点之间的实际环境、且所述接收数据量与所述发送数据量一致。
根据本说明书实施例的第五方面,提出了一种区块链中继通信网络的中立性验证装置,应用于源区块链节点,包括:获取单元,用于获取中立性验证消息,所述中立性验证消息包括由第一对称密钥对第一消息内容进行加密生成的第一加密后消息内容和由所述源区块链节点的身份私钥为所述第一加密后消息内容生成的数字签名,所述第一消息内容包含中立性验证消息类型标识;发送单元,用于通过区块链中继通信网络向目标区块链节点发送所述中立性验证消息,使所述目标区块链节点:根据所述源区块链节点的身份公钥对接收到的交互消息所含的数字签名进行验签,以及用所述第一对称密钥对所述交互消息所含的加密后消息内容进行解密,并在验签成功且解密得到的消息内容中包含所述中立性验证消息类型标识的情况下通过所述区块链中继通信网络向所述源区块链节点返回接收确认消息;以及,针对在预设时间段内接收到且由所述源区块链节点的身份公钥验签成功的交互消息进行数据量统计,得到接收数据量;处理单元,用于根据所述中立性验证消息的发送时刻和所述接收确认消息的接收时刻计算所述区块链中继通信网络的往返时延,以及将所述接收数据量与自身在所述预设时间段内通过所述区块链中继通信网络向所述目标区块链节点所发出的交互消息的发送数据量进行比较,判定所述区块链中继通信网络具有中立性的条件包括所述往返时延匹配于所述源区块链节点与所述目标区块链节点之间的实际环境、且所述接收数据量与所述发送数据量一致。
根据本说明书实施例的第六方面,提出了一种区块链中继通信网络的中立性验证装置,应用于目标区块链节点,包括:消息接收单元,用于接收源区块链节点通过区块链中继通信网络发送的中立性验证消息,所述中立性验证消息包括由第一对称密钥对第一消息内容进行加密生成的第一加密后消息内容和由所述源区块链节点的身份私钥为所述第一加密后消息内容生成的数字签名,所述第一消息内容包含中立性验证消息类型标识;消息处理单元,用于根据所述源区块链节点的身份公钥对接收到的交互消息所含的数字签名进行验签,以及用所述第一对称密钥对所述交互消息所含的加密后消息内容进行解密,并在验签成功且解密得到的消息内容中包含所述中立性验证消息类型标识的情况下通过所述区块链中继通信网络向所述源区块链节点返回接收确认消息,使所述源区块链节点根据所述中立性验证消息的发送时刻和所述接收确认消息的接收时刻计算所 述区块链中继通信网络的往返时延;数据量统计单元,用于针对在预设时间段内接收到且由所述源区块链节点的身份公钥验签成功的交互消息进行数据量统计,得到接收数据量,使所述源区块链节点将所述接收数据量与自身在所述预设时间段内通过所述区块链中继通信网络向所述目标区块链节点所发出的交互消息的发送数据量进行比较,判定所述区块链中继通信网络具有中立性的条件包括所述往返时延匹配于所述源区块链节点与所述目标区块链节点之间的实际环境、且所述接收数据量与所述发送数据量一致。
根据本说明书实施例的第七方面,提出了一种电子设备,包括处理器和用于存储处理器可执行指令的存储器。其中,所述处理器通过运行所述可执行指令以实现如上述第二方面或第三方面所述的方法。
根据本说明书实施例的第八方面,提出了一种计算机可读存储介质,其上存储有计算机指令,该指令被处理器执行时实现如上述第二方面或第三方面所述方法的步骤。
附图说明
图1是一示例性实施例提供的一种区块链中继通信网络的中立性验证方法的流程图。
图2是一示例性实施例提供的一种区块链节点通过区块链中继通信网络进行交互的示意图。
图3是一示例性实施例提供的一种基于源区块链节点侧的区块链中继通信网络的中立性验证方法的流程图。
图4是一示例性实施例提供的一种基于目标区块链节点侧的区块链中继通信网络的中立性验证方法的流程图。
图5是一示例性实施例提供的一种中立性验证的交互流程图。
图6是一示例性实施例提供的一种区块链中继通信网络的中立性验证系统的示意图。
图7是一示例性实施例提供的一种设备的结构示意图。
图8是一示例性实施例提供的一种基于源区块链节点侧的区块链中继通信网络的中立性验证装置的框图。
图9是一示例性实施例提供的一种基于目标区块链节点侧的区块链中继通信网络的中立性验证装置的框图。
具体实施方式
这里将详细地对示例性实施例进行说明,其示例表示在附图中。下面的描述涉及附图时,除非另有表示,不同附图中的相同数字表示相同或相似的要素。以下示例性实施例中所描述的实施方式并不代表与本说明书一个或多个实施例相一致的所有实施方式。相反,它们仅是与如所附权利要求书中所详述的、本说明书一个或多个实施例的一些方面相一致的装置和方法的例子。
需要说明的是:在其他实施例中并不一定按照本说明书示出和描述的顺序来执行相应方法的步骤。在一些其他实施例中,其方法所包括的步骤可以比本说明书所描述的更多或更少。此外,本说明书中所描述的单个步骤,在其他实施例中可能被分解为多个步骤进行描述;而本说明书中所描述的多个步骤,在其他实施例中也可能被合并为单个步骤进行描述。
区块链中继通信网络可以适用于各种类型的区块链网络,包括公有链、私有链和联盟链等。譬如,应用于公有链的区块链中继通信网络主要包括Falcon、Fast Bitcoin Relay Network(FBRN)、Fast Internet Bitcoin Relay Engine(FIBRE)等,而应用于联盟链的区块链中继通信网络主要包括BloXRoute、Blockchain Transmission Network(BTN)等。本说明书并不限制所采用的区块链中继通信网络。
虽然区块链中继通信网络具有如前所述的若干优势,但是区块链节点在使用区块链中继通信网络进行消息传输时,需要确定该区块链中继通信网络具有中立性,不会对消息传输造成负面影响。因此,本说明书提出了一种区块链中继通信网络的中立性验证方案,能够对区块链中继通信网络的中立性进行有效验证。
图1是一示例性实施例提供的一种区块链中继通信网络的中立性验证方法的流程图。如图1所示,该方法可以包括:步骤102,源区块链节点通过区块链中继通信网络向目标区块链节点发送中立性验证消息,所述中立性验证消息包括由第一对称密钥对第一消息内容进行加密生成的第一加密后消息内容和由所述源区块链节点的身份私钥为所述第一加密后消息内容生成的数字签名,所述第一消息内容包含中立性验证消息类型标识。
通过在一物理设备上运行区块链平台代码(即链代码),可以在该物理设备上形成相应的节点实例。如果不考虑该物理设备所实现的其他功能,可以不对物理设备和节点实例加以区分,此时该物理设备或节点实例均可以称为区块链节点。如果考虑到该物理 设备所实现的其他功能,比如除了节点实例之外还可以运行其他的业务实例,此时可以将该物理设备称为节点设备、将该节点实例称为区块链节点。总之,区块链节点可以是物理设备层面的概念,也可以是逻辑层面的概念,需要根据实际情况来确定。
需要说明的是,区块链中继通信网络中的中继节点,除了可以是物理设备之外,也可以是逻辑设备。对于逻辑设备而言,例如区块链中继通信网络可以是基于云处理平台搭建的骨干通信网络,此时中继节点可以为针对云处理平台上的云处理资源进行虚拟化而创建的虚拟设备。
在本说明书的技术方案中,与中立性验证相关的功能逻辑可属于上述的区块链平台代码的一部分,则源区块链节点和目标区块链节点可为相应的节点实例,也可为节点实例所处的物理设备。或者,与中立性验证相关的功能逻辑也可属于一业务实例,该业务实例与节点实例处于同一物理设备上,则源区块链节点和目标区块链节点可为相应的物理设备。不论对区块链节点的理解为何,本说明书中与中立性验证相关的功能逻辑可与区块链节点所实现的其他功能逻辑来自同一开发方,也可分别来自不同的开发方。例如,当来自不同开发方时,与中立性验证相关的功能逻辑可基于SDK(Software Development Kit,软件开发工具包)的形式而实现,以便于不同开发方之间的协同。
源区块链节点和目标区块链节点均为接入区块链中继通信网络的任意区块链节点。实际上,已接入区块链中继通信网络的每个区块链节点均可以作为源区块链节点,也可以作为目标区块链节点。对于任一源区块链节点而言,相应的目标区块链节点的数量可以为一个或多个,例如此时的目标区块链节点可以为已接入区块链中继通信网络的所有其他区块链节点中的一部分或全部区块链节点。在一实施例中,已接入区块链中继通信网络的所有区块链节点可以同时参与到中立性验证过程中:每个区块链节点都作为源区块链节点,并同时作为其他区块链节点对应的目标区块链节点,从而使得所有区块链节点都可以针对自身所接入的区块链中继通信网络实现中立性验证。
由于在生成中立性验证消息的过程中,需要通过源区块链节点的身份私钥生成数字签名,且该身份私钥通常由源区块链节点自行维护,因而通常由源区块链节点主动生成中立性验证消息。当然,如果源区块链节点的身份私钥可以交由其他可信对象进行维护,那么也可以由该可信对象生成中立性验证消息并提供至源区块链节点。源区块链节点和目标区块链节点可以分别维护有区块链节点列表。某一区块链节点所维护的区块链节点列表,通常用于记录该区块链节点所处区块链网络中的所有区块链节点的信息。当然,在一些情况下,譬如涉及到多条区块链网络之间的跨链场景时,区块链节点列表也可以维护其他区块链网络中的区块链节点的信息。因此,源区块链节点与目标区块链节点可以属于同一区块链网络,也可以分别属于不同的区块链网络。区块链节点列表中所维护的区块链节点的信息,譬如可以包括区块链节点的节点标识、链上节点身份公钥、节点IP和端口信息等。链上节点身份是基于非对称加密算法生成的,每个区块链节点的链上节点身份包含链上节点身份公钥和链上节点身份私钥。由于链上节点身份属于区块链节点之间实现链上交互的信任基础,因此区块链节点的链上节点身份可以用于实现本说明书中对数字签名的生成和验证,比如源区块链节点通过自身的链上节点身份私钥生成上述的数字签名,而目标区块链节点通过源区块链节点的链上节点身份公钥对该数字签名进行验签。当然,除了链上节点身份之外,源区块链节点与目标区块链节点可以采用其他的公私钥对,比如源区块链节点与目标区块链节点通过区块链中继通信网络协商的动态身份公私钥对,该动态身份公私钥对可以专门用于中立性验证,以实现对数字签名的生成和验证,本说明书并不对此进行限制。
除了数字签名之外,中立性验证消息还包含第一加密后消息内容。源区块链节点可以通过第一对称密钥对第一消息内容进行加密以生成上述的第一加密后消息内容。当然,如果源区块链节点将第一对称密钥交由其他可信对象进行维护,那么也可以由该可信对象生成第一加密后消息内容并提供至源区块链节点。第一对称密钥由源区块链节点与目标区块链节点分别维护,本说明书并不限制该第一对称密钥的生成方式。例如,第一对称密钥可以由密钥管理服务器(Key Management Server,KMS)生成并分发至源区块链节点和目标区块链节点。再例如,第一对称密钥可以由源区块链节点与目标区块链节点之间通过相关技术中的密钥协商技术进行协商得到,这里的密钥协商技术譬如可以包括DH(Diffie-Hellman)算法等。又例如,第一对称密钥可以由源区块链节点与目标区块链节点中的任一方生成后,分发至源区块链节点与目标区块链节点中的另一方。接入区块链中继通信网络的所有区块链节点可以共同维护统一的第一对称密钥;或者,当这些区块链节点存在分组(比如同一区块链网络内的节点属于同一组,再比如基于业务需求 划分的组等)时,同一组内的区块链节点可以维护统一的第一对称密钥、不同组的第一对称密钥不同;或者,每个区块链节点所采用的第一对称密钥可以各不相同。实际上,无论采用何种第一对称密钥,只要确保该第一对称密钥的安全性、避免区块链中继通信网络获得该第一对称密钥,以及目标区块链节点能够通过正确的第一对称密钥来实施解密操作,即可保证顺利完成本说明书的中立性验证方案。
若确定由源区块链节点将第一对称密钥分发至目标区块链节点,该源区块链节点通过区块链中继通信网络向目标区块链节点发送密钥分发消息,该密钥分发消息中包含由目标区块链节点的身份公钥对第一对称密钥进行加密后的密钥密文,以及由源区块链节点的身份私钥为密钥密文生成的数字签名;相应的,目标区块链节点接收到密钥分发消息后,根据源区块链节点的身份公钥对密钥分发消息中的数字签名进行验签,以及用自身的身份私钥对密钥密文进行解密,并在验签成功的情况下将解密得到的对称密钥确定为第一对称密钥。密钥分发消息包含上述的密钥密文和针对该密钥密文的数字签名。该密钥分发消息可由源区块链节点生成,或者由其他可信对象生成后提供至源区块链节点,本说明书并不对此进行限制。如果由其他可信对象生成密钥分发消息,那么源区块链节点可以将自身的身份私钥托管至该可信对象,以便该可信对象可以据此为密钥密文生成相应的数字签名。其中,源区块链节点获取该目标区块链节点的身份公钥,并基于非对称加密算法将该身份公钥用于对待分发的第一对称密钥进行加密,从而生成相应的密钥密文。那么,由于该密钥密文仅能够由目标区块链节点所维护的身份私钥所解密,因而能够安全地通过区块链中继通信网络进行传输,而不必担心第一对称密钥在区块链中继通信网络中暴露。进一步的,可以通过源区块链节点的身份私钥为上述的密钥密文生成数字签名,目标区块链节点可以根据源区块链节点的身份公钥对该数字签名进行验证,从而确定密钥密文在传输过程中是否发生了缺失、替换等,防止由于中间人攻击等带来的安全性问题。如前文所述,源区块链节点向目标区块链节点分发第一对称密钥的过程中,所涉及到的身份公私钥对可以为区块链节点的链上节点身份公私钥对,也可以为协商出的诸如动态身份公私钥对等,本说明书并不对此进行限制。
上述的第一消息内容包含中立性验证消息类型标识,该中立性验证消息类型标识用于表明其所处的交互消息为中立性验证消息,而非源区块链节点所发送的其他交互消息。因此,在实施中立性验证的过程中,源区块链节点仍然可以向目标区块链节点正常发送其他交互消息,譬如共识消息、区块同步消息等业务消息,不需要中断区块链业务,从而降低中立性验证对区块链业务的影响。除了中立性验证消息类型标识之外,第一消息内容是否包含其他信息以及包含何种信息,均不影响本说明书的中立性验证方案的实施。
源区块链节点通过区块链中继通信网络发送中立性验证消息时,与相关技术中通过区块链中继通信网络进行消息传输的过程无异。以图2所示的场景为例,如图2所示:假定源区块链节点为Node A、目标区块链节点为Node B,Node A与区块链中继通信网络中的中继节点a相连、Node B与区块链中继通信网络中的中继节点b相连。Node A可以将中立性验证消息发送至中继节点a,由中继节点a将该中立性验证消息路由至中继节点b后,由中继节点b进一步将该中立性验证消息发送至Node B。
在一实施例中,区块链中继通信网络可以对需要传输的消息进行广播,使得所有连接至该区块链中继通信网络的区块链节点均可以接收到消息。例如,中继节点a在收到中立性验证消息后,在区块链中继通信网络中对该中立性验证消息进行广播,并进一步由每个中继节点都将接收到的中立性验证消息转发至自身相连的区块链节点,比如中继节点c会接收到中立性验证消息并转发至区块链节点Node C。当然,如果某一区块链节点并不参与中立性验证,该区块链节点即便收到中立性验证消息也可以不做任何处理,比如可以直接丢弃。
在另一实施例中,中立性验证消息中可以包含接收方节点指示信息,以使区块链中继通信网络将中立性验证消息发送至该接收方节点指示信息对应的区块链节点。此时,区块链中继通信网络对于中立性验证消息的转发将具有针对性,而不会发送至与目标区块链节点无关的中继节点。接收方节点指示信息可以包括目标区块链节点的节点标识。如果存在多个目标区块链节点:一种情况下,每条中立性验证消息中的接收方节点指示信息可以仅为一个目标区块链节点的节点标识,此时需要针对每一目标区块链节点分别发送一条中立性验证消息;另一种情况下,一条中立性验证消息中的接收方节点指示信息可以包括多个目标区块链节点的节点标识,此时仅需要发送一条中立性验证消息。或者,接收方节点指示信息可以包括目标区块链节点所属区块链节点集合的集合标识,尤其是当多个目标区块链节点属于同一个区块链节点集合时,通过该集合标识可以减少接 收方节点指示信息的长度。这里的区块链节点集合可以为预先向区块链中继通信网络注册形成,同一区块链节点集合中的区块链节点可以为同一区块链网络中的全部或部分区块链节点,也可以同时包括来自多个区块链网络的区块链节点,可以根据业务需求进行注册,且该区块链节点集合中所含的区块链节点可以根据需求进行增删。
区块链中继通信网络中的各个中继节点可以维护有:各个中继节点之间的连接关系、每个中继节点与区块链节点之间的连接关系。基于所维护的上述信息,中继节点可以生成相应的路由策略,以用于进行消息传输。例如,当中继节点a读取中立性验证消息中的接收方节点指示信息时,确定目标区块链节点为Node B,该中继节点a会确定出自身与连接至该Node B的中继节点b之间的转发路径,并通过该转发路径对中立性验证消息进行转发至中继节点b。如果中继节点a与中继节点b之间存在直接相连的链路,上述转发路径为“中继节点a-中继节点b”,即中继节点a可以将中立性验证消息直接发送至中继节点b,而不会发送至中继节点c。如果中继节点a与中继节点b之间不存在直接相连的链路,或者直接相连的链路出现故障等,上述的转发路径可以为“中继节点a-中继节点c-中继节点b”,则中继节点a可以将中立性验证消息转发至中继节点c;与中继节点a相类似的,中继节点c在确定目标区块链节点为Node B后,也会确定出自身与连接至该Node B的中继节点b之间的转发路径,并通过该转发路径对中立性验证消息进行转发至中继节点b,譬如确定出的转发路径为“中继节点c-中继节点b”,即中继节点c可以将中立性验证消息直接发送至中继节点b。
如果存在上述的区块链节点集合,各个中继节点还可以维护有各个区块链节点集合的信息,包括集合标识、所含的区块链节点等。例如,当中继节点a读取中立性验证消息中的接收方节点指示信息时,确定该接收方节点指示信息为集合标识SID1,且确定出SID1所含的区块链节点为Node B和Node C,那么中继节点a将Node B和Node C分别确定为目标区块链节点,并基于如前所述的方式将中立性验证消息分别路由至Node B相连的中继节点b、Node C相连的中继节点c,此处不再赘述。
在如前所述的实施例中,若源区块链节点通过区块链中继通信网络将密钥分发消息传输至目标区块链节点,则该密钥分发消息的传输过程可以参考上述实施例中针对中立性验证消息的传输过程,此处不再赘述。需要说明的是:如果同一条密钥分发消息需要发送至多个目标区块链节点,那么该密钥分发消息中应当包含分别对应于每一目标区块链节点的数据集:每一数据集包括由相应目标区块链节点的身份公钥生成的密钥密文和相应的数字签名。假定Node A希望将第一对称密钥分发至Node B和Node C,则密钥分发消息中包括Node B对应的数据集M1、Node C对应的数据集M2,其中:M1包括由Node B的身份公钥生成的密钥密文enc_key_B和相应的数字签名enc_key_B_sign,M2包括由Node C的身份公钥生成的密钥密文enc_key_C和相应的数字签名enc_key_C_sign。相应的,每一目标区块链节点在收到密钥分发消息后,需要找到自身对应的数据集,以便实现前文所述的解密和验签。每一数据集可以包含相应的目标区块链节点的节点标识,以便于各个目标区块链节点准确找到自身对应的数据集;或者,数据集可以不包含相应的目标区块链节点的节点标识,每个目标区块链节点需要分别对各个数据集进行尝试,直至找到自身对应的数据集。
在一实施例中,已接入区块链中继通信网络的区块链节点,可定期实施本说明书的中立性验证方案,以针对区块链中继通信网络进行中立性验证。在另一实施例中,每个区块链节点可随时发起针对区块链中继网络的中立性验证,譬如某个区块链节点刚接入该区块链中继通信网络,或者某个区块链节点在运行过程中对于区块链中继通信网络的中立性存疑时,都可发起上述的中立性验证。当某个区块链节点希望发起上述的中立性验证时,该区块链节点可由普通模式切换至中立性验证模式,从而以本说明书中的源区块链节点这一角色而运行。在运行过程中,源区块链节点可通过区块链中继通信网络向目标区块链节点发送中立性验证请求,以及实现本说明书中涉及源区块链节点的其他功能。相应的,目标区块链节点根据接收到的中立性验证请求由普通模式切换至中立性验证模式,以针对源区块链节点发送的中立性验证消息进行响应。其中,当运行于中立性验证模式时,区块链节点不仅可继续完成在普通模式下的消息交互和处理功能,譬如对共识消息、区块同步消息等的收发和处理等,还可实现本说明书中的中立性验证方案。
通过为区块链节点设置诸如普通模式和中立性验证模式等不同的运行模式,使得区块链节点可以根据实际情况选择是否参与中立性验证,例如可以通过避免参与中立性验证以降低对自身业务的影响。当然,对于上述运行模式的选择可以是非必要的,例如所有区块链节点可以默认运行在中立性验证模式下,以便于随时实现对区块链中继通信网 络的中立性验证。
步骤104,所述目标区块链节点根据所述源区块链节点的身份公钥对接收到的交互消息所含的数字签名进行验签,以及用所述第一对称密钥对所述交互消息所含的加密后消息内容进行解密,并在验签成功且解密得到的消息内容中包含所述中立性验证消息类型标识的情况下通过所述区块链中继通信网络向所述源区块链节点返回接收确认消息;以及,所述目标区块链节点针对在预设时间段内接收到且由所述源区块链节点的身份公钥验签成功的交互消息进行数据量统计,得到接收数据量。
目标区块链节点在收到中立性验证消息后,可以分别获取该中立性验证消息所含的加密后消息内容和数字签名。如前所述,目标区块链节点可以根据源区块链节点的节点标识,从自身维护的区块链节点列表中获取源区块链节点的链上节点身份公钥,或者该源区块链节点的动态身份公钥等其他类型的身份公钥,以用于对上述的数字签名进行验签。由于在中立性验证消息中,定义了该数字签名是针对加密后消息内容而生成,因而目标区块链节点会根据加密后消息内容完成对数字签名的验证。如果验证成功,表明该中立性验证消息确实来自于源区块链节点,且传输过程中没有发生数据缺失,也没有受到中间人攻击。如果验证失败,表明加密后消息内容和数字签名中的至少之一存在异常,目标区块链节点可以丢弃或返回告警消息。
中立性验证消息中可以包含发送方节点标识信息,该发送方节点标识信息用于记录作为发送方的区块链节点的节点标识。因此,在源区块链节点所发出的中立性验证消息中,发送方节点标识信息的取值为源区块链节点的节点标识。相应的,目标区块链节点可以从发送方节点标识信息中提取源区块链节点的节点标识,并根据提取的节点标识确定源区块链节点对应的身份公钥,进而根据确定的身份公钥对中立性验证消息中的数字签名进行验签。
当然,中立性验证消息中的发送方节点标识信息只是用于表明发送方节点身份的一种方式,目标区块链节点还可通过其他方式获得发送方节点身份,本说明书并不对此进行限制。例如,区块链中继通信网络在获得中立性验证消息后,可以将该中立性验证消息封装为中继消息,并在区块链中继通信网络中传输该中继消息。其中,中继消息中可以封装有源区块链节点的节点标识,则源区块链节点的节点标识可由区块链中继通信网络从中继消息中解封后告知目标区块链节点。具体的,以上述的Node A向Node B分发密钥为例:中继节点a收到Node A发送的中立性验证消息后,将该中立性验证消息封装为中继消息,该封装过程中会在该中继消息中添加Node A的节点标识。相应的,中继节点b收到该中继消息后,可以通过解封获取Node A的节点标识,并将该节点标识与中立性验证消息一并发送至Node B,使得Node B获知该中立性验证消息来自Node A。
目标区块链节点可以通过自身维护的第一对称密钥对加密后消息内容进行解密。如前所述,如果接入区块链中继通信网络的所有区块链节点维护有统一的第一对称密钥,那么目标区块链节点可以直接使用该第一对称密钥对加密后消息内容进行解密。如果接入区块链中继通信网络的所有区块链节点所维护的第一对称密钥并不统一,那么目标区块链节点需要通过前述方式确定源区块链节点的节点标识,并据此确定出对应于源区块链节点的第一对称密钥并解密上述的加密后消息内容。目标区块链节点可以预先维护有节点标识与第一对称密钥的对应关系,从而根据源区块链节点的节点标识确定出所需采用的第一对称密钥。目标区块链节点可以预先维护有集合标识与第一对称密钥的对应关系,从而根据源区块链节点的节点标识确定该源区块链节点所属的集合标识,并进而根据该集合标识确定出所需采用的第一对称密钥。总之,基于目标区块链节点所维护的对应关系,目标区块链节点总是能够准确获取所需采用的第一对称密钥,从而实现对上述加密后消息内容的解密操作。
如前所述,源区块链节点在发送中立性验证消息的同时,还会同时发送其他类型的交互消息。如果其他类型的交互消息也采用加密发送,那么目标区块链节点在接收到交互消息后,将无法直接确定出该交互消息是否为中立性验证消息或其他类型的交互消息。因此,目标区块链节点需要通过第一对称密钥对所接收到的交互消息中的加密后消息内容进行解密,并在解密出的消息内容中包含中立性验证消息类型标识的情况下,确定接收到的交互消息为上述的中立性验证消息。如果解密出的消息内容中未包含中立性验证消息类型标识,目标区块链节点确认接收到的交互消息并非中立性验证消息。当然,对于并非中立性验证消息的交互消息,目标区块链节点可以按照相关技术对该交互消息做出响应处理,此处不再赘述。
如果验签成功且解密得到的消息内容中包含中立性验证消息类型标识,目标区块链 节点可以认为接收到来自源区块链节点的中立性验证消息,因此通过区块链中继通信网络向源区块链节点返回接收确认消息。对于该接收确认消息的传输过程,可以参考上文中对于中立性验证消息的传输过程,只是发送方与接收方之间发生了对调,但并不影响传输原理,因而此处不再赘述。
接收确认消息可采用明文消息。而出于提升安全性的考虑,可对接收确认消息进行隐私传输。例如,接收确认消息可包括由第二对称密钥对第二消息内容进行加密生成的第二加密后消息内容和由目标区块链节点的身份私钥为第二加密后消息内容生成的数字签名,且第二消息内容包含接收确认消息类型标识。相应的,源区块链节点在收到来自目标区块链节点的交互消息时,根据目标区块链节点的身份公钥对接收到的交互消息所含的数字签名进行验签,如果验签通过则确认该交互消息来自目标区块链节点。进一步地,如果目标区块链节点还同时发送诸如前文所述的业务消息或其他类型的交互消息,并且这些交互消息也采用隐私传输,那么源区块链节点需要用第二对称密钥对交互消息所含的加密后消息内容进行解密,如果解密得到的消息内容中包含上述的接收确认消息类型标识,即可确认收到的交互消息为上述的接收确认消息。可见,在隐私传输的场景下,源区块链节点可在验签成功且解密得到的消息内容中包含接收确认消息类型标识的情况下,确定接收到目标区块链节点发送的接收确认消息,因而可将该交互消息的接收时刻确认为接收确认消息的接收时刻,以用于在下文中计算区块链中继通信网络的往返时延(Round-Trip Time,RTT)。为了确保RTT的计算准确性,目标区块链节点可在确认接收到来自源区块链节点的中立性验证消息后立即返回接收确认消息,即目标区块链节点不会主动造成不必要的等待或延时,以便于尽早返回接收确认消息。
第二对称密钥可以与第一对称密钥相同。当然,第二对称密钥也可以与第一对称密钥不同,但第二对称密钥的生成方式可以参考前文所述的第一对称密钥的生成方式,譬如由源区块链节点与目标区块链节点协商、由密钥管理服务器分发、由目标区块链节点向源区块链节点分发等,此处不再一一赘述,且本说明书并不对此进行限制。
目标区块链节点可能同时接收到多个区块链节点所发送的交互消息。通过对交互消息所含的数字签名进行验证,目标区块链节点可以区分和确认交互消息的发送方,并针对在预设时间段内接收到且发送方为源区块链节点的交互消息进行数据量统计,得到接收数据量。如果中立性验证是周期性的,那么目标区块链节点对于接收数据量的统计也可以是周期性的,上述的预设时间段可以为各个统计周期。如果中立性验证是非周期性的,譬如在源区块链节点的触发下而发起,那么目标区块链节点可以在确认中立性验证已发起或在接收到首条来自源区块链节点的中立性验证消息时启动统计,且预设时间段为启动统计的时刻(即启动时刻)与预设时长所定义的时间段。其中,上述的“首条”是指当次中立性验证过程中的首条,而并不仅指历史上的首条。
如前所述,源区块链节点在实施中立性验证的过程中,向目标区块链节点发送的交互消息除了中立性验证消息之外,还可能包含其他类型的消息。目标区块链节点在统计过程中,既可以是针对中立性验证消息进行统计,也可以是针对所有类型的交互消息进行统计,本说明书并不对此进行限制。如果仅统计中立性验证消息,那么源区块链节点可适当增加对中立性验证消息的发送数量,以使得针对该中立性验证消息所统计的接收数据量具有统计意义。当然,如果是针对所有类型的交互消息进行统计,那么源区块链节点无需发送很多的中立性验证消息,这样一方面可由其他类型的交互消息来提供足够的数据量以使得所统计的接收数据量具有统计意义,另一方面可以避免过多的中立性验证消息对其他类型的交互消息造成较大影响,即降低中立性验证对正常业务造成的影响。
步骤106,所述源区块链节点根据所述中立性验证消息的发送时刻和所述接收确认消息的接收时刻计算所述区块链中继通信网络的往返时延,以及将所述接收数据量与自身在所述预设时间段内通过所述区块链中继通信网络向所述目标区块链节点所发出的交互消息的发送数据量进行比较。其中,判定所述区块链中继通信网络具有中立性的条件包括:所述往返时延匹配于所述源区块链节点与所述目标区块链节点之间的实际环境,且所述接收数据量与所述发送数据量一致。
源区块链节点向目标区块链节点所发送的中立性验证消息,可以为一条或多条,本说明书并不对此进行限制。如果源区块链节点通过区块链中继通信网络向目标区块链节点发送多条中立性验证消息,那么在计算上述的往返时延时,源区块链节点可以计算多条中立性验证消息的平均往返时延,以作为上述区块链中继通信网络的往返时延。其中,上述的多条中立性验证消息可由源区块链节点在前述预设时间段内周期性发送,这样可以将多条中立性验证消息的传输分摊在该预设时间段内的不同时刻,既可以避免集中发 送给正常业务造成不利影响,又可以分别获知区块链中继通信网络在不同时刻的时延情况,有利于提升计算的往返时延的准确性。
如果源区块链节点在中立性验证过程中会发送多条中立性验证消息,那么源区块链节点可以在每发送一条中立性验证消息之后,可以等待接收到目标区块链节点返回的接收确认消息,然后再发送下一条中立性验证消息,从而避免混淆中立性验证消息与接收确认消息之间的对应关系,比如将前一条中立性验证消息的发送时刻与后一条接收确认消息的接收时刻共同计算往返时延等,防止造成对往返时延的错误计算。或者,中立性验证消息的消息内容中可以包含消息编号,且目标区块链节点在获取对应于中立性验证消息的接收确认消息时,该接收确认消息的消息内容中也可以包含相同的消息编号,这样源区块链节点可以根据消息编号准确识别出中立性验证消息与接收确认消息之间的对应关系,使得源区块链节点可以随时发送中立性验证消息而无需等待接收确认消息。
基于源区块链节点与目标区块链节点之间的实际环境,可以获知在两者之间进行消息传输时的正常时延。因此,当源区块链节点确定出的往返时延与该正常时延相匹配时,就表明区块链中继通信网络没有故意对传输的消息造成时延,满足时延合理性。同时,当源区块链节点在预设时间段内统计的发送数据量与目标区块链节点在该预设时间段内所统计的接收数据量一致时,表明区块链中继通信网络在传输过程中没有故意丢弃数据,确保了数据完整性。通过采用加解密技术可以确保区块链中继通信网络无法获知消息内容、避免舞弊,且通过采用数字签名技术可以确保目标区块链节点准确识别来自源区块链节点的交互消息,并验证消息传输过程中是否存在缺失、替换等问题,从而保证了数据隐私性和数据正确性。
综上所述,本说明书通过从数据隐私性、数据正确性、数据完整性和时延合理性等多个维度对区块链中继通信网络进行验证,从而能够全面合理地确定出区块链中继通信网络的中立性。
图3是一示例性实施例提供的一种基于源区块链节点侧的区块链中继通信网络的中立性验证方法的流程图。如图3所示,该方法可以包括如下步骤。
步骤302,获取中立性验证消息,所述中立性验证消息包括由第一对称密钥对第一消息内容进行加密生成的第一加密后消息内容和由所述源区块链节点的身份私钥为所述第一加密后消息内容生成的数字签名,所述第一消息内容包含中立性验证消息类型标识。
步骤304,通过区块链中继通信网络向目标区块链节点发送所述中立性验证消息,使所述目标区块链节点:根据所述源区块链节点的身份公钥对接收到的交互消息所含的数字签名进行验签,以及用所述第一对称密钥对所述交互消息所含的加密后消息内容进行解密,并在验签成功且解密得到的消息内容中包含所述中立性验证消息类型标识的情况下通过所述区块链中继通信网络向所述源区块链节点返回接收确认消息;以及,针对在预设时间段内接收到且由所述源区块链节点的身份公钥验签成功的交互消息进行数据量统计,得到接收数据量。
步骤306,根据所述中立性验证消息的发送时刻和所述接收确认消息的接收时刻计算所述区块链中继通信网络的往返时延,以及将所述接收数据量与自身在所述预设时间段内通过所述区块链中继通信网络向所述目标区块链节点所发出的交互消息的发送数据量进行比较。其中,判定所述区块链中继通信网络具有中立性的条件包括:所述往返时延匹配于所述源区块链节点与所述目标区块链节点之间的实际环境,且所述接收数据量与所述发送数据量一致。
如前所述,所述方法还包括:获取密钥分发消息,所述密钥分发消息中包含由所述目标区块链节点的身份公钥对所述第一对称密钥进行加密后的密钥密文,以及由所述源区块链节点的身份私钥为所述密钥密文生成的数字签名;通过所述区块链中继通信网络向所述目标区块链节点发送所述密钥分发消息,使所述目标区块链节点:接收到所述密钥分发消息后,根据所述源区块链节点的身份公钥对所述密钥分发消息中的数字签名进行验签,以及用自身的身份私钥对所述密钥密文进行解密,并在验签成功的情况下将解密得到的对称密钥确定为所述第一对称密钥。
如前所述,所述源区块链节点、所述目标区块链节点的身份公私钥对包括下述任一:所述源区块链节点、所述目标区块链节点的链上节点身份公私钥对;所述源区块链节点与所述目标区块链节点通过所述区块链中继通信网络协商的动态身份公私钥对。
如前所述,所述接收确认消息包括由第二对称密钥对第二消息内容进行加密生成的第二加密后消息内容和由所述目标区块链节点的身份私钥为所述第二加密后消息内容 生成的数字签名,所述第二消息内容包含接收确认消息类型标识。所述方法还包括:所述源区块链节点根据所述目标区块链节点的身份公钥对接收到的交互消息所含的数字签名进行验签,以及用所述第二对称密钥对所述交互消息所含的加密后消息内容进行解密,并在验签成功且解密得到的消息内容中包含所述接收确认消息类型标识的情况下,将该交互消息的接收时刻确认为所述接收确认消息的接收时刻。
如前所述,所述通过区块链中继通信网络向目标区块链节点发送中立性验证消息,包括:通过所述区块链中继通信网络向所述目标区块链节点发送多条中立性验证消息;所述根据所述中立性验证消息的发送时刻和所述接收确认消息的接收时刻计算所述区块链中继通信网络的往返时延,包括:计算所述多条中立性验证消息的平均往返时延,以作为所述区块链中继通信网络的往返时延。
如前所述,所述多条中立性验证消息由所述源区块链节点在所述预设时间段内周期性发送。
如前所述,所述中立性验证消息中包含接收方节点指示信息;所述接收方节点指示信息包括所述目标区块链节点的节点标识,或者所述目标区块链节点所属的区块链节点集合的集合标识。
如前所述,所述方法还包括:通过所述区块链中继通信网络向所述目标区块链节点发送中立性验证请求,使所述目标区块链节点根据接收到的所述中立性验证请求由普通模式切换至中立性验证模式,以针对所述中立性验证消息进行响应。
在图1所示的实施例中,已经对源区块链节点与目标区块链节点之间的交互过程进行了详细描述,图3所示的实施例在源区块链节点的角度对该交互过程所涉及的内容进行了描述,相关细节与解释均可以参考前述的交互过程,此处不再赘述。
图4是一示例性实施例提供的一种基于目标区块链节点侧的区块链中继通信网络的中立性验证方法的流程图。如图4所示,该方法可以包括:步骤402,接收源区块链节点通过区块链中继通信网络发送的中立性验证消息,所述中立性验证消息包括由第一对称密钥对第一消息内容进行加密生成的第一加密后消息内容和由所述源区块链节点的身份私钥为所述第一加密后消息内容生成的数字签名,所述第一消息内容包含中立性验证消息类型标识;步骤404,根据所述源区块链节点的身份公钥对接收到的交互消息所含的数字签名进行验签,以及用所述第一对称密钥对所述交互消息所含的加密后消息内容进行解密,并在验签成功且解密得到的消息内容中包含所述中立性验证消息类型标识的情况下通过所述区块链中继通信网络向所述源区块链节点返回接收确认消息,使所述源区块链节点根据所述中立性验证消息的发送时刻和所述接收确认消息的接收时刻计算所述区块链中继通信网络的往返时延;步骤406,针对在预设时间段内接收到且由所述源区块链节点的身份公钥验签成功的交互消息进行数据量统计,得到接收数据量,使所述源区块链节点将所述接收数据量与自身在所述预设时间段内通过所述区块链中继通信网络向所述目标区块链节点所发出的交互消息的发送数据量进行比较。其中,判定所述区块链中继通信网络具有中立性的条件包括:所述往返时延匹配于所述源区块链节点与所述目标区块链节点之间的实际环境,且所述接收数据量与所述发送数据量一致。
如前所述,所述方法还包括:接收所述源区块链节点通过所述区块链中继通信网络发送的密钥分发消息,所述密钥分发消息中包含由所述目标区块链节点的身份公钥对所述第一对称密钥进行加密后的密钥密文,以及由所述源区块链节点的身份私钥为所述密钥密文生成的数字签名;根据所述源区块链节点的身份公钥对所述密钥分发消息中的数字签名进行验签,以及用自身的身份私钥对所述密钥密文进行解密,并在验签成功的情况下将解密得到的对称密钥确定为所述第一对称密钥。
如前所述,所述源区块链节点、所述目标区块链节点的身份公私钥对包括下述任一:所述源区块链节点、所述目标区块链节点的链上节点身份公私钥对;所述源区块链节点与所述目标区块链节点通过所述区块链中继通信网络协商的动态身份公私钥对。
如前所述,所述接收确认消息包括由第二对称密钥对第二消息内容进行加密生成的第二加密后消息内容和由所述目标区块链节点的身份私钥为所述第二加密后消息内容生成的数字签名,所述第二消息内容包含接收确认消息类型标识;所述接收确认消息用于使所述源区块链节点:根据所述目标区块链节点的身份公钥对接收到的交互消息所含的数字签名进行验签,以及用所述第二对称密钥对所述交互消息所含的加密后消息内容进行解密,并在验签成功且解密得到的消息内容中包含所述接收确认消息类型标识的情况下,将该交互消息的接收时刻确认为所述接收确认消息的接收时刻。
如前所述,接收所述源区块链节点通过区块链中继通信网络发送的中立性验证消息, 包括:接收所述源区块链节点通过所述区块链中继通信网络发送的多条中立性验证消息;所述源区块链节点根据所述中立性验证消息的发送时刻和所述接收确认消息的接收时刻计算所述区块链中继通信网络的往返时延,包括:所述源区块链节点计算所述多条中立性验证消息的平均往返时延,以作为所述区块链中继通信网络的往返时延。
如前所述,所述多条中立性验证消息由所述源区块链节点在所述预设时间段内周期性发送。
如前所述,所述中立性验证消息中包含接收方节点指示信息;所述接收方节点指示信息包括所述目标区块链节点的节点标识,或者所述目标区块链节点所属的区块链节点集合的集合标识。
如前所述,所述方法还包括:接收所述源区块链节点通过所述区块链中继通信网络发送的中立性验证请求;根据接收到的所述中立性验证请求由普通模式切换至中立性验证模式,以针对所述中立性验证消息进行响应。
在图1所示的实施例中,已经对源区块链节点与目标区块链节点之间的交互过程进行了详细描述,图4所示的实施例在目标区块链节点的角度对该交互过程所涉及的内容进行了描述,相关细节与解释均可以参考前述的交互过程,此处不再赘述。
下面以如图2所示的区块链节点Node A、Node B为例,结合图5对本说明书的中立性验证方案进行说明。图5是一示例性实施例提供的一种中立性验证的交互流程图。如图5所示,假定Node A希望对自身所接入的区块链中继通信网络进行中立性验证,NodeB为已接入该区块链中继通信网络的其他任一区块链节点,并由该NodeB配合NodeA完成验证过程。在下述交互过程中,NodeA与NodeB之间的交互均是通过区块链中继通信网络而实现,则区块链节点Node A和Node B之间的交互过程可以包括以下步骤。
步骤501,Node A向NodeB分发private_key。
Node A可以通过相关技术中的任意密钥生成算法,生成一对称密钥,以作为上述的private_key。当然,该private_key可以是Node A希望进行密钥分发时临时生成,也可以由Node A在先前已经生成的密钥集合中进行选取,本说明书并不对此进行限制。
Node A可以通过向NodeB发送密钥分发消息来完成密钥分发,该密钥分发消息比如可以为下述的PrivateKeyMsg。例如,Node A确定向Node B分发上述的private_key后,可以从自身维护的区块链节点列表中获取Node B的链上节点身份公钥Pub_key_B,并通过Pub_key_B对private_key进行非对称加密,得到相应的密钥密文enc_private_key。为了防范中间人攻击,Node A可以通过自身的链上节点身份私钥Pri_key_A对enc_private_key进行签名,生成相应的数字签名enc_private_key_sign。另外,Node A还可以为本次分发的private_key确定相应的版本号private_key_ver,以区分于Node A分发过的其他密钥。需要指出的是:除了通过Node A、Node B的链上节点身份信息进行加解密和签名验签之外,还可以通过其他的公私钥对来实现,比如由Node A与Node B协商的动态公私钥对等,本说明书并不对此进行限制。
基于上述信息,Node A可以生成中立性验证消息PrivateKeyMsg,该PrivateKeyMsg可以包含下述字段:
struct PrivateKeyMsg{
Bytesnode_id_from;//发送该消息的节点ID
Bytesnode_id_to;//接收该消息的节点ID
Bytes encrypted_symetric_private_key;//密钥密文
Bytes enc_private_key_sign;//对密钥密文的签名
Intprivate_key_ver;//密钥版本号
}
其中,node_id_from字段用于填写Node A的节点ID,node_id_to字段用于填写Node B的节点ID。encrypted_symetric_private_key字段用于填写密钥密文,即上述的enc_private_key。enc_private_key_sign字段用于填写针对密钥密文的数字签名。private_key_ver字段用于填写密钥private_key的版本号。
Node A将PrivateKeyMsg通过区块链中继通信网络发送至Node B。Node A首先将PrivateKeyMsg发送至自身所连接的中继节点a,并由中继节点a基于路由策略直接或间接将PrivateKeyMsg发送至中继节点b,进而由中继节点b将PrivateKeyMsg发送至Node B。由于enc_private_key始终处于密文状态,且只有Node B维护有解密密钥(Node B的链上节点身份私钥Pri_key_B),因而中继节点a、中继节点b和区块链中继通信网络 中的其他中继节点都无法获知明文的private_key。
相应的,Node B对PrivateKeyMsg中的enc_private_key_sign进行验签、对enc_private_key进行解密。例如,Node B在接收到PrivateKeyMsg后,根据node_id_from字段中提取的节点ID,从自身维护的区块链节点列表中获取该节点ID对应的链上节点身份公钥,以用于对enc_private_key_sign进行验签。如果PrivateKeyMsg的传输过程无异常,Node B将从node_id_from字段中提取到Node A的节点ID,并进而获取其链上节点身份公钥Pub_key_A,然后根据该Pub_key_A和PrivateKeyMsg中的enc_private_key对enc_private_key_sign进行验签。
Node B可以在验签的过程中,同时根据自身的链上节点身份私钥Pri_key_B对enc_private_key进行解密。Node B也可以在验签成功的情况下才执行解密操作,本说明书并不对此进行限制。当然,即便是并行实施验签和解密,Node B也仅在验签成功的情况下,才会认可解密得到的private_key。
Node B在对enc_private_key_sign验签成功的情况下,确定解密获得的private_key为Node A所分发的对称密钥,并将该private_key关联至Node A。例如,Node B可以将该private_key、private_key_ver与Node A的节点ID进行关联存储。以及,Node B通过区块链中继通信网络向Node A返回PrivateKeyRespMsg消息,向Node A表明自己已经成功获得所分发的密钥private_key。其中,PrivateKeyRespMsg可以包含下述字段:
struct PrivateKeyRespMsg{
Bytesnode_id_from;//发送该消息的节点ID
Bytesnode_id_to;//接收该消息的节点ID
Bytes node_id_from_sign;//对发送该消息的节点ID的签名
Int private_key_ver;//密钥版本号
}
其中,node_id_from字段用于填写Node B的节点ID,node_id_to字段用于填写Node A的节点ID。node_id_from_sign为Node B通过自身的链上节点身份私钥Pri_key_B对node_id_from字段的内容(即Node B的节点ID)进行签名操作而生成的数字签名。private_key_ver字段为Node B所记录的private_key的版本号信息。
Node B首先将PrivateKeyRespMsg发送至自身所连接的中继节点b,并由中继节点b基于路由策略直接或间接将PrivateKeyRespMsg发送至中继节点a,进而由中继节点a将PrivateKeyRespMsg发送至Node A。
Node A在接收到PrivateKeyRespMsg后,根据node_id_from字段中提取的节点ID,从自身维护的区块链节点列表中获取该节点ID对应的链上节点身份公钥,以用于对node_id_from_sign进行验签。如果PrivateKeyRespMsg的传输过程无异常,Node A将从node_id_from字段中提取到Node B的节点ID,并进而获取其链上节点身份公钥Pub_key_B,然后根据该Pub_key_B和PrivateKeyRespMsg中的node_id_from对node_id_from_sign进行验签。在验签成功的情况下,Node A可以确定该PrivateKeyRespMsg来自Node B,从而确定private_key已经成功分发至Node B。
步骤502a,Node A记录发送数据量和发送时刻。
步骤502b,Node A向Node B发送中立性验证消息。
其中,步骤502a与步骤502b之间的先后顺序可以对调,而并不影响方案的实施。
假定Node A希望对区块链中继通信网络进行中立性验证,Node A和Node B可以切换至中立性验证模式,使得Node A和Node B可以执行与中立性验证相关的操作。例如,Node A生成中立性验证消息NeutralVerifyMsg,譬如可以包含下述字段:
struct NeutralVerifyMsg{
Bytesnode_id_from;//发送该消息的节点ID
Bytesnode_id_to;//接收该消息的节点ID
Bytes encrypted_raw_data;//使用对称密钥对消息内容进行加密后的密文数据
Bytes encrypted_raw_data_sign;//对密文数据的签名
}
其中,node_id_from字段用于填写Node A的节点ID,node_id_to字段用于填写Node B的节点ID。encrypted_raw_data字段用于填写加密后消息内容enc_raw_data,encrypted_raw_data_sign为针对加密后消息内容enc_raw_data的签名。
在生成上述NeutralVerifyMsg时,Node A首先获取明文的消息内容raw_data,该消息内容raw_data至少包含中立性验证消息类型标识。然后,Node A可以通过前述的对 称密钥private_key对该消息内容raw_data进行加密,以生成上述的加密后消息内容enc_raw_data。进一步地,Node A利用自身的身份私钥对该加密后消息内容enc_raw_data进行签名,生成相应的数字签名encrypted_raw_data_sign。
Node A记录的发送时刻,即为Node A将NeutralVerifyMsg发出的时刻。Node A记录的发送数据量,可以为Node A在预设时间段内向Node B发送的所有交互消息的数据量之和,这里的交互消息既包括上述的NeutralVerifyMsg,也包括共识消息、区块同步消息等其他类型的业务消息,可以确保统计出的发送数据量足够大而具有可比性。
Node A对于发送数据量的记录是持续性的。因此,Node A记录发送数据量的动作,并不仅是针对NeutralVerifyMsg的数据量进行记录,而是指针对上述预设时间段内的所有交互消息的数据量进行累计,直至最终得到该预设时间段内所有交互消息的数据量之和。
步骤503,Node B对接收到的交互消息进行验签、解密。
Node B从区块链中继通信网络中接收到交互消息时,由于该交互消息的消息内容处于加密状态,因而无法直接确定该交互消息是否为NeutralVerifyMsg。同时,虽然node_id_from字段包含Node A的节点标识,但是Node B需要对此进行验证。
因此,Node B首先获取Node A的身份公钥,并通过该身份公钥来验证交互消息中所含的数字签名encrypted_raw_data_sign。如果验证成功,则Node B可以确认该交互消息来自Node A,且该交互消息的内容完整、无误。进而,Node B根据前述的对称密钥private_key对加密后消息内容enc_raw_data进行解密:如果解密成功,且解密得到的消息内容中包含前述的中立性验证消息类型标识,则Node B确认该交互消息为中立性验证消息。结合验签和解密的结果,Node B可以确认接收到的交互消息是否为Node A发送的NeutralVerifyMsg。
步骤504a,Node B向Node A发送接收确认消息。
步骤504b,Node B统计接收数据量。
其中,步骤504a与步骤504b之间的先后顺序可以对调,而并不影响方案的实施。
Node B在确定接收到来自Node A的NeutralVerifyMsg后,可以立即向Node A返回接收确认消息NeutralVerifyRespMsg,譬如可以包含下述字段:
struct NeutralVerifyRespMsg{
Bytesnode_id_from;//发送该消息的节点ID
Bytesnode_id_to;//接收该消息的节点ID
Bytes encrypted_raw_data_Resp;//使用对称密钥对消息内容进行加密后的密文数据
Bytes encrypted_raw_data_Resp_sign;//对密文数据的签名
}
其中,node_id_from字段用于填写Node B的节点ID,node_id_to字段用于填写Node A的节点ID。encrypted_raw_data_Resp字段用于填写加密后消息内容enc_raw_data_Resp,encrypted_raw_data_Resp_sign为针对加密后消息内容enc_raw_data_Resp的签名。
在生成上述NeutralVerifyRespMsg时,Node B首先获取明文的消息内容raw_data_Resp,该消息内容raw_data_Resp至少包含接收确认消息类型标识。然后,Node B可以通过前述的对称密钥private_key对该消息内容raw_data_Resp进行加密,以生成上述的加密后消息内容enc_raw_data_Resp。进一步地,Node B利用自身的身份私钥对该加密后消息内容enc_raw_data_Resp进行签名,生成相应的数字签名encrypted_raw_data_Resp_sign。
Node A从区块链中继通信网络中接收到交互消息时,由于该交互消息的消息内容处于加密状态,因而无法直接确定该交互消息是否为NeutralVerifyRespMsg。同时,虽然node_id_from字段包含Node B的节点标识,但是Node A需要对此进行验证。因此,Node A首先获取Node B的身份公钥,并通过该身份公钥来验证交互消息中所含的数字签名encrypted_raw_data_Resp_sign。如果验证成功,则Node A可以确认该交互消息来自Node B,且该交互消息的内容完整、无误。进而,Node A根据前述的对称密钥private_key对加密后消息内容enc_raw_data_Resp进行解密:如果解密成功,且解密得到的消息内容中包含前述的接收确认消息类型标识,则Node A确认该交互消息为接收确认消息。结合验签和解密的结果,Node A可以确认接收到的交互消息是否为Node B发送的NeutralVerifyRespMsg。
在确认接收到来自Node B的NeutralVerifyRespMsg后,Node A确认对该 NeutralVerifyRespMsg的接收时刻。实际上,Node A可以在接收到每条交互消息时都分别记录其相应的接收时刻,然后在通过验签和解密操作确认出某一交互消息为NeutralVerifyRespMsg时,确认该NeutralVerifyRespMsg对应的接收时刻。
Node B记录的发送数据量,可以为Node B在预设时间段内接收到来自Node A的所有交互消息的数据量之和,这里的交互消息既包括上述的NeutralVerifyMsg,也包括共识消息、区块同步消息等其他类型的业务消息,可以确保统计出的发送数据量足够大而具有可比性。Node B对于发送数据量的记录是持续性的。因此,Node B记录发送数据量的动作,并不仅是针对NeutralVerifyMsg的数据量进行记录,而是指针对上述预设时间段内的所有交互消息的数据量进行累计,直至最终得到该预设时间段内所有交互消息的数据量之和。
步骤505,Node B向Node A发送接收数据量。
步骤506,Node A计算RTT、比较数据量。
Node B可以在上述的预设时间段结束之后的任意时刻,将统计得到的接收数据量发送至Node A。当然,也可以由Node A向Node B发起获取请求,使得Node B响应于该获取请求而返回上述的接收数据量。因此,在一些情况下,步骤506中由Node A计算RTT的步骤可能早于步骤505,可以根据实际情况进行调整。
如前所述,Node A可以统计自身在预设时间段内所发交互消息的发送数据量。同时,Node A可以通过步骤505获取Node B统计得到的接收数据量。因此,Node A可以将该发送数据量与接收数据量进行比较:如果两者一致,则表明区块链中继通信网络在消息传输过程中没有丢弃数据;否则,表明区块链中继通信网络存在丢弃数据的情况,判定其不具有中立性。其中,可以在发送数据量与接收数据量完全相同的情况下,判定两者一致;或者,可以在发送数据量与接收数据量之间的差值不大于预设数值的情况下,判定两者一致,可以根据实际需求进行设定。
Node A根据前文所述的发送时刻和接收时刻之间的差值,可以确定区块链中继通信网络在针对NeutralVerifyMsg和NeutralVerifyRespMsg进行传输时所形成的RTT。如果Node A在预设时间段内发送了多条NeutralVerifyMsg,那么Node A可以获得多组发送时刻和接收时刻,并且可以将这些时刻数据计算得到的RTT进行均值计算,以作为最终区块链中继通信网络的RTT。当RTT的数值不大于预设时延时,Node A可以确定区块链中继通信网络的时延具有合理性;否则,表明区块链中继通信网络存在故意延迟消息传输的情况,判定其不具有中立性。
此外,通过采用加解密技术可以确保区块链中继通信网络无法获知消息内容、避免舞弊,且通过采用数字签名技术可以确保Node B准确识别来自Node A的交互消息,并验证消息传输过程中是否存在缺失、替换等问题,从而保证了数据隐私性和数据正确性。
综上所述,通过本说明书的技术方案,区块链节点可以从数据隐私性、数据正确性、数据完整性和时延合理性等多个维度对区块链中继通信网络进行验证,从而能够全面合理地确定出区块链中继通信网络的中立性。
图6是一示例性实施例提供的一种区块链中继通信网络的中立性验证系统的示意图。如图6所示,该系统可以包括:源区块链节点601和目标区块链节点602;其中:所述源区块链节点601可以通过区块链中继通信网络向所述目标区块链节点602发送中立性验证消息,所述中立性验证消息包括由第一对称密钥对第一消息内容进行加密生成的第一加密后消息内容和由所述源区块链节点601的身份私钥为所述第一加密后消息内容生成的数字签名,所述第一消息内容包含中立性验证消息类型标识;所述目标区块链节点602可以根据所述源区块链节点601的身份公钥对接收到的交互消息所含的数字签名进行验签,以及用所述第一对称密钥对所述交互消息所含的加密后消息内容进行解密,并在验签成功且解密得到的消息内容中包含所述中立性验证消息类型标识的情况下通过所述区块链中继通信网络向所述源区块链节点601返回接收确认消息;以及,所述目标区块链节点602可以针对在预设时间段内接收到且由所述源区块链节点601的身份公钥验签成功的交互消息进行数据量统计,得到接收数据量;所述源区块链节点601可以根据所述中立性验证消息的发送时刻和所述接收确认消息的接收时刻计算所述区块链中继通信网络的往返时延,以及将所述接收数据量与自身在所述预设时间段内通过所述区块链中继通信网络向所述目标区块链节点602所发出的交互消息的发送数据量进行比较。其中,判定所述区块链中继通信网络具有中立性的条件包括:所述往返时延匹配于所述源区块链节点601与所述目标区块链节点602之间的实际环境,且所述接收数据量与所述发送数据量一致。
可选的,所述源区块链节点601可以通过所述区块链中继通信网络向所述目标区块链节点602发送密钥分发消息,所述密钥分发消息中包含由所述目标区块链节点602的身份公钥对所述第一对称密钥进行加密后的密钥密文,以及由所述源区块链节点601的身份私钥为所述密钥密文生成的数字签名;所述目标区块链节点602接收到所述密钥分发消息后,可以根据所述源区块链节点601的身份公钥对所述密钥分发消息中的数字签名进行验签,以及用自身的身份私钥对所述密钥密文进行解密,并在验签成功的情况下将解密得到的对称密钥确定为所述第一对称密钥。
可选的,所述源区块链节点601、所述目标区块链节点602的身份公私钥对包括下述任一:所述源区块链节点601、所述目标区块链节点602的链上节点身份公私钥对;所述源区块链节点601与所述目标区块链节点602通过所述区块链中继通信网络协商的动态身份公私钥对。
可选的,所述接收确认消息包括由第二对称密钥对第二消息内容进行加密生成的第二加密后消息内容和由所述目标区块链节点602的身份私钥为所述第二加密后消息内容生成的数字签名,所述第二消息内容包含接收确认消息类型标识;所述源区块链节点601可以根据所述目标区块链节点602的身份公钥对接收到的交互消息所含的数字签名进行验签,以及用所述第二对称密钥对所述交互消息所含的加密后消息内容进行解密,并在验签成功且解密得到的消息内容中包含所述接收确认消息类型标识的情况下,将该交互消息的接收时刻确认为所述接收确认消息的接收时刻。
可选的,所述源区块链节点601可以通过区块链中继通信网络向目标区块链节点602发送中立性验证消息,包括:所述源区块链节点601通过所述区块链中继通信网络向所述目标区块链节点602发送多条中立性验证消息;所述源区块链节点601可以根据所述中立性验证消息的发送时刻和所述接收确认消息的接收时刻计算所述区块链中继通信网络的往返时延,包括:所述源区块链节点601计算所述多条中立性验证消息的平均往返时延,以作为所述区块链中继通信网络的往返时延。
可选的,所述多条中立性验证消息由所述源区块链节点601在所述预设时间段内周期性发送。
可选的,所述中立性验证消息中包含接收方节点指示信息;所述接收方节点指示信息包括所述目标区块链节点602的节点标识,或者所述目标区块链节点602所属的区块链节点集合的集合标识。
可选的:所述源区块链节点601可以通过所述区块链中继通信网络向所述目标区块链节点602发送中立性验证请求;所述目标区块链节点602可以根据接收到的所述中立性验证请求由普通模式切换至中立性验证模式,以针对所述中立性验证消息进行响应。
图7是一示例性实施例提供的一种设备的示意结构图。请参考图7,在硬件层面,该设备包括处理器702、内部总线704、网络接口706、内存708以及非易失性存储器710,当然还可能包括其他业务所需要的硬件。本说明书实施例可以基于软件方式来实现,比如由处理器702从非易失性存储器710中读取对应的计算机程序到内存708中然后运行。当然,除了软件实现方式之外,本说明书实施例并不排除其他实现方式,比如逻辑器件抑或软硬件结合的方式等等,也就是说以下处理流程的执行主体并不限定于各个逻辑单元,也可以是硬件或逻辑器件。
请参考图8,区块链中继通信网络的中立性验证装置可以应用于如图7所示的设备中,譬如该设备可以为源区块链节点,以实现本说明书的技术方案。其中,该区块链中继通信网络的中立性验证装置可以包括:获取单元801,用于获取中立性验证消息,所述中立性验证消息包括由第一对称密钥对第一消息内容进行加密生成的第一加密后消息内容和由所述源区块链节点的身份私钥为所述第一加密后消息内容生成的数字签名,所述第一消息内容包含中立性验证消息类型标识;发送单元802,用于通过区块链中继通信网络向目标区块链节点发送所述中立性验证消息,使所述目标区块链节点:根据所述源区块链节点的身份公钥对接收到的交互消息所含的数字签名进行验签,以及用所述第一对称密钥对所述交互消息所含的加密后消息内容进行解密,并在验签成功且解密得到的消息内容中包含所述中立性验证消息类型标识的情况下通过所述区块链中继通信网络向所述源区块链节点返回接收确认消息;以及,针对在预设时间段内接收到且由所述源区块链节点的身份公钥验签成功的交互消息进行数据量统计,得到接收数据量;处理单元803,用于根据所述中立性验证消息的发送时刻和所述接收确认消息的接收时刻计算所述区块链中继通信网络的往返时延,以及将所述接收数据量与自身在所述预设时间段内通过所述区块链中继通信网络向所述目标区块链节点所发出的交互消息的发送 数据量进行比较。其中,判定所述区块链中继通信网络具有中立性的条件包括:所述往返时延匹配于所述源区块链节点与所述目标区块链节点之间的实际环境,且所述接收数据量与所述发送数据量一致。
可选的,所述获取单元801还用于:获取密钥分发消息,所述密钥分发消息中包含由所述目标区块链节点的身份公钥对所述第一对称密钥进行加密后的密钥密文,以及由所述源区块链节点的身份私钥为所述密钥密文生成的数字签名;所述发送单元802还用于:通过所述区块链中继通信网络向所述目标区块链节点发送所述密钥分发消息,使所述目标区块链节点:接收到所述密钥分发消息后,根据所述源区块链节点的身份公钥对所述密钥分发消息中的数字签名进行验签,以及用自身的身份私钥对所述密钥密文进行解密,并在验签成功的情况下将解密得到的对称密钥确定为所述第一对称密钥。
可选的,所述源区块链节点、所述目标区块链节点的身份公私钥对包括下述任一:所述源区块链节点、所述目标区块链节点的链上节点身份公私钥对;所述源区块链节点与所述目标区块链节点通过所述区块链中继通信网络协商的动态身份公私钥对。
可选的,所述接收确认消息包括由第二对称密钥对第二消息内容进行加密生成的第二加密后消息内容和由所述目标区块链节点的身份私钥为所述第二加密后消息内容生成的数字签名,所述第二消息内容包含接收确认消息类型标识;所述装置还包括:所述处理单元803还用于:根据所述目标区块链节点的身份公钥对接收到的交互消息所含的数字签名进行验签,以及用所述第二对称密钥对所述交互消息所含的加密后消息内容进行解密,并在验签成功且解密得到的消息内容中包含所述接收确认消息类型标识的情况下,将该交互消息的接收时刻确认为所述接收确认消息的接收时刻。
可选的,所述通过区块链中继通信网络向目标区块链节点发送中立性验证消息,包括:通过所述区块链中继通信网络向所述目标区块链节点发送多条中立性验证消息;所述根据所述中立性验证消息的发送时刻和所述接收确认消息的接收时刻计算所述区块链中继通信网络的往返时延,包括:计算所述多条中立性验证消息的平均往返时延,以作为所述区块链中继通信网络的往返时延。
可选的,所述多条中立性验证消息由所述源区块链节点在所述预设时间段内周期性发送。
可选的,所述中立性验证消息中包含接收方节点指示信息;所述接收方节点指示信息包括所述目标区块链节点的节点标识,或者所述目标区块链节点所属的区块链节点集合的集合标识。
可选的,所述发送单元802还用于:通过所述区块链中继通信网络向所述目标区块链节点发送中立性验证请求,使所述目标区块链节点根据接收到的所述中立性验证请求由普通模式切换至中立性验证模式,以针对所述中立性验证消息进行响应。
请参考图9,区块链中继通信网络的中立性验证装置可以应用于如图7所示的设备中,譬如该设备可以为目标区块链节点,以实现本说明书的技术方案。其中,该区块链中继通信网络的中立性验证装置可以包括:消息接收单元901,用于接收源区块链节点通过区块链中继通信网络发送的中立性验证消息,所述中立性验证消息包括由第一对称密钥对第一消息内容进行加密生成的第一加密后消息内容和由所述源区块链节点的身份私钥为所述第一加密后消息内容生成的数字签名,所述第一消息内容包含中立性验证消息类型标识;消息处理单元902,用于根据所述源区块链节点的身份公钥对接收到的交互消息所含的数字签名进行验签,以及用所述第一对称密钥对所述交互消息所含的加密后消息内容进行解密,并在验签成功且解密得到的消息内容中包含所述中立性验证消息类型标识的情况下通过所述区块链中继通信网络向所述源区块链节点返回接收确认消息,使所述源区块链节点根据所述中立性验证消息的发送时刻和所述接收确认消息的接收时刻计算所述区块链中继通信网络的往返时延;数据量统计单元903,用于针对在预设时间段内接收到且由所述源区块链节点的身份公钥验签成功的交互消息进行数据量统计,得到接收数据量,使所述源区块链节点将所述接收数据量与自身在所述预设时间段内通过所述区块链中继通信网络向所述目标区块链节点所发出的交互消息的发送数据量进行比较。其中,判定所述区块链中继通信网络具有中立性的条件包括:所述往返时延匹配于所述源区块链节点与所述目标区块链节点之间的实际环境,且所述接收数据量与所述发送数据量一致。
可选的,所述消息接收单元901还用于:接收所述源区块链节点通过所述区块链中继通信网络发送的密钥分发消息,所述密钥分发消息中包含由所述目标区块链节点的身份公钥对所述第一对称密钥进行加密后的密钥密文,以及由所述源区块链节点的身份私 钥为所述密钥密文生成的数字签名;所述消息处理单元902还用于:根据所述源区块链节点的身份公钥对所述密钥分发消息中的数字签名进行验签,以及用自身的身份私钥对所述密钥密文进行解密,并在验签成功的情况下将解密得到的对称密钥确定为所述第一对称密钥。
可选的,所述源区块链节点、所述目标区块链节点的身份公私钥对包括下述任一:所述源区块链节点、所述目标区块链节点的链上节点身份公私钥对;所述源区块链节点与所述目标区块链节点通过所述区块链中继通信网络协商的动态身份公私钥对。
可选的,所述接收确认消息包括由第二对称密钥对第二消息内容进行加密生成的第二加密后消息内容和由所述目标区块链节点的身份私钥为所述第二加密后消息内容生成的数字签名,所述第二消息内容包含接收确认消息类型标识;所述接收确认消息用于使所述源区块链节点:根据所述目标区块链节点的身份公钥对接收到的交互消息所含的数字签名进行验签,以及用所述第二对称密钥对所述交互消息所含的加密后消息内容进行解密,并在验签成功且解密得到的消息内容中包含所述接收确认消息类型标识的情况下,将该交互消息的接收时刻确认为所述接收确认消息的接收时刻。
可选的,所述消息接收单元901具体用于:接收所述源区块链节点通过所述区块链中继通信网络发送的多条中立性验证消息;所述消息处理单元902具体用于:根据所述中立性验证消息的发送时刻和所述接收确认消息的接收时刻计算所述区块链中继通信网络的往返时延,包括:所述源区块链节点计算所述多条中立性验证消息的平均往返时延,以作为所述区块链中继通信网络的往返时延。
可选的,所述多条中立性验证消息由所述源区块链节点在所述预设时间段内周期性发送。可选的,所述中立性验证消息中包含接收方节点指示信息;所述接收方节点指示信息包括所述目标区块链节点的节点标识,或者所述目标区块链节点所属的区块链节点集合的集合标识。
可选的,所述消息接收单元901还用于接收所述源区块链节点通过所述区块链中继通信网络发送的中立性验证请求;所述消息处理单元902还用于根据接收到的所述中立性验证请求由普通模式切换至中立性验证模式,以针对所述中立性验证消息进行响应。
上述实施例阐明的系统、装置、模块或单元,具体可以由计算机芯片或实体实现,或者由具有某种功能的产品来实现。一种典型的实现设备为计算机,计算机的具体形式可以是个人计算机、膝上型计算机、蜂窝电话、相机电话、智能电话、个人数字助理、媒体播放器、导航设备、电子邮件收发设备、游戏控制台、平板计算机、可穿戴设备或者这些设备中的任意几种设备的组合。
在一个典型的配置中,计算机包括一个或多个处理器(CPU)、输入/输出接口、网络接口和内存。
内存可能包括计算机可读介质中的非永久性存储器,随机存取存储器(RAM)和/或非易失性内存等形式,如只读存储器(ROM)或闪存(flash RAM)。内存是计算机可读介质的示例。
计算机可读介质包括永久性和非永久性、可移动和非可移动媒体可以由任何方法或技术来实现信息存储。信息可以是计算机可读指令、数据结构、程序的模块或其他数据。计算机的存储介质的例子包括,但不限于相变内存(PRAM)、静态随机存取存储器(SRAM)、动态随机存取存储器(DRAM)、其他类型的随机存取存储器(RAM)、只读存储器(ROM)、电可擦除可编程只读存储器(EEPROM)、快闪记忆体或其他内存技术、只读光盘只读存储器(CD-ROM)、数字多功能光盘(DVD)或其他光学存储、磁盒式磁带、磁盘存储、量子存储器、基于石墨烯的存储介质或其他磁性存储设备或任何其他非传输介质,可用于存储可以被计算设备访问的信息。按照本文中的界定,计算机可读介质不包括暂存电脑可读媒体(transitory media),如调制的数据信号和载波。
还需要说明的是,术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含,从而使得包括一系列要素的过程、方法、商品或者设备不仅包括那些要素,而且还包括没有明确列出的其他要素,或者是还包括为这种过程、方法、商品或者设备所固有的要素。在没有更多限制的情况下,由语句“包括一个……”限定的要素,并不排除在包括所述要素的过程、方法、商品或者设备中还存在另外的相同要素。
上述对本说明书特定实施例进行了描述。其它实施例在所附权利要求书的范围内。在一些情况下,在权利要求书中记载的动作或步骤可以按照不同于实施例中的顺序来执行并且仍然可以实现期望的结果。另外,在附图中描绘的过程不一定要求示出的特定顺序或者连续顺序才能实现期望的结果。在某些实施方式中,多任务处理和并行处理也是 可以的或者可能是有利的。
在本说明书实施例使用的术语是仅仅出于描述特定实施例的目的,而非旨在限制本说明书实施例。在本说明书实施例和所附权利要求书中所使用的单数形式的“一种”、“所述”和“该”也旨在包括多数形式,除非上下文清楚地表示其他含义。还应当理解,本文中使用的术语“和/或”是指并包含相关联的列出项目的任何或所有可能组合。
应当理解,尽管在本说明书实施例可能采用术语第一、第二、第三等来描述各种信息,但这些信息不应限于这些术语。这些术语仅用来将同一类型的信息彼此区分开。例如,在不脱离本说明书实施例范围的情况下,第一信息也可以被称为第二信息,类似地,第二信息也可以被称为第一信息。取决于语境,如在此所使用的词语“如果”可以被解释成为“在……时”或“当……时”或“响应于确定”。
以上所述仅为本说明书实施例的较佳实施例而已,并不用以限制本说明书实施例,凡在本说明书实施例的精神和原则之内,所做的任何修改、等同替换、改进等,均应包含在本说明书实施例保护的范围之内。

Claims (29)

  1. 一种区块链中继通信网络的中立性验证方法,包括:
    源区块链节点通过区块链中继通信网络向目标区块链节点发送中立性验证消息,所述中立性验证消息包括由第一对称密钥对第一消息内容进行加密生成的第一加密后消息内容和由所述源区块链节点的身份私钥为所述第一加密后消息内容生成的数字签名,所述第一消息内容包含中立性验证消息类型标识;
    所述目标区块链节点根据所述源区块链节点的身份公钥对接收到的交互消息所含的数字签名进行验签,以及用所述第一对称密钥对所述交互消息所含的加密后消息内容进行解密,并在验签成功且解密得到的消息内容中包含所述中立性验证消息类型标识的情况下通过所述区块链中继通信网络向所述源区块链节点返回接收确认消息;以及,所述目标区块链节点针对在预设时间段内接收到且由所述源区块链节点的身份公钥验签成功的交互消息进行数据量统计,得到接收数据量;
    所述源区块链节点根据所述中立性验证消息的发送时刻和所述接收确认消息的接收时刻计算所述区块链中继通信网络的往返时延,以及将所述接收数据量与自身在所述预设时间段内通过所述区块链中继通信网络向所述目标区块链节点所发出的交互消息的发送数据量进行比较;其中,判定所述区块链中继通信网络具有中立性的条件包括所述往返时延匹配于所述源区块链节点与所述目标区块链节点之间的实际环境、且所述接收数据量与所述发送数据量一致。
  2. 根据权利要求1所述的方法,还包括:
    所述源区块链节点通过所述区块链中继通信网络向所述目标区块链节点发送密钥分发消息,所述密钥分发消息中包含由所述目标区块链节点的身份公钥对所述第一对称密钥进行加密后的密钥密文,以及由所述源区块链节点的身份私钥为所述密钥密文生成的数字签名;
    所述目标区块链节点接收到所述密钥分发消息后,根据所述源区块链节点的身份公钥对所述密钥分发消息中的数字签名进行验签,以及用自身的身份私钥对所述密钥密文进行解密,并在验签成功的情况下将解密得到的对称密钥确定为所述第一对称密钥。
  3. 根据权利要求2所述的方法,所述源区块链节点、所述目标区块链节点的身份公私钥对包括下述任一:
    所述源区块链节点、所述目标区块链节点的链上节点身份公私钥对;
    所述源区块链节点与所述目标区块链节点通过所述区块链中继通信网络协商的动态身份公私钥对。
  4. 根据权利要求1所述的方法,所述接收确认消息包括由第二对称密钥对第二消息内容进行加密生成的第二加密后消息内容和由所述目标区块链节点的身份私钥为所述第二加密后消息内容生成的数字签名,所述第二消息内容包含接收确认消息类型标识;
    所述方法还包括:所述源区块链节点根据所述目标区块链节点的身份公钥对接收到的交互消息所含的数字签名进行验签,以及用所述第二对称密钥对所述交互消息所含的加密后消息内容进行解密,并在验签成功且解密得到的消息内容中包含所述接收确认消息类型标识的情况下,将该交互消息的接收时刻确认为所述接收确认消息的接收时刻。
  5. 根据权利要求1所述的方法,
    所述源区块链节点通过区块链中继通信网络向目标区块链节点发送中立性验证消息,包括:所述源区块链节点通过所述区块链中继通信网络向所述目标区块链节点发送多条中立性验证消息;
    所述源区块链节点根据所述中立性验证消息的发送时刻和所述接收确认消息的接收时刻计算所述区块链中继通信网络的往返时延,包括:所述源区块链节点计算所述多条中立性验证消息的平均往返时延,以作为所述区块链中继通信网络的往返时延。
  6. 根据权利要求5所述的方法,所述多条中立性验证消息由所述源区块链节点在所述预设时间段内周期性发送。
  7. 根据权利要求1所述的方法,所述中立性验证消息中包含接收方节点指示信息;所述接收方节点指示信息包括所述目标区块链节点的节点标识,或者所述目标区块链节点所属的区块链节点集合的集合标识。
  8. 根据权利要求1所述的方法,还包括:
    所述源区块链节点通过所述区块链中继通信网络向所述目标区块链节点发送中立性验证请求;
    所述目标区块链节点根据接收到的所述中立性验证请求由普通模式切换至中立性 验证模式,以针对所述中立性验证消息进行响应。
  9. 一种区块链中继通信网络的中立性验证方法,应用于源区块链节点,包括:
    获取中立性验证消息,所述中立性验证消息包括由第一对称密钥对第一消息内容进行加密生成的第一加密后消息内容和由所述源区块链节点的身份私钥为所述第一加密后消息内容生成的数字签名,所述第一消息内容包含中立性验证消息类型标识;
    通过区块链中继通信网络向目标区块链节点发送所述中立性验证消息,使所述目标区块链节点:根据所述源区块链节点的身份公钥对接收到的交互消息所含的数字签名进行验签,以及用所述第一对称密钥对所述交互消息所含的加密后消息内容进行解密,并在验签成功且解密得到的消息内容中包含所述中立性验证消息类型标识的情况下通过所述区块链中继通信网络向所述源区块链节点返回接收确认消息;以及,针对在预设时间段内接收到且由所述源区块链节点的身份公钥验签成功的交互消息进行数据量统计,得到接收数据量;
    根据所述中立性验证消息的发送时刻和所述接收确认消息的接收时刻计算所述区块链中继通信网络的往返时延,以及将所述接收数据量与自身在所述预设时间段内通过所述区块链中继通信网络向所述目标区块链节点所发出的交互消息的发送数据量进行比较;其中,判定所述区块链中继通信网络具有中立性的条件包括所述往返时延匹配于所述源区块链节点与所述目标区块链节点之间的实际环境、且所述接收数据量与所述发送数据量一致。
  10. 根据权利要求9所述的方法,还包括:
    获取密钥分发消息,所述密钥分发消息中包含由所述目标区块链节点的身份公钥对所述第一对称密钥进行加密后的密钥密文,以及由所述源区块链节点的身份私钥为所述密钥密文生成的数字签名;
    通过所述区块链中继通信网络向所述目标区块链节点发送所述密钥分发消息,使所述目标区块链节点:接收到所述密钥分发消息后,根据所述源区块链节点的身份公钥对所述密钥分发消息中的数字签名进行验签,以及用自身的身份私钥对所述密钥密文进行解密,并在验签成功的情况下将解密得到的对称密钥确定为所述第一对称密钥。
  11. 根据权利要求10所述的方法,所述源区块链节点、所述目标区块链节点的身份公私钥对包括下述任一:
    所述源区块链节点、所述目标区块链节点的链上节点身份公私钥对;
    所述源区块链节点与所述目标区块链节点通过所述区块链中继通信网络协商的动态身份公私钥对。
  12. 根据权利要求9所述的方法,所述接收确认消息包括由第二对称密钥对第二消息内容进行加密生成的第二加密后消息内容和由所述目标区块链节点的身份私钥为所述第二加密后消息内容生成的数字签名,所述第二消息内容包含接收确认消息类型标识;
    所述方法还包括:所述源区块链节点根据所述目标区块链节点的身份公钥对接收到的交互消息所含的数字签名进行验签,以及用所述第二对称密钥对所述交互消息所含的加密后消息内容进行解密,并在验签成功且解密得到的消息内容中包含所述接收确认消息类型标识的情况下,将该交互消息的接收时刻确认为所述接收确认消息的接收时刻。
  13. 根据权利要求9所述的方法,
    所述通过区块链中继通信网络向目标区块链节点发送中立性验证消息,包括:通过所述区块链中继通信网络向所述目标区块链节点发送多条中立性验证消息;
    所述根据所述中立性验证消息的发送时刻和所述接收确认消息的接收时刻计算所述区块链中继通信网络的往返时延,包括:计算所述多条中立性验证消息的平均往返时延,以作为所述区块链中继通信网络的往返时延。
  14. 根据权利要求13所述的方法,所述多条中立性验证消息由所述源区块链节点在所述预设时间段内周期性发送。
  15. 根据权利要求9所述的方法,所述中立性验证消息中包含接收方节点指示信息;所述接收方节点指示信息包括所述目标区块链节点的节点标识,或者所述目标区块链节点所属的区块链节点集合的集合标识。
  16. 根据权利要求9所述的方法,还包括:
    通过所述区块链中继通信网络向所述目标区块链节点发送中立性验证请求,使所述目标区块链节点根据接收到的所述中立性验证请求由普通模式切换至中立性验证模式,以针对所述中立性验证消息进行响应。
  17. 一种区块链中继通信网络的中立性验证方法,应用于目标区块链节点,包括:
    接收源区块链节点通过区块链中继通信网络发送的中立性验证消息,所述中立性验证消息包括由第一对称密钥对第一消息内容进行加密生成的第一加密后消息内容和由所述源区块链节点的身份私钥为所述第一加密后消息内容生成的数字签名,所述第一消息内容包含中立性验证消息类型标识;
    根据所述源区块链节点的身份公钥对接收到的交互消息所含的数字签名进行验签,以及用所述第一对称密钥对所述交互消息所含的加密后消息内容进行解密,并在验签成功且解密得到的消息内容中包含所述中立性验证消息类型标识的情况下通过所述区块链中继通信网络向所述源区块链节点返回接收确认消息,使所述源区块链节点根据所述中立性验证消息的发送时刻和所述接收确认消息的接收时刻计算所述区块链中继通信网络的往返时延;
    针对在预设时间段内接收到且由所述源区块链节点的身份公钥验签成功的交互消息进行数据量统计,得到接收数据量,使所述源区块链节点将所述接收数据量与自身在所述预设时间段内通过所述区块链中继通信网络向所述目标区块链节点所发出的交互消息的发送数据量进行比较;其中,判定所述区块链中继通信网络具有中立性的条件包括所述往返时延匹配于所述源区块链节点与所述目标区块链节点之间的实际环境、且所述接收数据量与所述发送数据量一致。
  18. 根据权利要求17所述的方法,还包括:
    接收所述源区块链节点通过所述区块链中继通信网络发送的密钥分发消息,所述密钥分发消息中包含由所述目标区块链节点的身份公钥对所述第一对称密钥进行加密后的密钥密文,以及由所述源区块链节点的身份私钥为所述密钥密文生成的数字签名;
    根据所述源区块链节点的身份公钥对所述密钥分发消息中的数字签名进行验签,以及用自身的身份私钥对所述密钥密文进行解密,并在验签成功的情况下将解密得到的对称密钥确定为所述第一对称密钥。
  19. 根据权利要求18所述的方法,所述源区块链节点、所述目标区块链节点的身份公私钥对包括下述任一:
    所述源区块链节点、所述目标区块链节点的链上节点身份公私钥对;
    所述源区块链节点与所述目标区块链节点通过所述区块链中继通信网络协商的动态身份公私钥对。
  20. 根据权利要求17所述的方法,所述接收确认消息包括由第二对称密钥对第二消息内容进行加密生成的第二加密后消息内容和由所述目标区块链节点的身份私钥为所述第二加密后消息内容生成的数字签名,所述第二消息内容包含接收确认消息类型标识;所述接收确认消息用于使所述源区块链节点:根据所述目标区块链节点的身份公钥对接收到的交互消息所含的数字签名进行验签,以及用所述第二对称密钥对所述交互消息所含的加密后消息内容进行解密,并在验签成功且解密得到的消息内容中包含所述接收确认消息类型标识的情况下,将该交互消息的接收时刻确认为所述接收确认消息的接收时刻。
  21. 根据权利要求17所述的方法,
    接收所述源区块链节点通过区块链中继通信网络发送的中立性验证消息,包括:接收所述源区块链节点通过所述区块链中继通信网络发送的多条中立性验证消息;
    所述源区块链节点根据所述中立性验证消息的发送时刻和所述接收确认消息的接收时刻计算所述区块链中继通信网络的往返时延,包括:所述源区块链节点计算所述多条中立性验证消息的平均往返时延,以作为所述区块链中继通信网络的往返时延。
  22. 根据权利要求21所述的方法,所述多条中立性验证消息由所述源区块链节点在所述预设时间段内周期性发送。
  23. 根据权利要求17所述的方法,所述中立性验证消息中包含接收方节点指示信息;所述接收方节点指示信息包括所述目标区块链节点的节点标识,或者所述目标区块链节点所属的区块链节点集合的集合标识。
  24. 根据权利要求17所述的方法,还包括:
    接收所述源区块链节点通过所述区块链中继通信网络发送的中立性验证请求;
    根据接收到的所述中立性验证请求由普通模式切换至中立性验证模式,以针对所述中立性验证消息进行响应。
  25. 一种区块链中继通信网络的中立性验证系统,包括源区块链节点和目标区块链节点;其中:
    所述源区块链节点通过区块链中继通信网络向所述目标区块链节点发送中立性验 证消息,所述中立性验证消息包括由第一对称密钥对第一消息内容进行加密生成的第一加密后消息内容和由所述源区块链节点的身份私钥为所述第一加密后消息内容生成的数字签名,所述第一消息内容包含中立性验证消息类型标识;
    所述目标区块链节点根据所述源区块链节点的身份公钥对接收到的交互消息所含的数字签名进行验签,以及用所述第一对称密钥对所述交互消息所含的加密后消息内容进行解密,并在验签成功且解密得到的消息内容中包含所述中立性验证消息类型标识的情况下通过所述区块链中继通信网络向所述源区块链节点返回接收确认消息;以及,所述目标区块链节点针对在预设时间段内接收到且由所述源区块链节点的身份公钥验签成功的交互消息进行数据量统计,得到接收数据量;
    所述源区块链节点根据所述中立性验证消息的发送时刻和所述接收确认消息的接收时刻计算所述区块链中继通信网络的往返时延,以及将所述接收数据量与自身在所述预设时间段内通过所述区块链中继通信网络向所述目标区块链节点所发出的交互消息的发送数据量进行比较;其中,判定所述区块链中继通信网络具有中立性的条件包括所述往返时延匹配于所述源区块链节点与所述目标区块链节点之间的实际环境、且所述接收数据量与所述发送数据量一致。
  26. 一种区块链中继通信网络的中立性验证装置,应用于源区块链节点,包括:
    获取单元,用于获取中立性验证消息,所述中立性验证消息包括由第一对称密钥对第一消息内容进行加密生成的第一加密后消息内容和由所述源区块链节点的身份私钥为所述第一加密后消息内容生成的数字签名,所述第一消息内容包含中立性验证消息类型标识;
    发送单元,用于通过区块链中继通信网络向目标区块链节点发送所述中立性验证消息,使所述目标区块链节点:根据所述源区块链节点的身份公钥对接收到的交互消息所含的数字签名进行验签,以及用所述第一对称密钥对所述交互消息所含的加密后消息内容进行解密,并在验签成功且解密得到的消息内容中包含所述中立性验证消息类型标识的情况下通过所述区块链中继通信网络向所述源区块链节点返回接收确认消息;以及,针对在预设时间段内接收到且由所述源区块链节点的身份公钥验签成功的交互消息进行数据量统计,得到接收数据量;
    处理单元,用于根据所述中立性验证消息的发送时刻和所述接收确认消息的接收时刻计算所述区块链中继通信网络的往返时延,以及将所述接收数据量与自身在所述预设时间段内通过所述区块链中继通信网络向所述目标区块链节点所发出的交互消息的发送数据量进行比较;其中,判定所述区块链中继通信网络具有中立性的条件包括所述往返时延匹配于所述源区块链节点与所述目标区块链节点之间的实际环境、且所述接收数据量与所述发送数据量一致。
  27. 一种区块链中继通信网络的中立性验证装置,应用于目标区块链节点,包括:
    消息接收单元,用于接收源区块链节点通过区块链中继通信网络发送的中立性验证消息,所述中立性验证消息包括由第一对称密钥对第一消息内容进行加密生成的第一加密后消息内容和由所述源区块链节点的身份私钥为所述第一加密后消息内容生成的数字签名,所述第一消息内容包含中立性验证消息类型标识;
    消息处理单元,用于根据所述源区块链节点的身份公钥对接收到的交互消息所含的数字签名进行验签,以及用所述第一对称密钥对所述交互消息所含的加密后消息内容进行解密,并在验签成功且解密得到的消息内容中包含所述中立性验证消息类型标识的情况下通过所述区块链中继通信网络向所述源区块链节点返回接收确认消息,使所述源区块链节点根据所述中立性验证消息的发送时刻和所述接收确认消息的接收时刻计算所述区块链中继通信网络的往返时延;
    数据量统计单元,用于针对在预设时间段内接收到且由所述源区块链节点的身份公钥验签成功的交互消息进行数据量统计,得到接收数据量,使所述源区块链节点将所述接收数据量与自身在所述预设时间段内通过所述区块链中继通信网络向所述目标区块链节点所发出的交互消息的发送数据量进行比较;其中,判定所述区块链中继通信网络具有中立性的条件包括所述往返时延匹配于所述源区块链节点与所述目标区块链节点之间的实际环境、且所述接收数据量与所述发送数据量一致。
  28. 一种电子设备,包括处理器和用于存储处理器可执行指令的存储器;其中,所述处理器通过运行所述可执行指令以实现如权利要求9-24中任一项所述的方法。
  29. 一种计算机可读存储介质,其上存储有计算机指令,该指令被处理器执行时实现如权利要求9-24中任一项所述方法的步骤。
PCT/CN2022/127236 2021-11-05 2022-10-25 区块链中继通信网络的中立性验证 WO2023078123A1 (zh)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
CN202111306181.7A CN114095499B (zh) 2021-11-05 区块链中继通信网络的中立性验证方法及装置
CN202111306181.7 2021-11-05

Publications (1)

Publication Number Publication Date
WO2023078123A1 true WO2023078123A1 (zh) 2023-05-11

Family

ID=80299024

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/CN2022/127236 WO2023078123A1 (zh) 2021-11-05 2022-10-25 区块链中继通信网络的中立性验证

Country Status (1)

Country Link
WO (1) WO2023078123A1 (zh)

Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6298043B1 (en) * 1998-03-28 2001-10-02 Nortel Networks Limited Communication system architecture and a connection verification mechanism therefor
JP2012023442A (ja) * 2010-07-12 2012-02-02 Nec Corp フェアネス制御回路、ノード装置、フェアネス制御方法およびフェアネス制御プログラム
CN109874409A (zh) * 2017-09-12 2019-06-11 西北大学 区块链分发网络
CN110166411A (zh) * 2018-02-13 2019-08-23 华为技术有限公司 一种数据传输方法、装置和网络节点
CN114095499A (zh) * 2021-11-05 2022-02-25 支付宝(杭州)信息技术有限公司 区块链中继通信网络的中立性验证方法及装置

Patent Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6298043B1 (en) * 1998-03-28 2001-10-02 Nortel Networks Limited Communication system architecture and a connection verification mechanism therefor
JP2012023442A (ja) * 2010-07-12 2012-02-02 Nec Corp フェアネス制御回路、ノード装置、フェアネス制御方法およびフェアネス制御プログラム
CN109874409A (zh) * 2017-09-12 2019-06-11 西北大学 区块链分发网络
CN110166411A (zh) * 2018-02-13 2019-08-23 华为技术有限公司 一种数据传输方法、装置和网络节点
CN114095499A (zh) * 2021-11-05 2022-02-25 支付宝(杭州)信息技术有限公司 区块链中继通信网络的中立性验证方法及装置

Also Published As

Publication number Publication date
CN114095499A (zh) 2022-02-25

Similar Documents

Publication Publication Date Title
CN112491846B (zh) 一种跨链的区块链通信方法及装置
JP7011646B2 (ja) 量子通信及びトラステッドコンピューティングに基づくデータセキュリティのための方法及びシステム
Kaur et al. Blockchain-based lightweight authentication mechanism for vehicular fog infrastructure
KR101593864B1 (ko) 컨텐츠 중심 네트워킹
CN111949602B (zh) 一种支持完整性验证的外包数据安全迁移方法与系统
US20160065376A1 (en) Virally distributable trusted messaging
CN106941404B (zh) 密钥保护方法及装置
CN114362993B (zh) 一种区块链辅助的车联网安全认证方法
US20230262126A1 (en) Blockchain-based data processing method and apparatus, device, and readable storage medium
CN114710275B (zh) 物联网环境下基于区块链的跨域认证和密钥协商方法
CN112187450B (zh) 密钥管理通信的方法、装置、设备及存储介质
JP2016514913A (ja) セッション鍵を確立する方法および装置
CN114142995B (zh) 面向区块链中继通信网络的密钥安全分发方法及装置
CN110620776B (zh) 一种数据转移信息传输方法及其装置
CN115766066A (zh) 数据传输方法、装置、安全通信系统及存储介质
Lin et al. A fully decentralized infrastructure for subscription-based iot data trading
Garcia et al. Quantum-resistant Transport Layer Security
WO2023078123A1 (zh) 区块链中继通信网络的中立性验证
CN114143038A (zh) 面向区块链中继通信网络的密钥安全分发方法及装置
WO2023010688A1 (zh) 一种密钥管理方法及装置
CN115766075A (zh) 一种基于属性基加密和身份签名的委托认证方法
CN114095499B (zh) 区块链中继通信网络的中立性验证方法及装置
US9154548B2 (en) Auditable distribution of a data file
Rafael et al. An RT-cloud solution towards security in Vehicular platooning systems
CN116561820B (zh) 可信数据处理方法及相关装置

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 22889148

Country of ref document: EP

Kind code of ref document: A1