GB2623142A - Wallet system and transaction method - Google Patents

Wallet system and transaction method Download PDF

Info

Publication number
GB2623142A
GB2623142A GB2304532.1A GB202304532A GB2623142A GB 2623142 A GB2623142 A GB 2623142A GB 202304532 A GB202304532 A GB 202304532A GB 2623142 A GB2623142 A GB 2623142A
Authority
GB
United Kingdom
Prior art keywords
node
transaction
nodes
scheduling
signature
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Pending
Application number
GB2304532.1A
Other versions
GB202304532D0 (en
Inventor
Zhu Weisha
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Fifth Force Tech Ltd
Original Assignee
Fifth Force Tech Ltd
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Priority claimed from CN202210541275.0A external-priority patent/CN114723438B/en
Application filed by Fifth Force Tech Ltd filed Critical Fifth Force Tech Ltd
Publication of GB202304532D0 publication Critical patent/GB202304532D0/en
Publication of GB2623142A publication Critical patent/GB2623142A/en
Pending legal-status Critical Current

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/30—Payment architectures, schemes or protocols characterised by the use of specific devices or networks
    • G06Q20/36—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using electronic wallets or electronic money safes
    • G06Q20/367—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using electronic wallets or electronic money safes involving electronic purses or money safes
    • G06Q20/3672—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using electronic wallets or electronic money safes involving electronic purses or money safes initialising or reloading thereof
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/08—Key distribution or management, e.g. generation, sharing or updating, of cryptographic keys or passwords
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/30—Payment architectures, schemes or protocols characterised by the use of specific devices or networks
    • G06Q20/36—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using electronic wallets or electronic money safes
    • G06Q20/367—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using electronic wallets or electronic money safes involving electronic purses or money safes
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/30—Payment architectures, schemes or protocols characterised by the use of specific devices or networks
    • G06Q20/36—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using electronic wallets or electronic money safes
    • G06Q20/367—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using electronic wallets or electronic money safes involving electronic purses or money safes
    • G06Q20/3674—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using electronic wallets or electronic money safes involving electronic purses or money safes involving authentication
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/30—Payment architectures, schemes or protocols characterised by the use of specific devices or networks
    • G06Q20/36—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using electronic wallets or electronic money safes
    • G06Q20/367—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using electronic wallets or electronic money safes involving electronic purses or money safes
    • G06Q20/3678—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using electronic wallets or electronic money safes involving electronic purses or money safes e-cash details, e.g. blinded, divisible or detecting double spending
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/38—Payment protocols; Details thereof
    • G06Q20/382—Payment protocols; Details thereof insuring higher security of transaction
    • G06Q20/3825—Use of electronic signatures
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/38—Payment protocols; Details thereof
    • G06Q20/382—Payment protocols; Details thereof insuring higher security of transaction
    • G06Q20/3829—Payment protocols; Details thereof insuring higher security of transaction involving key management
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/38—Payment protocols; Details thereof
    • G06Q20/389—Keeping log of transactions for guaranteeing non-repudiation of a transaction
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/06—Network architectures or network communication protocols for network security for supporting key management in a packet data network
    • H04L63/062—Network architectures or network communication protocols for network security for supporting key management in a packet data network for key distribution, e.g. centrally by trusted party

Landscapes

  • Business, Economics & Management (AREA)
  • Accounting & Taxation (AREA)
  • Engineering & Computer Science (AREA)
  • Finance (AREA)
  • Strategic Management (AREA)
  • Physics & Mathematics (AREA)
  • General Business, Economics & Management (AREA)
  • General Physics & Mathematics (AREA)
  • Theoretical Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Computer Hardware Design (AREA)
  • Computing Systems (AREA)
  • General Engineering & Computer Science (AREA)
  • Financial Or Insurance-Related Operations Such As Payment And Settlement (AREA)

Abstract

Disclosed are a wallet system and a transaction method. The wallet system comprises a communication node, a scheduling node and at least one backup node, each node stores a private key, and all private keys aim at the same account. Firstly, the communication node generates a transaction request according to received payment transaction information, and sends the transaction request to the scheduling node; then, the scheduling node selects a plurality of nodes as signature nodes in response to the transaction request; next, the scheduling node schedules the private keys in the signature nodes to sign payment transactions one by one, and then generates signature success information and feeds back the signature success information to the communication node; and finally, after receiving the signature success information, the communication node executes a payment transaction operation. The system in the embodiments of the present invention is an independent cluster system completely mastered by a user, and is a wallet system constructed by combining a cluster technology and a multi-signature technology, so that high-security storage and inheritance of assets are achieved for the first time, and the design of a transaction mode suitable for Web3 is realized.

Description

WALLET SYSTEM AND TRANSACTION METHOD
TECHNICAL FIELD
[0001] The present disclosure relates to the field of digital asset trading, and in particular, to a wallet system and a transaction method
BACKGROUND
[0002] Web3 is a set of extensive campaigns and protocols initiated to make the Internet more decentralized, verifiable, and secure, in other words, is the Internet that enables users to master their own data. However, in the field of digital asset trading, there is still no wallet system in the prior art to well adapt to Web3. Therefore, how to provide a wallet system adapting to Web3 is a difficult problem to be resolved in the field of digital asset trading.
SUMMARY
[0003] The present disclosure provides a wallet system and a transaction method to resolve a problem of lack of a transaction mode adapting to Web3 in the prior art. A wallet system can be built by combining a cluster technology and a multi-signature technology to realize the transaction mode adapting to Web3.
[0004] To achieve the above objective, embodiments of the present disclosure provide a wallet system, including a communication node, a scheduling node, and at least one backup node, where each node stores one private key, and all the private keys are for a same account; [0005] the communication node is configured to generate a transaction request based on received payment transaction information and send the transaction request to the scheduling node; [0006] the scheduling node is configured to select a plurality of nodes as signature nodes in response to the transaction request; [0007] the scheduling node is further configured to: after scheduling private keys of the signature nodes to sign a payment transaction one by one, generate signature success information and feed the signature success information back to the communication node; [0008] the communication node is further configured to perform a payment transaction operation after receiving the signature success information.
[0009] As an improvement of the above solution, the payment transaction information at least includes a target transaction amount, and the transaction request at least includes a target signature mode; and 100101 that the communication node is configured to generate the transaction request based on the received payment transaction information specifically includes: [0011] the communication node is configured to obtain the target signature mode based on a preset mapping relationship between a transaction amount and a signature mode and the target transaction amount.
[0012] As an improvement to the above solution, the mapping relationship is specifically as follows: [0013] a plurality of transaction amount grades are obtained through division based on an amount size; 100141 when a first transaction amount is greater than a second transaction amount, a grade of the first transaction amount is higher than or equal to a grade of the second transaction amount; and [0015] a higher grade leads to more signatures required in the signature mode.
100161 As an improvement to the above solution, the private key is generated in a following manner: generating, by each node, one private key for the same account in an offline state. [0017] As an improvement to the above solution, the communication node is further configured to: when the payment transaction information belongs to non-fungible token (NH') transaction information, generate a transaction record based on the payment transaction operation after completing the payment transaction operation, and update its own account book; and 100181 the communication node is further configured to send the transaction record to other nodes, such that the other nodes update their own account books based on the transaction record. [0019] As an improvement to the above solution, after the communication node sends the transaction request to the scheduling node, and before the scheduling node schedules the private keys of the signature nodes to sign the payment transaction one by one, the scheduling node is further configured to send its own to-be-backed up account book to all backup nodes when the transaction payment information belongs to NFT transaction information, such that the backup nodes reconcile their account books with the to-be-backed up account book and update their own account books, where the to-be-backed up account book represents information not synchronized to all other nodes in an account book of the scheduling node.
[0020] As an improvement to the above solution, the communication node is further configured to: when the payment transaction information belongs to cryptocurrency transaction information, generate a transaction record based on the payment transaction operation after completing the payment transaction operation, so as to update a public account.
[0021] As an improvement to the above solution, the system further includes a replacement node; 100221 the replacement node is configured to obtain a private-key encryption file of a designated to-be-replaced node from a cloud end in response to a node replacement instruction entered by a user, generate a node replacement request, and send the node replacement request to the scheduling node; 100231 the scheduling node is further configured to schedule, in response to the node replacement request, private keys of a plurality of other nodes than the to-be-replaced node to sign the private-key encryption file, such that the replacement node opens the private-key encryption file to obtain a private key of the to-be-replaced node, where the private-key encryption file of the to-be-replaced node is generated by encrypting the private key of the tobe-replaced node by using the private keys of the other nodes; and 100241 the replacement node is further configured to: after setting the private key of the to-bereplaced node as a private key of the replacement node, generate node change information and send the node change information to the scheduling node, such that the scheduling node is capable of performing node scheduling accurately.
100251 As an improvement to the above solution, the system further includes an inheritance node, where a quantity of inheritance nodes is equal to a quantity of abandoned nodes, and the abandoned nodes include an abandoned communication node, an abandoned scheduling node, and an abandoned backup node; and 100261 a target inheritance node is configured to establish a corresponding relationship between the target inheritance node and an inheritance file stored at the cloud end based on a username and a password of one of the abandoned nodes in response to a user login instruction, where the target inheritance node is any one of the inheritance nodes; where 100271 the target inheritance node is further configured to control the cloud end to send the inheritance file to a preset social account of the user in response to a user inheritance instruction, such that the user assigns, based on the inheritance file, a usemame, a password, and a private key that are corresponding to an abandoned node to each of the inheritance nodes, where the inheritance file records usernames, passwords, and private keys of all the abandoned nodes. 100281 To achieve the above objective, the embodiments of the present disclosure further provide a transaction method based on the wallet system according to any one of the above embodiments, including: 100291 generating, by the communication node, a transaction request based on received payment transaction information, and sending the transaction request to the scheduling node; 100301 selecting, by the scheduling node, a plurality of nodes as signature nodes in response to the transaction request; 100311 generating, by the scheduling node after scheduling private keys of the signature nodes to sign a payment transaction one by one, signature success information, and feeding the signature success information back to the communication node; and [0032] performing, by the communication node, a payment transaction operation after receiving the signature success information.
[0033] Compared with the prior art, a wallet system and a transaction method provided in the embodiments of the present disclosure are as follows: The wallet system includes a communication node, a scheduling node, and at least one backup node, where each node stores one private key, and all the private keys are for a same account. First, the communication node generates a transaction request based on received payment transaction information and sends the transaction request to the scheduling node. Next, the scheduling node selects a plurality of nodes as signature nodes in response to the transaction request, and after scheduling private keys of the signature nodes to sign a payment transaction one by one, the scheduling node generates signature success information and feed the signature success information back to the communication node. Finally, the communication node performs a payment transaction operation after receiving the signature success information. The embodiments of the present disclosure can combine a cluster technology and a multi-signature technology to build a wallet system completely controlled by a user, so as to realize a transaction adapting to Web3.
BRIEF DESCRIPTION OF THE DRAWINGS
[0034] FIG. 1 is a schematic structural diagram of a wallet system according to an embodiment of the present disclosure; and [0035] FIG. 2 is a schematic flowchart of a transaction method according to an embodiment of the present disclosure.
DETAILED DESCRIPTION
[0036] The following clearly and completely describes the technical solutions in the embodiments of the present disclosure with reference to the accompanying drawings in the embodiments of the present disclosure. Apparently, the described embodiments are merely some rather than all of the embodiments of the present disclosure. All other embodiments obtained by a person of ordinary skill in the art based on the embodiments of the present disclosure without creative efforts shall fall within the protection scope of the present disclosure. [0037] FIG. I is a schematic structural diagram of a wallet system according to an embodiment of the present disclosure. The wall system includes a communication node, a scheduling node, and at least one backup node, where each node stores one private key, and all the private keys are for a same account; 100381 the communication node is configured to generate a transaction request based on received payment transaction information and send the transaction request to the scheduling node; 100391 the scheduling node is configured to select a plurality of nodes as signature nodes in response to the transaction request; 100401 the scheduling node is further configured to: after scheduling private keys of the signature nodes to sign a payment transaction one by one, generate signature success information and feed the signature success information back to the communication node; and 100411 the communication node is further configured to perform a payment transaction operation after receiving the signature success information.
100421 It is worth noting that each node (the communication node, the scheduling node, and the backup node) may be a mobile phone, a computer, a server, or another electronic device, which is not limited herein. A small cluster system suitable for a wallet is provided by using a GreatFree distributed language. The system is completely controlled by a user, without being controlled by an external device or external personnel. The system is a master-slave system built on a peer-to-peer network, and a role of a node can be converted based on an actual need. Each node has a function of making a private key signature. The communication node is responsible for external communication and serves as a bridge for information interaction between a device inside the system and a device outside the system. The scheduling node acts as an internal scheduling role of the system and performs information interaction with another node. The system has a function of making a multi-signature through cluster scheduling. It can be understood that in order to further improve security of the payment transaction, a verification function such as face recognition, password recognition or fingerprint recognition can be set on an electronic device where the node is located, and signature making, payment transaction, and other operations can be performed only after the verification is successful. For example, a verification operation is triggered after the scheduling node selects the signature node or after the communication node receives the signature success information. A verification mode and timing may be set by the user based on an actual need, and are not limited herein.
100431 Specifically, the wallet system is composed of the communication node, the scheduling node, and the backup node. A quantity of backup nodes is determined by a specific application of the system. Each node stores the one private key. These private keys are for the same account, that is, each account needs to be managed by one cluster system. When it is necessary to perform a transfer operation to another account, in other words, after receiving payment transaction information, the communication node responsible for external communication processes the payment transaction information to generate a transaction request, and sends the transaction request to the scheduling node inside the system. In response to the received transaction request, the scheduling node selects a plurality of nodes from all the nodes in the system as signature nodes, where a quantity of signature nodes is determined by a preset signature quantity rule, and the signature node may be the scheduling node, the communication node, or the backup node. The signature node is selected according to a preset selection rule, and may be selected randomly or by presetting a priority, which is not limited herein. The scheduling node schedules the signature node, such that the signature node uses its own private key to sign the current payment transaction, generates signature success information, and feeds the signature success information back to the communication node, such that the communication node obtains a transaction signal, so as to perform a payment transaction operation.
100441 Compared with the prior art, a wallet system provided in this embodiment of the present disclosure is as follows: The wallet system includes a communication node, a scheduling node, and at least one backup node, where each node stores one private key, and all the private keys are for a same account. First, the communication node generates a transaction request based on received payment transaction information and sends the transaction request to the scheduling node. Next, the scheduling node selects a plurality of nodes as signature nodes in response to the transaction request, and after scheduling private keys of the signature nodes to sign a payment transaction one by one, the scheduling node generates signature success information and feeds the signature success information back to the communication node. Finally, the communication node performs a payment transaction operation after receiving the signature success information. This embodiment of the present disclosure can combine a cluster technology and a multi-signature technology to build a wallet system completely controlled by a user, so as to realize a transaction adapting to Web3.
100451 In an implementation, the payment transaction information at least includes a target transaction amount, and the transaction request at least includes a target signature mode; and 100461 that the communication node is configured to generate the transaction request based on the received payment transaction information specifically includes: 10047] the communication node is configured to obtain the target signature mode based on a preset mapping relationship between a transaction amount and a signature mode and the target transaction amount.
100481 Specifically, the payment transaction information received by the communication node inevitably includes the target transaction amount. In this implementation, the target signature mode is determined by the target transaction amount. The communication node queries the preset mapping relationship between the transaction amount and the signature mode, and finds a signature mode corresponding to the target transaction amount as the target signature mode.
The signature mode may be determining a specific signature node or setting the quantity of signature nodes, which is not limited herein.
[0049] In an implementation, the mapping relationship is specifically as follows [0050] a plurality of transaction amount grades are obtained through division based on an amount size; 100511 when a first transaction amount is greater than a second transaction amount, a grade of the first transaction amount is higher than or equal to a grade of the second transaction amount; and 100521 a higher grade leads to more signatures required in the signature mode.
[0053] Specifically, the mapping relationship between the transaction amount and the signature mode is actually a mapping relationship between the transaction amount and a quantity of signatures (the quantity of signature nodes). The mapping relationship is set by the user when the system is built, and may be modified by the user based on an actual need in a subsequent application of the system. Transaction amount grades of a preset quantity are obtained through division based on the amount size. A larger transaction amount leads to a higher grade (including a case in which different transaction amounts correspond to a same grade, which is represented in a form of a piecewise function), and a higher grade leads to more signatures required in a corresponding signature mode. Signatures of a different quantity are selected based on the transaction amount, which considers both convenience of the payment transaction and ensures security of the payment transaction.
[0054] For example, it is assumed that there are three nodes (the communication node, the scheduling node, and the backup node) in the system, each node has one private key, a multi-signature scheme is executed, and a 3-1 signature mode (only one private key is required to make a signature), a 3-2 signature mode (two private keys are required to make signatures), and a 3-3 signature mode (all private keys are required to make signatures) are preset in advance. The preset mapping relationship is specifically as follows: a transaction amount less than or equal to 3000 CNY corresponds to the 3-1 signature mode, a transaction amount greater than 3000 CNY and less than or equal to 10000 CNY corresponds to the 3-2 signature mode, and a transaction amount greater than 10000 CNY corresponds to the 3-3 signature mode.
[0055] It is worth noting that the mapping relationship is not limited to the above specific examples, but may be set based on an actual situation. It can be understood that a minimum quantity of signatures is 0, and a maximum quantity of signatures is equal to a quantity of private keys. The quantity of private keys and a specific quantity of grades are set by the user. A minimum quantity of grades is 1, and a maximum quantity of grades is related to the quantity of private keys in the system, which is the quantity of private keys plus 1.
[0056] In an implementation, the payment transaction information further includes transaction party information; and [0057] the performing a payment transaction operation specificallyincludes: sending the target transaction amount to a corresponding transaction party based on the transaction party information. Specifically, when performing the payment transaction operation, the communication node needs to determine the target transaction amount and the transaction party information (an account of the transaction party) before transferring the target transaction amount to the transaction party.
[0058] In an implementation, the private key is generated in a following manner generating, by each node, one private key for the same account in an offline state.
[0059] Specifically, because the wallet system is a peer-to-peer network, the private keys can be generated separately in the offline state. The offline state herein is a state in which a node is disconnected from other nodes. The private key of each node is generated by the node itself, and each node only knows its own private key, and does not know private keys of other nodes. This avoids a possibility of leakage of private keys of other nodes when a node is attacked, thereby improving safety performance of the system.
100601 In an implementation, the communication node is further configured to: when the payment transaction information belongs to NFT transaction information, generate a transaction record based on the payment transaction operation after completing the payment transaction operation, and update its own account book; and [0061] the communication node is further configured to send the transaction record to other nodes, such that the other nodes update their own account books based on the transaction record. [0062] Specifically, after completing the payment transaction operation, the communication node needs to update an account book to which the account belongs. Different types of accounts correspond to different account book storage modes. The payment transaction information received by the communication node is payment transaction information about an NFT, which indicates that the account is an NET account. Each node of the system has a child account book. After completing the payment transaction operation, the communication node generates the transaction record based on the payment transaction operation to update its own account book, and sends the transaction record to the other nodes (the scheduling node and the backup node), such that the other nodes update their own account books based on the transaction record, thereby realizing data synchronization and backup. It can be understood that in each payment transaction process, the communication node as a bridge to perform information interaction with the outside, and the scheduling node for signature scheduling are inevitably online. Therefore, the account book of the communication node and an account book of the scheduling node are consistent, recording all transactions. The backup node is only a provider of the private key, and does not need to be online in real time. Therefore, an account book of the backup node may not be updated in real time.
[0063] Further, each node generates asset information based on its own account book. When receiving an asset query instruction entered by the user, the node displays the asset information on a display screen for the user to consult.
[0064] Further, the scheduling node is further configured to perform information interaction with an external preset transaction system ''chainless platform". The chainless platform establishes an information interaction relationship with another wallet system. In practical application, the chainless platform is configured to track a transfer operation. After detecting that a payment has been received, the chainless platform generates transaction success information and feeds the transaction success information back to two parties involved in a corresponding transaction, such that the two parties involved in the transaction know that the transaction is completed.
[0065] In an implementation, after the communication node sends the transaction request to the scheduling node, and before the scheduling node schedules the private keys of the signature nodes to sign the payment transaction one by one, the scheduling node is further configured to send its own to-be-backed up account book to all backup nodes when the transaction payment information belongs to NET transaction information, such that the backup nodes reconcile their account books with the to-be-backed up account book and update their own account books, where the to-be-backed up account book represents information not synchronized to all other nodes in the account book of the scheduling node.
[0066] Specifically, the to-be-backed up account book is account book information that has not been completely backed up (that is, the account book is not synchronized to all the backup nodes), and the to-be-backed up account book is temporarily stored in a to-be-backed up account book cache region of the scheduling node. In order to improve accuracy of data backup, before sending the to-be-backed up account book to the backup node, the scheduling node needs to reconcile the to-be-backed up account book with its own account book, and then transmits the to-be-backed up account book when the to-be-backed up account book is correct. Because it cannot be ensured that the backup node is online in real time, the scheduling node needs to send the to-be-backed up account book to an online backup node for reconciliation before each transfer operation, so as to synchronize the account book of the backup node with that of the scheduling node. In a synchronization process, the reconciliation can be performed based on a time stamp of each piece of data in the account book. After receiving the transaction request, the scheduling node learns that the transaction is to be performed. In order to ensure account book synchronization before the transfer operation, the scheduling node sends its temporarily stored to-be-backed up account book to the online backup node before signature scheduling, such that the backup node performs data synchronization.
[0067] In an implementation, the communication node is further configured to: when the payment transaction information belongs to cryptocurrency transaction information, generate a transaction record based on the payment transaction operation after completing the payment transaction operation, so as to update a public account.
[0068] Specifically, if the system serves a cryptocurrency transaction, there is no account book in the system, but the transaction is recorded in a form of the public account. After completing the payment transaction operation, the communication node generates the corresponding transaction record based on the payment transaction operation, and sends the transaction record to a full node of a corresponding cryptocurrency. The full node is responsible for managing and updating the public account. It can be understood that the process ends after the transaction record is generated and sent to the public account, and the public account can be updated based on the transaction record. For the wallet system, the transaction record is sent to a temporary data pool of the full node of the cryptocurrency.
100691 Further, as a chainless system, the wallet system stores a child account book on each node. The wallet system supports storage of sub-accounts, NET metadata, and indexes of the chainless system, and also includes a private key of the cryptocurrency, 100701 In an implementation, the system further includes a replacement node; [0071] the replacement node is configured to obtain a private-key encryption file of a designated to-be-replaced node from a cloud end in response to a node replacement instruction entered by the user, generate a node replacement request, and send the node replacement request to the scheduling node; [0072] the scheduling node is further configured to schedule, in response to the node replacement request, private keys of a plurality of other nodes than the to-be-replaced node to sign the private-key encryption file, such that the replacement node opens the private-key encryption file to obtain a private key of the to-be-replaced node, where the private-key encryption file of the to-be-replaced node is generated by encrypting the private key of the tobe-replaced node by using the private keys of the other nodes; and 100731 the replacement node is further configured to: after setting the private key of the to-bereplaced node as a private key of the replacement node, generate node change information and send the node change information to the scheduling node, such that the scheduling node is capable of performing node scheduling accurately.
100741 Specifically, as shown in FIG. 1, in the system, each node is configured with one cloud-end memory (a backup cloud-end memory, a scheduling cloud-end memory, or a communication cloud-end memory). The cloud-end memory may be a home cloud, an InterPlanetary File System (lPFS), or another cloud storage system, which is not limited herein. After generating the private key, the node encrypts the private key to obtain the private-key encryption file (smart contract), and sends the private-key encryption file to the cloud-end memory corresponding to the node for cloud backup of the private key. For example, the private-key encryption file can be decrypted by private keys of other nodes, for example, in the 3-2 signature mode. When a device is lost, the replacement node (a new device) responds to a node replacement instruction entered by the user, accesses, by using a preset password, a cloud-end memory corresponding to the lost device, downloads a private-key encryption file from the cloud end, generates a node replacement request, and sends the node replacement request to the scheduling node. In response to the node replacement request, the scheduling node schedules private keys of other devices than the lost device to decrypt the private-key encryption file of the new device, such that the new device obtains a private key of the lost device. Then, the new device sets the obtained private key as its own private key, and generates node change information and sends the node change information to the scheduling node, such that the scheduling node can accurately schedule the new device in a subsequent transaction process. [0075] In an implementation, when the user wants to replace an old device with a new device, the old device provides its own private key to the new device in response to a private key transfer instruction entered by the user. Specifically, the old device generates a quick response code for its own private key based on the private key in response to the private key transfer instruction entered by the user, and the new device obtains the corresponding private key by scanning the quick response code of the private key.
100761 In an implementation, the system further includes an inheritance node, where a quantity of inheritance nodes is equal to a quantity of abandoned nodes, and the abandoned nodes include an abandoned communication node, an abandoned scheduling node, and an abandoned backup node; and 100771 a target inheritance node is configured to establish a corresponding relationship between the target inheritance node and an inheritance file stored at the cloud end based on a username and a password of one of the abandoned nodes in response to a user login instruction, where the target inheritance node is any one of the inheritance nodes; where [0078] the target inheritance node is further configured to control the cloud end to send the inheritance file to a preset social account of the user in response to a user inheritance instruction, such that the user assigns, based on the inheritance file, a username, a password, and a private key that are corresponding to an abandoned node to each of the inheritance nodes, where the inheritance file records usernames, passwords, and private keys of all the abandoned nodes.
100791 Specifically, the private key is inherited when all the original nodes are lost. The inheritance file records a username, as well as a password and a private key that are corresponding to the usemame for each node in the wallet system. When all original devices (abandoned nodes) are lost, in response to a user login instruction, a new device (target inheritance node) logs in based on a username and a password of one of the abandoned nodes, and establishes a connection to a cloud-end memory corresponding to the abandoned node, in other words, establishes a corresponding relationship between the new device and the cloud-end memory stored at the cloud end, and in response to a user inheritance instruction, the new device controls, after a preset time period, the corresponding cloud-end memory to send the inheritance file to the preset social account (such as a mailbox or a mobile phone number) of the user. The preset time period may be set by the user based on an actual need. After the preset time period, a preset inheritance reminder message is displayed (through voice broadcasting or text displaying). The user can assign user names, passwords, and private keys to new devices (inheritance nodes) of a preset quantity based on the received inheritance file to replace the original devices. The quantity of the new devices is the same as that of the original devices. Further, when receiving the user inheritance instruction, the new device obtains a pre-stored inheritance verification question at the cloud end for the user to answer. When a user's answer to the inheritance verification question and a preset standard answer meet a preset accuracy rate, the new device performs a next operation.
[0080] Further, after the private key is inherited, a communication inheritance node generates a transaction request when receiving payment transaction information, and sends the transaction request to a scheduling inheritance node. The inheritance nodes include one communication inheritance node, one scheduling inheritance node, and at least one backup inheritance node. 100811 In response to the transaction request, the scheduling inheritance node schedules private keys of all the inheritance nodes to sign a payment transaction one by one, generates signature success information, and feeds the signature success information back to the communication inheritance node.
[0082] The communication inheritance node performs a payment transaction operation after receiving the signature success information.
100831 It can be understood that a device loss brings some insecurity. Therefore, after the private key is inherited, all private keys need to be used to make a signature for this transaction to reduce a risk. Further, if the user wants to further reduce the risk, the user can build a new wallet system, transfer all assets in the original wallet system to the new wallet system for asset management, and discard the original wallet system to improve asset security.
[0084] Further, the wallet system has a program security self-check function to ensure that a program is complete and synchronized and accounting is correct. Generally, a self-check operation is performed when an electronic device where the node is located is powered on. [0085] Further, since an electronic device where the communication node is located also involves a third-party application, such as WeChat, Alipay, or another centralized application, the wallet system can not only directly conduct the payment transaction as an independent application, but also interface with the third-party application for third-party application payment. Therefore, it is necessary to obtain an interface standard of an application programming interface (API) of the third-party application to configure the API for the wallet system, so as to enable the wallet system to smoothly interface with a third-party system for transaction payment.
[0086] This embodiment of the present disclosure can combine a cluster technology and a multi-signature technology to build a wallet system completely controlled by the user, so as to realize a transaction adapting to Web3.
[0087] Referring to a schematic flowchart of a transaction method shown in FIG. 2, an embodiment of the present disclosure provides a transaction method, which is applied to the wallet system described in any one of the above embodiments, and includes following steps: [0088] S I: A transaction request is generated by a communication node based on received payment transaction information, and sent to a scheduling node.
100891 S2: A plurality of nodes are selected as signature nodes by the scheduling node in response to the transaction request.
[0090] S3: Signature success information is generated by the scheduling node after scheduling private keys of the signature nodes to sign a payment transaction one by one, and fed back to the communication node.
100911 S4: A payment transaction operation is performed by the communication node after receiving the signature success information.
[0092] It is worth noting that for a specific working process of the transaction method, reference may be made to the working process of the wallet system in the above embodiments, and details are not described herein again.
[0093] Compared with the prior art, the transaction method provided in this embodiment of the present disclosure is as follows: First, the communication node generates the transaction request based on the received payment transaction information and sends the transaction request to the scheduling node. Next, the scheduling node selects the nodes as the signature nodes in response to the transaction request, and after scheduling the private keys of the signature nodes to sign the payment transaction one by one, the scheduling node generates the signature success information and feeds the signature success information back to the communication node. Finally, the communication node performs the payment transaction operation after receiving the signature success information. This embodiment of the present disclosure can combine a cluster technology and a multi-signature technology to build a wallet system completely controlled by a user, so as to realize a transaction adapting to Web3.

Claims (9)

  1. CLAIMS: 1. A wallet system, comprising a communication node, a scheduling node, and at least one backup node, wherein each node stores one private key, and all the private keys are for a same account; the communication node is configured to generate a transaction request based on received payment transaction information and send the transaction request to the scheduling node; the scheduling node is configured to select a plurality of nodes as signature nodes in response to the transaction request; the scheduling node is further configured to: after scheduling private keys of the signature nodes to sign a payment transaction one by one, generate signature success information and feed the signature success information back to the communication node; the communication node is further configured to perform a payment transaction operation after receiving the signature success information; the system further comprises a replacement node; the replacement node is configured to obtain a private-key encryption file of a designated to-be-replaced node from a cloud end in response to a node replacement instruction entered by a user, generate a node replacement request, and send the node replacement request to the scheduling node; the scheduling node is further configured to schedule, in response to the node replacement request, private keys of a plurality of other nodes than the to-be-replaced node to sign the private-key encryption file, such that the replacement node opens the private-key encryption file to obtain a private key of the to-be-replaced node, wherein the private-key encryption file of the to-be-replaced node is generated by encrypting the private key of the to-be-replaced node by using the private keys of the other nodes; and the replacement node is further configured to: after setting the private key of the to-bereplaced node as a private key of the replacement node, generate node change information and send the node change information to the scheduling node, such that the scheduling node is capable of performing node scheduling accurately.
  2. 2. The wallet system according to claim 1, wherein the payment transaction information at least comprises a target transaction amount, and the transaction request at least comprises a target signature mode; and that the communication node is configured to generate the transaction request based on the received payment transaction information specifically comprises: the communication node is configured to obtain the target signature mode based on a preset mapping relationship between a transaction amount and a signature mode and the target transaction amount
  3. 3. The wallet system according to claim 2, wherein the mapping relationship is specifically as follows: a plurality of transaction amount grades are obtained through division based on an amount size when a first transaction amount is greater than a second transaction amount, a grade of the first transaction amount is higher than or equal to a grade of the second transaction amount, and a higher grade leads to more signatures required in the signature mode.
  4. 4. The wallet system according to claim 1, wherein the private key is generated in a following manner: generating, by each node, one private key for the same account in an offline state.
  5. The wallet system according to claim 1, wherein the communication node is further configured to: when the payment transaction information belongs to non-fungible token (NFT) transaction information, generate a transaction record based on the payment transaction operation after completing the payment transaction operation, and update its own account book; and the communication node is further configured to send the transaction record to other nodes, such that the other nodes update their own account books based on the transaction record.
  6. 6. The wallet system according to claim 1, wherein after the communication node sends the transaction request to the scheduling node, and before the scheduling node schedules the private keys of the signature nodes to sign the payment transaction one by one, the scheduling node is further configured to send its own to-be-backed up account book to all backup nodes when the transaction payment information belongs to NFT transaction information, such that the backup nodes reconcile their account books with the to-be-backed up account book and update their own account books, wherein the to-be-backed up account book represents information not synchronized to all other nodes in an account book of the scheduling node.
  7. 7. The wallet system according to claim 1, wherein the communication node is further configured to: when the payment transaction information belongs to cryptocurrency transaction information, generate a transaction record based on the payment transaction operation after completing the payment transaction operation, so as to update a public account.
  8. 8. The wallet system according to claim 1, wherein the system further comprises an inheritance node, wherein a quantity of inheritance nodes is equal to a quantity of abandoned nodes, and the abandoned nodes comprise an abandoned communication node, an abandoned scheduling node, and an abandoned backup node; and a target inheritance node is configured to establish a corresponding relationship between the target inheritance node and an inheritance file stored at the cloud end based on a usemame and a password of one of the abandoned nodes in response to a user login instruction, wherein the target inheritance node is any one of the inheritance nodes; wherein the target inheritance node is further configured to control the cloud end to send the inheritance file to a preset social account of the user in response to a user inheritance instruction, such that the user assigns, based on the inheritance file, a usemame, a password, and a private key that are corresponding to an abandoned node to each of the inheritance nodes, wherein the inheritance file records usernames, passwords, and private keys of all the abandoned nodes
  9. 9. A transaction method based on the wallet system according to any one of claims 1 to 8, comprising: generating, by the communication node, a transaction request based on received payment transaction information, and sending the transaction request to the scheduling node; selecting, by the scheduling node, a plurality of nodes as signature nodes in response to the transaction request; generating, by the scheduling node after scheduling private keys of the signature nodes to sign a payment transaction one by one, signature success information, and feeding the signature success information back to the communication node; performing, by the communication node, a payment transaction operation after receiving the signature success information; obtaining, by the replacement node, a private-key encryption file of a designated to-bereplaced node from a cloud end in response to a node replacement instruction entered by a user, generating a node replacement request, and sending the node replacement request to the scheduling node; scheduling, by the scheduling node in response to the node replacement request, private keys of a plurality of other nodes than the to-be-replaced node to sign the private-key encryption file, such that the replacement node opens the private-key encryption file to obtain a private key of the to-be-replaced node, wherein the private-key encryption file of the to-be-replaced node is generated by encrypting the private key of the to-be-replaced node by using the private keys of the other nodes; and generating, by the replacement node after setting the private key of the to-be-replaced node as a private key of the replacement node, node change information, and sending the node change information to the scheduling node, such that the scheduling node is capable of performing node scheduling accurately.
GB2304532.1A 2022-05-19 2022-10-25 Wallet system and transaction method Pending GB2623142A (en)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
CN202210541275.0A CN114723438B (en) 2022-05-19 2022-05-19 Wallet system and transaction method
PCT/CN2022/127487 WO2023221401A1 (en) 2022-05-19 2022-10-25 Wallet system and transaction method

Publications (2)

Publication Number Publication Date
GB202304532D0 GB202304532D0 (en) 2023-05-10
GB2623142A true GB2623142A (en) 2024-04-10

Family

ID=86228073

Family Applications (1)

Application Number Title Priority Date Filing Date
GB2304532.1A Pending GB2623142A (en) 2022-05-19 2022-10-25 Wallet system and transaction method

Country Status (3)

Country Link
US (1) US20230410092A1 (en)
DE (1) DE112022000111T5 (en)
GB (1) GB2623142A (en)

Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2005203882A (en) * 2004-01-13 2005-07-28 Denso Corp Communication system and key transmitting method
CN111325546A (en) * 2018-12-13 2020-06-23 北京果仁宝软件技术有限责任公司 Block chain transaction system and method based on hardware wallet
US20210357915A1 (en) * 2018-12-30 2021-11-18 Tunnel International Inc. Methods, devices, and systems for secure payments
CN113888148A (en) * 2021-10-22 2022-01-04 支付宝(杭州)信息技术有限公司 Method and device for scheduling resources based on scheduling network
CN114723438A (en) * 2022-05-19 2022-07-08 北京第五力科技有限公司 Wallet system and transaction method

Patent Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2005203882A (en) * 2004-01-13 2005-07-28 Denso Corp Communication system and key transmitting method
CN111325546A (en) * 2018-12-13 2020-06-23 北京果仁宝软件技术有限责任公司 Block chain transaction system and method based on hardware wallet
US20210357915A1 (en) * 2018-12-30 2021-11-18 Tunnel International Inc. Methods, devices, and systems for secure payments
CN113888148A (en) * 2021-10-22 2022-01-04 支付宝(杭州)信息技术有限公司 Method and device for scheduling resources based on scheduling network
CN114723438A (en) * 2022-05-19 2022-07-08 北京第五力科技有限公司 Wallet system and transaction method

Also Published As

Publication number Publication date
US20230410092A1 (en) 2023-12-21
DE112022000111T5 (en) 2024-01-18
GB202304532D0 (en) 2023-05-10

Similar Documents

Publication Publication Date Title
WO2020244231A1 (en) Service processing system and method based on blockchain
WO2022042301A1 (en) Data processing method and apparatus, smart device and storage medium
US11238543B2 (en) Payroll based blockchain identity
US10554413B2 (en) Cross-blockchain authentication method and apparatus, and electronic device
CA3013603C (en) Dynamically managing exchanges of data using a distributed ledger and homomorphic commitments
US20220398576A1 (en) Telecommunication System and Method for Settling Session Transactions
US10798072B2 (en) Password management system and process
US20200005254A1 (en) Blockchain-implemented method for control and distribution of digital content
US20210288819A1 (en) Method for issuing identity certificate to blockchain node and related apparatus
WO2023221401A1 (en) Wallet system and transaction method
WO2020088074A1 (en) Privacy transaction method and apparatus based on blockchain, and application method and apparatus therefor
CN103262466A (en) Authentication system, authentication server, service provision server, authentication method, and computer-readable recording medium
US11038685B1 (en) Correcting blockchain transactions with cryptocurrency type mistakes
CN110601858B (en) Certificate management method and device
CN109299058A (en) Academic storage method, academic querying method and computer storage medium
US11799640B2 (en) Systems and methods for bifurcated blockchain-based digital encryption
JP2018098564A (en) Distributed ledger system and program
CN113011883A (en) Data processing method, device, equipment and storage medium
TW202006569A (en) Digital currency-based ticket counting method and block chain ticket counting system transmitting the current data block to other computer nodes for being stored newly after being verified
CN111008251A (en) Data processing method and equipment
US20230410092A1 (en) Wallet system and transaction method
US20230245118A1 (en) Point-to-point (p2p)-based data processing method and system, computing device, and storage medium
WO2023134259A1 (en) Point-to-point-based data processing method and system, computing device, and storage medium
WO2023233173A1 (en) Implementing self-sovereign identity (ssi) based on configurable individual profiles generated real-time from private attributes stored in the personal secure elements of the users
US20230069098A1 (en) Apparatus and passwords for providing double-sided estate password authentication via physical tokens and a distributed ledger