WO2024001025A1 - 一种预执行缓存数据清理方法和区块链节点 - Google Patents

一种预执行缓存数据清理方法和区块链节点 Download PDF

Info

Publication number
WO2024001025A1
WO2024001025A1 PCT/CN2022/135327 CN2022135327W WO2024001025A1 WO 2024001025 A1 WO2024001025 A1 WO 2024001025A1 CN 2022135327 W CN2022135327 W CN 2022135327W WO 2024001025 A1 WO2024001025 A1 WO 2024001025A1
Authority
WO
WIPO (PCT)
Prior art keywords
execution
transaction
variable
state
memory
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Ceased
Application number
PCT/CN2022/135327
Other languages
English (en)
French (fr)
Inventor
王江
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Ant Blockchain Technology Shanghai Co Ltd
Original Assignee
Ant Blockchain Technology Shanghai Co Ltd
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Ant Blockchain Technology Shanghai Co Ltd filed Critical Ant Blockchain Technology Shanghai Co Ltd
Publication of WO2024001025A1 publication Critical patent/WO2024001025A1/zh
Anticipated expiration legal-status Critical
Ceased legal-status Critical Current

Links

Images

Classifications

    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/20—Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
    • G06F16/21—Design, administration or maintenance of databases
    • G06F16/215—Improving data quality; Data cleansing, e.g. de-duplication, removing invalid entries or correcting typographical errors
    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/20—Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
    • G06F16/27—Replication, distribution or synchronisation of data between databases or within a distributed database system; Distributed database system architectures therefor
    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q40/00—Finance; Insurance; Tax strategies; Processing of corporate or income taxes
    • G06Q40/04—Trading; Exchange, e.g. stocks, commodities, derivatives or currency exchange
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • H04L9/3226—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials using a predetermined code, e.g. password, passphrase or PIN

Definitions

  • the embodiments of this specification belong to the field of blockchain technology, and particularly relate to a pre-execution cache data cleaning method and blockchain nodes.
  • Blockchain is a new application model of computer technology such as distributed data storage, point-to-point transmission, consensus mechanism, and encryption algorithm.
  • data blocks are combined into a chained data structure in a chronological manner and are cryptographically guaranteed to be an untamperable and unforgeable distributed ledger. Due to the characteristics of blockchain, such as decentralization, non-tamperable information, and autonomy, blockchain has also received more and more attention and applications.
  • the purpose of the present invention is to provide a pre-execution data cleaning solution that can effectively clean cached pre-execution data.
  • a first aspect of this specification provides a method for executing transactions in a blockchain.
  • the blockchain includes a master node and a plurality of slave nodes.
  • the method is executed by the master node and includes:
  • the pre-execution of the first transaction is terminated and the first information is recorded. Used to indicate that the first transaction includes a call to a preset type of contract, where the execution of the preset type of contract relies on data generated by consensus;
  • the consensus proposal is sent to at least some slave nodes, and the consensus proposal is reached with the at least some slave nodes.
  • the second aspect of this specification provides a blockchain node, including:
  • the acquisition unit is used to obtain the identifiers of multiple transactions included in the generated first block
  • a reading unit configured to, for the first transaction among the plurality of transactions, read the first state of the first variable written by the first transaction during pre-execution in the memory according to the identifier of the first transaction. Information; read the second state information of the first variable from the pre-execution state set stored in the memory;
  • a deletion unit configured to delete the state data of the first variable in the pre-execution state set when the first state information is consistent with the second state information.
  • a third aspect of this specification provides a computer-readable storage medium on which a computer program is stored.
  • the computer program is executed in a computer, the computer is caused to execute the method described in the first aspect.
  • a fourth aspect of this specification provides a computing device, including a memory and a processor.
  • the memory stores executable code.
  • the processor executes the executable code, the method described in the first aspect is implemented.
  • the persistent deletion can be performed in the pre-execution status set.
  • the stored variable status ensures the correctness of status cleaning.
  • Figure 1 is a block chain architecture diagram in the embodiment of this specification.
  • Figure 2 shows the blockchain structure diagram in the embodiment of this specification
  • Figure 3 is a flow chart of a method for executing transactions in the embodiment of this specification
  • Figure 4 is a flow chart of the pre-execution data cleaning method in the embodiment of this specification.
  • Figure 5 is an architectural diagram of a blockchain node in an embodiment of this specification.
  • Figure 1 shows the blockchain architecture diagram in the embodiment of this specification.
  • the blockchain includes, for example, a total of 6 nodes including master node 1, slave node 2 to slave node 5.
  • the connections between nodes schematically represent P2P (Peer to Peer, point-to-point) connections.
  • P2P Peer to Peer, point-to-point
  • These nodes store the entire ledger, which stores the status of all blocks and all accounts.
  • each node in the blockchain generates the same state in the blockchain by executing the same transaction, and each node in the blockchain stores the same state database.
  • the master node 1 can be responsible for receiving transactions from the client and initiating a consensus proposal to each slave node.
  • the consensus proposal includes, for example, multiple transactions in the block to be formed (such as block B1) and each Transaction submission order and other information. After the nodes in the blockchain successfully reach consensus on the consensus proposal, each node can execute the multiple transactions according to the submission order in the consensus proposal, thereby generating block B1.
  • the blockchain shown in FIG. 1 is only exemplary, and the embodiments of this specification are not limited to application to the blockchain shown in FIG. 1 , and may also be applied to a blockchain system including sharding, for example.
  • FIG. 1 shows that the blockchain includes 6 nodes
  • the embodiments of this specification are not limited to this, and may include other numbers of nodes.
  • the nodes included in the blockchain can meet Byzantine Fault Tolerance (BFT) requirements.
  • BFT Byzantine Fault Tolerance
  • the mentioned Byzantine fault tolerance requirements can be understood as meaning that Byzantine nodes can exist within the blockchain, but the blockchain does not reflect Byzantine behavior externally.
  • some Byzantine fault-tolerant algorithms require the number of nodes to be greater than 3f+1, where f is the number of Byzantine nodes, such as the Practical Byzantine Fault Tolerance algorithm PBFT (Practical Byzantine Fault Tolerance).
  • Transactions in the blockchain field can refer to task units that are executed and recorded in the blockchain. Transactions usually include sending fields (From), receiving fields (To) and data fields (Data). Among them, when the transaction is a transfer transaction, the From field represents the account address that initiated the transaction (that is, initiated a transfer task to another account), the To field represents the account address that received the transaction (that is, received the transfer), and the Data field Include transfer amount.
  • the From field indicates the account address that initiated the transaction
  • the To field indicates the account address of the contract called by the exchange
  • the Data field includes the function name in the calling contract and the corresponding Data such as the incoming parameters of the function are used to obtain the code of the function from the blockchain and execute the code of the function when the transaction is executed.
  • Smart contracts on the blockchain are contracts that can be triggered and executed by transactions on the blockchain system. Smart contracts can be defined in the form of code. Calling a smart contract in the blockchain is to initiate a transaction pointing to the smart contract address, allowing each node in the blockchain to run the smart contract code in a distributed manner. It should be noted that in addition to smart contracts created by users, smart contracts can also be set by the system in the genesis block. This type of contract is generally called a creation contract. Generally, some blockchain data structures, parameters, properties and methods can be set in the genesis contract. In addition, accounts with system administrator rights can create system-level contracts or modify system-level contracts (referred to as system contracts). Among them, the system contract can be used to add data structures for different business data in the blockchain.
  • Bob sends a transaction containing information about creating a smart contract (i.e., deploying the contract) to the blockchain as shown in Figure 1.
  • the data field of the transaction includes the code of the contract to be created (such as bytecode or machine code), the to field of the transaction is empty to indicate that the transaction is used to deploy the contract.
  • the contract address "0x6f8ae93" of the contract is determined.
  • Each node adds the contract account corresponding to the contract address of the smart contract in the state database, allocates the state storage corresponding to the contract account, and stores The contract code is saved in the state storage of the contract, so the contract is created successfully.
  • each node in the blockchain can execute the transaction respectively, thereby executing the contract respectively, and update the status database based on the execution of the contract.
  • the blockchain node can execute transactions in parallel through multiple processes in a single machine.
  • the blockchain node can be deployed in a server cluster and execute transactions in parallel through multiple servers.
  • the blockchain node first divides multiple transactions into multiple transaction groups according to the accounts accessed by the transactions. Each transaction group does not access the same account, so that each transaction group can be executed in parallel.
  • a smart contract is called in a transaction, the variables accessed in the transaction cannot be predicted before the transaction is executed, so multiple transactions cannot be effectively grouped, and transactions cannot be executed in parallel.
  • multiple transactions can be pre-executed by the master node to obtain respective pre-execution read and write sets of the multiple transactions, and based on the pre-execution read and write sets Write sets divide multiple transactions into multiple groups so that each slave node can execute multiple transactions in parallel according to multiple groups.
  • this article mainly uses a blockchain including a master node and a slave node as an example to describe the solutions of the embodiments of this specification.
  • the embodiments of this specification are not limited to blockchains including a master-slave structure, but can also be applied to any blockchain.
  • the main structure of the blockchain in a blockchain with no master structure, each blockchain node can perform the same steps as the master node.
  • FIG. 2 shows a structural diagram of the master node 1 and slave nodes (for example, slave node 2) of the blockchain provided by the embodiment of this specification.
  • the master node 1 includes a pre-execution module 11, a conflict detection module 12 and a consensus module 13, and the slave node 2 includes a consensus module 22 and a calculation module 23.
  • Masternode 1 can for example be connected to a client so that multiple transactions can be received from the client.
  • the pre-execution module 11 pre-executes the transaction and obtains the pre-execution read and write set of the transaction.
  • the pre-execution read and write set includes a pre-execution read set and a pre-execution write set.
  • the pre-execution read set can specifically be the key-value pairs of read variables generated during the pre-execution transaction.
  • the pre-execution write set can specifically be The key-value pair of the written variable generated during the pre-execution transaction, where the variable can be an external account in the blockchain, or it can be a contract variable defined in the contract.
  • the master node 1 can maintain a pre-execution status set, and the pre-execution module 11 can read the status values of variables from the pre-execution status set or the status database when pre-executing a transaction. After pre-executing the transaction, the pre-execution module 11 can update the pre-execution status set according to the pre-execution read and write set of the transaction.
  • the pre-execution module 11 may include multiple pre-execution sub-modules, such as the pre-execution sub-module 111 and the pre-execution sub-module 112. These two pre-execution sub-modules can pre-execute transactions in parallel.
  • the conflict detection module 12 includes a pre-execution status set and a pre-execution transaction set, wherein the master node 1 stores the pre-execution status set and the pre-execution transaction set in the memory for use by the conflict detection module 12 .
  • the conflict detection module 12 performs pre-execution conflict detection on each transaction serially.
  • the conflict detection module 12 detects whether there is a conflict between the pre-execution read set of the transaction and the write set of the transaction that has been pre-executed. If the value of a certain variable in the pre-execution read set of the transaction is inconsistent with the variable in the pre-execution status set If the values are different, it can be determined that there is a conflict. If it is determined that there is no conflict, the conflict detection module 12 updates the status in the pre-execution write set of the transaction to the pre-execution status set, and arranges the transaction sequence into the pre-execution transaction set.
  • the master node 1 initiates a consensus proposal to the consensus module (such as the consensus module 22) of each slave node, where the consensus proposal may include the consensus module 13 obtaining multiple previously recorded sequential transactions from the pre-execution transaction set. , the arrangement order of the multiple transactions in the pre-execution transaction set, and the pre-execution read and write set of the multiple transactions. It can be understood that the master node can also broadcast the multiple transactions to the slave nodes, so that the multiple transactions may not be included in the consensus proposal.
  • the consensus module such as the consensus module 22
  • slave node 2 can group the multiple transactions according to their respective pre-execution read and write sets to obtain multiple transaction groups. There are no differences between each transaction group. There is a conflicting transaction. Among them, the situation where there are conflicting transactions between two transaction groups usually includes the following situations: the transaction in the first transaction group reads the first variable (that is, the first transaction group reads the first variable), and the second transaction group writes The first variable; the first trading group writes the first variable, the second trading group writes the first variable; the first trading group reads the first variable and writes the first variable, and the second trading group writes the first variable; The first transaction group reads the first variable and writes the first variable, and the second transaction group reads the first variable and writes the first variable. Among them, if two transaction groups read the same variables, it can be considered that there is no conflicting transaction. Generally, in order to simplify the solution, slave node 2 can group multiple transactions according to the requirement that the same variables are not accessed between each transaction group.
  • the computing module 23 in the slave node 2 can execute the plurality of transactions in parallel in groups.
  • the computing module 23 of the slave node 2 includes multiple execution sub-modules (the figure schematically shows the execution sub-module 232, the execution sub-module 233 and the execution sub-module 234).
  • each execution sub-module can verify the correctness of the grouping based on the obtained execution read-write set of the transaction and the pre-execution read-write set of each transaction, thereby verifying whether the master node is doing evil.
  • the master node can pre-execute the transaction based on the state of the pre-execution state set cached in the memory, and update the pre-execution state set according to the pre-execution write set of the transaction, so that the state based on the transaction during pre-execution is consistent with the state of the pre-execution write set.
  • the state based on the transaction when executed is consistent, so that the pre-execution result of the transaction is consistent with the execution result when the master node does not do evil.
  • the read-write set, status data and other data generated during the pre-execution process cannot be directly saved to the data storage of the blockchain as real results.
  • the read-write set and status data are usually Stored in memory, or in the memory of the cache service (the process that provides the cache service). But the memory capacity is limited. Therefore, a cache data cleaning solution is needed that can not only reduce the amount of cached data, but also ensure that the state based on the transaction during pre-execution is consistent with the state based on the transaction during execution.
  • the embodiment of this specification provides a pre-execution cache data cleaning solution.
  • the state centralizes deletion of persistently stored variable states, ensuring the correctness of state cleaning.
  • step S301 the master node 1 pre-executes the transaction and obtains the pre-execution read and write set of each transaction.
  • Master node 1 can pre-execute the transaction immediately after receiving a transaction. Master node 1 can pre-execute multiple transactions received at the same time in parallel. Specifically, when master node 1 is pre-executing a transaction, when the value of any variable is read from the pre-execution state set or the state database in Figure 2, the read value is recorded in the read cache of the transaction set in the memory. The key-value pair of the variable. When the value of any variable is written, the key-value pair of the written variable is recorded in the write cache of the transaction, and after the pre-execution is completed, it can be based on the read cache and write cache of the transaction. Get the pre-execution read-write set for this transaction.
  • the master node 1 may include a storage device (not shown in Figure 2) for storing a state database.
  • the state database stores the world state of the variables defined by accounts and contracts in the blockchain.
  • the state database is updated based on the execution results of each transaction in the block.
  • the master node 1 when the master node 1 reads a variable (such as variable A) during the pre-execution of the transaction, the master node 1 first determines whether the value of variable A is stored in the write cache of the transaction. If the value of variable A is stored, The value of variable A can be read directly from the write cache. In the case where it is determined that the value of variable A is not stored in the write cache, it is determined whether the value of variable A is stored in the read cache of the transaction. If the value of variable A is stored, the value of variable A can be read from the read cache. . When it is determined that the value of variable A is not stored in the read cache, it is determined whether the value of variable A is stored in the pre-execution state set.
  • a variable such as variable A
  • the value of variable A can be read from the pre-execution state set. .
  • the value of variable A may be read from the state database. That is to say, during the process of pre-execution of the transaction, the priority of the master node 1 to read the variables is: transaction write cache > transaction read cache > pre-execution status set > status database. This can ensure that the reads during the pre-execution process are The value of the variable taken is the latest value of the variable.
  • the master node 1 After pre-executing each transaction as described above, the master node 1 obtains the pre-execution read and write set of each transaction.
  • the pre-execution read-write set includes a read set and a write set, wherein the read set includes key-value pairs (key-values) of variables read when pre-executing the transaction, and the write set includes pre-execute the The key-value pair of the variable written during the transaction.
  • the blockchain node may write to different variables based on the values of the variables read during the execution of the contract called by the transaction. For example, when the value of the read variable is 1, write 10 to variable a, when the value of the read variable is 2, write 20 to variable b, and so on. Therefore, for a transaction that calls a contract, the blockchain node must execute the transaction to determine the variables read and written by the transaction, thereby obtaining the read and write set of the transaction. To this end, the master node 1 obtains the pre-execution read and write set of each transaction by pre-executing each of the multiple transactions. The pre-execution process is basically the same as the process of executing the transaction.
  • the difference is that the pre-execution of the pair of transactions is Execution is the execution process that takes place before consensus, and the execution of transactions is the execution process that takes place after consensus. And the pre-execution result of the pre-execution transaction is only used to update the pre-execution state set, not to update the world state, while the execution result of the execution transaction is used to update the world state.
  • step S303 the master node 1 determines whether the pre-execution read set of the transaction conflicts with the pre-execution status set.
  • the pre-execution status set is the latest status value of each variable cached by master node 1 during the pre-execution of each transaction. After pre-executing each transaction, the master node 1 performs pre-execution conflict detection on each transaction serially.
  • master node 1 when master node 1 performs pre-execution conflict detection on transaction Tx1 among the multiple transactions, it first determines whether the pre-execution status set includes variables (such as variable A) in the pre-execution read set of transaction Tx1. If not, it is similarly determined whether other variables in the pre-execution read set of transaction Tx1 are included in the pre-execution state set.
  • variables such as variable A
  • the pre-execution status set does not include all the variables in the pre-execution read set of transaction Tx1, that is, the previous transaction that has passed pre-execution conflict detection has not read or written the variables accessed by this transaction, then the pre-execution of transaction Tx1 can be determined There is no conflict between the read set and the pre-execution status set, that is, it is determined that the pre-execution of the transaction Tx1 does not conflict with the previous transactions that have undergone pre-execution conflict detection.
  • master node 1 determines whether the value of variable A in the pre-execution read set is consistent with the value of variable A in the pre-execution status set. If they are consistent, it indicates that the variable A read by the transaction The value of is the latest status of variable A during pre-execution.
  • master node 1 determines that the value read for each variable in the pre-execution read set of transaction Tx1 is the latest state in the pre-execution process, it can be determined that there is no conflict between the pre-execution read set and the pre-execution status set of transaction Tx1.
  • master node 1 determines that the value of variable A in the pre-execution read set of transaction Tx1 is inconsistent with the value of variable A in the pre-execution state set, it means that the value of variable A read by transaction Tx1 is not the latest state in the pre-execution process, so , it can be determined that there is a conflict between the pre-execution read set and the pre-execution status set of transaction Tx1. In the case where it is determined that a conflict exists, the master node 1 can re-pre-execute the transaction Tx1 by executing step S301.
  • step S305 when the master node 1 determines that there is no conflict between the pre-execution read set and the pre-execution status set of the transaction, it updates the pre-execution status set and the pre-execution transaction set in the memory based on the pre-execution read and write set of the transaction.
  • the master node 1 determines that there is no conflict between the pre-execution read set and the pre-execution status set of the transaction Tx2 in the multiple transactions, and the master node 1 reads or writes the pre-execution read and write set of the transaction Tx2 in a centralized manner.
  • the values of the variables are updated to the pre-execution status set, so that the pre-execution status set records the latest status of each variable during the pre-execution process.
  • the master node 1 records the transaction sequence into the pre-execution transaction set, for example, records the transaction at the end position (ie, the last position) of the pre-execution transaction set.
  • the order of the transactions recorded in the pre-execution transaction set reflects the order of conflict detection of each transaction, and there is no conflict between each recorded transaction and the previously recorded transaction.
  • the pre-execution transaction set is, for example, in the form of a sequence table or a queue.
  • the version number of the variable's value can also be stored.
  • the pre-execution write set of transaction Tx2 includes the key-value pair "a:123" of variable a
  • master node 1 reads the status data of variable a in the pre-execution status set based on the pre-execution write set.
  • master node 1 can pre-execute according to the write set of transaction Tx2.
  • Add the status data of variable a to the status set such as "a:123,1", where "1" is the version number of variable a, which is used to indicate that "123” written by transaction Tx2 is the first version of variable a status.
  • step S307 the master node 1 stores the status information of the variables written during pre-execution of the transaction in association with the transaction identifier in the memory.
  • the master node 1 can record ⁇ Tx2: ⁇ "a:3" ⁇ in the memory for subsequent deletion of transaction Tx2 based on this record and write the state in the pre-execution state set. data.
  • the write set of transaction Tx2 also includes writes to other variables (such as variable b)
  • the status information of variable b can also be recorded in the set of transaction Tx2 , for example, ⁇ Tx2: ⁇ "a:3" ⁇ , ⁇ "b:4" ⁇ .
  • the status information written by the transaction is not limited to including the key and version number of the variable.
  • the master node 1 can be associated with the transaction identification in the memory. Store the keys and status values of variables written to the transaction during pre-execution.
  • step S309 the master node 1 generates a consensus proposal, sends the consensus proposal to at least some of the slave nodes, and reaches consensus on the consensus proposal with at least some of the slave nodes.
  • the consensus proposal may include multiple transactions in a previously recorded order in the pre-execution transaction set, the order in which the multiple transactions are arranged in the pre-execution transaction set, and the pre-execution reading and writing of the multiple transactions.
  • Set that is, the multiple transactions are regarded as multiple transactions in the block to be generated, and the arrangement order of the multiple transactions is the order in which they are arranged in the pre-execution transaction set.
  • Blockchain nodes can reach consensus on consensus proposals through the consensus mechanism.
  • the consensus mechanism is a mechanism for blockchain nodes to reach a network-wide consensus on block information (or block data), which can ensure that the latest blocks are accurately added to the blockchain.
  • the current mainstream consensus mechanisms include: Proof of Work (POW), Proof of Stake (POS), Delegated Proof of Stake (DPOS), Practical Byzantine Fault Tolerance (PBFT) ) algorithm, etc.
  • POW Proof of Work
  • POS Proof of Stake
  • DPOS Delegated Proof of Stake
  • PBFT Practical Byzantine Fault Tolerance
  • the consensus success of the consensus proposal is usually determined after a preset number of nodes reach an agreement on the consensus data (ie, consensus proposal).
  • consensus proposal Specifically, in the PBFT algorithm, for N ⁇ 3f + 1 consensus nodes, f malicious nodes can be tolerated. That is to say, when 2f + 1 nodes among the N consensus nodes reach an agreement, the consensus can be determined to be successful.
  • the master node 1 eliminates conflicts between transactions when performing pre-execution, and each node executes each transaction in the order in the pre-execution transaction set when executing the transaction, so that the transaction can be executed without the master node doing evil.
  • the resulting read-write set is consistent with the transaction's pre-execution read-write set.
  • step S311 master node 1 generates a block after consensus is reached.
  • the master node 1 After the master node 1 completes the pre-execution of multiple transactions, as mentioned above, the above-mentioned pre-execution process makes the pre-execution read-write set of the transaction consistent with the execution read-write set. Therefore, the master node 1 can directly transfer the pre-execution read-write set of the transaction.
  • the execution result is used as the execution result for the transaction.
  • the state database is updated according to the pre-execution read and write sets of the multiple transactions, and block B1 is generated.
  • the block B1 includes a block header and a block body.
  • the block body includes, for example, transaction bodies, receipts and other data of each of the multiple transactions.
  • the block header can include data such as status root, receipt root, and transaction root.
  • step S313 the master node 1 stores the transaction identifier included in the block in the memory.
  • master node 1 After generating block B1, master node 1 stores the identifiers of multiple transactions included in block B1 in the memory, such as the hash value of each transaction, for subsequent cleaning of the state data in the memory.
  • step S315 slave node 2 groups multiple transactions based on the pre-execution read and write set.
  • Slave node 2 may group multiple transactions based on the read variable key and the written variable key included in the pre-execution read and write set of each transaction. As mentioned above, this grouping can prevent transactions in different transaction groups from accessing the same variables. This access includes read operations and write operations. When the grouping conditions are met, there will be no conflicting transactions between various transaction groups. Therefore, individual trading groups can be executed in parallel.
  • step S317 slave node 2 executes multiple transactions in parallel according to the grouping results and arrangement order of the multiple transactions.
  • the slave node 2 can execute transactions in multiple transaction groups in parallel through multiple execution sub-modules.
  • the grouping sub-module 231 divides multiple transactions into six groups g1 to g6.
  • the grouping sub-module 231 can send group g1 and group g2 to the execution sub-module 232, and send group g3 and group g4 to the execution sub-module 233.
  • Group g5 and group g6 are sent to the execution sub-module 234, so that each execution sub-module can execute the transactions in the groups to which it is assigned in parallel.
  • the execution sub-module 232 can process the group g1 and group g2 to which it is assigned in series or in parallel. Since there may be conflicts between transactions in a group, the execution sub-module 232 executes transactions in a single group serially. After executing a certain transaction of group g1 (for example, transaction Tx1), the execution sub-module 232 obtains the execution read-write set of the transaction Tx1. The execution sub-module 232 may compare whether the execution read-write set of the transaction Tx1 is consistent with the pre-execution read-write set.
  • group g1 for example, transaction Tx1
  • the execution sub-module 232 may compare whether the execution read-write set of the transaction Tx1 is consistent with the pre-execution read-write set.
  • the execution sub-module 232 can update the state of each variable in the cache (i.e., world state) according to the execution write set of transaction Tx1.
  • master node 1 If they are inconsistent, it means that master node 1 provided the wrong pre-execution read and write set to slave node 2. That is, master node 1 does evil. In this case, the slave node can initiate the operation of replacing the master node.
  • step S319 blocks are generated from node 2.
  • Slave node 2 can update the state database based on the execution read and write sets of multiple transactions and generate blocks.
  • the block includes a block header and a block body.
  • Figure 4 is a flow chart of the pre-execution data cleaning method in the embodiment of this specification. It can be executed by the master node 1 in Figure 1. It can be understood that in the blockchain under the masterless architecture, it can also be executed by the blockchain. Each node in the execution.
  • step S401 the master node 1 obtains the identifiers of multiple transactions of the generated block.
  • the master node 1 after generating, for example, block B1, the master node 1 will store multiple transaction identifiers included in block B1 in the memory. Before master node 1 stores multiple transaction identifiers included in block B1 in the memory, it first determines whether the amount of data stored in the memory reaches the preset threshold. When it is determined that the threshold is reached, master node 1 begins to execute the steps in Figure 4 S401, to perform data cleaning on the memory, and then store multiple transaction identifiers included in block B1 after cleaning. In the event that it is determined that the threshold has not been reached, the master node 1 may directly store multiple transaction identifiers included in the block B1.
  • master node 1 After master node 1 generates block B1, it has updated the world state in the state database according to the pre-execution read and write set of the transaction in block B1, that is, it has permanently stored the variable state in the pre-execution write set. In this case, even if the variable state written by the transaction in block B1 is deleted from the pre-execution state set, masternode 1 can read the variable state from the state database when it needs to read the variable state when pre-executing subsequent transactions. , therefore, it will not affect the correctness of the transaction pre-execution results.
  • the identifier of the transaction may be a transaction hash value. It can be understood that the identifier of the transaction is not limited to a transaction hash value, for example, it may also be a unique identifier of the transaction such as a transaction number.
  • step S403 the master node 1 reads the first status information of the variables written during pre-execution of the transaction in the memory.
  • master node 1 After master node 1 obtains the identifiers of multiple transactions in block No. 901, for example, it can execute steps S403 to S409 in Figure 4 for each transaction based on the identifiers of each transaction, so as to compare with the identifiers in block No. 901. Pre-execution data is cleaned for each transaction.
  • the master node 1 reads the status data of the transaction Tx2 in the memory according to the identifier of the transaction Tx2.
  • the status data includes, for example, ⁇ Tx2: ⁇ "a:3" ⁇ , ⁇ "b:4" ⁇ , this status data indicates that transaction Tx2 writes the status of the third version of variable a and the status of the fourth version of variable b during pre-execution. Therefore, the master node 1 can read the first status information of variable a as "3" and the first status information of variable b as 4 from the status data of transaction Tx2.
  • the key-value pairs of each written variable can also be stored in the transaction Tx2.
  • the master node 1 can read the value of the variable a from the status data of the transaction Tx2 stored in the memory. as the first status information of variable a, and read the value of variable b as the first status information of variable b.
  • step S405 the master node 1 reads the second state information of the variable from the pre-execution state set stored in the memory.
  • master node 1 first reads the version number of variable a (assumed to be "3”) from the pre-execution status set as the second status information of variable a. Afterwards, master node 1 can read the version number of variable b (for example, “5”) from the pre-execution status set as the second status information of variable b.
  • the master node 1 when the pre-execution state set only stores key-value pairs of variables, the master node 1 can read the values of variable a and variable b from the pre-execution state set as respective second state information.
  • step S407 it is determined whether the first status information of the variable is consistent with the second status information.
  • variable a the first state information of variable a is 3, and the second state information is 3. Therefore, it can be determined that the first state information of variable a is consistent with the second state information, that is, stored in the pre-execution state set
  • the state of variable a is the state of variable a written by transaction Tx2.
  • the master node 1 can execute step S409 to delete the status data of variable a in the pre-execution status set.
  • the deleted status data is, for example, "a:123,3".
  • the first status information of variable b is 4 and the second status information is 5. Therefore, it can be determined that the first status information of variable b is inconsistent with the second status information, and the pre-execution status is stored centrally.
  • the state of variable b is the updated version of the state, not the state of variable b written by transaction Tx2. Therefore, master node 1 retains the state data of variable b in the pre-execution state set.
  • the master node 1 can execute steps S403 to S407 for each variable in the status data in the transaction Tx2 stored in the memory to determine whether to execute step S409. After traversing all variables in the status data of transaction Tx2, master node 1 can delete the status data of transaction Tx2 stored in the memory.
  • Master node 1 continues to execute steps S403 to S407 on other transactions in block No. 901 to further clean up the data in the pre-execution state set. After traversing all transactions in block No. 901, master node 1 can delete the identifier of the transaction included in block No. 901 stored in the memory.
  • Figure 5 is an architectural diagram of a blockchain node in an embodiment of this specification, including:
  • the acquisition unit 51 is used to acquire the identifiers of multiple transactions included in the generated first block;
  • the reading unit 52 is configured to, for the first transaction among the plurality of transactions, read the first variable of the first variable written during pre-execution of the first transaction in the memory according to the identifier of the first transaction. Status information; read the second status information of the first variable from the pre-execution status set stored in the memory;
  • the deletion unit 53 is configured to delete the status data of the first variable in the pre-execution status set when the first status information is consistent with the second status information.
  • the reading unit 52 is specifically configured to read the first version number of the first variable written in the first transaction during pre-execution in the memory, and the first version number is the same as the first version number.
  • the first state of the first variable corresponds to the second state information, and the second state information is a second version number corresponding to the second state of the first variable.
  • the node further includes: a retaining unit configured to retain the state of the first variable in the pre-execution state set when the first state information is inconsistent with the second state information. data.
  • the deletion unit 53 is also configured to: after deleting the status data of the first variable in the pre-execution status set, delete the identification association with the first transaction in the memory. The stored first status information of the first variable written during pre-execution of the first transaction.
  • the acquisition unit 51 is specifically configured to, after generating the second block, determine whether the amount of data stored in the memory reaches a threshold, and when determining that the threshold is reached, acquire the pre-stored data from the memory.
  • the first block includes the identification of multiple transactions.
  • the node further includes a storage unit configured to store in the memory the identifiers of multiple transactions included in the second block when it is determined that the threshold is not reached.
  • the first block is a block generated before the second block and differs from the second block by a preset number of blocks.
  • the node further includes:
  • a pre-execution unit configured to pre-execute the received first transaction and generate a pre-execution write set of the first transaction, where the pre-execution write set includes the key of the first variable and the first state;
  • the reading unit is further configured to read the third version number of the first variable from the pre-execution state set, and obtain the first version number based on the third version number;
  • An update unit configured to update the pre-execution status set according to the pre-execution write set and the first version number
  • the storage unit is further configured to store the key and the first version number of the first variable in the memory in association with the identification of the first transaction.
  • the pre-execution unit is specifically configured to: pre-execute the first transaction based on the pre-execution status set,
  • the update unit is also configured to: after pre-executing the first transaction, perform the following processing on the first transaction: determine whether the pre-execution read set of the first transaction conflicts with the pre-execution status set, wherein , when it is determined that there is no conflict, update the pre-execution status set based on the pre-execution write set of the first transaction and the first version number, and record the first transaction sequence into the pre-execution transaction set , as the pre-execution sequence of the first transaction.
  • the update unit is specifically configured to determine whether the pre-execution status set includes the second variable in the pre-execution read set of the first transaction, and when determining that the pre-execution status set includes the In the case of a second variable, determine whether the state of the second variable in the pre-execution status set is consistent with the state of the second variable in the pre-execution read set. If they are inconsistent, determine whether the first transaction The pre-execution read set conflicts with the pre-execution status set.
  • PLD Programmable Logic Device
  • FPGA Field Programmable Gate Array
  • HDL Hardware Description Language
  • HDL High-Speed Integrated Circuit Hardware Description Language
  • ABEL Advanced Boolean Expression Language
  • AHDL Altera Hardware Description Language
  • HDCal Joint CHDL
  • JHDL Java Hardware Description Language
  • Lava Lava
  • Lola MyHDL
  • PALASM RHDL
  • Verilog Verilog
  • the controller may be implemented in any suitable manner, for example, the controller may take the form of, for example, a microprocessor or processor and a computer readable medium storing computer readable program code (eg, software or firmware) executable by the (micro)processor. , logic gates, switches, Application Specific Integrated Circuit (ASIC), programmable logic controllers and embedded microcontrollers.
  • controllers include but are not limited to the following microcontrollers: ARC 625D, Atmel AT91SAM, For Microchip PIC18F26K20 and Silicone Labs C8051F320, the memory controller can also be implemented as part of the memory's control logic.
  • the controller in addition to implementing the controller in the form of pure computer-readable program code, the controller can be completely programmed with logic gates, switches, application-specific integrated circuits, programmable logic controllers and embedded logic by logically programming the method steps. Microcontroller, etc. to achieve the same function. Therefore, this controller can be considered as a hardware component, and the devices included therein for implementing various functions can also be considered as structures within the hardware component. Or even, the means for implementing various functions can be considered as structures within hardware components as well as software modules implementing the methods.
  • 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 server system.
  • the computer that implements the functions of the above embodiments may be, for example, a personal computer, a laptop computer, a vehicle-mounted human-computer interaction device, a cellular phone, a camera phone, a smart phone, or a personal digital assistant. , media player, navigation device, email device, game console, tablet, wearable device, or a combination of any of these devices.
  • the functions are divided into various modules and described separately.
  • the functions of each module can be implemented in the same or multiple software and/or hardware, or the modules that implement the same function can be implemented by a combination of multiple sub-modules or sub-units, etc. .
  • the device embodiments described above are only illustrative.
  • the division of the units is only a logical function division. In actual implementation, there may be other division methods.
  • multiple units or components may be combined or integrated. to another system, or some features can be ignored, or not implemented.
  • the coupling or direct coupling or communication connection between each other shown or discussed may be through some interfaces, and the indirect coupling or communication connection of the devices or units may be in electrical, mechanical or other forms.
  • These computer program instructions may also be stored in a computer-readable memory that causes a computer or other programmable data processing apparatus to operate in a particular manner, such that the instructions stored in the computer-readable memory produce an article of manufacture including the instruction means, the instructions
  • the device implements the functions specified in a process or processes of the flowchart and/or a block or blocks of the block diagram.
  • These computer program instructions may also be loaded onto a computer or other programmable data processing device, causing a series of operating steps to be performed on the computer or other programmable device to produce computer-implemented processing, thereby executing on the computer or other programmable device.
  • Instructions provide steps for implementing the functions specified in a process or processes of a flowchart diagram and/or a block or blocks of a block diagram.
  • a computing device includes one or more processors (CPUs), input/output interfaces, network interfaces, and memory.
  • processors CPUs
  • input/output interfaces network interfaces
  • memory volatile and non-volatile memory
  • Memory may include non-permanent storage in computer-readable media, random access memory (RAM) and/or non-volatile memory in the form of read-only memory (ROM) or flash memory (flash RAM). Memory is an example of computer-readable media.
  • RAM random access memory
  • ROM read-only memory
  • flash RAM flash random access memory
  • Computer-readable media includes both persistent and non-volatile, removable and non-removable media that can be implemented by any method or technology for storage of information.
  • Information may be computer-readable instructions, data structures, modules of programs, 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), and read-only memory.
  • PRAM phase change memory
  • SRAM static random access memory
  • DRAM dynamic random access memory
  • RAM random access memory
  • read-only memory read-only memory
  • ROM read-only memory
  • EEPROM electrically erasable programmable read-only memory
  • flash memory or other memory technology
  • compact disc read-only memory CD-ROM
  • DVD digital versatile disc
  • Magnetic tape magnetic tape storage, graphene storage or other magnetic storage devices or any other non-transmission medium can be used to store information that can be accessed by a computing device.
  • computer-readable media does not include transitory media, such as modulated data signals and carrier waves.
  • one or more embodiments of the present description may be provided as a method, system, or computer program product. Accordingly, one or more embodiments of the present description may take the form of an entirely hardware embodiment, an entirely software embodiment, or an embodiment that combines software and hardware aspects. Furthermore, one or more embodiments of the present description may employ a computer program implemented on one or more computer-usable storage media (including, but not limited to, disk storage, CD-ROM, optical storage, etc.) having computer-usable program code embodied therein. Product form.
  • computer-usable storage media including, but not limited to, disk storage, CD-ROM, optical storage, etc.
  • program modules include routines, programs, objects, components, data structures, etc. that perform specific tasks or implement specific abstract data types.
  • program modules may also be practiced in distributed computing environments where tasks are performed by remote processing devices connected through a communications network.
  • program modules may be located in both local and remote computer storage media including storage devices.

Landscapes

  • Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Databases & Information Systems (AREA)
  • Business, Economics & Management (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • Finance (AREA)
  • Data Mining & Analysis (AREA)
  • General Engineering & Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • Accounting & Taxation (AREA)
  • Signal Processing (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Computing Systems (AREA)
  • Development Economics (AREA)
  • Economics (AREA)
  • Marketing (AREA)
  • Strategic Management (AREA)
  • Technology Law (AREA)
  • General Business, Economics & Management (AREA)
  • Quality & Reliability (AREA)
  • Information Retrieval, Db Structures And Fs Structures Therefor (AREA)
  • Memory System Of A Hierarchy Structure (AREA)

Abstract

一种预执行数据清理方法和区块链节点，所述方法包括：获取已生成的第一区块包括的多个交易的标识；对于所述多个交易中的第一交易，根据所述第一交易的标识在内存中读取所述第一交易在预执行时写入的第一变量的第一状态信息；从内存中存储的预执行状态集中读取所述第一变量的第二状态信息；在所述第一状态信息与所述第二状态信息一致时，在所述预执行状态集中删除所述第一变量的状态数据。

Description

一种预执行缓存数据清理方法和区块链节点
本申请要求于2022年6月29日提交中国国家知识产权局、申请号为202210750986.9、申请名称为“一种预执行缓存数据清理方法和区块链节点”的中国专利申请的优先权，其全部内容通过引用结合在本申请中。
技术领域
本说明书实施例属于区块链技术领域，尤其涉及一种预执行缓存数据清理方法和区块链节点。
背景技术
区块链(Blockchain)是分布式数据存储、点对点传输、共识机制、加密算法等计算机技术的新型应用模式。区块链系统中按照时间顺序将数据区块以顺序相连的方式组合成链式数据结构，并以密码学方式保证的不可篡改和不可伪造的分布式账本。由于区块链具有去中心化、信息不可篡改、自治性等特性，区块链也受到人们越来越多的重视和应用。
发明内容
本发明的目的在于提供一种预执行数据清理方案，可以有效进行对缓存的预执行数据的清理。
本说明书第一方面提供一种在区块链中执行交易的方法，所述区块链包括主节点和多个从节点，所述方法由所述主节点执行，包括：
在开始预执行第一交易之后，在确定所述第一交易包括对预设类型的第一合约的调用时，终止对所述第一交易的预执行，记录第一信息，所述第一信息用于指示所述第一交易中包括对预设类型的合约的调用，其中，所述预设类型的合约的执行依赖于共识生成的数据；
生成第一区块的共识提议，所述共识提议中包括所述第一信息；
将所述共识提议发送给至少部分从节点，与所述至少部分从节点进行对所述共识提议的共识。
本说明书第二方面提供一种区块链节点，包括：
获取单元，用于获取已生成的第一区块包括的多个交易的标识；
读取单元，用于对于所述多个交易中的第一交易，根据所述第一交易的标识在内存中读取所述第一交易在预执行时写入的第一变量的第一状态信息；从内存中存储的预执行状态集中读取所述第一变量的第二状态信息；
删除单元，用于在所述第一状态信息与所述第二状态信息一致时，在所述预执行状态集中删除所述第一变量的状态数据。
本说明书第三方面提供一种计算机可读存储介质，其上存储有计算机程序，当所述计算机程序在计算机中执行时，令计算机执行第一方面所述的方法。
本说明书第四方面提供一种计算设备，包括存储器和处理器，所述存储器中存储有可执行代码，所述处理器执行所述可执行代码时，实现第一方面所述的方法。
通过本说明书实施例提供的方案，通过在内存记录交易的预执行的写入状态数据，并在生成区块之后在内存中存储区块包括的交易标识，从而可在预执行状态集中删除已持久存储的变量状态，保证了状态清理的正确性。
附图说明
为了更清楚地说明本说明书实施例的技术方案，下面将对实施例描述中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本说明书中记载的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动性的前提下，还可以根据这些附图获得其他的附图。
图1是本说明书实施例中的区块链架构图；
图2示出了本说明书实施例中的区块链结构图；
图3为本说明书实施例中的执行交易的方法流程图；
图4为本说明书实施例中的预执行数据清理方法的流程图；
图5为本说明书实施例中的一种区块链节点的架构图。
具体实施方式
为了使本技术领域的人员更好地理解本说明书中的技术方案，下面将结合本说明书实施例中的附图，对本说明书实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例仅仅是本说明书一部分实施例，而不是全部的实施例。基于本说明书中的实施例，本领域普通技术人员在没有作出创造性劳动前提下所获得的所有其他实 施例，都应当属于本说明书保护的范围。
图1示出本说明书实施例中的区块链架构图。如图1中，区块链中例如包含主节点1、从节点2～从节点5共6个节点。节点之间的连线示意性的表示P2P(Peer to Peer，点对点)连接。这些节点上都存储全量的账本，即存储全部区块和全部账户的状态。其中，区块链中的每个节点通过执行相同的交易而产生区块链中的相同的状态，区块链中的每个节点存储相同的状态数据库。所不同的是，主节点1可负责从客户端接收交易，并向各个从节点发起共识提议，该共识提议中例如包括将要成块的区块(例如区块B1)中的多个交易及各个交易的提交顺序等信息。在区块链中的节点对共识提议共识成功之后，各个节点可根据共识提议中的提交顺序执行该多个交易，从而生成区块B1。
可以理解，图1所示的区块链仅仅是示例性的，本说明书实施例不限于应用于图1所示的区块链，例如还可以应用于包括分片的区块链系统中。
另外，图1中虽然示出了区块链中包括6个节点，本说明书实施例不限于此，而是可以包括其他数目的节点。具体是，区块链中包含的节点可以满足拜占庭容错(Byzantine Fault Tolerance，BFT)要求。所述的拜占庭容错要求可以理解为在区块链内部可以存在拜占庭节点，而区块链对外不体现拜占庭行为。一般的，一些拜占庭容错算法中要求节点个数大于3f+1，f为拜占庭节点个数，例如实用拜占庭容错算法PBFT(Practical Byzantine Fault Tolerance)。
区块链领域中的交易可以指在区块链中执行并记录在区块链中的任务单元。交易中通常包括发送字段(From)、接收字段(To)和数据字段(Data)。其中，在交易为转账交易的情况中，From字段表示发起该交易(即发起对另一个账户的转账任务)的账户地址，To字段表示接收该交易(即接收转账)的账户地址，Data字段中包括转账金额。在交易调用区块链中的智能合约的情况中，From字段表示发起该交易的账户地址，To字段表示交易所调用的合约的账户地址，Data字段中包括调用合约中的函数名、及对该函数的传入参数等数据，以用于在交易执行时从区块链中获取该函数的代码并执行该函数的代码。
区块链中可提供智能合约的功能。区块链上的智能合约是在区块链系统上可以被交易触发执行的合约。智能合约可以通过代码的形式定义。在区块链中调用智能合约，是发起一笔指向智能合约地址的交易，使得区块链中每个节点分布式地运行智能合约代码。需要说明的是，除了可以由用户创建智能合约，也可以在创世块中由系统设置 智能合约。这类合约一般称为创世合约。一般的，创世合约中可以设置一些区块链的数据结构、参数、属性和方法。此外，具有系统管理员权限的账户可以创建系统级的合约，或者修改系统级的合约(简称为系统合约)。其中，所述系统合约可用于在区块链中增加不同业务的数据的数据结构。
在部署合约的场景中，例如，Bob将一个包含创建智能合约信息(即部署合约)的交易发送到如图1所示的区块链中，该交易的data字段包括待创建的合约的代码(如字节码或者机器码)，交易的to字段为空，以表示该交易用于部署合约。节点间通过共识机制达成一致后，确定合约的合约地址“0x6f8ae93…”，各个节点在状态数据库中添加与该智能合约的合约地址对应的合约账户，分配与该合约账户对应的状态存储，并将合约代码保存在该合约的状态存储中，从而合约创建成功。
在调用合约的场景中，例如，Bob将一个用于调用智能合约的交易发送到如图1所示的区块链中，该交易的from字段是交易发起方(即Bob)的账户的地址，to字段中的“0x6f8ae93…”代表了被调用的智能合约的地址，交易的data字段包括调用智能合约的方法和参数。在区块链中对该交易进行共识之后，区块链中的各个节点可分别执行该交易，从而分别执行该合约，基于该合约的执行更新状态数据库。
在相关技术中，为了提高区块链中的每秒执行交易(TPS)指标，需要加快交易的执行速度。为此，区块链节点中可通过并行执行交易来加快交易的执行速度。在一种实施方式中，区块链节点可通过单机中的多个进程并行执行交易，在另一种实施方式中，区块链节点可部署在服务器集群中，通过多台服务器并行执行交易。通常，对于转账交易，区块链节点首先根据交易访问的账户将多个交易划分为多个交易组，各个交易组之间不访问相同的账户，从而可并行执行各个交易组。然而，当交易中调用智能合约时，在执行该交易之前不能预知该交易中访问的变量，从而无法对多个交易进行有效的分组，也就无法对并行执行交易。
在一种相关技术中，在包括主节点和多个从节点的区块链中，可以由主节点预执行多个交易，得到多个交易各自的预执行读写集，并根据该预执行读写集将多个交易分为多个组，从而各个从节点可按照多个组并行执行多个交易。
可以理解，本文中主要以包括主节点和从节点的区块链为例描述本说明书实施例的方案，但是本说明书实施例不限于包括主从结构的区块链，而是也可以应用于无主结构的区块链。其中，在无主结构的区块链中，各个区块链节点都可以执行与主节点相同的步骤。
图2示出了本说明书实施例提供的区块链的主节点1和从节点(例如从节点2)的结构图。如图2所示，主节点1中包括预执行模块11、冲突检测模块12和共识模块13，从节点2中包括共识模块22和计算模块23。主节点1例如可以与客户端连接，从而可以从客户端接收到多个交易。主节点1在接收到每个交易之后，预执行模块11预执行该交易，得到该交易的预执行读写集。其中，预执行读写集包括预执行读集和预执行写集，预执行读集具体可以为在预执行交易的过程中生成的读取的变量的键值对，预执行写集具体可以为在预执行交易的过程中生成的写入的变量的键值对，其中，该变量可以是区块链中的外部账户，或者可以是合约中定义的合约变量。主节点1中可维护预执行状态集，预执行模块11在预执行交易时，可从预执行状态集或者状态数据库中读取变量的状态值。预执行模块11在预执行交易之后，可根据交易的预执行读写集更新预执行状态集。
如图2中所示，预执行模块11中可包括多个预执行子模块，例如预执行子模块111和预执行子模块112，这两个预执行子模块可并行预执行交易。冲突检测模块12中包括预执行状态集和预执行交易集合，其中，主节点1例如在内存中存储所述预执行状态集和预执行交易集合，以供冲突检测模块12使用。冲突检测模块12串行地对各个交易进行预执行冲突检测。具体是，冲突检测模块12检测该交易的预执行读集与已经预执行的交易的写集是否存在冲突，如果该交易的预执行读集中的某个变量的值与预执行状态集中的该变量的值不同，则可确定存在冲突。如果确定不存在冲突，冲突检测模块12将该交易的预执行写集中的状态更新到预执行状态集中，并将该交易顺序排列到预执行交易集合中。
之后，主节点1向各个从节点的共识模块(例如共识模块22)发起共识提议，其中，该共识提议中可包括共识模块13从预执行交易集合中获取在先记录的顺序排列的多个交易、所述多个交易在所述预执行交易集合中的排列顺序、所述多个交易的预执行读写集。可以理解，主节点也可以向从节点广播所述多个交易，从而在共识提议中可以不包括所述多个交易。
在区块链中各个节点对共识提议达成共识之后，从节点2可根据该多个交易各自的预执行读写集对该多个交易进行分组，得到多个交易组，各个交易组之间不存在冲突交易。其中，两个交易组之间存在冲突交易的情况通常包括如下种情况：第一交易组中的交易读取第一变量(即第一交易组读取第一变量)，第二交易组写入第一变量；第一交易组写入第一变量，第二交易组写入第一变量；第一交易组读取第一变量且写 入第一变量，第二交易组写入第一变量；第一交易组读取第一变量且写入第一变量，第二交易组读取第一变量且写入第一变量。其中，如果两个交易组读取相同的变量也可以认为是不存在冲突交易。通常，为了简化方案，从节点2可按照各个交易组之间不访问相同的变量的要求来对多个交易进行分组。
从节点2中的计算模块23可以按照分组并行执行所述多个交易。其中，从节点2的计算模块23中包括多个执行子模块(图中示意示出执行子模块232、执行子模块233和执行子模块234)。每个执行子模块在执行交易的过程中可以根据得到的交易的执行读写集和各个交易的预执行读写集来验证分组的正确性，从而验证主节点是否作恶。
通过上述过程可见，主节点可以通过基于在内存中缓存的预执行状态集中的状态预执行交易、并根据交易的预执行写集更新预执行状态集，使得交易在预执行时基于的状态与该交易在执行时基于的状态一致，从而使得在主节点不作恶的情况下交易的预执行结果与执行结果一致。但是预执行过程中产生的读写集、状态数据等数据并不能作为真实结果直接保存到区块链的数据存储中，同时，为了提高数据读取的效率，该读写集、状态数据通常是存储在内存中，或者缓存服务(提供缓存服务的进程)的内存中。但是内存的容量是有限的。因此，需要一种缓存数据清理方案，使得既能够减少缓存数据量，又可以保证交易在预执行时基于的状态与该交易在执行时基于的状态一致的状态一致性问题。
本说明书实施例提供一种预执行缓存数据清理方案，通过在内存记录交易的预执行的写入状态数据，并在生成区块之后在内存中存储区块包括的交易标识，从而可在预执行状态集中删除已持久存储的变量状态，保证了状态清理的正确性。
下文将参考图3所示的执行交易的方法流程图详细描述本说明书实施例中的交易执行过程。在图3中仅示出了主节点1和从节点2执行的流程，可以理解，区块链中的其他从节点与从节点2执行相同的流程。
如图3所示，首先，在步骤S301，主节点1预执行交易，得到各个交易的预执行读写集。
主节点1可以在每接收到一个交易之后，就立即对该交易进行预执行。主节点1可对同时接收的多个交易并行进行预执行。具体是，主节点1在预执行交易时，当从图2中的预执行状态集或者状态数据库中读取任意变量的值时，在内存中设置的该交易的读缓存中记录该读取的变量的键值对，在写入任意变量的值时，在该交易的写缓存中记录该写入的变量的键值对，并在预执行结束之后，可基于该交易的读缓存和写 缓存获取该交易的预执行读写集。其中，主节点1中可包括用于存储状态数据库的存储设备(图2中未示出)，状态数据库中存储了区块链中的账户和合约定义的变量的世界状态，主节点1中在生成区块之后，根据区块中的各个交易的执行结果更新状态数据库。
其中，主节点1在预执行该交易的过程中读取变量(例如变量A)时，主节点1首先确定该交易的写缓存中是否存储有变量A的值，如果存储了变量A的值，可直接从写缓存中读取变量A的值。在确定所述写缓存中未存储变量A的值情况中，确定该交易的读缓存中是否存储有变量A的值，如果存储了变量A的值，可从读缓存中读取变量A的值。在确定所述读缓存中未存储变量A的值情况中，确定所述预执行状态集中是否存储变量A的值，如果存储了变量A的值，可从预执行状态集中读取变量A的值。在确定预执行状态集中未存储变量A的值的情况中，可从状态数据库读取变量A的值。也就是说，主节点1在预执行交易的过程中，读取变量的优先度为：交易的写缓存＞交易的读缓存＞预执行状态集＞状态数据库，通过如此可保证预执行过程中读取的变量的值为该变量最新的值。
主节点1在如上所述预执行每个交易之后，得到各个交易的预执行读写集。在一种实施方式中，该预执行读写集中包括读集和写集，其中，读集包括预执行该交易时读取的变量的键值对(key-value)，写集包括预执行该交易时写入的变量的键值对。
在交易中调用合约的情况中，区块链节点在执行该交易调用的合约的过程中，有可能根据读取的变量的值来对不同的变量进行写入。例如，当读取的变量的值为1时，对变量a写入10，当读取的变量的值为2时，对变量b写入20等等。因此，对于调用合约的交易，区块链节点必须通过执行该交易，才能确定该交易读取的变量和写入的变量，从而得到该交易的读写集。为此，主节点1通过预执行多个交易中的每个交易，得到每个交易的预执行读写集，该预执行的过程与执行交易的过程基本相同，不同在于，该对交易的预执行是在共识之前进行的执行过程，而对交易的执行是在共识之后进行的执行过程。并且预执行交易的预执行结果仅用于更新预执行状态集，而不用于更新世界状态，而执行交易的执行结果用于更新世界状态。
在步骤S303，主节点1确定交易的预执行读集与预执行状态集是否冲突。
预执行状态集是主节点1在预执行各个交易的过程中缓存的各个变量的最新状态值。主节点1在预执行各个交易之后，串行地对各个交易进行预执行冲突检测。
具体是，主节点1在对所述多个交易中的交易Tx1预执行冲突检测时，首先确定 预执行状态集中是否包括交易Tx1的预执行读集中的变量(例如变量A)。如果没有，再类似地确定预执行状态集中是否包括交易Tx1的预执行读集中的其他变量。如果预执行状态集中不包括交易Tx1的预执行读集中的全部变量，也就是说，之前经过预执行冲突检测的交易还未对该交易访问的变量进行读写，则可确定交易Tx1的预执行读集与预执行状态集没有冲突，也即确定该交易Tx1的预执行与之前经过预执行冲突检测的交易不存在冲突。
如果主节点1确定预执行状态集中包括变量A的值，则确定预执行读集中的变量A的值与预执行状态集中的变量A的值是否一致，如果一致，说明该交易读取的变量A的值为预执行过程中变量A的最新状态。当主节点1对于交易Tx1预执行读集中的每个变量都确定所读取的值为预执行过程中的最新状态之后，可确定该交易Tx1的预执行读集与预执行状态集不存在冲突。
如果主节点1确定交易Tx1的预执行读集中的变量A的值与预执行状态集中的变量A的值不一致，说明该交易Tx1读取的变量A的值不是预执行过程中的最新状态，因此，可确定交易Tx1的预执行读集与预执行状态集存在冲突。在确定存在冲突的情况中，主节点1可通过执行步骤S301对该交易Tx1重新进行预执行。
在步骤S305，主节点1在确定交易的预执行读集与预执行状态集不存在冲突的情况中，基于该交易的预执行读写集更新内存中的预执行状态集和预执行交易集合。
具体是，例如，主节点1确定所述多个交易中的交易Tx2的预执行读集与预执行状态集不存在冲突，主节点1将交易Tx2的预执行读写集中读取或者写入的变量的值更新到预执行状态集中，从而使得该预执行状态集中记录各个变量在预执行过程中的最新状态。同时，主节点1将该交易顺序记录到预执行交易集合中，例如将该交易记录到预执行交易集合的末尾位置(即最后一个位置)。也就是说，预执行交易集合中记录的交易的顺序体现了各个交易的冲突检测的顺序，并且所记录的各个交易与之前记录的交易不存在冲突。其中，所述预执行交易集合例如为顺序表的形式，或者为队列的形式。
其中，在预执行状态集中除了存储各个变量的键值对之外，还可以存储变量的值的版本号。具体是，假设交易Tx2的预执行写集中包括变量a的键值对“a：123”，主节点1根据该预执行写集在预执行状态集中读取变量a的状态数据。在一种情况中，预执行状态集中没有变量a的状态数据，也就是说，在交易Tx2之前预执行的交易没有写入变量a，从而，主节点1根据交易Tx2的写集可在预执行状态集中增加变量a 的状态数据，例如“a：123，1”，其中，“1”为变量a的版本号，其用于指示交易Tx2写入的“123”为变量a的第1个版本的状态。
在另一种情况中，假设预执行状态集中已经存储了变量a的状态数据，例如“a：120，2”，这表示在交易Tx2之前预执行的交易已经对变量a进行了写入，其中“120”为变量a的值，“2”为变量a的状态版本号。主节点1可将从预执行状态集中的读取的变量a的版本号加1得到此次对变量a写入的状态的版本号“3”，从而可将变量a的状态数据更新为“a：123，3”。
在步骤S307，主节点1在内存中与交易标识关联地存储交易在预执行时写入的变量的状态信息。
具体是，以上述第二种情况为例，主节点1可在内存中记录{Tx2：{“a：3”}}，以用于后续基于该记录删除交易Tx2写入预执行状态集中的状态数据。在交易Tx2的写集中还包括对其他变量(例如变量b)的写入时，在根据变量b的写集更新预执行状态集之后，可以在该交易Tx2的集合中还记录变量b的状态信息，例如，{Tx2：{“a：3”}，{“b：4”}}。
可以理解，在本说明书实施例中，交易写入的状态信息不限于包括变量的键和版本号，在预执行状态集中不包括版本号的情况中，主节点1可在内存中与交易标识关联地存储交易在预执行时写入的变量的键和状态值。
在步骤S309，主节点1生成共识提议，将共识提议发送给至少部分从节点，与该至少部分从节点进行对共识提议的共识。
该共识提议中可包括预执行交易集合中在先记录的顺序排列的多个交易、所述多个交易在所述预执行交易集合中的排列顺序、及所述多个交易的预执行读写集，即将该多个交易作为即将生成的区块中的多个交易，并且该多个交易的排列顺序为其在预执行交易集合中的排列顺序。
区块链节点之间可以通过共识机制进行对共识提议的共识。所述共识机制是区块链节点就区块信息(或称区块数据)达成全网一致共识的机制，可以保证最新区块被准确添加至区块链。当前主流的共识机制包括：工作量证明(Proof of Work，POW)、股权证明(Proof of Stake，POS)、委任权益证明(Delegated Proof of Stake，DPOS)、实用拜占庭容错(Practical Byzantine Fault Tolerance，PBFT)算法等。其中，在各种共识算法中，通常在预设数目的节点对待共识的数据(即共识提议)达成一致之后，从而确定对该共识提议的共识成功。具体是，在PBFT算法中，对于N≥3f+1个共识节 点，可容忍f个恶意节点，也就是说，当N个共识节点中2f+1个节点达成一致时，可确定共识成功。
通过如此，主节点1在进行预执行时排除了交易之间的冲突，并且各个节点在执行交易时按照预执行交易集合中的排列顺序执行各个交易，使得在主节点不作恶的情况中执行交易得到的读写集与该交易的预执行读写集是一致的。
在步骤S311，主节点1在共识达成之后，生成区块。
主节点1在完成对多个交易的预执行之后，由于如上文所述，上述预执行过程使得交易的预执行读写集与执行读写集一致，因此，主节点1可以直接将交易的预执行结果用作为该交易的执行结果。根据该多个交易的预执行读写集更新状态数据库，并生成区块B1。该区块B1包括区块头和区块体。其中，区块体中例如包括所述多个交易各自的交易体、收据等数据。区块头中可以包括状态根、收据根、交易根等数据。
在步骤S313，主节点1在内存中存储区块包括的交易标识。
主节点1在生成区块B1之后，在内存中存储区块B1包括的多个交易的标识，例如各个交易的哈希值，以用于后续进行对内存中的状态数据的清理。
在步骤S315，从节点2基于预执行读写集对多个交易进行分组。
从节点2可基于各个交易的预执行读写集中包括的读取的变量的键(key)和写入的变量key，对多个交易进行分组。如上文所述，该分组可使得不同交易组中的交易不访问相同的变量，该访问包括读操作和写操作，在达到该分组条件的情况下，各个交易组之间不会存在冲突交易，因此，各个交易组可以并行执行。
在步骤S317，从节点2根据多个交易的分组结果和排列顺序并行执行所述多个交易。
参考图2，从节点2可通过多个执行子模块并行地执行多个交易组中的交易。假设分组子模块231将多个交易分为6个组g1～组g6，分组子模块231可将组g1和组g2发送给执行子模块232，将组g3和组g4发送给执行子模块233，将组g5和组g6发送给执行子模块234，从而各个执行子模块可并行执行其分到的组中的交易。
以执行子模块232为例，执行子模块232可串行或者并行地处理其分到的组g1和组g2。由于一个组中的交易之间可能存在冲突，执行子模块232串行执行单个组中的交易。执行子模块232在执行组g1的某个交易(例如交易Tx1)之后，得到该交易Tx1的执行读写集。执行子模块232可比较该交易Tx1的执行读写集与预执行读写集是否一致。如果交易Tx1的执行读写集与预执行读写集一致，执行子模块232可根据 交易Tx1的执行写集更新缓存中的各个变量的状态(即世界状态)。
如果不一致，则说明主节点1向从节点2提供了错误的预执行读写集。也即主节点1作恶。在该情况下，从节点可以发起更换主节点的操作。
在步骤S319，从节点2生成区块。
从节点2可以根据多个交易的执行读写集更新状态数据库，并生成区块。该区块包括区块头和区块体。
图4为本说明书实施例中的预执行数据清理方法的流程图，其可以由图1中的主节点1执行，可以理解，在无主架构下的区块链中，也可以由区块链中的各个节点执行。
参考图4，首先，在步骤S401，主节点1获取已生成的区块的多个交易的标识。
参考上文对图3的描述，主节点1在生成例如区块B1之后，会在内存中存储区块B1包括的多个交易标识。主节点1在内存中存储区块B1包括的多个交易标识之前，首先确定内存中存储的数据量是否达到预设阈值，在确定达到阈值的情况下，主节点1开始执行图4中的步骤S401，以对内存进行数据清理，并在清理之后再存储区块B1中包括的多个交易标识。在确定未到达阈值的情况下，主节点1可直接存储区块B1中包括的多个交易标识。
主节点1在生成区块B1之后，已经根据区块B1中的交易的预执行读写集更新了状态数据库中的世界状态，即对预执行写集中的变量状态进行了永久存储。在该情况下，即使在预执行状态集中删除区块B1中的交易写入的变量状态，主节点1在预执行后续的交易时需要读取变量状态时，可以从状态数据库中读取变量状态，因此，不会影响交易预执行结果的正确性。
然而，从前文参考图3的描述可以理解，如果在生成区块之后就在预执行状态集中清理该区块写入的变量的状态，可能导致预执行状态集中的状态数据较少，从而使得预执行交易的速度减慢。因此，可以预设一定的保留区块数目，使得在删除预执行状态集中的状态数据时，保留最近的所述保留区块数目的区块对应的状态数据。例如，可将所述保留区块数目设置为100，假设区块B1为1000号区块，当1000号区块成块之后，根据保留区块数目，对第901号区块中交易对应的状态数据进行清理。即在该步骤中，获取第901号区块的多个交易的标识，其中，该第901号区块的多个交易的标识由主节点1在生成第901号区块之后存储到内存中，以用于执行该清理方法。所述交易的标识可以为交易哈希值。可以理解，所述交易的标识不限于为交易哈希值， 例如，还可以为交易编号等交易的唯一标识。
在步骤S403，主节点1在内存中读取交易在预执行时写入的变量的第一状态信息。
主节点1获取例如第901号区块中的多个交易的标识之后，可以根据各个交易的标识，对每个交易执行图4中的步骤S403～S409，以相对于第901号区块中的每个交易进行对预执行数据的清理。
具体是，例如对于上述交易Tx2，主节点1根据交易Tx2的标识在内存中读取交易Tx2的状态数据，该状态数据例如包括{Tx2：{“a：3”}，{“b：4”}}，该状态数据表示，交易Tx2在预执行时写入变量a的第3版本的状态，写入变量b的第4版本的状态。从而，主节点1可从交易Tx2的状态数据中读取变量a的第一状态信息为“3”，变量b的第一状态信息为4。
可以理解，如上文所述，在交易Tx2中也可以存储各个写入变量的键值对，在该情况下，主节点1可从内存中存储的交易Tx2的状态数据中读取变量a的值作为变量a的第一状态信息，以及读取变量b的值作为变量b的第一状态信息。
在步骤S405，主节点1从内存中存储的预执行状态集中读取变量的第二状态信息。
具体是，对于交易Tx2的状态数据，主节点1首先从预执行状态集中读取变量a的版本号(假设为“3”)作为变量a的第二状态信息。之后，主节点1可以从预执行状态集中读取变量b的版本号(例如“5”)作为变量b的第二状态信息。
在另一个实施方式中，在预执行状态集中仅存储变量的键值对的情况下，主节点1可从预执行状态集中读取变量a和变量b的值作为各自的第二状态信息。
在步骤S407，确定变量的第一状态信息与第二状态信息是否一致。
具体是，对于变量a，变量a的第一状态信息为3，第二状态信息为3，因此，可确定变量a的第一状态信息与第二状态信息一致，即，在预执行状态集中存储的变量a的状态即为交易Tx2写入的变量a的状态。
因此，主节点1可执行步骤S409，在预执行状态集中删除变量a的状态数据。该删除的状态数据例如为“a：123，3”。
再回到步骤S407，对于变量b，变量b的第一状态信息为4，第二状态信息为5，因此，可确定变量b的第一状态信息与第二状态信息不一致，预执行状态集中存储的变量b的状态是更新版本的状态，而不是交易Tx2写入的变量b的状态，因此，主节点1在预执行状态集中保留变量b的状态数据。
主节点1可以针对内存中存储的交易Tx2中的状态数据中的每个变量执行步骤 S403～步骤S407，以确定是否执行步骤S409。在对交易Tx2中的状态数据中的全部变量都遍历了之后，主节点1可以删除内存中存储的交易Tx2的状态数据。
主节点1继续对第901号区块中的其他交易执行步骤S403～步骤S407，以进一步对预执行状态集中的数据进行清理。在对第901号区块中的全部交易都遍历了之后，主节点1可以删除内存中存储的第901号区块包括的交易的标识。
图5为本说明书实施例中的一种区块链节点的架构图，包括：
获取单元51，用于获取已生成的第一区块包括的多个交易的标识；
读取单元52，用于对于所述多个交易中的第一交易，根据所述第一交易的标识在内存中读取所述第一交易在预执行时写入的第一变量的第一状态信息；从内存中存储的预执行状态集中读取所述第一变量的第二状态信息；
删除单元53，用于在所述第一状态信息与所述第二状态信息一致时，在所述预执行状态集中删除所述第一变量的状态数据。
在一种实施方式中，所述读取单元52具体用于，在内存中读取所述第一交易在预执行时写入的第一变量的第一版本号，所述第一版本号与所述第一变量的第一状态对应，所述第二状态信息为与所述第一变量的第二状态对应的第二版本号。
在一种实施方式中，所述节点还包括：保留单元，用于在所述第一状态信息与所述第二状态信息不一致时，保留所述预执行状态集中的所述第一变量的状态数据。
在一种实施方式中，所述删除单元53还用于：当在所述预执行状态集中删除所述第一变量的状态数据之后，在所述内存中删除与所述第一交易的标识关联存储的所述第一交易在预执行时写入的第一变量的第一状态信息。
在一种实施方式中，所述获取单元51具体用于，在生成第二区块之后，确定所述内存中存储的数据量是否达到阈值，在确定达到阈值时，从所述内存获取预先存储的第一区块包括的多个交易的标识。
在一种实施方式中，所述节点还包括，存储单元，用于在确定未达到阈值时，在所述内存存储所述第二区块包括的多个交易的标识。
在一种实施方式中，所述第一区块为在所述第二区块之前生成的、与所述第二区块相差预设区块数的区块。
在一种实施方式中，所述节点还包括：
预执行单元，用于预执行接收的第一交易，生成第一交易的预执行写集，所述预执行写集包括所述第一变量的键和第一状态；
所述读取单元还用于，从所述预执行状态集读取所述第一变量的第三版本号，基于所述第三版本号得到所述第一版本号；
更新单元，用于根据所述预执行写集和所述第一版本号更新所述预执行状态集；
所述存储单元还用于，在所述内存中与所述第一交易的标识关联存储的所述第一变量的键和第一版本号。
在一种实施方式中，所述预执行单元具体用于：基于所述预执行状态集预执行所述第一交易，
所述更新单元还用于：在预执行完第一交易之后，对所述第一交易进行如下处理：确定所述第一交易的预执行读集是否与所述预执行状态集存在冲突，其中，在确定不存在冲突的情况中，基于所述第一交易的预执行写集和所述第一版本号更新所述预执行状态集，将所述第一交易顺序记录到预执行交易集合中，作为所述第一交易的预执行顺序。
在一种实施方式中，所述更新单元具体用于，确定所述预执行状态集中是否包括所述第一交易的预执行读集中的第二变量，在确定所述预执行状态集中包括所述第二变量的情况中，确定所述预执行状态集中的所述第二变量的状态与所述预执行读集中的所述第二变量的状态是否一致，如果不一致，则确定所述第一交易的预执行读集与所述预执行状态集存在冲突。
在20世纪90年代，对于一个技术的改进可以很明显地区分是硬件上的改进(例如，对二极管、晶体管、开关等电路结构的改进)还是软件上的改进(对于方法流程的改进)。然而，随着技术的发展，当今的很多方法流程的改进已经可以视为硬件电路结构的直接改进。设计人员几乎都通过将改进的方法流程编程到硬件电路中来得到相应的硬件电路结构。因此，不能说一个方法流程的改进就不能用硬件实体模块来实现。例如，可编程逻辑器件(Programmable Logic Device，PLD)(例如现场可编程门阵列(Field Programmable Gate Array，FPGA))就是这样一种集成电路，其逻辑功能由用户对器件编程来确定。由设计人员自行编程来把一个数字系统“集成”在一片PLD上，而不需要请芯片制造厂商来设计和制作专用的集成电路芯片。而且，如今，取代手工地制作集成电路芯片，这种编程也多半改用“逻辑编译器(logic compiler)”软件来实现，它与程序开发撰写时所用的软件编译器相类似，而要编译之前的原始代码也得用特定的编程语言来撰写，此称之为硬件描述语言(Hardware Description Language，HDL)，而HDL也并非仅有一种，而是有许多种，如ABEL(Advanced Boolean  Expression Language)、AHDL(Altera Hardware Description Language)、Confluence、CUPL(Cornell University Programming Language)、HDCal、JHDL(Java Hardware Description Language)、Lava、Lola、MyHDL、PALASM、RHDL(Ruby Hardware Description Language)等，目前最普遍使用的是VHDL(Very-High-Speed Integrated Circuit Hardware Description Language)与Verilog。本领域技术人员也应该清楚，只需要将方法流程用上述几种硬件描述语言稍作逻辑编程并编程到集成电路中，就可以很容易得到实现该逻辑方法流程的硬件电路。
控制器可以按任何适当的方式实现，例如，控制器可以采取例如微处理器或处理器以及存储可由该(微)处理器执行的计算机可读程序代码(例如软件或固件)的计算机可读介质、逻辑门、开关、专用集成电路(Application Specific Integrated Circuit，ASIC)、可编程逻辑控制器和嵌入微控制器的形式，控制器的例子包括但不限于以下微控制器：ARC 625D、Atmel AT91SAM、Microchip PIC18F26K20以及Silicone Labs C8051F320，存储器控制器还可以被实现为存储器的控制逻辑的一部分。本领域技术人员也知道，除了以纯计算机可读程序代码方式实现控制器以外，完全可以通过将方法步骤进行逻辑编程来使得控制器以逻辑门、开关、专用集成电路、可编程逻辑控制器和嵌入微控制器等的形式来实现相同功能。因此这种控制器可以被认为是一种硬件部件，而对其内包括的用于实现各种功能的装置也可以视为硬件部件内的结构。或者甚至，可以将用于实现各种功能的装置视为既可以是实现方法的软件模块又可以是硬件部件内的结构。
上述实施例阐明的系统、装置、模块或单元，具体可以由计算机芯片或实体实现，或者由具有某种功能的产品来实现。一种典型的实现设备为服务器系统。当然，本申请不排除随着未来计算机技术的发展，实现上述实施例功能的计算机例如可以为个人计算机、膝上型计算机、车载人机交互设备、蜂窝电话、相机电话、智能电话、个人数字助理、媒体播放器、导航设备、电子邮件设备、游戏控制台、平板计算机、可穿戴设备或者这些设备中的任何设备的组合。
虽然本说明书一个或多个实施例提供了如实施例或流程图所述的方法操作步骤，但基于常规或者无创造性的手段可以包括更多或者更少的操作步骤。实施例中列举的步骤顺序仅仅为众多步骤执行顺序中的一种方式，不代表唯一的执行顺序。在实际中的装置或终端产品执行时，可以按照实施例或者附图所示的方法顺序执行或者并行执行(例如并行处理器或者多线程处理的环境，甚至为分布式数据处理环境)。术语“包 括”、“包含”或者其任何其他变体意在涵盖非排他性的包含，从而使得包括一系列要素的过程、方法、产品或者设备不仅包括那些要素，而且还包括没有明确列出的其他要素，或者是还包括为这种过程、方法、产品或者设备所固有的要素。在没有更多限制的情况下，并不排除在包括所述要素的过程、方法、产品或者设备中还存在另外的相同或等同要素。例如若使用到第一，第二等词语用来表示名称，而并不表示任何特定的顺序。
为了描述的方便，描述以上装置时以功能分为各种模块分别描述。当然，在实施本说明书一个或多个时可以把各模块的功能在同一个或多个软件和/或硬件中实现，也可以将实现同一功能的模块由多个子模块或子单元的组合实现等。以上所描述的装置实施例仅仅是示意性的，例如，所述单元的划分，仅仅为一种逻辑功能划分，实际实现时可以有另外的划分方式，例如多个单元或组件可以结合或者可以集成到另一个系统，或一些特征可以忽略，或不执行。另一点，所显示或讨论的相互之间的耦合或直接耦合或通信连接可以是通过一些接口，装置或单元的间接耦合或通信连接，可以是电性，机械或其它的形式。
本发明是参照根据本发明实施例的方法、装置(系统)、和计算机程序产品的流程图和/或方框图来描述的。应理解可由计算机程序指令实现流程图和/或方框图中的每一流程和/或方框、以及流程图和/或方框图中的流程和/或方框的结合。可提供这些计算机程序指令到通用计算机、专用计算机、嵌入式处理机或其他可编程数据处理设备的处理器以产生一个机器，使得通过计算机或其他可编程数据处理设备的处理器执行的指令产生用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的装置。
这些计算机程序指令也可存储在能引导计算机或其他可编程数据处理设备以特定方式工作的计算机可读存储器中，使得存储在该计算机可读存储器中的指令产生包括指令装置的制造品，该指令装置实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能。
这些计算机程序指令也可装载到计算机或其他可编程数据处理设备上，使得在计算机或其他可编程设备上执行一系列操作步骤以产生计算机实现的处理，从而在计算机或其他可编程设备上执行的指令提供用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的步骤。
在一个典型的配置中，计算设备包括一个或多个处理器(CPU)、输入/输出接口、 网络接口和内存。
内存可能包括计算机可读介质中的非永久性存储器，随机存取存储器(RAM)和/或非易失性内存等形式，如只读存储器(ROM)或闪存(flash RAM)。内存是计算机可读介质的示例。
计算机可读介质包括永久性和非永久性、可移动和非可移动媒体可以由任何方法或技术来实现信息存储。信息可以是计算机可读指令、数据结构、程序的模块或其他数据。计算机的存储介质的例子包括，但不限于相变内存(PRAM)、静态随机存取存储器(SRAM)、动态随机存取存储器(DRAM)、其他类型的随机存取存储器(RAM)、只读存储器(ROM)、电可擦除可编程只读存储器(EEPROM)、快闪记忆体或其他内存技术、只读光盘只读存储器(CD-ROM)、数字多功能光盘(DVD)或其他光学存储、磁盒式磁带，磁带磁磁盘存储、石墨烯存储或其他磁性存储设备或任何其他非传输介质，可用于存储可以被计算设备访问的信息。按照本文中的界定，计算机可读介质不包括暂存电脑可读媒体(transitory media)，如调制的数据信号和载波。
本领域技术人员应明白，本说明书一个或多个实施例可提供为方法、系统或计算机程序产品。因此，本说明书一个或多个实施例可采用完全硬件实施例、完全软件实施例或结合软件和硬件方面的实施例的形式。而且，本说明书一个或多个实施例可采用在一个或多个其中包含有计算机可用程序代码的计算机可用存储介质(包括但不限于磁盘存储器、CD-ROM、光学存储器等)上实施的计算机程序产品的形式。
本说明书一个或多个实施例可以在由计算机执行的计算机可执行指令的一般上下文中描述，例如程序模块。一般地，程序模块包括执行特定任务或实现特定抽象数据类型的例程、程序、对象、组件、数据结构等等。也可以在分布式计算环境中实践本本说明书一个或多个实施例，在这些分布式计算环境中，由通过通信网络而被连接的远程处理设备来执行任务。在分布式计算环境中，程序模块可以位于包括存储设备在内的本地和远程计算机存储介质中。
本说明书中的各个实施例均采用递进的方式描述，各个实施例之间相同相似的部分互相参见即可，每个实施例重点说明的都是与其他实施例的不同之处。尤其，对于系统实施例而言，由于其基本相似于方法实施例，所以描述的比较简单，相关之处参见方法实施例的部分说明即可。在本说明书的描述中，参考术语“一个实施例”、“一些实施例”、“示例”、“具体示例”、或“一些示例”等的描述意指结合该实施例或示例描述的具体特征、结构、材料或者特点包含于本说明书的至少一个实施例或示 例中。在本说明书中，对上述术语的示意性表述不必须针对的是相同的实施例或示例。而且，描述的具体特征、结构、材料或者特点可以在任一个或多个实施例或示例中以合适的方式结合。此外，在不相互矛盾的情况下，本领域的技术人员可以将本说明书中描述的不同实施例或示例以及不同实施例或示例的特征进行结合和组合。
以上所述仅为本说明书一个或多个实施例的实施例而已，并不用于限制本本说明书一个或多个实施例。对于本领域技术人员来说，本说明书一个或多个实施例可以有各种更改和变化。凡在本说明书的精神和原理之内所作的任何修改、等同替换、改进等，均应包含在权利要求范围之内。

Claims (15)

  1. 一种预执行数据清理方法，由区块链节点执行，所述方法包括：
    获取已生成的第一区块包括的多个交易的标识；
    对于所述多个交易中的第一交易，根据所述第一交易的标识在内存中读取所述第一交易在预执行时写入的第一变量的第一状态信息；
    从内存中存储的预执行状态集中读取所述第一变量的第二状态信息；
    在所述第一状态信息与所述第二状态信息一致时，在所述预执行状态集中删除所述第一变量的状态数据。
  2. 根据权利要求1所述的方法，在内存中读取所述第一交易在预执行时写入的第一变量的第一状态信息包括，在内存中读取所述第一交易在预执行时写入的第一变量的第一版本号，所述第一版本号与所述第一变量的第一状态对应，所述第二状态信息为与所述第一变量的第二状态对应的第二版本号。
  3. 根据权利要求1或2所述的方法，还包括：在所述第一状态信息与所述第二状态信息不一致时，保留所述预执行状态集中的所述第一变量的状态数据。
  4. 根据权利要求1或2所述的方法，还包括：当在所述预执行状态集中删除所述第一变量的状态数据之后，在所述内存中删除所述第一交易在预执行时写入的第一变量的第一状态信息。
  5. 根据权利要求1或2所述的方法，所述获取已生成的第一区块包括的多个交易的标识包括，在生成第二区块之后，确定所述内存中存储的数据量是否达到阈值，在确定达到阈值时，从所述内存获取预先存储的第一区块包括的多个交易的标识。
  6. 根据权利要求5所述的方法，还包括，在确定未达到阈值时，在所述内存存储所述第二区块包括的多个交易的标识。
  7. 根据权利要求5所述的方法，所述第一区块为在所述第二区块之前生成的、与所述第二区块相差预设区块数的区块。
  8. 根据权利要求1或2所述的方法，还包括：
    预执行接收的第一交易，生成第一交易的预执行写集，所述预执行写集包括所述第一变量的键和第一状态；
    从所述预执行状态集读取所述第一变量的第三版本号，基于所述第三版本号得到所述第一版本号；
    根据所述预执行写集和所述第一版本号更新所述预执行状态集；
    在所述内存中与所述第一交易的标识关联存储的所述第一变量的键和第一版本号。
  9. 根据权利要求8所述的方法，所述预执行接收的第一交易包括：基于所述预执行状态集预执行所述第一交易，
    所述根据所述预执行写集和所述第一版本号更新所述预执行状态集包括：在预执行完第一交易之后，对所述第一交易进行如下处理：确定所述第一交易的预执行读集是否与所述预执行状态集存在冲突，其中，在确定不存在冲突的情况中，基于所述第一交易的预执行写集和所述第一版本号更新所述预执行状态集，将所述第一交易顺序记录到预执行交易集合中，作为所述第一交易的预执行顺序。
  10. 根据权利要求9所述的方法，其中，所述确定所述第一交易的预执行读集是否与所述预执行状态集存在冲突包括，确定所述预执行状态集中是否包括所述第一交易的预执行读集中的第二变量，在确定所述预执行状态集中包括所述第二变量的情况中，确定所述预执行状态集中的所述第二变量的状态与所述预执行读集中的所述第二变量的状态是否一致，如果不一致，则确定所述第一交易的预执行读集与所述预执行状态集存在冲突。
  11. 根据权利要求1所述的方法，其中，所述内存为所述区块链节点中用于提供缓存服务的进程的内存。
  12. 一种区块链节点，包括：
    获取单元，用于获取已生成的第一区块包括的多个交易的标识；
    读取单元，用于对于所述多个交易中的第一交易，根据所述第一交易的标识在内存中读取所述第一交易在预执行时写入的第一变量的第一状态信息；从内存中存储的预执行状态集中读取所述第一变量的第二状态信息；
    删除单元，用于在所述第一状态信息与所述第二状态信息一致时，在所述预执行状态集中删除所述第一变量的状态数据。
  13. 根据权利要求12所述的区块链节点，所述读取单元具体用于，在内存中读取所述第一交易在预执行时写入的第一变量的第一版本号，所述第一版本号与所述第一变量的第一状态对应，所述第二状态信息为与所述第一变量的第二状态对应的第二版本号。
  14. 一种计算机可读存储介质，其上存储有计算机程序，当所述计算机程序在计算机中执行时，令计算机执行权利要求1-11中任一项所述的方法。
  15. 一种区块链节点，包括存储器和处理器，所述存储器中存储有可执行代码， 所述处理器执行所述可执行代码时，实现权利要求1-11中任一项的所述的方法。
PCT/CN2022/135327 2022-06-29 2022-11-30 一种预执行缓存数据清理方法和区块链节点 Ceased WO2024001025A1 (zh)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
CN202210750986.9A CN115098483A (zh) 2022-06-29 2022-06-29 一种预执行缓存数据清理方法和区块链节点
CN202210750986.9 2022-06-29

Publications (1)

Publication Number Publication Date
WO2024001025A1 true WO2024001025A1 (zh) 2024-01-04

Family

ID=83295577

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/CN2022/135327 Ceased WO2024001025A1 (zh) 2022-06-29 2022-11-30 一种预执行缓存数据清理方法和区块链节点

Country Status (2)

Country Link
CN (1) CN115098483A (zh)
WO (1) WO2024001025A1 (zh)

Families Citing this family (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN115098483A (zh) * 2022-06-29 2022-09-23 蚂蚁区块链科技(上海)有限公司 一种预执行缓存数据清理方法和区块链节点
CN116049310B (zh) * 2022-12-30 2026-04-17 蚂蚁区块链科技(上海)有限公司 区块链系统中的交易执行方法、存储服务和区块链节点
CN117076507A (zh) * 2023-08-31 2023-11-17 蚂蚁区块链科技(上海)有限公司 交易的执行方法及装置

Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20180101560A1 (en) * 2016-10-07 2018-04-12 International Business Machines Corporation Establishing overlay trust consensus for blockchain trust validation system
CN113553378A (zh) * 2020-10-20 2021-10-26 支付宝(杭州)信息技术有限公司 一种区块链数据的删除方法和装置
CN113743942A (zh) * 2021-11-04 2021-12-03 支付宝(杭州)信息技术有限公司 交易执行方法、区块链、主节点和主存储设备
CN114529417A (zh) * 2022-02-25 2022-05-24 蚂蚁区块链科技(上海)有限公司 执行交易的方法、区块链、主节点和从节点
CN115098483A (zh) * 2022-06-29 2022-09-23 蚂蚁区块链科技(上海)有限公司 一种预执行缓存数据清理方法和区块链节点

Family Cites Families (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN111312352B (zh) * 2020-02-19 2023-07-21 百度在线网络技术（北京）有限公司 一种基于区块链的数据处理方法、装置、设备和介质
CN113743940B (zh) * 2021-11-04 2022-08-12 支付宝(杭州)信息技术有限公司 在区块链中执行交易的方法、区块链、主节点和从节点
CN114358934A (zh) * 2021-12-29 2022-04-15 中国农业银行股份有限公司 智能合约的校验方法和相关设备

Patent Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20180101560A1 (en) * 2016-10-07 2018-04-12 International Business Machines Corporation Establishing overlay trust consensus for blockchain trust validation system
CN113553378A (zh) * 2020-10-20 2021-10-26 支付宝(杭州)信息技术有限公司 一种区块链数据的删除方法和装置
CN113743942A (zh) * 2021-11-04 2021-12-03 支付宝(杭州)信息技术有限公司 交易执行方法、区块链、主节点和主存储设备
CN114529417A (zh) * 2022-02-25 2022-05-24 蚂蚁区块链科技(上海)有限公司 执行交易的方法、区块链、主节点和从节点
CN115098483A (zh) * 2022-06-29 2022-09-23 蚂蚁区块链科技(上海)有限公司 一种预执行缓存数据清理方法和区块链节点

Also Published As

Publication number Publication date
CN115098483A (zh) 2022-09-23

Similar Documents

Publication Publication Date Title
CN114827165B (zh) 对多个交易进行分组的方法和区块链节点
WO2023231336A1 (zh) 执行交易的方法和区块链节点
CN113743941B (zh) 一种在区块链中执行交易的方法、区块链和主节点
CN114936256B (zh) 在区块链中执行交易的方法和区块链节点
WO2024001024A1 (zh) 在区块链系统中执行交易的方法、区块链系统和节点
CN114547203B (zh) 执行交易的方法、区块链、主节点和从节点
WO2024001032A1 (zh) 在区块链系统中执行交易的方法、区块链系统和节点
CN115098483A (zh) 一种预执行缓存数据清理方法和区块链节点
CN110704438B (zh) 一种区块链中布隆过滤器的生成方法及装置
WO2023160083A1 (zh) 执行交易的方法、区块链、主节点和从节点
TW201918878A (zh) 任務執行的方法及裝置
WO2024092932A1 (zh) 交易执行方法和区块链节点
CN116032756A (zh) 基于区块链更新应用程序的配置信息的方法和区块链节点
WO2025000878A1 (zh) 交易的执行方法、节点和区块链系统
CN116707891A (zh) 重放攻击检查方法和区块链节点
CN116431312A (zh) 区块链系统中的交易执行方法和区块链节点
WO2023231335A1 (zh) 在区块链中执行交易的方法及区块链的主节点
CN115982781A (zh) 一种在区块链中创建账户的方法和区块链节点
CN107102898B (zh) 一种基于numa架构的内存管理、构建数据结构的方法及装置
WO2025043923A1 (zh) 交易的执行方法及装置
CN116668001A (zh) 区块链中的交易处理方法和区块链节点
CN115964442A (zh) 一种区块链中的账户状态访问方法和区块链节点
WO2023231342A1 (zh) 基于变量状态自动执行合约的方法和装置
CN116166342A (zh) 业务处理方法、装置、设备及存储介质
CN108733678B (zh) 一种数据搜索的方法、装置和相关设备

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 22949105

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 22949105

Country of ref document: EP

Kind code of ref document: A1

32PN Ep: public notification in the ep bulletin as address of the adressee cannot be established

Free format text: NOTING OF LOSS OF RIGHTS PURSUANT TO RULE 112(1) EPC (EPO FORM 1205A DATED 24.06.2025)

122 Ep: pct application non-entry in european phase

Ref document number: 22949105

Country of ref document: EP

Kind code of ref document: A1