Block chain architecture based on main-sub chain consensus inheritance and data processing method and device

Abstract

The invention relates to a block chain architecture based on main and sub-chain consensus inheritance and a data processing method and device, and the block chain architecture comprises a main chain which is a main block chain network; and the at least one sub-chain is a sub-block chain network. The main chain is configured with a sub-chain management contract, and a consensus node list obtained based on a main chain election mechanism is inherited to the sub-chain for use based on the sub-chain management contract. Mutually independent service execution environments exist among the sub-chains and support independent processing of corresponding services; each sub-chain is configured with a corresponding sub-chain business processing contract, transaction of the corresponding business and consensus processing in the sub-chain are carried out based on the sub-chain business processing contract, a consensus node object in the sub-chain is determined according to a consensus node list inherited from the main chain, and the consensus processing in the sub-chain is executed based on the consensus node object. The parallel processing capability of the system is improved on the whole, high-concurrency traffic is effectively faced, and the safety and expandability of the system are improved at the same time.

Description

Technical Field

[0001] The present disclosure relates to the field of blockchain technology, and in particular to a blockchain architecture, data processing method, and device based on master-subchain consensus inheritance. Background Art

[0002] Due to its advantages of decentralization and transaction traceability, blockchain technology holds broad application prospects in various scenarios, including financial payments and transactions, data security, digital asset storage, copyright storage and protection, provenance traceability, and chain tracking (e.g., evidence chain tracking and logistics tracking). With the massive explosion in user numbers, the diversification of business needs, and the increasing complexity of various businesses, single-chain architectures for data storage and processing based on a blockchain system (or blockchain network) face challenges such as low throughput, long confirmation times, and poor system scalability, making it difficult to meet diverse business needs and large-scale concurrent processing. Related technologies have proposed multi-chain blockchain architectures, which utilize the collaborative work of multiple blockchains to improve system scalability and interoperability.

[0003] However, in the process of realizing the concept of the present disclosure, the inventors found that the multi-chain architecture in the related technology has at least the following technical problems: the interaction between the main chain and the sub-chain is mainly to realize cross-chain business, and actually multiple sub-chains collaborate to process business. Since cross-chain interaction relies on a centralized relay mechanism, a transferor role is required (for example, the main chain or other chains assume the corresponding role), which becomes a bottleneck in system performance and is difficult to support high-concurrency scenarios; some solutions use sharding technology to improve parallel processing capabilities, but current sharding transactions require multiple verifications and frequent state synchronization, which significantly increases latency, and the consensus mechanism of the main chain and the sub-chain is separated (for example, the main chain adopts the PoS consensus mechanism and the sub-chain adopts the BFT (Byzantine) consensus mechanism), which makes it difficult to uniformly guarantee overall security and increases systemic risks. Summary of the Invention

[0004] In order to solve the above technical problems or at least partially solve the above technical problems, the embodiments of the present disclosure provide a blockchain architecture, a data processing method and a device based on master-child chain consensus inheritance.

[0005] In a first aspect, an embodiment of the present disclosure provides a blockchain architecture based on main-chain and sub-chain consensus inheritance. The above-mentioned blockchain architecture includes: a main chain, which is a main blockchain network; and at least one sub-chain, which is a sub-blockchain network. The above-mentioned main chain is configured with a sub-chain management contract, and based on the above-mentioned sub-chain management contract, the consensus node list obtained based on the main chain election mechanism is inherited to the sub-chain for adoption. Each sub-chain has an independent business execution environment and supports independent processing of corresponding businesses; each sub-chain is configured with a corresponding sub-chain business processing contract, and the transactions of the corresponding business and the consensus processing within the sub-chain are carried out based on the above-mentioned sub-chain business processing contract, wherein the consensus node object in the sub-chain is determined according to the consensus node list inherited from the main chain, and the consensus processing within the sub-chain is performed based on the above-mentioned consensus node object.

[0006] In some embodiments, the main chain includes multiple first nodes, the sub-chain includes multiple second nodes, and a mapping relationship exists between a first node account corresponding to the first node and a second node account corresponding to the second node. Determining a consensus node object in the sub-chain based on the consensus node list inherited from the main chain includes: mapping the first consensus node account in the consensus node list inherited from the main chain with the mapping relationship to obtain a second consensus node account in the sub-chain corresponding to the first consensus node account; and determining the consensus node corresponding to the second consensus node account in the sub-chain as the consensus node object.

[0007] In some embodiments, the main chain consensus mechanism corresponding to the above main chain and the sub-chain consensus mechanism corresponding to the above sub-chain are independent of each other, and the sub-chain consensus mechanisms corresponding to each sub-chain are also independent of each other.

[0008] In some embodiments, the consensus node list obtained by the main chain election is dynamically updated over time. During the transaction processing of the corresponding business in the target sub-chain based on the corresponding sub-chain business processing contract, after the consensus condition is triggered, a query request is initiated to the sub-chain management contract in the main chain based on a preset interface. The query request is used to query the latest configuration information of the target sub-chain, which includes the latest consensus node list. The target sub-chain determines the target consensus node object based on the latest consensus node list obtained by the query and performs the sub-chain consensus processing based on the target consensus node object.

[0009] In some embodiments, the blockchain architecture further includes: the main chain performs lifecycle management of the subchain based on the subchain management contract, and the lifecycle management includes executing at least one of the following preset action instructions on the subchain: a creation instruction, an exit instruction, a rejoining instruction after exit, or a termination instruction. The main chain receives a proposal transaction request for creating, exiting, rejoining after exiting, or terminating a subchain based on the subchain management contract; the main chain performs consensus voting on the proposal transaction request for creating, exiting, rejoining after exiting, or terminating a subchain based on the administrator node corresponding to the queried contract administrator list, and obtains a proposal transaction processing result; wherein, the contract administrator list adopts a consensus node list by default, and dynamically updates the corresponding contract administrator list after the member update request for the contract administrator to apply for joining or exit is elected based on the voting admission and admission mechanism in the main chain; the main chain updates the configuration information of the corresponding subchain based on the proposal transaction processing result; wherein the update process covers at least one of adding, clearing, or synchronizing the latest information of the consensus node list in the clear state.

[0010] In some embodiments, the updating includes at least one of the following: In response to the above creation instruction, the proposal transaction request carries: the initial configuration information of the subchain to be created; in response to the proposal transaction processing result indicating that the proposal transaction for creating the subchain is approved, the consensus node list obtained based on the main chain election mechanism is added to the initial configuration information of the subchain to be created, thereby obtaining the target configuration information of the subchain to be created; In response to the proposal transaction processing result indicating that the proposal transaction to exit the subchain is approved, the consensus node list in the target configuration information of the subchain to be exited is cleared, so that the subchain to be exited cannot conduct new transactions but supports historical transaction queries; In response to the proposal transaction processing result indicating that the proposal transaction to rejoin the subchain after exiting is approved, the consensus node list in the target configuration information of rejoining the subchain after exiting is restored from the cleared state to be synchronized with the current main chain election result, so that new transactions can be carried out in the subchain after rejoining; In response to the proposal transaction processing result indicating that the proposal transaction to terminate the sub-chain is passed, the target configuration information of the sub-chain to be terminated is cleared and the state of the sub-chain to be terminated is set to a disabled state.

[0011] In some embodiments, if the proposal transaction processing result indicates that the proposal transaction is approved, the proposal transaction-related information and target configuration information of the subchain are stored in the subchain management contract. During the process of running the newly created subchain on the target device, the subchain management contract in the main chain is called to query the corresponding target configuration information; a configuration file corresponding to the newly created subchain node is generated locally on the target device based on the target configuration information; and the node is started and configured on the target device based on the configuration file to complete the deployment and operation of the newly created subchain node.

[0012] In some embodiments, the above-mentioned blockchain architecture also includes: during the operation of the sub-chain node, after the sub-chain node receives the first configuration information update instruction locally, the sub-chain configuration information in the main chain is synchronously updated by calling the sub-chain management contract, and the above-mentioned first configuration information does not contain a consensus node list.

[0013] The consensus node list obtained by the main chain election is dynamically updated over time. During the operation of the sub-chain node, the latest consensus node list in the sub-chain configuration information is queried from the sub-chain management contract based on at least one of the following methods: Based on the preset period, query the latest consensus node list in the subchain configuration information from the subchain management contract; or, Receive updates from the main chain regarding the consensus node list in the subchain configuration information; or, After the subchain triggers the consensus condition, the latest consensus node list in the subchain configuration information is queried from the subchain management contract.

[0014] In some embodiments, the main chain and the sub-chain are deployed independently of each other, and their respective ledger data are isolated. After the consensus condition is triggered in the main chain, the latest sub-chain status is obtained from the sub-chain. After obtaining the latest sub-chain status of all sub-chains, the sub-chain status in the sub-chain management contract is updated according to the latest sub-chain status of all sub-chains, and the main chain consensus processing is performed during or after the sub-chain status update. Specifically, when the processing scenario of the main chain triggering the consensus condition is unrelated to the sub-chain status, the main chain performs transactions and main chain consensus processing for the corresponding processing scenario based on the main chain business processing contract, and can perform main chain consensus processing during or after the sub-chain status update; when the processing scenario of the main chain triggering the consensus condition is related to the sub-chain status, the main chain performs transactions and main chain consensus processing for the corresponding processing scenario based on the main chain business processing contract, and performs main chain consensus processing after the sub-chain status is updated.

[0015] In a second aspect, an embodiment of the present disclosure provides a data processing device. The above-mentioned device is a node in the main blockchain network, and the above-mentioned main blockchain network is configured with a sub-chain management contract. The above-mentioned device includes: an election module, a first consensus inheritance module and a sub-chain management module. The above-mentioned election module is used to interact with other nodes in the main blockchain network and obtain a consensus node list based on the main chain election mechanism. The above-mentioned first consensus inheritance module is used to inherit the above-mentioned consensus node list to the sub-chain for adoption based on the above-mentioned sub-chain management contract; wherein, the above-mentioned sub-chain is a sub-blockchain network, and when the sub-chain performs independent processing of the corresponding business, the consensus node object in the sub-chain is determined according to the consensus node list inherited from the main chain, and the consensus processing within the sub-chain is performed based on the above-mentioned consensus node object. The above-mentioned sub-chain management module is used to perform life cycle management of the sub-chain based on the above-mentioned sub-chain management contract.

[0016] In a third aspect, embodiments of the present disclosure provide a data processing device. This device is a node in a sub-blockchain network and includes a second consensus inheritance module and a data processing module. The second consensus inheritance module is used to obtain a consensus node list; this consensus node list is obtained from the main blockchain network based on the main chain election mechanism. The data processing module is used to perform corresponding business transactions and sub-chain consensus processing based on the corresponding sub-chain business processing contract. The data processing module determines the consensus node objects in the sub-chain based on the consensus node list inherited from the main chain, and performs sub-chain consensus processing based on these consensus node objects.

[0017] In a fourth aspect, embodiments of the present disclosure provide a data processing method for a blockchain architecture based on the embodiment of the first aspect. The method comprises: a target subchain receives a data processing request for a corresponding business, or a main chain receives a data processing request for a subchain business and forwards it to the corresponding target subchain; the target subchain performs transactions for the corresponding business and performs intra-subchain consensus processing based on the corresponding subchain business processing contract, wherein the consensus node object in the subchain is determined based on the consensus node list inherited from the main chain, and the intra-subchain consensus processing is performed based on the consensus node object.

[0018] The above technical solutions provided by the embodiments of the present disclosure have at least some or all of the following advantages: By setting up a main chain to manage the sub-chains, each sub-chain has an independent business execution environment and supports the independent processing of its own corresponding business. At the same time, consensus inheritance is carried out between the main chain and the sub-chain, which helps to improve the system's high concurrent processing capabilities and security as a whole; specifically, by obtaining a consensus node list based on the main chain election mechanism in the main chain, and inheriting the above consensus node list to the sub-chain through the sub-chain management contract, since the credibility of the consensus nodes given by the election results in the main chain is very high, regardless of whether the consensus mechanisms corresponding to the main chain and the sub-chain are the same, this application can ensure the consistency and reliability of the election results corresponding to the main chain and the sub-chain by setting up a consensus inheritance mechanism in which the sub-chain inherits the main chain's election results on the consensus node list from the main chain, thereby avoiding the sub-chain confirming based on its own independent internal election mechanism. The security risks caused by determining another set of node lists for consensus verification in the sub-chain (which may be less reliable), while the sub-chain saves the resources required for the corresponding election and inherits the consensus node identity consistent with the main chain to participate in consensus verification, and the reliability of the processing results is improved; moreover, when a sub-chain performs transactions and sub-chain consensus processing for the corresponding business based on the corresponding sub-chain business processing contract, it does not need to interact with other sub-chains and can realize data processing within the same sub-chain. Multiple sub-chains can process multiple businesses in parallel or different tasks or different sub-tasks of the same business in parallel; at the same time, the need to add new sub-chains or terminate existing sub-chains can also be uniformly managed by the main chain based on the sub-chain management contract, which is flexible in expansion and control, and improves the system's parallel processing capabilities as a whole, effectively copes with high concurrent traffic, and improves system security and scalability. BRIEF DESCRIPTION OF THE DRAWINGS

[0019] The accompanying drawings, which are incorporated in and constitute a part of this specification, illustrate embodiments consistent with the present disclosure and, together with the description, serve to explain the principles of the present disclosure.

[0020] In order to more clearly illustrate the embodiments of the present disclosure or the technical solutions in the prior art, the following briefly introduces the drawings required for use in the embodiments or related technical descriptions. Obviously, for ordinary technicians in this field, other drawings can be obtained based on these drawings without any creative work.

[0021] Figure 1 The following schematically illustrates a block diagram of a blockchain architecture based on master-subchain consensus inheritance according to an embodiment of the present disclosure. Figure 2 Schematically illustrates a process of managing subchains, obtaining a consensus node list through mainchain election, and inheriting the consensus node list between the mainchain and subchains in a blockchain architecture based on mainchain-subchain consensus inheritance according to an embodiment of the present disclosure; Figure 3The following schematically illustrates a process of selecting consensus nodes to obtain a consensus node list and transferring the consensus node list between the main chain and the sub-chain in a blockchain architecture based on main-chain and sub-chain consensus inheritance according to an embodiment of the present disclosure; Figure 4 The figure schematically shows the ledger distribution of a blockchain architecture based on master-child chain consensus inheritance according to an embodiment of the present disclosure; Figure 5 The following schematically illustrates the process of obtaining the subchain status from the subchain and synchronizing it to the subchain management contract before the main chain generates a block in a blockchain architecture based on main-subchain consensus inheritance according to an embodiment of the present disclosure; Figure 6 The following schematically illustrates a subchain creation process in which a main chain performs lifecycle management on a subchain in a blockchain architecture based on main-subchain consensus inheritance according to an embodiment of the present disclosure; Figure 7 Schematically illustrates a process diagram of a subchain updating first configuration information in which a main chain performs lifecycle management on a subchain in a blockchain architecture based on main-subchain consensus inheritance according to an embodiment of the present disclosure; Figure 8 The following schematically illustrates a subchain exit process in which a main chain performs lifecycle management on a subchain in a blockchain architecture based on main-subchain consensus inheritance according to an embodiment of the present disclosure; Figure 9 A block diagram schematically illustrates a structure of a data processing device according to an embodiment of the present disclosure; and Figure 10 The figure schematically shows a structural block diagram of a data processing device according to another embodiment of the present disclosure. DETAILED DESCRIPTION

[0022] With the massive explosion in user numbers, the diversification of business needs, and the increasing complexity of various businesses, single-chain architectures for data storage and processing based on a blockchain system (or blockchain network) face challenges such as low throughput, long confirmation times, and poor system scalability, making it difficult to meet diverse business needs and large-scale concurrent processing. For example, single-chain architectures process all transactions through a single main chain, requiring the use of global consensus mechanisms (such as PoW (Proof of Work) and PoS (Proof of Stake)) for multi-node consensus verification. However, the same architecture is not suitable for complex businesses requiring different storage formats, asset types, and detailed processing logic, thus limiting single-chain performance. Related technologies have proposed multi-chain blockchain architectures, which improve system scalability and interoperability through the collaborative work of multiple blockchains.

[0023] However, during research and development, we discovered that the multi-chain architectures employed in related technologies present at least the following technical issues: The interaction between the main chain and sub-chains primarily facilitates cross-chain transactions, but in reality involves collaborative processing between multiple sub-chains. Because cross-chain interactions rely on a centralized relay mechanism, requiring an intermediary (e.g., the main chain or another chain) to perform the corresponding role, this presents a performance bottleneck and makes it difficult to support high-concurrency scenarios. Some solutions employ sharding technology to enhance parallel processing capabilities, but current sharded transactions require multiple verifications and frequent state synchronization, significantly increasing latency. Furthermore, the separation of the main chain and sub-chain consensus mechanisms (e.g., the main chain uses PoS consensus and the sub-chain uses BFT (Byzantine) consensus) makes it difficult to uniformly guarantee overall security, increasing systemic risk. For example, in some cases, the sub-chain may not support the consensus mechanism supported by the main chain. Consequently, the main chain and sub-chain may use different consensus mechanisms. In some cases, the reliability of the sub-chain consensus mechanism may be unpredictable or low, leading to unreliable computation results and, consequently, systemic risk in the main-sub-chain architecture.

[0024] In view of this, the embodiments of the present disclosure provide a blockchain architecture, data processing method, and device based on master-subchain consensus inheritance. By setting up a master chain to manage subchains, each subchain has an independent business execution environment and supports the independent processing of its corresponding business. At the same time, consensus inheritance is carried out between the main chain and subchains, which helps to improve the system's high-concurrency processing capabilities and security as a whole. By setting up a subchain management contract, the need to add new subchains, terminate existing subchains, etc. can also be uniformly managed by the main chain based on the subchain management contract. At the same time, the consensus inheritance function is implemented based on the subchain management contract, which improves the system's parallel processing capabilities as a whole, effectively copes with high concurrent traffic, and improves system security and scalability.

[0025] To make the objectives, technical solutions, and advantages of the embodiments of the present disclosure more clear, the technical solutions in the embodiments of the present disclosure will be clearly and completely described below in conjunction with the accompanying drawings. Obviously, the described embodiments are part of the embodiments of the present disclosure, not all of the embodiments. All other embodiments obtained by ordinary technicians in this field based on the embodiments of the present disclosure without making any creative efforts shall fall within the scope of protection of the present disclosure.

[0026] The first exemplary embodiment of the present disclosure provides a blockchain architecture based on master-child chain consensus inheritance.

[0027] Figure 1 The structural block diagram of the blockchain architecture based on master-child chain consensus inheritance according to one embodiment of the present disclosure is schematically shown. Figure 2Schematically illustrates a process of managing subchains, obtaining a consensus node list through mainchain election, and inheriting the consensus node list between the mainchain and subchains in a blockchain architecture based on mainchain-subchain consensus inheritance according to an embodiment of the present disclosure; Figure 3 The present invention schematically illustrates a process of electing consensus nodes based on a blockchain architecture with main-chain and sub-chain consensus inheritance to obtain a consensus node list, and transmitting the consensus node list between the main chain and the sub-chain in accordance with an embodiment of the present invention.

[0028] Combine Figures 1 to 3 As shown in the process shown in ① and ②, the blockchain architecture 100 based on the main-subchain consensus inheritance includes: a main chain 110, which is a main blockchain network; at least one subchain 120, which is a sub-blockchain network, such as Figure 2 In the figure, N subchains are shown, where N is a positive integer. Figure 1 Two sub-chains are shown, namely the first sub-chain 121 and the second sub-chain 122. Figure 2 The leftmost side of the figure shows a main chain 110 and four sub-chains. In addition to the first sub-chain 121 and the second sub-chain 122, the third sub-chain 123 and the fourth sub-chain 124 are also shown. Figure 2 In the figure, small balls of different colors are used to indicate the blockchain nodes (referred to as nodes) contained in the main chain 110 and sub-chains 121-124, rectangular boxes are used to indicate block data, and rectangular boxes connected by arrows are used to indicate the block generation in a time sequence (before the blockchain actually implements accounting, a consensus algorithm will be used to select which node will generate a new block to initiate accounting, that is, obtain the accounting right. This process of generating a new block is called block generation). The corresponding time block structure of the consensus.

[0029] The main chain 110 is configured with a sub-chain management contract 111, based on which the consensus node list 101 (which can also be described as a consensus node pool) obtained based on the main chain election mechanism is inherited to the sub-chain 120 for adoption. Each sub-chain 120 has an independent business execution environment and supports independent processing of corresponding businesses; each sub-chain is configured with a corresponding sub-chain business processing contract, which performs transactions and sub-chain consensus processing based on the sub-chain business processing contract. The consensus node object in the sub-chain is determined based on the consensus node list inherited from the main chain, and the sub-chain consensus processing is performed based on the consensus node object. For example, Figure 2 The method of using multiple arrows pointing to the main chain and N sub-chains to indicate that the main chain and sub-chains share a set of consensus node lists, reflecting the consensus inheritance mechanism that obtains the consensus node list based on the main chain election mechanism and integrates it into the sub-chain to adopt this election result.

[0030] Reference Figure 1As shown, the main chain 110 includes multiple first nodes, such as nodes A1 to A5 as an example; the sub-chain includes multiple second nodes, such as the first sub-chain 121 includes multiple second nodes: B11 to B15, and the second sub-chain 122 includes multiple second nodes: B21 to B25.

[0031] The main chain 110 is configured with a main chain business processing contract TA, the first sub-chain 121 is configured with a sub-chain business processing contract TB1, and the second sub-chain 122 is configured with a sub-chain business processing contract TB2. The first sub-chain 121 and the second sub-chain 122 are used to process different businesses or to process different tasks or sub-tasks of the same business, etc.

[0032] During the operation of each node A1-A5 on the main chain 110, the main chain business processing contract TA can be called or deployed to process data for the corresponding business (for example, processing asset transactions between enterprises A and B within a certain park S1). During the operation of each node B11-B15 on the first sub-chain 121, the sub-chain business processing contract TB1 can be called or deployed to process data for the corresponding business (for example, storing enterprise data assets on-chain within a certain park S1). During the operation of each node B21-B25 on the second sub-chain 122, the sub-chain business processing contract TB2 can be called or deployed to process data for the corresponding business (for example, storing enterprise fixed equipment asset data on-chain within a certain park S1).

[0033] When a subchain (for example, the first subchain 121) conducts transactions and subchain consensus processing for the corresponding business based on the corresponding subchain business processing contract (for example, the subchain business processing contract TB1), data processing can be achieved within the same subchain without interacting with other subchains. Multiple subchains (for example, the first subchain 121 and the second subchain 122) can process multiple businesses in parallel or different tasks or subtasks of the same business in parallel, thereby improving the system's parallel processing capabilities and effectively handling high concurrent traffic.

[0034] In some embodiments, the mainchain consensus mechanism corresponding to the mainchain 110 and the subchain consensus mechanism corresponding to the subchain 120 are independent of each other, and the subchain consensus mechanisms corresponding to each subchain are also independent of each other. Mutual independence means that the mainchain consensus mechanism and the subchain consensus mechanism can be different or the same, and can be constructed based on the needs of their respective businesses. The subchain consensus mechanism corresponding to each subchain can be different or the same, and can be constructed based on the needs of their respective businesses.

[0035] In some exemplary scenarios, the main chain consensus mechanism corresponding to the main chain 110 includes a main chain election mechanism and a main chain consensus algorithm. Figure 1The main chain election mechanism and the main chain consensus algorithm are connected by a dotted line, indicating that in some cases the two can be combined into one. The main chain election mechanism is used to select multiple consensus nodes from multiple first nodes in the main chain 110 and generate a consensus node list. For example, Figure 1 The dashed circles in the figure indicate the elected consensus nodes A1, A2, and A4. The main chain consensus algorithm is used by multiple primary nodes on the main chain to perform consensus operations on a transaction, vote, or other issue. It is a unified set of rules or processing logic followed by distributed collaborative processing to achieve consistent results. For example, consensus algorithm X supported by main chain 110 is the DPoS (delegated proof of stake) consensus mechanism.

[0036] In some exemplary scenarios, the sub-chain consensus mechanism corresponding to sub-chain 120 includes a sub-chain election mechanism and a sub-chain consensus algorithm. Figure 1 The dotted line is used to connect the main chain election mechanism and the main chain consensus algorithm, indicating that the two are separate and will not be combined into one. Because in the embodiment of the present disclosure, the sub-chain obtains the consensus node list based on the main chain election mechanism from the main chain to achieve consensus inheritance. The sub-chain does not need to elect the consensus node in the sub-chain based on its own sub-chain election mechanism, which means that the sub-chain election mechanism is not used in this application to determine the consensus node based on the consensus inheritance mechanism. It can be applied in other data processing scenarios. The sub-chain inherits the corresponding consensus node list to obtain the consensus node object, for example, Figure 1 In the figure, the dotted circle indicates the consensus node objects B11, B12 and B14 obtained by inheriting the consensus node list in the first sub-chain 121; the dotted circle indicates the consensus node objects B21, B22 and B24 obtained by inheriting the consensus node list in the second sub-chain 122. Afterwards, the sub-chain consensus processing of related businesses is carried out based on the sub-chain consensus algorithm; for example, Figure 1 The first sub-chain 121 performs sub-chain consensus processing for related businesses based on consensus algorithm Y (for example, BFT (Byzantine) consensus mechanism); the second sub-chain 122 performs sub-chain consensus processing for related businesses based on consensus algorithm Z (for example, PoW (Proof of Work) consensus mechanism).

[0037] In some embodiments, the consensus node list 101 may store the blockchain accounts corresponding to the consensus nodes in the main chain; in other embodiments, the node identifiers of the consensus nodes in the main chain and the corresponding blockchain accounts may be stored simultaneously. This disclosure does not limit the specific storage format of the consensus node list, as long as a common and unique representation specification can be established between the main chain 110 and the sub-chain 120, and the corresponding blockchain accounts and corresponding nodes in the main chain and sub-chain can be determined based on the information in the consensus node list.

[0038] In scenarios where the main chain and sub-chain use different consensus mechanisms, related technologies often suffer from a disconnected consensus mechanism between the main chain and sub-chain (e.g., the main chain uses a PoS consensus mechanism, while the sub-chain uses a BFT (Byzantine) consensus mechanism). This leads to difficulties in ensuring unified overall security and increases systemic risk. In contrast, the disclosed embodiments obtain a consensus node list based on the main chain's election mechanism within the main chain, and inherit this consensus node list to the sub-chain through the sub-chain management contract. This consensus inheritance mechanism allows the sub-chain to inherit the main chain's consensus node list election results from the main chain. Because the consensus nodes given by the main chain's election results are highly reliable, the consistency and reliability of the election results between the main chain and sub-chain are guaranteed regardless of whether the consensus mechanisms used by the main chain and sub-chain are the same. This avoids the security risks associated with the sub-chain using its own independent internal election mechanism to determine a separate list of nodes for consensus verification within the sub-chain (which may be less reliable). Furthermore, the sub-chain saves resources required for the corresponding election and inherits the same consensus node identities as the main chain for consensus verification, improving the reliability of the processing results.

[0039] In some embodiments, a mapping relationship exists between the first node account corresponding to the first node and the second node account corresponding to the second node. For example, in some application scenarios, the first node account corresponding to node A1 in the main chain 110 is, for example, blockchain account AC1, the first node account corresponding to node A2 is, for example, blockchain account AC2, the first node account corresponding to node A3 is, for example, blockchain account AC3, the first node account corresponding to node A4 is, for example, blockchain account AC4, and the first node account corresponding to node A5 is, for example, blockchain account AC5. The second node account corresponding to node B11 in the first sub-chain 121 is, for example, blockchain account BC1, the second node account corresponding to node B12 is, for example, blockchain account BC2, the second node account corresponding to node B13 is, for example, blockchain account BC3, the second node account corresponding to node B14 is, for example, blockchain account BC4, and the second node account corresponding to node B15 is, for example, blockchain account BC5.

[0040] The example mapping relationship is: AC1→(arrows indicate mapping relationships) BC1; AC2→BC2; AC3→BC3; AC4→BC4; AC5→BC5; as an example, in some application scenarios, the main chain and the sub-chain use the same blockchain account system, then AC1 and BC1 can be the same; in other application scenarios, the main chain and the sub-chain are based on related blockchain account systems. For example, the generation form of the blockchain account corresponding to the sub-chain is related to the blockchain account of the corresponding main chain node, then the blockchain account corresponding to the sub-chain node (for example, AC1) and the blockchain account of the corresponding main chain node (for example, BC1) can also have an association relationship and be in different forms.

[0041] The method of determining the consensus node object in the subchain according to the consensus node list inherited from the main chain includes: performing mapping processing on the first consensus node account in the consensus node list inherited from the main chain and the mapping relationship to obtain the second consensus node account in the subchain corresponding to the first consensus node account; and determining the consensus node corresponding to the second consensus node account in the subchain as the consensus node object.

[0042] For example, according to the mapping relationship {AC1→BC1; AC2→BC2; AC3→BC3; AC4→BC4; AC5→BC5}, it is found that the first consensus node accounts AC1, AC2, AC4 corresponding to the nodes A1, A2, and A4 in the consensus node list are BC1, BC2, and BC4, respectively, and the second consensus node accounts corresponding to the nodes in the sub-chain are BC1, BC2, and BC4, respectively. Then, according to BC1, BC2, and BC4, the corresponding consensus node objects are determined to be: nodes B11, B12, and B14 in the first sub-chain 121.

[0043] In some embodiments, the consensus node list obtained by the main chain election is dynamically updated over time.

[0044] During the transaction processing of the corresponding business based on the corresponding sub-chain business processing contract in the target sub-chain, after the consensus condition is triggered, a query request is initiated to the sub-chain management contract in the main chain based on the preset interface. The above query request is used to query the latest configuration information of the above target sub-chain. The above latest configuration information includes: the latest consensus node list; the above target sub-chain determines the target consensus node object based on the latest consensus node list obtained by the query and performs sub-chain consensus processing based on the above target consensus node object.

[0045] In an embodiment of the present disclosure, the subchain configuration information includes the following general configuration information (chain type type, chain identifier chain_id, network identifier network_id, subchain genesis account genesis_account, slogan printed when creating the subchain, fee information fees and block reward configuration parameter block_reward, fee information includes: the amount of gas (gas refers to the unit used to measure the amount of computing work required to perform specific operations on the blockchain) reserved for the initial creation account, the minimum transaction gas fee; block reward configuration parameters include: reward period reward_period, reward initial value reward_init_value, reward decay reward_decay, etc.) and a unified consensus node list (validatorspool) for all subchains. This list can be accessed through the preset interface provided by the subchain management contract (for example, IP address: 192.168.x.xx:xxx).

[0046] In the above system architecture, the deployment and operation of the mainchain and subchain are decoupled, allowing them to be deployed on different devices. The mainchain and subchains each have independent consensus mechanisms and transaction processing capabilities. The mainchain deploys a subchain management contract to centrally manage the subchain, enabling operations such as creation, exit, rejoining after exit, termination, and sharing of consensus node lists. In some application scenarios, the mainchain supports the Delegated Proof of Stake (DPoS) consensus mechanism and dynamically adjusts the consensus node list through voting. Subchains do not support DPoS, but their consensus node election process does not need to be performed on the subchain itself. Instead, they directly inherit and adopt the mainchain's election results, or use the most recent queried results as consensus nodes before reaching consensus on a block, maintaining consistency with the mainchain. The mainchain's selected consensus node list is then inherited by the subchain, eliminating the need for the subchain to independently elect consensus nodes corresponding to on-chain transactions. This ensures the inheritance and use of the mainchain's election results, thus maintaining consistency and security.

[0047] Figure 4 The figure schematically illustrates the ledger distribution of a blockchain architecture based on master-child chain consensus inheritance according to an embodiment of the present disclosure. Figure 5 The present invention schematically illustrates a process of obtaining the subchain status from the subchain and synchronizing it to the subchain management contract before the main chain of the blockchain architecture based on the main-subchain consensus inheritance according to an embodiment of the present disclosure produces a block.

[0048] In the embodiment of the present disclosure, the deployment of the main chain 110 and the sub-chain 120 are independent of each other, and their respective account data are isolated, such as Figure 4 As shown in Figure 2, the main chain ledger and the sub-chain ledger are isolated from each other.

[0049] Reference Figure 4 As shown in the diagram on the left, the account databases on the main chain and sub-chain store on-chain account data. In this embodiment, the sub-chain's consensus node account configuration remains consistent with the main chain. Therefore, the data containing the consensus node list in the account databases corresponding to the main chain ledger data and the sub-chain ledger data are consistent. In other embodiments, the blockchain accounts of the main chain nodes and the sub-chain nodes are associated in different forms.

[0050] In addition, refer to Figure 5 As shown in the figure, before consensus is reached, the main chain will call the sub-chain management contract and issue a transaction to query the sub-chain for the latest status information of each sub-chain and store it. Therefore, the ledger of the latest block of the main chain will contain transaction data associated with the sub-chain status information.

[0051] Reference Figure 5 As shown, the specific process is: after the consensus condition is triggered in the main chain, the latest status of the sub-chain is obtained from the sub-chain, referring to Figure 5The process corresponding to sequence number ① is shown below; after obtaining the latest status of all subchains, the subchain status in the above subchain management contract is updated according to the latest status of all subchains. Figure 5 The process corresponding to sequence number ② is shown in the figure. During or after the sub-chain status update, the main chain consensus process is executed, that is, consensus block generation, refer to Figure 5 The process corresponding to sequence number ③ is shown below.

[0052] Among them, when the processing scenario of the main chain triggering the consensus condition is unrelated to the sub-chain status, the main chain performs transactions and main chain consensus processing for the corresponding processing scenario based on the main chain business processing contract, and the main chain consensus processing can be performed during or after the sub-chain status update.

[0053] When the processing scenario of the main chain triggering the consensus condition is related to the sub-chain status, the main chain performs transactions and main chain consensus processing for the corresponding processing scenario based on the main chain business processing contract, and executes the main chain consensus processing after the sub-chain status is updated.

[0054] Figure 6 The following schematically illustrates a subchain creation process in which a main chain performs lifecycle management on a subchain in a blockchain architecture based on main-subchain consensus inheritance according to an embodiment of the present disclosure; Figure 7 Schematically illustrates a process diagram of a subchain updating first configuration information in which a main chain performs lifecycle management on a subchain in a blockchain architecture based on main-subchain consensus inheritance according to an embodiment of the present disclosure; Figure 8 The following schematically illustrates a subchain exit process in which the main chain performs lifecycle management on the subchain in a blockchain architecture based on main-subchain consensus inheritance according to an embodiment of the present disclosure.

[0055] In some embodiments, combined Figures 6 to 8 As shown, the above-mentioned blockchain architecture also includes: the above-mentioned main chain performs life cycle management of the sub-chain based on the above-mentioned sub-chain management contract, and the above-mentioned life cycle management includes executing at least one of the following preset action instructions on the sub-chain: creation instruction, exit instruction, resumption instruction after exit or termination instruction.

[0056] The main chain receives proposal transaction requests for creating, exiting, rejoining after exiting, or terminating a subchain based on the subchain management contract.

[0057] For example, Figure 6 Sequence number ① indicates the user's proposal transaction request for creating a sub-chain on the main chain; in the application scenario of this disclosure, any user has the right to submit an application proposal for creating a new sub-chain, and the proposal must be voted through by all administrators before a new sub-chain can be created. Figure 8 Sequence number ① indicates the proposal transaction request initiated by the sub-chain owner to exit the sub-chain.

[0058] Afterwards, the main chain, based on the administrator node corresponding to the queried contract administrator list, performs consensus voting on the proposal transaction requests for creating, exiting, rejoining after exiting, or terminating the sub-chain, and obtains the proposal transaction processing result. Figure 6 As shown in the consensus voting process corresponding to sequence number ②, during the consensus voting process, it is necessary to verify whether the identity of the initiating user of the proposal transaction request is authentic, whether the initiating user identity has the corresponding authority, and whether the configuration information in the proposal transaction request is legal. Figure 8 The same execution process is simplified and only the different parts in the update configuration information are highlighted.

[0059] The above-mentioned contract administrator list adopts the consensus node list by default. The contract administrator applies for membership update requests to join or leave the contract administrator, and the corresponding contract administrator list is dynamically updated after elections are conducted based on the voting admission and exit mechanism in the main chain. The voting subjects corresponding to the above-mentioned voting admission and exit mechanism are all current contract administrators. The admission and exit mechanism can be: admission or exit if all members vote in favor; or admission or exit if more than a preset number or a preset ratio of people vote in favor; or, alternatively, the admission mechanism can set a threshold that requires unanimous approval by administrators, and the exit mechanism allows individual withdrawal requests to be directly approved.

[0060] Afterwards, the main chain updates the configuration information of the corresponding sub-chain based on the results of the proposal transaction. The update process includes adding, clearing, or synchronizing the latest information of the consensus node list in the cleared state. Figure 6 The process of storing or updating the subchain configuration information corresponding to sequence number ③ is shown in the figure. Taking the creation of a subchain as an example, the corresponding information of the consensus node list is added. Taking the exit of a subchain as an example, the corresponding information of the consensus node list is cleared. Figure 8 The process of updating the consensus node list corresponding to sequence number ② to be empty is shown in the figure.

[0061] In an embodiment of the present disclosure, the above-mentioned update includes at least one of the following: In response to the above creation instruction, the proposal transaction request carries: the initial configuration information of the subchain to be created; in response to the proposal transaction processing result indicating that the proposal transaction for creating the subchain is approved, the consensus node list obtained based on the main chain election mechanism is added to the initial configuration information of the subchain to be created, thereby obtaining the target configuration information of the subchain to be created; In response to the proposal transaction processing result indicating that the proposal transaction to exit the subchain is approved, the consensus node list in the target configuration information of the subchain to be exited is cleared, so that the subchain to be exited cannot conduct new transactions but supports historical transaction queries; In response to the proposal transaction processing result indicating that the proposal transaction to rejoin the subchain after exiting is approved, the consensus node list in the target configuration information of rejoining the subchain after exiting is restored from the cleared state to be synchronized with the current main chain election result, so that new transactions can be carried out in the subchain after rejoining; In response to the proposal transaction processing result indicating that the proposal transaction to terminate the sub-chain is passed, the target configuration information of the sub-chain to be terminated is cleared and the state of the sub-chain to be terminated is set to a disabled state.

[0062] In some embodiments, when the proposal transaction processing result indicates that the proposal transaction is passed, the proposal transaction related information and target configuration information of the subchain are stored in the subchain management contract.

[0063] After the main chain stores or updates the sub-chain configuration information, the sub-chain node can be deployed and run on the device according to the above configuration information. Figure 6 As shown in the process of obtaining the sub-chain configuration information indicated by sequence number ④, when running the newly created sub-chain in the target device, the sub-chain management contract in the main chain is called to query the corresponding target configuration information.

[0064] Reference Figure 6 As shown in the process of generating a local configuration file as shown in sequence number ⑤, a configuration file corresponding to a newly created sub-chain node is generated locally on the target device based on the above target configuration information.

[0065] Reference Figure 6 As shown in the process of deploying and running the newly created sub-chain node as shown in sequence number ⑥, the node is started and configured on the target device based on the above configuration file to complete the deployment and operation of the newly created sub-chain node.

[0066] In some embodiments, the above blockchain architecture further includes: Figure 7 As shown, during the operation of the sub-chain node, after the sub-chain node receives the first configuration information update instruction locally, the sub-chain configuration information in the main chain is synchronously updated by calling the sub-chain management contract. The above-mentioned first configuration information does not contain a consensus node list. For example, the first configuration information is the reserved gas fee, minimum gas parameters, etc.

[0067] The update method here can ensure the consistency between the local configuration information of the sub-chain node and the information managed in the main chain. The process of updating the configuration realizes the synchronous update of the storage content of the sub-chain management contract in the main chain. There is no need to set up other additional links to synchronize the local configuration update data of the sub-chain node with the node configuration information managed in the main chain. When there is an update to the sub-chain node, the sub-chain management contract is directly called for update synchronization. It is efficient and achieves data consistency between the main chain and the sub-chain, reflecting the management efficiency of the sub-chain management contract and timely synchronization of data, ensuring the processing accuracy of business data on the main chain that may be related to the sub-chain status.

[0068] In the embodiments of this disclosure, the consensus node list elected by the main chain is dynamically updated over time. During the operation of the sub-chain node, the latest consensus node list in the sub-chain configuration information (i.e., the target configuration information described above) is queried from the sub-chain management contract based on at least one of the following methods: Based on the preset period, query the latest consensus node list in the subchain configuration information from the subchain management contract; or, Receive updates from the main chain regarding the consensus node list in the subchain configuration information; or, After the subchain triggers the consensus condition, the latest consensus node list in the subchain configuration information is queried from the subchain management contract.

[0069] In this embodiment, based on periodic synchronization, timely synchronization or consensus condition-triggered synchronization, the dynamically updated election results in the main chain can be synchronized to the sub-chain nodes, so that the sub-chain nodes can perform consensus verification based on the latest consensus node list, so that the sub-chain can inherit the election results of the reliable consensus nodes after the main chain is updated.

[0070] In some embodiments of the present disclosure, to enhance the credibility of the consensus node list generated by the mainchain election mechanism, a multi-dimensional reputation assessment mechanism is implemented. This includes cross-validation of off-chain trusted data (e.g., CA certificates, hardware fingerprints) with on-chain behavioral data, and the use of a TEE (Trusted Execution Environment) for data collection and encryption, among other methods to mitigate the risk of Sybil attacks. Furthermore, the dynamic nature of the consensus node list is enhanced through a dynamic elimination mechanism. A dual-threshold monitoring module implements dual monitoring at both the hardware and protocol levels. Node health is monitored at the hardware level (e.g., CPU / memory / network utilization threshold alarm policies), while consensus behavior compliance is monitored at the protocol level (e.g., for proposal timeouts and signature anomalies). Gradient penalty rules are implemented for non-compliant behaviors, such as a 5% reputation reduction for delay-related behaviors, a 10% deduction of the staked deposit for each occurrence of malicious behavior, and a forced offline timeout for a preset threshold number of malicious behavior occurrences. In some embodiments, the mainchain election mechanism can also utilize collusion-resistant random election algorithms, such as those based on a VRF (Verifiable Random Function) random election mechanism, to ensure fairness and reliability of the election results.

[0071] This embodiment provides a blockchain architecture in which the main chain and multiple subchains are physically decoupled and deployed, logically coordinating their operations through a management contract. Subchains can operate independently, reach consensus, and produce blocks, while the main chain is responsible for recording their state and lifecycle management. A subchain management contract deployed on the main chain is proposed to uniformly implement all lifecycle management functions, including subchain creation, initial configuration, configuration updates, exit, rejoining after exit, and termination. Operations on subchains require administrator proposals and unanimous vote, demonstrating decentralized governance. A cross-chain state synchronization mechanism is provided: before each consensus block is produced, the main chain proactively queries all subchains for the latest state and uploads this state information to the blockchain. In some embodiments, the main chain utilizes a hybrid DPoS + BFT consensus, while the subchains utilize pure BFT. The consensus node list is centrally maintained by the main chain, and the subchain consensus inherits the security of the main chain. The main and subchain databases are completely isolated, and the subchains have independent account systems, but the consensus accounts remain consistent. A secure exit mechanism is provided, where the main chain management contract clears the consensus node list, invalidating the subchain consensus and freezing it, while still supporting historical data queries. The subchain's primary configuration information can be dynamically adjusted by the subchain owner and takes effect in real time. Overall, this system offers advantages such as high system security, high data processing throughput, isolation between the mainchain and subchain ledgers, independent deployment of subchains and ease of expansion, and significantly less data synchronization pressure on subchain ledgers in a mainchain-subchain architecture compared to a single-chain architecture.

[0072] In summary, in the blockchain architecture of this embodiment, the main chain and multiple sub-chains are physically decoupled and deployed, and logically operate in coordination through the sub-chain management contract; by setting up a main chain to manage the sub-chains, each sub-chain has an independent business execution environment and supports the independent processing of its corresponding business. At the same time, consensus inheritance is performed between the main chain and the sub-chains, which helps to improve the high-concurrency processing capability and security of the system as a whole. By obtaining a consensus node list based on the main chain election mechanism in the main chain, and inheriting the above consensus node list to the sub-chain through the sub-chain management contract, since the credibility of the consensus node given by the election result in the main chain is very high, regardless of whether the consensus mechanism corresponding to the main chain and the sub-chain is the same, this application can ensure the consistency and reliability of the election results corresponding to the main chain and the sub-chain by setting up a consensus inheritance mechanism in which the sub-chain inherits the main chain's election result on the consensus node list from the main chain, avoiding the security risk caused by the sub-chain determining another set of node lists for consensus verification in the sub-chain based on its own independent internal election mechanism (which may be less reliable). At the same time, the sub-chain saves the corresponding election. The required resources are inherited and the consensus node identity consistent with the main chain is adopted to participate in consensus verification, which improves the reliability of the processing results. Moreover, when a sub-chain conducts transactions and sub-chain consensus processing for the corresponding business based on the corresponding sub-chain business processing contract, it does not need to interact with other sub-chains and can realize data processing within the same sub-chain. Multiple sub-chains can process multiple businesses in parallel or different tasks or sub-tasks of the same business in parallel. At the same time, the need to add new sub-chains or end existing sub-chains can also be uniformly managed by the main chain based on the sub-chain management contract, which is flexible in expansion and control, and improves the system's parallel processing capabilities as a whole, effectively copes with high concurrent traffic, and improves system security and scalability.

[0073] A second exemplary embodiment of the present disclosure provides a data processing apparatus.

[0074] Figure 9 The structure of a data processing device according to an embodiment of the present disclosure is schematically shown.

[0075] Reference Figure 9 As shown, the data processing device 900 of this embodiment is a node in the main blockchain network. The above-mentioned main blockchain network is configured with a sub-chain management contract. The above-mentioned device includes: an election module 910, a first consensus inheritance module 920 and a sub-chain management module 930.

[0076] The election module 910 is used to interact with other nodes in the main blockchain network and obtain a consensus node list based on the main chain election mechanism.

[0077] The above-mentioned first consensus inheritance module 920 is used to inherit the above-mentioned consensus node list to the sub-chain for adoption based on the above-mentioned sub-chain management contract; wherein the above-mentioned sub-chain is a sub-blockchain network. When the sub-chain performs independent processing of corresponding business, the consensus node object in the sub-chain is determined according to the consensus node list inherited from the main chain and the consensus processing within the sub-chain is performed based on the above-mentioned consensus node object.

[0078] The above-mentioned sub-chain management module 930 is used to manage the life cycle of the sub-chain based on the above-mentioned sub-chain management contract.

[0079] For more details of this embodiment, please refer to the relevant description of the first embodiment. The communication protocol or corresponding interface followed by the interaction between the main chain and the sub-chain can be implemented by the sub-chain management contract opening the corresponding interface or access address. Therefore, the device of this embodiment can also include more functional modules or sub-modules or integrate more functions into existing modules to implement the above details, which will not be repeated here.

[0080] The data processing device of this embodiment is able to uniformly manage the sub-chain based on the sub-chain management contract, with flexible expansion and control. At the same time, consensus inheritance is carried out between the main chain and the sub-chain, which helps to ensure that the main chain and the sub-chain can independently handle corresponding businesses while achieving the security of the entire main-sub-chain system. The main chain also supports the processing of independent businesses and supports data calls for related businesses between the main chain and the sub-chain.

[0081] A third exemplary embodiment of the present disclosure provides a data processing apparatus.

[0082] Figure 10 The figure schematically shows a structural block diagram of a data processing device according to another embodiment of the present disclosure.

[0083] Reference Figure 10 As shown, the data processing device 1000 of this embodiment is a node in the sub-blockchain network, and the above-mentioned device includes: a second consensus inheritance module 1010 and a data processing module 1020.

[0084] The second consensus inheritance module 1010 is used to obtain a consensus node list; the consensus node list is obtained by the main blockchain network based on the main chain election mechanism.

[0085] The above-mentioned data processing module 1020 is used to perform corresponding business transactions and sub-chain consensus processing based on the corresponding sub-chain business processing contract, wherein the consensus node object in the sub-chain is determined according to the consensus node list inherited from the main chain and the sub-chain consensus processing is performed based on the above-mentioned consensus node object.

[0086] For more details of this embodiment, please refer to the relevant description of the first embodiment. The communication protocol or corresponding interface followed by the interaction between the main chain and the sub-chain can be implemented by the sub-chain management contract opening the corresponding interface or access address. Therefore, the device of this embodiment can also include more functional modules or sub-modules or integrate more functions into existing modules to implement the above details, which will not be repeated here.

[0087] By inheriting the consensus node list elected from the main chain, the data processing device of this embodiment helps ensure that the main chain and sub-chains can independently handle their respective business operations while maintaining the security of the entire main-sub-chain system. Each sub-chain can independently handle its corresponding business operations, including intra-sub-chain transactions, inherited consensus node lists, and independent consensus processing. Performance increases linearly, and transaction throughput is high. The main chain ledger is isolated from the sub-chain ledger, and the sub-chains are independently deployed and easily scalable. In addition, the amount of synchronized data in the sub-chain ledgers of the main-sub-chain architecture is much smaller than that of a single chain architecture, reducing the pressure of data synchronization.

[0088] A fourth exemplary embodiment of the present disclosure provides a data processing method based on the blockchain architecture of the first embodiment.

[0089] The above methods include: The target subchain receives the data processing request for the corresponding business, or the mainchain receives the data processing request for the subchain business and forwards it to the corresponding target subchain; The target subchain performs transactions and subchain consensus processing for the corresponding business based on the corresponding subchain business processing contract. The target subchain determines the consensus node object in the subchain based on the consensus node list inherited from the main chain and performs subchain consensus processing based on the above consensus node object.

[0090] In some embodiments, the data processing method further includes: After the consensus condition is triggered in the main chain, the latest status of the subchain is obtained from the subchain; after obtaining the latest status of all subchains, the subchain status in the above-mentioned subchain management contract is updated according to the latest status of all subchains; the main chain consensus processing is performed during or after the subchain status update.

[0091] Among them, when the processing scenario of the main chain triggering the consensus condition is unrelated to the sub-chain status, the main chain performs transactions and main chain consensus processing for the corresponding processing scenario based on the main chain business processing contract, and the main chain consensus processing can be performed during or after the sub-chain status update.

[0092] When the processing scenario of the main chain triggering the consensus condition is related to the sub-chain status, the main chain performs transactions and main chain consensus processing for the corresponding processing scenario based on the main chain business processing contract, and executes the main chain consensus processing after the sub-chain status is updated.

[0093] In some embodiments, the main chain triggering consensus condition can be based on the main chain business processing contract to perform the corresponding processing scenario.

[0094] For more details and beneficial effects of this embodiment, please refer to the relevant description of the first embodiment, which will not be repeated here.

[0095] Any number of the functional modules included in the data processing device 900 or 1000 described above may be combined into a single module, or any one of these modules may be split into multiple modules. Alternatively, at least part of the functionality of one or more of these modules may be combined with at least part of the functionality of other modules and implemented in a single module. At least one of the functional modules included in the data processing device 900 or 1000 described above may be at least partially implemented as a hardware circuit, such as a field programmable gate array (FPGA), a programmable logic array (PLA), a system on a chip, a system on a substrate, a system on a package, an application-specific integrated circuit (ASIC), or may be implemented in hardware or firmware through any other reasonable means of circuit integration or packaging, or implemented in any one of the three implementation methods, or any appropriate combination of software, hardware, and firmware. Alternatively, at least one of the functional modules included in the data processing device 900 or 1000 described above may be at least partially implemented as a computer program module that, when executed, performs the corresponding functionality.

[0096] It should be noted that, in this document, relational terms such as "first" and "second" are used only to distinguish one entity or operation from another entity or operation, and do not necessarily require or imply any actual relationship or order between these entities or operations. Moreover, the terms "comprises," "comprising," or any other variations thereof are intended to cover non-exclusive inclusion, so that a process, method, article, or device comprising a series of elements includes not only those elements, but also other elements not explicitly listed, or elements inherent to such process, method, article, or device. In the absence of further limitations, an element defined by the phrase "comprising a ..." does not exclude the presence of other identical elements in the process, method, article, or device comprising the element.

[0097] The foregoing description is intended only to provide specific embodiments of the present disclosure, intended to enable those skilled in the art to understand and implement the present disclosure. Various modifications to these embodiments will be readily apparent to those skilled in the art, and the general principles defined herein may be implemented in other embodiments without departing from the spirit or scope of the present disclosure. Therefore, the present disclosure is not to be limited to the embodiments shown herein, but is to be construed in the broadest manner consistent with the principles and novel features claimed herein.

Claims

1. A blockchain architecture based on master-child chain consensus inheritance, characterized by: include: The main chain is the main blockchain network; at least one sub-chain is a sub-blockchain network; The main chain is configured with a sub-chain management contract, based on which the consensus node list obtained based on the main chain election mechanism is inherited to the sub-chain for adoption; Each sub-chain has an independent business execution environment and supports independent processing of corresponding businesses; each sub-chain is configured with a corresponding sub-chain business processing contract, and transactions of corresponding businesses and consensus processing within the sub-chain are carried out based on the sub-chain business processing contract. Among them, the consensus node object in the sub-chain is determined according to the consensus node list inherited from the main chain, and the consensus processing within the sub-chain is performed based on the consensus node object.

2. The blockchain architecture according to claim 1, characterized in that: The main chain includes a plurality of first nodes, the sub-chain includes a plurality of second nodes, and a mapping relationship exists between first node accounts corresponding to the first nodes and second node accounts corresponding to the second nodes; The method of determining the consensus node object in the subchain according to the consensus node list inherited from the main chain includes: performing mapping processing on the first consensus node account in the consensus node list inherited from the main chain and the mapping relationship to obtain a second consensus node account in the subchain corresponding to the first consensus node account; and determining the consensus node corresponding to the second consensus node account in the subchain as the consensus node object.

3. The blockchain architecture according to claim 1, characterized in that: The main chain consensus mechanism corresponding to the main chain and the sub-chain consensus mechanism corresponding to the sub-chain are independent of each other, and the sub-chain consensus mechanisms corresponding to each sub-chain are also independent of each other.

4. The blockchain architecture according to any one of claims 1 to 3, characterized in that: The consensus node list obtained by the main chain election is dynamically updated over time; During the transaction processing of the corresponding business in the target sub-chain based on the corresponding sub-chain business processing contract, after the consensus condition is triggered, a query request is initiated to the sub-chain management contract in the main chain based on the preset interface. The query request is used to query the latest configuration information of the target sub-chain, and the latest configuration information includes: the latest consensus node list; the target sub-chain determines the target consensus node object based on the latest consensus node list obtained by the query and performs sub-chain consensus processing based on the target consensus node object.

5. The blockchain architecture according to any one of claims 1 to 3, characterized in that: Also includes: The main chain performs lifecycle management of the subchain based on the subchain management contract, and the lifecycle management includes executing at least one of the following preset action instructions on the subchain: a creation instruction, an exit instruction, a post-exit resume instruction, or a termination instruction; The main chain receives a proposal transaction request for creating, exiting, rejoining after exiting, or terminating a subchain based on the subchain management contract; The main chain performs consensus voting on proposal transaction requests for creating, exiting, rejoining, or terminating a subchain based on the administrator nodes corresponding to the queried contract administrator list, and obtains proposal transaction processing results. The contract administrator list adopts the consensus node list by default, and dynamically updates the corresponding contract administrator list after the member update request for the contract administrator to apply for joining or exit is elected based on the voting admission and exit mechanism in the main chain. The main chain updates the configuration information of the corresponding sub-chain according to the processing result of the proposed transaction; The update process involves adding, clearing, or synchronizing the latest information of the consensus node list in the cleared state.

6. The blockchain architecture according to claim 5, characterized in that: The update includes at least one of the following: In response to the creation instruction, the proposal transaction request carries: initial configuration information of the subchain to be created; in response to the proposal transaction processing result indicating that the proposal transaction to create the subchain is approved, the consensus node list obtained based on the main chain election mechanism is added to the initial configuration information of the subchain to be created, thereby obtaining the target configuration information of the subchain to be created; In response to the proposal transaction processing result indicating that the proposal transaction to exit the subchain is approved, the consensus node list in the target configuration information of the subchain to be exited is cleared, so that the subchain to be exited cannot conduct new transactions but supports historical transaction queries; In response to the proposal transaction processing result indicating that the proposal transaction to rejoin the subchain after exiting is approved, the consensus node list in the target configuration information of rejoining the subchain after exiting is restored from the cleared state to be synchronized with the current main chain election result, so that new transactions can be carried out in the subchain after rejoining; In response to the proposal transaction processing result indicating that the proposal transaction to terminate the sub-chain is passed, the target configuration information of the sub-chain to be terminated is cleared and the state of the sub-chain to be terminated is set to a disabled state.

7. The blockchain architecture according to claim 5, characterized in that: If the proposal transaction processing result indicates that the proposal transaction is approved, storing the proposal transaction related information and target configuration information of the subchain in the subchain management contract; During the process of running the newly created sub-chain in the target device, the sub-chain management contract in the main chain is called to query the corresponding target configuration information; a configuration file corresponding to the newly created sub-chain node is generated locally on the target device based on the target configuration information; and the node is started and configured on the target device based on the configuration file to complete the deployment and operation of the newly created sub-chain node.

8. The blockchain architecture according to claim 5, characterized in that: Also includes: During the operation of the sub-chain node, after receiving the first configuration information update instruction locally, the sub-chain node synchronously updates the sub-chain configuration information in the main chain by calling the sub-chain management contract. The first configuration information does not include the consensus node list. The consensus node list obtained by the main chain election is dynamically updated over time. During the operation of the sub-chain node, the latest consensus node list in the sub-chain configuration information is queried from the sub-chain management contract based on at least one of the following methods: Based on the preset period, query the latest consensus node list in the subchain configuration information from the subchain management contract; or, Receive updates from the main chain regarding the consensus node list in the subchain configuration information; or, After the subchain triggers the consensus condition, the latest consensus node list in the subchain configuration information is queried from the subchain management contract.

9. The blockchain architecture according to claim 1, wherein: The main chain and the sub-chain are deployed independently of each other, and their respective ledger data are isolated; After the consensus condition is triggered in the main chain, the latest subchain status is obtained from the subchain. After obtaining the latest subchain status of all subchains, the subchain status in the subchain management contract is updated according to the latest subchain status of all subchains. The main chain consensus processing is performed during or after the subchain status update; Among them, when the processing scenario of the main chain triggering the consensus condition is unrelated to the sub-chain status, the main chain performs transactions and main chain consensus processing for the corresponding processing scenario based on the main chain business processing contract, and can perform main chain consensus processing during or after the sub-chain status update; When the processing scenario of the main chain triggering the consensus condition is related to the sub-chain status, the main chain performs transactions and main chain consensus processing for the corresponding processing scenario based on the main chain business processing contract, and executes the main chain consensus processing after the sub-chain status is updated.

10. A data processing device, characterized in that: The device is a node in a main blockchain network, wherein the main blockchain network is configured with a sub-chain management contract; the device includes: The election module is used to interact with other nodes in the main blockchain network and obtain the consensus node list based on the main chain election mechanism; A first consensus inheritance module is configured to inherit the consensus node list to the subchain for adoption based on the subchain management contract; wherein the subchain is a sub-blockchain network, and when the subchain independently processes corresponding services, the consensus node object in the subchain is determined based on the consensus node list inherited from the main chain and the subchain consensus processing is performed based on the consensus node object; The sub-chain management module is used to manage the life cycle of the sub-chain based on the sub-chain management contract.

11. A data processing device, characterized in that: The device is a node in a sub-blockchain network, and the device includes: The second consensus inheritance module is used to obtain a consensus node list; the consensus node list is obtained by the main blockchain network based on the main chain election mechanism; The data processing module is used to perform transactions and sub-chain consensus processing for the corresponding business based on the corresponding sub-chain business processing contract. The consensus node object in the sub-chain is determined according to the consensus node list inherited from the main chain, and the sub-chain consensus processing is performed based on the consensus node object.

12. A data processing method based on a blockchain architecture based on master-subchain consensus inheritance according to any one of claims 1 to 9, characterized in that: The method comprises: The target subchain receives the data processing request for the corresponding business, or the mainchain receives the data processing request for the subchain business and forwards it to the corresponding target subchain; The target sub-chain performs transactions and sub-chain consensus processing for the corresponding business based on the corresponding sub-chain business processing contract, wherein the consensus node object in the sub-chain is determined according to the consensus node list inherited from the main chain and the sub-chain consensus processing is performed based on the consensus node object.

Images