Block ring chain processing method, related device and medium

Abstract

The invention provides a block loop chain processing method, a related device and a medium. The method comprises the following steps: receiving block heads of respective generated blocks of a plurality of consensus nodes in a current consensus period; receiving first signature information of the plurality of consensus nodes on the block head of the previous consensus node; based on the respective first signature information of the plurality of consensus nodes, determining the sequence of respective generated blocks of the plurality of consensus nodes in the current consensus period; receiving respective generation blocks of the plurality of consensus nodes in the current consensus period; based on the sorting, integrating the respective generated blocks of the plurality of consensus nodes into a block ring of the current consensus period; and recording the block ring of the current consensus period to the block ring chain. According to the embodiment of the invention, under the condition that block chain record conflicts are reduced and all consensus node records are inconsistent, the efficiency of packaging and block outputting of the consensus nodes is improved. The embodiment of the invention is applied to traffic data recording, electronic invoice recording and other scenes.

Description

Technical Field

[0001] This disclosure relates to the field of blockchain technology, and in particular to a method, apparatus and medium for processing blockchain ring chains. Background Technology

[0002] In a blockchain consensus network, consensus nodes are responsible for packaging events into blocks, executing events, and reaching consensus on the produced blocks. Generally, only one master consensus node can be responsible for packaging blocks within a consensus cycle. If the number of events requiring block production is large within a certain period, it will cause increased load and reduced performance for the master consensus node, and this method is inefficient. However, if multiple consensus nodes are allowed to package blocks simultaneously, the generation time of multiple blocks will be within the same consensus cycle, leading to blockchain record conflicts and potentially causing inconsistencies in the order of blockchain records maintained by different consensus nodes. Summary of the Invention

[0003] This disclosure provides a blockchain ring chain processing method, related apparatus, and medium, which can improve the efficiency of consensus nodes in packaging blocks while reducing blockchain record conflicts and inconsistencies in records among various consensus nodes.

[0004] According to one aspect of this disclosure, a method for processing a block ring chain is provided, wherein the block ring chain is composed of linked block rings, the block rings containing blocks generated by multiple consensus nodes in the same consensus cycle, the multiple consensus nodes having a predetermined order, and the method being executed by a master consensus node among the multiple consensus nodes, the method comprising:

[0005] Receive the block headers of the blocks generated by the multiple consensus nodes in the current consensus cycle;

[0006] The system receives first signature information of the block header of the preceding neighbor consensus node from each of the plurality of consensus nodes, wherein, in the predetermined order, the preceding neighbor consensus node is ranked before the signing consensus node, the signing consensus node is the consensus node that generated the first signature information, and the signing consensus node receives the block header of the preceding neighbor consensus node.

[0007] Based on the first signature information of each of the plurality of consensus nodes, the order of the generated blocks of each of the plurality of consensus nodes in the current consensus period is determined;

[0008] Receive the generated blocks from the plurality of consensus nodes during the current consensus period;

[0009] Based on the sorting, the generated blocks of the multiple consensus nodes are integrated into a block ring for the current consensus period;

[0010] Record the block ring of the current consensus cycle onto the block ring chain.

[0011] According to one aspect of this disclosure, a block ring chain processing apparatus is provided, the block ring chain being formed by linking block rings, the block rings containing blocks generated by multiple consensus nodes in the same consensus cycle, the multiple consensus nodes having a predetermined order, the apparatus being applied to the master consensus node among the multiple consensus nodes, the apparatus comprising:

[0012] The first receiving unit is used to receive the block headers of the blocks generated by the multiple consensus nodes in the current consensus period.

[0013] The second receiving unit is configured to receive first signature information of the block header of the preceding neighbor consensus node from each of the plurality of consensus nodes, wherein, in the predetermined order, the preceding neighbor consensus node is ranked before the signing consensus node, the signing consensus node is the consensus node that generates the first signature information, and the signing consensus node receives the block header of the preceding neighbor consensus node.

[0014] The first determining unit is configured to determine the order of the generated blocks of the plurality of consensus nodes in the current consensus period based on the first signature information of each of the plurality of consensus nodes.

[0015] The third receiving unit is used to receive the generated blocks of the plurality of consensus nodes in the current consensus period;

[0016] An integration unit is used to integrate the generated blocks of the multiple consensus nodes into a block ring for the current consensus period based on the sorting.

[0017] A recording unit is used to record the block ring of the current consensus cycle onto the block ring chain.

[0018] Optionally, the block header includes the previous neighbor block ring digest value, and the block ring chain processing device further includes:

[0019] The acquisition unit is used to acquire the previous block ring on the block ring chain, and the previous block ring is recorded on the block ring chain in the previous consensus cycle of the current consensus cycle;

[0020] A calculation unit is used to calculate the digest value of the previous block ring, which is used as the digest value of the previous neighboring block ring.

[0021] Optionally, the block chain processing device further includes:

[0022] The second determining unit is used to determine other consensus nodes from which the block header received by the signing consensus node during the current consensus period comes, as candidate consensus nodes.

[0023] The third determining unit is used to determine the last candidate consensus node that is arranged in the predetermined order before the signature consensus node as the previous neighbor consensus node;

[0024] The signing unit is used to sign the block header of the preceding neighbor consensus node using the first private key of the signing consensus node to obtain the first signature information.

[0025] Optionally, the first signature information includes the signed block header, the signature consensus node identifier, and the signature on the block header;

[0026] The first determining unit is specifically used for:

[0027] From the first signature information, obtain the signed block header and the signature consensus node identifier;

[0028] The generated block to which the block header to be signed belongs is arranged before the generated block of the signing consensus node corresponding to the signing consensus node identifier, thereby generating the order of the generated blocks of the multiple consensus nodes based on the first signature information of each of the multiple consensus nodes.

[0029] Optionally, the integration unit is specifically used for:

[0030] For each consensus node, the generated block of the consensus node and the first signature information of the consensus node are combined to form the block information of the consensus node;

[0031] The block ring is obtained by connecting the block information of the multiple consensus nodes according to the sorting.

[0032] Optionally, the integration unit is further configured to:

[0033] Based on the block information of the multiple consensus nodes connected in the sorted manner, the block ring ontology is obtained;

[0034] The block ring ontology is signed using the second private key of the primary consensus node to obtain the ontology signature;

[0035] The block ring body and the body signature are connected to obtain the block ring.

[0036] Optionally, the recording unit is specifically used for:

[0037] The block ring of the current consensus period is sent to other consensus nodes among the plurality of consensus nodes, so that the plurality of consensus nodes reach a consensus on the block ring and execute the events in the block ring, and record the block ring on the block ring chain maintained by each of the plurality of consensus nodes.

[0038] Optionally, the recording unit is further configured to:

[0039] Obtain the block information of each of the plurality of consensus nodes from the block ring;

[0040] From the block information, obtain the generated block of the consensus node and the first signature information of the consensus node;

[0041] The generated block is verified using the first signature information;

[0042] Execute multiple events in the generated block.

[0043] Optionally, the recording unit is further configured to:

[0044] Obtain the block ring body and the body signature from the block ring;

[0045] Obtain the first public key of the master consensus node;

[0046] The signature of the ontology is verified based on the block ring ontology and the first public key;

[0047] After successful verification, the block information of each of the multiple consensus nodes is obtained from the block ring ontology.

[0048] Optionally, the first signature information includes the signed block header, the signature consensus node identifier, and the signature on the block header;

[0049] The recording unit is further specifically used for:

[0050] From the first signature information, obtain the signed block header, the signature consensus node identifier, and the signature on the block header;

[0051] Obtain the second public key of the signature consensus node corresponding to the signature consensus node identifier;

[0052] The signature is decrypted using the second public key to obtain the decrypted result;

[0053] Perform a digest operation on the signed block header to obtain the block header digest;

[0054] The generated block is verified by comparing the decrypted result with the block header digest.

[0055] Optionally, the recording unit is further configured to:

[0056] Execute the events in the generated blocks of each of the other consensus nodes besides the main consensus node;

[0057] Execute the events in the generated block of the master consensus node.

[0058] Optionally, the recording unit is further configured to:

[0059] Select a block to be executed from the generated blocks of each of the other consensus nodes besides the main consensus node;

[0060] Execute the events in the block to be executed.

[0061] Optionally, the recording unit is further configured to:

[0062] Starting from the next consensus node after the primary consensus node in the predetermined order, the generated blocks of each of the other consensus nodes are sequentially used as the blocks to be executed, according to the predetermined order.

[0063] Optionally, each of the plurality of consensus nodes has an executed event table;

[0064] The recording unit is further specifically used for:

[0065] At the start of the current consensus period, the executed event table is cleared;

[0066] Events are obtained sequentially from the blocks to be executed;

[0067] If it is determined that the obtained event is not in the executed event table, the event is executed and added to the executed event table.

[0068] Optionally, the block chain processing device further includes:

[0069] A discard unit is configured to discard the event if it is determined that the acquired event is in the executed event table.

[0070] Optionally, the executed event table stores the first summary values ​​of the executed events;

[0071] The discarding unit is specifically used for:

[0072] Perform a digest operation on the acquired events to obtain a second digest value;

[0073] If the second summary value matches a first summary value in the executed event table, the obtained event is determined to be in the executed event table;

[0074] Discard the event.

[0075] Optionally, the executed event table also stores the first event initiator information corresponding to the first summary value;

[0076] The discarding unit is further used for:

[0077] If the second summary value matches a first summary value in the executed event table, and the second event initiator information of the obtained event matches the first event initiator information corresponding to the first summary value, then it is determined that the obtained event is in the executed event table.

[0078] Optionally, the recording unit is further configured to:

[0079] Based on each event in the event group, an event group summary prediction model is used to predict the event group summary.

[0080] Based on the event group summary, the execution order of each event group is determined;

[0081] Based on the execution order of the event groups, the events in each event group are executed.

[0082] According to one aspect of this disclosure, an electronic device is provided, including a memory and a processor, the memory storing a computer program, the processor executing the computer program to implement the block chain processing method as described above.

[0083] According to one aspect of this disclosure, a computer-readable storage medium is provided, the storage medium storing a computer program that, when executed by a processor, implements the block ring chain processing method as described above.

[0084] According to one aspect of this disclosure, a computer program product is provided, the computer program product comprising a computer program that is read and executed by a processor of a computer device, causing the computer device to perform the block chain processing method as described above.

[0085] This disclosure uses a block ring chain instead of a blockchain. The block ring chain is composed of linked block rings. A block ring contains blocks generated by multiple consensus nodes within the same consensus cycle. Thus, within the same consensus cycle, instead of only one master consensus node producing blocks, multiple consensus nodes can produce blocks. In one consensus cycle, the blocks produced by multiple consensus nodes form a block ring and are recorded on the block ring chain, significantly improving block production efficiency compared to a scheme where only one block can be recorded per consensus cycle. To prevent conflicts in the block recording order on their respective blockchains due to simultaneous block production by different consensus nodes within the same consensus cycle, each consensus node first sends the block header of its generated block to each other during the consensus cycle, and then sends each other its first signature information on the block header of its preceding neighbor consensus node. Multiple consensus nodes have a predetermined order. The preceding neighbor consensus node is the last consensus node to receive the block header from the signing consensus node in the predetermined order. The preceding neighbor consensus node is identified relative to each consensus node through the first signature information. The preceding neighbor consensus node is the consensus node that actually produces blocks in that consensus cycle. In this way, the master consensus node can sort the consensus nodes that actually produced blocks in the current consensus cycle based on the first signature information of each consensus node. After receiving the generated blocks from each consensus node, the master consensus node can uniquely arrange the generated blocks of each consensus node in the current consensus cycle according to this sorting, forming a block ring, and send it to the other consensus nodes for consensus on-chain. Since the sorting based on the first signature information is unique within the same consensus cycle, this sorting can be verified by each consensus node, reducing blockchain record conflicts and inconsistencies between the records of different consensus nodes, and improving the security of blockchain records.

[0086] Other features and advantages of this disclosure will be set forth in the following description and will be apparent in part from the description or may be learned by practicing the disclosure. The objectives and other advantages of this disclosure may be realized and obtained by means of the structures particularly pointed out in the description, claims and drawings. Attached Figure Description

[0087] The accompanying drawings are provided to further understand the technical solutions of this disclosure and constitute a part of the specification. They are used together with the embodiments of this disclosure to explain the technical solutions of this disclosure and do not constitute a limitation on the technical solutions of this disclosure.

[0088] Figure 1 This is a system architecture diagram of the block ring chain processing method according to the embodiments of this disclosure;

[0089] Figure 2A and Figure 2B This is a schematic diagram illustrating the application of the blockchain processing method according to the embodiments of this disclosure in an electronic invoice scenario;

[0090] Figure 3 This is a main flowchart of a block ring chain processing method according to an embodiment of the present disclosure;

[0091] Figure 4A and Figure 4B This is a schematic diagram of a block chain according to an embodiment of the present disclosure;

[0092] Figure 5 This is a schematic diagram of a block loop processing method according to an embodiment of the present disclosure;

[0093] Figure 6 yes Figure 3 Step 330 is a flowchart for determining the order of blocks generated by multiple consensus nodes in the current consensus cycle.

[0094] Figure 7A and Figure 7B This is a schematic diagram illustrating the determination of the order of generated blocks of multiple consensus nodes in the current consensus cycle according to an embodiment of the present disclosure;

[0095] Figure 8 yes Figure 3 Step 350 is a flowchart of integrating the blocks generated by multiple consensus nodes into a block ring for the current consensus cycle.

[0096] Figure 9 This is a schematic diagram of a block ring according to an embodiment of the present disclosure;

[0097] Figure 10 yes Figure 8 Step 820 is a flowchart of connecting the block information of multiple consensus nodes in a predetermined order to obtain a block ring;

[0098] Figure 11 yes Figure 3 Step 360 is a flowchart of recording the current consensus cycle's block ring onto the block ring chain;

[0099] Figure 12 yes Figure 11 A flowchart of step 1110 executing events in the block ring;

[0100] Figure 13 This is a schematic diagram of events in an execution block ring according to an embodiment of the present disclosure;

[0101] Figure 14 yes Figure 12 A flowchart of step 1210, obtaining the block information of each of the multiple consensus nodes;

[0102] Figure 15This is a schematic diagram illustrating the acquisition of block information for each of multiple consensus nodes according to an embodiment of this disclosure;

[0103] Figure 16 yes Figure 12 A flowchart of step 1230 verifying the generated block using the first signature information;

[0104] Figure 17 This is a schematic diagram illustrating the verification of a generated block using first signature information according to an embodiment of the present disclosure;

[0105] Figure 18 yes Figure 12 A flowchart of step 1240 executing multiple events in the block generation process;

[0106] Figure 19A and Figure 19B This is a schematic diagram illustrating the sequence of multiple events in the execution generation block according to an embodiment of the present disclosure;

[0107] Figure 20 yes Figure 18 Step 1810 is a flowchart of the events in the blocks generated by each of the other consensus nodes besides the main consensus node.

[0108] Figure 21 yes Figure 20 A flowchart for step 2010, selecting the block to be executed;

[0109] Figure 22 yes Figure 20 A flowchart of step 2020 for executing events in the block to be executed;

[0110] Figure 23A and Figure 23B This is a schematic diagram illustrating the execution of events in an execution block according to an embodiment of the present disclosure;

[0111] Figure 24 This is a flowchart illustrating how to process an event when it is determined that the acquired event is in an executed event table, according to an embodiment of this disclosure.

[0112] Figure 25 yes Figure 24 Step 2410 determines a flowchart in the executed event table for the acquired event;

[0113] Figure 26 yes Figure 25 Step 2520 determines a flowchart in the executed event table for the acquired event;

[0114] Figure 27 yes Figure 18Another flowchart for step 1810, which executes the events in the blocks generated by each of the other consensus nodes besides the main consensus node;

[0115] Figure 28 This is a schematic diagram illustrating the determination of execution order using an event execution prediction model according to an embodiment of the present disclosure;

[0116] Figure 29 This is a flowchart illustrating the determination of execution order using an event group summary prediction model according to embodiments of the present disclosure.

[0117] Figure 30 This is a schematic diagram illustrating the determination of execution order using an event group summary prediction model according to an embodiment of the present disclosure;

[0118] Figure 31 This is a flowchart illustrating the generation of the ring digest value of the previous neighbor block according to an embodiment of the present disclosure;

[0119] Figure 32 This is a flowchart illustrating the generation of first signature information according to an embodiment of the present disclosure;

[0120] Figure 33 This is a block diagram of a block chain processing apparatus according to an embodiment of the present disclosure;

[0121] Figure 34 This is a terminal structure diagram of a block ring chain processing method performed according to an embodiment of the present disclosure;

[0122] Figure 35 This is a server structure diagram of a block ring chain processing method performed according to an embodiment of the present disclosure. Detailed Implementation

[0123] To make the objectives, technical solutions, and advantages of this disclosure clearer, the following detailed description is provided in conjunction with the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are merely illustrative and are not intended to limit the scope of this disclosure.

[0124] Before providing a further detailed description of the embodiments of this disclosure, the terms and concepts used in these embodiments are explained, and they are subject to the following interpretations:

[0125] Blockchain: Blockchain is a new application model of computer technologies such as distributed data storage, peer-to-peer transmission, consensus mechanisms, and encryption algorithms. Essentially, a blockchain is a decentralized database, a chain of data blocks linked together using cryptographic methods. Each block contains information about a set of events, used to verify the validity of the information (anti-counterfeiting) and to link it to the previous block.

[0126] A blockchain consensus network is a technological infrastructure that allows applications to access block events and smart contract services. It consists of multiple nodes, which can be computers or other devices, that collectively maintain a distributed database.

[0127] Consensus nodes: Consensus nodes are a key type of node in a blockchain consensus network. They reach consensus through specific consensus algorithms to maintain network security and data integrity. The main responsibilities of consensus nodes include verifying events and generating new blocks, ensuring that all nodes in the blockchain consensus network agree on the blockchain state.

[0128] Blocks: These include information such as events, block headers, and additional data, similar to logs in a database system. However, blocks are hash-anchored to prevent tampering. A key characteristic of this data is its continuous growth; it is neither deleted nor modified. A block records multiple events related to the exchange or transfer of digital resources or information. For example, a blockchain consensus network might record e-invoice data, with events involving the issuance of e-invoices, such as issuing an e-invoice for restaurant expenses worth 100 yuan to person A. Similarly, a blockchain consensus network might record traffic data, with events involving changes in traffic lights at intersections and speed limits on roads, such as the traffic light at intersection A changing from red to green, or the speed limit on road Z being 40 kilometers per hour.

[0129] In a blockchain consensus network, consensus nodes are responsible for packaging events into blocks, executing events, and reaching consensus on the produced blocks. Generally, only one master consensus node can be responsible for packaging blocks within a consensus cycle. If the number of events requiring block production is large within a certain period, it will cause increased load and reduced performance for the master consensus node, and this method is inefficient. However, if multiple consensus nodes are allowed to package blocks simultaneously, the generation time of multiple blocks will be within the same consensus cycle, leading to blockchain record conflicts and potentially causing inconsistencies in the order of blockchain records maintained by different consensus nodes.

[0130] Based on this, the present disclosure provides a block ring chain processing method, related apparatus and medium. The block ring chain processing method can improve the efficiency of consensus nodes in packaging blocks while reducing blockchain record conflicts and inconsistencies in records of various consensus nodes.

[0131] System architecture and scenario description of the embodiments disclosed herein

[0132] Figure 1 This is a system architecture diagram of the block chain processing method according to embodiments of this disclosure. Figure 1 As shown, the system used in the blockchain ring chain processing method includes: external node 110, interface node 120, and blockchain consensus network 130.

[0133] External node 110 is the node that initiates events, such as the transfer or exchange of digital resources. Objects can initiate event requests to the blockchain consensus network 130 through external node 110. External node 110 is typically a terminal and can take various forms, including desktop computers, laptops, PDAs (personal digital assistants), mobile phones, in-vehicle terminals, home theater terminals, and dedicated terminals. Furthermore, external node 110 can be a single device or a collection of multiple devices. For example, multiple devices connected via a local area network, sharing a single display device for collaborative work, collectively constitute a terminal, namely external node 1110. Terminal 110 can also communicate with the Internet 120 via wired or wireless means to exchange data.

[0134] Interface node 120 serves as the communication interface between external node 110 and the blockchain consensus network 130. External node 110 communicates with the consensus nodes in the blockchain consensus network 130 and exchanges data through interface node 120.

[0135] The blockchain consensus network 130 refers to a network that processes events to generate a block ring, and after reaching a consensus on the generated block ring, uploads it to the blockchain chain. In the blockchain consensus network 130 used in the block ring chain processing method of the embodiments of this disclosure, each consensus node of the blockchain consensus network 130 maintains the block ring chain. Consensus nodes need to store a large amount of data; therefore, consensus nodes are typically servers. The communication between the blockchain consensus network 130 and the external node 110 is specifically achieved through communication between a specific consensus node in the blockchain consensus network 130 and the external node 110.

[0136] The embodiments disclosed herein can be applied in various scenarios, such as Figure 2A and Figure 2B The electronic invoice scenarios shown are examples of such scenarios.

[0137] exist Figure 2A In the blockchain consensus network shown, only one consensus node can be responsible for packaging a block within a consensus cycle. Assuming that... Figure 2A In the e-invoice scenario shown, during consensus period 1, consensus node B acquires the block-producing right and becomes the master consensus node. Therefore, other consensus nodes cannot produce blocks during this consensus period 1. Consensus node B retrieves e-invoice events B1-BN from its maintained event pool, packages these events into block 1, and produces the block. Since one consensus period is 12 seconds, the time required to upload N e-invoice events to the blockchain is 12 seconds.

[0138] Figure 2BThe blockchain consensus network shown applies the block ring chain processing method provided in this disclosure embodiment. Instead of a blockchain, each consensus node maintains a block ring chain. Multiple consensus nodes may produce blocks within the same consensus cycle, and the blocks output by multiple consensus nodes within the same consensus cycle form a block ring. The block rings generated by multiple consensus cycles are cascaded to form a block ring chain. Assume that consensus nodes B and D both produce blocks within consensus cycle 1. Consensus node B retrieves electronic invoice events B1-BN from its maintained event pool and packages them into block 1. Consensus node C retrieves electronic invoice events C1-CN from its maintained event pool and packages them into block 2. Consensus node D retrieves electronic invoice events D1-DN from its maintained event pool and packages them into block 3. Blocks 1, 2, and 3 form a block ring, which is output in consensus cycle 1. Thus, in consensus cycle 1, even with 3N e-invoice events simultaneously recorded on the blockchain, the time required for recording remains 12 seconds. Figure 2A In comparison, more events are uploaded to the chain within the same consensus cycle, which improves the efficiency of consensus nodes in producing blocks.

[0139] It should be understood that the above description only illustrates some application scenarios of this disclosure. The business scenarios to which this disclosure can be applied may include, but are not limited to, the specific embodiments described above.

[0140] General Description of Embodiments in this Disclosure

[0141] It should be emphasized that the embodiments disclosed herein are applicable to a variety of application scenarios, such as Figure 2A and Figure 2B The example shown is an electronic invoice scenario. In blockchain consensus networks of related technologies, generally, only one master consensus node can be responsible for packaging and producing blocks within a consensus cycle. This leads to increased load and reduced performance on the master consensus node, and the block production efficiency is extremely low. However, allowing multiple consensus nodes to package and produce blocks simultaneously can easily cause blockchain record conflicts and inconsistencies in the order of blockchain records maintained by various consensus nodes. Some embodiments of this disclosure provide a block ring chain processing method, related apparatus, and medium that can improve the efficiency of consensus nodes in packaging and producing blocks while reducing blockchain record conflicts and inconsistencies in records among various consensus nodes.

[0142] The block ring chain processing method involves the master node among multiple consensus nodes processing the generated blocks from each consensus node during the current consensus cycle to obtain a block ring, which is then recorded on the block ring chain. This method can improve the efficiency of consensus nodes in packaging blocks while reducing blockchain record conflicts and inconsistencies among the records of various consensus nodes.

[0143] In the block ring chain processing method provided in this embodiment, the block ring chain is formed by linking block rings. The block ring contains generated blocks from multiple consensus nodes in the same consensus cycle. The multiple consensus nodes have a predetermined order, and the block ring chain processing method is executed by the master consensus node among the multiple consensus nodes.

[0144] like Figure 3 As shown, according to one embodiment of this disclosure, the block chain processing method includes:

[0145] Step 310: Receive the block headers of the blocks generated by multiple consensus nodes in the current consensus cycle;

[0146] Step 320: Receive the first signature information of the block header of the previous neighbor consensus node from each of the multiple consensus nodes. In the predetermined order, the previous neighbor consensus node is placed before the signing consensus node. The signing consensus node is the consensus node that generates the first signature information and receives the block header of the previous neighbor consensus node.

[0147] Step 330: Based on the first signature information of each of the multiple consensus nodes, determine the order of the blocks generated by each of the multiple consensus nodes in the current consensus cycle;

[0148] Step 340: Receive the blocks generated by multiple consensus nodes in the current consensus cycle;

[0149] Step 350: Based on the order, integrate the generated blocks of multiple consensus nodes into a block ring for the current consensus cycle;

[0150] Step 360: Record the current consensus cycle's block ring on the block ring chain.

[0151] Steps 310 to 360 are described in detail below.

[0152] A block chain is a chain-like structure formed by linking multiple block rings; the block ring is the basic unit of a block chain. A block ring is a ring-shaped structure formed by linking multiple blocks. Figure 4B The diagram shows a partial structure of the block ring chain. It is clear that block ring N-1, block ring N, and block ring N+1 are connected sequentially to form a chain structure, i.e., the block ring chain.

[0153] This embodiment of the disclosure uses a block ring chain instead of a blockchain. Therefore, each consensus node in the blockchain consensus network maintains a block ring chain. Thus, the blockchain consensus network using this embodiment can also be considered a block ring chain consensus network, for example... Figure 2B The blockchain consensus network shown can be considered a block ring chain consensus network. In a block ring chain consensus network, each consensus node maintains a block ring chain.

[0154] A block ring is a ring-shaped structure formed by linking multiple blocks, and the blocks generated within the block ring are generated by different consensus nodes within the same consensus cycle. The consensus cycle refers to the time period or rounds required for multiple consensus nodes to reach a consensus, and its definition may differ across different consensus algorithms and networks. Assuming... Figure 2B The consensus cycle of the blockchain consensus network shown is 12 seconds, meaning that within each consensus cycle, the consensus nodes in the blockchain consensus network need to reach a consensus within 12 seconds. In some blockchain networks, however, the consensus cycle may be determined based on parameters such as the length of the block ring chain.

[0155] Block generation refers to the process by which consensus nodes package events into blocks. (See also...) Figure 4B The generated block N_A is Figure 4A The consensus nodes in the process package events into blocks.

[0156] Reference Figure 4B The block ring N contains generated blocks N_A, N_B, and N_C. Block N_A is generated by consensus node A during consensus period N, block N_B is generated by consensus node B during consensus period N, and block N_C is generated by consensus node C during consensus period N. It can be seen that the consensus nodes corresponding to the generated blocks in the block ring are different, but all blocks are generated within the same period.

[0157] A block ring contains blocks generated by multiple consensus nodes within the same consensus cycle. Therefore, in the block ring chain, each block ring corresponds to a different consensus cycle, and the public announcement cycle for the blocks generated within each block ring is different. (Refer to...) Figure 4B Each block in block ring N-1 is generated within consensus period N-1, each block in block ring N is generated within consensus period N, and each block in block ring N+1 is generated within consensus period N+1.

[0158] Consensus nodes are nodes that participate in consensus within a blockchain consensus network. In a blockchain network, such as a consortium blockchain, there are other nodes besides the consensus nodes, but only the consensus nodes participate in recording events. Therefore, all blocks generated in the blockchain are generated by the consensus nodes.

[0159] The predetermined order refers to the sequence among multiple consensus nodes. This predetermined order can be set as needed, but to improve data transmission efficiency, nodes that are close to each other are typically placed adjacently in the predetermined order. Furthermore, based on the predetermined order, multiple consensus nodes can be arranged in a ring, or in other words, connected end-to-end.

[0160] Reference Figure 4A Assume that the blockchain consensus network includes consensus node A, consensus node B and consensus node C, and the predetermined order of the consensus nodes is consensus node A, consensus node B and consensus node C, and consensus node C points to consensus node A.

[0161] The master consensus node is the block-producing node in the block ring, and its configuration corresponds to the consensus cycle; the master consensus node may differ across different consensus cycles. The specific master consensus node is determined based on the consensus mechanism. Figure 4A Of the consensus nodes shown, based on the consensus mechanism, the primary consensus node is always consensus node B. Figure 4B The primary consensus node corresponding to block rings N-1, N, and N+1 shown is consensus node B. Furthermore, based on the consensus mechanism, the primary consensus node may rotate among multiple consensus nodes. For example, if multiple consensus nodes include consensus node A, consensus node B, and consensus node C, consensus node A will be the primary consensus node in the first consensus cycle, consensus node B in the second consensus cycle, and consensus node C in the third consensus cycle.

[0162] Furthermore, assuming the consortium blockchain uses the block ring chain processing method provided in this embodiment, there are other nodes besides the consensus node in the consortium blockchain network. In the consortium blockchain network, the block-producing node can be the primary consensus node or other nodes; that is, the block-producing node is not necessarily a consensus node. Therefore, the primary consensus node is not necessarily one of multiple consensus nodes; it can be any node other than the consensus node. The primary consensus node is specifically determined based on the consensus mechanism.

[0163] In step 310, the block headers of the blocks generated by multiple consensus nodes in the current consensus cycle are received.

[0164] The current consensus cycle refers to the cycle in which multiple consensus nodes are located at the current time. Assuming that the block ring closest to the current time in the block ring chain is block ring N, then the current consensus cycle refers to the consensus cycle in which block ring N+1 is expected to be generated.

[0165] A generated block refers to a block generated by a consensus node during the current consensus cycle, and there is a one-to-one correspondence between the generated block and the consensus; that is, each consensus node generates only one block during the current consensus cycle. A consensus node packages its local events to obtain a generated block.

[0166] Reference Figure 4A Each consensus node has an event pool, which stores events that have not yet been uploaded to the blockchain. The consensus node packages multiple events in the event pool to generate a block. This process can be represented as:

[0167] BlockN,X =X.GET_TXPOLL(),

[0168] Among them, Block N,X This represents the block generated by consensus node X, where X represents the consensus node and its value can be X = A, B, or C. N,X In this context, N represents the identifier of the block ring, indicating the generation of the block. N,X The expected block ring is the Nth block ring on the block ring chain.

[0169] GET_TXPOLL() is a function for each consensus node to retrieve events from its own event pool and package them into blocks. TXPOLL is the event pool of node X.

[0170] Furthermore, in the blockchain ring consensus network, some consensus nodes may have too few events to meet the requirements for block production. In this case, the node will not produce any blocks in the current consensus cycle, and the master consensus node will not receive the corresponding blocks. Therefore, the multiple blocks received by the master node in the current consensus cycle can originate from only a subset of the consensus nodes in the blockchain ring consensus network.

[0171] Assuming the blockchain consensus network includes consensus node 1, consensus node 2, consensus node 3 and consensus node 4, with consensus node 2 being the master consensus node, if the number of events in consensus node 3 during the current consensus period does not meet the requirements for packaging into a block, then consensus node 2 will only receive the block headers of the blocks generated by consensus nodes 1 and 4 during the current consensus period.

[0172] The block header is the beginning of the block generated by the consensus nodes in the current cycle. It contains a series of verification data that ensures the security and immutability of the block.

[0173] It should be noted that, for each consensus node, after obtaining the generated block, the block header of the generated block is broadcast to multiple consensus nodes. Referring to Figure 4, this broadcasting process can be represented as follows:

[0174]

[0175] Where X and Y both represent consensus nodes, and X,Y∈{A,B,C},Y≠X, Block N,X The header indicates the block header of the block generated by consensus node X, and Y indicates the arrival of the generated block at the consensus node, i.e., when consensus node X sends the block. N, X The header leads to consensus node Y. N is the identifier of the block ring, representing the block header generation process. N,XThe block corresponding to the Header is expected to be located in the Nth block ring on the block ring chain.

[0176] In step 320, the first signature information of the block header of the previous neighbor consensus node is received by each of the multiple consensus nodes. In a predetermined order, the previous neighbor consensus node is placed before the signing consensus node. The signing consensus node is the consensus node that generates the first signature information and receives the block header of the previous neighbor consensus node.

[0177] The first signature information corresponds to the generated block and is the encrypted information in the block header of the generated block. Assuming the block header is represented as {Block Identifier A, Block Digest Value HA, ...}, then the first signature information can be represented as {#%*h;}. Block Identifier A refers to the identifier information of the generated block corresponding to the block header. The block digest value is a key element used to uniquely identify the generated block. The block digest value is determined based on the data information in the block header. Any change to the internal data in the generated block will cause a change in the block digest value, which can then be detected by other consensus nodes. Therefore, the block digest value ensures the immutability of the data.

[0178] The signing consensus node is the node that generates the first signature information. The preceding neighbor consensus node is the node that precedes the signing consensus node in a predetermined order. Among the consensus nodes corresponding to multiple block headers received by the signing consensus node, the preceding neighbor consensus node is the consensus node that is closest to the signing consensus node in the predetermined order, preceding it. (See reference...) Figure 4A Multiple consensus nodes, including consensus node A, consensus node B, and consensus node C, are arranged in the predetermined order of consensus node A, consensus node B, and consensus node C. The next consensus node after consensus node C is consensus node A. If consensus node C receives block header A from consensus node A and block header B from consensus node B, then for consensus node C, its preceding consensus node is consensus node B. Therefore, consensus node C can process the block header B of its preceding consensus node, i.e., consensus node B, to generate the first signature information B of block header B. Consensus node C is the signing consensus node for the first signature information B.

[0179] In addition, Figure 4A Among the multiple consensus nodes shown, if consensus node C only receives block header A from consensus node A in the current consensus period, then the previous neighbor of consensus node C is consensus node A. Consensus node C processes block header A to generate the first signature information A of block header A. Consensus node C is the signing consensus node of the first signature information A.

[0180] It should be noted that, for each consensus node, the preceding consensus node is determined among the consensus nodes corresponding to the multiple block headers received, and the block header of the preceding consensus node is processed to obtain the first signature information of the block header.

[0181] In addition, the generation of the first signature information usually occurs at the end of the current consensus cycle. After the first signature information is generated, even if the consensus node receives a new block header, it will not process the block header in the current consensus cycle.

[0182] It should be noted that for each consensus node, after receiving the first signature information of the block header from its preceding neighbor, the first signature information is broadcast to multiple consensus nodes. (Refer to...) Figure 4A and Figure 4B The broadcasting process of the first signature information can be represented as:

[0183]

[0184] Among them, CircleSig N,X.Prev This represents the first signature information in the block header of the preceding neighboring consensus node generated by consensus node X. X and Y both represent consensus nodes, and X,Y∈{A,B,C},Y≠X. X is the consensus node that generates and sends the first signature information, while Y is the consensus node that receives the first signature information, i.e., the node that sends the new first signature information CircleSig from consensus node X. N,X.Prev To consensus node Y. N is the identifier of the block ring, which represents the first signature information CircleSig. N,X.Prev The corresponding block is expected to be located in the Nth block ring on the block ring chain.

[0185] In step 330, the order of the blocks generated by the multiple consensus nodes in the current consensus cycle is determined based on their respective first signature information.

[0186] The ordering refers to the ranking of the blocks generated by multiple consensus nodes within the current consensus period, and also the ranking of these blocks within the block ring. Since the consensus nodes that package blocks to generate blocks may differ in different consensus periods, and the consensus nodes for multiple blocks in the block ring differ across consensus periods, the ranking will also differ for each consensus period. For example, in consensus period N-1, if the multiple consensus nodes include consensus node 1, consensus node 2, and consensus node 4, then the ranking for consensus period N-1 is: block N-1_1 generated by consensus node 1, block N-1_2 generated by consensus node 4, and block N-1_4 generated by consensus node 5, with one block generated by block N-1_4 being block N-1_1. Similarly, in consensus period N, if the multiple consensus nodes include consensus node 2, consensus node 3, and consensus node 4, then the ranking for consensus period N is: block N_2 generated by consensus node 2, block N_3 generated by consensus node 3, and block N_4 generated by consensus node 4, with one block generated by block N_4 being block N_2. It is evident that the ordering corresponding to consensus period N-1 is different from that corresponding to consensus period N.

[0187] The order of blocks generated by multiple consensus nodes in the current consensus cycle is determined based on their corresponding first signature information. For each first signature information, based on the block header corresponding to the first signature information and the signing consensus node corresponding to the first signature information, the positional relationship between the generated block to which the block header corresponding to the signing consensus node belongs and the generated blocks corresponding to the previous neighboring consensus nodes of the signing consensus node can be determined. Thus, based on multiple first signature information, the order of blocks generated by multiple consensus nodes in the current consensus cycle can be determined.

[0188] Reference Figure 4A , Figure 4B and Figure 5 During consensus period N, consensus node B receives first signature information C and first signature information B from consensus node A, and consensus node B also contains first signature information A locally. The consensus node that signed first signature information A is consensus node B, and its preceding neighbor is consensus node A. Consensus node A is the consensus node that generated block N_A corresponding to first signature information A. Therefore, it can be determined that the next block in the order of generated block A from consensus node A is generated block N_B from consensus node B. Similarly, the next block in the order of generated block N_B is determined to be generated block N_C from consensus node C, and the next block in the order of generated block N_C is generated block N_A, thus obtaining the order among generated blocks N_A, N_B, and N_C.

[0189] In step 340, the generated blocks of multiple consensus nodes in the current consensus period are received.

[0190] After determining the order of the blocks generated by multiple consensus nodes in the current consensus period, the generated blocks are broadcast for each consensus node, so that the master node receives the generated blocks of multiple consensus nodes in the current consensus period.

[0191] The order in which blocks are generated can be determined separately by multiple consensus nodes. After determining the order, the consensus nodes broadcast the generated blocks. For example, Figure 4A Consensus nodes A, B, and C determine the order of blocks generated by multiple consensus nodes in the current period. After determining the order, consensus node A broadcasts the generated block N_A to consensus nodes B and C.

[0192] Reference Figure 4A and Figure 4B After each consensus node determines the order of its generated blocks in the current consensus cycle, and confirms that the ring structure is complete, the consensus nodes begin broadcasting the generated blocks for the current consensus cycle, which can be represented as:

[0193]

[0194] Among them, Block N,X Let Y be the consensus node that generated the block, where X is the consensus node that sent the generated block, and Y is the consensus node that received the generated block. In other words, consensus node X sends the generated block. N,X To consensus node Y. And X,Y∈{A,B,C},Y≠X. N,X In this context, N represents the identifier of the block ring, indicating the generation of the block. N,X The expected block ring is the Nth block ring on the block ring chain.

[0195] The order of generated blocks can also be determined solely by the primary consensus node. After determining the order, the primary consensus node broadcasts the order confirmation message, so that other consensus nodes, upon receiving the order confirmation message, will also broadcast their generated blocks. For example, refer to... Figure 4A After consensus node B determines the order of generating blocks N_A, N_B, and N_C, it broadcasts this order confirmation message. Upon receiving the message, consensus node A sends generated block N_A to consensus node B. Upon receiving the message, consensus node C sends generated block N_C to consensus node B.

[0196] In step 350, based on the order, the generated blocks of multiple consensus nodes are integrated into a block ring for the current consensus cycle.

[0197] The ordering refers to the ranking of the blocks generated by multiple consensus nodes in the current consensus cycle. Therefore, based on this ordering, the blocks generated by multiple consensus nodes can be arranged and integrated to obtain the block ring ontology for the current consensus cycle. Figure 4B Block ring N-1, block ring N, and block ring N+1 are all integrated block rings.

[0198] In step 360, the block ring of the current consensus cycle is recorded on the block ring chain.

[0199] After determining the block ring of the current consensus period, the block ring of the current period is recorded on the blockchain. This process permanently stores the events in each generated block on the blockchain, ensuring that they cannot be tampered with and guaranteeing the security of the events and the blockchain.

[0200] Reference Figure 4A , Figure 4B and Figure 5 In consensus cycle N, the consensus nodes participating in block ring generation are consensus node A, consensus node B, and consensus node C. First, each consensus node packages multiple events from the event pool into blocks, resulting in generated blocks N_A, N_B, and N_C. Then, the consensus nodes broadcast the block headers of the corresponding generated blocks. Consensus node A, based on the received block headers, determines consensus node C as its previous neighbor, signs the block header C of generated block N_C, generates first signature information C, and broadcasts it. Consensus node B, based on the received block headers, determines consensus node A as its previous neighbor, signs the block header A of generated block N_A, generates first signature information A, and broadcasts it. Consensus node C, based on the received block headers, determines consensus node B as its previous neighbor, signs the block header B of generated block N_B, generates first signature information B, and broadcasts it. Subsequently, each consensus node determines the order of generated blocks N_A, N_B, and N_C within consensus period N based on the first signature information A, B, and C. After determining the order, each consensus node broadcasts its locally generated blocks. Consensus node B, acting as the master consensus node, integrates generated blocks N_A, N_B, and N_C into a block ring N based on the order, and sends the integrated block ring N to consensus nodes A and C. Multiple consensus nodes then record the block ring N on the block ring chain.

[0201] In the embodiments of steps 310 to 360 above, a block ring chain replaces the blockchain. The block ring chain is composed of linked block rings. A block ring contains blocks generated by multiple consensus nodes within the same consensus cycle. Thus, within the same consensus cycle, instead of only one primary consensus node producing blocks, multiple consensus nodes can produce blocks. In one consensus cycle, the blocks produced by multiple consensus nodes form a block ring and are recorded on the block ring chain, significantly improving block production efficiency compared to a scheme where only one block can be recorded per consensus cycle. To prevent conflicts in the block recording order on their respective blockchains due to simultaneous block production by different consensus nodes within the same consensus cycle, each consensus node first sends the block header of its generated block to each other during the consensus cycle, and then sends each other its first signature information on the block header of its preceding neighbor consensus node. Multiple consensus nodes have a predetermined order. The preceding neighbor consensus node is the last consensus node to receive the block header from the signing consensus node in the predetermined order. The preceding neighbor consensus node is thus identified relative to each consensus node through the first signature information. The preceding consensus node is the consensus node that actually produces blocks within the current consensus cycle. In this way, the master consensus node can sort the consensus nodes that actually produced blocks within the current consensus cycle based on the first signature information of each node. After receiving the blocks generated by each consensus node, the master consensus node can uniquely arrange the blocks generated by each consensus node within the current consensus cycle according to this sorting, forming a block ring, and send it to the other consensus nodes for consensus on-chain. Because the sorting based on the first signature information is unique within the same consensus cycle, this sorting can be verified by each consensus node, reducing blockchain record conflicts and inconsistencies between consensus node records, thus improving the security of the blockchain record.

[0202] The above is a general description of steps 310 to 360. Since steps 310, 320 and 340 have been described in detail above, the specific implementation process of steps 330, 350 and 360 will be described in detail below.

[0203] Detailed description of step 330

[0204] In step 330, the order of the blocks generated by the multiple consensus nodes in the current consensus cycle is determined based on their respective first signature information.

[0205] In one embodiment, the first signature information includes the signed block header, the signature consensus node identifier, and the signature on the block header, as shown in the following example. Figure 6 Step 330 includes:

[0206] Step 610: Obtain the signed block header and the signature consensus node identifier from the first signature information;

[0207] Step 620: Arrange the generated blocks to which the signature block header belongs before the generated blocks of the signature consensus node corresponding to the signature consensus node identifier, thereby generating the order of the generated blocks of multiple consensus nodes based on their respective first signature information.

[0208] Steps 610 and 620 are described in detail below.

[0209] The signed block header refers to the block header corresponding to the first signature information, and it is also the block header of the block generated by the preceding neighboring consensus node of the first signature consensus node. (See reference...) Figure 5 For the first signature information C, the signed block header is block header C.

[0210] The signature consensus node identifier refers to the identification information of the consensus node that signed the first signature information. (See reference...) Figure 5 The consensus node identifier of the first signature information C is the identifier of the consensus node A. If the identifier of the consensus node A is A, then the consensus node identifier of the first signature information C is A.

[0211] The block header signature is data obtained after encrypting the block header. (See reference...) Figure 5 A. Assuming the block header N_A is represented as {block identifier A, block digest value HA, ...}, then the signature of the block header can be represented as {#%*h;}. Furthermore, if the consensus node corresponding to the signature of the block header N_A is consensus node B, then the first signature information A of the block header N_A is represented as {block identifier A, block digest value HA, ..., consensus node B, #%*h;}, that is, {block header A, consensus node B, #%*h;}.

[0212] In step 610, the signed block header and the signature consensus node identifier are obtained from the first signature information.

[0213] After receiving the first signature information from multiple consensus nodes, the master consensus node extracts the signed block header and the signature consensus node identifier from each first signature information.

[0214] Assuming the first signature information A is {block identifier A, block digest value HA, ..., consensus node B, #%*h;}, based on {block identifier A, block digest value HA, ...}, the block header A and consensus node B can be determined, where the block header A is the header of the block being signed, and the consensus node B is the identifier of the signing consensus node.

[0215] In step 620, the generated block to which the block header to be signed belongs is arranged before the generated block of the signing consensus node corresponding to the signing consensus node identifier, thereby generating the order of the generated blocks of multiple consensus nodes based on the first signature information of each of the multiple consensus nodes.

[0216] The generated block to which the header of the signed block belongs is the generated block of the preceding consensus node of the signing consensus node, and the preceding consensus node is listed before the signing consensus node. Therefore, the generated block to which the header of the signed block belongs is arranged before the generated block of the signing consensus node corresponding to the signing consensus node identifier. Based on this method, multiple first signature information are processed to obtain the order of the generated blocks of multiple consensus nodes.

[0217] Reference Figure 7A Based on the first signature information C, the signed block header is determined to be block header C, and the signing consensus node identifier is determined to be consensus node A. Furthermore, consensus node A corresponds to the generation of block A; therefore, generated block C is placed before generated block A. Similarly, based on the first signature information A, generated block A is placed before generated block B, and based on the first signature information B, generated block B is placed before generated block A. Based on the arrangement relationship between the generated blocks, the order of the generated blocks of each consensus node is obtained.

[0218] Reference Figure 7B The blockchain consensus network includes consensus nodes A, B, C, D, and E. However, when determining the first signature information, none of the consensus nodes received the block header from consensus nodes B and C. Therefore, the preceding neighbor of consensus node D is consensus node A. Based on the first signature information E, the signed block header is determined to be block header E, and the signing consensus node identifier is consensus node A. Furthermore, consensus node A corresponds to the generation of block A; therefore, generated block E is placed before generated block A. Similarly, based on the first signature information A, generated block A is placed before generated block D, and generated block D is placed between generated blocks E. Based on the arrangement relationships between the generated blocks, the respective orders of generated blocks A, D, and E are obtained.

[0219] In the embodiments of steps 610 and 620 above, the first signature information includes the signed block header and the signature consensus node identifier. The generated block to which the signed block header belongs is the generated block of the preceding neighboring consensus node of the signature consensus node. Therefore, based on the first signature information, the arrangement relationship between the generated block to which the signed block header belongs and the generated block of the signature consensus node corresponding to the signature consensus node identifier can be determined, thereby determining the order of the generated blocks of multiple consensus nodes and the position of each generated block in the block ring, so that each block is sequentially connected in the block ring to form a chain structure, thereby enabling multiple blocks to be packaged within one consensus cycle, improving block production efficiency.

[0220] Detailed description of step 350

[0221] In step 350, based on the order, the generated blocks of multiple consensus nodes are integrated into a block ring for the current consensus cycle.

[0222] In one embodiment, reference is made to Figure 8 Step 350 includes:

[0223] Step 810: For each consensus node, combine the generated block of the consensus node with the first signature information of the consensus node to form the block information of the consensus node.

[0224] Step 820: Based on the sorted connection of the block information of multiple consensus nodes, a block ring is obtained.

[0225] Steps 810 and 820 are described in detail below.

[0226] In step 810, for each consensus node, the generated block of the consensus node and the first signature information of the consensus node are combined to form the block information of the consensus node.

[0227] Block information refers to data including the generated block and the first signature information corresponding to the generated block, and there is a one-to-one correspondence between the block information, consensus nodes, and generated blocks. After receiving the generated blocks from each consensus node in the current consensus cycle, the generated block and the first signature information of the consensus node are combined to obtain the block information of the consensus node.

[0228] Reference Figure 4A and Figure 9 For generating block N_A, block N_A and the first signature information A are combined to generate block information N_A. For generating block N_B, block N_B and the first signature information B are combined to generate block information N_B. For generating block N_C, block N_C and the first signature information C are combined to generate block information N_C.

[0229] In step 820, a block ring is obtained by sorting and connecting the block information of multiple consensus nodes.

[0230] After determining the block information of each of the multiple consensus nodes, the block information is connected to form a block ring based on the sorting of the blocks generated in the block information.

[0231] Reference Figure 9 After determining block information N_A, block information N_B, and block information N_C, they are connected based on the order in which blocks are generated, resulting in a block ring. In the block ring, block information N_A points to block information N_B, block information N_B points to block information N_C, and block information N_C points to block information N_A.

[0232] Assuming the generated block is a Block N,X The first signature information of the block header that generates the block is CircleSig N,x The generated block and the first signature information are combined to obtain the block information. Then, multiple generated blocks are concatenated to form a block ring, which can be represented as:

[0233] BlockCircle N =<{Block N,X},{CircleSig N,X}>,

[0234] Among them, BlockCircle N This represents a block circle, where N is the identifier for the block circle, and N represents the block circle. N This represents the Nth block ring on the blockchain. The value of X is {A, B, C}, where X represents the consensus node. N,X CircleSig is the block generated by consensus node X. N,x This refers to the first signature information corresponding to the block generated by consensus node X. Figure 4A The value of X is {A,B,C}, therefore, Figure 4A The multiple consensus nodes shown correspond to the BlockCircle. N It can be represented as:

[0235] BlockCircle N =<{Block N,A},{CircleSig N,A},{Block N,B},{CircleSig N,B},{BlockN,C},{CircleSig N,C}>.

[0236] In the embodiments of steps 810 and 820 above, a block ring is obtained by sequentially connecting the block information of multiple consensus nodes. The block information includes the generated block and the first signature information. The first signature information can indicate the block header of the signing consensus node corresponding to the block header of the currently generated block, ensuring that multiple block information can be sequentially connected in the block ring. In addition, the first signature information includes the signed block header, the signing consensus node identifier, and the signature on the block header. Therefore, the connection correctness between two adjacent block information in the block ring can be verified through the first signature information, improving the correctness of the connection of each block information in the block ring, thereby improving the security of the block ring chain.

[0237] The above is a general description of steps 810 and 820. Since step 810 has been described in detail above, the specific implementation process of step 820 will be described in detail below.

[0238] In step 820, a block ring is obtained by sorting and connecting the block information of multiple consensus nodes.

[0239] In one embodiment, reference is made to Figure 10 Step 820 includes:

[0240] Step 1010: Based on the block information of multiple consensus nodes in the sorted connection, obtain the block ring ontology;

[0241] Step 1020: Sign the block ring ontology using the second private key of the primary consensus node to obtain the ontology signature;

[0242] Step 1030: Connect the block ring body and the body signature to obtain the block ring.

[0243] Steps 1010 to 1030 are described in detail below.

[0244] In step 1010, the block ring ontology is obtained by sorting and connecting the block information of multiple consensus nodes.

[0245] The block ring ontology is a data structure obtained by connecting the block information of multiple consensus nodes using sorting. The block ring ontology is the most important data structure in the block ring. (See reference...) Figure 9 The ring structure obtained by connecting block information N_A, block information N_B and block information N_C based on the sorting is the block ring body of block ring N.

[0246] In step 1020, the block ring ontology is signed using the second private key of the master consensus node to obtain the ontology signature.

[0247] The second private key is the private key on the primary consensus node. It is used to encrypt the block ring ontology corresponding to the primary consensus node in the current consensus cycle. The second private key is stored only on the primary consensus node.

[0248] Reference Figure 4A If the primary consensus node is consensus node B, then the private key of consensus node B can be used to sign the blockchain ontology, thus obtaining the ontology signature. Assume the blockchain ontology is BlockCircle. N Then the ontology signature can be represented as B.SIGN(BlockCircle) N ), where B.SIGN is the signature function corresponding to the private key of consensus node B.

[0249] In step 1030, the block ring body and the body signature are connected to obtain the block ring.

[0250] After determining the block ring ontology and its signature, the block ring ontology and signature are concatenated to obtain the block ring. (See reference...) Figure 9 The block ring body is a ring structure in which block information N_A, block information N_B and block information N_C are connected in sequence. The block ring body and the body signature are connected to obtain the block ring N.

[0251] In the embodiments of steps 1010 to 1030 above, in addition to the block ring body obtained based on the block information of multiple consensus nodes, the block ring also includes an ontology signature. The ontology signature is encrypted information obtained by signing the block ring body with the second private key of the consensus node, which can further improve the integrity and security of the block ring.

[0252] Detailed description of step 360

[0253] In step 360, the block ring of the current consensus cycle is recorded on the block ring chain.

[0254] In one embodiment, reference is made to Figure 11 Step 360 includes:

[0255] Step 1110: Send the current consensus cycle's block ring to other consensus nodes among multiple consensus nodes, so that multiple consensus nodes can reach a consensus on the block ring and execute the events in the block ring, and record the block ring on the block ring chain maintained by each of the multiple consensus nodes.

[0256] Step 1110 will be described in detail below.

[0257] In step 1110, the block ring of the current consensus period is sent to other consensus nodes among multiple consensus nodes so that multiple consensus nodes can reach a consensus on the block ring and execute the events in the block ring, and record the block ring on the block ring chain maintained by each of the multiple consensus nodes.

[0258] Each block in the block ring records multiple events, which involve the exchange or transfer of digital resources or information. Figure 2B The blockchain's consensus network, maintained by various consensus nodes, records multiple e-invoice events, which involve the issuance of e-invoices. Assume the blockchain consensus network records traffic data, with events involving changes in traffic lights at intersections and speed limits on roads. For example, an event might be the traffic light at intersection A changing from red to green, or the speed limit on road Z being 40 kilometers per hour.

[0259] After determining the block ring, the master consensus node sends the block obtained in the current consensus cycle to the other consensus nodes. Multiple consensus nodes, including the master consensus node, reach a consensus on the block ring and execute the events in the block, and then record the block ring on the block ring chain they maintain.

[0260] Reference Figure 4A , Figure 4B and Figure 5 Consensus node B, acting as the master consensus node, integrates generated blocks N_A, N_B, and N_C into a block ring N. It then broadcasts block ring N to consensus nodes A and C. For block ring N, consensus nodes A, B, and C all reach a consensus on it, execute events within block ring N, and record block ring N on the block ring chain. Thus, consensus nodes A, B, and C each maintain the same block ring chain, and this chain records block ring N.

[0261] It should be noted that if, during the generation of the block ring, one of the consensus nodes in the block ring chain consensus network does not generate a block in the current consensus cycle (meaning that the node did not participate in the generation of the block ring for the current consensus cycle), the main consensus node still needs to send the block ring to the consensus node that did not participate in the generation of the block ring in the current consensus cycle for on-chain processing. For example, refer to... Figure 7BThe blockchain consensus network includes consensus nodes A, B, C, D, and E. However, consensus nodes B and C do not participate in the generation of the blockchain ring. Consensus node A, as the master consensus node, needs to send blockchain ring N to consensus nodes B, C, D, and E respectively after generating it. Consensus nodes A through E then reach consensus on the blockchain ring, execute the events within the ring, and record the ring on their respective blockchain chains.

[0262] In the embodiment of step 1110 above, multiple consensus nodes reach consensus on the block ring and execute events within the block ring, recording the block ring on their respective maintained block ring chains. Since multiple consensus nodes maintain the same block ring chain, data consistency among them is achieved, thereby improving the fault tolerance of the block ring chain consensus network. Even if one consensus node fails or is attacked, other consensus nodes can still maintain data integrity. Furthermore, unlike related technologies where events are executed before being packaged into blocks, this embodiment first produces blocks and then executes events after obtaining the block ring from the generated blocks. This allows for the sequential execution of each event, reducing event conflict issues, minimizing blockchain record conflicts and inconsistencies between consensus node records, and improving blockchain record security.

[0263] The above is a general description of step 1110. The following is a detailed description of the specific implementation process of step 1110.

[0264] In step 1110, the block ring of the current consensus period is sent to other consensus nodes among multiple consensus nodes so that multiple consensus nodes can reach a consensus on the block ring and execute the events in the block ring, and record the block ring on the block ring chain maintained by each of the multiple consensus nodes.

[0265] In one embodiment, reference is made to Figure 12 Step 1110 includes:

[0266] Step 1210: Obtain the block information of each consensus node from the block ring;

[0267] Step 1220: Obtain the block generated by the consensus node and the first signature information of the consensus node from the block information;

[0268] Step 1230: Verify the generated block using the first signature information;

[0269] Step 1240: Execute multiple events in the generated block.

[0270] Steps 1210 to 1240 are described in detail below.

[0271] In step 1210, the block information of each of the multiple consensus nodes is obtained from the block ring.

[0272] For each consensus node that receives the block ring, the block ring is first parsed to obtain the block information of each consensus node.

[0273] Assume consensus node A receives, for example Figure 9 The block ring N shown can be parsed by consensus node A to obtain the block information N_A corresponding to consensus node A, the block information N_B corresponding to consensus node B, and the block information N_C corresponding to consensus node C.

[0274] In step 1220, the generated block of the consensus node and the first signature information of the consensus node are obtained from the block information.

[0275] After obtaining the block information of each of the multiple consensus nodes, for each consensus node's block information, the block generated by the consensus node and the first signature information of the consensus node are obtained from the block information.

[0276] Reference Figure 9 For block information N_A, obtain the block N_A generated by consensus node A and the first signature information A of the consensus node. For block information N_B, obtain the block N_B generated by consensus node B and the first signature information B of the consensus node. For block information N_C, obtain the block N_C generated by consensus node A and the first signature information C of the consensus node.

[0277] Assume the block circle is a BlockCircle N , refer to Figure 13 This disclosure embodiment uses a block circle. N Input to the event executor for BlockCircle N The parsing process yields the generated blocks and first signature information of each consensus node. This parsing process can be represented as follows:

[0278] {Block N,X},{CircleSig N,X} = DECODE(BlockCircle) N ),

[0279] Among them, BlockCircle N This represents the block circle N, where N is the identifier for the block circle. N This refers to the Nth block ring on the block ring chain. N,X CircleSig represents the generated block of consensus node X obtained through parsing. N,XThis represents the first signature information of consensus node X obtained through parsing, where X∈{A,B,C}. DECODE() is the deserialization function for parsing the block ring.

[0280] In step 1230, the generated block is verified using the first signature information.

[0281] The first signature information corresponds one-to-one with the generated block. The first signature information is the signature obtained by the signing consensus node signing the block header of its predecessor consensus node. Therefore, using the first signature information to verify the generated block can not only verify the correctness of the generated block, but also verify the correctness of the connection between the generated block corresponding to the signing consensus node and the generated block corresponding to the predecessor consensus node.

[0282] Reference Figure 9 Regarding the first signature information A, the correctness of the generated block N_A can be verified using the first signature information A. Furthermore, since the first signature information A is generated by consensus node B, the correctness of the connection between block information N_A and block information N_B can be verified using the first signature information A.

[0283] In step 1240, multiple events in the generated block are executed.

[0284] After multiple generated blocks in the block ring have passed verification, multiple events in the generated blocks are executed.

[0285] Reference Figure 13 At each consensus node in the blockchain consensus network, the blockchain ring is input into the event executor for parsing and verification. Specifically, the blockchain ring is parsed to obtain multiple generated blocks and first signature information, and the first signature information is used to verify the generated blocks. After successful verification, multiple events in the generated blocks are executed.

[0286] In the embodiments of steps 1210 to 1240 above, the block ring includes generated blocks from multiple consensus nodes and first signature information. The first signature information is used to verify the generated blocks. Since the first signature information is generated by the signing consensus node from the block header of the preceding consensus node, and the preceding consensus node is ranked before the signing consensus node, the connection accuracy between the block information of the preceding consensus node and the block information of the signing consensus node can be verified based on the first signature information, thereby improving the accuracy of the block ring on the block ring chain.

[0287] The above is a general description of steps 1210 to 1240. Since step 1220 has been described in detail above, the specific implementation process of steps 1210, 1230 and 1240 will be described in detail below.

[0288] In step 1210, the block information of each of the multiple consensus nodes is obtained from the block ring.

[0289] In one embodiment, reference is made to Figure 14 Step 1210 includes:

[0290] Step 1410: Obtain the block ring body and body signature from the block ring;

[0291] Step 1420: Obtain the first public key of the master consensus node;

[0292] Step 1430: Verify the ontology signature based on the block ring ontology and the first public key;

[0293] Step 1440: After successful verification, obtain the block information of each consensus node from the block ring ontology.

[0294] Steps 1410 to 1440 are described in detail below.

[0295] In step 1410, the block ring body and the body signature are obtained from the block ring.

[0296] A block ring consists of the block ring body and its signature. Therefore, parsing the block ring yields the block ring body and its signature. For example, regarding... Figure 9 Parsing the block ring N shown can yield the block ring body and its signature.

[0297] In step 1420, the first public key of the master consensus node is obtained.

[0298] The first public key is the public key on the master consensus node, and it corresponds to the second private key. The second private key is used to encrypt the block ring ontology corresponding to the master consensus node in the current consensus cycle. Correspondingly, the first public key is used for decryption and signature verification. The first public key can be stored on multiple consensus nodes. For example... Figure 4A In the multiple consensus nodes, the second private key is stored only in consensus node B, while the first public key is stored in consensus nodes A, B, and C.

[0299] In step 1430, the ontology signature is verified based on the block ring ontology and the first public key.

[0300] The ontology signature is obtained by signing the blockchain ontology using the second private key of the primary consensus node. Therefore, the ontology signature can be decrypted using the first public key to obtain the decrypted blockchain ontology. If the decrypted blockchain ontology matches the blockchain ontology obtained from the blockchain, the verification passes; otherwise, the verification fails.

[0301] In step 1440, after successful verification, the block information of each consensus node is obtained from the block ring ontology.

[0302] Once verified, the block information of each consensus node can be obtained from the block ring ontology.

[0303] It should be noted that the block ring entity includes multiple generated blocks. In related technologies, the ParentHash field in a generated block points to the digest value of the previous block in the blockchain, while in this embodiment, the ParentHash field points to the digest value of the previous block ring corresponding to the generated block in the block ring chain. For example, Figure 4B The ParentHash field in the generated blocks N_A, N_B, and N_C shows the digest value of block ring N-1.

[0304] Reference Figure 15 In the process of parsing the block ring, the block ring ontology and ontology signature are first obtained from the block ring. Then, the ontology signature is decrypted using the first public key of the primary consensus node, and the decrypted result is compared with the block ring ontology. If the comparison shows they match, the verification is successful. Afterwards, the block information of each consensus node is obtained from the block ring ontology.

[0305] In the embodiments described in steps 1410 to 1440 above, the block ring includes the block ring body and the body signature. The body signature is a signature obtained by processing the block ring body using the second private key of the master consensus node. Therefore, the body signature can be verified using the first public key of the master consensus node and the block ring body. Successful verification indicates that the block ring body is correct, thus improving the correctness of the block ring and consequently improving the correctness of the block ring chain.

[0306] In step 1230, the generated block is verified using the first signature information.

[0307] In one embodiment, the first signature information includes the signed block header, the signature consensus node identifier, and the signature on the block header.

[0308] Reference Figure 16 Steps 1, 2, 30:

[0309] Step 1610: Obtain the signed block header, the signing consensus node identifier, and the signature on the block header from the first signature information;

[0310] Step 1620: Obtain the second public key of the signature consensus node corresponding to the signature consensus node identifier;

[0311] Step 1630: Decrypt the signature using the second public key to obtain the decrypted result;

[0312] Step 1640: Perform a digest operation on the signed block header to obtain the block header digest;

[0313] Step 1650: Verify the generated block based on the comparison between the decrypted result and the block header digest.

[0314] Steps 1610 to 1650 are described in detail below.

[0315] In step 1610, the signed block header, the signing consensus node identifier, and the signature on the block header are obtained from the first signature information.

[0316] The first signature information includes the signed block header, the signing consensus node identifier, and the signature on the block header. Therefore, after obtaining the first signature information from the block information, the signed block header, the signing consensus node identifier, and the signature on the block header can be further obtained from the first signature information.

[0317] Reference Figure 7A For the first signature information C, the obtained signed block header is block header C, the signing consensus node identifier is consensus node A, and the signature on block header C. For the first signature information A, the obtained signed block header is block header A, the signing consensus node identifier is consensus node B, and the signature on block header A. For the first signature information B, the obtained signed block header is block header B, the signing consensus node identifier is consensus node C, and the signature on block header A.

[0318] It should be noted that, in this embodiment of the disclosure, the block header of the generated block corresponding to the first signature information can also be used as the block header to be signed.

[0319] In step 1620, the second public key of the signature consensus node corresponding to the signature consensus node identifier is obtained.

[0320] The second public key is the public key of the signing consensus node that identifies the signing consensus node. It is the public key used to decrypt and verify the signature in the block header. The second public key is stored in multiple consensus nodes of the blockchain ring chain consensus network.

[0321] Reference Figure 4A Consensus node A stores the second public keys of consensus nodes A, B, and C; consensus node B stores the second public keys of consensus nodes A, B, and C; and consensus node C stores the second public keys of consensus nodes A, B, and C. Therefore, signature verification of the block header can be completed locally on each consensus node.

[0322] In step 1630, the signature is decrypted using the second public key to obtain the decrypted result.

[0323] The first signature is the signature information generated by the signing consensus node in response to the block header of the preceding consensus node. The second public key is the public key of the signing consensus node; therefore, the signature can be decrypted using the second public key to obtain the decrypted result.

[0324] It should be noted that, to ensure data accuracy, the signature in the first signature information is typically the signature of the block header digest value by the signing consensus node. Therefore, the decrypted result is the digest value of the decrypted signed block header, and since this digest value is the result of encryption and decryption, it is usually the accurate digest value of the block header.

[0325] In step 1640, a digest operation is performed on the signed block header to obtain the block header digest.

[0326] A block header digest is the result of performing a digest operation on the signed block header. In a blockchain ring-chain consensus network, hash operations are typically used as digest operations. For example, assuming the signed block header is {block identifier 1, timestamp 1, ...}, performing a hash operation on this block header yields a block header digest, which can be represented as {*&%GKJVF$@&}. The block header digest is an encrypted block header, possessing immutability. The block header can be verified through the block header digest, thereby ensuring the integrity of the event object index.

[0327] In step 1650, the generated block is verified based on the comparison between the decrypted result and the block header digest.

[0328] After determining the decrypted result and the block header digest, the decrypted result is compared with the block header digest to verify the generated block. If they match, the verification passes; otherwise, the verification fails.

[0329] It should be noted that the verification of block generation can be represented as:

[0330] Valid X =VERIFY(Block) N,X.Prev .Header.Hash,CircleSig N,X.Prev ,X),

[0331] Where X represents the signature consensus node identifier, in Figure 4A In the diagram, X∈{A,B,C}. VERIFY(Λ,X) is the signature verification function for the second public key of the consensus node, i.e., consensus node X. N,X.Prev.Header.Hash is the header of the signed block, that is, the block header digest of the previous neighboring consensus nodes of the signing consensus node, CircleSig N,X.Prev It is the signature corresponding to the signed block header, Valid X This indicates the validation result. If each generated block corresponds to a Valid... X If both are true, the block ring is correct and valid, and events within the block ring can be executed. Otherwise, the block ring is invalid and needs to be regenerated.

[0332] Reference Figure 17 After determining the first signature information for generating a block, the process involves obtaining the signed block header, the signing consensus node, and the signature on the block header. The signature on the block header is decrypted using the second public key of the signing consensus node, yielding the decrypted result. Simultaneously, a digest operation is performed on the signed block header to obtain the block header digest. The verification result is determined by comparing the block header digest and the decrypted result. If the block header digest and the decrypted result match, the block generation verification passes; otherwise, the verification fails.

[0333] In the embodiments of steps 1610 to 1650 above, the first signature information includes the signature of the block header. To ensure data accuracy, this signature is a signature of the digest value of the block header of the block generated by the signing consensus node and the block generated by the preceding consensus node. Therefore, the second public key of the signing consensus node can decrypt the signature and verify the generated block by comparing the decrypted result with the block header digest obtained from the digest operation. This improves the accuracy of the block generated by the preceding consensus node and enhances the accuracy of the block information of the signing consensus node and the connection between the information of the signing consensus node and the preceding consensus node. Furthermore, determining the block information through comparison of the block header digest is more accurate than determining the block header itself, further improving the accuracy of the block information in the block ring.

[0334] In step 1240, multiple events in the generated block are executed.

[0335] In one embodiment, reference is made to Figure 18 Step 1240 includes:

[0336] Step 1810: Execute the events in the generated blocks of each of the other consensus nodes besides the main consensus node;

[0337] Step 1820: Execute the events in the block generated by the master consensus node.

[0338] Steps 1810 and 1820 are described in detail below.

[0339] In step 1810, the events in the generated blocks of each of the other consensus nodes besides the main consensus node are executed.

[0340] When executing multiple block-generating events within the block ring, the events in the blocks generated by each of the other consensus nodes (excluding the primary consensus node) are executed first. (Refer to...) Figure 4A and Figure 19A , Figure 19B Since the primary consensus node is consensus node B, when executing multiple block-generating events in the block ring, events in block A generated by consensus node A and block C generated by consensus node C are executed first.

[0341] When executing events in the blocks generated by other consensus nodes besides the primary consensus node, there are no restrictions on the execution order of these events. Execution can begin from any generated block in the block ring and proceed in the order of the generated blocks within the ring, simply ignoring the primary consensus node's generated blocks during execution. Alternatively, a generated block can be randomly selected from the generated blocks of other consensus nodes besides the primary consensus node, and the events within that block can be executed.

[0342] In step 1820, the events in the block generation of the master consensus node are executed.

[0343] After the events in the generated blocks of all other consensus nodes besides the primary consensus node have been executed, the events in the generated blocks of the primary consensus node are executed. Assume... Figure 4A In this model, consensus node A corresponds to generating block A, consensus node B corresponds to generating block B, and consensus node C corresponds to generating block C. Figure 19A and Figure 19B These are two different ways to execute events that generate multiple blocks in the block ring. In both ways, the events in block B generated by the primary consensus node, i.e., consensus node B, are executed last.

[0344] Assuming the blockchain ring processing method of this embodiment is applied to an electronic invoice scenario, and the reimbursement limit for a catering electronic invoice is 1000 yuan, the multiple consensus nodes corresponding to the blockchain ring include consensus node A, consensus node B, and consensus node C, with consensus node B as the main consensus node. Consensus node A has an event "Catering invoice with a reimbursement value of 300 yuan". The generated blocks corresponding to the multiple consensus nodes are processed by consensus node B to generate the blockchain ring. If consensus node B acts maliciously, it may generate a "Catering invoice with a reimbursement value of 1000 yuan" based on the event "Catering invoice with a reimbursement value of 300 yuan" in block A generated by consensus node A. If the events in the generated blocks of each of the other consensus nodes (excluding the main consensus node) are executed first, then the event "Catering invoice with a reimbursement value of 300 yuan" can be executed normally, and the catering invoice with a value of 300 yuan can be reimbursed. However, if events in the main consensus node's block generation are executed first, such as "reimbursement of restaurant invoices worth 1000 yuan," the reimbursement amount becomes 0, thus affecting the execution of the event "reimbursement of restaurant invoices worth 300 yuan." Therefore, executing events in the main consensus node's block generation after other consensus nodes' block generation reduces the possibility of event preemption attacks and improves the security of the block ring consensus network.

[0345] If events in the blocks generated by the primary consensus node are executed first, malicious behavior by the primary consensus node could lead to the generation of events related to those in other consensus nodes. For example, if an event in another consensus node is "reimbursement of restaurant invoices worth 300 yuan," and the primary consensus node generates an event for "reimbursement of restaurant invoices worth 1000 yuan," this could constitute a preemptive attack, affecting the execution of events in other consensus nodes. Therefore, the embodiments of steps 1810 and 1820 above, which place the events in the blocks generated by the primary consensus node after the blocks generated by other consensus nodes, reduce the likelihood of preemptive attacks and improve the security of the block ring consensus network.

[0346] The above is a general description of steps 1810 and 1820. Since step 1820 has been described in detail above, the specific implementation process of step 1810 will be described in detail below.

[0347] In step 1810, the events in the generated blocks of each of the other consensus nodes besides the main consensus node are executed.

[0348] In one embodiment, reference is made to Figure 20 Step 1810 includes:

[0349] Step 2010: Select the block to be executed from the blocks generated by each of the other consensus nodes besides the main consensus node;

[0350] Step 2020: Execute the events in the block to be executed.

[0351] Steps 2010 and 2020 are described in detail below.

[0352] In step 2010, a block to be executed is selected from the blocks generated by each of the other consensus nodes besides the main consensus node.

[0353] Each consensus node other than the master consensus node generates multiple blocks. To ensure the orderly execution of events in each generated block, it is necessary to select a block to be executed from the generated blocks of each of the other consensus nodes.

[0354] Reference Figure 4A and Figure 19A Consensus node A corresponds to block A, consensus node B corresponds to block B, and consensus node C corresponds to block C. Consensus node B is the primary consensus node. Therefore, either block A or block C can be selected as the block to be executed.

[0355] In step 2020, the events in the block to be executed are performed.

[0356] After determining the block to be executed, the events in the block to be executed are executed. If the events in the block to be executed have been completed, and there are still unexecuted events in generated blocks other than those generated by the main consensus node, then one generated block is selected as the block to be executed from among the unexecuted generated blocks other than those generated by the main consensus node.

[0357] Assume the block ring corresponds to multiple generated blocks including generated block 1, generated block 2, generated block 3, generated block 4, and generated block 5, with generated block 4 being the generated block of the primary consensus node. First, one generated block from among generated block 1, generated block 2, generated block 3, and generated block 5 is selected as the block to be executed, and the events in that block are executed. If the block to be executed is generated block 1, and the events in that block have been executed, then another generated block is selected from generated block 2, generated block 3, and generated block 5 to update the block to be executed. This process of updating generated blocks continues until the events in all generated blocks except the generated block of the primary consensus node have been executed.

[0358] The embodiments of steps 2010 and 2020 above select blocks to be executed from the generated blocks of each of the other consensus nodes besides the main consensus node and execute the events in the blocks to be executed. This determines the execution order for multiple generated blocks with the same block production time, and only executes the events in a single generated block at the same time. This reduces the problems of execution conflicts of multiple generated blocks with the same block production time and event conflicts in multiple generated blocks, and improves the security of the block execution process.

[0359] The above is a general description of steps 2010 and 2020. The following is a detailed description of the specific implementation process of steps 2010 and 2020.

[0360] In step 2010, a block to be executed is selected from the blocks generated by each of the other consensus nodes besides the main consensus node.

[0361] In one embodiment, reference is made to Figure 21 Step 2010 includes:

[0362] Step 2110: Starting from the next consensus node after the primary consensus node in the predetermined order, take the generated blocks of each of the other consensus nodes as blocks to be executed in the predetermined order.

[0363] Step 2110 will be described in detail below.

[0364] In step 2110, starting from the next consensus node in the predetermined order of the primary consensus node, the generated blocks of each of the other consensus nodes are sequentially taken as blocks to be executed in the predetermined order.

[0365] The predetermined order is the arrangement of multiple consensus nodes, which is also the basis for determining the order of the blocks generated by each consensus node in the current consensus cycle. To facilitate the rapid determination of the blocks to be executed, this embodiment of the disclosure starts from the consensus node next to the main consensus node in the predetermined order, and sequentially uses the blocks generated by each of the other consensus nodes as the blocks to be executed according to the predetermined order.

[0366] Reference Figure 4A If the primary consensus node is consensus node B, then first, block C generated by consensus node C is set as the block to be executed. After the events in block C are executed, block A generated by consensus node A is set as the block to be executed. Finally, the events in block B generated by consensus node B are executed. The execution order of each generated block can be referred to... Figure 19B As shown, the execution order is to generate block C, generate block A, and generate block B. The specific execution order can be represented as follows:

[0367] TXs = {Block N,C .TX,BlockN,A .TX,Block N,A .TX}

[0368] Where TXs represents the execution order of events that generate multiple blocks in the block ring. N,C .TX represents the event in block C generated by block ring N. N,A .TX represents the event in block A generated by block ring N. N,B .TX represents the event in block B generated by block ring N.

[0369] Furthermore, if, in the predetermined sequence, there is a consensus node that did not participate in the generation of the block ring for the current period, then during the process of determining the block to be executed, that consensus node is skipped, and the block generated by the next consensus node in the predetermined sequence that participates in the generation of the block ring for the current period is taken as the block to be executed. For example, suppose... Figure 4A Among the multiple consensus nodes shown, consensus node C did not participate in the generation of the block ring, so block A generated by consensus node A will be the block to be executed.

[0370] In the embodiment of step 2110 above, the first block to be executed is the block generated by the next consensus node after the main consensus node in the predetermined order. Then, the blocks to be executed are selected according to the predetermined order. The predetermined order is more convenient and faster than other methods. It does not require repeatedly determining the blocks to be executed among multiple unexecuted generated blocks, thus improving the execution efficiency of multiple events in the block ring.

[0371] In step 2020, the events in the block to be executed are performed.

[0372] In one embodiment, each of the multiple consensus nodes has its own table of executed events.

[0373] Reference Figure 22 Step 2020 includes:

[0374] Step 2210: At the start of the current consensus cycle, clear the executed event table;

[0375] Step 2220: Obtain events sequentially from the block to be executed;

[0376] Step 2230: If it is determined that the obtained event is not in the executed event table, execute the event and add the event to the executed event table.

[0377] Steps 2210 to 2230 are described in detail below.

[0378] The executed events table corresponds to the consensus cycle. It records the events that have been executed within the current consensus cycle. Referring to the executed events table before event 4 in block C generated by 23A, events 1, 2, and 3 are all events that have been executed within the current cycle.

[0379] In a multi-consensus network, it's possible for two or more nodes to record the same event. For example, in a blockchain consensus network used for e-invoices, the client communicates with both consensus nodes 1 and 2. When the client generates an e-invoice event A, it sends event A to both nodes, resulting in both nodes recording it. Thus, the same event might be recorded in two or more generated blocks within the current consensus cycle. To mitigate data errors caused by multiple executions of the same event, an executed event table is used to record events executed within the current consensus cycle.

[0380] In step 2210, at the start of the current consensus cycle, the executed event table is cleared.

[0381] The executed event table corresponds to the consensus cycle. In order to reduce the storage space occupied by the executed event table, it is cleared at the beginning of the current consensus cycle.

[0382] In step 2220, events are retrieved sequentially from the block to be executed.

[0383] After determining the block to be executed, events are retrieved sequentially from that block. (See reference...) Figure 19A Assuming that block A is the block to be executed, then events 1, 2, 3, ... are obtained sequentially from block A.

[0384] In step 2230, if it is determined that the acquired event is not in the executed event table, the event is executed and added to the executed event table.

[0385] For the currently acquired event, query the executed events table. If the acquired event is not in the executed events table, then the event has not been executed within the current consensus period. In this case, execute the acquired event, and add the event to the executed events table after the event is executed, indicating that the event has been executed within the current consensus period.

[0386] Reference Figure 19A and Figure 23AAt the current moment, multiple events in block A have been executed, and the executed event table records events 1, 2, and 3 for block generation. Event 4 is retrieved from block C. A query of the executed event table confirms that event 4 is not present in the table. Event 4 is then executed and added to the executed event table.

[0387] Reference Figure 13 If it is determined that the acquired event is not in the executed event table, then the event is executed, and the event status data is updated. The event status data corresponds to the event. For example, if the event is "reimburse an electronic restaurant invoice worth 300 yuan," and the reimbursement limit for the electronic restaurant invoice is 1000 yuan, then after the event is executed, the event status data changes from "reimbursement limit for the electronic restaurant invoice is 1000 yuan" to "reimbursement limit for the electronic restaurant invoice is 7000 yuan." Afterwards, the executed event table is updated, adding the executed event to the table. Then, if multiple events in the blockchain ring are not completed, the next event is acquired. If multiple events in the blockchain ring are completed, the execution of blockchain ring events for the current consensus cycle is terminated.

[0388] The embodiments described in steps 2210 to 2230 above establish an executed event table, which corresponds to a consensus period and records executed events within that period. At the start of the current consensus period, the executed event table is cleared, and expired data is deleted, reducing the storage space occupied by the table and minimizing data redundancy. Furthermore, if an event is not found in the executed event table, it indicates that the event has not yet been executed within the current consensus period. The event is then executed and added to the executed event table, improving the completeness of the multiple executed events recorded in the table.

[0389] In one embodiment, reference is made to Figure 24 Following step 2220, the block ring chain processing method includes:

[0390] Step 2410: If it is determined that the obtained event is in the executed event table, discard the event.

[0391] Step 2410 will be described in detail below.

[0392] In step 2410, if it is determined that the acquired event is in the executed event table, the event is discarded.

[0393] If the obtained event is found in the executed event table, it means that the obtained event has already been executed within the current consensus cycle and there is no need to execute the event again. Therefore, the event needs to be discarded.

[0394] Reference Figure 19A and Figure 23B After obtaining event 2 from block C, events 1, 2, and 3 from block A, and event 4 from block C have all been executed and recorded in the executed events table. Based on event 2 obtained from block C, it is determined that... Figure 23B If event 2 exists in the executed event table, then event 2 in block C is discarded.

[0395] Reference Figure 13 If an event obtained from the pending block is found to be in the executed event table, then the obtained event has already been executed. In this case, the event is discarded, and the next event after the currently obtained event is obtained, so that the execution of the event is re-determined based on the executed event table. If multiple events in the block ring have been executed, the execution of block ring events in the current consensus cycle is terminated.

[0396] In the embodiment of step 2410 above, if it is determined that the obtained event is in the executed event table, it means that the obtained event has been executed within the current consensus cycle. Discarding the event can reduce the occurrence of errors in event state data caused by repeated execution of the same event, thereby improving the security of the blockchain ring chain.

[0397] In step 2410, if it is determined that the acquired event is in the executed event table, the event is discarded.

[0398] In one embodiment, the executed event table stores the first summary value of the executed events.

[0399] Reference Figure 25 Step 2410 includes:

[0400] Step 2510: Perform a digest operation on the acquired events to obtain the second digest value;

[0401] Step 2520: If the second digest value matches a first digest value in the executed event table, determine that the obtained event is in the executed event table;

[0402] Step 2530, Discard Event.

[0403] Steps 2510 to 2530 are described in detail below.

[0404] The first digest value is the first digest value of the executed event. It is the result of performing a digest operation on the executed event. In a blockchain ring chain consensus network, hashing is typically used as the digest operation. Assuming the executed event is "Issuing an electronic travel invoice worth 30", performing a hash operation on the executed event yields the first digest value, which can be represented as "&#FK*%". The first digest value is the encrypted executed event, possessing immutability and uniqueness.

[0405] In step 2510, a digest operation is performed on the acquired events to obtain a second digest value.

[0406] Since the executed event table stores the first digest value of executed events, determining whether a retrieved event is in the executed event table first requires determining the digest value of the retrieved event. Specifically, a digest operation is performed on the retrieved event to obtain the second digest value.

[0407] The second digest value is the digest value obtained by performing a digest operation on the acquired events.

[0408] In step 2520, if the second digest value matches a first digest value in the executed event table, it is determined that the acquired event is in the executed event table.

[0409] In determining the second digest value, a query is performed in the executed events table based on the second digest value. If the second digest value matches a first digest value in the executed events table, the retrieved event is determined to be in the executed events table.

[0410] Reference Figure 23B The executed events table records the summary values ​​of events 1 through 4. To check if the executed events table contains event 2, which generates block C, we first need to perform a summary operation on event 2 to obtain its second summary value. If the summary value of event 2 at index 2 matches the second summary value, then event 2 is in the executed events table.

[0411] In step 2530, the event is discarded.

[0412] If the obtained event is found in the executed event table, there is no need to execute the event again, and the event is discarded.

[0413] For each event in the acquired block ring, first check if the event is in the executed event table. This process can be represented as:

[0414] Res = FinishedTXs.Contains(TX) i .Hash),

[0415] Here, `Res` is a flag indicating whether the retrieved event is in the executed event table. `Res` is true if the retrieved event is in the executed event table, and false if it is not. `FinishedTXs` is the executed event table, where `TX`... i .Hash is the hash of the retrieved event TX. iThe second digest value obtained by performing the digest operation, Contains, is used to determine whether there exists a match between the second digest value TX and the completed event table FinishedTXs. i A function that returns the first digest value that is equal to the hash value.

[0416] If Res is false, meaning the retrieved event is not in the executed events table, execute the event and add it to the executed events table:

[0417] FinishedTXs.Add(TX i .Hash)

[0418] Where Add is the second summary value TX of the acquired event. i .Hash functions added to the FinishedTXs event table.

[0419] In the embodiments of steps 2510 to 2530 above, the executed event table stores the first digest value of each executed event. When determining whether the obtained event is in the executed event table, it is necessary to calculate the second digest value of the obtained event. The first digest value and the second digest value are immutable and unique. Compared with the event, the setting of the digest value is more accurate, thereby improving the accuracy of determining whether the obtained event is in the executed event table and improving the execution accuracy of the events that generate blocks in the block ring.

[0420] The above is a general description of steps 2510 to 2530. Since steps 2510 and 2530 have been described in detail above, the specific implementation process of step 2520 will be described in detail below.

[0421] In step 2520, if the second digest value matches a first digest value in the executed event table, it is determined that the acquired event is in the executed event table.

[0422] In one embodiment, the executed event table also stores information about the first event initiator corresponding to the first summary value.

[0423] Reference Figure 26 Step 2520 includes:

[0424] Step 2610: If the second summary value is consistent with a first summary value in the executed event table, and the second event initiator information of the obtained event is consistent with the first event initiator information corresponding to the first summary value, then it is determined that the obtained event is in the executed event table.

[0425] Step 2610 will be described in detail below.

[0426] The first event initiator information is the initiator information of the event corresponding to the first summary value.

[0427] Assuming event 1 is "Issuing an e-invoice for travel with a value of 30", the first summary value of event 1 is "&#FK*%", and "Issuing an e-invoice for travel with a value of 30" is initiated by object A, then the first event initiator information for event 1 is "object A". If event 1 is in the executed event table, then the executed event table includes the first summary value "&#FK*%" and the first event initiator information "object A".

[0428] In step 2610, if the second summary value is consistent with a first summary value in the executed event table, and the second event initiator information of the obtained event is consistent with the first event initiator information corresponding to the first summary value, then it is determined that the obtained event is in the executed event table.

[0429] The second event initiator information refers to the initiator information of the obtained event. Assuming the obtained event is "Issuing an electronic invoice for catering with a value of 40" initiated by object C, then the second event initiator information is object C.

[0430] If the second summary value matches a first summary value in the executed events table, the second event initiator information of the acquired event is further compared with the first event initiator information corresponding to the first summary value. If the second event initiator information matches the first event initiator information, the acquired event is determined to be in the executed events table. If the second event initiator information does not match the first event initiator information, the acquired event is determined not to be in the executed events table. The comparison of the first and second event initiator information applies to situations where different objects initiate the same event. For example, both object A and object B initiate the event "Issue an electronic travel invoice with a value of 30".

[0431] In addition to the first digest value, the executed event table also stores the first event initiator information corresponding to the first digest value in the embodiment of step 2610 above. This setting is applicable to the situation where different objects initiate the same event. Therefore, when determining whether the acquired event exists in the executed event table, it is necessary to compare the first digest value and the first event initiator information, thereby improving the accuracy of determining whether the acquired event has been executed and improving the accuracy of block ring execution.

[0432] In another embodiment, reference Figure 27 Step 1810 includes:

[0433] Step 2710: For the events in the generated blocks of each of the other consensus nodes besides the main consensus node, determine the event objects associated with the events;

[0434] Step 2720: Classify the events associated with the same event object into event groups;

[0435] Step 2730: Input the event group into the event execution order prediction model to obtain the event execution order of each event in the event group;

[0436] Step 2740: Execute each event in the event group based on the event execution order.

[0437] Steps 2710 to 2740 are described in detail below.

[0438] In step 2710, for events in the generated blocks of each of the other consensus nodes besides the main consensus node, the event objects associated with the events are determined.

[0439] An event object is associated with an event. It is not the object that initiates the event, but rather the object corresponding to the data that is changed after the event is executed. For example, if the event is "reimbursement of a restaurant e-invoice with a value of 40", then the event object is the restaurant e-invoice. If the event is "the traffic light at intersection L changes from red to green", then the event object is "the state of the traffic light at intersection L".

[0440] After determining the events in the execution block ring, since the blocks generated by the main consensus node need to be executed last, the event objects associated with the events in the blocks generated by each of the other consensus nodes besides the main consensus node are determined.

[0441] Assuming that block A contains events 1, 2, and 3, block B contains events 4, 5, and 6, and block C contains events 7, 8, and 9, and block C is the block generated by the main consensus node, then for events 1, 2, 3, 4, 5, and 6, the event objects associated with each event are determined in sequence.

[0442] In step 2720, events associated with the same event object are classified into event groups.

[0443] Event groups are configured to correspond to event objects. An event group is a group containing multiple events associated with the event object corresponding to that event group. (See reference...) Figure 28 Based on the event objects associated with each event, events 1, 2, 3, 4, 5, and 6 are divided into three event groups. Event group 1 corresponds to event object A and includes events 1 and 5. Event group 2 corresponds to event object B and includes events 2 and 6. Event group 3 corresponds to event object C and includes events 3 and 4.

[0444] In step 2730, the event group is input into the event execution order prediction model to obtain the event execution order of each event in the event group.

[0445] The event execution order is the sequence in which multiple events are executed.

[0446] An event execution order prediction model is a model that predicts the execution order of multiple events within an event group. This model can be a large language model or a neural network model. For each event in an event group—that is, each event corresponding to the same event object—the event execution prediction model can analyze data such as the event initiator information to determine the execution order of each event.

[0447] Assuming the event group corresponds to the reimbursement amount of electronic invoices for catering, the event group includes event 1 and event 2. If the priority of the initiator of event 1 is higher than that of the initiator of event 2, then by inputting the event group into the event execution prediction model, the execution order of the events can be determined to be event 1, event 2, that is, event 1 is executed first.

[0448] In step 2740, each event within the event group is executed based on the event execution order.

[0449] After determining the event execution order, for each event group, each event within the event group is executed based on the event execution order corresponding to the event group.

[0450] The execution order among multiple event groups is uncertain. Event groups can be randomly selected from multiple event groups, and each event in the event group can be executed. Alternatively, the events that are ranked first in the execution order of multiple event groups can be executed sequentially, followed by the events that are ranked second in the execution order of multiple event groups, and so on, until all events in multiple event groups have been executed.

[0451] Reference Figure 28 The execution order of events in event group 1 is event 5, event 1; the execution order of events in event group 2 is event 2, event 6; and the execution order of events in event group 3 is event 4, event 6.

[0452] The embodiments of steps 2710 to 2740 above classify the events in the generated blocks of each consensus node other than the main consensus node into multiple event groups based on the event objects associated with the events. Then, the execution order of multiple event groups can be determined according to the importance between the event objects. In addition, in the same event group, the execution order of each event is predicted based on the event execution prediction model. The setting of the event execution prediction model can analyze and predict the importance of each event, thereby improving the prediction accuracy of the execution order and improving the security of block ring execution.

[0453] In one embodiment, reference is made to Figure 29 Following step 2720, the block ring chain processing method further includes:

[0454] Step 2910: Based on each event in the event group, use the event group summary prediction model to predict the event group summary;

[0455] Step 2920: Based on the event group summary, determine the execution order of each event group;

[0456] Step 2930: Execute the events in each event group based on the execution order of the event groups.

[0457] Steps 2910 to 2930 are described in detail below.

[0458] In step 2910, based on each event in the event group, the event group summary is predicted using the event group summary prediction model.

[0459] An event group summary is a summary of the main content of each event in an event group. Assuming that the blockchain is applied to traffic data, event group A includes event 1 "the traffic light at intersection A changes from green to red" and event 2 "the traffic flow at intersection A is 40 vehicles per minute". Then the event group summary of event group A can be the traffic light status and traffic flow at intersection A.

[0460] An event group summary prediction model is a model that predicts the event group summary of an event group. The event group prediction model can be a neural network model or a large language model. The event group summary prediction model is trained by multiple existing event groups and event group summaries. A well-trained event group summary prediction model can accurately predict the event group summary.

[0461] In step 2920, the execution order of each event group is determined based on the event group summary.

[0462] The event group execution order refers to the order in which multiple event groups corresponding to events in the blocks generated by each of the other consensus nodes (excluding the master consensus node) are executed. The importance of each event group can be determined based on its summary, thus determining the execution order of each event group.

[0463] Suppose that the event group summary of event group A is "traffic light status and traffic flow at intersection A", and the event group summary of event group B is "traffic flow at intersection M". Compared to intersection M, intersection A is a traffic hub, and timely changes to the traffic light status are more important than traffic flow. Therefore, the execution order of event group A is before that of event group B.

[0464] In step 2930, events in each event group are executed based on the execution order of the event groups.

[0465] After determining the execution order of the event groups, the events in each event group are executed sequentially.

[0466] Reference Figure 28 and Figure 30 First, using the event group summary prediction model, the event group summary 1 for event group 1, the event group summary 2 for event group 2, and the event group summary 3 for event group 3 are determined. The execution order of the event groups is then determined as: event group 2, event group 1, event group 3, and events in the generated blocks of the main consensus node. When executing each event in event group 2, event group 1, and event group 3, it can be based on... Figure 28 The event execution order shown is obtained from the event execution prediction model, which executes the events in each event group in sequence.

[0467] The embodiments described in steps 2910 to 2930 above determine the execution order of event groups through event group summaries. These summaries indicate the importance of each event within a group, improving the accuracy of the execution order and consequently enhancing the accuracy and security of the block ring execution. Furthermore, since the event group summaries are determined using an event group prediction model, the resulting summary values ​​are more precise, further improving the accuracy of the event group execution order.

[0468] Steps 310 to 360 have been explained in detail above. The following sections will elaborate on some specific points and related concepts. These topics include the generation of the previous neighbor block digest value and the generation of the first signature information.

[0469] Generation of ring digest values ​​of previous neighbor blocks

[0470] In one embodiment, the block header includes the ring digest value of the preceding neighboring block. For example... Figure 31 As shown, the ring digest value of the previous neighbor block is generated in the following way:

[0471] Step 3110: Obtain the previous block ring on the block ring chain. The previous block ring was recorded on the block ring chain in the consensus cycle preceding the current consensus cycle.

[0472] Step 3120: Calculate the digest value of the previous block ring as the digest value of the previous neighboring block ring.

[0473] Steps 3110 and 3120 are described in detail below.

[0474] The preceding neighbor block ring digest value refers to the block ring digest value of the block ring corresponding to the block to which the block header belongs, which is the block ring preceding the previous block ring in the block ring chain. The block ring digest value is a key element used to uniquely identify a block ring. Therefore, based on the preceding neighbor block ring digest value in the block header, it is possible to determine the previous block ring in the block ring chain corresponding to the block header.

[0475] Reference Figure 4B If block ring N+1 is located on the block ring chain, then the preceding block ring is block ring N. If generated blocks N+1_A, N+1_B, and N+1_C are located on block ring N+1, then the block headers of these generated blocks all store the block ring digest value of block ring N.

[0476] Furthermore, the previous neighbor block ring digest value is stored in the ParentHash field of the block header. In related technologies, the ParentHash field in the generated block points to the digest value of the previous block in the blockchain. However, in this embodiment, the ParentHash field in the generated block points to the digest value of the previous block ring in the block ring chain corresponding to the generated block, i.e., the previous neighbor block ring digest value. The previous neighbor block ring digest value in the block header can be represented as:

[0477] Block N+1,X .Header.ParentHash=BlockCircle N .Hash,

[0478] Among them, Block N+1,X .Header.ParentHash is the ParentHash field of the block header in the block circle N+1. N .Hash is the block ring digest value of block ring N.

[0479] In step 3110, the previous block ring on the block ring chain is obtained. The previous block ring was recorded on the block ring chain in the consensus cycle preceding the current consensus cycle.

[0480] The previous block ring is the block ring generated in the consensus cycle preceding the current consensus cycle, and it is also the block ring digest value of the block ring preceding the current consensus cycle in the block ring chain. (Refer to...) Figure 4B Block ring N-1 is the preceding block ring of block ring N, and block ring N is the preceding block ring of block ring N+1.

[0481] In step 3120, the digest value of the previous block ring is calculated and used as the digest value of the previous neighboring block ring.

[0482] After determining the previous block ring, calculate the digest value of the previous block ring, which is then used as the digest value of the previous neighboring block ring. (Refer to...) Figure 4B The digest value of block ring N-1 is the digest value of the previous neighbor block ring in the block header of each generated block in block ring N, and the digest value of block ring N is the digest value of the previous neighbor block ring in the block header of each generated block in block ring N+1.

[0483] In the embodiments of steps 3110 and 3120 above, the block header of the block generated in the current period includes the previous neighbor block ring digest value. The previous neighbor block ring digest value is the digest value of the block ring recorded on the block ring chain in the previous consensus period of the current consensus period. Therefore, based on the previous neighbor block ring digest value, the previous block ring connected to the block ring of the current consensus period can be determined, and the connection relationship between the two block rings can be determined, which improves the security of the connection between the various block rings in the block ring chain.

[0484] Generation of the first signature information

[0485] The first signature is the encrypted information in the block header that generates the block. Multiple consensus nodes participating in the block ring generation, including the master consensus node, will generate the first signature.

[0486] In one embodiment, reference is made to Figure 32 The first signature information is generated by the signature consensus node in the following way:

[0487] Step 3210: Determine other consensus nodes from which the block header received by the signing consensus node within the current consensus period originates, and use them as candidate consensus nodes;

[0488] Step 3220: The last candidate consensus node that is ranked before the signature consensus node in the predetermined order is determined as the previous neighbor consensus node;

[0489] Step 3230: Use the first private key of the signing consensus node to sign the block header of the previous neighboring consensus node to obtain the first signature information.

[0490] Steps 3210 to 3230 are described in detail below.

[0491] In step 3210, other consensus nodes from which the block headers received by the signing consensus node in the current consensus cycle originate are identified as candidate consensus nodes.

[0492] Candidate consensus nodes are the consensus nodes from which the block headers received by the signing consensus nodes originate. (See reference...) Figure 4A Consensus node B will receive the block header of block A generated by consensus node A and the block header of block C generated by consensus node C. Therefore, consensus nodes A and C are considered as candidate consensus nodes. If consensus node B only receives the block header of block A generated by consensus node A, then only consensus node B is considered as a candidate consensus node.

[0493] In step 3220, the last candidate consensus node that is ranked before the signature consensus node in a predetermined order is determined as the previous neighbor consensus node.

[0494] Based on a predetermined order, the last candidate consensus node preceding the signature consensus node is determined and designated as the preceding neighbor consensus node.

[0495] Reference Figure 4A Consensus node B receives the block header of block A generated by consensus node A, and the block header of block B generated by consensus node B. Between consensus node A and consensus node C, consensus node A is the last candidate consensus node preceding the signing consensus node; therefore, consensus node A is determined to be the preceding neighbor consensus node of the signing consensus node.

[0496] In step 3230, the first private key of the signing consensus node is used to sign the block header of the previous neighboring consensus node to obtain the first signature information.

[0497] The first private key is used at the signing consensus node to encrypt the block header of the previous consensus node, and it is stored only at the signing consensus node. The first private key corresponds to the second public key. The first private key is used to encrypt the block header of the previous consensus node, while the second public key is used to decrypt the signature in the first signature information to obtain the block header of the previous consensus node.

[0498] Reference Figure 4A If the previous neighbor of consensus node B is consensus node A, then consensus node B uses its first private key to sign the block header of block A generated by consensus node A.

[0499] It should be noted that, in order to improve the accuracy of the first signature information, the first private key of the signing consensus node usually signs the block digest value stored in the block header of the previous neighboring consensus node to obtain the first signature information.

[0500] The embodiments of steps 3210 to 3230 above determine the last consensus node that is arranged in a predetermined order before the signature consensus node, as the previous neighbor consensus node of the signature generation node, and sign the block header of the previous neighbor consensus node. This is applicable to the situation where some consensus nodes have few events and have not obtained corresponding generated blocks in the current consensus cycle, so that the generated blocks in the block ring can be connected sequentially, thus improving the applicability of the block ring chain processing method.

[0501] It is understood that although the steps in the above flowcharts are shown sequentially according to the arrows, these steps are not necessarily executed in the order indicated by the arrows. Unless explicitly stated in this embodiment, there is no strict order restriction on the execution of these steps, and they can be executed in other orders. Moreover, at least some steps in the above flowcharts may include multiple steps or multiple stages. These steps or stages are not necessarily completed at the same time, but can be executed at different times. The execution order of these steps or stages is not necessarily sequential, but can be performed alternately or in turn with other steps or at least some of the steps or stages in other steps.

[0502] It should be noted that in various specific embodiments of this application, when processing is required based on data related to the characteristics of the target object, such as target object attribute information or a set of attribute information, the permission or consent of the target object will be obtained first. Furthermore, the collection, use, and processing of this data will comply with relevant laws, regulations, and standards. In addition, when embodiments of this application require obtaining target object attribute information, separate permission or consent from the target object will be obtained through pop-ups or redirection to a confirmation page. Only after obtaining the target object's separate permission or consent will the necessary target object-related data for the normal operation of the embodiments of this application be obtained.

[0503] Description of apparatus and devices according to embodiments of this disclosure

[0504] Figure 33 This is a schematic diagram of the structure of the block ring processing device 3300 provided in this embodiment of the disclosure. The block ring is formed by linking blocks together. Each block ring contains blocks generated by multiple consensus nodes within the same consensus cycle. The multiple consensus nodes have a predetermined order. The device is applied to the master consensus node among the multiple consensus nodes. The block ring processing device 3300 includes:

[0505] The first receiving unit 3310 is used to receive the block headers of the blocks generated by multiple consensus nodes in the current consensus cycle.

[0506] The second receiving unit 3320 is used to receive the first signature information of the block header of the preceding neighbor consensus node from each of the multiple consensus nodes. In a predetermined order, the preceding neighbor consensus node is placed before the signing consensus node. The signing consensus node is the consensus node that generates the first signature information and receives the block header of the preceding neighbor consensus node.

[0507] The first determining unit 3330 is used to determine the order of the blocks generated by the multiple consensus nodes in the current consensus cycle based on the first signature information of each of the multiple consensus nodes.

[0508] The third receiving unit 3340 is used to receive the blocks generated by multiple consensus nodes in the current consensus cycle.

[0509] Integration unit 3350 is used to integrate the generated blocks of multiple consensus nodes into a block ring for the current consensus period based on sorting.

[0510] Recording unit 3360 is used to record the block ring of the current consensus cycle onto the block ring chain.

[0511] Optionally, the block header includes the ring digest value of the previous neighboring block, and the block ring chain processing device 3300 further includes:

[0512] The acquisition unit is used to acquire the previous block ring on the block ring chain. The previous block ring was recorded on the block ring chain in the consensus cycle preceding the current consensus cycle.

[0513] The calculation unit is used to calculate the digest value of the previous block ring, which is then used as the digest value of the previous neighboring block ring.

[0514] Optionally, the block chain processing device 3300 further includes:

[0515] The second determining unit is used to determine other consensus nodes from which the block header received by the signing consensus node in the current consensus cycle comes, as candidate consensus nodes.

[0516] The third determining unit is used to determine the last candidate consensus node that is ranked before the signature consensus node in a predetermined order as the previous neighbor consensus node.

[0517] The signature unit is used to sign the block header of the preceding consensus node using the first private key of the signing consensus node to obtain the first signature information.

[0518] Optionally, the first signature information includes the signed block header, the signature consensus node identifier, and the signature on the block header;

[0519] The first determining unit 3330 is specifically used for:

[0520] From the first signature information, obtain the signed block header and the signature consensus node identifier;

[0521] The generated blocks to which the signature header belongs are arranged before the generated blocks of the signing consensus node corresponding to the signature consensus node identifier, thereby generating the order of the generated blocks of multiple consensus nodes based on their respective first signature information.

[0522] Optionally, the integration unit 3350 is specifically used for:

[0523] For each consensus node, the block generated by the consensus node and the first signature information of the consensus node are combined to form the block information of the consensus node.

[0524] A block ring is obtained by sorting and connecting the block information of multiple consensus nodes.

[0525] Optionally, the integration unit 3350 is also specifically used for:

[0526] Based on the sorted connection of the block information of multiple consensus nodes, the block ring ontology is obtained;

[0527] The block ring ontology is signed using the second private key of the primary consensus node to obtain the ontology signature;

[0528] By concatenating the block ring body and the body signature, a block ring is obtained.

[0529] Optionally, the recording unit 3360 is specifically used for:

[0530] The current consensus cycle's block ring is sent to other consensus nodes among multiple consensus nodes, so that multiple consensus nodes can reach a consensus on the block ring and execute the events in the block ring, and record the block ring on the block ring chain maintained by each of the multiple consensus nodes.

[0531] Optionally, the recording unit 3360 is also specifically used for:

[0532] Obtain the block information of each consensus node from the block ring;

[0533] From the block information, obtain the block generated by the consensus node and the first signature information of the consensus node;

[0534] The generated block is verified using the first signature information;

[0535] Execute multiple events in the generated block.

[0536] Optionally, the recording unit 3360 is also specifically used for:

[0537] Obtain the block ring body and body signature from the block ring;

[0538] Obtain the first public key of the master consensus node;

[0539] The ontology signature is verified based on the block ring ontology and the first public key;

[0540] After successful verification, the block information of each consensus node is obtained from the block ring ontology.

[0541] Optionally, the first signature information includes the signed block header, the signature consensus node identifier, and the signature on the block header;

[0542] Recording unit 3360 is also specifically used for:

[0543] From the first signature information, obtain the signed block header, the signature consensus node identifier, and the signature on the block header;

[0544] Obtain the second public key of the signature consensus node corresponding to the signature consensus node identifier;

[0545] The signature is decrypted using the second public key to obtain the decrypted result.

[0546] Perform a digest operation on the signed block header to obtain the block header digest;

[0547] The generated block is verified by comparing the decrypted result with the block header digest.

[0548] Optionally, the recording unit 3360 is also specifically used for:

[0549] Execute events in the blocks generated by each of the other consensus nodes besides the main consensus node;

[0550] Execute events in the block generation of the master consensus node.

[0551] Optionally, the recording unit 3360 is also specifically used for:

[0552] Select the block to be executed from the blocks generated by each of the other consensus nodes besides the main consensus node;

[0553] Execute events in the block to be executed.

[0554] Optionally, the recording unit 3360 is also specifically used for:

[0555] Starting from the next consensus node in the predetermined order, the generated blocks of each of the other consensus nodes are sequentially used as blocks to be executed, according to the predetermined order.

[0556] Optionally, each consensus node may have its own table of executed events.

[0557] Recording unit 3360 is also specifically used for:

[0558] At the start of the current consensus cycle, clear the table of executed events;

[0559] Retrieve events sequentially from the blocks to be executed;

[0560] If it is determined that the retrieved event is not in the executed events table, execute the event and add the event to the executed events table.

[0561] Optionally, the block chain processing device 3300 further includes:

[0562] The discard unit is used to discard an event if it is determined that the acquired event is in the executed events table.

[0563] Optionally, the executed events table stores the first summary values ​​of the executed events;

[0564] The discard unit is specifically used for:

[0565] Perform a digest operation on the acquired events to obtain a second digest value;

[0566] If the second summary value matches a first summary value in the executed event table, the event obtained is determined to be in the executed event table;

[0567] Discard event.

[0568] Optionally, the executed event table also stores the information of the first event initiator corresponding to the first summary value;

[0569] The discard unit is also specifically used for:

[0570] If the second summary value matches a first summary value in the executed event table, and the second event initiator information of the obtained event matches the first event initiator information corresponding to the first summary value, then the obtained event is determined to be in the executed event table.

[0571] Optionally, the recording unit 3360 is also specifically used for:

[0572] Based on each event in the event group, the event group summary prediction model is used to predict the event group summary.

[0573] Based on the event group summary, determine the execution order of each event group;

[0574] Based on the execution order of event groups, the events in each event group are executed.

[0575] Reference Figure 34 , Figure 34 This is a structural block diagram of a terminal portion of the blockchain processing method according to an embodiment of the present disclosure. The terminal includes: a radio frequency (RF) circuit 3410, a memory 3415, an input unit 3430, a display unit 3440, a sensor 3450, an audio circuit 3460, a wireless fidelity (WiFi) module 3470, a processor 3480, and a power supply 3490, among other components. Those skilled in the art will understand that... Figure 34 The terminal structure shown does not constitute a limitation on mobile phones or computers and may include more or fewer components than shown, or combine certain components, or have different component arrangements.

[0576] The RF circuit 3410 can be used to receive and transmit signals during information transmission or calls. In particular, it receives downlink information from the base station and processes it with the processor 3480; in addition, it transmits uplink data to the base station.

[0577] The memory 3415 can be used to store software programs and modules, and the processor 3480 executes various functional applications and data processing of the content terminal by running the software programs and modules stored in the memory 3415.

[0578] The input unit 3430 can be used to receive input numeric or character information, and to generate key signal inputs related to the settings and function control of the content terminal. Specifically, the input unit 3430 may include a touch panel 3431 and other input devices 3432.

[0579] Display unit 3440 can be used to display input or provided information, as well as various menus of the content terminal. Display unit 3440 may include display panel 3441.

[0580] Audio circuitry 3460, speaker 3461, and microphone 3462 provide an audio interface.

[0581] In this embodiment, the processor 3480 included in the terminal can execute the block ring chain processing method of the previous embodiment.

[0582] Figure 35 This is a partial structural block diagram of a server implementing the blockchain processing method of this disclosure. The server can vary significantly due to different configurations or performance characteristics, and may include one or more Central Processing Units (CPUs) 3522 (e.g., one or more processors) and memory 3532, and one or more storage media 3530 (e.g., one or more mass storage devices) for storing application programs 3542 or data 3544. The memory 3532 and storage media 3530 can be temporary or persistent storage. The program stored in the storage media 3530 may include one or more modules (not shown in the diagram), each module including a series of instruction operations on the server. Furthermore, the CPU 3522 may be configured to communicate with the storage media 3530 and execute the series of instruction operations in the storage media 3530 on the server.

[0583] The server may also include one or more power supplies 3526, one or more wired or wireless network interfaces 3550, one or more input / output interfaces 3558, and / or one or more operating systems 3541, such as Windows Server™, Mac OS X™, Unix™, Linux™, FreeBSD™, etc.

[0584] The central processing unit 3522 in the server can be used to execute the block ring chain processing method of the present disclosure embodiments.

[0585] This disclosure also provides a computer-readable storage medium for storing program code for executing the block chain processing methods of the foregoing embodiments.

[0586] This disclosure also provides a computer program product comprising a computer program. A processor of a computer device reads and executes the computer program, causing the computer device to perform the block chain processing method described above.

[0587] In this application embodiment, the terms "module" or "unit" refer to a computer program or part of a computer program that has a predetermined function and works with other related parts to achieve a predetermined goal, and can be implemented wholly or partially using software, hardware (such as processing circuitry or memory), or a combination thereof. Similarly, a processor (or multiple processors or memory) can be used to implement one or more modules or units. Furthermore, each module or unit can be part of an overall module or unit that includes the functionality of that module or unit.

[0588] The terms “first,” “second,” “third,” “fourth,” etc. (if present) in this disclosure and the foregoing drawings are used to distinguish similar terms and are not necessarily used to describe a particular order or sequence. It should be understood that such use of data can be interchanged where appropriate so that embodiments of this disclosure described herein can be implemented, for example, in orders other than those illustrated or described herein. Furthermore, the terms “comprising” and “including,” and any variations thereof, are intended to cover non-exclusive inclusion; for example, a process, method, system, product, or apparatus that includes a series of steps or units is not necessarily limited to those steps or units explicitly listed, but may include other steps or units not explicitly listed or inherent to such processes, methods, products, or apparatuses.

[0589] It should be understood that in this disclosure, "at least one item" refers to one or more items, and "more than one item" refers to two or more items. "And / or" is used to describe the relationship between related content, indicating that three relationships can exist. For example, "A and / or B" can represent three cases: only A exists, only B exists, and both A and B exist simultaneously, where A and B can be singular or plural. The character " / " generally indicates that the preceding and following related content are in an "or" relationship. "At least one of the following" or similar expressions refer to any combination of these items, including any combination of single or plural items. For example, at least one of a, b, or c can represent: a, b, c, "a and b", "a and c", "b and c", or "a and b and c", where a, b, and c can be single or multiple.

[0590] It should be understood that in the description of the embodiments disclosed herein, "multiple" means two or more, "greater than", "less than", "exceeding" etc. are understood to exclude the number itself, and "above", "below", "within" etc. are understood to include the number itself.

[0591] In the several embodiments provided in this disclosure, it should be understood that the disclosed systems, apparatuses, and methods can be implemented in other ways. For example, the apparatus embodiments described above are merely illustrative; for instance, the division of units is only a logical functional division, and in actual implementation, there may be other division methods. For example, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. Furthermore, the coupling or direct coupling or communication connection shown or discussed may be through some interfaces, indirect coupling or communication connection between apparatuses or units, and may be electrical, mechanical, or other forms.

[0592] The units described as separate components may or may not be physically separate. The components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the units can be selected to achieve the purpose of this embodiment according to actual needs.

[0593] Furthermore, the functional units in the various embodiments of this disclosure can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit. The integrated unit can be implemented in hardware or as a software functional unit.

[0594] If the integrated unit is implemented as a software functional unit and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of this disclosure, in essence, or the part that contributes to the prior art, or all or part of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the steps of the methods of the various embodiments of this disclosure. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, portable hard drives, read-only memory (ROM), random access memory (RAM), magnetic disks, or optical disks.

[0595] It should also be understood that the various implementation methods provided in this disclosure can be combined arbitrarily to achieve different technical effects.

[0596] The above is a detailed description of the embodiments of this disclosure. However, this disclosure is not limited to the above embodiments. Those skilled in the art can make various equivalent modifications or substitutions without departing from the spirit of this disclosure. All such equivalent modifications or substitutions are included within the scope defined by the claims of this disclosure.

Claims

1. A method for processing block chain loops, characterized in that, The block ring chain is composed of linked block rings, each containing blocks generated by multiple consensus nodes within the same consensus cycle. These consensus nodes have a predetermined order, and the method is executed by the master consensus node among them. The method includes: Receive the block headers of the blocks generated by the multiple consensus nodes in the current consensus cycle; The system receives first signature information of the block header of the preceding neighbor consensus node from each of the plurality of consensus nodes, wherein, in the predetermined order, the preceding neighbor consensus node is ranked before the signing consensus node, the signing consensus node is the consensus node that generated the first signature information, and the signing consensus node receives the block header of the preceding neighbor consensus node. Based on the first signature information of each of the plurality of consensus nodes, the order of the generated blocks of each of the plurality of consensus nodes in the current consensus period is determined; Receive the generated blocks from the plurality of consensus nodes during the current consensus period; Based on the sorting, the generated blocks of the multiple consensus nodes are integrated into a block ring for the current consensus period; Record the block ring of the current consensus cycle onto the block ring chain.

2. The method according to claim 1, characterized in that, The block header contains the ring digest value of the previous neighbor block, which is generated in the following way: Obtain the previous block ring on the block ring chain, and the previous block ring is recorded on the block ring chain in the consensus cycle preceding the current consensus cycle; Calculate the digest value of the previous block ring, and use it as the digest value of the previous neighboring block ring.

3. The method according to claim 1, characterized in that, The first signature information is generated by the signature consensus node in the following way: Identify other consensus nodes from which the block header received by the signature consensus node during the current consensus period originates, and designate them as candidate consensus nodes; The last candidate consensus node that is ranked before the signature consensus node in the predetermined order is determined as the previous neighbor consensus node; The first signature information is obtained by signing the block header of the preceding neighbor consensus node with the first private key of the signing consensus node.

4. The method according to claim 1, characterized in that, The first signature information includes the signed block header, the signature consensus node identifier, and the signature on the block header; The step of determining the order of the generated blocks of the plurality of consensus nodes in the current consensus period based on the first signature information of each of the plurality of consensus nodes includes: From the first signature information, obtain the signed block header and the signature consensus node identifier; The generated block to which the block header to be signed belongs is arranged before the generated block of the signing consensus node corresponding to the signing consensus node identifier, thereby generating the order of the generated blocks of the multiple consensus nodes based on the first signature information of each of the multiple consensus nodes.

5. The method according to claim 1, characterized in that, The step of integrating the generated blocks of the multiple consensus nodes into a block ring for the current consensus period based on the sorting includes: For each consensus node, the generated block of the consensus node and the first signature information of the consensus node are combined to form the block information of the consensus node; The block ring is obtained by connecting the block information of the multiple consensus nodes according to the sorting.

6. The method according to claim 5, characterized in that, The step of obtaining the block ring based on the block information of the multiple consensus nodes connected in the ordered manner includes: Based on the block information of the multiple consensus nodes connected in the sorted manner, the block ring ontology is obtained; The block ring ontology is signed using the second private key of the primary consensus node to obtain the ontology signature; The block ring body and the body signature are connected to obtain the block ring.

7. The method according to claim 1, characterized in that, The step of recording the block ring of the current consensus period onto the block ring chain includes: The block ring of the current consensus period is sent to other consensus nodes among the plurality of consensus nodes, so that the plurality of consensus nodes reach a consensus on the block ring and execute the events in the block ring, and record the block ring on the block ring chain maintained by each of the plurality of consensus nodes.

8. The method according to claim 7, characterized in that, The consensus reached on the block ring and the execution of events within the block ring include: Obtain the block information of each of the plurality of consensus nodes from the block ring; From the block information, obtain the generated block of the consensus node and the first signature information of the consensus node; The generated block is verified using the first signature information; Execute multiple events in the generated block.

9. The method according to claim 8, characterized in that, The step of obtaining the block information of each of the plurality of consensus nodes from the block ring includes: Obtain the block ring body and the body signature from the block ring; Obtain the first public key of the master consensus node; The signature of the ontology is verified based on the block ring ontology and the first public key; After successful verification, the block information of each of the multiple consensus nodes is obtained from the block ring ontology.

10. The method according to claim 8, characterized in that, The first signature information includes the signed block header, the signature consensus node identifier, and the signature on the block header; The step of verifying the generated block using the first signature information includes: From the first signature information, obtain the signed block header, the signature consensus node identifier, and the signature on the block header; Obtain the second public key of the signature consensus node corresponding to the signature consensus node identifier; The signature is decrypted using the second public key to obtain the decrypted result; Perform a digest operation on the signed block header to obtain the block header digest; The generated block is verified by comparing the decrypted result with the block header digest.

11. The method according to claim 8, characterized in that, The execution of multiple events in the generated block includes: Execute the events in the generated blocks of each of the other consensus nodes besides the main consensus node; Execute the events in the generated block of the master consensus node.

12. The method according to claim 11, characterized in that, The execution of events in the generated blocks by each of the other consensus nodes besides the main consensus node includes: Select a block to be executed from the generated blocks of each of the other consensus nodes besides the main consensus node; Execute the events in the block to be executed.

13. The method according to claim 12, characterized in that, The step of selecting a block to be executed from the generated blocks of each of the other consensus nodes besides the main consensus node includes: Starting from the next consensus node after the primary consensus node in the predetermined order, the generated blocks of each of the other consensus nodes are sequentially used as the blocks to be executed, according to the predetermined order.

14. The method according to claim 12, characterized in that, Each of the multiple consensus nodes has its own table of executed events; The execution of events in the block to be executed includes: At the start of the current consensus period, the executed event table is cleared; Events are obtained sequentially from the blocks to be executed; If it is determined that the obtained event is not in the executed event table, the event is executed and added to the executed event table.

15. The method according to claim 14, characterized in that, After sequentially retrieving events from the block to be executed, the method further includes: If the event is determined to be in the executed events table, discard the event.

16. The method according to claim 15, characterized in that, The executed events table stores the first summary values ​​of the executed events; If it is determined that the acquired event is in the executed event table, discarding the event includes: Perform a digest operation on the acquired events to obtain a second digest value; If the second summary value matches a first summary value in the executed event table, the obtained event is determined to be in the executed event table; Discard the event.

17. A block chain processing device, characterized in that, The block ring chain is composed of linked block rings, each containing blocks generated by multiple consensus nodes within the same consensus cycle. These multiple consensus nodes have a predetermined order. The device is applied to the master consensus node among these multiple consensus nodes. The device includes: The first receiving unit is used to receive the block headers of the blocks generated by the multiple consensus nodes in the current consensus period. The second receiving unit is configured to receive first signature information of the block header of the preceding neighbor consensus node from each of the plurality of consensus nodes, wherein, in the predetermined order, the preceding neighbor consensus node is ranked before the signing consensus node, the signing consensus node is the consensus node that generates the first signature information, and the signing consensus node receives the block header of the preceding neighbor consensus node. The first determining unit is configured to determine the order of the generated blocks of the plurality of consensus nodes in the current consensus period based on the first signature information of each of the plurality of consensus nodes. The third receiving unit is used to receive the generated blocks of the plurality of consensus nodes in the current consensus period; An integration unit is used to integrate the generated blocks of the multiple consensus nodes into a block ring for the current consensus period based on the sorting. A recording unit is used to record the block ring of the current consensus cycle onto the block ring chain.

18. An electronic device comprising a memory and a processor, wherein the memory stores a computer program, characterized in that, When the processor executes the computer program, it implements the block ring chain processing method according to any one of claims 1 to 16.

19. A computer-readable storage medium storing a computer program, characterized in that, When the computer program is executed by a processor, it implements the block ring chain processing method according to any one of claims 1 to 16.

20. A computer program product comprising a computer program that is read and executed by a processor of a computer device, causing the computer device to perform the block chain processing method according to any one of claims 1 to 16.

Images