CN110059494B - Privacy protection method for block chain transaction data and block chain system - Google Patents
Privacy protection method for block chain transaction data and block chain system Download PDFInfo
- Publication number
- CN110059494B CN110059494B CN201910310361.9A CN201910310361A CN110059494B CN 110059494 B CN110059494 B CN 110059494B CN 201910310361 A CN201910310361 A CN 201910310361A CN 110059494 B CN110059494 B CN 110059494B
- Authority
- CN
- China
- Prior art keywords
- account
- sender
- transaction
- balance
- block
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Active
Links
Images
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
- G06F21/60—Protecting data
- G06F21/602—Providing cryptographic facilities or services
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
- G06F21/60—Protecting data
- G06F21/62—Protecting access to data via a platform, e.g. using keys or access control rules
- G06F21/6218—Protecting access to data via a platform, e.g. using keys or access control rules to a system of files or objects, e.g. local or distributed file system or database
- G06F21/6245—Protecting personal data, e.g. for financial or medical purposes
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
- G06Q20/00—Payment architectures, schemes or protocols
- G06Q20/38—Payment protocols; Details thereof
- G06Q20/382—Payment protocols; Details thereof insuring higher security of transaction
- G06Q20/3829—Payment protocols; Details thereof insuring higher security of transaction involving key management
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L67/00—Network arrangements or protocols for supporting network services or applications
- H04L67/01—Protocols
- H04L67/10—Protocols in which an application is distributed across nodes in the network
- H04L67/1097—Protocols in which an application is distributed across nodes in the network for distributed storage of data in networks, e.g. transport arrangements for network file system [NFS], storage area networks [SAN] or network attached storage [NAS]
Landscapes
- Engineering & Computer Science (AREA)
- Theoretical Computer Science (AREA)
- Physics & Mathematics (AREA)
- Bioethics (AREA)
- General Health & Medical Sciences (AREA)
- Business, Economics & Management (AREA)
- General Physics & Mathematics (AREA)
- Computer Security & Cryptography (AREA)
- Health & Medical Sciences (AREA)
- General Engineering & Computer Science (AREA)
- Software Systems (AREA)
- Computer Hardware Design (AREA)
- Accounting & Taxation (AREA)
- Databases & Information Systems (AREA)
- Computer Networks & Wireless Communication (AREA)
- Signal Processing (AREA)
- Medical Informatics (AREA)
- Finance (AREA)
- Strategic Management (AREA)
- General Business, Economics & Management (AREA)
- Financial Or Insurance-Related Operations Such As Payment And Settlement (AREA)
Abstract
The embodiment of the invention relates to the technical field of block chains, and discloses a privacy protection method for block chain transaction data and a block chain system. The privacy protection method of the blockchain transaction data is applied to a blockchain system, and comprises the following steps: and generating an auxiliary key pair with addition homomorphic attributes for the private key association of each user in the block chain system, encrypting the account balance and the transaction amount through an auxiliary public key in the auxiliary key pair, writing a ciphertext obtained by encrypting the transaction amount into the block chain, and updating the corresponding account balance ciphertext in the state tree through the ciphertext according to an addition homomorphic algorithm. By storing the transaction data in the form of the ciphertext on both the block chain and the state tree, the embodiment of the invention solves the technical problem that the privacy protection of the block chain depends on a third-party trusted authority at present, and protects the privacy of the user transaction data.
Description
Technical Field
The present invention relates to the field of blockchain technologies, and in particular, to a method for protecting privacy of blockchain transaction data and a blockchain system.
Background
The block chain (Blockchain) is a distributed database system which is participated by different nodes together, and is an open account book system (leader); it is composed of a string of data blocks or packets generated according to a cryptographic method, i.e. blocks, and each block data information is automatically time-stamped, so as to calculate a data encryption value, i.e. hash value (hash). Each block contains the hash value of the last block, and the linking (chain) is started from the starting block (genesis block) to the current area, thereby forming a block chain. In the world of blockchains, nodes around the world participate in the accounting of the network. For example: through a workload proving mechanism, miners solve the Hash puzzle for the blocks generated by packaging, submit the result to a network, wait for other nodes to verify and confirm the blocks. The nodes express their identities by means of public keys and exercise the right to transfer themselves by means of private keys.
All transaction data, whether in bitcoin or ether house, and the wide variety of public chains that appear later, is exposed in the clear on the blockchain. Although the identity of a person cannot be judged only by the public key, the disclosure of the transaction data makes account tracking feasible, and thus the privacy of the transaction behavior of the account cannot be protected.
At present, a third-party trusted authority is usually introduced to privacy protection of the blockchain, and the third-party trusted authority masters the private key of the whole account book, so that the blockchain loses the decentralized characteristic. If the private key of the organization is lost or compromised, the entire blockchain will always crash. If the user has to apply for inquiry by an organization under the condition of not knowing the balance, the use cost of the user is greatly increased.
Disclosure of Invention
The embodiment of the invention aims to provide a block chain transaction data privacy protection method and a block chain system, which solve the technical problem that the privacy protection of the current block chain depends on a third-party trusted authority in a mode of hiding transaction amount, and protect the user transaction data privacy.
In order to solve the above technical problems, embodiments of the present invention provide the following technical solutions:
in a first aspect, an embodiment of the present invention provides a method for protecting privacy of blockchain transaction data, where the method is applied to a blockchain system, where the blockchain system includes a normal node, a miner node, and a verification node, and the method includes:
step S1, respectively generating an auxiliary key pair (PAh, SAh) according to the private key SA association of the sender A of the transaction, and generating an auxiliary key pair (PBh, SBh) according to the private key SB association of the receiver B;
in step S2, the sender a sends transfer intentions to the receiver B, the transfer intentions including: account balance A, transaction amount, signature of the transfer intention of the sender A by using a private key SA, and an attached public key PAh of the sender A;
step S3, the receiver B receives the transfer intention and sends transaction information to the miner node, the transaction information including: the intent to transfer sent by sender A, the B account balance, the recipient B's signature of the transaction using the private key SB, and the recipient B's affiliated public key PBh;
step S4, after receiving the transaction information, the miner node encrypts the account balance and the transaction amount of the sender A through the affiliated public key PAh of the sender A, encrypts the account balance and the transaction amount of the receiver B through the affiliated public key PBh of the receiver B, verifies the transaction information and adds the transaction information into a block;
step S5, the verification node verifies the block, and the transaction information is written into the block chain after the verification is successful;
in step S6, the regular node receives the block and updates its own state tree.
In some embodiments, the step S1 of generating the affiliated key pair (PAh, SAh) according to the private key SA association of the sender a of the transaction and generating the affiliated key pair (PBh, SBh) according to the private key SB association of the receiver B respectively includes:
associating the sender A private key SA generates an affiliated key pair (PAh, SAh) of the sender A with an addition homomorphic encryption attribute, and associating the receiver B private key SB generates an affiliated key pair (PBh, SBh) of the receiver B with an addition homomorphic encryption attribute.
In some embodiments, the sending of the transfer intention from the sender a to the receiver B in the step S2 further includes:
newly establishing an account C in the state tree;
the transaction amount in the transfer interest that needs to be sent to the recipient B is sent by the sender a to the account C, and the account C sends its full balance to the account of the recipient B.
In some embodiments, the verifying the transaction information in step S4 specifically includes:
judging whether a ciphertext obtained by encrypting the balance of the account A by the auxiliary public key PAh of the sender A is consistent with a balance ciphertext of the account A in the state tree or not, and whether a ciphertext obtained by encrypting the balance of the account B by the auxiliary public key PBh of the receiver B is consistent with a balance ciphertext of the account B in the state tree or not;
judging whether the transaction amount is positive or not and whether the transaction amount is not more than the balance of the account A or not;
the sender a's signature of the intent to commit using the private key SA is verified by the sender a's public key PA, and the recipient B's signature of the transaction using the private key SB is verified by the recipient B's public key PB.
In some embodiments, the adding the transaction information to the block in step S4 includes:
the ciphertext obtained by encrypting the transaction amount with the affiliated public key PAh of the sender a and the ciphertext obtained by encrypting the transaction amount with the affiliated public key PBh of the receiver B are added to the block as transaction information.
In some embodiments, the verifying the block in the step S5 includes:
verifying the legitimacy of all transactions in said block, and,
and verifying the workload certification of the miner node.
In some embodiments, before the normal node receives the tile in step S5, the method further includes:
and verifying whether the signature number of the verification nodes in the block exceeds a threshold value or not according to a Byzantine fault-tolerant protocol, and receiving the block if the signature number of the verification nodes in the block exceeds the threshold value.
In some embodiments, the receiving, by the common node, the block in step S6 and updating its own state tree specifically includes:
the balance of the account A is homomorphic added through a ciphertext obtained by encrypting the transaction amount through an attached public key PAh of the sender A, and the balance of the account A is updated;
and (4) carrying out homomorphic addition on the balance of the account B through a ciphertext obtained by encrypting the transaction amount through the attached public key PBh of the receiver B, and updating the balance of the account B.
In some embodiments, users in the blockchain system use their own public key as a unique identifier of an identity, and the blockchain system generates an affiliated key pair for each user's private key association, where each affiliated key pair includes an affiliated public key and an affiliated private key, and the affiliated private key is used to decrypt a ciphertext encrypted by its corresponding affiliated public key.
In a second aspect, an embodiment of the present invention provides a blockchain system, which applies the above method for protecting privacy of blockchain transaction data, where the blockchain system includes: the system comprises a common node, a miner node and a verification node, wherein the blockchain system generates an affiliated key pair for the private key association of each node.
The embodiment of the invention has the beneficial effects that: in contrast to the prior art, an embodiment of the present invention provides a method for protecting privacy of blockchain transaction data, which is applied to a blockchain system, where the blockchain system includes a normal node, a miner node, and a verification node, and the method includes: step S1, respectively generating an auxiliary key pair (PAh, SAh) according to the private key SA association of the sender A of the transaction, and generating an auxiliary key pair (PBh, SBh) according to the private key SB association of the receiver B; in step S2, the sender a sends transfer intentions to the receiver B, the transfer intentions including: account balance A, transaction amount, signature of the transfer intention of the sender A by using a private key SA, and an attached public key PAh of the sender A; step S3, the receiver B receives the transfer intention and sends transaction information to the miner node, the transaction information including: the intent to transfer sent by sender A, the B account balance, the recipient B's signature of the transaction using the private key SB, and the recipient B's affiliated public key PBh; step S4, after receiving the transaction information, the miner node encrypts the account balance and the transaction amount of the sender A through the affiliated public key PAh of the sender A, encrypts the account balance and the transaction amount of the receiver B through the affiliated public key PBh of the receiver B, verifies the transaction information and adds the transaction information into a block; step S5, the verification node verifies the block, and the transaction information is written into the block chain after the verification is successful; in step S6, the regular node receives the block and updates its own state tree. Through the mode, the embodiment of the invention can solve the technical problem that the privacy protection of the current block chain depends on the third-party trusted authority, and protect the privacy of the user transaction data.
Drawings
One or more embodiments are illustrated by way of example in the accompanying drawings, which correspond to the figures in which like reference numerals refer to similar elements and which are not to scale unless otherwise specified.
Fig. 1 is a block chain system according to an embodiment of the present invention;
fig. 2 is a flowchart illustrating a method for protecting privacy of blockchain transaction data according to an embodiment of the present invention;
FIG. 3 is a schematic diagram of an embodiment of the present invention for generating an affiliated key pair;
FIG. 4 is a schematic flow chart of a transaction provided by an embodiment of the invention;
FIG. 5 is a schematic workflow diagram of an existing PBFT algorithm provided by an embodiment of the present invention;
fig. 6 is a schematic diagram illustrating an update flow of a state tree according to an embodiment of the present invention.
Detailed Description
In order to make the objects, technical solutions and advantages of the embodiments of the present invention clearer, the technical solutions in the embodiments of the present invention will be clearly and completely described below with reference to the drawings in the embodiments of the present invention, and it is obvious that the described embodiments are some, but not all, embodiments of the present invention. All other embodiments, which can be derived by a person skilled in the art from the embodiments given herein without making any creative effort, shall fall within the protection scope of the present invention.
In addition, the technical features involved in the embodiments of the present invention described below may be combined with each other as long as they do not conflict with each other.
The blockchain system has a decentralized feature, which is different from the traditional centralized server, because the blockchain system has no centralized node, it needs a consensus mechanism to maintain normal operation, for example, the consensus mechanism includes a proof of workload algorithm (POW), i.e., POW algorithm, and based on the POW algorithm, the blockchain system can realize the consensus verification of the blocks.
The POW algorithm is a strategy for dealing with denial of service attacks and other services abuses, and a workload certification refers to a data calculation that satisfies a specific condition, which is difficult to generate a correct result, but is simple to verify the correct result. The generation of correct results can only be verified and tried by continuously enumerating random numbers, so that correct answers are finally found. Wherein, the verification trial and error is realized by adopting a hash (hash) algorithm. The hash algorithm is a one-way hash algorithm, the process of calculating the hash value is simple, but the process of calculating the hash value is only performed by enumeration trial and error if the hash value meeting the requirement is obtained.
In some virtual cryptocurrency systems, when performing random hash operations, the POW algorithm introduces a scanning operation for a specific value, for example, in SHA-256, the random hash value starts with one or more 0 s, and as the number of 0 s increases, the amount of work required to traverse the solution corresponding to the random hash value in this case increases exponentially, and only one random hash operation is required to check the result.
Some blocks of a virtual cryptocurrency system are supplemented with a random number (Nonce) that needs to satisfy the condition of a prescribed number of 0's required to cause the hash value of a given block to appear. Due to the irreversible nature of the hash operation, it is only possible to traverse the random numbers that satisfy the condition by trial and error.
As long as the block chain node traverses the random number meeting the condition, the block chain node completes the proof of the workload, thereby obtaining the packing accounting right of the block.
In the world of blockchain, nodes around the world participate in accounting for blockchain networks in common. For example, bitcoin solves the hash puzzle for the block generated by packaging through a workload proving mechanism, and the miners submit the result to the network to wait for other nodes to verify and confirm the block. The nodes express their identities by means of public keys and exercise the right to transfer themselves by means of private keys.
All transaction data, whether in bitcoin or ether house, and the wide variety of public chains that appear later, is exposed in the clear on the blockchain. Although the identity of a person cannot be judged only by the public key, the disclosure of the transaction data makes account tracking feasible, and thus the privacy of the transaction behavior of the account cannot be protected.
In the design of the ChainStack block chain, an original consensus mechanism of deterministic POW is adopted, and in the consensus mechanism, two roles of miners and verifiers exist. Miners need to carry out Hash calculation to solve the mathematical problem, and verifiers verify the blocks of the miners through a practical Byzantine fault-tolerant consensus algorithm and finally submit the blocks to a network. Other nodes accept a block by only verifying the verifier's signature, and such acceptance is deterministic rather than probabilistic validation like bitcoin.
In the ChainStack block chain, the invention introduces a privacy protection method of block chain transaction data, so that the transaction data of a user is stored on the block chain in a ciphertext mode.
Referring to fig. 1, fig. 1 is a schematic diagram illustrating a block chain system according to an embodiment of the present invention; as shown in fig. 1, the blockchain system 100 includes: the system comprises three block chain nodes, namely a common node 11, a miner node 12 and a verification node 13. All the blockchain nodes in the blockchain system have the functions of common nodes, that is, all the blockchain nodes can be a sender of a transaction and can also be a receiver of the transaction.
Any two of the ordinary node 11, the miner node 12 and the verification node 13 support Point-to-Point communication (P2P), and the ordinary node 11, the miner node 12 and the verification node 13 can all be used as block link points in the block link system, and each of them undertakes different responsibilities in the block link system, and commonly maintain the work, stability and safety of the block link system.
The normal node 11 holds the circulated electronic money and has the right to vote in the blockchain system. The regular node 11 may perform the relevant transaction operations but does not have the block's packaged accounting right. The regular node 11 can only synchronize the recording block data from the relevant nodes that possess the packed billing right. The generic node 11 may be the sender of the transaction or the receiver of the transaction.
The miner node 12 is responsible for calculating the hash problem and finding out the blocks. The block is generated based on a random number satisfying a predetermined condition. In some embodiments, the block is generated by the mineworker node 12 using a Proof of work (POW) algorithm, i.e., the hash value to be verified calculated based on the block's random number is less than the target hash value. Wherein, the miner node 12 is converted from the common node 11 by starting the ore excavation mode.
The verification node 13 is configured to identify the verification blocks and record the blocks passing the verification onto the block chain. Wherein, the verification node 13 is generated after the ordinary node 11 submits a registration application and votes for election.
It is understood that the above general node 11, the miner node 12 and the verification node 13 may be a physical server or a logical server virtualized by a plurality of physical servers. The server may also be a server cluster formed by a plurality of servers capable of communicating with each other, and each functional module may be respectively distributed on each server in the server cluster.
Referring to fig. 2, fig. 2 is a flowchart illustrating a method for privacy protection of blockchain transaction data according to an embodiment of the present invention;
as shown in fig. 2, the method for protecting privacy of blockchain transaction data is applied to a blockchain system, where the blockchain system includes a normal node, a miner node, and a verification node, and the method includes:
step S1: generating a pair of affiliated keys (PAh, SAh) from the sender a's private key SA association of the transaction, and a pair of affiliated keys (PBh, SBh) from the recipient B's private key SB association, respectively;
specifically, all blockchain nodes in the blockchain system generate a key pair through an elliptic curve encryption algorithm, wherein the key pair comprises a public key and a private key, all nodes or all users in the blockchain system use their own public keys as unique identifiers of identities and sign transactions through their own private keys, and other nodes or users in the blockchain system verify their signatures through the use of the users' public keys.
In the embodiment of the present invention, the blockchain system generates an affiliated key pair for the private key association of all blockchain nodes (including common nodes, miners' nodes, and verification nodes) in the blockchain system, each affiliated key pair includes an affiliated public key and an affiliated private key, the affiliated public key is used to encrypt account balance and transaction amount, and the affiliated private key is used to decrypt ciphertext encrypted by the corresponding affiliated public key to generate plaintext corresponding to the ciphertext.
Referring to fig. 3, fig. 3 is a schematic diagram of generating an auxiliary key pair according to an embodiment of the present invention;
as shown in fig. 3, the private keys of all blockchain nodes in the blockchain system generate an affiliated key pair through an additive homomorphism algorithm, the private keys are used for signing transfer intention of a certain node or user, and the rest nodes or users in the blockchain system verify the signature through the corresponding public keys of the node or user.
Specifically, the step S1 of generating the affiliated key pair (PAh, SAh) according to the private key SA of the sender a of the transaction and generating the affiliated key pair (PBh, SBh) according to the private key SB of the receiver B respectively includes:
generating an affiliated key pair (PAh, SAh) of the sender a with an addition homomorphic encryption attribute in association with the private key SA of the sender a, and generating an affiliated key pair (PBh, SBh) of the receiver B with an addition homomorphic encryption attribute in association with the private key SB of the receiver B such that the affiliated key pair (PAh, SAh) of the sender a and the affiliated key pair (PBh, SBh) of the receiver B satisfy an addition homomorphic characteristic, i.e., PAh (X + Y) ═ PAh (X) + PAh (Y) and PBh (X + Y) ═ PBh (X) + PBh (Y). In an embodiment of the present invention, Pailliers key pairs are generated by Pailliers' algorithm, which have additive identity, i.e. PAh (X1+ X2) ═ PAh (X1) + PAh (X2) and PBh (X1+ X2) + PBh (X1) + PBh (X2) are satisfied for any plaintext X1 and X2. The affiliated public key PAh of the sender A is used for the miner node to encrypt the balance of the account A and the transaction amount; the recipient B's affiliated public key PBh is used by the mineworker to encrypt B's account balance and transaction amount.
Specifically, the generating an affiliated key pair (PAh, SAh) of the sender a in association with the private key SA of the sender a and generating an affiliated key pair (PBh, SBh) of the receiver B in association with the private key SB of the receiver B based on the additive homomorphic algorithm specifically includes:
hashing the private key SA of the sender A to generate a first seed from which an affiliated key pair (PAh, SAh) of the sender A is generated; the private key SA of the receiver B is hashed to generate a second seed from which an affiliated key pair (PBh, SBh) of the receiver B is generated. Because the generation of Pailliers key pair depends on large prime numbers, the only large prime number is generated through the seeds, so that the random generation of the auxiliary key pair is realized, and because of the existence of randomness, the auxiliary key pair is generated in a seed mode without revealing any information of the private key, thereby ensuring the privacy security of a sender and a receiver.
Step S2: the sender A sends transfer intents to the receiver B, wherein the transfer intents comprise: account balance A, transaction amount, signature of the transfer intention of the sender A by using a private key SA, and an attached public key PAh of the sender A;
specifically, since the transfer intention sent by the sender a to the receiver B includes the account balance a and the transaction amount, in order to further ensure the privacy and security of the sender a when the sender a does not want the receiver B to know the account balance, the sending of the transfer intention from the sender a to the receiver B in step S2 specifically includes:
an account C is newly established in the state tree, the sender A sends the transaction amount in the transfer intention which needs to be sent to the receiver B to the account C, and the account C sends the whole balance to the account of the receiver B. The account C is a temporary account, the account C is an account temporarily generated in the state tree, the account C is used for forwarding the transaction amount in the transfer interest to the receiver B, and the receiver B cannot know the account balance of the sender A due to the forwarding of the temporary account C, so that the privacy information of the sender A is guaranteed not to be leaked. Wherein the account balance of the account C will change from 0 to the transaction amount upon receiving the transaction amount in the transfer interest sent by the sender a, it is understood that the account C will be cleared after the transaction is completed, and at this time the account C may be deleted from the status tree, thereby clearing redundant data of the status tree.
The sender A uses a public key PA of the sender A as a unique identification of the identity, and signs the transfer intention through a private key SA of the sender A.
Step S3: the receiver B receives the transfer intention and sends transaction information to the miner node, wherein the transaction information comprises: the intent to transfer sent by sender A, the B account balance, the recipient B's signature of the transaction using the private key SB, and the recipient B's affiliated public key PBh;
specifically, the receiver B receives the transfer intention sent by the sender a, or the receiver B receives the transfer intention sent by the temporary account C and sends the transaction information to the miner node, wherein the miner node is generated after a common node enters a mining mode, and the miner node is used for receiving the transaction information sent by the receiver B.
Referring to fig. 4 again, fig. 4 is a schematic flow chart of a transaction according to an embodiment of the invention;
as shown in FIG. 4, sender A sends transfer intent to recipient B, the transfer intent including: account balance a, transaction amount, sender a's signature of the intention to transfer using private key SA, and sender a's affiliated public key PAh, for example: the account balance of A is 20 yuan, A wants to transfer 5 yuan to B, which is the signature of A, and the affiliated public key of A is X;
after receiving the transfer intention sent by the sender A, the receiver B packages the transfer intention sent by the sender A and the information of the receiver B into transaction information and sends the transaction information to a miner node, wherein the transaction information comprises: the intent of the transfer sent by sender A, the balance of the B account, the signature of the transaction by receiver B using the private key SB, and the affiliated public key PBh of receiver B, such as: the transfer intention sent by the sender A is as follows: the account balance of A is 20 yuan, A wants to transfer 5 yuan to B, which is the signature of A, the affiliated public key of A is X, and the account information of B is as follows: the account balance of B is 8-tuple, which is the signature of B, and the affiliated public key of B is Y.
Step S4: after receiving the transaction information, the miner node encrypts the balance of the account A and the transaction amount through the attached public key PAh of the sender A, encrypts the balance of the account B and the transaction amount through the attached public key PBh of the receiver B, verifies the transaction information and adds the transaction information into the block;
the block chain is a chain structure composed of blocks, and each block is composed of a block head and a block body. The most important element of the block body is the transaction, and the miners node packs and writes a large number of transactions in the network into the block body, and then writes the hash value formed by connecting the transactions of the block body in series in a certain mode into the block head.
Specifically, after the miner node receives the transaction information, the balance of the account a and the transaction amount are encrypted through the affiliated public key PAh of the sender a in the transaction information to generate a ciphertext of the balance of the account a and a ciphertext of the transaction amount respectively, the account amount of the recipient B and the transaction amount are encrypted through the affiliated public key PBh of the recipient B in the transaction information to generate a ciphertext of the balance of the account B and a ciphertext of the transaction amount respectively, it should be noted that the balance of the account a and the balance of the account B are the current balances of the account a and the account B respectively, that is, the balance of the account before the transaction is completed, and the transaction amount in the transfer intention sent by the sender a is encrypted through the affiliated public key PAh of the sender a and the affiliated public key PBh of the recipient B respectively.
Specifically, the adding the transaction information into the block in the step S4 specifically includes:
the ciphertext obtained by encrypting the transaction amount with the affiliated public key PAh of the sender a and the ciphertext obtained by encrypting the transaction amount with the affiliated public key PBh of the receiver B are added to the block body of the block as transaction information. Specifically, the miner node encrypts the transaction amount with the affiliated public key PAh of the sender a to generate a ciphertext corresponding to the transaction amount, and the miner node encrypts the transaction amount with the affiliated public key PBh of the receiver B to generate the ciphertext corresponding to the transaction amount, which corresponds to the transaction amount being encrypted twice, and the difference between the two is that the ciphertext is encrypted with the affiliated public key PAh of the sender a and the affiliated public key PBh of the receiver B, respectively, and the reason is that: when the state tree changes the account balance of a, the ciphertext encrypted by the affiliated public key PAh of a needs to be homomorphically added, and when the state tree changes the account balance of B, the ciphertext encrypted by the affiliated public key PBh of B needs to be homomorphically added.
Specifically, the verifying the transaction information by the miner node specifically includes:
judging whether a ciphertext obtained by encrypting the balance of the account A by the auxiliary public key PAh of the sender A is consistent with a balance ciphertext of the account A in the state tree or not, and whether a ciphertext obtained by encrypting the balance of the account B by the auxiliary public key PBh of the receiver B is consistent with a balance ciphertext of the account B in the state tree or not;
judging whether the transaction amount is positive or not and whether the transaction amount is not more than the balance of the account A or not;
the sender a's signature of the intent to commit using the private key SA is verified by the sender a's public key PA, and the recipient B's signature of the transaction using the private key SB is verified by the recipient B's public key PB.
Specifically, whether a ciphertext obtained by encrypting the balance of the account a by the sender a is consistent with the balance ciphertext of the account a in the state tree is judged, and since the balance of the account a in the state tree is stored in a ciphertext form, the encryption mode is the same as that of encrypting by the sender a, whether the ciphertext obtained by encrypting the balance of the account a by the sender a is consistent with the balance ciphertext of the account a in the state tree is judged, so that the current balance of the account a can be verified, and if the ciphertext is not consistent with the balance ciphertext, the verification of the transaction by the miner fails, and the miner does not write the transaction into the block;
similarly, whether a ciphertext obtained by encrypting the balance of the account B by the accessory public key PBh of the receiver B is consistent with the balance ciphertext of the account B in the state tree is judged, because the balance of the account B in the state tree is stored in a ciphertext form, the encryption mode is the same as that of the accessory public key of the receiver B, whether the ciphertext obtained by encrypting the balance of the account B by the accessory public key PBh of the receiver B is consistent with the balance ciphertext of the account B in the state tree is judged, the current balance of the account B can be verified, and if the ciphertext is not consistent with the balance ciphertext, the verification of the transaction by the miner fails, and the miner does not write the transaction into the block;
determining whether the transaction is a reasonable transaction by judging whether the transaction amount is positive and whether the transaction amount is not greater than the balance of the account A, if the transaction amount is not positive or the transaction amount is greater than the balance of the account A, determining that the transaction is an abnormal transaction, and if the verification fails, the miner node does not write the transaction into a block;
verifying the signature of the sender A on the transfer intention by using the private key SA through the public key PA of the sender A, and verifying the signature of the receiver B on the transaction by using the private key SB through the public key PB of the receiver B, so that the transaction can be determined to be sent by the sender A himself, and the transaction is determined to be received by the receiver B.
The miner node, upon receiving the transaction, passes multiple verifications, such as: judging whether a ciphertext obtained by encrypting the balance of the account A by the auxiliary public key PAh of the sender A is consistent with a balance ciphertext of the account A in the state tree or not, and whether a ciphertext obtained by encrypting the balance of the account B by the auxiliary public key PBh of the receiver B is consistent with a balance ciphertext of the account B in the state tree or not; judging whether the transaction amount is positive or not and whether the transaction amount is not more than the balance of the account A or not; verifying the signature of the sender A on the transfer intention by using the private key SA through the public key PA of the sender A, verifying the signature of the receiver B on the transaction by using the private key SB through the public key PB of the receiver B, if any verification step fails, the miner node abandons the transaction to be written into a block, and if all verification steps are correct, the transaction is added into the block, so that the validity of the transaction is ensured.
In an embodiment of the present invention, the adding the transaction to the block specifically includes: the miner node adds the transaction into the block body of the block and packages the transaction together with other qualified transactions, specifically, after receiving the transaction, the miner node packages the transaction and more other transactions into the same block together, and executes a hash certification of the workload certification on the block, and after solving a hash puzzle, the miner node transmits the block to a verification node for verification. The transaction that the miner node is added into the block body does not include the attached public keys of the sender A and the receiver B, but the ciphertext obtained by encrypting the transaction amount by the attached public key PAh of the sender A and the ciphertext obtained by encrypting the transaction amount by the attached public key PBh of the receiver B are stored in the block body, so that all transaction amounts in a block chain are guaranteed to be in a ciphertext form, and the information security of the node or the user is guaranteed.
It can be understood that the ciphertext obtained by encrypting the account balance of the sender a with the affiliated public key PAh of the sender a and the ciphertext obtained by encrypting the account balance of the receiver B with the affiliated public key PBh of the receiver B are not stored in the block, but stored in the state tree of the block chain node, and are continuously updated according to the continuous accumulation of the transactions in the block, so as to ensure the stable operation of the block chain system.
Step S5: the verification node verifies the block, and writes the transaction information into a block chain after the verification is successful;
specifically, after the miner node writes the transaction into the block, the block is submitted to the verification node for verification, the verification node recognizes the verification block in common, and the block which is successfully verified is recorded on the block chain.
Specifically, the verifying the block by the verifying node includes:
verifying the legitimacy of all transactions in the block, and verifying the proof of workload submitted by the mineworker node.
Specifically, the verifying the validity of all transactions in the block includes:
checking signatures of all transactions, said signatures comprising: the signature of the sender and the signature of the receiver, and checking the validity of the block, whether the merkel root is correct.
Specifically, the verifying the workload certification submitted by the miner node includes: and identifying the verification blocks in common according to a Byzantine fault-tolerant algorithm.
The verification node verifies the block generated by the miner node through a Deterministic Proof of work (DPoW), wherein the DPoW consists of two stages, namely a Proof of work (POW) and a Practical Byzantine Fault-tolerant algorithm (PBFT), and the safety of the two stages is combined. The POW ensures that miners cannot generate legal blocks without paying calculation power, the PBFT ensures the consistency of network processing results, and blocks generated by nodes of the miners can be accepted by a block chain network only after being checked by the PBFT consensus of the verification nodes.
The PBFT (Practical Byzantine Fault Tolerance) is a state machine copy replication algorithm, i.e., a service is used as a state machine to perform modeling, and the state machine performs copy replication at different nodes of a distributed system. The copies of each state machine preserve the state of the service and also enable the operation of the service. The set of all replicas is represented using the capital letter R, each replica being represented using an integer from 0 to | R | -1. For convenience of description, it is assumed that | R | ═ 3f +1, where f is the maximum number of copies that are likely to fail. Although there may be more than 3f +1 copies, the additional copies may not improve reliability except for reduced performance.
All copies operate in a rotation process called View (View). In a view, one copy acts as primary node (primary) and the other copies act as backups. Views are consecutively numbered integers. The master node is calculated by the formula p ═ v mod | R |, where v is the view number, p is the copy number, and | R | is the number of copy sets. A view change process needs to be initiated when the primary node fails.
Based on the problem of the general Byzantine, the PBFT consistency is mainly ensured in three stages: pre-preparation (pre-preparation), preparation (preparation) and confirmation (commit).
In the following, the embodiment of the present invention details the main workflow of PBFT with reference to fig. 5:
in fig. 5, C is a request sending end, 0123 is a server, and 3 is a down server, and the specific steps are as follows:
request: the sending requester C sends a request to any node, here 0.
2, Pre-Prepare: and the server 0 broadcasts after receiving the request of C and spreads the request to the servers 1, 2 and 3.
Prepare: and the service terminals 1, 2 and 3 record and broadcast again after receiving the information, wherein 1- >023, 2- >013 and 3 cannot broadcast due to downtime.
Commit: if the server 0123 node receives more than a certain number of the same requests in the Prepare phase, it enters the Commit phase and broadcasts the Commit request.
Reply: the service end 0123 node feeds back C if it receives more than a certain number of the same requests in Commit stage.
When the number of nodes at the server is greater than 100, the network bandwidth pressure is increased, and therefore, the pure PBFT consensus cannot satisfy the public link network with a large number of nodes.
In this embodiment of the present invention, before the verifying node verifies the block, the method further includes:
and selecting a plurality of verification nodes, wherein each verification node is used for verifying the block generated by the miner node. When each verification node passes the verification of the block generated by the miner node, the verification node signs the block, and if the verification fails, the verification node does not sign the block.
When the verification node successfully verifies the block, the verification node writes the transaction information into a block chain, for example: and writing the balance of the account A and the balance of the account B into the blockchain. The balance of the account A and the balance of the account B are stored on the block chain in a ciphertext mode, the ciphertext of the balance of the account A is the ciphertext obtained by encrypting the balance of the account A through an affiliated public key PAh of the account A by a miner node, and the ciphertext of the balance of the account B is the ciphertext obtained by encrypting the balance of the account B through an affiliated public key PBh of the account B by the miner node. In addition, because the auxiliary private key of the auxiliary key pair can decrypt the encrypted ciphertext of the corresponding auxiliary public key, when the user forgets or wants to query the account balance of the user, the user can obtain the account balance of the user on the block chain, and the requirement of the user can be further met on the premise of ensuring the privacy.
Step S6: and the common node receives the block and updates the state tree of the common node.
Specifically, after a new block is added to the blockchain, a new transaction is generated, all the blockchain link points in the blockchain system need to update their own state trees, and when a common node receives the new block, the following operations are performed:
(1) verifying 2/3 whether the signature number of the verification node of the block reaches the total number of the verification nodes of the block chain system according to Byzantine fault tolerance protocol, and receiving the block if the signature number of the verification node of the block reaches the total number of the verification nodes of the block chain system. Specifically, according to the byzantine fault-tolerant protocol, whether the signature number of verification nodes in the block exceeds a threshold is verified, if yes, the block is received, wherein the threshold is 2/3 of the number of the verification nodes, if the block passes the verification of the verification nodes, the verification nodes sign the block, and the common node judges whether the signature number of the verification nodes signing the block exceeds two thirds of the number of all the verification nodes in the block chain system, and if yes, the block is received.
(2) And updating the balance ciphertext of the account related to the transaction in the state tree by using the addition homomorphism according to the transaction in the block, wherein the balance ciphertext comprises the balance ciphertext of the sender and the balance ciphertext of the receiver. For example: and if the balance of the account B in the state tree is X1 and the amount ciphertext received by the account B in the blockchain transaction is X2, updating the balance ciphertext of the account B to be X1+ X2.
In this embodiment of the present invention, the receiving, by the common node, the block and updating the state tree of the common node itself specifically includes:
the balance of the account A is homomorphic added through a ciphertext obtained by encrypting the transaction amount through an attached public key PAh of the sender A, and the balance of the account A is updated;
and (4) carrying out homomorphic addition on the balance of the account B through a ciphertext obtained by encrypting the transaction amount through the attached public key PBh of the receiver B, and updating the balance of the account B.
Specifically, in the state tree, the account balances of all the block chain nodes are stored in the form of balance ciphertexts, for example: the account balances of the sender A and the receiver B are stored through balance ciphertexts, the balance ciphertexts corresponding to the account balance of the sender A are A balance ciphertexts, and the balance ciphertexts corresponding to the account balance of the receiver B are B balance ciphertexts. The balance ciphertext of all the block chain nodes in the state tree is generated through an addition homomorphic algorithm, and the addition homomorphic algorithm has addition homomorphism, so that the balance ciphertext can be subjected to homomorphic addition, and the balance ciphertext can be updated, namely the account balance is updated.
Specifically, please refer to fig. 6, fig. 6 is a schematic diagram illustrating a process of updating a state tree according to an embodiment of the present invention;
as shown in fig. 6, after the block chain node receives the block, according to the sender and the receiver of the transaction in the block, and the transaction amount, wherein the transaction amount is encrypted by the affiliated public key and stored on the block in the form of ciphertext, two ciphertext obtained by encrypting the transaction amount respectively by the affiliated public key PAh of the sender a and the ciphertext obtained by encrypting the transaction amount by the affiliated public key PBh of the receiver B may be stored in the transaction amount. Specifically, after the common node receives the block, the state tree of the common node is updated based on the addition homomorphism according to the two parties of the transaction and the ciphertext of the transaction amount. After a transaction is issued to a block chain, all block chain nodes on the block chain system update their own state trees respectively, and through addition homomorphism, if a certain block chain node does not update its own state tree, the state tree is inconsistent with the state tree data of other nodes, which may cause data errors sent by the block chain node, and thus is not acknowledged by the whole network.
As shown in fig. 6, the transaction information included in the block is: the transaction amount transmitted to the B by the A is MIWEN, and after the block chain node receives the block, the state tree of the block chain node is updated according to the transaction information, for example: the state tree is, before updating: and when the balance of the account A is MIWENA and the balance of the account B is MIWENB, after the block is received, according to the transaction information: and the transaction amount transmitted to the B by the A is MIWEN, the balance of the account A is updated to MIWENA-MIWEN, and the balance of the account B is updated to MIWENB + MIWEN, so that the real-time property of the state tree is maintained, and the block chain node can be ensured to legally participate in the transaction.
It is understood that the transaction in the block provided by the embodiment of the present invention is only one, and in practical cases, the transaction in the block may be multiple, and when the transaction in the block is multiple, the operation manner is the same, and the present invention is also within the protection scope of the present invention.
It can be understood that although the data on the blockchain and the data in the state tree are both stored in the form of ciphertext, the miners' nodes and the verification node can still verify the validity of the transaction, so that the normal operation of the consensus protocol is not affected.
In an embodiment of the invention, a block link point comprises one or more of processing and memory. Wherein the processor and the memory may be connected by a bus or other means.
The memory, which is a non-volatile computer-readable storage medium, may be used to store non-volatile software programs, non-volatile computer-executable programs, and modules. The processor executes various functional applications and data processing by executing non-volatile software programs, instructions, and modules stored in the memory.
The memory may include high speed random access memory and may also include non-volatile memory, such as at least one magnetic disk storage device, flash memory device, or other non-volatile solid state storage device. In some embodiments, the memory optionally includes memory located remotely from the processor, and such remote memory may be coupled to the processor via a network. Examples of such networks include, but are not limited to, the internet, intranets, local area networks, mobile communication networks, and combinations thereof.
The block link points of embodiments of the present invention exist in a variety of forms, including but not limited to:
(1) tower server
The general tower server chassis is almost as large as the commonly used PC chassis, while the large tower chassis is much larger, and the overall dimension is not a fixed standard.
(2) Rack-mounted server
Rack-mounted servers are a type of server that has a standard width of 19 inch racks, with a height of from 1U to several U, due to the dense deployment of the enterprise. Placing servers on racks not only facilitates routine maintenance and management, but also may avoid unexpected failures. First, placing the server does not take up too much space. The rack servers are arranged in the rack in order, and no space is wasted. Secondly, the connecting wires and the like can be neatly stored in the rack. The power line, the LAN line and the like can be distributed in the cabinet, so that the connection lines accumulated on the ground can be reduced, and the accidents such as the electric wire kicking off by feet can be prevented. The specified dimensions are the width (48.26cm ═ 19 inches) and height (multiples of 4.445 cm) of the server. Because of its 19 inch width, a rack that meets this specification is sometimes referred to as a "19 inch rack".
(3) Blade server
A blade server is a HAHD (High Availability High Density) low cost server platform designed specifically for the application specific industry and High Density computer environment, where each "blade" is actually a system motherboard, similar to an individual server. In this mode, each motherboard runs its own system, serving a designated group of different users, without any relationship to each other. Although system software may be used to group these motherboards into a server cluster. In the cluster mode, all motherboards can be connected to provide a high-speed network environment, and resources can be shared to serve the same user group.
(4) Cloud server
The cloud server (ECS) is a computing Service with simplicity, high efficiency, safety, reliability, and flexible processing capability. The management mode is simpler and more efficient than that of a physical server, and a user can quickly create or release any plurality of cloud servers without purchasing hardware in advance. The distributed storage of the cloud server is used for integrating a large number of servers into a super computer, and a large number of data storage and processing services are provided. The distributed file system and the distributed database allow access to common storage resources, and IO sharing of application data files is achieved. The virtual machine can break through the limitation of a single physical machine, dynamically adjust and allocate resources to eliminate single-point faults of the server and the storage equipment, and realize high availability.
Embodiments of the present invention also provide a non-volatile computer storage medium having stored thereon computer-executable instructions that are executed by one or more processors.
In an embodiment of the present invention, a method for protecting privacy of blockchain transaction data is provided, where the method is applied to a blockchain system, where the blockchain system includes a normal node, a miner node, and a verification node, and the method includes: step S1, respectively generating an auxiliary key pair (PAh, SAh) according to the private key SA association of the sender A of the transaction, and generating an auxiliary key pair (PBh, SBh) according to the private key SB association of the receiver B; in step S2, the sender a sends transfer intentions to the receiver B, the transfer intentions including: account balance A, transaction amount, signature of the transfer intention of the sender A by using a private key SA, and an attached public key PAh of the sender A; step S3, the receiver B receives the transfer intention and sends transaction information to the miner node, the transaction information including: the intent to transfer sent by sender A, the B account balance, the recipient B's signature of the transaction using the private key SB, and the recipient B's affiliated public key PBh; step S4, after receiving the transaction information, the miner node encrypts the account balance and the transaction amount of the sender A through the affiliated public key PAh of the sender A, encrypts the account balance and the transaction amount of the receiver B through the affiliated public key PBh of the receiver B, verifies the transaction information and adds the transaction information into a block; step S5, the verification node verifies the block, and the transaction information is written into the block chain after the verification is successful; in step S6, the regular node receives the block and updates its own state tree. Because the transaction amount on the block chain and the account balance in the state tree are both stored in a ciphertext mode, the security and the privacy of the transaction are guaranteed, the technical problem that the privacy protection of the current block chain depends on a third-party trusted institution is solved, and the privacy of the transaction data of the user is protected.
The above-described embodiments of the apparatus or device are merely illustrative, wherein the unit modules described as separate parts may or may not be physically separate, and the parts displayed as module units may or may not be physical units, may be located in one place, or may be distributed on a plurality of network module units. Some or all of the modules may be selected according to actual needs to achieve the purpose of the solution of the present embodiment.
Through the above description of the embodiments, those skilled in the art will clearly understand that each embodiment can be implemented by software plus a general hardware platform, and certainly can also be implemented by hardware. Based on such understanding, the technical solutions mentioned above may be embodied in the form of a software product, which may be stored in a computer-readable storage medium, such as ROM/RAM, magnetic disk, optical disk, etc., and includes instructions for causing a computer device (which may be a personal computer, a server, or a network device) to execute the method according to each embodiment or some parts of the embodiments.
Finally, it should be noted that: the above examples are only intended to illustrate the technical solution of the present invention, but not to limit it; within the idea of the invention, also technical features in the above embodiments or in different embodiments may be combined, steps may be implemented in any order, and there are many other variations of the different aspects of the invention as described above, which are not provided in detail for the sake of brevity; although the present invention has been described in detail with reference to the foregoing embodiments, it will be understood by those of ordinary skill in the art that: the technical solutions described in the foregoing embodiments may still be modified, or some technical features may be equivalently replaced; and the modifications or the substitutions do not make the essence of the corresponding technical solutions depart from the scope of the technical solutions of the embodiments of the present application.
Claims (10)
1. A privacy protection method of blockchain transaction data is applied to a blockchain system, the blockchain system comprises a common node, a miner node and a verification node, and the method comprises the following steps:
step S1, respectively generating auxiliary key pairs (PAh, SAh) according to the private key SA association of the sender A of the transaction and auxiliary key pairs (PBh, SBh) according to the private key SB association of the receiver B based on the addition homomorphic algorithm;
in step S2, the sender a sends transfer intentions to the receiver B, the transfer intentions including: account balance A, transaction amount, signature of the transfer intention of the sender A by using a private key SA, and an attached public key PAh of the sender A;
step S3, the receiver B receives the transfer intention and sends transaction information to the miner node, the transaction information including: the intent to transfer sent by sender A, the B account balance, the recipient B's signature of the transaction using the private key SB, and the recipient B's affiliated public key PBh;
step S4, after receiving the transaction information, the miner node encrypts the account balance and the transaction amount of the sender A through the affiliated public key PAh of the sender A, encrypts the account balance and the transaction amount of the receiver B through the affiliated public key PBh of the receiver B, verifies the transaction information and adds the transaction information into a block;
step S5, the verification node verifies the block, and the transaction information is written into the block chain after the verification is successful;
in step S6, the regular node receives the block and updates its own state tree.
2. The method according to claim 1, wherein the step S1 of generating the affiliated key pair (PAh, SAh) according to the private key SA association of the sender a of the transaction and the affiliated key pair (PBh, SBh) according to the private key SB association of the receiver B respectively comprises:
associating the sender A private key SA generates an affiliated key pair (PAh, SAh) of the sender A with an addition homomorphic encryption attribute, and associating the receiver B private key SB generates an affiliated key pair (PBh, SBh) of the receiver B with an addition homomorphic encryption attribute.
3. The method according to claim 1, wherein the step S2, where the sender a sends the intention to transfer to the receiver B, further comprises:
newly establishing an account C in the state tree;
the transaction amount in the transfer interest that needs to be sent to the recipient B is sent by the sender a to the account C, and the account C sends its full balance to the account of the recipient B.
4. The method according to claim 1, wherein the verifying the transaction information in step S4 specifically includes:
judging whether a ciphertext obtained by encrypting the balance of the account A by the auxiliary public key PAh of the sender A is consistent with a balance ciphertext of the account A in the state tree or not, and whether a ciphertext obtained by encrypting the balance of the account B by the auxiliary public key PBh of the receiver B is consistent with a balance ciphertext of the account B in the state tree or not;
judging whether the transaction amount is positive or not and whether the transaction amount is not more than the balance of the account A or not;
the sender a's signature of the intent to commit using the private key SA is verified by the sender a's public key PA, and the recipient B's signature of the transaction using the private key SB is verified by the recipient B's public key PB.
5. The method according to claim 1, wherein the adding the transaction information into the block in the step S4 specifically comprises:
the ciphertext obtained by encrypting the transaction amount with the affiliated public key PAh of the sender a and the ciphertext obtained by encrypting the transaction amount with the affiliated public key PBh of the receiver B are added to the block as transaction information.
6. The method of claim 1, wherein the verifying the block in step S5 includes:
verifying the legitimacy of all transactions in said block, and,
and verifying the workload certification submitted by the miner node.
7. The method according to claim 1, wherein before the normal node receives the block in step S5, the method further comprises:
and verifying whether the signature number of the verification nodes in the block exceeds a threshold value or not according to a Byzantine fault-tolerant protocol, and receiving the block if the signature number of the verification nodes in the block exceeds the threshold value.
8. The method according to claim 1, wherein the step S6 of the ordinary node receiving the block and updating its own state tree specifically includes:
the balance of the account A is homomorphic added through a ciphertext obtained by encrypting the transaction amount through an attached public key PAh of the sender A, and the balance of the account A is updated;
and (4) carrying out homomorphic addition on the balance of the account B through a ciphertext obtained by encrypting the transaction amount through the attached public key PBh of the receiver B, and updating the balance of the account B.
9. The method according to any one of claims 1 to 8, wherein the users in the blockchain system use their own public key as a unique identifier of the identity, and the blockchain system generates an affiliated key pair for each user's private key association, each affiliated key pair including an affiliated public key and an affiliated private key, and the affiliated private key is used for decrypting the encrypted ciphertext of its corresponding affiliated public key.
10. A blockchain system applying the method of privacy protection of blockchain transaction data according to any one of claims 1 to 9, the blockchain system comprising: the system comprises common nodes, miner nodes and verification nodes, wherein the block chain system generates an affiliated key pair for private key association of each node based on an addition homomorphic algorithm.
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN201910310361.9A CN110059494B (en) | 2019-04-17 | 2019-04-17 | Privacy protection method for block chain transaction data and block chain system |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN201910310361.9A CN110059494B (en) | 2019-04-17 | 2019-04-17 | Privacy protection method for block chain transaction data and block chain system |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| CN110059494A CN110059494A (en) | 2019-07-26 |
| CN110059494B true CN110059494B (en) | 2020-11-03 |
Family
ID=67319243
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CN201910310361.9A Active CN110059494B (en) | 2019-04-17 | 2019-04-17 | Privacy protection method for block chain transaction data and block chain system |
Country Status (1)
| Country | Link |
|---|---|
| CN (1) | CN110059494B (en) |
Families Citing this family (22)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN110490003B (en) * | 2019-08-09 | 2022-04-22 | 杭州安存网络科技有限公司 | User trusted data generation method, user trusted data acquisition method, device and system |
| CN110599163B (en) * | 2019-08-20 | 2023-03-24 | 江苏大学 | Transaction record outsourcing method facing block chain transaction supervision |
| EP3688620B1 (en) * | 2019-08-27 | 2021-10-20 | Advanced New Technologies Co., Ltd. | System and method for blockchain-based notification |
| CN110569309B (en) * | 2019-09-17 | 2023-06-20 | 上海保险交易所股份有限公司 | Apparatus, method, system, and medium for implementing blockchain |
| CN110766400B (en) * | 2019-10-22 | 2023-01-13 | 全链通有限公司 | Transaction record processing method based on block chain, accounting node and medium |
| CN110766407A (en) * | 2019-10-22 | 2020-02-07 | 全链通有限公司 | Transaction verification method, accounting node and medium based on block chain |
| CN111080296B (en) * | 2019-12-05 | 2023-12-01 | 深圳前海微众银行股份有限公司 | Verification method and device based on blockchain system |
| CN113132078B (en) * | 2019-12-31 | 2023-07-14 | 航天信息股份有限公司 | Block chain privacy protection method and block chain system based on homomorphism promise |
| CN113128999B (en) * | 2019-12-31 | 2024-04-12 | 航天信息股份有限公司 | Block chain privacy protection method and device |
| CN111461682A (en) * | 2020-03-18 | 2020-07-28 | 必成汇(成都)科技有限公司 | Financial system and digital currency trusteeship system that has it |
| CN111510450B (en) * | 2020-04-13 | 2021-02-05 | 西安电子科技大学 | Block chain link point identity verification method |
| CN111526217B (en) * | 2020-07-03 | 2020-10-09 | 支付宝(杭州)信息技术有限公司 | Consensus method and system in block chain |
| CN111988290B (en) * | 2020-08-05 | 2022-10-14 | 上海交通大学 | Transaction deletion method and system under user balance privacy protection and authorization supervision |
| CN111915302B (en) * | 2020-08-05 | 2021-08-03 | 腾讯科技（深圳）有限公司 | Associated data processing method and device, electronic equipment and computer readable medium |
| CN112184433A (en) * | 2020-08-31 | 2021-01-05 | 武汉市果壳璐网络科技有限公司 | Block chain system |
| CN112990903B (en) * | 2021-03-10 | 2023-06-09 | 中国联合网络通信集团有限公司 | Block chain-based telephone charge transfer method, transferable node and demand node |
| CN112926967B (en) * | 2021-03-18 | 2024-02-02 | 上海零数众合信息科技有限公司 | Metering and payment method for blockchain platform |
| CN113094733A (en) * | 2021-04-25 | 2021-07-09 | 永旗(北京)科技有限公司 | Block chain data privacy protection method and system |
| CN113570373B (en) * | 2021-09-23 | 2022-02-11 | 北京理工大学 | Responsibility pursuing transaction method and system based on block chain |
| CN114297721A (en) * | 2022-01-25 | 2022-04-08 | 联想(北京)有限公司 | Information processing method, information processing apparatus, block chain platform, and storage medium |
| CN117294429B (en) * | 2023-09-23 | 2024-04-19 | 南京市公共资源交易中心江北新区分中心 | Public resource transaction data encryption and decryption method, system and medium based on blockchain |
| CN117236959B (en) * | 2023-11-10 | 2024-02-09 | 金网络(北京)数字科技有限公司 | Blockchain transaction method and device with privacy protection function and storage medium |
Citations (1)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN109086585A (en) * | 2018-07-10 | 2018-12-25 | 众安信息技术服务有限公司 | History data processing method, system and computer readable storage medium |
Family Cites Families (4)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN106549749B (en) * | 2016-12-06 | 2019-12-24 | 杭州趣链科技有限公司 | Block chain privacy protection method based on addition homomorphic encryption |
| CN106845960B (en) * | 2017-01-24 | 2018-03-20 | 上海壹账通区块链科技有限公司 | Method for secure transactions and system based on block chain |
| CN109462472A (en) * | 2017-09-06 | 2019-03-12 | 阿里巴巴集团控股有限公司 | The methods, devices and systems of data encryption and decryption |
| CN109040014A (en) * | 2018-06-13 | 2018-12-18 | 湖南搜云网络科技股份有限公司 | Block chain processing method and processing device, block chain node and storage medium |
-
2019
- 2019-04-17 CN CN201910310361.9A patent/CN110059494B/en active Active
Patent Citations (1)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN109086585A (en) * | 2018-07-10 | 2018-12-25 | 众安信息技术服务有限公司 | History data processing method, system and computer readable storage medium |
Also Published As
| Publication number | Publication date |
|---|---|
| CN110059494A (en) | 2019-07-26 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| CN110059494B (en) | Privacy protection method for block chain transaction data and block chain system | |
| CN111681003B (en) | Resource cross-chain transfer method and device, computer equipment and storage medium | |
| Wang et al. | Blockchain-based fair payment smart contract for public cloud storage auditing | |
| TWI724391B (en) | Node management method and device based on blockchain | |
| CN109829326B (en) | Cross-domain authentication and fair audit de-duplication cloud storage system based on block chain | |
| CN109409122B (en) | File storage method, electronic device and storage medium | |
| CN111797159B (en) | Information management and access control in a database | |
| TWI737392B (en) | Computer-implemented method for processing blockchain data by a blockchain node of a blockchain network in a trusted execution environment (tee), system communicating shared blockchain data and apparatus for communicating shared blockchain data | |
| US20200143366A1 (en) | Methods for decentralized digital asset transfer and smart contract state transition | |
| CN112055025B (en) | Privacy data protection method based on block chain | |
| TWI729880B (en) | Shared blockchain data storage based on error correction coding in trusted execution environments | |
| US20230316273A1 (en) | Data processing method and apparatus, computer device, and storage medium | |
| TWI720918B (en) | Consenus of shared blockchain data storage based on error correction code | |
| TWI740575B (en) | Method, system and device for prioritizing shared blockchain data storage | |
| TWI759791B (en) | Method, system and apparatus of shared blockchain data storage based on error correction code | |
| EP3726774A1 (en) | Transparent blockchain sidechains to support blockchain processing heterogeneity | |
| CN111656386B (en) | Managing transaction requests in ledger system | |
| CN111630545B (en) | Managing transaction requests in ledger system | |
| US11676111B1 (en) | Apparatuses and methods for determining and processing dormant user data in a job resume immutable sequential listing | |
| CN114039733B (en) | Certificate storage service transfer method, device and equipment for alliance chains | |
| CN111385096A (en) | Block chain network, signature processing method, terminal and storage medium | |
| CN114762288A (en) | System and method for establishing trust relationships in distributed systems | |
| Qi et al. | Blockchain-Based Light-Weighted Provable Data Possession for Low Performance Devices. | |
| Wang et al. | A lightweight data integrity verification with data dynamics for mobile edge computing | |
| CN111630549B (en) | Managing transaction requests in ledger system |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| PB01 | Publication | ||
| PB01 | Publication | ||
| SE01 | Entry into force of request for substantive examination | ||
| SE01 | Entry into force of request for substantive examination | ||
| TA01 | Transfer of patent application right | ||
| TA01 | Transfer of patent application right |
Effective date of registration: 20200908 Address after: 518000 block D, Central Avenue, intersection of Xixiang Avenue and Baoyuan Road, labor community, Xixiang street, Bao'an District, Shenzhen City, Guangdong Province Applicant after: Shenzhen Qiyuan Information Service Co.,Ltd. Address before: 518100 Yujingwan Garden, Xin'an Sixth Road, Xixiang Street, Baoan District, Shenzhen City, Guangdong Province, 101, 201A, 301, 401 4th floor 401-03 Applicant before: Shenzhen Luyun District Chain Network Technology Co.,Ltd. |
|
| GR01 | Patent grant | ||
| GR01 | Patent grant | ||
| TR01 | Transfer of patent right | ||
| TR01 | Transfer of patent right |
Effective date of registration: 20230403 Address after: No. 4145, Building 4, Yard 10, Xixiaoying South Ring Road, Sujiatuo Town, Haidian District, Beijing, 100194 Patentee after: Beijing Mingtai Hengtong Information Technology Co.,Ltd. Address before: 518000, 13C, Block D, Central Avenue, intersection of Xixiang Avenue and Baoyuan Road, Labor Community, Xixiang Street, Bao'an District, Shenzhen, Guangdong Province Patentee before: Shenzhen Qiyuan Information Service Co.,Ltd. |