Account management key derivation

Abstract

Key derivation for account management is disclosed, including: generating an account private key associated with a new account; generating a compute key associated with the new account based at least in part on the account private key, wherein the compute key is usable to validate a new transaction to be confirmed on a blockchain, and wherein the new transaction is initiated by the new account; and generating a view key associated with the new account based at least in part on the account private key, wherein the view key is usable to decrypt a portion of a confirmed transaction on the blockchain belonging to the new account.

Description

BACKGROUND

[0001] Transactions on a blockchain are typically publicly visible. As such, the blockchain can be traversed to reveal activity and token amounts associated with each account. However, public consumption of such information is not conducive to protecting the privacy of users of accounts. It is desirable to enable transactions on a blockchain to protect privacy, and thus the security of accounts participating in the blockchain. BRIEF DESCRIPTION OF DRAWINGS

[0002] Various embodiments of the present invention are disclosed in the detailed description and drawings below.

[0003] Figure 1 FIG. 1 is a diagram illustrating an embodiment of a system for generating and using key derivation for account management.

[0004] Figure 2 FIG. 2 is a diagram illustrating an example of a client device, according to some embodiments.

[0005] Figure 3 FIG. 3 is a diagram illustrating a path of deriving a key from an account private key corresponding to an account, according to some embodiments.

[0006] Figure 4 FIG. 4 is a flowchart illustrating an embodiment of a process for deriving a key for managing an account.

[0007] Figure 5 FIG. 5 is a flowchart illustrating an example of a process for deriving a key from an account private key associated with an account, according to some embodiments.

[0008] Figure 6 FIG. 6 is a flowchart illustrating an example of a process for creating a transaction, according to some embodiments.

[0009] Figure 7 FIG. 7 is a diagram illustrating an example of a transaction created by a sender account, according to some embodiments.

[0010] Figure 8 FIG. 8 is a flowchart illustrating an example of a process for transaction viewing, according to some embodiments.

[0011] Figure 9 FIG. 9 is a flowchart illustrating an example of a process for tracking trends in transactions, according to some embodiments. DETAILED DESCRIPTION

[0012] The application can be implemented in numerous ways, including as a process; an apparatus; a system; a composition of matter; a computer program product of a computer readable storage medium embodying computer program instructions; and / or a processor, such as a processor configured to execute instructions stored on and / or provided by a memory coupled to the processor. In this specification, these implementations, or any other form that the application can take, can be referred to as techniques. In general, the order of the steps of disclosed processes can be altered, except where such alteration would necessarily fail to yield a functionally or structurally equivalent result. Unless otherwise indicated, components described as being configured to perform a task can alternatively be configured to perform the task based on instructions received from another component. As used in this specification, the term "processor" refers to one or more devices, circuits, and / or processing cores configured to process data, such as computer program instructions.

[0013] A detailed description of one or more embodiments of the application is provided below along with accompanying figures that illustrate the principles of the application. The application is described in connection with such embodiments, but the application is not limited to any embodiment. The scope of the application is limited only by the claims and the application encompasses numerous alternatives, modifications and equivalents. Numerous specific details are set forth in the following description in order to provide a thorough understanding of the application. These details are provided for the purpose of example and the application can be practiced according to the claims without some or all of these specific details. For the purpose of clarity, technical material that is known in the technical fields related to the application has not been described in detail so that the application is not unnecessarily obscured.

[0014] Embodiments of key derivation for account management are described herein. In various embodiments, a request to open a new account for engaging in transactions on a blockchain is received. In response to the request, an "account private key" associated with the new account is generated. Then, a "computational key" associated with the new account is generated based at least in part on the account private key. Further, a "viewing key" associated with the new account is generated based at least in part on the account private key. As will be described in further detail below, the computational key can be used to verify new transactions to be confirmed on the blockchain and that the new transactions were initiated by the new account. The viewing key can be used to decrypt a portion of confirmed transactions on the blockchain that belong to the new account. In various embodiments, each of the computational key and the viewing key can be individually used to derive an "account address," which can also be referred to as a "public key" that publicly identifies the new account. Although the account private key can perform all functions related to the derived keys (e.g., the computational key and the viewing key), which are derived from the account private key and are thus highly sensitive, neither of the derived keys can be used, alone or in combination, to recover the account private key. Further, each of the derived keys cannot be used to recover any other key that is directly derived from the account private key nor perform a function associated with any other derived key. By separating / splitting the functions of the account private key of an account into several derived keys, the derived keys can be delegated to trusted third parties to perform different transaction functions on behalf of the account for transactions on the blockchain without the need to directly share the highly sensitive account private key.

[0015] Figure 1 FIG. 1 is a diagram illustrating an embodiment of a system for generating and using key derivation for account management. As shown in FIG. 1, the system 100 includes a client device 102, a proof generation server 104, a transaction scanning server 106, a trend analysis server 108, a blockchain network 110, and a network 112. The network 112 includes a data and / or telecommunication network. Figure 1

[0016] ​The client device 102 is configured to execute computer program code associated with a standalone software application or a web browser-based application that is configured to generate and use cryptographic keys associated with managing accounts that participate in transactions on the blockchain 110. Examples of the client device 102 can be a mobile device, a laptop, a desktop computer, a tablet device, or any other computing device. A user (not shown) can interact with a user interface associated with the application executing at the client device 102 to open a new account. In response to user input to open a new account, the application is configured to generate a new “account private key” (sometimes referred to simply as a “private key”). In some embodiments, the new private account key is generated based on a seed value and a hash value determined based on concatenations that include the seed value. As will be described in further detail below, the new private account key can include two or more elements (e.g., each element can be represented in 32 bytes). The account private key of the user (new account holder) can be used to perform various functions related to transactions on the blockchain 110. Some examples of such functions include authorizing transactions (e.g., disbursement of tokens associated with the new account), decrypting portions of confirmed transactions on the blockchain 110 to determine which transactions are related to the new account, and determining patterns associated with confirmed transactions on the blockchain 110 that were initiated by the new account. Thus, the account private key is a powerful and sensitive piece of information that ideally should not be shared with other users or devices to reduce the risk of unauthorized transactions associated with the new account.

[0017] After the application executing at the client device 102 generates the account private key for the new account, the application is configured to derive one or more other keys corresponding to the new account directly or indirectly from the account private key. A first key corresponding to the new account and derivable from the account private key is an “account computation key” or simply a “computation key.” The computation key can be included in every account signature and used to perform zero-knowledge proofs related to transactions. In various embodiments, the computation key can also be used to verify signatures associated with transactions initiated using the account private key. The computation key can only be shared with trusted parties. A second key corresponding to the new account and derivable from the account private key is an “account view key” or simply a “view key.” The view key can be used to decrypt all transactions belonging to the new account. The view key can only be shared with trusted parties. Neither the view key nor the computation key can perform the other’s capabilities / functions. In some embodiments, a third key corresponding to the new account and derivable from the view key, which is derived from the account private key, is an “account graph key” or simply a “graph key.” The graph key can be used to compute labels to be included in transactions, which can then be used to identify transactions belonging to the new account at a high level to detect patterns across transactions (e.g., spending of tokens). The graph key should only be shared with trusted parties. A fourth key corresponding to the new account and derivable from the view key, which is derived from the account private key, is an “account address,” “address,” or “public key.” The address is a public identifier for the new account and can be publicly shared. For example, another account wanting to perform a transaction with the new account will need to specify the address of the new account in the transaction. For example, the address of the new account can be shared with another device that causes the transaction.

[0018] To initiate a transaction to be confirmed by the blockchain network 110, the user of the new account will enter parameters associated with the transaction in a user interface of the application executed at the client device 102. For example, if the transaction involves a consumption token associated with the new account, the parameters associated with the transaction can include identification information associated with one or more confirmation records on the blockchain network 110 that record what the new account owns. These confirmation records will be included by the application as one or more input records in the transaction. In addition, in this example, the user input parameters will also include at least the number of tokens the user wishes to send to a recipient and at least one output record (to be confirmed by the blockchain network 110) that specifies an account address (public key) of the recipient, a program to execute, and the number of tokens to send to the recipient, which will be included by the application as an output record in the transaction. In some embodiments, each output record is also encrypted using the recipient account address included in the output record. In various embodiments, the application at the client device 102 generates a signature based at least on the locally generated account private key corresponding to the new account and at least a portion of the transaction (e.g., the one or more input records and / or the one or more output records). In some embodiments, the application executed at the client device 102 is also configured to generate a zero-knowledge proof using the signature, the computed key, and at least a portion of the input and / or output records (e.g., the account address / public key of the new account initiating the transaction). In this case, the “zero-knowledge proof” verifies that the signature actually belongs to the user associated with the new account without revealing the signature itself (or the computed key and record contents) to the verifier (e.g., a node of the blockchain network 110). In some embodiments, the application at the client device 102 generates a label based at least on the graph key corresponding to the new account and at least a portion of the transaction (e.g., the one or more output records). The label can be used by the holder of the graph key to identify transactions associated with the new account, but does not provide detailed information of such transactions (e.g., because the output records of such transactions are encrypted and cannot be decrypted using the graph key). In various embodiments, the transaction including the set of one or more input records, the set of output records, the zero-knowledge proof, and optionally one or more labels is sent by the client device 102 to the blockchain network 110 for nodes of the blockchain network to confirm and thus validate the one or more output records and add the valid / confirmed one or more output records to the ledger.

[0019] As described above, during the process of creating a transaction initiated by the new account holder at the client device 102, a zero-knowledge proof needs to be generated using the signature associated with the new account. Generating the zero-knowledge proof can be computationally intensive, especially when the client device 102 is a mobile device with limited computing resources. Therefore, in some embodiments, the client device 102 can delegate / shift the process of generating the zero-knowledge proof associated with the transaction to a third-party server, such as the proof generation server 104, by sending at least the signature and / or a portion of the transaction, the computation key, and / or data derived from the signature and / or the transaction to the proof generation server 104, so that the proof generation server 204 generates the entire zero-knowledge proof or completes the later stages of the zero-knowledge proof generation. Thus, the proof generation server 104 can generate at least a portion of the zero-knowledge proof to free up resources at the client device 102 and then send the generated proof to the client device 102.

[0020] After transactions initiated by parties other than the new account holder are confirmed by the blockchain network 110, the application executing at the client device 102 can use the locally derived viewing key corresponding to the new account to determine which, if any, of the confirmed transactions are related to the new account. As described above, during the process of creating a transaction initiated by the new account holder (the sender account) at the client device 102, the transaction output records describing the nature of the transaction and the recipient of the transaction are encrypted using the recipient’s account address (the recipient’s public key). The encrypted output records can only be decrypted and viewed using the viewing key corresponding to the same account, and thus, only entities having a copy of the viewing key can decrypt the encrypted output records of the transactions and learn the nature of these transactions (e.g., how many tokens the corresponding sender account sent to the recipient). In other words, entities that do not have the viewing key corresponding to the recipient’s account of the encrypted output records of the confirmed transactions cannot decrypt these output records. By using asymmetric encryption in this way, entities other than those entrusted with a copy of the viewing key corresponding to the account cannot see / learn about transactions in which the account is a party.

[0021] While the application executing at client device 102 can (periodically) download encrypted output records of transactions confirmed by blockchain network 110 and then use a locally derived viewing key to determine which output records it can decrypt (if any), in some embodiments, the application can delegate the service of checking which confirmed transactions a new account is the recipient of to a third-party server, such as transaction scanning server 106. For example, delegating the service of checking which confirmed transactions a new account is the recipient of to transaction scanning server 106 includes sending a viewing key to transaction scanning server 106 so that transaction scanning server 106 can continuously (e.g., at regular intervals or in response to events) download encrypted output records of confirmed transactions from blockchain network 110, and then use the obtained viewing key to determine which of these output records can be decrypted using the viewing key. Then, for those output records that transaction scanning server 106 can decrypt, transaction scanning server 106 can determine the nature of those transactions for which the new account is the recipient, and then send a message (e.g., in the form of a push notification) to client device 102 to notify the account holder of these transactions. In this way, transaction scanning server 106 can continue to scan (e.g., new) confirmed transactions at blockchain network 110 to identify those transactions associated with the new account, even when client device 102 is offline (e.g., no confirmed output records have been downloaded from the blockchain network for any reason).

[0022] As described above, during the process of creating a transaction initiated by a new account holder at client device 102, a tag can be generated using a graph key corresponding to the new account, which is also included in the transaction. In some embodiments, client device 102 may delegate the service of checking trends / patterns among transactions with tags generated based on the graph key to a third-party server, such as trend analysis server 108. For example, delegating the service of checking trends / patterns among transactions with tags generated based on the graph key includes sending the graph key to trend analysis server 108, enabling trend analysis server 108 to download confirmed transactions from blockchain network 110 and determine those transactions that include tags determined based on the graph key. Trend analysis server 108 is configured to audit transactions, for example, by analyzing (e.g., by applying machine learning models and / or using clustering) transactions to determine patterns in transactions that include tags generated by the graph key. For example, these patterns may indicate anomalous transactions, which may indicate hacking or other malicious behavior. However, since only the graph key is available and there is no viewing key corresponding to the new account, trend analysis server 108 cannot decrypt and view the details of the encrypted output record of the transaction. In some cases, the trend analysis server 108 can alert another entity (e.g., client device 102, transaction scanning server, or another server) that holds the viewing key, informing it of those transactions that have been identified as anomalous. This allows the notified entity to use the viewing key to decrypt the encrypted output records of these transactions for a more thorough examination to determine if they indicate suspicious behavior.

[0023] Therefore, in system 100, keys derived from the account private key associated with the account can be used to segment the various capabilities that the account private key can perform. However, these derived keys cannot perform each other's functions, nor can they be used to recover the account private key individually. Therefore, derived keys can be shared with different trusted parties to delegate / transfer services to be performed by these parties without concern that these parties could recover the account private key. By deriving and using derived keys from the account private key as described in the various embodiments herein, the leakage of highly sensitive account private keys can be prevented, while still providing the flexibility to potentially utilize third parties to perform at least some tasks associated with account management on behalf of the account for transactions at the blockchain.

[0024] Figure 2 This is a diagram illustrating an example of a client device according to some embodiments. In some embodiments, Figure 1 System 100's client device 102 can use Figure 2 This is implemented using an example client device. For example... Figure 2As shown, the client device includes a key generation engine 202, a key storage 204, a transaction creation engine 206, a transaction viewing engine 208, and a delegation engine 210. Each of the key generation engine 202, key storage 204, transaction creation engine 206, transaction viewing engine 208, and delegation engine 210 can be implemented using software and / or hardware.

[0025] Key generation engine 202 is configured to generate account private keys for accounts (e.g., in response to a request to create a new account). After generating account private keys for an account, key generation engine 202 is configured to derive keys directly from the account private keys, including a view key and a computed key corresponding to the account. The view key can be used to decrypt one or more output records associated with a transaction confirmed by the blockchain network. The computed key can be used to verify the signature associated with a transaction initiated using the account private key. In some embodiments, confirmation key generation engine 202 derives a graph key corresponding to the account from the view key. The graph key is used to generate a tag based on one or more records associated with a transaction and to identify the transaction to the holder of the graph key, but for records without a view key, these records are not decrypted. Key generation engine 202 can derive the account address (public key) corresponding to the account from the view key or the computed key. Unlike other keys corresponding to the account, the account address is a public identifier of the account and can be freely shared with others (e.g., so that they can use the account's address to initiate transactions involving the account). For example, the key generation engine 202 can share an account address by sending the account address to one or more other devices, where another account holder can be a counterparty to the account address holder in a transaction.

[0026] Key storage 204 is configured to store all keys associated with each account (e.g., locally generated by key generation engine 202). For example, keys associated with each account include the account's private key, computation key, viewing key, graph key, and account address (account's public key). The keys corresponding to an account can be used locally on the client device to create transactions and / or view confirmed transactions. Copies of at least some of the keys corresponding to an account can also be sent to a third-party server (e.g., via delegation engine 210), enabling third-party services to perform computationally intensive services on behalf of the account and / or utilize services provided by the third-party server.

[0027] Transaction creation engine 206 is configured to create transactions initiated by an account holder using their account private key. To initiate a transaction, the account holder can input parameters that identify zero or more confirmed records in the blockchain's public ledger as one or more input records. To initiate a transaction, the account holder can also input parameters for one or more output records, detailing what / who the transaction will affect, such as the account address of the transaction recipient and the nature of the transaction (e.g., token transfer or smart contract execution). In various embodiments, transaction creation engine 206 is configured to encrypt each output record using the recipient's account address (which is also included in the output record), such that only parties with a viewing key associated with the recipient's account address can decrypt and view the contents of the output record after the transaction is confirmed on the blockchain network. In some embodiments, transaction creation engine 206 is configured to generate a cryptographic signature corresponding to the transaction using the account private key and at least a portion of one or more records included in the transaction. In some embodiments, transaction creation engine 206 is configured to input a signature associated with a transaction and at least a computational key corresponding to an account into a zero-knowledge proof generation technique, such that a zero-knowledge proof can be generated to prove (e.g., to a validator including one or more nodes at a blockchain network) that the signature does indeed belong to an account holder associated with the sender account address included in the transaction. In other words, the zero-knowledge proof proves that the sender account did indeed authorize the transaction. In some embodiments, transaction creation engine 206 is configured to use a graph key corresponding to the account to generate a record-level tag or transaction-level tag corresponding to the transaction. Transaction creation engine 206 is configured to "tag" the transaction by including the tag in the transaction, such that the tag can later be used to identify the transaction as belonging to the sender account of the transaction. As will be further described below, transaction creation engine 206 is configured to create a transaction including zero or more confirmed input records, one or more unconfirmed sub-output records, (optionally) a tag, and a zero-knowledge proof, and then send the transaction to the blockchain network for confirmation, such that its output record is added to the ledger.

[0028] Transaction viewing engine 208 is configured to attempt to decrypt encrypted output records associated with confirmed transactions on the blockchain using a viewing key corresponding to an account, in order to identify output records that identify the account as the transaction recipient (if any). In some embodiments, transaction viewing engine 208 is configured to periodically or in response to an event (e.g., a user inspection instruction) download output records associated with (most recently) confirmed transactions on the blockchain. Transaction viewing engine 208 is then configured to attempt to decrypt one or more encrypted output records associated with each confirmed transaction to determine if the output record can be decrypted. As described above, the sender / creator of the transaction encrypts each output record of the transaction using the account address (public key) of the recipient of the output record, and the encrypted output record can only be decrypted using the recipient's viewing key. Therefore, transaction viewing engine 208 can only decrypt output records encrypted using the account's viewing key. In other words, transaction viewing engine 208 can only successfully decrypt encrypted output records where the account holder of the viewing key is the recipient. In some embodiments, for each output record successfully decrypted by the transaction viewing engine 208, the transaction viewing engine 208 is configured to generate and present a prompt at the display (not shown) of the client device to notify the user / account holder of the type of transaction to which the user has been identified as the recipient. For example, if an output record successfully decrypted by the transaction viewing engine 208 indicates that a sender has sent five tokens to the user, the transaction viewing engine 208 is configured to present a message or prompt at the display of the client device indicating that the user has received five tokens from the sender (e.g., this could be determined by the transaction viewing engine 208 from the input record of the same transaction, since the input record is not encrypted and is therefore viewable).

[0029] The delegation engine 210 is configured to, during the delegation process, send copies of keys derived from an account's private key or data derived from those keys to other devices or servers for execution by other entities in the process, such as transaction creation, transaction viewing, and transaction trend analysis. In the first example of delegation, as described above, during the process of creating a transaction initiated by the account holder (e.g., executed by the transaction creation engine 206), it is necessary to generate a zero-knowledge proof based on one or more of the following: a signature derived from the account's private key, a computation key derived from the account's private key, the account address associated with the account, and at least a portion of the record associated with the transaction. However, generating zero-knowledge proofs can be resource-intensive; therefore, the delegation engine 210 can delegate the generation of this proof to a third-party server (e.g., Figure 1The proof generation server 104. For example, the delegation engine 210 may delegate the generation of zero-knowledge proofs to a third-party server in response to a user instruction or in response to determining that the available computing resources locally available on the client device are less than a predetermined threshold. To delegate the generation of zero-knowledge proofs to a third-party server, the delegation engine 210 is configured to send one or more of a signature, a computation key, and at least a portion of a transaction to the third-party server. After receiving the zero-knowledge proof from the third-party server, the delegation engine 210 is configured to send the proof to the transaction creation engine 206, so that the transaction creation engine 206 can complete the transaction before sending it to the blockchain network for confirmation.

[0030] In the second example of delegation, to view transactions associated with an account (e.g., which could be performed by transaction viewing engine 208), the output records of newly confirmed transactions are continuously downloaded from the blockchain, and then it is determined which records can be decrypted using the viewing key corresponding to the account. However, if there are a large number of such transactions, or if the client device is unable to connect to the blockchain for any reason, continuous monitoring of newly confirmed transactions at the blockchain can also be resource-intensive. Therefore, delegation engine 210 can delegate the inspection of related transactions to a third-party service. For example, delegation engine 210 can delegate transaction monitoring to a third-party server in response to a user instruction or in response to determining that the available computing resources locally available on the client device are less than a predetermined threshold. To delegate transaction monitoring to a third-party server, delegation engine 210 is configured to send the viewing key to the third-party server (e.g., Figure 1 (Transaction scanning server 106). This allows the third-party server to continue examining account-related transactions even when the client device is offline (e.g., not connected to the blockchain). When the third-party server identifies an account-related transaction (because the transaction includes at least one output record that can be decrypted using a viewing key), the third-party service can send at least a portion of the decrypted output record to the transaction viewing engine 208 to display a prompt or message (e.g., a push notification) on the client device's display.

[0031] In the third example of delegation, to examine trends, but not necessarily to view data related to transactions about an account, a graph key corresponding to the account can be used to regenerate tags associated with the account, and transactions including that tag can be identified as account-related. Because using the graph key to generate these account-related tags, finding blockchain-confirmed transactions, and then analyzing transaction patterns can be resource-intensive and / or of interest to third parties (such as auditors), the delegation engine 210 can delegate the service of analyzing such transaction trends to a third-party server. To delegate the analysis of transaction trends to a third-party server, the delegation engine 210 is configured to send the graph key to the third-party server (e.g., ...). Figure 1(Trend analysis server 108). In this way, the third-party server can use graph keys to generate tags and find transactions that include such tags, then analyze the trends or anomalous behavior of the transactions. When the third-party server identifies a transaction that may indicate anomalous activity, it can send a message to the client device to notify the user, and, for example, the user instructs the delegation engine 210 to send the viewing key along with the tagged transaction to another third-party server. This allows the second third-party server to decrypt the transaction and examine its nature to determine if any malicious activity is involved.

[0032] Figure 3 This is a diagram illustrating the path of deriving a key from the account private key corresponding to an account, according to some embodiments. As mentioned above, the account private key is highly sensitive, capable of authorizing transactions (e.g., token spending or smart contract authorization) and other functions on behalf of the account, and should therefore be kept confidential by the account holder (not shared with any other party). The computation key can be directly derived from the account private key, and can be used to verify the signature associated with the created transaction. The computation key can be shared with a trusted third party to perform signature verification (e.g., during the process of generating a zero-knowledge proof). The account private key cannot be recovered from the computation key because, mathematically, it is impossible to recreate the account private key using the computation key, as shown in further detail below. The viewing key can be directly derived from the account private key, and can be used to view transactions in which the account holder is the recipient. The viewing key can be shared with a trusted third party to monitor confirmed transactions, thereby determining which transactions the account holder is the recipient of. The account private key cannot be recovered from the viewing key because, mathematically, it is impossible to recreate the account private key using the viewing key, as shown in further detail below. Graph keys can be derived from view keys and can be used to identify transactions with tags generated using graph keys. Account private keys cannot be recovered from graph keys because graph keys are derived from view keys, and view keys cannot be used to recover account private keys. Account addresses (public keys) can be derived from either computed keys or view keys. Addresses are the public identifier of an account and can be shared with any party (e.g., allowing another party to execute transactions with the account as a recipient). Account private keys cannot be recovered from addresses because addresses are derived from either view keys or computed keys, neither of which can be used to recover account private keys.

[0033] The private key and address are the key and public key of an elliptic curve-based signature scheme. In some embodiments, the private key can sign on behalf of the address, while the look-through key can decrypt on behalf of the address. The address is associated with the signature and is used to encrypt arbitrary data. The look-through key and address is an asymmetric public-key scheme, where the look-through key is the decryption key and the address is the encryption key.

[0034] likeFigure 3 As shown, by indirectly deriving the account's address (public key) from the account's private key, the address is decoupled from the private key. Furthermore, recovering the account's private key from the address becomes mathematically and practically impossible, enhancing the security of sensitive account private keys. Additionally, as... Figure 3 The key relationships / derivations shown illustrate how different permissions that an account's private key can use can be split into multiple derived keys to allow the derived keys to be delegated to (e.g., different) trusted parties, thereby allowing the delegator to perform tasks associated with each permission.

[0035] The following are examples of generating account private keys and deriving keys from account private keys according to some implementation examples:

[0036] The following description uses the definitions of the following mathematical objects:

[0037] Finite field of prime numbers: For a prime number r, a finite field It consists of integers {0, 1, ..., r}. There are two related operations: addition modulo r and multiplication modulo r. In this paper, we will use two finite fields of prime numbers: prime order p, and The prime order is q. In some embodiments, q > p.

[0038] Elliptic curve group of prime order: In this paper, we will consider the base field The p-order subgroup of points on the elliptic curve defined above. The elements of this subgroup consist of coordinate pairs (x, y). The group has two associated operations: point addition and point doubling. The group also has a unique point, the generator G, which is a fixed point of the group. In some embodiments, the generator is derived using the "HashToCurve" algorithm, but any arbitrary point in the prime-order subgroup is sufficient.

[0039] For finite fields It is a cryptographic hash function that takes a sequence of bytes or elements as input and outputs a sequence of elements.

[0040] HashToScalar: Outputs scalar fields The instantiation of the HashToField of the element in the dataset. In some embodiments, the HashToScalar function is a "Poseidon" hash function (with... (operations on), and the output is truncated to fit In some other embodiments, the HashToScalar function includes other cryptographic hash functions, such as SHA256 or SHA512.

[0041] It encodes the bit string x into a finite field. Functions of elements.

[0042] Account private key generation

[0043] In some embodiments, a generator may be generated comprising two components (sk) sig ,r sig The account private key is referred to as "Variation A". In some other embodiments, the account private key can be generated to include three components (sk... sig ,r sig ,sk vrf This is called "Variation B". Each variant of the account private key will have a corresponding derivation of the computation key, view key, graph key, and address. Variants A and B are described below:

[0044] Variant A(sk) sig r sig )

[0045] function PrivateKey.New():

[0046] 1. By from Select a random value from the base field and sample “seed” from the base field {0, 1, ..., q}.

[0047] / / The ASCII-encoded byte sequence (forming an integer) including the predefined value "AccountSignatureSecretKey0" is encoded as a division by q. The members, therefore, the remainder are The values ​​within the base field {0, 1, ..., q-1}. Then... The remainder in the base field is concatenated with the "seed" value, and this concatenation is fed into the HashToScalar() function to map the input to... Members of the scalar field {0,1,...,p-1}, where q and p are prime numbers and q>p.

[0048] / / The ASCII-encoded byte sequence (forming an integer) including the predefined value "AccountSignatureRandomizer0_0" is encoded as a division by q. The members of b, therefore, the remainder is The values ​​within the base field {0, 1, ..., q-1}. Then... The remainder in the base field is concatenated with the "seed" value, and this concatenation is fed into the HashToScalar() function to map the input to... Members of the scalar field {0, 1, ..., p-1}. sig The alternative derivation can be r sig =seed||r sig , where "counter sig "This is a pre-set value."

[0049] 4. Output(seed,(sk sig ,r sig )) / / “seed” is Members of the base field {0, 1, ..., q-1}, and sk sig and r sig Each of them is Members of the scalar field {0, 1, ..., p-1}. seed and sk sig and r sig Each of them can be represented by 32 bytes.

[0050] As described below, variant B is similar to variant A, except that it includes an additional component sk. vrf .

[0051] Variant B(sk) sig ,r sig ,sk vrf )

[0052] function PrivateKey.New():

[0053] 1. Seed←F base / / Same as variant A

[0054] 2. / / Same as variant A.

[0055] 3. / / Same as variant A.

[0056] 4. The ASCII-encoded byte sequence (forming an integer) including the predefined value "AccountVRFSercretKey0" is encoded as a division by q. The members, therefore, the remainder are The values ​​within the base field {0, 1, ..., q-1}. Then... The remainder in the base field is concatenated with the "seed" value, and this concatenation is fed into the HashToScalar() function to map the input to... Members of the scalar field {0,1,...,p-1}.

[0057] 5. Output(seed,(sk sig ,r sig ,sk vrf )) / / seed is Members of the base field {0, 1, ..., q-1}, and sk sig ,r sig and SK vrf Each one is Members of the scalar field {0, 1, ..., p-1}. seed and sk sig ,r sig and SK vrf Each of them can be represented by 32 bytes.

[0058] In some embodiments, any variant of the account private key's component sk sig and r sig These components (along with generator G) can be used to authorize transactions from associated account holders, as they can be used to generate a signature corresponding to the transaction. This signature will then be used to verify the transaction on the blockchain.

[0059] Computational key generation

[0060] In some embodiments, the computed key associated with the account private key can be based on two components (sk sig r sig As mentioned above, these two components are derived from "Variation A" of the account private key. In some embodiments, the computation key associated with the account private key may be based on three components (sk... sig r sig ,sk vrf As mentioned above, these three components are derived from "Variant B" of the account's private key.

[0061] Variant A(sk) sig ,r sig )

[0062] The function ComputeKey.FromPrivateKey(sk sig ,r sig ):

[0063] 1.key compute =(sk sig ·G,r sig ·G) / / As mentioned above, G is a selected generator on the elliptic curve, so every other element of the elliptic curve can be obtained by repeatedly applying group operations to G. Scalar multiplication sksig G is the addition of G to itself sk. sig Scalar multiplication r sig G is G added to itself r sig Since G is a group element that includes (x, y) coordinates, the result of each scalar multiplication is also (x, y) coordinates, where each of x and y is derived from... Members of the base field {0,1,...,q-1}.

[0064] 2. Output key compute / / key compute It includes two group elements. Specifically, each group element is a corresponding (x, y) coordinate, and each of x and y is a... Members of the base field {0, 1, ..., q-1}. compute Each element (x or y coordinate) can be represented using 32 bytes.

[0065] As described below, the computation key associated with variant B is similar to that of variant A, except that it includes an additional component sk. vrf .

[0066] Variant B(sk) sig ,r sig ,sk vrf )

[0067] The function ComputeKey.FromPrivateKey(sk sig ,r sig ,sk vrf ):

[0068] 1.key compute =(sk sig ·G,r sig ·G,sk vrf ·G) / / Similar to variant A, but includes an additional component, namely scalar multiplication sk vrf ·G.

[0069] 2. Output key compute / / key compute It consists of three group elements. Specifically, each group element is a corresponding (x, y) coordinate, where x and y are derived from... Members of the base field {0, 1, ..., q-1}. compute Each element (x or y coordinate) can be represented using 32 bytes.

[0070] Account View Key Generation

[0071] In some embodiments, the viewing key associated with the account private key can be based on two components (sk sig r sig As mentioned above, these two components are derived from "Variation A" of the account private key. In some embodiments, the viewing key associated with the account private key can be based on three components (sk... sig ,r sig ,sk vrf As mentioned above, these three components are derived from "Variant B" of the account's private key.

[0072] Variant A(sk) sig ,r sig )

[0073] The function ViewKey.FromPrivateKey(sk sig ,r sig ):

[0074] 1.key view =sk sig +r sig +HashToScalar(sk sig ·G||r sig ·G) / / “sk sig ·G||r sig ·G” to sk sig ·G and r sig The product of the corresponding scalar multiplication of G is performed with separate joins for the x and y components. The resulting join group elements, including (x, y), are then fed into the HashToScalar() function to output the result. Members of the scalar field {0,1,…,p-1}. sig +r sig +HashToScalar(sk sig ·G||r sig The remainder when the sum of G) is divided by p is the key to view the key. view It is a scalar Members of the field {0,1,...,p-1}.

[0075] 2. Output key view / / key view yes Members of the scalar field {0, 1, ..., p-1}. view It can be represented using 32 bytes.

[0076] As described below, the computation key associated with variant B is similar to that of variant A, except that it includes an additional component sk. vrf .

[0077] Variant B(sk) sig ,r sig ,sk vrf )

[0078] The function ViewKey.FromPrivateKey(sk sig ,r sig ,sk vrf ):

[0079] 1.key view =sk sig +r sig +HashToScalar(sk sig ·G||r sig ·G||sk vrf ·G) / / “sk sig ·G||r sig ·G||sk vrf ·G” to sk sig ·G,r sig ·Gsk vrf The product of the corresponding scalar multiplication of G performs a separate join of the x and y components. Then, the resulting join group elements, including (x, y), are fed into the HashToScalar() function to output the result. Members of the scalar field {0,1,…,p-1}. sig +r sig +HashToScalar(sk sig ·G||r sig The remainder when the sum of G) is divided by p is the key to view the key. view It is Members of the scalar field {0,1,...,p-1}.

[0080] 2. Output key view / / key view yes Members of the scalar field {0, 1, ..., p-1}. view It can be represented using 32 bytes.

[0081] Graph Key Derivation

[0082] In some embodiments, as described above, a graph key associated with an account private key can be generated based on a view key derived from "Variant A" of the account private key. In some embodiments, as described above, a graph key associated with an account private key can be generated based on a view key derived from "Variant B" of the account private key.

[0083] Variants A and B

[0084] The function GraphKey.FromPrivateKey(key) view ):

[0085] 1. / / The ASCII-encoded byte sequence (forming an integer) including the predefined value "GraphKey0" is encoded as follows: The members, therefore, the remainder are The values ​​within the base field {0, 1, ..., q-1}. Next, this remainder is compared with the key value (key). view (This can be derived from variable A or B of the account's private key) and linked with the value "counter", which is The predefined members selected from the base field {0, 1, ..., q-1}. In some embodiments, a "counter" is also provided as an input parameter to the GraphKey.FromPrivateKey() function. The join is then hashed using the HashToBase() function to determine the graph key. graph .

[0086] 2. Output key graph / / key graph yes Members of the base field {0, 1, ..., q-1}, and can be represented by 32 bytes.

[0087] Account address

[0088] In some embodiments, as described above, an account address associated with an account private key can be generated based on a viewing key derived from "Variant A" of the account private key. In some embodiments, as described above, an account address associated with an account private key can be generated based on a viewing key derived from "Variant B" of the account private key.

[0089] Variants A and B

[0090] The function Address.FromPrivateKey(key) view ):

[0091] 1. address = key view ·G / / View key view It is a scalar multiplied by G, which is the coordinate of a selected point ((x, y) on the elliptic curve).

[0092] 2. Output address / / Account address The address is a group of elements including (x, y) coordinates, and each element (x or y) includes... Members of the base field {0, 1, ..., q-1}. Each element can be represented using 32 bytes.

[0093] In some embodiments, as described above, an account address associated with an account private key can be generated based on a computational key determined from "Variant A" of the account private key. In some embodiments, as described above, an account address associated with an account private key can be generated based on a computational key determined from "Variant B" of the account private key.

[0094] Variant A(sk) sig ,r sig )

[0095] The function Address.FromComputeKey(key) compute =(sk sig ·G,r sig ·G)):

[0096] 1.s = HashToScalar(sk sig ·G||r sig ·G) / / sk sig ·G and r sig The join of G is fed into the HashToScalar function to obtain the join from... The scalar field {0,1,…,p-1} outputs s.

[0097] 2. address = sk sig ·G+r sig ·G+s·G / / sk sig ·G+r sig The sum of G+s and G is an address. In some embodiments, sk is... sig ·G++r sig ·The sum of G divided by q, to ​​obtain from The scalar field {0, 1, ..., q-1} obtains its value as an address.

[0098] 3. Output address / / Account address The address is a group of elements including (x, y) coordinates, and each element (x or y) includes... Members of the base field {0, 1, ..., q-1}. Each element can be represented using 32 bytes.

[0099] Variant B(sk) sig ,r sig ,sk vrf )

[0100] The function Address.FromComputeKey(key) compute =(sksig ·G,r sig ·G,sk vrf ·G)):

[0101] 1.s = HashToScalar(sk sig ·G||r sig ·G||sk vrf ·G) / / Similar to variant A.

[0102] 2.ddress=sk sig ·G+r sig ·G+s·G / / Similar to variant A.

[0103] 3. Output address

[0104] Figure 4 This is a flowchart illustrating an embodiment of a process for deriving a key used to manage an account. In some embodiments, process 400 can be performed on a client device (such as...). Figure 1 Implemented at client device 102).

[0105] At 402, generate the account private key associated with the new account. In response to the request to generate a new account received at the client device, generate the account private key at the client device.

[0106] In a 404 error, a computational key associated with the new account is generated, at least in part, based on the account's private key. This computational key can be used to verify a new transaction to be confirmed on the blockchain, where the new transaction was initiated by the new account. The computational key is derived from the account's private key in such a way that it is mathematically unlikely to be recovered from the computational key. Therefore, the entity that receives only the computational key cannot recover it and thus cannot obtain the permissions associated with the account's private key. In some embodiments, the computational key corresponding to the new account is used to verify a signature (e.g., a signature generated using the account's private key) corresponding to a transaction initiated by the new account holder, at least in part, based on a portion of the transaction. In some embodiments, the signature, computational key, and at least some records of the transaction are used to generate a zero-knowledge proof associated with the transaction. This zero-knowledge proof proves to the verifier the existence of one or more input records (generated as outputs of previously confirmed transactions), whose sequence numbers are correctly derived, and whose signatures correspond to these input records are correct. The zero-knowledge proof also ensures the correct construction of the output record. Furthermore, the zero-knowledge proof hides from the verifier which input records, signatures, computational keys, addresses of the input records, and the contents of all records were used. The zero-knowledge proof is then added to the transaction and sent to the blockchain network. The nodes of the blockchain network will at least verify the zero-knowledge proof during the process of confirming whether the output record of the transaction should be added to the blockchain ledger.

[0107] At 406, a view key associated with the new account is generated, at least in part, based on the account's private key. This view key can be used to decrypt a portion of a confirmed transaction belonging to the new account on the blockchain. The view key is derived from the account's private key in such a way that it is mathematically unlikely to be recovered from the view key. Therefore, an entity that only receives the computed key cannot recover it and thus cannot obtain the permissions associated with the account's private key. In some embodiments, the view key corresponding to the new account is used to attempt to decrypt the encrypted output record of the most recently confirmed transaction on the blockchain. The transaction's output record is encrypted using the account address (public key) of the recipient account of the output record, and this encrypted output record can only be decrypted using the view key corresponding to the recipient account. Therefore, any output record that can be decrypted using the view key corresponding to the new account designates the new account as the recipient of the output record.

[0108] Figure 5 This is a flowchart illustrating an example of a process for deriving a key from an account private key associated with an account, according to some embodiments. In some embodiments, process 500 can be performed on a client device (such as...). Figure 1 Implemented at the client device 102). In some embodiments, Figure 4 Process 400 can be implemented at least in part using process 500.

[0109] At 502, a request to create a new account is received.

[0110] Upon encountering a 504 error, generate a private key for the new account. You can generate a new private key for the new account based on the example above. The private key should be kept confidential (e.g., not shared with anyone).

[0111] In step 506, a computed key is generated based on the account's private key. Following the example above, a computed key corresponding to the new account can be derived from the account's private key. This computed key can be shared with trusted parties.

[0112] In step 508, a view key is generated from the account's private key. Based on the example above, a view key corresponding to a new account can be derived from the account's private key. The view key can be shared with trusted parties.

[0113] In step 510, a graph key is generated from the view key. Based on the example above, a graph key corresponding to a new account can be derived from the view key. The graph key can be shared with trusted parties.

[0114] In step 512, an address is generated from the view key. Based on the example above, the address (public key) corresponding to the new account can be derived from the view key. This address can be publicly shared.

[0115] In section 514, the account's private key, computation key, viewing key, graph key, and address are stored. All keys associated with the new account are stored so that they can be retrieved later to create, view, and analyze transactions locally or via a trusted third party (except for the account's private key, which should be kept confidential).

[0116] Figure 6 This is a flowchart illustrating an example of a process for creating a transaction according to some embodiments. In some embodiments, process 600 can be performed on a client device (such as...). Figure 1 Implemented on client device 102.

[0117] At 602, a request to generate a transaction from the sender's account is received. A request to generate a transaction from the account (sender's account) is received.

[0118] In 604, a transaction is generated to include zero or more input records and one output record. Depending on the nature of the transaction, the account holder selects zero or more confirmed records (the output records of transactions already confirmed on the blockchain) to include in the transaction. For example, input records may establish the basis for executing the transaction, such as the number of tokens held by the sender's account in a transaction involving sending tokens to the recipient's account. However, if the transaction does not rely on previous records (e.g., the minting of the first tokens of a new currency), the transaction may have no input records. The account holder also provides an output record that records the nature of the intended transaction and specifically specifies the recipient's account address and the procedure (e.g., function) to be executed. The output record is also encrypted using the recipient's account address included in the output record itself.

[0119] In 606, an account private key associated with at least a portion of the sender's account and the transaction is used to generate a signature. In various embodiments, a signature corresponding to a transaction can be generated by inputting the account private key (e.g., associated with one or more input records) and at least a portion of the transaction (e.g., the transaction's input and one or more output records) into a signature generation technique. Specifically, in some embodiments, the account private key can be used based on the portion of the account holder's use of the account private key (e.g., sk...). sig ,r sig At least a portion of the input records is used to authorize the transaction, generating a signature and a unique sequence number associated with one or more input records of the transaction. As described below, the signature is then used to generate a zero-knowledge proof to be included in the transaction.

[0120] For example, if a sender account initiates a transaction to send 10 tokens to a recipient, one or more input records in this current transaction may be output records of previously confirmed transactions on the blockchain that show the sender account possesses at least 10 tokens. Each input record includes a tuple containing the sender's account address, the procedure associated with the expenditure, and data specifying the number of tokens transferred to the sender's account. The sender's account private key is used to generate the signature associated with the transaction, and it is also used to generate the sequence number associated with the input record. The output record in this transaction records the expected transfer of 10 tokens to the recipient's account. The output record includes a tuple containing the recipient's account address, the procedure associated with the expenditure, and data specifying the 10 tokens to be transferred to the recipient's account. The output record is also encrypted using the recipient's account address, ensuring that only parties with a viewing key belonging to the recipient's account can decrypt and view the 10 tokens sent from the sender's account to the recipient's account in this record / transaction. Once the transaction is published to the blockchain network and subsequently verified by it, the output record is confirmed and added to the ledger of valid records.

[0121] At 608, a zero-knowledge proof associated with a transaction is generated, based at least in part on the signature, computation key, and address associated with the sender's account. In various embodiments, by inputting the signature, computation key, and the sender's account address into the zero-knowledge proof technique, a zero-knowledge proof is generated proving that the transaction was initiated by the sender's account (and not a fraudster). The computation key and the sender's account address verify that the signature associated with the transaction belongs to the sender's account. In some embodiments, at least a portion of the zero-knowledge proof generation process is delegated to a third-party server to free up computational resources on the client device.

[0122] At 610, optionally, a tag corresponding to the output record is generated using a graph key associated with the sender's account. In some embodiments, the tag may be specific to a particular output record. In some embodiments, the tag is generic across the entire transaction. In some embodiments, the tag is generated as "HashToBase(record_commitment_i||)graph_key", where record_commitment_i is the commitment to the i-th input record.

[0123] In 612, zero-knowledge proofs and labels are included in the transaction.

[0124] At step 614, the transaction is sent for confirmation by the blockchain network. The blockchain network will use zero-knowledge proofs to determine whether to confirm the transaction and will add one or more output records to the list (ledger) of valid output records. In some embodiments, in addition to using zero-knowledge proofs to confirm the transaction, the blockchain network also checks before confirming the transaction whether the unique sequence number associated with each input record of the transaction is associated with any previously confirmed transaction (e.g., because if so, the input record cannot be consumed / spent again). Entities possessing a copy of the graph key can use the tags to regenerate tags and use the tags to identify transactions associated with accounts in order to analyze transaction trends and / or anomalous behavior.

[0125] Figure 7 This is a diagram illustrating an example of a transaction created by a sender's account according to some embodiments. In some embodiments, methods such as... Figure 6The process 600 is used to create transaction 700. Transaction 700 includes an input record 702, which includes at least the following tuples (sender account address, program, data). Input record 702 is an output record included in a previously confirmed transaction on the blockchain; therefore, input record 702 can be a valid input record providing the basis for the transaction. "Sender account address" is the account address / public key of the sender account that initiated the creation of transaction 700. The "program" of input record 702 specifies the program (function) to be executed when input record 702 is consumed / spent, and the "data" in input record 702 is the data being recorded by input record 702. Transaction 700 includes an output record 704, which describes the expected transaction to be executed by the sender account relative to the recipient account. Output record 704 includes at least the following tuples (recipient account address, program, data). Unlike input record 702, output record 704 is invalid until transaction 700 is confirmed by the blockchain. The “recipient account address” is the account address / public key of the recipient account in transaction 700. The “program” of output record 704 specifies the program (function) to be executed when output record 704 is consumed / spent, and the “data” of input record 702 is the data being recorded by output record 704. Furthermore, output record 704 is also encrypted using the recipient account address, which is also the first member of its tuple, such that output record 704 can only be successfully decrypted using the view key associated with the recipient account, as described above. Transaction 700 also includes a tag 706, which is generated based on at least one or both of input record 702 and output record 704, and a graph key associated with the sender account. Transaction 700 also includes a zero-knowledge proof 708, which is generated based on a signature, a computation key associated with the sender account, and the sender account address. In some embodiments, the signature is generated based on the account private key associated with the sender account and at least one or both of input record 702 and output record 704.

[0126] For example, if transaction 700 describes the transfer of 10 tokens from the sender's account to the receiver's account, then input record 702 will record that the sender's account has at least 10 tokens, and output record 704 will record that the receiver's account should receive 10 tokens.

[0127] After transaction 700 is generated, it is sent / published to a blockchain network configured to confirm whether to add output record 704 to the list of valid output records, based at least on a zero-knowledge proof 708 and a unique sequence number associated with input record 702. Zero-knowledge proof 708 proves to the blockchain network that the sender account has indeed authorized the transaction (e.g., the spending of tokens) without revealing the computation key associated with the sender account. The blockchain network uses the unique sequence number associated with input record 702 to confirm that input record 702 has not been used in another confirmed transaction (transaction 700 is only confirmed if input record 702 has not been previously consumed in another transaction). Once the blockchain network confirms transaction 700, it adds output record 704 to the list of valid output records, which can then be used / consumed / spent by the recipient account as an input record for subsequent transactions.

[0128] Figure 8 This is a flowchart illustrating an example of a process for viewing transactions according to some embodiments. In some embodiments, process 800 can be performed on a client device (such as...). Figure 1 The process 800 is implemented at the client device 102. In some embodiments, the process 800 can be implemented at a transaction scanning server (such as...). Figure 1 The transaction scanning server (106) is implemented.

[0129] Procedure 800 can be executed on a client device used by the given account as described below, or it can be executed by a transaction scanning server to which the client device has delegated procedure 800 via a shared viewing key associated with the given account.

[0130] At 802, a request is received to determine whether a given account is a party to one or more confirmed transactions.

[0131] At 804, obtain the most recently confirmed output record associated with the confirmed transaction. Transactions sent to the blockchain network are confirmed over time, and after a transaction is confirmed, its output record is added to the list of valid / confirmed output records. Periodically or in response to triggers / events, new output records are added to the list to scan for transactions associated with a given account.

[0132] In 806, the view key associated with a given account is used to determine zero or more confirmed output records that can be decrypted using the view key. As described above, each output record is encrypted using the recipient account address included in its tuple. The encrypted output record can only be decrypted using the view key associated with the recipient account address. Therefore, only output records encrypted with the address of the same account used for decryption using the view key can be decrypted by that view key. This type of asymmetric encryption only allows parties trusted by the account and possessing its view key to view transactions associated with that account.

[0133] At step 808, information regarding zero or more decryption confirmation output records is presented to the given account. For each decryption output record, i.e., the record associated with the given account, at least a portion of the data recorded by that record is presented at the user interface of the given account. For example, if a decryption output record indicates that the given account received 10 tokens, this information will be presented to the account holder at the user interface.

[0134] Figure 9 This is a flowchart illustrating an example of a process for tracking trading trends according to some embodiments. In some embodiments, process 900 can be performed on a client device (such as...). Figure 1 The process 900 is implemented at the client device 102. In some embodiments, the process 900 can be implemented at a trend analysis server (such as...). Figure 1 The trend analysis server (108) is implemented.

[0135] Process 900 can be executed on a client device used by a given account as described below, or it can be executed by a trend analysis server to which the client device has delegated process 900 via a shared graph key associated with the given account.

[0136] In 902, a request is received to track trends associated with a given account.

[0137] At 904, the most recently confirmed transaction is retrieved. Transactions sent to the blockchain network are confirmed over time, and once a transaction is confirmed, its output record is added to the list of valid / confirmed output records. New output records added to the list are retrieved periodically or in response to triggers / events to help determine trends.

[0138] In step 906, for the (next) confirmed transaction, a transaction-specific tag is generated based on the graph key associated with the given account. In some embodiments, the transaction-specific tag is generated based on the graph key and a portion of the transaction.

[0139] At step 908, determine whether the confirmed transaction includes a transaction-specific label. If the transaction includes a transaction-specific label, control is transferred to step 910. Otherwise, if the transaction does not include a transaction-specific label, control is transferred to step 912. If the confirmed transaction includes a calculated label, the transaction is determined to belong to the given account.

[0140] In step 910, confirmed transactions are included in a set of transactions to analyze trends associated with a given account. Transactions identified as having tags generated based on graph keys are those determined to be associated with a given account. These associated transactions can then be analyzed using clustering, machine learning, or other techniques to determine overall trends and the potential presence of anomalous activity.

[0141] At 912, determine if at least one confirmed transaction exists. If at least one confirmed transaction exists, control returns to 906. Otherwise, if no further confirmed transactions are found, process 900 ends.

[0142] Although the embodiments described above have been given in detail for clarity of understanding, the invention is not limited to the details provided. Many alternative methods of carrying out the invention exist. The disclosed embodiments are illustrative and not restrictive.

Claims

1. A system comprising: One or more memory units; and One or more processors, coupled to the one or more memories, and configured to: Generate an account private key associated with the new account; A computational key associated with the new account is derived from the account's private key, wherein the computational key is configured to verify a new transaction to be confirmed on the blockchain, and wherein the new transaction is initiated by the new account, wherein the account's private key cannot be recovered from the computational key; Receive a request to generate the new transaction from the new account, wherein the request includes a record associated with the new transaction; Generating the new transaction includes: A signature is generated, at least in part, based on the account's private key and the record associated with the new transaction; and The zero-knowledge proof is generated using at least part of the signature, the address associated with the new account, and the computation key; and The new transaction, including the zero-knowledge proof, is sent to a validator associated with the blockchain, wherein the zero-knowledge proof is configured to verify to the validator that the signature associated with the new transaction belongs to the new account, without revealing the signature to the validator.

2. The system of claim 1, wherein the one or more processors are further configured to: A viewing key associated with the new account is generated, at least in part, based on the account's private key, wherein the viewing key is configured to decrypt a portion of a confirmed transaction belonging to the new account on the blockchain, and wherein the account's private key cannot be recovered from the viewing key; and An address associated with the new account is generated, at least in part, based on the viewing key, wherein the viewing key is configured to decrypt data encrypted by the address.

3. The system of claim 2, wherein the one or more processors are further configured to generate a graph key associated with the new account based at least in part on the viewing key, wherein the graph key is configured to generate a tag based at least in part on the new transaction, wherein the tag is included in the new transaction to mark the new transaction as associated with the new account.

4. The system of claim 1, wherein the one or more processors are further configured to generate the account private key in response to a request to generate the new account.

5. The system of claim 1, wherein the record comprises zero or more input records and one output record, wherein the output record comprises a receiver account address, and wherein the one or more processors are further configured to: The output record is encrypted using the recipient's account address, wherein the encrypted output record can be decrypted using a recipient viewing key corresponding to the recipient's account address.

6. The system of claim 5, wherein the zero or more input records each include an address associated with the new account, wherein the address is generated at least in part based on a viewing key derived from the account's private key, wherein the account's private key cannot be recovered from the viewing key.

7. The system of claim 5, wherein the zero or more input records include one or more output records of transactions previously confirmed on the blockchain.

8. The system of claim 5, wherein the one or more processors are further configured to: A viewing key associated with the new account is generated at least in part based on the account private key, wherein the viewing key is configured to decrypt a portion of a confirmed transaction on the blockchain belonging to the new account, wherein the account private key cannot be recovered from the viewing key; A graph key associated with the new account is generated, at least in part, based on the viewing key; Use at least one of the zero or more input records and the one output record to generate a tag corresponding to the new transaction; and The tag is included in the new transaction before it is sent to the validator associated with the blockchain.

9. The system of claim 1, wherein the one or more processors are further configured to: A viewing key associated with the new account is generated at least in part based on the account private key, wherein the viewing key is configured to decrypt a portion of a confirmed transaction on the blockchain belonging to the new account, wherein the account private key cannot be recovered from the viewing key; Receive a request to determine whether the new account is a party to one or more confirmed transactions on the blockchain; Obtain a new confirmation output record associated with the one or more confirmed transactions; Identify a confirmation output record that can be decrypted using the viewing key, wherein the confirmation output record is encrypted using an address associated with the new account; and Information about the confirmation output record is presented on the user interface.

10. The system of claim 1, wherein the one or more processors are further configured to: A viewing key associated with the new account is generated at least in part based on the account private key, wherein the viewing key is configured to decrypt a portion of a confirmed transaction on the blockchain belonging to the new account, wherein the account private key cannot be recovered from the viewing key; A graph key associated with the new account is generated, at least in part, based on the viewing key; Receive a request to track trends associated with the new account; The transaction is confirmed on the blockchain; Use the graph key to generate a corresponding tag for the confirmed transaction; Determine a subset of the confirmed transactions, which includes the corresponding subset of the respective tags; and Analyze the subset of confirmed transactions associated with the new account for trend or unusual activity.

11. A method comprising: Generate an account private key associated with the new account; A computational key associated with the new account is derived from the account's private key, wherein the computational key is configured to verify a new transaction to be confirmed on the blockchain, and wherein the new transaction is initiated by the new account, wherein the account's private key cannot be recovered from the computational key; Receive a request to generate the new transaction from the new account, wherein the request includes a record associated with the new transaction; Generating the new transaction includes: A signature is generated, at least in part, based on the account's private key and the record associated with the new transaction; and The zero-knowledge proof is generated using at least part of the signature, the address associated with the new account, and the computation key; and The new transaction, including the zero-knowledge proof, is sent to a validator associated with the blockchain, wherein the zero-knowledge proof is configured to verify to the validator that the signature associated with the new transaction belongs to the new account, without revealing the signature to the validator.

12. The method of claim 11, further comprising: A viewing key associated with the new account is generated, at least in part, based on the account's private key, wherein the viewing key is configured to decrypt a portion of a confirmed transaction belonging to the new account on the blockchain, and wherein the account's private key cannot be recovered from the viewing key; and An address associated with the new account is generated at least in part based on the viewing key, wherein the viewing key is configured to decrypt data encrypted by the address.

13. The method of claim 12, further comprising generating a graph key associated with the new account based at least in part on the viewing key, wherein the graph key is configured to generate a tag based at least in part on the new transaction, wherein the tag is included in the new transaction to mark the new transaction as associated with the new account.

14. The method of claim 11, wherein the record comprises zero or more input records and an output record, wherein the output record comprises a recipient account address, the method further comprising: The output record is encrypted using the recipient's account address, and the encrypted output record can be decrypted using a recipient viewing key corresponding to the recipient's account address.

15. The method of claim 14, wherein the zero or more input records each include an address associated with the new account, wherein the address is generated at least in part based on a viewing key derived from the account's private key, wherein the account's private key cannot be recovered from the viewing key.

16. The method of claim 14, wherein the zero or more input records include one or more output records of transactions previously confirmed on the blockchain.

17. A computer program product comprising a non-transitory computer-readable storage medium and including computer instructions stored therein, which, when executed by one or more processors, cause the one or more processors to perform operations, including: Generate an account private key associated with the new account; A computational key associated with the new account is derived from the account's private key, wherein the computational key is configured to verify a new transaction to be confirmed on the blockchain, and wherein the new transaction is initiated by the new account, wherein the account's private key cannot be recovered from the computational key; Receive a request to generate the new transaction from the new account, wherein the request includes a record associated with the new transaction; Generating the new transaction includes: A signature is generated, at least in part, based on the account's private key and the record associated with the new transaction; and The zero-knowledge proof is generated using at least part of the signature, the address associated with the new account, and the computation key; and The new transaction, including the zero-knowledge proof, is sent to a validator associated with the blockchain, wherein the zero-knowledge proof is configured to verify to the validator that the signature associated with the new transaction belongs to the new account, without revealing the signature to the validator.

Images