Blockchain honeychain fraud defense system and method

Abstract

The present invention discloses a honeychain fraud prevention system and method for blockchain. The system includes: multiple consensus node systems, wherein any consensus node system includes: a redirector, a blockchain consensus node, and a honeychain consensus node; if the blockchain consensus node fails to reach consensus, the redirector redirects the transaction set and consensus result to the honeychain consensus node of the same consensus node system; the blockchain consensus node determines whether to reselect the blockchain consensus node based on the consensus screening result; the honeychain consensus node is suitable for performing fraud screening based on the redirected transaction set and consensus result, and receiving the screening results broadcast by other honeychain consensus nodes through consensus communication; the consensus screening results are fed back to the blockchain consensus node through the redirector. By embedding honeychain technology into the blockchain consensus algorithm, the high reliability of the blockchain system is actively improved, ensuring that the prerequisites are met, rather than just passively handling the failure of the prerequisites.

Description

Technical Field

[0001] The present invention relates to the field of communication technologies, and in particular to a blockchain honeylink deception defense system and method. Background Art

[0002] Blockchain technology, a novel integrated application of distributed data storage, peer-to-peer transmission, consensus mechanisms, and encryption algorithms, boasts characteristics such as decentralization, openness, tamper-resistance, anonymity, and traceability. Blockchain systems do not rely on any centralized trusted institution, but instead ensure node integrity through incentives and consensus mechanisms. They use timestamps, hash value pointers, and digital signatures to ensure the irreversibility and traceability of transactions. Digital signatures ensure that transactions cannot be forged, tampered with, or denied. Digital signatures utilize a one-time public key to ensure user identity privacy. Only records recognized by a majority of accounting nodes are added to the blockchain.

[0003] Existing blockchain-based deception defense methods primarily utilize deception attack defense technology. The blockchain-based ARP deception attack defense method involves obtaining an ARP request sent by a source host to a target host within a local area network. The ARP request includes the target host's IP address; obtaining an ARP response returned by the target host to the source host. The ARP response includes the target host's first MAC address; querying the target host's second MAC address stored on the blockchain network based on the target host's IP address; determining whether the first and second MAC addresses are consistent; and, if the first and second MAC addresses are inconsistent, sending the second MAC address to the source host, allowing the source host to communicate with the target host based on the second MAC address. However, this technology suffers from the following issues: It lacks an integrated approach to consensus algorithms and processes, enabling it to passively handle consensus failures. Summary of the Invention

[0004] In view of the above problems, embodiments of the present invention are proposed to provide a blockchain honeychain fraud defense system and method that overcomes the above problems or at least partially solves the above problems.

[0005] According to one aspect of an embodiment of the present invention, a blockchain honeychain fraud prevention system is provided, comprising: a plurality of consensus node systems, wherein any consensus node system comprises: a redirector, a blockchain consensus node, and a honeychain consensus node;

[0006] The blockchain consensus node is adapted to perform consensus verification on the received transaction set to obtain a first consensus verification result; receive a second consensus verification result broadcast by other blockchain consensus nodes through consensus communication, and determine whether consensus is reached based on the first consensus verification result and the second consensus verification result; if not, redirect the transaction set and the consensus result to a honeychain consensus node in the same consensus node system through a redirector; and determine whether to reselect a blockchain consensus node based on the consensus screening result;

[0007] The honeychain consensus node is suitable for performing fraud detection based on the redirected transaction set and consensus results, receiving the detection results broadcast by other honeychain consensus nodes through consensus communication, and feeding back the consensus detection results to the blockchain consensus node through the redirector.

[0008] According to another aspect of an embodiment of the present invention, a method for preventing honeylink fraud in a blockchain is provided. The method is applied to the honeylink fraud prevention system of the blockchain described above, and the method includes:

[0009] The blockchain consensus node performs consensus verification on the received transaction set to obtain a first consensus verification result; receives the second consensus verification result broadcast by other blockchain consensus nodes through consensus communication, and determines whether consensus is reached based on the first consensus verification result and the second consensus verification result; if not, redirects the transaction set and consensus result to the honeychain consensus node of the same consensus node method through the redirector; determines whether to re-select the blockchain consensus node based on the consensus screening result;

[0010] The honeychain consensus node performs fraud detection based on the redirected transaction set and consensus results, receives the detection results broadcast by other honeychain consensus nodes through consensus communication, and feeds back the consensus detection results to the blockchain consensus node through the redirector.

[0011] According to another aspect of an embodiment of the present invention, there is provided a computing device, comprising: a processor, a memory, a communication interface, and a communication bus, wherein the processor, the memory, and the communication interface communicate with each other via the communication bus;

[0012] The memory is used to store at least one executable instruction, and the executable instruction enables the processor to perform operations corresponding to the above-mentioned blockchain honeychain deception defense method.

[0013] According to another aspect of an embodiment of the present invention, a computer storage medium is provided, in which at least one executable instruction is stored. The executable instruction enables a processor to perform operations corresponding to the above-mentioned blockchain honeylink deception defense method.

[0014] According to the solution provided by the above-mentioned embodiment of the present invention, honeylink technology is embedded in the blockchain consensus algorithm, which actively improves the high reliability of the blockchain system and ensures that the prerequisites are met, rather than just passively handling the situation where the prerequisites fail.

[0015] The above description is only an overview of the technical solutions of the embodiments of the present invention. In order to more clearly understand the technical means of the embodiments of the present invention, they can be implemented in accordance with the contents of the specification. In order to make the above and other purposes, features and advantages of the embodiments of the present invention more obvious and easy to understand, the specific implementation methods of the embodiments of the present invention are listed below. BRIEF DESCRIPTION OF THE DRAWINGS

[0016] Various other advantages and benefits will become apparent to those skilled in the art upon reading the detailed description of the preferred embodiment below. The accompanying drawings are for illustration purposes only and are not to be considered as limiting the embodiments of the present invention. The same reference numerals are used throughout the accompanying drawings to denote the same components. In the accompanying drawings:

[0017] Figure 1A A schematic diagram of a blockchain honeychain fraud prevention system provided by an embodiment of the present invention is shown;

[0018] Figure 1B This is a schematic diagram of a directed acyclic graph (DAG) honeychain log.

[0019] Figure 1C Schematic diagram of the working blockchain maintained by the blockchain consensus node and the shadow honeychain maintained by the honeychain consensus node;

[0020] Figure 1D Schematic diagram of the working blockchain and shadow honeychain after the transaction rollback operation;

[0021] Figure 2 A flowchart of a method for preventing honeychain fraud in a blockchain provided by an embodiment of the present invention is shown;

[0022] Figure 3 A schematic structural diagram of a computing device provided by an embodiment of the present invention is shown. DETAILED DESCRIPTION

[0023] Exemplary embodiments of the present invention will be described in more detail below with reference to the accompanying drawings. Although exemplary embodiments of the present invention are shown in the accompanying drawings, it should be understood that the present invention can be implemented in various forms and should not be limited by the embodiments set forth herein. Rather, these embodiments are provided to enable a more thorough understanding of the present invention and to fully convey the scope of the present invention to those skilled in the art.

[0024] Figure 1 shows a schematic diagram of a blockchain honeychain fraud prevention system provided by an embodiment of the present invention. As shown in Figure 1, the system includes: multiple consensus node systems, wherein any consensus node system includes: a redirector, a blockchain consensus node, and a honeychain consensus node;

[0025] The blockchain consensus node is adapted to perform consensus verification on the received transaction set to obtain a first consensus verification result; receive the second consensus verification result broadcast by other blockchain consensus nodes through consensus communication, and determine whether consensus is reached based on the first consensus verification result and the second consensus verification result; if not, redirect the transaction set and the consensus result to the honeychain consensus node of the same consensus node system through the redirector; and determine whether to reselect the blockchain consensus node based on the consensus screening processing result.

[0026] The honeychain consensus node is suitable for performing fraud screening on the redirected transaction set and consensus results, receiving the screening results broadcast by other honeychain consensus nodes through consensus communication; and feeding back the consensus screening results to the blockchain consensus node through the redirector.

[0027] The blockchain honeychain fraud prevention system provided in this embodiment runs a consensus algorithm on the blockchain consensus node, for example, the Byzantine fault-tolerant consensus algorithm. Of course, it can also be other consensus algorithms, which are not specifically limited here.

[0028] Each blockchain consensus node performs consensus verification on the transaction set it receives and obtains a first consensus verification result; each blockchain consensus node can conduct consensus communication between itself and receive the second consensus verification result broadcast by other blockchain consensus nodes in the system through consensus communication, and determine whether consensus is reached based on the first consensus verification result and the second consensus verification result; if not, the transaction set and consensus result are redirected to the honeychain consensus node belonging to the same consensus node system through the redirector. At this time, the transaction set is not chained to the working blockchain, thereby ensuring the security of the system; based on the consensus screening processing result, it is determined whether to re-select the blockchain consensus node.

[0029] The honeychain consensus node is suitable for performing fraud detection based on the redirected transaction set and consensus results, receiving the detection results broadcast by other honeychain consensus nodes through consensus communication, and feeding back the consensus detection results to the blockchain consensus node through the redirector.

[0030] In an optional embodiment of the present invention, the blockchain consensus node is further adapted to: count the number of blockchain consensus nodes that have not reached consensus;

[0031] If the number of blockchain consensus nodes that have not reached consensus is less than or equal to the preset number, the transaction set will be uploaded to the working blockchain, and the consensus failure risk level will be determined based on the number of blockchain consensus nodes that have not reached consensus. The consensus failure risk level, transaction set, and consensus result will be redirected to the honeychain consensus node in the same consensus node system through the redirector.

[0032] If the number of blockchain consensus nodes that have not reached consensus is greater than the preset number, the transaction set and consensus results will be redirected to the honeychain consensus node of the same consensus node system through the redirector.

[0033] The consensus algorithm used here is the Byzantine Fault Tolerance consensus algorithm. This is not limited to the above algorithms. The Practical Byzantine Fault Tolerance (PBFT) consensus algorithm points out the prerequisite for ensuring the normal operation of the system. That is, when the number of faulty blockchain consensus nodes is less than or equal to f, the blockchain system can still operate normally and obtain the correct result.

[0034] like Figure 1A As shown in the figure, a blockchain's honeychain fraud prevention system has 3f + 1 = 4 blockchain consensus nodes, distributed across four independent consensus node systems A, B, C, and D. Where f = 1, this means that even if a compromised blockchain consensus node appears in the honeychain fraud prevention system, the system will still function normally. In addition to independently performing normal operations such as transaction verification, encryption and decryption, smart contract execution, consensus algorithm operation, verification result voting, broadcast communication, and blockchain storage, each consensus node system also utilizes honeychain fraud prevention technology to enhance and strengthen blockchain security.

[0035] Let x represent the number of blockchain consensus nodes that failed to reach consensus during the consensus process, where the blockchain consensus nodes that failed to reach consensus refer to the blockchain consensus nodes whose consensus results were inconsistent with the consensus results of no less than 2f+1 blockchain consensus nodes during the consensus process; z represents the number of rounds after consensus is reached, and Z represents the threshold number of rounds for block production; y represents the number of rounds in which the consistency of the consensus result is less than 2f+1, and Y represents the threshold number of rounds in which the consensus result is inconsistent; r represents the risk level of the failure of the PBFT prerequisite, for example, three levels: high, medium, and low, based on the ratio of x to f.

[0036] After the blockchain's honeychain fraud prevention system is activated, 3f+1 consensus nodes are selected from the consensus node pool (assuming all blockchain consensus nodes in the consensus node pool are in a safe and healthy state) to participate in the blockchain's honeychain fraud prevention system's consensus operation. A blockchain consensus master node is selected from the 3f+1 consensus nodes to build blocks. The selected master node sequentially extracts a certain number of transaction blocks from its transaction pool and broadcasts these blocks to the other selected consensus nodes. The 3f+1 consensus nodes then execute the Byzantine Fault Tolerance algorithm.

[0037] If the number of blockchain consensus nodes that have not reached consensus does not exceed f, a block is generated and the number of rounds z of block generation does not exceed Z. If the transaction set continues to be obtained from the transaction pool, if it exceeds Z, a new blockchain consensus master node is selected from the selected 3f+1 blockchain consensus nodes to continue the consensus operation; at the same time, the risk level is calculated based on the value of x, and the risk level, transaction set, and consensus result are redirected to the honeychain consensus node in the same consensus node system through the redirector for further processing by the honeychain consensus node;

[0038] If the number of blockchain consensus nodes that have not reached consensus exceeds f, the system further determines whether the number of rounds y in which consensus has not been reached is less than or equal to the threshold Y. If so, the transactions in the transaction block are returned to the transaction pool, a new transaction set is obtained, and the blockchain consensus master node continues to build the block. If the number of rounds y in which consensus has not been reached is greater than the threshold Y, the security of the entire blockchain is in a serious threat, and 3f+1 blockchain consensus nodes must be reselected from the consensus node pool to participate in the consensus operation. At the same time, the transaction set and consensus result state are redirected to the honeychain consensus node in the same consensus node system through the redirector for further processing by the honeychain consensus node.

[0039] In an optional embodiment of the present invention, the honeychain consensus node is further adapted to: use a private key to sign the transaction set and the consensus result to generate a request verification package, connect the request verification package to the local directed acyclic graph DAG honeychain log, broadcast the request verification package to other honeychain consensus nodes, so that other honeychain consensus nodes can connect the request verification package to their respective local directed acyclic graph DAG honeychain logs, verify the request verification package to obtain a verification package, and broadcast the verification package; receive the verification packages broadcasted by other honeychain consensus nodes, determine the target transaction set to be tracked based on the received verification packages, perform transaction party tracking on the target transaction set, and notify the redirector to route the target transaction set corresponding to the transaction party to the honeychain consensus node.

[0040] Among them, each honeychain consensus node connects the first request verification package to the genesis package of the local directed acyclic graph DAG honeychain log; connects the Nth request verification package to the most recently connected verification package of the directed acyclic graph DAG honeychain log; if there is no connected verification package within the preset time period, the request verification package will be directly connected to the most recently connected request verification package, where N≥2.

[0041] The honeychain consensus node is also suitable for: regularly broadcasting the incremental directed acyclic graph (DAG) honeychain log to other honeychain consensus nodes; and identifying whether the honeychain consensus node is controlled based on the incremental directed acyclic graph (DAG) honeychain log broadcast by other honeychain consensus nodes through consensus communication and the local directed acyclic graph (DAG) honeychain log.

[0042] Specifically, while blockchain data is tamper-proof and decentralized, attacks on the blockchain are ubiquitous. These attacks can stem from vulnerabilities in the blockchain itself and smart contracts, as well as a variety of hacker attacks, including phishing websites, DDoS attacks on exchanges, and deception.

[0043] Availability attacks on blockchain systems are similar to traditional DDoS attacks, halting the processing of valuable transactions and data, thus halting the entire system. Hackers can employ simple methods, such as flooding the network with junk transactions or maliciously blocking one or more consensus nodes, causing an eclipse attack on them.

[0044] Taking the PBFT-based consortium chain as an example, in order to prevent and disrupt the normal progress of transactions and paralyze the blockchain system, hackers may send a large or even extremely large number of transactions to some blockchain consensus nodes in the blockchain system, exhausting network bandwidth resources and forming a blockade of these blockchain consensus nodes, causing the number of blockchain consensus nodes that cannot reach consensus to exceed f, ultimately causing the blockchain system to be unable to produce blocks normally and become paralyzed.

[0045] Assume that consensus node system A is blocked and continuously receives a large number of transaction processing requests, which makes blockchain consensus node A unable to receive other normal transaction processing requests, unable to verify these normal transactions, and unable to participate in consensus voting. At the end of a round of consensus, it is confirmed as an error node by the other three blockchain consensus nodes. Blockchain consensus node A sends the transaction set S A Together with the consensus result R of this round, it is sent to the redirector, which forwards it to the honeychain consensus node A. Figure 1B shown.

[0046] Honeychain consensus node A will send transaction set S AThe request verification package P is packaged with the consensus result R and signed with its private key. On the one hand, P is connected to the local directed acyclic graph DAG honeychain log (abbreviated as honeylog). The request verification package P is represented by a square in the DAG honeylog. On the other hand, P is broadcast to the honeychain consensus nodes B, C, and D of other consensus node systems. Honeychain consensus nodes B, C, and D receive the request verification package P and each connect the request verification package P to the local DAG honeylog. Assuming that the hacker's target is honeychain consensus node A, the transaction set S in P sent from honeychain consensus node A is A , most transactions are not received by Honeychain consensus nodes B, C, and D. Honeychain consensus nodes B, C, and D each mark the unreceived transactions and each package their verification results into a verification package V, signed with their own private key. Each verification package V is inserted into the local DAG honeylog. The V package is represented by a triangle in the DAG. Furthermore, each packaged and signed verification package V is broadcast to the honeychain consensus nodes of the other consensus node systems. These honeychain consensus nodes receive the verification package V and each inserts all received verification results into their local DAG honeylog. Assuming that Honeychain consensus nodes B, C, and D can successfully execute the verification request, the broadcasted V packages are all received. Honeychain consensus node A determines the target transaction set T to be tracked based on the three V packages from the other three honeychain consensus nodes.

[0047] After determining the target transaction set to be tracked, Honeychain consensus node A simultaneously takes three actions. First, it implements watermark technology to track the initiator of the transaction in the target transaction set T, providing attack paths and other evidence of the attack. Second, it queries the registration information of the users in the target transaction set from the identity authentication center CA, verifies the watermark technology-tracked transactions with the query results of the identity authentication center CA, and further confirms the true identity of the transaction initiator so that the initiator of the transaction can be held financially and legally accountable. At the same time, the redirector of consensus node system A is notified to route all target transaction sets involved in the transaction to Honeychain consensus node A. On the one hand, Honeychain consensus node A continues to track and analyze the initiators of these transactions, and on the other hand, it avoids the pressure of these transactions on blockchain consensus node A to process normal transaction requests, allowing blockchain consensus node A to resume normal operation and ensure that the prerequisites of the Byzantine fault tolerance algorithm are always met.

[0048] This embodiment uses a directed acyclic graph (DAG) data structure as the carrier for honeychain logs, rather than block chain or other data structures, because DAG-based distributed ledger technology offers high scalability and concurrency, making it suitable for blockchain system security testing scenarios. The logging objective of honeychain consensus nodes is not to process business transactions, but to ensure the secure operation of the blockchain system. Honeychain logs must be secure and efficient, with high throughput, to process the large volume of logs generated by honeychain technology. This embodiment ensures security through private key signatures and independent storage of DAG honeylogs. The DAG honeylog in this embodiment not only independently records request verification packets P and verification packets V, but also enables a series of security analysis and testing based on the DAG honeylog.

[0049] The starting node of the DAG honeylog is the genesis package. Each honeychain consensus node directly connects the first submitted request verification to the genesis node; the request verification package submitted later is connected to the verification package that it has completed most recently. If it has not participated in the verification for a certain period of time, the request verification package is directly connected to the request verification package submitted most recently. By analyzing the DAG honeylog and processing the information of each request verification package and verification package in the DAG honeylog, the relationship between nodes in the same DAG honeylog also provides important information, such as (1) the situation of each honeychain consensus node participating in the verification. If the honeychain consensus node cannot participate in the verification in time, there may be some problems or risks. (2) The honeychain consensus node continuously issues verification requests, which is reflected in the DAG honeylog as the request verification nodes being continuously and directly connected to each other. The corresponding blockchain consensus node may be under serious threat, which should arouse the high vigilance of other blockchain consensus nodes.

[0050] In addition, each honeychain consensus node iteratively forwards incremental DAG honeylogs to each other in a scheduled or pre-agreed manner. By analyzing the similarity of the DAGs of different honeychain consensus nodes, it is possible to find out whether there is a possibility that the honeychain consensus node is controlled, thereby improving and ensuring the security of the honeychain subsystem.

[0051] In an optional embodiment of the present invention, the honeychain consensus node is further adapted to: start the honeychain cabin, execute the smart contract according to the target transaction set in the honeychain cabin, and store the execution result in the cabin transaction pool; perform consensus verification on the shadow block created by the honeychain consensus master node to obtain a third consensus verification result; receive the fourth consensus verification result broadcast by other honeychain consensus nodes through consensus communication, determine whether consensus is reached based on the third consensus verification result and the fourth consensus verification result, and if so, link the consensus shadow block to the shadow honeychain;

[0052] If the preset isolation window period ends, determine whether there is any attack on the smart contract;

[0053] If there is no attack, the honeychain container is closed to remove the isolation of the smart contract operation and the target transaction set, and the shadow blocks on the shadow honeychain are synchronized to the working blockchain;

[0054] If there is an attack, the shadow honeychain transaction is rolled back to its initial state.

[0055] Specifically, a smart contract is a consensus-based rule stored in code on the blockchain. When the contract conditions are met, the contract code automatically executes without interference or control by any party. Transactions triggered by the contract are traceable and irreversible. While smart contracts are powerful, developing completely flawless code is impossible. If a contract written in code is legally binding and stores information on an immutable blockchain, vulnerabilities in smart contract code can pose significant risks and cause immeasurable economic losses, making it a major concern for blockchain security.

[0056] After reaching consensus, each consensus system in the blockchain system independently stores and maintains its own working blockchain and shadow honeychain, such as Figure 1C As shown in the figure, the working blockchain refers to the blocks in the blockchain consensus system that have been verified and reached consensus by the consensus nodes, while the shadow honeychain refers to the blocks reached by the honeychain consensus nodes in the blockchain consensus system, which are pointed to the corresponding working blocks or synchronized to the working blockchain.

[0057] Smart contracts are vulnerable to attacks such as reentrancy, permission control, integer overflow, unchecked call return values, transaction order dependency, timestamp dependency, and race conditions. Attacks on smart contracts often result in significant financial losses. For example, an attacker may pass a very large parameter value, causing the payment integer variable amount to overflow and reach zero through assignment. If the smart contract code fails to check the amount, even if subsequent code performs rigorous checks, the amount will bypass the check after reaching zero. As a result, the hacker can obtain a very large amount of digital currency while not receiving a single cent in their own wallet. This is a typical integer overflow attack. Reentrancy is essentially recursion: a loop in which a function is repeatedly called and then called again. The code contract's withdraw function can actually perform recursive operations. However, the problem is that it does not perform a pre-check before transferring the funds, creating a condition for an attacker to successfully exploit a reentrancy vulnerability. Therefore, shadow honeychain processing is necessary. The specific process is as follows:

[0058] The redirector redirects the transaction set sent by the blockchain consensus node and the target transaction set notified by the honeychain consensus node to redirect to the honeychain consensus node. These transaction requests execute the suspected problematic smart contract.

[0059] Honeychain consensus nodes pre-set an isolation window through a consensus mechanism. Each Honeychain consensus node activates the Honeychain pod, where smart contracts are executed. "Account read" operations for Honeychain contracts are available on the working blockchain, but "account write" operations for Honeychain contracts are only possible on the shadow Honeychain. Each Honeychain consensus node executes the smart contract in the Honeychain pod, and the execution results are placed in the pod's pending transaction pool.

[0060] If the isolation window has not yet expired, the system checks whether the block creation conditions have been met, such as whether the transaction volume in the transaction pool has reached a certain threshold or a certain time period has passed. If the block creation conditions are met, each honeychain consensus node extracts the transaction set from the honeychain cube's transaction pool. The honeychain consensus master node in the honeychain consensus node creates a block. Each honeychain consensus node verifies the contract execution results, inserts the consensus shadow block into the shadow honeychain, and continues to check whether the isolation window has expired. If the block creation conditions are not met, the smart contract continues to execute, and the execution results are placed in the cube's transaction pool.

[0061] If the isolation window ends, diagnose whether there are smart contract vulnerabilities and hacker attacks. If it can be confirmed that there are no attacks, close the honeychain cabin to release the isolation of smart contract operation and data, and synchronize the consensus block on the shadow honeychain to the working blockchain. Figure 1D As shown, taking blockchain consensus system A as an example, blocks a2' and a3' on the shadow honeychain are executed in an isolated cabin to verify the contract results, vote, and block shadow honeychain. When it is confirmed that there is no attack, blocks a2' and a3' on the shadow honeychain are synchronized to the working blockchain as a2 and a3. If a smart contract vulnerability is confirmed and an attack occurs, the honeychain subsystem will take a transaction rollback operation, which may adopt a transaction rollback operation pre-determined by the blockchain system, such as the Saga mechanism. The most efficient and direct method is to invalidate the block data on the shadow honeychain and roll back to the last block state of the working blockchain, such as Figure 1D As shown, assuming that the shadow block processed by the honeychain consensus node in the honeychain cabin reaches a5', then the shadow block data a5' of the shadow honeychain is discarded, and the last block of the working blockchain processed by the blockchain system is a4.

[0062] Each honeychain consensus node in a shadow honeychain independently executes smart contract code in an isolated container. The data accessed and operations performed by the contract code are restricted: "read account" operations can be performed on the working blockchain, but "write account" operations can only be performed on the honeychain. This ensures that potential attackers perceive the blockchain system as executing contract code without being deceived by the honeychain, enhancing the system's high interoperability. Furthermore, it prevents potential threats from causing damage to the blockchain system. If the threat is confirmed to be non-attackable, the smart contract execution and block verification results of each honeychain consensus node in the honeychain system are synchronized and reused. If a smart contract vulnerability is confirmed and an attack is underway, the honeychain consensus node performs a transaction rollback, using a pre-defined transaction rollback procedure within the blockchain system. This returns the blockchain system to a state as if no attack had occurred, effectively preventing any adverse consequences of the attack.

[0063] In a consortium chain system based on the Byzantine fault-tolerant consensus algorithm, 3f+1 blockchain consensus nodes run the Byzantine fault-tolerant consensus algorithm. If less than or equal to f blockchain consensus nodes do not provide a consistent consensus result, on the one hand, normal block building is carried out and the block is put on the chain; on the other hand, the honeychain subsystem is triggered through the redirector to identify whether it is a transaction abnormality or these consensus nodes are controlled; if it is a transaction abnormality, the honeychain subsystem will record, analyze and track the transaction initiator. If the consensus node is controlled, the honeychain subsystem will start the shadow honeychain technology, generate shadow blocks and support transaction rollback to avoid economic losses caused by malicious attacks; the honeychain subsystem will promptly feedback the analysis and tracking results to the redirector, and the redirector will feedback the detection results of the honeychain system to the blockchain consensus system. The blockchain consensus system will decide whether to reselect the consensus node set from the consensus node pool based on the current number of error nodes and the severity, to ensure that the consensus node set always meets the prerequisites for the normal operation of the consensus algorithm.

[0064] This invention provides a solution that embeds honeylink technology into the blockchain consensus algorithm, proactively improving the reliability of the blockchain system and ensuring that prerequisites are met, rather than simply reactively addressing precondition failures. A honeylink log based on a DAG data structure supports both independent and coordinated logging, as well as efficient and easy analysis. Within the honeylink subsystem, suspected vulnerable smart contracts are placed in a honeylink container, preventing potential damage to the blockchain system while ensuring high interactivity and enhancing fraud prevention. Shadow honeylinks support transaction rollback, restoring the blockchain system to a state as if no attack had occurred, effectively preventing any adverse consequences of the attack.

[0065] Figure 2FIG1 is a flowchart of a honeylink fraud prevention method for a blockchain provided by another embodiment of the present invention. The method is applied to the honeylink fraud prevention system of the blockchain of the embodiment shown in FIG1 , such as Figure 2 As shown, the method includes the following steps:

[0066] In step S201, the blockchain consensus node performs consensus verification on the received transaction set to obtain a first consensus verification result; receives a second consensus verification result broadcast by other blockchain consensus nodes through consensus communication, and determines whether consensus is reached based on the first consensus verification result and the second consensus verification result; if not, redirects the transaction set and consensus result to the honeychain consensus node of the same consensus node method through the redirector; and determines whether to reselect the blockchain consensus node based on the consensus screening processing result.

[0067] In step S202, the honeychain consensus node performs fraud detection processing based on the redirected transaction set and consensus results, receives the detection processing results broadcast by other honeychain consensus nodes through consensus communication, and feeds back the consensus detection processing results to the blockchain consensus node through the redirector.

[0068] Optionally, the honeychain consensus node performs fraud detection based on the redirected transaction set and consensus result, and receives the detection result broadcasted by other honeychain consensus nodes through consensus communication; and feeding back the consensus detection result to the blockchain consensus node through the redirector further includes:

[0069] Use the private key to sign the transaction set and consensus result to generate a request verification package, connect the request verification package to the local directed acyclic graph (DAG) honeychain log, broadcast the request verification package to other honeychain consensus nodes, so that other honeychain consensus nodes can connect the request verification package to their respective local directed acyclic graph (DAG) honeychain logs, verify the request verification package to obtain a verification package, and broadcast the verification package; receive the verification package broadcasted by other honeychain consensus nodes, determine the target transaction set to be tracked based on the received verification package, track the transaction party of the target transaction set, and notify the redirector to route the target transaction set corresponding to the transaction party to the honeychain consensus node.

[0070] Optionally, each honeychain consensus node connects the first request verification package to the genesis package of the local directed acyclic graph DAG honeychain log; connects the Nth request verification package to the most recently connected verification package of the directed acyclic graph DAG honeychain log; if there is no connected verification package within a preset time period, the request verification package is directly connected to the most recently connected request verification package, where N≥2.

[0071] Optionally, the method also includes: the honeychain consensus node regularly broadcasts the incremental directed acyclic graph DAG honeychain log to other honeychain consensus nodes; and identifies whether the honeychain consensus node is controlled based on the incremental directed acyclic graph DAG honeychain log broadcast by other honeychain consensus nodes through consensus communication and the local directed acyclic graph DAG honeychain log.

[0072] Optionally, the method further includes: the honeychain consensus node starts the honeychain cabin, executes the smart contract according to the target transaction set in the honeychain cabin, and stores the execution result in the cabin transaction pool; performs consensus verification on the shadow block created by the honeychain consensus master node to obtain a third consensus verification result; receives the fourth consensus verification result broadcast by other honeychain consensus nodes through consensus communication, determines whether consensus is reached based on the third consensus verification result and the fourth consensus verification result, and if so, links the consensus shadow block to the shadow honeychain;

[0073] If the preset isolation window period ends, determine whether there is any attack on the smart contract;

[0074] If there is no attack, the honeychain container is closed to remove the isolation of the smart contract operation and the target transaction set, and the shadow blocks on the shadow honeychain are synchronized to the working blockchain;

[0075] If there is an attack, the shadow honeychain transaction is rolled back to its initial state.

[0076] Optionally, the blockchain consensus node determining whether consensus is reached according to the first consensus verification result and the second consensus verification result further includes:

[0077] Count the number of blockchain consensus nodes that have not reached consensus;

[0078] If the number of blockchain consensus nodes that have not reached consensus is less than or equal to the preset number, the transaction set will be uploaded to the working blockchain, and the consensus failure risk level will be determined based on the number of blockchain consensus nodes that have not reached consensus; the consensus failure risk level, transaction set and consensus result will be redirected to the honeychain consensus node of the same consensus node method through the redirector.

[0079] Optionally, the method also includes: if the number of blockchain consensus nodes that have not reached consensus is greater than a preset number, the blockchain consensus node redirects the transaction set and consensus result to the honeychain consensus node of the same consensus node method through a redirector.

[0080] This invention provides a solution that embeds honeylink technology into the blockchain consensus algorithm, proactively improving the reliability of the blockchain system and ensuring that prerequisites are met, rather than simply reactively addressing precondition failures. A honeylink log based on a DAG data structure supports both independent and coordinated logging, as well as efficient and easy analysis. Within the honeylink subsystem, suspected vulnerable smart contracts are placed in a honeylink container, preventing potential damage to the blockchain system while ensuring high interactivity and enhancing fraud prevention. Shadow honeylinks support transaction rollback, restoring the blockchain system to a state as if no attack had occurred, effectively preventing any adverse consequences of the attack.

[0081] An embodiment of the present invention provides a non-volatile computer storage medium, which stores at least one executable instruction. The computer executable instruction can execute the blockchain honeylink deception defense method in any of the above method embodiments.

[0082] Figure 3 The schematic diagram of the structure of the computing device provided by the embodiment of the present invention is shown. The specific embodiment of the present invention does not limit the specific implementation of the computing device.

[0083] like Figure 3 As shown, the computing device may include: a processor, a communication interface, a memory, and a communication bus.

[0084] The processor, communication interface, and memory communicate with each other via a communication bus. The communication interface is used to communicate with other devices, such as clients or other server network elements. The processor is used to execute programs, specifically the steps described in the aforementioned embodiment of the honeylink fraud prevention method for blockchain computing devices.

[0085] Specifically, the program may include program codes including computer operation instructions.

[0086] The processor may be a central processing unit (CPU), an application-specific integrated circuit (ASIC), or one or more integrated circuits configured to implement the embodiments of the present invention. The one or more processors included in the computing device may be processors of the same type, such as one or more CPUs, or processors of different types, such as one or more CPUs and one or more ASICs.

[0087] Memory is used to store programs. The memory may include high-speed RAM memory, and may also include non-volatile memory (non-volatile memory), such as at least one disk storage.

[0088] The program can be specifically configured to cause a processor to execute the blockchain honeylink fraud prevention method described in any of the aforementioned method embodiments. The specific implementation of each step in the program can be found in the corresponding descriptions of the corresponding steps and units in the aforementioned blockchain honeylink fraud prevention embodiments and will not be repeated here. Those skilled in the art will clearly understand that, for ease and brevity of description, the specific operating processes of the devices and modules described above can be referenced to the corresponding process descriptions in the aforementioned method embodiments and will not be repeated here.

[0089] The algorithm or display provided herein is not inherently related to any particular computer, virtual system or other device. Various general-purpose systems can also be used together with the teachings based on this. According to the above description, it is obvious that the structure required for constructing such systems. In addition, the embodiment of the present invention is not directed to any specific programming language. It should be understood that various programming languages ​​can be utilized to implement the content of the embodiment of the present invention described herein, and the above description of specific languages ​​is for the purpose of disclosing the best mode of implementation of the embodiment of the present invention.

[0090] In the description provided herein, numerous specific details are described. However, it is understood that embodiments of the present invention may be practiced without these specific details. In some instances, well-known methods, structures, and techniques are not shown in detail so as not to obscure the understanding of this description.

[0091] Similarly, it should be understood that in order to streamline the embodiments of the invention and aid in understanding one or more of the various inventive aspects, in the above description of exemplary embodiments of the invention, various features of the embodiments of the invention are sometimes grouped together into a single embodiment, figure, or description thereof. However, this disclosed approach should not be interpreted as reflecting an intention that the claimed embodiments of the invention require more features than are expressly recited in each claim. Rather, as reflected in the claims below, inventive aspects lie in less than all of the features of the individual embodiments disclosed above. Accordingly, the claims that follow the detailed description are hereby expressly incorporated into this detailed description, with each claim standing on its own as a separate embodiment of the invention.

[0092] Those skilled in the art will appreciate that the modules in the devices in the embodiments may be adaptively changed and arranged in one or more devices different from the embodiments. The modules or units or components in the embodiments may be combined into one module or unit or component, and in addition may be divided into multiple submodules or subunits or subcomponents. All features disclosed in this specification (including the accompanying claims, abstracts and drawings) and all processes or units of any method or device disclosed herein may be combined in any combination, except that at least some of such features and / or processes or units are mutually exclusive. Unless expressly stated otherwise, each feature disclosed in this specification (including the accompanying claims, abstracts and drawings) may be replaced by an alternative feature providing the same, equivalent or similar purpose.

[0093] Furthermore, those skilled in the art will appreciate that although some embodiments herein include certain features included in other embodiments but not other features, combinations of features from different embodiments are intended to be within the scope of the present invention and to form different embodiments. For example, in the claims below, any of the claimed embodiments may be used in any combination.

[0094] The various component embodiments of the present invention can be implemented in hardware, or in software modules running on one or more processors, or in a combination thereof. It should be understood by those skilled in the art that a microprocessor or digital signal processor (DSP) can be used in practice to implement some or all of the functions of some or all of the components according to the embodiments of the present invention. The embodiments of the present invention can also be implemented as a device or apparatus program (e.g., a computer program and a computer program product) for executing part or all of the methods described herein. Such a program implementing an embodiment of the present invention can be stored on a computer-readable medium, or can have the form of one or more signals. Such a signal can be downloaded from an Internet website, or provided on a carrier signal, or provided in any other form.

[0095] It should be noted that the above embodiments illustrate rather than limit the embodiments of the invention, and that a person skilled in the art may devise alternative embodiments without departing from the scope of the appended claims. In the claims, any reference signs placed between brackets should not be construed as limiting the claims. The word "comprising" does not exclude the presence of elements or steps not listed in the claims. The word "a" or "an" preceding an element does not exclude the presence of a plurality of such elements. The embodiments of the invention may be implemented by means of hardware comprising several different elements and by means of a suitably programmed computer. In a unit claim enumerating several means, several of these means may be embodied by the same item of hardware. The use of the words first, second, and third etc. does not indicate any order. These words may be interpreted as names. The steps in the above embodiments should not be understood as limiting the order of execution unless otherwise specified.

Claims

1. A blockchain honeychain fraud defense system, comprising: Multiple consensus node systems, where any consensus node system includes: a redirector, a blockchain consensus node, and a honeychain consensus node; The blockchain consensus node is adapted to perform consensus verification on the received transaction set to obtain a first consensus verification result; receive a second consensus verification result broadcast by other blockchain consensus nodes through consensus communication, and determine whether consensus is reached based on the first consensus verification result and the second consensus verification result; if not, redirect the transaction set and the consensus result to a honeychain consensus node in the same consensus node system through a redirector; and determine whether to reselect a blockchain consensus node based on the consensus screening result; The honeychain consensus node is suitable for performing fraud detection based on the redirected transaction set and consensus results, receiving the detection results broadcast by other honeychain consensus nodes through consensus communication, and feeding back the consensus detection results to the blockchain consensus node through the redirector.

2. The system according to claim 1, wherein: The honeychain consensus node is further adapted to: use a private key to sign the transaction set and the consensus result to generate a request verification package, insert the request verification package into the local directed acyclic graph (DAG) honeychain log, broadcast the request verification package to other honeychain consensus nodes, so that other honeychain consensus nodes can insert the request verification package into their respective local directed acyclic graph (DAG) honeychain logs, verify the request verification package to obtain a verification package, and broadcast the verification package; Receive verification packages broadcast by other honeychain consensus nodes, determine the target transaction set to be tracked based on the received verification packages, perform transaction party tracking on the target transaction set, and notify the redirector to route the target transaction set corresponding to the transaction party to the honeychain consensus node.

3. The system according to claim 2, wherein: Each honeychain consensus node connects the first request verification package to the genesis package of the local directed acyclic graph (DAG) honeychain log; connects the Nth request verification package to the most recently connected verification package of the directed acyclic graph (DAG) honeychain log; if there is no verification package connected within the preset time period, the request verification package is directly connected to the most recently connected request verification package, where N ≥ 2.

4. The system according to claim 2 or 3, wherein: The honeychain consensus node is also suitable for: regularly broadcasting the incremental directed acyclic graph (DAG) honeychain log to other honeychain consensus nodes; and identifying whether the honeychain consensus node is controlled based on the incremental directed acyclic graph (DAG) honeychain log broadcast by other honeychain consensus nodes through consensus communication and the local directed acyclic graph (DAG) honeychain log.

5. The system according to claim 1 or 2, wherein: The honeychain consensus node is further adapted to: start the honeychain cube, execute the smart contract according to the target transaction set in the honeychain cube, and store the execution result in the cube transaction pool; perform consensus verification on the shadow block created by the honeychain consensus master node to obtain a third consensus verification result; Receive the fourth consensus verification results broadcast by other honeychain consensus nodes through consensus communication, and determine whether consensus is reached based on the third and fourth consensus verification results. If so, the consensus shadow block is chained to the shadow honeychain; If the preset isolation window period ends, determine whether there is any attack on the smart contract; If there is no attack, the honeychain container is closed to remove the isolation of the smart contract operation and the target transaction set, and the shadow blocks on the shadow honeychain are synchronized to the working blockchain; If there is an attack, the shadow honeylink is subjected to transaction rollback processing to roll back the shadow honeylink to its initial state.

6. The system according to claim 1 or 2, wherein: The blockchain consensus node is also suitable for: Count the number of blockchain consensus nodes that have not reached consensus; If the number of blockchain consensus nodes that have not reached consensus is less than or equal to the preset number, the transaction set will be uploaded to the working blockchain, and the consensus failure risk level will be determined based on the number of blockchain consensus nodes that have not reached consensus; The consensus failure risk level, transaction set and consensus results are redirected to the honeychain consensus node in the same consensus node system through the redirector.

7. The system according to claim 6, wherein: The blockchain consensus node is also suitable for: If the number of blockchain consensus nodes that have not reached consensus is greater than the preset number, the transaction set and consensus results will be redirected to the honeychain consensus node of the same consensus node system through the redirector.

8. A blockchain honeylink fraud prevention method, the method being applied to the blockchain honeylink fraud prevention system of any one of claims 1 to 7, the method comprising: The blockchain consensus node performs consensus verification on the received transaction set and obtains the first consensus verification result; Receive the second consensus verification result broadcast by other blockchain consensus nodes through consensus communication, and determine whether consensus is reached based on the first consensus verification result and the second consensus verification result; If not, the transaction set and consensus results are redirected to the honeychain consensus node of the same consensus node method through the redirector; Determine whether to reselect the blockchain consensus node based on the consensus screening results; The honeychain consensus node performs fraud detection based on the redirected transaction set and consensus results, and receives the detection results broadcast by other honeychain consensus nodes through consensus communication. The consensus identification processing results are fed back to the blockchain consensus node through the redirector.

9. A computing device comprising: A processor, a memory, a communication interface, and a communication bus, wherein the processor, the memory, and the communication interface communicate with each other via the communication bus; The memory is used to store at least one executable instruction, and the executable instruction enables the processor to perform operations corresponding to the honeylink deception defense method of the blockchain as described in claim 8.

10. A computer storage medium, wherein the storage medium stores at least one executable instruction, wherein the executable instruction causes a processor to perform operations corresponding to the honeylink fraud defense method for blockchain as described in claim 8.

Images