A decentralized account management method

Abstract

The application discloses a kind of decentralized chain on account management method, by providing a digital encryption client account for user, let digital encryption client realize the user experience of approaching internet product, utilize such as mobile phone number, email and the socialization platform of traditional internet familiar to user with account organic binding, utilize this kind of social authentication ID, realize the private key of management and digital client account decoupling to some extent, reduce the threshold of user using blockchain;Solve the problem that there is almost no possibility to obtain the digital assets controlled by original private key after losing private key in traditional digital encryption client.

Description

Technical Field

[0001] This invention relates to the fields of digital encryption and blockchain technology, and in particular to a decentralized on-chain account management method. Background Technology

[0002] Digital encryption clients primarily function as software for managing user private keys. They help users generate private keys, derive public keys, and even generate or register on-chain accounts, interacting with specific blockchains on behalf of the user. The core function of a digital encryption client lies in the management and maintenance of private keys. If a user loses or leaks their private key, their assets are at risk. While a new public key and address can be obtained by replacing the private key, assets bound to the previous private key must be transferred or discarded. Furthermore, all activity records and reputation accumulated on the blockchain associated with the user's address will be lost.

[0003] Because the private keys used in blockchain technology are quite long, typically 256 bits or more, and usually have sufficient randomness, they are difficult for the human brain to remember accurately for a long time. Furthermore, once lost, they are irretrievable. Currently, they are primarily stored encrypted using client software (also known as wallets), and the use of private keys is also done through digitally encrypted clients. However, wallets only simplify the process of signing transactions using private keys; they do not solve the problem of lost private keys. When a user forgets their wallet password, they cannot use the private key because it is also encrypted; and when the wallet file is corrupted or accidentally deleted, the private key is completely lost.

[0004] Currently, most blockchain account retrieval methods in the industry are based on centralized verification schemes, which usually have certain centralized risks and security vulnerabilities. Summary of the Invention

[0005] The purpose of this invention is to utilize blockchain smart contract technology and introduce social factors such as social authentication IDs to enable users to manage and control smart contract accounts.

[0006] To achieve the above objectives, the present invention provides a decentralized on-chain account management method, characterized by comprising the following steps: 1. Deploying smart contracts on a blockchain, wherein the smart contracts have the functions of creating accounts representing user identities, registering user identity verification information, maintaining smart contract accounts, and also have the functions of user asset management and reputation value maintenance; 2. The user enters and confirms a local login password LPwd, and then selects a username, denoted as ChainName, on the local computer through the digital encryption client. A private key PrvKey is randomly generated for this username. The generated private key PrvKey is symmetrically encrypted using the password LPwd, and the ciphertext is stored locally on the digital encryption client. 3. Derive the public key, denoted as actPubKey, from the private key PrvKey. The user then inputs and confirms a random secret, rndSecret, used to protect data stored in the on-chain smart contract. The social authentication ID, account name (ChainName), and current timestamp (curTime) are hashed to obtain a hash value, which is then submitted to the smart contract to confirm the availability of the account name (ChainName). The following information is stored on-chain: ① The account name ChainName is unique within the smart contract. As the account of the digital encryption client, it is successfully registered and registered within the smart contract. ② The public key actPubKey of the account name ChainName serves as the basis for controlling this account by possessing the private key PrvKey stored in the encrypted client. ③ The hash value is obtained by hashing the social verification ID, account name ChainName, and current timestamp curTime; 4. When a user logs into the client with the account name ChainName, enters the local login password LPwd, decrypts the locally stored private key ciphertext to obtain the private key plaintext PrvKey`, and derives the public key actPubKey`. If the actPubKey stored under the account name ChainName in the smart contract is the same as actPubKey`, then this account is allowed to log in to the digital encryption client.

[0007] Furthermore, the social authentication ID is held by the user and can uniquely identify the user, and is one or more combinations of mobile phone number, email, and login account of centralized platform.

[0008] Furthermore, the account-related information stored on the chain also includes: (1) A random secret rndSecret, wherein the random secret rndSecret is a sequence of more than a certain number of characters containing uppercase and lowercase characters and numbers, which is either input by the user or generated by the client program; (2) The public key derived from the private key used to manage the account is denoted as actPubKey; (3) actHashKey is obtained by hashing the user's social authentication ID + random secret rndSecret to get hash1, and then using hash1 + account name ChainName to perform a second hash operation; (4) actAdminLogTime, a field used to record the time when the account last performed an operation involving resetting social authentication ID control information; (5) LogTimeHash1, the hash value obtained by hashing actAdminLogTime and the random secret rndSecret; (6) LogTimeHash, which is calculated by adding the hash value of TimeHash1 + account name ChainName; (7) In the ChainName storage area on the blockchain, use the attribute actHashKey to store actHashKey and use LogTimeKey to store LogTimeHash.

[0009] Furthermore, if the private key PrvKey corresponding to the attribute actPubKey under the account name ChainName is lost and has not been backed up using a mnemonic phrase, the user can regain control of the account through social authentication ID, specifically through the following steps: (1) Confirm that the social authentication ID belongs to the current user, and send a temporary verification code with an expiration time limit to the user. The user enters the temporary verification code to verify that the social authentication ID belongs to the current user. (2) A new private key newPriKey is pre-generated to replace the old private key and reset the smart contract account, and a new public key newPK is derived. At the same time, the new public key newPK is stored locally on the encrypted client using the local login password LPwd in symmetric encryption. The LPwd is then replaced. (3) The user can input a new random secret newRndSecret that meets the length and complexity requirements. newRndSecret can also be the old random secret rndSecret. Input the old random secret rndSecret, read the value of actAdminLogTime under the account name ChainName as lastTime, hash the value of lastTime + random secret rndSecret as timeLogHash1, hash the value of timeLogHash1 + ChainName as LogTimeKey`, read whether LogTimeKey under ChainName is equal to LogTimeKey`. If they are equal, continue the comparison; otherwise, exit the current operation. (4) Record the hash value after hashing the social authentication ID + random secret rndSecret as hash1, and the hash value after hashing hash1 + ChainName again as actHashKey`. Match the account name ChainName on the query chain. If the query finds that its actHashKey is consistent with actHashKey`, it indicates that the current user is the real owner of the account ChainName. (5) Calculate the hash value of the social authentication ID + new random secret newRndSecret as newHash1, and then use the hash operation of newHash1 + account name ChainName to obtain the new hash value newActHashKey; (6) Let the current timestamp be curTime. Use the current timestamp curTime + the new random secret newRndSecret to perform a hash operation to obtain the hash value newHash1. Then, calculate the hash value of newHash1 + ChainName to be newTimeLogHash. (7) Submit hash1, timeLogHash1, ChainName, newPK, newActHashKey, and curTime to the smart contract; (8) The smart contract execution compares whether the hash value of hash1+ChainName is consistent with the actHashKey value of ChainName. If they are inconsistent, the operation is terminated. If they are consistent, the hash value of timeLogHash1+ChainName is compared with the LogTimeKey value of ChainName. If they are inconsistent, the execution is terminated. If both comparisons are consistent, it can be confirmed that the user of the current social authentication ID has submitted a verified proof. (9) The smart contract uses the smart contract account maintenance function to update the actHashKey of the contract account in the smart contract to newActHashKey. The specific steps are as follows: ① Submit hash1, timeLogHash1, ChainName, newPK, newActHashKey, curTime, and logTimeHash to the smart contract; ② The smart contract executes the hash value `actHashKey` of hash1 + Chainname and compares it with the `actHashKey` value under ChainName; it calculates the hash value of timeLogHash1 + ChainName to obtain `logTimeHash`, and compares it with the `LogTimeKey` value under ChainName. If the two comparisons are consistent, the following update steps are executed; otherwise, the execution is terminated. ③ Update the value of ChainName's actPubKey to newPK; ④ Update the value of ChainName's actHashKey to newActHashKey; ⑤ Update the LogTimeKey value of ChainName to curTime; ⑥ Update the value of `actAdminLogTime` in `ChainName` to `curTime`; (10) The update is complete. Users can choose to log in and verify their accounts again.

[0010] Furthermore, when a user possesses the private key that controls the client account, they can use the client account's private key to sign and invoke the smart contract's function to maintain the smart contract account. After security checks and identity verification, the client account information within the smart contract is updated, specifically including the following steps: (1) Verify that the entered social authentication ID belongs to the current user; (2) The user inputs a new random secret rndSecretNew that meets the requirements of length and character composition rules, where rndSecretNew is rndSecret; (3) Use the client password LPwd of the current account held by the user to decrypt the ciphertext of the private key stored in the client to obtain the plaintext of the private key; (4) Record the hash value of the social authentication ID + new random secret rndSecretNew as hash1New, and record the hash value of hash1New + ChainName as actHashKeyNew; (5) Denote the current timestamp as curTime; (6) Record the hash value of the new random secret rndSecretNew+curTime as timeLogHashNew; (7) Submit actHashKeyNew, timeLogHashNew, current timestamp curTime, and account name ChainName to the smart contract through the smart contract's account maintenance function; (8) The smart contract updates the actHashKey of the account name ChainName to actHashKeyNew, updates actTimeLogKey to timeLogHashNew, and updates actAdminLogTime to curTime; (9) Log in and verify your account again.

[0011] Furthermore, the social authentication ID input for verification belongs to the current user, and the current user can control the smart contract account. The user-controlled random secret rndSecret proves that the current on-chain account name ChainName belongs to the current user. The specific verification process is as follows: (1) Send a time-limited SMS verification code, verification email, or verification information from a centralized platform to verify that the current user is using a social authentication ID; after confirmation, the user enters the social authentication ID bound to the client account + the password rndSecret that the user controls, and the hash calculation yields the hashold value; (2) Calculate the hash of the hashold value and the client account to obtain the actHashKey. If it matches the actHashKey of the client account in the smart contract, proceed to the next step to confirm that the user owns the client account. (3) Record the hash value of ChainName's actAdminLogTime + password rndSecret as timehash1, and the hash value of timehash1 + ChainName as timeLogHash`. Compare timeLogHash` with ChainName's actTimeLogKey. If they match, then the current user who owns rndSecret and social authentication ID is confirmed to be a legitimate owner of ChainName. If they do not match, then terminate the current comparison. The beneficial effects of this invention are: by providing users with an account for a digitally encrypted client, the digitally encrypted client achieves a user experience close to that of internet products; it organically binds the account to traditional internet social platforms familiar to users, such as mobile phone numbers and email addresses; and by using such social authentication IDs, it decouples the managed private key from the digital client account to a certain extent, reducing the barrier for users to use blockchain; and it solves the problem that after a traditional digitally encrypted client loses its private key, it is almost impossible to obtain the digital assets controlled by the original private key. Smart contract accounts can perform on-chain operations on behalf of user addresses, and other addresses / accounts can initiate contract interaction operations. This is equivalent to enabling others to pay the blockchain gas fees for contract accounts on behalf of others, thus avoiding the predicament of new users being unable to operate the blockchain due to lack of gas fees. Attached Figure Description

[0012] For ease of explanation, the present invention will be described in detail below with reference to the preferred embodiments and accompanying drawings.

[0013] Figure 1 This is a flowchart of the digital encryption client account registration process of the present invention; Figure 2 This is a flowchart of the social authentication recovery process for client accounts using digital encryption, as described in this invention. Figure 3 This invention relates to a digital encryption client account private key recovery process. Detailed Implementation

[0014] To make the implementation objectives, technical solutions, and features of this invention application clearer, the technical solutions of this invention application will be clearly and completely described below with reference to the accompanying drawings of the embodiments. Obviously, the described embodiments are only a part of the examples of this invention application, and not all of the implementation cases. The embodiments of this invention application described and shown in the accompanying drawings can generally be arranged and designed in different configurations.

[0015] It should be noted that similar labels and letters in the following figures indicate similar items. Therefore, once an item is defined in one figure, it does not need to be further defined and explained in subsequent figures.

[0016] In the description of this application, it should also be noted that, unless otherwise expressly specified and limited, the terms "set up," "install," "connect," "link," and "asymmetric encryption" should be interpreted broadly. For example, they can refer to a fixed connection, a detachable connection, or an integral connection; they can refer to a mechanical connection or an electrical connection; they can refer to a direct connection or an indirect connection through an intermediate medium; and they can refer to the internal connection of two components. Those skilled in the art can understand the specific meaning of the above terms in this application based on the specific circumstances.

[0017] Since blockchain is essentially a public distributed ledger technology, information recorded on the blockchain is usually public. All blockchain nodes should be able to obtain information from a particular blockchain record. Each account participating in a blockchain transaction does not need to know where the other party is. Information can be exchanged and transmitted through the blockchain without a centralized server. Any on-chain interaction information between two accounts is publicly visible after being recorded on the chain. In addition, the account's private key is managed and stored through wallet-like DApps. Wallets simplify the operation of signing transactions using private keys.

[0018] In view of this, this implementation example provides a decentralized account management method, and the solution provided by the embodiment of the present invention will be described in detail below: like Figure 1 As shown below, we will consider implementing this method using a mobile phone as a requirement for social authentication: 1. The digital client operator deploys the smart contract WalletNameSC on the blockchain. This smart contract has the functions of creating accounts that represent user identities, registering user identity verification information, maintaining smart contract accounts, and also has the functions of user asset management and reputation value maintenance. 2. When a user first uses the digital encryption client, they register an account and enter and confirm a local login password LPwd. Then, the digital encryption client pre-selects an account name, denoted as ChainName, and generates a 256-bit random number as the private key PrvKey for this account name. The user can back up the mnemonic phrase or private key. The generated private key PrvKey is symmetrically encrypted using the password LPwd, and the ciphertext is stored locally on the digital encryption client. In this embodiment, the social authentication ID uses a mobile phone number as an example. The client operator sends a time-limited verification code to confirm that the current user controls the current mobile phone number. This verification process can also filter for duplicate account registrations based on the mobile phone number. The social authentication ID is held by the individual user and uniquely identifies the user; it can be a mobile phone number, email address, or a login account from a centralized platform. 3. Derive the public key, denoted as PubKey, from the private key PrvKey. Then, have the user input and confirm a random secret, rndSecret, used to protect data stored in the on-chain smart contract. The phone number, account name (ChainName), and current timestamp (curTime) are hashed to obtain a hash value, which is then submitted to the smart contract to request confirmation of the account name's availability. If the account has already been registered, another account needs to be selected until the account can be registered. The following information is stored on the chain: ① The account name ChainName is unique within the smart contract. As the account of the digital encryption client, it is successfully registered and registered within the smart contract. ② The public key actPubKey of the account name ChainName serves as the basis for controlling this account by possessing the private key PrvKey stored in the encrypted client. ③ The hash value is obtained by performing a hash operation on the mobile phone number, account name ChainName, and current timestamp curTime; When a user logs into the client with the username ChainName, enters the local login password LPwd, decrypts the locally stored private key ciphertext to obtain the private key plaintext PrvKey`, and derives the public key actPubKey`, if the actPubKey stored under the username ChainName in the smart contract is the same as actPubKey`, then this account is allowed to log in to the digital encryption client. The account-related information stored on the blockchain also includes: preparing a random secret rndSecret of at least 8 characters in length for the on-chain account to be registered. This password needs to be easy to remember and has requirements such as sensitivity to uppercase and lowercase letters and numbers to ensure that it is not easy to be cracked by brute force. The public key derived from the private key used to manage this account is denoted as actPubKey; The hash value obtained by hashing mobile+rndSecret is recorded as hash1. The hash value obtained by hashing hash1+ChainName is actHashKey. actTimeLogKey is a field used to record the time when the account last performed an operation involving resetting social authentication ID control information; LogTimeHash1 is the hash value obtained by hashing actAdminLogTime and the random secret rndSecret. LogTimeHash is calculated by adding the hash value of TimeHash1 to the account name ChainName; In the ChainName storage area on the blockchain, the actHashKey is stored using the actHashKey attribute, and the LogTimeHash is stored using the LogTimeKey attribute. Finally, the data structure of the on-chain account is { ChainName: ChainName actPubKey:PubKey, actHashKey:actHashKey LogTimeKey: LogTimeKey, actAdminLogTime:curTime }; like Figure 2 As shown, when a user loses their private key and has not backed it up using a mnemonic phrase, but still remembers their phone number and login password, the user can retrieve and control their account by generating a new private key through social authentication factors. In this embodiment, the social authentication factor is a phone number as an example: (1) Confirm that the mobile phone number belongs to the current user by sending a temporary verification code with an expiration time limit to the user. The user enters the temporary verification code to verify that the mobile phone number belongs to the current user. (2) A new private key, newPriKey, is pre-generated to replace the old private key and reset the smart contract account, and a new public key, newPK, is derived. These keys are then stored locally on the encrypted client using the local login password, LPwd, which can be replaced. (3) The user can input a new random secret newRndSecret that meets the length and complexity requirements. newRndSecret can also be the old random secret rndSecret. Input the old random secret rndSecret, read the value of actAdminLogTime under the account name ChainName as lastTime, hash the value of lastTime + random secret rndSecret as timeLogHash1, hash the value of timeLogHash1 + ChainName as LogTimeKey`, read whether LogTimeKey under ChainName is equal to LogTimeKey`. If they are equal, continue the comparison; otherwise, exit the current operation. (4) Record the hash value of the mobile phone number + random secret rndSecret as hash1, and the hash value of hash1 + ChainName as actHashKey`. Match the account name ChainName on the query chain. If the actHashKey matches actHashKey`, it means that the current user is the true owner of the account ChainName. (5) Calculate the hash value of the mobile phone number plus the new random secret newRndSecret as newHash1, and then use the hash operation to obtain the new hash value newActHashKey by adding the account name ChainName to newHash1; (6) Let the current timestamp be curTime. Use the current timestamp curTime + the new random secret newRndSecret to perform a hash operation to obtain the hash value newHash1. Then, calculate the hash value of newHash1 + ChainName to be newTimeLogHash. (7) Submit hash1, timeLogHash1, ChainName, newPK, newActHashKey, and curTime to the smart contract; (8) The smart contract execution compares whether the hash value of hash1+ChainName is consistent with the actHashKey value of ChainName. If they are inconsistent, the operation is terminated. If they are consistent, the hash value of timeLogHash1+ChainName is compared with the LogTimeKey value of ChainName. If they are inconsistent, the execution is terminated. If both comparisons are consistent, it can be confirmed that the user of the current mobile phone number has submitted a verified proof. (9) The smart contract uses the smart contract account maintenance function to update the actHashKey of the contract account in the smart contract to newActHashKey. The specific steps are as follows: ① Submit hash1, timeLogHash1, ChainName, newPK, newActHashKey, curTime, and logTimeHash to the smart contract; ② The smart contract executes the hash value `actHashKey` of hash1 + Chainname and compares it with the `actHashKey` value under ChainName; it calculates the hash value of timeLogHash1 + ChainName to obtain `logTimeHash`, and compares it with the `LogTimeKey` value under ChainName. If the two comparisons are consistent, the following update steps are executed; otherwise, the execution is terminated. ③ Update the value of ChainName's actPubKey to newPK; ④ Update the value of ChainName's actHashKey to newActHashKey; ⑤ Update the LogTimeKey value of ChainName to curTime; ⑥ Update the value of `actAdminLogTime` in `ChainName` to `curTime`; (10) The update is complete. Users can choose to log in and verify their accounts again.

[0019] like Figure 3As shown, when a user possesses the private key that controls the client account, they can use the client account's private key to sign and call the smart contract's function to maintain the smart contract account. After security checks and identity verification, the client account information within the smart contract is updated, specifically including the following steps: (1) Verify the current user's mobile phone number by sending SMS verification codes, verification emails, and verification information from a centralized platform with time validity periods; after confirmation, the user enters the mobile phone number bound to the client account + the password rndSecret which is controlled by the user and obtains the hashold value through hash calculation; (2) Hash the hashold value and the client account to obtain the actHashKey. If it matches the actHashKey of the client account in the smart contract, you can proceed to the next step to confirm that the user owns the client account. (3) Record the hash value of ChainName's actAdminLogTime + password rndSecret as timehash1, and the hash value of timehash1 + ChainName as timeLogHash`. Compare timeLogHash` with ChainName's actTimeLogKey. If they match, it can be confirmed that the current user who owns rndSecret and mobile phone number is a legitimate owner of ChainName. If they do not match, the current comparison can be terminated.

[0020] By possessing the phone number and a random secret of the on-chain account, or by possessing the private key of the encrypted client user's account, the storage control information of this on-chain account can be reset. This ensures that if the user correctly manages the private key, they can update the relevant attribute values ​​of the on-chain account through the blockchain smart contract call method of the encrypted client. If the private key cannot be managed correctly, for example, if the smart device storing the private key is lost, and the private key is not backed up in time or is damaged or leaked, the user can immediately replace the actPubKey after authentication with a combination of phone number and random secret, thereby regaining control of the encrypted client account. For security, we will strengthen the user's control over the on-chain account by verifying the attribute values ​​of actHashKey and actTimeLogKey.

[0021] In the embodiments provided in this application, it should be understood that the disclosed apparatus and methods can also be implemented in other ways. The apparatus embodiments described above are merely illustrative. For example, the flowcharts and block diagrams in the accompanying drawings illustrate the architecture, functionality, and operation of possible implementations of apparatus, methods, and computer program products according to various embodiments of this application. In this regard, each block in a flowchart or block diagram may represent a module, segment, or portion of code containing one or more executable instructions for implementing a specified logical function. It should also be noted that in some alternative implementations, the functions marked in the bars may occur in a different order than those marked in the drawings. For example, two consecutive blocks may actually be executed substantially in parallel, and they may sometimes be executed in reverse order, depending on the functions involved. It should also be noted that each block in a block diagram and / or flowchart, and combinations of blocks in block diagrams and / or flowcharts, can be implemented using a dedicated hardware-based system that performs the specified function or action, or using a combination of dedicated hardware and computer instructions.

[0022] Furthermore, the functional modules in the various embodiments of this application can be integrated together to form an independent part, or each module can exist independently, or two or more modules can be integrated to form an independent part. The blockchain in this invention is not limited to a single blockchain, but includes all blockchains that support smart contract functionality. The distributed storage network is not limited to a single technology-implemented distributed storage network, but supports file-block distributed storage where a unique hash value can be used to identify and access files. The public key corresponding to the private key in this invention, taking asymmetric encryption algorithms such as the elliptic curve algorithm as an example, can actually be any algorithm that satisfies the following characteristics: 1. A public key can be derived from a private key; 2. The public key cannot be directly derived from the private key, or the derivation requires computing power resources that cannot be provided in the actual production environment, thus determining that the public key cannot be derived from the private key; 3. Ciphertext encrypted with a public key can be decrypted with a private key. If the private key is incorrect, the decryption operation cannot be completed. 4. The private key can be used to sign the submitted information, and the public key can be used to verify that the information was indeed performed by the person who holds the private key; 5. The social authentication ID designed in this invention refers to a unique identifier that each user possesses, which requires services from a platform or public basic service organization. It is often verified by the platform or organization to ensure the authenticity and uniqueness of the user's identity. The platform or public service organization can uniquely send time-sensitive messages to the user. Social authentication IDs include, but are not limited to: a user's mobile phone number in a telecommunications network, a user's email address in an email service, a WeChat ID in a social network such as WeChat, and an Apple ID for an Apple mobile phone user.

[0023] It should be noted that, in this document, relational terms such as "first" and "second" are used only to distinguish one entity or operation from another, and do not necessarily require or imply any such actual relationship or order between these entities or operations. Furthermore, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or apparatus. Without further limitations, an element defined by the phrase "comprising a—" does not exclude the presence of other identical elements in the process, method, article, or apparatus that includes said element.

[0024] The above descriptions are merely various embodiments of this application, but the scope of protection of this application is not limited thereto. Any variations or substitutions that can be easily conceived by those skilled in the art within the scope of the technology disclosed in this application should be included within the scope of protection of this application. Therefore, the scope of protection of this application should be determined by the scope of the claims.

Claims

1. A decentralized account management method, characterized in that, Includes the following steps: (1) Deploy smart contracts on the blockchain, wherein the smart contracts have the functions of creating accounts representing user identities, registering user identity verification information, maintaining smart contract accounts, and also have the functions of user asset management and reputation value maintenance; (2) The user enters and confirms a local login password LPwd, and then selects a username as ChainName in advance on the client through the digital encryption client. A private key PrvKey is randomly generated for this username. The generated private key PrvKey is symmetrically encrypted using the password LPwd, and the ciphertext is stored locally on the digital encryption client. (3) Derive the public key from the private key PrvKey, denoted as actPubKey. The user then inputs and confirms a random secret rndSecret used to protect the data stored in the on-chain smart contract. Combine the social authentication ID, account name ChainName, and current timestamp curTime, perform a hash operation to obtain the hash value, and submit it to the smart contract to request confirmation of the availability of the account name ChainName. Store the following information on the chain: ① The account name ChainName is unique within the smart contract. As the account of the digital encryption client, it is successfully registered and registered within the smart contract. ② The public key actPubKey of the account name ChainName serves as the basis for controlling this account by possessing the private key PrvKey stored in the encrypted client. ③ The hash value is obtained by combining the social verification ID, account name ChainName, and current timestamp curTime; (4) When a user logs into the client with the account name ChainName, enters the local login password LPwd to decrypt the private key ciphertext stored locally to obtain the private key plaintext PrvKey`, and derives the public key actPubKey`, if the actPubKey stored under the account name ChainName in the smart contract is the same as actPubKey`, then this account is allowed to log in to the digital encryption client.

2. The decentralized account management method according to claim 1, characterized in that: The social authentication ID is held by the user and can uniquely identify the user. It can be a mobile phone number, email address, or login account of a centralized platform.

3. The decentralized account management method according to claim 2, wherein the account-related information stored on the chain further includes: (1) A random secret rndSecret, wherein the random secret rndSecret is a sequence of more than 8 characters containing uppercase and lowercase characters and numbers that is input by the user or generated by the client program; (2) The public key derived from the private key used to manage the account is denoted as actPubKey; (3) actHashKey is obtained by hashing the user's social authentication ID + random secret rndSecret to get hash1, and then using hash1 + account name ChainName to perform a second hash operation; (4) actAdminLogTime, a field used to record the time when the account last performed an operation involving resetting social authentication ID control information; (5) timeHash1, the hash value obtained by hashing actAdminLogTime and the random secret rndSecret; (6) LogTimeHash, which is calculated by adding the hash value of timeHash1 + account name ChainName; (7) In the ChainName storage area on the blockchain, use the attribute actHashKey to store actHashKey and use LogTimeKey to store LogTimeHash.

4. A decentralized account management method according to claim 3, characterized in that: If the private key PrvKey corresponding to the attribute actPubKey under the account name ChainName is lost and has not been backed up using a mnemonic phrase, the user can regain control of the account through social authentication ID. The specific steps are as follows: (1) Confirm that the social authentication ID belongs to the current user, and send a temporary verification code with an expiration time limit to the user. The user enters the temporary verification code to verify that the social authentication ID belongs to the current user. (2) A new private key newPriKey is pre-generated to replace the old private key and reset the smart contract account, and a new public key newPK is derived. The new public key newPK is stored locally on the encrypted client using the local login password LPwd in symmetric encryption. The LPwd can be replaced. (3) The user can input a new random secret newRndSecret that meets the length and complexity requirements. newRndSecret can also be the old random secret rndSecret. Input the old random secret rndSecret, read the value of actAdminLogTime under the account name ChainName as lastTime, hash the value of lastTime + random secret rndSecret as timeLogHash1, hash the value of timeLogHash1 + ChainName as LogTimeKey`, read whether LogTimeKey under ChainName is equal to LogTimeKey`. If they are equal, continue the comparison; otherwise, exit the current operation. (4) Record the hash value after hashing the social authentication ID + random secret rndSecret as hash1, and the hash value after hashing hash1 + ChainName again as actHashKey`. Match the account name ChainName on the query chain. If the query finds that its actHashKey is consistent with actHashKey`, it indicates that the current user is the real owner of the account ChainName. (5) Calculate the hash value of the social authentication ID + the new random secret newRndSecret as newHash1, and then use the hash operation to obtain the new hash value newActHashKey by hashing newHash1 + the account name ChainName; (6) Let the current timestamp be curTime. Use the current timestamp curTime + the new random secret newRndSecret to perform a hash operation to obtain the hash value newHash1. Then, calculate the hash value of newHash1 + ChainName to be newTimeLogHash. (7) Submit hash1, timeLogHash1, ChainName, newPK, newActHashKey, and curTime to the smart contract; (8) The smart contract execution compares whether the hash value of hash1+ChainName is consistent with the actHashKey value of ChainName. If they are inconsistent, the operation is terminated. If they are consistent, the hash value of timeLogHash1+ChainName is compared with the LogTimeKey value of ChainName. If they are inconsistent, the execution is terminated. If both comparisons are consistent, it can be confirmed that the user of the current social authentication ID has submitted a verified proof. (9) The smart contract uses the smart contract account maintenance function to update the actHashKey of the contract account in the smart contract to newActHashKey. The specific steps are as follows: ① Submit hash1, timeLogHash1, ChainName, newPK, newActHashKey, curTime, and logTimeHash to the smart contract; ② The smart contract executes the hash value `actHashKey` of hash1 + Chainname and compares it with the `actHashKey` value under ChainName; it calculates the hash value of timeLogHash1 + ChainName to obtain `logTimeHash`, and compares it with the `LogTimeKey` value under ChainName. If the two comparisons are consistent, the following update steps are executed; otherwise, the execution is terminated. ③ Update the value of ChainName's actPubKey to newPK; ④ Update the value of ChainName's actHashKey to newActHashKey; ⑤ Update the LogTimeKey value of ChainName to curTime; ⑥ Update the value of `actAdminLogTime` in `ChainName` to `curTime`; (10) Update complete. Users can choose to log in and verify their accounts again.

5. The decentralized account management method according to claim 3, characterized in that: When a user possesses the private key that controls the client account, they can use this private key to sign and invoke the smart contract's account maintenance function. After security checks and identity verification, the client account information within the smart contract is updated, specifically including the following steps: (1) Verify that the entered social authentication ID belongs to the current user; (2) The user inputs a new random secret rndSecretNew that meets the requirements of length and character composition rules, where rndSecretNew can be rndSecret; (3) Use the client password LPwd of the current account held by the user to decrypt the ciphertext of the private key stored in the client to obtain the plaintext of the private key; (4) Record the hash value of the social authentication ID + new random secret rndSecretNew as hash1New, and record the hash value of hash1New + ChainName as actHashKeyNew; (5) Denote the current timestamp as curTime; (6) Record the hash value of the new random secret rndSecretNew+curTime as timeLogHashNew; (7) Submit actHashKeyNew, timeLogHashNew, current timestamp curTime, and account name ChainName to the smart contract through the smart contract's account maintenance function; (8) The smart contract updates the actHashKey of the account name ChainName to actHashKeyNew, updates actTimeLogKey to timeLogHashNew, and updates actAdminLogTime to curTime; (9) Log in and verify your account again.

6. The decentralized account management method according to claim 5, characterized in that: The verification input social authentication ID belongs to the current user, and the current user can control the smart contract account. The user-controlled random secret rndSecret proves that the current on-chain account name ChainName belongs to the current user. The specific verification process is as follows: (1) Send a time-limited SMS verification code, verification email, or verification information from a centralized platform to verify that the current user is using a social authentication ID; after confirmation, the user enters the social authentication ID bound to the client account + the password rndSecret that the user controls, and the hash calculation yields the hashold value; (2) Hash the hashold value and the client account to obtain the actHashKey. If it matches the actHashKey of the client account in the smart contract, you can proceed to the next step to confirm that the user owns the client account. (3) Record the hash value of ChainName's actAdminLogTime + password rndSecret as timehash1, and the hash value of timehash1 + ChainName as timeLogHash`. Compare timeLogHash` with ChainName's actTimeLogKey. If they match, it can be confirmed that the current user who owns rndSecret and social authentication ID is a legitimate owner of ChainName. If they do not match, the current comparison can be terminated.

Images