CN114444097A

CN114444097A - Block chain-based user access method and device, electronic equipment and storage medium

Info

Publication number: CN114444097A
Application number: CN202210028059.6A
Authority: CN
Inventors: 沈健刚; 王凯; 杨志雄
Original assignee: Alipay Hangzhou Information Technology Co Ltd
Current assignee: Alipay Hangzhou Information Technology Co Ltd
Priority date: 2022-01-11
Filing date: 2022-01-11
Publication date: 2022-05-06

Abstract

A user access method, a device, an electronic device and a storage medium based on a block chain are provided. The method is applied to node equipment in a block chain; numerical values of user characteristics are stored in blocks of the block chain in advance; the method comprises the following steps: receiving an admission evaluation transaction for a target user; responding to the admission evaluation transaction, calling an intelligent contract to inquire whether a historical credit evaluation value corresponding to the target user is stored in a block of the block chain; if the value of the user characteristic associated with the target user is stored and is not changed, determining whether the target user is allowed to be admitted or not based on the historical credit evaluation value; if the numerical value of the user characteristic which does not exist or is associated with the target user is changed, the credit evaluation value is determined by calling the access evaluation logic corresponding to the intelligent contract code, whether the target user is allowed to access or not is determined, and the determined credit evaluation value is stored in the block of the block chain.

Description

Block chain-based user access method and device, electronic equipment and storage medium

Technical Field

One or more embodiments of the present disclosure relate to the field of block chain technologies, and in particular, to a method and an apparatus for block chain-based user admission, an electronic device, and a storage medium.

Background

The institution needs to provide credit services to the user, so the value of the user's characteristics is checked, and when the value of the user's characteristics meets a preset condition, the user is allowed to be admitted, and the admitted user can obtain the services provided by the institution. In the prior art, the strategy for checking the value of the user's feature is a "cut-off" strategy, that is, if the value of a certain feature of the user is not satisfied with a preset condition, the user is not allowed to access; since some features are not important to the user's credit judgment, if the user is not admitted only for the unimportant features, the user will complain; meanwhile, the existing related technology runs on a specific server during inspection, and once the server is maliciously controlled or fails, the judgment on the user admission is inaccurate.

Disclosure of Invention

In view of this, the present application provides a block chain-based user admission method and apparatus, and an electronic device.

According to a first aspect of the present application, a block chain-based user admission method is applied to a node device in a block chain; an intelligent contract used for carrying out admission evaluation on a user is deployed in the block chain, and numerical values of user characteristics are stored in blocks of the block chain in advance; the method comprises the following steps:

receiving an admission evaluation transaction for a target user; wherein the admission evaluation transaction is used to invoke the smart contract to obtain a numerical value of the user characteristic associated with the target user;

in response to the admission evaluation transaction, invoking the intelligent contract to inquire whether a historical credit evaluation value corresponding to the target user is stored in a block of a block chain;

and determining whether the target user is allowed to be admitted or not based on the query result or the calling intelligent contract.

According to a second aspect of the present application, there is provided a block chain-based user admission apparatus, which is applied to a node device in the block chain; an intelligent contract used for carrying out admission evaluation on a user is deployed in the block chain, and numerical values of user characteristics are stored in blocks of the block chain in advance; the device comprises:

the receiving module is used for receiving the admission evaluation transaction of the target user; wherein the admission evaluation transaction is used to invoke the smart contract to obtain a numerical value of the user characteristic associated with the target user;

the query module is used for responding to the admission evaluation transaction, calling the intelligent contract to query whether the historical credit evaluation value corresponding to the target user is stored in a block of a block chain; and determining whether the target user is allowed to be admitted or not based on the query result or the calling intelligent contract.

According to a third aspect of the present application, there is provided an electronic device comprising a processor;

a memory for storing processor-executable instructions;

wherein the processor implements the method of the first aspect of the present application by executing the executable instructions.

According to a fourth aspect of the present application, there is provided a computer readable storage medium having computer instructions thereon which, when executed by a processor, implement the steps of the method of the first aspect of the present application.

In the technical scheme, the query logic corresponding to the intelligent contract code in the intelligent contract is called, and whether the target user is allowed to be accessed is determined based on the query result or the intelligent contract calling, so that the user access is judged more accurately, the user complaint rate is reduced, and the user access probability is improved. And the determined credit evaluation value is stored in the block of the block chain, so that the credit evaluation value for access can be traced and cannot be tampered, and the safety and reliability of user access are realized.

Drawings

FIG. 1 is a schematic diagram of an organization of account state data for blockchains into an MPT state tree provided by an exemplary embodiment;

FIG. 2 is a diagram of organizing contract data stored in storage space corresponding to a contract account into an MPT storage tree, according to 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 method for intelligent contract management based on blockchains according to an exemplary embodiment;

FIG. 5 is a flowchart of another intelligent contract management method based on blockchains, as provided by an exemplary embodiment;

fig. 6 is a schematic diagram illustrating a block chain based user admission system according to an exemplary embodiment;

fig. 7 is a flowchart of a block chain-based user admission method according to an exemplary embodiment;

fig. 8 is a block diagram of an apparatus of a block chain-based user admission method according to an exemplary embodiment;

fig. 9 is a hardware block diagram of an electronic device 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 following exemplary embodiments 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 that 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.

A block chain is typically made up 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 data generated outside the chain can be constructed into a standard transaction (transaction) format supported by the blockchain, then the data is issued to the blockchain, the node devices in the blockchain perform consensus on the transaction, and after the consensus is achieved, the node devices serving as accounting nodes in the blockchain package the transaction into blocks, and the persistent evidence is stored in the blockchain.

Current blockchain systems typically include two mainstream transaction models; one of them is UTXO (un-spent Transaction Output) model; and the other is an account model.

If the two types of block chains want to implement data storage, the following storage mode can be generally adopted:

for blockchains employing the UTXO model, the supported native transactions typically include only transfer transactions, and during transfer based transfer transactions, the user may deposit additional data on the blockchain by populating the additional data in the transaction epilogue (i.e., the transfer epilogue) in the transfer transaction.

For a blockchain adopting an account model, blockchain data which needs to be stored and maintained generally include blockchain data and account state data corresponding to blockchain accounts in the blockchain; the tile data may further include tile header data, tile transaction data in the tile, and a transaction receipt corresponding to the tile transaction data in the tile, etc. When storing the various blockchain data shown above, the various blockchain data can be organized into a Merkle tree to be stored in a database in the form of key-value key value pairs.

In such a blockchain model, an intelligent contract for data verification may be deployed on a blockchain, and a user may store data that needs to be verified as an account state of a contract account corresponding to the intelligent contract into a Merkle tree corresponding to the intelligent contract by calling the intelligent contract.

For example, taking the blockchain network of the account model as an example, a special Merkle tree called MPT tree is usually used to store and maintain blockchain data; for the account state data, an MPT state tree (commonly called world state) can be organized and stored in the database; the MPT state tree stores key-value key value pairs with account addresses as keys and account state data as values. The data content stored in the contract account corresponding to the intelligent contract is further organized into a storage tree (an MPT storage tree for storing data) to be stored in the database; filling the hash value of the root node of the storage tree into the MPT state tree as a part of account state data corresponding to the contract account; the hash of the root node of the MPT state tree is used as the authentication root and is further filled into the block header. When a user needs to perform data storage, the data needing to be stored can be used as account state data of a contract account corresponding to the intelligent contract in a mode of calling the intelligent contract and stored in a storage tree corresponding to the intelligent contract.

In the field of blockchain, an important concept is Account (Account); the blockchain network of the account model generally divides the accounts into two categories, namely external accounts and contract accounts; 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).

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.

In one example, the structure of an account typically 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 content of the account; 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 stored in the independent storage space in a data structure constructed as an mpt (media Patricia trie) tree in the form of key-value key value pairs. An MPT tree is a logical tree structure in the field of blockchains for storing and maintaining blockchain data, and typically includes root nodes, intermediate nodes, and leaf nodes in the tree structure.

The logical tree structure is a structure in which physical storage structures completely corresponding to the tree structure do not exist in the underlying physical storage of the database, but only physical data of each node on the tree structure and link relation data between nodes are stored in the database, so that the tree structure can be logically restored based on the physical data and the link relation data of each node stored in the database.

The MPT tree is constructed based on the Storage content of the contract account, and 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. For the external account, the field values of the Code field and the Storage field shown above are both null values.

For node devices of a blockchain, blockchain data which needs to be stored and maintained generally includes blockchain data and account status data corresponding to blockchain accounts in the blockchain; the tile data may further include tile header data, tile transaction data in the tile, and a transaction receipt corresponding to the tile transaction data in the tile, etc.

For most blockchain models, a Merkle tree is usually used; or a logical tree structure based on Merkle tree varieties of the Merkle tree data structure to store and maintain data. For example, the MPT tree is a Merkle tree variant that merges the tree structures of Trie dictionary trees for storing and maintaining blockchain data.

When storing the various blockchain data shown above, the blockchain node device may generally organize the various blockchain data in the form of key-value key value pairs into the logical tree structure, and store the logical tree structure in the database. When the various blockchain data stored in the node device need to be queried, the data can be efficiently queried by traversing the Merkle tree by taking the keys of the various blockchain data as query indexes.

For example, an mpt (Merkle Patricia Trie) tree, which is a Merkle tree variation that merges the tree structure of the Trie dictionary tree and is used to store and maintain block chain data.

The following description will be given taking the example of using an MPT tree to organize and store block chain data;

among other things, it is emphasized that the use of an MPT tree to organize and store block chain data is merely exemplary. In practical applications, in addition to the modified version of the Merkle tree such as the MPT tree, other forms of Merkle tree varieties that merge the Trie dictionary trees may be used, which are not listed in this specification.

In one example, blockchain data that needs to be stored and maintained in the blockchain, typically includes account status (state) data, transaction data, and receipt data; therefore, in practical applications, the account status data, the transaction data, and the receipt data may be respectively combined into three MPT trees, such as an MPT status tree, an MPT transaction tree, and an MPT receipt tree, in the form of key-value key value pairs, and stored and maintained respectively.

In addition to the above three MPT trees, the contract data stored in the Storage space corresponding to the contract account is usually constructed as an MTP Storage tree (hereinafter, referred to as Storage tree). The hash value of the root node of the Storage tree is added to the Storage field in the struct of the contract account corresponding to the Storage tree.

The MPT state tree is organized by account state data of all accounts (including external accounts and contract accounts) in the block chain in the form of key-value key value pairs; the MPT transaction tree is organized by transaction (transaction) data in a block chain in a key-value key value pair form; the MPT receipt tree is an MPT tree which is organized in a key-value key value pair mode, wherein a transaction (receipt) receipt corresponding to each transaction is 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.

When a block chain generates a latest block, after a transaction in the latest block is executed, the account status of the accounts (which may be external accounts or contract accounts) related to the executed transaction in the block chain 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 transaction in the latest block is completed, which results in a change of the account status of some accounts in the block chain, 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.

Referring to fig. 1, fig. 1 is a schematic diagram illustrating organization of account status data of each blockchain account in a blockchain into an MPT status tree according to the present disclosure.

The MPT tree is a more 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 types of nodes are typically included in the MPT tree, namely leaf nodes (leaf nodes), extension nodes (extension nodes), and branch nodes (branch nodes).

The extension nodes and the branch nodes can be collectively called character nodes and are used for storing character prefix parts of character strings corresponding to keys of the block chain data; for the MPT tree, the above character prefix part usually refers to a shared character prefix; the shared character prefix refers to a prefix formed by one or more same characters of all the blockchain account addresses. The leaf node is used for storing the Value (namely the specific data content) and the character suffix part of the character string corresponding to the key of the block chain data

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; 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:

TABLE 1

It should be noted that, in table 1, the block chain accounts corresponding to the account addresses in the first three rows are external accounts, and the Codehash and Storage root fields are null values. The block chain account corresponding to the account address in the 4 th row is a contract account, and the Codehash field maintains the hash value of the contract code corresponding to the contract account; the Storage root field maintains a hash value of the root node of the Storage tree of which the Storage contents of the contract account constitute.

Finally, an MPT state tree is organized according to the account state data in the table 1, as shown in the figure 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).

In fig. 1, 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 character node of a 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 fields of the 16-system characters 0-f in the branch nodes correspond to the key values of the key value pairs contained in the branch nodes; 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 fields 0 to f are used for filling the hash value of the next layer 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 all nodes on the search path from the root node to the leaf node constitute 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 shown in fig. 1 is also stored in the database in the form of Key-Value pair;

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.

When a node in the MPT state tree is stored in the database, a hash Value of data content contained in the node can be calculated (i.e., 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.

The node on the MPT state tree is stored in a Key-value Key value pair mode; the Key may be a hash Value of data content contained in the node, and the Value may be data content contained in the node; 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.

Referring to fig. 2, fig. 2 is a schematic diagram illustrating organization of contract data stored in a storage space corresponding to a contract account into an MPT storage tree according to this specification.

With continued reference to table 1, the account with the account address "a 77d 397" shown in table 1 is a contract account, so that the contract data stored in the storage space corresponding to the contract account is organized into a storage tree; the hash value S1 of the root node of the storage tree is added to the storage root field in the leaf node corresponding to the contract account in the MTP state tree shown in fig. 1.

Assume that the contract data stored in the storage space of the contract account is as shown in table 2 below:

TABLE 2

It should be noted that, the contract data stored in the storage space of the contract account may be generally in the form of a state variable; during storage, a hash value of the state variable name may be used as a key, a variable value corresponding to the state variable name may be used as a value, and a storage tree shown in fig. 2 is organized in a key-value key value pair form for storage. The basic structure of the storage tree shown in fig. 2 is similar to the MTP state tree shown in fig. 1, and is not described again in this specification.

As can be seen from the above description of fig. 1 and fig. 2, based on the tree structure design of the MPT tree, the branch node may store one of the characters in the shared character prefixes of all account addresses; and the extension node may store one or more characters in the shared character prefix of all account addresses.

In practical application, the character length of the shared character prefix of the key of all data stored on the MPT tree is not fixed generally; moreover, when new data is written into the MPT tree, the character length of the shared character prefix may change accordingly; therefore, the expansion nodes on the MPT tree can be split to generate new branch nodes; that is, the splitting condition of the nodes in the MPT tree is that the character length of the shared character prefix is changed;

for example, taking the MPT state tree shown in fig. 1 as an example, assuming that account state data of an account address with first two digits of "a 8" of an account address is added to the MPT state tree, the Shared character prefix stored in the "Shared table" field of the extension node shown in fig. 1 as the root node is changed from "a 7" to "a"; according to the splitting condition of the nodes of the MPT state tree, the extension node serving as the root node is split into a stored extension node with a shared character prefix of 'a'; and one branch node with the character "8" occupied.

In a programmable blockchain, some complex logic can be created and invoked by users in a blockchain network by providing the user with the functionality of a Smart contract (Smart contract). A so-called smart contract is a program that can be executed on a blockchain triggered by a transaction.

In the programmable block chain, each node device can carry a virtual machine with complete graphic flexibility as an execution environment of an intelligent contract, and various complex logics can be realized through the virtual machine.

The intelligent contracts issued and called by the users in the block chain are run on the virtual machine. In fact, the virtual machine directly runs virtual machine code (virtual machine bytecode, hereinafter referred to as "bytecode"), so the intelligent contract deployed on the blockchain may be bytecode.

As shown in fig. 3, after Bob sends an intelligent contract creation transaction containing contract codes to the blockchain network, each node device may execute the transaction in the hosted virtual machine.

In fig. 3, 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 the above 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. 3 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.

It was mentioned earlier that the Data field containing the transaction that created the intelligent contract holds what may be the bytecode 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.

In the Solidity language for example, contract code written using the method is similar to a Class (Class) in an object-oriented programming language, and can declare various members in a contract, including state variables, functions, function modifiers, events, and the like. 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. 4, still taking the blockchain network of the account model as an example, after Bob sends an intelligent contract invocation transaction to the blockchain network of the account model, each node device may execute the transaction in the mounted virtual machine.

In fig. 4, the From field of the transaction is used To record the address of the account initiating the invocation of the smart contract, the To field is used To record the address of the invoked smart contract, and the Data field of the transaction is used To record the method and parameters of the invocation of the smart contract. 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 blockchain node (e.g., node 1 in fig. 4).

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. 5. An intelligent contract is created in a block chain network of an account model, and the intelligent contract is required to be written, changed into byte codes, deployed to a block chain and the like. The intelligent contract is called in the block chain network of the account model, 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 operated in a distributed mode in the virtual machine of each node in the block chain network of the account model.

In programmable blockchains, it is often possible to support the conversion of physical assets of non-monetary attributes in the real world into digital assets on the blockchain. Converting the physical assets to the digital assets generally refers to a process of "anchoring" the physical assets to the digital assets on the blockchain as a value support for the virtual assets, and further generating digital assets on the blockchain that match the value of the physical assets 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 a block chain; the asset account, expanded, may serve as a vehicle for holding digital assets anchored to the physical asset value of non-monetary attributes in the real world.

For a user accessing a block chain, in addition to completing the creation of a user account and an intelligent contract on the block chain, a digital asset matched with the entity asset value of non-currency attributes of the real world can be created on the block chain and circulated on the block chain;

for example, a user may convert a physical property of non-monetary nature, such as real estate, stocks, loan contracts, notes, accounts receivable, etc., held to a value-matched digital property 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 the structure described above, and may of course be designed based on actual requirements;

in one implementation, the structure of the asset account may also include the above-described Balance, Nonce, Code, and Storage fields.

It should be noted that the Balance field is generally used to maintain the current account Balance of the account; for the above asset account, since the entity asset anchored by the asset account may be a non-Balance type asset which cannot be counted based on the Balance, the meaning of the Balance field may be extended, and the "Balance" of the account is not represented, but is used for maintaining the address information of the asset. In practical application, address information corresponding to a plurality of digital assets can be maintained in the Balance field.

In this case, the external account, the contract account, and the asset account shown above may hold the digital asset by adding address information of "digital asset" 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 digital 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.

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

In this scenario, the intelligent contract deployed on the blockchain can access data on the data entities outside the chain through the Oracle ora. Data entities outside the chain may include, for example, centralized servers or data centers deployed outside the chain, and so on.

When the organization needs to provide credit service for the user, the value of the user characteristic is checked, when the value of the user characteristic meets a preset condition, the user is allowed to be admitted, and the admitted user can obtain the service provided by the organization. Taking the example of applying for the housing loan before the user purchases the housing, the user characteristic to be checked can be the housing accumulation fund paid by the user, and the numerical value of the user characteristic can be the age of paying the housing accumulation fund or the balance of the accumulation fund. In the prior art, the strategy adopted for checking the numerical value of the user characteristic is a 'break' strategy, that is, if the numerical value of a certain characteristic of a user does not meet the preset condition, the user is not allowed to access; and if the user does not continuously pay the house accumulation fund for three years, the user is not allowed to obtain the house accumulation fund loan.

Since a part of the user characteristics are not important for the judgment of the user credit, if the user is not allowed to access only because of the unimportant characteristics, the user will complain; meanwhile, related codes for checking numerical values of user characteristics in the existing related technology run on a specific server, and once the server is maliciously controlled or fails, judgment on user admission can be inaccurate.

Due to the fact that the blockchain technology is used, data stored on the blockchain can be traceable and not be tampered, the blockchain uses distributed computing, the blockchain runs on a plurality of equipment nodes, and safety and reliability of intelligent contract codes running on the blockchain can be guaranteed. Therefore, the application provides a block chain-based user admission method.

Referring to fig. 6, fig. 6 is a schematic diagram of a block chain based user admission system according to an exemplary embodiment of the present disclosure.

In a block chain based user admission system as shown in fig. 6, an intelligent contract may be deployed on the block chain. Wherein the intelligent contract may include intelligent contract code for executing the query logic to obtain a credit assessment value for the target user. In practical application, the intelligent contract code for acquiring the credit evaluation value of the target user by executing the query logic can realize the acquisition of the credit evaluation value of the user, and whether the user is allowed to be admitted or not is determined based on the credit evaluation value obtained by the query. The credit evaluation value is a numerical value obtained by calculating a numerical value of the user characteristic in the intelligent contract, and the numerical value is used for representing the credit quality of the user; through the credit evaluation value, whether the user can be admitted or not can be determined, and the judgment on the user admission is safer and more accurate.

It should be noted that, for a specific process of creating and invoking an intelligent contract, reference may be made to the foregoing process of creating and invoking an intelligent contract, which is not described herein again.

In a specific implementation, the target user may initiate a transaction for invoking the intelligent contract deployed on the blockchain through the client that establishes a connection with the node device in the blockchain. When receiving the transaction, the node device in the blockchain may send the transaction to other node devices in the blockchain to perform consensus processing on the transaction, and after the transaction consensus passes, execute the intelligent contract code in the intelligent contract to implement admission operation on the target user.

In practical applications, the client may be deployed on an electronic device, where the electronic device may be a server, a computer, a mobile phone, a tablet device, a notebook computer, a Personal Digital assistant (pda), or the like; similarly, the electronic device added to the block chain as a node device may also be a server, a computer, a mobile phone, a tablet device, a notebook computer, a palm computer, or the like; this is not limited by the present description.

Referring to fig. 7, fig. 7 is a flowchart illustrating a block chain based user admission method according to an exemplary embodiment of the present disclosure.

In conjunction with the block chain-based user admission system shown in fig. 6, the block chain-based user admission method described above may be applied to the node device in the block chain shown in fig. 6; the block chain-based user admission method can comprise the following steps:

at step 702, an admission evaluation transaction for a target user is received.

Wherein the admission evaluation transaction is used to invoke the smart contract to obtain a value of the user characteristic associated with the target user.

Step 704, in response to the admission evaluation transaction, invoking the smart contract to query whether the historical credit evaluation value corresponding to the target user is already stored in a block of the block chain.

Step 706, determining whether the target user is allowed to be admitted based on the query result or the invoking intelligent contract.

In this embodiment, an intelligent contract may be deployed on the block chain, and the target user refers to a user who needs to query whether admission is available. In this embodiment, the node device in the blockchain may respond to the admission evaluation transaction for the target user, that is, the target user may initiate a transaction for invoking the intelligent contract deployed on the blockchain through the client that establishes a connection with the node device in the blockchain, that is, the admission evaluation transaction for the target user.

In step 702, the intelligent contract has a code for obtaining a numerical value of a feature associated with the target user from a block in the blockchain, and by running the code, the numerical value of the feature of the target user can be read in the intelligent contract. The values of the characteristics of the target user are pre-stored by the mechanism on the tiles of the blockchain.

As an example, in performing step 706, if the stored query result is queried, it may be further checked whether the values of the user characteristics associated with the target user match to determine whether the values of the user characteristics associated with the target user change, and if so, indicating no change, then determining whether the target user is allowed to admit based on the historical credit evaluation value. If the numerical value of the user characteristic associated with the target user is changed or the query result is not inquired, namely the historical credit evaluation value corresponding to the target user does not exist, calling an intelligent contract to determine the credit evaluation value, determining whether the target user is allowed to be admitted or not, and storing the determined credit evaluation value into the block of the block chain.

In one embodiment, the intelligent contract is provided with code for acquiring a historical credit evaluation value of a target user from a block of a block chain, and by running the code for acquiring the historical credit evaluation value of the target user, if the historical credit evaluation value of the target user exists in the block of the block chain, the historical credit evaluation value of the target user can be read in the intelligent contract; if the historical credit evaluation value of the target user does not exist in the blocks of the block chain, returning a result that the historical credit evaluation value of the target user does not exist. The code is the code corresponding to the query logic in the intelligent contract.

In one embodiment, code corresponding to the admission evaluation logic is also present on the intelligent contract. And the code corresponding to the admission evaluation logic performs admission evaluation according to a result returned after the code corresponding to the query logic operates. When the step returns a result that the historical credit evaluation value of the target user does not exist, the code corresponding to the admission evaluation logic operates the evaluation logic according to the numerical value of the user characteristic obtained in the step to obtain the credit evaluation value, and the credit evaluation value is stored in the block of the block chain; when the historical credit evaluation value of the target user is obtained through the steps, codes corresponding to the admission evaluation logic check whether the numerical value of the user characteristic is changed, if so, the evaluation logic is operated to obtain the credit evaluation value, and the credit evaluation value is stored in the block of the block chain; and if no change occurs, returning to the historical credit evaluation value obtained in the previous step.

When only the historical credit evaluation value is obtained, determining whether the target user is allowed to be admitted or not according to the historical credit evaluation value; when the admission evaluation logic is operated to obtain the credit evaluation value, whether the target user is allowed to be admitted or not is determined according to the credit evaluation value.

Specifically, referring to the foregoing process of persisting the evidence data in the blockchain, the client may construct an admission evaluation transaction for the target user, which is used to invoke the intelligent contract deployed on the blockchain, and issue a credit evaluation value generated by the admission evaluation transaction for the target user to the blockchain for evidence preservation. That is, the node device in the block chain that is docked with the client may receive the admission evaluation transaction for the target user first, and then send the admission evaluation transaction for the target user to the other node devices in the block chain. When each node device in the block chain receives the admission evaluation transaction of the target user, the node device can perform consensus processing on the admission evaluation transaction of the target user. After agreement is reached, node devices in the blockchain may package admission evaluation transactions for the target user into blocks in which persistent crediting of credit evaluation values is performed.

The admission evaluation transaction for the target user packaged in the block can be inquired, and the result of the admission evaluation transaction cannot be tampered, so that when the characteristics of the user do not accord with the admission conditions and the admission is not allowed, any person cannot tamper the result of the admission evaluation transaction unless the numerical value of the characteristics of the user is changed or an organization modifies the intelligent contract, and the safety and the reliability of the admission evaluation result are ensured.

In practical application, the target user initiates an admission evaluation transaction to the target user when applying for the service provided by the relevant mechanisms, wherein the relevant mechanisms comprise banks, financial companies, payment platforms and the like; services include financing, credit payment, first use and then payment, etc.; the target user can be a natural person or a legal person; the characteristics of the target user are authorized and legally obtained by the user and agreed by the user to be used for providing products or services for the user; and the use of the user's features does not exceed the user's authorized scope of use. The target user may be a user's own characteristics or may be a manually divided characteristic, the user's own characteristics include a user gender, an organization property, a user monthly income, a user liability rate, and the like, the manually divided characteristics include a purpose of the user applying for a service provided by an organization, a place where the user applies for the service, a user's network environment, and the like, and the description is not limited thereto.

The characteristic source is wide and can be information authorized to be used in the service using process of the user; or log data recorded in the process of using the service by the user is mined by a statistical method; the credit data may be provided by a third party, which is not limited in this specification, and any feature associated with the user credit may be the feature of the present application, and the value of the user feature is the value corresponding to the user feature.

Since some user characteristics are not important for determining whether to allow the user to be admitted, in some embodiments, an IV (Information Value) Value of a Value of the user characteristics stored in advance is not lower than a preset Value in order to save a storage space.

The mechanism may store the value of the user characteristic in a block of the block chain, and may not store the value of the characteristic having an IV value lower than a preset value on the block chain by calculating the IV value of the characteristic before storing the value of the user characteristic in the block.

The IV value may change due to a change in the probability of a breach of the user in the business process, for example, if a large-scale breach of the user with the same feature occurs, the IV value of the feature may change. In some embodiments, the developer may set events in advance that affect the IV value of the feature, such as:

complaint events arising from the lack of admission of an associated user by any of the historical user characteristics; because any historical user characteristic allows events such as default events generated after the related user is admitted, research and development personnel can synthesize one event or a combination of multiple events according to actual requirements to be used as the event influencing the IV value.

In the process that an organization approves the user to access the service in the past, the user is not allowed to access because any characteristic does not meet the access condition; the user may complain about this situation. Therefore, before the user characteristics are selected and the numerical values of the selected user characteristics are stored in the blockchain, the IV value of the characteristics generating the customer complaints can be calculated, and the numerical values of the characteristics of which the IV values are lower than the preset value are not stored in the blockchain.

The organization gives access to the network because any feature of the user meets the condition of the access, and the organization generates default behaviors after the access is given. Therefore, before selecting a feature and storing the value of the selected feature on the blockchain, an IV value of the feature generating the default behavior may be calculated, and the value of the feature having an IV value lower than a preset value is not stored on the blockchain.

The values of the characteristics may be stored in different ways, and in some embodiments, the values of the characteristics are stored in different blocks in order to facilitate management of the user data.

The above-mentioned block may be a block of a block chain of the UTXO model, or may be a block of a block chain of the account model. When the numerical value of the user characteristic is stored in the blocks of the block chain, the numerical values of different characteristics are stored in different blocks, and one block can only store the numerical value of one characteristic; when the numerical value of the user characteristic is updated, only the block corresponding to the characteristic is updated.

The organization usually has data of user credit condition, and generates a designated credit parameter according to the data of the user credit condition, wherein the parameter can be a specific number or credit rating; such as the pay for premium sesame credit score, and such as the standard pul credit rating of standard pul corporation. Taking a credit as an example, if the credit score of the user is lower than a threshold, the intelligent contract of the admission evaluation transaction is not called, and the user is not allowed to be admitted; if the user has a credit rating, assuming the highest rating is AAA followed by AA, and the lowest rating is A, if the user's credit rating is A, then the intelligent contract for admission evaluation transactions is not invoked and the user is not allowed to admit. Thus, in some embodiments, the step of evaluating a transaction in response to the admission may further comprise: if the value of the specified credit parameter of the target user is below a threshold, the initiator of the admission evaluation transaction is not allowed to invoke the smart contract. (doing a bedding first and then writing you will make it easier for a person to have a feeling of substitution)

When a target user initiates a request of an admission service, a node device in a block chain receives an admission evaluation transaction for the target user and calls an intelligent contract, a credit evaluation value needs to be determined according to corresponding admission evaluation logic in an intelligent contract code, and the admission evaluation logic can be realized in various ways.

Taking the credit evaluation value calculated by the weighting formula as An example, if the numerical value of the feature of the user is pi, the weight coefficient corresponding to the feature is Ai, and the credit evaluation value obtained finally is R, then R is p1 × a1+ p2 × a2+ … + pn × An. Here, it is only a simple example, and other weighting operation methods such as exponential weighting may be used in the actual operation, and it is sufficient that the credit evaluation value R can be adjusted by the weighting factor.

The weighting factor used for the user characteristic value may be adjusted empirically, or calculated statistically, or may be obtained using a machine learning model.

The weight coefficients may be stored in the intelligent contract for use when the code of the intelligent contract admission evaluation logic is invoked. Before the weight coefficients are written into the intelligent contract, the calculated values obtained by the machine learning model for supervised learning can be used as the weight coefficients by using supervised training on the machine learning model.

Data is used to train a machine learning model, which in some embodiments is a supervised training model labeled customer complaint data and/or asset loss data generated from the user features as samples.

The supervised learning of the machine learning model comprises the steps of taking user characteristics as samples, combining customer complaint data and asset loss data generated by the user characteristics into a group of labels, and enabling the machine learning model to find out the relation between the user characteristics and the combined labels through training; or, the user characteristics are used as a sample, the customer complaint data generated by the user characteristics are used as a group of labels, and the machine learning model can find out the relation between the user characteristics and the labels of the customer complaint data through training; the user characteristics are used as samples, asset loss data generated by the user characteristics are used as a group of labels, and the machine learning model can find out the relation between the user characteristics and the labels of the asset loss data through training; finally, since the machine learning model has already found the association between the user feature and the label, when data of only the user feature without the label is acquired, the label of the user feature can be judged.

The machine learning model may be various and in some embodiments, the machine learning model may be a scorecard model.

The scoring card model comprises the steps of data preprocessing, variable screening, variable binning, model training, scoring card generation and the like, wherein a supervised learning mode can be used for training during model training.

When supervised training is carried out on the scoring card model, combining customer complaint data and asset loss data generated by the user characteristics as a sample into a data set of a group of labels to be divided into a training set and a testing set; or, dividing a data set which takes the user characteristics as a sample and takes the customer complaint data generated by the user characteristics as a group of labels into a training set and a testing set; the data set with the user characteristics as a sample and the asset loss data generated by the user characteristics as a group of labels can be further divided into a training set and a testing set. Wherein, the training set is used for training a model to obtain model parameters; the test set is used to verify the fitting ability of the model, preventing over-or under-fitting. The scoring card model can be constructed in a supervised learning process by using logistic regression, Decision Tree and GBDT (Gradient Boosting Decision Tree) and the like.

Because a plurality of machine learning models can be trained when the data has various labels, in some embodiments, the calculation value is obtained by performing weighting operation on the output values of the two scoring card models; wherein the label of one scoring card model is the customer complaint data and the label of the other scoring card model is the asset loss data.

Dividing a data set which takes user characteristics as a sample and customer complaint data generated by the user characteristics as labels into a training set and a testing set, wherein the training set is used for training a model to obtain model parameters; the test set is used for testing the fitting capability of the model, preventing over-fitting or under-fitting and obtaining the output value of the first scoring card model; dividing a data set which takes the user characteristics as a sample and takes asset loss data generated by the user characteristics as a label into a training set and a testing set, wherein the training set is used for training a model to obtain model parameters; the test set is used for testing the fitting capability of the model, preventing over-fitting or under-fitting and obtaining the output value of the second scoring card model; and performing weighted operation on the output value of the first scoring card model and the output value of the second scoring card model to obtain a calculated value.

In order to save the time for training the model, multiple labels of data can be combined into one, only one machine learning model is trained, in some embodiments, user characteristics are used as samples, and customer complaint data and asset loss data generated by the user characteristics are combined into a data set of the same group of labels to be divided into a training set and a testing set, wherein the training set is used for training the model to obtain model parameters; the test set is used for testing the fitting capability of the model, preventing over-fitting or under-fitting, obtaining the output value of the scoring card model, and taking the output value as a calculation value.

To further explain the block chain based user admission method of the present application, the following is explained with reference to a specific embodiment.

In this embodiment, a block of a block chain stores a numerical value of a user characteristic in advance, and a node device of the block chain receives an admission evaluation transaction for a target user; the admission evaluation transaction is used for calling query logic corresponding to an intelligent contract code in an intelligent contract to acquire a numerical value of a user characteristic associated with a target user; responding to the admission evaluation transaction, calling query logic corresponding to an intelligent contract code in an intelligent contract, and querying whether a historical credit evaluation value corresponding to a target user is stored in a block of a block chain; if the value of the user characteristic associated with the target user is stored and is not changed, determining whether the target user is allowed to be admitted or not based on the historical credit evaluation value; and if the numerical value of the user characteristic which does not exist or is associated with the target user is changed, calling admission evaluation logic corresponding to the intelligent contract code to determine a credit evaluation value, determining whether the target user is allowed to be admitted or not, and storing the determined credit evaluation value into the block of the block chain.

The electronic device added to the block chain as the node device may be a server, a computer, a mobile phone, a tablet device, a notebook computer, a palm computer, or the like.

In this embodiment, an Information Value (IV) of the prestored numerical Value of the user characteristic is not lower than a preset Value. The mechanism may store the value of the user characteristic in a block of the block chain, and may not store the value of the characteristic having an IV value lower than a preset value on the block chain by calculating the IV value of the characteristic before storing the value of the user characteristic in the block.

Before the numerical values of the features are stored on the blockchain, calculating an IV value of the features generating the customer complaints, wherein the numerical values of the features with the IV values lower than a preset value are not stored on the blockchain; or, calculating the IV value of the characteristics defaulted by the user after the user is admitted because any characteristic meets the admission condition.

Taking the age of the user as an example, the user is denied admission because of being under 30 years old, and often makes a customer complaint about this situation; alternatively, when a user is allowed to enter the home by age 30, a default is often made. An IV value for the age of the user is calculated. The age of the users is grouped as in table 3 below:

identification	Age interval	Number of good users	Number of bad users
				L1	(n1,n2]	G1	B1
L2	(n2,n3]	G2	B2
				L3	(n3,n4]	G3	B3

TABLE 3

The users are divided into good users and bad users, and the good and bad users are determined according to the service types, for example, if the users are inquired whether the users can be admitted for developing the shared bicycle renting service, the bad users are the users who do not return the bicycle or pay money, otherwise, if the users normally use the bicycle, the users who have performed the obligation are the good users. If the identification of the i-th group of users is Li, the number of good users is Gi, the number of bad users is Bi, the number of all good users is Gt, and the number of all bad users is Bt, the I-th group of WOE (weight of evidence), WOE_iIs calculated by the formula WOE_iLn { (Bi/Bt)/(Gi/Gt) }, IV value IV of i-th group_iThe calculation formula of (2) is as follows:

the final IV value obtained is the IV of each group_iSum of

And for the numerical value of the characteristic with the user IV value smaller than the preset value, the numerical value is not stored on the block chain, and the numerical value of the characteristic with the IV value smaller than the preset value, which exists on the block chain, is not updated. For example, if the IV value of the user age is less than 0.02, the feature that the user age is invalid can be identified, the user age is not stored on the blockchain, and data on the user age already existing on the blockchain is not updated.

In this embodiment, the values of different user characteristics are stored in different blocks. Each block has a unique hash value corresponding to it, i.e. if the value of the user characteristic is modified, the unique hash value will also be changed, so as to make it traceable and not be tampered.

In this embodiment, if the value of the specified credit parameter of the target user is below a threshold, the initiator of the admission evaluation transaction is not allowed to invoke the intelligent contract. Taking credit as an example, if the credit score of the target user is below a threshold, such as 600, the initiator of the admission evaluation transaction is not allowed to invoke the smart contract and return a result that the user is not allowed to admit without performing blockchain related invocation and storage operations. The credit score can be a numerical value obtained by the user daily consumption behavior data through a data statistics method; the rating may replace the credit score of the present application as long as it is a value that characterizes the user's historical credit.

Next, in response to the admission evaluation transaction, the admission evaluation logic corresponding to the intelligent contract code is invoked to determine a credit evaluation value. And the intelligent contract performs weighting operation on the numerical values of different user characteristics by using different weight coefficients according to the inquired numerical value of the user characteristic associated with the target user to obtain the credit evaluation value.

The intelligent contracts in this embodiment are written in a solid language, and one contract includes state variables, functions, function modifiers, and the like.

Taking the credit evaluation value calculated by the weighting formula as An example, if the numerical value of the feature of the user is pi, the weight coefficient corresponding to the feature is Ai, and the credit evaluation value obtained finally is R, then R is p1 × a1+ p2 × a2+ … + pn × An. The intelligent contract stores weight coefficients corresponding to the features,

a function for calculating a credit evaluation value is present in the smart contract, receives the value of the feature, returns a credit evaluation value, and stores the credit evaluation value in a block of the block chain. The intelligent contract also has a comparison function, whether the characteristic value of the user is updated or not is compared, if not, the historical credit evaluation value is directly read from the block of the block chain and returned; if there is an update, the compare function calls a function that calculates a credit evaluation value. And when the weight coefficient corresponding to the feature needs to be modified, a new intelligent contract is created, and the original intelligent contract is not used any more. In this embodiment, the weight coefficient corresponding to the feature may also be stored in a block of the block chain, the hash address of the block where the weight coefficient is located may be stored in the smart contract, when the weight coefficient needs to be read, the weight coefficient of the corresponding block is read according to the hash address, and when the weight coefficient corresponding to the feature needs to be updated, a transaction is initiated to update the weight coefficient of the block.

In this embodiment, the weight coefficient may be a calculated value obtained by the machine learning model through supervised training. The machine learning model in this embodiment may be a scorecard model. And dividing a data set into a training set and a testing set by taking the user characteristics as samples and taking the customer complaint data and the asset loss data generated by the user characteristics as labels. Wherein the customer complaint data and the asset loss data are merged into the same set of tags. For example, the label of a set of data with customer complaints and asset losses is 1, the label of a set of data with customer complaints but no asset losses is 0.5, the label of a set of data with no customer complaints but asset losses is 0.5, and the label of a set of data with no customer complaints and no asset losses is 0, where the labels are merely exemplary and can be adjusted according to specific situations. The final data of the data set with three characteristics of monthly income, age of the user and number of family as samples is shown in the following table 4:

income per month	Age of the user	Number of family members	Label (R)
				5000	20	3	0
6000	21	4	0.5
				7000	22	5	1
…	…	…	…

TABLE 4

In this embodiment, 70% of the data sets are used as training sets, and 30% of the data sets are used as test sets, where the training sets are used to train models to obtain model parameters; the test set is used to verify the fitting ability of the model, preventing over-or under-fitting. The ratio of the training set to the test set may be adjusted as needed, for example, may be adjusted to 6: 4.

in this example, a score card model was constructed using logistic regression. And solving the cost function of the sigmoid function by a gradient descent method to obtain a parameter value of the sigmoid function, namely an output value of the scoring card model.

The parameters of the Sigmoid function may be as shown in table 5 below:

income per month	A1
		Age of the user	A2
Number of family members	A3

TABLE 5

Taking a user with a monthly income of 8000 yuan, an age of 40 years and 5 families as an example, according to the determined weight coefficient, calculating a credit evaluation designated function by an intelligent contract to calculate the credit evaluation value of the user to be 8000 xA 1+40 xA 2+5 xA 3, storing the credit evaluation value into a block of a block chain, ensuring that the credit evaluation value is traceable and not falsifiable, and realizing the safety and reliability of user admission;

returning the credit evaluation value to the node equipment, and if the credit evaluation value is smaller than a preset value, not allowing the user to access; if the credit evaluation value is greater than or equal to the preset value, the user is allowed to access, the judgment of the user access by the credit evaluation value calculated by the method is more accurate, the complaint rate of the user is reduced, and the access probability of the user is improved.

Corresponding to the above user admission method, the present specification further provides a block chain-based user admission apparatus, and as shown in fig. 8, it is a block diagram of the block chain-based user admission apparatus shown in the present specification, and this block chain-based user admission apparatus 80 may be applied to an electronic device shown in fig. 9, where the electronic device may be used as a node device in the block chain. The apparatus 80 is applied to node devices in the block chain; an intelligent contract used for carrying out admission evaluation on a user is deployed in the block chain, and numerical values of user characteristics are stored in blocks of the block chain in advance; the apparatus 80 comprises:

a receiving module 801, configured to receive an admission evaluation transaction for a target user; wherein the admission evaluation transaction is to invoke the smart contract to obtain a value of the user characteristic associated with the target user;

a query module 802, configured to, in response to the admission evaluation transaction, invoke the smart contract to query whether a historical credit evaluation value corresponding to the target user is already stored in a block of a blockchain; determining whether the target user is allowed admission based on the query result or the invoked intelligent contract.

In some embodiments, the step of query module 802 invoking intelligent contract code to determine the credit evaluation value comprises:

and according to the inquired numerical value of the user characteristic associated with the target user, carrying out weighting operation on the numerical values of different user characteristics by using different weight coefficients to obtain the credit evaluation value.

In some embodiments, the IV value of the pre-stored numerical value of the user characteristic is not lower than a preset value.

In some embodiments, the event affecting the IV value of the numerical value of the user characteristic comprises at least any one of: complaint events arising from the lack of admission of an associated user by any of the historical user characteristics; default events resulting from the admission of an associated user by any of the historical user characteristics.

In some embodiments, values for different user characteristics are stored in different blocks.

In some embodiments, the step of the receiving module 801 responding to the admission evaluation transaction comprises: if the value of the specified credit parameter of the target user is below a threshold, the initiator of the admission evaluation transaction is not allowed to invoke the smart contract.

In some embodiments, the numerical values of the user features are weighted using a weighting factor comprising a calculated value derived using a machine learning model.

In some embodiments, the machine learning model is a supervised learning model that is modeled as a sample of the user features and labeled with customer complaint data and/or asset loss data resulting from the user features.

In some embodiments, the machine learning model comprises a scoring card model.

In some embodiments, the calculation value is obtained by weighting the output values of the two scoring card models; wherein the label of one scoring card model is the customer complaint data and the label of the other scoring card model is the asset loss data.

The implementation process of the functions and actions of each module in the above device is specifically described in the implementation process of the corresponding step in the above method, and is not described herein again.

For the device embodiment, since it basically corresponds to the method embodiment, reference may be made to the partial description of the method embodiment for relevant points. The above-described embodiments of the apparatus are merely illustrative, wherein the modules described as separate parts may or may not be physically separate, and the parts displayed as modules may or may not be physical modules, may be located in one place, or may be distributed on a plurality of network modules. Some or all of the modules can be selected according to actual needs to achieve the purpose of the solution in the specification. One of ordinary skill in the art can understand and implement it without inventive effort.

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 embodiments, 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 user access method based on a block chain is applied to node equipment in the block chain, an intelligent contract used for access evaluation of a user is deployed in the block chain, and numerical values of user characteristics are stored in blocks of the block chain in advance; the method comprises the following steps:

in response to the admission evaluation transaction, calling the intelligent contract to inquire whether a historical credit evaluation value corresponding to the target user is stored in a block of a block chain;

2. The method of claim 1, the step of determining whether the target user is allowed to admit based on a query result or a call intelligence contract comprising:

if the query result is matched with the numerical value of the user characteristic associated with the target user, determining whether the target user is allowed to be admitted or not based on the historical credit evaluation value;

if the query result is not queried or the query result is not matched with the numerical value of the user characteristic associated with the target user, calling an intelligent contract to determine a credit evaluation value, determining whether the target user is allowed to be admitted or not, and storing the determined credit evaluation value into the block of the block chain.

3. The method of claim 2, wherein invoking the smart contract to determine the credit evaluation value comprises:

4. The method of claim 1, wherein the IV value of the pre-stored numerical value of the user characteristic is not lower than a preset value.

5. The method of claim 4, the event affecting the IV value of the numerical value of the user characteristic comprising at least any one of:

complaint events arising from the lack of admission of an associated user by any of the historical user characteristics;

default events resulting from the admission of an associated user by any of the historical user characteristics.

6. The method of claim 1, wherein values of different user characteristics are stored in different blocks.

7. The method of claim 1, the step of evaluating a transaction in response to the admission further comprising: if the value of the specified credit parameter of the target user is below a threshold, the initiator of the admission evaluation transaction is not allowed to invoke the smart contract.

8. The method of claim 3, wherein the numerical values of the user features are weighted using a weighting factor comprising a calculated value derived using a machine learning model.

9. The method of claim 8, machine learning model is a supervised learning model that is sampled with the user features and labeled with customer complaint data and/or asset loss data resulting from the user features.

10. The method of claim 9, the machine learning model comprising a scoring card model.

11. The method of claim 10, the calculated value comprising an output value of the scoring card model;

or, the evaluation data is obtained by performing weighted operation on output values of the two scoring card models, wherein the label of one scoring card model is the customer complaint data, and the label of the other scoring card model is the asset loss data.

12. A block chain-based user admission device is applied to node equipment in a block chain; an intelligent contract used for carrying out admission evaluation on a user is deployed in the block chain, and numerical values of user characteristics are stored in blocks of the block chain in advance; the device comprises:

the receiving module is used for receiving the admission evaluation transaction of the target user; wherein the admission evaluation transaction is to invoke the smart contract to obtain a value of the user characteristic associated with the target user;

the query module is used for responding to the admission evaluation transaction, calling the intelligent contract to query whether the historical credit evaluation value corresponding to the target user is stored in a block of a block chain; determining whether the target user is allowed admission based on the query result or the invoked intelligent contract.

13. 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-11 by executing the executable instructions.

14. A computer readable storage medium having stored thereon computer instructions which, when executed by a processor, carry out the steps of the method according to any one of claims 1 to 11.