Data processing method, system and node

Abstract

The invention relates to the technical field of block chains, and discloses a data processing method and system and nodes. Wherein the control node, the receiving node and the block management node belong to the same block chain system. A control node may broadcast a block chain including a cross-chain contract, the cross-chain contract including time information indicating a reporting time of state information of at least one parallel chain. The state information of any parallel chain is submitted to the receiving node within the time specified by the cross-chain contract. And the receiving node sends the state information of the parallel chain to the block management node, and the block management node records the state information of the parallel chain to the relay chain and broadcasts the relay chain. Through the data processing method, the time delay of cross-chain transaction in the block chain system can be reduced.

Description

Data processing method, system and node Technical Field

[0001] The present application relates to the field of communication technology, and in particular to a data processing method, system, and node. Background Art

[0002] Blockchain, as a distributed ledger technology, has been applied in many fields due to its openness, transparency, and immutability. If a transaction on one blockchain requires the completion of a sub-transaction on another blockchain, it is considered a cross-chain transaction.

[0003] Cross-chain transactions involve the transfer of cross-chain state information. This transfer can be achieved using relay chain technology. For example, all relay node groups in a blockchain system jointly maintain a relay chain, where each relay node group records the state of its corresponding blockchain. The relay chain can broadcast this information to all blockchains, allowing different blockchains to query each other's state, thus enabling cross-chain state transfer.

[0004] However, each blockchain independently sends status information to its corresponding relay node group, and each parachain independently decides when to report its status information. This results in the relay chain recording blockchain status information being out of date, making it difficult for one blockchain to obtain the real-time status information of another blockchain, and thus making it difficult to guarantee transaction timeliness.

[0005] Summary of the Invention

[0006] This application provides a data processing method, system, and node for reducing the latency of cross-chain transactions in a blockchain system.

[0007] In a first aspect, embodiments of the present application provide a data processing method, which is applied to a control node in a blockchain system. The blockchain system also includes at least one receiving node group, each receiving node group including at least one receiving node. The method can be performed by a first communication device, which can be a control node or a unit or functional module within the control node. For example, the first communication device can be a chip provided in the control node, or the first communication device can be another component used to implement the functions of the control node. The method provided in the first aspect is described below using the first communication device as an example of the control node itself.

[0008] The method includes: a control node determining a cross-chain contract and broadcasting the cross-chain contract. The cross-chain contract includes time information indicating a time when status information of at least one parachain is reported. A parachain is a blockchain connected to a receiving node group. The control node broadcasts the cross-chain contract.

[0009] In this solution, a blockchain system can be equipped with a control node to specify the reporting time for the status information of at least one parachain in the blockchain system. The control node can broadcast a cross-chain contract, which, through the cross-chain contract, broadcasts the reporting time for the status information of at least one parachain. Devices storing the status information of the parachain in the blockchain system are required to report the status of the parachain within the time specified by the cross-chain contract. Because the cross-chain contract can constrain the reporting time for the status information of the parachain, each node in the blockchain system can, in accordance with the cross-chain contract, report the latest status information of at least one parachain before the specified reporting time. This method can reduce the latency caused by the acquisition of out-of-date status information of the parachain in cross-chain transactions. Furthermore, a parachain is a blockchain connected to a single receiving node group. This means that a blockchain only needs to establish a connection with one receiving node group to interact with n other blockchains connected to that receiving node group. Therefore, there is no need to maintain block data for multiple blockchains, reducing overhead.

[0010] In a possible implementation, the time information may include one time, or the time information may include multiple times, each time corresponding to one or more parachains. That is, the time information may indicate one time, or the time information may indicate multiple times, each of which indicates the reporting time of the status information of one or more parachains. The reporting time of the status information of each parachain may be the same. In this case, the cross-chain contract may include one time, and the status information of each parachain may be reported before this time; or the reporting time of the status information of different parachains may be different. In this case, the cross-chain contract may include multiple times, and each time corresponds to one or more parachains.

[0011] In a possible implementation, the control node determines the cross-chain contract, including: the control node receives information from at least one parachain, and determines the cross-chain contract based on the information from the at least one parachain. The control node may determine an appropriate reporting time for the status information of each parachain based on the information of the parachain itself.

[0012] In a possible implementation, the method further includes: the control node broadcasting a first scheduling instruction, where the first scheduling instruction is used to group receiving nodes in the blockchain system.

[0013] In this method, the control node can group the receiving nodes in the blockchain system, with each receiving node group corresponding to a parallel chain. By grouping the receiving nodes, the management of the parallel chain can be achieved.

[0014] In a possible implementation, the method further includes: the control node determining that the state information on the relay chain does not include the state information of the first parachain, broadcasting a second scheduling instruction, the second scheduling instruction being used to regroup the receiving node group corresponding to the first parachain. The reporting time of the state information on the relay chain satisfies the cross-chain contract. The reporting time of the state information on the relay chain satisfies the cross-chain contract, which is equivalent to the reporting time of the state information on the relay chain meeting the time specified by the time information included in the cross-chain contract.

[0015] If the status information on the relay chain does not include the status information of the first parachain, it indicates that the transmission of the status information of the first parachain has been interrupted. The interruption in the transmission of the status information of the first parachain may be due to a disconnection between the first parachain and the receiving node group. The control node regroups the receiving node group corresponding to the first parachain through the second scheduling instruction, and may attempt to have different receiving nodes interact with the first parachain, thereby resuming the reporting of the status information of the first parachain.

[0016] In a possible implementation, the method further includes: receiving, by a control node, an admission application sent by a first receiving node, the admission application being a request to join the relay chain system, allowing the first receiving node to join the relay chain system, and recording authorization information of the first receiving node. The first receiving node is any receiving node in the blockchain system.

[0017] In this method, the control node manages the inclusion of receiving nodes in the relay chain. Maintaining the relay chain through the control node allows all nodes in the blockchain system to share information recorded in the relay chain. For example, the relay chain records the authorization information of the receiving node, which can be used to authenticate the receiving node during cross-chain transactions.

[0018] In a possible implementation, the blockchain system further includes at least one block management node, the block management node being configured to manage the acquired state information of the parachain. The method further includes: receiving, by a control node, an admission application sent by a first block management node, the admission application being configured to request to join the relay chain system; allowing the first block management node to join the relay chain system, and recording authorization information of the first block management node. The first block management node belongs to the at least one block management node.

[0019] The blockchain system also includes a block manager node (BMP) that manages the status of parachains. The control node also manages the BMP's inclusion in the relay chain, which is maintained by the controller. Each node in the blockchain system authenticates the BMP based on its authorization information.

[0020] In a second aspect, embodiments of the present application provide a data processing method, which is applied to a block management node in a blockchain system. The blockchain system also includes a control node and at least one receiving node group, each receiving node group including at least one receiving node. The method can be performed by a second communication device, which can be a block management node or a unit or functional module within the block management node. For example, the second communication device can be a chip provided in the block management node, or the second communication device can be other components used to implement the functions of the block management node. The method provided in the second aspect is described below using the block management node itself as an example.

[0021] The method includes: a block management node receives a cross-chain contract from a control node, the cross-chain contract includes time information, and the time information indicates the reporting time of status information of at least one parallel chain, where a parallel chain is a blockchain connected to a receiving node group; a first block management node receives status information of multiple parallel chains; the first block management node records the status information of at least one parallel chain to a relay chain and broadcasts the relay chain, wherein the reporting time of the status information of the at least one parallel chain satisfies the cross-chain contract.

[0022] In this method, the first block manager node can obtain the status information of multiple parachains from multiple receiving nodes. Considering that the reporting time of some parachain status information may not meet the cross-chain contract, that is, the parachain status information may not be up to date, the first block manager node can record the status information of at least one parachain that meets the cross-chain contract to the relay chain and then broadcast it to the relay chain. This allows parachains to obtain the latest status information from each other, thereby reducing the latency of cross-chain transactions.

[0023] In a possible implementation, the time information may include a single time, or the time information may include multiple times, each time corresponding to one or more parachains. In other words, the time information may indicate a single time, or the time information may indicate multiple times, each of which indicates a reporting time for status information of one or more parachains.

[0024] In a possible implementation, the method further includes: the first block management node sending an admission request to the control node, the admission request being used to request to join the relay chain system; and the first block management node receiving authorization information of the first block management node sent by the control node. The authorization information may indicate to the control node that the first block management node is permitted to join the relay chain system.

[0025] Regarding the beneficial effects of the second aspect and each implementation method, reference may be made to the beneficial effects of the aforementioned first aspect and each implementation method, which will not be repeated here.

[0026] In a third aspect, an embodiment of the present application provides a data processing method, which is applied to any receiving node in a blockchain system. The blockchain system also includes a control node and at least one receiving node group, and a receiving node group includes at least one receiving node. The method can be performed by a third communication device, which can be any receiving node or a unit, functional module, etc. within any receiving node. For example, the third communication device can be a chip provided in the receiving node, or the third communication device can be other components for implementing the functions of any receiving node. The method provided in the third aspect is described below using the third communication device as any receiving node itself as an example.

[0027] The method includes: the receiving node receives a cross-chain contract from the control node, the cross-chain contract includes time information, the time information indicates the reporting time of the status information of at least one parallel chain, and one of the parallel chains is a blockchain connected to a receiving node group; the receiving node receives the status information of the first parallel chain, and the first parallel chain is a blockchain connected to the first receiving node group to which the receiving node belongs; if the status information of the first parallel chain meets the time information included in the cross-chain contract, the status information of the first parallel chain is broadcast.

[0028] In this method, a receiving node receives the status information of the first parachain and can determine whether the status information of the first parachain satisfies the cross-chain contract. If so, the status information of the first parachain is broadcast. This method facilitates the maintenance of parachains. In addition, a parachain is a blockchain connected to a receiving node group. That is, a blockchain only needs to establish a connection with one receiving node group to interact with n other blockchains connected to the receiving node group. Therefore, there is no need to maintain block data for multiple blockchains, which can reduce overhead.

[0029] In a possible implementation, the method further includes: the first receiving node sending an admission request to the control node, the admission request being used to request to join the relay chain system; and the first receiving node receiving authorization information of the first receiving node sent by the control node. The authorization information may indicate that the control node permits the first receiving node to join the relay chain system.

[0030] In a possible implementation, the method further includes: the first receiving node receives a first scheduling instruction broadcast by the control node, where the first scheduling instruction is used to group the receiving nodes in the blockchain system; the first receiving node determines that the first receiving node belongs to a first group of receiving nodes based on the first scheduling instruction.

[0031] In a possible implementation, the method also includes: the first receiving node receives a second scheduling instruction broadcast by the control node, and the second scheduling instruction is used to regroup the first group of receiving nodes; the first receiving node determines to establish a connection with the memory corresponding to the second receiving node group according to the second scheduling instruction, wherein the first receiving node changes from originally belonging to the first receiving node group to belonging to the second receiving node group.

[0032] Regarding the third aspect and the beneficial effects of each implementation method, reference can be made to the beneficial effects of the aforementioned first aspect and its various implementation methods, which will not be repeated here.

[0033] In the fourth aspect, the embodiment of the present application further provides a node. The beneficial effects can be found in the description of the first aspect and will not be described in detail here. The device has the function of implementing the behavior in the method example of the first aspect above. The function can be implemented by hardware, or by hardware executing corresponding software implementation. The hardware or software includes one or more modules corresponding to the above functions. In one possible design, the structure of the device includes a processing module and a transceiver module, which can perform the corresponding functions in the method example of the first aspect above. Please refer to the detailed description in the method example for details, which will not be described here.

[0034] In the fifth aspect, the embodiment of the present application further provides a node. The beneficial effects can be found in the description of the second aspect and will not be described in detail here. The device has the function of implementing the behavior in the method example of the second aspect above. The function can be implemented by hardware, or by hardware executing corresponding software implementation. The hardware or software includes one or more modules corresponding to the above functions. In one possible design, the structure of the device includes a processing module and a transceiver module, which can perform the corresponding functions in the method example of the second aspect above. Please refer to the detailed description in the method example for details, which will not be described here.

[0035] In the sixth aspect, the embodiment of the present application further provides a node. The beneficial effects can be found in the description of the third aspect, which will not be repeated here. The device has the function of implementing the behavior in the method example of the third aspect above. The function can be implemented by hardware, or by hardware executing corresponding software implementation. The hardware or software includes one or more modules corresponding to the above functions. In one possible design, the structure of the device includes a processing module and a transceiver module, which can perform the corresponding functions in the method example of the third aspect above. Please refer to the detailed description in the method example for details, which will not be repeated here.

[0036] In the seventh aspect, an embodiment of the present invention provides a node, which includes a processor and a memory, and may also include a network card. The processor can call the program instructions in the memory to enable the computing device to execute the method provided by the first aspect or any possible implementation of the first aspect, or execute the method provided by the second aspect or any possible implementation of the second aspect, or execute the method provided by the third aspect or any possible implementation of the third aspect. The memory is coupled to the processor, which stores the program instructions and data necessary to execute the data transmission method. The communication interface is used to communicate with other devices and transmit data, such as providing status information of the parallel chain and providing cross-chain contracts.

[0037] In an eighth aspect, the present application provides a computer-readable storage medium storing computer program instructions. When the instructions are executed by a computing device, the computing device may execute the aforementioned first aspect or any possible implementation of the first aspect, or execute the aforementioned second aspect or any possible implementation of the second aspect, or execute the aforementioned third aspect or any possible implementation of the third aspect.

[0038] The storage medium stores the program, including but not limited to volatile memory, such as random access memory, and non-volatile memory, such as flash memory, hard disk drive (HDD), and solid state drive (SSD).

[0039] In a ninth aspect, the present application provides a computing device program product, which includes computer instructions. When executed by a computing device, the computing device can execute the aforementioned first aspect or any possible implementation of the first aspect, or execute the aforementioned second aspect or any possible implementation of the second aspect, or execute the aforementioned third aspect or any possible implementation of the third aspect. The computer program product can be a software installation package. When it is necessary to use the method provided in the aforementioned first aspect or any possible implementation of the first aspect, or when it is necessary to use the method provided in the aforementioned second aspect or any possible implementation of the second aspect, or when it is necessary to use the method provided in the aforementioned third aspect or any possible implementation of the third aspect, the computer program product can be downloaded and executed on a computing device.

[0040] For description of the effects that can be achieved in any of the second to ninth aspects or any possible design in any of the aspects, please refer to the technical effects of the corresponding aspects in the first aspect above, and repetitions will not be discussed. BRIEF DESCRIPTION OF THE DRAWINGS

[0041] FIG1 is a schematic diagram of a cross-chain communication provided in an embodiment of the present application;

[0042] FIG2 is a schematic diagram of another cross-chain communication provided in an embodiment of the present application;

[0043] FIG3 is a schematic diagram of cross-chain communication provided by an embodiment of the present application;

[0044] FIG4 is a flow chart of a data processing method provided in an embodiment of the present application;

[0045] FIG5 is a schematic diagram of the process of transmitting the status information of the parallel chain provided in an embodiment of the present application;

[0046] FIG6 is a schematic diagram of a control flow of a control node provided in an embodiment of the present application;

[0047] FIG7 is a schematic diagram of a structure of a node provided in an embodiment of the present application;

[0048] FIG8 is another structural diagram of a node provided in an embodiment of the present application. DETAILED DESCRIPTION

[0049] To facilitate understanding of the technical solutions provided by the embodiments of the present application, some technical terms involved in the embodiments of the present application are first introduced.

[0050] 1) Blockchains are a distributed ledger composed of sequentially linked data blocks in chronological order, ensuring that the data cannot be tampered with or forged using cryptographic methods. Blockchains are based on peer-to-peer (P2P) networks. Every P2P network node involved in transactions and block storage, verification, and forwarding is a node on the blockchain.

[0051] A blockchain network can include one or more blockchains, each of which can include multiple blockchain nodes. Blockchain nodes can include ledger instances and chaincodes. Ledger instances record transactions within the blockchain network. Chaincodes, also known as smart contracts, allow blockchain nodes to query transactions within ledger instances and add new transactions to them. There can be one or more chaincodes. Blockchain nodes can be implemented as various terminals or servers, acting as trusted nodes capable of executing smart contracts for private transactions and synchronizing block data within the blockchain network.

[0052] Blockchain nodes that join the same blockchain can conduct transactions and share ledgers. A blockchain node can join one or more blockchains. When a blockchain node joins a single blockchain, it holds a single ledger. When a blockchain node joins multiple blockchains, it holds multiple ledgers. Each blockchain node stores both ledger data and state information (a state database).

[0053] It's important to note that the ledger data in the block is immutable, while the state information in the state information repository records the results of each transaction. Therefore, it can be modified by adding transactions. In practice, the state information stored in the state information repository may be data related to the most recent transaction in the current ledger. Furthermore, during each transaction, the ledger data is not updated; instead, a "simulated" transaction is performed to obtain the results. Once consensus is reached on the blockchain, the corresponding results are synchronized to the corresponding block. Afterward, blockchain nodes can retrieve the structure from the target block storing it and write the pending data within it to the corresponding state information repository.

[0054] It should be understood that smart contracts are essentially executable code stored on a blockchain. While they don't necessarily have actual owners and aren't strictly accounts, their characteristics and behavior can, in many cases, be considered machine accounts controlled by programming logic. In a broader sense, smart contracts can also include smart contract programming languages, compilers, virtual machines, events, state machines, and fault-tolerance mechanisms.

[0055] 2) Verification of the integrity and accuracy of the blockchain data. For example, the integrity and accuracy of the blockchain data can be verified using a Merkle tree, or a Merkle range can be used to verify the integrity and accuracy of the blockchain data.

[0056] A Merkle tree is a binary hash tree consisting of a set of leaf nodes, a set of intermediate nodes, and a root node. Leaf nodes contain stored information or hash values ​​of stored information, intermediate nodes store the hash values ​​of their two child nodes, and the root node at the top also stores the hash values ​​of its two child nodes. When new data is added to discrete dataset 1 corresponding to blockchain 1, discrete dataset 2 is obtained. Then, Merkle tree 1 corresponding to discrete dataset 1 is reorganized to obtain Merkle tree 2. Based on Merkle tree 2, discrete dataset 2 is processed to obtain digest 2, which is then used to verify discrete dataset 2.

[0057] A Merkle range is a Merkle tree structure that resembles a series of continuous mountain peaks. Merkle ranges have the advantage of being immutable once nodes are inserted, allowing for dynamic insertion. Continuing with the example above, to verify data accuracy using a Merkle range, we simply need to expand Merkle range A corresponding to discrete dataset 1 to obtain Merkle range B. We then process discrete dataset 2 based on Merkle range B to obtain summary B, which we then use to verify discrete dataset 2.

[0058] 3) Cross-chain refers to operations that coordinate multiple chains and have an impact on multiple chains. Alternatively, operations that coordinate multiple chains and have an impact on multiple chains can be considered cross-chain.

[0059] Cross-chain communication / cross-chain transactions refer to transactions that require the simultaneous execution of sub-transactions on multiple blockchains. Cross-chain transactions require the simultaneous success or failure of sub-transactions on multiple blockchains. Cross-chain transactions are implemented through the execution of cross-chain transactions, meaning that cross-chain functionality is achieved through the execution of cross-chain transactions. For example, if a cross-chain transaction on blockchain A requires a specific transaction on blockchain B, then blockchain A requires cross-chain communication.

[0060] Cross-chain transactions involve the verification of cross-chain state information, which can be referred to as cross-chain state verification. This cross-chain state verification can be achieved through cross-chain state transfer technology. Cross-chain state transfer technology involves the transfer and verification of cross-chain state. Continuing with the example above, the state of blockchain B can be transferred to the smart contract of blockchain A, allowing users on blockchain A to verify the cross-chain state of blockchain B.

[0061] Cross-chain state transfer technology requires the use of relay nodes. Relay nodes interconnect two networks by retransmitting or forwarding data signals. Relay nodes in a cross-chain transaction can convert data sent from one blockchain into a data structure recognizable by the other chain. They also send cross-chain instructions to the other chain by calling the blockchain's application programming interface, coordinating all participating blockchains.

[0062] For example, see Figure 1, which is a schematic diagram of a cross-chain communication system. The system shown in Figure 1 includes blockchain A, blockchain B, and a relay node cluster. Figure 1 uses the example of four blockchain nodes (also called users) on blockchain 1 and four blockchain nodes (also called users) on blockchain B. The relay node cluster includes multiple relay nodes and is a distributed structure. Figure 1 uses the example of a relay node cluster including three relay nodes. Any relay node can join one or more blockchains and provide cross-chain services. Figure 1 uses the example of a user on blockchain A needing to conduct a cross-chain transaction, and this cross-chain transaction requires the cross-chain status on blockchain B.

[0063] For example, when a user on blockchain A needs cross-chain verification, they can request block data from blockchain B from a relay node in the relay node cluster. After obtaining all the block data from blockchain B, the relay node sends it to the smart contract on blockchain A. The smart contract on blockchain A receives and maintains the block data from blockchain B. For example, the smart contract can generate a summary of the transaction data within each block on blockchain B using Merkle Trees and record this summary in the block header. This allows the smart contract on blockchain A to verify the validity of the transaction data on blockchain B based on the block header data, thereby achieving cross-chain state verification.

[0064] However, in the system shown in Figure 1, the smart contract on blockchain A needs to receive and maintain data from all blocks on blockchain B, which results in significant overhead. Furthermore, if blockchain A wishes to conduct cross-chain transactions with multiple blockchains, it must establish multiple cross-chain connections sequentially, which is inefficient. Furthermore, blockchain A needs to maintain data from all blocks on multiple blockchains, which is still very costly.

[0065] To this end, we propose implementing cross-chain transactions based on relay chain technology. A relay chain is a blockchain with the same functionality as a relay node, enabling interconnection between multiple blockchains. In a relay chain-based cross-chain communication system, a relay node cluster originally connected to two blockchains can now connect to multiple blockchains. This allows a blockchain to interact with n other blockchains connected to the relay node cluster, where N is a positive integer. Blockchains connected to relay node clusters are also called parachains.

[0066] A cross-chain communication system based on a relay chain is similar to a relay node cluster-based cross-chain communication system, where the relay node cluster is divided into multiple relay node groups. Each relay node group can connect to and communicate with a single parachain. All relay node groups jointly maintain a relay chain, and each relay node group records the state of its corresponding parachain on the relay chain. The relay chain can broadcast to all parachains, allowing different parachains to obtain each other's state by querying the relay chain, thereby enabling cross-chain state transfer.

[0067] For example, see Figure 2, which shows a schematic diagram of a relay chain-based cross-chain communication system. The system shown in Figure 2 includes parachain A, parachain B, parachain C, and the relay chain. Any parachain connected to the relay chain, including relay node groups 1 through 3, can communicate with other parachains connected to the relay chain. Taking parachain A as an example, parachain A can communicate with parachains B and C through the relay chain. For example, parachain A can send state information to relay node group 1, which records the state information of parachain A on the relay chain. Similarly, relay node group 2 can record the state information of parachain B on the relay chain, and relay node group 3 can record the state information of parachain C on the relay chain. The relay chain records the state information of multiple parachains. The relay chain can broadcast this recorded state information to all parachains, allowing different parachains to access each other's data.

[0068] Each parachain independently sends status information to its corresponding relay node group, independently determining when to report. The relay chain passively receives status information from parachains, resulting in varying delays in status reporting between different parachains. For example, when parachain A's status information is updated, it may report the latest information to relay node group 1 relatively quickly, while when parachain B's status information is updated, it may report the latest information to relay node group 2 with a delay. This results in the relay chain recording parachain status information being out of date, preventing one parachain from obtaining the real-time status information of another, making transaction timeliness difficult to guarantee. Furthermore, parachains and relay chains are independent of each other, and failure of either a parachain or relay chain can cause cross-chain transactions to fail. For example, if a parachain unilaterally terminates the submission of status information, cross-chain transactions will fail due to the inability to obtain the corresponding status information. Furthermore, the relay node cluster is divided into multiple relay node groups, with each group containing fewer relay nodes. This reduces the difficulty of successful attacks on relay node groups and increases the probability of cross-chain transaction failure.

[0069] In order to solve the above problems, a solution of an embodiment of the present application is provided. In the embodiment of the present application, a node for maintaining the relay chain and a node for scheduling the relay node group can be added. This is equivalent to dividing the nodes into multiple categories from a functional perspective: one type of node is used to maintain the relay chain, one type of node is used as a node of the relay node group, and one type of node is used to schedule the nodes of the relay node group. For the convenience of description, the node used to maintain the relay chain is called a block management node, the node used to schedule the relay node group is called a control node, and the node as the relay node group is called a receiving node. The control node, block management node, and receiving node belong to the same blockchain system / network, so that they can be compatible with the current blockchain consensus protocol. In the embodiment of the present application, the time for the parallel chain to report status information can be specified, so that the parallel chain reports status information within a limited time range. The status information of each parallel chain recorded on the relay chain is the latest, and each parallel chain can obtain the latest status information from each other based on the relay chain, thereby reducing the latency of cross-chain transactions. If the relay chain does not obtain the status information of a parallel chain within the specified time, it can be considered that the transmission of the status information is interrupted. The control node can schedule other receiving nodes to interact with the parallel chain to restore the transmission of the status information.

[0070] Please refer to Figure 3, which is a schematic diagram of a system applicable to the data processing method provided in the embodiments of this application. This system is built on a blockchain and is also referred to as a blockchain system. Blockchain systems include two types of blockchains: one type is a relay chain, and the other type is a parachain. The data processing system includes multiple data nodes and at least one memory, each of which is used to store a parachain and belongs to the parachain system. These multiple data nodes belong to the same blockchain network and, as nodes of the blockchain, belong to the relay chain system.

[0071] These multiple data nodes and at least one memory have the basic functions of a blockchain node. Each node in the data processing system stores its own data information and can provide each other with their own data information. For any data node, the data node can provide the data information of the data node to other data nodes in the data processing system. For any memory, the memory can provide the data information stored in the memory to one or more data nodes. Any data node can obtain multiple data information from multiple data nodes and data information from at least one memory. In the embodiment of the present application, the interaction method between different nodes follows the interaction method of the blockchain nodes in the above description. For example, the information exchanged between different nodes can be published to the blockchain network to which the node belongs, so that each blockchain node of the blockchain can obtain this information, so that each blockchain node can record this information and reach a unified consensus on this information.

[0072] The memory can be understood as a distributed node that stores the state information of a parachain. The memory at least stores the state information of the parachain. This state information is updated as the blockchain changes. Optionally, the memory also stores a backup of this state information, which is also updated as the blockchain changes.

[0073] The multiple data nodes belong to the relay chain system. From a functional perspective, these multiple data nodes can be divided into three types of entities, such as control nodes, block management nodes, and receiving nodes. Of course, the multiple data nodes may include at least one control node, at least one block management node, and at least one receiving node. At least one control node, at least one block management node, and at least one receiving node all belong to the relay chain system. At least one block management node jointly maintains a relay chain. It should be noted that the control node, block management node, and receiving node are essentially relay nodes, and the embodiments of the present application do not limit the specific names of the control node, block management node, and receiving node. For example, the control node can also be called a first-class relay node, the block management node can also be called a second-class relay node, and the receiving node can also be called a third-class relay node.

[0074] Receiving nodes are responsible for transmitting parachain status information to the block management node. At least one receiving node is divided into at least one receiving node group. Each receiving node group corresponds to a parachain. Any receiving node group can connect to the corresponding parachain, authenticate that parachain, and interact with it. Authentication of a parachain includes authenticating the identity of the storage device that stores the parachain's status information. The storage device stores the parachain's status information and can send its stored status information to the corresponding receiving node group. Any receiving node group obtains the parachain's status information and transmits it to each block management node. For example, the receiving node group can package the received status information into a status event / transaction and broadcast it to at least one block management node.

[0075] After obtaining the status information of the parachain, the block manager node can generate a relay chain block based on this status information and record this status information on the relay chain. Any block manager node can broadcast the relay chain to all nodes, and each node in the system can obtain the status information of each parachain.

[0076] A control node is responsible for controlling at least one block management node (relay chain), at least one receiving node, and the parachain. For example, the control node can divide the at least one receiving node into at least one receiving node group. For another example, the control node has the authority to determine whether any block management node can join the relay chain system, and also has the authority to determine whether any receiving node can join the relay chain system. Alternatively, any block management node and any receiving node must be reviewed and authorized by the control node before joining the relay chain system. For approved block management nodes and / or receiving nodes, the control node can use a joint signature to authorize them. It can be considered that all control nodes jointly maintain an identity blockchain. It should be understood that this identity blockchain includes information about at least one block management node and at least one receiving node. The control node broadcasts this identity blockchain to all parachains, allowing each parachain to obtain information about all entities on the identity blockchain.

[0077] As mentioned above, if the storage unit independently reports / submits the parachain status information to the receiving node group, and the receiving node group passively receives the status information from the storage unit, the state information of each parachain stored on the relay chain may be out of date, resulting in one parachain being unable to obtain the real-time status information of another parachain, making it difficult to ensure transaction timeliness. In the embodiments of this application, the terms "report" and "submit" are interchangeable.

[0078] To solve this problem, in an embodiment of the present application, it can be stipulated that each storage device shall submit the status information of the parallel chain within a specified time. The status information of the parallel chain submitted within the specified time can be considered as the latest status information of the parallel chain. For example, the control node can sign a cross-chain contract in the form of a joint signature on behalf of the relay chain with any parallel chain that wishes to establish a cross-chain connection with the relay chain. The cross-chain contract can instruct the parallel chain to submit status information within a specified time. In this way, any parallel chain can submit status information according to the cross-chain contract, so that the relay chain can obtain the latest status information of each parallel chain within a limited time, reduce the delay of passively waiting to receive the status information of the parallel chain, and thus try to ensure the timeliness of cross-chain transactions. If the storage device does not submit the status information of the parallel chain within the specified time, it can be considered that the transmission of the status information is interrupted. In this case, the control node can schedule other receiving node groups to interact with the parallel chain to restore the transmission of status information.

[0079] The following first introduces the functions of the control node in conjunction with Figure 4. Please refer to Figure 4 for a flow chart of a data processing method provided in an embodiment of the present application. Figure 4 takes the method as an example of being executed by the first block management node, the first receiving node, the control node, and the parachain management node. If there are multiple block management nodes and multiple receiving nodes, the execution steps of each block management node are the same, and the execution steps of each receiving node are the same. The method includes:

[0080] Step 401: The first block management node sends an admission request to the control node. Correspondingly, the control node receives the admission request from the first block management node, where the admission request is used to request to join the relay chain system.

[0081] The first block management node is one of the block management nodes that wish to join the relay chain system. Any block management node that wishes to join the relay chain system can send an admission application to the control node requesting to join the relay chain system. Taking the first block management node as an example, the admission application sent by the first block management node includes the identity information of the first block management node. For example, the admission application includes the qualification certificate of the first block management node. The embodiment of the present application does not limit the source of the qualification certificate. For example, the qualification certificate of the first block management node can come from an identity authentication system. For example, the qualification certificate of the first block management node can be issued by a certificate authority. Alternatively, the qualification certificate of the first block management node can also come from other channels. For example, the qualification certificate of the first block management node can be obtained from a technology company, a social platform, and a collaboration tool.

[0082] After receiving the admission application from the first BMP, the control node will review the first BMP based on the information contained in the admission application. If the first BMP meets the review criteria, the control node will allow the first BMP to join the relay chain system, or the control node will authorize the first BMP to join the relay chain system. The control node may record the authorization information for the first BMP in a blockchain maintained by the control node, which is also called the identity blockchain.

[0083] Step 402: The first receiving node sends an admission application to the control node. Correspondingly, the control node receives the admission application from the first receiving node, where the admission application is used to request to join the relay chain system.

[0084] The first receiving node is a receiving node that wishes to join the relay chain system. Any receiving node that wishes to join the relay chain system can send an admission application to the control node requesting to join the relay chain system. Taking the first receiving node as an example, the admission application sent by the first receiving node includes the identity information of the first receiving node. For example, the admission application includes the qualification certificate of the first receiving node. The source of the qualification certificate of the first receiving node can refer to the source of the qualification certificate of the first block management node mentioned above, which will not be repeated here. It should be noted that the source of the qualification certificate of the first receiving node may be the same as or different from the source of the qualification certificate of the first block management node.

[0085] After receiving the admission application from the first receiving node, the control node will review the first receiving node based on the information contained in the admission application. If the first receiving node meets the review criteria, the control node will allow the first receiving node to join the relay chain system, or the control node will authorize the first receiving node to join the relay chain system. Optionally, the control node can use a joint signature authorization for the first block management node and the first receiving node that meet the review criteria. Of course, the control node can also record the authorization information of the receiving node in the identity blockchain maintained by the control node.

[0086] The control node can also control the grouping of multiple receiving nodes, that is, dividing multiple receiving nodes into n receiving node groups. For example, the control node can send a scheduling instruction to each receiving node, and any receiving node receives the scheduling instruction and determines the group to which it belongs according to the scheduling instruction. The scheduling instruction may include identification information of each receiving node group and identification information of the receiving nodes included in each receiving node group. The identification information of the receiving node group may include the identity (ID) of the receiving node group, and the identification information of the receiving node may include the Internet Protocol (IP) address of the receiving node. The control node can broadcast the scheduling instruction so that any receiving node can determine the group to which it belongs and the other receiving nodes in the group. Moreover, any receiving node can communicate with other receiving nodes based on the IP addresses of other receiving nodes in the group. In an embodiment of the present application, the control node can also record the scheduling instruction in the identity blockchain, so that the control node broadcasts the identity blockchain, which can realize the broadcast scheduling instruction.

[0087] Step 403: The parachain management node sends the parachain specification to the control node. Correspondingly, the control node receives the parachain specification from the parachain management node.

[0088] A parachain specification includes information such as the public keys, Internet Protocol (IP) addresses, and credentials of all storage within the parachain system. It also includes the parachain's specifications, such as its block format, block generation rate, and consensus protocol. Parachains seeking to establish a cross-chain connection with the Relay Chain submit their parachain specifications to the control node through the parachain management node. The control node then controls the parachain based on the information contained in the parachain specification.

[0089] Step 404: The control node determines a cross-chain contract, which includes time information, and the time information is used to indicate the reporting time of the status information of at least one parallel chain.

[0090] The control node can determine the maximum delay for reporting the status information of each parachain. This means that the control node can determine the maximum delay for each storage device to submit its stored status information. The time information can indicate or include a single time, meaning that the reporting time for each parachain can be the same. Alternatively, the time information can indicate or include multiple times, each of which indicates the reporting time for one or more parachains. That is, each time corresponds to one or more parachains, and the reporting times for different parachains can also be different. Status information submitted by a storage device within this maximum delay can be considered the latest state information for the parachain submitted by that storage device. This ensures that each storage device submits parachain status information within the maximum delay, ensuring that the state information recorded by the relay chain is up to date. Furthermore, the cross-chain contract can specify other information, such as the specifications for the block header data packet generated by the receiving node after the status information is packaged. The maximum delay for different storage devices to submit status information can vary. That is, the cross-chain contract includes multiple times for storage devices to submit status information, and the times for different storage devices to submit status information can be the same or different.

[0091] It should be noted that the control node can sign the cross-chain contract before the storage is added to the cross-chain protocol. In other words, the cross-chain contract is an offline agreement.

[0092] Step 405: The control node broadcasts the identity blockchain.

[0093] The control node maintains an identity blockchain, which includes authorization information for each block manager and receiving node, scheduling instructions, and cross-chain contracts. The control node broadcasts this identity blockchain, meaning it broadcasts authorization information for each block manager and receiving node, scheduling instructions, and cross-chain contracts. Other nodes on the same blockchain network as the control node can access this identity blockchain.

[0094] Different types of nodes receive the identity blockchain and perform different steps depending on the content of the identity blockchain.

[0095] For example, any receiving node can determine its own receiving node group based on the scheduling instructions included in the identity blockchain. Furthermore, a receiving node can also query the storage corresponding to its receiving node group and establish a connection with the storage so that the storage can subsequently submit / report the stored parachain status information to the corresponding receiving node group.

[0096] For example, a parachain management node could embed the cross-chain contract included in the identity blockchain into the parachain protocol. This would require any storage in the parachain system to submit its latest state information, specifically the parachain block header information, to the receiving node in accordance with this contract. Because the cross-chain contract specifies a minimum time for storage to submit state information, this allows storage to submit parachain state information within a limited timeframe, allowing the relay chain to obtain the latest state information from each parachain within a limited timeframe. This reduces the latency of passively waiting for status information reported by the parachain, thereby ensuring the timeliness of cross-chain transactions.

[0097] If the block management node does not receive the status information submitted by the storage within the time specified by the cross-chain contract, it can be considered that the transmission of status information has been interrupted. The interruption may be caused by the failure of a receiving node in the corresponding receiving node group. In this case, the control node can schedule the interrupted receiving node group. For example, the control node can disband the interrupted receiving node group and randomly assign the receiving nodes included in the receiving node group to other receiving node groups. One or more receiving nodes included in the other receiving node groups can be reorganized into a receiving node group. In this way, the transmission of status information can be restored through interaction between different receiving nodes and the storage.

[0098] For example, there are three receiving node groups, such as receiving node group 1-receiving node group 3. Among them, receiving node group 1 includes receiving nodes 1-receiving node 3, receiving node group 2 includes receiving nodes 4-receiving node 6, and receiving node group 3 includes receiving nodes 7-receiving node 8. Receiving node group 1 can receive the status information of parallel chain 1. If receiving node 2 in receiving node group 1 fails, that is, receiving node 2 causes the transmission of the status information of parallel chain 1 to be interrupted. The control node reschedules each receiving node. For example, the control node schedules receiving node 5, receiving node 6 and receiving node 8 to form a new receiving node group 1. In this way, the status information of parallel chain 1 can be transmitted through receiving node 5, receiving node 6 or receiving node 8 in the new receiving node group to restore the transmission of the status information of parallel chain 1.

[0099] If the control node fails to restore the state of the parachain after multiple dispatches, the possibility of a receiving node group failure can be ruled out. For example, the control node may assume that the parachain failed to submit or refused to submit state information. In this case, the control node can mark the parachain that failed to transmit state information.

[0100] The following describes the process of transmitting the status information of the parallel chain and the process of the control node scheduling the receiving node in conjunction with Figures 5 and 6 respectively.

[0101] Please refer to Figure 5, which is a schematic diagram of the process of transmitting the state information of the parallel chain provided in an embodiment of the present application. Figure 5 takes the process executed by the first block management node, the first receiving node, the first memory and the control node as an example. If there are multiple block management nodes and multiple receiving node groups, the execution steps of each block management node are the same, and the execution steps of each receiving node group are the same. Among them, the first receiving node initially belongs to the first receiving node group. The method includes:

[0102] Step 501: A first receiving node and a first storage establish a connection and authenticate each other based on the identity blockchain.

[0103] The first receiving node can search for a memory that has joined the blockchain system, such as the first memory. After that, the first receiving node and the first memory can authenticate each other based on the authorization information of each receiving node and the memory included in the identity blockchain obtained from the control node. If the first receiving node successfully verifies the identity of the first memory, the first receiving node can request to establish a connection with the first memory. The first memory verifies the identity of the first receiving node and establishes a connection with the first receiving node. It should be noted that, similar to the first receiving node, each receiving node in a receiving node group can search for the memory of the corresponding parallel chain and authenticate each other with the searched memory. Subsequently, after the identity authentication is successful, the receiving node and the memory can establish a connection.

[0104] Step 502: The first storage submits the status information of the first parallel chain to the first receiving node. Correspondingly, the first receiving node receives the status information of the first parallel chain from the first storage.

[0105] The first storage device collects and stores the status information of the corresponding parallel chain (e.g., the first parallel chain), that is, the parallel chain block information. The first storage device can send the status information of the first parallel chain to any receiving node (e.g., the first receiving node) in the receiving node group corresponding to the first parallel chain. The first storage device can submit the acquired status information of the first parallel chain to the first receiving node before the reporting time of the status information of the first parallel chain specified in the cross-chain contract. In this case, the status information of the first parallel chain submitted by the first storage device can be considered as the latest status information of the first parallel chain.

[0106] Step 503: The first receiving node broadcasts the status information of the first parallel chain.

[0107] After the first receiving node obtains the status information of the first parachain from the first storage, it verifies the correctness of the status information based on the block header of the first parachain. For the status information that passes the verification, the receiving node can repackage / pack the status information. For example, the first receiving node can use the Merkle Mountain data structure to encapsulate and co-sign the status information of the first parachain to generate a block header data packet, which includes the status information of the first parachain. The first receiving node then broadcasts the status information of the first parachain to the first block management node. It should be noted that the receiving nodes within a receiving node group can communicate with each other. In a possible implementation, after the first receiving node obtains the status information of the first parachain from the first storage, it can send it to the second receiving node within the first receiving node group, and the second receiving node will broadcast the status information of the first parachain. When a receiving node broadcasts the status information of a parachain, it can also be understood that the receiving node group to which the receiving node belongs broadcasts the status information of the parachain.

[0108] Step 504: The first block management node records the status information of the first parallel chain in the relay chain.

[0109] The first block manager node can receive parachain status information broadcasted by multiple receiving node groups. Each receiving node group corresponds to one parachain, and the first block manager node can obtain the status information of at least one parachain. The first block manager node can record the obtained status information of at least one parachain on the relay chain, so that any node in the blockchain network can obtain the status information of at least one parachain from the relay chain.

[0110] Step 505: The first block management node publishes the relay chain to each node in the blockchain network.

[0111] The first block manager can publish the maintained relay chain to each node in the blockchain network, so that each node can obtain relevant information from the relay chain. For example, different parachains can query the relay chain to obtain each other's status information, thereby achieving cross-chain information transmission.

[0112] Please refer to Figure 6, which is a schematic diagram of the control process of the control node provided in an embodiment of the present application. Figure 6 takes the process executed by the first block management node, the first receiving node group, the first memory, and the control node as an example. If there are multiple block management nodes and multiple receiving node groups, the execution steps of each block management node are the same, and the execution steps of each receiving node group are the same. Among them, the first receiving node initially belongs to the first receiving node group. The method includes:

[0113] Step 601: The control node generates a first scheduling instruction and publishes an identity blockchain, where the identity blockchain includes the first scheduling instruction, where the first scheduling instruction is used to group multiple receiving nodes.

[0114] The control node can group multiple receiving nodes. For example, the control node can send a first scheduling instruction to each receiving node via the identity blockchain. Each receiving node receives the first scheduling instruction and determines its own group based on the first scheduling instruction. For example, the first receiving node is assigned to the first receiving node group.

[0115] Step 602: The control node generates a second scheduling instruction and publishes an identity blockchain, where the identity blockchain includes the second scheduling instruction, and the second scheduling instruction is used to regroup the first receiving node group.

[0116] The control node can regroup the receiving node group that has been interrupted, or the control node can regroup multiple receiving node groups. For example, if the control node determines that the status information of one or more parallel chains has failed to be transmitted, the control node can regroup multiple receiving nodes. For example, the control node can periodically query whether the status information of each parallel chain is recorded in the relay chain within the time specified in the cross-chain contract. If the status information of a parallel chain is not recorded in the relay chain within the time specified in the cross-chain contract, then it is considered that the status information transmission of the parallel chain has been interrupted. In this case, the control node can regroup multiple receiving nodes.

[0117] For a parallel chain where the state information transmission is interrupted, the control node can generate a new scheduling instruction, which can be used to reorganize the receiving node group corresponding to the parallel chain. Taking the interruption of the state information of the first parallel chain as an example, the control node can regroup the first receiving node group. For example, the control node can generate a second scheduling instruction, and the second scheduling instruction is used to regroup the first receiving node group. The control node records the second scheduling instruction in the identity blockchain, and the control node broadcasts the identity blockchain. Each receiving node can obtain the identity blockchain and can determine its own group based on the second scheduling instruction. For example, the second scheduling instruction indicates that the first receiving node belongs to the second receiving node group. The first receiving node receives the second scheduling instruction to determine that the first receiving node has changed from the original first receiving node group to the second receiving node group.

[0118] Step 603: The first receiving node determines the second memory according to the second scheduling instruction and establishes a connection with the second memory.

[0119] The original first receiving node group corresponds to the parallel chain where the state information transmission is interrupted. The second scheduling instruction causes the receiving nodes included in the original first receiving node group to change. After the original first receiving node group receives the second scheduling instruction, the receiving nodes included are determined according to the second scheduling instruction to form a reorganized / updated first receiving node group. The reorganized / updated first receiving node group searches for the memory of the corresponding parallel chain, that is, the first memory. Afterwards, each receiving node in the reorganized / updated first receiving node group performs mutual authentication with the first memory. After the authentication is passed, the reorganized first receiving node group establishes a connection with the first memory.

[0120] The first receiving node may be reassigned to the second receiving node group and can re-search the corresponding parallel chain's storage (e.g., the second storage). Afterwards, each receiving node in the second receiving node group performs mutual authentication with the second storage. After the authentication is successful, the second receiving node group establishes a connection with the second storage.

[0121] By scheduling the interrupted receiving node group through the control node, the control node can attempt to restore the interrupted state information transmission through interaction between different receiving nodes and the storage. If the control node's repeated scheduling still fails to restore the parachain's state information transmission, the possibility of receiving node group failure can be ruled out. For example, the control node may assume that the parachain has failed to submit or refused to submit state information. In this case, the control node can mark the parachain that failed to transmit state information. This marking can promptly identify the faulty parachain and prevent the parachain from unilaterally terminating state information, which may lead to the failure of cross-chain transactions.

[0122] In this embodiment of the present application, a time limit is set for parachains to report status information. This allows parachains to report status information within a limited timeframe. The state information of each parachain recorded on the relay chain is up-to-date, reducing the latency of cross-chain transactions. If the relay chain fails to obtain the status information of a parachain within the specified timeframe, the transmission of the status information is considered interrupted. The control node can schedule other receiving nodes to interact with the parachain to resume the transmission of the status information.

[0123] In the embodiments provided by the present application, the method provided by the embodiment of the present application is introduced from the perspective of the interaction between the control node, the block management node, the receiving node and the memory. In order to implement the various functions in the method provided by the above-mentioned embodiment of the present application, the terminal device and the network device may include a hardware structure and / or a software module to implement the above-mentioned functions in the form of a hardware structure, a software module, or a hardware structure plus a software module. Whether a function of the above-mentioned functions is executed in the form of a hardware structure, a software module, or a hardware structure plus a software module depends on the specific application and design constraints of the technical solution.

[0124] For example, embodiments of the present application further provide a node 700. This node 700 can implement the functions of a control node, a first receiving node, or a first block management node in one or more of Figures 4-6 . As shown in Figure 7 , this node 700 includes a processing module 701 and a transceiver module 702. Optionally, this node 700 may also include a storage module, which is not shown in Figure 7 .

[0125] For example, node 700 implements the functionality of the control node in one or more of Figures 4-6 . Processing module 701 is used to determine a cross-chain contract, which includes time information indicating the time at which the status information of at least one parachain is reported, where a parachain is a blockchain connected to a receiving node group. Transceiver module 702 is used to broadcast the cross-chain contract.

[0126] As an optional implementation, the time information includes a single time, or the time information includes multiple times, each time corresponding to one or more parachains. Alternatively, the time information indicates a single time, or the time information indicates multiple times, each of which indicates a reporting time for status information of one or more parachains.

[0127] As an optional implementation method, the transceiver module 702 is also used to receive information of at least one parallel chain; the processing module 701 is specifically used to determine the cross-chain contract based on the information of at least one parallel chain.

[0128] As an optional implementation, the transceiver module 702 is further used to: broadcast a first scheduling instruction, where the first scheduling instruction is used to group receiving nodes in the blockchain system.

[0129] As an optional implementation method, the processing module 701 is used to determine that the status information on the relay chain does not include the status information of the first parallel chain, and the reporting time of the status information on the relay chain satisfies the cross-chain contract; the transceiver module 702 is used to broadcast the second scheduling instruction, and the second scheduling instruction is used to regroup the receiving node group corresponding to the first parallel chain.

[0130] As an optional implementation method, the transceiver module 702 is also used to receive an admission application sent by the first receiving node, which admission application is used to request to join the relay chain system; the processing module 701 is also used to allow the first receiving node to join the relay chain system and record the authorization information of the first receiving node.

[0131] As an optional implementation method, the transceiver module 702 is further used to receive an admission application sent by the first block management node, which is used to request to join the relay chain system; the processing module 701 is further used to allow the first block management node to join the relay chain system and record the authorization information of the first block management node.

[0132] For example, node 700 implements the functionality of the block management node in one or more of Figures 4-6. Transceiver module 702 is configured to receive a cross-chain contract from a control node and receive status information of multiple parachains, wherein the cross-chain contract includes time information indicating the reporting time of the status information of at least one parachain, where a parachain is a blockchain connected to a receiving node group. Processing module 701 is configured to record the status information of at least one parachain to the relay chain, where the reporting time of the status information of the at least one parachain satisfies the cross-chain contract. Transceiver module 702 is also configured to broadcast the relay chain.

[0133] As an optional implementation method, the transceiver module 702 is also used to: send an admission application to the control node, the admission application is used to request to join the relay chain system; receive authorization information sent by the control node to allow node 700 to join the relay chain system.

[0134] For example, node 700 implements the functionality of a receiving node in one or more of the aforementioned Figures 4-6. The transceiver module 702 is configured to receive a cross-chain contract from a control node, the cross-chain contract including time information indicating a reporting time for status information of at least one parachain, where a parachain is a blockchain connected to a receiving node group. The transceiver module 702 is configured to receive status information of a first parachain, where the first parachain is a blockchain connected to a first receiving node group to which the first receiving node belongs. The processing module 701 is configured to determine whether the submission time of the status information of the first parachain satisfies the time information included in the cross-chain contract. The transceiver module 702 is further configured to broadcast the status information corresponding to the first parachain.

[0135] As an optional implementation method, the transceiver module 702 is also used to: send an admission application to the control node, which admission application is used to request to join the relay chain system; receive the authorization information sent by the control node, the first receiving node allowing node 700 to join the relay chain system.

[0136] As an optional implementation method, the transceiver module 702 is also used to receive a first scheduling instruction broadcast by the control node, and the first scheduling instruction is used to group the receiving nodes in the blockchain system; the processing module 701 is also used to determine whether the first receiving node belongs to the first group of receiving nodes according to the first scheduling instruction.

[0137] As an optional implementation method, the transceiver module 702 is also used to receive a second scheduling instruction broadcast by the control node, and the second scheduling instruction is used to regroup the first receiving node group; the processing module 701 is also used to determine to establish a connection with the memory corresponding to the second receiving node group according to the second scheduling instruction, wherein the node 700 changes from originally belonging to the first receiving node group to belonging to the second receiving node group.

[0138] In the above description, the division of modules in node 700 is carried out from a functional perspective. In specific applications, the modules in node 700 can also be divided in other ways. The embodiment of the present application does not limit the division method of the modules. Regardless of the division method adopted, the node 700 always has the functions of the various modules mentioned above. The embodiment of the present application does not limit the specific form of each module in the node 700. Each module of the node 700 can exist in the form of software. For example, the processing module 701 can be an application deployed on the node 700, and the transceiver module 702 can be a microservice established on the data node 700. The specific forms of each module in the node 700 listed above are only examples.

[0139] The division of modules in the embodiments of the present application is illustrative and is merely a logical functional division. In actual implementation, other division methods may be used. Furthermore, the functional modules in the various embodiments of the present application may be integrated into a single processor, or may exist physically separately, or two or more modules may be integrated into a single module. The aforementioned integrated modules may be implemented in the form of hardware or software functional modules.

[0140] If the integrated module is implemented in the form of a software functional module and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of the present application is essentially or the part that contributes to the prior art or all or part of the technical solution can be embodied in the form of a software product. The computer software product is stored in a storage medium, including a number of instructions for enabling a terminal device (which can be a personal computer, mobile phone, or network device, etc.) or a processor to execute all or part of the steps of the method of each embodiment of the present application. The aforementioned storage medium includes: U disk, mobile hard disk, read-only memory (ROM), random access memory (RAM), magnetic disk or optical disk, etc., various media that can store program code.

[0141] The present application further provides a node 800 as shown in Figure 8. The node 800 includes a bus 801, a processor 802, a communication interface 803, and a memory 804. The processor 802, the memory 804, and the communication interface 803 communicate with each other via the bus 801.

[0142] Among them, the processor 802 can be a central processing unit (CPU). The memory 804 can include a volatile memory (volatile memory), such as a random access memory (RAM). The memory 804 can also include a non-volatile memory (non-volatile memory), such as a read-only memory (ROM), a flash memory, an HDD or an SSD. The memory stores executable code, and the processor 802 executes the method described in one or more of the above Figures 4 to 6. The memory 804 can also include software modules required for other running processes such as an operating system (such as multiple modules in the node 700, for example, the processing module 701 and / or the transceiver module 702). The operating system can be LINUX TM ,UNIX TM ,WINDOWS TM wait.

[0143] The present application also provides a system, comprising at least one node 800 as shown in FIG8 . The at least one node 800 in the computing device system communicates with each other via a communication path. The at least one node 800 in the system establishes communication with each other via a communication network, with each node 800 running any one or more modules in the node 700.

[0144] The descriptions of the processes corresponding to the above figures have different focuses. For parts that are not described in detail in a certain process, please refer to the relevant descriptions of other processes.

[0145] In the above embodiments, all or part of the embodiments may be implemented using software, hardware, firmware, or any combination thereof. When implemented using software, all or part of the embodiments may be implemented in the form of a computer program product. The computer program product includes computer program instructions that, when loaded and executed on a computer, fully or partially generate the processes or functions described in one or more of Figures 4 to 6 of the embodiments of the present invention.

[0146] The computer may be a general-purpose computer, a special-purpose computer, a computer network, or other programmable device. The computer instructions may be stored in a computer-readable storage medium or transmitted from one computer-readable storage medium to another computer-readable storage medium. For example, the computer instructions may be transmitted from one website, computer, server, or data center to another website, computer, server, or data center via a wired (e.g., coaxial cable, optical fiber, digital subscriber line, or wireless (e.g., infrared, wireless, microwave, etc.) method. The computer-readable storage medium may be any available medium that a computer can access or a data storage device such as a server or data center that includes one or more available media integrated therein. The available medium may be a magnetic medium (e.g., a floppy disk, a hard disk, a tape), an optical medium (e.g., a DVD), or a semiconductor medium (e.g., an SSD).

[0147] In the embodiments of the present application, the number of nouns, unless otherwise specified, means "singular noun or plural noun", that is, "one or more". "At least one" refers to one or more, "at least one group" refers to one or more groups, and "multiple" refers to two or more. "And / or" describes the association relationship of associated objects, indicating that three relationships may exist. For example, A and / or B can mean: A exists alone, A and B exist at the same time, and B exists alone, where A and B can be singular or plural. The character " / " generally indicates that the previous and next associated objects are in an "or" relationship. For example, A / B means: A or B. "At least one of the following items" or similar expressions refers to any combination of these items, including any combination of single items or plural items. For example, at least one of a, b, or c means: a, b, c, a and b, a and c, b and c, or a and b and c, where a, b, c can be single or multiple.

[0148] Obviously, those skilled in the art may make various modifications and variations to this application without departing from the scope of protection of this application. Thus, if these modifications and variations of this application fall within the scope of the claims of this application and their equivalents, this application is intended to include these modifications and variations.

Claims

1. A data processing method, characterized in that: The method is applied to a control node in a blockchain system, wherein the blockchain system further comprises at least one receiving node group, wherein a receiving node group comprises at least one receiving node, and wherein the method comprises: The control node determines a cross-chain contract, the cross-chain contract includes time information, and the time information indicates a reporting time of status information of at least one parallel chain, wherein one of the parallel chains is a blockchain that establishes a connection with a receiving node group; The control node broadcasts the cross-chain contract.

2. The method according to claim 1, characterized in that The time information indicates one time, or the time information indicates multiple times, and the multiple times respectively indicate the reporting time of status information of one or more parallel chains.

3. The method according to claim 1 or 2, characterized in that The control node determines the cross-chain contract, including: The control node receives information of at least one parallel chain; The control node determines the cross-chain contract based on the information of the at least one parallel chain.

4. The method according to claim 1 or 2, characterized in that: The method further comprises: The control node broadcasts a first scheduling instruction, where the first scheduling instruction is used to group receiving nodes in the blockchain system.

5. The method according to claim 4, characterized in that The method further comprises: The control node determines that the status information on the relay chain does not include the status information of the first parallel chain, and the reporting time of the status information of the relay chain satisfies the time information included in the cross-chain contract; The control node broadcasts a second scheduling instruction, and the second scheduling instruction is used to regroup the receiving node group corresponding to the first parallel chain.

6. The method according to any one of claims 1 to 5, characterized in that: The method further comprises: The control node receives an admission application sent by a first receiving node, where the admission application is used to request to join the relay chain system, and the first receiving node is any receiving node in the blockchain system; The control node allows the first receiving node to join the relay chain system and records the authorization information of the first receiving node.

7. The method according to any one of claims 1 to 6, characterized in that: The blockchain system further includes at least one block management node, and the block management node is used to manage the acquired state information of the parallel chain. The method further includes: The control node receives an admission application sent by a first block management node, where the admission application is used to request to join the relay chain system, and the first block management node belongs to the at least one block management node; The control node allows the first block management node to join the relay chain system and records the authorization information of the first block management node.

8. A data processing method, characterized in that: A block management node applied to a blockchain system, wherein the blockchain system further comprises a control node and at least one receiving node group, wherein a receiving node group comprises at least one receiving node, and the method comprises: The block management node receives a cross-chain contract from the control node, wherein the cross-chain contract includes time information, and the time information indicates a reporting time of status information of at least one parallel chain, wherein one parallel chain is a blockchain connected to a receiving node group; The block management node receives status information of multiple parallel chains reported by the at least one receiving node; The block management node sends the state information of at least one target parallel chain among the state information of the multiple parallel chains to The information is recorded in the relay chain and the relay chain is broadcast; wherein the reporting time of the status information of at least one target parallel chain satisfies the time information included in the cross-chain contract.

9. The method according to claim 8, characterized in that The method further comprises: The block management node sends an admission application to the control node, where the admission application is used to request to join the relay chain system; The block management node receives authorization information sent by the control node to allow the block management node to join the relay chain system.

10. A data processing method, characterized in that: Applied to any receiving node in a blockchain system, the blockchain system includes a control node and at least one receiving node group, one of the receiving node groups includes at least one of the receiving nodes, and the method includes: The receiving node receives a cross-chain contract from the control node, the cross-chain contract includes time information, the time information indicates a reporting time of status information of at least one parallel chain, and one of the parallel chains is a blockchain connected to a receiving node group; The receiving node receives status information of a first parallel chain, where the first parallel chain is a blockchain that has established a connection with a first receiving node group to which the receiving node belongs; If the state information of the first parallel chain satisfies the time information included in the cross-chain contract, the state information of the first parallel chain is broadcast.

11. The method according to claim 10, characterized in that The method further comprises: The receiving node sends an admission application to the control node, where the admission application is used to request to join the relay chain system; The receiving node receives authorization information sent by the control node to allow the first receiving node to join the relay chain system.

12. The method according to claim 10 or 11, characterized in that The method further comprises: The receiving node receives a first scheduling instruction broadcast by the control node, where the first scheduling instruction is used to group the receiving nodes in the blockchain system; The receiving node determines, according to the first scheduling instruction, that the first receiving node belongs to the first receiving node group.

13. The method according to claim 12, characterized in that The method further comprises: The receiving node receives a second scheduling instruction broadcast by the control node, where the second scheduling instruction is used to regroup the receiving node group; The receiving node determines to establish a connection with a memory corresponding to a second receiving node group according to the second scheduling instruction, wherein the receiving node changes from originally belonging to the first receiving node group to belonging to the second receiving node group.

14. A node, characterized in that: The node is deployed in a blockchain system, and the blockchain system further includes at least one receiving node group, and a receiving node group includes at least one receiving node, and the node includes: A processing module, configured to determine a cross-chain contract, wherein the cross-chain contract includes time information, and the time information indicates a reporting time of status information of at least one parallel chain, wherein one of the parallel chains is a blockchain connected to a receiving node group; The transceiver module is used to broadcast the cross-chain contract.

15. The node according to claim 14, characterized in that The time information indicates one time, or the time information indicates multiple times, and the multiple times respectively indicate the reporting time of status information of one or more parallel chains.

16. The node according to claim 14 or 15, characterized in that The transceiver module is also used to receive information of at least one parallel chain; The processing module is specifically used to determine the cross-chain contract based on the information of the at least one parallel chain.

17. The node according to claim 14 or 15, characterized in that The transceiver module is also used for: Broadcast a first scheduling instruction, where the first scheduling instruction is used to group receiving nodes in the blockchain system.

18. The node according to claim 17, characterized in that The processing module is used to determine that the status information on the relay chain does not include the status information of the first parallel chain, and the reporting time of the status information on the relay chain satisfies the time information included in the cross-chain contract; The transceiver module is also used to broadcast a second scheduling instruction, and the second scheduling instruction is used to regroup the receiving node group corresponding to the first parallel chain.

19. The node according to any one of claims 14 to 18, characterized in that: The transceiver module is further used to receive an admission application sent by a first receiving node, wherein the admission application is used to request to join the relay chain system, and the first receiving node belongs to at least one receiving node in the blockchain system; The processing module is further used to allow the first receiving node to join the relay chain system and record the authorization information of the first receiving node.

20. The node according to any one of claims 14 to 19, characterized in that: The blockchain system further includes at least one block management node, and the transceiver module is further used to receive an admission application sent by a first block management node, the admission application is used to request to join the relay chain system, and the first block management node belongs to the at least one block management node; The processing module is further used to allow the first block management node to join the relay chain system and record the authorization information of the first block management node.

21. A node, characterized in that: The node is deployed in a blockchain system, the blockchain system further includes a control node and at least one receiving node group, a receiving node group includes at least one receiving node, and the node includes a processing module and a transceiver module; The transceiver module is used to receive a cross-chain contract from the control node, and receive status information of multiple parallel chains, wherein the cross-chain contract includes time information, and the time information indicates the reporting time of the status information of at least one parallel chain, and one of the parallel chains is a blockchain connected to a receiving node group; The processing module is used to record the status information of at least one parallel chain to the relay chain, and the reporting time of the status information of at least one parallel chain meets the cross-chain contract; The transceiver module is also used to broadcast the relay chain.

22. The node according to claim 21, characterized in that The transceiver module is also used for: Sending an admission application to the control node, wherein the admission application is used to request to join the relay chain system; Receive authorization information sent by the control node to allow the first block management node to join the relay chain system.

23. A node, characterized in that: The node is deployed in a blockchain system, the blockchain system further includes a control node, the node belongs to a first receiving node group, and the node includes a processing module and a transceiver module; The transceiver module is used to receive a cross-chain contract from the control node, wherein the cross-chain contract includes time information, and the time information indicates a reporting time of status information of at least one parallel chain, wherein one parallel chain is a blockchain connected to a receiving node group; The processing module is used for status information of a first parallel chain, where the first parallel chain is the state information of the first parallel chain to which the receiving node belongs. The first receiving node group establishes a connected blockchain; The transceiver module is also used to broadcast the status information of the first parallel chain when the status information of the first parallel chain meets the time information included in the cross-chain contract.

24. The node according to claim 23, characterized in that The transceiver module is also used for: Sending an admission application to the control node, wherein the admission application is used to request to join the relay chain system; Receive authorization information sent by the control node to allow the first receiving node to join the relay chain system.

25. The node according to claim 23 or 24, characterized in that The transceiver module is also used to receive a first scheduling instruction broadcast by the control node, where the first scheduling instruction is used to group receiving nodes in the blockchain system; The processing module is further configured to determine, according to the first scheduling instruction, that the first receiving node belongs to the first group of receiving nodes.

26. The node according to claim 25, characterized in that The transceiver module is further used to receive a second scheduling instruction broadcast by the control node, where the second scheduling instruction is used to regroup the first receiving node group; The processing module is further configured to determine, according to the second scheduling instruction, to establish a connection with a memory corresponding to a second receiving node group, wherein the node originally belongs to the first receiving node group and changes to the second receiving node group.

27. A blockchain system, characterized in that: The blockchain system includes a control node, at least one receiving node group and at least one block management node, and a receiving node group includes at least one receiving node; The control node is used to perform the method according to any one of claims 1 to 7; Any one of the at least one receiving node is configured to execute the method according to claim 8 or 9; Any one of the at least one block management node is used to execute the method according to any one of claims 10 to 13.

28. A node, characterized in that: The node includes a processor and a memory; The memory is used to store computer program instructions; The processor is configured to call and execute computer program instructions in the memory so that the method according to any one of claims 1 to 13 is implemented.

29. A computer-readable storage medium, characterized in that: The computer-readable storage medium stores computer program instructions, and when the computer program instructions are executed by a computing device, the method according to any one of claims 1 to 13 is implemented.

Images