On-chain consensus and benefit distribution method, system and electronic device of transformer area flexible resource and medium

Abstract

The present application relates to the technical field of power equipment management, and more particularly to a method, system, device and medium for on-chain consensus and income distribution of flexible resources in a transformer area; the method first acquires multi-dimensional behavior data of each flexible resource node in the transformer area, and generates a unified flexibility contribution value after preprocessing. Based on this contribution value, the registered candidate nodes are sorted, and consensus nodes, backup nodes and supervision nodes are dynamically elected, thereby constructing an on-chain consensus layer driven by a smart contract. After the consensus verification is completed, an on-chain income pool is created according to the heterogeneous income. Finally, the differentiated income weight is distributed according to the flexibility contribution value of each node, and the income clearing and on-chain settlement are automatically completed through the smart contract. The present application solves the closed-loop mapping problem of "resource behavior to consensus weight, consensus weight to income incentive", and improves the fairness, transparency and resource participation enthusiasm of the operation of the power transformer area.

Description

Technical Field

[0001] This invention relates to the field of power equipment management technology, and in particular to an on-chain consensus and revenue distribution method, system, electronic device and medium for flexible resources in power distribution areas. Background Technology

[0002] As the penetration rate of distributed photovoltaics, energy storage, and electric vehicles on the distribution side continues to increase, power distribution areas are gradually evolving into aggregated units with multiple types of controllable resources, requiring simultaneous participation in various market transactions such as electricity, ancillary services, and demand response. Against this backdrop, blockchain technology, due to its distributed ledger, tamper-proof, and traceability characteristics, has been introduced into the field of distribution area-level energy trading and collaborative control to build trusted resource access, transparent transaction execution, and incentive allocation mechanisms.

[0003] In existing technologies, some solutions have attempted to leverage blockchain and smart contracts to achieve coordinated transaction matching and scheduling of resources within a trading area. For example, some solutions employ traditional consensus mechanisms such as PoW (Proof of Work), PoS (Proof of Stake), or PBFT (Practical Byzantine Fault Tolerance) to record transaction data on the blockchain and combine it with predefined contracts for identity registration and revenue settlement. However, in-depth research by the inventors has revealed several prominent problems with these methods: (1) The consensus mechanism is disconnected from the actual operation of resources. Existing blockchain platforms mostly rely on computing power or asset holdings to select consensus nodes, failing to correlate with the responsiveness, availability, stability and other behavioral characteristics of devices in the actual scheduling process. As a result, node election cannot objectively reflect its actual contribution to system coordination.

[0004] (2) Lack of quantification and incentive mechanisms for multi-dimensional behavioral value. Most platforms only record power and transaction data, lacking integrated measurement of multi-dimensional characteristics such as response timeliness, fulfillment rate, and event participation, making it difficult to build a differentiated clearing mechanism based on behavioral contributions.

[0005] (3) The revenue distribution mechanism is crude and difficult to support a multi-market coupling environment. Existing methods generally adopt a static allocation strategy based on electricity or time ratio, which cannot adapt to the dynamic division of revenue structures of various types such as energy, capacity, and mileage, and the verifiable incentive requirements. This can easily lead to the same physical capacity being repeatedly allocated or actual execution deviations.

[0006] It is particularly noteworthy that although Comparative Document 1 (CN108712468B) proposes a blockchain revenue distribution system based on computing power and equity collateral, and attempts to improve the fairness of node incentives by introducing a profit-sharing coefficient and equity table, its profit-sharing mechanism still relies on on-chain parameters such as computing power level and collateral equity value, and is not coupled with factors such as the actual response behavior of resources in the physical system and the value contributed by multiple markets. Therefore, it cannot solve the problem of the lack of closed-loop mapping of resource "behavior-consensus-incentive" in the transformer area scenario. Summary of the Invention

[0007] To address the aforementioned shortcomings or deficiencies, this invention provides an on-chain consensus and revenue distribution method, system, electronic device, and medium for flexible resources in a distribution area. This solves the core technical problem that existing blockchain platforms struggle to achieve a closed-loop mapping from "resource behavior to consensus weight, and consensus weight to revenue incentives" in distribution area collaboration scenarios.

[0008] This invention provides an on-chain consensus and revenue distribution method for flexible resources in a distribution network, including: The system acquires multi-dimensional behavioral data of each flexible resource node within the distribution area, and preprocesses the multi-dimensional behavioral data to obtain the flexibility contribution value of each flexible resource node.

[0009] The registered candidate node set is sorted according to the flexibility contribution value to obtain the candidate node ranking result.

[0010] Consensus nodes, backup nodes, and supervisory nodes are elected based on the candidate node ranking results. An on-chain consensus layer is then created based on the consensus nodes, backup nodes, and supervisory nodes. The on-chain consensus layer includes the role relationships of election, consensus, accounting, and verification nodes coupled through smart contract logic in the blockchain network.

[0011] After consensus verification by the on-chain consensus layer, an on-chain revenue pool is created based on the set heterogeneous revenue.

[0012] In the on-chain revenue pool, differentiated revenue weights are allocated to the corresponding flexible resource nodes based on their flexibility contribution values, so that revenue clearing and on-chain settlement can be executed through smart contracts.

[0013] According to a second aspect, this invention provides an on-chain consensus and revenue distribution system for flexible resources in a distribution area, comprising: The flexibility contribution measurement module is used to acquire multi-dimensional behavioral data of each flexible resource node in the transformer area, and preprocess the multi-dimensional behavioral data to obtain the flexibility contribution value of each flexible resource node.

[0014] The candidate node sequence generation module is used to sort the registered candidate node set according to each flexibility contribution value to obtain the candidate node sorting result.

[0015] The on-chain consensus layer generation module is used to elect consensus nodes, backup nodes, and supervisory nodes based on the candidate node ranking results, and to create an on-chain consensus layer based on the consensus nodes, backup nodes, and supervisory nodes. The on-chain consensus layer includes the role relationships of election, consensus, accounting, and verification nodes coupled through smart contract logic in the blockchain network.

[0016] The on-chain yield pool generation module is used to create an on-chain yield pool based on the set heterogeneous yield after consensus verification by the on-chain consensus layer.

[0017] The on-chain consensus and revenue distribution module is used to allocate differentiated revenue weights to corresponding flexible resource nodes in the on-chain revenue pool based on their respective flexibility contribution values, so as to automatically execute revenue clearing and on-chain settlement through smart contracts.

[0018] According to a third aspect, the present invention provides an electronic device comprising: At least one processor; and The memory that is communicatively connected to the at least one processor; The memory stores instructions that can be executed by the at least one processor, which are executed by the at least one processor to enable the at least one processor to execute the on-chain consensus and revenue distribution method for any of the flexible resources in the present invention.

[0019] According to another aspect of the present invention, a non-transitory computer-readable storage medium storing computer instructions is provided, wherein the computer instructions are used to cause a computer to execute the on-chain consensus and revenue distribution method for any of the flexible resources of the server area in the embodiments of the present invention.

[0020] The technical solution of this invention first acquires behavioral data of each flexible resource node within the distribution area across multiple dimensions, including demand response, distribution area collaboration, and blockchain support. After data integrity verification and standardized preprocessing, this data is input into a flexibility contribution value calculation model to generate a unified quantitative indicator representing the value of resource behavior—the flexibility contribution value. Subsequently, based on this contribution value, the registered candidate node set is sorted, and nodes with higher contributions are selected as the candidate node set. Then, according to the candidate node sorting results, a consensus node, backup node, and regulatory node are dynamically elected using a Verifiable Random Function (VRF), thereby constructing an on-chain consensus layer. This layer uses smart contracts to achieve logical coupling and functional collaboration between the roles of election, consensus, accounting, and verification nodes. After the on-chain consensus layer verifies the consensus on multi-market revenue data, it creates on-chain revenue pools based on heterogeneous revenue types such as energy, capacity, and mileage. Finally, differentiated revenue weights are calculated in the revenue pools based on the flexibility contribution value of each node, and the clearing logic and on-chain settlement are automatically executed through smart contracts.

[0021] Throughout the process, the technical solution of this invention addresses the problem of "disconnect between consensus mechanism and resource behavior" mentioned in the background technology by constructing a multi-dimensional flexible contribution value system. This system integrates the actual response behavior of devices, the collaborative value of the system, and the on-chain support capabilities into a unified quantitative indicator, achieving direct coupling between consensus weights and physical behavior. To address the problem of "single or missing contribution measurement dimensions," it introduces multi-dimensional quantifiable features such as response latency, fulfillment rate, and data integrity, forming an objective evaluation basis based on behavioral value and supporting differentiated incentives. To address the problem of "inability to support refined revenue distribution across multiple markets," it designs a weight allocation model centered on flexible contribution values, combining smart contracts to achieve dynamic, verifiable, and automated clearing of revenue pools across multiple markets, avoiding the crude mechanism of traditional static allocation based on electricity consumption or time. To address the problem of "insufficient fairness and resistance to manipulation in node elections," it adopts a dynamic election mechanism based on a combination of contribution value sorting and random functions, ensuring the decentralization, traceability, and high availability of the consensus group structure.

[0022] Therefore, the technical solution of this invention solves the core technical problem that existing blockchain platforms are unable to achieve a closed-loop mapping of "resource behavior to consensus weight, and consensus weight to revenue incentive" in the context of power distribution area collaboration. This improves the fairness, transparency and resource participation of power distribution area operations, and provides reliable technical support for the participation of various types of flexible loads in market transactions. Attached Figure Description

[0023] Figure 1 This is a flowchart of an embodiment of the on-chain consensus and revenue distribution method for flexible resources in the distribution area according to the present invention; Figure 2 This is a structural block diagram of an on-chain consensus and revenue distribution system for flexible resources in a distribution area according to an embodiment of the present invention. Figure 3 This is a block diagram of an electronic device used to implement embodiments of the present invention. Detailed Implementation

[0024] The following description, in conjunction with the accompanying drawings, illustrates exemplary embodiments of the present invention, including various details to aid understanding. These details should be considered merely exemplary. Therefore, those skilled in the art will recognize that various changes and modifications can be made to the embodiments described herein without departing from the scope of the invention. Similarly, for clarity and brevity, descriptions of well-known functions and structures are omitted in the following description.

[0025] This invention provides an on-chain consensus and revenue distribution method for flexible resources in a power distribution area, based on a first aspect. This method can be applied to an on-chain consensus and revenue distribution system for flexible resources in a power distribution area (hereinafter referred to as the "system"). The power equipment in the power distribution area should be able to run a large model and rule base through local deployment or containerization, completing real-time collection, cleaning, feature extraction, and trusted on-chain preprocessing of multi-dimensional behavioral data from each flexible resource node within the area. This provides a high-quality, verifiable input data foundation for subsequent calculation of flexibility contribution values ​​and consensus decisions. Specifically, the power equipment in the power distribution area includes, but is not limited to, flexible resource nodes such as distributed photovoltaic systems, energy storage systems, electric vehicle charging piles, and adjustable loads.

[0026] like Figure 1 As shown, the method may include: Step S110: Obtain multi-dimensional behavioral data of each flexible resource node in the transformer area, and preprocess the multi-dimensional behavioral data to obtain the flexibility contribution value of each flexible resource node.

[0027] Within a power distribution area, each flexible resource node refers to a distributed power resource entity that possesses controllable and adjustable characteristics and can participate in collaborative operation and market-based transactions through technologies such as blockchain within the power distribution area (typically referring to the low-voltage distribution network area within the power supply range of a distribution transformer). These nodes are the basic units for constructing a new power system and realizing flexible interaction between power generation, grid, load, and storage. Multidimensional behavioral data can include demand response dimension data, distribution area collaboration dimension data, and blockchain support dimension data. The flexibility contribution value (which can be simply referred to as...) The scalar value is obtained by weighted fusion calculation of the above three dimensions of quantitative indicators, and is used to comprehensively evaluate the overall contribution level of nodes in physical response, system coordination and on-chain support.

[0028] Specifically, demand response dimension data can include response mileage (e.g., absolute power integral of instruction tracking), response latency (i.e., the delay between the start time of the response action and the market instruction), and tracking accuracy (e.g., root mean square error, or RMSE for short). Distribution area collaboration dimension data can include equipment availability (the proportion of time equipment is in an adjustable state relative to total runtime), historical fulfillment rate (i.e., the ratio of successful executions to total participations), and event participation (e.g., the proportion of equipment participating in key scheduling events such as peak-valley reduction and frequency control). Blockchain support dimension data includes data reporting completeness (e.g., transmission success rate, format compliance rate) and consensus participation activity (e.g., the number of historical successful consensuses, node online rate).

[0029] For example, the system can obtain multi-dimensional behavioral data of some flexible resource nodes in the following manner: First, the power response data and latency of the charging pile are collected in real time by the edge computing unit deployed in the smart ring network box; then, the available capacity and historical charging and discharging performance records of the energy storage device are obtained through the interface of the Energy Management System (EMS); finally, the success rate of recording and data on-chain is achieved by synchronizing consensus through blockchain light nodes.

[0030] Specifically, the system can calculate the flexibility contribution value through the following steps: First, the raw data for each dimension is standardized to eliminate the influence of units. Then, weighting coefficients are assigned to the response, collaboration, and support dimensions (e.g., 0.4, 0.3, 0.3 respectively), and these coefficients can be dynamically adjusted based on actual operational strategies. Finally, a linear weighted summation formula is used to calculate the weighting coefficients for each node. .

[0031] Furthermore, The calculation formula can be: in, , , These are the weight coefficients for each dimension, and ; , , The scores are for the standardized demand response dimension, the district collaboration dimension, and the blockchain support dimension, respectively.

[0032] Step S120: Sort the registered candidate node set according to each flexibility contribution value to obtain the candidate node ranking result.

[0033] The set of registered candidate nodes refers to the set of flexible resource nodes that have completed identity registration and authentication in the blockchain network. The sorting operation is based on... Nodes are sorted in descending order, with those having higher contribution values ​​ranked higher.

[0034] Specifically, the system can periodically (e.g., every 15 minutes) calculate the flexibility contribution value of all candidate nodes and generate a ranking list of node contributions across the entire network. This list serves as the basis for subsequent consensus node elections. For example, assuming that the candidate node set at a certain time period includes nodes A, B, and C, with flexibility contribution values ​​of 0.85, 0.92, and 0.78 respectively, the sorted result would be: [node B, node A, node C].

[0035] Step S130: Elect consensus nodes, backup nodes, and regulatory nodes based on the candidate node ranking results, and create an on-chain consensus layer based on the consensus nodes, backup nodes, and regulatory nodes.

[0036] The on-chain consensus layer comprises the roles of election, consensus, accounting, and verification nodes coupled through smart contract logic within the blockchain network. In other words, the on-chain consensus layer refers to the set of node logic within a blockchain network, coordinated and managed by smart contracts, each possessing specific functional roles (including election, consensus, accounting, and verification). Its core function is to ensure the trustworthiness, efficiency, and fault tolerance of the consensus process. A smart contract is an automated program running on the blockchain; its core function is to automatically execute contract terms when preset conditions are met, enabling trusted transactions and business logic processing without third-party intervention.

[0037] In this embodiment, smart contracts are mainly used to implement functions such as node election, consensus verification, revenue pool creation, and automated clearing and settlement, ensuring that the contribution measurement, consensus participation, and revenue distribution of flexible resource nodes within the platform are transparent, tamper-proof, and traceable throughout the entire process. Specific smart contract models or platforms that can be used include contracts written in Solidity on the Ethereum platform, Chaincode from Hyperledger Fabric, or FISCO BCOS (Financial Blockchain Open Consortium Operating System) smart contract modules suitable for consortium blockchain environments. These contract types all support complex condition judgments, state storage, and event triggering mechanisms, effectively supporting the business needs of multi-role collaboration, dynamic weight allocation, and on-chain automated settlement in this embodiment.

[0038] Specifically, the system can automatically execute the following node election process through smart contracts: The top K nodes (e.g., the top 20) are selected from the sorted candidate node list as the candidate node set. Then, N nodes (e.g., 7) are randomly selected from the candidate node set based on the verifiable random function (VRF) as the official consensus nodes for the current period, responsible for block packaging and verification. At the same time, M nodes (e.g., 3) are selected from the candidate node set that were not selected as consensus nodes, ranked by their contribution value, as backup nodes, responsible for taking over the work when a consensus node fails. The regulatory nodes are pre-authorized and designated by the system operator or regulatory agency, responsible for auditing and supervising the consensus process and revenue distribution.

[0039] VRF is a cryptographic primitive based on asymmetric keys. It generates deterministic and publicly verifiable random numbers using node private keys and input data (such as the current block hash and the ranking of candidate nodes). Specifically, in blockchain elections, it is used to randomly select consensus nodes from the ranked set of candidate nodes, ensuring the unpredictability, fairness, and verifiability of the election process (by verifying the correctness of the generated random numbers through public keys), thereby avoiding centralized manipulation and enhancing the decentralized nature of the consensus layer.

[0040] Step S140: After consensus verification by the on-chain consensus layer, create an on-chain revenue pool according to the set heterogeneous revenue.

[0041] Heterogeneous revenue refers to the various types of revenue obtained by a (power) distribution area from participating in different power markets (such as the energy market, capacity ancillary services market, demand response market, etc.). On-chain revenue pool (available) (This can refer to a pool of digital assets created on a blockchain through smart contracts, used for the temporary collection and distribution of returns from various markets.)

[0042] For example, the system can achieve on-chain verification of revenue data and consensus through the following steps: The consensus nodes perform multi-signature verification on the revenue data from various market data sources to ensure the authenticity and integrity of the data; after the verification is successful, the revenue data is written to the blockchain through a smart contract, and the revenue pool creation event is triggered.

[0043] For example, at the end of each settlement cycle (e.g., 1 day), the smart contract automatically retrieves revenue data from various market settlement interfaces and transfers it to a designated on-chain revenue pool address. For instance, it retrieves energy revenue from the electricity market interface. Obtain capacity revenue from the ancillary services market interface and mileage benefits The total revenue pool amount is calculated using the following formula: .

[0044] Alternatively, smart contracts can automatically perform the following operations: The electricity market, capacity ancillary services market, and mileage market in which the transformer substation participates will form a unified revenue pool in each settlement cycle. The system automatically settles and distributes incentives on-chain according to the parameters (Φ) of each device. The formula for calculating the total revenue pool is as follows: ; in, This represents the total electricity sales revenue obtained by the distribution area within the settlement period t through participation in electricity market transactions (such as medium- and long-term transactions and spot transactions), expressed in yuan. This represents the total capacity compensation revenue obtained by the transformer substation within the settlement period t through participation in the capacity ancillary services market (such as providing standby capacity), expressed in yuan. This represents the total mileage compensation revenue obtained by the substation area within the settlement period t through participation in the mileage ancillary services market (such as providing frequency modulation services), expressed in yuan. This represents the deviation assessment fee payable according to market rules within the settlement period t, due to the discrepancy between the actual operating power and the power won in the market bid. The unit is yuan. This represents the on-chain transaction fees paid within the settlement period t to maintain the operation of the blockchain network (such as transaction on-chaining and smart contract execution), expressed in yuan. This represents the total net income available for final distribution within the settlement period t, after deducting relevant fees from the transaction volume of multiple markets in the trading area. It is the total income pool amount, expressed in yuan.

[0045] The flexibility contribution value of each flexible resource node is calculated using the following formula for allocating weighting coefficients: ; in, This represents the flexibility contribution value of the i-th flexible resource node within the settlement period t. This value is a quantitative indicator calculated based on the node's multi-dimensional behavioral data (such as response time, availability, stability, etc.), used to comprehensively evaluate its contribution to the coordinated operation of the system. This represents the sum of the flexibility contribution values ​​of all n flexible resource nodes participating in revenue distribution within the distribution area; This indicates that the i-th node is in the total revenue pool. The distribution weight coefficient is determined by the proportion of the node's contribution value to the total contribution value of all nodes, ensuring that the distribution of benefits is positively correlated with the degree of contribution.

[0046] The revenue that each device should receive is calculated using the following formula: ; in, Indicates based on the assigned weight coefficient The calculated final revenue that the i-th flexible resource node should receive within the settlement period t is expressed in yuan. The standardized weighting coefficients are dimensionless, and their physical meaning represents the relative contribution of node i to the coordinated operation of the transformer area. (Unit: Yuan) The result after multiplying This represents the absolute profit amount (in yuan) that node i should receive based on the relative contribution ratio. The two are of the same dimension and conform to the economic logic of profit distribution.

[0047] Step S150: In the on-chain revenue pool, differentiated revenue weights are allocated to the corresponding flexible resource nodes according to each flexibility contribution value, so as to execute revenue clearing and on-chain settlement through smart contracts.

[0048] Among them, the differentiated revenue weight can refer to the weight based on each node. The calculated percentage of the revenue pool that the node should receive. The weighting calculation aims to ensure that nodes that contribute more receive a higher share of the revenue.

[0049] For example, the smart contract calculates the revenue distribution amount for each node using the following revenue distribution formula: ; in, The contribution value to the flexibility of node i. The sum of the contribution values ​​of all participating nodes. This represents the total amount in the revenue pool.

[0050] For example, after the smart contract completes the calculation, it automatically transfers the corresponding profit amount from the profit pool to the blockchain address of each node, and records key information such as the transaction hash, allocation time, and the amount allocated to each node on the blockchain for auditing and querying by regulatory nodes.

[0051] The profit distribution and on-chain settlement process is entirely executed automatically by smart contracts without human intervention, ensuring transparency, efficiency, and tamper-proof distribution.

[0052] Therefore, according to the above implementation method, the system first acquires behavioral data of each flexible resource node within the distribution area in multiple dimensions such as demand response, distribution area collaboration, and blockchain support. After data integrity verification and standardized preprocessing, the data is input into the flexibility contribution value calculation model to generate a unified quantitative indicator representing the value of resource behavior—the flexibility contribution value. Subsequently, based on this contribution value, the registered candidate node set is sorted, and nodes with higher contributions are selected as the candidate node set. Then, based on the candidate node sorting results, consensus nodes, backup nodes, and regulatory nodes are dynamically elected through VRF, and an on-chain consensus layer is constructed accordingly. This layer realizes the logical coupling and functional collaboration of the roles of election, consensus, accounting, and verification nodes through smart contracts. After the on-chain consensus layer verifies the consensus on multi-market revenue data, it creates an on-chain revenue pool based on heterogeneous revenue types such as energy, capacity, and mileage. Finally, differentiated revenue weights are calculated in the revenue pool based on the flexibility contribution value of each node, and the clearing logic and on-chain settlement are automatically executed through smart contracts.

[0053] Throughout the process, the technical solution of this invention addresses the problem of "disconnect between consensus mechanism and resource behavior" mentioned in the background technology by constructing a multi-dimensional flexible contribution value system. This system integrates the actual response behavior of devices, the collaborative value of the system, and the on-chain support capabilities into a unified quantitative indicator, achieving direct coupling between consensus weights and physical behavior. To address the problem of "single or missing contribution measurement dimensions," it introduces multi-dimensional quantifiable features such as response latency, fulfillment rate, and data integrity, forming an objective evaluation basis based on behavioral value and supporting differentiated incentives. To address the problem of "inability to support refined revenue distribution across multiple markets," it designs a weight allocation model centered on flexible contribution values, combining smart contracts to achieve dynamic, verifiable, and automated clearing of revenue pools across multiple markets, avoiding the crude mechanism of traditional static allocation based on electricity consumption or time. To address the problem of "insufficient fairness and resistance to manipulation in node elections," it adopts a dynamic election mechanism based on a combination of contribution value sorting and random functions, ensuring the decentralization, traceability, and high availability of the consensus group structure.

[0054] Therefore, the technical solution implemented above can solve the core technical problem that existing blockchain platforms are unable to achieve a closed-loop mapping from "resource behavior to consensus weight, and consensus weight to revenue incentive" in the context of power distribution area collaboration. This improves the fairness, transparency, and resource participation enthusiasm of power distribution area operations, and provides reliable technical support for the participation of various types of flexible loads in market transactions.

[0055] In some embodiments, each multidimensional behavioral data includes response mileage, response latency, tracking accuracy, available state percentage, historical fulfillment rate, event participation, data reporting completeness, and consensus participation activity for the corresponding operational behavior; the multidimensional behavioral data is preprocessed to obtain the flexibility contribution value of each flexible resource node, including: The response mileage, response latency, and tracking accuracy of each operational behavior are normalized and mapped to obtain the demand response dimension indicators.

[0056] Specifically, the system can use the minimum-maximum scaling method to perform normalization mapping, that is, the system linearly transforms the original data to the [0,1] interval, eliminating the difference in dimensions and unifying the order of magnitude; For example, if the original response delay value is [0, 300] seconds, the normalization formula is: ; If the actual latency of a node is 150 seconds, then the normalized value is 0.5.

[0057] Among them, response mileage refers to the absolute integral value of the deviation between the actual power and the commanded power of the node within the response period, and the unit is kilowatt-hour (kWh); response delay refers to the time interval from the issuance of the command to the start of the node's response, and the unit is seconds; tracking accuracy refers to the root mean square error (RMSE) between the actual power and the commanded power, and the unit is kilowatt (kW).

[0058] The available state percentage, historical fulfillment rate, and event participation of each operational behavior are normalized and mapped to obtain the regional collaboration dimension indicators.

[0059] For example, the availability percentage refers to the percentage of time a node is in a schedulable state out of the total runtime. For instance, if an energy storage device is available for 20 hours in a 24-hour operating cycle, the availability percentage is 83.3%. The historical fulfillment rate refers to the ratio of the number of times a node actually completes scheduling to the total number of scheduling tasks. For instance, if a charging pile participates in 10 scheduling tasks and successfully completes 8 of them, the fulfillment rate is 80%. The event participation rate refers to the proportion of times a node participates in key scheduling events (such as peak-valley regulation and frequency response) out of the total number of events. For instance, if a platform area initiates 5 peak-shaving events and a photovoltaic node participates in 3 of them, the event participation rate is 60%.

[0060] The data reporting completeness and consensus participation activity of each operational behavior are normalized and mapped to generate on-chain support dimension indicators.

[0061] Specifically, data reporting completeness refers to the ratio of the number of times a node successfully uploads data to the total number of times it needs to upload data. For example, if a node needs to report data 24 times a day and actually successfully reports data 23 times, then the completeness is 95.8%. Consensus participation activity refers to the proportion of consensus rounds that a node successfully participates in in the blockchain network. For example, if a node successfully participates in 90 out of 100 consensus rounds, then the activity is 90%.

[0062] The flexibility contribution value is obtained by performing aggregate calculations on the demand response dimension indicators, the transformer area collaboration dimension indicators, and the on-chain support dimension indicators.

[0063] For example, the system can assign weight coefficients to three dimensions, such as a weight of 0.5 for demand response, a weight of 0.3 for transformer area collaboration, and a weight of 0.2 for on-chain support, and calculate the contribution value using a weighted summation formula: Flexibility contribution = 0.5 × Demand response score + 0.3 × Substation coordination score + 0.2 × On-chain support score; If a node scores 0.8, 0.9, and 0.7 in the three dimensions respectively, then its contribution value is 0.8×0.5+0.9×0.3+0.7×0.2=0.81.

[0064] Specifically, the system can dynamically adjust the weighting coefficients based on actual business needs, and achieve transparency and auditability of the calculation process through smart contracts.

[0065] Therefore, according to the above implementation method, the system can generate an objective, quantitative and verifiable flexibility contribution value by standardizing and weighting the multidimensional behavioral data, providing a reliable basis for subsequent consensus node election and benefit distribution, while ensuring that the evaluation process takes into account physical response performance, system collaborative value and on-chain support capabilities.

[0066] In some embodiments, the candidate node set consists of all flexible resource nodes that have completed on-chain registration and resource authentication; the registered candidate node set is sorted according to each flexibility contribution value to obtain the candidate node ranking result, including: Read the registration identifier and authentication status recorded in the distributed ledger of the blockchain network.

[0067] Among them, the registration identifier refers to the unique identity identifier of a node in the blockchain network (such as a 64-bit hexadecimal string generated by a hash algorithm), and the authentication status refers to whether the node has passed the security verification, capability verification and compliance review set by the platform (such as passing CA certificate verification and resource capability audit), and is recorded in the status field of the distributed ledger (such as "authenticated" or "unauthenticated").

[0068] Nodes that are unregistered or whose authentication has expired are removed from the registration identifier and authentication status to obtain the candidate pool.

[0069] Specifically, the system can automatically traverse the node status list in the ledger through smart contracts, filter out nodes with an authentication status of "valid" and a registration time within the validity period, and exclude nodes that are not registered (without a registration identifier), have expired authentication, or have had their qualifications revoked.

[0070] For example, if a certain distribution area has 50 flexible resource nodes, and 5 of them are marked as "invalid" due to expired certificates or failed capability verification, then the candidate pool contains 45 valid nodes.

[0071] For each flexible resource node in the candidate pool, the flexibility contribution value is called, and the candidate nodes are sorted in descending order according to the flexibility contribution values ​​to generate the candidate node ranking result.

[0072] For example, the system can retrieve the latest calculated Φ for each node from a distributed database or on-chain storage and sort them numerically. For instance, if the flexibility contribution values ​​of nodes A, B, and C in the candidate pool are 0.92, 0.85, and 0.78 respectively, the descending sort result would be: Node A (0.92), Node B (0.85), Node C (0.78). This sorting result will serve as the direct basis for subsequent consensus node elections.

[0073] Therefore, according to the above implementation method, the system can quickly construct a set of trustworthy candidate nodes through automated on-chain data reading and state verification, and achieve fairness, transparency and traceability of the sorting process based on objectively quantified flexibility contribution values, providing a reliable and efficient input basis for subsequent consensus node election.

[0074] In some embodiments, consensus nodes, backup nodes, and supervisory nodes are elected based on the candidate node ranking results, and an on-chain consensus layer is created based on the consensus nodes, backup nodes, and supervisory nodes, including: The candidate node ranking results are input into a set verifiable random function to calculate the consensus node identity set.

[0075] Specifically, the system can take the sorted list of candidate nodes (such as the top 30 nodes) and the current block hash value as input, generate a random index using the VRF algorithm, and select a fixed number (such as 7) of nodes as consensus nodes. For example, if the VRF output index is [3,15,8,22,5,11,19], then the nodes at the corresponding positions in the sorted list are selected to form the consensus node identity set.

[0076] Candidate nodes that were not selected for the consensus node identity set are replaced in order of their flexibility contribution value to generate a backup node identity set.

[0077] For example, the system can select several nodes (such as the top 5) from the remaining candidate nodes according to their flexibility contribution value from high to low as backup nodes. For instance, if the consensus node identity set has occupied 7 nodes, the system can select the 5 nodes with the highest contribution value (such as the nodes ranked 8th, 9th, 10th, 11th, and 12th) from the remaining 23 nodes as backup nodes to take over the work of the consensus node in case of failure.

[0078] Write the consensus node identity set, the backup node identity set, and the regulatory node identity set into the same block to trigger the smart contract to complete the node role initialization and generate the on-chain consensus layer.

[0079] Among them, the regulatory node identity set can be directly written into the pre-authorized node list of the blockchain by authorized institutions (such as power grid operators or regulatory agencies) through digital signatures, and has audit and supervision permissions. After receiving the above three types of node identity sets, the smart contract automatically assigns them the corresponding role permissions (such as the block packaging right of consensus nodes, the standby status mark of standby nodes, and the read-only audit right of regulatory nodes), and completes the logical construction and state synchronization of the on-chain consensus layer.

[0080] Therefore, according to the above implementation method, the system can ensure the fairness of the election through a verifiable random function, realize the reasonable replacement of backup nodes by combining contribution value sorting, and complete the role initialization automatically through smart contracts. Finally, a decentralized, highly available and clearly defined on-chain consensus layer is built, providing a reliable consensus foundation for the collaborative operation of the distribution area.

[0081] In some embodiments, heterogeneous revenue includes energy revenue, capacity revenue, and mileage revenue generated across multiple market cycles; after consensus verification by the on-chain consensus layer, an on-chain revenue pool is created based on the defined heterogeneous revenue, including: By normalizing the energy gains, capacity gains, and mileage gains, a set of gains with unified dimensions is obtained.

[0082] Specifically, the normalization mapping uses the minimum-maximum scaling method to linearly transform the original revenue data to the [0,1] interval, eliminating dimensional differences and unifying the order of magnitude; For example, if the original value of the energy gain is [0, 10000] yuan, the normalization formula can be as follows: ; If the actual energy gain of a node is 5000 yuan, then the normalized value is 0.5.

[0083] Among them, energy revenue refers to the revenue obtained by a node through electricity trading in the electricity market, and the unit is yuan; capacity revenue refers to the revenue obtained by a node through providing standby capacity in the capacity market, and the unit is yuan; mileage revenue refers to the revenue obtained by a node through providing frequency regulation services in the ancillary services market, and the unit is yuan.

[0084] The revenue pool is written into the same block, and after consensus verification by the on-chain consensus layer, a smart contract is triggered to create an on-chain revenue pool.

[0085] For example, the system writes the normalized revenue set into the same block in the blockchain network, and after consensus verification by the on-chain consensus layer, triggers the smart contract to automatically create an on-chain revenue pool. For instance, if a certain substation has an energy revenue of 5000 yuan, a capacity revenue of 3000 yuan, and a mileage revenue of 2000 yuan in a certain settlement cycle, then the normalized revenue set is [0.5, 0.3, 0.2]. After being written into the block and verified by consensus, the smart contract automatically creates an on-chain revenue pool and stores the revenue set in the pool.

[0086] Therefore, according to the above implementation method, the system can construct a unified revenue set by normalizing the revenue from multiple markets and verifying it with on-chain consensus, and automatically create an on-chain revenue pool through smart contracts to ensure the credibility, transparency and traceability of revenue data, providing a reliable data foundation for subsequent revenue distribution.

[0087] In some embodiments, the steps of smart contract execution of revenue distribution and on-chain settlement include: Read the yield set of the on-chain yield pool and the flexibility contribution value of each flexible resource node.

[0088] The revenue set refers to a collection of multi-market revenue data stored in a specific blockchain address after being verified through on-chain consensus. This includes normalized values ​​of energy revenue, capacity revenue, and mileage revenue. The flexibility contribution value Φ is a quantitative indicator representing the comprehensive contribution of nodes, calculated from multi-dimensional behavioral data. Smart contracts read the above data by calling blockchain interfaces (such as Web3.js or the FISCO BCOS SDK).

[0089] The revenue set is weighted according to the contribution value of each flexibility level to obtain the revenue share of each flexible resource node.

[0090] For example, the system uses a weighted allocation formula: Calculate the assigned weight for each node (e.g., the weight of node A). The weights are multiplied by the total revenue to obtain the share of revenue that each node should receive (e.g., the share of revenue for node A). (yuan), thereby enabling the weighting of the revenue set based on the contribution value of each flexibility.

[0091] Specifically, smart contracts can use a weighted allocation algorithm to calculate the revenue share of each node. The specific calculation formula for the weighted allocation algorithm is as follows: ; in, This represents the flexibility contribution value of node i. This represents the sum of the flexibility contribution values ​​of all participating nodes. The total revenue amount is the cumulative value of energy, capacity, and mileage revenue in the on-chain revenue pool. For example, if the total revenue amount is 10,000 yuan, node A's flexibility contribution value is 0.8, and the sum of the contribution values ​​of all nodes is 40, then node A's share of the revenue is (0.8 / 40) × 10,000 = 200 yuan.

[0092] Each party's share of the profits is written to the corresponding node account, and the profit distribution log is recorded in the block to complete the on-chain settlement.

[0093] Specifically, the smart contract transfers the calculated share of profits to the blockchain addresses of each node (such as Ethereum addresses or FISCO BCOS accounts) and records the allocation details in the current block, including fields such as allocation time, node identifier, profit type, amount, and transaction hash, ensuring that the entire process is auditable and tamper-proof. For example, if a settlement involves 50 nodes, the smart contract completes the fund transfer for all accounts within 5 seconds and generates an allocation log containing 50 detailed entries in the block.

[0094] Therefore, according to the above implementation method, the system can automatically execute revenue distribution and settlement through smart contracts, ensuring that the distribution process is efficient, transparent and fair. This effectively solves the problems of inefficiency, lack of transparency and susceptibility to tampering in traditional centralized settlement mechanisms, and enhances the trust and enthusiasm of resources in the region to participate in multi-market transactions.

[0095] In some embodiments, after performing revenue distribution and on-chain settlement, the above method further includes: Perform hash digest calculations on the consensus node identities, election random numbers, revenue distribution records, and node behavior logs in the distributed ledger to obtain the evidence hash.

[0096] Specifically, the hash digest calculation employs a cryptographic hash algorithm (such as SHA-256) to generate a fixed-length (e.g., 256-bit) unique digital fingerprint (i.e., evidence hash) using the aforementioned key data as input. For example, the system concatenates consensus node identities (e.g., a list of node IDs), election random numbers (VRF output values), revenue distribution records (a list of revenue amounts for each node), and node behavior logs (e.g., response time, performance status, etc.) into a raw data string, and calculates a unique evidence hash value (e.g., "a1b2c3d4e5f6...") using a hash function. This process ensures data integrity and tamper-proofness. The evidence hash uses the SHA-256 cryptographic hash algorithm to perform a digest calculation on the consensus node identities, election random numbers, revenue distribution records, and node behavior logs in the distributed ledger to generate a fixed-length digital fingerprint. After being written into the ledger, the original data can be retrieved by the monitoring node to recalculate the hash value for comparison and verification. If the two match, it proves that the data has not been tampered with, thereby achieving traceability and compliance auditing of abnormal behavior.

[0097] The evidence hash is written into the distributed ledger to complete the on-chain evidence storage operation, which is then used by regulatory nodes for compliance verification and tracking of abnormal behavior.

[0098] For example, a smart contract automatically writes the proof hash into a specific storage field (such as "proofHash") of the current block and triggers the block confirmation process. Regulatory nodes can verify the randomness of historical consensus node elections, the fairness of revenue distribution, and the compliance of node behavior by querying the proof hash in the distributed ledger. For instance, if a node is accused of malicious behavior, the regulatory node can retrieve the original data corresponding to the proof hash and verify whether the data has been tampered with by reverse hashing, thereby achieving precise tracing of abnormal behavior.

[0099] Therefore, according to the above implementation method, the system can solidify key operation records through cryptographic hashing technology, forming an immutable on-chain evidence, providing a transparent and reliable data foundation for supervision, and effectively enhancing the system's compliance, auditability, and security reliability.

[0100] Figure 2 This is a structural block diagram of an on-chain consensus and revenue distribution system for flexible resources in a distribution area according to an embodiment of the present invention.

[0101] like Figure 2 As shown, the on-chain consensus and revenue distribution system for the flexible resources in this area includes: The flexibility contribution measurement module 210 is used to acquire multi-dimensional behavioral data of each flexible resource node in the transformer area, and to preprocess the multi-dimensional behavioral data to obtain the flexibility contribution value of each flexible resource node.

[0102] The candidate node sequence generation module 220 is used to sort the registered candidate node set according to each flexibility contribution value to obtain the candidate node sorting result.

[0103] The on-chain consensus layer generation module 230 is used to elect consensus nodes, backup nodes and regulatory nodes according to the candidate node ranking results, and to create an on-chain consensus layer based on the consensus nodes, backup nodes and regulatory nodes. The on-chain consensus layer includes the role relationships of election, consensus, accounting and verification nodes coupled through smart contract logic in the blockchain network.

[0104] The on-chain yield pool generation module 240 is used to create an on-chain yield pool based on the set heterogeneous yield after consensus verification by the on-chain consensus layer.

[0105] The on-chain consensus and revenue distribution module 250 is used to allocate differentiated revenue weights to corresponding flexible resource nodes in the on-chain revenue pool based on each flexibility contribution value, so as to automatically execute revenue clearing and on-chain settlement through smart contracts.

[0106] The specific functions and examples of each module and submodule of the device in this embodiment of the invention can be found in the relevant descriptions of the corresponding steps in the above method embodiments, and will not be repeated here.

[0107] According to embodiments of the present invention, the above-described method of the present invention can be applied to an electronic device and a readable storage medium.

[0108] Figure 3 A schematic block diagram of an example electronic device 600 that can be used to implement embodiments of the present invention is shown. The electronic device is intended to represent various forms of digital computers, such as laptop computers, desktop computers, workstations, personal digital assistants, servers, blade servers, mainframe computers, and other suitable computers. The electronic device may also represent various forms of mobile devices, such as personal digital assistants, cellular phones, smartphones, wearable devices, and other similar computing devices. The components shown herein, their connections and relationships, and their functions are merely illustrative and are not intended to limit the implementation of the invention described and / or claimed herein.

[0109] like Figure 3 As shown, the electronic device 600 includes a computing unit 601, which can perform various appropriate actions and processes based on a computer program stored in a read-only memory (ROM) 602 or a computer program loaded from a storage unit 608 into a random access memory (RAM) 603. The RAM 603 may also store various programs and data required for the operation of the electronic device 600. The computing unit 601, ROM 602, and RAM 603 are interconnected via a bus 604. An input / output (I / O) interface 605 is also connected to the bus 604.

[0110] Multiple components in electronic device 600 are connected to I / O interface 605, including: input unit 606, such as keyboard, mouse, etc.; output unit 607, such as various types of displays, speakers, etc.; storage unit 608, such as disk, optical disk, etc.; and communication unit 609, such as network card, modem, wireless transceiver, etc. Communication unit 609 allows electronic device 600 to exchange information / data with other devices through computer networks such as the Internet and / or various telecommunications networks.

[0111] The computing unit 601 can be various general-purpose and / or special-purpose processing components with processing and computing capabilities. Some examples of the computing unit 601 include, but are not limited to, a central processing unit (CPU), a graphics processing unit (GPU), various special-purpose artificial intelligence (AI) computing chips, various computing units running machine learning model algorithms, a digital signal processor (DSP), and any suitable processor, controller, microcontroller, etc. The computing unit 601 performs the various methods and processes described above, such as an on-chain consensus and revenue distribution method for flexible resources in a distribution area. For example, in some embodiments, an on-chain consensus and revenue distribution method for flexible resources in a distribution area can be implemented as a computer software program, which is tangibly contained in a machine-readable medium, such as storage unit 608. In some embodiments, part or all of the computer program can be loaded and / or installed on electronic device 600 via ROM 602 and / or communication unit 609. When the computer program is loaded into RAM 603 and executed by the computing unit 601, one or more steps of the on-chain consensus and revenue distribution method for flexible resources in a distribution area described above can be performed. Alternatively, in other embodiments, computing unit 601 may be configured by any other suitable means (e.g., by means of firmware) to perform an on-chain consensus and revenue distribution method for flexible resources in a distribution area.

[0112] Various embodiments of the systems and techniques described above herein can be implemented in digital electronic circuit systems, integrated circuit systems, field-programmable gate arrays (FPGAs), application-specific integrated circuits (ASICs), application-specific standard products (ASSPs), systems-on-a-chip (SoCs), payload-programmable logic devices (CPLDs), computer hardware, firmware, software, and / or combinations thereof. These various embodiments may include implementations in one or more computer programs that can be executed and / or interpreted on a programmable system including at least one programmable processor, which may be a dedicated or general-purpose programmable processor, capable of receiving data and instructions from a storage system, at least one input device, and at least one output device, and transmitting data and instructions to the storage system, the at least one input device, and the at least one output device.

[0113] The program code used to implement the methods of the present invention can be written in any combination of one or more programming languages. This program code can be provided to a processor or controller of a general-purpose computer, special-purpose computer, or other programmable data processing device, such that when executed by the processor or controller, the program code causes the functions / operations specified in the flowcharts and / or block diagrams to be implemented. The program code can be executed entirely on the machine, partially on the machine, as a standalone software package partially on the machine and partially on a remote machine, or entirely on a remote machine or server.

[0114] In the context of this invention, a machine-readable medium can be a tangible medium that may contain or store a program for use by or in conjunction with an instruction execution system, apparatus, or device. A machine-readable medium can be a machine-readable signal medium or a machine-readable storage medium. Machine-readable media can be, but is not limited to, electronic, magnetic, optical, electromagnetic, infrared, or semiconductor systems, apparatus, or devices, or any suitable combination of the foregoing. More specific examples of machine-readable storage media include electrical connections based on one or more wires, portable computer disks, hard disks, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), optical fibers, portable compact disk read-only memory (CD-ROM), optical storage devices, magnetic storage devices, or any suitable combination of the foregoing.

[0115] To provide interaction with a user, the systems and techniques described herein can be implemented on a computer having: a display device (e.g., a CRT or LCD monitor) for displaying information to the user; and a keyboard and pointing device (e.g., a mouse or trackball) through which the user provides input to the computer. Other types of devices can also be used to provide interaction with the user; for example, feedback provided to the user can be any form of sensory feedback (e.g., visual, auditory, or tactile feedback); and input from the user can be received in any form (including sound input, voice input, or tactile input).

[0116] The systems and technologies described herein can be implemented in computing systems that include back-end components (e.g., as a data server), or computing systems that include middleware components (e.g., an application server), or computing systems that include front-end components (e.g., a user computer with a graphical user interface or web browser through which a user can interact with implementations of the systems and technologies described herein), or any combination of such back-end, middleware, or front-end components. The components of the system can be interconnected via digital data communication of any form or medium (e.g., a communication network). Examples of communication networks include local area networks (LANs), wide area networks (WANs), and the Internet.

[0117] Computer systems can include clients and servers. Clients and servers are generally located far apart and typically interact via communication networks. Client-server relationships are created by computer programs running on the respective computers and having a client-server relationship with each other. Servers can be cloud servers, servers in distributed systems, or servers incorporating blockchain technology.

[0118] It should be understood that the various forms of processes shown above can be used to reorder, add, or delete steps. For example, the steps described in this invention can be executed in parallel, sequentially, or in different orders, as long as the desired result of the technical solution disclosed in this invention can be achieved, and this is not limited herein.

[0119] The specific embodiments described above do not constitute a limitation on the scope of protection of this invention. Those skilled in the art should understand that various modifications, combinations, and substitutions can be made according to design requirements and other factors. Any modifications, equivalent substitutions, and improvements made within the principles of this invention should be included within the scope of protection of this invention.

Claims

1. A method for on-chain consensus and revenue distribution of flexible resources in a distribution area, characterized in that, include: Acquire multidimensional behavioral data of each flexible resource node within the transformer area, and preprocess the multidimensional behavioral data to obtain the flexibility contribution value of each flexible resource node. The flexibility contribution value is obtained by normalizing and aggregating the multi-dimensional behavioral data through demand response dimension, platform collaboration dimension, and on-chain support dimension. The multi-dimensional behavioral data includes the response mileage, response latency, tracking accuracy, available state ratio, historical fulfillment rate, event participation degree, data reporting completeness, and consensus participation activity of the corresponding operating behavior. The registered candidate node set is sorted according to the flexibility contribution value of each node to obtain the candidate node ranking result. Consensus nodes, backup nodes, and oversight nodes are elected based on the candidate node ranking results. An on-chain consensus layer is then created based on these nodes, including the consensus nodes, backup nodes, and oversight nodes. This on-chain consensus layer comprises the roles of election, consensus, accounting, and verification nodes coupled through smart contract logic within the blockchain network. Specifically, it includes: The candidate node ranking results are input into a set verifiable random function to calculate the consensus node identity set; Candidate nodes that were not selected into the consensus node identity set are replaced in order of their flexibility contribution values ​​to generate a backup node identity set. The consensus node identity set, the backup node identity set, and the regulatory node identity set are written into the same block, triggering a smart contract to complete node role initialization in order to generate the on-chain consensus layer. The regulatory node identity set is written by an authorized institution. After consensus verification by the on-chain consensus layer, an on-chain revenue pool is created based on the set heterogeneous revenue. In the on-chain revenue pool, differentiated revenue weights are allocated to the corresponding flexible resource nodes based on each flexibility contribution value, so as to execute revenue clearing and on-chain settlement through smart contracts.

2. The method according to claim 1, characterized in that, The preprocessing of the multidimensional behavioral data to obtain the flexibility contribution value of each flexible resource node includes: For each operational behavior, the response mileage, response latency, and tracking accuracy are normalized and mapped to obtain the demand response dimension indicators. The available status percentage, historical fulfillment rate, and event participation of each operational behavior are normalized and mapped to obtain the regional collaboration dimension indicators. The data reporting completeness and consensus participation activity of each operational behavior are normalized and mapped to generate on-chain support dimension indicators; The flexibility contribution value is obtained by performing aggregate calculations on the demand response dimension index, the transformer area collaboration dimension index, and the on-chain support dimension index.

3. The method according to claim 1 or 2, characterized in that, The candidate node set consists of all flexible resource nodes that have completed on-chain registration and resource authentication; the registered candidate node set is sorted according to the flexibility contribution value of each node to obtain the candidate node ranking result, including: Read the registration identifier and authentication status recorded in the distributed ledger of the blockchain network; Nodes that are unregistered or whose authentication has expired are removed from the registration identifiers and authentication statuses to obtain a candidate pool; For each flexible resource node in the candidate pool, the flexibility contribution value is called, and the candidate nodes are sorted in descending order according to the flexibility contribution values ​​to generate the candidate node sorting result.

4. The method according to claim 1, characterized in that, The heterogeneous revenue includes energy revenue, capacity revenue, and mileage revenue generated across multiple market cycles; the creation of an on-chain revenue pool based on the set heterogeneous revenue, after consensus verification by the on-chain consensus layer, includes: The energy gain, capacity gain, and mileage gain are normalized and mapped to obtain a set of gains with unified dimensions. The aforementioned revenue set is written into the same block, and after consensus verification by the on-chain consensus layer, a smart contract is triggered to create an on-chain revenue pool.

5. The method according to claim 1, characterized in that, The steps of the smart contract execution revenue distribution and on-chain settlement include: Read the revenue set of the on-chain revenue pool and the flexibility contribution value of each flexible resource node; The revenue set is weighted according to the flexibility contribution value of each node to obtain the revenue share of each flexible resource node. Write each party's share of the profits to the corresponding node account and record the profit distribution log in the block to complete the on-chain settlement.

6. The method according to claim 3, characterized in that, After performing revenue distribution and on-chain settlement, the method further includes: Perform hash digest calculations on the consensus node identities, election random numbers, revenue distribution records, and node behavior logs in the distributed ledger to obtain the evidence storage hash; The evidence hash is written into the distributed ledger to complete the on-chain evidence storage operation for regulatory nodes to perform compliance verification and trace abnormal behavior.

7. An on-chain consensus and revenue distribution system for flexible resources in a distribution area, characterized in that, include: The flexibility contribution measurement module is used to acquire multi-dimensional behavioral data of each flexible resource node within the distribution area, and preprocess the multi-dimensional behavioral data to obtain the flexibility contribution value of each flexible resource node. The flexibility contribution value is obtained by normalizing and aggregating the multi-dimensional behavioral data through demand response dimension, distribution area collaboration dimension, and on-chain support dimension. The multi-dimensional behavioral data includes the response mileage, response latency, tracking accuracy, available state ratio, historical fulfillment rate, event participation degree, data reporting completeness, and consensus participation activity of the corresponding operating behavior. The candidate node sequence generation module is used to sort the registered candidate node set according to each of the aforementioned flexibility contribution values ​​to obtain the candidate node sorting result; The on-chain consensus layer generation module is used to elect consensus nodes, backup nodes, and supervisory nodes based on the candidate node ranking results, and to create an on-chain consensus layer based on the consensus nodes, backup nodes, and supervisory nodes. The on-chain consensus layer includes the role relationships of election, consensus, accounting, and verification nodes coupled through smart contract logic within the blockchain network; specifically, it includes: The candidate node ranking results are input into a set verifiable random function to calculate the consensus node identity set; Candidate nodes that were not selected into the consensus node identity set are replaced in order of their flexibility contribution values ​​to generate a backup node identity set. The consensus node identity set, the backup node identity set, and the regulatory node identity set are written into the same block, triggering a smart contract to complete node role initialization in order to generate the on-chain consensus layer. The regulatory node identity set is written by an authorized institution. The on-chain yield pool generation module is used to create an on-chain yield pool based on the set heterogeneous yield after consensus verification by the on-chain consensus layer. The on-chain consensus and revenue distribution module is used to allocate differentiated revenue weights to the corresponding flexible resource nodes in the on-chain revenue pool according to the flexibility contribution value of each node, so as to automatically execute revenue clearing and on-chain settlement through smart contracts.

8. An electronic device, characterized in that, include: At least one processor; as well as The memory that is communicatively connected to the at least one processor; The memory stores instructions that can be executed by the at least one processor to enable the at least one processor to perform the method of any one of claims 1-6.

9. A non-transitory computer-readable storage medium storing computer instructions, characterized in that, Computer instructions are used to cause a computer to perform the method according to any one of claims 1-6.

Images