A blockchain-based cross-border payment data tamper-proofing method, device and equipment

Abstract

The application provides a cross-border payment data tamper-proofing method, device and equipment based on a blockchain, which comprises the following steps: obtaining payment data, a first hash value of a first block, a first timestamp and a client public key; determining a second hash value according to the payment data, the first hash value, the first timestamp and the client public key; obtaining a client private key; determining a first digital signature according to the client private key and the second hash value; sending the payment data, the first hash value and the first digital signature to a server, so that the server determines a second digital signature and a third hash value according to the payment data, the first hash value and the first digital signature; receiving the second digital signature and the third hash value sent by the server; and determining a verification result of the payment data according to the second digital signature and the third hash value, wherein the verification result is used to judge whether the payment data is tampered with. The scheme realizes that cross-border payment full-link data is tamper-proof, verifiable and efficient.

Description

Technical Field

[0001] This invention relates to the field of computer information processing technology, and in particular to a method, apparatus and equipment for preventing tampering of cross-border payment data based on blockchain. Background Technology

[0002] With the increasing frequency of globalized trade and financial activities, cross-border payment systems face higher requirements for security and efficiency. Currently, mainstream cross-border payment networks still mainly rely on centralized architectures, using correspondent banking relationships between participating banks for clearing and reconciliation. To improve trustworthiness and transparency, existing technologies are beginning to explore the introduction of blockchain as a distributed ledger to record changes in the state of payment transactions. Typical solutions include using smart contracts to automatically execute payment conditions, or using hash functions to generate digital fingerprints for key payment data (such as transaction amounts and participant information) and storing them on the blockchain, attempting to ensure data integrity through the immutability of blockchain. In addition, some improved models propose combining multi-party signatures or threshold signature mechanisms to enhance identity verification, or introducing consensus algorithms to ensure data consistency among nodes.

[0003] However, the aforementioned existing technologies still have significant drawbacks. First, most solutions only store the hash value of the final transaction state on-chain, while the intermediate states of payments flowing between multiple banks do not form a traceable and verifiable tamper-proof chain, making it difficult to detect local data tampering in a timely manner. Second, there is a lack of a strong correlation mechanism between off-chain data and on-chain anchored data, resulting in high complexity in cross-chain verification and making it a potential security vulnerability. Furthermore, existing hash chain construction methods typically do not introduce external randomness (such as the blockchain's own block hash), relying solely on business data sequences to calculate hashes, leading to a highly predictable chain structure and limited ability to resist collusive tampering. In addition, in terms of supporting regulatory audits and cross-system interoperability, existing tamper-proof mechanisms often do not provide lightweight verification interfaces, making it difficult to balance data privacy and verification efficiency. Summary of the Invention

[0004] This invention provides a blockchain-based method, apparatus, and device for preventing tampering of cross-border payment data, solving the problem of difficulty in preventing tampering and verifying trusted data throughout the entire cross-border payment process.

[0005] To solve the above-mentioned technical problems, the technical solution of the present invention is as follows:

[0006] This invention provides a blockchain-based method for preventing tampering of cross-border payment data, applied to a client-side application, comprising:

[0007] Obtain payment data, the first hash value of the first block, the first timestamp, and the client's public key;

[0008] The second hash value is determined based on the payment data, the first hash value, the first timestamp, and the client public key;

[0009] Obtain the client's private key;

[0010] The first digital signature is determined based on the client's private key and the second hash value;

[0011] The payment data, the first hash value, and the first digital signature are sent to the server, so that the server determines the second digital signature and the third hash value based on the payment data, the first hash value, and the first digital signature;

[0012] Receive the second digital signature and the third hash value sent by the server;

[0013] The verification result of the payment data is determined based on the second digital signature and the third hash value. The verification result is used to determine whether the payment data has been tampered with.

[0014] Optionally, the second hash value is determined based on the payment data, the first hash value, the first timestamp, and the client public key, including:

[0015] according to: Determine the second hash value;

[0016] in, The second hash value; For payment data; First timestamp; For the client's public key; The first hash value; For concatenation operators; This is the hash calculation function.

[0017] Optionally, determining the first digital signature based on the client's private key and the second hash value includes:

[0018] according to: Determine the first digital signature;

[0019] in, For the first digital signature; For the client's private key; This is a function for calculating digital signatures.

[0020] Optionally, the verification result of the payment data is determined based on the second digital signature and the third hash value, including:

[0021] Get the third timestamp;

[0022] Based on the second digital signature, the third hash value, the third timestamp, and the client public key, a fourth hash value is determined and written into the blockchain for storage.

[0023] Determine the fifth hash value based on the blockchain;

[0024] The fifth hash value is compared with the fourth hash value. If the fifth hash value is the same as the fourth hash value, the verification result of the payment data is that the verification is successful. If the fifth hash value is different from the fourth hash value, the verification result of the payment data is that the verification is unsuccessful. The client then resends the payment data, the first hash value, and the first digital signature to the server.

[0025] This invention also provides a blockchain-based method for preventing tampering of cross-border payment data, applied to a server, comprising:

[0026] Receive payment data, first hash value, and first digital signature sent by the client;

[0027] Obtain the server's public key and second timestamp;

[0028] The third hash value is determined based on the payment data, the first hash value, the first digital signature, the server public key, and the second timestamp;

[0029] Obtain the server's private key;

[0030] The second digital signature is determined based on the server's private key and the third hash value;

[0031] The second digital signature and the third hash value are sent to the client.

[0032] Optionally, a third hash value is determined based on the payment data, the first hash value, the first digital signature, the server public key, and the second timestamp, including:

[0033] according to: Determine the third hash value;

[0034] in, The third hash value; For payment data; This is the second timestamp; This is the server's public key; For the first digital signature; The first hash value; For concatenation operators; This is the hash calculation function.

[0035] Optionally, the second digital signature is determined based on the server's private key and the third hash value, including:

[0036] according to: Determine the second digital signature;

[0037] in, For a second digital signature; This is the server's private key; This is a function for calculating digital signatures.

[0038] This invention also provides a blockchain-based cross-border payment data anti-tampering device, applied to a client, comprising:

[0039] The first acquisition module is used to acquire payment data, the first hash value of the first block, the first timestamp, and the client public key.

[0040] The first processing module is configured to determine the second hash value based on the payment data, the first hash value, the first timestamp, and the client public key;

[0041] The first acquisition module is also used to acquire the client's private key;

[0042] The first processing module is further configured to determine the first digital signature based on the client's private key and the second hash value;

[0043] The first transceiver module is configured to send the payment data, the first hash value, and the first digital signature to the server, so that the server determines the second digital signature and the third hash value based on the payment data, the first hash value, and the first digital signature; and receive the second digital signature and the third hash value sent by the server.

[0044] The determining module is used to determine the verification result of the payment data based on the second digital signature and the third hash value, and the verification result is used to determine whether the payment data has been tampered with.

[0045] This invention also provides a blockchain-based anti-tampering device for cross-border payment data, applied to a server, comprising:

[0046] The second transceiver module is used to receive payment data, the first hash value, and the first digital signature sent by the client.

[0047] The second acquisition module is used to acquire the server public key and the second timestamp;

[0048] The second processing module is used to determine the third hash value based on the payment data, the first hash value, the first digital signature, the server public key, and the second timestamp;

[0049] The second acquisition module is also used to acquire the server's private key;

[0050] The second processing module is further configured to determine the second digital signature based on the server private key and the third hash value;

[0051] The second transceiver module is also used to send the second digital signature and the third hash value to the client.

[0052] This invention also provides a computing device, including: a processor and a memory storing a computer program, wherein the computer program, when run by the processor, executes the above-described method.

[0053] The technical solution of the present invention has at least the following effects:

[0054] The above-described solution of the present invention obtains payment data, a first hash value of a first block, a first timestamp, and a client public key; determines a second hash value based on the payment data, the first hash value, the first timestamp, and the client public key; obtains a client private key; determines a first digital signature based on the client private key and the second hash value; sends the payment data, the first hash value, and the first digital signature to a server, so that the server determines a second digital signature and a third hash value based on the payment data, the first hash value, and the first digital signature; receives the second digital signature and the third hash value sent by the server; and determines a verification result of the payment data based on the second digital signature and the third hash value. The verification result is used to determine whether the payment data has been tampered with, thus achieving tamper-proof, verifiable, and efficient data transfer throughout the entire cross-border payment process. Attached Figure Description

[0055] Figure 1 This is a flowchart of a blockchain-based cross-border payment data anti-tampering method applied to a client, provided by an embodiment of the present invention;

[0056] Figure 2 This is a flowchart of a blockchain-based cross-border payment data anti-tampering method applied to a server, provided by an embodiment of the present invention.

[0057] Figure 3 This is a structural diagram of a blockchain-based cross-border payment data anti-tampering device applied to a client, provided in an embodiment of the present invention.

[0058] Figure 4 This is a structural diagram of a blockchain-based cross-border payment data anti-tampering device applied to a server, provided in an embodiment of the present invention.

[0059] Figure 5 This is a schematic diagram of the structure of the computing device provided in an embodiment of the present invention. Detailed Implementation

[0060] Exemplary embodiments of the invention will now be described in more detail with reference to the accompanying drawings. While exemplary embodiments of the invention are shown in the drawings, it should be understood that the invention may be implemented in various forms and should not be limited to the embodiments set forth herein. Rather, these embodiments are provided so that this invention will be thorough and complete, and will fully convey the scope of the invention to those skilled in the art.

[0061] like Figure 1 As shown, an embodiment of the present invention proposes a blockchain-based method for preventing tampering of cross-border payment data, applied to a client-side application, comprising:

[0062] Step 11: Obtain payment data, the first hash value of the first block, the first timestamp, and the client's public key;

[0063] Step 12: Determine the second hash value based on the payment data, the first hash value, the first timestamp, and the client public key;

[0064] Step 13, obtain the client's private key;

[0065] Step 14: Determine the first digital signature based on the client's private key and the second hash value;

[0066] Step 15: Send the payment data, the first hash value, and the first digital signature to the server, so that the server determines the second digital signature and the third hash value based on the payment data, the first hash value, and the first digital signature;

[0067] Step 16: Receive the second digital signature and the third hash value sent by the server;

[0068] Step 17: Determine the verification result of the payment data based on the second digital signature and the third hash value. The verification result is used to determine whether the payment data has been tampered with.

[0069] In step 11 of this embodiment, the client needs to obtain payment data, which is the core information of the entire cross-border payment transaction, including transaction amount, payee information, and payer information. Simultaneously, it obtains the latest confirmed block hash value (i.e., the first hash value of the first block; for example, waiting for 3 blocks to confirm to ensure security). The hash value is a unique identifier obtained by hashing the data within a block; it represents the data characteristics of that block and is used for subsequent data association and verification. The first timestamp records the time when this data was obtained, helping to determine the time sequence and timeliness of the data, and plays an important role in verifying whether the data has been tampered with. The client public key is the public key used by the client for encryption and digital signature verification; it is an identifier of the client's identity and is used in conjunction with the client private key.

[0070] In step 12, the client processes the obtained payment data, first hash value, first timestamp, and client public key, performing hash calculations on this data to generate a second hash value. The second hash value is a comprehensive summary of these key data points, uniquely representing the combined state of this data. If any data point changes, the second hash value will also change, providing a basis for subsequent data verification.

[0071] In step 13, the client's private key is a confidential key possessed only by the client. It is used to digitally sign the data, ensuring the authenticity and integrity of the data's origin.

[0072] In step 14, the client uses the obtained client private key and the second hash value generated in step 12 to perform calculations using a digital signature algorithm (such as RSA, ECDSA, etc.) to generate a first digital signature. The first digital signature is an encrypted identifier of the payment data and related information, proving that the data was issued by the client and has not been tampered with. Because only the entity possessing the client private key can generate a correct digital signature, the digital signature is unique and unforgeable.

[0073] In step 15, the client sends the payment data, the first hash value, and the first digital signature to the server. Upon receiving this data, the server verifies and calculates the information using the corresponding algorithm and key, based on the received payment data, the first hash value, and the first digital signature. Specifically, the server recalculates the hash value (i.e., the third hash value) and generates a second digital signature using its own private key. This process ensures that the data received by the server is complete and tamper-proof, while also providing the client with the server's verification information.

[0074] In step 16, the client receives the second digital signature and the third hash value sent back by the server. This information is the server's feedback on the verification results of the data sent by the client, and the client will use this information for subsequent verification operations.

[0075] In step 17, the client performs a verification operation using the received second digital signature and third hash value, employing the corresponding algorithm and the client's public key (used to verify the server's digital signature). The client checks whether the second digital signature was correctly generated by the server and whether the third hash value matches the expected hash value calculated by the client based on its own data. If both requirements are met, it indicates that the payment data has not been tampered with during transmission and processing, and the verification result is that the data is valid; conversely, if either verification fails, it indicates that the payment data may have been tampered with, and the verification result is that the data is invalid.

[0076] The above embodiments of the present invention construct a multi-level hash chain structure with blockchain block hash as random anchor point, connecting various participants (such as payers, intermediary banks, and receiving banks), and finally distributively storing the chain tail hash value on the blockchain. This achieves the effect of quickly auditing the authenticity of data without relying on a central institution, effectively balancing the multiple requirements of security, efficiency, and transparency and trustworthiness in cross-border payment scenarios.

[0077] In an optional embodiment of the present invention, step 12, determining the second hash value based on the payment data, the first hash value, the first timestamp, and the client public key, may include:

[0078] Step 121, according to: Determine the second hash value;

[0079] in, The second hash value; For payment data; First timestamp; For the client's public key; The first hash value; For concatenation operators; This is the hash calculation function.

[0080] In step 121 of this embodiment, the core objective is to generate a "digital fingerprint" that can uniquely represent all the key information of this payment transaction and has strong correlation and tamper resistance, namely the second hash value. ).this It is not isolated; it will serve as the foundation for subsequent operations (such as signing and on-chain processing). Its existence ensures the security of payment data ( ),time( ), Client identity ( ) and the previous hash state ( They are tightly bound together; any alteration to any one of them will lead to... Invalid, and therefore rejected by the system. The system will consider the above four parameters ( The data is concatenated end-to-end in a prescribed order to form a longer data string or byte stream. Both parties in the protocol (client and server) must strictly adhere to the same concatenation and verification order; otherwise, the calculated hash values ​​will be completely different. This prescribed order is part of the algorithm protocol, ensuring consistency in computation. This concatenated long data is then input into a cryptographic hash function (such as SHA-256). The hash function performs a series of complex mathematical operations, outputting a fixed-length, seemingly random string—the second hash value. The characteristics of hash functions determine that... Value:

[0081] (1) Determinism: The same input will always produce the same result. .

[0082] (2) Unidirectionality: from The original input data cannot be retrieved.

[0083] (3) Avalanche effect: Even if the input data changes by only one bit (e.g., the amount changes from 100.00 to 100.01), the output... It will also become unrecognizable and completely unrelated.

[0084] (4) Collision resistance: It is extremely difficult to find two different inputs that can produce the same result. .

[0085] In an optional embodiment of the present invention, step 14, determining the first digital signature based on the client private key and the second hash value, may include:

[0086] Step 141, according to: Determine the first digital signature;

[0087] in, For the first digital signature; For the client's private key; This is a function for calculating digital signatures.

[0088] In step 141 of this embodiment, the core objective is to use the client's private key to perform encryption operations on the second hash value H2 to generate a first digital signature. Its functions include:

[0089] (1) Identity authentication: Prove that the transaction was indeed initiated by the client who possesses the corresponding private key, and not by someone impersonating the client;

[0090] (2) Data Integrity: Ensure that all data (including payment data) is intact throughout the entire process from H2 generation to signature verification. timestamp (etc.) were not altered;

[0091] (3) Non-repudiation: Because the signature can only be generated using the client's private key, the client cannot deny that it initiated the transaction afterward.

[0092] Digital signature function The two input parameters include:

[0093] (1) Client private key ( : Stored in the client's secure environment (such as a hardware encryption module or security chip), and is linked to the client's public key used in previous steps. The signature generator and encryption key are a pair of asymmetric keys. The private key is the key used by the signature generator or encryption key. Its confidentiality is the foundation of the security of the entire signature mechanism.

[0094] (2) Second hash value ( This represents all key information (data) related to this transaction. ,time ,identity ,history A fixed-length "digital fingerprint". In this step, It's a signed message. The reason for not directly accessing the raw data is... The reason for signing H2 is:

[0095] (1) Efficiency: It is of fixed length (e.g., SHA-256 outputs 256 bits), but for large amounts of payment data... Performing asymmetric cryptographic signature operations is very time-consuming. It is extremely efficient for signing short hash values.

[0096] (2) Security: Hash functions ensure that any tiny change in data will produce a completely new result. This immediately invalidates the old signature, which is equivalent to signing the original data itself.

[0097] A function is a complex cryptographic operation; its internal logic can be understood as: using a private key... Regarding the message Perform a special encryption that can only be decrypted with the corresponding public key. Digital signature algorithms (such as ECDSA, RSA) include the following steps:

[0098] (1) Again Perform cryptographic processing (e.g., for) Perform a hash.

[0099] (2) Using the client's private key Perform mathematical operations on the processed result (e.g., dot product in elliptic curve cryptography, modular exponentiation in RSA) to generate a unique, similar to... and All are related numeric strings. This output numeric string is the first digital signature ( The first digital signature has the following properties:

[0100] (1) Uniqueness: For different Or different private keys, generated Completely different.

[0101] (2) Dependency: The value depends entirely on and Even if someone knows the private key, they cannot know the private key. It is also impossible to calculate the correct one. .

[0102] (3) Verifiability: Possessing the corresponding public key ( (A person can verify that this signature was indeed made by) It was generated, and it is specific to this. .

[0103] In an optional embodiment of the present invention, step 15, sending the payment data, the first hash value, and the first digital signature to the server, so that the server determines the second digital signature and the third hash value based on the payment data, the first hash value, and the first digital signature, may include:

[0104] Step 151: The client sends the payment data, the first hash value, and the first digital signature to the server. After receiving this data, the server performs a series of operations to generate the second digital signature and the third hash value. The specific process is as follows:

[0105] (1) Data reception and verification: After the server receives the payment data, the first hash value and the first digital signature sent by the client, it first needs to verify the validity of the first digital signature.

[0106] The server obtains a pre-stored client public key (e.g., from registration information or a security certificate store) and uses that public key to decrypt the first digital signature, obtaining the decrypted hash value.

[0107] At the same time, the server recalculates the second hash value based on the locally stored payment data (which should be consistent with the one sent by the client), the first hash value, the first timestamp (which the server can obtain from the transaction context or client request), and the client's public key. The calculation method is the same as in client step 12.

[0108] The server compares the decrypted second hash value with the recalculated second hash value. If they match, the verification passes, indicating that the payment data has not been tampered with during transmission and the signature is valid; otherwise, the server returns an error response and terminates the process.

[0109] (2) Generating a second digital signature and a third hash value: After successful verification, the server begins processing the data to upload it to the blockchain or for further protection. The server uses its own private key (server private key) to digitally sign the second hash value or related data (such as a combination of payment data and the first hash value) to generate a second digital signature. This represents the server's confirmation of the data's validity and is used for subsequent on-chain verification.

[0110] Simultaneously, the server packages payment data, the first hash value, and the second digital signature into a transaction or data block, and calculates its hash value as the third hash value. The third hash value is typically an identifier related to the blockchain, for example:

[0111] If the server submits data directly to the blockchain, the third hash value can be the transaction hash or block hash of the transaction on the blockchain.

[0112] If the server first stores the data in an off-chain system (such as distributed storage), the third hash value may be the hash of the content identifier (such as IPFS CID) after storage.

[0113] The third hash value ensures the immutability of data on the server or blockchain; any modification to the data will result in a change in the third hash value.

[0114] (3) Data preparation and response: The server prepares to send the second digital signature and the third hash value back to the client as response data. This data will be used by the client for final verification in step 17.

[0115] In an optional embodiment of the present invention, step 16, receiving the second digital signature and the third hash value sent by the server, may include:

[0116] Step 161: The client receives the response data returned by the server through a network channel (such as HTTPS or P2P protocol), including the second digital signature and the third hash value.

[0117] The client also receives other metadata, such as server ID, timestamp, or status code.

[0118] Step 162, Data Integrity Check: The client first checks whether the received data is complete and valid, for example, verifying whether the data format is correct, and ensuring that the second digital signature and the third hash value are not empty. If the data is corrupted or lost, the client will resend the request or display an error message.

[0119] Step 163: The client temporarily stores the second digital signature and the third hash value in local memory or secure storage for use in step 17.

[0120] In an optional embodiment of the present invention, step 17, determining the verification result of the payment data based on the second digital signature and the third hash value, may include:

[0121] Step 171, obtain the third timestamp;

[0122] Step 172: Determine the fourth hash value based on the second digital signature, the third hash value, the third timestamp, and the client public key, and write the fourth hash value into the blockchain for storage;

[0123] Step 173: Determine the fifth hash value based on the blockchain;

[0124] Step 174: Compare the fifth hash value with the fourth hash value. If the fifth hash value and the fourth hash value are the same, the verification result of the payment data is verified as successful. If the fifth hash value and the fourth hash value are different, the verification result of the payment data is verified as unsuccessful. The client then resends the payment data, the first hash value, and the first digital signature to the server.

[0125] The purpose of step 17 in this embodiment is to write a hash value (fourth hash value) representing the final state of this transaction into the blockchain, and to query the blockchain to compare whether the data has been successfully and correctly recorded by the blockchain network, thereby providing an authoritative, consensus-based verification result. Its functions include:

[0126] (1) By utilizing the tamper-proof nature of blockchain data, it is ensured that once transaction data is confirmed and uploaded to the chain, its state is permanently fixed and any subsequent modifications will be detected.

[0127] (2) Provide objective and credible verification evidence. The verification results do not depend on the statements of either the client or the server, but are provided by a neutral and decentralized blockchain network.

[0128] (3) To achieve traceability and auditability, the key fingerprint (hash value) of the transaction is permanently stored on the blockchain, providing tamper-proof evidence for future audits and dispute arbitration.

[0129] In step 171, the third timestamp ( This records the time when the verification request was initiated or the time when the data was prepared to be written to the blockchain. (Compared to the first timestamp...) )similar, This is used to prevent replay attacks and to accurately record the time point when the verification operation occurs, further enhancing the traceability of the entire process.

[0130] In step 172, the second digital signature ( The third hash value is the server's signature on the processing result, representing the server's approval and endorsement of the transaction. A third timestamp is another "data fingerprint" generated by the server after processing payment data and other related information, representing the server's processed state. The current timestamp was just retrieved. The client's public key ( This is the client's identity identifier. After concatenating the above four parameters, calculate the hash value: .

[0131] Will It is sent to the blockchain network, which will then use a consensus mechanism (such as PoW, PoS) to process this. This is packaged into a new block and broadcast to all nodes for recording. This means that this "super fingerprint" has been permanently and immutably recorded in the distributed ledger.

[0132] In step 173, after the necessary confirmation period of the blockchain network (such as waiting for 6 block confirmations), the client (or server) queries the blockchain for the hash value that was just recorded, based on the transaction ID or block information. This value retrieved from the chain is named the fifth hash value. ). yes An official mirror on the blockchain. If everything is working correctly... It should equal .

[0133] In step 174, the verification results are compared and confirmed. If This means that the "super fingerprint" the client initially wanted to store on the blockchain... This is in contrast to the "official record" that is ultimately recognized and recorded by the blockchain network. Complete consistency proves that throughout the entire process from client-generated data to server processing and data upload to the blockchain, all critical information has not been tampered with by any party. The state of the transaction data has received ultimate endorsement from the blockchain. If This means that the client's local computation With the records on the chain Inconsistency. This inconsistency can mean several things:

[0134] (1) The data was accidentally damaged or maliciously tampered with during the process of being sent to the server or processed by the server.

[0135] (2) Data is rejected or modified by blockchain nodes during the process of being uploaded to the blockchain.

[0136] (3) Network transmission error.

[0137] At this point, the client needs to re-initiate the process, resending the payment data, the first hash value, and the first digital signature to the server. This is an error recovery mechanism to ensure that there is ultimately a consistent result that is confirmed by the blockchain.

[0138] like Figure 2 As shown, an embodiment of the present invention proposes a blockchain-based method for preventing tampering of cross-border payment data, applied to a server, comprising:

[0139] Step 21: Receive payment data, first hash value, and first digital signature sent by the client;

[0140] Step 22: Obtain the server public key and the second timestamp;

[0141] Step 23: Determine the third hash value based on the payment data, the first hash value, the first digital signature, the server public key, and the second timestamp;

[0142] Step 24, obtain the server's private key;

[0143] Step 25: Determine the second digital signature based on the server private key and the third hash value;

[0144] Step 26: Send the second digital signature and the third hash value to the client.

[0145] In this embodiment, the core objectives of the server-side process include:

[0146] (1) Verify the authenticity and integrity of the client request, and confirm that the received data does indeed come from the claimed client and has not been tampered with during transmission.

[0147] (2) Perform business logic processing, including compliance checks, foreign exchange conversion, and accounting processing required for cross-border payments (this part is not explicitly stated in the plan, but is implied in the process).

[0148] (3) Generate authoritative credentials for the server, create a “processing receipt” containing the server identity, processing result and timestamp, and use digital signature to ensure that the receipt cannot be forged or tampered with.

[0149] (4) Provide the client with the basis for final verification, and return the generated credentials (second digital signature and third hash value) to the client so that the client can complete the final blockchain-based verification.

[0150] In step 21, after receiving the client data, the server first needs to verify the client's signature using the attached client public key. (This is usually also included in the request or can be obtained from the certificate) Perform verification; based on the received , , and Recalculate The server will compare the verification results. Only if the verification passes will the request be considered legitimate and the data complete, and the server will then execute step 22 and subsequent operations. Otherwise, the request will be immediately rejected.

[0151] In step 22, the server public key ( This is the server's identity identifier. Introducing it into computation allows the server to bind its identity to the current processing flow.

[0152] Second timestamp ( This represents the time when the server received and began processing the transaction. Its function is similar to the client's timestamp. Similar to, including:

[0153] (1) Prevent replay attacks: Ensure that client requests are fresh.

[0154] (2) Record processing time: Provide key time node evidence for the entire transaction process for auditing and tracing.

[0155] In step 23, the server concatenates the received data with its own information and calculates a third hash value; the third hash value is a "processing status fingerprint" generated by the server, uniquely representing "the server's processing status fingerprint". At that moment, the client was confirmed. Certification about and The entire event of "this transaction" is the "message" that the server will endorse next.

[0156] In step 24, the server's private key ( The server's private key is typically stored in the server's Hardware Security Module (HSM) and is protected at the highest level. The server's private key is the core key for generating digital signatures and represents the server's identity.

[0157] In step 25, the server uses its private key to sign the third hash value (i.e., the second digital signature). This second digital signature is the core output of the entire server-side process; it serves as the server's authoritative endorsement, proving that the server indeed processed the transaction and that it has verified the client's signature and data integrity, thus ensuring... All the information it represents ( , , , , None of them can be tampered with, because any alteration will result in... Change, thus Verification failed. Meanwhile, the second digital signature is also non-repudiable because only the holder of the signature can verify it. Only servers can generate .

[0158] In step 26, the second digital signature and the third hash value are sent to the client, completing the process loop. The client receives... and Then, they will be used (along with a third timestamp). and its own public key Generate the fourth hash value And write it into the blockchain for final verification.

[0159] The above embodiments of the present invention have the following technical effects:

[0160] (1) Two-way authentication: Not only does the client prove its identity to the server, but the server also generates authentication information. It proves its identity and processing behavior to the client (and the ultimate blockchain validator).

[0161] (2) Extending the data integrity chain: extending the client's original data ( , ) and authorization ( ) and server processing information ( , These are bundled together to generate new and richer state fingerprints. and signed with strong cryptography. This protects the data. This extends the chain of data tamper-proofing from the client to the server.

[0162] (3) Clear responsibility: If a problem occurs in any link, the problem can be located by verifying the corresponding digital signature, whether it is on the client side, the transmission process or the server side.

[0163] In an optional embodiment of the present invention, step 23, determining the third hash value based on the payment data, the first hash value, the first digital signature, the server public key, and the second timestamp, may include:

[0164] Step 231, according to: Determine the third hash value;

[0165] in, The third hash value; For payment data; This is the second timestamp; This is the server's public key; For the first digital signature; The first hash value; For concatenation operators; This is the hash calculation function.

[0166] In step 231 of this embodiment, the server strictly follows a preset order to process the above five parameters ( The two data streams are concatenated end-to-end to form a long data stream. This concatenated long data stream is then input into a cryptographic hash function (such as SHA-256). The hash function performs a series of complex irreversible operations, outputting a fixed-length, unique, and seemingly random string, which is the third hash value. . It has the following characteristics:

[0167] (1) Represents the whole: It became a highly compressed and unique digital representation of all input information.

[0168] (2) Sensitivity: A change in any bit of the five input parameters will produce a completely different and unrelated result. .

[0169] (3) Irreversibility: from It is impossible to deduce any of the original input information.

[0170] In an optional embodiment of the present invention, step 25, determining the second digital signature based on the server private key and the third hash value, may include:

[0171] Step 251, according to: Determine the second digital signature;

[0172] in, For a second digital signature; This is the server's private key; This is a function for calculating digital signatures.

[0173] In step 251 of this embodiment, The function typically employs algorithms such as ECDSA or RSA-PSS, and its data processing steps include:

[0174] The system uses the server's private key. For the third hash value Perform mathematical transformations to generate a unique string of numbers containing two parts (often called r and s values), which is the second digital signature. .

[0175] For specific and specific Only one correct one will be produced. Any change to any parameter will produce a completely different invalid signature. The server's private key is unknown. Even people who are fully aware It is absolutely impossible to calculate an effective one. This is the foundation of the entire trustworthy mechanism. Anyone holding the corresponding server's public key ( Entities (such as clients, auditors, and other nodes) can all use standard verification algorithms to verify a given [object / entity]. Indeed, it is made by sign And thus it was generated.

[0176] generate Then, the server combines it with Send them back to the client together. This is a "processing receipt" from the server to the client. The client can be assured that the server has received the complete and correct request and has processed it. Upon receiving this receipt... and Then, these will be used as key inputs, along with their own information (such as public keys). New timestamp Combined again, a fourth hash value is generated. And eventually, it is written into the blockchain. The existence of makes It includes not only transaction data but also the server's authoritative digital signature. This means that what is ultimately permanently recorded on the blockchain is not the original data, but a "claim" that has been authenticated and signed by the server. When the transaction needs to be audited in the future, the auditor can retrieve it from the blockchain. And parse out its components, while using the server's public key. right Verification is required.

[0177] A specific embodiment of a blockchain-based method for preventing tampering of cross-border payment data provided by this invention is as follows:

[0178] This method involves multiple parties, including the sender (i.e., the client) and the receiving bank (i.e., the server). Each party hashes and signs the payment data, forming a hash chain, and finally writes the root hash into the blockchain. During verification, data integrity is ensured by recalculating the hash chain and comparing it with the root hash on the blockchain.

[0179] Step 1: Obtain payment data, the first hash value of the first block, the first timestamp, and the client's public key;

[0180] (1) Payment data generation:

[0181] The sender generates cross-border payment data D, which includes transaction ID, sender information, recipient information, amount, currency type, transaction timestamp, etc.

[0182] (2) Obtaining the blockchain block hash

[0183] The sender queries the blockchain to obtain the hash of the latest confirmed block (e.g., waiting for 3 block confirmations to ensure security). This is denoted as... .

[0184] Step 2: Determine the second hash value based on the payment data, the first hash value, the first timestamp, and the client public key;

[0185] The sender calculates the initial hash. The formula is:

[0186] ,

[0187] in, The second hash value; For payment data; First timestamp; For the client's public key; The first hash value; For concatenation operators; For hash calculation functions;

[0188] Step 3: Obtain the client's private key, and determine the first digital signature based on the client's private key and the second hash value;

[0189] The sender uses the private key right The formula for digital signature is:

[0190] ,

[0191] in, For the first digital signature; For the client's private key; Function for calculating digital signatures;

[0192] Step 4: Send the payment data, the first hash value, and the first digital signature to the server;

[0193] The sender will send D, , , , , Send to the sending bank.

[0194] Step 5: The server receives the payment data, the first hash value, and the first digital signature sent by the client, and verifies them.

[0195] Receiving bank use verify The validity of the verification is checked. If the verification is successful, the bank receives D; otherwise, it is rejected.

[0196] Step 6: The server obtains the server public key and the second timestamp, and determines the third hash value based on the payment data, the first hash value, the first digital signature, the server public key, and the second timestamp;

[0197] The receiving bank generates the current timestamp. And calculate the third hash value, using the formula:

[0198] ,

[0199] in, The third hash value; For payment data; This is the second timestamp; This is the server's public key; For the first digital signature; The first hash value; For concatenation operators; For hash calculation functions;

[0200] Step 7: Determine the second digital signature based on the server private key and the third hash value;

[0201] Receiving bank uses private key right To sign, the formula is:

[0202] ,

[0203] in, For a second digital signature; This is the server's private key; Function for calculating digital signatures;

[0204] Step 8: The server sends the second digital signature and the third hash value to the client.

[0205] The receiving bank will , , , , Send to the client; simultaneously, send the bank's reserved D, , Data is available for verification.

[0206] Step 9: The client receives the second digital signature and the third hash value sent by the server and performs verification.

[0207] The client uses PubI to verify the validity of the second digital signature. If the verification is successful, the client generates a timestamp. Calculate hash The formula is:

[0208] ;

[0209] If there are more participants (such as other intermediary banks), repeat steps 8 to 9: each participant verifies the previous signature and hash, calculates its own hash and signature, and sends it to the next participant.

[0210] Step 10: Determine the verification result of the payment data based on the second digital signature and the third hash value.

[0211] The final participants (such as the client) calculate the final hash. Afterwards, Write it to the blockchain. Through smart contracts or transactions, Stored in association with the transaction ID.

[0212] At any time when a verifier (such as an auditor) needs to verify payment data D:

[0213] Get D from the sender, and get it from the blockchain. .

[0214] calculate: ,

[0215] Final comparison With blockchain If all hashes match, then data D has not been tampered with; otherwise, tampering has been detected.

[0216] The above embodiments of the present invention construct a multi-level hash chain structure with blockchain block hash as random anchor point, connecting various participants (such as payers, intermediary banks, and receiving banks), and finally distributively storing the chain tail hash value on the blockchain. This achieves the effect of quickly auditing the authenticity of data without relying on a central institution, effectively balancing the multiple requirements of security, efficiency, and transparency and trustworthiness in cross-border payment scenarios.

[0217] like Figure 3 As shown, this embodiment of the invention also provides a blockchain-based cross-border payment data anti-tampering device, applied to a client, comprising:

[0218] The first acquisition module 31 is used to acquire payment data, the first hash value of the first block, the first timestamp, and the client public key;

[0219] The first processing module 32 is used to determine the second hash value based on the payment data, the first hash value, the first timestamp, and the client public key;

[0220] The first acquisition module 31 is also used to acquire the client's private key;

[0221] The first processing module 32 is further configured to determine the first digital signature based on the client private key and the second hash value;

[0222] The first transceiver module 33 is used to send the payment data, the first hash value, and the first digital signature to the server, so that the server determines the second digital signature and the third hash value based on the payment data, the first hash value, and the first digital signature; and to receive the second digital signature and the third hash value sent by the server.

[0223] The determining module 34 is used to determine the verification result of the payment data based on the second digital signature and the third hash value, and the verification result is used to determine whether the payment data has been tampered with.

[0224] Optionally, the first processing module 32 is specifically used for:

[0225] according to: Determine the second hash value;

[0226] in, The second hash value; For payment data; First timestamp; For the client's public key; The first hash value; For concatenation operators; This is the hash calculation function.

[0227] Optionally, the first processing module 32 is also specifically used for:

[0228] according to: Determine the first digital signature;

[0229] in, For the first digital signature; For the client's private key; This is a function for calculating digital signatures.

[0230] Optionally, module 34 is specifically used for:

[0231] Get the third timestamp;

[0232] Based on the second digital signature, the third hash value, the third timestamp, and the client public key, a fourth hash value is determined and written into the blockchain for storage.

[0233] Determine the fifth hash value based on the blockchain;

[0234] The fifth hash value is compared with the fourth hash value. If the fifth hash value is the same as the fourth hash value, the verification result of the payment data is that the verification is successful. If the fifth hash value is different from the fourth hash value, the verification result of the payment data is that the verification is unsuccessful. The client then resends the payment data, the first hash value, and the first digital signature to the server.

[0235] It should be noted that this device is the same as the blockchain-based cross-border payment data anti-tampering method applied to the client described above. All implementation methods in the above method embodiments are applicable to this embodiment and can achieve the same technical effect.

[0236] like Figure 4 As shown, this embodiment of the invention also provides a blockchain-based cross-border payment data anti-tampering device, applied to a server, comprising:

[0237] The second transceiver module 41 is used to receive payment data, a first hash value, and a first digital signature sent by the client;

[0238] The second acquisition module 42 is used to acquire the server public key and the second timestamp;

[0239] The second processing module 43 is used to determine the third hash value based on the payment data, the first hash value, the first digital signature, the server public key, and the second timestamp;

[0240] The second acquisition module 42 is also used to acquire the server's private key;

[0241] The second processing module 43 is further configured to determine the second digital signature based on the server private key and the third hash value;

[0242] The second transceiver module 41 is also used to send the second digital signature and the third hash value to the client.

[0243] Optionally, the second processing module 43 is specifically used for:

[0244] according to: Determine the third hash value;

[0245] in, The third hash value; For payment data; This is the second timestamp; This is the server's public key; For the first digital signature; The first hash value; For concatenation operators; This is the hash calculation function.

[0246] Optionally, the second processing module 43 is also specifically used for:

[0247] according to: Determine the second digital signature;

[0248] in, For a second digital signature; This is the server's private key; This is a function for calculating digital signatures.

[0249] It should be noted that this device is the same as the blockchain-based cross-border payment data anti-tampering method applied to the server described above. All implementation methods in the above method embodiments are applicable to this embodiment and can achieve the same technical effect.

[0250] like Figure 5 As shown, this embodiment of the invention also provides a computing device 50, including a processor 51, a memory 52, and a program or instructions stored in the memory 52 and executable on the processor 51. When executed by the processor 51, the program or instructions implement the various processes of the above-described embodiment of the blockchain-based cross-border payment data anti-tampering method, and achieve the same technical effect. To avoid repetition, further details are omitted here. It should be noted that the computing device in this embodiment includes the aforementioned mobile electronic devices and non-mobile electronic devices.

[0251] Those skilled in the art will recognize that the units and algorithm steps of the various examples described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, or a combination of computer software and electronic hardware. Whether these functions are implemented in hardware or software depends on the specific application and design constraints of the technical solution. Those skilled in the art can use different methods to implement the described functions for each specific application, but such implementations should not be considered beyond the scope of this invention.

[0252] Those skilled in the art will understand that, for the sake of convenience and brevity, the specific working processes of the systems, devices, and units described above can be referred to the corresponding processes in the foregoing method embodiments, and will not be repeated here.

[0253] In the embodiments provided by this invention, it should be understood that the disclosed apparatus and methods can be implemented in other ways. For example, the apparatus embodiments described above are merely illustrative; for instance, the division of units is only a logical functional division, and in actual implementation, there may be other division methods. For example, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. Furthermore, the coupling or direct coupling or communication connection shown or discussed may be through some interfaces; the indirect coupling or communication connection between apparatuses or units may be electrical, mechanical, or other forms.

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

[0255] In addition, the functional units in the various embodiments of the present invention can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit.

[0256] If the aforementioned functions are implemented as software functional units and sold or used as independent products, they can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of this invention, or the part that contributes to the prior art, or a portion of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the steps of the methods of the various embodiments of this invention. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, portable hard drives, ROM, RAM, magnetic disks, or optical disks.

[0257] Furthermore, it should be noted that in the apparatus and method of the present invention, it is obvious that the components or steps can be decomposed and / or recombined. These decompositions and / or recombinations should be considered equivalent solutions of the present invention. Moreover, the steps performing the above series of processes can naturally be executed in the order described, but are not necessarily required to be executed in chronological order; some steps can be executed in parallel or independently of each other. Those skilled in the art will understand that all or any step or component of the method and apparatus of the present invention can be implemented in any computing device (including processors, storage media, etc.) or network of computing devices, in hardware, firmware, software, or a combination thereof. This is something that those skilled in the art can achieve by using their basic programming skills after reading the description of the present invention.

[0258] Therefore, the object of the present invention can also be achieved by running a program or a set of programs on any computing device. The computing device can be a known general-purpose device. Therefore, the object of the present invention can also be achieved simply by providing a program product containing program code for implementing the method or apparatus. That is, such a program product also constitutes the present invention, and the storage medium storing such a program product also constitutes the present invention. Obviously, the storage medium can be any known storage medium or any storage medium developed in the future. It should also be noted that in the apparatus and method of the present invention, it is obvious that the components or steps can be decomposed and / or recombined. These decompositions and / or recombinations should be considered equivalent to the present invention. Furthermore, the steps for performing the above series of processes can naturally be performed in the order described, but are not necessarily required to be performed in chronological order. Some steps can be performed in parallel or independently of each other.

[0259] The above are preferred embodiments of the present invention. It should be noted that, for those skilled in the art, several improvements and modifications can be made without departing from the principle of the present invention, and these improvements and modifications should also be considered within the scope of protection of the present invention.

Claims

1. A blockchain-based method for preventing tampering of cross-border payment data, applied to a client-side application, characterized in that: include: Obtain payment data, the first hash value of the first block, the first timestamp, and the client's public key; The second hash value is determined based on the payment data, the first hash value, the first timestamp, and the client public key; Obtain the client's private key; The first digital signature is determined based on the client's private key and the second hash value; The payment data, the first hash value, and the first digital signature are sent to the server, so that the server determines the second digital signature and the third hash value based on the payment data, the first hash value, and the first digital signature; Receive the second digital signature and the third hash value sent by the server; The verification result of the payment data is determined based on the second digital signature and the third hash value, and the verification result is used to determine whether the payment data has been tampered with. The process of determining the second digital signature and the third hash value includes: according to: Determine the third hash value; in, The third hash value; For payment data; This is the second timestamp; This is the server's public key; For the first digital signature; The first hash value; For concatenation operators; For hash calculation functions; according to: Determine the second digital signature; in, For a second digital signature; This is the server's private key; Function for calculating digital signatures; Specifically, the server obtains the pre-stored client public key and uses the client public key to decrypt the first digital signature to obtain the decrypted hash value; The server recalculates the second hash value based on the locally stored payment data, the first hash value, the first timestamp, and the client's public key; The server compares the decrypted second hash value with the recalculated second hash value. If they match, the verification passes; otherwise, the server returns an error response. After successful verification, the server uses its private key to digitally sign the second hash value or the combination of the payment data and the first hash value, generating a second digital signature. At the same time, the server packages the payment data, the first hash value, and the second digital signature into a transaction or data block and calculates its hash value as the third hash value. The verification result of the payment data is determined based on the second digital signature and the third hash value, including: Get the third timestamp; Based on the second digital signature, the third hash value, the third timestamp, and the client public key, a fourth hash value is determined and written into the blockchain for storage. Determine the fifth hash value based on the blockchain; The fifth hash value is compared with the fourth hash value. If the fifth hash value is the same as the fourth hash value, the verification result of the payment data is that the verification is successful. If the fifth hash value is different from the fourth hash value, the verification result of the payment data is that the verification is unsuccessful. The client then resends the payment data, the first hash value, and the first digital signature to the server.

2. The blockchain-based method for preventing tampering of cross-border payment data as described in claim 1, characterized in that, Determining the second hash value based on the payment data, the first hash value, the first timestamp, and the client public key includes: according to: Determine the second hash value; in, The second hash value; For payment data; First timestamp; For the client's public key; The first hash value; For concatenation operators; This is the hash calculation function.

3. The blockchain-based method for preventing tampering of cross-border payment data as described in claim 1, characterized in that, Determining the first digital signature based on the client's private key and the second hash value includes: according to: Determine the first digital signature; in, For the first digital signature; For the client's private key; This is a function for calculating digital signatures.

4. A blockchain-based method for preventing tampering of cross-border payment data, applied to a server, characterized in that: include: Receive payment data, first hash value, and first digital signature sent by the client; Obtain the server's public key and second timestamp; The third hash value is determined based on the payment data, the first hash value, the first digital signature, the server public key, and the second timestamp; Obtain the server's private key; The second digital signature is determined based on the server's private key and the third hash value; Send the second digital signature and the third hash value to the client; The process of determining the second digital signature and the third hash value includes: according to: Determine the third hash value; in, The third hash value; For payment data; This is the second timestamp; This is the server's public key; For the first digital signature; The first hash value; For concatenation operators; For hash calculation functions; according to: Determine the second digital signature; in, For a second digital signature; This is the server's private key; Function for calculating digital signatures; Specifically, the server obtains the pre-stored client public key and uses the client public key to decrypt the first digital signature to obtain the decrypted hash value; The server recalculates the second hash value based on the locally stored payment data, the first hash value, the first timestamp, and the client's public key; The server compares the decrypted second hash value with the recalculated second hash value. If they match, the verification passes; otherwise, the server returns an error response. After successful verification, the server uses its private key to digitally sign the second hash value or the combination of the payment data and the first hash value, generating a second digital signature. At the same time, the server packages the payment data, the first hash value, and the second digital signature into a transaction or data block and calculates its hash value as the third hash value. The second digital signature and the third hash value are used by the client to determine the verification result of the payment data, including: Get the third timestamp; Based on the second digital signature, the third hash value, the third timestamp, and the client public key, a fourth hash value is determined and written into the blockchain for storage. Determine the fifth hash value based on the blockchain; The fifth hash value is compared with the fourth hash value. If the fifth hash value is the same as the fourth hash value, the verification result of the payment data is that the verification is successful. If the fifth hash value is different from the fourth hash value, the verification result of the payment data is that the verification is unsuccessful. The client then resends the payment data, the first hash value, and the first digital signature to the server.

5. A blockchain-based anti-tampering device for cross-border payment data, applied to a client-side application, characterized in that: include: The first acquisition module is used to acquire payment data, the first hash value of the first block, the first timestamp, and the client public key. The first processing module is configured to determine the second hash value based on the payment data, the first hash value, the first timestamp, and the client public key; The first acquisition module is also used to acquire the client's private key; The first processing module is further configured to determine the first digital signature based on the client's private key and the second hash value; The first transceiver module is used to send the payment data, the first hash value, and the first digital signature to the server, so that the server determines the second digital signature and the third hash value based on the payment data, the first hash value, and the first digital signature. Receive the second digital signature and the third hash value sent by the server; The determining module is used to determine the verification result of the payment data based on the second digital signature and the third hash value, wherein the verification result is used to determine whether the payment data has been tampered with; The process of determining the second digital signature and the third hash value includes: according to: Determine the third hash value; in, The third hash value; For payment data; This is the second timestamp; This is the server's public key; For the first digital signature; The first hash value; For concatenation operators; For hash calculation functions; according to: Determine the second digital signature; in, For a second digital signature; This is the server's private key; Function for calculating digital signatures; Specifically, the server obtains the pre-stored client public key and uses the client public key to decrypt the first digital signature to obtain the decrypted hash value; The server recalculates the second hash value based on the locally stored payment data, the first hash value, the first timestamp, and the client's public key; The server compares the decrypted second hash value with the recalculated second hash value. If they match, the verification passes; otherwise, the server returns an error response. After successful verification, the server uses its private key to digitally sign the second hash value or the combination of the payment data and the first hash value, generating a second digital signature. At the same time, the server packages the payment data, the first hash value, and the second digital signature into a transaction or data block and calculates its hash value as the third hash value. The verification result of the payment data is determined based on the second digital signature and the third hash value, including: Get the third timestamp; Based on the second digital signature, the third hash value, the third timestamp, and the client public key, a fourth hash value is determined and written into the blockchain for storage. Determine the fifth hash value based on the blockchain; The fifth hash value is compared with the fourth hash value. If the fifth hash value is the same as the fourth hash value, the verification result of the payment data is that the verification is successful. If the fifth hash value is different from the fourth hash value, the verification result of the payment data is that the verification is unsuccessful. The client then resends the payment data, the first hash value, and the first digital signature to the server.

6. A blockchain-based anti-tampering device for cross-border payment data, applied to a server, characterized in that, include: The second transceiver module is used to receive payment data, the first hash value, and the first digital signature sent by the client. The second acquisition module is used to acquire the server public key and the second timestamp; The second processing module is used to determine the third hash value based on the payment data, the first hash value, the first digital signature, the server public key, and the second timestamp; The second acquisition module is also used to acquire the server's private key; The second processing module is further configured to determine the second digital signature based on the server private key and the third hash value; The second transceiver module is further configured to send the second digital signature and the third hash value to the client; wherein the process of determining the second digital signature and the third hash value includes: according to: Determine the third hash value; in, The third hash value; For payment data; This is the second timestamp; This is the server's public key; For the first digital signature; The first hash value; For concatenation operators; For hash calculation functions; according to: Determine the second digital signature; in, For a second digital signature; This is the server's private key; Function for calculating digital signatures; Specifically, the server obtains the pre-stored client public key and uses the client public key to decrypt the first digital signature to obtain the decrypted hash value; The server recalculates the second hash value based on the locally stored payment data, the first hash value, the first timestamp, and the client's public key; The server compares the decrypted second hash value with the recalculated second hash value. If they match, the verification passes; otherwise, the server returns an error response. After successful verification, the server uses its private key to digitally sign the second hash value or the combination of the payment data and the first hash value, generating a second digital signature. At the same time, the server packages the payment data, the first hash value, and the second digital signature into a transaction or data block and calculates its hash value as the third hash value. The second digital signature and the third hash value are used by the client to determine the verification result of the payment data, including: Get the third timestamp; Based on the second digital signature, the third hash value, the third timestamp, and the client public key, a fourth hash value is determined and written into the blockchain for storage. Determine the fifth hash value based on the blockchain; The fifth hash value is compared with the fourth hash value. If the fifth hash value is the same as the fourth hash value, the verification result of the payment data is that the verification is successful. If the fifth hash value is different from the fourth hash value, the verification result of the payment data is that the verification is unsuccessful. The client then resends the payment data, the first hash value, and the first digital signature to the server.

7. A computing device, characterized in that, include: A processor, a memory storing a computer program, wherein the computer program, when executed by the processor, performs the method as described in any one of claims 1 to 3 or claim 4.

Images