Data transmission method, device and equipment and readable storage medium

Abstract

The invention discloses a data transmission method and device, equipment and a readable storage medium, and belongs to the technical field of block chains. The method comprises the following steps: in response to capturing that a first node generates an event transmission mark in a process of maintaining a first block chain, acquiring transmission data sent by the first node and related to the event transmission mark, the first block chain comprising a plurality of first block heads, the event transmission mark is used for marking event data to be transmitted to a second block chain deriving the first block chain, and the transmission data comprises the event data; determining a target block head related to the event transmission mark from the plurality of first block heads; the transmission data and the target block head are sent to a second node maintaining the second block chain, and the second node is used for storing the transmission data to the second block chain after verification of the transmission data based on the target block head is passed. According to the invention, only the data related to the event transmission mark is transmitted and stored, so that the occupation of transmission resources and storage resources can be reduced.

Description

Technical Field

[0001] Embodiments of the present application relate to the field of blockchain technology, and particularly to a data transmission method, apparatus, device, and readable storage medium. Background Art

[0002] In the field of blockchain technology, a data structure for recording transaction data is called a block. One block after another is linked in the order of their respective generation times to form a blockchain. There can be multiple blockchains, and different blockchains can communicate through a cross-chain bridge.

[0003] In the related art, when the first blockchain needs to summarize the data in the second blockchain, the second blockchain can be transmitted to the nodes maintaining the first blockchain, so that the nodes can integrate the second blockchain onto the first blockchain. However, the second blockchain includes not only the data to be summarized, resulting in the transmission of a large amount of irrelevant information and increasing the occupation of transmission resources. In addition, the first blockchain after integrating the second blockchain includes a large amount of irrelevant information, increasing the occupation of storage resources. Summary of the Invention

[0004] The present application provides a data transmission method, apparatus, device, and readable storage medium, which can reduce the occupation of transmission resources and storage resources. The technical solutions include the following content.

[0005] In a first aspect, a data transmission method is provided. The method includes:

[0006] In response to capturing an event transmission flag generated by a first node during the process of maintaining a first blockchain, obtaining transmission data sent by the first node related to the event transmission flag. The first blockchain includes a plurality of first block headers, and the event transmission flag is used to mark event data to be transmitted to a second blockchain derived from the first blockchain. The transmission data includes the event data;

[0007] Determining a target block header related to the event transmission flag from the plurality of first block headers;

[0008] Sending the transmission data and the target block header to a second node that maintains the second blockchain. The second node is configured to store the transmission data on the second blockchain after verifying the transmission data based on the target block header.

[0009] In a second aspect, a data transmission method is provided. The method includes:

[0010] Obtain the transmission data related to the event transmission tag and the target block header sent by the relay node when the relay node captures the event transmission tag. The event transmission tag is a tag generated by the first node during the process of maintaining the first blockchain. The event transmission tag is used to mark the event data to be transmitted to the second blockchain derived from the first blockchain. The transmission data includes the event data, and the target block header is determined from multiple first block headers included in the first blockchain;

[0011] Verify the transmission data based on the target block header to obtain a target verification result;

[0012] If the target verification result indicates that the verification is passed, store the transmission data on the second blockchain.

[0013] In a third aspect, a data transmission device is provided. The device includes:

[0014] An acquisition module, configured to, in response to capturing an event transmission tag generated by the first node during the process of maintaining the first blockchain, obtain the transmission data related to the event transmission tag sent by the first node. The first blockchain includes multiple first block headers. The event transmission tag is used to mark the event data to be transmitted to the second blockchain derived from the first blockchain. The transmission data includes the event data;

[0015] A determination module, configured to determine a target block header related to the event transmission tag from the multiple first block headers;

[0016] A sending module, configured to send the transmission data and the target block header to a second node that maintains the second blockchain. The second node is configured to store the transmission data on the second blockchain after verifying the transmission data based on the target block header.

[0017] In a possible implementation manner, the acquisition module is configured to store the event transmission tag in a buffer pool. The buffer pool is used to store the captured tags to be transmitted. If the sum of the number of tags to be transmitted and the event transmission tag is not less than a quantity threshold, send a data acquisition request to the first node. The data acquisition request is used to request to obtain the transmission data; receive the transmission data fed back by the first node.

[0018] In a possible implementation manner, the data acquisition request is further used to request to obtain reference data related to the tag to be transmitted;

[0019] The acquisition module is further configured to receive the reference data fed back by the first node;

[0020] The determining module is further configured to determine a reference block header related to the to-be-transmitted tag from the multiple first block headers;

[0021] The sending module is further configured to send the reference data and the reference block header to the second node, and the second node is configured to store the reference data on the second blockchain after verifying the reference data based on the reference block header.

[0022] In a possible implementation manner, the determining module is configured to verify the multiple first block headers in a trusted execution environment to obtain verification results of each first block header; if the verification results of each first block header all indicate passing the verification, extract the target block header from the multiple first block headers.

[0023] In a possible implementation manner, the first first block header among the multiple first block headers is a genesis block, and the first block header carries an original feature value;

[0024] The determining module is configured to verify the genesis block in a trusted execution environment to obtain the verification result of the genesis block; for any first block header other than the genesis block among the multiple first block headers, obtain the transaction information of the any first block header in the trusted execution environment, calculate the reference feature value of the any first block header based on the transaction information of the any first block header and the original feature value carried by the previous first block header, and determine the verification result of the any first block header based on the reference feature value and the original feature value of the any first block header.

[0025] In a possible implementation manner, the sending module is configured to sign the target block header in the trusted execution environment to obtain signature information; verify the signature information to obtain a first verification result of the signature information; if the first verification result of the signature information indicates passing the verification, send the transmission data and the target block header to the second node.

[0026] In a possible implementation manner, the sending module is further configured to send the signature information to the second node, and the second node is configured to verify the transmission data based on the target block header after verifying the signature information.

[0027] Fourthly, a data transmission device is provided, and the device includes:

[0028] An acquisition module, configured to acquire transmission data related to the event transmission tag and a target block header sent by a relay node when the relay node captures the event transmission tag. The event transmission tag is a tag generated by a first node during the process of maintaining a first blockchain, and is used to mark event data to be transmitted to a second blockchain derived from the first blockchain. The transmission data includes the event data, and the target block header is determined from a plurality of first block headers included in the first blockchain;

[0029] A verification module, configured to verify the transmission data based on the target block header to obtain a target verification result;

[0030] A storage module, configured to store the transmission data on the second blockchain if the target verification result indicates that the verification is passed.

[0031] In a possible implementation manner, the verification module is configured to acquire signature information obtained by the relay node signing the target block header in the trusted execution environment; verify the signature information to obtain a second verification result of the signature information; if the second verification result of the signature information indicates that the verification is passed, verify the transmission data based on the target block header to obtain a target verification result.

[0032] In a possible implementation manner, the transmission data includes transaction data of a plurality of transactions and a Merkle path, and the Merkle path is used to indicate a path for compressing the transaction data of the plurality of transactions into a Merkle root;

[0033] The verification module is configured to compress the transaction data of the plurality of transactions according to the Merkle path to obtain a reference Merkle root; extract a target Merkle root from the target block header; and determine a target verification result based on the reference Merkle root and the target Merkle root.

[0034] In a possible implementation manner, the acquisition module is further configured to acquire reference data and a reference block header sent by the relay node;

[0035] The verification module is further configured to verify the reference data based on the reference block header to obtain a reference verification result;

[0036] The storage module is further configured to store the reference data on the second blockchain if the reference verification result indicates that the verification is passed.

[0037] In a fifth aspect, a data transmission system is provided, characterized in that the data transmission system includes a relay node and a second node. The relay node is configured to execute the data transmission method as described in the first aspect, and the second node is configured to execute the data transmission method as described in the second aspect.

[0038] In a sixth aspect, an electronic device is provided. The electronic device includes a processor and a memory. At least one computer program is stored in the memory and is loaded and executed by the processor to enable the electronic device to implement any one of the above data transmission methods.

[0039] In a seventh aspect, a computer-readable storage medium is further provided. At least one computer program is stored in the computer-readable storage medium and is loaded and executed by a processor to enable an electronic device to implement any one of the above data transmission methods.

[0040] In an eighth aspect, a computer program is further provided. The computer program is at least one, and at least one computer program is loaded and executed by a processor to enable an electronic device to implement any one of the above data transmission methods.

[0041] In a ninth aspect, a computer program product is further provided. At least one computer program is stored in the computer program product and is loaded and executed by a processor to enable an electronic device to implement any one of the above data transmission methods.

[0042] The technical solution provided by this application at least brings the following beneficial effects:

[0043] In the technical solution provided by this application, when an event transmission mark of the first blockchain is captured, transmission data and a target block header related to the event transmission mark are obtained and sent to the second node, realizing the transmission of only the data related to the event transmission mark, avoiding the transmission of irrelevant data, and reducing the occupation of transmission resources. After the second node verifies and passes the transmission data based on the target block header, the transmission data is stored on the second blockchain, which not only ensures the security and reliability of the data, avoids storing data with data loss or tampering, but also can realize the storage of only the data related to the event transmission mark, avoid storing irrelevant data, and reduce the occupation of storage resources. Description of the Drawings

[0044] In order to more clearly illustrate the technical solutions in the embodiments of this application, the following will briefly introduce the drawings required for the description of the embodiments. Obviously, the following drawings are only some embodiments of this application. For those of ordinary skill in the art, without creative efforts, other drawings can be obtained based on these drawings.

[0045] Figure 1 It is a schematic diagram of a blockchain system provided by an embodiment of this application;

[0046] Figure 2It is a schematic diagram of a blockchain provided by an embodiment of the present application;

[0047] Figure 3 It is a schematic diagram of the generation of a block provided by an embodiment of the present application;

[0048] Figure 4 It is a schematic diagram of the implementation environment of a data transmission method provided by an embodiment of the present application;

[0049] Figure 5 It is a schematic diagram of the interaction between a public network and a private network provided by an embodiment of the present application;

[0050] Figure 6 It is a flowchart of a data transmission method provided by an embodiment of the present application;

[0051] Figure 7 It is a flowchart of another data transmission method provided by an embodiment of the present application;

[0052] Figure 8 It is a schematic diagram of the interaction of a data transmission provided by an embodiment of the present application;

[0053] Figure 9 It is a framework diagram of a data transmission provided by an embodiment of the present application;

[0054] Figure 10 It is a network schematic diagram of a tax scenario provided by an embodiment of the present application;

[0055] Figure 11 It is a schematic diagram of the structure of a data transmission device provided by an embodiment of the present application;

[0056] Figure 12 It is a schematic diagram of the structure of another data transmission device provided by an embodiment of the present application;

[0057] Figure 13 It is a schematic diagram of the structure of a terminal device provided by an embodiment of the present application;

[0058] Figure 14 It is a schematic diagram of the structure of a server provided by an embodiment of the present application. Detailed implementation manners

[0059] To make the objectives, technical solutions, and advantages of the present application clearer, the following will further describe the embodiments of the present application in detail with reference to the accompanying drawings.

[0060] In the field of blockchain technology, a blockchain can consist of multiple chains. When the first blockchain needs to aggregate data from the second blockchain, it can transmit the second blockchain to the nodes maintaining the first blockchain, enabling the nodes to integrate the second blockchain onto the first blockchain. However, the second blockchain includes not only the data to be aggregated, resulting in the transmission of a large amount of irrelevant information and increasing the consumption of transmission resources. Additionally, the first blockchain after integrating the second blockchain contains a large amount of irrelevant information, increasing the consumption of storage resources. Based on this, the embodiments of the present application provide a data transmission method that can reduce the amount of data transmitted, thereby reducing the consumption of transmission resources. Moreover, it can avoid the integration of irrelevant data in the blockchain, thus reducing the consumption of storage resources.

[0061] The method of the embodiments of the present application is applicable to the field of blockchain technology. A blockchain is a decentralized database that includes multiple blocks. Each block in the blockchain stores certain information, and these blocks are connected into a chain in the order of their respective generation times to form a blockchain.

[0062] The blockchain underlying platform can include processing modules such as user management, basic services, smart contracts, and operation management. Among them, the user management module is responsible for the identity information management of all blockchain participants, including maintaining public-private key generation (account management), key management, and the maintenance of the correspondence between the user's real identity and the blockchain address (permission management). And under authorization, it manages and audits the transaction situations of certain real identities, providing the rule configuration for risk control (risk control audit); the basic service module is deployed on all blockchain node devices to verify the validity of business requests. After reaching a consensus on valid requests, it records them in storage. For a new business request, the basic service first performs interface adaptation parsing and authentication processing (interface adaptation), then encrypts the business information through a consensus algorithm (consensus management), transmits it intact and consistently to the shared ledger after encryption (network communication), and records and stores it; the smart contract module is responsible for the registration and issuance of contracts, as well as contract triggering and contract execution. Developers can define contract logic through a certain programming language, publish it to the blockchain (contract registration), trigger the execution according to the logic of the contract terms by calling keys or other events, complete the contract logic, and also provide functions for contract upgrade and cancellation; the operation management module is mainly responsible for the deployment, configuration modification, contract setting, cloud adaptation during the product release process, and the visual output of the real-time status during product operation, such as: alarming, managing network conditions, managing the health status of node devices, etc.

[0063] Please refer to Figure 1 , Figure 1It is a schematic diagram of a blockchain system provided by an embodiment of the present application. The blockchain system 100 can be used for data sharing between nodes, and the blockchain system 100 includes multiple nodes 101.

[0064] The node 101 can be any form of device in the network. For example, the node 101 is a server, a terminal device (client), etc. When the node 101 is working properly, it can receive input information and maintain the shared data in the blockchain system 100 based on the received input information. To ensure information interconnection in the blockchain system 100, there can be an information connection between each node 101 in the blockchain system 100, and the nodes 101 can transmit information through the above information connection. For example, when any node 101 in the blockchain system 100 receives input information, other nodes 101 in the blockchain system 100 obtain the input information according to the consensus algorithm and store the input information as data in the shared data, so that the data stored on all nodes 101 in the blockchain system 100 is consistent.

[0065] For each node in the blockchain system 100, there is a corresponding node identifier, and each node 101 in the blockchain system 100 can store the node identifiers of other nodes 101 in the blockchain system 100, so as to broadcast the generated block to other nodes 101 in the blockchain system 100 according to the node identifiers of other nodes 101 later. Each node 101 can maintain a node identifier list and store the node name and the node identifier in the node identifier list correspondingly. Among them, the node identifier can be an Internet Protocol (IP) address for interconnection between networks and any other information that can be used to identify the node. Table 1 below shows a possible node identifier list. In Table 1, the node identifier is an IP address.

[0066] Table 1

[0067] Node Name Node Identifier Node 1 117.114.151.174 Node 2 117.116.189.145 … … Node N 119.123.789.258

[0068] Each node in the blockchain system 100 stores an identical blockchain. The blockchain consists of multiple blocks. Please refer to Figure 2, a blockchain consists of multiple blocks. The genesis block includes a block header and a block body. The block header stores the feature value of the input information, version number, timestamp, and difficulty value. The block body stores the input information (corresponding to the transaction data, event data, Merkle path, etc. mentioned below); the next block of the genesis block takes the genesis block as the parent block. Similarly, the next block includes a block header and a block body. The block header stores the feature value of the input information of the current block, the feature value of the block header of the parent block, version number, timestamp, and difficulty value, and so on. This makes the block data stored in each block in the blockchain associated with the block data stored in the parent block, ensuring the security of the input information in the block.

[0069] As Figure 3 shown, when generating each block in the blockchain, when the node where the blockchain is located receives the input information, it verifies the input information. After the verification is completed, it stores the input information in the memory pool and updates the hash tree used to record the input information; then, it updates the timestamp to the time when the input information is received and tries different random numbers, performing eigenvalue calculations multiple times so that the calculated eigenvalue can satisfy the following formula:

[0070] SHA256(SHA256(version + prev_hash + merkle_root + ntime + nbits + x)) < TARGET

[0071] where SHA256 is the eigenvalue algorithm used to calculate the eigenvalue; version (version number) is the version information of the relevant block protocol in the blockchain; prev_hash is the feature value of the block header of the parent block of the current block; merkle_root is the Merkle root, representing the feature value of the input information; ntime is the update time of the updated timestamp; nbits is the current difficulty, which is a fixed value within a certain period of time and is determined again after exceeding the fixed time period; x is a random number; TARGET is the eigenvalue threshold, and this eigenvalue threshold can be determined according to nbits.

[0072] In this way, when a random number that satisfies the above formula is calculated, the information can be stored correspondingly, generating a block header and a block body to obtain the current block. Subsequently, the node where the blockchain is located sends the newly generated block to other nodes in the data sharing system where it is located according to the node identifiers of other nodes in the data sharing system. Other nodes verify the newly generated block and add the newly generated block to the blockchain they store after the verification is completed.

[0073] Please refer to Figure 4 , Figure 4FIG. 0 is a schematic diagram of an implementation environment of a data transmission method provided by an embodiment of the present application. The implementation environment includes a service node, a local consensus node, a core node, and a core consensus node.

[0074] A service node is an entity that can independently provide a certain service. The entity can be a hardware device or a software module. There is at least one service node. For example, Figure 4 FIG. 5 shows four service nodes, respectively called Service Node 1 to Service Node 4. Any service node can obtain service transaction data related to its own service based on the method of secure data clearing. Among them, data clearing means that after the consensus node receives a request from the service node to synchronize transaction data, it synchronizes the transaction data that the service node has the right to read to the service node. The service transaction data can be uploaded to the blockchain through the local consensus network. In addition, the service node can also obtain the service transaction data on the blockchain from the local consensus network.

[0075] The embodiment of the present application does not limit the service transaction data. Exemplarily, the service transaction data includes resource data such as the type, quantity, and processing method of resources involved in the service, bill data such as the type, quantity, and content of bills for recording resources involved in the service, status data for characterizing the service status, and so on.

[0076] It can be understood that the service transaction data can be uploaded to the local blockchain maintained by the local consensus node, and / or uploaded to the core blockchain maintained by the core consensus node. Similarly, the service node can obtain the service transaction data on the local blockchain, and / or obtain the service transaction data on the core blockchain.

[0077] The local consensus node is used to maintain a blockchain, which can be called a local blockchain, a sub-blockchain, a slave blockchain, and the first blockchain mentioned below, etc. The sub-blockchain is a concept relative to the parent blockchain. Simply understood, the sub-blockchain is constructed on the basis of constructing the parent blockchain. The sub-blockchain is the representative of each industry or vertical field of the blockchain, and is also a general term for various blockchain projects in each subdivided field. When the sub-blockchain is created, the relevant information of the sub-blockchain will be recorded in the parent blockchain. That is to say, the data on the sub-blockchain must rely on the parent blockchain for storage, verification, traceability, etc.

[0078] There is at least one local consensus node, and these local consensus nodes form a local consensus network. For example, Figure 4Five local consensus nodes are shown, respectively called local consensus node 1 to 5, and the local consensus network includes local consensus node 1 to 5. Any business node can submit business transaction data to any local consensus node in the local consensus network. After reaching a consensus through the local consensus network, the local consensus node can generate a block based on the business transaction data and splice the block after the local blockchain to achieve the chain-on of the business transaction data.

[0079] When any business node needs to obtain business transaction data on the local blockchain, it can send a request for obtaining business transaction data to any local consensus node in the local consensus network. After reaching a consensus through the local consensus network, the local consensus node can determine the business transaction data from the local blockchain and send the business transaction data to the business node, thereby realizing the business transaction data on the local blockchain.

[0080] In addition, the local consensus node can communicate with the core consensus node for maintaining the core blockchain. Through the communication between the local consensus node and the core consensus node, it can be realized to aggregate the business transaction data on the local blockchain to the core blockchain.

[0081] Similar to the business node, the core node can be an entity that can independently provide a certain service, and the entity can be a hardware device or a software module. In addition, the core node can communicate with the local consensus node to obtain business transaction data from the local consensus node. There is at least one core node. For example, Figure 4 Two core nodes are shown, respectively called core node 1 and 2. Optionally, the roles, permissions, etc. of the two core nodes are exactly the same, and the effect of service dual active can be achieved, that is, the two core nodes perform business processing simultaneously, and the two core nodes are backups of each other and can perform real-time backup to ensure that in the case of a crash of one core node, the business can still be processed through the other core node.

[0082] Any core node can obtain business transaction data related to its own business, chain on the business transaction data through the core consensus network. In addition, the core node can also obtain the business transaction data on the chain from the core consensus network. In addition, the core node can also be used as the business node corresponding to the local consensus network to maintain the local blockchain.

[0083] Similar to the local consensus node, the core consensus node is used to maintain a blockchain, which can be called the core blockchain, the parent blockchain, the main blockchain, and the second blockchain mentioned below, etc. There is at least one core consensus node, and these core consensus nodes form a core consensus network. For example, Figure 4Four core consensus nodes are shown. Any one of the core nodes can submit business transaction data to the entrance of the core consensus network, where the entrance can be any one of the core consensus nodes. After reaching a consensus through the core consensus network, the core consensus node can generate a block based on the business transaction data and splice the block after the core blockchain to realize the chain - up of the business transaction data.

[0084] When any one of the core nodes needs to obtain the business transaction data on the core blockchain, it can send a request for obtaining the business transaction data to any one of the core consensus nodes in the core consensus network. After reaching a consensus through the core consensus network, the core consensus node can determine the business transaction data from the core blockchain and send the business transaction data to the core node, thereby realizing the acquisition of the business transaction data on the core blockchain.

[0085] In a possible implementation manner, business nodes, core nodes, etc. can be deployed in a public network, and local consensus nodes, core consensus nodes, etc. can be deployed in a private network. The public network and the private network interact through a routing boundary, as Figure 5 shown. Among them, the routing boundary is a technology that simplifies the peripheral functions of a Wide Area Network (WAN) and can manage different nodes through the routing boundary.

[0086] Since the public network can be accessed by designated network terminals and non - designated network terminals, while the private network allows access by designated network terminals, the consensus nodes are in a relatively secure private cloud. The security of mutual access between consensus nodes is guaranteed through a consensus mechanism, and no additional identity management and network control are required. Business nodes need to communicate with consensus nodes through the routing boundary, which realizes strict control over the behavior of business nodes accessing the consensus network.

[0087] In an exemplary embodiment, the business node can be a Special Purpose Vehicle (SPV) light node. Generally, a Bloom Filter is set in the adjacent nodes of the SPV light node, and the Bloom Filter corresponds to a condition. When the adjacent node receives transaction data that meets the condition corresponding to the Bloom Filter, it sends a Merkle Block to the SPV light node. The Merkle Block includes the block header corresponding to the transaction data and the Merkle path connected to the transaction data. The SPV node can use the Merkle path to verify the block header, thereby determining whether the transaction data exists on the blockchain.

[0088] It can be understood that any one of the business nodes, local consensus nodes, core nodes, core consensus nodes, etc. in the embodiments of the present application can be a terminal device or a server. The terminal device can be a smart phone, game console, desktop computer, tablet computer, laptop computer, smart TV, intelligent vehicle-mounted device, intelligent voice interaction device, smart home appliance, etc. The server can be a single server, a server cluster composed of multiple servers, or any one of a cloud computing platform and a virtualization center, and the embodiments of the present application do not limit this. The server can communicate with the terminal device through a wired network or a wireless network. The server can have functions such as data processing, data storage, and data sending and receiving, which are not limited in the embodiments of the present application. The number of terminal devices and servers is not limited and can be one or more.

[0089] Please refer to Figure 6 , Figure 6 FIG. is a flowchart of a data transmission method provided by an embodiment of the present application, and this method can be applied to the above-mentioned implementation environment. In the embodiments of the present application, the above-mentioned local blockchain can be used as the first blockchain, and the above-mentioned core blockchain can be used as the second blockchain. The device that executes the data transmission method in the embodiments of the present application is an electronic device that is communicatively connected to the first blockchain and the second blockchain. For the sake of convenience of description, this electronic device is referred to as a relay node. The relay node is any electronic device that is communicatively connected to the first blockchain and the second blockchain. For example, the relay node can be the above-mentioned core node or other devices. The relay node is a terminal device, a server, or a server cluster, etc. As Figure 6 shown, the method includes the following steps.

[0090] Step 601, in response to capturing that an event transmission mark is generated by a first node during the maintenance of the first blockchain, obtain transmission data related to the event transmission mark sent by the first node. The first blockchain includes a plurality of first block headers, and the event transmission mark is used to mark event data to be transmitted to the second blockchain derived from the first blockchain. The transmission data includes the event data.

[0091] In the embodiments of the present application, the first blockchain is a sub-chain derived from the second blockchain. That is to say, the second blockchain is the main blockchain and the parent blockchain of the first blockchain. Among them, the first blockchain is maintained by at least one first node, and the second blockchain is maintained by at least one second node. Any one first node and any one second node can be the same node or different nodes.

[0092] A sub-blockchain management contract is deployed on any one second node. The sub-blockchain management contract is an automatically executed computer program for deriving a sub-blockchain on the main blockchain and managing the sub-blockchain.

[0093] In an embodiment of the present application, a second node may obtain a derivation request for deriving a sub-blockchain on a second blockchain, where the derivation request carries a block height. In response to the derivation request, the second node runs a sub-blockchain management contract, registers a first blockchain through the sub-blockchain management contract, and derives the first blockchain at the block of the second blockchain corresponding to the block height. Among them, registering the first blockchain means allocating an identity (Identity Document, ID) for the first blockchain. The block height is the number of blocks of the main blockchain. For example, if the derivation request carries a block height of 100, the second node derives the first blockchain at the 100th block of the second blockchain.

[0094] It can be understood that, in addition to carrying the block height, the derivation request may also carry other information. For example, the derivation request also carries the identity of the second blockchain, and the second node determines the second blockchain based on the identity of the second blockchain to derive the first blockchain on the second blockchain. Or, the derivation request may also carry a business type. When the second node registers the first blockchain through the sub-blockchain management contract, it can correlate the identity of the first blockchain with the business type to implement storing data of a single business type in a single sub-blockchain, ensuring the singularity of data storage. For example, deriving a first blockchain corresponding to a bill business on the second blockchain, or deriving a first blockchain corresponding to a tax refund business on the second blockchain, etc. It can be understood that the second blockchain may derive at least one first blockchain, and every two first blockchains may correspond to the same or different business types.

[0095] At least one smart contract is deployed on the first node, and these smart contracts are used to maintain the first blockchain. The embodiments of the present application do not limit the type, content, etc. of the smart contract.

[0096] Exemplarily, a consensus contract is deployed on the first node. The consensus contract is an automatically executed computer program used to process transaction data based on a consensus mechanism. Optionally, a business node may send transaction data to the first node. The transaction data is data reflecting the occurrence of a business. For example, order data, record data, item warehousing data, etc. all belong to transaction data. After receiving the transaction data, the first node may run the consensus contract, generate proposal information for the transaction data through the consensus contract, and send the proposal information to multiple nodes other than the first node that maintain the first blockchain. Any node that receives the proposal information may vote in favor of or against the proposal information and send the voting result to the first node. If the first node receives more than a set number of nodes voting in favor, the first node completes the confirmation of the transaction data and can chain the transaction data. That is, the first node generates a new block of the first blockchain based on the transaction data.

[0097] For another example, an event transmission contract is deployed on the first node. The event transmission contract is an automatically executable computer program used to determine whether transaction data needs to be transmitted to the second blockchain. After the first node completes the confirmation of the transaction data, the event transmission contract runs. If it is determined through the event transmission contract that the transaction data needs to be transmitted to the second blockchain, the event transmission contract generates event data carrying an event transmission tag based on the transaction data. If it is determined through the event transmission contract that the transaction data does not need to be transmitted to the second blockchain, the event transmission contract generates event data without carrying an event transmission tag based on the transaction data.

[0098] Event data is data used to characterize the event that generates the transaction data. For example, issuing a bill is an event. During the process of issuing a bill, steps such as filling in the issuing time of the bill, filling in the content of the bill, and stamping the bill need to be executed, and each step corresponds to a piece of transaction data. Through these transaction data, the event data used to characterize the event of issuing the bill can be determined.

[0099] The event transmission tag is used to mark the event data to be transmitted to the second blockchain. That is to say, if the event data carries an event transmission tag, the event data is the data to be transmitted to the second blockchain. If the event data does not carry an event transmission tag, the event data is the data that does not need to be transmitted to the second blockchain.

[0100] When the first node generates an event transmission tag, the first node can send the event transmission tag to the relay node, or send a notification message for notifying the first node of generating the event transmission tag, so that the relay node can capture the event transmission tag and confirm that there is event data on the first node to be transmitted to the second blockchain. The event transmission tag can carry at least one piece of information. The embodiments of the present application do not limit the information carried by the event transmission tag. For example, the event transmission tag can carry the identifier of the source blockchain and the identifier of the destination blockchain, and the transmission direction of the event data is indicated by the identifier of the source blockchain and the identifier of the destination blockchain. For example, when the identifier of the source blockchain is the identifier of the first blockchain and the identifier of the destination blockchain is the identifier of the second blockchain, it indicates that the event data is transmitted from the first blockchain to the second blockchain.

[0101] After the relay node captures the event transmission tag, it can send a data acquisition request to the first node. The data acquisition request is used to acquire the transmission data related to the event transmission tag. In response to the data acquisition request, the first node sends the transmission data to the relay node. The transmission data includes event data, transaction data, and a Merkle path. It can be understood that the transmission data can also include other information. For example, the transmission data can also include the identifier of the first node.

[0102] In the embodiments of the present application, the event transmission flag may carry a transmission type, which is used to characterize the transmission mode of event data, and the embodiments of the present application do not limit the transmission type. Exemplarily, the transmission type is used to characterize the immediate transmission of event data. In this case, after the relay node captures the event transmission flag, it immediately sends a data acquisition request to the first node and receives the transmission data fed back by the first node based on the data acquisition request.

[0103] For another example, the transmission type is used to characterize that the event data can be transmitted with a delay. In this case, step 601 includes steps 6011 to 6013 (not shown in the figure).

[0104] Step 6011, store the event transmission flag in a buffer pool, where the buffer pool is used to store the captured transmission flags to be transmitted.

[0105] In the embodiments of the present application, the relay node maintains a buffer pool, which is used to store the captured transmission flags to be transmitted. Among them, the generation methods, characterization contents, etc. of the transmission flags to be transmitted and the event transmission flags are similar. That is to say, the transmission flags to be transmitted are used to mark the event data to be transmitted to the second blockchain, which is different from the event data marked by the event transmission flag.

[0106] Before the relay node captures the event transmission flag, the buffer pool may not store the transmission flags to be transmitted, or may store at least one transmission flag to be transmitted. Among them, if the buffer pool stores the transmission flags to be transmitted, the number of the transmission flags to be transmitted is less than the quantity threshold. When the relay node captures the event transmission flag, it can store the event transmission flag in the buffer pool.

[0107] Step 6012, if the sum of the number of the transmission flags to be transmitted and the event transmission flag is not less than the quantity threshold, send a data acquisition request to the first node, where the data acquisition request is used to request to acquire the transmission data.

[0108] If the number of the flags stored in the buffer pool is not less than the quantity threshold, that is, the sum of the number of the transmission flags to be transmitted and the event transmission flag is not less than the quantity threshold, the relay node generates a data acquisition request and sends the data acquisition request to the first node. The data acquisition request is used to request to acquire the transmission data related to the event transmission flag.

[0109] It can be understood that if the sum of the number of the transmission flags to be transmitted and the event transmission flag is less than the quantity threshold, the relay node can continue to capture the transmission flags to be transmitted and store the captured transmission flags to be transmitted in the buffer pool until the sum of the number of the transmission flags to be transmitted and the event transmission flag is not less than the quantity threshold. In this case, the relay node generates a data acquisition request and sends the data acquisition request to the first node.

[0110] Step 6013, receive the transmission data fed back by the first node.

[0111] After the first node receives a data acquisition request, in response to the data acquisition request, it feeds back transmission data to the relay node.

[0112] In a possible implementation, the data acquisition request is further used to request to obtain reference data related to the to-be-transmitted tag. In this case, after step 6012, step 6014 (not shown in the figure) is further included.

[0113] Step 6014: Receive the reference data fed back by the first node; determine a reference block header related to the to-be-transmitted tag from multiple first block headers; send the reference data and the reference block header to the second node, and the second node is used to store the reference data on the second blockchain after verifying the reference data based on the reference block header.

[0114] Among them, the content of the to-be-transmitted tag is similar to the content of the event transmission tag, the content, processing method, etc. of the reference data are similar to the content, processing method, etc. of the transmission data, and the content, processing method, etc. of the reference block header are similar to the content, processing method, etc. of the target block header. Based on this, the implementation manner of step 6014 can refer to the descriptions of step 6013, step 602, step 603, etc., and will not be elaborated here.

[0115] When there are no less than a quantity threshold of tags stored in the buffer pool, batch obtain data related to each tag through a data acquisition request, reduce the sending frequency of the data acquisition request, and reduce the occupation of transmission resources.

[0116] Step 602: Determine a target block header related to the event transmission tag from multiple first block headers.

[0117] In the embodiment of the present application, the first blockchain includes multiple first blocks, and among the multiple first blocks, there are target blocks related to the event transmission tag. Among them, the first first block in the first blockchain is the genesis block, and the genesis block is the earliest constructed block and has a unique identifier. The target block is at least one first block in the first blockchain other than the genesis block.

[0118] The target block includes a target block header and a target block body. The target block body is used to store transaction data in the transmission data. Optionally, the target block body is further used to store other data in the transmission data except for the transaction data. For example, the target block body is further used to store event data and Merkle paths. The target block header includes the block header feature value of the previous first block of the target block, the feature value of the target block header, the difficulty value, and the Merkle root.

[0119] In a possible implementation, step 602 includes steps 6021 to 6022 (not shown in the figure).

[0120] Step 6021: Verify multiple first block headers in the trusted execution environment to obtain the verification results of each first block header.

[0121] A trusted execution environment (TEE) is a secure isolation environment implemented based on hardware and software. Through a combination of software and hardware, a trusted execution environment can be built in the central processing unit, ensuring the confidentiality and integrity of programs, data, etc. loaded in the trusted execution environment. By dividing hardware resources and software resources into two mutually isolated execution environments, one is the trusted execution environment that can ensure the security of programs and data, and the other is the normal execution environment. Among them, the normal execution environment cannot access the storage resources of the trusted execution environment.

[0122] Optionally, when building a central processing unit with a trusted execution environment, key information applicable to the trusted execution environment can be created. This key information includes public key information and private key information. Among them, the private key information cannot be exported, while the public key information can be exported in specific usage scenarios. Some specified programs can run in the trusted execution environment, and the operation of the specified programs is protected by the hardware of the central processing unit. Data can be stored in the trusted execution environment, and the stored data is the data obtained after being encrypted by the private key information applicable to the trusted execution environment. Generally, the private key information can be used to encrypt plaintext data to obtain ciphertext data, and the public key information can be used to decrypt the ciphertext data to obtain plaintext data.

[0123] The specified program needs to be authenticated to obtain an authentication response message, and can only run in the trusted execution environment after the authentication response message is verified. Among them, the authentication response message of the specified program includes key information such as the measurement value of the specified program, publisher information, and information specified by the responder through the request. The measurement value is a unique value of the specified program, calculated from the binary file of the program and the initialization data of the program. Any change to the program will cause the measurement value to change. Passing the verification of the authentication response message is equivalent to the specified program not being tampered with and can run in the trusted execution environment.

[0124] In the embodiment of the present application, the relay node is configured with a TEE verification service. The TEE verification service is an automatically executed computer program that is used to synchronize each first block and the transaction data corresponding to each first block in the first blockchain to the trusted execution environment according to a specific logic, and verify each first block and the corresponding transaction data in the trusted execution environment. Optionally, the TEE verification service also supports a data query service, and can sign the data whenever the data is queried.

[0125] Optionally, when registering the first blockchain through the sub-blockchain management contract, a TEE verification service can be registered for the first blockchain. Only after the second node authenticates that the first blockchain supports the TEE verification service can the relay node synchronize each first block and the corresponding transaction data in the first blockchain to the trusted execution environment and perform verification in the trusted execution environment.

[0126] In an exemplary embodiment, the first first block header among the multiple first block headers is the genesis block, and the first block header carries an original feature value. Step 6021 includes: verifying the genesis block in the trusted execution environment to obtain the verification result of the genesis block; for any first block header other than the genesis block among the multiple first block headers, obtaining the transaction information of any first block header in the trusted execution environment, calculating the reference feature value of any first block header based on the transaction information of any first block header and the original feature value carried by the previous first block header, and determining the verification result of any first block header based on the reference feature value and the original feature value of any first block header.

[0127] In the embodiment of the present application, the first block header includes the feature value of the first block header, and this feature value can be referred to as the original feature value. The relay node can verify whether the original feature value of the genesis block is a fixed value in the trusted execution environment. If the original feature value of the genesis block is a fixed value, the verification result of the genesis block indicates that the verification passes. If the original feature value of the genesis block is not a fixed value, the verification result of the genesis block indicates that the verification fails.

[0128] For any first block other than the genesis block, as mentioned above, the relay node will synchronize each first block and the corresponding transaction data to the trusted execution environment according to a specific logic. Based on this, the relay node can obtain the transaction data corresponding to any first block and the previous first block of this first block, and the previous first block is the parent block mentioned above. The parent block includes the block header feature value, that is to say, the parent block carries the original feature value. The reference feature value of this first block header can be determined based on the transaction data corresponding to any first block and the original feature value carried by the parent block.

[0129] The embodiment of the present application does not limit the calculation method of the reference feature value. Exemplarily, the Merkle root of any first block can be determined according to the transaction data corresponding to any first block, and then, based on the Merkle root of the first block, version information, the original feature value carried by the parent block, etc., for example, according to the feature value calculation formula mentioned above, the reference feature value of the first block header is calculated.

[0130] It can be understood that there are multiple transaction data corresponding to the first block. The relay node can obtain the Merkle path in the trusted execution environment, and the Merkle path is used to indicate the path for compressing multiple transaction data into a Merkle root. Multiple transaction data can be compressed according to the Merkle path to obtain the Merkle root. The compression method can be seen in the following description of the reference Merkle root and will not be elaborated here.

[0131] If the reference eigenvalue of the first block header is the same as the original eigenvalue of the first block header, the relay node determines that the verification result of the first block header is verified; if the reference eigenvalue of the first block header is different from the original eigenvalue of the first block header, the relay node determines that the verification result of the first block header is not verified.

[0132] Step 6022, if the verification results of each first block header all indicate verification, extract the target block header from multiple first block headers.

[0133] In the embodiment of the present application, if the verification results of each first block header in the first blockchain all indicate verification, it means that each first block header is correct data without problems such as errors and tampering, and the verification is performed in the trusted execution environment to ensure data security. On the premise of ensuring the safety and reliability of each first block header, the relay node extracts the target block header from multiple first block headers.

[0134] Optionally, after the first node completes the confirmation of the transaction data, it can first generate event data based on the transaction data, and then generate a new block of the first blockchain based on the transaction data and the event data. That is to say, each event data corresponds to a first block in the first blockchain. If the event data carries an event transmission flag, the first node can send the identifier of the first block corresponding to the event transmission flag to the relay node. The relay node can confirm the first block header corresponding to the identifier of the first block from multiple first block headers and determine the first block header as the target block header.

[0135] Step 603, send the transmission data and the target block header to the second node that maintains the second blockchain, and the second node is used to store the transmission data on the second blockchain after verifying the transmission data based on the target block header.

[0136] In the embodiment of the present application, the second blockchain is maintained by at least one second node. The relay node can send the transmission data and the target block header to any second node so that the second node stores the transmission data on the second blockchain after verifying the transmission data based on the target block header. The verification method and storage method can be seen in the following description of Figure 7 and will not be elaborated here.

[0137] In an exemplary embodiment, step 603 includes: signing the target block header in a trusted execution environment to obtain signature information; verifying the signature information to obtain a first verification result of the signature information; if the first verification result of the signature information indicates that the verification is passed, sending the transmission data and the target block header to a second node.

[0138] In the embodiment of the present application, the relay node can obtain public key information applicable to the trusted execution environment (hereinafter referred to as TEE public key information) and private key information (hereinafter referred to as TEE private key information). As mentioned above, the TEE verification service supports the data query service, and whenever data is queried, the data can be signed. That is to say, after the relay node determines the target block header in the trusted execution environment, it can use the TEE private key information to sign the target block header in the trusted execution environment to obtain signature information.

[0139] The embodiment of the present application does not limit the signature method. Exemplarily, the target block header includes information such as the block header feature value of the parent block, version information, the feature value of the target block header, difficulty value, time stamp, Merkle root, etc. The relay node can use the TEE private key information to sign at least one piece of information in the target block header in the trusted execution environment to obtain signature information.

[0140] Then, the relay node uses the TEE public key information to verify the signature information to obtain a first verification result of the signature information. In an exemplary embodiment, on the one hand, the relay node uses the TEE public key information to decrypt the signature information to obtain a first digest information of the signature information, and on the other hand, the relay node performs a digest operation on the target block header to obtain a second digest information. If the first digest information and the second digest information are the same, it is determined that the first verification result indicates that the verification is passed; if the first digest information and the second digest information are different, it is determined that the first verification result indicates that the verification fails.

[0141] It can be understood that only when the first verification result indicates that the verification is passed, the relay node will send the transmission data and the target block header to the second node.

[0142] Optionally, the method of the embodiment of the present application further includes: sending the signature information to the second node, and the second node is used to verify the signature information and then verify the transmission data based on the target block header. It can be understood that this step can be executed after "signing the target block header in the trusted execution environment to obtain signature information".

[0143] That is to say, the relay node will also send the signature information to the second node so that the second node can verify the signature information. After the verification is passed, the second node will verify the transmission data based on the target block header. This part of the content will be described below and will not be elaborated here.

[0144] It should be noted that the information involved in this application (including but not limited to user device information, user personal information, etc.), data (including but not limited to data for analysis, stored data, displayed data, etc.), and signals are all authorized by the user or fully authorized by all parties, and the collection, use, and processing of relevant data need to comply with relevant laws, regulations, and standards in the relevant regions. For example, the transaction data, transmission data, etc. involved in this application are all obtained under full authorization.

[0145] In the above method, when the first blockchain generates an event transmission tag, the transmission data and the target block header related to the event transmission tag are obtained and sent to the second node, realizing the transmission of only the data related to the event transmission tag, avoiding the transmission of irrelevant data, and reducing the occupation of transmission resources. After the second node verifies and passes the transmission data based on the target block header, the transmission data is stored on the second blockchain, which not only ensures the security and reliability of the data, avoids storing data with data loss or tampering, but also realizes the storage of only the data related to the event transmission tag, avoiding the storage of irrelevant data, and reducing the occupation of storage resources.

[0146] Please refer to Figure 7 , Figure 7 which is a flowchart of another data transmission method provided by an embodiment of this application. This method can be applied to the above implementation environment. The device that executes the data transmission method in the embodiment of this application is the second node. The second node is any electronic device that maintains the second blockchain. For example, the second node can be the core consensus node mentioned above or other devices. The second node is a terminal device, a server, or a server cluster, etc. As Figure 7 shown, this method includes the following steps.

[0147] Step 701: Obtain the transmission data and the target block header related to the event transmission tag sent by the relay node when the event transmission tag is captured. The event transmission tag is a tag generated by the first node during the process of maintaining the first blockchain, and the event transmission tag is used to mark the event data to be transmitted to the second blockchain derived from the first blockchain. The transmission data includes the event data, and the target block header is determined from multiple first block headers included in the first blockchain.

[0148] In the embodiment of this application, the implementation manner of step 701 can be seen in the description of steps 601 to 603. The implementation principles of the two are similar and will not be elaborated here.

[0149] Step 702: Verify the transmission data based on the target block header to obtain a target verification result.

[0150] In the embodiments of the present application, the second node may adopt any verification method to verify the transmitted data based on the target block header to obtain a target verification result. It can be understood that the contents included in the transmitted data and the target block header are different, and the verification methods also vary, which will not be elaborated here.

[0151] The target verification result can indicate whether the transmitted data passes the verification. If the transmitted data passes the verification, it means that the transmitted data is accurate data, the relay node has not tampered with the data, and no data loss has occurred during the transmission process. If the transmitted data fails to pass the verification, it means that there is incorrect data in the transmitted data, the relay node has tampered with the data, and / or data loss has occurred during the transmission process. By verifying the transmitted data, the second node can determine whether it has received secure and reliable data, so as to realize the chain - up of secure and reliable data.

[0152] In implementation manner A, step 702 includes: obtaining the signature information obtained by the relay node signing the target block header in the trusted execution environment; verifying the signature information to obtain a second verification result of the signature information; if the second verification result of the signature information indicates that the verification passes, verifying the transmitted data based on the target block header to obtain a target verification result.

[0153] In the embodiments of the present application, after the relay node signs the target block header in the trusted execution environment to obtain the signature information, it may send the signature information to the second node. Optionally, the relay node may send the TEE public key information and the signature information to the second node simultaneously or successively.

[0154] Next, the second node uses the TEE public key information to verify the signature information to obtain a second verification result of the signature information. In an exemplary embodiment, on the one hand, the second node decrypts the signature information using the TEE public key information to obtain a third digest information of the signature information, and on the other hand, the second node performs a digest operation on the target block header to obtain a fourth digest information. If the third digest information and the fourth digest information are the same, it is determined that the second verification result indicates that the verification passes; if the third digest information and the fourth digest information are different, it is determined that the second verification result indicates that the verification fails.

[0155] It can be understood that only when the second verification result indicates that the verification passes, will the relay node verify the transmitted data based on the target block header, and the verification method can be seen in the description of implementation manner B below.

[0156] In implementation manner B, the transmitted data includes transaction data of multiple transactions and a Merkle path, where the Merkle path is used to indicate the path for compressing the transaction data of multiple transactions into a Merkle root. In this case, step 702 includes: compressing the transaction data of multiple transactions according to the Merkle path to obtain a reference Merkle root; extracting a target Merkle root from the target block header; and determining a target verification result based on the reference Merkle root and the target Merkle root.

[0157] In the embodiments of the present application, the relay node may send transmitted data to the second node, and the transmitted data includes the transaction data corresponding to the target block header. There are multiple pieces of transaction data, the target block header includes a target Merkle root, and the target Merkle root is obtained by compressing multiple pieces of transaction data. The path for compressing multiple pieces of transaction data into a Merkle root is called a Merkle path. In the embodiments of the present application, the transmitted data further includes a Merkle path.

[0158] Taking the compression of four pieces of transaction data into a Merkle root as an example, these four pieces of transaction data may be sequentially recorded as transaction data 1 to 4. Optionally, hash calculations may be performed on transaction data 1 to 4 to obtain the hash values of transaction data 1 to 4. On the one hand, the hash values of transaction data 1 and transaction data 2 are used as the two leaf nodes of the Merkle tree, and hash calculations are performed on these two leaf nodes to obtain the hash values of these two leaf nodes, and the hash values of these two leaf nodes are used as the parent node 1-2 of these two leaf nodes. On the other hand, in the same way, the hash values of transaction data 3 and transaction data 4 are used as the two leaf nodes of the Merkle tree, and hash calculations are performed on these two leaf nodes to obtain the hash values of these two leaf nodes, and the hash values of these two leaf nodes are used as the parent node 3-4 of these two leaf nodes. Then, hash calculations are performed on these two parent nodes to obtain the hash values of these two parent nodes, and the hash values of these two parent nodes are the Merkle root 1-2-3-4 of the Merkle tree. The Merkle path is used to indicate the path for compressing transaction data 1 to 4 into the Merkle root 1-2-3-4 in the above manner.

[0159] For another example, according to the above compression principle, the hash values of transaction data 1 and transaction data 4 may be used as the two leaf nodes of the Merkle tree, and the parent node 1-4 of these two leaf nodes is determined. And the hash values of transaction data 2 and transaction data 3 are used as the two leaf nodes of the Merkle tree, and the parent node 2-3 of these two leaf nodes. Then, the hash values of the two parent nodes are the Merkle root 1-4-2-3 of the Merkle tree. The Merkle path is used to indicate the path for compressing transaction data 1 to 4 into the Merkle root 1-4-2-3 in the above manner.

[0160] In the embodiments of the present application, the relay node may compress multiple transaction data according to the above Merkle root compression principle and the Merkle path to obtain a reference Merkle root. Optionally, the transmitted data further includes event data. The event data and any one of the transaction data may be concatenated, and the concatenated data is hashed to obtain a leaf node of the Merkle tree. Multiple leaf nodes are compressed into a reference Merkle root according to the Merkle path. Alternatively, the event data may be hashed to obtain a leaf node of the Merkle tree, and multiple transaction data are hashed to obtain multiple leaf nodes of the Merkle tree. Multiple leaf nodes are compressed into a reference Merkle root according to the Merkle path.

[0161] In addition, the second node may extract the target Merkle root from the target block header. If the reference Merkle root is the same as the target Merkle root, the second node determines that the target verification result is verification passed; if the reference Merkle root is different from the target Merkle root, the second node determines that the target verification result is verification failed.

[0162] Step 703, if the target verification result indicates verification passed, store the transmitted data on the second blockchain.

[0163] In the embodiments of the present application, if the second node determines that the target verification result indicates verification passed, the second node may use the transmitted data as the data stored in the target block body corresponding to the target block header, and based on the target block header and the target block body, assemble a new block of the second blockchain, thereby realizing storing the transmitted data on the second blockchain.

[0164] Optionally, the block header of any block in the blockchain except the first block includes the block header feature value of the parent block. The parent block of the target block located in the first blockchain is the previous block of the target block in the first blockchain, and the parent block of the target block located in the second blockchain is the previous block of the target block in the second blockchain. That is, the same block corresponds to different parent blocks when located in different blockchains. Based on this, the target block header sent by the relay node to the second node may or may not include the block header feature value of the parent block. When assembling a new block of the second blockchain based on the target block header and the target block body, the block header feature value of the previous block of the target block in the second blockchain may be added or replaced in the target block header.

[0165] Optionally, the second node may summarize the transmitted data to obtain summary data. The embodiments of the present application do not limit the method of summarizing the transmitted data. For example, according to summary dimensions such as users or enterprises, the transmitted data belonging to the same summary dimension may be summarized to obtain the summary data corresponding to the summary maintenance.

[0166] The aggregated data can be multiple. On the one hand, the multiple aggregated data are used as the data stored in the block body. On the other hand, a block header is generated based on the multiple aggregated data, and the generation method of the block header will not be elaborated here. The block header and the block body are assembled to obtain a new block of the second blockchain, thereby realizing the storage of the transmitted data on the second blockchain.

[0167] In an exemplary embodiment, the method of the embodiment of the present application further includes step 704 (not shown in the figure). It can be understood that step 704 can be executed before or after any one of steps 701 to 703.

[0168] Step 704: Obtain the reference data and the reference block header sent by the relay node; verify the reference data based on the reference block header to obtain a reference verification result; if the reference verification result indicates that the verification is passed, store the reference data on the second blockchain.

[0169] It can be understood that the content, processing method, etc. of the reference data are similar to those of the transmitted data, and the content, processing method, etc. of the reference block header are similar to those of the target block header. Based on this, the implementation manner of step 704 can be seen in the description of steps 701 to 703, and the implementation principles of the two are similar and will not be elaborated here.

[0170] It should be noted that the information (including but not limited to user device information, user personal information, etc.), data (including but not limited to data for analysis, stored data, displayed data, etc.) and signals involved in the present application are all authorized by the user or fully authorized by all parties, and the collection, use and processing of relevant data need to comply with the relevant laws, regulations and standards of the relevant regions. For example, the transaction data, transmitted data, etc. involved in the present application are all obtained under full authorization.

[0171] In the above method, when an event transmission mark is generated on the first blockchain, the transmitted data and the target block header related to the event transmission mark are obtained and sent to the second node, realizing the transmission of only the data related to the event transmission mark, avoiding the transmission of irrelevant data, and reducing the occupation of transmission resources. After the second node verifies the transmitted data based on the target block header and passes the verification, the transmitted data is stored on the second blockchain, which not only ensures the security and reliability of the data, avoids storing data with data loss or tampering, but also can realize the storage of only the data related to the event transmission mark, avoiding the storage of irrelevant data, and reducing the occupation of storage resources.

[0172] The data transmission method of the embodiment of the present application is described above from the perspective of method steps. Now, a systematic and comprehensive description will be given. Please refer to Figure 8 , Figure 8It is an interaction schematic diagram of data transmission provided by an embodiment of the present application. The data transmission process of the embodiment of the present application involves a first node, a relay node, and a second node, and includes steps 1 to 10 as shown below.

[0173] Step 1, the first node generates event data based on transaction data, and generates a target block in the first blockchain based on the event data and the transaction data. The target block includes a target block header and a target block body. The event data may carry an event transmission flag or may not carry a data transmission flag. The implementation manner of step 1 can be seen in the description of step 601, and will not be elaborated here.

[0174] Step 2, if the event data carries an event transmission flag, the first node sends a data packet to the relay node. The data packet corresponds to the transmission data mentioned above. The implementation manner of step 2 can be seen in the description of step 601, and will not be elaborated here.

[0175] Step 3, the relay node sends the data packet to the second node.

[0176] Step 4, the relay node synchronizes each first block header in the first blockchain to the executable environment, and verifies each first block header in the executable environment. The implementation manner of step 4 can be seen in the description of step 6021, and will not be elaborated here.

[0177] Step 5, after each first block header is verified, the relay node signs the target block header in the executable environment to obtain signature information. The implementation manner of step 5 can be seen in the description of step 603, and will not be elaborated here.

[0178] Step 6, the relay node obtains the target block header and verifies the signature information. The implementation manner of step 6 can be seen in the description of step 603, and will not be elaborated here.

[0179] Step 7, after the signature information is verified, the relay node sends the target block header and the signature information to the second node.

[0180] Step 8, the second node verifies the signature information. The implementation manner of step 8 can be seen in the description of Implementation A, and will not be elaborated here.

[0181] Step 9, after the signature information is verified, the second node verifies the data packet based on the target block header. The implementation manner of step 9 can be seen in the description of Implementation B, and will not be elaborated here.

[0182] Step 10, after the data packet is verified, the second node generates a new block on the second blockchain based on the data packet. The implementation manner of step 10 can be seen in the description of step 703, and will not be elaborated here.

[0183] The embodiment of the present application also provides a method for implementingFigure 8 The data transmission framework of the method shown, such as Figure 9 shown. Among them, the first blockchain is a sub-blockchain, and the second blockchain is the main blockchain.

[0184] The first node is used for the dimension sub-blockchain. The sub-blockchain corresponds to local consensus business contracts and main blockchain status confirmation contracts that communicate with each other. The local consensus business contract is a computer program whose business logic corresponds to the data aggregation contract, and is used to reach a consensus on transaction data and generate target blocks in the sub-blockchain based on the transaction data. The main blockchain status confirmation contract is a computer program used to obtain the confirmation status of the main blockchain.

[0185] The relay node deploys services such as event data packet forwarding relay, sub-blockchain TEE verification, and event block header forwarding relay. The event data packet forwarding relay service is a computer program that, after capturing an event transmission tag, obtains a data packet related to the event transmission tag from the local consensus business contract corresponding to the sub-blockchain and forwards it to the event data packet verification contract corresponding to the main blockchain. The sub-blockchain TEE verification service is a computer program that synchronizes each first block header in the first blockchain from the local consensus business contract corresponding to the sub-blockchain to an executable environment, verifies each first block header in the executable environment, and signs the target block header in the executable environment to obtain signature information. The event block header forwarding relay service is a computer program that obtains the target block header and signature information of the target block from the sub-blockchain TEE verification service and sends the target block header and signature information to the event block header verification contract corresponding to the main blockchain. Among them, according to the resource requirements of the main blockchain, the sub-blockchain TEE verification service can sign a batch of block headers to obtain signature information, and the event block header forwarding relay service can transmit the block headers and signature information in batches.

[0186] Optionally, when there are multiple sub-blockchains, one or several sub-blockchains can correspond to one event data packet forwarding relay service. The event data packet forwarding relay service is used to obtain event transmission tags, data packets, etc. of the corresponding sub-blockchain.

[0187] The second node is used for the dimension main blockchain. The main blockchain corresponds to an event data packet verification contract, an event block header verification contract, and a data aggregation contract. The event block header verification contract is a computer program that receives the target block header and signature information, verifies the signature information, and stores the target block header after passing the verification. The event data packet verification contract is a computer program that verifies the data packet based on the target block header. The data aggregation contract is a computer program related to the event data packet verification contract, and is used to receive the verified data packets and generate new blocks in the main blockchain based on the data packets.

[0188] Among them, the event block header verification contract can be registered in the sub-blockchain management contract. The event block header verification contract obtains the TEE public key information by calling back the sub-blockchain management contract, and verifies the signature information based on the TEE public key information to determine whether the target block header is secure and reliable. Since the security and reliability of the target block header are guaranteed through the TEE service, the event block header verification contract can receive discontinuous target block headers.

[0189] It can be understood that there is at least one main blockchain, and each main blockchain can derive at least one sub-blockchain. Different main blockchains can correspond to different event types. At least one data aggregation contract can be deployed on the second node. Different data aggregation contracts correspond to different event types. The correspondence between the event type and the data aggregation contract can be bound and stored through the event data packet verification contract. The event data packet verification contract can determine the event type based on the event data in the data packet, and determine the data aggregation contract corresponding to the event type based on the correspondence. The new block of the main blockchain corresponding to the event type is generated based on the data packet through the data aggregation contract corresponding to the event type.

[0190] For example, the event type of "bill" can be configured to correspond to the "bill" data aggregation contract, and the event type of "resource" can be configured to correspond to the "resource" data aggregation contract. When the event data packet verification contract determines that the event type in the data packet is "resource" based on the event data, the data packet is sent to the "resource" data aggregation contract. The new block of the main blockchain corresponding to "resource" is generated based on the data packet through the "resource" data aggregation contract.

[0191] The main blockchain also corresponds to the sub-blockchain management contract. The sub-blockchain management contract is a computer program used to derive sub-blockchains from the main blockchain and manage sub-blockchains. In addition, through services such as event data packet forwarding relay, sub-blockchain TEE verification, event block header forwarding relay, and contracts such as event data packet verification contract and event block header verification contract, the data of the sub-blockchain can be transmitted to the main blockchain. These services and contracts need to be registered in the sub-blockchain management contract. That is to say, all services and contracts related to the data transmission of the sub-blockchain need to be registered in the sub-blockchain management contract.

[0192] The main blockchain also corresponds to the TEE authentication module. The TEE authentication module is a computer program used to authenticate the sub-blockchain TEE verification service. It can be understood that the sub-blockchain TEE verification service may need to be changed, and each change requires authentication by the TEE authentication module.

[0193] In addition, when generating a new block of the main blockchain based on a data packet, a confirmation status of the main blockchain can be generated, which is used to confirm that the data packet has been uploaded to the main blockchain. The confirmation status of the main blockchain can be transmitted through the data channel between the main blockchain and the sub-blockchain, and the confirmation status of the main blockchain can be written into the main blockchain status confirmation contract.

[0194] The data transmission method provided by the embodiments of this application can be applicable to any scenario related to the blockchain. For example, it is applicable to the tax scenario. Please refer to Figure 10 , Figure 10 which is a network schematic diagram of a tax scenario provided by the embodiments of this application. Generally, the tax scenario is often accompanied by the circulation of electronic invoices. An electronic invoice platform can be built to realize the circulation of electronic invoices through the electronic invoice platform.

[0195] The electronic invoice platform includes a business layer, a routing proxy layer, and a core consensus network layer. The network corresponding to the business layer is the business network, and the business network includes multiple business nodes. The network corresponding to the core consensus network layer is the core consensus network, and the core consensus network includes multiple consensus nodes. The network corresponding to the routing proxy layer is the routing network used to isolate the business network and the consensus network. Among them, the routing proxy layer and the core consensus network layer are used to form Figure 10 the tax private network shown.

[0196] Among them, the business nodes in the business layer can include the tax bureau terminals corresponding to the e-tax bureaus, the enterprise terminals corresponding to the enterprise users, and the consumer terminals corresponding to the consumer users. The e-tax bureau can refer to the local tax bureau in the tax bureau private network. The enterprise users can be the invoicing service providers corresponding to the invoicing terminals in the public cloud, the reimbursement service providers corresponding to the reimbursement terminals, or the retail enterprises corresponding to the dedicated terminals, etc. The consumer users can be the payment service providers corresponding to the payment servers in the private cloud, the circulation service providers corresponding to the circulation servers, or the retail enterprises corresponding to the dedicated terminals, etc. Among them, the circulation server can be used to temporarily save a certain electronic invoice to be circulated for the consumer user.

[0197] Any one of the routing nodes in the routing proxy layer can be used to isolate the service layer and the core consensus network layer. Among them, each routing node can have Peer To Peer services, routing services, certificate caching, and authentication services. It can be understood that the Peer To Peer service refers to the service in the Peer To Peer network. Based on a specific network protocol, in the Peer To Peer network, there is no need for a central node to maintain the network state among network nodes. Instead, each node maintains the node state of the entire network or the connection state of its adjacent nodes through broadcast interaction with adjacent nodes. The routing service is a basic function of the node and can be used for communication between nodes. The certificate associated with the certificate caching can refer to the Public Key Infrastructure (PKI). In the certificate system, the certificate is an identity proof of the public key owner and is issued by an authoritative institution (Certificate Authority, CA). The authentication service can be used to verify the data format of the received data, the legitimacy of the node, etc. It can be understood that in the embodiments of the present application, the routing node can forward the transaction data submitted by a certain service node in the service layer to the consensus node.

[0198] The blockchain electronic bill platform includes multiple blockchains. Specifically, the multiple blockchains can include Figure 10 the core chain 1, core chain 2, …, and core chain N shown in the figure. Each core chain can be a blockchain maintained by tax bureaus in different regions. The cross-chain transfer of resources between any two core chains is realized through the relay blockchain. Each core chain is maintained by multiple consensus nodes, and a permission contract is deployed on any one of the consensus nodes. Here, the permission contract stores the transfer logic of the entire life cycle of the electronic bill, such as the bill status of the electronic bill, the transfer process, the access permission of the data, the application conditions of the electronic bill, the issuance conditions of the electronic bill, and so on. The consensus node can not only be used as a cache for providing data caching services (which can also be called caching), but also be used to store the blocks obtained by the block packaging service. These functions can support the verification of the correctness of the cross-chain information associated with the cross-chain task.

[0199] It can be understood that the second blockchain involved in the embodiments of the present application can be any one of the above core chains 1 to N. The first blockchain can be derived in the second blockchain, so that the first blockchain is a sub-chain of the second blockchain. Among them, the first blockchain can be any one of the above core chains 1 to N except the second blockchain. For example, the first blockchain is core chain N, and the second blockchain is core chain 1.

[0200] The data transmission method in the embodiments of the present application has at least the following advantages.

[0201] Advantage 1. The data transmission method of the embodiment of the present application is implemented based on a multi-layer blockchain framework and can be applied to large-scale services such as electronic bills. The form of the multi-layer blockchain facilitates hierarchical business governance, ensuring the relatively independent operation of each layer of business without having to converge all the traffic of the entire business to the main blockchain. On the premise of realizing data isolation, business isolation, legality and compliance, etc., it is ensured that the main blockchain does not need to carry a large number of detailed services, enabling the main blockchain to focus on key task management and global governance.

[0202] Advantage 2. By providing the main blockchain with the native ability of TEE authentication, a sub-blockchain TEE verification service can be set up for each sub-blockchain. Through the sub-blockchain TEE verification service, the main blockchain only needs to store the block headers that are related to the event transmission mark and are signed and guaranteed by the sub-blockchain TEE verification service. On the basis of ensuring the correctness and credibility of the block headers, the transmission and storage of other irrelevant block headers are avoided, reducing the occupation of transmission resources and storage resources.

[0203] Advantage 3. Through the event transmission mark and capture technology, the sub-blockchain can selectively transmit transaction data, avoiding the transmission of a large amount of irrelevant transaction data back to the main blockchain, thereby reducing the storage cost.

[0204] Advantage 4. By signing the block header in the trusted execution environment, relay forgery and tampering of the block header can be avoided. By verifying the transaction data through the block header, relay forgery and tampering of the transaction data can be avoided.

[0205] Based on the foregoing, the embodiment of the present application further provides a data transmission system, which includes a relay node and a second node. The relay node is used to execute the data transmission method as Figure 6 shown, and the second node is used to execute the data transmission method as Figure 7 shown. Since the implementation process of the data transmission method has been described above, it will not be elaborated here.

[0206] Figure 11 The following shows a schematic structural diagram of a data transmission device provided by the embodiment of the present application. As Figure 11 shown, the device includes:

[0207] An acquisition module 1101, configured to obtain, in response to capturing that the first node generates an event transmission mark during the process of maintaining the first blockchain, the transmission data sent by the first node and related to the event transmission mark. The first blockchain includes a plurality of first block headers, and the event transmission mark is used to mark the event data to be transmitted to the second blockchain derived from the first blockchain. The transmission data includes event data;

[0208] A determination module 1102, configured to determine a target block header related to an event transmission tag from a plurality of first block headers;

[0209] A sending module 1103, configured to send transmission data and the target block header to a second node that maintains a second blockchain. The second node is configured to store the transmission data on the second blockchain after verifying the transmission data based on the target block header.

[0210] In a possible implementation, an acquisition module 1101 is configured to store the event transmission tag in a buffer pool. The buffer pool is configured to store captured tags to be transmitted. If the sum of the number of tags to be transmitted and the event transmission tag is not less than a quantity threshold, a data acquisition request is sent to a first node. The data acquisition request is used to request to obtain transmission data, and the transmission data fed back by the first node is received.

[0211] In a possible implementation, the data acquisition request is further configured to request to obtain reference data related to the tags to be transmitted;

[0212] The acquisition module 1101 is further configured to receive the reference data fed back by the first node;

[0213] The determination module 1102 is further configured to determine a reference block header related to the tags to be transmitted from a plurality of first block headers;

[0214] The sending module 1103 is further configured to send the reference data and the reference block header to the second node. The second node is configured to store the reference data on the second blockchain after verifying the reference data based on the reference block header.

[0215] In a possible implementation, the determination module 1102 is configured to verify a plurality of first block headers in a trusted execution environment to obtain verification results of each first block header. If the verification results of each first block header all indicate passing the verification, the target block header is extracted from the plurality of first block headers.

[0216] In a possible implementation, the first first block header among the plurality of first block headers is a genesis block, and the first block header carries an original feature value;

[0217] The determination module 1102 is configured to verify the genesis block in a trusted execution environment to obtain the verification result of the genesis block. For any first block header other than the genesis block among the plurality of first block headers, the transaction information of any first block header is obtained in the trusted execution environment. Based on the transaction information of any first block header and the original feature value carried by the previous first block header, the reference feature value of any first block header is calculated. Based on the reference feature value and the original feature value of any first block header, the verification result of any first block header is determined.

[0218] In a possible implementation, the sending module 1103 is configured to sign the target block header in the trusted execution environment to obtain signature information; verify the signature information to obtain a first verification result of the signature information; if the first verification result of the signature information indicates verification success, send the transmission data and the target block header to the second node.

[0219] In a possible implementation, the sending module 1103 is further configured to send the signature information to the second node, and the second node is configured to verify the signature information and then verify the transmission data based on the target block header.

[0220] In the above device, when an event transmission flag of the first blockchain is captured, the transmission data and the target block header related to the event transmission flag are obtained and sent to the second node, realizing the transmission of only the data related to the event transmission flag, avoiding the transmission of irrelevant data, and reducing the occupation of transmission resources. After the second node verifies the transmission data based on the target block header and passes the verification, the transmission data is stored on the second blockchain, which not only ensures the security and reliability of the data, avoids storing data with data loss or tampering, but also realizes the storage of only the data related to the event transmission flag, avoids storing irrelevant data, and reduces the occupation of storage resources.

[0221] It should be understood that when the above Figure 11 provided device realizes its functions, only the above division of each functional module is used for illustration. In practical applications, the above functions can be allocated to different functional modules according to needs, that is, the internal structure of the device is divided into different functional modules to complete all or part of the functions described above. In addition, the device provided in the above embodiment and the method embodiment belong to the same concept, and the specific implementation process can be seen in the method embodiment, which will not be elaborated here.

[0222] Figure 12 The following shows a schematic structural diagram of a data transmission device provided by an embodiment of the present application. As Figure 12 shown, the device includes:

[0223] An obtaining module 1201, configured to obtain the transmission data and the target block header related to the event transmission flag sent by the relay node when the event transmission flag is captured. The event transmission flag is a flag generated by the first node during the maintenance of the first blockchain, and the event transmission flag is used to mark the event data to be transmitted to the second blockchain derived from the first blockchain. The transmission data includes the event data, and the target block header is determined from multiple first block headers included in the first blockchain;

[0224] A verification module 1202, configured to verify the transmission data based on the target block header to obtain a target verification result;

[0225] The storage module 1203 is configured to store the transmission data on the second blockchain if the target verification result indicates successful verification.

[0226] In a possible implementation, the verification module 1202 is configured to obtain the signature information obtained by the relay node signing the target block header in the trusted execution environment; verify the signature information to obtain a second verification result of the signature information; if the second verification result of the signature information indicates successful verification, verify the transmission data based on the target block header to obtain a target verification result.

[0227] In a possible implementation, the transmission data includes the transaction data of multiple transactions and a Merkle path, and the Merkle path is used to indicate the path for compressing the multiple transaction data into a Merkle root;

[0228] The verification module 1202 is configured to compress the multiple transaction data according to the Merkle path to obtain a reference Merkle root; extract the target Merkle root from the target block header; and determine the target verification result based on the reference Merkle root and the target Merkle root.

[0229] In a possible implementation, the acquisition module 1201 is further configured to obtain the reference data and the reference block header sent by the relay node;

[0230] The verification module 1202 is further configured to verify the reference data based on the reference block header to obtain a reference verification result;

[0231] The storage module 1203 is further configured to store the reference data on the second blockchain if the reference verification result indicates successful verification.

[0232] In the above device, when an event transmission flag is generated on the first blockchain, the transmission data and the target block header related to the event transmission flag are obtained and sent to the second node, realizing the transmission of only the data related to the event transmission flag, avoiding the transmission of irrelevant data, and reducing the occupation of transmission resources. After the second node verifies the transmission data based on the target block header and passes the verification, the transmission data is stored on the second blockchain, which not only ensures the security and reliability of the data, avoids storing data with data loss or tampering, but also realizes the storage of only the data related to the event transmission flag, avoids storing irrelevant data, and reduces the occupation of storage resources.

[0233] It should be understood that the above Figure 12When the provided device implements its functions, only the division of the above-mentioned functional modules is used for illustration. In actual applications, the above functions can be allocated to different functional modules according to needs, that is, the internal structure of the device is divided into different functional modules to complete all or part of the functions described above. In addition, the device provided in the above embodiment and the method embodiment belong to the same concept. For the specific implementation process, please refer to the method embodiment and will not be elaborated here.

[0234] Figure 13 FIG. shows a structural block diagram of a terminal device 1300 provided by an exemplary embodiment of the present application. The terminal device 1300 includes: a processor 1301 and a memory 1302.

[0235] The processor 1301 may include one or more processing cores, such as a 4-core processor, an 8-core processor, etc. The processor 1301 may be implemented in at least one hardware form of DSP (Digital Signal Processing), FPGA (Field-Programmable Gate Array), and PLA (Programmable Logic Array). The processor 1301 may also include a main processor and a coprocessor. The main processor is a processor for processing data in the wake state, also known as the CPU (Central Processing Unit); the coprocessor is a low-power processor for processing data in the standby state. In some embodiments, the processor 1301 may be integrated with a GPU (Graphics Processing Unit), and the GPU is responsible for rendering and drawing the content to be displayed on the display screen. In some embodiments, the processor 1301 may further include an AI (Artificial Intelligence) processor, and the AI processor is used to process computational operations related to machine learning.

[0236] The memory 1302 may include one or more computer-readable storage media, and the computer-readable storage media may be non-transitory. The memory 1302 may also include high-speed random access memory and non-volatile memory, such as one or more disk storage devices and flash storage devices. In some embodiments, the non-transitory computer-readable storage medium in the memory 1302 is used to store at least one computer program, and the at least one computer program is used to be executed by the processor 1301 to implement the data transmission method provided in the method embodiment of the present application.

[0237] In some embodiments, the terminal device 1300 may further optionally include: a peripheral device interface 1303 and at least one peripheral device. The processor 1301, the memory 1302, and the peripheral device interface 1303 may be connected through a bus or signal lines. Each peripheral device may be connected to the peripheral device interface 1303 through a bus, signal lines, or a circuit board. Specifically, the peripheral device includes at least one of a radio frequency circuit 1304, a display screen 1305, a camera assembly 1306, an audio circuit 1307, and a power supply 1308.

[0238] The peripheral device interface 1303 may be used to connect at least one peripheral device related to I / O (Input / Output) to the processor 1301 and the memory 1302. In some embodiments, the processor 1301, the memory 1302, and the peripheral device interface 1303 are integrated on the same chip or circuit board; in some other embodiments, any one or two of the processor 1301, the memory 1302, and the peripheral device interface 1303 may be implemented on a separate chip or circuit board, and this embodiment does not limit this.

[0239] The radio frequency circuit 1304 is used to receive and transmit RF (Radio Frequency) signals, also known as electromagnetic signals. The radio frequency circuit 1304 communicates with a communication network and other communication devices through electromagnetic signals. The radio frequency circuit 1304 converts an electrical signal into an electromagnetic signal for transmission, or converts the received electromagnetic signal into an electrical signal. Optionally, the radio frequency circuit 1304 includes: an antenna system, an RF transceiver, one or more amplifiers, a tuner, an oscillator, a digital signal processor, a codec chipset, a subscriber identity module card, and the like. The radio frequency circuit 1304 may communicate with other terminals through at least one wireless communication protocol. The wireless communication protocol includes but is not limited to: the World Wide Web, a metropolitan area network, an intranet, each generation of mobile communication networks (2G, 3G, 4G, and 5G), a wireless local area network, and / or a WiFi (Wireless Fidelity) network. In some embodiments, the radio frequency circuit 1304 may further include a circuit related to NFC (Near Field Communication), and this application does not limit this.

[0240] The display screen 1305 is used to display the UI (User Interface). The UI may include graphics, text, icons, videos, and any combination thereof. When the display screen 1305 is a touch display screen, the display screen 1305 also has the ability to collect touch signals on or above the surface of the display screen 1305. The touch signals can be input to the processor 1301 as control signals for processing. At this time, the display screen 1305 can also be used to provide virtual buttons and / or virtual keyboards, also known as soft buttons and / or soft keyboards. In some embodiments, there may be one display screen 1305, which is disposed on the front panel of the terminal device 1300; in other embodiments, there may be at least two display screens 1305, which are respectively disposed on different surfaces of the terminal device 1300 or are in a foldable design; in other embodiments, the display screen 1305 may be a flexible display screen, which is disposed on the curved surface or the folding surface of the terminal device 1300. Even further, the display screen 1305 can also be set to an irregular non-rectangular shape, that is, a special-shaped screen. The display screen 1305 can be prepared using materials such as LCD (Liquid Crystal Display) and OLED (Organic Light-Emitting Diode).

[0241] The camera module 1306 is used to capture images or videos. Optionally, the camera module 1306 includes a front camera and a rear camera. Generally, the front camera is disposed on the front panel of the terminal, and the rear camera is disposed on the back of the terminal. In some embodiments, there are at least two rear cameras, which are any one of a main camera, a depth-of-field camera, a wide-angle camera, and a telephoto camera, to implement functions such as background blurring by fusing the main camera and the depth-of-field camera, panoramic shooting by fusing the main camera and the wide-angle camera, and VR (Virtual Reality) shooting function or other fused shooting functions. In some embodiments, the camera module 1306 may further include a flash. The flash can be a single-color-temperature flash or a two-color-temperature flash. A two-color-temperature flash refers to a combination of a warm light flash and a cold light flash, which can be used for light compensation under different color temperatures.

[0242] The audio circuit 1307 may include a microphone and a speaker. The microphone is used to collect sound waves of the user and the environment, and convert the sound waves into electrical signals for input to the processor 1301 for processing, or input to the radio frequency circuit 1304 to enable voice communication. For the purpose of stereo collection or noise reduction, there may be multiple microphones, which are respectively arranged at different parts of the terminal device 1300. The microphone may also be an array microphone or an omnidirectional collection microphone. The speaker is used to convert the electrical signal from the processor 1301 or the radio frequency circuit 1304 into sound waves. The speaker may be a traditional thin film speaker or a piezoelectric ceramic speaker. When the speaker is a piezoelectric ceramic speaker, it can not only convert the electrical signal into sound waves audible to humans, but also convert the electrical signal into sound waves inaudible to humans for uses such as ranging. In some embodiments, the audio circuit 1307 may further include a headphone jack.

[0243] The power supply 1308 is used to supply power to each component in the terminal device 1300. The power supply 1308 may be alternating current, direct current, a disposable battery or a rechargeable battery. When the power supply 1308 includes a rechargeable battery, the rechargeable battery may be a wired rechargeable battery or a wireless rechargeable battery. A wired rechargeable battery is a battery charged through a wired line, and a wireless rechargeable battery is a battery charged through a wireless coil. The rechargeable battery can also be used to support fast charging technology.

[0244] In some embodiments, the terminal device 1300 further includes one or more sensors 1309. The one or more sensors 1309 include but are not limited to: an acceleration sensor 1311, a gyroscope sensor 1312, a pressure sensor 1313, an optical sensor 1314, and a proximity sensor 1315.

[0245] The acceleration sensor 1311 can detect the magnitude of acceleration on the three coordinate axes of the coordinate system established with the terminal device 1300. For example, the acceleration sensor 1311 can be used to detect the components of the gravitational acceleration on the three coordinate axes. The processor 1301 can control the display screen 1305 to display the user interface in a landscape view or a portrait view according to the gravitational acceleration signal collected by the acceleration sensor 1311. The acceleration sensor 1311 can also be used for the collection of game or user's motion data.

[0246] The gyroscope sensor 1312 can detect the body direction and rotation angle of the terminal device 1300. The gyroscope sensor 1312 can cooperate with the acceleration sensor 1311 to collect the 3D actions of the user on the terminal device 1300. Based on the data collected by the gyroscope sensor 1312, the processor 1301 can achieve the following functions: motion sensing (such as changing the UI according to the user's tilt operation), image stabilization during shooting, game control, and inertial navigation.

[0247] The pressure sensor 1313 can be disposed on the side frame of the terminal device 1300 and / or the lower layer of the display screen 1305. When the pressure sensor 1313 is disposed on the side frame of the terminal device 1300, it can detect the holding signal of the user on the terminal device 1300, and the processor 1301 performs left and right hand recognition or quick operation according to the holding signal collected by the pressure sensor 1313. When the pressure sensor 1313 is disposed on the lower layer of the display screen 1305, the processor 1301 controls the operable controls on the UI interface according to the pressure operation of the user on the display screen 1305. The operable controls include at least one of a button control, a scroll bar control, an icon control, and a menu control.

[0248] The optical sensor 1314 is used to collect the ambient light intensity. In one embodiment, the processor 1301 can control the display brightness of the display screen 1305 according to the ambient light intensity collected by the optical sensor 1314. Specifically, when the ambient light intensity is high, the display brightness of the display screen 1305 is increased; when the ambient light intensity is low, the display brightness of the display screen 1305 is decreased. In another embodiment, the processor 1301 can also dynamically adjust the shooting parameters of the camera module 1306 according to the ambient light intensity collected by the optical sensor 1314.

[0249] The proximity sensor 1315, also known as a distance sensor, is usually disposed on the front panel of the terminal device 1300. The proximity sensor 1315 is used to collect the distance between the user and the front of the terminal device 1300. In one embodiment, when the proximity sensor 1315 detects that the distance between the user and the front of the terminal device 1300 is gradually decreasing, the processor 1301 controls the display screen 1305 to switch from the lit state to the off state; when the proximity sensor 1315 detects that the distance between the user and the front of the terminal device 1300 is gradually increasing, the processor 1301 controls the display screen 1305 to switch from the off state to the lit state.

[0250] Those skilled in the art can understand that Figure 13 the structure shown in does not limit the terminal device 1300, and it may include more or fewer components than shown in the figure, or combine some components, or adopt different component arrangements.

[0251] Figure 14FIG. 0 is a schematic structural diagram of a server provided by an embodiment of the present application. The server 1400 may vary greatly due to different configurations or performances, and may include one or more processors 1401 and one or more memories 1402. Among them, at least one computer program is stored in the one or more memories 1402, and the at least one computer program is loaded and executed by the one or more processors 1401 to implement the data transmission methods provided by the above various method embodiments. Exemplarily, the processor 1401 is a CPU. Of course, the server 1400 may also have components such as wired or wireless network interfaces, keyboards, and input / output interfaces for input / output. The server 1400 may also include other components for implementing the functions of the device, which will not be elaborated here.

[0252] In an exemplary embodiment, a computer-readable storage medium is also provided. At least one computer program is stored in the storage medium, and the at least one computer program is loaded and executed by a processor to enable an electronic device to implement any one of the above data transmission methods.

[0253] Optionally, the above computer-readable storage medium may be a read-only memory (ROM), a random access memory (RAM), a compact disc read-only memory (CD-ROM), a magnetic tape, a floppy disk, an optical data storage device, etc.

[0254] In an exemplary embodiment, a computer program is also provided. The computer program is at least one, and the at least one computer program is loaded and executed by a processor to enable an electronic device to implement any one of the above data transmission methods.

[0255] In an exemplary embodiment, a computer program product is also provided. At least one computer program is stored in the computer program product, and the at least one computer program is loaded and executed by a processor to enable an electronic device to implement any one of the above data transmission methods.

[0256] It should be understood that the term "plurality" mentioned herein refers to two or more. "And / or" describes the association relationship of associated objects and indicates that three relationships may exist. For example, A and / or B may represent three situations: A exists alone, A and B exist simultaneously, and B exists alone. The character " / " generally represents an "or" relationship between the associated objects before and after.

[0257] The serial numbers of the embodiments of the present application above are only for description and do not represent the advantages or disadvantages of the embodiments.

[0258] The above are only exemplary embodiments of the present application and are not intended to limit the present application. Any modifications, equivalent replacements, improvements, etc. made within the principles of the present application shall be included within the protection scope of the present application.

Claims

1. A data transmission method, characterized in that: The method comprises: In response to capturing that an event transmission mark is generated by the first node in the process of maintaining a first blockchain, obtaining transmission data related to the event transmission mark sent by the first node, the first blockchain includes a plurality of first block headers, the event transmission mark is used to mark event data to be transmitted to a second blockchain derived from the first blockchain, and the transmission data includes the event data; Determine a target block header associated with the event transmission tag from the plurality of first block headers; The transmission data and the target block header are sent to a second node that maintains a second blockchain, and the second node is used to store the transmission data on the second blockchain after verifying the transmission data based on the target block header.

2. The method according to claim 1, characterized in that: The acquiring the transmission data related to the event transmission mark sent by the first node includes: storing the event transmission mark in a buffer pool, wherein the buffer pool is used to store the captured mark to be transmitted; If the sum of the number of the to-be-transmitted markers and the event transmission markers is not less than the number threshold, sending a data acquisition request to the first node, where the data acquisition request is used to request to acquire the transmission data; Receive the transmission data fed back by the first node.

3. The method according to claim 2, characterized in that The data acquisition request is also used to request to acquire reference data related to the mark to be transmitted; the method further includes: receiving the reference data fed back by the first node; Determine a reference block header related to the to-be-transmitted tag from the plurality of first block headers; The reference data and the reference block header are sent to the second node, and the second node is used to store the reference data on the second blockchain after verifying the reference data based on the reference block header.

4. The method according to claim 1, characterized in that: The determining a target block header associated with the event transmission mark from the plurality of first block headers includes: Verifying the multiple first block headers in a trusted execution environment to obtain verification results of each first block header; If the verification results of the first block headers all indicate that the verification is passed, the target block header is extracted from the multiple first block headers.

5. The method according to claim 4, characterized in that A first first block header among the plurality of first block headers is a genesis block, and the first block header carries an original characteristic value; The verifying the plurality of first block headers in the trusted execution environment to obtain verification results of the respective first block headers includes: Verifying the genesis block in a trusted execution environment to obtain a verification result of the genesis block; For any first block header among the multiple first block headers except the genesis block, transaction information of the any first block header is obtained in the trusted execution environment, a reference feature value of the any first block header is calculated based on the transaction information of the any first block header and an original feature value carried by a previous first block header, and a verification result of the any first block header is determined based on the reference feature value and the original feature value of the any first block header.

6. The method according to claim 4, characterized in that The sending the transmission data and the target block header to the second node maintaining the second blockchain includes: Signing the target block header in the trusted execution environment to obtain signature information; Verifying the signature information to obtain a first verification result of the signature information; If the first verification result of the signature information indicates that the verification is passed, the transmission data and the target block header are sent to the second node.

7. The method according to claim 6, characterized in that The method further comprises: The signature information is sent to the second node, and the second node is used to verify the transmission data based on the target block header after verifying the signature information.

8. A data transmission method, characterized in that: The method comprises: Obtaining transmission data and a target block header related to an event transmission marker sent by a relay node when an event transmission marker is captured, wherein the event transmission marker is a marker generated by a first node in the process of maintaining a first blockchain, and the event transmission marker is used to mark event data to be transmitted to a second blockchain derived from the first blockchain, the transmission data includes the event data, and the target block header is determined from a plurality of first block headers included in the first blockchain; Verify the transmission data based on the target block header to obtain a target verification result; If the target verification result indicates that the verification is passed, the transmission data is stored in the second blockchain.

9. The method according to claim 8, characterized in that The verifying the transmission data based on the target block header to obtain a target verification result includes: Obtaining signature information obtained by the relay node signing the target block header in a trusted execution environment; Verifying the signature information to obtain a second verification result of the signature information; If the second verification result of the signature information indicates that the verification is passed, the transmission data is verified based on the target block header to obtain a target verification result.

10. The method according to claim 8 or 9, characterized in that: The transmission data includes transaction data of a plurality of transactions and a Merkle path, wherein the Merkle path is used to indicate a path for compressing the plurality of transaction data into a Merkle root; The verifying the transmission data based on the target block header to obtain a target verification result includes: Compressing the plurality of transaction data according to the Merkle path to obtain a reference Merkle root; Extracting a target Merkle root from the target block header; Based on the reference Merkle root and the target Merkle root, a target verification result is determined.

11. The method according to claim 8, characterized in that The method further comprises: Obtaining reference data and reference block header sent by the relay node; Verifying the reference data based on the reference block header to obtain a reference verification result; If the reference verification result indicates that the verification is passed, the reference data is stored in the second blockchain.

12. A data transmission device, characterized in that: The device comprises: an acquisition module, configured to, in response to capturing that an event transmission mark is generated by a first node in a process of maintaining a first blockchain, acquire transmission data related to the event transmission mark sent by the first node, wherein the first blockchain includes a plurality of first block headers, the event transmission mark is used to mark event data to be transmitted to a second blockchain derived from the first blockchain, and the transmission data includes the event data; A determination module, configured to determine a target block header associated with the event transmission mark from the plurality of first block headers; The sending module is used to send the transmission data and the target block header to the second node maintaining the second blockchain, and the second node is used to store the transmission data on the second blockchain after verifying the transmission data based on the target block header.

13. A data transmission device, characterized in that: The device comprises: an acquisition module, configured to acquire transmission data and a target block header related to an event transmission marker sent by a relay node when an event transmission marker is captured, wherein the event transmission marker is a marker generated by a first node in the process of maintaining a first blockchain, and the event transmission marker is used to mark event data to be transmitted to a second blockchain derived from the first blockchain, the transmission data includes the event data, and the target block header is determined from a plurality of first block headers included in the first blockchain; A verification module, used to verify the transmission data based on the target block header to obtain a target verification result; The storage module is used to store the transmission data on the second blockchain if the target verification result indicates that the verification is passed.

14. A data transmission system, characterized in that: The data transmission system comprises a relay node and a second node, the relay node is used to execute the data transmission method according to any one of claims 1 to 7, and the second node is used to execute the data transmission method according to any one of claims 8 to 11.

15. An electronic device, characterized in that: The electronic device comprises a processor and a memory, wherein the memory stores at least one computer program, and the at least one computer program is loaded and executed by the processor so that the electronic device implements the data transmission method according to any one of claims 1 to 11.

16. A computer-readable storage medium, characterized in that: The computer-readable storage medium stores at least one computer program, and the at least one computer program is loaded and executed by the processor to enable the electronic device to implement the data transmission method according to any one of claims 1 to 11.

17. A computer program product, characterized in that The computer program product stores at least one computer program, and the at least one computer program is loaded and executed by a processor so that the electronic device implements the data transmission method according to any one of claims 1 to 11.

Images