Key derivation for account management

Abstract

Key derivation for account management is disclosed, including generating an account private key associated with a new account, generating a computation key associated with the new account based at least in part on the account private key, the computation key usable to verify new transactions confirmed on the blockchain, the new transactions 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, the view key usable to decrypt a portion of the transactions confirmed on the blockchain that belong to the new account.

Description

[Background technology]

[0001] Transactions on a blockchain are typically publicly viewable. Thus, traversing the blockchain can reveal the activity and token amounts associated with each account. However, making such information publicly available for consumption is detrimental to protecting the privacy of users of the accounts. It is desirable to enable transactions on a blockchain to protect the privacy and, therefore, the security of accounts participating in the blockchain. [Brief explanation of the drawings]

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

[0003] [Figure 1] FIG. 1 illustrates one embodiment of a system for generating and utilizing key derivations for account management.

[0004] [Figure 2] 1 illustrates an example of a client device according to some embodiments.

[0005] [Figure 3] 4A-4C illustrate key derivation paths from an account private key corresponding to an account, according to some embodiments.

[0006] [Figure 4] 10 is a flow chart illustrating one embodiment of a process for deriving a key for managing an account.

[0007] [Figure 5] 10 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] 1 is a flowchart illustrating an example of a process for creating a transaction, according to some embodiments.

[0009] [Figure 7] FIG. 1 illustrates an example of a transaction made by a sender account, according to some embodiments.

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

[0011] [Figure 9] 1 is a flowchart illustrating an example of a process for tracking transaction trends according to some embodiments. DETAILED DESCRIPTION OF THE INVENTION

[0012] The present invention may be embodied in various forms, including as a process, an apparatus, a system, a composition of matter, a computer program product embodied on a computer-readable storage medium, and / or a processor configured to execute instructions stored in and / or provided by a memory coupled to the processor. These embodiments, or any other form the present invention may take, may be referred to herein as technology. In general, the order of steps in a disclosed process may be varied within the scope of the present invention. Unless otherwise noted, components, such as a processor or memory, described as configured to perform a task may be implemented as general components temporarily configured to perform the task at a given time, or as specific components manufactured to perform the task. As used herein, the term “processor” refers to one or more devices, circuits, and / or processing cores configured to process data, such as computer program instructions.

[0013] The following is a detailed description of one or more embodiments of the present invention with reference to figures that illustrate the principles of the invention. While the present invention has been described in connection with such embodiments, it is not limited to any particular embodiment. The scope of the present invention is limited only by the claims, and the present invention includes many alternatives, modifications, and equivalents. In the following description, numerous specific details are set forth in order to provide a thorough understanding of the present invention. These details are for the purpose of example, and the present invention may be practiced according to the claims without some or all of these specific details. For simplicity, technical matters that are well known in the art related to the present invention have not been described in detail so as not to unnecessarily obscure the present invention.

[0014] Embodiments of key derivation for account management are described herein. In various embodiments, a request to open a new account for use in participating in transactions on a blockchain is received. In response to the request, an “account private key” associated with the new account is generated. A “computation key” associated with the new account is then generated based at least in part on the account private key. Further, a “view key” associated with the new account is then generated based at least in part on the account private key. As described in more detail below, the computation key can be used to verify new transactions confirmed on the blockchain and where the new transactions are initiated by the new account. The view key can be used to decrypt portions of transactions confirmed on the blockchain that belong to the new account. In various embodiments, the computation key and view key can each be used separately to derive an “account address” (which may be referred to as a “public key”) that publicly identifies the new account. The account private key can perform all of the functions associated with the derived, and therefore highly sensitive, derived keys (e.g., the computation key and the view key), but no derived key can be used individually or in combination to recover the account private key. Furthermore, each of the derived keys cannot be utilized to recover any of the other keys directly derived from the account private key, nor can it perform any of the functions associated with any other derived key. By separating / splitting the functions of an account's account private key into several derived keys, the derived keys can potentially be delegated to trusted third parties to perform different functions regarding transactions on the blockchain on behalf of the account, without having to directly share the highly sensitive account private key.

[0015] Figure 1 illustrates one embodiment of a system for generating and utilizing key derivations for account management. As shown in Figure 1, 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. Network 112 includes a data network and / or a telecommunications network.

[0016] The client device 102 is configured to execute computer program code associated with a standalone software application or a web browser-based application configured to generate and utilize cryptographic keys in connection with managing accounts involved in transactions on the blockchain 110. Examples of the client device 102 may be a mobile device, a laptop computer, a desktop computer, a tablet device, or any other computing device. A user (not shown) may interact with a user interface associated with an application running on 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” (also 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 determined based on a concatenation that includes the seed value. As described in more detail below, the new private account key may include two or more elements (e.g., each element may be represented by 32 bytes). The user's (new account holder's) account private key may be utilized to perform a wide variety of functions related to transactions on the blockchain 110. Some examples of such functions include authorizing transactions (e.g., using tokens associated with the new account), decrypting a portion of the confirmed transactions on the blockchain 110 to determine which transactions are associated with the new account, and determining patterns associated with confirmed transactions on the blockchain 110 initiated by the new account. Thus, the account private key is powerful and sensitive information that ideally should not be shared with other users or devices to reduce the risk of unauthorized transactions being associated with the new account.

[0017] After an account private key is generated for the new account by an application running on client device 102, the application is configured to derive, directly or indirectly, one or more other keys corresponding to the new account from the account private key. A first key corresponding to the new account and derived from the account private key is an “account computation key,” or simply a “computation key.” The computation key can be included in each account signature and is used to perform zero-knowledge proofs associated with 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 should be shared only with trusted parties. A second key corresponding to the new account and derived 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 should be shared only with trusted parties. Neither the view key nor the computation key can perform each other's functions. In some embodiments, a third key corresponding to the new account and derived from a view key derived from the account private key is an "account graph key," or simply a "graph key." The graph key can be used to calculate a tag to be included in the transaction, and the tag can then be used to identify transactions belonging to the new account at a high level, toward detecting patterns (e.g., of token usage) across transactions. The graph key should only be shared with trusted parties. A fourth key corresponding to the new account and derived from a view key 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 shared publicly.For example, another account wishing to perform a transaction with the new account must specify the address of the new account in the transaction, which may be shared, for example, with another device on which the transaction occurs.

[0018] To initiate a transaction that is confirmed by the blockchain network 110, a user of the new account enters parameters associated with the transaction into a user interface of an application running on the client device 102. For example, if the transaction involves the use of tokens associated with the new account, the parameters associated with the transaction may include identifying information associated with one or more confirmed records in the blockchain network 110 that record what the new account holds. These confirmed records are included by the application as one or more input records in the transaction. Further, in this example, the user input parameters also include at least the amount of tokens the user wants to send to the receiving party, as well as at least one output record (confirmed by the blockchain network 110) that identifies the receiving party's account address (public key), the program to be executed, and the amount of tokens to be sent to the receiving party, which are included in the transaction as output records by the application. In some embodiments, each output record is also encrypted using the recipient account address included in that output record. In various embodiments, a signature is generated by the application on the client device 102 based at least on a locally generated account private key corresponding to the new account and at least a portion of the transaction (e.g., the input record and / or the output record). In some embodiments, the application running on the client device 102 is further configured to generate a zero-knowledge proof using the signature, the computation key, and at least a portion of the input record and / or the output record (e.g., the account address / public key of the new account that initiated the transaction).In this context, a “zero-knowledge proof” verifies that a signature actually belongs to a user associated with a new account without revealing the signature itself (or the computation key and record contents) to a verifier (e.g., a node in the blockchain network 110). In some embodiments, a tag is generated by an application on the client device 102 based at least on a graph key corresponding to the new account and at least a portion of the transaction (e.g., the output record). The tag can be used by the holder of the graph key to identify the transaction associated with the new account, but does not provide details about such transaction (e.g., because the output record of such transaction is encrypted and cannot be decrypted using the graph key). In various embodiments, a transaction including a set of input records, a set of output records, a zero-knowledge proof, and optionally a tag is transmitted by the client device 102 to the blockchain network 110, where a node in the blockchain network 110 confirms and thus validates the output record and adds the valid / confirmed output record to the ledger.

[0019] As described above, during the process of creating a transaction initiated by the holder of a new account at the client device 102, a zero-knowledge proof needs to be generated using a signature associated with the new account. Generating a zero-knowledge proof can be computationally intensive, especially when the client device 102 is a mobile device with limited computational resources. Thus, in some embodiments, the client device 102 can delegate / offload the process of generating a zero-knowledge proof associated with a transaction to a third-party server (such as the proof generation server 104) by sending at least a portion of the signature and / or transaction, a computation key, and / or data derived from the signature and / or transaction to the proof generation server 104 to generate the entire zero-knowledge proof or to complete the second half of the generation of the zero-knowledge proof. 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 a transaction initiated by a party other than the holder of a new account is confirmed by the blockchain network 110, an application running on the client device 102 can use a locally derived view key corresponding to the new account to determine which, if any, confirmed transactions involve the new account. As described above, during the process of creating a transaction initiated by the holder of a new account (the sender account) on the client device 102, the transaction's output record, which describes the nature of the transaction and the transaction recipient, is encrypted using the recipient's account address (the recipient's public key). Because the encrypted output record can only be decrypted and viewed using the view key corresponding to the same account, only entities with a copy of that view key can decrypt the encrypted output records of the transactions and learn the nature of those transactions (e.g., how many tokens were sent to the recipient by the corresponding sender account). In other words, entities that do not have a view key corresponding to the recipient account of the encrypted output records of the confirmed transactions cannot decrypt those output records. This use of asymmetric encryption prevents entities other than those entrusted with a copy of the view key corresponding to an account from seeing or learning about transactions involving that account.

[0021] Although an application running on the client device 102 can (periodically) download the encrypted output records of transactions confirmed by the blockchain network 110 and determine which, if any, of the output records can be decrypted using a locally derived view key, in some embodiments the application can delegate the service of checking which confirmed transactions are recipients to a third-party server (such as the transaction scanning server 106). For example, delegating the service of checking which confirmed transactions are recipients to the transaction scanning server 106 includes sending a view key to the transaction scanning server 106 so that the transaction scanning server 106 can continuously (e.g., periodically or in response to an event) download the encrypted output records of confirmed transactions from the blockchain network 110 and use the obtained view key to determine which of those output records are decryptable with the view key. For output records that the transaction scanning server 106 is able to decode, the transaction scanning server 106 can then determine the nature of transactions in which the new account is the recipient and then send messages (e.g., in the form of push notifications) to the client device 102 to notify the account holders of these transactions. In this way, the transaction scanning server 106 can continue to scan (e.g., newly) confirmed transactions on the blockchain network 110 to determine transactions associated with the new account, even when the client device 102 is offline (e.g., has not downloaded confirmed output records from the blockchain network for any reason).

[0022] As described above, during the process of creating a transaction initiated by the holder of a new account on the client device 102, a tag may be generated using a graph key corresponding to the new account and included in the transaction. In some embodiments, the 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 (e.g., trend analysis server 108). For example, delegating the service of checking trends / patterns among transactions with tags generated based on the graph key includes transmitting the graph key to the trend analysis server 108 so that the trend analysis server 108 can download confirmed transactions from the blockchain network 110 and determine transactions that include tags determined based on the graph key. The trend analysis server 108 is configured to audit transactions, for example, by analyzing the transactions (e.g., by applying machine learning models and / or utilizing clustering) to determine patterns among transactions that include tags generated by the graph key. For example, patterns may indicate anomalous transactions that may indicate hacking or other undesirable behavior. However, without the graph key and no view key corresponding to the new account, the trend analysis server 108 cannot decrypt and view the details of the encrypted output records of the transactions. In some examples, the trend analysis server 108 can alert another entity (e.g., the client device 102 or a transaction scanning server or another server) that holds the view keys of transactions that it has determined to be anomalous so that the notified entity can use the view keys to decrypt the encrypted output records of those transactions to more closely examine those transactions for suspicious behavior.

[0023] Thus, in system 100, keys derived from an account private key associated with an account can be used to separate various functions that may be performed by the account private key. However, these derived keys cannot perform each other's functions or be used to independently recover the account private key. Thus, by sharing the derived keys with different trusted parties, services can be delegated / offloaded to be performed by these parties without concern that these parties will be unable to recover the account private key. As described in various embodiments herein, deriving and using derived keys from the account private key can prevent the highly sensitive account private key from being leaked, while providing the flexibility to potentially utilize third parties to perform at least some of the tasks associated with account management with respect to transactions on the blockchain on behalf of the account.

[0024] Figure 2 is a diagram illustrating an example client device, according to some embodiments. In some embodiments, client device 102 of system 100 of Figure 1 can be implemented using the example client device of Figure 2. As shown in Figure 2, 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 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] The key generation engine 202 is configured to generate an account private key for the account (e.g., in response to a request to create a new account). After generating the account private key for the account, the key generation engine 202 is configured to derive keys directly from the account private key, such as a view key and a computation key corresponding to the account. The view key may be used to decrypt output records associated with transactions confirmed by the blockchain network. The computation key may be used to verify signatures associated with transactions initiated using the account private key. In some embodiments, the key generation engine 202 is configured to derive a graph key corresponding to the account from the view key. The graph key is used to generate tags based on records associated with the transaction and is used to identify the transaction to the holder of the graph key, but is not used to decrypt records for them without the view key. The key generation engine 202 can derive an account address (public key) corresponding to the account from the view key or the computation key. Unlike other keys corresponding to an account, the account address is a public identifier for 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 the account address of another account holder by transmitting the address to one or more other devices where the account holder may be a counterparty in a transaction with the account address holder.

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

[0027] The transaction creation engine 206 is configured to create transactions initiated by the account holder using the account private key. To initiate a transaction, the account holder may input parameters identifying zero or more previously confirmed records in the blockchain's public ledger as input records. Additionally, to initiate a transaction, the account holder may also input parameters for one or more output records detailing who / what will be affected by the transaction, such as the account address of the receiving party of the transaction and the nature of the transaction (e.g., a transfer of tokens or the execution of a smart contract). In various embodiments, the transaction creation engine 206 is configured to encrypt each output record using the recipient account address (included in the output record) so that only those with a view key associated with the recipient account address can decrypt and view the contents of the output record after the transaction is confirmed by the blockchain network. In some embodiments, the transaction creation engine 206 is configured to generate a digital signature corresponding to the transaction using the account private key and at least a portion of the records included in the transaction. In some embodiments, the transaction creation engine 206 is configured to input the signature associated with the transaction along with at least a computation key corresponding to the account into zero-knowledge proof generation technology to generate a zero-knowledge proof to prove (e.g., to a verifier with a node in the blockchain network) that the signature indeed belongs to the 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 not authorize the transaction. In some embodiments, the transaction creation engine 206 is configured to generate either a record-level tag or a transaction-level tag corresponding to the transaction using a graph key corresponding to the account.The transaction creation engine 206 is configured to "mark" a transaction by including a tag in the transaction so that the tag can later be used to identify the transaction as belonging to the transaction's sender account. As described in more detail below, the transaction creation engine 206 is configured to create a transaction that includes zero or more confirmed input records, one or more unconfirmed output records, (optionally) a tag, and a zero-knowledge proof, and then submit the transaction to the blockchain network for confirmation so that the output records can be added to the ledger.

[0028] The transaction viewing engine 208 is configured to attempt to decrypt encrypted output records associated with transactions confirmed on the blockchain using a view key corresponding to the account to determine which output records, if any, identified the account as the recipient of the transaction. In some embodiments, the transaction viewing engine 208 is configured to download output records associated with (recently) confirmed transactions on the blockchain periodically or in response to an event (e.g., a user command to check). The transaction viewing engine 208 is then configured to attempt to decrypt encrypted output records associated with each confirmed transaction to determine whether the output record can be decrypted. As described above, the sender / creator of a transaction encrypts each output record of the transaction using the account address (public key) of the receiving party of each output record, and the encrypted output record is only decryptable using the receiving party's view key. Therefore, the transaction viewing engine 208 can only decrypt output records encrypted using the account's account address using the account's view key. In other words, the transaction viewing engine 208 can successfully decrypt only encrypted output records for which the account holder of the view key is the receiving party. In some embodiments, for each output record that the transaction viewing engine 208 successfully decodes, the transaction viewing engine 208 is configured to generate and present a prompt on a client device display (not shown) to inform the user / account holder of the type of transaction for which the user was determined to be the recipient.For example, if an output record successfully decrypted by the transaction viewing engine 208 indicates that the sending party sent five tokens to the user, the transaction viewing engine 208 is configured to present a message or prompt on the client device display that the user has received five tokens from the sending party (e.g., as may be determined by the transaction viewing engine 208 from the input record of the same transaction because the input record is not encrypted and therefore viewable).

[0029] The delegation engine 210 is configured to send a copy of a key derived from the account's account private key or data derived from those keys to other entities in the course of delegating services to be performed by those other entities, such as in processes such as transaction creation, transaction viewing, and transaction trend analysis. In a first example of delegation, as described above, during a process of creating a transaction initiated by an account holder (e.g., performed by the transaction creation engine 206), a zero-knowledge proof needs to be generated based on one or more of a signature derived from the account private key, a computational key derived from the account private key, an account address associated with the account, and at least a portion of a record associated with the transaction. However, generating a zero-knowledge proof can be resource-intensive; therefore, the delegation engine 210 can delegate the generation of this proof to a third-party server (e.g., the proof generation server 104 of FIG. 1 ). For example, the delegation engine 210 can delegate the generation of the zero-knowledge proof to a third-party server in response to a user command or in response to a determination that resources available locally at the client device are below a predetermined threshold of available computational resources. To delegate the generation of the zero-knowledge proof to a third-party server, the delegation engine 210 is configured to send one or more of the signature, the computation key, and at least a portion of the transaction to the third-party server. After the zero-knowledge proof is received 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 finalize the transaction before submitting it to the blockchain network for confirmation.

[0030] In a second example of delegation, to view transactions associated with an account (e.g., as may be performed by the transaction viewing engine 208), output records of newly confirmed transactions are continuously downloaded from the blockchain, and then it is determined which of them can be decrypted using a view key corresponding to the account. However, if there is a large number of such transactions, or if the client device cannot connect to the blockchain for any reason, continuously monitoring newly confirmed transactions on the blockchain can also be resource-intensive. Therefore, the delegation engine 210 can delegate checking of associated transactions to a third-party server. For example, the delegation engine 210 can delegate monitoring of transactions to a third-party server in response to a user command or in response to a determination that resources locally available on the client device are below a predetermined threshold of available computational resources. To delegate monitoring of transactions to a third-party server, the delegation engine 210 is configured to send a view key to the third-party server (e.g., the transaction scanning server 106 of FIG. 1 ). In that way, the third-party server can continue checking transactions associated with the account even when the client device is offline (e.g., not connected to the blockchain). Once the third-party server determines the transactions associated with the account (because the transaction includes at least one output record that can be decrypted using the view key), the third-party server can send at least a portion of the decrypted output records to the transaction viewing engine 208 for displaying a prompt or message (e.g., a push notification) on the display of the client device.

[0031] In a third example of delegation, a graph key corresponding to an account can be used to regenerate tags associated with the account and identify transactions that include the tags as being associated with the account, without necessarily viewing data about transactions associated with the account, to check for trends. Because using the graph key to generate these account-related tags, find transactions confirmed by the blockchain, and then analyze 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 trends in such transactions to a third-party server. To delegate the analysis of transaction trends to the third-party server, the delegation engine 210 is configured to send the graph key to the third-party server (e.g., trend analysis server 108 of FIG. 1 ). In this way, the third-party server can use the graph key to generate tags, find transactions that include such tags, and analyze the transactions for trends or anomalous behavior. If the third-party server determines a transaction may indicate anomalous activity, the third-party server may send a message to the client device informing the user, for example, the user may input a command to cause the delegation engine 210 to send the view key along with the flagged transaction to another third-party server for decryption, for the purpose of a second third-party server examining the nature of the transaction to determine whether any malicious activity was involved.

[0032] FIG. 3 illustrates a key derivation path from an account private key corresponding to an account, according to some embodiments. As described above, an account's account private key can, among other functions, authorize transactions on behalf of the account (e.g., spending tokens or authorizing smart contracts) and is therefore highly sensitive and should be kept secret by the account's holder (and not shared with any other party). A computation key can be derived directly from the account private key, and the computation key can be used to verify signatures associated with created transactions. 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). As shown in further detail, it is mathematically impossible to recreate the account private key using the computation key, and therefore the account private key cannot be recovered from the computation key. A view key can be derived directly from the account private key, and the view key can be used to view transactions in which the account holder is a recipient. The view key can be shared with a trusted third party to monitor confirmed transactions in order to determine transactions in which the account holder is a recipient. As will be shown in more detail later, it is mathematically impossible to recreate an account private key using a view key, so it is not possible to recover the account private key from the view key. A graph key can be derived from the view key and can be used to identify transactions with tags generated using the graph key. Because the graph key is derived from the view key, it is not possible to recover the account private key from the graph key, and the view key cannot be used to recover the account private key. An account's address (public key) can be derived from either the computation key or the view key. An address is a public identifier for an account and can be shared with any party (e.g., to allow other parties to perform transactions on the account as a recipient).Because the address is derived from the view key or computation key, the account private key cannot be recovered from the address, and neither the view key nor the computation key can be used to recover the account private key.

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

[0034] As shown in Figure 3, by indirectly deriving an account's address (public key) from its account private key, the address is decoupled from the private key, making it mathematically improbable and practically impossible to recover the account private key from its address, enhancing the security of the sensitive account private key. Furthermore, the key relationship / derivation shown in Figure 3 illustrates how the different powers that can be exercised by the account private key can be distributed across multiple derived keys by allowing the derived keys to be delegated to (e.g., different) trusted parties, enabling the delegators to perform tasks associated with each power.

[0035] The following is an example of generating an account private key and deriving a key from the account private key, according to some embodiments.

[0036] In the following description, the following definitions of mathematical objects are used:

[0037] Prime finite field: For a prime number r, the finite field F r consists of integers {0, 1, , r}. Fr has two related operations: addition modulo r and multiplication modulo r. In this paper, we use two prime finite fields: F of prime order p scalar , and F of prime order q base In some embodiments, q>p.

[0038] Prime-order elliptic curve group: In this specification, the base field F base Consider a subgroup of order p of points on an elliptic curve defined in. An element of this subgroup consists of a coordinate pair (x,y). The group has two related operations: point addition and point doubling. The group also has a distinguishing point (i.e., a generator G) that is a fixed point of the group. In some embodiments, the generator is G derived using the "HashToCurve" algorithm, although any point in a prime-order subgroup will suffice.

[0039] HashToField F :For a finite field F, HashToField F is a cryptographic hash function that takes as input either a sequence of bytes or a sequence of elements of F, and outputs an element of F.

[0040] HashToScalar: a scalar field F scalar An instantiation of HashToField that outputs the elements in base The Poseidon hash function (with the above operations) outputs F scalar In some other embodiments, the HashToScalar function includes other cryptographic hash functions, such as, for example, SHA256 or SHA512.

[0041] EncodeToF(F,x) is a function that encrypts a bit string x as an element of a finite field F.

[0042] Account Private Key Generation

[0043] In some embodiments, two components (sk) referred to as "variant A" sig ,r sig In some embodiments, the account private key can be generated to include three components (sk) called "variant B": sig ,r sig ,sk vrf ), each variant of the account private key has a derivation corresponding to the computation key, view key, graph key, and address. Both variants A and B are described below.

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

[0045] Function PrivateKey.New():

[0046] 1.Seed←F base / / "seed" is F base It is sampled from the underlying field {0, 1, , q} by selecting a random value from the underlying field.

[0047] 2.sk sig =HashToScalar(seed||EncodeToF(F base ,“AccountSignatureSecretKey0”)) / / The byte sequence (forming an integer) containing the ASCII encoding of the given value of “AccountSignatureSecretKey0” is divided by q to obtain F base The resulting remainder is encoded as an element of F base is a value in the base field {0, 1, , q-1}. Then, F base The remainder in the base field is concatenated with the "Seed" value, and the concatenation is input to the HashToScalar() function, whose input is F scalarIt maps onto the elements of the scalar field {0, 1, . . . , p-1}, where q and p are both prime numbers and q>p.

[0048] 3.r sig =HashToScalar(seed||EncodeToF(F base ,“AccountSignatureRandomizer0_0”)) / / The byte sequence (forming an integer) containing the ASCII encoding of a given value of “AccountSignatureRandomizer0_0” is divided by q to obtain F base The resulting remainder is encoded as an element of F base is a value in the base field {0, 1, , q-1}. Then, F base The remainder in the base field is concatenated with the "Seed" value, and the concatenation is input to the HashToScalar() function, whose input is F scalar It is mapped onto the elements of the scalar field {0, 1, , p-1}. sig Another derivation of r sig =seed||counter sig Here, "counter sig " is a predetermined value.

[0049] 4.Output(seed,(sk sig ,r sig )) / / "Seed" is F base is an element of the base field {0,1,···,q-1}, and sk sig and r sig Each of the F scalar are elements of the scalar field {0, 1, , p-1}. seed and sk sig and r sig Each of these can be represented using 32 bytes.

[0050] Variant B may contain additional components, as described below. vrf Similar to variant A, except that it contains:

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

[0052] Function PrivateKey.New():

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

[0054] 2.sk sig =HashToScalar(seed||EncodeToF(F base ,“AccountSignatureSecretKey0”)) / / Same as variant A.

[0055] 3.r sig =HashToScalar(seed||EncodeToF(F base ,“AccountSignatureRandomizer0_0”)) / / Same as variant A.

[0056] 4.sk vrf =HashToScalar(seed||EncodeToF(F base ,“AccountVRFSecretKey0”)) / / The byte sequence (forming an integer) containing the ASCII encoding of the given value of “AccountVRFSecretKey0” is divided by q to obtain F base The resulting remainder is encoded as an element of F base is a value in the base field {0, 1, , q-1}. Then, F base The remainder in the base field is concatenated with the "Seed" value, and the concatenation is input to the HashToScalar() function, whose input is F scalar It is mapped onto the elements of the scalar field {0, 1, , p-1}.

[0057] 5.Output(seed,(sk sig ,r sig ,sk vrf )) / / "Seed" is F baseis an element of the base field {0,1,···,q-1}, and sk sig , r sig , and , sk vrf Each of the F scalar are elements of the scalar field {0, 1, , p-1}. sig , r sig , and , sk vrf Each of these can be represented using 32 bytes.

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

[0059] Calculation Key Generation

[0060] In some embodiments, the computation key associated with the account private key is composed of two components (sk) derived from the "variant A" of the account private key as described above. sig ,r sig In some embodiments, the computation key associated with the account private key may be generated based on three components (sk) derived from the "variant B" of the account private key as described above. sig ,r sig ,sk vrf ) can be generated based on

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

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

[0063] 1.key compute =(sk sig G,r sig ·G) / / As mentioned above, G is a chosen generator on the elliptic curve, so that all other elements of the elliptic curve can be obtained by repeatedly applying group operations to G. Scalar multiplication sk sig G sk G to himself sig It is added twice. Scalar multiplication r sig G gives G to himself sig Since G is a group element with (x,y) coordinates, the result of each scalar multiplication is also an (x,y) coordinate, where each of x and y is a function of F base is an element from the base field {0, 1, , q-1}.

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

[0065] The calculation key associated with variant B is calculated using the further components sk as explained below. vrf Similar to variant A, except that it contains:

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

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

[0068] 1.key compute =(sk sig G,r sig ·G,skvrf ·G) / / Similar to variant A, but with the scalar product sk vrf Contains a further component which is G.

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

[0070] Account View Key Generation

[0071] In some embodiments, the view key associated with the account private key is composed of two components (sk) derived from the "variant A" of the account private key as described above. sig ,r sig In some embodiments, the view key associated with the account private key may be generated based on three components (sk) derived from the "variant B" of the account private key as described above. sig ,r sig ,sk vrf ) can be generated based on

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

[0073] 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" is sk sig G and r sig Perform separate concatenation of the x and y components of each scalar multiplication product of G. The resulting concatenated group elements containing (x, y) are then added to F scalar To output the elements of the scalar field {0, 1, , p-1}, it is input to the HashToScalar() function. sig +r sig +HashToScalar(sk sig ·G||r sig The remainder when the sum of G) is divided by p is F scalar The view key key is an element of the scalar field {0, 1, , p-1}. view is.

[0075] 2.Output key view / / key view is F scalar is an element of the scalar field {0, 1, , p-1}. view can be represented using 32 bytes.

[0076] The calculation key associated with variant B is calculated using the further components sk as explained below. vrf Similar to variant A, except that it contains:

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

[0078] 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" is sk sig G, r sig ·G, and, sk vrf Perform a separate concatenation of the x and y components of each scalar multiplication product of G. The resulting concatenated group elements containing (x, y) are then added to F scalar To output the elements of the scalar field {0, 1, , p-1}, it is input to the HashToScalar() function. sig +r sig +HashToScalar(sk sig ·G||r sig The remainder when the sum of G) is divided by p is F scalar The view key key is an element of the scalar field {0, 1, , p-1}. view is.

[0080] 2.Output key view / / key view is F scalar is an element of the scalar field {0, 1, , p-1}. view can be represented using 32 bytes.

[0081] Graph Key Derivation

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

[0083] Variants A and B

[0084] Function GraphKey.FromPrivateKey(key view ):

[0085] 1.key graph=HashToBase(EncodeToF(F base ,“GraphKey0”)||key view ||counter) / / The byte sequence (forming an integer) containing the ASCII encoding of the given value "GraphKey0" is divided by q to obtain F base , resulting in a value of the remainder being a value in the Fbase underlying field {0, 1, , q-1}. The remainder is then encoded as a key value (which can be derived from either variant A or B of the account private key). view ) and (F base , q-1}) is concatenated with the value "counter", which is a selected predetermined element in the underlying field {0, 1, , q-1}. In some embodiments, "counter" is also provided as an input parameter to the GraphKey.FromPrivateKey() function. The concatenation is then performed on the graph key key graph The base is hashed using the function HashToBase() to determine the base.

[0086] 2.Output key graph / / key graph is F base It is an element of the base field {0, 1, . . . , q-1} and can be represented using 32 bytes.

[0087] Account Address

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

[0089] Variants A and B

[0090] Function Address.FromPrivateKey(key view ):

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

[0092] 2. Output address / / Account address is a group element consisting of (x, Y) coordinates, where each element (x or y) is a base Contains elements of the base field {0, 1, , q-1}, where each element can be represented using 32 bytes.

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

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

[0095] 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 ·G's connection is F scalar To output s from the scalar field {0, 1, , q-1}, it is input to the HashToScalar function.

[0097] 2.address=sk sig G+r sig ·G+s·G / / sk sig G+r sig The sum of s G + s G is the address. sig G+r sig The sum of G+s G is used to act as an address. base To obtain a value from the scalar field {0, 1, , q-1}, it is divided by q.

[0098] 3. Output address / / Account address is a group element consisting of (x, Y) coordinates, where each element (x or y) is a base Contains elements of the base field {0, 1, , q-1}, where each element can be represented using 32 bytes.

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

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

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

[0102] 2.address=sk sig G+r sig ·G+s·G / / Same as variant A.

[0103] 3.Output address

[0104] 4 is a flow diagram illustrating one embodiment of a process for deriving a key for managing an account. In some embodiments, the process 400 may be implemented on a client device (such as client device 102 of FIG. 1).

[0105] An account private key associated with the new account is generated at step 402. The account private key is generated at the client device in response to a request to create a new account received at the client device.

[0106] At step 404, a computation key associated with the new account is generated based at least in part on the account private key, where the computation key can be used to verify new transactions confirmed on the blockchain and initiated by the new account. The computation key is derived from the account private key such that the likelihood of recovering the account private key from the computation key is mathematically low. Thus, an entity that receives only the computation key cannot recover the account private key and thus obtain the privileges associated with it. In some embodiments, the computation key corresponding to the new account is used to verify a signature (e.g., generated using the account private key) corresponding to a transaction initiated by the new account holder based at least in part on a portion of the transaction. In some embodiments, the signature, the computation key, and at least a portion of the transaction record are used to generate a zero-knowledge proof associated with the transaction. Such a zero-knowledge proof proves to a verifier that input records exist (having been generated as outputs of previously confirmed transactions), that the serial numbers of these input records were correctly derived, and that the signatures corresponding to these input records are correct. The zero-knowledge proof also ensures that the output record is correctly constructed. Furthermore, the zero-knowledge proof hides from the verifier which input records were used, the signature, the computation key, the addresses of the input records, and the contents of all records. The zero-knowledge proof is then added to the transaction before it is sent to the blockchain network, where nodes in the blockchain network verify at least the zero-knowledge proof during the process of determining whether the transaction's output record should be added to the blockchain ledger.

[0107] At step 406, a view key associated with the new account is generated based at least in part on the account private key, where the view key can be used to decrypt a portion of the transactions confirmed on the blockchain that belong to the new account. The view key is derived from the account private key such that the likelihood of recovering the account private key from the view key is mathematically low. Thus, an entity that receives only the computation key cannot recover the account private key and, therefore, obtain the privileges associated with it. In some embodiments, the view key corresponding to the new account is used to attempt to decrypt encrypted output records of transactions recently confirmed on the blockchain. The output records of the transactions are encrypted using the account address (public key) of the recipient account of the output records, and these encrypted output records are decryptable only using the view key corresponding to the recipient account. Thus, any output record that can be decrypted using the view key corresponding to the new account specifies the new account as the recipient of the output record.

[0108] 5 is a flow chart illustrating an example process for deriving a key from an account private key associated with an account, according to some embodiments. In some embodiments, process 500 may be implemented on a client device (such as client device 102 of FIG. 1). In some embodiments, process 400 of FIG. 4 may be implemented, at least in part, using process 500.

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

[0110] In step 504, an account private key corresponding to the new account is generated. The new account private key corresponding to the new account may be generated according to the examples described above. The account private key should remain secret (e.g., not shared with anyone).

[0111] In step 506, a computation key is generated from the account private key. The computation key corresponding to the new account may be derived from the account private key according to the examples described above. The computation key may be shared with trusted parties.

[0112] At step 508, a view key is generated from the account private key. The view key corresponding to the new account may be derived from the account private key according to the examples described above. The view key may be shared with trusted parties.

[0113] At step 510, a graph key is generated from the view key. The graph key corresponding to the new account may be derived from the view key according to the examples described above. The graph key may be shared with trusted parties.

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

[0115] The account private key, computation key, view key, graph key, and address are stored in step 514. All keys associated with the new account are stored for later retrieval, either locally or via delegation to a trusted third party, for transaction creation, transaction viewing, and transaction analysis (except for the account private key, which should remain secret).

[0116] 6 is a flow chart illustrating an example process for creating a transaction according to some embodiments. In some embodiments, process 600 may be implemented on a client device (such as client device 102 of FIG. 1).

[0117] A request to create a transaction is received from a sender account at step 602. A request to create a transaction is received from an account (sender account).

[0118] At step 604, a transaction is generated to include zero or more input records and an output record. Depending on the nature of the transaction, zero or more confirmed records (which are records that were output records of the transaction confirmed on the blockchain) are selected by the account holder to be included in the transaction. For example, an input record may establish the basis on which the transaction is executed (e.g., the amount of tokens held by the sender account in a transaction involving sending tokens to a recipient account). However, if the transaction does not depend 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, in particular, identifies the recipient's account address and the program (e.g., function) to be executed. The output record is also encrypted with the receiving party's account address, which is included in the output record itself.

[0119] At step 606, an account private key associated with the sender account and at least a portion of the transaction are used to generate a signature. In various embodiments, a signature corresponding to a transaction may be generated by inputting the account private key (e.g., associated with an input record) and at least a portion of the transaction (e.g., the input and output records of the transaction) into a signature generation technique. In particular, in some embodiments, the account private key is generated by an account holder providing components of the account private key (e.g., sk sig ,r sig ) to generate a signature and a unique serial number associated with the transaction's input record. As described below, the signature is then used to generate a zero-knowledge proof that is included in the transaction.

[0120] For example, if a sender account initiates a transaction to send 10 tokens to a receiving party, the input records in this current transaction may be output records of previously confirmed transactions on the blockchain that record that the sender account holds at least 10 tokens. Each input record contains a tuple including the sender's account address, a program associated with the transaction, and data identifying the amount of tokens transferred to the sender account. The sender account's account private key is used to generate the signature associated with the transaction and is also used to generate a serial number associated with the input record. The output record in this transaction records the intended transfer of 10 tokens to the recipient account. The output record contains a tuple including the recipient's account address, a program associated with the transaction, and data identifying that 10 tokens are being transferred to the recipient account. The output record is also encrypted with the recipient's account address so that only a party with a view key belonging to the recipient account can decrypt it and view that 10 tokens were sent by the sender account to the recipient account in this record / transaction. The output record is confirmed and added to the ledger of valid records once the transaction is published to and verified by the blockchain network.

[0121] At step 608, a zero-knowledge proof associated with the transaction is generated based at least in part on the signature, the computation key, and the address associated with the sender account. In various embodiments, a zero-knowledge proof that proves the transaction was initiated by the sender account (and not a fraudster) is generated by inputting the signature, the computation key, and the account address of the sender account into zero-knowledge proof technology. The computation key and the address of the sender account verify the signature associated with the transaction as belonging to the sender 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 step 610, optionally, a tag corresponding to the output record is generated using the graph key associated with the sender account. In some embodiments, the tag may be specific to a particular output record. In some embodiments, the tag is generic to 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] At step 612, the zero-knowledge proof and tag are included in the transaction.

[0124] At step 614, the transaction is sent to be confirmed by the blockchain network. Zero-knowledge proofs are used by the blockchain network to confirm the transaction and determine whether to add the included output records to a list (ledger) of valid output records. In some embodiments, in addition to confirming the transaction using zero-knowledge proofs, the blockchain network also checks whether the unique serial number associated with each input record of the transaction is associated with any previously confirmed transactions before confirming the transaction (e.g., because if so, the input record cannot be consumed / used again). The tag can be used by entities holding a copy of the graph key to regenerate the tag and to use the tag to identify transactions related to the account for purposes of analyzing the transactions for trends and / or anomalous behavior.

[0125] FIG. 7 illustrates an example of a transaction created by a sender account, according to some embodiments. In some embodiments, transaction 700 may be created using a process such as process 600 of FIG. 6. Transaction 700 includes an input record 702, which includes at least the following tuple: sender account address, program, data. Because input record 702 was an output record included in a transaction previously confirmed on the blockchain, input record 702 is a valid input record that can provide the basis for a transaction. The "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 identifies the program (function) that was executed when input record 702 was consumed / spent, and the "data" of input record 702 is the data that input record 702 records. Transaction 700 includes an output record 704, which describes the desired transaction to be performed by the sender account with respect to the recipient account. The output record 704 contains at least the following tuple: recipient account address, program, data. Unlike the input record 702, the output record 704 is not valid until the transaction 700 is confirmed by the blockchain. The "recipient account address" is the account address / public key of the recipient account of the transaction 700. The "program" of the output record 704 identifies the program (function) that is executed when the output record 704 is consumed / used, and the "data" of the input record 702 is the data that the output record 704 records. Furthermore, the output record 704 is encrypted using the recipient account address, which is also the first element of that tuple, so that the output record 704 can only be successfully decrypted using the view key associated with the recipient account, as described above.Transaction 700 further 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 further includes a zero-knowledge proof 708, which is generated based on the signature, a computation key associated with the sender account, and the sender account address. In some embodiments, the signature is generated based on an 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 a sender account to a recipient account, input record 702 records that the sender account has at least 10 tokens, and output record 704 records that the recipient account will receive 10 tokens.

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

[0128] 8 is a flow chart illustrating an example of a process for transaction viewing, according to some embodiments. In some embodiments, process 800 may be implemented on a client device (such as client device 102 of FIG. 1). In some embodiments, process 800 may be implemented on a transaction scanning server (such as transaction scanning server 106 of FIG. 1).

[0129] Process 800 may be performed on a client device used by a given account, as described below, or may be performed by a transaction scanning server to which the client device has delegated process 800 by sharing a view key associated with the given account.

[0130] At step 802, a request is received to determine whether a given account is involved in a confirmed transaction.

[0131] At step 804, recently confirmed output records associated with the confirmed transaction are retrieved. Transactions submitted to the blockchain network are confirmed over time, and after a transaction is confirmed, their output records are added to a list of valid / confirmed output records. Periodically, or in response to a trigger / event, new output records added to the list are retrieved to scan for transactions related to a given account.

[0132] In step 806, the view key associated with a given account is utilized to determine zero or more confirmed output records that can be decrypted using the view key. As described above, each output record is encrypted with the recipient account address included in its tuple. An encrypted output record can only be decrypted using the view key of the recipient account address. Thus, only obtained output records encrypted with the address of the same account for which the view key is used for decryption can be decrypted with that view key. This type of asymmetric encryption ensures that only parties delegated with that view key by an account can view transactions related to that account.

[0133] At step 808, information about zero or more decrypted confirmed output records is presented to the given account. For each decrypted output record that pertains to the given account, at least a portion of the data recorded by the recording is presented in a user interface to the user of the given account. For example, if the decrypted output record indicates that the given account received 10 tokens, this information is presented in the user interface for viewing by the account holder.

[0134] FIG. 9 illustrates a transaction trend analysis according to some embodiments. Track 9 is a flowchart illustrating an example of a process. In some embodiments, the process 900 may be implemented on a client device (such as the client device 102 of FIG. 1). In some embodiments, the process 900 may be implemented on a trend analysis server (such as the trend analysis server 108 of FIG. 1).

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

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

[0137] At step 904, recently confirmed transactions are retrieved. Transactions submitted to the blockchain network are confirmed over time, and after transactions are confirmed, their output records are added to a list of valid / confirmed output records. Periodically, or in response to a trigger / event, new output records added to the list are retrieved for use in determining trends.

[0138] At 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, it is determined whether the confirmed transaction includes a transaction-specific tag. If the transaction includes a transaction-specific tag, control is transferred to step 910. Conversely, if the transaction does not include a transaction-specific tag, control is transferred to step 912. If the confirmed transaction includes the calculated tag, it is determined that the transaction belongs to a given account.

[0140] At step 910, the confirmed transactions are included in a set of transactions for analyzing trends associated with the given account. Transactions determined to include tags generated based on the graph key are transactions determined to be related to the given account. These related transactions may then be analyzed using clustering, machine learning, or another technique to determine general trends and the potential existence of anomalous activity.

[0141] At step 912, it is determined whether there is at least one more confirmed transaction. If there is at least one more confirmed transaction, control is returned to step 906. Conversely, if there are no more confirmed transactions, process 900 ends.

[0142] Although the above-described embodiments have been described in some detail for ease of understanding, the invention is not limited to the details provided. There are many alternative ways of implementing the invention. The disclosed embodiments are illustrative and are not intended to be limiting. [Application Example 1] A system, Memory and a processor connected to the memory; Equipped with The processor: Generate an account private key associated with the new account, generating a computation key associated with the new account based at least in part on the account private key, the computation key usable to verify new transactions confirmed on a blockchain, the new transactions initiated by the new account; a system configured to generate a view key associated with the new account based at least in part on the account private key, the view key being usable to decrypt a portion of transactions confirmed on the blockchain that belong to the new account. [Application Example 2] The system described in Application Example 1, wherein the processor is further configured to generate an address associated with the new account based at least in part on the view key, and the view key is configured to decrypt data encrypted by the address. [Application Example 3] A system as described in Application Example 1, wherein the processor is further configured to generate a graph key associated with the new account based at least in part on the view key, and the graph key is configured to generate a tag based at least in part on the new transaction, and the tag is included in the new transaction to mark the new transaction as associated with the new account. [Application Example 4] A system according to Application Example 1, wherein the processor is further configured to generate the account private key in response to a request to generate the new account. [Application Example 5] In the system according to Application Example 1, the processor further receiving a request to create the new transaction associated with the new account; generating the new transaction to include zero or more input records and an output record, the output record including a recipient account address; a system configured to encrypt the output record using the recipient account address, the encrypted output record being decryptable using a recipient view key corresponding to the recipient account address. [Application Example 6] A system described in Application Example 5, wherein the zero or more input records each include an address associated with the new account, the address being generated at least in part based on the view key. [Application Example 7] The system described in Application Example 5, wherein the zero or more input records include output records of transactions previously confirmed on the blockchain. [Application Example 8] In the system according to Application Example 5, the processor further obtaining a signature corresponding to the new transaction generated based at least in part on the account private key; obtaining a zero-knowledge proof based at least in part on the signature and the computation key; Including the zero-knowledge proof in the new transaction; 1. A system configured to submit the new transaction to be published on the blockchain, wherein the zero-knowledge proof is used by a blockchain network to determine whether the output record is valid. [Application Example 9] In the system according to Application Example 7, the processor further generating a graph key associated with the new account based at least in part on the view key; generating a tag corresponding to the new transaction using the zero or more input records and at least one of the output records; The system is configured to include the tag in the new transaction before submitting the new transaction to be published on the blockchain. [Application Example 10] In the system according to Application Example 1, the processor further receiving a request to determine whether the new account is involved in a transaction confirmed on the blockchain; Obtain a new confirmed output record associated with the confirmed transaction; determining a confirmed output record that can be decrypted using the view key, the confirmed output record being encrypted using an address generated from the view key; The system is configured to present information about the confirmed output records in a user interface. [Application Example 11] In the system according to Application Example 1, the processor further generating a graph key associated with the new account based at least in part on the view key; receiving a request to track trends associated with the new account; Obtaining confirmed transactions on the blockchain; generating respective tags corresponding to the confirmed transactions using the graph keys; determining a portion of the confirmed transaction that includes a corresponding portion of the respective tag; A system configured to analyze the portion of the confirmed transactions related to the new account for trends or unusual activity. [Application Example 12] The system according to Application Example 1, wherein the view key cannot be used to recover the calculation key, and the calculation key cannot be used to recover the view key. [Application Example 13] A method, Generate an account private key associated with the new account, generating a computation key associated with the new account based at least in part on the account private key, the computation key usable to verify new transactions confirmed on a blockchain, the new transactions initiated by the new account; generating a view key associated with the new account based at least in part on the account private key, the view key being usable to decrypt a portion of transactions confirmed on the blockchain that belong to the new account. [Application Example 14] The method described in Application Example 13, further comprising generating an address associated with the new account based at least in part on the view key, the view key being configured to decrypt data encrypted by the address. [Application Example 15] A method as described in Application Example 13, further comprising generating a graph key associated with the new account based at least in part on the view key, the graph key being configured to generate a tag based at least in part on the new transaction, and the tag being included in the new transaction to mark the new transaction as associated with the new account. [Application Example 16] The method according to Application Example 13, further comprising: receiving a request to create the new transaction in association with the new account; generating the new transaction to include zero or more input records and an output record, the output record including a recipient account address; encrypting the output record using the recipient account address, wherein the encrypted output record is decryptable using a recipient view key corresponding to the recipient account address. [Application Example 17] A method as described in Application Example 16, wherein the zero or more input records each include an address associated with the new account, the address being generated at least in part based on the view key. [Application Example 18] The method described in Application Example 16, wherein the zero or more input records include output records of transactions previously confirmed on the blockchain. [Application Example 19] The method according to Application Example 16, further comprising: obtaining a signature corresponding to the new transaction generated based at least in part on the account private key; obtaining a zero-knowledge proof based at least in part on the signature and the computation key; Including the zero-knowledge proof in the new transaction; submitting the new transaction to be published on the blockchain, wherein the zero-knowledge proof is used by a blockchain network to determine whether the output record is valid. [Application Example 20] A computer program product embodied in a non-transitory computer-readable storage medium, computer instructions for generating an account private key associated with the new account; computer instructions for generating a computational key associated with the new account based at least in part on the account private key, the computational key being usable to verify new transactions confirmed on a blockchain, the new transactions initiated by the new account; and computer instructions for generating a view key associated with the new account based at least in part on the account private key, the view key being usable to decrypt a portion of transactions confirmed on the blockchain that belong to the new account.

Claims

1. 1. A system comprising: one or more memories; one or more processors coupled to the one or more memories; Equipped with the one or more processors: Generate an account private key associated with the new account, deriving a computation key associated with the new account from the account private key, the computation key configured to verify new transactions confirmed on a blockchain, the new transactions initiated by the new account, the account private key not being recoverable from the computation key; receiving a request from the new account to create the new transaction, the request including a record associated with the new transaction; generating the new transaction, and generating the new transaction includes: generating a signature based at least in part on the account private key and the record associated with the new transaction; causing a zero-knowledge proof to be generated using, at least in part, the signature, the address associated with the new account, and the computation key; a system configured to send the new transaction including the zero-knowledge proof to a verifier associated with the blockchain, the zero-knowledge proof configured to verify to the verifier that the signature associated with the new transaction belongs to the new account without revealing the signature to the verifier.

2. 2. The system of claim 1, wherein the one or more processors are further configured to generate a view key associated with the new account based at least in part on the account private key, the view key configured to decrypt a portion of transactions confirmed on the blockchain that belong to the new account, the account private key not being recoverable from the computation key; a system configured to generate the address associated with the new account based at least in part on the view key, the view key configured to decrypt data encrypted by the address.

3. 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 view key, the graph key being configured to generate a tag based at least in part on the new transaction, the tag being included in the new transaction to mark the new transaction as associated with the new account.

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

5. 10. The system of claim 1, wherein the records include zero or more input records and an output record, the output record including a recipient account address; the one or more processors are further configured to encrypt the output record using the recipient account address, the encrypted output record being decryptable using a recipient view key corresponding to the recipient account address.

6. 6. The system of claim 5, wherein the zero or more input records each comprise the address associated with the new account, the address being generated based at least in part on a view key derived from the account private key, and the account private key cannot be recovered from the view key.

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

8. 6. The system of claim 5, wherein the one or more processors further comprise: generating a view key associated with the new account based at least in part on the account private key, the view key being configured to decrypt a portion of the transactions confirmed on the blockchain that belong to the new account, the account private key not being recoverable from the view key; generating a graph key associated with the new account based at least in part on the view key; generating a tag corresponding to the new transaction using the zero or more input records and at least one of the output records; The system is configured to include the tag in the new transaction before sending the new transaction to the verifier associated with the blockchain.

9. 10. The system of claim 1, wherein the one or more processors further comprise: generating a view key associated with the new account based at least in part on the account private key, the view key being configured to decrypt a portion of the transactions confirmed on the blockchain that belong to the new account, the account private key not being recoverable from the view key; receiving a request to determine whether the new account is involved in a transaction confirmed on the blockchain; Obtain a new confirmed output record associated with the confirmed transaction; determining a confirmed output record that can be decrypted using the view key, the confirmed output record encrypted using the address associated with the new account; The system is configured to present information about the confirmed output records in a user interface.

10. 10. The system of claim 1, wherein the one or more processors further comprise: generating a view key associated with the new account based at least in part on the account private key, the view key being configured to decrypt a portion of the transactions confirmed on the blockchain that belong to the new account, the account private key not being recoverable from the view key; generating a graph key associated with the new account based at least in part on the view key; receiving a request to track trends associated with the new account; Obtaining a transaction confirmed on the blockchain; generating respective tags corresponding to the confirmed transactions using the graph keys; determining a portion of the confirmed transaction that includes a corresponding portion of the respective tag; A system configured to analyze the portion of the confirmed transactions related to the new account for trends or anomalous activity.

11. 1. A method comprising: Generate an account private key associated with the new account, deriving a computation key associated with the new account from the account private key, the computation key configured to verify new transactions confirmed on a blockchain, the new transactions initiated by the new account, the account private key not being recoverable from the computation key; receiving a request from the new account to create the new transaction, the request including a record associated with the new transaction; generating said new transaction; generating a signature based at least in part on the account private key and the record associated with the new transaction; causing a zero-knowledge proof to be generated using, at least in part, the signature, the address associated with the new account, and the computation key; sending the new transaction including the zero-knowledge proof to a verifier associated with the blockchain, the zero-knowledge proof being configured to verify to the verifier that the signature associated with the new transaction belongs to the new account without revealing the signature to the verifier.

12. 12. The method of claim 11 further comprising: generating a view key associated with the new account based at least in part on the account private key, the view key being configured to decrypt a portion of the transactions confirmed on the blockchain that belong to the new account, the account private key not being recoverable from the view key; generating the address associated with the new account based at least in part on the view key, the view key configured to decrypt data encrypted by the address.

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

14. 12. The method of claim 11, The records include zero or more input records and an output record, the output record including a recipient account address, and the method further comprising: encrypting the output record using the recipient account address, wherein the encrypted output record is decryptable using a recipient view key corresponding to the recipient account address.

15. 15. The method of claim 14, wherein the zero or more input records each comprise the address associated with the new account, the address being generated based at least in part on a view key derived from the account private key, and the account private key cannot be recovered from the view key.

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

17. 1. A computer program product comprising a non-transitory computer-readable storage medium having computer instructions stored therein, the computer instructions, when executed by one or more processors, Generate an account private key associated with the new account, deriving a computation key associated with the new account from the account private key, the computation key configured to verify new transactions confirmed on a blockchain, the new transactions initiated by the new account, the account private key not being recoverable from the computation key; receiving a request from the new account to create the new transaction, the request including a record associated with the new transaction; generating said new transaction; generating a signature based at least in part on the account private key and the record associated with the new transaction; causing a zero-knowledge proof to be generated using, at least in part, the signature, the address associated with the new account, and the computation key; 12. The computer program product of claim 11, wherein the one or more processors perform operations including sending the new transaction, including the zero-knowledge proof, to a verifier associated with the blockchain, the zero-knowledge proof being configured to verify to the verifier that the signature associated with the new transaction belongs to the new account without revealing the signature to the verifier.

Images