Data transmission method and apparatus

Abstract

The present application relates to the technical field of communications, and provides a data transmission method and apparatus. Data in one distributed ledger can be transmitted to another distributed ledger, achieving information interaction between different distributed ledgers, improving user experience. The method comprises: a first node determines a first message, sends the first message to a second node, and then receives a second message, wherein the first message is used for indicating a first identifier, a second identifier, and information of first data, the first identifier is an identifier of a first distributed ledger, the second identifier is an identifier of a second distributed ledger, the first distributed ledger and the second distributed ledger belong to different operators, the first data is data in the first distributed ledger, the information of the first data comprises the first data or an identifier of the first data, the second node is a node in the second distributed ledger, and the second message is used for indicating whether the first data is successfully stored in the second distributed ledger.

Description

Data transmission method and apparatus

[0001] The present application claims priority to the Chinese patent application No. 202411565083.9, filed on November 4, 2024, and entitled “Data transmission method and apparatus”, the content of which is incorporated herein by reference in its entirety. TECHNICAL FIELD

[0002] The present application relates to the field of communication technology, and in particular to a data transmission method and apparatus. BACKGROUND

[0003] A distributed ledger (DL) is a database that is shared, replicated, and synchronized among network members. The distributed ledger can record transactions, such as exchanges of assets or data, between network members. In essence, the distributed ledger is a shared database, and the data or information stored therein has characteristics such as non-falsifiability, full traceability, traceability, openness and transparency, and collective maintenance. Therefore, the distributed ledger technology has a great potential to be introduced into the communication network in the future to improve the security of the communication network.

[0004] If the distributed ledger technology is introduced into the communication network, multiple operators can establish distributed ledgers based on devices in the communication network, such as access network devices or core network devices, etc. The information (such as data, etc.) of the nodes of a distributed ledger can be stored on the distributed ledger. However, if the information cannot be interacted between different distributed ledgers, the user experience will be affected. SUMMARY

[0005] The present application provides a data transmission method and apparatus, which can transmit data in one distributed ledger to another distributed ledger, realize information interaction between different distributed ledgers, and improve the user experience.

[0006] To achieve the above-mentioned purpose, the present application adopts the following technical solutions:

[0007] In a first aspect, a data transmission method is provided, which can be performed by a first node. The first node can refer to the first node itself, or a processor, circuit, module, logic node, chip, or chip system, etc. in the first node that implements the method. For example, the first node can be any node in a first distributed ledger, such as a distributed ledger enabler (DLE) network element, which can be deployed in a terminal, a radio access network (RAN) node, or a network element in a core network. Alternatively, the first node can be a node related to the first distributed ledger, such as a distributed ledger anchor function (DLAF) network element. Alternatively, the first node can have both DLE and DLAF functions.

[0008] The method includes determining a first message, sending the first message to a second node, and receiving a second message. The first message is used to indicate information of a first identifier, a second identifier, and first data. The first identifier is an identifier of the first distributed ledger, the second identifier is an identifier of the second distributed ledger, the first distributed ledger and the second distributed ledger belong to different operators, and the first data is data in the first distributed ledger. The information of the first data includes the first data or an identifier of the first data. The second node is a node in the second distributed ledger. The second message is used to indicate whether the first data is successfully stored in the second distributed ledger.

[0009] According to the method provided in the first aspect, when there is a cross-ledger data transmission requirement between distributed ledgers constructed by different operators (for example, data (such as first data) stored in the first distributed ledger needs to be transmitted to the second distributed ledger, and the first distributed ledger and the second distributed ledger are constructed by different operators), a node (i.e., the first node) in the first distributed ledger can send the identifier (i.e., the first identifier) of the first distributed ledger, the identifier (i.e., the second identifier) of the second distributed ledger, and the information of the data (i.e., the first data) to be transmitted to a node (i.e., the second node) in the second distributed ledger, that is, the first node can send a first message to the second node. The first message is used to indicate the first identifier, the second identifier, and the information of the first data.

[0010] It can be understood that the information is exchanged between different operators through the SEPP to ensure the security of information exchange between operators. Therefore, the first node can send the first message to the SEPP of the operator to which the first distributed ledger belongs, and the SEPP of the operator to which the first distributed ledger belongs sends the first message to the SEPP of the operator to which the second distributed ledger belongs, so as to ensure that the transmission of the first message between the two operators is secure.

[0011] In addition, since the first message is used to indicate the first identifier and the second identifier, the second node can determine whether the first distributed ledger is trusted based on the first identifier, and store the information of the first data in the second distributed ledger based on the second identifier when the first distributed ledger is trusted, so as to ensure the security of the information of the first data in the process from the first distributed ledger to the second distributed ledger and improve the experience.

[0012] In a possible implementation, when the second message indicates that the first data is successfully stored in the second distributed ledger, the data transmission method further includes: signing the information of the first data, the first identifier, and the second identifier to generate a data output transaction; and storing the data output transaction in the first distributed ledger.

[0013] Based on the above possible implementation, when the first node obtains that the first data has been stored in the second distributed ledger, the data output transaction can be generated, and the data migration transaction is stored in the first distributed ledger, so that the nodes in the first distributed ledger can know the latest status of the first data (i.e., the first data has been stored in the second distributed ledger), and thus can timely process the corresponding processing according to the latest status of the first data when processing the first data related business.

[0014] In a possible implementation, the second message is further used to indicate a second verification path, and the second verification path indicates a verification path of the first data in the second distributed ledger; and signing the information of the first data, the first identifier, and the second identifier to generate a data output transaction includes: when it is determined that the first data has been stored in the second distributed ledger based on the second verification path, signing the information of the first data, the first identifier, and the second identifier to generate a data output transaction.

[0015] Based on the above possible implementation, if the second message further carries the verification path of the first data in the second distributed ledger, the first node can further verify the second verification path to determine whether the first data has indeed been stored in the second distributed ledger, so as to ensure the authenticity of the latest status of the first data (i.e., the first data has been stored in the second distributed ledger).

[0016] In a possible implementation, before determining the first message, the data transmission method further includes: signing the information of the first data, the first identifier, and the second identifier to generate a data output transaction; and determining a first verification path according to the data output transaction, the first verification path being a verification path of the first data in the first distributed ledger, and the first message further indicating the first verification path.

[0017] Based on the possible implementation, the first node can further generate the data output transaction of the first data, and generate the verification path of the first data in the first distributed ledger by using the data output transaction, and then can inform the second node of the verification path (i.e., the first verification path), so that the second node can determine that the first data is indeed the data stored in the first distributed ledger, rather than data maliciously sent by the first node, and thus can store the first data in the second distributed ledger, thereby realizing cross-ledger transmission of the first data.

[0018] In a possible implementation, the data transmission method further includes: storing the data output transaction in the first distributed ledger.

[0019] Based on the possible implementation, when the first node learns that the first data has been stored in the second distributed ledger, the first node can store the data output transaction in the first distributed ledger, so that the nodes in the first distributed ledger can learn the latest status of the first data (i.e., the first data has been stored in the second distributed ledger), and thus can timely process the first data according to the latest status of the first data when processing a business related to the first data.

[0020] In a possible implementation, the first distributed ledger includes a first blockchain and a first database, the data output transaction is stored in the first blockchain, and the first database includes the information of the first data and a first timestamp, the first timestamp being a timestamp of a node to which the first data belongs joining the first distributed ledger; and the data transmission method further includes: deleting the information of the first data in the first database; or updating the first timestamp as an output indication, the output indication indicating that the first data has been output from the first distributed ledger.

[0021] Based on the possible implementation, when the first node learns that the first data has been stored in the second distributed ledger and deletes the information of the first data stored in the first distributed ledger, or retains the information of the first data and prompts the latest status of the first data (i.e., the first data has been output from the first distributed ledger) by using the output indication, when the information of the first data needs to be input from the second distributed ledger to the first distributed ledger, the data transmission process does not need to be performed again, and the information of the first data can be directly restored, thereby improving transmission efficiency.

[0022] In a possible implementation, when the information of the first data includes an identifier of the first data, before receiving the second message, the data transmission method further includes: sending the first data to the second node.

[0023] In the possible implementation, if the first message only carries the identifier of the first data, the second node learns that the first data needs to be transmitted to the second node by the first node after receiving the first message, and thus the second node waits for the first data from the first node, that is, the first node also needs to send the first data to the second node, to implement the cross-ledger data transmission. For example, when the data amount of the first data is too large, the first node can first send the identifier of the first data to the second node, and then send the first data to the second node after receiving feedback information from the second node. The feedback information indicates that the second distributed ledger allows the first data to be input. That is, when the second node allows the first data to be input, the first node sends the first data to the second node again, and if the second node does not allow the first data to be input, the first node does not need to send the first data to the second node, thereby saving transmission resources.

[0024] In a possible implementation, the first message is further used to indicate one or more of the following: an output reason of the first data, an identifier of a node to which the first data belongs, and a signature of the first node; and the output reason of the first data includes that the node to which the first data belongs joins the second distributed ledger, or the second distributed ledger subscribes to data in the first distributed ledger.

[0025] Based on the possible implementation, the first node can further send the output reason of the first data, the identifier of the node to which the first data belongs, or the signature of the first node to the second node. When the first node sends the transmission reason of the first data to the second node, the second node can select a suitable verification manner based on the output reason of the first data to determine whether the second distributed ledger allows the first data to be input; when the first node sends the identifier of the node to which the first data belongs to the second node, the identifier of the node to which the first data belongs can be stored in the second distributed ledger as an identifier of the first data in the second distributed ledger or a source of the first data, so that the first data is traceable and the security of the first data is improved. When the first node sends the signature of the first node to the second node, the second node can verify whether the first node is trustworthy based on the signature of the first node, so that when the first node is trustworthy, it is determined that the data (such as the first data) from the first node is safe, and thus the first data can be stored in the second distributed ledger.

[0026] In a possible implementation, the determining the first message includes: determining whether the first data is allowed to be output from the first distributed ledger; and when it is determined that the first data is allowed to be output from the first distributed ledger, the first message is determined.

[0027] Based on the possible implementation manner above, the first node can first determine whether the first distributed ledger allows the data output, and then determine the first message and output the first data when it is determined that the first distributed ledger allows the data output, thereby providing an optional implementation manner for the first node to output the first data.

[0028] In a possible implementation manner, the data access policy of the first distributed ledger indicates that the data in the first distributed ledger is allowed to be output, which indicates that the first data is allowed to be output from the first distributed ledger.

[0029] Based on the possible implementation manner above, the data access policy of the distributed ledger usually indicates whether the data in the distributed ledger is allowed to be output, and therefore, the first node determines whether the first data is allowed to be output from the first distributed ledger based on the data access policy of the first distributed ledger, thereby providing an optional implementation manner for the first node to determine whether the first data is allowed to be output from the first distributed ledger.

[0030] In a possible implementation manner, before the determination of whether the first data is allowed to be output from the first distributed ledger, the data transmission method further includes: receiving a third message, the third message being used to indicate an identity of the first data; and determining whether the first data is allowed to be output from the first distributed ledger, including: when the first data exists in the first distributed ledger, determining that the first data is allowed to be output from the first distributed ledger.

[0031] Based on the possible implementation manner above, when the cross-ledger transmission (i.e., transmission from the first distributed ledger to the second distributed ledger) process of the first data is triggered based on the third message, since the third message carries the identity of the first data, the first node can determine, according to the identity of the first data, whether the first data exists in the first distributed ledger, and then determine whether the first data is allowed to be output from the first distributed ledger, thereby providing another optional implementation manner for the first node to determine whether the first data is allowed to be output from the first distributed ledger.

[0032] In a possible implementation manner, the third message further indicates a second identity and / or an output reason of the first data, and the output reason of the first data includes that a node to which the first data belongs joins the second distributed ledger, or the second distributed ledger subscribes to the data in the first distributed ledger.

[0033] Based on the possible implementation manner above, the third message can further carry the output reason of the first data and / or the destination distributed ledger (i.e., the second distributed ledger) of the first data, so that the first node can know the destination distributed ledger of the first data, and then know the destination address of the first data, thereby realizing the transmission of the first data.

[0034] In one possible implementation, the time difference between the first timestamp and the current time is less than a first threshold, indicating that the first data is allowed to be output from the first distributed ledger; wherein, the first timestamp is the timestamp when the node to which the first data belongs joins the first distributed ledger.

[0035] In one possible implementation, the time difference between a first timestamp and the current time is less than a first threshold, indicating that the first data is allowed to be output from the first distributed ledger. This includes situations where the output of the first data is due to the node to which the first data belongs joining the second distributed ledger, where the time difference between the first timestamp and the current time is less than the first threshold, indicating that the first data is allowed to be output from the first distributed ledger.

[0036] Based on the two possible implementation methods described above, the first node can determine whether the node to which the first data belongs frequently switches distributed ledgers (such as frequent switching of distributed ledgers caused by being controlled by an attacker) based on the duration of time the node to which the first data belongs joined the first distributed ledger (i.e., the time difference between the first timestamp and the current time). If the duration of time it joined the first distributed ledger is less than the first threshold, it means that the node to which the first data belongs has not frequently switched distributed ledgers, that is, the node to which the first data belongs is switching distributed ledgers normally, and thus the first data can be allowed to be output from the first distributed ledger.

[0037] In one possible implementation, a second identifier exists in the first distributed ledger, indicating that the first data is allowed to be output from the first distributed ledger.

[0038] Based on the above possible implementation methods, when the first node learns that the destination distributed ledger of the first data is the second distributed ledger, the first node can query whether the second distributed ledger exists from the list of trusted distributed ledgers of the first distributed ledger. If it exists, it means that the second distributed ledger is trusted, and thus the first data can be transmitted to the second distributed ledger.

[0039] In one possible implementation, before determining the first message, the data transmission method further includes: receiving a fourth message, the fourth message being used to indicate the identifier and second identifier of the first data; determining the first message, including: determining the first message based on the fourth message.

[0040] Based on this possible implementation, the first node can learn the identifier and second identifier of the first data based on the fourth message, and then determine the first message, providing an optional implementation method for the first node to determine the first message.

[0041] In one possible implementation, the fourth message is also used to indicate the reason for the output of the first data, which may include the node to which the first data belongs joining the second distributed ledger, or the second distributed ledger subscribing to data in the first distributed ledger.

[0042] Based on the above possible implementation methods, the third message may also carry the reason for the output of the first data, so that the first can know the destination distributed ledger (i.e., the second distributed ledger) of the first data, and then know the destination address of the first data, thereby realizing the transmission of the first data.

[0043] In one possible implementation, the fourth message is used to indicate that the second distributed ledger has permission to access the first data.

[0044] Based on the above possible implementation methods, the fourth message is permission information (i.e., the fourth message is used to indicate that the second distributed ledger has the permission to obtain the first data, such as the fourth message being a token), so that the first node determines the first message based on the permission information, providing another optional implementation method for the first node to determine the first message.

[0045] Secondly, a data transmission method is provided, which can be executed by a second node. Here, the second node can refer to the second node itself, or to a processor, circuit, module, logic node, chip, or chip system within the second node that implements the method. For example, the second node can be any node in the second distributed ledger, such as a DLE network element, which can be deployed in a terminal, RAN node, or network element in the core network. Alternatively, the second node can be a node related to the second distributed ledger, such as a DLAF network element, or the second node can simultaneously possess both DLE and DLAF functions.

[0046] The method includes: receiving a first message from a first node; determining whether a second distributed ledger allows first data input based on a first identifier indicated by the first message; when it is determined that the second distributed ledger allows first data input; signing the first identifier, a second identifier, information about the first data, and a second timestamp to generate a data input transaction; storing the data input transaction in the second distributed ledger; and sending a second message to the first node. The first message includes information indicating the first identifier, the second identifier, and the first data; the first node is a node in the first distributed ledger; the first identifier is the identifier of the first distributed ledger; the second identifier is the identifier of the second distributed ledger; the first and second distributed ledgers belong to different operators; the first data is data in the first distributed ledger; the information of the first data includes the first data or its identifier; the second timestamp is the timestamp when the node to which the first data belongs joined the second distributed ledger; and the second message indicates whether the first data was successfully stored in the second distributed ledger.

[0047] Based on the method provided in the second aspect above, when there is a need for cross-ledger data transmission between distributed ledgers built by different operators (for example, data stored in the first distributed ledger (such as first data) needs to be transmitted to the second distributed ledger for storage, and the first and second distributed ledgers are built by different operators), a node in the second distributed ledger (i.e., the second node) can receive information from the node in the first distributed ledger (i.e., the first node) regarding the identifier of the first distributed ledger (i.e., the first identifier), the identifier of the second distributed ledger (the second identifier), and the data to be transmitted (i.e., the first data). That is, the second node receives a first message from the first node, wherein the first message is used to indicate information about the first identifier, the second identifier, and the first data.

[0048] Understandably, different operators use SEPP to exchange information to ensure the security of information exchange between operators. Therefore, the first node can send the first message to the SEPP of the operator to which the first distributed ledger belongs, and then the SEPP of the operator to which the first distributed ledger belongs will send the first message to the SEPP of the operator to which the second distributed ledger belongs, so as to ensure that the transmission of the first message between the two operators is secure.

[0049] Furthermore, since the first message is used to indicate the first identifier and the second identifier, the second node can determine whether the first distributed ledger is trustworthy based on the first identifier. When the first distributed ledger is trustworthy, the second node stores the information of the first data in the second distributed ledger based on the second identifier, thereby ensuring the security of the information of the first data in the process from the first distributed ledger to the second distributed ledger and improving the user experience.

[0050] In one possible implementation, the first message is also used to indicate the signature of the first node; the above data transmission method further includes: verifying the signature of the first node; when it is determined that the second distributed ledger allows the first data input, signing the first identifier, the second identifier, the information of the first data, and the second timestamp to generate a data input transaction, including: when it is determined that the second distributed ledger allows the first data input, and the signatures of the first nodes are all verified, signing the first identifier, the second identifier, the information of the first data, the signature of the first node, and the second timestamp to generate a data input transaction.

[0051] Based on the above possible implementation methods, when the first message carries the signature of the first node, the second node can further verify whether the first node is trustworthy based on the signature of the first node. Thus, when the first node is trustworthy, it can determine that the data from the first node (such as the first data) is safe. Then, when it is determined that the second distributed ledger allows the input of the first data, the first data can be stored in the second distributed ledger.

[0052] In one possible implementation, the second distributed ledger includes a second blockchain and a second database, with data input transactions stored in the second blockchain; the data transmission method further includes: storing the information of the first data and the second timestamp in the second database; or, using the information of the first data to update the information of the node to which the first data belongs in the second database.

[0053] Based on the above possible implementation methods, the second node can store the transaction information of the first data (i.e., data input transaction) in the second distributed ledger, so that all nodes in the second distributed ledger can know the information of the first data. Thus, when the nodes in the second distributed ledger process the business related to the first data, they can directly obtain the first data from the second distributed ledger for corresponding processing, thereby improving the efficiency of the relevant business.

[0054] In one possible implementation, the second message is also used to indicate a second verification path, which is the verification path of the first data in the second distributed ledger.

[0055] Based on the above possible implementation methods, the second message can also carry the verification path of the first data in the second distributed ledger, so that the first node can verify the second verification path to determine whether the first data has indeed been stored in the second distributed ledger, so as to ensure the authenticity of the latest dynamics of the first data (i.e. the first data has been stored in the second distributed ledger).

[0056] In one possible implementation, the first message is further used to indicate a first verification path, which is the verification path of the first data in the first distributed ledger; the data transmission method further includes: verifying the first verification path; when it is determined that the second distributed ledger allows the input of the first data, signing the first identifier, the second identifier, the information of the first data, and the second timestamp to generate a data input transaction, including: when it is determined that the second distributed ledger allows the input of the first data, and it is determined based on the first verification path that the first data is stored in the first distributed ledger, signing the first identifier, the second identifier, the information of the first data, and the second timestamp to generate a data input transaction.

[0057] Based on the above possible implementation methods, when the first message also carries the verification path of the first data in the first distributed ledger (i.e., the first verification path), the second node can determine based on the verification path that the first data is indeed the data stored in the first distributed ledger, rather than the data maliciously sent by the first node. Thus, when it is determined that the second distributed ledger allows the input of the first data, the first data can be stored in the second distributed ledger, thereby realizing the cross-ledger transmission of the first data.

[0058] In one possible implementation, when the information of the first data includes the identifier of the first data, the above data transmission method further includes receiving the first data sent from the first node before sending the second message.

[0059] In one possible implementation, the first message is also used to indicate one or more of the following: the reason for the output of the first data, the identifier of the node to which the first data belongs, and the signature of the first node; wherein the reason for the output of the first data includes the node to which the first data belongs joining the second distributed ledger, or the second distributed ledger subscribing to data in the first distributed ledger.

[0060] In one possible implementation, before receiving the first message, the data transmission method further includes sending a fourth message, which is used to indicate the identifier and the second identifier of the first data.

[0061] In one possible implementation, the fourth message is also used to indicate the reason for the output of the first data, which may include the node to which the first data belongs joining the second distributed ledger, or the second distributed ledger subscribing to data in the first distributed ledger.

[0062] In one possible implementation, the fourth message is used to indicate that the second distributed ledger has permission to access the first data.

[0063] The technical effects of any design in the second aspect can be referenced from the technical effects of the corresponding design in the first aspect, and will not be elaborated here.

[0064] Thirdly, a communication device is provided for implementing the method provided in the first aspect. This communication device can be the second node in the first aspect. The communication device includes modules, units, or means that implement the method described above. These modules, units, or means can be implemented in hardware, software, or by hardware executing corresponding software. The hardware or software includes one or more modules or units corresponding to the functions described above.

[0065] In one possible implementation, the communication device may include a processing module and an interface module. The processing module can be used to implement the processing functions described in the first aspect and any possible implementation thereof. The processing module may be, for example, a processor. The interface module, also referred to as an interface unit, is used to implement the sending and / or receiving functions described in the first aspect and any possible implementation thereof. The interface module may consist of an interface circuit, a transceiver, a transceiver unit, or a communication interface.

[0066] In one possible implementation, a processing module is configured to determine a first message, which indicates information about a first identifier, a second identifier, and first data. The first identifier is an identifier of a first distributed ledger, and the second identifier is an identifier of a second distributed ledger. The first and second distributed ledgers belong to different operators. The first data is data in the first distributed ledger, and the information of the first data includes the first data itself or its identifier. An interface module is configured to send the first message to a second node. The interface module is also configured to receive a second message from the second node, which is a node in the second distributed ledger. The second message indicates whether the first data has been successfully stored in the second distributed ledger.

[0067] In one possible implementation, when the second message indicates that the first data has been successfully stored in the second distributed ledger, the processing module further signs the information, the first identifier, and the second identifier of the first data to generate a data output transaction; and stores the data output transaction in the first distributed ledger.

[0068] In one possible implementation, when the second message is also used to indicate the second verification path, the processing module is also used to verify the second verification path. After successful verification, the module signs the information of the first data, the first identifier, and the second identifier to generate a data output transaction.

[0069] In one possible implementation, before determining the first message, the processing module is further configured to sign the information, first identifier, and second identifier of the first data to generate a data output transaction; the processing module is further configured to determine a first verification path based on the data output transaction, the first verification path being the verification path in the first distributed ledger of the first data, and the first message is further configured to indicate the first verification path.

[0070] In one possible implementation, the processing module is also used to output data transactions stored in the first distributed ledger.

[0071] In one possible implementation, the first distributed ledger includes a first blockchain and a first database. Data output transactions are stored in the first blockchain, and the first database includes information about the first data and a first timestamp, where the first timestamp is the timestamp when the node to which the first data belongs is added to the first distributed ledger. The processing module is further configured to delete the information about the first data in the first database. Alternatively, the processing module is further configured to update the first timestamp to an output indication, whereby the output indication indicates that the first data has been output from the first distributed ledger.

[0072] In one possible implementation, when the information of the first data includes the identifier of the first data, the interface module is also used to send the first data to the second node before receiving the second message.

[0073] In one possible implementation, the first message is also used to indicate one or more of the following: the reason for the output of the first data, the identifier of the node to which the first data belongs, and the signature of the first node; wherein the reason for the output of the first data includes the node to which the first data belongs joining the second distributed ledger, or the second distributed ledger subscribing to data in the first distributed ledger.

[0074] In one possible implementation, the processing module is specifically used to determine whether to allow the first data to be output from the first distributed ledger; when it is determined that the first data to be output from the first distributed ledger is allowed, a first message is determined.

[0075] In one possible implementation, the data access policy of the first distributed ledger indicates that data output from the first distributed ledger is permitted, meaning that first data is permitted to be output from the first distributed ledger.

[0076] In one possible implementation, the interface module is further configured to receive a third message indicating the identifier of the first data; in this case, the processing module is specifically configured to determine, when the first data exists in the first distributed ledger, that the first data is allowed to be output from the first distributed ledger.

[0077] In one possible implementation, the third message also indicates a second identifier and / or the reason for the output of the first data, including whether the node to which the first data belongs has joined the second distributed ledger or whether the second distributed ledger has subscribed to data in the first distributed ledger.

[0078] In one possible implementation, the processing module is specifically used to determine the relationship between the time difference between the first timestamp and the current time and a first threshold; when the time difference between the first timestamp and the current time is less than the first threshold, it indicates that the first data is allowed to be output from the first distributed ledger; wherein, the first timestamp is the timestamp when the node to which the first data belongs joins the first distributed ledger.

[0079] In one possible implementation, when the time difference between the first timestamp and the current time is less than a first threshold, it indicates that the first data is allowed to be output from the first distributed ledger, including: when the reason for the output of the first data is that the node to which the first data belongs joins the second distributed ledger, the time difference between the first timestamp and the current time is less than the first threshold, indicating that the first data is allowed to be output from the first distributed ledger.

[0080] In one possible implementation, the processing module is specifically used to determine whether a second identifier exists in the first distributed ledger; wherein, when a second identifier exists in the first distributed ledger, it indicates that the first data is allowed to be output from the first distributed ledger.

[0081] In one possible implementation, the interface module is further configured to receive a fourth message, which indicates the identifier and the second identifier of the first data; in this case, the processing module is specifically configured to determine the first message based on the fourth message.

[0082] In one possible implementation, the fourth message is also used to indicate the reason for the output of the first data, which may include the node to which the first data belongs joining the second distributed ledger, or the second distributed ledger subscribing to data in the first distributed ledger.

[0083] In one possible implementation, the fourth message is used to indicate that the second distributed ledger has permission to access the first data.

[0084] Fourthly, a communication device is provided for implementing the method provided in the second aspect. This communication device can be the second node in the second aspect. The communication device includes modules, units, or means that implement the method described above. These modules, units, or means can be implemented in hardware, software, or by hardware executing corresponding software. The hardware or software includes one or more modules or units corresponding to the functions described above.

[0085] In one possible implementation, the communication device may include a processing module and an interface module. The processing module can be used to implement the processing functions in the second aspect described above and any possible implementation thereof. The processing module may be, for example, a processor. The interface module, also referred to as an interface unit, is used to implement the sending and / or receiving functions in the second aspect described above and any possible implementation thereof. The interface module may consist of an interface circuit, a transceiver, a transceiver unit, or a communication interface.

[0086] In one possible implementation, an interface module is used to receive a first message from a first node. The first message includes information indicating a first identifier, a second identifier, and first data. The first node is a node in a first distributed ledger, the first identifier is an identifier of the first distributed ledger, the second identifier is an identifier of the second distributed ledger, the first and second distributed ledgers belong to different operators, and the first data is data in the first distributed ledger. The information of the first data includes the first data or its identifier. A processing module is used to determine whether the second distributed ledger allows the input of the first data based on the first identifier and the second identifier. When it is determined that the second distributed ledger allows the input of the first data, the processing module signs the first identifier, the second identifier, the information of the first data, and a second timestamp to generate a data input transaction and stores the data input transaction in the second distributed ledger. The second timestamp is the timestamp when the node to which the first data belongs joins the second distributed ledger. The interface module is also used to send a second message to the first node, which indicates whether the first data has been successfully stored in the second distributed ledger.

[0087] In one possible implementation, the first message is also used to indicate the signature of the first node; the processing module is also used to verify the signature of the first node; when it is determined that the second distributed ledger allows the first data input and the signatures of the first nodes are all verified, the first identifier, the second identifier, the information of the first data, the signature of the first node, and the second timestamp are signed to generate a data input transaction.

[0088] In one possible implementation, the second distributed ledger includes a second blockchain and a second database, with data input transactions stored in the second blockchain; the processing module is also used to store the information of the first data and the second timestamp in the second database; or, to use the information of the first data to update the information of the node to which the first data belongs in the second database.

[0089] In one possible implementation, the second message is also used to indicate a second verification path, which is the verification path of the first data in the second distributed ledger.

[0090] In one possible implementation, the first message is further used to indicate a first transmission path, the first verification path being the verification path of the first data in the first distributed ledger; the processing module is further used to verify the first verification path; when it is determined that the second distributed ledger allows the input of the first data, and it is determined that the first data is stored in the first distributed ledger based on the first verification path, the first identifier, the second identifier, the information of the first data, and the second timestamp are signed to generate a data input transaction.

[0091] In one possible implementation, when the information of the first data includes the identifier of the first data, the interface module is also used to receive the first data sent from the first node.

[0092] In one possible implementation, the first message is also used to indicate one or more of the following: the reason for the output of the first data, the identifier of the node to which the first data belongs, and the signature of the first node; wherein the reason for the output of the first data includes the node to which the first data belongs joining the second distributed ledger, or the second distributed ledger subscribing to data in the first distributed ledger.

[0093] In one possible implementation, the interface module is also used to send a fourth message, which indicates the identifier of the first data and the second identifier.

[0094] In one possible implementation, the fourth message is also used to indicate the reason for the output of the first data, which may include the node to which the first data belongs joining the second distributed ledger, or the second distributed ledger subscribing to data in the first distributed ledger.

[0095] In one possible implementation, the fourth message is used to indicate that the second distributed ledger has permission to access the first data.

[0096] Fifthly, a communication device is provided, comprising: a processor; configured to cause the communication device to perform the method described in any of the preceding aspects by executing a computer program (or computer-executable instructions) stored in a memory, and / or by means of logic circuitry. The communication device may be a first node as described in the first aspect; or, the communication device may be a second node as described in the second aspect. Optionally, the number of processors may be one or more.

[0097] In one possible implementation, the communication device also includes a memory.

[0098] In one possible implementation, the processor and memory are integrated together; alternatively, the memory is independent of the processor.

[0099] In one possible implementation, the communication device further includes a communication interface for communicating with other devices, such as transmitting or receiving data and / or signals. Exemplarily, the communication interface may be a transceiver, circuit, bus, module, or other type of communication interface.

[0100] In one possible implementation, the communication device is a chip or a chip system. Optionally, when the communication device is a chip system, it can be composed of chips or may include chips and other discrete components.

[0101] A sixth aspect provides a communication device, comprising: a processor and an interface circuit; the interface circuit being configured to receive a computer program or instructions and transmit them to the processor; the processor being configured to execute the computer program or instructions to cause the communication device to perform the method described in any of the preceding aspects. The communication device may be a first node in the first aspect; or, the communication device may be a second node in the second aspect. Optionally, the number of processors may be one or more.

[0102] In one possible implementation, the communication device is a chip or a chip system. Optionally, when the communication device is a chip system, it can be composed of chips or may include chips and other discrete components.

[0103] In a seventh aspect, a computer-readable storage medium is provided, which stores instructions that, when executed on a computer, cause the computer to perform the methods described in any of the preceding aspects.

[0104] Eighthly, a computer program product containing instructions is provided, which, when run on a computer, enables the computer to perform the methods described in any of the preceding aspects.

[0105] A ninth aspect provides a communication system comprising at least one of the following: a first node for performing the method described in the first aspect, and a second node for performing the method described in the second aspect.

[0106] The technical effects of any possible implementation of aspects three through nine can be found in the technical effects of any one of aspects one through two or different possible implementations of any one of aspects, and will not be repeated here.

[0107] Understandably, provided that the solutions do not contradict each other, the solutions in the above aspects can be combined. Attached Figure Description

[0108] Figure 1 is a schematic diagram of the communication system architecture provided in this application;

[0109] Figure 2 is a schematic diagram of the communication network provided in this application;

[0110] Figure 3 is a schematic diagram of the communication network provided in this application (II).

[0111] Figure 4 is a schematic diagram of the hardware structure of the communication device provided in this application;

[0112] Figure 5 is a flowchart illustrating the data transmission method provided in this application.

[0113] Figure 6 is a schematic diagram of the distributed ledger storage method provided in this application;

[0114] Figure 7 is a flowchart illustrating the data transmission method provided in this application (II).

[0115] Figure 8 is a schematic diagram of the storage method of the distributed ledger provided in this application;

[0116] Figure 9 is a flowchart illustrating the cross-ledger subscription process provided in this application;

[0117] Figure 10 is a flowchart illustrating the data transmission method provided in this application.

[0118] Figure 11 is a flowchart illustrating the data transmission method provided in this application.

[0119] Figure 12 is a flowchart illustrating the data transmission method provided in this application.

[0120] Figure 13 is a schematic diagram of the data input transaction verification process provided in this application;

[0121] Figure 14 is a flowchart illustrating the data transmission method provided in this application.

[0122] Figure 15 is a flowchart illustrating the data transmission method provided in this application.

[0123] Figure 16 is a flowchart illustrating the data transmission method provided in this application.

[0124] Figure 17 is a schematic diagram of the communication device provided in this application. Detailed Implementation

[0125] To facilitate understanding of the technical solutions of the embodiments of this application, a brief introduction to the relevant technologies of this application is given below.

[0126] 1. Security Edge Protection Proxies (SEPP):

[0127] SEPP is the fifth generation (5) th It is a key component of the roaming security architecture for generation (5G), used for information exchange between users and other operators when roaming, responsible for message filtering and policy management on the control plane interface between operators, and mainly serves as an edge gateway between the core network control plane of operators; it is used to ensure secure information exchange between two operators.

[0128] Specifically, when two operators have information exchange needs, the user first sends the information to the SEPP of their own operator, which then sends the information to the SEPP of the other operator. The SEPP of the other operator then forwards the user's information to the network of that other operator for processing.

[0129] 2. Distributed Ledger (DL):

[0130] A distributed ledger, also known as a shared ledger, is a database that is shared, replicated, and synchronized among network members. Distributed ledgers can record transactions between network members, such as the exchange of assets or data. Essentially, a distributed ledger is a shared database where the data or information stored is characterized by being unforgeable, fully traceable, auditable, transparent, and collectively maintained.

[0131] Distributed ledgers can be consortium blockchains (Hyperledger Fabric), with open-source code. In this case, the distributed ledger consists of a global state and a blockchain. The global state is stored in the form of a database, where the data can be updated at any time. The blockchain is stored in a chain-like structure, where the data is immutable.

[0132] Taking a user's car information stored in the global state as an example, this information could include the license plate number, color, price, and passenger capacity. In a blockchain transaction, if this user trades the car to another user at price A, a transaction log is added to the blockchain: the car was traded to another user at price A; correspondingly, the price in the car information stored in the global state is updated to A. Similarly, if the user changes the car's color to B, a transaction log is added to the blockchain: the car's color is updated to B; correspondingly, the color in the car information stored in the global state is updated to B.

[0133] The advantages of distributed ledgers, such as unforgeable data, complete traceability, and transparency, make them highly likely to be introduced into future communication systems. Specifically, distributed ledgers in communication systems exhibit characteristics of layered heterogeneity and multi-chain coexistence.

[0134] In this context, "layered heterogeneity" refers to the hierarchical structure of large chains (where "chain" is short for blockchain) and small chains in a communication network. For example, multiple countries and / or multiple operators can form a large chain to store basic information such as identity and credentials. Private chains can be established within an operator or among a few operators for resource sharing, log auditing, and other purposes. The distributed ledger used to store identity information needs to transmit this information to other distributed ledgers as an access basis, enabling resource sharing, log auditing, and other services to be performed.

[0135] Multi-chain coexistence refers to the existence of multiple distributed ledgers in a communication network. For example, multiple distributed ledgers can be divided by region (e.g., different countries and regions correspond to different distributed ledgers). Alternatively, multiple distributed ledgers can be divided by function; for example, one distributed ledger is used for identity authentication, another for resource sharing, and yet another for log auditing. Specifically, the distributed ledger used for auditing needs to transmit node trust score data to the distributed ledger used for asset sharing, enabling the asset sharing distributed ledger to update the node's trust score. Similarly, if a node joins distributed ledger #2 from distributed ledger #1, the node's data needs to be transmitted from distributed ledger #1 to distributed ledger #2 to ensure normal communication.

[0136] As can be seen from the above, there is a need for cross-ledger data transmission in communication systems; especially when the two distributed ledgers for cross-ledger transmission are built by different operators, the implementation of information exchange between different operators also needs to be considered.

[0137] One readily conceivable approach is to utilize SEPP (Secure Provider Provider) for data forwarding. Specifically, the user sends data stored in distributed ledger A to the SEPP of the operator building distributed ledger A. The SEPP of operator A then forwards the data to the SEPP of the operator building distributed ledger B. The SEPP of operator B then forwards the data to its in-network storage. Here, the SEPP verifies the trustworthiness of the operator building distributed ledger A, and only forwards the data after successful verification (i.e., confirming the trustworthiness of the operator building distributed ledger A). This ensures the security of the interaction between the two operators.

[0138] However, in SEPP-based data transmission, SEPP only verifies the operator's credentials to determine data transmission security. In other words, even if distributed ledger A is untrusted, SEPP will still consider the transmission secure and forward the data. Furthermore, after receiving data from another operator, SEPP typically stores it in that operator's database. Therefore, when an operator has built multiple distributed ledgers, upon receiving data from another operator, it cannot determine which distributed ledger to store the data in.

[0139] In view of this, embodiments of this application provide a data transmission method and apparatus. When there is a need for cross-ledger data transmission between distributed ledgers built by different operators (for example, data stored in a first distributed ledger (such as first data) needs to be transmitted to a second distributed ledger for storage, and the first and second distributed ledgers are built by different operators), a node in the first distributed ledger (i.e., the first node) can send the identifier of the first distributed ledger (i.e., the first identifier), the identifier of the second distributed ledger (the second identifier), and the information of the data to be transmitted (i.e., the first data) to a node in the second distributed ledger (i.e., the second node). That is, the first node can send a first message to the second node, wherein the first message is used to indicate the information of the first identifier, the second identifier, and the first data.

[0140] Understandably, different operators use SEPP to exchange information to ensure the security of information exchange between operators. Therefore, the first node can send the first message to the SEPP of the operator to which the first distributed ledger belongs, and then the SEPP of the operator to which the first distributed ledger belongs will send the first message to the SEPP of the operator to which the second distributed ledger belongs, so as to ensure that the transmission of the first message between the two operators is secure.

[0141] Furthermore, since the first message is used to indicate the first identifier and the second identifier, the second node can determine whether the first distributed ledger is trustworthy based on the first identifier. When the first distributed ledger is trustworthy, the second node stores the information of the first data in the second distributed ledger based on the second identifier, thereby ensuring the security of the information of the first data in the process from the first distributed ledger to the second distributed ledger and improving the user experience.

[0142] The method provided in this application can be used in various communication systems. For example, the communication system can be a long-term evolution (LTE) system, a 5th generation (5G) communication system, a wireless fidelity (WiFi) system, a 3rd generation partnership project (3GPP) related communication system, a communication system evolving after 5G, or a system integrating multiple systems, etc., without limitation. Among them, 5G can also be referred to as new radio (NR).

[0143] The method provided in this application will be described below using the communication system shown in Figure 1 as an example. Figure 1 is only a schematic diagram and does not constitute a limitation on the applicable scenarios of the technical solution provided in this application.

[0144] Figure 1 shows a schematic diagram of the architecture of the communication system 20 provided in this application. The communication system 20 includes at least one node in the distributed ledger 201 (such as one or more nodes from node 2010 to node 2017) and at least one node in the distributed ledger 202 (such as one or more nodes from node 2020 to node 2027).

[0145] For example, one of nodes 2010 to 2017 can communicate with one of nodes 2020 to 2027. For instance, node 2013 can communicate with node 2020.

[0146] For example, at least one node in distributed ledger 201 is used to construct distributed ledger 201, that is, nodes 2010 to 2017 are used to construct distributed ledger 201; similarly, at least one node in distributed ledger 202 is used to construct distributed ledger 202, that is, nodes 2020 to 2027 are used to construct distributed ledger 202.

[0147] In this application, distributed ledgers 201 and 202 can respectively store the data of their respective nodes (such as node identity information, contract information, audit information, asset information, etc.). Furthermore, different nodes in the distributed ledgers can have the same or different permissions. That is, different nodes in distributed ledger 201 can have the same or different permissions; similarly, different nodes in distributed ledger 202 can have the same or different permissions. Taking nodes 2011 and 2013 in distributed ledger 201 as an example, node 2011 can query information in distributed ledger 201 but cannot write information to it, while node 2013 can query information, write information, and participate in consensus in distributed ledger 201, or both nodes 2011 and 2013 can query information, write information, and participate in consensus in distributed ledger 201.

[0148] In this application, the nodes in distributed ledger 201 and distributed ledger 202 may be partially the same or completely different, without restriction.

[0149] In this application, the nodes in the distributed ledger can be devices with wireless transceiver capabilities, such as terminals, radio access network (RAN) nodes, servers, or core network elements.

[0150] In this application, RAN nodes can provide wireless access services to terminals. Specifically, each RAN node corresponds to a service coverage area, and terminals entering this area can communicate with the RAN node through the air interface to receive the wireless access services provided by the RAN node.

[0151] RAN nodes are nodes within an RAN (Radio Network Area Network) or in an Open RAN (O-RAN or ORAN). RAN nodes can also be referred to as access network equipment, RAN entities, access nodes, or network equipment. RAN nodes include, but are not limited to: evolved Node Bs (NodeBs or eNBs or e-NodeBs) in LTE, next-generation eNBs (ng-eNBs) in next-generation LTE, base stations (gNodeBs or gNBs) in NR, transmitting points (TPs) or transmission receiving points / transmission reception points (TRPs), base stations in subsequent 3GPP evolutions, base stations in future mobile communication systems, satellites, access points (APs) in WiFi systems, wireless relay nodes, wireless backhaul nodes, integrated access and backhaul (IAB) nodes, and network equipment in non-terrestrial network (NTN) communication systems in mobile switching centers. These can be deployed on low-altitude platforms, high-altitude platforms, or satellites. Base stations can be macro base stations, micro base stations, pico base stations, small stations, relay stations, or balloon stations, etc. Multiple base stations can support networks using the same technology mentioned above, or networks using different technologies mentioned above. A base station can contain one or more co-located or non-co-located TRPs. RAN nodes can also be devices that function as base stations in device-to-device (D2D) communication, vehicle-to-everything (V2X) communication, drone communication, and machine-to-machine (M2M) communication. RAN nodes can also be radio controllers in cloud radio access network (CRAN) scenarios. RAN nodes can also be centralized units (CU), distributed units (DU), CU-control plane (CP), CU-user plane (UP), radio units (RU), roadside units (RSU) with base station functions, wired access gateways, or core network elements, etc. RAN nodes can also be servers, wearable devices, machine-to-machine communication devices, or vehicle-mounted devices, etc. For example, the access network device in V2X technology can be an RSU. The following explanation uses RAN nodes as base stations as an example. The multiple RAN nodes can be base stations of the same type or base stations of different types.Base stations can communicate with terminals directly, or they can communicate with terminals via relay stations. Terminals can communicate with multiple base stations using different technologies. For example, a terminal can communicate with a base station that supports LTE networks, or it can communicate with a base station that supports 5G networks, and it can also support dual connections with both LTE and 5G network base stations.

[0152] In this application, the CU can implement the functions of the radio resource control (RRC) layer and the packet data convergence protocol (PDCP) layer in the 3GPP standard. The CU can also implement the functions of the service data adaptation protocol (SDAP) layer. The DU can implement the functions of the radio link control (RLC) layer and the medium access control (MAC) layer in the 3GPP standard. The DU can also implement some or all physical layer functions, such as forward error correction (FEC) encoding / decoding, scrambling / descrambling, or modulation / demodulation. The RU can be used to implement radio frequency signal transmission and reception functions. The CU and DU can be set up separately, or they can be included in the same network element, such as in the baseband unit (BBU). It is understood that the CU can be classified as a network device in the access network or a network device in the core network; no limitation is made here. Furthermore, the CU can be further divided into CU-CP and CU-UP. CU-CP can implement the functions of the RRC layer and the control plane functions of the PDCP layer. CU-UP can implement the functions of the SDAP layer and the user plane functions of the PDCP layer.

[0153] In this application, the RU can be included in a radio frequency (RF) device or RF unit, such as in a remote radio unit (RRU), an active antenna unit (AAU), or a remote radio head (RRH). The RU can implement some physical layer functions and RF functions in the 3GPP standard. The physical layer functions implemented by the RU include one or more of the following: Fast Fourier Transform (FFT), Inverse Fast Fourier Transform (IFFT), digital beamforming, or extraction and filtering of the physical random access channel (PRACH), etc.

[0154] In different systems, CU (or CU-CP and CU-UP), DU, or RU may have different names, but those skilled in the art will understand their meaning. For example, in an ORAN system, CU can also be called O-CU (open CU), DU can also be called O-DU, CU-CP can also be called O-CU-CP, CU-UP can also be called O-CU-UP, and RU can also be called O-RU. For ease of description, this application uses CU, CU-CP, CU-UP, DU, and RU as examples. Any of the units among CU (or CU-CP, CU-UP), DU, and RU in this application can be implemented through software modules, hardware modules, or a combination of software and hardware modules.

[0155] Terminals can be deployed on land, including indoors, outdoors, handheld, or vehicle-mounted; they can also be deployed on water (such as ships); and they can be deployed in the air (such as airplanes, balloons, and satellites). Terminals can also be called terminal equipment, which can be user equipment (UE), mobile station (MS), mobile terminal (MT), or any device used to provide voice or data connectivity to users. UEs include handheld devices with wireless communication capabilities, vehicle-mounted devices (e.g., cars, bicycles, electric vehicles, airplanes, ships, trains, high-speed trains), wearable devices (e.g., smartwatches, smart bracelets, pedometers), or computing devices. For example, a UE can be a mobile phone, tablet computer, laptop computer, PDA, mobile internet device (MID), satellite terminal, or computer with wireless transceiver capabilities. UE can also be a virtual reality (VR) terminal device, an augmented reality (AR) terminal device, a wireless modem, a point-of-sale (POS) machine, customer-premises equipment (CPE), a smart robot, a robotic arm, workshop equipment, smart home devices (e.g., refrigerators, televisions, air conditioners, electricity meters, etc.), a wireless terminal in industrial control, a wireless terminal in autonomous driving, a wireless terminal in telemedicine, a wireless terminal in a smart grid, a wireless terminal in transportation safety, a wireless terminal in intelligent transportation, a wireless terminal in a smart city, a wireless terminal in a smart home, an in-vehicle terminal, an RSU with terminal functionality, or flying equipment (e.g., a smart robot, a hot air balloon, a drone, an airplane), etc. A terminal can also be other devices with terminal functionality; for example, a terminal can also be a device that performs terminal functionality in D2D communication.

[0156] The terminal can be an on-board module, on-board component, on-board chip, on-board unit (OBU), or telematics box (T-BOX) built into the vehicle as one or more components or units. The vehicle can implement the methods of this application through the built-in on-board module, on-board component, on-board chip, on-board unit, or T-BOX. The terminal can also be a complete vehicle device.

[0157] Understandably, in some scenarios, the roles of RAN nodes and terminals are relative. For example, a helicopter or drone, which is usually configured as a terminal, can also be configured as a mobile base station, and a device that accesses the RAN via a helicopter or drone is configured as a terminal.

[0158] Core network elements refer to network elements in the core network, such as network slice selection function (NSSF) network elements, network exposure function (NEF) network elements, network repository function (NRF) network elements, policy control function (PCF) network elements, unified data management (UDM) network elements, application function (AF) network elements, authentication server function (AUSF) network elements, access and mobility management function (AMF) network elements, session management function (SMF) network elements, or user plane function (UPF) network elements, etc.

[0159] One or more nodes in a distributed ledger can be distributed ledger enabler (DLE) network elements. A DLE network element is a distributed ledger enabling module in a communication network, which can be configured and managed by the distributed ledger anchor function (DLAF).

[0160] DLE network elements can possess one or more of the following functions: transaction proposal, transaction endorsement / execution, deployment and execution of smart contracts, consensus, transaction / block synchronization, or ledger storage. DLE network elements can be deployed on various nodes in the network, such as terminals, RAN nodes, core network elements, or network functions (NFs). A DLE network element can also function as an independent NF, providing distributed ledger proxy capabilities to other NFs. Furthermore, DLE network elements can be categorized into peer nodes or clients based on their roles. For example, a terminal can be considered a client. RAN nodes, servers, and core network elements can be considered either clients or peer nodes. Peer nodes can perform one or more of the following operations: participate in consensus, propose transactions, and save or query ledger data. Clients can perform one or more of the following operations: generate transactions or query ledger data.

[0161] As is understandable, distributed ledgers are usually represented by blockchains, so in this application, "distributed ledger" can be replaced with "blockchain", "nodes in a distributed ledger" can be replaced with "nodes in a blockchain" or "blockchain node", and other similar expressions can also be replaced in a similar way, which will not be elaborated further.

[0162] Optionally, the communication system 20 may further include one or more of the following network elements: network element 203, which can communicate with nodes in distributed ledger 201 and network element 204, and / or network element 204, which can communicate with nodes in distributed ledger 202 and network element 203. The functions of each of the above network elements are further explained below.

[0163] Network element 203 serves as the anchor point for the management and association of distributed ledger 201. For example, network element 203 can perform one or more functions such as management of distributed ledger 201, registration management of DLEs, creation of distributed ledger 201, activation of DLEs, and access control of distributed ledger 201. For example, network element 203 is a DLAF network element. Network element 204 serves as the anchor point for the management and association of distributed ledger 202. For example, network element 204 can perform one or more functions such as management of distributed ledger 202, registration management of DLEs, creation of distributed ledger 202, activation of DLEs, and access control of distributed ledger 202. For example, network element 204 is a DLAF network element. DLAF network elements are generally deployed in the core network in the form of network functions. DLAF network elements may also have a hierarchical structure, such as deploying sub-DLAFs in the access network; that is, DLAFs can be deployed at RAN nodes.

[0164] Network element 203 and network element 204 belong to different operators. For example, the operators can be domestic operators or overseas operators. Specifically, network element 203 and network element 204 belonging to different operators can also be understood as distributed ledger 201 and distributed ledger 202 belonging to different operators, or in other words, distributed ledger 201 and distributed ledger 202 being constructed by different operators.

[0165] In this application, the nodes of distributed ledger 201 and distributed ledger 202 can communicate through a gateway. That is, the nodes of distributed ledger 201 and distributed ledger 202 can establish a trust relationship through a roaming architecture, thereby enabling communication.

[0166] For example, the communication system 20 shown in Figure 1 can be applied to the communication network shown in Figure 2. Specifically, one or more nodes in the distributed ledger 201 can communicate directly with SEPP 205, SEPP 205 can communicate with SEPP 206, and SEPP 206 can communicate directly with one or more nodes in the distributed ledger 202. Taking the direct communication connection between node 2013 and SEPP 205, and the direct communication connection between SEPP 206 and node 2020 as an example, if node 2013 needs to communicate with node 2020, the information sent by node 2013 can be forwarded to node 2020 sequentially via SEPP 205 and SEPP 206.

[0167] Optionally, SEPP 205 can be deployed in conjunction with the DLE network element corresponding to Distributed Ledger 201, and SEPP 206 can be deployed in conjunction with the DLE network element corresponding to Distributed Ledger 202.

[0168] It is understood that the above-mentioned communication system 20 can be applied to a variety of communication networks, such as the 5G network currently under discussion, or other future networks, etc. This application embodiment does not specifically limit it in this regard.

[0169] For example, communication system 20 is applicable to the communication network shown in Figure 3. This communication network includes DLE network elements, DLAF network elements, UPF network elements, RAN nodes, terminals, and a data network (DN). It should be understood that the NFs included in the communication network shown in Figure 3 can be ID management (IDM) network elements, AMF, SMF, or UDM, etc., without limitation. Furthermore, terminals, RAN nodes, or some core network elements (as shown in the NFs in Figure 3) can also have DLE functionality; or, in other words, DLE network elements can be deployed in terminals, RAN nodes, or some core network elements. That is, DLE network elements can be deployed in the form of modules in terminals, RAN nodes, or some core network elements.

[0170] In Figure 3, the terminal can access the communication network through the RAN node. The RAN node can communicate with DLAF network elements and UPF network elements, and the UPF network element can access the DN. The RAN node can communicate directly with the DLAF network element, or indirectly with it through the AMF network element. DLE network elements, DLAF network elements, IDM network elements, and NF network elements can interact using service-oriented interfaces.

[0171] It is understandable that the devices or entities corresponding to the nodes in the distributed ledger 201 of the communication system 20 are terminals, RAN nodes, or NF network elements in the communication network shown in Figure 3, and the devices or entities corresponding to network element 203 of the communication system 20 are DLAF network elements in the communication network shown in Figure 3. Alternatively, the devices or entities corresponding to the nodes in the distributed ledger 202 of the communication system 20 are terminals, RAN nodes, or NF network elements in the communication network shown in Figure 3, and the devices or entities corresponding to network element 204 of the communication system 20 are DLAF network elements in the communication network shown in Figure 3.

[0172] It is understood that the communication system 20 shown in Figure 1 is for illustrative purposes only and is not intended to limit the technical solutions of this application. Those skilled in the art should understand that in specific implementations, the communication system 20 may also include other devices, and the number of network elements or nodes in the distributed ledger may be determined according to specific needs without limitation.

[0173] Optionally, each network element or device in Figure 1 of this application (such as a node in distributed ledger 201, a node in distributed ledger 202, network element 203, or network element 204, etc.) may also be referred to as a communication device, which may be a general-purpose device or a special-purpose device. This application does not make any specific limitation on this.

[0174] Optionally, the functions of each network element or device in Figure 1 of this application (e.g., nodes in distributed ledger 201, nodes in distributed ledger 202, network element 203, or network element 204, etc.) can be implemented by one device, multiple devices working together, or by one or more functional modules within a single device. This application does not impose specific limitations on these aspects. It is understood that the aforementioned functions can be network elements in hardware devices, software functions running on dedicated hardware, a combination of hardware and software, or virtualization functions instantiated on a platform (e.g., a cloud platform).

[0175] In practical implementation, each network element or device in Figure 1 of this application (e.g., nodes in distributed ledger 201, nodes in distributed ledger 202, network element 203, or network element 204, etc.) can adopt the composition structure shown in Figure 4, or include the components shown in Figure 4. Figure 4 shows a schematic diagram of the hardware structure of a communication device applicable to this application. The communication device 40 includes at least one processor 401 and at least one communication interface 404 for implementing the method provided in this application. The communication device 40 may also include a communication line 402 and a memory 403.

[0176] The processor 401 may be a general-purpose central processing unit (CPU), a microprocessor, an application-specific integrated circuit (ASIC), or one or more integrated circuits used to control the execution of the program of the present application.

[0177] Communication line 402 may include a path for transmitting information between the aforementioned components, such as a bus.

[0178] Communication interface 404 is used for communication with other devices or communication networks. Communication interface 404 can be any transceiver-like device, such as an Ethernet interface, a radio access network (RAN) interface, a wireless local area network (WLAN) interface, a transceiver, pins, a bus, interface circuits, or transceiver circuits, etc.

[0179] The memory 403 may be a read-only memory (ROM) or other type of static storage device capable of storing static information and instructions, random access memory (RAM), cache, or other type of dynamic storage device capable of storing information and instructions. It may also be an electrically erasable programmable read-only memory (EEPROM), a compact disc read-only memory (CD-ROM) or other optical disc storage, optical disc storage (including compressed optical discs, laser discs, optical discs, digital universal optical discs, Blu-ray discs, etc.), magnetic disk storage media, or other magnetic storage devices, or any other medium capable of carrying or storing desired program code in the form of instructions or data structures and accessible by a computer, but is not limited thereto. The memory may exist independently and be coupled to the processor 401 via communication line 402. The memory 403 may also be integrated with the processor 401. The memory provided in this application is generally non-volatile.

[0180] The memory 403 stores computer execution instructions related to the solution provided in this application, and its execution is controlled by the processor 401. The processor 401 executes the computer execution instructions stored in the memory 403 to implement the method provided in this application. Alternatively, in this application, the processor 301 may execute the processing-related functions of the method provided below, and the communication interface 404 may be responsible for communicating with other devices or communication networks; this application does not specifically limit this aspect.

[0181] Optionally, the processor 401 and / or memory 403 may include an AI module (not shown in Figure 4). This AI module is used to implement AI-related functions. The AI ​​module can be implemented through software, hardware, or a combination of both. For example, the AI ​​module may include a RIC module. For instance, the AI ​​module can be a near real-time RIC or a non-real-time RIC.

[0182] Optionally, the computer execution instructions in this application may also be referred to as application code, and this application does not specifically limit them.

[0183] The coupling in this application is an indirect coupling or communication connection between devices, units, or modules, which can be electrical, mechanical, or other forms, and is used for information exchange between devices, units, or modules.

[0184] As one embodiment, processor 401 may include one or more CPUs, such as CPU0 and CPU1 in FIG4.

[0185] As one embodiment, the communication device 40 may include multiple processors, such as processor 401 and processor 407 in FIG. 4. Each of these processors may be a single-core (single-CPU) processor or a multi-core (multi-CPU) processor. Here, a processor may refer to one or more devices, circuits, and / or processing cores for processing data (e.g., computer program instructions).

[0186] As one embodiment, the communication device 40 may further include an output device 405 and / or an input device 406. The output device 405 is coupled to the processor 401 and can display information in various ways. For example, the output device 405 may be a liquid crystal display (LCD), a light-emitting diode (LED) display device, a cathode ray tube (CRT) display device, or a projector, etc. The input device 406 is coupled to the processor 401 and can receive user input in various ways. For example, the input device 406 may be a mouse, keyboard, touchscreen device, or sensing device, etc.

[0187] It is understood that the composition shown in Figure 4 does not constitute a limitation on the communication device. In addition to the components shown in Figure 4, the communication device may include more or fewer components than shown, or combine certain components, or have different component arrangements.

[0188] The method provided in this application will now be described with reference to the accompanying drawings. Each network element in the following embodiments may include the components shown in Figure 4, which will not be elaborated upon further.

[0189] It is understood that the nodes (such as the first node, the second node, the third node, or the fourth node, etc.) in the following embodiments of this application may perform some or all of the steps in this application. These steps are merely examples, and this application may also perform other steps or variations thereof. Furthermore, the steps may be performed in different orders as presented in this application, and it is not necessary to perform all the steps in this application.

[0190] It is understood that the methods provided below in this application use nodes (such as the first node, the second node, the third node, or the fourth node, etc.) as examples to illustrate the method, but this application does not limit the execution subject of the interaction. For example, any node in the method provided in the following embodiments of this application can also be a chip, chip system, or processor that supports the implementation of the method by the node, or it can also be a logical node, logical module, or software that can implement all or part of the functions of the node.

[0191] It is understood that the method provided in this application can be applied to the communication system 20 shown in Figure 1 above. For example, the first distributed ledger in the following embodiments of this application can be distributed ledger 201 in the communication system 20, and the second distributed ledger in the following embodiments of this application can be distributed ledger 202 in the communication system 20; wherein the first distributed ledger and the second distributed ledger belong to different operators. It is understood that for two distributed ledgers of different operators, the operators will create a pair of nodes that can establish communication through a roaming architecture; this pair of nodes is the first node and the second node, that is, the first node is the node in the first distributed ledger that can communicate with the node in the second distributed ledger (established through a roaming architecture), and correspondingly, the second node is the node in the second distributed ledger that can communicate with the node in the first distributed ledger (established through a roaming architecture). Specifically, the first node can be a node in the distributed ledger 201 in the communication system 20, or a communication device that simultaneously has the functions of the node and the network element 203. The second node can be a node in the distributed ledger 202 in the communication system 20, or a communication device that simultaneously has the functions of either node and the network element 204.

[0192] As shown in Figure 5, a data transmission method provided in this application may include the following steps:

[0193] S501, First node determines first message.

[0194] The first message is used to indicate information about the first identifier, the second identifier, and the first data; the first identifier is the identifier of the first distributed ledger, the second identifier is the identifier of the second distributed ledger, the first data is the data in the first distributed ledger, and the information of the first data includes the first data or the identifier of the first data.

[0195] The first node is a node in the first distributed ledger, such as a DLE network element in the first distributed ledger; or, the first node is a communication device that simultaneously has the functions of a node in the first distributed ledger and the function of managing nodes in the first distributed ledger; for example, the first node is a communication device that has the functions of both a DLE network element and a DLAF network element in the first distributed ledger. In other words, the first node is composed of a DLE network element and a DLAF network element from the first distributed ledger. The DLE network element is a DLE network element in the first distributed ledger that can communicate with nodes in the second distributed ledger.

[0196] For example, when the amount of the first data is greater than or equal to a preset threshold, the information of the first data includes the information of the first data; when the amount of the first data is less than the preset threshold, the information of the first data includes the first data.

[0197] Optionally, the first node determines the first message, including: the first node signing the information of the first identifier, the second identifier, and the first data to generate the first message. That is, the first message also includes the first node's signature.

[0198] Optionally, the first node determines the first message, including: when there is a need to send the first data to the second distributed ledger in the first distributed ledger, the first node determines the first message.

[0199] Typically, when the node owning the first data joins the second distributed ledger, it indicates that the first distributed ledger has a need to send the first data to the second distributed ledger; or, when the second distributed ledger subscribes to data in the first distributed ledger, it indicates that the first distributed ledger has a need to send the first data to the second distributed ledger. In other words, the reasons for transmitting the first data include the node owning the first data joining the second distributed ledger, or the second distributed ledger subscribing to data in the first distributed ledger.

[0200] For example, the node to which the first data belongs can be a node in the first distributed ledger; for example, the node to which the first data belongs can be a DLE network element in the first distributed ledger. For example, the node to which the first data belongs can be any other node in the first distributed ledger besides the first node.

[0201] Specifically, the joining of the first data node to the second distributed ledger can also be understood as: the first data node leaving the first distributed ledger and then joining the second distributed ledger; that is, the joining of the first data node to the second distributed ledger can be replaced by: the first data node leaving the first distributed ledger and joining the second distributed ledger. Alternatively, the joining of the first data node to the second distributed ledger can also be understood as: the first data node remaining in the first distributed ledger and also joining the second distributed ledger; that is, the joining of the first data node to the second distributed ledger can be replaced by: the first data node remaining in the first distributed ledger and joining the second distributed ledger.

[0202] Specifically, the second distributed ledger can subscribe to data in the first distributed ledger through steps #1 to #3 in Figure 9 below. For details, please refer to the relevant description in Figure 9 below, which will not be repeated here.

[0203] Optionally, the first message may also indicate one or more of the following: the signature of the first node, the reason for the transmission of the first data, the identifier of the node to which the first data belongs, and the first verification path. The first verification path is the verification path of the first data in the first distributed ledger.

[0204] For example, the reason for the transmission of the first data can be represented by a 1-bit value in the first message; for instance, a 1-bit value indicates that the reason for the transmission of the first data is that the node to which the first data belongs has joined the second distributed ledger, and a 1-bit value of 0 indicates that the reason for the transmission of the first data is that the second distributed ledger has subscribed to the data in the first distributed ledger.

[0205] For example, the node to which the first data belongs can indicate the data source of the first data, serving as an identifier / index of the first data in the second distributed ledger.

[0206] Optionally, before the first node determines the first message, it can also sign the information of the first data, the first identifier, and the second identifier to generate a data output transaction. Based on the data output transaction, a first verification path is determined. In this case, the first message also indicates the first verification path. Furthermore, the first node can store the data output transaction in a first distributed ledger.

[0207] Specifically, the implementation of the first node generating and storing data output transactions can be found in the relevant descriptions of steps S507 to S508 below, and will not be repeated here.

[0208] As can be understood, the verification path refers to the storage location of data in the distributed ledger; for example, the hash value from the block containing the data to the hash value of the root block of the blockchain. Therefore, the verification path of the first data in the first distributed ledger can be understood as the location of the first data in the first distributed ledger.

[0209] S502, the first node sends a first message to the second node; correspondingly, the second node receives the first message from the first node.

[0210] The second node is a node in the second distributed ledger, such as a DLE network element in the second distributed ledger. Alternatively, the second node is a communication device that simultaneously possesses the functions of a node in the second distributed ledger and the functions for managing nodes in the second distributed ledger; for example, the second node is a communication device that possesses the functions of a DLE network element in the second distributed ledger and a DLAF network element in the second distributed ledger. That is, the second node is composed of a DLE network element and a DLAF network element in the second distributed ledger. The DLE network element is a DLE network element in the second distributed ledger that can communicate with nodes in the first distributed ledger.

[0211] For example, the first node and the second node can communicate through a gateway; for instance, the first node can send a first message to the SEPP of the operator used to build the first distributed ledger, and then the SEPP of the operator used to build the first distributed ledger will send the first message to the SEPP of the operator used to build the second distributed ledger, and further, the SEPP of the operator used to build the second distributed ledger will send the first message to the network of the second distributed ledger, that is, the SEPP of the operator used to build the second distributed ledger will send the first message to the second node to ensure the security of the first message transmitted between the two operators.

[0212] S503, the second node determines whether the second distributed ledger allows the first data input based on the first identifier.

[0213] For example, the second node can query a list of distributed ledgers; when the first distributed ledger or the first identifier exists in the distributed list, it means that the second distributed ledger allows the first data input; at this time, it can also be understood that the first distributed ledger is trustworthy, and further, the first distributed ledger allows data (such as the first data) from the first distributed ledger to be input.

[0214] Optionally, the second node can also determine whether the second distributed ledger allows the input of the first data based on the reason for the transmission of the first data. For example, the reason for the transmission of the first data may be determined by the second node itself; or it may be informed to the second node by the first node, such as the first message also indicating the reason for the transmission of the first data; or, when the second node is one of the nodes in the second distributed ledger, it may be informed to the second node by the DLAF network element used to manage the nodes in the second distributed ledger.

[0215] Specifically, when the reason for transmitting the first data is that the node to which the first data belongs accesses the second distributed ledger, the second node can determine whether the second distributed ledger allows the node to join. This can be done by querying the second distributed ledger's data access policy to determine whether adding new data is allowed, and then further determining whether the node can join; or by obtaining information from the DLAF network element (such as the fourth node) used to manage nodes in the second distributed ledger to determine whether the second distributed ledger allows the node to join. Specifically, if the second distributed ledger's data access policy indicates that adding new data is allowed, or the DLAF network element used to manage nodes in the second distributed ledger reports that the second distributed ledger allows the node to join, and the first distributed ledger is trusted, then the second node determines that the second distributed ledger allows the input of the first data. If the second node cannot determine whether the second distributed ledger allows the node to join, or the second distributed ledger's data access policy indicates that adding new data is not allowed, or the DLAF network element used to manage nodes in the second distributed ledger reports that the second distributed ledger does not allow the node to join, then the second node does not allow the first data input to the second distributed ledger.

[0216] When the reason for transmitting the first data is that the second distributed ledger has subscribed to data from the first distributed ledger, the second node can query its local storage to see if the subscription ID exists. If the subscription ID exists in its local storage and the first distributed ledger is trusted, the second node determines that it is allowed to receive the data to be transmitted. If the subscription ID does not exist in its local storage, the second node can request the DLAF network element used to manage the nodes in the second distributed ledger to query whether the subscription ID exists. Thus, when the DLAF network element used to manage the nodes in the second distributed ledger reports that the subscription ID exists and the first distributed ledger is trusted, the second node determines that the second distributed ledger allows the first data input. When the DLAF network element used to manage the nodes in the second distributed ledger reports that the subscription ID does not exist, or when the DLAF network element used to manage the nodes in the second distributed ledger does not report, the second node determines that the second distributed ledger does not allow the first data input.

[0217] Specifically, the data access policy of the second distributed ledger is created when the second distributed ledger is built, and the data access policy of the second distributed ledger is used to indicate whether data is allowed to be entered into the second distributed ledger.

[0218] Optionally, the second node determining that the second distributed ledger allows the first data input can also be understood as: the second distributed ledger allows the first data to be stored in its ledger, thus the second node can store the first data in the second distributed ledger; or, after the second node determines that the second distributed ledger allows the first data input, the second node can verify the first node's signature, that is, determine whether the second distributed ledger allows the first data input based on the first node's signature. The first node's signature can be carried in the first message; that is, the first message also indicates the first node's signature.

[0219] Specifically, the second node can verify the first node's signature using the first node's public key. Because there is a network connection between the first and second nodes, they store each other's public keys, enabling mutual verification. This prevents the first data from being tampered with during transmission, ensuring the data source is trustworthy. When the first node's signature verification passes, it means the first data can be stored in the second distributed ledger, i.e., the second distributed ledger allows the first data input; when the first node's signature verification fails, it means the first data cannot be stored in the second distributed ledger, i.e., the second distributed ledger does not allow the first data input.

[0220] Optionally, when the information of the first data includes the ID of the first data, after the second node determines that the second distributed ledger allows the input of the first data, the second node can send a feedback message to send the first message; thus, the first node can send the first data to the second node.

[0221] Specifically, the first node can send a message containing complete first data to the second node; alternatively, the first node can send multiple messages to the second node, each message containing a portion of the first data, ensuring that all the first data is delivered to the second node after multiple messages. For example, when the first node sends multiple messages to the second node, the second node can send an acknowledgment (ACK) message to the first node after successfully receiving each message. The first node then sends the next message to the second node after receiving the ACK message.

[0222] Optionally, when the first message is used to indicate the first verification path, the second node can also verify the first verification path to ensure that the first data is stored in the first distributed ledger, i.e., the first data sent by the first node is trustworthy, thus preventing the first node from maliciously sending data to the second node. Specifically, when it is determined that the first data is indeed stored in the first distributed ledger, it indicates that the first data was not maliciously sent by the first node, and therefore the first data can be stored in the second distributed ledger. In other words, the second node can determine whether the second distributed ledger allows the input of the first data based on the first verification path. Specifically, when it is determined according to the first verification path that the first data is indeed stored in the first distributed ledger, it indicates that the second distributed ledger allows the input of the first data. When it is determined according to the first verification path that the first data is not stored in the first distributed ledger, it indicates that the second distributed ledger does not allow the input of the first data.

[0223] Specifically, the first verification path includes the hash value of the sibling block of the block containing the first data in the first distributed ledger up to the hash value of the root block of the blockchain containing the first data. Therefore, the second node can calculate the hash value of the block containing the first data based on the first verification path, and calculate the hash value of the first data based on the first data. Then, it compares the calculated hash value of the first data with the hash value of the block containing the first data. If the comparison is consistent, it is determined that the first data is indeed stored in the first distributed ledger. If the comparison is inconsistent, it is determined that the first data is not stored in the first distributed ledger.

[0224] S504. When it is determined that the second distributed ledger allows the input of the first data, the second node signs the first identifier, the second identifier, the information of the first data, and the second timestamp to generate a data input transaction. The second timestamp is the timestamp at which the node to which the first data belongs joined the second distributed ledger.

[0225] Optionally, when the first message also includes the signature of the first node, step S504 can be replaced by: when it is determined that the second distributed ledger allows the first data input and the signature verification of the first node is successful, the second node signs the first identifier, the second identifier, the information of the first data, the second timestamp, and the signature of the first node to generate a data input transaction.

[0226] Optionally, when the first message is also used to indicate the first verification path, step S504 can be replaced by: when it is determined that the second distributed ledger allows the first data input, and it is determined based on the first verification path that the first data is indeed stored in the first distributed ledger, the second node signs the first identifier, the second identifier, the information of the first data, and the second timestamp to generate a data input transaction.

[0227] Optionally, when the first message is also used to indicate the reason for the transmission of the first data, step S504 can be replaced by: when it is determined that the second distributed ledger allows the first data input, the second node signs the first identifier, the second identifier, the information of the first data, the reason for the transmission of the first data, and the second timestamp to generate a data input transaction.

[0228] Optionally, after generating the data input transaction, the second node can use other nodes in the second distributed ledger to verify the data input transaction. For details, please refer to the relevant description in Figure 13 below, which will not be repeated here.

[0229] S505, the second node inputs the transaction data and stores it in the second distributed ledger.

[0230] For example, the second node learns from the second identifier that the first data needs to be stored in the second distributed ledger; therefore, after determining the data input transaction, it stores it in the second distributed ledger.

[0231] Optionally, the second distributed ledger includes a second blockchain and a second database. Data input transactions are stored in the second blockchain; the data transmission method further includes: the second node storing a second timestamp of the first data in the second database, or updating the information of the node to which the first data belongs in the second database using the information of the first data.

[0232] For example, in conjunction with the implementation of the first message described in step S504 above, the data input transaction includes the content shown in Figure 6(a), that is, the data input transaction includes information of the first data, a first identifier, a second identifier, a second timestamp, and the signature of the second node; furthermore, when the first message is also used to indicate the reason for the transmission of the first data and / or the signature of the first node, the data input transaction also includes the reason for the transmission of the first data and / or the signature of the first node.

[0233] Furthermore, when the reason for the transmission of the first data is that the node to which the first data belongs has joined the second distributed ledger, it means that the second database does not store information about the node to which the first data belongs. Therefore, the timestamp of the node to which the first data belongs joining the second distributed ledger (i.e., the second timestamp) can be stored in the second database. In addition, a storage area for storing information about the node to which the first data belongs can be created in the second database. For example, as shown in Figure 6(b), this storage area can store the ID of the node to which the first data belongs plus the latest information of the node (such as the information about the first data). When the reason for the transmission of the first data is that the second distributed ledger has subscribed to data in the first distributed ledger (such as the information about the first data), the second database stores information about the node to which the first data belongs. At this time, the second node can update the information about the node to which the first data belongs based on the information about the first data.

[0234] Specifically, the second blockchain can be a blockchain of a second distributed ledger; the second database can be the world state of the second distributed ledger.

[0235] S506, the second node sends a second message to the first node; correspondingly, the first node receives the second message from the second node. The second message indicates whether the first data has been successfully stored in the second distributed ledger.

[0236] For example, the first node and the second node can communicate through a gateway; for instance, the second node can send a second message to the SEPP of the operator used to build the second distributed ledger, and then the SEPP of the operator used to build the second distributed ledger sends the second message to the SEPP of the operator used to build the first distributed ledger, and further, the SEPP of the operator used to build the first distributed ledger sends the second message to the network of the first distributed ledger, that is, the SEPP of the operator used to build the first distributed ledger sends the second message to the first node.

[0237] For example, the second message can be represented by a 1-bit value. A 1-bit value indicates that the first data was successfully stored in the second distributed ledger; conversely, a 0-bit value indicates that the first data was not successfully stored in the second distributed ledger, meaning the inter-ledger transmission failed. Alternatively, a 0-bit value indicates that the first data was successfully stored in the second distributed ledger; conversely, a 1-bit value indicates that the first data was not successfully stored in the second distributed ledger, meaning the inter-ledger transmission failed.

[0238] Optionally, when it is determined in step 503 that the second distributed ledger does not allow the input of the first data, and / or it is determined that the first data has not been successfully stored in the second distributed ledger, the second node does not need to execute steps S504 to S505, but directly executes step S506. At this time, the second message indicates that the first data has not been successfully stored in the second distributed ledger.

[0239] Optionally, when the second message indicates that the first data has been successfully stored in the second distributed ledger, the second node can also generate a second verification path based on the data input transaction. The second verification path is the verification path of the first data in the second distributed ledger. In this case, the second message is also used to indicate the second verification path.

[0240] For example, the implementation of the second verification path is similar to that of the first verification path described above. For details, please refer to the relevant description of the first verification path described above, which will not be repeated here.

[0241] Optionally, when the second message indicates that the first data has been successfully stored in the second distributed ledger, and the first node has not generated a data output transaction before step S501, after step S506, based on the implementation of the data output transaction, the first node can also execute S507 to S508 as shown in Figure 7:

[0242] S507. The first node signs the information, first identifier, and second identifier of the first data to generate a data output transaction.

[0243] For example, a data output transaction includes information about the first data, a first identifier, a second identifier, and a signature of the first node.

[0244] Optionally, when the second message is also used to indicate the second verification path, step S507 can be replaced by: the first node verifies the second verification path, and when it is determined based on the second verification path that the first data has been stored in the second distributed ledger, the first data information, the first identifier, and the second identifier are signed to generate a data output transaction.

[0245] S508, The first node stores the data output transaction in the first distributed ledger.

[0246] Optionally, the first distributed ledger includes a first blockchain and a first database. Data output transactions are stored in the first blockchain, and the first database includes information about the first data and a first timestamp. The first timestamp is the timestamp when the node to which the first data belongs joins the first distributed ledger.

[0247] For example, a data output transaction includes the content shown in Figure 8(a), namely, the data output transaction includes information about the first data, a first identifier, a second identifier, and the signature of the first node. Specifically, the first blockchain can be a blockchain of a first distributed ledger; the first database can be the world state of the first distributed ledger.

[0248] Optionally, since the node to which the first data belongs is a node in the first distributed ledger, the first database stores information about the node to which the first data belongs (such as the ID of the node to which the first data belongs plus the latest information of that node) and a first timestamp. In this case, the first node can delete the information about the node to which the first data belongs stored in the first database; or, the first node can update the first timestamp to an output indicator, which indicates that the first data has been output from the first distributed ledger. For example, as shown in Figure 8(b), the first timestamp is updated to a null (NULL) indicator.

[0249] Optionally, if the first node generates a data output transaction before step S501, and the second message is also used to indicate the second verification path, then after receiving the second message, the first node can also verify the second verification path to determine that the first data has indeed been successfully stored in the second distributed ledger.

[0250] This application provides a data transmission method in which, when there is a need for cross-ledger data transmission between distributed ledgers built by different operators (for example, data stored in a first distributed ledger (such as first data) needs to be transmitted to a second distributed ledger for storage, and the first and second distributed ledgers are built by different operators), a node in the first distributed ledger (i.e., the first node) can send the identifier of the first distributed ledger (i.e., the first identifier), the identifier of the second distributed ledger (the second identifier), and the information of the data to be transmitted (i.e., the first data) to a node in the second distributed ledger (i.e., the second node). That is, the first node can send a first message to the second node, wherein the first message is used to indicate the information of the first identifier, the second identifier, and the first data.

[0251] Understandably, different operators use SEPP to exchange information to ensure the security of information exchange between operators. Therefore, the first node can send the first message to the SEPP of the operator to which the first distributed ledger belongs, and then the SEPP of the operator to which the first distributed ledger belongs will send the first message to the SEPP of the operator to which the second distributed ledger belongs, so as to ensure that the transmission of the first message between the two operators is secure.

[0252] Furthermore, since the first message is used to indicate the first identifier and the second identifier, the second node can determine whether the first distributed ledger is trustworthy based on the first identifier. When the first distributed ledger is trustworthy, the second node stores the information of the first data in the second distributed ledger based on the second identifier, thereby ensuring the security of the information of the first data in the process from the first distributed ledger to the second distributed ledger and improving the user experience.

[0253] The above is an overall description of the process of the "data transmission method" provided in this application. The following is a detailed description of the implementation of the "second distributed ledger subscribing to data in the first distributed ledger" mentioned above.

[0254] Referring to Figure 9, this is a schematic diagram illustrating the process of a second distributed ledger subscribing to data in a first distributed ledger, as provided in this application. Specifically, the implementation includes the following steps:

[0255] Step #1: The fourth node sends a subscription request message to the third node, and the third node receives the subscription request message from the fourth node. The subscription request message indicates the first identifier, the second identifier, and the subscription event.

[0256] The third node manages the nodes in the first distributed ledger. For example, the third node can be a DLAF network element of the first distributed ledger; or, when the first node is a communication device that simultaneously functions as a node in the first distributed ledger and manages the nodes in the first distributed ledger, the third node is the first node. Similarly, the fourth node manages the nodes in the second distributed ledger. For example, the fourth node can be a DLAF network element of the second distributed ledger. When the second node is a communication device that simultaneously functions as a node in the second distributed ledger and manages the nodes in the second distributed ledger, the fourth node is the second node.

[0257] For example, the subscription event can be set to a period T, meaning the subscription event occurs periodically, thus requiring the first distributed ledger to periodically send data from the first distributed ledger to the second distributed ledger. In this case, the subscription event can be update information from the first distributed ledger within that period. Alternatively, the subscription event can be an event related to a specific node in the first distributed ledger, so when the subscription event occurs, it indicates that the data of the node to which the first data belongs in the first distributed ledger has been updated; therefore, the first distributed ledger needs to send the event related to that node to which the first data belongs to the second distributed ledger. Alternatively, the subscription event can be an event related to the first distributed ledger, so when the first distributed ledger adds or removes nodes (such as DLE network elements), and / or its configuration information is updated, it indicates that the subscription event has occurred, thus requiring the first distributed ledger to send its update information to the second distributed ledger.

[0258] In this application, taking the change of the node to which the first data belongs as an example to trigger a subscription event, the first distributed ledger needs to send the data (such as the first data) of the node to which the first data belongs to the second distributed ledger. Specifically, the change of the node to which the first data belongs can be the node joining the first distributed ledger, the node leaving the first distributed ledger, or the data of the node to which the first data belongs being updated, etc.

[0259] Optionally, the subscription request message may also indicate the subscription ID.

[0260] Step #2: The third node determines that the fourth node is trustworthy, the first distributed ledger allows data to be subscribed across ledgers, and determines the subscription ID.

[0261] For example, the third node can determine whether the fourth node is trustworthy. If the third node determines that the fourth node is untrustworthy, then the second distributed ledger subscription fails. The third node can also determine whether the first distributed ledger allows cross-ledger subscriptions. If the third node determines that the first distributed ledger does not allow cross-ledger subscriptions, then the second distributed ledger subscription fails.

[0262] Furthermore, the third node can also determine the subscription ID. For example, the subscription ID can be generated and communicated to the third node by the fourth node, such as when the subscription request message in step #1 also indicates a subscription ID. In this case, the third node can determine the subscription ID upon receiving the subscription request message. Alternatively, the subscription ID can be generated by the third node itself, such as when the third node generates a subscription ID based on the subscription request message after receiving it. Further, after determining the subscription ID, the third node can communicate it to the fourth node. Specifically, the third node can generate the subscription ID based on the first identifier, the second identifier, and the subscription event.

[0263] Step #3: The third node sends a subscription response message to the fourth node, and the fourth node receives the subscription response message from the third node.

[0264] For example, if the third node determines that the fourth node is untrusted, and / or the first distributed ledger does not allow data to subscribe across ledgers, the subscription response message indicates that the subscription request failed. If the third node determines that the fourth node is trustworthy, and the first distributed ledger does not allow data to subscribe across ledgers, the subscription response message indicates that the subscription request succeeded when the subscription ID is generated by the fourth node; and when the subscription ID is generated by the third node, the subscription response message indicates that the subscription request succeeded and also indicates the subscription ID.

[0265] The implementation of the first message in step S501 above will be described in detail below.

[0266] Optionally, the first node determines the first message, including: the first node obtains a first identifier, a second identifier, and an identifier of the first data; and determines the first message based on the first identifier, the second identifier, and the identifier of the first data.

[0267] For example, based on the relationship between the first node and the first distributed ledger, it can be known that the identifier of the first distributed ledger (i.e., the first identifier) ​​is known to the first node; at this time, when the first node learns the identifier of the second representation and the first data, it can determine the first message.

[0268] For example, the second identifier and the identifier of the first data can be obtained based on the following two possible methods:

[0269] In one possible implementation, the identifier of the first data can be provided to the first node by the node to which the first data belongs / a third node. For example, the node to which the first data belongs / a third node can inform the first node of the identifier of the first data by sending a third message. The third message is used to indicate the identifier of the first data.

[0270] As an example, when the reason for transmitting the first data is that the node to which the first data belongs joins the second distributed ledger—that is, when the node to which the first data belongs itself has a need to join the second distributed ledger—the node to which the first data belongs can inform the first node of the identifier of the first data. In other words, the node to which the first data belongs actively triggers the first node to execute the data transmission process, enabling the first node to learn the identifier of the first data.

[0271] Specifically, when the node owning the first data needs to join the second distributed ledger, it can query the first distributed ledger to identify nodes that can communicate with nodes in the second distributed ledger, thus determining the first node. Further, a third message is sent to the first node to trigger it to execute the data transmission process. That is, as shown in Figure 10, before step S501, the data transmission method also includes step S500A-1:

[0272] S500A-1, the node to which the first data belongs sends a third message to the first node; correspondingly, the first node receives the third message from the node to which the first data belongs. The third message is used to trigger the first node to execute the data transmission process, and also to indicate the identifier of the first data, enabling the first node to obtain the identifier of the first data.

[0273] Specifically, the identifier of the first data can be the index of the first data or the ID of the node to which the first data belongs.

[0274] Optionally, when the reason for the transmission of the first data is that the second distributed ledger has subscribed to the first distributed ledger, the identifier of the first data may further include the type of data subscribed to by the second distributed ledger. For example, the data described in this scheme includes three types: (1) data stored in the first database; (2) data stored in the first blockchain; and (3) data obtained after processing by the first database and the first blockchain.

[0275] Specifically, the data stored in the first database refers to: the timestamp (e.g., the first timestamp) of a node (such as the node to which the first data belongs) added to the first distributed ledger, and the latest data of the node in the first distributed ledger (or, it can also be called basic data); taking car data as an example, the latest data of the node may include the license plate, the color of the car, the price of the car, the number of passengers the car can carry, etc. The data stored in the first blockchain refers to: the transaction data of the nodes; taking car data as an example, the transaction data of the nodes may be the transaction data of the cars. The data obtained after processing the first database and the first blockchain refers to: the change data of the nodes; taking car data as an example, the change data of the nodes may include the number of changes to the node's relevant information, the initial state of the node's latest information, and the current state, etc.

[0276] Therefore, when the identifier of the first data also includes the type of data subscribed to by the second distributed ledger, the first data is the data corresponding to the type subscribed to by the second distributed ledger in the data corresponding to the node to which the first data belongs (i.e., the first data is the data corresponding to the type subscribed to by the second distributed ledger). When the identifier of the first data does not include the type subscribed to by the second distributed ledger, the first data is the latest data of the node to which the first data belongs, stored in the first database.

[0277] Optionally, the third message may also be used to indicate the second identifier and / or the reason for the transmission of the first data. Wherein, when the third message is used to indicate the second identifier, it means that the first node can also obtain the second identifier from the node to which the first data belongs.

[0278] Specifically, the implementation of the third message indicating the reason for the transmission of the first data is similar to the implementation of the first message indicating the reason for the transmission of the first data in step S501 above. For details, please refer to the relevant description in step S501 above, which will not be repeated here.

[0279] As another example, when a third node learns that there is a data output requirement in the first distributed ledger, the third node can determine whether the first distributed ledger allows data output. If so, it determines the first identifier, the second identifier, and the identifier of the first data. Furthermore, based on the identifier of the first data, it determines and informs the first node of the third message, thereby allowing the first node to obtain the identifier of the first data based on the third message.

[0280] For example, this possible implementation is applicable to scenarios where the first distributed ledger is about to be deleted and the data in the first distributed ledger needs to be transferred to the second distributed ledger for storage, or where the second distributed ledger is created and the data in the first distributed ledger needs to be used to initialize the second distributed ledger, or where the second distributed ledger has subscribed to the data in the first distributed ledger.

[0281] Specifically, the first node can obtain the first identifier and the second identifier based on step S500A-2 as shown in Figure 10. That is, before step S501, the data transmission method may also include step S500A-2:

[0282] S500A-2, the third node sends a third message to the first node; correspondingly, the first node receives the third message from the third node. Thus, the first node obtains the identifier of the first data based on the third message.

[0283] Optionally, when the first node and the third node are the same node, step S500A-2 can be replaced by: the first node determining the identifier of the first data.

[0284] Combining the two examples above, optionally, the first node determines the first message by: the first node determining the first message based on the third message. That is, the first node obtains the identifier of the first data upon receiving the third message. Furthermore, if the third message also indicates a second identifier, the first node can also obtain the second identifier based on the third message.

[0285] In another possible implementation, the second identifier and the identifier of the first data can be obtained by the first node from the second or third node. That is, the fourth message is used to indicate the second identifier and the identifier of the first data.

[0286] Optionally, the fourth message may also be used to indicate one or more of the first identifier, the reason for the transmission of the first data, and the identifier of the node to which the first data belongs.

[0287] As an example, the second node indicates to the first node via a fourth message that the second distributed ledger has permission to access the first data; that is, the fourth message is used to indicate that the second distributed ledger has permission to access the first data.

[0288] For example, this example applies to scenarios where a second distributed ledger subscribes to data in a first distributed ledger, or where a second distributed ledger is created and needs to be initialized using data in a first distributed ledger.

[0289] For example, the fourth message can be a token. In this case, the implementation of the fourth message can be seen in the implementation of the token in Figure 16 below, and will not be repeated here.

[0290] As another example, the second node indicates to the first node via a fourth message that the first data needs to be transferred to the second distributed ledger; that is, the fourth message is used to trigger the first node to transfer the first data to the second distributed ledger.

[0291] For example, this example applies to scenarios where the reason for the transmission of the first data is that the second distributed ledger has subscribed to data in the first distributed ledger, and after the subscription event occurs, the second distributed ledger does not receive information about the first data from the first node, or the node to which the first data belongs wants to join the second distributed ledger, and the second node / fourth node receives an access request from the node to which the first data belongs.

[0292] Combining the two examples above, specifically, the first node can obtain the first identifier and the second identifier based on step S500B-1 as shown in Figure 11. That is, before step S501, the data transmission method may also include step S500B-1:

[0293] S500B-1, the second node sends a fourth message to the first node; correspondingly, the first node receives the fourth message from the second node.

[0294] As another example, when the third node learns that there is a data output requirement in the first distributed ledger, the third node can determine the fourth message and inform the first node of it. Specifically, the fourth message may be the same as or different from the third message described in step S500A-2 of Figure 10 above.

[0295] Specifically, the first node can obtain the first identifier and the second identifier based on step S500B-5 as shown in Figure 11. That is, before step S501, the data transmission method may also include step S500B-2:

[0296] S500B-2, the third node sends a fourth message to the first node; correspondingly, the first node receives the fourth message from the third node.

[0297] The fourth message is used to indicate the second identifier and the identifier of the first data. Furthermore, the fourth message is also used to indicate the reason for the transmission of the first data.

[0298] Optionally, when the first node and the third node are the same node, step S500B-2 can be replaced by: the first node determining the identifier of the second identifier and the identifier of the first data.

[0299] Combining the two possible implementation methods mentioned above, optionally, the first node determines the first message, including: the first node determines whether to allow the first data to be output from the first distributed ledger; when it is determined that the first data is allowed to be output from the first distributed ledger, the first message is determined.

[0300] For example, the first node can determine whether to allow the first data to be output from the first distributed ledger based on the following four examples:

[0301] As a first example, the first node determines whether to allow the first data to be output from the first distributed ledger based on the data access policy of the first distributed ledger.

[0302] For example, a data access policy for the distributed ledger can be specified during its creation. This data access policy includes whether data transfer from the distributed ledger to other distributed ledgers is permitted. Thus, a first node can query the data access policy of the first distributed ledger based on a first identifier, thereby determining whether data output from the first distributed ledger is permitted, and ultimately deciding whether to allow the first data to be output from the first distributed ledger. Specifically, when the data access policy indicates that data output from the first distributed ledger is permitted, the first data is allowed to be output from the first distributed ledger. When the data access policy indicates that data output from the first distributed ledger is not permitted, the first data is not allowed to be output from the first distributed ledger.

[0303] Specifically, the first node can determine that there is a data output requirement in the first distributed ledger (e.g., it knows that the first data needs data). Alternatively, the first node can know that there is a data output requirement in the first distributed ledger based on the aforementioned third / fourth message; therefore, after receiving the third / fourth message, the first node can query the data access policy of the first distributed ledger.

[0304] Furthermore, when the first node can learn from the third / fourth message that there is a data output requirement in the first distributed ledger, and the data access policy of the first distributed ledger indicates that data output from the first distributed ledger is not allowed, i.e., the first data is not allowed to be output from the first distributed ledger, the first node can return a corresponding response message to indicate that the cross-ledger data transmission has failed. The destination address of the response message can be found in the relevant descriptions in Figure 10 or Figure 11 above, and will not be repeated here.

[0305] As a second example, when the first node can obtain information about the existence of data output requirements in the first distributed ledger based on the third / fourth message, the first node can determine whether to allow the data output of the first distributed ledger based on the identifier of the first data.

[0306] For example, the first node can query the first data in the first distributed ledger based on the identifier of the first data. If the first node can find the first data in the first distributed ledger, it indicates that data output from the first distributed ledger is allowed; if the first node cannot find the first data in the first distributed ledger, it indicates that data output from the first distributed ledger is not allowed, that is, the first data is not allowed to be output from the first distributed ledger. Furthermore, when the first node cannot find the first data in the first distributed ledger, the first node can return a response message to indicate that the cross-ledger data transmission has failed. The destination address of the response message can be referred to the relevant descriptions in Figures 10 and 11 above, and will not be repeated here.

[0307] As a third example, when the reason for the output of the data to be transmitted is that the node to which the first data belongs has joined the second distributed ledger, the first node can determine whether to allow the first data to be output from the first distributed ledger based on the first timestamp.

[0308] For example, if the node owning the first data joins the second distributed ledger within a very short time after joining the first distributed ledger, it may be because the node is controlled by an attacker and frequently joins and leaves the distributed ledger. Furthermore, the very short time it takes for the node to join the first distributed ledger to join the second distributed ledger also increases network resource consumption. Therefore, to prevent the node owning the first data from frequently joining and leaving the distributed ledger due to attacker control, and to conserve network resources, the decision to allow data output from the first distributed ledger can be based on the duration of the node's membership in the first distributed ledger. Specifically, the node owning the first data can obtain a first timestamp from the first database; further, it calculates the difference between the first timestamp and the current time. When the difference is less than a first threshold, data output from the first distributed ledger is not allowed, i.e., the first data is not allowed to be output from the first distributed ledger; when the difference is greater than or equal to the first threshold, data output from the first distributed ledger is allowed, i.e., the first data is allowed to be output from the first distributed ledger. For example, the first threshold can be a preset value; further, the first threshold can be used as configuration information for the first distributed ledger.

[0309] As a fourth example, the first node can determine whether to allow the first data to be output from the first distributed ledger based on the second identifier.

[0310] For example, a first node can query its locally stored list of distributed ledgers to check if a second identifier exists. If the second identifier exists in the list, it means that data output from the first distributed ledger is allowed, i.e., the first data is allowed to be output from the first distributed ledger. If the second identifier does not exist in the list, it means that data output from the first distributed ledger is not allowed, i.e., the first data is not allowed to be output from the first distributed ledger. Alternatively, when the second identifier does not exist in the list, the first node can request the second identifier from a third node. If the third node does not respond with the second identifier, i.e., the first node cannot obtain the second identifier from the third node, it means that data output from the first distributed ledger is not allowed, i.e., the first data is not allowed to be output from the first distributed ledger.

[0311] It should be noted that the four examples above can also be used in combination; that is, the first node can determine whether to allow the first data to be output from the first distributed ledger based on multiple judgment methods (i.e., any two judgment methods described in any two examples above, or any three judgment methods described in any three examples above, or all four judgment methods described in any four examples above). When the judgment results of these multiple judgment methods are all "allowing the first data to be output from the first distributed ledger", the first node can determine that the first data is allowed to be output from the first distributed ledger. If at least one of the judgment results of the multiple judgment methods is "disallowing the first data to be output from the first distributed ledger", then it means that the first data is output from the first distributed ledger.

[0312] Furthermore, the above example only uses the first node to determine whether the first data is allowed to be output from the first distributed ledger. In fact, the third node can also determine whether the first data is allowed to be output from the first distributed ledger. The specific implementation is similar to the implementation of the first node determining whether the first data is allowed to be output from the first distributed ledger. For details, please refer to the above description, which will not be repeated here.

[0313] It should be noted that Figures 5 to 11 above illustrate the example of "data in the first distributed ledger (i.e., the first data) needing to be transmitted to the second distributed ledger." In fact, this application also supports a scheme where "data in the second distributed ledger needs to be transmitted to the first distributed ledger." In this case, the implementation of the first node is similar to that of the second node in Figures 5 to 11, and the implementation of the second node is similar to that of the first node in Figures 5 to 11. Furthermore, the implementation of the third node is similar to that of the fourth node in Figures 5 to 11, and the implementation of the fourth node is similar to that of the third node in Figures 5 to 11. In other words, in this application, data in the first distributed ledger (i.e., the first data) can be transmitted to the second distributed ledger for storage, or data in the second distributed ledger can be transmitted to the first distributed ledger for storage. For details, please refer to the relevant descriptions in the above embodiments, which will not be repeated here.

[0314] To better understand the method provided in this application, the method is described below with reference to the communication system 20 shown in Figure 1. Specifically, refer to the methods shown in Figures 12, 14, 15, and 16 below. It should be understood that the methods shown in Figures 5 to 11, and the methods shown in Figures 12, 14, 15, and 16, which have the same function, can be referred to and learned from each other.

[0315] The following figures 12, 14, 15, and 16 illustrate the following scenario: the data to be transmitted is the first data; the first node is DLE#1 (at this time, the first node is only one node in the first distributed ledger); the node to which the first data belongs is DLE#0; the first distributed ledger is DL#1; the third node is DLAF#1 (at this time, the third node and the first node are different nodes); the second node is DLE#2 (at this time, the second node is only one node in the second distributed ledger); the second distributed ledger is DL#2; and the fourth node is DLAF#2 (at this time, the fourth node and the third node are different nodes). This will be explained uniformly here and will not be repeated.

[0316] Figure 12 illustrates another data transmission method provided in this application. In this method, DLE#1 in DL#1 can transmit data from DLE#0 in DL#1 to DLE#2 in DL#2, enabling DLE#2 to store the data of DLE#0 in DL#2, thus achieving cross-ledger data transmission and improving user experience. This method may include the following steps:

[0317] S1201 and DLE#1 obtain the ID of DL#2 and the ID of the data to be transmitted.

[0318] For example, the ID of DL#2 is the second identifier described in Figures 5 to 11 above; the ID of the data to be transmitted is the identifier of the first data described in Figures 5 to 11 above. Specifically, DLE#1 can obtain the ID of DL#2 and the ID of the data to be transmitted based on the following two cases:

[0319] Scenario 1: The reason for the output of the data to be transmitted is that DLE#0 adds DL#2. In this case, it can be understood that DLE#0 itself has a need to add DL#2; therefore, DLE#0 actively triggers DLE#1 to execute the data transmission process.

[0320] Specifically, DLE#0 can query the DLEs within DL#1 that can communicate with the DLEs within DL#2, thus determining that DLE#1 can communicate with the DLEs within DL#2 (i.e., DLE#2). Further, DLE#0 sends a trigger message #1 to DLE#1 to trigger DLE#1 to execute the data transmission process. That is, before step S1201, this data transmission method also includes step S1200A:

[0321] S1200A, DLE#0 sends trigger message #1 to DLE#1; correspondingly, DLE#1 receives trigger message #1 from DLE#0.

[0322] For example, trigger message #1 includes the ID of DL#2 and the ID of the data to be transmitted, enabling DLE#1 to obtain the ID of DL#2 and the ID of the data to be transmitted. In other words, under certain circumstances, DLE#1 can obtain the ID of DL#2 and the ID of the data to be transmitted from DLE#0. Specifically, the ID of the data to be transmitted can be the index of the data to be transmitted, or it can be the ID of DLE#0.

[0323] Specifically, the trigger message #1 is the third message mentioned in step S500A-1 of Figure 10 above. For the specific implementation, please refer to the relevant description in Figure 10 above, which will not be repeated here.

[0324] Scenario 2: The reason for the output of the data to be transmitted is that DL#2 has subscribed to the data of DL#1.

[0325] For example, when DLAF#1, which manages DLEs in DL#1, learns that DL#2 has subscribed to data from DL#1, it can query the DLEs within DL#1 that can communicate with the DLEs in DL#2, thus knowing that DLE#1 can communicate with the DLEs within DL#2 (i.e., DLE#2). Further, DLAF#1 informs DLE#1 of the subscription content of DL#2, so that DLE#1 can trigger the data transmission process when a subscription event occurs. The subscription content carries the ID of DL#1, the ID of DL#2, and the subscription event. DLE#1 can determine the data to be transmitted based on the subscription event. In other words, DLE#1 can learn the ID of DL#2 and the ID of the data to be transmitted based on the subscription content.

[0326] Alternatively, when a subscription event occurs, DLAF#1 sends a trigger message #2 to DLE#1 to trigger DLE#1 to execute the data transmission process. That is, before step S1201, this data transmission method further includes step S1200B:

[0327] S1200B and DLAF#1 send trigger message #2 to DLE#1; correspondingly, DLE#1 receives trigger message #2 from DLAF#1.

[0328] For example, trigger message #2 includes the ID of DL#2 and the ID of the data to be transmitted, enabling DLE#1 to obtain the ID of DL#2 and the ID of the data to be transmitted. That is, under certain circumstances, DLE#1 can obtain the ID of DL#2 and the ID of the data to be transmitted from DLE#0. Specifically, the ID of the data to be transmitted can include the index of the data to be transmitted, or it can be the ID of DLE#0. Furthermore, the ID of the data to be transmitted can include the type of data subscribed to by DL#2.

[0329] For example, the trigger message #2 is the third message described in step S500A-2 of Figure 10 or the fourth message described in step S500B-2 of Figure 11. For specific implementation, please refer to the relevant descriptions in Figures 10 and 11 above, which will not be repeated here.

[0330] S1202, DLE#1 determines whether data output of DL#1 is allowed.

[0331] For example, after DLE#1 learns that DLE#0 has data to be transmitted, it can execute step S1202; that is, DLE#1 triggers step S1202 when it learns that DLE#0 has data to be transmitted. Specifically, DLE#1 itself can determine that DLE#0 has data to be transmitted. Alternatively, DLE#1 can learn that DLE#0 has data to be transmitted based on trigger message #1 or trigger message #2. That is, step S1202 can be executed after step S1200A or step S1200B. In other words, step S1202 can be executed before step S1201, or step S1202 can be executed after step S1201, or step S1202 and step S1201 can be executed simultaneously.

[0332] For example, the implementation of step S1202 is the same as the implementation of "the first node determines whether to allow the first data to be output from the first distributed ledger" described above. For specific implementation, please refer to the relevant description in the above embodiments, which will not be repeated here.

[0333] S1203, DLE#1 sends a migration request message to DLE#2, and DLE#2 receives the migration request message from DLE#1 accordingly.

[0334] The migration request message is used to indicate the ID of DL#1, the ID of DL#2, the data to be transferred / the ID of the data to be transferred, and the signature of DLE#1.

[0335] As an example, DLE#1 can sign the ID of DL#1, the ID of DL#2, and the data to be transferred, and then send the signed message to DLE#2. Furthermore, the migration request message can also include one or more of the output reasons for the data to be transferred; in this case, the signature of DLE#1 refers to the signature of DLE#1 on one or more of the ID of DL#1, the ID of DL#2, the data to be transferred, or the output reason for the data to be transferred.

[0336] Optionally, the data access policy of DL#1 also indicates whether data encryption is required. If the data access policy of DL#1 indicates that data encryption is required, DLE#1 can encrypt the data to be transmitted, sign the encrypted result, and then send it to DLE#2 after signing. In this case, the signature of DLE#1 refers to the signature of DLE#1 on the encrypted result of the data to be transmitted, the ID of DL#1, and the ID of DL#2. Furthermore, the migration request message can also include the output reason of the data to be transmitted; in this case, the signature of DLE#1 refers to the signature of DLE#1 on the encrypted result of the data to be transmitted, the ID of DL#1, the ID of DL#2, and the output reason of the data to be transmitted.

[0337] As another example, the migration request message relates to the amount of data to be transferred, and also includes the ID of DL#1, the ID of DL#2, and the signature of DLE#1.

[0338] Optionally, when the amount of data to be transferred exceeds a preset threshold, the migration request message includes an indication message to declare that DL#1 has data to be migrated to DL#2, or to declare that the data to be transferred will be carried in subsequent messages. When the amount of data to be transferred is less than or equal to the preset threshold, the migration request message includes the data to be transferred. Specifically, the indication message may include the ID of the data to be transferred.

[0339] For example, when the amount of data to be transferred is less than or equal to a preset threshold, the implementation of the migration request message is the same as that in the example above, as detailed in the relevant description above, and will not be repeated here. When the amount of data to be transferred is greater than the preset threshold, DLE#1 can sign the ID of the data to be transferred, the ID of DL#1, and the ID of DL#2, and send the signed message to DLE#2. Furthermore, the migration request message can also include the output reason for the data to be transferred; in this case, the signature of DLE#1 refers to the signature of the ID of the data to be transferred, the ID of DL#1, the ID of DL#2, and the output reason for the data to be transferred by DLE#1.

[0340] Combining the two examples above, optionally, the migration request message also includes the ID of DLE#0, which indicates the source of the data to be transferred, and further, it can also serve as the identifier (or index) of the data to be transferred in DL#2.

[0341] For example, the migration request message is based on the first message described in Figures 5 to 11 above; in addition, the implementation of step S1203 is the same as the implementation of step S502 in Figures 5 to 11 above. For specific implementation, please refer to the relevant descriptions in Figures 5 to 11 above, which will not be repeated here.

[0342] S1204 and DLE#2 determine whether to allow receiving the data to be transmitted based on the migration request message, and verify the signature of DLE#1.

[0343] For example, the implementation of DLE#2 in determining whether to allow receiving the data to be transmitted based on the migration request message is the same as the implementation of step S503 in Figures 4 to 11 above. For details, please refer to the relevant description of step S503, which will not be repeated here.

[0344] Optionally, if the migration request message does not include the data to be transmitted, after DLE#2 confirms that it has received the data to be transmitted, it can send a successful migration request message to DLE#1; thus, DLE#1 can send the data to be transmitted to DLE#2.

[0345] Specifically, the implementation of DLE#1 sending the data to be transmitted to DLE#2 is the same as the implementation of the first node sending the first data to the second node as described in Figures 5 to 11 above. For details, please refer to the relevant descriptions in Figures 5 to 11 above. In addition, the implementation of DLE#2 verifying the signature of DLE#1 can be referred to the implementation of "the second node verifying the signature of the first node" in the above embodiments, and will not be repeated here.

[0346] Optionally, when receiving the data to be transmitted is permitted and the signature verification of DLE#1 passes, DLE#2 may also execute step S1205:

[0347] S1205 and DLE#2 generate data input transactions based on the migration request message and upload them to DL#2. The data input transaction is related to the reason for the output of the data to be transferred.

[0348] Specifically, when the migration request message includes the data to be transferred / ID of the data to be transferred, ID of DL#1, ID of DL#2, and signature of DLE#1, the data input transaction includes the data to be transferred / ID of the data to be transferred, ID of DL#1, ID of DL#2, signature of DLE#1, signature of DLE#2, and timestamp of DLE#0 joining DL#2. Furthermore, when the migration request message also includes the reason for the output of the data to be transferred, the data input transaction also includes one or more of the ID of DL#1, ID of DL#2, ID of DLE#0, or the reason for the output of the data to be transferred.

[0349] For example, taking the runtime log data of a DL with auditing capabilities as the data to be transmitted, DLE#2 can use the data to be transmitted as an input parameter of the smart contract to obtain the trust score of the DL with auditing capabilities, package the trust score to generate and publish the data input transaction. Specifically, the implementation of uploading the data input transaction to DL#2 can be found in the relevant description in Figure 8 above, and will not be repeated here.

[0350] Optionally, after the data input transaction is generated, other DLEs in DL#2 validate the data input transaction. For example, DLE#2 can utilize multiple other DLEs in DL#2 besides DLE#2 to validate the data input transaction. As shown in Figure 13, the data input transaction validation process may include the following steps:

[0351] Step #1: DLE#2 sends data input transactions to DLE#X and DLE#Y, and correspondingly, DLE#X and DLE#Y receive data input transactions from DLE#2.

[0352] Among them, DLE#X and DLE#Y are DLEs within the same consensus group that are not DLE#2 within DL#2.

[0353] For example, the aforementioned data input transaction includes at least: the ID of the data to be transferred / migrated, the ID of DL#1, the ID of DL#2, the signature of DLE#1, the signature of DLE#2, and the timestamp of DLE#0 joining DL#2. Furthermore, the data input transaction may also include the ID of DLE#0, and / or the reason for the output of the data to be transferred.

[0354] Step 2: DLE#X and DLE#Y verify the signature of DLE#2 respectively.

[0355] Step 3: DLE#X and DLE#Y respectively verify the data input transaction.

[0356] For example, DLE#X and DLE#Y each verify the data input transaction after their respective signature verification of DLE#2 passes. Taking DLE#X verifying the signature of DLE#1 as an example, DLE#X can verify both the signature of DLE#1 and the transaction content. The transaction content includes all elements of the data input transaction except for the signatures of DLE#1 and DLE#2. For example, the transaction content might include the data to be transmitted / the ID of the data to be transmitted. Specifically, if DLE#X stores the public key of DLE#1, it can verify the signature of DLE#1 based on the stored public key, obtaining the verification result of the signature of DLE#1. If DLE#X does not store the public key of DLE#1, and the data input transaction also includes the ID of DL#1, DLE#X can determine the DLE in DL#1 based on the ID of DL#1, and then verify the signature of DLE#1 based on the DLE in DL#1, obtaining the verification result of the signature of DLE#1. For example, DLE#X can obtain the public key of DLE#1 from the DLE in DL#1, and then verify the signature of DLE#1 based on the public key of DLE#1 to obtain the verification result of the signature of DLE#1; or, DLE#X can send the signature of DLE#1 and the transaction content to the DLE in DL#1, and receive the verification result of the signature of DLE#1 from that DLE. Optionally, when the reason for the output of the data to be transmitted is that DLE#0 joins DL#2, and the data input transaction also includes the ID of DLE#0, DLE#X also needs to determine the connection status of DLE#0. If DLE#0 is in the state of accessing the network, and the signature verification of DLE#1 is successful, DLE#X finally determines that the signature verification of DLE#1 is successful.

[0357] Similarly, the implementation of DLE#Y to verify the signature of DLE#1 is the same as the implementation of DLE#X to verify the signature of DLE#1. For details, please refer to the relevant description of the implementation of DLE#X to verify the signature of DLE#1, which will not be repeated here.

[0358] Furthermore, DLE#X and DLE#Y can utilize a consensus mechanism to verify transaction content. Therefore, when both the signature and transaction content of DLE#1 are verified successfully, the data input transaction can be considered to have passed verification.

[0359] Step 4: DLE#X and DLE#Y send the verification results of the data input transactions to DLE#2 respectively. Correspondingly, DLE#2 receives the verification results of the data input transactions from DLE#X and DLE#Y.

[0360] For example, after DLE#2 receives the verification results of data input transactions from DLE#X and DLE#Y, it can aggregate these verification results to determine whether the data input transaction has been verified successfully.

[0361] S1206, DLE#2 sends a migration response message to DLE#1, and DLE#1 receives the migration response message from DLE#2 accordingly.

[0362] Specifically, when DLE#2 determines that it is allowed to receive the data to be transmitted and the signature verification of DLE#1 is successful, DLE#2 can store the data to be transmitted in DL#2. Furthermore, the migration response message indicates that the data to be transmitted has been successfully stored in DL#2. When DLE#2 determines that it is not allowed to receive the data to be transmitted, and / or, the signature verification of DLE#1 is unsuccessful, and / or, the data input transaction verification fails, the migration response message indicates that the data to be transmitted has not been stored in DL#2, that is, the cross-ledger transmission has failed.

[0363] Furthermore, when DLE#2 determines that receiving the data to be transmitted is allowed, the signature verification of DLE#1 passes, and the data input transaction verification passes, DLE#2 can store the data to be transmitted in DL#2, and the migration response message indicates that the data to be transmitted has been successfully stored in DL#2; when one or more of the following conditions exist: DLE#2 determines that receiving the data to be transmitted is not allowed, the data input transaction verification fails, or the signature verification of DLE#1 fails, the migration response message indicates that the data to be transmitted has failed to be stored in DL#2.

[0364] Specifically, the migration response message is the second message described in Figures 5 to 11 above; for details on the implementation, please refer to the relevant descriptions in Figures 5 to 11 above, which will not be repeated here.

[0365] Optionally, when the migration response message indicates that the data to be transferred has been successfully stored in DL#2, the migration response message also indicates the verification path of the data input transaction in DL#2. Specifically, the verification path of the data input transaction in DL#2 is based on the second verification path described in Figures 5 to 11 above. For specific implementation details, please refer to the relevant descriptions in Figures 5 to 11 above, which will not be repeated here.

[0366] Optionally, when the migration response message indicates that the data to be transferred has been successfully stored in DL#2, DLE#1 can also execute step S1207:

[0367] S1207 and DLE#1 generate data output transactions based on the data to be transmitted / ID of the data to be transmitted, ID of DL#1, and ID of DL#2, and upload them to DL#1.

[0368] For example, DLE#1 packages the data to be transferred / the ID of the data to be transferred, the ID of DL#1, and the ID of DL#2, signs them, and generates and publishes the data output transaction. Alternatively, the data output transaction can also be generated when the migration request message is determined, that is, the migration request message can contain the data output transaction. In this case, step S1207 can be replaced by DLE#1 uploading the data output transaction to DL#1. Specifically, the implementation of the data output transaction can be found in the relevant description in Figure 8 above, and will not be repeated here.

[0369] Optionally, when DLE#1 triggers the data transmission process based on trigger message #1 or trigger message #2, after step S206, DLE#1 can also send back a response message to the trigger message to indicate whether the data transmission process was successful or failed. For example, when DLE#1 triggers the data transmission process based on trigger message #1, DLE#1 can send a response message to DLE#0; when DLE#1 triggers the data transmission process based on trigger message #2, DLE#1 can send a response message to DLAF#1.

[0370] Referring to Figure 14, which is a flowchart illustrating another data transmission method provided in this application, DLE#1 transmits the data to be transmitted in DL#1 to DL#2 based on the migration trigger information of DLE#2 / DLAF#2; this provides an optional implementation method for transmitting the data to be transmitted from DL#1 to DL#2. As shown in Figure 14, the data transmission method can be implemented through the following steps:

[0371] S1401, DLE#2 / DLAF#2 determines the ID of DL#1, the ID of DL#2, and the ID of the data to be transmitted.

[0372] Optionally, DLE#2 or DLAF#2 can determine the ID of DL#1, the ID of DL#2, and the ID of the data to be transmitted based on the reason for the output of the data to be transmitted. The reason for the output of the data to be transmitted includes whether DLE#0 has joined DL#2 or whether DL#2 has subscribed to the ID of DL#1.

[0373] Alternatively, when the reason for outputting the data to be transmitted includes DLE#0 joining DL#2, DLE#2 or DLAF#2 can determine the ID of DL#1, the ID of DL#2, and the ID of the data to be transmitted based on the join request message of DLE#0. That is, before step S1401, this data transmission method further includes step S1400:

[0374] S1400, DLE#0 sends a join request message to DLE#2 / DLAF#2, and DLE#2 / DLAF#2 receives the join request message from DLE#0 accordingly.

[0375] The join request message is used to request to join DL#2, and it also indicates that DLE#0's own data is stored in DL#1. Therefore, DLE#2 or DLAF#2 can determine the ID of DL#1, the ID of DL#2, and the ID of the data to be transmitted based on the join request message from DLE#0.

[0376] Optionally, step S1401 can be executed when DLE#2 or DLAF#2 learns the reason for the output of the data to be transmitted; further, it can be executed if the reason for the output of the data to be transmitted is that DL#2 has subscribed to data from DL#1, and DL#1 has not fed back the corresponding data to DL#2 according to the subscription agreement. Alternatively, it can be executed when DLE#2 or DLAF#2 receives a join request message.

[0377] S1402, DLE#2 / DLAF#2 determines DLE#1 based on the ID of DL#1.

[0378] For example, DLE#2 or DLAF#2 can query the DLEs in DL#1 that can communicate with the DLE in DL#2 (such as DLE#2) based on the ID of DL#1, thereby knowing that DLE#1 can communicate with the DLE in DL#2 (i.e. DLE#2), thus determining DLE#1.

[0379] S1403, DLE#2 / DLAF#2 sends a migration trigger message to DLE#1; correspondingly, DLE#1 receives the migration trigger message from DLE#2 / DLAF#2. The migration trigger message includes the ID of the data to be migrated and the ID of DL#2.

[0380] For example, when DLE#2 sends a migration trigger message to DLE#1, since DLE#2 and DLE#1 can communicate with each other, DLE#2 can directly send the migration trigger message to DLE#1. When DLAF#2 sends a migration trigger message to DLE#1, DLAF#2 can send the migration trigger message to DLE#2, and then DLE#2 will send the migration trigger message to DLE#1. Furthermore, when DLAF#2 is replaced by DLAF#1, DLAF#1 can directly send the migration trigger message to DLE#1.

[0381] Optionally, the migration trigger message may also include one or more of the following: the ID of DL#1, the reason for outputting the data to be transferred, or the ID of DLE#0. Specifically, the migration trigger message in step S1403 is the third message described in step S500A-2 of Figure 10 or the fourth message described in step S500B-2 of Figure 11. For specific implementation details, please refer to the relevant descriptions in Figures 10 and 11 above, which will not be repeated here.

[0382] S1404, DLE#1 sends a migration request message to DLE#2, and DLE#2 receives the migration request message from DLE#1 accordingly.

[0383] The migration request message in step S1404 is the first message described in Figures 5 to 11 above. For specific implementation details, please refer to the relevant descriptions in Figures 5 to 11 above, which will not be repeated here.

[0384] S1405, DLE#2 determines whether the data to be transferred indicated by the migration request message is the same as the data to be transferred indicated by the migration trigger message, and verifies the signature of DLE#1.

[0385] For example, the migration request message contains data to be transferred / ID of the data to be transferred. When the migration request message contains data to be transferred, DLE#2 can determine whether the data to be transferred is the same as the data to be transferred indicated by the ID of the data to be transferred in the migration trigger message. If yes, it means that the data to be transferred indicated by the migration request message is the same as the data to be transferred indicated by the migration trigger message; if no, it means that the data to be transferred indicated by the migration request message is different from the data to be transferred indicated by the migration trigger message.

[0386] When the migration request message contains the ID of the data to be transferred, DLE#2 can determine whether the ID of the data to be transferred is the same as the ID of the data to be transferred in the migration trigger message. If they are the same, it means that the data to be transferred indicated by the migration request message is the same as the data to be transferred indicated by the migration trigger message; if they are different, it means that the data to be transferred indicated by the migration request message is different from the data to be transferred indicated by the migration trigger message.

[0387] Optionally, when the data to be transferred indicated by the migration request message is the same as the data to be transferred indicated by the migration trigger message, DLE#2 may also execute step S1406:

[0388] S1406 and DLE#2 generate a data input transaction based on the migration request message and upload it to DL#2. Further, the signature of DLE#1 is verified based on the data input transaction. The data input transaction is related to the reason for the output of the data to be transmitted.

[0389] For example, the implementation of DLE#2 generating data input transaction and verifying the signature of DLE#1 is the same as the implementation of steps S503 to S504 in Figures 5 to 11 above. For specific implementation, please refer to the relevant descriptions of steps S503 to S504 in Figures 5 to 11 above, which will not be repeated here.

[0390] S1407, DLE#2 sends a migration response message to DLE#1, and correspondingly, DLE#1 receives a migration response message from DLE#2. Specifically, when DLE#2 determines that receiving the data to be transmitted is permitted and DLE#1's signature verification passes, the migration response message indicates that the data to be transmitted has been successfully stored in DL#2; when DLE#2 determines that receiving the data to be transmitted is permitted, and / or DLE#1's signature verification fails, the migration response message indicates that the data to be transmitted has not been successfully stored in DL#2.

[0391] Specifically, the migration response message in step S1407 is the second message in step S506 of Figures 5 to 11 above. For the specific implementation, please refer to the relevant description of step S506 in Figures 5 to 11 above, which will not be repeated here.

[0392] Optionally, when the migration response message indicates that the data to be transferred has been successfully stored in DL#2, DLE#1 can also execute step S1408:

[0393] S1408 and DLE#1 generate data output transactions based on the data to be transmitted / ID of the data to be transmitted, ID of DL#1, and ID of DL#2, and upload them to DL#1.

[0394] The implementation of step S1408 is the same as that of steps S507 to S508 in Figure 7 above. For details, please refer to the relevant descriptions of steps S507 to S508 in Figure 7 above, which will not be repeated here.

[0395] Referring to Figure 15, which is a flowchart of another data transmission method provided in this application, DLAF#1 performs judgment and other operations, and DLE#1 only needs to transmit the data to be transmitted to DLE#2 to realize the transmission of the data to be transmitted in DL#1 to DL#2; this scheme reduces the workload of DLE#1 and improves the data transmission efficiency. As shown in Figure 15, the data transmission method can be implemented through the following steps:

[0396] S1501 and DLAF#1 determine the ID of DL#2 and the ID of the data to be transmitted.

[0397] For example, DLAF#1 can obtain the ID of DL#2 and the ID of the data to be transmitted based on the following two cases:

[0398] Scenario 1: The reason for the output of the data to be transmitted is that DLE#0 adds DL#2. In this case, it can be understood that DLE#0 itself has a need to add DL#2; therefore, DLE#0 actively triggers DLAF#1 to execute the data transmission process.

[0399] Specifically, DLE#0 can send trigger message #1 to DLAF#1 to trigger DLAF#1 to execute the data transmission process. That is, before step S1501, this data transmission method also includes step S1500A:

[0400] S1500A and DLE#0 send trigger message #1 to DLAF#1; correspondingly, DLAF#1 receives trigger message #1 from DLE#0.

[0401] The implementation of step S1500A is similar to that of step S1200A in Figure 12 above. For details, please refer to the relevant description of step S1200A above, which will not be repeated here.

[0402] Scenario 2: The reason for the output of the data to be transmitted is that DL#2 has subscribed to the data of DL#1.

[0403] For example, DLE#2 / DLAF#2 can send trigger message #2 to DLAF#1 to trigger DLAF#1 to execute the data transmission process. That is, before step S1801, the data transmission method further includes step S1500B:

[0404] S1500B and DLE#2 / DLAF#2 send trigger message #2 to DLAF#1; correspondingly, DLAF#1 receives trigger message #2 from DLE#2 / DLAF#2.

[0405] The implementation of step S1500B is similar to that of step S1200B in Figure 12 above. For details, please refer to the relevant description of step S1200B above, which will not be repeated here.

[0406] In addition, DLAF#2 can directly send trigger message #2 to DLAF#1; furthermore, when DLE#2 sends trigger message #2 to DLAF#1, DLE#2 can send trigger message #2 to DLAF#2, and then DLAF#2 sends trigger message #2 to DLAF#1.

[0407] S1502, DLAF#1 determines whether data output of DL#1 is allowed.

[0408] For example, the implementation of step S1502 is the same as the implementation of "the first node determines whether to allow the first data to be output from the first distributed ledger" described above. For specific implementation, please refer to the relevant description in the above embodiments, which will not be repeated here.

[0409] S1503, DLAF#1 sends message #1 to DLE#1, and DLE#1 receives message #1 from DLAF#1 accordingly. Message #1 indicates the ID of the data to be transmitted.

[0410] Step S1503 is executed when DLAF#1 determines that data output is allowed.

[0411] For example, message #1 is the third message described in step S500A-2 of Figure 10 or the fourth message described in step S500B-2 of Figure 11. For specific implementation, please refer to the relevant descriptions in Figures 10 and 11 above, which will not be repeated here.

[0412] S1504, DLE#1 determines message #2 based on message #1. Message #2 contains the data to be transmitted and the signature of DLE#1.

[0413] For example, DLE#1 can sign the data to be transmitted and the ID of DL#1, and then send the signed data to DLAF#1.

[0414] S1505, DLE#1 sends message #2 to DLAF#1, and DLAF#1 receives message #2 from DLE#1 accordingly.

[0415] S1506, DLAF#1 determines message #3 based on message #2. Message #3 contains the data to be transmitted and the signature of DLAF#1.

[0416] For example, DLAF#1 can verify the signature of DLE#1. When the signature verification of DLE#1 passes, DLAF#1 signs the data to be transmitted, the ID of DL#1, and the ID of DL#2.

[0417] S1507, DLAF#1 sends message #3 to DLE#2 / DLAF#2, and correspondingly, DLE#2 / DLAF#2 receives message #3 from DLAF#1.

[0418] The implementation of message #2 is similar to the implementation of the first message described in Figures 5 to 11 above. For details, please refer to the relevant descriptions in Figures 5 to 11 above, which will not be repeated here.

[0419] S1508, DLE#2 / DLAF#2 verifies the signature of DLAF#1 and stores the data to be transmitted.

[0420] For example, the public key of DLAF#1 can be pre-configured in DLE#2 / DLAF#2, and the signature of DLAF#1 can be verified based on the public key of DLAF#1. Alternatively, the signature of DLAF#1 can be verified based on other DLEs in DL#2 besides DLE#2. Specifically, the implementation of verifying the signature of DLAF#1 based on other DLEs in DL#2 besides DLE#2 is similar to the implementation of the signature verification process of DLE#1 in Figure 13 above, and can be referred to the relevant description in Figure 13 above, which will not be repeated here.

[0421] For example, if the signature verification of DLAF#1 passes, DLE#2 / DLAF#2 stores the data to be transmitted. Specifically, DLE#2 / DLAF#2 can generate a data input transaction based on the data to be transmitted and upload it to DL#2. The implementation of the data input transaction can be found in the relevant description in Figure 6 above, and will not be repeated here.

[0422] S1509, DLE#2 / DLAF#2 sends message #4 to DLE#1, and correspondingly, DLE#1 receives message #4 from DLE#2 / DLAF#2. Specifically, when the signature verification of DLAF#1 passes, message #4 indicates that the data to be transmitted has been successfully stored in DL#2; when the signature verification of message #4 fails, a migration response message indicates that the data to be transmitted has not been successfully stored in DL#2.

[0423] Specifically, message #4 in step S1509 is the second message in step S506 of Figures 5 to 11 above. For the specific implementation, please refer to the relevant description of step S506 in Figures 5 to 11 above, which will not be repeated here.

[0424] Optionally, when message #4 indicates that the data to be transmitted has been successfully stored in DL#2, DLE#1 can also execute step S1510:

[0425] S1510 and DLE#1 generate data output transactions based on the data to be transmitted / ID of the data to be transmitted, ID of DL#1, and ID of DL#2, and upload them to DL#1.

[0426] The implementation of step S1510 is the same as that of steps S507 to S508 in Figure 7 above. For details, please refer to the relevant descriptions of steps S507 to S508 in Figure 7 above, which will not be repeated here.

[0427] Referring to Figure 16, which is a flowchart of another data transmission method provided in this application, DLAF#1 performs judgment and other operations to grant DLE#2 / DLAF#2 the permission to receive the data to be transmitted, so that DLE#1 can directly send the data to be transmitted to DLE#2 according to the permission information to realize the transmission of the data to be transmitted in DL#1 to DL#2; this scheme reduces the workload of DLE#1 and improves the data transmission efficiency.

[0428] As shown in Figure 16, the data transmission method can be implemented through the following steps:

[0429] S1601, DLE#2 / DLAF#2 determines the ID of DL#1, the ID of DL#2, and the ID of the data to be transmitted.

[0430] The implementation of step S1601 is the same as that of step S1401 in Figure 14 above, and can be found in the relevant description in Figure 14 above, which will not be repeated here.

[0431] S1602, DLE#2 / DLAF#2 determines DLAF#1 based on the ID of DL#1.

[0432] S1603, DLAF#2 sends a migration trigger message to DLAF#1; correspondingly, DLAF#1 receives migration trigger messages from DLE#2 / DLAF#2.

[0433] For example, when DLE#2 determines DLAF#1 based on the ID of DL#1 in step S1602, DLE#2 can send the ID of DLAF#1 to DLAF#2, so that DLAF#2 can send a migration trigger message to DLAF#1.

[0434] The migration trigger message in step S1603 is the fourth message described in step S500B-1 of Figure 11 above. For the specific implementation, please refer to the relevant description in Figure 11 above, which will not be repeated here.

[0435] S1604, DLAF#1 determines whether data output of DL#1 is allowed.

[0436] For example, when DLAF#1 determines that data migration from DL#1 is permitted, a token is generated. This token indicates that the data to be transferred from DL#1 is allowed to be migrated to DL#2. Specifically, the token may contain the ID of DL#1, the ID of the data to be transferred, and the ID of DL#2.

[0437] Specifically, the operator to which DLAF#1 belongs can pre-set the judgment rules. For example, the judgment rules can be: allow all migration request messages from DLE#2 / DLAF#2; or, allow all migration request messages from DLAF#3 (where DLAF#3 is used to manage DLE in DL#3); or, allow all migration request messages for data to be transmitted with the output reason of initializing DL.

[0438] Alternatively, the implementation of DLAF#1 determining whether to allow the output of DL#1 data can be the same as the implementation of "the first node determines whether to allow the first data to be output from the first distributed ledger" in the above embodiment. For details, please refer to the relevant description in the above embodiment, which will not be repeated here.

[0439] S1605, DLAF#1 sends message #5 to DLAF#2, and DLAF#2 receives message #5 from DLAF#1. Message #5 indicates the token and the ID of DLE#1.

[0440] For example, DLAF#1 can query the DLE in DL#1 that can communicate with the DLE in DL#2, thereby knowing that DLE#1 can communicate with the DLE in DL#2 (such as DLE#2), and thus determine the ID of DLE#1.

[0441] S1606, DLAF#2 sends a token to DLE#2, and DLE#2 receives the token from DLAF#2 accordingly.

[0442] S1607, DLE#2 sends a token to DLE#1, and DLE#1 receives the token from DLE#2 accordingly.

[0443] For example, the token in step S1607 is the fourth message described in step S500A-1 of Figure 11 above; for specific implementation, please refer to the relevant description in Figure 11 above, which will not be repeated here.

[0444] S1608 verifies the token using DLE#1 and determines message #6. Message #6 contains the data to be transmitted, the ID of DL#2, the ID of DL#1, and the signature of DLE#1.

[0445] For example, DLE#1 can verify the token's signature to determine whether the token issued by DLAF#1 has been tampered with. If it has not been tampered with, it means that the token verification is successful. Furthermore, DLE#1 can determine message #2 based on the token.

[0446] In step S1608, message #6 is the first message described in Figures 5 to 11 above. For specific implementation details, please refer to the relevant descriptions in Figures 5 to 11 above, which will not be repeated here.

[0447] S1609, DLE#1 sends message #6 to DLE#2, and DLE#2 receives message #6 from DLE#1 accordingly.

[0448] The implementation of step S1609 is the same as that of step S502 in Figures 5 to 11 above. For details, please refer to the relevant descriptions in Figures 5 to 11 above, which will not be repeated here.

[0449] S1610, DLE#2 verifies the signature of DLE#1 and stores the data to be transmitted.

[0450] For example, the public key of DLE#1 can be pre-configured in DLE#2, and the signature of DLE#1 can be verified based on the public key of DLE#1. Alternatively, the signature of DLAF#1 can be verified based on other DLEs in DL#2 besides DLE#2. Specifically, the implementation of verifying the signature of DLAF#1 based on other DLEs in DL#2 besides DLE#2 is similar to the implementation of the signature verification process of DLE#1 in Figure 13 above. For details, please refer to the relevant description in Figure 13 above, and it will not be repeated here.

[0451] For example, if the signature verification of DLE#1 passes, DLE#2 / DLAF#2 stores the data to be transmitted. Specifically, DLE#2 can generate a data input transaction based on the data to be transmitted and upload it to DL#2. The implementation of the data input transaction can be found in the relevant description in Figure 6 above, and will not be repeated here.

[0452] S1611, DLE#2 sends message #7 to DLE#1, and correspondingly, DLE#1 receives message #7 from DLE#2. Specifically, when DLE#1's signature verification passes, message #7 indicates that the data to be transmitted has been successfully stored in DL#2; when DLE#1's signature verification fails, message #7 indicates that the data to be transmitted has not been successfully stored in DL#2.

[0453] Specifically, message #7 in step S1910 is the second message in step S506 of Figures 5 to 14 above. For the specific implementation, please refer to the relevant description of step S507 in Figures 5 to 14 above, which will not be repeated here.

[0454] Optionally, when message #7 indicates that the data to be transmitted has been successfully stored in DL#2, DLE#1 can also execute step S1612:

[0455] S1612 and DLE#1 generate a data output transaction based on the data to be transmitted / ID of the data to be transmitted, ID of DL#1, and ID of DL#2, and upload it to DL#1.

[0456] The implementation of step S1612 is the same as that of steps S507 to S508 in Figure 7 above. For details, please refer to the relevant descriptions of steps S507 to S508 in Figure 7 above, which will not be repeated here.

[0457] The various embodiments mentioned above in this application can be combined without contradiction, and no limitation is imposed.

[0458] The above mainly describes the solution provided in this application from the perspective of interaction between various network elements. Correspondingly, this application also provides a communication device, which can be the first node in the above method embodiments, or a device containing the first node, or a component usable in the first node; or, the communication device can be the second node in the above method embodiments, or a device containing the second node, or a component usable in the second node. It is understood that the first node, second node, third node, or fourth node, etc., in order to achieve the above functions, include hardware structures and / or software modules corresponding to the execution of each function. Those skilled in the art should readily recognize that, in conjunction with the unit and algorithm operations of the various examples described in the embodiments disclosed herein, this application can be implemented in hardware or a combination of hardware and computer software. Whether a function is executed by hardware or by computer software driving hardware depends on the specific application and design constraints of the technical solution. Those skilled in the art can use different methods to implement the described functions for each specific application, but such implementation should not be considered beyond the scope of this application.

[0459] This application can divide the first or second node into functional modules based on the above method example. For example, each function can be divided into its own functional module, or two or more functions can be integrated into one processing module. The integrated module can be implemented in hardware or as a software functional module. It is understood that the module division in this application is illustrative and only represents one logical functional division; other division methods may be used in actual implementation.

[0460] For example, when functional modules are integrated, Figure 17 shows a schematic diagram of a communication device 170. The communication device 170 includes a processing module 1701 and an interface module 1702. The processing module 1701, also called a processing unit, is used to perform operations other than transmission and reception; for example, it can be a processing circuit or a processor. The interface module 1702, also called an interface unit, is used to perform transmission and reception operations; for example, it can be an interface circuit, a transceiver, a transceiver unit, or a communication interface.

[0461] In some embodiments, the communication device 170 may further include a storage module (not shown in FIG17) for storing program instructions and data.

[0462] For example, the communication device 170 is used to implement the functions of the first node. The communication device 170 is, for example, the first node described in the embodiment shown in FIG5.

[0463] The processing module 1701 is used to determine the first message. For example, the processing module 1701 can be used to execute S501.

[0464] Interface module 1702 is used to send the first message. For example, interface module 1702 can be used to execute S502.

[0465] When used to implement the function of the second node, other functions that the communication device 170 can implement can be referred to the relevant description of the embodiment shown in FIG5, which will not be elaborated further.

[0466] Alternatively, by way of example, communication device 170 is used to implement the function of a second node. Communication device 170 is, for example, the third node described in the embodiment shown in FIG5.

[0467] Interface module 1702 is used to receive the first message. For example, interface module 1702 can be used to execute S502.

[0468] Processing module 1701 is used to determine whether the second distributed ledger allows the first data input. For example, processing module 1701 can be used to execute S503.

[0469] When determining whether the second distributed ledger allows the first data input, processing module 1701 is also used to determine the generation of a data input transaction. For example, processing module 1701 can be used to execute S504.

[0470] Processing module 1701 is also used to store data input transactions in a second distributed ledger. For example, processing module 1701 can be used to execute S505.

[0471] When used to implement the function of the second node, other functions that the communication device 170 can implement can be referred to the relevant description of the embodiment shown in FIG5, which will not be elaborated further.

[0472] In a simplified embodiment, those skilled in the art will recognize that the communication device 170 can take the form shown in FIG4. For example, the processor 401 in FIG4 can invoke computer execution instructions stored in memory 403 to cause the communication device 170 to perform the methods described in the above method embodiments.

[0473] For example, the functions / implementation processes of the processing module 1701 and interface module 1702 in FIG17 can be implemented by the processor 401 in FIG4 calling computer execution instructions stored in memory 403. Alternatively, the functions / implementation processes of the processing module 1701 in FIG17 can be implemented by the processor 401 in FIG4 calling computer execution instructions stored in memory 403, and the functions / implementation processes of the interface module 1702 in FIG17 can be implemented by the communication interface 404 in FIG4.

[0474] It is understood that one or more of the above modules or units can be implemented by software, hardware, or a combination of both. When any of the above modules or units are implemented by software, the software exists as computer program instructions and is stored in memory. The processor can be used to execute the program instructions and implement the above method flow. The processor can be built into a system-on-a-chip (SoC) or an application-specific integrated circuit (ASIC), or it can be a stand-alone semiconductor chip. In addition to the core that executes software instructions for computation or processing, the processor may further include necessary hardware accelerators, such as field-programmable gate arrays (FPGAs), programmable logic devices (PLDs), or logic circuits that implement dedicated logic operations.

[0475] When the above modules or units are implemented in hardware, the hardware can be any one or any combination of a CPU, microprocessor, digital signal processing (DSP) chip, microcontroller unit (MCU), artificial intelligence processor, ASIC, SoC, FPGA, PLD, application-specific digital circuit, hardware accelerator, or non-integrated discrete device, which can run the necessary software or perform the above method flow independently of software.

[0476] Optionally, this application also provides a chip system, including: at least one processor and an interface, wherein the at least one processor is coupled to a memory via the interface, and when the at least one processor executes a computer program or instructions in the memory, the method in any of the above method embodiments is executed. In one possible implementation, the chip system further includes a memory. Optionally, the chip system may be composed of chips or may include chips and other discrete devices; this application does not specifically limit this.

[0477] Optionally, this application also provides a computer-readable storage medium. All or part of the processes in the above method embodiments can be implemented by a computer program instructing related hardware. This program can be stored in the aforementioned computer-readable storage medium. When executed, the program can include the processes described in the above method embodiments. The computer-readable storage medium can be an internal storage unit of the communication device in any of the foregoing embodiments, such as the hard disk or memory of the communication device. The aforementioned computer-readable storage medium can also be an external storage device of the communication device, such as a plug-in hard disk, smart media card (SMC), secure digital (SD) card, flash card, etc., equipped on the communication device. Further, the aforementioned computer-readable storage medium can include both internal storage units and external storage devices of the communication device. The aforementioned computer-readable storage medium is used to store the aforementioned computer program and other programs and data required by the communication device. The aforementioned computer-readable storage medium can also be used to temporarily store data that has been output or will be output.

[0478] Optionally, this application also provides a computer program product. All or part of the processes in the above method embodiments can be executed by a computer program instructing related hardware. This program can be stored in the above computer program product, and when executed, it can include the processes described in the above method embodiments.

[0479] Optionally, this application also provides computer instructions. All or part of the processes in the above method embodiments can be executed by computer instructions to instruct related hardware (such as a computer, processor, first node, or second node). The program can be stored in the aforementioned computer-readable storage medium or the aforementioned computer program product.

[0480] Optionally, this application also provides a communication system, including: a first node and a second node as described in the above embodiments.

[0481] Optionally, the communication system described above may further include at least one of the third or fourth nodes described in the above embodiments.

[0482] Through the above description of the embodiments, those skilled in the art can clearly understand that, for the sake of convenience and brevity, only the division of the above functional modules is used as an example. In actual applications, the above functions can be assigned to different functional modules as needed, that is, the internal structure of the device can be divided into different functional modules to complete all or part of the functions described above.

[0483] It is understood that the term "connection" in this application can refer to a direct connection or an indirect connection; furthermore, it can refer to an electrical connection or a communication connection. For example, the connection of two electrical components A and B can refer to a direct connection between A and B, or an indirect connection between A and B through other electrical components or connection media, enabling the transmission of electrical signals between A and B; similarly, the connection of two devices A and B can refer to a direct connection between A and B, or an indirect connection between A and B through other communication devices or communication media, enabling communication between A and B.

[0484] It is understood that the message names between various network elements or the names of various parameters in the messages in the above embodiments of this application are just examples, and other names may be used in the specific implementation. This application does not make any specific limitations on this.

[0485] It is understood that in this application, " / " can indicate that the objects before and after it are in an "or" relationship. For example, A / B can mean A or B. "And / or" can be used to describe three relationships between the related objects. For example, A and / or B can mean: A exists alone, A and B exist simultaneously, and B exists alone. Here, A and B can be singular or plural. Furthermore, expressions like "at least one of A, B, and C" or "at least one of A, B, or C" are generally used to indicate any of the following: A exists alone; B exists alone; C exists alone; A and B exist simultaneously; A and C exist simultaneously; B and C exist simultaneously; A, B, and C exist simultaneously. The above examples using three elements (A, B, and C) illustrate the optional entries for this item. When the expression contains more elements, its meaning can be obtained according to the aforementioned rules.

[0486] To facilitate the description of the technical solutions of this application, the terms "first" and "second" may be used to distinguish technical features with the same or similar functions. The terms "first" and "second" do not limit the number or execution order, nor do they imply that they are necessarily different. In this application, the terms "exemplary" or "for example" are used to indicate examples, illustrations, or descriptions. Any embodiment or design scheme described as "exemplary" or "for example" should not be construed as being more preferred or advantageous than other embodiments or design schemes. The use of "exemplary" or "for example" is intended to present the relevant concepts in a concrete manner for ease of understanding.

[0487] It is understood that the term "embodiment" used throughout the specification means that a specific feature, structure, or characteristic related to an embodiment is included in at least one embodiment of this application. Therefore, various embodiments throughout the specification do not necessarily refer to the same embodiment. Furthermore, these specific features, structures, or characteristics can be combined in any suitable manner in one or more embodiments. It is understood that in the various embodiments of this application, the sequence number of each process does not imply a sequential order of execution; the execution order of each process should be determined by its function and internal logic, and should not constitute any limitation on the implementation process of this application.

[0488] It is understood that in this application, "when," "under the circumstances," "if," and "if" all refer to the corresponding processing that will be carried out under certain objective circumstances, and are not time-limited, nor do they require that there must be a judgment action when implemented, nor do they imply any other limitations.

[0489] In this application, "simultaneously" can be understood as at the same point in time, within a period of time, or within the same cycle.

[0490] It is understood that some optional features in this application can be implemented independently in certain scenarios without relying on other features, such as the current solution upon which they are based, to solve the corresponding technical problems and achieve the corresponding effects. Alternatively, they can be combined with other features as needed in certain scenarios. Correspondingly, the apparatus provided in this application can also implement these features or functions, which will not be elaborated here.

[0491] It is understood that the same step or step with the same function or technical feature in this application can be referenced and learned from each other in different embodiments.

[0492] In the several embodiments provided in this application, it should be understood that the disclosed apparatus and methods can be implemented in other ways. For example, the apparatus embodiments described above are merely illustrative; for instance, the division of modules or units is only a logical functional division, and in actual implementation, there may be other division methods. For example, multiple units or components may be combined or integrated into another device, or some features may be ignored or not executed. Furthermore, the mutual coupling or direct coupling or communication connection shown or discussed may be through some interfaces; the indirect coupling or communication connection between devices or units may be electrical, mechanical, or other forms.

[0493] The units described as separate components may or may not be physically separate. A component shown as a unit can be one or more physical units; that is, it can be located in one place or distributed in multiple different locations. Some or all of the units can be selected to achieve the purpose of this embodiment according to actual needs.

[0494] Furthermore, the functional units in the various embodiments of this application can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit. The integrated unit can be implemented in hardware or as a software functional unit.

[0495] The above description is merely a specific embodiment of this application, but the scope of protection of this application is not limited thereto. Any changes or substitutions within the technical scope disclosed in this application should be included within the scope of protection of this application. Therefore, the scope of protection of this application should be determined by the scope of the claims.

Claims

1. A data transmission method, characterized in that, The method is applied to a first node, which is a node in a first distributed ledger, and the method includes: A first message is determined, which is used to indicate information about a first identifier, a second identifier, and first data. The first identifier is the identifier of a first distributed ledger, the second identifier is the identifier of a second distributed ledger, the first distributed ledger and the second distributed ledger belong to different operators, the first data is data in the first distributed ledger, and the information of the first data includes the first data or the identifier of the first data. Send the first message to the second node, where the second node is a node in the second distributed ledger; A second message is received, which indicates whether the first data has been successfully stored in the second distributed ledger.

2. The method according to claim 1, characterized in that, When the second message indicates that the first data has been successfully stored in the second distributed ledger, the method further includes: Sign the information, the first identifier, and the second identifier of the first data to generate a data output transaction; The data output transactions are stored in the first distributed ledger.

3. The method according to claim 2, characterized in that, The second message is also used to indicate a second verification path, which is the verification path of the first data in the second distributed ledger; The step of signing the information of the first data, the first identifier, and the second identifier to generate a data output transaction includes: When it is determined based on the second verification path that the first data has been stored in the second distributed ledger, the information of the first data, the first identifier, and the second identifier are signed to generate the data output transaction.

4. The method according to claim 1, characterized in that, Before determining the first message, the method further includes: Sign the information, the first identifier, and the second identifier of the first data to generate a data output transaction; Based on the data output transaction, a first verification path is determined. The first verification path is the verification path of the first data in the first distributed ledger. The first message is also used to indicate the first verification path.

5. The method according to claim 4, characterized in that, The method further includes: The data output transactions are stored in the first distributed ledger.

6. The method according to any one of claims 2-5, characterized in that, The first distributed ledger includes a first blockchain and a first database. The data output transactions are stored in the first blockchain. The first database includes information about the first data and a first timestamp, where the first timestamp is the timestamp when the node to which the first data belongs joins the first distributed ledger. The method further includes: Delete the information of the first data from the first database; or, The first timestamp is updated to an output indication, which indicates that the first data has been output from the first distributed ledger.

7. The method according to any one of claims 1-6, characterized in that, When the information of the first data includes the identifier of the first data, the method further includes, before receiving the second message: Send the first data to the second node.

8. The method according to any one of claims 1-7, characterized in that, The first message is also used to indicate one or more of the following: the reason for the output of the first data, the identifier of the node to which the first data belongs, and the signature of the first node; The reasons for the output of the first data include the node to which the first data belongs joining the second distributed ledger, or the second distributed ledger subscribing to data in the first distributed ledger.

9. The method according to any one of claims 1-8, characterized in that, The determination of the first message includes: Determine whether to allow the first data to be output from the first distributed ledger; The first message is determined when it is determined that the first data can be output from the first distributed ledger.

10. The method according to claim 9, characterized in that, The data access policy of the first distributed ledger indicates that data output from the first distributed ledger is permitted, meaning that the first data is allowed to be output from the first distributed ledger.

11. The method according to claim 9 or 10, characterized in that, Before determining whether to allow the first data to be output from the first distributed ledger, the method further includes: Receive a third message, the third message being used to indicate the identifier of the first data; The step of determining whether to allow the first data to be output from the first distributed ledger includes: When the first data exists in the first distributed ledger, it is determined that the first data is allowed to be output from the first distributed ledger.

12. The method according to claim 11, characterized in that, The third message also indicates the second identifier, and / or the reason for the output of the first data, including the node to which the first data belongs joining the second distributed ledger, or the second distributed ledger subscribing to data in the first distributed ledger.

13. The method according to any one of claims 9-12, characterized in that, If the time difference between the first timestamp and the current time is less than a first threshold, it means that the first data is allowed to be output from the first distributed ledger; Wherein, the first timestamp is the timestamp when the node to which the first data belongs is added to the first distributed ledger.

14. The method according to claim 13, characterized in that, When the reason for the output of the first data is that the node to which the first data belongs joins the second distributed ledger, the time difference between the first timestamp and the current time is less than the first threshold, indicating that the first data is allowed to be output from the first distributed ledger.

15. The method according to any one of claims 9-14, characterized in that, The presence of the second identifier in the first distributed ledger indicates that the first data is allowed to be output from the first distributed ledger.

16. The method according to any one of claims 1-15, characterized in that, Before determining the first message, the method further includes: Receive a fourth message, the fourth message being used to indicate the identifier of the first data and the second identifier; Determining the first message includes: The first message is determined based on the fourth message.

17. The method according to claim 16, characterized in that, The fourth message is also used to indicate the reason for the output of the first data, which may include the node to which the first data belongs joining the second distributed ledger, or the second distributed ledger subscribing to data in the first distributed ledger.

18. The method according to claim 16 or 17, characterized in that, The fourth message is used to indicate that the second distributed ledger has permission to access the first data.

19. A data transmission method, characterized in that, The method is applied to a second node, which is a node in a second distributed ledger, and the method includes: Receive a first message from a first node, the first message including information for indicating a first identifier, a second identifier and first data, the first node is a node in a first distributed ledger, the first identifier is an identifier of the first distributed ledger, the second identifier is an identifier of a second distributed ledger, the first distributed ledger and the second distributed ledger belong to different operators, the first data is data in the first distributed ledger, and the information of the first data includes the first data or the identifier of the first data. Based on the first identifier, determine whether the second distributed ledger allows the first data input; When it is determined that the second distributed ledger allows the first data input, the first identifier, the second identifier, the information of the first data, and the second timestamp are signed to generate a data input transaction. The second timestamp is the timestamp when the node to which the first data belongs joins the second distributed ledger. The data input transaction is stored in the second distributed ledger; A second message is sent to the first node, the second message indicating whether the first data has been successfully stored in the second distributed ledger.

20. The method according to claim 19, characterized in that, The first message is also used to indicate the signature of the first node; The method further includes: verifying the signature of the first node; When it is determined that the second distributed ledger allows the first data input, the first identifier, the second identifier, the information of the first data, and the second timestamp are signed to generate a data input transaction, including: When it is determined that the second distributed ledger allows the first data input and the signatures of the first nodes are all verified, the first identifier, the second identifier, the information of the first data, the signature of the first node, and the second timestamp are signed to generate a data input transaction.

21. The method according to claim 19 or 20, characterized in that, The second distributed ledger includes a second blockchain and a second database, and the data input transactions are stored in the second blockchain; The method further includes: Store the information from the first data and the second timestamp in the second database; or... The information of the first data is used to update the information of the node to which the first data belongs in the second database.

22. The method according to any one of claims 19-21, characterized in that, The second message is also used to indicate a second verification path, which is the verification path of the first data in the second distributed ledger.

23. The method according to any one of claims 19-22, characterized in that, The first message is also used to indicate the first transmission path, and the first verification path is the verification path of the first data in the first distributed ledger; The method further includes: Verify the first verification path; When it is determined that the second distributed ledger allows the first data input, the first identifier, the second identifier, the information of the first data, and the second timestamp are signed to generate a data input transaction, including: When it is determined that the second distributed ledger allows the first data input and the first data is stored in the first distributed ledger based on the first verification path, the first identifier, the second identifier, the information of the first data, and the second timestamp are signed to generate the data input transaction.

24. The method according to any one of claims 19-23, characterized in that, When the information of the first data includes the identifier of the first data, the method further includes, before sending the second message: Receive the first data sent from the first node.

25. The method according to any one of claims 19-24, characterized in that, The first message is also used to indicate one or more of the following: the reason for the output of the first data, the identifier of the node to which the first data belongs, and the signature of the first node; The reasons for the output of the first data include the node to which the first data belongs joining the second distributed ledger, or the second distributed ledger subscribing to data in the first distributed ledger.

26. The method according to any one of claims 19-25, characterized in that, Before receiving the first message, the method further includes: A fourth message is sent, which indicates the identifier of the first data and the second identifier.

27. The method according to claim 26, characterized in that, The fourth message is also used to indicate the reason for the output of the first data, which may include the node to which the first data belongs joining the second distributed ledger, or the second distributed ledger subscribing to data in the first distributed ledger.

28. The method according to claim 26 or 27, characterized in that, The fourth message is used to indicate that the second distributed ledger has permission to access the first data.

29. A communication device, characterized in that, It includes units or modules for performing the method as described in any one of claims 1 to 18, or includes units or modules for performing the method as described in any one of claims 19 to 28.

30. A communication device, characterized in that, include: A processor coupled to a memory for storing a program or instructions which, when executed by the processor, cause the apparatus to perform the method as claimed in any one of claims 1 to 18, or the method as claimed in any one of claims 19 to 28.

31. A computer-readable storage medium having a computer program or instructions stored thereon, characterized in that, When the computer program or instructions are executed, they cause the computer to perform the method as described in any one of claims 1 to 18, or the method as described in any one of claims 19 to 28.

32. A computer program product, said computer program product comprising computer program code, characterized in that, When the computer program code is run on a computer, it causes the computer to implement the method of any one of claims 1 to 18, or the method of any one of claims 19 to 28.

Images