Block data processing method and apparatus, and electronic device and storage medium

Abstract

The present application is applied to the technical field of the Internet and other technical fields, such as cloud computing and the Internet of Vehicles, related to Internet technology. Disclosed are a block data processing method and apparatus, and an electronic device and a storage medium. The method comprises: acquiring a voting right requirement of a service object to be subjected to processing, and constructing a service node group according to the voting right requirement of said service object, wherein the service node group comprises a service node of said service object and at least one shadow node; the service node of said service object is used for executing block data processing according to stored block ledger data; and block data processing executed by the shadow node remains consistent with the block data processing of the service node of said service object, and the shadow node does not store block ledger data for the block data processing, such that the voting right requirement of any service object can be met, thereby reducing the resource occupation amount of a service object with a high weight proportion, and thus improving the operation efficiency of a blockchain network.

Description

Block data processing method, device, electronic device and storage medium

[0001] This application claims priority to the Chinese patent application filed with the China Patent Office on June 28, 2023, application number 202310781850.9, and application name “A block data processing method, device, electronic device and storage medium”, all contents of which are incorporated by reference into this application. Technical Field

[0002] The present application relates to the field of computer technology, in particular to block data processing technology. Background Art

[0003] With the continuous development of computer networks, blockchain-related technologies are becoming increasingly mature. Blockchain represents a new application model for computer technologies such as distributed data storage, peer-to-peer transmission, consensus mechanisms, and encryption algorithms. Given that information stored on a blockchain cannot be forged or tampered with, an increasing number of enterprises are building business nodes on the blockchain to store and manage their business data.

[0004] However, for some business systems, due to the varying importance of their business, different business systems have different weights within the same blockchain, meaning their voting values ​​within the blockchain are different. In this case, for business systems with higher weights, a corresponding number of consensus nodes need to be deployed on the blockchain. For example, assuming the entire blockchain network includes three business systems as participants, if participant A wishes to have a higher voice, it will need to deploy more consensus nodes. For example, for participants A, B, and C, if A requires a higher voice, this means deploying two consensus nodes for participant A, and one consensus node each for B and C. At this point, participant A has two consensus nodes and has a higher voice in voting transactions initiated within the blockchain.

[0005] 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 required, such as central processing unit (CPU) resources and storage resources, resulting in greater resource consumption.

[0006] Summary of the Invention

[0007] In view of this, the embodiments of the present application provide 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.

[0008] In one aspect, an embodiment of the present application provides a block data processing method, which is performed by an electronic device and includes but is not limited to the following steps:

[0009] Get the voting rights requirements of the business object to be processed;

[0010] Constructing a business node group for the business object to be processed based on the voting rights requirements of the business object to be processed; wherein the business node group includes the business node of the business object to be processed and at least one shadow node corresponding to the business node;

[0011] The business node of the business object to be processed is used to perform block data processing based on the stored block ledger data;

[0012] The block data processing performed by the shadow node is consistent with the block data processing of the business node of the business object to be processed. The shadow node does not save the block ledger data of the block data processing.

[0013] On the other hand, an embodiment of the present application provides a block data processing method, which is executed by an electronic device and includes:

[0014] In response to a proposal message sent by a business node of a pending business object, extracting block information from the proposal message for proposal processing and generating a proposal notification; the proposal notification is used to trigger each node to perform block locking processing, the business node and shadow node of the pending business object being located in a business node group of the pending business object, and the business node group of the pending business object being constructed based on any of the methods of the previous aspect;

[0015] In response to the block lock voting information sent by the business node of the business object to be processed, extract the first voting content from the block lock voting information, and use the first voting content to perform block lock processing on the proposal notification;

[0016] In response to the block submission voting information sent by the business node of the business object to be processed, the second voting content is extracted from the block submission voting information, and the block submission processing is performed using the second voting content to complete the consensus on the block information; wherein the second voting content includes the results of the block locking processing of each node.

[0017] On the other hand, an embodiment of the present application provides a method for processing block data of a blockchain network, wherein the blockchain network includes multiple nodes, and the method is performed by an electronic device, including:

[0018] Determine a business node for a business object to be processed from multiple nodes in the blockchain network;

[0019] Calculate the number of shadow nodes to be configured for the business node of the business object to be processed based on the expected voting weight of the business node of the business object to be processed and the number of nodes in the blockchain network;

[0020] Configure shadow nodes for the business nodes to be processed based on the number of shadow nodes;

[0021] Among them, the business node of the business object to be processed saves the block ledger data of the block data processing, the block data processing performed by the shadow node remains consistent with the block data processing of the business node of the business object to be processed, and the shadow node does not save the block ledger data of the block data processing.

[0022] On the other hand, an embodiment of the present application provides a block data processing device, which is deployed on an electronic device and includes:

[0023] An acquisition module is configured to obtain the voting rights requirements of a pending business object; a first module is configured to construct a business node group for the pending business object based on the voting rights requirements of the pending business object; wherein the business node group includes a business node of the pending business object and at least one shadow node corresponding to the business node;

[0024] The business node of the business object to be processed is used to perform block data processing based on the stored block ledger data;

[0025] The block data processing performed by the shadow node is consistent with the block data processing of the business node of the business object to be processed. The shadow node does not save the block ledger data of the block data processing.

[0026] On the other hand, an embodiment of the present application provides a block data processing device, which is deployed on a shadow node and includes:

[0027] A second module is configured to respond to proposal information sent by a business node of a pending business object, extract block information from the proposal information, perform proposal processing, and generate a proposal notification; the proposal notification is used to trigger each node to perform block locking processing, the business node and shadow node of the pending business object being located in a business node group of the pending business object, and the business node group of the pending business object being constructed based on any of the methods of the aforementioned aspects;

[0028] A third module is configured to extract first voting content from the block lock voting information in response to the block lock voting information sent by the business node of the business object to be processed, and perform block lock processing on the proposal notification using the first voting content;

[0029] The fourth module is used to respond to the block submission voting information sent by the business node of the business object to be processed, extract the second voting content from the block submission voting information, and use the second voting content to perform block submission processing to achieve consensus on the block information; wherein the second voting content includes the results of the block locking processing of each node.

[0030] On the other hand, an embodiment of the present application provides a block data processing device for a blockchain network, wherein the blockchain network includes multiple nodes, and the device is deployed on an electronic device, including:

[0031] A determination module, configured to determine a business node of a business object to be processed from multiple nodes in a blockchain network;

[0032] A calculation module, configured to calculate the number of shadow nodes to be configured for the business node of the business object to be processed based on the voting weight expected to be achieved by the business node of the business object to be processed and the number of nodes in the blockchain network;

[0033] A configuration module, configured to configure shadow nodes for business nodes of services to be processed according to the number of shadow nodes;

[0034] Among them, the business node of the business object to be processed saves the block ledger data of the block data processing, the block data processing performed by the shadow node remains consistent with the block data processing of the business node of the business object to be processed, and the shadow node does not save the block ledger data of the block data processing.

[0035] On the other hand, an embodiment of the present application further provides an electronic device, including a processor and a memory;

[0036] The memory is used to store programs;

[0037] The processor executes the program to implement the above block data processing method.

[0038] On the other hand, an embodiment of the present application further provides a computer-readable storage medium, which stores a computer program. The computer program is executed by a processor to implement the block data processing method as described above.

[0039] On the other hand, an embodiment of the present application further provides a computer program product, including a computer program, which implements the above block data processing method when executed by a processor.

[0040] The embodiment of the present application first obtains the voting rights requirements of the business object to be processed, and constructs a business node group based on the voting rights requirements of the business object to be processed, wherein the business node group includes the business node of the business object to be processed and at least one shadow node; the business node of the business object to be processed in the embodiment of the present application performs block data processing based on the stored block ledger data, and the block data processing performed by the shadow node is consistent with the block data processing of the business node of the business object to be processed. 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 processing behaviors that are consistent with or default with the business node of the business object to be processed, thereby reducing the resource occupancy of business objects with high weight ratios and improving the operating efficiency of the blockchain network. The embodiment of the present application can meet the voting rights requirements of any business object and improve the operating efficiency of the blockchain network in a manner with low resource occupancy. BRIEF DESCRIPTION OF THE DRAWINGS

[0041] In order to more clearly illustrate the technical solutions in the embodiments of the present application, the following briefly introduces the drawings required for use in the description of the embodiments. 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 any creative work.

[0042] FIG1 is a schematic diagram of the structural deployment of a related implementation environment in the related art;

[0043] FIG2 is a schematic diagram of an implementation environment for data processing in an embodiment of the present application;

[0044] FIG3 is a schematic diagram of an implementation environment structure deployment provided in an embodiment of the present application;

[0045] FIG4 is a schematic diagram of a business system application provided in an embodiment of the present application;

[0046] FIG5 is a schematic flow chart of the steps of a block data processing method provided in an embodiment of the present application;

[0047] FIG6 is a schematic diagram of the shadow node configuration information structure provided in an embodiment of the present application;

[0048] FIG7 is a diagram illustrating an example configuration of shadow node configuration information provided in an embodiment of the present application;

[0049] FIG8a is a schematic flow chart of another block data processing method provided in an embodiment of the present application;

[0050] FIG8 b is a schematic diagram of the process of the shadow node in the proposal stage provided in an embodiment of the present application;

[0051] FIG9 is a flow diagram of a business node of a business object to be processed in the proposal stage provided in an embodiment of the present application;

[0052] FIG10 is a schematic diagram of a consensus process when the business node of the business object to be processed provided in an embodiment of the present application is a proposal node;

[0053] FIG11 is a schematic diagram of a process flow of a shadow node in the pre-voting phase provided in an embodiment of the present application;

[0054] FIG12 is a schematic diagram of a process of a shadow node in the pre-commit stage provided in an embodiment of the present application;

[0055] FIG13 is a schematic diagram of the overall consensus processing flow of the shadow node provided in an embodiment of the present application;

[0056] FIG14 is a modular schematic diagram of a block data processing device provided in an embodiment of the present application;

[0057] FIG15 is a schematic structural diagram of an electronic device provided in an embodiment of the present application. DETAILED DESCRIPTION

[0058] In order to make the purpose, technical solutions and advantages of this application more clearly understood, the present application is further described in detail below with reference to the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are only used to explain this application and are not intended to limit this application.

[0059] In the following description, reference is made to “some embodiments”, which describes 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.

[0060] Unless otherwise defined, all technical and scientific terms used herein have the same meaning as commonly understood by those skilled in the art to which this application pertains. The terms used herein are for the purpose of describing the embodiments of this application only and are not intended to limit this application.

[0061] Before further describing the embodiments of the present application in detail, the nouns and terms involved in the embodiments of the present application are explained. The nouns and terms involved in the embodiments of the present application are subject to the following interpretations.

[0062] Blockchain is a new application model for computer technologies, including distributed data storage, peer-to-peer transmission, consensus mechanisms, and encryption algorithms. Essentially, a blockchain is a decentralized database, a chain of data blocks linked using cryptographic methods. Each block contains information about a batch of network transactions, used to verify the validity of this information (to prevent counterfeiting) and generate the next block. Blockchains can include the underlying blockchain platform, the platform's product and service layer, and the application service layer. Blockchains can include public, consortium, and private chains. Public chains are blockchains where anyone can access the network at any time to read data, send data, or compete for recordkeeping. Consortium chains are blockchains jointly managed by several organizations or institutions. Private chains are blockchains with a certain degree of centralized control. Write access to the private chain's ledger is controlled by a specific organization or institution, and data access and use are subject to strict permission management.

[0063] 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 the hash value of the previous block. The block is verified by the network's consensus mechanism and the transactions in the block are confirmed.

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

[0065] On this basis, the characteristic concepts that may be involved in the invention are explained:

[0066] Consensus algorithms are the specifications followed by all blockchain nodes. They are a set of processes and rules developed to implement a distributed consensus protocol. When geographically distributed nodes negotiate and interact according to these rules, they ultimately reach a consensus on a particular issue or issues, achieving consistency across nodes in the distributed system.

[0067] TBFT algorithm: Tendermint BFT consensus algorithm, it 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.

[0068] 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 consistent decisions through a consensus algorithm.

[0069] Proposal: A request or proposal sent by the business node of the pending business object to the verification node for consensus processing on a certain block.

[0070] Based on the above theoretical foundations, 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.

[0071] With the continuous development of computer networks, blockchain-related technologies are becoming increasingly mature. Blockchain represents a new application model for computer technologies such as distributed data storage, peer-to-peer transmission, consensus mechanisms, and encryption algorithms. Given that information stored on a blockchain cannot be forged or tampered with, an increasing number of enterprises are building business nodes on the blockchain to store and manage their business data. However, for some business systems, due to varying degrees of importance, different business systems have varying weights within the same blockchain, meaning their votes have a higher value. In these cases, the more weighted business systems require a corresponding number of consensus nodes to be deployed on the blockchain. For example, referring to Figure 1, assume that the entire blockchain network includes three business systems as participants. If participant A desires a higher voice, it will need to deploy more consensus nodes. For example, for participants A, B, and C, if participant A desires a higher voice, two consensus nodes can be deployed for participant A, and one consensus node can be deployed for participants B and C. In this case, participant A has two consensus nodes and has a higher voice in voting transactions initiated on the blockchain.

[0072] 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 required, such as CPU resources and storage resources, resulting in greater resource consumption.

[0073] To this end, the solution provided in the embodiment of the present application involves technologies such as blockchain, and the shadow node in the business node group performs proposal processing, block locking processing or block submission processing according to the instructions of the business node of the business object to be processed, 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 business node of the business object to be processed, thereby effectively reducing the resource usage of business objects with high weight ratio and improving the operating efficiency of the blockchain network.

[0074] It is understandable that the block data processing method provided in the embodiment of the present application can be applied to any electronic device with data processing and computing capabilities, and this electronic device can be various terminals or servers, and the terminal and 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 electronic device in the embodiment of the present application 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), and big data and artificial intelligence platforms. Optionally, the terminal is a smart phone, tablet computer, laptop computer, desktop computer, etc., but is not limited to this.

[0075] It should be further explained that the terminals involved in the embodiments of the present application include but are not limited to smartphones, computers, intelligent voice interaction devices, smart home appliances, vehicle-mounted terminals, aircraft, etc. The embodiments of the present application can be applied to various scenarios, including but not limited to cloud technology, artificial intelligence, smart transportation, assisted driving, etc.

[0076] In some possible implementations, a computer program capable of implementing the block data processing method provided in the embodiments of the present application may be deployed and executed on one electronic device, or on multiple electronic devices located at one location, or on multiple electronic devices distributed at multiple locations and interconnected through a communication network. Multiple electronic devices distributed at multiple locations and interconnected through a communication network may constitute a blockchain system.

[0077] Based on the fact that multiple electronic devices can form a blockchain system, the electronic device that implements the block data processing method in the embodiment of the present application 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 business node group including a business node of the business object to be processed and at least one shadow node according to the voting rights requirements of the business object to be processed, so that the shadow node performs proposal processing, block locking processing or block submission processing according to the instructions of the business node of the business object to be processed. At the same time, in the embodiment of the present application, the shadow node does not store the relevant account book data of the blockchain network, but only needs to execute the processing behavior that is consistent with or defaults to the business node of the business object to be processed, thereby reducing the resource usage of business objects with high weight ratios and improving the operating efficiency of the blockchain network.

[0078] As shown in Figure 2, it is a schematic diagram of an implementation environment provided by an embodiment of the present application. Referring to Figure 2, the implementation environment includes multiple nodes 101, and multiple nodes 101 refer to each terminal or server in the data processing system 100, which can be a computer, mobile phone, tablet computer, other terminal, the background server of the program logic, or a cloud server that provides services such as cloud computing and cloud storage. Among them, node 101 can also be called a business node, or a consensus node. When performing normal work, each 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 information can be transmitted between nodes through the above-mentioned information connection. For example, when any node in the data processing system 100 receives input information, the 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. The relevant node 101 can construct a business node group including the business node of the business object to be processed and at least one shadow node based on the voting rights requirements of the business object to be processed. The constructed shadow node can be directly used in downstream tasks for performing relevant block consensus operations (including but not limited to proposal processing, block locking processing, or block submission processing).

[0079] Exemplarily, node 101 first obtains the voting rights requirements of the business object to be processed, and then constructs a business node group based on the voting rights requirements of the business object to be processed, wherein the business node group includes the business node of the business object to be processed 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 business node of the business object to be processed, 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 business node of the business object to be processed, extract the first voting content from the block lock voting information and perform block lock processing on the proposal notification; c. In response to the block submission voting information issued by the business node of the business object to be processed, extract the second voting content from the block submission voting information for block submission processing and complete the consensus on the block information; at this point, the shadow node in the business node group constructed in the embodiment of the present application 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 improve the operation efficiency of the blockchain network in a way with low resource occupancy.

[0080] This block data processing method can be applied in various scenarios.

[0081] For example, in a consensus voting scenario involving a pending business object, after obtaining authorization from the pending business object, a business node group is constructed within node 101 of the pending business object based on the voting rights requirements of the pending business object. Accordingly, the business node group includes the business node of the pending business object and at least one shadow node. The number of shadow nodes is set based on the voting rights requirements of the pending business object. Shadow nodes in the business node group can execute proposal processing, block locking, or block submission processing according to the instructions of the business node of the pending business object. Shadow nodes do not store relevant ledger data for the blockchain network and only need to execute processing behaviors consistent with or default to the business node of the pending business object. This ensures that the shadow nodes maintain consistent processing behaviors with those of the business node of the pending business object, increases the voting weight of the business node of the pending business object, and satisfies the voting rights requirements of the pending business object. Furthermore, shadow nodes consume fewer resources, effectively improving the operational efficiency of the blockchain network. It can be understood that the above application scenarios only serve as 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 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 business node group. No limitation is made to the application scenario of the block data processing method provided in the embodiment of the present application.

[0082] Based on the implementation environment shown in FIG2 , the embodiment of the present application provides an application scenario for consensus node weight distribution. In this scenario, there is an information connection between the nodes, and information can be transmitted between the nodes through the above information connection. The node can be applied to the target by building a business node group to increase its weight ratio in the node network. For example, referring to FIG3 , in a four-node network, according to the voting rights requirements of the business object to be processed, the weight ratio of the corresponding node needs to be occupied to 50%. Then, a business node group including a business node (node ​​1) and a shadow node (node ​​2) of a business object to be processed is constructed to achieve the weight distribution of the consensus node, and the shadow node does not store the relevant account book data of the blockchain network, but only executes the processing behavior consistent with the business node of the business object to be processed or the default, that is, node 2 does not have an actual account book, but has voting rights, thereby being able to 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. For example, the target application can be an application platform for resource allocation, or a web link, mini-program, or application plug-in with business functions such as transaction validity verification or shared status updates, set up in multimedia applications (such as film and television applications, short video applications, or music applications, etc.), social applications, gaming applications, and navigation applications. For example, in an actual business system, its deployment may be as shown in Figure 4, where the real node in the figure can serve as the business node of the business object to be processed of the shadow node, that is, the business node of the business object to be processed.

[0083] It should be noted that in each specific implementation of this application, when it comes to obtaining the object's feature data, object behavior data, object historical data, object location information and other data related to the object's identity or characteristics for related processing, the object's permission or authorization 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 this application needs to obtain the sensitive personal information of the object, it will obtain the object's separate permission or separate consent through a pop-up window or jump to a confirmation page. After clearly obtaining the object's separate permission or separate consent, the necessary object-related data for the normal operation of the embodiment of this application will be obtained.

[0084] FIG5 is a flowchart of a block data processing method provided by an embodiment of the present application. The execution subject of the block data processing method can be any of the aforementioned electronic devices. Referring to FIG5 , the method includes the following steps:

[0085] S210: Obtain the voting rights requirements of the business object to be processed.

[0086] S220: Construct a business node group based on the voting rights requirements of the business object to be processed.

[0087] The business node group includes the business node of the business object to be processed and at least one shadow node of the business node. The business node of the business object to be processed is used to perform block data processing based on the stored block ledger data. The block data processing performed by the shadow node is consistent with the block data processing of the business node of the business object to be processed. The shadow node does not store the block ledger data of the block data processing.

[0088] In the embodiments of this application, a pending business object refers to a participant or organization in a business application, such as an enterprise, related institution, or group participating in a blockchain business network. In the embodiments of this application, voting rights, or voting weights, refer to the permissions each node possesses during the voting process. Accordingly, in the embodiments of this application, voting rights requirements refer to the desired permissions of the business node corresponding to the pending business object, i.e., the voting weight value that the business node needs to possess.

[0089] It is easy to understand that in the embodiment of the present application, the shadow node only performs relevant consensus business processing according to the instructions of the business node of the business object to be processed, such as proposal processing, block locking processing or block submission processing, so that the shadow node can maintain consistency with the processing behavior of the business node of the business object to be processed, increase the voting weight of the business node of the business object to be processed, meet the voting rights requirements of the business object to be processed, and the shadow node does not store the relevant ledger data in the blockchain network, which can effectively reduce the resource occupation of the shadow node and improve the operating efficiency of the blockchain network.

[0090] Specifically, in the embodiment of the present application, the business node group constructed based on the voting rights requirements of the business object to be processed includes the business node of the business object to be processed and at least one shadow node. Among them, the business node of the business object to be processed is the real node of the business object to be processed and can serve as the host node. Therefore, the business node of the business object to be processed can also be called the host node, and the block ledger data is stored in the host node. In the embodiment of the present application, the number of shadow nodes of the business node can be specifically adjusted according to the voting rights requirements. For example, taking a network security application scenario as an example, the embodiment of the present application first constructs the corresponding business node group based on 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 network security verification process, so that its voting results have greater influence, thereby improving the security of the network. Therefore, the embodiment of the present application determines the number of shadow nodes included in the corresponding business node group based on the voting rights requirements of the relevant network security nodes, thereby constructing a business node group that meets the voting rights requirements of the network security nodes. Accordingly, in the embodiment of the present application, the shadow node performs relevant business processing according to the instructions of the business node of the business object to be processed to maintain consistency with the processing behavior of the business node of the business object to be processed, thereby increasing the voting weight of the business node of the business object to be processed, that is, the voting influence of the corresponding network security node is increased.

[0091] In order to effectively improve the voting weight of the business object to be processed and meet the voting rights requirements of any business object, in some feasible embodiments, the step of constructing a business node group according to the voting rights requirements of the business object to be processed may include but is not limited to S310 to S320:

[0092] S310: According to the voting rights requirements of the business object to be processed, one or more shadow nodes are configured for the business node of the business object to be processed.

[0093] In the embodiment of the present application, the business node of the business object to be processed is a real node, that is, the host node of the shadow node, and the business node of the business object to be processed will store the relevant block ledger data in the blockchain network. Accordingly, in the embodiment of the present application, the shadow node does not have actual block ledger data, that is, the shadow node will not store the relevant block ledger 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. Therefore, other nodes cannot perceive that the node is a shadow node, and do not know that there is no block ledger data stored in the shadow node. The embodiment of the present application analyzes the voting requirements of the business object to be processed and configures one or more shadow nodes for the business node of the business object to be processed, so that the voting rights requirements of any business object can be met.

[0094] For example, taking an application scenario consisting of four pending business objects as an example, each pending business object corresponds to a business node, and therefore, the voting weight of the business node of each pending business object is 25%. When one of the pending business objects A needs to reach a voting weight of 40%, the embodiment of the present application configures a shadow node for the node corresponding to the pending business object, that is, the business node of the pending business object, based on the voting rights requirement of the pending business object, that is, the voting weight accounts for 40%. It is easy to understand that after configuring a shadow node for the business node of the pending business object of the pending business object, there are five nodes in the network. The nodes of other pending 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 business node of the pending business object, thereby being able to increase the voting weight of the pending business object A to 40%. Accordingly, the embodiment of the present application configures a corresponding number of shadow nodes for the business nodes of the pending business objects with different voting rights requirements, thereby being able to effectively improve the voting weight of the pending business objects, thereby meeting the voting rights requirements of any business object.

[0095] S320: Perform initial information configuration on each shadow node, and combine the configured shadow node with the service node of the service object to be processed to obtain a service node group.

[0096] In the embodiments of the present application, the initial information configuration refers to the relevant node configuration information of the shadow node, such as the shadow node's identity, network address, security settings, and other configuration information. After configuring the corresponding number of shadow nodes for the business node of the business object to be processed according to the voting rights requirements of the business object to be processed, the embodiment of the present application performs initialization information configuration on each shadow node, and then combines the configured shadow nodes with the business node of the business object to be processed to obtain a business node group. For example, when two shadow nodes are configured for the corresponding business node according to the voting rights requirements of the business object to be processed. Then, the embodiment of the present application first initializes the two shadow nodes separately, that is, performs initial information configuration, such as relevant identity, consensus algorithm parameters, and relevant node information parameters such as network address. After completing the relevant initialization information configuration, the shadow node is equivalent to an ordinary node to the outside world. Except for the business node of the corresponding business object to be processed, which can perceive that it is a shadow node, other nodes recognize it as a normal node. Then, the embodiment of the present application combines the two configured shadow nodes with the business node of the corresponding business object to be processed, thereby constructing a business node combination that meets the voting rights requirements of the relevant business object to be processed.

[0097] In order to enable the shadow node to have consistent processing behavior with the business node of the business object to be processed 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 S410 to S430:

[0098] S410: Configuring node mapping information between shadow nodes and service nodes of the business object to be processed. The node mapping information represents the association relationship between each shadow node and the service node corresponding to the business object to be processed.

[0099] In the embodiment of the present application, the node mapping information refers to the mapping information of the shadow node and the business node of the business object to be processed to which it corresponds, that is, the real node information mapped by the shadow node. In the embodiment of the present application, the association relationship refers to the correspondence between the shadow node and the business node of the business object to be processed. Among them, the mapping node information in the embodiment of the present application represents the association relationship between each shadow node and the business node of the business object to be processed to which it corresponds. In the embodiment of the present application, the node mapping information between the shadow node and the business node of the business object to be processed is configured to construct the correspondence between the business node of the business object to be processed and the shadow node, so that the shadow node can receive the instruction of the business node of the business object to be processed and maintain the consistency of the processing behavior of the business node of the business object to be processed. For example, as shown in Figures 6 and 7, after the business node of the business object to be processed is configured with a corresponding number of shadow nodes according to the voting rights requirements of the business object to be processed, the embodiment of the present application configures the node mapping information for each shadow node to associate the business node of the corresponding business object to be processed, so that the shadow node can perform the relevant processing behavior according to the instruction of the business node of the business object to be processed.

[0100] S420: Configuring 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 an instruction from the business node of the business object to be processed.

[0101] The default operation information in the embodiment of the present application refers to the relevant processing action information executed when the shadow node does not receive the instruction issued by the business node of the corresponding business object to be processed. 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 business node of the business object to be processed, or the business node of the business object to be processed fails to issue 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, as shown in Figures 6 and 7, the default operation information configured in the embodiment of the present application includes the default content of the proposal (Proposal), the default content of the pre-vote (Prevote) and the default content of the pre-commit (Precommit).

[0102] It should be noted that the default operation information mentioned in the embodiment of the present application can be adaptively configured according to the needs of the business nodes of the business objects to be processed. For example, the pre-voting information issued by the business nodes of the business objects to be processed can be set to default approval, and the pre-voting information issued by the business nodes of the non-business objects to be processed can be set to default disapproval. The embodiment of the present application does not limit this. For example, in a resource allocation application scenario, the results of node voting can affect the allocation of assets or rewards. Therefore, the voting weight distribution of consensus nodes can also be used to determine the allocation method of resources to ensure that the nodes participating in the consensus receive appropriate returns according to their contributions or benefits. Accordingly, after configuring a corresponding number of shadow nodes for the business nodes of the business objects to be processed according to the voting rights requirements of the business objects to be processed, the embodiment of the present application configures corresponding default operation information for each shadow node to alleviate the problem that the shadow node cannot execute the relevant node consensus processing when it does not receive instructions from the business nodes of the business objects to be processed.

[0103] The embodiment of the present application configures corresponding default content for 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 business node of the business object to be processed, the shadow node takes corresponding processing actions according to the corresponding default content, thereby completing the entire node consensus process and making it impossible for other nodes to perceive that the node is a shadow node.

[0104] S430: Configure response timeout information of the shadow node.

[0105] In the embodiment of the present application, response timeout refers to the failure to receive information or the failure to receive corresponding information after exceeding the specified time. Accordingly, the response timeout information refers to the response timeout of the shadow node at each stage of the node consensus. The embodiment of the present application configures corresponding response timeout information for each shadow node so that the shadow node can perform the corresponding processing action according to the pre-configured default operation information after the response timeout. Exemplarily, as shown in Figures 6 and 7, in a shadow node initial information configuration scenario, the response timeout information configured in the embodiment of the present application 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 application configures the relevant corresponding timeout information for each shadow node so that when the shadow node does not receive an instruction from the business node of the business object to be processed within the specified time, that is, the response timeout, it can take the corresponding processing action in time according to the preset default operation information, effectively improving the operating efficiency of the blockchain network.

[0106] Based on the above introduction to the method of constructing a business node group, an embodiment of the present application further provides a block data processing method for a blockchain network, wherein the blockchain network includes multiple nodes. The method is used to configure a shadow node for a business node, and the method includes:

[0107] Determine a business node for a business object to be processed from multiple nodes in the blockchain network;

[0108] Calculate the number of shadow nodes to be configured for the business node of the business object to be processed based on the expected voting weight of the business node of the business object to be processed and the number of nodes in the blockchain network;

[0109] Configure shadow nodes for the business nodes to be processed based on the number of shadow nodes.

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

[0111] When the voting right requirement in S310 is the voting right weight that the business node of the business object to be processed expects to achieve, this method may be a specific implementation of S310.

[0112] In one possible implementation, configuring shadow nodes for the service nodes of the business object to be processed based on the number of shadow nodes may include configuring node mapping information between the shadow nodes and the service nodes of the business object to be processed, where the node mapping information represents the association between each shadow node and the service node of the business object to be processed; configuring default operation information for the shadow nodes, where the default operation information indicates the processing action to be taken by the shadow nodes when they do not receive an instruction from the service node of the business object to be processed; and configuring response timeout information for the shadow nodes. For details, see S410 to S430, which will not be further described here.

[0113] In an embodiment of the present application, in a specific business scenario, a blockchain network is constructed. This blockchain network includes multiple nodes, including business nodes of business objects to be processed with a higher degree of importance. According to some specific business scenario requirements, the business nodes of the business objects to be processed need to obtain higher voting rights weights. Therefore, the embodiment of the present application can calculate the number of shadow nodes to be configured based on the voting rights weight expected to be achieved by the business nodes of the business objects to be processed, and then configure shadow nodes for the business nodes of the business objects to be processed. For example, for a blockchain network with three nodes, assuming that a certain participant (i.e., the business node of the business object to be processed) hopes to occupy 50% of the authority, then it only needs to deploy one shadow node. At this time, the entire blockchain network contains four nodes with voting rights, and the voting rights obtained by combining the business nodes and shadow nodes of the business objects to be processed account for 50%, reaching the voting rights weight expected to be achieved by the business nodes of the business objects to be processed. In summary, the shadow nodes of the embodiment of the present application do not need to store the relevant account book data of the blockchain network, and can execute processing behaviors consistent with or defaulted to the business nodes of the business objects to be processed, reducing the resource usage of business objects with high weight ratios and improving the operating efficiency of the blockchain network.

[0114] After constructing a business node group for the business object to be processed based on the above method, when block data needs to be processed, block data processing can be performed based on the business node group for the business object to be processed. The block data processing method can be executed by a shadow node, which can be an electronic device such as a server or terminal, but this embodiment of the application does not limit this. Referring to Figure 8a, the method includes:

[0115] S230: In response to the proposal information sent by the business node of the business object to be processed, extract the block information from the proposal information, perform proposal processing, and generate a proposal notification.

[0116] The proposal notification is used to trigger each node to perform block locking processing. The business node and shadow node of the pending business object are located in the business node group of the pending business object. The business node group of the pending business object is constructed based on the method described in the above embodiment.

[0117] In the embodiment of the present application, 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 application, the proposal information of the shadow node in the business node group is provided by the business node of the business object to be processed, that is, before the shadow node initiates the proposal, it first obtains the corresponding proposal information from the business node of the business object to be processed to maintain consistency with the processing behavior of the business node of the business object to be processed. It can be understood that the shadow node can receive the proposal information sent by the business node of the business object to be processed in real time within the preset waiting time. This proposal information can directly issue an instruction to the shadow node, requiring the shadow node to make a corresponding proposal processing. In other words, the proposal processing of the shadow node can be consistent with the processing behavior of the business node of the business object to be processed. 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 by 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 application can help the business node of the business object to be processed to improve the voting weight.

[0118] In the embodiment of the present application, 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 based on the block information and vote to decide whether to accept the block. In the embodiment of the present application, 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. Accordingly, a proposal notification refers to the notification information that the relevant consensus node proposes a new rule, protocol or improvement plan and notifies other nodes to discuss and vote to decide whether to adopt the proposal. In the embodiment of the present application, the shadow node extracts the corresponding block information from the proposal information sent by the business node of the pending business object for proposal processing to generate a relevant proposal notification and send it to each node, thereby triggering each node to perform block locking processing. Wherein, 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 approval of a certain block. For example, 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 application first sends a proposal message to the corresponding shadow node through the business node of the corresponding business node group. Then, the corresponding shadow node responds to the proposal message, extracts the relevant block information from it, and performs the 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.

[0119] S240: In response to the block lock voting information sent by the business node of the business object to be processed, extract the first voting content from the block lock voting information, and use the first voting content to perform block lock processing on the proposal notification.

[0120] In the embodiment of the present application, the block lock voting information refers to the information in the blockchain network in which the business node of the pending business object votes on the lock status of a certain block. Accordingly, 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. In the embodiment of the present application, the first voting content refers to the block lock status information executed on the relevant block, which is extracted from the block lock voting information issued by the business node of the pending business object, such as confirming whether the node is valid or invalid. For example, 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 pending business objects to ensure the fairness and transparency of the election. Therefore, the embodiment of the present application first constructs a business node group based on the voting rights requirements of the corresponding election voting objects. Then, when the business node group receives a proposal notification initiated by other nodes, the business node of the business object to be processed in the business node group sends block lock voting information to the shadow node. 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 based on the first voting content, so that the processing behavior of the shadow node is consistent with that of the business node of the business object to be processed, thereby increasing the voting weight of the business node of the business object to be processed, that is, the voting influence of the corresponding election voting object is increased.

[0121] S250: In response to the block submission voting information sent by the business node of the business object to be processed, the shadow node extracts the second voting content from the block submission voting information, and uses the second voting content to perform block submission processing to complete the consensus on the block information.

[0122] The second voting content includes the results of the block locking process of each node.

[0123] In the embodiment of the present application, the block submission voting information refers to the voting information submitted for this block when 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 lock 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 application, 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 application is extracted from the block voting information issued by the business node of the business object to be processed, and the consensus on the situation information is completed based on the extracted block locking process results of each node, so that the voting behavior of the shadow node is consistent with the business node of the business object to be processed. For example, 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 pending business object receives a protocol modification proposal from a certain node, the pending business object sends a block submission voting information to the shadow node through the business node of the pending business object in the business node group to instruct the shadow node to perform the relevant block voting processing. In the embodiment of the present application, the block voting information of the business node of the pending business object is obtained from the result of the block locking processing of each node. Accordingly, in the embodiment of the present application, 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 business node of the pending business object on the relevant proposals, and completing the consensus on the block information.

[0124] In order to enable the shadow node to process proposals without storing 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 business node of the business object to be processed, the shadow node extracts block information from the proposal information for proposal processing and generates a proposal notification. This step may include but is not limited to S510 to S520:

[0125] S510: When the shadow node becomes a proposal node, it receives proposal information of the business node of the business object to be processed in real time within a preset waiting time.

[0126] In the embodiments of the present application, a proposal node, also known as a proposer, refers to a node that proposes to set a value. This act of setting a value is called a proposal, for example, a node that proposes a new transaction or block. The proposal node needs to obtain votes from other nodes for the proposal to take effect. In the embodiments of the present application, the preset waiting time is the response timeout of the shadow node. That is, if the proposal information of the business node of the pending business object is not received within the preset waiting time, the response timeout occurs. Specifically, when the shadow node needs to initiate a proposal, that is, the shadow node becomes the current proposal node. Since the shadow node does not store the relevant block ledger data in the blockchain network, it needs to receive the proposal information of the business node of the corresponding pending business object to generate the corresponding proposal notification. At the same time, in order to alleviate the problem of being unable to complete the proposal process due to not receiving the proposal information of the business node of the pending business object, the embodiments of the present application set a corresponding preset waiting time. The shadow node receives the proposal information of the business node of the pending business object in real time within the preset waiting time. If the proposal information of the business node of the pending business object is not received within the preset waiting time, the shadow node performs the corresponding response timeout operation.

[0127] 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 application constructs a corresponding business node group based on the voting rights requirements of different pending business objects, so as to conduct governance and decision-making through the distribution of voting weights of consensus nodes. Accordingly, when a shadow node in a business node group becomes a proposal node, since the shadow node does not store the relevant block ledger data, it cannot generate corresponding proposal information by itself. In the embodiment of the present application, the business node of the pending business object 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 business node of the pending business object in real time within the preset waiting time, so as to perform subsequent proposal operations according to the received proposal information, thereby realizing a complete proposal process and making it impossible for other nodes to perceive that it is a shadow node.

[0128] S520: When the proposal information of the business node of the business object to be processed 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.

[0129] In the embodiment of the present application, a secondary proposal refers to a proposal put forward by a shadow node. The shadow node constructs corresponding proposal content based on the proposal information of the business node of the business object to be processed, so as to package the proposal of the business node of the business object to be processed into a proposal of the shadow node, i.e., a secondary proposal. When the shadow node receives the proposal information of the business node of the business object to be processed within the preset waiting time, the embodiment of the present application extracts the relevant block information from the proposal information, and then synthesizes the block information to obtain the proposal content of the shadow node, i.e., the secondary proposal. Then, in the embodiment of the present application, the shadow node generates a corresponding proposal notification based on the synthesized secondary proposal. For example, in a blockchain node consensus application scenario, when the shadow node in a certain business object to be processed becomes a proposal node, the business node of the business object to be processed associated with the shadow node perceives that its corresponding shadow node is the current proposal node. The business node of the business object to be processed generates 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 waiting time, it extracts relevant block information from the proposal information, such as all transaction records, block headers, and other relevant information in the block. Next, the embodiment of the present application synthesizes the extracted block information to obtain a secondary proposal and generates a corresponding proposal notification.

[0130] After receiving the proposal notification, the proposal notification can be broadcast to each node. In the embodiment of the present application, broadcast 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 application, the 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 business node of the business object to be processed, it receives 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 application, the business node of the business object to be processed generates proposal information for the associated shadow node, which enables the shadow node to complete the proposal function of the node consensus without storing the account book data. While reducing resource usage, it increases the voting weight of the business object to be processed and can effectively improve the operating efficiency of the blockchain network.

[0131] In order to alleviate the problem that the shadow node fails to receive the proposal information of the business node of the business object to be processed in a timely manner, resulting in the shadow node being unable to complete the proposal, in some feasible embodiments, the block data processing method provided in the embodiment of the present application may further include S610:

[0132] S610: When no proposal information of the business node of the business object to be processed is received within the preset waiting time, 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 application, the default configuration information is the default information initialized when the shadow node is constructed. The default information includes the default content for executing the proposal after the response timeout. In the embodiment of the present application, the preset waiting time is the timeout for triggering the proposal. Specifically, when the shadow node as the proposal node does not receive the proposal information of its associated business node within the preset waiting time, the embodiment of the present application 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 based on the default configuration information pre-configured in the shadow node, and broadcasts it to each node to complete the proposal function. For example, 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 certain business objects with higher reliability, they require a higher voice, that is, a higher voting weight. In the embodiment of the present application, based on the relevant voting rights requirements, a business node group is constructed to obtain a corresponding number of shadow nodes and business nodes of the business object to be processed. When a shadow node becomes a proposal node, it is necessary to construct a corresponding secondary proposal by receiving the proposal information of the business node of the business object to be processed, thereby generating a proposal notification. When the shadow node fails to receive the proposal information of the business node of the pending business object within the preset waiting time, 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 according to 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 of the business node of the pending business object in a timely manner, resulting in the shadow node being unable to complete the proposal.

[0134] For example, refer to Figure 8b, which is a schematic diagram of the shadow node's proposal phase in an embodiment of the present application. After entering the consensus process for a block at a new height, the shadow node in this embodiment first determines whether it is the proposing node for that height. In this embodiment, height refers to the block height in the blockchain network, i.e., the number of blocks in the blockchain. Accordingly, 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. Furthermore, in the blockchain consensus algorithm, each node must verify the validity of the new block by verifying the transactions and hash value within the block and adding it to the blockchain. Therefore, height also represents the synchronization status within the blockchain network, as every node should have the same block height. If the shadow node determines that it is not the proposing node for that height, it waits for proposal information from other nodes within a certain period of time. If the shadow node determines that it is the proposing node for that height, it waits for the business node of the corresponding pending business object to send it a proposal. At the same time, when the business node of the pending business object determines that its corresponding shadow node is a proposal node, it generates corresponding proposal information and sends it to the shadow node, instructing the shadow node to process the proposal. Upon receiving the proposal information from the business node of the pending business object, the shadow node first verifies the source of the proposal information to confirm that it is from the business node of the associated pending business object. Then, upon successful verification, i.e., determining that the proposal information originated from the business node of the associated pending business object, the shadow node parses the proposal information to obtain the block information contained therein and generates new proposal information, i.e., a proposal notification, which is then broadcast to each node in the blockchain network. Accordingly, if it is determined that the proposal information does not originate from the business node of the associated pending business object, the proposal information is discarded. Furthermore, if the shadow node does not receive the proposal information from the business node of the pending business object within a preset waiting time, i.e., if the response to the proposal information from the business node of the pending business object times out, the shadow node generates default proposal information, i.e., a proposal notification, based on pre-configured default configuration information and broadcasts it to each node.

[0135] Accordingly, refer to Figure 9, which is a schematic diagram of the process flow for a business node of a pending business object during the proposal phase in an embodiment of the present application. First, before entering the proposal phase, the embodiment of the present application configures the business node of the pending business object. For example, when constructing a business node group, the business node of the pending business object is configured and a list of its associated shadow nodes, i.e., a shadow node list, is constructed to associate the business node of the pending business object with the corresponding shadow node. Next, when the consensus process reaches a new level, the business node of the pending business object first determines whether it is the proposing node for that round. If it is determined to be the proposing node for that round, it generates a corresponding proposal and broadcasts it to other nodes. If it is determined not to be the proposing node, the business node of the pending business object further determines whether its associated shadow node is a proposing node based on the shadow node list. If it is determined that its associated shadow node is the current proposing node, it generates a corresponding proposal and sends it to the corresponding shadow node to instruct the shadow node to submit a proposal. Conversely, if it is determined that its associated shadow node is not a proposing node, the business node of the pending business object waits for other nodes in the blockchain network to submit a proposal.

[0136] In order to enable the shadow node to maintain consistency in processing behavior with the business node of the business object to be processed and implement block locking phase processing, in some feasible embodiments, in response to the block locking voting information sent by the business node of the business object to be processed, the shadow node extracts the first voting content from the block locking voting information and performs block locking processing on the proposal notification. This step may include but is not limited to 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 business node of the pending business object in real time within the preset waiting time.

[0138] In the embodiment of the present application, the range of the preset waiting time refers to the timeout time for triggering the pre-vote (Prevote). In the embodiment of the present application, the pre-voting information of the shadow node is generated by receiving the block voting information of the business node of the pending business object. 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 business node of the pending business object in real time within the range of the preset waiting time, that is, in the embodiment of the present application, the shadow node obtains the block locking voting information of the proposal from the business node of the associated pending business object to maintain consistency with the processing behavior of the business node of the pending business object. For example, in a network security application scenario, the nodes corresponding to certain pending business objects may have more voting weights to improve the security of the network. Accordingly, after the pending business object constructs the business node group according to the corresponding voting rights requirements, the relevant node consensus process is carried out through the business node group. Among them, when the shadow node in the business node group becomes a proposal node, the business node of the pending business object sends an instruction to the shadow node so that the shadow node can generate the relevant proposal notification and broadcast it to each node. Furthermore, after broadcasting the proposal notification, the shadow node waits for voting information from the business node of the pending business object, i.e., the block lock voting information. Furthermore, in this embodiment of the application, the shadow node only receives block lock voting information from the business node of the pending business object within a preset waiting time. If the waiting time exceeds the preset waiting time, the corresponding response timeout processing is executed.

[0139] S720: When block lock voting information of the business node of the business object to be processed is received, first voting content is extracted from the block lock voting information, and the first voting content is synthesized to obtain first voting information of the shadow node, and then a first voting notification is generated.

[0140] In the embodiment of the present application, the first voting information is the voting information for the relevant proposal generated by the shadow node. Among them, the voting information of the shadow node in the embodiment of the present application is generated by extracting the first voting content from the block-locked voting information of the business node of the business object to be processed, so that the shadow node can follow the vote of the business node of the business object to be processed and increase the voting weight of the business node of the business object to be processed. Specifically, when the shadow node receives the block-locked voting information of the business node of the business object to be processed, the embodiment of the present application extracts the voting content of the business node of the business object to be processed 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 a corresponding first voting notification.

[0141] For example, in a digital collectibles trading scenario, consensus verification of the validity of the relevant transaction behavior is required during the digital collectibles trading process. Nodes of pending business objects with greater stakes or higher reliability have a higher voice in the voting verification process, i.e., a higher voting weight. Therefore, in embodiments of the present application, corresponding business node groups are configured so that the corresponding pending business objects occupy corresponding voting weights. Accordingly, when a shadow node in a business node group becomes a proposal node and completes the broadcast of the corresponding proposal notification, the shadow node receives block lock voting information from the business node of the pending business object in real time within a preset waiting time. When the shadow node receives the corresponding block lock voting information within the preset waiting time, embodiments of the present application extract voting information of the business node of the pending business object from the block lock voting information, such as relevant verification voting information, vote count information, signature information, voting round number, etc. Furthermore, embodiments of the present application combine 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.

[0142] S730: Broadcast the first voting notification to each node.

[0143] In the embodiment of the present application, the first voting notification is a voting notification generated by the shadow node based on the block-locked voting information of the business node of the business object to be processed. The embodiment of the present application is based on the relevant voting information extracted from the situation-locked voting information of the business node of the business object to be processed, and generates a voting notification of the shadow node, that is, the first voting notification. Then, the shadow node sends the first voting notification to each node in the blockchain network in a broadcast manner. For example, after the shadow node generates its own voting notification according to the instructions of the business node of the business object to be processed, 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 the business node of the business object to be processed to which it is associated, the voting result of the shadow node is consistent with the business node of the business object to be processed, thereby increasing the voting weight of the business node of the business object to be processed.

[0144] In order to alleviate the problem that the shadow node fails to receive the block lock voting information of the business node of the business object to be processed in time, resulting in the shadow node being unable to complete the pre-voting, in some feasible embodiments, the block data processing method provided in the embodiment of the present application may further include S810:

[0145] S810: When the block lock voting information of the business node of the pending business object is not received within the preset waiting time, 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.

[0146] In the embodiment of the present application, the default configuration information refers to the default content of the pre-vote (Prevote) pre-configured in the shadow node. For example, the pre-vote default content is configured during the initialization configuration process of the shadow node so that when the shadow node does not receive the block lock voting information of the business node of the pending business object within the range of the preset waiting time, it can complete the voting according to the default configuration information. Specifically, in the embodiment of the present application, the range of the preset waiting time is the timeout time for triggering the pre-vote (Prevote), that is, the timeout time for responding to the block lock voting information of the business node of the pending business object. When the shadow node does not receive the block lock voting information of the business node of the pending business object within the range of the preset waiting time, the shadow node generates a corresponding second voting notification according to its pre-configured pre-vote 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 lock voting information, resulting in the shadow node being unable to complete the pre-vote, and improving the operating efficiency of the blockchain network.

[0147] For example, 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). Therefore, 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 interests. Accordingly, the embodiment of the present application configures the corresponding business node group according to the voting weight requirements of different pending business objects. When the shadow node of the relevant business node group needs to vote, the block lock voting information of the business node of the pending business object is first obtained within the scope of the preset waiting time to generate the corresponding voting notification. When the shadow node does not receive the corresponding block lock voting information within the scope of the preset waiting time, that is, the block lock voting information reception response times out, at this time, the shadow node generates a 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.

[0148] To further achieve consistency in processing behavior between the shadow node and the business node of the pending business object and improve the voting weight of the business node of the pending business object, in some feasible embodiments, in response to the block lock voting information sent by the business node of the pending business object, the shadow node extracts the first voting content from the block lock voting information and performs block lock processing on the proposal notification, which may also include but is not limited to S910 to S920:

[0149] S910: When the shadow node is not a proposal node, it waits for proposal notifications from other nodes within a preset waiting time.

[0150] In the embodiments of the present application, "other nodes" are nodes in the blockchain network other than the shadow node. When a shadow node is not a proposal node, it waits for proposals from other nodes in the blockchain network for a certain period of time, i.e., within a preset waiting time. For example, upon entering a new height, the shadow node first determines whether it is a proposal node for that height. If it determines that it is not a proposal node for that height, the shadow node enters a waiting state, awaiting proposal information from other nodes in the blockchain network for a preset waiting time.

[0151] S920: When the proposal notification received by the shadow node comes from the business node of the business object to be processed, 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.

[0152] In the embodiment of the present application, the business node of the business object to be processed refers to the business node of the business object to be processed associated with the shadow node. In the embodiment of the present application, the default configuration information refers to the default voting content configured when the shadow node is initialized. When the proposal node is the business node of the business object to be processed associated with the shadow node, the embodiment of the present application generates corresponding voting information through the default voting content. Specifically, in the embodiment of the present application, when the shadow node receives a proposal notification from the business node of the business object to be processed, 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 business node of the business object to be processed.

[0153] As shown in Figure 10, a schematic diagram of the consensus process in a four-node environment, when the business node of the pending business object serves as the proposal node for this round. In the figure, Node 2 and Node 1 form a business node group. Node 1 is the business node of the pending business object, and Node 2 is a shadow node associated with Node 1. For example, in a blockchain shared state update scenario, when the blockchain's protocols or rules change, blockchain network nodes can vote to decide whether to accept these changes and update the blockchain's state. Accordingly, different blockchain network nodes may have different voting weights and different numbers of shadow nodes in their business node groups. When a shadow node does not serve as a proposal node, it simply receives proposal information from other nodes in the blockchain network. When a shadow node receives a proposal notification from the business node of the pending business object within a preset waiting time, it directly generates a default voting notification based on the corresponding default configuration information and broadcasts it to each node in the blockchain network. The default configuration information is already initialized and configured when the target business node is constructed. By generating a third voting notification based on the default configuration information, the embodiments of the present application can effectively improve the operational efficiency of the blockchain network.

[0154] In order to further achieve consistency in processing behavior between the shadow node and the business node of the pending business object and improve the voting weight of the business node of the pending business object, in some feasible embodiments, in response to the block lock voting information sent by the business node of the pending business object, the shadow node extracts the first voting content from the block lock voting information and performs block lock processing on the proposal notification. This step may also include but is not limited to S1010 to S1020:

[0155] S1010: When the proposal notification received by the shadow node does not come from the business node of the business object to be processed, the shadow node receives the block lock voting information of the business node of the business object to be processed in real time within the preset waiting time.

[0156] In the embodiment of the present application, the range of the preset waiting time is the timeout time of the trigger pre-vote (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 the trigger pre-vote. Specifically, when the block consensus enters a new height, the shadow node first determines whether it is a proposal node at that height. After determining 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 receiving the proposal notification, the shadow node analyzes the source of the proposal information. When it is determined that the proposal notification does not come from the business node of the business object to be processed, the pre-vote of the shadow node needs to be executed according to the instructions of the business node of the business object to be processed. At this time, the shadow node receives the block lock voting information of the business node of the business object to be processed in real time within the range of the preset waiting time. For example, taking a digital financial asset transaction application scenario as an example, when the shadow node of the target object of the relevant digital financial asset receives a proposal notification from other digital financial assets in the blockchain network, that is, a proposal notification not from the business node of the business object to be processed corresponding to the shadow node, then the shadow node needs to obtain the block lock voting information of the business node of the business object to be processed to generate the corresponding voting information, so as to maintain consistency with the processing behavior of the business node of the business object to be processed. Accordingly, the shadow node obtains the block lock voting information of the business node of the business object to be processed within the timeout period of triggering the pre-vote, that is, within the range of the preset waiting time. It is easy to understand that when the shadow node does not receive the relevant indication information of the business node of the business object to be processed within the range of the preset waiting time, the corresponding response timeout processing is performed according to the default configuration information.

[0157] S1020: When the block lock voting information of the business node of the pending business object is received within the preset waiting time, a fourth voting notification is generated and broadcast to each node.

[0158] In the embodiments of the present application, the fourth voting notification is the voting information generated by the shadow node for the relevant proposal based on the block-locked voting information. In this embodiment, the shadow node's voting notification is generated by extracting voting content from the block-locked voting information of the business node of the pending business object, allowing the shadow node to follow the vote of the business node of the pending business object and increase the voting weight of the business node of the pending business object. Specifically, when the shadow node receives the block-locked voting information of the business node of the pending business object within a preset waiting time, the embodiment of the present application extracts the relevant voting content of the business node of the pending business object from the block-locked voting information. The shadow node then synthesizes the extracted voting content of the business node of the pending business object to obtain the shadow node's voting notification, i.e., the fourth voting notification. The shadow node then broadcasts the fourth voting notification to each node in the blockchain network, completing the voting. For example, in a blockchain decision management application scenario, in some decentralized autonomous organizations or blockchain projects, nodes of different pending business objects may have different interests and perspectives. By assigning different voting weight ratios to different pending business objects, it is possible to ensure that nodes participating in the consensus have different influence in the decision-making process. Accordingly, when the shadow nodes of the pending 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 business node of the pending business object, it needs to receive the block lock voting information from the business node of the pending business object within the preset waiting time to generate the corresponding voting notification. After the shadow node obtains the block lock voting information of the business node of the associated pending business object within the preset waiting time, the shadow node extracts the corresponding voting content based on 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 business node of the pending business object. Therefore, the voting processing behavior of the shadow node is consistent with the business node of the pending business object, which effectively improves the influence of the vote of the corresponding pending business object.

[0159] For example, refer to Figure 11, which is a flow chart of the consensus processing and pre-voting phases of the shadow node in an embodiment of the present application. In this embodiment of the present application, after the shadow node broadcasts the corresponding proposal notification to other nodes, it waits for the voting information broadcast by the business node of the pending business object, i.e., the block lock voting information. At the same time, after the business node of the pending business object receives the proposal notification broadcast by the shadow node, it generates corresponding block lock voting information and sends it to the shadow node. Accordingly, after the shadow node receives the block lock voting information from the business node of the pending business object, it first parses the block lock voting information to obtain the voting information therein, i.e., the first voting content, and generates new voting information, i.e., the first voting notification. The shadow node then broadcasts this row of voting information to other nodes. In addition, if the shadow node does not receive the voting information, i.e., the block lock voting information, from the business node of the pending business object within a preset waiting time, the response is considered to have timed out. At this point, the shadow node generates corresponding default pre-voting information, i.e., the second voting notification, based on the preset default configuration information, and broadcasts it to each node in the blockchain network. When the shadow node is not a proposal node of that height, the shadow node will first wait for proposals from other nodes within a certain period of time. After the shadow node receives the proposal information sent by the relevant node, the shadow node will first verify the source of the received proposal information to determine whether the proposal comes from the business node of the business object to be processed that is associated with it. When it is determined that the proposal comes from the business node of the associated business object to be processed, the shadow node will directly generate the corresponding voting information, i.e., the third voting notification, according to the preset default configuration information, and broadcast it to each node. On the contrary, when it is determined that the proposal does not come from the business node of the associated business object to be processed, the shadow node will enter a waiting state, waiting for the pre-voting information sent by the business node of the associated business object to be processed, i.e., the block lock voting information, so as to perform the processing behavior consistent with the business node of the business object to be processed according to the relevant block lock voting information.

[0160] In order to enable the shadow node to maintain consistency in processing behavior with the business node of the business object to be processed and implement block submission phase processing, in some feasible embodiments, in response to the block submission voting information sent by the business node of the business object to be processed, the node extracts the second voting content from the block submission voting information and performs block submission processing. This step may include but is not limited to S1110 to S1140:

[0161] S1110: Obtain block locking voting information of other nodes.

[0162] The block lock voting information in the embodiment of the present application comes from each node in the blockchain network. After 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 application, 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 pending business object generates a voting notification based on the block lock voting information of the business node of the corresponding pending business object, 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 application, it is necessary to collect a preset number of pre-voting information before entering the block lock, for example, receiving votes greater than 2 / 3 of the number of nodes.

[0163] S1120: After obtaining the block locking voting information of the other nodes, receiving the block submission voting information of the business node of the pending business object in real time within a preset waiting time.

[0164] In the embodiment of the present application, the range of the preset waiting time refers to the timeout time for triggering the pre-commit (Precommit), that is, the block submission voting information response timeout time of the business node receiving the business object to be processed. Specifically, in the embodiment of the present application, after obtaining the block lock voting information of other nodes, the shadow node waits for the block submission voting information broadcast by the business node of the business object to be processed within the range of the preset waiting time, so as to generate a corresponding voting notification according to the block submission voting information of the business node of the business object to be processed, thereby realizing the block submission phase processing and maintaining the consistency of the processing behavior of the business node of the business object to be processed. 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 phase, to each node, it enters the pre-commit (Precommit) phase. The shadow node first obtains the block lock voting information of each node in the block network. Then, within the preset timeout period for triggering pre-submission, the shadow node receives in real time the block submission voting information of the business node of the pending business object, that is, the voting information submitted for the block after the locked block exists in the business node of the pending business object. In this embodiment of the present application, the block voting information submitted by the shadow node is extracted from the block voting information sent by the business node of the pending business object, and a consensus on the situation information is completed based on the extracted block locking processing results of each node, so that the voting behavior of the shadow node is consistent with that of the business node of the pending business object.

[0165] S1130: When the block submission voting information of the business node of the pending business object is received within the preset waiting time, 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.

[0166] In the embodiment of the present application, the second voting content includes the results of the block locking processing of each node, that is, the block locking processing results of each node received by the business node of the business object to be processed. Specifically, in the implementation of the present application, when the shadow node receives the block submission voting information sent by the business node of the business object to be processed within the preset waiting time, the shadow node parses the block voting information to extract the corresponding voting content, that is, the second voting content, and thus generates new voting information based on the second voting content, obtains the second voting information of the shadow node, and generates the corresponding fifth voting notification. For example, taking a digital financial asset application scenario as an example, the embodiment of the present application constructs a corresponding business node group so that the corresponding digital financial asset business object to be processed has a higher voice, that is, a higher voting weight. Accordingly, when the shadow node of the pending digital financial asset business object receives the block voting information (i.e., Precommit information) from the business node of the pending business object within the preset timeout period for triggering pre-commit, the shadow node parses the block voting information and extracts relevant voting content, such as the block lock processing results of each node. Based on the extracted voting content, the shadow node then synthesizes the corresponding shadow node voting information (i.e., the second voting information), and then generates a voting notification for the shadow node. It is easy to understand that this voting notification corresponds to the voting information of the business node of the pending business object, thereby maintaining consistency with the processing behavior of the business node of the pending business object during the block commit phase.

[0167] S1140: Broadcast the fifth voting notification to each node.

[0168] In the embodiment of the present application, after the shadow node generates the fifth voting notification based on the block submission voting information of the business node of the pending business object, 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 (Precommit) stage. At this time, the shadow node obtains the block submission voting information of the business node of the pending business object in real time within the preset waiting time range, and submits the voting information according to the situation of the business node of the pending business object to generate the corresponding fifth voting notification. Furthermore, after the shadow node generates the corresponding fifth voting notification according to the instruction of the business node of the pending business object, it sends it to each node in the blockchain network in a broadcast manner for voting, thereby realizing the block submission function.

[0169] In order to alleviate the problem that the shadow node fails to receive the block submission voting information of the business node of the business object to be processed in time, resulting in the shadow node being unable to complete the pre-submission, in some feasible embodiments, the block data processing method provided in the embodiment of the present application may further include S1210:

[0170] S1210: When the block submission voting information of the business node of the pending business object is not received within the preset waiting time, 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.

[0171] In the embodiment of the present application, the default configuration information includes the default content of pre-commit. During the shadow node initialization process, the embodiment of the present application configures the default content of the shadow node pre-commit, that is, the default content submitted by the shadow node after the shadow node receives the block submission voting information response of the business node of the pending business object and the timeout occurs. Specifically, in the embodiment of the present application, when the shadow node does not receive the block submission voting information of the business node of its associated pending business object within the preset waiting time, 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 business node group of the corresponding digital collection target object does not receive the block submission voting information sent by the business node of the corresponding pending business object within the preset waiting time, in order to complete the pre-commit in time, the shadow node directly generates a default voting notification, that is, the sixth voting notification, according to the pre-configured default configuration information. Then, the shadow node broadcasts the default voting notification to each node to complete the pre-submission function, and effectively alleviates the problem that the shadow node cannot complete the pre-submission due to failing to receive the block submission voting information of the business node of the business object to be processed in time.

[0172] For example, refer to Figure 12, which is a flow chart of the consensus processing and pre-commitment phase of the shadow node in an embodiment of the present application. In the embodiment of the present application, after broadcasting the corresponding voting notification to each node, the shadow node obtains the block lock voting information of other nodes, i.e., the pre-voting information. It is easy to understand that at a certain height and round number, after a node receives a pre-voting set for a block that exceeds 2 / 3 of the total number of nodes, the node locks the block at this height and round. Therefore, in the embodiment of the present application, it is necessary to collect 2f+1 pre-voting tickets. Here, f is the number of abnormal nodes in the network, i.e., the number of malicious nodes. Next, the shadow node waits for the pre-commit voting information, i.e., the block commit voting information, broadcast by the business node of the pending business object. Upon receiving the block commit voting information sent by the business node of the pending business object, the shadow node parses the block commit voting information to obtain the corresponding voting content, i.e., the second voting content, thereby generating new pre-commit voting information, i.e., the fifth voting notification, and broadcasts it to other nodes. Accordingly, if the shadow node does not receive the pre-submission voting information (i.e., block submission voting information) from the business node of the pending business object within the preset waiting time, it is considered that the response has timed out. At this time, the shadow node of the embodiment of the present application generates the default pre-submission voting information (i.e., the sixth voting notification) based on the preset default configuration information and broadcasts it to each node in the blockchain network.

[0173] For example, 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:

[0174] Referring to Figure 13, a schematic diagram of the overall consensus processing flow for shadow nodes in a block data processing method provided as a specific example is provided. After constructing a business node group comprising a corresponding number of business nodes and shadow nodes for the pending business object, the corresponding node consensus process can be performed using the business nodes and shadow nodes of the pending business object in the business node group. Specifically, upon entering a new height, the shadow node first determines whether it is a proposal node for that height. Once it determines that it is a proposal node, it waits for proposal information to be sent from the business node of its corresponding pending business object. Next, upon receiving the relevant proposal information, the shadow node first verifies the source of the proposal information to confirm that it originates from the business node of the pending business object associated with the shadow node. If verification succeeds, i.e., confirming that the proposal information originates from the business node of the pending business object, the shadow node parses the proposal information to obtain the corresponding block information, generates a new proposal notification based on the block information, and broadcasts the proposal notification to other nodes in the blockchain network. Conversely, if verification indicates that the proposal information does not originate from the business node of the pending business object, this is considered a reception error and the proposal information is discarded. Additionally, if a shadow node does not receive a proposal within the preset waiting time while waiting for the corresponding business node to process the business object, it will be considered a response timeout. At this point, the shadow node will generate a default proposal notification based on the pre-configured default configuration information and broadcast it to each node in the blockchain network. Furthermore, if the shadow node determines that the proposing node at that height is not itself, it will enter a waiting state, waiting for proposal information broadcast by other nodes within a certain period of time.

[0175] Then, after the shadow node broadcasts the corresponding proposal notification to each other node, the shadow node enters a waiting state, waiting for the voting information broadcast by the business node of the corresponding pending business object, namely the block lock voting information. In addition, after the shadow node receives the block lock voting information sent by the business node of the corresponding pending business object, it first parses the block lock voting information to obtain the relevant voting information, namely the first voting content, and then generates new voting information based on the voting information, namely the first voting information. At the same time, when the shadow node times out while waiting for the block lock voting information of the business node of the pending business object, that is, it does not receive the relevant voting information of the business node of the pending business object within the preset waiting time, the shadow node generates default pre-voting information according to the default configuration information, namely the second voting notification, and broadcasts it to each node in the blockchain network. Accordingly, when the shadow node is not a proposal node and receives 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 business node of the pending business object. If the proposal notification is determined to be from the business node of the pending business object, the shadow node directly generates default voting information based on the pre-configured default configuration information, namely the third voting notification, and broadcasts it to other nodes. Conversely, if the proposal node is determined not to be from the business node of the pending business object, the shadow node enters a waiting state, waiting for the block lock voting information broadcast by the corresponding business node of the pending business object. It then generates the corresponding voting information (voting notification) based on the block lock information of the business node of the pending business object and broadcasts it to each node in the blockchain network.

[0176] After the shadow node broadcasts the generated voting information to each node, it first obtains the block lock voting information of other nodes, i.e., pre-voting information. For example, the shadow node needs to collect 2f+1 pieces of block lock voting information. Here, f refers to the number of nodes allowed to act maliciously 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, i.e., block submission information, broadcast by the business node of its associated pending business object, 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 parsed voting content, i.e., the second voting content, and broadcasts it to other nodes in the blockchain network. Accordingly, if the shadow node does not receive the block submission information from the business node of the pending business object within the preset waiting time, it is considered that the response has timed out. At this time, the shadow node generates the corresponding default voting information, i.e., the sixth voting notification, based on 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.

[0177] As shown in FIG14 , an embodiment of the present application further provides a block data processing device, which is deployed on an electronic device and includes:

[0178] An acquisition module 1310 is used to obtain the voting rights requirements of the business object to be processed;

[0179] The first module 1320 is configured to construct a business node group based on the voting rights requirements of the business object to be processed. The business node group includes the business node of the business object to be processed and at least one shadow node of the business node. The business node of the business object to be processed is configured to perform block data processing based on stored block ledger data. The block data processing performed by the shadow node is consistent with the block data processing performed by the business node of the business object to be processed. The shadow node does not store the block ledger data for block data processing.

[0180] In one possible implementation, the first module 1320 includes:

[0181] The first unit is configured to configure one or more shadow nodes for the business node of the business object to be processed according to the voting rights requirements of the business object to be processed;

[0182] The second unit is used to perform initial information configuration on each shadow node, and combine the configured shadow node with the service node of the business object to be processed to obtain a service node group of the business object to be processed.

[0183] In a possible implementation, the second unit includes:

[0184] A first subunit is used to configure node mapping information between shadow nodes and service nodes of the business object to be processed, where the node mapping information represents the association relationship between each shadow node and the service node corresponding to the business object to be processed;

[0185] The second subunit is used to configure the 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 it does not receive an instruction from the business node of the business object to be processed;

[0186] The third subunit is used to configure the response timeout information of the shadow node.

[0187] With reference to FIG14 , the specific implementation process of the block data processing device provided by this application is described: an acquisition module 1310 obtains the voting rights requirements of a pending business object; a first module 1310 constructs a business node group based on the voting rights requirements of the pending business object. Specifically, the business node group includes the business node of the pending business object and at least one shadow node. The business node of the pending business object is responsible for performing block data processing based on stored block ledger data. The block data processing performed by the shadow node is consistent with the block data processing performed by the business node of the pending business object, and the shadow node does not store the block ledger data for block data processing. In this way, the shadow node can perform proposal processing, block locking processing, or block submission processing according to the instructions of the business node of the pending business object, thereby achieving consensus on block information. As a result, the shadow node does not need to store relevant ledger data of the blockchain network and can execute processing actions consistent with or defaulted to the business node of the pending business object, reducing resource usage by high-weighted business objects and improving the operational efficiency of the blockchain network.

[0188] An embodiment of the present application further provides a block data processing device, which is deployed on a shadow node and includes a second module 1330 for extracting block information from the proposal information, performing proposal processing, and generating a proposal notification in response to proposal information sent by a business node of a pending business object. The proposal notification is used to trigger each node to perform block locking processing, wherein the business node and shadow node of the pending business object are located in a business node group of the pending business object, and the business node group of the pending business object is constructed based on the method described in any of the aforementioned embodiments.

[0189] The third module 1340 is configured to extract first voting content from the block locking voting information in response to the block locking voting information sent by the business node of the business object to be processed, and perform block locking processing on the proposal notification using the first voting content.

[0190] Fourth module 1350 is configured to, in response to the block submission voting information sent by the business node of the business object to be processed, extract second voting content from the block submission voting information, and use the second voting content to perform block submission processing to achieve consensus on the block information. The second voting content includes the results of the block locking processing of each node.

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

[0192] In one possible implementation, the second module 1330 includes:

[0193] The third unit is used to receive proposal information of the business node of the business object to be processed in real time within a preset waiting time range when the shadow node becomes a proposal node;

[0194] The fourth unit is used to extract block information from the proposal information when receiving the proposal information of the business node of the business object to be processed, synthesize the block information to obtain the secondary proposal of the shadow node, and generate a proposal notification.

[0195] In one possible implementation, the block data processing device in the embodiment of the present application further includes:

[0196] 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 business node of the business object to be processed is received within the preset waiting time.

[0197] In one possible implementation, the block data processing device in the embodiment of the present application further includes:

[0198] The fifth unit is used to broadcast the proposal notification to each node;

[0199] The third module includes:

[0200] The sixth unit is used to receive block lock voting information of the business node of the pending business object 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;

[0201] The seventh unit is configured to, upon receiving block lock voting information of a business node of a business object to be processed, extract first voting content from the block lock voting information, synthesize the first voting content to obtain first voting information of a shadow node, and generate a first voting notification;

[0202] The eighth unit is used to broadcast the first voting notification to each node.

[0203] In one possible implementation, the block data processing device in the embodiment of the present application further includes:

[0204] 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 business node of the business object to be processed is not received within the preset waiting time, and broadcast the second voting notification to each node.

[0205] In one possible implementation, the block data processing device in the embodiment of the present application further includes:

[0206] The fifth unit is used to broadcast the proposal notification to each node;

[0207] The third module includes:

[0208] The ninth unit is used when the shadow node is not a proposal node and waits for proposal notifications from other nodes within the preset waiting time range;

[0209] 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 business node of the business object to be processed, and broadcast the third voting notification to each node.

[0210] In one possible implementation, the block data processing device in the embodiment of the present application further includes:

[0211] The eleventh unit is used to receive the block lock voting information of the business node of the pending business object in real time within a preset waiting time range when the proposal notification received by the shadow node does not come from the business node of the pending business object;

[0212] The twelfth unit is configured to generate a fourth voting notification and broadcast the fourth voting notification to each node when receiving the block locking voting information of the business node of the pending business object within a preset waiting time.

[0213] In one possible implementation, the fourth module includes:

[0214] Unit 13 is used to obtain block locking voting information of other nodes;

[0215] The fourteenth unit is used to receive the block submission voting information of the business node of the pending business object in real time within a preset waiting time after obtaining the block locking voting information of other nodes;

[0216] The fifteenth unit is configured to, upon receiving block submission voting information of a business node of a pending business object within a preset waiting time, extract the second voting content from the block submission voting information, synthesize the second voting content to obtain the second voting information of the shadow node, and generate a fifth voting notification;

[0217] The sixteenth unit is used to broadcast the fifth voting notification to each node.

[0218] In one possible implementation, the block data processing device in the embodiment of the present application further includes:

[0219] 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 business node of the business object to be processed is not received within the preset waiting time, and broadcast the sixth voting notification to each node.

[0220] The present application also provides a block data processing device for a blockchain network, wherein the blockchain network includes multiple nodes and the device is deployed on an electronic device, including:

[0221] A determination module, configured to determine a business node of a business object to be processed from multiple nodes in a blockchain network;

[0222] A calculation module, configured to calculate the number of shadow nodes to be configured for the business node of the business object to be processed based on the voting weight expected to be achieved by the business node of the business object to be processed and the number of nodes in the blockchain network;

[0223] A configuration module, configured to configure shadow nodes for business nodes of services to be processed according to the number of shadow nodes;

[0224] Among them, the business node of the business object to be processed saves the block ledger data of the block data processing, the block data processing performed by the shadow node remains consistent with the block data processing of the business node of the business object to be processed, and the shadow node does not save the block ledger data of the block data processing.

[0225] In one possible implementation, the configuration module is configured to:

[0226] Configuring node mapping information between the shadow node and the service node of the business object to be processed, wherein the node mapping information represents an association relationship between each shadow node and the service node of the business object to be processed;

[0227] 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 from the service node of the service object to be processed;

[0228] Configure the response timeout information of the shadow node.

[0229] As shown in Figure 15, an embodiment of the present application also 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 business data processing software system provided by the embodiment of the present application, such as a personal computer (Personal Computer, PC), a mobile phone, a smart phone, a personal digital assistant (Personal Digital Assistant, PDA), a wearable device, a handheld computer PPC (Pocket PC), a tablet computer, a car terminal, etc.

[0230] It can be understood that the contents of the block data processing method embodiment shown above are all applicable to the embodiment of this electronic device. The functions specifically implemented by this 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.

[0231] The present application also provides a computer-readable storage medium storing a computer program, which is executed by a processor to implement the aforementioned block data processing method. Furthermore, the present application also provides a computer program product comprising a computer program stored in a computer-readable storage medium. A processor of an electronic device can read the computer program from the computer-readable storage medium and execute the computer program, causing the electronic device to perform the aforementioned block data processing method.

[0232] It can be understood that the contents of the block data processing method embodiment shown above are all applicable to the embodiment of this computer-readable storage medium. The functions specifically implemented by this 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.

[0233] It can be understood that the contents of the block data processing method embodiment shown above are all applicable to the embodiment of this computer program product. The functions specifically implemented by this computer program product 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.

[0234] In some optional 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 embodiments presented and described in the flow chart of the present application are provided in an exemplary manner for the purpose of providing a more comprehensive understanding of the technology. The disclosed method is not limited to the operations and logical flows presented herein. Optional embodiments are contemplated in which the order of the various operations is changed and the sub-operations described as a part of a larger operation are performed independently.

[0235] From the embodiments provided in the above description, it can be clearly seen that the technical solution of the present application has at least the following beneficial effects:

[0236] In some optional 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 embodiments presented and described in the flow chart of the present application are provided in an exemplary manner for the purpose of providing a more comprehensive understanding of the technology. The disclosed method is not limited to the operations and logical flows presented herein. Optional embodiments are contemplated in which the order of the various operations is changed and the sub-operations described as a part of a larger operation are performed independently.

[0237] In addition, although the present application is described in the context of functional modules, it is understood that, unless otherwise stated, 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 not necessary for understanding the present application. More specifically, given the properties, functions, and internal relationships of the various functional modules in the devices disclosed herein, the actual implementation of the module will be understood within the routine skills of an engineer. Therefore, a person skilled in the art can implement the present application as set forth in the claims using ordinary techniques without undue experimentation. It is also understood that the specific concepts disclosed are merely illustrative and are not intended to limit the scope of the present application, which is determined by the full scope of the appended claims and their equivalents.

[0238] 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 application, 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 and includes a number of instructions for enabling an electronic device (which can be a personal computer, a server, or a network device, etc.) to execute all or part of the steps of the method described in each embodiment of the present application. The aforementioned storage medium includes various media that can store program codes, such as a USB flash drive, a mobile hard disk, a read-only memory (ROM), a random access memory (RAM), a magnetic disk or an optical disk.

[0239] The logic and / or steps represented in the flowcharts or otherwise described herein, for example, can be considered as an ordered list of executable instructions for implementing the logical functions, and can be embodied in any computer-readable medium for use by, or in conjunction with, an instruction execution system, apparatus, or device (e.g., a computer-based system, a system including a processor, or other system that can fetch and execute instructions from an instruction execution system, apparatus, or device). For purposes of this specification, a "computer-readable medium" can be any device that can contain, store, communicate, propagate, or transport a program for use by, or in conjunction with, an instruction execution system, apparatus, or device.

[0240] More specific examples (a non-exhaustive list) of computer-readable media include the following: an electrical connection with one or more wires (electronic devices), a portable computer disk cartridge (magnetic devices), a random access memory (RAM), a read-only memory (ROM), an erasable and programmable read-only memory (EPROM or flash memory), a fiber optic device, and a portable compact disc read-only memory (CDROM). In addition, the computer-readable medium may even be 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 processing in another suitable manner as necessary, and then stored in a computer memory.

[0241] It is understood that various parts of the present application can be implemented using hardware, software, firmware, or a combination thereof. In the above embodiments, multiple steps or methods can be implemented using software or firmware stored in a memory and executed by a suitable instruction execution system. For example, if implemented using hardware, as in another embodiment, any one of the following technologies known in the art or a combination thereof can be used to implement: a discrete logic circuit having a logic gate circuit for implementing a logic function on a data signal, an application-specific integrated circuit having a suitable combination of logic gate circuits, a programmable gate array (PGA), a field programmable gate array (FPGA), etc.

[0242] Throughout this specification, reference to terms such as "one embodiment," "some embodiments," "examples," "specific examples," or "some examples" means that a specific feature, structure, material, or characteristic described in conjunction with that embodiment or example is included in at least one embodiment or example of the present application. In this specification, schematic representations of the above terms do not necessarily refer to the same embodiment or example. Furthermore, the specific features, structures, materials, or characteristics described may be combined in any suitable manner in any one or more embodiments or examples.

[0243] Although the embodiments of the present application have been shown and described, those skilled in the art will appreciate that various changes, modifications, substitutions, and variations may be made to the embodiments without departing from the principles and intent of the present application, and that the scope of the present application is defined by the claims and their equivalents.

[0244] The above is a specific description of the preferred implementation of the present application, but the present application is not limited to the embodiments. Those skilled in the art may make various equivalent modifications or substitutions without violating the spirit of the present application, and these equivalent modifications or substitutions are all included in the scope defined by the claims of the present application.

Claims

1. A block data processing method, the method being executed by an electronic device, comprising: Get the voting rights requirements of the business object to be processed; According to the voting right requirements of the business object to be processed, a business node group of the business object to be processed is constructed; wherein the business node group includes the business node of the business object to be processed and at least one shadow node corresponding to the business node; The business node of the business object to be processed is used to perform 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 business node of the business object to be processed, and the shadow node does not save the block ledger data of the block data processing.

2. The block data processing method according to claim 1, wherein the step of constructing the business node group of the business object to be processed according to the voting right requirements of the business object to be processed comprises: According to the voting right requirements of the business object to be processed, one or more shadow nodes are configured for the business node of the business object to be processed; Initial information is configured for each of the shadow nodes, and the configured shadow nodes are combined with the service nodes of the service object to be processed to obtain a service node group of the service object to be processed.

3. The block data processing method according to claim 2, wherein the initial information configuration for each shadow node comprises: Configuring node mapping information between the shadow node and the service node of the service object to be processed, wherein the node mapping information represents an association relationship between each shadow node and the service node corresponding to the service object to be processed; Configuring 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 the shadow node does not receive an instruction issued by the service node of the service object to be processed; Configure the response timeout information of the shadow node.

4. A block data processing method, the method being executed by a shadow node, comprising: In response to proposal information sent by a business node of a business object to be processed, extract block information from the proposal information for proposal processing and generate a proposal notification; The proposal notification is used to trigger each node to perform block locking processing, the business node of the business object to be processed and the shadow node are located in the business node group of the business object to be processed, and the business node group of the business object to be processed is constructed based on the method described in any one of claims 1 to 3; In response to the block locking voting information sent by the business node of the business object to be processed, extracting first voting content from the block locking voting information, and performing block locking processing on the proposal notification using the first voting content; In response to the block submission voting information issued by the business node of the business object to be processed, extract the second voting content from the block submission voting information, and use the second voting content to perform block submission processing to complete the consensus on the block information; wherein the second voting content includes the result of the block locking processing of each node.

5. The block data processing method according to claim 4, wherein the step of responding to the proposal information sent by the business node of the business object to be processed, extracting the block information from the proposal information for proposal processing, and generating a proposal notification comprises: When the shadow node becomes a proposal node, it receives proposal information of the business node of the business object to be processed in real time within a preset waiting time; When the proposal information of the business node of the business object to be processed 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 then a proposal notification is generated.

6. The block data processing method according to claim 5, further comprising: When the proposal information of the business node of the to-be-processed business object is not received within the preset waiting time, a default proposal notification is generated according to the default configuration information of the shadow node.

7. The block data processing method according to claim 5, further comprising: Broadcast the proposal notification to each node; The step of extracting first voting content from the block locking voting information in response to the block locking voting information sent by the business node of the business object to be processed, and performing block locking processing on the proposal notification using the first voting content includes: When the shadow node is a proposal node, after broadcasting the proposal notification to each node, the block locking voting information of the business node of the pending business object is received in real time within the preset waiting time; When receiving the block lock voting information of the business node of the to-be-processed business object, 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. The block data processing method according to claim 7, further comprising: When the block lock voting information of the business node of the pending business object is not received within the preset waiting time, 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. The block data processing method according to claim 5, further comprising: Broadcast the proposal notification to each node; The step of extracting first voting content from the block locking voting information in response to the block locking voting information sent by the business node of the business object to be processed, and performing block locking processing on the proposal notification using the first voting content includes: When the shadow node is not a proposal node, wait for proposal notifications from other nodes within the preset waiting time; When the proposal notification received by the shadow node comes from the business node of the business object to be processed, 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. The block data processing method according to claim 9, further comprising: When the proposal notification received by the shadow node does not come from the business node of the business object to be processed, the block locking voting information of the business node of the business object to be processed is received in real time within the preset waiting time; When the block locking voting information of the business node of the to-be-processed business object is received within the preset waiting time, a fourth voting notification is generated and broadcasted to each node.

11. The block data processing method according to claim 4, wherein in response to the block submission voting information sent by the business node of the business object to be processed, extracting second voting content from the block submission voting information, and performing block submission processing using the second voting content, comprises: Get the block lock voting information of other nodes; After obtaining the block locking voting information of the other nodes, receiving the block submission voting information of the business node of the business object to be processed in real time within a preset waiting time; When the block submission voting information of the business node of the to-be-processed business object is received within the preset waiting time, 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. The block data processing method according to claim 11, further comprising: When the block submission voting information of the business node of the pending business object is not received within the preset waiting time, 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 blockchain network, wherein the blockchain network includes a plurality of nodes, and the method is executed by an electronic device, comprising: Determine a business node of a business object to be processed from multiple nodes of the blockchain network; Calculate the number of shadow nodes to be configured for the business node of the business object to be processed according to the expected voting weight of the business node of the business object to be processed and the number of nodes of the blockchain network; According to the number of shadow nodes, a shadow node is configured for the service node of the service to be processed; Among them, the business node of the business object to be processed saves the block ledger data of the block data processing, the block data processing performed by the shadow node is consistent with the block data processing of the business node of the business object to be processed, and the shadow node does not save the block ledger data of the block data processing.

14. The block data processing method according to claim 13, wherein configuring shadow nodes for the business nodes of the business object to be processed according to the number of shadow nodes comprises: Configuring node mapping information between the shadow node and the service node of the service object to be processed, wherein the node mapping information represents an association relationship between each shadow node and the service node of the service object to be processed; 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 the shadow node does not receive an instruction issued by the service node of the service object to be processed; Configure the response timeout information of the shadow node.

15. A block data processing device, the device being deployed on an electronic device, comprising: The acquisition module is used to obtain the voting rights requirements of the business object to be processed; The first module is used to construct a business node group of the business object to be processed according to the voting right requirements of the business object to be processed; wherein the business node group includes the business node of the business object to be processed and at least one shadow node corresponding to the business node; The business node of the business object to be processed is used to perform 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 business node of the business object to be processed, and the shadow node does not save the block ledger data of the block data processing.

16. A block data processing device, the device being deployed on a shadow node, comprising: The second module is used to respond to the proposal information sent by the business node of the business object to be processed, extract the block information from the proposal information for proposal processing, and generate a proposal notification; the proposal notification is used to trigger each node to perform block locking processing, the business node of the business object to be processed and the shadow node are located in the business node group of the business object to be processed, and the business node group of the business object to be processed is constructed based on the method described in any one of claims 1 to 3; A third module is used to extract first voting content from the block locking voting information in response to the block locking voting information sent by the business node of the business object to be processed, and perform block locking processing on the proposal notification using the first voting content; The fourth module is used to respond to the block submission voting information issued by the business node of the business object to be processed, extract the second voting content from the block submission voting information, and use the second voting content 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.

17. A block data processing device of a blockchain network, the blockchain network comprising a plurality of nodes, the device being deployed on an electronic device, comprising: A determination module, used to determine a business node of a business object to be processed from multiple nodes of the blockchain network; A calculation module, used to calculate the number of shadow nodes to be configured for the business node of the business object to be processed according to the expected voting weight of the business node of the business object to be processed and the number of nodes of the blockchain network; A configuration module, configured to configure shadow nodes for the service nodes of the service to be processed according to the number of shadow nodes; Among them, the business node of the business object to be processed saves the block ledger data of the block data processing, the block data processing performed by the shadow node is consistent with the block data processing of the business node of the business object to be processed, and the shadow node does not save the block ledger data of the block data processing.

18. An electronic device comprising 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 14.

19. A computer-readable storage medium storing a computer program, wherein the computer program is executed by a processor to implement the method according to any one of claims 1 to 14.

20. A computer program product, comprising a computer program, wherein when the computer program is executed by a processor, the method according to any one of claims 1 to 14 is implemented.

Images