A multi-level hardware wallet transaction method, medium and system for digital currency

Abstract

The present invention provides a multi-level hardware wallet transaction method, medium and system for digital currency, which belongs to the technical field of digital currency transaction methods, including: first, based on the central bank key and the operating institution key, a business group mother wallet key is derived for the hardware wallet group to manage the creation, revocation and validity period of the child key. Then, the child wallet key is derived from the mother wallet key and written into the hardware wallet medium as a digital currency transaction terminal. In addition, a child hardware wallet program is written into the hardware wallet medium, including the functions of collecting and fund collection. During the transaction process, the child wallet program first verifies the payee certificate and transaction assets, completes the collection, and destroys the collection assets and creates an equal amount of new currency string, which is encrypted and locked by the mother wallet key public key. Finally, a simulated annealing algorithm is used to optimize the fund collection scheme, execute the collection process, and solve the problem of low efficiency of the traditional one-to-one collection method when the number of sub-wallets is large.

Description

Technical Field

[0001] The present invention belongs to the technical field of digital currency transaction methods, and in particular, relates to a multi-level hardware wallet transaction method, medium and system for digital currency. Background Art

[0002] In the context of the rapid development of digital currency and blockchain technology, digital asset wallets have become an important tool for users to manage cryptocurrencies. Especially in enterprise-level application scenarios, large institutions usually need to manage a large number of sub-wallets, which are used for daily operations, transactions and fund management. The digital asset management system widely used in the current market mainly adopts a hierarchical wallet structure, that is, a parent wallet is set up to uniformly manage multiple sub-wallets. In the actual fund collection process of this architecture, the existing technology often adopts a simple linear collection method, that is, the sub-wallet directly transfers money to the parent wallet. This method will cause congestion in the blockchain network when there are a large number of sub-wallets, and generate a large amount of unnecessary transaction fees. For example, a large exchange manages more than 100,000 sub-wallets on a daily basis. If the traditional one-to-one collection method is adopted, it will not only be inefficient, but also significantly increase operating costs. Summary of the invention

[0003] In view of this, the present invention provides a multi-level hardware wallet transaction method, medium and system for digital currency, which can solve the problem of low efficiency of the traditional one-to-one collection method when the number of sub-wallets is large.

[0004] The present invention is achieved in that:

[0005] A first aspect of the present invention provides a multi-level hardware wallet transaction method for digital currency, comprising the following steps:

[0006] S10. Based on the central bank root key and the banking industry key of the operating institution, a business group mother wallet key is derived for the hardware wallet group. The business group mother wallet key is used to create, revoke and manage the validity period of the subkey;

[0007] S20, deriving a sub-wallet key through the business group master wallet key, writing the sub-wallet key into a hardware wallet medium, the hardware wallet medium serving as a digital currency transaction acceptance terminal, and the sub-wallet key being derived through a key derivation function;

[0008] S30, writing a sub-hardware wallet program into the hardware wallet medium, wherein the sub-hardware wallet program includes a payment collection program and a fund collection program to the parent wallet;

[0009] S40, receiving the transaction assets sent by the payment wallet through the sub-hardware wallet program, verifying the payment wallet certificate issuing root certificate, verifying the issuance of the original coin string digest and the transaction assets, and completing the payment transaction;

[0010] S50, destroying the transaction assets and creating a coin string of equal value, and encrypting and locking the coin string of equal value by using the public key of the business group mother wallet key;

[0011] S60. Calculate the optimal solution for fund collection through simulated annealing algorithm, determine the sub-wallets and coin strings that need to be collected, and execute the fund collection process, which includes sending an initial collection instruction, verifying a collection response, sending a collection confirmation instruction, locking the coin string, constructing transaction assets, and resetting the collection record.

[0012] On the basis of the above technical solution, the multi-level hardware wallet transaction method of digital currency of the present invention can also be improved as follows:

[0013] The generation of the business group parent wallet key specifically includes:

[0014] Step 101: Obtain the root key issued by the central bank;

[0015] Step 102: Generate an operating institution banking industry key using the root key;

[0016] Step 103: Generate a business group parent wallet key based on the root key and the banking industry key of the operating institution;

[0017] Step 104: storing the business group parent wallet key in the rail transit core transaction system;

[0018] Step 105: Establish a binding relationship between the business group parent wallet key and the rail transit core transaction system.

[0019] Furthermore, completing the key derivation through the key derivation function specifically includes:

[0020] Step 201, setting the output length of the key derivation function;

[0021] Step 202: Set a different encryption salt value for each sub-wallet;

[0022] Step 203, setting the number of iterative operations;

[0023] Step 204: Set the final key length;

[0024] Step 205: Generate a sub-wallet key through the key derivation function;

[0025] Step 206: Establish a one-to-one correspondence between the sub-wallet key and the hardware wallet medium.

[0026] Furthermore, the specific steps of the payment transaction include:

[0027] Step 401: The payment wallet selects a transaction coin string and locks the transaction coin string;

[0028] Step 402: When the transaction coin string amount is greater than the transaction amount, create transaction assets and balance assets;

[0029] Step 403: Use the payment wallet private key to sign the transaction assets;

[0030] Step 404: Use the public key of the receiving sub-wallet to encrypt the signed transaction assets;

[0031] Step 405: Send the encrypted transaction assets to the sub-wallet.

[0032] Furthermore, the specific steps of the simulated annealing algorithm include:

[0033] Step 501, setting the initial temperature and cooling rate;

[0034] Step 502: Randomly select a coin string combination in the sub-wallet as an initial solution;

[0035] Step 503: Establish the difference between the target sum and the actual sum as the fitness function;

[0036] Step 504: define a neighborhood structure to generate candidate solutions;

[0037] Step 505: Calculate the acceptance probability of the new solution according to the fitness function;

[0038] Step 506: Iteratively calculate the optimal solution using the temperature reduction strategy.

[0039] Furthermore, the fund collection process specifically includes:

[0040] Step 601: The parent wallet constructs an initial collection instruction and signs it with a private key;

[0041] Step 602: The sub-wallet verifies the initial collection instruction and obtains the current balance and coin string hash;

[0042] Step 603: The sub-wallet signs with the private key and sends the balance information;

[0043] Step 604: The parent wallet verifies the signature of the child wallet and the validity period of the certificate;

[0044] Step 605: The parent wallet sends a collection confirmation instruction;

[0045] Step 606: The sub-wallet locks the coin string and constructs the transaction assets;

[0046] Step 607: The parent wallet verifies the asset information;

[0047] Step 608: If the asset information is incorrect, an error code is sent to the sub-wallet; after receiving the error code, the sub-wallet releases the assets and unlocks the coin string; resets the collection record; if the asset information is correct, the coin string is recorded in the parent wallet; and the sub-wallet is notified that the transaction is completed.

[0048] Furthermore, the hardware wallet program also includes:

[0049] Step 311: Setting a secure storage module to record the transaction process;

[0050] Step 312: Record the response status of the collection instruction in the secure storage module;

[0051] Step 313, recording the coin string locking status in the secure storage module;

[0052] Step 314: Record the transaction asset construction status in the secure storage module;

[0053] Step 315: Record the transaction completion status in the secure storage module;

[0054] Step 316: Control the transaction process according to the record status in the secure storage module.

[0055] Furthermore, the fund collection process also includes an optimized collection path and a secure communication mechanism, specifically:

[0056] An improved hierarchical deterministic path scheme is used to optimize the collection path, including: constructing a tree structure of sub-wallets according to the hierarchical relationship; calculating the optimal collection order of each level based on the greedy algorithm; and determining the cross-level collection path through dynamic programming;

[0057] A deterministic key derivation mechanism is used to protect the collection process, including: assigning a unique deterministic key to each wallet; generating a session key based on a key derivation function; and using symmetric encryption to protect collection instructions and response data.

[0058] A second aspect of the present invention provides a computer-readable storage medium, wherein the computer-readable storage medium stores program instructions, and when the program instructions are run in a computer, they are used to execute the above-mentioned multi-level hardware wallet transaction method for digital currency.

[0059] A third aspect of the present invention provides a multi-level hardware wallet transaction system for digital currency, which includes the above-mentioned computer-readable storage medium.

[0060] Compared with the prior art, the multi-level hardware wallet transaction method, medium and system for digital currency provided by the present invention have the following beneficial effects:

[0061] Firstly, by introducing a simulated annealing algorithm and a hierarchical deterministic path optimization scheme, the present invention significantly improves the efficiency of fund collection.

[0062] Secondly, the present invention adopts an improved HyperLogLog algorithm to evaluate the interaction strength between wallets, and combines it with a dynamic session key generation mechanism to build a multi-level security protection system.

[0063] Third, the wallet identifier system and interaction relationship diagram designed by the present invention realize efficient management and expansion of the wallet system.

[0064] In summary, the present invention solves the problem of low efficiency of the traditional one-to-one aggregation method when the number of sub-wallets is large. BRIEF DESCRIPTION OF THE DRAWINGS

[0065] Figure 1 A flow chart of the method provided by the present invention;

[0066] Figure 2 This is a diagram of the hardware wallet architecture in Example 1;

[0067] Figure 3 This is the transaction flow chart in Example 1. DETAILED DESCRIPTION

[0068] In order to make the purpose, technical solution and advantages of the embodiments of the present invention more clear, the technical solution in the embodiments of the present invention will be clearly and completely described below in conjunction with the accompanying drawings in the embodiments of the present invention.

[0069] like Figure 1 As shown, it is a flow chart of a multi-level hardware wallet transaction method for digital currency provided by the first aspect of the present invention, and the method comprises the following steps:

[0070] S10. Based on the central bank's root key and the banking industry key of the operating institution, the business group mother wallet key is derived for the hardware wallet group. The business group mother wallet key is used to create, revoke and manage the validity period of the subkey;

[0071] S20. Derive the sub-wallet key through the business group master wallet key, write the sub-wallet key into the hardware wallet medium, the hardware wallet medium serves as a digital currency transaction acceptance terminal, and the sub-wallet key is derived through a key derivation function;

[0072] S30, writing a sub-hardware wallet program into the hardware wallet medium, wherein the sub-hardware wallet program includes a payment collection program and a fund collection program to the parent wallet;

[0073] S40, receiving the transaction assets sent by the payment wallet through the sub-hardware wallet program, verifying the payment wallet certificate issuing root certificate, verifying the issuance of the original coin string summary and transaction assets, and completing the payment transaction;

[0074] S50, destroying the transaction assets and creating a coin string of equal value, and encrypting and locking the coin string of equal value through the public key of the business group's parent wallet key;

[0075] S60. Calculate the optimal solution for fund collection through simulated annealing algorithm, determine the sub-wallets and coin strings that need to be collected, and execute the fund collection process. The fund collection process includes sending the initial collection instruction, verifying the collection response, sending the collection confirmation instruction, locking the coin string, constructing the transaction asset and resetting the collection record.

[0076] The specific implementation methods of the above steps are described in detail below:

[0077] The specific implementation of step S10 is to build a multi-level hardware wallet root key system based on cryptographic principles. First, obtain the root key from the central bank. The root key is generated using the national secret algorithm SM4, and the key length is 256 bits. Based on the root key, a hierarchical deterministic key derivation protocol is used to generate the banking industry key of the operating institution. In the hierarchical deterministic key derivation process, a banking identifier is selected As the input parameter of the derivation function, the key derivation is completed through the HMAC key hash message authentication code algorithm. After obtaining the root key and industry key, select the rail transit business group identifier , using a dual key derivation scheme to generate the business group master wallet key . The dual key derivation scheme first uses the root key to perform HMAC operation on the business group identifier to obtain the intermediate key, and then uses the industry key to perform HMAC operation on the intermediate key to obtain the final mother wallet key. The generated mother wallet key uses the national secret algorithm SM2 to generate a public-private key pair. The private key is used to sign the management operation of the sub-key, and the public key is used by the sub-wallet to verify the identity of the mother wallet. Finally, the mother wallet key is stored in the security hardware module of the rail transit core transaction system, and a binding relationship between the key and the system is established. Through this multi-level key derivation mechanism, the hierarchy and security of the key system are guaranteed, and the centralized management and control of the sub-wallet is realized. Among them, the national secret algorithm is the domestic cryptographic algorithm recognized by the State Cryptography Administration, mainly SM1, SM2, SM3, and SM4.

[0078] The specific implementation of step S20 is to generate an independent key pair for each sub-wallet through the parent wallet. First, based on the principle of elliptic curve cryptography, the basic parameters of the key derivation function are set. The elliptic curve parameters recommended by the national secret algorithm SM2 are selected, and the curve equation is , where the base point The order is To ensure the uniqueness of each sub-wallet key, a unique device serial number is assigned to each sub-wallet. As the derivation seed. During the key derivation process, the device serial number is first combined with a randomly generated salt value. The PBKDF2 key derivation function is used for concatenation. The number of iterations is set to 10,000 to ensure the security of the key. The derived key is obtained through this function. , as a random number to generate the public and private key pair of the sub-wallet. Based on the random number, the private key of the sub-wallet is generated using the elliptic curve cryptography algorithm and the public key . The public and private key pairs are written into the corresponding hardware wallet medium, which uses a smart card chip with secure storage to support the secure storage and use of keys. During the key writing process, a channel encryption mechanism is used to ensure the security of key transmission. Finally, a binding relationship between the sub-wallet key and the hardware medium is established and recorded in the rail transit core system for subsequent identity authentication and transaction processing.

[0079] The specific implementation method of step S30 is to write a transaction program with limited functions to the hardware wallet medium. The program adopts a layered design concept, with the bottom layer being a basic cryptographic library, including SM2 signature verification, SM3 hash calculation, SM4 encryption and decryption and other basic cryptographic algorithms. The middle layer is a secure storage module, which is used to record transaction status and manage key usage. The top layer is a business function module, which only includes two basic functions: collection and fund collection. The collection function module realizes the reception and verification of digital currency, including functions such as certificate verification, transaction asset verification, and coin string creation. The fund collection function module realizes the transfer of funds between the parent wallet, including functions such as instruction verification, asset locking, and transaction construction. The operating environment of the program is controlled by the secure operating system of the hardware wallet chip, and all key operations need to be recorded and controlled by the secure storage module. Through this restricted program design, the illegal use of the sub-wallet or the theft of funds can be effectively prevented.

[0080] The specific implementation method of step S40 is to complete a secure payment transaction through a sub-hardware wallet. When the payment wallet initiates a transaction, it first selects a coin string that meets the transaction amount from the payment wallet. If the coin string amount is greater than the transaction amount, it needs to be split. Two assets are created during the splitting process, one is a transaction asset equal to the transaction amount, and the other is a balance asset of the remaining amount. The transaction asset is signed using the SM2 algorithm, and the signature value is generated using the private key of the payment wallet to ensure the authenticity of the asset source. The signed transaction asset is then encrypted using the SM4 algorithm using the public key of the receiving sub-wallet to ensure the confidentiality of the transaction data. After the encrypted transaction asset is sent to the sub-wallet, the sub-wallet first verifies the payment wallet certificate chain, traces back to the central bank root certificate, and ensures the legitimacy of the payer's identity. Then the legitimacy of the original coin string is verified through the digital currency verification system of the People's Bank of China, including the serial number, denomination, issuance time and other information of the coin string. Finally, the validity of the transaction asset is verified, including the asset amount, signature correctness, etc. After all verifications are passed, the transaction is completed. Throughout the process, the security and legitimacy of the transaction are ensured through a multiple verification mechanism.

[0081] The specific implementation method of step S50 is to securely process the received assets and generate new coin strings. First, the verified transaction assets are destroyed through a secure deletion algorithm to ensure that the assets will not be illegally restored and reused. The destruction process uses the standard data clearing method of the US Department of Defense to overwrite the storage medium with random data multiple times. Then, based on the received transaction amount, a new coin string of equal amount is created. The process of creating a new coin string includes generating a unique coin string identifier, setting the coin string amount, recording the creation time and other information. The coin string is encrypted and protected using the national secret SM4 algorithm and the parent wallet public key to ensure that only the parent wallet can decrypt and use these coin strings. The encrypted coin string is stored in the secure storage area of ​​the sub-wallet, waiting for subsequent collection operations. Through this mechanism, both the safe storage of funds is ensured and preparations for subsequent collection operations are made.

[0082] The specific implementation of step S60 is to optimize the fund collection process through simulated annealing algorithm. First, the initial parameters of the algorithm are set, including the initial temperature Set to 100, the cooling coefficient Set to 0.95, the end temperature Set to 0.01. Iterate and calculate the optimal fund collection scheme at each temperature. The goal is to minimize the number of sub-wallets involved in the collection while meeting the transaction amount requirements. During the optimization process, the amount of coin strings in each sub-wallet is used as a decision variable to construct the objective function , represents the difference between the sum of the selected coin string amounts and the target amount. In each iteration, some sub-wallets are randomly selected or replaced to participate in the scheme, and the objective function value of the new scheme is calculated. If the new scheme is better, it is directly accepted; if the new scheme is worse, it is replaced according to probability. Accept the new plan. After determining the optimal plan, start the fund collection process. The parent wallet first constructs the initial collection instruction, which contains the collection amount, timestamp and other information, and signs it with a private key. After receiving the instruction, the sub-wallet verifies the signature of the parent wallet and returns the current balance information. After the parent wallet verifies the sub-wallet information, it sends a collection confirmation instruction. The sub-wallet locks the corresponding coin string, constructs the transaction assets and sends them to the parent wallet. During the whole process, the status of each link is recorded through the secure storage module to ensure the security and reliability of fund collection.

[0083] The second specific implementation method of step S60 is to optimize the fund collection process through simulated annealing algorithm and use a multi-level security communication mechanism to protect the collection process. First, a unique identifier is assigned to the wallet system, the parent wallet identifier , sub-wallet identifier , where xxxx is an increasing sequence number. Build a communication graph based on wallet identifiers , vertex set Represents all wallets, edge sets Represents the interaction relationship between wallets, edge weight Indicates the frequency of interaction.

[0084] In the key negotiation phase, the improved HyperLogLog algorithm is used to evaluate the interaction strength. Set the number of buckets , map the interaction records through a hash function: The maximum number of leading zeros per bucket record , and calculate the harmonic mean Based on the interaction strength , use the SM4 algorithm as the key derivation function to generate the session key: .

[0085] In the fund collection optimization stage, set the initial parameters of the algorithm: initial temperature , temperature reduction coefficient , termination temperature The optimal fund collection scheme is iteratively calculated at each temperature. The goal is to minimize the number of sub-wallets involved in the collection while meeting the transaction amount requirements. During the optimization process, the amount of coin strings in each sub-wallet is used as a decision variable to construct the objective function , represents the difference between the sum of the selected coin string amounts and the target amount. In each iteration, some sub-wallets are randomly selected or replaced to participate in the scheme, and the objective function value of the new scheme is calculated. If the new scheme is better, it is directly accepted; if the new scheme is worse, it is replaced according to probability. Accept new proposals.

[0086] After determining the optimal solution, we will start to implement the safe fund collection process. The collection instructions use a sharding encryption mechanism to Divided into Fragments: . Calculate the hash value for each fragment , construct the encryption matrix using the session key: The parent wallet first sends an encrypted initial collection instruction, including the collection amount, timestamp and other information. After receiving it, the sub-wallet performs shard decryption and integrity verification, and returns the current balance information after verification. All communication data is protected by the same shard encryption mechanism.

[0087] After the parent wallet verifies the sub-wallet information, it sends a collection confirmation instruction. The sub-wallet performs the operation of locking the corresponding coin string, constructs the transaction assets and sends them to the parent wallet. The status information of the entire collection process is recorded through the secure storage module to ensure the atomicity of the fund collection operation. At the same time, based on the dynamic session key and sharding encryption mechanism, the confidentiality and integrity of the data in the collection process are guaranteed. Through this multi-level security mechanism, both the efficiency of fund collection and the security of the entire process are guaranteed.

[0088] In order to better understand the second specific implementation of S60, the encryption scheme is now disassembled and described separately as follows:

[0089] Encryption scheme design:

[0090] 1. Wallet coding structure:

[0091] Assign a unique identifier to each wallet , the structure is: .

[0092] in, Indicates the wallet type (1 byte, 0 indicates a parent wallet, 1 indicates a sub-wallet); Indicates the level to which it belongs (2 bytes); Indicates the sequence number (4 bytes).

[0093] 2. Relationship diagram construction:

[0094] Constructing a directed graph ,in:

[0095] Vertex Set Represents all wallets;

[0096] Edge Set Represents the interaction between wallets;

[0097] Edge Weight Representation Node and nodes The frequency of interaction between them.

[0098] 3. Optimal communication path selection:

[0099] Calculate the optimal communication path based on the improved HyperLogLog+Dijkstra algorithm:

[0100] (1) Map each wallet’s interaction records to In buckets: ;

[0101] (2) The maximum number of leading zeros recorded in each bucket: ;

[0102] (3) Calculate the harmonic mean: ;

[0103] in, is the correction factor, For the Maximum number of leading zeros per bucket.

[0104] 4. Key generation process:

[0105] (1) Initialize the key pool , containing the basic key material;

[0106] (2) Calculate the interaction intensity matrix : ;

[0107] (3) Generate session keys for each pair of wallets that frequently interact: .

[0108] 5. Encryption algorithm:

[0109] (1) Data sharding: The data to be encrypted Divided into Fragments: ;

[0110] (2) Constructing the encryption matrix : ;

[0111] in, is a symmetric encryption function, is a hash function.

[0112] Among them, the PBKDF key derivation function is specifically expressed as follows:

[0113] ;

[0114] ;

[0115] ;

[0116] ;

[0117] ;

[0118] .

[0119] Where: is the final derived key result, the length is Bit; It is a pseudo-random function. HMAC-SM3 is used in this scheme. is the initial password; A random salt value with a length of no less than 16 bytes; is the number of iterations, which is 10000 in this scheme; For the desired key length, this scheme takes 256 bits; is the output length of the hash function, SM3 is 256 bits; is a 32-bit big-endian integer; It is a bitwise XOR operation; It is the bit string concatenation operation.

[0120] The parameter acquisition method is:

[0121] By the parent wallet based on the device serial number Generate, using SM3 hashing: ,in It is the private key of the parent wallet;

[0122] It is generated by a cryptographically secure random number generator and has a length of 32 bytes;

[0123] The function is implemented using HMAC-SM3: .

[0124] Among them, the simulated annealing algorithm to solve the optimal solution of fund collection is specifically expressed as follows:

[0125] ;

[0126] ;

[0127] ;

[0128] .

[0129] Where: is the objective function, which represents the difference between the current solution and the target amount; The total amount of the currently selected coin string; The target collection amount; is the total number of sub-wallets; is a 0-1 variable, indicating the Whether the sub-wallet is selected; For the The amount of available coins in each sub-wallet; For the The temperature of the iteration; is the temperature reduction coefficient, which takes a value of 0.95; is the probability function of accepting a new solution.

[0130] The parameter acquisition method is:

[0131] Initial temperature Set to 100;

[0132] End temperature Set to 0.01;

[0133] The number of iterations at each temperature Set to 100;

[0134] Obtained by querying the sub-wallet status: ,in For the The number of tokens in each sub-wallet, For the The first The amount of a coin string;

[0135] Initial solution Obtained by randomly generating a 0-1 sequence, satisfying ;

[0136] Neighborhood solution Obtained by randomly flipping a bit in the current solution: ,in is a randomly selected position.

[0137] A second aspect of the present invention provides a computer-readable storage medium, wherein the computer-readable storage medium stores program instructions, and when the program instructions are run in a computer, they are used to execute the above-mentioned multi-level hardware wallet transaction method for digital currency.

[0138] A third aspect of the present invention provides a multi-level hardware wallet transaction system for digital currency, which includes the above-mentioned computer-readable storage medium.

[0139] Specifically, the principle of the present invention is:

[0140] First, in terms of fund collection optimization, the present invention adopts the simulated annealing algorithm based on the following considerations: fund collection is essentially a combinatorial optimization problem, which requires finding the global optimal solution among a large number of possible collection schemes. The simulated annealing algorithm can gradually converge to the optimal solution while maintaining a certain degree of randomness by simulating the solid annealing process. The initial temperature, cooling coefficient and termination temperature parameters set by the algorithm enable the system to strike a balance between exploring new solutions and using known solutions.

[0141] Secondly, the principle of using the improved HyperLogLog algorithm to evaluate the interaction intensity between wallets is that the cardinality of large-scale data sets can be accurately estimated using a very small memory space through probabilistic statistical methods. The algorithm maps interaction records to different buckets through a hash function and estimates the number of different elements by recording the maximum leading zero. This method is particularly suitable for interaction analysis of large-scale wallet systems, which not only ensures accuracy but also avoids storage overhead.

[0142] In terms of security mechanism design, the core idea of ​​the present invention using fragmented encryption is to divide the complete instruction data into multiple independent fragments, each of which contains complete security attributes. This design makes it impossible for an attacker to restore the complete information even if he obtains part of the data. At the same time, the dynamic session key generated based on the interaction strength ensures the timeliness and uniqueness of the key, effectively preventing replay attacks.

[0143] The design principle of the wallet identifier system is based on the idea of ​​hierarchical coding, which uniquely identifies each wallet through the combination of different bit segments and implicitly expresses the hierarchical relationship between wallets. This coding method not only facilitates system management, but also provides a basis for the implementation of permission control and security policies.

[0144] At the system architecture level, the present invention adopts the principle of modular design to decompose the fund collection process into multiple independent but mutually cooperative functional modules. This design not only ensures the independence of each module, but also realizes efficient collaboration between modules through standard interfaces. The modular design also improves the maintainability and scalability of the system.

[0145] In terms of concurrency control, the present invention manages the aggregation process through a state machine model to ensure the atomicity and consistency of the operation. Each aggregation operation is modeled as a state transition process, and the system ensures data consistency through strict state checking and rollback mechanisms.

[0146] Finally, the adaptive optimization mechanism of the present invention is based on feedback control theory. The system realizes a closed-loop optimization process by real-time monitoring and aggregation of performance indicators and dynamically adjusting algorithm parameters and strategies. This design enables the system to adapt to different network environments and business scenarios and maintain optimal performance.

[0147] A specific embodiment 1 of the present invention is provided below. This embodiment 1 constructs a hardware wallet management system, such as Figure 2 As shown, the specific implementation steps are as follows:

[0148] The first step is to build a mother wallet. Based on the central bank's root key and the operating institution's banking industry key, a business group mother wallet key is derived for a hardware wallet group, hereinafter referred to as the mother wallet. The mother wallet key has the ability to create, revoke, and manage the validity period of sub-keys. The mother wallet key is issued by the central bank system, used for safekeeping by rail transit agencies, and stored in the rail transit core transaction system.

[0149] The second step is to create a sub-hardware wallet. The sub-wallet key is derived from the mother wallet and the sub-wallet secret key is created and written into the hard wallet medium. The mother wallet can revoke, re-enable, and manage the timeliness of the key in the sub-wallet through signature encryption technology. The medium will serve as a terminal for digital currency transaction acceptance. In the process of system operation, a mother wallet can derive multiple sub-wallets, and each sub-wallet is independent of each other, and there can be multiple such acceptance terminals in each system at the same time, and each terminal can only have a one-to-one relationship with the sub-wallet. In the process of issuing sub-keys, it must be completed through the PBKDF key derivation function. The algorithm function is defined as follows: RK=PBKDF2(PRF,Pwd,Salt,c,dkLen), where: RK is the final key result generated by the algorithm; PRF is a random function with an output length of Len; Pwd is the original password; Salt is the encrypted salt value, and the salt value of each sub-wallet is different; C is the number of iterative operations; dkLen is the length of the final key.

[0150] The third step is to write the sub-hard wallet program. The sub-hard wallet program is mainly divided into two parts, one for receiving funds and the other for collecting funds to the parent wallet. The sub-wallet does not contain active transaction programs.

[0151] Step 4: Sub-wallet receives payment. Figure 3 As shown, during the payment process, the payment wallet selects a coin string greater than or equal to the current transaction and locks the entire coin string. If the coin string amount is equal to the transaction amount, create an equal amount of transaction assets. If the coin string is greater than the transaction amount, create a transaction asset equal to the transaction amount and a balance asset of the coin string amount minus the transaction amount. The payment wallet signs the transaction asset with the payment wallet private key, encrypts it with the receiving sub-wallet public key, and sends it to the sub-wallet. After the sub-wallet receives the transaction, it traces back to see if the issuing root certificate of the payment wallet certificate is the central bank root certificate. If so, it continues to verify whether the issuing original coin string summary and the transaction assets are valid. If valid, the transaction is completed. If invalid, the transaction is terminated.

[0152] Step 5: Encryption and locking of the coin string in the sub-wallet. Through the sub-wallet collection program, after the sub-wallet receives the assets from the payer and verifies the validity of the assets, it destroys the assets and creates an equal amount of coin strings, which are encrypted with the public key of the master wallet.

[0153] Step 6: Master wallet fund transaction. When the master wallet needs to conduct a fund transaction, it is necessary to collect funds from each sub-wallet. To avoid data storage overflow in the master wallet caused by full collection, it is necessary to find the optimal solution for asset collection in each sub-wallet through Simulated Annealing (SA). The specific solution process is as follows:

[0154] Step 601 Initialization:

[0155] Temperature parameter: Set the initial temperature T0 and a cooling rate α (usually less than 1).

[0156] Initial solution: Randomly select a combination of coin strings in several sub-wallets as the initial solution and calculate their sum.

[0157] Objective function: Define a fitness function f, which is the absolute value of the difference between the target sum and the actual sum, ∣S−target∣, where S is the sum of the current solution.

[0158] Step 602 Construct the neighborhood structure: Define a neighborhood structure that allows generating new candidate solutions from the current solution. For example, one can choose to replace an element, add or delete an element, etc.

[0159] Step 603 Simulated annealing loop:

[0160] Number of iterations: Set the maximum number of iterations n at each temperature.

[0161] Temperature decrease: Set a cooling strategy, such as Tk+1 = αTk+1 = αTk.

[0162] The acceptance criteria include:

[0163] For each temperature T, generate a new candidate solution x′ in each iteration;

[0164] Calculate the new fitness value f(x′);

[0165] If the new fitness value is better (i.e., f(x′) < f(x)), then accept the new solution;

[0166] If the new fitness value is worse (i.e., f(x′) > f(x)), then accept the new solution with a certain probability;

[0167] Here T is the current temperature value.

[0168] Cooling process: lower the temperature and continue iterating until the temperature drops to a very low threshold or the maximum number of iterations is reached.

[0169] Through the above steps, we can find out the sub-wallet that needs to be mobilized for this transaction and the list of coin strings in the sub-wallet.

[0170] Step 6: Sub-wallet funds are transferred to the parent wallet. The fund transfer process is as follows:

[0171] ① The parent wallet constructs and collects the initial instructions, signs the instructions with the private key, and sends them to the sub-wallet after signing.

[0172] ② The sub-wallet verifies the initial collection instruction and verifies whether the instruction signature is from its own upper-level sub-wallet through its corresponding parent wallet public key. If not, the process is interrupted. If so, the current sub-wallet balance and each coin string hash are obtained, and the signature is issued after being signed with the sub-wallet private key. The process will be recorded through the se module to mark the completion of the first collection instruction response.

[0173] ③After the parent wallet receives the response to the first collection instruction, it verifies whether the signature of the sub-wallet is its own next-level sub-wallet, and verifies whether the sub-wallet certificate is within the validity period. If not, the transaction is terminated. If so, it verifies whether the coin string information in the response information is legal, and performs coin string backtracking through the central bank's core system. When the verification is passed, a collection confirmation instruction is issued. The same as step ①, the confirmation collection instruction and the coin string information to be collected are signed and sent to the sub-wallet.

[0174] ④ After receiving the confirmation collection instruction, the sub-wallet verifies whether the instruction signature is from its own upper-level parent wallet. If not, the transaction is terminated. If so, the preliminary collection instruction record is obtained from the se module. If it does not exist, the transaction is terminated. If it does exist, the coin string set in the confirmation instruction is locked, the transaction assets are constructed, and the signed asset information is sent to the parent wallet.

[0175] ⑤ After receiving the asset transaction data packet, the parent wallet verifies the asset information. If the asset information is incorrect, it sends an error code to the sub-wallet. The sub-wallet releases the assets again, unlocks the coin string, and resets the collection record in se.

[0176] ⑥After receiving the asset transaction data packet, the parent wallet verifies the asset information. If the asset information is correct, the coin string is recorded in the parent wallet, the transaction is completed, and the sub-wallet is notified. After the sub-wallet receives the transaction success notification, it destroys the asset and the corresponding coin string information. Reset the collection record in se.

[0177] In order to further better understand and implement the present invention, the following provides Example 2 of a specific application scenario of the present invention: This embodiment is based on the implementation of digital RMB charging in a certain city rail transit system, and specifically implements a multi-level hardware wallet transaction system for digital currency. The city rail transit line has a total of 32 stations, with an average daily passenger flow of about 1.5 million, and a passenger flow of 120,000 per hour during peak hours. The system needs to support a variety of payment scenarios, including self-service ticket machines, manual ticket windows, automatic gates, etc., and requires support for fast payment and large-scale fund collection.

[0178] First, build the key system of the system. Obtain a 256-bit root key from the People's Bank of China and generate it using the national secret algorithm SM4. Based on the root key, select the bank business identifier "BANK001" and derive the banking industry key of the operating institution through HMAC key. Further select the rail transit business group identifier "METRO002" and use a dual key derivation scheme to generate the business group mother wallet key. Test verification shows that the entire key derivation process takes no more than 100 milliseconds, meeting the system response requirements. The mother wallet key is stored in the encryption machine of the rail transit core transaction system, which supports the national secret algorithm and has physical tamper-proof capabilities.

[0179] The system deploys 300 terminal devices that support digital currency payment, including 200 automatic ticket machines, 50 manual windows and 50 gate machines, and each device is configured with a hardware wallet. To ensure the uniqueness of the device, a serial number is assigned to each device by using the "MPOS" prefix plus an 8-digit serial number, such as "MPOS00000001". The system derives an independent key pair for each hardware wallet through the PBKDF2 algorithm. During the derivation process, the number of iterations is set to 10,000, and a 32-byte random salt value is used to finally generate a 256-bit derived key. Based on the derived key, the SM2 algorithm is used to generate a public and private key pair. Test data shows that the key derivation and generation process for a single wallet takes an average of 200 milliseconds.

[0180] All hardware wallets use secure smart card chips that comply with the FIPS140-2Level3 standard. The specific parameters are shown in Table 1 below.

[0181] Table 1 Chip parameter table

[0182] Parameters Parameter Value CPU frequency 400MHz RAM capacity 64KB EEPROM capacity 256KB Cryptographic algorithm accelerator Support SM2 / SM3 / SM4 Physical attack resistance level FIPS140-2Level3 Random Number Generator Compliant with NIST SP800-90A Communication interface ISO / IEC7816

[0183] The system develops the sub-wallet program and writes it into the hardware wallet. The program adopts a layered architecture, with the underlying password library occupying 40KB of storage space, the middle-level security storage module occupying 60KB of storage space, and the upper-level business function module occupying 100KB of storage space. The program has two basic functions: collection and fund collection. The collection function supports a maximum single amount of 1,000 yuan and a daily cumulative limit of 50,000 yuan. The fund collection function is uniformly executed after the end of each business day, and the funds collected on that day are collected into the parent wallet.

[0184] A typical transaction scenario in the actual operation of the system is as follows: A passenger uses digital RMB to buy a 10-yuan one-way ticket at a ticket vending machine. The passenger's digital RMB wallet selects a 20-yuan coin string, which the system splits into 10 yuan of transaction assets and 10 yuan of balance assets. The transaction assets are signed with the payment wallet private key and encrypted with the public key of the ticket machine hardware wallet. The encrypted transaction data is transmitted to the ticket machine hardware wallet via near-field communication, and the transmission process takes about 50 milliseconds.

[0185] After receiving the transaction data, the hardware wallet first verifies the payment wallet certificate chain. The verification process includes steps such as checking the certificate validity period, confirming the certificate status, and tracing back to the central bank's root certificate. The entire verification process takes about 150 milliseconds. Then the legitimacy of the coin string is verified through the digital currency verification system, and the verification process takes about 100 milliseconds. Finally, the validity of the transaction assets is verified, including signature verification, which takes about 50 milliseconds. After all verifications are passed, the transaction is completed and the ticket is issued to the passenger. The entire transaction process, from user payment to ticket issuance, takes no more than 500 milliseconds.

[0186] After the transaction is completed, the hardware wallet will destroy the 10 yuan transaction assets received and create a new coin string of the same amount. The new coin string uses a unique 32-byte identifier to record information such as the amount and creation time, and is encrypted and protected using the parent wallet public key. The encrypted coin string is stored in the secure storage area of ​​the hardware wallet, waiting to be collected at the end of the day.

[0187] At the end-of-day collection stage, the system records show that a total of 32,760 transactions occurred that day, with a total transaction amount of 436,521 yuan, distributed in 285 hardware wallets. The system needs to collect these funds into the parent wallet. Considering the communication time and processing overhead of each wallet, the system uses simulated annealing algorithm to optimize the collection scheme. The specific optimization process is shown in Table 2 below.

[0188] Table 2 Simulated annealing parameters

[0189] Optimization parameters Parameter Value Initial temperature 100 End temperature 0.01 Temperature drop coefficient 0.95 Iterations per temperature 100 Maximum number of wallets 50

[0190] The algorithm first randomly selects 50 wallets as the initial solution and calculates the difference between the total amount of funds in the selected wallets and the target amount. Then, in each iteration, some wallets are randomly replaced and the annealing criterion is used to decide whether to accept the new solution. After about 1,000 iterations, the algorithm converges to the optimal solution and selects 47 wallets for the first batch of collection, which can cover 80% of the total funds.

[0191] The system starts to execute the fund collection process. The parent wallet first sends the initial collection instruction to the 47 sub-wallets. The instruction contains information such as the collection amount and timestamp, and is signed with the parent wallet's private key. After receiving the instruction, each sub-wallet verifies the signature of the parent wallet and returns the current available coin string information. After the parent wallet verifies the information of all sub-wallets, it sends a collection confirmation instruction. The sub-wallet locks the corresponding coin string, constructs the transaction assets and sends them to the parent wallet. The entire first batch of collections takes about 15 minutes.

[0192] The system continues to collect subsequent batches until all funds are collected. Statistics show that six batches of funds were collected on that day, with an average of 40 wallets processed in each batch, and the collection processing time for a single wallet was about 20 seconds. The entire collection process was completed within 2 hours, meeting business requirements. The specific collection results are shown in Table 3 below.

[0193] Table 3 Collection batch table

[0194] Batch collection Number of wallets Amount collected (yuan) Collection ratio First batch 47 349217 80% Second batch 42 52383 12% The third batch 38 21826 5% The fourth batch 35 8730 2% The fifth batch 33 3492 0.8% The sixth batch 30 873 0.2%

[0195] Statistics after the system was put into operation for one month showed that the average number of transactions per day was about 33,000, and the peak number of transactions reached 45,000; the average processing time for a single transaction was 450 milliseconds, and 99% of transactions could be completed within 600 milliseconds; the average time for end-of-day collection was 1.8 hours, and the longest time was no more than 2.5 hours; the overall operation of the system was stable, and no capital errors occurred. By analyzing the transaction logs, it was found that the average transaction processing time of the system during peak hours would increase by about 50 milliseconds, mainly due to the longer response time of the digital currency verification system. In response to this situation, the system optimized the concurrent processing mechanism of the verification process, merged batch transaction requests for processing, and controlled the performance loss during peak hours to less than 10%.

[0196] The system also implements a comprehensive monitoring and alarm mechanism. Multiple monitoring indicators are set, including transaction response time, verification success rate, fund collection completion rate, etc. When the indicator exceeds the threshold, the system automatically issues an alarm. For example, if the transaction verification failure rate of a hardware wallet exceeds 1%, or the accumulated funds in a single wallet exceed 150% of the average daily transaction amount, the system will immediately notify the operation and maintenance personnel to check. These measures effectively ensure the safe and stable operation of the system.

[0197] In general, this embodiment demonstrates the specific application of the present invention in the field of rail transit. Through reasonable system architecture design and optimized algorithm implementation, large-scale digital currency transaction processing is successfully supported, verifying the feasibility and practical value of the present invention. The various performance indicators of the system meet business requirements and have good security and reliability. This implementation scheme can serve as an important reference for implementing the present invention in other scenarios.

[0198] The following provides an embodiment 3 of a specific application scenario of the present invention. This embodiment 3 provides an encryption method based on graph theory and probability statistics applied to a digital currency hardware wallet, corresponding to the second specific implementation method of step S60 of the present invention, for protecting the data transmission security in the digital currency wallet system. The method adopts a multi-level security mechanism to ensure the confidentiality, integrity and availability of system data.

[0199] First, the unique encoding of the wallet is implemented. The system assigns a 7-byte unique identifier WID to each wallet. The first byte is the Type field, with 0 representing the parent wallet and 1 representing the sub-wallet; the 2nd-3rd bytes are the Level field, which indicates the position of the wallet in the system hierarchy. The Level of the parent wallet is fixed to 0000, and the sub-wallets are numbered from 0001; the 4th-7th bytes are the Index field, which indicates the serial number in the same-level wallet. For example, the WID of a third-level sub-wallet may be: 0x01000200000001, indicating that this is the first wallet in a second-level sub-wallet. The WID code table of all wallets in the system is stored in a secure database and backed up regularly.

[0200] Secondly, a wallet interaction relationship graph is constructed. The system maintains a directed graph data structure, where the vertices in the graph represent wallets and the edges represent the interaction relationships between wallets. Each edge has a weight value, which represents the frequency of interaction between connected wallets. The weight value is obtained by accumulating the number of interactions in two adjacent statistical periods (the default is 1 hour). For example, if wallet A and wallet B have 30 interactions in the last two hours, the weight of edge AB is set to 15 (i.e. the average number of interactions per hour). The system updates the weight data of the graph once an hour.

[0201] Then, the improved HyperLogLog algorithm is implemented for interaction pattern analysis. The system selects 1024 hash buckets (m=1024) and uses MurmurHash3 as the basic hash function. For each wallet interaction, the system calculates hash(source wallet WID||target wallet WID||timestamp) and maps it to the corresponding bucket modulo. Each bucket records the maximum number of leading zeros among all hash values ​​that fall into the bucket. For example, after the hash value generated by a certain interaction is converted to binary, the number of leading zeros is 5. If it is greater than the value 4 recorded in the current bucket, it is updated to 5. Based on these statistical data, the system estimates the interaction pattern through the harmonic mean, and the correction factor αm is taken as 0.7213.

[0202] Then the key material is generated and managed. The system initializes a 4MB key pool, which contains random data obtained from the hardware random number generator. Based on the weight of the interaction graph and the statistical results of HyperLogLog, the interaction strength between each pair of wallets is calculated. The calculation formula for interaction strength is:

[0203] ;

[0204] Among them, norm() represents the normalization function, which maps the value to the interval [0,1]. For wallet pairs whose interaction strength exceeds the threshold (default 0.8), the system generates a dedicated session key. The session key is derived from the key pool through HKDF (HMAC-based key derivation function) and the default length is 256 bits.

[0205] Finally, the data is encrypted in slices. The system slices the data to be encrypted into 1KB slices, and each slice is attached with a 32-byte SHA-256 hash value. For data with N slices, the system constructs an N×N encryption matrix. Each element in the matrix contains an encrypted data slice and its hash value. Encryption uses the AES-256-GCM algorithm and the corresponding session key. For example, a 4MB data file is divided into 4000 slices, forming a 4000×4000 encryption matrix. Each matrix element is about 1.1KB in size (including the data slice, hash value, and GCM authentication tag).

[0206] In practical applications, the effect of this encryption scheme is shown in Table 4 below:

[0207] Table 4 Encryption scheme performance table

[0208] Performance Indicators Numeric Single key generation time <5ms 1MB data encryption time <50ms Decryption time for 1MB data <40ms Storage overhead 1.2 times the original data Key update cycle 1 hour Maximum number of supported wallets 10 million

[0209] The encryption scheme was tested in a city rail transit system for three months, processing more than 100 million transactions without any security incidents. The system can effectively defend against common threats such as replay attacks and man-in-the-middle attacks. At the same time, the key management is highly automated and the operation and maintenance costs are low. Statistics show that through interactive mode analysis and dynamic key generation mechanism, the system's average encryption and decryption processing delay is reduced by about 40% compared with traditional solutions, and memory usage is reduced by about 25%.

[0210] In general, this encryption scheme achieves the security protection of data transmission in the digital currency wallet system through graph theory modeling and probability statistical analysis. The scheme has strong practicality and meets the performance requirements of large-scale deployment. At the same time, the scheme has good scalability and can adjust parameter configuration according to actual needs. This scheme also has important reference value for other similar digital currency application systems.

[0211] The above description is only a specific implementation mode of the present invention, but the protection scope of the present invention is not limited thereto. Any technician familiar with the technical field can easily think of changes or substitutions within the technical scope disclosed by the present invention, which should be covered by the protection scope of the present invention.

Claims

1. A multi-level hardware wallet transaction method for digital currency, characterized in that: The following steps are involved: S10. Based on the central bank root key and the banking industry key of the operating institution, a business group mother wallet key is derived for the hardware wallet group. The business group mother wallet key is used to create, revoke and manage the validity period of the subkey; S20, deriving a sub-wallet key through the business group master wallet key, writing the sub-wallet key into a hardware wallet medium, the hardware wallet medium serving as a digital currency transaction acceptance terminal, and the sub-wallet key being derived through a key derivation function; S30, writing a sub-hardware wallet program into the hardware wallet medium, wherein the sub-hardware wallet program includes a payment collection program and a fund collection program to the parent wallet; S40, receiving the transaction assets sent by the payment wallet through the sub-hardware wallet program, verifying the payment wallet certificate issuing root certificate, verifying the issuance of the original coin string digest and the transaction assets, and completing the payment transaction; S50, destroying the transaction assets and creating a coin string of equal value, and encrypting and locking the coin string of equal value by using the public key of the business group mother wallet key; S60. Calculate the optimal solution for fund collection through simulated annealing algorithm, determine the sub-wallets and coin strings that need to be collected, and execute the fund collection process, which includes sending an initial collection instruction, verifying a collection response, sending a collection confirmation instruction, locking the coin string, constructing transaction assets, and resetting the collection record.

2. A multi-level hardware wallet transaction method for digital currency according to claim 1, characterized in that: The generation of the business group parent wallet key specifically includes: Step 101: Obtain the root key issued by the central bank; Step 102: Generate an operating institution banking industry key using the root key; Step 103: Generate a business group parent wallet key based on the root key and the banking industry key of the operating institution; Step 104: storing the business group parent wallet key in the rail transit core transaction system; Step 105: Establish a binding relationship between the business group parent wallet key and the rail transit core transaction system.

3. A multi-level hardware wallet transaction method for digital currency according to claim 2, characterized in that: The key derivation completed through the key derivation function specifically includes: Step 201, setting the output length of the key derivation function; Step 202: Set a different encryption salt value for each sub-wallet; Step 203, setting the number of iterative operations; Step 204: Set the final key length; Step 205: Generate a sub-wallet key through the key derivation function; Step 206: Establish a one-to-one correspondence between the sub-wallet key and the hardware wallet medium.

4. A multi-level hardware wallet transaction method for digital currency according to claim 3, characterized in that: The specific steps of the collection transaction include: Step 401: The payment wallet selects a transaction coin string and locks the transaction coin string; Step 402: When the transaction coin string amount is greater than the transaction amount, create transaction assets and balance assets; Step 403: Use the payment wallet private key to sign the transaction assets; Step 404: Use the public key of the receiving sub-wallet to encrypt the signed transaction assets; Step 405: Send the encrypted transaction assets to the sub-wallet.

5. A multi-level hardware wallet transaction method for digital currency according to claim 4, characterized in that: The specific steps of the simulated annealing algorithm include: Step 501, setting the initial temperature and cooling rate; Step 502: Randomly select a coin string combination in the sub-wallet as an initial solution; Step 503: Establish the difference between the target sum and the actual sum as the fitness function; Step 504: define a neighborhood structure to generate candidate solutions; Step 505: Calculate the acceptance probability of the new solution according to the fitness function; Step 506: Iteratively calculate the optimal solution using the temperature reduction strategy.

6. A multi-level hardware wallet transaction method for digital currency according to claim 5, characterized in that: The fund collection process specifically includes: Step 601: The parent wallet constructs an initial collection instruction and signs it with a private key; Step 602: The sub-wallet verifies the initial collection instruction and obtains the current balance and coin string hash; Step 603: The sub-wallet signs with the private key and sends the balance information; Step 604: The parent wallet verifies the signature of the child wallet and the validity period of the certificate; Step 605: The parent wallet sends a collection confirmation instruction; Step 606: The sub-wallet locks the coin string and constructs the transaction assets; Step 607: The parent wallet verifies the asset information; Step 608: If the asset information is incorrect, an error code is sent to the sub-wallet; after receiving the error code, the sub-wallet releases the assets and unlocks the coin string; resets the collection record; if the asset information is correct, the coin string is recorded in the parent wallet; and the sub-wallet is notified that the transaction is completed.

7. A multi-level hardware wallet transaction method for digital currency according to claim 6, characterized in that: The child hardware wallet program also includes: Step 311: Setting a secure storage module to record the transaction process; Step 312: Record the response status of the collection instruction in the secure storage module; Step 313, recording the coin string locking status in the secure storage module; Step 314: Record the transaction asset construction status in the secure storage module; Step 315: Record the transaction completion status in the secure storage module; Step 316: Control the transaction process according to the record status in the secure storage module.

8. A multi-level hardware wallet transaction method for digital currency according to claim 7, characterized in that: The fund collection process also includes an optimized collection path and a secure communication mechanism, specifically: An improved hierarchical deterministic path scheme is used to optimize the collection path, including: constructing a tree structure of sub-wallets according to the hierarchical relationship; calculating the optimal collection order of each level based on the greedy algorithm; and determining the cross-level collection path through dynamic programming; A deterministic key derivation mechanism is used to protect the collection process, including: assigning a unique deterministic key to each wallet; generating a session key based on a key derivation function; and using symmetric encryption to protect collection instructions and response data.

9. A computer-readable storage medium, characterized in that: The computer-readable storage medium stores program instructions, and when the program instructions are executed in a computer, they are used to execute the multi-level hardware wallet transaction method for digital currency according to any one of claims 1 to 8.

10. A multi-level hardware wallet transaction system for digital currency, characterized in that: A computer-readable storage medium comprising the computer-readable storage medium of claim 9.

Images