Sub-chain management method and system for distributed ledger

Abstract

Provided in the embodiments of the present disclosure are a sub-chain management method and system for a distributed ledger, which method and system are applied to a first node. The method comprises: receiving a sub-chain management application proposed by a second node; reviewing the sub-chain management application; when the sub-chain management application passes the review, generating a sub-chain management block corresponding to the application; and broadcasting the sub-chain management block to a third node for reaching multi-party consensus. By means of the present disclosure, the problems in the prior art of it being impossible for a sub-chain node of a distributed ledger to participate in the management and supervision of a sub-chain, and the sub-chain node being only capable of passively using control commands, which are all provided by a core network, are solved.

Description

Subchain Management Methods and Systems for Distributed Ledgers

[0001] Cross-references to related applications

[0002] This disclosure is based on and claims priority to Chinese patent application CN202411628787.6, filed on November 14, 2024, entitled “Subchain Management Method and System for Distributed Ledger”, the entire contents of which are incorporated herein by reference. Technical Field

[0003] This disclosure relates to the field of communications, and more specifically, to a method and system for managing subchains of a distributed ledger. Background Technology

[0004] Distributed ledgers can be implemented using multiple chains, divided into a main chain and sub-chains. Sub-chains need to meet specific requirements and configurations. However, telecommunications networks operate on a centralized control model, with all control commands issued by the core network. Sub-chain nodes cannot participate in the management and supervision of the sub-chains and can only passively use them, which contradicts the original intention of sub-chains to have customization capabilities. Summary of the Invention

[0005] This disclosure provides a method and system for managing subchains in a distributed ledger.

[0006] According to one embodiment of this disclosure, a subchain management method for a distributed ledger is provided, applied to a first node, comprising: receiving a subchain management application submitted by a second node, reviewing the subchain management application, generating a subchain management block corresponding to the application if the subchain management application is approved, and broadcasting the subchain management block to a third node for multi-party consensus.

[0007] According to another embodiment of this disclosure, a subchain management system for a distributed ledger is provided, comprising: a first node, a second node, and a third node. The first node is configured to receive a subchain management application submitted by the second node, review the subchain management application, generate a subchain management block corresponding to the application if the subchain management application is approved, and broadcast the subchain management block to the third node for multi-party consensus. The second node is configured to submit a subchain management application to the first node. The third node is configured to receive the subchain management block broadcast by the first node and perform multi-party consensus on the subchain management block.

[0008] According to yet another embodiment of this disclosure, a computer-readable storage medium is also provided, in which a computer program is stored, wherein the computer program is configured to perform the steps in any of the above method embodiments when it is run.

[0009] According to yet another embodiment of this disclosure, an electronic device is also provided, including a memory and a processor, wherein a computer program is stored in the memory and the processor is configured to run the computer program to perform the steps in any of the above method embodiments.

[0010] According to yet another embodiment of this disclosure, a computer program product is also provided, including a computer program that, when executed by a processor, implements the steps in any of the above method embodiments.

[0011] Through the embodiments described above, the first node receives and reviews the subchain management application submitted by the second node. If the application is approved, a subchain management block corresponding to the application is generated and broadcast to the third node for multi-party consensus. Therefore, this solves the problem in related technologies where subchain nodes in distributed ledgers cannot participate in the management and supervision of the subchain, and all control commands are issued by the core network, leaving them only able to passively use the system. This achieves the effect of subchain nodes flexibly and autonomously participating in the management and supervision of the subchain. Attached Figure Description

[0012] Figure 1 is a flowchart of a subchain management method for a distributed ledger according to an embodiment of the present disclosure;

[0013] Figure 2 is a structural block diagram of a subchain management system for a distributed ledger according to an embodiment of the present disclosure;

[0014] Figure 3 is a flowchart of subchain establishment according to an embodiment of the present disclosure;

[0015] Figure 4 is a flowchart of subchain parameter modification according to an embodiment of the present disclosure;

[0016] Figure 5 is a flowchart of subchain sealing according to an embodiment of the present disclosure. Detailed Implementation

[0017] The embodiments of this disclosure will be described in detail below with reference to the accompanying drawings and examples.

[0018] It should be noted that the terms "first," "second," etc., in the specification, claims, and drawings of this disclosure are used to distinguish similar objects and are not necessarily used to describe a specific order or sequence.

[0019] The convergence trend of Operation Data Information Communication Technology (ODICT) brings new elements, new ecosystems, and new models to 6G networks, with trust being one of them. Distributed ledger is a key technology for achieving inherent trust in 6G networks.

[0020] Because distributed ledgers possess characteristics such as multi-party consensus, immutability, and transparency, they enable decentralized trust and automatic execution of trust, thus becoming a key technology for 6G trust. 6G distributed ledgers have the following requirements: first, they need to achieve high-speed transaction rates to meet the tens of thousands of interactions per second required by 6G; second, they need to ensure a certain level of security, providing different security levels for different businesses, scenarios, or nodes; and third, they need customizable configurations, similar to vertical industry networks, with different parameter configurations.

[0021] Therefore, there is now a certain consensus in the industry that 6G native distributed ledgers need to have multi-chain characteristics, which can be divided into sub-chains and a main chain. The main chain is the basic chain that always exists, while sub-chains are configurable, customized chains. The two chains have different node admission lists and different parameter configurations. Sub-chains have fewer restrictions on usage compared to the main chain. For example, a specific industry can use a customized sub-chain. This characteristic requires sub-chains to have a certain degree of autonomy.

[0022] Existing public network distributed ledger subchains utilize mechanisms such as notary publics, hash locking, and sidechains. These technologies generally generate subchains that are not directly related to the original chain, and the original chain does not participate in the consensus process. In telecommunications networks, such subchain methods clearly do not meet the requirements of trust and security. Therefore, a new subchain management method is needed for telecommunications networks.

[0023] 6G native distributed ledgers are generally consortium blockchains, with members limited to a specific group and a limited number of third parties. The chain is jointly managed by these members. 6G native distributed ledgers have a multi-chain structure, consisting of a main chain and sub-chains. The main chain exists since the system's inception, with a lifespan identical to the system's. Main chain nodes can be categorized as user nodes, consensus nodes, and management nodes. Management nodes are typically handled by core network distributed ledger functional nodes; consensus nodes participate in main chain block consensus; user nodes do not participate in main chain block consensus but only use the main chain.

[0024] A subchain is a chain connected to the main chain. Each subchain must have a unique identifier, and each block within a subchain contains this identifier to identify whether the block belongs to the main chain or a specific subchain. Subchain blocks can be divided into two categories, generated using different methods: transaction blocks, which contain various transaction information, and management blocks, which contain only subchain parameter information. Subchains focus on a specific function or purpose and are highly specialized; therefore, they need the ability to adjust their parameters to ensure they always meet the actual needs of the subchain nodes. Simultaneously, to ensure the security of the subchain and achieve the same level of ledger security assurance as the main chain management nodes, subchains can employ a multi-party consensus mechanism where subchain nodes assist management nodes in generating management blocks, enabling modifications to subchain parameters.

[0025] It should be noted that all child chain nodes are main chain nodes, and a main chain node can participate in multiple different child chains. A participating main chain node can be a node in a child chain.

[0026] To address the issue in related technologies where child chain nodes of distributed ledgers cannot participate in the management and supervision of the child chain, and all control commands are issued by the core network, thus requiring passive use, this disclosure provides a child chain management method for distributed ledgers. This method can be applied to the first node. Figure 1 is a flowchart of the child chain management method for distributed ledgers according to an embodiment of this disclosure. As shown in Figure 1, the process includes the following steps:

[0027] Step S102: Receive the subchain management application submitted by the second node;

[0028] Step S104: Review the subchain management application;

[0029] Step S106: If the subchain management application is approved, generate the subchain management block corresponding to the application;

[0030] Step S108: Broadcast the subchain management block to the third node for multi-party consensus.

[0031] In one exemplary embodiment, if a subchain management application fails to pass review, the first node may notify the second node of the reason for the failure.

[0032] For example, when a subchain management application fails to pass review, the first node can discard the subchain management application and know the reason why the subchain management application failed to the second node.

[0033] In an exemplary embodiment, the subchain management application can be a subchain establishment application, the first node can be a main chain management node, the second node can be a non-main chain management node, the third node can be a main chain consensus node and other main chain management nodes different from the first node, and the subchain management block can be the subchain genesis block.

[0034] For example, a non-main chain management node can submit a sub-chain establishment application to the main chain management node. After receiving the sub-chain establishment application, the main chain management node reviews the application. If the application is approved, a sub-chain genesis block corresponding to the application is generated, and the sub-chain genesis block is broadcast to the main chain consensus nodes and other main chain management nodes that are different from the main chain management node for multi-party consensus.

[0035] The genesis block of the subchain is used to establish the subchain. The first node can be the management node of the core network to which the second node belongs; the management node is generally a distributed ledger functional unit of the core network.

[0036] In one exemplary embodiment, reviewing a subchain management application includes at least one of the following: reviewing whether the application type of the subchain establishment application matches the application content of the subchain establishment application, reviewing whether the digital signature in the subchain establishment application is the digital signature of the node participating in the subchain establishment application, and reviewing whether the application content in the subchain establishment application complies with the distributed ledger rules.

[0037] In an exemplary embodiment, if the subchain management application is approved, generating the subchain management block corresponding to the subchain management application includes: generating a subchain identifier and digitally signing the subchain establishment application to form a subchain establishment transaction, generating the subchain genesis block, and writing the subchain establishment transaction into the subchain genesis block.

[0038] The subchain identifier can be in the form of a subchain number or code.

[0039] In one exemplary embodiment, generating a subchain identifier includes: generating a subchain identifier based on the receipt time of the subchain establishment application and the identifier of the first node.

[0040] For example, a subchain identifier can also be generated based on various information such as information about the subchain's use for a specific business scenario or function, random or pseudo-random numbers, serial numbers or version numbers, geographical location or region identifiers, cryptographic hashes, etc.

[0041] In one exemplary embodiment, after broadcasting the subchain management block to a third node for multi-party consensus, the process includes: establishing a subchain and determining the main chain management node as the subchain supervisor node if the subchain genesis block is recognized by the third node.

[0042] For example, the genesis block of a subchain needs to go through a certain consensus process. If the requirements of the consensus rules are met, the genesis block of the subchain is recognized, and the subchain will be formally established only after the genesis block of the subchain is recognized. The consensus rules can be determined according to the needs of the actual application scenario, and this embodiment of the disclosure does not impose any restrictions.

[0043] In an exemplary embodiment, the application content of the subchain establishment application includes at least one of the following: subchain parameters, digital signatures of the subchain establishment application by the nodes participating in the subchain establishment application, wherein the nodes participating in the subchain establishment application include the second node that made the application and other second nodes.

[0044] The subchain parameters include at least one of the following: the consensus rules for the subchain management block, the identifier of the node participating in the subchain establishment application, and the form of the subchain smart contract.

[0045] The consensus rules for subchain management blocks include at least one of the following: the node type of the third node, the first predetermined number of block intervals or predetermined time intervals between two subchain modified blocks that include the same parameter.

[0046] The subchain parameters are determined either by the second node that made the application or by the second node that made the application in consultation with other second nodes.

[0047] For example, the subchain parameters may also include the consensus rules of the subchain transaction blocks, wherein the consensus rules of the subchain transaction blocks can be determined according to the needs of the actual application scenario, and this disclosure embodiment does not impose any limitations.

[0048] Among them, the consensus rules for managing subchain blocks, which include the first predetermined number of block intervals or predetermined time intervals between two subchain modified blocks with the same parameter, are designed to prevent frequent disturbances of the parameter.

[0049] For example, when there is a node that wants to establish a subchain (i.e., a node participating in the subchain establishment application), this node can be a second node, meaning that the subchain parameters are determined by this second node itself. When there are multiple nodes that want to establish a subchain (i.e., multiple nodes participating in the subchain establishment application), this node can be the second node that made the application, along with other second nodes. In other words, the subchain parameters need to be negotiated and determined by the multiple participating nodes. After the negotiation, the second node that made the application submits a subchain establishment application containing the subchain parameters to the first node.

[0050] In one exemplary embodiment, the subchain genesis block includes at least one of the following: a block identifier of the subchain genesis block, subchain parameters, identifiers of nodes participating in the subchain establishment application, digital signatures of nodes participating in the subchain establishment application for the subchain establishment application, identifier of a first node, and digital signatures of the first node for the subchain establishment application.

[0051] In an exemplary embodiment, the subchain management application is a subchain parameter modification application, the first node is the subchain supervisor node, the second node is the subchain non-supervisor node, the third node is the main chain consensus node and other main chain management nodes different from those in the first section, and the subchain management block is the subchain modification block, wherein the subchain supervisor node and the subchain non-supervisor node are nodes on the same subchain.

[0052] For example, a non-manager node of a subchain can submit a subchain parameter modification request to the subchain manager node. After receiving the subchain parameter modification request, the subchain manager node reviews the request. If the review is successful, it generates a subchain modification block corresponding to the subchain parameter modification request and broadcasts the subchain modification block to the main chain consensus nodes and other main chain management nodes that are different from the subchain manager node for multi-party consensus.

[0053] In this implementation, the subchain modification block is used to modify the subchain parameters. The subchain manager node is the main chain management node that establishes the subchain genesis block. The subchain modification block needs to go through a certain consensus process; only if the consensus rules are met will the subchain modification block be recognized. The consensus rules can be determined according to the needs of the actual application scenario, and this embodiment does not impose any limitations.

[0054] In one exemplary embodiment, a subchain parameter modification application may include at least one of the following: subchain parameter modification information, and digital signatures of nodes participating in the subchain parameter modification application. In one exemplary embodiment, reviewing a subchain management application includes at least one of the following: reviewing whether the application type of the subchain parameter modification application matches the application content; reviewing whether the subchain parameter modification information in the application content is correct; reviewing whether the number of digital signatures in the subchain parameter modification application reaches a second predetermined number; and reviewing whether the digital signatures are digital signatures of nodes participating in the subchain parameter modification application.

[0055] The second predetermined quantity can be specified in the subchain management block consensus rules, the subchain transaction block consensus rules, or in other forms; this disclosed embodiment does not impose any restrictions. Verifying whether the digital signature belongs to the node participating in the subchain parameter modification application is to check the authenticity of the digital signature and prevent cases of proxy signing or incorrect signing.

[0056] In an exemplary embodiment, if the subchain management application is approved, generating the subchain management block corresponding to the subchain management application includes: digitally signing the subchain parameter modification application, generating the subchain modification block, and writing the subchain parameter modification application and the first node's digital signature of the subchain parameter modification application into the subchain modification block.

[0057] In one exemplary embodiment, the subchain modification block includes at least one of the following: a block identifier of the subchain modification block, subchain parameter modification information, digital signatures of the nodes participating in the subchain parameter modification request on the subchain parameter modification request, and digital signatures of the first node on the subchain parameter modification request.

[0058] In one exemplary embodiment, a block generated after the sub-chain modification block and traced back to the sub-chain modification block is a valid block; a block generated after the sub-chain modification block and not traced back to the sub-chain modification block is an invalid block.

[0059] In an exemplary embodiment, the subchain management application is a subchain sealing application, the first node is the subchain supervisor node, the second node is the subchain non-supervisor node, the third node is the main chain consensus node and other main chain management nodes different from the first node, and the subchain management block is the subchain sealing block, wherein the subchain supervisor node and the subchain non-supervisor node are nodes on the same subchain.

[0060] For example, a non-manager node of a subchain can submit a subchain sealing application to the subchain manager node. After receiving the subchain sealing application, the subchain manager node reviews the application and generates a subchain sealing block corresponding to the application if the review is successful. The subchain sealing block is then broadcast to the main chain consensus nodes and other main chain management nodes that are different from the subchain manager node for multi-party consensus.

[0061] In this embodiment, the subchain genesis block is configured to implement the sealing of the subchain. The subchain master node is the main chain management node that establishes the subchain genesis block. The subchain genesis block needs to go through a certain consensus process; only if the requirements of the consensus rules are met will the subchain genesis block be recognized. The consensus rules can be determined according to the needs of the actual application scenario, and this embodiment does not impose any limitations.

[0062] In one exemplary embodiment, a subchain sealing application may include at least one of the following: subchain sealing information, and digital signatures of nodes participating in the subchain sealing application. In one exemplary embodiment, reviewing a subchain management application includes at least one of the following: reviewing whether the application type of the subchain sealing application matches the application content; reviewing whether the subchain sealing information in the application content is correct if it is not empty; reviewing whether the number of digital signatures in the subchain sealing application reaches a third predetermined number; and reviewing whether the digital signatures are digital signatures of nodes participating in the subchain sealing application.

[0063] The third predetermined quantity can be specified in the subchain management block consensus rules, the subchain transaction block consensus rules, or in other forms; this disclosed embodiment does not impose any restrictions. Verifying whether the digital signature belongs to the node participating in the subchain sealing application is to check the authenticity of the digital signature and prevent cases of proxy signing or incorrect signing.

[0064] For example, a subchain can be sealed when a subchain node exits, resulting in too few subchain nodes, or when there are other situations requiring the subchain to be closed.

[0065] In an exemplary embodiment, if the subchain management application is approved, generating the subchain management block corresponding to the subchain management application includes: digitally signing the subchain sealing application, generating the subchain sealing block, and writing the subchain sealing application and the first node's digital signature on the subchain sealing application into the subchain sealing block.

[0066] In one exemplary embodiment, the subchain sealed block includes at least one of the following: a block identifier of the subchain sealed block, a digital signature of the subchain sealed application by a node participating in the subchain sealed application, and a digital signature of the subchain sealed application by a first node.

[0067] In one exemplary embodiment, the subchain sealed block can be traced back to all valid blocks in the subchain to ensure that the subchain sealed block is the last block in the subchain; blocks generated after the subchain sealed block are invalid blocks.

[0068] In an exemplary embodiment, the structure of the application includes the application type and the application content; the application type includes subchain establishment, subchain parameter modification, and subchain sealing; different application types are represented by different serial numbers or codes.

[0069] In one exemplary embodiment, the application content refers to the specific application details, which varies depending on the type of application. It can also be blank, such as in a subchain sealing application.

[0070] Through the above steps, the problem that child chain nodes in distributed ledgers cannot participate in the management and supervision of the child chain in related technologies, and that all control commands are given by the core network and can only be used passively, is solved. This enables child chain nodes to flexibly and autonomously participate in the management and supervision of the child chain.

[0071] Through the above description of the embodiments, those skilled in the art can clearly understand that the methods according to the above embodiments can be implemented by means of software plus necessary general-purpose hardware platforms. Of course, they can also be implemented by hardware, but in many cases the former is a better implementation method. Based on this understanding, the technical solutions of this disclosure, in essence or the part that contributes to the prior art, can be embodied in the form of a software product. This computer software product is stored in a storage medium (such as ROM / RAM, magnetic disk, optical disk) and includes several instructions to cause a terminal device (which may be a mobile phone, computer, server, or network device, etc.) to execute the methods of the various embodiments of this disclosure.

[0072] This embodiment also provides a sub-chain management system for a distributed ledger, which is used to implement the above embodiments and preferred embodiments; details already described will not be repeated. As used below, the term "module" can refer to a combination of software and / or hardware that implements a predetermined function. Although the apparatus described in the following embodiments is preferably implemented in software, hardware implementation, or a combination of software and hardware, is also possible and contemplated.

[0073] Figure 2 is a structural block diagram of a subchain management system for a distributed ledger according to an embodiment of the present disclosure. As shown in Figure 2, the system 20 includes a first node, a second node, and a third node, characterized in that...

[0074] The first node 22 is set to receive subchain management applications from the second node, review the subchain management applications, generate the subchain management block corresponding to the application if the subchain management application is approved, and broadcast the subchain management block to the third node for multi-party consensus.

[0075] The second node, 24, is configured to submit a subchain management request to the first node.

[0076] The third node, 26, is configured to receive the sub-chain management block broadcast by the first node and to conduct multi-party consensus on the sub-chain management block.

[0077] It should be noted that the above modules can be implemented by software or hardware. For the latter, they can be implemented in the following ways, but are not limited to: all the above modules are located in the same processor; or, the above modules are located in different processors in any combination.

[0078] Example 1

[0079] This embodiment is an example of subchain establishment. Figure 3 is a flowchart of subchain establishment according to an embodiment of this disclosure. As shown in Figure 3, the specific method is as follows:

[0080] S301, Determine Subchain Parameters. One or more nodes wishing to establish a subchain negotiate the subchain parameters, which include at least one of the following: the consensus rules for the subchain management blocks, the identifiers of the nodes participating in the subchain establishment application, and the form of the subchain smart contract. If only one node participates in the subchain establishment application, this node can decide the subchain parameters independently without negotiation. If more than one node participates in the subchain establishment application, all participating nodes need to negotiate to determine the subchain parameters.

[0081] S302, Non-main chain management nodes submit a sub-chain establishment application to the main chain management node. The sub-chain establishment application includes at least one of the following: sub-chain parameters, digital signatures of the sub-chain establishment application by the nodes participating in the sub-chain establishment application.

[0082] S303, The main chain management node reviews the received sub-chain establishment applications, which may include at least one of the following:

[0083] The review process includes verifying whether the application type of the subchain establishment application matches the application content, verifying whether the digital signature in the subchain establishment application is the digital signature of the node participating in the subchain establishment application, and verifying whether the application content in the subchain establishment application complies with the distributed ledger rules.

[0084] If a subchain creation application fails verification, the application will be discarded, and the main chain management node will notify the non-main chain management nodes of the reason for the failure.

[0085] S304. Upon approval of the subchain establishment application, the main chain management node generates a subchain identifier and digitally signs the application to form a subchain establishment transaction. The main chain management node then generates the subchain genesis block and writes the subchain establishment transaction into it. The subchain identifier is generated by the main chain management node based on the time the application was received and the node's identifier.

[0086] S305, the main chain management node broadcasts the genealogy block of the sub-chain to the main chain consensus node and other main chain management nodes that are different from the main chain management node for multi-party consensus. When the genealogy block of the sub-chain is recognized by the main chain consensus node and other main chain management nodes that are different from the main chain management node, the sub-chain is established and the main chain management node is determined as the sub-chain supervisor node.

[0087] Example 2

[0088] This embodiment is an example of subchain parameter modification. Figure 4 is a flowchart of subchain parameter modification according to an embodiment of this disclosure. As shown in Figure 4, the specific method is as follows:

[0089] S401, a non-supervisor node of the subchain submits a subchain parameter modification request to the supervisor node of the subchain. The subchain parameter modification request may include at least one of the following: subchain parameter modification information, or digital signatures of the nodes participating in the subchain parameter modification request.

[0090] S402, Subchain supervisor node reviews subchain parameter modification requests, which may include at least one of the following:

[0091] The review process includes verifying whether the application type and content of the subchain parameter modification application match, whether the subchain parameter modification information in the application content is correct, whether the number of digital signatures in the subchain parameter modification application reaches the second predetermined number, and whether the digital signatures belong to the nodes participating in the subchain parameter modification application.

[0092] If a subchain parameter modification request fails to pass review, discard the request and notify the non-supervisor nodes of the subchain of the reason for the failure.

[0093] S403, if the subchain parameter modification application is approved, the subchain supervisor node digitally signs the subchain parameter modification application, generates a subchain modification block, and writes the subchain parameter modification application and the subchain supervisor node's digital signature on the subchain parameter modification application into the subchain modification block.

[0094] S404, the subchain supervisor node broadcasts the modified subchain block to the main chain consensus node and other main chain management nodes that are different from the subchain supervisor node to achieve multi-party consensus.

[0095] Example 3

[0096] This embodiment is an example of subchain sealing. Figure 5 is a flowchart of subchain sealing according to an embodiment of this disclosure. As shown in Figure 5, the specific method is as follows:

[0097] S501, a non-supervisor node of the subchain submits a subchain sealing request to the subchain supervisor node. The subchain sealing request may include at least one of the following: subchain sealing information, digital signatures of the nodes participating in the subchain sealing request.

[0098] S502, the subchain supervisor node reviews the subchain sealing application, which may include at least one of the following:

[0099] The review process includes verifying whether the application type and content of the subchain sealing application match, verifying the correctness of the subchain sealing information if the subchain sealing information in the application content is not empty, verifying whether the number of digital signatures in the subchain sealing application reaches the third predetermined number, and verifying whether the digital signatures are those of the nodes participating in the subchain sealing application.

[0100] If a subchain sealing application is approved, the subchain supervisor node discards the application and notifies the non-supervisor nodes of the reason for the rejection.

[0101] S503: If the subchain management application is approved, the subchain supervisor node digitally signs the subchain sealing application, generates a subchain sealing block, and writes the subchain sealing application and the subchain supervisor node's digital signature on the subchain sealing application into the subchain sealing block.

[0102] S504, the subchain supervisor node broadcasts the subchain sealed blocks to the main chain consensus nodes and other main chain management nodes that are different from the subchain supervisor node to achieve multi-party consensus.

[0103] Embodiments of this disclosure also provide a computer-readable storage medium storing a computer program configured to perform the steps in any of the above method embodiments when executed.

[0104] In one exemplary embodiment, the aforementioned computer-readable storage medium may include, but is not limited to, various media capable of storing computer programs, such as a USB flash drive, read-only memory (ROM), random access memory (RAM), portable hard disk, magnetic disk, or optical disk.

[0105] Embodiments of this disclosure also provide an electronic device including a memory and a processor, the memory storing a computer program and the processor being configured to run the computer program to perform the steps in any of the above method embodiments.

[0106] In one exemplary embodiment, the electronic device may further include a transmission device and an input / output device, wherein the transmission device is connected to the processor and the input / output device is connected to the processor.

[0107] Specific examples in this embodiment can be found in the examples described in the above embodiments and exemplary implementations, and will not be repeated here.

[0108] It is obvious to those skilled in the art that the modules or steps of this disclosure described above can be implemented using general-purpose computing devices. They can be centralized on a single computing device or distributed across a network of multiple computing devices. They can be implemented using computer-executable program code, and thus can be stored in a storage device for execution by a computing device. In some cases, the steps shown or described can be performed in a different order than those presented herein, or they can be fabricated as separate integrated circuit modules, or multiple modules or steps can be fabricated as a single integrated circuit module. Thus, this disclosure is not limited to any particular combination of hardware and software.

[0109] The above are merely preferred embodiments of this disclosure and are not intended to limit this disclosure. Various modifications and variations can be made to this disclosure by those skilled in the art. Any modifications, equivalent substitutions, improvements, etc., made within the principles of this disclosure should be included within the scope of protection of this disclosure.

Claims

1. A subchain management method for a distributed ledger, applied to the first node, comprising: Receive the subchain management request submitted by the second node; Review the aforementioned subchain management application; If the subchain management application is approved, a subchain management block corresponding to the application will be generated; The subchain management block is broadcast to a third node for multi-party consensus.

2. The method of claim 1, wherein, The subchain management application is a subchain establishment application. The first node is the main chain management node, the second node is a non-main chain management node, the third node is the main chain consensus node and other main chain management nodes different from the first node, and the subchain management block is the subchain genesis block.

3. The method of claim 2, wherein, The review of the subchain management application includes at least one of the following: Verify whether the application type of the subchain establishment application matches the application content of the subchain establishment application; Verify whether the digital signature in the subchain establishment application is the digital signature of the node participating in the subchain establishment application; Verify whether the application content in the subchain establishment application complies with the distributed ledger rules.

4. The method of claim 2, wherein, If the subchain management application is approved, generating the subchain management block corresponding to the subchain management application includes: Generate a subchain identifier and digitally sign the subchain establishment application to form a subchain establishment transaction; Generate the genesis block of the subchain and write the transactions that establish the subchain into the genesis block.

5. The method of claim 4, wherein, Generating the subchain identifier includes: The subchain identifier is generated based on the receipt time of the subchain establishment application and the identifier of the first node.

6. The method of claim 2, wherein, After broadcasting the subchain management block to the third node for multi-party consensus, the process includes: If the genesis block of the subchain is recognized by the third node, the subchain is established and the main chain management node is determined as the subchain manager node.

7. The method of claim 2, wherein, The application content of the subchain establishment application includes at least one of the following: subchain parameters, digital signatures of the subchain establishment application by the nodes participating in the subchain establishment application, wherein the nodes participating in the subchain establishment application include the second node that made the application and other second nodes; The subchain parameters include at least one of the following: the consensus rules of the subchain management block, the identifier of the node participating in the application to establish the subchain, and the form of the subchain smart contract; The consensus rules for the sub-chain management blocks include at least one of the following: the node type of the third node, a first predetermined number of block intervals or a predetermined time interval between two sub-chain modified blocks that include the same parameter; The subchain parameters are determined autonomously by the second node that made the application or determined through negotiation between the second node that made the application and the other second nodes.

8. The method of claim 2, wherein, The subchain genesis block includes at least one of the following: the block identifier of the subchain genesis block, subchain parameters, the identifiers of the nodes participating in the subchain establishment application, the digital signature of the nodes participating in the subchain establishment application for the subchain establishment application, the identifier of the first node, and the digital signature of the first node for the subchain establishment application.

9. The method of claim 1, wherein, The subchain management application is a subchain parameter modification application. The first node is the subchain supervisor node, the second node is the subchain non-supervisor node, and the third node is the main chain consensus node and other main chain management nodes different from the first node. The subchain management block is the subchain modification block, wherein the subchain supervisor node and the subchain non-supervisor node are nodes on the same subchain.

10. The method of claim 9, wherein, The review of the subchain management application includes at least one of the following: Verify whether the application type of the subchain parameter modification application matches the application content of the subchain parameter modification application; Verify that the subchain parameter modification information in the application content of the subchain parameter modification application is correct; Verify whether the number of digital signatures in the subchain parameter modification application has reached the second predetermined number; Verify whether the digital signature belongs to the node that participated in the subchain parameter modification application.

11. The method of claim 9, wherein, If the subchain management application is approved, generating the subchain management block corresponding to the subchain management application includes: The request to modify the subchain parameters is digitally signed; Generate the subchain modification block, and write the subchain parameter modification request and the first node's digital signature of the subchain parameter modification request into the subchain modification block.

12. The method of claim 9, wherein, The subchain modification block includes at least one of the following: the block identifier of the subchain modification block, subchain parameter modification information, the digital signature of the node participating in the subchain parameter modification application for the subchain parameter modification application, and the digital signature of the first node for the subchain parameter modification application.

13. The method of claim 1, wherein, The subchain management application is a subchain sealing application. The first node is the subchain supervisor node, the second node is the subchain non-supervisor node, and the third node is the main chain consensus node and other main chain management nodes different from the first node. The subchain management block is the subchain sealing block, wherein the subchain supervisor node and the subchain non-supervisor node are nodes on the same subchain.

14. The method of claim 13, wherein, The review of the subchain management application includes at least one of the following: Verify whether the application type of the subchain sealing application matches the application content of the subchain sealing application; If the subchain sealing information in the application content of the subchain sealing application is not empty, verify whether the subchain sealing information is correct; Verify whether the number of digital signatures in the subchain sealing application has reached the third predetermined number; Verify whether the digital signature belongs to the node that participated in the subchain sealing application.

15. The method of claim 13, wherein, If the subchain management application is approved, generating the subchain management block corresponding to the subchain management application includes: Digitally sign the subchain sealing application; Generate the subchain sealing block, and write the subchain sealing application and the first node's digital signature on the subchain sealing application into the subchain sealing block.

16. The method of claim 13, wherein, The subchain sealed block includes at least one of the following: the block identifier of the subchain sealed block, the digital signature of the node participating in the subchain sealed application for the subchain sealed application, and the digital signature of the first node for the subchain sealed application.

17. The method of claim 1, wherein, The method further includes: If the subchain management application fails to pass the review, notify the second node of the reason why the subchain management application failed.

18. A sub-chain management system for a distributed ledger, comprising a first node, a second node, and a third node. The first node is configured to receive subchain management applications submitted by the second node, review the subchain management applications, generate a subchain management block corresponding to the application if the subchain management application is approved, and broadcast the subchain management block to the third node for multi-party consensus. The second node is configured to submit the sub-chain management request to the first node; The third node is configured to receive the sub-chain management block broadcast by the first node and perform multi-party consensus on the sub-chain management block.

19. A computer readable storage medium having stored therein a computer program, wherein, When the computer program is executed by a processor, it implements the steps of the method described in any one of claims 1 to 17.

20. An electronic device comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor, when executing the computer program, performs the steps of the method of any one of claims 1 to 17.

21. A computer program product comprising a computer program that, when executed by a processor, implements the steps of the method described in any one of claims 1 to 17.

Images