A wallet custody method, system, and storage medium

Abstract

This application discloses a wallet hosting method, apparatus, and storage medium, applied in the field of blockchain technology. The method includes: obtaining attribute information of an application registering a wallet service; determining the wallet hosting service type of the application based on the application's attribute information; determining the target wallet system of the application in the wallet hosting service system and the target cache corresponding to the target wallet system based on the application's wallet hosting service type; generating the interface path corresponding to the application based on the mapping relationship between the application and the target wallet system; continuously creating wallet accounts using the target wallet system, generating private keys corresponding to the wallet accounts, and determining the blockchain address corresponding to the wallet accounts; and storing the correspondence between wallet accounts, the private keys corresponding to the wallet accounts, and the blockchain addresses corresponding to the wallet accounts in the cache.

Description

Technical Field

[0001] This application relates to the field of blockchain technology, specifically to a wallet custody method, system, and storage medium. Background Technology

[0002] In blockchain-based fields such as gaming, finance, and insurance, numerous applications offer wallet services to users. These services include wallet creation, querying, and signing. Users of these wallet services are only concerned with their wallet account's blockchain address and do not need information such as the wallet's private key or mnemonic phrase. Therefore, a dedicated system is needed to manage user wallets.

[0003] Because different applications have varying requirements for wallet data isolation, private key security, and wallet creation and query performance, different wallet hosting strategies must be provided to meet the specific performance needs of each application. Currently, there are two wallet hosting methods: one is for each application to host its own user wallets to ensure data storage and security; the other is for multiple applications to use a unified wallet hosting service system to host user wallets, supporting wallet creation and querying for multiple applications.

[0004] If a business unit has multiple applications, designing a separate wallet hosting service system for each application would be prohibitively costly and extremely inefficient. Using a unified wallet hosting service system would require multiple applications to call the same interface to create wallets. Since the wallet hosting service system needs to generate a wallet private key and determine a blockchain address when creating a wallet account, the entire wallet creation process is slow. Therefore, it cannot support the wallet creation needs of multiple applications. Furthermore, when wallet data from multiple applications is stored in a single database, the data from different applications will be mixed together, leading to security risks. Therefore, how to efficiently and securely provide unified hosting for wallets from multiple applications has become a pressing issue. Summary of the Invention

[0005] This application provides a wallet hosting method, system, and storage medium. By creating independent wallet systems and a public wallet system within the wallet hosting service system, it achieves the goal of hosting wallet data for different applications on demand. In this way, the wallet hosting service system provides a unified wallet interface externally, supporting the hosting of wallets for any application. Internally, different wallet systems are used to support the isolation of wallet data from multiple applications, ensuring the security of wallet private key data. Simultaneously, each internal wallet system asynchronously creates wallet accounts, improving the efficiency of wallet account creation.

[0006] The first aspect of this application provides a wallet custody method applied to a wallet custody service system, the wallet custody service system including independent wallet systems and public wallet systems, the method comprising:

[0007] Obtain the attribute information of the application that registered the wallet service.

[0008] Determine the wallet hosting service type for the application based on its attribute information.

[0009] Based on the application's wallet hosting service type, determine the application's target wallet system within the wallet hosting service system, and determine the target cache corresponding to the target wallet system.

[0010] Establish a mapping relationship between the application and the target wallet system, and generate the corresponding interface path for the application based on the mapping relationship. The interface path is used by the application to call the target wallet system.

[0011] Use the target wallet system to continuously create wallet accounts and generate the private keys corresponding to the wallet accounts.

[0012] Determine the blockchain address corresponding to the wallet account.

[0013] The cache stores the correspondence between wallet accounts, the private keys associated with wallet accounts, and the blockchain addresses associated with wallet accounts.

[0014] A second aspect of this application provides a wallet custody device, which includes a wallet custody service system. The wallet custody service system includes an independent wallet system and a public wallet system. The wallet custody device includes:

[0015] The acquisition unit is used to obtain attribute information of the application that registers the wallet service.

[0016] The determination unit is used to determine the wallet hosting service type of the application based on the application's attribute information.

[0017] The determining unit is also used to determine the target wallet system of the application in the wallet hosting service system based on the wallet hosting service type of the application, and to determine the target cache corresponding to the target wallet system.

[0018] Establishment unit, used to establish the mapping relationship between the application and the target wallet system.

[0019] The generation unit is used to generate the corresponding interface path for the application based on the mapping relationship. The interface path is used by the application to call the target wallet system.

[0020] The unit is also used to continuously create wallet accounts using the target wallet system.

[0021] The generation unit is also used to generate the private key corresponding to the wallet account.

[0022] The unit is also used to determine the blockchain address corresponding to the wallet account.

[0023] The storage unit is used to store the correspondence between the wallet account, the private key corresponding to the wallet account, and the blockchain address corresponding to the wallet account in the cache.

[0024] A third aspect of this application provides an electronic device, including: a memory and a processor, wherein the memory and the processor are coupled.

[0025] The memory is used to store one or more computer instructions.

[0026] The processor is used to execute one or more computer instructions to implement a wallet escrow method as described in the first aspect above.

[0027] A fourth aspect of this application also provides a computer-readable storage medium storing one or more computer instructions that are executed by a processor to implement a wallet custody method as described in any of the above technical solutions.

[0028] The wallet hosting method provided in this application first obtains the attribute information of the application registering the wallet service. This attribute information determines the application's hosting requirements, and thus whether the application's wallet data should be hosted through an independent wallet system or a non-independent wallet system. Next, a target wallet system, along with its corresponding target cache and database, is selected. Finally, a mapping relationship between the application and the target wallet system is established, generating an interface path. This allows the application to call the target wallet system through the interface path. The target wallet system asynchronously and continuously establishes a cached mapping between the wallet account, its corresponding private key, and its corresponding blockchain address. This allows the target wallet system to directly assign the cached wallet account to the application's user when it receives a wallet creation request from the application, thereby saving the user's wallet creation time.

[0029] The wallet hosting method provided in this application utilizes a single wallet hosting service system to offer wallet hosting services to multiple applications with different needs. This system provides a unified wallet service interface externally, while internally it creates independent wallet systems and a public wallet system. When an application calls the wallet service interface to host wallet data, the wallet hosting service type for the application is first determined based on the application's attribute information, and then either an independent wallet system or a public wallet system is selected for hosting. Simultaneously, each wallet system has its own target cache and database. This ensures that wallet data from different applications is stored in the databases or caches of different wallet systems, achieving isolation between wallet data and improving the security of data such as private keys. Furthermore, each wallet system continuously and asynchronously creates wallet accounts, generates private keys for wallet accounts, and assigns blockchain addresses. The created wallet accounts are then stored in the cache. Thus, when a user of an application requests to create a wallet, the cached wallet account can be directly provided to the user without needing to synchronously create a wallet account upon receiving a request. This shortens user waiting time and improves wallet creation performance. Attached Figure Description

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

[0031] Figure 1 A network architecture diagram of a wallet custody service system provided in this application embodiment;

[0032] Figure 2 This is a schematic diagram of the structure of the wallet custody service system provided in the embodiments of this application;

[0033] Figure 3 A flowchart illustrating the wallet custody method provided in this application embodiment;

[0034] Figure 4 A flowchart illustrating a method for creating a wallet account as provided in an embodiment of this application;

[0035] Figure 5 A flowchart illustrating the wallet account query method provided in this application embodiment;

[0036] Figure 6 This is a schematic diagram of the structure of a wallet custody device provided in an embodiment of this application;

[0037] Figure 7This is a schematic diagram of the structure of an electronic device provided in an embodiment of this application. Detailed Implementation

[0038] This application provides a wallet hosting method, system, and storage medium. By creating independent wallet systems and a public wallet system within the wallet hosting service system, it achieves the goal of hosting wallet data for different applications on demand. In this way, the wallet hosting service system provides a unified wallet interface externally, supporting the hosting of wallets for any application. Internally, different wallet systems are used to support the isolation of wallet data from multiple applications, ensuring the security of wallet private key data. Simultaneously, each internal wallet system asynchronously creates wallet accounts, improving the efficiency of wallet account creation.

[0039] Many specific details are set forth in the following description to provide a full understanding of this application. However, this application can be implemented in many other ways different from those described herein, and those skilled in the art can make similar extensions without departing from the spirit of this application; therefore, this application is not limited to the specific embodiments disclosed below.

[0040] It should be noted that the terms "first," "second," "third," etc., in the claims, specification, and drawings of this application are used to distinguish similar objects and are not used to describe a specific order or sequence. Such data are interchangeable where appropriate so that the embodiments of this application described herein can be implemented in a sequence other than that shown or described herein. Furthermore, the terms "comprising," "having," and their variations are intended to cover non-exclusive inclusion; for example, a process, method, system, product, or apparatus that includes a series of steps or units is not necessarily limited to those steps or units explicitly listed, but may include other steps or units not explicitly listed or inherent to these processes, methods, products, or apparatuses.

[0041] Blockchain is a time-sequential chained data structure that uses cryptography to ensure the immutability and unforgeability of data; it is a distributed ledger technology. It is generally considered to have characteristics such as decentralization, node participation, unforgeable and tamper-proof stored data, and transparency.

[0042] In blockchain-based fields such as gaming, finance, and insurance, numerous applications offer wallet services to users. These services include wallet creation, querying, and signing. Users of these wallet services are only concerned with their wallet account's blockchain address and do not need information such as the wallet's private key or mnemonic phrase. Therefore, a dedicated system is needed to manage user wallets.

[0043] A custodial wallet, as the name suggests, involves users entrusting their private keys and digital assets to another institution for management, essentially providing centralized and secure asset management and storage. This fundamentally contradicts the decentralization pursued by blockchain technology. However, custodial wallets offer convenience to users; they don't need to worry about forgetting their private keys or mnemonic phrases, and the risk of asset loss due to personal error is greatly reduced. Currently, there are generally two wallet custody methods: one is where each application independently hosts its user wallets. This means each application maintains its own system to provide wallet custody services. In this case, the application is responsible for ensuring wallet data storage and security. The other method involves unifying wallet data from multiple applications within a single wallet service, where one wallet custody service system supports wallet custody for multiple applications.

[0044] If a business unit has multiple applications, designing a separate wallet hosting service system for each application would be prohibitively costly and extremely inefficient. Using a unified wallet hosting service system would require multiple applications to call the same interface to create wallets. Since the wallet hosting service system needs to generate a wallet private key and determine a blockchain address when creating a wallet account, the entire wallet creation process is slow. Therefore, it cannot support the wallet creation needs of multiple applications. Furthermore, when wallet data from multiple applications is stored in a single database, the data from different applications will be mixed together, leading to security risks. Additionally, if the wallet data of a particular application continues to increase, storing too much wallet data in a single database will cause poor database input / output performance, thus impacting the entire service. Therefore, how to efficiently and securely host wallets from multiple applications in a unified manner becomes a pressing issue that needs to be addressed.

[0045] To address the aforementioned problems, this application provides a wallet custody method applied to a wallet custody service system. By creating independent wallet systems and public wallet systems within the wallet custody service system, the method achieves on-demand custody of wallet data for different applications. The method, apparatus, terminal, and computer-readable storage medium described in this application will be further described in detail below with reference to specific embodiments and accompanying drawings.

[0046] Before introducing the embodiments of this application, for ease of understanding, the following will be combined with... Figure 1 The application scenarios of the wallet custody method in the embodiments of this application are introduced. Figure 1 This is a network architecture diagram of a wallet custody service system provided in an embodiment of this application. Figure 1As shown, the network architecture includes: application node device 310, wallet hosting service system node device 320, communication network 330 connecting the application node device and the wallet hosting service system node device, and blockchain node device 340. In this embodiment, the application node device 310 has an application program, which can be a standalone application or a web application. Each application is an application node, and multiple application nodes can be installed, deployed, or run on one application node device 310, or they can be distributed and deployed or run on different application node devices 310. The application node device 310 can be a terminal device, which can be, but is not limited to, desktop computers, laptops, mobile phones, smartwatches, tablets, and other electronic devices with program running capabilities. The wallet hosting service system can be centrally deployed on one device or distributed across multiple devices, depending on the installation and deployment requirements of the wallet hosting service. That is, the wallet hosting service system node device 320 can be one or more server devices, and such server devices can be, but are not limited to, computers, servers, or other network devices.

[0047] Taking the Cloud Music app, which uses a wallet hosting service, as an example: The Cloud Music app, running on mobile phones, tablets, and other terminal devices, acts as an application node. It can call the wallet hosting service system through its interface. The server running the wallet hosting service system acts as a wallet service system node device, responding to the Cloud Music app's calls to the wallet service to enable functions such as wallet creation, transaction query, and electronic payment within the Cloud Music app. The wallet hosting service system can uniformly manage and store wallet data within the Cloud Music app and send relevant transactions to the blockchain node device 340, or query relevant transaction data in the blockchain node device 340 according to relevant needs. The communication network 330 includes various wired and wireless network devices that provide information transmission paths. The Cloud Music app can achieve rapid wallet hosting by calling the unified interface provided by the wallet hosting service system.

[0048] The following is a detailed introduction to the wallet custody service system:

[0049] Figure 2 This is a schematic diagram of the structure of the wallet custody service system provided in an embodiment of this application. Figure 2 As shown, the wallet hosting service system includes: wallet service interface 101, application management system 102, public wallet system 103, independent wallet system 104, database and cache.

[0050] The wallet service interface 101 serves as the interface between the wallet hosting service system and the application. It receives call requests from the application for the internal wallet system. In this embodiment, the wallet service interface 101 receives wallet creation requests, wallet query requests, and wallet signing requests from the application. Therefore, the wallet service interface 101 includes wallet creation interfaces and wallet query interfaces. After an application registers with the wallet hosting service, it needs to determine the target wallet system corresponding to its application within the wallet hosting service system based on the application's requirements. The wallet hosting service system then establishes a mapping relationship between the application and the target wallet system, allocates a corresponding interface to the application based on the mapping relationship, and generates an interface path for the application. This interface path is then used by the application to call the target wallet system within the wallet hosting service system.

[0051] The application management system 102 includes an application management module and a corresponding database. In this embodiment, the application management system 102 manages the identification information and private keys of applications, and stores the correspondence between the application identification information and the application private keys in the corresponding database. When an application registers for a wallet service, the application management system 102 obtains the application's private key from the registration request sent by the application. Then, the application management module manages the information of each application and stores the application's identification information and corresponding private key in the database.

[0052] Public wallet system 103 and independent wallet system 104 are two different wallet service systems provided by the wallet hosting service system. In this embodiment, an independent wallet system 104 hosts the wallet data of only one application, while the public wallet system 103 can host the wallet data of multiple applications. When an application registers for a wallet hosting service, it needs to determine whether the application's wallet hosting service type is a public wallet service or an independent wallet service based on the application's attribute information, thereby determining whether to use a public wallet system or an independent wallet system to host the application's wallet data.

[0053] In this embodiment, each wallet system in the wallet hosting service system is configured with a dedicated database and a dedicated cache. Each wallet system stores the created wallet accounts in its own cache. The database stores various information corresponding to the assigned wallet accounts. The database corresponding to the public wallet system also includes multiple independent wallet tables, each storing only the wallet data for one application, thus achieving data isolation between multiple applications.

[0054] Based on the above, the wallet custody method provided in the embodiments of this application will be described in detail below:

[0055] Figure 3 This is a flowchart illustrating the wallet custody method provided in an embodiment of this application. The method is based on the above... Figure 2 The wallet custody service system shown. The method includes the following steps:

[0056] 301. Obtain the attribute information of the application that registers the wallet service.

[0057] The application (APP) here can be any APP registered with the wallet service. When an application registers with the wallet service, the wallet hosting service system can obtain the application's attribute information from the application's registration information. This attribute information can include the application's identification information, such as the application's identifier (APPKey) and its private key (AppSecret). The wallet hosting service system uses the APPKey to distinguish different applications, while the private key is used to obtain administrative permissions for the application for subsequent wallet hosting. Understandably, the application's attribute information can also include other information, such as the application's user base, performance requirements, service type, etc., without specific limitations. Through this attribute information, the wallet hosting service system can fully understand the application's needs, obtain application information and permissions, and thus manage its wallet data appropriately.

[0058] 302. Determine the wallet hosting service type of the application based on the application's attribute information.

[0059] Wallet hosting services are categorized into independent and public service types. Independent services provide dedicated wallet hosting for individual applications, while public service services utilize a single platform to manage wallet data from multiple applications simultaneously. Therefore, upon receiving application registration information, it's necessary to determine whether the application's wallet hosting service type is independent or public based on the application's attributes.

[0060] In this embodiment, the application's requirements need to be determined based on its attribute information. These requirements are primarily considered from several aspects, such as the application's user base, interface concurrency performance requirements, and data security level requirements. For example, an application with hundreds of millions of users, a peak user wallet creation and query QPS of 10,000, and requiring completely independent data and a high level of security, would require a completely independent wallet hosting service. Conversely, if the application's user base, data requirements, and security level are not high, a separate wallet hosting service is not necessary; a public wallet service can be used to simultaneously host the wallet data of several applications. This saves costs and reduces resource consumption while ensuring the hosting requirements of each application are met.

[0061] For example, Table 1 provides attribute information for several applications, as well as the final deployment method of the wallet hosting service for each application. As shown in Table 1, the Cloud Music APP has a large user base and high requirements for data security, therefore, it needs to deploy an independent wallet hosting service for it. The Youku APP and Westward Journey APP have relatively few users, so a common wallet hosting service can be provided for both, managing the wallet data of both apps simultaneously.

[0062] Table 1

[0063]

[0064]

[0065] 303. Based on the application's wallet hosting service type, determine the target wallet system for the application within the wallet hosting service system.

[0066] The wallet hosting service system includes public wallet systems and independent wallet systems. Once the wallet hosting service type for an application is determined, a suitable wallet system is selected to host the application's wallet data. For independent services, an independent wallet system is used. This requires creating a new independent wallet system within the wallet hosting service system and configuring its cache and database. For public services, a public wallet system can be used.

[0067] For example, if the Cloud Music app requires a separate wallet hosting service, then a separate wallet system for Cloud Music needs to be created within the wallet hosting service system, and the corresponding cache and database for the Cloud Music wallet service need to be configured for this separate wallet system. However, the wallet hosting service type for the Youniker app and the Westward Journey app is a public service type, so the public wallet system within the wallet hosting service system is used to simultaneously host the wallet data for both apps.

[0068] In this system, an independent wallet system stores and manages wallet data for only one application. A public wallet system, on the other hand, requires multiple applications to share a single wallet system. To achieve data isolation between different applications, the database of the public wallet system can provide each application with a separate wallet table, with each table storing only the wallet data for that application. For example, the wallet table name for each application could be "wallet_{appKey}".

[0069] Understandably, if the hosting needs of applications in a public wallet system change—for example, if an application that originally used the public wallet system for wallet hosting needs an independent wallet system due to an increase in the number of users—a new independent wallet system can be created within the wallet hosting service system, and then the data in the application's database wallet table can be migrated.

[0070] For example, the process of migrating wallet data from a public wallet system is as follows: First, a separate wallet service system for applications requiring independent hosting is created within the wallet hosting service system. Then, a separate cache and database are configured for this separate wallet system. Next, the wallet data tables of the applications requiring independent hosting in the public wallet system are transferred to the database of the newly created independent target wallet system. Finally, a mapping relationship is established between the application and the new independent wallet system, and a new interface path corresponding to the application is generated based on this mapping relationship.

[0071] For example, in the above case, the YouNike app is registered as a public service. However, if the number of YouNike app wallet users continues to increase to over ten million, a separate wallet hosting service will be needed. First, a separate wallet system for the YouNike app needs to be created within the wallet hosting service system, and new caches and databases need to be configured. Then, the YouNike app wallet data tables need to be transferred to the database of the newly created separate wallet system. Finally, a mapping relationship between the YouNike app and the separate wallet system needs to be established, and a new interface path corresponding to the YouNike app needs to be generated based on this mapping relationship. In this way, the YouNike app completes its transformation from a public service type to a separate service type.

[0072] 304. Establish the mapping relationship between the application and the target wallet system, and generate the corresponding interface path for the application based on the mapping relationship.

[0073] After determining the target wallet system for the application, it is necessary to establish a mapping relationship between the application and the target wallet system, enabling the application to call the specified target wallet system to host the wallet. Specifically, it is necessary to establish an interface path for the application and use this interface path to implement the call to the target wallet system.

[0074] Specifically, the application's AppKey is used to generate the corresponding API path. When the application calls the target wallet system, it uses the AppKey of the requesting application to invoke the target wallet system. When an application calls the wallet service, the API path must include the AppKey name, following the rule: / prefix / {AppKey} / detailed API URL. The wallet service API will map and call the specific wallet system based on the path " / prefix / {AppKey}".

[0075] For example, the NetEase Cloud Music app is an independent wallet service, while the YouNiKe app and daHuaXiYou app are public wallet services. Therefore, it's necessary to use the yunYinYueApp mapping service to connect to NetEase Cloud Music's independent wallet system, and the youNiKeApp and daHuaXiYouApp mapping services to connect to the public wallet systems.

[0076] For example, the path for creating a wallet in the Cloud Music app could be:

[0077] / openApi / wallet / yunYinYueApp / createWallet

[0078] The path to create a wallet in the Younike APP can be:

[0079] / openApi / wallet / youNiKeApp / createWallet

[0080] For example, the wallet query interface path can be in the following form:

[0081] / openApi / wallet / {AppKey} / queryWallet

[0082] The path to the wallet signing interface can be:

[0083] / openApi / wallet / {AppKey} / signRawData

[0084] 305. Continuously create wallet accounts using the target wallet system, generate the private key corresponding to the wallet account, and determine the blockchain address corresponding to the wallet account.

[0085] After specifying the target wallet system for the application, the wallet systems in the wallet hosting service system, including independent wallet systems and public wallet systems, continuously and asynchronously create wallet accounts in multiple threads, generate the private keys corresponding to the wallet accounts, and determine the corresponding blockchain addresses for the wallet accounts.

[0086] For example, in a wallet hosting service system, the wallet system continuously creates wallet accounts asynchronously through multiple threads, generating the corresponding private key and mnemonic phrase. In other words, the wallet system pre-creates wallet accounts, and when a user sends a wallet creation request, it directly assigns the pre-created wallet account to the user. This saves users time creating wallets and improves response efficiency.

[0087] For example, the Cloud Music Wallet service (wallet-yunYinYueApp) can support four wallet systems at its core, each with two threads continuously creating wallet accounts, private keys, mnemonic phrases, and corresponding blockchain addresses, while caching 1 million wallet account data. The public wallet service (wallet-common) also uses four wallet systems at its core, each with two threads continuously creating wallet accounts, private keys, mnemonic phrases, and corresponding blockchain addresses, while caching 1 million wallet account data.

[0088] 306. Store the correspondence between wallet account, the private key corresponding to the wallet account, and the blockchain address corresponding to the wallet account in the cache.

[0089] Specifically, the mapping between the wallet account, the corresponding private key, and the corresponding blockchain address created by the target wallet system in step 305 is stored in the target wallet system's cache. That is, the cache stores the created wallet accounts. When a user's wallet creation request is received, a wallet account is directly retrieved from the cache and then associated with the user. For example, the wallet account, including the wallet's private key, mnemonic phrase, and corresponding blockchain address, is encrypted using AES and stored in the target wallet system's cache; the encryption key is stored by the wallet service. Other encryption methods can also be used; there are no restrictions here.

[0090] The wallet hosting method provided in this application first obtains the attribute information of the application registering the wallet service. This attribute information is used to determine the application's hosting requirements. It then determines whether the application's wallet data should be hosted through an independent wallet system or a non-independent wallet system. Next, a target wallet system, along with its corresponding target cache and database, is selected. Finally, a mapping relationship between the application and the target wallet system is established, generating an interface path. This allows the application to call the target wallet system through the interface path. The target wallet system asynchronously and continuously establishes a cached mapping between the wallet account, its corresponding private key, and its corresponding blockchain address. This allows the target wallet system to directly assign the cached wallet account to the application's user when it receives a wallet creation request from the application, thus saving the user's wallet creation time.

[0091] The wallet hosting method provided in this application utilizes a single wallet hosting service system to offer wallet hosting services to multiple applications with different needs. This system provides a unified wallet service interface externally, while internally it creates independent wallet systems and a public wallet system. When an application calls the wallet service interface to host wallet data, the wallet hosting service type for the application is first determined based on the application's attribute information, and then either an independent wallet system or a public wallet system is selected for hosting. Simultaneously, each wallet system has its own target cache and database. This ensures that wallet data from different applications is stored in the databases or caches of different wallet systems, achieving isolation between wallet data and improving the security of data such as private keys. Furthermore, each wallet system continuously and asynchronously creates wallet accounts, generates private keys for wallet accounts, and assigns blockchain addresses. The created wallet accounts are then stored in the cache. Thus, when a user of an application requests to create a wallet, the cached wallet account can be directly provided to the user without needing to synchronously create a wallet account upon receiving a request. This shortens user waiting time and improves wallet creation performance.

[0092] Based on the above embodiments, after configuring the target wallet system for the application, the process of creating a wallet account for the user within the application is described below. The wallet hosting service system includes a wallet creation interface, which users can call through the application to create their wallet accounts using the target wallet system corresponding to the application. Figure 4 This is a flowchart illustrating a method for creating a wallet account, as provided in an embodiment of this application. Figure 4 As shown, after step 306 in the above embodiment, the wallet account creation process includes the following steps:

[0093] 401. Receive wallet creation requests sent by the application through the wallet creation interface.

[0094] First, when a user needs to create a wallet account, they need to call the wallet creation interface through the application. The wallet hosting service system receives the wallet creation request sent by the application through the wallet creation interface. This wallet creation request needs to include the application's identification information and the user's identity information for that application.

[0095] The application's identification information includes the application's AppKey, and the user's identity information may include the user's ID (appUserNumber) and detailed identity information such as phone number, username, etc., without any specific limitations.

[0096] 402. Sign the contents of the wallet creation request.

[0097] Next, the application needs to sign the request content using the application's private key, AppSecret, to prevent the content from being tampered with.

[0098] Specifically, the content in the wallet creation request is signed using the application's AppSecret to obtain the signature (sign), which is then placed in the HTTP request header. For example, when signing the content in the wallet creation request using the application's AppSecret, the signing algorithm can be HmacSHA256, MD5, or other signing methods; no restrictions are placed here.

[0099] 403. Send the signed wallet creation request to the target wallet system according to the wallet creation interface path corresponding to the application.

[0100] Next, the application calls the corresponding wallet creation interface and sends the application's wallet creation request to the target wallet system corresponding to the application according to the wallet creation interface path described in the above embodiment.

[0101] For example: the wallet creation path in yunYinYueApp is:

[0102] / openApi / wallet / yunYinYueApp / createWallet.

[0103] 404. Verify the application's validity through the target wallet service system. If the application is verified as valid, proceed to step 405. If the application is verified as invalid, end the wallet creation process.

[0104] After receiving a wallet creation request from an application, the target wallet service system needs to verify the validity of the application's wallet creation request. Only after confirming that the wallet creation request is valid can the application call the current target wallet service system for subsequent processing.

[0105] When verifying validity, the independent wallet service system and the public wallet service system within the target wallet service system employ different verification modes. The independent wallet service system uses an App whitelist mode to verify applications, while the public wallet service uses an App blacklist mode. The whitelist mode means that only applications on the whitelist can pass verification; any other applications not on the whitelist will fail. The blacklist mode adds applications from the independent wallet service system to a blacklist; applications on the blacklist will fail verification, while other applications not on the blacklist will pass.

[0106] For example, if the Cloud Music (yunYinYueApp) application has its own independent wallet system, and the Cloud Music (yunYinYueApp) wallet service verification is set to whitelist mode, the Cloud Music wallet service system will only accept wallet creation requests with the AppKey "Cloud Music (yunYinYueApp)". Conversely, if the public wallet system's wallet service verification is set to blacklist mode, and the independent wallet system's application "Cloud Music (yunYinYueApp)" is added to the blacklist, the public wallet system will not accept wallet creation requests with the AppKey "(yunYinYueApp)".

[0107] 405. Verify the application signature. If the signature is valid, proceed to step 406. If the signature is invalid, end the wallet creation process.

[0108] After verifying the validity of the wallet creation request, it is necessary to further verify the application signature carried in the request. This is to prevent the wallet creation request from being forged. The specific verification process is as follows:

[0109] First, the App's private key, AppSecret, needs to be obtained from the application management system within the wallet escrow service system. The application management system stores the mapping between application identification information and application private keys. Therefore, the application's private key can be determined by querying the application management system based on the application identification information in the wallet creation request.

[0110] Then, a standard signature for the application is generated based on the application's private key, AppSecret. Finally, the standard signature and the application signature are compared. If the standard signature and the application signature match, the application signature is considered valid. Only after this is confirmed will the wallet creation request be responded to. If they do not match, it indicates that the wallet creation request is forged, and the wallet creation process must be terminated.

[0111] 406. Respond to the wallet creation request and retrieve the target wallet account from the target wallet account cache through the target wallet system.

[0112] After receiving the wallet creation request from the application, the target wallet system does not need to generate a wallet account synchronously. Instead, it retrieves an already created wallet account from the cache. That is, it obtains a target wallet account, the private key corresponding to the target wallet account, and the blockchain address corresponding to the target wallet account through the cache.

[0113] 407. Associate the target wallet account with the application user.

[0114] Then, the target wallet system associates the target wallet account with the application user. That is, it assigns the target wallet account to the application user. The target wallet system establishes a mapping between the target wallet account, the corresponding private key, the corresponding blockchain address, and the user's identity information, and stores this mapping in the target wallet system's database, completing the wallet creation process.

[0115] If the target wallet system is a public wallet system, then the target wallet table corresponding to the application needs to be found in the target database of the public wallet system. Then, the target wallet table stores the correspondence between the target wallet account, the private key corresponding to the target wallet account, the blockchain address corresponding to the target wallet account, and the user identity information.

[0116] After the user's wallet is created, the target wallet account needs to be deleted from the target wallet system's cache. Furthermore, feedback information needs to be sent to the application, including the target wallet account assigned to the user, the corresponding blockchain address, and the wallet's public key. The wallet's public key is generated from the wallet's private key; returning the public key to the user prevents private key leakage.

[0117] The wallet hosting method provided in this application embodiment allows the application user to send a wallet creation request to the target wallet system corresponding to the application according to the interface path of the application. Then, the target wallet system retrieves the target wallet account from the target cached wallet account and associates the target wallet account with the application user.

[0118] As can be seen, the wallet hosting service system continuously and asynchronously creates wallet accounts. When a user of the application requests to create a wallet, the created wallet can be directly associated with the user, without needing to synchronously create the wallet and generate a private key, resulting in higher wallet creation performance. Furthermore, when the wallet hosting receives a wallet creation request, it needs to verify the validity of the request and verify the application signature before responding to the wallet creation request, thus ensuring the security of wallet data.

[0119] Based on the wallet creation process shown in the above embodiments, this application also provides a wallet account query method based on a wallet hosting service system. The wallet hosting service system also provides a wallet query interface for users to query wallet information. Figure 5 This is a flowchart illustrating the wallet account query method provided in an embodiment of this application. Figure 5 As shown, the query process includes the following steps:

[0120] 501. Receive wallet query requests through the wallet query interface.

[0121] When a user needs to query their wallet account, they need to call the wallet query interface to send a wallet query request. The wallet query request includes the application's identification information and the user's identity information for that application.

[0122] The application's identification information includes the application's AppKey, and the user's identity information includes the user's ID (appUserNumber) and detailed identity information such as phone number and username.

[0123] Understandably, applications also need to use their application private key, AppSecret, to sign the content of wallet query requests to prevent the content from being tampered with.

[0124] Specifically, the content in the wallet query request is signed using the application's AppSecret to obtain the signature (sign), which is then placed in the HTTP request header. For example, when signing the content in the wallet creation request using the application's AppSecret, the signing algorithm can be HmacSHA256, MD5, or other signing methods; no restrictions are placed here.

[0125] 502. Determine the query interface path corresponding to the application based on the application's identification information.

[0126] Similarly, the application's AppKey is needed to determine the corresponding query interface path. Only then can the wallet query request be sent to the corresponding wallet system.

[0127] 503. Send the wallet query request to the target wallet system according to the interface path corresponding to the application.

[0128] The application's wallet query request is sent to the target wallet system corresponding to the application based on the interface path of the application.

[0129] For example, the format of the wallet query interface path can be:

[0130] / openApi / wallet / {AppKey} / queryWallet

[0131] 504. In response to a wallet query request, the system queries the target database based on the user's identity information to obtain the blockchain address and public key of the target wallet account corresponding to the application user.

[0132] Understandably, when the target wallet system receives a wallet query request, it also needs to verify the validity of the application's wallet query request and the legality of the application signature carried in the request. Only after successful verification will it respond to the wallet query request.

[0133] First, upon receiving a wallet query request from an application, the target wallet service system verifies the application's validity. During this verification, the independent wallet service system and the public wallet service system within the target wallet service system employ different modes. Similarly, the independent wallet service system uses an App whitelist mode for verification, while the public wallet service uses an App blacklist mode. In the whitelist mode, only applications that are specifically selected can pass verification; any application not on the whitelist will fail. In the blacklist mode, applications from the independent wallet service system are added to a blacklist; applications on the blacklist will fail verification, while applications not on the blacklist can pass.

[0134] After confirming the application's validity, the legitimacy of the application signature carried in the wallet query request is verified. First, the private key AppSecret corresponding to the AppKey carried in the wallet query request is retrieved from the application management system. Then, a standard signature for the application is generated based on the application's private key AppSecret. Next, if the standard signature matches the application signature, the application signature is deemed valid. The wallet query request is then responded to. If they do not match, the wallet query process must be stopped.

[0135] The query process involves the target wallet system querying the target database based on the application user's identity information to obtain the blockchain address and public key of the target wallet account corresponding to the application user. The public key is generated from the private key.

[0136] 505. Send the blockchain address and public key of the target wallet account corresponding to the application user to the application through the wallet query interface.

[0137] The application user sends the blockchain address and public key of the target wallet account corresponding to the application user to the application via the wallet query interface, and the application user completes the wallet query.

[0138] The wallet query method provided in this application embodiment allows the following steps: When an application user requests to query a wallet, the query interface path corresponding to the application can be determined based on the application's identification information. The wallet query request is then sent to the target wallet system. When the wallet system receives the wallet query request, it verifies the validity of the creation request and the application signature. If the creation request is found to be valid and the application signature is legal, the system responds to the wallet creation request. The target wallet system then queries the target database based on the application user's user identity information to obtain the blockchain address and public key of the target wallet account corresponding to the application user, thus ensuring the security of the wallet data.

[0139] For example, the wallet escrow service system also provides a general signature interface. The application inputs raw data (signing data, transactions to be signed, etc.), and after verifying its legitimacy, the wallet escrow service system retrieves the corresponding user's wallet private key from the corresponding wallet system's database, signs the raw data, and returns it. This ensures that the user's wallet private key is never exposed.

[0140] Figure 6 This is a schematic diagram of a wallet custody device provided in an embodiment of this application. The following is in conjunction with... Figure 6 The wallet custody device provided in this embodiment will be described in detail. The embodiments described below are used to explain the technical solutions of this application and are not intended to limit actual use.

[0141] The wallet custody device includes:

[0142] The acquisition unit 601 is used to acquire attribute information of the application that registers the wallet service.

[0143] The determining unit 602 is used to determine the wallet hosting service type of the application based on the application's attribute information.

[0144] The determining unit 602 is also used to determine the target wallet system of the application in the wallet hosting service system according to the wallet hosting service type of the application, and to determine the target cache corresponding to the target wallet system.

[0145] Establishment unit 603 is used to establish the mapping relationship between the application and the target wallet system.

[0146] Generation unit 604 is used to generate the interface path corresponding to the application based on the mapping relationship. The interface path is used by the application to call the target wallet system.

[0147] Unit 603 is also used to continuously create wallet accounts using the target wallet system.

[0148] The generation unit 604 is also used to generate the private key corresponding to the wallet account.

[0149] The determining unit 602 is also used to determine the blockchain address corresponding to the wallet account.

[0150] Storage unit 605 is used to store in the cache the correspondence between wallet account, the private key corresponding to the wallet account, and the blockchain address corresponding to the wallet account.

[0151] In one optional implementation, the application's attribute information includes the application's identification information.

[0152] Unit 602 is specifically used to, if the application's wallet hosting service type is an independent service type, create a new target wallet system for the application in the wallet hosting service system based on the application's identification information. The target wallet system is an independent wallet system. It also determines the target cache corresponding to the target wallet system, specifically for configuring the target cache for the target wallet system.

[0153] In an optional implementation, the determining unit 602 is specifically configured to determine the target wallet system of the application as a public wallet system if the wallet hosting service type of the application is an independent public service type. Here, the public wallet system corresponds to multiple applications.

[0154] In an optional implementation, the wallet hosting service system further includes a wallet creation interface, and the wallet hosting device further includes a receiving unit 606, a sending unit 607, and a processing unit 608.

[0155] The receiving unit 606 is used to receive a wallet creation request sent by the application through the wallet creation interface. The wallet creation request includes the application's identification information and the user's identity information.

[0156] Sending unit 607 is used to send a wallet creation request to the target wallet system according to the interface path corresponding to the application.

[0157] The acquisition unit 601 is also used to respond to a wallet creation request and obtain the target wallet account from the wallet account in the target cache through the target wallet system.

[0158] Processing unit 608 associates the target wallet account with the application user.

[0159] In one alternative implementation, the wallet custody service system also includes a database.

[0160] The determining unit 602 is also used to determine the target database corresponding to the target wallet system.

[0161] Storage unit 605 is also used to store the correspondence between the target wallet account, the private key corresponding to the target wallet account, the blockchain address corresponding to the target wallet account, and the user identity information in the target database.

[0162] Processing unit 608 is also used to delete the target wallet account in the cache.

[0163] In one alternative implementation, the wallet creation request carries an application signature.

[0164] The determining unit 602 is also used to determine the validity of the wallet creation request based on the application's identification information.

[0165] Processing unit 608 is also configured to verify the application signature when it determines that the wallet creation request is valid. When the application signature is determined to be valid, it responds to the wallet creation request.

[0166] In an alternative implementation, the application's private key is included in the program's attribute information.

[0167] Storage unit 605 is also used to store the correspondence between the application's identification information and the application's private key.

[0168] The determining unit 602 is also used to determine the application's private key based on the application's identification information through the application management system.

[0169] The generation unit 604 is also used to generate a standard signature for the application based on the application's private key.

[0170] The processing unit 608 is also used to determine that the application signature is valid when the standard signature matches the application signature.

[0171] In one optional implementation,

[0172] Storage unit 605 is specifically used to create a target wallet table corresponding to the application in the target database corresponding to the public wallet system when the target wallet system is a public wallet system. The target wallet table stores the mapping relationship between the target wallet account, the private key corresponding to the target wallet account, the blockchain address corresponding to the target wallet account, and the user's identity information.

[0173] In an optional implementation, the wallet custody service system also includes a wallet query interface.

[0174] The receiving unit 606 is also configured to receive wallet query requests via a wallet query interface. The wallet query request includes the application's identification information and the application user's identity information.

[0175] The determining unit 602 is also used to determine the interface path corresponding to the application based on the application's identification information.

[0176] The sending unit 607 is also used to send a wallet query request to the target wallet system according to the interface path corresponding to the application.

[0177] The processing unit 608 is also used to respond to wallet query requests and query the target database through the target wallet system based on the user's identity information of the application user.

[0178] The acquisition unit 601 is also used to obtain the blockchain address and public key of the target wallet account corresponding to the application user. The public key and private key of the target wallet account are associated.

[0179] The sending unit 607 is also used to send the blockchain address of the target wallet account corresponding to the application user and the public key of the target wallet account to the application through the wallet query interface.

[0180] In one alternative implementation, the wallet query request carries an application signature.

[0181] The determining unit 602 is also used to determine the validity of the wallet query request based on the identification information of the application.

[0182] The processing unit 608 is also configured to verify the application signature when it determines that the wallet query request is valid. When the application signature is determined to be valid, it responds to the wallet query request.

[0183] The wallet hosting device provided in this application enables a unified wallet service interface to be provided externally by the wallet hosting service system. Internally, it provides different wallet hosting service types to applications based on their attribute information, supporting arbitrary wallet hosting. Each wallet system has its own target cache and database, achieving isolation between wallet data and enhancing wallet data security. Furthermore, because the wallet system continuously and asynchronously creates wallets and stores the generated private keys in the cache, when an application user requests to create a wallet, the wallet already created in the target wallet system can be directly associated with the application user, eliminating the need for synchronous wallet creation and private key generation, resulting in higher wallet creation performance.

[0184] It should be noted that the information interaction and execution process between the various modules / units in the device are different from those in this application. Figures 1 to 5 The various method embodiments are based on the same concept, and the details can be found in the descriptions of the method embodiments shown above in this application, which will not be repeated here.

[0185] The following describes an electronic device provided by an embodiment of this application. Please refer to [link / reference]. Figure 7 , Figure 7This is a schematic diagram of an electronic device provided in an embodiment of this application. The electronic device 800 may be equipped with... Figure 6 The wallet escrow device described in the corresponding embodiment is used to implement Figures 1 to 5 The functions correspond to those in the embodiments. Specifically, the electronic device 800 includes: a receiver 801, a transmitter 802, a processor 803, and a memory 804 (wherein the electronic device 800 may have one or more processors 803). Figure 7 (Taking a processor as an example), the processor 803 may include an application processor 8031 ​​and a communication processor 8032. In some embodiments of this application, the receiver 801, transmitter 802, processor 803, and memory 804 may be connected via a bus or other means.

[0186] Memory 804 may include read-only memory and random access memory, and provides instructions and data to processor 803. A portion of memory 804 may also include non-volatile random access memory (NVRAM). Memory 804 stores processor and operation instructions, executable modules, or data structures, or subsets thereof, or extended sets thereof, wherein the operation instructions may include various operation instructions for implementing various operations.

[0187] The processor 803 controls the operation of the execution device. In specific applications, the various components of the execution device are coupled together through a bus system, which may include not only the data bus but also power buses, control buses, and status signal buses. However, for clarity, all buses in the diagram are referred to as the bus system.

[0188] The methods disclosed in the embodiments of this application can be applied to or implemented by processor 803. Processor 803 can be an integrated circuit chip with signal processing capabilities. During implementation, each step of the above methods can be completed by integrated logic circuits in the hardware of processor 803 or by instructions in software form. Processor 803 can be a general-purpose processor, a digital signal processor (DSP), a microprocessor, or a microcontroller, and may further include application-specific integrated circuits (ASICs), field-programmable gate arrays (FPGAs), or other programmable logic devices, discrete gate or transistor logic devices, or discrete hardware components. Processor 803 can implement or execute the methods, steps, and logic block diagrams disclosed in the embodiments of this application. A general-purpose processor can be a microprocessor or any conventional processor. The steps of the methods disclosed in the embodiments of this application can be directly implemented by a hardware decoding processor, or implemented by a combination of hardware and software modules in the decoding processor. The software module can reside in a mature storage medium in the field, such as random access memory, flash memory, read-only memory, programmable read-only memory, electrically erasable programmable memory, or registers. This storage medium is located in memory 804, and processor 803 reads the information from memory 804 and, in conjunction with its hardware, completes the steps of the above method.

[0189] Receiver 801 can be used to receive input digital or character information, and to generate signal inputs related to the settings and function control of the execution device. Transmitter 802 can be used to output digital or character information through the first interface; transmitter 802 can also be used to send instructions to the disk group through the first interface to modify the data in the disk group; transmitter 802 may also include a display device such as a display screen.

[0190] In this embodiment of the application application, the application processor 8031 ​​in the processor 803 is used to execute... Figures 1 to 5 The wallet escrow method in the corresponding embodiment. It should be noted that the specific manner in which the application processor 8031 ​​executes each step differs from that in this application. Figures 1 to 5 The various method embodiments are based on the same concept, and the technical effects they bring are the same as those in this application. Figures 1 to 5 The corresponding method embodiments are the same, and for details, please refer to the description in the method embodiments shown above in this application, which will not be repeated here.

[0191] This application provides a computer-readable storage medium, which includes computer instructions. When executed by a processor, the computer instructions are used to implement any of the wallet custody methods described in this application.

[0192] In a typical configuration, a computing device includes one or more processors (CPU), input / output interfaces, network interfaces, and memory.

[0193] Memory may include non-persistent storage in computer-readable media, such as random access memory (RAM) and / or non-volatile memory, such as read-only memory (ROM) or flash RAM. Memory is an example of computer-readable media.

[0194] Computer-readable media, as defined herein, includes both permanent and non-permanent, removable and non-removable media, which can store information using any method or technology. Information can be computer-readable instructions, data structures, program modules, or other data. Examples of computer storage media include, but are not limited to, phase-change memory (PRAM), static random access memory (SRAM), dynamic random access memory (DRAM), other types of random access memory (RAM), read-only memory (ROM), electrically erasable programmable read-only memory (EEPROM), flash memory or other memory technologies, CD-ROM, digital versatile optical disc (DVD) or other optical storage, magnetic tape, magnetic magnetic disk storage or other magnetic storage devices, or any other non-transferable medium that can be used to store information accessible by a computing device. As defined herein, computer-readable media does not include non-transitory computer-readable media, such as modulated data signals and carrier waves.

[0195] Those skilled in the art will understand that embodiments of this application can be provided as methods, systems, or computer program products. Therefore, this application can take the form of a completely hardware embodiment, a completely software embodiment, or an embodiment combining software and hardware aspects. Furthermore, this application can take the form of a computer program product embodied on one or more computer-usable storage media (including, but not limited to, disk storage, CD-ROM, optical storage, etc.) containing computer-usable program code.

[0196] Although this application discloses preferred embodiments as described above, it is not intended to limit this application. Any person skilled in the art can make possible changes and modifications without departing from the spirit and scope of this application. Therefore, the scope of protection of this application should be determined by the scope defined in the claims of this application.

Claims

1. A wallet escrow method, characterized in that, The wallet custody method is applied to a wallet custody service system, which includes independent wallet systems and public wallet systems. The method includes: Obtain the attribute information of the application that registered the wallet service; Based on the application's attribute information, determine the wallet hosting service type of the application; Based on the wallet hosting service type of the application, determine the target wallet system of the application in the wallet hosting service system; and determine the target cache corresponding to the target wallet system; Establish a mapping relationship between the application and the target wallet system, and generate an interface path corresponding to the application based on the mapping relationship; the interface path is used by the application to call the target wallet system. Using the target wallet system, wallet accounts are continuously created, and private keys corresponding to the wallet accounts are generated; Determine the blockchain address corresponding to the wallet account; The cache stores the correspondence between the wallet account, the private key corresponding to the wallet account, and the blockchain address corresponding to the wallet account. The wallet hosting service system also includes a wallet creation interface, and the method further includes: The wallet creation interface receives a wallet creation request sent by the application; the wallet creation request includes the application's identification information and the application user's user identity information. The wallet creation request is sent to the target wallet system according to the interface path corresponding to the application. In response to the wallet creation request, the target wallet account is obtained from the target cache wallet account through the target wallet system; Associate the target wallet account with the application user.

2. The method according to claim 1, characterized in that, The application's attribute information includes the application's identification information; The step of determining the target wallet system in the application within the wallet custody service system based on the wallet custody service type of the application includes: If the wallet hosting service type of the application is an independent service type, then a new target wallet system is created for the application in the wallet hosting service system according to the application's identification information; the target wallet system is an independent wallet system. Determining the target cache corresponding to the target wallet system includes: Configure the target cache for the target wallet system.

3. The method according to claim 2, characterized in that, The step of determining the target wallet system in the application within the wallet custody service system based on the wallet custody service type of the application includes: If the wallet hosting service type of the application is a public service type, then the target wallet system of the application is determined to be a public wallet system; wherein, the public wallet system corresponds to multiple applications.

4. The method according to claim 1, characterized in that, The wallet custody service system also includes a database; the method further includes: Determine the target database corresponding to the target wallet system; The target database stores the correspondence between the target wallet account, the private key corresponding to the target wallet account, the blockchain address corresponding to the target wallet account, and the user identity information. And delete the target wallet account from the cache.

5. The method according to claim 4, characterized in that, The wallet creation request carries an application signature; Before responding to the wallet creation request, the method further includes: The validity of the wallet creation request is determined based on the application's identification information; Upon confirming the validity of the wallet creation request, verify the application signature; Once the application signature is determined to be valid, the wallet creation request is responded to.

6. The method according to claim 5, characterized in that, The wallet hosting service system also includes an application management system; the application's attribute information includes the application's private key; The application management system is used to store the correspondence between the application's identification information and the application's private key; The verification of the application signature includes: The application management system determines the application's private key based on the application's identification information. Generate a standard signature for the application based on the application's private key; When the standard signature matches the application signature, the application signature is determined to be valid.

7. The method according to claim 4, characterized in that, The process of storing the correspondence between the target wallet account, the private key corresponding to the target wallet account, the blockchain address corresponding to the target wallet account, and the user identity information in the target database includes: When the target wallet system is the public wallet system, a target wallet table corresponding to the application is created in the target database corresponding to the public wallet system. The target wallet table stores the correspondence between the target wallet account, the private key corresponding to the target wallet account, the blockchain address corresponding to the target wallet account, and the user identity information.

8. The method according to any one of claims 1 to 7, characterized in that, The wallet custody service system also includes a wallet query interface, and the method further includes: The wallet query request is received through the wallet query interface; the wallet query request includes the application's identification information and the user's identity information. The interface path corresponding to the application is determined based on the application's identification information; The wallet query request is sent to the target wallet system according to the interface path corresponding to the application. In response to the wallet query request, the target wallet system queries the target database based on the user identity information of the application user to obtain the blockchain address of the target wallet account corresponding to the application user and the public key of the target wallet account; the public key of the target wallet account and the private key of the target wallet account are associated. The application sends the blockchain address of the target wallet account corresponding to the user of the application and the public key of the target wallet account to the application through the wallet query interface.

9. The method according to claim 8, characterized in that, The wallet query request carries the application signature; Before responding to the wallet query request, the method further includes: The validity of the wallet query request is determined based on the application's identification information; Upon determining that the wallet query request is valid, verify the application signature; When the application signature is determined to be valid, the wallet query request is responded to.

10. A wallet custody device, characterized in that, The wallet custody device is equipped with a wallet custody service system, which includes an independent wallet system and a public wallet system. The wallet custody device includes: The acquisition unit is used to obtain attribute information of the application that registers the wallet service; The determining unit is used to determine the wallet hosting service type of the application based on the application's attribute information; The determining unit is further configured to determine the target wallet system of the application in the wallet hosting service system according to the wallet hosting service type of the application; and determine the target cache corresponding to the target wallet system; A setup unit is used to establish a mapping relationship between the application and the target wallet system; A generation unit is used to generate an interface path corresponding to the application based on the mapping relationship; the interface path is used by the application to call the target wallet system. The establishment unit is also used to continuously establish wallet accounts using the target wallet system; The generation unit is also used to generate the private key corresponding to the wallet account; The determining unit is further configured to determine the blockchain address corresponding to the wallet account; A storage unit is used to store in the cache the correspondence between the wallet account, the private key corresponding to the wallet account, and the blockchain address corresponding to the wallet account; The wallet hosting service system also includes a wallet creation interface, and the device is further used for: The wallet creation interface receives a wallet creation request sent by the application; the wallet creation request includes the application's identification information and the application user's user identity information. The wallet creation request is sent to the target wallet system according to the interface path corresponding to the application. In response to the wallet creation request, the target wallet account is obtained from the target cache wallet account through the target wallet system; Associate the target wallet account with the application user.

11. An electronic device, characterized in that, The electronic device includes: a memory and a processor; the memory and the processor are coupled. The memory is used to store one or more computer instructions; The processor is used to execute the one or more computer instructions to implement the wallet custody method as described in any one of claims 1-9.

12. A computer-readable storage medium, characterized in that, The system contains a data processing program that is run by a processor to perform the wallet custody method as described in any one of claims 1-9.

Images