CN114444097A - Blockchain-based user access method, device, electronic device and storage medium - Google Patents

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

Blockchain-based user access method, device, electronic device and storage medium

technical field

One or more embodiments of this specification relate to the field of blockchain technology, and in particular, to a blockchain-based user access method, apparatus, electronic device, and storage medium.

Background technique

The institution needs to provide users with credit services, so it will check the value of the user's characteristics. When the value of the user's characteristics meets the preset conditions, the user is allowed to enter, and the admitted user can obtain the services provided by the institution. In the existing related art, the strategy used to check the value of the user's feature is a "circuit breaker" strategy, that is, if the value of a certain feature of the user does not meet the preset conditions, the user is not allowed to enter; Judgment of user credit is not important. If the user is denied access only because of unimportant features, the user will complain; at the same time, the existing related technology is run on a specific server. Once the server is maliciously controlled or malfunctions , the judgment of user access will be inaccurate.

SUMMARY OF THE INVENTION

In view of this, the present application provides a blockchain-based user access method, device, and electronic device.

According to a first aspect of the present application, a blockchain-based user access method is applied to node devices in the blockchain; a smart contract for evaluating user access is deployed in the blockchain , the values of user characteristics are pre-stored in the blocks of the blockchain; the method includes the steps:

Receive an access evaluation transaction for the target user; wherein, the access evaluation transaction is used to call the smart contract to obtain the value of the user characteristic associated with the target user;

In response to the admission evaluation transaction, invoking the smart contract to query whether the historical credit evaluation value corresponding to the target user has been stored in the block of the blockchain;

Whether the target user is allowed to enter is determined based on the query result or invoking the smart contract.

According to a second aspect of the present application, a blockchain-based user admission device is provided, the device is applied to node devices in the blockchain; The smart contract entered into the evaluation, the value of the user characteristic is pre-stored in the block of the blockchain; the device includes:

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

The query module is used for invoking the smart contract to query whether the historical credit evaluation value corresponding to the target user has been stored in the block of the blockchain in response to the admission evaluation transaction; based on the query result or calling the smart contract It is determined whether the target user is allowed to admit.

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

memory for storing processor-executable instructions;

Wherein, the processor implements the method described in the first aspect of the present application by running the executable instructions.

According to a fourth aspect of the present application, a computer-readable storage medium is provided, and the readable storage medium has computer instructions, and when the instructions are executed by a processor, implement the steps of the method described in the first aspect of the present application.

In the above technical solution, since the query logic corresponding to the smart contract code in the smart contract is invoked, it is determined whether the target user is allowed access based on the query result or the smart contract is invoked, so as to realize a more accurate judgment on user access and reduce The user complaint rate increases the user's access probability. And the determined credit evaluation value is stored in the block of the blockchain to ensure that the access credit evaluation value can be traced back and cannot be tampered with, so as to realize the safety and reliability of user access.

Description of drawings

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

2 is a schematic diagram of organizing contract data stored in a storage space corresponding to a contract account into an MPT storage tree provided by an exemplary embodiment;

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

4 is a flowchart of a blockchain-based smart contract management method provided by an exemplary embodiment;

5 is a flowchart of another blockchain-based smart contract management method provided by an exemplary embodiment;

6 is a schematic diagram of the use of a blockchain-based user access system provided by an exemplary embodiment;

7 is a flowchart of a blockchain-based user access method provided by an exemplary embodiment;

8 is a block diagram of an apparatus for a blockchain-based user access method provided by an exemplary embodiment;

FIG. 9 is a hardware structure diagram of an electronic device provided by an exemplary embodiment.

Detailed ways

Exemplary embodiments will be described in detail herein, examples of which are illustrated in the accompanying drawings. Where the following description refers to the drawings, the same numerals in different drawings refer to the same or similar elements unless otherwise indicated. The implementations described in the exemplary embodiments below are not intended to represent all implementations consistent with one or more embodiments of this specification. Rather, they are merely examples of apparatus and methods consistent with some aspects of one or more embodiments of this specification, as recited in the appended claims.

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

A blockchain is usually composed of several blocks. Timestamps corresponding to the creation time of the blocks are respectively recorded in these blocks, and all blocks form a time-ordered data chain strictly according to the timestamps recorded in the blocks.

For the data generated outside the chain, it can be constructed into a standard transaction format supported by the blockchain, and then published to the blockchain. After the consensus, the node device in the blockchain as the accounting node will package the transaction into the block and store the certificate persistently in the blockchain.

The current blockchain system usually includes two mainstream transaction models; one is the UTXO (UnspentTransaction Output, unspent transaction output) model; the other is the account model.

Among them, if the above two types of blockchains want to realize the data storage certificate, the following storage methods can usually be adopted:

For blockchains using the UTXO model, the supported native transactions usually only include transfer transactions. In the process of transferring funds based on transfer transactions, users can fill in additional transactions in the transaction postscript (ie, transfer postscript) in the transfer transaction. to store the additional data on the blockchain.

For the blockchain that adopts the account model, the blockchain data that needs to be stored and maintained usually includes the block data and the account status data corresponding to the blockchain account in the blockchain; and the block data can further include the block header. data, block transaction data in blocks, and transaction receipts corresponding to block transaction data in blocks, etc. When storing the various blockchain data shown above, the various blockchain data described above can usually be organized into a Merkle tree in the form of key-value pairs and stored in the database.

In this type of blockchain model, a smart contract for data storage can be deployed on the blockchain, and users can call the smart contract to use the data that needs to be stored as the contract account corresponding to the smart contract. Account status, stored in the Merkle tree corresponding to the smart 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; among them, the account status data can be organized into MPT status The tree (commonly known as the world state) is stored in the database; the MPT state tree stores the key-value pair with the account address as the key and the account state data as the value. The data content stored in the contract account corresponding to the smart contract will also be further organized into a storage tree (an MPT storage tree for storing data) and stored in the database; the hash value of the root node of the storage tree will be used as a Part of the account state data corresponding to the contract account is filled into the MPT state tree; and the hash of the root node of the MPT state tree will be used as the authentication root and further filled into the block header. When the user needs to store the data, the data that needs to be stored can be stored in the storage tree corresponding to the smart contract as the account status data of the contract account corresponding to the smart contract by invoking the smart contract.

In the field of blockchain, an important concept is Account; the blockchain network of the account model usually divides accounts into two types: external accounts and contract accounts; external accounts are accounts directly controlled by users, also known as It is a user account; while a contract account is an account (ie, a smart contract) that is created by the user through an external account and contains the contract code.

For an account in the blockchain, a structure is usually used to maintain the account state of the account. When a transaction in a block is executed, the state of the account associated with that transaction in the blockchain usually changes as well.

In one example, the structure of the account usually includes fields such as Balance, Nonce, Code and Storage. in:

The Balance field is used to maintain the current account balance of the account;

The Nonce field is used to maintain the number of transactions of the account; it is a counter used to ensure that each transaction can be processed only once, effectively avoiding replay attacks;

The Code field is used to maintain the contract code of the account; in practical applications, the Code field usually only maintains the hash value of the contract code; therefore, the Code field is usually also called the Codehash field.

The Storage field is used to maintain the storage content of the account; for a contract account, an independent storage space is usually allocated to store the storage content of the contract account; the independent storage space is usually referred to as the contract account's storage space. Account storage.

The storage content of the contract account is usually constructed into a data structure of an MPT (Merkle Patricia Trie) tree in the form of key-value key-value pairs and stored in the above-mentioned independent storage space. MPT tree is a logical tree structure used to store and maintain blockchain data in the blockchain field. This tree structure usually includes root nodes, intermediate nodes, and leaf nodes.

It should be noted that the so-called logical tree structure means that in the underlying physical storage of the database, there is no physical storage structure completely corresponding to the tree structure, but only each node on the above tree structure is stored in the database. The physical data and the link relationship data between each node, so that the above tree structure can be restored at the logical level based on the physical data and link relationship data of each node stored in the database.

Among them, the MPT tree constructed based on the storage content of the contract account is also commonly referred to as the Storage tree. The Storage field usually only maintains the root node of the Storage tree; therefore, the Storage field is usually also called the StorageRoot field. For an external account, the field values of the Code field and Storage field shown above are all null values.

For the node device of the blockchain, the blockchain data that needs to be stored and maintained usually includes the block data and the account status data corresponding to the blockchain account in the blockchain; and the block data can further include the block data. Block header data, block transaction data in the block, and transaction receipts corresponding to the block transaction data in the block, etc.

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

When the node device of the blockchain stores the various blockchain data shown above, it can usually organize the above various blockchain data in the form of key-value key-value pairs into the above-mentioned logical tree structure. , stored in the database. When it is necessary to query the above-mentioned various blockchain data stored in the node device, the data can be efficiently queried by traversing the above-mentioned Merkle tree by using the key of the above-mentioned various blockchain data as a query index.

For example, the MPT (Merkle Patricia Trie) tree is a Merkle tree variant that combines the tree structure of the Trie dictionary tree for storing and maintaining blockchain data.

The following is an example of using MPT tree to organize and store blockchain data;

Among them, it should be emphasized that the use of MPT tree to organize and store blockchain data is only exemplary. In practical applications, in addition to an improved Merkle tree such as an MPT tree, other forms of Merkle tree variants incorporating the Trie dictionary tree can also be used, which will not be listed one by one in this specification.

In one example, the blockchain data that needs to be stored and maintained in the blockchain usually includes account state data, transaction data, and receipt data; therefore, in practical applications, the above account state data, transaction data, and transaction data can be stored and maintained, respectively. The data and receipt data are formed into three MPT trees in the form of key-value pairs, namely the MPT state tree (ie world state), the MPT transaction tree and the MPT receipt tree, which are stored and maintained respectively.

Among them, 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 the Storage tree). The hash value of the root node of the Storage tree will be added to the Storage field in the above structure of the contract account corresponding to the Storage tree.

The MPT state tree is an MPT tree organized by the account state data of all accounts (including external accounts and contract accounts) in the blockchain in the form of key-value pairs; the MPT transaction tree is composed of The transaction data in the block chain is an MPT tree organized in the form of key-value key-value pairs; the MPT receipt tree is the transaction corresponding to each transaction generated after the transaction in the block is executed. ) receipt, an MPT tree organized in the form of key-value pairs.

The hash values of the root nodes of the MPT state tree, MPT transaction tree, and MPT receipt tree shown above will eventually be added to the block header of the corresponding block.

Among them, both the MPT transaction tree and the MPT receipt tree correspond to blocks, that is, each block has its own MPT transaction tree and MPT receipt tree. The MPT state tree is a global MPT tree, which does not correspond to a specific block, but covers the account state data of all accounts in the blockchain.

Each time the blockchain generates a newest block, after the transactions in the latest block are executed, the account status of the relevant accounts (which can be external accounts or contract accounts) of the executed transactions in the blockchain, usually will also change accordingly;

For example, when a "transfer transaction" in the block is executed, the balances of the sender's account and the transferer's account related to the "transfer transaction" (that is, the field value of the Balance field of these accounts) are usually also will change accordingly. After the node device executes the transaction in the latest block generated by the blockchain, since the account status in the current blockchain has changed, the node device needs to construct the current account status data based on the current account status data of all accounts in the blockchain. The MPT state tree is used to maintain the latest state of all accounts in the blockchain.

That is, whenever a newest block is generated in the blockchain and the transaction in the latest block is executed, the account status of some accounts in the blockchain changes, and the node device needs to be based on the The latest account status data of all accounts, and rebuild an MPT status tree. In other words, each block in the blockchain has a corresponding MPT state tree; the MPT state tree maintains that after the transaction in the block is executed, all accounts in the blockchain are up-to-date. account status.

Please refer to FIG. 1. FIG. 1 is a schematic diagram of organizing the account status data of each blockchain account in the blockchain into an MPT state tree shown in this specification.

MPT tree is a more traditional and improved variant of Merkle tree, which combines the advantages of two tree structures of Merkle tree and Trie dictionary tree (also called prefix tree).

An MPT tree usually includes three kinds of nodes, namely, a leaf node (leaf node), an extension node (extension node) and a branch node (branch node).

Among them, the extension node and the branch node can be collectively referred to as character nodes, which are used to store the character prefix part of the character string corresponding to the key of the blockchain data; wherein, for the MPT tree, the above character prefix part usually refers to the shared character prefix; The shared character prefix refers to a prefix composed of the same one or more characters that all blockchain account addresses have. The above leaf nodes are used to store the character suffix part and Value (that is, the specific data content) of the string corresponding to the key of the blockchain data.

Extended node, represented as a key-value pair of [key, value], where key is a special hexadecimal coded character, representing the shared character prefix of the account address; value is the hash value (hash pointer) of other nodes, also That is to say, you can link to other nodes through the hash pointer.

Branch node, including 17 elements, the first 16 elements correspond to the 16 possible hexadecimal characters in the key, and one character corresponds to a nibble (nibble), which respectively represent the shared character prefix of an account address (length is one character). Among them, if there is a [key, value] pair terminated at this 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 can be Null value.

A leaf node is a key-value pair expressed as [key, value], where key is also a special hexadecimal coded character, representing the character suffix of the account address; among them, the character suffix of the account address and the shared character of the account address The prefix together forms a complete account address; the character suffix refers to the suffix consisting of the last one or more characters except the shared character prefix of the account address; value is the status data of the account address corresponding to the leaf node (ie structure shown above).

Because on the MPT tree, the characters on the search path from the root node to a leaf node form a complete account address; therefore, for the branch node, it can be either the termination node of the above search path, or the above Intermediate nodes of the search path.

Assume that the account state data that needs to be organized into an MTP state tree is shown in Table 1 below:

Table 1

Among them, it should be noted that in Table 1, the blockchain account corresponding to the account address in the first three lines is an external account, and the fields of Codehash and Storage root are empty. The blockchain account corresponding to the account address in line 4 is the contract account. The Codehash field maintains the hash value of the contract code corresponding to the contract account; the Storage root field maintains the root node of the Storage tree composed of the storage content of the contract account. hash value.

Finally, the MPT state tree is organized according to the account state data in Table 1, as shown in Figure 1; the MPT state tree consists of 4 leaf nodes, 2 branch nodes, and 2 extension nodes (one of which is the extension node as the root). node) composition.

In FIG. 1 , the prefix field is a prefix field shared by the extension node and the leaf node. Different field values of the prefix field can be used to represent different node types.

For example, the value of the prefix field is 0, indicating an extension node containing an even number of nibbles; as mentioned above, a nibble represents a nibble, which is composed of 4-bit binary, and a nibble can correspond to a character that constitutes an account address. The value of the prefix field is 1, which means that the extension node contains an odd number of nibble(s); the value of the prefix field is 2, which means that the leaf node contains an even number of nibbles; the value of the prefix field is 3, which means that it contains an odd number of nibbles. (s) leaf nodes.

The branch node, because it is a parallel single nibble character node, does not have the above prefix field.

The Shared nibble field in the extension node corresponds to the key value of the key-value pair contained in the extension node, indicating the common character prefix between account addresses; for example, all account addresses in the above table have a common character prefix a7. The Next Node field is filled with the hash value (hash pointer) of the next node.

The hexadecimal character 0～f field 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 on the search path of the account address in the MPT tree, the branch node The Value field can be null. The hash value used to fill the next layer of nodes in the 0~f field.

The Key-end in the leaf node corresponds to the key value of the key-value pair contained in the leaf node, and represents the last few characters of the account address (the character suffix of the account address). The key value of each node on the search path from the root node to the leaf node constitutes a complete account address. The Value field of the leaf node is filled with the account status data corresponding to the account address; for example, the structure composed of the fields such as Balance, Nonce, Code, and storage can be encoded, and then filled into the Value field of the leaf node.

Further, the nodes on the MPT state tree shown in Figure 1 are ultimately stored in the database in the form of Key-Value key-value pairs;

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

When the node on the MPT state tree is stored in the database, the hash value of the data content contained in the node can be calculated (that is, the hash calculation is performed on the entire node), and the calculated hash value can be used as the key. The content of the data is used as value, and a Key-Value key-value pair is generated; then, the generated Key-Value key-value pair is stored in the database.

Because the nodes on the MPT state tree are stored in the form of key-value pairs; among them, the key can be the hash value of the data content contained in the node, and the value can be the data content contained in the node; therefore, when you need to query When a node on the MPT state tree is used, content addressing can usually be performed based on the hash value of the data content contained in the node as a key.

Please refer to FIG. 2, which is a schematic diagram of organizing contract data stored in a storage space corresponding to a contract account into an MPT storage tree shown in this specification.

Please continue to refer to Table 1. The account whose account address is "a77d397" shown in Table 1 is a contract account, so the contract data stored in the storage space corresponding to the contract account will be organized into a storage tree; among them, the storage tree The hash value S1 of the root node will be added to the storage root field in the leaf node corresponding to the contract account in the MTP state tree shown in Figure 1.

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

Table 2

It should be noted that the contract data stored in the storage space of the contract account can usually be in the form of state variables; when storing, the hash value of the state variable name can be used as the key, and the value of the variable corresponding to the state variable name can be used as the key. The value is organized into a storage tree as shown in Figure 2 in the form of key-value key-value pairs 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 will not be repeated in this specification.

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

In practical applications, the character length of the shared character prefix of the keys of all data stored in the MPT tree is usually not fixed; moreover, when the newly added data is written to the MPT tree, the characters of the above shared character prefix may be caused The length will also change accordingly; therefore, this may cause the expansion node on the MPT tree to split and split into new branch nodes; that is, the split condition of the nodes on the MPT tree is that the above-mentioned shared character prefix character length changes;

For example, taking the MPT state tree shown in FIG. 1 as an example, assuming that an account state data of an account address whose first two characters of the account address are “a8” is added to the MPT state tree, then the MPT state tree shown in FIG. 1 The shared character prefix stored in the "Shared nible" field of the extension node of the root node will be changed from "a7" to "a"; according to the splitting conditions of the nodes of the MPT state tree, this extension node as the root node will be Split into an extension node where the shared character prefix "a" is stored; and a branch node where the character "8" is occupied.

In a programmable blockchain, users can create and invoke some complex logic in the blockchain network by providing users with smart contracts. The so-called smart contract is a program on the blockchain that can be triggered and executed by a transaction.

In the programmable blockchain, each node device can be equipped with a Turing-complete virtual machine as the execution environment of smart contracts, through which various complex logics can be realized.

Users publish and invoke smart contracts in the blockchain that run on virtual machines. In fact, the virtual machine directly runs the virtual machine code (virtual machine bytecode, hereinafter referred to as "bytecode"), so the smart contract deployed on the blockchain can be bytecode.

As shown in Figure 3, after Bob can send a smart contract creation transaction containing the contract code to the blockchain network, each node device can execute the transaction in the onboard virtual machine.

Among them, the From field of the transaction in Figure 3 is used to record the address of the account that initiated the creation of the smart contract, the contract code stored in the field value of the Data field of the transaction can be the above bytecode, and the field value of the To field of the transaction is a null (empty) account. When the nodes reach an agreement through the consensus mechanism, the smart contract is successfully created, and subsequent users can call the smart contract.

After the smart contract is created, a contract account corresponding to the smart contract appears on the blockchain and has a specific address; for example, "0x68e12cf284..." in each node in Figure 3 represents the address of the created contract account ; The contract code (Code) and account storage (Storage) will be saved in the account storage of the contract account. The behavior of the smart contract is controlled by the contract code, and the account storage of the smart contract saves the state of the contract.

As mentioned above, the Data field containing the transaction that creates the smart contract can store the bytecode of the smart contract. Bytecode consists of a sequence of bytes, each of which can identify an operation. Based on development efficiency, readability and other considerations, developers can choose a high-level language to write smart contract code instead of writing bytecode directly. For example, high-level languages such as Solidity, Serpent, LLL, etc. may be used. For smart contract code written in a high-level language, it can be compiled by a compiler to generate bytecode that can be deployed on the blockchain.

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

As shown in Figure 4, still taking the blockchain network of the account model as an example, after Bob sends a smart contract invocation transaction to the blockchain network of the account model, each node device can execute this function in the onboard virtual machine. transaction.

Among them, the From field of the transaction in Figure 4 is used to record the address of the account that initiates the call to the smart contract, the To field is used to record the address of the called smart contract, and the Data field of the transaction is used to record the method and parameters of calling the smart contract. After calling the smart contract, the account status of the contract account may change. Subsequently, a client can view the account status of the contract account through the connected blockchain node (for example, node 1 in Figure 4).

Smart contracts can be executed independently on each node in the blockchain network in a prescribed manner, and all execution records and data are stored on the blockchain. Tampered, never lost transaction credentials.

A schematic diagram of creating a smart contract and calling a smart contract is shown in Figure 5. To create a smart contract in the blockchain network of the account model, it needs to go through the process of writing the smart contract, converting it into bytecode, and deploying it to the blockchain. Invoking a smart contract in the blockchain network of the account model is to initiate a transaction pointing to the address of the smart contract. The EVM of each node can execute the transaction separately and run the smart contract code in a distributed manner in the blockchain network of the account model. in the virtual machine of each node.

In a programmable blockchain, it is usually possible to support the transformation of non-monetary physical assets in the real world into digital assets on the blockchain. Converting the above-mentioned physical assets into the above-mentioned digital assets usually refers to "anchoring" the physical assets with the digital assets on the blockchain, as the value support of these virtual assets, and then generating the physical assets on the blockchain. The process of digital assets that match the value of and can be circulated between blockchain accounts on the blockchain.

During implementation, the account types supported by the blockchain can be extended, and on the basis of the account types supported by the blockchain, an asset account (also called an asset object) can be expanded; On the basis of the external account and contract account supported by the chain, an asset account is extended; the extended asset account can be used as a medium for holding digital assets anchored to the value of non-monetary physical assets in the real world .

For users who access the blockchain, in addition to completing the creation of user accounts and smart contracts on the blockchain, they can also create a value match with the real-world non-monetary physical asset value on the blockchain. The digital assets are circulated on the blockchain;

For example, users can convert non-monetary physical assets such as real estate, stocks, loan contracts, bills, accounts receivable, etc. they hold into digital assets with matching value to circulate on the blockchain.

Among them, for the above asset account, the account status of the account can also be maintained through a structure. The content contained in the structure of the above asset account can be the same as the structure described above, and of course can also be designed based on actual needs;

In an implementation manner, the structure of the asset account may also include fields such as Balance, Nonce, Code, and Storage described above.

It should be noted that the Balance field is usually used to maintain the current account balance of the account; for the above-mentioned asset accounts, due to the anchored entity assets, they may usually be non-balance assets that cannot be counted based on the balance. The meaning of the Balance field is expanded, and it no longer represents the "balance" of the account, but is used to maintain the address information of the asset. Among them, in practical applications, the address information corresponding to multiple "digital assets" can be maintained in the Balance field.

In this case, the external account, contract account and asset account shown above can all hold this digital asset by adding the address information of the "digital asset" to be held in the Balance field. That is, in addition to external accounts and contract accounts, the asset account itself can also hold digital assets.

For the asset account, the field value of the Nonce and Code fields can be null (or not); the field value of the Storage field can no longer be null; the Storage field can be used to maintain the corresponding asset account. The asset status of the "virtual asset". 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 will not be described again.

Smart contracts deployed on the blockchain can usually only access the data content stored on the blockchain; however, in practical applications, for some complex business scenarios based on smart contract technology, smart contracts may also need to access off-chain data. External data stored on a data entity.

In this scenario, smart contracts deployed on the blockchain can access data on data entities outside the chain through Oracle oracles, thereby realizing data interaction between smart contracts and real-world data entities. The data entities outside the chain may include, for example, centralized servers or data centers deployed outside the chain, and so on.

When the institution needs to provide users with credit services, it will check the value of the user's characteristics. When the value of the user's characteristics meets the preset conditions, the user is allowed to enter, and the admitted user can obtain the service provided by the institution. Taking a user applying for a housing loan before buying a house as an example, the user characteristic to be checked can be the housing provident fund paid by the user, and the value of the user characteristic can be the number of years of housing provident fund payment or the balance of the provident fund. In the existing related art, the strategy adopted for checking the value of the user feature is a "circuit breaker" strategy, that is, if the value of a certain feature of the user does not meet the preset conditions, the user is not allowed to enter; If the housing provident fund has been completed for three years, it is not allowed to obtain a housing provident fund loan.

Since some user characteristics are not important to the user's credit evaluation, if the user is denied access only because of unimportant characteristics, the user will complain; at the same time, the existing related technologies check the value of the user's characteristics. The relevant code runs on a specific server On the other hand, once the server is maliciously controlled or malfunctions, the judgment of user access will be inaccurate.

In view of the use of blockchain technology, the data stored on the blockchain can be traced and cannot be tampered with, and the blockchain uses distributed computing, allowing the blockchain to run on multiple device nodes, which can ensure that it runs in the region. Security and reliability of smart contract code on the blockchain. Therefore, the present application provides a blockchain-based user access method.

Please refer to FIG. 6 , which is a schematic diagram of a blockchain-based user admission system according to an exemplary embodiment of this specification.

In the blockchain-based user admission system shown in Figure 6, smart contracts can be deployed on the blockchain. Wherein, the smart contract may include smart contract code for executing query logic to obtain the credit evaluation value of the target user. In practical applications, by executing the query logic to obtain the smart contract code of the target user's credit evaluation value, the user's credit evaluation value can be obtained, and based on the credit evaluation value obtained by the query, it is determined whether the user is allowed to enter. The credit evaluation value refers to a value obtained by calculating the value of the user's characteristics in the smart contract, and this value is used to represent the user's credit; The judgment of user access is more secure and accurate.

It should be noted that the specific process of creating and invoking a smart contract can refer to the above-mentioned process of creating and invoking a smart contract, which will not be repeated in this manual.

During specific implementation, the target user can initiate a transaction for invoking the above-mentioned smart contract deployed on the above-mentioned blockchain through a client that establishes a connection with a node device in the above-mentioned blockchain. When the node device in the blockchain receives the transaction, it can send the transaction to other node devices in the blockchain to perform consensus processing on the transaction, and after the transaction consensus is passed, execute the intelligent The smart contract code in the contract realizes the access operation to the target user.

In practical applications, the above client can be deployed on an electronic device, which can be a server, a computer, a mobile phone, a tablet device, a notebook computer, a PDA (Personal Digital Assistants), etc.; similarly, it is added as a node device The electronic devices connected to the above-mentioned blockchain can also be servers, computers, mobile phones, tablet devices, notebook computers, handheld computers, etc.; this specification does not limit this.

Please refer to FIG. 7. FIG. 7 is a flowchart of a blockchain-based user access method according to an exemplary embodiment of this specification.

Combined with the blockchain-based user access system shown in Figure 6, the above-mentioned blockchain-based user access method can be applied to the node devices in the blockchain as shown in Figure 6; The user admission method may include the following steps:

Step 702: Receive an access evaluation transaction for the target user.

Wherein, the admission evaluation transaction is used for invoking the smart contract to obtain the 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 has been stored in the block of the blockchain.

Step 706, based on the query result or calling the smart contract, determine whether the target user is allowed to enter.

In this embodiment, a smart contract can be deployed on the above-mentioned blockchain, and the target user refers to a user who needs to check whether access is possible. In this embodiment, the node device in the blockchain can respond to the admission evaluation transaction for the target user, that is, the target user can initiate a connection with the node device in the blockchain through the client The transaction that invokes the smart contract deployed on the blockchain is an admission evaluation transaction for the target user.

In step 702, there is a code on the smart contract to obtain the value of the feature associated with the target user from the block on the blockchain. By running the above code, the value of the feature of the target user can be read in the smart contract. The value of the characteristics of the target user is pre-stored on the block of the blockchain by the institution.

As an example, when step 706 is executed, if the stored query result is queried, it may be further checked whether the value of the user feature associated with the target user matches, to determine whether the value of the user feature associated with the target user has changed, if it matches , it means that there is no change, and based on the historical credit evaluation value, it is determined whether the target user is allowed to enter. If the value of the user feature associated with the target user changes, or the query result is not found, that is, the historical credit evaluation value corresponding to the target user does not exist, the smart contract is invoked to determine the credit evaluation value, and whether the target user is Admission is allowed and the determined credit assessment value is stored in the block of the blockchain.

In one embodiment, there is a code on the smart contract to obtain the historical credit evaluation value of the target user from the block of the blockchain, and by running the code to obtain the historical credit evaluation value of the target user, if there is a code in the block of the blockchain The historical credit evaluation value of the target user, the historical credit evaluation value of the target user can be read in the smart contract; if the historical credit evaluation value of the target user does not exist in the block of the blockchain, a target user's historical credit evaluation value is returned. The result of a historical credit assessment value that does not exist. The above code is the code corresponding to the query logic in the smart contract.

In one embodiment, code corresponding to the admission evaluation logic also exists on the smart contract. The code corresponding to the admission evaluation logic performs admission evaluation according to the result returned after the code corresponding to the query logic runs. When the previous 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 runs the evaluation logic according to the value of the user characteristics obtained in the previous step, obtains the credit evaluation value, and converts the credit evaluation value Stored in the block of the blockchain; when the historical credit evaluation value of the target user is obtained through the preceding steps, the code corresponding to the admission evaluation logic checks whether the value of the user characteristic has changed, and if there is a change, runs the evaluation logic, Obtain the credit evaluation value and store the credit evaluation value in the block of the blockchain; if there is no change, return to the historical credit evaluation value obtained in the previous steps.

When only the historical credit evaluation value is obtained, it is determined whether the target user is allowed to access according to the historical credit evaluation value; when the credit evaluation value is obtained by running the admission evaluation logic, it is determined whether the target user is allowed to access according to the credit evaluation value.

Specifically, referring to the aforementioned process of persisting certificate data in the blockchain, the client can construct an access evaluation transaction for the target user for invoking the smart contract deployed on the blockchain, and will The credit evaluation value generated by the target user's access evaluation transaction is released to the blockchain for storage. That is, the node device in the blockchain that is docked with the client can first receive the admission evaluation transaction for the target user, and then send the admission evaluation transaction for the target user to other nodes in the blockchain equipment. When each node device in the blockchain receives the access evaluation transaction of the target user, it can perform consensus processing on the access evaluation transaction of the target user. After reaching a consensus, the node devices in the blockchain can package the target user's access evaluation transaction into a block, and store the credit evaluation value persistently in the blockchain.

For the access evaluation transaction of the target user packaged into the block, it can be queried, and the result of the access evaluation transaction cannot be tampered with, so that when the user's characteristics do not meet the access conditions and the access is not allowed, unless the value of the user's characteristics In the event of a change or the organization modifies the smart contract, no one can tamper with the result of the access evaluation transaction, which ensures the safety and reliability of the access evaluation result.

In practical applications, the above-mentioned target users initiate an access evaluation transaction for the target user when applying for the services provided by the relevant institutions. The relevant institutions include banks, financial companies, payment platforms, etc.; The target user can be a natural person or a legal person; the characteristics of the target user are authorized by the user, obtained legally, and used to provide the user with products or services with the user's consent; and the use of the user's characteristics does not exceed the user's authorization. scope. The characteristics of the target user can be the user's own characteristics or the characteristics of artificial division. The characteristics of the user's own include the user's gender, the nature of the organization, the user's monthly income, and the user's debt ratio. The purpose of the service, the location where the user applies, the network environment of the user, etc., are not limited in this manual.

The features come from a wide range of sources, which can be the information authorized by the user in the process of using the business; it can also be the log data recorded in the process of using the business, which is mined by statistical methods; it can also be the credit data provided by a third party. This is not limited, as long as the features related to the user's credit can become the features 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 judging whether to allow user access, in order to save storage space, in some embodiments, the IV (Information Value, information value) value of the pre-stored values of the user characteristics is not lower than the predetermined value. set value.

The institution can store the value of the user's feature in the block of the blockchain. Before storing the value of the user's feature in the block, by calculating the IV value of the feature, the value of the feature whose IV value is lower than the preset value may not be in the block. stored on the blockchain.

The IV value will change due to the change in the probability of a user's default in the business process. For example, if a user with the same feature defaults on a large scale, the IV value of the feature will change. In some embodiments, the developer can set events that affect the IV value of the value of the feature in advance, such as:

Complaints generated after any one of the historical user features does not allow the associated user to access; events such as default events after any of the historical user features allows the associated user to access, the R&D personnel can Requirement, one of the events or a combination of multiple events is integrated as an event that affects the IV value.

In the process of approving users to access the business in the past, users often refused access because any feature did not meet the access conditions; users would complain about this situation. Therefore, before selecting the user feature and storing the value of the selected user feature on the blockchain, the IV value of the feature that generates customer complaints can be calculated, and the value of the feature whose IV value is lower than the preset value is not stored on the blockchain. .

After the institution grants access because any feature of the user meets the access conditions, a breach of contract occurs. Therefore, before selecting a feature and storing the value of the selected feature on the blockchain, the IV value of the feature that caused the default behavior can be calculated, and the value of the feature whose IV value is lower than the preset value is not stored on the blockchain.

The values of the features can be stored in different ways. In order to facilitate the management of user data, in some embodiments, the values of different user features are stored in different blocks.

The above block can be a block of the blockchain of the UTXO model, or a block of the blockchain of the account model. When the values of user features are stored on the blocks of the blockchain, the values of different features are stored on different blocks, and a block can store only the values of one feature; in order to realize when the values of user features have When updating, only the block corresponding to the feature is updated.

Institutions usually have data on the user's credit situation, and generate a specified credit parameter based on the data of the credit situation. This parameter can be a specific number or a credit rating; for example, the sesame credit score in Alipay, or the Standard & Poor's company's credit rating. Standard & Poor's credit rating. Taking the credit score as an example, if the user's credit score is lower than a threshold, the smart contract for the access evaluation transaction will not be invoked, and the user will not be allowed to enter; for another example, if the user has a credit rating, it is assumed that the highest rating is AAA, followed by For AA, the minimum rating is A. If the user's credit rating is A, the smart contract for the admission evaluation transaction will not be invoked, and the user will not be allowed to enter. Accordingly, in some embodiments, the step of responding to the admission evaluation transaction may further include: if the value of the target user's specified credit parameter is below a threshold, disallowing the originator of the admission evaluation transaction to invoke the admission evaluation transaction. smart contracts. (It will make it easier for people to have a sense of substitution after doing a good job of laying the groundwork first and then writing about your practice)

When the target user initiates a request for admission business, the node device in the blockchain receives the admission evaluation transaction for the target user, and when calling the smart contract, the credit evaluation value needs to be determined according to the corresponding admission evaluation logic in the smart contract code. , the admission evaluation logic can be implemented in various ways. In some embodiments, the admission evaluation logic uses different weighting coefficients to weight the values of different user characteristics according to the queried values of the user characteristics associated with the target user. operation to obtain the credit evaluation value.

Taking the credit evaluation value calculated by the weighted formula as an example, the value of the user's feature is recorded as pi, the weight coefficient corresponding to the feature is recorded as Ai, and the final credit evaluation value is recorded as R, then R=p1×A1+p2× A2+…+pn×An. This is just a simple example, other weighting operation methods such as index weighting can be used in actual operation, and the credit evaluation value R can be adjusted by the weight coefficient.

The weight coefficient used by the numerical value of the user feature can be adjusted according to experience, or calculated according to statistical methods, or a machine learning model can be used to obtain the weight coefficient. In some embodiments, the weight coefficient used by the numerical value of the user feature includes: Calculated using a machine learning model.

The weight factor can be stored in the smart contract and used when the code of the smart contract admission evaluation logic is called. Before writing the weight coefficient into the smart contract, you can use supervised training on the machine learning model to use the calculated value obtained by the machine learning model for supervised learning as the weight coefficient.

It is necessary to use data to train a machine learning model. In some embodiments, the machine learning model takes the user characteristics as a sample and uses the customer complaint data and/or asset loss data generated by the user characteristics as a supervised supervised model. trained model.

The supervised learning of the machine learning model includes taking user characteristics as samples, combining customer complaint data and asset loss data generated by user characteristics into a set of labels, and through training, so that the machine learning model can find out user characteristics and merged data. It is also possible to use user characteristics as samples and customer complaint data generated by user characteristics as a set of labels. Through training, the machine learning model can find out the relationship between user characteristics and the labels of customer complaint data. It is also possible to use the user characteristics as a sample and the asset loss data generated by the user characteristics as a set of labels. Through training, the machine learning model can find the relationship between the user characteristics and the labels of the asset loss data; finally , since the machine learning model has found the relationship between user features and labels, when acquiring data with only user features but no labels, the labels of user features can be determined.

There can be many types of machine learning models, and in some embodiments, the machine learning model can be a scorecard model.

The scorecard model includes steps such as data preprocessing, variable screening, variable binning, model training, and scorecard generation, among which supervised learning can be used during model training.

In the supervised training of the scorecard model, the data sets that take user characteristics as samples and combine customer complaint data and asset loss data generated by user characteristics into a set of labels are divided into training set and test set; Yes, the data set with user characteristics as samples and customer complaint data generated by user characteristics as a set of labels is divided into training set and test set; it is also possible to use user characteristics as samples and assets generated by user characteristics The loss data is a set of labels and the dataset is divided into training set and test set. Among them, the training set is used to train the model to obtain model parameters; the test set is used to test the fitting ability of the model to prevent overfitting or underfitting. A scorecard model can be built in a supervised learning process using logistic regression, decision tree, and GBDT (Gradient Boosting Decision Tree).

Since multiple machine learning models can be trained when there are multiple labels in the data, in some embodiments, the calculated value is obtained by weighting the output values of the two scorecard models; The label is the customer complaint data, and another scorecard model is labeled the asset loss data.

The data set with user characteristics as samples and customer complaint data generated by user characteristics as labels is divided into training set and test set. The training set is used to train the model to obtain model parameters; the test set is used to test the model Fitting ability to prevent over-fitting or under-fitting, and obtain the output value of the first scorecard model; divide the data set with user characteristics as samples and asset loss data due to user characteristics as labels as training sets And the test set, where the training set is used to train the model to obtain the model parameters; the test set is used to test the fitting ability of the model to prevent over-fitting or under-fitting, and obtain the output value of the second scorecard model; The calculated value is obtained by weighting the output value of the first scorecard model and the output value of the second scorecard model.

In order to save the time of training the model, multiple labels of the data can be combined into one, and only one machine learning model can be trained. In some embodiments, the user characteristics are used as samples, and the customer complaint data and asset losses generated by the user characteristics are used as samples. The data set with the same set of labels is divided into training set and test set. The training set is used to train the model to obtain model parameters; the test set is used to test the fitting ability of the model to prevent overfitting or underfitting. , the output value of the scorecard model is obtained, and the output value is the calculated value.

In order to further explain the blockchain-based user access method of the present application, the following is explained with reference to a specific embodiment.

In this embodiment, the value of user characteristics is pre-stored in the block of the blockchain, and the node device of the blockchain receives the admission evaluation transaction for the target user; wherein, the admission evaluation transaction is used to call the smart contract The query logic corresponding to the smart contract code in the smart contract obtains the value of the user characteristics associated with the target user; in response to the access evaluation transaction, the query logic corresponding to the smart contract code in the smart contract is invoked to query the historical credit evaluation value corresponding to the target user. Whether it has been stored in the block of the blockchain; if it has been stored, and the value of the user characteristic associated with the target user has not changed, then determine whether the target user is allowed access based on the historical credit evaluation value; If it does not exist or the value of the user characteristic associated with the target user is changed, call the access evaluation logic corresponding to the smart contract code to determine the credit evaluation value, determine whether the target user allows access, and assign the determined value to the user. The credit evaluation value is stored in the block of the blockchain.

Electronic devices added to the above-mentioned blockchain as node devices can be servers, computers, mobile phones, tablet devices, laptops, PDAs, and the like.

In this embodiment, an IV (Information Value, information amount) value of the pre-stored value of the user feature is not lower than a preset value. The institution can store the value of the user's feature in the block of the blockchain. Before storing the value of the user's feature in the block, by calculating the IV value of the feature, the value of the feature whose IV value is lower than the preset value may not be in the block. stored on the blockchain.

Before the value of the feature is stored on the blockchain, calculate the IV value of the feature that generates customer complaints, and the value of the feature whose IV value is lower than the preset value is not stored on the blockchain; The entry condition, the IV value of the feature that the user defaults on after entry.

Taking the age of the user as an example, the user is denied access because he is under the age of 30, and customers often complain about this situation; or, after the user is over the age of 30 and is allowed access, there is often a breach of contract. Then calculate the IV value of the user's age. The ages of users are grouped as follows in Table 3:

logo age range 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

Users are divided into good users and bad users, and the quality of the user is determined according to the type of business. For example, if the user is asked whether the user can access the shared bicycle rental service, then the bad customer is the user who does not return the bicycle or does not pay. On the other hand, if the bicycle is used normally, the user who fulfills the agreed obligations is a good user. The identifier of group i 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, then the WOE (weight of evidence, weight of evidence) of group i is ), the calculation formula of WOE _i is WOE _i =ln{(Bi/Bt)/(Gi/Gt)}, and the calculation formula of the IV value IV _i of the i-th group is:

The final IV value is the sum of the IV _i of each group

The value of the feature whose IV value of the user is less than the predetermined value is not stored on the blockchain, and the value of the feature whose IV value is less than the predetermined value already existing on the blockchain will not be updated. For example, if the IV value of the user's age is less than 0.02, it can be regarded as an invalid feature of the user's age, the user's age will not be stored on the blockchain, and the existing user's age data on the blockchain will not be updated.

In this embodiment, values of different user characteristics are stored in different blocks. Each block corresponds to a unique hash value, that is, if the value of the user feature is modified, the unique hash value will also change, so as to be traceable and non-tamperable.

In this embodiment, if the value of the specified credit parameter of the target user is lower than the threshold, the initiator of the admission evaluation transaction is not allowed to invoke the smart contract. Taking the credit score as an example, if the target user's credit score is lower than a threshold, such as 600, the initiator of the admission evaluation transaction is not allowed to call the smart contract, and the result that the user is not allowed to be admitted is returned instead of Perform blockchain-related calls and storage operations. The above-mentioned credit score can be a numerical value obtained by the method of data statistics based on the daily consumption behavior data of the user; as long as it is a numerical value that can characterize the user's historical credit situation, the rating can replace the credit score of this application.

Next, in response to the access evaluation transaction, the access evaluation logic corresponding to the smart contract code is invoked to determine the credit evaluation value. The smart contract obtains the credit evaluation value by applying different weighting coefficients to the values of different user characteristics according to the queried values of the user characteristics associated with the target user.

The smart contract in this embodiment is written in Solidity language, and a contract includes state variables, functions, function modifiers, and the like.

Taking the credit evaluation value calculated by the weighted formula as an example, the value of the user's feature is recorded as pi, the weight coefficient corresponding to the feature is recorded as Ai, and the final credit evaluation value is recorded as R, then R=p1×A1+p2× A2+…+pn×An. The smart contract stores the weight coefficient corresponding to the feature,

There is a function to calculate the credit evaluation value in the smart contract. The function receives the value of the feature, returns a credit evaluation value, and stores the credit evaluation value in the block of the blockchain. There is also a comparison function in the smart contract to compare whether the user's characteristic value has been updated. If there is no update, the historical credit evaluation value will be directly read from the block of the blockchain and returned; if there is an update, the comparison function will be called. A function that calculates a credit rating. When the weight coefficient corresponding to the feature needs to be modified, a new smart contract is created, and the original smart contract is no longer used. In this embodiment, the weight coefficient corresponding to the feature can also be stored on the block of the blockchain, and the smart contract stores the hash address of the block where the weight coefficient is located. When the weight coefficient needs to be read, the corresponding area is read according to the hash address. The weight coefficient of the block. When the weight coefficient corresponding to the feature needs to be updated, a transaction is initiated to update the weight coefficient on 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. Using user characteristics as samples, the data set with customer complaint data and asset loss data generated by user characteristics as labels is divided into training set and test set. Among them, customer complaint data and asset loss data are combined into the same set of labels. For example, the label of a group of data with customer complaints and asset loss is 1, the label of a group of data with customer complaints but no asset loss is 0.5, and the label of a group of data without customer complaints but with asset loss is 0.5, The label of data with neither customer complaints nor asset loss is 0. The labels here are only exemplary and can be adjusted according to specific situations. The final data of the dataset with the three characteristics of monthly income, user age and family size as samples are shown in Table 4 below:

monthly income User age family size Label 5000 20 3 0 6000 twenty one 4 0.5 7000 twenty two 5 1 … … … …

Table 4

In this embodiment, 70% of the data set is used as the training set, and 30% of the data set is used as the test set, wherein the training set is used to train the model to obtain model parameters; the test set is used to test the fitting ability of the model to prevent excessive Fit or underfit. The ratio of training set and test set can be adjusted as needed, for example, it can be adjusted to 6:4.

In this embodiment, logistic regression is used to construct a scorecard model. The cost function of the sigmoid function is solved by the gradient descent method, and the parameter value of the sigmoid function is obtained, which is the output value of the scorecard model.

The parameters of the sigmoid function can be shown in Table 5 below:

monthly income A1 User age A2 family size A3

table 5

Taking a user with a monthly income of 8,000 yuan, an age of 40, and a family of 5 people as an example, according to the weight coefficient determined above, the smart contract calculates the credit evaluation specified function to calculate the user's credit evaluation value equal to 8000×A1+40× A2+5×A3, store the credit evaluation value in the block of the blockchain to ensure that the access credit evaluation value can be traced back and cannot be tampered with, so as to realize the safety and reliability of user access;

Return the credit evaluation value to the node device. If the credit evaluation value is less than the preset value, the user is not allowed to enter; if the credit evaluation value is greater than or equal to the preset value, the user is allowed to enter, and the credit evaluation value calculated by this method is used. The judgment of user access is more accurate, the user complaint rate is reduced, and the user's access probability is improved.

Corresponding to the above-mentioned user access method, this embodiment of the present description also provides a blockchain-based user access device, as shown in FIG. A block diagram of a user access device, the blockchain-based user access device 80 can be applied to an electronic device as shown in FIG. 9 , and the electronic device can be used as a node device in the blockchain. The device 80 is applied to the node equipment in the blockchain; the blockchain is deployed with a smart contract for evaluating user access, and the blocks of the blockchain are pre-stored with user characteristics. Numerical value; the device 80 includes:

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

The query module 802 is configured to, in response to the admission evaluation transaction, call the smart contract to query whether the historical credit evaluation value corresponding to the target user has been stored in the block of the blockchain; The contract determines whether the target user is allowed access.

In some embodiments, the step of invoking the smart contract code by the query module 802 to determine the credit evaluation value includes:

According to the queried value of the user feature associated with the target user, the value of different user features is weighted with different weighting coefficients to obtain the credit evaluation value.

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

In some embodiments, the events that affect the IV value of the value of the user feature include at least one of the following: a complaint event generated after any one of the historical user features does not allow the associated user to access; The aforementioned historical user feature allows default events generated after the associated user accesses.

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

In some embodiments, the step of receiving module 801 in response to the admission evaluation transaction includes: if the value of the target user's specified credit parameter is below a threshold, disallowing the initiator of the admission evaluation transaction to invoke the intelligent contract.

In some embodiments, the weight coefficient used by the value of the user feature includes a calculated value obtained by using a machine learning model.

In some embodiments, the machine learning model is a supervised learning model using the user characteristics as samples and the customer complaint data and/or asset loss data generated by the user characteristics as labels.

In some embodiments, the machine learning model includes a scorecard model.

In some embodiments, the calculated value is obtained by weighting the output values of the two scorecard models; the label of one scorecard model is the customer complaint data, and the label of the other scorecard model is the Asset loss data.

For details of the implementation process of the functions and functions of each module in the above-mentioned device, please refer to the implementation process of the corresponding steps in the above-mentioned method, which will not be repeated here.

For the apparatus embodiments, since they basically correspond to the method embodiments, reference may be made to the partial descriptions of the method embodiments for related parts. The device embodiments described above are only illustrative, wherein the modules described as separate components may or may not be physically separated, and the components shown as modules may or may not be physical modules, that is, they may be located in One place, or it can be distributed over multiple network modules. Some or all of the modules can be selected according to actual needs to achieve the purpose of the solution in this specification. Those of ordinary skill in the art can understand and implement it without creative effort.

The systems, devices, modules or units described in the above embodiments may be specifically implemented by computer chips or entities, or by products with certain functions. A typical implementing device is a computer, which may be in the form of a personal computer, laptop computer, cellular phone, camera phone, smart phone, personal digital assistant, media player, navigation device, email sending and receiving device, game control desktop, tablet, 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.

Memory may include non-persistent memory in computer readable media, random access memory (RAM) and/or non-volatile memory in the form of, for example, read only memory (ROM) or flash memory (flash RAM). Memory is an example of a computer-readable medium.

Computer-readable media includes both persistent and non-permanent, removable and non-removable media, and storage of information may be implemented by any method or technology. Information may be computer readable instructions, data structures, modules of programs, 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 Disc (DVD) or other optical storage, Magnetic tape cartridges, disk storage, quantum memory, graphene-based storage media or other magnetic storage devices or any other non-transmission media can be used to store information that can be accessed by computing devices. As defined herein, computer-readable media does not include transitory computer-readable media, such as modulated data signals and carrier waves.

It should also be noted that the terms "comprising", "comprising" or any other variation thereof are intended to encompass a non-exclusive inclusion such that a process, method, article or device comprising a series of elements includes not only those elements, but also Other elements not expressly listed, or which are inherent to such a process, method, article of manufacture, or apparatus are also included. Without further limitation, an element qualified by the phrase "comprising a..." does not preclude the presence of additional identical elements in the process, method, article of manufacture, or device that includes the element.

The foregoing describes specific embodiments of the present specification. Other embodiments are within the scope of the appended claims. In some cases, the actions or steps recited in the claims can be performed in an order different from that in the embodiments and still achieve desirable results. Additionally, the processes depicted in the figures do not necessarily require the particular order shown, or sequential order, to achieve desirable results. In some embodiments, multitasking and parallel processing are also possible or may be advantageous.

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

It will be understood that although the terms first, second, third, etc. may be used in this specification to describe various information, such information should not be limited by these terms. These terms are only used to distinguish the same type of information from each other. For example, the first information may also be referred to as the second information, and similarly, the second information may also be referred to as the first information without departing from the scope of one or more embodiments of the present specification. Depending on the context, the word "if" as used herein can be interpreted as "at the time of" or "when" or "in response to determining."

The above descriptions are only preferred embodiments of one or more embodiments of this specification, and are not intended to limit one or more embodiments of this specification. All within the spirit and principles of one or more embodiments of this specification, Any modifications, equivalent replacements, improvements, etc. made should be included within the protection scope of one or more embodiments of this specification.

Claims (14)

1. A blockchain-based user access method, applied to node devices in the blockchain, in which a smart contract for evaluating user access is deployed, and the blockchain The value of user characteristics is pre-stored in the block of ; the method comprises the steps: Receive an access evaluation transaction for the target user; wherein, the access evaluation transaction is used to call the smart contract to obtain the value of the user characteristic associated with the target user; In response to the admission evaluation transaction, invoking the smart contract to query whether the historical credit evaluation value corresponding to the target user has been stored in the block of the blockchain; Whether the target user is allowed to enter is determined based on the query result or invoking the smart contract. 2. The method according to claim 1, wherein the step of determining whether the target user allows access based on a query result or calling a smart contract comprises: If the query result matches the numerical value of the user characteristic associated with the target user, determining whether the target user is allowed admission based on the historical credit evaluation value; If the query result is not found or the query result does not match the value of the user characteristic associated with the target user, call the smart contract to determine the credit evaluation value, determine whether the target user is allowed to enter, and assign the determined value to the user. The credit evaluation value is stored in the block of the blockchain. 3. The method according to claim 2, the step of invoking the smart contract to determine the credit evaluation value comprises: According to the queried value of the user feature associated with the target user, the value of different user features is weighted with different weighting coefficients to obtain the credit evaluation value. 4. The method according to claim 1, wherein the IV value of the pre-stored value of the user characteristic is not lower than a preset value. 5. The method according to claim 4, the event affecting the IV value of the numerical value of the user characteristic comprises at least any of the following: Complaints arising from any of the historical user characteristics that do not allow the associated user to access; An event of default resulting from the admission of the associated user due to 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 responding to the admission evaluation transaction further comprising disallowing an initiator call of the admission evaluation transaction if the target user's specified credit parameter value is below a threshold the smart contract. 8. The method according to claim 3, wherein the weight coefficient used by the numerical value of the user feature includes a calculated value obtained by using a machine learning model. 9. The method according to claim 8, wherein the machine learning model is a supervised learning model using the user characteristics as samples and customer complaint data and/or asset loss data generated due to the user characteristics as labels. 10. The method of claim 9, the machine learning model comprising a scorecard model. 11. The method of claim 10, the calculated value comprising an output value of the scorecard model; Alternatively, it is obtained by weighting the output values of the two scorecard models, wherein the label of one scorecard model is the customer complaint data, and the label of the other scorecard model is the asset loss data. 12. A blockchain-based user access device, the device is applied to node equipment in the blockchain; a smart contract for evaluating user access is deployed in the blockchain, the The value of the user characteristic is pre-stored in the block of the blockchain; the device includes: a receiving module, configured to receive an access evaluation transaction for a target user; wherein, the access evaluation transaction is used to call the smart contract to obtain the value of the user characteristic associated with the target user; The query module is used for invoking the smart contract to query whether the historical credit evaluation value corresponding to the target user has been stored in the block of the blockchain in response to the admission evaluation transaction; based on the query result or calling the smart contract It is determined whether the target user is allowed to admit. 13. An electronic device comprising: processor; memory for storing processor-executable instructions; Wherein, the processor implements the method according to any one of claims 1-11 by executing the executable instructions. 14. A computer-readable storage medium having stored thereon computer instructions that, when executed by a processor, implement the steps of the method of any of claims 1-11.

Images