Blockchain transaction processing method and device

Abstract

One or more embodiments of the present specification provide a blockchain transaction processing method, which is applied to a blockchain node in a blockchain network, and the method includes: verifying the legitimacy of a received blockchain transaction, and reaching a consensus on the blockchain transaction with other blockchain nodes in the blockchain network if the verification passes; if it is confirmed that the blockchain transaction passes the consensus, calling a management contract pre-deployed at the blockchain node to perform a security verification on the blockchain transaction through the transaction verification rules in the management contract; if it is confirmed that the blockchain transaction passes the security verification, executing the blockchain transaction; and if it is confirmed that the blockchain transaction fails the security verification, refusing to execute the blockchain transaction.

Description

Technical Field

[0001] One or more embodiments of the present specification relate to the field of blockchain technology, and more particularly, to a blockchain transaction processing method and device. Background Art

[0002] Blockchain technology, also known as distributed ledger technology, is an emerging technology in which several computing devices jointly participate in "bookkeeping" and jointly maintain a complete distributed database. Since blockchain technology is decentralized, open and transparent, each computing device can participate in database records, and data can be quickly synchronized between computing devices, blockchain technology is used to build a decentralized system, and various execution programs are included in the distributed database of the blockchain for automatic execution. It has been widely used in many fields. Summary of the invention

[0003] In view of this, one or more embodiments of this specification provide a blockchain transaction processing method and device.

[0004] Specifically, one or more embodiments of this specification provide the following technical solutions:

[0005] According to a first aspect of one or more embodiments of this specification, a blockchain transaction processing method is proposed, which is applied to a blockchain node in a blockchain network, including:

[0006] Verify the legitimacy of the received blockchain transaction, and if the verification passes, reach consensus on the blockchain transaction with other blockchain nodes in the blockchain network;

[0007] When it is confirmed that the blockchain transaction has passed the consensus, calling the management contract pre-deployed in the blockchain node to perform security verification on the blockchain transaction according to the transaction verification rules in the management contract;

[0008] If it is confirmed that the blockchain transaction has passed the security check, the blockchain transaction is executed; and if it is confirmed that the blockchain transaction has not passed the security check, the blockchain transaction is refused to be executed.

[0009] According to a second aspect of one or more embodiments of this specification, a blockchain transaction processing device is proposed, which is applied to a blockchain node in a blockchain network, including:

[0010] A verification consensus unit is used to verify the legitimacy of the received blockchain transaction, and if the verification passes, reach a consensus on the blockchain transaction with other blockchain nodes in the blockchain network;

[0011] A verification unit, configured to, when confirming that the blockchain transaction has passed the consensus, call a management contract pre-deployed in the blockchain node to perform security verification on the blockchain transaction according to the transaction verification rules in the management contract;

[0012] The execution unit is used to execute the blockchain transaction if it is confirmed that the blockchain transaction passes the security check; and refuse to execute the blockchain transaction if it is confirmed that the blockchain transaction fails the security check.

[0013] According to a third aspect of this specification, there is provided an electronic device, including:

[0014] processor;

[0015] a memory for storing processor-executable instructions;

[0016] The processor implements the method described in the embodiment of the first aspect above by running the executable instructions.

[0017] According to a fourth aspect of the embodiments of this specification, a computer-readable storage medium is provided, on which computer instructions are stored, and when the instructions are executed by a processor, the steps of the method described in the embodiments of the first aspect above are implemented. BRIEF DESCRIPTION OF THE DRAWINGS

[0018] Figure 1 It is a schematic diagram of creating a smart contract provided by an exemplary embodiment;

[0019] Figure 2 It is a schematic diagram of calling a smart contract provided by an exemplary embodiment;

[0020] Figure 3 It is a schematic diagram of creating and calling a smart contract provided by an exemplary embodiment;

[0021] Figure 4 It is a schematic diagram of a method for processing blockchain transactions provided by an exemplary embodiment;

[0022] Figure 5 It is a schematic diagram of a network environment related to blockchain provided by an exemplary embodiment;

[0023] Figure 6 It is a schematic diagram of a method for processing blockchain transactions provided by an exemplary embodiment;

[0024] Figure 7 is a schematic diagram of an electronic device provided by an exemplary embodiment;

[0025] Figure 8It is a block diagram of a blockchain transaction processing device provided by an exemplary embodiment. DETAILED DESCRIPTION

[0026] Exemplary embodiments will be described in detail herein, examples of which are shown in the accompanying drawings. When the following description refers to the drawings, the same numbers in different drawings represent the same or similar elements unless otherwise indicated. The implementations described in the following exemplary embodiments do not represent all implementations consistent with one or more embodiments of this specification. Instead, they are merely examples of devices and methods consistent with some aspects of one or more embodiments of this specification as detailed in the appended claims.

[0027] It should be noted that: in other embodiments, the steps of the corresponding method are not necessarily performed in the order shown and described in this specification. In some other embodiments, the steps included in the method may be more or less than those described in this specification. In addition, a single step described in this specification may be decomposed into multiple steps for description in other embodiments; and multiple steps described in this specification may be combined into a single step for description in other embodiments.

[0028] Blockchain is generally divided into three types: public blockchain, private blockchain and alliance blockchain. In addition, there are many types of combinations, such as private blockchain + alliance blockchain, alliance blockchain + public blockchain and other different combinations. Among them, the public chain has the highest degree of decentralization. Participants who join the public chain can read the data records on the chain, participate in transactions, and compete for the right to record new blocks. Moreover, each participant (i.e., node) can freely join and exit the network and perform related operations. On the contrary, the private chain has the write permission of the network controlled by a certain organization or institution, and the data reading permission is stipulated by the organization. In simple terms, the private chain can be a weakly centralized system with strictly limited and few participating nodes. This type of blockchain is more suitable for use within a specific organization. The alliance chain is a blockchain between the public chain and the private chain, which can achieve "partial decentralization". Each node in the alliance chain usually has a corresponding entity or organization; participants join the network through authorization and form a stakeholder alliance to jointly maintain the operation of the blockchain.

[0029] Based on the basic characteristics of blockchain, blockchain is usually composed of several blocks. In each of these blocks, a timestamp corresponding to the creation time of the block is recorded. All blocks strictly follow the timestamp recorded in the block to form a data chain that is ordered in time.

[0030] For data generated outside the chain, it can be constructed into a standard transaction format supported by the blockchain and then published to the blockchain. The node devices in the blockchain verify the legitimacy and reach consensus on the transaction. After reaching a consensus, the node devices in the blockchain that serve as accounting nodes will package the transaction into a block and store it persistently in the blockchain.

[0031] Among them, the legitimacy verification of blockchain transactions can usually be achieved by verifying the validity of signatures. When the blockchain adopts an account model, the accounts applicable to the blockchain usually correspond to one or more sets of public key-private key pairs. The above public keys can be recorded in the corresponding account status, or stored in the distributed database of the blockchain in other forms, and can be obtained by any node device in the blockchain network. The private key corresponding to the above public key is stored in the local database or other hardware terminal of the account owner for the account owner to perform digital signature or encryption and decryption operations. The blockchain transaction initiated by the initiator includes not only the transaction content, but also the digital signature of the initiator using the private key corresponding to its account for the transaction content. After receiving the blockchain transaction, the blockchain node can verify the legitimacy of the blockchain transaction based on the digital signature contained in the blockchain transaction. The legitimacy verification usually includes: verifying whether the digital signature is obtained based on the transaction content of the blockchain transaction (also known as integrity verification), etc. Through integrity verification, it can be ensured that the blockchain transaction is indeed initiated by the user corresponding to the public key and that the transaction has not been tampered with during transmission. In another case, the initiator's public key can also be carried in the CA certificate issued by the CA center to the initiator. When the initiator sends a blockchain transaction, the CA certificate signed by the CA center's private key can be sent to the blockchain node. The blockchain node verifies the signature of the CA certificate based on the CA center's public key. If the verification is successful, the initiator's public key carried in the CA certificate can be obtained. Among them, the CA center is an authoritative organization that can be trusted by blockchain nodes by default. Therefore, as long as the certificate is successfully signed with the CA center's public key, it can be determined that the public key in the certificate is credible, so that the blockchain node can verify the legitimacy of the digital signature contained in the received blockchain transaction through the public key.

[0032] Among them, the consensus algorithms supported in blockchain can include:

[0033] The first type of consensus algorithm is the consensus algorithm in which node devices need to compete for the right to record in each accounting cycle; for example, consensus algorithms such as Proof of Work (POW), Proof of Stake (POS), and Delegated Proof of Stake (DPOS);

[0034] The second type of consensus algorithm is the consensus algorithm that elects accounting nodes in advance for each accounting cycle (without the need to compete for accounting rights); for example, consensus algorithms such as Practical Byzantine Fault Tolerance (PBFT).

[0035] In a blockchain network that uses the first type of consensus algorithm, node devices competing for the right to record transactions can execute the transaction after receiving it. Among the node devices competing for the right to record transactions, one node device may win in this round of competition for the right to record transactions and become a record node. The record node can package the received transaction with other transactions to generate a candidate block, and send the generated candidate block or the block header of the candidate block to other node devices for consensus.

[0036] In a blockchain network that uses the second type of consensus algorithm, the node devices with the right to record accounts have been agreed upon before this round of accounting. Therefore, after receiving a transaction, if the node device itself is not the accounting node of this round, it can send the transaction to the accounting node. For the accounting node of this round, the transaction can be sent to other node devices for consensus. After determining that the transaction has passed the consensus, other node devices can package the transaction with other transactions to generate a candidate block and execute the transaction.

[0037] As mentioned above, no matter which consensus algorithm shown above is adopted by the blockchain, the accounting node of this round can package the received transactions to generate candidate blocks, and send the generated candidate blocks or the block headers of the candidate blocks to other node devices for consensus verification. If other node devices receive the candidate blocks or the block headers of the candidate blocks and verify that there are no problems, the candidate blocks can be appended to the end of the original blockchain as the latest blocks, thereby completing the accounting process of the blockchain. In the process of other nodes verifying the new blocks or block headers sent by the accounting nodes, they can also execute the transactions contained in the blocks.

[0038] When implementing data storage, blockchains that use the account model need to store and maintain blockchain data, which usually includes block data and account status data corresponding to blockchain accounts in the blockchain; block data can further include block header data, block transaction data in the block, etc. When storing the various blockchain data shown above, the various blockchain data can usually be organized into a Merkle tree in the form of key-value pairs and stored in the database.

[0039] In the above blockchain model, a smart contract for data storage can be deployed on the blockchain. Users can call the smart contract to store the data to be stored as the account status of the contract account corresponding to the smart contract in the Merkle tree corresponding to the smart contract.

[0040] For example, taking Ethereum as an example, a special Merkle tree called MPT tree is usually used to store and maintain blockchain data; among them, for account status data, it can be organized into MPT state tree (i.e. world state) and stored in the database; the MPT state tree stores key-value pairs with account address as key and account status data as value. The data content stored in the contract account corresponding to the smart contract will also be further organized into a storage tree (an MPT storage tree for storing data) and stored in the database; the hash value of the root node of the storage tree will be filled into the MPT state tree as part of the account status data corresponding to the contract account; and the hash of the root node of the MPT state tree will be further filled into the block header. When the user needs to store data, the data to be stored can be stored in the storage tree corresponding to the smart contract as the account status data of the contract account corresponding to the smart contract by calling the smart contract.

[0041] In the field of blockchain, another important concept is account. Taking Ethereum as an example, Ethereum usually divides accounts into two categories: external accounts and contract accounts. External accounts are accounts directly controlled by users, also called user accounts. Contract accounts are accounts created by users through external accounts and contain contract codes (i.e. smart contracts).

[0042] Of course, for some blockchain models derived from the Ethereum-based architecture, the account types supported by the blockchain can be further expanded, which is not specifically limited in this specification.

[0043] For accounts in the blockchain, a structure is usually used to maintain the account status. When a transaction in a block is executed, the status of the account related to the transaction in the blockchain will usually change.

[0044] In an example, the structure of an account usually includes fields such as Balance, Nonce, Code, and Storage. Among them:

[0045] The Balance field is used to maintain the current account balance of the account;

[0046] The Nonce field is used to maintain the number of transactions for the account. It is a counter used to ensure that each transaction can and can only be processed once, effectively avoiding replay attacks.

[0047] The Code field is used to maintain the contract code of the account. In actual applications, the Code field usually only maintains the hash value of the contract code. Therefore, the Code field is also often called the Codehash field.

[0048] The Storage field is used to maintain the storage content of the account (the default field value is empty). For a contract account, an independent storage space is usually allocated to store the storage content of the contract account. This independent storage space is usually called the account storage of the contract account.

[0049] The storage content of the contract account is usually constructed into an MPT (Merkle Patricia Trie) tree data structure and stored in the above independent storage space; among them, the MPT tree constructed based on the storage content of the contract account is usually also called the Storage tree. The Storage field usually only maintains the root node of the Storage tree; therefore, the Storage field is usually also called the StorageRoot field.

[0050] For an external account, the field values ​​of the Code field and the Storage field shown above are both empty.

[0051] In practical applications, whether it is a public chain, a private chain or a consortium chain, it may provide the function of smart contract. Smart contracts on the blockchain are contracts that can be triggered and executed by transactions on the blockchain. Smart contracts can be defined in the form of code.

[0052] Taking Ethereum as an example, it supports users to create and call some complex logic in the Ethereum network. As a programmable blockchain, Ethereum is centered on the Ethereum Virtual Machine (EVM), and each Ethereum node can run EVM. EVM is a Turing-complete virtual machine that can implement various complex logics. Users publish and call smart contracts in Ethereum on EVM. In fact, EVM directly runs virtual machine code (virtual machine bytecode, hereinafter referred to as "bytecode"), so smart contracts deployed on the blockchain can be bytecode.

[0053] like Figure 1 As shown in the figure, after Bob sends a transaction containing the information of creating a smart contract to the Ethereum network, each node can execute the transaction in the EVM. Figure 1The From field of the transaction is used to record the address of the account that initiated the creation of the smart contract. The contract code stored in the Data field of the transaction can be bytecode, and the To field of the transaction is a null account. When the nodes reach an agreement through the consensus mechanism, the smart contract is successfully created and subsequent users can call this smart contract.

[0054] After a smart contract is created, a contract account corresponding to the smart contract appears on the blockchain and has a specific address; for example, Figure 1 The "0x68e12cf284..." in each node represents the address of the created contract account. The behavior of the smart contract is controlled by the contract code, and the account storage of the smart contract saves the state of the contract. In other words, the smart contract generates a virtual account on the blockchain that contains the contract code and account storage.

[0055] As mentioned above, the Data field of the transaction that creates a smart contract can store the bytecode of the smart contract. The bytecode consists of a series of bytes, each of which can identify an operation. Based on development efficiency, readability and other considerations, developers can choose a high-level language to write smart contract code instead of writing bytecode directly. For example, high-level languages ​​can be Solidity, Serpent, LLL, etc. For smart contract code written in a high-level language, it can be compiled by a compiler to generate bytecode that can be deployed on the blockchain.

[0056] Taking Solidity as an example, the contract code written in it is very similar to the class in object-oriented programming language. In a contract, multiple members can be declared, including state variables, functions, function modifiers, events, etc. State variables are values ​​permanently stored in the account storage field of the smart contract, which are used to save the state of the contract.

[0057] like Figure 2 As shown in the figure, still taking Ethereum as an example, after Bob sends a transaction containing the information of calling a smart contract to the Ethereum network, each node can execute the transaction in the EVM. Figure 2 The From field of the transaction is used to record the address of the account that initiates the call to the smart contract, the To field is used to record the address of the smart contract being called, and the Data field of the transaction is used to record the method and parameters of calling the smart contract. After calling the smart contract, the account status of the contract account may change. Later, a client can access the blockchain node (for example Figure 2 Node 1) in the contract account to view the account status.

[0058] Smart contracts can be executed independently on each node in the blockchain network in a prescribed manner, and all execution records and data are stored on the blockchain. Therefore, when such a transaction is executed, the blockchain will store transaction credentials that cannot be tampered with or lost.

[0059] The schematic diagram of creating and calling smart contracts is as follows: Figure 3 To create a smart contract in Ethereum, you need to go through the process of writing the smart contract, converting it into bytecode, and deploying it to the blockchain. To call a smart contract in Ethereum, you initiate a transaction pointing to the smart contract address. The EVM of each node can execute the transaction separately, and the smart contract code is distributed and run in the virtual machine of each node in the Ethereum network.

[0060] It should be noted that in addition to being able to be created by users, smart contracts can also be set by the system in the genesis block. This type of contract is generally called a genesis contract. Generally, some blockchain network data structures, parameters, properties, and methods can be set in the genesis contract. In addition, accounts with system administrator privileges can create system-level contracts or modify system-level contracts (referred to as system contracts). In addition to the EVM in Ethereum, different blockchain networks may also use various virtual machines, which are not limited here.

[0061] With the widespread application of blockchain technology, the security of blockchain accounts has received more and more attention. Although blockchain technology is based on basic features such as consensus mechanism and signature verification, it can ensure that data on the blockchain network is secure, transparent and cannot be tampered with. However, existing transaction methods still have security risks. Attackers seize security loopholes in the blockchain transaction process and initiate malicious blockchain transactions in a specific attack method, causing huge losses to the attacked objects and posing a major threat to the security of the blockchain network.

[0062] In order to solve the above problems, Figure 4 FIG. 1 is a flowchart of a blockchain transaction processing method according to an exemplary embodiment of this specification. Figure 4 As shown, the method is applied to a blockchain node in a blockchain network and may include the following steps:

[0063] Step 402: Verify the legitimacy of the received blockchain transaction, and if the verification passes, reach a consensus on the blockchain transaction with other blockchain nodes in the blockchain network.

[0064] In the technical solution of this specification, Figure 5For example, the blockchain-related network environment shown in FIG. 5 may include a client-side computing device 501, a server-side 502, and at least one blockchain system; for example, a blockchain system 503. The blockchain network in this specification may include, for example, Figure 5 The blockchain system 503 shown. The client-side computing device 501 may include various types of client-side computing devices; for example, the client-side computing device may include a PC computing device, a mobile computing device, an Internet of Things device, and other forms of smart devices with certain computing capabilities, etc. In one embodiment, at least some of the computing devices in the client-side computing device 501 may be connected to the server 502 via various communication networks; for example, Figure 5 The device 5 shown in FIG. 5 is connected to the server 502. It is not difficult to understand that some computing devices in the client-side computing device 501 may not be connected to the server 502, but may be directly connected to the blockchain system through various communication networks as blockchain nodes; for example, Figure 5 Devices 3 and 4 shown in the figure can be connected to the blockchain system as blockchain nodes. In one embodiment, the client-side computing device 501 can also include one or more user-side servers; for example, Figure 5 At least some of the computing devices in the client-side terminal device 501 may be connected to the user-side server; for example, Figure 5 Device 6 shown in FIG. 4 is connected to device 4, and device 1 and device 2 are connected to device 5. It is understood that the blockchain transaction can be sent to the blockchain system through a client computing device such as device 4, or can be sent to the blockchain system through the server 502. Therefore, in the above step 402, the blockchain transaction received by the blockchain node can be sent by the client computing device, can be sent by the server platform, or can be broadcast by other blockchain nodes, and this specification does not limit this.

[0065] After receiving a blockchain transaction, the blockchain node first needs to verify the legitimacy of the blockchain transaction. As mentioned above, a blockchain transaction includes the transaction content and the digital signature generated by the initiator based on its own account private key, and the blockchain node can verify the digital signature in the received blockchain transaction through the account public key corresponding to the initiator. The working principle of the transaction legitimacy verification can be referred to the relevant description above, which will not be repeated here. By verifying the legitimacy of the received transaction, it can be determined that the received blockchain transaction has not been tampered with during the transmission process, thereby improving the security of the blockchain transaction.

[0066] For blockchain transactions that have passed verification, the blockchain node needs to reach a consensus with other blockchain nodes in the blockchain network to which it belongs. In this specification, different blockchain consensus algorithms can be used according to actual needs. For example, PBFT (Practical Byzantine Fault Tolerance) can be used; POW (Proof Of Work) can also be used, and this specification does not limit this. Among them, the working principle of blockchain transaction consensus can refer to the above-mentioned related description, which will not be repeated here.

[0067] Step 404: When it is confirmed that the blockchain transaction has passed consensus, call the management contract pre-deployed at the blockchain node to perform security verification on the blockchain transaction through the transaction verification rules in the management contract.

[0068] After a blockchain transaction passes consensus, the blockchain node will usually assume that there is no problem with the blockchain transaction and it can be executed directly, and will not perform other checks or verifications on the blockchain transaction before executing the blockchain transaction. In the technical solution of this specification, the blockchain node can call the management contract to perform further security verification on the blockchain transaction based on the transaction verification rules in the management contract after confirming that the blockchain transaction has passed consensus. In the related art, by adding a gateway to the network, the passing traffic can be managed, such as filtering out traffic that may pose security risks. The management contract used in this specification can achieve a role similar to that of a gateway. For example, the management contract can screen blockchain transactions to filter out blockchain transactions that do not comply with the transaction verification rules, so that the blockchain node only executes blockchain transactions that comply with the transaction verification rules, thereby avoiding security risks that may be caused by the execution of blockchain transactions, thereby helping to improve the security of executing transactions on the blockchain.

[0069] Before performing security verification on blockchain transactions, blockchain nodes can first parse blockchain transactions to obtain data to be tested that can be used for security verification. The data to be tested can be used to compare with the preset data range in the transaction verification rules. When the data to be tested of the blockchain transaction is within the preset data range of the transaction verification rules, it can be determined that the blockchain transaction has passed the security verification. For example, the data to be tested can be the account address of the transaction initiator, or when the blockchain transaction is a transfer transaction, the data to be tested can be the specific content of the transfer included in the transaction, such as the specific amount of the transfer or the account address of the transfer object, or when the blockchain transaction is a transaction that calls a contract, the data to be tested can be the contract address of the smart contract to be called by the exchange, etc., and this specification does not limit this. In actual applications, the type of verification data and the specific form of verification targeted by the transaction verification rules can be configured by those skilled in the art according to actual needs.

[0070] The specific content of the transaction verification rules in the management contract can be set in a targeted manner for existing blockchain attack forms. For example, for overflow attacks, usually the attacker of overflow attacks will set the transaction amount in the blockchain transaction to a huge amount. Accordingly, a threshold can be set for the parameter of transaction amount in the transaction verification rules. If the transaction amount of the blockchain transaction received by the blockchain node exceeds the preset amount threshold, it is considered that the blockchain transaction may be an attack transaction of overflow attacks, and the blockchain node refuses to execute the blockchain transaction. For another example, for reentrancy attacks, since the attack method of reentrancy attacks is to call transactions multiple times in a short period of time, a threshold can be set for the parameter of transaction frequency in the transaction verification rules. If the blockchain node obtains a large number of blockchain transactions per unit time, and the frequency of receiving transactions exceeds the preset frequency threshold in the transaction verification rules, it is considered that the blockchain transaction may be an attack transaction of reentrancy attacks, and the blockchain node refuses to execute the blockchain transaction. For example, for denial of service attacks, since denial of service attacks mainly involve a large amount of data in blockchain transactions, which occupies a large amount of processing and computing resources on blockchain nodes, resulting in the inability of blockchain nodes to provide other services normally, a threshold can be set for the data volume parameter in the transaction verification rules. When the data volume of a blockchain transaction obtained by a blockchain node exceeds the preset data volume threshold, the blockchain transaction is considered to be an attack transaction of a denial of service attack, and the blockchain node refuses to execute the transaction. For example, for a user account that has repeatedly initiated malicious transactions to undermine the security of blockchain transactions, it can be added to the account blacklist of the transaction verification rules, and the blockchain node can refuse to execute all blockchain transactions initiated by user accounts in the account blacklist according to the transaction verification rules.

[0071] After confirming that the blockchain transaction has passed the consensus, the blockchain node can spontaneously call the management contract without being called by the blockchain transaction. Therefore, when creating the blockchain transaction, the initiator of the blockchain transaction does not need to pay attention to the security verification process in this specification, and does not need to actively add the call information of the management contract in the blockchain transaction. In fact, the security verification process may be imperceptible to the initiator of the blockchain transaction. Then, for some initiators who actively carry out attacks, since these initiators will definitely not actively call the management contract in the blockchain transaction, this specification can ensure that the blockchain transactions initiated by these initiators can go through the above-mentioned security verification process to avoid the attack from taking effect.

[0072] In one embodiment, the management contract includes an interface contract and a verification contract. The interface contract is used to provide a unique and unchanging calling interface to the outside, and the transaction verification rules for security verification of blockchain transactions are maintained in the verification contract. After the blockchain transaction passes the consensus, the blockchain node can call the interface contract through the predefined interface (i.e., the unique and unchanging calling interface mentioned above), and the contract address of the verification contract is maintained in the interface contract, so that the blockchain node can further call the verification contract based on the contract address in the interface contract, and then judge whether the blockchain transaction is safe according to the transaction verification rules maintained by the verification contract.

[0073] Specifically, in order to enable blockchain nodes to spontaneously call management contracts, interface contracts can be deployed in the blockchain platform chain code running on blockchain nodes. The blockchain node itself is a logical concept. By creating a node instance on a node device and having the node instance run the above blockchain platform chain code, the node instance can be made into a blockchain node. It can be seen that the blockchain platform chain code is the underlying logic that makes the node instance a blockchain node. Therefore, the blockchain node can directly execute the blockchain platform chain code during operation, so that the blockchain node can actively trigger the call to the interface contract through the predefined interface recorded in the blockchain platform chain code, without the need for blockchain transactions to call the interface contract as in the related art.

[0074] Different from the interface contract deployed in the blockchain platform chain code, the verification contract needs to be combined with the above Figure 1The verification contract is deployed to the blockchain in the manner shown. For example, the verification contract can be a genesis contract, that is, the verification contract is deployed in the genesis block at the beginning of the creation of the blockchain network. For another example, the verification contract can be a system contract, which needs to be deployed by an administrator. In some cases, the deployment may be completed with the approval of administrators exceeding a preset ratio. Of course, it is not ruled out that in some cases, the verification contract may be deployed by general members of the blockchain network, that is, the verification contract may be a common contract that is different from the genesis contract and the system contract. Since the interface contract is located in the blockchain platform chain code, it is difficult to upgrade the interface contract and the feasibility is low; and whether it is a genesis contract, a system contract or an ordinary contract, since the verification contract is deployed in the blockchain, it is easy to update the verification contract. Of course, since the transaction verification rules are maintained in the verification contract, the verification contract is often updated for the purpose of adjusting the transaction verification rules, and there is generally no need to update the interface contract.

[0075] In this specification, the contract address of the verification contract is recorded in the corresponding world state of the above-mentioned interface contract. When updating the verification contract, it is only necessary to deploy the updated verification contract containing the new transaction verification rules in the blockchain, and update the value of the above-mentioned world state of the interface contract to the contract address of the updated verification contract: Since the calling interface of the interface contract has not changed, the blockchain node can always call the interface contract through a unified interface, and call the updated verification contract according to the contract address maintained by the interface contract in the world state, and then perform security verification on the blockchain transaction according to the new transaction verification rules. A blockchain transaction that calls the interface contract can be initiated, and the contract address of the updated verification contract can be provided as an input parameter to the interface contract by the blockchain transaction, and then updated to the value of the world state corresponding to the interface contract; wherein, the blockchain transaction that calls the interface contract can be initiated by the blockchain administrator to ensure security.

[0076] Step 406: If it is confirmed that the blockchain transaction passes the security check, execute the blockchain transaction; and if it is confirmed that the blockchain transaction does not pass the security check, refuse to execute the blockchain transaction.

[0077] In the technical solution of this specification, blockchain transactions may include transactions that call smart contracts as described above; or, blockchain transactions may also include transactions that are unrelated to smart contracts, which only need to implement simple transaction logic and do not need to use smart contracts to implement complex transaction logic. For example, simple transaction logic may include transfers, etc. Then, after the blockchain node determines that the received blockchain transaction has passed the security check of the management contract, if the blockchain transaction is not a transaction that calls a smart contract, such as a transfer transaction, the transfer transaction may be executed through the management contract to transfer the account, that is, the management contract can be used to complete simple transaction logic such as transfer in addition to security verification; if the blockchain transaction is a transaction that calls a business contract, the business contract is mobilized to execute the blockchain transaction. If the blockchain node confirms that the blockchain transaction has not passed the security check, it refuses to execute the blockchain transaction and continues to process other received blockchain transactions.

[0078] Furthermore, the management contract in this specification does not always remain unchanged. As the form of blockchain attack is updated, the transaction verification rules in this specification will also change accordingly. If necessary, new transaction verification rules can be added on the basis of the original transaction verification rules of the management contract, or part of the original transaction verification rules can be deleted, or the original transaction verification rules can be modified by modifying the preset thresholds in the original transaction rules. For example, the transaction verification rules in the management contract are used to check whether the transaction amount is within the preset amount range when receiving a transfer transaction and check whether the transfer object account of the transaction is in the blacklist account. On the basis of the transaction verification rules, the value of the original preset amount range can be modified, some accounts in the original blacklist account can be deleted, or new inspection rules can be added.

[0079] The specific content of the transaction verification rules to be updated can be decided by the blockchain network administrator, or the administrator can propose an update to the transaction verification rules outside the chain, and some or all blockchain users can vote on the update proposal. If the voting results meet the specific rules, the transaction verification rules are updated according to the update proposal. This specification does not limit this. For example, the blockchain network administrator can provide users with one or more update proposals for managing contract transaction verification rules on an off-chain website, so that users of the blockchain network can vote on the update proposal on the off-chain website, and finally select the update proposal with the most votes or more than the preset number of votes to update the transaction verification rules based on the voting results of the users. This specification does not limit this. In addition to the off-chain voting method, blockchain users can also vote by signing the update proposal. The blockchain administrator or ordinary blockchain user initiates the update proposal off-chain, and the members of the blockchain network sign it according to whether they agree with the update proposal. For example, the members of the blockchain network can sign the update proposal only if they agree with the update proposal according to the pre-defined rules, and can broadcast the signature to other blockchain nodes, so that all blockchain users in the blockchain network can know the signature results of other blockchain users. When there are no less than a preset number or a preset ratio of blockchain network members who sign the update proposal, the blockchain network administrator updates the transaction verification rules according to the update proposal. Among them, the users participating in the signature can be all users in the blockchain network, or only all administrators with higher permissions, and this manual does not limit this.

[0080] Although this application does not limit the storage location of the transaction verification rules in the verification contract, it should be understood that if the transaction verification rules are written in the contract code of the verification contract, since the contract code of the smart contract cannot be changed after being put on the chain, when updating the transaction verification rules, it is necessary to redeploy the verification contract containing the new transaction verification rules on the blockchain; if the transaction verification rules are written in the world state of the verification contract, there is no need to update the transaction verification rules by deploying a new verification contract, but instead, an update transaction for the transaction verification rules can be directly initiated to update the value of the world state of the verification contract to the new transaction verification rule.

[0081] On the basis of the above-mentioned update of transaction verification rules, if only the updated verification contract is deployed on the blockchain, the blockchain node will still call the original verification contract after receiving the blockchain transaction according to the original call logic. Therefore, in addition to deploying the updated verification contract containing the new transaction verification rules, it is also necessary to change the value of the corresponding world state of the interface contract accordingly. Among them, the deployment of the updated verification contract and the update of the world state value of the interface contract can be completed through two blockchain transactions respectively. For example, the blockchain network administrator can first send a transaction containing the information of creating the updated verification contract to the blockchain network. When it is determined that the blockchain transaction has passed the consensus, the updated verification contract is successfully deployed on the blockchain and the corresponding contract address is generated. On this basis, the blockchain network administrator can initiate a contract update transaction based on the contract address of the updated verification contract, so that the blockchain node calls the interface contract after receiving the contract update transaction, and updates the value of the world state corresponding to the interface contract to the contract address of the updated verification contract. In addition, the deployment of the updated verification contract and the update of the interface contract world state value can also be completed through only one blockchain transaction. For example, the blockchain network administrator can initiate a contract update transaction including the updated verification contract. After receiving the contract update transaction, the blockchain node can create and deploy the updated verification contract to the blockchain, so that a contract address corresponding to the updated verification contract is generated on the blockchain. The blockchain node then modifies the corresponding world state value of the interface contract according to the contract address. The deployment method of the updated verification contract can refer to the above Figure 1 This manual does not restrict the relevant content of the deployment smart contract shown. It should be noted that the update transaction of the management contract can only be initiated by the administrator of the blockchain network, that is, the administrator is only allowed to update the original management contract of the blockchain network, avoiding opening the modification rights of the management contract to ordinary users to prevent the resulting security issues.

[0082] By updating the transaction verification rules in the verification contract and the calling logic of the verification contract, although the blockchain node will still call the interface contract according to the original preset interface when receiving the blockchain transaction, the contract address maintained by the interface contract has been modified to the contract address of the updated verification contract. The interface contract can further call the updated verification contract according to the contract address of the updated verification contract, so that the security of the blockchain transaction can be verified according to the new transaction verification rules.

[0083] For any of the above embodiments, if the blockchain network is a consortium chain, the blockchain nodes in the consortium chain can be divided into multiple types based on whether they participate in consensus. For example, the blockchain nodes participating in consensus are called execution nodes, and the blockchain nodes not participating in consensus are called synchronization nodes. Synchronization nodes do not participate in consensus and execute blockchain transactions, but directly synchronize blocks from execution nodes or other synchronization nodes. Therefore, the technical solution disclosed in this specification can only be applied to execution nodes in the consortium chain, that is, only execution nodes perform security verification on blockchain transactions through management contracts, and synchronization nodes may not participate.

[0084] This specification adds a management contract to the blockchain system so that all blockchain transactions must be screened by the management contract before being executed. The blockchain node only executes blockchain transactions that meet the security verification of the management contract. In addition, the management contract in this specification can flexibly set different transaction verification rules to solve the security problem of the blockchain network in the face of different forms of attack transactions. Figure 5 Taking the blockchain node 3 in the blockchain network environment as an example, Figure 2 The smart contract call transaction shown, combined with Figure 6 Detailed description is given. Figure 6 This is a flowchart of a method for processing a blockchain transaction according to an exemplary embodiment of this specification. Figure 6 As shown, the following steps may be included:

[0085] Step 602: Blockchain node 3 receives the blockchain transaction sent by device 4.

[0086] For example, blockchain node 3 in blockchain system 503 receives a blockchain transaction sent by user Bob through device 4, and the blockchain transaction is signed by user Bob's account private key.

[0087] Step 604: Blockchain node 3 determines whether the blockchain transaction has passed the legitimacy verification.

[0088] After receiving the blockchain transaction, blockchain node 3 verifies the digital signature carried by the blockchain transaction based on the local stored public key of user Bob's account.

[0089] Alternatively, the blockchain transaction carries a CA certificate issued by the CA center to the user Bob's account. The CA certificate stores the user Bob's account public key and is signed by the CA center's private key. After receiving the blockchain transaction, blockchain node 3 can use the CA center's public key to verify the digital signature of the CA certificate, and obtain the user Bob's account public key contained in the CA certificate after the signature verification is passed, so that the digital signature of the blockchain transaction can be verified using the obtained user Bob's account public key.

[0090] Blockchain node 3 calculates the digital signature using the public key of user Bob, and compares the calculated result with the hash summary of the blockchain transaction. If the comparison fails, blockchain node 3 determines that the received blockchain transaction has not passed the legitimacy verification and goes to step 614; if the comparison succeeds, blockchain node 3 determines that the received blockchain transaction has passed the legitimacy verification and goes to step 606.

[0091] Step 606: Blockchain node 3 and other blockchain nodes in the blockchain system 503 reach consensus on the blockchain transaction.

[0092] For example, if the consensus algorithm adopted by the blockchain network is a POW algorithm that requires a contest for the right to record in each accounting cycle, after confirming that the transaction has passed the legality verification, the blockchain node 3 broadcasts it to other blockchain nodes in the blockchain system 503. The node devices competing for the right to record execute the transaction after receiving the blockchain transaction. In the end, one node device may win in the process of competing for the right to record in this round and become the accounting node. The accounting node can package the received blockchain transaction with other transactions to generate a candidate block, and send the generated candidate block or the block header of the candidate block to other node devices for consensus.

[0093] For example, if the consensus algorithm adopted by the blockchain network is a Byzantine fault-tolerant algorithm that does not require competition for accounting rights, blockchain node 3 can send the blockchain transaction to the accounting node of this round, and the accounting node will package the blockchain transaction together with other blockchain transactions to generate a candidate block, and send the generated candidate block or the block header of the candidate block to other node devices for consensus.

[0094] Step 608: Blockchain node 3 calls the management contract to perform security verification.

[0095] In this embodiment, the management contract includes an interface contract and a verification contract. The interface contract is deployed in the blockchain platform code running on the blockchain node, and the contract address of the verification contract is maintained in the corresponding world state. The verification contract maintains preset transaction verification rules.

[0096] After the blockchain transaction consensus is passed, blockchain node 3 calls the interface contract according to the predefined interface recorded in the blockchain platform code, obtains the contract address of the verification contract according to the world state of the interface contract, and calls the corresponding verification contract to verify the received blockchain transaction.

[0097] With the above Figure 2Taking the transaction of calling the smart contract as an example, after the consensus on the blockchain transaction is reached, blockchain node 3 calls the management contract to parse and obtain the From field in the blockchain transaction as "Bob (0xf5e...)", which is the account address that initiates the call to the smart contract. The account address is compared with the blacklist account in the transaction verification rule.

[0098] Or, taking a transfer transaction as an example, blockchain node 3 calls the management contract after reaching consensus on the received transfer transaction, and parses the value field in the transfer transaction. In the blockchain transaction, the "value" field is the amount that the transaction initiator wants to transfer to the transaction recipient, and compares the transaction amount with the preset transaction amount threshold in the transaction verification rule. At the same time, blockchain node 3 can also call the management contract to calculate the frequency of receiving blockchain transactions, and compare the transaction frequency with the preset frequency threshold in the transaction verification rule.

[0099] Step 610: Blockchain node 3 determines whether the blockchain transaction passes the security check.

[0100] Taking the transaction of calling the smart contract as an example, if the account address "Bob (0xf5e...)" exists in the blacklist account of the transaction verification rule, the blockchain transaction cannot pass the security verification of the management contract, and the process goes to step 614. The blockchain node 3 refuses to execute the blockchain transaction and discards the transaction, waiting to process the next blockchain transaction. If the account address does not exist in the blacklist account of the management contract transaction verification rule, it is considered that the blockchain transaction has passed the security verification of the management contract, and the process goes to step 612.

[0101] Taking the above transfer transaction as an example, if the transfer amount or transaction frequency exceeds the preset amount threshold and the preset frequency threshold in the transaction verification rule, the blockchain transaction cannot pass the security verification of the management contract, and the process goes to step 614. The blockchain node 3 refuses to execute the blockchain transaction and discards the transaction, waiting to process the next blockchain transaction. If the transfer amount and transaction frequency do not exceed the preset amount threshold and the preset frequency threshold in the transaction verification rule, the blockchain transaction is considered to have passed the security verification of the management contract, and the process goes to step 612.

[0102] Step 612: Blockchain node 3 executes the blockchain transaction.

[0103] Taking the above-mentioned transaction of calling a smart contract as an example, blockchain node 3 calls the smart contract according to the contract address “0x6f8ae93…” in the blockchain transaction.

[0104] Taking the above transfer transaction as an example, blockchain node 3 transfers money to the transaction recipient address in the transaction according to the transaction amount in the blockchain transaction.

[0105] Step 614: Blockchain node 3 does not execute the blockchain transaction.

[0106] Figure 7 This is a schematic diagram of a blockchain transaction processing electronic device provided by an exemplary embodiment. Please refer to Figure 7 At the hardware level, the device includes a processor 702, an internal bus 704, a network interface 706, a memory 708, and a non-volatile memory 710, and may also include hardware required for other services. One or more embodiments of this specification may be implemented based on software, such as the processor 702 reading the corresponding computer program from the non-volatile memory 710 into the memory 708 and then running it. Of course, in addition to the software implementation, one or more embodiments of this specification do not exclude other implementations, such as logic devices or a combination of software and hardware, etc., that is, the execution subject of the following processing flow is not limited to each logic unit, but can also be hardware or logic devices.

[0107] Please refer to Figure 8 The blockchain transaction processing device can be applied to Figure 7 The device shown in the figure is used to implement the technical solution of this specification. Among them, the blockchain transaction processing device may include:

[0108] The consensus verification unit 802 is configured to verify the legitimacy of the received blockchain transaction, and if the verification passes, reach a consensus on the blockchain transaction with other blockchain nodes in the blockchain network.

[0109] The verification unit 804 is configured to call the management contract pre-deployed in the blockchain node when confirming that the blockchain transaction has passed the consensus, so as to perform security verification on the blockchain transaction through the transaction verification rules in the management contract.

[0110] The execution unit 806 is configured to execute the blockchain transaction if it is confirmed that the blockchain transaction passes the security check; and refuse to execute the blockchain transaction if it is confirmed that the blockchain transaction fails the security check.

[0111] Optionally, the management contract includes an interface contract and a verification contract; the calling of the management contract pre-deployed in the blockchain node includes: calling the interface contract through a predefined interface when the calling conditions of the interface contract are met; wherein the calling conditions of the interface contract include: the blockchain transaction passes consensus; and further calling the verification contract according to the contract address of the verification contract maintained by the interface contract to perform security verification on the blockchain transaction through the transaction verification rules in the verification contract.

[0112] Optionally, the interface contract includes: a system contract deployed in a blockchain platform code running on the blockchain node; wherein the predefined interface is recorded in the blockchain platform code.

[0113] Optionally, the contract address of the verification contract is maintained in the world state corresponding to the interface contract.

[0114] Optionally, the above device further comprises:

[0115] The first update unit 808 is configured to update the contract transaction received, wherein the contract update transaction includes the contract address of the updated verification contract; in response to the contract update transaction, call the interface contract to update the value of the world state to the contract address of the updated verification contract.

[0116] The second update unit 810 is configured to update the contract transaction received, wherein the contract update transaction includes an updated verification contract; in response to the contract update transaction, deploy the updated verification contract, and call the interface contract to update the value of the world state to the contract address of the updated verification contract.

[0117] Optionally, the contract update transaction is submitted by an administrator in the blockchain network; or, the contract update transaction includes signatures of no less than a preset number or a preset proportion of all members of the blockchain network; or, the contract update transaction includes signatures of no less than a preset number or a preset proportion of all administrators of the blockchain network.

[0118] Optionally, the transaction verification rule is used to implement at least one of the following checks:

[0119] Whether the transaction amount is within the preset amount range; whether the transaction data volume is within the preset data volume range; whether the transaction frequency is within the preset frequency range; whether the transaction initiator account is a preset blacklist account.

[0120] Optionally, executing the blockchain transaction includes: if the blockchain transaction is a transfer transaction, executing the transfer transaction through the management contract to perform the transfer; if the blockchain transaction is a transaction that calls a business contract, calling the business contract to execute the blockchain transaction.

[0121] The systems, devices, modules or units described in the above embodiments may be implemented by computer chips or entities, or by products with certain functions. A typical implementation device is a computer, which may be in the form of a personal computer, a laptop computer, a cellular phone, a camera phone, a smart phone, a personal digital assistant, a media player, a navigation device, an email transceiver, a game console, a tablet computer, a wearable device or a combination of any of these devices.

[0122] In a typical configuration, a computer includes one or more processors (CPU), input / output interfaces, network interfaces, and memory.

[0123] Memory may include non-permanent storage in a computer-readable medium, in the form of random access memory (RAM) and / or non-volatile memory, such as read-only memory (ROM) or flash RAM. Memory is an example of a computer-readable medium.

[0124] Computer-readable media include permanent and non-permanent, removable and non-removable media that can be used to store information by any method or technology. Information can be computer-readable instructions, data structures, program modules or other data. Examples of computer storage media include, but are not limited to, phase change memory (PRAM), static random access memory (SRAM), dynamic random access memory (DRAM), other types of random access memory (RAM), read-only memory (ROM), electrically erasable programmable read-only memory (EEPROM), flash memory or other memory technology, compact disc read-only memory (CD-ROM), digital versatile disc (DVD) or other optical storage, magnetic cassettes, disk storage, quantum memory, graphene-based storage media or other magnetic storage devices or any other non-transmission media that can be used to store information that can be accessed by a computing device. As defined herein, computer-readable media does not include temporary computer-readable media (transitory media), such as modulated data signals and carrier waves.

[0125] It should also be noted that the terms "include", "comprises" or any other variations thereof are intended to cover non-exclusive inclusion, so that a process, method, commodity or device including a series of elements includes not only those elements, but also other elements not explicitly listed, or also includes elements inherent to such process, method, commodity or device. In the absence of more restrictions, the elements defined by the sentence "comprises a ..." do not exclude the existence of other identical elements in the process, method, commodity or device including the elements.

[0126] The above is a description of a specific embodiment of the specification. Other embodiments are within the scope of the appended claims. In some cases, the actions or steps recorded in the claims can be performed in an order different from that in the embodiments and still achieve the desired results. In addition, the processes depicted in the drawings do not necessarily require the specific order or continuous order shown to achieve the desired results. In some embodiments, multitasking and parallel processing are also possible or may be advantageous.

[0127] The terms used in one or more embodiments of this specification are only for the purpose of describing specific embodiments, and are not intended to limit one or more embodiments of this specification. The singular forms of "a", "said" and "the" used in one or more embodiments of this specification and the appended claims are also intended to include plural forms, unless the context clearly indicates other meanings. It should also be understood that the term "and / or" used herein refers to and includes any or all possible combinations of one or more associated listed items.

[0128] It should be understood that although the terms first, second, third, etc. may be used to describe various information in one or more embodiments of this specification, these information should not be limited to these terms. These terms are only used to distinguish the same type of information from each other. For example, without departing from the scope of one or more embodiments of this specification, the first information may also be referred to as the second information, and similarly, the second information may also be referred to as the first information. Depending on the context, the word "if" as used herein may be interpreted as "at the time of" or "when" or "in response to determining".

[0129] The above description is merely a preferred embodiment of one or more embodiments of the present specification and is not intended to limit one or more embodiments of the present specification. Any modifications, equivalent substitutions, improvements, etc. made within the spirit and principles of one or more embodiments of the present specification shall be included in the scope of protection of one or more embodiments of the present specification.

Claims

1. A blockchain transaction processing method, applied to a blockchain node in a blockchain network, the method comprising: Verify the legitimacy of the received blockchain transaction, and if the verification passes, reach consensus on the blockchain transaction with other blockchain nodes in the blockchain network; When it is confirmed that the blockchain transaction has passed the consensus, calling the management contract pre-deployed at the blockchain node to perform security verification on the blockchain transaction according to the transaction verification rules in the management contract; If it is confirmed that the blockchain transaction passes the security check, execute the blockchain transaction; and if it is confirmed that the blockchain transaction fails the security check, refuse to execute the blockchain transaction; The management contract includes an interface contract and a verification contract; The calling of the management contract pre-deployed in the blockchain node includes: When the calling conditions of the interface contract are met, the interface contract is called through a predefined interface; wherein the predefined interface is recorded in the blockchain platform code running on the blockchain node, and the calling conditions of the interface contract include: the blockchain transaction passes consensus; According to the contract address of the verification contract maintained by the interface contract, the verification contract is further called to perform security verification on the blockchain transaction through the transaction verification rules in the verification contract.

2. According to the method of claim 1, the interface contract comprises: A system contract deployed in the blockchain platform code.

3. According to the method of claim 1, the contract address of the verification contract is maintained in the world state corresponding to the interface contract.

4. The method according to claim 3, further comprising: According to the received contract update transaction, the contract update transaction includes the contract address of the updated verification contract; In response to the contract update transaction, the interface contract is called to update the value of the world state to the contract address of the updated verification contract.

5. The method according to claim 3, further comprising: According to the received contract update transaction, the contract update transaction includes an updated verification contract; In response to the contract update transaction, the updated verification contract is deployed, and the interface contract is called to update the value of the world state to the contract address of the updated verification contract.

6. According to the method of claim 4 or 5, the contract update transaction is submitted by an administrator in the blockchain network; or, the contract update transaction contains signatures of no less than a preset number or a preset proportion of all members of the blockchain network; or, the contract update transaction contains signatures of no less than a preset number or a preset proportion of all administrators of the blockchain network.

7. The method according to claim 1, wherein the transaction verification rule is used to implement at least one of the following checks: Whether the transaction amount is within the preset amount range; Whether the transaction data volume is within the preset data volume range; Whether the transaction frequency is within the preset frequency range; Whether the transaction initiator account is a preset blacklist account.

8. The method according to claim 1, wherein executing the blockchain transaction comprises: If the blockchain transaction is a transfer transaction, the transfer transaction is executed through the management contract to perform the transfer; If the blockchain transaction is a transaction that calls a business contract, then the business contract is called to execute the blockchain transaction.

9. According to the method described in any one of claims 1-5 and 7-8, the blockchain network is a consortium chain, and the blockchain node is an execution node in the consortium chain.

10. A blockchain transaction processing device, applied to a blockchain node in a blockchain network, the device comprising: A verification consensus unit is used to verify the legitimacy of the received blockchain transaction, and if the verification passes, reach a consensus on the blockchain transaction with other blockchain nodes in the blockchain network; A verification unit, configured to, when confirming that the blockchain transaction has passed the consensus, call a management contract pre-deployed at the blockchain node to perform security verification on the blockchain transaction according to the transaction verification rules in the management contract; The management contract includes an interface contract and a verification contract; The calling of the management contract pre-deployed in the blockchain node includes: calling the interface contract through a predefined interface when the calling condition of the interface contract is met; wherein the predefined interface is recorded in the blockchain platform code running on the blockchain node, and the calling condition of the interface contract includes: the blockchain transaction passes the consensus; according to the contract address of the verification contract maintained by the interface contract, further calling the verification contract to perform security verification on the blockchain transaction through the transaction verification rules in the verification contract; The execution unit is used to execute the blockchain transaction if it is confirmed that the blockchain transaction passes the security check; and refuse to execute the blockchain transaction if it is confirmed that the blockchain transaction fails the security check.

11. An electronic device, characterized in that: include: processor; a memory for storing processor-executable instructions; The processor implements the method according to any one of claims 1 to 9 by running the executable instructions.

12. A computer-readable storage medium having computer instructions stored thereon, characterized in that: When the instruction is executed by a processor, the steps of the method according to any one of claims 1 to 9 are implemented.

Images