Method for generating blocks in distributed ledger, and storage medium, electronic apparatus and computer program product

Abstract

Provided in the embodiments of the present disclosure are a method for generating blocks in a distributed ledger, and a storage medium, an electronic apparatus and a computer program product. The method comprises: generating target blocks that each carry a block number, wherein the block number comprises a block type identifier of the target block; and broadcasting the target blocks, such that a plurality of nodes receiving the target blocks perform a consensus process on the target blocks. Target blocks of different block types are generated and broadcast, such that nodes receiving the target blocks can participate in a consensus process of the target blocks, that is, the consensus process of the target blocks can be open to all the nodes receiving the target blocks. Thus, the technical problem in the related art whereby a distributed ledger control mode cannot meet increasingly high credibility requirements of users can be solved.

Description

Distributed ledger block generation methods, storage media, electronic devices, and computer program products

[0001] Cross-reference to related applications

[0002] This disclosure is based on and claims priority to Chinese patent application CN202411632933.2, filed on November 14, 2024, entitled “Block Generation Method, Storage Medium, Electronic Device and Computer Program Product for Distributed Ledger”, and incorporates the entire contents of that patent application by reference. Technical Field

[0003] This disclosure relates to the field of communications, and more specifically, to a method for generating blocks in a distributed ledger, a storage medium, an electronic device, and a computer program product. Background Technology

[0004] The convergence of Operation, Data, Information, Communication, and Technology (ODICT) brings new capabilities, ecosystems, and models to 6G networks. 6G's native distributed ledger technology enables inherent trustworthiness. Data in a distributed ledger is distributed across different geographical locations or institutions, with each node holding a copy of the ledger. Summary of the Invention

[0005] This disclosure provides a method for generating blocks in a distributed ledger, a storage medium, an electronic device, and a computer program product.

[0006] According to one embodiment of this disclosure, a block generation method for a distributed ledger is provided. The method includes: generating a target block carrying a block number, wherein the block number includes a block type identifier of the target block; and broadcasting the target block to enable multiple nodes that receive the target block to perform a consensus process on the target block.

[0007] According to another embodiment of this disclosure, a distributed ledger system is also provided, comprising: a management node and a consensus node, wherein the management node or consensus node is configured to implement the steps of the method described in any of the preceding claims.

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

[0009] According to yet another embodiment of this disclosure, an electronic device is also provided, including a memory and a processor, the memory storing a computer program, the processor being 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. Attached Figure Description

[0011] Figure 1 is a hardware structure block diagram of a mobile terminal for a block generation method of a distributed ledger according to an embodiment of the present disclosure.

[0012] Figure 2 is a flowchart of a block generation method for a distributed ledger according to an embodiment of the present disclosure;

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

[0014] Figure 4 is a schematic diagram of the process for changing distributed ledger business parameters in one embodiment of this disclosure;

[0015] Figure 5 is a schematic diagram of the process of changing a participating node to a consensus node in one embodiment of this disclosure. Detailed Implementation

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

[0017] The 6G native distributed ledger does not mandate that all nodes possess the same performance and functional modules. Based on their roles within the consortium blockchain, nodes can be categorized into user nodes, consensus nodes, and management nodes. User nodes do not participate in block consensus or the block generation process; they simply use the distributed ledger. Consensus nodes possess strong computing capabilities, enabling them not only to use the distributed ledger but also to generate blocks and participate in block consensus. Management nodes assume management responsibilities for the distributed ledger and are typically distributed ledger functional nodes within the core network, possessing full permissions. Multiple nodes collaboratively maintain a unified ledger, ensuring data security, transparency, and immutability.

[0018] When new transaction data is added to the ledger, its legitimacy needs to be verified through a consensus mechanism within the network. Common consensus mechanisms include Proof of Work (PoW) and Proof of Stake (PoS). Consensus mechanisms ensure that all nodes agree on the ledger state, thus guaranteeing the ledger's consistency and security. Distributed ledger technology also employs cryptographic techniques to protect the security and privacy of transaction data. For example, public and private keys are used to sign and verify transactions. Once transaction data is written to the distributed ledger and verified by the consensus mechanism, this data cannot be tampered with or deleted. Furthermore, all transaction data in the distributed ledger is publicly verifiable (unless there are special privacy protection mechanisms), which increases the system's transparency and makes it easier for participants to verify the authenticity and legitimacy of transactions.

[0019] However, the current distributed ledger management method is centralized, and users cannot participate in the management process, which does not meet the future users' increasing demand for higher trust in the system.

[0020] 6G native distributed ledgers are generally in the form of consortium blockchains, jointly built and maintained by multiple organizations or institutions. Each organization or institution manages one or more nodes, and data can only be read, written, and sent by institutions within the system. The method in this embodiment can be applied to any node in a 6G native distributed ledger. This node can be a relevant functional node in the operator's core network, a base station, an end user, a relevant node in a private network, etc., and this disclosure does not impose any restrictions. Each node in the distributed ledger can possess different performance and functional modules to undertake different functions within the distributed ledger. In this embodiment, the node can execute the various steps in the block generation method to achieve the block generation function.

[0021] The method embodiments provided in this disclosure can be executed in a mobile terminal, computer terminal, or similar computing device. Taking a mobile terminal as an example, FIG1 is a hardware structure block diagram of a mobile terminal according to the block generation method of distributed ledger according to an embodiment of this disclosure. As shown in FIG1, the mobile terminal may include one or more (only one is shown in FIG1) processors 102 (processor 102 may include, but is not limited to, processing devices such as microprocessors MCUs or programmable logic devices FPGAs) and a memory 104 configured to store data. The mobile terminal may also include a transmission device 106 configured for communication functions and an input / output device 108. It will be understood by those skilled in the art that the structure shown in FIG1 is only illustrative and does not limit the structure of the mobile terminal. For example, the mobile terminal may also include more or fewer components than shown in FIG1, or have a different configuration than shown in FIG1.

[0022] The memory 104 may be configured to store computer programs, such as application software programs and modules, like the computer program corresponding to the distributed ledger block generation method in this embodiment. The processor 102 executes various functional applications and data processing by running the computer programs stored in the memory 104, thereby implementing the aforementioned method. The memory 104 may include high-speed random access memory and may also include non-volatile memory, such as one or more magnetic storage devices, flash memory, or other non-volatile solid-state memory. In some instances, the memory 104 may further include memory remotely located relative to the processor 102, and these remote memories can be connected to the mobile terminal via a network. Examples of such networks include, but are not limited to, the Internet, corporate intranets, local area networks, mobile communication networks, and combinations thereof.

[0023] The transmission device 106 is configured to receive or send data via a network. Specific examples of the network described above may include a wireless network provided by the mobile terminal's communication provider. In one example, the transmission device 106 includes a Network Interface Controller (NIC), which can connect to other network devices via a base station to communicate with the Internet. In another example, the transmission device 106 may be a Radio Frequency (RF) module configured to communicate with the Internet wirelessly.

[0024] This disclosure provides a block generation method for a distributed ledger in one embodiment. Figure 2 is a flowchart of the block generation method for a distributed ledger according to an embodiment of this disclosure. As shown in Figure 2, the process includes the following steps:

[0025] Step S202: Generate a target block carrying a block number;

[0026] Step S204: Broadcast the target block so that multiple nodes that receive the target block can perform a consensus process on the target block.

[0027] In this embodiment of the disclosure, the block number includes the block type identifier of the target block.

[0028] The method in this disclosure can be applied to any node of a 6G native distributed ledger. This node can be a relevant functional node of the operator's core network, a base station, a terminal user, a relevant node in a private network, etc. This disclosure does not limit this.

[0029] In this embodiment of the disclosure, through the above steps S202 and S204, target blocks with different block type identifiers can be generated and broadcast, enabling nodes that receive the target block to participate in the consensus process of the target block. That is, the consensus process of the target block can be open to all nodes that receive the target block. Therefore, it can solve the technical problem that the control method of distributed ledger in related technologies cannot meet the increasingly high trust requirements of users, and achieve the effect of improving the trust capability of the introduced distributed ledger.

[0030] In some embodiments, block numbers are used to identify different types of target blocks, and each target block has a unique block number.

[0031] In some embodiments, the distributed ledger takes the form of, but is not limited to, consortium blockchains, public blockchains, and private blockchains. In a consortium blockchain, multiple organizations or institutions jointly participate in its construction and maintenance, with each organization or institution managing one or more nodes, and data can only be read, written, and sent by institutions within the system.

[0032] In some embodiments, broadcasting can be implemented in various ways, such as through peer-to-peer networks, centralized broadcast servers, or broadcasting according to broadcast rules. Furthermore, during the broadcast process, encryption techniques and access control can be used to protect the target block from being accessed by unauthorized third parties. This disclosure does not impose any limitations in this regard.

[0033] In some embodiments, target blocks carrying different block numbers may record information corresponding to block type identifiers, wherein the types of target blocks include:

[0034] The first type of block is set up to record changes in the ledger parameters of the distributed ledger;

[0035] The second type of block is set up to record transaction information.

[0036] In some embodiments, the ledger parameter information of the distributed ledger includes at least one of the following: ledger node information, consensus rules, and smart contract rules. The consensus rules are used to coordinate the actions and decisions among the nodes to ensure that all nodes reach a consensus on the target block. This disclosure does not impose any limitations on this.

[0037] In some embodiments, node information includes at least one of the following: node type, node function, node participation capability, node security, and reliability. For example, a node's participation capability may be the ability to participate in the consensus process of first-type blocks and / or second-type blocks, or the inability to participate in the consensus process of first-type blocks and / or second-type blocks.

[0038] In some embodiments, transaction information refers to ordinary transaction information unrelated to ledger parameters, and includes at least one of the following: the identities of the transacting parties, the time of transaction creation, transaction rules, transaction description, and transaction identifier. This disclosure does not impose any limitations on this.

[0039] In some embodiments, the first type of blocks are generated by the management node, and the first type of blocks undergo a consensus process by the management node, or the first type of blocks undergo a consensus process by the management node and the consensus node.

[0040] The second type of block is generated by the management node or consensus node, and the consensus process between the management node and the consensus node is carried out on the second type of block.

[0041] In this embodiment of the disclosure, the management node establishes a first type of block and a consensus process is conducted by the management node or the consensus node, thereby enabling the management node or the consensus node to manage the distributed ledger.

[0042] In some embodiments, the management node is a node with distributed ledger management authority and assumes the management responsibility of the distributed ledger. For example, the distributed ledger function node in the core network serves as the management node. The consensus node has strong computing power and can not only use the distributed ledger, but also generate target blocks and participate in the consensus process of the target blocks.

[0043] In one exemplary embodiment, blocks in the distributed ledger can be divided into two categories: management blocks (i.e., the first type of block mentioned above), which only store parameter information and control information change information of the distributed ledger; and transaction blocks (i.e., the second type of block mentioned above), which can store various transaction information. Based on this, the two types of blocks use different generation methods. Transaction blocks can be generated by consensus nodes or management nodes, and both consensus nodes and management nodes can participate in the block consensus process. Management blocks can only be generated by management nodes, and the consensus process can be undertaken by the management node or jointly by the management node and consensus nodes.

[0044] In some embodiments, all nodes can request the management node to generate management blocks, or the management node can generate them itself. This disclosure does not impose any restrictions on this.

[0045] In some embodiments, the block number further includes: the time when the target block was generated and the node number that generated the target block.

[0046] In some embodiments, the time to generate the target block is the time required to generate a new target block, which may be a pre-set fixed value.

[0047] In some embodiments, the node number that generates the target block is the number corresponding to the node that generates the block, used to distinguish different nodes. The node numbering method for generating the target block can be to directly number any node in the distributed account sequentially. For example, nodes can be numbered sequentially using numbers. Alternatively, nodes with the same function can use the same type of number to distinguish nodes with different functions, and further distinguish different nodes with the same function using the same type of number. For example, management nodes use letter numbers, and different letters are used to distinguish different management nodes; consensus nodes use number numbers, and different numbers are used to distinguish different consensus nodes. This disclosure does not impose any limitations on this.

[0048] In some embodiments, the block type identifier includes a first identifier and a second identifier, wherein the first identifier includes a main chain identifier or a sub-chain identifier, and the second identifier includes a first type block identifier or a second type block identifier. However, this disclosure is not limited thereto.

[0049] In some embodiments, if the target block is of type 1, then step S202, generating the target block carrying the block number, may include the following steps:

[0050] Step S202A-2: The management node generates change information for ledger parameters based on the parameter change requirements of the distributed ledger.

[0051] In step S202A-4, the management node digitally signs the change information of the ledger parameter information and the block number, and generates a first type of block carrying the block number, the change information of the ledger parameter information, and the digital signature.

[0052] In some embodiments, the parameter change requirements of a distributed ledger include at least one of the following: changes to transaction rules, changes to consensus rules, and changes to node information. However, this disclosure is not limited to these, and parameter change requirements may also be other management requirements.

[0053] In one exemplary embodiment, change information for ledger parameters can be generated according to transaction rules based on the parameter change requirements of the distributed ledger.

[0054] In some embodiments, before the management node generates change information for ledger parameters based on the parameter change requirements of the distributed ledger in step S202A-2, the method may further include the following steps:

[0055] Step S2012, the management node receives the change request of the distributed ledger, wherein the change request includes application information and the digital signature of the sending node of the change request, and the sending node of the change request includes the consensus node or participating node of the distributed ledger;

[0056] Step S2014: The management node verifies the application information and the digital signature of the sending node;

[0057] In step S2016, in response to the successful verification, the management node determines the parameter change requirement based on the application information.

[0058] In this embodiment, the participating nodes are also core members of the distributed ledger system, responsible for verifying transactions, maintaining ledger updates, and reaching consensus.

[0059] In some embodiments, digital signatures can be used not only to verify application information but also to verify the identity of the sending node, thereby ensuring the authenticity of the account application information and the reliability of the sending node's identity.

[0060] In some embodiments, a change request for the distributed ledger includes at least one of the following: changes to certain business parameters of the distributed ledger, or changes to node permissions. For example, each node in the distributed ledger can upgrade or downgrade its permissions as needed. If a terminal wants to change from a participating node to a consensus node but does not have management permissions, it needs to initiate a change request for the distributed ledger to a management node with permissions, thereby achieving a change of identity.

[0061] In some embodiments, after step S2014, the method may further include step S2018, in which, in response to the verification failing, the management node sends a change request verification failure notification to the node that sent the change request.

[0062] It should be noted that steps S2016 and S2018 are selected based on the verification result of step S2014. That is, after executing step S2014, only step S2016 or step S2018 can be executed.

[0063] In some embodiments, the nodes in the distributed ledger can communicate directly or indirectly. Therefore, the management node can send a change request verification failure notification directly to the sending node that sent the change request, or it can send it through other nodes, which will then forward it to the sending node. This disclosure does not limit the method of transmission.

[0064] In some embodiments, if either the application information or the digital signature of the sending node fails verification, the change application verification fails.

[0065] In some embodiments, the content of the change application verification failure notification can directly indicate failure, or it can implicitly indicate failure by stating the reason for the verification failure. For example, if the digital signature is invalid, the content of the change application verification failure notification can be failure, or it can be that the digital signature failed (implicitly). If the application information does not conform to the rules and the digital signature is invalid, the content of the change application verification failure notification can be failure, or it can be that both the application information and the digital signature failed (implicitly). This disclosure does not limit the content of the change application verification failure notification.

[0066] In some embodiments, if the target block is a second type of block, then step S202, generating the target block carrying the block number, may include the following steps:

[0067] Step S202B-2: The management node or consensus node generates transaction information according to business needs;

[0068] In step S202B-4, the management node or the consensus node digitally signs the transaction information and the block number, and generates a second type of block carrying the block number, the transaction information, and the digital signature.

[0069] In one exemplary embodiment, the management node or consensus node generates transaction information according to transaction rules based on business needs.

[0070] In this embodiment, a block type identifier is added to distinguish between first-type blocks and second-type blocks, with each type configured to store different information. By generating and broadcasting target blocks of different block types, nodes receiving the target block can participate in its consensus process. Furthermore, since each management node and / or each consensus node can participate in the target block's consensus process, it can meet users' increasingly higher trust requirements, thereby solving the technical problem that the control methods of distributed ledgers in related technologies cannot meet users' increasingly higher trust requirements, and achieving the technical effect of improving the trustworthiness of distributed ledgers.

[0071] On the one hand, due to the principle of controllability of telecommunications networks, typically only a single control node (usually owned by the telecommunications network operator) has management authority over the distributed ledger. Since ordinary nodes cannot participate in the management of the distributed ledger (such as node generation), the trustworthiness of the distributed ledger is reduced, contradicting the original intention of introducing distributed ledgers into telecommunications networks. On the other hand, existing distributed ledgers only have one type of block, without needing to distinguish block types, and this type of block does not involve the management of distributed ledger parameters; any node can generate this block, but this does not conform to the principle of controllability of telecommunications networks. Therefore, in this embodiment, a new type of block is proposed, distinguished by a block type identifier. All operations related to distributed ledger control parameters (such as node permissions, consensus rules, etc.) are written into the new block, and only some authorized nodes generate it. This separates operations that do not involve ledger parameters from those that do, enabling telecommunications networks to control the distributed ledger.

[0072] In another embodiment of this disclosure, a distributed ledger system is also provided. FIG3 is a structural block diagram of a distributed ledger system according to an embodiment of this disclosure. As shown in FIG3, the distributed ledger system 30 includes:

[0073] Management node 302 and consensus node 304.

[0074] In this embodiment, management node 302 and consensus node 304 can execute the steps in any of the above method embodiments to generate blocks in the distributed ledger.

[0075] In this embodiment, the distributed ledger system may include multiple management nodes and multiple consensus nodes.

[0076] In this embodiment, management node 302 is a node with distributed ledger management authority. Consensus node 304 is a node other than the management node that participates in the distributed ledger consensus process. The roles of management node and consensus node can be switched.

[0077] In some embodiments, management node 302 may generate either a first type of block or a second type of block.

[0078] In some embodiments, consensus node 304 can only generate second-type blocks. Consensus nodes can modify the distributed ledger's parameter information by submitting a request to management node 302.

[0079] In some embodiments, management nodes may participate in the consensus process for Type 1 blocks and / or Type 2 blocks. Consensus nodes may also participate in the consensus process for Type 2 blocks and / or Type 1 blocks. The specific consensus method and consensus rules may be set as part of the change information for ledger parameters.

[0080] In this embodiment of the disclosure, by generating and broadcasting target blocks of different block types, the nodes receiving the target blocks can participate in the consensus process of the target blocks. That is, the consensus process of the target blocks can be open to all nodes receiving the target blocks. Therefore, it can solve the technical problem that the control method of distributed ledgers in related technologies cannot meet the increasingly high trust requirements of users, and achieve the effect of improving the trustworthiness of the introduced distributed ledger.

[0081] Through the various embodiments of this disclosure, a 6G native distributed ledger can be implemented, adopting a consortium blockchain approach, jointly constructed and maintained by multiple organizations or institutions. Each organization or institution manages one or more nodes, and data can only be read, written, and sent by institutions within the system. These nodes can be relevant functional nodes of the operator's core network, base stations, end users, or relevant nodes in a private network, etc.

[0082] In this embodiment, the 6G native distributed ledger does not mandate that all nodes possess the same performance and functional modules. Based on their functions within the consortium blockchain, nodes can be categorized into user nodes (or participating nodes), consensus nodes, and management nodes. User nodes do not participate in block consensus or block generation; they only use the distributed ledger. Consensus nodes possess strong computing capabilities and can not only use the distributed ledger but also generate blocks and participate in block consensus. Management nodes assume management responsibilities for the distributed ledger and are typically distributed ledger functional nodes in the core network, possessing full permissions.

[0083] In this embodiment, blocks in the distributed ledger can be divided into two categories: Category 1 blocks, which only store parameter and control information of the distributed ledger, and Category 2 blocks, which can store various transaction information. The two types of blocks use different generation methods. Category 2 blocks can be generated by consensus nodes or management nodes, and both consensus and management nodes can participate in the block consensus process. Category 1 blocks can only be generated by management nodes, and the consensus process can be undertaken by the management node alone, or jointly by the management node and consensus nodes. All nodes can apply to the management node to generate Category 1 blocks, and the management node can also generate them itself. In this way, nodes can participate in the management process of the distributed ledger, and the control and management content is open to all nodes, realizing the trust capability expected from introducing the distributed ledger.

[0084] Figure 4 is a schematic diagram of the process for changing distributed ledger business parameters in one embodiment of this disclosure. As shown in Figure 4, the process includes the following steps:

[0085] In step S402, the ledger function unit submits application information and generates change information for ledger parameter information according to the transaction rules, and digitally signs the change information for ledger parameter information and the block number.

[0086] Step S404: Generate a management block containing change information, ledger parameter information, and a digital signature;

[0087] In step S406, the ledger function unit broadcasts the management block according to the broadcast rules, and the broadcast target is other management nodes;

[0088] Step S408: Other management nodes verify the application information after receiving the management block;

[0089] Step S410: Determine whether to broadcast the management block based on the verification result.

[0090] In this embodiment, the ledger function unit can be the ledger function unit of the core network.

[0091] In some embodiments, after performing step S410, any of the following steps may also be performed:

[0092] Step S412A: If the verification passes, other management nodes save the management block and broadcast the management block according to the broadcast rules.

[0093] In step S412B, if the verification fails, meaning the application information does not conform to the rules or the digital signature is forged, the management block is discarded. It should be noted that steps S412A and S412B are selectively performed based on the verification result of step S410; that is, after executing step S410, only step S412A or step S412B can be executed.

[0094] In this embodiment, the first type of block is the management block, which is set to store the parameter information and control information of the distributed ledger.

[0095] In this embodiment, the ledger function unit is a management node with management authority over the distributed ledger.

[0096] In some embodiments, changing certain distributed ledger business parameters includes at least one of the following: adding a new node or deleting a node.

[0097] In some embodiments, broadcast rules include, but are not limited to, the Gossip protocol and reliable broadcasting.

[0098] In some embodiments, verifying application information includes at least one of the following: verifying whether the application information is compliant, and verifying whether the digital signature is valid.

[0099] Figure 5 is a schematic diagram of the process of changing a participating node to a consensus node in one embodiment of this disclosure. As shown in Figure 5, the process includes the following steps:

[0100] Step S502: Participating nodes send change requests to the management node;

[0101] Step S504: The management node verifies the change request according to the rules;

[0102] Step S506: The management node determines whether the verification is successful.

[0103] Step S508A: If the verification passes, a management block is generated;

[0104] Step S510A: The management node broadcasts the management block to other management nodes and consensus nodes;

[0105] In step S512A, the management node and the consensus node conduct a consensus process. If the consensus requirements are met, the management block is recognized.

[0106] In some embodiments, after executing step S506, if the management node determines that the verification has failed, the following steps are executed:

[0107] In step S508B, if the verification fails, the management node sends a notification of failure to the participating nodes regarding the verification of the change request.

[0108] It should be noted that if step S508B is executed, steps S508A to S512A will not be executed.

[0109] In this embodiment, the first type of block is the management block, which stores the parameter information and control information of the distributed ledger.

[0110] In this embodiment, the change application includes application information and the terminal's digital signature.

[0111] In this embodiment, participating nodes can be terminals in the operator's network, and management nodes are nodes that grant distributed ledger permissions to participating nodes, which can be core network nodes.

[0112] In some embodiments, verifying a change request includes verifying whether the request information is compliant and whether the digital signature is valid.

[0113] In some embodiments, the content of the change application verification failure notification can directly indicate failure, or it can implicitly indicate failure by stating the reason for the verification failure.

[0114] 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 solution 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 described in the various embodiments of this disclosure.

[0115] Embodiments of this disclosure also provide a computer-readable storage medium storing a computer program, wherein the computer program, when executed by a processor, implements the steps in any of the above method embodiments.

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

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

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

[0119] Embodiments of this disclosure also provide a computer program product, including a computer program that, when executed by a processor, implements the steps in any of the method embodiments described above.

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

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

[0122] The above description is merely an exemplary embodiment of this disclosure and is 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 block generation method for a distributed ledger, the method comprising: Generate a target block carrying a block number, wherein the block number includes a block type identifier of the target block; The target block is broadcast so that multiple nodes that receive the target block can perform a consensus process on the target block.

2. The method of claim 1, wherein, The types of the target blocks include: The first type of block is set up to record changes in the ledger parameters of the distributed ledger; The second type of block is set up to record transaction information.

3. The method according to claim 2, wherein, The first type of block is generated by the management node, and the consensus process for the first type of block is carried out by the management node or the consensus process for the first type of block is carried out by the management node and the consensus node; The second type of block is generated by the management node or consensus node, and the consensus process between the management node and the consensus node is carried out on the second type of block.

4. The method of claim 1, wherein, The block number also includes: the time when the target block was generated and the node number that generated the target block.

5. The method of claim 1, wherein, The block type identifier includes: a first identifier and a second identifier, wherein the first identifier includes a main chain identifier or a sub-chain identifier, and the second identifier includes a first type block identifier or a second type block identifier.

6. The method of claim 2, wherein, The target block is a first-type block, and the generation of the target block carrying a block number includes: The management node generates change information for ledger parameters based on the parameter change requirements of the distributed ledger; The management node digitally signs the change information of the ledger parameter information and the block number, and generates a first type of block carrying the block number, the change information of the ledger parameter information, and the digital signature.

7. The method of claim 6, wherein, The parameter change requirements of the distributed ledger include at least one of the following: transaction rule change, consensus rule change, and node information change.

8. The method of claim 6, wherein, Before the management node generates change information for ledger parameters based on the parameter change requirements of the distributed ledger, the method further includes: The management node receives a change request from the distributed ledger, wherein the change request includes request information and the digital signature of the node that sent the change request, and the node that sent the change request includes the consensus node or participating node of the distributed ledger; The management node verifies the application information and the digital signature of the sending node; Upon successful verification, the management node determines the parameter change requirement based on the application information.

9. The method of claim 8, wherein, The method further includes: In response to the failure of the verification, the management node sends a change request verification failure notification to the node that sent the change request.

10. The method of claim 2, wherein, The target block is a second-type block, and the generation of the target block carrying a block number includes: Management nodes or consensus nodes generate transaction information based on business needs; The management node or the consensus node digitally signs the transaction information and the block number, and generates a second type of block carrying the block number, the transaction information, and the digital signature.

11. A distributed ledger system, the system comprising a management node and a consensus node, wherein, The management node or the consensus node is used to implement the steps of the method described in any one of claims 1 to 10.

12. A computer-readable storage medium having stored therein a computer program, wherein, The computer program, which is executed by a processor, realizes the steps of the method as claimed in any one of claims 1 to 10.

13. An electronic device comprising a memory, a processor, and a computer program stored on the memory and executable on the processor, the processor realizing the steps of the method as claimed in any one of claims 1 to 10 when executing the computer program.

14. A computer program product comprising a computer program, which, when executed by a processor, realizes the steps of the method as claimed in any one of claims 1 to 10.

Images