CN111831678A

CN111831678A - Privacy protection method and device based on block chain and electronic equipment

Info

Publication number: CN111831678A
Application number: CN202010977032.2A
Authority: CN
Inventors: 贺三元
Original assignee: Alipay Hangzhou Information Technology Co Ltd
Current assignee: Alipay Hangzhou Information Technology Co Ltd
Priority date: 2020-09-17
Filing date: 2020-09-17
Publication date: 2020-10-27

Abstract

The embodiment of the specification provides a privacy protection method and device based on a block chain and an electronic device. The method comprises the following steps: receiving an application request of a virtual contact way submitted by a user side, wherein the application request carries a real contact way of the user; determining an idle virtual contact way, establishing a corresponding relation between the virtual contact way and the real contact way, and issuing the virtual contact way and the identity information of the user to a block chain for storing a certificate; returning the virtual contact information to the user side so that the user takes the virtual contact information as an externally provided contact information; and when a contact request aiming at the virtual contact way is received, routing the contact request to the real contact way according to the real contact way corresponding to the virtual contact way.

Description

Privacy protection method and device based on block chain and electronic equipment

Technical Field

One or more embodiments of the present disclosure relate to the field of blockchain technologies, and in particular, to a method and an apparatus for privacy protection based on a blockchain, and an electronic device.

Background

The block chain technology, also called distributed ledger technology, is an emerging technology in which several computing devices participate in "accounting" together, and a complete distributed database is maintained together. The blockchain technology has been widely used in many fields due to its characteristics of decentralization, transparency, participation of each computing device in database records, and rapid data synchronization between computing devices.

Disclosure of Invention

The embodiment of the specification provides a method and a device for improving information security and electronic equipment.

According to a first aspect of embodiments herein, there is provided a block chain based privacy protection method, the method including:

receiving an application request of a virtual contact way submitted by a user side, wherein the application request carries a real contact way of the user;

determining an idle virtual contact way, establishing a corresponding relation between the virtual contact way and the real contact way, and issuing the virtual contact way and the identity information of the user to a block chain for storing a certificate;

returning the virtual contact information to the user side so that the user takes the virtual contact information as an externally provided contact information;

and when a contact request aiming at the virtual contact way is received, routing the contact request to the real contact way according to the real contact way corresponding to the virtual contact way.

According to a second aspect of embodiments herein, there is provided a privacy protecting apparatus based on a block chain, the apparatus including:

the first receiving unit is used for receiving an application request of a virtual contact way submitted by a user side, wherein the application request carries a real contact way of the user;

the issuing unit is used for determining an idle virtual contact way, establishing a corresponding relation between the virtual contact way and the real contact way, and issuing the virtual contact way and the identity information of the user to a block chain for storing the certificate;

the return unit is used for returning the virtual contact way to the user side so that the user takes the virtual contact way as an externally provided contact way;

and the routing unit is used for routing the contact request to the real contact way according to the real contact way corresponding to the virtual contact way when receiving the contact request aiming at the virtual contact way.

According to a third aspect of embodiments herein, there is provided an electronic apparatus including:

a processor;

a memory for storing processor-executable instructions;

wherein the processor is configured to perform any one of the above block chain based privacy protecting methods.

The embodiment of the specification provides a privacy protection scheme based on a block chain, and a virtual contact way which is uniquely corresponding to a real contact way is distributed to a user, so that the user can use the virtual contact way as an externally provided contact way; the outside world can only contact the user through the virtual contact way; specifically, when receiving a contact request for a virtual contact address, a communication operator may route the contact request to a real contact address according to the real contact address corresponding to the virtual contact address. On the other hand, not only is the user contact channel to the outside ensured, but also the real contact way is ensured not to be revealed. On the other hand, after the user cancels the virtual contact way, the outside cannot contact the user through the virtual contact way any more. Therefore, the problem of continuous disturbance caused by leakage of the real contact information is avoided. On the other hand, by using the chain storage of the virtual contact way, the verification function of the virtual contact way can be provided for the outside by using the characteristic that the block chain is not falsifiable, so as to determine whether the user providing the virtual contact way is the holder of the virtual contact way. Identity information is checked at any time, and the virtual contact way is prevented from being forged.

Drawings

FIG. 1 is a flow diagram of creating an intelligent contract provided by an exemplary embodiment;

FIG. 2 is a schematic diagram of invoking an intelligent contract provided by an exemplary embodiment;

FIG. 3 is a schematic diagram of creating an intelligent contract and invoking an intelligent contract provided by an exemplary embodiment;

FIG. 4 is a flowchart of a block chain based privacy protection method provided by an example embodiment;

FIG. 5 is a flowchart of a block chain based privacy preserving method under multi-party interaction according to an exemplary embodiment;

FIG. 6 is a schematic diagram of an electronic device according to an exemplary embodiment;

fig. 7 is a block diagram of a privacy protecting apparatus based on a block chain according to an exemplary embodiment.

Detailed Description

Reference will now be made in detail to the exemplary embodiments, examples of which are illustrated in the accompanying drawings. When the following description refers to the accompanying drawings, like numbers in different drawings represent the same or similar elements unless otherwise indicated. The implementations described in the exemplary embodiments below do not represent all implementations consistent with one or more embodiments of the present specification. Rather, they are merely examples of apparatus and methods consistent with certain aspects of one or more embodiments of the specification, as detailed in the claims which follow.

It should be noted that: in other embodiments, the steps of the corresponding methods are not necessarily performed in the order shown and described herein. In some other embodiments, the method may include more or fewer steps than those described herein. Moreover, a single step described in this specification may be broken down into multiple steps for description in other embodiments; multiple steps described in this specification may be combined into a single step in other embodiments.

Blockchains are generally divided into three types: public chain (Public Blockchain), private chain (PrivateBlockchain) and alliance chain (Consortium Blockchain). Furthermore, there may be a combination of the above types, such as private chain + federation chain, federation chain + public chain, and so on.

Among them, the most decentralized is the public chain. The public chain is represented by bitcoin and ether house, and participants (also called nodes in the block chain) joining the public chain can read data records on the chain, participate in transactions, compete for accounting rights of new blocks, and the like. Moreover, each node can freely join or leave the network and perform related operations.

Private chains are the opposite, with the network's write rights controlled by an organization or organization and the data read rights specified by the organization. Briefly, a private chain may be a weakly centralized system with strict restrictions on nodes and a small number of nodes. This type of blockchain is more suitable for use within a particular establishment.

A federation chain is a block chain between a public chain and a private chain, and "partial decentralization" can be achieved. Each node in a federation chain typically has a physical organization or organization corresponding to it; the nodes are authorized to join the network and form a benefit-related alliance, and block chain operation is maintained together.

Based on the basic characteristics of a blockchain, a blockchain is usually composed of several blocks. The time stamps corresponding to the creation time of the block are recorded in the blocks respectively, and all the blocks form a time-ordered data chain according to the time stamps recorded in the blocks strictly.

The real data generated by the physical world can be constructed into a standard transaction (transaction) format supported by a block chain, then is issued to the block chain, the node equipment in the block chain performs consensus processing on the received transaction, and after the consensus is achieved, the node equipment serving as an accounting node in the block chain packs the transaction into a block and performs persistent evidence storage in the block chain.

The consensus algorithm supported in the blockchain may include:

the first kind of consensus algorithm, namely the consensus algorithm that the node device needs to contend for the accounting right of each round of accounting period; consensus algorithms such as Proof of Work (POW), Proof of equity (POS), Proof of commission rights (DPOS), etc.;

the second kind of consensus algorithm, namely the consensus algorithm which elects accounting nodes in advance for each accounting period (without competing for accounting right); for example, a consensus algorithm such as a Practical Byzantine Fault Tolerance (PBFT) is used.

In a blockchain network employing a first type of consensus algorithm, node devices competing for billing rights can execute a transaction upon receipt. One of the node devices competing for the accounting right may win in the process of competing for the accounting right in the current round, and become an accounting node. The accounting node may package the received transaction with other transactions to generate a candidate block and send the generated candidate block or a block header of the candidate block to other node devices for consensus.

In the block chain network adopting the second type of consensus algorithm, the node equipment with the accounting right is agreed before accounting in the current round. Thus, the node device, after receiving the transaction, may send the transaction to the accounting node if it is not the accounting node of its own round. For the accounting node of the current round, the transaction may be performed during or before packaging the transaction with other transactions to generate candidate blocks. After generating the candidate block, the accounting node may send the candidate block or a block header of the candidate block to other node devices for consensus.

As described above, regardless of which consensus algorithm is used by the blockchain, the accounting node of the current round may package the received transaction to generate a candidate block and send the generated candidate block or the block header of the candidate block to other node devices for consensus verification. If no problem is verified after the other node device receives the candidate block or the block header of the candidate block, the candidate block can be added to the end of the original block chain as the latest block, thereby completing the accounting process of the block chain. The transaction contained in the block may also be performed by other nodes in verifying the new block or block header sent by the accounting node.

In the field of blockchain, an important concept is Account (Account); taking an ether house as an example, the ether house generally divides an account into an external account and a contract account; the external account is an account directly controlled by the user and is also called as a user account; and the contract account is created by the user through an external account, the account containing the contract code (i.e. the smart contract).

Of course, for some blockchain models derived from the ethernet-based architecture (such as ant blockchains), account types supported by the blockchain may be further expanded, and are not particularly limited in this specification.

For accounts in a blockchain, the account status of the account is usually maintained through a structure. When a transaction in a block is executed, the status of the account associated with the transaction in the block chain is also typically changed.

Taking etherhouses as an example, the structure of an account usually includes fields such as Balance, Nonce, Code and Storage. Wherein:

a Balance field for maintaining the current account Balance of the account;

a Nonce field for maintaining a number of transactions for the account; the counter is used for guaranteeing that each transaction can be processed only once, and replay attack is effectively avoided;

a Code field for maintaining a contract Code for the account; in practical applications, only the hash value of the contract Code is typically maintained in the Code field; thus, the Code field is also commonly referred to as the Codhash field.

A Storage field for maintaining the Storage contents of the account (default field value is null); for a contract account, a separate storage space is usually allocated to store the storage content of the contract account; this separate storage space is often referred to as the account storage of the contract account. The storage content of the contract account is usually constructed into a data structure of an MPT (MerklePatricia trie) tree and stored in the independent storage space; in which, the Storage content based on the contract account is constructed into an MPT tree, which is also commonly referred to as a Storage tree. Whereas the Storage field typically maintains only the root node of the Storage tree; thus, the Storage field is also commonly referred to as the Storage root field.

Wherein, for the external account, the field values of the Code field and the Storage field shown above are both null values.

For most blockchain models, Merkle trees are typically used; alternatively, the data is stored and maintained based on the data structure of the Merkle tree. Taking etherhouses as an example, the etherhouses use MPT tree (a Merkle tree variation) as a data organization form for organizing and managing important data such as account status, transaction information, and the like.

The Etherhouse designs three MPT trees, namely an MPT state tree, an MPT transaction tree and an MPT receipt tree, aiming at data needing to be stored and maintained in a block chain. In addition to the three MPT trees, there is actually a Storage tree constructed based on the Storage content of the contract account.

An MPT state tree, which is an MPT tree organized by account state data of all accounts in a blockchain; an MPT transaction tree, which is an MPT tree organized by transaction (transaction) data in a blockchain; the MPT receipt tree is organized into transaction (receipt) receipts corresponding to each transaction generated after the transactions in the block are executed. The hash values of the root nodes of the MPT state tree, the MPT transaction tree, and the MPT receipt tree shown above are eventually added to the block header of the corresponding block.

The MPT transaction tree and the MPT receipt tree correspond to the blocks, namely each block has the MPT transaction tree and the MPT receipt tree. The MPT state tree is a global MPT tree, which does not correspond to a specific tile, but covers account state data of all accounts in the tile chain.

For the MPT transaction tree, the MPT receipt tree and the MPT state tree which are organized, the MPT transaction tree, the MPT receipt tree and the MPT state tree are finally stored in a Key-Value type database (such as a levelDB) which adopts a multi-level data storage structure.

The database adopting a multilevel data storage structure usually adopts a multilevel data storage structure and can be divided into n levels of data storage; for example, each level of data storage may be set to L0, L1, L2, L3.. L (n-1) in sequence; for each level of data storage in the database, the smaller the level number is, the higher the level is generally; for example, L0 stores the latest chunks of data, L1 stores the next-to-new chunks of data, and so on.

Wherein, the read-write performance of the storage medium corresponding to each level of data storage may also have performance difference in general; for example, the read/write performance of the storage medium corresponding to the data storage with a higher rank (i.e., with a smaller rank number) may be higher than the read/write performance of the storage medium corresponding to the data storage with a lower rank. In practical application, a storage medium with higher storage cost and better storage performance can be used for storing data with high level; and the storage medium with low unit cost and large capacity can be used for storing the data with low level.

In practical applications, as the block number of a block chain increases (also referred to as block height), the data stored in the database contains a lot of historical data; also, the longer the data in a block with a smaller block number is, the less important it is. Therefore, in order to reduce the overall storage cost, data of different block heights can be generally treated differently; for example, the data in the block with the smaller block number can be stored on a storage medium with lower cost; and the data in the block with larger block number is stored on the storage medium with higher cost.

It should be noted that, each time a latest block is generated in the blockchain, after a transaction in the latest block is executed, the account status of the accounts (which may be an external account or a contract account) related to the executed transaction in the blockchain is usually changed;

for example, when a "transfer transaction" is completed in a block, the balances of the transferring party account and the transferring party account associated with the "transfer transaction" (i.e., the field values of the Balance fields of these accounts) are usually changed.

After the transaction in the latest block generated by the blockchain is completed, the node device needs to construct an MPT state tree according to the current account state data of all accounts in the blockchain because the account state in the current blockchain changes, so as to maintain the latest state of all accounts in the blockchain.

That is, each time a latest block is generated in the block chain and the account status in the block chain changes after the transaction in the latest block is completed, the node device needs to reconstruct an MPT status tree based on the latest account status data of all accounts in the block chain. In other words, each block in the block chain has a corresponding MPT state tree; the MPT status tree maintains the latest account status of all accounts in the blockchain after the transaction in the block is completed.

The explanation is given by taking an MPT state tree organized by account state data of the blockchain as an example.

The MPT tree is a relatively traditional modified Merkle tree variety, and combines the advantages of two tree structures, namely a Merkle tree and a Trie dictionary tree (also called as a prefix tree).

Three data nodes, a leaf node (leaf node), an extension node (extension node), and a branch node (branch node), are typically included in the MPT tree.

The extended node is represented as a key-value pair of [ key, value ], wherein the key is a special hexadecimal code character and represents a shared character prefix of the account address; the shared character prefix refers to a prefix formed by one or more same characters of a plurality of block chain account addresses; value is the hash value (hash pointer) of the other node, i.e. it can be linked to the other node by a hash pointer.

The branch node comprises 17 elements, the first 16 elements correspond to 16 possible hexadecimal characters in the key, and one character corresponds to one nibble (half byte), and the shared character prefixes (the length of the prefixes is one character) of one account address are respectively represented. If a [ key, value ] pair terminates at the branch node, the branch node can act as a leaf node, and the last element represents the value of the leaf node; otherwise, the last element of the branch node may be null.

A leaf node, which is a key-value pair represented as [ key, value ], wherein key is also a special hexadecimal code character and represents a character suffix of the account address; the character suffix of the account address and the shared character prefix of the account address jointly form a complete account address; the character suffix refers to a suffix formed by the last one or more characters except the shared character prefix of the account address; value is the status data (i.e., the structure shown above) of the account address corresponding to that leaf node.

Because characters on a search path from a root node to a leaf node on the MPT tree form a complete account address; therefore, the branch node may be a termination node of the search path or an intermediate node of the search path.

Assume that account status data that needs to be organized into an MTP status tree is shown in table 1 below:

in table 1, the account address is a character string composed of several 16-ary characters. The account status is a structure composed of fields such as Balance, Nonce, Code, and Storage.

The MPT state tree is finally organized according to the account state data in the table 1; the MPT state tree is composed of 4 leaf nodes, 2 branch nodes, and 2 extension nodes (one of which serves as a root node).

The prefix field is a prefix field that the extension node and the leaf node have in common. Different field values of the prefix field may be used to indicate different node types.

For example, the value of the prefix field is 0, which indicates that an extension node includes an even number of nibbles; as previously mentioned, a nibble represents a nibble, consisting of a 4-bit binary, and one nibble may correspond to one character that makes up an account address. The value of the prefix field is 1, and the prefix field represents an expansion node containing odd number of nibbles(s); the value of the prefix field is 2, which represents a leaf node containing an even number of nibbles; the value of the prefix field is 3, which indicates that the leaf node contains an odd number of nibbles(s).

And the branch node does not have the prefix field because the branch node is a prefix node of the parallel single neighbor.

A Shared neighbor field in the extension node, corresponding to a key value of a key-value pair contained in the extension node, represents a common character prefix between account addresses; for example, all account addresses in the table above have a common character prefix a 7. The Next Node field is filled with the hash value (hash pointer) of the Next Node.

The field of the 16-system characters 0-f in the branch node corresponds to the key value of the key value pair contained in the branch node; if the branch node is an intermediate node of the account address on the search path on the MPT tree, the Value field of the branch node may be null. And the 0-f field is used for filling the hash value of the next node.

The Key-end in a leaf node, corresponding to the Key value of the Key-value pair contained in that leaf node, represents the last few characters of the account address (the character suffix of the account address). The key values of the nodes on the search path from the root node to the leaf nodes form a complete account address. Filling account state data corresponding to the account address in a Value field of the leaf node; for example, a structure composed of fields such as Balance, Nonce, Code, and storage may be encoded and filled in the Value field of the leaf node.

Further, the node on the MPT state tree is finally stored in the database in a Key-Value Key Value pair mode;

when a node on the MPT state tree is stored in the database, a key in a key value pair of the node on the MPT state tree can be a hash value of data content contained in the node; value in the key Value pair of the node on the MPT state tree is the data content contained in the node.

That is, when a node in the MPT state tree is stored in the database, a hash Value of data content contained in the node may be calculated (that is, the whole node is subjected to hash calculation), the calculated hash Value is used as a Key, the data content contained in the node is used as a Value, and a Key-Value Key Value pair is generated; and then storing the generated Key-Value Key Value pair into a database.

Because the node in the MPT state tree takes the hash value of the data content contained in the node as Key and the data content contained in the node as value for storage; therefore, when a node on the MPT state tree needs to be queried, content addressing can be performed as a key based on the hash value of the data content contained in the node.

By adopting the content addressing, for some nodes with repeated content, the node can be generally multiplexed to save the storage space of data storage.

Further introduces node multiplexing on the MPT state tree. It should be noted that, in practical applications, when a transaction in a latest block generated by a block chain is completed, only the account status of a part of accounts may be changed; therefore, when the MPT state tree is constructed, it is not necessary to reconstruct a complete MPT state tree based on the current state data of all accounts in the block chain, but only to update the node corresponding to the account whose partial account state changes on the basis of the MPT state tree corresponding to the block before the latest block. For the nodes corresponding to the accounts with unchanged account states in the MPT state tree, since the nodes do not have data update, the nodes corresponding to the blocks before the latest block can be directly multiplexed.

Assuming the account status data in table 1, the latest account status of all accounts in the Block chain after the transaction in Block N is completed; an MPT state tree is organized based on the account state data in table 1.

Suppose that when the transaction in Block N +1 is completed, the account status that results in the account address "a 7f 9365" in table 1 above is updated to "state 5" from "state 3"; at this time, when Block N +1 updates the MPT state tree, it is not necessary to reconstruct an MPT state tree based on the current state data of all accounts in the Block chain after the transaction in Block N +1 is completed.

In this case, it is possible to update only Value in the leaf node whose "key-end" is "9365" on the MPT state tree corresponding to Block N from "state 3" to "state 5", and continue to update the hash pointers of all nodes on the path from the root node to the leaf node;

that is, when a leaf node on the MPT state tree is updated, the hash value of the whole leaf node is updated, and then the hash pointers of all nodes on the path from the root node to the leaf node are also updated accordingly.

For example, in addition to updating the Value in the leaf Node with "key-end" of "9365", the hash pointer pointing to the leaf Node filled in the f field of the last Branch Node (Branch Node) of the leaf Node needs to be updated; furthermore, the root Node can be traced back continuously, and the hash pointer pointing to the branch Node filled in the Next Node field of the last root Node (RootExtension Node) of the branch Node can be updated continuously.

Except the nodes which are updated, other nodes which are not updated can directly multiplex the corresponding nodes on the MPT state tree of the Block N;

the MPT tree corresponding to the Block N is finally reserved as historical data; therefore, when Block N +1 updates the MPT state tree, these updated nodes are not modified and updated directly on the basis of the original nodes in the MPT state tree corresponding to Block N, but are recreated in the MPT tree corresponding to Block N + 1. That is, on the MPT state tree corresponding to Block N +1, only a small number of nodes that are updated need to be created again, and for other nodes that are not updated, the corresponding nodes on the MPT state tree corresponding to Block N may be directly multiplexed.

For example, for the MPT state tree corresponding to Block N +1, only one expansion node, one branch node, and one leaf node, which are root nodes, need to be created again in practice; for nodes which are not updated, the nodes can be multiplexed by adding hash pointers pointing to corresponding nodes on the MPT state tree corresponding to Block N in the nodes which are re-created on the MPT state tree. The nodes before updating on the MPT state tree corresponding to Block N are used as historical account state data to be stored; for example, a leaf node with "key-end" being "9365" and Value being "state 3" will be retained as history data.

In the above example, the content update is performed on a small number of nodes in the MPT state tree of Block N +1, so that most of the nodes of the previous Block N can be "multiplexed". In practical applications, a node may be added to the MPT state tree of Block N +1 more than the previous Block N. In this case, although the newly added node cannot be "multiplexed" directly from the MPT tree of the previous Block N, it may be "multiplexed" from the MPT state tree of the earlier Block;

for example, a node newly added to the MPT state tree of Block N +1, although not already present in the MPT state tree of Block N, may be present in the MPT state tree of an earlier Block; for example, appear on the MPT state tree of Block N-1; therefore, the newly added node on the MPT state tree of Block N +1 can directly multiplex the corresponding node on the MPT state tree of Block N-1.

In practical applications, whether public, private, or alliance, it is possible to provide the functionality of a smart contract (Smartcontract). An intelligent contract on a blockchain is a contract on a blockchain that can be executed triggered by a transaction. An intelligent contract may be defined in the form of code.

Taking an Etherhouse as an example, a user is supported to create and call some complex logic in the Etherhouse network. The ethernet workshop is used as a programmable block chain, and the core of the ethernet workshop is an ethernet workshop virtual machine (EVM), and each ethernet workshop node can run the EVM. The EVM is a well-behaved virtual machine through which various complex logic can be implemented. The user issuing and invoking smart contracts in the etherhouse is running on the EVM. In fact, the EVM directly runs virtual machine code (virtual machine bytecode, hereinafter referred to as "bytecode"), so the intelligent contract deployed on the blockchain may be bytecode. After Bob sends a Transaction (Transaction) containing information to create a smart contract to the ethernet network, each node can execute the Transaction in the EVM, as shown in fig. 1. In fig. 1, the From field of the transaction is used To record the address of the account initiating the creation of the intelligent contract, the contract code stored in the field value of the Data field of the transaction may be byte code, and the field value of the To field of the transaction is a null account. After the nodes reach the agreement through the consensus mechanism, the intelligent contract is successfully created, and the follow-up user can call the intelligent contract.

After the intelligent contract is established, a contract account corresponding to the intelligent contract appears on the block chain, and the block chain has a specific address; for example, "0 x68e12cf284 …" in each node in fig. 1 represents the address of the contract account created; the contract Code (Code) and account store (Storage) will be maintained in the account store for that contract account. The behavior of the intelligent contract is controlled by the contract code, while the account storage of the intelligent contract preserves the state of the contract. In other words, the intelligent contract causes a virtual account to be generated on the blockchain that contains the contract code and account storage.

As mentioned above, the Data field containing the transaction that created the intelligent contract may hold the byte code of the intelligent contract. A bytecode consists of a series of bytes, each of which can identify an operation. Based on the multiple considerations of development efficiency, readability and the like, a developer can select a high-level language to write intelligent contract codes instead of directly writing byte codes. For example, the high-level language may employ a language such as Solidity, Serpent, LLL, and the like. For intelligent contract code written in a high-level language, the intelligent contract code can be compiled by a compiler to generate byte codes which can be deployed on a blockchain.

Taking the Solidity language as an example, the contract code written by it is very similar to a Class (Class) in the object-oriented programming language, and various members including state variables, functions, function modifiers, events, etc. can be declared in one contract. A state variable is a value permanently stored in an account Storage (Storage) field of an intelligent contract to save the state of the contract.

As shown in FIG. 2, still taking the Etherhouse as an example, after Bob sends a transaction containing the information of the calling intelligent contract to the Etherhouse network, each node can execute the transaction in the EVM. In fig. 2, the From field of the transaction is used To record the address of the account initiating the intelligent contract invocation, the To field is used To record the address of the intelligent contract invocation, and the Data field of the transaction is used To record the method and parameters of the intelligent contract invocation. After invoking the smart contract, the account status of the contract account may change. Subsequently, a client may view the account status of the contract account through the accessed block link point (e.g., node 1 in fig. 2).

The intelligent contract can be independently executed at each node in the blockchain network in a specified mode, and all execution records and data are stored on the blockchain, so that after the transaction is executed, transaction certificates which cannot be tampered and lost are stored on the blockchain.

A schematic diagram of creating an intelligent contract and invoking the intelligent contract is shown in fig. 3. An intelligent contract is created in an Ethernet workshop and needs to be subjected to the processes of compiling the intelligent contract, changing the intelligent contract into byte codes, deploying the intelligent contract to a block chain and the like. The intelligent contract is called in the Ethernet workshop, a transaction pointing to the intelligent contract address is initiated, the EVM of each node can respectively execute the transaction, and the intelligent contract code is distributed and operated in the virtual machine of each node in the Ethernet workshop network.

Conventional blockchain models, represented by etherhouses, typically support the conversion of real-world currency into virtual tokens that can be circulated over the chain in order to effect a "value transfer" over the blockchain.

In the blockchain field, for some blockchain models derived based on the ethernet architecture (such as ant blockchains), the function of converting real-world currency into virtual tokens that can circulate on the chains is generally no longer supported; instead, in these blockchain models, some non-monetary attributes of the physical assets in the real world may be converted into virtual assets that can be circulated over the blockchain.

It should be noted that converting an entity asset having a non-monetary attribute in the real world into a virtual asset on a blockchain generally refers to a process of "anchoring" the entity asset and a virtual asset on the blockchain to serve as a value support for the virtual assets, and further generating a virtual asset on the blockchain which is matched with the value of the entity asset and can be circulated between blockchain accounts on the blockchain.

In the implementation process, the account types supported by the blockchain can be expanded, and an asset account (also called an asset object) is expanded on the basis of the account types supported by the blockchain; for example, an asset account can be expanded on the basis of an external account and a contract account supported by an Ethernet; the expanded asset account is a virtual asset which can support the real-world non-monetary property of the physical asset as value and can be circulated between the blockchain accounts.

For users accessing such a blockchain, in addition to completing the creation of user accounts and intelligent contracts on the blockchain, a virtual asset matched with the entity asset value of non-monetary attributes of the real world is created on the blockchain, and circulation is performed on the blockchain;

for example, a user may convert physical assets of non-monetary attributes, such as real estate, stocks, loan contracts, notes, accounts receivable, etc., held to value-matched virtual assets for circulation over a blockchain.

The above asset account may be maintained by a structure, specifically, the account status of the account may be maintained by a structure. The content of the structure of the asset account may be the same as that of the ether house, and may be designed based on actual requirements;

in one implementation, for example, the content of the structure body of the asset account is the same as that of an ethernet bay, the structure body of the asset account may also include the fields of Balance, Nonce, Code, and Storage described above.

It should be noted that, in an ethernet, the Balance field is usually used to maintain the current account Balance of the account; however, for the block chain model derived based on the ethernet framework, since it may not support the conversion of real-world currency into virtual tokens that can be circulated on the chain, in such block chains, the meaning of the Balance field may be extended, and the Balance of the account is no longer represented, but is used to maintain the address information of the asset account corresponding to the "virtual asset" held by the account. In practical application, address information of asset accounts corresponding to multiple virtual assets can be maintained in the Balance field.

In this case, the external account, the contract account, and the asset account shown above can hold the virtual asset by adding address information of the asset account corresponding to the "virtual asset" that needs to be held in the Balance field. That is, in addition to the external account and the contract account, the asset account itself may hold the virtual asset.

For an asset account, Nonce, the field value of the Code field may or may not be null; and the field value of the Storage field may no longer be a null value; the Storage field may be used to maintain the asset status of the "virtual asset" corresponding to the asset account. The specific manner of maintaining the asset state of the "virtual asset" corresponding to the asset account in the Storage field can be flexibly designed based on requirements, and is not described in detail.

In the blockchain model derived based on the framework of the etherhouse, a user can create a virtual asset on the blockchain that matches the value of the real-world non-monetary attribute physical asset by the implementation shown below:

in one implementation, the transaction types supported by the blockchain may be extended to extend a transaction for creating virtual assets; for example, the types of transactions supported by the etherhouse typically include normal transfer transactions, transactions to create smart contracts, and transactions to invoke smart contracts, and a transaction to create virtual assets may be expanded based on the above three types of transactions.

In this case, a user may create a virtual asset for the user by issuing a transaction into the blockchain network by the client, which is performed by a node device in the blockchain in the local EVM. When the node devices reach the agreement through the consensus mechanism, the virtual asset is successfully created, and an asset account corresponding to the virtual asset appears on the blockchain and has a specific address.

In another implementation, intelligent contracts for creating virtual assets may also be deployed on blockchains; the process of deploying the intelligent contract for creating the virtual asset is not described in detail.

In this case, the user may create a virtual asset for the user by issuing a transaction for invoking the intelligent contract into the blockchain network by the client, executing the transaction in the local EVM by the node device in the blockchain, and running a contract code associated with the intelligent contract in the EVM. When the node devices reach the agreement through the consensus mechanism, the virtual asset is successfully created, and an asset account corresponding to the virtual asset appears on the blockchain and has a specific address.

Of course, for some block chain models derived based on the ethernet framework, if they also support the function of converting real-world currency into virtual tokens that can circulate on the chain, some non-currency property entity assets in the real world can still be converted into a form of virtual tokens that can circulate on the block chain, and circulate on the block chain, which is not described in detail in this specification.

In a cross-chain scenario, multiple blockchains may implement cross-chain docking through cross-chain relays.

The cross-link relay can be respectively connected with the block chains through the bridging interfaces, and the cross-link data synchronization among the block chains is completed based on the realized data carrying logic.

The chain-crossing technology used for realizing the chain-crossing relay is not particularly limited in this specification; for example, in practical applications, a plurality of block chains can be connected by a chain-crossing mechanism such as side chain technology, notary technology, and the like.

After a plurality of block chains are connected in a butt joint mode through cross-chain relays, data on other block chains can be read and authenticated between the block chains, and intelligent contracts deployed on other block chains can be called through the cross-chain relays.

The inter-link relay is used only for transferring data between a plurality of block chains, and does not need to store the transferred data persistently or maintain the data state of the transferred data. In practical applications, the inter-link relay may be configured in a device, a node, a platform, or the like other than the plurality of block chains to which the inter-link relay is connected, or may be configured in a node device of the plurality of block chains to which the inter-link relay is connected, and is not particularly limited in this specification.

The intelligent contracts deployed on the blockchains can only reference data contents stored on the blockchains generally; in practical applications, for some complex business scenarios implemented based on the intelligent contract technology, the intelligent contract may need to refer to some external data on the data entities outside the chain.

In this scenario, the intelligent contract deployed on the blockchain may refer to data on the data entities outside the chain through the Oracle prediction machine, thereby implementing data interaction between the intelligent contract and the data entities in the real world. Data entities outside the chain may include, for example, centralized servers or data centers deployed outside the chain, and so on.

It should be noted that the cross-link relay is used to connect two block chains, and the Oracle.

In practical application, when a predicting machine is deployed for an intelligent contract on a block chain, a predicting machine intelligent contract corresponding to the predicting machine can be deployed on the block chain; the intelligent contract of the prediction machine is used for maintaining external data sent to the intelligent contract on the block chain by the prediction machine; for example, external data sent by the predictive machine to the smart contract on the blockchain may be stored in the account storage space of the predictive machine smart contract.

When a target intelligent contract on the blockchain is called, external data required by the target intelligent contract can be read from the account storage space of the prediction machine intelligent contract to complete the calling process of the intelligent contract.

It should be noted that, when sending external data to the smart contract on the blockchain, the prediction engine may use an active sending method or a passive sending method.

In one implementation, the data entity outside the chain may send external data to be provided to the target intelligent contract to the intelligent contract of the language prediction machine after signing by using the private key of the language prediction machine; for example, in time, the signed external data may be sent to the intelligent contract of the prediction machine in a periodic sending manner;

the intelligent contract of the language predicting machine can maintain a CA (certificate authority) certificate of the language predicting machine, after external data sent by a data entity outside a chain is received, a signature of the external data can be verified by using a public key of the language predicting machine maintained in the CA certificate, and after the signature passes, the external data sent by the data entity outside the chain is stored in an account storage space of the intelligent contract of the language predicting machine.

In another implementation, when a target intelligent contract on a blockchain is called, if external data required by the target intelligent contract is not read from an account storage space of the intelligent contract of the language predictive controller, the intelligent contract of the language predictive controller may interact with the language predictive controller by using an event mechanism of the intelligent contract, and the language predictive controller sends the external data required by the target intelligent contract to the account storage space of the intelligent contract of the language predictive controller.

For example, when a target intelligent contract on a blockchain is called, if external data required by the target intelligent contract is not read from an account storage space of the intelligent contract of the language predictive machine, the intelligent contract of the language predictive machine can generate an external data acquisition event, record the external data acquisition event into a transaction log of the transaction calling the intelligent contract, and store the transaction log into a storage space of a node device; the predicting machine can monitor a transaction log generated by the predicting machine intelligent contract stored in the storage space of the node equipment, respond to the monitored external data acquisition event after monitoring the external data acquisition event in the transaction log, and send the external data required by the target intelligent contract to the predicting machine intelligent contract.

The event mechanism of the intelligent contract is a mode for the interaction between the intelligent contract and the out-of-chain entity. For intelligent contracts deployed on blockchains, direct interaction with out-of-chain entities is generally not possible; for example, the intelligent contract cannot generally send the call result of the intelligent contract to the call initiator of the intelligent contract point to point after the call is completed.

The call results (including intermediate results and final call results) generated during the call of the intelligent contract are usually recorded in the form of events (events) to the transaction log (transactions logs) of the transaction that called the intelligent contract, and stored in the memory space of the node device. The entity outside the chain which needs to interact with the intelligent contract can acquire the calling result of the intelligent contract by monitoring the transaction log stored in the storage space of the node equipment;

for example, in the case of an Etherhouse, the transaction log will eventually be stored in the MPT receipt tree described above as part of the receipt (receipt) of the transaction pen transaction that invoked the smart contract. And the entity outside the chain interacting with the intelligent contract can monitor the transaction receipts stored in the storage space of the node device on the MPT receipt tree and acquire the events generated by the intelligent contract from the monitored transaction receipts.

The specification aims to provide a privacy protection scheme based on a block chain, and a virtual contact way which is uniquely corresponding to a real contact way is distributed to a user, so that the user can use the virtual contact way as an externally provided contact way; the outside world can only contact the user through the virtual contact way; specifically, when receiving a contact request for a virtual contact address, a communication operator may route the contact request to a real contact address according to the real contact address corresponding to the virtual contact address. On the other hand, not only is the user contact channel to the outside ensured, but also the real contact way is ensured not to be revealed. On the other hand, after the user cancels the virtual contact way, the outside cannot contact the user through the virtual contact way any more. Therefore, the problem of continuous disturbance caused by leakage of the real contact information is avoided. On the other hand, by using the chain storage of the virtual contact way, the verification function of the virtual contact way can be provided for the outside by using the characteristic that the block chain is not falsifiable, so as to determine whether the user providing the virtual contact way is the holder of the virtual contact way. Identity information is checked at any time, and the virtual contact way is prevented from being forged.

The real contact way in the description can be a real mobile phone number, and the virtual contact way can be a virtual mobile phone number. For another example, the real contact address may be a real account, and the virtual contact address may be a virtual account. These accounts may be, for example, mailbox accounts, user accounts for various applications. The application may be, for example, a user account for social software, a user account for instant messaging, a payment account for a payment application, etc.

This is further described below in connection with the exemplary embodiment shown in fig. 4. Fig. 4 is a flowchart of a block chain-based privacy protection method according to an exemplary embodiment. The method can be applied to a system for protecting the privacy of the real contact way of the user, and the system can comprise a user party, a communication operator, a blockchain system, an identity authentication party and a verification request party. Specifically, the method shown in fig. 4 may be divided into an application stage (hereinafter referred to as an application stage) of the virtual contact, a recovery stage (hereinafter referred to as a recovery stage) of the virtual contact, and a verification stage (hereinafter referred to as a verification stage) of the virtual contact, and each stage may include the following steps:

firstly, an application stage:

step 1: and the user side submits the real contact information of the user.

The user side may refer to a terminal device used by a user, and the terminal device may be, for example, a smart phone, a tablet computer, a handheld computer, a desktop computer, a laptop computer, a smart wearable device, or the like. The user can send the real contact information to the communication operator through the terminal equipment.

Step 1.1: the communication operator stores the actual contact information of the user.

A communication operator may refer to an operator that provides communication contact for different users. For example, the communication carrier may be a telecommunications carrier, using a telecommunications network to carry two-way voice in real time for conversational communication. For the communication mode of information interaction for data transmission of the internet, the communication operator may be a network operator.

It is worth mentioning that in the communication mode of real-time transmitting two-way voice to carry out conversation by using the telecommunication network, the communication operator can also be a virtual operator. The virtual operator refers to a new type of telecommunication operator that relies on hiring communication resources of a conventional telecommunication operator to carry out telecommunication services. The virtual operator can improve the communication service according to the self business requirement after renting the basic communication resource so as to provide personalized and differentiated service. Such as the virtual contact means provided in this specification.

Step 2: the communication operator initiates an identity information acquisition request to a user side.

In order to confirm the user identity, the communication operator may initiate an identity information acquisition request to the user.

And step 3: and the user side collects and uploads the identity information of the user.

And after receiving the identity information acquisition request, the user terminal acquires the identity information of the user and uploads the acquired identity information to a communication operator.

The identity information may be information or data having a unique identification of the user. For example, it may refer to a preset password, an identification number, biometric information, and the like. Specifically, the biometric information may include a face, a fingerprint, a voiceprint, an iris, a brain wave, a palm print, and the like. The specific identity information is not limited in this specification.

Step 3.1: the communication operator initiates a checking request aiming at the identity information to the identity authentication party.

And 4, step 4: and the identity authentication party authenticates the identity information and returns an authentication result.

After receiving the identity information of the user, the communication operator may initiate a verification request for the identity information to an identity authenticator having an identity authentication function.

The identity authentication party stores the identity information reserved by the user; thus, the acquired identity information is compared with the reserved identity information; if the comparison result is consistent, the acquired identity information is the identity of the user, and authentication can be returned. If the comparison result is inconsistent, the acquired identity information is not the identity of the user, and further the authentication can be returned to fail.

It is worth mentioning that if the communication operator itself stores the identity information reserved by the user, the communication operator itself can perform the identity authentication.

Step 4.1: and if the authentication is not passed, the communication operator initiates the identity information acquisition request to the user side again, namely, the step 2 is executed again.

Step 4.2: and the communication operator stores the identity information passing the authentication.

Step 4.3: and the communication operator returns the authentication passing result to the user side after passing the authentication.

And 5: the user side submits an application request of the virtual contact way to a communication operator.

Wherein the application request carries the real contact information of the user.

Step 5.1: the communication operator determines the virtual contact means.

The communication operator determines an idle virtual contact address.

Step 6: and the communication operator uploads the virtual contact way and the identity information to a block chain.

In one embodiment, the communication operator may first calculate a summary of the virtual contact address and the identity information as a whole (for convenience of distinction, this summary is referred to as an application summary), and then issue this application summary as an application transaction to the blockchain to enable the blockchain to verify the application summary.

Step 6.1: and the block links the virtual contact way and the identity information uploaded by the communication operator.

Step 6.2: the blockchain returns the uplink result.

And 7: and the communication operator establishes a corresponding relation between the virtual contact way and the real contact way.

The corresponding relation is a one-to-one corresponding relation, namely, one virtual contact address corresponds to one real contact address only.

The communication operator may locally maintain a mapping table storing the correspondence, and if the correspondence between the virtual contact information and the real contact information is established, the virtual contact information and the real contact information are recorded in the mapping table.

And 8: and the communication operator returns the virtual contact way to the user side.

And step 9: the user can provide virtual contact means to the outside.

The user can take the virtual contact way as an externally provided contact way; the outside world can only contact the user through the virtual contact way; specifically, when receiving a contact request for a virtual contact address, a communication operator may route the contact request to a real contact address according to the real contact address corresponding to the virtual contact address; therefore, although the user provides the virtual contact way to the outside, the user can still receive the outside contact request under the real contact way.

II, a recovery stage:

step 10: and the user side submits a recovery request of the virtual contact way to the communication operator.

The recovery request carries the real contact information of the user and the collected identity information.

Step 10.1: and the communication operator authenticates the identity of the user side.

Since the communication operator already stores the identity information of the user in step 4.2, the communication operator can directly authenticate the identity information carried in the recovery request locally. Only after the authentication is passed, step 10.2 can be performed; if the authentication is not passed, the recovery is terminated. Thereby avoiding the malicious transmission of the virtual contact means.

Step 10.2: and the communication operator deletes the corresponding relation between the virtual contact way and the real contact way.

If the authentication passes, the virtual contact address and the real contact address recorded in the mapping table are deleted, as in the mapping table of the previous step 7.

Step 11: and the communication operator uploads the virtual contact way, the identity information, the unbinding moment and the unbinding identification to a block chain.

In one embodiment, the communication operator may first calculate a summary of the virtual contact address, the identity information, and the unbinding time as a whole (for convenience of distinction, this summary is referred to as a recycle summary), and then issue this recycle summary as a recycle transaction to the blockchain, so that the blockchain certifies the recycle summary.

Step 11.1: and the block chain stores the virtual contact way of the certificate, the identity information, the unbinding moment and the unbinding identification.

Step 11.2: the blockchain returns the uplink result.

Step 11.3: and the communication operator returns a recovery result to the user side.

After the user applies for the virtual contact way, the user can cancel the virtual contact way at any time. And after the user cancels the virtual contact, the outside cannot contact the user through the virtual contact, and the external connection does not have the real contact of the user, so that the problem of continuous disturbance caused by contact leakage can be avoided.

Thirdly, checking:

step 12: the verification request side submits a verification request for the virtual contact address to the communication operator.

Wherein the check request carries the virtual contact way and the collected identity information;

in some scenarios, it may be necessary to verify the user providing the virtual contact address to determine that the holder of the virtual contact address is indeed the user.

The function of checking the authenticity of the virtual contact way of the user at any time can be provided for the outside by utilizing the characteristic that the block chain can not be tampered.

Step 12.1: the communication operator inquires the binding time and the unbinding time of the virtual contact way.

When the current time is greater than the binding time and the binding time does not exist, executing the step 12.2;

when the current time is greater than the unbinding time, returning authentication failure to the authentication requester;

and when the current time is less than the binding time, returning authentication failure to the authentication requester.

Step 12.2: and initiating a query transaction to the blockchain, wherein the query transaction carries the virtual contact way and the identity information.

In one embodiment, the communication operator may first calculate a digest of the virtual contact address and the identity information as a whole (for the sake of distinction, this digest is referred to as a verification digest), and then issue this verification digest as a verification transaction to the blockchain.

Step 12.3: and the block chain checks whether the virtual contact way and the identity information exist in the block chain.

The node equipment of the block chain responds to the checking transaction, calls checking logic declared in the intelligent contract on the block chain, and inquires whether the virtual contact way and the identity information are stored in the block chain; if yes, the check is returned to pass, and if not, the check is returned to fail.

If the application stage block chain is verified to be the application abstract, the checking logic stated in the intelligent contract is to check whether the application abstract same as the checking abstract is stored in the block chain; if yes, the check is returned to pass, and if not, the check is returned to fail.

Step 12.4: the blockchain returns a verification result.

Step 12.5: the communication operator returns the verification result to the verification requester.

To sum up, in the embodiments provided in this specification, by allocating a virtual contact address uniquely corresponding to a real contact address to a user, the user can use the virtual contact address as an externally provided contact address; the outside world can only contact the user through the virtual contact way; specifically, when receiving a contact request for a virtual contact address, a communication operator may route the contact request to a real contact address according to the real contact address corresponding to the virtual contact address. On the other hand, not only is the user contact channel to the outside ensured, but also the real contact way is ensured not to be revealed. On the other hand, after the user cancels the virtual contact way, the outside cannot contact the user through the virtual contact way any more. Therefore, the problem of continuous disturbance caused by leakage of the real contact information is avoided. On the other hand, by using the chain storage of the virtual contact way, the verification function of the virtual contact way can be provided for the outside by using the characteristic that the block chain is not falsifiable, so as to determine whether the user providing the virtual contact way is the holder of the virtual contact way. Identity information is checked at any time, and the virtual contact way is prevented from being forged.

Corresponding to the method embodiment shown in fig. 4, the present specification further provides a method embodiment with a communication operator as an execution subject, and as shown in fig. 5, the method may include:

step 210, receiving an application request of a virtual contact way submitted by a user side, wherein the application request carries a real contact way of the user.

Step 220, determining an idle virtual contact way, establishing a corresponding relation between the virtual contact way and the real contact way, and issuing the virtual contact way and the identity information of the user to a block chain for storing a certificate;

the virtual contact information and the identity information of the user can be taken as a whole, the application abstract is calculated firstly, and then the chain deposit certificate is uploaded to the application abstract in a transaction form.

For example, the application digest is a hash value obtained by calculating (virtual contact information and identity information) by using a hash algorithm.

Step 230, returning the virtual contact information to the user side, so that the user uses the virtual contact information as an externally provided contact information;

step 240, when receiving the contact request for the virtual contact address, routing the contact request to the real contact address according to the real contact address corresponding to the virtual contact address.

In this way, the user can use the virtual contact way as an externally provided contact way by allocating the virtual contact way uniquely corresponding to the real contact way to the user; the outside world can only contact the user through the virtual contact way; not only ensures the user to contact the channel to the outside, but also ensures that the real contact way is not revealed.

In an exemplary embodiment, before determining a free virtual contact at step 220, the method further comprises:

and initiating an identity information acquisition request to the user side, and receiving and storing the identity information of the user acquired and uploaded by the user side.

The communication operator collects the identity information of the user through the user side, so that the identity of the user is authenticated based on the identity information collected in real time. Not only is the security improved, but also the identity information can be used for identity authentication in the subsequent steps.

As shown in fig. 4, a recycling phase is further included after the application phase, that is, an embodiment of recycling virtual contact is provided:

receiving a recovery request of a virtual contact way submitted by a user side, wherein the recovery request carries a real contact way of the user;

inquiring whether the real contact information corresponds to a virtual contact information;

if so, deleting the corresponding relation between the virtual contact way and the real contact way;

and issuing the virtual contact way, the identity information of the user and the unbinding moment to a block chain for storing the certificate.

The virtual contact way, the identity information of the user and the unbinding moment can be taken as a whole, the recovery abstract is calculated firstly, and then the recovery abstract is used for chain deposit certificate in a transaction applying mode.

For example, the application digest is a hash value obtained by calculating (virtual contact information and identity information and unbinding time) by using a hash algorithm.

Wherein, the recovery request also carries the user identity information collected by the user;

before inquiring whether the real contact address corresponds to the virtual contact address, the method further comprises the following steps:

comparing the identity information carried by the recovery request with the stored identity information;

the querying whether the real contact information corresponds to a virtual contact information includes:

and if the identity information carried by the recovery request is consistent with the stored identity information, inquiring whether the real contact information corresponds to a virtual contact information.

In an exemplary embodiment, the aforementioned identity information may include a face image; accordingly:

in the application phase, the receiving and storing of the user's identity information collected and uploaded by the user side includes:

receiving a face image of a user collected and uploaded by the user side;

extracting each face feature from the face image, and storing each face feature;

in the recovery stage. The comparing the identity information carried by the recovery request with the stored identity information includes:

extracting each face feature from the face image carried by the recovery request;

and comparing each extracted face feature with each face feature of the stored face image.

In this embodiment, the user can cancel the virtual contact address at any time after applying for the virtual contact address. And after the user cancels the virtual contact, the outside cannot contact the user through the virtual contact, and the external connection does not have the real contact of the user, so that the problem of continuous disturbance caused by contact leakage can be avoided.

As shown in fig. 4, a verification phase is further included after the application phase, that is, an embodiment for verifying the authenticity of the virtual contact is provided:

receiving a verification request submitted by a verification requester, wherein the verification request carries the virtual contact way and the identity information of the user;

issuing the virtual contact way and the identity information to the blockchain in a check transaction mode so that node equipment of the blockchain responds to the check transaction, calling a check logic declared in an intelligent contract on the blockchain, and inquiring whether the virtual contact way and the identity information are stored in the blockchain or not; if the verification does not exist, returning that the verification does not pass;

and sending the verification result returned by the block chain to the verification requester.

The virtual contact information and the identity information can be taken as a whole, the checking abstract is calculated firstly, and then the chain deposit certificate is sent to the recovery abstract in a checking transaction form. The checking logic stated in the intelligent contract is that whether the application abstract same as the checking abstract exists in the block chain is inquired; if yes, the check is returned to pass, and if not, the check is returned to fail.

Wherein before issuing the virtual contact address and the identity information to the blockchain in a transaction checking manner, the method further comprises:

inquiring the binding time and the unbinding time of the virtual contact way;

the issuing of the virtual contact and identity information to the blockchain in a transaction verification manner includes:

when the current time is greater than the binding time and the binding time is not available, the virtual contact way and the identity information are issued to the block chain in a transaction checking way;

when the current time is greater than the unbinding time, returning that the verification fails to pass to the verification requesting party;

and returning that the verification is not passed to the verification requesting party when the current time is less than the binding time.

In this embodiment, by using the chain link for storing the virtual contact, the verification function of the virtual contact can be provided for the outside world by using the characteristic that the blockchain is not tampered, so as to determine whether the user providing the virtual contact is a holder of the virtual contact. Identity information is checked at any time, and the virtual contact way is prevented from being forged.

Corresponding to the above method embodiments, the present specification further provides an embodiment of a privacy protecting apparatus based on a block chain.

The embodiment of the block chain-based hierarchical storage device of the present specification can be applied to an electronic device. The device embodiments may be implemented by software, or by hardware, or by a combination of hardware and software. Taking a software implementation as an example, as a logical device, the device is formed by reading, by a processor of the electronic device where the device is located, a corresponding computer program instruction in the nonvolatile memory into the memory for operation.

In terms of hardware, as shown in fig. 6, the block chain-based privacy protection apparatus in this specification is a hardware structure diagram of an electronic device in which the privacy protection apparatus is located, except for the processor, the memory, the network interface, and the nonvolatile memory shown in fig. 6, the electronic device in which the apparatus is located in the embodiment may also include other hardware according to an actual function of the electronic device, which is not described again.

Fig. 7 is a block diagram illustrating a block chain based privacy protection apparatus according to an exemplary embodiment of the present disclosure.

Referring to fig. 7, the privacy protecting apparatus based on the block chain may be applied to the electronic device shown in fig. 6 and corresponds to the method embodiment shown in fig. 4, where the apparatus includes:

a first receiving unit 310, configured to receive an application request of a virtual contact address submitted by a user, where the application request carries a real contact address of the user;

the issuing unit 320 determines an idle virtual contact way, establishes a corresponding relationship between the virtual contact way and the real contact way, and issues the virtual contact way and the identity information of the user to a block chain for storing a certificate;

a returning unit 330, which returns the virtual contact address to the user side, so that the user uses the virtual contact address as an externally provided contact address;

the routing unit 340, when receiving the contact request for the virtual contact address, routes the contact request to the real contact address according to the real contact address corresponding to the virtual contact address.

Optionally, the apparatus further comprises:

the second receiving unit is used for receiving a recovery request of the virtual contact way submitted by a user side, wherein the recovery request carries a real contact way of the user;

the first query unit is used for querying whether the real contact information corresponds to a virtual contact information;

the unbinding unit deletes the corresponding relation between the virtual contact way and the real contact way if the virtual contact way and the real contact way are the same;

and the second card storage unit is used for issuing the virtual contact way, the identity information of the user, the unbinding moment and the unbinding identification to the block chain for card storage.

Optionally, the apparatus further comprises:

the third receiving unit is used for receiving a checking request which is submitted by a checking requester and aims at a user, wherein the checking request carries a virtual contact way and identity information of the user;

the authentication unit is used for issuing the virtual contact way and the identity information to the block chain in an authentication transaction mode so that the node equipment of the block chain responds to the authentication transaction, calling authentication logic declared in an intelligent contract on the block chain and inquiring whether the virtual contact way and the identity information are stored in the block chain or not; if the authentication exists, the authentication is returned to pass, and if the authentication does not exist, the authentication is returned to fail;

and the return unit is used for sending the authentication result returned by the block chain to the checking requester.

Optionally, the method further includes:

and the acquisition unit initiates an identity information acquisition request to the user party and receives and stores the identity information of the user acquired and uploaded by the user party.

Optionally, the recovery request further carries the identity information of the user, which is collected by the user;

the comparing unit is used for comparing the identity information carried by the recovery request with the stored identity information; and if the identity information carried by the recovery request is consistent with the stored identity information, executing the first query unit.

Optionally, the identity information includes a face image;

the acquisition unit specifically includes: initiating a face image acquisition request to the user side, receiving face images of the user acquired and uploaded by the user side, extracting each face feature from the face images, and storing each face feature;

the comparison unit specifically includes:

extracting each face feature from the face image carried by the recovery request, and comparing each extracted face feature with each face feature of the stored face image; and if the first query unit is consistent with the second query unit, executing the first query unit.

Optionally, the apparatus further comprises:

the second query unit is used for querying the binding time and the unbinding time of the virtual contact way; and when the current time is greater than the binding time and the binding time does not exist, executing the authentication unit.

Optionally, the second query unit further includes: when the current time is greater than the unbinding time, returning authentication failure to the checking requester; and when the current time is less than the binding time, returning authentication failure to the checking requester.

Optionally, the real contact way is a real mobile phone number, and the virtual contact way is a virtual mobile phone number.

Optionally, the blockchain comprises a federation chain.

The systems, devices, modules or units illustrated in the above embodiments may be implemented by a computer chip or an entity, or by a product with certain functions. A typical implementation device is a computer, which may take the form of a personal computer, laptop computer, cellular telephone, camera phone, smart phone, personal digital assistant, media player, navigation device, email messaging device, game console, tablet computer, wearable device, or a combination of any of these devices.

In a typical configuration, a computer includes one or more processors (CPUs), input/output interfaces, network interfaces, and memory.

The memory may include forms of volatile memory in a computer readable medium, Random Access Memory (RAM) and/or non-volatile memory, such as Read Only Memory (ROM) or flash memory (flash RAM). Memory is an example of a computer-readable medium.

Computer-readable media, including both non-transitory and non-transitory, removable and non-removable media, may implement information storage by any method or technology. The information may be computer readable instructions, data structures, modules of a program, or other data. Examples of computer storage media include, but are not limited to, phase change memory (PRAM), Static Random Access Memory (SRAM), Dynamic Random Access Memory (DRAM), other types of Random Access Memory (RAM), Read Only Memory (ROM), Electrically Erasable Programmable Read Only Memory (EEPROM), flash memory or other memory technology, compact disc read only memory (CD-ROM), Digital Versatile Discs (DVD) or other optical storage, magnetic cassettes, magnetic disk storage, quantum memory, graphene-based storage media or other magnetic storage devices, or any other non-transmission medium that can be used to store information that can be accessed by a computing device. As defined herein, a computer readable medium does not include a transitory computer readable medium such as a modulated data signal and a carrier wave.

It should also be noted that the terms "comprises," "comprising," or any other variation thereof, are intended to cover a non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements does not include only those elements but may include other elements not expressly listed or inherent to such process, method, article, or apparatus. Without further limitation, an element defined by the phrase "comprising an … …" does not exclude the presence of other like elements in a process, method, article, or apparatus that comprises the element.

The foregoing description has been directed to specific embodiments of this disclosure. Other embodiments are within the scope of the following claims. In some cases, the actions or steps recited in the claims may be performed in a different order than in the embodiments and still achieve desirable results. In addition, the processes depicted in the accompanying figures do not necessarily require the particular order shown, or sequential order, to achieve desirable results. In some implementations, multitasking and parallel processing may also be possible or may be advantageous.

The terminology used in the description of the one or more embodiments is for the purpose of describing the particular embodiments only and is not intended to be limiting of the description of the one or more embodiments. As used in one or more embodiments of the present specification and the appended claims, the singular forms "a," "an," and "the" are intended to include the plural forms as well, unless the context clearly indicates otherwise. It should also be understood that the term "and/or" as used herein refers to and encompasses any and all possible combinations of one or more of the associated listed items.

It should be understood that although the terms first, second, third, etc. may be used in one or more embodiments of the present description to describe various information, such information should not be limited to these terms. These terms are only used to distinguish one type of information from another. For example, first information may also be referred to as second information, and similarly, second information may also be referred to as first information, without departing from the scope of one or more embodiments herein. The word "if" as used herein may be interpreted as "at … …" or "when … …" or "in response to a determination", depending on the context.

The above description is only for the purpose of illustrating the preferred embodiments of the one or more embodiments of the present disclosure, and is not intended to limit the scope of the one or more embodiments of the present disclosure, and any modifications, equivalent substitutions, improvements, etc. made within the spirit and principle of the one or more embodiments of the present disclosure should be included in the scope of the one or more embodiments of the present disclosure.

Claims

1. A privacy protection method based on a blockchain, the method comprising:

2. The method of claim 1, further comprising:

and issuing the virtual contact way, the identity information of the user, the unbinding moment and the unbinding identification to a block chain for storing the certificate.

3. The method of claim 1, further comprising:

receiving a verification request aiming at a user and submitted by a verification requester, wherein the verification request carries a virtual contact way and identity information of the user;

4. The method of claim 2, prior to said determining an idle virtual contact, the method further comprising:

5. The method of claim 4, wherein the recovery request further carries the identity information of the user collected by the user;

6. The method of claim 5, the identity information comprising a facial image;

the receiving and storing the user identity information collected and uploaded by the user side comprises:

receiving a face image of a user collected and uploaded by the user side;

the comparing the identity information carried by the recovery request with the stored identity information includes:

7. The method of claim 3, further comprising, prior to issuing the virtual contact and identity information to the blockchain in a transaction-verifying manner:

inquiring the binding time and the unbinding time of the virtual contact way;

and when the current time is greater than the binding time and the binding time is not available, the virtual contact way and the identity information are issued to the block chain in a transaction checking way.

8. The method of claim 7, further comprising:

9. The method of claim 1, wherein the real contact means is a real mobile phone number and the virtual contact means is a virtual mobile phone number.

10. The method of claim 1, the blockchain comprising a federation chain.

11. A privacy preserving apparatus based on a blockchain, the apparatus comprising:

12. The apparatus of claim 11, the apparatus further comprising:

13. The apparatus of claim 11, the apparatus further comprising:

the checking unit is used for issuing the virtual contact way and the identity information to the block chain in a checking transaction mode so that the node equipment of the block chain responds to the checking transaction, calling checking logic declared in an intelligent contract on the block chain and checking whether the virtual contact way and the identity information are stored in the block chain or not; if the verification does not exist, returning that the verification does not pass;

and the return unit is used for sending the verification result returned by the block chain to the verification requester.

14. The apparatus of claim 12, further comprising:

15. The apparatus according to claim 14, wherein the recovery request further carries the identity information of the user collected by the user;

16. The apparatus of claim 15, the identity information comprising a facial image;

the comparison unit specifically includes:

17. The apparatus of claim 13, the apparatus further comprising:

the second query unit is used for querying the binding time and the unbinding time of the virtual contact way; and when the current time is greater than the binding time and the binding time does not exist, executing the verification unit.

18. The apparatus of claim 17, the second query unit further comprising: when the current time is greater than the unbinding time, returning that the verification fails to pass to the verification requesting party; and returning that the verification is not passed to the verification requesting party when the current time is less than the binding time.

19. The apparatus of claim 11, the real contact means is a real cell phone number, and the virtual contact means is a virtual cell phone number.

20. The apparatus of claim 11, the blockchain comprises a federation chain.

21. An electronic device, comprising:

a processor;

a memory for storing processor-executable instructions;

wherein the processor implements the method of any one of claims 1-10 by executing the executable instructions.