Virtual power plant data aggregation method based on edge calculation and consensus mechanism

By introducing edge computing and consensus mechanisms into the virtual power plant, localized processing and lightweight summary uploading of massive distributed energy data were achieved. This solved the problems of high communication latency, insufficient throughput, and high terminal resource consumption in the blockchain technology of virtual power plants, improved the system's throughput, reduced latency, and built a reliable data traceability system.

CN121567708APending Publication Date: 2026-02-24ZHONGYAODA DIGITAL ENERGY ECOLOGICAL TECH (ZHEJIANG) CO LTD
View PDF 10 Cites 0 Cited by

Patent Information

Application Number
CN202610084810.2
Authority / Receiving Office
CN · China
Patent Type
Applications(China)
Current Assignee / Owner
Filing Date
2026-01-22
Publication Date
2026-02-24

AI Technical Summary

Technical Problem

Existing blockchain technology for virtual power plants suffers from problems such as high communication latency, insufficient system throughput, high resource consumption of terminal devices, and poor data processing timeliness when processing massive amounts of high-frequency real-time data from distributed energy sources. Furthermore, it has not been effectively integrated with edge computing, leading to network congestion and computing bottlenecks.

Method used

A data aggregation method based on edge computing and consensus mechanism is adopted to divide the physical entities in the virtual power plant network into edge nodes, consensus nodes and application nodes. Through the first-level consensus in the edge domain and the second-level consensus of the backbone consensus network, localized data processing and lightweight digest upload are realized. The data transmission and consensus process are optimized by combining the K-Means clustering algorithm and the Raft/PBFT protocol.

Benefits of technology

Significantly improve system throughput and scalability, reduce data processing latency, reduce terminal device resource consumption, build a structured, hierarchical security and traceability system, and ensure the real-time and reliable nature of data processing.

✦ Generated by Eureka AI based on patent content.

Smart Images

  • Figure CN121567708A_ABST
    Figure CN121567708A_ABST
Patent Text Reader

Abstract

The invention relates to the technical field of power systems, in particular to a virtual power plant data aggregation method based on edge calculation and a consensus mechanism. The method comprises the following steps: dividing edge nodes to obtain a plurality of edge domains, and electing a main edge node in each edge domain; each main edge node packages the collected distributed energy data into an edge block; each master edge node completes first-level consensus based on confirmation of more than half of slave edge nodes in an edge domain; generating data summary information based on the edge block subjected to the first-level consensus to obtain a trunk chain transaction; the consensus node executes a secondary consensus protocol on the main chain transaction to achieve global consensus; and the application node obtains the trunk block and analyzes the data summary information for application of the virtual power plant. According to the invention, a structured hierarchical security and traceability system is constructed, the throughput and expandability of the system are improved, the data processing delay is reduced by more than 90%, and the resource overhead of terminal equipment is reduced.
Need to check novelty before this filing date? Find Prior Art

Description

Technical Field

[0001] This invention relates to the field of power system technology, and specifically to a method for virtual power plant data aggregation based on edge computing and consensus mechanisms. Background Technology

[0002] Virtual Power Plants (VPPs) aggregate massive amounts of distributed energy resources (DERs) through advanced information technology, participating in grid operation and the electricity market as a whole. To ensure the trustworthiness of data interaction, blockchain technology has been widely adopted. Currently, the technical solutions for applying blockchain to virtual power plants mainly focus on several aspects:

[0003] 1. Trading and Scheduling: Many solutions utilize blockchain to build decentralized power trading platforms. For example, Chinese patent application CN202211396462.0 discloses "A Trusted Trading Method for Layered Virtual Power Plants Based on Blockchain," which supports trading between different levels by constructing a three-tiered blockchain network at the provincial, municipal, and county levels. However, its layering aims to match the levels of trading entities and does not solve the problem of real-time access and consensus of high-frequency data from massive underlying devices.

[0004] 2. Data Security and Transmission: Some technologies focus on the security of on-chain data. For example, Chinese patent application CN202510241287.5 proposes "A method and system for protecting virtual power plant data under blockchain based on AES algorithm," which encrypts data before it is uploaded to the blockchain; Chinese patent application CN202411433113.0 discloses "A reliable data transmission method for a smart virtual power plant operation platform based on blockchain," which optimizes transmission priority by assessing data importance and node computing power. However, these solutions mainly operate at the data level and do not change the underlying "network consensus" architecture of the blockchain, thus failing to solve the efficiency bottleneck of large-scale concurrent data processing.

[0005] 3. Exploration of Multi-Layer Architecture: To address scalability challenges, some solutions have begun exploring multi-layered blockchains. For example, Chinese patent application CN202411411417.7 proposes a "Trusted Terminal Access Method for Virtual Power Plants Based on Multi-Layer Blockchain Technology," which manages terminal devices by separating the access chain and the consensus chain. However, this method still requires the terminal to have a certain computing power to handle access authentication, and it does not combine edge computing for localized data preprocessing and first-level consensus; the data flow remains a direct "terminal-blockchain" model.

[0006] In summary, although existing technologies have made many explorations in combining virtual power plants with blockchain, the following core technical shortcomings still exist:

[0007] 1. Communication and computing bottlenecks persist: Neither single-chain architecture nor the existing multi-layer architecture fundamentally changes the pattern that massive amounts of raw data need to be transmitted through multiple layers of network and ultimately processed by consensus nodes. This results in persistent network congestion and computing bottlenecks, failing to meet the business requirements of millisecond-level rapid response in virtual power plants.

[0008] 2. The contradiction between consensus efficiency and scale: Existing solutions generally adopt a single consensus mechanism (such as PBFT) or a simple hierarchical transaction mechanism. When the number of distributed energy resources aggregated by virtual power plants reaches hundreds of thousands or even millions, any consensus protocol that needs to process all device transactions at the network-wide or backbone level will face a performance ceiling, leading to a sharp increase in data confirmation latency.

[0009] 3. Terminal resource constraints are ignored: Most solutions default to or require terminal devices to have the ability to perform encryption, signing, or even participate in consensus. This is unrealistic for a large number of smart meters, sensors, and other devices with extremely limited computing and storage resources, thus limiting the universality and cost-effectiveness of the technical solutions.

[0010] 4. The value of data locality is not being utilized: A large amount of distributed energy status data (such as instantaneous power and voltage) has strong timeliness and locality, and its main value lies in rapid local analysis and fault diagnosis. Existing technologies upload this data indiscriminately to the global network for consensus, which not only wastes valuable network bandwidth but also increases the burden on the backbone consensus network. Summary of the Invention

[0011] The purpose of this invention is to solve the problems of high communication latency, insufficient system throughput, high terminal equipment resource consumption, and poor data processing timeliness in the processing of massive distributed energy high-frequency real-time data in existing virtual power plant blockchain technology due to the lack of effective integration with edge computing. The invention proposes a virtual power plant data aggregation method based on edge computing and consensus mechanism.

[0012] To achieve the above objectives, the technical solution provided by this invention is as follows:

[0013] A method for data aggregation in virtual power plants based on edge computing and consensus mechanisms includes:

[0014] The physical entities in the virtual power plant network are respectively positioned as edge nodes, consensus nodes, or application nodes;

[0015] The edge nodes are divided into multiple edge domains. In each edge domain, one edge node is elected as the master edge node, and the remaining edge nodes are designated as slave edge nodes.

[0016] Within a data aggregation cycle, each master edge node packages its own and slave edge node's distributed energy data into edge blocks;

[0017] Each master edge node broadcasts the edge block to the slave edge nodes and receives confirmations from the slave edge nodes. Based on the confirmations from more than half of the slave edge nodes in the edge domain, the first-level consensus of the edge block is completed.

[0018] Each main edge node generates data digest information based on the edge blocks that have passed the first-level consensus, obtains backbone chain transactions based on the data digest information, and submits them to the backbone consensus network;

[0019] Consensus nodes in the backbone consensus network execute the secondary consensus protocol on backbone chain transactions to achieve secondary consensus and obtain backbone blocks;

[0020] Application nodes obtain backbone blocks from the backbone consensus network, parse out data digest information, and use it for virtual power plant applications.

[0021] Furthermore, the process of dividing the edge nodes includes:

[0022] The K-Means clustering algorithm is used to divide all edge nodes into multiple initial clusters based on geographical location. The internal connectivity of each initial cluster is checked to ensure that the network communication delay between any two edge nodes is less than a preset communication delay threshold. The initial clusters that meet the conditions are solidified as edge domains.

[0023] For initial clusters that do not meet the conditions, identify edge nodes in the initial clusters that cause high latency, remove the identified edge nodes from the current initial clusters, and reassign the removed edge nodes to the second nearest initial clusters. If there are no initial clusters to join, perform secondary clustering on the remaining edge nodes.

[0024] Iteratively perform the partitioning of edge nodes until all edge nodes are partitioned into edge domains that satisfy the communication delay constraints.

[0025] Furthermore, the Raft or Paxos protocol is used to elect an edge node as the master edge node in each edge domain.

[0026] Furthermore, each master edge node broadcasts the edge block to the slave edge nodes and receives confirmations from the slave edge nodes. Based on the confirmations from more than half of the slave edge nodes within the edge domain, a first-level consensus for the edge block is achieved, including:

[0027] Each master edge node broadcasts the edge block to all slave edge nodes within the edge domain. Upon receiving the block, each slave edge node verifies its validity. If the verification is successful, the slave edge node writes the edge block to its local log and returns a successful write response to the master edge node.

[0028] Once the current master edge node receives responses from more than half of the edge nodes indicating successful writes, the current edge block completes Level 1 consensus and is written to the local state database of the current edge domain.

[0029] Furthermore, each main edge node generates data digest information based on edge blocks that have passed the first-level consensus, obtains backbone chain transactions based on the data digest information, and submits them to the backbone consensus network, including:

[0030] Each primary edge node calculates a hash value based on the edge block that has passed the first-level consensus, and sums the power data and electricity data in the edge block to obtain a data digest information composed of total power and total electricity.

[0031] Each main edge node uses its own private key to sign a tuple consisting of a hash value and a data digest, thus forming a backbone transaction.

[0032] Each main edge node broadcasts its own backbone transactions to the backbone consensus network.

[0033] Furthermore, the consensus nodes in the backbone consensus network execute a second-level consensus protocol on backbone chain transactions to achieve second-level consensus and obtain backbone blocks, including:

[0034] The leading consensus node in the consensus nodes packages one or more backbone chain transactions received into a backbone block proposal and broadcasts a pre-preparation message to other backup consensus nodes. The pre-preparation message includes the backbone block proposal, the sequence number of the backbone block proposal, and the term number of the main edge node.

[0035] After the backup consensus node verifies and passes the pre-preparation message, it broadcasts the preparation message to all consensus nodes. The preparation message is the message that the current backbone block proposal has been verified.

[0036] When any consensus node receives more than a preset number of preparation messages, it broadcasts a commit message to all consensus nodes. The commit message is a message confirming that more than a preset number of consensus nodes in the backbone consensus network agree to the current backbone block proposal.

[0037] When any consensus node receives more than a preset number of commit messages, a secondary consensus is reached, and the backbone block proposal is written into the global main chain as a backbone block.

[0038] Furthermore, the preset quantity is ,in, This represents the maximum number of malicious nodes the system can tolerate. To round down, This represents the total number of consensus nodes.

[0039] Compared with existing technologies, the present invention has the following significant advantages: (1) The system throughput and scalability are improved by orders of magnitude: Unlike the traditional layered application layer scheme, the present invention parallelizes the consensus pressure at the network edge. Assuming that the processing capacity of the first-level consensus in a single edge domain is 100 TPS (transactions per second), when the system is expanded to 100 edge domains, the total data processing capacity of the system can be linearly expanded to about 10,000 TPS, far exceeding the performance bottleneck of less than 1,000 TPS in the traditional single blockchain architecture. The load of the backbone consensus network is only the number of edge domains, not the total number of terminal devices, so that the total throughput of the system can be horizontally expanded with the increase of the DER scale. (2) The data processing latency is reduced by more than 90%: The first-level consensus is completed near the data source (within the edge domain), and the end-to-end latency can be controlled within 100 milliseconds, ensuring the real-time performance of VPP internal control and optimization. In contrast, in the traditional scheme, data needs to be uploaded to the cloud through multiple levels and complete the network consensus, and the latency is usually several seconds to several minutes. Second-level consensus only processes lightweight digest data, and its confirmation speed on the backbone network is much faster than consensus on massive amounts of raw data. (3) Terminal device resource overhead is minimized: Compared with the traditional method that requires terminal participation in authentication, the resource-constrained DER terminal in this invention only needs to report data, and its CPU utilization can be maintained below 5%, with minimal memory overhead. This completely avoids the high hardware cost (cost can be reduced by more than 50%) and power consumption caused by running complex cryptographic calculations or consensus protocols on the terminal, and has better economic efficiency and universality. (4) A structured hierarchical security and traceability system is constructed: First-level consensus ensures the local consistency and anti-tampering of data in the edge domain; second-level consensus ensures the final consistency and non-repudiation of globally aggregated data. Compared with the traditional method of simple data encryption scheme, this invention uses the hash value of edge blocks stored on the chain. It has constructed a rapidly verifiable index from global aggregated data to local raw datasets, enabling efficient and structured end-to-end trusted traceability. Attached Figure Description

[0040] Figure 1 This is a schematic diagram of the system architecture of a virtual power plant data aggregation method based on edge computing and consensus mechanism according to the present invention;

[0041] Figure 2 This is an overall flowchart of a virtual power plant data aggregation method based on edge computing and consensus mechanism according to the present invention;

[0042] Figure 3 This is a detailed message interaction diagram of the first-level consensus (Raft protocol) within the edge domain of this invention;

[0043] Figure 4This is a schematic diagram of the three-stage message interaction process of the backbone consensus network second-level consensus (PBFT protocol) of this invention. Detailed Implementation

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

[0045] This embodiment can be applied to, for example... Figure 1 The system architecture shown includes a VPP operations center consisting of application nodes AN-1, a backbone consensus network consisting of five consensus nodes CN-1 to CN-5, and two edge domains. and Edge domain It comprises 100 edge nodes (EN-1-1 to EN-1-100), each connected to a distributed photovoltaic unit. Edge domain. It contains 50 edge nodes (EN-2-1 to EN-2-50), each node is connected to an energy storage battery unit.

[0046] like Figure 2 As shown, this invention provides a virtual power plant data aggregation method based on edge computing and consensus mechanisms. It includes the following steps:

[0047] Step S1: VPP network architecture definition and edge domain construction.

[0048] S101: Node Role Definition. Physical entities in the VPP network are defined as three types of logical nodes: Edge Nodes (EN), Consensus Nodes (CN), and Application Nodes (AN). Wherein:

[0049] Edge Node (EN): An industrial-grade edge computing gateway with at least a 4-core ARM processor, 2GB RAM, 16GB eMMC storage, and a gigabit Ethernet interface is selected. Each EN is pre-installed with a lightweight operating system and the data acquisition, consensus, and communication software modules described in this invention.

[0050] Consensus Node (CN): Utilizes enterprise-grade servers with at least 8 x86 processors, 32GB RAM, and 1TB NVMe SSDs. Each CN deploys a complete blockchain node program, including the PBFT consensus engine, P2P network module, and state database.

[0051] Application Node (AN): This is the server cluster of the VPP operations center, equipped with a blockchain light client SDK for interacting with the backbone consensus network. Before joining the network, all nodes must generate a public-private key pair, register with a pre-configured permission management center, and obtain a digital certificate for identity authentication and signing in subsequent communications.

[0052] S102: Edge Domain Construction. Based on physical proximity or communication topology, a set of edge nodes (EN) is divided into an edge domain. The partitioning principle is: for any two edge nodes... Network communication delay between them Less than the preset communication delay threshold .

[0053] Specifically, the system administrator initiates the edge domain construction process through the network management platform. The platform first collects the geographical location information (GPS coordinates) and network proximity information (round-trip time (RTT) between nodes measured via ping or traceroute) of all edge nodes. A communication latency threshold is then set. =50ms. The K-Means clustering algorithm is used, with geographical location as the feature, to divide edge nodes into initial clusters. Subsequently, internal connectivity is checked for each cluster to ensure that the RTT between any two edge nodes is less than 50ms. Finally, clusters that meet the conditions are solidified into edge domains. For initial clusters that do not meet the connectivity test (i.e., the communication delay between some nodes in the cluster exceeds a threshold), the system executes an optimization strategy: identify outlier edge nodes causing high latency, remove them from the current initial clusters, and attempt to reassign them to other initial clusters with the next closest geographical location; if no suitable initial cluster can be added, a secondary clustering is performed on the remaining set of outlier edge nodes. This process is iteratively executed until all edge nodes are successfully assigned to edge domains that meet the communication delay constraints. In this embodiment, 100 photovoltaic edge nodes are assigned to edge domains. 50 energy storage edge nodes were included The partitioning results (the mapping relationship between EN_ID and ED_ID) are distributed to all nodes.

[0054] This embodiment proposes a specific edge domain construction algorithm: first, K-Means is used for clustering by geographical location, and then RTT measured by ping / traceroute is used for verification and screening. The technical purpose is to construct a physically low-latency communication domain to ensure and maximize the performance of the subsequent first-level consensus protocol (Raft).

[0055] Step S2: Lightweight and fast consensus (Level 1 consensus) for data within the edge domain. (Based on the edge domain...) For example, its internal consensus process is as follows: Figure 3 As shown.

[0056] S201: Master Edge Node Election. In each edge domain... Internally, a master edge node is elected using the Raft protocol. .

[0057] Specifically, After the 100 edge nodes (ENs) are started, the Raft protocol's election process begins. Initially, all edge nodes are slave nodes. After a random election timeout period (e.g., 150-300ms), an edge node (let's say EN-1-1) times out first, transitioning to the Candidate state, incrementing its term number, and sending a RequestVoteRPC (remote procedure call) to the remaining 99 edge nodes. Other edge nodes that have not yet voted during their current term vote for EN-1-1. EN-1-1, having received more than half (51 votes, including its own) of the votes, becomes the Leader. ). Subsequently, To maintain its leadership, it sends AppendEntriesRPCs (Append Entries Remote Procedure Calls) to all edge nodes at a fixed heartbeat cycle (e.g., 50ms).

[0058] S202: Intra-domain data blockization. Within a preset data aggregation cycle... Inside, main edge node Collect all distributed energy data uploaded from edge nodes within the domain, and package the distributed energy data of the domain itself and those from edge nodes into an edge block. .

[0059] Specifically, set the data aggregation cycle. In the first Within a time period It retrieves distributed energy data records uploaded by the other 99 slave nodes from its message queue. The format of a data record is: {derID:"PV002",timestamp:1661659201,type:"power",value:4.5kW}. All 100 data records collected within the period are used as a transaction list to construct edge blocks. .

[0060] The meanings of each field are as follows:

[0061] DistributedEnergyResourceID: A unique identifier for distributed energy devices, used to distinguish different physical devices in a network;

[0062] timestamp: A Unix timestamp used when data is collected, accurate to the second or millisecond, used for the temporal arrangement and backtracking of data;

[0063] type: Data type identifier, such as "power" representing instantaneous power, "voltage" representing voltage, "capacity" representing remaining capacity, etc.

[0064] value: The specific physical measurement value, with the corresponding unit (such as kW, V, kWh, etc.).

[0065] S203: Intra-domain consensus confirmation. The primary edge node broadcasts the edge block, and when it receives more than half (i.e., ...) consensus confirmation... Once the edge nodes confirm the agreement, a first-level consensus is reached.

[0066] Specifically, Will The edge block is sent to all slave nodes via AppendEntriesRPC. Upon receiving the block, each slave node verifies its validity. If verification is successful, the edge block is written to its local log, and a successful write response is returned to the master edge node. After receiving successful responses from more than half (50) of the edge nodes, the edge block is considered "Committed" within the domain and is officially written to the database. The local state database (local ledger).

[0067] Step S3: Global efficient consensus (second-level consensus) across edge domain data.

[0068] S301: Data Summary Submission. The main edge node for each edge domain. Extract the hash value of the edge block and calculate the data aggregation summary. The calculation formula is as follows:

[0069]

[0070] in, and The first one in the edge domain Distributed energy data in a cycle The average power and total charge within the area. The main edge node will use a binary tuple. Submitted to the backbone consensus network. The ellipsis "..." in the formula indicates an expandable field in the data digest structure. In practical applications, in addition to active power (P) and energy (E), other key operational indicators such as total reactive power (Q_total), average node voltage deviation (V_avg_dev), or regulation capacity margin can be included according to grid dispatch requirements. This design allows the system to flexibly support various ancillary services without changing the underlying consensus architecture.

[0071] Specifically, Submitting to the backbone consensus network Then, immediately calculate its SHA-256 hash value. The total power is obtained by summing the 100 power data points in the block. =450kW. The total power consumption is obtained by summing the power consumption data. Then, the primary edge node uses its own private key to... Signing constitutes a main chain transaction. .at the same time, Main edge node It also completes its internal consensus, generating another main chain transaction. Both will broadcast the main chain transactions to the main chain consensus network.

[0072] By combining hash values ​​and data aggregation digests into a single tuple and using it as the consensus content of the backbone chain, an architectural design that deeply optimizes system functionality and performance is achieved. By combining aggregation digests with direct business value with block hashes that provide cryptographically trusted anchors, it decouples the system's real-time application requirements from the need for end-to-end traceable auditing, thus solving the problem of balancing efficiency and trust in existing technologies.

[0073] Specifically, the data aggregation digest, as lightweight business data, enables the backbone consensus network to process state updates from various edge domains with low communication and computational overhead, meeting the performance requirements of the virtual power plant for market response and real-time control. Meanwhile, the hash value, as a unique and immutable cryptographic fingerprint of the original dataset, once recorded on the global main chain, is equivalent to providing global existence and integrity verification for all original data at the network edge. This design constructs a dual-channel information processing model: the upper-layer application processes the real-time updated data aggregation digest, while the underlying trust of the system is guaranteed by a trust chain composed of hash values. This structure optimizes the system's monitoring and auditing processes. When verification of any aggregated data is required, regulators do not need to perform inefficient searches in historical data; instead, they can directly use the block hash recorded on the chain as an index to initiate a verification request for the original data block to the corresponding edge domain. By comparing the locally calculated hash value with the on-chain record, an efficient, accurate, and cryptographically deterministic audit can be achieved. In summary, this data structure, through its inherent logical decoupling and functional complementarity, ensures high throughput and low latency operation of the system while constructing a scalable, low-cost, reliable, and trustworthy data traceability system.

[0074] S302: Backbone consensus network PBFT consensus. The backbone consensus network uses the Practical Byzantine Fault Tolerance (PBFT) protocol to perform a three-phase (pre-preparation, preparation, commit) consensus on transactions submitted by each edge domain. When a node receives... After a consistent commit message (where, This represents the maximum number of malicious nodes the system can tolerate. To round down, (This represents the total number of consensus nodes), indicating that a second-level consensus has been reached.

[0075] Specifically, the five consensus nodes in the backbone consensus network execute PBFT consensus. This is based on the PBFT standard fault-tolerance formula. The number of malicious nodes that the system can tolerate can be calculated. .

[0076] Preparatory Phase: The leading consensus node CN-1 will and Packaged into a backbone block proposal The sequence number n=512 is assigned, and a pre-preparation message is broadcast to other nodes. The pre-preparation message is the starting point of the PBFT consensus and is issued by the primary consensus node. It mainly contains three key pieces of information: 1. The backbone block proposal (… ), that is, the consensus node's packaged content containing and The block content includes: 1. The block content of the transaction; 2. The sequence number (n), such as n=512 in the example, used to determine the unique order of the block on the chain; 3. The view number (similar to the term number in the Raft protocol, used to distinguish different consensus rounds), representing the current leader's term. Once the backup consensus node receives this message, it will begin verifying the proposal.

[0077] Preparation Phase: After the backup consensus nodes verify the proposal, they broadcast preparation messages to each other. Each consensus node collects... After receiving a consistent preparation message, the system enters the "Ready" state. The preparation message is the message indicating that the current backbone block proposal has been verified.

[0078] Submission Phase: Nodes that have entered the "Ready" state broadcast a commit message. The commit message confirms that more than a preset number of consensus nodes in the backbone consensus network agree to the current backbone block proposal. When any consensus node collects... After a consistent commit message is received, consensus is reached, and the backbone block proposal is written into the global main chain as a backbone block.

[0079] If a consensus node fails to collect within the specified time... If no consistent prepare or commit message is received, the process will not proceed to the next phase. This is typically considered a consensus failure (e.g., the leading consensus node acts maliciously / crashes, or network latency is too high). In this case, the consensus node will trigger the PBFT view change protocol:

[0080] 1. The consensus node will time out and broadcast a VIEW-CHANGE message, proposing to move to the next view (i.e., change the leading consensus node).

[0081] 2. When a consensus node collects... After a VIEW-CHANGE message, it will become the dominant consensus node for the new view (e.g., CN-2 becomes the new Primary).

[0082] 3. The new dominant consensus node will be repackaged. and (These transactions were not lost, but were not agreed upon), and a new round of "pre-preparation-preparation-submission" process was initiated.

[0083] In summary, if consensus is not reached, the system will trigger the ViewChange protocol, elect a new dominant consensus node, and restart the consensus process for the same batch of transactions. To prevent the system from getting stuck in an infinite loop due to network partitions or persistent attacks, a maximum retry threshold is set. (For example, set to 3 times). If after If no consensus is reached on the secondary view change, the system will execute a circuit breaker mechanism: marking the current backbone block proposal as invalid and discarding it, recording the anomaly log and triggering an alarm, and then restoring the state to prepare for processing new transactions in the next time window, thereby ensuring the real-time performance of the virtual power plant operation and the continuous availability of the system.

[0084] Second-level consensus process as follows Figure 4 As shown:

[0085] The solid line represents "Request: Submit Transaction". This solid arrow points from the "Edge Domain Master Node" to the "Leading Consensus Node", representing the initiation of the second-level consensus. According to step S301 (Data Digest Submission) in this embodiment, the edge domain master node... After achieving Level 1 consensus within the domain, the edge domain's "data digest" and "edge block hash" are packaged into a backbone transaction. This line represents the edge domain master node sending this backbone transaction to the current leading consensus node (PrimaryCN) in the backbone consensus network, requesting its inclusion in the global ledger.

[0086] The dashed line represents pre-prepare, with the dashed arrow pointing from the "leading consensus node" to all "backup consensus nodes," corresponding to step S302 (pre-prepare phase) in this embodiment. When the leading consensus node receives a backbone transaction from the edge domain, it verifies the transaction, assigns it a sequence number, and packages it into a backbone block proposal. This line represents the leading consensus node broadcasting a pre-prepare message to all other backup consensus nodes, meaning: "Propose adding this new backbone transaction / backup block proposal to the chain; please verify."

[0087] The dashed arc represents "Prepare," signifying a network-wide broadcast. This corresponds to step S302 (Prepare Phase) in this embodiment. Once a backup consensus node receives and verifies the prepare message from the leading consensus node, it broadcasts a prepare message to all other nodes (including the leading consensus node and other backup consensus nodes). This means: "The proposal from the leading consensus node has been received, and it is considered to be without problems."

[0088] The solid arc represents a commit, signifying another network-wide broadcast, corresponding to step S302 (commit phase) in this embodiment. When any consensus node (whether the leading consensus node or a backup consensus node) has collected enough (i.e. After receiving readiness messages from different consensus nodes, it indicates that a majority of consensus nodes in the network have agreed to the proposal. At this point, the current consensus node will broadcast a commit message to all other nodes again. This line represents the final confirmation broadcast, which means: "Confirming that a majority of consensus nodes are ready, we are now officially committing this backbone block proposal to the local ledger." When a consensus node receives... After the submission message is sent, the consensus of the backbone block proposal is completely completed, and the backbone block proposal is written into the global main chain as a backbone block.

[0089] Step S4: Querying and applying aggregated data on the blockchain.

[0090] Application node AN acts as a light client, obtaining the latest confirmed backbone blocks in real time, parsing out the hash values ​​and aggregate digests of all edge domains, and using them for upper-layer applications of VPP.

[0091] Specifically, application node AN-1, through its connected CN node, detects the generation of a new backbone block. AN-1 immediately downloads and parses the backbone block, obtaining... and The content, that is, in the first The total power generation of the photovoltaic domain within each time period is =450kW, the total charging and discharging power of the energy storage domain is Based on this highly reliable, second-level updated aggregated data, the VPP operator's Energy Management System (EMS) accurately calculates the overall adjustability of the current VPP and automatically generates bids to participate in the grid's ancillary services market. Simultaneously, the hash value... and It is stored in the database of the application node for future data auditing and traceability.

[0092] In this embodiment, Raft consensus is used within the edge domain, while PBFT consensus is used in the backbone consensus network, and they interact through a clearly defined data interface. The edge layer transmits not intermediate states or proposals during the consensus process to the consensus layer, but rather the final result after consensus is achieved, which is then abstracted as... This is a standard data unit. For the PBFT network at the consensus layer, the received tuple is treated as an independent, pending transaction, and the backbone consensus network does not need to know the generation process of this transaction within the edge domain. This design eliminates complex protocol handshakes, state synchronization, or locking mechanisms between the two layers, and the data flow is explicitly unidirectional, thus achieving a high degree of decoupling. This loosely coupled design brings several substantial advantages to the system. First, it establishes clear modular boundaries, allowing the edge layer and consensus layer to evolve and upgrade independently, thereby improving the system's flexibility and maintainability. Second, this design achieves effective fault isolation, ensuring that internal failures in a single edge domain do not affect the normal operation of the backbone network or other domains, enhancing the robustness of the entire system. Third, by avoiding complex cross-domain state synchronization and dependency management, the system logic is simplified, reducing the complexity of development and debugging. Finally, decoupling allows each edge domain and the backbone consensus network to execute consensus in parallel and independently. This parallel processing capability is the foundation for the system to achieve high throughput and scalability, ensuring its performance as the scale of distributed energy continues to expand.

[0093] The embodiments described above are merely illustrative of several implementations of the present invention, and while the descriptions are relatively specific and detailed, they should not be construed as limiting the scope of the invention patent. It should be noted that those skilled in the art can make various modifications and improvements without departing from the concept of the present invention, and these all fall within the protection scope of the present invention. Therefore, the protection scope of this invention patent should be determined by the appended claims.

Claims

1. A method for data aggregation in virtual power plants based on edge computing and consensus mechanisms, characterized in that, The virtual power plant data aggregation method based on edge computing and consensus mechanisms includes: The physical entities in the virtual power plant network are respectively positioned as edge nodes, consensus nodes, or application nodes; The edge nodes are divided into multiple edge domains. In each edge domain, one edge node is elected as the master edge node, and the remaining edge nodes are designated as slave edge nodes. Within a data aggregation cycle, each master edge node packages its own and slave edge node's distributed energy data into edge blocks; Each master edge node broadcasts the edge block to the slave edge nodes and receives confirmations from the slave edge nodes. Based on the confirmations from more than half of the slave edge nodes in the edge domain, the first-level consensus of the edge block is completed. Each main edge node generates data digest information based on the edge blocks that have passed the first-level consensus, obtains backbone chain transactions based on the data digest information, and submits them to the backbone consensus network; Consensus nodes in the backbone consensus network execute the secondary consensus protocol on backbone chain transactions to achieve secondary consensus and obtain backbone blocks; Application nodes obtain backbone blocks from the backbone consensus network, parse out data digest information, and use it for virtual power plant applications.

2. The virtual power plant data aggregation method based on edge computing and consensus mechanism according to claim 1, characterized in that, The process of dividing edge nodes includes: The K-Means clustering algorithm is used to divide all edge nodes into multiple initial clusters based on geographical location. The internal connectivity of each initial cluster is checked to ensure that the network communication delay between any two edge nodes is less than a preset communication delay threshold. The initial clusters that meet the conditions are solidified as edge domains. For initial clusters that do not meet the conditions, identify edge nodes in the initial clusters that cause high latency, remove the identified edge nodes from the current initial clusters, and reassign the removed edge nodes to the second nearest initial clusters. If there are no initial clusters to join, perform secondary clustering on the remaining edge nodes. Iteratively perform the partitioning of edge nodes until all edge nodes are partitioned into edge domains that satisfy the communication delay constraints.

3. The virtual power plant data aggregation method based on edge computing and consensus mechanism according to claim 1, characterized in that, The Raft or Paxos protocol is used to elect an edge node as the master edge node in each edge domain.

4. The virtual power plant data aggregation method based on edge computing and consensus mechanism according to claim 1, characterized in that, Each master edge node broadcasts the edge block to the slave edge nodes and receives confirmations from the slave edge nodes. Based on the confirmations from more than half of the slave edge nodes within the edge domain, a first-level consensus for the edge block is achieved, including: Each master edge node broadcasts the edge block to all slave edge nodes within the edge domain. Upon receiving the block, each slave edge node verifies its validity. If the verification is successful, the slave edge node writes the edge block to its local log and returns a successful write response to the master edge node. Once the current master edge node receives responses from more than half of the edge nodes indicating successful writes, the current edge block completes Level 1 consensus and is written to the local state database of the current edge domain.

5. The virtual power plant data aggregation method based on edge computing and consensus mechanism according to claim 1, characterized in that, Each primary edge node generates data digest information based on edge blocks that have passed Level 1 consensus, obtains backbone chain transactions based on the data digest information, and submits them to the backbone consensus network, including: Each primary edge node calculates a hash value based on the edge block that has passed the first-level consensus, and sums the power data and electricity data in the edge block to obtain a data digest information composed of total power and total electricity. Each main edge node uses its own private key to sign a tuple consisting of a hash value and a data digest, thus forming a backbone transaction. Each main edge node broadcasts its own backbone transactions to the backbone consensus network.

6. The virtual power plant data aggregation method based on edge computing and consensus mechanism according to claim 1, characterized in that, The consensus nodes in the backbone consensus network execute the secondary consensus protocol on backbone chain transactions to achieve secondary consensus and obtain backbone blocks, including: The leading consensus node in the consensus nodes packages one or more backbone chain transactions received into a backbone block proposal and broadcasts a pre-preparation message to other backup consensus nodes. The pre-preparation message includes the backbone block proposal, the sequence number of the backbone block proposal, and the term number of the main edge node. After the backup consensus node verifies and passes the pre-preparation message, it broadcasts the preparation message to all consensus nodes. The preparation message is the message that the current backbone block proposal has been verified. When any consensus node receives more than a preset number of preparation messages, it broadcasts a commit message to all consensus nodes. The commit message is a message confirming that more than a preset number of consensus nodes in the backbone consensus network agree to the current backbone block proposal. When any consensus node receives more than a preset number of commit messages, a secondary consensus is reached, and the backbone block proposal is written into the global main chain as a backbone block.

7. The virtual power plant data aggregation method based on edge computing and consensus mechanism according to claim 6, characterized in that, The preset quantity is ,in, This represents the maximum number of malicious nodes the system can tolerate. To round down, This represents the total number of consensus nodes.

Citation Information

Patent Citations

  • Hierarchical virtual power plant trusted transaction method based on block chain

    CN115439255A

  • Intelligent virtual power plant operation platform data reliable transmission method based on block chain

    CN118972391A

  • Virtual power plant trusted terminal access method based on multi-layer blockchain technology

    CN119520014B

  • Virtual power plant data protection method and system under block chain based on AES algorithm

    CN120197229A

  • Wiring optimization method of wired vehicle detector in indoor parking lot

    CN101887645A