A blockchain-based method and system for storing evidence of the condition of a used vehicle

Abstract

The application provides a kind of second-hand vehicle condition information evidence storage method and system based on blockchain, belongs to vehicle data processing and blockchain application technical field, first, the fault code log of target vehicle, the accumulated driving time after fault code clearing and the prior probability distribution data of the same model are obtained. Then, the term frequency value is calculated according to the number of fault codes, and the term frequency value is corrected by using the gain coefficient determined by the accumulated driving time to generate the term frequency vector. Then, the inverse document frequency is calculated combined with the prior data, the fault spectrum is constructed by projection mapping and the health hazard index is aggregated. Homomorphic encryption is carried out on the health hazard index by Pedersen commitment, and logical proof information is generated by zero-knowledge range proof. Finally, the proof information and the encrypted commitment are packaged and chained, and after the node consensus verification, the previous block is cascaded and locked to complete the information storage. The application realizes the privacy protection and tamper-proof storage of vehicle condition data.

Description

Technical Field

[0001] This application belongs to the field of vehicle data processing and blockchain application technology, and in particular relates to a method and system for storing evidence of the condition of used cars based on blockchain. Background Technology

[0002] With the rapid development of the used car market, the authenticity of vehicle condition data has become a core factor affecting trust and valuation in transactions. Blockchain technology, with its decentralized and immutable characteristics, provides a reliable solution for the notarization and traceability of vehicle lifecycle data, demonstrating broad application prospects in building a transparent trading environment.

[0003] Existing blockchain-based methods for documenting used cars typically involve directly uploading or generating hash digests of raw information such as vehicle maintenance records, insurance claim data, or mileage readings and recording them on a distributed ledger. This approach primarily focuses on ensuring that the data is not maliciously tampered with by third parties after its generation, thereby establishing a static historical record for the vehicle.

[0004] However, existing methods typically lack the ability to identify temporary concealment behaviors such as deliberately clearing fault codes before a transaction, and directly uploading detailed fault logs can easily lead to the leakage of specific repair privacy. Furthermore, simply piling up records cannot quantitatively assess the severity of potential health hazards by combining them with the vehicle model's historical fault probability, making it difficult for buyers to intuitively judge the true risk. Therefore, existing technologies suffer from insufficient evidence of vehicle condition information due to their inability to effectively identify vehicle condition concealment behaviors and their difficulty in achieving quantifiable risk evidence preservation while protecting data privacy. Summary of the Invention

[0005] The purpose of this application is to provide a blockchain-based method and system for storing vehicle condition information of used cars, in order to solve the problem of insufficient vehicle condition information storage in the existing technology.

[0006] To address the aforementioned technical issues, firstly, this application provides a blockchain-based method for storing evidence of the condition of used cars, comprising: Obtain the fault code log sequence of the target vehicle, the cumulative driving time after the fault codes are cleared, and the prior probability distribution data of fault codes of the same model throughout its entire life cycle; Based on the frequency of occurrence of different fault codes in the fault code log sequence, the word frequency value of each fault code is obtained, and the gain coefficient is determined according to the cumulative driving time to correct the word frequency value, thus obtaining the word frequency vector of each fault code. Based on the prior probability distribution data, the inverse document frequency of each fault code in the entire set of the same model is determined. The term frequency vector of each fault code and the corresponding inverse document frequency are projected and mapped to obtain the fault spectrum. The multi-dimensional feature components of the fault spectrum are weighted and aggregated using linear weighting to obtain the health hazard index. The health risk index is homomorphically encrypted using Pedersen commitments to obtain encrypted commitment values, and the health risk index is logically verified using zero-knowledge scope proofs and polynomial verifications to obtain logical proof information. Logical proof information, encrypted commitment value, and vehicle identification code are encapsulated into an on-chain transaction package and broadcast to the blockchain. After the logical proof information is validated by the blockchain's node consensus protocol, the evidence record, including the verification result, timestamp, and transaction hash value, is cascaded and locked with the preceding block in the blockchain to obtain the information evidence record.

[0007] Optionally, before determining the inverse document frequency of each fault code in the entire set of the same vehicle model based on prior probability distribution data, and projecting and mapping the term frequency vector and corresponding inverse document frequency of each fault code to obtain the fault map, the method further includes: Obtain the cumulative number of power-on cycles of the control unit of the target vehicle within the cumulative driving time; The power-on frequency of the target vehicle within a unit of time is determined based on the ratio of the cumulative number of power-on cycles to the cumulative driving time. The masking risk coefficient is calculated based on the ratio between the power-on frequency and the preset power-on frequency reference. The word frequency vector is adjusted by weighting it using the masking risk coefficient, resulting in an updated word frequency vector.

[0008] Optionally, based on the frequency of different fault codes in the fault code log sequence, the term frequency value of each fault code is obtained, and a gain coefficient is determined based on the cumulative driving time to correct the term frequency value, resulting in a term frequency vector for each fault code, including: Calculate the number of times different fault codes appear repeatedly in the fault code log sequence to obtain the term frequency value of each fault code; The ratio of the cumulative driving time to the preset reference cycle time is calculated to obtain the cycle completion rate. Based on the cycle completion rate, the gain coefficient is obtained according to the preset mapping relationship between the cycle completion rate and the gain coefficient. The product of the word frequency value and the gain coefficient is calculated to obtain the weighted word frequency value of each fault code. The word frequency vector of each fault code is obtained by multiplying the weighted word frequency value with the corresponding preset benchmark vector.

[0009] Optionally, based on prior probability distribution data, the inverse document frequency of each fault code in the entire set of the same vehicle model is determined. The term frequency vector and corresponding inverse document frequency of each fault code are then projected and mapped to obtain a fault map, including: Extract the probability value of each fault code in the entire set of the same model from the prior probability distribution data, and perform logarithmic operation on the reciprocal of the probability value to obtain the corresponding inverse document frequency; The target term frequency vector for each fault code is obtained by calculating the numerical product of the inverse document frequency and the corresponding term frequency vector. All target word frequency vectors are mapped to a preset multi-dimensional feature coordinate system to obtain a spatial distribution set consisting of multiple discrete vector points, and the spatial distribution set is determined as the fault map.

[0010] Optionally, a health hazard index is obtained by using linear weighting to perform weighted aggregation of multi-dimensional feature components on the fault map, including: Extract the component values ​​of each dimension of the target word frequency vector in the fault map in the multi-dimensional feature coordinate system; The product of the component values ​​of each dimension and the corresponding preset risk coefficient is accumulated to obtain the fault risk value corresponding to each target word frequency vector; The health hazard index is obtained by summing up all the fault risk values.

[0011] Optionally, the health hazard index is homomorphically encrypted using Pedersen commitments to obtain an encrypted commitment value, and the health hazard index is logically verified using zero-knowledge range proofs and polynomial verifications to obtain logical proof information, including: The encrypted commitment value is obtained by performing a point addition operation on the result of the scalar multiplication of the preset first elliptic curve base point and the health risk index and the result of the scalar multiplication of the preset second elliptic curve base point and the preset random blinding factor. Construct an interval constraint polynomial that satisfies the health hazard index being within a preset legal value range, and use a random blinding factor to perform verifiable calculations on the interval constraint polynomial to generate interval proof data; Construct a verification polynomial with the health risk index as a specific order coefficient, and use a pre-set public reference string to perform bilinear pairing calculation on the verification polynomial to generate polynomial proof data. By using data splicing, the interval proof data and the polynomial proof data are concatenated, recombined, and encapsulated to obtain logical proof information.

[0012] Optionally, after the logical proof information is validated through the blockchain's node consensus protocol, the evidence record, including the verification result, timestamp, and transaction hash value, is concatenated and locked with the preceding block in the blockchain to obtain an information evidence record, including: When the logical proof information passes verification, a verification pass identifier is generated as the verification result. The verification result, the current timestamp, and the transaction hash value corresponding to the on-chain transaction package are serialized and concatenated to generate a proof record. The digital fingerprint of the evidence record is calculated using a hash algorithm, the chain tail hash value of the preceding block in the blockchain is extracted, and the block header data is obtained by concatenating the chain tail hash value with the digital fingerprint. By performing a one-way hash operation on the block header data, a block hash value is generated. The block hash value is then associated with the evidence storage record and written into the distributed ledger of the blockchain to obtain the information evidence storage record.

[0013] Secondly, this application provides a blockchain-based used car condition information storage system, including: The acquisition module is used to acquire the fault code log sequence of the target vehicle, the cumulative driving time after the fault codes are cleared, and the prior probability distribution data of fault codes of the same model throughout its entire life cycle. The generation module is used to obtain the word frequency value of each fault code based on the number of times different fault codes appear in the fault code log sequence, and to correct the word frequency value based on the gain coefficient determined by the cumulative driving time, so as to obtain the word frequency vector of each fault code. The generation module is also used to determine the inverse document frequency of each fault code in the entire set of the same model based on the prior probability distribution data, project and map the word frequency vector and the corresponding inverse document frequency of each fault code to obtain the fault map, and use linear weighting to perform weighted aggregation of multi-dimensional feature components of the fault map to obtain the health hazard index. The verification module is used to homomorphically encrypt the health hazard index using Pedersen commitments to obtain the encrypted commitment value, and to logically verify the health hazard index using zero-knowledge scope proofs and polynomial verifications to obtain logical proof information. The locking module is used to encapsulate logical proof information, encrypted commitment value and vehicle identification code into on-chain transaction package and broadcast it to the blockchain. After the logical proof information is verified for validity by the blockchain's node consensus protocol, the evidence record including the verification result, timestamp and transaction hash value is cascaded and locked with the previous block in the blockchain to obtain the information evidence record.

[0014] Thirdly, this application provides an electronic device, comprising: Memory, used to store computer programs; A processor is configured to execute the computer program to implement the steps of the blockchain-based used car condition information storage method described in the first aspect above.

[0015] Fourthly, this application provides a computer-readable storage medium storing a computer program, which, when executed by a processor, can implement the steps of the blockchain-based used car condition information storage method described in the first aspect above.

[0016] The blockchain-based method for storing used car condition information provided in this application firstly effectively identifies malicious attempts to conceal fault codes before a transaction by combining the cumulative driving time after fault code clearance, thus ensuring the authenticity and integrity of the stored data. Subsequently, by utilizing the prior probability distribution of fault codes throughout the entire lifecycle of the same vehicle model, an inverse document frequency reflecting the scarcity and severity of faults is constructed, accurately quantifying potential health hazards of the vehicle and solving the problem that existing technologies struggle to scientifically assess vehicle condition risks.

[0017] Meanwhile, by employing Pedersen commitments and zero-knowledge-scope proof technology, the encrypted verification and on-chain storage of the health hazard index are achieved without disclosing specific repair and fault details. This protects both the owner's privacy and the buyer's right to know about the vehicle's compliance. Therefore, this application achieves highly reliable information storage that balances vehicle condition authenticity verification, risk quantification assessment, and privacy protection.

[0018] Furthermore, this application first obtains the cumulative number of power-on cycles of the control unit and calculates the power-on frequency within a unit of time by combining the cumulative driving time. This can effectively identify abnormal operating behaviors that attempt to mask the fault code recurrence cycle by frequently cutting off power or powering on for very short periods.

[0019] Subsequently, based on the concealment risk coefficient generated by the abnormal power-on frequency, the original word frequency vector was adjusted with targeted weights, significantly improving the sensitivity and recognition accuracy of the health hazard index against malicious concealment behavior, and preventing interference from more covert cheating methods in vehicle condition assessment. Therefore, this application further strengthens the defense capability of the stored evidence data against human fraud by introducing multi-dimensional operational feature verification, ensuring the high authenticity and credibility of the stored evidence of used car condition information. Attached Figure Description

[0020] To more clearly illustrate the technical solutions of the embodiments of this application or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are only some embodiments of this application. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0021] Figure 1 A flowchart illustrating a blockchain-based method for storing evidence of used car condition information, provided in an embodiment of this application; Figure 2 A flowchart illustrating a method for generating word frequency vectors provided in an embodiment of this application; Figure 3 A flowchart illustrating a method for generating encrypted commitment values ​​and logical proof information, provided in an embodiment of this application; Figure 4A schematic diagram of a blockchain-based used car condition information storage system provided in this application embodiment; Figure 5 This is a schematic diagram of the hardware structure of an electronic device provided in one embodiment of this application. Detailed Implementation

[0022] Current technologies for documenting the condition of used cars often limit themselves to uploading static repair lists or mileage snapshots to the blockchain. While this prevents data tampering to some extent, it lacks effective dynamic identification methods for maliciously clearing fault codes before a transaction, leading to vehicles that appear to have no problems actually harboring hidden issues. Furthermore, directly uploading plaintext fault logs to the blockchain not only leaks the owner's repair privacy but also makes it difficult for ordinary buyers to intuitively quantify the vehicle's true health risks due to the massive amount of technical code, resulting in an irreconcilable conflict between transparency and privacy protection.

[0023] To address the aforementioned issues, this application proposes a blockchain-based method for storing vehicle condition information in used cars. Its core lies in constructing a dynamic evidence storage system that integrates behavioral analysis and privacy computing. Specifically, this application combines the cumulative driving time after fault code clearance with the prior probability of faults throughout the entire lifecycle of the same vehicle model to accurately calculate the word frequency vector and inverse document frequency reflecting the scarcity of faults and the risk of concealment, thereby quantifying and generating a health hazard index. Furthermore, it utilizes Pedersen commitments and zero-knowledge scope proof technology to complete the encrypted verification and on-chain evidence storage of the hazard index without exposing specific repair details.

[0024] This method abandons the traditional static data stacking mode. Through the weighted aggregation of multi-dimensional features and cryptographic proof, it effectively identifies the behavior of concealing vehicle condition and achieves a balance between risk quantification and privacy protection. It solves the problems of evidence distortion and privacy leakage caused by the lack of dynamic behavior analysis and privacy computing in existing technologies, and significantly improves the trust mechanism and data security of used car transactions.

[0025] To enable those skilled in the art to better understand the present application, the present application will be further described in detail below with reference to the accompanying drawings and specific embodiments. Obviously, the described embodiments are merely some embodiments of the present application, and not all embodiments. Based on the embodiments in this application, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this application.

[0026] To address the problems of existing technologies, this application provides a method, apparatus, device, computer storage medium, and computer program product for storing used car condition information based on blockchain. The method for storing used car condition information based on blockchain provided in this application will be described below.

[0027] Figure 1 This illustration shows a flowchart of a blockchain-based method for storing evidence of used car condition information according to an embodiment of this application. Figure 1 As shown, the method includes: S101. Obtain the fault code log sequence of the target vehicle, the cumulative driving time after the fault codes are cleared, and the prior probability distribution data of fault codes of the same model throughout its entire life cycle.

[0028] A fault code log sequence refers to a set of fault records read from the vehicle's electronic control unit, arranged chronologically. Specifically, this sequence refers to the set of fault code records newly generated within the current accumulated driving time since the last fault code clearing command was executed on the target vehicle. This sequence includes not only standard OBD-II fault codes but also status bit information for each fault code when it was triggered.

[0029] Cumulative driving time refers to the total time the engine has run and driven the vehicle since the last time a fault code clearing command was executed. This metric is used to determine whether the vehicle has completed a sufficient number of driving cycles to expose potential faults. Prior probability distribution data refers to the set of occurrence probabilities of each fault code at different mileage stages, derived from statistical analysis of massive amounts of maintenance data from vehicles of the same model.

[0030] In practice, diagnostic data is directly read from the vehicle gateway via the CAN bus protocol by connecting to the vehicle's OBD interface or using an onboard T-BOX terminal. First, the fault code log sequence stored in non-volatile memory is extracted. ,in Indicates the first The recorded fault codes include P0300 fire fault.

[0031] Next, read the Mode from the Engine Control Module (ECM). Data stream, retrieves the cumulative runtime since the last DTCs were cleared. Simultaneously, prior probability distribution data for the same model as the target vehicle is downloaded from the A brand vehicle repair database on the cloud server. ,in Indicates the first The average occurrence probability of a fault code over the entire life cycle of the same model is as follows: for example, the occurrence rate of the P0420 low catalytic converter efficiency fault is 5%.

[0032] S102. Based on the frequency of different fault codes in the fault code log sequence, obtain the word frequency value of each fault code, and determine the gain coefficient based on the cumulative driving time to correct the word frequency value, thereby obtaining the word frequency vector of each fault code.

[0033] Optionally, step S102, which obtains the term frequency value of each fault code based on the frequency of occurrence of different fault codes in the fault code log sequence, and corrects the term frequency value by determining a gain coefficient based on the cumulative driving time, to obtain the term frequency vector of each fault code, may specifically include: Figure 2 A flowchart illustrating a method for generating word frequency vectors according to an embodiment of this application is shown. Figure 2 As shown, the method includes: S1021. Calculate the number of times different fault codes appear repeatedly in the fault code log sequence to obtain the word frequency value of each fault code.

[0034] The term frequency value refers to the frequency of a sequence of fault codes in the acquired fault code log. The absolute frequency of a specific fault code, and this value directly reflects the activity level of the fault in the current vehicle history.

[0035] In the specific implementation process, the fault code log sequence obtained from step S101 is first traversed. For each individual fault code type in the sequence, a counter is set up, and the counter is incremented every time the fault code occurs. Finally, the count results for all fault codes are aggregated to generate a set of word frequency values. ,in Indicates the first Fault codes in sequence The number of times it appears in the text.

[0036] For example, suppose a fault code log sequence P0300 appeared 3 times, P0420 appeared once, and P0171 appeared once. The corresponding word frequencies are as follows: .

[0037] S1022. Calculate the ratio of the cumulative driving time to the preset reference cycle time to obtain the cycle completion rate. Based on the cycle completion rate, and according to the preset mapping relationship between the cycle completion rate and the gain coefficient, obtain the gain coefficient.

[0038] Cycle completion rate refers to the ratio of the actual operating time of the vehicle since the last fault code clearing to the time required for the standard inspection cycle, and is used to measure whether the vehicle has undergone sufficient operating conditions to fully expose potential faults. The gain coefficient is a correction factor calculated based on cycle completion rate, used to adjust the weight of word frequency values ​​and prevent the risk of missed detection due to insufficient fault exposure caused by short driving time. The preset reference cycle duration is shown in Table 1 below: Table 1: Reference Period Duration Table

[0039] As shown in Table 1, the preset reference period duration Depending on the vehicle type and emission standards, the settings typically correspond to the shortest time required to complete a full OBD driving cycle, ensuring that all readiness monitoring bits can complete their self-checks.

[0040] The preset mapping relationship between cycle completion and gain coefficient is shown in Table 2 below: Table 2: Mapping Relationship between Cycle Completion and Gain Coefficient

[0041] As shown in Table 2, this mapping relationship is determined based on the fault exposure probability model of the same vehicle model in standard bench testing. Specifically, a large amount of fault code detection data of the same vehicle model under different driving durations was collected to construct the fault detection rate. Over time The cumulative distribution function of the change.

[0042] Gain coefficient The computational basis stems from a fault exposure probability model of the same vehicle model in standard bench testing. In practical implementation, to reduce off-chain computational complexity, this probability model formula is used beforehand. The theoretical values ​​for different cycle completion rates were calculated and then processed using piecewise linearization, solidified into a preset mapping table as shown in Table 2, so as to adapt to the real-time cycle completion rate. Directly look up the table for retrieval.

[0043] When the cycle completion rate is low, the fault detection rate is low. The gain coefficient is extremely low, and the calculated gain coefficient is relatively large, which means that the recorded fault frequency needs to be compensated for the unexposed probability risk through the amplification factor; when the cycle completion rate is close to or exceeds 100%, the gain coefficient approaches 1, indicating that the fault record at this time has become more realistic and stable.

[0044] In the specific implementation process, the first step is to refer to Table 1 based on the target vehicle's model information to determine the corresponding preset reference cycle length. Next, the accumulated driving time obtained in S101 is used. and Perform division to calculate the period completion rate. Then, the calculated... Match the values ​​with the intervals in Table 2 to find the corresponding gain coefficients. .

[0045] For example, assuming the target vehicle is a Class A sedan meeting the China VI B emission standard, referring to Table 1, we can see... Hours. If the cumulative driving time obtained in S101 If an hour is 30 minutes, then the completion rate of the calculation period is calculated. According to Table 2, when When, the corresponding gain coefficient This indicates that although the vehicle has been driven for a short time and the fault codes may not have been fully reproduced, by introducing a gain factor of 1.8, the weight of the recorded faults is amplified in advance, thereby effectively identifying risky behaviors that attempt to cover up the vehicle's condition by clearing the codes in a short period of time.

[0046] S1023. Calculate the product of the word frequency value and the gain coefficient to obtain the weighted word frequency value of each fault code, and obtain the word frequency vector of each fault code by multiplying the weighted word frequency value with the corresponding preset reference vector.

[0047] The weighted word frequency value refers to the fault frequency value after gain coefficient correction, and comprehensively reflects the absolute number of fault occurrences and the completeness of the current detection cycle. The preset baseline vector refers to the unit direction vector assigned to each fault code in the multi-dimensional feature space, used to map the scalar weighted word frequency value into a vector form with spatial attributes. The preset baseline vectors are shown in Table 3 below: Table 3: Preset Reference Vector Comparison Table

[0048] As shown in Table 3, each individual fault code corresponds to a unique reference vector. These vectors are typically orthogonal or linearly independent in the feature space to ensure the independence between different fault features.

[0049] In the specific implementation process, the word frequency values ​​obtained in step S1021 are first used. The gain coefficient obtained in step S1022 Perform multiplication to calculate the weighted word frequency value. Next, refer to Table 3 based on the fault code ID to obtain the corresponding preset reference vector. Finally, the scalar with vector Perform scalar multiplication to obtain the final term frequency vector for each fault code. .

[0050] This embodiment introduces cumulative driving time as a dynamic correction factor while statistically analyzing the basic frequency of fault codes, and calculates a gain coefficient that reflects the integrity of the detection cycle. This effectively solves the problem of underestimating potential risks caused by maliciously clearing fault codes before a transaction, and accurately quantifies the potential risk of fault recurrence.

[0051] Optionally, before determining the inverse document frequency of each fault code in the entire set of the same model based on the prior probability distribution data in step S103, and projecting the term frequency vector and the corresponding inverse document frequency of each fault code to obtain the fault map, the method further includes: Obtain the cumulative number of power-on cycles of the control unit of the target vehicle within the cumulative driving time.

[0052] The cumulative number of power-on cycles refers to the cumulative driving time obtained in S101. The total number of times the vehicle's ignition switch switches from the off state to the on state during this period, and this data is stored in the non-volatile memory of the engine control unit, is an important basis for determining whether the vehicle frequently starts and stops.

[0053] In practice, specific UDS (Unified Diagnostic Service) commands are sent through the OBD interface, such as reading the service ID. The data identifier directly retrieves the ignition cycle counter value recorded internally by the ECU. First, it reads the initial count value at the time the fault code was cleared. Then read the count value at the current moment. The cumulative number of power-on cycles is calculated by the difference between the two. .

[0054] The power-on frequency of the target vehicle within a unit of time is determined by the ratio of the cumulative number of power-on cycles to the cumulative driving time.

[0055] The power-on frequency per unit time refers to the average number of ignition starts performed by the vehicle during one hour of driving, and this indicator is used to measure whether the vehicle's usage pattern is abnormal. Under normal driving conditions, the power-on frequency is usually stable within a certain range. However, in order to quickly complete the driving cycle and cover up the fault code recurrence cycle, malicious operators often frequently start and stop the vehicle in a very short period of time.

[0056] In the specific implementation process, the cumulative number of power-on cycles obtained using the aforementioned steps is used. The cumulative driving time obtained from S101 Perform division to calculate the power-on frequency per unit time. For example, if the cumulative number of power-on cycles... times, cumulative driving time The calculated power-on frequency is [hour]. times / hour.

[0057] The masking risk coefficient is calculated based on the ratio between the power-on frequency and the preset power-on frequency reference.

[0058] The preset power-on frequency benchmark refers to the standard reference value of the average number of ignitions per hour, calculated based on statistical data of normal usage habits of the same vehicle model. The masking risk coefficient is a dimensionless index calculated based on the deviation between the actual frequency and the benchmark frequency, used to quantify the possibility that the current vehicle operation behavior constitutes malicious masking of a fault. The preset power-on frequency benchmarks are shown in Table 4 below: Table 4: Power-on Frequency Reference Table

[0059] As shown in Table 4, different types of vehicles have different normal power-on frequency references due to their different uses. There are also some differences.

[0060] In the specific implementation process, first refer to Table 4 according to the vehicle type to determine the corresponding preset power-on frequency reference. Next, the calculated actual power frequency was used. Compared with the benchmark Perform a comparison calculation. If the actual frequency... Less than or equal to the benchmark If the actual frequency is 1, then there is no risk of masking, and the coefficient is set to 1. Greater than the benchmark Then through the formula Calculate the concealment risk coefficient .

[0061] The word frequency vector is adjusted by weighting it using the masking risk coefficient, resulting in an updated word frequency vector.

[0062] The updated term frequency vector refers to the fault feature vector after being weighted and amplified by the masking risk coefficient. It strengthens the weight of fault codes recorded in abnormal operating modes and makes even occasional fault records prominent in health assessments.

[0063] In the specific implementation process, the calculated concealment risk coefficient is used. The original term frequency vector for each fault code generated in step S102 Perform scalar multiplication. Specifically, multiply the vectors... Each component in the equation is multiplied by a coefficient. The updated word frequency vector is obtained. .

[0064] This embodiment can effectively identify covert behaviors that attempt to quickly complete the driving cycle by frequently starting short-term, and uses a risk coefficient generated based on the deviation of the reference frequency to perform secondary weighting on the fault feature vector, which significantly improves the sensitivity of the health hazard index to malicious operations and prevents the interference of covert cheating methods on vehicle condition assessment.

[0065] S103. Based on the prior probability distribution data, determine the inverse document frequency of each fault code in the entire set of the same model. Project and map the term frequency vector and the corresponding inverse document frequency of each fault code to obtain the fault map. Use linear weighting to perform weighted aggregation of multi-dimensional feature components on the fault map to obtain the health hazard index.

[0066] Optionally, step S103, which involves determining the inverse document frequency of each fault code in the entire set of the same vehicle model based on prior probability distribution data, and projecting the term frequency vector and corresponding inverse document frequency of each fault code to obtain the fault map, may specifically include: S1031. Extract the probability value of each fault code in the entire set of the same model from the prior probability distribution data, and perform logarithmic operation on the reciprocal of the probability value to obtain the corresponding inverse document frequency.

[0067] The probability of occurrence refers to the proportion of samples in which a specific fault code is recorded throughout the entire lifecycle of the same vehicle model, out of the total number of samples, reflecting the prevalence of that fault. Inverse Document Frequency (IDF) is an important indicator for measuring the scarcity and information content of fault codes. In this technical solution, the entire set of fault codes for the same vehicle model is analogous to a full document set in text processing, and the current fault log of the target vehicle is analogous to the currently processed document.

[0068] Within the TF-IDF algorithm framework, the rarer the fault, the lower its probability of occurrence, the greater the amount of feature information it contains, and the higher its corresponding inverse document frequency. In the field of used car condition assessment, rare fault codes for specific models, such as extremely low catalytic converter efficiency or internal errors in core control modules, usually indicate deep systemic degradation rather than wear and tear on vulnerable parts. Their potential risk is far higher than that of common, occasional sensor interference faults, thus assigning them higher weights aligns with risk quantification logic. Conversely, the weight of common, occasional faults is correspondingly reduced.

[0069] In the specific implementation process, the prior probability distribution data is first obtained from S101. In the middle, read the first The probability value of occurrence corresponding to each fault code Next, the inverse document frequency of the fault code is calculated using a logarithmic function. The specific calculation formula is as follows: .

[0070] S1032. Calculate the numerical product of the inverse document frequency and the corresponding term frequency vector to obtain the target term frequency vector for each fault code.

[0071] The target word frequency vector refers to the fault feature vector after inverse document frequency weighting correction, which combines the fault's activity level on the current vehicle (i.e., word frequency) with its scarcity in the entire set of the same model (IDF).

[0072] In the specific implementation process, the inverse document frequency calculated in step S1031 is used. With the word frequency vector generated in step S102 Perform scalar multiplication. Specifically, multiply the vectors... Each component in the scalar is multiplied by the scalar. The target word frequency vector is obtained. .

[0073] S1033. Map all target word frequency vectors to a preset multi-dimensional feature coordinate system to obtain a spatial distribution set consisting of multiple discrete vector points, and determine the spatial distribution set as a fault map.

[0074] A multidimensional feature coordinate system refers to a predefined high-dimensional mathematical space where each coordinate axis represents the health dimension or fault attribute of different vehicle subsystems such as the engine, transmission, and emission system. In specific implementations, a fault mapping matrix is ​​pre-defined. And this matrix It stores the fault code ID for each standard and N system dimensions, i.e. ... The attribution weight relationship between them. For example, for That is, a fire fault, which is in the matrix Chinese correspondence That is, the mapping weight of the ignition system is 1.0, while the weight of other dimensions is 0.

[0075] A fault map refers to the distribution of points in a high-dimensional coordinate system, consisting of the target word frequency vectors corresponding to all fault codes, which visually represents the degree of damage to the vehicle in various health dimensions. The preset multi-dimensional feature coordinate system is shown in Table 5 below: Table 5: Reference Table of Preset Multidimensional Feature Coordinate Systems

[0076] As shown in Table 5, this coordinate system typically includes multiple orthogonal feature dimensions, each corresponding to a specific type of vehicle system fault attribute.

[0077] In the specific implementation process, firstly, the fault mapping matrix is ​​determined according to Table 5. Subsequently, each target word frequency vector generated in step S1032 is... Projecting the fault code as a vector point in space involves transforming the original numerical value of the fault code dimension onto the corresponding subsystem feature axis through matrix multiplication. Ultimately, the set... This constitutes the vehicle's fault map. For example, assume the vehicle simultaneously has P0300, which affects... Dimensions and P0420, i.e., influence For dimensional faults, the fault map is in There is a component with a fixed mold length on the shaft. There is a component with a fixed modulus length on the shaft.

[0078] Optionally, the process of using linear weighting to perform weighted aggregation of multi-dimensional feature components of the fault map to obtain the health hazard index in step S103 may specifically include: S1034. Extract the component values ​​of each dimension of the target word frequency vector in the fault map in the multidimensional feature coordinate system.

[0079] The component value refers to the projection length of the target word frequency vector on each coordinate axis of the multidimensional feature coordinate system, and the magnitude of the value indicates the degree of impact of the fault on a specific vehicle subsystem.

[0080] In the specific implementation process, the fault map set is traversed. Each vector in For each vector, parse it along each dimension defined in Table 5 ( Numerical components on ) For example, for the target word frequency vector Extract its in Component values ​​in dimension ,exist Component values ​​in dimension .

[0081] S1035. Accumulate and calculate the product of the component value of each dimension and the corresponding preset risk coefficient to obtain the fault risk value corresponding to each target word frequency vector.

[0082] The preset risk coefficient refers to a weighting factor set according to the impact of different vehicle subsystem failures on driving safety and maintenance costs. The failure risk value is a single quantitative indicator combining the intensity of failure characteristics and risk weights, directly reflecting the threat level of a specific failure to the overall vehicle health. The preset risk coefficients are shown in Table 6 below: Table 6: Preset Risk Coefficient Comparison Table

[0083] As shown in Table 6, the preset risk coefficient It is calculated using the Analytic Hierarchy Process (AHP) combined with historical maintenance big data. In practice, a judgment matrix including various dimensions is first constructed. The value of each matrix element is determined by the ratio of the product of the corresponding historical average maintenance cost and the probability of causing a traffic accident.

[0084] Next, the largest eigenvalue of the judgment matrix and its corresponding eigenvector are calculated and passed through a consistency check. Finally, the eigenvectors are normalized, and the resulting component values ​​are the preset risk coefficients for each dimension. Therefore, dimensions involving core power and safety systems are typically assigned a higher risk coefficient due to their high maintenance costs and significant safety impact, while auxiliary systems have a relatively lower coefficient.

[0085] In the specific implementation process, first refer to Table 6 to obtain the risk coefficients for each dimension. Next, for each target word frequency vector... , its dimensional component values With the corresponding coefficient Multiply and sum to obtain the fault risk value corresponding to the vector. .

[0086] S1036. The health hazard index is obtained by summing up all fault risk values.

[0087] The Health Hazard Index (HHI) is a comprehensive quantitative indicator that represents the overall sub-health condition of a vehicle. A higher value indicates higher potential repair costs and greater safety hazards. In the specific implementation process, the fault risk value of all independent fault codes calculated in step S1035 is used. The results are accumulated to obtain the final health risk index. .

[0088] This embodiment constructs a three-dimensional fault map by accurately calculating the inverse document frequency, which reflects the scarcity and severity of faults. It achieves in-depth deconstruction and weighted aggregation of fault features, and generates a health hazard index that scientifically quantifies the overall sub-health status of the vehicle.

[0089] S104. Homomorphically encrypt the health hazard index using the Pedersen commitment to obtain the encrypted commitment value, and logically verify the health hazard index using zero-knowledge scope proof and polynomial verification to obtain logical proof information.

[0090] Optionally, step S104, which uses the Pedersen commitment to homomorphically encrypt the health hazard index to obtain an encrypted commitment value, and then uses zero-knowledge scope proof and polynomial verification to logically verify the health hazard index to obtain logical proof information, may specifically include: Figure 3 A flowchart illustrating a method for generating cryptographic commitment values ​​and logical proof information according to an embodiment of this application is shown. Figure 3 As shown, the method includes: S1041. The encrypted commitment value is obtained by performing a point addition operation on the result of the scalar multiplication of the preset first elliptic curve base point and the health hazard index and the result of the scalar multiplication of the preset second elliptic curve base point and the preset random blinding factor.

[0091] Pedersen commitment is a cryptographic primitive based on the discrete logarithm problem. It allows the sender to convert a secret value, such as a health risk index, into a highly binding yet perfectly hidden commitment value. The first and second elliptic curve base points are two linearly independent generators defined on the same secure elliptic curve group, such as secp256k1 or BN128, and they are common parameters.

[0092] The randomization factor is a large integer generated by a true random number generator. It is used to obfuscate the secret value and ensure that even if two different vehicles have the same vulnerability index, their generated cryptographic commitment values ​​will be completely different. The preset elliptic curve parameters and randomization factors are shown in Table 7 below: Table 7: Comparison Table of Elliptic Curve Parameters and Random Blinding Factor

[0093] As shown in Table 7, the base point and It is pre-selected and publicly disclosed, while the random blinding factor... These are private parameters that are dynamically generated each time a commitment is generated.

[0094] In the specific implementation process, the calculated health risk index is first obtained from step S103. Next, a random blinding factor that meets the safety requirements is generated. Then, using elliptic curve scalar multiplication, calculate respectively... With base point product ,as well as With base point product Finally, the two results are added together using elliptic curve point addition to obtain the encrypted commitment value. .

[0095] S1042. Construct an interval constraint polynomial that satisfies the health hazard index being within a preset legal value range, and use a random blinding factor to perform verifiable calculations on the interval constraint polynomial to generate interval proof data.

[0096] Interval-constrained polynomials are the core construction of zero-knowledge range proofs, aiming to transform numerical... In the interval This proposition is transformed into a polynomial identity problem. The interval proof data is a set of compressed elliptic curve points and scalar values, used to prove the commitment value to the verifier. The secret hidden behind The interval constraint is indeed satisfied without disclosure. .

[0097] In the specific implementation process, in order to prove the health risk index It is a non-negative number and does not overflow. First of all Decomposed into binary bit vectors Next, construct an interval-constrained polynomial of the following form:

[0098] in, and Based on binary bit vector and random blinding factor Constructed linear polynomial vectors, This represents the inner product operation. The constant term of the polynomial. With secret value There exists a specific algebraic relationship. Then, the blinding factor is used. The polynomial coefficients are committed, a series of intermediate challenge values ​​are generated, and finally compressed interval proof data is output. .

[0099] S1043. Construct a verification polynomial with the health risk index as a specific order coefficient, and use a preset public reference string to perform bilinear pairing calculation on the verification polynomial to generate polynomial proof data.

[0100] Verification polynomials are algebraic structures used to prove that a health hazard index satisfies specific business logic, such as hazard index < threshold. Common Reference Strings (CRS) are trusted setting parameters for zero-knowledge proofs such as Groth16 or Plonk. Bilinear pairing is a special type of mapping operation. ,have It has properties and is often used to verify the correctness of polynomial commitments.

[0101] In the specific implementation process, it is assumed that it is necessary to prove that the Health Risk Index (HHI) is less than a preset threshold. This is equivalent to proving the existence of a non-negative integer. , making First, the addition constraint logic is transformed into an arithmetic circuit consisting of addition and multiplication gates. Then, the arithmetic circuit is transformed into a first-order constraint R1CS that satisfies... In matrix-vector form, where The solution vector includes the secret input and intermediate variables.

[0102] Then, by selecting the corresponding root set on the finite field, the vectors in R1CS are mapped to polynomial form using Lagrange interpolation, thereby constructing the verification polynomial corresponding to the quadratic arithmetic program QAP:

[0103] in, They are respectively by and The left and right input and output polynomials generated by weighting equal variables. It is the objective polynomial that is zero on the root set. Next, using a pre-defined common reference string... For polynomials Perform evaluation and bilinear pairing calculations to generate polynomial proof data. .

[0104] Specifically, the prover calculates The verifier checks the paired verification equation. The logic is verified by whether it is true or not. For example, if... If the verification passes, it proves that... This fact, however, did not reveal the specific value of 35.

[0105] S1044. By using data splicing, the interval proof data and the polynomial proof data are concatenated, recombined, and encapsulated to obtain logical proof information.

[0106] The logical proof information is a complete data body that packages the generated interval proof and logical verification proof. It is a self-contained, independently verifiable binary object.

[0107] In the specific implementation process, the interval proof data generated in step S1042 is first... The polynomial proof data generated in step S1043 Binary serialization is performed. Next, metadata such as version number, proof algorithm identifier, and common input digest are added. Finally, all data segments are concatenated according to a predetermined format to generate the final logical proof information. .For example, It could be a 1KB hexadecimal string that will be broadcast as part of the transaction to the blockchain network for nodes to verify in a consensus manner.

[0108] This embodiment successfully breaks down the conflict between data privacy and business compliance verification, providing a credible proof for used car transactions that both protects car owner privacy and has mathematical certainty, significantly enhancing the security and market credibility of the stored evidence data.

[0109] S105. The logical proof information, encrypted commitment value and vehicle identification code are encapsulated into an on-chain transaction package and broadcast to the blockchain. After the logical proof information is validated by the blockchain's node consensus protocol, the evidence record including the verification result, timestamp and transaction hash value is cascaded and locked with the preceding block in the blockchain to obtain the information evidence record.

[0110] An on-chain transaction package refers to a data structure constructed according to blockchain network protocol standards such as the Ethereum ERC standard or chaincode call format. It encapsulates the vehicle's identity and all core privacy credentials that need to be stored, and serves as the carrier for initiating on-chain state changes. A node consensus protocol refers to the algorithmic rules followed by distributed nodes in the blockchain network, such as miners or validators, to achieve data consistency. These rules include PoW (Proof of Work), PoS (Proof of Stake), or PBFT (Byzantine Fault Tolerance), ensuring the legitimacy of on-chain data and its consistency across the entire network.

[0111] A preceding block refers to the confirmed block preceding the current block to be written in the blockchain's chain structure. This ensures the temporal linking and tamper-proofing of data by referencing its hash value. Information storage records refer to data entries that are ultimately fixed in the blockchain's distributed ledger, including verification conclusions and time anchors, and possess legally binding traceability.

[0112] In the specific implementation process, the vehicle identification code is first obtained from step S101. For example, with a 17-bit VIN code, the encrypted commitment value is obtained from step S104. and logical proof information Specifically, to protect the anonymity of vehicle owners and prevent illegal tracking of specific vehicles via blockchain, this method performs a salted hash operation on the 17-digit VIN code to generate a unique anonymous vehicle identification code. .

[0113] Next, these three pieces of data are assembled into a digitally signed transaction. ,in It is the private key of the vehicle owner or authorized device. The transaction is broadcast to the P2P network.

[0114] Then, the validator nodes in the blockchain network receive the transaction. Then, during the pre-consensus phase, its built-in smart contract verification engine is invoked to execute the verification function. Through analysis Check its mathematical validity. If the verification passes, the node generates a verification-passed identifier. Finally, the packaged node will include , , and the timestamp of the current block generation time and transaction hash The data structure is written into the new block.

[0115] This node uses a hash algorithm to calculate the digital fingerprint of the stored evidence record. Extract the tail hash value of the preceding block. By and Perform concatenation and one-way hash operations to generate the hash value of the current new block. This completes the chain locking to generate a permanent information storage record.

[0116] This embodiment utilizes the consensus mechanism of blockchain to achieve decentralized verification and network-wide synchronization of vehicle condition data, constructing a tamper-proof data chain anchored by timestamps. This ensures the legal validity and non-repudiation of used car condition records, resolving the trust crisis caused by the susceptibility of traditional centralized evidence storage to tampering.

[0117] Optionally, in step S105, after the logical proof information is validated through the blockchain's node consensus protocol, the process of concatenating and locking the evidence record, including the verification result, timestamp, and transaction hash value, with the preceding block in the blockchain to obtain the information evidence record can specifically include: S1051. When the logical proof information passes verification, a verification pass identifier is generated as the verification result. The verification result, the current timestamp, and the transaction hash value corresponding to the on-chain transaction package are serialized and concatenated to generate a proof record.

[0118] The verification pass indicator refers to the information used to clearly indicate the vehicle's logical proof information. A status code that has been verified as valid by blockchain network nodes is typically a binary Boolean value or a specific success code. A timestamp is a precise time stamp generated by blockchain miners or validators when writing data to a new block, synchronized with the network clock. Serialization concatenation refers to the process of converting different types of data fields into a continuous stream of bytes according to strict protocol formats such as ASN.1 or RLP encoding.

[0119] In the specific implementation process, blockchain nodes receive transactions. Then, execute the verification function. If the verification result is true, a verification pass flag is generated. First, obtain the timestamp of the current block's generation time. Next, the unique transaction hash value generated in the network for the on-chain transaction package is extracted. like Finally, using the RLP encoding algorithm, the... , and Concatenate them sequentially to generate a binary format evidence record. .

[0120] S1052. Calculate the digital fingerprint of the evidence record using a hash algorithm, extract the chain tail hash value of the preceding block in the blockchain, and obtain the block header data by concatenating the chain tail hash value with the digital fingerprint.

[0121] Digital fingerprints of evidence records refer to the digital fingerprints of evidence records. The fixed-length digest value generated after a one-way hash operation is the unique identifier of the record. The tail hash value of the preceding block refers to the hash value of the latest confirmed block in the current blockchain network, serving as the anchor connecting new and old blocks. The block header data is a data structure that includes the hash of the preceding block, the current data fingerprint, and other metadata such as the Merkle root and difficulty value; it is the core carrier of the blockchain's chain structure.

[0122] In the specific implementation process, the SHA-256 algorithm is first used to calculate the evidence storage record generated in step S1051. Digital fingerprint Next, query the blockchain ledger to obtain the latest block on the chain, i.e., the block with height [height missing]. The hash value of the block is denoted as the tail hash value. Finally, and Other necessary block header fields such as version number Random numbers The data is concatenated and combined to generate the block header data of the new block to be added to the blockchain. .

[0123] S1053. By performing a one-way hash operation on the block header data, a block hash value is generated, and the block hash value is associated with the evidence storage record and written into the distributed ledger of the blockchain to obtain the information evidence storage record.

[0124] A block hash value is the result of hashing the entire block header data. It is the unique identifier of a new block and will also become the preceding hash of subsequent blocks. A distributed ledger refers to a fully synchronized copy of blockchain data stored on all blockchain network nodes. Information storage records refer to vehicle evidence entries that are ultimately written into the ledger and confirmed by network consensus, including complete blockchain context information.

[0125] In the specific implementation process, the block header data generated in step S1052 is first processed. Perform a one-way hash operation to calculate the hash value of the current new block. If the network uses the PoW consensus mechanism, this step also involves finding a target that satisfies a specific difficulty objective. Value. Next, will The evidence record will be stored as the ID of this block. As part of the block body, a complete block structure is constructed. Finally, the new block is broadcast to the entire network, and each node, after verifying its accuracy, appends it to the end of its local distributed ledger, thus making the vehicle's certificate information officially effective.

[0126] This embodiment constructs a data chain for evidence storage with irreversible time characteristics, ensuring the permanent traceability and tamper-proof nature of vehicle compliance verification results. It solves the trust problem of centralized evidence storage being easily modified, and provides legally valid electronic evidence for used car transactions.

[0127] Figure 4 This is a schematic diagram illustrating a specific implementation of a blockchain-based used car condition information storage system provided in this application. (Refer to...) Figure 4 The system may include: The acquisition module 410 is used to acquire the fault code log sequence of the target vehicle, the cumulative driving time after the fault codes are cleared, and the prior probability distribution data of fault codes of the same model throughout its entire life cycle. The generation module 420 is used to obtain the word frequency value of each fault code based on the number of times different fault codes appear in the fault code log sequence, and to correct the word frequency value based on the gain coefficient determined according to the cumulative driving time, so as to obtain the word frequency vector of each fault code. The generation module 420 is also used to determine the inverse document frequency of each fault code in the entire set of the same model based on the prior probability distribution data, project and map the word frequency vector and the corresponding inverse document frequency of each fault code to obtain the fault map, and use linear weighting to perform weighted aggregation of multi-dimensional feature components of the fault map to obtain the health hazard index. The verification module 430 is used to homomorphically encrypt the health hazard index using the Pedersen commitment to obtain the encrypted commitment value, and to logically verify the health hazard index using zero-knowledge scope proof and polynomial verification to obtain logical proof information. The locking module 440 is used to encapsulate the logical proof information, the encrypted commitment value and the vehicle identification code into an on-chain transaction package and broadcast it to the blockchain. After the logical proof information is verified for validity by the blockchain's node consensus protocol, the evidence record including the verification result, timestamp and transaction hash value is cascaded and locked with the preceding block in the blockchain to obtain the information evidence record.

[0128] The blockchain-based used car condition information storage system of this application embodiment is used to implement the aforementioned blockchain-based used car condition information storage method. Therefore, the specific implementation of the blockchain-based used car condition information storage system can be found in the embodiment section of the blockchain-based used car condition information storage method above. The specific implementation can be referred to the description of the corresponding embodiments, which will not be repeated here.

[0129] Figure 5 A schematic diagram of the hardware structure of an electronic device provided in one embodiment of this application is shown.

[0130] The electronic device may include a processor 510 and a memory 520 storing computer program instructions.

[0131] Specifically, the processor 510 may include a central processing unit (CPU), an application-specific integrated circuit (ASIC), or one or more integrated circuits that can be configured to implement the embodiments of this application.

[0132] Memory 520 may include mass storage for data or instructions. For example, and not limitingly, memory 520 may include a hard disk drive (HDD), floppy disk drive, flash memory, optical disk, magneto-optical disk, magnetic tape, or Universal Serial Bus (USB) drive, or a combination of two or more of these. Where appropriate, memory 520 may include removable or non-removable (or fixed) media. Where appropriate, memory 520 may be internal or external to the integrated gateway disaster recovery device. In a particular embodiment, memory 520 is non-volatile solid-state memory.

[0133] Memory may include read-only memory (ROM), random access memory (RAM), disk storage media devices, optical storage media devices, flash memory devices, and electrical, optical, or other physical / tangible memory storage devices. Therefore, typically, memory includes one or more tangible (non-transitory) computer-readable storage media (e.g., memory devices) encoded with software including computer-executable instructions, and when the software is executed (e.g., by one or more processors), it is operable to perform the operations described with reference to the method according to the first aspect of this disclosure.

[0134] The processor 510 reads and executes computer program instructions stored in the memory 520 to implement any of the blockchain-based methods for storing evidence of used car condition information in the above embodiments.

[0135] In one example, the electronic device may also include a communication interface 530 and a bus 540. Wherein, such as Figure 5 As shown, the processor 510, memory 520, and communication interface 530 are connected through bus 540 and complete communication with each other.

[0136] The communication interface 530 is mainly used to realize communication between various modules, devices, units and / or equipment in the embodiments of this application.

[0137] Bus 540 includes hardware, software, or both, that couples components of an online data traffic metering device together. For example, and not limitingly, the bus may include an Accelerated Graphics Port (AGP) or other graphics bus, an Enhanced Industry Standard Architecture (EISA) bus, a Front Side Bus (FSB), HyperTransport (HT) interconnect, an Industry Standard Architecture (ISA) bus, an Infinite Bandwidth Interconnect, a Low Pin Count (LPC) bus, a memory bus, a Microchannel Architecture (MCA) bus, a Peripheral Component Interconnect (PCI) bus, a PCI-Express (PCI-X) bus, a Serial Advanced Technology Attachment (SATA) bus, a Video Electronics Standards Association Local (VLB) bus, or other suitable buses, or combinations of two or more of these. Where appropriate, bus 540 may include one or more buses. Although specific buses are described and illustrated in embodiments of this application, any suitable bus or interconnect is contemplated herein.

[0138] The electronic device can execute the blockchain-based used car condition information storage method in the embodiments of this application, thereby realizing the blockchain-based used car condition information storage method described in conjunction with the accompanying drawings.

[0139] Furthermore, in conjunction with the blockchain-based used car condition information storage method in the above embodiments, this application embodiment can provide a computer-readable storage medium for implementation. This computer-readable storage medium stores computer program instructions; when these computer program instructions are executed by a processor, they implement any of the blockchain-based used car condition information storage methods in the above embodiments.

[0140] It should be clarified that this application is not limited to the specific configurations and processes described above and shown in the figures. For the sake of brevity, detailed descriptions of known methods are omitted here. In the above embodiments, several specific steps are described and shown as examples. However, the method process of this application is not limited to the specific steps described and shown. Those skilled in the art can make various changes, modifications, and additions, or change the order of steps, after understanding the spirit of this application.

[0141] The functional blocks shown in the above-described structural diagram can be implemented as hardware, software, firmware, or a combination thereof. When implemented in hardware, they can be, for example, electronic circuits, application-specific integrated circuits (ASICs), appropriate firmware, plug-ins, function cards, etc. When implemented in software, the elements of this application are programs or code segments used to perform the required tasks. Programs or code segments can be stored on a machine-readable medium or transmitted over a transmission medium or communication link via data signals carried on a carrier wave. "Machine-readable medium" can include any medium capable of storing or transmitting information. Examples of machine-readable media include electronic circuits, semiconductor memory devices, ROM, flash memory, erasable ROM (EROM), floppy disks, CD-ROMs, optical disks, hard disks, fiber optic media, radio frequency (RF) links, etc. Code segments can be downloaded via computer networks such as the Internet, intranets, etc.

[0142] It should also be noted that the exemplary embodiments mentioned in this application describe methods or systems based on a series of steps or apparatus. However, this application is not limited to the order of the above steps; that is, the steps can be performed in the order mentioned in the embodiments, or in a different order, or several steps can be performed simultaneously.

[0143] The aspects of this application have been described above with reference to flowchart illustrations and / or block diagrams of methods, apparatus (systems), and computer program products according to embodiments of this application. It should be understood that each block in 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, a special-purpose computer, or other programmable data processing apparatus to produce a machine such that these instructions, executable via the processor of the computer or other programmable data processing apparatus, enable the implementation of the functions / actions specified in one or more blocks of the flowchart illustrations and / or block diagrams. Such a processor can be, but is not limited to, a general-purpose processor, a special-purpose processor, a special application processor, or a field-programmable logic circuit. It is also understood that each block in the block diagrams and / or flowcharts, and combinations of blocks in the block diagrams and / or flowcharts, can also be implemented by dedicated hardware performing the specified functions or actions, or can be implemented by a combination of dedicated hardware and computer instructions.

[0144] The foregoing has provided a detailed description of a blockchain-based method and system for storing vehicle condition information of used cars. Specific examples have been used to illustrate the principles and implementation methods of this application. The descriptions of the embodiments above are merely for the purpose of helping to understand the method and its core ideas. It should be noted that those skilled in the art can make various improvements and modifications to this application without departing from its principles, and these improvements and modifications also fall within the protection scope of this application.

Claims

1. A method for storing evidence of the condition of used cars based on blockchain, characterized in that, include: Obtain the fault code log sequence of the target vehicle, the cumulative driving time after the fault codes are cleared, and the prior probability distribution data of fault codes of the same model throughout its entire life cycle; Based on the frequency of occurrence of different fault codes in the fault code log sequence, the word frequency value of each fault code is obtained, and the gain coefficient is determined based on the cumulative driving time to correct the word frequency value, thereby obtaining the word frequency vector of each fault code. Based on the prior probability distribution data, the inverse document frequency of each fault code in the entire set of the same model is determined. The term frequency vector and the corresponding inverse document frequency of each fault code are projected and mapped to obtain a fault map. The fault map is then weighted and aggregated with multidimensional feature components using linear weighting to obtain a health hazard index. The health risk index is homomorphically encrypted using Pedersen commitments to obtain an encrypted commitment value, and the health risk index is logically verified using zero-knowledge scope proofs and polynomial verifications to obtain logical proof information. The logical proof information, the encrypted commitment value, and the vehicle identification code are encapsulated into an on-chain transaction package and broadcast to the blockchain. After the logical proof information is validated by the blockchain's node consensus protocol, the evidence record, including the verification result, timestamp, and transaction hash value, is cascaded and locked with the preceding block in the blockchain to obtain the information evidence record.

2. The method according to claim 1, characterized in that, Before determining the inverse document frequency of each fault code in the entire set of the same vehicle model based on the prior probability distribution data, and projecting the term frequency vector and the corresponding inverse document frequency of each fault code to obtain the fault map, the method further includes: Obtain the cumulative number of power-on cycles of the control unit of the target vehicle within the cumulative driving time; The power-on frequency of the target vehicle within a unit time period is determined based on the ratio of the cumulative number of power-on cycles to the cumulative driving time. The masking risk coefficient is calculated based on the ratio between the power-on frequency and the preset power-on frequency reference. The word frequency vector is weighted and corrected using the masking risk coefficient to obtain the updated word frequency vector.

3. The method according to claim 1, characterized in that, The process involves obtaining the term frequency value of each fault code based on the frequency of occurrence of different fault codes in the fault code log sequence, and then correcting the term frequency value using a gain coefficient determined based on the cumulative driving time to obtain the term frequency vector for each fault code, including: Calculate the number of times different fault codes appear repeatedly in the fault code log sequence to obtain the word frequency value of each fault code; The ratio of the accumulated driving time to the preset reference cycle time is calculated to obtain the cycle completion rate. Based on the cycle completion rate, the gain coefficient is obtained according to the preset mapping relationship between the cycle completion rate and the gain coefficient. The product of the word frequency value and the gain coefficient is calculated to obtain the weighted word frequency value of each fault code, and the word frequency vector of each fault code is obtained by multiplying the weighted word frequency value with the corresponding preset reference vector.

4. The method according to claim 1, characterized in that, The step of determining the inverse document frequency of each fault code in the entire set of the same vehicle model based on the prior probability distribution data, and projecting the term frequency vector and the corresponding inverse document frequency of each fault code onto the fault map to obtain the fault map includes: Extract the probability value of each fault code in the entire set of the same model from the prior probability distribution data, and perform a logarithmic operation on the reciprocal of the probability value to obtain the corresponding inverse document frequency; Calculate the numerical product of the inverse document frequency and the corresponding term frequency vector to obtain the target term frequency vector for each fault code; All target word frequency vectors are mapped to a preset multi-dimensional feature coordinate system to obtain a spatial distribution set consisting of multiple discrete vector points, and the spatial distribution set is determined as the fault map.

5. The method according to claim 4, characterized in that, The health hazard index is obtained by weighting and aggregating the multidimensional feature components of the fault map using linear weighting, including: Extract the component values ​​of each target word frequency vector in the fault map in each dimension of the multidimensional feature coordinate system; The product of the component values ​​of each dimension and the corresponding preset risk coefficient is accumulated to obtain the fault risk value corresponding to each target word frequency vector; The health hazard index is obtained by summing all the aforementioned fault risk values.

6. The method according to claim 1, characterized in that, The health hazard index is homomorphically encrypted using a Pedersen commitment to obtain an encrypted commitment value, and then logically verified using zero-knowledge range proofs and polynomial verifications to obtain logical proof information, including: The encrypted commitment value is obtained by performing a point addition operation on the result of the scalar multiplication of the preset first elliptic curve base point and the health risk index and the result of the scalar multiplication of the preset second elliptic curve base point and the preset random blinding factor. Construct an interval constraint polynomial that satisfies the health risk index being within a preset legal value range, and use the random blinding factor to perform verifiable calculations on the interval constraint polynomial to generate interval proof data; Construct a verification polynomial with the health risk index as a specific order coefficient, and use a preset public reference string to perform bilinear pairing calculation on the verification polynomial to generate polynomial proof data. The logical proof information is obtained by concatenating and recombining the interval proof data and the polynomial proof data and encapsulating the data using data splicing.

7. The method according to claim 1, characterized in that, After the logical proof information is validated through the blockchain's node consensus protocol, the evidence record, including the verification result, timestamp, and transaction hash value, is concatenated and locked with the preceding block in the blockchain to obtain an information evidence record, including: When the logical proof information passes verification, a verification pass identifier is generated as the verification result, and the verification result, the current timestamp, and the transaction hash value corresponding to the on-chain transaction package are serialized and concatenated to generate the evidence storage record; The digital fingerprint of the evidence record is calculated using a hash algorithm, the chain tail hash value of the preceding block in the blockchain is extracted, and the block header data is obtained by concatenating the chain tail hash value with the digital fingerprint. By performing a one-way hash operation on the block header data, a block hash value is generated, and the block hash value is associated with the evidence storage record and written into the distributed ledger of the blockchain to obtain the information evidence storage record.

8. A blockchain-based used car condition information storage system, characterized in that, include: The acquisition module is used to acquire the fault code log sequence of the target vehicle, the cumulative driving time after the fault codes are cleared, and the prior probability distribution data of fault codes of the same model throughout its entire life cycle. The generation module is used to obtain the word frequency value of each fault code based on the number of times different fault codes appear in the fault code log sequence, and to correct the word frequency value by determining a gain coefficient based on the cumulative driving time, so as to obtain the word frequency vector of each fault code. The generation module is also used to determine the inverse document frequency of each fault code in the entire set of the same model based on the prior probability distribution data, project and map the word frequency vector and the corresponding inverse document frequency of each fault code to obtain a fault map, and use linear weighting to perform weighted aggregation of multi-dimensional feature components of the fault map to obtain a health hazard index. The verification module is used to homomorphically encrypt the health hazard index using Pedersen commitment to obtain an encrypted commitment value, and to logically verify the health hazard index using zero-knowledge scope proof and polynomial verification to obtain logical proof information. The locking module is used to encapsulate the logical proof information, the encrypted commitment value, and the vehicle identification code into an on-chain transaction package and broadcast it to the blockchain. After the logical proof information is validated by the blockchain's node consensus protocol, the stored record, including the verification result, timestamp, and transaction hash value, is cascaded and locked with the preceding block in the blockchain to obtain the information storage record.

9. An electronic device, characterized in that, include: Memory, used to store computer programs; A processor, configured to execute the computer program to implement the steps of the blockchain-based used car condition information storage method as described in any one of claims 1 to 7.

10. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores a computer program that, when executed by a processor, enables the implementation of the blockchain-based method for storing evidence of used car condition information as described in any one of claims 1 to 7.

Images