A Risk Assessment Method, Device and Equipment Based on Blockchain

Abstract

In an embodiment of this specification, a risk assessment method, apparatus, and device based on a blockchain are disclosed. The solution may include: after the blockchain system obtains a first blockchain transaction carrying financing application information of a user, it first invokes a first type of smart contract deployed in the blockchain system, and based on the first on-chain credit data and the financing application information, performs a quick risk identification process on the user's financing application. If the financing risk level indicated by the result of the first risk identification process is lower than the preset financing risk level, the financing risk of the user is determined according to the first risk identification result. Otherwise, a second type of smart contract deployed in the blockchain system is invoked, and based on the financing application information and more comprehensive second on-chain credit data, a second risk identification process is performed on the user's financing application to determine the financing risk of the user according to the result of the second risk identification process.

Description

Technical Field

[0001] This application relates to the field of blockchain technology, and in particular, to a risk assessment method, apparatus, and device based on blockchain. Background Art

[0002] With the development of the economy and the progress of technology, more and more financing products are provided by various financing institutions. In the operation of financing business, it is usually necessary to conduct risk control for the financing applications of each user to reduce the possibility of risk events and protect the rights and interests of enterprises and users. Currently, each financing institution usually sets its own risk control strategy and requests relevant user credit data from a trusted institution, so as to use its risk control strategy and relevant user information data to evaluate the risks existing in the user's financing application.

[0003] Based on this, how to balance the efficiency and accuracy of the risk assessment of user financing applications has become a technical problem to be solved urgently. Summary of the Invention

[0004] A risk assessment method, apparatus, and device based on blockchain provided by the embodiments of this specification can improve the efficiency and accuracy of risk assessment for user financing applications.

[0005] To solve the above technical problems, the embodiments of this specification are implemented as follows:

[0006] A risk assessment method based on blockchain provided by the embodiments of this specification includes:

[0007] The blockchain system obtains the user's first blockchain transaction; the financing application information of the user is carried in the first blockchain transaction;

[0008] Call the first type of smart contract deployed in the blockchain system, and perform risk identification processing according to the financing application information and the first on-chain credit data to obtain a first risk identification result;

[0009] Judge whether the financing risk level indicated by the first risk identification result is lower than the preset financing risk level;

[0010] If so, determine the financing risk of the user according to the first risk identification result;

[0011] If not, call the second type of smart contract deployed in the blockchain system, and perform risk identification processing according to the financing application information and the user's second on-chain credit data to obtain a second risk identification result; the risk identification processing speed of the second type of smart contract is less than the risk identification processing speed of the first type of smart contract;

[0012] Determine the financing risk of the user according to the second risk identification result.

[0013] A risk assessment device based on blockchain provided by an embodiment of this specification includes:

[0014] A first acquisition module, configured to enable a blockchain system to acquire a first blockchain transaction of a user; the first blockchain transaction carries financing application information of the user;

[0015] A first invocation module, configured to invoke a first type of smart contract deployed in the blockchain system, and perform risk identification processing according to the financing application information and first on-chain credit data to obtain a first risk identification result;

[0016] A judgment module, configured to judge whether the financing risk level indicated by the first risk identification result is lower than a preset financing risk level;

[0017] A first determination module, configured to, when the financing risk level indicated by the first risk identification result is lower than the preset financing risk level, determine the financing risk of the user according to the first risk identification result;

[0018] A second invocation module, configured to, when the financing risk level indicated by the first risk identification result is not lower than the preset financing risk level, invoke a second type of smart contract deployed in the blockchain system, and perform risk identification processing according to the financing application information and second on-chain credit data of the user to obtain a second risk identification result; the risk identification processing speed of the second type of smart contract is less than the risk identification processing speed of the first type of smart contract;

[0019] A second determination module, configured to determine the financing risk of the user according to the second risk identification result.

[0020] A risk assessment device based on blockchain provided by an embodiment of this specification includes:

[0021] At least one processor; and,

[0022] A memory communicatively connected to the at least one processor; wherein,

[0023] The memory stores instructions executable by the at least one processor, and when the instructions are executed by the at least one processor, the at least one processor is enabled to:

[0024] Acquire a first blockchain transaction of a user; the first blockchain transaction carries financing application information of the user;

[0025] Invoke the first type of smart contract deployed in the blockchain system, and perform risk identification processing based on the financing application information and the first on-chain credit data to obtain a first risk identification result;

[0026] Determine whether the financing risk level indicated by the first risk identification result is lower than the preset financing risk level;

[0027] If so, determine the financing risk of the user according to the first risk identification result;

[0028] If not, invoke the second type of smart contract deployed in the blockchain system, and perform risk identification processing based on the financing application information and the user's second on-chain credit data to obtain a second risk identification result; the risk identification processing speed of the second type of smart contract is less than that of the first type of smart contract;

[0029] Determine the financing risk of the user according to the second risk identification result.

[0030] At least one embodiment provided in this specification can achieve the following beneficial effects:

[0031] After the blockchain system obtains the first blockchain transaction carrying the financing application information of the user, it first invokes the first type of smart contract with a faster risk identification processing speed deployed in the blockchain system, and performs the first risk identification processing on the user's financing application according to the first on-chain credit data and the financing application information. If the financing risk level indicated by the first risk identification processing result is lower than the preset financing risk level, then determine the financing risk of the user according to this first risk identification result. In this way, it is beneficial to improve the risk assessment efficiency. And if the financing risk level indicated by the first risk identification processing result is not lower than the preset financing risk level, then invoke the second type of smart contract deployed in the blockchain system, perform the second risk identification processing on the user's financing application according to the financing application information and the more comprehensive second on-chain credit data, and determine the financing risk of the user according to the second risk identification processing result. In this way, it is beneficial to improve the accuracy of the risk assessment result, so as to balance the efficiency and accuracy of the risk assessment of the user's financing application. BRIEF DESCRIPTION OF THE DRAWINGS

[0032] In order to more clearly illustrate the technical solutions in the embodiments of this specification or the prior art, the following will briefly introduce the drawings required for the description of the embodiments or the prior art. Obviously, the drawings in the following description are only some embodiments recorded in this application. For those of ordinary skill in the art, without creative efforts, other drawings can also be obtained based on these drawings.

[0033] Figure 1Schematic diagram of an application scenario of a risk assessment method based on blockchain provided by an embodiment of this specification;

[0034] Figure 2 Schematic flowchart of a risk assessment method based on blockchain provided by an embodiment of this specification;

[0035] Figure 3 Corresponding to the risk assessment method based on blockchain in Figure 2 Swimlane flowchart;

[0036] Figure 4 Corresponding to the risk assessment method based on blockchain in Figure 2 Schematic diagram of the structure of a risk assessment device based on blockchain;

[0037] Figure 5 Corresponding to the risk assessment method based on blockchain in Figure 2 Schematic diagram of the structure of a risk assessment device based on blockchain; Detailed implementation manners

[0038] To make the objectives, technical solutions, and advantages of one or more embodiments of this specification clearer, the technical solutions of one or more embodiments of this specification will be clearly and completely described below in conjunction with the specific embodiments of this specification and the corresponding drawings. Apparently, the described embodiments are only a part rather than all of the embodiments of this specification. Based on the embodiments in this specification, all other embodiments obtained by those of ordinary skill in the art without creative efforts shall fall within the scope of protection of one or more embodiments of this specification.

[0039] The following will detail the technical solutions provided by each embodiment of this specification with reference to the drawings.

[0040] In the operation process of the existing financing business, to reduce the probability of risk events and protect the rights and interests of enterprises and users, it is usually necessary to perform risk control on the financing applications of each user. Specifically, each financing institution usually sets its own risk control strategy. Since these risk control strategies rely on the manual experience of the staff at a single financing institution, the accuracy of the financing risk assessment results is affected. At the same time, due to the small amount of relevant user information data at a single financing institution, the financing institution needs to request relevant user credit data from a trusted institution. The time-consuming feedback of the trusted institution on the relevant user credit data will seriously affect the efficiency of the financing risk assessment. Based on this, how to balance the efficiency and accuracy of the risk assessment of user financing applications has become an urgent technical problem to be solved.

[0041] To solve the defects in the existing technology, the following embodiments are given in this solution:

[0042] Figure 1 This is a schematic diagram of an application scenario of a risk assessment method based on blockchain provided by an embodiment of this specification.

[0043] As Figure 1 shown, the blockchain system 101 may include multiple blockchain node devices. After the terminal device 102 obtains the smart contract deployment operation of the smart contract deployer, it may, in response to the smart contract deployment operation, send a blockchain transaction carrying smart contract deployment information to the blockchain system 101. After receiving the blockchain transaction, the blockchain system 101 may deploy a corresponding smart contract in the blockchain system 101 according to the smart contract deployment information.

[0044] In practical applications, a first type of smart contract, a second type of smart contract, a third type of smart contract, and a fourth type of smart contract may be deployed in the blockchain system 101. Among them, both the first type of smart contract and the second type of smart contract can be used to identify the risks existing in financial applications, and the risk identification processing speed of the first type of smart contract is faster than that of the second type of smart contract. The third type of smart contract can verify the effectiveness of the first type of smart contract, the second type of smart contract itself, the data used, and the generated risk identification results to address systemic risks. The fourth type of smart contract can provide the program code of the target operator for the first type of smart contract, the second type of smart contract, and the third type of smart contract to call during operation. This can not only enable multiple smart contracts to share the same piece of program code to save storage resources in the blockchain system, but also make the writing formats of each smart contract the same, facilitating the deployment and parsing of smart contracts.

[0045] After the terminal device 103 obtains the financing application operation of the financing application user, it can respond to the financing application operation and send a first blockchain transaction carrying financing application information to the blockchain system 101. After receiving the first blockchain transaction, the blockchain system 101 first calls the first type of smart contract to perform risk identification processing on the user's financing application according to the financing application information and the first on-chain credit data, and obtains a first risk identification result. If the financing risk level indicated by the first risk identification result is lower than the preset financing risk level, the third type of smart contract is used to verify the effectiveness of the first risk identification result, and the financing risk of the user is determined only based on the valid first risk identification result. In this way, it is beneficial to improve the risk assessment efficiency; if the financing risk level indicated by the first risk identification result is not lower than the preset financing risk level, the second type of smart contract is called to perform risk identification processing on the user's financing application again according to the financing application information and the more comprehensive second on-chain credit data, and a second risk identification result is obtained. Then, the third type of smart contract is used to verify the effectiveness of the second risk identification result, and the financing risk of the user is determined only based on the valid second risk identification result. In this way, it is beneficial to improve the accuracy of the risk assessment result, so that the efficiency and accuracy of the risk assessment of the user's financing application can be taken into account.

[0046] Next, a blockchain-based risk assessment method provided in the embodiments of the specification will be specifically described in conjunction with the accompanying drawings:

[0047] Figure 2 It is a schematic flowchart of a blockchain-based risk assessment method provided in the embodiments of this specification. From a program perspective, the execution subject of this process can be a blockchain system or an application program running in the blockchain system. As Figure 2 shown, this process may include the following steps:

[0048] Step 202: The blockchain system obtains the first blockchain transaction of the user; the first blockchain transaction carries the financing application information of the user.

[0049] In the embodiments of this specification, a blockchain can be understood as a data chain formed by sequentially storing multiple blocks. The block header of each block contains the timestamp of this block, the hash value of the previous block information, and the hash value of this block information, thereby realizing mutual verification between blocks and constituting an immutable blockchain. Each block can be understood as a data block (a unit for storing data). As a decentralized database, a blockchain is a string of data blocks generated by using cryptographic methods to be interrelated. Each data block contains the information of a network transaction, which is used to verify the validity of its information (anti-counterfeiting) and generate the next block. The chain formed by connecting the heads and tails of blocks is the blockchain. If it is necessary to modify the data within a block, it is necessary to modify the content of all blocks after this block and modify the data backed up by all nodes in the blockchain network. Therefore, the blockchain has the characteristics of being difficult to tamper with and delete. After the data has been saved to the blockchain, it is reliable as a method for maintaining the integrity of the content.

[0050] In the embodiments of this specification, relevant program codes of the blockchain can be pre-deployed on multiple devices respectively, so as to create a blockchain system including multiple blockchain nodes. In practical applications, this blockchain system can be used to run a consortium chain, or can also be used to run a public chain or a private chain, and no specific limitation is made thereto.

[0051] In the embodiments of this specification, a user can generate a first blockchain transaction carrying financing application information through a Decentralized Application (DApp), and send the first blockchain transaction to the blockchain system to initiate a financing request to the blockchain system through the first blockchain transaction.

[0052] Among them, the user can be either an enterprise or an individual. And the financing application information can include information such as user identity information, collateral information, and expected loan amount. In practical applications, the user identity information can be either the identity information currently input by the user, for example, an enterprise business license, or, it can also be the Decentralized IDentity (DID) information pre-registered by the user in the blockchain system, etc. And the collateral information can be information reflecting the assets of the user, for example, the equipment purchase invoice information for proving that the user has a specified device, the invoice information for proving the customer's outstanding payment, real estate information, etc., and no specific limitation is made thereto.

[0053] The DApp has the advantage of high transaction security. The embodiments of this specification support users to generate the first blockchain transaction through the DApp, which is beneficial to improving the transaction security of users. The DID has the advantages of being verifiable and having a high credibility. The embodiments of this specification support the DID as user identity information, which is beneficial to ensuring the authenticity of user identity information. In addition, the DID also has the advantages of convenient application and effective protection of user privacy. The embodiments of this specification support the DID as user identity information, which is beneficial to enhancing the user experience.

[0054] The financing application information may also include user-defined information. There is no format restriction on the user-defined information, which may result in different formats of user-defined information written by different users. In order for the blockchain system to successfully identify the user-defined information of each user, after receiving the user-defined information, the blockchain system may convert the user-defined information of each user into information data in a specific format through the application data standardization conversion contract deployed in the blockchain system, so that the blockchain system can perform risk identification processing based on the converted user-defined information.

[0055] Step 204: Invoke the first type of smart contract deployed in the blockchain system, and perform risk identification processing based on the financing application information and the first on-chain credit data to obtain a first risk identification result.

[0056] In the embodiments of this specification, the blockchain system may deploy a first type of smart contract and a second type of smart contract for financing risk identification. Among them, the risk identification processing speed of the first type of smart contract is greater than that of the second type of smart contract. And usually, the data type and data volume of the on-chain information data required by the first type of smart contract are less than those of the second type of smart contract.

[0057] Specifically, the first type of smart contract can determine the user category according to the first on-chain credit data and the user's financing application information. The user category includes trustworthy users and suspicious users. Among them, for trustworthy users, it can be directly determined that their financing risk level is lower than the preset financing risk level. In this way, the risk identification processing efficiency of trustworthy users is improved, and thus the risk assessment efficiency of the embodiments of this specification is improved; for suspicious users, it is necessary to invoke the second type of smart contract deployed in the blockchain system to perform risk identification processing on them again to improve the accuracy of the risk identification processing result of suspicious users, and thus improve the accuracy of the risk assessment result of the embodiments of this specification.

[0058] Step 206: Determine whether the financing risk level indicated by the first risk identification result is lower than the preset financing risk level. If so, execute step 208; otherwise, execute step 210.

[0059] Step 208: Determine the financing risk of the user according to the first risk identification result.

[0060] In the embodiment of this specification, when the financing risk level indicated by the first risk identification result is lower than the preset financing risk level, the first risk decision smart contract deployed in the blockchain system can be called to finally determine the financing risk of the user according to the first risk identification result. In practical applications, when the contract code of the first risk decision smart contract is executed, the first risk identification result can be used as an input parameter to finally determine the financing risk of the user according to the first risk identification result and the user's financing application information.

[0061] Step 210: Call the second type of smart contract deployed in the blockchain system, and perform risk identification processing according to the financing application information and the user's second on-chain credit data to obtain a second risk identification result; the risk identification processing speed of the second type of smart contract is less than the risk identification processing speed of the first type of smart contract.

[0062] In the embodiment of this specification, for users whose financing risk level indicated by the first risk identification result is not lower than the preset financing risk level, the second type of smart contract can also be called to perform a second risk identification process on such users to more accurately determine the financing risk level of such users, which is beneficial to improving the accuracy of the risk assessment result.

[0063] The user's second on-chain credit data includes at least one of the following information data: the financing product orders completed by the user in the blockchain system, the information on the user's business transactions with other users, the user's financing risk data feedback by the credit reference center recognized by the financing institution, and the user's off-chain credit data obtained based on the oracle stored in the blockchain system.

[0064] Among them, the financing product orders completed by the user in the blockchain system can be used to determine whether the target pledge submitted by the user in this financing application has been pledged. Specifically, when the financing product orders completed by the user in the blockchain system include the user's target pledge, it can be considered that the user's target pledge has been pledged; when the financing product orders completed by the user in the blockchain system do not include the user's target pledge, it can be considered that the possibility that the user's target pledge has not been pledged is relatively high. Secondly, the information on the user's business transactions with other users can be contracts and / or payment vouchers related to the pledge, etc. According to the information on the user's business transactions with other users, the authenticity of the user's pledge information can be determined. It should be noted that the user can have multiple pledges. In the embodiment of this specification, the pledges of the user are valued, specifically, all the pledges of the user are valued to determine the value of the total valuation.

[0065] Of course, the user financing risk data feedback by the credit reference center recognized by the financing institution and the off-chain credit data of the user obtained based on the oracle in the blockchain system can also be used to verify the authenticity of the pledged assets and whether they have been pledged. At the same time, they can also be used to determine the user's creditworthiness.

[0066] In practical applications, the second type of smart contract deployed in the blockchain system is called, and risk identification processing is performed based on the financing application information and the user's second on-chain credit data to obtain a second risk identification result. Specifically, it may include:

[0067] Execute the contract code of the second type of smart contract to obtain a second risk identification result; when the contract code of the second type of smart contract is executed, it is used to obtain the user's second on-chain credit data stored in the blockchain system according to the user's identity information, generate an evaluation result for the pledged asset information according to the second on-chain credit data, and perform risk identification processing according to the evaluation result and the second on-chain credit data to obtain a second risk identification result.

[0068] Specifically, in the process of evaluating the pledged asset information, it can be: first, judge the authenticity of the pledged asset according to the information of the user's business transactions with other users. If the pledged asset is false, end the evaluation process of the pledged asset. If the pledged asset is true, judge whether the pledged asset has been pledged according to the financing product orders completed by the user in the blockchain system. If the pledged asset has been pledged, discount the pledged asset, and the minimum discount result is 0. If the pledged asset has not been pledged, evaluate the pledged asset to obtain an evaluation result. Subsequently, risk identification processing can also be performed on the user's financing application according to the evaluation result of the pledged asset and the second on-chain credit data to obtain a second risk identification result.

[0069] Step 212: Determine the financing risk of the user according to the second risk identification result.

[0070] In the embodiments of this specification, the second risk identification result can be data capable of representing the degree of the user's financing risk. For example, the second risk identification result can be the user's credit score data or credit rating data. After the blockchain system determines the second risk identification result, it can call the second risk decision smart contract deployed in the blockchain system and use the second risk identification result as input data to determine the user's final financing risk.

[0071] Figure 2In the method described above, after the blockchain system obtains the user's first blockchain transaction, it first invokes the first type of smart contract deployed in the blockchain system with a relatively fast risk identification processing speed to perform the first risk identification processing, so as to quickly identify users whose financing risk level is lower than the preset financing risk level. For such users, their financing risk is directly determined according to the result of the first risk identification processing, which improves the risk assessment efficiency of the embodiments of this specification. For users whose financing risk level is not lower than the preset financing risk level, the second type of smart contract deployed in the blockchain system is invoked to perform the second risk identification processing, and based on the result of the second risk identification processing, the financing risk of such users is determined, which improves the accuracy of the risk assessment result of the embodiments of this specification. Ultimately, the embodiments of this specification take into account both the efficiency and accuracy of the risk assessment of the user's financing application.

[0072] Based on Figure 2 the method described above, the embodiments of this specification also provide some specific implementation schemes of this method, which will be described below.

[0073] In the embodiments of this specification, after invoking the first type of smart contract deployed in the blockchain system to perform risk identification processing on the user's financing application according to the financing application information and the first on-chain credit data, if the first risk identification result indicates that the financing risk level is lower than the preset financing risk level, then the financing risk of the user is directly determined according to the first risk identification result of this user, so as to improve the efficiency of risk assessment for the user. It can be seen that how to quickly and accurately perform risk identification processing on the user's financing application according to the financing application information and the first on-chain credit data is the key to improving the risk assessment efficiency of the embodiments of this specification.

[0074] Based on this, the first on-chain credit data may include on-chain risk list data.

[0075] Correspondingly, step 204, invoking the first type of smart contract deployed in the blockchain system to perform risk identification processing according to the financing application information and the first on-chain credit data, and obtaining a first risk identification result, may specifically include:

[0076] Executing the contract code of the first type of smart contract to obtain a first risk identification result; when the contract code of the first type of smart contract is executed, it is used to compare the identity information of the user with the on-chain risk list data to obtain a comparison result, and based on the comparison result, generate a first risk identification result.

[0077] In the embodiments of this specification, the on-chain risk list data can be the data in the on-chain risk list stored in the blockchain system. There can be multiple types of the on-chain risk list. For example, user lists, device lists, etc. Among them, the user list can include: enterprise name list and individual name list. The device list can include: Internet Protocol Address (IP) list, Unique Device Identifier list, etc.

[0078] In practical applications, the number of on-chain risk lists can be at least one, and the number of the first type of smart contracts can be at least one. The verification methods of each on-chain risk list determine the number of the first type of smart contracts. Specifically, if the verification methods of each on-chain risk list are the same, the number of the first type of smart contracts is one, that is, each on-chain risk list shares one first type of smart contract; if the verification methods of each on-chain risk list are different, each verification method corresponds to one first type of smart contract. In this way, the number of the first type of smart contracts is reduced, and the workload of developers is reduced.

[0079] The verification methods of the on-chain risk list include: if a user is in the on-chain risk list, it is determined that the financing risk degree of the user is lower than the preset financing risk degree, and if a user is in the on-chain risk list, it is determined that the financing risk degree of the user is not lower than the preset financing risk degree, etc. The verification methods of each on-chain risk list in the embodiments of this specification can be the same or different, and this specification does not limit this here.

[0080] The embodiments of this specification adopt the above solution. By comparing the identity information of the user with the on-chain risk list data, according to the comparison result, a first risk identification result including the financing risk degree of the user is generated, so that the embodiments of this specification can quickly and accurately determine the financing risk degree of the user, which is conducive to improving the efficiency of risk assessment in the embodiments of this specification.

[0081] In practical applications, the on-chain risk list may need to be changed. For example, if a certain user refuses to repay the loan on time and is listed as a defaulter, in this case, the on-chain risk list needs to be changed according to the situation of this user. When changing the on-chain risk list, if only the on-chain risk list can be changed without changing the corresponding first type of smart contract, it will be beneficial to reduce the workload of developers and further reduce the operation and maintenance cost of the blockchain system.

[0082] Based on this, when the on-chain risk list data is the data in the risk list stored in the blockchain system, the method in the embodiments of this specification may further include:

[0083] The blockchain system obtains a second blockchain transaction; the second blockchain transaction is used to add several user identity information to the risk list, or the second blockchain transaction is used to identify that several user identity information in the risk list has become invalid.

[0084] According to the second blockchain transaction, the risk list is updated to obtain updated on-chain risk list data.

[0085] In the embodiments of this specification, the first on-chain credit data is not written into the contract code of the first type of smart contract in a hard-coded form, but the first type of smart contract is enabled to have the ability to call the updatable first on-chain credit data. In this way, by conveniently updating the first on-chain credit data (on-chain risk list), without changing and redeploying the first type of smart contract, the first type of smart contract can be used to accurately determine the current financing risks of each user whose credit situation has changed based on the updated first on-chain information data, which is beneficial to reducing the operation and maintenance costs of the blockchain system in the embodiments of this specification.

[0086] In the embodiments of this specification, if it is determined through the first type of smart contract and the first on-chain credit data that the financing risk degree of a user is not lower than the preset financing risk degree, further risk identification processing needs to be performed on this user, so that the embodiments of this specification can take into account the accuracy of the risk assessment result while improving the risk assessment efficiency. It can be seen that how to accurately perform risk identification processing on the user financing application with a financing risk degree not lower than the preset financing risk degree is a technical problem to be solved in the embodiments of this specification.

[0087] Based on this, the second type of smart contract mentioned in step 210 may include at least one of a first smart contract, a second smart contract, and a third smart contract. Among them, the first smart contract is used to perform risk identification processing based on a machine learning model, the second smart contract is used to perform risk identification processing based on a scoring card model, and the third smart contract is used to perform risk identification processing based on a preset policy.

[0088] In the embodiments of this specification, when the contract code of the first smart contract is executed, the second on-chain credit data of the user can be input into a pre-trained machine learning model, so that the machine learning model outputs a first risk identification sub-result. Since the machine learning model has high risk identification efficiency and high accuracy of risk identification results, it is beneficial to improve the risk assessment efficiency and the accuracy of the risk assessment result in the embodiments of this specification.

[0089] When the contract code of the second smart contract is executed, it can input the user's second on-chain credit data into the scoring card model and determine the second risk identification sub-result according to the scoring criteria of the scoring card model. Specifically, multiple scoring strategies are set in the scoring card model, and each scoring strategy can independently correspond to a scoring criterion. For example, the scoring strategy is whether the user's default times are greater than 5 times, and the corresponding scoring criterion is: if the user's default times are greater than 5 times, the user gets 1 point; otherwise, the user gets 5 points, etc. Thus, the credit score or credit rating of the user can be determined based on the scoring card model. The scoring card model can accurately perform financing risk identification processing by setting comprehensive and detailed scoring strategies, which is beneficial to improving the accuracy of the risk assessment results of the embodiments of this specification.

[0090] When the contract code of the third smart contract is executed, it can determine the third risk identification sub-result according to the user's second on-chain credit data and the preset strategy. Specifically, the first smart contract and the second smart contract are usually relatively stable and do not change frequently. During the operation of the financing business, there are often risk control strategies that need to be implemented temporarily. Therefore, the preset strategy at the third smart contract can be set according to actual needs to meet the business requirements. For example, when it is necessary to temporarily limit the loan amount of type A enterprises not to exceed a specified amount, the preset strategy can be set as: if the enterprise type of the enterprise applying for financing is a type A enterprise, then set the maximum value of the financing amount of this enterprise to the specified amount. Subsequently, if the maximum value of the loan amount of type A enterprises is no longer restricted, an invalid flag can be set for the risk identification processing result generated by this preset strategy, so that the maximum value of the financing amount of this enterprise is no longer restricted. In this way, the need of the financing institution to change the risk control strategy according to the actual situation is met, which is convenient and fast.

[0091] In the embodiments of this specification, if the target risk identification result (the first risk identification result or the second risk identification result) is invalid data, then the financing risk of the user determined according to the target risk identification result will not match the actual financing risk of the user. Therefore, in order to improve the accuracy of the risk assessment results of the embodiments of this specification, during the process of determining the financing risk of the user according to the target risk identification result, it is necessary to verify the validity of the target risk identification result.

[0092] Based on this, in step 208, the determining of the financing risk of the user according to the first risk identification result may specifically include:

[0093] Invoke the third type of smart contract deployed in the blockchain system to verify the validity of the first risk identification result and obtain the first verification result.

[0094] If the first verification result meets the first verification passing condition, then determine the financing risk of the user according to the first risk identification result.

[0095] Correspondingly, in step 212, determining the financing risk of the user according to the second risk identification result specifically includes:

[0096] Invoking the third type of smart contract to perform validity verification on the second risk identification result to obtain a second verification result.

[0097] If the second verification result meets the second verification passing condition, determine the financing risk of the user according to the second risk identification result.

[0098] In the embodiments of the present specification, a third type of smart contract can also be deployed in the blockchain system to perform validity verification on the risk identification results generated by the first type of smart contract and the second type of smart contract.

[0099] In practical applications, for the first risk identification result, it can be verified that at least part of the risk identification results in the first risk identification result are invalid, and an invalid flag is added to this part of the invalid first risk identification results, so that subsequently, the financing risk of the user can be determined only according to the first risk identification results without the invalid flag. Similarly, for the second risk identification result, it can be verified that at least part of the risk identification results in the second risk identification result are invalid, and an invalid flag is added to this part of the invalid second risk identification results, so that subsequently, the financing risk of the user can be determined only according to the second risk identification results without the invalid flag.

[0100] The embodiments of the present specification improve the accuracy of the risk assessment results of the embodiments of the present specification by verifying the validity of the target risk identification result (the first risk identification result or the second risk identification result) and determining the financing risk of the user only according to the verified valid risk identification results. At the same time, it is beneficial to solve the decision-making of systematic risks caused by global risks.

[0101] In the embodiments of the present specification, since the first risk identification result is determined according to the first type of smart contract and the first on-chain credit data, therefore, the security of the first type of smart contract and the first on-chain credit data can be verified to accurately determine the validity of the first risk identification result. Similarly, the second risk identification result is determined according to the second type of smart contract and the second on-chain credit data, so the security of the second type of smart contract and the second on-chain credit data can be verified to accurately determine the validity of the second risk identification result.

[0102] Based on this, based on step 208, the invocation of the third type of smart contract deployed in the blockchain system to perform validity verification on the first risk identification result specifically may include:

[0103] Invoke the third type of smart contract to perform security verification on the first type of smart contract and the on-chain credit data of the first chain; wherein, the first type of smart contract includes a cross-chain smart contract, and the on-chain credit data of the first chain includes cross-chain data.

[0104] Based on step 212, the invocation of the third type of smart contract to perform validity verification on the second risk identification result may specifically include:

[0105] Invoke the third type of smart contract to perform security verification on the second type of smart contract and the on-chain credit data of the second chain; wherein, the second type of smart contract includes a cross-chain smart contract, and the on-chain credit data of the second chain includes cross-chain data.

[0106] In the embodiments of this specification, performing security verification on the on-chain credit data of the target chain (the on-chain credit data of the first chain or the on-chain credit data of the second chain) may specifically include: verifying whether the obtained on-chain credit data has been tampered with, and verifying whether the submitting institution of the on-chain credit data is a trusted institution, etc. Performing security verification on the target smart contract (the first type of smart contract or the second type of smart contract) may specifically include: verifying whether the contract code of the smart contract has been tampered with and verifying whether the user deploying the smart contract is reliable, etc.

[0107] It should be noted that a target smart contract (for example, the first type of smart contract and the second type of smart contract) can be used to implement multiple risk control strategies. When performing security verification on the target smart contract, it may specifically be to verify whether each risk control strategy in the target smart contract has been tampered with and / or whether the strategy deployment user is reliable. The verification result may be that all risk control strategies in the target smart contract are effective, some risk control strategies are effective, or all risk control strategies are ineffective. In this way, the purpose of accurately verifying the security of the target smart contract is achieved, and effective risk control strategies are prevented from being invalidated.

[0108] Specifically, the risk identification result generated by the target smart contract will be pushed to the third type of smart contract in the form of a message. The third type of smart contract can also obtain the contract information of the target smart contract from the state tree, so as to be able to perform security verification on the target smart contract itself and the on-chain credit data used during the operation of the target smart contract, and determine the validity of the risk identification result generated by the target smart contract based on the verification result.

[0109] In practical applications, the first type of smart contract and the second type of smart contract may include cross-chain smart contracts, and the first on-chain credit data and the second on-chain credit data may also include cross-chain data, so that cross-chain risk control can also be achieved by using the third type of smart contract. Of course, the first type of smart contract and the second type of smart contract may also include smart contracts within the blockchain system, and the first on-chain credit data and the second on-chain credit data may also include on-chain credit data on this blockchain system. In this way, the embodiments of this specification can more accurately verify the effectiveness of the first risk identification result and the second risk identification result.

[0110] In the embodiments of this specification, if a smart contract is verified to be invalid, a failure flag needs to be set for the risk identification result generated by the smart contract.

[0111] Based on this, based on step 208, the calling of the third type of smart contract deployed in the blockchain system to verify the effectiveness of the first risk identification result may specifically include:

[0112] Calling the third type of smart contract to set a failure flag for the third risk identification result in the first risk identification result; the third risk identification result is the risk identification result generated by the invalid smart contract in the first type of smart contract.

[0113] Based on step 212, the calling of the third type of smart contract to verify the effectiveness of the second risk identification result may specifically include:

[0114] Calling the third type of smart contract to set a failure flag for the fourth risk identification result in the second risk identification result; the fourth risk identification result is the risk identification result generated by the invalid smart contract in the second type of smart contract.

[0115] As can be seen from the above analysis, when performing security verification on a target smart contract (the first type of smart contract or the second type of smart contract), the verification result may be that all risk control strategies in the target smart contract are invalid or some risk control strategies are invalid. The embodiments of this specification specifically set a failure flag for the risk identification result generated by the invalid risk control strategy, so that the risk identification results generated by the effective risk control strategies can all be used to evaluate the financing risk of the user, which is beneficial to improving the accuracy of the risk assessment result of the embodiments of this specification.

[0116] In the embodiments of this specification, even if the contract code of the smart contract has not been tampered with and the deploying user of the smart contract is reliable, the smart contract may still need to be invalidated due to unreasonable settings. In practical applications, it can be that the blockchain system verifies the invalidation of the smart contract based on preset invalidation conditions and the running data of the smart contract, or it can be that relevant personnel (such as smart contract deploying personnel) determine the invalidation of the smart contract based on preset invalidation conditions and the running data of the smart contract.

[0117] Based on this, before step 208, when setting an invalidation flag for the third risk identification result in the first risk identification result, the method in the embodiments of this specification may further include:

[0118] Determine the smart contracts in the first type of smart contracts that meet the preset invalidation conditions according to the execution results of the first type of smart contracts within a preset time period, so as to obtain the invalid smart contracts in the first type of smart contracts; or, determine the invalid smart contracts in the first type of smart contracts according to the identification information of the invalid smart contracts carried in the third blockchain transaction received.

[0119] Correspondingly, before step 212, when setting an invalidation flag for the fourth risk identification result in the second risk identification result, it may further include:

[0120] Determine the smart contracts in the second type of smart contracts that meet the preset invalidation conditions according to the execution results of the second type of smart contracts within a preset time period, so as to obtain the invalid smart contracts in the second type of smart contracts; or, determine the invalid smart contracts in the second type of smart contracts according to the identification information of the invalid smart contracts carried in the fourth blockchain transaction received.

[0121] In the embodiments of this specification, the preset invalidation condition may be whether the policy failure rate of the smart contract within a preset time period meets the preset failure rate standard. Among them, the policy failure rate may be the ratio (percentage) of the users who do not meet the conditions for subscribing to financing products determined by the smart contract to all users who submit financing applications. The preset failure rate standard can be set by the financing institution according to the actual situation, with the criterion of not affecting the normal business execution of the financing institution. For example, the preset invalidation condition may be: within a preset time period, when the ratio of the users who do not meet the conditions for subscribing to financing products determined by a certain smart contract to all users who submit financing applications is greater than 50%, then determine that the certain smart contract is invalid. In this way, unreasonable smart contracts can be invalidated in a timely manner, which is beneficial to improving the effectiveness of smart contracts.

[0122] Secondly, in practical applications, it may also be the case that the deployer of the smart contract or other relevant personnel discover that the deployment of the smart contract is unreasonable, and its running result affects the normal operation of the financing institution. At this time, the person who discovers the unreasonableness of the smart contract can actively submit a third blockchain transaction carrying the identification information of the invalid smart contract to the blockchain system, so that the blockchain system can determine the invalid smart contract according to the third blockchain transaction. In this way, the need for users to invalidate unreasonable smart contracts is satisfied, and at the same time, the effectiveness of the smart contract is improved.

[0123] In the embodiments of this specification, the operators required during the operation of each smart contract may be repeated. If the program code for implementing the same operator is repeatedly deployed in each smart contract, it will cause unnecessary waste of the storage space of the blockchain system, and in addition, increase the workload of the smart contract deployer. Therefore, it is necessary to reduce the repeated deployment of the program code corresponding to the same operator in each smart contract.

[0124] Based on this, before calling the first type of smart contract deployed in the blockchain system, the method of the embodiments of this specification may further include:

[0125] Obtain a fifth blockchain transaction for deploying a fourth type of smart contract; the contract code of the fourth type of smart contract includes program code for performing calculations corresponding to a preset operator.

[0126] Store the contract code of the fourth type of smart contract in the blockchain system.

[0127] Obtain a sixth blockchain transaction for deploying a target smart contract; the target smart contract includes at least one of the first type of smart contract, the second type of smart contract, and the third type of smart contract. When the target smart contract runs, it calls the contract code of the fourth type of smart contract to perform calculations corresponding to the preset operator.

[0128] In response to the sixth blockchain transaction, deploy the target smart contract in the blockchain system.

[0129] In the embodiments of this specification, the program code of the fourth type of smart contract may include the program codes of operators corresponding to several methods. Specifically, each method may include several operators, and the operators in each method are of one type of operator. For example, the first method includes three operators: greater than, equal to, and less than, and the second method includes two operators: and and or, etc. By deploying the program code of the fourth type of smart contract to the blockchain system, and enabling the first type of smart contract, the second type of smart contract, and the third type of smart contract to directly call the program code of the fourth type of smart contract when they need to call the program code of a specified operator during operation, the reuse of the program code corresponding to the same operator can be achieved, which is beneficial to avoiding the waste of the storage space of the blockchain system.

[0130] Specifically, usually, it is necessary to first deploy the fourth type of smart contract and write the contract address of the fourth type of smart contract into the program codes of the first type of smart contract, the second type of smart contract, and the third type of smart contract. Thus, after deploying the first type of smart contract, the second type of smart contract, and the third type of smart contract, they can call the contract code of the fourth type of smart contract through the contract address of the fourth type of smart contract, and then execute the calculation corresponding to the specified operator.

[0131] Since the first type of smart contract, the second type of smart contract, and the third type of smart contract are used to implement the financing risk control strategy, therefore, when deploying the first type of smart contract, the second type of smart contract, and the third type of smart contract, in addition to submitting the contract framework code, some information for executing the preset risk control strategy can also be carried in the contract framework code. Of course, it is also possible to only submit the contract framework code and update the risk control strategies required to be executed by each smart contract after the above-mentioned smart contracts are successfully deployed. No specific limitation is made on this.

[0132] In the embodiments of this specification, when it is necessary to update the target smart contract so that the updated target smart contract executes the newly added risk control strategy to meet the requirements of relevant risk identification and processing, specifically, the following steps may be executed after deploying the target smart contract in the blockchain system:

[0133] Obtain the seventh blockchain transaction for changing the target smart contract; the seventh blockchain transaction is used to add the risk control strategy required to be executed by the target smart contract, and the target operator of the risk control strategy, the left value information of the target operator, and the right value information of the target operator are carried in the seventh blockchain transaction.

[0134] In response to the seventh blockchain transaction, the target smart contract is modified to obtain an updated target smart contract; when the updated target smart contract runs, by invoking the program code in the fourth type of smart contract for performing the calculation corresponding to the target operator, according to the left value information and the right value information, an execution result for the risk control policy is generated.

[0135] Specifically, the seventh blockchain transaction can be sent by the administrator of the blockchain system to the blockchain system. The seventh blockchain transaction can carry the DID, account information, and signature of the administrator, so that the blockchain system can confirm that the administrator has the permission to modify the smart contract based on this information; it should be noted that before the administrator initiates the seventh blockchain transaction, the risk control policy in the seventh blockchain transaction needs to be audited by each financing institution off-chain, that is, the risk control policy in the seventh blockchain transaction is a risk control policy that has passed the audit to protect the rights and interests of each financing institution.

[0136] Secondly, the seventh blockchain transaction can carry the target operator of the risk control policy, the left value information of the target operator, and the right value information of the target operator in a specified field, so as to facilitate the blockchain system to parse and identify the execution of the risk control policy. For ease of understanding, the left value information and the right value information of the target operator are illustrated by examples. For example, assume that it is necessary to determine whether the number of default times of a user is greater than 5 times. Then the target operator can be the greater than operator, its left value information can be the number of default times of the user, and the right value information can be 5.

[0137] The seventh blockchain transaction can also carry the contract address of the target smart contract, the account information of the transaction recipient, the account information of the transaction initiator, and the name of the method to which the target operator belongs, so that the blockchain system can determine the target smart contract according to the contract address of the target smart contract, determine the legality of the transaction according to the account information of the transaction recipient and the account information of the transaction initiator, and quickly find the program code corresponding to the target operator in the fourth type of smart contract according to the name of the method to which the target operator belongs.

[0138] In the embodiments of this specification, if it is determined whether a user can order a financing product only based on the financing risk of the user. For example, users with a financing risk lower than the preset financing risk can order all financing products, and users not lower than the preset financing risk cannot order all financing products. This will cause the operation result of the blockchain system to affect the normal business operation of the financing institution. Therefore, after determining the financing risk of the user, it is also necessary to determine the available financing products of the user according to the financing risk of the user and the preset financing conditions.

[0139] Based on this, after determining the financing risk of the user, the method in the embodiments of this specification may further include:

[0140] Determine available financing products that meet the preset financing conditions for the user according to the user's financing risk.

[0141] Obtain the eighth blockchain transaction of the user; the eighth blockchain transaction is used to indicate the subscription of the target financing product among the available financing products.

[0142] Generate an order for the target financing product for the user based on the eighth blockchain transaction.

[0143] Specifically, the preset loan amount, the total amount of loans already disbursed, and financing product information of each financing institution can be stored in the blockchain system. The preset financing conditions may include: the remaining loan amount of the financing institution is greater than the user's expected loan amount, the user's financing risk meets the financing risk requirements of the target financing product, the available credit of the user at the financing institution is greater than the user's expected loan amount, etc.

[0144] The user can submit the eighth blockchain transaction to the blockchain system through the DAPP. The eighth blockchain transaction may carry the identifier of the target financial product and the user's subscription request information, so that the blockchain system can generate an order for the target financing product according to the eighth blockchain transaction. The order for the target financing product is used to enable the blockchain system to generate, according to the order information of the order for the target financing product, a blockchain transaction for instructing the lending institution providing the target financing product to disburse a loan to the user according to the order information of the order for the target financing product, without requiring the lending institution providing the target financing product to conduct a financing approval for the user again. This is not only convenient and fast, but also because the financing risk approval process is implemented based on blockchain technology, the transparency of the financing approval result can be guaranteed, and cheating can be avoided.

[0145] The embodiments of this specification adopt the above technical solutions. According to the user's financing risk, available financing products that meet the preset financing conditions for the user are determined. Then, according to the user's operation of selecting the target financing product, relevant orders are generated for the user, making the user's financing product subscription result more reasonable and more in line with the actual situation, which is beneficial to the normal operation of the financing institution's business.

[0146] Figure 3 For the Figure 2 in this specification, it is a swimlane process schematic diagram of the blockchain-based risk assessment method. As Figure 3 shown, the blockchain-based risk assessment process may involve execution entities such as user devices and blockchain systems.

[0147] In the financing risk determination module, in response to the user's financing application operation, the user device sends a first blockchain transaction carrying the financing application information to the blockchain system. After the blockchain system obtains the first blockchain transaction, first, it calls the first type of smart contract with a relatively fast risk identification processing speed, performs risk identification processing based on the financing application information and the first on-chain credit data, obtains the first risk identification result, and determines whether the financing risk level indicated by the first risk identification result is lower than the preset financing risk level. If the financing risk level indicated by the first risk identification result is lower than the preset financing risk level, it calls the third type of smart contract deployed in the blockchain system to perform validity verification on the first risk identification result and obtains the first verification result; if the first verification result meets the first verification passing condition, it determines the user's financing risk according to the first risk identification result; if the financing risk level indicated by the first risk identification result is not lower than the preset financing risk level, it calls the second type of smart contract deployed in the blockchain system to perform risk identification processing based on the financing application information and more comprehensive second on-chain credit data, obtains the second risk identification result, and then calls the third type of smart contract to perform validity verification on the second risk identification result and obtains the second verification result; if the second verification result meets the second verification passing condition, it determines the user's financing risk according to the second risk identification result.

[0148] In the financing product ordering stage, the blockchain system determines the available financing products that the user meets the preset financing conditions according to the user's financing risk, and feeds back the information including the available financing products to the user device, so that the user can select the target financing product from the available financing products according to the display information of the user device, and perform the corresponding ordering operation on the target financing product. In response to the user's ordering operation, the user device sends an eighth blockchain transaction to the blockchain system. After the blockchain system obtains the eighth blockchain transaction, based on the eighth blockchain transaction, it generates an order for the user for the target financing product.

[0149] Based on the same idea, the embodiments of this specification also provide a device corresponding to the above method. Figure 4 For the embodiments of this specification, the corresponding Figure 2 structural schematic diagram of a blockchain-based risk assessment device. As Figure 4 shown, the device may include:

[0150] The first acquisition module 402 is configured to cause the blockchain system to acquire the user's first blockchain transaction; the first blockchain transaction carries the financing application information of the user.

[0151] The first call module 404 is configured to call the first type of smart contract deployed in the blockchain system, perform risk identification processing based on the financing application information and the first on-chain credit data, and obtain the first risk identification result;

[0152] A judgment module 406, configured to judge whether the financing risk level indicated by the first risk identification result is lower than a preset financing risk level;

[0153] A first determination module 408, configured to, when the financing risk level indicated by the first risk identification result is lower than the preset financing risk level, determine the financing risk of the user according to the first risk identification result;

[0154] A second invocation module 410, configured to, when the financing risk level indicated by the first risk identification result is not lower than the preset financing risk level, invoke a second type of smart contract deployed in the blockchain system, and perform risk identification processing according to the financing application information and the user's second on-chain credit data to obtain a second risk identification result; the risk identification processing speed of the second type of smart contract is less than the risk identification processing speed of the first type of smart contract;

[0155] A second determination module 412, configured to determine the financing risk of the user according to the second risk identification result.

[0156] Based on Figure 4 For the device, some specific implementation solutions of the device are further provided in the embodiments of the present specification, and are described below.

[0157] The financing application information of the user may include the identity information of the user; the first on-chain credit data may include on-chain risk list data.

[0158] The first invocation module 410 may specifically be configured to:

[0159] Execute the contract code of the first type of smart contract to obtain a first risk identification result; when the contract code of the first type of smart contract is executed, it is used to compare the identity information of the user with the on-chain risk list data to obtain a comparison result, and generate a first risk identification result according to the comparison result.

[0160] The on-chain risk list data is data in the risk list stored in the blockchain system. The device in the embodiments of the present specification may further include:

[0161] A second acquisition module, configured to cause the blockchain system to acquire a second blockchain transaction; the second blockchain transaction is used to add a plurality of user identity information to the risk list, or the second blockchain transaction is used to indicate that a plurality of user identity information in the risk list has expired.

[0162] An update module, configured to update the risk list according to the second blockchain transaction to obtain updated on-chain risk list data.

[0163] The financing application information of the user may include: the identity information of the user and the pledge information.

[0164] The second calling module may specifically be used for:

[0165] Execute the contract code of the second type of smart contract to obtain a second risk identification result; when the contract code of the second type of smart contract is executed, it is used to obtain the second on-chain credit data of the user stored in the blockchain system according to the identity information of the user, generate an evaluation result for the pledge information according to the second on-chain credit data, and perform risk identification processing according to the evaluation result and the second on-chain credit data to obtain a second risk identification result.

[0166] The second type of smart contract may include at least one of: a first smart contract, a second smart contract, and a third smart contract.

[0167] Among them, the first smart contract is used to perform risk identification processing based on a machine learning model, the second smart contract is used to perform risk identification processing based on a scoring card model, and the third smart contract is used to perform risk identification processing based on a preset policy.

[0168] The first determination module may include:

[0169] A first calling sub-module, which is used to call the third type of smart contract deployed in the blockchain system to verify the effectiveness of the first risk identification result and obtain a first verification result.

[0170] A first determination sub-module, which is used to determine the financing risk of the user according to the first risk identification result if the first verification result meets the first verification passing condition.

[0171] The second determination module may include:

[0172] A second calling sub-module, which is used to call the third type of smart contract to verify the effectiveness of the second risk identification result and obtain a second verification result.

[0173] A second determination sub-module, which is used to determine the financing risk of the user according to the second risk identification result if the second verification result meets the second verification passing condition.

[0174] The first calling sub-module may specifically be used for:

[0175] Call the third type of smart contract to perform security verification on the first type of smart contract and the first on-chain credit data; among them, the first type of smart contract includes a cross-chain smart contract, and the first on-chain credit data includes cross-chain data.

[0176] The second call sub-module can be specifically used to call the third type of smart contract to perform security verification on the second type of smart contract and the credit data on the second chain; wherein, the second type of smart contract includes a cross-chain smart contract, and the credit data on the second chain includes cross-chain data.

[0177] The first call sub-module can be specifically used to call the third type of smart contract to set an invalidation flag for the third risk identification result in the first risk identification result; the third risk identification result is the risk identification result generated by the invalid smart contract in the first type of smart contract;

[0178] The second call sub-module can be specifically used to call the third type of smart contract to set an invalidation flag for the fourth risk identification result in the second risk identification result; the fourth risk identification result is the risk identification result generated by the invalid smart contract in the second type of smart contract.

[0179] The device according to the embodiment of the present specification may further include:

[0180] A third determination module, configured to determine, according to the execution result of the first type of smart contract within a preset time period, the smart contracts in the first type of smart contract that meet the preset invalidation conditions, so as to obtain the invalid smart contracts in the first type of smart contract; or, determine the invalid smart contracts in the first type of smart contract according to the identification information of the invalid smart contracts carried in the received third blockchain transaction.

[0181] A fourth determination module, configured to determine, according to the execution result of the second type of smart contract within a preset time period, the smart contracts in the second type of smart contract that meet the preset invalidation conditions, so as to obtain the invalid smart contracts in the second type of smart contract; or, determine the invalid smart contracts in the second type of smart contract according to the identification information of the invalid smart contracts carried in the received fourth blockchain transaction.

[0182] The device according to the embodiment of the present specification may further include:

[0183] A third acquisition module, configured to acquire a fifth blockchain transaction for deploying a fourth type of smart contract; the contract code of the fourth type of smart contract includes program code for performing calculations corresponding to preset operators.

[0184] A storage module, configured to store the contract code of the fourth type of smart contract into the blockchain system.

[0185] A fourth acquisition module, configured to acquire a sixth blockchain transaction for deploying a target smart contract; the target smart contract includes at least one of the first type of smart contract, the second type of smart contract, and the third type of smart contract. When the target smart contract runs, it calls the contract code of the fourth type of smart contract to execute the calculation corresponding to the preset operator.

[0186] A first response module, configured to deploy the target smart contract in the blockchain system in response to the sixth blockchain transaction.

[0187] The device according to an embodiment of the present specification may further include:

[0188] A fifth acquisition module, configured to acquire a seventh blockchain transaction for changing the target smart contract; the seventh blockchain transaction is used to add a risk control strategy required to be executed by the target smart contract, and the seventh blockchain transaction carries the target operator of the risk control strategy, the left value information of the target operator, and the right value information of the target operator.

[0189] A second response module, configured to change the target smart contract in response to the seventh blockchain transaction to obtain an updated target smart contract; when the updated target smart contract runs, it calls the program code in the fourth type of smart contract for executing the calculation corresponding to the target operator, and generates an execution result for the risk control strategy according to the left value information and the right value information.

[0190] The device according to an embodiment of the present specification may further include:

[0191] A fifth determination module, configured to determine available financing products that the user meets the preset financing conditions according to the financing risk of the user.

[0192] A sixth acquisition module, configured to acquire an eighth blockchain transaction of the user; the eighth blockchain transaction is used to indicate an order for a target financing product among the available financing products.

[0193] A generation module, configured to generate an order of the user for the target financing product based on the eighth blockchain transaction.

[0194] Based on the same idea, an embodiment of the present specification further provides a device corresponding to the above method.

[0195] Figure 5 For the corresponding one provided by an embodiment of the present specification Figure 2 is a schematic structural diagram of a blockchain-based risk assessment device. As Figure 5 shown, the device 500 may include:

[0196] At least one processor 510; and,

[0197] A memory 530 communicatively connected to the at least one processor; wherein,

[0198] The memory 530 stores instructions 520 executable by the at least one processor 510, and when the instructions are executed by the at least one processor 510, the at least one processor 510 is enabled to:

[0199] Obtain a first blockchain transaction of a user; the first blockchain transaction carries financing application information of the user;

[0200] Invoke a first type of smart contract deployed in the blockchain system, perform risk identification processing based on the financing application information and first on-chain credit data, and obtain a first risk identification result;

[0201] Determine whether the financing risk level indicated by the first risk identification result is lower than a preset financing risk level;

[0202] If so, determine the financing risk of the user according to the first risk identification result;

[0203] If not, invoke a second type of smart contract deployed in the blockchain system, perform risk identification processing based on the financing application information and second on-chain credit data of the user, and obtain a second risk identification result; the risk identification processing speed of the second type of smart contract is less than the risk identification processing speed of the first type of smart contract;

[0204] Determine the financing risk of the user according to the second risk identification result.

[0205] Each embodiment in this specification is described in a progressive manner. For the same or similar parts among the embodiments, reference can be made to each other. Each embodiment focuses on the differences from other embodiments. In particular, for Figure 5 the device shown, since it is basically similar to the method embodiment, the description is relatively simple. For the relevant parts, reference can be made to the partial description of the method embodiment.

[0206] In the 1990s, it was obvious to distinguish whether an improvement to a technology was a hardware improvement (e.g., improvement to circuit structures such as diodes, transistors, switches, etc.) or a software improvement (improvement to method flows). However, with the development of technology, many of today's improvements to method flows can be regarded as direct improvements to hardware circuit structures. Almost all designers obtain the corresponding hardware circuit structure by programming the improved method flow into the hardware circuit. Therefore, it cannot be said that an improvement to a method flow cannot be implemented with a hardware entity module. For example, a Programmable Logic Device (PLD) (such as a Field Programmable Gate Array (FPGA)) is such an integrated circuit whose logical function is determined by the user programming the device. Designers can program by themselves to "integrate" a digital character system on a piece of PLD, without having to ask a chip manufacturer to design and fabricate a dedicated integrated circuit chip. Moreover, nowadays, instead of manually fabricating integrated circuit chips, this programming is mostly implemented using "logic compiler" software, which is similar to the software compiler used in program development and writing. The original code before compilation also has to be written in a specific programming language, which is called a Hardware Description Language (HDL). And there is not only one kind of HDL, but many kinds, such as ABEL (Advanced Boolean Expression Language), AHDL (Altera Hardware Description Language), Confluence, CUPL (Cornell University Programming Language), HDCal, JHDL (Java Hardware Description Language), Lava, Lola, MyHDL, PALASM, RHDL (Ruby Hardware Description Language), etc. Currently, the most commonly used ones are VHDL (Very-High-Speed Integrated Circuit Hardware Description Language) and Verilog. Those skilled in the art should also be aware that by simply performing a little logical programming on the method flow with the above-mentioned several hardware description languages and programming it into an integrated circuit, it is easy to obtain the hardware circuit that implements the logical method flow.

[0207] The controller can be implemented in any suitable manner. For example, the controller can take the form of, for example, a microprocessor or a processor and a computer-readable medium storing computer-readable program code (such as software or firmware) executable by the (micro)processor, logic gates, switches, an application specific integrated circuit (ASIC), a programmable logic controller, and an embedded microcontroller. Examples of the controller include, but are not limited to, the following microcontrollers: ARC625D, Atmel AT91SAM, Microchip PIC18F26K20, and Silicone Labs C8051F320. The memory controller can also be implemented as part of the control logic of the memory. Those skilled in the art also know that in addition to implementing the controller in the form of pure computer-readable program code, it is entirely possible to logically program the method steps to enable the controller to be implemented in the form of logic gates, switches, application specific integrated circuits, programmable logic controllers, embedded microcontrollers, etc. to achieve the same function. Therefore, such a controller can be considered a hardware component, and the devices included therein for implementing various functions can also be regarded as the structures within the hardware component. Or even, the devices for implementing various functions can be regarded as either software modules for implementing the method or structures within the hardware component.

[0208] The systems, devices, modules, or units illustrated in the above embodiments can be specifically implemented by computer chips or entities, or by products with certain functions. A typical implementation device is a computer. Specifically, the computer can be, for example, a personal computer, a laptop computer, a cellular phone, a camera phone, a smart phone, a personal digital assistant, a media player, a navigation device, an email device, a game console, a tablet computer, a wearable device, or any combination of these devices.

[0209] For the convenience of description, when describing the above devices, they are described separately as various units according to their functions. Of course, when implementing the present application, the functions of each unit can be implemented in the same or multiple software and / or hardware.

[0210] Those skilled in the art should understand that the embodiments of the present invention can be provided as a method, a system, or a computer program product. Therefore, the present invention can take the form of a completely hardware embodiment, a completely software embodiment, or an embodiment combining software and hardware aspects. Moreover, the present invention can take the form of a computer program product implemented on one or more computer-usable storage media (including but not limited to disk memories, CD-ROMs, optical memories, etc.) containing computer-usable program code.

[0211] The present invention is described with reference to flowchart illustrations and / or block diagrams of methods, apparatus (systems), and computer program products according to embodiments of the invention. It should be understood that each flow and / or block of the flowchart illustrations and / or block diagrams, and combinations of flows and / or blocks in the flowchart illustrations and / or block diagrams, can be implemented by computer program instructions. These computer program instructions may be provided to a processor of a general purpose computer, special purpose computer, embedded processor, or other programmable data processing apparatus to produce a machine, such that the instructions executed by the processor of the computer or other programmable data processing apparatus create means for implementing the functions specified in the flowchart flow or flows and / or block or blocks. Figure 1 in a flow or flows and / or block or blocks Figure 1 or means for implementing the functions specified in a block or blocks.

[0212] These computer program instructions may also be stored in a computer-readable memory that can direct a computer or other programmable data processing apparatus to function in a particular manner, such that the instructions stored in the computer-readable memory produce an article of manufacture including instruction means that implement the functions specified in the flowchart flow or flows and / or block or blocks. Figure 1 in a flow or flows and / or block or blocks Figure 1 or means for implementing the functions specified in a block or blocks.

[0213] These computer program instructions may also be loaded onto a computer or other programmable data processing apparatus to cause a series of operational steps to be performed on the computer or other programmable apparatus to produce a computer-implemented process, such that the instructions executed on the computer or other programmable apparatus provide steps for implementing the functions specified in the flowchart flow or flows and / or block or blocks. Figure 1 in a flow or flows and / or block or blocks Figure 1 or means for implementing the functions specified in a block or blocks.

[0214] In a typical configuration, a computing device includes one or more processors (CPUs), an input / output interface, a network interface, and memory.

[0215] The memory may include non-permanent memory in the form of computer-readable media, random access memory (RAM), and / or non-volatile memory, such as read only memory (ROM) or flash memory (flash RAM). The memory is an example of computer-readable media.

[0216] Computer readable media include permanent and non-permanent, removable and non-removable media that can be implemented by any method or technology to store information. Information can be computer readable instructions, data structures, program modules 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 disk read-only memory (CD-ROM), digital versatile disk (DVD) or other optical storage, magnetic cassettes, magnetic disk storage or other magnetic storage devices or any other non-transmission media that can be used to store information that can be accessed by a computing device. As defined herein, computer readable media does not include temporary computer readable media (transitory media), such as modulated data signals and carrier waves.

[0217] It should also be noted that the terms "include", "comprises" or any other variations thereof are intended to cover non-exclusive inclusion, so that a process, method, commodity or device including a series of elements includes not only those elements, but also other elements not explicitly listed, or also includes elements inherent to such process, method, commodity or device. In the absence of more restrictions, the elements defined by the sentence "comprises a ..." do not exclude the existence of other identical elements in the process, method, commodity or device including the elements.

[0218] Those skilled in the art will appreciate that the embodiments of the present application may be provided as methods, systems or computer program products. Therefore, the present application may adopt the form of a complete hardware embodiment, a complete software embodiment or an embodiment in combination with software and hardware. Moreover, the present application may adopt the form of a computer program product implemented on one or more computer-usable storage media (including but not limited to disk storage, CD-ROM, optical storage, etc.) that contain computer-usable program code.

[0219] The present application may be described in the general context of computer-executable instructions executed by a computer, such as program modules. Generally, program modules include routines, programs, objects, components, data structures, etc. that perform specific tasks or implement specific abstract data types. The present application may also be practiced in distributed computing environments where tasks are performed by remote processing devices connected through a communication network. In a distributed computing environment, program modules may be located in local and remote computer storage media, including storage devices.

[0220] The above are only embodiments of the present application and are not intended to limit the present application. For those skilled in the art, various modifications and changes can be made to the present application. Any modification, equivalent replacement, improvement, etc. made within the spirit and principle of the present application shall be included within the scope of the claims of the present application.

Claims

1. A risk assessment method based on blockchain, including: The blockchain system obtains the user's first blockchain transaction; The first blockchain transaction carries the user's financing application information; The financing application information includes at least one of the user's identity information, collateral information, expected loan amount, and user-defined information; Invoke the first type of smart contract deployed in the blockchain system, and determine the user category of the user according to the financing application information and the first on-chain credit data; the user category includes trusted users and suspicious users; The first on-chain credit data includes on-chain risk list data; Perform risk identification processing based on the user category to obtain a first risk identification result; Judge whether the financing risk degree indicated by the first risk identification result is lower than the preset financing risk degree; If so, determine the financing risk of the user according to the first risk identification result; If not, invoke the second type of smart contract deployed in the blockchain system, and generate an appraisal result for the collateral information of the user according to the financing application information and the user's second on-chain credit data; Perform risk identification processing according to the appraisal result and the second on-chain credit data to obtain a second risk identification result; The risk identification processing speed of the second type of smart contract is less than the risk identification processing speed of the first type of smart contract; The second on-chain credit data includes at least one of the financing product orders completed by the user in the blockchain system, the information on the user's business transactions with other users, the user financing risk data feedback by the credit reference center recognized by the financing institution, the off-chain credit data of the user obtained based on the oracle in the blockchain system, and cross-chain data; Determine the financing risk of the user according to the second risk identification result.

2. The method according to claim 1, wherein the step of invoking the first type of smart contract deployed in the blockchain system and determining the user category of the user according to the financing application information and the first on-chain credit data specifically includes: Execute the contract code of the first type of smart contract to determine the user category of the user; When the contract code of the first type of smart contract is executed, it is used to compare the user's identity information with the on-chain risk list data to obtain a comparison result, and determine the user category of the user according to the comparison result.

3. The method according to claim 2, wherein the on-chain risk list data is the data in the risk list stored in the blockchain system, and the method further includes: The blockchain system obtains a second blockchain transaction; The second blockchain transaction is used to add the identity information of several users to the risk list, or the second blockchain transaction is used to indicate that the identity information of several users in the risk list has become invalid; Update the risk list according to the second blockchain transaction to obtain the updated on-chain risk list data.

4. The method according to claim 1, wherein the second type of smart contract deployed in the blockchain system is called, and an evaluation result of the collateral information for the user is generated according to the financing application information and the second on-chain credit data of the user ； Risk identification processing is performed according to the evaluation result and the second on-chain credit data to obtain a second risk identification result, which specifically includes: Execute the contract code of the second type of smart contract to obtain a second risk identification result; When the contract code of the second type of smart contract is executed, it is used to obtain the second on-chain credit data of the user stored in the blockchain system according to the identity information of the user, generate an evaluation result of the collateral information according to the second on-chain credit data, and perform risk identification processing according to the evaluation result and the second on-chain credit data to obtain a second risk identification result.

5. The method according to claim 4, wherein the second type of smart contract comprises: At least one of a first smart contract, a second smart contract, and a third smart contract; Wherein, the first smart contract is used to perform risk identification processing based on a machine learning model, the second smart contract is used to perform risk identification processing based on a scoring card model, and the third smart contract is used to perform risk identification processing based on a preset policy.

6. The method according to claim 1, wherein determining the financing risk of the user according to the first risk identification result specifically comprises: Call the third type of smart contract deployed in the blockchain system to perform validity verification on the first risk identification result to obtain a first verification result; If the first verification result meets the first verification passing condition, determine the financing risk of the user according to the first risk identification result; Determining the financing risk of the user according to the second risk identification result specifically includes: Call the third type of smart contract to perform validity verification on the second risk identification result to obtain a second verification result; If the second verification result meets the second verification passing condition, determine the financing risk of the user according to the second risk identification result.

7. The method according to claim 6, wherein calling the third type of smart contract deployed in the blockchain system to perform validity verification on the first risk identification result specifically comprises: Call the third type of smart contract to perform security verification on the first type of smart contract and the first on-chain credit data; wherein, the first type of smart contract includes a cross-chain smart contract, and the first on-chain credit data includes cross-chain data; Calling the third type of smart contract to perform validity verification on the second risk identification result specifically includes: Call the third type of smart contract to perform security verification on the second type of smart contract and the second on-chain credit data; wherein, the second type of smart contract includes a cross-chain smart contract, and the second on-chain credit data includes cross-chain data.

8. The method according to claim 6 or 7, wherein calling the third type of smart contract deployed in the blockchain system to perform validity verification on the first risk identification result specifically comprises: Invoke the third type of smart contract and set an invalidation flag for the third risk identification result in the first risk identification result; The third risk identification result is the risk identification result generated by the invalid smart contract in the first type of smart contract; The step of invoking the third type of smart contract to perform validity verification on the second risk identification result specifically includes: Invoke the third type of smart contract and set an invalidation flag for the fourth risk identification result in the second risk identification result; The fourth risk identification result is the risk identification result generated by the invalid smart contract in the second type of smart contract.

9. The method according to claim 8, before setting the invalidation flag for the third risk identification result in the first risk identification result, it also includes: Determine the smart contracts in the first type of smart contract that meet the preset invalidation conditions according to the execution results of the first type of smart contract within a preset time period, and obtain the invalid smart contracts in the first type of smart contract; Or, Determine the invalid smart contracts in the first type of smart contract according to the identification information of the invalid smart contracts carried in the third blockchain transaction received; Before setting the invalidation flag for the fourth risk identification result in the second risk identification result, it also includes: Determine the smart contracts in the second type of smart contract that meet the preset invalidation conditions according to the execution results of the second type of smart contract within a preset time period, and obtain the invalid smart contracts in the second type of smart contract; or, Determine the invalid smart contracts in the second type of smart contract according to the identification information of the invalid smart contracts carried in the fourth blockchain transaction received.

10. The method according to claim 6, before invoking the first type of smart contract deployed in the blockchain system, it also includes: Obtain the fifth blockchain transaction for deploying the fourth type of smart contract; The contract code of the fourth type of smart contract contains program code for performing calculations corresponding to preset operators; Store the contract code of the fourth type of smart contract in the blockchain system; Obtain the sixth blockchain transaction for deploying the target smart contract; The target smart contract includes at least one of the first type of smart contract, the second type of smart contract, and the third type of smart contract. When the target smart contract runs, it invokes the contract code of the fourth type of smart contract to perform calculations corresponding to the preset operators; In response to the sixth blockchain transaction, deploy the target smart contract in the blockchain system.

11. The method according to claim 10, after deploying the target smart contract in the blockchain system, it also includes: Obtain the seventh blockchain transaction for changing the target smart contract; The seventh blockchain transaction is used to add risk control strategies required to be executed by the target smart contract. The seventh blockchain transaction carries the target operator of the risk control strategy, the left value information of the target operator, and the right value information of the target operator; In response to the seventh blockchain transaction, the target smart contract is changed to obtain an updated target smart contract; when the updated target smart contract runs, by invoking the program code in the fourth type of smart contract for performing the calculation corresponding to the target operator, according to the left value information and the right value information, an execution result for the risk control strategy is generated.

12. The method according to claim 1, after determining the financing risk of the user, further comprises: Determining available financing products that the user meets the preset financing conditions according to the financing risk of the user; Obtaining an eighth blockchain transaction of the user; The eighth blockchain transaction is used to indicate subscribing to a target financing product among the available financing products; Generating an order for the target financing product by the user based on the eighth blockchain transaction.

13. A blockchain-based risk assessment device, comprising: A first acquisition module, configured to enable a blockchain system to acquire a first blockchain transaction of a user; The first blockchain transaction carries financing application information of the user; The financing application information includes at least one of the user's identity information, collateral information, expected loan amount, and user-defined information; A first invocation module, configured to invoke a first type of smart contract deployed in the blockchain system, and determine the user category of the user according to the financing application information and first on-chain credit data; the user category includes a trusted user and a suspicious user; The first on-chain credit data includes on-chain risk list data; A risk identification module, configured to perform risk identification processing based on the user category to obtain a first risk identification result; A judgment module, configured to judge whether the financing risk level indicated by the first risk identification result is lower than a preset financing risk level; A first determination module, configured to, when the financing risk level indicated by the first risk identification result is lower than the preset financing risk level, determine the financing risk of the user according to the first risk identification result; A second invocation module, configured to, when the financing risk level indicated by the first risk identification result is not lower than the preset financing risk level, invoke a second type of smart contract deployed in the blockchain system, and generate an evaluation result for the collateral information of the user according to the financing application information and the second on-chain credit data of the user; Performing risk identification processing according to the evaluation result and the second on-chain credit data to obtain a second risk identification result; The risk identification processing speed of the second type of smart contract is less than the risk identification processing speed of the first type of smart contract; The second on-chain credit data includes at least one of: financing product orders completed by the user in the blockchain system, information on the user's business transactions with other users, user financing risk data feedback by a credit reference center recognized by the financing institution, off-chain credit data of the user obtained based on an oracle in the blockchain system, and cross-chain data; A second determination module, configured to determine the financing risk of the user according to the second risk identification result.

14. The device according to claim 13, wherein the first invocation module is specifically configured to: Execute the contract code of the first type of smart contract to determine the user category of the user; when the contract code of the first type of smart contract is executed, it is used to compare the identity information of the user with the on-chain risk list data to obtain a comparison result, and determine the user category of the user according to the comparison result.

15. The device according to claim 14, wherein the on-chain risk list data is the data in the risk list stored in the blockchain system, and the device further comprises: A second acquisition module, configured to cause the blockchain system to acquire a second blockchain transaction; The second blockchain transaction is used to add the identity information of several users to the risk list, or the second blockchain transaction is used to identify that the identity information of several users in the risk list has become invalid; An update module, configured to update the risk list according to the second blockchain transaction to obtain updated on-chain risk list data.

16. The device according to claim 13, wherein the second invocation module is specifically configured to: Execute the contract code of the second type of smart contract to obtain a second risk identification result; when the contract code of the second type of smart contract is executed, it is used to obtain the second on-chain credit data of the user stored in the blockchain system according to the identity information of the user, generate an evaluation result for the pledge information according to the second on-chain credit data, and perform risk identification processing according to the evaluation result and the second on-chain credit data to obtain a second risk identification result.

17. The second type of smart contract according to claim 16 comprises: At least one of a first smart contract, a second smart contract, and a third smart contract; Wherein, the first smart contract is used to perform risk identification processing based on a machine learning model, the second smart contract is used to perform risk identification processing based on a scoring card model, and the third smart contract is used to perform risk identification processing based on a preset policy.

18. The device according to claim 13, wherein the first determination module comprises: A first invocation sub-module, configured to invoke a third type of smart contract deployed in the blockchain system to perform validity verification on the first risk identification result to obtain a first verification result; A first determination sub-module, configured to determine the financing risk of the user according to the first risk identification result if the first verification result meets the first verification pass condition; The second determination module comprises: A second invocation sub-module, configured to invoke the third type of smart contract to perform validity verification on the second risk identification result to obtain a second verification result; A second determination sub-module, configured to determine the financing risk of the user according to the second risk identification result if the second verification result meets the second verification pass condition.

19. The device according to claim 18, wherein the first invocation sub-module is specifically configured to: Invoke the third type of smart contract to perform security verification on the first type of smart contract and the first on-chain credit data; Wherein, The first type of smart contract includes cross-chain smart contracts, and the first on-chain credit data includes cross-chain data; The second call sub-module is specifically configured to call the third type of smart contract to perform security verification on the second type of smart contract and the second on-chain credit data; wherein, the second type of smart contract includes cross-chain smart contracts, and the second on-chain credit data includes cross-chain data.

20. The device according to claim 18 or 19, wherein the first call sub-module is specifically configured to call the third type of smart contract to set an invalidation flag for the third risk identification result in the first risk identification result; the third risk identification result is the risk identification result generated by the invalid smart contract in the first type of smart contract; The second call sub-module is specifically configured to call the third type of smart contract to set an invalidation flag for the fourth risk identification result in the second risk identification result; The fourth risk identification result is the risk identification result generated by the invalid smart contract in the second type of smart contract.

21. The device according to claim 20, further comprising: A third determination module, configured to: Determine the smart contracts in the first type of smart contract that meet the preset invalidation conditions according to the execution results of the first type of smart contract within a preset time period, so as to obtain the invalid smart contracts in the first type of smart contract; Or, Determine the invalid smart contracts in the first type of smart contract according to the identification information of the invalid smart contracts carried in the received third blockchain transaction; A fourth determination module, configured to: Determine the smart contracts in the second type of smart contract that meet the preset invalidation conditions according to the execution results of the second type of smart contract within a preset time period, so as to obtain the invalid smart contracts in the second type of smart contract; or, Determine the invalid smart contracts in the second type of smart contract according to the identification information of the invalid smart contracts carried in the received fourth blockchain transaction.

22. The device according to claim 18, further comprising: A third acquisition module, configured to acquire a fifth blockchain transaction for deploying a fourth type of smart contract; The contract code of the fourth type of smart contract includes program code for performing calculations corresponding to preset operators; A storage module, configured to store the contract code of the fourth type of smart contract into the blockchain system; A fourth acquisition module, configured to acquire a sixth blockchain transaction for deploying a target smart contract; The target smart contract includes at least one of the first type of smart contract, the second type of smart contract, and the third type of smart contract. When the target smart contract runs, it calls the contract code of the fourth type of smart contract to perform calculations corresponding to the preset operators; A first response module, configured to respond to the sixth blockchain transaction and deploy the target smart contract in the blockchain system.

23. The device according to claim 22, further comprising: A fifth acquisition module, configured to acquire a seventh blockchain transaction for changing the target smart contract; The seventh blockchain transaction is used to add a risk control strategy required for the target smart contract. The seventh blockchain transaction carries the target operator of the risk control strategy, the left value information of the target operator, and the right value information of the target operator; A second response module, configured to respond to the seventh blockchain transaction, change the target smart contract, and obtain an updated target smart contract; when the updated target smart contract runs, by calling the program code in the fourth type of smart contract for executing the calculation corresponding to the target operator, according to the left value information and the right value information, generate an execution result for the risk control strategy.

24. The device according to claim 13, further comprising: A fifth determination module, configured to determine available financing products that the user meets the preset financing conditions according to the financing risk of the user; A sixth acquisition module, configured to acquire an eighth blockchain transaction of the user; the eighth blockchain transaction is used to indicate an order for a target financing product among the available financing products; A generation module, configured to generate an order for the target financing product by the user based on the eighth blockchain transaction.

25. A blockchain-based risk assessment device, comprising: At least one processor; And, A memory communicatively connected to the at least one processor; wherein, The memory stores instructions executable by the at least one processor, and the instructions are executed by the at least one processor to enable the at least one processor to: Acquire a first blockchain transaction of a user; the first blockchain transaction carries financing application information of the user; the financing application information includes at least one of the user's identity information, collateral information, expected loan amount, and user-defined information; Call a first type of smart contract deployed in the blockchain system, and determine the user category of the user according to the financing application information and first on-chain credit data; the user category includes a trusted user and a suspicious user; the first on-chain credit data includes on-chain risk list data; Perform risk identification processing based on the user category to obtain a first risk identification result; Judge whether the financing risk degree indicated by the first risk identification result is lower than a preset financing risk degree; If so, determine the financing risk of the user according to the first risk identification result; If not, then call the second type of smart contract deployed in the blockchain system, generate an appraisal result for the collateral information of the user according to the financing application information and the user's second on-chain credit data; perform risk identification processing based on the appraisal result and the second on-chain credit data to obtain a second risk identification result; the risk identification processing speed of the second type of smart contract is less than the risk identification processing speed of the first type of smart contract; the second on-chain credit data includes at least one of: financing product orders completed by the user in the blockchain system, information on the user's business transactions with other users, user financing risk data feedback by a credit reference center recognized by the financing institution, off-chain credit data of the user obtained based on an oracle stored in the blockchain system, and cross-chain data; Determine the financing risk of the user according to the second risk identification result.

Images