HK40011077B - System and method for information protection - Google Patents

Description

Systems and methods for information protection

Technical Field

The present disclosure generally relates to methods and apparatus for information protection.

Background Art

Privacy is important for communications and data transfers between various users. Without protection, users are exposed to the risk of identity theft, illegal transfers, or other potential losses. When communications and transfers are carried out online, the risks become even greater due to the unfettered access to online information.

Summary of the Invention

Various embodiments of the present invention include systems, methods, and non-transitory computer-readable media for information protection.

According to one aspect, a computer-implemented method for information protection includes: committing a transaction amount t of a transaction using a commitment scheme to obtain a transaction commitment value T, wherein the commitment scheme includes at least a transaction blinding factor r_t; generating a first key of a symmetric key pair; encrypting a combination of the transaction blinding factor r_t and the transaction amount t using the first key; and sending the transaction commitment value T and the encrypted combination to a recipient node associated with a recipient of the transaction so that the recipient node verifies the transaction.

In some embodiments, generating the first key includes generating the first key based on a private key SK_A of a sender of the transaction and a public key PK_B of a receiver of the transaction according to a Diffie-Hellman (DH) key exchange protocol.

In some embodiments, the commitment scheme comprises a Pedersen commitment based on at least a transaction blinding factor r_t and having a transaction amount t as the committed value.

In some embodiments, the combination of the transaction blinding factor r_t and the transaction amount t comprises a concatenation of the transaction blinding factor r_t and the transaction amount t.

In some embodiments, sending a transaction commitment value T and an encrypted combination to a recipient node associated with a recipient of a transaction so that the recipient node verifies the transaction includes sending a transaction commitment value T and an encrypted combination to a recipient node associated with the recipient of the transaction, so that the recipient node: generates a second key of a symmetric key pair based on a private key SK_B of the recipient of the transaction and a public key PK_A of the sender of the transaction; decrypts the encrypted combination with the second key generated by the receiving node to obtain a transaction blinding factor r_t and a transaction amount t; and verifies the transaction based at least on the transaction commitment value T, the transaction blinding factor r_t and the transaction amount t.

In some embodiments, causing the receiving node to verify the transaction based on at least the transaction commitment value T, the transaction blinding factor r_t, and the transaction amount t includes causing the receiving node to: reject the transaction in response to determining that the transaction commitment value T does not match the commitment scheme for the transaction amount t based on the transaction blinding factor r_t; and approve the transaction by signing the transaction to generate a receiving signature SIGB to be returned to the sending node associated with the sender in response to determining that the transaction commitment value T matches the commitment scheme for the transaction amount t based on the transaction blinding factor r_t.

In some embodiments, before sending the encrypted combination to a recipient node associated with the recipient, the method further includes: committing the change y of the transaction using a commitment scheme to obtain a change commitment value Y, the commitment scheme including at least a change blinding factor r_y, where the change y is one or more assets of the sender mobilized in the transaction minus the transaction amount t; generating another key based on the sender's private key SK_A and the sender's public key PK_A; and encrypting another combination of the change blinding factor r_y and the change y using the other key.

In some embodiments, the method further includes: in response to receiving the recipient signature SIGB, generating a sender signature SIGA by signing the transaction to approve the transaction; and submitting the transaction including the encrypted combination, the other encrypted combination, the transaction commitment value T, the change commitment value Y, the sender signature SIGA and the recipient signature SIGB to one or more nodes in the blockchain network so that the one or more nodes verify the transaction.

In some embodiments, submitting a transaction including an encrypted combination, another encrypted combination, a transaction commitment value T, a change commitment value Y, a sender signature SIGA, and a receiver signature SIGB to one or more nodes in a blockchain network so that one or more nodes verify the transaction includes: submitting a transaction including an encrypted combination, another encrypted combination, a transaction commitment value T, a change commitment value Y, a sender signature SIGA, and a receiver signature SIGB to one or more nodes in the blockchain network, so that the one or more nodes, in response to successfully verifying the transaction, release the transaction amount t to the receiver, eliminate one or more assets mobilized for the transaction, and release the change y to the sender.

According to another aspect, a non-transitory computer-readable storage medium stores instructions to be executed by a processor to cause the processor to perform operations, the operations including: committing a transaction amount t of a transaction using a commitment scheme to obtain a transaction commitment value T, the commitment scheme including at least a transaction blinding factor r_t; generating a first key of a symmetric key pair; encrypting a combination of the transaction blinding factor r_t and the transaction amount t using the first key; and sending the transaction commitment value T and the encrypted combination to a recipient node associated with a recipient of the transaction so that the recipient node verifies the transaction.

According to another aspect, a system for information protection includes a processor and a non-transitory computer-readable storage medium coupled to the processor, the storage medium storing instructions to be executed by the processor to cause the system to perform operations, the operations including: committing a transaction amount t of a transaction using a commitment scheme to obtain a transaction commitment value T, the commitment scheme including at least a transaction blinding factor r_t; generating a first key of a symmetric key pair; encrypting a combination of the transaction blinding factor r_t and the transaction amount t using the first key; and sending the transaction commitment value T and the encrypted combination to a recipient node associated with a recipient of the transaction so that the recipient node verifies the transaction.

According to another aspect, a computer-implemented method for information protection includes: committing a transaction amount t of a transaction using a commitment scheme to obtain a transaction commitment value T, wherein the commitment scheme includes at least a transaction blinding factor r_t; generating a first key of a symmetric key pair; encrypting a combination of the transaction blinding factor r_t and the transaction amount t using the first key; and sending the transaction commitment value T and the encrypted combination to a receiver node associated with a receiver of the transaction, so that the receiver node: generates a second key of the symmetric key pair based on the receiver's private key SK_B and the sender's public key PK_A, decrypts the encrypted combination using the second key generated by the receiver node to obtain the transaction blinding factor r_t and the transaction amount t, and verifies the transaction based at least on the transaction commitment value T, the transaction blinding factor r_t and the transaction amount t.

According to another aspect, a non-transitory computer-readable storage medium stores instructions to be executed by a processor so that the processor performs the following operations, the operations including: committing a transaction amount t of a transaction using a commitment scheme to obtain a transaction commitment value T, the commitment scheme including at least a transaction blinding factor r_t; generating a first key of a symmetric key pair; encrypting a combination of the transaction blinding factor r_t and the transaction amount t using the first key; and sending the transaction commitment value T and the encrypted combination to a receiver node associated with a receiver of the transaction, so that the receiver node: generates a second key of the symmetric key pair based on the receiver's private key SK_B and the sender's public key PK_A, decrypts the encrypted combination using the second key pair generated by the receiver node to obtain the transaction blinding factor r_t and the transaction amount t, and verifies the transaction based at least on the transaction commitment value T, the transaction blinding factor r_t and the transaction amount t.

According to another aspect, a system for information protection includes a processor and a non-transitory computer-readable storage medium coupled to the processor, the storage medium storing instructions to be executed by the processor to enable the system to perform operations, the operations including: committing a transaction amount t of a transaction using a commitment scheme to obtain a transaction commitment value T, the commitment scheme including at least a transaction blinding factor r_t; generating a first key of a symmetric key pair; encrypting a combination of the transaction blinding factor r_t and the transaction amount t using the first key; and sending the transaction commitment value T and the encrypted combination to a receiver node associated with a receiver of the transaction, so that the receiver node: generates a second key of the symmetric key pair based on the receiver's private key SK_B and the sender's public key PK_A, decrypts the encrypted combination using the second key generated by the receiver node to obtain the transaction blinding factor r_t and the transaction amount t, and verifies the transaction based at least on the transaction commitment value T, the transaction blinding factor r_t and the transaction amount t.

According to another aspect, a computer-implemented method for information protection includes: committing a transaction amount t of a transaction using a commitment scheme to obtain a transaction commitment value T, wherein the commitment scheme includes at least a transaction blinding factor r_t; generating a first key of a symmetric key pair; encrypting a combination of the transaction blinding factor r_t and the transaction amount t using the first key; and sending the transaction commitment value T and the encrypted combination to a receiving node associated with a recipient of the transaction, so that the receiving node: generates a second key of the symmetric key pair based on the recipient's private key SK_B and the sender's public key PK_A, decrypts the encrypted combination using the second key generated by the recipient node to obtain the transaction blinding factor r_t and the transaction amount t, and verifies the transaction based at least on the transaction commitment value T, the transaction blinding factor r_t and the transaction amount t.

According to another aspect, a non-transitory computer-readable storage medium stores instructions to be executed by a processor to cause the processor to perform operations, the operations including: committing a transaction amount t of a transaction using a commitment scheme to obtain a transaction commitment value T, the commitment scheme including at least a transaction blinding factor r_t; generating a first key of a symmetric key pair; encrypting a combination of the transaction blinding factor r_t and the transaction amount t using the first key; and sending the transaction commitment value T and the encrypted combination to a receiver node associated with a receiver of the transaction, so that the receiver node: generates a second key of the symmetric key pair based on the receiver's private key SK_B and the sender's public key PK_A, decrypts the encrypted combination using the second key generated by the receiver node to obtain the transaction blinding factor r_t and the transaction amount t, and verifies the transaction based at least on the transaction commitment value T, the transaction blinding factor r_t and the transaction amount t.

According to another aspect, a system for information protection includes a processor and a non-transitory computer-readable storage medium coupled to the processor, the storage medium storing instructions to be executed by the processor to enable the system to perform operations, the operations including: committing a transaction amount t of a transaction using a commitment scheme to obtain a transaction commitment value T, the commitment scheme including at least a transaction blinding factor r_t; generating a first key of a symmetric key pair; encrypting a combination of the transaction blinding factor r_t and the transaction amount t using the first key; and sending the transaction commitment value T and the encrypted combination to a recipient node associated with a recipient of the transaction, so that the receiving node: generates a second key of the symmetric key pair based on the recipient's private key SK_B and the sender's public key PK_A, decrypts the encrypted combination using the second key generated by the recipient node to obtain the transaction blinding factor r_t and the transaction amount t, and verifies the transaction based at least on the transaction commitment value T, the transaction blinding factor r_t and the transaction amount t.

According to another aspect, a computer-implemented method for information protection includes: obtaining a combination of a transaction blinding factor r_t and a transaction amount t encrypted with a first key of a symmetric key pair, and obtaining a transaction commitment value T, wherein a sender node associated with a sender of the transaction commits to the transaction amount t using a commitment scheme to obtain the transaction commitment value T, and the commitment scheme includes at least the transaction blinding factor r_t; generating a second key of the symmetric key pair; decrypting the obtained combination with a second key generated by a receiver node associated with a receiver of the transaction to obtain the transaction blinding factor r_t and the transaction amount T; and verifying the transaction based at least on the transaction commitment value T, the transaction blinding factor r_t and the transaction amount t.

According to another aspect, a non-transitory computer-readable storage medium stores instructions to be executed by a processor to cause the processor to perform operations, the operations including: obtaining a combination of a transaction blinding factor r_t and a transaction amount t encrypted with a first key of a symmetric key pair, and obtaining a transaction commitment value T, wherein a sender node associated with a sender of the transaction commits the transaction amount t using a commitment scheme to obtain the transaction commitment value T, the commitment scheme including at least the transaction blinding factor r_t; generating a second key of the symmetric key pair; decrypting the obtained combination using a second key generated by a receiver node associated with a receiver of the transaction to obtain the transaction blinding factor r_t and the transaction amount t; and verifying the transaction based at least on the transaction commitment value T, the transaction blinding factor r_t, and the transaction amount t.

According to another aspect, a system for information protection includes a processor and a non-transitory computer-readable storage medium coupled to the processor, the storage medium storing instructions to be executed by the processor to cause the system to perform operations, the operations including: obtaining a combination of a transaction blinding factor r_t and a transaction amount t encrypted with a first key of a symmetric key pair, and obtaining a transaction commitment value T, wherein a sender node associated with a sender of the transaction commits the transaction amount t using a commitment scheme to obtain the transaction commitment value T, the commitment scheme including at least the transaction blinding factor r_t; generating a second key of the symmetric key pair; decrypting the obtained combination using a second key generated by a receiver node associated with a receiver of the transaction to obtain the transaction blinding factor r_t and the transaction amount T; and verifying the transaction based at least on the transaction commitment value T, the transaction blinding factor r_t, and the transaction amount t.

These and other features of the systems, methods, and non-transitory computer-readable media disclosed herein, as well as the functionality of the related elements of the methods of operation and structures, and the economy of assembly and manufacture of parts, will become more apparent after consideration of the following description and appended claims with reference to the accompanying drawings, all of which form a part of this specification, wherein like reference numerals designate corresponding parts throughout the various figures. It should be expressly understood, however, that the drawings are for purposes of illustration and description only and are not intended as a definition of the limits of the invention.

BRIEF DESCRIPTION OF THE DRAWINGS

Certain features of various embodiments of the present technology are set forth with particularity in the appended claims. A better understanding of the features and advantages of the present technology will be obtained by referring to the following detailed description of exemplary embodiments utilizing the principles of the invention and the accompanying drawings, in which:

FIG1 illustrates an exemplary system for information protection according to various embodiments.

FIG2 illustrates exemplary steps of transaction initiation and verification according to various embodiments.

FIG3A illustrates a flow chart of an exemplary method for information protection according to various embodiments.

FIG3B illustrates a flow chart of an exemplary method for information protection according to various embodiments.

FIG4A illustrates a flow chart of an exemplary method for information protection according to various embodiments.

FIG4B illustrates a flow chart of an exemplary method for information protection according to various embodiments.

FIG5 illustrates a block diagram of an exemplary computer system upon which any of the embodiments described herein may be implemented.

DETAILED DESCRIPTION

Because operations are performed by individual nodes (e.g., computing devices) in the network, a blockchain can be considered a decentralized database, often referred to as a distributed ledger. Any information can be written to and stored in the blockchain, or read from the blockchain. Anyone can set up a server and join the blockchain network as a node. Any node can contribute computing power to maintaining the blockchain by performing complex calculations such as hashing to add blocks to the current blockchain. These added blocks can contain various types of data or information. Nodes that contribute computing power to added blocks can be rewarded with tokens (e.g., digital currency units). Because a blockchain has no central node, every node is equal and stores the entire blockchain database.

A node is a computing device or large computer system, such as one that supports a blockchain network and keeps it running smoothly. There are two types of nodes: full nodes and lightweight nodes. Full nodes maintain a complete copy of the blockchain. Full nodes on a blockchain network validate the transactions and blocks they receive and relay them to connected peers to provide consensus verification of transactions. Lightweight nodes, on the other hand, only download a small portion of the blockchain. For example, lightweight nodes are used for digital currency transactions. When a lightweight node wants to conduct a transaction, it communicates with a full node.

This decentralized nature can help prevent the emergence of a centrally controlled administrative center. For example, the Bitcoin blockchain is maintained by a network of communicating nodes in a region running (or equipped with) the Bitcoin software. This disclosure utilizes one or more blockchains or digital currencies, such as Bitcoin and Ethereum. Those skilled in the art will appreciate that the technical solutions disclosed herein can be used or applied to other types of blockchains and digital currencies. In other words, instead of traditional banks, institutions, or administrators, multiple intermediaries exist in the form of computer servers executing the Bitcoin software. These computer servers form a network connected via the Internet, where anyone can join. Transactions accommodated by the network can take the form of "User A wants to send Z bitcoins to User B," where transactions are broadcast to the network using readily available software applications. The computer servers function as Bitcoin servers, which are operable to verify these financial transactions, add records of these transactions to their own copies of the ledger, and then broadcast these ledger additions to other servers in the network.

Maintaining the blockchain is called "mining," and those who perform this maintenance are rewarded with newly created Bitcoin and transaction fees, as described above. For example, nodes can determine whether a transaction is valid based on a set of rules agreed upon by the blockchain network. Miners can be located on any continent and process payments by verifying that each transaction is valid and adding it to the blockchain. This verification is achieved through consensus provided by multiple miners, assuming there is no systematic collusion. Ultimately, all data will be consistent, as computations must meet certain requirements to be valid, and all nodes will be synchronized to ensure the blockchain is consistent. Therefore, data can be stored consistently across the distributed system of blockchain nodes.

Through the mining process, transactions such as asset transfers are verified by network nodes and added to the growing chain of blocks in the blockchain. By traversing the entire blockchain, verification can include, for example, whether the payee has access to the transferred assets, whether the assets have been previously spent, and whether the transferred amount is correct. For example, in a hypothetical transaction issued by a sender (e.g., a Bitcoin transaction based on the UTXO (unspent transaction output) model, an Ethereum transaction based on the account/balance model), the proposed transaction can be broadcast to the blockchain network for mining. Miners need to check whether the transaction is eligible for execution based on the blockchain history. If the sender's wallet balance has sufficient funds based on the existing blockchain history, the transaction is considered valid and can be added to the block. Once the asset transfer is verified, it can be included in the next block to be added to the blockchain.

Blocks are very similar to database records. Each time data is written, a block is created. These blocks are linked and secured using cryptography to form an interconnected network. Each block is connected to the previous block, hence the name "blockchain." Each block typically contains a cryptographic hash of the previous block, the time it was generated, and the actual data. For example, each block consists of two parts: a block header, which records the characteristic values of the current block, and a body, which records the actual data (e.g., transaction data). The chain of blocks is linked through the block header. Each block header can contain multiple characteristic values, such as a version, a hash of the previous block, a Merkle root, a timestamp, a difficulty target, and a nonce. The hash of the previous block contains not only the address of the previous block, but also the hash of the data within the previous block, making the blockchain immutable. A nonce is a number that, when included, produces a hash value with a specified number of leading zeros.

To mine, a node obtains a hash value of the contents of a new block. A nonce (e.g., a random string) is appended to this hash value, resulting in a new string. The new string is hashed again. The final hash value is then compared to a difficulty target (e.g., a level) to determine whether the final hash value is actually less than the difficulty target. If the final hash value is not less than the difficulty target, the nonce is changed and the process is repeated. If the final hash value is less than the difficulty target, the block is added to the chain, the public ledger is updated, and the addition is notified. The node responsible for the successful addition is rewarded with Bitcoin, for example, by adding a reward transaction for itself to the new block (called minting).

That is, for each output "Y," if k is chosen from a distribution with high minimum entropy, it is impossible to find an input x such that H(k|x) = Y, where K is a nonce, x is the hash of the block, Y is the difficulty target, and "|" represents concatenation. Because cryptographic hashes are essentially random, and because their output cannot be predicted from their input, there is only one known way to find a nonce: trying integers one by one, such as 1, then 2, then 3, and so on, which can be called brute force. The greater the number of leading zeros, the longer it takes on average to find the necessary nonce Y. In one example, the Bitcoin system continuously adjusts the number of leading zeros so that the average time to find a nonce is approximately ten minutes. Thus, as the processing power of computing hardware increases over time, over the next few years, the Bitcoin protocol will only need more leading zeros to achieve a mining duration of approximately ten minutes.

As mentioned above, hashing is an important foundation of blockchain. A hash algorithm can be understood as a function that compresses a message of any length into a fixed-length message digest. MD5 and SHA are more commonly used. In some embodiments, the hash value of a blockchain is 256 bits long, meaning that regardless of the original content, a 256-bit binary number is ultimately calculated. And as long as the original content is different, the corresponding hash value is guaranteed to be unique. For example, the hash value of the string "123" is a8fdc205a9f19cc1c7507a60c4f01b13d11d7fd0 (hexadecimal), which has 256 bits when converted to binary, and only "123" has this hash value. The hash algorithm in the blockchain is irreversible. That is, while forward calculation is easy (from "123" to a8fdc205a9f19cc1c7507a60c4f01b1c7507a60c4f01b13d11d7fd0), the reverse calculation is impossible even if all computing resources are exhausted. Therefore, the hash value of each block in the blockchain is unique.

Furthermore, if the contents of a block change, its hash value will also change. Blocks and hash values correspond one-to-one, and the hash value of each block is calculated specifically for the block header. That is, the characteristic values of the block header are concatenated to form a long string, and then the hash value is calculated for this string. For example, "hash value = SHA256(block header)" is the formula for calculating a block hash value, and SHA256 is the blockchain hash algorithm applied to the block header. The hash value is uniquely determined by the block header, not the block body. As mentioned above, the block header contains many contents, including the hash value of the current block and the hash value of the previous block. This means that if the contents of the current block change, or if the hash value of the previous block changes, the hash value of the current block will change. If a hacker modifies a block, the hash value of the block will change. Since the next block must contain the hash value of the previous block, in order for subsequent blocks to be connected to the modified block, the hacker must modify all subsequent blocks in sequence. Otherwise, the modified block will be separated from the blockchain. Due to design reasons, hash value calculation is time-consuming, and it is almost impossible to modify multiple blocks in a short period of time unless the hacker has mastered more than 51% of the computing power of the entire network. Therefore, the blockchain guarantees its own reliability, and once the data is written, it cannot be tampered with.

Once a miner finds the hash of the new block (i.e., a valid signature or solution), it broadcasts the signature to all other miners (nodes in the blockchain). The other miners then verify that the solution corresponds to the sender's block's problem (i.e., determine whether the hash input actually results in the signature). If the solution is valid, the other miners confirm it and agree that the new block can be added to the blockchain. Thus, consensus on the new block is reached. This is also known as "proof of work." The block that has reached consensus can now be added to the blockchain and broadcast to all nodes on the network, along with its signature. As long as the transactions within the block correctly correspond to the current wallet balance (transaction history) at that point in time, the node will accept the block and save it in its transaction data. Every time a new block is added on top of the previous block, the addition also counts as another "confirmation" of the previous block. For example, if a transaction is included in block 502, and the blockchain has 507 blocks, this means that the transaction has five confirmations (corresponding to blocks 507 through 502). The more confirmations a transaction has, the harder it is for an attacker to alter it.

In some embodiments, the exemplary blockchain asset system utilizes public-key cryptography, in which two keys are generated: a public key and a private key. The public key can be considered an account number, while the private key can be considered an evidence of ownership. For example, a Bitcoin wallet is a collection of public and private keys. Knowledge of the private key associated with an asset address can be used to prove ownership of the asset (e.g., digital currency, cash assets, stocks, equities, bonds) associated with that address. For example, Bitcoin wallet software, sometimes referred to as "Bitcoin client software," allows a given user to trade Bitcoin. The wallet program generates and stores private keys and communicates with peers on the Bitcoin network.

In blockchain transactions, the payer and payee are identified in the blockchain by their public keys. For example, most contemporary Bitcoin transfers are from one public key to a different public key. In practice, hashes of these keys are used in the blockchain and are known as "Bitcoin addresses." In principle, if a user's Bitcoin address were used instead of their name, a hypothetical attacker, Person S, could steal money from Person A by simply adding a transaction to the blockchain ledger that reads something like "Person A pays Person S 100 Bitcoins." The Bitcoin protocol prevents this theft by requiring each transfer to be digitally signed with the payer's private key, and only signed transactions can be added to the blockchain ledger. Since Person S cannot forge Person A's signature, Person S cannot deceive Person A by adding an entry to the blockchain that reads "Person A pays Person S 200 Bitcoins." At the same time, anyone can verify Person A's signature using his or her public key and, therefore, verify that he or she authorized any transaction in the blockchain if he or she was the payee.

In the case of a Bitcoin transaction, to transfer some Bitcoin to User B, User A can construct a record containing information about the transaction passing through the node. This record can be signed with User A's signing key (private key) and contain User A's public verification key and User B's public verification key. The signature serves to confirm that the transaction originated from User A and, once published, prevents anyone from altering the transaction. This record, along with other records occurring in the same time window in a new block, can be broadcast to all nodes. Upon receiving the record, the full node can merge it into the ledger of all transactions ever to have occurred in the blockchain system, add the new block to the previously accepted blockchain through the mining process described above, and validate the added block against the network's consensus rules.

The UTXO (unspent transaction output) model and the account/balance model are two exemplary models for implementing blockchain transactions. UTXO is a blockchain object model. According to UTXO, assets are represented by outputs from unspent blockchain transactions, which can be used as inputs in new transactions. For example, user A's to-be-transferred assets may be in the form of UTXOs. To spend (transact) these assets, user A must sign with their private key. Bitcoin is an example of a digital currency that uses the UTXO model. In the case of a valid blockchain transaction, unspent outputs can be used to implement further transactions. In some embodiments, only unspent outputs can be used in further transactions to prevent double spending and fraud. To this end, inputs on the blockchain are deleted when a transaction occurs, while outputs in the form of UTXOs are created. These unspent transaction outputs can be used (by the private key holder, such as someone with a digital currency wallet) for future transactions.

On the other hand, the account/balance model (also known as the account-based transaction model) keeps track of the balance of each account as global state. The account balance is checked to determine if the account balance is greater than or equal to the transaction amount being spent. The following provides an example of how the account/balance model works in Ethereum:

1. Alice obtains 5 Ether through mining. The system records Alice as having 5 Ether.

2. Alice wants to give Bob 1 ether, so the system will first deduct 1 ether from Alice's account, so Alice now has 4 ether.

3. The system then adds 1 ether to Bob's account. The system knows that Bob originally had 2 ether, so Bob's balance increases to 3 ether.

Ethereum's ledger system can be compared to how banks keep accounts. An analogy is using an ATM/debit card. The bank keeps track of how much money is on each debit card, and when Bob needs to spend money, the bank checks its records to ensure he has a sufficient balance before approving the transaction.

Because blockchains and other similar ledgers are completely public, blockchains themselves offer no privacy protection. The public nature of P2P networks means that even though users are not identified by name, it is possible to link transactions to individuals and companies. For example, in cross-border remittances or supply chains, transaction amounts have a very high level of privacy protection value because the specific location and identity of the parties can be inferred using transaction amount information. The subject matter of a transaction can include, for example, money, tokens, digital currencies, contracts, deeds, medical records, customer details, stocks, bonds, equity, or any other asset that can be described in digital form. Although the UTXO model can make transaction amounts private, for example through ring signatures in Monero and zero-knowledge cryptography in Zcash, transaction amounts remain unprotected under the account/balance model. Therefore, the technical problem addressed by this disclosure is how to protect the privacy of online information such as transaction amounts. Such transactions can adopt the account/balance model.

Some existing technologies propose using a Pedersen commitment scheme to encrypt transaction amounts and replace the account/balance model. Under this scheme, the sender sends the transaction amount and a random number corresponding to the Pedersen commitment to the transaction amount to the payee via a secure channel outside the blockchain. The payee verifies that the random number matches the transaction commitment and performs local storage. For example, according to the account/balance model, an account can be considered a wallet (account) for storing assets that are aggregated but not merged. Each asset can correspond to an asset type (e.g., cryptocurrency), and the balance of the account is the sum of the asset values. Even assets of the same type are not merged. During a transaction, the recipient of the transferred assets can be specified, and the corresponding assets can be removed from the wallet to fund the transaction. The blockchain node verifies that the payment wallet has sufficient assets to cover the transaction. The node then removes the transferred assets from the payment wallet and adds the corresponding assets to the recipient's wallet.

However, this approach still has limitations. First, it requires users to maintain local persistent storage to manage the random numbers and plaintext balances corresponding to encrypted account balances, which is complex to implement. Second, the blinding factors (such as random numbers) and plaintext balances corresponding to "Pedersen assets" stored in a single local node are easily lost or damaged, and due to the frequent changes in account balances, multi-node backup storage is difficult to implement.

The systems and methods proposed in this disclosure can overcome the aforementioned limitations and achieve robust privacy protection for transaction amounts, asset values, and blinding factors in commitment schemes. To this end, symmetric keys obtained through the Diffie-Hellman (DH) key exchange protocol can be used to encrypt/decrypt random numbers and plaintext balances, providing convenient management. Furthermore, storing the encrypted information in the blockchain ensures that transaction amounts, asset values, and blinding factors in commitment schemes are not easily lost or tampered with.

Before discussing the figures of this disclosure, the following describes Pedersen commitments and the Diffie-Hellman (DH) key exchange protocol.

In some embodiments, a commitment scheme (e.g., Pedersen commitment) may encrypt a value a (e.g., transaction amount, asset value, key parameter) as follows:

PC(a)＝r×G+a×H

Where r is a random blinding factor (or blinding factor) that provides concealment, G and H are generators/base points of the elliptic curve that reach consensus and can be randomly selected, sn is the value of the commitment, C(sn) is the curve point used as the commitment and given to the other party, and H is another curve point. That is, G and H can be parameters known to the nodes. The "nothing up my sleeve" of H can be generated by hashing the base point G using a hash function that maps from one point to another (H=hash(G)). H and G are public parameters of a given system (e.g., randomly generated points on the elliptic curve). Although an example of a Pedersen commitment in the form of an elliptic curve is provided above, various other forms of Pedersen commitments or other commitment schemes can be used instead.

Commitment schemes keep data confidential but commit data so that the sender of the data cannot later change the data. If one party only knows the commitment value (e.g., PC(a)), they cannot determine which underlying data value (e.g., a) has been committed. The data (e.g., a) and the blinding factor (e.g., r) can later be revealed (e.g., by the initiating node), and the recipient of the commitment (e.g., a consensus node) can run the commitment and verify that the committed data matches the revealed data. This blinding factor exists because without it, someone could attempt to guess the data.

A commitment scheme is a way for a sender (committer) to commit to a value (e.g., a) such that the committed value remains private, but the committed value can be revealed at a later time when the committer reveals the necessary parameters of the commitment process. Strong commitment schemes can be information hiding and computationally binding. Hiding refers to the concept that a given value a and the commitment PC(a) to that value should be unrelated. That is, PC(a) should not reveal information about a. Given PC(a), G, and H, it is almost impossible to know a because of the random number r. A commitment scheme is binding if there is almost no way that two different values can lead to the same commitment. Pedersen commitments are completely hidden and computationally binding under the discrete logarithm assumption. Furthermore, given r, G, H, and PC(a), PC(a) can be verified by determining whether PC(a) = r×G+a×H holds.

Pedersen commitments have the additive property: commitments can be added together, and the sum of a set of commitments is the same as a commitment to the sum of the data (where the blinding factor is set to the sum of the blinding factors):

PC(r ₁ ,data ₁ )+PC(r ₂ ,data ₂ )==PC(r ₁ +r ₂ ,data ₁ +data ₂ );

PC(r ₁ ,data ₁ )-PC(r ₁ ,data ₁ )==0.

In other words, the commitment preserves addition and the commutative property applies, i.e., Pedersen commitments are additively homomorphic in that the underlying data can be mathematically operated on as if it were not encrypted.

In one embodiment, a Pedersen commitment for encrypting input values can be constructed using elliptic curve points. Traditionally, an elliptic curve cryptography (ECC) public key is created by multiplying the generator for a group (G) with a secret key (r): Pub = rG. The result can be serialized as a 33-byte array. ECC public keys can obey the additive homomorphic property mentioned above for Pedersen commitments. That is, Pub1 + Pub2 = (r1 + r2 (mod n))G.

A Pedersen commitment for an input value can be created by picking an additional generator (H, in the equation below) for the group such that no one knows the discrete logarithm of the second generator H with respect to the first generator G (or vice versa), which means that no one knows x such that xG = H. This can be done, for example, by picking H using a cryptographic hash of G:

H=to_point(SHA256(ENCODE(G))).

Given two generators G and H, an exemplary commitment scheme for encrypted input values can be defined as: commitment = rG + aH. Here, r can be a secret blinding factor, and a can be the input value being committed. Therefore, if sn is committed, the above commitment scheme PC(a) = r×G + a×H can be obtained. Pedersen commitments are information-theoretically private: for any commitment, there exists a blinding factor that matches a value with the commitment. Because arbitrary mappings are uncomputable, Pedersen commitments are computationally resistant to false commitments.

The party (node) committing to the value can make the commitment public by disclosing the original value a and the factor r that completes the commitment equation. The party wishing to disclose the value PC(a) will then recalculate the commitment to verify that the shared original value indeed matches the originally received commitment PC(a). Thus, asset type information can be protected by mapping it to a unique serial number and then encrypting it via a Pedersen commitment. The random number r chosen when generating the commitment makes it virtually impossible for anyone to infer the type of the committed asset based on the commitment value PC(a).

In some embodiments, Diffie-Hellman (DH) key exchange can be used as a method for securely exchanging cryptographic keys over a public channel. DH key exchange, also known as exponential key exchange, is a digital encryption method that uses numbers raised to specific powers to generate decryption keys based on components that are never directly communicated, making the task of a potential code cracker mathematically overwhelming.

In an example implementation of Diffie-Hellman (DH) key exchange, two end users, Alice and Bob, communicate over a known private channel and agree on positive integers p and q: p is a prime number and q is a generator of p. Generator q is a number such that when raised to a positive integer power less than p, no two integers produce the same result. While p can be large, q is typically small. That is, q is a primitive root modulo p.

Once Alice and Bob privately agree on p and q, they choose positive integer personal keys a and b, both of which are less than a prime modulus p and both of which can be randomly generated. Users do not reveal their personal keys to anyone, and ideally, they memorize these numbers and do not write them down or store them anywhere. Next, Alice and Bob calculate the public keys a* and b* based on their personal keys according to the formula

a*＝q ^a mod p

and

b*＝q ^b mod p

Two users can share their public keys a* and b* over an assumed insecure communication medium, such as the Internet or a corporate wide area network (WAN). From these public keys, either user can generate a number k1 based on their own personal key.

Alice calculates k1 using the following formula: k1 = (b*) ^a mod p

Bob calculates k1 using the following formula: k1 = (a*) ^b mod p

The value of k1 is proven to be the same using either of the two equations above. However, the personal keys a and b, crucial in the calculation of k1, are not transmitted over a public medium. Even if p, q, a*, and b* are known, calculating a and b remains difficult. Because k1 is a large, apparently random number, a potential hacker has little chance of correctly guessing k1, even after millions of attempts with the help of a powerful computer. Therefore, in theory, two users can use the decryption key k1 to communicate privately over a public medium using their chosen encryption method.

In another example, in an implementation of Diffie-Hellman (DH) key exchange, all computation occurs in a discrete group of sufficient size for the Diffie-Hellman problem to be considered hard, typically a multiplicative group modulo a large prime number (e.g., for classical DH) or an elliptic curve group (e.g., for the Diffie-Hellman elliptic curve).

For both parties of a transaction, each party chooses private key a or private key b.

Each party computes the corresponding public key aG or public key bG.

Each party sends either the public key aG or the public key bG to the other party.

Each party uses the received public key together with its own private key to compute a new shared secret a(bG) = b(aG), which may be referred to as the symmetric key of the symmetric key pair.

As described later, the exemplary method can be used to generate symmetric keys abG and baG. The result of the key exchange is a shared secret, which can then be used with a key derivation function (e.g., an encryption function E() that uses other inputs known to both parties, such as a concatenation of a random number and an asset value) to derive a key set for a symmetric encryption scheme. Alternatively, various other computational methods can be used, for example, by generating public keys g ^a and g ^b and a shared key g ^ab or a shared key g ^ba .

During transactions, information protection is important for protecting user privacy, and transaction amounts are one type of information that lacks protection. FIG1 illustrates an exemplary system 100 for information protection according to various embodiments. As shown, a blockchain network may include multiple nodes (e.g., full nodes implemented in servers, computers, etc.). For some blockchain platforms (e.g., NEO), full nodes with a certain level of voting power may be referred to as consensus nodes, which bear the responsibility for transaction verification. In the present disclosure, full nodes, consensus nodes, or other equivalent nodes may verify transactions.

Furthermore, as shown in Figure 1, user A and user B can perform transactions using respective devices acting as lightweight nodes, such as laptops and mobile phones. For example, user A may want to transact with user B by transferring certain assets from user A's account to user B's account. User A and user B can use respective devices installed with appropriate blockchain software for transactions. User A's device can be referred to as initiator node A, which initiates a transaction with user B's device, referred to as recipient node B. Node A can access the blockchain through communication with node 1, while node B can access the blockchain through communication with node 2. For example, node A and node B can submit a transaction to the blockchain through nodes 1 and 2 to request that a transaction be added to the blockchain. Node A and node B can have other communication channels besides the blockchain (e.g., regular internet communication that does not go through nodes 1 and 2).

Each node in FIG1 may include a processor and a non-transitory computer-readable storage medium storing instructions to be executed by the processor so that the node (e.g., the processor) performs the various steps for information protection described herein. Each node may be installed with software (e.g., a transaction program) and/or hardware (e.g., wired or wireless connections) to communicate with other nodes and/or other devices. Further details of the node hardware and software will be described later with reference to FIG5.

Figure 2 illustrates exemplary steps for a transaction and verification between a sender node A, a receiver node B, and one or more verification nodes, according to various embodiments. The operations presented below are intended to be illustrative. Depending on the implementation, the exemplary steps may include additional, fewer, or alternative steps performed in various orders or in parallel.

In various embodiments, the accounts of the transacting parties (sender user A and recipient user B) are configured for an account/balance model. User A and User B can perform the following steps to execute a transaction via one or more devices (e.g., their laptops, mobile phones, etc.). These devices can be installed with appropriate software and hardware for performing the various steps. Each account can be associated with a cryptographic private key (secret key)-public key pair. The private key can be represented as SK = x, and the public key can be represented as PK = xG, where G is a generator of a group. Each account can contain various assets, each represented as: (V = PC(r,v), E(K,r,v)), where v represents the face value of the asset, V represents a Pedersen commitment to the face value v, r is a blinding factor (e.g., a random number), PC() is the Pedersen commitment algorithm, E() is an encryption algorithm (e.g., a symmetric key encryption algorithm), and K is an encryption key. In one example, each asset can be represented as (V = PC(r,v), E(K,r||v)), where || represents concatenation. Each asset may also include information in addition to the listed information, such as source information of the asset.

In one example, before user A successfully trades amount t to user B in a blockchain-verified transaction, the addresses of the assets in A’s account and B’s account are as follows:

For A's account (Account A):

Address: (SK_A＝a,PK_A＝aG)

Assets A_1 to A_m with values a_1 to a_m are represented as follows:

(A_1=PC(r_{a_1},a_1),E(K_A,r_{a_1}||a_1)),

(A_2=PC(r_{a_2},a_2),E(K_A,r_{a_2}||a_2)),

...

(A_m=PC(r_{a_m},a_m),E(K_A,r_{a_m}||a_m))

For B's account (Account B):

Address: (SK_B=b,PK_B=bG)

Assets B_1 to B_n with values b_1 to b_n are represented as follows:

(B_1＝PC(r_{b_1},b_1),E(K_B,r_{b_1}||b_1)),

(B_2＝PC(r_{b_2},b_2),E(K_B,r_{b_2}||b_2)),

...

(B_n=PC(r_{b_n},b_n),E(K_B,r_{b_n}||b_n))

In some embodiments, for each account under the account/balance model, a key can be generated based on the elliptic curve ecp256k1. For example, on Ethereum ecp256k1, any number between 1 and ^2256-1 can be a valid private key SK. A good library generates a private key while taking into account sufficient randomness. Ethereum requires that the private key SK be 256 bits long. Public key generation is completed using a group operation of ECC cryptography. To derive the public key PK, the private key can be multiplied by G. The multiplication used to derive the public key PK is ECC multiplication (elliptic curve point multiplication), which is different from conventional multiplication. G is a generator point that is one of the domain parameters of ECC cryptography. For ecp256k1, G can have a fixed value. The address can be, for example, the last 20 bytes of the hash value of the public key PK.

In some embodiments, at step 201, node A may initiate a transaction with node B. For example, user A and user B may negotiate a transaction amount t from user A's account A to user B's account B. Account A and account B may correspond to the "wallets" described herein. Account A may have one or more assets. Assets may include, for example, currency, tokens, digital currencies, contracts, deeds, medical records, customer details, stocks, bonds, equities, or any other asset that can be described in digital form. Account B may have one or more assets or no assets. Each asset may be associated with various blockchain information stored in a block of the blockchain, including, for example, a NoteType representing the asset type, a NoteID representing the unique identifier of the asset, a commitment value representing a commitment value (e.g., a Pedersen commitment) of the asset value, a random number, and encryption of the asset value.

As described for account A, in some embodiments, assets A_1 to A_m correspond to asset values a_1 to asset values a_m and random numbers r_1 to r_m, respectively. Based on random numbers r_1 to r_m, node A can submit the asset values in account A to a commitment scheme (e.g., a Pedersen commitment) to obtain an encrypted commitment value. For example, the encrypted commitment value can be PC_1 to PC_m, where PC_i = PC(r_{a_i}, a_i) = r_{a_i}×G+a_i×H, where G and H are known parameters and i is 1 to m. In addition to the first field PC(…), each asset is also associated with a second field E(…), as described above. The second field E(…) can represent the encryption of the corresponding random number and asset value using the key K_A. For example, the encryption can be E(K_A, r_{a_i}||a_i)). The PC(…) and E(…) of each asset can be inherited from previous transactions. The same mechanism can be applied to Account B and its assets.

In some embodiments, K_A may include various types of encryption keys. For example, K_A may be a*PK_A=aaG as further described below, and K_B may be a*PK_B=abG as further described below, where a, b, and G may be multiplied by ECC multiplication.

In some embodiments, to satisfy a transaction amount t, user A can mobilize one or more assets from account A with a total value of at least t. For example, referring to Figure 1, node A can select assets A_1 and A_2 for the transaction. Node A can read assets PC(r_1, a_1) and PC(r_2, a_2) from node 1. Given the random numbers r_1 and r_2, node A can decrypt the read assets PC(r_1, a_1) and PC(r_2, a_2) to obtain the asset values a_1 and a_2, ensuring that the sum of a_1 and a_2 is no less than the transaction amount t. Different assets within an account can be exchanged for each other based on various rates.

In some embodiments, if the amount of the selected asset value exceeds t, y is set as the change. For example, node A may determine the change y = a_1 + a_2 - t. Node A may select a random number r_t and a random number r_y as blinding factors to generate a Pedersen commitment for t and y:

T=PC(r_t,t), Y=PC(r_y,y).

That is, node A may generate a random number r_t for t and a random number r_y for y. Node A may submit t and r_t to a commitment scheme (e.g., homomorphic encryption) to obtain a commitment value T = PC(r_t, t), and submit y and r_y to a commitment scheme (e.g., homomorphic encryption) to obtain a commitment value Y = PC(r_y, y).

In addition, in some embodiments, node A generates a first key a*PK_B=abG of a symmetric key pair and generates another key a*PK_A=aaG. Node A encrypts (r_t||t) using the first key abG, which produces the encryption E(abG, r_t||t), and uses the key aaG to encrypt (r_y||y), producing the encryption E(aaG, r_y||y). Figures 3A and 3B can follow the example. As an alternative to obtaining the encryption E(abG, r_t||t) through node A, user A can send r_t and t along with the transaction information to node B, so that node B generates a second key b*PK_A=baG of the symmetric key pair for encrypting (r_t||t). Node B sends a ciphertext to node A to allow node A to verify. Figures 4A and 4B can follow the example. Although cascading is used in various examples of the present disclosure, alternative combinations of inputs, outputs, or other parameters can be used for encryption functions or other operations.

Furthermore, in some embodiments, if the values of PC(r_t, t) and PC(r_y, y) are each within a valid range, node A may generate a range proof (RP) to prove this to blockchain nodes. For example, in order for PC(r_t, t) to have a valid value, the transaction amount t may be within the valid range [0, ²ⁿ -1]; and in order for PC(r_y, y) to have a valid value, the change y may be within the valid range [0, ²ⁿ -1]. In one embodiment, node A may use block proof technology to generate a range proof (RP) associated with (r_y, y, Y, r_t, t, T), so that blockchain nodes (e.g., consensus nodes) can later verify whether the transaction amount t and change y are within the valid range based on the range proof. Such range proofs may include, for example, bulletproofs, Borromean ring signatures, and the like.

At step 202, node A may send transaction information to node B (e.g., via a secure channel outside the blockchain). The sent transaction information may include, for example, a commitment value T = PC(r_t, t), a commitment value Y = PC(r_y, y), encrypted E(abG, r_t||t), encrypted E(aaG, r_y||y), a range proof RP, and the like. Commitment value Y = PC(r_y, y), encrypted E(aaG, r_y||y), and range proof RP may be optional, as node B may not care about the change sent back to account A. In some embodiments, transactions via a communication channel outside the blockchain can prevent the transaction information from being recorded in the blockchain and prevent nodes other than the sender node A and the recipient node B from obtaining the transaction information. E(aaG, r_y||y) may not need to be sent to node B, but since the change y will be returned to account A, user A may need to spend the change y in the future.

At step 203, node B may verify the random number r_t, the transaction amount t, and the commitment value T. In some embodiments, node B may generate a second key b*PK_A=baG of the symmetric key pair, and use the second key bAG to decrypt the encrypted E(abG, r_t||t) to obtain r_t||t. From r_t||t, node B may obtain r_t and t, and then verify whether r_t and t match T=PC(r_t,t). In other words, node B may verify whether the commitment value T=PC(r_t,t) is correct based on the random number r_t and the transaction amount t according to the Pedersen commitment algorithm. If the match/verification fails, node B may reject the transaction; if the match/verification succeeds, node B may sign the transaction in reply to node A at step 204.

At step 204, Node B may sign the transaction using User B's private key SK_B, thereby generating a signature SIGB. This signature may conform to a digital signature algorithm (DSA), such as the Elliptic Curve Digital Signature Algorithm (ECDSA), so that the recipient of the signature can verify the signature using the signer's public key, thereby authenticating the signed data. The signature SIGB indicates that the recipient, Node B, agrees to the transaction.

At step 205 , node B may send the signed transaction back to node A along with the signature SIGB.

At step 206, if SIGB is not successfully verified, node A may reject the transaction. If SIGB is successfully verified, node A may sign the transaction using user A's private key SK_A, thereby generating a signature SIGA. Similarly, the signature may conform to the Digital Signature Algorithm (DSA). In one embodiment, node A may sign the transaction using user A's private key pair (E(abG, r_t||t); E(aaG, r_y||y); Y; T; RP), thereby generating a signature SIGA.

At step 207, node A may submit the transaction to the blockchain, allowing the blockchain nodes to verify the transaction and determine whether to add the transaction to the blockchain. In one embodiment, node A may submit the transaction (E(abG, r_t||t); E(aaG, r_y||y); Y; T; RP; SIGA; SIGB) to the blockchain via node 1 to execute the transaction. The transaction may include additional parameters or may not include all listed parameters. The transaction may be broadcast to one or more nodes in the blockchain (e.g., consensus nodes) for verification. If verification succeeds, the transaction is added to the blockchain. If verification fails, the transaction is rejected from the blockchain.

At steps 208 to 213, one or more nodes (e.g., consensus nodes) verify the signature, range proof, and other information of the submitted transaction. If the verification fails, the node rejects the transaction. If the verification succeeds, the node accepts the transaction and updates User A's account and User B's account, respectively.

In some embodiments, to execute a transaction, each blockchain node may verify transaction information. Transaction information may include the transaction address TXID, signature, inputs, and outputs. The TXID may include a hash value of the transaction content. The signature may include the signatures of the sender and receiver's keys. Inputs may include the address of the sender's account on the blockchain, one or more assets mobilized from the sender's blockchain account for the transaction, etc. Outputs may include the address of the recipient's account on the blockchain, the asset type of the recipient's asset, the committed value of the recipient's asset, etc. Inputs and outputs may include index information in a tabular format. In some embodiments, the value of a NoteID may be "TXID + index of the asset in the output."

In some embodiments, one or more nodes of the blockchain may verify the submitted transaction (E(abG, r_t||t); E(aaG, r_y||y); Y; T; RP; SIGA; SIGB).

At step 208 , the node may verify whether the transaction has been executed using an anti-double-spending mechanism or an anti-replay attack mechanism. If the transaction has been executed, the node may reject the transaction; otherwise, the method may proceed to step 209 .

At step 209 , the node may check the signature SIGA and the signature SIGB (e.g., based on A's public key and B's public key, respectively). If any signature is incorrect, the node may reject the transaction; otherwise, the method may proceed to step 210 .

At optional step 210, the node may verify whether the asset types are consistent. For example, the node may verify whether the asset type in the NoteType for A_1 to A_2 is consistent with the asset type of the transaction amount t. If any asset type is inconsistent, the node may reject the transaction; otherwise, the method may proceed to step 211. In some embodiments, the original asset type in the wallet may have already been converted to another type based on the exchange rate, so this step can be skipped.

At step 211, the node may check the range proof RP to verify the values of PC(r_t, t) and PC(r_y, y). In one embodiment, the node may check the range proof RP to verify that the transaction amount t is not less than zero and the change y is not less than zero. If verification fails, the node may reject the transaction; otherwise, the method may proceed to step 212.

At step 212, the node may check whether the input and output of the transaction are consistent. If the check fails, the node may reject the transaction; otherwise, the method may proceed to step 213.

At step 213, the node may verify whether Node A has the assets mobilized for the transaction. In one embodiment, the node may perform this verification based on information stored in the blockchain, such as information corresponding to Account A. This information may include previous transaction information for all assets. Thus, the node can determine whether Account A has the transaction assets for the transaction. If this determination is negative, the node may reject the transaction; otherwise, the method may proceed to step 214.

At step 214, the node can update accounts A and B. For example, the node can remove a transaction asset in the amount of t from account A and add it to account B. Based on the homomorphic property, since Y = PC(r_y, y), and node 1 knows r_y and can access the commitment value Y from the blockchain, node 1 can decrypt Y to obtain the change y and return it to account A. Node 2 obtained the random number r_t from node 1 at step 202, and node 2 can also obtain the commitment value T from the blockchain. Therefore, node 2 can decrypt T to obtain the asset value t and add it to account B.

In one example, after updating accounts A and B, account A receives change y for its deployed assets and its undeployed assets. For example, deployed assets may be A_1 and A_2, which are removed in the transaction, with change y returned to account A, and undeployed assets may be A_3, ..., A_m. Account B receives the transaction amount t and its original assets (e.g., B_1, ..., B_n). The assets in A's account and B's account are as follows:

For A's account (Account A), the updated assets are represented as:

(Y＝PC(r_y,y),E(aaG,r_y||y)),

...

(A_m=PC(r_{a_m},a_m),E(K_A,r_{a_m}||a_m))

For B's account (Account B), the updated assets are represented as:

(B_1＝PC(r_{b_1},b_1),E(K_B,r_{b_1}||b_1)),

(B_2＝PC(r_{b_2},b_2),E(K_B,r_{b_2}||b_2)),

...

(B_n=PC(r_{b_n},b_n),E(K_B,r_{b_n}||b_n)),

(T＝PC(r_t,t),E(abG,r_t||t))

Although this disclosure uses Node A/User A and Node B/User B to illustrate the sender and receiver, respectively, the sender and receiver can be the same node/user. For example, the change y for a transaction (the total active assets in Account A minus the transaction amount) can be sent back to the sender of the transaction. Therefore, various steps described herein as being performed by Node B can alternatively be performed by Node A.

Figure 3A shows a flowchart of an exemplary method 300 for information protection according to various embodiments of the present disclosure. Method 300 may be implemented by one or more components of system 100 of Figure 1 (e.g., node A, node 1, a combination of node A and node 1). Method 300 may be implemented by a system or device (e.g., a computer, a server) including a processor and a non-transitory computer-readable storage medium (e.g., a memory), wherein the storage medium stores instructions to be executed by the processor to enable the system or device (e.g., a processor) to perform method 300. The operations of method 300 given below are intended to be illustrative. Depending on the implementation, exemplary method 300 may include additional, fewer, or alternative steps performed in various orders or in parallel.

Block 301 includes committing a transaction amount t of a transaction using a commitment scheme, wherein the commitment scheme includes at least a transaction blinding factor r_t to obtain a transaction commitment value T. For example, as previously described, T = PC(r_t, t). In some embodiments, the commitment scheme includes a Pedersen commitment, which is based on at least the transaction blinding factor r_t and has the transaction amount t as the committed value.

Block 302 includes generating a first key of a symmetric key pair. For example, as previously described, SK_A = a and PK_B = bG, and the first key may be a*PK_B = abG. In some embodiments, generating the first and second keys includes generating the first and second keys based on a private key SK_A of a sender of a transaction and a public key PK_B of a recipient of the transaction according to the Diffie-Hellman (DH) key exchange protocol.

Block 303 includes encrypting the combination (e.g., concatenation) of the transaction blinding factor r_t and the transaction amount t using a first key. For example, as previously described, node A may encrypt (r_t||t) using a first key abG, which produces the encryption E(abG, r_t||t).

Block 304 includes sending the transaction commitment value T and the encrypted combination to a recipient node associated with the recipient of the transaction so that the recipient node can verify the transaction. In some embodiments, sending the transaction commitment value T and the encrypted combination to the recipient node associated with the recipient of the transaction so that the recipient node can verify the transaction includes sending the transaction commitment value T and the encrypted combination to the recipient node associated with the recipient of the transaction, so that the recipient node: generates a second key of a symmetric key pair based on the recipient's private key SK_B and the sender's public key PK_A; decrypts the encrypted combination using the second key generated by the recipient node to obtain a transaction blinding factor r_t and a transaction amount t; and verifies the transaction based on at least the transaction commitment value T, the transaction blinding factor r_t, and the transaction amount t. See, for example, step 203. For example, as previously described, the recipient node can independently generate a second key b*PK_A=baG. The keys abG and baG are symmetric and equal. That is, the receiving node may not receive the first key abG from the sending node, but the receiving node may independently generate the second key baG which is equivalent to abG.

In some embodiments, causing the receiving node to verify the transaction based on at least the transaction commitment value T, the transaction blinding factor r_t, and the transaction amount t includes causing the receiving node to: reject the transaction in response to determining that the transaction commitment value T does not match the commitment scheme for the transaction amount t based on the transaction blinding factor r_t; and approve the transaction by signing the transaction to generate a receiving signature SIGB to be returned to the sending node associated with the sender in response to determining that the transaction commitment value T matches the commitment scheme for the transaction amount t based on the transaction blinding factor r_t.

In some embodiments, before transmitting the encrypted combination to a recipient node associated with the recipient (block 304), the method further includes: committing the change y of the transaction using a commitment scheme to obtain a change commitment value Y, the commitment scheme including at least a change blinding factor r_y, the change y being the one or more assets of the sender mobilized in the transaction minus the transaction amount t; generating another key based on the sender's private key SK_A and the sender's public key PK_A; and encrypting the another combination of the change blinding factor r_y and the change y using the another key. For example, as previously described, Y = PC(r_y, y), PK_A = a, node A can generate a key a*PK_A = aaG and encrypt (r_y||y) using the key aaG, which produces the encryption E(aaG, r_y||y).

In some embodiments, the method further includes: in response to receiving the recipient signature SIGB, generating a sender signature SIGA by signing the transaction to approve the transaction; and submitting the transaction including the encrypted combination, the other encrypted combination, the transaction commitment value T, the change commitment value Y, the sender signature SIGA, and the recipient signature SIGB to one or more nodes in the blockchain network for verification of the transaction. More details are described above with reference to steps 208 to 213.

In some embodiments, submitting a transaction comprising an encrypted combination, another encrypted combination, a transaction commitment value T, a change commitment value Y, a sender's signature SIGA, and a receiver's signature SIGB to one or more nodes in a blockchain network so that the one or more nodes can verify the transaction includes: submitting the transaction comprising the encrypted combination, another encrypted combination, a transaction commitment value T, a change commitment value Y, a sender's signature SIGA, and a receiver's signature SIGB to one or more nodes in the blockchain network, so that the one or more nodes, in response to successfully verifying the transaction, release the transaction amount t to the receiver, eliminate one or more assets mobilized for the transaction, and release change y to the sender. More details are described above with reference to step 214.

3B shows a flowchart of an exemplary method 400 for information protection according to various embodiments of the present disclosure. The method 400 may be implemented by one or more components of the system 100 of FIG. 1 (e.g., Node B, Node 2, a combination of Node B and Node 2, etc.). The method 400 may be implemented by a system or device (e.g., a computer, a server) including a processor and a non-transitory computer-readable storage medium (e.g., a memory), wherein the storage medium stores instructions to be executed by the processor so that the system or device (e.g., a processor) performs the method 400. The operations of the method 400 given below are intended to be illustrative. Depending on the implementation, the exemplary method 400 may include additional, fewer, or alternative steps performed in various orders or in parallel.

Block 401 includes obtaining a combination of a transaction blinding factor r_t and a transaction amount t encrypted using a first key of a symmetric key pair, and obtaining a transaction commitment value T. The transaction commitment value T is obtained by a sender node associated with the sender of the transaction committing to the transaction amount t using a commitment scheme that includes at least the transaction blinding factor r_t. In some embodiments, the first key is generated by the sender node based on a private key SK_A of the sender of the transaction and a public key PK_B of the recipient of the transaction.

Block 402 includes generating a second key of a symmetric key pair. In some embodiments, generating the second key of the symmetric key pair includes generating the second key of the symmetric key pair based on a private key SK_B of a recipient of the transaction and a public key PK_A of a sender according to a Diffie-Hellman (DH) key exchange protocol.

Block 403 includes decrypting the obtained combination using a second key generated by a receiver node associated with the receiver to obtain the transaction blinding factor r_t and the transaction amount t.

Block 404 includes validating the transaction based on at least the transaction commitment value T, the transaction blinding factor r_t, and the transaction amount t.

Instead of encrypting a combination (r_t, t) such as (r_t||t) at node A, node A can send (r_t, t) to node B so that node B encrypts the combination (r_t, t), as described below with reference to Figures 4A and 4B. The other steps and descriptions of Figures 1 to 3B are similarly applicable to Figures 4A and 4B.

Figure 4A shows a flowchart of an exemplary method 440 for information protection according to various embodiments of the present disclosure. Method 440 can be implemented by one or more components of system 100 of Figure 1 (e.g., node A, node 1, a combination of node A and node 1). Method 440 can be implemented by a system or device (e.g., a computer, a server) including a processor and a non-transitory computer-readable storage medium (e.g., a memory), wherein the storage medium stores instructions to be executed by the processor to enable the system or device (e.g., a processor) to perform method 440. The operations of method 440 given below are intended to be illustrative. Depending on the implementation, exemplary method 440 may include additional, fewer, or alternative steps performed in various orders or in parallel.

Block 441 includes committing a transaction amount t of the transaction using a commitment scheme to obtain a transaction commitment value T, wherein the commitment scheme includes at least a transaction blinding factor r_t.

Block 442 includes sending the transaction amount t, the transaction blinding factor r_t, and the transaction commitment value T to a recipient node associated with the recipient of the transaction, so that the recipient node can verify the transaction and encrypt the transaction blinding factor r_t and the transaction amount t with the second key of the symmetric key pair. For example, node B can verify that T = PC(r_t, t) holds, and node B can encrypt the combination with the key b a G to obtain E(b a G, r_t||t).

Block 443 includes obtaining from the recipient node an encrypted combination of the transaction blinding factor r_t and the transaction amount t (eg, E(baG, r_t||t)).

Block 444 includes generating a first key of a symmetric key pair to decrypt the encrypted combination, thereby verifying the transaction. For example, node A may generate a first key abG to decrypt E(baG, r_t||t) and verify that r_t and t are correct. Once r_t and t are mutually verified by the sender and receiver nodes, the transaction may be submitted to the blockchain for verification.

4B shows a flowchart of an exemplary method 450 for information protection according to various embodiments of the present disclosure. Method 450 may be implemented by one or more components of system 100 of FIG. 1 (e.g., Node B, Node 2, a combination of Node B and Node 2, etc.). Method 450 may be implemented by a system or device (e.g., a computer, a server) including a processor and a non-transitory computer-readable storage medium (e.g., a memory), wherein the storage medium stores instructions to be executed by the processor so that the system or device (e.g., a processor) performs method 450. The operations of method 450 given below are intended to be illustrative. Depending on the implementation, exemplary method 450 may include additional, fewer, or alternative steps performed in various orders or in parallel.

Block 451 includes: obtaining the transaction amount t, the transaction blinding factor r_t, and the transaction commitment value T of the transaction.

Block 452 includes verifying the transaction based on the obtained transaction amount t, the obtained transaction blinding factor r_t, and the obtained transaction commitment value T.

Block 453 includes, in response to successfully verifying the transaction, encrypting the transaction blinding factor r_t and the transaction amount t with a second key of the symmetric key pair to obtain an encrypted combination (eg, E(baG, r_t||t)).

Block 454 includes sending the encrypted combination to a sender node associated with the sender of the transaction.

As shown in the figure, the privacy of transaction amounts can be protected through various improvements in computational techniques. For example, the account structure includes one or more fields, such as a first field associated with a Pedersen commitment to an asset value (e.g., the first field is PC(r_{a_i}, a_i), where i is 1 to m), and a second field associated with a Pedersen commitment random number and the asset value (e.g., the second field is E(...)). The first and second fields are also used in the transaction process and stored in the blockchain.

For another example, a symmetric key is used to encrypt the random number and corresponding asset value of each Pedersen commitment, and the transaction including the encrypted random number and asset value is stored on the blockchain. This approach avoids local management of such random numbers and improves security based on distributed and consensus-based blockchain storage.

Furthermore, under the DH key exchange protocol or replacement protocol, even without direct communication, user A and user B share a common key (symmetric key pair abG and baG) for encrypting/decrypting the committed random number and asset value. Since the symmetric key pair is derived from the public-private key pair of the corresponding account, the committed random number can be efficiently stored on the blockchain without the need for further encryption keys.

For another example, range proofs are used to prove that the pre-existing assets traded are balanced with the new assets and the transaction, and that the value of each new asset is within a reasonable range. Furthermore, the transacting parties can send a committed random number and the value of the new asset to the recipient via a secure off-blockchain channel to verify that the committed value matches the value of the transacted assets.

This makes it possible to easily manage the random numbers of Pedersen commitments without the risk of error and without incurring additional key management burdens. Therefore, transaction privacy can be fully protected and transaction amounts can be kept secret.

The techniques described herein are implemented by one or more special-purpose computing devices. A special-purpose computing device may be a desktop computer system, a server computer system, a portable computer system, a handheld device, a networked device, or any other device, or a combination of devices that include hardwiring and/or program logic to implement the techniques. Computing devices are typically controlled and coordinated by operating system software. Traditional operating systems control and schedule computer processes for execution, perform memory management, provide file system, networking, I/O services, and provide user interface functionality, such as a graphical user interface (GUI).

5 is a block diagram illustrating a computer system 500 on which any of the embodiments described herein may be implemented. System 500 may be implemented in any of the nodes described herein and configured to perform the corresponding steps of the information protection method. Computer system 500 includes a bus 502 or other communication mechanism for transmitting information, and one or more hardware processors 504 coupled to bus 502 for processing information. Hardware processors 504 may be, for example, one or more general-purpose microprocessors.

The computer system 500 also includes a main memory 506, such as random access memory (RAM), a cache, and/or other dynamic storage device, coupled to the bus 502 for storing information and instructions to be executed by the processor 504. The main memory 506 can also be used to store temporary variables or other intermediate information to be executed by the processor(s) 504 during the execution of instructions. When these instructions are stored in a storage medium accessible to the processor 504, these instructions cause the computer system 500 to appear as a special-purpose machine customized to perform the operations specified in the instructions. The computer system 500 also includes a read-only memory (ROM) 508 or other static storage device coupled to the bus 502 for storing static information and instructions for the processor 504. A storage device 510, such as a magnetic disk, an optical disk, or a USB thumb drive (flash drive), is provided and coupled to the bus 502 for storing information and instructions.

The computer system 500 may implement the techniques described herein using custom hardwired logic, one or more ASICs or FPGAs, firmware, and/or program logic that, in combination with the computer system, renders the computer system 500 a special-purpose machine or programs the computer system 500 to be a special-purpose machine. According to one embodiment, the computer system 500 performs the operations, methods, and processes described herein in response to the processor 504 executing one or more sequences of one or more instructions contained in the main memory 506. These instructions may be read into the main memory 506 from another storage medium, such as the storage device 510. Execution of the sequences of instructions contained in the main memory 506 causes the processor 504 to perform the process steps described herein. In alternative embodiments, hardwired circuitry may be used in place of, or in combination with, software instructions.

Main memory 506, ROM 508, and/or storage device 510 may include non-transitory storage media. As used herein, the term "non-transitory media" and similar terms refer to media that store data and/or instructions for causing a machine to operate in a specific manner, and the media does not include transient signals. Such non-transitory media may include non-volatile media and/or volatile media. Non-volatile media include, for example, optical or magnetic disks, such as storage device 510. Volatile media include dynamic memory, such as main memory 506. Common forms of non-transitory media include, for example, floppy disks, flexible disks, hard disks, solid-state drives, magnetic tape or any other magnetic data storage medium, CD-ROMs, any other optical data storage medium, any physical medium with a pattern of holes, RAM, PROMs and EPROMs, FLASH-EPROMs, NVRAMs, any other memory chips or storage cartridges, and networked versions thereof.

Computer system 500 also includes a network interface 518 coupled to bus 502. Network interface 518 provides two-way data communication coupled to one or more network links, and the one or more network links are connected to one or more local networks. For example, network interface 518 can be an integrated services digital network (ISDN) card, a cable modem, a satellite modem or a modem that is provided to the data communication connection of the telephone line of the corresponding type. As another example, network interface 518 can be a LAN card that is provided to the data communication connection of a compatible local area network (LAN) (or a WAN component that communicates with a WAN). A wireless link can also be implemented. In any such implementation, network interface 518 sends and receives electrical signals, electromagnetic signals or optical signals that carry digital data streams representing various types of information.

Computer system 500 can send messages and receive data, including program code, through the network, network link, and network interface 518. In the Internet example, a server can transmit the requested code for an application program through the Internet, an ISP, a local network, and network interface 518.

The received code may be executed by processor 504 as it is received, and/or stored in storage 510 or other non-volatile storage for later execution.

Each process, method, and algorithm described in the preceding sections can be implemented in a code module executed by one or more computer systems or computer processors comprising computer hardware, and can be fully automated or partially automated. The processes and algorithms can be implemented partially or fully in dedicated circuits.

The various features and processes described above may be used independently of one another or may be combined in various ways. All possible combinations and sub-combinations will fall within the scope of this disclosure. In addition, certain method or process blocks may be omitted in some implementations. The methods and processes described herein are not limited to any particular order, and the blocks or states associated therewith may be performed in other appropriate orders. For example, the blocks or states described may be performed in an order different from that specifically disclosed, or multiple blocks or states may be combined in a single block or state. The exemplary blocks or states may be performed serially, in parallel, or in some other manner. Blocks or states may be added to or removed from the disclosed exemplary embodiments. The exemplary systems and components described herein may be constructed differently from those described. For example, elements may be added, removed, or rearranged compared to the disclosed exemplary embodiments.

The various operations of the exemplary methods described herein may be performed, at least in part, by an algorithm. The algorithm may be included in program code or instructions stored in a memory (e.g., the non-transitory computer-readable storage medium described above). Such an algorithm may include a machine learning algorithm. In some embodiments, the machine learning algorithm may not explicitly program a computer to perform a function, but may learn from training data to build a predictive model that performs the function.

The various operations of the exemplary methods described herein may be performed, at least in part, by one or more processors that are temporarily or permanently configured (e.g., by software) to perform the relevant operations. Whether temporarily or permanently configured, such processors may constitute a processor-implemented engine that operates to perform one or more operations or functions described herein.

Similarly, the method described herein can be implemented at least in part by a processor, wherein specific one or more processors are examples of hardware. For example, at least some operations of the method can be performed by one or more processors or an engine implemented by the processor. In addition, one or more processors can also be operated to support the performance of related operations in a "cloud computing" environment, or as a "software as a service" (SaaS) operation. For example, at least some operations can be performed by a group of computers (for example, a machine including a processor), which can be accessed via a network (for example, the Internet) and via one or more appropriate interfaces (for example, application program interface (API)).

Certain operational capabilities may be distributed among processors, residing not only within a single machine but also across multiple machines. In some exemplary embodiments, a processor or processor-implemented engine may be located in a single geographic location (e.g., in a home environment, an office environment, or a server farm). In other exemplary embodiments, a processor or processor-implemented engine may be distributed across multiple geographic locations.

Throughout the specification, multiple instances can be implemented as components, operations or structures described as single instances. Although each operation of one or more methods is shown and described as a separate operation, one or more of these separate operations can be performed simultaneously, and do not require these operations to be performed in the order shown. The structure and function presented as a separate component in the exemplary configuration can be implemented as a combined structure or component. Similarly, the structure and function presented as a separate component can be implemented as a separate component. These and other variations, modifications, additions and improvements all fall within the scope of the subject matter of this paper.

Although the overview of the subject matter has been described with reference to specific exemplary embodiments, various modifications and changes may be made to these embodiments without departing from the broader scope of the embodiments of the present invention. If more than one disclosure or concept is actually disclosed, these embodiments of the subject matter may be referred to herein individually or collectively by the term "invention," which is merely for convenience and is not intended to actively limit the scope of the present application to any single disclosure or concept. The detailed description should not be read in a limiting sense, and the scope of the various embodiments is defined solely by the appended claims, along with the full scope of equivalents to which such claims are entitled.

Claims (21)

1. A computer-implemented method for information protection, comprising: The transaction amount t is committed to using a commitment scheme to obtain a transaction commitment value T, wherein the commitment scheme includes at least a transaction blind factor r_t; Generate the first key for a symmetric key pair; Encrypt the combination of the transaction blind factor r_t and the transaction amount t using the first key; and Send the transaction commitment value T and the encrypted combination to the recipient node associated with the recipient of the transaction, such that the recipient node: Generate the second key for the symmetric key pair; The encrypted combination is decrypted using the second key generated by the receiving node to obtain the transaction blind factor r_t and the transaction amount t; and In response to determining that the transaction commitment value T does not match the commitment scheme of the transaction amount t based on the transaction blind factor r_t, the transaction is rejected; in response to determining that the transaction commitment value T matches the commitment scheme of the transaction amount t based on the transaction blind factor r_t, the transaction is approved by generating a receiver signature SIGB to be returned to the sender node associated with the sender through the transaction signature. 2. The method of claim 1, wherein generating the first key comprises: According to the Diffie-Hellman (DH) key exchange protocol, the first key is generated based on the private key SK_A of the sender of the transaction and the public key PK_B of the receiver. 3. The method as described in claim 1, wherein, The commitment scheme includes the Pedersen commitment. The Pedersen commitment is based at least on the transaction blinding factor r_t and has the transaction amount t as the committed value. 4. The method of claim 1, wherein the combination of the transaction blinding factor r_t and the transaction amount t comprises a cascade of the transaction blinding factor r_t and the transaction amount t. 5. The method of claim 1, wherein generating the second key of the symmetric key pair comprises: The second key of the symmetric key pair is generated based on the recipient's private key SK_B and the sender's public key PK_A. 6. The method of claim 1, further comprising, before sending the encrypted combination to the receiver node associated with the receiver: The commitment scheme is used to commit to the change y of the transaction to obtain the change commitment value Y. The commitment scheme includes at least a change blind factor r_y, where the change y is one or more assets of the sender used in the transaction minus the transaction amount t. Generate another key based on the sender's private key SK_A and the sender's public key PK_A; and Encrypt another combination of the zero-finding blind factor r_y and the zero-finding y with the other key. 7. The method of claim 6, further comprising: In response to receiving the recipient signature SIBB, a sender signature SIGA is generated by signing the transaction, thereby approving the transaction; and The transaction, comprising the encrypted combination, another encrypted combination, the transaction commitment value T, the change commitment value Y, the sender signature SIGA, and the receiver signature SIGB, is submitted to one or more nodes in the blockchain network so that the one or more nodes can verify the transaction. 8. The method of claim 7, wherein submitting the transaction comprising the encrypted combination, another encrypted combination, the transaction commitment value T, the change commitment value Y, the sender signature SIGA, and the receiver signature SIBB to the one or more nodes in the blockchain network, so that the one or more nodes verify the transaction, comprises: Submitting a transaction to one or more nodes in the blockchain network, comprising the encrypted combination, another encrypted combination, the transaction commitment value T, the change commitment value Y, the sender signature SIGA, and the receiver signature SIGB, causes the one or more nodes to:, in response to successfully verifying the transaction, publish the transaction amount t to the receiver, eliminate one or more assets used for the transaction, and publish the change y to the sender. 9. A non-transitory computer-readable storage medium storing instructions to be executed by a processor to cause the processor to perform operations, the operations including: The transaction amount t is committed to using a commitment scheme to obtain a transaction commitment value T, wherein the commitment scheme includes at least a transaction blind factor r_t; Generate the first key for a symmetric key pair; Encrypt the combination of the transaction blind factor r_t and the transaction amount t using the first key; and Send the transaction commitment value T and the encrypted combination to the recipient node associated with the recipient of the transaction, such that the recipient node: Generate the second key for the symmetric key pair; The encrypted combination is decrypted using the second key generated by the receiving node to obtain the transaction blind factor r_t and the transaction amount t; and In response to determining that the transaction commitment value T does not match the commitment scheme of the transaction amount t based on the transaction blind factor r_t, the transaction is rejected; in response to determining that the transaction commitment value T matches the commitment scheme of the transaction amount t based on the transaction blind factor r_t, the transaction is approved by generating a receiver signature SIGB to be returned to the sender node associated with the sender through the transaction signature. 10. The storage medium of claim 9, wherein generating the first key comprises: According to the Diffie-Hellman (DH) key exchange protocol, the first key is generated based on the private key SK_A of the sender of the transaction and the public key PK_B of the receiver. 11. The storage medium as claimed in claim 9, wherein, The commitment scheme includes the Pedersen commitment. The Pedersen commitment is based at least on the transaction blinding factor r_t and has the transaction amount t as the committed value. 12. The storage medium of claim 9, wherein the combination of the transaction blinding factor r_t and the transaction amount t comprises a cascade of the transaction blinding factor r_t and the transaction amount t. 13. The storage medium of claim 9, wherein the second key for generating the symmetric key pair comprises: The second key of the symmetric key pair is generated based on the recipient's private key SK_B and the sender's public key PK_A. 14. The storage medium of claim 9, wherein before sending the encrypted combination to the receiver node associated with the receiver, the operation further comprises: The commitment scheme is used to commit to the change y of the transaction to obtain the change commitment value Y. The commitment scheme includes at least a change blind factor r_y, where the change y is one or more assets of the sender used in the transaction minus the transaction amount t. Based on the sender's private key SK_A and the sender's public key PK_A, generate another key; and Encrypt another combination of the zero-finding blind factor r_y and the zero-finding y with the other key. 15. The storage medium of claim 14, wherein the operation further comprises: In response to receiving the recipient signature SIBB, a sender signature SIGA is generated by signing the transaction, thereby approving the transaction; and The transaction, comprising the encrypted combination, another encrypted combination, the transaction commitment value T, the change commitment value Y, the sender signature SIGA, and the receiver signature SIGB, is submitted to one or more nodes in the blockchain network so that the one or more nodes can verify the transaction. 16. The storage medium of claim 15, submitting the transaction comprising the encrypted combination, another encrypted combination, the transaction commitment value T, the change commitment value Y, the sender signature SIGA, and the receiver signature SIGB to the one or more nodes in the blockchain network, so that the one or more nodes may verify the transaction, comprising: Submitting a transaction to one or more nodes in the blockchain network, comprising the encrypted combination, another encrypted combination, the transaction commitment value T, the change commitment value Y, the sender signature SIGA, and the receiver signature SIGB, causes the one or more nodes to:, in response to successfully verifying the transaction, publish the transaction amount t to the receiver, eliminate one or more assets used for the transaction, and publish the change y to the sender. 17. A system for information protection, comprising a processor and a non-transitory computer-readable storage medium coupled to the processor, the storage medium storing instructions to be executed by the processor to cause the system to perform operations, the operations including: The transaction amount t is committed to using a commitment scheme to obtain a transaction commitment value T, wherein the commitment scheme includes at least a transaction blind factor r_t; Generate the first key for a symmetric key pair; Encrypt the combination of the transaction blind factor r_t and the transaction amount t using the first key; and Send the transaction commitment value T and an encrypted combination to the recipient node associated with the recipient of the transaction, such that the recipient node: Generate the second key for the symmetric key pair; The encrypted combination is decrypted using the second key generated by the receiving node to obtain the transaction blind factor r_t and the transaction amount t; and In response to determining that the transaction commitment value T does not match the commitment scheme of the transaction amount t based on the transaction blind factor r_t, the transaction is rejected; in response to determining that the transaction commitment value T matches the commitment scheme of the transaction amount t based on the transaction blind factor r_t, the transaction is approved by generating a receiver signature SIGB to be returned to the sender node associated with the sender through the transaction signature. 18. A computer-implemented method for information protection, comprising: Obtain a combination of a transaction blind factor r_t and a transaction amount t encrypted with a first key of a symmetric key pair, and obtain a transaction commitment value T, wherein the transaction commitment value T is obtained by a sender node associated with the sender of the transaction committing the transaction amount t using a commitment scheme, the commitment scheme including at least the transaction blind factor r_t; Generate the second key for the symmetric key pair; The obtained combination is decrypted using the second key generated by the recipient node associated with the recipient of the transaction to obtain the transaction blind factor r_t and the transaction amount t; and In response to determining that the transaction commitment value T does not match the commitment scheme of the transaction amount t based on the transaction blind factor r_t, the transaction is rejected; in response to determining that the transaction commitment value T matches the commitment scheme of the transaction amount t based on the transaction blind factor r_t, the transaction is approved by generating a receiver signature SIGB to be returned to the sender node associated with the sender through the transaction signature. 19. The method of claim 18, wherein, Generating the second key of the symmetric key pair includes: generating the second key of the symmetric key pair based on the receiver's private key SK_B and the sender's public key PK_A, according to the Diffie-Hellman (DH) key exchange protocol; and The commitment scheme includes Pedersen commitments, which are based at least on the transaction blinding factor r_t and have a transaction amount t as the committed value. 20. A non-transitory computer-readable storage medium storing instructions to be executed by a processor to cause the processor to perform operations, said operations including: Obtain a combination of a transaction blind factor r_t and a transaction amount t encrypted with a first key of a symmetric key pair, and obtain a transaction commitment value T, wherein the transaction commitment value T is obtained by a sender node associated with the sender of the transaction committing the transaction amount t using a commitment scheme, the commitment scheme including at least the transaction blind factor r_t; Generate the second key for the symmetric key pair; The obtained combination is decrypted using the second key generated by the recipient node associated with the recipient of the transaction to obtain the transaction blind factor r_t and the transaction amount t; and In response to determining that the transaction commitment value T does not match the commitment scheme of the transaction amount t based on the transaction blind factor r_t, the transaction is rejected; in response to determining that the transaction commitment value T matches the commitment scheme of the transaction amount t based on the transaction blind factor r_t, the transaction is approved by generating a receiver signature SIGB to be returned to the sender node associated with the sender through the transaction signature. 21. A system for information protection, comprising a processor and a non-transitory computer-readable storage medium coupled to the processor, the storage medium storing instructions to be executed by the processor to cause the system to perform operations, the operations including: Obtain a combination of a transaction blind factor r_t and a transaction amount t encrypted with a first key of a symmetric key pair, and obtain a transaction commitment value T, wherein the transaction commitment value T is obtained by a sender node associated with the sender of the transaction committing the transaction amount t using a commitment scheme, the commitment scheme including at least the transaction blind factor r_t; Generate the second key for the symmetric key pair; The obtained combination is decrypted using the second key generated by the recipient node associated with the recipient of the transaction to obtain the transaction blind factor r_t and the transaction amount T; and In response to determining that the transaction commitment value T does not match the commitment scheme of the transaction amount t based on the transaction blind factor r_t, the transaction is rejected; in response to determining that the transaction commitment value T matches the commitment scheme of the transaction amount t based on the transaction blind factor r_t, the transaction is approved by generating a receiver signature SIGB to be returned to the sender node associated with the sender through the transaction signature.