Consensus method of blockchain system, blockchain system, medium and program product

Abstract

The present application is applicable to the field of blockchain technology, and provides a consensus method, blockchain system, medium and program product of a blockchain system, wherein the method comprises: upon receiving a first transaction of a first account, obtaining account identification information of the first account in the blockchain system; obtaining a target transaction behavior score corresponding to the first account from a transaction behavior score set according to the account identification information, wherein the target transaction behavior score is used to indicate the probability of the first account attacking the blockchain system; upon satisfying a first condition, storing the first transaction in a transaction cache pool; performing a consensus operation on the transactions in the transaction cache pool to obtain a consensus result, wherein the consensus result indicates the execution order of transactions in the blockchain system. Only transactions of accounts whose transaction behavior scores satisfy the first condition are allowed to enter the transaction cache pool, thereby intercepting malicious users, reducing the number of abnormal transactions in the consensus result, and improving the consensus success rate.

Description

Technical Field

[0001] The present application belongs to the field of blockchain technology, and in particular relates to a consensus method of a blockchain system, a blockchain system, a medium, and a program product. Background Art

[0002] As a new distributed ledger technology, blockchain technology has created a secure distributed trust system, in which the asynchronous consensus mechanism is an important part of blockchain technology. The asynchronous consensus mechanism refers to the process in which multiple nodes in the blockchain system can sort the transaction set of each block in an asynchronous network and finally reach a consensus on the transaction execution results.

[0003] The current asynchronous consensus mechanism is usually that the nodes in the blockchain system package the transactions in their respective work pools into a transaction set and broadcast it so that the consensus nodes can reach a consensus on the transaction set. However, this asynchronous consensus mechanism cannot effectively defend against the challenge of distributed denial of service (DDoS) attacks. DDoS attacks exhaust network resources by sending a large number of invalid transaction requests, causing legitimate transactions to be delayed or discarded, seriously affecting the normal operation of the blockchain system, and also causing abnormal transactions to enter the consensus stage, greatly reducing the consensus success rate.

[0004] Therefore, how to improve the consensus success rate of the blockchain system has become a technical problem that needs to be solved urgently. Summary of the invention

[0005] The embodiments of the present application provide a consensus method, a blockchain system, a medium, and a program product of a blockchain system, which can solve the problem of how to improve the consensus success rate of the blockchain system.

[0006] In a first aspect, an embodiment of the present application provides a consensus method for a blockchain system, including:

[0007] Upon receiving a first transaction of a first account, obtaining account identification information of the first account in the blockchain system;

[0008] According to the account identification information, a target transaction behavior score corresponding to the first account is obtained from a transaction behavior score set, where the transaction behavior score set includes transaction behavior scores corresponding to different accounts in the blockchain system, respectively. The target transaction behavior score is used to indicate the probability of the first account attacking the blockchain system;

[0009] When the target transaction behavior score satisfies the first condition, the first transaction is stored in a transaction cache pool, where the transaction cache pool is used to store transactions in the blockchain system that have not been subjected to consensus operations;

[0010] Consensus operations are performed on transactions in the transaction cache pool to obtain consensus results, which are used to indicate the execution order of transactions in the blockchain system.

[0011] In a second aspect, an embodiment of the present application provides a blockchain system, the system comprising:

[0012] A scheduler, configured to receive a first transaction of a first account and send the first transaction to a validator;

[0013] The verifier is used to obtain the account identification information of the first account in the blockchain system when receiving the first transaction; send the account identification information to the scoring manager; receive the target transaction behavior score sent by the scoring manager; if the target transaction behavior score meets the first condition, store the first transaction in the transaction cache pool, and the transaction cache pool is used to store transactions in the blockchain system that have not been subjected to consensus operations;

[0014] The scoring manager is used to obtain a target transaction behavior score corresponding to the first account from a transaction behavior score set according to the account identification information, wherein the transaction behavior score set includes transaction behavior scores corresponding to different accounts in the blockchain system, and the target transaction behavior score is used to indicate the probability of the first account attacking the blockchain system; and send the target transaction behavior score to the verifier;

[0015] The consensus device is used to perform consensus operations on transactions in the transaction cache pool and obtain consensus results. The consensus results are used to indicate the execution order of transactions in the blockchain system.

[0016] In a third aspect, an embodiment of the present application provides a computer-readable storage medium, which stores a computer program. When the computer program is executed, it implements the consensus method of the blockchain system as described in any one of the first aspects.

[0017] In a fourth aspect, an embodiment of the present application provides a computer program product, which, when executed on a blockchain system, enables the blockchain system to execute the consensus method of the blockchain system described in any one of the first aspects above.

[0018] Compared with the prior art, the embodiment of the present application has the following beneficial effects: when receiving the first transaction of the first account, the target transaction behavior score of the first account is obtained from the different transaction behavior score sets storing the blockchain system to determine the probability of the account attacking the blockchain system. The first transaction is stored in the transaction cache pool only when the target transaction behavior score meets the first condition, and only the transactions in the transaction cache pool are subjected to consensus operations. In this way, in the consensus scenario, only the transactions of accounts whose transaction behavior scores meet the first condition are allowed to enter the transaction cache pool, so as to separate the transactions of malicious accounts that do not meet the first condition from the transactions of normal accounts, thereby intercepting abnormal transactions (i.e., invalid transactions) of malicious users. This allows subsequent consensus operations to be performed only on transactions of normal accounts, reducing the number of invalid transactions in the consensus results, improving the consensus success rate, and also improving the security of the consensus. In addition, there is no need to sign and verify each transaction, which reduces the signature verification overhead of the certificate. BRIEF DESCRIPTION OF THE DRAWINGS

[0019] In order to more clearly illustrate the technical solutions in the embodiments of the present application, the drawings required for use in the embodiments or the description of the prior art will be briefly introduced below. Obviously, the drawings described below are only some embodiments of the present application. For ordinary technicians in this field, other drawings can be obtained based on these drawings without paying any creative work.

[0020] Figure 1 This is a flowchart of a consensus method for a blockchain system provided by an embodiment of the present application;

[0021] Figure 2 It is a structural diagram of a blockchain system provided by an embodiment of the present application;

[0022] Figure 3 This is a schematic diagram of the process of transaction processing before consensus operation in an application scenario of an embodiment of the present application;

[0023] Figure 4 It is a schematic diagram of a process of verifying a transaction by a verifier in an application scenario of an embodiment of the present application;

[0024] Figure 5 It is a schematic diagram of a transaction packaging process in an application scenario of an embodiment of the present application;

[0025] Figure 6 It is a schematic diagram of a process for determining a transaction behavior score in an embodiment of the present application;

[0026] Figure 7 It is a flowchart of another consensus method of a blockchain system provided by the present application;

[0027] Figure 8It is a flow chart of feedback of transaction execution results in an application scenario of an embodiment of the present application. DETAILED DESCRIPTION

[0028] In the following description, specific details such as specific system structures, technologies, etc. are provided for the purpose of illustration rather than limitation, so as to provide a thorough understanding of the embodiments of the present application. However, it should be clear to those skilled in the art that the present application may also be implemented in other embodiments without these specific details. In other cases, detailed descriptions of well-known systems, devices, circuits, and methods are omitted to prevent unnecessary details from obstructing the description of the present application.

[0029] It should be understood that when used in the present specification and the appended claims, the term "comprising" indicates the presence of described features, wholes, steps, operations, elements and / or components, but does not exclude the presence or addition of one or more other features, wholes, steps, operations, elements, components and / or combinations thereof.

[0030] It should also be understood that the term “and / or” used in the specification and appended claims refers to any and all possible combinations of one or more of the associated listed items, and includes these combinations.

[0031] As used in the specification and appended claims of this application, the term "if" can be interpreted as "when" or "uponce" or "in response to determining" or "in response to detecting", depending on the context. Similarly, the phrase "if it is determined" or "if [described condition or event] is detected" can be interpreted as meaning "uponce it is determined" or "in response to determining" or "uponce [described condition or event] is detected" or "in response to detecting [described condition or event]", depending on the context.

[0032] In addition, in the description of the present application specification and the appended claims, the terms "first", "second", "third", etc. are only used to distinguish the descriptions and cannot be understood as indicating or implying relative importance.

[0033] References to "one embodiment" or "some embodiments" etc. described in the specification of this application mean that one or more embodiments of the present application include specific features, structures or characteristics described in conjunction with the embodiment. Therefore, the statements "in one embodiment", "in some embodiments", "in some other embodiments", "in some other embodiments", etc. that appear in different places in this specification do not necessarily refer to the same embodiment, but mean "one or more but not all embodiments", unless otherwise specifically emphasized in other ways. The terms "including", "comprising", "having" and their variations all mean "including but not limited to", unless otherwise specifically emphasized in other ways.

[0034] First, let’s explain the professional data involved in this application:

[0035] Transaction: refers to a data exchange or operation in the blockchain network. It generally includes the account address and digital signature of the initiator of the transaction and the account address of the recipient of the transaction.

[0036] Batch: A collection of at least one transaction, also called a transaction set.

[0037] Public Blockchain: A public blockchain is a completely open blockchain where anyone can participate, conduct transactions and view all transaction records.

[0038] Consortium Blockchain: A consortium blockchain is a blockchain between a public chain and a private chain, usually maintained by a group of pre-selected nodes.

[0039] Layer 1 chain: Layer 1 chain refers to the basic layer of the blockchain network, which is responsible for handling core functions such as transaction verification, consensus mechanism and block generation.

[0040] Checkpoint: It is a specific status mark or record point on the blockchain, which is usually recognized and accepted by most nodes in the blockchain network. By setting a checkpoint, the historical record of the blockchain can be locked to prevent attackers from reorganizing the blockchain or creating forks by controlling a large amount of computing power.

[0041] Quorum: In some consensus mechanisms of blockchain systems, the minimum number of nodes that need to be reached to participate in consensus in order to reach an effective consensus. Quorum is the minimum number of nodes that need to be reached.

[0042] Watermark: An indicator used to measure node performance.

[0043] View change: refers to the process of switching from one current view to another in the distributed network of the blockchain system. Each view is usually led by a specific leader (Primary) node, which is responsible for collecting transactions, packaging blocks and broadcasting them to other nodes for verification. It can also be understood as the process of re-electing the Primary node in the blockchain system after consensus fails.

[0044] Transactions per second (tps): tps is a measure of a system's ability to process transactions.

[0045] Distributed Denial of Service (DDoS): Attackers control a large number of malicious nodes or use infected devices to initiate a large number of repeated abnormal transactions (invalid transactions) to specific nodes in the blockchain network or the entire network in order to exhaust the resources of the nodes (such as computing power or network bandwidth, etc.), thereby making it impossible for the nodes to participate in the consensus process of the blockchain or provide services to legitimate users.

[0046] Semi-synchronous consensus mechanism: As a blockchain consensus protocol based on the synchronous consensus mechanism and the asynchronous consensus mechanism, it attempts to find a balance between synchronization and asynchrony, ensuring a certain degree of synchronization to improve efficiency, and allowing a certain degree of asynchrony to adapt to the uncertainty of the actual network environment. In the synchronous consensus mechanism, all nodes must complete specific operations within a certain time. This mechanism can operate efficiently when the network latency is low and the node performance is stable, but in the actual environment, network latency and node failure may cause system performance to degrade or even stagnate. The asynchronous consensus mechanism allows nodes to complete operations within an uncertain time (that is, in the case of an asynchronous network), with high fault tolerance, but there may be a situation where consensus cannot be reached for a long time. The semi-synchronous consensus mechanism is usually based on the partial synchronization assumption, that is, there is a known upper limit to the message delivery time in the network, but this upper limit may vary in different situations. This means that in most cases, messages can be delivered in a relatively short time, but in some special cases, longer delays may occur.

[0047] Byzantine Fault Tolerance: A consensus mechanism that allows the blockchain system to reach a consensus even when some nodes fail or act maliciously.

[0048] In the field of blockchain technology, most consortium chains usually use semi-synchronous consensus mechanisms to reach consensus due to the small size of nodes. A typical example is the partially synchronous Practical Byzantine Fault Tolerance (PBFT) consensus mechanism, whose main process is transaction collection and broadcasting -> block consensus (only determines the execution order of transactions, but does not produce execution results) -> transaction execution -> checkpoint after block placement (to prevent forks). This consensus mechanism allows consensus and execution to be completed in parallel like a pipeline instead of serial execution, greatly improving the performance of the consortium chain.

[0049] However, this consensus mechanism is not completely applicable to public chains, because the node scale of public chains is large and the network conditions of nodes are unknown. Assuming that the performance of some verification nodes is poor, due to the barrel effect, the partially synchronized PBFT consensus mechanism requires a quorum of nodes to participate in the consensus. If some nodes are below the watermark, the timeout mechanism will be triggered and a viewchange will be required. After the viewchange is completed, the blockchain system will return to normal. However, viewchange is a very time-consuming operation. During the viewchange, the cluster is in an abnormal state and will not be able to package transactions, which will cause the system's tps to drop to 0. In order to improve the stability of the blockchain, it is necessary to avoid viewchange operations as much as possible. Therefore, in the current blockchain technology field, many public chains are gradually adopting asynchronous consensus mechanisms to replace traditional semi-synchronous consensus mechanisms for the performance of layer 1 chains.

[0050] The benefit of the asynchronous consensus mechanism is that even in an asynchronous network (i.e., some nodes have poor network conditions), consensus can be reached normally without viewchange. There are usually three ways to implement asynchronous consensus mechanisms in blockchains. One is to use the efficient Byzantine fault-tolerant consensus and memory pool protocol based on directed acyclic graphs (DAG) (DAG-based Asynchronous Consensus using Narwhal and Tusk) to achieve asynchronous consensus in blockchain systems.

[0051] This implementation method collects transactions in a worker pool outside the worker node and packages multiple transactions into a batch (this process is also called Generate batch). Then the worker pool pushes the batch to the Primary node for consensus. However, this implementation method only broadcasts batches but not transactions between worker pools. Therefore, if there is a DDOS attack, the client sends the same transaction to different worker pools. When generating batches, different worker pools will package the same transaction, resulting in a large number of repeated invalid transactions during execution, resulting in low consensus efficiency.

[0052] The other is to use the Asynchronous Consensus Protocol Adaptation with Quorum Store (Aptos) to achieve asynchronous consensus in the blockchain system. The Aptos solution adapts the asynchronous consensus protocol by adding a Quorum Store component. This component serves as a bridge between the local transaction pool (txpool) and the consensus node. Its function is similar to that of the worker pool. However, when it is attacked by DDoS, different components will package the same transaction. This solution does not prevent DDoS attacks on consensus.

[0053] Another is Sui's Asynchronous Consensus Implementation based on Delegated Proof of Stake (DPoS) Consensus Mechanism (Sui Scheme) to achieve asynchronous consensus in blockchain systems. This scheme requires a series of validity and security checks to be performed on the validator and signed before each transaction enters consensus. The validator returns the signed transaction to the client. The client collects responses from a group of validators that account for at least quorum equity (consensus security threshold, such as 2 / 3) to form a certificate. Although this scheme can verify transactions before consensus, it requires the generation and verification of a large number of signatures, which greatly increases the latency of a single transaction and also increases the signature verification overhead of the certificate, resulting in poor overall performance.

[0054] In response to the above problems, the embodiments of the present application provide a consensus method, blockchain system, medium and program product for a blockchain system. The transaction behavior score of the account is obtained from the transaction behavior score set, and only the transactions of accounts that have not attempted to attack the blockchain system (that is, accounts whose transaction behavior scores meet the first condition) are allowed to enter the public transaction cache pool. Accounts that do not meet the first scoring condition are identified as malicious accounts, and the transactions of the account are not allowed to enter the transaction cache pool, thereby intercepting abnormal transactions (also called invalid transactions or repeated transactions) of malicious users. This allows consensus operations to be performed only on transactions of normal accounts in the future, reducing the number of abnormal transactions in the consensus results, improving the success rate of consensus, and also improving the security of consensus. In addition, there is no need to sign and verify each transaction, which reduces the signature verification overhead of the certificate.

[0055] The consensus method of the blockchain system in the embodiment of the present application is described in detail below. Figure 1: is a flowchart of a consensus method of a blockchain system in an embodiment of the present application, the method comprising the following steps:

[0056] Step S101, when a first transaction of a first account is received, obtaining account identification information of the first account in the blockchain system.

[0057] It should be noted that the consensus method of the blockchain system of this application is executed by the blockchain system, such as Figure 2 As shown, the blockchain system includes a transaction cache pool (tx store), a scheduler (Coordinator), a verifier (Verifier), a consensus (Consensus), a scoring manager and at least one client, and the at least one client includes a first client corresponding to the first account.

[0058] The client can be a mobile phone, tablet computer, desktop computer, laptop computer, ultra-mobile personal computer (ultra-mobile personal computer, UMPC), netbook, personal digital assistant (personal digital assistant, PDA) and other electronic devices in the blockchain system. The scheduler, verifier, consensus device and scoring manager can be a server or virtual machine (for example, Ethereum Virtual Machine (EVM)) in the blockchain system. It can be understood that the scheduler, verifier, consensus device and scoring manager can be concentrated on the same server or virtual machine, or can be respectively set on different servers or virtual machines. The transaction cache pool is also called a local transaction cache pool, which can be a storage device such as a hard disk, a solid-state drive or a memory database in the blockchain system. In the embodiment of the present application, the specific types of the client, scheduler, verifier, consensus device, scoring manager and transaction cache pool are not limited.

[0059] The first transaction includes the account identification information of the first account in the blockchain system. The account identification information included in the first transaction may be the account address of the first account or the digital signature of the first account, or other self-set information, which is not specifically limited in the embodiments of the present application. The blockchain system may receive the first transaction sent by the first account through the first client through the scheduler, and send the first transaction to the verifier, and extract the account identification information in the first transaction through the verifier.

[0060] Step S102: acquiring a target transaction behavior score corresponding to the first account from a transaction behavior score set according to the account identification information.

[0061] The blockchain system can record and manage the transaction behavior scores corresponding to each account in the blockchain system over time through the score manager, thereby obtaining a transaction behavior score set. The transaction behavior score set includes the transaction behavior scores corresponding to different accounts in the blockchain system, and the target transaction behavior score is used to indicate the probability of the first account attacking the blockchain system. The account identification information is used in the transaction behavior score set to indicate the account in the blockchain system.

[0062] Specifically, taking the first account as an example, the process of recording and managing the corresponding transaction behavior score of the blockchain system through the scoring manager is explained. First, the blockchain system sets a reference transaction behavior score for the first account through the scoring manager as the initial transaction behavior score corresponding to the first account, completing the initial recording of the transaction behavior score of the first account.

[0063] At first, if the reference transaction behavior score meets the first condition, the blockchain system will store the transaction of the first account in the transaction cache pool through the verifier so as to perform consensus operation on the transaction of the first account. After the consensus operation, the transaction of the first account will exist in the transaction set and be saved in the block. The blockchain system executes each transaction stored in the block through the executor. In this way, the blockchain system can determine the abnormal transactions that have been executed under the first account through the executor, and then determine whether the total number of abnormal transactions of the first account in the historical time is high and whether the time interval for abnormal transactions to enter the consensus is short based on the number of abnormal transactions executed under the first account and the time when the abnormal transactions are saved in the block (the time is the block generation time of the block) through the scoring manager. If the total number is high or the time interval is short, it means that the first account always submits abnormal transactions to the blockchain system, which may be a malicious account attacking the blockchain system.

[0064] At this time, the blockchain system adjusts the transaction behavior score of the first account downward based on the reference transaction behavior score through the score manager, completes the update of the transaction behavior score of the first account, and manages the transaction behavior score corresponding to the first account in the transaction behavior score set. The specific process of the blockchain system determining the transaction behavior score of the account through the score manager is introduced in the subsequent embodiments.

[0065] In this way, the blockchain system will send the account identification information to the scoring manager through the verifier, and then the blockchain system will find the transaction behavior score corresponding to the account identification information of the first account from the transaction behavior score set through the scoring manager and return it to the verifier, thereby obtaining the target transaction behavior score.

[0066] It should be noted that in the present application, the acquisition of the target transaction behavior score is based on the transaction passing the basic verification, that is, the first transaction itself needs to be verified to ensure that the content of the first transaction complies with the rules of the blockchain and the security requirements of the network, and the first transaction is credible.

[0067] Exemplarily, the blockchain system performs a basic verification operation on the first transaction through a verifier, and the basic verification operation includes at least one of verifying the transaction signature, verifying the transaction format, or verifying the transaction content; when the first transaction passes the basic verification, the target transaction behavior score corresponding to the first account is obtained from the transaction behavior score set according to the account identification information; when the first transaction fails to pass the basic verification, transaction abnormality information is generated, and the transaction abnormality information is sent to the client terminal corresponding to the first account to remind the user that the transaction has not passed the verification. In this way, before the consensus operation is performed on the transactions in the transaction cache pool, the account is double-verified based on the basic verification operation of the transaction and the transaction behavior score corresponding to the account, malicious accounts are screened out as much as possible, and the security of the blockchain system consensus is improved.

[0068] Exemplarily, the transaction signature verification can be that the blockchain system calculates the hash value of the received transaction through the verifier, and compares it with the hash value (i.e., digital signature) stored in the transaction to ensure that the transaction has not been tampered with during transmission. The transaction format verification can be that the blockchain system checks whether the format of the transaction complies with the protocol rules of the blockchain through the verifier. The transaction content verification can be that the blockchain system checks whether the fields of the transaction are complete and whether they comply with the protocol rules of the blockchain through the verifier, etc., which can be set according to the needs, and the embodiments of this application do not make specific restrictions.

[0069] For example, see Figure 3 as well as Figure 4 , the user of the first account sends a transaction (an example of the first transaction) to the scheduler through the first client. After receiving the transaction, the scheduler assigns it to the verifier for transaction verification (including basic verification and verification of whether the transaction behavior score meets the first condition). If the verification result of the transaction is verified, the verifier will send the transaction to the transaction cache pool for caching. When the verifier verifies the received transaction, it will first perform basic verification operations on the transaction, including verification of transaction legitimacy, verification of transaction signature, verification of transaction format, and verification of transaction content. If the transaction fails the basic verification (that is, the verification fails), the verifier will generate transaction exception information and send the transaction exception information to the first client terminal to remind the user of the first account that the transaction is an abnormal transaction.

[0070] If the transaction passes the basic verification, the verifier will allow the transaction to be subsequently verified. Specifically, the verifier will send the transaction initiator information (that is, account identification information) in the transaction to the scoring manager. After receiving the transaction initiator information, the scoring manager will find the transaction behavior score corresponding to the account of the account identification information from the transaction behavior score set stored in itself and send it to the verifier. The verifier will compare the transaction behavior score with the scoring threshold. If the transaction behavior score is less than the scoring threshold, it means that the transaction behavior score verification of the first account has failed, the probability of the first account attacking the blockchain system is high, and the first account is a malicious account. At this time, the validator will restrict the transactions initiated by the first account within a certain period of time (that is, within the preset time period) from entering the transaction cache pool. On the contrary, it means that the first account is a normal account of the blockchain system, and the verification result of the transaction is determined to be passed.

[0071] Step S103: When the target transaction behavior score satisfies the first condition, the first transaction is stored in the transaction cache pool.

[0072] The transaction buffer pool is used to store transactions in the blockchain system that have not been subjected to consensus operations. It should be noted that the accounts corresponding to the transactions in the transaction buffer pool that have not been subjected to consensus operations are all accounts whose transaction behavior scores meet the first condition. The first condition indicates that the probability of the account attacking the blockchain system is small, and the account is a normal account in the blockchain system. Optionally, the first condition may be that the transaction behavior score corresponding to the account is greater than or equal to the score threshold. The score threshold can be set by itself, and the embodiment of the present application does not impose specific restrictions. After the blockchain system determines through the verifier that the target transaction behavior score meets the first condition, it will allow the verifier to store the first transaction in the transaction buffer pool for subsequent consensus operations.

[0073] It should be noted that when the blockchain system determines through the verifier that the target transaction behavior score does not meet the first condition, the verifier will intercept the transactions of the first account within a period of time to prevent the transactions of the first account from being stored in the transaction cache pool. In a possible implementation, when the target transaction behavior score does not meet the first condition, the method also includes: when the transaction of the first account is received within a preset time period, the transaction of the first account is not stored in the transaction cache pool. The preset time period can be set by yourself, for example, one hour or half an hour. Compared with the traditional Aptos solution, the method in the embodiment of the present application determines whether to store the transactions of the account in the transaction cache pool by determining whether the transaction behavior score of the account meets the first condition. It can defend against DDoS attacks launched by malicious accounts (or malicious clients) against different nodes in the blockchain system before performing consensus operations, thereby improving the success rate and security of consensus.

[0074] Step S104, performing consensus operations on the transactions in the transaction cache pool to obtain a consensus result.

[0075] The consensus result is used to indicate the execution order of transactions in the blockchain system. The execution order is the order in which the executor in the blockchain system executes the transactions in the transaction cache pool after consensus. The process of the blockchain system performing consensus operations on at least one transaction in the transaction cache pool may include four parts: transaction packaging, transaction sequencing, consensus algorithm execution, and block confirmation and broadcasting.

[0076] For the transaction packaging part, the blockchain system extracts at least one transaction from the transaction cache pool through the working node and packages the extracted transactions into a transaction set. For the transaction sequencing part, the blockchain system determines the order of transactions in the transaction set (for example, the timestamps in the transaction are from early to late or the fees in the transaction are from large to small) and the sorting algorithm (for example, the distributed sorting algorithm or the bubble sorting algorithm) through the consensus machine, and then determines the order of transactions in the transaction set (the sorting order is the execution order).

[0077] For the consensus algorithm execution part, the blockchain will propose a block after determining the execution order of transactions in the transaction set through the consensus machine, store the transaction set in the block, and store the block on the chain. At this time, the blockchain system will select a consensus algorithm, such as Proof of Work (PoW), Proof of Stake (PoS) or Practical Byzantine Fault Tolerance (PBFT), etc., and control other consensus machines to execute the consensus algorithm to determine whether other consensus machines recognize the block storing the transaction set, that is, to determine whether the block is valid.

[0078] As for block confirmation and broadcasting, when the blockchain system finds a valid block through any of its own nodes, it will broadcast the block to other nodes through the node. After receiving the block, other nodes will verify the block. If the verification is successful, the node will add the block to its local blockchain, indicating that the transaction in the block has been confirmed. As more nodes in the blockchain system confirm and add the block, the block is propagated and synchronized in the entire blockchain network.

[0079] In order to improve the reliability of the transaction set during the consensus operation and thus improve the security of the blockchain system consensus, the transaction set can also be verified after being packaged. For example, continue to refer to Figure 2The blockchain system may include working nodes and multiple validators. The blockchain system extracts batch transactions from the transaction cache pool through the working nodes and packages them into transaction sets, and broadcasts the transaction sets to multiple validators in the blockchain system. The validators will perform signature verification on the received transaction sets to generate the availability certificate of the transaction sets. The blockchain system then extracts the transaction sets carrying the availability certificate from the working nodes through the consensus machine for consensus operations.

[0080] Exemplarily, the blockchain system can also package at least one transaction in the transaction cache pool through cooperation between the working nodes and the scheduler, see Figure 5 The schematic diagram of the transaction packaging process in an application scenario shown in the figure, the blockchain sends a batch generation request (Generate Batch Request) to the scheduler through the working node, the scheduler extracts batch transactions from the transaction cache pool and packages them into a transaction set (Get Batch), and returns the transaction set obtained from the transaction cache pool to the working node, thus completing the transaction packaging and obtaining the transaction set.

[0081] In an embodiment of the present application, when the first transaction of the first account is received, the target transaction behavior score of the first account is obtained from the different transaction behavior score sets stored in the blockchain system to determine the probability of the account attacking the blockchain system. The first transaction is stored in the transaction cache pool only when the target transaction behavior score meets the first condition, and only the transactions in the transaction cache pool are subjected to consensus operations. In this way, in a consensus scenario, only transactions of accounts whose transaction behavior scores meet the first condition are allowed to enter the transaction cache pool, so as to separate transactions of malicious accounts that do not meet the first condition from transactions of normal accounts, thereby intercepting abnormal transactions (i.e., invalid transactions) of malicious users. This allows subsequent consensus operations to be performed only on transactions of normal accounts, reducing the number of invalid transactions in the consensus results, improving the consensus success rate, and improving the security of the consensus. In addition, there is no need to sign and verify each transaction, which reduces the signature verification overhead of the certificate.

[0082] Figure 6 is a schematic diagram of a process for determining a transaction behavior score in an embodiment of the present application, such as Figure 6 As shown, before obtaining the target transaction behavior score corresponding to the first account from the transaction behavior score set according to the account identification information, the consensus method of the blockchain system of the embodiment of the present application also includes the following steps S201 to S206:

[0083] Step S201: Determine at least one target block corresponding to a first account from at least one executed block.

[0084] The target block includes the abnormal transaction initiated by the first account, and the executed block includes at least one on-chain transaction. The on-chain transaction has been consensus-operated by the blockchain system in the transaction cache pool and stored in the blockchain.

[0085] In the consensus scenario of the blockchain system, after the blockchain system obtains the block through consensus through the consensus machine, the consensus result will be sent to the executor. The consensus result includes the execution order of transactions in the transaction set and the commit information (commitInfo), which at least includes the valid blocks confirmed by the consensus machine and the executable transaction set in the block. The executor can determine the executable transaction set in each block of the blockchain system according to the commit information in the consensus result, and execute the transactions in the transaction set according to the execution order corresponding to the transaction set to obtain the execution result. The execution result includes the block generation time, block height, and the total number of abnormal transactions of the account in the block and the account identification information, where the block height is the number of the generated block in the blockchain system. The execution result is sent to the consensus machine by the executor. The blockchain system can clearly identify the executed block by receiving the block height and block generation time in the execution result through the consensus machine, and can determine the target block including the abnormal transaction initiated by the first account from the executed block through the total number of abnormal transactions and account identification information of the account in the execution result.

[0086] Step S202: determine the target block whose block height is within the preset block height window as the scoring block.

[0087] The preset block height window H can be set by itself, such as H=100 or H=2, etc., and the embodiments of the present application do not make specific restrictions. Exemplarily, taking H=100, the block height of the executed block is 1 to 200 (recorded as block 1 to block 200), and the target blocks are block 58, block 65, block 101 and block 103 as an example, the blockchain system starts to slide the preset block height window from block 1, and when the preset block height window slides to block 1 to block 100, the scoring blocks in the target block are block 58 and block 65, and when the preset block height window slides to block 50 to block 150, the scoring blocks are block 65, block 101 and block 103.

[0088] Step S203: determine a target block whose block generation time is earlier than the block generation time of the scoring block and is adjacent to the scoring block as a first target block.

[0089] The blockchain system records the determined target blocks in the order of block generation time from early to late through the scoring manager every time it receives the execution result, that is, it sorts the target blocks in the order of block generation time from early to late, and then determines the target block whose block generation time is earlier than the scoring block and adjacent to the scoring block as the first target block. Continuing to refer to the above example, the result obtained after sorting in the order of block generation time from early to late is block 58->block 65->block 101->block 103. If the scoring block is block 65, the first target block is block 58. If the scoring block is block 103, the first target block is block 101.

[0090] Step S204: determining the time interval corresponding to the scoring block based on the time difference between the block generation time of the first target block and the scoring block.

[0091] The blockchain system determines the time difference between the block generation time of the first target block and the scoring block as the time interval corresponding to the scoring block through the scoring manager. For example, the scoring block is block 65, whose block generation time is 14:58, and the block generation time of block 58 is 14:56, then the time interval of block 65 is 2 minutes (min).

[0092] Step S205, determining a target transaction behavior score corresponding to the first account according to the reference transaction behavior score corresponding to the first account, the time interval corresponding to the scoring block, and the total number of abnormal transactions of the first account in the scoring block.

[0093] The blockchain system sets a reference transaction behavior score for the first account through the scoring manager, and its specific value can be set by itself. The embodiment of this application does not make specific restrictions. In one example, if there is a scoring block in the preset block height window, the blockchain system calculates the ratio between the total number of abnormal transactions of the first account in the scoring block and the time interval through the scoring manager. This ratio can characterize the frequency of abnormal transactions initiated by the first account in the preset block height window, and then the difference between the reference transaction behavior score and the ratio is determined as the target behavior transaction score. The score can be used to measure the gap between the frequency of abnormal transactions initiated by the first account in the preset block height window and the expectation. If the gap is smaller (that is, less than the scoring threshold), it means that the probability of the first account attacking the blockchain system is greater.

[0094] If there are multiple scoring blocks within the preset block height window, the ratio between the total number of abnormal transactions of the first account and the time interval in each scoring block is added, and the difference between the reference transaction behavior score and the added ratio is determined as the target behavior transaction score.

[0095] It is understandable that if a certain scoring block no longer meets the condition that the block height is within the preset block height window after the preset block height window slides, the ratio between the total number of abnormal transactions of the first account in the scoring block and the time interval calculated previously will be deleted from the target transaction behavior score, so as to eliminate the influence of expired abnormal transactions on the behavior score of the account. If only one target block is determined from the executed blocks, the reference transaction behavior score is determined as the target transaction behavior score.

[0096] In another example, the blockchain system further determines, through the scoring manager, a first weighted average of the time intervals corresponding to each scoring block in a preset block height window, and determines a second weighted average of the total number of abnormal transactions of the first account in each scoring block, and then determines a ratio between the first weighted average and the second weighted average, and determines the difference between the reference transaction behavior score and the ratio as the target behavior transaction score.

[0097] In another example, considering that clients attacking a blockchain system often initiate a large number of abnormal transactions to the blockchain system in a short period of time, in order to improve the reliability of transaction behavior scores, when the blockchain system determines the transaction behavior score corresponding to an account through a scoring manager, a weight coefficient can be introduced to enhance the impact of the number of abnormal transactions on the transaction behavior score, and a time decay coefficient can be introduced to reduce the impact of longer time intervals on the transaction behavior score.

[0098] Exemplarily, the ratio between the total number of abnormal transactions of the first account in the scoring block and the time interval may be determined by the following formula 1:

[0099]

[0100] Among them, α is the weight coefficient, β is the time decay coefficient, t is the time interval corresponding to the scoring block, and its unit is minutes, n is the total number of abnormal transactions of the first account in the scoring block, and IF is the ratio between the total number of abnormal transactions of the first account in the scoring block to be determined and the time interval, which is also called the attacker sub-score corresponding to the scoring block or the impact factor corresponding to the scoring block. Correspondingly, the target transaction behavior score corresponding to the first account in the preset block height window can be determined by the following formula 2:

[0101]

[0102] in, R is the transaction behavior score, R o Score the reference transaction behavior, IF i is the attacker sub-score corresponding to the ith scoring block in the preset block height window, n i is the total number of abnormal transactions in the i-th scoring block within the preset block height window, ti is the time interval corresponding to the i-th scoring block in the preset block height window, and m is the total number of scoring blocks in the preset block height window.

[0103] In another example, a large amount of sample data marked as malicious accounts and normal accounts can also be collected. These sample data may include abnormal transactions of accounts, the time when abnormal transactions enter blocks after consensus (that is, the block generation time of blocks), and the actual transaction behavior score of accounts. The sample data is input into a suitable supervised learning algorithm, such as a decision tree, random forest, or support vector machine, to establish a prediction model. Then, the time interval corresponding to the scoring block, the total number of abnormal transactions of the first account in the scoring block, and the reference transaction behavior score are input into the prediction model to evaluate the target transaction behavior score.

[0104] Considering that attackers will continue to attack the blockchain system with abnormal transactions for a long time, a preset time window can also be introduced into the calculation of the transaction behavior score to determine the situation in which an account in the blockchain system (through the client) initiates abnormal transactions within a specific time period, further improving the accuracy of the transaction behavior score indicating the probability of an account attacking the blockchain system. In one possible implementation, the target transaction behavior score corresponding to the first account is determined based on the reference transaction behavior score corresponding to the first account, the time interval corresponding to the scoring block, and the total number of abnormal transactions of the first account in the scoring block, including:

[0105] In the preset block height window, the attacker score of the first account in the preset block height window is determined according to the time interval corresponding to the scoring block and the total number of abnormal transactions of the first account in the scoring block;

[0106] Within a preset time window, the target transaction behavior score is obtained according to the sum of the attacker's scores, and the end time of the preset time window is earlier than the time when the blockchain system receives the first transaction.

[0107] In the embodiment of the present application, the end time of the preset time window is later than the block generation time of the last executed block in the preset block height window. That is to say, the preset time window may include multiple preset block height windows.

[0108] The blockchain system can determine the ratio between the total number of abnormal transactions of the first account in each scoring block in the preset block height window and the time interval through the process in the above example for each preset block height window in the preset time window through the scoring manager, and then determine the attacker score of the first account in the preset block height window based on the difference between the reference transaction behavior score in the preset block height window and the ratio. Then, within the preset time window, determine the sum of the attacker scores of the first account in each preset block height window, obtain the sum result, and use the sum result as the target transaction behavior score.

[0109] In the above technical solution, when determining the transaction behavior score corresponding to the first account, the sum of the attacker scores of the account within the preset time window is taken into account, and the attacker score is determined based on the time interval corresponding to the scoring block of the account within the preset block height window and the total number of abnormal transactions of the first account in the scoring block. The attacker score can reflect the activity of the first account in initiating abnormal transactions to the blockchain system within the preset block height window, and then the sum of the results can aggregate the activity of the first account in initiating abnormal transactions in different time periods within a period of time (the time period corresponding to the preset block height window), comprehensively reflecting the trend of the first account initiating abnormal transactions to the blockchain system from a long time span, and improving the reliability of the transaction behavior score.

[0110] In a possible implementation, determining the attacker score of the first account in the set block height window according to the time interval corresponding to the scoring block and the total number of abnormal transactions of the first account in the scoring block includes:

[0111] Determine the attacker sub-score corresponding to the scoring block according to the time interval corresponding to the scoring block and the total number of abnormal transactions of the first account in the scoring block;

[0112] In the preset block height window, the attacker's impact score in the preset block height window is obtained based on the sum of the attacker's sub-scores;

[0113] The difference between the reference transaction behavior score and the attacker impact score is determined as the attacker score.

[0114] The blockchain system determines the ratio between the total number of abnormal transactions of the first account in each scoring block within the preset block height window and the time interval through the scoring manager based on the process in the above example. This ratio is the attacker sub-score, and the attacker sub-scores corresponding to each scoring block in the preset block height window are added together, and the result of the addition is used as the attacker impact score.

[0115] In the above technical solution, the attacker sub-score is determined based on the time interval corresponding to the scoring block and the total number of abnormal transactions of the first account in the scoring block, which can reflect the threat level of the account to the blockchain system caused by the abnormal transaction initiated by the account at a certain time. When determining the attacker score of an account, the sum of the attacker sub-scores corresponding to each scoring block in the set block height window is taken into account, and the threat level of each account to the blockchain system in the set block height window can be synthesized to obtain a reliable attacker score.

[0116] In a possible implementation, determining the attacker sub-score corresponding to the scoring block according to the time interval corresponding to the scoring block and the total number of abnormal transactions in the scoring block includes:

[0117] Get the time decay coefficient and weight coefficient corresponding to the first account;

[0118] Determine the scoring time corresponding to the first account according to the power exponent between the time decay coefficient and the time interval;

[0119] Determine the product of the total number of abnormal transactions and the weight coefficient;

[0120] According to the proportional relationship between the product result and the scoring time, the attacker sub-score corresponding to the scoring block is determined.

[0121] The blockchain system determines the attacker sub-score corresponding to each scoring block in the set block height window through the scoring manager based on the above formula 1. Correspondingly, in the set block height window, the attacker score of the first account can be determined based on the above formula 2, except that at this time, R in formula 2 represents the attacker score of the account in the set block height window.

[0122] In the above technical solution, the time decay coefficient and weight coefficient corresponding to the first account are introduced. After determining the power exponent between the time decay coefficient and the time interval and the product result between the total number of abnormal transactions and the weight coefficient, the proportional relationship between the product result and the scoring time is determined as the attacker sub-score corresponding to the scoring block. Considering the decay of time when the first account initiates abnormal transactions at different times within the time period corresponding to the preset block height window and the proportion of the total number of abnormal transactions in the attacker sub-score each time an abnormal transaction is initiated, and considering the characteristics that the client attacking the blockchain system often initiates a large number of abnormal transactions to the blockchain system in a short period of time, the reliability of the attacker sub-score is improved, and then the accuracy of intercepting abnormal transactions of malicious accounts is improved in subsequent consensus operations, thereby improving the security of the blockchain system consensus.

[0123] In one application scenario, the preset block height window H=100, i.e., the latest 100 block heights. The reference transaction behavior score of the first account is R0=100, the score threshold is Rmin=20, the preset time window is T, and the block height of the executed block is 1 to 100. For abnormal transactions within the preset time window T, the attacker sub-score IF is shown in Formula 1, and the determination of the attacker score is shown in Formula 2.

[0124] Assume that there are three scoring blocks (blocks 1 to 3) in a preset block height window H within a preset time window T: n1=50 abnormal transactions occurred in the first scoring block, and the corresponding time interval t1′=0.06 minutes for this block. n2=80 abnormal transactions occurred in the second scoring block, and the corresponding time interval t2′=0.0625 minutes for this block. n2=60 abnormal transactions occurred in the third scoring block, and the corresponding time interval t3′=0.133 minutes for this block.

[0125] First, calculate the attacker sub-score corresponding to each scoring block:

[0126]

[0127] Then, the attacker score of the first account is determined as:

[0128]

[0129] The blockchain system continues to execute the blocks generated by consensus through the executor. When the total block height of the executed blocks reaches 101, the preset block height window is lowered. At this time, the height of the blocks in the preset block height window is 2 to 101. At this time, there are still three scoring blocks (blocks 2, 3 and 101) in the preset block height window H. 101 instead of IF 1 Get the attacker score of the first account after the downward adjustment. At this time, the attacker score of the first account is 100-IF 101 -IF 2 -IF 3 If there are only two preset block height windows within the preset time window T, the target transaction behavior score of the first account is the sum of the attacker scores of the first account within the two preset block height windows, that is, 200-2 (IF 2 +IF 3 )-IF 1 -IF 101 .

[0130] In order to improve the reliability of the transaction behavior score, a suitable weight system and time decay coefficient can be obtained through machine learning. In a possible implementation, before obtaining the time decay coefficient and weight coefficient corresponding to the first account, the method also includes:

[0131] Obtain a transaction data set, which includes the total number of abnormal transactions, time intervals, and sub-scores of real attackers corresponding to the sample scoring block;

[0132] The total number of abnormal transactions and time intervals corresponding to the sample scoring block are input into the sample machine learning model to obtain the predicted attacker sub-score;

[0133] determining a target loss function based on the difference between the predicted attacker sub-score and the actual attacker sub-score;

[0134] In the i-th iteration training process, the i+1-th sample machine learning model is obtained based on the i-th target loss function training, where i is a positive integer;

[0135] When the i+1th predicted attacker sub-score output by the i+1th sample machine learning model meets the second condition, the weight coefficient and time decay coefficient in the i-th target loss function are used as the weight coefficient and time decay coefficient corresponding to the first account, respectively.

[0136] In this implementation, there are multiple sample scoring blocks in the transaction data set, and the transaction data set may include a training set and a test set. The sample machine learning model may be a linear regression model, a random forest regression model, or a neural network model. This embodiment of the present application does not make any specific restrictions. The mean squared error (MSE) can be used to construct a target loss function that can indicate the difference between the predicted attacker sub-score and the actual attacker sub-score. The formula of the target loss function is specifically: Among them, L(α,β) is the target loss function, h is the number of sample scoring blocks in the training set, and n j and t j are the total number of abnormal transactions and time interval corresponding to the jth sample scoring block, IF trie,j is the real attacker sub-score corresponding to the j-th sample scoring block, The predicted attacker sub-score corresponding to the j-th sample score block output by the sample machine learning model.

[0137] During each training iteration, the blockchain system can input the training set into the preset machine learning model through the scoring manager so that it can predict the attacker sub-score corresponding to the sample account based on the total number of abnormal transactions and time intervals corresponding to each sample scoring block in the training set, so as to obtain the predicted attacker sub-score corresponding to the sample account. And based on the formula of the above-mentioned target loss function, the predicted attacker sub-score corresponding to each sample scoring block in the training set and the real attacker sub-score are used to construct the target loss function in this training iteration. The weight coefficient and time decay coefficient in the target loss function are adjusted through an optimization algorithm (such as gradient descent method) to minimize the target loss function (that is, minimize the difference between the real attacker sub-score and the predicted attacker sub-score), and the model parameters are adjusted to train the sample machine learning model.

[0138] During the i-th iteration training process, after constructing the i-th target loss function, the trained i+1-th sample machine learning model is obtained. If the i+1-th predicted attacker sub-score output by the i+1-th sample machine learning model meets the second condition, the weight coefficient and time decay coefficient in the i-th target loss function are used as the weight coefficient and time decay coefficient corresponding to the first account, respectively. If the i+1-th predicted attacker sub-score output by the i+1-th sample machine learning model does not meet the second condition, the next iteration training process is entered. The second condition can be that the difference between the predicted attacker sub-score and the actual attacker sub-score is the smallest, that is, the target loss function is the smallest.

[0139] It should be noted that when the i+1 predicted attacker sub-score output by the i+1 sample machine learning model meets the second condition, the blockchain system will use the test set to evaluate the trained i+1 sample machine learning model, check the performance and generalization ability of the model, and determine whether to adjust and improve the i+1 sample machine learning model based on the evaluation results. If it is determined to adjust the parameters of the preset machine learning model, the iterative training process will be entered after the parameters of the i+1 sample machine learning model are readjusted, so that the error (or difference) between the model prediction value (predicted attacker sub-score) and the true value (true attacker sub-score) becomes smaller and smaller until satisfactory performance is achieved. The weight coefficient and time decay coefficient in the target loss function corresponding to the sample machine learning model obtained by the last training are used as the weight coefficient and time decay coefficient corresponding to the first account, respectively.

[0140] In the above technical solution, the target loss function reflects the difference between the predicted attacker sub-score determined by the sample machine learning model and the real attacker sub-score. In this way, when the i+1th predicted attacker sub-score output by the i+1th sample machine learning model meets the second condition, the difference between the predicted attacker score and the real attacker score is minimal. At this time, the weight coefficient and time decay coefficient in the target loss function can more accurately reflect the total number of abnormal transactions and time intervals of the account on the attacker sub-score of the account, avoiding manual analysis and value selection, improving the accuracy of the weight coefficient and time decay coefficient, and utilizing the characteristics of the machine learning model that can quickly process a large amount of data, thereby improving the efficiency of determining the weight coefficient and time decay coefficient.

[0141] Step S206: associate the target transaction behavior score and the account identification information and store them in a transaction behavior score set.

[0142] The blockchain system searches for the transaction behavior score corresponding to the account identification information of the first account from the transaction behavior score set through the score manager, and if found, replaces the transaction behavior score with the determined target transaction behavior score. If not found, the account identification information of the first account and the target transaction behavior score are associated and stored in the transaction behavior score set.

[0143] In the embodiment of the present application, the executed block includes at least one transaction cache pool that has been consensus-operated and chained by the blockchain system, then the determined target block includes the account's abnormal transactions that have been consensus-operated and chained and executed. Then the selected scoring block can indicate all abnormal transactions of the account participating in the consensus within the corresponding time period of the preset block height window. The block generation time of the first target block is earlier than the block generation time of the scoring block, and is adjacent to the scoring block, which means that the first target block is a block generated by the system when the account last initiated an abnormal transaction. Then based on the time difference between the block generation time of the target block and the scoring block, the time interval corresponding to the determined scoring block can characterize the interval time between two adjacent abnormal transactions initiated by the account. In this way, the transaction behavior score determined based on the relevant features can characterize whether the number of abnormal transactions initiated by the account to the system in the historical period is large and whether the time interval between each abnormal transaction is short. Therefore, the probability of an account attacking the blockchain system can be accurately reflected based on the transaction behavior score, which facilitates the subsequent accurate storage of normal account transactions in the transaction cache pool to improve the success rate and efficiency of the blockchain system consensus.

[0144] Figure 7 It is a flow chart of another consensus method of a blockchain system in an embodiment of the present application. Figure 7 The method shown comprises the following steps:

[0145] For details of steps S301 to S303, see Figure 1 Steps S101 to S103 in the illustrated embodiment are not described in detail here.

[0146] Step S304: Pack at least one transaction in the transaction buffer pool into a transaction set.

[0147] In the embodiment of the present application, the blockchain system includes multiple validators, including the first validator. The electronic signature can be an encrypted hash value, and the preset number is the minimum number of nodes for a successful consensus, the number of participants, and the quorum, which can be set based on the number of nodes in the blockchain network, and the embodiment of the present application does not impose any specific restrictions.

[0148] The blockchain system extracts at least one transaction from the transaction cache pool through a working node, packages the extracted transactions into a transaction set, and broadcasts the transaction set to the validator in the blockchain system.

[0149] Step S305: determine the electronic signature of the transaction set through the first verifier, and send the electronic signature and the transaction set to other verifiers except the first verifier.

[0150] The blockchain system determines the electronic signature of the received transaction set through the first verifier based on a digital signature algorithm such as a hash algorithm or an elliptic curve digital signature algorithm (ECDSA), and attaches the electronic signature to the transaction set, and then broadcasts the transaction set carrying the electronic signature to other verifiers in the system.

[0151] Step S306, controlling other verifiers to verify the received transaction set according to the electronic signature.

[0152] The blockchain system will control other validators to extract the electronic signature and the public key of the first validator from the transaction set it receives. The public key can be attached to the transaction set by the first validator, or it can be obtained by other means controlled by the blockchain system, such as derived from the address of the first validator. Then the blockchain system controls other validators to calculate the hash value of the transaction set it receives, and then use the public key to decrypt the extracted electronic signature to obtain a hash value, and compare the obtained hash value with the calculated hash value. If the two are consistent, the verification is successful, otherwise the verification fails.

[0153] Step S307, when it is determined that the verification results of the preset number of verifiers all meet the pass condition, determining the execution order of the transactions in the transaction set.

[0154] The blockchain system will collect the verification results of other validators through the first validator. When it is determined that the verification results of a preset number of validators among the collected verification results meet the passing conditions (that is, the verification is successful), it will generate an availability certificate for the transaction set and attach the availability certificate to the transaction set and return it to the working node.

[0155] Step S308, storing the transaction set with the determined execution order into the first block generated by the blockchain system to obtain a consensus result.

[0156] The blockchain system extracts a transaction set with an availability certificate from the working node through the consensus machine, sorts the transactions in the extracted transaction set (that is, enters the transaction sequencing part), and proposes the first block to store the transaction set in the first block to enter the consensus algorithm execution and the block confirmation and broadcast part, thereby obtaining a consensus result.

[0157] In some embodiments, continue to refer to Figure 2 The blockchain system includes an executor. After storing the transaction set with a determined execution order in the first block generated by the blockchain system and obtaining a consensus result, the method further includes:

[0158] Execute the transactions in the transaction set in the first block according to the execution order of the transactions in the transaction set by the executor to obtain the execution result, which includes the block generation time and block height of the first block, and the total number of abnormal transactions and account identification information of the account in the first block;

[0159] The transaction behavior score corresponding to at least one account in the transaction behavior score set is updated according to the execution result.

[0160] After the blockchain system stores the transaction set in the first block through the consensus device, it will send the consensus result to the executor. The blockchain system can determine the execution order of transactions in the executable transaction set in the first block based on the submission information in the received consensus result through the executor, and then execute the transactions in the transaction set to obtain the execution result, and send the execution result to the scoring manager.

[0161] The blockchain system determines the block generation time and block height of the first block and the total number of abnormal transactions and account identification information of the account in the first block based on the execution result through the scoring manager, and then for the account with abnormal transactions in the first block, Figure 6The illustrated embodiment determines a process similar to that of a target transaction behavior score (except that this time it is for accounts with abnormal transactions in the first block), determines the transaction behavior score corresponding to the account, and when the account identification information of the account exists in the transaction behavior score set, replaces the transaction behavior score originally corresponding to the account with the re-determined transaction behavior score; when the account identification information of the account does not exist in the transaction behavior score set, the account identification information of the account is associated with the determined transaction behavior score and stored in the transaction behavior score set.

[0162] In the above technical solution, the transaction behavior score corresponding to the account in the transaction behavior score set can be updated in time based on the execution results of the transactions in the transaction set in the block, providing a reliable transaction behavior score basis for the next consensus, so as to accurately intercept transactions of malicious accounts from entering the transaction cache pool and improve the success rate of consensus in the blockchain system.

[0163] In some embodiments, in order to improve the security and reliability of the consensus of the blockchain system, the method further includes: the execution result can also be sent to the consensus machine in the form of a checkpoint; when the consensus machine receives the first number of execution results, the transaction behavior score corresponding to at least one account in the transaction behavior score set is updated according to the first number of execution results. It can be understood that the first number can be the number of legal persons, and the blockchain system sends the execution result to the consensus machine through the executor. When the blockchain system detects that the consensus machine has received the first number of execution results, the consensus machine sends the first number of execution results to the scoring manager through the consensus machine so that the scoring manager updates the transaction behavior score corresponding to at least one account in the transaction behavior score set. On the one hand, in this technical solution, recording the execution result in the form of a checkpoint can prevent the execution result from being tampered with, thereby improving the data security of the blockchain system. On the other hand, only after the consensus machine collects the execution results in the form of the first number of checkpoints, the transaction behavior score corresponding to at least one account is updated based on the execution result, ensuring that the execution result is a result recognized by most nodes in the blockchain system, such as the executor, and ensuring the reliability of the execution result, thereby improving the reliability of the transaction behavior score.

[0164] In some embodiments, the method further includes: sending the first number of execution results to the transaction cache pool through the consensus device, and the transaction cache pool is used to determine the status of at least one transaction in the transaction cache pool according to the first number of execution results, and the status of the transaction may include an unconfirmed state, a confirmed state, a failed state, or a partially confirmed state. Among them, the unconfirmed state indicates that the transaction is stored in the transaction cache pool, but has not yet been packaged into the block for confirmation. The confirmed state indicates that the transaction is packaged into the block and confirmed by a certain number of nodes. The failed state indicates that an error occurred during the verification or execution of the transaction, resulting in the failure of the transaction to be successfully executed. The partially confirmed state indicates that the transaction is confirmed by some nodes, while other nodes have not yet confirmed the transaction.

[0165] For example, Figure 8 The flowchart of the execution result feedback of a transaction in an application scenario shown in FIG. 1 is a flowchart of the execution result feedback of a transaction in an application scenario shown in FIG. 1 . Taking the blockchain system including three working nodes (working nodes 1 to 3) as an example, each working node will receive Figure 5 The process shown packages at least one transaction in the transaction cache pool into a transaction set and obtains the availability certificate of the transaction set (it can be understood that different working nodes can extract different transactions from the transaction cache pool to be packaged into a transaction set). The blockchain system extracts the transaction set carrying the availability certificate from working nodes 1 to 3 through the consensus machine, sorts the transactions in the transaction set, obtains the consensus result, and then sends the consensus result to the executor. After the blockchain system executes the executable transaction set through the executor, it obtains the execution result and returns the execution result to the consensus machine in the form of Checkpoint. When the blockchain system detects that the consensus machine has collected a quorum number of Checkpoints (an example of the first number of execution results, that is, collect quorum checkpoint in the figure), the consensus machine generates a notification transaction cache pool in the form of Quorum Checkpoint (an example of the first number of execution results), and sends the execution result to the scheduler. The blockchain system updates the last received execution result, i.e., updates reputation, through the scheduler. The reputation information (Reputation Manager) integrates the block height Blockheight, block generation time Block timestamp, and the total number of abnormal transactions and account identification information in the first number of execution results and sends it to the scoring manager so that the scoring manager updates the transaction behavior score corresponding to at least one account (i.e. Figure 8 in updatereputation).

[0166] In the embodiment of the present application, whether the account's transaction can be stored in the transaction cache pool is determined by whether the account's transaction behavior score meets the first condition, so as to intercept the transaction of malicious accounts and improve the success rate and security of subsequent consensus. When consensus is reached on the transactions in the transaction cache pool, the execution order of the transactions in the transaction set is determined only when the verification results of the electronic signatures of the transaction set by a preset number of validators meet the passing conditions, so as to ensure that the processed transaction sets are all verified and safe transaction sets, further improving the security of the blockchain system consensus. The electronic signature determined by the first validator and verified by other validators is the electronic signature of the transaction set, rather than the electronic signature of a single transaction, which avoids the traditional situation of determining and verifying the electronic signature for each transaction, greatly reducing the signature pressure of the validator while reducing the delay of the consensus of a single transaction and improving the consensus efficiency.

[0167] Figure 2 Schematic diagram of the structure of a blockchain system of an embodiment of the present application, the blockchain system is applicable to the consensus method of the blockchain system of any of the above embodiments of the present application, such as Figure 2 The blockchain system shown includes:

[0168] A scheduler, configured to receive a first transaction of a first account and send the first transaction to a validator;

[0169] The verifier is used to obtain the account identification information of the first account in the blockchain system when receiving the first transaction; send the account identification information to the scoring manager; receive the target transaction behavior score sent by the scoring manager; if the target transaction behavior score meets the first condition, store the first transaction in the transaction cache pool, and the transaction cache pool is used to store transactions in the blockchain system that have not been subjected to consensus operations;

[0170] The scoring manager is used to obtain a target transaction behavior score corresponding to the first account from a transaction behavior score set according to the account identification information, wherein the transaction behavior score set includes transaction behavior scores corresponding to different accounts in the blockchain system, and the target transaction behavior score is used to indicate the probability of the first account attacking the blockchain system; and send the target transaction behavior score to the verifier;

[0171] The consensus device is used to perform consensus operations on transactions in the transaction cache pool and obtain consensus results. The consensus results are used to indicate the execution order of transactions in the blockchain system.

[0172] In some embodiments, the verifier is further used to perform basic verification operations on the first transaction, and the basic verification operations at least include verifying at least one of the transaction signature, verifying the transaction format, or verifying the transaction content; if the first transaction passes the basic verification, the account identification information is sent to the scoring manager; if the first transaction fails the basic verification, transaction exception information is generated, and the transaction exception information is sent to the client terminal corresponding to the first account.

[0173] In some embodiments, continue to refer to Figure 2 , the blockchain system includes a working node and a plurality of validators, the plurality of validators including a first validator;

[0174] A working node, configured to package at least one transaction in the transaction cache pool into a transaction set, and send the transaction set to the first validator;

[0175] A first verifier, configured to determine an electronic signature of the transaction set, and send the electronic signature and the transaction set to other verifiers except the first verifier;

[0176] Other validators, for validating the received transaction set based on the received electronic signature;

[0177] The consensus device is used to determine the execution order of transactions in the transaction set when it is determined that the verification results of a preset number of validators all meet the passing conditions; the transaction set with the determined execution order is stored in the first block generated by the blockchain system to obtain a consensus result.

[0178] In some embodiments, continue to refer to Figure 2 , the system further comprises:

[0179] An executor is used to execute the transactions in the transaction set in the first block according to the execution order of the transactions in the transaction set, obtain the execution result, and the execution result includes the block generation time and block height of the first block, and the total number of abnormal transactions and account identification information of the account in the first block; and send the execution result to the scoring manager;

[0180] The scoring manager is further used to update the transaction behavior score corresponding to at least one account in the transaction behavior score set according to the execution result.

[0181] In some embodiments, the scoring manager is further configured to:

[0182] Determine at least one target block corresponding to the first account from at least one executed block, the target block includes the abnormal transaction initiated by the first account, the executed block includes at least one on-chain transaction, and the on-chain transaction has been consensus-operated by the blockchain system in the transaction cache pool and stored in the blockchain;

[0183] The target block whose block height is within the preset block height window is determined as a scoring block;

[0184] Determine a target block whose block generation time is earlier than the block generation time of the scoring block and is adjacent to the scoring block as a first target block;

[0185] Determine the time interval corresponding to the scoring block based on the time difference between the block generation time of the first target block and the scoring block;

[0186] Determine a target transaction behavior score corresponding to the first account according to the reference transaction behavior score corresponding to the first account, the time interval corresponding to the scoring block, and the total number of abnormal transactions of the first account in the scoring block;

[0187] The target transaction behavior score and account identification information are associated and stored in a transaction behavior score set.

[0188] In some embodiments, the scoring manager is further configured to:

[0189] In the preset block height window, the attacker score of the first account in the preset block height window is determined according to the time interval corresponding to the scoring block and the total number of abnormal transactions of the first account in the scoring block;

[0190] Within a preset time window, the target transaction behavior score is obtained according to the sum of the attacker's scores, and the end time of the preset time window is earlier than the time when the blockchain system receives the first transaction.

[0191] In some embodiments, the scoring manager is further configured to:

[0192] Determine the attacker sub-score corresponding to the scoring block according to the time interval corresponding to the scoring block and the total number of abnormal transactions of the first account in the scoring block;

[0193] In the preset block height window, the attacker's impact score in the preset block height window is obtained based on the sum of the attacker's sub-scores;

[0194] The difference between the reference transaction behavior score and the attacker impact score is determined as the attacker score.

[0195] In some embodiments, the scoring manager is further configured to:

[0196] Get the time decay coefficient and weight coefficient corresponding to the first account;

[0197] Determine the scoring time corresponding to the first account according to the power exponent between the time decay coefficient and the time interval;

[0198] Determine the product of the total number of abnormal transactions and the weight coefficient;

[0199] According to the proportional relationship between the product result and the scoring time, the attacker sub-score corresponding to the scoring block is determined.

[0200] In some embodiments, the scoring manager is further configured to:

[0201] Obtain a transaction data set, which includes the total number of abnormal transactions, time intervals, and sub-scores of real attackers corresponding to the sample scoring block;

[0202] The total number of abnormal transactions and time intervals corresponding to the sample scoring block are input into the sample machine learning model to obtain the predicted attacker sub-score;

[0203] determining a target loss function based on the difference between the predicted attacker sub-score and the actual attacker sub-score;

[0204] In the i-th iteration training process, the i+1-th sample machine learning model is obtained based on the i-th target loss function training, where i is a positive integer;

[0205] When the i+1th predicted attacker sub-score output by the i+1th sample machine learning model meets the second condition, the weight coefficient and time decay coefficient in the i-th target loss function are used as the weight coefficient and time decay coefficient corresponding to the first account, respectively.

[0206] In some embodiments, when the target transaction behavior score does not meet the first condition, the verifier is also used to not store the transactions of the first account in the transaction cache pool when the transactions of the first account are received within a preset time period, and the preset time period includes the moment when the first transaction is received.

[0207] It should be noted that the above-mentioned scheduler, checker, scoring manager, consensus device, validator, executor and the information interaction, execution process and other contents between the working nodes are based on the same concept as the method embodiment of the present application. Their specific functions and technical effects can be found in the method embodiment part and will not be repeated here.

[0208] The technicians in the relevant field can clearly understand that for the convenience and simplicity of description, only the division of the above-mentioned functional units, devices, and modules is used as an example for illustration. In practical applications, the above-mentioned function allocation can be completed by different functional units and modules as needed, that is, the internal structure of the device can be divided into different functional units or modules to complete all or part of the functions described above. The functional units and modules in the embodiment can be integrated in a processing unit, or each unit can exist physically separately, or two or more units can be integrated in one unit. The above-mentioned integrated unit can be implemented in the form of hardware or in the form of software functional units. In addition, the specific names of the functional units and modules are only for the convenience of distinguishing each other, and are not used to limit the scope of protection of this application. The specific working process of the units and modules in the above-mentioned system can refer to the corresponding process in the aforementioned method embodiment, which will not be repeated here.

[0209] An embodiment of the present application also provides a computer-readable storage medium, which stores a computer program. When the computer program is executed by the blockchain system, it can implement the steps in the above-mentioned method embodiments.

[0210] An embodiment of the present application provides a computer program product. When the computer program product runs on a blockchain system, the steps in the above-mentioned method embodiments can be implemented when the blockchain system is executed.

[0211] If the above-mentioned actuators and other devices are implemented in the form of software functional units and sold or used as independent products, they can be stored in a computer-readable storage medium. Based on this understanding, the present application implements all or part of the processes in the above-mentioned embodiment method, which can be completed by instructing the relevant hardware through a computer program. The computer program can be stored in a computer-readable storage medium. When the computer program is executed by the blockchain system, the steps of the above-mentioned method embodiments can be implemented. Among them, the computer program includes computer program code, which can be in source code form, object code form, executable file or some intermediate form. The computer-readable medium can at least include: any entity or device that can carry the computer program code to the camera / terminal device, recording medium, computer memory, read-only memory (ROM, Read-Only Memory), random access memory (RAM, Random Access Memory), electric carrier signal, telecommunication signal and software distribution medium. For example, USB flash drive, mobile hard disk, disk or optical disk. In some jurisdictions, according to legislation and patent practice, computer-readable media cannot be electric carrier signals and telecommunication signals.

[0212] In the above embodiments, the description of each embodiment has its own emphasis. For parts that are not described or recorded in detail in a certain embodiment, reference can be made to the relevant descriptions of other embodiments.

[0213] Those of ordinary skill in the art will appreciate that the units and algorithm steps of each example described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, or a combination of computer software and electronic hardware. Whether these functions are performed in hardware or software depends on the specific application and design constraints of the technical solution. Professional and technical personnel can use different methods to implement the described functions for each specific application, but such implementation should not be considered to be beyond the scope of this application.

[0214] In the embodiments provided in the present application, it should be understood that the disclosed systems and methods can be implemented in other ways. For example, the device / network equipment embodiments described above are merely schematic. For example, the division of the modules or units is only a logical function division. There may be other division methods in actual implementation, such as multiple units or components can be combined or integrated into another system, or some features can be ignored or not executed. Another point is that the mutual coupling or direct coupling or communication connection shown or discussed can be through some interfaces, indirect coupling or communication connection of devices or units, which can be electrical, mechanical or other forms.

[0215] The units described as separate components may or may not be physically separated, and the components shown as units may or may not be physical units, that is, they may be located in one place or distributed on multiple network units. Some or all of the units may be selected according to actual needs to achieve the purpose of the solution of this embodiment.

[0216] The embodiments described above are only used to illustrate the technical solutions of the present application, rather than to limit them. Although the present application has been described in detail with reference to the aforementioned embodiments, a person skilled in the art should understand that the technical solutions described in the aforementioned embodiments may still be modified, or some of the technical features may be replaced by equivalents. Such modifications or replacements do not deviate the essence of the corresponding technical solutions from the spirit and scope of the technical solutions of the embodiments of the present application, and should all be included in the protection scope of the present application.

Claims

1. A consensus method for a blockchain system, characterized in that: include: Upon receiving a first transaction of a first account, obtaining account identification information of the first account in the blockchain system; According to the account identification information, a target transaction behavior score corresponding to the first account is obtained from a transaction behavior score set, wherein the transaction behavior score set includes transaction behavior scores corresponding to different accounts in the blockchain system, and the target transaction behavior score is used to indicate a probability of the first account attacking the blockchain system; When the target transaction behavior score satisfies a first condition, storing the first transaction in a transaction cache pool, where the transaction cache pool is used to store transactions in the blockchain system for which no consensus operation has been performed; A consensus operation is performed on the transactions in the transaction cache pool to obtain a consensus result, wherein the consensus result is used to indicate the execution order of the transactions in the blockchain system.

2. The method according to claim 1, characterized in that Before acquiring the target transaction behavior score corresponding to the first account from the transaction behavior score set according to the account identification information, the method further includes: Determine at least one target block corresponding to the first account from at least one executed block, wherein the target block includes the abnormal transaction initiated by the first account, and the executed block includes at least one on-chain transaction, wherein the on-chain transaction has been consensus-operated by the blockchain system in the transaction cache pool, and the on-chain transaction is stored in the blockchain; The target block whose block height is within the preset block height window is determined as the scoring block; Determine the target block whose block generation time is earlier than the block generation time of the scoring block and is adjacent to the scoring block as the first target block; Determining a time interval corresponding to the scoring block based on a time difference between the block generation time of the first target block and the scoring block; Determine the target transaction behavior score corresponding to the first account according to the reference transaction behavior score corresponding to the first account, the time interval corresponding to the scoring block, and the total number of abnormal transactions of the first account in the scoring block; The target transaction behavior score and the account identification information are associated and stored in the transaction behavior score set.

3. The method according to claim 2, characterized in that The determining the target transaction behavior score corresponding to the first account according to the reference transaction behavior score corresponding to the first account, the time interval corresponding to the scoring block, and the total number of abnormal transactions of the first account in the scoring block includes: In the preset block height window, determining the attacker score of the first account in the preset block height window according to the time interval corresponding to the scoring block and the total number of abnormal transactions of the first account in the scoring block; Within a preset time window, the target transaction behavior score is obtained according to the sum of the attacker scores, and the end time of the preset time window is earlier than the time when the blockchain system receives the first transaction.

4. The method according to claim 3, characterized in that Determining the attacker score of the first account in the set block height window according to the time interval corresponding to the scoring block and the total number of abnormal transactions of the first account in the scoring block includes: Determine an attacker sub-score corresponding to the scoring block according to the time interval corresponding to the scoring block and the total number of abnormal transactions of the first account in the scoring block; In the preset block height window, according to the sum of the attacker sub-scores, the attacker influence score in the preset block height window is obtained; The difference between the reference transaction behavior score and the attacker influence score is determined as the attacker score.

5. The method according to claim 4, characterized in that Determining the attacker sub-score corresponding to the scoring block according to the time interval corresponding to the scoring block and the total number of abnormal transactions in the scoring block includes: Obtaining a time decay coefficient and a weight coefficient corresponding to the first account; Determining a scoring time corresponding to the first account according to a power exponent between the time decay coefficient and the time interval; Determine the product of the total number of abnormal transactions and the weight coefficient; The attacker sub-score corresponding to the scoring block is determined according to the proportional relationship between the multiplication result and the scoring time.

6. The method according to claim 5, characterized in that Before obtaining the time decay coefficient and the weight coefficient corresponding to the first account, the method further includes: Acquire a transaction data set, wherein the transaction data set includes the total number of abnormal transactions, time interval, and real attacker sub-score corresponding to the sample scoring block; Input the total number of abnormal transactions and the time interval corresponding to the sample scoring block into the sample machine learning model to obtain a predicted attacker sub-score; determining a target loss function based on a difference between the predicted attacker sub-score and the actual attacker sub-score; In the i-th iteration training process, the i+1-th sample machine learning model is obtained based on the i-th target loss function training, where i is a positive integer; When the i+1th predicted attacker sub-score output by the i+1th sample machine learning model satisfies the second condition, the weight coefficient and time decay coefficient in the i-th target loss function are respectively used as the weight coefficient and time decay coefficient corresponding to the first account.

7. The method according to any one of claims 1 to 6, characterized in that: When the target transaction behavior score does not satisfy the first condition, the method further includes: In the case where the transaction of the first account is received within a preset time period, the transaction of the first account is not stored in the transaction cache pool, and the preset time period includes the moment when the first transaction is received.

8. The method according to claim 7, characterized in that The blockchain system includes a first validator among a plurality of validators; The performing consensus operation on the transactions in the transaction cache pool to obtain a consensus result includes: Packing at least one transaction in the transaction cache pool into a transaction set; Determine, by the first verifier, an electronic signature of the transaction set, and send the electronic signature and the transaction set to other verifiers except the first verifier; Controlling the other verifiers to verify the received transaction set according to the electronic signature; When it is determined that the verification results of the preset number of verifiers meet the passing condition, determining the execution order of the transactions in the transaction set; The transaction set with a determined execution order is stored in a first block generated by the blockchain system to obtain the consensus result.

9. A blockchain system, characterized in that: The system comprises: A scheduler, configured to receive a first transaction of a first account and send the first transaction to a validator; The verifier is used to, upon receiving the first transaction, obtain the account identification information of the first account in the blockchain system; send the account identification information to the scoring manager; receive the target transaction behavior score sent by the scoring manager; and, if the target transaction behavior score satisfies a first condition, store the first transaction in a transaction cache pool, wherein the transaction cache pool is used to store transactions in the blockchain system that have not been subjected to consensus operations; The scoring manager is configured to obtain, according to the account identification information, a target transaction behavior score corresponding to the first account from a transaction behavior score set, wherein the transaction behavior score set includes transaction behavior scores corresponding to different accounts in the blockchain system, respectively, and the target transaction behavior score is used to indicate a probability of the first account attacking the blockchain system; and send the target transaction behavior score to the verifier; The consensus device is used to perform consensus operations on the transactions in the transaction cache pool to obtain a consensus result, and the consensus result is used to indicate the execution order of the transactions in the blockchain system.

10. A computer-readable storage medium storing a computer program, characterized in that: When the computer program is executed, the method according to any one of claims 1 to 8 is implemented.

Images