Block chain-based lease user credit risk assessment method and system

Abstract

The invention discloses a leasing user credit risk assessment method and system based on a block chain, and relates to the technical field of block chain management. The leasing user credit risk assessment method based on the block chain comprises the following steps: carrying out block chain calling delay assessment; evaluating data write-in delay; and performing off-chain transmission delay evaluation. According to the method, the stability delay evaluation is performed based on the link transmission data volume, meanwhile, according to the stability delay evaluation result, whether to perform block parameter optimization or not is judged, data write-in delay evaluation is performed based on write-in delay data, whether to perform block chain data call optimization or not is judged, and under-chain transmission delay evaluation is performed based on transmission delay data; and meanwhile, whether data byte number optimization is carried out or not is judged, so that the effect of improving the reliability of the lease user credit rating data transmission risk assessment is achieved, and the problem of low reliability of the lease user credit rating data transmission risk assessment caused by corresponding transmission delay in the data chaining process of the block chain in the prior art is solved.

Description

Technical Field

[0001] This invention relates to the field of blockchain management technology, and in particular to a blockchain-based method and system for assessing the credit risk of leasing users. Background Technology

[0002] Against the backdrop of intensifying industry competition, enterprises tend to shift non-core assets (such as office equipment) to leasing models to reduce fixed costs and improve cash flow. Leasing platforms collect relevant data on leasing users (such as lease duration, rent payment status, and default records) from multiple channels through oracles and securely and reliably transmit this data to the blockchain. The blockchain ensures the reliability and immutability of the data source. The collected data is then cleaned, standardized, and noise and redundancy are removed. Key features (such as lease frequency, lease duration, and equipment type) are extracted, and methods such as the analytic hierarchy process (AHP) or entropy weight method are used to assign corresponding weights to each key feature based on its impact on credit risk. A credit risk assessment model is then constructed using a decision tree algorithm. The processed data is input into the model to train it. A consortium blockchain is used, with leasing platforms, financial institutions, and regulatory agencies participating as nodes in the maintenance of the blockchain network. New user data is input into the decision tree algorithm model to assess the credit risk of leasing users in real time and dynamically update users' credit scores based on the assessment results, providing decision support for the leasing platform. The assessment process and results are also stored on the blockchain for evidence.

[0003] For example, the invention patent with announcement number CN110826903B discloses a blockchain-based enterprise reputation assessment method, which includes: standardizing the enterprise reputation data uploaded to the blockchain based on smart contract technology and packaging it into an initial block; evaluating the enterprise reputation data in the initial block based on a dynamic weighted voting consensus mechanism; if it meets the model assessment requirements, generating a new block and adding it to the blockchain; establishing a standardized enterprise blockchain reputation assessment model based on the blockchain; and obtaining the reputation value of the enterprise to be assessed in the enterprise blockchain reputation assessment model.

[0004] For example, the invention patent with publication number CN115130883A discloses a blockchain-based address credit risk assessment method and system, which includes: monitoring blacklisted addresses across the entire network, parsing blacklisted addresses to establish an address blacklist database, and deploying blacklisted addresses as decentralized blacklisted blockchain nodes, while simultaneously establishing server nodes; requesting the server nodes to obtain blockchain transaction data, comparing the transaction data with the server nodes or blacklisted blockchain nodes to obtain abnormal transaction addresses; and based on the abnormal transaction addresses, applying machine learning models to analyze the upstream and downstream blockchain nodes of transactions related to the abnormal transaction addresses, and performing transaction risk assessment modeling.

[0005] The above-mentioned technology has at least the following technical problems: In existing technologies, user rental risk assessment systems rely on data stored on the blockchain. This data must be uploaded to the blockchain through a consensus mechanism before it can be read. The consensus mechanism requires nodes to reach an agreement through computation, voting, or signing. Due to differences in the number of nodes, network bandwidth, and computing power, this process cannot be completed instantly and must take time. Data transmission from the source node to the target node often involves multiple intermediate nodes. As the number of nodes increases, the data transmission path becomes more complex, leading to a longer overall transmission time. Therefore, during this time, data cannot be transmitted to the target node in a timely manner, resulting in a transmission delay from the source node to the target node. If the assessment system initiates a request to retrieve user credit data stored on the blockchain to provide a basis for rental decisions, the target node may not have fully received the latest user credit information. This means the time required for transmission from the source node to the target node is longer, affecting the accuracy of the data correction mechanism in processing the credit assessment results. This presents a problem of low reliability in the data transmission risk assessment of rental users' credit ratings due to transmission delays during the data uploading process. Summary of the Invention

[0006] This application provides a blockchain-based method and system for assessing the credit risk of rental users. This solves the problem in the prior art where the reliability of data transmission risk assessment of rental user credit ratings is low due to transmission delays during the data uploading process. It improves the reliability of data transmission risk assessment of rental user credit ratings during the data uploading process.

[0007] This application provides a blockchain-based method for assessing the credit risk of rental users, comprising the following steps: Step 1, during the call phase of the established consortium blockchain network, a data call latency assessment is performed on the process of calling rental user credit rating data, and it is determined whether there is a need for block parameter optimization; Step 2, during the data writing phase, based on the acquired write latency data, a data write latency assessment is performed on the process of writing qualified data by rental users, and it is determined whether there is a need for blockchain data call optimization; Step 3, during the off-chain transmission phase, based on the acquired transmission latency data, an off-chain transmission latency assessment is performed on the process of writing qualified data by rental users, and it is determined whether there is a need for data byte count optimization.

[0008] This application provides a blockchain-based credit risk assessment system for rental users, including: a data call latency assessment module, a data write latency assessment module, and an off-chain transmission latency assessment module. The data call latency assessment module assesses the data call latency of the rental user's credit rating data during the call phase of the established consortium blockchain network, and simultaneously determines whether there is a need for block parameter optimization. The data write latency assessment module assesses the data write latency of the rental user's process of writing qualified data based on the acquired write latency data during the data write phase, and simultaneously determines whether there is a need for blockchain data call optimization. The off-chain transmission latency assessment module assesses the off-chain transmission latency of the rental user's process of writing qualified data based on the acquired transmission latency data during the off-chain transmission phase, and simultaneously determines whether there is a need for data byte count optimization.

[0009] One or more technical solutions provided in the embodiments of this application have at least the following technical effects or advantages: 1. Stability latency is assessed by evaluating the amount of data transmitted through the link. Based on the stability latency assessment results, it is determined whether to optimize block parameters to improve the data throughput of the link and reduce the pressure of single data transmission. Then, data write latency is assessed based on write latency data, and it is determined whether to optimize blockchain data calls to avoid frequent blockchain calls under high system load, reduce redundant calls, and reduce response waiting time. Finally, off-chain transmission latency is assessed based on transmission latency data, and it is determined whether to optimize the number of data bytes to reduce the demand on blockchain network bandwidth, transmit more effective data at the same bandwidth cost, and reduce transmission latency. This improves the reliability of data transmission risk assessment for the credit rating of leasing users.

[0010] 2. By comparing the obtained oracle data fetching frequency, data consensus execution time, and consensus verification count with the preset write latency data in the database at the end of the data write latency evaluation period, this method introduces write latency correction values ​​to correct the results of each difference comparison analysis. The results of each correction are then coupled and calculated to obtain the data write latency evaluation value. Compared with existing technologies that rely on only a single indicator affecting data write latency for evaluation, such as average write latency, this method uses multi-dimensional attribution to quickly identify the problem dimensions causing the latency. By continuously comparing and analyzing the deviation trend, the correction values ​​are dynamically updated, thereby reducing the impact of data write latency on the corresponding transmission delay in the consortium blockchain during the data on-chain process.

[0011] 3. By comparing the obtained data format conversion time, data packet transmission delay fluctuation value, and weighted score calculation time with the preset transmission delay data in the database at the end of the off-chain transmission delay evaluation period, a difference analysis is performed. At the same time, a transmission delay data correction value is introduced to correct the difference analysis results of each difference. The difference results of each correction are coupled and calculated to obtain the off-chain transmission delay evaluation value. Compared with the existing technology that relies on static thresholds and cannot adapt to the fluctuations of the consortium blockchain network or changes in node load, this method introduces correction values ​​to adjust the difference analysis results in real time, flexibly respond to fluctuations, and thus reduce the impact of data transmission delay on the corresponding transmission delay in the consortium blockchain during the data uplink process. Attached Figure Description

[0012] Figure 1 A flowchart illustrating the blockchain-based rental user credit risk assessment method provided in this application embodiment; Figure 2 A logical framework diagram of the blockchain-based rental user credit risk assessment method provided in the embodiments of this application; Figure 3 A flowchart for blockchain call latency evaluation provided in this application embodiment; Figure 4 A flowchart for evaluating data writing latency provided in this application embodiment; Figure 5 A flowchart for evaluating off-chain transmission delay provided in an embodiment of this application; Figure 6 This is a schematic diagram of the structure of a blockchain-based rental user credit risk assessment system provided in an embodiment of this application. Detailed Implementation

[0013] This application provides a blockchain-based method and system for assessing the credit risk of rental users. It addresses the problem in existing technologies where transmission delays during data upload lead to low reliability in assessing the credit risk of rental users. The method utilizes a data call latency assessment module to evaluate the latency of data access during the onboarding phase of the consortium blockchain network, simultaneously determining if block parameter optimization is needed. Then, a data write latency assessment module evaluates the write latency of qualified data access during the data write phase based on acquired write latency data, again determining if blockchain data call optimization is required. Finally, an off-chain transmission latency assessment module evaluates the off-chain transmission latency of qualified data access during the off-chain transmission phase based on acquired transmission latency data, simultaneously determining if data byte count optimization is needed. This approach improves the reliability of the credit risk assessment of rental users and resolves the issue of low reliability caused by transmission delays during data upload.

[0014] The technical solution in this application aims to address the problem of low reliability in data transmission risk assessment of rental user credit ratings due to transmission delays during the data uploading process in the blockchain. The overall approach is as follows: Stability latency is assessed based on the amount of data transmitted through the link. The results of the stability latency assessment determine whether to optimize block parameters. Then, data write latency is assessed based on write latency data, and the results determine whether to optimize blockchain data calls. Finally, off-chain transmission latency is assessed based on transmission latency data, and the results determine whether to optimize the number of data bytes. This approach improves the reliability of data transmission risk assessment for the corresponding rental user credit rating during the data uploading process.

[0015] To better understand the above technical solutions, the following will provide a detailed explanation of the technical solutions in conjunction with the accompanying drawings and specific implementation methods.

[0016] like Figure 1The diagram shows a flowchart of a blockchain-based credit risk assessment method for rental users provided in this application embodiment. The blockchain-based credit risk assessment method for rental users provided in this application embodiment includes the following steps: Step 1, during the constructed consortium blockchain network call phase, a data call latency assessment is performed on the process of calling rental user credit rating data. Simultaneously, it is determined whether there is a need for block parameter optimization. The data call latency assessment measures the impact of the amount of data transmitted in the link during the consortium blockchain network call phase on the corresponding transmission delay during the data upload process on the blockchain. Block parameter optimization refers to reducing the blockchain call latency risk by adjusting the block size and block generation time. Step 2, during the data writing phase, data is written based on the acquired write latency data to the process of writing qualified data for rental users. The first step involves a latency assessment, which assesses whether there is a need for blockchain data call optimization. Data write latency assessment measures the impact of delayed data writes on the corresponding transmission delays during the data uploading process. Blockchain data call optimization involves adjusting the number of concurrent calls and the data readjustment frequency to reduce the risk of write latency. The second step, in the off-chain transmission phase, assesses the off-chain transmission latency of qualified data written by the leasing user based on the acquired transmission latency data. Simultaneously, it determines whether there is a need for data byte count optimization. Off-chain transmission latency assessment measures the impact of delayed data transmits on the corresponding transmission delays during the data uploading process. Data byte count optimization involves adjusting the data packet size to reduce the risk of off-chain transmission latency.

[0017] like Figure 2 The diagram shown is a logical framework diagram of the blockchain-based rental user credit risk assessment method provided in this application embodiment. The specific design logic is as follows: First, the consortium blockchain network call stage is evaluated, and the entire process is divided into three stages: consortium blockchain network call, data writing, and off-chain transmission. The latency issues of each stage are accurately located. Latency evaluation is performed in the data call and writing stages to ensure the timeliness and accuracy of rental user credit rating data and qualified data. Through off-chain transmission latency evaluation and byte count optimization, the integrity and efficiency of data in the off-chain transmission process are ensured, reducing data loss or errors caused by transmission problems. The phased evaluation and optimization avoids redundant operations that may be caused by global optimization and improves resource utilization efficiency.

[0018] like Figure 3As shown in the flowchart of the blockchain call latency evaluation provided in this application embodiment, the specific design logic is as follows: First, in the call phase of the constructed consortium blockchain network, the call process of the rental user's credit rating data is evaluated for data call latency against the consortium blockchain network to obtain the data call latency evaluation result. Based on the data call latency evaluation result, it is determined whether there is a need for block parameter optimization. If the data call latency evaluation result shows that there is such a need, the block parameter optimization operation is immediately executed; if the data call latency evaluation result shows that there is no such need, the data writing phase is evaluated.

[0019] Furthermore, to determine if there is a need for block parameter optimization, the specific process is as follows: Determine the numerical relationship between the acquired link transmission data volume and the preset link transmission data volume in the database. If the acquired link transmission data volume is not less than the preset link transmission data volume, the data call is considered qualified. Simultaneously, the qualified rental user credit rating data is recorded as qualified rental call data and enters the data writing stage. The link transmission data volume is used to quantify the data transmission rate of the consortium blockchain communication link in the acquired rental user credit rating data blockchain. If the acquired link transmission data volume is less than the preset link transmission data volume, the data call is considered unqualified, and block parameter optimization is performed. The link transmission data volume is used to quantify the amount of data transmitted through the consortium blockchain communication link, and is used to measure the speed of data transmission in the consortium blockchain network.

[0020] The block parameter optimization process involves the following steps: First, based on the acquired link transmission data volume deviation, a block size adjustment value is mapped into the database. This value is used to prompt smart contracts in the consortium blockchain to adjust the block size to reduce data transmission pressure within the consortium blockchain network. Second, based on the acquired link transmission data volume deviation, a block generation time extension is mapped into the database. This extension is used to prompt smart contracts in the consortium blockchain to improve transaction processing speed of network nodes. The link transmission data volume deviation represents the absolute value of the difference between the acquired link transmission data volume at the end of the data call latency assessment period and the preset link transmission data volume. The preset link transmission data volume is represented by the average of the corresponding link transmission data volumes at the end of historical consortium blockchain network call phases in the database. If the re-acquired link transmission data volume after block parameter optimization is not less than the preset link transmission data volume, the block parameter optimization is complete, and the data writing phase begins. Otherwise, it is determined that there is a transmission latency risk in the consortium blockchain communication link, and a communication link latency risk warning is issued. Block parameter optimization includes block size optimization and block generation time optimization.

[0021] In this embodiment, the consortium blockchain is a specific type of blockchain that can quickly complete data storage and verification. Its transaction processing speed can meet the real-time requirements of credit risk assessment in leasing businesses. The obtained block size adjustment value and block generation time extension are used as inputs to the least squares linear regression algorithm. By minimizing the sum of squared errors between the predicted and actual values, the linear relationship between the link transmission data volume deviation and the block size and block size adjustment value, and between the link transmission data volume deviation and the block generation time and block generation time extension value are found. The block size adjustment result and block generation time result are output, thereby accelerating the speed at which nodes synchronize user credit rating data, ensuring that data updates can be quickly propagated to each node, and improving data quality and system performance.

[0022] This example automatically adjusts block parameters based on the real-time consortium blockchain network status to adapt to different network load scenarios. By optimizing the block size, it reduces the amount of data transmitted in a single transaction, alleviating link bandwidth consumption. After dynamic adjustment, the block size matches the actual data traffic, reducing invalid transmission overhead and improving link utilization. By adjusting the generation time, it avoids node resource contention, increases transaction throughput, ensures that nodes can synchronize block data in a timely manner, and reduces the probability of consensus failure, thereby improving the overall stability of the consortium blockchain network and the transaction confirmation speed.

[0023] like Figure 4 The diagram shown is a flowchart of the data write latency evaluation process provided in this application embodiment. The specific design logic is as follows: At the beginning of the process, the write process of the leasing user calling qualified data is evaluated for the data write latency of the consortium blockchain network during the data write stage. The data write latency evaluation result is obtained, and based on the data write latency evaluation result, it is determined whether there is a need for blockchain data call optimization. If the data write latency evaluation result shows that there is such a need, the blockchain data call optimization operation is executed; if the data write latency evaluation result shows that there is no such need, the data transmission stage is evaluated.

[0024] Furthermore, based on the acquired write latency data, a data write latency evaluation is performed on the process of leasing users calling qualified data. The specific process is as follows: at the end of the data write latency evaluation period, the acquired write latency data is compared with the preset write latency data in the database. At the same time, a write latency data correction value is introduced to correct the results of each difference comparison analysis. The results of each correction are coupled and calculated to obtain the data write latency evaluation value. The write latency data includes the oracle data fetching frequency, data consensus execution time, and consensus verification count.

[0025] Among them, the oracle data fetching frequency is used to quantify the interval at which the oracle obtains user credit rating data from external APIs. It is calculated using a time window counting method after being recorded by a counter. The data consensus execution time represents the time interval between nodes in the consortium blockchain network reaching consensus and completing block generation. It is calculated by using the generation timestamp corresponding to the block height to calculate the block generation interval. The consensus verification count represents the number of rounds required for nodes to reach consensus through message interaction. It is calculated by counting the number of operations in which nodes participate in verification through the verification mechanism in the consensus protocol. The write latency data correction value includes the oracle data fetching frequency correction value, the data consensus execution time correction value, and the consensus verification count correction value. The data write latency evaluation value represents the quantitative data of the degree of data call latency caused by the write latency data. It is the result of the coupled processing of the oracle data fetching frequency coefficient, the data consensus execution time coefficient, and the consensus verification count coefficient. The preset write latency data includes the preset oracle data fetching frequency, the data consensus execution time, and the consensus verification count. The write latency data correction value includes the oracle data fetching frequency correction value, the data consensus execution time correction value, and the consensus verification count correction value.

[0026] Specifically, the specific constraint expression for the oracle data fetching frequency coefficient W1 is as follows: In the formula, W1 represents the oracle data fetching frequency coefficient corresponding to the end of the data write latency evaluation period for the consortium blockchain communication link, a1 represents the oracle data fetching frequency correction value, T1 represents the oracle data fetching frequency corresponding to the end of the data write latency evaluation period for the consortium blockchain communication link, and T10 represents the preset oracle data fetching frequency. The preset oracle data fetching frequency is obtained by summing the historical oracle data fetching frequencies corresponding to the end of the data write latency evaluation period for the consortium blockchain communication links, then calculating the average value of this sum, and finally using this average value. The value is used to represent this. It should be noted that the oracle data fetching frequency in the formula for calculating the oracle data fetching frequency coefficient (e.g., multiple times per second) is greater than the preset oracle data fetching frequency (e.g., once per second). In this case, the higher the oracle data fetching frequency, the higher the corresponding latency. This is because high-frequency fetching will increase the load on the consortium blockchain communication link, leading to data write queuing and resource contention, thereby increasing latency. Calculating the oracle data fetching frequency coefficient in this situation can avoid link overload, ensure that the data write latency is stable within an acceptable range, prevent data inconsistency or system lag caused by excessive latency, and ensure the collaborative efficiency and reliability of the oracle and the consortium blockchain.

[0027] The specific constraint expression for the data consensus execution time coefficient W2 is as follows: In the formula, W2 represents the data consensus execution time coefficient corresponding to the end of the data write latency evaluation period of the consortium blockchain communication link, a2 represents the data consensus execution time correction value, T2 represents the data consensus execution time corresponding to the end of the data write latency evaluation period of the consortium blockchain communication link, and T20 represents the preset data consensus execution time. The preset data consensus execution time is obtained by summing up the historical data consensus execution times corresponding to the end of the data write latency evaluation period of the consortium blockchain communication link, and then calculating the average value of the sum. Finally, this average value is used to represent the data consensus execution time.

[0028] The specific constraint expression for the consensus verification number coefficient W3 is as follows: In the formula, W3 represents the consensus verification number coefficient corresponding to the end of the data write latency evaluation period of the consortium blockchain communication link, a3 represents the consensus verification number correction value, T3 represents the consensus verification number corresponding to the end of the data write latency evaluation period of the consortium blockchain communication link, and T30 represents the preset consensus verification number. The preset consensus verification number is obtained by summing up the historical consensus verification numbers corresponding to the end of the data write latency evaluation period of the consortium blockchain communication link, and then calculating the average value of the sum. Finally, this average value is used to represent the value.

[0029] The specific constraint expression for the data write latency evaluation value W is: In the formula, W represents the data write latency evaluation value of the consortium chain communication link in the blockchain at the end of the data write latency evaluation period.

[0030] The database pre-stores preset correction values ​​closely related to the data write latency evaluation. These correction values ​​are mapped to the oracle data fetching frequency, data consensus execution duration, and consensus verification count using clearly defined rules based on business needs and system characteristics. This mapping can be a one-to-one correspondence between a single parameter and a compensation value, or a combination relationship where multiple parameters correspond to a single correction value. For example, during the data write latency evaluation period, the system can obtain the actual values ​​of the oracle data fetching frequency, data consensus execution duration, and consensus verification count in real time, and invoke the preset mapping rules to accurately match and extract the corresponding correction values.

[0031] Most importantly, to ensure the smooth progress of the evaluation process and to ensure the comparability of evaluation results in different scenarios, this example makes a unified limit on the range of values ​​for the correction values ​​of oracle data capture frequency, data consensus execution time, and consensus verification times: all three are controlled within the range of 0 to 1, and the sum of the three is always equal to 1.

[0032] In this embodiment, the data write latency assessment value increases with the increase of oracle data fetching frequency, data consensus execution time, and consensus verification count. When the oracle data fetching frequency increases, since a consensus process is required after each data fetch, frequent fetching leads to an increase in the cumulative time of the consensus process, thus lengthening the data consensus execution time. The increased data consensus execution time and multiple consensus verification counts usually mean that the oracle needs to process more data and consensus tasks. Because the increased consensus verification counts increase the system burden, the system may not be able to process all verification tasks in time. At this time, when the oracle data fetching frequency decreases and the data consensus execution time increases, if multiple data fetching and consensus tasks need to be completed within a certain period of time, it may cause delays in subsequent tasks, thereby reducing the number of consensus verification counts actually completed in the same period of time.

[0033] This example simulates latency trends under different business scenarios based on the interaction between parameters, capturing the causal transmission chain between parameters. For example, when business needs require an increase in data capture frequency, the model can simultaneously predict the extent of the increase in consensus time and the degree of decrease in the number of verifications, thereby outputting a more accurate latency assessment value, providing a basis for resource scheduling, transforming parameter correlation into adjustment rules, enabling the system to have self-adjustment capabilities, building a closed-loop feedback adjustment mechanism, enhancing fault tolerance in abnormal scenarios, and ultimately improving the stability, efficiency, and predictability of the blockchain system in complex business scenarios.

[0034] Furthermore, to determine if there is a need for blockchain data call optimization, the specific process is as follows: Determine the numerical relationship between the obtained data write latency evaluation value and the preset data write latency evaluation value in the database: If the obtained data write latency evaluation value is not greater than the preset data write latency evaluation value, it is recorded as data write qualified, and the qualified data after data write is recorded as lease write qualified data and enters the off-chain transmission stage; If the obtained data write latency evaluation value is greater than the preset data write latency evaluation value, it is recorded as data write unqualified and blockchain data call optimization is performed.

[0035] The specific steps for optimizing blockchain data calls are as follows: First, based on the deviation of the acquired data write latency assessment value, a concurrent call adjustment value is mapped in the database. This value is used to prompt the resource management and scheduling controller to adjust the concurrent call quantity based on the acquired concurrent call quantity adjustment value to reduce contract call resource contention. After optimizing the concurrent call quantity, if the newly acquired data write latency assessment value is not greater than the preset data write latency assessment value, the concurrent call quantity optimization is completed and the off-chain transmission stage begins; otherwise, data readjustment frequency optimization is performed. The specific steps for data readjustment frequency optimization are as follows: Based on the deviation of the acquired data write latency assessment value, a readjustment frequency adjustment value is mapped in the database. This value is used to prompt the resource management and scheduling controller to adjust the concurrent call quantity based on the acquired concurrent call quantity adjustment value. The dynamic resource optimization controller reduces system resource consumption based on the acquired re-call frequency adjustment value. The data write latency evaluation value deviation represents the difference between the acquired data write latency evaluation value and the preset data write latency evaluation value in the database. The preset data write latency evaluation value is represented by the average of the data write latency evaluation values ​​corresponding to the end of the historical data write phase in the database. After the data re-call frequency optimization, if the re-acquired data write latency evaluation value is not greater than the preset data write latency evaluation value, the data re-call frequency optimization is completed and the off-chain transmission phase begins. Otherwise, it is determined that there is a transmission latency risk in the data write phase and a data write latency risk warning is issued.

[0036] In this embodiment, the PID (Proportional-Integral-Derivative) control algorithm in the consortium blockchain network scheduler takes the concurrent call quantity adjustment value and the re-call frequency adjustment value as input. Through the synergistic effect of the proportional, integral, and derivative components, it quickly responds to real-time deviations and reduces resource contention during contract execution between nodes. In this example, the proportional term (P) of the concurrent call quantity adjustment value quickly responds to deviations and reduces resource contention during contract execution between nodes. The integral term (I) accumulates historical latency deviations and drives the re-call frequency adjustment value to converge towards the "low energy consumption-high efficiency" range, ensuring latency meets the target while reducing the consumption of invalid computing power by nodes. The derivative term (D) predicts the trend of latency deviation changes and adjusts the concurrency and re-adjustment parameters in advance. Ultimately, it eliminates redundant competition for call resources, dynamically balances resource competition and system energy consumption, reduces the processing time of contract calls, and improves the system response rate.

[0037] like Figure 5The diagram shown is a flowchart of the off-chain transmission latency evaluation process provided in this application embodiment. The specific design logic is as follows: The process begins by evaluating the off-chain transmission latency of the process of writing qualified data to the leasing user in the off-chain transmission stage for the consortium blockchain network, obtaining the off-chain transmission latency evaluation result, and determining whether there is a need for data byte number optimization based on the off-chain transmission latency evaluation result. If the off-chain transmission latency evaluation result shows that there is such a need, then the data byte number optimization operation is performed; if the off-chain transmission latency evaluation result shows that there is no such need, then the evaluation process ends.

[0038] Furthermore, based on the acquired transmission delay data, an off-chain transmission delay assessment is performed on the off-chain transmission process of the leased user writing qualified data. The specific process is as follows: at the end of the off-chain transmission delay assessment period, the acquired transmission delay data is compared with the preset transmission delay data in the database. At the same time, a transmission delay data correction value is introduced to correct the results of each difference comparison analysis. The difference results of each correction are coupled and calculated to obtain the off-chain transmission delay assessment value. The transmission delay data includes data format conversion time, data packet transmission delay fluctuation value, and weighted score calculation time. The data format conversion time and weighted score calculation time are obtained through the system's built-in timer. The data packet transmission delay fluctuation value represents the maximum delay time corresponding to the data packet in the same data stream during transmission, which is usually obtained through network probe monitoring on the consortium blockchain.

[0039] Among them, the data format conversion time is used to quantify the time required to convert the data format on the consortium blockchain into a format that the off-chain evaluation system can recognize; the weighted score calculation time represents the total time consumed from reading the data to outputting the final weighted score result; the off-chain transmission delay evaluation value represents the quantitative data on the degree of delay of the transmission delay data on the off-chain data transmission; and the data format conversion time coefficient, the data packet transmission delay fluctuation value coefficient, and the weighted score calculation time coefficient represent the coupled processing result. The preset transmission delay data includes the preset data format conversion time, the data packet transmission delay fluctuation value, and the weighted score calculation time. The transmission delay data correction value includes the data format conversion time correction value, the data packet transmission delay fluctuation value correction value, and the weighted score calculation time correction value.

[0040] Specifically, the specific constraint expression for the data format conversion time coefficient D1 is as follows: In the formula, D1 represents the data format conversion time coefficient corresponding to the end of the off-chain transmission delay evaluation period for qualified data written to leases, b1 represents the data format conversion time correction value, P1 represents the data format conversion time corresponding to the end of the off-chain transmission delay evaluation period for qualified data written to leases, and P10 represents the preset data format conversion time. The preset data format conversion time is obtained by summing up the historical data format conversion times corresponding to the end of the off-chain transmission delay evaluation period for qualified data written to leases, and then calculating the average value of the sum. Finally, this average value is used to represent the final value.

[0041] The specific constraint expression for the data packet transmission delay fluctuation coefficient D2 is as follows: In the formula, D2 represents the data packet transmission delay fluctuation value coefficient corresponding to the end of the off-chain transmission delay evaluation period for qualified data written to leases, b2 represents the data packet transmission delay fluctuation value correction value, P2 represents the data packet transmission delay fluctuation value corresponding to the end of the off-chain transmission delay evaluation period for qualified data written to leases, and P20 represents the preset data packet transmission delay fluctuation value. The preset data packet transmission delay fluctuation value is obtained by summing up the historical data packet transmission delay fluctuation values ​​corresponding to the end of the off-chain transmission delay evaluation period for qualified data written to leases, and then calculating the average value of the sum. Finally, this average value is used to represent the value.

[0042] The specific constraint expression for the weighted score calculation time D3 is: In the formula, D3 represents the weighted score calculation time coefficient corresponding to the end of the off-chain transmission delay evaluation period for qualified data written to leases, b3 represents the weighted score calculation time correction value, P3 represents the weighted score calculation time corresponding to the end of the off-chain transmission delay evaluation period for qualified data written to leases, and P30 represents the preset weighted score calculation time. The preset weighted score calculation time is obtained by summing up the historical weighted score calculation times corresponding to the end of the off-chain transmission delay evaluation period for qualified data written to leases, and then calculating the average value of the sum. Finally, this average value is used to represent the final result.

[0043] The specific constraint expression for the off-chain transmission delay evaluation value D is: In the formula, D represents the off-chain transmission delay assessment value corresponding to the end of the off-chain transmission delay assessment period when the leased qualified data is written.

[0044] The database pre-stores preset correction values ​​closely related to the off-chain transmission latency assessment. These correction values ​​are mapped to data format conversion time, data packet transmission latency fluctuation, and weighted score calculation time using clearly defined rules based on business needs and system characteristics. This mapping can be a one-to-one correspondence between a single parameter and its compensation value, or a combination of multiple parameters corresponding to a single correction value. For example, during the data transmission latency assessment period, the system can obtain the actual values ​​of data format conversion time, data packet transmission latency fluctuation, and weighted score calculation time in real time, and then invoke the preset mapping rules to accurately match and extract the corresponding correction values.

[0045] Most importantly, to ensure the smooth progress of the evaluation process and to ensure the comparability of evaluation results in different scenarios, this example makes a unified limit on the range of values ​​for data format conversion time correction, data packet transmission delay fluctuation correction, and weighted score calculation time correction: all three are controlled within the range of 0 to 1, and the sum of the three is always equal to 1.

[0046] In this embodiment, the off-chain transmission latency assessment value increases with the increase of data format conversion time, data packet transmission latency fluctuation value, and weighted score calculation time. When the data format conversion time increases, the CPU (Central Processing Unit) utilization rate of the off-chain system in processing format conversion increases, which may prevent timely response to the reception and transmission of data packets in the consortium blockchain network, resulting in an increase in data packet transmission latency fluctuation value. The increase in data packet transmission latency fluctuation value may lead to uneven data arrival time in the off-chain system. When the data arrives in a concentrated manner, the system needs to process each data packet in sequence. The conversion of subsequent data packets may need to wait for the previous processing to complete, thus increasing the data format conversion time. If the weighted score calculation time increases, it may consume more system resources, resulting in a reduction of available resources during data format conversion, thereby prolonging the data format conversion time.

[0047] This example, by considering the relationship between the three factors, accurately pinpoints the root cause of system latency, synchronously collects and integrates the three-parameter evaluation results of each node, and achieves cross-node collaborative adjustment. The parameter collaborative adjustment under comprehensive evaluation can accurately control CPU utilization, avoid energy waste caused by excessive resource consumption of a certain task, and dynamically adjust resource allocation strategies. For example, excessive transmission latency fluctuations may lead to data retransmission (such as timeout retransmission mechanisms), while correlation optimization can reduce the retransmission rate by adjusting parameters in advance, reduce data retransmission and redundant processing, and ensure the real-time performance of critical data.

[0048] Furthermore, to determine if there is a need for data byte count optimization, the specific process is as follows: Determine the numerical relationship between the obtained off-chain transmission latency assessment value and the preset off-chain transmission latency assessment value in the database. If the obtained off-chain transmission latency assessment value is not greater than the preset off-chain transmission latency assessment value, it is recorded as qualified off-chain transmission, and the qualified off-chain transmission data is written into the qualified data and recorded as qualified off-chain transmission data for the lease, and the credit risk assessment of the lease user is completed. If the obtained off-chain transmission latency assessment value is greater than the preset off-chain transmission latency assessment value, it is recorded as unqualified off-chain transmission, and data byte count optimization is performed.

[0049] The specific steps for optimizing the number of data bytes are as follows: The average of the deviation of the off-chain transmission latency assessment value and the deviation of the data byte count score is used as the adjustment amount for the number of bytes in the data packet to be transmitted. This adjustment is used to prompt the intelligent traffic scheduling router to reduce data transmission queuing delay based on the acquired byte count adjustment amount. The deviation of the off-chain transmission latency assessment value measures the difference between the acquired off-chain transmission latency assessment value and the preset off-chain transmission latency assessment value, i.e., the difference between the acquired and preset off-chain transmission latency assessment values. The deviation of the data byte count score represents the absolute value of the difference between the data byte count score corresponding to the qualified data written by the lease at the end of the off-chain transmission latency assessment period and the preset data byte count score. The data byte count score represents the ratio of the acquired number of bytes of qualified data written by the lease to the total number of transmitted data bytes. After optimizing the number of data bytes, if the re-acquired off-chain transmission latency assessment value is not greater than the preset off-chain transmission latency assessment value, the data byte count optimization is completed and the credit risk assessment of the lease user is completed. Otherwise, it is determined that there is a latency risk in the off-chain transmission of the lease, and an off-chain transmission latency risk warning is issued.

[0050] In this embodiment, the PID control algorithm in the scheduling router takes the adjusted number of bytes of the data packet to be transmitted as input. Through the synergistic effect of proportional, integral, and derivative steps, it reduces the data packet size, alleviates the transmission pressure of the consortium blockchain network, and dynamically balances latency and compression efficiency. The preset off-chain transmission latency evaluation value is represented by the sum and average of the corresponding off-chain transmission latency evaluation values ​​at the end of the historical off-chain transmission latency evaluation period in the database. The preset data byte count score is represented by the sum and average of the corresponding data byte count scores at the end of the historical off-chain transmission latency evaluation period in the database.

[0051] This example transforms a two-dimensional indicator into a single adjustment quantity by summing and averaging the off-chain transmission latency deviation and the byte count fraction deviation. This allows intelligent traffic to adjust data packet sending strategies in real time, reducing transmission errors and retransmission requirements through byte count adjustment. This ensures that leased data is completely uploaded to the blockchain, achieving dual protection of data integrity and timeliness. If the latency still does not meet the standard after optimization, the system triggers a risk warning based on a comprehensive assessment of the two deviations. This forms a complete closed loop from "deviation calculation - adjustment execution - effect verification," ensuring the effectiveness of the optimization measures.

[0052] like Figure 6 The diagram shows the structure of a blockchain-based rental user credit risk assessment system provided in this application embodiment. The system includes: a data call latency assessment module, a data write latency assessment module, and an off-chain transmission latency assessment module. The data call latency assessment module assesses the data call latency of the rental user's credit rating data during the call phase of the constructed consortium blockchain network, and determines whether there is a need for block parameter optimization. The data write latency assessment module assesses the data write latency of the rental user's call for qualified data during the data write phase, based on the acquired write latency data, and determines whether there is a need for blockchain data call optimization. The off-chain transmission latency assessment module assesses the off-chain transmission latency of the rental user's write for qualified data during the off-chain transmission phase, based on the acquired transmission latency data, and determines whether there is a need for data byte count optimization.

[0053] In this embodiment, a three-stage latency assessment module of "call-write-transfer" is used to control the latency of leasing credit data from on-chain to off-chain transmission, thereby improving the timeliness of risk assessment. Each module dynamically schedules resources in stages according to the latency assessment results, avoiding optimization of a single link and achieving performance improvement across the entire chain. This also avoids invalid data occupying on-chain storage. Furthermore, the assessment results of each module will trigger corresponding optimization strategies, forming a closed loop of "assessment-optimization-reassessment". This supports dynamic adaptation to changes in the consortium blockchain network in high-frequency scenarios and improves the accuracy of credit assessment.

[0054] In summary, this application embodiment assesses stability latency by evaluating the amount of data transmitted through the link. Based on the stability latency assessment results, it determines whether to optimize block parameters to improve link data throughput and reduce the pressure of a single data transmission. Then, it assesses data write latency based on write latency data and determines whether to optimize blockchain data calls to avoid frequent blockchain calls under high system load, reducing redundant calls and response waiting time. Finally, it assesses off-chain transmission latency based on transmission latency data and determines whether to optimize the number of data bytes to reduce the demand on blockchain network bandwidth, transmitting more effective data at the same bandwidth cost and reducing transmission latency. This improves the reliability of data transmission risk assessment for leased user credit ratings.

[0055] Those skilled in the art will understand that embodiments of the present invention can be provided as methods, systems, or computer program products. 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. Furthermore, the present invention can take the form of a computer program product embodied on one or more computer-usable storage media (including, but not limited to, disk storage, CD-ROM, optical storage, etc.) containing computer-usable program code.

[0056] This 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 will be understood that each block of the flowchart illustrations and / or block diagrams, and combinations of blocks in the flowchart illustrations and / or block diagrams, can be implemented by computer program instructions. These computer program instructions can 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, which execute via the processor of the computer or other programmable data processing apparatus, generate instructions for implementing the flowchart illustrations and / or block diagrams. Figure 1 a process or multiple processes and / or boxes Figure 1 A device that provides the functions specified in a block or multiple blocks.

[0057] These computer program instructions may also be stored in a computer readable memory that can direct a computer or other programmable data processing device to work in a specific manner, so that the instructions stored in the computer readable memory produce an article of manufacture comprising an instruction device, which implements the process Figure 1 a process or multiple processes and / or boxes Figure 1 The function specified in one or more boxes.

[0058] These computer program instructions can also be loaded onto a computer or other programmable data processing device so that a series of operational steps are executed on the computer or other programmable device to produce a computer-implemented process, thereby providing the instructions executed on the computer or other programmable device for implementing the process. Figure 1 a process or multiple processes and / or boxes Figure 1 A step that specifies a function in one or more boxes.

[0059] Although the preferred embodiments of the present invention have been described, those skilled in the art may make additional changes and modifications to these embodiments once they have learned the basic creative concept. Therefore, the appended claims are intended to be interpreted as including the preferred embodiments and all changes and modifications that fall within the scope of the present invention.

[0060] Obviously, those skilled in the art can make various modifications and variations to this invention without departing from its spirit and scope. Therefore, if these modifications and variations fall within the scope of the claims of this invention and their equivalents, this invention also intends to include these modifications and variations.

Claims

1. A blockchain-based method for assessing credit risk of rental users, characterized in that, Includes the following steps: Step 1: In the call phase of the established consortium blockchain network, the data call latency of the call process for the credit rating data of the leasing user is evaluated, and it is determined whether there is a need for block parameter optimization. The block parameter optimization means reducing the risk of blockchain call latency by adjusting the block size and block generation time. Step 2: During the data writing phase, the data writing latency of the rental user calling qualified data is evaluated based on the acquired write latency data. At the same time, it is determined whether there is a need for blockchain data call optimization. The blockchain data call optimization means reducing the risk of blockchain write latency by adjusting the number of concurrent calls and the data readjustment frequency. Step 3: In the off-chain transmission stage, based on the acquired transmission delay data, the off-chain transmission delay of the process of the leasing user writing qualified data is evaluated. At the same time, it is determined whether there is a need for data byte number optimization. The data byte number optimization means reducing the risk of off-chain transmission delay of the blockchain by adjusting the number of data packets.

2. The blockchain-based method for assessing credit risk of leasing users as described in claim 1, characterized in that, The specific process for determining whether there is a need for block parameter optimization is as follows: Determine the difference between the acquired link transmission data volume and the preset link transmission data volume in the database. Value change relationship: If the amount of data transmitted via the link is not less than the preset amount of data transmitted via the link, it is recorded as a qualified data call. At the same time, the credit rating data of the leased user after the qualified call is recorded as qualified lease call data and enters the data writing stage. The amount of data transmitted via the link is used to quantify the data transmission rate of the consortium chain communication link in the blockchain of the obtained leased user credit rating data. If the amount of data transmitted via the link is less than the preset amount of data transmitted via the link, it is recorded as an unqualified data call and block parameter optimization is performed.

3. The blockchain-based credit risk assessment method for rental users as described in claim 2, characterized in that, The specific steps for optimizing the block parameters are as follows: Based on the obtained deviation of the link transmission data volume, a block size adjustment value is obtained by mapping it in the database. This value is used to prompt smart contracts in the blockchain to adjust the block size to reduce the data transmission pressure in the blockchain network. Meanwhile, the block generation time extension is mapped in the database based on the obtained deviation of the link transmission data volume. This is used to prompt smart contracts in the blockchain to improve the transaction processing speed of blockchain network nodes based on the obtained block generation time extension. If the amount of data transmitted via the link after block parameter optimization is not less than the preset amount of data transmitted via the link, then the block parameter optimization is completed and the data writing stage begins. Otherwise, it is determined that there is a transmission delay risk in the consortium blockchain communication link and a communication link delay risk warning is issued. The block parameter optimization includes block size optimization and block generation time optimization.

4. The blockchain-based method for assessing credit risk of leasing users as described in claim 1, characterized in that, The process of evaluating the data write latency of the rental user's call for qualified data based on the acquired write latency data is as follows: At the end of the data write latency evaluation period, the acquired write latency data is compared with the preset write latency data in the database to analyze the difference. At the same time, the write latency data correction value is introduced to correct the results of the difference comparison analysis. The results of each correction are coupled and calculated to obtain the data write latency evaluation value. The write latency data includes the oracle data fetching frequency, data consensus execution time, and consensus verification count. The data write latency evaluation value represents the quantitative data of the degree of data call latency caused by the write latency data.

5. The blockchain-based credit risk assessment method for rental users as described in claim 4, characterized in that, The specific process for determining whether there is a need for blockchain data retrieval optimization is as follows: Determine the numerical relationship between the acquired data write latency evaluation value and the preset data write latency evaluation value in the database: If the acquired data write latency evaluation value is not greater than the preset data write latency evaluation value, it is recorded as data write qualified. At the same time, the qualified data after the data write is qualified is recorded as lease write qualified data and enters the off-chain transmission stage. If the obtained data write latency evaluation value is greater than the preset data write latency evaluation value, it is recorded as unqualified data write and blockchain data call optimization is performed.

6. The blockchain-based credit risk assessment method for rental users as described in claim 5, characterized in that, The optimization of blockchain data retrieval involves the following steps: Based on the deviation of the acquired data write latency evaluation value, the concurrent call quantity adjustment value is mapped in the database. This value is used to prompt the resource management and scheduling controller to adjust the concurrent call quantity based on the acquired value to reduce contract call resource contention. After optimizing the number of concurrent calls, if the evaluation value of the write latency of the reacquired data is not greater than the preset evaluation value of the write latency of the data, the optimization of the number of concurrent calls is completed and the off-chain transmission stage is entered; otherwise, the data readjustment frequency optimization is performed. The specific steps for optimizing the data readjustment frequency are as follows: The deviation of the acquired data write latency evaluation value is mapped in the database to obtain the recall frequency adjustment value, which is used to prompt the dynamic resource optimization controller to reduce system resource consumption based on the acquired recall frequency adjustment value. After the data readjustment frequency optimization, if the newly acquired data write latency evaluation value is not greater than the preset data write latency evaluation value, the data readjustment frequency optimization is completed and the off-chain transmission stage is entered; otherwise, it is determined that there is a transmission latency risk in the data write stage and a data write latency risk warning is issued.

7. The blockchain-based method for assessing credit risk of leasing users as described in claim 1, characterized in that, The off-chain transmission latency assessment of the process of writing qualified data to the lease user based on the acquired transmission latency data is as follows: At the end of the off-chain transmission delay evaluation period, the acquired transmission delay data is compared with the preset transmission delay data in the database. At the same time, a transmission delay data correction value is introduced to correct the results of each difference comparison analysis. The difference results of each correction are coupled and calculated to obtain the off-chain transmission delay evaluation value. The transmission delay data includes data format conversion time, data packet transmission delay fluctuation value, and weighted scoring calculation time. The off-chain transmission delay evaluation value represents the quantitative data of the degree of delay of the transmission delay data to the off-chain data transmission.

8. The blockchain-based method for assessing the credit risk of leasing users as described in claim 7, characterized in that, The specific process for determining whether there is a need to optimize the number of data bytes is as follows: Determine the numerical relationship between the obtained off-chain transmission delay assessment value and the preset off-chain transmission delay assessment value in the database: If the obtained off-chain transmission delay assessment value is not greater than the preset off-chain transmission delay assessment value, it is recorded as qualified off-chain transmission. At the same time, the qualified off-chain transmission data is written into the qualified data and recorded as qualified off-chain transmission data for leasing, and the credit risk assessment of the leasing user is completed. If the obtained off-chain transmission latency evaluation value is greater than the preset off-chain transmission latency evaluation value, it is recorded as an unqualified off-chain transmission and the number of data bytes is optimized. The blockchain-based rental user credit risk assessment method as described in claim 8, characterized in that the data byte count optimization specifically includes the following steps: The summation and average of the off-chain transmission delay assessment deviation and the data byte count fraction deviation are used as the byte count adjustment amount for the data packets to be transmitted. This is used to prompt the intelligent traffic scheduling router to reduce data transmission queuing delay based on the acquired byte count adjustment amount. After optimizing the number of data bytes, if the re-acquired off-chain transmission latency assessment value is not greater than the preset off-chain transmission latency assessment value, the data byte optimization is completed and the credit risk assessment of the leasing user is completed; otherwise, it is determined that there is a latency risk in the off-chain transmission of the lease and an off-chain transmission latency risk warning is issued.

9. A system applying the blockchain-based credit risk assessment method for leasing users as described in any one of claims 1-9, characterized in that, include: Data call latency evaluation module, data write latency evaluation module, and off-chain transmission latency evaluation module; The data call latency evaluation module is used to evaluate the data call latency of the rental user credit rating data during the call phase of the constructed consortium blockchain network, and at the same time determine whether there is a need for block parameter optimization. The data write latency evaluation module is used to evaluate the data write latency of the rental user calling qualified data based on the acquired write latency data during the data write phase, and at the same time determine whether there is a need for optimization of blockchain data calling. The off-chain transmission latency assessment module is used to assess the off-chain transmission latency of the rental user's write of qualified data based on the acquired transmission latency data during the off-chain transmission phase, and at the same time determine whether there is a need for data byte count optimization.

10. A system applying the blockchain-based credit risk assessment method for leasing users as described in any one of claims 1-9, characterized in that, include: Data call latency evaluation module, data write latency evaluation module, and off-chain transmission latency evaluation module; The data call latency evaluation module is used to evaluate the data call latency of the rental user credit rating data during the call phase of the constructed consortium blockchain network, and at the same time determine whether there is a need for block parameter optimization. The data write latency evaluation module is used to evaluate the data write latency of the rental user calling qualified data based on the acquired write latency data during the data write phase, and at the same time determine whether there is a need for optimization of blockchain data calling. The off-chain transmission latency assessment module is used to assess the off-chain transmission latency of the rental user's write of qualified data based on the acquired transmission latency data during the off-chain transmission phase, and at the same time determine whether there is a need for data byte count optimization.

Images