Consensus algorithm configuration change method, device and storage medium based on log observation
By configuring log collection tools and preset policies in blockchain nodes, and automatically generating and executing configuration change transactions, the problem of consensus algorithm configuration relying on manual in harsh network environments is solved, efficient configuration changes are achieved without downtime, and system stability and user experience are improved.
Patent Information
- Application Number
- CN202311083984.X
- Authority / Receiving Office
- CN · China
- Patent Type
- Patents(China)
- Current Assignee / Owner
- Filing Date
- 2023-08-25
- Publication Date
- 2025-08-26
- Estimated Expiration
- 2043-08-25
AI Technical Summary
In harsh network environments, blockchain node consensus algorithm configuration requires manual intervention, resulting in long downtime, relying on operation and maintenance personnel experience and difficulty in systematically solving problems.
By configuring the target log collection tool in the blockchain node, collecting log data and detecting exceptions, generating configuration change transaction requests based on preset policies, and automatically performing configuration change transactions to achieve non-stop configuration changes of the consensus algorithm.
The configuration changes of automated consensus algorithms without human participation have been realized, which improves the reliability and accuracy of configuration, reduces downtime, and improves user experience.
Smart Images

Figure CN117312336B_ABST
Abstract
Description
Technical Field
[0001] The present application relates to the field of blockchain technology, and in particular to a method, device, and storage medium for changing the configuration of a consensus algorithm based on log observation. Background Art
[0002] Blockchain, a distributed ledger technology, has been widely applied in finance, supply chain, the Internet of Things, and other fields. The core of blockchain is the consensus algorithm, which ensures that nodes in the network reach agreement on transactions and state changes. However, in harsh network environments, manual modification of node consensus algorithm configurations is often required by operations and maintenance personnel. This relies heavily on the experience of these personnel, and the modification process can result in significant downtime, impacting user experience. Summary of the Invention
[0003] In order to solve the technical problem of how to automatically and accurately implement the change of consensus algorithm configuration without downtime, the present application provides a consensus algorithm configuration change method, device and storage medium based on log observation.
[0004] In a first aspect, the present application provides a method for changing the configuration of a consensus algorithm based on log observation, the method comprising:
[0005] Obtaining log data of a blockchain node; wherein the blockchain node is configured with a target log collection tool, and the target log collection tool is used to collect the log data of the blockchain node;
[0006] Detecting all the log data, and determining a target strategy from a preset strategy when detecting an abnormality in a target node among the blockchain nodes;
[0007] Generate a configuration change transaction request according to the target policy; wherein the configuration change transaction request includes configuration information;
[0008] Executing the configuration change transaction corresponding to the configuration change transaction request, so as to send the configuration information to the target node after the configuration change transaction is executed, and perform configuration changes on the consensus algorithm of the target node using the configuration information;
[0009] Optionally, before determining the target strategy from the preset strategies, the method further includes:
[0010] Configuring the preset policy in a configuration management system;
[0011] The preset strategies include at least the following strategies:
[0012] If the blockchain node does not generate a new block within a first preset time period, executing a first strategy; wherein the first strategy includes calculating network latency to reduce the block size when the network latency is greater than a first preset threshold, and / or adjusting a timeout for attempted changes based on a log check of view change status;
[0013] If the number of interruption logs between any two blockchain nodes exceeds a second preset threshold, a node connection strategy is executed; wherein the node connection strategy includes at least one of controlling the blockchain node to communicate only with a preset node, adjusting the node weight of the blockchain node, adjusting the election strategy, replacing the master node, and activating a backup node; wherein the preset node is a node that has stable communication with any blockchain node, and the election strategy includes an election strategy for a leader or a validator among the blockchain nodes;
[0014] If no transaction is uploaded to the chain within the second preset time, the master node will be replaced;
[0015] Optionally, executing the configuration change transaction corresponding to the configuration change transaction request includes:
[0016] Obtaining the verification transaction signature of the target client corresponding to the configuration change transaction request;
[0017] Broadcasting the signed configuration change transaction to all participants so that they can reach a consensus on the configuration change transaction;
[0018] Executing the configuration change transaction after consensus, and broadcasting transaction confirmation information to the participants, so that each participant records based on the transaction confirmation information; wherein the transaction confirmation information at least includes the transaction execution result and status update information;
[0019] Optionally, broadcasting the signed configuration change transaction to the participants so that the participants reach a consensus on the configuration change transaction includes:
[0020] Broadcast the signed configuration change transaction to all participants;
[0021] Obtaining target verification results of the configuration change transaction by each participant;
[0022] If the target verification result indicates that all the participants have reached a consensus, then continue to execute the step of executing the configuration change transaction after the consensus is reached;
[0023] Optionally, performing detection on all the log data includes:
[0024] The log server obtains the target log data of each of the blockchain nodes from the target log collection tool, and uses all the target log data as the log data;
[0025] The log processing module obtains the log data from the log server and detects the log data;
[0026] Optionally, after obtaining the log data of the blockchain node, the method further includes:
[0027] Based on the target log collection tool, each blockchain node is monitored in real time and a consensus algorithm performance report is generated; wherein the consensus algorithm performance report includes at least the processing time, latency, and resource utilization of each blockchain node;
[0028] Analyze the consensus algorithm performance of each of the blockchain nodes according to the consensus algorithm performance report to obtain analysis results;
[0029] Optionally, the method further includes:
[0030] Based on the target log collection tool, the consensus algorithm configuration change process of each blockchain node is recorded respectively.
[0031] In a second aspect, the present application provides a device for changing the configuration of a consensus algorithm based on log observation, the device comprising:
[0032] An acquisition module, configured to acquire log data of a blockchain node; wherein the blockchain node is configured with a target log collection tool, and the target log collection tool is configured to collect log data of the blockchain node;
[0033] A detection module, configured to detect all the log data and, upon detecting an abnormality in a target node among the blockchain nodes, determine a target strategy from preset strategies;
[0034] a transaction request generating module, configured to generate a configuration change transaction request according to the target policy; wherein the configuration change transaction request includes configuration information;
[0035] An execution module is used to execute the configuration change transaction corresponding to the configuration change transaction request, so as to send the configuration information to the target node after the configuration change transaction is executed, and to change the configuration of the consensus algorithm of the target node through the configuration information.
[0036] In a third aspect, the present application provides an electronic device, comprising a processor, a communication interface, a memory, and a communication bus, wherein the processor, the communication interface, and the memory communicate with each other via the communication bus;
[0037] Memory for storing computer programs;
[0038] The processor is used to implement the steps of the consensus algorithm configuration change method based on log observation described in any one of the embodiments of the first aspect when executing the program stored in the memory.
[0039] In a fourth aspect, the present application provides a computer-readable storage medium having a computer program stored thereon, which, when executed by a processor, implements the steps of the consensus algorithm configuration change method based on log observation as described in any embodiment of the first aspect.
[0040] The above technical solution provided by the embodiment of the present application has the following advantages compared with the prior art:
[0041] The method provided by the embodiment of the present application configures a target log collection tool in each blockchain node, collects log data of each blockchain node respectively, detects all log data, and when an abnormality is detected in the target node in the blockchain node, determines the target strategy from the preset strategy, and generates a configuration change transaction request according to the target strategy; wherein the configuration change transaction request includes configuration information; executes the configuration change transaction corresponding to the configuration change transaction request, so as to send the configuration information to the target node after the configuration change transaction is executed, and performs configuration changes on the consensus algorithm of the target node through the configuration information. This method can automatically make configuration changes to the consensus algorithm of the target node with problems without manual intervention, thereby improving the reliability and accuracy of the configuration change, and the sending of the configuration information adopts the form of a configuration change transaction. After the target node executes the transaction, the configuration of the target node will be changed according to the configuration information in the transaction, thereby achieving non-stop configuration changes and improving the user experience. BRIEF DESCRIPTION OF THE DRAWINGS
[0042] The accompanying drawings, which are incorporated in and constitute a part of this specification, illustrate embodiments consistent with the present application and, together with the description, serve to explain the principles of the present application.
[0043] In order to more clearly illustrate the embodiments of the present application or the technical solutions in the prior art, the following briefly introduces the drawings required for use in the embodiments or the description of the prior art. Obviously, for ordinary technicians in this field, other drawings can be obtained based on these drawings without any creative work.
[0044] Figure 1 A system architecture diagram of a method for changing the consensus algorithm configuration based on log observation provided in one embodiment of the present application;
[0045] Figure 2 A flowchart of a method for changing the consensus algorithm configuration based on log observation provided in one embodiment of the present application;
[0046] Figure 3A schematic diagram of a device for changing a consensus algorithm configuration based on log observation provided in one embodiment of the present application;
[0047] Figure 4 A schematic structural diagram of an electronic device provided in accordance with an embodiment of the present application. DETAILED DESCRIPTION
[0048] To make the purpose, technical solutions, and advantages of the embodiments of this application more clear, the technical solutions in the embodiments of this application will be clearly and completely described below in conjunction with the drawings in the embodiments of this application. Obviously, the described embodiments are part of the embodiments of this application, not all of the embodiments. Based on the embodiments in this application, all other embodiments obtained by ordinary technicians in this field without making creative efforts are within the scope of protection of this application.
[0049] The first embodiment of the present application provides a method for changing the consensus algorithm configuration based on log observation, such as Figure 1 This is a system architecture diagram of a consensus algorithm configuration change method based on log observation. The system architecture includes at least blockchain nodes 101, log servers 102, log event processing systems 103 and configuration management systems 104. Each blockchain node 101 establishes a communication connection with the log server 102 and the configuration management system 104 respectively, and the log event processing system 103 establishes a communication connection with the log server 102 and the configuration management system 104 respectively. The method can be applied to the log event processing system 103 in the system architecture.
[0050] To facilitate understanding of this application, the problems existing in the related art are briefly explained below.
[0051] Currently, in a harsh network environment, blockchain often requires operations and maintenance personnel to modify the node consensus algorithm configuration. This practice leads to the following problems:
[0052] First, manual intervention is required and the experience of operations personnel is relied upon, which means that during the execution process, dedicated personnel are needed to oversee and manage the entire process.
[0053] Secondly, the process can result in significant downtime, as the system may need to be restarted or reconfigured during configuration changes. This downtime can impact business operations and prevent users from accessing services. Furthermore, data loss is a potential risk, as data loss or inconsistencies may occur during the modification process.
[0054] Third, operations personnel often work on a per-node basis, making it difficult for them to analyze problems and propose solutions from a system-wide perspective. They may become overly focused on the performance and configuration of specific nodes, while overlooking the interrelationships and impacts of the entire system. When problems arise from the interactions between multiple nodes, this lack of overall awareness can prevent operations personnel from effectively resolving system-wide issues.
[0055] Next, based on this system architecture, the method for changing the consensus algorithm configuration based on log observation is described in detail. Figure 2 , methods include:
[0056] Step 201: Obtain log data of the blockchain node, wherein the blockchain node is configured with a target log collection tool, and the target log collection tool is used to collect log data of the blockchain node.
[0057] The blockchain system includes multiple blockchain nodes. A target log collection tool is configured in each blockchain node. For example, the fluent-bit log collection tool is configured. Fluent-bit can collect log data of the blockchain node.
[0058] Step 202: All log data is checked. When an abnormality is detected in a target node in the blockchain node, a target strategy is determined from preset strategies.
[0059] In one embodiment, all log data is detected, including: a log server obtains target log data of each blockchain node from a target log collection tool, and uses all target log data as log data; a log processing module obtains log data from the log server and detects the log data.
[0060] In this embodiment, the log server can be a LoKi log server. The LoKi log server obtains log data through fluent-bit configured on each blockchain node, and sends the log data of each node to the log event processing system. The log processing module in the log event processing system detects the log data.
[0061] In one embodiment, before determining the target policy from the preset policies, the method further includes: configuring the preset policy in a configuration management system.
[0062] The preset strategies include at least the following strategies:
[0063] The first strategy: If the blockchain node does not generate a new block within a first preset time period, the first strategy is executed, wherein the first strategy includes calculating network latency to reduce the block size when the network latency is greater than a first preset threshold, and / or adjusting the timeout period for attempted changes based on log inspection of view change status.
[0064] Blockchain nodes (also referred to as nodes) print logs containing block information when they generate blocks. Therefore, if a node does not generate new blocks for a long time, the log processing program will detect the anomaly and try the following remedial measures:
[0065] Network latency is calculated based on the time differences between requests sent and received by different nodes. Specifically, when a node sends or receives a request, the relevant information and time are logged. By calculating the time differences between network requests between different nodes, the network latency between nodes can be calculated. When network latency is excessive and packet loss is frequent, it can be considered that the network is overly congested. In this case, the block size can be reduced to prevent overly large blocks from failing to reach consensus in poor network conditions. The block generation rate can also be reduced to reduce network burden and improve blockchain stability.
[0066] For PBFT-like algorithms, the status of view changes can be checked based on logs. When a node's view change parameters are incorrectly set or incompatible with network conditions, nodes in the cluster will continuously attempt view changes to elect a new leader. However, since the election is unsuccessful, the cluster cannot advance toward consensus. Specifically, log messages such as "Enter View Change" will appear continuously in the node logs. If the log analysis program detects that a node frequently prints this log message and that no block submission log messages such as "Block 153 Finished" have appeared for an extended period, the node is considered to have entered an abnormal state of continuously attempting view changes. In this case, the view change timeout can be appropriately increased. Furthermore, if the cluster state becomes irreparably inconsistent, a node will also enter a state of continuously attempting view changes. In this case, log messages indicating that the node rejects information from other nodes due to state inconsistencies will appear. The log event handler can report this abnormality to operations personnel.
[0067] The second strategy: if the number of interruption logs between any two blockchain nodes exceeds a second preset threshold, the node connection strategy is executed; wherein the node connection strategy includes controlling the blockchain node to communicate only with the preset node, adjusting the node weight of the blockchain node, adjusting the election strategy, replacing the master node and enabling at least one of the backup nodes; wherein the preset node is a node that has stable communication with any blockchain node, and the election strategy includes the election strategy of the leader or validator in the blockchain node.
[0068] When the connection between some nodes is poor, you'll see frequent disconnection logs between the two nodes. Specifically, if the number of "connection not established" logs between two nodes exceeds a second preset threshold, the log analysis platform will deem the network connection between the two nodes to be poor. To restore cluster stability, you need to adjust the node connection policy.
[0069] Nodes can be made to communicate only with nodes with which they have a more stable connection, ensuring that the node does not waste bandwidth resources in the process of constantly trying to establish connections with other nodes.
[0070] Adjusting the weight of nodes in the consensus algorithm based on the network conditions of the nodes is an effective method while ensuring fairness. By adjusting the weight of nodes, it is easier for nodes with higher weights to reach consensus, thus ensuring that the cluster can still advance consensus as much as possible in a poor network environment.
[0071] Consider adjusting the leader or validator election strategy to select the fastest node while ensuring security and liveness, thereby improving cluster efficiency. Specifically, you can regularly proactively monitor and evaluate the node's CPU, memory, disk I / O, network I / O, and other performance indicators, and select the node with the best overall performance as the master node. This election strategy ensures that the highest-performing node in the cluster is selected as the leader or validator, thereby improving overall system efficiency. Through regular performance evaluation and elections, the master node can be dynamically adjusted, ensuring that the cluster remains efficient in a changing environment.
[0072] Thorough performance testing is performed in a pre-production environment to determine the expected throughput of the master node under good network conditions. In a production environment, if the current master node fails to meet reasonable performance indicators, a view change is triggered and the master node is replaced.
[0073] With the help of fault-tolerant mechanisms, spare nodes can be selected to participate in consensus, so that the cluster can still operate normally even if the connection between some nodes is interrupted.
[0074] The third strategy: If no transaction is uploaded to the chain within the second preset time, the master node will be replaced.
[0075] When the slave node log shows that transactions have not been uploaded to the chain for a long time, it can be considered that the master node lacks the ability to process transactions, or even that the master node is maliciously reviewing transactions, which has damaged fairness. The master node can be replaced. The master node can also be replaced when the number of slave nodes that have not uploaded transactions to the chain for a long time exceeds a specified threshold, with no restrictions.
[0076] After determining the target strategy, the configuration information can be issued according to the target strategy to implement the configuration change of the consensus algorithm. The specific process of configuration issuance includes:
[0077] Initial configuration upload. After completing the configuration, the operation and maintenance personnel start the node. After the node starts, the initial configuration is automatically uploaded to the configuration management system.
[0078] Configuration delivery request generation. The handler modifies the initial configuration based on the preset strategy and generates a configuration delivery request.
[0079] Configuration request broadcast. Configuration request will be broadcast to all blockchain nodes through the network. The broadcast mechanism can be implemented using point-to-point communication, broadcast and multicast, etc. according to the specific network architecture.
[0080] The blockchain node receives the request. Each blockchain node listens for configuration requests on the network and processes them after receiving them.
[0081] Verify the legitimacy of the request. The node will verify the legitimacy of the received configuration delivery request, including verifying the signature of the request, the identity of the sender, and other information to ensure the validity and security of the request and prevent malicious request tampering.
[0082] Parse configuration information. The node will parse the configuration information in the configuration delivery request, including network parameters, node parameters, etc.
[0083] Apply configuration information. The node will update its own configuration based on the parsed configuration information.
[0084] Configuration application completion notification. After the node has completed the configuration application, it can send a notification to the configuration management system to confirm that the configuration has been successfully applied.
[0085] This application aims to achieve non-stop changes to the consensus algorithm configuration, which can be done in the form of configuration change transactions after the target strategy is determined.
[0086] Step 203: Generate a configuration change transaction request according to the target policy, wherein the configuration change transaction request includes configuration information.
[0087] Step 204: Execute the configuration change transaction corresponding to the configuration change transaction request, so as to send the configuration information to the target node after the configuration change transaction is completed, and perform configuration changes on the consensus algorithm of the target node through the configuration information.
[0088] This method configures a target log collection tool in each blockchain node, collects log data from each blockchain node, and detects all log data. When an abnormality is detected in a target node in the blockchain node, the target strategy is determined from the preset strategy, and a configuration change transaction request is generated based on the target strategy; wherein the configuration change transaction request includes configuration information; the configuration change transaction corresponding to the configuration change transaction request is executed, so that the configuration information is sent to the target node after the configuration change transaction is completed, and the consensus algorithm of the target node is configured with the configuration information. This method can automatically change the configuration of the consensus algorithm of the target node with the problem without human intervention, thereby improving the reliability and accuracy of the configuration change. In addition, the configuration information is sent in the form of a configuration change transaction. After the target node executes the transaction, the configuration of the target node will be changed according to the configuration information in the transaction, thereby achieving non-stop configuration changes and improving the user experience.
[0089] In one embodiment, executing a configuration change transaction corresponding to a configuration change transaction request includes:
[0090] Get the verification transaction signature of the target client corresponding to the configuration change transaction request.
[0091] The signed configuration change transaction is broadcast to all participants so that they can reach a consensus on the configuration change transaction. Specifically, the following steps are performed: broadcasting the signed configuration change transaction to all participants, obtaining the target verification results of the configuration change transaction from each participant, and if the target verification results indicate that all participants have reached a consensus, then continuing to execute the steps of executing the consensus configuration change transaction.
[0092] Execute the configuration change transaction after consensus, and broadcast the transaction confirmation information to the participants so that each participant can record it based on the transaction confirmation information, where the transaction confirmation information at least includes the transaction execution result and status update information.
[0093] In this embodiment, the configuration change transaction can be as follows:
[0094] Configuration transaction generation: The log event processing system prepares a transaction containing configuration information based on the preset strategy.
[0095] Transaction Signature: After a transaction is generated, the target client (i.e., the blockchain client that initiates the transaction) will use its private key to sign the transaction to ensure the authenticity and integrity of the transaction. The target client can be set in the configuration management system or log event processing system without restriction.
[0096] Transaction broadcast: After signing, the transaction will be broadcast to all participants through the network.
[0097] Transaction verification: Each participant will verify the legitimacy of the received transaction, including verifying the transaction signature, sender identity and other information to ensure the validity and security of the transaction.
[0098] Transaction consensus: Each participant reaches consensus to ensure the order and consistency of transactions.
[0099] Transaction Execution: Consensus-received transactions are executed. This process may involve updating node configurations, adjusting parameters, and other operations, depending on the application scenario.
[0100] Transaction confirmation: Once a transaction is successfully executed, the participating party will generate transaction confirmation information and broadcast it to other participating parties. The transaction confirmation information may include transaction execution results, status updates, and other information.
[0101] Transaction persistence: After the transaction is confirmed, the relevant information of the transaction will be recorded in the blockchain to ensure the immutability and traceability of the transaction.
[0102] In this embodiment, a configuration change transaction is a special transaction used to modify the cluster configuration. After a node executes the transaction, the node configuration is modified based on the transaction body, enabling non-disruptive configuration changes. Furthermore, because the log event processing system can simultaneously analyze log data from multiple blockchain nodes, it can select the most efficient target strategy from among pre-set strategies, enhancing the performance and stability of the blockchain cluster.
[0103] In one embodiment, after obtaining the log data of the blockchain node, the method further includes: monitoring each blockchain node in real time based on the target log collection tool, and generating a consensus algorithm performance report, wherein the consensus algorithm performance report includes at least the processing time, delay time and resource utilization of each blockchain node, and analyzing the consensus algorithm performance of each blockchain node according to the consensus algorithm performance report to obtain an analysis result.
[0104] In this embodiment, the fluent-bit log collection tool, deployed on each blockchain node, monitors the blockchain node in real time and sends the monitoring data to the LoKi log server. The LoKi log server generates a consensus algorithm performance report based on the monitoring data. This consensus algorithm performance report is then used to analyze the consensus algorithm performance of each blockchain node and generate analysis results. Based on this analysis, bottlenecks in the blockchain consensus algorithm can be identified, performance issues can be promptly detected, and targeted optimizations can be implemented to improve system throughput and performance.
[0105] In one embodiment, the method further includes: recording the consensus algorithm configuration change process of each blockchain node based on a target log collection tool.
[0106] In this embodiment, the operations and interaction processes of the consensus algorithm of each blockchain node can also be recorded and monitored separately based on the target log collection tool to implement security auditing and compliance monitoring, prevent malicious behavior and illegal operations, and improve the stability and security of the overall operation of the blockchain.
[0107] Based on the same technical concept, the second embodiment of the present application provides a consensus algorithm configuration change device based on log observation, such as Figure 3 , the device comprises:
[0108] An acquisition module, configured to acquire log data of a blockchain node; wherein the blockchain node is configured with a target log collection tool, and the target log collection tool is configured to collect log data of the blockchain node;
[0109] A detection module, configured to detect all the log data and, upon detecting an abnormality in a target node among the blockchain nodes, determine a target strategy from preset strategies;
[0110] a transaction request generating module, configured to generate a configuration change transaction request according to the target policy; wherein the configuration change transaction request includes configuration information;
[0111] An execution module is used to execute the configuration change transaction corresponding to the configuration change transaction request, so as to send the configuration information to the target node after the configuration change transaction is executed, and to change the configuration of the consensus algorithm of the target node through the configuration information.
[0112] This device configures a target log collection tool in each blockchain node, collects log data from each blockchain node, and detects all log data. When an abnormality is detected in a target node in the blockchain node, the device determines the target strategy from the preset strategy and generates a configuration change transaction request based on the target strategy. The configuration change transaction request includes configuration information. The device executes the configuration change transaction corresponding to the configuration change transaction request, so that the configuration information is sent to the target node after the configuration change transaction is completed. The target node's consensus algorithm is configured with the configuration information. This method can automatically change the configuration of the consensus algorithm of the target node with the problem without human intervention, thereby improving the reliability and accuracy of the configuration change. In addition, the configuration information is sent in the form of a configuration change transaction. After the target node executes the transaction, the configuration of the target node will be changed according to the configuration information in the transaction, thereby achieving non-stop configuration changes and improving the user experience.
[0113] like Figure 4As shown, the third embodiment of the present application provides an electronic device, including a processor 111, a communication interface 112, a memory 113 and a communication bus 114, wherein the processor 111, the communication interface 112, and the memory 113 communicate with each other through the communication bus 114.
[0114] Memory 113, for storing computer programs;
[0115] In one embodiment, the processor 111 is configured to execute a program stored in the memory 113 to implement the method for changing the consensus algorithm configuration based on log observation provided by any of the aforementioned method embodiments, including:
[0116] Obtaining log data of a blockchain node; wherein the blockchain node is configured with a target log collection tool, and the target log collection tool is used to collect the log data of the blockchain node;
[0117] Detecting all the log data, and determining a target strategy from a preset strategy when detecting an abnormality in a target node among the blockchain nodes;
[0118] Generate a configuration change transaction request according to the target policy; wherein the configuration change transaction request includes configuration information;
[0119] Execute the configuration change transaction corresponding to the configuration change transaction request, so as to send the configuration information to the target node after the configuration change transaction is completed, and perform configuration changes on the consensus algorithm of the target node through the configuration information.
[0120] The communication bus mentioned in the terminal can be a Peripheral Component Interconnect (PCI) bus or an Extended Industry Standard Architecture (EISA) bus. This communication bus can be divided into an address bus, a data bus, a control bus, etc. For ease of illustration, only one thick line is used in the figure, but this does not mean that there is only one bus or only one type of bus.
[0121] The communication interface is used for communication between the above terminal and other devices.
[0122] The memory may include random access memory (RAM) or non-volatile memory, such as at least one disk storage. Alternatively, the memory may be at least one storage device located away from the processor.
[0123] The above-mentioned processor can be a general-purpose processor, including a central processing unit (CPU), a network processor (NP), etc.; it can also be a digital signal processor (DSP), an application-specific integrated circuit (ASIC), a field-programmable gate array (FPGA) or other programmable logic devices, discrete gate or transistor logic devices, and discrete hardware components.
[0124] The fourth embodiment of the present application also provides a computer-readable storage medium on which a computer program is stored. When the computer program is executed by a processor, the steps of the consensus algorithm configuration change method based on log observation as provided in any of the aforementioned method embodiments are implemented.
[0125] In the above embodiments, it can be implemented in whole or in part by software, hardware, firmware or any combination thereof. When software is used for implementation, it can be implemented in whole or in part in the form of a computer program product. The computer program product includes one or more computer instructions. When the computer program instructions are loaded and executed on a computer, the process or function described in the embodiment of the present application is generated in whole or in part. The computer can be a general-purpose computer, a special-purpose computer, a computer network, or other programmable device. The computer instructions can be stored in a computer-readable storage medium or transmitted from one computer-readable storage medium to another computer-readable storage medium. For example, the computer instructions can be transmitted from a website, computer, server or data center to another website, computer, server or data center via a wired (e.g., coaxial cable, optical fiber, digital subscriber line (DSL)) or wireless (e.g., infrared, wireless, microwave, etc.) method. The computer-readable storage medium can be any available medium that a computer can access or a data storage device such as a server or data center that includes one or more available media integrations. The available medium can be a magnetic medium (e.g., a floppy disk, a hard disk, a tape), an optical medium (e.g., a DVD), or a semiconductor medium (e.g., a solid-state drive (SSD)).
[0126] It should be noted that, in this document, relational terms such as "first" and "second" are used only to distinguish one entity or operation from another entity or operation, and do not necessarily require or imply any actual relationship or order between these entities or operations. Moreover, the terms "comprises," "comprising," or any other variations thereof are intended to cover non-exclusive inclusion, so that a process, method, article, or device comprising a series of elements includes not only those elements, but also other elements not explicitly listed, or elements inherent to such process, method, article, or device. In the absence of further limitations, an element defined by the phrase "comprising a ..." does not exclude the presence of other identical elements in the process, method, article, or device comprising the element.
[0127] It should be understood that the specific embodiments described herein are intended only to illustrate the present application and are not intended to limit the present application. In the description, suffixes such as "module," "component," or "unit" used to represent elements are used solely to facilitate the description of the present application and have no specific meaning. Therefore, "module," "component," or "unit" may be used interchangeably.
[0128] The foregoing is merely a list of specific embodiments of the present application, intended to enable those skilled in the art to understand or implement the present application. Various modifications to these embodiments will be readily apparent to those skilled in the art, and the general principles defined herein may be implemented in other embodiments without departing from the spirit or scope of the present application. Therefore, the present application is not limited to the embodiments shown herein, but is intended to conform to the broadest scope consistent with the principles and novel features of the present application.
Claims
1. A method for changing the consensus algorithm configuration based on log observation, characterized in that: The method comprises: Obtaining log data of a blockchain node; wherein the blockchain node is configured with a target log collection tool, and the target log collection tool is used to collect the log data of the blockchain node; Detecting all the log data, and determining a target strategy from a preset strategy when detecting an abnormality in a target node among the blockchain nodes; Generate a configuration change transaction request according to the target policy; wherein the configuration change transaction request includes configuration information; Executing the configuration change transaction corresponding to the configuration change transaction request, so as to send the configuration information to the target node after the configuration change transaction is executed, and perform configuration changes on the consensus algorithm of the target node using the configuration information; Before determining the target strategy from the preset strategies, the method further includes: Configuring the preset policy in a configuration management system; The preset strategies include at least the following strategies: If the blockchain node does not generate a new block within a first preset time period, executing a first strategy; wherein the first strategy includes calculating network latency to reduce the block size when the network latency is greater than a first preset threshold, and / or adjusting a timeout for attempted changes based on a log check of view change status; If the number of interruption logs between any two blockchain nodes exceeds a second preset threshold, a node connection strategy is executed; wherein the node connection strategy includes at least one of controlling the blockchain node to communicate only with a preset node, adjusting the node weight of the blockchain node, adjusting the election strategy, replacing the master node, and activating a backup node; wherein the preset node is a node that has stable communication with any blockchain node, and the election strategy includes an election strategy for a leader or a validator among the blockchain nodes; If no transaction is uploaded to the chain within the second preset time, the master node will be replaced.
2. The method according to claim 1, characterized in that Executing the configuration change transaction corresponding to the configuration change transaction request includes: Obtaining the verification transaction signature of the target client corresponding to the configuration change transaction request; Broadcasting the signed configuration change transaction to all participants so that they can reach a consensus on the configuration change transaction; Execute the configuration change transaction after consensus, and broadcast transaction confirmation information to the participants, so that each participant records based on the transaction confirmation information; wherein the transaction confirmation information at least includes transaction execution results and status update information.
3. The method according to claim 2, characterized in that The signed configuration change transaction is broadcast to all participants so that they can reach a consensus on the configuration change transaction, including: Broadcast the signed configuration change transaction to all participants; Obtaining target verification results of the configuration change transaction by each participant; If the target verification result indicates that all the participants have reached a consensus, the step of executing the configuration change transaction after the consensus is reached will be continued.
4. The method according to claim 1, wherein All of the log data is tested, including: The log server obtains the target log data of each of the blockchain nodes from the target log collection tool, and uses all the target log data as the log data; The log processing module obtains the log data from the log server and detects the log data.
5. The method according to claim 1, wherein After obtaining the log data of the blockchain node, the method further includes: Based on the target log collection tool, each blockchain node is monitored in real time and a consensus algorithm performance report is generated; wherein the consensus algorithm performance report includes at least the processing time, latency, and resource utilization of each blockchain node; Analyze the consensus algorithm performance of each of the blockchain nodes according to the consensus algorithm performance report to obtain analysis results.
6. The method according to claim 1, characterized in that The method further comprises: Based on the target log collection tool, the consensus algorithm configuration change process of each blockchain node is recorded respectively.
7. A consensus algorithm configuration change device based on log observation, characterized in that: The device comprises: An acquisition module, configured to acquire log data of a blockchain node; wherein the blockchain node is configured with a target log collection tool, and the target log collection tool is configured to collect log data of the blockchain node; A detection module is configured to detect all of the log data and, upon detecting an abnormality in a target node among the blockchain nodes, determine a target strategy from a preset strategy; wherein, before determining the target strategy from the preset strategy, the detection module is further configured to: configure the preset strategy in a configuration management system; wherein the preset strategy includes at least the following strategies: if the blockchain node does not generate a new block within a first preset time period, executing a first strategy; wherein the first strategy includes statistically analyzing network latency to reduce the block size when the network latency is greater than a first preset threshold, and / or adjusting a timeout for attempted changes based on a log check view change state; if the number of interruption logs between any two blockchain nodes exceeds a second preset threshold, executing a node connection strategy; wherein the node connection strategy includes at least one of controlling the blockchain node to communicate only with a preset node, adjusting the node weight of the blockchain node, adjusting the election strategy, replacing the master node, and activating a backup node; wherein the preset node is a node that has stable communication with any blockchain node, and the election strategy includes an election strategy for a leader or validator among the blockchain nodes; and if no transaction is uploaded to the chain for more than a second preset time period, replacing the master node. a transaction request generating module, configured to generate a configuration change transaction request according to the target policy; wherein the configuration change transaction request includes configuration information; An execution module is used to execute the configuration change transaction corresponding to the configuration change transaction request, so as to send the configuration information to the target node after the configuration change transaction is executed, and to change the configuration of the consensus algorithm of the target node through the configuration information.
8. An electronic device, characterized in that: It includes a processor, a communication interface, a memory and a communication bus, wherein the processor, the communication interface and the memory communicate with each other via the communication bus; Memory for storing computer programs; The processor is configured to implement the steps of the method for changing the consensus algorithm configuration based on log observation according to any one of claims 1 to 6 when executing the program stored in the memory.
9. A computer-readable storage medium having a computer program stored thereon, characterized in that: When the computer program is executed by a processor, the steps of the method for changing the consensus algorithm configuration based on log observation are implemented.
Citation Information
Patent Citations
Algorithm change method and device, computer equipment and storage medium
CN115328509A
Methods and systems for modifying blockchain network configuration
US20210250169A1