Blockchain data transmission method and device, and electronic equipment

Abstract

The application belongs to the technical field of blockchains, and specifically provides a blockchain data transmission method, device and electronic equipment, the method comprising: generating a data transmission case identifier, a confirmation message parameter and an asymmetric encryption key pair by using a preset data generation algorithm; the asymmetric encryption key pair comprises a temporary public key and a temporary private key; sending the temporary public key, the confirmation message parameter and the data transmission case identifier to the data sender; sending a data transmission request to a smart contract; when it is detected that the smart contract sets the data transmission case state corresponding to the data transmission case identifier as determined, obtaining target transmission data from the smart contract; performing decryption processing and hash processing on the target transmission data, generating corresponding blockchain transaction information, and transmitting the blockchain transaction information to the smart contract. The blockchain data transmission method improves the security of blockchain data transmission.

Description

Technical Field

[0001] This application relates to the field of blockchain technology, and in particular to a blockchain data transmission method, apparatus, and electronic device. Background Technology

[0002] Blockchain technology, as a distributed digital ledger technology, uses cryptography to enable people to build trust in each other's collaboration without the supervision of a central authority, achieving decentralized multilateral transactions in a distributed network. All nodes in a blockchain maintain the same digital ledger, the ledger content is public to everyone, and once data is uploaded to the ledger, it cannot be tampered with.

[0003] Currently, during blockchain data transmission, the interaction typically occurs between the data sender and the data receiver. However, security issues at either the data sender or receiver can compromise the security of blockchain data transmission. Therefore, the security of blockchain data transmission needs further improvement. Summary of the Invention

[0004] This application provides a blockchain data transmission method, apparatus, and electronic device to address the issue that the security of current blockchain data transmission needs further improvement.

[0005] The first aspect of this application provides a blockchain data transmission method applied to a data receiver, wherein the data receiver, data sender, and smart contract communicate with each other, and the method includes:

[0006] A preset data generation algorithm is used to generate a data transmission case identifier, confirmation message parameters, and an asymmetric encryption key pair; the asymmetric encryption key pair includes a temporary public key and a temporary private key.

[0007] Send the temporary public key, confirmation message parameters, and data transmission case identifier to the data sender;

[0008] Send a data transmission request to the smart contract so that the smart contract sets the status of the data transmission case corresponding to the data transmission case identifier to requested based on the data transmission request.

[0009] When the smart contract detects that the data transmission case status corresponding to the data transmission case identifier is confirmed, the target transmission data is obtained from the smart contract; the target transmission data is transmitted to the smart contract by the data sender when the data transmission case status is requested.

[0010] The target transmitted data is decrypted and hashed to generate corresponding blockchain transaction information, which is then transmitted to a smart contract. The smart contract compares the blockchain transaction information with the target transmitted data, and if the blockchain transaction information and the target transmitted data are identical, the data transmission case status is changed to "completed".

[0011] Furthermore, in the method described above, the preset data generation algorithm includes: a preset random number generation algorithm, a preset confirmation parameter generation algorithm, and a preset key generation algorithm; the data transmission request includes a first tuple and a data transmission security deposit; the first tuple includes a data transmission case identifier, a confirmation message parameter, the asymmetric encryption key pair, a data receiver identifier, and a data sender identifier;

[0012] The process of generating a data transmission case identifier, confirmation message parameters, and asymmetric encryption key pair using a preset data generation algorithm includes:

[0013] A data transmission case identifier is generated using a preset random number generation algorithm;

[0014] The confirmation message parameters are generated using a preset confirmation parameter generation algorithm;

[0015] An asymmetric encryption key pair is generated using a preset key generation algorithm; the asymmetric encryption key pair includes a temporary public key and a temporary private key.

[0016] Furthermore, in the method described above, the target transmission data includes: an algorithm identifier and a second tuple; the second tuple includes a data transmission case identifier, an acknowledgment message value, and ciphertext;

[0017] The process of decrypting and hashing the target transmitted data to generate corresponding blockchain transaction information includes:

[0018] The ciphertext is decrypted using the temporary private key to generate a decrypted first message and a first random number;

[0019] The first message and the data transmission case identifier are hashed to generate a first hash value;

[0020] Generate the blockchain transaction information; the blockchain transaction information includes a third tuple; the third tuple includes the data transmission case identifier, the confirmation message value, the first hash value, and the first random number.

[0021] Furthermore, in the method described above, the method further includes:

[0022] When the data transmission case status is "completed", the confirmation message value is disclosed.

[0023] A second aspect of this application provides a blockchain data transmission method applied to a data sender, wherein the data sender, data receiver, and smart contract communicate with each other, and the method includes:

[0024] Receive the temporary public key, confirmation message parameters, and data transmission case identifier sent by the data recipient;

[0025] When the smart contract sets the data transmission case status corresponding to the data transmission case identifier to be requested, the corresponding second hash value, second random number and confirmation message value are generated according to the second message to be transmitted, the data transmission case identifier, the confirmation message parameters and the preset data generation algorithm.

[0026] The second message and the second random number are asymmetrically encrypted using a temporary public key to generate the corresponding ciphertext;

[0027] The target transmission data is sent to the smart contract so that the smart contract modifies the data transmission case status corresponding to the data transmission case identifier to confirmed based on the target transmission data; the target transmission data includes an algorithm identifier and a second tuple; the second tuple includes the data transmission case identifier, the confirmation message value, and the ciphertext.

[0028] Furthermore, in the method described above, the preset data generation algorithm includes: a preset random number generation algorithm and a confirmation message generation algorithm; the algorithm identifier includes an identifier corresponding to the preset random number generation algorithm and an identifier corresponding to the confirmation message generation algorithm;

[0029] The step of generating a corresponding second hash value, a second random number, and a confirmation message value based on the second message to be transmitted, the data transmission case identifier, the confirmation message parameters, and a preset data generation algorithm includes:

[0030] The second message to be transmitted and the data transmission case identifier are hashed to generate a corresponding second hash value; the data transmission case identifier has a mapping relationship with the data sender identifier.

[0031] A second random number is generated using a preset random number generation algorithm;

[0032] An acknowledgment message generation algorithm is used to generate a corresponding acknowledgment message value based on the second random number, the second hash value, and the acknowledgment message parameters.

[0033] Furthermore, in the method described above, after sending the target data to the smart contract, the method further includes:

[0034] Check whether the data transmission case status is "requested";

[0035] If it is determined that the data transmission case status is not requested, a rejection message is sent to the smart contract.

[0036] A third aspect of this application provides a blockchain data transmission method applied to smart contracts, in which a data sender, a data receiver, and the smart contract communicate with each other. The method includes:

[0037] Receive a data transmission request sent by the data receiver, and set the corresponding data transmission case status to requested based on the data transmission request;

[0038] Receive the target transmission data sent by the data sender, and modify the data transmission case status corresponding to the data transmission case identifier to confirmed based on the target transmission data;

[0039] Receive blockchain transaction information sent by the data recipient;

[0040] The blockchain transaction information and the target transmission data are compared, and if they are the same, the data transmission case status is modified to "completed".

[0041] Furthermore, in the method described above, the data transmission request includes a first tuple and a data transmission security deposit; the first tuple includes a data transmission case identifier, a confirmation message parameter, an asymmetric encryption key, a data receiver identifier, and a data sender identifier; the asymmetric encryption key pair includes a temporary public key and a temporary private key;

[0042] The step of setting the corresponding data transmission case status to "requested" according to the data transmission request includes:

[0043] Verification processing is performed on the data receiver identifier and the data sender identifier;

[0044] If the verification result is successful, the status of the data transmission case corresponding to the data transmission case identifier is set to requested, and the confirmation message parameters and the asymmetric encryption key pair are stored.

[0045] Further, in the method described above, the target transmission data includes an algorithm identifier and a second tuple; the algorithm identifier includes an identifier corresponding to a preset random number generation algorithm and an identifier corresponding to a confirmation message generation algorithm; the second tuple includes a data transmission case identifier, a confirmation message value, and ciphertext; the blockchain transaction information includes a third tuple; the third tuple includes the data transmission case identifier, the confirmation message value, a first hash value, and a first random number;

[0046] The comparison of the blockchain transaction information and the target transmission data includes:

[0047] The ciphertext is decrypted using the temporary private key to generate a decrypted second message and a second random number;

[0048] The corresponding confirmation message generation algorithm is determined based on the algorithm identifier;

[0049] The corresponding second hash value is determined based on the confirmation message generation algorithm, the second random number, the confirmation message value, and the confirmation message parameters.

[0050] Compare whether the first hash value and the second hash value are the same, and whether the first random number and the second random number are the same;

[0051] If they are the same, then the blockchain transaction information and the target transmission data are determined to be identical.

[0052] Furthermore, in the method described above, the method further includes:

[0053] Receive case appeal requests sent by the data recipient;

[0054] If the data transfer case status is "completed", then determine whether the following conditions are met:

[0055] The temporary private key does not match the ciphertext;

[0056] The third message generated after decrypting the ciphertext using the temporary private key is empty;

[0057] The third random number generated after decrypting the ciphertext using the temporary private key is different from the first random number.

[0058] The third hash value, determined by the confirmation message generation algorithm, the third random number, the confirmation message value, and the confirmation message parameters, is different from the first hash value.

[0059] If it is determined that the above conditions are not fully met, then the data recipient is determined to be a malicious object, and the data transmission deposit is sent to the data sender.

[0060] If none of the above conditions are met, the data sender is determined to be a malicious entity, the data transmission deposit is sent to the data receiver, and the data sender's identifier is added to a preset blacklist.

[0061] A fourth aspect of this application provides a blockchain data transmission device located at a data receiver, wherein the data receiver, data sender, and smart contract communicate with each other, and the device includes:

[0062] The generation module is used to generate a data transmission case identifier, confirmation message parameters, and an asymmetric encryption key pair using a preset data generation algorithm; the asymmetric encryption key pair includes a temporary public key and a temporary private key.

[0063] The first sending module is used to send a temporary public key, confirmation message parameters, and data transmission case identifier to the data sender;

[0064] The second sending module is used to send a data transmission request to the smart contract, so that the smart contract sets the data transmission case status corresponding to the data transmission case identifier to requested according to the data transmission request.

[0065] The acquisition module is used to acquire the target transmission data from the smart contract when it detects that the data transmission case status corresponding to the data transmission case identifier set by the smart contract is determined; the target transmission data is transmitted to the smart contract by the data sender when it detects that the data transmission case status is requested.

[0066] The transmission module is used to decrypt and hash the target transmission data, generate corresponding blockchain transaction information, and transmit the blockchain transaction information to the smart contract. This allows the smart contract to compare the blockchain transaction information with the target transmission data, and if the blockchain transaction information and the target transmission data are the same, modify the data transmission case status to "completed".

[0067] Furthermore, in the apparatus described above, the preset data generation algorithm includes: a preset random number generation algorithm, a preset confirmation parameter generation algorithm, and a preset key generation algorithm; the data transmission request includes a first tuple and a data transmission security deposit; the first tuple includes a data transmission case identifier, a confirmation message parameter, the asymmetric encryption key pair, a data receiver identifier, and a data sender identifier;

[0068] The generation module is specifically used for:

[0069] A data transmission case identifier is generated using a preset random number generation algorithm; a confirmation message parameter is generated using a preset confirmation parameter generation algorithm; and an asymmetric encryption key pair is generated using a preset key generation algorithm. The asymmetric encryption key pair includes a temporary public key and a temporary private key.

[0070] Furthermore, in the apparatus described above, the target transmission data includes: an algorithm identifier and a second tuple; the second tuple includes a data transmission case identifier, an acknowledgment message value, and ciphertext;

[0071] The transmission module is specifically used for:

[0072] The ciphertext is decrypted using the temporary private key to generate a decrypted first message and a first random number; the first message and the data transmission case identifier are hashed to generate a first hash value; the blockchain transaction information is generated; the blockchain transaction information includes a third tuple; the third tuple includes the data transmission case identifier, the confirmation message value, the first hash value, and the first random number.

[0073] Furthermore, in the method described above, the apparatus further includes:

[0074] The public module is used to publicly disclose the confirmation message value when the data transmission case status is "completed".

[0075] A fifth aspect of this application provides a blockchain data transmission device located at a data sender, wherein the data sender, data receiver, and smart contract communicate with each other, and the device includes:

[0076] The receiving module is used to receive the temporary public key, confirmation message parameters, and data transmission case identifier sent by the data receiver.

[0077] The generation module is used to generate a corresponding second hash value, a second random number, and a confirmation message value based on the second message to be transmitted, the data transmission case identifier, the confirmation message parameters, and a preset data generation algorithm when the smart contract sets the data transmission case identifier to a requested state.

[0078] The encryption module is used to perform asymmetric encryption on the second message and the second random number using a temporary public key to generate corresponding ciphertext;

[0079] The sending module is used to send target transmission data to the smart contract, so that the smart contract modifies the data transmission case status corresponding to the data transmission case identifier to confirmed based on the target transmission data; the target transmission data includes an algorithm identifier and a second tuple; the second tuple includes a data transmission case identifier, a confirmation message value, and ciphertext.

[0080] Furthermore, in the apparatus described above, the preset data generation algorithm includes: a preset random number generation algorithm and a confirmation message generation algorithm; the algorithm identifier includes an identifier corresponding to the preset random number generation algorithm and an identifier corresponding to the confirmation message generation algorithm;

[0081] When the generation module generates the corresponding second hash value, second random number, and confirmation message value based on the second message to be transmitted, the data transmission case identifier, the confirmation message parameters, and the preset data generation algorithm, it is specifically used for:

[0082] The second message to be transmitted and the data transmission case identifier are hashed to generate a corresponding second hash value; the data transmission case identifier and the data sender identifier have a mapping relationship; a second random number is generated using a preset random number generation algorithm; and a corresponding confirmation message value is generated using a confirmation message generation algorithm based on the second random number, the second hash value, and the confirmation message parameters.

[0083] Furthermore, the apparatus as described above further includes:

[0084] The inspection module is used to check whether the data transmission case status is requested; if it is determined that the data transmission case status is not requested, a rejection message is sent to the smart contract.

[0085] A sixth aspect of this application provides a blockchain data transmission device located within a smart contract, enabling communication between a data sender, a data receiver, and the smart contract. The device includes:

[0086] The setting module is used to receive data transmission requests sent by the data receiver and set the corresponding data transmission case status to requested according to the data transmission request.

[0087] The modification module is used to receive the target transmission data sent by the data sender, and modify the data transmission case status corresponding to the data transmission case identifier to "confirmed" according to the target transmission data;

[0088] The receiving module is used to receive blockchain transaction information sent by the data recipient;

[0089] The comparison module is used to compare the blockchain transaction information with the target transmission data, and modify the data transmission case status to "completed" when the blockchain transaction information and the target transmission data are the same.

[0090] Furthermore, in the apparatus described above, the data transmission request includes a first tuple and a data transmission security deposit; the first tuple includes a data transmission case identifier, a confirmation message parameter, an asymmetric encryption key, a data receiver identifier, and a data sender identifier; the asymmetric encryption key pair includes a temporary public key and a temporary private key;

[0091] When the setting module sets the corresponding data transmission case status to "requested" according to the data transmission request, it is specifically used for:

[0092] The data receiver identifier and the data sender identifier are verified. If the verification result is successful, the data transmission case status corresponding to the data transmission case identifier is set to requested, and the confirmation message parameters and the asymmetric encryption key pair are stored.

[0093] Further, in the apparatus described above, the target transmission data includes an algorithm identifier and a second tuple; the algorithm identifier includes an identifier corresponding to a preset random number generation algorithm and an identifier corresponding to a confirmation message generation algorithm; the second tuple includes a data transmission case identifier, a confirmation message value, and ciphertext; the blockchain transaction information includes a third tuple; the third tuple includes the data transmission case identifier, the confirmation message value, a first hash value, and a first random number;

[0094] When comparing the blockchain transaction information and the target transmission data, the comparison module is specifically used for:

[0095] The ciphertext is decrypted using the temporary private key to generate a decrypted second message and a second random number; the corresponding confirmation message generation algorithm is determined based on the algorithm identifier; the corresponding second hash value is determined based on the confirmation message generation algorithm, the second random number, the confirmation message value, and the confirmation message parameters; the first hash value and the second hash value are compared to see if they are the same, as are the first random number and the second random number; if they are all the same, it is determined that the blockchain transaction information and the target transmission data are the same.

[0096] Furthermore, the apparatus as described above further includes:

[0097] The processing module receives case appeal requests from the data recipient; if the case data transmission status is "completed," it determines whether the following conditions are met:

[0098] The temporary private key does not match the ciphertext;

[0099] The third message generated after decrypting the ciphertext using the temporary private key is empty;

[0100] The third random number generated after decrypting the ciphertext using the temporary private key is different from the first random number.

[0101] The third hash value, determined by the confirmation message generation algorithm, the third random number, the confirmation message value, and the confirmation message parameters, is different from the first hash value.

[0102] If it is determined that not all of the above conditions are met, the data recipient is identified as a malicious entity, and the data transmission deposit is sent to the data sender; if it is determined that none of the above conditions are met, the data sender is identified as a malicious entity, the data transmission deposit is sent to the data recipient, and the data sender's identifier is added to a preset blacklist.

[0103] A seventh aspect of this application provides an electronic device, including: a memory and a processor;

[0104] The memory stores computer-executed instructions;

[0105] The processor executes computer execution instructions stored in the memory to implement the blockchain data transmission method as described in any one of the first to third aspects.

[0106] The eighth aspect of this application provides a computer-readable storage medium storing computer-executable instructions, which, when executed by a processor, are used to implement the blockchain data transmission method described in any one of the first to third aspects.

[0107] The ninth aspect of this application provides a computer program product, including a computer program that, when executed by a processor, implements the blockchain data transmission method described in any one of the first to third aspects.

[0108] This application provides a blockchain data transmission method, apparatus, and electronic device, in which the data receiver, data sender, and smart contract communicate with each other. The method includes: generating a data transmission case identifier, confirmation message parameters, and an asymmetric encryption key pair using a preset data generation algorithm; the asymmetric encryption key pair includes a temporary public key and a temporary private key; sending the temporary public key, confirmation message parameters, and data transmission case identifier to the data sender; sending a data transmission request to the smart contract, so that the smart contract sets the data transmission case status corresponding to the data transmission case identifier to "requested" according to the data transmission request; when the smart contract sets the data transmission case status corresponding to the data transmission case identifier to "confirmed", obtaining the target transmission data from the smart contract; the target transmission data is transmitted by the data sender to the smart contract when the data transmission case status is "requested"; decrypting and hashing the target transmission data to generate corresponding blockchain transaction information, and transmitting the blockchain transaction information to the smart contract, so that the smart contract compares the blockchain transaction information with the target transmission data, and when the blockchain transaction information and the target transmission data are the same, modifying the data transmission case status to "completed". The blockchain data transmission method of this application involves data transmission between the data sender and the data receiver through a smart contract third party. Since the smart contract can control the triggering conditions of its internal functions through specific logic and is not subject to the control of anyone, the third party enhances the security of blockchain data transmission. Attached Figure Description

[0109] The accompanying drawings, which are incorporated in and form part of this specification, illustrate embodiments consistent with this application and, together with the description, serve to explain the principles of this application.

[0110] Figure 1 This is a scenario diagram illustrating how the blockchain data transmission method of this application embodiment can be implemented;

[0111] Figure 2 Flowchart of the blockchain data transmission method provided in this application Figure 1 ;

[0112] Figure 3 Flowchart of the blockchain data transmission method provided in this application Figure 2 ;

[0113] Figure 4 Flowchart of the blockchain data transmission method provided in this application Figure 3 ;

[0114] Figure 5 An interactive diagram illustrating the blockchain data transmission method provided in this application;

[0115] Figure 6 Schematic diagram of the blockchain data transmission device provided in this application Figure 1 ;

[0116] Figure 7 Schematic diagram of the blockchain data transmission device provided in this application Figure 2 ;

[0117] Figure 8 Schematic diagram of the blockchain data transmission device provided in this application Figure 3 ;

[0118] Figure 9 A schematic diagram of the structure of the electronic device provided in this application.

[0119] The accompanying drawings illustrate specific embodiments of this application, which will be described in more detail below. These drawings and descriptions are not intended to limit the scope of the concept in any way, but rather to illustrate the concept of this application to those skilled in the art through reference to particular embodiments. Detailed Implementation

[0120] Exemplary embodiments will now be described in detail, examples of which are illustrated in the accompanying drawings. When the following description relates to the drawings, unless otherwise indicated, the same numbers in different drawings denote the same or similar elements. The embodiments described in the following exemplary embodiments do not represent all embodiments consistent with this application. Rather, they are merely examples of apparatuses and methods consistent with some aspects of this application as detailed in the appended claims.

[0121] The collection, storage, use, processing, transmission, provision, and disclosure of user personal information involved in the technical solutions of this application comply with the provisions of relevant laws and regulations and do not violate public order and good morals.

[0122] It should be noted that the user information (including but not limited to user device information, user personal information, etc.) and data (including but not limited to data used for analysis, data stored, data displayed, etc.) involved in this application are all information and data authorized by the user or fully authorized by all parties. Furthermore, the collection, use and processing of the relevant data must comply with the relevant laws, regulations and standards of the relevant countries and regions, and corresponding operation portals are provided for users to choose to authorize or refuse.

[0123] It should be noted that the blockchain data transmission method, apparatus, equipment, medium, and product disclosed herein can be used in the field of blockchain technology. They can also be used in any field other than blockchain technology. The application areas of the blockchain data transmission method, apparatus, equipment, medium, and product disclosed herein are not limited.

[0124] The technical solutions of this application will be described in detail below with reference to specific embodiments. These specific embodiments can be combined with each other, and the same or similar concepts or processes may not be described again in some embodiments. The embodiments of this application will be described below with reference to the accompanying drawings.

[0125] To clearly understand the technical solution of this application, we will first provide a detailed description of existing solutions. Smart contracts are typically written in officially supported programming languages, and the compiled code can be deployed to a blockchain to achieve distributed collaboration. Once deployed, a smart contract has a unique address that identifies it. Blockchain users can use this address to initiate transactions to the smart contract identified by that address or to query historical transaction information related to the smart contract. Because smart contracts can control the triggering conditions of their internal functions through specific logic and are not subject to the control of any single individual, they are often used in research to replace trusted third parties.

[0126] Currently, blockchain data transmission typically involves interaction between the data sender and receiver without the use of a trusted third party. Security issues at either the data sender or receiver can compromise the security of blockchain data transmission. Therefore, the security of blockchain data transmission needs further improvement.

[0127] Therefore, in response to the problem that the security of blockchain data transmission in existing technologies needs to be further improved, the inventors discovered in their research that, in order to solve this problem, smart contracts can be used as a trusted third party, thereby improving the security of data transmission between data senders and data receivers.

[0128] Specifically, for the data recipient:

[0129] A preset data generation algorithm is used to generate a data transmission case identifier, confirmation message parameters, and an asymmetric encryption key pair. The asymmetric encryption key pair includes a temporary public key and a temporary private key.

[0130] Send the temporary public key, confirmation message parameters, and data transmission case identifier to the data sender.

[0131] Send a data transfer request to the smart contract so that the smart contract sets the data transfer case status corresponding to the data transfer case identifier to "requested" based on the data transfer request.

[0132] When the smart contract detects that the data transmission case status corresponding to the data transmission case identifier is "confirmed," the target data to be transmitted is retrieved from the smart contract. The target data to be transmitted is sent to the smart contract by the data sender when the data transmission case status is "requested."

[0133] The target transmitted data is decrypted and hashed to generate corresponding blockchain transaction information, which is then transmitted to a smart contract. The smart contract compares the blockchain transaction information with the target transmitted data, and if the blockchain transaction information and the target transmitted data are identical, the data transmission case status is changed to "completed".

[0134] The blockchain data transmission method of this application involves data transmission between the data sender and the data receiver through a smart contract third party. Since the smart contract can control the triggering conditions of its internal functions through specific logic and is not subject to the control of anyone, the third party enhances the security of blockchain data transmission.

[0135] Based on the above-mentioned inventive discovery, the inventor has proposed the technical solution of this application.

[0136] The following describes the application scenarios of the blockchain data transmission method provided in the embodiments of this application. For example... Figure 1 As shown, 1 represents the data receiver, 2 represents the data sender, and 3 represents the smart contract. The network architecture of the application scenario corresponding to the blockchain data transmission method provided in this embodiment includes: data receiver 1, data sender 2, and smart contract 3.

[0137] For example, data receiver 1 uses a preset data generation algorithm to generate a data transmission case identifier, confirmation message parameters, and an asymmetric encryption key pair. The asymmetric encryption key pair includes a temporary public key and a temporary private key. ① Data receiver 1 sends the temporary public key, confirmation message parameters, and data transmission case identifier to data sender 2. Simultaneously, ① it sends a data transmission request to smart contract 3, so that the smart contract sets the data transmission case status corresponding to the data transmission case identifier to "requested" based on the data transmission request. ② When data sender 2 detects that the data transmission case status is "requested," it sends the target data to the smart contract, so that smart contract 3 modifies the data transmission case status corresponding to the data transmission case identifier to "confirmed" based on the target data.

[0138] ③ When data receiver 1 detects that the data transmission case status corresponding to the data transmission case identifier set by smart contract 3 is "determined," it obtains the target transmission data from smart contract 3. It decrypts and hashes the target transmission data to generate corresponding blockchain transaction information, ④ and transmits the blockchain transaction information to smart contract 3. Smart contract 3 compares the blockchain transaction information with the target transmission data, and if they match, modifies the data transmission case status to "completed." If, after the data transmission case is completed, data receiver 1 discovers errors in the process or data, it can file a complaint with smart contract 3 and proceed with the subsequent complaint process.

[0139] The embodiments of this application are described below with reference to the accompanying drawings.

[0140] Figure 2 Flowchart of the blockchain data transmission method provided in this application Figure 1 ,like Figure 2 As shown, in this embodiment, the execution subject of this application embodiment is a blockchain data transmission device, which can be integrated into an electronic device. The blockchain data transmission method provided in this embodiment is applied to a data receiver, and the data receiver, data sender, and smart contract communicate with each other. The blockchain data transmission method provided in this embodiment includes the following steps:

[0141] Step S101: A data transmission case identifier, confirmation message parameters, and an asymmetric encryption key pair are generated using a preset data generation algorithm. The asymmetric encryption key pair includes a temporary public key and a temporary private key.

[0142] In this embodiment, the preset data generation algorithm includes: a preset random number generation algorithm, a preset confirmation parameter generation algorithm, and a preset key generation algorithm.

[0143] Optionally, in this embodiment, S101 specifically includes:

[0144] A preset random number generation algorithm is used to generate data transmission case identifiers.

[0145] The confirmation message parameters are generated using a preset confirmation parameter generation algorithm.

[0146] An asymmetric encryption key pair is generated using a preset key generation algorithm. The asymmetric encryption key pair includes a temporary public key and a temporary private key.

[0147] The data transmission case identifier is associated with the data transmission case, and the confirmation message parameter can be used to generate the confirmation message value. This embodiment employs asymmetric encryption to further enhance security. The preset random number generation algorithm and the preset confirmation parameter generation algorithm can be algorithms commonly used in the blockchain field. The preset confirmation parameter generation algorithm can be the commonly used ComGen algorithm.

[0148] Step S102: Send the temporary public key, confirmation message parameters, and data transmission case identifier to the data sender.

[0149] In this embodiment, a temporary public key corresponds to a temporary private key. The temporary public key is used to encrypt data, and the temporary private key is used to decrypt data. Sending the temporary public key to the data sender allows the data sender to encrypt the data to be transmitted, thereby improving the security of data transmission.

[0150] Step S103: Send a data transmission request to the smart contract so that the smart contract sets the data transmission case status corresponding to the data transmission case identifier to requested based on the data transmission request.

[0151] In this embodiment, the data transmission request includes a first tuple and a data transmission security deposit. The first tuple includes a data transmission case identifier, confirmation message parameters, an asymmetric encryption key pair, a data receiver identifier, and a data sender identifier.

[0152] A data transmission guarantee deposit can be used to compensate the other party in the event of malicious intent or abnormal problems on either side of the data sender or receiver. In this embodiment, the data transmission guarantee deposit is provided by the data receiver and is used to compensate the data sender in the event of an abnormality on the data receiver's side. If the data sender experiences an abnormality, the data transmission guarantee deposit will be refunded to the data receiver.

[0153] The status of a data transmission case can be requested, confirmed, or completed, which respectively indicate that the data transmission case has completed the data transmission request, confirmed the data, or completed the data transmission.

[0154] Step S104: When the data transmission case status corresponding to the data transmission case identifier set by the smart contract is detected as "determined," the target transmission data is obtained from the smart contract. The target transmission data is transmitted to the smart contract by the data sender when the data transmission case status is detected as "requested."

[0155] When the data transmission case status is "Confirmed," it means the smart contract has confirmed receipt of the target data. At this point, the data recipient can retrieve the target data from the smart contract and proceed with the subsequent decryption process.

[0156] If the data transmission case status is not confirmed, you can choose to continue waiting or apply to the smart contract to terminate the transmission and redeem the data transmission deposit.

[0157] Step S105: Decrypt and hash the target transmitted data to generate corresponding blockchain transaction information, and transmit the blockchain transaction information to the smart contract so that the smart contract can compare the blockchain transaction information with the target transmitted data. If the blockchain transaction information and the target transmitted data are the same, modify the data transmission case status to "completed".

[0158] Blockchain transaction information is used to compare with the target transmitted data to determine whether the data decrypted by the data recipient is consistent with the target transmitted data stored in the smart contract.

[0159] Optionally, in this embodiment, the target transmitted data includes: an algorithm identifier and a second tuple. The second tuple includes a data transmission case identifier, an acknowledgment message value, and ciphertext.

[0160] The process of decrypting and hashing the target transmitted data in S105 to generate corresponding blockchain transaction information can be specifically described as follows:

[0161] The ciphertext is decrypted using a temporary private key, generating the first decrypted message and the first random number.

[0162] The first message and data transmission case identifier are hashed to generate the first hash value.

[0163] Generate blockchain transaction information. The blockchain transaction information includes a third tuple. The third tuple includes a data transfer case identifier, a confirmation message value, a first hash value, and a first random number.

[0164] The decrypted first message may be the same as or different from the second message the data sender intended to transmit. For example, if a decryption error occurs, the first message may be empty. The same applies to the first random number.

[0165] After determining the first hash value and the first random number, they can be compared with the corresponding hash value and random number in the target transmission data of the smart contract to determine whether the blockchain transaction information is consistent with the target transmission data.

[0166] Optionally, in this embodiment, the method further includes:

[0167] When the data transmission case status is "completed", a public confirmation message value is displayed.

[0168] When the data transmission case status is "completed," it means that the data transmission has been completed and the message value can be publicly confirmed so that other parties in the blockchain know the completion status of this data transmission case.

[0169] This application provides a blockchain data transmission method in which data senders and receivers transmit data through a smart contract third party. Since the smart contract can control the triggering conditions of its internal functions through specific logic and is not subject to the control of anyone, the third party improves the security of blockchain data transmission.

[0170] Figure 3 Flowchart of the blockchain data transmission method provided in this application Figure 2 ,like Figure 3 As shown, the blockchain data transmission method provided in this embodiment is applied to communication between the data sender, the data receiver, and the smart contract. The blockchain data transmission method provided in this embodiment includes the following steps.

[0171] Step S201: Receive the temporary public key, confirmation message parameters, and data transmission case identifier sent by the data receiver.

[0172] Step S202: When the status of the data transmission case corresponding to the data transmission case identifier set by the smart contract is "requested", the corresponding second hash value, second random number and confirmation message value are generated according to the second message to be transmitted, the data transmission case identifier, the confirmation message parameters and the preset data generation algorithm.

[0173] In this embodiment, the second message to be transmitted refers to the message that the data sender needs to transmit to the data receiver.

[0174] Optionally, in this embodiment, the preset data generation algorithm includes: a preset random number generation algorithm and an acknowledgment message generation algorithm. The algorithm identifier includes an identifier corresponding to the preset random number generation algorithm and an identifier corresponding to the acknowledgment message generation algorithm. The algorithm identifier is used to refer to a specific algorithm. Since there are many types of random number generation algorithms and acknowledgment message generation algorithms, the specific algorithm used can be determined through the algorithm identifier.

[0175] The process in S202 of generating the corresponding second hash value, second random number, and confirmation message value based on the second message to be transmitted, the data transmission case identifier, the confirmation message parameters, and the preset data generation algorithm can be specifically described as follows:

[0176] The second message to be transmitted and the data transmission case identifier are hashed to generate a corresponding second hash value. There is a mapping relationship between the data transmission case identifier and the data sender identifier.

[0177] A second random number is generated using a preset random number generation algorithm.

[0178] An acknowledgment message generation algorithm is used to generate the corresponding acknowledgment message value based on the second random number, the second hash value, and the acknowledgment message parameters.

[0179] Confirmation message generation algorithms, such as the COM algorithm commonly used in blockchain, can generate corresponding confirmation message values, while the corresponding Open algorithm can be used to open the corresponding confirmation message value.

[0180] Step S203: Use a temporary public key to perform asymmetric encryption on the second message and the second random number to generate the corresponding ciphertext.

[0181] Step S204: Send the target transmission data to the smart contract so that the smart contract modifies the data transmission case status corresponding to the data transmission case identifier to "confirmed" based on the target transmission data. The target transmission data includes an algorithm identifier and a second tuple. The second tuple includes the data transmission case identifier, the confirmation message value, and the ciphertext.

[0182] The data transmission case identifier is used to identify the corresponding data transmission case, the ciphertext is used to transmit to the data receiver, and the acknowledgment message value is used during the acknowledgment process.

[0183] Optionally, in this embodiment, after sending the target transmission data to the smart contract, the method further includes:

[0184] Check if the data transfer case status is "requested".

[0185] If it is determined that the data transmission case status is not requested, a rejection message is sent to the smart contract.

[0186] By re-verifying whether the data transmission case status is requested, erroneous transmissions can be further avoided when the data transmission case status is not requested.

[0187] Figure 4 Flowchart of the blockchain data transmission method provided in this application Figure 3 ,like Figure 4 As shown, the blockchain data transmission method provided in this embodiment is applied to smart contracts, enabling communication between the data sender, data receiver, and smart contract. The blockchain data transmission method provided in this embodiment includes the following steps.

[0188] Step S301: Receive the data transmission request sent by the data receiver, and set the corresponding data transmission case status to requested according to the data transmission request.

[0189] Optionally, in this embodiment, the data transmission request includes a first tuple and a data transmission security deposit. The first tuple includes a data transmission case identifier, a confirmation message parameter, an asymmetric encryption key, a data receiver identifier, and a data sender identifier. The asymmetric encryption key pair includes a temporary public key and a temporary private key.

[0190] In S301, setting the corresponding data transmission case status to "requested" based on the data transmission request can be specifically as follows:

[0191] Verification processing is performed on the data receiver identifier and the data sender identifier.

[0192] If the verification result is successful, the status of the data transmission case corresponding to the data transmission case identifier is set to requested, and the confirmation message parameters and asymmetric encryption key pair are stored.

[0193] The verification process can check for anomalies in the data receiver and data sender identifiers, such as whether they are on a preset blacklist. If they are on the blacklist, the verification result will fail. It can also check whether a data transmission security deposit has been uploaded; if not, the verification result will also fail.

[0194] Step S302: Receive the target transmission data sent by the data sender, and modify the data transmission case status corresponding to the data transmission case identifier to "confirmed" according to the target transmission data.

[0195] Step S303: Receive blockchain transaction information sent by the data recipient.

[0196] Step S304: Compare the blockchain transaction information with the target transmission data, and modify the data transmission case status to "completed" if the blockchain transaction information and the target transmission data are the same.

[0197] Optionally, in this embodiment, the target transmitted data includes an algorithm identifier and a second tuple. The algorithm identifier includes an identifier corresponding to a preset random number generation algorithm and an identifier corresponding to a confirmation message generation algorithm. The second tuple includes a data transmission case identifier, a confirmation message value, and ciphertext. The blockchain transaction information includes a third tuple. The third tuple includes a data transmission case identifier, a confirmation message value, a first hash value, and a first random number.

[0198] The process of comparing blockchain transaction information and target transmitted data in S304 can be specifically described as follows:

[0199] The ciphertext is decrypted using a temporary private key, generating a second decrypted message and a second random number.

[0200] The corresponding confirmation message generation algorithm is determined based on the algorithm identifier.

[0201] The corresponding second hash value is determined based on the confirmation message generation algorithm, the second random number, the confirmation message value, and the confirmation message parameters.

[0202] Compare whether the first hash value and the second hash value are the same, and whether the first random number and the second random number are the same.

[0203] If they are the same, then the blockchain transaction information and the target transmission data are identical.

[0204] Using a temporary private key to decrypt the ciphertext generates a second message and a second random number. If the second hash value corresponding to the second message is the same as the first hash value, and the first random number and the second random number are also the same, then it can be determined that the second message is the same as the first message, the blockchain transaction information is the same as the target transmitted data, and this data transmission case has been completed.

[0205] Optionally, in this embodiment, the method further includes:

[0206] Receive case appeal requests sent by the data recipient.

[0207] If the data transfer case status is "completed", then determine whether the following conditions are met:

[0208] The temporary private key does not match the ciphertext.

[0209] The third message generated after decrypting the ciphertext using the temporary private key is empty.

[0210] The third random number generated after decrypting the ciphertext using the temporary private key is different from the first random number.

[0211] The third hash value, determined by the confirmation message generation algorithm, the third random number, the confirmation message value, and the confirmation message parameters, is different from the first hash value.

[0212] If it is determined that the above conditions are not fully met, the data recipient is identified as a malicious party, and the data transmission security deposit is sent to the data sender.

[0213] If none of the above conditions are met, the data sender is determined to be a malicious entity, the data transmission deposit is sent to the data receiver, and the data sender's identifier is added to the preset blacklist.

[0214] Even after a data transmission case is considered complete, there may still be issues with transmitted data anomalies, such as the transmitted data being empty or not the data the recipient intended. In this case, the recipient can file a protest with the smart contract. The smart contract will then check whether the problem lies with the recipient or the sender. If any of the above conditions are met, such as a mismatch between the temporary private key and the ciphertext, it indicates an anomaly in the temporary private key sent by the recipient, suggesting the recipient is malicious. Similarly, if the third random number decrypted by the smart contract differs from the first random number, it suggests the recipient may be misrepresenting information. The same applies to other conditions, but their fulfillment may indicate an anomaly in the recipient's behavior. If none of the above conditions are met, the sender can be determined to be malicious.

[0215] To better understand the blockchain data transmission method of this embodiment, the following will be combined with the appendix. Figure 5 Further explanation is needed.

[0216] First, the secure data transmission in the blockchain network of this embodiment is divided into three main entities: the data sender, the data receiver, and the smart contract. The main symbols used are shown in Table 1. The relevant algorithm schemes in the cryptographic building blocks are as follows.

[0217] Table 1. Related Symbols and Definitions

[0218] S Information sender R Data receiver SC Smart Contracts <![CDATA[ID S ]]> sender's ID <![CDATA[ID R ]]> Receiver ID <![CDATA[pk temp ,sk temp ]]> Temporary key pairs for asymmetric encryption M Transmitted message segment hx Hash value <![CDATA[Com x ]]> Confirmation value of ciphertext x dR Data transmission deposit L Data transmission case identifier SL Transmit case status value

[0219] (1) Hash function

[0220] Hash functions are used to compress an input string of arbitrary length into a short, fixed-length output string. A keyless hash function can be written as H:{0,1}. * →{0,1} 1 The hash calculation message M can be simply represented as h = Hash(M).

[0221] (2) Confirmation Message Scheme

[0222] An implementation based on the discrete logarithm problem is adopted. The acknowledgment message scheme involves two parties: the sender and the receiver, who execute algorithms (ComGen, Com, and Open) between tuples. The ComGen generation algorithm is used to generate the acknowledgment message parameters pp, which are then used to calculate the acknowledgment message value, denoted as pp←Comgen(1). λ For any input ciphertext x∈{0,1} * Submission is required. The COM confirmation message generation algorithm needs another randomly generated parameter r and the generated confirmation message parameter pp to produce a confirmation message value COM. x , can be represented as com x ←Com(pp,x,r). Confirmation message, open algorithm, Open judgment, com x ←Com(pp,x,r), if true, outputs 1; otherwise, outputs 0, which can be represented as {0,1}←Open(pp,comx,x,r). The acknowledgment message scheme must satisfy two properties: concealment and binding. Concealment means that any malicious adversary node cannot access the com algorithm before the corresponding Open algorithm is executed. x Obtain any information about x. Binding implies a specific confirmation message value com. x It can only be opened with the original ciphertext x.

[0223] Normally, the ComGen algorithm is executed by the receiver, while the Com and Open algorithms are executed by the sender. However, in this embodiment, the confirmation message scheme is redesigned and implemented based on blockchain and smart contracts. The receiver performs an open operation to confirm that they have received the ciphertext. Furthermore, the sender and receiver will interact with the smart contract, rather than interacting directly with each other.

[0224] (3) Encryption scheme

[0225] Define and denote the three algorithms for asymmetric encryption schemes: key generation, encryption, and decryption as C←AsymGen(1). λ The ciphertext encrypted with the public key pk can only be decrypted with the corresponding private key sk.

[0226] The specific process of this embodiment can be categorized into four steps, such as... Figure 5 As shown, the essential steps include data transmission request, confirmation message publication phase, and public confirmation message publication phase. Figure 5 The steps are distributed across the aforementioned data transmission request, confirmation message publication, and public confirmation message stages. The fourth step, the accusation stage, only occurs when malicious activity occurs on the network. To distinguish each different data transmission case, each case is assigned a random number identifier L, i.e., a data transmission case identifier. For each case with identifier L, the smart contract assigns an execution state SL to a unique case.

[0227] (1) Data transmission request phase

[0228] The receiver R runs a preset random number generation algorithm, RandomGen(1). λ To obtain a data transmission case identifier L as the label of the data transmission case, run the preset confirmation parameter generation algorithm ComGen(1) λ Generate a confirmation message parameter and run the preset key generation algorithm AsymGen(1) λ Generate a temporary asymmetric encryption key pair (pk, sk) and initiate a blockchain transaction to send the relevant data to the data sender, specifically including:

[0229] Temporary public key, confirmation message parameters, and data transmission case identifier.

[0230] Simultaneously, a data transmission request is sent to the smart contract, specifically including:

[0231] The identifier of the data transfer request TransRequest executed by the smart contract, tuple (L, ID) SID R ,pk temp ,pp), and some blockchain currency dR chosen by the recipient as a data transmission guarantee for publicly confirmed messages.

[0232] The smart contract received the tuple TransRequest(L, ID) S ID R ,pk temp After (pp, dR), first ensure that the data recipient has paid the data transfer deposit, then execute TransRequest(L, ID) S ID R ,pk temp The algorithm (pp, dR) handles data transfer requests. Internally, the smart contract ensures the caller is the receiver, then checks the tag L and ID. If L has already flagged any other data transfer case or the ID is in a blacklist, the smart contract rejects the request. Otherwise, the smart contract initiates the data transfer instance, stores these parameters, and sets the instance's state to SL as requested.

[0233] (2) Confirmation message release stage

[0234] When sender S, who is in a listening state, discovers that the smart contract transaction contains an account identifier (ID) S When a data transmission case is established and the data transmission case status SL is set to requested, the sender S is immediately prepared to send the message m to be transmitted to the requester R.

[0235] First, sender S generates the target transmission data through the following steps:

[0236] Calculate the hash value h of the transmitted message with the attached tag, i.e., h ← hash(m||L). Next, the sender S runs the random number generation algorithm r ← RandomGen(1 / L). λ Generate a random value r and calculate the acknowledgment message h with the hash value h of the acknowledgment message scheme exponent pp, i.e., com h ←Com(pp,h,r). The sender S uses the receiver R's temporary public key pk. temp Perform asymmetric encryption on the original message and the random number r, and generate the ciphertext C←AsymEnc(pk). temp ,m||r).

[0237] Sender S initiates a blockchain transaction to send the following target data to a smart contract: the algorithm identifier PubComm and the tuple (L,com). h C).

[0238] When the smart contract receives the tuple (PubComm, (L, com) submitted by the caller with account identifier S... h After C), the sender S will check the state variable SL again. If SL is not requested, the sender rejects the transaction. Otherwise, the sender S stores the parameters and sets the state SL to trusted.

[0239] If the sender S does not send a blockchain transaction in response to the data transmission request during the data transmission phase, the receiver R can choose to continue waiting for the submitted response, or initiate a termination transaction by sending a tuple (Terminate, L) to the sender S. In this case, the receiver R can terminate the protocol and immediately redeem its data transmission deposit dR.

[0240] The smart contract receives the account identifier as ID R After the tuple (Terminate, L) is executed, Terminate(L) will be run to check the state variable SL. If the state variable is Requested, the termination request will be rejected. Otherwise, the sender will set the state variable to Terminated, return the data transfer deposit to the receiver, and terminate the instance.

[0241] (3) Public confirmation of information stage

[0242] Receiver R, in a listening state, retrieves the target transmitted data, such as the ciphertext C, from the smart contract. Receiver R then runs AsymDec(sk... temp C) Decrypt the ciphertext C, restore it to m′, and then the receiver R obtains the decrypted message m′.

[0243] Receiver R calculates the hash value h′ ← hash(m′||L) to obtain the hash value h′. If the AsymDec algorithm outputs 0, receiver R can set any string as h′. Now, receiver R can use blockchain transaction information, which includes the tuple (OpenComm,(L,com)). h The system initiates a blockchain transaction to the smart contract. If the recipient R receives a correct result, then recipient R publicly confirms the transaction via the message "com". h And redeem its data transfer deposit dR.

[0244] The smart contract receives the account identifier as ID R The tuple of the caller (OpenComm, (L,com) h After ,h',r')), start running (OpenComm,(L,com h This involves comparing the target transmitted data with the blockchain transaction information. If (Open(pp,com hIf the output of ,h',r')) is non-zero, the smart contract stores h' and r', sets the state variable SL to "completed", and then returns the data transfer deposit dR to the receiver R. The instance ends normally. If (Open(pp,com h If the output of (h', r') is 0, the smart contract sets the state variable SL to misbehavior and stores h' and r' to determine whether the sender or receiver has misbehaved.

[0245] (4) Complaint Stage

[0246] When the data transmission instance is in the "finished" state, the receiver R can use the tuple (ComPlain,(L,sk)) temp To initiate a blockchain transaction to a smart contract, upload its temporary private key sk. temp An appeal can be filed against a decision made by the smart contract in the previous stage.

[0247] Smart contracts use account identifiers as IDs R The caller receives the tuple (ComPlain, (L, sk temp After that, the smart contract executes (ComPlain,(L,sk)). temp To handle complaint requests, the smart contract checks the state variable SL. If the SL state variable indicates misconduct rather than that the misconduct has ended, the request is rejected. If the misconduct has ended, the following conditions are checked:

[0248] (a) Uploaded sk temp This is not the corresponding private key.

[0249] (b)0←AsymDec(sk temp C).

[0250] (c)m”||r”←AsymDec(sk temp C) and h”←Hash(m||L), but h”≠h' or r”≠r', where h’ and r are uploaded and stored in the public confirmation message stage in step 3.

[0251] If all of the above statements are negative, it means that the smart contract uses sk temp C was successfully decrypted, and the output matched the parameters uploaded by R, indicating that the receiver R was acting in good faith. Therefore, the sender S was determined to be malicious, and the smart contract returned the data transfer deposit dR to the receiver R and added the sender ID to the blacklist. Conversely, if any of the above conditions were met, the receiver R was determined to be a malicious node, the data transfer deposit dR was returned to the sender, and the receiver ID was added to the blacklist. Finally, the smart contract set the state SL to terminate, ending the protocol.

[0252] Figure 6 Schematic diagram of the blockchain data transmission device provided in this application Figure 1 ,like Figure 6 As shown, in this embodiment, the blockchain data transmission device 400 is located on the data receiver and can be installed in an electronic device. The blockchain data transmission device 400 includes:

[0253] The generation module 401 is used to generate a data transmission case identifier, confirmation message parameters, and an asymmetric encryption key pair using a preset data generation algorithm. The asymmetric encryption key pair includes a temporary public key and a temporary private key.

[0254] The first sending module 402 is used to send a temporary public key, confirmation message parameters, and data transmission case identifier to the data sender.

[0255] The second sending module 403 is used to send a data transmission request to the smart contract, so that the smart contract sets the data transmission case status corresponding to the data transmission case identifier to "requested" according to the data transmission request.

[0256] The acquisition module 404 is used to retrieve the target data to be transmitted from the smart contract when the status of the data transmission case corresponding to the data transmission case identifier set by the smart contract is "determined". The target data to be transmitted is transmitted to the smart contract by the data sender when the status of the data transmission case is "requested".

[0257] The transmission module 405 is used to decrypt and hash the target transmission data, generate corresponding blockchain transaction information, and transmit the blockchain transaction information to the smart contract so that the smart contract can compare the blockchain transaction information with the target transmission data. When the blockchain transaction information and the target transmission data are the same, the data transmission case status is modified to complete.

[0258] Optionally, in this embodiment, the preset data generation algorithm includes: a preset random number generation algorithm, a preset confirmation parameter generation algorithm, and a preset key generation algorithm. The data transmission request includes a first tuple and a data transmission security deposit. The first tuple includes a data transmission case identifier, confirmation message parameters, an asymmetric encryption key pair, a data receiver identifier, and a data sender identifier.

[0259] The generation module 401 is specifically used for:

[0260] A data transmission case identifier is generated using a preset random number generation algorithm. Confirmation message parameters are generated using a preset confirmation parameter generation algorithm. An asymmetric encryption key pair is generated using a preset key generation algorithm. The asymmetric encryption key pair includes a temporary public key and a temporary private key.

[0261] Optionally, in this embodiment, the target transmitted data includes: an algorithm identifier and a second tuple. The second tuple includes a data transmission case identifier, an acknowledgment message value, and ciphertext.

[0262] The transmission module 405 is specifically used for:

[0263] The ciphertext is decrypted using a temporary private key, generating a decrypted first message and a first random number. The first message and data transmission case identifier are hashed to generate a first hash value. Blockchain transaction information is then generated. This blockchain transaction information includes a third tuple. The third tuple includes the data transmission case identifier, the confirmation message value, the first hash value, and the first random number.

[0264] Optionally, in this embodiment, the blockchain data transmission device 400 further includes:

[0265] The public module is used to publicly display the confirmation message value when the data transmission case status is "completed".

[0266] The blockchain data transmission device provided in this embodiment can execute... Figure 2 The technical solution of the method embodiment shown has the same implementation principle and technical effect as... Figure 2 The methods and embodiments shown are similar and will not be described in detail here.

[0267] Figure 7 Schematic diagram of the blockchain data transmission device provided in this application Figure 2 ,like Figure 7 As shown, in this embodiment, the blockchain data transmission device 500 is located on the data sender and can be installed in an electronic device. The blockchain data transmission device 500 includes:

[0268] The receiving module 501 is used to receive the temporary public key, confirmation message parameters, and data transmission case identifier sent by the data receiver.

[0269] The generation module 502 is used to generate a corresponding second hash value, a second random number, and a confirmation message value based on the second message to be transmitted, the data transmission case identifier, the confirmation message parameters, and a preset data generation algorithm when the data transmission case status corresponding to the data transmission case identifier set by the smart contract is "requested".

[0270] The encryption module 503 is used to perform asymmetric encryption on the second message and the second random number using a temporary public key to generate the corresponding ciphertext.

[0271] The sending module 504 is used to send the target transmission data to the smart contract, so that the smart contract can modify the data transmission case status corresponding to the data transmission case identifier to "confirmed" based on the target transmission data. The target transmission data includes an algorithm identifier and a second tuple. The second tuple includes the data transmission case identifier, the confirmation message value, and the ciphertext.

[0272] Optionally, in this embodiment, the preset data generation algorithm includes: a preset random number generation algorithm and an acknowledgment message generation algorithm. The algorithm identifiers include the identifier corresponding to the preset random number generation algorithm and the identifier corresponding to the acknowledgment message generation algorithm.

[0273] When generating the corresponding second hash value, second random number, and confirmation message value based on the second message to be transmitted, the data transmission case identifier, the confirmation message parameters, and the preset data generation algorithm, the generation module 502 is specifically used for:

[0274] The second message to be transmitted and the data transmission case identifier are hashed to generate a corresponding second hash value. The data transmission case identifier and the data sender identifier have a mapping relationship. A second random number is generated using a preset random number generation algorithm. An acknowledgment message generation algorithm is used to generate a corresponding acknowledgment message value based on the second random number, the second hash value, and the acknowledgment message parameters.

[0275] Optionally, in this embodiment, the blockchain data transmission device 500 further includes:

[0276] The inspection module checks whether the data transmission case status is "requested". If it determines that the data transmission case status is not "requested", it sends a rejection message to the smart contract.

[0277] The blockchain data transmission device provided in this embodiment can execute... Figure 3 The technical solution of the method embodiment shown has the same implementation principle and technical effect as... Figure 3 The methods and embodiments shown are similar and will not be described in detail here.

[0278] Figure 8 Schematic diagram of the blockchain data transmission device provided in this application Figure 3 ,like Figure 8 As shown, in this embodiment, the blockchain data transmission device 600 is located in a smart contract and can be installed in an electronic device. The blockchain data transmission device 600 includes:

[0279] The setting module 601 is used to receive data transmission requests sent by the data receiver and set the corresponding data transmission case status to requested based on the data transmission request.

[0280] Modification module 602 is used to receive the target transmission data sent by the data sender and modify the data transmission case status corresponding to the data transmission case identifier to "confirmed" according to the target transmission data.

[0281] The receiving module 603 is used to receive blockchain transaction information sent by the data receiver.

[0282] The comparison module 604 is used to compare the blockchain transaction information with the target transmission data, and modify the data transmission case status to "completed" when the blockchain transaction information and the target transmission data are the same.

[0283] Optionally, in this embodiment, the data transmission request includes a first tuple and a data transmission security deposit. The first tuple includes a data transmission case identifier, a confirmation message parameter, an asymmetric encryption key, a data receiver identifier, and a data sender identifier. The asymmetric encryption key pair includes a temporary public key and a temporary private key.

[0284] When setting the status of the corresponding data transmission case to "requested" based on the data transmission request, module 601 is specifically used for:

[0285] The data receiver identifier and data sender identifier are validated. If the validation passes, the data transmission case status corresponding to the data transmission case identifier is set to requested, and the confirmation message parameters and asymmetric encryption key pair are stored.

[0286] Optionally, in this embodiment, the target transmitted data includes an algorithm identifier and a second tuple. The algorithm identifier includes an identifier corresponding to a preset random number generation algorithm and an identifier corresponding to a confirmation message generation algorithm. The second tuple includes a data transmission case identifier, a confirmation message value, and ciphertext. The blockchain transaction information includes a third tuple. The third tuple includes a data transmission case identifier, a confirmation message value, a first hash value, and a first random number.

[0287] When comparing blockchain transaction information with target transmission data, the comparison module 604 is specifically used for:

[0288] The ciphertext is decrypted using a temporary private key, generating a second decrypted message and a second random number. The corresponding confirmation message generation algorithm is determined based on the algorithm identifier. The corresponding second hash value is determined based on the confirmation message generation algorithm, the second random number, the confirmation message value, and the confirmation message parameters. The first and second hash values, as well as the first and second random numbers, are compared. If they are all the same, it is determined that the blockchain transaction information and the target transmitted data are identical.

[0289] Optionally, in this embodiment, the blockchain data transmission device 600 further includes:

[0290] The processing module receives case appeal requests from the data recipient. If the case data transmission status is "completed," it determines whether the following conditions are met:

[0291] The temporary private key does not match the ciphertext.

[0292] The third message generated after decrypting the ciphertext using the temporary private key is empty.

[0293] The third random number generated after decrypting the ciphertext using the temporary private key is different from the first random number.

[0294] The third hash value, determined by the confirmation message generation algorithm, the third random number, the confirmation message value, and the confirmation message parameters, is different from the first hash value.

[0295] If it is determined that not all of the above conditions are met, the data recipient is identified as a malicious party, and a data transmission security deposit is sent to the data sender. If it is determined that none of the above conditions are met, the data sender is identified as a malicious party, a data transmission security deposit is sent to the data recipient, and the data sender's identifier is added to a preset blacklist.

[0296] The blockchain data transmission device provided in this embodiment can execute... Figure 3 The technical solution of the method embodiment shown has the same implementation principle and technical effect as... Figure 3 The methods and embodiments shown are similar and will not be described in detail here.

[0297] According to embodiments of this application, this application also provides an electronic device, a computer-readable storage medium, and a computer program product.

[0298] like Figure 9 As shown, Figure 9 This is a schematic diagram of the electronic device provided in this application. The electronic device is intended for various forms of digital computers, such as laptop computers, desktop computers, workstations, personal digital assistants, blade servers, mainframe computers, and other suitable computers. The components shown herein, their connections and relationships, and their functions are merely illustrative and are not intended to limit the implementation of the present application described and / or claimed herein.

[0299] like Figure 9 As shown, the electronic device includes a processor 701 and a memory 702. The various components are interconnected via different buses and can be mounted on a common motherboard or installed in other ways as needed. The processor can process instructions executed within the electronic device.

[0300] The memory 702 is the non-transitory computer-readable storage medium provided in this application. The memory stores instructions executable by at least one processor to cause the at least one processor to execute the blockchain data transmission method provided in this application. The non-transitory computer-readable storage medium of this application stores computer instructions for causing a computer to execute the blockchain data transmission method provided in this application.

[0301] Memory 702, as a non-transitory computer-readable storage medium, can be used to store non-transitory software programs, non-transitory computer-executable programs, and modules, such as the program instructions / modules corresponding to the blockchain data transmission method in the embodiments of this application (e.g., attached...). Figure 6 The diagram shows a generation module 401, a first sending module 402, a second sending module 403, an acquisition module 404, and a transmission module 405. The processor 701 executes various functional applications and data processing of the electronic device by running non-transient software programs, instructions, and modules stored in the memory 702, thereby implementing the blockchain data transmission method in the above method embodiments.

[0302] In addition, this embodiment also provides a computer product, which, when the instructions in the computer product are executed by the processor of an electronic device, enables the electronic device to execute the blockchain data transmission method of the above embodiment.

[0303] Other embodiments of the present application will readily occur to those skilled in the art upon consideration of the specification and practice of the invention disclosed herein. This application is intended to cover any variations, uses, or adaptations of the embodiments of this application that follow the general principles of the embodiments of this application and include common knowledge or customary techniques in the art not disclosed in the embodiments of this application.

[0304] It should be understood that the embodiments of this application are not limited to the precise structures described above and shown in the accompanying drawings, and various modifications and changes can be made without departing from their scope. The scope of the embodiments of this application is limited only by the appended claims.

Claims

1. A blockchain data transmission method, characterized in that, Applied to a data receiver, where the data receiver, data sender, and smart contract communicate with each other, the method includes: A preset data generation algorithm is used to generate a data transmission case identifier, confirmation message parameters, and an asymmetric encryption key pair; the asymmetric encryption key pair includes a temporary public key and a temporary private key. Send the temporary public key, confirmation message parameters, and data transmission case identifier to the data sender; Send a data transmission request to the smart contract so that the smart contract sets the status of the data transmission case corresponding to the data transmission case identifier to requested based on the data transmission request. When the smart contract detects that the data transmission case status corresponding to the data transmission case identifier is confirmed, the target transmission data is obtained from the smart contract; the target transmission data is transmitted to the smart contract by the data sender when the data transmission case status is requested. The target transmission data is decrypted and hashed to generate corresponding blockchain transaction information, which is then transmitted to a smart contract. The smart contract compares the blockchain transaction information with the target transmission data, and if they match, modifies the data transmission case status to "completed." The target transmission data includes: an algorithm identifier and a second tuple; the second tuple includes a data transmission case identifier, a confirmation message value, and ciphertext. The step of decrypting and hashing the target transmitted data to generate corresponding blockchain transaction information includes: using the temporary private key to decrypt the ciphertext and generate a decrypted first message and a first random number; The first message and the data transmission case identifier are hashed to generate a first hash value; Generate the blockchain transaction information; the blockchain transaction information includes a third tuple; the third tuple includes the data transmission case identifier, the confirmation message value, the first hash value, and the first random number; The method further includes: after the data transmission case status is completed, if there is a dispute over the transmission result, sending a case protest request to the smart contract; the smart contract is configured to respond to the case protest request and, when determining that the data transmission case status is completed, perform a malicious behavior determination, the determination including: Determine whether at least one of the following conditions is met: The temporary private key does not match the ciphertext in the target transmitted data; The message generated after decrypting the ciphertext using the temporary private key is empty; The random number generated after decrypting the ciphertext using the temporary private key is different from the first random number in the blockchain transaction information. The hash value determined by the confirmation message generation algorithm, the random number generated after decryption, the confirmation message value in the target transmitted data, and the confirmation message parameters is different from the first hash value in the blockchain transaction information; If at least one of the above conditions is met, the data receiver is determined to be a malicious entity, and the data transmission deposit prepaid by the data receiver is sent to the data sender. If none of the above conditions are met, the data sender is determined to be a malicious entity, the data transmission deposit is sent to the data receiver, and the identifier of the data sender is added to a preset blacklist.

2. The method according to claim 1, characterized in that, The preset data generation algorithm includes: a preset random number generation algorithm, a preset confirmation parameter generation algorithm, and a preset key generation algorithm; the data transmission request includes a first tuple and a data transmission security deposit; the first tuple includes a data transmission case identifier, a confirmation message parameter, the asymmetric encryption key pair, a data receiver identifier, and a data sender identifier; The process of generating a data transmission case identifier, confirmation message parameters, and asymmetric encryption key pair using a preset data generation algorithm includes: A data transmission case identifier is generated using a preset random number generation algorithm; The confirmation message parameters are generated using a preset confirmation parameter generation algorithm; An asymmetric encryption key pair is generated using a preset key generation algorithm; the asymmetric encryption key pair includes a temporary public key and a temporary private key.

3. The method according to claim 1, characterized in that, The method further includes: When the data transmission case status is "completed", the confirmation message value is disclosed.

4. A blockchain data transmission method, characterized in that, Applied to the data sender, where the data sender, data receiver, and smart contract communicate with each other, the method includes: Receive the temporary public key, confirmation message parameters, and data transmission case identifier sent by the data recipient; When the smart contract sets the data transmission case status corresponding to the data transmission case identifier to be requested, the corresponding second hash value, second random number and confirmation message value are generated according to the second message to be transmitted, the data transmission case identifier, the confirmation message parameters and the preset data generation algorithm. The second message and the second random number are asymmetrically encrypted using a temporary public key to generate the corresponding ciphertext; Sending target transmission data to a smart contract, causing the smart contract to modify the data transmission case status corresponding to the data transmission case identifier to "confirmed" based on the target transmission data, and causing the smart contract to receive blockchain transaction information sent by the data receiver; the target transmission data includes an algorithm identifier and a second tuple; the second tuple includes a data transmission case identifier, a confirmation message value, and ciphertext; the blockchain transaction information includes a third tuple; the third tuple includes the data transmission case identifier, a confirmation message value, a first hash value, and a first random number; the first hash value is generated by hashing a first message and the data transmission case identifier; the first message and the first random number are generated by decrypting the ciphertext using the temporary private key; and causing the smart contract to compare the blockchain transaction information and the target transmission data, and modifying the data transmission case status to "completed" when the blockchain transaction information and the target transmission data are the same; if the data receiver disputes the transmission result after the data transmission case status is "completed," a case protest request is sent to the smart contract; the smart contract is configured to respond to the case protest request and, when determining that the data transmission case status is "completed," perform a malicious behavior determination, the determination including: Determine whether at least one of the following conditions is met: The temporary private key does not match the ciphertext in the target transmitted data; The message generated after decrypting the ciphertext using the temporary private key is empty; The random number generated after decrypting the ciphertext using the temporary private key is different from the first random number in the blockchain transaction information. The hash value determined by the confirmation message generation algorithm, the random number generated after decryption, the confirmation message value in the target transmitted data, and the confirmation message parameters is different from the first hash value in the blockchain transaction information; If at least one of the above conditions is met, the data receiver is determined to be a malicious entity, and the data transmission deposit prepaid by the data receiver is sent to the data sender. If none of the above conditions are met, the data sender is determined to be a malicious entity, the data transmission deposit is sent to the data receiver, and the identifier of the data sender is added to a preset blacklist.

5. The method according to claim 4, characterized in that, The preset data generation algorithm includes: a preset random number generation algorithm and a confirmation message generation algorithm; the algorithm identifier includes the identifier corresponding to the preset random number generation algorithm and the identifier corresponding to the confirmation message generation algorithm. The step of generating a corresponding second hash value, a second random number, and a confirmation message value based on the second message to be transmitted, the data transmission case identifier, the confirmation message parameters, and a preset data generation algorithm includes: The second message to be transmitted and the data transmission case identifier are hashed to generate a corresponding second hash value; the data transmission case identifier has a mapping relationship with the data sender identifier. A second random number is generated using a preset random number generation algorithm; An acknowledgment message generation algorithm is used to generate a corresponding acknowledgment message value based on the second random number, the second hash value, and the acknowledgment message parameters.

6. The method according to claim 5, characterized in that, After sending the target data to the smart contract, the process further includes: Check whether the data transmission case status is "requested"; If it is determined that the data transmission case status is not requested, a rejection message is sent to the smart contract.

7. A blockchain data transmission method, characterized in that, Applied to smart contracts, where a data sender, a data receiver, and the smart contract communicate with each other, the method includes: Receive a data transmission request sent by the data receiver, and set the corresponding data transmission case status to requested based on the data transmission request; The system receives target transmission data sent by the data sender and modifies the data transmission case status corresponding to the data transmission case identifier to "confirmed" based on the target transmission data. The target transmission data includes: an algorithm identifier and a second tuple; the second tuple includes the data transmission case identifier, a confirmation message value, and ciphertext. The system receives blockchain transaction information sent by a data recipient; the blockchain transaction information includes a third tuple; the third tuple includes a data transmission case identifier, a confirmation message value, a first hash value, and a first random number; the first hash value is generated by hashing a first message and the data transmission case identifier; the first message and the first random number are generated by decrypting the ciphertext using the temporary private key; Compare the blockchain transaction information with the target transmission data, and modify the data transmission case status to "completed" when the blockchain transaction information and the target transmission data are the same; The method further includes: Receive case appeal requests sent by the data recipient; If the data transfer case status is "completed", then determine whether the following conditions are met: The temporary private key does not match the ciphertext; The third message generated after decrypting the ciphertext using the temporary private key is empty; The third random number generated after decrypting the ciphertext using the temporary private key is different from the first random number. The third hash value, determined by the confirmation message generation algorithm, the third random number, the confirmation message value, and the confirmation message parameters, is different from the first hash value. If it is determined that the above conditions are not fully met, then the data recipient is determined to be a malicious object, and the data transmission deposit is sent to the data sender. If none of the above conditions are met, the data sender is determined to be a malicious entity, the data transmission deposit is sent to the data receiver, and the data sender's identifier is added to a preset blacklist.

8. The method according to claim 7, characterized in that, The data transmission request includes a first tuple and a data transmission security deposit; the first tuple includes a data transmission case identifier, a confirmation message parameter, an asymmetric encryption key, a data receiver identifier, and a data sender identifier; the asymmetric encryption key pair includes a temporary public key and a temporary private key. The step of setting the corresponding data transmission case status to "requested" according to the data transmission request includes: Verification processing is performed on the data receiver identifier and the data sender identifier; If the verification result is successful, the status of the data transmission case corresponding to the data transmission case identifier is set to requested, and the confirmation message parameters and the asymmetric encryption key pair are stored.

9. The method according to claim 8, characterized in that, The target transmission data includes an algorithm identifier and a second tuple; the algorithm identifier includes an identifier corresponding to a preset random number generation algorithm and an identifier corresponding to a confirmation message generation algorithm; the second tuple includes a data transmission case identifier, a confirmation message value, and ciphertext; the blockchain transaction information includes a third tuple; the third tuple includes the data transmission case identifier, the confirmation message value, a first hash value, and a first random number; The comparison of the blockchain transaction information and the target transmission data includes: The ciphertext is decrypted using the temporary private key to generate a decrypted second message and a second random number; The corresponding confirmation message generation algorithm is determined based on the algorithm identifier; The corresponding second hash value is determined based on the confirmation message generation algorithm, the second random number, the confirmation message value, and the confirmation message parameters. Compare whether the first hash value and the second hash value are the same, and whether the first random number and the second random number are the same; If they are the same, then the blockchain transaction information and the target transmission data are determined to be identical.

10. A blockchain data transmission device, characterized in that, Located at the data receiver, the data receiver, the data sender, and the smart contract communicate with each other. The device is used to implement the blockchain data transmission method according to any one of claims 1-3, and the device includes: The generation module is used to generate a data transmission case identifier, confirmation message parameters, and an asymmetric encryption key pair using a preset data generation algorithm; the asymmetric encryption key pair includes a temporary public key and a temporary private key. The first sending module is used to send a temporary public key, confirmation message parameters, and data transmission case identifier to the data sender; The second sending module is used to send a data transmission request to the smart contract, so that the smart contract sets the data transmission case status corresponding to the data transmission case identifier to requested according to the data transmission request. The acquisition module is used to acquire the target transmission data from the smart contract when it detects that the data transmission case status corresponding to the data transmission case identifier set by the smart contract is determined; the target transmission data is transmitted to the smart contract by the data sender when it detects that the data transmission case status is requested. The transmission module is used to decrypt and hash the target transmission data, generate corresponding blockchain transaction information, and transmit the blockchain transaction information to the smart contract. This allows the smart contract to compare the blockchain transaction information with the target transmission data, and if the blockchain transaction information and the target transmission data are the same, modify the data transmission case status to "completed".

11. A blockchain data transmission device, characterized in that, Located at the data sender, the data sender, the data receiver, and the smart contract communicate with each other. The device is used to implement the blockchain data transmission method according to any one of claims 4-6, and the device includes: The receiving module is used to receive the temporary public key, confirmation message parameters, and data transmission case identifier sent by the data receiver. The generation module is used to generate a corresponding second hash value, a second random number, and a confirmation message value based on the second message to be transmitted, the data transmission case identifier, the confirmation message parameters, and a preset data generation algorithm when the smart contract sets the data transmission case identifier to a requested state. The encryption module is used to perform asymmetric encryption on the second message and the second random number using a temporary public key to generate corresponding ciphertext; The sending module is used to send target transmission data to the smart contract, so that the smart contract modifies the data transmission case status corresponding to the data transmission case identifier to confirmed based on the target transmission data; the target transmission data includes an algorithm identifier and a second tuple; the second tuple includes a data transmission case identifier, a confirmation message value, and ciphertext.

12. A blockchain data transmission device, characterized in that, Located within a smart contract, the data sender, data receiver, and smart contract communicate with each other. The device is used to implement the blockchain data transmission method according to any one of claims 7-9, and the device includes: The setting module is used to receive data transmission requests sent by the data receiver and set the corresponding data transmission case status to requested according to the data transmission request. The modification module is used to receive the target transmission data sent by the data sender, and modify the data transmission case status corresponding to the data transmission case identifier to "confirmed" according to the target transmission data; The receiving module is used to receive blockchain transaction information sent by the data recipient; The comparison module is used to compare the blockchain transaction information with the target transmission data, and modify the data transmission case status to "completed" when the blockchain transaction information and the target transmission data are the same.

13. An electronic device, characterized in that, include: Memory and processor; The memory stores computer-executed instructions; The processor executes computer execution instructions stored in the memory to implement the blockchain data transmission method as described in any one of claims 1 to 9.

Images