Data processing method and apparatus based on blockchain, and device and medium

Abstract

Disclosed in the embodiments of the present application are a data processing method and apparatus based on a blockchain, and a device and a medium. The method comprises: acquiring a node weight update instruction which is generated for a first consensus node in a blockchain network, wherein the node weight update instruction is used for instructing the update of a node weight which is configured for the first consensus node regarding voting information in a consensus service; on the basis of the node weight update instruction, predicting whether the updated node weight of the first consensus node meets a node update condition, so as to obtain a prediction result; in response to the prediction result being positive, updating the node weight of the first consensus node according to the node weight update instruction, so as to obtain an update result; and recording the update result in a database of the blockchain network. By using the embodiments of the present application, resources consumed for deploying nodes and the difficulty in managing the nodes can be reduced.

Description

A data processing method, device, equipment and medium based on blockchain

[0001] This application claims priority to the Chinese patent application filed with the China Patent Office on July 3, 2023, with application number 202310809879.3 and application name “A Blockchain-based Data Processing Method, Device, Equipment and Medium”, the entire contents of which are incorporated by reference into this application. Technical Field

[0002] The present application relates to the field of blockchain network technology, and in particular to a blockchain-based data processing method, device, equipment, and medium. Background Art

[0003] In traditional blockchain network deployment scenarios, if certain business organizations (for example, Organization 1) desire greater decision-making power within the entire blockchain network, they need to deploy more consensus nodes specifically for Organization 1. This means increasing the number of Organization 1's nodes to increase Organization 1's participation weight. However, since each consensus node in a blockchain network maintains its own independent database, which may reside on different servers, this often requires increased computing and memory resources. For example, adding a new consensus node to a blockchain network requires configuring the new node's consensus algorithm, its network connections with existing consensus nodes, and the database it maintains. These configuration operations require significant effort. Furthermore, increasing the number of consensus nodes inevitably increases the blockchain network's consensus computation workload and network traffic, leading to increased resource consumption. Furthermore, blockchain network nodes are relatively complex programs, which means node management is also more complex. Consequently, traditional deployment methods not only increase the workload for node deployment but also increase resource consumption and the difficulty of node management.

[0004] Summary of the Invention

[0005] The embodiments of the present application provide a blockchain-based data processing method, apparatus, device, and medium, which can reduce the workload of deploying nodes without additionally increasing the resource consumption of the blockchain network and the difficulty of node management.

[0006] On the one hand, an embodiment of the present application provides a data processing method based on blockchain, including:

[0007] Obtaining a node weight update instruction generated for a first consensus node in the blockchain network, where the node weight update instruction is used to instruct an update of the node weight of voting information configured for the first consensus node in a consensus service;

[0008] Based on the node weight update instruction, predict whether the updated node weight of the first consensus node meets the node update condition and obtain the prediction result;

[0009] In response to the prediction result being positive, updating the node weight of the first consensus node according to the node weight update instruction to obtain an updated result;

[0010] Record the updated results in the blockchain network's database.

[0011] An embodiment of the present application provides, on one hand, a blockchain-based data processing device, comprising:

[0012] An acquisition module, configured to acquire a node weight update instruction generated for a first consensus node in a blockchain network, wherein the node weight update instruction is used to instruct an update of a node weight of voting information configured for the first consensus node in a consensus service;

[0013] An update processing module is used to predict whether the node weight of the updated first consensus node meets the node update condition based on the node weight update instruction, and obtain a prediction result;

[0014] The update processing module is further configured to update the node weight of the first consensus node according to the node weight update instruction in response to the prediction result being positive, to obtain an updated result;

[0015] The writing module is used to record the update results into the database of the blockchain network.

[0016] The first consensus node belongs to the N consensus nodes included in the blockchain network, where N is a positive integer;

[0017] The update processing module includes:

[0018] A list acquisition unit is used to acquire a node weight list corresponding to the blockchain network based on the node weight update instruction; the node weight list includes the node weight corresponding to each consensus node in the N consensus nodes;

[0019] A quantity determination unit, configured to determine a maximum number F of illegal nodes allowed in the blockchain network based on the N node weights and a configuration weight carried by the node weight update instruction; the configuration weight being the predicted node weight of the first consensus node after the update;

[0020] A comparison unit is used to compare the configuration weight and the maximum number F to obtain a comparison result;

[0021] The first updating unit is used to determine that the prediction result is positive if the comparison result indicates that the configuration weight is less than or equal to the maximum number F; a positive prediction result indicates that the configuration weight meets the node update condition.

[0022] The update processing module is used to update the node weight of the first consensus node according to the node weight update instruction in response to the prediction result being positive, and when obtaining the updated result, is specifically used to perform the following operations:

[0023] In response to the prediction result being positive, the node weight of the first consensus node is updated according to the configuration weight in the node weight update instruction to obtain an updated result; the configuration weight of the first consensus node in the updated result is used to update the node weight list.

[0024] The quantity determination unit includes:

[0025] The acquisition subunit is used to obtain (N-1) node weights excluding the node weight of the first consensus node from the N node weights;

[0026] The summing subunit is used to sum the (N-1) node weights and the configuration weights carried by the node weight update instruction to obtain the total node weight H corresponding to the blockchain network; H is a positive integer;

[0027] The determination subunit is used to determine the maximum number F of illegal nodes allowed by the blockchain network based on the total node weight H and the node configuration rules corresponding to the blockchain network.

[0028] Among them, the node configuration rule is H=3F+1, H is the total node weight, and F is the maximum number of illegal nodes allowed by the blockchain network.

[0029] The update processing module further includes:

[0030] The discarding unit is used to determine that the prediction result is negative and discard the node weight update instruction if the comparison result indicates that the configuration weight is greater than the maximum number F; a negative prediction result indicates that the configuration weight does not meet the node update condition.

[0031] The update processing module includes:

[0032] A first acquisition unit is configured to acquire a configuration weight carried by a node weight update instruction, and to determine by default that a prediction result is positive according to the node weight update instruction; the configuration weight is the predicted node weight of the first consensus node after the update; a positive prediction result indicates that the configuration weight satisfies a node update condition;

[0033] a second acquiring unit, configured to acquire, in response to the prediction result being positive, a node weight of the first consensus node from the blockchain network;

[0034] The second updating unit is used to update the node weight of the first consensus node to the configuration weight in the node weight update instruction to obtain an updated result.

[0035] The target consensus node is the master node with the proposal function in the blockchain network; the target consensus node belongs to the N consensus nodes included in the blockchain network; N is a positive integer equal to (3F+1); F is the maximum number of illegal nodes allowed in the blockchain network;

[0036] The writing module includes:

[0037] The packaging unit is used to package the update results to obtain the blocks to be verified to be written into the blockchain network;

[0038] The broadcast unit is used to broadcast the block to be verified to the (N-1) backup nodes in the blockchain network, so that the (N-1) backup nodes can reach a consensus on the block to be verified and obtain a consensus result; the (N-1) backup nodes refer to the consensus nodes other than the target consensus node among the N consensus nodes;

[0039] A statistical unit is used to count the consensus results that are consistent from the received consensus results, and determine the consensus results that are consistent with the statistical consensus as a consensus result set;

[0040] A consensus determination unit, configured to determine the sum of the node weights of the backup nodes corresponding to each consensus result in the consensus result set as the consensus quantity corresponding to the consensus result set;

[0041] A writing unit is configured to determine that the consensus nodes in the blockchain network have reached a consensus if the ratio of the number of consensuses to the total weight of the nodes corresponding to the blockchain network reaches a consensus threshold, and to write the block to be verified as a target block into the database in the blockchain network; the total node weight refers to the sum of the node weights of N consensus nodes; the target block written into the database in the blockchain network is used to indicate that the updated node weight of the first consensus node is capable of weighted processing the voting information of the first consensus node in the consensus business.

[0042] Wherein, the writing module also includes:

[0043] a detection unit configured to, if consensus nodes in the blockchain network fail to reach a consensus and a prediction result is determined to be positive by default through a node weight update instruction, detect a consensus node in an abnormal state in the blockchain network and determine the detected consensus node as a second consensus node;

[0044] A third acquisition unit is used to obtain the node weight of the second consensus node;

[0045] a restart unit, configured to restart the second consensus node and update the consensus state of the second consensus node if the node weight of the second consensus node is greater than the maximum number F of illegal nodes allowed by the blockchain network;

[0046] The consensus unit is configured to re-reach consensus on the acquired block to be verified if the consensus status of the updated second consensus node returns to a normal state.

[0047] The writing module further includes:

[0048] An information generation unit is configured to generate alarm information associated with the second consensus node if the consensus state of the updated second consensus node is an abnormal state, and send the alarm information to a management terminal device associated with the blockchain network.

[0049] The target consensus node is the master node with the proposal function in the blockchain network; the block containing the update result in the blockchain network is the target block;

[0050] The device also includes:

[0051] A block generation rule acquisition module is used to obtain block generation rules associated with the blockchain network;

[0052] The target weight acquisition module is used to obtain the node weight of the target consensus node if the block generation rule is a block generation rule associated with the node weight; the node weight of the target consensus node is used to indicate the total number of blocks generated by the target consensus node in the current round;

[0053] The master node determination module is used to determine the target consensus node as a master node with a proposal function if the number of blocks produced by the target consensus node in the current round has not reached the total number of blocks produced, so that the target consensus node can put the next block of the target block on the chain.

[0054] Wherein, the first consensus node belongs to the N consensus nodes included in the blockchain network; N is a positive integer; one consensus node corresponds to one business organization; the business organization corresponding to the first consensus node is the first business organization; the node weight update instruction is generated by the first terminal device of the first business organization in response to the configuration operation of the first object on the node weight of the first consensus node;

[0055] An acquisition module is specifically configured to receive a node weight update instruction sent by a first terminal device; the node weight update instruction carries primary signature information and multi-party signature information; the primary signature information is obtained by the first terminal device signing the node weight update instruction based on the first private key of the first object; the multi-party signature information is obtained by multi-party signature of the node weight update instruction based on the second private key of the second object associated with M second business organizations; the second business organization is a business organization other than the first business organization among the N business organizations; M is a positive integer less than N and greater than the signature threshold;

[0056] The device also includes:

[0057] A legitimacy verification module, configured to verify the legitimacy of the node weight update instruction based on the first public key and the primary signature information of the first object, and obtain a legitimacy verification result;

[0058] A multi-signature verification module, configured to, if the legitimacy verification result indicates that the node weight update instruction is legitimate, perform multi-signature verification on the multi-party signature information based on the second public keys corresponding to the second objects associated with the M second business institutions, and obtain a multi-signature verification result;

[0059] The execution module is used to notify the update processing module to execute the node weight update instruction to predict whether the node weight of the updated first consensus node meets the node update condition when the multi-signature verification result indicates that the verification is successful, and obtain the prediction result.

[0060] The legitimacy verification module includes:

[0061] a signature verification unit, configured to verify the primary signature information based on the first public key of the first object to obtain a primary signature verification result;

[0062] A verification unit, used to verify the instruction format of the node weight update instruction based on the smart contract on the blockchain network and obtain a verification result;

[0063] A first generating unit is configured to generate a legitimacy verification result indicating that the node weight update instruction is legitimate if the primary signature verification result indicates that the verification is successful and the verification result indicates that the verification is successful;

[0064] The second generating unit is configured to generate a legitimacy verification result indicating that the node weight update instruction is not legitimate if the primary signature verification result indicates that the verification has failed, or the verification result indicates that the verification has failed.

[0065] Among them, if the target consensus node is a master node with a proposal function in the blockchain network and is not the first consensus node, the node weight update instruction obtained by the target consensus node is submitted by the first consensus node when it determines that the multi-signature verification result indicates that the verification is successful; the multi-signature verification result is obtained by the first consensus node after performing multi-signature verification on the multi-party signature information carried in the node weight update instruction when it determines that the legitimacy verification result indicates that the node weight update instruction is legitimacy; the legitimacy verification result is generated by the first consensus node after performing legitimacy verification on the received node weight update instruction.

[0066] The present invention provides a blockchain network, including:

[0067] N consensus nodes; N is a positive integer; one consensus node corresponds to one node weight; the N consensus nodes include a first consensus node and a target consensus node; the target consensus node is used to obtain a node weight update instruction generated for the first consensus node in the blockchain network, and the node weight update instruction is used to instruct to update the node weight of the voting information configured for the first consensus node in the consensus business; the target consensus node is also used to predict whether the node weight of the updated first consensus node meets the node update condition based on the node weight update instruction, and obtain a prediction result; the target consensus node is also used to update the node weight of the first consensus node according to the node weight update instruction in response to a positive prediction result, obtain an update result, and record the update result in the database of the blockchain network.

[0068] Among them, the first consensus node is used to broadcast the node weight update instruction to the target consensus node when it is determined that the instruction verification result of the node weight update instruction indicates that the verification is successful; the instruction verification result is determined by the first consensus node based on the legitimacy verification result and the multi-signature verification result; the legitimacy verification result is generated after the first consensus node verifies the legitimacy of the node weight update instruction; the multi-signature verification result is obtained after the first consensus node performs multi-signature verification on the multi-party signature information carried in the node weight update instruction when it is determined that the legitimacy verification result indicates that the node weight update instruction is legitimacy.

[0069] On one hand, the present application provides a computer device, including: a processor, a memory, and a network interface;

[0070] The processor is connected to the memory and the network interface, wherein the network interface is used to provide data communication functions, the memory is used to store computer programs, and the processor is used to call the computer program so that the computer device executes the method provided in the embodiment of the present application.

[0071] On the one hand, an embodiment of the present application provides a computer-readable storage medium, which stores a computer program. The computer program is suitable for being loaded and executed by a processor so that a computer device having the processor executes the method provided by the embodiment of the present application.

[0072] On the one hand, an embodiment of the present application provides a computer program product, which includes a computer program stored in a computer-readable storage medium; a processor of a computer device reads the computer program from the computer-readable storage medium, and the processor executes the computer program, so that the computer device executes the method in the embodiment of the present application.

[0073] In an embodiment of the present application, the target consensus node can obtain a node weight update instruction generated for the first consensus node in the blockchain network. The node weight update instruction is used to instruct the update of the node weight of the voting information configured for the first consensus node in the consensus business. Among them, if the business organization that owns the first consensus node wishes to change the decision-making power in the entire blockchain network, the target consensus node can predict whether the node weight of the updated first consensus node meets the node update condition based on the node weight update instruction, obtain a prediction result, and in response to the prediction result being positive, update the node weight of the first consensus node according to the node weight update instruction, obtain an update result, and record the update result in the database of the blockchain network. This means that if the business organization wants to have greater decision-making power in the entire blockchain network, there is no need to increase the number of nodes of the business organization. Instead, based on the idea of ​​node weight, by changing the node weight of the first consensus node, the weight of the voting information initiated by the first consensus node in the process of participating in the consensus business can be changed. When adding a new consensus node to a blockchain network, it is necessary to configure the consensus algorithm for the new consensus node, configure the network connection relationship between the new consensus node and the existing consensus node, and configure the maintained database and other configuration operations. These configuration operations require a lot of work to implement, and by increasing the number of consensus nodes, the consensus calculation amount of the blockchain network will inevitably increase, and the network traffic will also increase, resulting in increased resource consumption of the blockchain network. However, the present application uses a deployment method of changing the node weight, which eliminates the need to add new consensus nodes and the need to perform the above-mentioned configuration operations, thereby reducing the workload of deploying nodes. Moreover, since the number of consensus nodes in the blockchain network has not increased, the resource consumption of the blockchain network will not be increased. Moreover, since the number of consensus nodes maintained and managed has not increased, the difficulty of maintaining and managing the consensus nodes will not increase. BRIEF DESCRIPTION OF THE DRAWINGS

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

[0075] FIG1 is a schematic diagram of a blockchain network structure provided by an embodiment of the present application;

[0076] FIG2 is a schematic diagram of a data interaction scenario provided by an embodiment of the present application;

[0077] FIG3 is a flow chart of a data processing method based on blockchain provided in an embodiment of the present application;

[0078] FIG4 is a schematic diagram of a scenario of a check node weight update instruction provided in an embodiment of the present application;

[0079] FIG5 is a schematic diagram of a consensus algorithm according to an embodiment of the present application;

[0080] FIG6 is a first schematic diagram of a scenario for updating the node weight of a first consensus node provided by an embodiment of the present application;

[0081] FIG7 is a second schematic diagram of a scenario of updating the node weight of a first consensus node provided by an embodiment of the present application;

[0082] FIG8 is a third schematic diagram of a scenario of updating the node weight of a first consensus node provided by an embodiment of the present application;

[0083] FIG9 is a schematic diagram of a transaction on-chain scenario provided by an embodiment of the present application;

[0084] FIG10 is a schematic diagram of a scenario of a business consensus provided by an embodiment of the present application;

[0085] FIG11 is a flow chart of a data processing method based on blockchain provided in an embodiment of the present application;

[0086] FIG12 is a schematic diagram of a scenario for rotating a master node provided in an embodiment of the present application;

[0087] FIG13 is a flow chart of a data processing method based on blockchain provided in an embodiment of the present application;

[0088] FIG14 is a schematic diagram of the structure of a blockchain-based data processing device provided in an embodiment of the present application;

[0089] FIG15 is a schematic diagram of a computer device provided in an embodiment of the present application. DETAILED DESCRIPTION

[0090] The following will be combined with the drawings in the embodiments of this application to clearly and completely describe the technical solutions in the embodiments of this application. Obviously, the embodiments described are only part of the embodiments of this application, not all of the embodiments. Based on the embodiments in this application, all other embodiments obtained by ordinary technicians in this field without making creative efforts are within the scope of protection of this application.

[0091] It should be understood that the embodiment of the present application proposes a consensus voting processing solution based on blockchain. Among them, the blockchain network (blockchain or block chain) can be a series of text records (also known as blocks) that are connected and protected by cryptography, that is, it includes a series of blocks that are connected to each other in the order of their generation. Once a new block is added to the blockchain network, it will not be removed. Each block can include the encrypted hash of the previous block (i.e., the parent block hash value), the generation timestamp, and the transaction data (also known as business data, usually represented by a hash value calculated by the Merkle tree algorithm). Such a design makes the block content difficult to tamper with. The distributed database connected in series with blockchain network technology allows both parties to effectively record transactions and can permanently check the transaction (i.e., business data).

[0092] Smart contracts are applications or programs that run on blockchain network nodes. Typically, they are digital agreements with specific rules that can be enforced. These rules are predefined in computer source code that is copied and executed by all network nodes.

[0093] Please refer to Figure 1, which is a schematic diagram of a blockchain network structure provided in an embodiment of the present application. It should be understood that the blockchain network structure can be applied to a blockchain network system, which can include a distributed system formed by N consensus nodes connected through network communication, where N is a positive integer. The consensus node here can be a server connected to the blockchain network or a terminal device connected to the blockchain network. The specific form of the consensus node is not limited here. Among them, a consensus node can correspond to a business organization, and each consensus node has an independent database, which can also be called a blockchain ledger.

[0094] Among them, the consensus node refers to the node running the blockchain network consensus protocol, which has the block generation and voting rights. The consensus node can participate in the verification and broadcasting of transaction data and block information, and will discover and maintain connections with other consensus nodes. At the same time, the consensus node can also include a complete blockchain network database. The N consensus nodes shown in Figure 1 will take turns as the main node with proposal function in the blockchain network based on the block generation rules associated with the blockchain network to participate in the generation, broadcasting and consensus of new blocks.

[0095] It's understandable that consensus algorithms are one of the core technologies of blockchain networks. Consensus algorithms are the specifications followed by all nodes in a blockchain network (i.e., consensus nodes). Commonly used consensus algorithms in the industry include Proof of Work (PoW), Proof of Stake (PoS), and Byzantine Fault Tolerant algorithms (e.g., TBFT). TBFT, or TendermintBFT, is a Byzantine Fault Tolerant consensus algorithm. Its supported nodes must meet the node configuration rule of N equal to 3F + 1, where F represents the maximum number of malicious nodes (i.e., illegal nodes) allowed in the blockchain network. Exceeding this number will reduce the security of the entire network and even make it unavailable. Illegal nodes may not transmit messages or transmit inconsistent messages in an attempt to disrupt other consensus nodes. This consensus algorithm allows illegal nodes to delay network transmissions between legitimate nodes, ensuring security and liveness when the number of illegal nodes is less than one-third. For example, in the blockchain network system shown in Figure 1, when there are at least (2F + 1) legitimate consensus nodes operating normally, the nodes in the blockchain network can reach consensus. For example, in a blockchain network system with 4 consensus nodes, the maximum number of illegal nodes allowed is 1.

[0096] For ease of explanation, the total number of nodes N in the blockchain network shown in Figure 1 can be 4 as an example. These 4 consensus nodes can specifically include node 10a corresponding to business organization A, node 10b corresponding to business organization B, node 10c corresponding to business organization C, and node 10d corresponding to business organization D. Each business organization can correspond to one or more business objects (i.e., organizational members). Among them, the database corresponding to node 10a is database 1; the database corresponding to node 10b is database 2; the database corresponding to node 10c is database 3; and the database corresponding to node 10d is database 4.

[0097] Each of the four consensus nodes in the blockchain network shown in Figure 1 can be assigned a node weight. For example, the node weight of node 10a indicates the proportion of voting information initiated by node 10a during the consensus process of the blockchain network; the node weight of node 10b indicates the proportion of voting information initiated by node 10b during the consensus process of the blockchain network; the node weight of node 10c indicates the proportion of voting information initiated by node 10c during the consensus process of the blockchain network; and the node weight of node 10d indicates the proportion of voting information initiated by node 10d during the consensus process of the blockchain network. The node weights of any two consensus nodes in the blockchain network can be the same or different, and this is not limited here.

[0098] If one of the four business organizations (for example, business organization A) wishes to change the decision-making power in the entire blockchain network, then in this embodiment of the application, business organization A may be referred to as the first business organization, and node 10a corresponding to business structure A may be used as the consensus node for which weights are to be configured. For ease of distinction, in this embodiment of the application, the consensus node for which weights are to be configured in the blockchain network may be referred to as the first consensus node, and the other consensus nodes in the blockchain network other than the first consensus node may be referred to as the third consensus node. It should be noted that if a consensus node is detected to be in an abnormal state in the blockchain network, then in this embodiment of the application, the consensus node detected to be in an abnormal state may be referred to as the second consensus node.

[0099] For ease of explanation, in the embodiment of the present application, any business object belonging to the business organization A may be referred to as a first object, and the terminal device corresponding to the first object may be referred to as a first terminal device. The first terminal device can generate a node weight update instruction in response to the first object's configuration operation on the node weight of node 10a, wherein the node weight update instruction is used to instruct to update the node weight of the voting information configured for the first consensus node in the consensus business. The node weight update instruction can also be understood as a transaction in the blockchain business for requesting an update to the node weight of the first consensus node.

[0100] It should be understood that the target consensus node in the blockchain network (for example, a master node with a proposal function) can obtain the node weight update instruction for node 10a, and then can predict (specifically, predict through a prediction rule) whether the node weight of the updated first consensus node meets the node update condition based on the node weight update instruction, and obtain a prediction result. Among them, the prediction rule here can be a first prediction rule (for example, a strong rule) or a second prediction rule (for example, a weak rule). The so-called strong rule means that after a consensus node updates its weight, even if the consensus node subsequently encounters an abnormality, it cannot affect the normal consensus of the entire blockchain network. That is, the node update condition at this time can refer to the condition that the node weight of the updated first consensus node does not affect the normal consensus of the blockchain network. Among them, the prediction result can be divided into positive and negative. A positive result can indicate that the predicted node weight of the updated first consensus node meets the node update condition, or it can also indicate that the node weight of the updated first consensus node does not affect the normal consensus of the blockchain network. A negative result can indicate that the predicted node weight of the updated first consensus node does not meet the node update condition, or it can also indicate that the node weight of the updated first consensus node will affect the normal consensus of the blockchain network.

[0101] For weak rules, there is no control during the node weight update process, that is, based on the node weight update instruction, it can be directly determined that the node weight of the updated first consensus node meets the node update condition, but it will be strictly required in the subsequent consensus stage. The node update condition at this time can refer to the default condition that allows the node weight of the first consensus node to be updated. Among them, there will only be positive results in the prediction results. A positive result can be expressed as the predicted node weight of the updated first consensus node meets the node update condition. A positive result can also be expressed as allowing the node weight of the first consensus node to be updated.

[0102] Furthermore, in response to the prediction result being positive, the node weight of node 10a can be updated according to the configuration weight carried by the node weight update instruction to obtain an updated result, and then the updated result can be written into the database in the blockchain network. The updated result written into the database in the blockchain network can also be understood as the transaction execution result written into the blockchain ledger (the updated result can be written into the database in the form of a block, and the block can also include a node weight update instruction), that is, each consensus node in the blockchain network will recognize the updated result written into the database in the blockchain network, that is, recognize the updated node weight of the first consensus node. Among them, the node weight of node 10a in the updated result is used to indicate the proportion of voting information initiated by node 10a in the process of participating in the consensus business. For example, if the node weight of node 10a is updated to 2, it means that the number of votes corresponding to the voting information generated by node 10a in the subsequent consensus stage is equivalent to 2.

[0103] It can be seen that the embodiment of the present application proposes a processing model in which the nodes in the blockchain network themselves support weights. When the first business organization needs to have greater decision-making power, there is no need to increase the number of nodes corresponding to the first business organization. Instead, the node weight of the first consensus node is changed to change the proportion of voting information initiated by the first consensus node in the process of participating in the consensus business. This application uses this deployment method of changing the node weight to avoid the need to add new consensus nodes, and there is no need to perform various configuration operations required to create new consensus nodes, thereby reducing the workload of deploying nodes. Moreover, since the number of consensus nodes in the blockchain network has not increased, the resource consumption of the blockchain network will not be increased. Moreover, since the number of consensus nodes maintained and managed has not increased, the difficulty of maintaining and managing consensus nodes will not increase.

[0104] For ease of understanding, please refer to Figure 2, which is a schematic diagram of a data interaction scenario provided in an embodiment of the present application. As shown in Figure 2, the total number of consensus nodes in the blockchain network in the embodiment of the present application can be four, specifically including node 20a, node 20b, node 20c, and node 20d. Among them, one consensus node can correspond to one business organization, and each business organization can include one or more business objects.

[0105] The terminal device cluster shown in FIG2 may be a terminal device cluster corresponding to the business organization (e.g., business organization A) corresponding to node 20a. The terminal device cluster may include terminal devices corresponding to X business objects (i.e., members of business organization A), specifically including terminal device 200Z1 corresponding to object A1, terminal device 200Z2 corresponding to object A2, terminal device 200Z3 corresponding to object A3, ..., and terminal device 200Z4 corresponding to object A4. x Corresponding terminal device 200Z x .

[0106] Each terminal device in the terminal device cluster may include: smart phones, tablet computers, laptop computers, desktop computers, smart speakers, smart watches, car terminals, smart TVs and other smart terminals with data processing functions. It should be understood that each terminal device in the terminal device cluster shown in Figure 2 can be installed with a business application (i.e., an application client). When the application client runs in each terminal device, data can be exchanged with the node 20a shown in Figure 2 above. Among them, the application client may include a social client, a multimedia client (e.g., a video client), an entertainment client (e.g., a game client), an information stream client, an education client, a live broadcast client and other application clients. Among them, the application client can be an independent client or an embedded sub-client integrated in a client (e.g., a social client, an education client, and a multimedia client, etc.), which is not limited here.

[0107] Each terminal device corresponding to a business object can establish a network connection with node 20a to facilitate data exchange with node 20a via the network connection. The network connection herein is not limited to a connection method and can be directly or indirectly connected via wired communication, directly or indirectly connected via wireless communication, or via other methods, which are not limited in this application.

[0108] When business organization A needs to change the decision-making power in the entire blockchain network, any business object belonging to business organization A can generate a node weight update instruction (for example, the node weight update instruction 2t shown in Figure 2) for node 20a through the terminal device used.

[0109] For example, object A1 (i.e., the first object) can determine the configuration weight corresponding to node 20a on terminal device 200Z1, and after the determination is completed, perform a configuration operation on the node weight of node 20a, so that terminal device 200Z1 (i.e., the first terminal device) responds to the configuration operation and generates a node weight update instruction 2t for node 20a (the node weight update instruction 2t may carry the configuration weight). The configuration operation here may include contact operations such as clicking and long pressing, and may also include non-contact operations such as voice and gestures, which will not be limited here.

[0110] The configuration weight here is determined based on the percentage of consensus nodes that business organization A hopes to occupy in the entire blockchain environment and the total weight of nodes in the blockchain network. The configuration weight can be directly input by object A1 on the weight configuration interface of terminal device 200Z1 (i.e., the terminal interface for weight configuration), or it can be selected by object A1 from multiple candidate weights provided on the weight configuration interface of terminal device 200Z1, or it can be automatically calculated by terminal device 200Z1 based on the percentage input by object A1 on the weight configuration interface of terminal device 200Z1 and the total weight of nodes in the blockchain network. Of course, the configuration weight can also include other determination methods, which will not be limited here. For example, if the percentage entered by object A1 in the weight configuration interface of the terminal device 200Z1 is 40%, and the node weight of each consensus node in the blockchain network is 1, which means that the total node weight in the blockchain network is 4, then the terminal device 200Z1 can automatically determine that the configuration weight corresponding to node 20a is 2 (wherein, the total node weight after the predicted node weight update becomes 5, and the configuration weight is 2, so it can satisfy that the node weight of node 20a accounts for 40% of the entire blockchain network), and then generate a node weight update instruction 2t for requesting to change the node weight of node 20a to the configuration weight.

[0111] Furthermore, the terminal device 200Z1 can send the node weight update instruction 2t to the node 20a (i.e., the first consensus node) in the blockchain network, so that the node 20a verifies the acquired node weight update instruction 2t (including legitimacy verification and multi-signature verification) to obtain the transaction verification result. Among them, the embodiment of the present application can refer to the verification result of the legitimacy verification (i.e., verification instruction format verification and master signature information) of the node weight update instruction 2t as the legitimacy verification result, and the verification result of the node weight update instruction 2t multi-signature verification (i.e., verification of multi-party signature information) as the multi-signature verification result. It is understandable that if the legitimacy check result indicates that the node weight update instruction 2t is legitimate, and the multi-signature verification result indicates that the verification is successful, it means that the transaction verification result here indicates that the verification is successful. If the legitimacy check result indicates that the node weight update instruction 2t is legitimate, but the multi-signature verification result indicates that the verification failed, it means that the transaction verification result here indicates that the verification failed. If the validity check result indicates that the node weight update instruction 2t is not valid, there is no need to perform multi-signature verification on the node weight update instruction 2t, and the transaction verification result can be directly determined to indicate verification failure. It is understandable that when the transaction verification result indicates verification failure, the node 20a can directly discard the node weight update instruction 2t.

[0112] When the transaction verification result indicates successful verification, the node 20a can broadcast the node weight update instruction 2t to other nodes in the blockchain network (i.e., the third consensus node), that is, the node weight update instruction 2t can be broadcast to nodes 20b, 20c, and 20d shown in Figure 2, respectively, to wait for the master node with proposal function in the blockchain network (i.e., the target consensus node) to execute the node weight update instruction 2t, thereby obtaining the update result corresponding to the node weight update instruction 2t. Then, when the consensus nodes in the blockchain network reach a consensus, the master node can write the update result and the node weight update instruction 2t into the blockchain network.

[0113] For example, if the master node with the proposal function in the blockchain network is node 20d, node 20d can predict whether the updated node weight of the first consensus node meets the node update condition based on the node weight update instruction, and obtain a prediction result. In response to the prediction result being positive, node 20d can update the node weight of node 20a based on the configuration weight carried by node weight update instruction 2t to obtain an updated result. Then, when the consensus nodes in the blockchain network reach consensus, node 20d can write the updated result and node weight update instruction 2t into the blockchain network.

[0114] If the node weight of node 20a is 1, then node 20d can update the node weight of node 20a to the configured weight based on the configured weight carried by the node weight update instruction 2t. The node weight of node 20a in the update result is used to indicate the proportion of voting information initiated by node 20a in the process of participating in the consensus business. That is, when the configured weight is 2, this means that one voting information initiated by node 20a in the process of participating in the consensus business is equivalent to two.

[0115] It can be seen that when business organization A needs to have greater decision-making power, the deployment method proposed in the embodiment of the present application does not need to increase the number of nodes corresponding to business organization A, but instead changes the node weight of node 10a to change the proportion of voting information initiated by node 10a in the process of participating in the consensus business. The deployment method of changing the node weight in this application can eliminate the need to add new consensus nodes, and does not require the execution of various configuration operations required to create new consensus nodes, thereby reducing the workload of deploying nodes. Moreover, since the number of consensus nodes in the blockchain network has not increased, the resource consumption of the blockchain network will not be increased. Moreover, since the number of consensus nodes maintained and managed has not increased, the difficulty of maintaining and managing consensus nodes will not increase.

[0116] Among them, the embodiments of the present application are based on the idea of ​​weight, and the specific implementation method of deploying nodes in the blockchain network can be referred to the embodiments corresponding to the following Figures 3 to 13.

[0117] Further, please refer to Figure 3, which is a flow chart of a data processing method based on blockchain provided by an embodiment of the present application. As shown in Figure 3, the method can be executed by a target consensus node, which can be a master node with a proposal function in the blockchain network shown in Figure 1 above. The target consensus node can be a first consensus node (for example, node 10a shown in Figure 1 above), or a third consensus node (for example, any one of node 10b, node 10c, or node 10d). The target consensus node is not limited here. The method can at least include the following steps S101-S103:

[0118] Step S101: Obtain a node weight update instruction generated for a first consensus node in a blockchain network, where the node weight update instruction is used to instruct to update the node weight of voting information configured for the first consensus node in a consensus service.

[0119] The first consensus node here is one of the N consensus nodes included in the blockchain network; the N consensus nodes may include the first consensus node and the third consensus node; N is a positive integer, and one consensus node corresponds to one business organization. The business organization corresponding to the first consensus node is the first business organization. The first business organization is the business organization that wishes to change decision-making authority within the entire blockchain network. The node weight update instruction here is generated by the first terminal device of the first business organization in response to the first object's configuration operation on the node weight of the first consensus node. It is understood that the node weight update instruction obtained by the target consensus node can be sent directly by the first terminal device or broadcast by other nodes in the blockchain network after successful verification, and this is not limited here.

[0120] It should be understood that each of the N consensus nodes in a blockchain network can be assigned a node weight. For example, if each consensus node has a node weight of 1, the total number of nodes in the blockchain network is the total node weight of the blockchain network. When a first business organization needs to change its decision-making authority, a first subject can, on a first terminal device, determine the node weight to be configured for the first consensus node based on the first business organization's desired percentage of the blockchain network and the total node weight of the blockchain network. For example, if all three consensus nodes have a node weight of 1, the first business organization's desired percentage of the blockchain network is 50%, and the total node weight of the blockchain network is 3, then the node weight to be configured for the first consensus node determined by the first subject is 2.

[0121] Then, the first object can perform a configuration operation on the first terminal device for the node weight of the first consensus node, so that when the first terminal device responds to the configuration operation, the node weight to be configured of the first consensus node determined by the first object is determined as the configuration weight, and then based on the configuration weight, a business transaction (i.e., a node weight update instruction) for requesting a change in the node weight of the first consensus node can be generated. At this time, the first terminal device can sign the node weight update instruction based on the object private key of the first object (i.e., the first private key) to obtain the primary signature information corresponding to the node weight update instruction.

[0122] Since the blockchain network includes N consensus nodes, and one consensus node corresponds to one business organization, this means that the blockchain network is related to N business organizations. In the embodiment of the present application, the business organizations other than the first business organization in the N business organizations may be referred to as second business organizations. Based on this, the first terminal device can send the node weight update instruction containing the main signature information to the second terminal device corresponding to the second object belonging to the second business organization, so that the second terminal device that receives the node weight update instruction containing the main signature information returns the signature parameters for multi-party signature of the node weight update instruction based on the object private key of the second object (i.e., the second private key).

[0123] The first terminal device may count the number M of signature agencies of the received signature parameters. When the number M of signature agencies is greater than a signature threshold (e.g., 2N / 3), the first terminal device may aggregate the M signature parameters to obtain multi-party signature information of the node weight update instruction, and then send the node weight update instruction containing the multi-party signature information and the primary signature information to the blockchain network. This means that the multi-party signature information in the embodiment of the present application is obtained by multi-signing the node weight update instruction based on the second private key of the second object associated with the M second business organizations.

[0124] It is understandable that the target consensus node here can be the first consensus node or the third consensus node (i.e., another consensus node other than the first consensus node). If the target consensus node is the first consensus node, the target consensus node can directly receive the node weight update instruction sent by the first terminal device. The node weight update instruction carries the primary signature information and the multi-party signature information. Then, the target consensus node can perform a legitimacy verification on the node weight update instruction based on the first public key of the first object and the primary signature information to obtain a legitimacy verification result. Among them, when the target consensus node performs a legitimacy verification on the node weight update instruction, it can verify the primary signature information based on the first public key of the first object to obtain a primary verification result. Furthermore, the target consensus node also needs to verify the instruction format of the node weight update instruction based on the smart contract on the blockchain network to obtain a verification result. If the primary verification result indicates that the verification is successful, and the verification result indicates that the verification is successful, the target consensus node can generate a legitimacy verification result indicating that the node weight update instruction is legitimate. If the primary signature result indicates a verification failure, or the verification result indicates a verification failure, the target consensus node may generate a legitimacy verification result indicating that the node weight update instruction is not legitimate.

[0125] If the legitimacy verification result indicates that the node weight update instruction is legitimate, the target consensus node needs to continue to perform multi-signature verification on the multi-party signature information based on the second public keys corresponding to the second objects associated with the M second business institutions to obtain a multi-signature verification result. When the multi-signature verification result indicates that the verification is successful, the target consensus node can broadcast the node weight update instruction to other nodes in the blockchain network (for example, the third consensus node). When the multi-signature verification result indicates that the verification is successful, the target consensus node can further execute the following step S102.

[0126] Optionally, if the target consensus node is the third consensus node (i.e., not the first consensus node), the node weight update instruction obtained by the target consensus node is submitted by the first consensus node when it determines that the multi-signature verification result indicates that the verification is successful. The multi-signature verification result here is obtained by the first consensus node after performing multi-signature verification on the multi-party signature information carried in the node weight update instruction when it determines that the legitimacy verification result indicates that the node weight update instruction is legitimacy; the legitimacy verification result here is generated by the first consensus node after performing legitimacy verification on the received node weight update instruction.

[0127] For ease of understanding, further, please refer to Figure 4, which is a scenario diagram of a verification node weight update instruction provided in an embodiment of the present application. As shown in Figure 4, the object A1 corresponding to the terminal device 400Z here belongs to a member of the business organization A (i.e., the first business organization). The node corresponding to the business organization A in the blockchain network can be the node 40a shown in Figure 4. The node 40a here can be the node 10a in the blockchain network in the embodiment corresponding to Figure 1 above. In addition to business organization A, the business organization associated with the blockchain network to which node 40a belongs can also include a second business organization, for example, business organization B, business organization C, and business organization D.

[0128] When the terminal device 400Z belonging to the business organization A generates the node weight update instruction 4t shown in Figure 4, it can be based on the object private key (i.e., the first private key) of the object A1, the node weight update instruction 4t is signed to obtain the main signature information corresponding to the node weight update instruction 4t. It can be understood that the terminal device 400Z can obtain a hash calculation rule, which can be a summary algorithm agreed in advance by the terminal device 400Z and other blockchain network nodes in the blockchain network. The terminal device 400Z can perform a hash calculation on the node weight update instruction 4t based on the hash calculation rule to obtain the summary information (e.g., summary information h) of the node weight update instruction 4t. In this embodiment of the present application, the summary information of the node weight update instruction 4t determined by the terminal device 400Z can be referred to as the first summary information. Further, the terminal device 400Z can perform a signature process on the first summary information based on the object private key of the object A1, so as to obtain the main signature information shown in Figure 4.

[0129] Then, the terminal device 400Z can send the node weight update instruction 4t containing the primary signature information to the second terminal device corresponding to the second object belonging to business organization B, the second terminal device corresponding to the second object belonging to business organization C, and the second terminal device corresponding to the second object belonging to business organization D, respectively, so that the second terminal device returns signature parameters for multi-party signature of the node weight update instruction 4t based on the second private key of the second object corresponding to itself. The signature parameters returned to the terminal device 400Z by multiple second terminal devices belonging to the same second business organization can all be regarded as signature parameters returned by the same signature authority.

[0130] For example, if the signature parameters received by the terminal device 400Z include signature parameter 1 of object B1 (for example, the signature parameter returned by the terminal device corresponding to object B1), signature parameter 2 of object B2 (for example, the signature parameter returned by the terminal device corresponding to object B2), signature parameter 3 of object C1 (for example, the signature parameter returned by the terminal device corresponding to object C1) and signature parameter 4 of object D1 (for example, the signature parameter returned by the terminal device corresponding to object D1), where object B1 and object B2 are both members of business organization B, object C1 is a member of business organization C, and object D1 is a member of business organization D, this means that the number M of signature organizations counted by the terminal device 400Z is 3, namely business organization B, business organization C and business organization D.

[0131] Since the number of signature agencies 3 is greater than the signature threshold (e.g., 2N / 3), the terminal device 400Z can aggregate the three signature parameters to obtain the multi-party signature information of the node weight update instruction 4t. Then, the terminal device 400Z can send the node weight update instruction 4t containing the multi-party signature information and the primary signature information to the consensus node corresponding to the business organization A (i.e., the first consensus node in the blockchain network, e.g., node 40a), so that node 40a can verify the node weight update instruction 4t.

[0132] It is understood that when node 40a obtains the node weight update instruction 4t, it can verify the legitimacy of the node weight update instruction 4t based on the object public key (i.e., the first public key) of object A1 and the primary signature information to obtain a legitimacy verification result. The legitimacy verification result here is determined by the verification result and the primary signature result.

[0133] For example, node 40a needs to first verify the main signature information based on the object public key of object A1 and obtain the main verification result. That is, node 40a can obtain the object public key of object A1, and then can verify the main signature information based on the object public key of object A1, and obtain the first summary information of node weight update instruction 4t. At the same time, the node 40a can also obtain the same hash calculation rule as terminal device 400Z, and perform hash calculation on node weight update instruction 4t, so as to obtain the summary information (for example, summary information H) of the node weight update instruction 4t. Wherein, the summary information of the node weight update instruction 4t determined by node 40a can be referred to as the second summary information in the embodiment of the present application. Then, the node 40a can compare the first summary information with the second summary information to obtain the main verification result, to determine whether the node weight update instruction 4t has been tampered with. It is understandable that if the first summary information is different from the second summary information, the node 40a can determine that the main verification result indicates that the verification has failed. Optionally, if the first summary information is the same as the second summary information, the node 40a can determine that the main verification result indicates successful verification, which means that the node weight update instruction 4t has not been tampered with and the node weight update instruction 4t is indeed sent by the terminal device 400Z.

[0134] At the same time, the node 40a also needs to verify the instruction format of the node weight update instruction 4t based on the smart contract on the blockchain network to obtain a verification result. If the primary verification result indicates that the verification is successful, and the verification result indicates that the verification is successful, the node 40a can generate a legitimacy verification result indicating that the node weight update instruction 4t is legitimate. If the primary verification result indicates that the verification fails, or the verification result indicates that the verification fails, the node 40a can generate a legitimacy verification result indicating that the node weight update instruction 4t is not legitimate.

[0135] When the legitimacy verification result indicates that the node weight update instruction 4t is not legitimate (i.e., the verification fails), the node 40a can discard the node weight update instruction 4t. Optionally, when the legitimacy verification result indicates that the node weight update instruction 4t is legitimate (i.e., when the verification succeeds), the node 40a needs to continue to perform multi-signature verification on the multi-party signature information based on the second public keys corresponding to the second objects associated with the M second business institutions, and obtain a multi-signature verification result. Among them, the second public keys corresponding to the second objects associated with the M second business institutions can include the object public key of object B1, the object public key of object B2, the object public key of object C1, and the object public key of object D1. Among them, the embodiment of the present application can adopt a non-interactive aggregate signature rule (e.g., Schnorr algorithm) to perform multi-party signature on the node weight update instruction 4t to obtain multi-party signature information, and the specific implementation method of node 40a performing multi-party verification on the multi-party signature information can refer to this non-interactive aggregate signature rule, which will not be repeated here.

[0136] It is understandable that when the multi-signature verification result indicates that the verification has failed, the node 40a can discard the node weight update instruction 4t. Optionally, if the multi-signature verification result indicates that the verification is successful, the node 40a can broadcast the node weight update instruction 4t to other nodes in the blockchain network to wait for the master node with the proposal function to put it on the chain. For example, if the master node is node 40a, the node 40a can continue to execute the following S102 step. It can be seen that the legitimacy verification and multi-signature verification can ensure that the node weight update instructions to be executed subsequently are legal and reliable. Through the legitimacy verification and multi-signature verification, some abnormal or illegal node weight update instructions can be discarded to avoid causing erroneous node weight updates. That is, by executing legal and reliable node weight update instructions, it can be guaranteed that the updated node weights are also legal and reliable.

[0137] Among them, the blockchain network of the present application can adopt the original consensus algorithm (for example, TBFT consensus). For ease of understanding, further, please refer to Figure 5, which is a flow chart of a consensus algorithm provided by an embodiment of the present application. As shown in Figure 5, the blockchain network in the embodiment of the present application may include N consensus nodes, and these N consensus nodes may specifically include a master node with a proposal function (for example, node a) and (N-1) backup nodes with a verification function, which may specifically include node b, node c, and node d. Among them, N here can be a positive integer equal to (3F+1), and F can be the maximum number of illegal nodes allowed by the blockchain network.

[0138] Among them, under the TBFT consensus algorithm, the consensus process between nodes can include 5 stages, specifically including the preparation stage (NewRound) of consensus voting, the proposal stage (Proposal), the pre-voting stage (Prevote), the pre-commit stage (Precommit), and the commit stage (Commit).

[0139] In the preparation phase, when node a receives a transaction sent by the client in the first terminal device (for example, a node weight update instruction generated for node a), it will initialize the consensus-related state.

[0140] During the proposal phase, the masternode can generate a proposal and broadcast it to other nodes. For example, node a will package the transactions to be uploaded to the blockchain and broadcast the resulting blocks to nodes b, c, and d.

[0141] During the pre-voting phase, any backup node (node ​​b, node c, or node d) can execute the transactions in the block after receiving it from node a, and determine whether the block hash value of the block is correct. This generates prevote information (i.e., first voting information) during the pre-voting phase, and broadcasts the prevote information to other nodes. If the block hash value is correct, the backup node generates prevote information indicating a yes vote; otherwise, it generates prevote information indicating a no vote.

[0142] In the pre-commit phase, any consensus node can collect the prevote voting information generated by other nodes in the pre-voting phase. If the number of votes in the collected prevote voting information reaches (2F+1), then the Precommit voting information (i.e., the second voting information) is generated based on the collected prevote voting information, and the Precommit voting information is broadcast to other nodes.

[0143] In the submission phase, any consensus node can collect the Precommit voting information generated by other nodes in the precommit phase. If the number of votes in the collected Precommit voting information reaches (2F+1), a submission message is generated based on the collected Precommit voting information. The submission message here is used to indicate whether the block in the proposal is submitted to the database.

[0144] Step S102: Based on the node weight update instruction, predict whether the node weight of the updated first consensus node meets the node update condition, and obtain a prediction result; in response to the prediction result being positive, update the node weight of the first consensus node according to the node weight update instruction to obtain an update result.

[0145] Among them, the consensus algorithm mentioned above (e.g., TBFT consensus) is a three-stage model. Since the embodiment of the present application is based on the idea of ​​node weight to change the proportion of voting information initiated by the first consensus node in the process of participating in the consensus business, for security reasons, the embodiment of the present application does not modify its three-stage model and the entire fault tolerance mechanism. Instead, two prediction rules are designed for the blockchain network. Both prediction rules can be used to indicate whether the node weight update for the first consensus node meets the node update condition. Specifically, the prediction rule may include a first prediction rule (e.g., a strong rule) or a second prediction rule (e.g., a weak rule). The so-called strong rule means that after a consensus node updates its weight, even if an abnormality occurs in the node later, it cannot affect the normal consensus of the entire blockchain network. That is, the node update condition at this time can refer to the condition that the node weight of the updated first consensus node does not affect the normal consensus of the blockchain network. Among them, the prediction results can be divided into positive and negative. A positive result can indicate that the predicted node weight of the updated first consensus node meets the node update condition, and a positive result can also indicate that the node weight of the updated first consensus node does not affect the normal consensus of the blockchain network. A negative result can indicate that the predicted node weight of the updated first consensus node does not meet the node update condition, and a negative result can also indicate that the node weight of the updated first consensus node will affect the normal consensus of the blockchain network.

[0146] As for weak rules, there is no control during the node weight update process, that is, based on the node weight update instruction, it can be directly determined that the node weight of the updated first consensus node meets the node update condition, but it will be strictly required in the subsequent consensus stage. At this time, the node update condition can refer to the default condition that allows the node weight of the first consensus node to be updated. Among them, there will only be positive results in the prediction results. A positive result can be expressed as the predicted node weight of the updated first consensus node meeting the node update condition, and a positive result can also be expressed as allowing the node weight of the first consensus node to be updated. Among them, the prediction rule obtained by the target consensus node can be directly obtained from the database in the blockchain network (that is, the blockchain network database, or the blockchain ledger), or it can be read from the smart contract associated with the blockchain network, or it can be jointly agreed upon by N consensus nodes in the blockchain network (for example, read from a configuration file). It will not be limited here.

[0147] Among them, the configuration weight of the first consensus node in the update result here is used to indicate the proportion of voting information initiated by the first consensus node in the process of participating in the consensus business. It should be understood that if the prediction rule is the first prediction rule, the target consensus node (i.e., the master node) needs to determine whether the first consensus node meets the node update condition based on the configuration weight in the node weight update instruction and the node weight list corresponding to the blockchain network to obtain the prediction result. Among them, the node update condition here can also mean that the configuration weight of the first consensus node is less than or equal to the maximum number of illegal nodes allowed by the blockchain network to ensure that the node weight (i.e., the configuration weight) of the updated first consensus node does not affect the normal consensus of the blockchain network. If the prediction rule is the second prediction rule, the target consensus node can directly assume that the predicted node weight of the updated first consensus node meets the node update condition, that is, it can directly execute the node weight update instruction to update the node weight of the first consensus node and obtain the update result.

[0148] It is understood that each consensus node in a blockchain network has a corresponding node identifier, and each consensus node can store the node identifiers of other consensus nodes in the blockchain network, so that the generated blocks can be broadcast to other consensus nodes based on the node identifiers of other consensus nodes. The node identifier can be an IP (Internet Protocol, a protocol for interconnecting networks) address or any other information that can be used to identify the node.

[0149] In other words, each consensus node can maintain a node identification list. Since the embodiment of the present application proposes a processing model in which the nodes in the blockchain network themselves support weights, the embodiment of the present application can add a new field for indicating the node weight and a field for indicating the business organization corresponding to the consensus node on the basis of the node identification list to obtain the node weight list corresponding to the blockchain network.

[0150] For ease of understanding, please refer to Table 1 further. Table 1 is a list of node weights corresponding to a blockchain network provided in an embodiment of the present application. Among them, the node weight list may include fields corresponding to the business organization, fields corresponding to the consensus node name, fields corresponding to the node identifier, and fields corresponding to the node weight. Of course, the node weight list may also be other lists containing fields corresponding to the node weights, which will not be limited here. As shown in Table 1, the blockchain network corresponding to the node weight list may be the blockchain network in the embodiment corresponding to Figure 1 above. The blockchain network may include 4 consensus nodes, specifically including node 10a corresponding to business organization A, node 10b corresponding to business organization B, node 10c corresponding to business organization C, and node 10d corresponding to business organization D. Among them, one consensus node corresponds to one consensus node weight. Specifically as shown in Table 1:

[0151] Table 1

[0152] For example, if the prediction rule is the first prediction rule, the target consensus node can obtain the node weight list corresponding to the blockchain network. Since the first consensus node here belongs to the N consensus nodes included in the blockchain network, the embodiment of the present application can refer to the node weight of each consensus node in the N consensus nodes in the node weight list as the node weight; N is a positive integer. Then, based on the N node weights and the configuration weight carried by the node weight update instruction, the target consensus node can determine the maximum number F of illegal nodes allowed by the blockchain network, and then compare the configuration weight with the maximum number F to obtain a comparison result.

[0153] Among them, when determining the maximum number F, the target consensus node can obtain (N-1) node weights other than the node weight of the first consensus node from the N node weights, and then can sum the (N-1) node weights and the configuration weight carried by the node weight update instruction to obtain the predicted total node weight H corresponding to the blockchain network. Here, H is a positive integer. Furthermore, the target consensus node can obtain the node configuration rules corresponding to the blockchain network (i.e., H = 3F + 1), and based on the total node weight H and the node configuration rules, determine the maximum number F of illegal nodes allowed by the blockchain network.

[0154] If the comparison result indicates that the configuration weight is less than or equal to the maximum number F, the target consensus node can determine that the configuration weight meets the node update condition, that is, it can determine that the prediction result is positive, and then based on the configuration weight in the node weight update instruction, it can update the node weight of the first consensus node to obtain an update result. Among them, the configuration weight of the first consensus node in the update result here can be used to update the node weight list of the blockchain network. Optionally, if the comparison result indicates that the configuration weight is greater than the maximum number F, the target consensus node can determine that the prediction result is negative, and a negative prediction result indicates that the configuration weight does not meet the node update condition, and the node weight update instruction is discarded. It can be seen that before updating the node weights, the present application can use strong rules to ensure that the configuration weights that are desired to be changed will not affect the normal consensus of the entire blockchain network. That is, even if the consensus node that has been changed to the configuration weight is abnormal or acts maliciously, the blockchain network can still continue to complete the consensus process normally. Configuration weights that do not meet the node update conditions (that is, the configuration weight is greater than the maximum number F of illegal nodes allowed by the blockchain network) will not be allowed to be changed. This can effectively increase the security of updating node weights and ensure that the blockchain network can still safely and normally execute the consensus process after the node weights are updated.

[0155] For ease of understanding, further reference is made to FIG6 , which is a schematic diagram of a scenario for updating the node weight of a first consensus node provided in an embodiment of the present application. As shown in FIG6 , the total number of nodes N in the blockchain network (i.e., the current blockchain network) in the embodiment of the present application can be 4, for example, specifically including node 60a, node 60b, node 60c, and node 60d.

[0156] If the prediction rule is the first prediction rule, the target consensus node (i.e., the master node) may obtain a node weight list corresponding to the blockchain network. For example, the node weight list may include the node weight of node 60a (e.g., 1), the node weight of node 60b (e.g., 1), the node weight of node 60c (e.g., 1), and the node weight of node 60d (e.g., 1).

[0157] Since the node weight update instruction is used to request that the node weight of node 60a be changed to the configuration weight (for example, 2), the target consensus node needs to obtain the three node weights other than node 60a from these four node weights, and then sum these three node weights and the configuration weight of node 60a to obtain the predicted total node weight H (for example, 5) corresponding to the updated blockchain network. Furthermore, the target consensus node can determine the maximum number F (for example, 1) of illegal nodes allowed by the blockchain network based on the node configuration rules corresponding to the blockchain network.

[0158] Since the node update condition in the first prediction rule indicates that once the updated node exits, it is necessary to ensure that other nodes can continue to reach consensus. Therefore, after the node weight of node 60a is predicted and updated, the blockchain network after the update is predicted to require four consensus results to reach a consensus. If node 60a is abnormal (for example, it is offline, malicious, or other abnormal states), then the remaining nodes 60b, 60c, and 60d will not be able to reach a consensus, which means that the first prediction rule does not allow node 60a to change its node weight. In other words, since the configuration weight of node 60a is greater than the maximum number F, the target consensus node can determine that the configuration weight of node 60a does not meet the node update condition and can directly discard the node weight update instruction.

[0159] For ease of understanding, further reference is made to FIG7 , which is a second schematic diagram of a scenario for updating the node weight of a first consensus node provided in an embodiment of the present application. As shown in FIG7 , the total number of nodes N in the blockchain network (i.e., the current blockchain network) in the embodiment of the present application can be 6, for example, and can specifically include node 70a, node 70b, node 70c, node 70d, node 70e, and node 70f.

[0160] If the prediction rule is the first prediction rule, the target consensus node (i.e., the master node) may obtain a node weight list corresponding to the blockchain network. For example, the node weight list may include the node weight of node 70a (e.g., 1), the node weight of node 70b (e.g., 1), the node weight of node 70c (e.g., 1), the node weight of node 70d (e.g., 1), the node weight of node 70e (e.g., 1), and the node weight of node 70f (e.g., 1).

[0161] Since the node weight update instruction is used to request that the node weight of node 70a be changed to the configuration weight (for example, 2), the target consensus node needs to obtain 5 node weights other than node 70a from these 6 node weights, and then sum these 5 node weights and the configuration weight of node 70a to obtain the predicted total node weight H (for example, 7) corresponding to the updated blockchain network. Furthermore, the target consensus node can determine the maximum number F (for example, 2) of illegal nodes allowed by the blockchain network based on the node configuration rules corresponding to the blockchain network.

[0162] Since the node update condition in the first prediction rule indicates that once the updated node exits, it is necessary to ensure that other nodes can continue to reach consensus. Therefore, after the node weight of node 70a is predicted and updated, it is predicted that the updated blockchain network needs 5 consensus results to reach a consensus. If node 70a is abnormal (for example, it is offline, malicious, or other abnormal states), then the remaining nodes 70b, 70c, 70d, 70e, and 70f can still reach a consensus, which means that the first prediction rule allows node 70a to change its node weight. In other words, since the configuration weight of node 70a is equal to the maximum number F, the target consensus node can determine that the configuration weight of node 70a meets the node update condition, and then based on the configuration weight, the node weight of node 70a can be updated to obtain an updated result. Among them, the node weight of node 70a in the update result (i.e., the configuration weight) is used to update the node weight list of the blockchain network. By updating the node weight list of the blockchain network, it is possible to ensure that the correct node weight of each current consensus node is recorded in real time, so that when the node weight is updated next time, the accurate node weight can be obtained through the updated node weight list to ensure that the node weight update can continue to be completed safely and reliably.

[0163] For ease of understanding, further reference is made to FIG8 , which is a schematic diagram of a third scenario for updating the node weight of a first consensus node provided in an embodiment of the present application. As shown in FIG8 , the total number of nodes N in the blockchain network (i.e., the current blockchain network) in the embodiment of the present application can be 7, for example, specifically including nodes 80a, 80b, 80c, 80d, 80e, 80f, and 80g.

[0164] If the prediction rule is the first prediction rule, the target consensus node (i.e., the master node) may obtain a node weight list corresponding to the blockchain network. For example, the node weight list may include the node weight of node 80a (e.g., 1), the node weight of node 80b (e.g., 1), the node weight of node 80c (e.g., 1), the node weight of node 80d (e.g., 1), the node weight of node 80e (e.g., 1), the node weight of node 80f (e.g., 1), and the node weight of node 80g (e.g., 1).

[0165] Since the node weight update instruction is used to request that the node weight of node 80a be changed to the configuration weight (for example, 2), the target consensus node needs to obtain 6 node weights other than node 80a from these 7 node weights, and then sum these 6 node weights and the configuration weight of node 80a to obtain the predicted total node weight H (for example, 8) corresponding to the updated blockchain network. Furthermore, the target consensus node can determine the maximum number F (for example, 2) of illegal nodes allowed by the blockchain network based on the node configuration rules corresponding to the blockchain network.

[0166] Since the node update condition in the first prediction rule indicates that once the updated node exits, it is necessary to ensure that other nodes can continue to reach consensus. Therefore, after the node weight of node 80a is predicted and updated, the blockchain network after the update is predicted to require 6 consensus results to reach a consensus. If node 80a is abnormal (for example, it is offline, malicious, etc.), then the remaining nodes 80b, 80c, 80d, 80e, 80f, and 80g can still reach a consensus, which means that the first prediction rule allows node 80a to change its node weight. In other words, since the configuration weight of node 80a is equal to the maximum number F, the target consensus node can determine that the configuration weight of node 80a meets the node update condition, and then based on the configuration weight, the node weight of node 80a can be updated to obtain an updated result. Among them, the node weight of node 80a in the update result (i.e., the configuration weight) is used to update the node weight list of the blockchain network.

[0167] For another example, if the prediction rule is the second prediction rule, the target consensus node can directly obtain the configuration weight carried by the node weight update instruction. According to the node weight update instruction, the prediction result is determined to be positive by default. A positive prediction result indicates that the configuration weight meets the node update condition. Then, in response to the positive prediction result, the node weight of the first consensus node can be obtained from the blockchain network, and the node weight of the first consensus node can be changed to the configuration weight to obtain the updated result. It can be seen that by providing a weak rule node weight update mechanism, the present application can complete the node weight update more efficiently when the user has time requirements.

[0168] Step S103: record the update result in the database of the blockchain network.

[0169] Specifically, when the target consensus node is a master node with a proposal function in a blockchain network, the blockchain network also includes (N-1) backup nodes, where the blockchain network includes N consensus nodes, and the (N-1) backup nodes refer to the consensus nodes in the N consensus nodes other than the target consensus node; N is the total number of consensus nodes in the blockchain network; N is a positive integer equal to (3F+1); and F is the maximum number of illegal nodes allowed in the blockchain network. At this time, the target consensus node can package the update result (optionally, the update result and the node weight update instruction can also be packaged together) to obtain a block to be verified to be written to the blockchain network. The target consensus node can then broadcast the block to be verified to the (N-1) backup nodes in the blockchain network, so that the (N-1) backup nodes can reach consensus on the obtained block to be verified and obtain a consensus result. Furthermore, the target consensus node can count the consensus results that are consistent from the received consensus results (consensus results that are consistent can be understood as consensus results that voted in favor in the consensus vote), determine the consensus results that are consistent with the statistics as a consensus result set, and then determine the sum of the node weights of the backup nodes corresponding to each consensus result in the consensus result set as the number of consensuses corresponding to the consensus result set. If the ratio between the number of consensuses and the total node weight corresponding to the blockchain network reaches the consensus threshold, it is determined that the consensus nodes in the blockchain network have reached a consensus, and then the block to be verified can be written into the blockchain network as the target block. The total node weight refers to the sum of the node weights of N consensus nodes; the target block written into the database of the blockchain network is used to indicate the updated node weight of the first consensus node, which can perform weighted processing on the voting information of the first consensus node in the consensus business.

[0170] Since the embodiment of the present application proposes a processing model in which the nodes in the blockchain network themselves support weights, the node weights of the consensus nodes in the embodiment of the present application can be stored in the latest block in the blockchain network (for example, the update results in the block or the status tree in the block), or in the node weight list maintained by itself, or in a configuration file associated with the consensus node. Of course, the storage method of the current node weight here can also include other forms, which will not be given as examples here.

[0171] For example, if the consensus node's node weight is desired to be stored in the update result of the latest block in the blockchain network, then after executing step S102, the target consensus node can obtain the block with the maximum generation timestamp from the blockchain network. Based on the block hash value and update result of the obtained block, the target consensus node can determine the information to be packaged. The packaged information can then be packaged and the resulting block used as the block to be verified, which is then written to the blockchain network. The target consensus node can then broadcast the block to be verified to the (N-1) backup nodes in the blockchain network, allowing the (N-1) backup nodes to reach consensus on the obtained block to obtain a consensus result. Upon determining that the consensus nodes in the blockchain network have reached consensus on the block to be verified, the block to be verified can be written to the blockchain network as the target block. The generation timestamp of the target block can be used to update the maximum generation timestamp of the blockchain network.

[0172] For example, if the consensus node's node weight is desired to be stored in the state tree of the latest block in the blockchain network, this means that each block in the blockchain network can store a state tree associated with the node weights of N consensus nodes. Therefore, after executing step S102, the target consensus node can obtain the block with the highest generation timestamp from the blockchain network and use the obtained block as the parent block. The state tree in the parent block stores the node weight of the first consensus node. Furthermore, the target consensus node can, based on the path indicated by the first consensus node's key information (e.g., node identifier), obtain a leaf node from the parent block's state tree that stores the first consensus node's node weight. The target consensus node then changes the information stored in the obtained leaf node from the first consensus node's node weight to the configuration weight carried by the node weight update instruction, thereby obtaining an updated state tree. The target consensus node can then determine the information to be packaged based on the parent block's block hash value, the updated state tree, and the update result. The target consensus node can then package the information to be packaged, and use the resulting block as the block to be written to the blockchain network for verification. The target consensus node can then broadcast the block to be verified to the (N-1) backup nodes in the blockchain network, allowing the (N-1) backup nodes to reach a consensus on the block to be verified and obtain a consensus result. When it is determined that the consensus nodes in the blockchain network have reached a consensus on the block to be verified, the block to be verified can be written into the blockchain network as the target block. The generation timestamp of the target block can be used to update the maximum generation timestamp of the blockchain network, and the node weight of the first consensus node stored in the state tree of the target block is the configuration weight of the first consensus node.

[0173] For another example, if the node weight of the consensus node is desired to be stored in the node weight list maintained by itself, then after executing step S103, that is, after the target consensus node writes the target block into the blockchain network, the target consensus node can also search for the node weight of the first consensus node from the node weight list corresponding to the blockchain network (for example, the node weight list shown in Table 1 above), and then change the node weight found in the node weight list to the configuration weight.

[0174] For another example, if the node weight of the consensus node is desired to be stored in the configuration file of the consensus node, then the target consensus node may change the node weight of the first consensus node in the configuration file to the configuration weight after executing step S103, that is, after the target consensus node writes the target block into the blockchain network.

[0175] For ease of understanding, please refer to Figure 9, which is a schematic diagram of a transaction on-chain scenario provided by an embodiment of the present application. As shown in Figure 9, the total number of consensus nodes in the blockchain network in the embodiment of the present application can be 4, for example, specifically including node 90a, node 90b, node 90c, and node 90d. Among them, node 90d can be a master node with a proposal function determined according to the block production rules associated with the blockchain network, and nodes 90a, node 90b, and node 90c can all be referred to as backup nodes.

[0176] The node weight update instruction here can be used to request that the node weight of node 90a be changed to the configured weight (for example, 2). The blockchain network shown in FIG9 can be an identical blockchain network shared by each consensus node in the blockchain network, and each consensus node can obtain the information stored in the blockchain network (for example, the current node weight of any consensus node) in the blockchain network. Before the node 90d is updated on the chain, the blockchain network includes blocks 9Q1, 9Q2, ... and 9Q n .

[0177] It is understandable that when the node 90d (i.e., the target consensus node) updates the result on the chain, it needs to obtain the block with the maximum generation timestamp from the blockchain network (for example, block 9Q shown in FIG9 ). n ) and block 9Q n The block hash value of is used as the parent block hash value of the block to be generated. Furthermore, node 90d can package the parent block hash value and the update result, and use the block generated after the packaging process as the block to be verified to be written into the blockchain network to which node 90d belongs.

[0178] At this point, node 90d can broadcast the block to be verified to the three backup nodes in the blockchain network where node 90d is located, so that these three backup nodes can each reach consensus on the obtained block to be verified, thereby obtaining a consensus result to be returned to node 90d. The number of consensus results returned by each backup node is equal to the number of consensus results corresponding to the node weight. For example, if the node weight of node 90a is 1, the node weight of node 90b is 1, the node weight of node 90c is 3, and the node weight of node 90d is 2, then the total node weight of the blockchain network is 7. At this time, the number of consensus results returned by node 90a is equivalent to one consensus result, the number of consensus results returned by node 90b is equivalent to one consensus result, the number of consensus results returned by node 90c is equivalent to three consensus results, and the number of consensus results generated by node 90d itself is equivalent to two consensus results.

[0179] Then, the node 90d can count the consensus results that are consistent from the received consensus results (the consensus results that are consistent can be understood as the consensus results of the affirmative votes in the consensus vote), and call the consensus results that are consistent with the statistics as the consensus result set, and then the sum of the node weights of the backup nodes corresponding to each consensus result in the consensus result set can be determined as the consensus number corresponding to the consensus result set. If the comparison between the consensus number and the total weight of the nodes corresponding to the blockchain network reaches the consensus threshold (for example, 2 / 3), it is determined that the consensus nodes in the blockchain network have reached a consensus, and then the block to be verified can be used as the target block to be used as block 9Q n The next block of the target block is successfully written to the blockchain network’s database, effectively ensuring the data security of the update result on the chain. Among them, the generation timestamp of the target block is used to update the maximum generation timestamp of the blockchain network.

[0180] Furthermore, if the consensus nodes in the blockchain network have not reached consensus, and the prediction rule associated with the blockchain network is the second prediction rule (i.e., the prediction result is determined to be positive by default through the node weight update instruction), the target consensus node can detect a consensus node in the blockchain network that is in an abnormal state and determine the detected consensus node as a second consensus node. Furthermore, the target consensus node can obtain the node weight of the second consensus node. If the node weight of the second consensus node is greater than the maximum number F of illegal nodes allowed by the blockchain network, the second consensus node can be restarted and its consensus state can be updated. If the consensus state of the second consensus node after the update returns to a normal state, consensus can be re-established on the acquired block to be verified. If the consensus state of the second consensus node after the update is still abnormal, the target consensus node can generate an alarm message associated with the second consensus node and send the alarm message to a management terminal device associated with the blockchain network, so that the management object corresponding to the management terminal device can process the second consensus node. It can be seen that in the scenario where node weight updates are implemented through weak rules, this application not only takes into account the timeliness of updating node weights, but also further sets up an abnormality checking mechanism in the consensus process after the node weights are updated. That is, by restarting the consensus nodes whose node weights are greater than the maximum number F of illegal nodes allowed by the blockchain network, these consensus nodes that will affect the consensus process of the blockchain network can be restored or alerted in time. Therefore, the security of implementing weak rules can be improved.

[0181] For ease of understanding, further, please refer to Figure 10, which is a schematic diagram of a scenario of a business consensus provided by an embodiment of the present application. As shown in Figure 10, taking the prediction rule associated with the blockchain network in the embodiment of the present application as the second prediction rule and the total number of nodes in the blockchain network as 4 as an example, it can specifically include node 100a, node 100b, node 100c and node 100d. For example, the node weight of node 100a can be 2, the node weight of node 100b can be 1, the node weight of node 100c can be 1, and the node weight of node 100d can be 1. At this time, the total node weight of the blockchain network is 5, and the maximum number of illegal nodes allowed by the blockchain network is 1.

[0182] If node 100a is in an abnormal state, the remaining nodes in the blockchain network will be unable to reach a consensus because the node weight of node 100a is greater than the maximum number of illegal nodes allowed by the blockchain network. Alternatively, if only node 100d is in an abnormal state, the blockchain network can still reach a consensus because the node weight of node 100a is equal to the maximum number of illegal nodes allowed by the blockchain network.

[0183] Based on this, when the target consensus node is chaining the block to be verified, if the consensus nodes in the blockchain network have not reached a consensus, the target consensus node needs to detect a consensus node in an abnormal state in the blockchain network and determine the detected consensus node as the second consensus node (for example, node 100a). Since if the node weight of node 100a is greater than the maximum number F of illegal nodes allowed by the blockchain network, the embodiment of the present application can instruct node 100a to restart through the target consensus node, thereby updating the consensus state of node 100a. If the consensus state of node 100a after the update returns to a normal state, consensus can be reached again on the acquired block to be verified.

[0184] Optionally, if the consensus state of node 100a after the update is abnormal, the target consensus node may generate an alarm message associated with node 100a and send the alarm message to a management terminal device associated with the blockchain network, so that the management object corresponding to the management terminal device processes node 100a. The alarm message here may be a voice, text, video, image, or other type of warning message, and the form of the alarm message is not limited here.

[0185] In an embodiment of the present application, if the first business organization wants to have greater decision-making power in the entire blockchain network, there is no need to increase the number of nodes of the first business organization. Instead, based on the idea of ​​node weight, by changing the node weight of the first consensus node, the proportion of voting information initiated by the first consensus node in the process of participating in the consensus business can be changed. This application uses this deployment method of changing the node weight to avoid the need to add new consensus nodes, and there is no need to perform various configuration operations required to create new consensus nodes, thereby reducing the workload of deploying nodes. Moreover, since the number of consensus nodes in the blockchain network has not increased, the resource consumption of the blockchain network will not be increased. Moreover, since the number of consensus nodes maintained and managed has not increased, the difficulty of maintaining and managing consensus nodes will not increase.

[0186] Further, please refer to Figure 11, which is a flow chart of a data processing method based on blockchain provided by an embodiment of the present application. The method involves a target consensus node (i.e., a master node with a proposal function) and a first consensus node in a blockchain network. The target consensus node here is not the first consensus node, but other consensus nodes in the blockchain network other than the first consensus node (e.g., a third consensus node). The method may include at least the following steps S201-S205:

[0187] In step S201, when the first consensus node obtains the node weight update instruction generated for the first consensus node, the first consensus node verifies the node weight update instruction and obtains a transaction verification result.

[0188] Among them, the transaction verification result is determined by the first consensus node based on the legitimacy verification result and the multi-signature verification result; the legitimacy verification result is generated by the first consensus node after performing legitimacy verification on the node weight update instruction; the multi-signature verification result is obtained by the first consensus node after performing multi-signature verification on the multi-party signature information carried in the node weight update instruction when it determines that the legitimacy verification result indicates that the node weight update instruction is legal.

[0189] Step S202: When the transaction verification result indicates that the verification is successful, the first consensus node broadcasts the node weight update instruction to the blockchain network.

[0190] Specifically, when the transaction verification result indicates that the verification is successful, the first consensus node can broadcast the node weight update instruction to other consensus nodes (for example, the third consensus node) in the blockchain network except the first consensus node.

[0191] Step S203: The target consensus node obtains a node weight update instruction generated for the first consensus node.

[0192] In step S204, the target consensus node predicts whether the updated node weight of the first consensus node meets the node update condition based on the node weight update instruction, and obtains a prediction result; in response to the prediction result being positive, the node weight of the first consensus node is updated according to the node weight update instruction to obtain an update result.

[0193] In step S205, the target consensus node records the update result in the database of the blockchain network.

[0194] The specific implementation of steps S201 to S205 can refer to the description of steps S101 to S103 in the embodiment corresponding to FIG3 , and will not be repeated here.

[0195] Furthermore, when the target consensus node is a master node with a proposal function in the blockchain network, and the block of the update result in the blockchain network is the target block (for example, the target block shown in FIG9 ), the target consensus node can obtain the block rules associated with the blockchain network. Among them, the block rules here can be block rules associated with the node weight (i.e., the first block rules) or block rules that are unrelated to the node weight (i.e., the second block rules). If the block rules are block rules associated with the node weight, the target consensus node can obtain the node weight of the target consensus node. Among them, the node weight of the target consensus node here is used to indicate the total number of blocks produced by the target consensus node in the current round.

[0196] If the number of blocks produced by the target consensus node in the current round does not reach the total number of blocks produced, the target consensus node can continue to determine itself as a master node with a proposal function, so that the target consensus node continues to put the next block of the target block on the chain. Wherein, each time the target consensus node puts a block on the chain, the number of blocks produced is accumulated once. Optionally, if the number of blocks produced by the target consensus node in the current round reaches the total number of blocks produced, the embodiment of the present application can determine the next node of the target consensus node determined based on the block production rules as a master node with a proposal function, so that the new master node puts the next block of the target block on the chain. It can be seen that the node weight of the present application can not only act on the process of consensus voting, but also determine the polling timing of the master node, that is, the consensus node with a higher node weight can have more opportunities to become a master node, further improving the influence of the node weight.

[0197] For ease of understanding, please further refer to Figure 12, which is a schematic diagram of a scenario for rotating master nodes provided in an embodiment of the present application. As shown in Figure 12, the total number of nodes in the blockchain network in the embodiment of the present application can be 4, for example, specifically including node 120a, node 120b, node 120c, and node 120d. For example, the node weight of node 120a can be 2, the node weight of node 120b can be 1, the node weight of node 120c can be 1, and the node weight of node 120d can be 3.

[0198] It is understood that if the block generation rule associated with the blockchain network is the first block generation rule (i.e., the block generation rule associated with the node weight), then the node weight of each consensus node is used to indicate the total number of blocks generated by the node in the current round. The polling order of the master node in a certain round in the blockchain network can be node 120a, node 120a (i.e., node 120a can be the master node twice in a row, i.e., it can chain two blocks in a row), node 120b, node 120c, node 120d, node 120d, and node 120d (i.e., node 120d can be the master node three times in a row, i.e., it can chain three blocks in a row). Among them, the first parameter included in the parameter 12R shown in Figure 12 is 1, which is used to indicate that the block height of the new block generated by the current master node (i.e., node 120a) is 1, and the second parameter in the parameter 12R is 0, which is used to indicate that the current round is the first round.

[0199] Taking node 120d as an example, after node 120d has chained the 5th block, it has produced blocks for the first time in the current round. Since the node weight of node 120d is 3, this means that the number of blocks produced by node 120d in the first round has not yet reached the total number of blocks produced. At this time, node 120d can continue to be the master node to chain the next block after the 5th block (i.e., the 6th block). When the 7th block is successfully chained, the number of blocks produced by node 120d in the current round is the third time, which is equal to the corresponding total number of blocks produced. Therefore, another node will be replaced as the master node (such as node 120a).

[0200] As shown in FIG12 , when node 120a is chaining the 8th block, it is in an abnormal state. In this case, the block generation rule in the embodiment of the present application can determine the next node of node 120a (for example, node 120b) as the master node according to the round order associated with the first block generation rule, so that node 120b continues to chain the 8th block.

[0201] It is understood that if the block generation rule associated with the blockchain network is the second block generation rule (i.e., a block generation rule that is unrelated to the node weight), then the number of blocks generated by each consensus node in the current round is 1. The polling order of the master node in a certain round in the blockchain network may be node 120a, node 120b, node 120c, and node 120d.

[0202] As shown in FIG12 , when node 120b is chaining the sixth block, it is in an abnormal state. In this case, the block generation rule in the embodiment of the present application can determine the next node of node 120b (for example, node 120c) as the master node according to the round order associated with the second block generation rule, so that node 120c continues to chain the sixth block.

[0203] Further, referring to Figure 13, which is a flowchart illustrating a blockchain-based data processing method provided in an embodiment of the present application. This method can be executed by a target consensus node in a blockchain network, where the target consensus node is the first consensus node whose node weight is to be configured, and is also the master node in the blockchain network with a proposal function.

[0204] As shown in FIG13 , when the target consensus node receives the node weight update instruction generated for the first consensus node, the target consensus node can perform a validity verification on the node weight update instruction (i.e., verify the primary signature information and instruction format carried by the node weight update instruction respectively) to obtain a validity verification result, and then execute step S131 to determine whether the validity verification result indicates that the verification is successful. If the validity verification result indicates that the verification failed (i.e., the node weight update instruction is not valid), the target consensus node can jump to step S138 and discard the node weight update instruction.

[0205] If the legitimacy verification result indicates that the verification is successful (i.e., the node weight update instruction is valid), the target consensus node can continue to perform multi-signature verification on the multi-signature information carried by the node weight update instruction to obtain the multi-signature verification result, and then execute step S132 to determine whether the multi-signature verification result indicates that the verification is successful. If the multi-signature verification result indicates that the verification failed, the target consensus node can jump to step S138 and discard the node weight update instruction.

[0206] If the multi-signature verification result indicates a successful verification, the target consensus node may broadcast the node weight update instruction to other nodes in the blockchain network. Then, if the target consensus node is a master node in the blockchain network, the target consensus node may proceed to step S133 to obtain the prediction rules associated with the blockchain network.

[0207] It is understandable that if the prediction rule is the first prediction rule, the target consensus node can execute steps S134-S136: that is, the target consensus node can execute step S134 to obtain the node weight list corresponding to the blockchain network, and then execute step S135 based on the configuration weight of the first consensus node in the node weight update instruction and the node weight list to determine whether the configuration weight meets the node update condition. If the configuration weight does not meet the node update condition, the target consensus node can jump to step S138 and discard the node weight update instruction. If the configuration weight meets the node update condition, the target consensus node can continue to execute step S136, that is, based on the configuration weight, update the node weight of the first consensus node to obtain an updated result.

[0208] Alternatively, if the prediction rule is the second prediction rule, the target consensus node may configure the weight to meet the node update condition by default, i.e., the process may directly jump to step S136 to update the node weight of the first consensus node based on the configured weight to obtain an updated result. Then, when the target consensus node reaches a consensus with the consensus nodes in the blockchain network, it writes the updated result to the database in the blockchain network.

[0209] Furthermore, the target consensus node may also execute step S137 to update the node weight list based on the configuration weight of the first consensus node in the update result to obtain an updated node weight list. At the same time, the target consensus node may also update the maximum number of illegal nodes allowed in the blockchain network based on the configuration weight of the first consensus node in the update result to obtain an updated maximum number F.

[0210] In the embodiments of the present application, a new node deployment method is proposed to address the existing blockchain network solution that requires multiple consensus nodes to achieve weighting. Based on the concept of weighting, a processing model is proposed in which consensus nodes themselves support weighting. Furthermore, this model supports both strong and weak prediction rules, allowing users to choose based on their actual business scenarios, thereby improving business adaptability. Furthermore, it still meets the 3F+1 rule in terms of security, without compromising security due to node weighting. By changing the node weighting method, the present application eliminates the need to add new consensus nodes and perform the various configuration operations required to create new consensus nodes, thereby reducing the workload of deploying nodes. Furthermore, since the number of consensus nodes in the blockchain network does not increase, there is no additional increase in resource consumption of the blockchain network. Furthermore, since the number of consensus nodes to be maintained and managed does not increase, the difficulty of maintaining and managing consensus nodes is not increased.

[0211] Further, please refer to Figure 14, which is a schematic diagram of the structure of a blockchain-based data processing device provided in an embodiment of the present application. As shown in Figure 14, the blockchain-based data processing device 1 can be a computer program (including program code) running on a computer device. For example, the blockchain-based data processing device 1 is an application software; the blockchain-based data processing device 1 can be used to perform the corresponding steps of the method provided in an embodiment of the present application. As shown in Figure 14, the blockchain-based data processing device 1 can run on a target consensus node, which can be any consensus node in the blockchain network in the embodiment corresponding to Figure 1 above. The blockchain-based data processing device 1 can include: an acquisition module 11, an update processing module 12, a write module 13, a legitimacy verification module 15, a multi-signature verification module 16, an execution module 17, a block rule acquisition module 18, a target weight acquisition module 19, and a master node determination module 20.

[0212] The acquisition module 11 is used to obtain a node weight update instruction generated for a first consensus node in the blockchain network, where the node weight update instruction is used to instruct to update the node weight of the voting information configured for the first consensus node in the consensus business;

[0213] The update processing module 12 is configured to predict whether the node weight of the updated first consensus node meets the node update condition based on the node weight update instruction, and obtain a prediction result;

[0214] The update processing module 12 is further configured to update the node weight of the first consensus node according to the node weight update instruction in response to the prediction result being positive, to obtain an updated result.

[0215] The first consensus node belongs to the N consensus nodes included in the blockchain network, where N is a positive integer;

[0216] The update processing module 12 includes: a list acquisition unit 121 , a quantity determination unit 122 , a comparison unit 123 , a first update unit 124 , a discarding unit 125 , a first acquisition unit 126 , a second acquisition unit 127 and a second update unit 128 .

[0217] The list acquisition unit 121 is used to obtain a node weight list corresponding to the blockchain network based on the node weight update instruction; the node weight list includes the node weight corresponding to each consensus node in the N consensus nodes;

[0218] The number determination unit 122 is used to determine the maximum number F of illegal nodes allowed by the blockchain network based on the N node weights and the configuration weight carried by the node weight update instruction; the configuration weight is the predicted node weight of the updated first consensus node.

[0219] The quantity determining unit 122 includes an acquiring subunit 1221 , a summing subunit 1222 and a determining subunit 1223 .

[0220] The acquisition subunit 1221 is used to acquire (N-1) node weights excluding the node weight of the first consensus node from the N node weights;

[0221] The summing subunit 1222 is used to sum the (N-1) node weights and the configuration weights carried by the node weight update instruction to obtain the total node weight H corresponding to the blockchain network; H is a positive integer;

[0222] The determination subunit 1223 is configured to determine the maximum number F of illegal nodes allowed in the blockchain network based on the total node weight H and the node configuration rule corresponding to the blockchain network. The node configuration rule is H = 3F + 1, where H is the total node weight and F is the maximum number of illegal nodes allowed in the blockchain network.

[0223] The specific implementation of the acquisition subunit 1221, the summing subunit 1222 and the determination subunit 1223 can refer to the description of the maximum number of illegal nodes in the embodiment corresponding to FIG3 above, which will not be further described here.

[0224] The comparison unit 123 is used to compare the configuration weight and the maximum number F to obtain a comparison result;

[0225] The first updating unit 124 is configured to determine that the prediction result is positive if the comparison result indicates that the configuration weight is less than or equal to the maximum number F; a positive prediction result indicates that the configuration weight satisfies the node update condition.

[0226] The update processing module 12 is used to update the node weight of the first consensus node according to the node weight update instruction in response to the prediction result being positive, and when obtaining the updated result, is specifically used to perform the following operations:

[0227] In response to the prediction result being positive, the node weight of the first consensus node is updated according to the configuration weight in the node weight update instruction to obtain an updated result; the configuration weight of the first consensus node in the updated result is used to update the node weight list.

[0228] The discarding unit 125 is used to determine that the prediction result is negative and discard the node weight update instruction if the comparison result indicates that the configuration weight is greater than the maximum number F; a negative prediction result indicates that the configuration weight does not meet the node update condition.

[0229] The first acquisition unit 126 is used to obtain the configuration weight carried by the node weight update instruction, and determine by default that the prediction result is positive according to the node weight update instruction; the configuration weight is the predicted node weight of the first consensus node after the update; a positive prediction result indicates that the configuration weight meets the node update condition;

[0230] The second obtaining unit 127 is configured to obtain the node weight of the first consensus node from the blockchain network in response to the prediction result being positive;

[0231] The second updating unit 128 is configured to update the node weight of the first consensus node to the configured weight in the node weight update instruction to obtain an updated result.

[0232] Among them, the specific implementation methods of the list acquisition unit 121, the quantity determination unit 122, the comparison unit 123, the first update unit 124, the discarding unit 125, the first acquisition unit 126, the second acquisition unit 127 and the second update unit 128 can be referred to the description of step S102 in the embodiment corresponding to Figure 3 above, and will not be repeated here.

[0233] The writing module 13 is used to record the update results into the database of the blockchain network.

[0234] The target consensus node is the master node with the proposal function in the blockchain network; the target consensus node belongs to the N consensus nodes included in the blockchain network; N is a positive integer equal to (3F+1); F is the maximum number of illegal nodes allowed in the blockchain network;

[0235] The writing module 13 includes: a packaging unit 1301, a broadcasting unit 1302, a statistics unit 1303, a consensus determination unit 1304, a writing unit 1305, a detection unit 1306, a third acquisition unit 1307, a restart unit 1308, a consensus unit 1309 and an information generation unit 1310.

[0236] The packaging unit 1301 is used to package the update results to obtain a block to be verified to be written into the blockchain network;

[0237] The broadcast unit 1302 is configured to broadcast the block to be verified to (N-1) backup nodes in the blockchain network, so that the (N-1) backup nodes reach a consensus on the block to be verified and obtain a consensus result; the (N-1) backup nodes are the consensus nodes other than the target consensus node among the N consensus nodes;

[0238] The counting unit 1303 is configured to count consensus results that are consistent from the received consensus results, and determine the consensus results that are consistent with the count as a consensus result set;

[0239] The consensus determining unit 1304 is configured to determine the sum of the node weights of the backup nodes corresponding to each consensus result in the consensus result set as the consensus quantity corresponding to the consensus result set;

[0240] The writing unit 1305 is used to determine that the consensus nodes in the blockchain network have reached a consensus if the ratio between the number of consensuses and the total weight of the nodes corresponding to the blockchain network reaches a consensus threshold, and write the block to be verified as a target block into the database in the blockchain network; the total node weight refers to the sum of the node weights of N consensus nodes; the target block written into the database in the blockchain network is used to indicate that the updated node weight of the first consensus node can perform weighted processing on the voting information of the first consensus node in the consensus business.

[0241] The detection unit 1306 is configured to detect a consensus node in an abnormal state in the blockchain network if the consensus nodes in the blockchain network fail to reach a consensus and the prediction result is determined to be positive by default through the node weight update instruction, and determine the detected consensus node as a second consensus node;

[0242] The third obtaining unit 1307 is used to obtain the node weight of the second consensus node;

[0243] The restart unit 1308 is configured to restart the second consensus node and update the consensus state of the second consensus node if the node weight of the second consensus node is greater than the maximum number F of illegal nodes allowed by the blockchain network;

[0244] The consensus unit 1309 is configured to re-conclude consensus on the acquired block to be verified if the consensus state of the updated second consensus node is restored to a normal state.

[0245] The information generating unit 1310 is configured to generate alarm information associated with the second consensus node if the consensus state of the updated second consensus node is an abnormal state, and send the alarm information to a management terminal device associated with the blockchain network.

[0246] Among them, the specific implementation methods of the packaging unit 1301, the broadcasting unit 1302, the statistics unit 1303, the consensus determination unit 1304, the writing unit 1305, the detection unit 1306, the third acquisition unit 1307, the restart unit 1308, the consensus unit 1309 and the information generation unit 1310 can be found in the description of step S103 in the embodiment corresponding to Figure 3 above, and will not be further described here.

[0247] Wherein, the first consensus node belongs to the N consensus nodes included in the blockchain network; N is a positive integer; one consensus node corresponds to one business organization; the business organization corresponding to the first consensus node is the first business organization; the node weight update instruction is generated by the first terminal device of the first business organization in response to the configuration operation of the first object on the node weight of the first consensus node;

[0248] The acquisition module 11 is specifically configured to receive a node weight update instruction sent by a first terminal device; the node weight update instruction carries primary signature information and multi-party signature information; the primary signature information is obtained by the first terminal device signing the node weight update instruction based on the first private key of the first object; the multi-party signature information is obtained by multi-party signing the node weight update instruction based on the second private key of the second object associated with M second business organizations; the second business organization is a business organization other than the first business organization among the N business organizations; and M is a positive integer less than N and greater than a signature threshold.

[0249] The legitimacy verification module 15 is used to verify the legitimacy of the node weight update instruction based on the first public key and the primary signature information of the first object to obtain a legitimacy verification result.

[0250] The legitimacy verification module 15 includes: a signature verification unit 151 , a verification unit 152 , a first generation unit 153 and a second generation unit 154 .

[0251] The signature verification unit 151 is configured to verify the primary signature information based on the first public key of the first object to obtain a primary signature verification result;

[0252] The verification unit 152 is used to verify the instruction format of the node weight update instruction based on the smart contract on the blockchain network to obtain a verification result;

[0253] The first generating unit 153 is configured to generate a validity verification result indicating that the node weight update instruction is valid if the primary signature verification result indicates that the verification is successful and the verification result indicates that the verification is successful;

[0254] The second generating unit 154 is configured to generate a validity verification result indicating that the node weight update instruction is not valid if the primary signature verification result indicates a verification failure or the verification result indicates a verification failure.

[0255] Among them, the specific implementation methods of the signature verification unit 151, the verification unit 152, the first generation unit 153 and the second generation unit 154 can refer to the description of the legitimacy verification of the node weight update instruction in the embodiment corresponding to Figure 3 above, and will not be further described here.

[0256] The multi-signature verification module 16 is configured to perform multi-signature verification on the multi-party signature information based on the second public keys corresponding to the second objects associated with the M second business institutions to obtain a multi-signature verification result if the legitimacy verification result indicates that the node weight update instruction is legitimate;

[0257] The execution module 17 is used to notify the update processing module 12 to execute the node weight update instruction to predict whether the node weight of the updated first consensus node meets the node update condition when the multi-signature verification result indicates that the verification is successful, and obtain a prediction result.

[0258] Among them, if the target consensus node is a master node with a proposal function in the blockchain network and is not the first consensus node, the node weight update instruction obtained by the target consensus node is submitted by the first consensus node when it determines that the multi-signature verification result indicates that the verification is successful; the multi-signature verification result is obtained by the first consensus node after performing multi-signature verification on the multi-party signature information carried in the node weight update instruction when it determines that the legitimacy verification result indicates that the node weight update instruction is legitimacy; the legitimacy verification result is generated by the first consensus node after performing legitimacy verification on the received node weight update instruction.

[0259] The target consensus node is the master node with the proposal function in the blockchain network; the block containing the update result in the blockchain network is the target block;

[0260] The block generation rule acquisition module 18 is used to obtain the block generation rules associated with the blockchain network;

[0261] The target weight acquisition module 19 is used to obtain the node weight of the target consensus node if the block generation rule is a block generation rule associated with the node weight; the node weight of the target consensus node is used to indicate the total number of blocks generated by the target consensus node in the current round;

[0262] The master node determination module 20 is used to continue to determine the target consensus node as a master node with a proposal function if the number of blocks produced by the target consensus node in the current round has not reached the total number of blocks produced, so that the target consensus node can put the next block of the target block on the chain.

[0263] Among them, the specific implementation of the acquisition module 11, update processing module 12, writing module 13, legitimacy verification module 15, multi-signature verification module 16, execution module 17, block rule acquisition module 18, target weight acquisition module 19 and master node determination module 20 can be found in the description of steps S101 to S103 in the embodiment corresponding to FIG3 and steps S201 to S205 in the embodiment corresponding to FIG11, and steps S131 to S137 in the embodiment corresponding to FIG13, and will not be further described here. In addition, the description of the beneficial effects of using the same method will not be repeated.

[0264] Further, please refer to Figure 15, which is a schematic diagram of a computer device provided in an embodiment of the present application. As shown in Figure 15, the computer device 1000 may include: at least one processor 1001, for example, a CPU, at least one network interface 1004, a memory 1005, and at least one communication bus 1002. Among them, the communication bus 1002 is used to realize the connection communication between these components. The network interface 1004 may optionally include a standard wired interface, a wireless interface (such as a WI-FI interface). The memory 1005 may be a high-speed RAM memory or a non-volatile memory (non-volatile memory), such as at least one disk storage. The memory 1005 may also be at least one storage device located away from the aforementioned processor 1001. As shown in Figure 15, the memory 1005 as a computer storage medium may include an operating system, a network communication module, a user interface module, and a device control application. In some embodiments, the computer device may further include the user interface 1003 shown in FIG15 . For example, if the computer device is a terminal device, the computer device may further include the user interface 1003 , wherein the user interface 1003 may include a display screen (Display), a keyboard (Keyboard), and the like.

[0265] In the computer device 1000 shown in FIG15 , the network interface 1004 is mainly used for network communication; the user interface 1003 is mainly used for providing an interface for user input; and the processor 1001 can be used to call the device control application stored in the memory 1005 to implement:

[0266] Obtaining a node weight update instruction generated for a first consensus node in the blockchain network, where the node weight update instruction is used to instruct an update of the node weight of voting information configured for the first consensus node in a consensus service;

[0267] Based on the node weight update instruction, predict whether the updated node weight of the first consensus node meets the node update condition and obtain the prediction result;

[0268] In response to the prediction result being positive, updating the node weight of the first consensus node according to the node weight update instruction to obtain an updated result;

[0269] Record the updated results in the blockchain network's database.

[0270] It should be understood that the computer device 1000 described in the embodiments of the present application can execute the description of the data processing method based on the blockchain network in the embodiments corresponding to Figures 3, 11, and 13 above, and can also execute the description of the data processing device 1 based on the blockchain network in the embodiment corresponding to Figure 14 above, which will not be repeated here. In addition, the description of the beneficial effects of using the same method will not be repeated here.

[0271] An embodiment of the present application further provides a computer-readable storage medium storing a computer program, wherein the computer program includes program instructions. When the program instructions are executed by a processor, the data processing method based on the blockchain network provided in each step of Figures 3, 11, and 13 is implemented. For details, please refer to the implementation methods provided in each step of Figures 3, 11, and 13, which will not be repeated here.

[0272] The computer-readable storage medium may be the data transmission device provided in any of the aforementioned embodiments or the internal storage unit of the computer device, such as the hard disk or memory of the computer device. The computer-readable storage medium may also be an external storage device of the computer device, such as a plug-in hard disk, a smart media card (SMC), a secure digital (SD) card, a flash card, etc. equipped on the computer device. Furthermore, the computer-readable storage medium may also include both the internal storage unit of the computer device and an external storage device. The computer-readable storage medium is used to store the computer program and other programs and data required by the computer device. The computer-readable storage medium may also be used to temporarily store data that has been output or is to be output.

[0273] The present application also provides a computer program product, comprising a computer program stored in a computer-readable storage medium. A processor of a computer device reads the computer program from the computer-readable storage medium and executes the computer program, enabling the computer device to perform the descriptions of the blockchain network-based data processing methods or apparatuses described in the preceding embodiments, which are not further detailed here. Furthermore, the descriptions of the beneficial effects of employing the same methods are also not further detailed.

[0274] The terms "first", "second", etc. in the description, claims, and drawings of the embodiments of the present application are used to distinguish different objects, rather than to describe a specific order. In addition, the terms "comprising" and any variations thereof are intended to cover non-exclusive inclusions. For example, a process, method, apparatus, product, or device that includes a series of steps or units is not limited to the listed steps or modules, but may optionally include steps or modules that are not listed, or may optionally include other steps and units inherent to these processes, methods, apparatuses, products, or devices.

[0275] Those skilled in the art will appreciate that the units and algorithm steps of each example described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, computer software, or a combination of the two. In order to clearly illustrate the interchangeability of hardware and software, the composition and steps of each example have been generally described in terms of function in the above description. Whether these functions are performed in hardware or software depends on the specific application and design constraints of the technical solution. Professional and technical personnel can use different methods to implement the described functions for each specific application, but such implementation should not be considered to be beyond the scope of this application.

[0276] The above disclosure is only a preferred embodiment of the present application, and certainly cannot be used to limit the scope of rights of the present application. Therefore, equivalent changes made according to the claims of the present application are still within the scope covered by the present application.

Claims

1. A data processing method based on blockchain, characterized in that: The method is performed by a target consensus node and includes: Obtaining a node weight update instruction generated for a first consensus node in a blockchain network, wherein the node weight update instruction is used to instruct to update a node weight of voting information configured for the first consensus node in a consensus service; Predicting whether the updated node weight of the first consensus node meets the node update condition based on the node weight update instruction, and obtaining a prediction result; In response to the prediction result being positive, updating the node weight of the first consensus node according to the node weight update instruction to obtain an update result; The update result is recorded in the database of the blockchain network.

2. The method according to claim 1, characterized in that The first consensus node belongs to N consensus nodes included in the blockchain network, where N is a positive integer; The predicting, based on the node weight update instruction, whether the updated node weight of the first consensus node meets the node update condition, and obtaining the prediction result includes: Obtain a node weight list corresponding to the blockchain network based on the node weight update instruction; the node weight list includes the node weight corresponding to each consensus node in the N consensus nodes; Determine the maximum number F of illegal nodes allowed by the blockchain network based on the N node weights and the configuration weight carried by the node weight update instruction; the configuration weight is the predicted updated node weight of the first consensus node; Comparing the configuration weight with the maximum number F to obtain a comparison result; If the comparison result indicates that the configuration weight is less than or equal to the maximum number F, the prediction result is determined to be positive; the prediction result having a positive value indicates that the configuration weight satisfies the node update condition.

3. The method according to claim 2, characterized in that In response to the prediction result being positive, updating the node weight of the first consensus node according to the node weight update instruction to obtain an update result, including: In response to the prediction result being positive, the node weight of the first consensus node is updated according to the configuration weight in the node weight update instruction to obtain an update result; the configuration weight of the first consensus node in the update result is used to update the node weight list.

4. The method according to claim 2 or 3, characterized in that: The determining, based on the N node weights and the configuration weights carried by the node weight update instruction, the maximum number F of illegal nodes allowed by the blockchain network includes: From the N node weights, obtain (N-1) node weights other than the node weight of the first consensus node; The (N-1) node weights and the configuration weights carried by the node weight update instruction are summed to obtain a total node weight H corresponding to the blockchain network; H is a positive integer; Based on the total node weight H and the node configuration rules corresponding to the blockchain network, the maximum number F of illegal nodes allowed by the blockchain network is determined.

5. The method according to claim 4, characterized in that The node configuration rule is H=3F+1, where H is the total weight of the node and F is the maximum number of illegal nodes allowed by the blockchain network.

6. The method according to any one of claims 2 to 5, characterized in that: The method further comprises: If the comparison result indicates that the configuration weight is greater than the maximum number F, the prediction result is determined to be negative and the node weight update instruction is discarded; a negative prediction result indicates that the configuration weight does not meet the node update condition.

7. The method according to claim 1, characterized in that The predicting, based on the node weight update instruction, whether the updated node weight of the first consensus node meets the node update condition, and obtaining the prediction result includes: Obtaining a configuration weight carried by the node weight update instruction; the configuration weight is the predicted updated node weight of the first consensus node; According to the node weight update instruction, the prediction result is determined to be positive by default; the prediction result having a positive value indicates that the configuration weight satisfies the node update condition; In response to the prediction result being positive, updating the node weight of the first consensus node according to the node weight update instruction to obtain an update result, including: In response to the prediction result being positive, obtaining a node weight of the first consensus node from the blockchain network; The node weight of the first consensus node is updated to the configuration weight in the node weight update instruction to obtain an update result.

8. The method according to any one of claims 1 to 7, characterized in that: The target consensus node is a master node with a proposal function in the blockchain network; the target consensus node belongs to the N consensus nodes included in the blockchain network; N is a positive integer equal to (3F+1); F is the maximum number of illegal nodes allowed by the blockchain network; The step of recording the update result to the database of the blockchain network includes: The update results are packaged to obtain a block to be verified to be written into the blockchain network; Broadcasting the block to be verified to (N-1) backup nodes in the blockchain network, so that the (N-1) backup nodes reach a consensus on the block to be verified and obtain a consensus result; the (N-1) backup nodes refer to the consensus nodes among the N consensus nodes except the target consensus node; From the received consensus results, the consensus results with the same consensus are counted, and the consensus results with the same consensus are determined as the consensus result set; Determine the sum of the node weights of the backup nodes corresponding to each consensus result in the consensus result set as the consensus quantity corresponding to the consensus result set; If the ratio between the number of consensuses and the total weight of the nodes corresponding to the blockchain network reaches a consensus threshold, it is determined that the consensus nodes in the blockchain network have reached a consensus, and the block to be verified is written into the database in the blockchain network as a target block; the total node weight refers to the sum of the node weights of the N consensus nodes; the target block written into the database in the blockchain network is used to indicate that the updated node weight of the first consensus node can perform weighted processing on the voting information of the first consensus node in the consensus business.

9. The method according to claim 8, characterized in that The method further comprises: If the consensus nodes in the blockchain network fail to reach a consensus, and the prediction result is determined to be positive by default through the node weight update instruction, a consensus node in an abnormal state is detected in the blockchain network, and the detected consensus node is determined as a second consensus node; Obtaining the node weight of the second consensus node; If the node weight of the second consensus node is greater than the maximum number F of illegal nodes allowed by the blockchain network, the second consensus node is restarted and the consensus state of the second consensus node is updated; If the consensus state of the updated second consensus node is restored to a normal state, consensus is performed again on the acquired block to be verified.

10. The method according to claim 9, characterized in that The method further comprises: If the consensus state of the updated second consensus node is an abnormal state, an alarm message associated with the second consensus node is generated, and the alarm message is sent to a management terminal device associated with the blockchain network.

11. The method according to any one of claims 1 to 10, characterized in that: The target consensus node is a master node with a proposal function in the blockchain network; the block containing the update result in the blockchain network is the target block; The method further comprises: Obtaining a block generation rule associated with the blockchain network; If the block generation rule is a block generation rule associated with a node weight, the node weight of the target consensus node is obtained; the node weight of the target consensus node is used to indicate the total number of blocks generated by the target consensus node in the current round; If the number of blocks produced by the target consensus node in the current round does not reach the total number of blocks produced, the target consensus node will continue to be determined as the master node with the proposal function, and the next block of the target block will be put on the chain.

12. The method according to any one of claims 1 to 11, characterized in that: The first consensus node belongs to the N consensus nodes included in the blockchain network; N is a positive integer; one consensus node corresponds to one business organization; the business organization corresponding to the first consensus node is the first business organization; the node weight update instruction is generated by the first terminal device of the first business organization in response to the configuration operation of the first object on the node weight of the first consensus node; The obtaining of a node weight update instruction generated for a first consensus node in the blockchain network includes: Receive a node weight update instruction sent by the first terminal device; the node weight update instruction carries primary signature information and multi-party signature information; the primary signature information is obtained after the first terminal device signs the node weight update instruction based on the first private key of the first object; the multi-party signature information is obtained after the node weight update instruction is multi-signed based on the second private key of the second object associated with M second business institutions; the second business institution is a business institution other than the first business institution among the N business institutions; M is a positive integer less than N and greater than the signature threshold; The method further comprises: Based on the first public key of the first object and the primary signature information, the node weight update instruction is subjected to a legitimacy verification to obtain a legitimacy verification result; If the legitimacy verification result indicates that the node weight update instruction is legitimate, then based on the second public keys respectively corresponding to the second objects associated with the M second business organizations, multi-signature verification is performed on the multi-party signature information to obtain a multi-signature verification result; When the multi-signature verification result indicates that the verification is successful, the step of predicting whether the updated node weight of the first consensus node meets the node update condition based on the node weight update instruction is performed to obtain a prediction result.

13. The method according to claim 12, characterized in that The step of performing legitimacy verification on the node weight update instruction based on the first public key of the first object and the primary signature information to obtain a legitimacy verification result includes: Based on the first public key of the first object, verify the primary signature information to obtain a primary signature verification result; Based on the smart contract on the blockchain network, verify the instruction format of the node weight update instruction to obtain a verification result; If the primary signature verification result indicates that the verification is successful, and the verification result indicates that the verification is successful, then a legitimacy verification result is generated to indicate that the node weight update instruction is legitimate; If the primary signature verification result indicates a verification failure, or the verification result indicates a verification failure, a legitimacy verification result is generated to indicate that the node weight update instruction is not legitimate.

14. The method according to any one of claims 1 to 13, characterized in that: If the target consensus node is a master node with a proposal function in the blockchain network and is not the first consensus node, the node weight update instruction obtained by the target consensus node is submitted by the first consensus node when it determines that the multi-signature verification result indicates that the verification is successful; the multi-signature verification result is obtained by the first consensus node after performing multi-signature verification on the multi-party signature information carried in the node weight update instruction when it determines that the legitimacy verification result indicates that the node weight update instruction is legitimacy; the legitimacy verification result is generated by the first consensus node after performing legitimacy verification on the received node weight update instruction.

15. A blockchain network, characterized in that: include: N consensus nodes; N is a positive integer; One consensus node corresponds to one node weight; the N consensus nodes include a first consensus node and a target consensus node; The target consensus node is used to obtain a node weight update instruction generated for a first consensus node in the blockchain network, and the node weight update instruction is used to instruct to update the node weight of the voting information configured for the first consensus node in the consensus business; the target consensus node is also used to predict whether the node weight of the updated first consensus node meets the node update condition based on the node weight update instruction, and obtain a prediction result; the target consensus node is also used to update the node weight of the first consensus node according to the node weight update instruction in response to the prediction result being positive, obtain an update result, and record the update result in the database of the blockchain network.

16. The blockchain network according to claim 15, characterized in that: The first consensus node is used to broadcast the node weight update instruction to the target consensus node when it is determined that the instruction verification result of the node weight update instruction indicates that the verification is successful; the instruction verification result is determined by the first consensus node based on the legitimacy verification result and the multi-signature verification result; the legitimacy verification result is generated after the first consensus node performs legitimacy verification on the node weight update instruction; the multi-signature verification result is obtained after the first consensus node performs multi-signature verification on the multi-party signature information carried in the node weight update instruction when it is determined that the legitimacy verification result indicates that the node weight update instruction is legitimacy.

17. A data processing device based on blockchain, characterized in that: include: An acquisition module, used to acquire a node weight update instruction generated for a first consensus node in a blockchain network, wherein the node weight update instruction is used to instruct to update the node weight of voting information configured for the first consensus node in a consensus service; An update processing module, configured to predict whether the updated node weight of the first consensus node meets the node update condition based on the node weight update instruction, and obtain a prediction result; The update processing module is further configured to update the node weight of the first consensus node according to the node weight update instruction in response to the prediction result being positive, to obtain an update result; A writing module is used to record the update result into the database of the blockchain network.

18. A computer device, characterized in that: include: processor and memory and network interface; The processor is connected to the memory and the network interface, wherein the network interface is used to provide a data communication function, the memory is used to store a computer program, and the processor is used to call the computer program so that the computer device executes the method described in any one of claims 1 to 14.

19. A computer-readable storage medium, characterized in that: The computer-readable storage medium stores a computer program, and the computer program is suitable for being loaded and executed by a processor, so that a computer device having the processor executes the method according to any one of claims 1 to 14.

20. A computer program product, characterized in that The computer program product comprises a computer program, which is stored in a computer-readable storage medium. The computer program is suitable for being read and executed by a processor, so that a computer device having the processor executes the method according to any one of claims 1 to 14.

Images