Blockchain architecture, data processing method, and device based on master-slave chain consensus inheritance

Abstract

The present disclosure relates to a blockchain architecture based on main sub-chain consensus inheritance, a data processing method and device, the blockchain architecture comprising: a main chain, which is a main blockchain network; and at least one sub-chain, which is a sub-blockchain network. The main chain is configured with a sub-chain management contract, and a list of consensus nodes obtained based on a main chain election mechanism is inherited to the sub-chain based on the sub-chain management contract. 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 and intra-sub-chain consensus processing of corresponding businesses are performed based on the sub-chain business processing contract. The consensus node objects in the sub-chain are determined according to the list of consensus nodes inherited from the main chain, and the intra-sub-chain consensus processing is performed based on the consensus node objects. Overall, the system parallel processing capability is improved, high concurrency traffic is effectively faced, and the system security and scalability are improved.

Description

Technical Field

[0001] This disclosure relates to the field of blockchain technology, and in particular to a blockchain architecture, data processing method and apparatus based on master-slave chain consensus inheritance. Background Technology

[0002] Due to its advantages such as decentralization and traceability of transactions, blockchain technology has broad application prospects in various scenarios, including financial payments and transactions, data security, digital asset notarization, copyright notarization and protection, origin tracing, and supply chain tracking (e.g., evidence chain tracking, logistics tracking). However, with the explosive growth of users, the diversification of business needs, and the increasing complexity of various business processes, single-chain architectures face challenges such as low throughput, long confirmation times, and poor system scalability when performing data notarization or processing based on a single blockchain system (or described as a blockchain network), making it difficult to meet diverse business needs and large-scale concurrent processing. Related technologies have proposed multi-chain blockchain architecture technology, which refers to improving the scalability and interoperability of a system through the collaborative work of multiple blockchains.

[0003] However, in realizing the concept disclosed herein, the inventors discovered that the multi-chain architecture in the relevant technologies has at least the following technical problems: The interaction between the main chain and the sub-chains is mainly to realize cross-chain business, which is actually a collaboration between multiple sub-chains to process business. Since cross-chain interaction relies on a centralized relay mechanism, a relay role is required (such as the main chain or other chains undertaking the corresponding role), which becomes a bottleneck in system performance and makes it difficult to support high-concurrency scenarios; Some solutions use sharding technology to improve parallel processing capabilities, but current sharded transactions require multiple verifications and frequent state synchronization, which significantly increases latency. Furthermore, the consensus mechanisms of the main chain and the sub-chains are fragmented (such as the main chain using the PoS consensus mechanism and the sub-chain using the BFT (Byzantine Fault Tolerance) consensus mechanism), making it difficult to uniformly guarantee overall security and increasing systemic risks. Summary of the Invention

[0004] To address or at least partially address the aforementioned technical problems, embodiments of this disclosure provide a blockchain architecture, data processing method, and apparatus based on master-slave chain consensus inheritance.

[0005] Firstly, embodiments of this disclosure provide a blockchain architecture based on master-slave chain consensus inheritance. The blockchain architecture includes: a master chain, serving as the main blockchain network; and at least one sub-chain, serving as a sub-blockchain network. The master chain is configured with a sub-chain management contract, which inherits a consensus node list obtained based on the master chain election mechanism to the sub-chains. 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, which performs corresponding business transactions and intra-chain consensus processing. Specifically, consensus node objects in the sub-chain are determined based on the consensus node list inherited from the master chain, and intra-chain consensus processing is executed based on these consensus node objects.

[0006] In some embodiments, the main chain includes multiple first nodes, and the sub-chain includes multiple second nodes. A mapping relationship exists between the first node accounts corresponding to the first nodes and the second node accounts corresponding to the second nodes. Specifically, determining the consensus node object in the sub-chain based on the consensus node list inherited from the main chain includes: performing mapping processing based on the first consensus node accounts in the consensus node list inherited from the main chain and the aforementioned mapping relationship to obtain the second consensus node accounts in the sub-chain corresponding to the first consensus node accounts; and determining the consensus node corresponding to the second consensus node accounts in the sub-chain as the consensus node object.

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

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

[0009] In some embodiments, the blockchain architecture further includes: the main chain managing the lifecycle of the sub-chains based on the sub-chain management contract, wherein the lifecycle management includes executing at least one of the following preset action instructions on the sub-chains: creation instruction, exit instruction, exit and rejoin instruction, or termination instruction. The main chain receives proposal transaction requests for creating, exiting, rejoining, or terminating a sub-chain based on the sub-chain management contract; the main chain performs consensus voting processing on the proposal transaction requests for creating, exiting, rejoining, or terminating a sub-chain based on the administrator nodes corresponding to the queried contract administrator list, obtaining the proposal transaction processing result; wherein, the contract administrator list is a consensus node list by default, and for contract administrators requesting to join or leave, the corresponding contract administrator list is dynamically updated after election based on the voting admission and admission mechanism in the main chain; the main chain updates the configuration information of the corresponding sub-chains according to the proposal transaction processing result; wherein the update process includes at least one of adding, clearing, or synchronizing the latest information in a cleared state regarding the consensus node list.

[0010] In some embodiments, the above update includes at least one of the following:

[0011] For 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 to create the subchain has passed, the information of 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, so as to obtain the target configuration information of the subchain to be created.

[0012] In response to the proposal transaction processing result indicating that the proposal transaction to exit the subchain has been 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 make new transactions but supports historical transaction queries.

[0013] In response to the proposal transaction processing result indicating that the proposal transaction for rejoining the subchain after exiting has been approved, the consensus node list in the target configuration information for rejoining the subchain after exiting will be restored from a cleared state to be synchronized with the current election results of the main chain, so that new transactions can be carried out after rejoining the subchain after exiting.

[0014] In response to the proposal transaction processing result indicating that the proposal transaction to terminate the subchain has been passed, the target configuration information of the subchain to be terminated is cleared and the status of the subchain to be terminated is set to disabled.

[0015] In some embodiments, when the proposal transaction processing result indicates that the proposal transaction has passed, 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 new subchain on the target device, the subchain management contract in the main chain is invoked to query the corresponding target configuration information; based on the target configuration information, a configuration file corresponding to the new subchain node is generated locally on the target device; based on the configuration file, the node is started and configured on the target device to complete the deployment and operation of the new subchain node.

[0016] In some embodiments, the above blockchain architecture further includes: during the operation of a sub-chain node, after receiving a first configuration information update instruction locally on the sub-chain node, the sub-chain management contract is invoked to synchronously update the sub-chain configuration information in the main chain, wherein the first configuration information does not include a consensus node list.

[0017] The consensus node list obtained from the main chain election is dynamically updated over time. During the operation of the sub-chain nodes, the latest consensus node list in the sub-chain configuration information is queried from the sub-chain management contract using at least one of the following methods:

[0018] Based on a preset period, query the subchain management contract for the latest consensus node list in the subchain configuration information; or...

[0019] Receive updates from the main chain regarding the consensus node list in the sub-chain configuration information; or,

[0020] After the consensus condition is triggered in the subchain, the latest list of consensus nodes in the subchain configuration information is queried from the subchain management contract.

[0021] In some embodiments, the deployment of the main chain and the sub-chains are independent of each other, and their respective ledger data is isolated. After a consensus condition is triggered in the main chain, the latest state of the sub-chains is obtained from the sub-chains. After obtaining the latest states of all sub-chains, the sub-chain state in the sub-chain management contract is updated according to the latest states of all sub-chains. Consensus processing within the main chain is performed during or after the sub-chain state update. Specifically, when the processing scenario in which the main chain triggers the consensus condition is unrelated to the sub-chain state, the main chain performs transactions and consensus processing within the corresponding scenario based on the main chain business processing contract, and can perform consensus processing within the main chain both during and after the sub-chain state update; when the processing scenario in which the main chain triggers the consensus condition is related to the sub-chain state, the main chain performs transactions and consensus processing within the corresponding scenario based on the main chain business processing contract, and performs consensus processing within the main chain after the sub-chain state update.

[0022] Secondly, embodiments of this disclosure provide a data processing apparatus. The apparatus is a node in a main blockchain network, which is configured with a sub-chain management contract. The apparatus includes an election module, a first consensus inheritance module, and a sub-chain management module. The election module interacts with other nodes in the main blockchain network and obtains a consensus node list based on the main chain election mechanism. The first consensus inheritance module inherits the consensus node list to the sub-chain based on the sub-chain management contract; wherein the sub-chain is a sub-blockchain network, and when the sub-chain performs independent processing of corresponding business, it determines the consensus node objects in the sub-chain based on the consensus node list inherited from the main chain and performs consensus processing within the sub-chain based on the consensus node objects. The sub-chain management module manages the lifecycle of the sub-chain based on the sub-chain management contract.

[0023] Thirdly, embodiments of this disclosure provide a data processing apparatus. The apparatus 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; 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 corresponding business transactions and sub-chain consensus processing based on the corresponding sub-chain business processing contract, wherein consensus node objects in the sub-chain are determined according to the consensus node list inherited from the main chain, and sub-chain consensus processing is performed based on the consensus node objects.

[0024] Fourthly, embodiments of this disclosure provide a data processing method based on the blockchain architecture of the first aspect embodiment described above. The method includes: a target sub-chain receiving a data processing request for a corresponding business, or a main chain receiving a data processing request for a sub-chain business and forwarding it to the corresponding target sub-chain; the target sub-chain performing transactions and intra-chain consensus processing for the corresponding business based on the corresponding sub-chain business processing contract, wherein consensus node objects in the sub-chain are determined according to a consensus node list inherited from the main chain, and intra-chain consensus processing is performed based on the aforementioned consensus node objects.

[0025] The technical solutions provided in the embodiments of this disclosure have at least some or all of the following advantages:

[0026] By setting up a main-subchain architecture where the main chain manages the subchains, and each subchain has an independent business execution environment supporting independent processing of its corresponding business, while simultaneously implementing consensus inheritance between the main chain and subchains, the overall system's high-concurrency processing capability and security are improved. Specifically, by obtaining a consensus node list in the main chain based on the main chain's election mechanism, and then inheriting this consensus node list to the subchains through the subchain management contract, the consistency and reliability of the election results between the main chain and subchains are guaranteed. This avoids the need for subchains to rely on their own internal independent election mechanisms to determine the consensus node list. This approach mitigates security risks associated with using a separate list of nodes for consensus verification within a subchain (which may have lower reliability). Simultaneously, the subchain saves resources needed for elections by inheriting the same consensus node identities as the main chain, thus improving the reliability of the processing results. Furthermore, when a subchain performs transactions and consensus processing based on its corresponding subchain business processing contract, it can achieve data processing within the same subchain without interacting with other subchains. Multiple subchains can process various businesses in parallel or different tasks or subtasks of the same business. Adding new subchains or terminating existing ones can also be uniformly managed by the main chain based on the subchain management contract, offering flexible expansion and control. Overall, this improves the system's parallel processing capabilities, effectively handling high-concurrency traffic while enhancing system security and scalability. Attached Figure Description

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

[0028] To more clearly illustrate the technical solutions in the embodiments of this disclosure or the prior art, the accompanying drawings used in the description of the embodiments or related technologies will be briefly introduced below. Obviously, those skilled in the art can obtain other drawings based on these drawings without creative effort.

[0029] Figure 1 A schematic diagram illustrating a blockchain architecture based on master-slave chain consensus inheritance according to an embodiment of this disclosure is shown.

[0030] Figure 2 The illustration schematically depicts a process in which a blockchain architecture based on master-subchain consensus inheritance according to an embodiment of the present disclosure manages subchains, elects a master chain to obtain a consensus node list, and inherits the consensus node list between the master chain and subchains.

[0031] Figure 3 The illustration schematically shows a process of obtaining a consensus node list through consensus node election and transmitting the consensus node list between the main chain and the sub-chain in a blockchain architecture based on main-sub-chain consensus inheritance according to an embodiment of the present disclosure.

[0032] Figure 4 The diagram illustrates the ledger distribution of a blockchain architecture based on master-slave chain consensus inheritance according to an embodiment of this disclosure.

[0033] Figure 5 The illustration schematically shows the process by which the main chain obtains the sub-chain state from the sub-chain and synchronizes it to the sub-chain management contract before the main chain produces a block in a blockchain architecture based on main-sub-chain consensus inheritance, according to an embodiment of the present disclosure.

[0034] Figure 6 This illustration schematically depicts the subchain creation process in a blockchain architecture based on master-subchain consensus inheritance, where the master chain manages the lifecycle of the subchain.

[0035] Figure 7 This illustration schematically depicts the process of the main chain updating the first configuration information of the sub-chain in a blockchain architecture based on main-sub-chain consensus inheritance, according to an embodiment of this disclosure.

[0036] Figure 8 This illustration schematically depicts the subchain exit process in a blockchain architecture based on master-subchain consensus inheritance, where the master chain manages the lifecycle of the subchain.

[0037] Figure 9 A structural block diagram of a data processing apparatus according to an embodiment of the present disclosure is schematically shown; and

[0038] Figure 10 A structural block diagram of a data processing apparatus according to another embodiment of the present disclosure is shown schematically. Detailed Implementation

[0039] With the explosive growth of user numbers, the diversification of business needs, and the increasing complexity of various business operations, single-chain architectures face challenges such as low throughput, long confirmation times, and poor scalability when performing data storage or processing based on a single blockchain system (or blockchain network). This makes it difficult to meet diverse business requirements and large-scale concurrent processing. For example, a single-chain architecture processes all transactions through a single main chain, requiring a global consensus mechanism (such as PoW or PoS) for multi-node consensus verification. However, this single architecture is unsuitable for complex business needs involving different storage formats, asset types, and refined processing logic, thus limiting single-chain performance. Related technologies have proposed multi-chain blockchain architecture technology, which refers to improving system scalability and interoperability through the collaborative work of multiple blockchains.

[0040] However, during research and development, at least the following technical problems were found in the multi-chain architecture of related technologies: The interaction between the main chain and sub-chains mainly realizes cross-chain business, which is actually a collaboration between multiple sub-chains to process business. Since cross-chain interaction relies on a centralized relay mechanism, a relay role is needed (such as the main chain or other chains playing the corresponding role), which becomes a bottleneck in system performance and makes it difficult to support high-concurrency scenarios. Some solutions use sharding technology to improve parallel processing capabilities, but current sharded transactions require multiple verifications and frequent state synchronization, which significantly increases latency. Moreover, the consensus mechanisms of the main chain and sub-chains are fragmented (e.g., the main chain uses the PoS consensus mechanism, while the sub-chain uses the BFT (Byzantine Fault Tolerance) consensus mechanism), making it difficult to uniformly guarantee overall security and increasing systemic risks. For example, in some cases, the consensus mechanism supported by the main chain may not be supported by the sub-chain. In such cases, the main chain and sub-chain use different consensus mechanisms. In some cases, the reliability of the sub-chain's consensus mechanism is uncontrollable or low, which can easily lead to unreliable calculation results, thus creating systemic risks in the main-sub-chain architecture.

[0041] In view of this, the embodiments of this disclosure provide a blockchain architecture, data processing method, and apparatus based on master-slave chain consensus inheritance. By setting up a master chain to manage sub-chains, where each sub-chain has an independent business execution environment and supports independent processing of its corresponding business, and by performing consensus inheritance between the master chain and sub-chains, the overall system's high-concurrency processing capability and security are improved. By setting up a sub-chain management contract, the master chain can uniformly manage the addition of new sub-chains and the termination of existing sub-chains, while also implementing consensus inheritance functionality based on this sub-chain management contract. This improves the system's overall parallel processing capability, effectively handling high-concurrency traffic, while also enhancing system security and scalability.

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

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

[0044] Figure 1 A schematic diagram of a blockchain architecture based on master-child chain consensus inheritance according to an embodiment of the present disclosure is shown. Figure 2 The illustration schematically depicts a process in which a blockchain architecture based on master-subchain consensus inheritance according to an embodiment of the present disclosure manages subchains, elects a master chain to obtain a consensus node list, and inherits the consensus node list between the master chain and subchains. Figure 3 The illustration schematically depicts a process in which a consensus node list is obtained through consensus node election and transmitted between the main chain and the sub-chain using a blockchain architecture based on main-sub-chain consensus inheritance, according to an embodiment of the present disclosure.

[0045] Combination Figures 1-3 As illustrated in ① and ②, the blockchain architecture 100 based on master-slave chain consensus inheritance includes: a master chain 110, which is the main blockchain network; and at least one sub-chain 120, which is a sub-blockchain network, for example... Figure 2 The diagram illustrates N sub-chains, where N is a positive integer. Figure 1 The diagram illustrates two sub-chains, namely the first sub-chain 121 and the second sub-chain 122. Figure 2 The leftmost part illustrates one main chain 110 and four sub-chains. Besides the first sub-chain 121 and the second sub-chain 122, it also illustrates the third sub-chain 123 and the fourth sub-chain 124. Figure 2 In the diagram, small spheres of different colors represent the blockchain nodes (referred to as nodes) contained in the main chain 110 and sub-chains 121-124. Rectangles represent block data, and rectangles connected by arrows represent the time-series block structure corresponding to the consensus of block production (before the blockchain actually implements accounting, it will select which node to generate a new block to initiate accounting, that is, obtain the right to record accounting, and this process of generating a new block is called block production).

[0046] The main chain 110 is configured with a sub-chain management contract 111. Based on the sub-chain management contract 111, 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 by the sub-chain 120. 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. Based on the sub-chain business processing contract, transactions and consensus processing within the sub-chain are performed for the corresponding businesses. Specifically, consensus node objects in the sub-chain are determined according to the consensus node list inherited from the main chain, and consensus processing within the sub-chain is performed based on these consensus node objects. For example, in... Figure 2 The diagram uses multiple arrows pointing to the main chain and N sub-chains to indicate that the main chain and sub-chains share the same consensus node list. This reflects the consensus inheritance mechanism that obtains the consensus node list based on the main chain election mechanism and integrates this election result into the sub-chains.

[0047] Reference Figure 1 As shown, the main chain 110 contains multiple first nodes, for example, nodes A1 to A5 are included; the sub-chain contains multiple second nodes, for example, the first sub-chain 121 contains multiple second nodes: B11 to B15, and the second sub-chain 122 contains multiple second nodes: B21 to B25.

[0048] The main chain 110 is configured with the main chain business processing contract TA, the first sub-chain 121 is configured with the sub-chain business processing contract TB1, and the second sub-chain 122 is configured with the 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.

[0049] During the operation of nodes A1-A5 on the main chain 110, the main chain business processing contract TA can be invoked or deployed to process data for corresponding business transactions (e.g., processing asset transactions between companies a and b within park S1). During the operation of nodes B11-B15 on the first sub-chain 121, the sub-chain business processing contract TB1 can be invoked or deployed to process data for corresponding business transactions (e.g., on-chain notarization of data assets of companies within park S1). During the operation of nodes B21-B25 on the second sub-chain 122, the sub-chain business processing contract TB2 can be invoked or deployed to process data for corresponding business transactions (e.g., on-chain notarization of fixed equipment asset data of companies within park S1).

[0050] When a subchain (e.g., the first subchain 121) performs transactions and consensus processing for its corresponding business based on the corresponding subchain business processing contract (e.g., subchain business processing contract TB1), it can achieve data processing within the same subchain without interacting with other subchains. Multiple subchains (e.g., the first subchain 121 and the second subchain 122) can process multiple businesses in parallel or process different tasks or subtasks of the same business in parallel, thereby improving the system's parallel processing capabilities and effectively handling high-concurrency traffic.

[0051] In some embodiments, the consensus mechanism of the main chain 110 and the consensus mechanism of the sub-chain 120 are independent of each other, and the consensus mechanisms of each sub-chain are also independent of each other. Independence means that the main chain consensus mechanism and the sub-chain consensus mechanism can be different or the same, depending on the needs of their respective businesses. Similarly, the consensus mechanisms of each sub-chain can be different or the same, depending on the needs of their respective businesses.

[0052] In some exemplary scenarios, the main chain consensus mechanism corresponding to main chain 110 includes a main chain election mechanism and a main chain consensus algorithm. Figure 1 The main chain election mechanism and the main chain consensus algorithm are connected by a dashed straight line, indicating that in some cases they can be combined into one. The main chain election mechanism is used to elect multiple consensus nodes from multiple first nodes within the main chain and generate a consensus node list, for example, in... Figure 1 The dashed circles in the diagram represent the consensus nodes A1, A2, and A4 obtained through election. The main chain consensus algorithm is used by multiple first nodes on the main chain to perform consensus operations on a specific transaction, vote, etc. It is a unified set of rules or processing logic followed by distributed collaborative processing to achieve consistency in the operation results. For example, the consensus algorithm X supported by main chain 110 is the DPoS (Delegated Proof-of-Stake) consensus mechanism.

[0053] In some exemplary scenarios, the subchain consensus mechanism corresponding to subchain 120 includes a subchain election mechanism and a subchain consensus algorithm. Figure 1 The main chain election mechanism and the main chain consensus algorithm are connected by a dashed line, indicating that they are separate and will not be merged. Because in the embodiments of this 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 consensus nodes based on its own sub-chain election mechanism. This means that based on the consensus inheritance mechanism, the consensus node determination step in the sub-chain election mechanism is not used in this application, although its application in other data processing scenarios is not excluded. The sub-chain obtains the consensus node object after inheriting the corresponding consensus node list, for example, in... Figure 1The dashed circles represent consensus node objects B11, B12, and B14 obtained by inheriting the consensus node list in the first subchain 121; the dashed circles also represent consensus node objects B21, B22, and B24 obtained by inheriting the consensus node list in the second subchain 122. Subsequently, consensus processing within the subchain for related business operations is performed based on the subchain consensus algorithm; for example, in... Figure 1 The first subchain 121 performs intra-chain consensus processing for related business based on consensus algorithm Y (e.g., BFT (Byzantine Fault Tolerance) consensus mechanism); the second subchain 122 performs intra-chain consensus processing for related business based on consensus algorithm Z (e.g., PoW (Proof of Work) consensus mechanism).

[0054] 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 and corresponding blockchain accounts of the consensus nodes in the main chain may be stored simultaneously. This disclosure does not limit the specific storage format of the consensus node list, as long as a universal and unique representation standard can be formed between the main chain 110 and the sub-chain 120, and the corresponding blockchain accounts and nodes in the main chain and sub-chain can be determined based on the information in the consensus node list.

[0055] In scenarios where the main chain and sub-chains employ different consensus mechanisms, related technologies suffer from fragmented consensus mechanisms (e.g., the main chain uses PoS consensus while the sub-chain uses BFT (Byzantine Fault Tolerance) consensus), leading to difficulties in ensuring unified overall security and increasing systemic risks. In contrast, this disclosure addresses this issue by obtaining a consensus node list based on the main chain's election mechanism within the main chain, and then inheriting this list to the sub-chain through a sub-chain management contract. This consensus inheritance mechanism, where the sub-chain inherits the election results from the main chain regarding the consensus node list, ensures high reliability of the consensus nodes generated by the main chain's election results. Regardless of whether the main chain and sub-chain use the same consensus mechanisms, the consistency and reliability of the election results are guaranteed. This avoids the security risks associated with the sub-chain determining its own (potentially less reliable) consensus verification node list based on its own independent election mechanism. Furthermore, the sub-chain saves resources needed for elections by inheriting and using consensus node identities consistent with the main chain for consensus verification, thus improving the reliability of the processing results.

[0056] In some embodiments, there is a mapping relationship 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. Similarly, 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.

[0057] The example mapping relationships are: 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 sub-chains use the same blockchain account system, so AC1 and BC1 can be the same. In other application scenarios, the main chain and sub-chains 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. In this case, the blockchain account corresponding to the sub-chain node (e.g., AC1) and the blockchain account of the corresponding main chain node (e.g., BC1) can also be related but in different forms.

[0058] Specifically, determining the consensus node object in the sub-chain based on 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 above mapping relationship to obtain the 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.

[0059] For example, based on the mapping relationship {AC1→BC1; AC2→BC2; AC3→BC3; AC4→BC4; AC5→BC5}, the first consensus node accounts corresponding to nodes A1, A2, and A4 in the consensus node list, and the second consensus node accounts corresponding to nodes AC1, AC2, and AC4 in the subchain, are BC1, BC2, and BC4, respectively. Then, based on BC1, BC2, and BC4, the corresponding consensus node objects are determined to be nodes B11, B12, and B14 in the first subchain 121.

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

[0061] During the transaction processing of the corresponding business based on the corresponding subchain business processing contract in the target subchain, after the consensus condition is triggered, a query request is initiated to the subchain 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 subchain, which includes the latest consensus node list. The target subchain determines the target consensus node object based on the latest consensus node list obtained by the query and performs consensus processing within the subchain based on the target consensus node object.

[0062] In the embodiments disclosed herein, the subchain configuration information includes the following general configuration information (chain 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; the fee information includes: the amount of gas initially reserved for the account (gas refers to a unit used to measure the amount of computational work required to perform a specific operation on the blockchain), and the minimum transaction gas fee; the block reward configuration parameter includes: reward period reward_period, initial reward value reward_init_value, reward decay reward_decay, etc.) and a unified consensus node list (validatorspool) for all subchains. This list can be accessed and obtained through a preset interface provided by the subchain management contract (e.g., in the form of IP address: 192.168.x.xx:xxx).

[0063] In the above system architecture, the deployment and operation of the main chain and sub-chains are decoupled, allowing them to be deployed on different devices. The main chain and sub-chains possess independent consensus mechanisms and transaction processing capabilities. The main chain deploys a sub-chain management contract to centrally manage the sub-chains, enabling management of sub-chain creation, exit, recovery after exit, termination, and consensus node list sharing. In some application scenarios, the main chain supports the DPoS consensus mechanism and dynamically adjusts the consensus node list through voting; the sub-chain does not support DPoS, but its consensus node election process does not need to be executed on the sub-chain. It directly inherits and adopts the election results of the main chain, or uses the latest election results queried before block consensus is produced, maintaining consistency with the main chain. The consensus node list selected by the main chain is inherited and adopted by the sub-chain without the sub-chain needing to separately elect consensus nodes corresponding to in-chain transactions, achieving the inheritance and reuse of the main chain's election results, thus maintaining consistency and security.

[0064] Figure 4 The diagram illustrates the ledger distribution of a blockchain architecture based on master-slave chain consensus inheritance according to an embodiment of this disclosure. Figure 5The illustration schematically depicts the process by which the main chain obtains the sub-chain state from the sub-chain and synchronizes it to the sub-chain management contract before the main chain produces a block in a blockchain architecture based on main-sub-chain consensus inheritance, according to an embodiment of this disclosure.

[0065] In the embodiments of this disclosure, the deployment of the main chain 110 and the sub-chain 120 are independent of each other, and their respective ledger data is isolated, such as... Figure 4 As shown, the main chain ledger and the sub-chain ledger are isolated from each other.

[0066] Reference Figure 4 The diagram on the left illustrates the account databases in the main chain and sub-chains. These databases store on-chain account data. In this embodiment, the consensus node account configuration of the sub-chain is consistent with that of the main chain. Therefore, the data containing the consensus node list in the respective account databases of the main chain ledger data and the sub-chain ledger data is identical. In other embodiments, the blockchain accounts of the main chain nodes and the blockchain accounts of the sub-chain nodes have related but different forms.

[0067] In addition, refer to Figure 5 As shown, before consensus is reached and a block is produced, the main chain calls the sub-chain management contract to publish a transaction to query 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.

[0068] Reference Figure 5 As shown, the specific process is as follows: after the consensus condition is triggered in the main chain, the latest state of the sub-chain is obtained from the sub-chain, referring to... Figure 5 The process corresponding to number ① is shown below: After obtaining the latest state of all subchains, the subchain state within the aforementioned subchain management contract is updated based on the latest state of all subchains. (Refer to...) Figure 5 The process corresponding to number ② in the middle section is as follows: During or after the subchain state update, consensus processing within the main chain is performed, i.e., consensus block production, as shown in the reference. Figure 5 The process corresponding to number ③ in the middle is shown.

[0069] When the processing scenario that triggers the consensus condition on the main chain is unrelated to the state of the sub-chain, the main chain performs the corresponding transaction and consensus processing based on the main chain business processing contract, and can execute the consensus processing within the main chain during or after the sub-chain state update.

[0070] When the processing scenario that triggers the consensus condition on the main chain is related to the state of the sub-chain, the main chain performs the corresponding transaction and consensus processing based on the main chain business processing contract, and executes the consensus processing within the main chain after the sub-chain state is updated.

[0071] Figure 6This illustration schematically depicts the subchain creation process in a blockchain architecture based on master-subchain consensus inheritance, where the master chain manages the lifecycle of the subchain. Figure 7 This illustration schematically depicts the process of the main chain updating the first configuration information of the sub-chain in a blockchain architecture based on main-sub-chain consensus inheritance, according to an embodiment of this disclosure. Figure 8 This illustration schematically depicts the subchain exit process in a blockchain architecture based on master-subchain consensus inheritance, where the master chain manages the lifecycle of the subchain.

[0072] In some embodiments, combined with Figures 6-8 As shown, the above blockchain architecture also includes: the main chain manages the lifecycle of the sub-chain based on the sub-chain management contract. The lifecycle management includes executing at least one of the following preset action instructions on the sub-chain: creation instruction, exit instruction, exit and rejoin instruction, or termination instruction.

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

[0074] For example in Figure 6 The number ① in the diagram indicates a user's proposal to create a subchain on the main chain. In this disclosed application scenario, any user has the authority to submit a proposal to create a new subchain, and the proposal must be approved by a vote of all administrators before a new subchain can be created. Figure 8 The number ① in the middle indicates that the subchain owner initiated a proposal transaction request to withdraw from the subchain.

[0075] Subsequently, the main chain, based on the administrator nodes corresponding to the queried list of contract administrators, performs consensus voting on proposal transaction requests for creating, leaving, rejoining, or terminating subchains, obtaining the proposal transaction processing results. Taking the creation of a subchain as an example, refer to... Figure 6 As shown in the consensus voting process corresponding to number ②, the consensus voting process requires, for example, verifying whether the identity of the user initiating the proposal transaction request is genuine, verifying whether the user initiating the request has the corresponding permissions, and verifying whether the configuration information in the proposal transaction request is legal. Figure 8 The simplified illustration shows the same execution process, highlighting only the different parts of the updated configuration information.

[0076] The aforementioned contract administrator list, by default, uses a consensus node list. When contract administrators submit requests to join or leave, the list is dynamically updated after an election based on the main chain's voting admission and exit mechanisms. The voting subjects for these mechanisms are all current contract administrators. The admission and exit mechanisms can be: admission or exit is granted by a unanimous vote; or admission or exit is granted if more than a preset number or percentage of administrators vote; or, the admission mechanism requires unanimous approval from all administrators, while the exit mechanism allows individual withdrawal requests to be approved immediately.

[0077] Subsequently, the main chain updates the configuration information of the corresponding sub-chains based on the transaction processing results of the aforementioned proposal; the update process includes at least one of the following: adding, clearing, or synchronizing the latest information in the consensus node list. (Refer to...) Figure 6 As shown in section ③, the process of storing or updating subchain configuration information involves, for example, adding the consensus node list information when creating a subchain. Conversely, exiting a subchain involves clearing the consensus node list information. (Refer to...) Figure 8 The process of updating the consensus node list to be empty is shown in section number ②.

[0078] In embodiments of this disclosure, the above updates include at least one of the following:

[0079] For 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 to create the subchain has passed, the information of 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, so as to obtain the target configuration information of the subchain to be created.

[0080] In response to the proposal transaction processing result indicating that the proposal transaction to exit the subchain has been 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 make new transactions but supports historical transaction queries.

[0081] In response to the proposal transaction processing result indicating that the proposal transaction for rejoining the subchain after exiting has been approved, the consensus node list in the target configuration information for rejoining the subchain after exiting will be restored from a cleared state to be synchronized with the current election results of the main chain, so that new transactions can be carried out after rejoining the subchain after exiting.

[0082] In response to the proposal transaction processing result indicating that the proposal transaction to terminate the subchain has been passed, the target configuration information of the subchain to be terminated is cleared and the status of the subchain to be terminated is set to disabled.

[0083] In some embodiments, if the above-mentioned proposal transaction processing result indicates that the proposal transaction has passed, the proposal transaction-related information and target configuration information of the subchain are stored in the above-mentioned subchain management contract.

[0084] After the main chain stores or updates the sub-chain configuration information, the sub-chain nodes can be deployed and run on the device based on the above configuration information. (Refer to...) Figure 6 As shown in step ④, the process of obtaining subchain configuration information involves calling the subchain management contract in the main chain to query the corresponding target configuration information during the process of creating a new subchain on the target device.

[0085] Reference Figure 6 As shown in step ⑤, the process of generating a local configuration file involves generating the configuration file corresponding to the newly created sub-chain node on the target device based on the target configuration information described above.

[0086] Reference Figure 6 As shown in step ⑥, the process of deploying and running a new sub-chain node involves starting and configuring the node on the target device based on the above configuration file to complete the deployment and operation of the new sub-chain node.

[0087] In some embodiments, the above blockchain architecture further includes: (referring to...) Figure 7 As shown, during the operation of the subchain node, after receiving the first configuration information update instruction locally, the subchain node calls the subchain management contract to synchronously update the subchain configuration information in the main chain. The first configuration information does not include the consensus node list. For example, the first configuration information is the reserved gas fee, minimum gas parameter, etc.

[0088] This update method ensures consistency between the local configuration information of the subchain nodes and the information managed in the main chain. The configuration update process synchronously updates the content stored in the subchain management contract in the main chain. There is no need to set up other steps to synchronize the local configuration update data of the subchain nodes with the configuration information of the nodes managed in the main chain. It directly calls the subchain management contract to update and synchronize when there is an update in the subchain node. This is efficient and ensures data consistency between the main chain and the subchain. It reflects the management efficiency and timely data synchronization of the subchain management contract, and ensures the accuracy of processing business data on the main chain that may be related to the subchain status.

[0089] In the embodiments of this disclosure, the consensus node list obtained from the main chain election is dynamically updated over time. During the operation of the sub-chain nodes, 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 using at least one of the following methods:

[0090] Based on a preset period, query the subchain management contract for the latest consensus node list in the subchain configuration information; or...

[0091] Receive updates from the main chain regarding the consensus node list in the sub-chain configuration information; or,

[0092] After the consensus condition is triggered in the subchain, the latest list of consensus nodes in the subchain configuration information is queried from the subchain management contract.

[0093] 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 child chain nodes, enabling the child chain nodes to perform consensus verification based on the latest consensus node list, thus allowing the child chain to inherit the election results of reliable consensus nodes after the main chain is updated.

[0094] In some embodiments of this disclosure, to enhance the credibility of the consensus node list elected by the main chain election mechanism, a multi-dimensional reputation evaluation mechanism is implemented. This includes cross-validation of off-chain trusted data (such as CA certificates and hardware fingerprints) with on-chain behavioral data, and the use of TEE (Trusted Execution Environment) for encrypted data collection. This approach aims to reduce the risk of Sybil attacks. Furthermore, the dynamic nature of the consensus node list is based on a dynamic elimination mechanism. A dual-threshold monitoring module enables dual monitoring at both the hardware and protocol layers. At the hardware layer, node device health is monitored (e.g., CPU / memory / network usage threshold alarm policies). At the protocol layer, compliance of consensus behavior is monitored (e.g., monitoring for proposal timeouts and signature anomalies). A tiered penalty rule is set for non-compliant behaviors, such as reducing the reputation value by 5% for delay-related behaviors, deducting 10% of the staked funds for each instance of malicious behavior, and forcing the node offline for a preset duration if the number of malicious behaviors reaches a preset threshold. In some embodiments, the main chain election mechanism can also achieve fairness and reliability through anti-collusion random election algorithms, such as a VRF (Verifiable Random Function)-based random election mechanism.

[0095] The blockchain architecture provided in this embodiment physically decouples the main chain from multiple sub-chains, but logically coordinates their operation through management contracts. Sub-chains can operate independently, achieving consensus and producing blocks, while the main chain is responsible for recording the state and managing the lifecycle of the sub-chains. A sub-chain management contract deployed on the main chain is proposed to uniformly manage the lifecycle of sub-chains, including creation, initial configuration, configuration updates, exit, rejoining after exit, and termination. Operations on sub-chains require administrator proposals and a vote by all members, exhibiting decentralized governance characteristics. A cross-chain state synchronization mechanism is provided: before each consensus block production, the main chain proactively queries all sub-chains for the latest state and uploads the state information to the chain. In some embodiments, the main chain uses a DPoS+BFT hybrid consensus, while the sub-chains use pure BFT. The consensus node list is uniformly maintained by the main chain, and the sub-chain consensus inherits the security of the main chain. The main and sub-chain databases are completely isolated, with sub-chains having independent account systems, but consensus accounts maintain consistency. A secure exit mechanism is provided: the main chain management contract clears the consensus node list, invalidating the sub-chain consensus and achieving a frozen state, while still supporting the query of historical data. The initial configuration information of the subchain can be dynamically adjusted by the subchain owner and take effect in real time. Overall, it has advantages such as higher overall system security, high data processing throughput, isolation between the main chain ledger and the subchain ledger, independent deployment of subchains and easy expansion, and the amount of synchronized data in the subchain ledger in the main-subchain architecture is much smaller than the amount of synchronized data in a single chain architecture, resulting in less data synchronization pressure.

[0096] In summary, the blockchain architecture of this embodiment physically decouples the main chain from multiple sub-chains, while logically coordinating their operation through sub-chain management contracts. By setting up a main-sub-chain architecture where the main chain manages the sub-chains, each sub-chain has an independent business execution environment and supports independent processing of its corresponding business, and consensus inheritance is implemented between the main chain and sub-chains, the overall system's high-concurrency processing capability and security are improved. By obtaining a consensus node list based on the main chain's election mechanism in the main chain and inheriting this consensus node list to the sub-chains through the sub-chain management contract, the consistency and reliability of the election results between the main chain and sub-chains are guaranteed, regardless of whether the consensus mechanisms of the main chain and sub-chains are the same. This avoids the security risks caused by sub-chains determining another set of node lists for consensus verification (which may have lower reliability) based on their own independent internal election mechanisms. Simultaneously, the sub-chains save on corresponding election... The system inherits the consensus node identity consistent with the main chain to participate in consensus verification, thus improving the reliability of the processing results. Moreover, when a subchain performs transactions and consensus processing within its corresponding business based on its subchain business processing contract, it can achieve data processing within the same subchain without interacting with other subchains. Multiple subchains can process various businesses in parallel or process different tasks or subtasks of the same business in parallel. At the same time, the main chain can uniformly manage the addition of new subchains and the termination of existing subchains based on the subchain management contract, which is flexible in expansion and control, improves the overall parallel processing capability of the system, effectively handles high concurrency traffic, and enhances the system's security and scalability.

[0097] A second exemplary embodiment of this disclosure provides a data processing apparatus.

[0098] Figure 9 A schematic block diagram of a data processing apparatus according to an embodiment of the present disclosure is shown.

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

[0100] The aforementioned 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.

[0101] The aforementioned first consensus inheritance module 920 is used to inherit the aforementioned consensus node list to the sub-chain based on the aforementioned sub-chain management contract; wherein, the aforementioned sub-chain is a sub-blockchain network, and when the sub-chain performs independent processing of corresponding business, it determines the consensus node objects in the sub-chain based on the consensus node list inherited from the main chain and performs consensus processing within the sub-chain based on the aforementioned consensus node objects.

[0102] The aforementioned subchain management module 930 is used to manage the lifecycle of the subchain based on the aforementioned subchain management contract.

[0103] 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.

[0104] The data processing device in this embodiment can uniformly manage subchains based on subchain management contracts, and its expansion and control are flexible. At the same time, consensus inheritance between the main chain and subchains helps to ensure that the main chain and subchains can independently process their respective businesses while ensuring the security of the entire main chain-subchain system. The main chain also supports the processing of independent businesses, as well as data calls for related businesses between the main chain and subchains.

[0105] A third exemplary embodiment of this disclosure provides a data processing apparatus.

[0106] Figure 10 A structural block diagram of a data processing apparatus according to another embodiment of the present disclosure is shown schematically.

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

[0108] The aforementioned 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.

[0109] The aforementioned 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. Specifically, it 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 the aforementioned consensus node objects.

[0110] 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.

[0111] The data processing device in this embodiment inherits the consensus node list obtained from the main chain election, which helps ensure that the main chain and sub-chains can independently process their respective businesses while maintaining the security of the entire main-sub-chain system. Each sub-chain can independently process its corresponding business, including sub-chain transactions, inheriting the consensus node list, and independent consensus processing. Performance increases linearly, and transaction throughput is high. The isolation between the main chain ledger and the sub-chain ledger, the independent deployment and easy expansion of sub-chains, and the fact that the amount of synchronized data in the sub-chain ledger in the main-sub-chain architecture is much smaller than the amount of synchronized data in a single-chain architecture all contribute to lower data synchronization pressure.

[0112] The fourth exemplary embodiment of this disclosure provides a data processing method based on the blockchain architecture of the first embodiment described above.

[0113] The above methods include:

[0114] The target sub-link receives the data processing request for the corresponding business, or the main link receives the data processing request for the sub-link business and forwards it to the corresponding target sub-link;

[0115] The target subchain performs corresponding business transactions and subchain consensus processing based on the corresponding subchain business processing contract. Specifically, the consensus node objects in the subchain are determined according to the consensus node list inherited from the main chain, and the subchain consensus processing is executed based on the aforementioned consensus node objects.

[0116] In some embodiments, the above data processing method further includes:

[0117] After the consensus condition is triggered in the main chain, the latest state of the sub-chain is obtained from the sub-chain; after obtaining the latest state of all sub-chains, the sub-chain state in the aforementioned sub-chain management contract is updated according to the latest state of all sub-chains; consensus processing in the main chain is performed during or after the sub-chain state update.

[0118] When the processing scenario that triggers the consensus condition on the main chain is unrelated to the state of the sub-chain, the main chain performs the corresponding transaction and consensus processing based on the main chain business processing contract, and can execute the consensus processing within the main chain during or after the sub-chain state update.

[0119] When the processing scenario that triggers the consensus condition on the main chain is related to the state of the sub-chain, the main chain performs the corresponding transaction and consensus processing based on the main chain business processing contract, and executes the consensus processing within the main chain after the sub-chain state is updated.

[0120] In some embodiments, the consensus triggering condition of the main chain can be the processing of a corresponding processing scenario based on the main chain business processing contract.

[0121] More details and beneficial effects of this embodiment can be found in the relevant description of the first embodiment, which will not be repeated here.

[0122] Any plurality of the functional modules included in the data processing apparatus 900 or data processing apparatus 1000 may be combined into one module, or any one of the modules may be split into multiple modules. Alternatively, at least a portion of the functionality of one or more of these modules may be combined with at least a portion of the functionality of other modules and implemented in one module. At least one of the functional modules included in the data processing apparatus 900 or data processing apparatus 1000 may be at least partially implemented as hardware circuitry, 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-package, an application-specific integrated circuit (ASIC), or any other reasonable means of integrating or packaging circuitry, or implemented in software, hardware, or firmware, or in any appropriate combination of any of these three implementation methods. Alternatively, at least one of the functional modules included in the data processing apparatus 900 or data processing apparatus 1000 may be at least partially implemented as a computer program module, which, when run, can perform corresponding functions.

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

[0124] The above description is merely a specific embodiment of this disclosure, enabling those skilled in the art to understand or implement it. 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 this disclosure. Therefore, this disclosure is not to be limited to the embodiments shown herein, but is to be accorded the widest scope consistent with the principles and novel features claimed herein.

Claims

1. A blockchain architecture based on consensus inheritance of main sub-chain, characterized in that, Comprise: a main chain, being a main blockchain network; at least one sub-chain, being a sub-blockchain network; the main chain is configured with a sub-chain management contract, based on which a consensus node list obtained by a main chain election mechanism is inherited to a sub-chain; the consensus node list obtained by the main chain election is dynamically updated over time; 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, based on which transaction processing and intra-sub-chain consensus processing of corresponding businesses are performed, wherein the consensus node objects in the sub-chain are determined according to the consensus node list inherited from the main chain, and the intra-sub-chain consensus processing is performed based on the consensus node objects. 2.The blockchain architecture of claim 1, wherein, The main chain includes a plurality of first nodes, and the sub-chain includes a plurality of second nodes, and there is a mapping relationship between the first node account corresponding to the first node and the second node account corresponding to the second node. Wherein, determining the consensus node objects in the sub-chain according to the consensus node list inherited from the main chain comprises: 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 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. 3.The blockchain architecture of claim 1, wherein, 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-3, characterized in that, in the transaction processing of the corresponding business in the target sub-chain based on the corresponding sub-chain business processing contract, after triggering the consensus condition, 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, and the latest configuration information includes: the latest consensus node list; the target consensus node object is determined according to the latest consensus node list obtained by the query, and the intra-sub-chain consensus processing is performed based on the target consensus node object. 5.The blockchain architecture according to any one of claims 1-3, characterized in that, Further comprise: The main chain manages the life cycle of the sub-chain based on the sub-chain management contract, and the life cycle management includes at least one of the following preset action instructions: creation instruction, exit instruction, rejoin after exit instruction or termination instruction; The main chain receives a proposal transaction request for creating, exiting, rejoining after exiting or terminating the sub-chain based on the sub-chain management contract; The main chain performs consensus voting processing on the proposal transaction request for creating, exiting, rejoining after exiting or terminating the sub-chain 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 the consensus node list in the default state, and the member update request for applying to join or exit the contract administrator is dynamically updated after the corresponding contract administrator list 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 proposal transaction processing result; The updating process includes at least one of the following: 6.The blockchain architecture of claim 5, wherein, In response to the proposal transaction processing result indicating that the proposal transaction of creating a sub-chain is passed, the information of the consensus node list obtained based on the main chain election mechanism is added in the initial configuration information of the sub-chain to be created to obtain the target configuration information of the sub-chain to be created. In response to the proposal transaction processing result indicating that the proposal transaction of exiting a sub-chain is passed, the information of the consensus node list in the target configuration information of the sub-chain to be exited is emptied, so that the sub-chain to be exited cannot perform new transactions but supports historical transaction query. In response to the proposal transaction processing result indicating that the proposal transaction of rejoining a sub-chain after exiting is passed, the information of the consensus node list in the target configuration information of the sub-chain rejoining after exiting is restored from the empty state to synchronization with the election result of the current main chain, so that the sub-chain rejoining after exiting can perform new transactions. In response to the proposal transaction processing result indicating that the proposal transaction of terminating a sub-chain is passed, the target configuration information of the sub-chain to be terminated is emptied and the state of the sub-chain to be terminated is set to a disabled state. In the case where the proposal transaction processing result indicates that the proposal transaction is passed, the proposal transaction related information and the target configuration information of the sub-chain are stored in the sub-chain management contract of the main chain. 7.The blockchain architecture of claim 5, wherein, In 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; the configuration file corresponding to the newly created sub-chain node is generated locally in the target device according to the target configuration information; and the node startup and configuration are performed in the target device based on the configuration file, so as to complete the deployment and running of the newly created sub-chain node. Further comprising: 8.The blockchain architecture of claim 5, wherein, During the running of the sub-chain node, after receiving a first configuration information update instruction locally in the sub-chain node, the sub-chain configuration information in the main chain is synchronously updated by calling the sub-chain management contract, and the first configuration information does not contain the consensus node list. The consensus node list obtained by the main chain election is dynamically updated over time; during the running 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 modes: The latest consensus node list in the sub-chain configuration information is queried from the sub-chain management contract based on a preset period; or The update information about the consensus node list in the sub-chain configuration information pushed by the main chain is received; or The latest consensus node list in the sub-chain configuration information is queried from the sub-chain management contract after the sub-chain triggers the consensus condition. The deployment of the main chain and the sub-chain is independent of each other, and the respective ledger data is isolated; 9.The blockchain architecture of claim 1, wherein, After triggering the consensus condition in the main chain, the latest state of the sub-chain is obtained from the sub-chain, after obtaining the latest state of all sub-chains, the sub-chain state in the sub-chain management contract is updated according to the latest state of all sub-chains, and the consensus processing in the main chain is performed during or after the sub-chain state updating; ​ When the processing scenario of the main chain triggering the consensus condition is irrelevant to the sub-chain state, the main chain performs transaction and intra-main-chain consensus processing of the corresponding processing scenario based on the main chain business processing contract, and can perform intra-main-chain consensus processing during or after the sub-chain state update; When the processing scenario of the main chain triggering the consensus condition is relevant to the sub-chain state, the main chain performs transaction and intra-main-chain consensus processing of the corresponding processing scenario based on the main chain business processing contract, and performs intra-main-chain consensus processing after the sub-chain state update.

10. A data processing apparatus, characterized by, The device is a node in a main blockchain network, and the main blockchain network is configured with a sub-chain management contract; the device comprises: An election module configured to interact with other nodes in the main blockchain network and obtain a consensus node list based on a main chain election mechanism; the consensus node list is dynamically updated over time; A first consensus inheritance module configured to inherit the consensus node list to a sub-chain based on the sub-chain management contract; the sub-chain is a sub-blockchain network, and when the sub-chain performs independent processing of corresponding business, a consensus node object in the sub-chain is determined according to the consensus node list inherited from the main chain, and intra-sub-chain consensus processing is performed based on the consensus node object; A sub-chain management module configured to perform life cycle management of the sub-chain based on the sub-chain management contract.

11. A data processing apparatus, characterized by The device is a node in a sub-blockchain network, and the device comprises: A second consensus inheritance module configured to obtain a consensus node list; the consensus node list is obtained by a main blockchain network based on a main chain election mechanism; the consensus node list is dynamically updated over time; A data processing module configured to perform transaction and intra-sub-chain consensus processing of corresponding business based on a corresponding sub-chain business processing contract, wherein a consensus node object in the sub-chain is determined according to the consensus node list inherited from the main chain, and intra-sub-chain consensus processing is performed based on the consensus node object.

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

Images