A multi-device cooperative offline account fund processing method

Abstract

The application discloses a kind of off-line account fund processing methods of multi-device cooperation, comprising: using server for each device allocation device fingerprint starting point, and current account balance is stored in trusted execution environment as check reference, when it is identified that user is to positive offline transaction, generate positive transaction fingerprint and store in local pending area, marked as unconfirmed, by identifying the distance between devices, screening short-distance equipment, each device sends unconfirmed transaction information to each other, and cooperates sequencing using arbitration rule, obtain global transaction sequence list, update transaction state according to this, execute deduction for confirmed transaction and update fingerprint and store in fingerprint chain area;For rejected transaction, prompt user and clear from pending area, after arbitration, each device exchanges the latest fingerprint chain head, and anchor information is stored in check area, with the help of fingerprint chain and pending area short-distance negotiation, effectively solve the problem of storage bottleneck and balance conflict under offline environment, make offline transaction conflict rate tend to zero, significantly reduce merchant dispute.

Description

Technical Field

[0001] This invention relates to the field of funds processing technology, and in particular to a method for offline account funds processing involving multiple devices. Background Technology

[0002] With the rapid development of mobile payment technology, offline transactions, as an important supplement to online transactions, have a wide range of application needs in scenarios such as signal blind spots, network congestion, and temporary network outages of devices. Especially in closed or semi-closed scenarios such as canteens, convenience stores, and park restaurants, multiple payment terminals need to provide fast payment services to a large number of users simultaneously, and the instability of the network environment makes offline transaction capability a key guarantee for system availability.

[0003] Existing offline transaction solutions typically involve both parties generating transaction documents locally on their terminal devices, and then uploading the transaction data to the server for settlement after the devices reconnect to the network. However, this approach has the following technical drawbacks in practical applications:

[0004] First, the trusted execution environment storage space of the device is extremely limited, typically only a few hundred KB to several MB. When the device needs to process a large number of small, high-frequency transactions while offline, storing complete transaction details one by one can easily exhaust storage resources, causing the device to be unable to process new transactions. At the same time, after the device is connected to the network, it needs to upload massive amounts of transaction details, resulting in low clearing efficiency and high network transmission overhead.

[0005] Secondly, when multiple offline payment terminals are deployed in the same scenario, each device records transaction information independently, lacking an effective real-time communication and coordination mechanism. When the same user's account balance is consumed simultaneously on multiple devices, each device cannot detect the amount deducted by other devices, resulting in insufficient account balance to cover all consumption during online clearing. Some transactions fail, but the goods have already been taken, leading to disputes between merchants and users.

[0006] Third, existing offline transaction systems assume that once a transaction is confirmed and written to the storage chain, it is irrevocable by default. However, in actual operation, due to reasons such as incorrect menu items, repeated facial recognition, incorrect amount entry, or equipment malfunction, operators may need to temporarily cancel completed transactions. Since the cancellation operation is only performed on a single device, other devices cannot know that the transaction has been canceled, resulting in canceled transactions still being considered as valid fund usage by other devices, leading to fund conflict issues.

[0007] Fourth, the existing cancellation mechanism only supports canceling the most recent transaction and cannot handle the reverse rollback of multiple transactions coupled across devices and time. When it is necessary to cancel an earlier transaction that has been relied upon by multiple subsequent transactions, direct cancellation will disrupt the balance calculation benchmark of subsequent transactions, resulting in inconsistencies in the fund accounts.

[0008] Fifth, malicious users may exploit the information delay between offline devices, making a purchase on device A and immediately requesting cancellation, then using the same funds to make another purchase on device B before receiving the cancellation synchronization information, thus achieving inter-period arbitrage and causing financial losses to merchants. Summary of the Invention

[0009] This application provides a method for offline account fund processing with multi-device collaboration. By negotiating with the local pending area through a transaction fingerprint chain, it effectively solves the storage bottleneck and balance conflict problem of multiple POS terminals in a completely offline environment. By caching unconfirmed transactions in the pending area, and by using short-distance communication between devices to collaboratively sort, simulate deductions, and reject excessive transactions in advance, the offline transaction conflict rate approaches zero, significantly reducing merchant disputes.

[0010] This application provides a method for offline account fund processing with multi-device collaboration, including:

[0011] S101: Use the server to assign a device fingerprint starting point to each device, obtain the current account balance information of the device, and store the current account balance information in the trusted execution environment as a verification benchmark.

[0012] S102, Identify the user's offline transaction behavior. When it is a positive transaction behavior, collect the transaction information of the user's offline transaction account, generate a positive transaction fingerprint based on the transaction information, and store the positive transaction fingerprint in the local pending area, marking the transaction status of the pending area as unconfirmed; the transaction behavior includes positive transaction behavior and negative transaction behavior;

[0013] S103, identify the distance between multiple devices, use a threshold to filter short-distance devices based on the identified distance between multiple devices, each short-distance device sends unconfirmed transaction information in its local pending area, when other short-distance devices receive transaction information from the other short-distance device, use the adjudication rules to make a collaborative adjudication, obtain a global transaction order list, and update the transaction status in the pending area based on the global transaction order list;

[0014] S104, deduct funds and update the positive transaction fingerprint according to the transaction status marked as confirmed in the global transaction sequence list, and store the updated positive transaction fingerprint in the fingerprint chain area; for the transaction status marked as rejected in the global transaction sequence list, the device displays a prompt message to the user and removes the transaction status marked as rejected from the pending area;

[0015] S105, after collaborative adjudication, each short-range device sends the latest fingerprint chain head, and the receiving short-range device stores the anchoring information in its own verification area; until the detection device is connected to the network, it uploads the current latest fingerprint chain head, chain length, transaction status marked as confirmed in the global transaction order list, updated transaction fingerprint, and information in the verification area to the server.

[0016] Preferably, the method for obtaining the current account balance information of the device is as follows: When the device connects to the network, the server verifies the legality of the device, registers its identifier and public key, and generates a random number for each device as the starting point of the device fingerprint. The fingerprint is encrypted with the device's public key and signed by the server before being sent out. The trusted execution environment of the device decrypts and verifies the signature with its private key, stores the starting point of the fingerprint in the starting slot of the fingerprint chain, initializes the chain head pointer and sets the chain length to zero. The server adds a timestamp and account identifier to the balance and generates a balance certificate. The balance and certificate are stored in the balance reference slot of the trusted execution environment to complete the establishment of the offline verification reference.

[0017] Preferably, the step of using a threshold to filter short-range devices is as follows: when a device is offline and there are unconfirmed transactions in the waiting area, the device periodically sends its own device information, scans other device information in the vicinity, and records the device identifier and received signal strength indication. The physical distance to each discovered device is calculated based on the received signal strength indication, and a distance threshold is set. When the physical distance is less than or equal to the distance threshold, it is determined to be a short-range device.

[0018] Preferably, the method for obtaining the global transaction order list is as follows: the selected short-distance devices are selected to elect a coordinating device based on the device identifier hash value. Each device reads unconfirmed transactions from the pending area to generate a transaction summary, which is then exchanged via short-distance communication broadcast and merged to form a transaction summary set. After being sorted in ascending order by timestamp and device identifier hash, the deductions are simulated one by one starting from the account balance. Transactions that result in a negative balance are marked as conflicts and removed. Finally, the remaining non-conflicting transactions constitute the global transaction order list.

[0019] Preferably, the offline account fund processing method further includes:

[0020] S201, if the user's behavior is found to meet the reverse rule, the transaction behavior is determined to be a reverse transaction behavior, and the fingerprint of the reverse transaction behavior is obtained;

[0021] S202, based on the determined reverse transaction behavior, a collaborative decision is made among multiple short-range devices, and the reverse transaction information is transmitted to all other short-range devices. After receiving the reverse transaction information, the other short-range devices update their device fingerprint chains to form a unified fingerprint chain containing both forward and reverse fingerprint information.

[0022] S203, when merging the unified fingerprint chain of multiple short-range devices, uses conflict rules to detect and eliminate reversal conflicts; at the same time, it performs pairwise cancellation through forward and reverse transactions to compress the fingerprint chain.

[0023] Preferably, the reverse rules include user cancellation, duplicate transactions, device malfunction, and system revocation. User cancellation refers to the user actively canceling the transaction, and customer service confirms it on the device. When the system detects that the same user has made consecutive transactions of the same amount on the same device within a short period of time, it is determined to be a duplicate transaction. Device malfunction refers to the device detecting a hardware abnormality. System revocation refers to the supermarket causing the transaction to be unable to be confirmed during the collaborative adjudication stage, and the system automatically initiates the revocation.

[0024] Preferably, the offline account funds processing method further includes:

[0025] S301, Construct a transaction dependency table and a rollback set based on the device's trusted execution environment. The transaction dependency table is used to store the dependencies between transactions.

[0026] S302, the trusted execution environment of the device determines the transaction fingerprint and the preceding dependency fingerprint of the new transaction, updates the dependency count and calculates the dependency depth based on the preceding dependency fingerprint, appends the transaction fingerprint of the new transaction to the unified fingerprint chain, updates the chain head of the unified fingerprint chain, and stores the dependency information in the transaction dependency table; the dependency information refers to the dependency count and dependency depth.

[0027] S303, when a user requests to cancel a target forward transaction, the device's trusted execution environment extracts the count of subsequent transactions depending on the transaction from the transaction dependency table, and determines whether it can be directly canceled based on the count of subsequent transactions depending on the transaction; if the determination result is that it cannot be directly canceled, a reverse rollback is performed. The reverse rollback involves constructing a rollback list, sorting the rollback list according to the dependency depth, and rolling back according to the order in the rollback list until the user's requested forward transaction is canceled; if the determination result is that it can be directly canceled, then the cancellation is performed.

[0028] S304 calculates the arbitrage risk coefficient based on the total amount of cancelled transactions and the amount of completed transactions, identifies the risk level based on the arbitrage risk coefficient, and controls different levels accordingly.

[0029] One or more technical solutions provided in this application have at least the following technical effects or advantages: By negotiating with the local pending area through the transaction fingerprint chain, the storage bottleneck and the problem of multiple device balance conflicts in a completely offline environment are effectively solved. By caching unconfirmed transactions in the pending area, and by using short-distance communication between devices to coordinate sorting, simulate deduction and reject over-limit transactions in advance, the offline transaction conflict rate approaches zero, significantly reducing merchant disputes.

[0030] It solves the conflict problem caused by the irrevocability of transactions once confirmed and the inability to propagate revocation information across devices. Revocation conflict detection can be completed through linear scanning, and through short-distance broadcast synchronization and pairwise cancellation compression mechanism, it realizes reliable propagation of revocation information among multiple devices, controllable long-term storage, and suppression of malicious revocation behavior, thereby achieving complete traceability of forward and reverse transactions and global consistency of revocation.

[0031] By using dependency counting and dependency depth, the complex graph structure is simplified into a linearly processable counting mechanism, reducing the computation and storage overhead of TEE. All descendant transactions of the transaction to be revoked are collected and revoked in descending order of dependency depth (revoking the nearest dependent transaction first and the target transaction last), ensuring balance consistency after rollback, eliminating fund conflicts, quantifying user revocation behavior, and dynamically adjusting offline permissions through three-level risk control, effectively suppressing malicious arbitrage. Attached Figure Description

[0032] Figure 1 This is a flowchart illustrating a multi-device collaborative offline account fund processing method according to the present invention.

[0033] Figure 2 This is a schematic diagram illustrating the process of forming a unified fingerprint chain according to the present invention;

[0034] Figure 3 This is a schematic diagram of the process of executing reverse rollback for the target transaction of this invention. Detailed Implementation

[0035] To facilitate understanding of the present invention, a more complete description of this application will be given below with reference to the accompanying drawings, which illustrate preferred embodiments of the invention. However, the invention can be implemented in many different forms and is not limited to the embodiments described herein. Rather, these embodiments are provided to enable a more thorough and complete understanding of the disclosure of the present invention.

[0036] It should be noted that the terms "vertical," "horizontal," "up," "down," "left," "right," and similar expressions used in this article are for illustrative purposes only and do not represent the only possible implementation.

[0037] Unless otherwise defined, all technical and scientific terms used herein have the same meaning as commonly understood by one of ordinary skill in the art to which this invention pertains; the terminology used herein in the description of the invention is for the purpose of describing particular embodiments only and is not intended to limit the invention; the term "and / or" as used herein includes any and all combinations of one or more of the associated listed items.

[0038] Example 1: Figure 1This is a flowchart illustrating a multi-device collaborative offline account funds processing method according to an embodiment of the present invention, including:

[0039] S101: Use the server to assign a device fingerprint starting point to each device, obtain the current account balance information of the device, and store the current account balance information in the trusted execution environment as a verification benchmark.

[0040] Specifically, each device is equipped with a unique Device ID and a pair of asymmetric keys (public and private keys) at the factory. The private key is stored in the device's Trusted Execution Environment (TEE) and cannot be exported. When a device connects to the network, the server verifies the device. After confirming the device's legitimacy, the server registers the device's Device ID and public key in the server's device management list. The server generates a device fingerprint starting point for each device. The device fingerprint starting point is a 256-bit truly random number generated by the server's random number generator. The server encrypts the device fingerprint starting point using the device's public key and attaches its signature. After receiving the encrypted data from the server, the TEE decrypts it using its internal private key to obtain the device fingerprint starting point. The TEE also verifies the server signature to confirm that the device fingerprint starting point was issued by a legitimate server. After successful verification, the TEE stores the device fingerprint starting point in the fingerprint chain starting slot, initializes the current fingerprint chain head pointer to the device fingerprint starting point, and records the chain length as zero.

[0041] When the device connects to the network for the first time, it sends a request to the server through a secure channel to identify the real-time balance of the current user account. The request includes the device's identity token and retrieves the account balance. The server uses its private key to add a timestamp and account identifier signature to the balance to obtain a balance certificate. The server generates balance information based on the account balance and the balance certificate and sends the balance information to the device. After receiving the balance information, the device uses the server's public key to verify it. If the verification finds that the signature is invalid or the timestamp is out of reasonable range, it refuses to accept the information and sends an error message requesting a re-acquisition. After successful verification, the TEE writes the account balance to the balance reference slot in its secure storage and saves the balance certificate. After the device completes the above storage, it has built an offline verification reference.

[0042] S102, Identify the user's offline transaction behavior. When it is a positive transaction behavior, collect the transaction information of the user's offline transaction account, generate a positive transaction fingerprint based on the transaction information, and store the positive transaction fingerprint in the local pending area, marking the transaction status of the pending area as unconfirmed; the transaction behavior includes positive transaction behavior and negative transaction behavior;

[0043] Furthermore, for positive transactions, when a user transacts on the device, the device captures a facial image. The TEE calls the local facial recognition module for detection and identity comparison to confirm the user's identity and obtain their corresponding account identifier. The device checks the current network connection status; if it cannot connect to the server, it determines that it is currently in offline transaction mode. The TEE records the current offline flag and initiates the offline transaction process. The user enters the transaction amount on the device, and the TEE receives and temporarily stores the amount. The TEE reads the fingerprint at the head of the current fingerprint chain from the storage area. If this is the first transaction, the chain head is the starting point of the device fingerprint assigned by the server during initialization. The TEE reads the current timestamp and Device ID, extracts the corresponding user account identifier from the facial recognition result, and combines the obtained amount, timestamp, device ID, and account identifier into an internal structure, i.e., transaction information. The transaction information is then concatenated into a binary string according to a predetermined format, with the expression: ,in, It is a binary string. This is the positive transaction fingerprint of the previous transaction. When i=1, This refers to the starting point of the device fingerprint assigned by the server in S101. This is the consumption amount for this transaction. The timestamp when the transaction occurred. A unique device identifier for the consumer machine that executes the transaction. A de-identified identifier for user accounts, used to distinguish different users, is set using the HMAC-SHA256 algorithm. This hash value is the de-identified identifier for the user account. The TEE calls the SHA-256 hash function to calculate the 256-bit hash value on the input string, which is the positive transaction fingerprint. The expression is: ,in, This serves as the positive transaction fingerprint for this transaction. This is a hash function that outputs a fixed-length 256-bit hash value. The string is a binary string. The TEE sets up a local pending area in memory. Both the pending area and the fingerprint chain area are logical partitions in the non-volatile storage space inside the Trusted Execution Environment (TEE). They share the same physical storage medium, but are isolated in address space by the TEE's memory management unit and do not overlap. The total physical storage capacity is determined according to the device hardware specifications. The local pending area stores unconfirmed transactions in the form of a list. The TEE creates an entry for a transaction, which includes a positive transaction fingerprint, transaction summary, status field and sequence number. The entry is written to the end of the local pending area. At this time, the positive transaction fingerprint of this transaction is only a candidate fingerprint in the pending area. In the status field of the pending area entry, the TEE writes a predefined enumeration value, that is, marks the transaction status of the pending area as unconfirmed, indicating that the transaction has not been coordinated by multiple devices and has not obtained global order recognition.

[0044] S103, identify the distance between multiple devices, use a threshold to filter short-distance devices based on the identified distance between multiple devices, each short-distance device sends unconfirmed transaction information in its local pending area, when each short-distance device receives transaction information from the other short-distance device, it uses the adjudication rules to make a collaborative adjudication, obtains a global transaction order list, and updates the transaction status in the pending area based on the global transaction order list;

[0045] Specifically, when a device is offline and there are unconfirmed transactions in the waiting area, the TEE wakes up the Bluetooth or Wi-Fi module and enters discovery mode. Simultaneously, the device begins periodically sending its own device information, scanning for surrounding Bluetooth or Wi-Fi signals, collecting information about other devices, and recording the device ID and Received Signal Strength Indicator (RSSI). The physical distance to each discovered device is calculated based on the RSSI using the following formula: ,in, The physical distance between the device and the detection device. For transmission power, all devices participating in offline transactions will uniformly fix their transmission power at +4 dBm. The received power index (RSSI) is read in real time by the device's Bluetooth / Wi-Fi chipset. Let 1 meter be the reference RSSI, n be the environmental attenuation factor, and a distance threshold be set. The calculated physical distance is compared with the preset distance threshold. When the physical distance is less than or equal to the preset distance threshold, it is determined to be a short-range device. All short-range devices are selected as the coordinating device according to the hash value of their Device IDs. The short-range device with the largest hash value is selected as the coordinating device. The coordinating device generates a temporary key and communicates with the device via Bluetooth or Wi-Fi. The encrypted channel is distributed to all participating short-range devices. Each short-range device's TEE reads all unconfirmed transactions from its local pending area and generates a transaction summary for each unconfirmed transaction. Each short-range device encrypts its own transaction summary using a temporary key and transmits it to all other short-range devices via short-range communication. Each short-range device collects the transaction summaries of other short-range devices, decrypts them using the temporary key, verifies the message format and sequence number, and merges the transaction summaries of all short-range devices to form a transaction summary set. Each transaction is uniquely identified by a positive transaction fingerprint. Based on the transaction summary set, a collaborative adjudication rule is used. The adjudication rule is as follows: all transactions in the transaction summary set are sorted in ascending order by timestamp; if the timestamps are the same, they are sorted in ascending order by the hash value of the device ID as the secondary sorting key; if they are still the same, they are sorted by... The hash values ​​of positive transaction fingerprints are sorted in ascending order. Starting from the initial account balance, each transaction is processed sequentially according to the sorted order. If the transaction is a positive consumption, the balance = balance - amount. If the balance calculation result is negative, a conflict mark is made and removed from the sorted list. After removal, the balance is restored to the value before the transaction was processed. The position of each removed transaction in the original order is recorded. The remaining non-conflicting transactions form a global transaction order list. Each transaction in the global transaction order list is accompanied by a status confirmation that the payment can be made. Deleted transactions are accompanied by a status conflict rejection and are recorded separately in the conflict list. The coordinating device sends the global transaction order list and the conflict list to other short-range devices via short-range communication. After receiving them, other short-range devices verify the coordinator's signature and compare it with their own independently calculated results. If they match, the result is accepted; if they do not match, a renegotiation mode is triggered.

[0046] Each device iterates through the unconfirmed transactions in its local pending area based on the received global transaction order list and conflict list: if a positive transaction fingerprint appears in the global order list, its status is updated from unconfirmed to confirmed, and its position index in the global order is recorded; if a positive transaction fingerprint appears in the conflict list, its status is updated to rejected.

[0047] S104, deduct funds and update the positive transaction fingerprint according to the transaction status marked as confirmed in the global transaction sequence list, and store the updated positive transaction fingerprint in the fingerprint chain area; for the transaction status marked as rejected in the global transaction sequence list, the device displays a prompt message to the user and removes the transaction status marked as rejected from the pending area;

[0048] Furthermore, deductions are made sequentially according to the order of confirmed transaction status in the global transaction order list. For confirmed transactions existing in the local pending area, the TEE accumulates the transaction amounts to obtain the cumulative confirmed amount. The TEE reads the currently stored balance from the balance base slot, subtracts the cumulative confirmed amount from the current stored balance to obtain the latest balance information, writes the latest balance information into the balance base slot, overwriting the old balance information, and records the timestamp of the update, thus obtaining the updated positive transaction fingerprint. For each confirmed transaction in the pending area, the TEE retrieves its updated positive transaction fingerprint and appends the updated positive transaction fingerprint to the end of the fingerprint chain area in the same order as the global order list, forming a new fingerprint chain head. ,in, To add the current transaction, the new chain head of the fingerprint chain, To add the fingerprint chain head before the current transaction, i.e., the chain head value after the last addition, the initial value is the starting point of the device fingerprint. This is the positive transaction fingerprint of the current transaction. The transaction type is marked to indicate that this is a forward transaction, not a reverse cancellation. A unique device identifier for the device executing the transaction. This is a hash algorithm.

[0049] The TEE scans all entries in the local pending area, deletes confirmed entries, and removes confirmed transactions from the pending area list to free up memory space. Transaction information that is still unconfirmed is retained. The device identifies transactions marked as rejected in the pending area based on the conflict list. For each rejected transaction, the TEE returns a rejection reason code to the application layer. The application displays a prompt message on the device screen, such as: Insufficient balance, this transaction failed; please retry after connecting to the network, etc. The TEE writes a rejection record in the internal audit log. The TEE traverses the local pending area and deletes all rejected transactions. The TEE sends a signal to the application layer indicating that the formal deduction and fingerprint chain progress is complete, along with the number of transactions processed, the total deduction amount, and the updated balance snapshot. If there are still unconfirmed transactions remaining in the pending area, the TEE returns to step S103 for short-range device collaborative adjudication.

[0050] S105, after collaborative adjudication, each short-range device sends the latest fingerprint chain head, and the receiving short-range device stores the anchoring information in its own verification area; until the detection device is connected to the network, it uploads the current latest fingerprint chain head, chain length, transaction status marked as confirmed in the global transaction order list, updated transaction fingerprint, and information in the verification area to the server;

[0051] Specifically, after the multi-device short-range collaborative adjudication is completed, and each device has completed formal deduction and fingerprint chain advancement, each participating device automatically triggers a cross-anchoring process. Each short-range device's TEE reads the latest fingerprint chain head from its fingerprint chain area, along with the current fingerprint chain length. The other device ID, timestamp, latest fingerprint chain head, and fingerprint chain length constitute the anchoring information. The short-range device sends the anchoring information to all other participating short-range devices. Upon receiving the anchoring information, the receiving device verifies it. If verification is successful, the anchoring information is stored in its own verification area. The device continuously monitors network connectivity in the background. Once an internet connection is detected as available, online clearing is immediately initiated. The device's TEE reads the latest fingerprint chain head and chain length from the fingerprint chain area, and simultaneously reads the balance value updated from the last balance snapshot. The TEE obtains a summary list of all confirmed transactions since the last online clearing, and reads all stored anchor records from other devices from the verification area. It packages the latest fingerprint chain head, chain length, transaction status marked as confirmed in the global transaction order list, the updated transaction fingerprint, and the information from the verification area into clearing information and uploads it to the server. After receiving and processing the information, the server returns a clearing success confirmation to the device.

[0052] The technical solutions described in the above embodiments of this application have at least the following technical effects or advantages: By negotiating with the local pending area through the transaction fingerprint chain, the storage bottleneck and balance conflict of multiple consumer terminals in a completely offline environment are effectively solved. By caching unconfirmed transactions in the pending area, and by using short-distance communication between devices to coordinate sorting, simulate deduction and reject excessive transactions in advance, the offline transaction conflict rate approaches zero, significantly reducing merchant disputes.

[0053] Example 2: Example 1 solved the storage bottleneck and concurrent balance conflict issues in offline transactions across multiple devices. However, transactions that have been confirmed and written into the fingerprint chain are considered irrevocable by default. When a transaction is revoked on a device, because the revocation operation cannot be propagated to other devices offline, other devices still consider the transaction as valid fund usage, leading to the same fund being mistakenly considered available by other devices after being revoked, causing a conflict. This example designs the revocation operation as a reverse transaction block isomorphic to the forward transaction, directly embedded in the original single fingerprint chain. Reliable propagation and consistent synchronization of revocation information across multiple devices are achieved through cryptographic hash association, thereby eliminating conflicts and maintaining the simplicity and verifiability of the chain structure. Figure 2 As shown.

[0054] S201, if the user's behavior is found to meet the reverse rule, the transaction behavior is determined to be a reverse transaction behavior, and the fingerprint of the reverse transaction behavior is obtained;

[0055] Specifically, reverse rules are set up, including user cancellation, duplicate transactions, device malfunction, and system revocation. User cancellation refers to the user actively canceling the transaction, with customer service confirming it on the device. When the system detects that the same user makes consecutive transactions of the same amount on the same device within a short period, it is determined to be a duplicate transaction. Device malfunction refers to the device detecting a hardware abnormality. System revocation refers to the supermarket causing the transaction to be unconfirmed during the collaborative adjudication stage, and the system automatically initiates revocation. The TEE matches the identified user behavior with the behavior in the reverse rules. If the match is successful, it is determined to be a reverse transaction behavior; if the match is unsuccessful, the identification continues. Based on the reverse transaction behavior, the TEE locates the corresponding forward transaction in the fingerprint chain. The TEE checks whether the entity initiating the revocation operation has revocation authority. The TEE collects reverse transaction information, which includes the forward transaction fingerprint corresponding to the reverse transaction, the original transaction amount, the timestamp, and the device's unique identifier. A hash input string is constructed based on the reverse transaction information, with the expression: ,in, The input string is a hash string. The original fingerprint of the revoked positive transaction. The amount to be cancelled for the reverse transaction. The code for the reason for canceling a reverse transaction is as follows: 01 for customer cancellation, 02 for duplicate transaction, 03 for equipment failure, and 04 for automatic system cancellation. The timestamp for the generation of the reverse transaction. This is a one-time random number generator to ensure that multiple reversals of the same positive transaction generate different hash results, thus preventing replay attacks. To determine the unique identifier of the device performing the reversal operation, the reverse transaction fingerprint is calculated based on the obtained hash input string, using the following formula: ,in, This is the reverse transaction fingerprint for this reverse transaction. Given a hash input string, obtain the chain head of the current reverse fingerprint based on the reverse transaction fingerprint.

[0056] S202, based on the determined reverse transaction behavior, a collaborative decision is made among multiple short-range devices, and the reverse transaction information is transmitted to all other short-range devices. After receiving the reverse transaction information, the other short-range devices update their device fingerprint chains to form a unified fingerprint chain containing both forward and reverse fingerprint information.

[0057] Furthermore, based on the determined reverse transaction behavior, collaborative adjudication is performed among multiple short-range devices. The TEE of each short-range device transmits the reverse transaction information to all other short-range devices via a short-range communication channel. Upon receiving the reverse transaction information, the short-range receiving device verifies it. The TEE scans the current fingerprint chain sequentially to check for the existence of a positive transaction. If a positive transaction exists in the fingerprint chain, the device directly appends a reverse transaction entry to its local fingerprint chain. Other short-range devices, upon receiving the reverse transaction information, update their fingerprint chains, forming a new chain head. If the positive transaction does not exist in the fingerprint chain, other short-range devices send a synchronization request to the sending short-range device to synchronize their fingerprint chains. After the collaborative adjudication is completed, a unified fingerprint chain containing both positive and reverse fingerprint information is formed, expressed as: ,in, The new chain head after appending the i-th entry represents the latest state of the unified fingerprint chain. Add the current fingerprint chain state to the previous chain head after appending the (i-1)th entry. This refers to the transaction record when the i-th entry is a positive transaction. This is the reversal record when the i-th entry is a reverse transaction. This is a type marker indicating that the current entry is a forward transaction. This is a type marker indicating that the current entry is a reverse transaction. The unified fingerprint chain, which serves as a unique identifier for the device performing the additional operation, includes a forward chain (fingerprint chain) and a reverse fingerprint chain.

[0058] S203, when merging the unified fingerprint chain of multiple short-range devices, uses conflict rules to detect and eliminate reversal conflicts; at the same time, it performs pairwise cancellation through forward and reverse transactions to compress the fingerprint chain.

[0059] Specifically, when multiple short-range devices collaborate on adjudication, it is necessary to merge the unified fingerprint chains of the devices, collect the unified fingerprint chain data of all short-range devices, and group the forward and reverse transactions in the unified fingerprint chains of all short-range devices according to the forward transaction fingerprint to form a global set with the forward transaction fingerprint as the key. Conflict detection is performed on each forward transaction in the global set, and the conflict detection is executed in the following five priority order. After any layer makes a clear judgment, the subsequent detection is immediately terminated: Local validity judgment: if the usage time of the forward transaction on this device is earlier than the usage time of the reverse transaction, the reverse transaction is invalid; Paired offset judgment: if a valid reverse transaction exists, it is marked as offset; Fork elimination: when the number of devices containing reverse transactions exceeds 50% of the total, the effect is revoked, otherwise it is invalid; Re-revocation processing: retain the valid reverse transaction with the earliest timestamp, and ignore the rest; Last resort: time priority principle.The cancellation time is compared with the time the transaction was included in the pending zone; the earlier one takes effect, and the priority of the above rules decreases accordingly. The process involves checking for the existence of a corresponding reverse transaction, checking for forks, handling duplicate cancellations, and resolving conflicts that persist after these three steps. For checking for the existence of a corresponding reverse transaction (paired offset determination), if both a positive transaction fingerprint and a reverse transaction fingerprint pointing to it exist in the global set, the transaction is considered cancelled, funds are rolled back, and both the positive and reverse transaction fingerprints are marked as offset. If only a positive transaction fingerprint exists in the global set without a reverse transaction fingerprint, the transaction is considered valid and cleared according to normal transaction procedures. For checking for forks (majority rule), if some devices' fingerprint chains contain positive transaction fingerprints without cancellation, and other devices contain reverse transaction fingerprints pointing to positive transaction fingerprints, forming a fork, the number of devices containing reverse transaction fingerprints and the total number of devices containing positive transaction fingerprints are counted. If the number of devices containing reverse transaction fingerprints is greater than half the total number of devices containing positive transaction fingerprints, the cancellation is considered effective and marked. Forward and reverse transaction fingerprints have been offset. If the number of devices containing reverse transaction fingerprints is less than or equal to half the total number of devices containing forward transaction fingerprints, the revocation is invalid, and the forward transaction fingerprint is marked as a valid transaction. For handling duplicate revocations, if the same forward transaction fingerprint corresponds to multiple reverse transaction fingerprints, they are sorted by revocation timestamp. The reverse transaction with the earliest timestamp that meets the validity verification is retained, and the rest are ignored. It is checked whether the device that generated the reverse transaction has the right to revoke (only the original transaction device or authorized device can revoke). If the earliest valid reverse transaction comes from an unauthorized device, it is postponed to the next valid reverse transaction. For cases where there is still a conflict after the above three steps, i.e., the time priority principle, the revocation timestamp is compared with the first use time of the forward transaction on other devices (i.e., the time when the transaction is included in the pending area on other devices). If the revocation time is less than the first use time, the revocation is effective, and the forward and reverse transaction fingerprints are marked as offset. If the revocation time is greater than or equal to the first use time, the revocation is invalid, and the forward transaction fingerprint is marked as a valid transaction.

[0060] The tags marked as offset indicate the existence of a reverse transaction corresponding to the forward transaction. If the reverse transaction timestamp of the reverse transaction fingerprint is greater than the forward transaction timestamp, it is determined to be a pair of transactions that can be offset. The pair of transactions that can be offset is deleted from the unified fingerprint chain, thereby compressing the unified fingerprint chain.

[0061] The technical solutions described in the above embodiments of this application have at least the following technical effects or advantages: they solve the conflict problem caused by the irrevocability of transactions once confirmed and the inability of revocation information to be propagated across devices; they can complete the revocation conflict detection through linear scanning; and through short-distance broadcast synchronization and pairwise offset compression mechanisms, they achieve reliable propagation of revocation information among multiple devices, controllable long-term storage, and suppression of malicious revocation behavior, thereby achieving complete traceability of forward and reverse transactions and global consistency of revocation.

[0062] Example 3: Example 2 achieved secure synchronization of a single undo operation across multiple devices, resolving the conflict issue of undo information. However, in Example 2, the undo operation could only apply to the most recent transaction at the end of the fingerprint chain. This is because the balance calculation for each transaction in the fingerprint chain depends on the cumulative result of all its preceding transactions. Undoing a non-end transaction would disrupt the balance benchmark of subsequent transactions. When it is necessary to undo a non-end transaction, Example 2 cannot achieve this. By using counting and reverse rollback, the undo capability is extended from a single transaction at the end to reverse rollback in any order, such as... Figure 3 As shown.

[0063] S301, Construct a transaction dependency table and a rollback set based on the device's trusted execution environment. The transaction dependency table is used to store the dependencies between transactions.

[0064] Specifically, the trusted execution environment of the device constructs a transaction dependency table. The transaction dependency table uses the forward transaction fingerprint as the key and stores the fingerprint of the preceding transaction, the number of subsequent transactions that depend on it, the transaction amount, the timestamp, and the transaction status. During the operation of the device, the transaction dependency table inserts new records one by one as each new transaction is generated, and the count (dep_count) field of the subsequent transactions that depend on the preceding transaction is updated synchronously. The rollback set independently maintains a dynamic fingerprint list, which only contains the transaction fingerprints where dep_count = 0 at present. It is used to quickly locate transaction candidates that can be directly revoked. The transaction dependency table records the complete dependency graph, and the rollback set serves as an index structure that is updated in real time based on the status of the dependency table, providing query support for the reverse rollback algorithm.

[0065] S302, the trusted execution environment of the device determines the transaction fingerprint and the preceding dependency fingerprint of the new transaction, updates the dependency count and calculates the dependency depth based on the preceding dependency fingerprint, appends the transaction fingerprint of the new transaction to the unified fingerprint chain, updates the chain head of the unified fingerprint chain, and stores the dependency information in the transaction dependency table; the dependency information refers to the dependency count and dependency depth.

[0066] Specifically, the Trusted Execution Environment (TEE) reads the complete transaction sequence corresponding to the current head of the unified fingerprint chain. This sequence records all confirmed forward and reverse transactions in chronological order. Since the unified fingerprint chain contains both forward and reverse transactions, the TEE scans backward from the head of the chain to identify all unrevoked forward transactions. Specifically, the TEE starts from the end of the unified fingerprint chain (the latest transaction) and checks backward one by one. If the current entry's type is marked as... If it is determined to be a reverse transaction, it means that the forward transaction has been revoked and should be skipped; if the current entry's type is marked as 1. If a transaction is determined to be a forward transaction and there is no reverse transaction pointing to it, then this transaction is the last forward transaction that has not been revoked. The TEE extracts the fingerprint of this transaction and records it as the preceding dependency fingerprint. The TEE collects the amount, timestamp, device ID, and account identifier of this transaction, and calculates the fingerprint of this transaction according to the hash rule: ,in, For the transaction fingerprint of the new transaction, Before adding new transactions, the current head of the unified fingerprint chain is initially set as the starting point of the device fingerprint. The raw data for the new transaction. The type marker indicates that the current appended transaction is a positive transaction. It is a unique device identifier.

[0067] The TEE searches the transaction dependency table for the record whose key is the preceding dependency fingerprint. It increments the count field corresponding to the preceding dependency fingerprint, indicating that a new transaction depends on the preceding dependency fingerprint. Simultaneously, it adds the preceding dependency fingerprint to the new transaction's preceding transaction fingerprint list. The TEE then reads the dependency depth of all preceding transactions from the transaction fingerprint list, taking the maximum value as the dependency depth. The expression is: ,in, The dependency depth of a new transaction indicates its hierarchical position in the dependency chain and is used to determine the order of reversals during reverse rollback. Let be a function representing the dependency depth value of a given preceding transaction fingerprint. This value is assigned to each transaction during its generation and stored in the transaction dependency table. The variable is used to iterate through the list of preceding transaction fingerprints for the new transaction. The new transaction's preceding dependency fingerprint list is the set of fingerprints of all historical transactions that the new transaction directly depends on. The TEE writes the fingerprint of the new transaction and the fingerprint type label into the unified fingerprint chain, overwrites the old value, obtains the new chain head, and the dependency information is constituted by the count and dependency depth of subsequent transactions. The dependency information of the new transaction is stored in the transaction dependency table.

[0068] S303, when a user requests to cancel a target forward transaction, the device's trusted execution environment extracts the count of subsequent transactions depending on the transaction from the transaction dependency table, and determines whether the transaction can be directly canceled based on the count of subsequent transactions depending on the transaction; if the determination result is that the transaction cannot be directly canceled, a reverse rollback is performed. The reverse rollback is to construct a rollback list, sort the rollback list according to the dependency depth, and rollback is performed according to the order in the rollback list until the forward transaction requested by the user is canceled.

[0069] Furthermore, when a user requests to rescind a forward transaction, they specify the identifier of the forward transaction to be rescinded, i.e., the target transaction fingerprint. The TEE locates the record with the target transaction fingerprint as the key in the transaction dependency table and reads the count field of subsequent transactions. The count of subsequent transactions indicates how many subsequent transactions directly or indirectly depend on the target transaction fingerprint. Based on the count of subsequent transactions depending on the transaction, it is determined whether it can be directly rescinded. Specifically: when the count of subsequent transactions depending on the transaction is equal to zero, it means that no subsequent transactions depend on the target transaction fingerprint, and direct rescission can be performed; when the count of subsequent transactions depending on the transaction is greater than zero, it means that there are subsequent transactions depending on the target transaction fingerprint. The target transaction fingerprint is highly dependent and cannot be directly revoked. A reverse rollback is performed, with the following steps: The trusted execution environment constructs an empty queue and an empty list, adding the target transaction fingerprint as the starting node. The trusted execution environment constructs a reverse dependency table, using the transaction fingerprint as the key, to store a list of all subsequent transactions that depend on the transaction. For example, if the preceding dependency list of transaction A's fingerprint contains the fingerprint of transaction B, then the record corresponding to transaction B's fingerprint in the reverse dependency table contains the fingerprint of transaction A. For each current transaction fingerprint in the queue, the reverse dependency table is searched for a list of all subsequent transactions that depend on the current transaction fingerprint. Add all subsequent transactions to the queue and list, repeating the above process until the queue is empty. This means the reverse dependency table stores the dependencies between transactions in reverse: if a transaction depends on another transaction (the latter is in the former's preceding dependency list), then in the reverse dependency table, the dependent transaction points to that subsequent transaction. When a reversal request is initiated, first add the target transaction to the queue, then repeatedly execute the operation of retrieving a transaction from the queue, searching for all its dependent subsequent transactions in the reverse dependency table, adding these transactions to the queue, and recording them in the result list. Since each transaction is only processed once (processed transactions are not added again), this process is repeated. Furthermore, the transaction dependencies form a directed acyclic graph (without circular dependencies). Each round consumes one element in the queue and may add several new descendant transactions. When processing a transaction, if no transaction in the reverse dependency table depends on it, no new element will be added to the queue. This process repeats until all reachable descendant transactions are processed, and the queue eventually becomes empty, thus completing the collection of all relevant descendant transactions. At this point, the list contains the target transaction fingerprint and all its direct or indirect descendant transactions, that is, all transactions that directly or indirectly depend on the target transaction fingerprint.

[0070] For each transaction in the list, read its dependency depth field in the transaction dependency table, sort them by dependency depth value from largest to smallest, and obtain the reverse rollback list. Transactions with larger dependency depths are deeper in the dependency chain and should be rolled back first. Dependency depth is assigned when a transaction is generated, and the dependency depth of a new transaction is equal to the maximum dependency depth of all its predecessor transactions plus 1. Therefore, the dependency depth value reflects the layer depth and order of occurrence of transactions. The larger the dependency depth, the closer the transaction is to the end of the dependency chain. For each transaction fingerprint in the reverse rollback list, generate a corresponding reverse transaction according to the reverse transaction generation rules, append the reverse transaction to the unified fingerprint chain, and append the reverse transaction fingerprint as an entry marked with type 0x02 to the unified fingerprint chain. Update the chain head, update the status field of the current transaction fingerprint in the transaction dependency table to "rollbacked", and traverse the predecessor dependency list of the current transaction fingerprint: for each predecessor transaction... The fingerprint is used to decrement the number of subsequent transactions. If the number of subsequent transactions for a preceding transaction fingerprint becomes 0, it is added to the global rollback set. For each transaction that is rolled back, the trusted execution environment recalculates the current account balance and updates the local balance snapshot. When all descendant transactions have been rolled back, the number of subsequent transactions for the target transaction fingerprint will inevitably become 0. At this point, the execution generates a reverse transaction for the target transaction fingerprint, calculates the reverse transaction fingerprint, appends the reverse transaction fingerprint as an entry with type 0x02 to the unified fingerprint chain, updates the chain head, updates the status of the target transaction fingerprint to rolled back, traverses the preceding dependency list of the target transaction fingerprint, decrements the number of subsequent transactions for each preceding transaction by 1, and if the number of subsequent transactions for a preceding transaction becomes 0, it is added to the rollback set, i.e., the target transaction itself is rolled back. The current account balance is recalculated, the local balance snapshot is updated, and the trusted execution environment returns a rollback completion signal to the application layer.

[0071] The unified fingerprint chain employs a storage model that only adds and never subtracts. During the rollback process, reverse transaction fingerprints generated are appended to the end of the chain as new entries marked with type 0x02, while the original forward transaction entries remain unchanged. The status field in the transaction dependency table is used to mark "valid" or "revoked." Revoked transactions are automatically skipped during balance calculation. The compression mechanism (S203) only optimizes the index data structure and does not delete any physical entries in the fingerprint chain. The fingerprint chain always maintains a complete and traceable audit log.

[0072] S304 calculates the arbitrage risk coefficient based on the total amount of cancelled transactions and the amount of completed transactions, identifies the risk level based on the arbitrage risk coefficient, and controls different levels accordingly.

[0073] Specifically, the formula for calculating the arbitrage risk coefficient based on the total amount of cancelled transactions and the amount of completed transactions is as follows: ,in, This is an arbitrage risk coefficient used to quantify the degree of abnormal account cancellations. To calculate the total amount of positive transactions that have been cancelled within the statistics window. This refers to the total amount of positive transactions that have been completed (confirmed and not revoked) within the same statistical window. To avoid extremely small positive numbers introduced by division by zero error, This represents the cancellation frequency over the past 30 days, calculating the percentage of cancellations made by the account in the past 30 days relative to the total number of transactions. This is the baseline value for cancellation frequency, representing the average cancellation frequency of normal users. This value is derived from industry statistical experience in offline retail scenarios. The standard deviation of the cancellation frequency is used as a benchmark value to measure the dispersion of the cancellation frequency. This is a penalty coefficient for frequency anomalies, used to amplify the impact of frequency deviations from the normal range on the risk factor; if If the numerator is 0, then the numerator is 0. =0; <1, then =1 indicates that risk is determined solely by the amount ratio. The specific method for identifying risk levels based on the calculated arbitrage risk coefficient is as follows: A first threshold, a second threshold, and a third threshold are set, with the first threshold being less than the second threshold and less than the third threshold. When the arbitrage risk coefficient is greater than or equal to zero and less than the first threshold, it is classified as a low-risk level, and offline transactions are processed normally. If the arbitrage risk coefficient is greater than or equal to the first threshold and less than the second threshold, it is classified as a medium-risk level, and new transactions require joint endorsement from at least three devices to be executed. During the offline negotiation phase, confirmation signatures from at least three devices are required to complete the transaction confirmation. If sufficient endorsements cannot be collected within the negotiation window... Book transactions are automatically rejected. This control measure will continue until the next online clearing. If the AR (Average Reduction) drops below 0.3, it will be automatically lifted. When the arbitrage risk coefficient is greater than or equal to the second threshold and less than the third threshold, it is judged as a high-risk level, and the offline refund function of the account is locked. Refund requests can only be processed manually through the online server. When the device TEE receives a cancellation request, it checks the risk level. If it is LEVEL_HIGH, it will refuse to generate a reverse transaction and inform the user that the account's refund function has been restricted. Please contact customer service after connecting to the internet. Forward transactions (consumption) are not affected, but refund operations must be performed online. This measure will continue until the next online clearing. If the AR (Average Reduction) drops below 0.3, it will be automatically lifted. If the risk level drops below 0.6, the risk level will automatically be downgraded to medium risk control. If the arbitrage risk coefficient is greater than or equal to the third threshold, it will be classified as the highest risk level, freezing the account's offline trading capabilities. All offline trading requests must be approved online before they can take effect. When the device's TEE receives a new trading request, it will check the risk level. If it is LEVEL_CRITICAL, it will refuse to generate a new trading fingerprint and directly notify the user that the account's offline trading has been frozen. The user should contact customer service after connecting to the internet. During the freeze period, the device can still connect to the internet for clearing and reading historical trading records, but it cannot generate new transactions. This measure must be manually reviewed and confirmed by the server before it can be lifted and cannot be automatically downgraded.

[0074] The technical solutions described in the above embodiments of this application have at least the following technical effects or advantages: by using dependency counting and dependency depth, the complex graph structure is simplified into a linearly processable counting mechanism, reducing the computation and storage overhead of TEE, collecting all descendant transactions of the transaction to be revoked, and revoking them in descending order of dependency depth (revoking the most recent dependent transaction first, and revoking the target transaction last), ensuring the consistency of the balance after rollback, eliminating fund conflicts, quantifying user revocation behavior, dynamically adjusting offline permissions through three-level risk control, and effectively suppressing malicious arbitrage.

[0075] To make the technical solution of the present invention clearer, the above specific embodiments may involve several specific numerical values, thresholds, parameters, formulas, and examples. Those skilled in the art should understand that these specific contents are merely exemplary descriptions given for ease of implementation and are not essential technical features necessary for realizing the present invention, nor do they constitute a limitation on the scope of protection of the present invention. The mathematical formulas, parameter values, model structures, calculation rules, constraints, and data acquisition methods described in the specific embodiments section of this application are preferred examples for realizing the technical concept of the present invention, not the only implementation methods. Based on the core logic and inventive concept disclosed in this application, those skilled in the art can make reasonable equivalent substitutions, parameter adjustments, or logical optimizations to the parameters, formulas, and algorithm models according to actual conditions, industry standards, or conventional experimental methods, without producing substantial differences. Any changes that do not depart from the inventive concept of this application fall within the scope of this application. All mathematical expressions in this application should ensure that their physical meaning is clear when applied; parameters such as weights and thresholds can be calibrated using statistical or machine learning methods known in the art.

[0076] The above description is merely a preferred embodiment of the present invention and is not intended to limit the invention. For those skilled in the art, the present invention can have various modifications and variations. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of the present invention should be included within the scope of protection of the present invention.

Claims

1. A method for offline account fund processing involving multiple devices, characterized in that, include: S101, the server assigns a device fingerprint starting point to each device, obtains the current account balance information of the device, and stores the current account balance information in the trusted execution environment as a verification benchmark; the device fingerprint starting point is a true random number with a length of 256 bits, generated by the server's random number generator; S102, Identify the user's offline transaction behavior. When it is a positive transaction behavior, collect the transaction information of the user's offline transaction account, generate a positive transaction fingerprint based on the transaction information, and store the positive transaction fingerprint in the local pending area, marking the transaction status of the pending area as unconfirmed; the transaction behavior includes positive transaction behavior and negative transaction behavior; The positive transaction behavior refers to the behavior where a user initiates a payment while offline, and the device confirms the user's identity and obtains the account identifier through facial recognition, then generates a positive transaction fingerprint by hashing a binary string composed of the current transaction amount, timestamp, device ID, and the fingerprint of the previous transaction. The negative transaction behavior refers to the behavior where, based on the set rules for user cancellation, duplicate transactions, device failure, and system reversal, the trusted execution environment matches the identified user behavior with the behavior in the negative rules, and the user behavior that matches successfully. S103, identify the distance between multiple devices, use a threshold to filter short-distance devices based on the identified distance between multiple devices, each short-distance device sends unconfirmed transaction information in its local pending area, when other short-distance devices receive transaction information from the other short-distance device, use the adjudication rules to make a collaborative adjudication, obtain a global transaction order list, and update the transaction status in the pending area based on the global transaction order list; S104, deduct funds and update the positive transaction fingerprint according to the transaction status marked as confirmed in the global transaction sequence list, and store the updated positive transaction fingerprint in the fingerprint chain area; for the transaction status marked as rejected in the global transaction sequence list, the device displays a prompt message to the user and removes the transaction status marked as rejected from the pending area; S105, after collaborative adjudication, each short-range device sends the latest fingerprint chain head, and the receiving short-range device stores the anchoring information in its own verification area; until the detection device is connected to the network, it uploads the current latest fingerprint chain head, chain length, transaction status marked as confirmed in the global transaction order list, updated transaction fingerprint, and information in the verification area to the server.

2. The method for offline account fund processing with multi-device collaboration according to claim 1, characterized in that, The method for obtaining the current account balance information of a device is as follows: When a device connects to the network, the server verifies the legality of the device, registers its identifier and public key, and generates a random number for each device as the starting point of the device fingerprint. The fingerprint is encrypted with the device's public key and signed by the server before being sent out. The trusted execution environment of the device decrypts and verifies the signature with its private key, stores the fingerprint starting point in the fingerprint chain starting point slot, initializes the chain head pointer and sets the chain length to zero, and the server adds a timestamp and account identifier to the balance to generate a balance certificate. The balance and certificate are then stored in the balance benchmark slot of the trusted execution environment to complete the establishment of the offline verification benchmark.

3. The method for offline account fund processing with multi-device collaboration according to claim 2, characterized in that, The steps for generating a positive transaction fingerprint based on transaction information are as follows: The obtained amount, timestamp, device identifier, and account identifier are combined to form transaction information; the transaction information is then concatenated into a binary string according to a predetermined format, expressed as: ,in, It is a binary string. This is the positive transaction fingerprint of the previous transaction. When i=1, This refers to the starting point of the device fingerprint assigned by the server. This is the consumption amount for this transaction. The timestamp when the transaction occurred. A unique device identifier for the consumer machine that executes the transaction. To de-identify the user account, the trusted execution environment calls the SHA-256 hash function to obtain the positive transaction fingerprint, the expression of which is: ,in, This serves as the positive transaction fingerprint for this transaction. For hash functions, It is a binary string.

4. The method for offline account fund processing with multi-device collaboration according to claim 1, characterized in that, The steps for using threshold filtering to screen short-range devices are as follows: When a device is offline and there are unconfirmed transactions in the waiting area, the device periodically sends its own device information, scans other device information in the vicinity, and records the device identifier and received signal strength indication. The physical distance to each discovered device is calculated based on the received signal strength indication, and a distance threshold is set. When the physical distance is less than or equal to the distance threshold, it is determined to be a short-range device.

5. The method for offline account fund processing with multi-device collaboration according to claim 4, characterized in that, The method to obtain the global transaction order list is as follows: the selected short-distance devices are selected to elect a coordinating device according to the device identifier hash value. Each device reads unconfirmed transactions from the pending area to generate a transaction summary, which is then exchanged via short-distance communication broadcast and merged to form a transaction summary set. After sorting the transactions in ascending order by timestamp and device identifier hash, simulated deductions are made one by one starting from the account balance. Transactions that result in a negative balance are marked as conflicting and removed. Finally, the remaining non-conflicting transactions form a global transaction order list.

6. The method for offline account fund processing with multi-device collaboration according to claim 1, characterized in that, Offline account fund processing methods also include: S201, if the user's behavior is found to meet the reverse rule, the transaction behavior is determined to be a reverse transaction behavior, and the fingerprint of the reverse transaction behavior is obtained; S202, based on the determined reverse transaction behavior, a collaborative decision is made among multiple short-range devices, and the reverse transaction information is transmitted to all other short-range devices. After receiving the reverse transaction information, the other short-range devices update their device fingerprint chains to form a unified fingerprint chain containing both forward and reverse fingerprint information. S203, when merging the unified fingerprint chain of multiple short-range devices, uses conflict rules to detect and eliminate reversal conflicts; at the same time, it performs pairwise cancellation through forward and reverse transactions to compress the fingerprint chain.

7. The method for offline account fund processing with multi-device collaboration according to claim 6, characterized in that, The reverse rules are as follows: user cancellation, duplicate transaction, device failure, and system revocation. User cancellation is when the user actively cancels the transaction and the customer service confirms it on the device. When the system detects that the same user makes consecutive transactions of the same amount on the same device within a short period of time, it is determined to be a duplicate transaction. Device failure is when the device detects a hardware malfunction. System revocation is when the collaborative adjudication stage times out, causing the transaction to be unable to be confirmed, and the system automatically initiates revocation.

8. The method for offline account fund processing with multi-device collaboration according to claim 7, characterized in that, The expression for the unified fingerprint chain is: ,in, The new chain head after appending the i-th entry represents the latest state of the unified fingerprint chain. Add the current fingerprint chain state to the previous chain head after appending the (i-1)th entry. This refers to the transaction record when the i-th entry is a positive transaction. This is the reversal record when the i-th entry is a reverse transaction. This is a type marker indicating that the current entry is a forward transaction. This is a type marker indicating that the current entry is a reverse transaction. A unique identifier for the device performing the append operation.

9. A method for offline account fund processing with multi-device collaboration according to claim 6, characterized in that, The offline account fund processing method also includes: S301, Construct a transaction dependency table and a rollback set based on the device's trusted execution environment. The transaction dependency table is used to store the dependencies between transactions. S302, the trusted execution environment of the device determines the transaction fingerprint and the preceding dependency fingerprint of the new transaction, updates the dependency count and calculates the dependency depth based on the preceding dependency fingerprint, appends the transaction fingerprint of the new transaction to the unified fingerprint chain, updates the chain head of the unified fingerprint chain, and stores the dependency information in the transaction dependency table; the dependency information refers to the dependency count and dependency depth. S303, when a user requests to cancel a target forward transaction, the device's trusted execution environment extracts the count of subsequent transactions depending on the transaction from the transaction dependency table, and determines whether it can be directly canceled based on the count of subsequent transactions depending on the transaction; if the determination result is that it cannot be directly canceled, a reverse rollback is performed. The reverse rollback involves constructing a rollback list, sorting the rollback list according to the dependency depth, and rolling back according to the order in the rollback list until the user's requested forward transaction is canceled; if the determination result is that it can be directly canceled, then the cancellation is performed. S304 calculates the arbitrage risk coefficient based on the total amount of cancelled transactions and the amount of completed transactions, identifies the risk level based on the arbitrage risk coefficient, and controls different levels accordingly.

10. A method for offline account fund processing with multi-device collaboration according to claim 9, characterized in that, The formula for calculating the arbitrage risk coefficient based on the total amount of cancelled transactions and the amount of completed transactions is as follows: ,in, For arbitrage risk coefficient, To calculate the total amount of positive transactions that have been cancelled within the statistics window. This represents the total amount of positive transactions completed within the same statistical window. To avoid extremely small positive numbers introduced by division by zero error, This represents the cancellation frequency over the past 30 days, calculating the percentage of cancellations made by the account in the past 30 days relative to the total number of transactions. To revoke the frequency reference value, To remove the baseline value for the frequency standard deviation, This is the penalty coefficient for frequency anomalies.

Images