Cross-operator charging recommendation and trusted settlement method based on block chain

Abstract

The invention relates to the technical field of block chain technology and electric vehicle charging service, and discloses a cross-operator charging recommendation and credible settlement method based on a block chain, and the method comprises the steps: firstly collecting multi-operator node data, and generating an initial path set through Hash verification and cross-chain association; and the matching degree between the user demand and the operator permission is calculated according to the field information, and the permission path meeting the requirement is screened out. On the basis, a priority coefficient is calculated by integrating the matching degree, the node trust degree and the account period span, and a recommendation list with a settlement control field is generated. And then, a dynamic multi-count Bloom filter is adopted to verify the real-time performance of the state, and the block chain account book index is compared to screen unoccupied paths, so that a synchronous settlement path list can be formed. And finally, writing the list into a block chain according to an account period section, checking node consistency, and generating a final settlement state. According to the method, the credibility of cross-operator data can be ensured, and efficient real-time recommendation and automatic settlement can be realized.

Description

Technical Field

[0001] This invention relates to the fields of blockchain technology and electric vehicle charging service technology, specifically a blockchain-based cross-operator charging recommendation and trusted settlement method, as well as a computer terminal and computer-readable storage medium for applying this method. Background Technology

[0002] With the global electric vehicle ownership increasing year by year, "cross-operator collaboration" of charging infrastructure has become a core requirement for solving the problems of "difficulty in finding charging stations and cumbersome settlement". At present, the existing technologies for cross-operator charging services are mainly divided into two categories: centralized intermediary service solutions and blockchain-assisted collaboration solutions. Both types of solutions have significant limitations in structural design, core principles and practical applications, and cannot simultaneously meet the comprehensive requirements of "trustworthiness, efficiency, privacy and scalability".

[0003] The first category of existing technologies: centralized cross-operator charging service solutions. The current mainstream solution in the market is the "third-party centralized platform-mediated model," whose core architecture includes: a single third-party platform as the core node, connecting N charging operators, M charging pile terminals (including public and private piles), and user terminals (APP / vehicle system), forming a "star topology"; third-party platform modules: including user identity management module, charging pile data collection module, order scheduling module, manual reconciliation and settlement module, and complaint handling module; operator interface module: each operator synchronizes local charging pile status (idle / occupied, power, electricity price) and user order data to the third-party platform through API interface; user interaction module: users complete "one-time registration - multi-operator use" through the APP, but need to authorize the third-party platform to obtain sensitive information such as mobile phone number and vehicle VIN code. The core principle of this type of technology is to rely on a third-party platform for "centralized data storage + manual intervention settlement". The specific process is as follows: the user initiates a charging request → the third-party platform queries the charging pile data of various operators → returns recommended results (based only on distance and price sorting); the user completes charging → the operator uploads the transaction data to the third-party platform → the platform manually verifies the data of multiple operators (usually in a T+1 cycle); after verification, the platform allocates funds according to the agreed ratio (e.g., operator 92%, platform 8%) and generates a settlement voucher. This type of solution suffers from four core flaws, which have become bottlenecks for the industry's large-scale development: ① Single point of failure and data tampering risk: The third-party platform is the sole data storage and scheduling node. Once the server crashes or internal data is tampered with, it will lead to the paralysis of the entire network service or transaction disputes, and neither users nor operators can independently verify the authenticity of the data; ② Low settlement efficiency and high cost: Manual reconciliation takes as long as 2-3 days, and the handling fee generally accounts for 5%-8%; ③ Low recommendation accuracy and serious privacy leakage: The recommendation algorithm only relies on two-dimensional data of "distance (weight 60%) + electricity price (weight 40%)", without incorporating key dimensions such as charging pile failure rate, green electricity attributes, and user charging habits. The recommendation matching degree is only 75%-80%. At the same time, users need to authorize the third-party platform with sensitive information such as ID card, bank card, and vehicle location; ④ Poor scalability and difficulty in private charging pile access: The third-party platform has high entry barriers for operators, and private charging pile owners cannot access the platform due to lack of operating qualifications. In addition, the platform's data interface is not standardized, and the data format of charging piles from different operators is not uniform, with the access cycle for new operators taking as long as 1-2 months.

[0004] The second category of existing technologies: Blockchain-assisted cross-carrier charging service solutions. For example: (1) Cross-chain information verification scheme with multi-chain architecture: A dual-chain architecture of "main chain + sub-chain" is proposed. The main chain stores the reputation data of charging piles shared across operators, and the sub-chain stores the local order data of each operator; through "cross-chain trusted smart contracts ( The system uses Merkle proofs to verify data authenticity and Multi-Count Bloom Filters (MCBFs) to verify data real-time performance. However, it has several drawbacks: ① MCBFs use static hash functions (4 fixed hash functions), and when peak charging data volume is ≥100 records / second, the rate of missed detection for expired data increases from 1% to 3.2%; ② It lacks a recommendation algorithm and settlement module, only achieving "data trustworthiness" without forming a closed loop of "recommendation-transaction-settlement"; ③ The main chain uses traditional PBFT consensus, requiring verification from ≥2 / 3 of the nodes, preventing edge charging piles (with computing power ≤2GB RAM) from participating, relying solely on core operator nodes, thus posing a risk of "consensus centralization."

[0005] (2) Consortium blockchain charging transaction model: A consortium blockchain is jointly established by 5-10 operators, and each operator deploys accounting nodes; the PBFT consensus algorithm is used to verify charging transactions, and the "order creation-transaction confirmation-fund storage" function is implemented through smart contracts; Disadvantages: ① The consortium blockchain does not have an independent "trusted data chain", and all data is stored in a single chain, which poses a risk of "overexposure of data"; ② The consensus algorithm is not adapted to edge nodes, and private charging piles cannot be connected to the consortium blockchain; ③ There is no charging recommendation function, and users still need to manually select charging piles from multiple operators, so the experience is not improved.

[0006] (3) Smart charging system of consortium blockchain: Based on the Hyperledger Fabric consortium blockchain, a "charging scheduling smart contract" is designed, and the BOMILP (mixed integer linear programming) model is used to optimize the allocation of charging piles and balance the revenue of operators and the needs of users. Disadvantages: ① The recommendation model only includes two variables: "user charging time" and "operator equipment utilization rate", without considering the green electricity attributes and service experience, which is out of touch with the current "dual carbon" policy and user experience needs; ② The "full data on chain" mode is adopted, and the privacy data such as user charging history and vehicle model are directly stored on the consortium blockchain and can be queried by all nodes, which violates the "sensitive personal information protection" requirements of Article 28 of the Personal Information Protection Law; ③ No cross-chain mechanism is designed, which only supports operator collaboration within a single consortium blockchain and cannot be extended to external operators.

[0007] (4) Multi-consortium chain transaction framework: Construct a dual consortium chain architecture of "operator consortium chain + payment consortium chain", realize cross-chain transaction verification through node voting mechanism, and use BLS threshold signature to ensure that the transaction is tamper-proof; Disadvantages: ① Cross-chain verification requires the transmission of full transaction data (including complete Merkle tree nodes), the data transmission volume reaches 500KB / transaction, and the transmission delay of edge nodes exceeds 1 second; ② There is no exception handling mechanism. When the offline rate of a consortium chain node is ≥20%, the cross-chain transaction is directly interrupted, which is not robust enough; ③ There is no associated charging recommendation module. Users need to manually switch between multiple consortium chains to query charging piles, which is complicated. Summary of the Invention

[0008] To address the technical problems existing in the prior art, this invention provides a blockchain-based cross-carrier charging recommendation and trusted settlement method, which can not only ensure the trustworthiness of cross-carrier data, but also achieve efficient real-time recommendation and automated settlement.

[0009] To achieve the above objectives, the present invention provides the following technical solution: This invention discloses a blockchain-based cross-carrier charging recommendation and trusted settlement method, comprising the following steps: S1. Collect node data from multiple operators, verify it with hashes and associate it with cross-chain fields to generate an initial set of fields for the charging path; S2. Based on the field information in the initial field set of the charging path, calculate the matching degree between user needs and operator permissions, thereby filtering out a set of charging permission paths that meet the requirements; S3. Based on the set of charging permission paths, calculate the recommendation priority coefficient by combining the matching degree, operator node trust degree and billing period span, and generate a list of charging recommendation paths with settlement control fields accordingly; S4. A dynamic multi-count Bloom filter is used to verify the real-time status of the charging recommended path list, and the paths in the list are compared with the blockchain ledger index to filter out unoccupied paths, generating a list of charging recommended settlement paths that can be synchronized. S5. Write the fields in the charging recommended settlement path list into the blockchain ledger according to the payment period segment, verify the consistency of writing between nodes, and generate the final settlement status set.

[0010] As a further improvement to the above solution, step S1 includes the following specific steps: S11. Collect three types of data from N operators: charging pile data, user demand data, and payment data. Based on this, calculate the paired hash value of each data record, i.e., the path field and the billing period field, to obtain the effective set of node billing period paths. The charging pile data includes charging piles ,power Electricity price and the proportion of green electricity User request data includes user anonymity. Required charging amount Distance limit The received data includes the payment period identifier. and settlement cycle The formula for calculating the paired hash value is as follows: ; In the formula, The paired hash value for the data record; This is the charging path field; This is the payment period field; The salt value is random. Indicates string concatenation; It is a hash algorithm; S12. For the valid set of node billing period paths, assign sorting numbers according to the order of the path fields in the data, extract the position index of the billing period field in the path field, and calculate the mapping coefficient between the path sorting and the billing period position. Obtain the billing period field order mapping table based on the calculation results. The order mapping table for the payment period field includes the sorting number, the position index, the mapping coefficient, and the grouping identifier; the formula for calculating the mapping coefficient is: ; In the formula, The mapping coefficient between path sorting and payment period position; Weight the payment period field; For sorting numbering; For location index; S13. Based on the order mapping table of the payment period field, associate the charging pile attribute field with the user demand field, and calculate the cross-chain field correlation degree for each record: ; In the formula, For cross-chain field correlation; The actual percentage of green electricity This represents the upper limit for the proportion of green electricity. The actual distance between the charging station and the user. This represents the maximum distance between the charging station and the user. To serve actual ratings, The maximum score for service rating; , and These are the correlation weights for green electricity ratio, distance, and service score, respectively. S14. Retain records whose cross-chain field correlation is not less than a set threshold to obtain the initial field set of the charging path, which includes the path field, billing period field, correlation degree and basic attribute field.

[0011] As a further improvement to the above scheme, step S2 includes the following specific steps: S21. Extract the user identity field and operator permission field from the basic attribute fields in step S14, align them according to the path segment order, calculate the field position offset, and compare it with a preset offset threshold to obtain the field position pairing result, which includes the aligned valid records and the corresponding field position offset values; wherein, the formula for calculating the field position offset is: ; In the formula, This is the field position offset; For the location index of the identity field; Index the location of the permission field; This is the offset coefficient; S22. Based on the field position matching results, multiple user requirement dimensions are introduced to calculate the requirement-permission matching degree for each data record and verify whether it meets the standards; the formula for calculating the requirement-permission matching degree is: ; In the formula, Demand-permission matching degree; , and They are respectively , and The association weight; Based on the degree of matching of basic needs, To match the demand for low carbon, To determine the service demand matching degree, the calculation formulas for the three are as follows: ; ; ; In the formula, To meet user demand for charging capacity; This is the minimum charging capacity for the charging station. To meet user demand for green electricity ratio; Rate services based on user needs; Actual service rating; S23. For data records that meet the matching degree in step S22, calculate the confidence score for permission release and retain the data records with the qualified confidence score to obtain a set of charging permission paths that meet the requirements. This set needs to be confirmed by the signatures of ≥51% of the consortium blockchain nodes. The charging permission path set includes a path field, a requirement-permission matching degree, and a confidence score for permission release. The formula for calculating the confidence score for permission release is: ; In the formula, Release confidence for permissions; This represents the number of nodes that passed verification. This represents the total number of nodes participating in the verification.

[0012] As a further improvement to the above scheme, in step S21, if the field position offset is not higher than the offset threshold, the alignment is effective; otherwise, the field position is adjusted and re-aligned.

[0013] As a further improvement to the above scheme, step S3 includes the following specific steps: S31. Associate the path field and the billing period field in the charging permission path set to calculate the billing period span of the path: ; In the formula, For the payment period span of the path; and These are the start and end dates of the payment period; S32. Combining matching degree, payment period span, and stage trust degree, calculate the recommendation priority coefficient and priority level for each path; the priority level is divided into three levels: high, medium, and low; the formula for calculating the recommendation priority coefficient is: ; In the formula, This is the recommendation priority coefficient; This is the maximum payment period. Trust level of operator nodes; , and These are the correlation weights for matching degree, payment period span, and stage trust, respectively. S33. Add settlement control fields according to priority level and calculate the validity of the control fields: ; reserve The path is determined by excluding duplicate records, resulting in a list of recommended charging paths with control constraints, including priority sorting, control fields, and the validity of the control fields; the hash value of the recommended charging path list needs to be synchronized to the main blockchain.

[0014] As a further improvement to the above scheme, in step S32, the formula for calculating the operator node trust level is as follows: ; In the formula, To incorporate dynamic reward and penalty coefficients, adjustments are made dynamically based on the duration of consecutive anomalies, cross-chain verification accuracy, and response latency compliance rate; the formula for calculating the basic trust value is as follows: The basic trust value is calculated using the following formula: ; In the formula, The number of times to verify consistency for nodes; Total number of node verifications; To delay the number of compliant requests; This represents the total number of node responses. This represents the total number of violations or abnormal behaviors committed by the operator's sub-chain nodes within the trust calculation period. This is a preset threshold for the maximum number of anomalies that a node can accept. , and As weight, .

[0015] As a further improvement to the above scheme, step S4 includes the following specific steps: S41. Extract the status field from the charging recommended path list. The status field value is either occupied or unoccupied. A dynamic multi-count Bloom filter is used to verify the real-time performance of the status, calculate the status false negative rate, and retain unused paths with a status false negative rate not exceeding a preset threshold. This results in a path status field information table, which includes status field values ​​and the status false negative rate. The formula for calculating the status false negative rate is as follows: ; In the formula, The false negative rate is the rate at which the status is not detected. The number of hash functions; Number of status fields; The filter bit length; e It is a natural constant; S42. Read the state field index of the blockchain ledger and calculate the similarity between the current path hash and the index: ; In the formula, The hash value of the current path; The hash value of the occupied path stored in the status field index; Filter paths with similarity below a preset similarity threshold, partition them by status missing type, and obtain a list of missing path status fields. This list records the number of unused paths and their corresponding similarity. S43. For paths in the missing list of path status fields, append synchronization timestamps and node signatures, and calculate synchronization integrity: ; In the formula, For synchronization integrity; This represents the number of signature nodes. This represents the total number of nodes. The current time; Paths with synchronization integrity not lower than a preset integrity threshold are considered valid synchronization paths, thus obtaining a list of recommended charging settlement paths that can be synchronized. This list includes synchronization status data and synchronization integrity.

[0016] As a further improvement to the above scheme, step S5 includes the following specific steps: S51. Classify the fields in the charging recommended settlement path list into: recommendation fields, settlement fields, or status fields, and assign weights to different categories of fields. This classification process yields a path field classification result table, which includes the field category and its weight. The formula for calculating the field weight is: ; In the formula, For the first c Weight of class fields For recommended field classes, For settlement field class, For status field class; For the first c Number of class fields; S52. Divide the path into segments according to the billing period representation and calculate the billing period coverage for each path: ; In the formula, For payment terms coverage; This represents the number of intersections between the path billing period and the segment billing period; This represents the total number of payment periods for each segment; if If the percentage exceeds the set percentage, it will be classified into that segment; each segment includes a set number of paths, thus obtaining the charging settlement period segment division table, which includes segment number and coverage path list; S53. Write the fields classified in step S51 into the blockchain ledger according to the segments divided in step S52, and calculate the consistency of writes among nodes: ; In the formula, Ensure write consistency between nodes; Write a consistent number of nodes for the field; The total number of objects involved in a specific operation for the charging path; If the value is not less than the set consistency threshold, the write is considered valid. Each field corresponds one-to-one with a segment path. After being written into the blockchain ledger, a block hash value is generated and synchronized to all consortium blockchain nodes to obtain a set of charging recommendation settlement status fields. This set includes the field data of each segment, the consistency of writing between nodes, and the block hash value, serving as the final, tamper-proof record of the blockchain.

[0017] The present invention also discloses a computer terminal, including a memory, a processor, and a computer program stored in the memory and executable on the processor. When the processor executes the computer program, it implements the steps of a blockchain-based cross-carrier charging recommendation and trusted settlement method as described above.

[0018] The present invention also discloses a computer-readable storage medium having a computer program stored thereon, wherein when the program is executed by a processor, it implements the steps of the blockchain-based cross-carrier charging recommendation and trusted settlement method described above.

[0019] Compared with the prior art, the beneficial effects of the present invention are: 1. The three-layer multi-chain distributed design of this invention solves the problems of "single point of failure + data silos" in existing technologies. It adopts a three-layer architecture of "main chain (core consensus) + operator sub-chain (business processing) + trusted data chain (privacy storage)". The sub-chain nodes use lightweight edge hardware, and the chains are connected through standardized cross-link interfaces. Compared with the single-chain blockchain or centralized server commonly used in existing technologies, this invention can effectively avoid centralized single point of failure, improve hardware redundancy, and the standardized interface supports the access of new operators. Its scalability is better than the existing single-chain / centralized architecture.

[0020] 2. The recommended process of this invention includes "federated learning three-dimensional matching (basic needs / low-carbon needs / service needs, with dynamic weight iteration) + dynamic MCBFs state verification (the number of hash functions k is adjusted according to the amount of data)". Compared with the existing technology's "distance / electricity price single-dimensional recommendation" without dynamic verification, this invention can improve the accuracy of charging recommendations, meet users' green travel needs, and improve recommendation response efficiency. The dynamic multi-count Bloom filter can reduce the state omission rate and reduce invalid recommendations.

[0021] 3. The settlement process of this invention adopts "partitioned writing of settlement period segments (batch writing at certain time intervals) + PBFT layered consensus (participation when trust level reaches threshold) + dynamic cross-chain contract (hash mutual exclusion scheduling)". Compared with the technically advanced "writing one record at a time + full node consensus", this invention can shorten the settlement cycle, partitioned writing can improve the efficiency of ledger writing, reduce the settlement anomaly rate, and eliminate problems such as duplicate settlement and amount errors. In addition, dynamic cross-chain contract reduces inter-chain conflicts and improves the success rate of cross-operator settlement.

[0022] 4. The sub-chain nodes of this invention have a built-in dynamic DID identity function and use lightweight zero-knowledge proof (ZKP) to process user privacy data (such as anonymous ID, charging needs), thereby reducing the risk of user privacy data leakage. Zero-knowledge proof ensures that "data is usable but not visible". Operator business data is stored in isolation through the sub-chain, avoiding the leakage of business secrets caused by data sharing under the existing single-chain architecture. Attached Figure Description

[0023] Figure 1 This is a flowchart of the blockchain-based cross-carrier charging recommendation and trusted settlement method in Embodiment 1 of the present invention.

[0024] Figure 2This is a schematic diagram of the structure of the computer terminal in Embodiment 2 of the present invention. Detailed Implementation

[0025] The technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present invention, and not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention.

[0026] Example 1 The core objective of this invention is to address the four major shortcomings of existing technologies: "imbalance between reliability and efficiency, incomplete recommendation dimensions, insufficient privacy protection, and poor robustness and scalability." The invention provides an integrated technical solution combining "multi-chain collaboration, dynamic cross-chain functionality, multi-dimensional recommendation, and privacy compatibility," with the specific objectives as follows: Addressing the imbalance between "trustworthiness and efficiency": To address the single point of failure / data tampering risks of centralized solutions and the high cross-chain verification latency of blockchain solutions, a "lightweight cross-chain verification + layered consensus" mechanism is constructed to achieve trusted data flow across operators while reducing cross-chain verification latency and shortening transaction settlement cycles.

[0027] Addressing the shortcomings of incomplete recommendation dimensions and low accuracy: To address the issue that existing solutions rely solely on two-dimensional "distance-price" recommendations and lack key dimensions such as green electricity attributes / service experience, a "federated learning + three-dimensional variables" recommendation model is designed to improve the matching degree of charging resources and adapt to relevant requirements and user experience upgrade needs.

[0028] Addressing the compatibility issues between privacy protection and traceability: To address the privacy leakage risks of centralized solutions and the problems of "full on-chain exposure of privacy" and "complete anonymity and lack of traceability" in blockchain solutions, a "dynamic anonymity + authorized access" mechanism is constructed to achieve zero leakage of sensitive user data while ensuring traceability of abnormal transactions; To address the shortcomings of poor robustness and low scalability: In response to the problems of existing solutions being unable to adapt to edge nodes, service interruption when nodes go offline, and long operator access cycles, an "edge adaptation consensus + anomaly fault tolerance" mechanism is designed to support normal operation when the node offline rate is within a certain range, allowing private charging piles to be connected and shortening the access cycle for new operators.

[0029] Please see Figure 1This embodiment provides a blockchain-based cross-carrier charging recommendation and trusted settlement method. It follows the blockchain collaborative logic of "data association - permission matching - control sorting - ledger verification - field writing," and combines cross-chain trusted verification and multi-dimensional recommendation optimization technologies to achieve accurate recommendation and real-time settlement in cross-carrier charging scenarios. Each step is quantitatively calculated using formulas to ensure controllable results. The specific steps are as follows, namely S1~S5.

[0030] S1. Collect node data from multiple operators, verify it with hash and associate it with cross-chain fields to generate an initial set of fields for the charging path.

[0031] This step, based on data from multiple carrier nodes, establishes cross-chain data associations through hash verification and field mapping to ensure data integrity. Specifically, it includes steps S11 to S14.

[0032] S11. Collect three types of data from N operators: charging pile data, user demand data, and payment data. Based on this, calculate the paired hash value of each data record, i.e., the path field and the billing period field, to obtain the valid set of node billing period paths.

[0033] The charging pile data includes charging piles ,power Electricity price and the proportion of green electricity User request data includes user anonymity. Required charging amount Distance limit The received data includes the payment period identifier. and settlement cycle The formula for calculating the paired hash value is as follows: ; In the formula, The paired hash value for the data record; This is the charging path field, formatted as: "Operator ID-Charging Pile ID-User Anonymous ID"; This is the payment period field, formatted as "YYYYMM"; The salt value is a random value with a length of [length value]. This is used to avoid hash collisions; Indicates string concatenation; The algorithm uses a hash function, conforms to blockchain data encryption standards, and the salt value is randomly generated by each operator node, requiring cross-node consistency verification (verification pass rate ≥ 100%). ).

[0034] like If the hash value matches the one stored locally by the operator, the pairing is considered "valid"; otherwise, it is marked as "data abnormal" and needs to be collected again. After calculating the pairing hash value, a valid set of node billing paths is obtained, which includes valid pairing records and their corresponding... value.

[0035] S12. Assign sorting numbers to the valid set of node billing cycle paths according to the order of the path fields in the data. (1~N), extract the position index of the billing period field in the path field, and then calculate the mapping coefficient between the path sorting and the billing period position. Based on the calculation results, obtain the order mapping table of the billing period field. The order mapping table for the payment period field includes the sorting number, the position index, the mapping coefficient, and the grouping identifier; the formula for calculating the mapping coefficient is: ; In the formula, The mapping coefficient between path sorting and payment period position; Weight the payment period field; For sorting numbering; For location indexing, such as in the path field "Operator A-Pile 001-User 101-202510", =4.

[0036] Based on the calculations, a mapping table for the order of payment period fields is obtained, containing... , , and group identifiers.

[0037] S13. Based on the aforementioned billing period field sequence mapping table, associate the charging pile attribute fields (green electricity ratio G, service score S) with the user demand field, and calculate the cross-chain field correlation degree for each record: ; In the formula, For cross-chain field correlation; The actual percentage of green electricity This is the upper limit for the proportion of green electricity (usually taken as 100%). The actual distance between the charging station and the user. This represents the maximum distance between the charging station and the user. To serve actual ratings, The maximum score for service rating (usually 5 points); , and The correlation weights are respectively the proportion of green electricity, distance, and service score, and satisfy the following conditions: + + =1; S14. Retain records whose cross-chain field correlation is not less than a set threshold to obtain the initial field set of the charging path, which includes the path field, billing period field, correlation degree and basic attribute field.

[0038] In this embodiment, only retain For records with a value ≥0.6, ensure the validity of field associations, and finally obtain the initial field set for the charging path, which includes the path field, billing period field, association degree, and basic attribute fields.

[0039] S2. Based on the field information in the initial field set of the charging path, calculate the matching degree between user needs and operator permissions, thereby filtering out a set of charging permission paths that meet the requirements.

[0040] This step combines user needs with operator permissions to filter valid paths through matching degree calculation. Specifically, it includes steps S21 to S23.

[0041] S21. Extract the user identity field (anonymous ID, demand identifier) ​​and operator permission field (charging pile open status, settlement permission) from the basic attribute fields in step S14. Align them according to the path segment order, calculate the field position offset, and compare it with a preset offset threshold to obtain the field position matching result, which includes the aligned valid records and the corresponding field position offset values; wherein, the formula for calculating the field position offset is: ; In the formula, This is the field position offset; For the location index of the identity field; Index the location of the permission field; The offset coefficient (determined by voting among consortium blockchain nodes to ensure the offset amount) ).

[0042] In this embodiment, if the field position offset If the alignment is correct, then the alignment is effective; otherwise, the field positions need to be adjusted and realigned.

[0043] The field position pairing results are obtained through calculation, including the aligned valid records and their corresponding... value.

[0044] S22. Based on the field position matching results, multiple user requirement dimensions are introduced to calculate the requirement-permission matching degree for each data record and verify whether it meets the standards; the formula for calculating the requirement-permission matching degree is: ; In the formula, Demand-permission matching degree; , and They are respectively , and The association weight; Based on the degree of matching of basic needs, To match the demand for low carbon, To determine the service demand matching degree, the calculation formulas for the three are as follows: ; ; ; In the formula, To meet user demand for charging capacity; This is the minimum charging capacity for the charging station. To meet user demand for green electricity ratio; Rate services based on user needs; The actual rating is based on the service.

[0045] The deviation between the requirements and permission fields is calculated, and the deviation is recorded for each path. Values ​​and deviation dimensions.

[0046] filter The records are used to further verify the triggering conditions of the permission fields.

[0047] S23. For data records that meet the matching degree in step S22, calculate the confidence score for permission release and retain the data records with the qualified confidence score to obtain a set of charging permission paths that meet the requirements. This set needs to be confirmed by the signatures of ≥51% of the consortium blockchain nodes. The charging permission path set includes a path field, a requirement-permission matching degree, and a confidence score for permission release. The formula for calculating the confidence score for permission release is: ; In the formula, Release confidence for permissions; This represents the number of nodes that passed verification. The total number of nodes participating in the verification (≥5).

[0048] Considered "permissions can be released". Reserved. The path is used to obtain a set of charging permission paths that meet the requirements, including the path field. , It requires signature confirmation from ≥51% of the consortium blockchain nodes.

[0049] S3. Based on the set of charging permission paths, calculate the recommendation priority coefficient by combining the matching degree, operator node trust degree and billing period span, and generate a list of recommended charging paths with settlement control fields accordingly.

[0050] This step optimizes the recommendation order by calculating priority and adding control fields, specifically including S31~S33.

[0051] Step S3 includes the following specific steps: S31. Associate the path field and the billing period field in the charging permission path set to calculate the billing period span of the path: ; In the formula, For the payment period span (unit: months); and These are the start and end dates of the payment period.

[0052] The payment period must meet the following requirements. ≥1 month; otherwise, the default payment period is the current payment period + 1 month.

[0053] S32. Combining matching degree, payment period span, and stage trust degree, calculate the recommendation priority coefficient and priority level for each path; the priority level is divided into three levels: high, medium, and low; the formula for calculating the recommendation priority coefficient is: ; In the formula, This is the recommendation priority coefficient; Maximum payment period (set according to industry scenario); Trust level of operator nodes; , and These are the correlation weights for matching degree, payment period span, and stage trust degree, respectively. 0.6-0.8 is high priority, 0.6-0.8 is medium priority, and <0.6 is low priority. A priority table is calculated to record the priority of each path. And priority level.

[0054] The formula for calculating the trust level of an operator's node is as follows: ; In the formula, To incorporate dynamic reward and penalty coefficients, adjustments are made dynamically based on the duration of consecutive anomalies, cross-chain verification accuracy, and response latency compliance rate; the formula for calculating the basic trust value is as follows: The basic trust value is calculated using the following formula: ; In the formula, The number of times to verify consistency for nodes; Total number of node verifications; To delay the number of compliant requests; This represents the total number of node responses. This represents the total number of violations or abnormal behaviors committed by the operator's sub-chain nodes within the trust calculation period. This is a preset threshold for the maximum number of anomalies that a node can accept. , and As weight, .

[0055] Overlay dynamic reward and punishment coefficient The specific design is as follows: ①Reward Scenarios ( (positive value) For consecutive days without any abnormalities (≥15 days): the reward coefficient is +0.05; Participating in cross-chain verification ≥ 1000 times with 100% accuracy: the reward coefficient is +0.03; Assisting in fixing other node anomalies ≥ 2 times within the same payment period: the reward coefficient is +0.02; The cumulative reward coefficient should not exceed 0.1 to avoid excessive trust levels that deviate from reality.

[0056] ②Punishment scenarios ( (negative value) Single severe anomaly: penalty coefficient is -0.05; If the response delay compliance rate is less than 80% for three consecutive days, the penalty is -0.03. Failure to synchronize ledger data as required ≥ 2 times: Penalty coefficient is -0.02; The cumulative penalty coefficient should not be lower than -0.1 to prevent excessive reduction in trust level.

[0057] S33. Control Field Appendage and Path List Generation

[0058] Add settlement control fields according to priority level, with higher priority fields set as "priority settlement" and transaction fee rates. =2%; Priority is given to "normal settlement", with a handling fee rate of 2%. =3%; Low-priority "delayed settlement" handling fee rate =4%, calculate the validity of the control field: ; reserve The path is determined by excluding duplicate records, resulting in a list of recommended charging paths with control constraints, including priority sorting, control fields, and the validity of the control fields; the hash value of the recommended charging path list needs to be synchronized to the main blockchain.

[0059] S4. A dynamic multi-count Bloom filter is used to verify the real-time status of the charging recommended path list, and the paths in the list are compared with the blockchain ledger index to filter out unused paths, generating a list of charging recommended settlement paths that can be synchronized.

[0060] This step verifies the status field and compares it with the ledger to ensure that the path is not occupied, specifically including S41~S43.

[0061] S41. Extract the status field from the charging recommended path list. The status field value is either occupied or unoccupied. A dynamic multi-count Bloom filter is used to verify the real-time performance of the status, calculate the status false negative rate, and retain unused paths with a status false negative rate not exceeding a preset threshold. This results in a path status field information table, which includes status field values ​​and the status false negative rate. The formula for calculating the status false negative rate is as follows: ; In the formula, The false negative rate is the rate at which the status is not detected. The number of hash functions (dynamically adjusted: when the data volume is ≥100 records / second). =6, otherwise =4); Number of status fields; The filter bit width (fixed at 1024 bits); e It is a natural constant; It is considered "valid status".

[0062] Only retain "unoccupied" and The path is obtained, and the path status field information table is obtained, which includes the status field values. .

[0063] S42. Ledger Index Comparison and Missing List Generation Read the state field index of the blockchain ledger (stores the hash values ​​of occupied paths) ), calculate the similarity between the current path hash and the index: ; In the formula, The hash value of the current path; This is the hash value of the occupied path stored in the status field index.

[0064] Paths with similarity scores below a preset similarity threshold are filtered out and partitioned by status missing type to obtain a list of missing path status fields. This list records the number of unused paths and their corresponding similarity scores.

[0065] In this embodiment, Considered "unoccupied" (no risk of hash collision). Filter. The paths are partitioned by status missing type to obtain a list of missing path status fields, recording the number of unused paths and... .

[0066] S43. For paths in the missing list of path status fields, append a synchronization timestamp. (Accurate to the second) Calculate synchronization integrity using node signatures: ; In the formula, For synchronization integrity; Number of signature nodes (≥3); This represents the total number of nodes. This is the current time.

[0067] Paths with synchronization integrity not lower than a preset integrity threshold (set to 0.8 in this embodiment) are considered valid synchronization paths, thereby obtaining a list of recommended charging settlement paths that can be synchronized. This list includes synchronization status data and synchronization integrity.

[0068] S5. Write the fields in the charging recommended settlement path list into the blockchain ledger according to the payment period segment, verify the consistency of writing between nodes, and generate the final settlement status set.

[0069] This step involves writing data into fields according to payment periods to ensure consistency of the ledger, specifically including steps S51 to S53.

[0070] S51. Categorize the fields in the charging recommended settlement path list as: Recommended fields (priority) Matching degree ), settlement field (amount) Handling fees ) or status field (synchronization status, payment period) This process involves assigning weights to different categories of fields, resulting in a path field classification result table. This table includes the field categories and their weights; the formula for calculating the field weights is as follows: ; In the formula, For the first c Weight of class fields For recommended field classes, For settlement field class, For status field class; For the first c Number of class fields, ensure .

[0071] S52. Divide the path into segments according to the billing period representation and calculate the billing period coverage for each path: ; In the formula, For payment terms coverage; This represents the number of intersections between the path billing period and the segment billing period; This represents the total number of payment periods for each segment; if If the percentage exceeds the set percentage (50% in this embodiment), it is classified into this segment; each segment includes a set number of paths, thereby obtaining the charging settlement period segment division table, which includes segment number and coverage path list.

[0072] Each segment contains ≥10 paths to ensure even data distribution, resulting in a charging settlement period segment division table, which includes segment number and a list of covered paths.

[0073] S53. Write the fields classified in step S51 into the blockchain ledger according to the segments divided in step S52, and calculate the consistency of writes among nodes: ; In the formula, Ensure write consistency between nodes; Write a consistent number of nodes for the field; The total number of objects involved in a specific operation for the charging path; If the write is not less than the set consistency threshold (90% in this example), it is considered valid.

[0074] Each field corresponds one-to-one with a segment path. After being written into the blockchain ledger, a block hash value is generated and synchronized to all consortium blockchain nodes to obtain a set of charging recommendation settlement status fields. This set includes field data for each segment and write consistency between nodes. And the block hash value, which serves as the final, immutable record of the blockchain.

[0075] In summary, the core highlight of this invention lies in its targeted breakthrough of the shortcomings of existing technologies, forming a differentiated technical solution through "architectural innovation + mechanism optimization + algorithm upgrade," as detailed below: ① Three-layer multi-chain architecture: solves the defects of "data co-location + privacy exposure + poor scalability". Breaking through the limitations of existing blockchain solutions' "dual-chain / dual-consortium-chain" architecture, we design a three-layer architecture of "main chain + operator sub-chain + trusted data chain": Main chain: Only stores global cross-chain instructions, consensus rules and sub-chain identity identifiers, and does not store specific business data, thus avoiding "high storage pressure on the main chain"; Operator subchain: Each operator deploys independently to store local private data such as orders / charging pile status, ensuring operational autonomy and solving the problem of "data mixing exposing privacy"; Trusted Data Chain: Stores only anonymized shared data and limits the scope of data through dynamic access control, thus solving the privacy risks of "putting all data on the chain".

[0076] ② Dynamic cross-chain trusted contracts: Solving the defects of "static verification missed detection + full transmission delay". In Heetal.2021 Based on T-contracts, three core mechanisms have been optimized: Dynamic MCBFs: Automatically adjust the number of hash functions based on the real-time data volume to reduce the rate of missed detection of expired data and solve the defect of "poor adaptability of static configuration"; Lightweight zero-knowledge proof: Only the "Merkle hash validity digest" is transmitted instead of the full data, reducing the amount of data transmitted, lowering the transmission latency of edge nodes, and solving the problem of high latency in full data transmission; Hash-based mutual exclusion dynamic scheduling: Status update requests for the same charging pile are sorted by priority based on "timestamp + device ID" to avoid data conflicts between chains and solve the problem of "data write disorder under high concurrency".

[0077] ③ Federated Learning 3D Recommendation Model: Addressing the shortcomings of "incomplete recommendation dimensions + exposure of privacy data" Breaking through the limitations of existing recommendation algorithms in terms of "single dimension + data exposure": Federated learning and training: Each operator trains a recommendation sub-model locally using user data and only uploads the model parameters, thus solving the problem of "exposing privacy by uploading all data to the blockchain"; Three-dimensional recommendation variables: integrating "basic variables (distance ≤ 5km, electricity price ±10%) + low-carbon variables (green electricity ratio ≥ 80%) + experience variables (service rating ≥ 4.5 stars, interface compatibility rate ≥ 95%)", with weights dynamically adjusted according to user needs; Real-time model iteration: The global model is updated periodically based on new transaction data, and the recommendation matching degree is continuously optimized as data accumulates.

[0078] ④ Layered consensus and fault tolerance mechanism: to solve the defects of "poor edge node adaptation + service interruption". To address the differences in computing power across different nodes and the risk of offline operation, a layered consensus and fault-tolerance logic is designed: Layered consensus: The main chain adopts "PPoR consensus" (PBFT+PoR), authorizing only core operator nodes to participate in global consensus; the sub-chain adopts "PoA consensus", allowing only the scheduling center to generate blocks; edge charging piles only participate in local data verification and do not require full consensus, solving the defect of "low computing power nodes cannot access"; Fault tolerance: When the offline rate of subchain nodes is ≥20% and <40%, it automatically switches to "Simplified PoR consensus"; when the offline rate is ≥40%, it triggers "temporary takeover of the main chain" to ensure that transactions are not interrupted and to solve the defect of "node offline as a service paralysis". Standardized Interface: Design a "Standardized Protocol for Carrier Access" to unify the data format. New carriers only need to complete the interface adaptation.

[0079] 5. Dynamic anonymity and authorized access mechanism: resolving the contradiction between "privacy leakage and lack of traceability". Dynamic Anonymous Identity: A "temporary DID" is generated when a user charges their phone. After the transaction is completed, the user can choose to "keep the record" or "remove the association", thus solving the problem of "permanent anonymity and untraceability". Fine-grained authorized access: Operators can only access anonymized data from a trusted data chain. If they need to obtain user charging preferences, they must submit an application and pay an authorization fee through a smart contract. Users approve in real time, which solves the problem of "overly open data". Anomaly tracing trigger: When an abnormal transaction is detected, the regulatory node can retrieve the temporary association certificate of "anonymous identity-order" with authorization, thus resolving the contradiction between "privacy protection and anomaly tracing".

[0080] Example 2 This embodiment provides a computer terminal, including a memory, a processor, and a computer program stored in the memory and executable on the processor. When the processor executes the computer program, it implements the steps of the blockchain-based cross-carrier charging recommendation and trusted settlement method as described in Embodiment 1.

[0081] like Figure 2 As shown, the computer terminal provided in this embodiment includes: at least one processor 101, and a memory 102 connected to at least one processor 101. This embodiment does not limit the specific connection medium between the processor 101 and the memory 102. Figure 2 The example shown is the connection between processor 101 and memory 102 via bus 100. Bus 100 is... Figure 2 The connections between other components are shown in bold lines and are for illustrative purposes only, not as limiting information. Bus 100 can be divided into address bus, data bus, control bus, etc., for ease of representation. Figure 2 The bus is represented by a single thick line, but this does not indicate that there is only one bus or one type of bus. Alternatively, the processor 101 may also be called a controller; there is no restriction on the name.

[0082] In this embodiment, the memory 102 stores instructions that can be executed by at least one processor 101. The at least one processor 101 can execute the aforementioned method by executing the instructions stored in the memory 102.

[0083] The processor 101 is the control center of the device. It can connect to various parts of the control device through various interfaces and lines. By running or executing instructions stored in memory 102 and calling data stored in memory 102, the processor can perform various functions and process data, thereby monitoring the device as a whole.

[0084] In one possible design, processor 101 may include one or more processing units. Processor 101 may integrate an application processor and a modem processor, wherein the application processor mainly handles the operating system, user interface, and applications, and the modem processor mainly handles wireless communication. It is understood that the modem processor may also not be integrated into processor 101. In some embodiments, processor 101 and memory 102 may be implemented on the same chip; in some embodiments, they may also be implemented on separate chips.

[0085] Processor 101 can be a general-purpose processor, such as a central processing unit (CPU), digital signal processor, application-specific integrated circuit, field-programmable gate array or other programmable logic device, discrete gate or transistor logic device, or discrete hardware component, capable of implementing or executing the methods, steps, and logic block diagrams disclosed in the embodiments. The general-purpose processor can be a microprocessor or any conventional processor. The steps of the blockchain-based cross-carrier charging recommendation and trusted settlement method disclosed in Embodiment 1 can be directly manifested as execution by a hardware processor, or execution by a combination of hardware and software modules in processor 101.

[0086] Memory 102, as a non-volatile computer-readable storage medium, can be used to store non-volatile software programs, non-volatile computer-executable programs, and modules. Memory 102 may include at least one type of storage medium, such as flash memory, hard disk, multimedia card, card-type memory, random access memory (RAM), static random access memory (SRAM), programmable read-only memory (PROM), read-only memory (ROM), electrically erasable programmable read-only memory (EEPROM), magnetic storage, magnetic disk, optical disk, etc. Memory 102 can be any other medium capable of carrying or storing desired program code in the form of instructions or data structures that can be accessed by a computer, but is not limited thereto. In this embodiment, memory 102 can also be a circuit or any other device capable of implementing storage functions for storing program instructions and / or data.

[0087] By designing and programming the processor 101, the code corresponding to the blockchain-based cross-carrier charging recommendation and trusted settlement method described in the foregoing embodiments can be embedded into the chip, enabling the chip to execute it during operation. Figure 1 The steps of the blockchain-based cross-carrier charging recommendation and trusted settlement method are shown. How to design and program the processor 101 is a technique well-known to those skilled in the art and will not be described further here.

[0088] Example 3 This embodiment provides a computer-readable storage medium storing a computer program thereon. When the program is executed by a processor, it implements the steps of the blockchain-based cross-carrier charging recommendation and trusted settlement method as described in Embodiment 1.

[0089] The computer-readable storage medium may include flash memory, hard disk, multimedia card, card-type memory (e.g., SD or DX memory), random access memory (RAM), static random access memory (SRAM), read-only memory (ROM), electrically erasable programmable read-only memory (EEPROM), programmable read-only memory (PROM), magnetic memory, magnetic disk, optical disk, etc. In some embodiments, the storage medium may be an internal storage unit of a computer device, such as the hard disk or memory of the computer device. In other embodiments, the storage medium may also be an external storage device of the computer device, such as a plug-in hard disk, smart memory card, secure digital card, flash memory card, etc., provided on the computer device. Of course, the storage medium may include both internal storage units and external storage devices of the computer device. In this embodiment, the memory is typically used to store the operating system and various application software installed on the computer device. In addition, the memory can also be used to temporarily store various types of data that have been output or will be output.

[0090] The above description is only a preferred embodiment of the present invention, but the scope of protection of the present invention is not limited thereto. Any equivalent substitutions or modifications made by those skilled in the art within the scope of the technology disclosed in the present invention, based on the technical solution and inventive concept of the present invention, should be covered within the scope of protection of the present invention.

Claims

1. A blockchain-based cross-carrier charging recommendation and trusted settlement method, characterized in that, Includes the following steps: S1. Collect node data from multiple operators, verify it using hashes, associate it with cross-chain fields, and generate an initial set of fields for the charging path; S2. Based on the field information in the initial field set of the charging path, calculate the matching degree between user needs and operator permissions, thereby filtering out a set of charging permission paths that meet the requirements; S3. Based on the set of charging permission paths, calculate the recommendation priority coefficient by combining the matching degree, operator node trust degree and billing period span, and generate a list of charging recommendation paths with settlement control fields accordingly; S4. A dynamic multi-count Bloom filter is used to verify the real-time status of the charging recommended path list, and the paths in the list are compared with the blockchain ledger index to filter out unoccupied paths, generating a list of charging recommended settlement paths that can be synchronized. S5. Write the fields in the charging recommended settlement path list into the blockchain ledger according to the payment period segment, verify the consistency of writing between nodes, and generate the final settlement status set.

2. The blockchain-based cross-carrier charging recommendation and trusted settlement method according to claim 1, characterized in that, Step S1 includes the following specific steps: S11. Collect three types of data from N operators: charging pile data, user demand data, and payment data. Based on this, calculate the paired hash value of each data record, i.e., the path field and the billing period field, to obtain the effective set of node billing period paths. The charging pile data includes charging piles ,power Electricity price and the proportion of green electricity User request data includes user anonymity. Required charging amount Distance limit The received data includes the payment period identifier. and settlement cycle The formula for calculating the paired hash value is as follows: In the formula, The paired hash value for the data record; This is the charging path field; For payment period field; The salt value is random. Indicates string concatenation; It is a hash algorithm; S12. For the valid set of node billing period paths, assign sorting numbers according to the order of the path fields in the data, extract the position index of the billing period field in the path field, and calculate the mapping coefficient between the path sorting and the billing period position. Obtain the billing period field order mapping table based on the calculation results. The order mapping table for the payment period field includes the sorting number, the position index, the mapping coefficient, and the grouping identifier; the formula for calculating the mapping coefficient is: In the formula, The mapping coefficient between path sorting and payment period position; Weight the payment period field; For sorting numbering; For location index; S13. Based on the order mapping table of the payment period field, associate the charging pile attribute field with the user demand field, and calculate the cross-chain field correlation degree for each record: In the formula, For cross-chain field correlation; The actual percentage of green electricity This represents the upper limit for the proportion of green electricity. The actual distance between the charging station and the user. This represents the maximum distance between the charging station and the user. To serve actual ratings, The maximum score for service rating; , and These are the correlation weights for green electricity ratio, distance, and service score, respectively. S14. Retain records whose cross-chain field correlation is not less than a set threshold to obtain the initial field set of the charging path, which includes the path field, billing period field, correlation degree and basic attribute field.

3. The blockchain-based cross-carrier charging recommendation and trusted settlement method according to claim 2, characterized in that, Step S2 includes the following specific steps: S21. Extract the user identity field and operator permission field from the basic attribute fields in step S14, align them according to the path segment order, calculate the field position offset, and compare it with a preset offset threshold to obtain the field position pairing result, which includes the aligned valid records and the corresponding field position offset values; wherein, the formula for calculating the field position offset is: In the formula, This is the field position offset; For the location index of the identity field; Index the location of the permission field; This is the offset coefficient; S22. Based on the field position matching results, multiple user requirement dimensions are introduced to calculate the requirement-permission matching degree for each data record and verify whether it meets the standards; the formula for calculating the requirement-permission matching degree is: In the formula, Demand-permission matching degree; , and They are respectively , and The association weight; Based on the degree of matching of basic needs, To match the demand for low carbon, To determine the service demand matching degree, the calculation formulas for the three are as follows: In the formula, To meet user demand for charging capacity; This is the minimum charging capacity for the charging station. To meet user demand for green electricity ratio; Rate services based on user needs; Actual service rating; S23. For data records that meet the matching degree in step S22, calculate the confidence score for permission release and retain the data records with the qualified confidence score to obtain a set of charging permission paths that meet the requirements. This set needs to be confirmed by ≥51% of the consortium blockchain nodes. The charging permission path set includes a path field, a requirement-permission matching degree, and a confidence score for permission release. The formula for calculating the confidence score for permission release is: In the formula, Release confidence for permissions; This represents the number of nodes that passed verification. This represents the total number of nodes participating in the verification.

4. The blockchain-based cross-carrier charging recommendation and trusted settlement method according to claim 3, characterized in that, In step S21, if the field position offset is not higher than the offset threshold, the alignment is effective; otherwise, the field position is adjusted and realigned.

5. The blockchain-based cross-carrier charging recommendation and trusted settlement method according to claim 3, characterized in that, Step S3 includes the following specific steps: S31. Associate the path field and the billing period field in the charging permission path set to calculate the billing period span of the path: In the formula, For the payment period span of the path; and These are the start and end dates of the payment period; S32. Combining matching degree, payment period span, and stage trust degree, calculate the recommendation priority coefficient and priority level for each path; the priority level is divided into three levels: high, medium, and low; the formula for calculating the recommendation priority coefficient is: In the formula, This is the recommendation priority coefficient; This is the maximum payment period. Trust level of operator nodes; , and These are the correlation weights for matching degree, payment period span, and stage trust, respectively. S33. Add settlement control fields according to priority level and calculate the validity of the control fields: reserve The path is determined by excluding duplicate records, resulting in a list of recommended charging paths with control constraints, including priority sorting, control fields, and the validity of the control fields; the hash value of the recommended charging path list needs to be synchronized to the main blockchain.

6. The blockchain-based cross-carrier charging recommendation and trusted settlement method according to claim 5, characterized in that, In step S32, the formula for calculating the operator node trust level is as follows: In the formula, To incorporate dynamic reward and penalty coefficients, adjustments are made dynamically based on the duration of consecutive anomalies, cross-chain verification accuracy, and response latency compliance rate; the formula for calculating the basic trust value is as follows: The basic trust value is calculated using the following formula: In the formula, The number of times to verify consistency for nodes; Total number of node verifications; To delay the number of compliant requests; This represents the total number of node responses. This represents the total number of violations or abnormal behaviors committed by the operator's sub-chain nodes within the trust calculation period. This is a preset threshold for the maximum number of anomalies that a node can accept. , and As weight, .

7. A blockchain-based cross-carrier charging recommendation and trusted settlement method according to claim 5, characterized in that, Step S4 includes the following specific steps: S41. Extract the status field from the charging recommended path list. The status field value is either occupied or unoccupied. A dynamic multi-count Bloom filter is used to verify the real-time performance of the status, calculate the status false negative rate, and retain unused paths with a status false negative rate not exceeding a preset threshold. This results in a path status field information table, which includes status field values ​​and the status false negative rate. The formula for calculating the status false negative rate is as follows: In the formula, The false negative rate is the rate at which the status is not detected. The number of hash functions; Number of status fields; The filter bit length; e It is a natural constant; S42. Read the state field index of the blockchain ledger and calculate the similarity between the current path hash and the index: In the formula, The hash value of the current path; The hash value of the occupied path stored in the status field index; Filter paths with similarity below a preset similarity threshold, partition them by status missing type, and obtain a list of missing path status fields. This list records the number of unused paths and their corresponding similarity. S43. For paths in the missing list of path status fields, append synchronization timestamps and node signatures, and calculate synchronization integrity: In the formula, For synchronization integrity; This represents the number of signature nodes. This represents the total number of nodes. The current time; Paths with synchronization integrity not lower than a preset integrity threshold are considered valid synchronization paths, thus obtaining a list of recommended charging settlement paths that can be synchronized. This list includes synchronization status data and synchronization integrity.

8. A blockchain-based cross-carrier charging recommendation and trusted settlement method according to claim 7, characterized in that, Step S5 includes the following specific steps: S51. Classify the fields in the charging recommended settlement path list into: recommendation fields, settlement fields, or status fields, and assign weights to different categories of fields. This classification process yields a path field classification result table, which includes the field category and its weight. The formula for calculating the field weight is: In the formula, For the first c Weight of class fields For recommended field classes, For settlement field class, For status field class; For the first c Number of class fields; S52. Divide the path into segments according to the billing period representation and calculate the billing period coverage for each path: In the formula, For payment terms coverage; This represents the number of intersections between the path billing period and the segment billing period; This represents the total number of payment periods for each segment; if If the percentage exceeds the set percentage, it will be classified into that segment; each segment includes a set number of paths, thus obtaining the charging settlement period segment division table, which includes segment number and coverage path list; S53. Write the fields classified in step S51 into the blockchain ledger according to the segments divided in step S52, and calculate the consistency of writes among nodes: In the formula, Ensure write consistency between nodes; Write a consistent number of nodes for the field; The total number of objects involved in a specific operation for the charging path; If the value is not less than the set consistency threshold, the write is considered valid. Each field corresponds one-to-one with a segment path. After being written into the blockchain ledger, a block hash value is generated and synchronized to all consortium blockchain nodes to obtain a set of charging recommendation settlement status fields. This set includes the field data of each segment, the consistency of writing between nodes, and the block hash value, serving as the final, tamper-proof record of the blockchain.

9. A computer terminal, comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, characterized in that, When the processor executes the computer program, it implements the steps of a blockchain-based cross-carrier charging recommendation and trusted settlement method as described in any one of claims 1 to 8.

10. A computer-readable storage medium having a computer program stored thereon, characterized in that, When the program is executed by the processor, it implements the steps of a blockchain-based cross-carrier charging recommendation and trusted settlement method as described in any one of claims 1 to 8.

Images