A blockchain-based charger supply chain data traceability management method

Abstract

The application discloses a kind of charger supply chain data traceability management methods based on blockchain, it is related to supply chain data management technical field, the method is built on the hybrid architecture of on-chain anchoring and off-chain execution, according to supplier trust score and data importance level Generation encrypted trust anchor point;Subsequently, combined with the dynamic evolution of supplier trust score and blockchain network load factor, the real-time decision verification depth and anchoring frequency are triggered by elastic verification trigger function;Further, periodically solve system total utility function to obtain optimal parameter combination, and use it to calibrate decision function, realize the combination of strategic optimization and tactical response;Finally, through oracle, the trust anchor point is chained and stored, and off-chain asynchronous verification is triggered, the application significantly reduces the storage and consensus overhead of blockchain, improves the scalability of the system, and can adaptively balance safety, efficiency and cost, realizes low-cost, high-efficiency and safe and reliable supply chain data traceability management.

Description

Technical Field

[0001] This invention relates to the field of supply chain data management, specifically a blockchain-based method for traceability management of charger supply chain data. Background Technology

[0002] In the data traceability management of the charger supply chain, traditional blockchain technology applications mainly rely on storing and reaching consensus on massive amounts of raw traceability data directly on the chain. Although this method utilizes the immutability of blockchain, its inherent architectural defects lead to inefficient and costly data processing, failing to effectively meet the dynamic management needs of complex supply chain scenarios. This situation forces enterprises to bear high operating costs and limited system scalability while seeking high security, hindering the large-scale application of the technology.

[0003] The aforementioned situation and shortcomings are mainly due to the limitations of the data upload method and verification mechanism. Uploading all raw data to the blockchain greatly increases the storage and consensus overhead of the blockchain, resulting in poor system scalability. Furthermore, traditional methods lack a flexible and adaptive management mechanism, making it impossible to dynamically adjust the verification intensity based on changes in supplier trust levels or the criticality level of the data, or to adjust the frequency of data upload based on real-time fluctuations in the blockchain network load. Ultimately, when trust risks change within the supply chain or when the external network environment becomes congested, the system cannot respond intelligently, resulting in a waste of blockchain resources or serious delays in transaction processing, making it difficult to achieve a balance between security, efficiency, and cost.

[0004] The information disclosed in the background section above is only intended to enhance the understanding of the background of this disclosure, and therefore may include information that does not constitute prior art known to those skilled in the art. Summary of the Invention

[0005] The purpose of this invention is to provide a blockchain-based method for data traceability management in the charger supply chain, in order to solve the problems mentioned in the background art.

[0006] The technical solution of the present invention includes the following specific steps:

[0007] S1. Trust Anchor Generation: Collect supply chain data and map the data to data importance levels. Based on the supplier's current trust score With data importance level The data is encrypted and digested to generate trust anchors;

[0008] S2, Flexible Verification Decision: Calculating Dynamic Trust Scores for Suppliers and blockchain network system load factor ;Will With Input to the elastic verification trigger function T to make real-time decisions on the verification depth With anchor frequency ;

[0009] S3, Parameter optimization and calibration: periodically solve the maximum value of the system total utility function to obtain the optimal solution ; Use the optimal solution to calibrate the benchmark parameters of the elastic verification trigger function T;

[0010] S4, On-chain anchoring and off-chain execution: according to With , the trust anchor is submitted to the smart contract on the blockchain for notarization; the smart contract triggers asynchronous verification of the original data stored off-chain;

[0011] S5, Closed-loop traceability verification: when receiving a traceability query, obtain the on-chain trust anchor and off-chain original data; according to the original data, recalculate the trust anchor for verification locally, and compare it with the on-chain trust anchor, and output the verification conclusion or trigger the risk alarm according to the comparison result.

[0012] Preferably, the encryption summary process in S1 includes:

[0013] If the current trust score of the supplier is high or the data importance level is low, a single hash algorithm is used to generate the trust anchor;

[0014] If the current trust score of the supplier is low or the data importance level is high, a hierarchical Merkle tree is constructed to generate a unique Merkle root as the trust anchor.

[0015] Preferably, S1 is followed by and S4 is preceded by:

[0016] A dynamic knowledge graph of the supply chain is constructed off-chain; the knowledge graph is used to associate original data, trust anchors, and supply chain business entities;

[0017] A material batch life cycle finite state machine is defined; the state transition of the state machine is driven by an off-chain business rule engine, and an event summary containing the trust anchor is used as a state transition credential.

[0018] Preferably, the calculation of the supplier dynamic trust score in S2 is based on the following formula:

[0019] ;

[0020] Wherein, ​the current trust score, the last period trust score, the learning rate, the validation result of the current period, the time interval, the trust decay time constant.

[0021] The calculation of the blockchain network system load factor in S2 is based on the following formula:

[0022] ;

[0023] wherein, is the system load factor, is the number of transactions to be processed, is the theoretical maximum TPS of the blockchain, is the statistical time window.

[0024] The decision mechanism of the flexible verification trigger function T in S2 is set as:

[0025] When decreases, the value of is mapped to a higher integer;

[0026] When increases, the value of is mapped to a lower value.

[0027] The parameter optimization in S3 is achieved through the iterative search of the light-emitting swarm optimization algorithm to find the optimal solution that maximizes the system total utility function . .

[0028] The calculation of the system total utility function is based on the following formula:

[0029] ;

[0030] wherein, is the preset dimensionless weight coefficient, is the verification completeness function, is the consensus delay function, is the normalized transaction cost function.

[0031] The sub-functions in the system total utility function are defined as follows:

[0032] The verification completeness function is , wherein is the completeness growth coefficient; ​

[0033] The consensus time delay function is characterized as ;

[0034] The normalized transaction cost function is , wherein is the average cost of a single transaction, is the budget benchmark cost rate.

[0035] Preferably, the submission of the trust anchor point in S4 is completed through an oracle; the asynchronous verification triggered by the smart contract is instructed to be executed through the oracle callback chain data verification service.

[0036] The application provides a charger supply chain data traceability management method based on a blockchain by improvement, compared with the prior art, has the following improvements and advantages:

[0037] 1. An elastic verification decision mechanism is established; the mechanism dynamically decides the verification depth and anchoring frequency by real-time calculation of the dynamic trust score of the supplier and the load factor of the blockchain network system; this design enables the strength of data verification to be accurately matched with the trust risk level of the supply chain, and the rhythm of on-chain interaction to actively avoid congestion periods of external network environment; compared with the traditional fixed strategy traceability system, the application realizes intelligent trade-off between ensuring data security and responding to network fluctuations, has high adaptability and running economy;

[0038] 2. The risk self-adaptation of the encryption summary processing is realized; according to the difference of the supplier trust score or the data importance level, the system can automatically select to use single hash algorithm or construct hierarchical Merkle tree; this strategy of dynamically adjusting the cryptography tool according to the risk level is a fine management of computing resources and on-chain resources; it guarantees the highest processing efficiency for low-risk scenarios, and greatly reduces the on-chain cost for high-risk or massive data scenarios through the Merkle root, realizes the optimal allocation of system resources under the premise of ensuring security;

[0039] 3. The global parameter optimization and calibration link is introduced; by periodically solving a system total utility function which integrates verification completeness, consensus time delay and transaction cost, the optimal parameter solution of the system overall performance can be obtained; the optimal solution is used to calibrate the benchmark parameters of the elastic verification decision mechanism, realizing the continuous guidance of the global optimization at the strategic level to the real-time decision at the tactical level; this design ensures that the system can always adaptively adjust around the optimal utility interval in the long-term operation, significantly improving the long-term operation performance of the system;

[0040] 4. The supply chain dynamic knowledge graph and material batch life cycle finite state machine are constructed off-chain. This deepens the association between isolated trust anchors and specific supply chain business entities and processes, and uses event summaries containing trust anchors as state transition credentials to establish a verifiable closed loop between on-chain trust and off-chain business logic evolution. Traceability queries are no longer limited to verifying the integrity of data itself, but can also verify the compliance of business processes, greatly enhancing the business context and logical depth of traceability information;

[0041] 5. The reliable communication between on-chain smart contracts and off-chain execution environments is realized through the oracle. The submission of trust anchors and the triggering of off-chain asynchronous verification are both completed through the trusted interface, solving the inherent problem of blockchain interaction with external systems. It provides key technical support for the mixed architecture of on-chain anchoring and off-chain execution, ensuring the automation, seamless connection and reliable execution of cross-system workflows. BRIEF DESCRIPTION OF DRAWINGS

[0042] The application will be further explained below in conjunction with the accompanying drawings and embodiments:

[0043] Figure 1 is a process block diagram of the system of the application. DETAILED DESCRIPTION

[0044] In order to make the purpose, technical scheme and advantages of the application clearer and more apparent, the application will be further described in detail below in conjunction with specific embodiments.

[0045] Embodiment 1

[0046] Please refer to Figure 1 , the application provides a charger supply chain data traceability management method based on a blockchain, and the specific steps include:

[0047] S1, trust anchor generation: collect supply chain data and map the data to data importance level ; based on the current trust score of the supplier and the data importance level , the data is encrypted and summarized to generate a trust anchor;

[0048] S2, flexible verification decision: calculate the dynamic trust score of the supplier and the load factor of the blockchain network system ; input and to the flexible verification trigger function T to decide the verification depth and the anchoring frequency in real time;

[0049] S3, parameter optimization and calibration: periodically solve the system total utility function The maximum value of the optimal solution is obtained ; the reference parameters of the elastic verification trigger function T are calibrated using the optimal solution; for example, the reference anchor frequency in the internal decision table of function T is updated to the solved optimal frequency , and the optimal verification depth is taken as the core reference value for adjusting the verification depth, so that real-time tactical decisions always revolve around the periodically updated strategic optimal point;

[0050] S4, on-chain anchoring and off-chain execution: according to and , the trust anchor is submitted to the smart contract on the blockchain for notarization; the smart contract triggers asynchronous verification of the original data stored off-chain;

[0051] S5, closed-loop traceability verification: when receiving a traceability query, the on-chain trust anchor and the off-chain original data are obtained; the trust anchor for verification is recalculated according to the original data locally, and is compared with the on-chain trust anchor, and the verification conclusion or risk alarm is output according to the comparison result;

[0052] The application discloses a charger supply chain data traceability management method based on a blockchain, and a technical scheme is constructed on an elastic architecture of on-chain anchoring / off-chain execution. Instead of directly chaining consensus of massive original traceability data, the state verifiability of the data is taken as the core of trust.

[0053] In this embodiment, the steps of the method are described as follows:

[0054] S1, trust anchor generation: this step aims to convert original supply chain data into a lightweight, verifiable cryptographic certificate; to achieve this goal, the system performs supply chain data collection; supply chain data refers to multi-source heterogeneous information from each link of the charger supply chain, and serves as the basis for traceability, and is sourced from supplier qualification documents, production batches and process parameters, Internet of Things sensor data, and multi-level quality inspection reports; the collected data is mapped to data importance levels . , which is a dimensionless integer, and serves to quantify the sensitivity and criticality of the data to the business, and is derived from analyzing the data content according to a preset classification marking rule; the working principle of the preset rule is that the content sensitivity of the data, for example, process parameters related to core intellectual property rights are given a high level and business criticality, for example, the final quality inspection report is given a high level together; at the same time, each supplier is given the current trust score of the supplier . represents a floating-point number in the interval [0, 1], and is used to evaluate the reliability of a supplier. The initial value is preset according to the historical average default rate of the category to which the supplier belongs, and is dynamically updated by the system subsequently;

[0055] Based on the above score and level, the data is encrypted and summarized to generate a trust anchor. The trust anchor refers to the encrypted summary of the original data, and is used to lock the existence, integrity and attribution of the original data at a very low cost. The trust anchor is calculated by a hash algorithm or a Merkle tree algorithm.

[0056] S2, flexible verification decision: this step aims to dynamically adjust the strength and frequency of data verification according to the current state of the system. In the specific implementation, the dynamic trust score of the supplier is calculated and the load factor of the blockchain network system ; represents the trust score of the supplier evolving over time, and is used to reflect the recent behavior of the supplier. The trust score is calculated by a credit evaluation model based on Bayesian inference. represents a dimensionless number in the interval [0, 1], and is used to quantify the congestion level of the blockchain network. The congestion level is calculated according to the resource utilization rate defined in the standard queuing theory.

[0057] and are passed as input parameters to the flexible verification trigger function T to make real-time decisions on the verification depth and the anchoring frequency . The flexible verification trigger function T is a core custom decision model, which is used to convert the internal trust risk and external network environment into specific operation parameters through quantitative mapping. The preset rules are a series of segmented nonlinear mapping rules, which are used to simulate risk avoidance logic. For example, when the trust score is lower than a certain preset threshold, such as 0.5, the verification depth is mapped to a higher integer that needs to build a Merkle tree. When the network load is higher than a certain preset threshold, such as 0.8, the anchoring frequency is reduced accordingly from the baseline value. The verification depth represents a positive integer, and is used to represent the strength of the cryptographic evidence on which the data verification depends. The verification depth is the output of the function T. The anchoring frequency represents the time frequency of submitting the trust anchor to the chain, and is used to control the rate of consumption of blockchain resources. The anchoring frequency is the output of the function T.

[0058] ​S3. Parameter Optimization and Calibration: This step aims to provide a strategic-level global optimal benchmark for the real-time decision-making mechanism of the decision-making layer; in this embodiment, the system periodically solves for the total system utility function. The maximum value; the total utility function of the system. This refers to a mathematical expression that integrates information theory, queuing theory, and economic models. Its function is to comprehensively evaluate the overall benefits and costs of the system under a given verification depth and anchoring frequency. It originates from the core custom model of this invention. The process of solving for the maximum value of this function is designed to obtain the optimal solution. The system uses the optimal solution to calibrate the baseline parameters of the elastic verification trigger function T; this calibration process updates the piecewise mapping threshold and baseline output value within function T. This allows its decision-making behavior to be fine-tuned around the overall optimal point;

[0059] Applying the optimal solution After calibrating the function T, the system will also perform a model robustness verification; this verification is performed by inputting parameter values ​​under a series of boundary conditions, such as... , , , To test the output of the calibrated function T, ensuring that its decision-making behavior is always within the preset safe and economical operating range, and avoiding making decisions that may harm the system in extreme cases;

[0060] S4. On-chain anchoring and off-chain execution: This step aims to solidify trust credentials on the blockchain and trigger verification of massive amounts of raw data; in this embodiment, based on the determined verification depth... With anchoring frequency The trust anchor is submitted to a smart contract on the blockchain for notarization; a smart contract is a piece of autonomous code deployed on the blockchain, which automatically and trustlessly executes predefined rules, and is pre-programmed and deployed; the smart contract triggers asynchronous verification of the raw data stored off-chain; off-chain storage here refers to storing massive amounts of raw data in an off-chain environment such as a high-performance distributed file system;

[0061] S5. Closed-Loop Source Tracing Verification: This step aims to respond to the user's source tracing request and provide a final trusted verification conclusion. When a source tracing query is received, the system first obtains the on-chain trust anchor and the off-chain original data; it then recalculates the verification trust anchor locally based on the obtained original data; it compares the locally recalculated trust anchor with the tamper-proof trust anchor obtained from the on-chain; based on the comparison result, it outputs a verification conclusion or triggers a risk alert; if the two are completely consistent, it outputs the conclusion that the on-chain verification has passed; if they are inconsistent, it immediately triggers a data tampering risk alert and can accurately locate the inconsistent data source.

[0062] The present application constructs a hybrid architecture of on-chain anchoring / off-chain execution by chaining the encrypted digest of data and the trust anchor, and placing massive raw data and its verification logic off-chain; this method not only ensures the final trust root of data traceability by using the tamper-proof nature of the blockchain, but also dynamically balances the security, efficiency and cost of the system through elastic verification decision and periodic parameter optimization; compared with the prior art, the storage and consensus overhead of the blockchain is greatly reduced, the scalability of the system is improved, and the trust changes within the supply chain and the fluctuations of the external network environment can be adaptively responded to, realizing low-cost, high-efficiency and safe and reliable supply chain data traceability management.

[0063] The encrypted digest processing in S1 includes:

[0064] If the current trust score of the supplier is high or the data importance level is low, a single hash algorithm is used to generate the trust anchor;

[0065] If the current trust score of the supplier is low or the data importance level is high, a hierarchical Merkle tree is constructed to generate a unique Merkle root as the trust anchor;

[0066] This embodiment is a specific implementation of the encrypted digest processing method in S1 described above;

[0067] In this embodiment, the specific strategy of the encrypted digest processing in S1 is set to adaptively select the algorithm according to the risk level; the risk level here is determined by the current trust score of the supplier and the data importance level ;

[0068] If the current trust score of the supplier is high or the data importance level is low, this case is determined by the system as a low-risk scenario; at this time, the encrypted digest processing is set to generate the trust anchor using a single hash algorithm; the implementation is to apply a standard cryptographic hash function, such as SHA-256, directly to a single raw data file d to generate its unique hash digest h, i.e.:

[0069]

[0070] wherein, : data digest; : raw data; : hash function;

[0071] If the current trust score of the supplier is low or the data importance level higher, the system determines that it is a high-risk or large data volume scenario; at this time, the encryption summary processing is set to build a hierarchical Merkle tree to generate a unique Merkle root as a trust anchor; the construction process is: a batch of massive data files are respectively subjected to hash operation to obtain a group of leaf node hashes ; by recursively hashing the hash values of adjacent node pairs, that is , indicates a splicing operation, and the aggregation calculation is performed layer by layer upwards until a unique Merkle root is generated ; the Merkle root is used as the total trust anchor of the batch of massive data;

[0072] By introducing this adaptive encryption summary strategy, the application realizes fine management of computing resources and on-chain resources; for low-risk data, single hash with minimum computing cost is adopted to ensure efficiency; for high-risk or massive data, Merkle tree is used to compress the verification summary of n data files into one on-chain transaction, which significantly reduces the on-chain cost and data redundancy while ensuring that the data integrity can be efficiently verified; this way makes the generation process of the trust anchor have risk perception ability, and a better balance between safety and economy is achieved;

[0073] S1 and before S4 also include:

[0074] Building a supply chain dynamic knowledge graph off-chain; the knowledge graph is used to associate raw data, trust anchors and supply chain business entities;

[0075] Defining a material batch life cycle finite state machine; the state transition of the state machine is driven by an off-chain business rule engine, and an event summary containing a trust anchor is used as a state transition voucher;

[0076] This embodiment adds steps of off-chain data processing after S1 and before S4 described above, to enhance the correlation of data and the coherence of business logic;

[0077] In this embodiment, after the trust anchor generated in S1 is completed, the following off-chain processing steps are added before the trust anchor is submitted on-chain in S4:

[0078] A supply chain dynamic knowledge graph is constructed off-chain. The supply chain dynamic knowledge graph refers to a data model organized in a graph data structure, and its role is to establish deep associations between different data. Its source is realized in an off-chain high-performance graph database. In this embodiment, the collected raw data, generated trust anchors and business entities in the supply chain, such as suppliers, material batches, production lines, etc., are taken as nodes, and the business relationships between them are taken as edges, thereby constructing a dynamically evolving knowledge network.

[0079] A material batch life cycle finite state machine is defined. The material batch life cycle finite state machine refers to an abstract model for describing the state transition of a material batch from creation to quality inspection and then to delivery. Its role is to ensure the normativity and traceability of off-chain business processes. The state transition of the state machine is driven by an off-chain business rule engine. The off-chain business rule engine refers to a software component for executing predefined business logic. Each state transition is triggered by a specific business event, and the summary of the event is recorded. The summary contains the trust anchor of the current state data as a valid voucher for state transition.

[0080] By constructing a knowledge graph off-chain, isolated data points and trust anchors are associated with specific business entities and processes, greatly enhancing the contextualization and understandability of traceability information. At the same time, by modeling the business process with a finite state machine and using an event summary containing a trust anchor as a state transition voucher, it is ensured that the evolution process of the off-chain business logic itself is rigorous and traceable. This establishes a verifiable association between on-chain trust anchors and off-chain business logic evolution, so that traceability not only verifies the integrity of the data, but also checks the compliance of the business process.

[0081] Embodiment 2

[0082] S2 supplier dynamic trust score is calculated according to the following formula:

[0083] ;

[0084] wherein, is the score of the last period, is the learning rate, is the verification result of the current period, is the time interval, is the trust decay time constant;

[0085] S2 blockchain network system load factor is calculated according to the following formula:

[0086] ;

[0087] wherein, is the system load factor, is the number of transactions to be processed, is the theoretical maximum TPS of the blockchain, is the statistical time window;

[0088] The decision mechanism of the flexible verification trigger function T in S2 is set as:

[0089] When decreases, the value of is mapped to a higher integer;

[0090] When increases, the value of is mapped to a lower value;

[0091] This embodiment is a specific description of the flexible verification decision core parameters and decision mechanism in S2; the above three technical features are closely related and work together to form the flexible verification decision engine;

[0092] In this embodiment, the formulation process of the flexible verification decision in S2 is further illustrated;

[0093] Supplier dynamic trust score is calculated to establish a trust quantitative index that can reflect the recent performance of the supplier and dynamically evolve over time; the calculation is based on the following formula:

[0094]

[0095] wherein, is the current trust score; is the learning rate, which controls the rate of score update; is the verification result of this period, 1 for success and 0 for failure, which is obtained from the return result of the asynchronous verification in S4; is the statistical time window from the last score; is the trust decay time constant, which controls the rate of influence weight decay of historical scores over time; the parameter and are empirical parameters obtained by regression analysis of historical supplier verification result data sets;

[0096] The regression analysis method is as follows: collect a structured data set containing supplier ID, historical verification time point, and verification result v; consider the trust score update formula as an autoregressive model, and minimize the mean square error between the predicted score and the actual verification result as the target; use optimization algorithms such as grid search or gradient descent to train the model on this data set, and automatically find the optimal and Parameter combination

[0097] Blockchain network system load factor The calculation aims to provide a quantitative index that objectively reflects the network congestion in real time; the calculation is based on the following formula:

[0098]

[0099] Wherein, is the system load factor; is the number of transactions to be processed in the statistical time window, which is obtained by real-time monitoring of the memory pool in the blockchain network; is the theoretical maximum transaction throughput of the blockchain network, which is a known parameter; is the statistical time window; this factor intuitively reflects the utilization rate of network resources within the statistical time;

[0100] The decision mechanism of the flexible verification trigger function T is set to simulate the decision logic of risk management experts to achieve adaptive response to intrinsic trust and external network environment; the core mechanism is set to a series of segmented nonlinear mapping rules, which are represented as:

[0101] When the supplier dynamic trust score drops, indicating that the risk of the supplier is increasing, the system needs stronger cryptographic evidence to ensure data trust; at this time, the mapping rule of function T is triggered, which maps the value of verification depth to a higher integer; for example, from =1 representing single hash, to =5 representing building a multi-layer Merkle tree;

[0102] When the blockchain network system load factor rises, indicating that the network tends to be congested, and continuing to submit transactions at high frequency will lead to skyrocketing transaction fees and confirmation delays; at this time, another set of mapping rules of function T is triggered, which maps the value of anchor frequency to a lower value, i.e. extends the interval time of submitting trust anchor points to actively avoid peak period and relieve network congestion;

[0103] To further illustrate the mapping rule, function T can be implemented as a decision table based on threshold judgment, for example:

[0104] Scenario one: when the supplier dynamic trust score and the blockchain network system load factor , high trust, low load, the system determines the optimal state, and sets the verification depth , single hash, anchor frequency to the base frequency ;

[0105] Scenario two: when the supplier dynamic trust score is low, regardless of network load, to prioritize data security, the system is forced to set the verification depth , build a Merkel tree;

[0106] Scenario three: when the blockchain network system load factor is high, regardless of trust score, to prioritize system economy, the system sets the anchor frequency , that is, the frequency is halved;

[0107] The decision table clearly defines the nonlinear mapping relationship between the input parameters and the output operation parameters , so that the person skilled in the art can implement the function accordingly;

[0108] By precisely defining the calculation method of the supplier dynamic trust score , the trust evaluation model has the characteristics of dynamic learning and time decay, and the evaluation result is closer to reality; by quantitatively defining the system load factor , the system can accurately perceive the network state on the chain; more importantly, by setting and negative correlation and and negative correlation decision mechanism, the present application builds an intelligent decision engine; the engine can automatically balance between strengthening verification to deal with trust risks and reducing frequency to avoid network congestion, so that the entire traceability management system realizes high adaptability, maximizes the operation efficiency and economy on the premise of ensuring safety.

[0109] Embodiment 3

[0110] The parameter optimization in S3 is achieved by iterative search of the light-emitting worm swarm optimization algorithm to find the optimal solution that maximizes the system total utility function ;

[0111] In the specific application of the algorithm:

[0112] Solution encoding: the position vector of each light-emitting worm individual is encoded as , where the verification depth is a discrete integer, and the anchor frequency is a continuous floating-point number, forming a mixed integer optimization problem;

[0113] Fitness function: the fitness function that evaluates the merits of each light-emitting worm individual, or the fluorescence value is directly derived from the system total utility function​ The greater the function value, the better the individual position is determined by the calculation result;

[0114] Parameter setting: the control parameters of the algorithm, such as population size, luciferin update rate, perception radius update rule, etc., can be set according to the standard practice in the field of optimization algorithm, and fine-tuned through preliminary simulation experiment to ensure the convergence speed and optimization accuracy of the algorithm;

[0115] System total utility function The calculation is based on the following formula:

[0116] ;

[0117] Wherein, is a preset dimensionless weight coefficient, is a verification completeness function, is a consensus delay function, is a normalized transaction cost function;

[0118] The sub-functions in the system total utility function are defined as follows:

[0119] The verification completeness function is , wherein is a completeness growth coefficient;

[0120] The consensus delay function is represented as ;

[0121] The normalized transaction cost function is , wherein is the average cost of a single transaction, is the budget benchmark cost rate;

[0122] This embodiment is a specific description of the parameter optimization process in S3 described above; the optimization process is realized by introducing the light-emitting swarm optimization algorithm and constructing a multi-objective system total utility function The above content further limits the utility function and its sub-functions, so they are described here;

[0123] In this embodiment, the parameter optimization and calibration process in S3 is designed as:

[0124] Parameter optimization is performed by iterative search of the light-emitting swarm optimization algorithm; the light-emitting swarm optimization algorithm is a bio-inspired heuristic search algorithm that simulates group intelligent search behavior to find the global optimal solution of complex optimization problems; in this embodiment, each search individual is abstracted as a solution vector The algorithm finds the system total utility function Optimal solution reaching maximum ;

[0125] The system total utility function is calculated to create a unified mathematical model to evaluate the comprehensive performance of the system under different parameters ; the calculation of the function is based on the following formula:

[0126]

[0127] wherein, is a preset dimensionless weight coefficient, which is derived from the system administrator according to the current business strategy, for example, more emphasis on security at the initial stage of product release, then adjust to set, in order to make the weight setting more objective and systematic, the analytic hierarchy process can be introduced; by constructing a judgment matrix, the system administrator and business experts compare the importance of each other when verifying completeness, security, consensus delay, efficiency and transaction cost, economy, and thus scientifically calculate the weight vector ; this method converts qualitative business strategy preferences into quantitative model parameters, improving the rationality and reproducibility of parameter setting, and the sum of the three is 1; is the verification completeness function, which represents the revenue item of the system; is the consensus delay function, is the normalized transaction cost function, and the two together constitute the cost or penalty item of the system;

[0128] The system total utility function The sub-functions in the system total utility function are further defined as follows:

[0129] The verification completeness function is ; this function is derived from the information gain theory, and its physical meaning is that as the verification depth increases, the amount of information about data integrity obtained by the system is more, and the uncertainty is lower, and the function value tends to 1; wherein, is the completeness growth coefficient, which is an empirical constant obtained by statistical analysis and curve fitting of historical verification data sets;

[0130] The fitting process is as follows: a test data set containing a large amount of normal data is constructed, and tampered data is randomly injected at different proportions, such as 0.01%, 0.1%, and 1%; for data sets with different tampering proportions, different verification depths , such as =1, 2, 3... are used for verification, and the probability of successfully detecting tampering is calculated; ; a series of data points are obtained, and these data points are fitted with the verification completeness function Nonlinear least square fitting is performed to finally solve the optimal coefficient value;

[0131] The consensus latency function is characterized as ; this definition is a linear simplification of the latency and load factor positive correlation characteristics in queuing theory; the physical meaning is that the network load factor Itself as a dimensionless penalty term, the higher the load, the greater the latency penalty;

[0132] In a more accurate implementation, to reflect the reality that latency increases exponentially with load, the consensus latency function can be characterized by a nonlinear formula based on the M / M / 1 queuing model:

[0133]

[0134] This model can more realistically depict the characteristics that when the system load Tends to 1, the system transaction confirmation latency will deteriorate sharply, thus providing a more accurate cost penalty term for the utility function;

[0135] Is a function of the anchor frequency Because a higher frequency will result in more pending transactions, thus pushing up the load;

[0136] This functional relationship can be defined as:

[0137]

[0138] Where Represents the average background transaction rate generated by other participants in the supply chain or external applications, units: TPS, which can be obtained by periodic sampling statistics of the network; Is the anchor frequency set for the system, units: TPS; Is the theoretical maximum transaction throughput of the blockchain network, which is a known parameter, and this formula explicitly defines the direct contribution of the anchor behavior of the system to the load of the entire blockchain network;

[0139] The normalized transaction cost function is ; the purpose of this function is to convert the transaction cost rate with physical dimensions into a dimensionless penalty term; where Is the average cost of a single on-chain transaction, derived from statistical averaging of historical data on the Gas cost of the blockchain network; Is the budget benchmark cost rate, representing the maximum transaction cost budget that the system can accept per unit of time, derived from pre-setting according to the system operation cost requirements; by dividing the real-time cost rate By the budget benchmark The obtained Intuitively reflects the ratio of the current cost and the budget upper limit;

[0140] By introducing the light-emitting swarm optimization algorithm, an efficient global search capability is provided for finding the optimal parameter combination. More importantly, by constructing a system total utility function including a revenue item, a completeness verification item, and two types of penalty items, consensus time delay and transaction cost, the invention unifies the originally conflicting multiple optimization objectives, safety, response speed, and economy, into a quantifiable framework. The accurate mathematical definition of each sub-function enables the utility model to truly reflect the system state, so that the solution found by the optimization algorithm Can truly maximize the overall utility of the system; this provides the decision layer with a benchmark parameter for the flexible verification trigger function T, which realizes the organic combination of strategic optimization and tactical response, and significantly improves the long-term operation efficiency of the system.

[0141] Embodiment 4

[0142] In S4, the submission of the trust anchor point is completed through the oracle; the asynchronous verification triggered by the smart contract is instructed to be executed through the data verification service under the callback chain of the oracle;

[0143] This embodiment is a specific implementation of the on-chain and off-chain interaction mode in S4, which clearly illustrates that cross-system communication is achieved through the oracle;

[0144] In this embodiment, the specific implementation mechanism of the on-chain anchoring and off-chain execution in S4 is clarified:

[0145] The submission of the trust anchor point is completed through the oracle; the oracle refers to a middleware service that serves as a trusted data interaction interface between the blockchain and the external world, off-chain; its role is to provide external data for the smart contract or to pass on-chain instructions to the off-chain system; in this embodiment, the off-chain system will submit the packaged trust anchor point transaction to the oracle service; the oracle service is responsible for reliably broadcasting the transaction to the blockchain network and ensuring that it is received by the anchor smart contract;

[0146] At the same time, the asynchronous verification triggered by the smart contract is instructed to be executed through the data verification service under the callback chain of the oracle; after the anchor smart contract successfully records the trust anchor point on the chain, it will trigger a predefined on-chain event; the oracle service continuously listens to such events; once the event is listened to, the oracle will analyze the event content, such as containing the trust anchor point and the original data storage pointer, and accordingly initiate a callback request to the off-chain data verification service; the request instructs the off-chain service to verify the integrity of the original data stored in the distributed file system according to the trust anchor point uploaded from the chain;

[0147] ​By introducing the oracle as a trusted data interaction interface between on-chain and off-chain systems, the application solves the inherent limitation that the blockchain cannot directly access external data; this mechanism ensures that the trust anchor generated off-chain can be safely and reliably submitted on-chain, while also ensuring that the execution results of the on-chain smart contract can trigger precise off-chain operations; a safe and reliable two-way communication channel is constructed, which is the key technical support for realizing the mixed architecture of on-chain anchoring / off-chain execution of the application, and guarantees the automation, seamless connection and reliable execution of the entire cross-system workflow.

[0148] It should be noted that the above embodiments are only used to illustrate the technical solutions of the present application and are not limiting. Although the present application has been described in detail with reference to the preferred embodiments, it should be understood by those skilled in the art that the technical solutions of the present application can be modified or replaced by equivalents without departing from the spirit and scope of the technical solutions of the present application.

Claims

1. A blockchain-based charger supply chain data traceability management method, characterized in that, The specific steps include: S1, trust anchor generation: collect supply chain data and map data to data importance level ; based on the current trust score of the supplier with the data importance level , the data is encrypted and summarized to generate a trust anchor; S2, elastic verification decision: calculate the dynamic trust score of the supplier and the blockchain network system load factor ; will and input into the elastic verification trigger function T to make real-time decisions on the verification depth and anchor frequency ; the elastic verification trigger function T is a core self-defined decision model, which is used to convert internal trust risk and external network environment into specific operation parameters through quantitative mapping relationship, and the source is a series of preset segmented nonlinear mapping rules; S3, parameter optimization and calibration: periodically solving the system total utility function for a maximum to obtain an optimal solution ; using the optimal solution to calibrate the baseline parameters of the elasticity verification trigger function T;​ S4, On-chain anchoring and off-chain execution: according to With submitting the trust anchor to a smart contract on the blockchain for notarization; triggering the asynchronous verification of the original data stored off-chain by the smart contract; S5, closed-loop traceability verification: when receiving a traceability query, obtain the on-chain trust anchor and off-chain original data; according to the original data, recompute the verification trust anchor locally, and compare it with the on-chain trust anchor, and output the verification conclusion or trigger the risk alarm according to the comparison result; System total utility function The calculation of the system total utility function is based on the following equation: ； wherein, is a preset dimensionless weight coefficient, is a verification completeness function, is a consensus delay function, is a normalized transaction cost function.

2. The blockchain-based charger supply chain data traceability management method of claim 1, wherein, The encryption summary processing in S1 includes: If the supplier current trust score Higher or data importance level Lower, a single hash algorithm is employed to generate the trust anchor; If the supplier's current trust score Lower or data importance level Higher, then a hierarchical Merkle tree is constructed to generate a unique Merkle root as a trust anchor point. 3.The blockchain-based charger supply chain data traceability management method of claim 1, wherein, S1 after and S4 before also include: Building a dynamic knowledge graph of the supply chain off-chain; the knowledge graph is used to associate original data, trust anchors and supply chain business entities; Defining a material batch life cycle finite state machine; the state transition of the state machine is driven by an off-chain business rule engine, and an event summary containing a trust anchor is used as a state transition certificate. 4.The blockchain-based charger supply chain data traceability management method of claim 1, wherein, Supplier dynamic trust score in S2 The calculation of the trust score of the supplier S2 is based on the following formula: ； wherein, is the current trust score, is the previous period score, is the learning rate, is the current period validation result, is the time interval, is the trust decay time constant. 5.The blockchain-based charger supply chain data traceability management method of claim 1, wherein, S2 blockchain network system load factor The calculation is made according to the following formula: ； wherein, is the system load factor, is the number of transactions to be processed, is the theoretical maximum TPS of the blockchain, is the statistical time window.

6. The blockchain-based charger supply chain data traceability management method of claim 1, wherein, The decision mechanism of the elastic verification trigger function T in S2 is set as: When on the way down, the value of is mapped to a higher integer; When on the rise, the value of is mapped to a lower value.

7. The blockchain-based charger supply chain data traceability management method of claim 1, wherein, The parameter optimization in S3 is achieved by the iterative search of the photogenic swarm optimization algorithm to find the optimal solution that makes the system total utility function reach the maximum value. .​ 8.The blockchain-based charger supply chain data traceability management method of claim 1, wherein, System total utility function The sub-functions in the system total utility function are defined as follows: The verification completeness function is wherein is a completeness growth coefficient; The consensus delay function is characterized as ; The normalized transaction cost function is where is the average cost per transaction, is the budgeted base cost rate. 9.The blockchain-based charger supply chain data traceability management method of claim 1, wherein, In S4, the submission of the trust anchor is completed through the oracle; the asynchronous verification triggered by the smart contract is executed through the oracle callback off-chain data verification service.

Images