A blockchain-based distributed photovoltaic power transaction system
By using a blockchain-based distributed photovoltaic power trading system, which employs multi-dimensional dynamic trust assessment and marginal pricing mechanisms to match power transactions, the system solves the problems of low transaction efficiency and management difficulties in existing systems, achieves safe, transparent, and fair matching, and improves system efficiency and user benefits.
Patent Information
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- CHINA THREE GORGES NEW ENERGY (GROUP) CO LTD GUIZHOU BRANCH
- Filing Date
- 2026-04-23
- Publication Date
- 2026-07-14
AI Technical Summary
Existing distributed photovoltaic power trading systems lack dynamic matching and credit constraint mechanisms based on the algorithm layer, resulting in low trading efficiency, management difficulties, and a lack of transparency and security, making it difficult to achieve fair matching.
The distributed photovoltaic power trading system based on blockchain achieves secure, transparent, and fair power trading through encryption, trust index calculation, order generation, and dynamic matching modules. It utilizes multi-dimensional dynamic trust assessment and marginal pricing mechanisms for transaction matching, supports diverse payment methods, and enables cross-regional power value exchange through blockchain cross-chain technology.
It has improved the efficiency of the distributed photovoltaic power trading system, enhanced management level, enabled users to complete matching and payment settlement within seconds, significantly improved the return on investment, and promoted the development of the energy internet.
Smart Images

Figure CN122390866A_ABST
Abstract
Description
Technical Field
[0001] This invention relates to the fields of new energy and smart grid technology, and specifically to a blockchain-based distributed photovoltaic power trading system. Background Technology
[0002] With the popularization of distributed photovoltaic (PV) power generation and the development of the energy internet, distributed PV power generation, as an important form of clean energy, is gradually being widely deployed on the user side. More and more users are both consumers and producers of electricity, and a large number of households and industrial and commercial users are achieving self-consumption and grid connection of surplus electricity by installing PV power stations.
[0003] The application of blockchain in electricity trading is mostly limited to the data on-chain level, lacking dynamic matching and credit constraint mechanisms based on the algorithm layer. This makes it difficult to achieve explainable and fair matching, resulting in low efficiency and management difficulties in distributed photovoltaic power trading systems. Summary of the Invention
[0004] This invention provides a blockchain-based distributed photovoltaic power trading system to address the problems of low efficiency and management difficulties caused by the lack of a dynamic matching and credit constraint mechanism based on the algorithm layer, which makes it difficult to achieve interpretable and fair matching.
[0005] In a first aspect, the present invention provides a blockchain-based distributed photovoltaic power trading system, the system comprising: The encryption module is used to acquire raw power data collected by multiple distributed terminals, encrypt the raw power data, and upload the encrypted power data to the blockchain node. The trust index calculation module is used to obtain the power data of the power trading participants in the blockchain node, and to perform multi-dimensional dynamic trust weight calculation on the power data based on the power data of the power trading participants to obtain the trust index value of the power trading participants. The order generation module is used to generate electricity trading orders based on the electricity data of the participating nodes in the electricity trading, and upload the electricity trading orders to the blockchain nodes; The determination module is used to determine the time-sensitive priority and transaction price of electricity trading orders; The dynamic matching module is used to match electricity trading orders based on the trust index value, time-sensitive priority, and transaction price of the participating nodes, generate matching results, and upload the matching results to the blockchain node after signing.
[0006] This invention provides a blockchain-based distributed photovoltaic power trading system. Through blockchain distributed ledger technology, all power data is collected in real-time by smart meters and encrypted and uploaded to blockchain nodes. Once written to a block, it cannot be tampered with. Each transaction is accompanied by a timestamp and hash value, ensuring full traceability. Even if individual nodes are attacked or malfunction, the overall system data remains intact and reliable. Furthermore, the dynamic matching module matches power trading orders based on the trust index value of participating nodes, time-sensitive priority, and transaction price, automatically executing transaction matching and settlement. After a user submits a transaction request, matching and payment settlement can be completed within seconds without manual intervention, improving the efficiency of the distributed photovoltaic power trading system and enhancing its management level.
[0007] In one alternative implementation, the encryption module includes: The data acquisition unit is used to determine the physical current data stream and the account behavior data stream based on the raw power data, and to align the physical current data stream and the account behavior data stream on the time axis to obtain the aligned power data; Edge aggregation unit is used to perform edge aggregation on the aligned power data to obtain reliable time series samples; An anomaly detection unit is used to detect and correct anomalies in reliable time-series samples to obtain reliable electrical energy data. The hash signature processing unit is used to perform hash signature processing on trusted electrical energy data to obtain an identity signature and a hash digest value, and then upload the hash digest value to the blockchain; The regional consensus on-chain unit is used to upload trusted power data, identity signatures, and hash digest values to the blockchain for regional consensus.
[0008] In one optional implementation, the hash signature processing unit includes: The signature verification subunit is used to verify the signature of trusted electrical energy data to obtain an identity signature; The hash calculation subunit is used to perform hash calculations on multiple fields in the trusted power data to obtain a hash digest value, and upload the hash digest value to the blockchain, while storing the trusted power data and identity signature in an off-chain database.
[0009] In one optional implementation, the trust index calculation module includes: The feature extraction unit is used to extract features from the electricity data of the electricity trading participants to obtain feature index values. The trust calculation unit is used to calculate the trust index value of the participating nodes in the power trading based on the feature index value using a weighted linear model.
[0010] In one alternative implementation, the order generation module includes: The order generation unit is used to generate electricity trading orders based on the electricity data of the participating nodes in the electricity trading; wherein, the electricity trading orders include power generation orders and power consumption orders; The order verification unit is used to verify electricity trading orders; The order on-chain unit is used to convert verified electricity trading orders into hashed transaction objects and upload the hashed transaction objects to the on-chain order pool.
[0011] In one optional implementation, the order verification unit is specifically used to perform signature verification, trust threshold verification, and resource verification on electricity trading orders.
[0012] In one alternative implementation, the determining module includes: The time-sensitive priority sorting unit is used to obtain the order waiting time of the power trading orders in the on-chain order pool, and calculate the time-sensitive priority of the power trading orders based on the order waiting time and the trust index value of the power trading participating nodes. The dynamic marginal pricing unit is used to compare the seller's price and the buyer's price of orders in the on-chain order pool. If the seller's price is less than or equal to the buyer's price, the seller's trust score and the buyer's trust score are obtained. The transaction price of the power trading order is calculated based on the seller's price, the buyer's price, the seller's trust score, and the buyer's trust score.
[0013] In one alternative implementation, the dynamic matching module includes: The order filtering unit is used to extract unexecuted transaction orders from the on-chain order pool and prioritize them based on the trust index value of the participating nodes in the power trading, time sensitivity priority, and transaction price. The matching unit is used to match unexecuted orders after priority sorting, generate matching results, and upload the matching results to the blockchain node after signing.
[0014] In one optional implementation, the dynamic matching module further includes: The settlement unit is used to perform energy and fund settlement using smart contracts based on the matching results, generate performance data, update the trust weight based on the performance data, and obtain the updated trust index value.
[0015] In one alternative implementation, it further includes: The smart contract settlement module is used to perform normal performance settlement and default handling using smart contracts after the transaction is matched, generate evidence data, and upload the evidence data to the blockchain node. Attached Figure Description
[0016] To more clearly illustrate the specific embodiments of the present invention or the technical solutions in the prior art, the drawings used in the description of the specific embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are some embodiments of the present invention. For those skilled in the art, other drawings can be obtained from these drawings without creative effort.
[0017] Figure 1 This is a structural block diagram of a blockchain-based distributed photovoltaic power trading system according to an embodiment of the present invention; Figure 2 This is a logical schematic diagram of a distributed photovoltaic power trading matching algorithm based on a multi-dimensional dynamic trust assessment and marginal pricing mechanism according to an embodiment of the present invention. Figure 3 This is a structural block diagram of an encryption module according to an embodiment of the present invention; Figure 4 This is a structural block diagram of a hash signature processing unit according to an embodiment of the present invention; Figure 5 This is a structural block diagram of the trust index calculation module according to an embodiment of the present invention; Figure 6 This is a structural block diagram of an order generation module according to an embodiment of the present invention; Figure 7 This is a structural block diagram of the determining module according to an embodiment of the present invention; Figure 8 This is a structural block diagram of the dynamic matching module according to an embodiment of the present invention. Detailed Implementation
[0018] To make the objectives, technical solutions, and advantages of the embodiments of the present invention clearer, 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, 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.
[0019] It is understood that before using the technical solutions disclosed in the various embodiments of the present invention, users should be informed of the types, scope of use, and usage scenarios of the personal information involved in the present invention and their authorization should be obtained in accordance with relevant laws and regulations through appropriate means.
[0020] The terms "first" and "second" are used for descriptive purposes only and should not be construed as indicating or implying relative importance or implicitly specifying the number of technical features indicated. Thus, a feature defined as "first" or "second" may explicitly or implicitly include one or more of that feature. In the description of this invention, "a plurality of" means two or more, unless otherwise explicitly specified.
[0021] The existing power trading system relies on centralized grid dispatch and power company settlement, which leads to the following technical and management problems in the current energy recovery and trading mechanism: 1) Low efficiency of surplus electricity recovery: At present, most regions adopt the "grid-connected electricity price" or "subsidy policy" model. Users' surplus electricity needs to be recovered to the grid and purchased and settled by the power company. Due to the cumbersome settlement process and fixed electricity price, it is difficult to maximize the benefits on the user side, and the efficiency of surplus electricity utilization is not high.
[0022] 2) Lack of transparency and security in the transaction process: The surplus power generation of distributed photovoltaic users needs to be matched through a centralized platform. Users cannot verify the authenticity of the transaction data in real time, which can easily lead to problems such as data tampering, information asymmetry and unfair distribution of benefits. At the same time, the data transmission and approval cycle is long, making it impossible to achieve real-time transactions.
[0023] 3) High pressure on grid dispatch: Distributed photovoltaic power output is volatile and random, and large-scale integration places higher demands on grid dispatch and stability. If a flexible power trading mechanism cannot be established, the grid is prone to uneven dispatch and curtailment of solar power during peak hours.
[0024] 4) Lack of flexible market mechanisms: Transaction pricing is usually based on fixed feed-in tariffs or peak-valley tariffs, lacking flexible market feedback mechanisms and failing to reflect supply and demand dynamics and credit differences. The lack of direct electricity trading methods among users hinders point-to-point energy sharing between neighbors, communities, or regions, impeding the formation of the energy internet and new electricity markets.
[0025] 5) Lack of transparency in node reputation: There is a lack of effective user credit measurement standards, and malicious nodes can disrupt market order through false orders and defaulted delivery.
[0026] 6) Limitations of blockchain applications: Although blockchain has been applied in electricity trading, it is mostly limited to the "data on-chain" level and lacks a "dynamic matching and credit constraint" mechanism based on the algorithm layer, making it difficult to achieve interpretable and fair matching.
[0027] Therefore, there is an urgent need for a decentralized electricity trading system that can ensure the security and transparency of electricity trading while enabling distributed users to participate autonomously, so as to promote the efficient utilization of distributed photovoltaic power generation.
[0028] This invention provides a blockchain-based distributed photovoltaic power trading system. Through a distributed photovoltaic power trading matching algorithm based on a multi-dimensional dynamic trust assessment and marginal pricing mechanism, by introducing trust weights, dynamic marginal pricing functions, and time priority queues, it realizes intelligent matching of point-to-point power trading and credit-driven price adjustment, thereby improving the system's credibility and economic benefits.
[0029] In addition, this system supports diversified payment and cross-regional settlement. The relevant transaction modes generally only support local power grid clearing, and cross-regional power trading is difficult to realize. Therefore, this system supports three settlement methods: digital currency, energy points and fiat currency account binding. It can also realize cross-regional power value interoperability through blockchain cross-chain technology. Users can not only use energy points to offset electricity bills, but also circulate distributed photovoltaic power as assets on a larger scale, expanding the clearing methods and transaction scenarios.
[0030] Since power trading systems are often centralized, they are difficult to flexibly cope with the rapid development of distributed energy. Therefore, the embodiments of this invention adopt a modular design, which can be extended to multiple energy trading scenarios such as wind power, energy storage, and electric vehicle charging piles. At the same time, it supports cross-regional power trading and dynamic electricity price models, adapting to the diversified energy market demands of the future. It not only solves the problem of distributed photovoltaic trading, but also provides a feasible path for building a larger-scale multi-energy collaborative trading platform. The system has strong scalability and adaptability.
[0031] This embodiment also provides a blockchain-based distributed photovoltaic power trading system. As used below, the term "module" can refer to a combination of software and / or hardware that performs a predetermined function. Although the system described in the following embodiments is preferably implemented in software, hardware implementation, or a combination of software and hardware, is also possible and contemplated.
[0032] This embodiment provides a blockchain-based distributed photovoltaic power trading system, such as... Figure 1 As shown, it includes: The encryption module 101 is used to acquire raw power data collected by multiple distributed terminals, encrypt the raw power data, and upload the encrypted power data to the blockchain node.
[0033] Specifically, such as Figure 2As shown, the encryption module is the data entry point of the entire system. Its core objectives are: to ensure the authenticity and timeliness of transaction data; to clean and compress data before it is uploaded to the chain, thereby reducing the load on the main chain; and to form a traceable and verifiable energy behavior data base, providing high-quality input for subsequent trust assessment and intelligent matching algorithms. Therefore, the encryption module 101 is not simply "uploading data", but a distributed data trust generation algorithm that includes four layers of logic: collection, aggregation, verification, and uploading to the chain. The logical connections and objectives of this algorithm are shown in Table 1 below.
[0034] Table 1:
[0035] Furthermore, power data is continuously collected from multiple distributed terminals (such as photovoltaic inverters, smart meters, and energy storage monitors). The collected power data (used for basic trust modeling) includes node historical transaction behavior, default records, price deviations, performance status, basic identity information, and device registration information. The above data is relatively static and is used for historical trust, identity verification, and long-term reputation building.
[0036] The trust index calculation module 102 is used to obtain the power data of the power trading participants in the blockchain node, and to perform multi-dimensional dynamic trust weight calculation on the power data based on the power data of the power trading participants to obtain the trust index value of the power trading participants.
[0037] Specifically, the goal of the trust index calculation module 102 is to integrate the historical behavior and real-time performance of each participating node (power generator, power consumer, energy storage, or intermediary transaction party) into a dynamically variable trust index. Its overall strategy is: extract several interpretable features from multi-source data → standardize and fuse them → derive a single trust index → put it on the blockchain and use it during matching; at the same time, it realizes dynamic adaptive updating of scores and interpretability support. The structural description of the trust index calculation module 102 is shown in Table 2 below.
[0038] Table 2:
[0039] Furthermore, the electricity data of the participating nodes in the electricity trading within the blockchain includes: the daily power generation curve uploaded by the power generation node (seller). Predicted power generation Actual transaction volume And a default flag (if present), uploaded by the electricity node (buyer). Actual electricity consumption and payment records, fund account status, as well as authentication status and historical credit scores provided by regulatory nodes. And default statistics.
[0040] Furthermore, the Seller node is responsible for submitting seller orders, uploading real-time power generation data, and participating in settlement and contract execution; the Buyer node is responsible for submitting buyer orders, uploading load / demand data, and participating in settlement; the Regulator node is the blockchain's audit node, with "read-only + query" permissions, does not participate in matching, but can access on-chain summaries and off-chain evidence indexes for compliance supervision and anomaly arbitration.
[0041] Furthermore, the collected electricity data (used for dynamic trust weight calculation) of the electricity trading participants in the blockchain nodes includes: real-time power, actual transaction electricity, real-time load, energy storage status, line loss, time series consistency, physical model deviation, and actual delivery status. The data is biased towards real-time and is used for physical performance, immediate behavior, and dynamic status assessment.
[0042] The order generation module 103 is used to generate electricity trading orders based on the electricity data of the electricity trading participating nodes, and upload the electricity trading orders to the blockchain nodes.
[0043] Specifically, the core task of the order generation module 103 is to transform the supply and demand intentions of market participants (power generators, power consumers, and energy storage providers) after trust calculation into verifiable and standardized order data structures, and to realize the legality verification, trust filtering, and on-chain registration of orders through algorithmic processes.
[0044] The determination module 104 is used to determine the time-sensitive priority and transaction price of electricity trading orders.
[0045] The dynamic matching module 105 is used to match electricity trading orders based on the trust index value, time-sensitive priority and transaction price of the participating nodes in the electricity trading, generate matching results, and upload the matching results to the blockchain node after signing.
[0046] Specifically, after order verification and priority sorting, a closed loop of automatic matching, transaction confirmation, energy settlement, and credit feedback between buyers and sellers is achieved.
[0047] Furthermore, the matching trigger conditions include: periodic matching: the system scans the order pool and performs matching at fixed intervals; event matching: automatically triggered when a new order enters or when price fluctuations exceed a threshold; the above two modes can coexist to ensure real-time market responsiveness and transaction continuity.
[0048] Furthermore, the output data of the blockchain-based distributed photovoltaic power trading system includes: 1) Transaction Volume Statistics (by Hour / User): By Hour: Statistics on total transaction volume (unit: kWh) and number of orders across the network, forming a time-transaction activity curve; By User: Records the cumulative transaction volume, transaction frequency, and fulfillment rate for each node; Data is automatically uploaded to the blockchain and hashed via smart contracts to ensure immutability. The visualization interface can output to the operations and maintenance console or monitoring nodes to achieve transaction activity monitoring and trend prediction.
[0049] 2) Average transaction price: Summarize the transaction prices of each period, calculate the weighted average price, and output the maximum and minimum price fluctuation range and median value to improve the rationality of price analysis at market supervision nodes; if the price fluctuation exceeds the set threshold, a price fluctuation warning will be automatically triggered and the matching parameters will be adjusted.
[0050] 3) Trust distribution: The latest trust values of all participating nodes are statistically distributed across intervals to generate a node reputation heatmap, reflecting the overall credit health of the system. If the proportion of low-trust nodes rises above the threshold, the system will automatically raise the entry threshold or adjust the margin ratio.
[0051] 4) Default Alert: The smart contract monitors the order fulfillment status in real time and triggers an alert when any of the following situations occur: the actual delivered electricity is more than 10% lower than the agreed value; payment timeout or insufficient balance; or the trust level drops by more than [a certain percentage] in a short period of time. T threshold; default events are automatically marked and reported to the regulatory node, and are also written into the node's reputation file, affecting subsequent trust assessments.
[0052] Furthermore, such as Figure 2 As shown, to ensure the efficient and secure operation of the blockchain photovoltaic power trading platform, the following key monitoring indicators are defined and tracked in real time through on-chain statistical intelligent agents: 1) Matching latency: Defined as the time difference between order submission and confirmation of the matching result; the implementation mechanism is: using a distributed matching queue and memory caching mechanism, when the load is too high, the system automatically enables parallel matching threads to ensure real-time response. When the latency exceeds the limit, the node calculation weight is automatically adjusted and a performance alarm is triggered.
[0053] 2) Success rate: defined as the number of orders successfully matched and settled / the total number of valid orders; the implementation mechanism is: reducing "empty orders" and failed matches through trust screening and resource verification mechanisms; the statistics module calculates the success rate every hour and outputs a trend curve; if the success rate continues to decline, an automatic diagnostic program is triggered to locate algorithm bottlenecks or abnormal nodes.
[0054] 3) Abnormal Order Ratio: Defined as the number of orders marked as abnormal (e.g., false reporting, duplicate signatures, frequent submissions) divided by the total number of orders. The detection logic combines a frequency detection algorithm with a signature duplication verification mechanism to identify high-risk orders in real time. If the abnormal ratio exceeds the threshold, the system immediately freezes suspicious nodes and notifies operations and maintenance personnel. Simultaneously, the abnormal pattern characteristics are input into the trust model for retraining to improve the system's defense capabilities.
[0055] This invention provides a blockchain-based distributed photovoltaic power trading system. Traditional power trading systems typically rely on power grid companies or centralized platforms for data aggregation and clearing, which suffers from centralized data management, single points of failure, and potential tampering risks. Users often struggle to independently verify the authenticity of transaction data, easily leading to disputes. Therefore, through blockchain distributed ledger technology, all power data is collected in real-time by smart meters and encrypted and uploaded to blockchain nodes. Once written to a block, it is immutable. Each transaction is accompanied by a timestamp and hash value, ensuring full traceability. Even if individual nodes are attacked or malfunction, the overall system data remains intact and reliable. In other models, discrepancies in accounts or settlement delays may occur. This invention ensures the authenticity and uniqueness of transaction data, preventing human tampering and accounting disputes, achieving data trustworthiness and tamper-proofing, and guaranteeing fair transactions. Furthermore, it enhances the distributed... Photovoltaic User Benefits: In the relevant power system, surplus electricity from small and medium-sized distributed photovoltaic power plants often faces problems such as low electricity prices and high trading thresholds, resulting in long investment return cycles for users. Therefore, through a point-to-point trading mechanism, users can directly sell surplus electricity to neighboring users or enterprises, reducing intermediate links and obtaining higher electricity price benefits. According to simulation experiments, the average selling price of surplus electricity from photovoltaic users under this system can be 15-30% higher than the traditional grid-connected electricity price, significantly improving the return on investment and accelerating the popularization of photovoltaics. In addition, since regulatory agencies rely heavily on data reports from grid companies for the review of distributed power transactions, there are lags and incompleteness. Therefore, by making all transaction records open and verifiable through a blockchain ledger, regulatory agencies can monitor transaction volume, electricity price fluctuations, and market compliance in real time, significantly reducing manual auditing costs, improving the transparency and timeliness of power market supervision, and promoting the standardized development of green energy trading.
[0056] In some alternative implementations, such as Figure 3 As shown, the encryption module 101 includes: The acquisition unit 1011 is used to determine the physical current data stream and the account behavior data stream based on the raw power data, and to align the physical current data stream and the account behavior data stream on the time axis to obtain the aligned power data.
[0057] Specifically, a dual-channel input stream is set up at the acquisition layer: one is the physical current data stream (real-time voltage, current power), and the other is the account behavior data stream (transaction records, fund flow, reputation behavior). The two are compared synchronously on the time axis, so that the system not only knows how much electricity has been generated, but also verifies whether the electricity has actually entered the market transaction process. This dual-stream aligned acquisition logic is the key foundation for subsequent anti-counterfeiting and trust calculation.
[0058] Furthermore, in the dual-channel input structure, the power data is distinguished based on a four-tier mechanism: device physical ID, data structure differences, protocol tags, and stream processing partitioning, ensuring automatic stream homing and stable reliability. The core implementation is as follows: 1) Terminal physical ID as source identifier: Each physical device (inverter, meter, energy storage device) has a globally unique identifier, such as: Meter-ID (meter number); Inverter-ID (inverter number); ESS-ID (energy storage system number). These IDs are used to identify whether the data belongs to the physical current data stream.
[0059] 2) The data structure inherently distinguishes between two streams: Different structures are defined for the two types of data at the acquisition protocol layer: physical data stream fields, such as voltage, current, active power, reactive power, and whether the sampling frequency is stable (e.g., every 1 second or 100 ms); and behavioral data stream fields, such as account address (Wallet Address), order ID, matching timestamp, and fund transfer records. The two types of data structures have completely different characteristics, therefore the parser can automatically classify the streams without complex judgment.
[0060] 3) Communication protocol layer tags: In the data acquisition gateway, each data item is automatically labeled with a tag field: channel=Physical → physical current data stream; channel=Behavioral → account behavior data stream. The above tags are written directly on the edge side (such as the data collector) to ensure that the data is correctly classified before it arrives at the platform.
[0061] 4) The stream processing framework establishes independent topics: separate topics are created for each type of data: topic_physical_stream and topic_behavior_stream. Through the above structured stream splitting, the data will never be confused.
[0062] Furthermore, synchronizing and comparing the physical current data stream and the account behavior data stream on the time axis includes: 1) Timestamp unification: Before data collection, all devices perform the following: the terminal synchronizes with the NTP (Network Time Protocol) or GPS (Global Positioning System) time source, and all data packets are given a unified format timestamp to ensure that the backend data can be sorted by time.
[0063] 2) Physical current data is sliced into fixed windows: one time segment is generated every 1 second. Current, voltage, active power, reactive power, and the actual power generation ∑(P_actual × Δt) is broken down into each time period.
[0064] 3) Mapping behavioral data streams to the timeline: Placing transaction behaviors on the same timeline, including order creation time, order completion time, settlement time, and fund freeze time.
[0065] 4) Establish matching rules (core step): Perform a matching check once in each time window, including: Matching electricity volume: Check that the physical power generation during this period = the power generation declared in the transaction ± the allowable deviation. If there is no match, mark it as a risk of false electricity volume; Matching activity (P value): Set a certain correlation between the physical layer activity P (power generation fluctuation intensity) and the behavioral layer activity (transaction frequency). If the device's physical activity is high (power generation changes frequently) but the behavioral flow has no transaction action, mark it as suspected power hoarding or skipping the transaction link; Verify the order of behavior: including but not limited to: whether physical electricity volume is generated before the order is placed, whether there is no physical power generation during the order transaction period, and whether there is a situation of "no light at night but power generation transaction". All of the above are judged by the synchronized timeline.
[0066] 5) Output synchronous comparison results: Output the following indicators: whether it matches, deviation ratio, anomaly type (physical false / behavioral false / time misalignment, etc.), and the basis for recalculating the trust score.
[0067] 6) Provide trusted power generation proof to the upper layer: used for trust scoring, risk warning, risk transaction shielding, and smart contract execution basis.
[0068] Edge aggregation unit 1012 is used to perform edge aggregation on the aligned power data to obtain a reliable time series sample.
[0069] Specifically, since the sampling frequency of distributed terminal devices is high, directly uploading them to the chain would cause chain load and redundant information. Therefore, the algorithm designed an edge aggregation mechanism, where each regional node temporarily stores multiple data records for a short period of time locally and forms a data packet through a sliding time window.
[0070] Furthermore, the aggregation logic for edge aggregation of aligned power data includes consistency judgment, time alignment mechanism, and spatial correlation filtering.
[0071] Furthermore, consistency judgment: power data from different sources (meters, inverters, storage units) at the same time are cross-compared, and only those differences within a threshold range are considered valid. Before cross-comparing power data from different sources at the same time, the data from different sources needs to be processed. The general approach is to unify units → calibration / normalization → semantic verification → confidence-weighted comparison. Specific steps include: Unifying the unit system: all energy / power data are uniformly converted to the same basic unit (e.g., power in W or kW, energy in Wh or kWh) when entering the database, and each data entry carries the original unit and conversion factor for traceability; Equipment calibration and range mapping: for different types of equipment (meters, inverters, storage units)... Establish range and accuracy profiles for meters / inverters / energy storage converters, and assign confidence weights to data according to equipment accuracy; Time window and integration alignment: Short-time high-frequency power values are integrated over time to obtain energy, so as to directly compare with the power consumption reported at low frequencies or declared in orders (power and energy conversion: energy = power × time); Physical quantity semantic check: Check whether the semantics of fields match (e.g., "output power" cannot be mixed with "input active power"). If the semantics are inconsistent, direct comparison is rejected and data cleaning is triggered; Confidence-weighted fusion: When comparing, the differences are weighted according to the source confidence (equipment accuracy, reporting frequency, signature integrity) to weaken the impact of low-confidence source comparison on the results.
[0072] Furthermore, cross-referencing power data from different sources at the same time involves aligning two types of heterogeneous frequency data to the same time base, performing in-window comparisons, and outputting a consistency metric. The specific steps include: 1) Time standardization: Ensure that all records have a uniform timestamp (using the time network protocol UTC / NTP), with errors within the allowable range.
[0073] 2) Define alignment window: Select the length of the sliding or scrolling window (e.g., 1s, 5s, 30s, 1min, determined by business needs), slice the physical flow, and perform time mapping on the behavior flow (mapping order creation / completion to the corresponding time window).
[0074] 3) Power to Energy Mapping: Integrating the physical power sequence within each time window yields the energy within that window. (1) The energy within the window is compared with the transaction volume corresponding to that window in the behavior flow. Compare.
[0075] 4) Alignment comparison rules: Calculate the deviation rate, the formula of which is as follows: (2) If the deviation rate is lower than the defined threshold and the two times overlap, it is considered a match; otherwise, it is marked as an anomaly.
[0076] 5) Multi-source consistency verification: If there are multiple physical sources (electricity meter, inverter, energy storage converter) in the same window, perform internal aggregation (weighted average according to confidence level) at the physical layer first, and then compare it with the behavior flow.
[0077] 6) Output consistency score: Output a consistency score (0-1) for each time window, as well as anomaly labels (time misalignment, power deviation, no behavior, etc.).
[0078] 7) Triggering action: Consistency below the threshold triggers risk control (freezing orders / manual verification / recording evidence hash).
[0079] Furthermore, the time alignment mechanism ensures a constant interval between sampling points through timestamp synchronization, facilitating subsequent prediction and modeling. Specific steps for timestamp synchronization include: Unified time protocol: All edge devices / gateways should use a unified time service, prioritizing devices with hardware GPS time alignment; Local calibration: Devices perform time calibration upon startup / periodically (e.g., daily) and record calibration history and deviations; Time signature: Reported data should include two time fields: the device's local timestamp and the gateway's received timestamp (gateway time calibrated by NTP / GPS), used to detect network latency and device drift; Fault tolerance window: The backend sets an acceptable time deviation threshold (±1s); exceeding this threshold marks the device as a time anomaly and handles it in tiers (compensation / discard / manual processing); Time drift compensation: If continuous device drift (accumulated deviation) is detected, remote synchronization or maintenance intervention for replacement / recalibration is triggered; Time traceability record: Each data record saves time synchronization metadata (synchronization source, synchronization delay, calibration time) for easy traceability.
[0080] Furthermore, spatial correlation filtering: Geographically related nodes are clustered using device regional tags (such as GPS or transformer node IDs) to prevent data from remote devices from being mistakenly mixed into local transaction areas. This involves obtaining geographical / grid proximity relationships through two paths: device registration information and network topology mapping. This includes: reporting geographical tags during device registration: writing GPS coordinates, site ID, transformer ID, distribution box ID, and other metadata when the device leaves the factory or is installed; grid topology mapping: obtaining the relationship between the transformer, feeder, and distribution area of the node (grid-side proximity) through wiring diagrams or operation and maintenance databases; near-field network information: determining physical proximity through gateway / MAC (Media Access Control) / IP (Internet Protocol) geographical information or the same gateway / PLC bus connection; dynamic verification: verifying geographical / grid proximity through statistical historical data similarity (voltage / power fluctuation synchronization); and unified tag storage: writing geographical / grid tags into device metadata and uploading them to a hash index on the blockchain for easy clustering and auditing.
[0081] Furthermore, the specific steps for clustering geographically related nodes using device area tags include: Preparing elements: Each device should have at least one area tag: GPS coordinates / transformer ID / distribution box ID / cell ID; Selecting cluster granularity: Determining the cluster radius or logical boundaries of clusters based on transformers / feeders (e.g., the same transformer is considered as one cluster); Clustering algorithm: If based on coordinates: Using spatial clustering (e.g., distance-based clustering, or density-based clustering algorithms like DBSCAN or simple radius search for indicative clustering) to group geographically adjacent devices together; If based on power grid topology: Directly grouping by transformer ID / feeder ID (strong consistency); A combination of both can be used (first dividing by transformer, then further subdividing within the group); Generating node group information: Generating a group ID for each cluster and recording the device list and group-level confidence (based on device online rate and data consistency history); Group-level aggregation and verification: Performing data aggregation, anomaly detection, and on-chain signature on edge nodes at the group level to reduce on-chain frequency and improve local consistency judgment capability; Dynamic adjustment: Periodically recalculating clusters (e.g., daily) to cope with device migration or topology changes.
[0082] Furthermore, edge aggregation of the aligned power data is essentially a distributed data consistency and clustering algorithm, ensuring that even with asynchronous acquisition by multiple nodes, structured "trustworthy time-series samples" can still be obtained.
[0083] The anomaly detection unit 1013 is used to perform anomaly detection and anomaly correction on the reliable time series samples to obtain reliable electrical energy data.
[0084] Specifically, before the data is uploaded to the blockchain, the algorithm performs three layers of anomaly detection: physical consistency detection, temporal continuity detection, and behavioral pattern detection.
[0085] Furthermore, physical consistency detection: The power conservation model is used to determine whether the input power, output power, and energy storage status are balanced. If the deviation exceeds the limit, it is marked as abnormal. The construction process of the power conservation model is as follows: Define the monitoring boundary (single meter / site / transformer area); determine the ports to be sampled (generation end, load end, grid connection end, energy storage end); establish a loss estimation model (using empirical coefficients or calculations based on resistance / current); select a time window and use integration / differential methods to calculate the energy balance.
[0086] Furthermore, within any time window [t, t+ Within t], the expression for the power conservation model is: (3) in, Indicates the output power of local power generation (photovoltaics). Indicates the external network / grid-connected input power. Indicates local load power. Indicates the power transmitted / connected to the internet. This indicates the loss (estimated or measured) of lines and equipment. This indicates the net charge / discharge power of the energy storage system (positive for charging, negative for discharging).
[0087] Furthermore, the specific steps for determining whether the input power, output power, and energy storage state are in balance using the power conservation model include: sampling and unit conversion: normalizing the power readings on each side of the boundary to the same unit and integrating them over a time window to obtain the energy value; calculating the theoretical balance term; and error measurement: calculating the relative error or residual rate. Judgment rule: If ≤Preset threshold → Balanced; Otherwise → Mark as physically inconsistent and abnormal; In-depth diagnosis: If unbalanced, check each item in order of priority (check energy storage readings, check grid connection port, check equipment failure or data loss), and determine responsibility based on source confidence (whether it is measurement error, communication delay, equipment failure or malicious tampering); Recording and traceability: Hash the balance check results and the original readings on the chain or store evidence on the chain for arbitration.
[0088] Furthermore, temporal continuity detection: This checks for time jumps or duplicate values in the sampled sequence to prevent forgery or tampering of interpolation. Specific steps include: Time interval consistency: Defining the expected sampling interval. If the time difference of a certain record and If the difference is too large (exceeding the threshold) or is 0, it is considered a jump or repetition; repetition value judgment: if the values are exactly the same in several consecutive sampling points and the equipment characteristics do not support a constant output for a long time (such as photovoltaics should not be constant in the short term), it is judged as repeated or sticky sampling; at the same time, compare whether the sampling timestamp is repeated; sequence integrity check: use the incrementing sequence number or the sequence number reported by the device to detect whether there is a backtracking or repeated reporting; statistical detection: calculate the variance and mean of the sequence difference, if there is an abnormal peak or a sudden change in variance, it is judged as a time jump or sampling abnormality.
[0089] Furthermore, behavioral pattern detection: The deviation of current data is calculated using the distribution of historical user data (such as the average power generation curve) to determine if there are any sudden anomalies, such as "falsely reporting high power generation" or "malicious power outages." The criteria for determining whether there are sudden anomalies are: Instantaneous mutation rule: A sampling point value deviates from the mean within a window by more than N times the standard deviation (e.g., z-score > 3) or exceeds a relative threshold (e.g., > ± 30%), then it is marked as a sudden anomaly; Continuous anomaly pattern: Multiple consecutive windows showing deviations exceeding the threshold within a short period indicate a systemic problem rather than isolated noise; Physical inconsistency: Physically impossible situations such as high output from the solar inverter at night or negative load; Cross-source contradiction: Within the same time window, readings from the inverter, meter, and transformer contradict each other (exceeding the confidence weighted allowable range); Behavioral anomaly correlation: A large number of abnormal orders / cancellations are displayed in the behavioral flow, and physical flow anomalies occur simultaneously, suggesting possible malicious activity or system interlocking failures.
[0090] Furthermore, after detection, abnormal data is automatically filtered or corrected to ensure the statistical stability of the on-chain information. This preprocessing logic is essentially a lightweight anomaly detection algorithm integration layer that achieves data credibility correction without relying on manual intervention. Among them, physical anomalies are given priority for physical correction (calibration / reissue / interpolation); time anomalies are given priority for time reconstruction and resampling; and behavioral anomalies are given priority for risk control and auditing (processed through contracts and arbitration).
[0091] Furthermore, if there is an abnormality in power conservation / energy deviation (i.e., physical inconsistency), the handling strategy is as follows: Short-term correction: If there is only a small deviation and some sources are missing, use confidence-weighted fusion to compensate for the missing values with other high-confidence sources or use linear interpolation / estimates based on historical peers as temporary substitutes; Loss / measurement correction: Apply loss model adjustment (add estimated line losses); If it is an instrument deviation, use the most recent calibration factor for correction; Rollback and resampling: Request the equipment to retransmit the original high-frequency data or restore the original samples from the edge cache and recalculate; Manual / arbitration: If the deviation is significant and affects settlement, freeze the relevant transactions and submit them for manual review / arbitration.
[0092] Furthermore, if there are jumps / repetitions / sequence rollbacks (i.e., time continuity anomalies), the handling strategy is as follows: Time reconstruction: If it is a slight drift, the device time is remapped and reordered using the gateway timestamp, and duplicate samples are deduplicated while retaining the received time order; Interpolation / resampling: Short-term missing points are recovered using interpolation (linear or spline), and duplicate points are recovered using the most reliable source data and low-confidence duplicates are discarded; Resend mechanism: Request the device to resend the original log; If the device cannot resend, estimate based on historical similar patterns and mark with uncertainty; Device maintenance: If frequent time anomalies are detected in the device, trigger on-site calibration or replacement by maintenance personnel.
[0093] Furthermore, if there are any abnormalities such as false reporting, abnormal order placement, or frequent order cancellations (i.e., abnormal behavior patterns), the handling strategy is as follows: Risk control strategy: immediately downgrade the trust value of the abnormal account, increase the margin, or temporarily prohibit order placement; Behavior playback and comparison: compare the behavior flow with the physical flow. If the behavior and physical flow do not match, mark it as malicious and report it to the regulator; Statistical correction: remove or reduce the weight of data points with short-term abnormal behavior in the statistical report without affecting the overall statistics; Accountability and arbitration: serious cases will enter the arbitration process and deduct the margin according to the contract.
[0094] The hash signature processing unit 1014 is used to perform hash signature processing on trusted electrical energy data to obtain an identity signature and a hash digest value, and then upload the hash digest value to the blockchain.
[0095] Specifically, the signature layer (identity authentication) ensures that the uploading node is indeed a legitimate device by verifying the uniqueness of its identity through the private key signature of each meter.
[0096] The regional consensus on-chain unit 1015 is used to upload trusted power data, identity signatures, and hash digest values to the regional consensus on-chain.
[0097] Specifically, the hash digest layer (data integrity) performs hash calculations on multiple fields (timestamp, battery level, node ID, etc.) to generate an irreversible digital fingerprint (i.e., hash digest value). Only the hash digest value is stored on the blockchain, while the original data is kept locally or in an off-chain database.
[0098] Furthermore, after the power data is encrypted and digested, the edge node initiates an on-chain broadcast request. A multi-node confirmation mechanism is adopted, that is, at least multiple neighboring nodes simultaneously verify the hash consistency, and the data digest is officially packaged into the block only after a local consensus is reached.
[0099] This invention provides a blockchain-based distributed photovoltaic power trading system that implements a hybrid storage mode of on-chain indexes and off-chain data. This includes blockchain records for credibility proofs and off-chain storage of complete data for supervision and analysis. This not only improves system operating efficiency but also makes energy data auditing traceable. Furthermore, it reduces the traditional network-wide consensus to regional consensus, significantly reducing on-chain latency while maintaining data credibility. This two-level on-chain logic of regional consensus and network-wide confirmation allows the system to meet real-time trading needs while also ensuring security and tamper resistance.
[0100] In some alternative implementations, such as Figure 4 As shown, the hash signature processing unit 1014 includes: The signature verification subunit 10141 is used to perform signature verification on trusted electrical energy data to obtain an identity signature.
[0101] The hash calculation subunit 10142 is used to perform hash calculations on multiple fields in the trusted power data to obtain a hash digest value, and upload the hash digest value to the blockchain, while storing the trusted power data and identity signature in an off-chain database.
[0102] This invention provides a blockchain-based distributed photovoltaic power trading system. Since the relevant power trading data is centrally stored in the power grid database, it is susceptible to risks such as hacker attacks, internal leaks, and data misuse. Therefore, the transaction data is secured through distributed storage and encryption algorithms. User privacy information is protected using technologies such as zero-knowledge proofs and homomorphic encryption. Only the transaction results are made public, while private data is not disclosed. Contract execution utilizes a multi-signature mechanism to prevent unilateral malicious operations, effectively preventing data leakage and identity theft. This ensures a balance between transparency and privacy in user power generation and consumption data, enhancing both security and privacy protection.
[0103] In some alternative implementations, such as Figure 5 As shown, the trust index calculation module 102 includes: The feature extraction unit 1021 is used to extract features from the electricity data of the electricity trading participants to obtain feature index values.
[0104] Specifically, the raw data (i.e., the electricity data of the participating nodes in the electricity trading) is mapped into several key interpretable indicators (features). Each feature represents a dimension of reputation, including: Performance accuracy dimension: comparing the gap between promised delivery and actual delivery to highlight whether there are short-term or long-term delivery behaviors; Stability dimension: measuring the time-series volatility and prediction deviation of power generation / supply, reflecting the system's stable operation capability; Compliance / Credit dimension: credit marks from regulators or certifications, historical violation records, etc., reflecting compliance and third-party recognition; Activity / Participation dimension: the frequency and volume of participation in transactions in the recent period, characterizing the growth trend of market participation and credibility; Dispute / Complaint dimension: the number of historical disputes, arbitration results, etc., as negative reputation factors.
[0105] The fulfillment rate (ratio of traded volume to committed volume) is calculated based on historical transaction records and updated daily. The calculation formula is as follows: (4) in, Indicates the amount committed.
[0106] The power consumption deviation is calculated based on data collected by smart meters and updated hourly. The calculation formula is as follows: (5) Credit scores are obtained through regulatory nodes. (Certified by regulatory authorities), and updated weekly.
[0107] Activity level (number of recent transactions per day) is calculated from blockchain transaction logs and updated in real time. The calculation formula is as follows: (6) in, This indicates the number of transactions completed in the last seven days. Indicates the reference standard.
[0108] Trust calculation unit 1022 is used to calculate the trust index value of the participating nodes in power trading based on the feature index value using a weighted linear model.
[0109] Specifically, the trust calculation unit uses an interpretable fusion function to combine various indicators into a scalar trust value. The design of the fusion function follows two principles: interpretability: the fused trust value should be decomposed back into the indicator that contributes the most, which is convenient for auditing and arbitration; flexibility and fairness: avoid extreme judgments caused by the abnormality of a single indicator (for example, a small default will not immediately reduce the trust to the minimum), and allow positive and negative factors to jointly affect the result.
[0110] Furthermore, each node user Trust index value Calculated dynamically using the following formula: + + (7) in, This indicates the credibility weight of transaction fulfillment. Its measurement criteria are whether the node fulfills the contract on time, whether the order is deliberately misrepresented, and whether the deviation from historical reputation is significant. It is used to reflect credibility at the behavioral level. The physical consistency weight is measured by whether the measured power curve is stable, whether the physical power is consistent with the quoted price, and whether there are false power generation / false load reports. It is used to reflect the credibility of the "equipment and power physical layer". This indicates the data credibility weight, which is measured by whether the data sampling is continuous; whether there are jumps, duplicates, missing data, and whether the data has been tampered with. It is used to reflect the credibility of the "reported data quality". The geographic-topology consistency weight is measured by whether the node's location in the distribution network topology is reasonable, whether the node's energy flow is consistent with the status of surrounding nodes, and whether "topology incompatible behavior" (such as fictitious nodes) occurs. It is used to reflect the credibility of the "grid topology level".
[0111] Furthermore, the threshold determination and label generation are shown in Table 3 below.
[0112] Table 3:
[0113] The present invention provides a distributed photovoltaic power trading system based on blockchain, which integrates various characteristic index values into a scalar trust value, avoiding extreme judgments caused by the abnormality of a single index, and laying the foundation for subsequent transaction order matching.
[0114] In some alternative implementations, such as Figure 6 As shown, the order generation module 103 includes: The order generation unit 1031 is used to generate electricity trading orders based on the electricity data of the electricity trading participating nodes; wherein, the electricity trading orders include power generation orders and electricity consumption orders.
[0115] Specifically, after the photovoltaic node completes the trust calculation, its intelligent control module or trading terminal will automatically generate a seller order (i.e., a power generation order) based on the current power generation capacity and market forecast information. The algorithm logic is as follows: read the real-time available power (i.e. the remaining power generation that can be sold at present) from the power generation node, combine the historical average price and the forecast model to calculate the suggested price range, and if the trust level is high, the node is allowed to set a higher price ceiling (reflecting the reputation premium mechanism).
[0116] Furthermore, the structure of the power generation order includes: node identity hash (to prevent identity leakage but ensure traceability), and available electricity volume. Expected price Available time window And signature and timestamp.
[0117] Furthermore, each seller's order is linked to the real-time power generation status of the equipment to prevent "false reporting of power consumption" or "premature order placement." Before generating an order, the smart meter needs to verify the consistency between the actual power curve and the order quantity.
[0118] Furthermore, electricity-consuming nodes (residents, businesses, or energy storage devices) generate demand orders (i.e., electricity-consuming orders) through client-side or automated control systems. The specific steps include: first, reading the predicted load curve and energy storage status to determine the required electricity volume. Then, based on historical transaction data and the market average price, an acceptable price is determined. The order validity period is set according to the energy demand cycle (e.g., 15 minutes to 1 hour); the order is hash-signed and a trust-attached identifier is added (i.e., bound to the trust value calculated in the previous step).
[0119] Further, the specific steps for determining the required electricity purchase volume by reading the predicted load curve and energy storage status include: Collecting real-time load data: Reading the current instantaneous power P(t) from smart meters, home energy management systems, or enterprise energy monitoring systems; Calling the load prediction model: Inputting the prediction model to the historical load curve, current time period (hourly / daily / seasonal factors), weather information (temperature, sunshine), and electricity consumption patterns (weekend / weekday differences), and outputting the predicted load curve for the next cycle (e.g., 15–60 minutes); Reading the energy storage device status (if present): Reading from the energy storage system the current SOC (State of Charge), maximum / minimum dischargeable power, and expected energy demand / compensation capacity for the next hour; Determining the electricity purchase gap: Calculating the required electricity purchase volume based on the following energy balance formula. : (8) in, Indicates real-time load power. Indicates within the time window The effective amount of electricity that can be released by an energy storage system.
[0120] Furthermore, if energy storage can compensate for part of the load, the amount of electricity purchased will decrease; if the amount of energy storage is insufficient, the amount of electricity purchased will increase; if the amount of energy storage is excessive (such as being fully charged during the day), no purchases may be made or even an order to sell electricity may be placed.
[0121] Furthermore, regarding the purchased electricity volume Conduct smoothing and anomaly investigation to avoid abnormal fluctuations in electricity purchases due to predicted jumps.
[0122] Furthermore, an acceptable price is determined based on historical transaction data and the market average price. The specific steps for the interval include: reading the user's historical electricity purchase price: reading the most recent N transaction prices, the average price during peak / off-peak periods, and the user's own purchasing habits (such as whether they prefer low prices) from the off-chain database or on-chain evidence storage; reading the current market average price: obtaining the current market average price from the order pool or market matching module. It can be the average transaction price in the last 5 minutes or the weighted average price of current seller orders; it uses user preferences to build a price willingness model; it determines the price range; trust level affects the price range: if the user's trust level is low, the system applies price protection: that is, it limits the maximum purchase price of their orders to prevent them from posting false orders and disturbing the market.
[0123] The expression for the price willingness model is: +(1- ) (9) In the above formula, This represents the user's price sensitivity coefficient, reflecting the user's price sensitivity. This represents the user's historical average transaction price. This indicates the user's expected electricity price.
[0124] Set a price range based on market fluctuations: - (10) - (11) In the above formula, Indicates the lower limit of the price. Indicates the upper limit of the price. and This indicates the adjustment amount automatically calculated by the system based on market fluctuations.
[0125] The order verification unit 1032 is used to verify electricity trading orders.
[0126] Specifically, the order verification unit 1032 is used to perform signature verification, trust threshold verification, and resource verification on electricity trading orders.
[0127] Furthermore, after an order is generated, the system does not immediately upload it to the blockchain. Instead, it goes through a pre-verification and authorization logic, which verifies the signature, trust threshold, and resources of the electricity trading order. Only after all three verifications are passed can the order be uploaded to the blockchain. The verification functions are shown in Table 4 below.
[0128] Table 4:
[0129] The signature verification process includes: the verification node using the user's public key to sign and verify the order, ensuring that: the order was indeed legally generated by the node, has not been tampered with by a third party, and the timestamp is within the allowed range. Only orders that pass signature verification are considered "trusted transaction intentions".
[0130] Furthermore, the trust threshold judgment includes: based on the results of the previous step "dynamic trust weight", executing the trust screening logic: if the node trust value is ≥ the system set threshold (e.g., 0.3), it is allowed to enter the matching pool; if the trust value is lower than the threshold but higher than the freeze line, it is temporarily listed as "orders to be verified" and needs to be reviewed through the deposit or manual review; if it is lower than the freeze line, it is directly rejected from being put on the chain.
[0131] Furthermore, the resource verification logic includes: automatically checking whether the resources corresponding to the order are sufficient: seller: verifying that the power generation or energy storage is greater than or equal to the order quantity; buyer: verifying that the account balance or credit limit is greater than or equal to the expected expenditure; orders with insufficient resources are rejected from being uploaded to the blockchain to prevent "empty orders" or "malicious quotations".
[0132] The order on-chain unit 1033 is used to convert the verified electricity trading order into a hashed transaction object and upload the hashed transaction object to the on-chain order pool.
[0133] Specifically, verified orders are converted into hashed transaction objects and submitted to the on-chain order pool. The specific steps include: first, calculating a digest of the main fields of the order (node ID hash, power, price, time window, signature) using a hash function, then writing the digest to the blockchain, while recording the off-chain detailed storage path, and finally, the smart contract generates a unique index (Order ID) for each order for subsequent matching algorithms to call.
[0134] Furthermore, in the on-chain order pool, orders are dynamically sorted according to the following rules: Trust priority: Orders from high-trust nodes are matched first; Time priority: Orders from nodes with the same trust level are sorted by submission time; Price incentive: If there are significant price differences, the sorting can be fine-tuned according to market fluctuations.
[0135] Furthermore, to prevent fake orders and malicious order manipulation, the algorithm introduces defensive logic in the generation and verification stages: Frequency detection: If a node repeatedly submits multiple high-frequency orders in a very short period of time, the system marks it as "abnormal behavior" and triggers a cooldown period or trust level penalty; Duplicate signature detection: If the same signature order content is repeatedly requested to be uploaded to the chain, the system rejects it and records a warning; Credit fluctuation protection: If a node's trust value drops rapidly in a short period of time (such as due to default), all of its unmatched orders are automatically frozen to prevent damage to market stability.
[0136] Furthermore, once an order enters the on-chain order pool, its lifecycle is recorded: if successfully matched → recorded as a positive reputation event, or cancelled or defaulted → recorded as a negative event. These events are fed back into the trust algorithm model to achieve "order result-driven trust self-learning," forming a closed-loop optimization mechanism. The trust algorithm model is a mathematical model used to calculate the trustworthiness of nodes, integrating multi-source data to quantify dimensions such as node behavioral trustworthiness, physical consistency, and data integrity. Its core components include: historical behavior trust (static trust): based on performance records, number of defaults, historical quote reliability, and the number of user complaints or arbitrations; real-time behavior trust (dynamic trust): based on the deviation between measured power and quoted power, accuracy of load forecasting, data continuity and consistency, and whether frequent order placement and malicious order manipulation are triggered; physical consistency trust: based on power conservation and node topology location to determine whether a node "falsifies electricity" or "fabricates supply and demand"; data quality trust: based on whether timestamps are continuous, whether sampling jumps or copies occur, and whether data has been abnormally tampered with; and finally, a trust score.
[0137] The present invention provides a blockchain-based distributed photovoltaic power trading system that transforms the supply and demand intentions of market participants (power generators, power consumers, and energy storage providers) after trust calculation into a verifiable and standardized order data structure, thereby achieving an accurate description of transaction orders.
[0138] In some alternative implementations, such as Figure 7 As shown, module 104 includes: The time-sensitive priority sorting unit 1041 is used to obtain the order waiting time of the power trading orders in the on-chain order pool, and calculate the time-sensitive priority of the power trading orders based on the order waiting time and the trust index value of the power trading participating nodes.
[0139] Specifically, the priority of orders is recalculated in each matching cycle (e.g., every 1 second). (i.e., time-sensitive priority of electricity trading orders): (12) in, Indicates the time decay coefficient. Indicates the order waiting time (in seconds).
[0140] Furthermore, the sorting rules are as follows: Buyer orders: price from high to low → priority from high to low; Seller orders: price from low to high → priority from high to low.
[0141] Furthermore, edge matching optimization includes: local matching is performed first on nodes in the same region; the matching results are synchronized to the main chain for full network settlement.
[0142] Furthermore, the goal of local matching is to allow nodes within the same region, on the same feeder, and under the same substation to first perform local power matching, thereby reducing cross-regional dispatch, minimizing energy loss, and increasing matching speed. The specific steps of local matching include: Region division: Based on the power grid topology (such as feeder number, substation ID, and geographical tags), all nodes are clustered into several local regions, each region corresponding to a set of buyer order pools and seller order pools; Region order screening: Within each matching cycle (e.g., per second), only orders within the current region are screened to enter the local matching module, including: the same region's seller order set and the same region's buyer order set, meeting basic conditions (such as price availability conditions). Orders that meet the following criteria will proceed to the next step; local priority sorting will be performed, with the system sorting according to rules within the region: Trust priority: nodes with higher trust levels will be prioritized; Time priority: orders will be sorted by submission time; Price incentive: orders with more favorable prices will be prioritized; Local matching execution: a two-pointer or two-queue method will be used to match one by one: starting from the head of the sorted list, sellers and buyers will be selected, and if the transaction conditions are met... The transaction price and transaction volume are calculated, and the remaining volume of both is updated. Nodes that have completed the matching process exit the matching queue, while those that have not completed the process continue to the next round of matching until there are no more orders to be matched in the region. Local transaction result generation: Each pair of successfully matched transactions generates a local transaction object, which includes: transaction volume, transaction price, seller / buyer identity hash, participation time, and trust score. Local results are synchronized on the blockchain. After local matching is completed, the local results are packaged and submitted to the main chain. After verification by the main chain, they are written into the global ledger. If there are unmatched orders in the region, they enter the cross-regional matching pool to wait for the next round of matching.
[0143] The dynamic marginal pricing unit 1042 is used to compare the seller's price and the buyer's price of orders in the on-chain order pool. If the seller's price is less than or equal to the buyer's price, the seller's trust score and the buyer's trust score are obtained. The transaction price of the power trading order is calculated based on the seller's price, the buyer's price, the seller's trust score, and the buyer's trust score.
[0144] Specifically, when the following conditions are met At that time, the matching engine calculates the transaction price. The calculation formula is as follows: (13) =1+ (14) in, This represents the seller's offer, i.e., the price per unit of electricity that the generating node is willing to sell. This represents the buyer's offer, i.e., the highest unit price at which the electricity consumption node is willing to purchase electricity. This represents the trust correction factor. Represents the trust adjustment function. This represents the seller's trust score, a comprehensive trust evaluation of the seller's nodes. It is calculated based on dimensions such as historical default history, order completion rate, metering equipment health, and node stability, and is used to reflect the credibility of the seller's quote. A higher price allows for a price premium. This represents the buyer's trust score, a comprehensive trust evaluation of the buyer's transaction history. It is calculated based on indicators such as sufficient funds, payment history, default rate, and account activity, and is used to reflect the buyer's "payment reliability." If the price is higher, the buyer is more likely to receive a discount; when At that time, the seller receives a premium. At that time, the buyer receives a discount.
[0145] Furthermore, the upper and lower limits of the transaction price are constrained as follows: (15) in, and This indicates the upper and lower limits of market prices set by regulatory nodes to prevent excessive price fluctuations.
[0146] This invention provides a blockchain-based distributed photovoltaic power trading system. In contrast, power trading prices are often set by power grid companies or large electricity retailers, leaving users with little bargaining power and making it difficult for small and medium-sized photovoltaic power plants to obtain reasonable returns. Therefore, the trading price is dynamically determined by smart contracts based on supply and demand and the real-time electricity market. All users compete under the same rules, avoiding monopolistic pricing. During peak photovoltaic power supply periods, electricity prices automatically decrease due to market supply and demand, reducing users' electricity purchase costs. During peak electricity consumption periods, power generation users can obtain higher returns, forming a truly market-based incentive mechanism.
[0147] In some alternative implementations, such as Figure 8 As shown, the dynamic matching module 105 includes: The order filtering unit 1051 is used to extract unexecuted transaction orders from the on-chain order pool and prioritize the unexecuted transaction orders based on the trust index value of the participating nodes in the power trading, time-sensitive priority, and transaction price.
[0148] Specifically, verified but unexecuted orders are extracted from the on-chain order pool and sorted by comprehensive priority (trust level, price, and time).
[0149] The matching unit 1052 is used to match unexecuted transaction orders after priority sorting, generate matching results, and upload the matching results to the blockchain node after signing.
[0150] Specifically, when the buyer makes an offer When time windows overlap, the system determines that a transaction is possible; if there are multiple matching sellers, priority is given to matching the node with high trust and a price close to the market average; if the order is partially matched, the remaining quantity is automatically split and put back into the pool.
[0151] Furthermore, the matching logic for matching unexecuted orders after priority sorting is as follows: start matching from high-priority buy orders → traverse available sell orders → generate a matching record if price and time conditions are met → sign the matching result and submit it to the blockchain to form an immutable transaction record.
[0152] This invention provides a blockchain-based distributed photovoltaic power trading system. Previously, distributed photovoltaic users had to sell their electricity through the power grid or power company intermediaries, a process that was cumbersome, with long approval cycles and settlement delays often lasting days or even weeks. Therefore, by using smart contracts to automatically execute transaction matching and settlement, users can complete matching and payment settlement within seconds of submitting a transaction request, without manual intervention. This automatic matching improves transaction efficiency.
[0153] In some alternative implementations, the dynamic matching module 105 further includes: Settlement unit 1053 is used to perform energy settlement and fund settlement using smart contracts based on the matching results, generate performance data, update the trust weight based on the performance data, and obtain the updated trust index value.
[0154] Specifically, settlement is automatically executed by smart contracts and includes two parts: energy settlement and fund settlement. Energy settlement involves the power generator's smart meter uploading its output electricity in real time, and the power consumer's meter reporting its connected power in real time. The smart contract compares the actual power transmission curve with the ordered electricity volume to confirm the fulfillment ratio. If there is a deviation (±Δ), the system automatically adjusts the settlement amount or triggers default processing according to the difference ratio. Fund settlement involves: after the transaction, calling the on-chain wallet to execute automatic transfer. The formula for calculating the settlement funds is as follows: The payment process records the transaction hash and signature verification on the blockchain. If the buyer uses a credit line to pay, the system locks the deposit as collateral until the energy delivery is confirmed.
[0155] Furthermore, to ensure market stability and fairness, the smart contract has a built-in default handling mechanism: minor default (battery power ≤5%): automatically deduct the margin or reduce the trust score; serious default (battery power >10%): freeze the node's transaction permissions and trigger manual review; system-level fluctuations (force majeure): maintain grid balance by scheduling nodes to start backup power or rematching mechanism.
[0156] Furthermore, after settlement, the matching results and performance are recorded as reputation events: successful performance → trust value increases; delayed performance or default → trust value decreases; the above feedback data is used to update the trust weight in real time, which automatically affects the node's transaction access and price weight when the next round of orders is generated, realizing a self-evolution mechanism of transaction-settlement-trust relearning.
[0157] The present invention provides a blockchain-based distributed photovoltaic power trading system. Compared with the automatic settlement of related power transactions, the transaction confirmation speed is increased by about 10-50 times, and the settlement cycle is shortened from days to minutes, which greatly improves transaction efficiency and capital turnover speed.
[0158] In some alternative implementations, it also includes: The smart contract settlement module 106 is used to perform normal performance settlement and default handling using smart contracts after the transaction matching is completed, generate evidence data, and upload the evidence data to the blockchain node.
[0159] Specifically, the smart contract settlement module 106 is the core execution link of the entire distributed photovoltaic power trading system. It is responsible for achieving automatic settlement, ledger recording, and on-chain evidence storage through smart contracts after the transaction is matched, so as to ensure transaction security, verifiable performance, and full traceability.
[0160] Furthermore, the settlement methods include normal performance settlement and default handling. Normal performance settlement occurs when the actual power generation and consumption reported by the smart meter meet the order requirements (or are within tolerance range). The smart contract automatically performs the following operations: verifying the consistency between the matching result and the settled electricity volume; deducting the payable amount from the buyer's account (or on-chain wallet); automatically transferring funds to the seller's account; synchronously updating the transaction completion status; if there is a minor difference in the transaction (e.g., within ±2%), automatically adjusting the traded electricity volume and settling proportionally, without triggering default handling. The default handling logic includes: if the seller fails to deliver sufficient electricity within the agreed time, or the buyer lacks sufficient funds, the smart contract automatically enters the default branch: seller default: deduct the difference from their margin; buyer default: freeze the corresponding credit limit or collateral assets; if both parties default, the contract calls the arbitration module to determine liability; default information is written to the trust record module, affecting subsequent trust scores; the entire contract execution is verified by blockchain consensus nodes to ensure no unilateral manipulation is possible.
[0161] Furthermore, the data structure for evidence storage is shown in Table 5 below.
[0162] Table 5:
[0163] The present invention provides a distributed photovoltaic power trading system based on blockchain. After the transaction is matched, the system uses smart contracts to achieve automatic settlement, ledger recording and on-chain evidence storage that can be supervised, so as to ensure transaction security, verifiable performance and full traceability.
[0164] Those skilled in the art will recognize that the units and algorithm steps of the various examples described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, or a combination of computer software and electronic hardware. Whether these functions are implemented in hardware or software depends on the specific application and design constraints of the technical solution. Those skilled in the art can use different methods to implement the described functions for each specific application, but such implementation should not be considered beyond the scope of the embodiments of this application.
[0165] Those skilled in the art will understand that, for the sake of convenience and brevity, the specific working processes of the systems, devices, and units described above can be referred to the corresponding processes in the foregoing method embodiments, and will not be repeated here.
[0166] In the embodiments provided in this application, it should be understood that the disclosed systems, apparatuses, and methods can be implemented in other ways. For example, the apparatus embodiments described above are merely illustrative; for instance, the division of units is only a logical functional division, and in actual implementation, there may be other division methods. For example, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. Furthermore, the displayed or discussed mutual couplings, direct couplings, or communication connections may be through some interfaces; indirect couplings or communication connections between devices or units may be electrical, mechanical, or other forms.
[0167] The units described as separate components may or may not be physically separate. The components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the units can be selected to achieve the purpose of this embodiment according to actual needs.
[0168] In addition, the functional units in the various embodiments of this application can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit.
[0169] If a function is implemented as a software functional unit and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, the technical solutions of this application, essentially, or the parts that contribute to the prior art, or parts of the technical solutions, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the steps of the methods in the various embodiments of this application. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, portable hard drives, read-only memory (ROM), random access memory (RAM), magnetic disks, or optical disks.
[0170] Although embodiments of the invention have been described in conjunction with the accompanying drawings, those skilled in the art can make various modifications and variations without departing from the spirit and scope of the invention, and such modifications and variations all fall within the scope defined by the appended claims.
Claims
1. A blockchain-based distributed photovoltaic power trading system, characterized in that, The system includes: An encryption module is used to acquire raw power data collected by multiple distributed terminals, encrypt the raw power data, and upload the encrypted power data to a blockchain node. The trust index calculation module is used to obtain the power data of the power trading participants in the blockchain node, and to perform multi-dimensional dynamic trust weight calculation on the power data based on the power data of the power trading participants to obtain the trust index value of the power trading participants. The order generation module is used to generate electricity trading orders based on the electricity data of the electricity trading participating nodes, and upload the electricity trading orders to the blockchain node; The determination module is used to determine the time sensitivity priority and transaction price of the electricity trading order; The dynamic matching module is used to match electricity trading orders based on the trust index value of the participating nodes, the time-sensitive priority, and the transaction price, generate matching results, and upload the matching results to the blockchain node after signing them.
2. The system according to claim 1, characterized in that, The encryption module includes: The acquisition unit is used to determine the physical current data stream and the account behavior data stream based on the original power data, and to align the physical current data stream and the account behavior data stream on the time axis to obtain the aligned power data. An edge aggregation unit is used to perform edge aggregation on the aligned power data to obtain a reliable time series sample. An anomaly detection unit is used to perform anomaly detection and anomaly correction on the reliable time series sample to obtain reliable electrical energy data; The hash signature processing unit is used to perform hash signature processing on the trusted electrical energy data to obtain an identity signature and a hash digest value, and upload the hash digest value to the blockchain; The regional consensus on-chain unit is used to perform regional consensus on-chain processing of the trusted power data, the identity signature, and the hash digest value.
3. The system according to claim 2, characterized in that, The hash signature processing unit includes: A signature verification subunit is used to perform signature verification on the trusted electrical energy data to obtain an identity signature; The hash calculation subunit is used to perform hash calculations on multiple fields in the trusted power data to obtain a hash digest value, upload the hash digest value to the blockchain, and store the trusted power data and the identity signature in an off-chain database.
4. The system according to claim 1, characterized in that, The trust index calculation module includes: The feature extraction unit is used to extract features from the power data of the power trading participants to obtain feature index values. The trust calculation unit is used to calculate the trust index value of the participating nodes in the power trading based on the feature index value using a weighted linear model.
5. The system according to claim 1, characterized in that, The order generation module includes: An order generation unit is used to generate electricity trading orders based on electricity data from participating nodes in an electricity trading transaction; wherein, the electricity trading orders include orders from power generators and orders from electricity consumers; An order verification unit is used to verify the electricity trading order. The order on-chain unit is used to convert verified electricity trading orders into hashed transaction objects and upload the hashed transaction objects to the on-chain order pool.
6. The system according to claim 5, characterized in that, The order verification unit is specifically used to perform signature verification, trust threshold verification, and resource verification on the electricity transaction order.
7. The system according to claim 5, characterized in that, The determining module includes: A time-sensitive priority sorting unit is used to obtain the order waiting time of the power trading orders in the on-chain order pool, and calculate the time-sensitive priority of the power trading orders based on the order waiting time and the trust index value of the power trading participating nodes. The dynamic marginal pricing unit is used to compare the seller's price and the buyer's price of the orders in the on-chain order pool. If the seller's price is less than or equal to the buyer's price, the seller's trust score and the buyer's trust score are obtained. The transaction price of the power trading order is calculated based on the seller's price, the buyer's price, the seller's trust score, and the buyer's trust score.
8. The system according to claim 5, characterized in that, The dynamic matching module includes: The order filtering unit is used to extract unexecuted transaction orders from the on-chain order pool and prioritize the unexecuted transaction orders based on the trust index value of the participating nodes in the power trading, the time-sensitive priority, and the transaction price. The matching unit is used to match unexecuted transaction orders after priority sorting, generate matching results, and upload the matching results to the blockchain node after signing.
9. The system according to claim 8, characterized in that, The dynamic matching module further includes: The settlement unit is used to perform energy settlement and fund settlement using smart contracts based on the matching results, generate performance data, update the trust weight based on the performance data, and obtain the updated trust index value.
10. The system according to claim 1, characterized in that, Also includes: The smart contract settlement module is used to perform normal performance settlement and default handling using smart contracts after the transaction matching is completed, generate evidence data, and upload the evidence data to the blockchain node.