Block data processing method and device, electronic equipment and storage medium
A block data processing method with host and shadow nodes in blockchain networks addresses resource inefficiencies by allowing shadow nodes to perform consensus tasks without storing ledger data, enhancing network efficiency.
Patent Information
- Application Number
- CN202310781850.9
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- Filing Date
- 2023-06-28
- Publication Date
- 2024-12-31
Smart Images

Figure CN119227146A_ABST
Abstract
Description
Technical Field
[0001] The present invention relates to the field of computer technology, and in particular to a block data processing method, device, electronic equipment and storage medium. Background Art
[0002] With the continuous development of computer networks, blockchain-related technologies are becoming more mature. Blockchain is a new application model of computer technologies such as distributed data storage, peer-to-peer transmission, consensus mechanism, and encryption algorithm. Considering that the information stored on the blockchain cannot be forged or tampered with, more and more companies will build business nodes on the blockchain to store business data on the corresponding business nodes and realize the management of business data.
[0003] However, for some business systems, due to the different importance of the nature of the business, different business systems have different weights in the same blockchain, that is, the voting value in the blockchain is higher. At this time, for business systems with higher weights, it is necessary to deploy a corresponding number of consensus nodes on the blockchain. For example, assuming that the entire blockchain network includes three business systems as participants, if participant A wants to have a higher voice, then it needs to deploy more consensus nodes. For example: for participants A, B, and C, when A needs a higher voice, it means that 2 consensus nodes can be deployed for participant A, and 1 consensus node can be deployed for B and C respectively. At this time, participant A has 2 consensus nodes and has a higher voice for voting transactions initiated in the blockchain.
[0004] However, since each consensus node needs to save the ledger, for participants who need a higher voice, more consensus nodes mean that more resources will be needed, such as CPU resources and storage resources, resulting in greater resource consumption. Summary of the invention
[0005] In view of this, an embodiment of the present invention provides a block data processing method, device, electronic device and storage medium to reduce the resource usage of high-weight business objects and improve the operating efficiency of the blockchain network.
[0006] On the one hand, an embodiment of the present invention provides a block data processing method, including but not limited to the following steps:
[0007] According to the voting right requirements of the target business object, a target business node group is constructed; wherein the target business node group includes a host node and at least one shadow node;
[0008] The host node performs block data processing based on the stored block ledger data;
[0009] The block data processing performed by the shadow node remains consistent with the block data processing of the host node, and the shadow node does not save the block ledger data of the block data processing.
[0010] On the other hand, an embodiment of the present invention provides a block data processing method of a target blockchain network, wherein the target blockchain network includes multiple nodes, including:
[0011] Determine a target business node from multiple nodes of the target blockchain network;
[0012] Calculate the number of shadow nodes to be configured for the target business node based on the voting weight that the target business node expects to achieve and the number of nodes in the target blockchain network;
[0013] Among them, the block data processing performed by the shadow node remains consistent with the block data processing of the target business node, and the shadow node does not save the block ledger data of the block data processing.
[0014] On the other hand, an embodiment of the present invention provides a block data processing device, including:
[0015] The first module is used to construct a target business node group according to the voting right requirements of the target business object; wherein the target business node group includes a host node and at least one shadow node;
[0016] The host node performs block data processing based on the stored block ledger data;
[0017] The block data processing performed by the shadow node remains consistent with the block data processing of the host node, and the shadow node does not save the block ledger data of the block data processing.
[0018] Optionally, the process of executing block data processing by the shadow node of the block data processing device in the embodiment of the present invention includes:
[0019] The second module is used to respond to the proposal information sent by the host node, and the shadow node extracts the block information from the proposal information for proposal processing and generates a proposal notification; the proposal notification is used to trigger each node to perform block locking processing;
[0020] The third module is used to respond to the block lock voting information sent by the host node, and the shadow node extracts the first voting content from the block lock voting information to perform block lock processing on the proposal notification;
[0021] The fourth module is used to respond to the block submission voting information sent by the host node, and the shadow node extracts the second voting content from the block submission voting information to perform block submission processing to complete the consensus on the block information; wherein the second voting content includes the results of the block locking processing of each node.
[0022] The first module includes:
[0023] The first unit is used to configure one or more shadow nodes for the host node of the target business object according to the voting right requirements of the target business object;
[0024] The second unit is used to perform initial information configuration on each shadow node, and combine the configured shadow node with the host node to obtain a target business node group.
[0025] Optionally, in the block data processing device in the embodiment of the present invention, the second unit includes:
[0026] A first subunit is used to configure node mapping information between shadow nodes and host nodes, where the node mapping information represents the association relationship between each shadow node and the corresponding host node;
[0027] The second subunit is used to configure the default operation information of the shadow node, and the default operation information is used to indicate the processing action to be taken by the shadow node when it does not receive the instruction sent by the host node;
[0028] The third subunit is used to configure the response timeout information of the shadow node.
[0029] Optionally, in the block data processing device in the embodiment of the present invention, the second module includes:
[0030] The third unit is used to receive the proposal information of the host node in real time within a preset waiting time range when the shadow node becomes a proposal node;
[0031] The fourth unit is used to extract block information from the proposal information when receiving the proposal information of the host node, synthesize the block information to obtain the secondary proposal of the shadow node, and generate a proposal notification;
[0032] The fifth unit is used to broadcast the proposal notification to each node.
[0033] Optionally, the block data processing device in the embodiment of the present invention further includes:
[0034] The fifth module is used to generate a default proposal notification according to the default configuration information of the shadow node when no proposal information of the host node is received within a preset waiting time range, and broadcast the proposal notification to each node.
[0035] Optionally, in the block data processing device in the embodiment of the present invention, the third module includes:
[0036] The sixth unit is used to receive the block lock voting information of the host node in real time within a preset waiting time range after broadcasting the proposal notification to each node when the shadow node is a proposal node;
[0037] The seventh unit is used for extracting the first voting content from the block locking voting information when receiving the block locking voting information of the host node, synthesizing the first voting content to obtain the first voting information of the shadow node, and generating a first voting notification;
[0038] The eighth unit is used to broadcast the first voting notification to each node.
[0039] Optionally, the block data processing device in the embodiment of the present invention further includes:
[0040] The sixth module is used to generate a default second voting notification according to the default configuration information of the shadow node when the block lock voting information of the host node is not received within a preset waiting time range, and broadcast the second voting notification to each node.
[0041] Optionally, in the block data processing device in the embodiment of the present invention, the third module further includes:
[0042] Unit 9 is used when the shadow node is not a proposal node and waits for proposal notifications from other nodes within a preset time range;
[0043] The tenth unit is used to generate a default third voting notification according to the default configuration information of the shadow node when the proposal notification received by the shadow node comes from the host node, and broadcast the third voting notification to each node.
[0044] Optionally, in the block data processing device in the embodiment of the present invention, the third module further includes:
[0045] Unit 11 is used to receive the block lock voting information of the host node in real time within a preset waiting time range when the proposal notification received by the shadow node does not come from the host node;
[0046] The twelfth unit is used to generate a fourth voting notification and broadcast the fourth voting notification to each node when receiving the block locking voting information of the host node within a preset waiting time.
[0047] Optionally, in the block data processing device in the embodiment of the present invention, the fourth module includes:
[0048] Unit 13 is used to obtain the block locking voting information of other nodes;
[0049] The fourteenth unit is used to receive the block submission voting information of the host node in real time within a preset waiting time range;
[0050] The fifteenth unit is used to extract the second voting content from the block submission voting information when receiving the block submission voting information of the host node within a preset waiting time range, and synthesize the second voting content to obtain the second voting information of the shadow node, and then generate a fifth voting notification;
[0051] The sixteenth unit is used to broadcast the fifth voting notification to each node.
[0052] Optionally, the block data processing device in the embodiment of the present invention further includes:
[0053] The seventh module is used to generate a default sixth voting notification according to the default configuration information of the shadow node when the block submission voting information of the host node is not received within the preset waiting time range, and broadcast the sixth voting notification to each node.
[0054] On the other hand, an embodiment of the present invention further provides an electronic device, including a processor and a memory;
[0055] The memory is used to store programs;
[0056] The processor executes the program to implement the above block data processing method.
[0057] On the other hand, an embodiment of the present invention further provides a computer-readable storage medium, wherein the storage medium stores a program, and the program is executed by a processor to implement the above block data processing method.
[0058] On the other hand, an embodiment of the present invention further provides a computer program product, including a computer program, which implements the above block data processing method when executed by a processor.
[0059] The embodiment of the present invention first constructs a target business node group according to the voting rights requirements of the target business object, wherein the target business node group includes a host node and at least one shadow node; the host node of the embodiment of the present invention performs block data processing according to the stored block ledger data, the block data processing performed by the shadow node maintains consistency with the block data processing of the host node, the shadow node does not save the block ledger data of the block data processing, the shadow node does not need to store the relevant ledger data of the blockchain network, and can execute the processing behavior consistent with the host node or the default, which reduces the resource occupancy of business objects with a high weight ratio and improves the operation efficiency of the blockchain network. The embodiment of the present invention can meet the voting rights requirements of any business object and improve the operation efficiency of the blockchain network in a low resource occupancy manner. BRIEF DESCRIPTION OF THE DRAWINGS
[0060] In order to more clearly illustrate the technical solutions in the embodiments of the present application, the drawings required for use in the description of the embodiments will be briefly introduced below. Obviously, the drawings described below are only some embodiments of the present application. For ordinary technicians in this field, other drawings can be obtained based on these drawings without creative work.
[0061] Figure 1 It is a schematic diagram of the structural deployment of a related implementation environment in the related technology;
[0062] Figure 2 is a schematic diagram of an implementation environment for performing data processing in an embodiment of the present invention;
[0063] Figure 3 It is a schematic diagram of the deployment of an implementation environment structure provided in an embodiment of the present invention;
[0064] Figure 4 It is a schematic diagram of a business system application provided in an embodiment of the present invention;
[0065] Figure 5 It is a schematic diagram of the steps of a block data processing method provided in an embodiment of the present invention;
[0066] Figure 6 is a schematic diagram of the shadow node configuration information structure provided in an embodiment of the present invention;
[0067] Figure 7 is a diagram showing an example of configuration of shadow node configuration information provided in an embodiment of the present invention;
[0068] Figure 8 It is a schematic diagram of the process of the shadow node in the proposal stage provided in an embodiment of the present invention;
[0069] Fig. 9 is a schematic diagram of the process of the host node in the proposal stage provided in an embodiment of the present invention;
[0070] Fig.10 It is a schematic diagram of the consensus process when the host node provided in an embodiment of the present invention is a proposal node;
[0071] Fig.11 It is a schematic diagram of the process of the shadow node in the pre-voting stage provided in an embodiment of the present invention;
[0072] Fig.12 It is a schematic diagram of the process of the shadow node in the pre-submission stage provided in an embodiment of the present invention;
[0073] Fig.13 It is a schematic diagram of the overall consensus processing flow of the shadow node provided in an embodiment of the present invention;
[0074] Fig.14 A modular schematic diagram of a block data processing device provided in an embodiment of the present invention;
[0075] Fig.15 The figure is a schematic diagram of the structure of an electronic device provided in an embodiment of the present invention. DETAILED DESCRIPTION
[0076] In order to make the purpose, technical solution and advantages of the present application more clearly understood, the present application is further described in detail below in conjunction with the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are only used to explain the present application and are not used to limit the present application.
[0077] In the following description, reference is made to “some embodiments”, which describe a subset of all possible embodiments, but it will be understood that “some embodiments” may be the same subset or different subsets of all possible embodiments and may be combined with each other without conflict.
[0078] Unless otherwise defined, all technical and scientific terms used herein have the same meaning as those commonly understood by those skilled in the art to which the present invention belongs. The terms used herein are only for the purpose of describing the embodiments of the present invention and are not intended to limit the present invention.
[0079] Before further describing the embodiments of the present invention in detail, the nouns and terms involved in the embodiments of the present invention are described. The nouns and terms involved in the embodiments of the present invention are subject to the following interpretations.
[0080] Blockchain is a new application model of computer technologies such as distributed data storage, peer-to-peer transmission, consensus mechanism, encryption algorithm, etc. Blockchain is essentially a decentralized database, a string of data blocks generated by cryptographic methods. Each data block contains a batch of network transaction information, which is used to verify the validity of its information (anti-counterfeiting) and generate the next block. Blockchain can include the underlying blockchain platform, platform product service layer and application service layer. Blockchain can include public chain, alliance chain and private chain. Among them, public chain refers to a blockchain that anyone can enter the blockchain network at any time to read data, send data or compete for accounting; alliance chain refers to a blockchain jointly managed by several organizations or institutions; private chain refers to a blockchain with certain centralized control. The write right of the private chain account book is controlled by a certain organization or institution, and the access and use of data are strictly managed by permissions.
[0081] Block: A data packet that carries transaction data (i.e., transaction business) on a blockchain network. It is a data structure marked with a timestamp and a hash value of the previous block. The block is verified by the network's consensus mechanism and the transactions in the block are confirmed.
[0082] Block height: used to identify the number of blocks connected to the blockchain, and can be used to determine the position of a block in the blockchain.
[0083] On this basis, the characteristic concepts that may be involved in the invention are explained:
[0084] Consensus algorithm: It is a specification followed by all blockchain nodes. It is a series of processes and rules generated to implement distributed consistency protocols. When nodes distributed in different regions negotiate and interact according to this set of rules, they can always reach a consistent decision on one or some issues, thereby achieving consistency among different nodes in the distributed system.
[0085] TBFT algorithm: Tendermint BFT consensus algorithm, which is a Byzantine fault-tolerant consensus algorithm. The nodes it supports must meet the 3f+1 rule, where f represents the number of malicious nodes allowed in the entire network. When the number of malicious nodes exceeds the total number, the security of the entire network will be reduced or even unavailable.
[0086] Consensus node: also known as verification node, is a node in the blockchain that performs consensus processing on blocks generated by the leader node. It refers to the node responsible for verifying transactions and generating new blocks in the blockchain network. They need to reach a consistent decision through a consensus algorithm.
[0087] Proposal: A request or proposal sent by the host node to the verification node to process a consensus on a block.
[0088] Based on the above theoretical foundation, as well as the research and progress of blockchain technology, blockchain technology has been studied and applied in many fields, such as common digital assets, financial asset transaction settlement, evidence storage and anti-counterfeiting, data services, etc. It is believed that with the development of technology, blockchain technology will be applied in more fields and play an increasingly important role.
[0089] With the continuous development of computer networks, blockchain-related technologies are becoming more mature. Among them, blockchain is a new application model of computer technologies such as distributed data storage, peer-to-peer transmission, consensus mechanism, and encryption algorithm. Considering that the information stored on the blockchain cannot be forged or tampered with, more and more companies will build business nodes on the blockchain to store business data on the corresponding business nodes to manage business data. However, for some business systems, due to the different importance of the nature of the business, different business systems have different weights in the same blockchain, that is, the voting value in the blockchain is higher. At this time, for business systems with higher weights, it is necessary to deploy a corresponding number of consensus nodes on the blockchain. For example, refer to Figure 1 Assume that the entire blockchain network includes three business systems as participants. If participant A wants to have a higher voice, it needs to deploy more consensus nodes. For example, for participants A, B, and C, when A needs a higher voice, it means that 2 consensus nodes can be deployed for participant A, and 1 consensus node can be deployed for B and C respectively. At this time, participant A has 2 consensus nodes and has a higher voice in voting transactions initiated in the blockchain.
[0090] However, since each consensus node needs to save the ledger, for participants who need a higher voice, more consensus nodes mean that more resources will be needed, such as CPU resources and storage resources, resulting in greater resource consumption.
[0091] To this end, the solution provided by the embodiment of the present invention involves technologies such as blockchain, and the shadow node in the target business node group executes proposal processing, block locking processing or block submission processing according to the instructions of the host node, and the shadow node does not need to store the relevant ledger data of the blockchain network. At the same time, the shadow node can execute the same or default processing behavior as the host node, thereby effectively reducing the resource usage of business objects with high weight ratio and improving the operation efficiency of the blockchain network.
[0092] It is understandable that the block data processing method provided in the embodiment of the present invention can be applied to any computer device with data processing computing capabilities, and this computer device can be various types of terminals or servers, and the terminal and the server are connected through a communication network. The server is a node server in the blockchain network, and multiple servers constitute the blockchain network. When the computer device in the embodiment of the present invention is a server, the server is an independent physical server, or a server cluster or distributed system composed of multiple physical servers, or a cloud server that provides basic cloud computing services such as cloud services, cloud databases, cloud computing, cloud functions, cloud storage, network services, cloud communications, middleware services, domain name services, security services, CDN (Content Delivery Network, content distribution network), and big data and artificial intelligence platforms. Optionally, the terminal is a smart phone, a tablet computer, a laptop computer, a desktop computer, etc., but is not limited to this.
[0093] It should be further explained that the terminals involved in the embodiments of the present invention include but are not limited to smart phones, computers, intelligent voice interaction devices, smart home appliances, vehicle terminals, aircraft, etc. The embodiments of the present invention can be applied to various scenarios, including but not limited to cloud technology, artificial intelligence, smart transportation, assisted driving, etc.
[0094] In some possible implementations, a computer program capable of implementing the block data processing method provided in an embodiment of the present invention may be deployed and executed on a computer device, or on multiple computer devices located at one location, or on multiple computer devices distributed at multiple locations and interconnected through a communication network. Multiple computer devices distributed at multiple locations and interconnected through a communication network may constitute a blockchain system.
[0095] Based on the fact that multiple computer devices can form a blockchain system, the computer device that implements the block data processing method in the embodiment of the present invention can be a node in the blockchain system. The node stores a computer program that can execute the block data processing method. The computer program first constructs a target business node group including a host node and at least one shadow node according to the voting rights requirements of the target business object, so that the shadow node performs proposal processing, block locking processing or block submission processing according to the instructions of the host node. At the same time, in the embodiment of the present invention, the shadow node does not store the relevant account book data of the blockchain network, but only needs to execute the processing behavior consistent with the host node or the default, thereby reducing the resource occupation of the business objects with high weight ratio and improving the operation efficiency of the blockchain network.
[0096] like Figure 2 FIG. 1 is a schematic diagram of an implementation environment provided by an embodiment of the present invention. Figure 2, the implementation environment includes multiple service nodes 101, which refer to various terminals or servers in the data processing system 100, which can be computers, mobile phones, tablet computers, other terminals, background servers of the program logic, or cloud servers that provide cloud computing and cloud storage services. When performing normal work, each service node 101 can receive input information and maintain the shared data in the data processing system 100 based on the received input information. In order to ensure the information intercommunication within the data processing system 100, there can be an information connection between each node in the data processing system 100, and the nodes can transmit information through the above information connection. For example, when any node in the data processing system 100 receives input information, other nodes in the data processing system 100 obtain the input information according to the consensus algorithm, and store the input information as data in the shared data, so that the data stored on all nodes in the data processing system 100 are consistent. Among them, the relevant service node 101 can construct a target business node group including a host node and at least one shadow node according to the voting rights requirements of the target business object. The constructed shadow node can be directly applied to downstream tasks for related block consensus operations (including but not limited to proposal processing, block locking processing or block submission processing, etc.).
[0097] Exemplarily, the service node 101 first constructs a target business node group according to the voting rights requirements of the target business object, wherein the target business node group includes a host node and at least one shadow node. Then, the shadow node can perform the following processing: a. In response to the proposal information issued by the host node, extract the block information from the proposal information for proposal processing and generate a proposal notification; b. In response to the block lock voting information issued by the host node, extract the first voting content from the block lock voting information to perform block lock processing on the proposal notification; c. In response to the block submission voting information issued by the host node, extract the second voting content from the block submission voting information for block submission processing and complete the consensus on the block information; so far, the shadow node in the target business node group constructed by the embodiment of the present invention can realize the same proposal or consensus function as an ordinary node without occupying the book storage resources, can meet the voting rights requirements of any business object, and improve the operation efficiency of the blockchain network in a low resource occupancy manner.
[0098] The block data processing method can be applied in various scenarios.
[0099] For example, in the scenario where the target business object conducts consensus voting: after obtaining the authorization of the target object, a target business node group is constructed in the corresponding service node 101 according to the voting rights requirements of the target business object. Accordingly, the target business node group includes a host node and at least one shadow node. Among them, the number of shadow nodes is set according to the voting rights requirements of the target business object. The shadow nodes in the target business node group can perform proposal processing, block locking processing or block submission processing according to the instructions of the host node, and the shadow nodes do not store the relevant account book data of the blockchain network. They only need to execute the processing behavior consistent with the host node or the default processing behavior, so that the shadow node can maintain the same processing behavior as the host node, increase the weight of the host node vote, and meet the voting rights requirements of the target business object. At the same time, the shadow nodes occupy lower resources, which effectively improves the operating efficiency of the blockchain network. It can be understood that the above application scenarios are only examples. In actual applications, in addition to using the server to execute the above data processing process, other devices with data processing capabilities, such as terminals, can also be used to construct a target business node group and execute related business processing processes; in addition, other devices other than terminal devices can also be used to carry the constructed target business node group. No limitation is made to the application scenario of the block data processing method provided in the embodiment of the present invention.
[0100] exist Figure 2 Based on the implementation environment shown in FIG. 1 , an embodiment of the present invention provides an application scenario of consensus node weight allocation. In this scenario, there is an information connection between service nodes, and information can be transmitted between service nodes through the above information connection. Service nodes can target applications by building a target business node group to increase their weight ratio in the node network. For example, referring to Figure 3 In a four-node network, according to the voting rights requirements of the target business object, the weight ratio of the corresponding service node needs to be 50%, then a target business node group including a host node (node 1) and a shadow node (node 2) is constructed to achieve weight distribution of consensus nodes, and the shadow node does not store the relevant ledger data of the blockchain network, but only executes the same or default processing behavior as the host node, that is, node 2 does not have an actual ledger, but has voting rights, and can thus meet the voting rights requirements of any business object, and can reduce the resource usage of business objects with high weight ratios, thereby improving the operating efficiency of the blockchain network. Exemplarily, the target application can be an application platform for resource allocation, or it can be a web link, applet or application plug-in with business functions such as transaction validity verification or shared status update set in multimedia applications (such as film and television applications, short video applications or music applications, etc.), social applications, game applications and navigation applications. For example, in an actual business system, its deployment may be as follows: Figure 4 As shown, the real node in the figure can be used as the host node of the shadow node, that is, the host node.
[0101] It should be noted that in each specific implementation of the present invention, when it comes to obtaining the feature data, behavior data, historical data, location information and other data related to the identity or characteristics of the object, the permission or authorization of the object will be obtained first, and the collection, use and processing of these data will comply with relevant laws, regulations and standards. In addition, when the embodiment of the present invention needs to obtain the sensitive personal information of the object, it will obtain the separate permission or consent of the object through a pop-up window or jump to a confirmation page, and after clearly obtaining the separate permission or consent of the object, it will obtain the necessary object-related data for the normal operation of the embodiment of the present invention.
[0102] like Figure 5 FIG. 1 is a flowchart of a block data processing method provided by an embodiment of the present invention. The execution subject of the block data processing method can be any of the aforementioned computer devices. Figure 5 , the method comprises the following steps:
[0103] S210: Construct a target business node group according to the voting rights requirements of the target business object. The target business node group includes a host node and at least one shadow node. The host node performs block data processing according to the stored block ledger data; the block data processing performed by the shadow node is consistent with the block data processing of the host node, and the shadow node does not save the block ledger data of the block data processing.
[0104] In an embodiment of the present invention, the target business object refers to a participant or organization in a certain business application, for example, an entity such as an enterprise, a related institution, or a group that participates in a blockchain business network. In an embodiment of the present invention, voting rights, i.e., voting weights, refer to the authority that each node possesses during the voting process. Accordingly, in an embodiment of the present invention, the voting rights requirement refers to the expected authority of the node corresponding to the corresponding target object, i.e., the voting weight value that the node needs to possess. It is easy to understand that in an embodiment of the present invention, the shadow node only performs relevant consensus business processing according to the instructions of the host node, such as proposal processing, block locking processing, or block submission processing, so that the shadow node can maintain the same processing behavior as the host node, improve the weight of the host node vote, meet the voting rights requirements of the target business object, and the shadow node does not store the relevant account book data in the blockchain network, which can effectively reduce the resource occupation of the shadow node and improve the operation efficiency of the blockchain network. Specifically, the target business node group constructed according to the voting rights requirements of the target business object in an embodiment of the present invention includes a host node and at least one shadow node. Among them, the number of shadow nodes in the target business node in an embodiment of the present invention can be specifically adjusted according to the voting rights requirements. Exemplarily, taking a network security application scenario as an example, an embodiment of the present invention first constructs a corresponding target business node group according to the voting rights requirements of each network security node. For example, a network security node with a higher credibility has a higher weight in the process of network security verification, so that its voting results have a greater influence, thereby improving the security of the network. Therefore, an embodiment of the present invention determines the number of shadow nodes included in the corresponding target business node group according to the voting rights requirements of the relevant network security nodes, thereby constructing a target business node group that meets the voting rights requirements of the network security nodes. Accordingly, in an embodiment of the present invention, the shadow node performs relevant business processing according to the instructions of the host node to maintain consistency with the processing behavior of the host node, thereby increasing the voting weight of the host node, that is, the voting influence of the corresponding network security node is increased.
[0105] S220: In response to the proposal information sent by the host node, the shadow node extracts the block information from the proposal information for proposal processing and generates a proposal notification. The proposal notification is used to trigger each node to perform block locking processing.
[0106] In the embodiment of the present invention, proposal information refers to the content proposed by the relevant nodes for all nodes to reach a consensus, waiting for the relevant information for each node to reach a consensus. In the embodiment of the present invention, the proposal information of the shadow node in the target business node group is provided by the host node, that is, before the shadow node initiates the proposal, it first obtains the corresponding proposal information from the host node to maintain consistency with the processing behavior of the host node. It can be understood that the shadow node can receive the proposal information sent by the host node in real time within the preset waiting time range. This proposal information can directly issue instructions to the shadow node, requiring the shadow node to make corresponding proposal processing. In other words, the proposal processing of the shadow node can be consistent with the processing behavior of the host node. Moreover, when the shadow node makes the corresponding proposal processing, it does not need to perform corresponding calculations based on the block ledger data stored in its own node like other ordinary nodes to obtain the operation results of the proposal processing. Therefore, the shadow node of the embodiment of the present invention can help the host node improve the voting weight.
[0107] In the embodiment of the present invention, block information refers to all transaction records, block headers and other relevant information contained in the block. When the relevant node proposes a new block, other nodes need to verify whether it is legal according to the block information, and vote to decide whether to accept the block. In the embodiment of the present invention, a proposal refers to the process in which the relevant consensus node proposes a proposal and notifies other nodes to discuss and vote in the blockchain network. Correspondingly, a proposal notification refers to the notification information that the relevant consensus node proposes a new rule, protocol or improvement plan, notifies other nodes to discuss and vote to decide whether to adopt the proposal. In the embodiment of the present invention, the shadow node extracts the corresponding block information from the proposal information sent by the host node for proposal processing to generate relevant proposal notifications and send them to each node, thereby triggering each node to perform block locking processing. Among them, block locking refers to a certain height and number of rounds. After a node receives a pre-voting set that exceeds a certain proportion of the total number of nodes for a block (for example, a pre-voting set that exceeds 2 / 3 of the total number of nodes), the node locks the block of this height and this round, that is, by locking the block to indicate the recognition of a certain block. Exemplarily, taking a digital financial asset transaction validity verification scenario as an example, when the target object initiates a digital financial asset transaction, it is necessary to verify the validity of a certain digital financial asset transaction. The embodiment of the present invention first sends proposal information to the corresponding shadow node through the host node of the corresponding target business node group. Then, the corresponding shadow node responds to the proposal information, extracts relevant block information from it, and performs relevant proposal processing to obtain a proposal notification. Then, the shadow node sends the generated proposal notification to each node, so that each node votes on the digital financial asset transaction to determine whether it is legal and valid, that is, triggers each node to perform block locking processing.
[0108] S230: In response to the block lock voting information sent by the host node, the shadow node extracts the first voting content from the block lock voting information and performs block lock processing on the proposal notification.
[0109] The block lock voting information in the embodiment of the present invention refers to the information that the host node votes on the lock status of a block in the blockchain network. Correspondingly, the lock status generally refers to whether the block has been confirmed as valid by other nodes and can no longer be modified or deleted. The first voting content in the embodiment of the present invention refers to the block lock status information executed on the relevant block extracted from the block lock voting information sent by the host node, such as confirming that the node is valid or invalid. Exemplarily, taking a blockchain election application scenario as an example, in the blockchain voting and election process, different voting weights need to be assigned to different voters to ensure the fairness and effectiveness of the voting. For example, voting weights are assigned according to the identities and rights of different target objects to ensure the fairness and transparency of the election. Therefore, the embodiment of the present invention first constructs a target business node group according to the voting rights requirements of the corresponding election voting objects. Then, when the target business node group receives a proposal notification initiated by other nodes, the host node in the target business node group sends a block lock voting information to the shadow node, and the shadow node extracts the voting information for a certain elected object based on the block lock voting information, that is, the first voting content, and then performs corresponding block lock processing on the received proposal notification according to the first voting content, so that the processing behavior of the shadow node is consistent with that of the host node, thereby increasing the voting weight of the host node, that is, the voting influence of the corresponding election voting object is increased.
[0110] S240: In response to the block submission voting information sent by the host node, the shadow node extracts the second voting content from the block submission voting information to perform block submission processing and complete the consensus on the block information. The second voting content includes the results of the block locking processing of each node.
[0111] In the embodiment of the present invention, the block submission voting information refers to the voting information submitted to the block after there is a locked block in the relevant node. Among them, in the blockchain, in order to ensure the validity and consistency of each block, the consensus node needs to vote on the locking status of a block to determine whether the block can be confirmed as a valid block. Accordingly, the voting information of the consensus node will be recorded on the blockchain so that other nodes can verify the validity and consistency of the block. In the embodiment of the present invention, the second voting content includes the results of the block locking process of each node. It is easy to understand that the block voting information submitted by the shadow node in the embodiment of the present invention is extracted from the block voting information issued by the host node, and the consensus on the situation information is completed according to the block locking process results of each node obtained by the extraction, so that the voting behavior of the shadow node is consistent with the host node. Exemplarily, taking a blockchain shared state application scenario as an example, when the protocol or rules of the relevant blockchain change, the node can decide whether to accept these changes by voting and update the status of the blockchain. When the relevant target business object receives a protocol modification proposal from a certain node, the target business object sends a block submission voting information to the shadow node through the host node in the target business node group to instruct the shadow node to perform the relevant block voting process. In the embodiment of the present invention, the block voting information of the host node is obtained from the result of the block locking process of each node. Accordingly, in the embodiment of the present invention, the shadow node extracts the block locking result of each node based on the received block voting information to perform block submission processing, thereby maintaining the consistency of the processing behavior of the shadow node and the host node on the relevant proposals and completing the consensus on the block information.
[0112] In order to effectively improve the voting weight of the target business object and meet the voting right requirements of any business object, in some feasible embodiments, the step of constructing the target business node group according to the voting right requirements of the target business object may include but is not limited to steps S310 to S320:
[0113] S310: configuring one or more shadow nodes for the host node of the target business object according to the voting right requirement of the target business object.
[0114] In the embodiment of the present invention, the host node is a real node, that is, the host node of the shadow node, and the host node will store the relevant account book data in the blockchain network. Correspondingly, in the embodiment of the present invention, the shadow node does not have an actual account book, that is, the shadow node will not store the relevant account book data in the blockchain network, but the shadow node has the same voting rights as the ordinary node, that is, because the shadow node has voting rights, other nodes can receive the voting information sent by the shadow node, so other nodes cannot perceive that the node is a shadow node, and do not know that there is no block account book data stored in the shadow node. The embodiment of the present invention analyzes the voting requirements of the target business object and configures one or more shadow nodes for the host node of the target business object, so as to meet the voting rights requirements of any business object. Exemplarily, taking an application scenario consisting of four target business objects as an example, each target business object corresponds to a consensus node, so the voting weight of each target business object node is 25%. When one of the target business objects A needs to reach a voting weight of 40%, the embodiment of the present invention configures a shadow node for the node corresponding to the target business object, that is, the host node, according to the voting rights requirements of the target business object, that is, the voting weight accounts for 40%. It is easy to understand that after configuring a shadow node for the host node of the target business object, there are five nodes in the network, and the nodes of other target business objects cannot perceive that the configured node is a shadow node. The shadow node also has voting rights, and the processing behavior of the shadow node is consistent with that of the host node, so that the voting weight of the target business object A can be increased to 40%. Accordingly, the embodiment of the present invention can effectively improve the voting weight of the target business object by configuring a corresponding number of shadow nodes for host nodes with different voting rights requirements, thereby meeting the voting rights requirements of any business object.
[0115] S320: Perform initial information configuration on each shadow node, and combine the configured shadow nodes with the host node to obtain a target service node group.
[0116] In the embodiment of the present invention, the initial information configuration refers to the relevant node configuration information of the shadow node, such as the identity, network address, security settings and other configuration information of the shadow node. After configuring the corresponding number of shadow nodes for the host node of the target business object according to the voting rights requirements of the target business object, the embodiment of the present invention performs initialization information configuration on each shadow node, and then combines the configured shadow node with the host node to obtain the target business node group. For example, when two shadow nodes are configured for the corresponding host node according to the voting rights requirements of the target business object. Then, the embodiment of the present invention first initializes the two shadow nodes respectively, that is, performs initial information configuration, such as relevant identity, consensus algorithm parameters and network address and other relevant node information parameters. After completing the relevant initialization information configuration, the shadow node is equivalent to an ordinary node to the outside, except that the corresponding host node can perceive that it is a shadow node, and other nodes recognize it as a normal node. Then, the embodiment of the present invention combines the two configured shadow nodes with the corresponding host node, thereby constructing a target business node combination that meets the voting rights requirements of the relevant target business object.
[0117] In order to make the shadow node consistent with the processing behavior of the host node and to perform related processing behaviors, in some feasible embodiments, the step of performing initial information configuration on each shadow node may include but is not limited to steps S410 to S430:
[0118] S410: Configuring node mapping information between shadow nodes and host nodes, where the node mapping information represents an association relationship between each shadow node and a corresponding host node.
[0119] In the embodiment of the present invention, the node mapping information refers to the mapping information between the shadow node and its corresponding host node, that is, the real node information mapped by the shadow node. In the embodiment of the present invention, the association relationship refers to the correspondence between the shadow node and the host node. Among them, the mapping node information in the embodiment of the present invention represents the association relationship between each shadow node and its corresponding host node. The embodiment of the present invention configures the node mapping information between the shadow node and the host node, thereby constructing the correspondence between the host node and the shadow node, so that the shadow node can receive the instruction of the host node and maintain the consistency of the processing behavior with the host node. For example, Figure 6 and Figure 7 As shown, after a corresponding number of shadow nodes are configured for the host node of the target business object according to the voting rights requirements of the target business object, an embodiment of the present invention configures node mapping information for each shadow node to associate with the corresponding host node, so that the shadow node can perform related processing behaviors according to the instructions of the host node.
[0120] S420: Configuring default operation information of the shadow node, where the default operation information is used to indicate the processing action to be taken by the shadow node when the shadow node does not receive an instruction from the host node.
[0121] In the embodiment of the present invention, the default operation information refers to the relevant processing action information executed when the shadow node does not receive the instruction sent by its corresponding host node. It is easy to understand that due to data transmission errors and other reasons, in some cases the shadow node may not receive the instruction of the host node, or the host node fails to send relevant instructions to the shadow node in time. At this time, the shadow node needs to perform the relevant default operation to complete the node consensus process. Specifically, Figure 6 and Figure 7 As shown, the default operation information configured in the embodiment of the present invention includes the default content of the proposal, the default content of the prevote, and the default content of the precommit. It should be noted that the default operation information mentioned in the embodiment of the present invention can be adaptively configured according to the needs of the host node. For example, the prevoting information issued by the host node can be set to default approval, and the prevoting information issued by the non-host node can be set to default disapproval. The embodiment of the present invention is not limited here. Exemplarily, in a resource allocation application scenario, the result of the node voting can affect the allocation of assets or rewards. Therefore, the consensus node voting weight allocation can also be used to determine the resource allocation method to ensure that the nodes participating in the consensus receive appropriate returns according to their contributions or benefits. Accordingly, after configuring the corresponding number of shadow nodes for the host node of the target business object according to the voting rights requirements of the target business object, the embodiment of the present invention configures the corresponding default operation information for each shadow node to alleviate the problem that the shadow node cannot execute the relevant node consensus processing when the instruction issued by the host node is not received. The embodiment of the present invention configures corresponding default contents of proposal, pre-voting and pre-submission stages for each shadow node, so that during each stage of node consensus, when the shadow node does not receive instructions from the host node, the shadow node takes corresponding processing actions according to the corresponding default contents, thereby completing the entire node consensus process and preventing other nodes from perceiving that the node is a shadow node.
[0122] S430: Configure response timeout information of the shadow node.
[0123] In the embodiment of the present invention, response timeout refers to the failure to receive information or the failure to receive corresponding information after exceeding the specified time. Correspondingly, response timeout information refers to the response timeout of the shadow node at each stage of node consensus. In the embodiment of the present invention, by configuring corresponding response timeout information for each shadow node, the shadow node can perform corresponding processing actions according to the pre-configured default operation information after the response timeout. For example, Figure 6 and Figure 7 As shown, in a shadow node initial information configuration scenario, the response timeout information configured in the embodiment of the present invention includes the timeout for triggering a proposal, the timeout for triggering a pre-vote, and the timeout for triggering a pre-commit. The embodiment of the present invention configures relevant corresponding timeout information for each shadow node, so that when the shadow node fails to receive an instruction from the host node within the specified time, that is, the response times out, it can take corresponding processing actions in time according to the preset default operation information, thereby effectively improving the operation efficiency of the blockchain network.
[0124] In order to enable the shadow node to process proposals without storing the relevant ledger data in the blockchain network and to achieve a complete node consensus process, in some feasible embodiments, in response to the proposal information sent by the host node, the shadow node extracts the block information from the proposal information for proposal processing and generates a proposal notification, which may include but is not limited to steps S510 to S530:
[0125] S510: When the shadow node becomes a proposal node, it receives proposal information from the host node in real time within a preset waiting time range.
[0126] In the embodiment of the present invention, the proposal node, also known as Proposer, refers to a node that proposes to set a certain value. The behavior of setting the value is a proposal, for example, a node that proposes a new transaction or block. Among them, the proposal node needs to obtain votes from other nodes to make the proposal effective. In the embodiment of the present invention, the preset waiting time is the response timeout of the shadow node, that is, when the proposal information of the host node is not received after the preset waiting time, the response timeout. Specifically, when the shadow node needs to initiate a proposal, that is, the shadow node becomes the current proposal node, because the shadow node does not store the relevant account book data in the blockchain network, it is necessary to receive the proposal information of the corresponding host node to generate the corresponding proposal notification. At the same time, in order to alleviate the problem that the proposal process cannot be completed due to the failure to receive the proposal information of the host node, the embodiment of the present invention sets a corresponding preset waiting time, and the shadow node receives the proposal information of the host node in real time within the preset waiting time range. If the proposal information of the host node is not received within the preset waiting time range, the shadow node performs the corresponding response timeout operation. For example, in a blockchain project application scenario, different nodes may have different interests and opinions. In order to conduct blockchain governance and decision-making, the embodiment of the present invention constructs a corresponding target business node group according to the voting rights requirements of different target business objects, so as to conduct governance and decision-making through the distribution of consensus node voting weights. Accordingly, when the shadow node in the target business node group becomes a proposal node, since the shadow node does not store relevant account book data, it cannot generate corresponding proposal information by itself. In the embodiment of the present invention, the host node associated with the shadow node generates corresponding proposal information and sends it to the corresponding shadow node. At the same time, the shadow node receives the proposal information of the host node in real time within the preset waiting time range, so as to perform subsequent proposal operations according to the received proposal information, thereby realizing a complete proposal process and making other nodes unable to perceive that it is a shadow node.
[0127] S520: When the proposal information of the host node is received, the block information is extracted from the proposal information, and the block information is synthesized to obtain the secondary proposal of the shadow node, and a proposal notification is generated.
[0128] In the embodiment of the present invention, the secondary proposal refers to the proposal put forward by the shadow node. The shadow node constructs the corresponding proposal content according to the proposal information of the host node to package the proposal of the host node into the proposal of the shadow node, that is, the secondary proposal. When the shadow node receives the proposal information of the host node within the preset waiting time range, the embodiment of the present invention extracts the relevant block information from the proposal information, and then synthesizes the block information to obtain the proposal content of the shadow node, that is, the secondary proposal. Then, in the embodiment of the present invention, the shadow node generates the corresponding proposal notification according to the synthesized secondary proposal. Exemplarily, in a blockchain node consensus application scenario, when the shadow node in a target business object becomes a proposal node, the host node associated with the shadow node perceives that its corresponding shadow node is the current proposal node, and the host node generates the corresponding proposal information and sends it to the shadow node that is currently the proposal node. When the shadow node receives the proposal information within the preset time range, it extracts the relevant block information from the proposal information, such as all transaction records, block headers and other relevant information in the block. Then, the embodiment of the present invention synthesizes the extracted block information to obtain the secondary proposal and generates the corresponding proposal notification.
[0129] S530: Broadcast the proposal notification to each node.
[0130] In the embodiment of the present invention, broadcasting refers to broadcast communication, which transmits data in a broadcast network, and each network node can receive relevant data information. In the embodiment of the present invention, a proposal notification is sent to each node in the blockchain network by broadcasting, so that other nodes can verify, accept or reject the proposal. For example, when the shadow node generates a corresponding sub-proposal based on the proposal information of the host node, it obtains a proposal notification, and the shadow node broadcasts the proposal notification so that each node can receive the proposal notification, thereby completing the proposal process of the shadow node. In the embodiment of the present invention, the host node generates proposal information for the associated shadow node, so that the shadow node can complete the proposal function of the node consensus without storing the account book data. While reducing the resource usage, it increases the voting weight of the target business object and can effectively improve the operation efficiency of the blockchain network.
[0131] In order to alleviate the problem that the shadow node fails to receive the proposal information of the host node in time, resulting in the shadow node being unable to complete the proposal, in some feasible embodiments, the block data processing method provided by the embodiment of the present invention may further include step S610:
[0132] S610: When no proposal information of the host node is received within a preset waiting time range, a default proposal notification is generated according to the default configuration information of the shadow node, and the proposal notification is broadcast to each node.
[0133] In the embodiment of the present invention, the default configuration information is the default information for initialization configuration when building a shadow node, and the default information includes the default content for executing a proposal after a response timeout. In the embodiment of the present invention, the preset waiting time is the timeout time for triggering a proposal. Specifically, when the shadow node as a proposal node does not receive the proposal information of its associated host node within the preset waiting time range, the embodiment of the present invention considers that the proposal information reception response has timed out. At this time, the shadow node performs the corresponding response timeout operation, generates a default proposal notification according to the default configuration information pre-configured in the shadow node, and broadcasts it to each node to complete the proposal function. Exemplarily, taking a digital financial asset application scenario as an example, the validity and legality of the transaction need to be verified during the digital financial asset transaction process. Therefore, for some target business objects with higher reliability, they need a higher voice, that is, a higher voting weight. The embodiment of the present invention constructs a target business node group including a corresponding number of shadow nodes and host nodes according to the relevant voting rights requirements. When one of the shadow nodes becomes a proposal node, it is necessary to receive the proposal information of the host node to construct a corresponding secondary proposal, thereby generating a proposal notification. When the shadow node fails to receive the proposal information from the host node within the preset waiting time range, that is, the proposal information reception response times out, in order to respond to the proposal in a timely manner, the shadow node generates a default proposal notification based on its default configuration information and broadcasts it to each node in the blockchain network, thereby alleviating the problem that the shadow node fails to receive the proposal information from the host node in a timely manner, resulting in the shadow node being unable to complete the proposal.
[0134] For example, refer to Figure 8 , Figure 8It is a flow chart of the shadow node in the proposal stage in the embodiment of the present invention. After entering the block consensus process of a new height, the shadow node in the embodiment of the present invention first determines whether it is a proposal node of the height. Among them, the height in the embodiment of the present invention refers to the block height in the blockchain network, that is, the number of blocks in the blockchain. Correspondingly, since each block contains the hash value of the previous block, the block height can also be understood as the chain length in the blockchain. In addition, in the consensus algorithm of the blockchain, each node needs to confirm the validity of the new block by verifying the transaction and hash value in the block and add it to the blockchain. Therefore, the height also represents the synchronization state in the blockchain network, because each node should have the same block height. When it is determined that it is not a proposal node of the height, the shadow node waits for the proposal information of other nodes within a certain period of time. When it is determined that the shadow node itself is a proposal node of the height, the shadow node waits for its corresponding host node to send it proposal information. At the same time, when the host node determines that its corresponding shadow node is a proposal node, it generates corresponding proposal information and sends it to the shadow node to instruct the shadow node to perform proposal processing. When the shadow node receives the proposal information from the host node, it first verifies the source of the proposal information to determine whether it is the proposal information from the associated host node. Then, after the verification is passed, that is, it is determined that the proposal information comes from the associated host node, the shadow node parses the proposal information to obtain the block information therein, and generates a new proposal, namely, a proposal notification, which is then broadcast to each node in the blockchain network. Accordingly, when it is determined that the proposal information does not come from the associated host node, the proposal information is discarded. In addition, when the shadow node does not receive the proposal information from the host node within the preset waiting time range, that is, the response to receiving the host node proposal information times out, the shadow node generates the default proposal information, namely, the proposal notification, according to the pre-configured default configuration information, and broadcasts it to each node.
[0135] Accordingly, refer to Fig. 9 , Fig. 9It is a flow chart of the host node in the proposal stage in an embodiment of the present invention. First, before entering the proposal stage, the embodiment of the present invention configures the host node first. For example, when constructing the target business node group, the host node is configured to construct the list information of the shadow node associated with itself, that is, the shadow node list, so as to associate the host node with the corresponding shadow node. Then, when the consensus process enters a new height, the host node first determines whether it is the proposal node of this round. When it is determined that it is the proposal node of this round, the corresponding proposal is generated and broadcast to other nodes. When it is determined that it is not a proposal node, the host node further determines whether the shadow node associated with itself is a proposal node according to the shadow node list. When it is determined that the shadow node associated with itself is the current proposal node, the corresponding proposal is generated and sent to the corresponding shadow node to guide the shadow node to make a proposal. On the contrary, when it is determined that the shadow node associated with it is not a proposal node, the host node waits for other nodes in the blockchain network to send proposals.
[0136] In order to enable the shadow node to maintain consistency in processing behavior with the host node and implement block locking stage processing, in some feasible embodiments, in response to the block locking voting information sent by the host node, the shadow node extracts the first voting content from the block locking voting information to perform block locking processing on the proposal notification, which may include but is not limited to steps S710 to S730:
[0137] S710: When the shadow node is a proposal node, after broadcasting the proposal notification to each node, it receives the block lock voting information of the host node in real time within a preset waiting time range.
[0138] The preset waiting time range in the embodiment of the present invention refers to the timeout time for triggering the pre-vote (Prevote). In the embodiment of the present invention, the pre-voting information of the shadow node is generated by receiving the block voting information of the host node. Specifically, after the shadow node as the proposal node broadcasts the corresponding proposal notification to each node, the shadow node receives the block locking voting information of the host node in real time within the preset waiting time range, that is, the shadow node obtains the block locking voting information of the proposal from the associated host node in the embodiment of the present invention to keep consistent with the processing behavior of the host node. Exemplarily, in a network security application scenario, the nodes corresponding to certain target business objects may have more weights to improve the security of the network. Accordingly, after the target business object constructs the target business node group according to the corresponding voting right requirements, the relevant node consensus process is performed through the target node group. Among them, when the shadow node in the target node group becomes a proposal node, the host node sends an instruction to the shadow node so that the shadow node can generate the relevant proposal notification and broadcast it to each node. Further, after broadcasting the proposal notification, the shadow node waits for the voting information of the host node, that is, the block locking voting information. At the same time, in the embodiment of the present invention, the shadow node only receives the block lock voting information of the host node within the preset waiting time range. When the waiting time is longer than the preset waiting time range, the corresponding response timeout processing is performed.
[0139] S720: When the block locking voting information of the host node is received, the first voting content is extracted from the block locking voting information, and the first voting content is synthesized to obtain the first voting information of the shadow node, and then a first voting notification is generated.
[0140] In the embodiment of the present invention, the first voting information is the voting information generated by the shadow node for the relevant proposal. Among them, the voting information of the shadow node in the embodiment of the present invention is generated by extracting the first voting content from the block-locked voting information of the host node, so that the shadow node can follow the voting of the host node and improve the voting weight of the host node. Specifically, when the shadow node receives the block-locked voting information of the host node, the embodiment of the present invention extracts the voting content of the host node from the block-locked voting information, that is, the first voting content. Then, the shadow node performs synthesis processing based on the extracted first voting content to construct its own voting information, that is, the first voting information, thereby generating the corresponding first voting notification. Exemplarily, taking a digital collection transaction application scenario as an example, in the process of digital collection transactions, it is necessary to conduct consensus verification on the validity of the relevant transaction behavior, and for some target business object nodes with greater rights and interests or higher reliability, they have a higher voice in the voting verification process, that is, a higher voting weight. Therefore, in the embodiment of the present invention, the corresponding target business node group is configured so that the corresponding target business object occupies the corresponding voting weight. Accordingly, when the shadow node in the target business node group becomes a proposal node and completes the broadcast of the corresponding proposal notification, the shadow node receives the block lock voting information of the host node in real time within the preset waiting time range. When the shadow node receives the corresponding block lock voting information within the preset waiting time range, the embodiment of the present invention extracts the voting information of the host node from the block lock voting information, such as relevant verification voting information, number of votes information, signature information, voting rounds, etc. Furthermore, the embodiment of the present invention combines the extracted first voting content with the relevant information of the shadow node to synthesize the first voting information corresponding to the shadow node, thereby generating a first voting notification.
[0141] S730: Broadcast the first voting notification to each node.
[0142] In the embodiment of the present invention, the first voting notification is a voting notification generated by the shadow node according to the block-locked voting information of the host node. The embodiment of the present invention generates a voting notification of the shadow node, i.e., the first voting notification, based on the relevant voting information extracted from the situation-locked voting information of the host node. Then, the shadow node broadcasts the first voting notification to each node in the blockchain network. For example, when the shadow node generates its own voting notification according to the instructions of the host node, the shadow node broadcasts the voting notification so that each node can receive the voting information of the shadow node and complete the pre-voting function. It is easy to understand that since the voting notification of the shadow node is generated based on the block-locked voting information of its associated host node, the voting result of the shadow node is consistent with that of the host node, thereby increasing the voting weight of the host node.
[0143] In order to alleviate the problem that the shadow node fails to receive the block locking voting information of the host node in time, resulting in the shadow node being unable to complete the pre-voting, in some feasible embodiments, the block data processing method provided by the embodiment of the present invention may further include step S810:
[0144] S810: When the block lock voting information of the host node is not received within the preset waiting time range, a default second voting notification is generated according to the default configuration information of the shadow node, and the second voting notification is broadcast to each node.
[0145] In the embodiment of the present invention, the default configuration information refers to the default content of the pre-voting (Prevote) pre-configured in the shadow node. For example, the default content of the pre-voting is configured during the initialization configuration process of the shadow node, so that when the shadow node does not receive the block locking voting information of the host node within the preset waiting time range, it can complete the voting according to the default configuration information. Specifically, the preset waiting time range in the embodiment of the present invention is the timeout time for triggering the pre-voting (Prevote), that is, the timeout time for receiving the response of the host node block locking voting information. When the shadow node does not receive the block locking voting information of the host node within the preset waiting time range, the shadow node generates a corresponding second voting notification according to its pre-configured pre-voting default content, and broadcasts it to each node, thereby completing the pre-voting function, effectively alleviating the problem that the shadow node cannot receive the block locking voting information, resulting in the shadow node being unable to complete the pre-voting, and improving the operation efficiency of the blockchain network. Exemplarily, taking a game virtual resource allocation application scenario as an example, in some game application scenarios, the game target object needs to allocate its game resources, and the result of the node voting can affect the allocation of game resources or game rewards (such as game coins, game props), so it is necessary to allocate the voting weights of game target objects with different rights and interests to ensure that the nodes participating in the consensus obtain appropriate returns according to their contributions or benefits. Accordingly, the embodiment of the present invention configures the corresponding target business node group according to the voting weight requirements of different game target objects. When the shadow node of the relevant target business node group needs to vote, first obtain the block lock voting information of the host node within the preset waiting time range to generate the corresponding voting notification. When the shadow node does not receive the corresponding block lock voting information within the preset waiting time range, that is, the block lock voting information reception response timeout, at this time, the shadow node generates the corresponding second voting notification according to the pre-configured default configuration information, that is, the default voting notification, and broadcasts the second voting notification to each node, thereby completing the pre-voting process.
[0146] In order to further achieve consistency in processing behaviors between shadow nodes and host nodes and improve the voting weight of host nodes, in some feasible embodiments, in response to the block lock voting information sent by the host node, the shadow node extracts the first voting content from the block lock voting information to perform block lock processing on the proposal notification, which may also include but not be limited to steps S910 to S920:
[0147] S910: When the shadow node is not a proposal node, it waits for proposal notifications from other nodes within a preset time range.
[0148] In the embodiment of the present invention, other nodes are nodes in the blockchain network other than the shadow node. When the shadow node is not a proposal node, the shadow node waits for other nodes in the blockchain network to make proposals within a certain time, that is, a preset time range. For example, when entering a new height, the shadow node first determines whether it is a proposal node for the height. When it is determined that it is not a proposal node for the height, the shadow node enters a waiting state and waits for proposal information from other nodes in the blockchain network within a preset time range.
[0149] S920: When the proposal notification received by the shadow node comes from the host node, a default third voting notification is generated according to the default configuration information of the shadow node, and the third voting notification is broadcast to each node.
[0150] In the embodiment of the present invention, the host node refers to the host node associated with the shadow node. In the embodiment of the present invention, the default configuration information refers to the default voting content configured when the shadow node is initialized. When the proposal node is the host node associated with the shadow node, the embodiment of the present invention generates corresponding voting information through the default voting content. Specifically, in the embodiment of the present invention, when the shadow node receives a proposal notification from the host node, the shadow node first generates a corresponding default voting notification according to its default configuration information, that is, the third voting notification, and broadcasts it to each node in the blockchain network, thereby realizing an increase in the voting weight of the host node. Fig.10 As shown, Fig.10Schematic diagram of the consensus process when the host node is used as the proposal node of this round in a 4-node environment. Among them, node 2 and node 1 in the figure constitute the target business node group, node 1 is the host node, and node 2 is a shadow node associated with node 1. Exemplarily, taking a blockchain shared state update application scenario as an example, when the protocol or rules of the relevant blockchain change, the blockchain network node can decide whether to accept these changes by voting and update the status of the blockchain. Correspondingly, different blockchain network nodes may have different voting weights, and the number of shadow nodes in their target business node groups is also different. When the shadow node is not used as a proposal node, the shadow node only needs to receive the proposal information of other nodes in the blockchain network. When the shadow node receives a proposal notification from the host node within a preset time range, the shadow node directly generates a default voting notification according to the corresponding default configuration information, and broadcasts it to each node in the blockchain network. Among them, the default configuration information has been initialized and configured when the target business node is constructed. The embodiment of the present invention can effectively improve the operating efficiency of the blockchain network by generating a third voting notification according to the default configuration information by the shadow node.
[0151] In order to further achieve consistency in processing behaviors between shadow nodes and host nodes and improve the voting weight of host nodes, in some feasible embodiments, in response to the block lock voting information sent by the host node, the shadow node extracts the first voting content from the block lock voting information to perform block lock processing on the proposal notification, which may also include but not be limited to steps S1010 to S1020:
[0152] S1010: When the proposal notification received by the shadow node does not come from the host node, the block locking voting information of the host node is received in real time within a preset waiting time range.
[0153] In the embodiment of the present invention, the preset waiting time range is the timeout time of triggering pre-voting (Prevote) configured during the initialization process of the shadow node, and the shadow node receives the block lock voting information within the timeout time of triggering pre-voting. Specifically, when the block consensus enters a new height, the shadow node first determines whether it is a proposal node at that height. When it is determined that it is not a proposal node, the shadow node waits for proposal notifications from other nodes within a certain period of time. Then, after the shadow node receives the proposal notification, it analyzes the source of the proposal information. When it is determined that the proposal notification does not come from the host node, the pre-voting of the shadow node needs to be executed according to the instructions of the host node. At this time, the shadow node receives the block lock voting information of the host node in real time within the preset waiting time range. Exemplarily, taking a digital financial asset transaction application scenario as an example, when the shadow node of the relevant digital financial asset target object receives a proposal notification from other digital financial assets in the blockchain network, that is, not a proposal notification from the host node corresponding to the shadow node, the shadow node needs to obtain the block lock voting information of the host node to generate the corresponding voting information, thereby maintaining consistency with the processing behavior of the host node. Accordingly, the shadow node obtains the block lock voting information of the host node within the timeout period of triggering the pre-voting, that is, within the preset waiting time range. It is easy to understand that when the shadow node does not receive the relevant indication information of the host node within the preset waiting time range, the corresponding response timeout processing is performed according to the default configuration information.
[0154] S1020: When the block locking voting information of the host node is received within the preset waiting time, a fourth voting notification is generated and the fourth voting notification is broadcast to each node.
[0155] In the embodiment of the present invention, the fourth voting notification is the voting information for the relevant proposal generated by the shadow node according to the block lock voting information. Among them, the voting notification of the shadow node in the embodiment of the present invention is generated by extracting the voting content from the block lock voting information of the host node, so that the shadow node can follow the voting of the host node and improve the voting weight of the host node. Specifically, when the shadow node receives the block lock voting information of the host node within the preset waiting time, the embodiment of the present invention extracts the relevant voting content of the host node from the block lock voting information. Then, the shadow node performs synthesis processing according to the extracted voting content of the host node to obtain the voting notification of the shadow node, that is, the fourth voting notification. Then, the shadow node broadcasts the fourth voting notification to each node in the blockchain network to complete the voting. Exemplarily, taking a blockchain decision management application scenario as an example, in some decentralized autonomous organizations or blockchain projects, nodes of different target business objects may have different interests and views. By assigning different voting weight ratios to different target business objects, it can be ensured that the nodes participating in the consensus have different influence in the decision-making process. Accordingly, when the shadow nodes of target business objects with different weight ratios are in the pre-voting process, if the proposal notification received by the shadow node does not come from the host node, it needs to receive the block lock voting information from the host node within the preset waiting time to generate the corresponding voting notification. After the shadow node obtains the block lock voting information of its associated host node within the preset waiting time, the shadow node extracts the corresponding voting content according to the block lock voting information and generates the corresponding fourth voting notification, thereby broadcasting the fourth voting notification to each node in the blockchain network for voting, and the fourth voting notification is generated according to the instructions of the host node, so the voting processing behavior of the shadow node is consistent with that of the host node, which effectively improves the influence of the vote of the corresponding target business object.
[0156] For example, refer to Fig.11 , Fig.11It is a flowchart of the consensus processing and pre-voting stage of the shadow node in the embodiment of the present invention. In the embodiment of the present invention, after the shadow node broadcasts the corresponding proposal notification to other nodes, it waits for the voting information broadcast by the host node, that is, the block lock voting information. At the same time, after the host node receives the proposal notification broadcast by the shadow node, it generates the corresponding block lock voting information and sends it to the shadow node. Correspondingly, after the shadow node receives the block lock voting information of the host node, it first parses the block lock voting information to obtain the voting information therein, that is, the first voting content, and generates new voting information, that is, the first voting notification. Then, the shadow node broadcasts the voting information of this line to other nodes. In addition, when the shadow node does not receive the voting information of the host node within the preset waiting time range, that is, the block lock voting information, it is considered that the response has timed out. At this time, the shadow node generates the corresponding default pre-voting information according to the default configuration information of the preset configuration, that is, the second voting notification, and broadcasts it to each node in the blockchain network. When the shadow node is not a proposal node of the height, the shadow node first waits for proposals from other nodes within a certain period of time. When the shadow node receives the proposal information sent by the relevant node, the shadow node first verifies the source of the received proposal information to determine whether the proposal comes from the host node associated with it. When it is determined that the proposal comes from the associated host node, the shadow node directly generates the corresponding voting information according to the preset default configuration information, that is, the third voting notification, and broadcasts it to each node. On the contrary, when it is determined that the proposal does not come from the associated host node, the shadow node enters the waiting state, waiting for the pre-voting information sent by the associated host node, that is, the block lock voting information, so as to perform the processing behavior consistent with the host node according to the relevant block lock voting information.
[0157] In order to enable the shadow node to maintain consistency in processing behavior with the host node and implement block submission phase processing, in some feasible embodiments, in response to the block submission voting information sent by the host node, the node extracts the second voting content from the block submission voting information to perform block submission processing, which may include but is not limited to steps S1110 to S1140:
[0158] S1110: Obtain block locking voting information of other nodes.
[0159] The block lock voting information in the embodiment of the present invention comes from each node in the blockchain network. When the proposal node initiates the corresponding proposal, each node in the blockchain network generates the corresponding block lock voting information after receiving the proposal notification, and broadcasts it to each node. Specifically, in the embodiment of the present invention, after the shadow node broadcasts the corresponding voting notification to each node, the shadow node obtains the block lock voting information broadcast by other nodes in the blockchain network. Exemplarily, in a blockchain voting and election application scenario, when the shadow node of a certain election target object generates a voting notification based on the block lock voting information of the corresponding host node and broadcasts it to each node, the shadow node obtains the block lock voting information broadcast by other nodes in the blockchain network, that is, collects the pre-voting information of other nodes. In the embodiment of the present invention, it is necessary to collect preset pre-voting information before entering the block lock, for example, receiving votes greater than 2 / 3 of the number of nodes.
[0160] S1120: Receive the block submission voting information of the host node in real time within a preset waiting time range.
[0161] In the embodiment of the present invention, the preset waiting time range refers to the timeout time for triggering pre-commit, that is, the timeout time for receiving the block submission voting information response of the host node. Specifically, in the embodiment of the present invention, after obtaining the block locking voting information of other nodes, the shadow node waits for the block submission voting information broadcast by the host node within the preset waiting time range, so as to generate the corresponding voting notification according to the block submission voting information of the host node, thereby realizing the block submission stage processing and maintaining the consistency of the processing behavior with the host node. Exemplarily, taking a network resource application scenario as an example, the network target object needs to allocate its network resources, and the result of the node voting can affect the allocation of network resources. Therefore, it is necessary to allocate the voting weights of the network target objects with different needs to ensure that the nodes participating in the consensus obtain appropriate resources according to their contributions or needs. Accordingly, when the corresponding shadow node broadcasts the corresponding pre-voting information, that is, the voting notification of the pre-voting stage, to each node, it enters the pre-commit stage. The shadow node first obtains the block locking voting information of each node in the block network. Then, the shadow node receives the block submission voting information of the host node in real time within the preset timeout period for triggering pre-submission, that is, the voting information submitted to the block after the host node has a locked block. In the embodiment of the present invention, the block voting information submitted by the shadow node is extracted from the block voting information sent by the host node, and the consensus on the situation information is completed based on the block locking processing results of each node obtained by extraction, so that the voting behavior of the shadow node is consistent with that of the host node.
[0162] S1130: When the block submission voting information of the host node is received within the preset waiting time range, the second voting content is extracted from the block submission voting information, and the second voting content is synthesized to obtain the second voting information of the shadow node, and then a fifth voting notification is generated.
[0163] In the embodiment of the present invention, the second voting content includes the result of the block locking process of each node, that is, the block locking process result of each node received by the host node. Specifically, in the implementation of the present invention, when the shadow node receives the block submission voting information sent by the host node within the preset waiting time range, the shadow node parses the block voting information to extract the corresponding voting content, that is, the second voting content, thereby generating new voting information according to the second voting content, obtaining the second voting information of the shadow node, and generating the corresponding fifth voting notification. Exemplarily, taking a digital financial asset application scenario as an example, the embodiment of the present invention constructs a corresponding target business node group so that the corresponding digital financial asset target object has a higher voice, that is, a higher voting weight. Correspondingly, when the shadow node of the digital financial asset target object receives the block voting information of the host node within the preset trigger pre-submission timeout range, that is, Precommit information, the shadow node parses the block voting information and extracts relevant voting content, such as the block locking process result of each node, so as to synthesize the corresponding shadow node voting information according to the extracted voting content, that is, the second voting information, and then generate the voting notification of the shadow node. It is easy to understand that the voting notification corresponds to the voting information of the host node, so that during the block submission phase, the processing behavior is also consistent with that of the host node.
[0164] S1140: Broadcast the fifth voting notification to each node.
[0165] In an embodiment of the present invention, after the shadow node generates the fifth voting notification according to the block submission voting information of the host node, the fifth voting notification is broadcast to each node to realize the block submission stage processing. For example, in a blockchain consensus application scenario, when the shadow node broadcasts the corresponding pre-vote to each node summarized by the blockchain network, it enters the pre-commit stage. At this time, the shadow node obtains the block submission voting information of the host node in real time within the preset waiting time range, and submits the voting information according to the situation of the host node to generate the corresponding fifth voting notification. Furthermore, after the shadow node generates the corresponding fifth voting notification according to the instruction of the host node, it sends it to each node in the blockchain network by broadcasting for voting, thereby realizing the block submission function.
[0166] In order to alleviate the problem that the shadow node fails to receive the block submission voting information of the host node in time, resulting in the shadow node being unable to complete the pre-submission, in some feasible embodiments, the block data processing method provided by the embodiment of the present invention may further include step S1210:
[0167] S1210: When the block submission voting information of the host node is not received within the preset waiting time range, a default sixth voting notification is generated according to the default configuration information of the shadow node, and the sixth voting notification is broadcast to each node.
[0168] In the embodiment of the present invention, the default configuration information includes the default content of pre-commit. In the process of shadow node initialization, the embodiment of the present invention configures the default content of pre-commit of the shadow node, that is, the default content submitted by the shadow node after the shadow node receives the block submission voting information response of the host node timeout. Specifically, in the embodiment of the present invention, when the shadow node does not receive the block submission voting information of its associated host node within the preset waiting time range, the shadow node directly generates the corresponding sixth voting notification according to the default configuration information and broadcasts it. Exemplarily, taking a digital collection application scenario as an example, when the shadow node in the target business node group of the corresponding digital collection target object does not receive the block submission voting information sent by the corresponding host node within the preset waiting time range, in order to complete the pre-commit in time, the shadow node directly generates a default voting notification according to the pre-configured default configuration information, that is, the sixth voting notification. Then, the shadow node sends the default voting notification to each node in a broadcast manner to complete the pre-commit function, and effectively alleviates the problem that the shadow node cannot complete the pre-commit due to the failure to receive the block submission voting information of the host node in time.
[0169] For example, refer to Fig.12 , Fig.12It is a flowchart of the consensus processing and pre-submission stage of the shadow node in the embodiment of the present invention. In the embodiment of the present invention, after the shadow node broadcasts the corresponding voting notification to each node, it obtains the block locking voting information of other nodes, that is, the pre-voting information. It is easy to understand that at a certain height and number of rounds, after the node receives a pre-voting set of more than 2 / 3 of the total number of nodes for a certain block, the node locks the block of this height and this round. Therefore, in the embodiment of the present invention, it is necessary to collect 2f+1 pre-voting tickets. Among them, f is the number of abnormal nodes in the network, that is, the number of malicious nodes. Then, the shadow node waits for the pre-submission voting information broadcast by the host node, that is, the block submission voting information. After receiving the block submission voting information sent by the host node, the shadow node parses the block submission voting information to obtain the corresponding voting content, that is, the second voting content, thereby generating new pre-submission voting information, that is, the fifth voting notification, and broadcasting it to other nodes. Accordingly, when the shadow node does not receive the pre-submission voting information of the host node within the preset waiting time range, that is, the block submission voting information, it is considered that the response has timed out. At this time, the shadow node of the embodiment of the present invention generates default pre-submission voting information, i.e., the sixth voting notification, according to the preset default configuration information, and broadcasts it to each node in the blockchain network.
[0170] Exemplarily, taking the blockchain node consensus application scenario as an example, the complete implementation process of the block data processing method in the technical solution of this application is described as follows:
[0171] Reference Fig.13 , Fig.13This is a schematic diagram of the overall consensus processing flow of the shadow node of the block data processing method provided by a specific example. After constructing a target business node group including a corresponding number of host nodes and shadow nodes according to the voting rights requirements of the target business object, the target business object performs the corresponding node consensus process through the host node and shadow node of the target business object group. Specifically, when entering a new height, the shadow node first determines whether it is a proposal node at that height. After determining that it is a proposal node, the shadow node waits for the proposal information sent by its corresponding host node. Then, when the shadow node receives the relevant proposal information, it first verifies the source of the proposal information to determine whether it is from the host node associated with the shadow node. When the verification passes, that is, it is determined that the proposal information comes from the host node, the proposal information is parsed to obtain the corresponding block information, and a new proposal notification is generated based on the block information, and the proposal notification is broadcast to other nodes in the blockchain network. On the contrary, if it is verified that the proposal information is not from the host node, it is considered to be a reception error and the proposal information is discarded. In addition, when the shadow node is waiting for the corresponding host node to send proposal information, if it does not receive the relevant proposal information within the preset waiting time range, it is considered that the response has timed out. At this time, the shadow node generates a default proposal notification based on the pre-configured default configuration information and broadcasts it to each node in the blockchain network. At the same time, when the shadow node determines that the proposal node at this height is not itself, it enters the waiting state and waits for the proposal information broadcast by other nodes within a certain period of time.
[0172] Then, after the shadow node broadcasts the corresponding proposal notification to other nodes, the shadow node enters waiting, waiting for the voting information broadcast by the corresponding host node, that is, the block lock voting information. In addition, when the shadow node receives the block lock voting information sent by the corresponding host node, it first parses the block lock voting information to obtain relevant voting information, that is, the first voting content, and then generates new voting information based on the voting information, that is, obtains the first voting information. At the same time, when the shadow node times out waiting for the block lock voting information of the host node, that is, the relevant voting information of the host node is not received within the preset waiting time range, the shadow node generates the default pre-voting information according to the default configuration information, that is, the second voting notification, and broadcasts it to each node in the blockchain network. Correspondingly, when the shadow node is not a proposal node and receives the proposal information (proposal notification) within a certain period of time, the shadow node first verifies the source of the received proposal to confirm whether the proposal notification comes from the host node. When it is determined that the proposal notification comes from the host node, the shadow node directly generates the default voting information according to the pre-configured default configuration information, that is, the third voting notification, and broadcasts it to other nodes. On the contrary, when it is determined that the proposal node is not from the host node, the shadow node enters a waiting state, waiting for the block lock voting information broadcast by the corresponding host node, so as to generate corresponding voting information (voting notification) according to the block lock information of the host node, and broadcast it to each node in the blockchain network.
[0173] Further, after the shadow node broadcasts the generated voting information to each node, the shadow node first obtains the block lock voting information of other nodes, that is, the pre-voting information. For example, the shadow node needs to collect 2f+1 blocks of block lock voting information. Among them, f refers to the number of nodes allowed to do evil in the entire blockchain network. If this number is exceeded, the security of the entire network will be reduced or even unavailable. Then, the shadow node waits for the pre-submission information, that is, the block submission information, broadcast by its associated host node, and parses the block submission information to obtain the voting content therein. Then, the shadow node generates new voting information (voting notification) based on the voting content obtained by the analysis, that is, the second voting content, and broadcasts it to other nodes in the blockchain network. Accordingly, when the shadow node does not receive the block submission information of the host node within the preset waiting time range, it is deemed to have timed out. At this time, the shadow node generates the corresponding default voting information, that is, the sixth voting notification, according to the default configuration information configured during initialization, and broadcasts it to each node. Then, when the node receives a block submission message for a locked block greater than 2 / 3 or satisfying 2f+1, it will confirm the block and enter the consensus process for the next height block.
[0174] The embodiment of the present invention also provides a block data processing method of a target blockchain network, wherein the target blockchain network includes multiple nodes, including:
[0175] Determine a target business node from multiple nodes of the target blockchain network;
[0176] Calculate the number of shadow nodes to be configured for the target business node based on the voting weight that the target business node expects to achieve and the number of nodes in the target blockchain network;
[0177] Among them, the block data processing performed by the shadow node remains consistent with the block data processing of the target business node, and the shadow node does not save the block ledger data of the block data processing.
[0178] Configuring shadow nodes for target service nodes according to the number of shadow nodes also includes:
[0179] Configure node mapping information between shadow nodes and target service nodes, where the node mapping information represents the association relationship between each shadow node and the target service node;
[0180] Configure the default operation information of the shadow node. The default operation information is used to indicate the processing action to be taken by the shadow node when it does not receive the instruction sent by the target service node;
[0181] Configure the response timeout information of the shadow node.
[0182] The method also includes:
[0183] In response to the proposal information sent by the target business node, the shadow node extracts the block information from the proposal information for proposal processing and generates a proposal notification; or, according to the default operation information, the shadow node extracts the block information from the proposal information for proposal processing and generates a proposal notification, wherein the proposal notification is used to trigger each node to perform block locking processing;
[0184] In response to the block lock voting information sent by the target business node, the shadow node extracts the first voting content from the block lock voting information to perform block lock processing on the proposal notification; or, according to the default operation information, the shadow node extracts the first voting content from the block lock voting information to perform block lock processing on the proposal notification;
[0185] In response to the block submission voting information sent by the target business node, the shadow node extracts the second voting content from the block submission voting information to perform block submission processing to complete the consensus on the block information; or, according to the default operation information, the shadow node extracts the second voting content from the block submission voting information to perform block submission processing to complete the consensus on the block information; wherein the second voting content includes the results of the block locking processing of each node.
[0186] In an embodiment of the present invention, in a specific business scenario, a target blockchain network is constructed, which includes multiple network nodes, including a target business node with a higher degree of importance. According to some specific business scenario requirements, the target business node needs to obtain a higher voting weight. Therefore, the embodiment of the present invention can calculate the number of shadow nodes to be configured according to the voting weight expected to be achieved by the target business node, and then configure the shadow node for the target business node. Exemplarily, for a blockchain network with three nodes, assuming that a certain participant (i.e., the target business node) hopes to occupy 50% of the authority, then it only needs to deploy a shadow node. At this time, the entire blockchain network contains four nodes with voting rights, and the voting rights obtained by combining the target business node and the shadow node account for 50%, reaching the voting weight expected to be achieved by the target business node. In summary, the shadow node of the embodiment of the present invention does not need to store the relevant account book data of the blockchain network, and can execute the processing behavior consistent with or defaulted by the host node, which reduces the resource occupation of the business object with a high weight ratio and improves the operation efficiency of the blockchain network.
[0187] like Fig.14 As shown, an embodiment of the present invention further provides a block data processing device, the device comprising:
[0188] The first module 1310 is used to construct a target business node group according to the voting rights requirements of the target business object. The target business node group includes a host node and at least one shadow node. The shadow node is used to perform proposal processing, block locking processing or block submission processing according to the instructions of the host node.
[0189] The second module 1320 is used to respond to the proposal information sent by the host node, and the shadow node extracts the block information from the proposal information for proposal processing and generates a proposal notification. The proposal notification is used to trigger each node to perform block locking processing.
[0190] The third module 1330 is used to respond to the block locking voting information sent by the host node, and the shadow node extracts the first voting content from the block locking voting information to perform block locking processing on the proposal notification.
[0191] The fourth module 1340 is used to respond to the block submission voting information sent by the host node, and the shadow node extracts the second voting content from the block submission voting information to perform block submission processing to complete the consensus on the block information. Among them, the second voting content includes the results of the block locking processing of each node.
[0192] It can be understood that the contents of the block data processing method embodiment shown above are all applicable to the block data processing device embodiment, and the functions specifically implemented by the block data processing device embodiment are the same as those of the block data processing method embodiment shown above, and the beneficial effects achieved are also the same as those achieved by the block data processing method embodiment shown above.
[0193] Combined with Fig.14 , the specific implementation process of the block data processing device provided by the present invention is described: First, the first module 1310 constructs a target business node group according to the voting rights requirements of the target business object. Specifically, the target business node group includes a host node and at least one shadow node. Among them, the shadow node can perform proposal processing, block locking processing or block submission processing according to the instructions of the host node. Correspondingly, the number of shadow nodes is determined by the voting rights requirements of the target business object. Then, the second module 1320 responds to the proposal information issued by the host node, and the shadow node extracts the block information from the proposal information for proposal processing and generates a proposal notification. Specifically, the proposal notification is used to trigger each node to perform block locking processing. Further, the third module 1330 responds to the block locking voting information issued by the host node, and the shadow node extracts the first voting content from the block locking voting information to perform block locking processing on the proposal notification. Finally, the fourth module 1340 responds to the block submission voting information issued by the host node, and the shadow node extracts the second voting content from the block submission voting information for block submission processing to complete the consensus on the block information. Specifically, the second voting content includes the result of the block locking process of each node. The embodiment of the present invention constructs a target business node group including a host node and at least one shadow node according to the voting rights requirements of the target business object, wherein the shadow node of the embodiment of the present invention is used to perform proposal processing, block locking processing or block submission processing according to the instructions of the host node. The shadow node does not need to store the relevant account book data of the blockchain network, and can execute the processing behavior consistent with or defaulted by the host node, which reduces the resource occupation of business objects with high weight ratio and improves the operation efficiency of the blockchain network.
[0194] like Fig.15As shown, an embodiment of the present invention further provides an electronic device, which includes a processor 1410 and a memory 1420; the memory 1420 stores a program; the processor 1410 executes the program to execute the aforementioned block data processing method; the electronic device has the function of carrying and running the software system for business data processing provided by an embodiment of the present invention, for example, a personal computer (PC), a mobile phone, a smart phone, a personal digital assistant (PDA), a wearable device, a handheld computer PPC (Pocket PC), a tablet computer, a vehicle-mounted terminal, etc.
[0195] It can be understood that the contents of the block data processing method embodiment shown above are all applicable to the present electronic device embodiment, the functions specifically implemented by the present electronic device embodiment are the same as those of the block data processing method embodiment shown above, and the beneficial effects achieved are also the same as those achieved by the block data processing method embodiment shown above.
[0196] The embodiment of the present invention further provides a computer-readable storage medium, the storage medium stores a program, and the program is executed by a processor to implement the aforementioned block data processing method. At the same time, the embodiment of the present invention further provides a computer program product or a computer program, the computer program product or the computer program includes a computer instruction, and the computer instruction is stored in a computer-readable storage medium. The processor of the computer device can read the computer instruction from the computer-readable storage medium, and the processor executes the computer instruction, so that the computer device executes the aforementioned block data processing method.
[0197] It can be understood that the contents of the block data processing method embodiment shown above are all applicable to the computer-readable storage medium embodiment, the functions specifically implemented by the computer-readable storage medium embodiment are the same as those of the block data processing method embodiment shown above, and the beneficial effects achieved are also the same as those achieved by the block data processing method embodiment shown above.
[0198] The embodiment of the present invention also discloses a computer program product or a computer program, wherein the computer program product or the computer program includes a computer instruction, and the computer instruction is stored in a computer-readable storage medium. A processor of a computer device can read the computer instruction from the computer-readable storage medium, and the processor executes the computer instruction, so that the computer device executes Figure 5 The method shown.
[0199] It can be understood that the contents of the block data processing method embodiment shown above are all applicable to the present computer program product or computer program embodiment, and the functions specifically implemented by the present computer program product or computer program embodiment are the same as those of the block data processing method embodiment shown above, and the beneficial effects achieved are also the same as those achieved by the block data processing method embodiment shown above.
[0200] In some selectable embodiments, the function / operation mentioned in the block diagram may not occur in the order mentioned in the operation diagram. For example, depending on the function / operation involved, the two boxes shown in succession can actually be executed substantially simultaneously or the boxes can sometimes be executed in reverse order. In addition, the embodiment presented and described in the flow chart of the present invention is provided by way of example, for the purpose of providing a more comprehensive understanding of technology. The disclosed method is not limited to the operation and logic flow presented herein. Selectable embodiments are expected, wherein the order of various operations is changed and the sub-operation of a part for which is described as a larger operation is performed independently.
[0201] From the embodiments provided in the above description, it can be clearly seen that the technical solution of the present invention has at least the following beneficial effects:
[0202] The technical solution of the present invention constructs a target business node group according to the voting rights requirements of the target business object, wherein the target business node group includes a host node and at least one shadow node; the shadow node of the embodiment of the present invention is used to perform proposal processing, block locking processing or block submission processing according to the instructions of the host node. The shadow node does not need to store relevant account book data of the blockchain network, and can execute processing behaviors consistent with or by default with the host node, thereby reducing the resource usage of business objects with high weight ratios and improving the operating efficiency of the blockchain network. Specifically, in an embodiment of the present invention, the shadow node can respond to the proposal information issued by the host node, extract the block information from the proposal information for proposal processing, and generate a proposal notification, so that the shadow node can realize the same block proposal function as all ordinary nodes in the blockchain network; in addition, the shadow node can also respond to the block lock voting information issued by the host node, extract the first voting content from the block lock voting information, and perform block lock processing on the proposal notification, so that the shadow node realizes the block lock voting function; finally, the shadow node can respond to the block submission voting information issued by the host node, extract the second voting content from the block submission voting information for block submission processing, and complete the consensus on the block information, so that the shadow node realizes the block submission voting function; so far, the shadow node in the target business node group constructed by the embodiment of the present invention can realize the same proposal or consensus function as an ordinary node without occupying the ledger storage resources, can meet the voting rights requirements of any business object, and occupy a low amount of resources, and effectively improve the operation efficiency of the blockchain network in a low resource occupancy manner.
[0203] In some selectable embodiments, the function / operation mentioned in the block diagram may not occur in the order mentioned in the operation diagram. For example, depending on the function / operation involved, the two boxes shown in succession can actually be executed substantially simultaneously or the boxes can sometimes be executed in reverse order. In addition, the embodiment presented and described in the flow chart of the present invention is provided by way of example, for the purpose of providing a more comprehensive understanding of technology. The disclosed method is not limited to the operation and logic flow presented herein. Selectable embodiments are expected, wherein the order of various operations is changed and the sub-operation of a part for which is described as a larger operation is performed independently.
[0204] In addition, although the present invention is described in the context of functional modules, it is understood that, unless otherwise specified, one or more of the functions and / or features described may be integrated into a single physical device and / or software module, or one or more functions and / or features may be implemented in separate physical devices or software modules. It is also understood that a detailed discussion of the actual implementation of each module is unnecessary for understanding the present invention. More specifically, in view of the properties, functions, and internal relationships of the various functional modules in the device disclosed herein, the actual implementation of the module will be understood within the conventional skills of the engineer. Therefore, those skilled in the art can implement the present invention set forth in the claims without excessive experimentation using ordinary techniques. It is also understood that the specific concepts disclosed are merely illustrative and are not intended to limit the scope of the present invention, which is determined by the full scope of the appended claims and their equivalents.
[0205] If the functions are implemented in the form of software functional units and sold or used as independent products, they can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of the present invention, or the part that contributes to the prior art or the part of the technical solution, can be embodied in the form of a software product. The computer software product is stored in a storage medium, including several instructions for a computer device (which can be a personal computer, a server, or a network device, etc.) to perform all or part of the steps of the methods described in each embodiment of the present invention. The aforementioned storage medium includes: U disk, mobile hard disk, read-only memory (ROM, Read-Only Memory), random access memory (RAM, Random Access Memory), disk or optical disk, etc., which can store program codes.
[0206] The logic and / or steps represented in the flowchart or otherwise described herein, for example, can be considered as an ordered list of executable instructions for implementing logical functions, and can be embodied in any computer-readable medium for use by an instruction execution system, device or apparatus (such as a computer-based system, a system including a processor, or other system that can fetch instructions from an instruction execution system, device or apparatus and execute instructions), or in conjunction with such instruction execution systems, devices or apparatuses. For the purposes of this specification, "computer-readable medium" can be any device that can contain, store, communicate, propagate or transmit a program for use by an instruction execution system, device or apparatus, or in conjunction with such instruction execution systems, devices or apparatuses.
[0207] More specific examples of computer-readable media (a non-exhaustive list) include the following: an electrical connection with one or more wires (electronic device), a portable computer disk case (magnetic device), a random access memory (RAM), a read-only memory (ROM), an erasable and programmable read-only memory (EPROM or flash memory), an optical fiber device, and a portable compact disk read-only memory (CDROM). In addition, the computer-readable medium may even be a paper or other suitable medium on which the program is printed, since the program may be obtained electronically, for example, by optically scanning the paper or other medium, followed by editing, deciphering or, if necessary, processing in another suitable manner, and then stored in a computer memory.
[0208] It is understood that the various parts of the present invention can be implemented by hardware, software, firmware or a combination thereof. In the above-mentioned embodiments, a plurality of steps or methods can be implemented by software or firmware stored in a memory and executed by a suitable instruction execution system. For example, if implemented by hardware, as in another embodiment, it can be implemented by any one of the following technologies known in the art or their combination: a discrete logic circuit having a logic gate circuit for implementing a logic function for a data signal, a dedicated integrated circuit having a suitable combination of logic gate circuits, a programmable gate array (PGA), a field programmable gate array (FPGA), etc.
[0209] In the description of this specification, the description with reference to the terms "one embodiment", "some embodiments", "examples", "specific examples", or "some examples" means that the specific features, structures, materials or characteristics described in conjunction with the embodiment or example are included in at least one embodiment or example of the present invention. In this specification, the schematic representation of the above terms does not necessarily refer to the same embodiment or example. Moreover, the specific features, structures, materials or characteristics described may be combined in any one or more embodiments or examples in a suitable manner.
[0210] Although the embodiments of the present invention have been shown and described, it will be appreciated by those skilled in the art that various changes, modifications, substitutions and variations may be made to the embodiments without departing from the principles and spirit of the present invention, and that the scope of the present invention is defined by the claims and their equivalents.
[0211] The above is a specific description of the preferred implementation of the present invention, but the present invention is not limited to the described embodiments. Those skilled in the art may make various equivalent modifications or substitutions without violating the spirit of the present invention. These equivalent modifications or substitutions are all included in the scope defined by the claims of the present invention.
Claims
1. A block data processing method, characterized in that: include: According to the voting right requirements of the target business object, a target business node group is constructed; wherein the target business node group includes a host node and at least one shadow node; The host node performs block data processing according to the stored block ledger data; The block data processing performed by the shadow node is consistent with the block data processing of the host node, and the shadow node does not save the block ledger data of the block data processing.
2. A block data processing method according to claim 1, characterized in that: The process of the shadow node performing block data processing includes: In response to the proposal information sent by the host node, the shadow node extracts the block information from the proposal information to perform proposal processing and generate a proposal notification; the proposal notification is used to trigger each node to perform block locking processing; in response to the block locking voting information sent by the host node, the shadow node extracts the first voting content from the block locking voting information to perform block locking processing on the proposal notification; In response to the block submission voting information sent by the host node, the shadow node extracts the second voting content from the block submission voting information to perform block submission processing, thereby completing the consensus on the block information; wherein the second voting content includes the results of the block locking processing of each node.
3. A block data processing method according to claim 1, characterized in that: The step of constructing a target business node group according to the voting rights requirements of the target business object includes: According to the voting right requirements of the target business object, configure one or more shadow nodes for the host node of the target business object; Initial information is configured for each of the shadow nodes, and the configured shadow nodes are combined with the host node to obtain the target service node group.
4. A block data processing method according to claim 3, characterized in that: The initial information configuration for each shadow node includes: Configuring node mapping information between the shadow node and the host node, wherein the node mapping information represents an association relationship between each shadow node and a corresponding host node; Configuring default operation information of the shadow node, wherein the default operation information is used to indicate a processing action to be taken by the shadow node when no instruction is received from the host node; Configure the response timeout information of the shadow node.
5. A block data processing method according to claim 2, characterized in that: In response to the proposal information sent by the host node, the shadow node extracts block information from the proposal information for proposal processing and generates a proposal notification, including: When the shadow node becomes a proposal node, it receives the proposal information of the host node in real time within a preset waiting time range; When receiving the proposal information of the host node, extracting the block information from the proposal information, synthesizing the block information to obtain the secondary proposal of the shadow node, and generating a proposal notification; The proposal notification is broadcast to each node.
6. A block data processing method according to claim 5, characterized in that: The method further comprises: When the proposal information of the host node is not received within the preset waiting time range, a default proposal notification is generated according to the default configuration information of the shadow node, and the proposal notification is broadcast to each node.
7. A block data processing method according to claim 5, characterized in that: In response to the block lock voting information sent by the host node, the shadow node extracts the first voting content from the block lock voting information to perform block lock processing on the proposal notification, including: When the shadow node is a proposal node, after broadcasting the proposal notification to each node, it receives the block locking voting information of the host node in real time within a preset waiting time range; When receiving the block lock voting information of the host node, extracting the first voting content from the block lock voting information, synthesizing the first voting content to obtain the first voting information of the shadow node, and generating a first voting notification; The first voting notification is broadcast to each node.
8. A block data processing method according to claim 7, characterized in that: The method further comprises: When the block lock voting information of the host node is not received within the preset waiting time range, a default second voting notification is generated according to the default configuration information of the shadow node, and the second voting notification is broadcast to each node.
9. A block data processing method according to claim 7, characterized in that: In response to the block lock voting information sent by the host node, the shadow node extracts the first voting content from the block lock voting information to perform block lock processing on the proposal notification, and further includes: When the shadow node is not a proposal node, it waits for proposal notifications from other nodes within a preset time range; When the proposal notification received by the shadow node comes from the host node, a default third voting notification is generated according to the default configuration information of the shadow node, and the third voting notification is broadcast to each node.
10. A block data processing method according to claim 9, characterized in that: In response to the block lock voting information sent by the host node, the shadow node extracts the first voting content from the block lock voting information to perform block lock processing on the proposal notification, and further includes: When the proposal notification received by the shadow node does not come from the host node, the block locking voting information of the host node is received in real time within a preset waiting time range; When the block locking voting information of the host node is received within the preset waiting time, a fourth voting notification is generated and the fourth voting notification is broadcast to each node.
11. A block data processing method according to claim 2, characterized in that: In response to the block submission voting information sent by the host node, the shadow node extracts the second voting content from the block submission voting information to perform block submission processing, including: Get the block lock voting information of other nodes; Receive the block submission voting information of the host node in real time within a preset waiting time range; When the block submission voting information of the host node is received within the preset waiting time range, the second voting content is extracted from the block submission voting information, and the second voting content is synthesized to obtain the second voting information of the shadow node, and a fifth voting notification is generated; The fifth voting notification is broadcast to each node.
12. A block data processing method according to claim 11, characterized in that: The method further comprises: When the block submission voting information of the host node is not received within the preset waiting time range, a default sixth voting notification is generated according to the default configuration information of the shadow node, and the sixth voting notification is broadcast to each node.
13. A method for processing block data of a target blockchain network, wherein the target blockchain network includes a plurality of nodes, characterized in that: include: Determining a target business node from multiple nodes of the target blockchain network; Calculate the number of shadow nodes to be configured for the target business node according to the voting weight that the target business node expects to achieve and the number of nodes in the target blockchain network; The block data processing performed by the shadow node is consistent with the block data processing of the target business node, and the shadow node does not save the block ledger data of the block data processing.
14. A block data processing method according to claim 13, characterized in that: The configuring of shadow nodes for the target service node according to the number of shadow nodes also includes: Configuring node mapping information between the shadow node and the target service node, wherein the node mapping information represents an association relationship between each shadow node and the target service node; Configuring default operation information of the shadow node, where the default operation information is used to indicate a processing action to be taken by the shadow node when the shadow node does not receive an instruction sent by the target service node; Configure the response timeout information of the shadow node.
15. A block data processing method according to claim 14, characterized in that: The method further comprises: In response to the proposal information sent by the target business node, the shadow node extracts the block information from the proposal information for proposal processing and generates a proposal notification; or, according to the default operation information, the shadow node extracts the block information from the proposal information for proposal processing and generates a proposal notification, wherein the proposal notification is used to trigger each node to perform block locking processing; In response to the block lock voting information sent by the target business node, the shadow node extracts the first voting content from the block lock voting information to perform block lock processing on the proposal notification; or, according to the default operation information, the shadow node extracts the first voting content from the block lock voting information to perform block lock processing on the proposal notification; In response to the block submission voting information sent by the target business node, the shadow node extracts the second voting content from the block submission voting information to perform block submission processing, and completes the consensus on the block information; or, according to the default operation information, the shadow node extracts the second voting content from the block submission voting information to perform block submission processing, and completes the consensus on the block information; wherein the second voting content includes the result of the block locking processing of each node.
16. A block data processing device, characterized in that: include: The first module is used to construct a target business node group according to the voting right requirements of the target business object; wherein the target business node group includes a host node and at least one shadow node; The host node performs block data processing according to the stored block ledger data; The block data processing performed by the shadow node is consistent with the block data processing of the host node, and the shadow node does not save the block ledger data of the block data processing.
17. An electronic device, characterized in that: including a processor and a memory; The memory is used to store programs; The processor executes the program to implement the method according to any one of claims 1 to 15.
18. A computer-readable storage medium, characterized in that: The storage medium stores a program, and the program is executed by a processor to implement the method according to any one of claims 1 to 15.
19. A computer program product comprising a computer program, characterized in that When the computer program is executed by a processor, the method according to any one of claims 1 to 15 is implemented.
Citation Information
Cited By
Node access method and system based on alliance chain
CN119484544A
Block data processing method and apparatus, and electronic device and storage medium
EP4700630A1