Transaction verification method and system based on block chain

Abstract

The invention discloses a transaction verification method and system based on a block chain, and relates to the technical field of block chains. Firstly, a transaction initiator constructs, signs and broadcasts a transaction, a node receives the transaction pool and then plays the transaction pool, the transaction pool is verified through formats, grammar and digital signatures, and a follow-up process is started if the transaction pool passes verification; checking the balance of the sender, operating and comparing the transaction cost based on the UTXO model and the account model, simultaneously carrying out double-spam checking, and carrying out corresponding processing on abnormal transactions; under different consensus mechanisms, corresponding nodes construct new blocks according to rules, nodes in the whole network verify the new blocks and included transactions, and if verification is passed, the new blocks are added into a main chain to enable the transactions to take effect; and finally, updating an account book state when the transaction is confirmed to be effective and new blocks are added, and providing an interface for conveniently querying transaction details and historical records. The method guarantees the safety and accuracy of transactions, and improves the reliability and traceability of the block chain system.

Description

Technical Field

[0001] The present invention relates to the field of blockchain technology, and more specifically, to a transaction verification method and system based on blockchain. Background Art

[0002] With the development of the Internet economy, electronic payments have become increasingly popular, and the scale of online transactions has expanded rapidly. However, traditional centralized ledgers are susceptible to single point failures and may be subject to the risk of insider manipulation of records, making it difficult to meet the growing demand for security and trust. In recent years, the distributed ledger, or blockchain, has emerged as a decentralized database structure that ensures system security through cryptography and implements reliable transaction processing under a multi-party consensus mechanism. It has received widespread attention from all walks of life and has been initially exploratory applied in multiple industries.

[0003] With the continuous expansion of blockchain technology applications in many fields such as digital currency and supply chain finance, the security and verification efficiency of blockchain transactions have become crucial issues. Traditional transaction verification methods often rely on centralized institutions (such as bank transaction processing systems), which have defects such as single point failure risks, high trust costs, and easy data tampering. However, when facing massive transactions, existing blockchain transaction verification methods and systems have problems such as complex verification processes, low consensus efficiency, and insufficient adaptability to special transaction rules, which affect the promotion and use experience of blockchain technology in actual application scenarios. Therefore, there is an urgent need for a more optimized, efficient and flexible blockchain-based transaction verification method and system. Summary of the invention

[0004] In view of the deficiencies in the prior art, the object of the present invention is to provide a transaction verification method and system based on blockchain.

[0005] To achieve the above object, the present invention provides the following technical solutions:

[0006] In a first aspect, a transaction verification method based on blockchain comprises the following steps:

[0007] Step 1: After the transaction initiator constructs and digitally signs the transaction on the local client, it broadcasts the transaction to the blockchain network nodes through the P2P network protocol;

[0008] Step 2: The blockchain network node receives the broadcast transaction and stores it in the local transaction pool. After format, syntax and digital signature verification, it will be discarded if verification fails, and will enter the subsequent process if verification passes;

[0009] Step 3: Check the sender's account balance and perform double-spending checks. Transactions with insufficient balance or possible double-spending are deemed illegal or marked as abnormal.

[0010] Step 4: Under different consensus mechanisms, the corresponding nodes build new blocks according to the rules, and all network nodes verify the new blocks and the transactions contained therein. If they pass, the new blocks will be added to the main chain to make the transactions effective;

[0011] Step 5: After confirming that the transaction is valid and adding a new block, the ledger status is updated and an interface is provided to facilitate querying transaction details and historical records.

[0012] Preferably, the step 1 comprises:

[0013] The transaction initiator constructs a transaction on the local client that includes the sender's blockchain address, the receiver's blockchain address, the transaction amount, a unique transaction identifier, and optional additional information;

[0014] The initiator uses the corresponding private key to digitally sign the transaction content, and processes the generated digital signature to obtain a transaction data packet;

[0015] The digitally signed transaction data packet is sent to the nodes in the blockchain network and broadcasted via the P2P network protocol.

[0016] Preferably, the step 2 comprises:

[0017] The nodes in the blockchain network receive the broadcasted transaction information and temporarily store it in the local transaction pool;

[0018] Check the format and syntax of the transaction to ensure that it complies with the structure and type and length requirements of each field specified in the blockchain protocol;

[0019] The sender's public key is used to verify whether the digital signature on the transaction is correct. If the verification fails, the transaction is discarded. If the verification passes, the subsequent verification process is entered.

[0020] Preferably, the step 3 comprises:

[0021] Check whether the sender's account balance is sufficient to pay the transaction amount and handling fee. If the balance is insufficient, the transaction is deemed illegal and removed;

[0022] Double-spending checks are performed. For UTXO-based blockchains, the UTXO involved in the transaction is checked to see if it has been referenced in other transactions to be confirmed. For account-based blockchains, corresponding mechanisms are used to ensure that the same funds will not be involved in multiple concurrent transactions at the same time. Transactions with the possibility of double spending will not be further processed and will be marked as abnormal.

[0023] Preferably, the step 4 comprises:

[0024] In a blockchain that uses the proof-of-work consensus mechanism, miner nodes select legitimate transactions from the transaction pool to build new blocks, and make the hash value of the block header meet the conditions by finding a random number that meets the difficulty target; under the proof-of-stake consensus mechanism, validator nodes that meet the corresponding conditions are responsible for selecting transactions to build new blocks and follow the consensus rules.

[0025] After receiving the new block, all nodes in the network will once again perform format and syntax checks, digital signature verification, and transaction legitimacy checks on all transactions contained in the new block, and verify whether the new block itself meets the requirements of the consensus mechanism. If it passes the verification, the new block will be added to the blockchain main chain, and the transactions in the new block will be finally confirmed and take effect.

[0026] Preferably, the step 5 comprises:

[0027] After confirming that the transaction is valid and adding the new block, updating the locally maintained ledger state according to the transaction content;

[0028] Provide corresponding interfaces or tools to allow users and regulators to query specific transaction details and historical records based on transaction identifiers and blockchain addresses.

[0029] In the second aspect, a transaction verification system based on blockchain includes a transaction broadcast module, a transaction verification module, an account and double-spending check module, a block construction and verification module, and a ledger management and query module;

[0030] Transaction broadcast module: After the transaction initiator constructs the transaction and digitally signs it on the local client, it broadcasts the transaction to the blockchain network nodes through the P2P network protocol;

[0031] The transaction verification module verifies the format syntax and digital signature of the transaction, and decides whether to discard the transaction or allow it to enter the subsequent process based on the verification results;

[0032] The account and double-spending check module checks the sender's account balance and performs double-spending checks, and determines and marks transactions with insufficient balance or possible double-spending.

[0033] The block construction and verification module coordinates the corresponding nodes to build new blocks according to different consensus mechanisms, and organizes all network nodes to verify the new blocks and the transactions contained therein, and adds the new blocks to the main chain after the verification is passed;

[0034] The ledger management and query module updates the ledger status after the transaction is confirmed to be valid and a new block is added, and provides an interface for convenient query of transaction details and historical records.

[0035] Compared with the prior art, the present invention has the following beneficial effects:

[0036] 1. In the present invention, after the transaction is broadcasted from the initiator, it must go through multiple rounds of strict verification processes such as format syntax check, digital signature verification, sender account balance check and double-spending check. If any link does not meet the requirements, the transaction will be processed accordingly (such as discarded or marked as abnormal). This greatly reduces the possibility of erroneous transactions and illegal transactions entering the blockchain main chain, improves the accuracy of transactions that are finally confirmed to be effective, ensures that every transaction recorded on the blockchain is legal and compliant and conforms to business logic, and enhances the reliability of the entire transaction system.

[0037] 2. In the present invention, two consensus mechanisms, PoW and PoS, are adopted. Different consensus mechanisms have their own advantages and applicable scenarios. The PoW mechanism ensures the fairness and decentralization of the generation of new blocks through computing power competition, and is suitable for scenarios with extremely high security requirements and a certain tolerance for resource consumption; the PoS mechanism determines the accounting rights based on the rights and interests held by the nodes, which is relatively more energy-efficient and can also ensure the security and stability of the network to a certain extent, and is suitable for some application scenarios that pay more attention to resource utilization efficiency. The system can select the appropriate consensus mechanism according to specific needs, so that the blockchain network can operate stably and reliably in different business scenarios and continue to provide services to users.

[0038] 3. In the present invention, after confirming that the transaction is valid and adding the block, the state of the locally maintained account book will be updated in a timely manner, and the corresponding interface will be provided for users, regulatory agencies, etc. to query specific transaction details and historical records based on information such as transaction identifiers and blockchain addresses. This allows each transaction to be clearly recorded on the blockchain, just like a traditional account book that can be traced back and viewed at any time. Whether it is an ordinary user checking his or her own transaction status or a regulatory agency conducting an audit or investigation, the required transaction information can be easily obtained, ensuring the transparency and traceability of blockchain transactions, helping to enhance the trust of all parties in the blockchain system, and also meeting the requirements of compliance supervision.

[0039] 4. In the present invention, the entire blockchain network is based on distributed ledger technology. Once the transaction information is verified and added to the main chain, it is difficult to be tampered with. All nodes keep the same copy of the ledger, and the content of the ledger is open and transparent (although the privacy-related parts such as private keys are confidential, the key information of the transaction itself is traceable). This feature enables all parties involved in the transaction and external supervisors to trust the authenticity and integrity of the transaction records, promotes the application and promotion of blockchain in more fields (such as supply chain finance, traceability systems, etc.), and lays the foundation for building a trust ecosystem based on blockchain. BRIEF DESCRIPTION OF THE DRAWINGS

[0040] Figure 1 A flowchart of a transaction verification method based on blockchain is proposed for the present invention;

[0041] Figure 2 A flowchart of a transaction verification system based on blockchain is proposed for the present invention. DETAILED DESCRIPTION

[0042] The embodiments further illustrate a blockchain-based transaction verification method and system proposed in the present invention.

[0043] Reference Figure 1 , a transaction verification method based on blockchain, comprising the following steps:

[0044] Step 1: After the transaction initiator constructs and digitally signs the transaction on the local client, it broadcasts the transaction to the blockchain network nodes through the P2P network protocol;

[0045] Step 2: The blockchain network node receives the broadcast transaction and stores it in the local transaction pool. After format, syntax and digital signature verification, it will be discarded if verification fails, and will enter the subsequent process if verification passes;

[0046] Step 3: Check the sender's account balance and perform double-spending checks. Transactions with insufficient balance or possible double-spending are deemed illegal or marked as abnormal.

[0047] Step 4: Under different consensus mechanisms, the corresponding nodes build new blocks according to the rules, and all network nodes verify the new blocks and the transactions contained therein. If they pass, the new blocks will be added to the main chain to make the transactions effective;

[0048] Step 5: After confirming that the transaction is valid and adding a new block, the ledger status is updated and an interface is provided to facilitate querying transaction details and historical records.

[0049] The step 1 comprises:

[0050] The transaction initiator constructs a transaction on the local client that includes the sender's blockchain address, the receiver's blockchain address, the transaction amount, a unique transaction identifier, and optional additional information;

[0051] The unique transaction identifier is generated, in the field of blockchain, by using the SHA-256 hash algorithm. The SHA-256 will process input data of any length and output a fixed 256-bit (32-byte) hash value, which is usually displayed in the form of a hexadecimal string.

[0052] Select key transaction information as input data, including sender address, receiver address, transaction amount and timestamp; concatenate these information into a data string and then send it as input to the SHA-256 hash algorithm for hash operation;

[0053] First, the input data is padded so that its length meets the specific multiple required by the algorithm (SHA-256 requires that the remainder of the input data length after modulo 512 bits is 448 bits, and if it is less than that, it is filled by a specific padding rule); then the padded data is divided into blocks of a fixed length of 512 bits (64 bytes) as the basic unit for subsequent iterative operations;

[0054] Set the initial hash value (also called the intermediate state value. There are 8 32-bit initial intermediate state values ​​in SHA-256. They are fixed constants used to start the entire calculation process);

[0055] For each divided 512-bit data block, a series of complex logic functions (including logical operations such as AND, OR, NOT, XOR, and nonlinear functions composed of arithmetic operations such as displacement and addition, such as Ch(x, y, z) = (x & y) ^ ((-x) & z) are some examples of functions, and all functions are not expanded in detail here) are used to calculate the current data block and the current intermediate state value, and the intermediate state value is continuously updated; this process will be repeated until all data blocks are involved in the calculation;

[0056] After the above iterative compression operation, the final 8 32-bit intermediate state values ​​are combined into a 256-bit hash value. Converting it into a hexadecimal string form gives us the transaction identifier we want.

[0057] The initiator uses the corresponding private key to digitally sign the transaction content, and processes the generated digital signature to obtain a transaction data packet;

[0058] Based on the ECDSA algorithm, the secp256k1 elliptic curve digital signature algorithm is used for digital signature to generate a set of temporary public and private key pairs;

[0059] Before the actual signature operation, the complete transaction content needs to be hashed and the SHA-256 hash algorithm is used to generate a fixed-length hash value. For example, assuming that the data string of the transaction content after being sorted is "TransactionData", the hash value obtained after the hash operation using the SHA-256 algorithm is recorded as "HashValue", that is: HashValue = SHA-256 (TransactionData);

[0060] The obtained private key itself may exist in the form of a string or byte array, but in the mathematical operation of the ECDSA algorithm, it needs to be converted into an integer form that meets the requirements of elliptic curve cryptography operations;

[0061] The digital signature operation process first selects a random number k and performs a point multiplication operation through the base point of the elliptic curve to obtain a point P on the elliptic curve. The horizontal coordinate value of the point is the value of r, that is, P = k*G, where G is the base point of the elliptic curve, and * represents the elliptic curve point multiplication operation; r = x(P)x(P) represents taking the horizontal coordinate value of point P and converting it into an integer form that meets the requirements;

[0062] Then, according to the private key d, the random number k, the hash value HashValue and the previously obtained r value, the s value is calculated by the formula: s = k^(-1)*(HashValue+d*r)mod n, where k^(-1) represents the multiplicative inverse element of k under modulus n, n is the order of the elliptic curve, and mod represents the modulus operation;

[0063] The final digital signature is an ordered pair consisting of two integers r and s, denoted as (r, s);

[0064] The generated digital signature (r, s) is appended to the original transaction information in accordance with the format and requirements specified by the blockchain system to form a complete transaction data packet with a digital signature.

[0065] The digitally signed transaction data packet is sent to the nodes in the blockchain network and broadcasted via the P2P network protocol.

[0066] The step 2 comprises:

[0067] The nodes in the blockchain network receive the broadcasted transaction information and temporarily store it in the local transaction pool;

[0068] Check the format and syntax of the transaction to ensure that it complies with the structure and type and length requirements of each field specified in the blockchain protocol;

[0069] Performing format and syntax checks on transactions includes checking structural integrity, verifying field type requirements, and verifying field length limits;

[0070] The structural integrity check includes the complete structural parts such as transaction version number, input list, output list and lock time, and the arrangement order of each part strictly complies with the specified requirements.

[0071] The verification of each field type requirement includes transaction version number type check, input list and subfield type check, output list and subfield type check, and lock time type check;

[0072] The transaction version number type check is specified as an integer type, which may be a 32-bit unsigned integer or other different formats (depending on the blockchain);

[0073] The input list and subfield type check include the previous transaction hash type check and the output index type; the previous transaction hash type, this field is generally a byte array type, and the byte length must comply with the standard length generated by a specific hash algorithm (for example, the hash value generated by the SHA-256 hash algorithm should be 32 bytes). During the check, it is necessary to confirm whether it is stored in the form of a byte array and whether the actual length is consistent with the specified length; the output index type, the output index should be an integer type, which is used to locate the specific position in the previous transaction output. It is necessary to check whether it can participate in the calculation as an integer and whether it complies with the definition range of the integer type of the blockchain (for example, the value range is between 0 and a positive integer, etc.). If it does not meet the integer requirement, then an error will occur when searching for the specific output corresponding to the source of funds in the subsequent search, and the transaction syntax will be incorrect;

[0074] The output list and subfield type check include the recipient blockchain address type check and the transfer amount type check; the recipient blockchain address type check, this field needs to be a string type that complies with the specific encoding rules of the blockchain. When checking, it is necessary to check whether the format of the string is correct, whether the characters are compliant, whether the length is within the specified range, etc. according to the address generation rules of the corresponding blockchain; the transfer amount type check, the transfer amount is usually expressed in the corresponding digital type according to the digital currency precision defined by the blockchain, to confirm whether it is a digital representation that meets the requirements and whether it can accurately reflect the amount involved in the transaction. If it is not the correct digital type or cannot accurately represent the amount under the specified precision, then the record of the amount of funds in the transaction is inaccurate and does not meet the grammatical requirements;

[0075] The lock time type check, if there is a lock time field, it should generally be an integer type, and have a value range and meaning specified by the corresponding blockchain protocol (such as representing a timestamp or time interval, etc.); check whether it meets the characteristics of an integer and whether it is within the specified value range. If the type is incorrect or exceeds the range, it does not meet the transaction syntax requirements because it cannot correctly reflect the restrictions on the transaction effectiveness time.

[0076] The verification of the length limit of each field includes transaction identifier length verification and blockchain address length verification; the transaction identifier length verification, the transaction identifier is generated by hashing the transaction key information, and it is necessary to check whether the actual transaction identifier length is strictly equal to the specified number of bytes. If the length is inconsistent, it does not meet the requirements; the blockchain address length verification, different blockchains have their own specified length ranges, and it is necessary to verify whether the lengths of the recipient and sender blockchain addresses are compliant based on the corresponding standards. For example, a blockchain stipulates that the minimum address length is L_min and the maximum is L_max, and the actual address length is recorded as 1_address. Then, it is judged by comparing the size relationship between 1_address and L_min and L_max; if 1_address<L_min or 1_address>L_max, it is determined that the blockchain address length does not meet the requirements, which further indicates that the transaction does not meet the grammatical specifications, because addresses that do not meet the length requirements cannot be accurately identified and processed in the blockchain network.

[0077] Use the sender's public key to verify whether the digital signature on the transaction is correct. If the verification fails, the transaction is discarded. If the verification passes, the subsequent verification process begins;

[0078] Get the sender's public key, recorded as PublicKey;

[0079] A digital signature usually consists of two key parts, generally denoted as r and s. The node needs to accurately extract the corresponding representation of r and s from the transaction data according to the specific field position specified by the blockchain protocol.

[0080] The verification logic based on the ECDSA algorithm is as follows:

[0081] First, extract all the complete contents of the transaction information except the digital signature, and then use the SHA-256 hash algorithm to perform a hash operation on these contents to obtain a hash value of a fixed length, recorded as HashValue;

[0082] According to the mathematical principle of the ECDSA algorithm, the verification operation is performed using the obtained sender's public key PublicKey, the r and s values ​​extracted from the digital signature, and the calculated HashValue.

[0083] Convert the public key (PublicKey) to the corresponding point coordinate representation on the elliptic curve (assuming it is (x_public, y_public)), then calculate the coordinates of point Q according to the ECDSA algorithm; let the base point of the elliptic curve be G, the order of the elliptic curve be n, first calculate the multiplication inverse of s under modulus n, denoted as s_inverse, the calculation principle is to find an integer such that s*s_inverse≡1(modn) (that is, the remainder of the product of s and s_inverse divided by n is 1, which is the definition of modular multiplication inverse in number theory); then, calculate the values ​​of the abscissa Q_x and ordinate Q_y of point Q, the calculation formula is as follows:

[0084] Q_x=(s_inverse*HashValue*G.x+r*x_public)modn

[0085] Q_y=(s_inverse*HashValue*G.y+r*y_public)modn

[0086] Where Gx and Gy represent the horizontal and vertical coordinates of the base point G, respectively, and x_public and y_public are the point coordinates corresponding to the public key;

[0087] Finally, the key to verification is to determine whether the horizontal coordinate of point Q (i.e., Q_x) is equal to the r value in the digital signature after being converted into a suitable integer form. The verification logic can be simply expressed as follows: If Q_x=r (here the values ​​on both sides are required to be compared under the same integer representation and operation rules to ensure the accuracy of the comparison), then the digital signature verification is successful, which means that the transaction is indeed initiated by the sender with the corresponding private key, and the transaction content has not been tampered with during the transmission process; conversely, if Q_x≠r, the digital signature verification fails, and the node will directly discard the transaction and will not process it further because the legality and authenticity of the transaction cannot be guaranteed.

[0088] The step 3 comprises:

[0089] Check whether the sender's account balance is sufficient to pay the transaction amount and handling fee. If the balance is insufficient, the transaction is deemed illegal and removed;

[0090] The blockchain based on the UTXO (unspent transaction output) model first uses the UTXO set to determine the sender, then calculates the available balance and compares it with the transaction amount and handling fee;

[0091] The UTXO set is used to determine the sender, specifically:

[0092] Traversing historical transaction records of the blockchain: The node needs to access the locally stored blockchain data, check each transaction information in order, and filter out the transaction records related to the sender's blockchain address;

[0093] Filter unspent transaction outputs: For each transaction related to the sender found, check its transaction output part; each transaction may have multiple outputs, each output has a corresponding status identifier, select those transaction outputs with a status identifier of "unspent"; these unspent transaction outputs are the UTXOs currently available to the sender; you can imagine it as finding the "money bags" that the sender has not used among many past transactions.

[0094] The calculation of available balance is specifically as follows:

[0095] Extract the amount of each UTXO: Extract the field value representing the amount from each record in the available UTXO set filtered out in the previous step; the amount of each UTXO is a specific amount of digital currency. The amounts of different UTXOs may be different, and they together constitute the funds that the sender can control;

[0096] Add up the amounts to get the total available balance: add up the amounts of all available UTXOs to get the sender's current total available balance; assuming that the available UTXO set is UTXO_Set = {UTXO1,UTXO2,…,UTXO n}, each UTXO i There is a corresponding amount i , then the total available balance Total_Balance calculation formula is: For example, the sender has 3 available UTXOs with amounts of 5 digital currency units, 3 digital currency units, and 2 digital currency units respectively. Then the total available balance obtained by accumulation is 5+3+2=10 digital currency units.

[0097] The comparison with the transaction amount and handling fee is as follows:

[0098] Get the transaction cost: Get the amount to be paid for this transaction (i.e., the transaction amount, set as Transaction_Amount) and the pre-set transaction fee (set as Fee), and add the two together to get the total cost of this transaction, i.e., Total_Cost = Transaction_Amount + Fee; for example, if the transaction amount is 8 digital currency units and the fee is set as 1 digital currency unit, then the total cost of this transaction is 8 + 1 = 9 digital currency units;

[0099] Balance comparison and judgment: Compare the calculated total available balance of the sender (Total_balance) with the total cost of this transaction (Total_Cost); if Total_balance≥Total_Cost, it means that the sender has enough money to pay for this transaction, and the transaction can enter the subsequent verification process; on the contrary, if Total_balance<Total_Cost, it means that the sender's balance is insufficient and cannot complete the transaction. At this time, the transaction is judged to be an illegal transaction, and the node will remove it from the local transaction pool to prevent it from continuing to spread in the blockchain network and participating in subsequent processing; for example, if the total available balance is 7 digital currency units and the total transaction cost is 9 digital currency units, the transaction is judged to be illegal and removed.

[0100] For blockchains based on the account model, the sender's account balance record is first queried, and then compared with the transaction amount and handling fee;

[0101] The query of the sender's account balance record is to search for the balance based on the address: the node uses the sender's blockchain address as an index (similar to using an account number to search for a bank account balance) in the account balance data storage maintained locally (which may be based on a database management system, or a specific key-value pair storage structure, etc.) to quickly locate and obtain the corresponding account balance value (set to Account_balance).

[0102] The comparison with the transaction amount and handling fee is as follows:

[0103] Get the transaction cost: first get the amount to be paid for this transaction (Transaction_Amount) and the set transaction fee (Fee), and calculate the total cost of this transaction Total_Cost = Transaction_Amount + Fee; for example, the transaction amount is 30 digital currency units and the fee is 2 digital currency units, then Total_Cost = 30 + 2 = 32 digital currency units;

[0104] Balance comparison: compare the obtained sender account balance (Account_balance) with the total cost of this transaction (Total_Cost); if Account_balance≥Total_Cost, it means that the money in the sender's account is enough to pay for this transaction, the transaction is legal, and the subsequent verification process can continue; if Account_balance<Total_Cost, it means that the balance is insufficient, the transaction is judged to be illegal, and the node will remove the transaction from the transaction pool; for example, if the account balance is 25 digital currency units and the total transaction cost is 32 digital currency units, the transaction is judged to be illegal and removed.

[0105] Double-spending checks are performed. For UTXO-based blockchains, the UTXO involved in the transaction is checked to see if it has been referenced in other pending transactions. For account-based blockchains, corresponding mechanisms are used to ensure that the same funds will not be involved in multiple concurrent transactions at the same time. Transactions with the possibility of double spending will not be further processed and will be marked as abnormal.

[0106] The blockchain based on the UTXO model first collects the input UTXO information of the transaction to be verified, and then checks the reference of UTXO in the transaction to be confirmed. If the transaction passes the double-spending check, the local UTXO reference status record is updated;

[0107] The above-mentioned collection of input UTXO information of the transaction to be verified, when a node receives a transaction to be verified, first parses the input part of the transaction; in the UTXO model, the input of the transaction will clearly point to the UTXO generated by some previous transactions, and each input contains two key pieces of information: the hash value (Transaction Hash) of the previous transaction and the output index (Output Index) in the previous transaction; for example, a transaction input may be represented as (TxHash123, 0), which means that it points to the 0th output in the previous transaction with a hash value of TxHash123;

[0108] The node extracts the UTXO identification information (i.e., the combination of the transaction hash value and the output index) involved in all the inputs of the transaction to be verified, forms a list, and prepares to check whether these UTXOs have been referenced in other transactions to be confirmed.

[0109] Regarding the check of the reference of UTXO in the transaction to be confirmed, the node maintains a local data structure (which can be a mapping table in memory, a database table, etc.) to record the usage of input UTXO of all transactions to be confirmed in the current network; the key of this data structure can be set to the identifier of UTXO (i.e., a combined string of the transaction hash value and the output index, such as "TxHash123_0"), and the value is a Boolean type, indicating whether the UTXO has been referenced by a transaction to be confirmed (for example, True means it has been referenced, and False means it has not been referenced);

[0110] For each UTXO identifier of the transaction to be verified collected in the previous step, the node queries the data structure maintained locally.

[0111] The local UTXO reference status record is updated. If all the input UTXOs of the transaction to be verified are not referenced by other transactions to be confirmed after inspection, it means that the transaction has temporarily passed the double-spending check. At this time, the node needs to update the locally maintained UTXO reference status record data structure, and mark the reference status corresponding to all UTXO identifiers involved in the transaction as "referenced" (that is, set to True), indicating that these UTXOs are participating in the current transaction to be verified, so as to avoid the problem of double-spending caused by repeated references to them by other subsequent transactions.

[0112] For blockchains based on the account model, first extract the sequence number of the transaction to be verified, then query the maximum sequence number of confirmed transactions of the same account, and finally check the sequence number order and double spending;

[0113] The node extracts the sequence number of the transaction to be verified from the received transaction data to be verified. In a blockchain based on an account model and using a sequence number mechanism, each transaction is accompanied by a sequence number, which is usually an integer, and the sequence number of the new transaction is required to be greater than the maximum sequence number of the confirmed transactions of the same account, so as to ensure the transaction order and avoid the double-spending problem.

[0114] To query the maximum sequence number of confirmed transactions of the same account, the node selects all confirmed transaction records of the account from the locally stored transaction record data structure (such as a database table, a transaction list in memory, etc.) according to the sender account address of the transaction to be verified; then searches for the maximum value of the sequence number field from these confirmed transaction records, and this maximum value is the maximum sequence number of confirmed transactions of the account (set to Max_Confirmed_Sequence_Number).

[0115] The sequence number order and double-spending situation are checked by comparing the sequence number of the transaction to be verified (set as Sequence_Number) with the maximum confirmed sequence number (Max_Confirmed_Sequence_Number) obtained by the query; under normal circumstances, Sequence_Number>Max_Confirmed_Sequence_Number should be satisfied, which means that the transaction is a new transaction initiated in sequence;

[0116] At the same time, the node also needs to check the changes in the account balance involved in the transaction (for example, check whether the account balance recorded locally has been deducted for the same amount in other unconfirmed transactions. If such repeated deductions exist, it may indicate a double-spending attempt); if Sequence_Number <= Max_Confirmed_Sequence_Number and abnormal situations such as repeated deductions in the account balance are found, it means that there may be a double-spending problem. At this time, the node will mark the transaction to be verified as abnormal and will not process it further.

[0117] The step 4 comprises:

[0118] In a blockchain that uses the Proof of Work (PoW) consensus mechanism, miner nodes select legitimate transactions from the transaction pool to build new blocks, and make the hash value of the block header meet the conditions by finding a random number that meets the difficulty target; under the Proof of Stake (PoS) consensus mechanism, verification nodes that meet the corresponding conditions are responsible for selecting transactions to build new blocks and follow the consensus rules.

[0119] After receiving the new block, all nodes in the network will once again perform format and syntax checks, digital signature verification, and transaction legitimacy checks on all transactions contained in the new block, and verify whether the new block itself meets the requirements of the consensus mechanism. If it passes the verification, the new block will be added to the blockchain main chain, and the transactions in the new block will be finally confirmed and take effect.

[0120] The process of finding a random number that meets the difficulty target (mining process) is as follows:

[0121] Perform the first hash operation: the miner takes the assembled new block header information (except the random number, all other field values ​​have been determined) as input, and uses the SHA-256 hash algorithm to perform a hash operation to obtain an initial block header hash value;

[0122] Compare hash value with difficulty target: Compare the obtained hash value with the difficulty target set by the current network. Taking Bitcoin as an example, the difficulty target is expressed as a specific value. The hash value is converted into a numerical value and compared with the numerical value of the difficulty target, as well as the number of consecutive 0s in the binary representation of the hash value to determine whether it meets the requirements. If it does not meet the difficulty target (for example, the first several bits of the hash value are required to be 0, but the corresponding positions in the front of the actually calculated hash value are not 0), the random number needs to be adjusted further.

[0123] Adjust the random number and repeat the hash operation: increase the value of the random number by 1 each time (other reasonable increment strategies can also be used), then re-hash the block header information containing the new random number, and get a new hash value again, and continue to compare it with the difficulty target; this process will be repeated continuously. Due to the randomness and irreversibility of the hash operation, miners need to try a large number of different random number values ​​until they find a random number that makes the calculated block header hash value meet the difficulty target set by the network.

[0124] The step 5 comprises:

[0125] After confirming that the transaction is valid and adding the new block, updating the locally maintained ledger state according to the transaction content;

[0126] Provide corresponding interfaces or tools to allow users and regulators to query specific transaction details and historical records based on transaction identifiers and blockchain addresses.

[0127] Reference Figure 2 , a transaction verification system based on blockchain, including a transaction broadcast module, a transaction verification module, an account and double-spending check module, a block construction and verification module, and a ledger management and query module;

[0128] Transaction broadcast module: After the transaction initiator constructs the transaction and digitally signs it on the local client, it broadcasts the transaction to the blockchain network nodes through the P2P network protocol;

[0129] The transaction verification module verifies the format syntax and digital signature of the transaction, and decides whether to discard the transaction or allow it to enter the subsequent process based on the verification results;

[0130] The account and double-spending check module checks the sender's account balance and performs double-spending checks, and determines and marks transactions with insufficient balance or possible double-spending.

[0131] The block construction and verification module coordinates the corresponding nodes to build new blocks according to different consensus mechanisms, and organizes all network nodes to verify the new blocks and the transactions contained therein, and adds the new blocks to the main chain after the verification is passed;

[0132] The ledger management and query module updates the ledger status after the transaction is confirmed to be valid and a new block is added, and provides an interface for convenient query of transaction details and historical records.

[0133] The above is only a preferred embodiment of the present invention, and the protection scope of the present invention is not limited to the above embodiments. All technical solutions under the concept of the present invention belong to the protection scope of the present invention. It should be pointed out that for ordinary technicians in this technical field, some improvements and modifications without departing from the principle of the present invention should also be regarded as the protection scope of the present invention.

Claims

1. A transaction verification method based on blockchain, characterized in that: The following steps are involved: Step 1: After the transaction initiator constructs and digitally signs the transaction on the local client, it broadcasts the transaction to the blockchain network nodes through the P2P network protocol; Step 2: The blockchain network node receives the broadcast transaction and stores it in the local transaction pool. After format, syntax and digital signature verification, it will be discarded if verification fails, and will enter the subsequent process if verification passes; Step 3: Check the sender's account balance and perform double-spending checks. Transactions with insufficient balance or possible double-spending are deemed illegal or marked as abnormal. Step 4: Under different consensus mechanisms, the corresponding nodes build new blocks according to the rules, and all network nodes verify the new blocks and the transactions contained therein. If they pass, the new blocks will be added to the main chain to make the transactions effective; Step 5: After confirming that the transaction is valid and adding a new block, the ledger status is updated and an interface is provided to facilitate querying transaction details and historical records.

2. A transaction verification method based on blockchain according to claim 1, characterized in that: The step 1 comprises: The transaction initiator constructs a transaction on the local client that includes the sender's blockchain address, the receiver's blockchain address, the transaction amount, a unique transaction identifier, and optional additional information; The initiator uses the corresponding private key to digitally sign the transaction content, and processes the generated digital signature to obtain a transaction data packet; The digitally signed transaction data packet is sent to the nodes in the blockchain network and broadcasted via the P2P network protocol.

3. A transaction verification method based on blockchain according to claim 2, characterized in that: The step 2 comprises: The nodes in the blockchain network receive the broadcasted transaction information and temporarily store it in the local transaction pool; Check the format and syntax of the transaction to ensure that it complies with the structure and type and length requirements of each field specified in the blockchain protocol; The sender's public key is used to verify whether the digital signature on the transaction is correct. If the verification fails, the transaction is discarded. If the verification passes, the subsequent verification process is entered.

4. A transaction verification method based on blockchain according to claim 3, characterized in that: The step 3 comprises: Check whether the sender's account balance is sufficient to pay the transaction amount and handling fee. If the balance is insufficient, the transaction is deemed illegal and removed; Double-spending checks are performed. For UTXO-based blockchains, the UTXO involved in the transaction is checked to see if it has been referenced in other transactions to be confirmed. For account-based blockchains, corresponding mechanisms are used to ensure that the same funds will not be involved in multiple concurrent transactions at the same time. Transactions with the possibility of double spending will not be further processed and will be marked as abnormal.

5. A transaction verification method based on blockchain according to claim 4, characterized in that: The step 4 comprises: In a blockchain that uses the proof-of-work consensus mechanism, miner nodes select legitimate transactions from the transaction pool to build new blocks, and make the hash value of the block header meet the conditions by finding a random number that meets the difficulty target; under the proof-of-stake consensus mechanism, validator nodes that meet the corresponding conditions are responsible for selecting transactions to build new blocks and follow the consensus rules. After receiving the new block, all nodes in the network will once again perform format and syntax checks, digital signature verification, and transaction legitimacy checks on all transactions contained in the new block, and verify whether the new block itself meets the requirements of the consensus mechanism. If it passes the verification, the new block will be added to the blockchain main chain, and the transactions in the new block will be finally confirmed and take effect.

6. A transaction verification method based on blockchain according to claim 5, characterized in that: The step 5 comprises: After confirming that the transaction is valid and adding the new block, updating the locally maintained ledger state according to the transaction content; Provide corresponding interfaces or tools to allow users and regulators to query specific transaction details and historical records based on transaction identifiers and blockchain addresses.

7. A transaction verification system based on blockchain, characterized in that: A blockchain-based transaction verification method applied to any one of claims 1 to 6, comprising a transaction broadcast module, a transaction verification module, an account and double-spending check module, a block construction and verification module, and a ledger management and query module; Transaction broadcast module: After the transaction initiator constructs the transaction and digitally signs it on the local client, it broadcasts the transaction to the blockchain network nodes through the P2P network protocol; The transaction verification module verifies the format syntax and digital signature of the transaction, and decides whether to discard the transaction or allow it to enter the subsequent process based on the verification results; The account and double-spending check module checks the sender's account balance and performs double-spending checks, and determines and marks transactions with insufficient balance or possible double-spending. The block construction and verification module coordinates the corresponding nodes to build new blocks according to different consensus mechanisms, and organizes all network nodes to verify the new blocks and the transactions contained therein, and adds the new blocks to the main chain after the verification is passed; The ledger management and query module updates the ledger status after the transaction is confirmed to be valid and a new block is added, and provides an interface for convenient query of transaction details and historical records.

Images