A blockchain financial identity authentication system

Abstract

The present application relates to the technical field of blockchain authentication, in particular to a blockchain financial identity authentication system, which comprises a behavior characteristic acquisition module, an identity behavior portrait module, a contract response judgment module, a trust node scheduling module and a block behavior writing module.In the present application, the keystroke rhythm, sliding trajectory and touch pressure in user registration interaction are collected, dynamic characteristics such as interval sequence and offset angle are extracted, and the behavior characteristic matrix under the pairing of input mode and terminal is constructed by combining terminal type, input frequency and trajectory flow direction, so as to realize the exclusive uniqueness of identity label and environmental adaptability, fuse path offset and device information in interactive verification, dynamically adjust the authentication level, improve the strategy flexibility and responsiveness, optimize node screening and task distribution based on response time and consistency score, improve the distributed authentication efficiency, encrypt and issue the authentication result and write it into the blockchain to ensure the traceability and data security of the process.

Description

Technical Field

[0001] This invention relates to the field of blockchain identity verification technology, and in particular to a blockchain financial identity verification system. Background Technology

[0002] The field of blockchain identity verification technology encompasses technologies for managing and verifying user identity information based on blockchain technology. The core of this technology lies in leveraging the distributed ledger characteristics of blockchain to achieve decentralized storage and trusted verification of identity information. By uploading user identity data to the blockchain, consistency and immutability across multiple nodes are ensured, enabling secure sharing of identity information across different systems. This technology covers various aspects of digital identity registration, authentication, management, and access control. Common implementation methods include combining cryptographic techniques for data encryption, automating the execution of identity verification logic through smart contracts, and using consensus mechanisms to ensure the credibility of the identity authentication process. This field also involves the design of multi-party identity interaction mechanisms and the application of privacy protection strategies to ensure effective identity verification while protecting user privacy.

[0003] Among them, the blockchain financial identity authentication system refers to a system that provides identity authentication support for users in financial scenarios based on blockchain technology. It mainly targets the need for reliable verification of users' real identities in financial business. It covers on-chain registration of user identity information, design of identity authentication process based on asymmetric encryption, consensus confirmation process of identity verification records, and setting of identity permission call rules using smart contracts. By hashing user identity data and putting it on the chain, data integrity and tamper-proof are ensured. At the same time, the system combines digital signature mechanism to confirm and verify user identity, ensuring the uniqueness and traceability of the authentication process. The system also realizes the reliable sharing of identity authentication results through consensus process between nodes, ensuring information consistency and mutual trust among multiple financial institutions in terms of identity authentication.

[0004] While existing technologies can achieve on-chain identity information and decentralized verification based on blockchain, they primarily rely on static identity data and pre-defined verification paths for authentication. They lack in-depth analysis of user behavior, making it difficult to accurately identify fraudulent or unauthorized actions. When faced with highly similar identity registration information, relying solely on user information hashes and digital signatures is insufficient to establish user behavior-based identification, leading to authentication overlap risks among multiple users on the same device. Regarding authentication level response, current solutions are mostly fixed mechanisms, unable to dynamically adjust to different terminals, input behavior differences, and environmental fluctuations. This results in insufficient authentication response in some high-risk interactions, making them easily bypassed. Consensus node scheduling is often based on average response times without clear execution capability prioritization, causing node congestion and delayed verification responses in high-frequency verification scenarios. The block writing process lacks detailed characterization of identity behavior, resulting in incomplete authentication trajectories and affecting subsequent traceability. While digital signature-based verification structures ensure the integrity of original data, the lack of a process behavior chain poses a potential risk of insufficient authentication effectiveness, particularly prominent in sensitive scenarios such as high-frequency financial transactions and cross-platform identity synchronization, easily leading to identity theft and trust mismatch risks. Summary of the Invention

[0005] The purpose of this invention is to address the shortcomings of existing technologies by proposing a blockchain-based financial identity authentication system.

[0006] To achieve the above objectives, the present invention adopts the following technical solution: A blockchain financial identity authentication system includes:

[0007] The behavioral feature acquisition module obtains input behavior data from the financial identity authentication registration page, collects user keystroke rhythm, swipe trajectory and touch pressure, extracts rhythm sequence and trajectory offset, compares trajectory length and duration fluctuation, filters high-frequency behavioral feature combinations, and generates a blockchain identity input behavior feature map.

[0008] The identity behavior profiling module is based on the blockchain identity input behavior feature map, combined with terminal model, typing frequency and trajectory flow, to identify operation rhythm and device habits, extract input method and terminal matching features, and generate identity behavior profile tags.

[0009] The contract response judgment module extracts user behavior data based on the identity behavior profile tags, analyzes the degree of deviation between the current input path and the original behavior tags, and combines the device fingerprint and access address to determine whether the authentication mechanism level needs to be adjusted according to the contract conditions, and generates a dynamic verification level set for the contract.

[0010] The trust node scheduling module calls the contract dynamic verification level set, retrieves the response time, verification frequency and consistency score in the consensus node pool, evaluates the execution capabilities of the nodes and sorts them, selects the top-ranked node groups for verification task assignment, and obtains the financial identity authentication node execution sequence.

[0011] As a further aspect of the present invention, the blockchain identity input behavior feature map includes keystroke rhythm difference factor, trajectory angle offset index, input stability measure, behavior pattern correlation degree, and input fluctuation frequency; the blockchain identity behavior profile label includes terminal adaptation feature, operation rhythm label, input method preference, behavior inertia parameter, and device usage feature; the contract dynamic verification level set includes path deviation magnitude, fingerprint consistency level, address trust weight, authentication dynamic identifier, and contract response label; and the financial identity authentication node execution sequence includes response delay sorting, verification task number, node execution weight, allocation scheduling parameter, and consensus priority label.

[0012] As a further aspect of the present invention, the behavioral feature acquisition module includes:

[0013] The keystroke rhythm extraction submodule obtains input behavior data from the financial identity authentication registration page, extracts keystroke intervals and arranges them in order, analyzes the interval fluctuation amplitude, filters the key keystroke time periods of fluctuation amplitude, and generates a keystroke rhythm fluctuation feature map.

[0014] The trajectory parameter recognition submodule extracts the sliding trajectory data input by the user based on the keystroke rhythm fluctuation feature map, identifies the path length and offset angle, analyzes the fluctuation of trajectory length and input duration, and filters the input behavior segments with offset amplitude to obtain the trajectory length fluctuation range.

[0015] The behavior feature construction submodule calls the trajectory length fluctuation range, combines it with touch pressure data, analyzes key-clicking and swiping behaviors in different time periods, filters related behavior feature combinations, and generates a blockchain identity input behavior feature map.

[0016] As a further aspect of the present invention, the identity behavior profiling module includes:

[0017] The transaction signature analysis submodule extracts the keystroke frequency and trajectory coordinates during the blockchain transaction signing process based on the blockchain identity input behavior feature map, calculates the transaction behavior entropy value, performs pattern matching with the signature benchmark library recorded in the blockchain ledger, and generates a transaction signature rhythm pattern.

[0018] The node verification feature submodule calls the transaction signature rhythm mode to analyze the device protocol stack features and encryption key usage frequency in the blockchain node interaction log to obtain the node verification feature set.

[0019] The credibility assessment submodule, based on the node verification feature set, uses the identity verification rule engine deployed by the smart contract to perform on-chain credibility weighted identification of multi-dimensional behavioral features and generate identity behavior profile tags.

[0020] As a further aspect of the present invention, the contract response judgment module includes:

[0021] The behavior offset recognition submodule identifies the user's operation path in the blockchain financial identity authentication interaction based on the identity behavior profile label, calculates the offset trajectory difference between the user and the registered behavior path, determines the path consistency deviation range, and obtains the behavior path offset features.

[0022] Based on the behavior path offset features, the device fingerprint verification submodule extracts the current device fingerprint and access address, compares its structural matching with the fingerprint combinations of previous identity authentications stored on the chain, determines the fingerprint stability level, and obtains the device trust identification factor.

[0023] The authentication level adjustment submodule calculates the dynamic authentication complexity based on the device's trusted identification factor, matches the corresponding verification scheme according to the contract rules, and generates a set of dynamic verification levels for the contract.

[0024] As a further aspect of the present invention, the trusted node scheduling module includes:

[0025] The node capability scoring submodule calls the contract dynamic verification level set, extracts the average response time, identity verification frequency and consistency score of the nodes in the consensus node pool, analyzes the execution stability and response capability indicators of the nodes, calculates the node execution capability score value, and obtains the blockchain certified node capability indicator set.

[0026] The authentication node dispatching submodule selects the set of nodes with the highest index scores based on the blockchain authentication node capability index set, and determines the priority order of task distribution by combining the current timeliness requirements of the verification task and the geographical network structure relationship of the nodes, thus obtaining the financial identity authentication node execution sequence.

[0027] As a further aspect of the present invention, the system also includes a block behavior writing module:

[0028] The block behavior writing module extracts the identity authentication result and contract verification process record based on the execution sequence of the financial identity authentication node, calls the issuance order and encryption strategy encoding, integrates the behavior feature summary and contract execution record and writes it into the ledger to obtain the on-chain evidence storage record of identity authentication.

[0029] The evidence storage records on the identity authentication chain include authentication result summary, execution process label, feature hash code, issuance encryption identifier, and ledger index entry.

[0030] As a further aspect of the present invention, the block behavior writing module includes:

[0031] The identity authentication extraction submodule extracts identity information and contract verification records based on the execution sequence of the financial identity authentication node, filters them according to identity credibility and contract matching degree, and obtains identity authentication behavior characteristics by combining identity authentication and contract verification data.

[0032] The issuance policy invocation submodule extracts the issuance order and encryption policy code based on the identity authentication behavior characteristics, matches the identity authentication behavior characteristics with the issuance policy, identifies the adaptability of the encryption policy code in the issuance order, and generates an encryption adaptation policy.

[0033] The evidence storage record generation submodule integrates contract execution records and identity authentication behavior features according to the encryption adaptation strategy, analyzes the mapping relationship of fields in the contract execution record, constructs the blockchain writing structure of contract execution based on the mapping relationship, and generates on-chain evidence storage records for identity authentication.

[0034] Compared with the prior art, the advantages and positive effects of the present invention are as follows:

[0035] In this invention, keystroke rhythm, swipe trajectory, and touch pressure are collected during user registration interactions, and dynamic behavioral features such as interval sequences, offset angles, and fluctuation amplitudes are extracted. This enables fine-grained analysis of individual input patterns, enhancing the sensitivity to capture behavioral-level information. Furthermore, by combining terminal model, input frequency, and trajectory flow, common operating habits and device usage preferences are mined, constructing a behavioral feature matrix based on input method and terminal pairing. This makes the construction of identity tags more unique and adaptable to the usage environment. During interactive behavior verification, a dynamic authentication level adjustment mechanism is implemented through path offset assessment and joint judgment of device information, making the identity verification strategy more flexible and scenario-responsive. The selection of execution nodes is optimized based on response time, consistency scores, and other dimensions, ensuring accurate and efficient distribution of verification tasks and improving the consistency and response efficiency of identity authentication in a distributed network. The authentication results are encrypted and signed after feature digest integration and written to the blockchain ledger, forming a complete and traceable verification record chain, ensuring data integrity, security, and traceability during the authentication process. The overall processing logic incorporates dynamic behavior trajectory analysis, usage habit recognition, and node scheduling strategies, which improves the individual distinguishability, strategy adaptability, and reliable closed-loop nature of the entire verification process. Attached Figure Description

[0036] Figure 1 This is a system flowchart of the present invention;

[0037] Figure 2 This is a flowchart of the behavior feature acquisition module in this invention;

[0038] Figure 3 This is a flowchart of the identity behavior profiling module in this invention;

[0039] Figure 4 This is a flowchart of the contract response judgment module in this invention;

[0040] Figure 5 This is a flowchart of the trusted node scheduling module in this invention;

[0041] Figure 6 This is a flowchart of the block behavior writing module in this invention. Detailed Implementation

[0042] To make the objectives, technical solutions, and advantages of this invention clearer, the invention will be further described in detail below with reference to the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are merely illustrative and not intended to limit the invention.

[0043] In the description of this invention, it should be understood that the terms "length," "width," "upper," "lower," "front," "rear," "left," "right," "vertical," "horizontal," "top," "bottom," "inner," and "outer," etc., indicating orientation or positional relationships, are based on the orientation or positional relationships shown in the accompanying drawings and are only for the convenience of describing the invention and simplifying the description, and do not indicate or imply that the device or element referred to must have a specific orientation, or be constructed and operated in a specific orientation, and therefore should not be construed as a limitation of the invention. Furthermore, in the description of this invention, "a plurality of" means two or more, unless otherwise explicitly specified.

[0044] Please see Figure 1 A blockchain-based financial identity authentication system includes:

[0045] The behavioral feature acquisition module obtains input behavior data from the financial identity authentication registration page, collects the user's keystroke rhythm, sliding trajectory and touch pressure in the password input area, extracts the keystroke interval sequence and trajectory offset angle, compares the fluctuation range of trajectory length and input duration, filters high-frequency behavioral feature combinations, and generates a blockchain identity input behavior feature map.

[0046] The identity behavior profiling module is based on the blockchain identity input behavior feature map. It combines the terminal model, typing frequency and trajectory flow at the time of registration to identify common operation rhythms and device usage habits, extract behavioral parameter features that match the input method and terminal, and generate identity behavior profile tags.

[0047] The contract response judgment module extracts user behavior data in the financial identity authentication interaction area based on identity behavior profile tags, analyzes the degree of deviation between the current input path and the original behavior tags, and combines the device fingerprint and access address to determine whether the authentication mechanism level needs to be adjusted according to the contract conditions, and generates a dynamic verification level set for the contract.

[0048] The trust node scheduling module calls the contract dynamic verification level set, retrieves the response time, verification frequency and consistency score in the consensus node pool, evaluates the execution capabilities of the nodes and sorts them, selects the top-ranked node groups for verification task assignment, and obtains the financial identity authentication node execution sequence.

[0049] The block behavior writing module extracts the identity authentication results and contract verification process records based on the execution sequence of financial identity authentication nodes, calls the issuance order and encryption strategy encoding, integrates the behavior feature summary and contract execution record and writes it into the ledger to obtain the on-chain evidence storage record of identity authentication.

[0050] The blockchain identity input behavior feature map includes keystroke rhythm difference factor, trajectory angle offset index, input stability measure, behavior pattern correlation, and input fluctuation frequency. The blockchain identity behavior profile label includes terminal adaptation features, operation rhythm label, input method preference, behavior inertia parameter, and device usage features. The contract dynamic verification level set includes path deviation magnitude, fingerprint consistency level, address trust weight, authentication dynamic identifier, and contract response label. The financial identity authentication node execution sequence includes response delay sorting, verification task number, node execution weight, allocation scheduling parameter, and consensus priority label. The identity authentication on-chain evidence storage record includes authentication result summary, execution process label, feature hash encoding, issuance encryption identifier, and ledger index entry.

[0051] Please see Figure 2 The behavioral feature acquisition module includes:

[0052] The keystroke rhythm extraction submodule obtains input behavior data from the financial identity authentication registration page, extracts keystroke intervals and arranges them in order, analyzes the interval fluctuation amplitude, filters the key keystroke time periods of fluctuation amplitude, and generates a keystroke rhythm fluctuation feature map.

[0053] First, input behavior data from the financial identity authentication registration page is acquired. This data can be obtained by recording the timestamps of each keystroke. The time difference between pressing and releasing a key is calculated as the keystroke interval. These intervals are then arranged sequentially to analyze their fluctuation range. During the analysis, calculating the fluctuation range involves obtaining the time difference between each pair of consecutive keystrokes and calculating the standard deviation of this time difference. This standard deviation is used as a measure of the fluctuation range. Statistics are compiled for each set of consecutive keystroke intervals (e.g., the time interval between two keystrokes), and fluctuations are identified by calculating the changing trend of each pair of intervals. For example, assuming a user inputs "1234" with keystroke intervals of 200ms, 180ms, and 210ms, the standard deviation is calculated based on the time interval, and this value is used as the fluctuation range of the keystroke rhythm. When filtering key keystroke time periods, a threshold is set based on the keystroke interval fluctuation value. For example, when the fluctuation range exceeds a certain threshold, it is determined to be a key keystroke period. This period can reflect irregularities or abnormal behavior in the user's input process. Finally, a keystroke rhythm fluctuation feature map is generated.

[0054] The trajectory parameter recognition submodule extracts the sliding trajectory data input by the user based on the keystroke rhythm fluctuation feature map, identifies the path length and offset angle, analyzes the fluctuation of trajectory length and input duration, and filters the input behavior segments with offset amplitude to obtain the trajectory length fluctuation range.

[0055] Extracting key trajectory features from user-input sliding trajectory data involves analyzing the user's input trajectory and calculating its path length and offset angle. Path length refers to the distance from the starting point to the ending point, while offset angle refers to the angle of change of the trajectory direction during the sliding process. The path length is calculated by summing the straight-line distances between consecutive sliding points, while the offset angle is calculated by calculating the angle change between adjacent trajectory points one by one. To analyze the fluctuations in trajectory length and input duration, the start and end times of each slide are recorded, the input duration is calculated, and compared with the path length. If there are significant fluctuations in the ratio between the input duration and the path length, this period is identified as a trajectory fluctuation range. For example, if the user maintains a short path movement for a relatively long period, abnormal behavior can be identified through ratio calculation. The fluctuation of offset amplitude is filtered by monitoring the relative offset value of each trajectory point. When the offset amplitude of a certain trajectory segment exceeds a certain set threshold, the trajectory segment is marked as abnormal. By identifying the fluctuation range, the trajectory length fluctuation range is determined.

[0056] The behavior feature construction submodule calls the trajectory length fluctuation range, combines touch pressure data, analyzes key-clicking and swiping behaviors in different time periods, filters related behavior feature combinations, and generates a blockchain identity input behavior feature map;

[0057] By combining trajectory length fluctuation ranges with touch pressure data, further analysis of keystroke and swipe behaviors within differentiated time periods is conducted. Analysis of touch pressure data determines the pressure changes of users during specific input behaviors, thereby inferring differences in behavioral characteristics. By comparing pressure data across different time periods, input behavior segments with significant pressure fluctuations can be identified and combined with corresponding keystroke rhythms or swipe trajectory fluctuations to extract associated behavioral features. First, the touch pressure value at each moment is recorded and compared with corresponding keystroke and trajectory data. For example, when a user presses a key for a long time, the touch pressure gradually increases; thus, behavior is identified through pressure data fluctuations. Differences in keystroke and swipe behaviors across different time periods are analyzed. For instance, when a user engages in rapid keystrokes or fast swipes during input, their pressure fluctuations are correlated with fluctuations in keystroke rhythm. By filtering behavioral feature combinations within differentiated time periods, a blockchain identity input behavior feature map is generated.

[0058] Please see Figure 3 The identity behavior profiling module includes:

[0059] The transaction signature analysis submodule extracts keystroke frequency and trajectory coordinates during the blockchain transaction signing process based on the blockchain identity input behavior feature graph, using the following formula:

[0060] ;

[0061] Calculate the transaction behavior entropy value, match it with the signature benchmark library recorded in the blockchain ledger, and generate a transaction signature rhythm pattern;

[0062] Where S represents the transaction behavior entropy value, T represents the average input duration of a single transaction, V represents the trajectory turning point density, and B and U represent the longitudinal coordinate displacement rates, respectively. The timestamp interval of the k-th transaction is represented by θ, where θ is the blockchain node type correction factor and n is the number of transactions within the verification period.

[0063] Transaction behavior entropy is an indicator used to quantify the complexity and uncertainty of user input behavior during a transaction. In blockchain transaction signature analysis, entropy is calculated by comprehensively evaluating dynamic behavioral characteristics such as the rhythm, trajectory changes, and keystroke frequency of user input. Specifically, a higher entropy value indicates more complex and uncertain user input behavior, while a lower entropy value indicates simpler and more regular user behavior. Transaction behavior entropy can not only help identify whether a user's signature behavior is normal, but also distinguish between forged or abnormal transaction input behavior. By analyzing the entropy value of transaction behavior, it is possible to effectively verify whether the transaction signature conforms to a specific operating pattern, thereby improving the security and verifiability of transactions. Transaction behavior entropy is a key metric tool that helps ensure that the input behavior of each transaction is consistent with the preset normal user operation, thus enhancing the security and anti-counterfeiting capabilities of the blockchain.

[0064] Blockchain transaction signature analysis is based on the user's behavioral trajectory during the transaction input process. It first collects various dynamic data parameters during a complete transaction input, including keystroke frequency T per unit time, trajectory turning density V, the upward and downward shift values ​​U and B of the vertical coordinate movement speed, and the time interval between k consecutive transactions. The parameters include the node type influence factor θ corresponding to the device and network. All raw data have undergone dimension conversion to ensure a unified calculation basis for each parameter. For example, keystroke frequency T is measured in "keystrokes / second". Assuming a user inputs 8 times per second, T=8. The trajectory turning density V is obtained by recording the number of directional changes per unit length in the touch path. For example, if the path length is 10cm and the number of directional changes is 5, then V=0.5 (changes / cm). B and U are 0.3cm / s and 0.2cm / s, respectively. To avoid abnormal calculation values ​​with a range of 0, a lower limit for the range is set to 0.01. θ represents the degree of influence of node type on behavior fluctuations. For example, θ=1 for ordinary nodes and θ=1.2 for miner nodes. This is obtained by recording the time differences between multiple transactions. Assuming k=3, the time intervals between each transaction are 2s, 3s, and 4s respectively. , , All time units are standardized to seconds;

[0065] Part One Calculation: times / second Transformation / cm cm / s, cm / s, cm / s;

[0066] The first item is: ;

[0067] Second calculation: , ;

[0068] but: ;

[0069] Final calculation results: ;

[0070] The value S is the behavioral entropy value of this transaction signing operation, with the unit being dimensionless output. It is used to characterize the rhythm intensity of this signing operation. This value is compared within a preset rhythm intensity threshold range. The preset benchmark range is [10, 20], indicating that the behavioral intensity of a normal user should fall within this range.

[0071] The results show that S=12.419 falls within this interval, so it can be considered that the transaction input behavior matches the normal user operation behavior in terms of rhythm characteristics. This leads to the generation of a transaction signature rhythm pattern as an intermediate result for identity recognition. By performing a three-dimensional combination calculation of trajectory change density, input frequency and trajectory flow speed difference, the rhythm characteristics of the behavior are made more differentiated, thereby improving the discriminability of transaction behavior data.

[0072] The node verification feature submodule calls the transaction signature rhythm mode to analyze the device protocol stack characteristics and encryption key usage frequency in the blockchain node interaction log to obtain the node verification feature set.

[0073] The device characteristics and encryption key usage frequency of blockchain nodes will be the primary analysis targets. Based on the transmission protocols in the blockchain protocol stack, device characteristics are analyzed. By invoking the transaction signature rhythm pattern generated in the previous step, device protocol stack characteristics related to each transaction operation can be extracted and cross-analyzed with the node's encryption key usage frequency. For example, if a node uses an encryption key that triggers twice per minute during a transaction, and the communication latency in the device protocol stack is 200 milliseconds, a detailed verification feature set can be generated for the node. This feature set includes the node's characteristics at different transaction times, including communication latency, encryption key triggering frequency, and data transmission quality of the protocol stack. These features are summarized into the node's verification information and used as the basis for further identity verification, ensuring that the node's behavior conforms to the characteristic patterns of normal blockchain operation. The calculated node verification feature set and signature rhythm pattern are used together to verify the node's credibility within the entire blockchain network.

[0074] The credibility assessment submodule, based on the node verification feature set, uses the identity verification rule engine deployed by the smart contract to perform on-chain credibility weighted identification of multi-dimensional behavioral features and generate identity behavior profile tags.

[0075] An identity verification rule engine deployed through smart contracts performs weighted calculations on all collected features to construct a multi-dimensional trustworthiness model. During the calculation process, the feature values ​​of each transaction are weighted based on timestamps, and each feature is assigned a corresponding weight according to the rules of the smart contract. Specifically, assuming the rule assigns 60% weight to encryption key usage frequency and communication latency, and 40% weight to device protocol stack and signature rhythm pattern, the weights are calculated proportionally. Based on transaction time distribution and node device behavior characteristics, combined with timestamps and device fingerprints, a trustworthiness label for each transaction is derived in real time. For example, if in a certain verification process, the signature rhythm pattern score is 0.8, the encryption key usage frequency is 0.9, and the communication latency is 0.7, the weights are applied to the scores, resulting in a trustworthiness of 0.83 for the transaction, indicating that the transaction conforms to the conventional identity verification pattern. The final output trustworthiness label will generate auditable identity data for each node and transaction, ensuring the authenticity and reliability of operations within the blockchain network, and generating identity behavior profile labels.

[0076] Please see Figure 4 The contract response judgment module includes:

[0077] The behavior offset recognition submodule identifies the user's operation path in the blockchain financial identity authentication interaction based on the identity behavior profile label, calculates the offset trajectory difference between it and the registered behavior path, determines the path consistency deviation range, and obtains the behavior path offset characteristics.

[0078] First, all historical path data of the user in the blockchain financial identity authentication interaction area is obtained. This path data consists of the user's operation sequence in the identity verification process, such as the order of accessing authentication pages, the order of input fields, and authentication click behavior. Through this type of path, a stable user behavior profile can be established. Then, the user's actual operation path in the current authentication process is obtained and converted into a structured path sequence in the same way. The two sets of paths are compared, and a path trajectory difference matrix is ​​formed by calculating the number of element displacements, path length differences, and path order similarity between the two path sequences. Euclidean distance is used to calculate the degree of sequence offset. For example, if the historical path is [1, 2, 3, 4] and the current path is [1, 3, 2, 4], then the order of the two is swapped in steps 2 and 3. By setting the step size difference threshold δ=1, the number of offset points is identified as 2, and the offset ratio is determined by the proportional method. After calculating the offset trajectory, the offset value is compared with the offset tolerance threshold in the behavior profile. This threshold can be set according to different financial business levels, such as 5% for high-sensitivity businesses, 10% for medium-sensitivity businesses, and 15% for low-sensitivity businesses, to determine whether the current operation path is within the normal behavior range. If the offset value exceeds the tolerance range, it is recorded as an abnormal offset trajectory, and structured data is generated and stored. For example, if the average length of the user authentication path is 8 steps, and the offset detection shows that the current path offset step length is 3 steps, then the behavior path offset rate is 37.5%, and the behavior path offset feature is obtained.

[0079] The device fingerprint verification submodule extracts the current device fingerprint and access address based on behavior path offset features, compares its structural matching with the fingerprint combinations of previous identity authentication stored on the chain, determines the fingerprint stability level, and obtains the device trust identification factor.

[0080] Device fingerprint data includes fields such as user terminal device model, browser version, timestamp, screen resolution, and font stack order. A unique device fingerprint string is generated using a hash function. The IP address and its parsed geographic location information are obtained from the access address. Simultaneously, the set of device fingerprints matching this identity in historical authentication records on the blockchain is retrieved. The current fingerprint structure is matched and compared with the historical fingerprint set, and the field consistency rate is compared. For example, if there are 8 fingerprint fields and 6 fields match completely, the matching rate is 75%. If the current matching rate is lower than a preset trust threshold (e.g., the preset trust matching threshold is 80%), the device is determined to be an untrusted source. A secondary judgment is made based on the accessed geographical location. If the current accessed IP resolution location differs from the historical login address by a province or higher, such as "Guangzhou City, Guangdong Province" in the past and "Zhengzhou City, Henan Province" in the present, it is recorded as an address location offset event. Combined with the location offset level classification table (e.g., provincial change is severe offset, city level is moderate offset), a comprehensive judgment is made on whether the device source is trustworthy. The device trustworthiness identification factor is constructed by combining the fingerprint matching rate and geographical change level. For example, if the trust matching rate threshold is set to 80% and the address consistency level threshold is city level, and the device fingerprint matching rate is 75% and the address level offset is provincial level, the trustworthiness identification factor is determined to be "low trustworthy".

[0081] The authentication level adjustment submodule uses the following formula based on the device's trusted identification factor:

[0082] ;

[0083] Calculate the dynamic authentication complexity, match the corresponding verification scheme according to the contract rules, and generate a set of dynamic verification levels for the contract.

[0084] Where R represents dynamic authentication complexity, A represents the current path behavior vector length, H represents the original path vector length of the profile, C represents device identification consistency, J represents behavior offset signal strength, E represents authentication frequency, F represents the current access geolocation code, and G represents the on-chain record geolocation code.

[0085] Dynamic authentication complexity refers to a continuous risk metric derived from the comprehensive assessment of potential identity authenticity risks in blockchain financial identity authentication scenarios, based on multiple factors such as the degree of difference between the user's current behavior path and historical profile, the reliability of device fingerprint matching, changes in authentication frequency, and geographical offset information of access addresses. The higher the value, the greater the deviation between the current authentication behavior and the on-chain historical records, the more untrustworthy the device environment, and the more abnormal the access behavior. Higher-level authentication mechanisms are required to enhance the accuracy of identity verification. Dynamic authentication complexity integrates various heterogeneous data sources through a unified normalization processing method, enabling cross-dimensional comparability and dynamic adjustment of identity authentication security levels based on real-time data collection. It is a key indicator for realizing intelligent, risk-oriented identity verification processes.

[0086] Based on the behavioral path offset characteristics and the device trust identification factor, the normalized numerical components from both are used for joint calculation. First, the current path length is defined. Image path length If the path length difference is 1 step, then this term is set to 1 after normalization. The normalized baseline value of 10 represents the maximum range of path steps in the identity authentication process. Next, the device recognition consistency... The matching degree is derived from the fingerprint field matching score. For example, if the current fingerprint matches 6 fields and the total number of fields is 8, the matching degree is calculated as follows: That is This value is already within the normalized range of [0, 1].

[0087] Behavioral offset intensity This represents the number of offset points in the path. For example, if the path sequence changes from [1, 2, 3, 4, 5, 6, 7, 8] to [1, 3, 2, 4, 6, 5, 7, 8], there are 3 offsets. Normalizing the total step length of the identity path (8), we get... ;

[0088] Authentication frequency This refers to the number of authentication requests a user makes per unit of time, set at 5 times per hour, with a standardized baseline of a maximum allowed request frequency of 20 times per hour. ;

[0089] Access geocoding is Historical geography code is The difference between the two is 330,000. To avoid dimensional disturbances in the results due to geocoding values, the coding difference needs to be normalized. This can be done by dividing the coding difference by the maximum range of administrative region coding differences (assuming the maximum coding difference is 999,999), thus normalizing it to... ;

[0090] Substituting all normalized parameters into the formula:

[0091] ;

[0092] By jointly introducing behavioral path offset, device trust level, and address offset, and by normalizing the dimensionality of each participating item, the comparability between different feature dimensions is ensured, so that the final authentication complexity score R reflects the balanced effect of each influencing factor. The result shows that the comprehensive risk score under the current identity authentication situation is 0.5840. According to the complexity level division range set by the system, such as [0.0–0.3] as low risk, [0.3–0.6] as medium risk, and [0.6–1.0] as high risk, the result falls at the threshold between medium and high risk, and needs to enter the auxiliary verification path to generate a dynamic verification level set for the contract.

[0093] Please see Figure 5 The trusted node scheduling module includes:

[0094] The node capability scoring submodule calls the contract's dynamic verification level set to extract the average response time, authentication frequency, and consistency score of nodes in the consensus node pool. It analyzes the execution stability and response capability indicators of the nodes using the following formula:

[0095] ;

[0096] The performance score of the computing node is used to obtain the set of blockchain certified node capability indicators.

[0097] Where x is the standard response time of the node, y is the real-time response time of the node, z is the number of verification records completed by the node, m is the total number of tasks completed by the node, l is the original consistency score of the node, q is the consistency reference value set by the contract, and P represents the node execution capability score.

[0098] The node execution capability score is a numerical indicator derived from the comprehensive performance of each node in the blockchain financial identity authentication process. It is calculated by normalizing the results after unifying the units of measurement to achieve reasonable scheduling of authentication tasks among multiple consensus nodes. The score reflects the carrying capacity and stability of a single node for identity authentication tasks in the current state. The higher the score, the more stable the response, the more concentrated the verification frequency, and the closer the consistency is to the standard in the recent stage. The node can be given priority to be selected into the authentication task execution sequence. The calculation of this indicator is carried out by integrating multiple heterogeneous performance parameters to build a multi-dimensional evaluation system, thereby realizing the reasonable scheduling of distributed load of financial identity authentication tasks in the blockchain network.

[0099] The system invokes the verification level assigned by the current contract and determines the corresponding node capability requirement parameter set. Then, it extracts three key metrics for each candidate node from the blockchain network consensus node pool: average response time, historical verification frequency, and consistency score. First, it obtains the node's standard response time. This value is set according to the certification level. For example, for L3 level certification tasks, the standard response time is set to 200ms.

[0100] Next, the real-time response time y of the node is detected. This is obtained by taking the arithmetic mean of the node's last 20 response data. For example, if the response time sequence is [205, 215, 198, 220, 210], the average value is taken as the real-time response time. ms;

[0101] The response time difference is calculated here. ms, to unify the units, this value is normalized to the interval [0, 1]. The normalization benchmark is set to a maximum tolerable response difference of 500ms, resulting in... Next, we extract the verification frequency z, defined as the number of valid identity authentications completed by a node in the past hour. For example, if node A has completed 180 identity authentications, we set... ;

[0102] The total number of block processing tasks undertaken by the record node in the past 24 hours This data is reported in real time by the block generator module;

[0103] Node Consistency Score This represents the effective adoption rate of a node's submissions in the consensus process. For example, if a node achieves final consensus adoption in 94 out of its last 100 submissions, then... Preset consistency reference value , representing the theoretical maximum value, the difference is calculated as To ensure a uniform scale, the normalization reference value interval is set to [0.8, 1], i.e. ;

[0104] Substitute the above data into the calculation formula: ;

[0105] The calculated node execution capability score of node A is 0.1059, which is a dimensionless score index used for ranking across nodes. The system sets the scheduling threshold for dynamic contract scheduling to 0.08. If the score is greater than or equal to this value, it is determined to be an available node, and the score will enter the scheduling queue to participate in the ranking.

[0106] Where x represents the system-defined standard response time for the node, in milliseconds, and y represents the node's real-time average response time within the current task cycle, in milliseconds. The response time error, after normalization, is used to express differences in response performance. z represents the number of authentications completed by a node per unit time, in units of times; m represents the total number of tasks processed by a node, in units of times; l represents the percentage of times a node's submitted results are accepted, a proportion between [0, 1]; and q is the system-defined consistency reference value, which is 1. The consistency score difference is normalized to eliminate the influence of dimensional offset. P represents the node's comprehensive execution capability score. By introducing the square root operation of the response error, the ability to identify differences in response stability is enhanced. Normalization unifies and integrates performance indicators across multiple dimensions, improving the discriminativeness and adaptability of node capability scores in task scheduling. The results show that node A's current state meets the scheduling execution criteria, and its capability value can be used for subsequent screening to ultimately obtain the blockchain certified node capability index set.

[0107] The authentication node dispatching submodule selects the set of nodes with the highest index scores based on the blockchain authentication node capability index set, and determines the priority order of task distribution by combining the current timeliness requirements of the verification task and the geographical network structure of the nodes, thus obtaining the execution sequence of financial identity authentication nodes.

[0108] The capability values ​​calculated by each node are read sequentially and sorted according to their numerical values. During the sorting process, the top ten nodes are retained, whose capability values ​​are all higher than the set scheduling threshold. For example, if the capability values ​​of the top ten nodes are between [0.3366, 0.8723], it indicates that the response capability and consistency performance of these nodes are stable. Nodes with the highest execution ranking are selected from these nodes. Then, combined with the verification level requirements of the authentication tasks to be processed in the current blockchain network, the required response time limit of the task is determined. For example, when the dynamic verification level is L3, the response time is required to be no more than 300ms. The geographical deployment information and network latency data of the sorted nodes are called sequentially. Nodes with a latency of less than 200ms and located in the business center node position are selected first. Four nodes are selected from the top ten nodes as the target execution group, and their authentication execution order is generated. For example, the sequence generated by sorting according to response speed is: [N8, N3, N1, N7], that is, node N8 has the fastest response speed and is executed first, followed by node N7. Finally, an ordered scheduling task list is formed, resulting in the financial identity authentication node execution sequence.

[0109] Please see Figure 6 The block behavior writing module includes:

[0110] The identity authentication extraction submodule extracts identity information and contract verification records based on the execution sequence of financial identity authentication nodes, filters them according to identity credibility and contract matching degree, and obtains identity authentication behavior characteristics by combining identity authentication and contract verification data.

[0111] This process extracts various data points containing financial identity information and relevant verification records from the contract verification process. Based on this data and the content of the contract verification records, the matching degree between the authentication information and the verification records is analyzed. The matching process is based on the credibility of the identity authentication information and the correlation between the behaviors appearing in the contract verification records and the identity characteristics. Credibility is determined by comparing the similarity values ​​calculated by the authentication model with historical authentication data. Behavioral matching degree is obtained by calculating the difference between the frequency of the behavior and the frequency predicted by the model. For example, if a user's identity information matches a contract verification record, and the identity information credibility is 0.85 and the contract verification behavior matching degree is 0.90, then the user's authentication behavior matching degree is 0.88. This value allows for the effective derivation of a suitable behavioral feature summary, which includes the final behavioral features, such as relevant identity attributes and behavioral patterns. These features will then be used for encryption and evidence storage operations.

[0112] The issuance policy invocation submodule extracts the issuance order and encryption policy code based on the identity authentication behavior characteristics, matches the identity authentication behavior characteristics with the issuance policy, identifies the adaptability of the encryption policy code in the issuance order, and generates an encryption adaptation policy.

[0113] The features are processed according to the issuance order and encryption policy encoding. Based on the behavioral feature digest in the issuance order, the compatibility between it and each field in the encryption policy encoding is calculated. Each item in the encryption policy encoding has specific encryption parameters, such as encryption bit length and encryption rounds. These parameters need to be selected according to the user's behavioral characteristics and the contract execution requirements. The encryption compatibility calculation is performed by comparing the behavioral features with the parameters set in the encryption policy. A threshold is set; if the compatibility of the behavioral feature is greater than a predetermined benchmark value, the policy is considered to have strong compatibility. Assuming the compatibility standard of the encryption policy is set to 0.85, and the actual calculated encryption compatibility value is 0.88, it means that the policy is suitable for this behavioral feature. Through calculation, the final encryption compatibility policy is generated, which is the encryption method for this behavioral feature, providing technical support for subsequent evidence storage operations.

[0114] The evidence storage record generation submodule integrates contract execution records and identity authentication behavior characteristics according to the encryption adaptation strategy, analyzes the mapping relationship of fields in the contract execution record, constructs the blockchain writing structure of contract execution based on the mapping relationship, and generates on-chain evidence storage records for identity authentication.

[0115] Contract execution records are compared against identity authentication behavioral characteristics using field mapping to ensure all necessary information is correctly stored on the blockchain. The field mapping is dynamically adjusted based on encryption strategies and identity authentication characteristics, determining the degree of overlap between fields—that is, the matching degree between fields in the contract execution record and identity authentication characteristics—and deciding which fields require enhanced encryption based on this matching degree. After encrypting the contract execution records using an encryption adaptation strategy, a blockchain-written evidence storage structure template is established. This template contains identity authentication information, encryption strategies, and detailed records of contract execution. Through this process, all authentication and contract data can be structured and stored on the blockchain, generating on-chain evidence storage records for identity authentication.

[0116] The above are merely preferred embodiments of the present invention and are not intended to limit the present invention in any other way. Any person skilled in the art may make changes or modifications to the above-disclosed technical content to create equivalent embodiments that can be applied to other fields. However, any simple modifications, equivalent changes, and modifications made to the above embodiments based on the technical essence of the present invention without departing from the scope of the present invention shall still fall within the protection scope of the present invention.

Claims

1. A blockchain-based financial identity authentication system, characterized in that, The system includes: The behavioral feature acquisition module obtains input behavior data from the financial identity authentication registration page, collects user keystroke rhythm, swipe trajectory and touch pressure, extracts rhythm sequence and trajectory offset, compares trajectory length and duration fluctuation, filters high-frequency behavioral feature combinations, and generates a blockchain identity input behavior feature map. The behavioral feature acquisition module includes: The keystroke rhythm extraction submodule obtains input behavior data from the financial identity authentication registration page, extracts keystroke intervals and arranges them in order, analyzes the interval fluctuation amplitude, filters the key keystroke time periods of fluctuation amplitude, and generates a keystroke rhythm fluctuation feature map. The trajectory parameter recognition submodule extracts the sliding trajectory data input by the user based on the keystroke rhythm fluctuation feature map, identifies the path length and offset angle, analyzes the fluctuation of trajectory length and input duration, and filters the input behavior segments with offset amplitude to obtain the trajectory length fluctuation range. The behavior feature construction submodule calls the trajectory length fluctuation range, combines it with touch pressure data, analyzes key-clicking and swiping behaviors in different time periods, filters related behavior feature combinations, and generates a blockchain identity input behavior feature map. The identity behavior profiling module is based on the blockchain identity input behavior feature map, combined with terminal model, typing frequency and trajectory flow, to identify operation rhythm and device habits, extract input method and terminal matching features, and generate identity behavior profile tags. The contract response judgment module extracts user behavior data based on the identity behavior profile tags, analyzes the degree of deviation between the current input path and the original behavior tags, and combines the device fingerprint and access address to determine whether the authentication mechanism level needs to be adjusted according to the contract conditions, and generates a dynamic verification level set for the contract. The trust node scheduling module calls the contract dynamic verification level set, retrieves the response time, verification frequency and consistency score in the consensus node pool, evaluates the execution capabilities of the nodes and sorts them, selects the top-ranked node groups for verification task assignment, and obtains the financial identity authentication node execution sequence.

2. The blockchain financial identity authentication system according to claim 1, characterized in that, The blockchain identity input behavior feature map includes keystroke rhythm difference factor, trajectory angle offset index, input stability measure, behavior pattern correlation degree, and input fluctuation frequency. The blockchain identity behavior profile label includes terminal adaptation feature, operation rhythm label, input method preference, behavior inertia parameter, and device usage feature. The contract dynamic verification level set includes path deviation magnitude, fingerprint consistency level, address trust weight, authentication dynamic identifier, and contract response label. The financial identity authentication node execution sequence includes response delay sorting, verification task number, node execution weight, allocation scheduling parameter, and consensus priority label.

3. The blockchain financial identity authentication system according to claim 1, characterized in that, The identity behavior profiling module includes: The transaction signature analysis submodule extracts the keystroke frequency and trajectory coordinates during the blockchain transaction signing process based on the blockchain identity input behavior feature map, calculates the transaction behavior entropy value, performs pattern matching with the signature benchmark library recorded in the blockchain ledger, and generates a transaction signature rhythm pattern. The node verification feature submodule calls the transaction signature rhythm mode to analyze the device protocol stack features and encryption key usage frequency in the blockchain node interaction log to obtain the node verification feature set. The credibility assessment submodule, based on the node verification feature set, uses the identity verification rule engine deployed by the smart contract to perform on-chain credibility weighted identification of multi-dimensional behavioral features and generate identity behavior profile tags.

4. The blockchain financial identity authentication system according to claim 3, characterized in that, The contract response determination module includes: The behavior offset recognition submodule identifies the user's operation path in the blockchain financial identity authentication interaction based on the identity behavior profile label, calculates the offset trajectory difference between the user and the registered behavior path, determines the path consistency deviation range, and obtains the behavior path offset features. Based on the behavior path offset features, the device fingerprint verification submodule extracts the current device fingerprint and access address, compares its structural matching with the fingerprint combinations of previous identity authentications stored on the chain, determines the fingerprint stability level, and obtains the device trust identification factor. The authentication level adjustment submodule calculates the dynamic authentication complexity based on the device's trusted identification factor, matches the corresponding verification scheme according to the contract rules, and generates a set of dynamic verification levels for the contract.

5. The blockchain financial identity authentication system according to claim 4, characterized in that, The trusted node scheduling module includes: The node capability scoring submodule calls the contract dynamic verification level set, extracts the average response time, identity verification frequency and consistency score of the nodes in the consensus node pool, analyzes the execution stability and response capability indicators of the nodes, calculates the node execution capability score value, and obtains the blockchain certified node capability indicator set. The authentication node dispatching submodule selects the set of nodes with the highest index scores based on the blockchain authentication node capability index set, and determines the priority order of task distribution by combining the current timeliness requirements of the verification task and the geographical network structure relationship of the nodes, thus obtaining the financial identity authentication node execution sequence.

6. The blockchain financial identity authentication system according to claim 1, characterized in that, The system also includes a block behavior writing module: The block behavior writing module extracts the identity authentication result and contract verification process record based on the execution sequence of the financial identity authentication node, calls the issuance order and encryption strategy encoding, integrates the behavior feature summary and contract execution record and writes it into the ledger to obtain the on-chain evidence storage record of identity authentication. The evidence storage records on the identity authentication chain include authentication result summary, execution process label, feature hash code, issuance encryption identifier, and ledger index entry.

7. The blockchain financial identity authentication system according to claim 6, characterized in that, The block behavior writing module includes: The identity authentication extraction submodule extracts identity information and contract verification records based on the execution sequence of the financial identity authentication node, filters them according to identity credibility and contract matching degree, and obtains identity authentication behavior characteristics by combining identity authentication and contract verification data. The issuance policy invocation submodule extracts the issuance order and encryption policy code based on the identity authentication behavior characteristics, matches the identity authentication behavior characteristics with the issuance policy, identifies the adaptability of the encryption policy code in the issuance order, and generates an encryption adaptation policy. The evidence storage record generation submodule integrates contract execution records and identity authentication behavior features according to the encryption adaptation strategy, analyzes the mapping relationship of fields in the contract execution record, constructs the blockchain writing structure of contract execution based on the mapping relationship, and generates on-chain evidence storage records for identity authentication.

Images