Consensus parameter updating method and device, storage medium and computer equipment
By updating the consensus parameters of the blockchain network in real time, the problem of poor adaptability of the consensus mechanism to the network environment is solved, and the performance and security of the blockchain are improved.
Patent Information
- Application Number
- CN202311344430.0
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- Filing Date
- 2023-10-17
- Publication Date
- 2025-04-18
AI Technical Summary
The consensus mechanism in existing blockchain technology is poorly adaptable to the network environment, resulting in a decline in blockchain performance.
By obtaining the network status information of the blockchain network, comparing it with the preset reference network status information, determining the consensus parameter adjustment value corresponding to the network status deviation information, calculating the target consensus parameters, and updating the consensus parameters of the blockchain network.
It improves the adaptability of blockchain networks to the network environment and improves the performance of blockchain, including improving security, reducing network congestion, improving transaction processing efficiency and accounting efficiency.
Smart Images

Figure CN119853932A_ABST
Abstract
Description
Technical Field
[0001] The present disclosure relates to the field of blockchain technology, and in particular to a consensus parameter updating method, device, storage medium and computer equipment. Background Art
[0002] In recent years, blockchain technology has developed rapidly. Compared with traditional networks, blockchain technology has two major characteristics: decentralization and data is difficult to tamper with, which makes the information recorded in the blockchain more authentic and reliable, and can solve the problem of mutual distrust between objects and central nodes tampering with data. Among them, the four core technologies of blockchain technology include: distributed ledger, consensus mechanism, smart contract and asymmetric encryption technology.
[0003] Among them, the consensus mechanism is a mechanism to coordinate the consistency of all node accounts, including the mechanism of agreeing on how to record accounts and the mechanism of agreeing on how to exchange information between nodes to keep node accounts consistent. However, the consensus mechanism in related technologies has poor adaptability to the blockchain network environment, which will reduce the performance of the blockchain. Summary of the invention
[0004] The embodiments of the present disclosure provide a consensus parameter updating method, apparatus, storage medium and computer equipment, which can improve the adaptability of the blockchain network to the network environment, thereby improving the performance of the blockchain.
[0005] According to one aspect of the present disclosure, a consensus parameter updating method is provided, comprising:
[0006] Get network status information in the blockchain network;
[0007] Comparing the network status information with preset reference network status information to obtain network status deviation information;
[0008] Determine the consensus parameter adjustment value corresponding to the network state deviation information based on the constraint relationship between the network state information and the consensus parameters, wherein the consensus parameters include the amount of pre-stored virtual resources, the amount of virtual resources rewarded or punished, and the block interval time;
[0009] Calculate the target consensus parameter according to the consensus parameter adjustment value and the current consensus parameter of the blockchain network;
[0010] The consensus parameters of the blockchain network are updated based on the target consensus parameters.
[0011] According to one aspect of the present disclosure, a consensus parameter updating device is provided, comprising:
[0012] An acquisition unit, used to acquire network status information in the blockchain network;
[0013] A comparing unit, used to compare the network state information with preset reference network state information to obtain network state deviation information;
[0014] A determination unit, configured to determine a consensus parameter adjustment value corresponding to the network state deviation information based on a constraint relationship between the network state information and consensus parameters, wherein the consensus parameters include a pre-stored virtual resource amount, a rewarded or punished virtual resource amount, and a block generation interval;
[0015] A calculation unit, configured to calculate a target consensus parameter according to the consensus parameter adjustment value and a current consensus parameter of the blockchain network;
[0016] An updating unit is used to update the consensus parameters of the blockchain network based on the target consensus parameters.
[0017] Optionally, in some embodiments, the blockchain network includes multiple verification nodes, and the updating unit includes:
[0018] The verification subunit is used to send the target consensus parameters to the verification node for verification;
[0019] A receiving subunit, used to receive the verification result returned by the verification node;
[0020] The updating subunit is used to update the consensus parameters of the blockchain network based on the target consensus parameters when it is determined according to the verification result that the verification of the target consensus parameters has passed.
[0021] Optionally, in some embodiments, updating the subunit includes:
[0022] A determination module, configured to determine a first number of verification nodes that have passed the verification according to the verification result;
[0023] An acquisition module, used to acquire the total number of verification nodes from the plurality of verification nodes to obtain a second number;
[0024] The update module is used to update the consensus parameters of the blockchain network based on the target consensus parameters when the ratio of the first number to the second number is greater than a preset threshold.
[0025] Optionally, in some embodiments, the update module includes:
[0026] A generating submodule, configured to generate a target smart contract based on a target consensus parameter when a ratio of the first quantity to the second quantity is greater than a preset threshold;
[0027] The sending submodule is used to send the target smart contract to each node in the blockchain network to update the consensus parameters of the blockchain network based on the target smart contract.
[0028] Optionally, in some embodiments, the acquiring unit includes:
[0029] The first acquisition subunit is used to obtain the current generation information and the block height information of the current generation of the blockchain network;
[0030] A second acquisition subunit is used to acquire network status information in the blockchain network when it is determined that the current block is the last block of the current generation according to the block height information;
[0031] Update unit, also used to:
[0032] Update the consensus parameters of the next generation of the blockchain network based on the target consensus parameters.
[0033] Optionally, in some embodiments, the consensus parameter updating device provided by the present disclosure further includes:
[0034] The selection subunit is used to select new verification node information from candidates that meet the staking conditions;
[0035] Create a subunit to create the next generation of the current generation based on the new verification node information and updated consensus parameters.
[0036] Optionally, in some embodiments, the network status information includes information on the number of candidate nodes and the number of verification nodes in the blockchain network, and the comparison unit includes:
[0037] A first calculation subunit, used to calculate the node number average of the number of verification nodes and the number of candidate nodes within a preset period of time;
[0038] A first comparison subunit is used to compare the node quantity mean with a preset reference node quantity to obtain a node quantity difference;
[0039] Identify units, including:
[0040] A third acquisition subunit is used to acquire a constraint relationship between the number of nodes and the amount of pre-stored virtual resources, and determine an adjustment value of the amount of pre-stored virtual resources corresponding to the difference in the number of nodes according to the constraint relationship;
[0041] The first determining subunit is used to determine the consensus parameter adjustment value according to the pre-stored virtual resource amount adjustment value.
[0042] Optionally, in some embodiments, the network status information includes block generation time information, and the comparison unit includes:
[0043] The second calculation subunit is used to calculate the average duration of the block generation time within a preset period;
[0044] The second comparison subunit is used to compare the duration mean with a preset reference duration value to obtain a block duration difference;
[0045] Identify units, including:
[0046] A fourth acquisition subunit is used to obtain a constraint relationship between a block duration and a block interval duration, and determine an adjustment value of the block interval duration corresponding to the block duration difference according to the constraint relationship;
[0047] The second determination subunit is used to determine the consensus parameter adjustment value according to the adjustment value of the block interval time.
[0048] Optionally, in some embodiments, the network status information includes transaction demand information and network congestion degree information, and the comparison unit includes:
[0049] The third calculation subunit is used to calculate the exponential mean of the transaction demand information and the network congestion degree information;
[0050] A third comparison subunit is used to compare the index mean with a preset reference index mean to obtain an index difference;
[0051] Identify units, including:
[0052] A fifth acquisition subunit is used to acquire a constraint relationship between the index mean and the amount of virtual resources awarded, and determine an adjustment value of the amount of virtual resources awarded corresponding to the index difference according to the constraint relationship;
[0053] The third determination subunit is used to determine the consensus parameter adjustment value according to the adjustment value of the rewarded virtual resource amount.
[0054] Optionally, in some embodiments, the determining unit includes:
[0055] A prediction subunit, used to predict the network status change trend based on the network status deviation information;
[0056] The fourth determination subunit is used to determine the consensus parameter adjustment value corresponding to the network state change trend based on the constraint relationship between the network state information and the consensus parameter.
[0057] Optionally, in some embodiments, the acquiring unit includes:
[0058] The sixth acquisition subunit is used to obtain the time interval between the current time and the last consensus parameter update time;
[0059] The seventh acquisition subunit is used to obtain network status information in the blockchain network when the time interval reaches a preset time.
[0060] According to one aspect of the present disclosure, a computer device is provided, including a memory and a processor, wherein the memory stores a computer program, and the processor implements the consensus parameter updating method as described above when executing the computer program.
[0061] According to one aspect of the present disclosure, a storage medium is provided, wherein the storage medium stores a computer program, and when the computer program is executed by a processor, the consensus parameter updating method as described above is implemented.
[0062] According to one aspect of the present disclosure, a computer program product is provided, which includes a computer program, and the computer program is read and executed by a processor of a computer device, so that the computer device executes the consensus parameter updating method as described above.
[0063] In the embodiment of the present disclosure, by obtaining the network status information in the blockchain network, the network status information includes the number of candidate nodes and verification nodes in the blockchain network, the block time information, the transaction demand information and the network congestion degree information; the network status information is compared with the preset reference network status information to obtain the network status deviation information; the consensus parameter adjustment value corresponding to the network status deviation information is determined based on the constraint relationship between the network status information and the consensus parameter, and the consensus parameter includes the pre-stored virtual resource amount, the reward or penalty virtual resource amount and the block interval time; the target consensus parameter is calculated according to the consensus parameter adjustment value and the current consensus parameter of the blockchain network; the consensus parameter of the blockchain network is updated based on the target consensus parameter. In this way, the consensus parameter update method provided by the present disclosure can update the consensus parameters in the blockchain consensus mechanism according to the network status information in the blockchain network in real time, so that the consensus parameters in the blockchain network can adapt to the changes in the blockchain network environment, and then improve the performance of the blockchain in all aspects. Specifically, for example, the security of the blockchain network can be improved to avoid centralization problems; the congestion degree of the blockchain network can also be reduced, and the operation efficiency of the blockchain network can be improved; and the enthusiasm of nodes to participate in block generation can be improved, and the accounting efficiency of the blockchain network can be further improved.
[0064] Other features and advantages of the present disclosure will be described in the following description, and partly become apparent from the description, or understood by practicing the present disclosure. The purpose and other advantages of the present disclosure can be realized and obtained by the structures particularly pointed out in the description, claims and drawings. BRIEF DESCRIPTION OF THE DRAWINGS
[0065] The accompanying drawings are used to provide further understanding of the technical solution of the present disclosure and constitute a part of the specification. Together with the embodiments of the present disclosure, they are used to explain the technical solution of the present disclosure and do not constitute a limitation on the technical solution of the present disclosure.
[0066] Figure 1A is a system architecture diagram of a consensus parameter updating method application according to an embodiment of the present disclosure;
[0067] Figure 1B It is a schematic diagram of the block structure in the blockchain;
[0068] Figure 1C This is a schematic diagram of the block generation process;
[0069] Figure 2 is a flow chart of a consensus parameter updating method provided by the present disclosure;
[0070] Figure 3 This is a schematic diagram of the process of rewarding verification nodes under the DPoS consensus mechanism;
[0071] Figure 4 This is a flowchart of punishing verification nodes under the DPoS consensus mechanism;
[0072] Figure 5 is another flowchart of the consensus parameter updating method provided by the present disclosure;
[0073] Figure 6 It is a structural diagram of a proposal node provided by the present disclosure;
[0074] Figure 7 is a structural diagram of a consensus parameter updating device according to an embodiment of the present disclosure;
[0075] Figure 8 is a terminal structure diagram for implementing various methods according to an embodiment of the present disclosure;
[0076] Fig. 9 It is a server structure diagram for implementing various methods according to an embodiment of the present disclosure. DETAILED DESCRIPTION
[0077] In order to make the purpose, technical solution and advantages of the present disclosure more clear, the present disclosure is further described in detail below in conjunction with the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are only used to explain the present disclosure and are not used to limit the present disclosure.
[0078] Before further describing the embodiments of the present disclosure in detail, the nouns and terms involved in the embodiments of the present disclosure are described. The nouns and terms involved in the embodiments of the present disclosure are subject to the following interpretations:
[0079] Blockchain: Blockchain is a new application model of computer technologies such as distributed data storage, peer-to-peer transmission, consensus mechanism, encryption algorithm, etc. Blockchain is essentially a decentralized database, a string of data blocks generated by cryptographic methods. Each data block contains a batch of network transaction information, which is used to verify the validity of its information (anti-counterfeiting) and generate the next block. Blockchain can include the underlying blockchain platform, platform product service layer, and application service layer.
[0080] The underlying blockchain platform can include processing modules such as user management, basic services, smart contracts, and operational detection. Among them, the user management module is responsible for the identity information management of all blockchain participants, including maintaining public and private key generation (account management), key management, and the maintenance of the correspondence between the user's real identity and the blockchain address (authority management), etc., and, under authorization, supervises and audits the transactions of certain real identities and provides risk control rule configuration (risk control audit); the basic service module is deployed on all blockchain node devices to verify the validity of business requests, and records valid requests to storage after consensus is reached. For a new business request, the basic service first performs interface adaptation analysis and authentication processing (interface adaptation), and then encrypts the business information through the consensus algorithm (consensus management). The smart contract module is responsible for the registration and issuance of contracts, as well as contract triggering and contract execution. Developers can define the contract logic in a programming language and publish it to the blockchain (contract registration). According to the logic of the contract terms, the key or other events are called to trigger the execution and complete the contract logic. It also provides the function of contract upgrade and cancellation. The operation detection module is mainly responsible for the deployment, configuration modification, contract setting, cloud adaptation and real-time status visualization output of the product during the product release process, such as alarm, network status detection, node equipment health status detection, etc.
[0081] The platform product service layer provides the basic capabilities and implementation framework of typical applications. Developers can superimpose business features based on these basic capabilities to complete the blockchain implementation of business logic. The application service layer provides application services based on blockchain solutions for business participants to use.
[0082] Proof of Stake (PoS): It is a consensus mechanism. In this mechanism, when creating a new block, the difficulty of the node's task will be proportionally reduced according to the number of virtual resources and time owned by each node according to the algorithm, thereby accelerating the speed at which the node finds random numbers. This mechanism can shorten the time required to reach consensus, but there is a risk of centralization.
[0083] Delegated Proof of Stake (DPoS): It is a consensus mechanism in which all nodes in the blockchain vote to select a certain number of node representatives, who will act on behalf of all nodes to perform data packaging, block generation, and block confirmation. Compared with the Proof of Work (PoW), this mechanism only requires a small number of nodes to generate and confirm blocks, which can reduce energy consumption and optimize block generation efficiency. Compared with the Proof of Stake (PoS), DPoS can avoid the problem of weak centralization, thereby maintaining the decentralized nature of the blockchain and improving the security of the blockchain.
[0084] Epoch: specifically refers to a period of time in the DPoS consensus mechanism, usually a few days or weeks. During each DPoS epoch, the selected verification nodes will take turns to serve as block production nodes to ensure the security and stability of the network. When the DPoS epoch ends, the identity and rights of the verification nodes will be recalculated and allocated to adapt to changes in the network status.
[0085] World State: refers to a data set that records all current status information on the blockchain. This data set includes all account information, smart contracts, on-chain resources, and virtual resource transfer records of the entire blockchain system.
[0086] In the related art, the DPoS consensus mechanism generally stipulates the following aspects: selection of validators: a certain number of validators are selected by voting on the virtual resource holders in the chain; collateral: the validator needs to lock a certain amount of virtual resources as collateral to prove its commitment to the network; block generation: the selected validators are responsible for creating and confirming new blocks; rewards and penalties: the selected validators can obtain corresponding rewards according to their work performance, and the validators who fail to perform their duties or have improper behavior will also be punished accordingly. At the same time, the DPoS algorithm will set corresponding parameters for the above content, such as setting the number of selected validators, the minimum amount of collateralized virtual resources, the ratio of rewards and penalties, and the interval time of block generation. In the related art, after the above parameters are set, the above parameters will be fixedly used to manage the blockchain network. However, during the operation of the blockchain network, the network state of the blockchain network will change with the demand for block generation, and the fixed consensus parameters will not be able to adapt to the changes in the network state in some cases, resulting in the performance of the blockchain network being reduced, such as network congestion, reduced processing efficiency, and reduced security. In this regard, the present disclosure provides a consensus parameter updating method in order to solve the problem of blockchain performance degradation caused by fixed consensus parameters under the DPoS consensus mechanism.
[0087] System architecture and scenario description of the application of the embodiments of the present disclosure
[0088] Figure 1A It is a system architecture diagram applied by the consensus parameter update method according to the embodiment of the present disclosure. Specifically, the system can be called a data sharing system 100 (i.e., a blockchain), and the data sharing system 100 includes multiple nodes 101, and the multiple nodes 101 can refer to each client in the data sharing system. Each node 101 can receive input information when performing normal work, and maintain the shared data in the data sharing system based on the received input information. In order to ensure the intercommunication of information in the data sharing system, there can be an information connection between each node in the data sharing system, and information can be transmitted between nodes through the above-mentioned information connection. For example, when any node in the data sharing system receives input information, other nodes in the data sharing system obtain the input information according to the consensus algorithm, and store the input information as data in the shared data, so that the data stored on all nodes in the data sharing system are consistent.
[0089] Each node in the data sharing system has a corresponding node identifier, and each node in the data sharing system can store the node identifiers of other nodes in the data sharing system, so that the generated blocks can be broadcast to other nodes in the data sharing system according to the node identifiers of other nodes. A node identifier list as shown in the following table can be maintained in each node, and the node name and node identifier are stored in the node identifier list accordingly. Among them, the node identifier can be an IP (Internet Protocol, a protocol for interconnecting networks) address and any other information that can be used to identify the node. Table 1 only takes the IP address as an example for illustration.
[0090]
[0091]
[0092] Table 1 Node identification diagram
[0093] Each node in the data sharing system stores the same blockchain. The blockchain consists of multiple blocks, see Figure 1BThe blockchain consists of multiple blocks. The genesis block includes a block header and a block body. The block header stores the input information characteristic value, version number, timestamp and difficulty value, and the block body stores the input information; the next block of the genesis block takes the genesis block as the parent block, and the next block also includes a block header and a block body. The block header stores the input information characteristic value of the current block, the block header characteristic value, version number, timestamp and difficulty value of the parent block, and so on, so that the block data stored in each block in the blockchain is associated with the block data stored in the parent block, ensuring the security of the input information in the block.
[0094] When generating each block in the blockchain, see Figure 1C When the node where the blockchain is located receives the input information, it verifies the input information. After the verification is completed, the input information is stored in the memory pool and the hash tree used to record the input information is updated. After that, the update timestamp is updated to the time when the input information is received, and different random numbers are tried to calculate the eigenvalue multiple times so that the calculated eigenvalue can satisfy the following formula:
[0095] SHA256(SHA256(version+prev_hash+merkle_root+ntime+nbits+x)) <TARGET
[0096] Among them, SHA256 is the eigenvalue algorithm used to calculate the eigenvalue; version (version number) is the version information of the relevant block protocol in the blockchain; prev_hash is the block header eigenvalue of the parent block of the current block; merkle_root is the eigenvalue of the input information; ntime is the update time of the update timestamp; nbits is the current difficulty, which is a fixed value within a period of time and is determined again after exceeding the fixed time period; x is a random number; TARGET is the eigenvalue threshold, which can be determined based on nbits.
[0097] In this way, when the random number that satisfies the above formula is calculated, the information can be stored accordingly, the block header and block body can be generated, and the current block can be obtained. Subsequently, the node where the blockchain is located sends the newly generated block to other nodes in the data sharing system according to the node identification of other nodes in the data sharing system. Other nodes verify the newly generated block and add the newly generated block to the blockchain stored in them after the verification is completed.
[0098] The node 101 can be a terminal or a server. When the node 101 is a terminal, the node 101 can include desktop computers, laptop computers, PDAs (personal digital assistants), mobile phones, vehicle-mounted terminals, home theater terminals, dedicated terminals, etc. In addition, it can be a single device or a collection of multiple devices. The node 101 can communicate with other nodes in a wired or wireless manner to exchange data.
[0099] When node 101 is a service, node 101 can be a high-performance computer in the blockchain network, a cluster of multiple high-performance computers, a portion of a high-performance computer (such as a virtual machine), a combination of portions of multiple high-performance computers (such as virtual machines), etc.
[0100] The consensus parameter updating method of the disclosed embodiment can be implemented in any node 101 in the data sharing system 100. That is, for any node 101, the node 101 can obtain the network status information in the blockchain network, the network status information includes the number of candidate nodes and verification nodes in the blockchain network, the block time information, the transaction demand information and the network congestion degree information; compare the network status information with the preset reference network status information to obtain the network status deviation information; determine the consensus parameter adjustment value corresponding to the network status deviation information based on the constraint relationship between the network status information and the consensus parameter, the consensus parameter includes the pre-stored virtual resource amount, the reward or penalty virtual resource amount and the block interval time; calculate the target consensus parameter according to the consensus parameter adjustment value and the current consensus parameter of the blockchain network; update the consensus parameter of the blockchain network based on the target consensus parameter.
[0101] The disclosed embodiments can be applied in various blockchain application scenarios, specifically in blockchain networks that use the aforementioned PoS or DPoS as a consensus mechanism. The blockchain application scenario can specifically be a transaction data processing scenario in the financial field, insurance field, or medical field.
[0102] General description of the disclosed embodiments
[0103] According to an embodiment of the present disclosure, a consensus parameter updating method is provided. The method can be used in the aforementioned blockchain network that adopts PoS or DPoS as a consensus mechanism.
[0104] like Figure 2 FIG. 1 is a flow chart of a consensus parameter updating method provided by the present disclosure. The method can be applied to a consensus parameter updating device, which can be integrated in a computer device, which can be a terminal or a server. The consensus parameter updating method can include:
[0105] Step 210, obtaining network status information in the blockchain network.
[0106] Among them, the consensus mechanism is one of the four core technologies of blockchain, and it is also a rule that every node in the blockchain network must abide by. In the blockchain network, the role of the consensus mechanism is to coordinate the consistency of the accounts of all nodes. Specifically, the consensus mechanism mainly stipulates two aspects. On the one hand, it is the problem of how nodes in the blockchain network keep accounts, and on the other hand, it is the problem of how different nodes exchange information to reach a consensus. At present, the consensus mechanisms adopted by the blockchain network include the proof of work mechanism, the proof of equity mechanism, and the proof of share authorization mechanism. Under the proof of work mechanism, the nodes in the blockchain network compete for the right to keep accounts by calculating the numerical solution of the three columns of random hashes. The ability to obtain the correct numerical solution to generate blocks is the specific manifestation of the node's computing power; this mechanism has the advantage of complete decentralization, but this mechanism also has the problem of causing a lot of waste of resources, and it takes a lot of time to reach a consensus between nodes under this mechanism, which makes this mechanism unable to be used well in the industry. The proof-of-stake mechanism and the share authorization proof mechanism can greatly improve the speed of transaction processing and reduce resource waste by determining a small number of nodes to generate and verify blocks based on the number of pledged virtual resources or the votes of all nodes; however, the proof-of-stake mechanism and the share authorization proof mechanism will also lead to a certain degree of reduction in the degree of decentralization of the blockchain network, thereby reducing the security of the blockchain network.
[0107] According to the above analysis, the essence of the consensus mechanism is the contradictory combination of information recording efficiency and information reliability. In industrial application scenarios, excessive resource waste and extremely low information recording efficiency obviously cannot generate industrial value, which has led to more and more blockchain networks abandoning the proof of work mechanism and adopting the proof of equity mechanism or the share authorization proof mechanism as the consensus mechanism of the blockchain network.
[0108] In the related art, whether the proof-of-stake mechanism or the share authorization proof mechanism is used as the consensus mechanism of the blockchain network, the consensus parameters in the consensus mechanism must be initialized and set in the initialization stage of the blockchain network to ensure the normal operation of the blockchain network. The following introduces the initialization parameters of the blockchain network by taking the share authorization proof mechanism as the consensus mechanism of the blockchain network as an example. When initializing the blockchain network, the following parameters need to be initialized: Genesis block, number of validators, block generation time, initial validators list, stake threshold, reward distribution policy, and penalty mechanism. Among them, the genesis block of the blockchain network is set, including information such as initial transaction information, timestamp, and total supply of genesis (i.e., the total number of virtual resources). The genesis block is the first block of the blockchain and can provide a reference benchmark for subsequent blocks. The number of validators in the blockchain network is set as the initial number of validators in the blockchain network, and the number of validators will determine the degree of decentralization and block generation speed of the network. The block generation time set during initialization can be specifically the time interval for setting block generation, which will affect the speed of transaction processing in the blockchain network. When the blockchain network is started, the validators in the initial validator list configured during initialization can participate in the generation and verification of blocks to ensure the smooth start of the blockchain network. The reward distribution strategy set during the initialization of the blockchain network mainly includes block rewards (i.e., a certain amount of virtual resources are rewarded to the node that generates the block) and the amount of virtual resources consumed by the transaction (gas fee). Block rewards will affect the degree of enthusiasm of nodes in the blockchain network to participate in block generation. The mortgage threshold set during the initialization of the blockchain network can be specifically the minimum amount of virtual resources that a node in the blockchain network needs to mortgage to be called a verification node; the mortgage threshold will affect the enthusiasm of nodes in the blockchain network to compete for verification nodes. The penalty mechanism set during the initialization of the blockchain network will set the penalty rules and conditions in the blockchain network so that corresponding penalties can be imposed when the verification node makes a mistake or behaves abnormally to ensure the security of the blockchain network.
[0109] Among them, the above-mentioned initialization content can be specifically recorded in the configuration file of the blockchain network. When the blockchain network is initialized and started, each node in the blockchain network starts and runs according to the initialization parameters recorded in the configuration file. As mentioned above, the time interval of block generation in the initialization parameters will affect the transaction processing speed in the blockchain network, the minimum amount of virtual resources required to become a verification node will affect the enthusiasm of nodes in the blockchain network to compete for verification nodes, and the amount of virtual resources rewarded when generating blocks will affect the degree of enthusiasm of nodes in the blockchain network to participate in block generation. That is, these parameters will affect the operating state of the blockchain network. In the relevant technology, these parameters (parameters in the consensus mechanism, also known as consensus parameters) are determined by the configuration file and remain fixed during the operation of the blockchain network; and the operating state of the blockchain network during operation will change in real time with the changes in the number of transactions, the number of validators, etc. When the fixed consensus parameters cannot adapt to the changes in the state of the blockchain network, it will cause the performance of the blockchain network to decline, such as the decline in transaction processing efficiency in the blockchain network, the decline in the degree of decentralization of the blockchain network, and the decline in the security of the blockchain network. For example, if the amount of virtual resources rewarded when generating a block in the consensus parameters of the blockchain network is set to a small value, the enthusiasm of nodes in the blockchain network to participate in block generation will decrease. When the transaction volume is small, the blockchain network can still operate well, that is, maintain a relatively fast transaction processing efficiency; when the transaction volume increases, the blockchain network will cause network congestion due to the small number of nodes participating in block generation, which will further lead to a decrease in transaction processing efficiency.
[0110] In this regard, in order to solve to a certain extent the problem that the consensus parameters in the blockchain consensus mechanism in the related technology are fixed, resulting in the inability to adapt to the changing network state of the blockchain network, thereby causing the performance of the blockchain network to decline, the present disclosure provides a consensus parameter updating method, which is introduced in detail below.
[0111] First, the network status information in the blockchain network can be obtained, where the network status information can specifically include information on the number of candidate nodes and verification nodes in the blockchain network, block generation time information, transaction demand information, network congestion level information, and the frequency of abnormal behavior or error frequency of nodes in the blockchain network.
[0112] Among them, candidate nodes in the blockchain network refer to nodes that have pledged a certain amount of virtual resources and can be selected as verification nodes; verification nodes are nodes selected to participate in the generation and verification of blocks. The selection operation here can be specifically voted for all nodes in the blockchain network. When multiple nodes are selected as verification nodes, these verification nodes take turns to generate blocks, and verify the generated blocks in multiple verification nodes. After the verification passes, the generated blocks are broadcast to each node in the blockchain network for storage. The number of candidate nodes and verification nodes in the blockchain network will change due to the enthusiasm of the nodes to participate in block generation, and the nodes in the blockchain network are all profit-seeking, that is, the enthusiasm of the nodes to participate in block generation will be affected by the amount of virtual resources rewarded by block generation and the number of transactions.
[0113] Among them, the block generation time information in the blockchain network can specifically be the average time required to generate a block in the blockchain network. The average time required to generate a block in the blockchain network will be affected by the number of transactions and the speed of transaction processing. Specifically, since the capacity of information that can be stored in a block is fixed, when the number of transactions is small, in order to avoid low storage space utilization in each block, the block generation speed can be reduced to store as much transaction information as possible in a block, which will lead to an increase in the block generation time; when the number of transactions is sufficient, the verification node needs to consume more resources to package the transaction information and generate blocks, which will lead to a decrease in consensus efficiency, and thus also lead to an increase in the block generation time.
[0114] Among them, the transaction demand information may include information such as the number of transactions in the transaction pool and the transaction retention time. In the blockchain network, the transaction demand information will be affected by the number of virtual resources consumed by the transaction. The smaller the number of virtual resources consumed by the transaction, the more motivated the object is to use the blockchain network to store transaction data, and thus the transaction demand will be greater. The degree of network congestion in a general network refers to the degree to which the data processing demand in the network occupies the bandwidth, storage space and processor processing power of the network link. In the embodiment of the present disclosure, the network congestion degree information of the blockchain network may specifically include information on the number of transactions in the block, the block interval time information, and the amount of virtual resources consumed by the transaction. In general, when the number of transactions in the block is large, the block interval time is long, and the amount of virtual resources consumed by the transaction is small, the network congestion degree of the blockchain network is higher.
[0115] Wherein, obtaining the network status information in the blockchain network can specifically be any node (including ordinary nodes, candidate nodes or verification nodes) in the blockchain network to obtain the network status information in the blockchain network. After obtaining the network status information in the blockchain network, the network status of the blockchain network can be analyzed accordingly. In addition, the blockchain network in the embodiment of the present disclosure can be any type of blockchain network in a private chain, a public chain or a consortium chain.
[0116] In some embodiments, obtaining network status information in a blockchain network includes:
[0117] Get the time interval between the current time and the last consensus parameter update time;
[0118] When the time interval reaches the preset time, the network status information in the blockchain network is obtained.
[0119] In the disclosed embodiment, the consensus parameters in the blockchain network can be updated at a preset frequency. Specifically, a preset duration can be set, and then the time interval between the current time and the last consensus parameter update time can be detected in real time. If the time interval between the current time and the last consensus parameter update time reaches the aforementioned preset duration, it can trigger the acquisition of network status information in the blockchain network, and update the consensus parameters of the blockchain network according to the acquired network status information. If the consensus parameters of the blockchain network have not been updated before the current time, the time interval between the current time and the initialization time of the blockchain network can be obtained. When the time interval reaches the preset duration, the network status information in the blockchain network can be obtained and the consensus parameters of the blockchain network can be updated according to the acquired network status information.
[0120] In some embodiments, in order to ensure that the consensus parameters of the blockchain network can better adapt to the rapid changes in the network status information of the blockchain network, a shorter time can be set as the preset duration, that is, a higher frequency is set to update the consensus parameters of the blockchain network. For example, the preset duration can be set to 2 minutes or 1 minute.
[0121] In some other embodiments, since the consensus parameters of the blockchain network also need to consume a certain amount of computing power resources, in order to reduce the computing power resources consumed by the consensus parameters for updating on the basis of ensuring that the consensus parameters of the blockchain network can better adapt to the rapid changes of the network status information of the blockchain network, the changes in the network status information of the blockchain network within a period of time can be further obtained, and then the aforementioned preset duration is dynamically determined according to the frequency of changes in the network status information of the blockchain network during this period, that is, the frequency of updating the consensus parameters of the blockchain network is dynamically determined. For example, when the data of the network status information in the blockchain network within a month is counted, and it is concluded from the data that the network status information of the blockchain network changes more frequently between 8 am and 8 pm every day, and changes less frequently between 8 pm and 8 am the next day, then the consensus parameters of the blockchain network can be set to be updated at a higher frequency between 8 am and 8 pm every day, that is, the aforementioned preset duration value is set to be smaller; and updated at a lower frequency between 8 pm and 8 am the next day, that is, the aforementioned preset duration value is set to be larger. In this way, it can be ensured that the consensus parameters of the blockchain network can better adapt to the changes in the network status information of the blockchain network on the basis of lower computing power resource consumption.
[0122] Step 220, compare the network status information with preset reference network status information to obtain network status deviation information.
[0123] In the disclosed embodiments, after obtaining the network status information of the blockchain network, the consensus parameters of the blockchain network can be updated based on the network status information of the blockchain network. In some embodiments, the consensus parameters corresponding to different network status information can be artificially designed in advance, and a mapping relationship table between the network status information and the consensus parameters can be generated based on the different network status information and the corresponding consensus parameters. In this way, after obtaining the network status information of the blockchain network, the corresponding consensus parameters can be found in the mapping relationship table based on the obtained network status information, and then the consensus parameters of the blockchain network can be updated based on the found consensus parameters.
[0124] In some embodiments, reference network status information may be preset, and the reference network status information is network status information of the blockchain network running in a relatively ideal state. After obtaining the actual network status information of the blockchain network, the obtained network status information may be compared with the reference network status information to obtain network status deviation information.
[0125] Among them, the preset reference network state information can be a reference value or a reference value range corresponding to the above-mentioned multiple types of network state information. For example, when the network state information is the number of candidate nodes and the number of verification nodes, a value range can be set, and the value range includes an upper limit and a lower limit. When the number of candidate nodes and the number of verification nodes in the blockchain network are within the value range, it is not necessary to update the consensus parameters of the blockchain network; only when the number of candidate nodes and the number of verification nodes is lower than the lower limit or higher than the upper limit, the consensus parameters of the blockchain network need to be updated so that the number of candidate nodes and the number of verification nodes return to the above value range. When the network state information is the block time information, the corresponding reference network state information can be a preset reference value or a preset reference value range. When the corresponding reference network state information is a preset reference value, if the block time information in the obtained network state information is not equal to the reference value, the consensus parameters of the blockchain network need to be updated so that the obtained block time approaches the reference value. If the corresponding reference network status information is a preset reference value range, it is also necessary to first determine whether the obtained block time is within the reference value range. If it is within the reference value range, there is no need to update the corresponding consensus parameters. Otherwise, the corresponding consensus parameters need to be updated to drive the block time to be within the reference value range.
[0126] Specifically, after obtaining the network status information of the blockchain network and the preset reference network status information, the network status information and the reference network status information are compared to obtain a corresponding comparison result, which can be called network status deviation information. When the corresponding consensus parameters need to be updated, the corresponding consensus parameter adjustment value can be calculated according to the network status deviation information, and then the consensus parameters of the blockchain network are adjusted based on the consensus parameter adjustment value.
[0127] Step 230, determining a consensus parameter adjustment value corresponding to the network state deviation information based on a constraint relationship between the network state information and the consensus parameter.
[0128] Among them, after the acquired network status information is compared with the preset reference network status information to obtain the network status deviation information, the consensus parameter adjustment value can be further determined according to the network status deviation information.
[0129] Specifically, as disclosed in the aforementioned step 210, the setting of the consensus parameters of the blockchain network will affect the network state in the blockchain network, that is, there is a constraint relationship between the network state information of the blockchain and the consensus parameters. In this way, after the network state deviation information between the acquired network state information and the reference network state information is determined, the adjustment value of the consensus parameter corresponding to the network state deviation information can be determined based on the constraint relationship between the network state information and the consensus parameters. Among them, in the disclosed embodiment, the consensus parameters may include the amount of pre-stored virtual resources (i.e., the aforementioned mortgaged virtual resources), the amount of virtual resources rewarded or punished, and the block interval time.
[0130] Next, we will take the DPoS consensus mechanism as an example to introduce the constraint relationship between the network status information in the blockchain and the consensus parameters of the consensus mechanism, that is, to introduce the specific impact of the consensus parameters of the consensus mechanism on the network status information.
[0131] Under the DPoS consensus mechanism, in order to motivate verification nodes (also called witnesses or super nodes) to actively participate in the maintenance of the blockchain, the blockchain network will give certain rewards when the verification nodes generate blocks. Figure 3 The figure below is a schematic diagram of the process of rewarding verification nodes under the DPoS consensus mechanism. As shown in the figure, the reward process includes the following steps:
[0132] Step 310, when it is detected that the verification node generates a new block, the address information of the verification node is obtained.
[0133] As mentioned above, under the DPoS consensus mechanism, the verification node is responsible for the generation and verification of blocks. Among multiple verification nodes, when a verification node generates a block, the node can be called a proposal node, and other nodes responsible for verification are called verification nodes. In the blockchain network, when a verification node generates a new block, the node becomes the proposal node of the new block, and the block reward allocation value of the proposal node can be set to be greater than 0. When it is detected that the verification node generates a new block, that is, when it is detected that the reward allocation value of the verification node is greater than 0, the address information of the verification node can be obtained so that the virtual resources of the reward can be allocated to it according to the address information.
[0134] Step 320, calculating the total amount of virtual resources corresponding to the new block according to the amount of virtual resources corresponding to the transaction data recorded in the new block.
[0135] Each newly generated block records multiple transaction data, and for each transaction data record, the provider of the transaction data needs to pay a certain amount of virtual resources (such as the aforementioned gas fee). Part of these virtual resources will be obtained by the blockchain system, and the other part will be used to reward the nodes participating in the block generation. In this way, when a new block is generated, the amount of virtual resources corresponding to the transaction data recorded in the block can be obtained, and then the amount of virtual resources corresponding to these transaction data can be accumulated to obtain the total amount of virtual resources corresponding to the new block.
[0136] Step 330: Calculate the target amount of virtual resources that should be allocated to the verification node according to the total amount of virtual resources and the virtual resource allocation ratio.
[0137] Among them, in each blockchain network, the reward coefficient for each verification node participating in the generation of a block will be set through the consensus parameters in the consensus mechanism, that is, the allocation ratio of the total amount of virtual resources corresponding to the new block will be set. In this way, after calculating the total amount of virtual resources corresponding to the new block, the target amount of virtual resources that the verification node (or proposal node) should be allocated can be calculated based on the total amount of virtual resources and the virtual resource allocation ratio.
[0138] Step 340: Check whether there are any nodes that need to be punished.
[0139] After calculating the target amount of virtual resources that the proposing node should be rewarded, it is possible to first detect whether there are nodes in the verification nodes that need to be punished. If there are nodes that need to be punished, the virtual resources used for the punishment can be used to reward the proposing node first.
[0140] Step 350: If there is no node that needs to be punished, a reward of the target virtual resource amount is issued to the verification node according to the address information.
[0141] When it is detected that there is no node that needs to be punished, a corresponding amount of reward can be issued to it based on the address information of the proposing node.
[0142] Step 360: If there is a penalty node, transfer the target virtual resource amount of virtual resources from the address corresponding to the penalty node to the address of the verification node.
[0143] If a node that needs to be punished is detected, the virtual resources of the target virtual resource amount can be transferred from the virtual resources pledged by the node that needs to be punished to the proposal node according to the address of the node that needs to be punished. If the amount of virtual resources to be punished is less than the target amount of virtual resources, the shortfall will be reissued to the proposal node.
[0144] As can be seen from the above analysis, the setting of the consensus parameter of the amount of virtual resources rewarded in the consensus mechanism will affect the amount of virtual resources obtained by the verification node for generating a block. In this way, if the consensus parameter of the amount of virtual resources rewarded is set larger, the verification node will be more willing to generate blocks, that is, the verification node will be more efficient in processing transaction data (for example, investing more computing resources for processing); on the contrary, if the consensus parameter of the amount of virtual resources rewarded is set smaller, the willingness of the verification node to generate blocks will be reduced, which will in turn reduce the efficiency of transaction processing and even cause the congestion of the blockchain network to increase.
[0145] In addition, in the DPoS consensus mechanism, in order to ensure the safe and stable operation of the blockchain network and maintain the order of the entire blockchain network, the DPoS consensus mechanism also designs a corresponding penalty system. Figure 4 The figure below is a schematic diagram of the process of punishing verification nodes under the DPoS consensus mechanism. As shown in the figure, the punishment process includes the following steps:
[0146] Step 410, when it is detected that the current block is the last block of the current generation, the number of blocks generated by each verification node in the current generation is obtained.
[0147] Among them, in the blockchain network, there may be many reasons for punishing a node, such as node errors (including unintentional errors and intentional errors), node workload not meeting the standard, etc. In the embodiment of the present disclosure, the node workload not meeting the standard is used as an example for introduction. Specifically, when the last block of each generation is generated, the number of blocks generated by each verification node in the current generation can be obtained.
[0148] Step 420, determining the verification node whose number of generated blocks is less than a preset number as a node to be punished.
[0149] After obtaining the number of blocks generated by each verification node in the current generation, the number of blocks generated by each verification node in the current generation can be compared with the preset number. When the number of blocks generated by the verification node in the current generation is less than the preset number, it is determined to be a node to be punished.
[0150] Step 430: Obtain address information of the node to be punished.
[0151] Furthermore, the address information of each node to be punished may be obtained, so that after the amount of virtual resources to be punished is determined, the punishment is made according to the corresponding address information.
[0152] Step 440: Calculate the amount of virtual resources to be punished for each node to be punished according to the penalty ratio and the pre-stored amount of virtual resources.
[0153] Among them, in the consensus parameters of the consensus mechanism, the penalty ratio for each verification node can also be set. When it is determined that a node needs to be punished, the amount of virtual resources that should be punished can be calculated based on the penalty ratio and its pre-stored virtual resource amount (i.e. the mortgaged virtual resource amount).
[0154] Step 450: Update the corresponding pre-stored virtual resource amount according to the address information and the virtual resource amount to be punished of each node to be punished.
[0155] After calculating the amount of virtual resources to be punished corresponding to each node to be punished, the amount of virtual resources to be punished can be used to punish each node to be punished. Specifically, the amount of virtual resources to be punished can be deducted from the pre-stored amount of virtual resources, thereby updating the pre-stored amount of virtual resources of each node to be punished.
[0156] According to the above introduction, the setting of the amount of virtual resources punished in the consensus parameters will affect the amount of virtual resources deducted when the node makes mistakes or the workload does not meet the standard. For example, when the amount of virtual resources punished is set to be large, it will prompt the node to reduce the number of mistakes or increase its workload, thereby improving the security of the blockchain network and reducing the congestion of the blockchain network. However, when the amount of virtual resources punished is set too large, it will also reduce the enthusiasm of nodes in the blockchain network to become verification nodes.
[0157] The above example shows that in the consensus mechanism, the setting of consensus parameters will affect the change of network state information in the blockchain network, that is, there is a constraint relationship between the network state information of the blockchain network and the consensus parameters. In this way, after the network state deviation information between the network state information and the reference network state information is determined, the consensus parameter adjustment value corresponding to the network state deviation information can be determined according to the constraint relationship between the network state information and the consensus parameters.
[0158] Specifically, the constraint relationship between each network state information and the corresponding consensus parameter can be a constraint relationship that can be quantitatively calculated. For example, there is an inverse proportional relationship between the value of the pre-stored virtual resource amount set in the consensus parameter and the number of candidate nodes and verification nodes in the blockchain network. The lower the value of the pre-stored virtual resource amount, the fewer the number of candidate nodes and verification nodes in the blockchain network. In this way, the consensus parameter adjustment value corresponding to the network state deviation information can be determined based on the quantitative relationship.
[0159] In some embodiments, the network status information includes information on the number of candidate nodes and the number of verification nodes in the blockchain network, and the network status information is compared with preset reference network status information to obtain network status deviation information, including:
[0160] Calculate the average number of verification nodes and candidate nodes within a preset period of time;
[0161] Compare the mean number of nodes with the preset reference number of nodes to obtain the difference in the number of nodes;
[0162] The consensus parameter adjustment value corresponding to the network state deviation information is determined based on the constraint relationship between the network state information and the consensus parameter, including:
[0163] Obtaining a constraint relationship between the number of nodes and the amount of pre-stored virtual resources, and determining an adjustment value of the amount of pre-stored virtual resources corresponding to the difference in the number of nodes according to the constraint relationship;
[0164] The consensus parameter adjustment value is determined according to the adjustment value of the pre-stored virtual resource amount.
[0165] Among them, in the embodiment of the present disclosure, when the network status information is the number of candidate nodes and the number of verification nodes in the blockchain network, the node number mean of the number of verification nodes and the number of candidate nodes in the preset period can be calculated. The preset period can be specifically set to multiple generations in the blockchain, such as 64 generations, and of course it can also be set to a small number of generations to obtain network status information that can accurately reveal the current blockchain network. Among them, the node number mean here can include the two means of the number of verification nodes and the number of candidate nodes, or it can be the mean of the sum of the number of verification nodes and the number of candidate nodes.
[0166] After obtaining the above-mentioned mean value of the number of nodes, the mean value of the number of nodes can be compared with the preset reference number of nodes to obtain the difference in the number of nodes. The reference number of nodes here can be a specific value or a numerical range. When the reference number of nodes is a numerical range, if the mean value of the number of nodes is in the numerical range, it can be determined that the difference in the number of nodes is 0; when the mean value of the number of nodes is less than the minimum value of the numerical range, it can be determined that the difference in the number of nodes is a negative value; when the mean value of the number of nodes is greater than the maximum value of the numerical range, it can be determined that the difference in the number of nodes is a positive value.
[0167] Then, the constraint relationship between the number of nodes and the amount of pre-stored virtual resources can be further obtained, and the adjustment value of the amount of pre-stored virtual resources corresponding to the difference in the number of nodes can be determined according to the constraint relationship. Among them, in general, when the difference in the number of nodes is a negative value, it indicates that the number of candidate nodes and verification nodes in the blockchain network is small, which will lead to a decrease in the transaction processing efficiency in the blockchain network, and then lead to an increase in the congestion of the blockchain network. In order to increase the number of candidate nodes and verification nodes in the blockchain network, the number of virtual resources that the nodes need to pledge (i.e., the number of pre-stored virtual resources) can be appropriately reduced to attract more nodes to become candidate nodes and verification nodes. On the contrary, when the difference in the number of nodes is a positive value, it means that the number of candidate nodes and verification nodes in the blockchain network is large, and at this time, there will be a problem that multiple verification nodes are easily controlled, thereby causing the blockchain network to have a centralization risk. At this time, the number of virtual resources that the nodes need to pledge can be appropriately increased to reduce the number of candidate nodes and verification nodes. That is, the adjustment value of the amount of pre-stored virtual resources can be calculated based on the constraint relationship and the difference in the number of nodes, and the adjustment value of the amount of pre-stored virtual resources becomes the consensus parameter adjustment value.
[0168] In some embodiments, the network status information includes block duration information, and the network status information is compared with preset reference network status information to obtain network status deviation information, including:
[0169] Calculate the average block duration within the preset period;
[0170] Compare the average duration with the preset reference duration value to obtain the block duration difference;
[0171] The consensus parameter adjustment value corresponding to the network state deviation information is determined based on the constraint relationship between the network state information and the consensus parameter, including:
[0172] Obtain the constraint relationship between the block time and the block interval time, and determine the adjustment value of the block interval time corresponding to the block time difference according to the constraint relationship;
[0173] The consensus parameter adjustment value is determined based on the adjustment value of the block interval.
[0174] In the disclosed embodiment, for the network status information of the block duration information, the mean duration of the block duration within a preset period can be calculated, and then the mean duration is compared with the preset reference duration value to obtain the block duration difference. Among them, the reference duration value here can also be a numerical range. When the mean duration is less than the minimum value of the numerical range, the block duration difference is determined to be a negative value. This indicates that the load in the blockchain network is low, and the block interval duration can be appropriately increased to save resources; when the mean duration is greater than the maximum value of the numerical range, the block duration difference is determined to be a positive value, which indicates that the transaction processing speed is slow, and the block interval duration can be appropriately reduced to increase the transaction processing speed. In this way, the constraint relationship between the block duration and the block interval duration can be further obtained, and the adjustment value of the block interval duration corresponding to the block duration difference can be determined according to the constraint relationship, and the adjustment value of the block interval duration is the consensus parameter adjustment value.
[0175] In some embodiments, the network status information includes transaction demand information and network congestion information. The network status information is compared with preset reference network status information to obtain network status deviation information, including:
[0176] Calculate the exponential mean of transaction demand information and network congestion information;
[0177] Compare the index mean with the preset reference index mean to obtain the index difference;
[0178] The consensus parameter adjustment value corresponding to the network state deviation information is determined based on the constraint relationship between the network state information and the consensus parameter, including:
[0179] Obtaining the constraint relationship between the index mean and the amount of virtual resources awarded, and determining the adjustment value of the amount of virtual resources awarded corresponding to the index difference according to the constraint relationship;
[0180] The consensus parameter adjustment value is determined according to the adjustment value of the amount of virtual resources rewarded.
[0181] For the network status information of transaction demand information and network congestion degree information, the index mean of the acquired transaction demand information and network congestion degree information can be calculated. Here, the index mean can be specifically the average value of the evaluation index of transaction demand and network congestion degree, and the evaluation index here can be the index value obtained by evaluating according to certain rules. After the index mean is calculated, the index mean can be compared with the preset reference index mean to obtain the index difference. Similarly, the reference index mean can be a numerical value or a numerical range. If the reference index mean is a numerical value, and the calculated index mean is greater than the reference index mean, the index difference is a positive value, which indicates that the transaction volume in the blockchain network is large and the network congestion is serious. At this time, the amount of virtual resources rewarded can be appropriately increased to enhance the enthusiasm of the verification node to process transactions, improve the efficiency of transaction processing, and reduce the network congestion. On the contrary, if the calculated index mean is less than the reference index mean, the index difference is a negative value, which indicates that the transaction volume in the blockchain network is small and the network congestion is low. At this time, the amount of virtual resources rewarded can be reduced to reduce the overall resource consumption of the blockchain network. Specifically, the constraint relationship between the index mean and the amount of virtual resources awarded can be further obtained, and the adjustment amount of the virtual resources awarded corresponding to the index difference can be determined according to the constraint relationship.
[0182]
[0183] Table 1 Schematic diagram of the constraint relationship between network status information and consensus parameters
[0184] As shown in Table 1, Table 1 is a schematic diagram of the constraint relationship between network status information and formula parameters. Among them, the number of candidate nodes and verification nodes in the network status information is negatively correlated with the amount of pre-stored virtual resources in the consensus parameters. The smaller the amount of pre-stored virtual resources set in the consensus parameters, the higher the enthusiasm of the blockchain nodes to become candidate nodes and verification nodes, which will increase the number of candidate nodes and verification nodes in the blockchain network. In this way, when it is detected that the number of candidate nodes and verification nodes in the network status information is less than the number in the reference network status information, the number of candidate nodes and verification nodes in the blockchain network can be increased by reducing the amount of pre-stored virtual resources. On the contrary, if it is detected that the number of candidate nodes and verification nodes in the network status information is greater than the number in the reference network status information, the number of candidate nodes and verification nodes in the blockchain network can be reduced by increasing the amount of pre-stored virtual resources. In addition, the block duration information in the network status information is negatively correlated with the block interval duration in the consensus parameters, that is, if the block interval duration is set low, the total block duration will increase, which can improve the block efficiency. In this way, when the block time information is lower than the preset block time information in the reference network status information, it means that the load in the blockchain network is low, so the block time interval can be appropriately increased to save resources; when the block time information is higher than the preset block time information in the reference network status information, it means that the block efficiency is low, and the block time interval can be appropriately reduced to improve the block efficiency. The transaction demand information in the blockchain network depends on the transaction demand of the object, and has little to do with the setting value of the consensus parameter, but the transaction demand will affect the smoothness of the network. When the transaction demand is stable, the network smoothness information of the blockchain network is positively correlated with the amount of virtual resources rewarded in the consensus parameter. Specifically, the smaller the amount of virtual resources rewarded is set, the lower the smoothness of the network; the larger the amount of virtual resources rewarded is set, the more active the nodes are in participating in the transaction processing in the blockchain, and the higher the smoothness of the network. When it is detected that the network connectivity information in the network status information is higher than the network connectivity information preset in the reference network status information (or the network congestion information is higher than the network congestion information preset in the reference network status information), the network connectivity can be improved by increasing the amount of virtual resources rewarded.
[0185] In some embodiments, determining a consensus parameter adjustment value corresponding to the network state deviation information based on a constraint relationship between the network state information and the consensus parameter includes:
[0186] Predict the trend of network status changes based on network status deviation information;
[0187] Based on the constraint relationship between network status information and consensus parameters, the consensus parameter adjustment value corresponding to the network status change trend is determined.
[0188] Among them, in some embodiments, after calculating the network state deviation information, the network state deviation information can be further analyzed and processed to predict the network state change trend of the blockchain network. Specifically, it can include the change trend of transaction processing speed, the change trend of validator participation, and the change trend of network load, etc. Then, the consensus parameter adjustment value corresponding to the network state change trend can be further determined based on the constraint relationship between the network state information and the consensus parameter.
[0189] Step 240, calculating the target consensus parameter according to the consensus parameter adjustment value and the current consensus parameter of the blockchain network.
[0190] Among them, after the consensus parameter adjustment value is determined according to the difference between the network status information and the reference network status information, and the constraint relationship between the network loading information and the consensus parameter, the consensus parameters of the consensus mechanism in the blockchain network can be updated based on the consensus parameter adjustment value.
[0191] Specifically, the consensus parameters of the consensus mechanism in the current blockchain network can be obtained first. The consensus parameters of the consensus mechanism in the current blockchain network can be obtained from the configuration file of the blockchain network, or from the smart contract recently received by each node in the blockchain network for adjusting the consensus parameters of the consensus mechanism in the blockchain network.
[0192] After obtaining the current consensus parameters of the blockchain network, the target consensus parameters can be calculated based on the current consensus parameters of the blockchain network and the consensus parameter adjustment values calculated above.
[0193] Step 250, updating the consensus parameters of the blockchain network based on the target consensus parameters.
[0194] After calculating the target consensus parameters, the consensus parameters of the consensus mechanism in the blockchain network can be updated based on the target consensus parameters. This drives the network status information of the blockchain network to approach the reference network status information. It is understandable that the consensus mechanism in the blockchain network is essentially a contradictory combination of the efficiency of information recording and the reliability of information. This means that the efficiency of information recording and the reliability of information are the two ends of a seesaw. Adjusting the consensus parameters will only make one increase while the other decreases, which means that there will not be a perfect consensus parameter that allows the blockchain network to maintain a good state stably. Therefore, after a period of time after the consensus parameters of the blockchain network are updated and the network status information of the blockchain network is driven to change, it is necessary to update the consensus parameters of the blockchain consensus mechanism again according to the network status information of the blockchain so that the blockchain network can dynamically maintain a good operating state, that is, the efficiency of information recording and the reliability of information are in a state of dynamic balance.
[0195] In some embodiments, the blockchain network includes multiple verification nodes, and the consensus parameters of the blockchain network are updated based on the target consensus parameters, including:
[0196] Send the target consensus parameters to the verification node for verification;
[0197] Receive the verification result returned by the verification node;
[0198] When it is determined according to the verification results that the target consensus parameters have been verified, the consensus parameters of the blockchain network are updated based on the target consensus parameters.
[0199] In the disclosed embodiment, a consensus parameter adjustment mechanism based on proxy voting is provided. In the disclosed embodiment, the blockchain network can specifically adopt the DPoS consensus mechanism, and the blockchain network includes multiple verification nodes. After the target consensus parameters are calculated, the target consensus parameters can be sent to the verification nodes for verification. Ordinary nodes can delegate their voting rights to trusted verification nodes, and the verification nodes make decisions on parameter adjustments based on the needs of ordinary nodes and network status. Then, the verification results returned by the verification nodes can be received, and it can be determined whether the target consensus parameters have been verified based on the verification results returned by the verification nodes. When it is determined that the target consensus parameters have been verified based on the verification results returned by the verification nodes, the consensus parameters of the blockchain network can be updated based on the target consensus parameters. This solution can retain the decentralized characteristics of the blockchain, thereby improving the security of the blockchain.
[0200] In some embodiments, when it is determined according to the verification result that the target consensus parameter is verified, the consensus parameter of the blockchain network is updated based on the target consensus parameter, including:
[0201] Determine a first number of verification nodes that have passed the verification according to the verification result;
[0202] Obtaining a total number of verification nodes from the plurality of verification nodes to obtain a second number;
[0203] When the ratio of the first quantity to the second quantity is greater than a preset threshold, the consensus parameters of the blockchain network are updated based on the target consensus parameters.
[0204] Among them, in the disclosed embodiment, whether the verification of the target consensus parameters is passed or not can be determined according to the verification results returned by the verification nodes, and the proportion of the verification nodes that have passed the verification in the total number of verification nodes can be determined, and whether the verification is passed or not can be determined according to the proportion. Specifically, the first number of verification nodes that have passed the verification can be determined according to the verification results, and then the total number of verification nodes in the multiple verification nodes (herein referred to as the second number) can be obtained. When the ratio of the first number to the second number is greater than a preset threshold value (for example, 51%), it can be determined that the verification of the target consensus parameters is passed, and at this time, the consensus parameters of the blockchain network can be updated based on the target consensus parameters.
[0205] In some embodiments, when the ratio of the first quantity to the second quantity is greater than a preset threshold, updating the consensus parameters of the blockchain network based on the target consensus parameters includes:
[0206] When the ratio of the first quantity to the second quantity is greater than a preset threshold, generating a target smart contract based on the target consensus parameters;
[0207] The target smart contract is sent to each node in the blockchain network to update the consensus parameters of the blockchain network based on the target smart contract.
[0208] In the disclosed embodiment, a specific smart contract can be deployed in the blockchain to handle the update logic of the consensus parameters. The smart contract can automatically update the associated parameters according to the target consensus parameters, and broadcast the update information to the verifier and other network nodes in the blockchain. Specifically, a target smart contract can be generated based on the target consensus parameters, and then the target smart contract can be sent to each node in the blockchain network to update the consensus parameters of the blockchain network according to the target smart contract. This solution can ensure the transparency, verifiability and decentralization of the blockchain consensus parameter update process.
[0209] In some embodiments, obtaining network status information in a blockchain network includes:
[0210] Get the current generation information of the blockchain network and the block height information of the current generation;
[0211] When the current block is determined to be the last block of the current generation according to the block height information, the network status information in the blockchain network is obtained;
[0212] Update the consensus parameters of the blockchain network based on the target consensus parameters, including:
[0213] Update the consensus parameters of the next generation of the blockchain network based on the target consensus parameters.
[0214] In the disclosed embodiment, the frequency of updating the consensus parameters of the consensus mechanism in the blockchain can be based on the epoch in the blockchain, that is, the consensus parameters are updated once every epoch. The epoch refers to a time period in the DPoS consensus mechanism. When the verification nodes in the blockchain need to be updated during the epoch change, the consensus parameters of the consensus mechanism in the blockchain can be updated at the same time.
[0215] Specifically, the current generation information of the blockchain network and the block height information of the current generation can be obtained. If the current block is determined to be the last block of the current generation based on the block height information, the network status information in the blockchain network can be obtained, and the target consensus parameters that need to be updated can be determined accordingly. Then, the consensus parameters of the next generation of the blockchain network are updated based on the determined target consensus parameters.
[0216] In some embodiments, after updating the consensus parameters of the next generation of the blockchain network based on the target consensus parameters, the process further includes:
[0217] Select new verification node information from candidates that meet the staking conditions;
[0218] Create the next generation of the current generation based on the new validation node information and updated consensus parameters.
[0219] In the disclosed embodiment, after the consensus parameters of the next generation are updated, the next generation of the blockchain can be created based on the updated consensus parameters of the next generation and the selected verification nodes of the next generation.
[0220] In summary, the consensus parameter updating method provided by the present disclosure is adopted, by obtaining the network status information in the blockchain network, the network status information includes the number of candidate nodes and verification nodes in the blockchain network, the block time information, the transaction demand information and the network congestion degree information; the network status information is compared with the preset reference network status information to obtain the network status deviation information; based on the constraint relationship between the network status information and the consensus parameters, the consensus parameter adjustment value corresponding to the network status deviation information is determined, and the consensus parameters include the pre-stored virtual resource amount, the reward or penalty virtual resource amount and the block interval time; the target consensus parameters are calculated according to the consensus parameter adjustment value and the current consensus parameters of the blockchain network; the consensus parameters of the blockchain network are updated based on the target consensus parameters. In this way, the consensus parameter updating method provided by the present disclosure can update the consensus parameters in the blockchain consensus mechanism in real time according to the network status information in the blockchain network, so that the consensus parameters in the blockchain network can adapt to the changes in the blockchain network environment, thereby improving the performance of the blockchain in all aspects.
[0221] The embodiments of the present disclosure are described in detail in combination with specific application scenarios.
[0222] like Figure 5 As shown, it is another flow chart of the consensus parameter update method provided by the present disclosure. In the embodiment of the present disclosure, the consensus parameter update method provided by the present disclosure will be introduced in detail by applying the method in the proposal node in the blockchain network. The proposal node can be a terminal or a server. The method specifically includes the following steps:
[0223] Step 501, the proposal node obtains the block height information of the current block and the generation information of the current generation.
[0224] In the related art, the DPoS consensus mechanism in the blockchain network sets fixed consensus parameters in the configuration file when the blockchain network is initialized, such as the number of validators, the minimum amount of pledged virtual resources, the amount of virtual resources for rewards and penalties (or the ratio of rewards and penalties), which results in the limited adaptability of the blockchain network in the face of changes in the state of the blockchain network and uncertain events. Specifically, when the load of the blockchain network, the number of validators, or the transaction demand, etc., change, the existing DPoS mechanism, due to the use of fixed consensus parameters, will cause problems such as network congestion of the blockchain network, a decrease in transaction processing speed, or a decrease in the security of the blockchain network. In addition, the DPoS consensus mechanism tends to use a fixed number of verification nodes, which may lead to centralization risks.
[0225] Since the consensus parameters in the DPoS consensus mechanism are fixed in the related technology, the blockchain network can only passively generate changes in the blockchain network state according to transaction requirements and node tendencies, and cannot actively control and optimize the blockchain network state information. The present disclosure provides a consensus parameter update method, which can automatically update the consensus parameters of the blockchain network according to the network state information of the blockchain network, thereby optimizing the blockchain network state and improving the transaction processing efficiency, security, and decentralization of the blockchain network.
[0226] The consensus parameter update method provided by the present disclosure can be applied to the proposal node in the blockchain network. The blockchain network can be any type of blockchain network, such as a private chain, a public chain or a consortium chain. The proposal node can be any type of node in the blockchain network, such as any type of node among ordinary nodes, candidate nodes and verification nodes. Specifically, the proposal node can be a randomly determined node in the blockchain network. That is, any node in the blockchain network can initiate a proposal for consensus parameter update and become a proposal node. Any node in the blockchain network can include the following modules: data collection module, data analysis module, parameter adjustment module and contract execution module. Figure 6As shown, it is a schematic diagram of the structure of the proposal node provided by the present disclosure. As shown in the figure, the proposal node 600 includes a data collection module 610, a data analysis module 620, a parameter adjustment module 630 and a contract execution module 640. The consensus parameter update method provided by the present disclosure will be introduced in detail below in combination with the multiple modules included in the proposal node.
[0227] The consensus parameter updating method provided by the present disclosure can specifically update the consensus parameters of the blockchain network according to a generation cycle. Specifically, after the last block of each generation is generated, the network status information in the blockchain network can be obtained, and the updated consensus parameters can be determined based on the obtained network status information of the blockchain network. Then, a new generation of the blockchain is created based on the updated consensus parameters and the re-selected verification nodes. Therefore, in the embodiment of the present disclosure, the proposal node (each node in the blockchain network) obtains the generation information of the current generation and the block height information of the currently generated block in real time to determine whether the currently generated block is the last block of the current generation.
[0228] Step 502, when it is detected that the block height information of the current block indicates that the current block is the last block of the current generation, the proposal node obtains the network status information in the blockchain network.
[0229] If the proposal node determines that the currently generated block is not the last block of the current generation based on the acquired block height information and generation information, it will not initiate the acquisition of network status information in the blockchain network, and will continue to acquire and detect the block information of the current block and the generation information of the current generation. When the proposal node detects that the block height information of the current block indicates that the current block is the last block of the current generation, the proposal node begins to acquire the network status information in the blockchain network. Specifically, the proposal node can use the data collection module to acquire the network status information of the blockchain network. The network status information can specifically include the number of candidate nodes and verification nodes in the blockchain network, block generation time information, transaction demand information, and network congestion information.
[0230] Step 503: The proposal node analyzes the acquired network status information to obtain an analysis result.
[0231] After obtaining the network status information of the blockchain network, the data analysis module 620 in the proposal node can be used to analyze the collected network status information to obtain analysis results. For example, trends and indicators in terms of transaction processing speed, verification node participation, network load, etc. can be calculated as analysis results. These analysis results are then used to provide a basis for updating consensus parameters.
[0232] Step 504: The proposing node determines the target consensus parameters that match the network status information based on the analysis results and the pre-stored parameter adjustment rules.
[0233] After analyzing the acquired network status information to obtain the analysis results, the parameter adjustment module 630 in the proposal node can be used to determine the target consensus parameters that match the network status information according to the analysis results. Among them, the parameter adjustment module 630 can store rules for determining the adjustment strategy of the consensus parameters. When the parameter adjustment module 630 receives the analysis results output by the data analysis module 620, it can calculate the target consensus parameters that match the network status information based on the analysis results and the rules of the pre-stored consensus parameter adjustment strategy.
[0234] Among them, the adjustment strategy rules of the consensus parameters have been introduced in detail in the above embodiments and will not be repeated here.
[0235] Step 505: The proposing node sends the target consensus parameters to the verifying node for verification.
[0236] When the proposal node determines the target consensus parameters that match the obtained network status information, it can send the target consensus parameters to the verification nodes in the blockchain network for verification. Among them, since the proposal node itself may also be a verification node, when the proposal node itself is also a verification node, the target consensus parameters can be sent to other verification nodes for verification.
[0237] Step 506: The verification node verifies the received target consensus parameters and returns the verification result to the proposing node.
[0238] After receiving the target consensus parameters sent by the proposal node, the verification node in the blockchain network can verify the received target consensus parameters. As mentioned above, each node in the blockchain network has the above four modules, that is, each node in the blockchain network will obtain the network status information of the blockchain network and determine the corresponding target consensus parameters. After receiving the target consensus parameters sent by the proposal node, the verification node can verify the received target consensus parameters based on the target consensus parameters determined by the verification node itself to obtain the verification result. Then the verification result is returned to the proposal node.
[0239] Step 507: When the verification result returned by the verification node indicates that the target consensus parameter verification has passed, the proposal node generates a target smart contract based on the target consensus parameter and the preset smart contract template.
[0240] After receiving the verification result returned by the verification node, the proposal node can determine whether the target consensus parameters have been verified based on the ratio of the number of nodes that have passed the verification in the verification result to the total number of verification nodes. If the verification result returned by the verification node determines that the target consensus parameters have not been verified, a proposal node can be randomly replaced; if the verification result returned by the verification node determines that the target consensus parameters have been verified, the proposal node can generate the target smart contract based on the target consensus parameters and the preset smart contract template. Among them, the generation of the target smart contract based on the target consensus parameters and the preset smart contract template can be specifically executed by the contract execution module 640 in the proposal node.
[0241] Step 508: The proposing node broadcasts the target smart contract to other nodes in the blockchain.
[0242] After the proposal node generates the target smart contract, it can broadcast the generated target smart contract to other nodes in the blockchain to update the parameters in the corresponding smart contracts in other nodes.
[0243] Step 509: Each node in the blockchain writes the target consensus parameters in the target smart contract into the ledger file and the world state database.
[0244] After receiving the target smart contract sent by the proposal node, each node of the blockchain can write the target consensus parameters in the target smart contract into the ledger file and the world state database, so that the target consensus parameters can be used as the parameters of the consensus mechanism in the next generation.
[0245] The consensus parameter updating method provided by the present disclosure provides a method for actively updating the consensus parameters of the consensus mechanism in the blockchain network. In this scheme, each node in the blockchain network can automatically obtain the network status information of the blockchain network in real time, and determine the consensus parameters that match it according to the network status information, and then update the consensus parameters of the consensus mechanism in the blockchain network according to the re-determined consensus parameters. In this way, the dynamic balance of the network status of the blockchain network can be achieved, avoiding the problem that the fixed consensus parameters cannot adapt to the changes in the network status information of the blockchain network, thereby causing the performance of the blockchain to deteriorate.
[0246] Description of the apparatus and device of the present disclosure
[0247] It is to be understood that, although the steps in the above-mentioned flowcharts are sequentially displayed according to the characterization of arrows, these steps are not necessarily executed in sequence according to the order of arrow characterization. Unless there is a clear description in the present embodiment, the execution of these steps does not have a strict order restriction, and these steps can be executed in other orders. Moreover, at least a portion of the steps in the above-mentioned flowcharts can include multiple steps or multiple stages, and these steps or stages are not necessarily executed at the same time, but can be executed at different times, and the execution order of these steps or stages is not necessarily to be carried out in sequence, but can be executed in turn or alternately with other steps or at least a portion of the steps or stages in other steps.
[0248] It should be noted that in each specific embodiment of the present disclosure, when it comes to the need to perform relevant processing based on data related to the characteristics of the target object such as the target object attribute information or attribute information set, the permission or consent of the target object will be obtained first, and the collection, use and processing of these data will comply with the relevant laws, regulations and standards of the relevant region. In addition, when the embodiment of the present application needs to obtain the attribute information of the target object, the separate permission or separate consent of the target object will be obtained through a pop-up window or jump to a confirmation page. After clearly obtaining the separate permission or separate consent of the target object, the necessary target object-related data used to enable the normal operation of the embodiment of the present application will be obtained.
[0249] Figure 7 A schematic diagram of the structure of a consensus parameter updating device 700 provided in an embodiment of the present disclosure. The consensus parameter updating device 700 includes:
[0250] The acquisition unit 710 is used to acquire network status information in the blockchain network, where the network status information includes information on the number of candidate nodes and verification nodes in the blockchain network, block generation time information, transaction demand information, and network congestion level information;
[0251] The comparison unit 720 is used to compare the network state information with the preset reference network state information to obtain network state deviation information;
[0252] A determination unit 730 is used to determine a consensus parameter adjustment value corresponding to the network state deviation information based on a constraint relationship between the network state information and the consensus parameters, where the consensus parameters include the amount of pre-stored virtual resources, the amount of virtual resources rewarded or punished, and the block interval;
[0253] A calculation unit 740 is used to calculate a target consensus parameter according to the consensus parameter adjustment value and the current consensus parameter of the blockchain network;
[0254] The updating unit 750 is used to update the consensus parameters of the blockchain network based on the target consensus parameters.
[0255] Optionally, in some embodiments, the blockchain network includes multiple verification nodes, and the updating unit 750 includes:
[0256] The verification subunit is used to send the target consensus parameters to the verification node for verification;
[0257] A receiving subunit, used to receive the verification result returned by the verification node;
[0258] The updating subunit is used to update the consensus parameters of the blockchain network based on the target consensus parameters when it is determined according to the verification result that the verification of the target consensus parameters has passed.
[0259] Optionally, in some embodiments, updating the subunit includes:
[0260] A determination module, configured to determine a first number of verification nodes that have passed the verification according to the verification result;
[0261] An acquisition module, used to acquire the total number of verification nodes from the plurality of verification nodes to obtain a second number;
[0262] The update module is used to update the consensus parameters of the blockchain network based on the target consensus parameters when the ratio of the first number to the second number is greater than a preset threshold.
[0263] Optionally, in some embodiments, the update module includes:
[0264] A generating submodule, configured to generate a target smart contract based on a target consensus parameter when a ratio of the first quantity to the second quantity is greater than a preset threshold;
[0265] The sending submodule is used to send the target smart contract to each node in the blockchain network to update the consensus parameters of the blockchain network based on the target smart contract.
[0266] Optionally, in some embodiments, the acquiring unit 710 includes:
[0267] The first acquisition subunit is used to obtain the current generation information and the block height information of the current generation of the blockchain network;
[0268] A second acquisition subunit is used to acquire network status information in the blockchain network when it is determined that the current block is the last block of the current generation according to the block height information;
[0269] The updating unit 750 is further configured to:
[0270] Update the consensus parameters of the next generation of the blockchain network based on the target consensus parameters.
[0271] Optionally, in some embodiments, the consensus parameter updating device 700 provided by the present disclosure further includes:
[0272] The selection subunit is used to select new verification node information from candidates that meet the staking conditions;
[0273] Create a subunit to create the next generation of the current generation based on the new verification node information and updated consensus parameters.
[0274] Optionally, in some embodiments, the network status information includes information on the number of candidate nodes and the number of verification nodes in the blockchain network, and the comparison unit 720 includes:
[0275] A first calculation subunit, used to calculate the node number average of the number of verification nodes and the number of candidate nodes within a preset period of time;
[0276] A first comparison subunit is used to compare the node quantity mean with a preset reference node quantity to obtain a node quantity difference;
[0277] The determining unit 730 includes:
[0278] A third acquisition subunit is used to acquire a constraint relationship between the number of nodes and the amount of pre-stored virtual resources, and determine an adjustment value of the amount of pre-stored virtual resources corresponding to the difference in the number of nodes according to the constraint relationship;
[0279] The first determining subunit is used to determine the consensus parameter adjustment value according to the pre-stored virtual resource amount adjustment value.
[0280] Optionally, in some embodiments, the network status information includes block generation duration information, and the comparison unit 720 includes:
[0281] The second calculation subunit is used to calculate the average duration of the block generation time within a preset period;
[0282] The second comparison subunit is used to compare the duration mean with a preset reference duration value to obtain a block duration difference;
[0283] The determining unit 730 includes:
[0284] A fourth acquisition subunit is used to obtain a constraint relationship between a block duration and a block interval duration, and determine an adjustment value of the block interval duration corresponding to the block duration difference according to the constraint relationship;
[0285] The second determination subunit is used to determine the consensus parameter adjustment value according to the adjustment value of the block interval time.
[0286] Optionally, in some embodiments, the network status information includes transaction demand information and network congestion information, and the comparison unit 720 includes:
[0287] The third calculation subunit is used to calculate the exponential mean of the transaction demand information and the network congestion degree information;
[0288] A third comparison subunit is used to compare the index mean with a preset reference index mean to obtain an index difference;
[0289] The determining unit 730 includes:
[0290] A fifth acquisition subunit is used to acquire a constraint relationship between the index mean and the amount of virtual resources awarded, and determine an adjustment value of the amount of virtual resources awarded corresponding to the index difference according to the constraint relationship;
[0291] The third determination subunit is used to determine the consensus parameter adjustment value according to the adjustment value of the rewarded virtual resource amount.
[0292] Optionally, in some embodiments, the determining unit 730 includes:
[0293] A prediction subunit, used to predict the network status change trend based on the network status deviation information;
[0294] The fourth determination subunit is used to determine the consensus parameter adjustment value corresponding to the network state change trend based on the constraint relationship between the network state information and the consensus parameter.
[0295] Optionally, in some embodiments, the acquiring unit 710 includes:
[0296] The sixth acquisition subunit is used to obtain the time interval between the current time and the last consensus parameter update time;
[0297] The seventh acquisition subunit is used to obtain network status information in the blockchain network when the time interval reaches a preset time.
[0298] Reference Figure 8 , Figure 8 The structural block diagram of the terminal part of the consensus parameter update method for implementing the embodiment of the present disclosure is shown in FIG. The terminal can be any node in the blockchain network, such as a proposal node, and the terminal includes: a radio frequency (RF) circuit 810, a memory 815, an input unit 830, a display unit 840, a sensor 850, an audio circuit 860, a wireless fidelity (WiFi) module 870, a processor 880, and a power supply 890. Those skilled in the art can understand that Figure 8 The terminal structure shown does not constitute a limitation on the mobile phone or computer, and may include more or fewer components than shown in the figure, or combine certain components, or arrange the components differently.
[0299] The RF circuit 810 may be used for receiving and sending signals during information transmission or calls. In particular, after receiving downlink information from the base station, it is sent to the processor 880 for processing; in addition, the designed uplink data is sent to the base station.
[0300] The memory 815 may be used to store software programs and modules. The processor 880 executes various functional applications of the terminal and updates consensus parameters by running the software programs and modules stored in the memory 815 .
[0301] The input unit 830 may be used to receive input digital or character information and generate key signal input related to the terminal's settings and function control. Specifically, the input unit 830 may include a touch panel 831 and other input devices 832 .
[0302] The display unit 840 may be used to display input information or provided information and various menus of the terminal. The display unit 840 may include a display panel 841.
[0303] The audio circuit 860, the speaker 861, and the microphone 862 may provide an audio interface.
[0304] In this embodiment, the processor 880 included in the terminal 140 can execute the consensus parameter updating method of the previous embodiment.
[0305] The terminals of the embodiments of the present disclosure include but are not limited to mobile phones, computers, intelligent voice interaction devices, smart home appliances, vehicle-mounted terminals, aircraft, etc.
[0306] Fig. 9 A block diagram of the structure of a portion of a server for implementing the consensus parameter update method of an embodiment of the present disclosure. The server can be any node in the blockchain network, such as a proposal node. The server may have relatively large differences due to different configurations or performances, and may include one or more central processing units (CPUs) 922 (e.g., one or more processors) and storage devices 932, and one or more storage media 930 (e.g., one or more massive storage devices) storing application programs 942 or data 944. Among them, the storage device 932 and the storage medium 930 may be short-term storage or permanent storage. The program stored in the storage medium 930 may include one or more modules (not shown in the figure), and each module may include a series of instruction operations on the server. Furthermore, the central processing unit 922 may be configured to communicate with the storage medium 930 and execute a series of instruction operations in the storage medium 930 on the server.
[0307] The server may also include one or more power supplies 926, one or more wired or wireless network interfaces 950, one or more input and output interfaces 958, and / or one or more operating systems 941, such as Windows ServerTM, Mac OS XTM, UnixTM, LinuxTM, FreeBSDTM, etc.
[0308] The central processor 922 in the server can be used to execute the consensus parameter updating method of the embodiment of the present disclosure.
[0309] The disclosed embodiments further provide a storage medium, which is used to store program codes, and the program codes are used to execute the consensus parameter updating methods of the aforementioned embodiments.
[0310] The embodiment of the present disclosure also provides a computer program product, which includes a computer program. A processor of a computer device reads and executes the computer program, so that the computer device executes and implements the above-mentioned consensus parameter update method.
[0311] The terms "first", "second", "third", "fourth", etc. (if any) in the specification of the present disclosure and the above-mentioned drawings are used to distinguish similar objects, and are not necessarily used to describe a specific order or sequence. It should be understood that the data used in this way can be interchangeable where appropriate, so that the embodiments of the present disclosure described herein can, for example, be implemented in an order other than those illustrated or described herein. In addition, the terms "comprises" and "comprising" and any variations thereof are intended to cover non-exclusive inclusions, for example, a process, method, system, product or device that includes a series of steps or units is not necessarily limited to those steps or units that are clearly listed, but may include other steps or units that are not clearly listed or inherent to these processes, methods, products or devices.
[0312] It should be understood that in the present disclosure, "at least one (item)" means one or more, and "plurality" means two or more. "And / or" is used to describe the association relationship of associated objects, indicating that three relationships may exist. For example, "A and / or B" can mean: only A exists, only B exists, and A and B exist at the same time, where A and B can be singular or plural. The character " / " generally indicates that the objects associated before and after are in an "or" relationship. "At least one of the following" or similar expressions refers to any combination of these items, including any combination of single or plural items. For example, at least one of a, b or c can mean: a, b, c, "a and b", "a and c", "b and c", or "a and b and c", where a, b, c can be single or multiple.
[0313] It should be understood that in the description of the embodiments of the present disclosure, the meaning of multiple (or multiple items) is more than two, greater than, less than, exceed, etc. are understood to not include the number, and above, below, within, etc. are understood to include the number.
[0314] In the several embodiments provided in the present disclosure, it should be understood that the disclosed systems, devices and methods can be implemented in other ways. For example, the device embodiments described above are only schematic. For example, the division of units is only a logical function division. There may be other division methods in actual implementation. For example, multiple units or components can be combined or integrated into another system, or some features can be ignored or not executed. Another point is that the mutual coupling or direct coupling or communication connection shown or discussed can be an indirect coupling or communication connection through some interfaces, devices or units, which can be electrical, mechanical or other forms.
[0315] The units described as separate components may or may not be physically separated, and the components shown as units may or may not be physical units, that is, they may be located in one place or distributed on multiple network units. Some or all of the units may be selected according to actual needs to achieve the purpose of the solution of this embodiment.
[0316] In addition, each functional unit in each embodiment of the present disclosure may be integrated into one processing unit, or each unit may exist physically separately, or two or more units may be integrated into one unit. The above-mentioned integrated unit may be implemented in the form of hardware or in the form of software functional units.
[0317] If the integrated unit is implemented in the form of a software functional unit and sold or used as an independent product, it can be stored in a storage medium. Based on this understanding, the technical solution of the present disclosure is essentially or the part that contributes to the prior art or all or part of the technical solution can be embodied in the form of a software product. The computer software product is stored in a storage medium, including a number of instructions to enable a computer device (which can be a personal computer, a server, or a network device, etc.) to perform all or part of the steps of the various embodiments of the present disclosure. The aforementioned storage medium includes: U disk, mobile hard disk, read-only memory (Read-Only Memory, referred to as ROM), random access memory (Random Access Memory, referred to as RAM), disk or optical disk and other media that can store program codes.
[0318] It should also be understood that the various implementations provided in the embodiments of the present disclosure can be combined arbitrarily to achieve different technical effects.
[0319] The above is a specific description of the implementation methods of the present disclosure, but the present disclosure is not limited to the above implementation methods. Technical personnel familiar with the art can also make various equivalent modifications or substitutions without violating the spirit of the present disclosure. These equivalent modifications or substitutions are all included in the scope defined by the claims of the present disclosure.
Claims
1. A consensus parameter updating method, characterized in that: The method comprises: Get network status information in the blockchain network; Comparing the network status information with preset reference network status information to obtain network status deviation information; Determine the consensus parameter adjustment value corresponding to the network state deviation information based on the constraint relationship between the network state information and the consensus parameters, wherein the consensus parameters include the amount of pre-stored virtual resources, the amount of virtual resources rewarded or punished, and the block interval time; Calculate the target consensus parameter according to the consensus parameter adjustment value and the current consensus parameter of the blockchain network; The consensus parameters of the blockchain network are updated based on the target consensus parameters.
2. The method according to claim 1, characterized in that The blockchain network includes a plurality of verification nodes, and the updating of the consensus parameters of the blockchain network based on the target consensus parameters includes: Sending the target consensus parameters to the verification node for verification; Receiving the verification result returned by the verification node; When it is determined according to the verification result that the target consensus parameter is verified to be passed, the consensus parameter of the blockchain network is updated based on the target consensus parameter.
3. The method according to claim 2, characterized in that When it is determined according to the verification result that the target consensus parameter is verified, updating the consensus parameter of the blockchain network based on the target consensus parameter includes: Determine a first number of verification nodes that have passed the verification according to the verification result; Obtaining a total number of verification nodes from the plurality of verification nodes to obtain a second number; When the ratio of the first number to the second number is greater than a preset threshold, the consensus parameters of the blockchain network are updated based on the target consensus parameters.
4. The method according to claim 3, characterized in that When the ratio of the first number to the second number is greater than a preset threshold, updating the consensus parameter of the blockchain network based on the target consensus parameter includes: When the ratio of the first quantity to the second quantity is greater than a preset threshold, generating a target smart contract based on the target consensus parameters; The target smart contract is sent to each node in the blockchain network to update the consensus parameters of the blockchain network based on the target smart contract.
5. The method according to claim 1, characterized in that The obtaining of network status information in the blockchain network includes: Get the current generation information of the blockchain network and the block height information of the current generation; When it is determined according to the block height information that the current block is the last block of the current generation, obtaining network status information in the blockchain network; The updating of the consensus parameters of the blockchain network based on the target consensus parameters includes: The consensus parameters of the next generation of the blockchain network are updated based on the target consensus parameters.
6. The method according to claim 5, characterized in that After the consensus parameters of the next generation of the blockchain network are updated based on the target consensus parameters, the method further includes: Select new verification node information from candidates that meet the staking conditions; Create the next generation of the current generation according to the new verification node information and the updated consensus parameters.
7. The method according to any one of claims 1 to 6, characterized in that The network status information includes information about the number of candidate nodes and the number of verification nodes in the blockchain network. The network status information is compared with preset reference network status information to obtain network status deviation information, including: Calculate the average number of verification nodes and candidate nodes within a preset period of time; Comparing the node quantity mean with a preset reference node quantity to obtain a node quantity difference; The determining the consensus parameter adjustment value corresponding to the network state deviation information based on the constraint relationship between the network state information and the consensus parameter includes: Acquire a constraint relationship between the number of nodes and the amount of pre-stored virtual resources, and determine an adjustment value of the amount of pre-stored virtual resources corresponding to the difference in the number of nodes according to the constraint relationship; The consensus parameter adjustment value is determined according to the adjustment value of the pre-stored virtual resource amount.
8. The method according to any one of claims 1 to 6, characterized in that The network status information includes block generation time information, and the network status information is compared with preset reference network status information to obtain network status deviation information, including: Calculate the average block duration within the preset period; Compare the duration mean with a preset reference duration value to obtain a block duration difference; The determining the consensus parameter adjustment value corresponding to the network state deviation information based on the constraint relationship between the network state information and the consensus parameter includes: Obtaining a constraint relationship between a block duration and a block interval duration, and determining an adjustment value of the block interval duration corresponding to the block duration difference according to the constraint relationship; The consensus parameter adjustment value is determined according to the adjustment value of the block interval time.
9. The method according to any one of claims 1 to 6, characterized in that The network status information includes transaction demand information and network congestion degree information, and the network status information is compared with preset reference network status information to obtain network status deviation information, including: Calculating the exponential mean of the transaction demand information and the network congestion degree information; Comparing the index mean with a preset reference index mean to obtain an index difference; The determining the consensus parameter adjustment value corresponding to the network state deviation information based on the constraint relationship between the network state information and the consensus parameter includes: Obtaining a constraint relationship between the index mean and the amount of virtual resources awarded, and determining an adjustment value of the amount of virtual resources awarded corresponding to the index difference according to the constraint relationship; The consensus parameter adjustment value is determined according to the adjustment value of the rewarded virtual resource amount.
10. The method according to claim 1, characterized in that The determining the consensus parameter adjustment value corresponding to the network state deviation information based on the constraint relationship between the network state information and the consensus parameter includes: Predicting a network status change trend according to the network status deviation information; The consensus parameter adjustment value corresponding to the network state change trend is determined based on the constraint relationship between the network state information and the consensus parameter.
11. The method according to claim 1, characterized in that: The obtaining of network status information in the blockchain network includes: Get the time interval between the current time and the last consensus parameter update time; When the time interval reaches a preset time, the network status information in the blockchain network is obtained.
12. A consensus parameter updating device, characterized in that: The device comprises: An acquisition unit, used to acquire network status information in the blockchain network; A comparing unit, used to compare the network state information with preset reference network state information to obtain network state deviation information; A determination unit, configured to determine a consensus parameter adjustment value corresponding to the network state deviation information based on a constraint relationship between the network state information and consensus parameters, wherein the consensus parameters include a pre-stored virtual resource amount, a rewarded or punished virtual resource amount, and a block generation interval; A calculation unit, configured to calculate a target consensus parameter according to the consensus parameter adjustment value and a current consensus parameter of the blockchain network; An updating unit is used to update the consensus parameters of the blockchain network based on the target consensus parameters.
13. A storage medium storing a computer program, characterized in that: When the computer program is executed by a processor, the consensus parameter updating method according to any one of claims 1 to 11 is implemented.
14. A computer device comprising a memory and a processor, wherein the memory stores a computer program, characterized in that: When the processor executes the computer program, it implements the consensus parameter updating method according to any one of claims 1 to 11.
15. A computer program product, comprising a computer program, wherein the computer program is read and executed by a processor of a computer device, so that the computer device executes the consensus parameter updating method according to any one of claims 1 to 11.