Consensus processing method and device of block chain system, readable medium and equipment

Abstract

The embodiment of the invention provides a consensus processing method and device of a block chain system, a readable medium and equipment. The consensus processing method of the block chain system comprises the following steps: acquiring operation data generated by a consensus node in the block chain system during operation; searching a pointer address of a target function from the operation data, wherein the target function is a function in a consensus algorithm adopted by the consensus node; and modifying a pointer address of the target function into a pointer address of a set function in a memory of the consensus node, so that the consensus node calls the set function to perform consensus processing. According to the technical scheme provided by the embodiment of the invention, the modification of the target function in the consensus algorithm can be realized on the premise of not depending on the source code of the consensus node, so that the convenience and flexibility of testing the consensus algorithm of the block chain system can be improved.

Description

Technical Field

[0001] The present application relates to the field of computer and communication technology, and more specifically, to a consensus processing method, apparatus, readable medium and device for a blockchain system. Background Art

[0002] In blockchain technology, the consensus mechanism is the basis for ensuring the normal operation of the blockchain system. The so-called consensus means reaching an agreement. Each node device in the blockchain system stores a distributed ledger (i.e., blockchain). The consensus process of the blockchain system is the process of keeping the distributed ledgers between each node device consistent. When testing the consensus process of the blockchain system, it is usually necessary to replace the functions used in the consensus algorithm to simulate the processing process after the consensus algorithm is modified. However, related technologies often require obtaining the source code of the consensus node, which has great limitations and cannot process the source code that is not open source. Summary of the invention

[0003] The embodiments of the present application provide a consensus processing method, apparatus, readable medium and device for a blockchain system, which can modify the objective function in the consensus algorithm without relying on the source code of the consensus node, thereby improving the convenience and flexibility of testing the consensus algorithm of the blockchain system.

[0004] Other features and advantages of the present application will become apparent from the following detailed description, or may be learned in part by the practice of the present application.

[0005] According to one aspect of an embodiment of the present application, a consensus processing method for a blockchain system is provided, comprising: obtaining operation data generated by a consensus node in the blockchain system during operation; searching for a pointer address of a target function from the operation data, wherein the target function is a function in a consensus algorithm adopted by the consensus node; and modifying the pointer address of the target function in the memory of the consensus node to a pointer address of a setting function, so that the consensus node calls the setting function for consensus processing.

[0006] According to one aspect of an embodiment of the present application, a consensus processing method for a blockchain system is provided, comprising: obtaining a binary file obtained by compiling a consensus algorithm by a consensus node in the blockchain system; decompiling the binary file to obtain decompiled data; searching for a pointer address of a target function from the decompiled data, wherein the target function is a function in the consensus algorithm adopted by the consensus node; if the consensus node starts a consensus processing process, then modifying the pointer address of the target function to a pointer address of a setting function in the memory of the consensus node, so that the consensus node calls the setting function for consensus processing.

[0007] According to one aspect of an embodiment of the present application, a consensus processing device of a blockchain system is provided, comprising: an acquisition unit, configured to acquire operation data generated by a consensus node in the blockchain system during operation; a search unit, configured to search for a pointer address of a target function from the operation data, wherein the target function is a function in a consensus algorithm adopted by the consensus node; and a processing unit, configured to modify the pointer address of the target function to a pointer address of a setting function in the memory of the consensus node, so that the consensus node calls the setting function for consensus processing.

[0008] In some embodiments of the present application, based on the aforementioned scheme, the search unit is configured to: search for the function structure of the target function according to the function structure information list contained in the running data; and search for the pointer address of the target function based on the function structure of the target function.

[0009] In some embodiments of the present application, based on the aforementioned scheme, the search unit is configured to: parse the function structure of each function contained in the function structure information list to obtain the first position offset contained in the function structure of each function, wherein the first position offset is used to represent the offset of the function information; search for the function information of each function in the running data according to the first position offset contained in the function structure of each function; locate the function structure of the target function in the function structure information list according to the function information of each function and the name of the target function.

[0010] In some embodiments of the present application, based on the aforementioned scheme, the search unit is configured to: search for the pointer address of the target function in the running data according to a second position offset contained in the function structure of the target function, and the second position offset is used to represent the offset of the function address.

[0011] In some embodiments of the present application, based on the aforementioned scheme, the acquisition unit is further configured to: when it is necessary to test the consensus process of the blockchain system, obtain a function that requires modification of the consensus algorithm adopted by the consensus node, and use the obtained function that requires modification of the consensus algorithm adopted by the consensus node as the setting function.

[0012] In some embodiments of the present application, based on the aforementioned scheme, the acquisition unit is further configured to: after modifying the pointer address of the target function to the pointer address of the set function in the memory of the consensus node, obtain the voting result of the consensus node for the proposal block; the processing unit is further configured to: compare the voting result of the consensus node for the proposal block with the expected voting result to determine the test effect of the consensus process of the blockchain system.

[0013] In some embodiments of the present application, based on the aforementioned scheme, the acquisition unit is further configured to: after modifying the pointer address of the target function to the pointer address of the set function in the memory of the consensus node, obtain the consensus result of the proposal block initiated by the consensus node; the processing unit is further configured to: compare the consensus result with the expected consensus result to determine the test effect of the consensus process of the blockchain system.

[0014] In some embodiments of the present application, based on the aforementioned scheme, the acquisition unit is configured to: when the consensus node in the blockchain system is in operation, obtain the data recorded by the specified application for recording runtime information, and use the data recorded by the specified application as the operation data.

[0015] According to one aspect of an embodiment of the present application, a consensus processing device of a blockchain system is provided, comprising: an acquisition unit, configured to acquire a binary file obtained by compiling a consensus algorithm by a consensus node in the blockchain system; a decompilation unit, configured to decompile the binary file to obtain decompiled data; a search unit, configured to search for a pointer address of a target function from the decompiled data, wherein the target function is a function in the consensus algorithm adopted by the consensus node; and a processing unit, configured to modify the pointer address of the target function to a pointer address of a setting function in the memory of the consensus node if the consensus node starts a consensus processing process, so that the consensus node calls the setting function for consensus processing.

[0016] In some embodiments of the present application, based on the aforementioned scheme, the search unit is configured to: search for the function structure of the target function according to the function structure information list contained in the decompiled data; and search for the pointer address of the target function based on the function structure of the target function.

[0017] According to one aspect of an embodiment of the present application, a computer-readable medium is provided, on which a computer program is stored. When the computer program is executed by a processor, the consensus processing method of the blockchain system as described in the above embodiment is implemented.

[0018] According to one aspect of an embodiment of the present application, an electronic device is provided, comprising: one or more processors; a storage device for storing one or more computer programs, wherein when the one or more computer programs are executed by the one or more processors, the electronic device implements the consensus processing method of the blockchain system as described in the above embodiment.

[0019] According to one aspect of an embodiment of the present application, a computer program product is provided, the computer program product comprising a computer program, the computer program being stored in a computer-readable storage medium. A processor of an electronic device reads and executes the computer program from the computer-readable storage medium, so that the electronic device executes the consensus processing method of the blockchain system provided in the above-mentioned various optional embodiments.

[0020] In the technical solutions provided in some embodiments of the present application, the operating data generated by the consensus node in the blockchain system during operation is obtained, and the pointer address of the target function in the consensus algorithm is found from the operating data. Then, the pointer address of the target function is modified to the pointer address of the setting function in the memory of the consensus node, so that the consensus node calls the setting function for consensus processing. When the target function in the consensus algorithm is modified, it can be processed based on the operating data generated by the consensus node during operation without relying on the source code of the consensus node, thereby improving the convenience and flexibility of testing the consensus algorithm of the blockchain system.

[0021] In the technical solutions provided in some embodiments of the present application, a binary file is obtained by obtaining a consensus node in a blockchain system to compile a consensus algorithm, and the binary file is decompiled to obtain decompiled data. Then, the pointer address of a target function in the consensus algorithm is searched from the decompiled data. When the consensus node starts a consensus processing process, the pointer address of the target function is modified to the pointer address of a setting function in the memory of the consensus node, so that the consensus node calls the setting function for consensus processing. When the target function in the consensus algorithm is modified, it can be processed based on the binary file obtained by compiling the consensus algorithm by the consensus node, without relying on the source code of the consensus node, thereby improving the convenience and flexibility of testing the consensus algorithm of the blockchain system.

[0022] It should be understood that the foregoing general description and the following detailed description are exemplary and explanatory only and are not restrictive of the present application. BRIEF DESCRIPTION OF THE DRAWINGS

[0023] Figure 1 A schematic diagram of the structure of a blockchain network is shown;

[0024] Figure 2 A schematic diagram showing the connection relationship between blocks in the blockchain;

[0025] Figure 3 A schematic diagram of the process of the BFT consensus algorithm is shown;

[0026] Figure 4 A schematic diagram showing a consensus node broadcasting a block according to an embodiment of the present application is shown;

[0027] Figure 5 A schematic diagram showing the processing process of each consensus stage of the BFT consensus algorithm is shown;

[0028] Figure 6 A schematic diagram of the consensus process in a blockchain system is shown;

[0029] Figure 7 A schematic diagram of the consensus process when the master node in the blockchain system acts maliciously is shown;

[0030] Figure 8 A schematic diagram of the consensus process when a slave node in a blockchain system acts maliciously is shown;

[0031] Fig. 9 A schematic diagram of testing the consensus process of a blockchain system is shown;

[0032] Fig.10 A schematic diagram of testing the consensus process of a blockchain system is shown;

[0033] Fig.11 A flowchart showing a consensus processing method of a blockchain system according to an embodiment of the present application is shown;

[0034] Fig.12 A flowchart showing a consensus processing method of a blockchain system according to an embodiment of the present application is shown;

[0035] Fig.13 A flowchart showing a target function in a modified consensus algorithm according to an embodiment of the present application is shown;

[0036] Fig.14 A flowchart of extracting a pointer address of a target function according to an embodiment of the present application is shown;

[0037] Fig.15 A block diagram of a consensus processing device of a blockchain system according to an embodiment of the present application is shown;

[0038] Fig.16 A block diagram of a consensus processing device of a blockchain system according to an embodiment of the present application is shown;

[0039] Fig.17 A schematic diagram of the structure of a computer system suitable for implementing an electronic device of an embodiment of the present application is shown. DETAILED DESCRIPTION

[0040] The exemplary embodiments are now described in a more comprehensive manner with reference to the accompanying drawings. However, the exemplary embodiments can be implemented in various forms and should not be understood as being limited to these examples; on the contrary, the purpose of providing these embodiments is to make this application more comprehensive and complete, and to fully convey the concept of the exemplary embodiments to those skilled in the art.

[0041] In addition, the features, structures or characteristics described in the present application may be combined in one or more embodiments in any suitable manner. In the following description, there are many specific details so that the embodiments of the present application can be fully understood. However, those skilled in the art will appreciate that when implementing the technical scheme of the present application, all the detailed features in the embodiments may not be needed, one or more specific details may be omitted, or other methods, elements, devices, steps, etc. may be adopted.

[0042] The block diagrams shown in the accompanying drawings are merely functional entities and do not necessarily correspond to physically independent entities. That is, these functional entities may be implemented in software form, or in one or more hardware modules or integrated circuits, or in different networks and / or processor devices and / or microcontroller devices.

[0043] The flowcharts shown in the accompanying drawings are only exemplary and do not necessarily include all the contents and operations / steps, nor must they be executed in the order described. For example, some operations / steps can be decomposed, and some operations / steps can be combined or partially combined, so the actual execution order may change according to actual conditions.

[0044] It should be noted that the "multiple" mentioned in this article refers to two or more. "And / or" describes the association relationship of the associated objects, indicating that there can be three relationships. For example, A and / or B can mean: A exists alone, A and B exist at the same time, and B exists alone. The character " / " generally indicates that the associated objects before and after are in an "or" relationship.

[0045] It is understandable that this application can display a prompt interface or pop-up window before collecting relevant data (such as the operating data generated by the consensus node during operation, the binary file obtained by compiling and processing the consensus algorithm, and other data) and during the process of collecting relevant data. The prompt interface or pop-up window is used to prompt the user that relevant data is currently being collected, so that this application only starts to execute the relevant steps of obtaining relevant data after obtaining the user's confirmation operation on the prompt interface or pop-up window, otherwise (that is, when the user's confirmation operation on the prompt interface or pop-up window is not obtained), the step of obtaining relevant data is terminated, that is, the relevant data is not obtained. In other words, all data collected by this application are collected with the user's consent and authorization, and the collection, use and processing of relevant data need to comply with the relevant laws, regulations and standards of relevant countries and regions.

[0046] The technical solution of the embodiment of the present application involves blockchain technology. Specifically, blockchain is a new application mode of computer technologies such as distributed data storage, point-to-point transmission, consensus mechanism, encryption algorithm, etc. Blockchain is essentially a decentralized database, a string of data blocks (i.e., 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, the platform product service layer, and the application service layer.

[0047] The underlying blockchain platform can include processing modules such as user management, basic services, smart contracts, and operation management. Among them, the user management module is responsible for the identity information management of all blockchain participants, including maintaining the generation of public and private keys (account management), key management, and the maintenance of the corresponding relationship between user information and blockchain addresses (authority management). The basic service module is deployed on all blockchain node devices to verify the validity of business requests and record the valid requests to the 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). After encryption, it is completely and consistently transmitted to the shared ledger (network communication) and recorded and stored. 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 certain programming language and publish it to the blockchain (contract registration). According to the logic of the contract terms, the key or other event triggers the execution to complete the contract logic. At the same time, it also provides the function of contract upgrade and cancellation. The operation management 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 device health status detection, etc.

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

[0049] As mentioned above, blockchain is essentially a decentralized database, and the blockchain is maintained by the nodes in the blockchain network. Figure 1 The blockchain network shown may include multiple nodes 101, and the multiple nodes 101 may be the various clients forming the blockchain network. Each node 101 may receive input information during normal operation, and maintain the shared data in the blockchain network based on the received input information. In order to ensure the information intercommunication within the blockchain network, there may be an information connection between each node in the blockchain network, and information may be transmitted between nodes through the above information connection. For example, when any node in the blockchain network receives input information, other nodes in the blockchain network obtain the input information according to the consensus algorithm, and store the input information as shared data, so that the data stored on all nodes in the blockchain network are consistent.

[0050] Each node in the blockchain network has a corresponding node identifier, and each node in the blockchain network can store the node identifiers of other nodes, so that the generated blocks can be broadcast to other nodes in the blockchain network according to the node identifiers of other nodes. A node identifier list can be maintained in each node, and the node name and node identifier are stored in the node identifier list accordingly. The node identifier can be an IP (Internet Protocol, a protocol for interconnecting networks) address or any other information that can be used to identify the node.

[0051] Each node in the blockchain network stores the same blockchain. The blockchain consists of multiple blocks, see Figure 2 As shown in the figure, the blockchain consists of multiple blocks, which are connected into a chain structure in the order of creation timestamp from small to large. Each block includes a block header and a block body. The block header stores the hash of the previous block and the Merkle root of this block. The block body contains the complete transaction data of this block and is organized in the form of a Merkle tree. From the structure of the blockchain, it can be seen that the block data stored in each block in the blockchain is associated with the block data stored in the parent block (i.e., the previous block), which ensures the security of the information input in the block.

[0052] Each node in the blockchain network can be a server or a terminal device. The server can be an independent physical server, a server cluster or a distributed system composed of multiple physical servers, or a cloud server that provides basic cloud computing services such as cloud services, cloud databases, cloud computing, cloud functions, cloud storage, network services, cloud communications, middleware services, domain name services, security services, CDN (Content Delivery Network), and big data and artificial intelligence platforms. The terminal device can be a smart phone, tablet computer, laptop computer, desktop computer, smart speaker, smart watch, smart home, vehicle terminal, aircraft, etc., but is not limited to this. Each node can be directly or indirectly connected by wired or wireless communication, and this application is not limited here.

[0053] It should be noted that the Merkle tree is an important part of blockchain technology. The blockchain will not directly save the original data in plain text. The original data needs to be hashed and stored in the form of hash values. The Merkle tree is used to organize the hash values ​​formed by hashing multiple original data according to the binary tree structure and save them in the block body.

[0054] There is another key technology in blockchain technology, namely the consensus mechanism, which is the basis for ensuring the normal operation of the blockchain system. The so-called consensus means reaching an agreement. Each node device in the blockchain system stores a distributed ledger (i.e., blockchain). The consensus process of the blockchain system is the process of keeping the distributed ledgers between each node device consistent. Among them, all or part of the node devices in the blockchain system can participate in the consensus process of the blockchain system. The consensus process of the blockchain system is usually based on the consensus algorithm. Each node device participating in the consensus executes the corresponding process of the consensus process by running the consensus algorithm. Optional consensus algorithms include PoW (Proof of Work), PoS (Proof of Stake), DPoS (Delegated Proof of Stake), BFT (Byzantine Fault Tolerance), PBFT (Practical Byzantine Fault Tolerance), etc.

[0055] Usually, one or more rounds of consensus process are required at a certain block height in the blockchain to reach a consensus among the various node devices participating in the consensus. The block height is used to indicate the number of blocks connected to the blockchain. The block height is the identifier of the block, which can be used to indicate the position of the block in the blockchain. For example, the block height of the genesis block in the blockchain defaults to 0, the block height of the first block after the genesis block is 1 (the first block can be referred to as block 1), the block height of the second block after the genesis block is 2 (the second block can be referred to as block 2), and so on.

[0056] For example, the block height of the current block of a blockchain is 300 (referred to as block 300), which means that 300 blocks have been stacked on the genesis block, that is, the number of blocks on the blockchain formed from the genesis block to block 300 is 301. The consensus process at a certain block height of the blockchain refers to the process of consensus on the blocks to be chained in the blockchain system when the blockchain is at a certain block height. If the consensus on the block to be chained is successful, the block is added to the blockchain, and the block height of the blockchain is +1. For example: the consensus process at the block height of the blockchain is 10. It means the process of consensus on the blocks to be chained in the blockchain system when the blockchain is at the block height of 10. If the consensus on the block is successful, the block is added to the blockchain, and the block height of the blockchain changes from 10 to 11.

[0057] Generally speaking, Figure 3 As shown in the figure, a round of consensus process can be divided into three consensus stages according to the execution order, namely the proposal stage, the prevote stage and the precommit stage. The multiple node devices participating in the same round of consensus process include two types: proposal nodes and non-proposal nodes. The so-called proposal node refers to a node device generated by multiple node devices participating in the consensus through election. As a proposal node, the node device is responsible for generating the block to be agreed upon according to the request in the proposal stage of this round of consensus process, and broadcasting the block to be agreed upon to other node devices participating in the consensus for consensus processing; it is also responsible for consensus processing of the block to be agreed upon. Non-proposal nodes only perform consensus processing on the block to be agreed upon.

[0058] Consensus processing includes pre-voting and pre-submitting. Pre-voting occurs in the pre-voting phase (prevote phase), while pre-submitting occurs in the pre-submitting phase (precommit phase). Pre-voting refers to the process of whether to agree to pre-vote on the block to be agreed upon. If you agree to pre-vote on the block to be agreed upon, it means that you agree to add the block to the blockchain. Pre-submitting refers to the process of whether to agree to pre-submit the block to be agreed upon. If you agree to pre-submit the block to be agreed upon, it means that you confirm that you agree to add the block to the blockchain. In the process of multiple rounds of consensus at the same block height, the node devices participating in the consensus may change for different rounds of consensus, that is, the node devices participating in each round of the consensus process may change, and the proposal node may change, and the block to be agreed upon may also change.

[0059] The following is a detailed description of the specific process of the Ni-th round of consensus process of the blockchain block height H in the embodiment of the present application using a specific example, where H, N, and i are all positive integers, and i is less than N. Taking i=1 as an example, in the N-1th round of consensus process of the blockchain block height H, there are 4 node devices participating in the consensus process. Figure 4 A block broadcasting schematic diagram of a consensus node according to an embodiment of the present application is shown; Figure 4 As shown in the figure, the node devices participating in the consensus process in the blockchain system are node device A, node device B, node device C and node device D. In the N-1th round of consensus process of the block height H of the blockchain, node device B is the proposal node, and node devices A, node devices C and node devices D are non-proposal nodes. Figure 5 As shown in the figure, the specific process of the N-1th round of consensus at the block height H of the blockchain includes:

[0060] 1. Proposal stage:

[0061] First, node device B (i.e., the proposal node) generates a target block Block-X to be agreed upon, which can be a new block created by node device B. Then, node device B generates a proposal message (proposal) for the target block Block-X, and then broadcasts it to node devices A, C, and D.

[0062] 2. Pre-voting stage:

[0063] Due to network failure, equipment failure or other reasons, some node devices may not be able to receive Block-X broadcast by node device B in the first time. For example, if node device A does not receive Block-X broadcast by node device B in the first time, node device C and node device D both receive Block-X broadcast by node device B in the first time; then in the pre-voting stage, node device B, node device C and node device D all take Block-X as the target block to be agreed upon, and pre-vote Block-X to obtain their respective pre-voting messages. The pre-voting message here contains the block identifier to be pre-voted. For example, node device C pre-votes Block-X to generate a pre-voting message of node device C. The pre-voting message of node device C includes the identifier of Block-X, and the pre-voting message indicates that node device C agrees to pre-vote Block-X, that is, agrees to add Block-X to the blockchain, and Block-X obtains the pre-vote of node device C.

[0064] It is understandable that if node device C does not generate a pre-voting message for node device C, it means that node device C has not pre-voted Block-X; if the pre-voting message for node device C does not include the identifier of Block-X, it means that node device C does not agree to pre-vote for Block-X, that is, it does not agree to add Block-X to the blockchain. Since node device A did not receive Block-X in the first time, it can determine the empty block emptyBlock as the target block to be agreed upon, and pre-vote emptyBlock to obtain the pre-voting message of node device A, and the pre-voting message of node device A includes the identifier of emptyBlock. The first time can be set according to actual needs, such as 1 minute, 3 minutes, etc.

[0065] Node device A, node device B, node device C and node device D each broadcast their own pre-voting message. Due to network failure, device failure or other reasons, some node devices may not receive the pre-voting message broadcast by other node devices within the second time. Therefore, when the second time arrives, each node device participating in the consensus process will count the number of pre-votes obtained by the target block to be agreed upon in the pre-voting stage according to the pre-voting message received within the second time, and confirm whether the number of pre-votes exceeds the quantity threshold. The quantity threshold here can be set according to actual conditions. For example, the quantity threshold can be 50% of the number of node devices participating in the consensus process, or 2 / 3 (or 2 / 3+1) of the number of node devices participating in the consensus process. The second time here can also be set according to actual needs, such as 1 minute, 3 minutes, etc.; the second time can be the same as the first time, or different from the first time.

[0066] For example: suppose the quantity threshold is 2. Since node device A only performs pre-voting on emptyBlock, the pre-voting message of node device A includes the identifier of emptyBlock; while node devices B, C and D all perform pre-voting on Block-X, and the pre-voting messages of node devices B, C and D all include the identifier of Block-X; at the same time, suppose node device A only receives the pre-voting message from node device B, and the number of pre-votes obtained by Block-X in the pre-voting stage is 1 in combination with the statistics of node device A's own pre-voting message, confirming that the number of pre-votes obtained by Block-X does not exceed the quantity threshold of 2. Suppose node device B receives three pre-voting messages from node devices A, C and D, and the number of pre-votes obtained by Block-X is 3 in combination with the statistics of node device B's own pre-voting message, confirming that the number of pre-votes obtained by Block-X exceeds the quantity threshold of 2. Similarly, suppose that node device C receives three pre-voting messages from node device A, node device B, and node device D, and then combines node device C's own pre-voting message to obtain a number of pre-votes obtained by Block-X of 3, confirming that the number of pre-votes obtained by Block-X exceeds the threshold of 2. Suppose that node device D also receives three pre-voting messages from node device A, node device B, and node device C, and then combines node device D's own pre-voting message to obtain a number of pre-votes obtained by Block-X of 3, confirming that the number of pre-votes obtained by Block-X exceeds the threshold of 2.

[0067] 3. Pre-submission stage:

[0068] Node device B, node device C and node device D all determine Block-X as the target block to be agreed upon, so they all pre-submit Block-X to obtain their own pre-submit voting messages; the pre-submit voting message here contains the block identifier of the pre-submitted block. For example: Node device C pre-submits Block-X to generate a pre-submit voting message of node device C, which includes the identifier of Block-X, and the pre-submit voting message indicates that node device C agrees to pre-submit Block-X, which means that it confirms that it agrees to add Block-X to the blockchain, and Block-X obtains the pre-submission of node device C.

[0069] It is understandable that if node device C does not generate a pre-submission voting message of node device C, it means that node device C has not pre-submitted Block-X; if the pre-submission voting message of node device C does not include the identifier of Block-X, it means that node device C does not agree to pre-submit Block-X, that is, it does not agree to add Block-X to the blockchain. Since node device A determines the empty block emptyBlock as the target block to be agreed upon, node device A pre-submits emptyBlock to obtain the pre-submission voting message of node device A, and the pre-submission voting message of node device A includes the identifier of emptyBlock.

[0070] Node device A, node device B, node device C and node device D each broadcast their own pre-submission voting message. Due to network failure, device failure or other reasons, some node devices may not receive the pre-submission voting message broadcast by other node devices within the third time. When the third time arrives, each node device participating in the consensus process counts the number of pre-submissions obtained by the target block to be agreed upon in the pre-submission stage according to the pre-submission voting message received within the third time, and confirms whether the pre-submission number exceeds the submission threshold. The submission threshold here can be set according to actual conditions, for example, the submission threshold can be 50% of the number of node devices participating in the consensus process, or 2 / 3 (or 2 / 3+1) of the number of node devices participating in the consensus process. The third time here can also be set according to actual needs, for example, 1 minute, 3 minutes, etc.; the third time can be the same as the second time, or different from the second time; similarly, the third time can be the same as the first time, or different from the first time.

[0071] For example: suppose the commit threshold is 2. Since node device A only performs pre-commit processing on emptyBlock, the pre-commit voting message of node device A includes the identifier of emptyBlock; while node devices B, node devices C and node devices D all perform pre-commit processing on Block-X, and the pre-commit voting messages of node devices B, node devices C and node devices D all include the identifier of Block-X; at the same time, suppose node device B receives pre-commit voting messages from node devices A and node devices C, and combines the statistics of node device B's own pre-commit voting messages to obtain the number of pre-commits obtained by Block-X in the pre-commit stage to be 2, confirming that the number of pre-commits obtained by Block-X does not exceed (is not greater than) the commit threshold of 2. Suppose node device C receives pre-commit voting messages from node devices A and node devices C, and combines the statistics of node device C's own pre-commit voting messages to obtain the number of pre-commits obtained by Block-X to be 2, confirming that the number of pre-commits obtained by Block-X does not exceed (is not greater than) the commit threshold of 2. Similarly, suppose that node device A receives three pre-submission voting messages from node device B, node device C, and node device D, and then combines the statistics of node device A's own pre-submission voting message to obtain the pre-submission number of Block-X to be 3, confirming that the pre-submission number obtained by Block-X exceeds the submission threshold of 2. Suppose that node device D also receives three pre-submission voting messages from node device A, node device B, and node device C, and then combines the statistics of node device D's own pre-submission voting message to obtain the pre-submission number of Block-X to be 3, confirming that the pre-submission number obtained by Block-X exceeds the submission threshold of 2.

[0072] After the above three consensus stages, if the number of pre-votes obtained by the target block to be agreed upon exceeds the number threshold, and the number of pre-submissions obtained exceeds the submission threshold, then the consensus of the target block to be agreed upon is successful and can be added to the blockchain, that is, the submission (commit) process is executed; otherwise, the consensus fails and cannot be added to the blockchain. According to the above example, node device A confirms that the number of pre-submissions obtained by Block-X exceeds the submission threshold, but the number of pre-votes obtained does not exceed the number threshold, so it is determined that the consensus of Block-X has failed. Node device B confirms that the number of pre-votes obtained by Block-X exceeds the number threshold, but the number of pre-submissions obtained does not exceed the submission threshold, so it is determined that the consensus of Block-X has failed. Node device C confirms that the number of pre-votes obtained by Block-X exceeds the number threshold, but the number of pre-submissions obtained does not exceed the submission threshold, so it is determined that the consensus of Block-X has failed. Node device D confirms that the number of pre-votes obtained by Block-X exceeds the number threshold, and the number of pre-submissions obtained exceeds the submission threshold, so it is determined that the consensus of Block-X has failed. Node device D confirms that the number of pre-votes obtained by Block-X exceeds the number threshold, and the number of pre-submissions obtained exceeds the submission threshold, so it is determined that the consensus of Block-X has succeeded, and node device D adds Block-X to the blockchain stored locally by node device D.

[0073] To summarize, in the N-1th round of consensus when the block height of the blockchain is H, node device A, node device B and node device C did not reach a consensus on Block-X, and did not write Block-X into their respective distributed ledgers (i.e., added it to their respective locally stored blockchains), but node device D reached a consensus on Block-X and wrote Block-X into its own distributed ledger, then the block height of the blockchain stored locally by node device D becomes H+1; during the Nth round of consensus when the block height of the blockchain is H, node device D will no longer participate in the consensus, and the node devices participating in the consensus will be changed to node device A, node device B and node device C.

[0074] It should be noted that when the Nth round of consensus process is carried out at a block height of H on the blockchain, the proposal node may change. For example, in the above example, the proposal node in the N-1th round of consensus process at a block height of H on the blockchain is node device B, while in the Nth round of consensus process at a block height of H on the blockchain, it may be changed to node device C; then the above three consensus stages are re-executed to complete the Nth round of consensus process at a block height of H on the blockchain.

[0075] From the above consensus mechanism, we can see that each block needs to go through three stages: proposal, pre-voting, and pre-submission. Figure 6As shown, the consensus node usually has a master node at the same time. The master node is used to package transactions from the transaction pool to generate proposal blocks, and then initiate the consensus process of the proposal blocks, that is, to send the packaged proposal blocks to each slave node.

[0076] After receiving the proposal block sent by the master node, each slave node verifies each transaction in the proposal block. If the verification fails, it will vote against (false); if the verification succeeds, it will vote in favor (true). For a normal consensus slave node, if the master node is not malicious, then each transaction in the proposal block is legal, so the verification is naturally passed, so it should vote in favor. However, if the current slave node itself is a malicious node, it may vote against it at this time.

[0077] In the absence of malicious nodes, after the master node normally packages the proposal block generated by legal transactions and broadcasts it to the slave nodes, all slave nodes can verify the proposal block and every transaction within the proposal block, and all slave nodes will vote in favor, then the proposal block initiated by the master node has reached a consensus.

[0078] However, malicious nodes may appear in the blockchain system. Specifically, the node does not send the correct data that needs to be sent, but maliciously sends some wrong data. This behavior is a malicious behavior, and the node with this behavior is a malicious node. Usually, there are two types of malicious nodes, one is the master node, and the other is the slave node. If the master node is malicious, then the correct content in the proposal information that should have been sent is tampered with into incorrect content; if the slave node is malicious, then when sending the voting information, it casts the opposite vote that should have been cast.

[0079] Specifically, for the master node, under normal circumstances, the master node needs to package normal transactions from the transaction pool to generate proposals, then broadcast the proposals to other slave nodes, and then receive voting information from the slave nodes to determine whether consensus has been reached by judging whether the information of affirmative votes exceeds half. Figure 7 As shown in the figure, for malicious master nodes, the proposals they broadcast are often problematic, such as tampering with the content information of a transaction in the proposal. When the tampered proposal (i.e., wrong proposal) is sent to the slave nodes, the normal slave nodes will vote against it because the transaction verification fails, so the proposal will fail to reach consensus, that is, no consensus is reached. However, if there are malicious nodes among the slave nodes, and they still vote in favor of the proposal that failed verification in cooperation with the master node, then when the malicious master node receives more than half of the votes in favor, it will write the tampered proposal into the blockchain ledger, causing abnormal data in the blockchain ledger.

[0080] For a normal slave node, it needs to receive the proposal broadcast by the master node, then verify the proposal, and vote in favor if the verification passes, and vote against if the verification fails. Figure 8 As shown in the figure, when slave node 2 acts maliciously, it may vote against the proposal that has been verified. In this case, if the master node receives more than half of the votes against it, it will be considered that the consensus has failed, and the current proposal will be invalidated. If the master node itself is a malicious node, and the broadcasted proposal itself has been modified, then if a group of slave nodes that should have voted against it vote in favor of it because of their malicious behavior, the modified proposal will reach a consensus, and eventually cause abnormal data in the blockchain ledger.

[0081] Based on the above technical background, in the actual development process, it is usually necessary to test the consensus process of the blockchain system to verify the ability of the blockchain system to resist malicious nodes. There are generally two methods for testing the consensus process of the blockchain system. One method is as follows: Fig. 9 As shown in the figure, after obtaining the source code of the consensus node, the original function in the consensus algorithm is replaced with other functions by directly modifying the source code, thereby simulating the malicious behavior caused by the attack on the consensus algorithm. This solution not only requires the source code, but also requires a high level of operation authority over the consensus node. Another method is as follows Fig.10 As shown, based on the source code of the consensus node (specifically, the source code of the consensus algorithm adopted by the consensus node), the target function or method at runtime is replaced with a new function by stubbing, that is, the pointer address of the target function at runtime is obtained by reflection of the target function in the source code, and then the pointer address of the new function is obtained by reflection of the new function, and then the pointer address of the target function is replaced by the pointer address of the new function. However, this solution also requires complete source code to be implemented.

[0082] It can be seen that in Fig. 9 and Fig.10 The solutions shown both require a strong reliance on the source code of the consensus algorithm, which makes the two solutions limited. They can only be tested on some open source blockchain systems, but cannot be tested on closed source code.

[0083] Based on this, a new consensus processing scheme for a blockchain system is proposed in the embodiment of the present application, which can realize the modification of the objective function in the consensus algorithm without relying on the source code of the consensus node, thereby improving the convenience and flexibility of testing the consensus algorithm of the blockchain system.

[0084] The implementation details of the technical solution of the embodiment of the present application are described in detail below:

[0085] Fig.11 A flowchart of a consensus processing method of a blockchain system according to an embodiment of the present application is shown. The consensus processing method of the blockchain system can be executed by an electronic device, and the electronic device can serve as a consensus node in the blockchain system. Fig.11 As shown, the consensus processing method of the blockchain system includes at least steps S1110 to S1130, which are described in detail as follows:

[0086] In step S1110, the operation data generated by the consensus node in the blockchain system during operation is obtained.

[0087] In some optional embodiments, the consensus algorithm adopted by the consensus node usually adopts a compiled language, and the compiled language will store relevant function information during operation. The operation data in this application includes this function information, such as relevant information of the function structure, etc. When obtaining the operation data, the data recorded by the specified application for recording the runtime information can be obtained when the consensus node is in operation, and then the data recorded by the specified application is used as the operation data.

[0088] Optionally, the runtime information may be RTSI (Runtime Symbol Information) and RTTI (Runtime Type Information), etc. For consensus nodes using the Go language, the designated application for recording runtime information may be moduledata, which records the data generated by the consensus node during the consensus process.

[0089] In step S1120, the pointer address of the target function is found from the running data, and the target function is a function in the consensus algorithm adopted by the consensus node.

[0090] In some optional embodiments, when searching for the pointer address of the target function from the running data, the function structure of the target function can be searched according to the function structure information list contained in the running data, and then the pointer address of the target function can be searched based on the function structure of the target function. Optionally, the function structure information list records the function structure information of each consensus node at runtime, wherein the function structure contains various variables for defining the specific functions of the function.

[0091] In some optional embodiments, when searching for the function structure of the target function according to the function structure information list contained in the running data, the function structure of each function contained in the function structure information list can be parsed to obtain the first position offset contained in the function structure of each function, and the first position offset is used to represent the offset of the function information. Then, according to the first position offset contained in the function structure of each function, the function information of each function is searched in the running data, and then the function structure of the target function is located in the function structure information list according to the function information of each function and the name of the target function.

[0092] Optionally, the first position offset is used to represent the position offset of function information, and specific information of the function, such as the name of the function, can be found in the running data according to the first position offset. In a specific example, for a consensus node using the Go language, the first position offset may be funcoff, which is used to represent the offset starting from pclntab (Program Counter Line Table, which may also be referred to as RTSI in the above embodiment in the Go language).

[0093] In some optional embodiments, the process of searching for the pointer address of the target function based on the function structure of the target function may be to search for the pointer address of the target function in the running data according to the second position offset contained in the function structure of the target function, and the second position offset is used to represent the offset of the function address. In a specific example, for a consensus node using the Go language, the first position offset may be entryoff, which is used to represent the offset starting from the code segment, that is, the actual pointer position of the function.

[0094] In step S1130, the pointer address of the target function is modified to the pointer address of the setting function in the memory of the consensus node, so that the consensus node calls the setting function for consensus processing.

[0095] In some optional embodiments, the setting function is a function that needs to replace the target function in the consensus algorithm. The original consensus logic in the consensus algorithm can be changed through the setting function, so that the node's malicious behavior can be simulated. Specifically, when the consensus process of the blockchain system needs to be tested, the function that needs to modify the consensus algorithm used by the consensus node can be obtained, and then the obtained function that needs to modify the consensus algorithm used by the consensus node is used as the setting function, thereby realizing the test process of the consensus node.

[0096] In some optional embodiments, if the consensus node is a slave node, that is, the pointer address of the target function is modified to the pointer address of the setting function in the memory of the slave node, then the voting result of the slave node for the proposal block can be obtained, and then the voting result of the consensus node for the proposal block is compared with the expected voting result to determine the test effect of the consensus process of the blockchain system. For example, under normal circumstances, the slave node votes in favor of the proposal block according to the consensus algorithm, and the approval vote is the expected voting result. However, by modifying the pointer address of the target function in the memory of the slave node to the pointer address of the setting function, the slave node may vote against the proposal block. Then, the actual voting result of the slave node can be compared with the expected voting result to determine the test effect of the consensus process, that is, whether the malicious behavior of the slave node is simulated.

[0097] In some optional embodiments, if the consensus node is a master node, that is, the pointer address of the target function is modified to the pointer address of the setting function in the memory of the master node, then the consensus result of the proposal block initiated by the master node can be obtained, and then the consensus result is compared with the expected consensus result to determine the test effect of the consensus process of the blockchain system. For example, under normal circumstances, the master node generates a proposal block by packaging normal transactions from the transaction pool and then broadcasts it to the slave node. If the pointer address of the target function is modified to the pointer address of the setting function in the memory of the master node, the master node may modify the transaction content in the proposal block to obtain an erroneous proposal. In this case, after verifying the proposal block, the slave node will cast a negative vote, which will cause the consensus of the proposal block to fail. Then, the actual consensus result of the proposal block can be compared with the expected consensus result to determine the test effect of the consensus process, that is, whether the malicious behavior of the master node is simulated.

[0098] In some optional embodiments, the pointer address of the target function can also be modified to the pointer address of the set function in the memory of the master node and the slave node at the same time, so as to simulate the behavior of the master node and the slave node doing evil together, so as to facilitate the testing of the consensus process of the blockchain system.

[0099] Fig.12 A flowchart of a consensus processing method of a blockchain system according to an embodiment of the present application is shown. The consensus processing method of the blockchain system can be executed by an electronic device, and the electronic device can serve as a consensus node in the blockchain system. Fig.12 As shown, the consensus processing method of the blockchain system includes at least steps S1210 to S1240, which are described in detail as follows:

[0100] In step S1210, a binary file obtained by compiling the consensus algorithm by the consensus node in the blockchain system is obtained.

[0101] In some optional embodiments, if the consensus node has not yet completed the consensus process, it cannot be Fig.11 The technical solution of the illustrated embodiment obtains the running data, and then the binary file compiled by the consensus algorithm can be obtained. The binary file may be, for example, the RTSI and RTTI in the aforementioned embodiment, which contains the initial data before the application is run (ie, before the consensus algorithm is executed).

[0102] In step S1220, the binary file is decompiled to obtain decompiled data.

[0103] Optionally, decompiling is to convert the executable program code (i.e., binary file) into some form of high-level programming language to make it more readable. Decompiling is a kind of reverse engineering, which has the opposite effect of compiling. In actual processing, the decompiling of binary files can be achieved through a decompiler.

[0104] In step S1230, the pointer address of the target function is found from the decompiled data, where the target function is a function in the consensus algorithm adopted by the consensus node.

[0105] In some optional embodiments, when searching for the pointer address of the target function from the decompiled data, the function structure of the target function can be searched according to the function structure information list contained in the decompiled data, and then the pointer address of the target function can be searched based on the function structure of the target function. Optionally, the function structure information list records the function structure information of each consensus node at runtime, wherein the function structure contains various variables for defining the specific functions of the function.

[0106] In some optional embodiments, the process of searching for the function structure of the target function according to the function structure information list, and the process of searching for the pointer address of the target function based on the function structure of the target function can refer to the technical solutions of the aforementioned embodiments and will not be repeated here.

[0107] In step S1240, if the consensus node starts the consensus processing, the pointer address of the target function is modified to the pointer address of the setting function in the memory of the consensus node, so that the consensus node calls the setting function for consensus processing.

[0108] In some optional embodiments, after finding the pointer address of the target function, if the consensus node starts the consensus processing process, the information of the target function is loaded into the memory of the consensus node. In this case, the pointer address of the target function can be modified to the pointer address of the set function in the memory of the consensus node, thereby implementing the test processing of the consensus process of the consensus node. The specific test process can refer to the technical solution of the aforementioned embodiment and will not be repeated here.

[0109] It can be seen that in the technical solution of the above-mentioned embodiment of the present application, the modification of the objective function in the consensus algorithm can be achieved without relying on the source code of the consensus node, thereby improving the convenience and flexibility of testing the consensus algorithm of the blockchain system.

[0110] The following uses the Go language as an example to describe the implementation details of the technical solution of the embodiment of the present application:

[0111] In one embodiment of the present application, during the compilation process, the compiled language usually compiles the functions, variables and other information in the source code onto a specified stack, and then introduces the pointer address to indicate that some related functions belong to a certain structure or class, and during compilation, the same processing is also performed on the parameters passed in by some structure methods. For the Go language, the method of the structure is mounted on the structure by means of a pointer, which is essentially the introduction of a pointer. For a blockchain system that uses the Go language as the programming language at the bottom, the source code will be compiled into a binary file before running, and then the compiled binary file can be run on the node to implement the consensus processing process. When the consensus process needs to be tested, the introduction pointer of the function structure to a certain method can be replaced with a redefined new function pointer to complete the replacement of the original structure function.

[0112] Specific as Fig.13As shown in the figure, the function relationship in the structure method is related to each other by introducing the pointer address after compilation. For example, the structure Person is related by introducing the pointer address of the Say() function in the structure method. When the method Persopn.Say() is called, the Say() method itself is found through the introduced pointer address (i.e. 0x101), and then the Say() method is executed. If you need to modify the target function in the consensus algorithm, you can modify the pointer address of the original introduced Say() function to the pointer address of the new Attack() function (i.e. 0x102) by modifying the pointer address after finding the pointer address of the target function. Then, when the original process calls the method Persopn.Say(), the pointer address found is actually the address of Attack() (i.e. 0x102). In this way, the modification of the Say() function is completed, and the malicious behavior of the consensus node can be simulated through the modified function.

[0113] If the source code of the consensus node can be obtained, it is very convenient to use the reflection mechanism provided by the Go language in conjunction with the unsafe package to obtain the pointer address of the target function, but in most cases, it is impossible to obtain the source code of the consensus node. Therefore, in the embodiment of the present application, the pointer address of the target function can be found by retrograde analysis of the runtime data. Specifically, if a runtime error occurs during runtime in the compiled language itself, it will support the output and printing of abnormal error information to remind the developer of the wrong function name, address and error location. Therefore, compiled languages ​​will have a place where users store these function information, such as pclntab.

[0114] As mentioned above, pclntab is also called Runtime Symbol Table in Go language, so the information contained in pclntab can be called RTSI. In the Go language system, Module is a higher-level concept than Package. Specifically, a Module can contain multiple different Packages, and each Package can contain multiple directories and many source code files. Correspondingly, moduledata is also a higher-level data structure in the Go language binary file. It contains index information of many other structures and can be regarded as a map of RTSI and RTTI in the Go language binary file. Therefore, the pointer address of the target function can be parsed from moduledata.

[0115] Specifically, Fig.14As shown, moduledata contains the ftab attribute and text for storing pointer addresses. The ftab attribute stores a list of all runtime function infrastructure structures, each of which is functab, such as functab1, functab2, etc. Two data are stored in functab, namely entryoff and funcoff, where funcoff is the offset of the function information (such as the offset starting from pclntab); entryoff is used to indicate the offset starting from the code segment, that is, the actual pointer position of the function.

[0116] Therefore, the function name can be obtained by reflecting the basic structure of the function through funcoff. Specifically, by traversing ftab and comparing the function name parsed by each functab with the target function name, the functab corresponding to the target function name can be found. After finding the functab of the target function, the entryoff offset in functab can be used to find the actual pointer address of the function from moduledata.text. After finding the actual pointer address of the target function, the pointer address of the target function is modified to the pointer address of the new function by modifying the pointer address. In this way, the modification of the target function in the consensus algorithm is completed, and the malicious behavior of the consensus node can be simulated through the modified function.

[0117] It should be noted that the method of obtaining the pointer address of the target function from moduledata is not only applicable to extracting by traversing the stack information at runtime, but also can be used to extract the compiled binary file, that is, the compiled binary file is decompiled to obtain the moduledata containing the original data, and then the pointer address of the target function is extracted by the above method. In the embodiment of the present application, the programming language Go is used as an example for explanation, and the technical solution of the embodiment of the present application can also be applied to other programming languages.

[0118] In summary, the technical solution of the embodiment of the present application can extract the pointer address of the target function by analyzing the compiled binary file or the stack information at runtime, and then replace the pointer address of the target function with the pointer address of the new function to complete the modification of the target function. This method can be implemented without relying on the source code of the consensus node, thereby improving the convenience and flexibility of testing the consensus algorithm of the blockchain system.

[0119] The following describes an embodiment of the device of the present application, which can be used to execute the consensus processing method of the blockchain system in the above embodiment of the present application. For details not disclosed in the embodiment of the device of the present application, please refer to the embodiment of the consensus processing method of the blockchain system in the above embodiment of the present application.

[0120] Fig.15 A block diagram of a consensus processing device of a blockchain system according to an embodiment of the present application is shown. The consensus processing device of the blockchain system can be applied to an electronic device, which can serve as a consensus node in the blockchain system.

[0121] Reference Fig.15 As shown, a consensus processing device 1500 of a blockchain system according to an embodiment of the present application includes: an acquisition unit 1502, a search unit 1504 and a processing unit 1506.

[0122] Among them, the acquisition unit 1502 is configured to obtain the operating data generated by the consensus node in the blockchain system during operation; the search unit 1504 is configured to search for the pointer address of the target function from the operating data, and the target function is a function in the consensus algorithm adopted by the consensus node; the processing unit 1506 is configured to modify the pointer address of the target function to the pointer address of the setting function in the memory of the consensus node, so that the consensus node calls the setting function for consensus processing.

[0123] In some embodiments of the present application, based on the aforementioned scheme, the search unit 1504 is configured to: search for the function structure of the target function according to the function structure information list contained in the running data; and search for the pointer address of the target function based on the function structure of the target function.

[0124] In some embodiments of the present application, based on the aforementioned scheme, the search unit 1504 is configured to: parse the function structure of each function contained in the function structure information list to obtain the first position offset contained in the function structure of each function, wherein the first position offset is used to represent the offset of the function information; search for the function information of each function in the running data according to the first position offset contained in the function structure of each function; locate the function structure of the target function in the function structure information list according to the function information of each function and the name of the target function.

[0125] In some embodiments of the present application, based on the aforementioned scheme, the search unit 1504 is configured to: search for the pointer address of the target function in the running data according to the second position offset contained in the function structure of the target function, and the second position offset is used to represent the offset of the function address.

[0126] In some embodiments of the present application, based on the aforementioned scheme, the acquisition unit 1502 is further configured to: when it is necessary to test the consensus process of the blockchain system, obtain a function that requires modification of the consensus algorithm adopted by the consensus node, and use the obtained function that requires modification of the consensus algorithm adopted by the consensus node as the setting function.

[0127] In some embodiments of the present application, based on the aforementioned scheme, the acquisition unit 1502 is further configured to: after modifying the pointer address of the target function to the pointer address of the set function in the memory of the consensus node, obtain the voting result of the consensus node for the proposal block; the processing unit 1506 is further configured to: compare the voting result of the consensus node for the proposal block with the expected voting result to determine the test effect of the consensus process of the blockchain system.

[0128] In some embodiments of the present application, based on the aforementioned scheme, the acquisition unit 1502 is further configured to: after modifying the pointer address of the target function to the pointer address of the set function in the memory of the consensus node, obtain the consensus result of the proposal block initiated by the consensus node; the processing unit 1506 is further configured to: compare the consensus result with the expected consensus result to determine the test effect of the consensus process of the blockchain system.

[0129] In some embodiments of the present application, based on the aforementioned scheme, the acquisition unit 1502 is configured to: when the consensus node in the blockchain system is in operation, obtain the data recorded by the specified application for recording runtime information, and use the data recorded by the specified application as the operation data.

[0130] Fig.16 A block diagram of a consensus processing device of a blockchain system according to an embodiment of the present application is shown. The consensus processing device of the blockchain system can be applied to an electronic device, which can serve as a consensus node in the blockchain system.

[0131] Reference Fig.16 As shown, a consensus processing device 1600 of a blockchain system according to an embodiment of the present application includes: an acquisition unit 1602, a decompilation unit 1604, a search unit 1606 and a processing unit 1608.

[0132] Among them, the acquisition unit 1602 is configured to obtain a binary file obtained by compiling the consensus algorithm by the consensus node in the blockchain system; the decompilation unit 1604 is configured to decompile the binary file to obtain decompiled data; the search unit 1606 is configured to search for the pointer address of the target function from the decompiled data, and the target function is a function in the consensus algorithm adopted by the consensus node; the processing unit 1608 is configured to modify the pointer address of the target function to the pointer address of the setting function in the memory of the consensus node if the consensus node starts the consensus processing process, so that the consensus node calls the setting function for consensus processing.

[0133] In some embodiments of the present application, based on the aforementioned scheme, the search unit 1606 is configured to: search for the function structure of the target function according to the function structure information list contained in the decompiled data; and search for the pointer address of the target function based on the function structure of the target function.

[0134] Fig.17 A schematic diagram of the structure of a computer system of an electronic device suitable for implementing an embodiment of the present application is shown, and the electronic device may be a consensus node in the aforementioned embodiment.

[0135] It should be noted that Fig.17 The computer system 1700 of the electronic device shown is only an example and should not bring any limitation to the functions and scope of use of the embodiments of the present application.

[0136] like Fig.17 As shown, the computer system 1700 may include a central processing unit (CPU) 1701, which can perform various appropriate actions and processes according to the program stored in the read-only memory (ROM) 1702 or the program loaded from the storage part 1708 to the random access memory (RAM) 1703, such as executing the method described in the above embodiment. In RAM 1703, various programs and data required for system operation are also stored. CPU 1701, ROM 1702 and RAM 1703 are connected to each other through bus 1704. Input / output (I / O) interface 1705 is also connected to bus 1704.

[0137] The following components can be connected to the I / O interface 1705: an input section 1706 including a keyboard, a mouse, etc.; an output section 1707 including a cathode ray tube (CRT), a liquid crystal display (LCD), etc., and a speaker, etc.; a storage section 1708 including a hard disk, etc.; and a communication section 1709 including a network interface card such as a LAN (Local Area Network) card, a modem, etc. The communication section 1709 performs communication processing via a network such as the Internet. A drive 1710 is also connected to the I / O interface 1705 as needed. A removable medium 1711, such as a magnetic disk, an optical disk, a magneto-optical disk, a semiconductor memory, etc., is installed on the drive 1710 as needed so that a computer program read therefrom is installed into the storage section 1708 as needed.

[0138] In particular, according to an embodiment of the present application, the process described above with reference to the flowchart can be implemented as a computer software program. For example, an embodiment of the present application includes a computer program product, which includes a computer program carried on a computer-readable medium, and the computer program is used to perform the method shown in the flowchart. In such an embodiment, the computer program can be downloaded and installed from a network through a communication section 1709, and / or installed from a removable medium 1711. When the computer program is executed by a central processing unit (CPU) 1701, various functions defined in the system of the present application are executed.

[0139] It should be noted that the computer-readable medium shown in the embodiment of the present application may be a computer-readable signal medium or a computer-readable storage medium or any combination of the above two. The computer-readable storage medium may be, for example, but not limited to, an electrical, magnetic, optical, electromagnetic, infrared, or semiconductor system, device or device, or any combination of the above. More specific examples of computer-readable storage media may include, but are not limited to: an electrical connection with one or more wires, a portable computer disk, a hard disk, a random access memory (RAM), a read-only memory (ROM), an erasable programmable read-only memory (EPROM), a flash memory, an optical fiber, a portable compact disk read-only memory (CD-ROM), an optical storage device, a magnetic storage device, or any suitable combination of the above. In the present application, a computer-readable storage medium may be any tangible medium containing or storing a computer program, which may be used by an instruction execution system, device or device or used in combination with it. In the present application, a computer-readable signal medium may include a data signal propagated in a baseband or as part of a carrier wave, wherein a computer-readable computer program is carried. Such propagated data signals may take a variety of forms, including but not limited to electromagnetic signals, optical signals, or any suitable combination of the above. Computer-readable signal media may also be any computer-readable medium other than computer-readable storage media, which may send, propagate, or transmit programs for use by or in conjunction with an instruction execution system, apparatus, or device. The computer program contained on the computer-readable medium may be transmitted using any appropriate medium, including but not limited to: wireless, wired, etc., or any suitable combination of the above.

[0140] The flowchart and block diagram in the accompanying drawings illustrate the possible architecture, functions and operations of the system, method and computer program product according to various embodiments of the present application. Wherein, each box in the flowchart or block diagram can represent a module, a program segment, or a part of the code, and the above-mentioned module, program segment, or a part of the code contains one or more executable instructions for realizing the specified logical function. It should also be noted that in some alternative implementations, the functions marked in the box can also occur in a different order from the order marked in the accompanying drawings. For example, two boxes represented in succession can actually be executed substantially in parallel, and they can sometimes be executed in the opposite order, depending on the functions involved. It should also be noted that each box in the block diagram or flowchart, and the combination of the boxes in the block diagram or flowchart can be implemented with a dedicated hardware-based system that performs a specified function or operation, or can be implemented with a combination of dedicated hardware and a computer program.

[0141] The units involved in the embodiments described in this application may be implemented by software or hardware, and the units described may also be set in a processor. The names of these units do not, in some cases, constitute limitations on the units themselves.

[0142] As another aspect, the present application also provides a computer-readable medium, which may be included in the electronic device described in the above embodiment; or may exist independently without being assembled into the electronic device. The above computer-readable medium carries one or more computer programs, and when the above one or more computer programs are executed by an electronic device, the electronic device implements the method described in the above embodiment.

[0143] It should be noted that, although several modules or units of the equipment for action execution are mentioned in the above detailed description, this division is not mandatory. In fact, according to the embodiments of the present application, the features and functions of two or more modules or units described above can be embodied in one module or unit. On the contrary, the features and functions of one module or unit described above can be further divided into being embodied by multiple modules or units.

[0144] Through the description of the above implementation methods, it is easy for those skilled in the art to understand that the example implementation methods described here can be implemented by software or by combining software with necessary hardware. Therefore, the technical solution according to the implementation methods of the present application can be embodied in the form of a software product, which can be stored in a non-volatile storage medium (which can be a CD-ROM, a USB flash drive, a mobile hard disk, etc.) or on a network, and includes several instructions to enable an electronic device to execute the method according to the implementation methods of the present application.

[0145] For example, electronic devices can perform Fig.11 or Fig.12 The consensus processing method of the blockchain system shown.

[0146] Those skilled in the art will readily appreciate other embodiments of the present application after considering the specification and practicing the embodiments disclosed herein. The present application is intended to cover any variations, uses or adaptations of the present application, which follow the general principles of the present application and include common knowledge or customary technical means in the art that are not disclosed in the present application.

[0147] It should be understood that the present application is not limited to the precise structures that have been described above and shown in the drawings, and that various modifications and changes may be made without departing from the scope thereof. The scope of the present application is limited only by the appended claims.

Claims

1. A consensus processing method for a blockchain system, characterized in that: include: Obtain the operation data generated by the consensus nodes in the blockchain system during operation; Finding a pointer address of a target function from the running data, where the target function is a function in the consensus algorithm adopted by the consensus node; In the memory of the consensus node, the pointer address of the target function is modified to the pointer address of the setting function, so that the consensus node calls the setting function to perform consensus processing.

2. The consensus processing method of the blockchain system according to claim 1 is characterized in that: Finding the pointer address of the target function from the running data includes: According to the function structure information list contained in the operation data, searching for the function structure of the target function; The pointer address of the target function is searched based on the function structure of the target function.

3. The consensus processing method of the blockchain system according to claim 2 is characterized in that: According to the function structure information list contained in the running data, searching for the function structure of the target function includes: Parsing the function structure of each function included in the function structure information list to obtain a first position offset included in the function structure of each function, wherein the first position offset is used to represent an offset of the function information; searching for function information of each function in the operation data according to the first position offset contained in the function structure of each function; According to the function information of each function and the name of the target function, the function structure of the target function is located in the function structure information list.

4. The consensus processing method of the blockchain system according to claim 2 is characterized in that: Searching for a pointer address of the target function based on a function structure of the target function includes: According to the second position offset contained in the function structure of the target function, the pointer address of the target function is searched in the running data, and the second position offset is used to represent the offset of the function address.

5. The consensus processing method of the blockchain system according to claim 1 is characterized in that: The consensus processing method of the blockchain system further includes: When the consensus process of the blockchain system needs to be tested, a function that needs to modify the consensus algorithm adopted by the consensus node is obtained, and the obtained function that needs to modify the consensus algorithm adopted by the consensus node is used as the setting function.

6. The consensus processing method of the blockchain system according to claim 1 is characterized in that: After the pointer address of the target function is modified to the pointer address of the setting function in the memory of the consensus node, the consensus processing method of the blockchain system further includes: Obtaining the voting results of the consensus node for the proposed block; The voting results of the consensus nodes for the proposed blocks are compared with the expected voting results to determine the test effect of the consensus process of the blockchain system.

7. The consensus processing method of the blockchain system according to claim 1 is characterized in that: After the pointer address of the target function is modified to the pointer address of the setting function in the memory of the consensus node, the consensus processing method of the blockchain system further includes: Obtain the consensus result of the proposal block initiated by the consensus node; The consensus result is compared with the expected consensus result to determine the test effect of the consensus process of the blockchain system.

8. The consensus processing method of the blockchain system according to any one of claims 1 to 7, characterized in that: Obtain the operation data generated by the consensus nodes in the blockchain system during operation, including: When the consensus node in the blockchain system is in operation, data recorded by a designated application for recording runtime information is obtained, and the data recorded by the designated application is used as the operation data.

9. A consensus processing method for a blockchain system, characterized in that: include: Obtain the binary file obtained by compiling the consensus algorithm by the consensus node in the blockchain system; Decompiling the binary file to obtain decompiled data; Finding a pointer address of a target function from the decompiled data, where the target function is a function in a consensus algorithm adopted by the consensus node; If the consensus node starts the consensus processing process, the pointer address of the target function is modified to the pointer address of the setting function in the memory of the consensus node, so that the consensus node calls the setting function to perform consensus processing.

10. The consensus processing method of the blockchain system according to claim 9 is characterized in that: Finding the pointer address of the target function from the decompiled data includes: According to the function structure information list contained in the decompiled data, searching for the function structure of the target function; The pointer address of the target function is searched based on the function structure of the target function.

11. A consensus processing device for a blockchain system, characterized in that: include: An acquisition unit, configured to acquire operation data generated by a consensus node in a blockchain system during operation; A search unit configured to search for a pointer address of a target function from the running data, wherein the target function is a function in a consensus algorithm adopted by the consensus node; The processing unit is configured to modify the pointer address of the target function to the pointer address of the setting function in the memory of the consensus node, so that the consensus node calls the setting function to perform consensus processing.

12. A consensus processing device for a blockchain system, characterized in that: include: An acquisition unit is configured to acquire a binary file obtained by compiling and processing the consensus algorithm by a consensus node in the blockchain system; A decompilation unit, configured to perform decompilation processing on the binary file to obtain decompiled data; A search unit configured to search for a pointer address of a target function from the decompiled data, wherein the target function is a function in a consensus algorithm adopted by the consensus node; The processing unit is configured to modify the pointer address of the target function to the pointer address of the setting function in the memory of the consensus node if the consensus node starts the consensus processing process, so that the consensus node calls the setting function to perform consensus processing.

13. A computer readable medium having a computer program stored thereon, characterized in that: When the computer program is executed by a processor, the consensus processing method of the blockchain system according to any one of claims 1 to 10 is implemented.

14. An electronic device, characterized in that: include: one or more processors; A memory for storing one or more computer programs, which, when executed by the one or more processors, enables the electronic device to implement the consensus processing method of the blockchain system as described in any one of claims 1 to 10.

15. A computer program product, characterized in that The computer program product includes a computer program, which is stored in a computer-readable storage medium. The processor of the electronic device reads and executes the computer program from the computer-readable storage medium, so that the electronic device executes the consensus processing method of the blockchain system as described in any one of claims 1 to 10.

Images