Verification-based trusted on-chain method and apparatus, device, system, and readable storage medium

Abstract

Embodiments of the present disclosure provide a verification-based trusted on-chain method and apparatus, a device, a system, and a readable storage medium. The method comprises: acquiring a first data packet, the first data packet comprising a verification command, the verification command being used for instructing to verify whether first data has been authentically written into a distributed ledger, and the first data being data generated by a second node and intended to be written into the distributed ledger by means of a third node; verifying, on the basis of the verification command, whether the first data has been authentically written into the distributed ledger, to obtain a verification result; and sending a second data packet to the third node, the second data packet comprising the verification result, and the third node being used for sending the verification result to the second node.

Description

Verification-based trusted blockchain methods, apparatus, devices, systems, and readable storage media

[0001] Cross-references to related applications

[0002] This disclosure claims priority to Chinese Patent Application No. 202411179551.9, filed in China on August 27, 2024, the entire contents of which are incorporated herein by reference. Technical Field

[0003] This disclosure relates to the field of communication technology, specifically to a verification-based trusted on-chain method, apparatus, device, system, and readable storage medium. Background Technology

[0004] When data needs to be saved from off-chain to on-chain, if the data source device cannot be directly connected to the distributed ledger system, the data needs to be saved to the distributed ledger system through the boundary node (B-node) of the distributed ledger system as a proxy, as shown in Figure 1.

[0005] Traditional solutions cannot determine the trustworthiness of boundary nodes. When a boundary node acts maliciously and fails to actually write the data generated by the data source device into the distributed ledger system, neither the data source device nor other nodes in the distributed ledger system may be aware of this, leading to data loss, loss of trust, and potential system security risks. Summary of the Invention

[0006] This disclosure provides a verification-based trusted on-chain method, apparatus, device, system, and readable storage medium to address the issue of ensuring effective verification of boundary node operations when using boundary nodes, thereby guaranteeing the authenticity and reliability of data.

[0007] Firstly, a verification-based trusted on-chain method is provided, applied to the first node of a distributed ledger system, including:

[0008] Obtain a first data packet, the first data packet including a verification command, the verification command being used to instruct whether the first data is actually written to the distributed ledger, the first data being generated by the second node and intended to be written to the distributed ledger by the third node;

[0009] According to the verification command, verify whether the first data has actually been written to the distributed ledger, and obtain the verification result;

[0010] The third node sends a second data packet to the third node, the second data packet including the verification result, and the third node is used to send the verification result to the second node.

[0011] Optionally, obtain the first data packet, including:

[0012] Obtain a first data packet, the first data packet including the ciphertext of the verification command, the ciphertext being generated by the second node based on the first key;

[0013] The verification command is obtained by decrypting the ciphertext of the verification command using the second key.

[0014] Optionally, sending a second data packet to the third node includes:

[0015] The verification result is encrypted using a third key to obtain the ciphertext of the verification result;

[0016] The third node sends a second data packet to the third node, the second data packet including the ciphertext of the verification result, and the third node is used to send the ciphertext of the verification result to the second node.

[0017] Optionally, based on the verification command, verify whether the first data has actually been written to the distributed ledger, and obtain the verification result, including:

[0018] According to the verification command, the verification program of the first node verifies whether the first data has been actually written to the distributed ledger, and obtains the verification result;

[0019] Alternatively, based on the verification command, the first data can be verified by a smart contract deployed on the first node to determine whether it has actually been written to the distributed ledger, and the verification result can be obtained.

[0020] Optionally, the method further includes:

[0021] Based on the verification command, determine whether the first node is the verification node selected by the second node;

[0022] If the first node is the verification node selected by the second node, the step of verifying whether the first data has been actually written to the distributed ledger is executed according to the verification command.

[0023] Optionally, before verifying whether the first data has actually been written to the distributed ledger according to the verification command and obtaining the verification result, the method further includes:

[0024] The first data is obtained from the distributed ledger according to the verification command.

[0025] Optionally, the first data packet may also include the first data.

[0026] Optionally, the first data packet further includes: the signature of the second node, wherein the signature of the second node is generated by the second node based on the fourth key;

[0027] Before verifying whether the first data has actually been written to the distributed ledger according to the verification command and obtaining the verification result, the method further includes:

[0028] The signature of the second node is verified using the fifth key.

[0029] If the signature of the second node is valid, then it is determined that the verification command was generated by the second node.

[0030] Optionally, the second data packet may further include: the signature of the first node, which is generated by the first node using a sixth key.

[0031] Optionally, before or after verifying whether the first data has actually been written to the distributed ledger according to the verification command and obtaining the verification result, the method further includes:

[0032] Based on the verification result and the verification command, it is determined whether the third node actually wrote the first data into the distributed ledger.

[0033] Optionally, the first key and the second key are the same symmetric key, or the first key and the second key are a pair of public and private keys in an asymmetric key, or the fourth key and the fifth key are the same symmetric key, or the fourth key and the fifth key are a pair of public and private keys in an asymmetric key.

[0034] Optionally, the verification command includes: first information, which is used to explicitly or implicitly indicate one or more selected verification nodes; second information, which is used to indicate the verification range; and third information, which is used to indicate the algorithm for calculating the verification result.

[0035] Optionally, the verification command may also include the expected value of the verification result.

[0036] Optionally, the verification scope includes at least one of the following: second node information, relevant information about the data to be written to the distributed ledger, and time range information, wherein the time range information is used to indicate the data to be written to the distributed ledger that occurred within the time range to be verified.

[0037] Optionally, the relevant information of the data to be written into the distributed ledger includes at least one of the following: the value of the first data, the storage information of the first data, and the verification information of the first data.

[0038] Secondly, a verification-based trusted on-chain method is provided, applied to the second node, including:

[0039] A third data packet is sent to a third node. The third data packet includes a verification command, which is used to instruct the verification of whether the first data has been actually written to the distributed ledger. The first data is generated by the second node and is data that is expected to be written to the distributed ledger through the third node.

[0040] The system receives a fourth data packet sent by the third node, the fourth data packet including a verification result, the verification result being obtained by the first node of the distributed ledger system verifying whether the first data was actually written to the distributed ledger according to the verification command;

[0041] Based on the verification results, it is determined whether the third node actually wrote the first data into the distributed ledger.

[0042] Optionally, a third data packet is sent to the third node, including:

[0043] The verification command is encrypted using the first key to obtain the ciphertext of the verification command;

[0044] A third data packet is sent to the third node, the third data packet including the ciphertext of the verification command.

[0045] Optionally, receiving the fourth data packet sent by the third node includes:

[0046] The system receives a fourth data packet sent by the third node, the fourth data packet including the ciphertext of the verification result, the ciphertext of the verification result being obtained by the first node encrypting the verification result using a third key.

[0047] The verification result is obtained by decrypting the ciphertext of the verification result using the seventh key.

[0048] Optionally, the third data packet may also include the signature of the second node, which is generated by the second node using a fourth key.

[0049] Optionally, the fourth data packet may also include the signature of the first node, which is generated by the first node using a sixth key.

[0050] Optionally, the method further includes:

[0051] The validity of the first node's signature is verified using the eighth key;

[0052] If the signature is valid, then the verification result is determined to have been generated by the first node.

[0053] Optionally, the third key and the seventh key are the same symmetric key, or the third key and the seventh key are a pair of public and private keys in an asymmetric key.

[0054] Optionally, the sixth key and the eighth key are the same symmetric key, or the sixth key and the eighth key are a pair of public and private keys in an asymmetric key.

[0055] Thirdly, a verification-based trusted on-chain method is provided for application to third-party nodes, including:

[0056] The system receives a third data packet sent by the second node. The third data packet includes a verification command, which is used to instruct the system to verify whether the first data has been actually written to the distributed ledger. The first data is generated by the second node and is intended to be written to the distributed ledger by the third node.

[0057] A first data packet is sent to the first node of the distributed ledger system. The first data packet includes a verification command. The first node is used to verify whether the first data has been actually written to the distributed ledger according to the verification command and obtain a verification result.

[0058] Receive a second data packet sent by the first node, the second data packet including the verification result;

[0059] A fourth data packet, including the verification result, is sent to the second node.

[0060] Optionally, the first data packet includes the ciphertext of the verification command, and the third data packet includes the ciphertext of the verification command, wherein the ciphertext of the verification command is generated by the second node based on the first key.

[0061] Optionally, the second data packet includes the ciphertext of the verification result, and the fourth data packet includes the ciphertext of the verification result, wherein the ciphertext of the verification result is obtained by the first node encrypting the verification result using a third key.

[0062] Optionally, the first data packet further includes the signature of the second node; the third data packet further includes the signature of the second node, which is generated by the second node based on the fourth key.

[0063] Optionally, the second data packet further includes: the signature of the first node, and the fourth data packet further includes the signature of the first node, wherein the signature of the first node is generated by the first node using the sixth key.

[0064] Fourthly, a verification-based trusted on-chain device is provided for the first node of a distributed ledger system, comprising: a first sending and receiving unit and a first processing unit;

[0065] The first transceiver unit is used to acquire a first data packet, the first data packet including a verification command, the verification command being used to instruct whether the first data is actually written to the distributed ledger, the first data being generated by the second node and intended to be written to the distributed ledger by the third node;

[0066] The first processing unit is used to verify whether the first data has actually been written to the distributed ledger according to the verification command, and to obtain the verification result;

[0067] The first transceiver unit is further configured to send a second data packet to the third node, the second data packet including the verification result, and the third node is configured to send the verification result to the second node.

[0068] Fifthly, a verification-based trusted on-chain device is provided for use in a second node, comprising: a second transceiver unit and a second processing device;

[0069] The second transceiver unit is used to send a third data packet to the third node. The third data packet includes a verification command, which is used to instruct whether the first data is actually written to the distributed ledger. The first data is generated by the second node and is data that is expected to be written to the distributed ledger through the third node.

[0070] The second transceiver unit is also used to receive a fourth data packet sent by the third node. The fourth data packet includes a verification result, which is obtained by the first node of the distributed ledger system verifying whether the first data has been actually written into the distributed ledger according to the verification command.

[0071] The second processing device is used to determine, based on the verification result, whether the third node actually wrote the first data into the distributed ledger.

[0072] Sixthly, a verification-based trusted on-chain device is provided for use in a third node, comprising: a third transceiver unit and a third processing device;

[0073] The third transceiver unit is used to receive a third data packet sent by the second node. The third data packet includes a verification command. The verification command is used to instruct whether the first data is actually written to the distributed ledger. The first data is generated by the second node and is data that is expected to be written to the distributed ledger through the third node.

[0074] The third transceiver unit is also used to send a first data packet to the first node of the distributed ledger system. The first data packet includes a verification command. The first node is used to verify whether the first data has been actually written to the distributed ledger according to the verification command and obtain a verification result.

[0075] The third transceiver unit is also configured to receive a second data packet sent by the first node, the second data packet including the verification result;

[0076] The third transceiver unit is also used to send a fourth data packet to the second node, the fourth data packet including a verification result.

[0077] A seventh aspect provides a first node including a processor, a memory, and a program or instructions stored in the memory and executable on the processor, wherein the program or instructions, when executed by the processor, implement the steps of the method described in the first aspect.

[0078] Eighth aspect, a second node is provided, including a processor, a memory, and a program or instructions stored in the memory and executable on the processor, wherein the program or instructions, when executed by the processor, implement the steps of the method as described in the second aspect.

[0079] A ninth aspect provides a third node including a processor, a memory, and a program or instructions stored in the memory and executable on the processor, wherein the program or instructions, when executed by the processor, implement the steps of the method described in the third aspect.

[0080] In a tenth aspect, a distributed ledger system is provided, comprising a first node as described in the seventh aspect, a second node as described in the eighth aspect, and a third node as described in the ninth aspect.

[0081] Eleventhly, a readable storage medium is provided, on which a program or instructions are stored, which, when executed by a processor, implement the steps of the method as described in the first, second, or third aspect.

[0082] In a twelfth aspect, a computer program product is provided, including computer instructions that, when executed by a processor, implement the steps of the method described in the first, second, or third aspect.

[0083] In this disclosure, a first node verifies whether a third node has indeed written the first data generated by a second node into the distributed ledger. The first node then sends the verification result to the second node through the third node. This effectively verifies the third node's operation and notifies the second node of the verification result, thereby ensuring the authenticity and reliability of the data and achieving transparency and traceability in the data transmission process. This mechanism not only enhances the system's security but also increases user trust in the reliability of the data, thus optimizing overall operational efficiency. Attached Figure Description

[0084] Various other advantages and benefits will become apparent to those skilled in the art upon reading the following detailed description of preferred embodiments. The accompanying drawings are for illustrative purposes only and are not intended to limit the scope of this disclosure. Furthermore, the same reference numerals denote the same parts throughout the drawings. In the drawings:

[0085] Figure 1 is a schematic diagram of writing off-chain data into a distributed ledger system;

[0086] Figure 2 is a schematic diagram of an off-chain data writing to a distributed ledger system provided by an embodiment of this disclosure;

[0087] Figure 3 is a flowchart of a verification-based trusted on-chain method provided by an embodiment of this disclosure;

[0088] Figure 4 is a flowchart of another verification-based trusted on-chain method provided by an embodiment of this disclosure;

[0089] Figure 5 is a flowchart of yet another verification-based trusted on-chain method provided by an embodiment of this disclosure;

[0090] Figure 6 is a schematic diagram of the interaction between the first node, the second node, and the third node provided in an embodiment of this disclosure;

[0091] Figure 7 is a flowchart of yet another verification-based trusted on-chain method provided by an embodiment of this disclosure;

[0092] Figure 8 is a schematic diagram of a verification-based trusted on-chain device provided by an embodiment of this disclosure;

[0093] Figure 9 is a schematic diagram of another verification-based trusted on-chain device provided by an embodiment of this disclosure;

[0094] Figure 10 is a schematic diagram of yet another verification-based trusted on-chain device provided by an embodiment of this disclosure;

[0095] Figure 11 is a schematic diagram of a communication device provided in an embodiment of this disclosure. Detailed Implementation

[0096] The technical solutions of the embodiments of this disclosure will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some, not all, of the embodiments of this disclosure. Based on the embodiments of this disclosure, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this disclosure.

[0097] The term "comprising," and any variations thereof, used in this disclosure and the claims are intended to cover a non-exclusive inclusion. For example, a process, method, system, product, or apparatus that includes a series of steps or units is not necessarily limited to those explicitly listed, but may include other steps or units not explicitly listed or inherent to such process, method, product, or apparatus. Furthermore, the use of "and / or" in the specification and claims indicates at least one of the connected objects, such as A and / or B, indicating the inclusion of A alone, B alone, or both A and B.

[0098] In this disclosure, the terms "exemplary" or "for example" are used to indicate that something is an example, illustration, or description. Any embodiment or design described as "exemplary" or "for example" in this disclosure should not be construed as being more preferred or advantageous than other embodiments or designs. Specifically, the use of terms such as "exemplary" or "for example" is intended to present the relevant concepts in a specific manner.

[0099] As shown in the architecture of Figure 1, some data source devices (such as IoT devices) lack sufficient resources (computing, storage, and network connectivity are insufficient to run the blockchain protocol stack or directly access the distributed ledger system), and therefore need to use a boundary node (B-node) as their proxy.

[0100] Ideally, the data source device collects IoT data (such as sensor readings) and submits it to the boundary node (B-node) of the distributed ledger system. The distributed ledger system client of the B-node initiates a Distributed Ledger Technology (DLT) write transaction to save the IoT data to the distributed ledger, and then notifies the data source device that the data has been saved to the distributed ledger system.

[0101] In reality, if the boundary nodes (B-nodes) of a distributed ledger system are dishonest or compromised, it is possible that: IoT data is not written to the distributed ledger system but is discarded directly, while falsely reporting to the data source device that the data has been written.

[0102] (1) Since the data source device cannot be directly connected to the distributed ledger system, it is also impossible to know whether the data has been written to the distributed ledger.

[0103] (2) Meanwhile, other nodes on the distributed ledger system are unaware that the data source device is attempting to write the data.

[0104] This data was lost without a trace.

[0105] To address the aforementioned technical problems, embodiments of this disclosure provide a verification-based trusted on-chain method, apparatus, device, system, and readable storage medium.

[0106] In this disclosure, "distributed ledger" can also be replaced with "blockchain".

[0107] In this disclosure, "Distributed Ledger Technology (DLT)" can also be replaced with "blockchain technology".

[0108] The term "Distributed Ledger System" in this disclosure can also be replaced with "blockchain system".

[0109] Referring to Figure 2, one or more verification nodes are configured on the distributed ledger system. These verification nodes are used to verify whether the boundary nodes have written the data generated by the data source device into the distributed ledger.

[0110] Optionally, the data source device establishes an encrypted communication mechanism with the verification nodes of the distributed ledger system to conduct confidential interactions, thereby verifying whether the boundary nodes have written the data generated by the data source device into the distributed ledger. Because the interaction is confidential, the boundary nodes cannot interfere, ensuring the validity of the verification operation between the data source device and the verification nodes.

[0111] Referring to Figure 3, an embodiment of this disclosure provides a verification-based trusted on-chain method, applied to the first node of a distributed ledger system, with specific steps including: step 31, step 32 and step 33.

[0112] Step 31: Obtain the first data packet, which includes a verification command. The verification command is used to instruct whether the first data is actually written to the distributed ledger. The first data is generated by the second node and is intended to be written to the distributed ledger by the third node.

[0113] In this disclosure, the second node cannot directly access the distributed ledger system; it needs to access the distributed ledger system through a third node.

[0114] Optionally, the first node can also be called the verification node.

[0115] Optionally, the second node can also be called a data source device, such as an IoT sensor.

[0116] Optionally, the third node can also be called the boundary node of the distributed ledger system.

[0117] Referring to Figure 6, the second node can be pre-configured with a first key for encrypting verification commands, a fourth key for signing the second node, a seventh key for decrypting verification results, and an eighth key for verifying the first node's signature. The first node can be pre-configured with a second key for decrypting verification commands, a fifth key for verifying the second node's signature, a third key for encrypting verification results, and a sixth key for signing the first node. Optionally, the first and second keys can be symmetric keys (i.e., two identical keys) or they can form an asymmetric public-private key pair, in which case the first key is the first node's public key and the second key is the first node's private key. Optionally, the fourth and fifth keys can be symmetric keys (i.e., two identical keys) or they can form an asymmetric public-private key pair, in which case the fourth key is the second node's private key and the fifth key is the second node's public key. Optionally, the third and seventh keys can be symmetric keys (i.e., two identical keys) or they can form an asymmetric public-private key pair, in which case the third key is the second node's public key and the seventh key is the second node's private key. Optionally, the sixth and eighth keys can be symmetric keys, meaning the two keys are the same, or they can form an asymmetric key pair of public and private keys. In this case, the sixth key is the private key of the first node, and the eighth key is the public key of the first node.

[0118] Optionally, the first data can also be referred to as the data load.

[0119] Optionally, the verification command can be generated (or constructed) by the second node.

[0120] In one embodiment of this disclosure, the verification command includes:

[0121] 1) First information, which is used to explicitly or implicitly indicate one or more selected verification nodes;

[0122] 2) Second information, which is used to indicate the verification range;

[0123] Optionally, the verification scope includes at least one of the following: second node information (i.e., data source device information), relevant information of the data to be written to the distributed ledger, and time range information, wherein the time range information is used to indicate the data to be written to the distributed ledger that occurred within the time range to be verified.

[0124] Optionally, the relevant information of the data to be written into the distributed ledger includes at least one of the following: the value of the first data, the storage information of the first data, and the verification information of the first data.

[0125] 3) Third information, which is used to indicate the algorithm for calculating the verification results;

[0126] Optionally, the algorithm for verifying the result includes, but is not limited to, hash algorithms, other algorithms, such as symmetric encryption algorithms, digital signature algorithms, etc.

[0127] Furthermore, optionally, the verification command may also include the expected value of the verification result.

[0128] Specifically, the first node can use the expected value and the verification result to determine whether the third node has actually written the first data into the distributed ledger.

[0129] Optionally, the first node can obtain the first data packet directly from the third node, or the first node can obtain the first data packet from other nodes in the distributed ledger system.

[0130] Step 32: According to the verification command, verify whether the first data has been actually written to the distributed ledger, and obtain the verification result;

[0131] For example, information related to the first data is retrieved in the distributed ledger according to the verification command, and a verification result is generated based on the relevant information. The verification result includes whether the third node has written the first data to the distributed ledger or whether the third node has not written the first data to the distributed ledger.

[0132] Step 33: Send a second data packet to the third node, the second data packet including the verification result, the third node being used to send the verification result to the second node.

[0133] In this disclosure, after the first node sends the second data packet to the third node, the third node can send the verification result to the second node. In this way, the second node can determine whether the third node has actually written the first data into the distributed ledger through the verification result.

[0134] In one embodiment of this disclosure, obtaining the first data packet includes:

[0135] Obtain a first data packet, the first data packet including the ciphertext of the verification command, the ciphertext being generated by the second node based on the first key;

[0136] The verification command is obtained by decrypting the ciphertext of the verification command using the second key.

[0137] Optionally, the first data packet can also be called the verification command data packet.

[0138] Optionally, the first data packet may also include first data.

[0139] In one embodiment of this disclosure, sending a second data packet to the third node includes:

[0140] The verification result is encrypted using a third key to obtain the ciphertext of the verification result;

[0141] The third node sends a second data packet to the third node, the second data packet including the ciphertext of the verification result, and the third node is used to send the ciphertext of the verification result to the second node.

[0142] Optionally, the second data packet can also be called a verification command data packet.

[0143] Optionally, the second data packet further includes: the signature of the first node, which is generated by the first node using the sixth key.

[0144] In this disclosure, the second node and the first node establish an encrypted communication mechanism to conduct confidential interaction in order to verify whether the third node has written data into the distributed ledger. Because the interaction is confidential, the third node cannot interfere, ensuring the validity of the verification operation between the second and first nodes.

[0145] In one embodiment of this disclosure, verifying whether the first data has actually been written to the distributed ledger according to the verification command, and obtaining the verification result, includes:

[0146] According to the verification command, the verification program of the first node verifies whether the first data has been actually written to the distributed ledger, and obtains the verification result.

[0147] Alternatively, based on the verification command, the first data can be verified by a smart contract deployed on the first node to determine whether it has actually been written to the distributed ledger, and the verification result can be obtained.

[0148] In this disclosure, the verification procedure of the first node verifies whether the first data has been truly written to the distributed ledger according to the verification command, ensuring the accuracy and integrity of the data. This process provides an automated verification mechanism, reducing the need for manual intervention and improving efficiency.

[0149] Furthermore, smart contracts can be used to verify whether the first data has been truly written to the distributed ledger, enabling transparent execution of verification rules and ensuring consistency and immutability of operations. This technology not only improves system security but also enhances user trust in the authenticity of information. The use of smart contracts makes all verification logic publicly verifiable on the blockchain, auditable by anyone. Simultaneously, when conditions are met, the verification process runs automatically, ensuring that the confirmation and recording of the first data is efficient and secure. In summary, this method, by combining smart contracts and verification procedures, not only optimizes the data verification process but also improves the reliability and transparency of the entire distributed ledger system, providing a higher level of security and trust for all participants.

[0150] In one embodiment of this disclosure, the method further includes:

[0151] Based on the verification command, determine whether the first node is the verification node selected by the second node;

[0152] If the first node is the verification node selected by the second node, the step of verifying whether the first data has been actually written to the distributed ledger is executed according to the verification command.

[0153] In this disclosure, determining whether the first node is the verification node selected by the second node based on the verification command enables efficient and secure verification in a distributed environment. Firstly, this determination mechanism ensures that only selected verification nodes can participate in data verification, thus preventing unauthorized access or potential malicious behavior. This method improves network security, reduces the attack surface, and enhances control over the verification process. Furthermore, once the first node is confirmed as a verification node, verification steps can be executed promptly to check whether the first data has been truly written to the distributed ledger. Through an explicit selection process, the system provides transparency, ensuring that every operation is recorded and traceable, facilitating subsequent auditing and traceability. In summary, this method guarantees the integrity and authenticity of the distributed ledger while optimizing resource allocation, making the verification process more efficient and reliable, ensuring the entire system operates according to predetermined rules, and improving user trust and system stability.

[0154] In one embodiment of this disclosure, before verifying whether the first data has actually been written to the distributed ledger according to the verification command and obtaining the verification result, the method further includes:

[0155] The first data is obtained from the distributed ledger according to the verification command.

[0156] In this disclosure, by extracting the required first data directly from the distributed ledger, data consistency can be improved and potential data biases can be reduced, ensuring that the basis for verification is real-time and reliable.

[0157] In one embodiment of this disclosure, the first data packet further includes: a signature of the second node, wherein the signature of the second node is generated by the second node based on a fourth key;

[0158] Before verifying whether the first data has actually been written to the distributed ledger according to the verification command and obtaining the verification result, the method further includes:

[0159] The signature of the second node is verified using the fifth key.

[0160] If the signature is valid, then the verification command is determined to have been generated by the second node.

[0161] In this disclosure, verifying the validity of the signature using a fifth key and confirming that the verification command was generated by the second node significantly enhances the system's security and trustworthiness. This process ensures that only authorized second nodes can submit valid verification commands, thereby preventing unauthorized access and potential security threats. By verifying the signature, the integrity of transmitted information and the authenticity of its source can be guaranteed, avoiding the risk of forged or tampered data. Once the signature is confirmed to be valid, the first node can perform subsequent first data verification operations based on the verification command, forming a secure closed loop. This process not only increases the auditing capabilities of all interactions but also makes the execution of transactions and verification processes more transparent and reliable for all participants. Overall, this method enhances the security of the entire distributed ledger system, improves the traceability and trustworthiness of the data verification process, provides users with higher protection, and enables it to operate more smoothly and securely in complex network environments.

[0162] In one embodiment of this disclosure, before or after verifying whether the first data has been truly written to the distributed ledger according to the verification command and obtaining the verification result, the method further includes:

[0163] Based on the verification result and the verification command, it is determined whether the third node actually wrote the first data into the distributed ledger.

[0164] Optionally, the verification command includes the expected value of the verification result generated by the second node. The first node determines whether the third node has actually written the first data into the distributed ledger based on the expected value of the verification result and the verification result obtained by the first node.

[0165] In this disclosure, by including the expected value of the verification result generated by the second node in the verification command, the first node can effectively determine whether the third node has actually written the first data into the distributed ledger, that is, the first node can identify whether the third node is trustworthy.

[0166] In this disclosure, a first node verifies whether a third node has indeed written the first data generated by a second node into the distributed ledger. The first node then sends the verification result to the second node through the third node. This effectively verifies the third node's operation and notifies the second node of the verification result, thereby ensuring the authenticity and reliability of the data and achieving transparency and traceability in the data transmission process. This mechanism not only enhances the system's security but also increases user trust in the reliability of the data, thus optimizing overall operational efficiency.

[0167] Referring to Figure 4, an embodiment of this disclosure provides a verification-based trusted on-chain method applied to a second node, including steps 41, 42, and 43.

[0168] Step 41: Send a third data packet to the third node. The third data packet includes a verification command. The verification command is used to instruct whether the first data has been actually written to the distributed ledger. The first data is generated by the second node and is data that is expected to be written to the distributed ledger through the third node.

[0169] In this disclosure, the verification command is constructed by the second node.

[0170] Step 42: Receive the fourth data packet sent by the third node. The fourth data packet includes a verification result. The verification result is obtained by the first node of the distributed ledger system verifying whether the first data has been actually written to the distributed ledger according to the verification command.

[0171] Optionally, the third and fourth data packets can also be called verification command data packets.

[0172] Step 43: Based on the verification results, determine whether the third node actually wrote the first data into the distributed ledger.

[0173] It is understandable that a second node can send a third data packet to one or more third nodes, and the second node can also receive a fourth data packet from one or more third nodes. The second node can determine whether the third node has actually written the first data into the distributed ledger based on one or more verification results.

[0174] In this disclosure, the second node can determine whether the third node actually wrote the first data into the distributed ledger based on the verification results, that is, the second node can identify whether the third node is trustworthy.

[0175] In one embodiment of this disclosure, sending a third data packet to a third node includes:

[0176] The verification command is encrypted using the first key to obtain the ciphertext of the verification command;

[0177] A third data packet is sent to the third node, the third data packet including the ciphertext of the verification command.

[0178] In this disclosure, the security and privacy of the verification process are ensured by sending a third data packet containing the encrypted verification command to a third node. Encrypting the verification command using a first key effectively prevents unauthorized access and data leakage, ensuring that only the target node can decrypt and process the command. This method enhances the security of data transmission and improves the reliability of the system in a distributed environment.

[0179] In one embodiment of this disclosure, receiving the fourth data packet sent by the third node includes:

[0180] The system receives a fourth data packet sent by the third node, the fourth data packet including the ciphertext of the verification result, the ciphertext of the verification result being obtained by the first node encrypting the verification result using a third key;

[0181] The verification result is obtained by decrypting the ciphertext of the verification result using the seventh key.

[0182] Optionally, the third and seventh keys can be symmetric keys, meaning the two keys are the same, or they can form an asymmetric key pair of public and private keys. In this case, the third key is the public key of the second node, and the seventh key is the private key of the second node.

[0183] In this disclosure, by receiving the fourth data packet and decrypting the ciphertext of the verification result within it, the second node can securely obtain the verification result, thereby ensuring data integrity and reliability. Using the seventh key to decrypt the verification result effectively prevents data tampering or leakage that may occur during transmission. This method enhances system security and ensures that only authorized nodes can access sensitive information.

[0184] In one embodiment of this disclosure, the third data packet further includes the signature of the second node, which is generated by the second node using a fourth key.

[0185] In one embodiment of this disclosure, the fourth data packet further includes the signature of the first node, which is generated by the first node using a sixth key.

[0186] In one embodiment of this disclosure, the method further includes:

[0187] The validity of the first node's signature is verified using the eighth key;

[0188] If the signature is valid, then the verification result is determined to have been generated by the first node.

[0189] Optionally, the sixth key and the eighth key are the same symmetric key, or the sixth key and the eighth key are a pair of public and private keys in an asymmetric key.

[0190] In this embodiment, by sending a third data packet containing a verification command to the third node, the second node can track the data status in real time. After receiving the verification result in the fourth data packet, the second node can determine whether the third node has truly completed the data writing. This mechanism improves the transparency of the operation, enhances the supervision of the behavior of each participant, makes the entire system more secure and trustworthy in data processing, and significantly improves user trust and system efficiency.

[0191] Referring to Figure 5, the embodiments of this disclosure provide a verification-based trusted on-chain method applied to a third node, and the specific steps include: step 51, step 52, step 53 and step 54.

[0192] Step 51: Receive a third data packet sent by the second node. The third data packet includes a verification command. The verification command is used to instruct whether the first data has been actually written to the distributed ledger. The first data is generated by the second node and is data that is expected to be written to the distributed ledger through the third node.

[0193] Step 52: Send a first data packet to the first node. The first data packet includes a verification command. The first node is used to verify whether the first data has been actually written to the distributed ledger according to the verification command to obtain a verification result.

[0194] Step 53: Receive the second data packet sent by the first node, the second data packet including the verification result;

[0195] Step 54: Send a fourth data packet to the second node, the fourth data packet including the verification result.

[0196] In one embodiment of this disclosure, the first data packet includes the ciphertext of the verification command, which is generated by the second node based on the first key.

[0197] Optionally, the first data packet may also include the signature of the second node, which is generated by the second node based on the fourth key.

[0198] In one embodiment of this disclosure, the third data packet includes the ciphertext of the verification command.

[0199] Optionally, the third data packet may also include the signature of the second node.

[0200] In one embodiment of this disclosure, the second data packet includes the ciphertext of the verification result, which is obtained by the first node encrypting the verification result using a third key.

[0201] Optionally, the second data packet further includes: the signature of the first node, which is generated by the first node using the sixth key.

[0202] In one embodiment of this disclosure, the fourth data packet includes the ciphertext of the verification result.

[0203] Optionally, the fourth data packet may also include the signature of the first node, which is generated by the first node using the sixth key.

[0204] In this embodiment, by receiving a third data packet containing a verification command, the third node can effectively initiate a verification request for the first data and send the request to the first node of the distributed ledger system. After receiving the verification result, the third node encapsulates it in a fourth data packet and sends it back to the second node, thereby providing timely and accurate information feedback. This mechanism not only improves the efficiency of data interaction but also strengthens the trust relationship between nodes, ensuring the security and reliability of the overall system.

[0205] The following example uses the first node as the verification node (i.e., the DLT system verification node), the second node as the data source device, the third node as the boundary node (i.e., the DLT system boundary node), and the first data as the data load.

[0206] Referring to Figure 7, the overall process includes: preparation phase, distributed ledger writing phase, and distributed ledger writing verification phase.

[0207] I. Preparation Stage:

[0208] 1. Data source device: Configure the verification key and verification program (data source side program). The verification key corresponds to the verification node.

[0209] Optionally, the data source device is a device that generates and stores data, and the data source device may include devices such as sensors and servers.

[0210] Optionally, the verification key is an encryption key used to ensure the legitimacy of the data source and protect the integrity of the data. Each data source device has a corresponding verification key, which corresponds to a verification node in the distributed ledger system.

[0211] For example, the data source device deploys a first key for encrypting verification commands, a fourth key for signing the data source device, a seventh key for decrypting verification results, and an eighth key for verifying the signature of the verification node.

[0212] Optionally, the validator can be software running on the data source device to perform data verification and transmission operations. The validator is able to push the required data and related information to the distributed ledger in the correct format.

[0213] 2. Deploy one or more verification nodes on the distributed ledger system; configure verification keys and verification programs (verification node-side programs) on the verification nodes, and the verification keys correspond to the data source devices.

[0214] For example, the verification node can be pre-configured with a second key for decrypting verification commands, a fifth key for verifying the signature of the data source device, a third key for encrypting the verification result, and a sixth key for signing the verification node.

[0215] Optionally, a verification node can be a computing node in a distributed ledger system, responsible for receiving, verifying, and storing data submitted from data source devices. Each verification node is configured with its own verification key and verification procedure (i.e., the verification node-side procedure).

[0216] Optionally, the verification process runs on the verification node to receive data from the data source device, verify the data using the corresponding verification key, and write the valid data into the distributed ledger.

[0217] Optionally, the verification keys on the data source device side and the verification node side can be symmetric keys or asymmetric keys. For example, a public key can be used for encryption, and a private key can be used for decryption. For instance, the first and second keys can be symmetric keys (i.e., the two keys are the same), or they can form an asymmetric public-private key pair, in which case the first key is the public key of the first node, and the second key is the private key of the first node. Optionally, the fourth and fifth keys can be symmetric keys (i.e., the two keys are the same), or they can form an asymmetric public-private key pair, in which case the fourth key is the private key of the second node, and the fifth key is the public key of the second node. Optionally, the third and seventh keys can be symmetric keys (i.e., the two keys are the same), or they can form an asymmetric public-private key pair, in which case the third key is the public key of the second node, and the seventh key is the private key of the second node. Optionally, the sixth and eighth keys can be symmetric keys (i.e., the two keys are the same), or they can form an asymmetric public-private key pair, in which case the sixth key is the private key of the first node, and the eighth key is the public key of the first node.

[0218] Optionally, each pair of data source devices and the verification nodes of the distributed ledger system may use different verification keys; or, a combination of 1 data source device and N verification nodes may use 1 set of verification keys; or, a combination of N data source devices and 1 verification node may use 1 set of verification keys; or, a combination of M data source devices and N verification nodes may use 1 set of verification keys.

[0219] Optionally, the verification procedures deployed on the verification nodes in a distributed ledger system can be implemented through smart contracts.

[0220] A smart contract is a computer program that automatically executes, manages, and records protocols or transactions. It can be deployed on data source devices and verification nodes. Smart contracts can automatically complete predefined operations when specific conditions are met, and they are immutable and transparent.

[0221] II. Distributed Ledger Writing Phase:

[0222] Step 11: The data source device generates a data payload;

[0223] Optionally, the data load can be a one-time reading collected by an IoT sensor, such as a water meter reading, an electricity meter reading, or a temperature measurement.

[0224] Optionally, the data load includes at least one of the following:

[0225] 1) Values ​​read by the sensor: for example, temperature, humidity, or power consumption at a certain point in time.

[0226] 2) Timestamp: Indicates the time of data collection, to facilitate subsequent data analysis and processing.

[0227] 3) Device identification information: Identify the sensor or device that generated the data to ensure that the source of the data can be traced.

[0228] Step 12-1: The data source device selects a verification node, constructs a verification command, and encrypts and signs it, as follows:

[0229] (1) Select the verification node to perform this verification operation from the data source device;

[0230] (2) Generate verification command.

[0231] Optionally, the verification command includes: first information, which explicitly or implicitly indicates one or more selected verification nodes; second information, which indicates the verification range; and third information, which indicates the algorithm for calculating the verification result. Optionally, the verification command may also include the expected value of the verification result.

[0232] (3) Encrypt the verification command based on the verification key.

[0233] Optionally, in step 12-1, the data source device may select one or more verification nodes.

[0234] Optionally, the first information includes any of the following:

[0235] (1) Explicitly indicate information about the selected verification node, such as the identifier of the verification node;

[0236] (2) Implicitly indicate the information of the selected verification node, which may be some kind of information agreed upon in advance by the data source device and the verification node.

[0237] For example, a hash value can be used to implicitly indicate a verification node: Hash(verification node identifier, verification key), where Hash represents the function used to calculate the hash value.

[0238] Optionally, the verification scope may include at least one of the following:

[0239] (1) Data source device information, such as the identifier of the data source device, indicating that the data submitted by the data source needs to be verified;

[0240] (2) Information related to the data load to be written to the distributed ledger;

[0241] Optionally, the relevant information may include at least one of the following: ① the value of the data payload; ② the storage information of the data payload, such as the block identifier and transaction identifier of the data; ③ the verification information of the data payload, such as the hash value of the data payload.

[0242] (3) Time range information, which is used to represent the data load written to the distributed ledger that is to be verified within the time range.

[0243] Optionally, in step 12-1, the algorithm for calculating the verification result may include, but is not limited to, a hash algorithm, or other calculation algorithms.

[0244] For example, the algorithm for calculating the verification result could be a function that calculates a hash value:

[0245] Hash (verification node information, data payload information retrieved from the distributed ledger, verification result calculation algorithm, verification key);

[0246] That is, the hash value is obtained by performing a hash operation on the "verification node information, data load information queried from the distributed ledger, verification result calculation algorithm, and verification key" in the parentheses of the above formula.

[0247] Optionally, in step 12-1, the verification command may also include the expected value of the verification result.

[0248] The expected value of the validation result refers to the result that the data source device expects to obtain after performing the validation operation. This expected value is typically used to compare and verify the actual returned result to confirm the validity and integrity of the data.

[0249] The expected value of the verification result sets a reference standard for the verification process, enabling verification nodes to accurately determine the reliability and compliance of received data. By providing the expected value, verification nodes can quickly determine whether the received data conforms to predetermined rules, thereby deciding on the next processing steps. If the actual result does not match the expected value, it may indicate that the data has been tampered with or is incorrect.

[0250] Optionally, in step 12-1, when the data source device encrypts the verification command, it can also calculate a digital signature based on the verification key, which serves as part of the verification command. This allows the verification node to confirm that the issuer of the verification command is indeed the data source device.

[0251] Optionally, a digital signature is an encryption technique used to verify the origin and integrity of information. The data source device uses its verification key to generate a unique signature for the verification command, proving that the command was issued by the data source device.

[0252] Optionally, the data source device first calculates the hash value of the verification command (i.e., the unique representation of the verification command), and then uses the verification key to encrypt the hash value to generate a signature.

[0253] Step 13-1: The data source device submits the data payload, the encrypted verification command, and the signature to the boundary node.

[0254] Step 14-1: The boundary node initiates a transaction request to write to the distributed ledger system, writing the data payload, verification command ciphertext, and signature to the distributed ledger system.

[0255] Step 15-1: The distributed ledger system successfully writes the data payload, verification command ciphertext, and signature.

[0256] Step 16: The boundary node obtains the write result of the data payload from the distributed ledger system.

[0257] The write result is the result of the distributed ledger write operation.

[0258] Step 17: The boundary node sends the write results back to the data source device.

[0259] Optionally, steps 14-1 to 15-1, the process of the verification command being passed to the distributed ledger system and read and parsed by the verification nodes, can be performed in any of the following ways:

[0260] (1) Ledger relay: The boundary node initiates a distributed ledger transaction request, writes the data payload into the distributed ledger, and writes the verification command into the distributed ledger at the same time; the verification node reads the verification command from the distributed ledger;

[0261] (2) Direct sending: The boundary node sends a request directly to the verification node, such as a Remote Procedure Call Protocol (RPC) request or a Hypertext Transfer Protocol (HTTP) request.

[0262] As shown in steps 12-2 to 15-2: When there is no data load to write to the distributed ledger, the data source device can also initiate a separate verification request.

[0263] Step 12-2: The data source device selects a verification node, constructs a verification command, and encrypts and signs it.

[0264] Step 12-2 can be referred to the description of step 12-1.

[0265] Step 13-2: The data source device submits the encrypted verification command and signature to the boundary node.

[0266] Step 14-2: The boundary node initiates a transaction request to write to the distributed ledger system, writing the ciphertext of the verification command and the signature into the distributed ledger system.

[0267] Step 15-2: The distributed ledger system successfully wrote the ciphertext and signature of the verification command.

[0268] III. Distributed Ledger Write Verification Phase

[0269] Step 21: The verification node reads the ciphertext of the verification command from the distributed ledger and decrypts it; if it can decrypt it, it further determines whether it has been selected to perform the verification operation and parses the specific content of the verification command.

[0270] Step 22: Based on the verification scope, read the information (or content) to be verified from the distributed ledger.

[0271] Optionally, the verification scope includes at least one of the following: second node information, relevant information about the data to be written to the distributed ledger, and time range information, wherein the time range information is used to indicate the data to be written to the distributed ledger that occurred within the time range to be verified.

[0272] Step 23-1: Calculate the verification result based on the verification result calculation algorithm in the verification command, and then encrypt it.

[0273] Step 24: Send the verification results to the boundary node.

[0274] Step 25: The boundary node sends the verification results back to the data source device.

[0275] Step 26: The data source device receives and parses the verification results to determine whether the data payload to be verified has been actually written to the distributed ledger.

[0276] Optionally, in step 21, when the verification node decrypts the verification command, if the verification command also contains a signature, the verification node can simultaneously verify whether the signature is valid in order to determine whether the sender of the verification command is the claimed data source device.

[0277] Optionally, in step 21, the verification node can determine whether it is a verification node selected by the data source device based on the verification command. For example, the verification command carries first information for explicitly or implicitly indicating one or more selected verification nodes, and the verification node can determine whether it is a verification node selected by the data source device based on the first information.

[0278] Optionally, in step 23-1, the algorithm for calculating the verification result can be a hash algorithm; or it can be another algorithm.

[0279] Optionally, in step 23-1, the data source device information receiving the verification result can be added to the verification result data packet. This can be done in one of the following ways:

[0280] (1) Explicitly indicate information about the data source device, such as the data source device identifier;

[0281] (2) Implicitly indicating information about the data source device, which can be some kind of information agreed upon in advance by the data source device and the verification node. For example, a hash value can be used to implicitly indicate the data source device: Hash(data source device identifier, verification key), where Hash represents the function for calculating the hash value.

[0282] Optionally, in step 23-1, when encrypting the verification result, a digital signature can also be calculated and included as part of the verification result data packet. This is so that the data source device can confirm that the issuer of the verification command is indeed this verification node.

[0283] Optionally, in step 24, the verification node can send the verification result data packet to the boundary node in any of the following ways:

[0284] (1) Ledger transfer: The verification node writes the verification result data packet into the distributed ledger, and the boundary node reads the distributed ledger.

[0285] This can be achieved either by writing the verification node into the distributed ledger, having the edge node read the blockchain ledger, and then determining (whether it needs to forward the verification result to the data source device) as described above, or by using a smart contract.

[0286] (2) Point-to-point sending: The verification node sends a request directly to the boundary node, such as an RPC remote procedure call or an HTTP request.

[0287] Optionally, in step 24, the process of the boundary node receiving the verification result can be a separate step or can be combined with step 16.

[0288] Optionally, in steps 24-25, after receiving the verification result, the boundary node determines which data source device needs to provide it to, which can be done using any of the following methods:

[0289] (1) If the boundary node can resolve the data source device indicated in the verification result, then the data source device is resolved. For example, the verification result may include information that explicitly or implicitly indicates the data source device, such as the data source identifier or the hash value indicating the data source device.

[0290] (2) If the boundary node cannot resolve which data source device(s) the verification result needs to be forwarded to, then it should be forwarded to all data source devices without further distinction.

[0291] Optionally, in step 25, the process of the boundary node feeding back the verification result to the data source device can be a separate step or can be combined with step 17.

[0292] Optionally, in step 25, if the verification result includes a digital signature, the data source node can verify the signature to determine whether the verification result originates from the claimed verification node.

[0293] Optionally, in step 26, the data source device may determine whether the data payload has been successfully written to the distributed ledger based on at least one of the following:

[0294] (1) Determine whether the write result returned by the boundary node (step 17) is consistent with the verification result returned by the verification node (step 25).

[0295] (2) Are there enough verification nodes whose verification results are consistent, and are these results indicating that the scope covered by the verification query conditions in the verification command has been successfully written to the distributed ledger?

[0296] (3) Are there specific verification nodes that provide verification results that indicate that the scope covered by the verification query conditions in the verification command has been successfully written to the distributed ledger? For example, these nodes are nodes that the data source device particularly trusts.

[0297] Optionally, in step 26, the data source device can determine whether the boundary node is malicious based on whether the data load has been successfully written to the distributed ledger.

[0298] Optionally, in step 23-2, if the verification command contains an expected value for the verification result, the verification node can determine whether the boundary node is malicious based on the verification command and the expected value for the verification result read from the distributed ledger.

[0299] In this embodiment, the off-chain data source device can notify the on-chain verification node (different from the boundary node) to provide verification results, thereby determining whether the boundary node is malicious.

[0300] Referring to Figure 8, an embodiment of this disclosure provides a verification-based trusted on-chain device applied to the first node of a distributed ledger system. The device 800 includes: a first transceiver unit 801 and a first processing unit 802.

[0301] The first transceiver unit 801 is used to acquire a first data packet, the first data packet including a verification command, the verification command being used to instruct whether the first data is actually written to the distributed ledger, the first data being generated by the second node and intended to be written to the distributed ledger by the third node;

[0302] The first processing unit 802 is used to verify whether the first data has been actually written to the distributed ledger according to the verification command, and to obtain the verification result;

[0303] The first transceiver unit 801 is further configured to send a second data packet to the third node, the second data packet including the verification result, and the third node is configured to send the verification result to the second node.

[0304] In one embodiment of this disclosure, a first transceiver unit 801 is used to acquire a first data packet, the first data packet including the ciphertext of the verification command, the ciphertext being generated by a second node based on a first key;

[0305] The first processing unit 802 is further configured to decrypt the ciphertext of the verification command using the second key to obtain the verification command.

[0306] Optionally, the first processing unit 802 is further configured to encrypt the verification result using a third key to obtain the ciphertext of the verification result;

[0307] The first transceiver unit 801 is further configured to send a second data packet to the third node, the second data packet including the ciphertext of the verification result, and the third node is configured to send the ciphertext of the verification result to the second node.

[0308] In one embodiment of this disclosure, the first processing unit 802 is further configured to verify whether the first data is actually written to the distributed ledger through the verification program of the first node according to the verification command, and obtain a verification result; or, according to the verification command, verify whether the first data is actually written to the distributed ledger through a smart contract deployed on the first node, and obtain a verification result.

[0309] In one embodiment of this disclosure, the first processing unit 802 is further configured to determine whether the first node is the verification node selected by the second node according to the verification command; if the first node is the verification node selected by the second node, execute the verification command to verify whether the first data is actually written to the distributed ledger.

[0310] In one embodiment of this disclosure, the first transceiver unit 801 is further configured to obtain the first data from the distributed ledger according to the verification command.

[0311] In one embodiment of this disclosure, the first data packet further includes the first data.

[0312] In one embodiment of this disclosure, the first data packet further includes: a signature of the second node, wherein the signature of the second node is generated by the second node based on a fourth key;

[0313] In one embodiment of this disclosure, the first processing unit 802 is further configured to verify whether the signature of the second node is valid using a fifth key; if the signature is valid, then it is determined that the verification command was generated by the second node.

[0314] In one embodiment of this disclosure, the second data packet further includes: a signature of the first node, wherein the signature of the first node is generated by the first node using the sixth key.

[0315] In one embodiment of this disclosure, the first processing unit 802 is further configured to determine, based on the verification result and the verification command, whether the third node actually writes the first data into the distributed ledger.

[0316] In one embodiment of this disclosure, the first key and the second key are the same symmetric key, or the first key and the second key are a pair of public and private keys in an asymmetric key, or the fourth key and the fifth key are the same symmetric key, or the fourth key and the fifth key are a pair of public and private keys in an asymmetric key.

[0317] In one embodiment of this disclosure, the verification command includes: first information, which is used to explicitly or implicitly indicate one or more selected verification nodes; second information, which is used to indicate the verification range; and third information, which is used to indicate the algorithm for calculating the verification result.

[0318] Optionally, the verification command may also include the expected value of the verification result.

[0319] In one embodiment of this disclosure, the verification scope includes at least one of the following: second node information, relevant information of the data to be written to the distributed ledger, and time range information, wherein the time range information is used to indicate the data to be written to the distributed ledger that occurred within the time range to be verified.

[0320] In one embodiment of this disclosure, the relevant information of the data to be written into the distributed ledger includes at least one of the following: the value of the first data, the storage information of the first data, and the verification information of the first data.

[0321] The apparatus provided in this disclosure can implement the various processes implemented in the method embodiment shown in FIG3 and achieve the same technical effect. To avoid repetition, it will not be described again here.

[0322] Referring to Figure 9, an embodiment of this disclosure provides a verification-based trusted on-chain device applied to a second node. The device 900 includes a second transceiver unit 901 and a second processing device 902.

[0323] The second transceiver unit 901 is used to send a third data packet to the third node. The third data packet includes a verification command. The verification command is used to instruct whether the first data is actually written to the distributed ledger. The first data is generated by the second node and is data that is expected to be written to the distributed ledger through the third node.

[0324] The second transceiver unit 901 is also used to receive a fourth data packet sent by the third node. The fourth data packet includes a verification result, which is obtained by the first node of the distributed ledger system verifying whether the first data was actually written into the distributed ledger according to the verification command.

[0325] The second processing device 902 is used to determine, based on the verification result, whether the third node actually wrote the first data into the distributed ledger.

[0326] In one embodiment of this disclosure, the second processing device 902 is further configured to encrypt the verification command using the first key to obtain the ciphertext of the verification command;

[0327] The second transceiver unit 901 is also used to send a third data packet to the third node, the third data packet including the ciphertext of the verification command.

[0328] Optionally, the second transceiver unit 901 is further configured to receive a fourth data packet sent by the third node, the fourth data packet including the ciphertext of the verification result, the ciphertext of the verification result being obtained by the first node encrypting the verification result using a third key;

[0329] The second processing device 902 is further configured to decrypt the ciphertext of the verification result using a seventh key to obtain the verification result.

[0330] In one embodiment of this disclosure, the third data packet further includes the signature of the second node, which is generated by the second node using a fourth key.

[0331] In one embodiment of this disclosure, the fourth data packet further includes the signature of the first node, which is generated by the first node using a sixth key.

[0332] In one embodiment of this disclosure, the second processing device 902 is further configured to verify whether the signature of the first node is valid using an eighth key; if the signature is valid, then it is determined that the verification result was generated by the first node.

[0333] Optionally, the sixth key and the eighth key are the same symmetric key, or the sixth key and the eighth key are a pair of public and private keys in an asymmetric key.

[0334] The apparatus provided in this disclosure can implement the various processes implemented in the method embodiment shown in FIG4 and achieve the same technical effect. To avoid repetition, it will not be described again here.

[0335] Referring to Figure 10, an embodiment of this disclosure provides a verification-based trusted on-chain device applied to a third node. The device 1000 includes a third transceiver unit 1001 and a third processing device 1002.

[0336] The third transceiver unit 1001 is used to receive a third data packet sent by the second node. The third data packet includes a verification command. The verification command is used to instruct whether the first data is actually written into the distributed ledger. The first data is generated by the second node and is data that is expected to be written into the distributed ledger through the third node.

[0337] The third transceiver unit 1001 is also used to send a first data packet to the first node of the distributed ledger system. The first data packet includes a verification command. The first node is used to verify whether the first data has been actually written to the distributed ledger according to the verification command and obtain a verification result.

[0338] The third transceiver unit 1001 is also configured to receive a second data packet sent by the first node, the second data packet including the verification result;

[0339] The third transceiver unit 1001 is also used to send a fourth data packet to the second node, the fourth data packet including a verification result.

[0340] In one embodiment of this disclosure, the first data packet includes the ciphertext of the verification command; the third data packet includes the ciphertext of the verification command, wherein the ciphertext of the verification command is generated by the second node based on the first key.

[0341] Optionally, the second data packet includes the ciphertext of the verification result, and the fourth data packet includes the ciphertext of the verification result, wherein the ciphertext of the verification result is obtained by the first node encrypting the verification result using a third key.

[0342] In one embodiment of this disclosure, the first data packet further includes the signature of the second node; the third data packet further includes the signature of the second node, which is generated by the second node based on the fourth key.

[0343] Optionally, the second data packet further includes: the signature of the first node; the fourth data packet further includes the signature of the first node, wherein the signature of the first node is generated by the first node using the second key.

[0344] The apparatus provided in this disclosure can implement the various processes implemented in the method embodiment shown in FIG5 and achieve the same technical effect. To avoid repetition, it will not be described again here.

[0345] As shown in Figure 11, this disclosure also provides a communication device 1100, including a processor 1101, a memory 1102, and a program or instructions stored in the memory 1102 and executable on the processor 1101. When the program or instructions are executed by the processor 1101, they implement the various processes of the method embodiments of Figures 3, 4, or 5 above, and achieve the same technical effects. To avoid repetition, further details are omitted here.

[0346] This disclosure also provides a distributed ledger system, including a first node as shown in FIG8, a second node as shown in FIG9, and a third node as shown in FIG10, which will not be described in detail here.

[0347] This disclosure also provides a readable storage medium storing a program or instructions that, when executed by a processor, implement the various processes of the method embodiments shown in FIG3, FIG4, or FIG5 above, and achieve the same technical effect. To avoid repetition, these will not be described again here.

[0348] The processor mentioned above is the processor in the terminal described in the above embodiments. The readable storage medium includes computer-readable storage media, such as computer read-only memory (ROM), random access memory (RAM), magnetic disk, or optical disk.

[0349] The steps of the methods or algorithms described in this disclosure can be implemented in hardware or by executing software instructions on a processor. The software instructions can consist of corresponding software modules, which can be stored in RAM, flash memory, ROM, erasable programmable read-only memory (EPROM), electrically erasable programmable read-only memory (EEPROM), registers, hard disks, portable hard disks, read-only optical discs, or any other form of storage medium known in the art. An exemplary storage medium is coupled to the processor, enabling the processor to read information from and write information to the storage medium. Of course, the storage medium can also be a component of the processor. The processor and storage medium can be housed in an application-specific integrated circuit (ASIC). Alternatively, the ASIC can be housed in a core network interface device. Of course, the processor and storage medium can also exist as discrete components in the core network interface device.

[0350] Those skilled in the art will recognize that the functions described in this disclosure in one or more of the examples above can be implemented using hardware, software, firmware, or any combination thereof. When implemented in software, these functions can be stored in a computer-readable medium or transmitted as one or more instructions or code on a computer-readable medium. Computer-readable media include computer storage media and communication media, wherein communication media include any medium that facilitates the transfer of a computer program from one place to another. Storage media can be any available medium accessible to a general-purpose or special-purpose computer.

[0351] The specific embodiments described above further illustrate the purpose, technical solution, and beneficial effects of this disclosure. It should be understood that the above description is only a specific embodiment of this disclosure and is not intended to limit the scope of protection of this disclosure. Any modifications, equivalent substitutions, improvements, etc., made on the basis of the technical solution of this disclosure should be included within the scope of protection of this disclosure.

[0352] Those skilled in the art will understand that embodiments of this disclosure can be provided as methods, systems, or computer program products. Therefore, embodiments of this disclosure can take the form of a completely hardware embodiment, a completely software embodiment, or an embodiment combining software and hardware aspects. Furthermore, embodiments of this disclosure can take the form of a computer program product implemented on one or more computer-usable storage media (including, but not limited to, disk storage, compact disc read-only memory (CD-ROM), optical storage, etc.) containing computer-usable program code.

[0353] This disclosure describes embodiments of methods, apparatus (systems), and computer program products according to embodiments of this disclosure with reference to flowchart illustrations and / or block diagrams. It will be understood that each block of the flowchart illustrations and / or block diagrams, and combinations of blocks in the flowchart illustrations and / or block diagrams, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, special-purpose computer, embedded processor, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, create means for implementing the functions specified in one or more flowchart illustrations and / or one or more block diagrams.

[0354] These computer program instructions may also be stored in a computer-readable storage medium that can direct a computer or other programmable data processing device to function in a particular manner, such that the instructions stored in the computer-readable storage medium produce an article of manufacture including instruction means that implement the functions specified in one or more flowcharts and / or one or more block diagrams.

[0355] These computer program instructions may also be loaded onto a computer or other programmable data processing apparatus to cause a series of operational steps to be performed on the computer or other programmable apparatus to produce a computer-implemented process, such that the instructions, which execute on the computer or other programmable apparatus, provide steps for implementing the functions specified in one or more flowcharts and / or one or more block diagrams.

[0356] Obviously, those skilled in the art can make various modifications and variations to the embodiments of this disclosure without departing from the spirit and scope of this disclosure. Therefore, if these modifications and variations to the embodiments of this disclosure fall within the scope of the claims of this disclosure and their equivalents, this disclosure is also intended to include these modifications and variations.

Claims

1. A verification-based trusted on-chain method, applied to the first node of a distributed ledger system, the method comprising: Obtain a first data packet, the first data packet including a verification command, the verification command being used to instruct whether the first data is actually written to the distributed ledger, the first data being generated by the second node and intended to be written to the distributed ledger by the third node; According to the verification command, verify whether the first data has actually been written to the distributed ledger, and obtain the verification result; The third node sends a second data packet to the third node, the second data packet including the verification result, and the third node is used to send the verification result to the second node.

2. The method according to claim 1, wherein, Obtain the first data packet, including: Obtain a first data packet, the first data packet including the ciphertext of the verification command, the ciphertext being generated by the second node based on the first key; The verification command is obtained by decrypting the ciphertext of the verification command using the second key.

3. The method according to claim 1, wherein, Sending a second data packet to the third node, including: The verification result is encrypted using a third key to obtain the ciphertext of the verification result; The third node sends a second data packet to the third node, the second data packet including the ciphertext of the verification result, and the third node is used to send the ciphertext of the verification result to the second node.

4. The method according to claim 1, wherein, According to the verification command, verify whether the first data has actually been written to the distributed ledger, and obtain the verification result, including: According to the verification command, the verification program of the first node verifies whether the first data has been actually written to the distributed ledger, and obtains the verification result; Alternatively, based on the verification command, the first data can be verified by a smart contract deployed on the first node to determine whether it has actually been written to the distributed ledger, and the verification result can be obtained.

5. The method according to claim 1, further comprising: Based on the verification command, determine whether the first node is the verification node selected by the second node; If the first node is the verification node selected by the second node, the step of verifying whether the first data has been actually written to the distributed ledger is executed according to the verification command.

6. The method according to claim 1, wherein, Before verifying whether the first data has actually been written to the distributed ledger according to the verification command and obtaining the verification result, the method further includes: The first data is obtained from the distributed ledger according to the verification command.

7. The method according to claim 1, wherein, The first data packet also includes the first data.

8. The method according to claim 1, wherein, The first data packet also includes: the signature of the second node, which is generated by the second node based on the fourth key; Before verifying whether the first data has actually been written to the distributed ledger according to the verification command and obtaining the verification result, the method further includes: The signature of the second node is verified using the fifth key. If the signature of the second node is valid, then it is determined that the verification command was generated by the second node.

9. The method according to claim 1, wherein, The second data packet also includes: the signature of the first node, which is generated by the first node using a sixth key.

10. The method according to claim 1, wherein, Before or after verifying whether the first data has been truly written to the distributed ledger according to the verification command and obtaining the verification result, the method further includes: Based on the verification result and the verification command, it is determined whether the third node actually wrote the first data into the distributed ledger.

11. The method according to claim 2 or 8, wherein, The first key and the second key are the same symmetric key, or the first key and the second key are a pair of public and private keys in an asymmetric key, or the fourth key and the fifth key are the same symmetric key, or the fourth key and the fifth key are a pair of public and private keys in an asymmetric key respectively.

12. The method according to claim 1, wherein, The verification command includes the following information: first information, which is used to explicitly or implicitly indicate one or more selected verification nodes; The second information is used to indicate the verification range; the third information is used to indicate the algorithm for calculating the verification result.

13. The method according to claim 12, wherein, The verification command also includes the following information: the expected value of the verification result.

14. The method according to claim 12, wherein, The verification scope includes at least one of the following: second node information, relevant information of the data to be written to the distributed ledger, and time range information, wherein the time range information is used to indicate the data to be written to the distributed ledger that occurred within the time range to be verified.

15. The method according to claim 14, wherein, The relevant information of the data to be written into the distributed ledger includes at least one of the following: the value of the first data, the storage information of the first data, and the verification information of the first data.

16. A verification-based trusted on-chain method, applied to a second node, the method comprising: A third data packet is sent to a third node. The third data packet includes a verification command, which is used to instruct the verification of whether the first data has been actually written to the distributed ledger. The first data is generated by the second node and is data that is expected to be written to the distributed ledger through the third node. The system receives a fourth data packet sent by the third node, the fourth data packet including a verification result, the verification result being obtained by the first node of the distributed ledger system verifying whether the first data was actually written to the distributed ledger according to the verification command; Based on the verification results, it is determined whether the third node actually wrote the first data into the distributed ledger.

17. The method according to claim 16, wherein, Send a third data packet to the third node, including: The verification command is encrypted using the first key to obtain the ciphertext of the verification command; A third data packet is sent to the third node, the third data packet including the ciphertext of the verification command.

18. The method according to claim 16, wherein, Receiving the fourth data packet sent by the third node includes: The system receives a fourth data packet sent by the third node, the fourth data packet including the ciphertext of the verification result, the ciphertext of the verification result being obtained by the first node encrypting the verification result using a third key. The verification result is obtained by decrypting the ciphertext of the verification result using the seventh key.

19. The method of claim 16, wherein, The third data packet also includes the signature of the second node, which is generated by the second node using the fourth key.

20. The method of claim 16, wherein, The fourth data packet also includes the signature of the first node, which is generated by the first node using the sixth key.

21. The method according to claim 20, further comprising: The validity of the first node's signature is verified using the eighth key; If the signature is valid, then the verification result is determined to have been generated by the first node.

22. The method according to claim 18, wherein, The third key and the seventh key are the same symmetric key, or the third key and the seventh key are a pair of public and private keys in an asymmetric key.

23. The method according to claim 21, wherein, The sixth key and the eighth key are the same symmetric key, or the sixth key and the eighth key are a pair of public and private keys in an asymmetric key.

24. A verification-based trusted on-chain method applied to a third node, the method comprising: The system receives a third data packet sent by the second node. The third data packet includes a verification command, which is used to instruct the system to verify whether the first data has been actually written to the distributed ledger. The first data is generated by the second node and is intended to be written to the distributed ledger by the third node. A first data packet is sent to the first node of the distributed ledger system. The first data packet includes a verification command. The first node is used to verify whether the first data has been actually written to the distributed ledger according to the verification command and obtain a verification result. Receive a second data packet sent by the first node, the second data packet including the verification result; A fourth data packet, including the verification result, is sent to the second node.

25. The method according to claim 24, wherein, The first data packet includes the ciphertext of the verification command, and the third data packet includes the ciphertext of the verification command, wherein the ciphertext of the verification command is generated by the second node based on the first key.

26. The method according to claim 24, wherein, The second data packet includes the ciphertext of the verification result, and the fourth data packet includes the ciphertext of the verification result, wherein the ciphertext of the verification result is obtained by the first node encrypting the verification result using a third key.

27. The method according to claim 24, wherein, The first data packet also includes the signature of the second node; the third data packet also includes the signature of the second node, which is generated by the second node based on the fourth key.

28. The method according to claim 24, wherein, The second data packet also includes the signature of the first node, and the fourth data packet also includes the signature of the first node, which is generated by the first node using the sixth key.

29. A verification-based trusted on-chain device, applied to the first node of a distributed ledger system, the device comprising: First transceiver unit and first processing unit; The first transceiver unit is used to acquire a first data packet, the first data packet including a verification command, the verification command being used to instruct whether the first data is actually written to the distributed ledger, the first data being generated by the second node and intended to be written to the distributed ledger by the third node; The first processing unit is used to verify whether the first data has actually been written to the distributed ledger according to the verification command, and to obtain the verification result; The first transceiver unit is further configured to send a second data packet to the third node, the second data packet including the verification result, and the third node is configured to send the verification result to the second node.

30. A verification-based trusted on-chain device, applied to a second node, the device comprising: Second transceiver unit and second processing device; The second transceiver unit is used to send a third data packet to the third node. The third data packet includes a verification command, which is used to instruct whether the first data is actually written to the distributed ledger. The first data is generated by the second node and is data that is expected to be written to the distributed ledger through the third node. The second transceiver unit is also used to receive a fourth data packet sent by the third node. The fourth data packet includes a verification result, which is obtained by the first node of the distributed ledger system verifying whether the first data has been actually written into the distributed ledger according to the verification command. The second processing device is used to determine, based on the verification result, whether the third node actually wrote the first data into the distributed ledger.

31. A verification-based trusted on-chain device, applied to a third node, the device comprising: The third transceiver unit and the third processing device; The third transceiver unit is used to receive a third data packet sent by the second node. The third data packet includes a verification command. The verification command is used to instruct whether the first data is actually written to the distributed ledger. The first data is generated by the second node and is data that is expected to be written to the distributed ledger through the third node. The third transceiver unit is also used to send a first data packet to the first node of the distributed ledger system. The first data packet includes a verification command. The first node is used to verify whether the first data has been actually written to the distributed ledger according to the verification command and obtain a verification result. The third transceiver unit is also configured to receive a second data packet sent by the first node, the second data packet including the verification result; The third transceiver unit is also used to send a fourth data packet to the second node, the fourth data packet including a verification result.

32. A first node comprising a processor, a memory, and a program or instructions stored in the memory and executable on the processor, wherein the program or instructions, when executed by the processor, implement the steps of the method as claimed in any one of claims 1 to 15.

33. A second node comprising a processor, a memory, and a program or instructions stored in the memory and executable on the processor, wherein the program or instructions, when executed by the processor, implement the steps of the method as claimed in any one of claims 16 to 23.

34. A third node comprising a processor, a memory, and a program or instructions stored in the memory and executable on the processor, wherein the program or instructions, when executed by the processor, implement the steps of the method as claimed in any one of claims 24 to 28.

35. A distributed ledger system, comprising a first node as described in claim 29, a second node as described in claim 30, and a third node as described in claim 31.

36. A readable storage medium on which a program or instructions are stored, wherein the program or instructions, when executed by a processor, implement the steps of the method as claimed in any one of claims 1 to 28.

37. A computer program product comprising computer instructions that, when executed by a processor, implement the steps of the method as claimed in any one of claims 1 to 28.

Images