Method and apparatus for transaction verification

Abstract

The application provides a transaction verification method and device, which are used in the technical field of computers. In the method, the application is applied to an electronic device including a secure element (SE), a trusted execution environment (TEE) and a rich execution environment (REE), and the execution of business logic and data storage are transferred from the SE side to the TEE side in a transaction verification process, and the SE side remains transaction legality verification. On the premise of ensuring security, the problem of limited SE storage space and computing performance of the electronic device is overcome, and the user experience is significantly improved. The method is also applied to the server side, including incremental verification of data credentials from the electronic device, and verifying the legality of data in the data credentials that are not recorded in the historical data credentials. Through the application, redundant verification calculation on the server side is reduced, thereby achieving the effect of quickly verifying data credentials on the server side in a high-concurrency scenario and saving resources.

Description

Technical Field

[0001] This application relates to the field of computer technology, and in particular to a method for transaction verification. Background Technology

[0002] With the rapid development of e-commerce and mobile payments, traditional financial systems and technologies are facing increasing challenges. Bitcoin, based on blockchain technology, has brought the concept of digital currency into the public eye, and major economies around the world are researching and promoting related technologies.

[0003] Digital currencies are generally issued by national central banks. To achieve high-performance, highly available, and efficient digital currencies, the industry commonly adopts blockchain and distributed ledger technologies or centralized financial account systems based on existing banking systems. However, while blockchain and distributed ledger technologies have many advantages, such as inherent data immutability and distributed consistency, they still have many shortcomings: blockchain technology is still under development, and its current performance may not be sufficient to support the transaction pressure brought about by the large-scale application of digital currencies. Therefore, solutions based on existing centralized banking system architectures are the preferred implementation option, but this approach still has performance bottlenecks in transaction verification.

[0004] To address this issue, an existing technology for achieving controlled anonymity in digital currencies exists. This technology simulates a cash-like transaction model within existing centralized banking systems to enable offline and online digital currency transactions. The digital currency token consists of an original token and several transaction sub-chains. In this existing technology, based on the original token, new transaction sub-chains are continuously appended to the end of the token as the digital currency circulates. After each transaction, a digital signature is generated for the entire token data, and its validity is verified. While this technology effectively enables online and offline digital currency transactions and addresses the issues of token legitimacy and security, it still suffers from redundancy in the verification process and a relatively poor user experience due to performance limitations.

[0005] Therefore, improving the verification performance of digital currencies and enhancing the user experience have become urgent issues to be addressed. Summary of the Invention

[0006] This application provides a method and apparatus for transaction verification, applied in the field of computer technology, and solves the following problems:

[0007] How to improve the verification performance of digital currencies during transactions to enhance user experience.

[0008] To facilitate understanding of the embodiments of this application, some technical concepts appearing in this application will be introduced below. It should be understood that these technical concepts are applied to the embodiments described below, but these embodiments are only some embodiments of the solutions provided by the present invention, so these technical concepts are not necessarily applied to all embodiments of this application.

[0009] Soft wallet: A client-side wallet application implemented on an electronic device, running in a rich execution environment (REE).

[0010] Hardware wallet: A wallet business logic and security module implemented on TEE and SE in conjunction with security hardware features on electronic devices.

[0011] Applet: An application developed and used in SE using the Java Card framework.

[0012] Issuing Institution: The back-end service provider for digital currency issuing institutions, responsible for the verification, synchronization, and auditing of digital currencies.

[0013] Original coin string: An immutable data structure used to represent the value of digital currency. It has a serial number as a unique identifier and carries information such as the issuing institution and amount.

[0014] Institutional signature: Used to prove the legitimacy of the original coin string, it is generated by digitally signing the original coin string with the private key of the digital currency issuing institution.

[0015] Transaction subchain: When two users conduct a transaction, it is appended to the original token token to record the value transfer of a payment transaction, including information such as the transaction amount.

[0016] Coin string certificate: It consists of the original coin string and several transaction sub-chains connected together, and its legality is guaranteed by iterative digital signatures.

[0017] Previous transaction: The data of the previous coin string certificate is appended to a certain transaction subchain on the same coin string certificate.

[0018] Digital signature: A transaction signature appended to the end of a token to prove the legitimacy of the transaction subchain and preceding transactions. It is generated by the payer's private key.

[0019] Double offline transaction: Both parties in a digital currency transaction are offline, and the transaction is generated solely through the transfer of coin tokens via terminal devices. A new transaction sub-chain is appended to the end of the original coin token to indicate the transaction amount. The amount in the last transaction sub-chain represents the value of the new coin token.

[0020] Serial number: As a unique identifier of the original coin string, it is consistent with the concept of serial number on paper money.

[0021] Cryptocurrency String Synchronization: As users use digital currencies, a large number of small-value cryptocurrency strings will gradually accumulate in their hardware wallets. At this time, the performance of the hardware wallet will be affected. Therefore, users need to synchronize with the issuing institution to consolidate the small-value cryptocurrency strings in the wallet into larger-value cryptocurrency strings and redistribute them to the wallet, or deposit them into their bank accounts.

[0022] This application will be described below from several aspects. It is readily understood that these aspects can be implemented individually or in combination. The implementation and beneficial effects of these aspects can be referenced in relation to each other.

[0023] In the description of this application, the last transaction subchain and the last transaction subchain have the same meaning.

[0024] In a first aspect, embodiments of this application provide a transaction verification method. The method is applied to a first electronic device including a Security Element (SE), a Trusted Execution Environment (TEE), and a Rich Execution Environment (REE). The method includes: the REE sending a first transaction request message to the TEE, the first transaction request message including a transaction type; the TEE executing first business logic according to the transaction type to obtain a first verification instruction, the first verification instruction including a digital signature to be verified; the TEE sending the first verification instruction to the SE; the SE verifying the legality of the transaction according to the digital signature to be verified to obtain a first verification result, and sending the first verification result to the TEE; the TEE sending a first transaction response message to the REE, the first transaction response message containing the first verification result; and the REE sending a second transaction request message to a second electronic device according to a recipient identifier of the transaction, the recipient identifier indicating the second electronic device, when the first verification result indicates successful verification.

[0025] For example, consider a user initiating a payment request in their REE soft wallet. After negotiating the recipient's address, the user initiates a payment operation in their REE-side soft wallet, sending a payment request message to the TEE. In this example, the aforementioned first transaction request message is the payment request. Upon receiving the payment request message, the TEE executes the first business logic, i.e., the payment business logic, such as basic verifications like the number of transactions and transaction limits, and sends a first verification instruction to the SE. The SE verifies the legality of the payment transaction based on the digital signature and returns the verification result to the TEE for storage. In contrast, in existing technology, after negotiating the recipient's address, the user initiates a payment operation in their REE-side soft wallet and generates a payment instruction that interacts with the SE. The SE then executes the payment business logic and stores the coin string certificate.

[0026] Since the SE in electronic devices is a hardware-isolated independent operating environment with limited storage space and computing performance, this application, compared with the prior art, transfers the first business logic and data storage to the TEE side for implementation, while the SE side retains the transaction legality verification. Under the premise of ensuring security, it makes full use of the edge performance and significantly improves the user experience.

[0027] In one possible implementation, the method further includes the TEE storing at least one candidate data credential.

[0028] In one possible implementation, the TEE executing the first business logic based on the transaction type includes the TEE executing the first business logic based on the transaction type and the at least one candidate data credential.

[0029] In one possible implementation, the method further includes the data certificate being a coin string certificate, the coin string certificate comprising an original coin string or an original coin string and at least one transaction sub-chain, the digital signature being a transaction signature appended to the end of the coin string certificate, used to indicate the legality of the transaction sub-chain, the original coin string comprising the original coin string amount, an issuing institution certificate, and an issuing institution signature, and the transaction sub-chain comprising a sub-chain digital signature corresponding to the transaction sub-chain.

[0030] Specifically, as transactions proceed, each transaction generates a sub-chain. The digital signature of each sub-chain is a digital signature generated based on the digital signature result of the previous transaction and the data of the current transaction, i.e., Signature(n) = Sign(Signature(n-1) + transaction(n)), where Signature(n-1) identifies the digital signature generated in the previous transaction, and transaction(n) represents the information related to the current transaction. This signature method forms an incremental chained signature structure. In existing technologies, the digital signature in each sub-chain is obtained by digesting the data of the entire token certificate; that is, each time a digital signature is generated, all preceding transaction data needs to be signed. Replacing the overall signature scheme with a chained signature scheme reduces redundant digest calculations during the generation and verification of digital signatures for token certificates, improves the performance of token certificate generation and verification on the client side, enhances the client-side user experience, and ensures the legality and integrity of the overall certificate.

[0031] In one possible implementation, the first transaction request message may also include the transaction amount.

[0032] In one possible implementation, the TEE executes a first business logic based on the transaction type and the at least one candidate data certificate. The TEE selects a token to be verified from the at least one candidate token tokens based on the transaction type and the transaction amount. The TEE performs basic verification on the token to be verified, including verification of the number of transactions or transaction limit. The TEE extracts the subchain digital signature of the last transaction subchain of the token that has passed the basic verification and generates a first verification instruction. The subchain digital signature of the last transaction subchain of the token that has passed the basic verification is the digital signature to be verified. The first verification instruction includes the subchain digital signature of the last transaction subchain of the token that has passed the basic verification and the transaction amount.

[0033] Specifically, the TEE selects a token to be verified from the at least one candidate token based on the transaction type and the transaction amount. Specifically, the TEE can select at least one token from all tokens stored in the TEE, starting with tokens with large amounts; it can also select a token with a balance closest to the transaction amount from the tokens stored in the TEE; it can also filter tokens with balances greater than or equal to the transaction amount from the tokens stored in the TEE, and then select at least one token based on a certain algorithm; it can also limit the selection to a specific issuing institution, prioritize tokens with the smallest single balance that meets the transaction amount requirement, or prioritize the integration of multiple small-balance tokens to meet the transaction amount requirement; it can also select tokens according to other rules, which are not particularly limited in this embodiment.

[0034] Specifically, the TEE's basic verification of the token to be verified may include verifying the legality of transaction amount, wallet limit, number of transactions, and transaction limit. Verifying the transaction amount may include verifying whether the balance of the token meets the transaction amount requirements. The balance of the token can be saved in the TEE. Wallet limit, number of transactions, and transaction limit can be preset on the TEE and verified by the TEE; alternatively, wallet limit, number of transactions, and transaction limit can be preset on the SE, then read from the SE into the TEE, and then verified on the TEE. Taking the number of transactions as an example, the number of transactions can be determined by judging the number of transaction subchains or the length of the token to see if it is within the preset limit. It is understood that the aforementioned basic verification is only an example, and this application does not impose any restrictions on the basic verification.

[0035] In one possible implementation, the TEE extracts the subchain digital signature of the last transaction subchain of the coin string certificate that has passed the basic verification, generates the first verification instruction, wherein the subchain digital signature of the last transaction subchain of the coin string certificate that has passed the basic verification is the digital signature to be verified, and the first verification instruction includes the subchain digital signature of the last transaction subchain of the coin string certificate that has passed the basic verification and the transaction amount, and the TEE sends the first verification instruction to the SE.

[0036] Understandably, in some processes, the TEE does not need to send the first verification instruction to the SE. For example, when the TEE does not need the SE to generate a new transaction subchain, such as when reading the total balance of the current wallet, or when it receives a new coin string certificate for the first time and needs to verify it, it does not need to send the first verification instruction to the SE.

[0037] In one possible implementation, the token string certificate that passes the basic verification includes a serial number, which is a unique identifier for the token string certificate that passes the basic verification. The SE verifies the legality of the transaction based on the digital signature to be verified to obtain a first verification result, including: the SE generating transaction information based on the transaction amount in the first verification instruction; the SE comparing a locally stored reference digital signature with the sub-chain digital signature of the last transaction sub-chain in the first verification instruction based on the serial number; when the locally stored reference digital signature matches the sub-chain digital signature of the last transaction sub-chain in the first verification instruction, the SE generates a digital signature corresponding to the transaction based on the transaction information, the sub-chain digital signature of the last transaction sub-chain, and the private key stored locally by the SE; the SE generates a transaction sub-chain corresponding to the transaction based on the digital signature corresponding to the transaction and the transaction information, where the sub-chain digital signature in the transaction sub-chain is the digital signature corresponding to the transaction; and the SE generates a first verification result including the transaction sub-chain corresponding to the transaction. It is understood that the SE can store the digital signature corresponding to the transaction locally.

[0038] Understandably, if the token to be verified selected by the TEE contains at least one token, the first verification instruction will include the digital signature of the last transaction subchain of each of the at least one token. Upon receiving the first verification instruction, the SE will compare the digital signature of the subchain of each last transaction subchain in the first verification instruction with the reference digital signature stored locally by the SE, based on the serial number. When the reference digital signature stored locally by the SE matches the digital signature of the last transaction subchain, the SE generates a digital signature corresponding to the transaction based on the transaction information, the digital signature of the last transaction subchain, and the private key stored locally by the SE. Understandably, each signature comparison that matches will generate a digital signature corresponding to the transaction, and the SE will generate a transaction subchain corresponding to the transaction based on the digital signature corresponding to the transaction and the transaction information.

[0039] For example, if a transaction initiator initiates a 5 yuan transfer transaction, and the TEE selects five 1 yuan coin chains locally, the TEE will send the digital signature of the last subchain of each of these five 1 yuan coin chains to the SE. Upon receiving this, the SE will compare the digital signatures of the last subchains of these five 1 yuan coin chains from the TEE with the signature information stored locally, based on their serial numbers. Each time a match is found, a digital signature corresponding to the transaction and a corresponding transaction subchain are generated. If the digital signatures of the last subchains of all five coin chains match, the SE will generate five digital signatures and five corresponding transaction subchains. The first verification result will include these five corresponding transaction subchains.

[0040] In one possible implementation, the SE generates a portion of the transaction information in a new transaction subchain based on the transaction amount, the unique identifier of the payee, the unique identifier of the transaction, and the transaction information portion.

[0041] In one possible implementation, the TEE stores the first verification result; the TEE updates the transaction subchain corresponding to the transaction to the coin string certificate that has passed the basic verification based on the serial number.

[0042] In one possible implementation, the method further includes the first electronic device synchronizing the updated coin token that has passed the basic verification to the server. Specifically, the timing of the coin token synchronization can be triggered manually by the user, or automatically when the transaction limit is reached, etc., and this application does not impose any restrictions. It should be noted that when the first electronic device synchronizes the coin token to the server, it can also simultaneously upload other information related to the coin token, such as coin token balance, transaction history, etc.

[0043] In one possible implementation, the method further includes the first electronic device receiving a confirmation message from the second electronic device to complete the transaction. After receiving the confirmation message, the first electronic device determines that if the amount on the token has been used up, it marks the token with a deletion flag. After the token is synchronized to the server, if the token is marked with a deletion flag, the server deletes the token.

[0044] In a second aspect, a transaction verification method is provided, characterized in that the method is applied to a second electronic device including a Security Element (SE), a Trusted Execution Environment (TEE), and a Rich Execution Environment (REE), the method comprising: the REE receiving a second transaction request message from a first electronic device and sending the second transaction request message to the TEE, the second transaction request message containing at least one data credential; the TEE executing second business logic based on the at least one data credential to obtain a second verification instruction, the second verification instruction including a digital signature to be verified; the TEE sending the second verification instruction to the SE; the SE verifying the legality of the at least one data credential based on the digital signature to be verified to obtain a second verification result, and sending the second verification result to the TEE, the second verification result indicating whether the legality of the at least one data credential has been verified successfully; the TEE receiving the second verification result from the SE, saving the verified data credential, and sending a second transaction response message to the REE, the second transaction response message indicating whether the transaction was successful; and the REE sending the second transaction response message to the first electronic device.

[0045] Since the SE is a hardware-isolated independent operating environment in electronic devices, its storage space and computing performance are limited. By using the method of this application, the second business logic and data storage are transferred to the TEE side for implementation, while the SE side retains the data credential verification. Under the premise of ensuring security, the performance of the end side is fully utilized, and the user experience is significantly improved.

[0046] In one possible implementation, the data certificate includes a coin string certificate, which includes an original coin string or an original coin string and at least one transaction sub-chain. The original coin string includes the original coin string amount, an issuing institution certificate, and an issuing institution signature. The transaction sub-chain includes a sub-chain digital signature corresponding to the transaction sub-chain.

[0047] Specifically, as transactions proceed, each transaction generates a sub-chain. The digital signature of each sub-chain is a digital signature generated based on the digital signature result of the previous transaction and the data of the current transaction, i.e., Signature(n) = Sign(Signature(n-1) + transaction(n)), where Signature(n-1) identifies the digital signature generated in the previous transaction, and transaction(n) represents the information related to the current transaction. This signature method forms an incremental chained signature structure. In existing technologies, the digital signature in each sub-chain is obtained by digesting the data of the entire token certificate; that is, each time a digital signature is generated, all preceding transaction data needs to be signed. Replacing the overall signature scheme with a chained signature scheme reduces redundant digest calculations during the generation and verification of digital signatures for token certificates, improves the performance of token certificate generation and verification on the client side, enhances the client-side user experience, and ensures the legality and integrity of the overall certificate.

[0048] In one possible implementation, the coin string certificate includes a serial number, which is a unique identifier for the coin string certificate.

[0049] In one possible implementation, the second business logic includes verification of the institutional signature of the original coin string or verification of the preceding transactions of the last transaction subchain of the coin string certificate. Specifically, most of the coin string verification logic can be executed in the TEE, including verification of the institutional signature of the original coin string and verification of the subchain digital signatures of all transaction subchains except the last transaction subchain. The TEE can also perform amount verification, which includes verifying whether the sum of the amounts of the last transaction subchains of at least one coin string certificate is equal. When verifying the digital signature of the last transaction subchain, the TEE obtains the information necessary to verify the subchain digital signature of the last transaction subchain, which may include the subchain digital signature of the penultimate transaction subchain, the information of the last transaction subchain, and the subchain digital signature of the last transaction subchain.

[0050] In one possible implementation, the TEE sends a second verification instruction to the SE, wherein the second verification instruction may include the digital signature of the penultimate transaction subchain, information of the last transaction subchain, and the digital signature of the last transaction subchain. It is understood that the second verification instruction may also include other information capable of verifying the legitimacy of the data credential; this application does not impose any particular limitations.

[0051] It should be noted that in existing technologies, since the digital signature in each transaction subchain is obtained by digesting the data of the entire token certificate, the entire content of the token certificate needs to be completely transmitted from the TEE to the SE during the digital signature generation process. Due to the transmission capacity limitations of the SE, it is not suitable for transmitting or receiving large amounts of data. Therefore, this approach will affect the performance and user experience of dual offline transaction scenarios on the client side. In this application, since the digital signature of each transaction subchain is generated based on the digital signature result of the previous transaction and the data of the current transaction, the information required to generate the digital signature each time is small, thereby breaking through the performance and storage bottlenecks of the SE and improving the transaction performance on the client side.

[0052] In one possible implementation, the SE verifies the legality of the at least one data credential based on the digital signature to be verified to obtain a second verification result, which includes verifying the legality of the last transaction subchain of each of the at least one coin string credentials.

[0053] In one possible implementation, after the legitimacy verification of the last transaction subchain is passed, the SE stores the subchain digital signature of the last transaction subchain. This subchain digital signature is used as a reference value for comparison and verification during subsequent transactions. For example, the legitimacy verification of the last transaction subchain can be achieved by verifying the subchain digital signature.

[0054] In one possible implementation, after the SE verifies the validity of the data credential, it sends a second verification result to the TEE, the second verification result indicating whether the validity of the at least one data credential has been verified.

[0055] In one possible implementation, the TEE receives a second verification result from the SE, stores the verified data credential, and sends a second transaction response message to the REE, the second transaction response message indicating whether the transaction was successful. It is understood that when the validity verification of at least one data credential fails, the TEE, after receiving the second verification result from the SE, does not store the failed data credential.

[0056] In one possible implementation, after receiving the second transaction response message, the REE sends the second transaction response message to the first electronic device. The second transaction response message is used to indicate to the transaction initiator of the first electronic device that the transaction is complete. The second transaction response message may include an identifier indicating whether the transaction was successful or failed, and may also include a random number, which can serve as a unique identifier for the transaction. This random number is negotiated by the transaction initiator and the transaction recipient before the transfer of the coin string certificate. In this embodiment, a confirmation message will be used as an example to illustrate the second transaction response message.

[0057] Due to the chained signature structure of the token token, the digital signature of the subchain of the last transaction can verify the integrity and legitimacy of the overall token information. Therefore, as long as the digital signature of the subchain of the last transaction is generated and verified in SE during on-device interaction, the same security effect can be achieved as if all verification calculations and data were placed in SE.

[0058] In this application, only the digital signature of the last transaction subchain and the user key are stored in the SE. The SE side retains the functions of generating and verifying signatures, while other business logic is implemented on the TEE side. Under the premise of ensuring equivalent security, the performance and storage bottlenecks of the SE are broken, and the transaction performance on the end side is improved.

[0059] In one possible implementation, the method further includes a second electronic device synchronizing the validated data credentials to the server. The timing of data credential synchronization can be triggered manually by the user, or automatically when the transaction limit is reached; this application does not impose any restrictions.

[0060] Thirdly, a method for transaction verification, characterized in that the method is applied to a server and includes:

[0061] Receive data credentials from an electronic device; perform incremental verification on the data credentials, the incremental verification including comparing the data credentials with historical data credentials stored on the server, verifying the legality of data in the data credentials that are not recorded in the historical data credentials; and save the data credentials whose legality verification is successful.

[0062] In existing technologies, during the verification process, the server needs to perform overall verification of all data credentials. Frequent and large-scale verification of data credentials leads to high resource consumption and low performance. This application addresses this by performing incremental verification of data credentials on the server side, verifying only the legality of data in the data credentials that is redundant compared to historical records. This reduces redundant verification calculations, thereby achieving the effect of rapid verification of data credentials and saving server resources in high-concurrency server scenarios.

[0063] In one possible implementation, the historical data certificate is data related to a verified data certificate. It should be noted that when saving historical data certificates, the server may only save the digital signature of the coin string certificate, or it may save the entire coin string certificate. The specific saving format is not limited in this embodiment. In this embodiment, the digital signature of the coin string certificate stored by the server will be used as an example for explanation.

[0064] In one possible implementation, the data certificate includes a coin string certificate, which includes an original coin string or an original coin string and at least one transaction sub-chain. The original coin string includes the original coin string amount, an issuing institution certificate, and an issuing institution signature. The transaction sub-chain includes the transaction amount, transaction information, a public key, and a sub-chain digital signature. The sub-chain digital signature is a digital signature generated based on the digital signature corresponding to the previous transaction and the current transaction data.

[0065] Specifically, as transactions proceed, each transaction generates a transaction subchain. The digital signature in each subchain is generated based on the digital signature of the previous transaction and the data of the current transaction, i.e., Signature(n) = Sign(Signature(n-1) + transaction(n)), where Signature(n-1) identifies the digital signature generated in the previous transaction, and transaction(n) represents the information related to the current transaction. This signature method forms an incremental chained signature structure. In existing technologies, the digital signature in each transaction subchain is obtained by digesting the data of the entire token certificate; that is, each time a digital signature is generated, all preceding transaction data needs to be signed. Replacing the overall signature scheme with a chained signature scheme reduces redundant digest calculations during the generation of digital signatures for token certificates, improves the performance of token certificate generation on the client side, enhances the client-side user experience, and simultaneously ensures the legality and integrity of the overall certificate.

[0066] Understandably, based on the above digital signature generation process, when the coin string certificate is synchronized to the server and the server performs digital signature verification, redundant digest calculations can be reduced, verification performance can be improved, the user experience on the client side can be enhanced, and the overall legality and integrity of the certificate can be guaranteed.

[0067] In one possible implementation, the coin string certificate includes a serial number, which is a unique identifier for the coin string certificate.

[0068] In one possible implementation, comparing the data certificate with historical data certificates stored on the server includes: querying the server to see if a historical coin string certificate corresponding to the serial number exists; if the server has a historical coin string certificate with the same serial number as the coin string certificate, traversing the transaction sub-chains of the coin string certificate and verifying any unverified transaction sub-chains in the coin string certificate that are present in addition to those in the historical coin string certificate. For example, when the server has a historical coin string certificate with the same serial number as the coin string certificate, starting from the original coin string digital signature, traversing the digital signature data of the coin string certificate, comparing each digital signature in the coin string certificate with the nodes of the historical coin string certificate; if any nodes are inconsistent, the verification of the coin string certificate fails; after the traversal is complete, if all transaction sub-chain signatures of the coin string certificate are consistent, the coin string certificate is valid; after all branch nodes of the historical record have been compared, if the coin string certificate still has unverified transaction sub-chain digital signatures, then the remaining transaction sub-chain digital signatures are iteratively verified.

[0069] In one possible implementation, the method further includes verifying all transaction subchains in the coin string certificate when the server does not have a historical coin string certificate with the same serial number as the coin string certificate.

[0070] In one possible implementation, the verification of the transaction subchain includes verifying the digital signature, the issuing institution's signature, the balance, and the transaction history. It is understood that the balance and transaction history can be synchronized to the server along with the coin string certificate.

[0071] In one possible implementation, storing the successfully verified data credential includes storing the verified subchain digital signature of the transaction subchain as a feature data in the server, based on the serial number.

[0072] Specifically, based on the aforementioned chain-structured digital signature scheme, during the synchronization of the token token to the server, the server verifies the validity of the token token. Upon successful verification, the server uses the digital signature value of each transaction sub-chain as a transaction feature and saves the verified transaction data in a specific transaction tree structure. For example, for a user-synchronized token token, after server verification, the server saves the digital signature of each transaction sub-chain of the token token to the server's database. Token tokens with different serial numbers can be saved in different transaction tree structures. This saved data serves as historical records and as reference values ​​for comparison during subsequent verification processes. That is, during the verification of transaction sub-chain signatures for all token tokens, signatures that can be found in the database's transaction tree structure do not need to be repeatedly verified. Only nodes not present in the database need incremental verification, and after successful verification, the verified node is appended to the transaction tree structure for rapid verification of subsequent token tokens.

[0073] During the circulation of digital currency, tokens with the same serial number are continuously split and spread through transactions. Eventually, tokens held by multiple users may contain some duplicate information. During the synchronization process, verified transaction data is stored in a specific transaction tree structure, so that duplicate information in tokens held by different users can be verified by simple data comparison without repeated signature verification, thus reducing the pressure on the server-side digital signature verification.

[0074] Fourthly, in relation to the method provided in the first aspect of this application, embodiments of this application also provide a transaction verification apparatus, which has the function of implementing any of the methods provided in the first aspect. These functions can be implemented by hardware or by hardware executing corresponding software. The hardware or software includes one or more modules corresponding to the above functions. The apparatus can exist in the form of a chip product. Specifically, the transaction verification apparatus can be a first electronic device or a functional module fixed or removable on the first electronic device.

[0075] Fifthly, in relation to the method provided in the second aspect of this application, embodiments of this application also provide a transaction verification apparatus, which has the function of implementing any of the methods provided in the second aspect. These functions can be implemented by hardware or by hardware executing corresponding software. The hardware or software includes one or more modules corresponding to the above functions. The apparatus can exist in the form of a chip product. Specifically, the transaction verification apparatus can be a second electronic device or a functional module fixed or removable on a second electronic device.

[0076] Sixthly, regarding the method provided in the third aspect of this application, embodiments of this application also provide a transaction verification apparatus, which has the function of implementing any of the methods provided in the third aspect. These functions can be implemented by hardware or by hardware executing corresponding software. The hardware or software includes one or more modules corresponding to the above functions. The apparatus can exist in the form of a chip product. Specifically, the transaction verification apparatus can be a server or a functional module that is fixed or removable and installed on the server.

[0077] In a seventh aspect, embodiments of this application provide an electronic device, characterized in that the electronic device includes one or more processors, a memory, and one or more computer programs, wherein the one or more computer programs are stored in the memory, and the one or more computer programs include instructions; when the instructions are executed by the one or more processors, the electronic device performs the method provided by any implementation of the first aspect; or, when the instructions are executed by the one or more processors, the electronic device performs the method provided by any implementation of the second aspect.

[0078] Eighthly, embodiments of this application provide a server, characterized in that the server includes one or more processors, a memory, and one or more computer programs, wherein the one or more computer programs are stored in the memory, and the one or more computer programs include instructions; when the instructions are executed by the one or more processors, the server performs the method provided by any implementation of the third aspect.

[0079] Ninthly, embodiments of this application provide a transaction verification system, characterized in that the system includes a first electronic device, a second electronic device, and a server, wherein the first electronic device is used to execute the operation steps of the method described in the first aspect, the second electronic device is used to execute the operation steps of the method described in the second aspect, and the server is used to execute the operation steps of the method described in the third aspect.

[0080] In a tenth aspect, embodiments of this application provide a storage medium, characterized in that it includes a computer program, which, when run on one or more processors, is used to implement the method provided in any implementation of the first aspect; or, when run on one or more processors, the computer program is used to implement the method provided in any implementation of the second aspect; or, when run on one or more processors, the computer program is used to implement the method provided in any implementation of the third aspect.

[0081] Eleventhly, embodiments of this application provide a computer program or computer program product, characterized in that, when the computer program or computer program product runs on one or more processors, it is used to implement the method provided in any implementation of the first aspect; or, when the computer program or computer program product runs on one or more processors, it is used to implement the method provided in any implementation of the second aspect; or, when the computer program or computer program product runs on one or more processors, it is used to implement the method provided in any implementation of the third aspect.

[0082] In a twelfth aspect, embodiments of this application provide a chip system including at least one processor and at least one interface circuit. The at least one interface circuit is used to perform transceiver functions and send instructions to the at least one processor. When the at least one processor executes instructions, the at least one processor performs the method provided by the first to third aspects described above, and any possible implementation thereof.

[0083] The technical effects of any of the design methods in aspects four through twelfth can be found in the technical effects of different design methods in aspects one, two, or three, and will not be repeated here. Attached Figure Description

[0084] To more clearly illustrate the technical solutions in the embodiments of this application or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are only some embodiments of this application. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0085] Figure 1 A schematic diagram of the system architecture for digital currency verification provided in this application embodiment;

[0086] Figure 2 A schematic diagram of the coin string certificate structure provided for existing technology;

[0087] Figure 3 A schematic diagram of the logical functions of a terminal device provided by existing technology;

[0088] Figure 4 A schematic diagram of the process for dual offline transactions on the client side provided by existing technology;

[0089] Figure 5 A flowchart illustrating a method for verifying digital currency using cloud servers provided by existing technology;

[0090] Figure 6 This is a schematic diagram of the structure of the coin string certificate provided in the embodiments of this application;

[0091] Figure 7 This is a schematic diagram of the logical function of a terminal device provided in an embodiment of this application;

[0092] Figure 8 A schematic diagram of the logical structure for digital currency verification by a cloud-based issuing institution provided in this application embodiment;

[0093] Figure 9 This application provides a schematic diagram of the structure of a server storing a digital signature for a coin string certificate.

[0094] Figure 9a A schematic diagram of a transaction branch provided in an embodiment of this application;

[0095] Figure 9b This is a schematic diagram of another transaction branch provided in an embodiment of this application;

[0096] Figure 10 A schematic diagram illustrating a server-side verification process for digital currency, provided as an embodiment of this application;

[0097] Figure 11 A schematic diagram of a terminal-side dual offline transaction provided for an embodiment of this application;

[0098] Figure 12 A schematic diagram of a first electronic device provided in an embodiment of this application;

[0099] Figure 13 A schematic diagram of a second electronic device provided in an embodiment of this application;

[0100] Figure 14 This is a schematic diagram of a server device provided in an embodiment of this application. Detailed Implementation

[0101] The technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, not all embodiments. Based on the embodiments of this application, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this application.

[0102] In the description of the embodiments of this application, unless otherwise stated, "multiple" means two or more. The term "and / or" or the character " / " in this application is merely a description of the relationship between related objects, indicating that three relationships can exist. For example, A and / or, or A / B, can represent: A existing alone, A and B existing simultaneously, and B existing alone.

[0103] Before introducing the embodiments of this application, to facilitate understanding of the embodiments of this application, a brief introduction to the methods of digital currency verification in the prior art will be given. The following will use a cloud-based system as an example to illustrate the function of the aforementioned server; and a terminal-based system as an example to illustrate the function of the aforementioned electronic device. Specifically, terminal device A will be described as the first electronic device and terminal device B as the second electronic device. In the following description of the digital signature of the subchain of the transaction subchain, the term "digital signature of the transaction subchain" will be used instead.

[0104] The following will use cryptocurrency verification as an example to illustrate the system architecture and process of transaction verification.

[0105] Figure 1 A schematic diagram of the system architecture for digital currency verification provided in this application embodiment.

[0106] For example, the system in this application embodiment is mainly divided into two parts: a cloud-side system and a terminal-side system. The cloud-side system and the terminal-side system can perform coin-to-coin synchronization or online transactions, wherein:

[0107] The cloud-side system includes:

[0108] Digital currency issuing institution back-end system: used for functions such as verification and synchronization of the issuing institution's currency tokens. Figure 1 The following example uses issuer A and issuer B as illustrations. For instance, the issuer could be a bank.

[0109] The Central Bank Institutional Interconnection Platform connects various currency issuing institutions through the central bank, facilitating inter-institutional transaction communication and the central bank's auditing of these institutions. Figure 2 Issuing institution A and issuing institution B connect through the central bank's inter-institutional interconnection platform.

[0110] The edge system includes a secure wallet application for terminal devices. Figure 1 The example illustrates terminal device A and terminal device B. It is understood that a terminal device is a type of electronic device, including but not limited to: terminal devices, fixed electronic devices, and network devices. Specifically, a terminal device can be a mobile terminal device or a fixed terminal device. Electronic devices can be existing electronic devices or future electronic devices.

[0111] For example, the electronic devices in the embodiments of this application may be mobile phones, tablets, computers with wireless transceiver capabilities, personal digital assistants (PDAs), smartwatches, netbooks, wearable electronic devices, augmented reality (AR) devices, virtual reality (VR) devices, in-vehicle equipment, wireless terminals in industrial control, wireless terminals in self-driving, wireless terminals in remote medical care, wireless terminals in smart grids, wireless terminals in transportation safety, wireless terminals in smart cities, wireless terminals in smart homes, artificial intelligence (AI) terminals, etc.

[0112] This application provides a method for verifying digital currency, which can be applied to electronic devices. Hereinafter, a terminal device will be used as an example of an electronic device to describe this application's embodiments. The technical solution provided by this application's embodiments is applicable to terminal devices having a Rich Execution Environment (REE), a Trusted Execution Environment (TEE), and a Secure Element (SE).

[0113] Rich Execution Environment (REE) module: also known as a general execution environment, it is the execution environment of the operating system and various applications above it. For example, a client wallet application implemented on a terminal device, also known as a software wallet, runs in the terminal device's REE environment.

[0114] Trusted Execution Environment (TEE) module: Implemented based on ARM's TrustZone technology, this technology creates a secure zone on the main processor of mobile devices (including smartphones, tablets, set-top boxes, smart TVs, etc.) to ensure the security, confidentiality, and integrity of code and data loaded into this environment. The execution space provided by TEE offers a higher level of security than that provided by common mobile operating systems (such as Linux, Android, etc.). TEE is typically used to run critical operations: (1) Mobile payments: fingerprint verification, PIN code input, etc.; (2) Confidential data: secure storage of private keys, certificates, etc.; (3) Content includes: DRM (Digital Rights Management), etc. TEE can provide security services for REE.

[0115] Secure Element (SE) module: This is a microprocessor chip used to store sensitive data and execute secure applications. It can be used in scenarios such as identity authentication, digital signatures, and secure storage. It is a hardware-based, independent operating environment that does not share system resources with the host machine, offering the highest level of security. However, due to its independent processing unit, its processing power is limited. Common applications include SIM cards issued by mobile operators, encrypted SD cards from some security companies, or independent chip modules built into devices.

[0116] Different terminal devices within the edge system can conduct offline transactions. Taking a dual offline transaction between terminal device A and terminal device B as an example, a dual offline transaction means that both parties using digital currency are offline, and the transaction is generated only by the transfer of coin tokens through the terminal devices. This transaction will append a new transaction sub-chain to the end of the original coin token, and the new transaction sub-chain will mark the transaction amount. The amount of the transaction sub-chain at the end represents the value of the new coin token.

[0117] based on Figure 1 The system architecture shown below illustrates the process of generating and verifying digital signatures for digital currencies in existing technologies.

[0118] like Figure 2 The diagram shown is a schematic representation of the structure of a coin string certificate in the prior art.

[0119] Specifically, the original coin string contains essential information such as the amount issued, the issuing institution, and the serial number, and is signed by the issuing institution. As the currency circulates, transaction sub-chains are continuously appended to the end, and the entire set of data is signed at the end of each transaction. The digital certificate structure of the currency consists of a sequence structure composed of the original coin string and transaction sub-chains. Each certificate transfer generates a new transaction sub-chain, and a digital signature is added to ensure data integrity and validity.

[0120] For example, such as Figure 2As shown, based on the original coin string, after a transaction, the endpoint generates digital signature 1 based on the data from the original coin string and the data from this transaction. This digital signature 1 is used to verify the legitimacy of transaction subchain 1. Transaction 1 and digital signature 1 constitute transaction subchain 1. When a second transaction occurs, digital signature 2 is generated based on the original coin string and the data related to the second transaction in transaction subchain 1. This digital signature 2 is used to verify the legitimacy of transaction subchain 2. Transaction subchain 1 contains digital signature 1, and transaction 2 and digital signature 2 constitute transaction subchain 2. This process continues.

[0121] In existing technologies, each digital signature generation requires signing all preceding transaction data as a whole. Therefore, redundant digest calculations exist in the process of generating digital signatures for token certificates. Under this implementation, since the signing method of the token certificate transaction sub-chain is to sign the entire data, the verification process of the token certificate requires verifying the digital signature layer by layer. The digest calculation process in the digital signature verification process also contains redundant calculations.

[0122] like Figure 3 The diagram shown is a logical function diagram of a terminal device in the prior art.

[0123] Specifically, in the context of digital currency, the hardware wallet logic of the terminal device is mainly implemented in the Applet application on the SE side, which defines the necessary interfaces and data for the hardware wallet transaction process. The main interface functions include: balance inquiry, cryptocurrency string synchronization, transfer in and out, and cryptocurrency string verification; the main data includes user keys, digital currency string certificates, transaction records, and institutional certificates, among which the user key is used to identify the identities of both parties in the transaction.

[0124] TEE is only used to store simple user identification information such as fingerprint password, face, communication key, etc., among which the communication key is used for encryption of the channel when communicating between devices.

[0125] The following explanation uses a money transfer transaction as an example, covering the payment and receipt processes.

[0126] like Figure 4 The diagram shown illustrates the process of existing edge-side dual offline transactions. The specific steps are as follows:

[0127] Steps S401-S402: The payer initiates a payment request in the REE soft wallet, and REE generates a payment instruction to interact with SE;

[0128] Step S403: After receiving the payment instruction, the payer SE executes the corresponding logic to prepare the transaction, such as balance verification;

[0129] Steps S404-S405: The payer SE appends the transaction subchain to the end of the coin string certificate to generate a new coin string certificate, and returns the coin string certificate to REE;

[0130] Step S406: After generating a payment instruction based on the new coin string certificate, the payer REE sends it to the payee;

[0131] Step S407: The payee REE transmits the payment instruction to the SE;

[0132] Steps S408-S409: The receiving party (SE) verifies the coin string certificate. After successful verification, the coin string certificate is saved locally.

[0133] Steps S410-S412: The payee returns transaction confirmation information, and the payer completes the transaction after receiving it.

[0134] like Figure 5 The diagram shown illustrates a process flow for a cloud server-based method for verifying digital currency using existing technology. The specific steps are as follows:

[0135] Step S501: The end user connects to the issuing institution's server and uploads a token with N transaction sub-chains, as well as the balance and transaction flow data related to the token.

[0136] Steps S502-S506: The cloud server parses the token certificate data, extracts the digital signatures of the transaction sub-chains from the token certificate from back to front, and verifies them sequentially using the corresponding signature algorithms such as the national cryptographic algorithm.

[0137] Steps S507-S508: After all the signatures of the transaction sub-chains have been verified, extract the institutional signature and the original coin string data, and verify the legality of the original coin string using the institutional signature and the original coin string data; if the institutional signature verification of the original coin string fails, the verification process fails, as shown in step S511, and the process ends.

[0138] Steps S509-S510: After the institutional signature verification of the original coin string is passed, verify the validity of the balance and transaction history. If the verification is successful, the coin string certificate is valid and the verification process ends.

[0139] The existing technologies described above can effectively realize online and offline digital currency transactions and solve the issues of legality and security of offline currency tokens. However, they still have shortcomings such as redundant calculations in the verification process and poor user experience due to performance limitations. The reasons for these shortcomings are as follows:

[0140] From the client-side perspective: Each transfer of the token certificate adds a transaction sub-chain, and each addition requires digital signatures for all certificate data, putting pressure on the client-side signature verification. The hardware wallet logic of the terminal device is mainly implemented in the SE (Secure Instance), while the TEE (Terminal Equipment Environment) is only used to store simple user identification information such as fingerprints and facial recognition. The terminal SE is a hardware-isolated, independent operating environment with limited storage space and computing performance. The security of the client-side TEE is slightly lower than that of the SE, but its performance is much higher. Currently, most of the business logic is implemented in the SE, while the TEE only implements simple functions and does not fully utilize its performance.

[0141] From the server-side analysis: During the server-side verification of coin token certificates, since the signature method of the coin token transaction subchain is to sign the entire data, the verification process requires layer-by-layer signature verification, resulting in redundant calculations in the digest calculation process during signature verification. At the same time, during the circulation of digital currency, coin tokens with the same serial number will spread to different user terminals, and there will inevitably be some duplicate information in the coin token certificates of different users. After the coin token certificates uploaded by different users, there will be duplicate transaction subchain signature verifications.

[0142] To address the aforementioned issues, embodiments of this application provide a method for verifying digital currency, which is based on... Figure 1 The system architecture shown here, and the main technical points of this method are as follows:

[0143] 1. The digital signature of the token uses a chain structure: As transactions proceed, each transaction generates a sub-chain. The digital signature in each sub-chain is generated based on the signature result of the previous transaction and the data of the current transaction, i.e., Signature(n) = Sign(Signature(n-1) + transaction(n)). Here, Signature(n-1) identifies the digital signature generated in the previous transaction, and transaction(n) represents the information related to the current transaction. This signature method creates an incremental chain-like signature structure.

[0144] 2. Due to the chain structure of the token token, the digital signature of the last transaction sub-chain can verify the integrity and legality of the overall token token information. Therefore, during the client-side interaction, the business logic on the SE side is transferred to the TEE side for execution, while the digital signature verification process to ensure transaction legality is retained in the SE.

[0145] 3. After receiving the synchronized token from the client, the cloud server constructs a token transaction tree. It stores the digital signatures of verified transaction sub-chains in a tree structure. During the verification process, incremental verification is performed on the digital signatures of the transaction sub-chains. For all tokens, signatures that can be found in the transaction tree structure of the database do not need to be verified repeatedly. Only nodes that do not exist in the database need to be incrementally verified. After successful verification, the verified node is appended to the transaction tree structure for rapid verification of subsequent tokens.

[0146] like Figure 6 The diagram shown is a structural schematic of the coin string certificate provided in an embodiment of this application.

[0147] As transactions proceed, each transaction generates a subchain. The digital signature in each subchain is generated based on the signature of the previous transaction and the data of the current transaction, i.e., Signature(n) = Sign(Signature(n-1) + transaction(n)). Here, Signature(n-1) identifies the digital signature generated in the previous transaction, and transaction(n) represents information related to the current transaction. Understandably, this signature method forms an incremental chained signature structure.

[0148] For example, such as Figure 6 As shown, based on the original coin string, after a transaction, the endpoint generates digital signature 1 based on the data from the original coin string and the data from this transaction. This digital signature 1 is used to verify the legitimacy of transaction subchain 1. Transaction 1 and digital signature 1 constitute transaction subchain 1. When a second transaction occurs, digital signature 2 is generated based on digital signature 1 and the data related to the second transaction. This digital signature 2 is used to verify the legitimacy of transaction subchain 2. Transaction 2 and digital signature 2 constitute transaction subchain 2, and so on.

[0149] To simplify the explanation of the chained signature principle, the digital signature in the transaction sub-chain and the institutional signature in the original coin string are presented separately. In implementation, the transaction sub-chain can contain digital signatures, and the original coin string can contain institutional signatures.

[0150] Replacing the overall signature scheme with a chained signature scheme reduces redundant digest calculations during the generation and verification of digital signatures for coin string certificates, improves the performance of coin string certificate generation and verification on the client side, enhances the client-side user experience, and ensures the legality and integrity of the overall certificate.

[0151] like Figure 7 The diagram shown is a logical function diagram of the terminal device provided in the embodiment of this application.

[0152] For example, the terminal device includes a rich execution environment (REE), a trusted execution environment (TEE), and a secure element (SE).

[0153] In terminal devices, the Trusted Execution Environment (TEE) implements most of the logic in the cryptocurrency transaction process, including balance inquiry, coin string synchronization, and transfers in and out. It also stores fingerprint passwords, communication keys, institutional certificates, cryptocurrency strings, and transaction records. The TEE's computing performance and storage space are superior to the SE, thus fully utilizing the terminal's performance to improve the user experience.

[0154] The Security Element (SE) defines two essential aspects of the hardware wallet transaction process: interfaces and data. The interfaces primarily verify the digital signature of the last transaction subchain of the token certificate, used by the recipient to verify the legitimacy of the incoming token certificate. The data primarily consists of the digital signature of the last transaction subchain of the token certificate, used by the payer to ensure that the token on the TEE side has not been tampered with before the transaction. When the token certificate data on the payer's TEE is tampered with, the digital signature of the last transaction subchain will also change. If this change is found to be inconsistent with the digital signature stored in the SE when the token certificate was received, the verification fails. When the recipient receives a valid token certificate, they will verify the digital signature of the last transaction subchain in the SE. Upon successful verification, the digital signature of the last transaction subchain corresponding to the token certificate will be stored in the SE. Therefore, transaction security is still guaranteed by the SE, but performance is significantly improved by using the TEE.

[0155] like Figure 8 The diagram shown is a logical structure diagram of the digital currency verification of the cloud-based issuing institution provided in the embodiments of this application.

[0156] In the issuance structure, the functions of each logical module are as follows:

[0157] Coin String Certificate Parsing: Parses the contents of each part of the coin string certificate from the data uploaded by users, mainly extracting the institutional signature and the digital signature of the transaction subchain;

[0158] Digital signature verification: According to the chain signature method in the present invention, the legality of all digital signatures on the coin string certificate is verified, and the verified digital signatures are saved to the storage structure of the transaction tree;

[0159] Transaction tree storage: When digital currency is uploaded to the issuing institution's backend, each unique serial number generates a tree structure composed of nodes representing digital signature information. The traversal path from the root to a leaf node represents the transaction chain of a coin string certificate. After multiple users holding the same serial number coin string operate synchronously, the resulting tree structure represents the entire circulation and transfer process of the original coin string.

[0160] Serial Number Lookup: In the backend storage of the issuing institution, the corresponding verification data can be retrieved based on the serial number of the coin string certificate, that is, the transaction tree associated with the serial number;

[0161] Digital signature comparison: Traverse the digital signature data in the coin string certificate and compare it with the verified transaction tree nodes. If an unverified node is found, perform incremental verification on these nodes.

[0162] like Figure 9 The diagram shown is a schematic representation of the structure of a digital signature for storing a coin string certificate on a server, as provided in an embodiment of this application.

[0163] Due to the transfer mechanism of cryptocurrency tokens, during the circulation of digital currency, tokens with the same serial number will form such... Figure 9 The topology shown is as follows. The digital signature xn represents the digital signature generated by payer x for the nth payment transaction using the coin string certificate, and it uses payer x's private key.

[0164] When multiple users synchronize their tokens to verify their validity on the server, a tree structure as shown in the figure is constructed and stored in the database. Each node is the digital signature value of the corresponding transaction subchain, and the relationship between the parent node and the child node is determined by the chain signature method defined in the previous token.

[0165] For example, the specific incremental verification method is as follows:

[0166] Taking the token token passing through users A, B, C, and D as an example: A->B->D->F, users D and F synchronize the token token to the cloud server online one after another.

[0167] like Figure 9a The diagram shown is a schematic representation of a transaction branch provided in an embodiment of this application.

[0168] After user D synchronizes the coin string certificate, it forms the following: Figure 9a The transaction branches are defined as follows: line b represents a payment from user A to user B, and line d represents a payment from user B to user D. When this transaction branch is generated for the first time, a complete legality verification is required. The verification includes: the institutional signature of the original coin string; verifying digital signature A-1 based on the content of transaction sub-chain b and the institutional signature; and verifying digital signature B-1 based on the content of transaction sub-chain d and digital signature A-1. Similarly, if the transaction sub-chain is longer, the signature can be verified iteratively.

[0169] like Figure 9b The diagram shown illustrates another transaction branch provided in this application embodiment. After user F synchronizes the coin string certificate, it forms a... Figure 9bThe transaction branches b and d can be confirmed to be valid by a simple comparison of signature values. The digital signature verification of user F only needs to verify the transaction f from user D to user F and the digital signature D-1.

[0170] Based on the above architecture diagram and the coin string certificate structure diagram, the following will describe in detail two specific embodiments.

[0171] like Figure 10 The diagram shown is a schematic representation of a server-verified digital currency process according to an embodiment of this application. The method may include steps S1001-S1010, as detailed below:

[0172] Step S1001: During the synchronization process, the user uploads the coin string certificate to the issuing institution's server.

[0173] In this step, users need to upload the tokens in their wallets that need to be synchronized to the corresponding issuing institution for verification, based on the information in the original token. The information in the original token described here can include the issuing institution's identifier, token amount, institution certificate, and reserved fields. Each token in this step needs to carry complete information including: the original token amount, issuing institution certificate, issuing institution signature, and the transaction subchain generated for each transaction. Each transaction subchain also includes: transaction amount, transaction information including the transaction index, payer's public key, and payer's signature. We declare the number of transaction subchains for a token as N.

[0174] Step S1002: Query the corresponding verification data based on the serial number of the coin string.

[0175] This step is performed before the actual verification of the digital signature of the token. First, the serial number information is extracted from the token, and then the database is queried to see if there is a verified record for that serial number.

[0176] If no record is found, proceed to steps S1009-S1010, which involves verifying the digital signature of each transaction subchain in a manner consistent with existing solutions. See details in [link to process details]. Figure 5 Then, the digital signature data of each transaction subchain is used as nodes to build a branch structure starting from the institutional signature of the original coin string, which is used for the rapid verification of subsequent coin string certificates. At this point, the process ends.

[0177] If a verified record exists, proceed to steps S1003-S1008:

[0178] Step S1003: Compare the digital signature of the local currency string voucher with the verified digital signature stored in the branch node. In this step, it is necessary to traverse the digital signature data of the currency string voucher starting from the institutional signature of the original currency string and compare it with the node data of the verified branch.

[0179] Step S1004: Determine whether there are inconsistent nodes. If there are nodes with inconsistent data, the verification of this currency string voucher fails and the process ends. Otherwise, execute steps S1005 - S1008.

[0180] Steps S1005 - S1008: Obtain the number M of verified transaction sub - chains.

[0181] If M >= N, the digital signatures of all transaction sub - chains of the currency string voucher are consistent, then this currency string voucher is valid, the verification is successful, and the process ends.

[0182] If M < N, it means that there are still digital signatures of un - verified transaction sub - chains in the currency string voucher. Then iterate to verify the digital signatures of the remaining transaction sub - chains, and save the digital signatures of the verified transaction sub - chains on the appended branch node for the subsequent quick verification of the currency string voucher. After all digital signatures are verified effectively, it proves that the currency string voucher is valid and other verification processes can be carried out, such as transaction flow verification, balance verification, etc.

[0183] As Figure 11 shown, it is a schematic diagram of the process of end - side dual - offline transactions provided by an embodiment of this application. This process includes the schematic diagram of the process between two terminal devices for offline transactions. In the actual application process, there are also other scenarios, such as online processes, single - offline processes (including the payer being online and the payee being offline, or the payer being offline and the payee being online). It can be understood that when the actual application scenario is a single - offline process, the processes of the payer or the payee locally are the same as those of the payer or the payee in the dual - offline process respectively.

[0184] The specific steps are as follows:

[0185] Step S1101: The user operates the wallet App on the REE side to initiate a payment request.

[0186] In this step, the payer user negotiates the target address of the payee through other channels and sends a payment request to the TEE according to the corresponding TEE interface.

[0187] Step S1102: The payer TEE reads the currency string voucher stored in the TEE and generates a payment instruction.

[0188] In this step, the TEE selects a suitable coin string based on the payment amount. After basic verification within the TEE, the digital signature at the end of the coin string certificate is extracted and transmitted to the SE. Basic verification includes verifying the validity of the transaction amount; or verifying the validity of initial setting limits such as wallet limits, transaction counts, and transaction limits. This limit information can be saved to either the TEE or the SE. If saved to the SE, it can be read from the SE and verified by the TEE. The transaction count can be determined by the number of transaction subchains or the length of the coin string certificate.

[0189] Step S1103: The payer (SE) executes the payment instruction logic;

[0190] Step S1104: The payer SE compares the digital signature received from TEE with the digital signature of the last transaction subchain saved after the previous transaction was verified. If the digital signature of the last transaction subchain of this transaction is consistent with the digital signature in SE, it can be proven that the coin string data in TEE has not been tampered with, because the digital signature of the last transaction subchain stored in SE has not been changed in SE since the last transaction was completed.

[0191] Steps S1105-S1106: The payer SE generates a new transaction subchain and returns the new transaction subchain to the payer TEE.

[0192] This step generates transaction subchain data based on the transaction amount required by the payer for this transaction and random numbers or other reserved fields. It also generates a new transaction signature based on the digital signature of the last transaction subchain of the previous transaction and the data of the current transaction subchain. Finally, the transaction information and digital signature are concatenated into a new transaction subchain and returned to the TEE, wherein the SE generates transaction information based on the transaction amount.

[0193] Step S1107: The payer TEE splices the new transaction subchain returned by SE onto the original coin string certificate, generates a payment instruction, and sends it to the payee.

[0194] Step S1108: The payee REE transmits the payment request to the TEE. After receiving the payment request, the TEE executes the payment logic and extracts all the data of the coin string certificate from the payment request.

[0195] Steps S1109-S1113: The payee verifies the coin string certificate in collaboration with the TEE and SE.

[0196] This application transmits a signature verification instruction: only the end signature is included; currently, only the newly generated coin string signature is saved.

[0197] The existing technology uses a payment instruction, which includes the entire coin string; previously, SE stored the entire coin string.

[0198] In this step, the payee executes most of the token string verification logic within the TEE, including institutional signature verification of the original token string, balance verification, and digital signature verification of the transaction sub-chains. When verifying the digital signature of the last transaction sub-chain, the necessary information for last signature verification is passed to the SE via a verification command. This necessary information includes the digital signature of the second-to-last transaction sub-chain, the information of the last transaction sub-chain, and the digital signature of the last transaction sub-chain itself. After successful verification in the SE, the digital signature of the last transaction sub-chain is saved in the SE for comparison and verification before payment in subsequent transactions. Simultaneously, the verification result is returned to the TEE. The TEE confirms the verification result, stores the new token string certificate locally, and sends a confirmation message to the payer upon successful verification.

[0199] Steps S1114-S1115: The payer receives the confirmation information, verifies it, and completes the transaction. If the amount in the coin string is exhausted, the coin string identifier is deleted. Subsequently, when the coin string voucher is synchronized to the server, the server will delete the coin string voucher based on this identifier. It is understood that the confirmation information here is an example of the second transaction response message described above.

[0200] The above is a detailed description of the digital currency verification method provided in the embodiments of this application.

[0201] The foregoing primarily describes the solutions of the embodiments of this application from a methodological perspective. It is understood that, in order to achieve the aforementioned functions, the digital currency verification device includes corresponding hardware structures and / or software modules for executing each function. Those skilled in the art should readily recognize that, based on the units and algorithm steps of the various examples described in conjunction with the embodiments disclosed herein, this application can be implemented in hardware or a combination of hardware and computer software. Whether a function is executed in hardware or by computer software driving hardware 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 implementation should not be considered beyond the scope of this application.

[0202] This application embodiment can divide the digital currency verification device into functional units based on the above method example. For example, each function can be divided into separate functional units, or two or more functions can be integrated into one processing unit. The integrated unit can be implemented in hardware or as a software functional unit. It should be noted that the unit division in this application embodiment is illustrative and only represents one logical functional division; other division methods may be used in actual implementation.

[0203] In one example, when dividing functional units according to various functions, such as Figure 12 The diagram shown is a schematic representation of a first electronic device according to an embodiment of this application. The device 1200 includes a Rich Execution Environment (REE) module 1201, a Trusted Execution Environment (TEE) module 1202, and a Security Element (SE) module 1203.

[0204] The Rich Execution Environment (REE) module 1201 is used to: send a first transaction request message to the Execution Environment (TEE) module, wherein the first transaction request message includes the transaction type and the transaction recipient identifier;

[0205] The Trusted Execution Environment (TEE) module 1202 is used to: execute a first business logic according to the transaction type to obtain a first verification instruction, and send the first verification instruction to the Security Unit (SE) module 1203, wherein the first verification instruction contains a digital signature;

[0206] The security unit (SE) module 1203 is used to: verify the legality of the transaction based on the digital signature to obtain a first verification result, and send the first verification result to the trusted execution environment (TEE) module;

[0207] The Trusted Execution Environment (TEE) module 1202 is further configured to: send a first transaction response message to the Rich Execution Environment (REE) module, wherein the first transaction response message includes the first verification result;

[0208] The Rich Execution Environment (REE) module 1203 is further configured to: send a second transaction request message to a second electronic device based on the recipient identifier.

[0209] In one possible design, the Trusted Execution Environment (TEE) module 1202 is also used to store at least one data credential; and to execute the first business logic according to the transaction type and the at least one data credential.

[0210] One possible design is that the data certificate includes a coin string certificate, which includes an original coin string or an original coin string and at least one transaction sub-chain. The transaction sub-chain includes a digital signature used to indicate the legality of the transaction sub-chain. The original coin string includes the original coin string amount, an issuing institution certificate, and an issuing institution signature.

[0211] In one possible design, the first transaction request message further includes a transaction amount; the Trusted Execution Environment (TEE) module 1202 is specifically used to: select at least one token from the at least one token token based on the transaction type and the transaction amount; perform basic verification on the selected at least one token token, the basic verification including verification of the number of transactions or the transaction limit; after the basic verification is passed, extract the digital signature of the last transaction subchain of each token token in the at least one token token, and generate a first verification instruction including the digital signature of the last transaction subchain of each token token and the transaction amount.

[0212] One possible design is that the token string certificate includes a serial number, which is a unique identifier for the token string certificate; the security unit SE module 1203 is specifically used for: generating transaction information based on the transaction amount in the first verification instruction; comparing the locally stored signature with the digital signature of the last transaction sub-chain in the first verification instruction based on the serial number; when the locally stored signature matches the digital signature of the last transaction sub-chain in the first verification instruction, generating a second digital signature based on the transaction information, the digital signature of the last transaction sub-chain, and the locally stored private key; generating a new transaction sub-chain based on the second digital signature and the transaction information; and generating a first verification result including the new transaction sub-chain.

[0213] One possible design is that the Trusted Execution Environment (TEE) module 1202 is specifically used to update the new transaction subchain onto the coin string certificate based on the serial number.

[0214] In one possible design, the Rich Execution Environment (REE) module 1203 is also used to synchronize the data credentials to the server.

[0215] like Figure 13 The diagram shown is a schematic representation of a second electronic device according to an embodiment of this application. The device 1300 includes a Rich Execution Environment (REE) module 1301, a Trusted Execution Environment (TEE) module 1302, and a Security Element (SE) module 1303.

[0216] The Rich Execution Environment (REE) module 1301 is used to: receive a second transaction request message from a first electronic device and send the second transaction request message to the Trusted Execution Environment (TEE) module 1302. The second transaction request message contains at least one data credential, wherein the data credential includes a serial number, which is a unique identifier of the data credential.

[0217] The Trusted Execution Environment (TEE) module 1302 is used to: execute a second business logic based on the at least one data credential to obtain a second verification instruction, and send the second verification instruction to the Security Element (SE) module 1303, wherein the second verification instruction includes a digital signature;

[0218] The security unit SE module 1303 is used to: verify the legality of the at least one data credential based on the digital signature to obtain a second verification result, and send the second verification result to the Trusted Execution Environment (TEE) module 1302, wherein the second verification result indicates whether the legality of the at least one data credential has been verified.

[0219] The Trusted Execution Environment (TEE) module 1302 is further configured to: receive the second verification result from the Security Unit (SE) module 1303, save the verified data credential, and send a second transaction response message to the Rich Execution Environment (REE) module 1301, wherein the second transaction response message is used to indicate whether the transaction is successful.

[0220] The Rich Execution Environment (REE) module 1301 is also used to: send a second transaction response message to the first electronic device.

[0221] One possible design is that the data certificate includes a coin string certificate, which includes an original coin string or an original coin string and at least one transaction sub-chain. The transaction sub-chain includes a digital signature used to indicate the legality of the transaction sub-chain. The original coin string includes the original coin string amount, an issuing institution certificate, and an issuing institution signature.

[0222] One possible design is that the second business logic includes institutional signature verification of the original coin string or verification of the preceding transaction of the last transaction subchain of the coin string certificate.

[0223] One possible design is that the security element SE module 1303 is specifically used to verify the legitimacy of the last transaction subchain of each of the at least one data credential.

[0224] In one possible design, the security unit SE module 1303 is also used to save the digital signature of the last transaction subchain after the legality verification of the last transaction subchain is passed. The digital signature is used as a reference value for comparison and verification in subsequent transactions.

[0225] like Figure 14 The diagram shown is a schematic representation of a server apparatus according to an embodiment of this application. The apparatus 1400 includes:

[0226] Receiver module 1401 is used to receive data credentials from electronic devices;

[0227] The verification module 1402 is used to perform incremental verification on the data credential. The incremental verification includes comparing the data credential with the historical records stored on the server to verify the legality of the data credential containing data that is redundant compared to the historical records. The historical records are verified historical data credentials.

[0228] The storage module 1403 is used to store the data credentials that have been successfully verified.

[0229] One possible design is that the data certificate includes a coin string certificate, which includes an original coin string or an original coin string and at least one transaction sub-chain. The original coin string includes the original coin string amount, an issuing institution certificate, and an issuing institution signature. The transaction sub-chain includes the transaction amount, transaction information, a public key, and a digital signature. The digital signature is a digital signature generated based on the signature result of the previous transaction and the current transaction data.

[0230] One possible design is that the token token includes a serial number, which is a unique identifier for the token token; the verification module 1402 is specifically used to query whether the server has a historical token token corresponding to the serial number. When the server has a historical token token with the same serial number as the token token, the module traverses the transaction sub-chains of the token token and verifies the unverified transaction sub-chains in the token token that are more numerous than those in the historical token token.

[0231] One possible design is that the verification module 1402 is specifically used to verify all transaction subchains in the coin string certificate when the server does not have a historical coin string certificate with the same serial number as the coin string certificate.

[0232] One possible design is that the verification module 1402 is specifically used to verify digital signatures, issuing institution signatures, balances, and transaction records.

[0233] In one possible design, the storage module 1403 is specifically used to store the verified digital signature of the transaction subchain as feature data in the server based on the serial number.

[0234] The specific implementation of the schemes involved in the device embodiments can be referred to the foregoing method embodiments, and will not be repeated here.

[0235] When multiple functional units (or modules) are integrated into a single processing unit, the actions performed by each functional unit can be executed by the processing unit according to the program stored in the storage unit. The processing unit can be a processor or a controller. The storage unit can be a memory. When the processing unit is a processor and the storage unit is a memory, the actions performed by each functional unit can be executed by the processor according to the program stored in the memory.

[0236] This application also provides a computer-readable storage medium including instructions that, when run on a computer, cause the computer to perform the above-described method.

[0237] This application also provides a computer program or computer program product containing instructions that, when run on a computer, cause the computer to perform the above-described method.

[0238] In the above embodiments, implementation can be achieved, in whole or in part, through software, hardware, firmware, or any combination thereof. When implemented using software programs, implementation can be, in whole or in part, in the form of a computer program product. This computer program product includes one or more computer instructions. When the computer program instructions are loaded and executed on a computer, all or part of the processes or functions described in the embodiments of this application are generated. The computer can be a general-purpose computer, a special-purpose computer, a computer network, or other programmable device. The computer instructions can be stored in a computer-readable storage medium or transmitted from one computer-readable storage medium to another. For example, computer instructions can be transmitted from one website, computer, server, or data center to another via wired (e.g., coaxial cable, fiber optic, digital subscriber line (DSL)) or wireless (e.g., infrared, wireless, microwave, etc.) means. The computer-readable storage medium can be any available medium accessible to a computer or a data storage device containing one or more servers, data centers, etc., that can be integrated with the medium. The available media can be magnetic media (e.g., floppy disks, hard disks, magnetic tapes), optical media (e.g., DVDs), or semiconductor media (e.g., solid-state disks (SSDs)).

[0239] Although this application has been described herein in conjunction with various embodiments, those skilled in the art, by reviewing the accompanying drawings, the disclosure, and the appended claims, will understand and implement other variations of the disclosed embodiments in carrying out the claimed application. In the claims, the word "comprising" does not exclude other components or steps, and "a" or "an" does not exclude multiple instances. A single processor or other unit can implement several functions listed in the claims. While different dependent claims may recite certain measures, this does not mean that these measures cannot be combined to produce good results.

[0240] Although this application has been described in conjunction with specific features and embodiments, it will be apparent that various modifications and combinations can be made therein without departing from the spirit and scope of this application. Accordingly, this specification and drawings are merely exemplary illustrations of the application as defined by the appended claims, and are to be considered as covering any and all modifications, variations, combinations, or equivalents within the scope of this application.

Claims

1. A method for transaction verification, characterized in that, The method is applied to a first electronic device including a Security Element (SE), a Trusted Execution Environment (TEE), and a Rich Execution Environment (REE), and the method includes: The REE sends a first transaction request message to the TEE, the first transaction request message including the transaction type; The TEE executes a first business logic according to the transaction type to obtain a first verification instruction, the first verification instruction including a digital signature to be verified. The TEE sends the first verification command to the SE; The SE verifies the legality of the transaction based on the digital signature to be verified to obtain a first verification result, and sends the first verification result to the TEE; The TEE sends a first transaction response message to the REE, the first transaction response message containing the first verification result; When the first verification result indicates successful verification, the REE sends a second transaction request message to the second electronic device based on the recipient identifier of the transaction, wherein the recipient identifier is used to instruct the second electronic device; The TEE stores at least one candidate data certificate; the data certificate includes a token string certificate, which includes a serial number, and the serial number is the unique identifier of the token string certificate; so that the server can query whether there is a historical token string certificate corresponding to the serial number. When the server has a historical token string certificate with the same serial number as the token string certificate, it traverses the transaction subchains of the token string certificate and verifies the unverified transaction subchains in the token string certificate that are more numerous than those in the historical token string certificate.

2. The method according to claim 1, characterized in that, The TEE executes the first business logic based on the transaction type, including: The TEE executes the first business logic based on the transaction type and the at least one candidate data credential.

3. The method according to claim 2, characterized in that, The coin string certificate also includes the original coin string or the original coin string and at least one transaction sub-chain. The original coin string includes the original coin string amount, the issuing institution certificate, and the issuing institution signature. The transaction sub-chain includes the sub-chain digital signature corresponding to the transaction sub-chain.

4. The method according to claim 3, characterized in that, The first transaction request message also includes the transaction amount; The TEE executes the first business logic based on the transaction type and the at least one candidate data credential, including: The TEE selects a token to be verified from at least one candidate token based on the transaction type and the transaction amount. The TEE performs basic verification on the token to be verified, including verification of the number of transactions or transaction limit. The TEE extracts the digital signature of the last subchain of the coin string certificate that has passed the basic verification, and generates the first verification instruction. The digital signature of the last subchain of the coin string certificate that has passed the basic verification is the digital signature to be verified. The first verification instruction includes the digital signature of the last subchain of the coin string certificate that has passed the basic verification and the transaction amount.

5. The method according to claim 4, characterized in that, The SE verifies the legality of the transaction based on the digital signature to be verified to obtain a first verification result, including: The SE generates transaction information based on the transaction amount in the first verification instruction; The SE compares the locally stored reference digital signature with the subchain digital signature of the last transaction subchain in the first verification instruction based on the serial number. When the locally stored reference digital signature matches the subchain digital signature of the last transaction subchain in the first verification instruction, the SE generates a digital signature corresponding to the transaction based on the transaction information, the subchain digital signature of the last transaction subchain, and the private key stored locally by the SE. The SE generates a transaction subchain corresponding to the transaction based on the digital signature corresponding to the transaction and the transaction information, wherein the digital signature of the subchain in the transaction subchain corresponding to the transaction is the digital signature corresponding to the transaction; The SE generates a first verification result that includes the transaction subchain corresponding to the transaction.

6. The method according to claim 5, characterized in that, The TEE stores the first verification result; The TEE updates the transaction subchain corresponding to the transaction to the coin string certificate that has passed the basic verification based on the serial number.

7. The method according to claim 6, characterized in that, The method further includes: The first electronic device synchronizes the updated coin string certificate that has passed the basic verification to the server.

8. A method for transaction verification, characterized in that, The method is applied to a second electronic device including a Security Element (SE), a Trusted Execution Environment (TEE), and a Rich Execution Environment (REE). The method includes: The REE receives a second transaction request message from the first electronic device and sends the second transaction request message to the TEE, wherein the second transaction request message contains at least one data credential; The TEE executes a second business logic based on the at least one data credential to obtain a second verification instruction, the second verification instruction including a digital signature to be verified. The TEE sends the second verification command to the SE; The SE verifies the legality of the at least one data credential based on the digital signature to be verified to obtain a second verification result, and sends the second verification result to the TEE. The second verification result indicates whether the legality of the at least one data credential has been verified. The TEE receives the second verification result from the SE, saves the verified data certificate, and sends a second transaction response message to the REE, the second transaction response message being used to indicate whether the transaction was successful; The REE sends a second transaction response message to the first electronic device; The data certificate includes a coin string certificate, which includes a serial number, and the serial number is a unique identifier for the coin string certificate. This allows the server to query whether there is a historical coin string certificate corresponding to the serial number. When the server has a historical coin string certificate with the same serial number as the coin string certificate, it traverses the transaction subchains of the coin string certificate and verifies the unverified transaction subchains in the coin string certificate that are more numerous than those in the historical coin string certificate.

9. The method according to claim 8, characterized in that, The coin string certificate also includes the original coin string or the original coin string and at least one transaction sub-chain. The original coin string includes the original coin string amount, the issuing institution certificate, and the issuing institution signature. The transaction sub-chain includes the sub-chain digital signature corresponding to the transaction sub-chain.

10. The method according to claim 9, characterized in that, The second business logic includes the institutional signature verification of the original coin string or the verification of the preceding transactions of the last transaction subchain of the coin string certificate.

11. The method according to claim 9, characterized in that, The SE verifies the legitimacy of the at least one data credential based on the digital signature to be verified to obtain a second verification result, including: Verify the validity of the last transaction subchain of each coin string certificate in at least one coin string certificate.

12. The method according to claim 11, characterized in that, The method further includes: After the legality verification of the last transaction subchain is passed, the SE saves the digital signature of the last transaction subchain. The digital signature of the last transaction subchain is used as a reference value for comparison and verification in subsequent transactions.

13. A method for transaction verification, characterized in that, The method is applied to a server and includes: Receive data credentials from electronic devices; Incremental verification is performed on the data credentials, which includes comparing the data credentials with historical data credentials stored on the server to verify the legality of data in the data credentials that are not recorded in the historical data credentials. Save the data credential that has been successfully verified for legitimacy; The data certificate includes a coin string certificate, which includes a serial number, and the serial number is the unique identifier of the coin string certificate; Comparing the coin string certificate with the historical coin string certificates stored on the server includes: querying the server to see if there is a historical coin string certificate corresponding to the serial number; when the server has a historical coin string certificate with the same serial number as the coin string certificate, traversing the transaction sub-chains of the coin string certificate and verifying the unverified transaction sub-chains in the coin string certificate that are more numerous than those in the historical coin string certificates.

14. The method according to claim 13, characterized in that, The coin string certificate includes an original coin string or an original coin string and at least one transaction sub-chain. The original coin string includes the original coin string amount, the issuing institution certificate, and the issuing institution signature. The transaction sub-chain includes the transaction amount, transaction information, public key, and sub-chain digital signature. The sub-chain digital signature is a digital signature generated based on the digital signature corresponding to the previous transaction and the current transaction data.

15. The method according to claim 14, characterized in that, The method further includes verifying all transaction subchains in the coin string certificate when the server does not have a historical coin string certificate with the same serial number as the coin string certificate.

16. The method according to claim 13 or 15, characterized in that, Verifying the transaction subchain includes verifying the subchain's digital signature, the issuing institution's signature, the balance, and the transaction history.

17. The method according to claim 16, characterized in that, The data credential for successfully verifying the legitimacy includes storing the digital signature of the verified subchain of the transaction subchain as a feature data in the server, based on the serial number.

18. A first electronic device, characterized in that, The first electronic device includes a Rich Execution Environment (REE) module, a Trusted Execution Environment (TEE) module, and a Security Element (SE) module. The Rich Execution Environment (REE) module is used to: send a first transaction request message to the Execution Environment (TEE) module, wherein the first transaction request message includes the transaction type of the transaction; The Trusted Execution Environment (TEE) module is used to: execute a first business logic according to the transaction type to obtain a first verification instruction, and send the first verification instruction to the Security Element (SE), wherein the first verification instruction contains a digital signature; The security unit (SE) module is used to: verify the legality of the transaction based on the digital signature to obtain a first verification result, and send the first verification result to the trusted execution environment (TEE) module; The Trusted Execution Environment (TEE) module is further configured to: send a first transaction response message to the Rich Execution Environment (REE) module, wherein the first transaction response message contains the first verification result; The Rich Execution Environment (REE) module is further configured to: when the first verification result indicates successful verification, send a second transaction request message to the second electronic device according to the recipient identifier of the transaction, wherein the recipient identifier is used to indicate the second electronic device; The Trusted Execution Environment (TEE) module is further configured to: store at least one candidate data credential; the data credential includes a coin string credential, the coin string credential includes a serial number, and the serial number is the unique identifier of the coin string credential; This enables the verification module in the server to: query whether the server has a historical coin string certificate corresponding to the serial number; when the server has a historical coin string certificate with the same serial number as the coin string certificate, traverse the transaction sub-chain of the coin string certificate and verify the unverified transaction sub-chains in the coin string certificate that are more numerous than those in the historical coin string certificate.

19. The first electronic device according to claim 18, characterized in that, The Trusted Execution Environment (TEE) module is also used for: The first business logic is executed based on the transaction type and the at least one candidate data credential.

20. The first electronic device according to claim 19, characterized in that, The coin string certificate also includes the original coin string or the original coin string and at least one transaction sub-chain. The original coin string includes the original coin string amount, the issuing institution certificate, and the issuing institution signature. The transaction sub-chain includes the sub-chain digital signature corresponding to the transaction sub-chain.

21. The first electronic device according to claim 20, characterized in that, The first transaction request message also includes the transaction amount; The Trusted Execution Environment (TEE) module is specifically used for: Select a token to be verified from at least one candidate token based on the transaction type and the transaction amount. The token to be verified is subjected to basic verification, which includes verification of the number of transactions or transaction limit. Extract the subchain digital signature of the last transaction subchain of the coin string certificate that has passed the basic verification, and generate the first verification instruction. The subchain digital signature of the last transaction subchain of the coin string certificate that has passed the basic verification is the digital signature to be verified. The first verification instruction includes the subchain digital signature of the last transaction subchain of the coin string certificate that has passed the basic verification and the transaction amount.

22. The first electronic device according to claim 21, characterized in that, The security unit (SE) module is specifically used for: Transaction information is generated based on the transaction amount in the first verification instruction; The local stored reference digital signature is compared with the subchain digital signature of the last transaction subchain in the first verification instruction based on the serial number. When the local stored reference digital signature is consistent with the subchain digital signature of the last transaction subchain in the first verification instruction, a digital signature corresponding to the transaction is generated based on the transaction information, the subchain digital signature of the last transaction subchain, and the locally stored private key. A transaction subchain corresponding to the transaction is generated based on the digital signature corresponding to the transaction and the transaction information, wherein the digital signature of the subchain in the transaction subchain corresponding to the transaction is the digital signature corresponding to the transaction; Generate a first verification result including the transaction subchain corresponding to the transaction.

23. The first electronic device according to claim 22, characterized in that, The Trusted Execution Environment (TEE) module is specifically used for: Update the transaction subchain corresponding to the transaction to the coin string certificate that has passed the basic verification according to the serial number.

24. The first electronic device according to claim 23, characterized in that, The Rich Execution Environment (REE) module is also used to synchronize the updated coin string credentials that have passed the basic verification to the server.

25. A second electronic device, characterized in that, The second electronic device includes a Rich Execution Environment (REE) module, a Trusted Execution Environment (TEE) module, and a Security Element (SE) module. The Rich Execution Environment (REE) module is used to: receive a second transaction request message from a first electronic device, and send the second transaction request message to the Trusted Execution Environment (TEE) module, wherein the second transaction request message contains at least one data credential; The Trusted Execution Environment (TEE) module is used to: execute a second business logic based on the at least one data credential to obtain a second verification instruction, and send the second verification instruction to the Security Element (SE) module, wherein the second verification instruction includes a digital signature to be verified. The security unit (SE) module is used to: verify the legality of at least one data credential based on the digital signature to be verified to obtain a second verification result, and send the second verification result to the trusted execution environment (TEE) module, wherein the second verification result indicates whether the legality of at least one data credential has been verified. The Trusted Execution Environment (TEE) module is further configured to: receive the second verification result from the Security Unit (SE) module, save the verified data credentials, and send a second transaction response message to the Rich Execution Environment (REE) module, wherein the second transaction response message is used to indicate whether the transaction was successful. The Rich Execution Environment (REE) module is also used to: send a second transaction response message to the first electronic device; The data certificate includes a token string certificate, which includes a serial number, which is a unique identifier for the token string certificate. This enables the verification module in the server to: query whether the server has a historical token string certificate corresponding to the serial number; and when the server has a historical token string certificate with the same serial number as the token string certificate, traverse the transaction sub-chains of the token string certificate to verify the unverified transaction sub-chains in the token string certificate that are present in addition to those of the historical token string certificates.

26. The second electronic device according to claim 25, characterized in that, The coin string certificate also includes the original coin string or the original coin string and at least one transaction sub-chain. The original coin string includes the original coin string amount, the issuing institution certificate, and the issuing institution signature. The transaction sub-chain includes the sub-chain digital signature corresponding to the transaction sub-chain.

27. The second electronic device according to claim 26, characterized in that, The second business logic includes the institutional signature verification of the original coin string or the verification of the preceding transactions of the last transaction subchain of the coin string certificate.

28. The second electronic device according to claim 25, characterized in that, The security unit (SE) module is specifically used for: Verify the validity of the last transaction subchain of each coin string certificate, which is at least one coin string certificate.

29. The second electronic device according to claim 28, characterized in that, The security unit SE module is also used for: After the legality verification of the last transaction subchain is passed, the digital signature of the last transaction subchain is saved. The digital signature of the last transaction subchain is used as a reference value for comparison and verification in subsequent transactions.

30. A server, characterized in that, It includes a receiving module, a verification module, and a storage module: The receiving module is used to: receive data credentials from an electronic device; The verification module is used to: perform incremental verification on the data credential, the incremental verification including comparing the data credential with historical data credentials stored on the server, and verifying the legality of data of the data credential that is not recorded in the historical data credentials; The storage module is used to: store the data credentials that have been successfully verified for legitimacy; The data certificate includes a coin string certificate, which includes a serial number, and the serial number is the unique identifier of the coin string certificate; The verification module is specifically used to: query whether the server has a historical coin string certificate corresponding to the serial number; when the server has a historical coin string certificate with the same serial number as the coin string certificate, traverse the transaction sub-chain of the coin string certificate and verify the unverified transaction sub-chains in the coin string certificate that are more numerous than those in the historical coin string certificate.

31. The server according to claim 30, characterized in that, The coin string certificate includes an original coin string or an original coin string and at least one transaction sub-chain. The original coin string includes the original coin string amount, the issuing institution certificate, and the issuing institution signature. The transaction sub-chain includes the transaction amount, transaction information, public key, and sub-chain digital signature. The sub-chain digital signature is a digital signature generated based on the digital signature corresponding to the previous transaction and the current transaction data.

32. The server according to claim 31, characterized in that, The verification module is specifically used for: When the server does not have a historical coin string certificate with the same serial number as the coin string certificate, all transaction sub-chains in the coin string certificate are verified.

33. The server according to claim 30 or 32, characterized in that, The verification module is specifically used for: Verify the subchain digital signature, the issuing institution's signature, the balance, and the transaction history.

34. The server according to claim 30 or 32, characterized in that, The storage module is specifically used for: The verified digital signature of the subchain of the transaction subchain is stored as a feature data in the server according to the serial number.

35. An electronic device, characterized in that, The electronic device includes a memory and one or more processors, the one or more processors being coupled to the memory: The memory is used to store programs; The one or more processors are configured to execute a program in the memory, causing the electronic device to perform the method as described in any one of claims 1-7; or, causing the electronic device to perform the method as described in any one of claims 8-12.

36. A server, characterized in that, The server includes a memory and one or more processors, the one or more processors being coupled to the memory. The memory is used to store programs; The one or more processors are configured to execute a program in the memory, causing the server to perform the method as described in any one of claims 13-17.

37. A transaction verification system, characterized in that, The system includes: The first electronic device according to any one of claims 18 to 24, the second electronic device according to any one of claims 25 to 29, and the server according to any one of claims 30 to 34.

38. A computer-readable storage medium, characterized in that, Includes a computer program, which, when run on one or more processors, is configured to implement the method as described in any one of claims 1-7; or to implement the method as described in any one of claims 8-12; or to implement the method as described in any one of claims 13-17.

Images