WO2022237569A1 - 一种交易验重方法、装置、设备以及介质 - Google Patents

一种交易验重方法、装置、设备以及介质 Download PDF

Info

Publication number
WO2022237569A1
WO2022237569A1 PCT/CN2022/090110 CN2022090110W WO2022237569A1 WO 2022237569 A1 WO2022237569 A1 WO 2022237569A1 CN 2022090110 W CN2022090110 W CN 2022090110W WO 2022237569 A1 WO2022237569 A1 WO 2022237569A1
Authority
WO
WIPO (PCT)
Prior art keywords
transaction
weight
processed
node
array
Prior art date
Application number
PCT/CN2022/090110
Other languages
English (en)
French (fr)
Inventor
刘区城
Original Assignee
腾讯科技（深圳）有限公司
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 腾讯科技（深圳）有限公司 filed Critical 腾讯科技（深圳）有限公司
Priority to EP22806537.1A priority Critical patent/EP4216130A4/en
Publication of WO2022237569A1 publication Critical patent/WO2022237569A1/zh
Priority to US18/073,355 priority patent/US20230102617A1/en

Links

Images

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR 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
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/38—Payment protocols; Details thereof
    • G06Q20/382—Payment protocols; Details thereof insuring higher security of transaction
    • G06Q20/3827—Use of message hashing
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR 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
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/02—Payment architectures, schemes or protocols involving a neutral party, e.g. certification authority, notary or trusted third party [TTP]
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR 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
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/04—Payment circuits
    • G06Q20/06—Private payment circuits, e.g. involving electronic currency used among participants of a common payment scheme
    • G06Q20/065—Private payment circuits, e.g. involving electronic currency used among participants of a common payment scheme using e-cash
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR 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
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/22—Payment schemes or models
    • G06Q20/223—Payment schemes or models based on the use of peer-to-peer networks
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR 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
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/30—Payment architectures, schemes or protocols characterised by the use of specific devices or networks
    • G06Q20/36—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using electronic wallets or electronic money safes
    • G06Q20/367—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using electronic wallets or electronic money safes involving electronic purses or money safes
    • G06Q20/3678—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using electronic wallets or electronic money safes involving electronic purses or money safes e-cash details, e.g. blinded, divisible or detecting double spending
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR 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
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/38—Payment protocols; Details thereof
    • G06Q20/382—Payment protocols; Details thereof insuring higher security of transaction
    • G06Q20/3829—Payment protocols; Details thereof insuring higher security of transaction involving key management
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR 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
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/38—Payment protocols; Details thereof
    • G06Q20/389—Keeping log of transactions for guaranteeing non-repudiation of a transaction
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR 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
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/38—Payment protocols; Details thereof
    • G06Q20/40—Authorisation, e.g. identification of payer or payee, verification of customer or shop credentials; Review and approval of payers, e.g. check credit lines or negative lists
    • G06Q20/401—Transaction verification
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR 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
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/38—Payment protocols; Details thereof
    • G06Q20/40—Authorisation, e.g. identification of payer or payee, verification of customer or shop credentials; Review and approval of payers, e.g. check credit lines or negative lists
    • G06Q20/401—Transaction verification
    • G06Q20/4016—Transaction verification involving fraud or risk level assessment in transaction processing
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR 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/3236—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 cryptographic hash functions
    • H04L9/3239—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 cryptographic hash functions involving non-keyed hash functions, e.g. modification detection codes [MDCs], MD5, SHA or RIPEMD
    • 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/50—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols using hash chains, e.g. blockchains or hash trees
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR 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
    • G06Q2220/00—Business processing using cryptography

Definitions

  • This application relates to the field of computer technology, in particular to transaction weight verification technology.
  • a blockchain node for example, node A
  • a transaction for example, transaction T
  • it needs to perform a transaction check on the transaction T that is, in the transaction cache of the node A and In the blockchain database associated with the node A, query whether the transaction T already exists; this means that the existing transaction weight verification scheme, when performing transaction weight verification on any transaction based on the transaction cache, if the transaction T If the transaction is not found in the cache, it is necessary to further request access to the blockchain database through the blockchain network to check whether the transaction exists in the blockchain database.
  • the existing transaction weight verification scheme will involve the access of the blockchain node to the blockchain database.
  • the blockchain node When the blockchain node receives multiple transactions (for example, the same transaction frequently sent by the blockchain client) , it will involve multiple visits to the blockchain database; frequent access to the blockchain database will affect the query performance of the blockchain database, which in turn will reduce the speed of transaction weight verification in the blockchain database , that is, to reduce the efficiency of blockchain nodes for transaction weight verification.
  • the present application provides a transaction weight verification method, device, equipment and medium, which can improve the efficiency of transaction weight verification.
  • the present application provides a transaction weight verification method, the method is executed by the first node in the blockchain network, and a transaction weight verification device is deployed in the first node, the method includes:
  • the query bit array includes M array elements, and the M array elements include the first array element; M is an integer greater than 1, and K is a positive integer smaller than M;
  • the transaction to be processed is mapped to the K target identification positions of the bit array to be queried; among the M array elements, the array elements at the K target identification positions are used as transactions at the K target identification positions map value;
  • the present application provides a transaction weighing device, which includes:
  • the transaction acquisition module is used to acquire pending transactions to be uploaded to the blockchain network
  • the first weight checking module is used to obtain the digit array and K hash functions of the transaction weight checker when performing the first transaction weight check on the transaction to be processed through the transaction weight checker, and use the obtained digit array as the pending transaction
  • the corresponding bit array to be queried; the bit array to be queried includes M array elements, and the M array elements include the first array element; M is an integer greater than 1, and K is a positive integer less than M;
  • the mapping value determination module is used to map the transaction to be processed to the K target identification positions of the bit array to be queried based on K hash functions; among the M array elements, the array elements at the K target identification positions are used as K The transaction mapping value at the position of target identification;
  • the first result determination module is configured to determine the association relationship between the first array element and the transaction mapping values at the K target identification positions, and obtain the first transaction weight verification for the transaction to be processed based on the association relationship. result.
  • An embodiment of the present application provides a computer device, including: a processor and a memory;
  • the processor is connected to the memory, wherein the memory is used to store a computer program, and when the computer program is executed by the processor, the computer device executes the method provided by the embodiment of the present application.
  • Embodiments of the present application provide, on the one hand, a computer-readable storage medium, where a computer program is stored in the computer-readable storage medium, and the computer program is adapted to be loaded and executed by a processor, so that a computing device having the processor executes the present application.
  • An embodiment of the present application provides a computer program product or computer program, where the computer program product or computer program includes computer instructions, and the computer instructions are stored in a computer-readable storage medium.
  • the processor of the computer device reads the computer instruction from the computer-readable storage medium, and the processor executes the computer instruction, so that the computer device executes the method provided by the embodiment of the present application.
  • the computer device (for example, the first node in the blockchain network) in the embodiment of the present application is equipped with a transaction checker for transaction check, so that when the computer device obtains a transaction to be processed, it can pass the transaction in advance.
  • the checker performs the first transaction check on the transaction to be processed.
  • the computer device can obtain the bit array and K hash functions of the transaction checker, and then can use the acquired bit array as the corresponding transaction to be processed.
  • the bit array to be queried it should be noted that the M array elements of the bit array to be queried here include the first array element; K here is a positive integer less than M; M is the array length of the bit array to be queried.
  • the computer device can map the transaction to be processed to the K target identification positions of the bit array to be queried based on the K hash functions, and can map the array elements at the K target identification positions among the M array elements As the transaction mapping value at K target identification positions.
  • a hash function can map the transaction to be processed into a point in the bit array to be queried, and the identification position of the point is a target identification position of the bit array to be queried.
  • the computer device can determine the association relationship between the first array element and the transaction mapping values at the K target identification positions, and then can obtain the first transaction weight verification after the first transaction weight verification of the transaction to be processed based on the association relationship result.
  • FIG. 1 is a schematic diagram of a network architecture provided by an embodiment of the present application.
  • Fig. 2 is a schematic diagram of a scene of transaction weight verification in the node memory provided by the embodiment of the present application;
  • Fig. 3 is a schematic flow chart of a transaction weight checking method provided by the present application.
  • FIG. 4 is a schematic diagram of a scene for determining a bit array to be queried provided by an embodiment of the present application
  • Fig. 5 is a schematic diagram of a scenario where transactions to be processed are mapped to bit groups to be queried through the hash function of the transaction checker provided by the embodiment of the present application;
  • Fig. 6 is a schematic flow chart of a transaction weight verification method provided by the embodiment of the present application.
  • FIG. 7 is a schematic diagram of a scene for updating a bit array to be queried provided by an embodiment of the present application.
  • Fig. 8 is a sequence diagram of transaction weight verification for a transaction in a service request provided by an embodiment of the present application.
  • Fig. 9 is a schematic flow chart of a transaction weight verification method provided by the embodiment of the present application.
  • Fig. 10 is an embodiment of a scenario of transaction weight verification for transactions in a block provided by the embodiment of this application;
  • Fig. 11 is a schematic structural diagram of a transaction weighing device provided by the present application.
  • FIG. 12 is a schematic structural diagram of a computer device provided by an embodiment of the present application.
  • FIG. 1 is a schematic diagram of a network architecture provided by an embodiment of the present application.
  • the network architecture shown in Figure 1 can be applied to a blockchain system, which can be a distributed system formed by connecting multiple nodes through network communication.
  • the blockchain system may include, but is not limited to, the blockchain system corresponding to the consortium chain.
  • Blockchain is a new application mode of computer technology such as distributed data storage, point-to-point transmission, consensus mechanism and encryption algorithm. It is mainly used to organize data in chronological order and encrypt it into ledgers so that it cannot be tampered with or forged. , while supporting data validation, storage, and update processing.
  • the blockchain is essentially a decentralized database. Each node in the database stores the same blockchain.
  • the blockchain network divides nodes into core nodes and light nodes. Among them, the core node can be responsible for the district
  • the consensus of the entire blockchain network means that the core node can be a consensus node in the blockchain network.
  • any node for example, a light node
  • the consensus node used for packaging in the blockchain network can further add the transaction to the main core node The transaction pool, so that the main core node will package the transaction and other transactions in the transaction pool into a block, and then broadcast the packaged block (that is, the target block) to other consensus in the blockchain network node (that is, the slave core node in the blockchain network), so that other consensus nodes perform block consensus on the target block, and after these consensus nodes reach a consensus, write the target block into the local ledger (for example, written into the transaction cache of the node memory), so that the target block can be written into the blockchain database corresponding to the target blockchain in the blockchain network (also referred to as the database for short).
  • the target blockchain here can be
  • the blockchain system can include smart contracts, which can be understood as codes that can be understood and executed between nodes (including consensus nodes) in the blockchain system, and can execute arbitrary logic and get results .
  • Users can initiate a transaction addition request for a certain transaction to any node in the blockchain network through the blockchain client, and then the nodes in the blockchain network (for example, the above-mentioned slave core nodes or light nodes) can Send the transaction carried in the transaction addition request to the above-mentioned main core node, so that the above-mentioned main core node can pre-judge whether the currently received transaction already exists in the blockchain network before calling the smart contract to execute the transaction requested by the user .
  • smart contracts can be understood as codes that can be understood and executed between nodes (including consensus nodes) in the blockchain system, and can execute arbitrary logic and get results .
  • Users can initiate a transaction addition request for a certain transaction to any node in the blockchain network through the blockchain client, and then the nodes in the blockchain network (for example, the above-ment
  • the transaction in the transaction addition request can be rejected (that is, the transaction is a repeated transaction). Conversely, if the transaction does not exist in the blockchain network, the transaction in the transaction addition request can be received (that is, the transaction is a non-repeating transaction).
  • the core node in the embodiment of this application After obtaining the transaction requested by the user, it is necessary to perform a first transaction check on the transaction in the node memory of the core node in advance through the transaction checker to determine whether to reject the transaction. In other words, the core node can quickly judge whether the currently acquired transaction is a duplicate transaction through the transaction checker in the node memory. If the transaction weight verification result determined by the transaction weight checker (ie, the first transaction weight verification result) indicates that the currently acquired transaction is a repeated transaction, the transaction in the transaction addition request may be rejected.
  • the transaction weight verification result determined by the transaction weight checker ie, the first transaction weight verification result
  • the transaction weight check result determined by the transaction weight checker indicates that the currently acquired transaction is not a duplicate transaction, it can be further determined that the currently acquired transaction needs to be checked for a second transaction, and then can be successively passed through the node memory.
  • the transaction pool, transaction cache, and blockchain database conduct secondary transaction weight checks, so as to judge whether the currently obtained transaction already exists in the blockchain network through the cooperation of the transaction pool, transaction cache, and blockchain database. If it already exists in the blockchain network, it can be finally determined that the currently obtained transaction is a duplicate transaction, and then refuse to accept the duplicate transaction. Conversely, if it is finally determined that the currently acquired transaction is a non-repeating transaction after the second transaction weight check, the non-repeating transaction can be added to the transaction pool.
  • one or more smart contracts can be included in the blockchain system, and these smart contracts can be distinguished by the contract call address, contract identification number (Identity document, ID) or contract name, and the blockchain client
  • the initiated transaction addition request can also carry the contract call address of the smart contract or the contract identification number or contract name to specify the smart contract that needs to be run.
  • each consensus node can call the data reading contract to quickly access Local ledgers (for example, each consensus node can quickly access the multi-level block cache built through the block chain structure in the node memory, wherein the multi-level block cache is based on the block hash of each block cached in the node memory of each consensus node
  • the index method of the Greek value is obtained by arranging the block cache of each block; a block cache can be used to store the transaction read cache and transaction write cache of each transaction in a block), and read the corresponding data.
  • each consensus node will verify with each other whether the transaction execution results for the transaction are consistent (that is, consensus). If they are consistent, the transaction can be determined to be a legal transaction, and then the transaction execution results of the legal transaction can be stored in their respective local The transactions of the ledger are written in the cache, and the transaction execution results of the above transactions can be returned to the blockchain client.
  • the network architecture shown in FIG. 1 may include a cluster of core nodes (that is, consensus nodes), a cluster of light nodes, and a cluster of user terminals.
  • the core node cluster may include one or more core nodes, and the multiple core nodes here may specifically include node 10a, node 10b, node 10c, and node 10d shown in FIG. 1 .
  • nodes 10 a , 10 b , and 10 d can be respectively connected to a network with node 10 c to form the consensus network 100 a shown in FIG. 1 .
  • the nodes 10a, 10b, and 10d can exchange data through the network connection with the node 10c.
  • the light node cluster may include one or more light nodes.
  • a light node is taken here as an example.
  • the light node is the node 4000a shown in FIG.
  • the network connection between nodes 10c performs data exchange.
  • the user terminal cluster shown in FIG. 1 may include one or more user terminals, and the multiple user terminals here may specifically include user terminal 3000a, user terminal 3000b, user terminal 3000c, ..., user terminal 3000c shown in FIG. Terminal 3000n. As shown in Fig.
  • user terminal 3000a, user terminal 3000b, user terminal 3000c, ..., user terminal 3000n can be respectively connected to the network with the node 4000a in the light node cluster, so as to pass through the network connection with the node 4000a Network connection for data exchange.
  • each core node (for example, node 10a, node 10b, node 10c, node 10d) in the consensus network 100a and each light node in the light node cluster can be collectively referred to as a blockchain node. All blockchain nodes can receive transaction addition requests sent by user terminals running blockchain clients. It should be understood that each core node here can maintain the same blockchain (for example, the blockchain 10e shown in FIG.
  • a point-to-point (P2P, Peer To Peer) network can be formed between any two core nodes in the network, and the point-to-point network can adopt the P2P protocol, which is a protocol running on the Transmission Control Protocol (TCP, Transmission Control Protocol) Application layer protocol.
  • P2P Peer To Peer
  • TCP Transmission Control Protocol
  • any device such as a server, terminal, etc. can be added as a blockchain node, where each blockchain node can include a hardware layer, an intermediate layer, an operating system layer, and an application layer.
  • a blockchain node can be bound to any role (for example, any individual user, any enterprise, any institution, etc.) that accesses the blockchain network, and these blockchain nodes
  • the formed blockchain network is collectively referred to as the alliance chain network. Therefore, there may be a one-to-one correspondence between the nodes 10a, 10b, 10c, and 10d shown in FIG. 1 and the corresponding roles (that is, entity objects in corresponding business scenarios) connected to the blockchain network.
  • the business scenarios here may include electronic bill scenarios, social scenarios, credit purchase scenarios, credit scenarios, etc.
  • the target business in the corresponding business scenario may specifically include electronic bill business, social networking business, credit purchase business, credit business, etc., and the specific business in the corresponding business scenario will not be listed here.
  • each entity object can correspond to a block chain node
  • the embodiment of the present application can take the entity object as the above-mentioned enterprise user (that is, the aforementioned enterprise) as an example.
  • the block chain associated with each enterprise user The nodes can be the same block chain node (for example, the node 4000a shown in FIG. 1 above can perform data interaction with user terminals corresponding to multiple enterprise users).
  • the electronic bill business corresponding to each billing enterprise for example, registration business, billing business, bill transfer business, etc.
  • a transaction business for example, registration business, billing business, bill transfer business, etc.
  • the billing company A can perform data interaction with the node 4000a shown in Figure 1 through the user terminal 3000a shown in Figure 1 to complete the corresponding transaction; and so on, the billing company B can use the user terminal 3000b shown in Figure Perform data interaction with the node 4000a shown in Figure 1 to complete the corresponding transaction; billing enterprise C can perform data interaction with the node 4000a shown in Figure 1 through the user terminal 3000c shown in Figure 1 to complete the corresponding transaction.
  • entity objects for example, billing company A, billing company B, .
  • the transaction addition request sent by the requesting user can be received through the above-mentioned light node, and the requesting user (for example, the transaction addition request sent by billing enterprise A, billing enterprise B, ..., billing enterprise C), here is not limited to the node type of the blockchain node receiving the transaction addition request.
  • the above-mentioned node 10c can perform data synchronization between other blockchain nodes with which it has a network connection (also called a session connection), that is, the above-mentioned node 10c can obtain data from other blockchain nodes.
  • the corresponding business data information is synchronized on the node (for example, the business data information here may include but not limited to the transaction in the above-mentioned transaction addition request and the block in the block synchronization request, etc.), at this time, each enterprise user is associated with
  • the core nodes of can be different blockchain nodes.
  • the billing company A can also perform data interaction with the node 10c shown in FIG. 1 through the user terminal 3000a shown in FIG.
  • the billing company B can also communicate with the node 10b shown in FIG. Perform data interaction; the billing company C can also perform data interaction with the node 4000a shown in FIG. 1 through the user terminal 3000c shown in FIG. 1 .
  • the network load in the blockchain network can be effectively balanced, thereby improving the business data corresponding to the corresponding business. processing efficiency.
  • the light node when it receives the transaction addition request sent by the requesting user corresponding to the blockchain client, it can forward the transaction addition request sent by the requesting user to the above-mentioned main core node, so as to pass the above-mentioned main core node to The transaction in the transaction addition request sent by the requesting user is checked for transaction weight.
  • the main core node can add the transaction requested by the requesting user (that is, a legal and non-repeated transaction) to the transaction pool after the transaction weight check is passed, so that the transaction data associated with the transaction can be packaged into a block, and Other consensus nodes (i.e.
  • Block chain database also can be referred to simply as database
  • FIG. 2 is a schematic diagram of a scenario of transaction weight verification in the node memory provided by an embodiment of the present application.
  • the user A shown in FIG. 2 can execute step S1 through the user terminal 20a shown in FIG. 2 to execute the transaction T1 requested by the user A (for example, the transaction T1 can be the Enterprise B issues an electronic invoice (invoice issuing business) and sends it to the node 20c shown in FIG. 2 .
  • the node 20c may execute step S2 to perform transaction weight verification on the transaction T1.
  • the blockchain node for example, the node 20c shown in FIG.
  • the nodes 20b, 20d, and 20e shown in FIG. 2 are collectively referred to as the second node.
  • the node 20c i.e.
  • the first node can receive the transaction T1 in the transaction addition request sent by the user terminal 20a running the blockchain client, and can also receive other nodes in the blockchain network ( That is, the transaction in the target block broadcast by the second node), whether the node 20c receives the transaction from the transaction addition request or receives the transaction in the target block broadcast by other nodes, it can execute the transaction shown in Figure 2 Step S2 of the step S2, to check the transaction weight of the currently received transaction, and judge whether the currently received transaction exists in the blockchain network.
  • the transaction checker shown in FIG. 2 includes a super large bit array and K hash functions; the length of the super large bit array may be M, where K may be a positive integer smaller than M.
  • the transaction checker after the node 20c obtains the above-mentioned transaction T1, it can use the transaction checker to perform transaction check on the transaction T1 to obtain the first transaction check result.
  • FIG. 2 among the M array elements of the bit array 201a, there may be an array element with a value of 0, and there may also be an array element with a value of 1.
  • array elements with a value of 0 may be collectively referred to as the first array element of the bit array, and array elements with a value of 1 may be collectively referred to as the second array element of the bit array.
  • each array element corresponds to an identification position.
  • the identification positions of these array elements may be identification positions 2 a to 2 p shown in FIG. 2 .
  • the array element corresponding to the identification position 2a is 0, and the array element corresponding to the identification position 2b is 1.
  • the array element corresponding to the identification position 2o is 0, and the array element corresponding to the identification position 2p is 1.
  • the value of M here can be adjusted according to the actual needs of the blockchain system, that is, the embodiment of this application does not limit the value of M.
  • the embodiment of the present application takes the K hash functions of the transaction weight checker as an example of 3 hash functions, and these 3 hash functions can specifically be the hash function 202a shown in FIG. function 202b and hash function 202c.
  • the hash function 202a can be used to perform hash calculation (for example, hash position mapping) on the hash value (for example, hash value 1) of the transaction T1 shown in Figure 2, so that the transaction T1 is mapped to a point in the bit array 201a (for example, point 1, this point 1 can be a bit), the target identification position corresponding to this point 1 can be the identification position 2e, and the array element on the identification position 2e is the above-mentioned first Two array elements.
  • hash function 202a can be used to perform hash calculation (for example, hash position mapping) on the hash value (for example, hash value 1) of the transaction T1 shown in Figure 2, so that the transaction T1 is mapped to a point in the bit array 201a (for example,
  • Map the transaction T1 to another point in the bit array 201a (for example, point 3, the point 3 can be a bit), the target identification position corresponding to the point 3 can be the identification position 2o, the array on the identification position 2o
  • the elements are the above-mentioned first array elements.
  • the specific implementation of performing hash calculation (for example, hash position mapping) on the hash value of transaction T1 through K hash functions here may include but not limited to performing a remainder operation on the hash value of transaction T1 , and then map the transaction T1 to the target identification position in the bit array 201a according to the one-to-one mapping relationship between the calculated remainder and the identification position in the bit array 201a.
  • the node 20c in the embodiment of the present application can perform hash calculation on the transaction data (also referred to as the transaction content) of the transaction T1 to obtain the unique identifier for the transaction T1.
  • Transaction hash eg, hash 1 above.
  • the node 20c can use the transaction hash value (for example, the above hash value 1) of the transaction T1 as the transaction checker shown in FIG.
  • the transaction checker is deployed in the node memory of the node 20c input value, so that the transaction checker can perform hash calculation on the input value again (for example, the above-mentioned Hash remainder operation) to obtain the above K bits associated with the transaction T1 (namely the above-mentioned identification position 2e, identification position 2m and identification position 2o).
  • the array elements on these K bits may be collectively referred to as a transaction mapping value.
  • the transaction checker here can be understood as a filter with a transaction check function (for example, the transaction checker can include but not limited to a Bloom filter).
  • the transaction checker can fundamentally solve repeated transactions frequently sent by malicious nodes, thereby preventing these repeated transactions from wasting the limited resource space of the node memory of the node 20c.
  • the transaction weight checker here can be used to maintain a weight check set, but it will not store the weight check element itself that has been inserted in the weight check set (that is, when node 20c needs to insert a certain transaction as a weight check element
  • the array elements at the K identification positions corresponding to the weight check element will be set to 1, so as to obtain the bit array 201a) shown in Figure 2 above, which is for some For transactions with a certain degree of privacy, higher security can be ensured.
  • the K hash functions in the transaction checker are independent of each other. In this way, after the above-mentioned node 20c obtains the above-mentioned transaction T1, the K hash functions can be directly executed in parallel by the hardware of the node 20c to pass These K hash functions map the transaction T1 shown in Figure 2 to the K target identification positions of the bit array 201a, and then can be based on the mapping between the first array element in the transaction weight checker and the K target identification positions The association relationship between the values is obtained to obtain the above-mentioned first transaction weight verification result. It can be seen that through the transaction weight checker shown in Figure 2, the currently acquired duplicate transactions can be quickly filtered in the node memory.
  • the transaction T1 has the same transaction mapping value as the first array element in the transaction mapping value at the three target identification positions, so it can be directly determined that the transaction T1 is not in the above-mentioned weight verification set, that is, it can be directly It is determined that the transaction T1 is a non-repeating transaction, and then the transaction T1 can be directly added to the transaction pool 200a in Figure 2 for storage in the node memory without accessing the blockchain database in Figure 2, which can increase the speed of transaction weight verification.
  • the first association relationship between the first array elements and the transaction mapping values at the K target identification positions can be obtained , the first relationship is used to reflect that the transaction T1 must not exist in the transaction weight verification set of the transaction weight checker, and then the transaction T1 can be directly regarded as a non-repeated transaction, so that the user terminal 20a shown in Figure 2 can be received Send the transaction T1, and add the transaction T1 to the transaction pool 200a.
  • the node 20c can also insert the transaction T1 as a weight checking element into the above-mentioned transaction weight checker, that is, at this time, the node 20c will be in the position shown in Figure 2 In the array 201a (that is, the bit array to be queried corresponding to the transaction T1), the array elements on the K target identification positions corresponding to the weight checking element (that is, the array element on the identification position 2e, the array element on the identification position 2m and The array elements at the identification position 2o) are all changed to 1 to obtain a new bit array, which can be used as the bit array to be queried for the next transaction.
  • the array elements on the K target identification positions corresponding to the weight checking element that is, the array element on the identification position 2e, the array element on the identification position 2m and The array elements at the identification position 2o
  • the transaction weight of the transaction T2 can still be checked by the transaction checker shown in Figure 2, that is, the first array element can be judged The association relationship with the K transaction mapping values of the transaction T2.
  • the transaction T2 can also be added to the transaction pool 200a, and the array elements at the positions of the K target identifiers corresponding to the transaction T2 are all changed to 1, that is, the transaction T2
  • the array elements at the corresponding K target identification positions are all set as the second array elements, so as to insert the transaction T2 into the weight checking set of the transaction weight checking device as a weight checking element.
  • the second association between the first array element and the transaction mapping values at the K target identification positions can be obtained relationship, the second association relationship is used to reflect that another transaction (for example, transaction T2) sent by other user terminals may exist in the verification set of the transaction checker, that is, the transaction T2 may be a repeated transaction.
  • transaction T2 may be a repeated transaction.
  • the reason why it is impossible to accurately determine whether transaction T2 is a repeated transaction in this case is that the array elements in the bit array of the transaction weight checker are shared, and different weight check elements in the weight check set may share the same value. Identifies the condition of the array element at position.
  • the embodiment of the present application can further search whether there is a first historical transaction matching the transaction T2 in the transaction pool 200a shown in FIG.
  • the transaction cache shown in Figure 2 find out whether the second historical transaction matching the transaction T2 is found, and if it is still not found, you can access the blockchain database 200d shown in Figure 2 through the blockchain network to make a final judgment Whether the transaction T2 is a non-repeating transaction.
  • the node 20c can therefore be allowed to add the transaction T2 to the transaction pool 200a shown in FIG.
  • FIG. 2 Other nodes shown in Figure 2 (for example, consensus node 20b, consensus node 20d, and consensus node 20e) carry out block consensus on the target block, and after the block consensus is passed, the target block is temporarily stored in Figure 2 The transaction cache shown, so that when the target block in the transaction cache is chained to the above-mentioned target blockchain, the transaction and transaction execution results in the target block are stored in the blockchain shown in Figure 2 Database 200d.
  • the first association relationship or the second association relationship system here can be referred to as the first transaction weight verification result after the first transaction weight verification of the transaction to be processed, and can pass through the transaction pool 200a and the local ledger layer 200c.
  • the transaction cache or the blockchain database 200d, and the finally obtained transaction weight verification results are collectively referred to as the second transaction weight verification results.
  • Figure 3 is a schematic flow diagram of a transaction weight verification method provided by the present application. As shown in Figure 3, the method can be executed by the first node in the above-mentioned blockchain network, and the first node It should be understood that the first node may be any node in the consensus network 100a shown in FIG. 1 above. The method may specifically include the following steps S101 to S104.
  • Step S101 acquire pending transactions to be uploaded to the blockchain network.
  • the first node when acquiring a certain transaction, may regard the acquired transaction as a transaction to be processed. The first node may further determine the transaction source attribute of the transaction to be processed, and then use different transaction weight verification strategies to perform transaction weight verification on the pending transaction through different transaction source attributes.
  • the transaction here may come from a first source, and the first source refers to a transaction addition request sent from a blockchain client.
  • the transactions here can also come from the second source, the second source refers to blocks broadcast from other nodes, or the transactions here can come from the third source, the third source refers to the transaction pool that can be synchronized from other nodes transactions in .
  • the source attributes of the first source and the third source may be collectively referred to as the first source attribute
  • the source attributes of the second source may be collectively referred to as the second source attribute.
  • the first source attribute can be used to characterize that the transaction to be processed is a transaction (for example, transaction Tx1) in the transaction addition request sent by the blockchain client; optionally, the first source attribute can also be used to represent The transaction to be processed is a transaction synchronized from the transaction pool of the second node (for example, transaction Tx2).
  • the second source attribute is used to characterize that the transaction to be processed is a transaction in the block sent by the above-mentioned second node (for example, other consensus nodes in the blockchain network) (for example, the transaction in the block may specifically include the transaction 1, transaction 2, ..., transaction N).
  • the first transaction weight verification strategy and/or the second transaction weight verification strategy may be used to perform transaction weight verification on the transaction to be processed.
  • the following steps S102 to S104 may be executed using the first transaction weight verification strategy, so as to perform the first transaction weight verification on the transaction currently acquired by the first node.
  • the third transaction weight verification strategy and/or the fourth transaction weight verification strategy may be used to perform transaction weight verification on the transactions in the target block.
  • the first node may control the transaction checker to traverse each transaction in the block (ie, the above-mentioned target block) based on the third transaction weight-checking policy in advance (ie, the above-mentioned transaction 1, transaction 2, ..., transaction N ) to carry out the transaction weight check, so as to obtain the block transaction weight check result corresponding to the target block.
  • each transaction in the target block is not a duplicate transaction (that is, each transaction in the target block is is a non-repeated transaction)
  • the target block can be received, and then the bit group ( That is, the array element at the position corresponding to the target identifier in the bit array to be queried) is changed to 1.
  • the transaction checker once it is determined that a certain transaction in the target block may be a duplicate transaction, it can be further based on the fourth transaction weight check strategy, in the transaction The transaction weight is checked again in the cache and the blockchain ledger to avoid misidentifying the transaction in the target block as a duplicate transaction.
  • the transaction source attribute determined by the first node is the above-mentioned first source attribute.
  • the first node can use the above-mentioned first transaction weight verification strategy to perform the following steps based on the first source attribute S102.
  • Step S102 after the first transaction check is performed on the transaction to be processed by the transaction checker, the bit array and K hash functions of the transaction checker are obtained, and the acquired bit array is used as the bit array to be queried corresponding to the transaction to be processed .
  • the bit array to be queried includes M array elements, and the M array elements include the first array element; M is the array length of the bit array to be queried, M is an integer greater than 1, and K is a positive integer smaller than M.
  • the first node can obtain a bit array with an array length of M from the transaction weight checker when performing the first transaction weight check on the transaction to be processed based on the first transaction weight check strategy through the transaction checker, and obtain the K hash functions associated with a bit array with a length of M; in the bit array with an array length of M, the array elements at the K key identification positions mapped to the weight check elements in the weight check set of the transaction weight checker are all It is the second array element (the second array element here can be the above-mentioned array element with a value of 1); a key identification position is the identification position obtained after the weight check element is mapped to the hash position by a hash function; further , the first node can be in the bit array whose array length is M, and the array element except the second array element among the M array elements can be used as the first array element (the first array element here can be the above-mentioned value 0 array element); wherein, the identification position corresponding to the first array element is different from the identification position
  • FIG. 4 is a schematic diagram of a scene for determining a bit group to be queried according to an embodiment of the present application.
  • the first node when it conducts a transaction query on the currently acquired transaction (that is, the transaction to be processed) based on the above-mentioned first transaction weight verification strategy, it can trigger the transaction weight checker 4a shown in Figure 4 to obtain
  • the bit array 401a currently maintained by the transaction checker 4a the bit array 401a shown in Figure 4 contains M array elements, and the M array elements are composed of a very long binary vector, that is, each array An element can be represented by a bit of 1 or a bit of 0.
  • the array element whose value is 0 is the above-mentioned first array element
  • the array element whose value is 1 is the above-mentioned second array element.
  • the bit array composed of the first array element and the second array element (that is, the bit array 401a shown in FIG. 4 ) may be used as the bit array to be queried corresponding to the transaction to be processed.
  • the first node When the first node acquires the above-mentioned bit array with an array length of M (that is, the bit array 401a shown in FIG. 4 ), it may also acquire K hash functions of the transaction checker. It should be understood that the K hash functions here may include the hash function 41a, the hash function 41b, ..., the hash function 41k shown in FIG. 4 .
  • the transaction map obtained after the hash map can be increased
  • the randomness of the value makes the transaction mapping value after hash mapping the transaction hash value of a transaction can be distributed as evenly as possible in the bit group of the transaction checker, thereby reducing the The probability of a hash collision of the transaction mapping value obtained after the transaction hash value is hash mapped.
  • the transaction checker 401a has three hash functions.
  • the three hash functions may be the hash function 41a, the hash function 41b, and the hash function 41k shown in FIG. 4 .
  • the transaction weight checker itself does not directly store the three weight check elements in the weight check set it maintains.
  • the array elements on the K key identification positions mapped by each weight-checking element in the weight-checking set are the second array elements; for a weight-checking element Regarding the associated K key identification positions, a key identification position is an identification position obtained by performing hash position mapping on a weight verification element through a hash function.
  • the element A1 can be currently mapped to the three target identification positions of the bit array 401 (for example, identification position 4b, The transaction mapping values at the marked position 4f and the marked position 4m) are both changed to 1.
  • the element A2 can be currently mapped to the three target identification positions of the bit array 401 (for example, identification position 4e , the transaction mapping values on the identification position 4f and the identification position 4k) are all changed to 1.
  • the element A3 can be currently mapped to the three target identification positions of the bit array 401 (for example, the identification position
  • the transaction mapping values at 4d, the identification position 4k and the identification position 4p) are all changed to 1.
  • element A1 and element A2 there may be a second array element (that is, an array element with a value of 1) that shares the same identification position (for example, identification position 4f shown in Figure 4 )
  • a second array element that is, an array element with a value of 1 sharing the same identification position (for example, the identification position 4k shown in FIG. 4 ).
  • the first node checks the currently acquired transaction through the transaction checker 401 a shown in FIG. 4 , it can accurately determine whether the currently acquired transaction exists in the check set. For example, in the case that the K (for example, 3) target identifier positions associated with the currently acquired transaction exist at 0, it can be accurately and quickly judged that the current transaction does not exist in the weight check set, that is, Determine that the currently acquired transaction is a non-repeating transaction.
  • the embodiment of the present application further needs to perform a second transaction weight verification on the currently acquired transaction based on the above-mentioned second transaction weight verification strategy, so as to further verify whether the currently acquired transaction is a repeated transaction, thereby improving transaction Check reliability.
  • Step S103 based on K hash functions, map the transaction to be processed to the K target identification positions of the bit array to be queried; among the M array elements, use the array elements at the K target identification positions as the K target identification positions The transaction mapping value on .
  • FIG. 5 is a schematic diagram of a scenario in which a transaction to be processed is mapped to a bit array to be queried through a hash function of a transaction checker provided by an embodiment of the present application.
  • the bit array 502a shown in FIG. 5 may be the bit array to be queried in the above embodiment corresponding to FIG. 4 . That is, the array of bits to be queried can be used to determine whether the transaction Tx1 shown in FIG. 5 exists in the verification set of the transaction verification device.
  • the first node can communicate with the user terminal (the user terminal running the blockchain client) that sends the above transaction addition request through the first node.
  • the hash conversion rules followed between the terminals) perform hash calculation on the transaction Tx1 to obtain the transaction hash value used to uniquely identify the transaction Tx1.
  • the first node can input the transaction hash value of the transaction Tx1 into the transaction checker 5a shown in Figure 5, that is, the transaction hash value of the transaction Tx1 is used as the input of the transaction checker value.
  • these three points can be the transaction mapping value on the identification position 5b (i.e. target identification position 1) shown in Figure 5, the transaction mapping value on the identification position 5f (i.e. target identification position 2), the identification position 5o (i.e. Target identifies the transaction map value at position 3).
  • the first node may further determine the correlation between the first array element in the bit array to be queried (that is, the array element with a value of 0) and the transaction mapping values at the three target identification positions. That is, it is possible to check whether there is a transaction mapping value identical to that of the first array element among the transaction mapping values at the three target identification positions, and if found, it can be determined that the transaction Tx1 does not exist in the transaction checker 5a In the maintained weight check set. On the contrary, it can be temporarily considered that the transaction Tx1 may exist in the weight check set maintained by the transaction weight checker 5a. Based on the above second transaction weight check strategy, the second transaction pool, transaction cache and blockchain database need to be further carried out. Transaction weight check to finally judge whether the transaction Tx1 exists in the blockchain network.
  • Step S104 determining the association relationship between the first array element and the transaction mapping values at the K target identification positions, and obtaining the first transaction weight verification result of the first transaction weight verification for the transaction to be processed based on the association relationship.
  • the association relationship between the first array elements and the transaction mapping values at the K target identification positions is the first association relationship
  • the transaction mapping value on the identification position 5b i.e. the target identification position 1
  • the transaction mapping value on the identification position 5f i.e. the target identification position 2
  • the first association relationship and then based on the first association relationship, it can be determined that the transaction Tx1 does not exist in the verification set maintained by the transaction weight checker 5a, and then the transaction weight checker 5a can be controlled to output the non-existence and verification of Tx1.
  • the weight check result of the transaction in the weight check set, and the output Tx1 does not exist and the weight check result of the transaction in the weight check set can be used as the first transaction weight check result of the first transaction weight check for the above-mentioned transactions to be processed.
  • the node memory of the first node can be used to determine whether the transaction to be processed exists in the verification set maintained by the transaction verification device in advance in the node memory of the first node. , and the determined transaction weight verification result can be used as the first transaction weight verification result after the first transaction weight verification of the transaction to be processed. It should be understood that in the embodiment of the present application, by using the transaction checker in the memory of the node to perform transaction check, it can quickly determine that the current transaction is a non-repeated transaction.
  • the embodiment of the present application can directly judge whether the transaction to be processed exists in the transaction weight checker through the relationship between the first array element in the transaction checker and the transaction mapping values at K target identification positions. In the weight checking set maintained, the efficiency of transaction weight checking can be improved without accessing the blockchain database.
  • FIG. 6 is a schematic flowchart of a transaction weight verification method provided by an embodiment of the present application.
  • the method can be executed by a first node in the blockchain network, and the first node can be any blockchain node in the consensus network 100a shown in FIG. 1 (for example, the above-mentioned node 10c).
  • the method specifically includes the following steps S201-S216:
  • Step S201 acquiring pending transactions to be uploaded to the blockchain network.
  • Step S202 determining the transaction source attribute of the transaction to be processed.
  • the transaction source attribute is used to indicate the transaction weight verification strategy used by the transaction weight checker (for example, the above-mentioned Bloom filter) to check the transaction weight of the transaction to be processed.
  • the transaction weight checker for example, the above-mentioned Bloom filter
  • the transaction weight verification strategy includes the first transaction weight verification strategy and the second transaction weight verification strategy associated with the transaction pool of the first node; for ease of understanding, the first The source attribute is used to represent the transaction to be processed as the transaction in the transaction adding request.
  • the transaction adding request can be sent by the blockchain client associated with the first node; then the first node can further execute Step S203 as follows.
  • Step S203 if the transaction source attribute is the first source attribute, when the transaction weight checker performs the first transaction weight check on the transaction to be processed based on the first transaction weight check strategy, obtain the transaction weight checker with an array length of M bit array, and obtain K hash functions associated with the bit array of array length M.
  • the array elements on the K key identification positions mapped by the weight checking elements in the weight checking set of the transaction weight checking device are all the second array elements;
  • a key identification position is the The identification position obtained after the weight check element is mapped to the hash position by a hash function;
  • Step S204 in the bit array whose array length is M, use the array element except the second array element among the M array elements as the first array element.
  • the identification position corresponding to the first array element is different from the identification position corresponding to the second array element, and the sum of the number of elements in the first array element and the number of elements in the second array element is M.
  • Step S205 using the bit array composed of the first array element and the second array element as the bit array to be queried corresponding to the transaction to be processed.
  • Step S206 based on K hash functions, map the transaction to be processed to the K target identification positions of the bit array to be queried; among the M array elements, use the array elements at the K target identification positions as the K target identification positions The transaction mapping value on .
  • Step S207 determine the relationship between the first array elements and the transaction mapping values at the K target identification positions, and based on the relationship, obtain the first transaction weight verification result after the first transaction weight verification of the transaction to be processed.
  • the association relationship includes a first association relationship, where the first association relationship is used to represent that there is a transaction mapping value identical to the first array element among the transaction mapping values at K target identification positions; at this time, the first node can further Execute the following steps S208-step 210.
  • the association relationship may also include a second association relationship, where the second association relationship is used to indicate that there is no transaction mapping value identical to that of the first array element among the transaction mapping values at K target identification positions; at this time, The first node may further jump to perform step S211 and step S212 after performing the above step S207.
  • Step S208 if the result of the first transaction weight verification indicates that the relationship is the first relationship, then determine that the transaction to be processed does not belong to the weight verification element in the weight verification set of the transaction weight checker, and control the transaction weight checker to output the transaction to be processed
  • the transaction attribute of is a non-repeating transaction attribute.
  • Step S209 determining the transaction to be processed with non-repetitive transaction attribute as the first target transaction to be saved in the transaction pool of the first node.
  • the first target transaction here may be a non-repetitive transaction that is determined by the first transaction verification of the transaction to be processed by the above-mentioned transaction verification device.
  • the first node may execute the following step S210 to add the first target transaction to the transaction pool.
  • Step S210 when saving the first target transaction to the transaction pool of the first node, use the same transaction mapping value as the first array element at K target identification positions as the first target transaction mapping value, and in the bit group to be queried , the array element at the target identification position corresponding to the first target transaction mapping value is updated from the first array element to the second array element.
  • FIG. 7 is a schematic diagram of a scene for updating a bit array to be queried according to an embodiment of the present application.
  • the transaction Tx1 shown in FIG. 7 may be the transaction to be processed in the above embodiment corresponding to FIG. 5 .
  • the first node can map the transaction Tx1 to the three target identification positions of the bit array 701a shown in Figure 7 through the three hash functions of the transaction checker 5a shown in Figure 5 above, which The three target identification positions can be the identification position 7b, the identification position 7f and the identification position 7o shown in Figure 7;
  • the value of the transaction map is the same as the first array element above (ie, the array element with value 0).
  • the first node can determine that the transaction attribute of the transaction Tx1 shown in FIG. 7 is a non-repeating transaction attribute, and can add the transaction Tx1 with the non-repeating transaction attribute as the first target transaction to the transaction pool (for example, the above-mentioned 200a) in the embodiment corresponding to FIG. 2 .
  • the transaction pool for example, the above-mentioned 200a
  • the target bit array 702a is used as the target bit array, so that when a new transaction (for example, transaction Tx2) is obtained later, the target bit array can be used as a new bit array to be queried, so as to repeatedly execute the above steps S205-Step S210.
  • the array elements at the three target identification positions in the bit array 702a are all the second array elements, at this time, the first node can use the transaction Tx1 added to the transaction pool as a new weight check
  • the element is inserted into the weight check set maintained by the transaction weight checker, that is, the number of check elements in the check weight set can be incremented, for example, plus one.
  • the embodiment of the present application can also directly use the same transaction mapping value as the first array element among the transaction mapping values at K target identification positions (that is, the transaction mapping value on the identification position 7o of the bit group 701a shown in Figure 7) as the first target transaction mapping value, and in the bit group to be queried, the target identification position corresponding to the first target transaction mapping value (i.e. The array element at the identified position 7o) is updated from the first array element (ie the value 0 at the identified position 7o of the bit array 701a) to the second array element (ie the value 1 at the identified position 7o of the bit array 702a).
  • Step S211 if the result of the first transaction weight verification indicates that the association relationship is the second association relationship, then obtain the second transaction weight verification policy associated with the transaction pool of the first node.
  • Step S212 based on the second transaction weight verification policy, perform a second transaction weight verification on the transaction to be processed, and obtain a second transaction weight verification result.
  • the first node may search the transaction pool of the first node for the first historical transaction that matches the transaction to be processed based on the second transaction weight verification strategy; If the transaction matches the first historical transaction, it is determined that the transaction attribute of the transaction to be processed is a repeated transaction attribute, and the pending transaction with the repeated transaction attribute is regarded as the first type of repeated transaction associated with the second transaction weight verification strategy; further , the first node may use the first type of repeated transactions as the second transaction weight verification result after performing the second transaction weight verification on the transaction to be processed.
  • the first node can use the first non-repeated transaction attributes to The transaction to be processed is regarded as the first transitional transaction, and the second historical transaction matching the first transitional transaction is searched in the transaction cache of the first node; if the transaction cache of the first node is found to match the first transitional transaction For the second historical transaction, it is determined that the transaction attribute of the first transitional transaction is a repeated transaction attribute, and the first transitional transaction with the repeated transaction attribute is used as the second type of repeated transaction associated with the second transaction weight verification strategy; further, the first transitional transaction A node may use the second type of repeated transaction as the second transaction weight verification result after the second transaction weight verification is performed on the transaction to be processed.
  • the first node can have the second non-repeated transaction attribute based on the second transitional weight verification result
  • the first transitional transaction of the first transitional transaction is used as the second transitional transaction, and the third historical transaction matching the second transitional transaction is found in the blockchain database associated with the first node; if the second transitional transaction is found in the blockchain database If the transition transaction matches the third historical transaction, the transaction attribute of the second transition transaction is determined to be a duplicate transaction attribute, and the second transition transaction with the duplicate transaction attribute is regarded as the third type of duplicate transaction associated with the second transaction weight verification strategy ; Further, the first node may use the third type of repeated transaction as the second transaction weight verification result after the second transaction
  • Step S213 if the second transaction weight verification result indicates that the transaction attribute of the transaction to be processed is a repeated transaction attribute, then determine the pending transaction as a repeated transaction, and refuse to add the repeated transaction to the transaction pool of the first node.
  • Step S214 if the second transaction weight verification result indicates that the transaction attribute of the transaction to be processed is a non-repeating transaction attribute, then based on the pending transaction with the non-repeating transaction attribute, determine the second target for adding to the transaction pool of the first node transaction, and save the second target transaction in the transaction pool of the first node.
  • Step S215 when inserting the second target transaction into the verification set of the transaction checker, use the transaction mapping values at the K target identification positions as the second target transaction mapping values.
  • Step S216 control the transaction weight checker to update the array element at the target identification position corresponding to the second target transaction mapping value in the to-be-queried bit array to the second array element, and use the updated to-be-queried bit array as the target bit array.
  • FIG. 8 is a sequence diagram of transaction weight verification for a transaction in a service request provided by an embodiment of the present application.
  • the first node can receive the transaction 1 sent by the client (here the client is the above-mentioned blockchain client) when executing step S81, and can use the currently received transaction 1 as the above-mentioned step S201 pending transactions in .
  • the transaction 1 here (that is, the transaction to be processed) may be the transaction in the service request sent by the client (that is, the above-mentioned blockchain client).
  • the business request here may include the transaction addition request sent by the user terminal running the blockchain client to request to receive the transaction 1; optionally, the business request here may also include the above-mentioned blockchain A transaction synchronization request sent by the second node in the network to request synchronization of transaction 1 in its own transaction pool.
  • the service request is a transaction addition request
  • the transaction 1 here may be the transaction Tx1 in the above-mentioned embodiment corresponding to FIG. 7 .
  • the service request is a transaction synchronization request
  • the transaction 1 here may be the transaction Tx2 in the above-mentioned embodiment corresponding to FIG. 3 .
  • the first node when the first node determines that the transaction source attribute of the transaction 1 is the first source attribute (that is, the transaction 1 originates from the above-mentioned business request), it can further execute step S82 to pass the transaction weight check
  • the device performs the first transaction weight check on transaction 1 to obtain the above-mentioned first transaction weight check result.
  • the method of obtaining the first transaction weight verification result can refer to the specific description of the above step S203-step S207, which will not be repeated here.
  • step S83 can be skipped to take the transaction 1 as the first target transaction, and then it can be saved to the transaction pool .
  • the first node can further execute step S84, and quickly update the array of bits to be queried in the transaction weight checker according to the array elements at the K target identification positions of the transaction 1 obtained in the above step S82 .
  • step S210 For a specific implementation manner of updating the bit array to be queried by the first node, refer to step S210 in the embodiment corresponding to FIG. 6 above.
  • step S85 executes step S85 shown in Figure 8 to determine whether the transaction 1 (i.e. the transaction to be processed) already exists in the transaction pool; Find historical transactions that match this transaction 1.
  • the embodiments of the present application may collectively refer to the historical transactions in the transaction pool as the first historical transactions.
  • the transaction weight verification result (that is, the transaction weight verification result that transaction 1 already exists in the transaction pool) can be Result 1)
  • the execution of step S86 can be skipped, that is, the transaction 1 can be directly rejected. It should be understood that when the first node determines that transaction 1 already exists in the transaction pool, it can regard the pending transaction with the attribute of repeated transaction as the first type of repeated transaction associated with the second transaction weight verification strategy, and can use the second transaction A type of repeated transaction is used as the second transaction weight verification result after the second transaction weight verification for transaction 1.
  • step S87 may be continued to further determine whether the transaction 1 already exists in the transaction cache.
  • the first node may use the transaction 1 with the non-repeated transaction attribute (ie, the first non-repeated transaction attribute) as the second transaction weight verification policy associated with the second transaction.
  • a transition weight checking result so as to further execute step S87 based on it.
  • the first node can use the transaction 1 with the first non-repeating transaction attribute as the first transition transaction, and further search in the transaction cache of step S87 whether there is a transaction related to the first transition transaction (that is, having the first non-repeating transaction Transactions with attributes 1) Matching historical transactions; for ease of understanding, the embodiments of the present application may collectively refer to the historical transactions stored in the transaction cache as the second historical transactions.
  • the first node finds the second historical transaction that matches the first transitional transaction in the transaction cache, then the transaction weight check result of transaction 1 that already exists in the transaction cache (that is, the weight check result 2 ) as the second transaction weight verification result after the second transaction weight verification is performed on transaction 1, and the execution of step S86 can be skipped, that is, the transaction 1 can be directly rejected.
  • the first node determines that transaction 1 already exists in the transaction cache, it can take the first transitional transaction with the repeated transaction attribute as the second type of repeated transaction associated with the second transaction weight verification strategy, and can use
  • the second type of repeated transaction is the result of the second transaction weight verification after the second transaction weight verification for transaction 1.
  • the first node may Use the transaction weight check result (for example, weight check result 2') that does not exist in the transaction cache in transaction 1 as the second transitional weight check result, and then proceed to step S88 to further determine whether transaction 1 already exists in the blockchain database middle.
  • the first node may use the transaction 1 with the non-repeated transaction attribute (that is, the first non-repeated transaction attribute and the second non-repeated transaction attribute) as the transaction 1 with the second non-repeated transaction attribute.
  • the second transitional weight verification result associated with the second transaction weight verification policy, so that step S88 can be further executed.
  • the first node can use the transaction 1 with the first non-repeating transaction attribute and the second non-repeating transaction attribute as the second transition transaction, that is, the first node takes the transaction 1 that is neither in the transaction pool nor in the transaction cache as the second transition transaction.
  • Two transitional transactions and can further search whether there is a historical transaction matching the second transitional transaction in the block chain database of step S88; Historical transactions are collectively referred to as the third historical transactions.
  • the transaction weight check result i.e.
  • step S86 As the second transaction weight check result after the second transaction weight check on transaction 1, the execution of step S86 can be skipped, that is, the transaction 1 can be directly rejected. It should be understood that when the first node determines that transaction 1 already exists in the blockchain database, it may use the second transitional transaction with the repeated transaction attribute as the third type of repeated transaction associated with the second transaction weight verification strategy, and The third type of repeated transaction can be used as the second transaction weight verification result after the second transaction weight verification is performed on transaction 1.
  • the transaction weight verification result (for example, weight verification result 3') that does not exist in the blockchain database for transaction 1 can be used as the second transaction weight verification result after the second transaction weight verification for transaction 1 , and then step S83 and step 84 can be continued.
  • the first node adds the transaction 1 to the transaction pool based on the above-mentioned second transaction weight verification strategy, and the specific implementation of updating the bit array to be queried can refer to step S214-step in the above-mentioned embodiment corresponding to FIG. 6 S216, no more details will be given here.
  • the node memory of the first node can be used to determine whether the transaction to be processed exists in the verification set maintained by the transaction verification device in advance in the node memory of the first node. , and the determined transaction weight verification result can be used as the first transaction weight verification result of the first transaction weight verification for the transaction to be processed.
  • the embodiment of this application by using the transaction weight checker in the node memory to check the transaction weight, it can quickly determine that the currently acquired transaction is a non-repeated transaction, that is, the embodiment of the application can directly use the transaction weight checker in the transaction weight checker.
  • the correlation between the elements of the first array and the transaction mapping values at K target identification positions can quickly determine whether the transaction to be processed exists in the verification set maintained by the transaction verification device, so as to improve the efficiency of transaction verification.
  • the transaction weight of the transaction to be processed can be checked.
  • the strategy is switched from the first transaction weight verification strategy of the transaction weight checker to the second transaction weight verification strategy associated with the blockchain network, and then the second transaction that is suspected of being a duplicate transaction can be processed based on the second transaction weight verification strategy. Transaction weight verification to obtain the second transaction weight verification result.
  • the second transaction weight checking here refers to further searching whether there is a historical transaction matching the suspected duplicate transaction in the transaction pool, transaction cache and blockchain database associated with the blockchain network, and if so, then Determine that the suspected duplicate transaction is indeed a duplicate transaction. On the contrary, if it does not exist, it can be determined that the suspected repeated transaction is a non-repeated transaction, thereby improving the reliability of transaction weight verification.
  • FIG. 9 is a schematic flowchart of a transaction weight verification method provided by an embodiment of the present application.
  • the method can be executed by a first node in the blockchain network, and the first node can be any blockchain node in the consensus network 100a shown in FIG. 1 (for example, the above-mentioned node 10c).
  • the method specifically includes the following steps S301-S309:
  • Step S301 acquiring pending transactions to be uploaded to the blockchain network.
  • Step S302 determining the transaction source attribute of the transaction to be processed.
  • the transaction source attribute is used to indicate the transaction weight verification strategy used by the transaction weight checker when performing transaction weight verification of the transaction to be processed.
  • the transaction source attribute here may include the above-mentioned first source attribute and the above-mentioned second source attribute.
  • the transaction weight verification strategy may include a first transaction weight verification strategy and a second transaction weight verification strategy associated with the transaction pool of the first node; wherein, the first transaction weight verification strategy The priority of the strategy is higher than that of the second transaction weight verification strategy.
  • the first source attribute can be used to characterize that the transaction to be processed is the transaction in the transaction addition request, and the transaction addition request is sent by the block chain client associated with the first node; optionally, the first source here
  • the attribute can also be used to represent the transaction to be processed as a transaction in the transaction synchronization request.
  • the transaction in the transaction addition request and the transaction in the transaction synchronization request can be collectively referred to as the transaction in the business request.
  • the specific process of the first node performing transaction weight verification on the transaction in the received service request can refer to the description of the specific process of transaction weight verification on transaction 1 in the embodiment corresponding to Figure 8 above, and will not continue here repeat.
  • the transaction weight verification strategy includes a third transaction weight verification strategy and a fourth transaction weight verification strategy associated with the transaction cache of the first node.
  • the priority of the third transaction weight verification strategy is higher than the priority of the second transaction weight verification strategy.
  • the first node may perform the following step S303 in advance based on the third transaction weight verification strategy;
  • the second source attribute is used to characterize that the transaction to be processed is a transaction in the target block broadcast by the second node in the blockchain network;
  • the target Each transaction in a block corresponds to a transaction identifier, and a transaction identifier is used to represent the packaging order of a transaction in the target block.
  • Step S303 if the transaction source attribute is the second source attribute, then based on the third transaction weight verification strategy, obtain the transaction identification of the key transaction in the target block.
  • the key transaction is the transaction with the largest packaging order among the N transactions included in the target block; N is a positive integer.
  • Step S304 comparing the transaction identification of the transaction to be processed with the transaction identification of the key transaction to obtain an initial comparison result.
  • Step S305 if the initial comparison result indicates that the transaction identifier of the transaction to be processed is different from the transaction identifier of the key transaction in the target block, then it is determined that there is a next transaction of the transaction to be processed.
  • step S306 the intra-block transaction weight check is performed on the pending transaction in the target block by the transaction checker, and the block transaction check result associated with the pending transaction is obtained.
  • the first node can obtain the bit array and K hash functions of the transaction checker when performing the first transaction check on the transaction to be processed through the transaction checker based on the above-mentioned third transaction check strategy, and will obtain
  • the bit array is used as the bit array to be queried corresponding to the transaction to be processed;
  • the M array elements of the bit array to be queried include the first array element;
  • K is a positive integer smaller than M;
  • M is the array length of the bit array to be queried.
  • the first node may map the transaction to be processed to K target identification positions of the bit array to be queried based on K hash functions, and among the M array elements, the array elements at the K target identification positions are regarded as K The transaction mapping value at the target identification position; further, the first node can determine the association relationship between the first array element and the transaction mapping value at the K target identification position, and obtain the first transaction verification for the transaction to be processed based on the association relationship. The rechecked first transaction weight check result can then be used as the block transaction weight check result associated with the transaction to be processed.
  • Step S307 if the block transaction weight verification result indicates that the transaction attribute of the transaction to be processed in the target block is a repeated transaction attribute, then based on the fourth transaction weight verification strategy, search the transaction cache of the first node for the transaction that matches the transaction to be processed transaction, if a transaction matching the transaction to be processed is found in the transaction cache, the target block broadcast by the second node is rejected.
  • the next transaction of the pending transaction can be determined as a new pending transaction to repeat the above steps S304-step S307, until the first node checks the transaction weight of the transaction with the largest packaging order in the target block (that is, the above-mentioned key transaction), and the weight check passes, at this time, it can be determined that each transaction in the target block transactions are non-repeating transactions.
  • Step S308 if the initial comparison result indicates that the transaction identification of the transaction to be processed is the same as the transaction identification of the key transaction in the target block, and it is determined that there is no next transaction of the transaction to be processed in the target block, then determine the Each transaction is a unique transaction.
  • the first node can compare the latest transaction ID of the transaction to be processed with the transaction ID of the key transaction in the target block to obtain the latest initial comparison result.
  • the result indicates that the transaction identification of the latest determined transaction to be processed is the same as the transaction identification of the key transaction in the target block, and it is determined that there is no next transaction of the pending transaction in the target block, then each The transactions are all non-repetitive transactions, and then the following step 309 can be continued.
  • Step S309 obtain the transaction hash value of each transaction in the target block through the transaction checker, and update the bit group in the transaction checker based on the transaction hash value of each transaction; the transaction hash value of each transaction The value is determined by K hash functions in the transaction checker.
  • FIG. 10 is an embodiment of a scenario of performing transaction weight verification on transactions in a block provided by an embodiment of the present application.
  • the first node shown in FIG. 10 may receive the target block broadcast by the second node, and the target block may be block X shown in FIG. 10 .
  • the block X may include N transactions, and the N transactions here may specifically be transaction 11 , transaction 12 , transaction 13 , . . . , transaction 1n shown in FIG. 10 .
  • each transaction in the target block corresponds to a transaction identifier, and a transaction identifier is used to represent a packing order of a transaction in the target block.
  • N is a positive integer.
  • step S901 can be performed to traverse the transactions in the target block as transactions to be processed according to the transaction packaging order of each transaction in the target block , for ease of understanding, the embodiment of this application regards the transaction 11 shown in Figure 10 (that is, has the smallest packaging order) as the transaction to be processed.
  • the first A node can determine that the transaction source attribute of the transaction 11 is the above-mentioned second source attribute, and then can be based on the third transaction weight verification strategy (that is, the transaction weight verification strategy used when the transaction 11 is verified by the transaction weight checker) , to obtain the transaction identification of the key transaction in the target block (that is, the transaction with the largest packaging order, for example, transaction 1n shown in Figure 10), and then step S902 shown in Figure 10 can be executed to determine the pending transaction Whether the transaction identification of (for example, transaction 11) is the same as the transaction identification of the key transaction (for example, transaction 1n). In other words, at this point, the first node can compare the transaction identifier of the transaction to be processed with the transaction identifier of the key transaction to obtain an initial comparison result.
  • the third transaction weight verification strategy that is, the transaction weight verification strategy used when the transaction 11 is verified by the transaction weight checker
  • the transaction identifier of the transaction to be processed (for example, transaction 11) is not the same as the transaction identifier of the key transaction (for example, transaction 1n) in the target block, then it is determined that there is The next transaction of the transaction to be processed can continue to execute step S904 shown in FIG. 10 , so that the transaction to be processed (for example, transaction 11) Check the transaction weight in the block to obtain the result of the block transaction weight check.
  • the first node uses a transaction weight checker (for example, a Bloom filter) to perform transaction weight check on the pending transaction 11.
  • a transaction weight checker for example, a Bloom filter
  • the first node can skip to step S907 shown in Figure 10 to refuse to receive the target block piece.
  • the first node may further execute the map based on the fourth transaction weight verification strategy associated with the second source attribute Step S905 shown in 10 is to determine whether the transaction to be processed (for example, transaction 11) already exists in the transaction cache.
  • the first node may search in the transaction cache whether there is a transaction hash value of the fourth historical transaction that matches the transaction hash value of the transaction to be processed (for example, transaction 11).
  • the fourth historical transaction here may be the historical transaction in the historical block to be uploaded obtained by the first node before receiving the target block.
  • These historical blocks can be temporarily stored in the transaction cache, so that when it is determined that these historical blocks belong to the longest chain, these historical blocks are written into the target blockchain corresponding to the blockchain database shown in FIG. 10 .
  • step S907 shown in FIG. 10 can be executed to refuse to receive the target block.
  • the first node does not find the transaction hash value of the fourth historical transaction that matches the transaction hash value of the transaction to be processed (for example, transaction 11) in the transaction cache, it continues to execute based on the fourth transaction weight verification strategy Step S906 shown in FIG.
  • the first node may search the block chain database whether there is a transaction hash value of the fifth historical transaction that matches the transaction hash value of the transaction to be processed (for example, transaction 11).
  • the fifth historical transaction here may be a historical transaction in a chained historical block.
  • the first node finds in the blockchain database that there is a transaction hash value of the fifth historical transaction that matches the transaction hash value of the transaction to be processed (for example, transaction 11), , it is determined that the transaction to be processed (for example, transaction 11) already exists in the block chain database, and then the step S907 shown in FIG. 10 can be skipped to refuse to receive the target block.
  • step S908 shown in Figure 10 can be continued to be executed to obtain the next block of the transaction to be processed from the target block (for example, block X shown in Figure 10 ).
  • a transaction for example, transaction 12 shown in FIG. 10 , to repeatedly execute steps S901-step S908 shown in FIG.
  • step S909 shown in FIG. 10 may be executed to determine that each transaction in the target block is a non-repeating transaction.
  • the first node when executing step S910, can obtain the transaction hash value of each transaction in the target block through the transaction checker, and then execute step S911 shown in Figure 10, that is, the first node can Update the bit array in the transaction validator based on the transaction hash value of each transaction.
  • the first node determines that the transaction to be processed (for example, transaction 11) already exists in the transaction cache, it can determine that the target block already exists in the transaction cache of the first node. For example, when the first node is down or the network is delayed (that is, the first node does not report the block reception message to the second node within the response time), the second node will repeatedly send the target block.
  • the target block can be checked in the above way, and the existing The target block refuses to receive it, so as to avoid wasting the storage space of the node memory.
  • the transaction weight checker in the memory of the node can quickly determine whether the transaction in the currently acquired target block is a duplicate transaction, and then it can be used in the target block In the case that all transactions in the target block are non-repeating transactions, the target block is received so that each transaction in the target block can continue to be executed subsequently, and the transaction execution result of each transaction in the target block is temporarily stored in the second A node's transaction cache.
  • the embodiment of the present application can directly judge whether the transaction to be processed exists in the node of the first node directly through the association relationship between the first array element in the transaction checker and the transaction mapping value at K target identification positions In the transaction weight checker deployed in the memory, the efficiency of transaction weight check can be improved.
  • the transaction weight verification strategy for the transaction weight verification of the pending transaction is switched to the fourth transaction weight verification strategy associated with the blockchain network, and then the second transaction can be performed on pending transactions suspected of repeated transactions through the fourth transaction weight verification strategy Check the weight to get the weight check result of the second transaction.
  • the second transaction weight checking refers to further checking whether there is a historical transaction that matches the suspected duplicate transaction in the transaction cache associated with the blockchain network and the blockchain database, and if so, determine The suspected duplicate transaction is indeed a duplicate transaction, and then the target block can be rejected to reduce the storage cost of the node memory. On the contrary, if it does not exist, it can be determined that the suspected repeated transaction is a non-repeated transaction, thereby improving the reliability of transaction weight verification.
  • FIG. 11 is a schematic structural diagram of a transaction weighing device provided by the present application.
  • the transaction weight verification device 1 can be a computer program (including program code) running in a computer device, for example, the transaction weight verification device 1 is an application software; the transaction weight verification device 1 can be used to implement the corresponding steps in the method.
  • the transaction weight verification device 1 can be applied to the above-mentioned first node, and the first node can be any block chain node in the above-mentioned consensus network, for example, the transaction weight verification device 1 can be applied to the above-mentioned Fig. Corresponds to the node 10c in the embodiment.
  • the transaction weight verification device 1 may include: a transaction acquisition module 100, a first weight verification module 200, a mapping value determination module 300 and a first result determination module 400; further, the transaction weight verification device 1 may also include : first relationship determination module 500, first target determination module 600, first target preservation module 700, second relationship determination module 800, second weighing module 900, transaction rejection module 101, second target determination module 102, target mapping Value determination module 103, element update module 104, transaction identification acquisition module 105, transaction identification comparison module 106, identification difference determination module 107, block weight verification result determination module 108, transaction cache search module 109, identification identical determination module 110 and Ha Greek value acquisition module 111;
  • a transaction acquisition module 100 configured to acquire pending transactions to be chained to the blockchain network
  • the transaction acquisition module 500 is also used to determine the transaction source attribute of the transaction to be processed; the transaction source attribute is used to indicate the transaction The transaction weight verification strategy used by the weight checker to check the transaction weight of the transaction to be processed.
  • the first weight checking module 200 is used to obtain the bit group and K hash functions of the transaction weight checking device when performing the first transaction weight checking on the transaction to be processed through the transaction weight checking device, and use the obtained bit group as the pending transaction
  • the bit array to be queried corresponding to the transaction; the bit array to be queried includes M array elements, and the M array elements include the first array element; M is an integer greater than 1, and K is a positive integer smaller than M;
  • the transaction weight verification strategy includes the first transaction weight verification strategy associated with the transaction pool of the first node; the first source attribute is used to indicate that the transaction to be processed is a transaction adding request The transaction; the transaction addition request is sent by the blockchain client associated with the first node;
  • the first weight verification module 200 includes: a first transaction weight verification unit 2001, a first element determination unit 2002, and a query array determination unit 2003;
  • the first transaction weight checking unit 2001 is configured to obtain a bit array with an array length of M from the transaction weight checker when performing the first transaction weight check on the transaction to be processed based on the first transaction weight checking strategy through the transaction weight checker, and Obtain the K hash functions associated with the bit array with an array length of M; in the bit array with an array length of M, the K key identification positions mapped to the weight check elements in the weight check set of the transaction weight checker
  • the elements of the array are all the elements of the second array;
  • a key identification position is the identification position obtained after the weight checking element is mapped to the hash position through a hash function;
  • the first element determining unit 2002 is configured to use, in the bit array with an array length of M, the array elements other than the second array element among the M array elements as the first array element; the identification positions corresponding to the first array elements are different At the identification position corresponding to the second array element, and the sum of the number of elements in the first array element and the number of elements in the second array element is M;
  • the query array determining unit 2003 is configured to use the bit array formed by the first array element and the second array element as the bit array to be queried corresponding to the transaction to be processed.
  • the specific implementation of the first transaction weight verification unit 2001, the first element determination unit 2002, and the query array determination unit 2003 can refer to the description of step S102 in the embodiment corresponding to FIG. 3 above, and will not be repeated here.
  • the mapping value determination module 300 is configured to map the transaction to be processed to K target identification positions of the bit array to be queried based on K hash functions; among the M array elements, the array elements at the K target identification positions are used as Transaction mapping values at K target identification positions;
  • the first result determination module 400 is configured to determine the association relationship between the first array elements and the transaction mapping values at the K target identification positions, and obtain the first transaction verification for the first transaction weight verification of the transaction to be processed based on the association relation. Focus on results.
  • the association relationship includes a first association relationship, and the first association relationship is used to indicate that there is a transaction mapping value that is the same as the first array element among the transaction mapping values at K target identification positions;
  • the first relationship determination module 500 is configured to determine that the transaction to be processed does not belong to the weight verification element in the weight verification set of the transaction weight verification device if the first transaction weight verification result indicates that the association relationship is the first association relationship, and control the transaction verification
  • the transaction attribute of the pending transaction output by the heavy device is a non-repeatable transaction attribute
  • the first target determining module 600 is configured to determine a transaction to be processed with a non-repetitive transaction attribute as a first target transaction to be saved in the transaction pool of the first node.
  • the first target saving module 700 is configured to, when saving the first target transaction to the transaction pool of the first node, use the same transaction mapping value as the first array element at the K target identification position as the first A target transaction mapping value, and in the bit array to be queried, the array element at the target identification position corresponding to the first target transaction mapping value is updated from the first array element to the second array element.
  • the association relationship includes a second association relationship, and the second association relationship is used to indicate that there is no transaction mapping value identical to the first array element among the transaction mapping values at the K target identification positions;
  • the second relationship determination module 800 is configured to obtain a second transaction weight verification strategy associated with the transaction pool of the first node if the first transaction weight verification result indicates that the association relationship is the second association relationship;
  • the second weight verification module 900 is configured to perform a second transaction weight verification on the transaction to be processed based on the second transaction weight verification strategy, and obtain a second transaction weight verification result.
  • the second weight verification module 900 includes: a transaction pool search unit 901, a first repetition determination unit 902, and a second result determination unit 903; optionally, the second weight verification module 900 also includes:
  • a transaction pool search unit 901 configured to search the transaction pool of the first node for a first historical transaction that matches the transaction to be processed based on the second transaction weight verification strategy;
  • the first repetition determining unit 902 is configured to determine that the transaction attribute of the transaction to be processed is a repeated transaction attribute if the first historical transaction matching the transaction to be processed is found in the transaction pool of the first node, and will have the repeated transaction attribute
  • the pending transactions of are regarded as the first type of repeated transactions associated with the second transaction weight verification strategy
  • the second result determination unit 903 is configured to use the first type of repeated transactions as the second transaction weight verification result after the second transaction weight verification is performed on the transaction to be processed.
  • the first transition result determining unit 904 is configured to determine the transaction attribute of the transaction to be processed if no first historical transaction matching the transaction to be processed is found in the transaction pool of the first node as The first non-repeated transaction attribute, using the pending transaction with the first non-repeated transaction attribute as the first transitional weight verification result associated with the second transaction weight verification strategy;
  • the transaction cache lookup unit 905 is configured to use the pending transaction with the first non-repeated transaction attribute as the first transition transaction based on the result of the first transition weight check, and search the transaction cache of the first node to match the first transition transaction The second historical transaction of ;
  • the second repetition determination unit 906 is configured to determine that the transaction attribute of the first transition transaction is a repeated transaction attribute if the second historical transaction matching the first transition transaction is found in the transaction cache of the first node, and will have the repetition
  • the first transitional transaction of the transaction attribute is used as the second type of repeated transaction associated with the second transaction weight verification strategy;
  • the second result determination unit 907 is configured to use the second type of repeated transactions as the second transaction weight verification result after the second transaction weight verification is performed on the transaction to be processed.
  • the second transition result determining unit 908 is configured to determine the transaction attribute of the first transition transaction if no second historical transaction matching the first transition transaction is found in the transaction cache of the first node For the second non-repetitive transaction attribute, the first transitional transaction with the second non-repetitive transaction attribute is used as the second transitional weight verification result associated with the second transaction weight verification strategy;
  • the database search unit 909 is configured to use the first transitional transaction with the second non-repeated transaction attribute as the second transitional transaction based on the second transitional weight checking result, and search for the first transitional transaction in the blockchain database associated with the first node.
  • the third repetition determining unit 910 is used to determine that the transaction attribute of the second transition transaction is a repeated transaction attribute if the third historical transaction matching the second transition transaction is found in the block chain database, and will have the repeat transaction attribute
  • the second transitional transaction is the third type of repeated transaction associated with the second transaction weight verification strategy
  • the second result determination unit 903 is further configured to use the third type of repeated transactions as the second transaction weight verification result after the second transaction weight verification is performed on the transaction to be processed.
  • the database search unit 909, and the third repetition determination unit 910 please refer to the description of the second transaction weight verification strategy in the embodiment corresponding to Figure 6 above, and will not continue here repeat.
  • the transaction rejection module 101 is configured to determine that the transaction to be processed is a duplicate transaction and refuse to add the duplicate transaction to the first node if the second transaction weight verification result indicates that the transaction attribute of the transaction to be processed is a duplicate transaction attribute transaction pool.
  • the second target determination module 102 is configured to, if the second transaction weight verification result indicates that the transaction attribute of the transaction to be processed is a non-repeated transaction attribute, then based on the pending transaction with the non-repeated transaction attribute, determine the second target transaction in the transaction pool of the first node, and save the second target transaction in the transaction pool of the first node;
  • a target mapping value determination module 103 configured to use the transaction mapping values at the K target identification positions as the second target transaction mapping value when inserting the second target transaction into the weight verification set of the transaction weight checker;
  • the element update module 104 is used to control the transaction weight checker to update the array element at the target identification position corresponding to the second target transaction mapping value in the to-be-queried bit array to the second array element, and use the updated to-be-queried bit array as the target bit array.
  • the transaction weight verification strategy includes a third transaction weight verification strategy and a fourth transaction weight verification strategy associated with the transaction cache of the first node;
  • the second source attribute It is used to represent transactions in the target block broadcast by the second node in the blockchain network; each transaction in the target block corresponds to a transaction ID, and a transaction ID is used to represent a transaction in the target area Packing order within a block;
  • the transaction identification acquisition module 105 is used to obtain the transaction identification of the key transaction in the target block based on the third transaction weight verification strategy; the key transaction is the transaction with the largest packaging order among the N transactions included in the target block; N is positive integer;
  • the transaction identification comparison module 106 is used to compare the transaction identification of the transaction to be processed with the transaction identification of the key transaction to obtain an initial comparison result;
  • the identification difference determination module 107 is used to determine that there is a next transaction of the transaction to be processed if the initial comparison result indicates that the transaction identification of the transaction to be processed is different from the transaction identification of the key transaction in the target block;
  • the block weight checking result determining module 108 is used to carry out transaction weight checking in the block to the transaction to be processed in the target block through the transaction weight checking device, and obtain the block transaction weight checking result associated with the transaction to be processed;
  • the transaction cache lookup module 109 is configured to search the transaction cache of the first node based on the fourth transaction weight check strategy to match the pending Processing the transaction matching the transaction, if finding a transaction matching the transaction to be processed in the transaction cache, rejecting the target block broadcast by the second node.
  • the ID identical determination module 110 is configured to determine that the transaction ID of the transaction to be processed is the same as that of the key transaction in the target block if the initial comparison result indicates that the next transaction, it is determined that each transaction in the target block is a non-repeating transaction;
  • the hash value acquisition module 111 is used to obtain the transaction hash value of each transaction in the target block through the transaction checker, and update the bit group in the transaction checker based on the transaction hash value of each transaction; each The transaction hash value of the transaction is determined by K hash functions in the transaction checker.
  • the first relationship determining module 500, the first target determining module 600, the first target saving module 700, the second relationship determining module 800, the second weighing module 900, the transaction rejection module 101, and the second target determining module 102 , the target mapping value determining module 103, and the element updating module 104 can refer to the description of steps S201-step S216 in the above-mentioned embodiment corresponding to FIG. 6 , and details will not be repeated here.
  • the transaction identification acquisition module 105 the transaction identification comparison module 106, the identification difference determination module 107, the block weight verification result determination module 108, the transaction cache search module 109, the same identification determination module 110 and the hash value acquisition module 111
  • FIG. 12 is a schematic structural diagram of a computer device provided by an embodiment of the present application.
  • the computer device 1000 can be applied to the block chain node in the corresponding embodiment of Figure 1 above, and the computer device 1000 can include: a processor 1001, a network interface 1004 and a memory 1005, in addition, the computer device 1000 can also include : user interface 1003, and at least one communication bus 1002.
  • the communication bus 1002 is used to realize connection and communication between these components.
  • the user interface 1003 may include a display screen (Display) and a keyboard (Keyboard), and the optional user interface 1003 may also include a standard wired interface and a wireless interface.
  • the network interface 1004 may include a standard wired interface and a wireless interface (such as a WI-FI interface).
  • the memory 1005 can be a high-speed RAM memory, or a non-volatile memory, such as at least one disk memory.
  • the memory 1005 may also be at least one storage device located away from the aforementioned processor 1001 .
  • the memory 1005 as a computer storage medium may include an operating system, a network communication module, a user interface module, and a device control application program.
  • the network interface 1004 in the computer device 1000 can also provide a network communication function, and the optional user interface 1003 can also include a display screen (Display) and a keyboard (Keyboard).
  • the network interface 1004 can provide a network communication function; the user interface 1003 is mainly used to provide an input interface for the user; and the processor 1001 can be used to call the device control application stored in the memory 1005
  • the program is to execute the description of the transaction weight verification method in the embodiment corresponding to Figure 3 or Figure 6 or Figure 9 above, and also execute the description of the transaction weight verification device 1 in the embodiment corresponding to Figure 11 above, which will not be repeated here repeat. In addition, the description of the beneficial effect of adopting the same method will not be repeated here.
  • the embodiment of the present application also provides a computer storage medium, and the computer storage medium stores the computer program executed by the aforementioned transaction weight verification device 1, and the computer program includes program instructions,
  • the processor executes the program instructions, it can execute the description of the transaction weight verification method in the embodiment corresponding to FIG. 3 , FIG. 6 or FIG. 9 above, so details will not be repeated here.
  • the description of the beneficial effect of adopting the same method will not be repeated here.
  • the storage medium may be a magnetic disk, an optical disk, a read-only memory (Read-Only Memory, ROM) or a random access memory (Random Access Memory, RAM), etc.

Landscapes

  • Business, Economics & Management (AREA)
  • Engineering & Computer Science (AREA)
  • Accounting & Taxation (AREA)
  • Finance (AREA)
  • Theoretical Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Physics & Mathematics (AREA)
  • Strategic Management (AREA)
  • General Business, Economics & Management (AREA)
  • Computer Security & Cryptography (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Development Economics (AREA)
  • Marketing (AREA)
  • Technology Law (AREA)
  • Economics (AREA)
  • Financial Or Insurance-Related Operations Such As Payment And Settlement (AREA)
  • Information Retrieval, Db Structures And Fs Structures Therefor (AREA)

Abstract

本申请公开了一种交易验重方法、装置、设备以及介质，方法包括：获取待上链至区块链网络的待处理交易；在通过交易验重器对待处理交易进行第一交易验重时，获取交易验重器的位数组和K个哈希函数，将获取到的位数组作为待处理交易对应的待查询位数组；待查询位数组中包括M个数组元素，M个数组元素中包括第一数组元素；M为大于1的整数，K为小于M的正整数；基于K个哈希函数将待处理交易映射至待查询位数组的K个目标标识位置，确定K个目标标识位置上的交易映射值；确定第一数组元素与K个目标标识位置上的交易映射值之间的关联关系，基于关联关系得到待处理交易的第一交易验重结果。本申请通过引入交易验重器，可以提升交易验重的效率。

Description

一种交易验重方法、装置、设备以及介质
本申请要求于2021年05月14日提交中国专利局、申请号为2021105262053、申请名称为“一种交易验重方法、装置、设备以及介质”的中国专利申请的优先权，其全部内容通过引用结合在本申请中。
技术领域
本申请涉及计算机技术领域，尤其涉及交易验重技术。
背景技术
目前，对于区块链系统中的区块链节点而言，由于区块链节点的节点内存有限，因此，位于该节点内存中的交易缓存所能缓存的交易数量也有限。基于此，区块链系统中的区块链节点将交易缓存中的交易成功写入区块链后，往往会在节点内存的交易缓存中清除已成功上链的交易，以避免已成功上链的交易继续占用节点内存。
基于此，区块链系统中的区块链节点(例如，节点A)在收到交易(例如，交易T)后，需要对这个交易T进行交易验重，即在该节点A的交易缓存和与该节点A相关联的区块链数据库中，查询这个交易T是否已经存在；这意味着，现有的交易验重方案，在基于交易缓存对任意一个交易进行交易验重时，若在交易缓存中未查找到这个交易，则需要进一步通过区块链网络请求访问区块链数据库，以在该区块链数据库中查询是否存在这个交易。由此可见，现有的交易验重方案会涉及区块链节点对区块链数据库的访问，当区块链节点接收到多个交易(例如，区块链客户端频繁发送的同一交易)时，就会涉及多次对于区块链数据库的访问；而频繁地访问区块链数据库，会影响该区块链数据库的查询性能，进而会降低在该区块链数据库中进行交易验重的速度，也即降低区块链节点进行交易验重的效率。
发明内容
本申请提供了一种交易验重方法、装置、设备以及介质，可以提升交易验重的效率。
本申请一方面提供了一种交易验重方法，方法由区块链网络中的第一节点执行，第一节点中部署有交易验重器，该方法包括：
获取待上链至区块链网络的待处理交易；
在通过交易验重器对待处理交易进行第一交易验重时，获取交易验重器的位数组和K个哈希函数，将获取到的位数组作为待处理交易对应的待查询位数组；待查询位数组中包括M个数组元素，M个数组元素中包括第一数组元素；M为大于1的整数，K为小于M的正整数；
基于K个哈希函数，将待处理交易映射至待查询位数组的K个目标标识 位置；在M个数组元素中，将K个目标标识位置上的数组元素作为K个目标标识位置上的交易映射值；
确定第一数组元素与K个目标标识位置上的交易映射值之间的关联关系，基于关联关系，得到对待处理交易进行第一交易验重的第一交易验重结果。
本申请一方面提供了一种交易验重装置，该装置包括：
交易获取模块，用于获取待上链至区块链网络的待处理交易；
第一验重模块，用于在通过交易验重器对待处理交易进行第一交易验重时，获取交易验重器的位数组和K个哈希函数，将获取到的位数组作为待处理交易对应的待查询位数组；待查询位数组中包括M个数组元素，M个数组元素中包括第一数组元素；M为大于1的整数，K为小于M的正整数；
映射值确定模块，用于基于K个哈希函数，将待处理交易映射至待查询位数组的K个目标标识位置；在M个数组元素中，将K个目标标识位置上的数组元素作为K个目标标识位置上的交易映射值；
第一结果确定模块，用于确定第一数组元素与K个目标标识位置上的交易映射值之间的关联关系，基于关联关系，得到对待处理交易进行第一交易验重的第一交易验重结果。
本申请实施例一方面提供了一种计算机设备，包括：处理器和存储器；
处理器与存储器相连，其中，存储器用于存储计算机程序，计算机程序被处理器执行时，使得该计算机设备执行本申请实施例提供的方法。
本申请实施例一方面提供了一种计算机可读存储介质，计算机可读存储介质存储有计算机程序，该计算机程序适于由处理器加载并执行，以使得具有该处理器的算计设备执行本申请实施例提供的方法。
本申请实施例一方面提供了一种计算机程序产品或计算机程序，该计算机程序产品或计算机程序包括计算机指令，该计算机指令存储在计算机可读存储介质中。计算机设备的处理器从计算机可读存储介质读取该计算机指令，处理器执行该计算机指令，使得该计算机设备执行本申请实施例提供的方法。
本申请实施例中的计算机设备(例如，区块链网络中的第一节点)部署有用于进行交易验重的交易验重器，这样，计算机设备获取到待处理交易时，可以预先通过该交易验重器对该待处理交易进行第一交易验重，此时，计算机设备可以获取该交易验重器的位数组和K个哈希函数，进而可以将获取到的位数组作为待处理交易对应的待查询位数组；需要注意的是，这里的待查询位数组的M个数组元素中包括第一数组元素；这里的K为小于M的正整数；M为待查询位数组的数组长度。进一步的，计算机设备可以基于这K个哈希函数，将待处理交易映射至待查询位数组的K个目标标识位置，并可以在M个数组元素中，将K个目标标识位置上的数组元素作为K个目标标识位置上的交易映射值。可以理解的是，一个哈希函数可以将该待处理交易映射为该待查询位数组中的一个点，该点所在的标识位置即为前述待查询位数 组的一个目标标识位置。进一步的，计算机设备可以确定第一数组元素与K个目标标识位置上的交易映射值之间的关联关系，进而可以基于关联关系得到对待处理交易进行第一交易验重后的第一交易验重结果。由此可见，本申请实施例在获取到待处理交易时，可以预先在第一节点的节点内存中通过交易验重器判断该待处理交易是否存在，并可以将判断出的结果作为待处理交易的第一交易验重结果。本申请实施例通过在该节点内存中使用交易验重器进行交易验重，可以直接通过待查询位数组中的第一数组元素与K个目标标识位置上的交易映射值之间的关联关系，快速判断该待处理交易是否存在，进而可以提升交易验重的效率。
附图说明
图1是本申请实施例提供的一种网络架构的示意图；
图2是本申请实施例提供的一种在节点内存中进行交易验重的场景示意图；
图3是本申请提供的一种交易验重方法的流程示意图；
图4是本申请实施例提供的一种确定待查询位数组的场景示意图；
图5是本申请实施例提供的一种通过交易验重器的哈希函数将待处理交易映射至待查询位数组的场景示意图；
图6是本申请实施例提供的一种交易验重方法的流程示意图；
图7是本申请实施例提供的一种更新待查询位数组的场景示意图；
图8是本申请实施例提供的一种业务请求中的交易进行交易验重的时序图；
图9是本申请实施例提供的一种交易验重方法的流程示意图；
图10是本申请实施例提供的一种对区块中的交易进行交易验重的场景实施例；
图11是本申请提供的一种交易验重装置的结构示意图；
图12是本申请实施例提供的一种计算机设备的结构示意图。
具体实施方式
下面将结合本申请中的附图，对本申请中的技术方案进行清楚、完整地描述，显然，所描述的实施例仅仅是本申请一部分实施例，而不是全部的实施例。基于本申请中的实施例，本领域普通技术人员在没有作出创造性劳动前提下所获得的所有其他实施例，都属于本申请保护的范围。
请参见图1，图1是本申请实施例提供的一种网络架构的示意图。图1所示的网络架构可以应用于区块链系统，该区块链系统可以是由多个节点通过网络通信的形式连接形成的分布式系统。该区块链系统可以包括但不限于联盟链对应的区块链系统。
区块链是一种分布式数据存储、点对点传输、共识机制以及加密算法等 计算机技术的新型应用模式，主要用于按时间顺序对数据进行整理，并加密成账本，使其不可被篡改和伪造，同时可支持数据验证、存储和更新等处理。区块链本质上是一个去中心化的数据库，该数据库中的每个节点均存储一条相同的区块链，区块链网络将节点区分为核心节点和轻节点，其中，核心节点可以负责区块链全网的共识，也就是说核心节点可以为区块链网络中的共识节点。应当理解，区块链网络中的任意一个节点(例如，轻节点)接收到客户端发送的交易数据(也可以简称为交易)后，可以将该交易以接力棒的方式在区块链网络中的轻节点之间传递，该区块链网络中用于进行打包的共识节点(即该区块链网络中的主核心节点)接收到该交易后，可以进一步将该交易添加到该主核心节点的交易池，以便后续该主核心节点将该交易和交易池中的其它交易一并打包进区块，进而将打包得到的区块(即目标区块)广播给该区块链网络中的其他共识节点(即该区块链网络中的从核心节点)，以使其他共识节点对该目标区块进行区块共识，在这些共识节点达成共识后，将该目标区块写入本地账本(比如，写入节点内存的交易缓存)，以便后续可以将该目标区块写入至该区块链网络中的目标区块链对应的区块链数据库(也可以简称为数据库)。这里的目标区块链可以理解为这些共识节点根据共识机制构建得到的最长链。
区块链系统中可以包括智能合约，该智能合约在区块链系统中可以理解为一种区块链各节点(包括共识节点)之间能够理解并执行的代码，可以执行任意逻辑并得到结果。用户可以通过区块链客户端，向区块链网络中的任意一个节点发起针对某个交易的交易添加请求，随后，区块链网络中的节点(例如，上述从核心节点或轻节点)可以将该交易添加请求中携带的交易发送至上述主核心节点，以使上述主核心节点在调用智能合约执行该用户请求的交易之前，预先判断当前接收到的这个交易是否已经存在于区块链网络。如果这个交易已存在于区块链网络，则可以拒绝接收该交易添加请求中的这个交易(即这个交易属于重复交易)。反之，如果这个交易未存在于区块链网络，则可以接收该交易添加请求中的这个交易(即这个交易属于非重复交易)。
比如，为避免某个核心节点接收到恶意节点频繁发送的交易，或者避免区块链客户端因为网络延迟没有收到核心节点针对交易的回复而重发的交易，本申请实施例中的核心节点在获取到用户请求的交易后，需要在该核心节点的节点内存中预先通过交易验重器对该交易进行第一交易验重，以判断是否拒绝接收该交易。换言之，核心节点可以在节点内存中通过交易验重器快速判断当前获取到的交易是否为重复交易。如果该交易验重器确定的交易验重结果(即第一交易验重结果)指示当前获取到的交易为重复交易，则可以拒绝接收交易添加请求中的该交易。反之，如果该交易验重器确定的交易验重结果指示当前获取到的交易不为重复交易，则可以进一步确定当前获取到的 交易需要进行第二交易验重，进而可以相继通过该节点内存的交易池、交易缓存以及区块链数据库等进行二次交易验重，以便于通过交易池、交易缓存以及区块链数据库等协同判断出当前获取到的交易是否已经存在于区块链网络中，如果已经存在于区块链网络中，则可以最终确定当前获取到的交易为重复交易，进而拒绝接收该重复交易。反之，若经过二次交易验重，最终确定当前获取到的交易为非重复交易时，则可以将该非重复交易添加到交易池中。
其中，应当理解，区块链系统中可以包括一个或多个智能合约，这些智能合约可以通过合约调用地址、合约标识号(Identity document，ID)或合约名称来进行区分，而区块链客户端发起的交易添加请求中，也可以携带智能合约的合约调用地址或者合约标识号或合约名称，以指定需要运行的智能合约。若区块链客户端指定的智能合约为需要读取数据的合约(即数据读取合约)，则各个共识节点可以在完成上述交易验重之后，进一步执行交易时，调用数据读取合约快速访问本地账本(例如，各个共识节点可以快速访问到节点内存中通过块链结构构建的多级块缓存，其中，多级块缓存是按照各个共识节点的节点内存中缓存的各个区块的区块哈希值的索引方式，对每个区块的块缓存进行排列得到的；一个块缓存可以用于存储一个区块中每个交易的交易读缓存和交易写缓存)，进行相应数据的读取，最后各个共识节点会互相验证针对该交易的各交易执行结果是否一致(也就是进行共识)，若一致则可以确定该交易为合法交易，进而可以将该合法交易的交易执行结果存入各自的本地账本的交易写缓存中，并可以将上述交易的交易执行结果返回至区块链客户端。
应当理解，图1所示的网络架构可以包括核心节点(即共识节点)集群、轻节点集群以及用户终端集群。其中，该核心节点集群可以包括一个或者多个核心节点，这里的多个核心节点具体可以包括图1所示的节点10a、节点10b、节点10c、节点10d。如图1所示，节点10a、节点10b、节点10d可以分别与节点10c进行网络连接，以构成图1所示的共识网络100a。在该共识网络100a中，节点10a、节点10b、节点10d能够通过与该节点10c之间的网络连接进行数据交互。此外，该轻节点集群可以包括一个或者多个轻节点，为便于理解，这里以一个轻节点为例，该轻节点为图1所示的节点4000a，该节点4000a可以通过与图1所示的节点10c之间的网络连接进行数据交互。另外，图1所示的用户终端集群可以包括一个或者多个用户终端，这里的多个用户终端具体可以包括图1所示的用户终端3000a、用户终端3000b、用户终端3000c、...、用户终端3000n。如图1所示，用户终端3000a、用户终端3000b、用户终端3000c、...、用户终端3000n可以分别与该轻节点集群中的节点4000a进行网络连接，以便于通过与该节点4000a之间的网络连接进行数据交互。
本申请实施例可以将共识网络100a中的每个核心节点(例如，节点10a、节点10b、节点10c、节点10d)和轻节点集群中的每个轻节点统称为区块链节点，这里的区块链节点均可以接收运行有区块链客户端的用户终端发送的交易添加请求。应当理解，这里的每个核心节点可以维护同一区块链(比如，图1所示的区块链10e可以为上述区块链网络中各个核心节点维护的目标区块链)，该共识网络100a中的任意两个核心节点之间可以形成点对点(P2P，Peer To Peer)网络，该点对点网络可以采用P2P协议，该P2P协议是一个运行在传输控制协议(TCP，Transmission Control Protocol)协议之上的应用层协议。在分布式系统中，任何设备如服务器、终端等都可以加入成为区块链节点，其中，每个区块链节点均可以包括硬件层、中间层、操作系统层和应用层。
本申请实施例可以为接入该区块链网络的任意一个角色(例如，任意一个个人用户、任意一个企业、任意一个机构等实体对象)绑定一个区块链节点，将这些区块链节点构成的区块链网络统称为联盟链网络。所以，图1所示的节点10a、节点10b、节点10c、节点10d可以与接入区块链网络中的相应角色(即相应业务场景下的实体对象)之间存在一一对应关系。这里的业务场景可以包括电子票据场景、社交场景、赊购场景、信贷场景等。此时，相应业务场景下的目标业务具体可以包括电子票据业务、社交业务、赊购业务、信贷业务等，这里不对相应业务场景下的具体业务进行一一列举。
由于每个实体对象均可以对应一个区块链节点，所以，本申请实施例可以以实体对象为上述企业用户(即前述企业)为例，此时，与每个企业用户相关联的区块链节点可以为同一区块链节点(例如，上述图1所示的节点4000a可以与多个企业用户各自对应的用户终端进行数据交互)。比如，在区块链电子票据系统中，可以将每个开票企业对应的电子票据业务(比如，注册业务、开票业务、票据转移业务等)统称为一笔交易业务。其中，开票企业A可以通过图1所示的用户终端3000a与图1所示的节点4000a进行数据交互，以完成相应的交易；以此类推，开票企业B可以通过图1所示的用户终端3000b与图1所示的节点4000a进行数据交互，以完成相应的交易；开票企业C可以通过图1所示的用户终端3000c与图1所示的节点4000a进行数据交互，以完成相应的交易。
本申请实施例可以将上述电子票据业务中发送交易添加请求的实体对象(例如，开票企业A、开票企业B、...、开票企业C)统称为请求用户。应当理解，本申请实施例可以通过上述轻节点接收请求用户(例如，开票企业A、开票企业B、...、开票企业C)发送的交易添加请求，还可以通过上述核心节点接收请求用户(例如，开票企业A、开票企业B、...、开票企业C)发送的交易添加请求，这里不对接收交易添加请求的区块链节点的节点类型进行限定。
可选的，在共识网络100a中，由于上述节点10c可以与其存在网络连接(也可以称之为会话连接)的其他区块链节点之间进行数据同步，即上述节点10c可以从其他区块链节点上同步相应的业务数据信息(例如，这里的业务数据信息可以包括但不限于上述交易添加请求中的交易和区块同步请求中的区块等)，此时，与每个企业用户相关联的核心节点可以为不同的区块链节点。比如，开票企业A也可以通过图1所示的用户终端3000a与图1所示的节点10c进行数据交互；开票企业B也可以通过图1所示的用户终端3000b与图1所示的节点10b进行数据交互；开票企业C也可以通过图1所示的用户终端3000c与图1所示的节点4000a进行数据交互。应当理解，通过将不同用户终端发送的交易添加请求随机分配给上述区块链系统中的区块链节点，可以有效地均衡区块链网络中的网络负载，从而可以提高相应业务对应的业务数据的处理效率。
可以理解的是，当轻节点接收到区块链客户端对应的请求用户发送的交易添加请求时，可以将该请求用户发送的交易添加请求转发给上述主核心节点，以通过上述主核心节点对该请求用户发送的交易添加请求中的交易进行交易验重。主核心节点可以在交易验重通过后，将该请求用户请求的交易(即具备合法性的非重复交易)添加至交易池，以便后续将与该交易相关联的交易数据打包成区块，与其他共识节点(即上述从核心节点)进行共识，并在共识通过后，将携带该交易的交易数据的区块暂存至上述本地账本，进而将携带该交易数据的区块写入至上述区块链数据库(也可以简称为数据库)。
为便于理解，进一步的，请参见图2，图2是本申请实施例提供的一种在节点内存中进行交易验重的场景示意图。其中，图2所示的用户A(即上述请求用户)可以通过图2所示的用户终端20a执行步骤S1，以将该用户A请求执行的交易T1(例如，该交易T1可以为用户A向企业B开具电子发票这一发票开具业务)发送给图2所示的节点20c。节点20c可以在接收到用户终端20a发送来的交易T1后，执行步骤S2，以对该交易T1进行交易验重。其中，本申请实施例可以将当前接收到该交易T1的区块链节点(例如，图2所示的节点20c)统称为第一节点，并将该区块链网络中的其他节点(例如，图2所示的节点20b、节点20d和节点20e等)统称为第二节点。如图2所示，该节点20c(即第一节点)可以接收运行有区块链客户端的用户终端20a发送的交易添加请求中的交易T1，还可以接收该区块链网络中的其他节点(即第二节点)广播的目标区块中的交易，该节点20c无论是接收到来自交易添加请求中的交易，还是接收到其他节点广播的目标区块中的交易，均可以执行图2所示的步骤S2，以对当前接收到的交易进行交易验重，判断当前接收到的交易是否存在于区块链网络中。
其中，图2所示的交易验重器包括一个超大的位数组和K个哈希函数；该超大的位数组的数组长度可以为M，其中，K可以为小于M的正整数。在 本申请实施例中，节点20c获取到上述交易T1后，可以通过该交易验重器对交易T1进行交易验重，以得到第一交易验重结果。
图2所示的位数组201a可以包含M个数组元素，这M个数组元素可以用一个很长的二进制向量表示，这里的二进制向量可以为图2所示的数组长度为M(例如，M＝16)的向量(即0101110000101001)。如图2所示，该位数组201a的M个数组元素中，可以存在数值为0的数组元素，还可以存在数值为1的数组元素。为便于理解，本申请实施例可以将数值为0的数组元素统称为位数组的第一数组元素，并可以将数值为1的数组元素统称为位数组的第二数组元素。如图2所示，每个数组元素对应一个标识位置，例如，这些数组元素的标识位置可以分别为图2所示的标识位置2a～标识位置2p。其中，标识位置2a对应的数组元素为0，标识位置2b对应的数组元素为1。以此类推，标识位置2o对应的数组元素为0，标识位置2p对应的数组元素为1。应当理解，这里的M的取值可以根据该区块链系统中的实际需要进行调整，即本申请实施例不对M的取值进行限定。
为便于理解，本申请实施例以该交易验重器的K个哈希函数为3个哈希函数为例，这3个哈希函数具体可以为图2所示的哈希函数202a、哈希函数202b和哈希函数202c。如图2所示，哈希函数202a可以用于将图2所示的交易T1的哈希值(例如，哈希值1)进行哈希计算(例如，哈希位置映射)，以将该交易T1映射为位数组201a中的一个点(例如，点1，该点1可以为一个bit位)，该点1对应的目标标识位置可以为标识位置2e，标识位置2e上的数组元素为上述第二数组元素。同理，如图2所示，哈希函数202b可以用于将图2所示的交易T1的哈希值(例如，哈希值1)进行哈希计算(例如，哈希位置映射)，以将该交易T1映射为位数组201a中的另一个点(例如，点2，该点2可以为另一个bit位)，该点2对应的目标标识位置可以为标识位置2m，标识位置2m上的数组元素为上述第二数组元素。同理，如图2所示，哈希函数202c可以用于将图2所示的交易T1的哈希值(例如，哈希值1)进行哈希计算(例如，哈希位置映射)，以将该交易T1映射为位数组201a中的又一个点(例如，点3，该点3可以为一个bit位)，该点3对应的目标标识位置可以为标识位置2o，标识位置2o上的数组元素为上述第一数组元素。应当理解，这里通过K个哈希函数对交易T1的哈希值进行哈希计算(例如，哈希位置映射)的具体实现方式，可以包括但不限于对交易T1的哈希值进行求余运算，进而根据求得的余数与位数组201a中的标识位置之间的一一映射关系，将该交易T1映射在位数组201a中的目标标识位置。
由此可见，本申请实施例的节点20c获取到上述交易T1后，可以对该交易T1的交易数据(也可以称之为交易内容)进行哈希计算，以得到用于唯一标识该交易T1的交易哈希值(例如，上述哈希值1)。进一步的，该节点20c可以将该交易T1的交易哈希值(例如，上述哈希值1)作为图2所示的交易 验重器(该交易验重器部署在节点20c的节点内存中)的输入值，以使该交易验重器可以通过K个哈希函数(例如，哈希函数202a、哈希函数202b和哈希函数202c)分别对该输入值再次进行哈希计算(例如，上述哈希求余运算)，以得到上述与该交易T1相关联的K个bit位(即上述标识位置2e、标识位置2m以及标识位置2o)。应当理解，本申请实施例可以将这K个bit位(即K个目标标识位置)上的数组元素统称为交易映射值。
这里的交易验重器可以理解为一种具有交易验重功能的过滤器(例如，该交易验重器可以包括但不限于布隆过滤器)。该交易验重器可以从根源上解决恶意节点频繁发送的重复交易，进而避免这些重复交易浪费该节点20c的节点内存的有限资源空间。注意，这里的交易验重器可以用于维护一个验重集合，但是并不会存储该验重集合中已插入过的验重元素本身(即当节点20c需要将某个交易作为验重元素插入上述交易验重器的验重集合时，会将该验重元素对应的K个标识位置上的数组元素均设置为1，以得到上述图2所示的位数组201a)，这对于对某些具有一定私密性的交易而言，可以确保较高的安全性。
该交易验重器中的K个哈希函数之间是相互独立的，这样，上述节点20c获取到上述交易T1后，可以直接通过该节点20c的硬件并行执行这K个哈希函数，以通过这K个哈希函数将图2所示的交易T1映射到位数组201a的K个目标标识位置上，进而可以根据该交易验重器中的第一数组元素与这K个目标标识位置上的映射值之间的关联关系，得到上述第一交易验重结果。由此可见，通过图2所示的交易验重器，可以在节点内存中快速对当前获取到的重复交易进行过滤，这样，不仅可以节省节点内存有限的资源空间，还可以在一定程度上减少对该区块链网络中的区块链数据库的查询压力。如图2所示，该交易T1在3个目标标识位置上的交易映射值中存在与第一数组元素相同的交易映射值，因此可以直接确定该交易T1不在上述验重集合中，即可以直接确定该交易T1为非重复交易，进而可以直接在节点内存中将该交易T1添加到图2的交易池200a进行存储，而无需访问图2的区块链数据库，可以提升交易验重的速度。
若这K个交易映射值中有一个或者多个交易映射值与上述第一数组元素相同，则可以得到第一数组元素与这K个目标标识位置上的交易映射值之间的第一关联关系，该第一关联关系用于反映交易T1一定不存在于该交易验重器的验重集合中，进而可以直接将该交易T1视为非重复交易，从而可以接收图2所示的用户终端20a发送来的交易T1，并将该交易T1添加到交易池200a。应当理解，节点20c将交易T1添加到交易池200a后，该节点20c还可以将该交易T1作为验重元素插入上述交易验重器，即此时，该节点20c会在图2所示的位数组201a(即该交易T1对应的待查询位数组)中，将该验重元素对应的K个目标标识位置上的数组元素(即标识位置2e上的数组元素、标识 位置2m上的数组元素以及标识位置2o上的数组元素)均变更为1，以得到新的位数组，该新的位数组可以作为下一笔交易的待查询位数组。
可选的，对于其他用户终端发送的另一交易(例如，交易T2而言)，仍可以通过图2所示的交易验重器对该交易T2进行交易验重，即可以判断第一数组元素与该交易T2的K个交易映射值之间的关联关系。同理，若该关联关系为上述第一关联关系，也可以将该交易T2添加到交易池200a，并将该交易T2对应的K个目标标识位置上的数组元素均变更为1，即将交易T2对应的K个目标标识位置上的数组元素均设置为第二数组元素，以实现将该交易T2作为验重元素插入交易验重器的验重集合。
反之，若K个交易映射值中的每个交易映射值均与上述第一数组元素不相同，则可以得到第一数组元素与这K个目标标识位置上的交易映射值之间的第二关联关系，该第二关联关系用于反映其他用户终端发送的另一交易(例如，交易T2)可能存在于该交易验重器的验重集合中，即该交易T2有可能是重复交易。之所以在该种情况下无法准确地确定交易T2是否为重复交易，是因为交易验重器的位数组中的数组元素具备共用性，验重集合中的不同验重元素之间可能存在共用同一标识位置上的数组元素的情况。基于此，为了确保交易验重的可靠性，本申请实施例可以进一步在图2所示的交易池200a中查找是否存在与该交易T2匹配的第一历史交易，如果没有查找到，则可以进一步在图2所示的交易缓存中查找是否与该交易T2匹配的第二历史交易，如果仍未查找到，则可以通过区块链网络访问图2所示的区块链数据库200d，以最终判断该交易T2是否是非重复交易。应当理解，如果在区块链数据库200d中也未查找到与该交易T2匹配的第三历史交易，则可以最终确定该交易T2为非重复交易，即该交易T2并不存在于整个区块链网络中，因此可以允许该节点20c将该交易T2添加至图2所示的交易池200a，以便后续该节点20c的共识层200b可以将该交易池200a中的交易打包成上述目标区块，通过图2所示的其他节点(例如，共识节点20b、共识节点20d以及共识节点20e)对该目标区块进行区块共识，并在区块共识通过之后，将该目标区块暂存至图2所示的交易缓存，以便后续在将该交易缓存中的目标区块上链至上述目标区块链时，将该目标区块中的交易和交易执行结果存储至图2所示的区块链数据库200d。
本申请实施例可以将这里的第一关联关系或者第二关联关系统称为对待处理交易进行第一交易验重后的第一交易验重结果，并可以将通过交易池200a、本地账本层200c的交易缓存或者区块链数据库200d，最终得到的交易验重结果统称为第二交易验重结果。
第一节点(例如，图2所示的节点20c)对接收到的交易添加请求中的交易、以及对接收到的区块中的交易进行交易验重的具体过程，可以参见如下图3至图10所对应的实施例。
进一步的，请参见图3，图3是本申请提供的一种交易验重方法的流程示意图，如图3所示，方法可以由上述区块链网络中的第一节点执行，该第一节点中部署有交易验重器，应当理解，该第一节点可以为上述图1所示的共识网络100a中任意一个节点。方法具体可以包括以下步骤S101-步骤S104。
步骤S101，获取待上链至区块链网络的待处理交易。
具体的，第一节点可以在获取到某个交易时，将该获取到交易视为待处理交易。该第一节点可以进一步确定该待处理交易的交易来源属性，进而可以通过不同的交易来源属性，使用不同的交易验重策略对该待处理交易进行交易验重。
其中，这里的交易可以来自第一来源，该第一来源是指来自区块链客户端发送的交易添加请求。这里的交易还可以来自第二来源，该第二来源是指来自其他节点广播过来的区块，或者这里的交易可以来自第三来源，该第三来源是指可以来自其他节点同步过来的交易池中的交易。为便于理解，本申请实施例可以将第一来源和第三来源的来源属性统称为第一来源属性，并可以将第二来源的来源属性统称为第二来源属性。其中，第一来源属性可以用于表征该待处理交易为上述区块链客户端发送的交易添加请求中的交易(例如，交易Tx1)；可选的，该第一来源属性还可以用于表征该待处理交易为上述第二节点的交易池同步过来的交易(例如，交易Tx2)。其中，第二来源属性用于表征该待处理交易为上述第二节点(例如，区块链网络中的其他共识节点)发送的区块中的交易(例如，区块中的交易具体可以包括交易1、交易2、…、交易N)。
基于此，若确定出的交易来源属性为第一来源属性，则可以采用第一交易验重策略和/或第二交易验重策略，对待处理交易进行交易验重。比如，可以采用第一交易验重策略执行下述步骤S102-步骤S104，以对该第一节点当前获取到的交易进行第一交易验重。
可选的，若确定出的交易来源属性为第二来源属性，则可以采用第三交易验重策略和/或第四交易验重策略，对该目标区块中的交易进行交易验重。比如，该第一节点可以预先基于第三交易验重策略控制交易验重器遍历该区块(即上述目标区块)中的每个交易(即上述前述交易1、交易2、…、交易N)，以进行交易验重，从而得到该目标区块对应的区块交易验重结果。
若在通过交易验重器对该目标区块中的交易进行交易验重的过程中，判断出该目标区块中的每个交易均不为重复交易(即目标区块中的每个交易均为非重复交易)，则可以接收该目标区块，进而可以根据该目标区块中所有交易的目标标识位置上的哈希映射值，将该第一节点的交易验重器中的位数组(即上述待查询位数组)中对应目标标识位置上的数组元素变更为1。反之，在通过交易验重器对该目标区块中的交易进行交易验重时，一旦确定目标区块中的某个交易可能为重复交易，则可以进一步基于第四交易验重策略， 在交易缓存和区块链账本中对该交易再次进行交易验重，以避免误将该目标区块中的这个交易识别为重复交易。
为便于理解，这里以该第一节点确定的交易来源属性为上述第一来源属性为例，此时，该第一节点可以基于该第一来源属性使用上述第一交易验重策略执行下述步骤S102。
步骤S102，在通过交易验重器对待处理交易进行第一交易验重，获取交易验重器的位数组和K个哈希函数，将获取到的位数组作为待处理交易对应的待查询位数组。
其中，待查询位数组中包括M个数组元素，这M个数组元素中包括第一数组元素；M为待查询位数组的数组长度，M为大于1的整数，K为小于M的正整数。
具体的，第一节点可以在通过交易验重器基于第一交易验重策略对待处理交易进行第一交易验重时，从交易验重器中获取数组长度为M的位数组，并获取与数组长度为M的位数组相关联的K个哈希函数；在数组长度为M的位数组中，交易验重器的验重集合中的验重元素映射的K个关键标识位置上的数组元素均为第二数组元素(这里的第二数组元素可以为上述值为1的数组元素)；一个关键标识位置为将验重元素通过一个哈希函数进行哈希位置映射后得到的标识位置；进一步的，第一节点可以在数组长度为M的位数组中，将M个数组元素中除第二数组元素之外的数组元素作为第一数组元素(这里的第一数组元素可以为上述值为0的数组元素)；其中，第一数组元素对应的标识位置不同于第二数组元素对应的标识位置，且第一数组元素的元素数量与第二数组元素的元素数量之和为M；进一步的，第一节点可以将由第一数组元素和第二数组元素构成的位数组作为待处理交易对应的待查询位数组。
为便于理解，进一步的，请参见图4，图4是本申请实施例提供的一种确定待查询位数组的场景示意图。如图4所示，第一节点在基于上述第一交易验重策略对当前获取到的交易(即待处理交易)进行交易查询时，可以触发图4所示的交易验重器4a，以获取该交易验重器4a当前所维护的位数组401a，图4所示的位数组401a包含M个数组元素，这M个数组元素由一个很长的二进制向量构成，即位数组401a中的每个数组元素可以用一个bit位的1表示，也可以用一个bit位的0表示。其中，值为0的数组元素即为上述第一数组元素，值为1的数组元素即为上述第二数组元素。本申请实施例可以将由第一数组元素和第二数组元素构成的位数组(即图4所示的位数组401a)作为该待处理交易对应的待查询位数组。
第一节点在获取上述数组长度为M的位数组(即图4所示的位数组401a)时，还可以获取该交易验重器的K个哈希函数。应当理解，这里的K个哈希函数可以包括图4所示的哈希函数41a、哈希函数41b、…、哈希函数41k。
在本申请实施例中，通过引入多个哈希函数，可以在将某个交易的交易哈希值进行哈希位置映射(简称为哈希映射)时，增大哈希映射后得到的交易映射值的随机性，使得对某个交易的交易哈希值进行哈希映射后的交易映射值可以尽可能均匀的分布在交易验重器的位数组中，从而在一定程度上减少对某个交易的交易哈希值进行哈希映射后得到的交易映射值产生哈希碰撞的概率。为便于理解，这里以该交易验重器401a的哈希函数有三个为例，这三个哈希函数可以为图4所示的哈希函数41a、哈希函数41b和哈希函数41k。
比如，对于图4所示的元素A1、元素A2和元素A3而言，交易验重器本身并不直接存储其维护的验重集合中的这3个验重元素。如图4所示，在数组长度为M的位数组401a中，验重集合中的每个验重元素映射的K个关键标识位置上的数组元素均为第二数组元素；对于一个验重元素所关联的K个关键标识位置而言，一个关键标识位置为将该一个验重元素通过一个哈希函数进行哈希位置映射后得到的标识位置。所以，当第一节点通过该交易验重器中的位数组401a描述当前已经插入元素A1时，可以将该元素A1当前映射在该位数组401的3个目标标识位置(例如，标识位置4b、标识位置4f和标识位置4m)上的交易映射值均变更为1。同理，当第一节点通过该交易验重器中的位数组401a描述当前已经插入元素A2时，可以将该元素A2当前映射在该位数组401的3个目标标识位置(例如，标识位置4e、标识位置4f和标识位置4k)上的交易映射值均变更为1。以此类推，当第一节点通过该交易验重器中的位数组401a描述当前已经插入元素A3时，可以将该元素A3当前映射在该位数组401的3个目标标识位置(例如，标识位置4d、标识位置4k和标识位置4p)上的交易映射值均变更为1。
如图4所示，对于元素A1和元素A2而言，可能会存在共享同一个标识位置(例如，图4所示的标识位置4f)上的第二数组元素(即值为1的数组元素)的情况，且对于元素A2和元素A3而言，也可能会存在共享同一个标识位置(例如，图4所示的标识位置4k)上的第二数组元素(即值为1的数组元素)的情况。
当该第一节点通过图4所示的交易验重器401a对当前获取到的交易进行交易验重时，可以准确判断出当前获取到的交易是否存在于验重集合中。比如，可以在当前获取到的交易关联的K(例如，3)个目标标识位置上的数组元素存在为0的情况下，可以准确且快速地判断出当前交易不存在验重集合中，即可以确定当前获取到的交易为非重复交易。
然而，如图4所示，对于图4所示的标识位置4b、标识位置4d和标识位置4e这3个点而言，尽管这3个关键标识位置上的数组元素均为1，但并不能直接认为当前获取到的交易存在于验重集合中，也就不能直接认为当前获取到的交易为重复交易，毕竟图4所示的标识位置4b、标识位置4d和标识位置4e这3个点是根据3个不同元素的哈希值经过哈希映射后得到的标识 位置。基于此，本申请实施例还需要进一步基于上述第二交易验重策略，对当前获取到的这个交易进行第二交易验重，以进一步验证当前获取到的交易是否为重复交易，进而可以提升交易验重的可靠性。
步骤S103，基于K个哈希函数，将待处理交易映射至待查询位数组的K个目标标识位置；在M个数组元素中，将K个目标标识位置上的数组元素作为K个目标标识位置上的交易映射值。
为便于理解，进一步的，请参见图5，图5是本申请实施例提供的一种通过交易验重器的哈希函数将待处理交易映射至待查询位数组的场景示意图。如图5所示的位数组502a可以为上述图4所对应的实施例中的待查询位数组。即通过该待查询位数组，可以用于判断图5所示的交易Tx1是否存在于该交易验重器的验重集合中。
如图5所示，第一节点可以在当前获取到的交易为图5所示的Tx1时，通过该第一节点与发送上述交易添加请求的用户终端(该用户终端中运行有区块链客户端)之间所遵从的哈希转换规则，对该交易Tx1进行哈希计算，以得到用于唯一标识该交易Tx1的交易哈希值。进一步的，如图5所示，第一节点可以将该交易Tx1的交易哈希值输入图5所示的交易验重器5a，即将该交易Tx1的交易哈希值作为交易验重器的输入值。进一步的，该第一节点可以通过图5所示的K(即K＝3)个哈希函数对该输入值再次进行哈希映射，以将该交易Tx1映射到该位数组502a上的3个点，一个点对应一个bit位。
其中，这3个点可以为图5所示的标识位置5b(即目标标识位置1)上的交易映射值、标识位置5f(即目标标识位置2)上的交易映射值、标识位置5o(即目标标识位置3)上的交易映射值。
进一步的，第一节点可以进一步确定该待查询位数组中的第一数组元素(即值为0的数组元素)与这3个目标标识位置上的交易映射值之间的关联关系。即，可以在这3个目标标识位置上的交易映射值中查找是否存在与第一数组元素相同的交易映射值，如果查找到，则可以确定该交易Tx1并不存在于该交易验重器5a维护的验重集合中。反之，则可以暂且认为该交易Tx1可能存在于该交易验重器5a维护的验重集合中，需要基于上述第二交易验重策略，进一步在交易池、交易缓存以及区块链数据库进行第二交易验重，以最终判断该交易Tx1是否为存在与该区块链网络中。
步骤S104，确定第一数组元素与K个目标标识位置上的交易映射值之间的关联关系，基于关联关系得到对待处理交易进行第一交易验重的第一交易验重结果。
本申请实施例可以在第一数组元素与K个目标标识位置上的交易映射值之间的关联关系为第一关联关系时，确定K个目标标识位置上的交易映射值中存在与第一数组元素相同的交易映射值，进而可以基于该第一关联关系，得到该待处理交易为非重复交易的验重结果，并可以将确定的该待处理交易 为非重复交易的验重结果，作为对待处理交易进行第一交易验重的第一交易验重结果。
其中，如上述图5所示，标识位置5b(即目标标识位置1)上的交易映射值和标识位置5f(即目标标识位置2)上的交易映射值为上述第二数组元素，但是，标识位置5o(即目标标识位置3)上的交易映射值为上述第一数组元素。即该第一节点可以在确定K(即K＝3)个交易映射值中存在与第一数组元素相同的交易映射值，作为第一数组元素与K个目标标识位置上的交易映射值之间的第一关联关系，进而可以基于该第一关联关系，确定该交易Tx1不存在于该交易验重器5a维护的验重集合中，进而可以控制该交易验重器5a输出Tx1不存在与验重集合中的交易验重结果，并可以将输出的Tx1不存在与验重集合中的交易验重结果，作为对上述待处理交易进行第一交易验重的第一交易验重结果。
由此可见，本申请实施例在获取到待处理交易时，可以预先在第一节点的节点内存中，通过交易验重器判断该待处理交易是否存在于该交易验重器维护的验重集合中，并可以将判断出的交易验重结果作为对待处理交易进行第一交易验重后的第一交易验重结果。应当理解，本申请实施例通过在该节点内存中使用交易验重器进行交易验重，可以快速判断出当前交易为非重复交易的情况。即本申请实施例可以直接通过交易验重器中的第一数组元素与K个目标标识位置上的交易映射值之间的关联关系，快速判断该待处理交易是否存在于该交易验重器所维护的验重集合中，进而可以在无需访问区块链数据库的情况下，提升交易验重的效率。
进一步的，请参见图6，图6是本申请实施例提供的一种交易验重方法的流程示意图。如图6示，方法可以由区块链网络中的第一节点执行，该第一节点可以为上述图1所示的共识网络100a中的任一个区块链节点(例如，上述节点10c)。该方法具体包括以下步骤S201-S216：
步骤S201，获取待上链至区块链网络的待处理交易。
步骤S202，确定待处理交易的交易来源属性。
其中，交易来源属性用于指示交易验重器(例如，上述布隆过滤器)对待处理交易进行交易验重时使用的交易验重策略。
其中，若交易来源属性为第一来源属性，则交易验重策略包括与第一节点的交易池相关联的第一交易验重策略和第二交易验重策略；为便于理解，这里以第一来源属性用于表征待处理交易为交易添加请求中的交易为例，此时，该交易添加请求可以是由与第一节点相关联的区块链客户端发送的；则第一节点可以进一步执行下述步骤S203。
步骤S203，若交易来源属性为第一来源属性，则在通过交易验重器基于第一交易验重策略对待处理交易进行第一交易验重时，从交易验重器中获取数组长度为M的位数组，并获取与数组长度为M的位数组相关联的K个哈 希函数。其中，在数组长度为M的位数组中，交易验重器的验重集合中的验重元素所映射的K个关键标识位置上的数组元素均为第二数组元素；一个关键标识位置为将验重元素通过一个哈希函数进行哈希位置映射后所得到的标识位置；
步骤S204，在数组长度为M的位数组中，将M个数组元素中除第二数组元素之外的数组元素作为第一数组元素。
其中，第一数组元素对应的标识位置不同于第二数组元素对应的标识位置，且第一数组元素的元素数量与第二数组元素的元素数量之和为M。
步骤S205，将由第一数组元素和第二数组元素构成的位数组作为待处理交易对应的待查询位数组。
步骤S206，基于K个哈希函数，将待处理交易映射至待查询位数组的K个目标标识位置；在M个数组元素中，将K个目标标识位置上的数组元素作为K个目标标识位置上的交易映射值。
步骤S207，确定第一数组元素与K个目标标识位置上的交易映射值之间的关联关系，基于关联关系，得到对待处理交易进行第一交易验重后的第一交易验重结果。
其中，关联关系包括第一关联关系，这里的第一关联关系用于表征K个目标标识位置上的交易映射值中存在与第一数组元素相同的交易映射值；此时，第一节点可以进一步执行下述步骤S208-步骤210。可选的，关联关系还可以包括第二关联关系，这里的第二关联关系用于表征K个目标标识位置上的交易映射值中不存在与第一数组元素相同的交易映射值；此时，第一节点可以在执行完上述步骤S207时，进一步跳转执行步骤S211和步骤S212。
步骤S208，若第一交易验重结果指示关联关系为第一关联关系，则确定待处理交易不属于交易验重器的验重集合中的验重元素，且控制交易验重器输出待处理交易的交易属性为非重复交易属性。
步骤S209，将具有非重复交易属性的待处理交易确定为待保存至第一节点的交易池的第一目标交易。
其中，这里的第一目标交易可以为通过上述交易验重器对待处理交易进行第一交易验重确定的非重复交易。此时，第一节点可以执行下述步骤S210，以将该第一目标交易添加到交易池中。
步骤S210，在将第一目标交易保存至第一节点的交易池时，将K个目标标识位置上与第一数组元素相同的交易映射值作为第一目标交易映射值，且在待查询位数组中，将第一目标交易映射值所对应的目标标识位置上的数组元素由第一数组元素更新为第二数组元素。
为便于理解，进一步的，请参见图7，图7是本申请实施例提供的一种更新待查询位数组的场景示意图。图7所示的交易Tx1可以为上述图5所对应实施例中的待处理交易。如图7所示，第一节点可以通过上述图5所示的 交易验重器5a的3个哈希函数，将该交易Tx1映射为图7所示位数组701a的3个目标标识位置，这3个目标标识位置可以为图7所示的标识位置7b、标识位置7f以及标识位置7o；如图7所示，由于在这3个目标标识位置上的交易映射值中，存在标识位置7o上的交易映射值与上述第一数组元素(即值为0的数组元素相同)。所以，该第一节点可以确定图7所示的交易Tx1的交易属性为非重复交易属性，并可以将该具有非重复交易属性的交易Tx1作为上述第一目标交易添加至交易池(例如，上述图2所对应实施例中的200a)中。
在将该第一目标交易添加至交易池中时，直接将该交易Tx1的三个目标标识位置上的数组元素均设置为第二数组元素，以得到图2所示的位数组702a，并可以将该位数组702a作为目标位数组，以便后续再获取到新的交易(例如，交易Tx2)时，可以将该目标位数组作为新的待查询位数组，以重复执行上述步骤S205-步骤S210。如图7所示，该位数组702a中的3个目标标识位置上的数组元素均为第二数组元素，此时，该第一节点可以将添加到交易池中的交易Tx1作为新的验重元素插入到交易验重器维护的验重集合中，即可以对验重集合中验重元素的数量进行递增处理，例如，加一处理。
可选的，为提升对交易验重器的数组元素进行更新的效率，本申请实施例还可以在K个目标标识位置上的交易映射值中，直接将与第一数组元素相同的交易映射值(即图7所示的位数组701a的标识位置7o上的交易映射值)作为第一目标交易映射值，且在待查询位数组中，将第一目标交易映射值对应的目标标识位置(即标识位置7o)上的数组元素由第一数组元素(即位数组701a的标识位置7o上的值0)更新为第二数组元素(即位数组702a的标识位置7o上的值1)。
步骤S211，若第一交易验重结果指示关联关系为第二关联关系，则获取与第一节点的交易池相关联的第二交易验重策略。
步骤S212，基于第二交易验重策略对待处理交易进行第二交易验重，得到第二交易验重结果。
具体的，第一节点可以基于第二交易验重策略，在第一节点的交易池中查找与待处理交易相匹配的第一历史交易；若在第一节点的交易池中查找到与待处理交易相匹配的第一历史交易，则确定待处理交易的交易属性为重复交易属性，将具备重复交易属性的待处理交易作为与第二交易验重策略相关联的第一类重复交易；进一步的，第一节点可以将第一类重复交易作为对待处理交易进行第二交易验重后的第二交易验重结果。
可选的，若在第一节点的交易池中未查找到与待处理交易相匹配的第一历史交易，则确定待处理交易的交易属性为第一非重复交易属性，并可以将具备第一非重复交易属性的待处理交易作为与第二交易验重策略相关联的第一过渡验重结果；进一步的，第一节点可以基于第一过渡验重结果，将具备 第一非重复交易属性的待处理交易作为第一过渡交易，在第一节点的交易缓存中查找与第一过渡交易相匹配的第二历史交易；若在第一节点的交易缓存中查找到与第一过渡交易相匹配的第二历史交易，则确定第一过渡交易的交易属性为重复交易属性，将具备重复交易属性的第一过渡交易作为与第二交易验重策略相关联的第二类重复交易；进一步的，第一节点可以将该第二类重复交易作为对待处理交易进行第二交易验重后的第二交易验重结果。
可选的，若在第一节点的交易缓存中未查找到与第一过渡交易相匹配的第二历史交易，则确定第一过渡交易的交易属性为第二非重复交易属性，将具备第二非重复交易属性的第一过渡交易作为与第二交易验重策略相关联的第二过渡验重结果；进一步的，第一节点可以基于第二过渡验重结果，将具备第二非重复交易属性的第一过渡交易作为第二过渡交易，在与第一节点相关联的区块链数据库中查找与第二过渡交易相匹配的第三历史交易；若在区块链数据库中查找到与第二过渡交易相匹配的第三历史交易，则确定第二过渡交易的交易属性为重复交易属性，将具备重复交易属性的第二过渡交易作为与第二交易验重策略相关联的第三类重复交易；进一步的，第一节点可以将该第三类重复交易作为对待处理交易进行第二交易验重后的第二交易验重结果。
步骤S213，若第二交易验重结果指示待处理交易的交易属性为重复交易属性，则将待处理交易确定为重复交易，且拒绝将重复交易添加至第一节点的交易池。
步骤S214，若第二交易验重结果指示待处理交易的交易属性为非重复交易属性，则基于具有非重复交易属性的待处理交易，确定用于添加至第一节点的交易池的第二目标交易，且在第一节点的交易池中保存第二目标交易。
步骤S215，在将第二目标交易插入至交易验重器的验重集合时，将K个目标标识位置上的交易映射值作为第二目标交易映射值。
步骤S216，控制交易验重器待查询位数组中第二目标交易映射值对应的目标标识位置上的数组元素更新为第二数组元素，将更新后的待查询位数组作为目标位数组。
为便于理解，进一步的，请参见图8，图8是本申请实施例提供的一种业务请求中的交易进行交易验重的时序图。如图8所示，第一节点可以在执行步骤S81时，接收客户端(这里的客户端为上述区块链客户端)发送的交易1，并可以将当前接收到的交易1作为上述步骤S201中的待处理交易。
这里的交易1(即待处理交易)可以为该客户端(即上述区块链客户端)发送的业务请求中的交易。可以理解的是，这里的业务请求可以包括运行有该区块链客户端的用户终端发送的用于请求接收该交易1的交易添加请求；可选的，这里的业务请求还可以包括上述区块链网络中的第二节点发送的用于请求同步自己交易池中的交易1的交易同步请求。比如，对于业务请求为 交易添加请求而言，这里的交易1可以为上述图7所对应实施例中的交易Tx1。又比如，对于业务请求为交易同步请求而言，这里的交易1可以为上述图3所对应实施例中的交易Tx2。
进一步的，如图8所示，第一节点在确定该交易1的交易来源属性为第一来源属性(即该交易1来源于上述业务请求)时，可以进一步执行步骤S82，以通过交易验重器对交易1进行第一交易验重，以得到的上述第一交易验重结果。其中，第一交易验重结果的获取方式可以参见上述步骤S203-步骤S207的具体描述，这里不再继续进行赘述。
进一步的，如图8所示，若第一交易验重结果指示该交易1为非重复交易，则可以跳转执行步骤S83，以将该交易1作为第一目标交易，进而可以保存至交易池。第一节点在将交易1保存至交易池时，可以进一步执行步骤S84，根据上述步骤S82得到的交易1的K个目标标识位置上的数组元素，快速更新交易验重器中的待查询位数组。其中，该第一节点更新该待查询位数组的具体实现方式，可以参见上述图6所对应实施例中对步骤S210。
可选的，如图8所示，若上述步骤S82得到的第一交易验重结果指示该交易1可能为重复交易，则可以进一步在上述关联关系为第二关联关系时，通过第二交易验重策略执行图8所示的步骤S85，以判断该交易1(即上述待处理交易)是否已经存在于交易池中；即此时，第一节点可以基于第二交易验重策略，在交易池中查找与该交易1相匹配的历史交易。为便于理解，本申请实施例可以将该交易池中的历史交易统称为第一历史交易。
进一步的，如图8所示，如果第一节点在交易池中查找到与交易1相匹配的第一历史交易，则可以将交易1已经存在于交易池的交易验重结果(即交易验重结果1)作为第二交易验重结果，进而可以跳转执行步骤S86，即可以直接拒绝接收该交易1。应当理解，第一节点在确定交易1已经存在于交易池中时，可以将具备重复交易属性的待处理交易作为与该第二交易验重策略相关联的第一类重复交易，并可以将第一类重复交易作为对交易1进行第二交易验重后的第二交易验重结果。
可选的，如图8所示，如果第一节点在交易池中未查找到与交易1相匹配的第一历史交易，则可以将交易1不存在于交易池的交易验重结果(例如，验重结果1’)作为第一过渡验重结果，进而可以继续执行步骤S87，以进一步判断交易1是否已经存在于交易缓存中。应当理解，第一节点在确定交易1不存在于交易池中时，可以将具备非重复交易属性(即第一非重复交易属性)的交易1作为与该第二交易验重策略相关联的第一过渡验重结果，以便于基于此进一步执行步骤S87。
此时，第一节点可以将具备第一非重复交易属性的交易1作为第一过渡交易，并进一步在步骤S87的交易缓存中查找是否存在与该第一过渡交易(即具备第一非重复交易属性的交易1)相匹配的历史交易；为便于理解，本申 请实施例可以将该交易缓存中存储的历史交易统称为第二历史交易。如图8所示，若第一节点在交易缓存中查找到与第一过渡交易相匹配的第二历史交易，则可以将交易1已经存在于交易缓存的交易验重结果(即验重结果2)作为对交易1进行第二交易验重后的第二交易验重结果，进而可以跳转执行步骤S86，即可以直接拒绝接收该交易1。应当理解，第一节点在确定交易1已经存在于交易缓存中时，可以将具备重复交易属性的第一过渡交易作为与该第二交易验重策略相关联的第二类重复交易，并可以将第二类重复交易作为对交易1进行第二交易验重后的第二交易验重结果。
可选的，如图8所示，如果第一节点在交易缓存池中未查找到与第一过渡交易(即具备第一非重复交易属性的交易1)相匹配的第二历史交易，则可以将交易1不存在于交易缓存的交易验重结果(例如，验重结果2’)作为第二过渡验重结果，进而可以继续执行步骤S88，以进一步判断交易1是否已经存在于区块链数据库中。应当理解，第一节点在确定交易1不存在于交易缓存中时，可以将具备非重复交易属性(即具备第一非重复交易属性且具备第二非重复交易属性)的交易1作为与该第二交易验重策略相关联的第二过渡验重结果，以便于可以进一步执行步骤S88。
此时，第一节点可以将具备第一非重复交易属性和第二非重复交易属性的交易1作为第二过渡交易，即该第一节点将既不在交易池又不在交易缓存的交易1作为第二过渡交易，并可以进一步在步骤S88的区块链数据库中查找是否存在与该第二过渡交易相匹配的历史交易；为便于理解，本申请实施例可以将该区块链数据库中所存储的历史交易统称为第三历史交易。如图8所示，若第一节点在区块链数据库中查找到与第二过渡交易相匹配的第三历史交易，则可以将交易1已经存在于区块链数据库的交易验重结果(即验重结果3)作为对交易1进行第二交易验重后的第二交易验重结果，进而可以跳转执行步骤S86，即可以直接拒绝接收该交易1。应当理解，第一节点在确定交易1已经存在于区块链数据库中时，可以将具备重复交易属性的第二过渡交易作为与该第二交易验重策略相关联的第三类重复交易，并可以将第三类重复交易作为对交易1进行第二交易验重后的第二交易验重结果。
可选的，如图8所示，如果第一节点在区块链数据库中未查找到与第二过渡交易(即具备第一非重复交易属性和第二非重复交易属性的交易1)相匹配的第三历史交易，则可以将交易1不存在于区块链数据库的交易验重结果(例如，验重结果3’)作为对交易1进行第二交易验重后的第二交易验重结果，进而可以继续执行步骤S83和步骤84。应当理解，该第一节点基于上述第二交易验重策略将该交易1添加至交易池、以及更新待查询位数组的具体实现方式，可以参见上述图6所对应实施例中的步骤S214-步骤S216，这里不再继续进行赘述。
由此可见，本申请实施例在获取到待处理交易时，可以预先在第一节点 的节点内存中，通过交易验重器判断该待处理交易是否存在于该交易验重器维护的验重集合中，并可以将判断出的交易验重结果作为对待处理交易进行第一交易验重的第一交易验重结果。本申请实施例通过在该节点内存中使用交易验重器进行交易验重，可以快速判断出当前获取到的交易为非重复交易的情况，即本申请实施例可以直接通过交易验重器中的第一数组元素与K个目标标识位置上的交易映射值之间的关联关系，快速判断该待处理交易是否存在于交易验重器维护的验重集合中，以提升交易验重的效率。可选的，本申请实施例还可以在通过交易验重器初步确定出当前获取到的交易(即上述待处理交易)疑似重复交易的情况下，将对待处理交易进行交易验重的交易验重策略由交易验重器的第一交易验重策略切换为与区块链网络相关联的第二交易验重策略，进而可以基于第二交易验重策略对疑似重复交易的待处理交易进行第二交易验重，以得到第二交易验重结果。这里的第二交易验重是指进一步在与该区块链网络相关联的交易池、交易缓存以及区块链数据库中查找是否存在与该疑似重复交易的相匹配的历史交易，如果存在，则确定该疑似重复交易确实为重复交易。反之，如果不存在，则可以确定该疑似重复交易为非重复交易，进而可以提升交易验重的可靠性。
进一步的，请参见图9，图9是本申请实施例提供的一种交易验重方法的流程示意图。如图9示，方法可以由区块链网络中的第一节点执行，该第一节点可以为上述图1所示的共识网络100a中的任一个区块链节点(例如，上述节点10c)。该方法具体包括以下步骤S301-S309：
步骤S301，获取待上链至区块链网络的待处理交易。
步骤S302，确定待处理交易的交易来源属性。
其中，交易来源属性用于指示交易验重器对待处理交易进行交易验重时使用的交易验重策略。这里的交易来源属性可以包括上述第一来源属性和上述第二来源属性。
其中，若交易来源属性为第一来源属性，则交易验重策略可以包括与第一节点的交易池相关联的第一交易验重策略和第二交易验重策略；其中，第一交易验重策略的优先级高于第二交易验重策略的优先级。其中，第一来源属性可以用于表征待处理交易为交易添加请求中的交易，该交易添加请求是与第一节点相关联的区块链客户端发送的；可选的，这里的第一来源属性还可以用于表征待处理交易为交易同步请求中的交易，这里的交易添加请求中的交易和交易同步请求中的交易均可以统称为业务请求中的交易。其中，第一节点对接收到的业务请求中的交易进行交易验重的具体过程，可以参见上述图8所对应实施例对交易1进行交易验重的具体过程的描述，这里将不再继续进行赘述。
若交易来源属性为第二来源属性，则交易验重策略包括与第一节点的交易缓存相关联的第三交易验重策略和第四交易验重策略。其中，第三交易验 重策略的优先级高于第二交易验重策略的优先级。比如，第一节点可以预先基于第三交易验重策略执行下述步骤S303；第二来源属性用于表征待处理交易为区块链网络中的第二节点广播的目标区块中的交易；目标区块中的每个交易对应一个交易标识，且一个交易标识用于表征一个交易在目标区块中的打包顺序。
为便于理解，这里以交易来源属性为第二来源属性为例，阐述第一节点对接收到的第二节点发送的目标区块中的交易进行交易验重的具体过程。
步骤S303，若交易来源属性为第二来源属性，则基于第三交易验重策略，获取目标区块中的关键交易的交易标识。
其中，关键交易为目标区块包括的N个交易中具有最大打包顺序的交易；N为正整数。
步骤S304，将待处理交易的交易标识与关键交易的交易标识进行比较，得到初始比较结果。
步骤S305，若初始比较结果指示待处理交易的交易标识与目标区块中的关键交易的交易标识不相同，则确定存在待处理交易的下一交易。
步骤S306，通过交易验重器，对目标区块中的待处理交易进行块内交易验重，得到与待处理交易相关联的区块交易验重结果。
具体的，第一节点可以在通过交易验重器基于上述第三交易验重策略对待处理交易进行第一交易验重时，获取交易验重器的位数组和K个哈希函数，将获取到的位数组作为待处理交易对应的待查询位数组；待查询位数组的M个数组元素中包括第一数组元素；K为小于M的正整数；M为待查询位数组的数组长度。
进一步的，第一节点可以基于K个哈希函数将待处理交易映射至待查询位数组的K个目标标识位置，在M个数组元素中，将K个目标标识位置上的数组元素作为K个目标标识位置上的交易映射值；进一步的，第一节点可以确定第一数组元素与K个目标标识位置上的交易映射值之间的关联关系，基于关联关系得到对待处理交易进行第一交易验重后的第一交易验重结果，进而可以将该第一交易验重结果作为与待处理交易相关联的区块交易验重结果。
步骤S307，若区块交易验重结果指示目标区块中的待处理交易的交易属性为重复交易属性，则基于第四交易验重策略在第一节点的交易缓存查找与待处理交易相匹配的交易，若在交易缓存中查找到与待处理交易相匹配的交易，则拒绝接收第二节点广播的目标区块。
可选的，若区块交易验重结果指示目标区块中的待处理交易的非重复交易，则可以继续将该待处理交易的下一个交易确定为新的待处理交易，以重复执行上述步骤S304-步骤S307，直到该第一节点对该目标区块中的具有最大打包顺序的交易(即上述关键交易)进行交易验重，且验重通过为止，此 时可以确定目标区块中的每个交易均为非重复交易。
步骤S308，若初始比较结果指示待处理交易的交易标识与目标区块中的关键交易的交易标识相同，且确定目标区块中不存在待处理交易的下一交易，则确定目标区块中的每个交易均为非重复交易。
由此可见，该第一节点可以将当前最新获取到待处理交易的交易标识与目标区块中的关键交易的交易标识进行比较，以得到最新的初始比较结果，进而可以在该最新的初始比较结果指示当前最新确定的待处理交易的交易标识与目标区块中的关键交易的交易标识相同，且确定目标区块中不存在待处理交易的下一交易，则确定目标区块中的每个交易均为非重复交易，进而可以继续执行下述步骤309。
步骤S309，通过交易验重器，获取目标区块中的每个交易的交易哈希值，基于每个交易的交易哈希值更新交易验重器中的位数组；每个交易的交易哈希值是由交易验重器中的K个哈希函数确定的。
为便于理解，进一步的，请参见图10，图10是本申请实施例提供的一种对区块中的交易进行交易验重的场景实施例。图10所示的第一节点可以接收第二节点广播来的目标区块，该目标区块可以为图10所示的区块X。其中，该区块X可以包括N个交易，这里的N个交易具体可以为图10所示的交易11、交易12、交易13、…、交易1n。其中，该目标区块中的每个交易分别对应一个交易标识，且一个交易标识用于表征一个交易在目标区块中的打包顺序。这里的N为正整数。
如图10所示，该第一节点获取到该目标区块后，可以执行步骤S901，以根据目标区块中每个交易的交易打包顺序，遍历将该目标区块中的交易作为待处理交易，为便于理解，本申请实施例将图10所示的交易11(即具有最小打包顺序)作为待处理交易，由于该待处理交易来自于第二节点广播来的区块X，所以，该第一节点可以确定该交易11的交易来源属性为上述第二来源属性，进而可以基于第三交易验重策略(即通过交易验重器对该交易11进行交易验重时使用的交易验重策略)，获取该目标区块中的关键交易(即具有最大打包顺序的交易，例如，图10所示的交易1n)的交易标识，进而可以执行图10所示的步骤S902，以判断该待处理交易(例如，交易11)的交易标识是否与该关键交易(例如，交易1n)的交易标识相同。换言之，此时，第一节点可以将待处理交易的交易标识与关键交易的交易标识进行比较，得到初始比较结果。
进一步的，如图10所示，若该初始比较结果指示待处理交易(例如，交易11)的交易标识与目标区块中的关键交易(例如，交易1n)的交易标识不相同，则确定存在待处理交易的下一交易，进而可以继续执行图10所示的步骤S904，以通过交易验重器(这里的交易验重器可以为上述布隆过滤器)对该待处理交易(例如，交易11)进行块内交易验重，以得到区块交易验重结 果。其中，该第一节点通过交易验重器(例如，布隆过滤器)对该待交易11进行交易验重的具体实现方式，可以参见上述图3所对应的实施例中基于第一交易验重策略对待处理交易进行交易验重的具体过程的描述，这里将不再继续进行赘述。
如图10所示，第一节点可以在区块交易验重结果指示该待处理交易(例如，交易11)为重复交易时，跳转执行图10所示的步骤S907，以拒绝接收该目标区块。反之，该第一节点可以在区块交易验重结果指示该待处理交易(例如，交易11)可能为非重复交易时，进一步基于与第二来源属性相关联的第四交易验重策略执行图10所示的步骤S905，以判断该待处理交易(例如，交易11)是否已经存在于交易缓存中。在本申请实施例中，该第一节点可以在交易缓存中查找是否存在与待处理交易(例如，交易11)的交易哈希值相匹配的第四历史交易的交易哈希值。这里的第四历史交易可以为该第一节点在接收到目标区块之前获取的待上链的历史区块中的历史交易。这些历史区块可以暂存在该交易缓存中，以便后续在确定这些历史区块均属于最长链时，将这些历史区块写入图10所示的区块链数据库对应的目标区块链。
进一步的，如图10所示，第一节点在交易缓存中查找到存在与待处理交易(例如，交易11)的交易哈希值相匹配的第四历史交易的交易哈希值时，确定待处理交易(例如，交易11)已经存在与图10所示的交易缓存中，进而可以执行图10所示的步骤S907，以拒绝接收该目标区块。反之，第一节点在交易缓存中未查找到与待处理交易(例如，交易11)的交易哈希值相匹配的第四历史交易的交易哈希值时，继续基于第四交易验重策略执行图10所示的步骤S906，以判断该待处理交易(例如，交易11)是否已经存在于区块链数据库中。在本申请实施例中，该第一节点可以在区块链数据库中查找是否存在与待处理交易(例如，交易11)的交易哈希值相匹配的第五历史交易的交易哈希值。这里的第五历史交易可以为已上链的历史区块中的历史交易。
进一步的，如图10所示，该第一节点在区块链数据库中查找到存在与待处理交易(例如，交易11)的交易哈希值相匹配的第五历史交易的交易哈希值时，确定该待处理交易(例如，交易11)已经存在于区块链数据库中，进而可以跳转执行图10所示的步骤S907，以拒绝接收该目标区块。反之，该第一节点在区块链数据库中未查找到与待处理交易(例如，交易11)的交易哈希值相匹配的第五历史交易的交易哈希值时，确定该待处理交易(例如，交易11)不在区块链数据库中，进而可以继续执行图10所示的步骤S908，以从该目标区块(例如，图10所示的区块X)中获取该待处理交易的下一交易(例如，图10所示的交易12)，以重复执行图10所示的步骤S901-步骤S908，直到第一节点获取到该目标区块中具有最大打包顺序的交易1n，且通过步骤S901-步骤S908对交易1n进行交易验重且确认验重通过时，可以执行图10所示的步骤S909，以确定该目标区块中的每个交易均为非重复交易。
进一步的，第一节点可以在执行步骤S910时，通过交易验重器获取目标区块中的每个交易的交易哈希值，进而可以执行图10所示的步骤S911，即该第一节点可以基于每个交易的交易哈希值更新交易验重器中的位数组。
此时，该第一节点可以确定待处理交易(例如，交易11)已经存在与交易缓存中时，确定该第一节点的交易缓存中已经有该目标区块。比如，在第一节点宕机或者网络延迟等情况(即第一节点未在响应时长内向第二节点反馈区块接收消息的情况)下，第二节点会存在重复发送目标区块的现象。当该第一节点接收到第二节点重复发来的目标区块(例如，图10所示的区块X)时，可以通过上述方式对该目标区块进行验重处理，并对已存在的目标区块拒绝接收，从而避免浪费节点内存的存储空间。
由此可见，本申请实施例通过在该节点内存中使用交易验重器进行交易验重，可以快速判断出当前获取到的目标区块中的交易是否为重复交易，进而可以在该目标区块中的所有交易均为非重复交易的情况下，接收目标区块，以便后续可以继续执行目标区块中的每个交易，进而将目标区块中每个交易的交易执行结果暂存至该第一节点的交易缓存。即本申请实施例可以直接通过交易验重器中的第一数组元素与K个目标标识位置上的交易映射值之间的关联关系，快速判断该待处理交易是否存在于该第一节点的节点内存中所部署的交易验重器中，进而可以提升交易验重的效率。可选的，本申请实施例还可以在通过交易验重器初步确定当前获取到的交易(即上述待处理交易)疑似重复交易的情况下，将对待处理交易进行交易验重的交易验重策略由交易验重器的第三交易验重策略切换为与区块链网络相关联的第四交易验重策略，进而可以通过第四交易验重策略对疑似重复交易的待处理交易进行第二交易验重，以得到第二交易验重结果。应当理解，这里的第二交易验重是指进一步在与该区块链网络相关联的交易缓存以及区块链数据库中查找是否存在与该疑似重复交易相匹配的历史交易，如果存在，则确定该疑似重复交易确实为重复交易，进而可以拒绝接收该目标区块，以降低节点内存的存储开销。反之，如果不存在，则可以确定该疑似重复交易为非重复交易，进而可以提升交易验重的可靠性。
进一步的，请参见图11，图11是本申请提供的一种交易验重装置的结构示意图。该交易验重装置1可以是运行于计算机设备中的一个计算机程序(包括程序代码)，例如，交易验重装置1为一个应用软件；该交易验重装置1可以用于执行本申请实施例提供的方法中的相应步骤。如图11所示，交易验重装置1可应用于上述第一节点，该第一节点可以为上述共识网络中任意一个区块链节点，例如，交易验重装置1可应用于上述图1所对应实施例中的节点10c。如图11所示，交易验重装置1可以包括：交易获取模块100、第一验重模块200、映射值确定模块300和第一结果确定模块400；进一步的，交易验重装置1还可以包括：第一关系确定模块500、第一目标确定模块600、 第一目标保存模块700、第二关系确定模块800、第二验重模块900、交易拒绝模块101、第二目标确定模块102、目标映射值确定模块103、元素更新模块104、交易标识获取模块105、交易标识比较模块106、标识不同确定模块107、区块验重结果确定模块108、交易缓存查找模块109、标识相同确定模块110和哈希值获取模块111；
交易获取模块100，用于获取待上链至区块链网络的待处理交易；
可选的，其中，在交易获取模块100获取待上链至区块链网络的待处理交易时，交易获取模块500，还用于确定待处理交易的交易来源属性；交易来源属性用于指示交易验重器对待处理交易进行交易验重时使用的交易验重策略。
第一验重模块200，用于在通过交易验重器对待处理交易进行第一交易验重时，获取交易验重器的位数组和K个哈希函数，将获取到的位数组作为待处理交易对应的待查询位数组；待查询位数组中包括M个数组元素，M个数组元素中包括第一数组元素；M为大于1的整数，K为小于M的正整数；
其中，若交易来源属性为第一来源属性，则交易验重策略包括与第一节点的交易池相关联的第一交易验重策略；第一来源属性用于表征待处理交易为交易添加请求中的交易；交易添加请求是与第一节点相关联的区块链客户端发送的；
第一验重模块200包括：第一交易验重单元2001，第一元素确定单元2002，查询数组确定单元2003；
第一交易验重单元2001，用于在通过交易验重器基于第一交易验重策略对待处理交易进行第一交易验重时，从交易验重器中获取数组长度为M的位数组，并获取与数组长度为M的位数组相关联的K个哈希函数；在数组长度为M的位数组中，交易验重器的验重集合中的验重元素映射的K个关键标识位置上的数组元素均为第二数组元素；一个关键标识位置为将验重元素通过一个哈希函数进行哈希位置映射后得到的标识位置；
第一元素确定单元2002，用于在数组长度为M的位数组中，将M个数组元素中除第二数组元素之外的数组元素作为第一数组元素；第一数组元素对应的标识位置不同于第二数组元素对应的标识位置，且第一数组元素的元素数量与第二数组元素的元素数量之和为M；
查询数组确定单元2003，用于将由第一数组元素和第二数组元素构成的位数组作为待处理交易对应的待查询位数组。
其中，第一交易验重单元2001，第一元素确定单元2002，查询数组确定单元2003的具体实现方式，可以参见上述图3所对应实施例对步骤S102的描述，这里将不再继续进行赘述。
映射值确定模块300，用于基于K个哈希函数，将待处理交易映射至待查询位数组的K个目标标识位置；在M个数组元素中，将K个目标标识位 置上的数组元素作为K个目标标识位置上的交易映射值；
第一结果确定模块400，用于确定第一数组元素与K个目标标识位置上的交易映射值之间的关联关系，基于关联关系，得到对待处理交易进行第一交易验重的第一交易验重结果。
可选的，其中，关联关系包括第一关联关系，第一关联关系用于表征K个目标标识位置上的交易映射值中存在与第一数组元素相同的交易映射值；
第一关系确定模块500，用于若第一交易验重结果指示关联关系为第一关联关系，则确定待处理交易不属于交易验重器的验重集合中的验重元素，且控制交易验重器输出待处理交易的交易属性为非重复交易属性；
第一目标确定模块600，用于将具有非重复交易属性的待处理交易确定为待保存至第一节点的交易池的第一目标交易。
可选的，其中，第一目标保存模块700，用于在将第一目标交易保存至第一节点的交易池时，将K个目标标识位置上与第一数组元素相同的交易映射值作为第一目标交易映射值，且在待查询位数组中，将第一目标交易映射值对应的目标标识位置上的数组元素由第一数组元素更新为第二数组元素。
可选的，其中，关联关系包括第二关联关系，第二关联关系用于表征K个目标标识位置上的交易映射值中不存在与第一数组元素相同的交易映射值；
第二关系确定模块800，用于若第一交易验重结果指示关联关系为第二关联关系，则获取与第一节点的交易池相关联的第二交易验重策略；
第二验重模块900，用于基于第二交易验重策略对待处理交易进行第二交易验重，得到第二交易验重结果。
其中，第二验重模块900包括：交易池查找单元901、第一重复确定单元902、第二结果确定单元903；可选的，第二验重模块900还包括：
交易池查找单元901，用于基于第二交易验重策略，在第一节点的交易池中查找与待处理交易相匹配的第一历史交易；
第一重复确定单元902，用于若在第一节点的交易池中查找到与待处理交易相匹配的第一历史交易，则确定待处理交易的交易属性为重复交易属性，将具备重复交易属性的待处理交易作为与第二交易验重策略相关联的第一类重复交易；
第二结果确定单元903，用于将第一类重复交易作为对待处理交易进行第二交易验重后的第二交易验重结果。
可选的，其中，第一过渡结果确定单元904，用于若在第一节点的交易池中未查找到与待处理交易相匹配的第一历史交易，则将待处理交易的交易属性确定为第一非重复交易属性，将具备第一非重复交易属性的待处理交易作为与第二交易验重策略相关联的第一过渡验重结果；
交易缓存查找单元905，用于基于第一过渡验重结果，将具备第一非重复交易属性的待处理交易作为第一过渡交易，在第一节点的交易缓存中查找 与第一过渡交易相匹配的第二历史交易；
第二重复确定单元906，用于若在第一节点的交易缓存中查找到与第一过渡交易相匹配的第二历史交易，则确定第一过渡交易的交易属性为重复交易属性，将具备重复交易属性的第一过渡交易作为与第二交易验重策略相关联的第二类重复交易；
第二结果确定单元907，用于将第二类重复交易作为对待处理交易进行第二交易验重后的第二交易验重结果。
可选的，其中，第二过渡结果确定单元908，用于若在第一节点的交易缓存中未查找到与第一过渡交易相匹配的第二历史交易，则确定第一过渡交易的交易属性为第二非重复交易属性，将具备第二非重复交易属性的第一过渡交易作为与第二交易验重策略相关联的第二过渡验重结果；
数据库查找单元909，用于基于第二过渡验重结果，将具备第二非重复交易属性的第一过渡交易作为第二过渡交易，在与第一节点相关联的区块链数据库中查找与第二过渡交易相匹配的第三历史交易；
第三重复确定单元910，用于若在区块链数据库中查找到与第二过渡交易相匹配的第三历史交易，则确定第二过渡交易的交易属性为重复交易属性，将具备重复交易属性的第二过渡交易作为与第二交易验重策略相关联的第三类重复交易；
第二结果确定单元903，还用于将第三类重复交易作为对待处理交易进行第二交易验重后的第二交易验重结果。
其中，交易池查找单元901、第一重复确定单元902、第二结果确定单元903、第一过渡结果确定单元904、交易缓存查找单元905、第二重复确定单元906、第二结果确定单元907、第二过渡结果确定单元908、数据库查找单元909、第三重复确定单元910的具体实现方式，可以参见上述图6所对应实施例中对第二交易验重策略的描述，这里将不再继续进行赘述。
可选的，交易拒绝模块101，用于若第二交易验重结果指示待处理交易的交易属性为重复交易属性，则将待处理交易确定为重复交易，且拒绝将重复交易添加至第一节点的交易池。
可选的，第二目标确定模块102，用于若第二交易验重结果指示待处理交易的交易属性为非重复交易属性，则基于具有非重复交易属性的待处理交易，确定用于添加至第一节点的交易池的第二目标交易，且在第一节点的交易池中保存第二目标交易；
目标映射值确定模块103，用于在将第二目标交易插入至交易验重器的验重集合时，将K个目标标识位置上的交易映射值作为第二目标交易映射值；
元素更新模块104，用于控制交易验重器将待查询位数组中第二目标交易映射值对应的目标标识位置上的数组元素更新为第二数组元素，将更新后的待查询位数组作为目标位数组。
可选的，其中，若交易来源属性为第二来源属性，则交易验重策略包括与第一节点的交易缓存相关联的第三交易验重策略和第四交易验重策略；第二来源属性用于表征待处理交易为区块链网络中的第二节点广播的目标区块中的交易；目标区块中的每个交易对应一个交易标识，且一个交易标识用于表征一个交易在目标区块中的打包顺序；
交易标识获取模块105，用于基于第三交易验重策略，获取目标区块中的关键交易的交易标识；关键交易为目标区块所包括的N个交易中具有最大打包顺序的交易；N为正整数；
交易标识比较模块106，用于将待处理交易的交易标识与关键交易的交易标识进行比较，得到初始比较结果；
标识不同确定模块107，用于若初始比较结果指示待处理交易的交易标识与目标区块中的关键交易的交易标识不相同，则确定存在待处理交易的下一交易；
区块验重结果确定模块108，用于通过交易验重器，对目标区块中的待处理交易进行块内交易验重，得到与待处理交易相关联的区块交易验重结果；
交易缓存查找模块109，用于若区块交易验重结果指示目标区块中的待处理交易的交易属性为重复交易属性，则基于第四交易验重策略在第一节点的交易缓存查找与待处理交易相匹配的交易，若在交易缓存中查找到与待处理交易相匹配的交易，则拒绝接收第二节点广播的目标区块。
可选的，标识相同确定模块110，用于若初始比较结果指示待处理交易的交易标识与目标区块中的关键交易的交易标识相同，且确定目标区块中不存在待处理交易的下一交易，则确定目标区块中的每个交易均为非重复交易；
哈希值获取模块111，用于通过交易验重器获取目标区块中的每个交易的交易哈希值，基于每个交易的交易哈希值更新交易验重器中的位数组；每个交易的交易哈希值是由交易验重器中的K个哈希函数确定的。
其中，交易获取模块100、第一验重模块200、映射值确定模块300和第一结果确定模块400的具体实现方式，可以参见上述图3所对应实施例中对步骤S101-步骤S104的描述，这里将不再继续进行赘述。可选的，第一关系确定模块500、第一目标确定模块600、第一目标保存模块700、第二关系确定模块800、第二验重模块900、交易拒绝模块101、第二目标确定模块102、目标映射值确定模块103、元素更新模块104的具体实现方式，可以参见上述图6所对应实施例中对步骤S201-步骤S216的描述，这里将不再继续进行赘述。可选的，交易标识获取模块105、交易标识比较模块106、标识不同确定模块107、区块验重结果确定模块108、交易缓存查找模块109、标识相同确定模块110和哈希值获取模块111的具体实现方式，可以参见上述图9或者图10所对应实施例对第三交易验重策略和第四交易验重策略的描述，这里将不再继续进行赘述。可以理解的是，对采用相同方法的有益效果描述，也 不再进行赘述。
进一步地，请参见图12，图12是本申请实施例提供的一种计算机设备的结构示意图。如图12所示，计算机设备1000可以应用于上述图1对应实施例中的区块链节点，计算机设备1000可以包括：处理器1001，网络接口1004和存储器1005，此外，计算机设备1000还可以包括：用户接口1003，和至少一个通信总线1002。其中，通信总线1002用于实现这些组件之间的连接通信。其中，用户接口1003可以包括显示屏(Display)、键盘(Keyboard)，可选用户接口1003还可以包括标准的有线接口、无线接口。网络接口1004可选的可以包括标准的有线接口、无线接口(如WI-FI接口)。存储器1005可以是高速RAM存储器，也可以是非不稳定的存储器(non-volatile memory)，例如至少一个磁盘存储器。存储器1005可选的还可以是至少一个位于远离前述处理器1001的存储装置。如图12所示，作为一种计算机存储介质的存储器1005中可以包括操作系统、网络通信模块、用户接口模块以及设备控制应用程序。
该计算机设备1000中的网络接口1004还可以提供网络通讯功能，且可选用户接口1003还可以包括显示屏(Display)、键盘(Keyboard)。在图12所示的计算机设备1000中，网络接口1004可提供网络通讯功能；而用户接口1003主要用于为用户提供输入的接口；而处理器1001可以用于调用存储器1005中存储的设备控制应用程序，以执行前文图3或图6或者图9所对应实施例中对交易验重方法的描述，也可执行前文图11所对应实施例中对交易验重装置1的描述，在此不再赘述。另外，对采用相同方法的有益效果描述，也不再进行赘述。
此外，这里需要指出的是：本申请实施例还提供了一种计算机存储介质，且计算机存储介质中存储有前文提及的交易验重装置1所执行的计算机程序，且计算机程序包括程序指令，当处理器执行程序指令时，能够执行前文图3、图6或图9所对应实施例中对交易验重方法的描述，因此，这里将不再进行赘述。另外，对采用相同方法的有益效果描述，也不再进行赘述。对于本申请所涉及的计算机存储介质实施例中未披露的技术细节，请参照本申请方法实施例的描述。
本领域普通技术人员可以理解实现上述实施例方法中的全部或部分流程，是可以通过计算机程序来指令相关的硬件来完成，的程序可存储于一计算机可读取存储介质中，该程序在执行时，可包括如上述各方法的实施例的流程。其中，的存储介质可为磁碟、光盘、只读存储记忆体(Read-Only Memory，ROM)或随机存储记忆体(Random Access Memory，RAM)等。
以上所揭露的仅为本申请较佳实施例而已，当然不能以此来限定本申请之权利范围，因此依本申请权利要求所作的等同变化，仍属本申请所涵盖的范围。

Claims (17)

  1. 一种交易验重方法，所述方法由区块链网络中的第一节点执行，所述第一节点中部署有交易验重器，所述方法包括：
    获取待上链至所述区块链网络的待处理交易；
    在通过所述交易验重器对所述待处理交易进行第一交易验重时，获取所述交易验重器的位数组和K个哈希函数，将获取到的位数组作为所述待处理交易对应的待查询位数组；所述待查询位数组中包括M个数组元素，所述M个数组元素中包括第一数组元素；所述M为大于1的整数，所述K为小于所述M的正整数；
    基于所述K个哈希函数，将所述待处理交易映射至所述待查询位数组的K个目标标识位置；在所述M个数组元素中，将所述K个目标标识位置上的数组元素作为所述K个目标标识位置上的交易映射值；
    确定所述第一数组元素与所述K个目标标识位置上的交易映射值之间的关联关系，基于所述关联关系，得到对所述待处理交易进行第一交易验重的第一交易验重结果。
  2. 根据权利要求1所述的方法，在所述获取待上链至所述区块链网络的待处理交易时，所述方法还包括：
    确定所述待处理交易的交易来源属性；所述交易来源属性用于指示所述交易验重器对所述待处理交易进行交易验重时使用的交易验重策略。
  3. 根据权利要求2所述的方法，若所述交易来源属性为第一来源属性，则所述交易验重策略包括与所述第一节点的交易池相关联的第一交易验重策略；所述第一来源属性用于表征所述待处理交易为交易添加请求中的交易；所述交易添加请求是与所述第一节点相关联的区块链客户端发送的；
    所述在通过所述交易验重器对所述待处理交易进行第一交易验重时，获取所述交易验重器的位数组和K个哈希函数，将获取到的位数组作为所述待处理交易对应的待查询位数组，包括：
    在通过所述交易验重器基于所述第一交易验重策略对所述待处理交易进行第一交易验重时，从所述交易验重器中获取数组长度为M的位数组，并获取与所述数组长度为M的位数组相关联的K个哈希函数；在所述数组长度为M的位数组中，所述交易验重器的验重集合中的验重元素映射的K个关键标识位置上的数组元素均为第二数组元素；一个关键标识位置为将所述验重元素通过一个哈希函数进行哈希位置映射后得到的标识位置；
    在所述数组长度为M的位数组中，将M个数组元素中除所述第二数组元素之外的数组元素作为第一数组元素；所述第一数组元素对应的标识位置不同于所述第二数组元素对应的标识位置，且所述第一数组元素的元素数量与所述第二数组元素的元素数量之和为所述M；
    将由所述第一数组元素和所述第二数组元素构成的位数组作为所述待处 理交易对应的待查询位数组。
  4. 根据权利要求1所述的方法，所述关联关系包括第一关联关系，所述第一关联关系用于表征所述K个目标标识位置上的交易映射值中存在与所述第一数组元素相同的交易映射值；
    所述方法还包括：
    若所述第一交易验重结果指示所述关联关系为所述第一关联关系，则确定所述待处理交易不属于所述交易验重器的验重集合中的验重元素，且控制所述交易验重器输出所述待处理交易的交易属性为非重复交易属性；
    将具有所述非重复交易属性的待处理交易确定为待保存至所述第一节点的交易池的第一目标交易。
  5. 根据权利要求4所述的方法，所述方法还包括：
    在将所述第一目标交易保存至所述第一节点的交易池时，将所述K个目标标识位置上与所述第一数组元素相同的交易映射值作为第一目标交易映射值，且在所述待查询位数组中，将所述第一目标交易映射值对应的目标标识位置上的数组元素由所述第一数组元素更新为第二数组元素。
  6. 根据权利要求1所述的方法，所述关联关系包括第二关联关系，所述第二关联关系用于表征所述K个目标标识位置上的交易映射值中不存在与所述第一数组元素相同的交易映射值；
    所述方法还包括：
    若所述第一交易验重结果指示所述关联关系为所述第二关联关系，则获取与所述第一节点的交易池相关联的第二交易验重策略；
    基于所述第二交易验重策略对所述待处理交易进行第二交易验重，得到第二交易验重结果。
  7. 根据权利要求6所述的方法，所述基于所述第二交易验重策略对所述待处理交易进行第二交易验重，得到第二交易验重结果，包括：
    基于所述第二交易验重策略，在所述第一节点的交易池中查找与所述待处理交易相匹配的第一历史交易；
    若在所述第一节点的交易池中查找到与所述待处理交易相匹配的第一历史交易，则确定所述待处理交易的交易属性为重复交易属性，将具备所述重复交易属性的待处理交易作为与所述第二交易验重策略相关联的第一类重复交易；
    将所述第一类重复交易作为对所述待处理交易进行第二交易验重后的第二交易验重结果。
  8. 根据权利要求7所述的方法，所述方法还包括：
    若在所述第一节点的交易池中未查找到与所述待处理交易相匹配的第一历史交易，则将所述待处理交易的交易属性确定为第一非重复交易属性，将具备所述第一非重复交易属性的待处理交易作为与所述第二交易验重策略相 关联的第一过渡验重结果；
    基于所述第一过渡验重结果，将具备所述第一非重复交易属性的待处理交易作为第一过渡交易，在所述第一节点的交易缓存中查找与所述第一过渡交易匹配的第二历史交易；
    若在所述第一节点的交易缓存中查找到与所述第一过渡交易相匹配的第二历史交易，则确定所述第一过渡交易的交易属性为重复交易属性，将具备所述重复交易属性的第一过渡交易作为与所述第二交易验重策略相关联的第二类重复交易；
    将所述第二类重复交易作为对所述待处理交易进行第二交易验重后的第二交易验重结果。
  9. 根据权利要求8所述的方法，所述方法还包括：
    若在所述第一节点的交易缓存中未查找到与所述第一过渡交易相匹配的第二历史交易，则确定所述第一过渡交易的交易属性为第二非重复交易属性，将具备所述第二非重复交易属性的第一过渡交易作为与所述第二交易验重策略相关联的第二过渡验重结果；
    基于所述第二过渡验重结果，将具备所述第二非重复交易属性的第一过渡交易作为第二过渡交易，在与所述第一节点相关联的区块链数据库中查找与所述第二过渡交易相匹配的第三历史交易；
    若在所述区块链数据库中查找到与所述第二过渡交易相匹配的第三历史交易，则确定所述第二过渡交易的交易属性为重复交易属性，将具备所述重复交易属性的第二过渡交易作为与所述第二交易验重策略相关联的第三类重复交易；
    将所述第三类重复交易作为对所述待处理交易进行第二交易验重后的第二交易验重结果。
  10. 根据权利要求6至9任一项所述的方法，所述方法还包括：
    若所述第二交易验重结果指示所述待处理交易的交易属性为重复交易属性，则将所述待处理交易确定为重复交易，且拒绝将所述重复交易添加至所述第一节点的交易池。
  11. 根据权利要求6至9任一项所述的方法，所述方法还包括：
    若所述第二交易验重结果指示所述待处理交易的交易属性为非重复交易属性，则基于具有所述非重复交易属性的待处理交易，确定用于添加至所述第一节点的交易池的第二目标交易，且在所述第一节点的交易池中保存所述第二目标交易；
    在将所述第二目标交易插入至所述交易验重器的验重集合时，将所述K个目标标识位置上的交易映射值作为第二目标交易映射值；
    控制所述交易验重器将所述待查询位数组中所述第二目标交易映射值对应的目标标识位置上的数组元素更新为第二数组元素，将更新后的待查询位 数组作为目标位数组。
  12. 根据权利要求2所述的方法，若所述交易来源属性为第二来源属性，则所述交易验重策略包括与所述第一节点的交易缓存相关联的第三交易验重策略和第四交易验重策略；所述第二来源属性用于表征所述待处理交易为所述区块链网络中的第二节点广播的目标区块中的交易；所述目标区块中的每个交易对应一个交易标识，且一个交易标识用于表征一个交易在所述目标区块中的打包顺序；
    所述方法还包括：
    基于所述第三交易验重策略，获取所述目标区块中的关键交易的交易标识；所述关键交易为所述目标区块包括的N个交易中具有最大打包顺序的交易；所述N为正整数；
    将所述待处理交易的交易标识与所述关键交易的交易标识进行比较，得到初始比较结果；
    若所述初始比较结果指示所述待处理交易的交易标识与所述目标区块中的关键交易的交易标识不相同，则确定存在所述待处理交易的下一交易；
    通过所述交易验重器，对所述目标区块中的所述待处理交易进行块内交易验重，得到与所述待处理交易相关联的区块交易验重结果；
    若所述区块交易验重结果指示所述目标区块中的所述待处理交易的交易属性为重复交易属性，则基于所述第四交易验重策略，在所述第一节点的交易缓存查找与所述待处理交易相匹配的交易，若在所述交易缓存中查找到与所述待处理交易相匹配的交易，则拒绝接收所述第二节点广播的所述目标区块。
  13. 根据权利要求12所述的方法，所述方法还包括：
    若所述初始比较结果指示所述待处理交易的交易标识与所述目标区块中的关键交易的交易标识相同，且确定所述目标区块中不存在所述待处理交易的下一交易，则确定所述目标区块中的每个交易均为非重复交易；
    通过所述交易验重器，获取所述目标区块中的每个交易的交易哈希值，基于所述每个交易的交易哈希值更新所述交易验重器中的位数组；所述每个交易的交易哈希值是由所述交易验重器中的所述K个哈希函数确定的。
  14. 一种交易验重装置，所述装置包括：
    交易获取模块，用于获取待上链至区块链网络的待处理交易；
    第一验重模块，用于在通过交易验重器对所述待处理交易进行第一交易验重时，获取所述交易验重器的位数组和K个哈希函数，将获取到的位数组作为所述待处理交易对应的待查询位数组；所述待查询位数组中包括M个数组元素，所述M个数组元素中包括第一数组元素；所述M为大于1的整数，所述K为小于所述M的正整数；
    映射值确定模块，用于基于所述K个哈希函数，将所述待处理交易映射 至所述待查询位数组的K个目标标识位置；在所述M个数组元素中，将所述K个目标标识位置上的数组元素作为所述K个目标标识位置上的交易映射值；
    第一结果确定模块，用于确定所述第一数组元素与所述K个目标标识位置上的交易映射值之间的关联关系，基于所述关联关系，得到对所述待处理交易进行第一交易验重的第一交易验重结果。
  15. 一种计算机设备，包括：处理器和存储器；
    所述处理器与存储器相连，其中，所述存储器用于存储计算机程序，所述处理器用于调用所述计算机程序，以使得所述计算机设备执行权利要求1-13任一项所述的方法。
  16. 一种计算机可读存储介质，所述计算机可读存储介质中存储有计算机程序，该计算机程序适于由处理器加载并执行，以使得具有所述处理器的计算机设备执行权利要求1-13任一项所述的方法。
  17. 一种计算机程序产品，包括指令，当其在计算机上运行时，使得计算机实现如权利要求1-13中任一项所述的方法。
PCT/CN2022/090110 2021-05-14 2022-04-29 一种交易验重方法、装置、设备以及介质 WO2022237569A1 (zh)

Priority Applications (2)

Application Number Priority Date Filing Date Title
EP22806537.1A EP4216130A4 (en) 2021-05-14 2022-04-29 METHOD AND DEVICE FOR VERIFYING TRANSACTION REPEATS AND DEVICE AND MEDIUM
US18/073,355 US20230102617A1 (en) 2021-05-14 2022-12-01 Repeat transaction verification method, apparatus, and device, and medium

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
CN202110526205.3A CN112950211B (zh) 2021-05-14 2021-05-14 一种交易验重方法、装置、设备以及介质
CN202110526205.3 2021-05-14

Related Child Applications (1)

Application Number Title Priority Date Filing Date
US18/073,355 Continuation US20230102617A1 (en) 2021-05-14 2022-12-01 Repeat transaction verification method, apparatus, and device, and medium

Publications (1)

Publication Number Publication Date
WO2022237569A1 true WO2022237569A1 (zh) 2022-11-17

Family

ID=76233854

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/CN2022/090110 WO2022237569A1 (zh) 2021-05-14 2022-04-29 一种交易验重方法、装置、设备以及介质

Country Status (4)

Country Link
US (1) US20230102617A1 (zh)
EP (1) EP4216130A4 (zh)
CN (1) CN112950211B (zh)
WO (1) WO2022237569A1 (zh)

Families Citing this family (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN113010115B (zh) * 2021-03-18 2022-11-22 腾讯科技（深圳）有限公司 区块链节点中的数据处理方法及相关设备
CN112950211B (zh) * 2021-05-14 2021-07-30 腾讯科技（深圳）有限公司 一种交易验重方法、装置、设备以及介质
CN116599973B (zh) * 2023-07-11 2023-09-26 天津卓朗昆仑云软件技术有限公司 基于bt服务加速组件的数据传输方法和装置

Citations (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN107357862A (zh) * 2017-06-30 2017-11-17 中国联合网络通信集团有限公司 话单排重方法及装置
CN108874803A (zh) * 2017-05-09 2018-11-23 腾讯科技（深圳）有限公司 数据存储方法、装置及存储介质
CN110503558A (zh) * 2019-08-29 2019-11-26 深圳前海微众银行股份有限公司 一种基于区块链系统的处理方法及装置
US10565192B2 (en) * 2017-08-01 2020-02-18 International Business Machines Corporation Optimizing queries and other retrieve operations in a blockchain
CN110880147A (zh) * 2019-11-22 2020-03-13 腾讯科技（深圳）有限公司 一种交易处理方法、相关设备及计算机存储介质
CN112667749A (zh) * 2021-03-16 2021-04-16 腾讯科技（深圳）有限公司 一种数据处理方法、装置、设备及存储介质
CN112950211A (zh) * 2021-05-14 2021-06-11 腾讯科技（深圳）有限公司 一种交易验重方法、装置、设备以及介质

Family Cites Families (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN107247773B (zh) * 2017-06-07 2018-05-15 北京邮电大学 一种基于区块链的在分布式数据库中进行交易查询的方法
GB201711879D0 (en) * 2017-07-24 2017-09-06 Nchain Holdings Ltd Computer-implemented system and method
JP2019145925A (ja) * 2018-02-16 2019-08-29 株式会社ｂｉｔＦｌｙｅｒ ブロックチェーン・ネットワークにおいてトランザクションを検証するための方法及び当該ネットワークを構成するためのノード
CN108768966B (zh) * 2018-05-14 2019-05-03 北京邮电大学 区块链平台和成员节点以及节点身份认证方法
US11775479B2 (en) * 2018-05-24 2023-10-03 Luther Systems Us Incorporated System and method for efficient and secure private similarity detection for large private document repositories
CN111640012A (zh) * 2019-03-01 2020-09-08 中国银联股份有限公司 一种区块链交易追溯的方法及装置
CN110704438B (zh) * 2019-09-26 2023-10-03 深圳前海微众银行股份有限公司 一种区块链中布隆过滤器的生成方法及装置

Patent Citations (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN108874803A (zh) * 2017-05-09 2018-11-23 腾讯科技（深圳）有限公司 数据存储方法、装置及存储介质
CN107357862A (zh) * 2017-06-30 2017-11-17 中国联合网络通信集团有限公司 话单排重方法及装置
US10565192B2 (en) * 2017-08-01 2020-02-18 International Business Machines Corporation Optimizing queries and other retrieve operations in a blockchain
CN110503558A (zh) * 2019-08-29 2019-11-26 深圳前海微众银行股份有限公司 一种基于区块链系统的处理方法及装置
CN110880147A (zh) * 2019-11-22 2020-03-13 腾讯科技（深圳）有限公司 一种交易处理方法、相关设备及计算机存储介质
CN112667749A (zh) * 2021-03-16 2021-04-16 腾讯科技（深圳）有限公司 一种数据处理方法、装置、设备及存储介质
CN112950211A (zh) * 2021-05-14 2021-06-11 腾讯科技（深圳）有限公司 一种交易验重方法、装置、设备以及介质

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
See also references of EP4216130A4 *

Also Published As

Publication number Publication date
CN112950211B (zh) 2021-07-30
US20230102617A1 (en) 2023-03-30
EP4216130A4 (en) 2024-04-24
CN112950211A (zh) 2021-06-11
EP4216130A1 (en) 2023-07-26

Similar Documents

Publication Publication Date Title
WO2022237569A1 (zh) 一种交易验重方法、装置、设备以及介质
US11030217B2 (en) Blockchain implementing cross-chain transactions
US11194837B2 (en) Blockchain implementing cross-chain transactions
CN113094396B (zh) 基于节点内存的数据处理方法、装置、设备以及介质
US11018980B2 (en) Data-interoperability-oriented trusted processing method and system
CN112005264A (zh) 实施跨链事务的区块链
CN113972986B (zh) 基于区块链的工业互联网标识信息解析方法以及相关装置
US20150215405A1 (en) Methods of managing and storing distributed files based on information-centric network
EP3794770B1 (en) Shared blockchain data storage based on error correction code
WO2021073156A1 (zh) 短链接的生成方法、服务器、存储介质及计算机设备
WO2023045617A1 (zh) 一种交易数据处理方法、装置、设备以及介质
CN113422733B (zh) 区块链的业务处理方法、装置、计算机设备及存储介质
Chen Flowchain: A distributed ledger designed for peer-to-peer iot networks and real-time data transactions
US20230289782A1 (en) Smart contract-based data processing
US20230078541A1 (en) Data storage method and apparatus based on blockchain network
AU2019381980A1 (en) Taking snapshots of blockchain data
US20230370285A1 (en) Block-chain-based data processing method, computer device, computer-readable storage medium
Zhao et al. A novel enhanced lightweight node for blockchain
CN110597922A (zh) 数据处理方法、装置、终端及存储介质
WO2022141024A1 (zh) 基于区块链技术的业务交易方法、系统及存储介质
CN110855810B (zh) 一种nat转换方法、装置、网络安全设备及存储介质
WO2023207529A1 (zh) 数据处理方法、装置及设备、介质、产品
WO2023142605A1 (zh) 一种基于区块链的数据处理方法和相关装置
WO2023221350A1 (zh) 基于区块链的代码版权登记系统、方法及平台
Zhang et al. Research on enterprise DNS security scheme based on blockchain technology

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: 22806537

Country of ref document: EP

Kind code of ref document: A1

ENP Entry into the national phase

Ref document number: 2022806537

Country of ref document: EP

Effective date: 20230420

NENP Non-entry into the national phase

Ref country code: DE