Blockchain-based distributed power transaction settlement method and system

Abstract

This invention discloses a distributed power trading settlement method and system based on blockchain, belonging to the field of blockchain trading and settlement technology. The method includes: collecting multi-source power data to construct original data units; generating verification status levels and verification credentials for each level through three layers of verification: format signature, multi-source consistency, and time continuity; allocating transaction payloads to three encrypted containers (complete transaction, deviation settlement, and invalid transaction) according to their levels and storing them accordingly; constructing a block header containing the evidence root of the credential aggregation and the three Merkle tree roots of the three transaction segments; combining the blocks and broadcasting them to the blockchain network to complete the settlement and on-chain processing of distributed power trading. This invention solves the technical problem that existing power trading settlement data verification and storage methods cannot accurately identify and process transaction data of different qualities, achieving layered verification and hierarchical storage of power trading data, improving the reliability and processing efficiency of settlement data, and ensuring the traceability of transaction data.

Description

Technical Field

[0001] This invention relates to the field of blockchain transaction and settlement technology, and in particular to a distributed power transaction and settlement method and system based on blockchain. Background Technology

[0002] Distributed power trading has become an important direction for the development of the power market. Blockchain, with its immutable and traceable characteristics, is widely used in power trading settlement scenarios. Existing blockchain power settlement solutions mostly adopt a unified storage and verification model. However, distributed power data comes from diverse sources, easily leading to problems such as format anomalies, multi-source data conflicts, and time-series gaps. Traditional technologies lack targeted hierarchical verification mechanisms, failing to accurately distinguish between normal, skewed, and invalid transactions. Unified encrypted storage of all data not only consumes on-chain resources and results in low settlement efficiency, but also suffers from loose binding between verification credentials and transaction data, making it difficult to clear and trace abnormal transactions. This fails to meet the actual needs of accurate verification, hierarchical management, and efficient settlement in distributed power trading. Summary of the Invention

[0003] This application provides a blockchain-based distributed power trading settlement method and system, which solves the technical problem that existing power trading settlement data verification and storage methods cannot accurately identify and process transaction data of different quality.

[0004] The first aspect of this application provides a blockchain-based distributed power trading settlement method, the method comprising: collecting power data from different physical sources to construct raw data units; performing hierarchical verification on the raw data units to establish a structured verification description vector, the hierarchical verification including format signature verification, multi-source consistency verification, and time continuity verification; generating verification data for each transaction based on the structured verification description vector, the verification data including a verification status level and verification credentials at each level; allocating the transaction payload associated with the raw data units to different encrypted containers and locating storage segments using the verification status level, wherein the first verification status level corresponds to the complete transaction segment of the block body, the second verification status level corresponds to the deviation settlement segment of the block body, and the third verification status level corresponds to the invalid transaction segment of the block body; constructing a block header, the block header including an evidence root generated by aggregating the verification credentials by verification layer, a Merkel tree root corresponding to three Merkel subtrees constructed from the complete transaction segment, the deviation settlement segment, and the invalid transaction segment, and an encryption suite identifier; combining the block header with the block body containing the encrypted containers to form a block, and broadcasting the block to the blockchain network to complete the settlement and on-chaining of distributed power trading.

[0005] A second aspect of this application provides a blockchain-based distributed power trading and settlement system, comprising: a raw data unit construction module for collecting power data from different physical sources and constructing raw data units; a verification description vector construction module for performing hierarchical verification on the raw data units and establishing a structured verification description vector, wherein the hierarchical verification includes format signature verification, multi-source consistency verification, and time continuity verification; a verification data generation module for generating verification data for each transaction based on the structured verification description vector, wherein the verification data includes a verification status level and verification credentials for each layer; and a storage segmentation and positioning module for using the verification status level to associate the transaction payloads of the raw data units. The blocks are allocated to different encrypted containers and their storage segments are located. The first verification status level corresponds to the complete transaction segment of the block body, the second verification status level corresponds to the deviation clearing segment of the block body, and the third verification status level corresponds to the invalid transaction segment of the block body. A block header construction module is used to construct the block header, which includes an evidence root generated by aggregating the verification credentials according to verification layers, Merkle tree roots corresponding to the three Merkle subtrees constructed from the complete transaction segment, deviation clearing segment, and invalid transaction segment, and a cryptographic suite identifier. A settlement and on-chain execution module is used to combine the block header with the block body containing the encrypted containers to form a block, and broadcast the block to the blockchain network to complete the settlement and on-chain execution of distributed power transactions.

[0006] One or more technical solutions provided in this application have at least the following technical effects or advantages: This application performs multi-dimensional verification processing on distributed power trading data to generate structured verification results. It classifies the trading data according to quality level and stores it in a differentiated manner. Through a customized block structure, it achieves a strong correlation between verification credentials and trading data, thereby completing the reliable settlement of distributed power trading. This makes the power trading settlement data more reliable and the processing efficiency higher. It achieves the technical effect of hierarchical verification and hierarchical storage of power trading data, improves the reliability and processing efficiency of settlement data, and ensures the traceability of trading data. Attached Figure Description

[0007] To more clearly illustrate the technical solutions in the embodiments of the present invention, the accompanying drawings used in the description of the embodiments will be briefly introduced below. Obviously, the accompanying drawings described below are only some embodiments of the present invention. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0008] Figure 1 This is a flowchart illustrating the blockchain-based distributed power trading settlement method provided in this application embodiment.

[0009] Figure 2This is a schematic diagram of the structure of a blockchain-based distributed power trading and settlement system provided in an embodiment of this application.

[0010] Figure labeling: 1. Original data unit construction module; 2. Verification description vector construction module; 3. Verification data generation module; 4. Storage segmentation and positioning module; 5. Block header construction module; 6. Settlement and on-chain execution module. Detailed Implementation

[0011] This application provides a blockchain-based distributed power trading settlement method and system, which solves the technical problem that existing power trading settlement data verification and storage methods cannot accurately identify and process transaction data of different quality.

[0012] The technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only a part of the embodiments of this application, and not all of them. All other embodiments obtained by those skilled in the art based on the embodiments of this application without creative effort are within the scope of protection of this application.

[0013] It should be noted that the terms "first," "second," etc., in the specification and accompanying drawings of this application are used to distinguish similar objects and are not necessarily used to describe a specific order or sequence. It should be understood that such data can be interchanged where appropriate so that the embodiments of this application described herein can be implemented in orders other than those illustrated or described herein. Furthermore, the terms "comprising" and "having," and any variations thereof, are intended to cover non-exclusive inclusion; for example, a process, method, system, product, or server that includes a series of steps or units is not necessarily limited to those steps or units explicitly listed, but may include other steps or modules not explicitly listed or inherent to such processes, methods, products, or devices.

[0014] Example 1, as Figure 1 As shown, a blockchain-based distributed power trading settlement method includes: Collect power data from different physical sources to construct raw data units.

[0015] In this embodiment, the original data unit is a standardized data set that integrates measured data from the power acquisition terminal, device identification, timestamp, and power grid topology information.

[0016] Specifically, when collecting power data from different physical sources, the first step is to collect output power, voltage, and current data from the generator side via smart metering terminals installed on the distributed power source side. The terminals use the Modbus-RTU protocol via an RS485 interface, sending collection messages to the data aggregation gateway at fixed intervals of 15 seconds. These messages include a unique device identifier, a millisecond-level timestamp, and the original measured values. Power is uniformly measured in kilowatts, voltage in volts, and current in amperes. Secondly, the second step is to collect power consumption, voltage, and current data from the consumer side via smart meters installed on the load side. These meters follow the DL / T645 communication protocol via an Ethernet interface, sending data in packets to the same data aggregation gateway at a preset collection cycle of one minute. The messages include the metering point number, collection time, and original sampled values, with the data units consistent with those on the generator side. Again, the transmission power, voltage, and current data of the power grid are collected by the feeder terminal equipment installed at key nodes of the power grid. In accordance with the power dedicated 104 protocol, the equipment sends the real-time monitoring data to the data aggregation gateway through the power dedicated communication network. The message contains the line number, node location identifier, and original measurement data, and the data unit follows a unified standard.

[0017] After receiving the three types of messages, the data aggregation gateway first performs message validity verification according to the corresponding communication protocol, discarding abnormal messages with incorrect formats or those failing verification. Then, it parses the compliant messages, extracting fields such as device identifier, timestamp, and measurement value. The gateway performs data alignment based on milliseconds. For example, data with a timestamp deviation exceeding 200 milliseconds is marked and temporarily stored. This marked and stored data does not participate in the subsequent hierarchical verification process and is transferred to an independent abnormal data processing channel. The remaining normal data is associated with the corresponding topology identifier according to the power grid's preset topology relationship. Finally, the device identifier, standard timestamp, normalized measurement data, and topology information are integrated to form a standardized and unified raw data unit, completing data acquisition and construction.

[0018] Layered verification is performed on the original data unit to establish a structured verification description vector. The layered verification includes format signature verification, multi-source consistency verification, and time continuity verification.

[0019] In this embodiment, the structured verification description vector is an ordered set of values ​​that integrates the three-layer verification results and is used to comprehensively determine the compliance status of power data.

[0020] Optionally, hierarchical verification is performed on the original data units, and a structured verification description vector is constructed. First, the first-level verification state is obtained by comparing data templates based on byte length, field type, and unit, and verifying device and gateway signatures. Then, a constraint channel containing node and line power constraints is built by combining the power topology relationship. The multi-source original data units are mapped to the channel to calculate the residual vector. Different residual components are decomposed and normalized and discretized to obtain the second-level verification state. Finally, the structured verification description vector is generated by combining the above two-level verification states and the third-level verification state. The specific implementation process of this step will be described in detail later.

[0021] Verification data for each transaction is generated based on the structured verification description vector. The verification data includes the verification status level and verification credentials at each level.

[0022] In one embodiment of this application, the verification status levels of each layer in the structured verification description vector are sequentially encoded to obtain a status code string. The verification credentials of each layer are hashed to obtain the corresponding hash value. The hash value is then combined with the verification timestamp and the verification node identifier to finally generate the verification data. The specific implementation process of this step will also be described in detail later.

[0023] The transaction payload associated with the original data unit is allocated to different encrypted containers and storage segments are located using the verification status level. The first verification status level corresponds to the complete transaction segment of the block body, the second verification status level corresponds to the deviation settlement segment of the block body, and the third verification status level corresponds to the invalid transaction segment of the block body.

[0024] In this embodiment, the transaction payload is the business data content transmitted along with the original data unit in a power business scenario. The encrypted container is a standardized data structure that encapsulates identification information and encrypted transaction data. The block body is the main part of a blockchain block that specifically stores various transactions and corresponding ancillary data.

[0025] Specifically, the structured verification description vector is first parsed, and the verification status level corresponding to the transaction is obtained according to the preset comprehensive judgment rules. When the first-level verification status is compliant and the second and third-level verification statuses are both low-level, it is determined to be the first verification status level, matching the fully private container type, and simultaneously locating the complete transaction segment within the block body. When the first-level verification status is compliant and the second or third level has a medium-level but no high-level, it is determined to be the second verification status level, matching the bias witness container type, and simultaneously locating the bias settlement segment within the block body. When the first-level verification status is non-compliant or any layer has a high-level, it is determined to be the third verification status level, matching the rejection proof container type, and simultaneously locating the invalid transaction segment within the block body. After completing the mapping and matching of verification level with container type and storage segment, the encryption and encapsulation process begins.

[0026] All encrypted containers adopt a unified three-segment field structure, which sequentially sets a container type identifier field, an encryption algorithm identifier field, and an encryption payload field. For example, the container type identifier field uses a 1-byte unsigned integer encoding, with a value of 1 for fully private containers, 2 for biased witness containers, and 3 for denial-of-proof containers, used to distinguish containers from different business categories. The encryption algorithm identifier field uses a 1-byte unsigned integer encoding, uniformly employing the SM4 symmetric encryption algorithm, with a corresponding encoding value of 16, used to specify the algorithm standard used for payload encryption. The encryption payload field is a variable-length field used to store the encrypted transaction payload ciphertext data.

[0027] During the encryption and encapsulation of the transaction payload, a 128-bit random symmetric key is generated. The original plaintext transaction payload is divided into 128-bit blocks, with the last block padded with PKCS7 if it is less than 128 bits. Using the SM4 algorithm in electronic cryptography mode, each block is encrypted sequentially to obtain complete ciphertext data. To ensure secure distribution and verification of the ciphertext, the random symmetric key is encrypted using an attribute-based encryption algorithm to generate key ciphertext. Based on the matched container type, the corresponding encoded value is written to the container type identifier field, and the encoded value corresponding to the SM4 algorithm is written to the encryption algorithm identifier field. The ciphertext data generated by SM4 encryption and the key ciphertext generated by attribute-based encryption are then written together to the encryption payload field, with the key ciphertext placed before the ciphertext data and separated by a length marker. This completes the assembly of a single encrypted container. The assembled encrypted containers are then written into their corresponding storage segments according to transaction time sequence, thus completing the hierarchical location storage of the transaction payload.

[0028] By implementing a verification level-driven container classification and segmented storage mechanism, hierarchical management and privacy protection of distributed power trading data are achieved, effectively improving the processing efficiency and storage security of transaction data within the block.

[0029] Construct a block header, which includes the evidence root generated by the aggregation of the verification credentials grouped by verification layer, the Merkle tree root corresponding to the three Merkle subtrees constructed by the complete transaction segment, the deviation clearing segment, and the invalid transaction segment, and the cryptographic suite identifier.

[0030] In this embodiment, the block header is a fixed data structure at the front end of the blockchain block, which stores core digests and related information such as hash value, Merkle root, and cryptographic identifier, and is used for chain connection and data integrity verification.

[0031] Specifically, by hierarchically aggregating three types of verification credentials and constructing Merkle trees for each layer, the credential root of each layer is obtained. The evidence root is generated by combining the hash of the previous block header. At the same time, Merkle trees are constructed for each of the three types of transaction storage segments to obtain each transaction root. All transaction roots and evidence roots are hashed together to obtain the verification transaction anchor hash. Finally, the cryptographic suite identifier is combined and written into the block header to achieve blockchain-style anchoring and lightweight verification of hierarchical data consistency. The specific implementation process of this step will be described in detail later.

[0032] The block header and the block body containing the encrypted container are combined into a block, and the block is broadcast to the blockchain network to complete the settlement and on-chaining of distributed power transactions.

[0033] Specifically, the following steps further describe the broadcast and network-wide synchronization process after block encapsulation. First, the assembled block header and integrated block body are concatenated end-to-end in a fixed order, with the block header first and the block body last, encapsulating the entire block into a big-endian binary byte stream format. The CRC32 checksum of the complete block data is calculated and appended to the end of the block. Simultaneously, the length and values ​​of each core field in the block header are checked to ensure they conform to preset specifications. Once the data is confirmed to be complete and error-free, the network-wide broadcast process is immediately triggered. The broadcast uses the TCP communication protocol to send the complete block data to all adjacent peer nodes in the locally maintained list of online authorized nodes. The online node list is updated in real-time via periodic heartbeat messages. Offline nodes that fail to respond to three consecutive heartbeats are automatically removed from the forwarding list to avoid invalid data transmission.

[0034] After receiving block data, each node in the network first reads the CRC32 checksum attached to the end of the block, re-performs the CRC32 operation on the received complete block data, and compares the result with the attached checksum. If they do not match, the data transmission is considered corrupted, the block is discarded, and no forwarding operation is performed. If they match, the previous block hash, root evidence, checksum-transaction anchor hash, and cryptographic suite identifier are extracted from the block header. The length and value range of each field are verified one by one to ensure they match the preset standards. At the same time, the hash index of the currently stored blocks is queried. If the hash of the current block already exists in the index, it is considered a duplicate block, and subsequent processing is terminated. If the field verification fails, the block is discarded, and the sending node is marked with an anomaly record. Nodes with three anomaly records are temporarily removed from the trusted forwarding list.

[0035] Upon receiving all verified and non-duplicate valid blocks, the receiving node immediately forwards the data to its maintained list of trusted neighboring nodes. During this forwarding process, the original binary format and content of the blocks remain unchanged, without any modifications. Through hop-by-hop forwarding, the block data gradually covers all online authorized nodes across the network, ensuring that all legitimate participating nodes can synchronously obtain the complete and latest block data.

[0036] After all nodes have received blocks, they store the valid blocks in their local write queue in ascending order of block height. Before performing the ledger write operation, an exclusive lock is placed on the local blockchain ledger file to prevent data corruption caused by concurrent writes. Then, the hash value of the block before the block to be written is verified to ensure it matches the hash value of the latest block in the local ledger. If they match, the block is appended to the end of the local blockchain ledger, and the exclusive lock is released after the write is complete. If multiple valid blocks are received at the same block height, the longest chain rule is followed, and the block with more valid transactions is selected as the main chain block and written to the ledger. The remaining blocks are marked as orphan blocks and stored in the local backup directory to ensure the consistency of ledger data across all nodes.

[0037] Through a complete process of standardized block encapsulation, multi-dimensional data verification, trusted hop-by-hop broadcasting, and orderly conflict handling, the distributed power transaction settlement block is ensured to be securely and consistently synchronized across the entire network, realizing trusted on-chain evidence storage and distributed retention of transaction settlement data.

[0038] Furthermore, the method provided in this application embodiment includes: The original data units are compared using data templates, including byte length, field type, and unit verification, to verify the device-side data signature and gateway signature, establishing a first-level verification state. A constraint channel, containing node power balance constraints and line power constraints, is established based on the power topology relationships corresponding to the original data units. This constraint channel describes the physical relationships between different data sources. Original data units from different physical sources are mapped to the constraint channel, and residual vectors are calculated. These residual vectors characterize the degree of deviation of multi-source data from physical constraints. The residual vectors are decomposed according to the constraint types within the constraint channel, establishing node power balance residual components, line power constraint residual components, and multi-source observation conflict residual components. Normalization processing is performed on each residual component, and interval discretization is performed according to a preset quantization interval to generate corresponding discrete residual levels, establishing a second-level verification state. A structured verification description vector is established based on the first-level and second-level verification states.

[0039] Specifically, when performing layered verification on the raw data units, the first layer is format signature verification. A unified data template is pre-configured, containing six fields: metering point identifier, timestamp, active power, reactive power, voltage, and current. For example, the metering point identifier is a 32-byte fixed-length string, the timestamp is an 8-byte unsigned integer using millisecond-level timing standards, and active power, reactive power, voltage, and current are each 4-byte single-precision floating-point numbers. The total length is limited to 128 to 256 bytes, with reserved optional extension fields. The units for physical quantities are uniformly kilowatts, kilovars, volts, and amperes. Each field of the raw data unit is compared one by one with the data template. Simultaneously, the device signature and gateway signature attached to the raw data unit are extracted, and SM2 signature verification is performed using the corresponding device public key and gateway public key, respectively. The device public key and gateway public key are pre-distributed to each aggregation gateway through the blockchain certificate management channel. When the byte length, field type, and unit all meet the template requirements and the dual signature verification passes, the first-level verification status is marked as compliant; if any one of them fails to meet the requirements, the first-level verification status is marked as non-compliant.

[0040] The second layer of multi-source consistency verification is then performed. Based on the pre-stored power topology table, all node and line information within the current acquisition area is extracted. A node power balance constraint is established for each node: the difference between the sum of the measured power of all incoming lines associated with that node and the sum of the measured power of all outgoing lines, as well as the sum of the measured power of the node's load, is zero. A line power constraint is established for each line: the difference between the measured power at the beginning and end of the line does not exceed the allowable line loss threshold, which is two percent of the rated power. All constraints are grouped by type to form constraint channels, with each constraint corresponding to a unique constraint number and constraint threshold.

[0041] Next, the raw data units from different physical sources are mapped to the corresponding input ports of the constraint channels according to the measurement point locations. The actual difference of each constraint is calculated one by one to form an initial residual vector. The initial residual vector is then decomposed into components according to the constraint type: residual values ​​belonging to nodal power balance constraints are collected as nodal power balance residual components, and residual values ​​belonging to line power constraints are collected as line power constraint residual components. For the maximum absolute difference between the measured values ​​of the same physical quantity from different physical sources at the same measurement point within the same time window, it is collected as a multi-source observation conflict residual component.

[0042] Range normalization is performed on the three types of residual components. The range normalization calculation method is to subtract the minimum value of the current component from its value, then divide by the difference between the maximum and minimum values ​​of the component. This maps the values ​​of each component to a uniform range of 0 to 1. Three preset quantization intervals are set, as detailed in Table 1. The normalized residual components are mapped to their corresponding discrete residual levels according to the quantization interval they fall into. Then, the node power balance residual level, line power constraint residual level, and multi-source observation conflict residual level are sequentially concatenated into a triplet as the second-level verification status output.

[0043] Table 1: Correspondence between residual component quantization interval and deviation level

[0044] Finally, the original data units are sorted sequentially according to a preset sliding time window to construct a continuous time series vector. By calculating the rate of change and missing ratio of adjacent data within the vector, a time continuity residual vector is obtained to characterize the degree of time series anomaly. This residual vector is normalized and mapped according to a preset quantization interval to obtain a discrete continuity level to form the third layer of verification state. Finally, the first and second layer verification states are combined to construct a structured verification description vector. The specific implementation process of this step will be described in detail later.

[0045] The first-level format verification is achieved by comparing the device signature verification with the data template. Combined with the residual calculation, component decomposition and normalization discretization processing of the power topology constraint channel, the quantitative and hierarchical verification of the physical consistency of multi-source power data is realized.

[0046] Furthermore, the method provided in this application embodiment includes: The original data units are arranged in chronological order according to a preset sliding time window to construct a continuous time series vector; the rate of change and missing ratio of adjacent data units within the continuous time series vector are calculated to establish a time continuity residual vector, which is used to characterize the temporal continuity and anomaly degree of the data; the time continuity residual vector is normalized and mapped to discrete continuity levels according to a preset quantization interval to generate a third-level verification state; a structured verification description vector is established based on the first-level verification state, the second-level verification state, and the third-level verification state.

[0047] Optionally, the preset sliding time window duration is five minutes, the sliding step size is one minute, and the time base is consistent with the millisecond-level timestamps of the original data units. For each measurement point, all original data units within the corresponding time period are retrieved and sorted in ascending order according to their timestamp values. Original data units within a specified time range are progressively extracted along the time axis with a fixed sliding step size. The original data units within each sliding window are arranged sequentially in chronological order to construct a continuous time series vector for the corresponding measurement point.

[0048] Next, the active power and voltage values ​​of the core physical quantities are extracted from each original data unit within the continuous time series vector. The relative rate of change of the same physical quantity between adjacent original data units is calculated sequentially. The relative rate of change is calculated by subtracting the value of the physical quantity from the value of the preceding data unit, dividing the difference by the absolute value of the preceding data unit's physical quantity, and obtaining the relative rate of change for a single pair of adjacent data. All adjacent data pairs within the window are traversed, and the maximum value among all relative rates of change is taken as the time-series abrupt change characteristic value. Based on the preset acquisition period of the original data units and the window duration of the sliding time window, the total number of theoretical data entries within the window is calculated. The number of missing data entries is obtained by subtracting the actual number of valid original data units within the window from the total number of theoretical data entries. The missing data ratio is obtained by dividing the number of missing data entries by the total number of theoretical data entries. The time-series abrupt change characteristic value and the missing ratio are combined in a fixed order, first the time-series abrupt change characteristic value, then the missing ratio, to form a time continuity residual vector, used to characterize the time-series continuity and the degree of anomaly of the data.

[0049] For the two components of temporal mutation feature value and missing ratio in the temporal continuity residual vector, range normalization is performed separately. Range normalization is calculated by subtracting the pre-calculated historical minimum value of the component from the current component value, and then dividing by the difference between the historical maximum and historical minimum values, thus mapping each component value to a value range of 0 to 1. The historical minimum and historical maximum values ​​are obtained from sample data collected in the 24 hours prior to system operation and are dynamically updated daily with the system's operating cycle. Three preset quantization intervals are set, as detailed in Table 2. Next, the normalized temporal mutation feature value component is mapped to the corresponding quantization interval to obtain the temporal mutation level, and the normalized missing ratio component is mapped to the corresponding quantization interval to obtain the missing ratio level. The temporal mutation level and the missing ratio level are then combined in the order of temporal mutation level first, followed by the missing ratio level to generate the third-level verification state.

[0050] Table 2: Correspondence between time continuity residual quantification interval and anomaly level

[0051] Finally, the first-level verification state, the second-level verification state, and the third-level verification state generated in the previous steps are concatenated in order of verification level from low to high to form a structured verification description vector containing format signature verification results, multi-source consistency verification results, and time continuity verification results. Each element in this vector corresponds one-to-one with the verification result of the corresponding level.

[0052] By adding a continuity verification step in the time-series dimension, the three-layer hierarchical verification system has been improved, effectively enhancing the comprehensiveness of power data verification and the accuracy of abnormal data identification.

[0053] Furthermore, the method provided in this application embodiment includes: The verification status levels of each layer in the structured verification description vector are sequentially encoded into status code strings; the credentials generated by each layer of verification are hashed to establish the hash value of each layer of credentials; the status code strings, the hash values ​​of each layer of credentials, the verification timestamps, and the verification node identifiers are combined to generate the verification data.

[0054] Specifically, the verification status levels of the first, second, and third layers in the structured verification description vector are extracted sequentially and encoded using decimal numbers in a fixed order from front to back. For the first layer, compliance is coded as 0, and non-compliance as 1. For the second and third layers, low-level verification is coded as 0, medium-level as 1, and high-level as 2. The encoded characters corresponding to the three layers are concatenated sequentially to form a three-digit status code string. The encoding rules are pre-stored locally on the verification node, and the unified rules are directly invoked during execution.

[0055] The system collects three layers of credentials: a first-layer format signature verification credential, a second-layer multi-source consistency verification credential, and a third-layer time continuity verification credential. Each type of credential is a complete original record text generated during the corresponding verification process. Each of the three layers of credentials undergoes an independent hash operation. The SHA256 hash algorithm is used. Specifically: first, the text content of a single credential is converted into a UTF-8 encoded binary byte stream. Then, a message padding operation is performed on the byte stream, appending a 1 bit to the end, followed by several 0 bits, until the total length of the padded message modulo 512 equals 448. Finally, 64 bits of the original message length are appended. The padded message is divided into multiple groups of 512 bits each. Each group undergoes 64 rounds of iterative compression operations, with each round performing word expansion, round function transformation, and register value updates. After all groups are processed, the values ​​of the eight 32-bit intermediate registers are concatenated from high to low bits to convert them into a string of 64 hexadecimal characters, which is the hash value of that layer of credentials. The operations on the three layers of credentials are performed sequentially to obtain the hash values ​​of each layer.

[0056] Finally, the millisecond-level verification timestamp generated by the current verification operation is read, along with the unique verification node identifier string corresponding to the node performing the verification. Following a fixed order—status code string, first-level credential hash value, second-level credential hash value, third-level credential hash value, verification timestamp, and verification node identifier—the contents of each field are arranged sequentially, separated by commas, forming complete verification data. This verification data simultaneously carries verification status level information for each level and summary information for each level of verification credential, and can be directly used for subsequent evidence storage and verification operations.

[0057] By generating verification data in a unified format through standardized coding and hash digest processing, the verification results can be quickly parsed and retrieved, and the tamper-proof verification of the subsequent blockchain evidence storage process can be supported.

[0058] Furthermore, the method provided in this application embodiment includes: The encrypted container includes a container type identifier field, an encryption algorithm identifier field, and an encryption payload field, wherein the container type identifier field is used to distinguish between a fully private container, a biased witness container, and a denial-of-proof container.

[0059] Specifically, the encrypted container adopts a unified three-segment data structure, which includes a container type identifier field, an encryption algorithm identifier field, and an encryption payload field. Among them, the container type identifier field is used to distinguish between three business categories: fully private containers, biased witness containers, and denial proof containers.

[0060] The Full Privacy Container corresponds to transaction data at the first verification status level. This type of data has high integrity and no bias, requiring full encryption protection, and is therefore assigned to the Full Privacy Container. The Bias Witness Container corresponds to transaction data at the second verification status level. This type of data has a moderate degree of bias, requiring only encryption of sensitive fields, and is therefore assigned to the Bias Witness Container to facilitate subsequent bias analysis and settlement verification. The Rejection Proof Container corresponds to transaction data at the third verification status level. This type of data has format errors or high bias, and can be stored in plaintext, and is therefore assigned to the Rejection Proof Container. It is mainly used to provide evidence of invalid transactions to support auditing and dispute resolution.

[0061] By differentiating the container type identifier field, the three storage areas within the block body can quickly locate various types of transaction data. When processing a block, the verification node does not need to traverse all transaction content; it can select the appropriate verification strategy and access permissions based solely on the container type, significantly improving block processing efficiency and data access control granularity. The specific implementation methods of the encryption algorithm identifier field and the encryption payload field in the encryption container are consistent with the encryption encapsulation process described in the aforementioned embodiments, and will not be repeated here.

[0062] Furthermore, the method provided in this application embodiment includes: After using the verification status level to allocate the transaction payload associated with the original data unit to different encrypted containers and locate the storage segments, the located complete transaction segments, deviation settlement segments and invalid transaction segments are combined in sequence to form a block body.

[0063] Specifically, block assembly trigger rules are set, employing a dual threshold trigger mechanism of time period and transaction quantity. The fixed block packaging period is set to 1 minute, and the threshold for the number of transactions to be packaged is set to 200. When either the timer ends or the cumulative number of transactions reaches the threshold, the block assembly process is initiated. The specific steps are as follows: The system retrieves data from the fully encrypted transaction segment, deviation settlement segment, and invalid transaction segment separately. It then counts the total number of encrypted containers and the total byte length of each segment. The standard CRC32 algorithm is used to calculate the checksum of each segment. Before the calculation, a 256-item lookup table based on the polynomial 0xEDB88320 is pre-generated, and the 32-bit register value is initialized to 0xFFFFFFFF. The binary data stream of each segment is read byte by byte. For each byte read, the lower 8 bits of the register are XORed with the current byte. The result is used as an index to retrieve the corresponding value from the lookup table. The register is then shifted right by 8 bits and XORed with the retrieved value. After traversing all bytes of the complete segment, the final register value is bitwise inverted to obtain the 32-bit checksum of that segment. The calculated checksum is compared with the checksum pre-stored during segment writing. After confirming the completeness of the segment data, the system proceeds to the concatenation stage.

[0064] The encrypted containers within each segment are arranged in ascending order according to the millisecond-level timestamps of the corresponding transactions, and the concatenation process maintains the same container order within each segment. Concatenation is performed in a fixed order: complete transaction segments first, deviation settlement segments in the middle, and invalid transaction segments last. Each segment's header is pre-written with a 2-byte segment type identifier and a 4-byte total segment length field. The segment type identifier corresponds one-to-one with the three segment types, defining the boundaries of different segments. During concatenation, the complete data of the complete transaction segments, the complete data of the deviation settlement segments, and the complete data of the invalid transaction segments are sequentially joined end-to-end. The header identifier and length field of each segment are written synchronously into the concatenation sequence along with the segment body.

[0065] After all the data is concatenated, the total byte length of the concatenated data is calculated. Similarly, the CRC32 algorithm is used again to calculate the overall check value of the block body and append it to the end of the block body to complete the assembly operation of the entire block body. All transaction data are classified and stored in the corresponding segments according to the check level, and the structural boundaries are clear and traceable.

[0066] By using dual-threshold triggered assembly and labeled segmented orderly splicing, the block structure is guaranteed to be regular and parseable, enabling hierarchical collection and unified storage of transaction data with different verification levels.

[0067] Furthermore, the method provided in this application embodiment includes: The transaction payload corresponding to the first verification status level is encrypted using an attribute-based encryption algorithm and then placed into the complete transaction segment of the block body. The transaction payload corresponding to the second verification status level is encrypted with sensitive fields and then placed into the deviation clearing segment of the block body. The transaction payload corresponding to the third verification status level is placed in the invalid transaction segment of the block body in plaintext form.

[0068] In one embodiment, all pending transaction payloads are first subjected to integrity and legality checks. The transaction payload includes fields such as metering point identifier, power value, and timestamp. The CRC32 algorithm is used to calculate the check value of the original data of the transaction payload and compare it with the check code attached to the payload. After the check passes, the completeness of all required fields in the payload is checked, and abnormal data with missing fields is removed. The confirmed valid transaction payloads enter the subsequent encryption processing flow according to the corresponding check status level.

[0069] Transaction payloads identified as belonging to the first verification status level are fully encrypted using a ciphertext policy attribute-based encryption algorithm. A system master key and public parameters are pre-generated by the blockchain trusted key management center, and each legitimate access node is assigned a corresponding attribute set and a dedicated private key. Attributes include categories such as transaction settlement permissions and data audit permissions. Before encryption, an access policy tree is configured according to the access rules of the electricity transaction data. The policy tree combines various access attributes using logical AND and logical OR relationships. The complete plaintext data of the transaction payload is read, and encryption operations are performed in conjunction with the system public parameters and the preset access policy tree. The plaintext data and the policy tree are embedded in the operation process, outputting ciphertext data containing the access policy. The encrypted full ciphertext is filled into the encrypted payload field of a fully private container, and the container type identifier and encryption algorithm identifier are updated synchronously. After container assembly is completed, the complete transaction segment is written into the block body in ascending order of transaction timestamp.

[0070] The transaction payload, identified as belonging to the second verification status level, pre-defines the range of sensitive and ordinary fields. Sensitive fields include transaction electricity volume, user metering number, and transaction time period; ordinary fields include verification status identifier, collection timestamp, and metering point identifier. The SM4 symmetric encryption algorithm is used to process sensitive fields, with a 128-bit key length, employing an electronic cryptographic book working mode and a 128-bit block length. A locally pre-stored symmetric encryption key, uniformly generated by the key management contract in the blockchain network, is retrieved and securely distributed to nodes with deviation settlement permissions via attribute-based encrypted packages, and is updated periodically. Block encryption is performed on the plaintext content of each sensitive field one by one. Fields less than 128 bits are padded according to the PKCS7 padding rule to complete the encryption, resulting in ciphertext data for each sensitive field. Ordinary fields remain in plaintext state. The ciphertext of sensitive fields and the plaintext of ordinary fields are recombine according to the original field arrangement to form semi-plaintext, semi-ciphertext transaction data. The recombined transaction data is filled into the encrypted payload field of the deviation witness container, the corresponding container identifier field is updated, and it is written into the deviation settlement segment of the block body in ascending order of transaction timestamp.

[0071] For transaction payloads identified as being at the third verification status level, no encryption operations are performed on any fields within the payload, preserving the original plaintext content of all fields. The plaintext transaction payload is directly filled into the encrypted payload field of the rejection proof container, and the corresponding container identifier field is assigned a value according to the rules. After the container is assembled, the invalid transaction segment is written into the block body in ascending order of transaction timestamps for subsequent tracing and verification of invalid transactions.

[0072] By using a tiered and differentiated encryption strategy to match transaction data with different verification levels, the privacy and security of high-level transaction data are guaranteed, while also ensuring the traceability and processing efficiency of biased and invalid data.

[0073] Furthermore, the method provided in this application embodiment includes: The verification credentials for all transactions within the current block are collected separately according to the format signature verification layer, multi-source consistency verification layer, and time continuity verification layer. A Merkle tree for each verification layer is independently constructed, resulting in a first-layer credential root, a second-layer credential root, and a third-layer credential root. The first-layer, second-layer, and third-layer credential roots are concatenated in sequence and then subjected to a joint hash operation with the block header hash of the previous block to generate the evidence root. This evidence root simultaneously anchors the integrity of the verification credentials for this block and its chain association with the previous block. The allocated complete transaction segments, deviation clearing segments, and invalid transaction segments are then processed. First, second, and third transaction Merkle trees are constructed respectively to obtain first, second, and third transaction roots. The first, second, and third transaction roots are then combined with the evidence root to perform a joint hash operation, generating the verification-transaction anchor hash for this block. This verification-transaction anchor hash, along with the cryptographic suite identifier, is written into the block header. The verification-transaction anchor hash is used by light nodes to verify the consistency between the verification credential and the corresponding transaction segment when only a single verification layer's credential branch and a single transaction segment's transaction branch are obtained.

[0074] In this embodiment, the current block is a new block that is under construction, carrying the verification credentials and transaction payload data of the current batch of electricity transactions to be settled, and has not yet been encapsulated and broadcast to the chain. A light node is a lightweight access node in the blockchain network that does not store the complete blockchain ledger, only synchronizes summary information such as block headers, and can complete data verification through the Merkel branch path.

[0075] Optionally, firstly, extract the corresponding original credentials from the verification data of all transactions contained in the current block, according to the verification level. All credentials from the format signature verification layer are grouped into the first group, all credentials from the multi-source consistency verification layer into the second group, and all credentials from the time continuity verification layer into the third group. For each group of credentials, independently construct a Merkle tree for the verification credentials. The construction process uniformly uses the SHA256 hash algorithm. First, perform a hash operation on each original credential within the group, outputting a string of 64 hexadecimal characters representing the hash value of the leaf node. All leaf nodes are arranged in ascending order according to the transaction timestamp corresponding to the credential. Pair the arranged leaf nodes from left to right, directly concatenating the hash string between each pair of nodes in the order of left node first, right node last, without adding any separators. Perform a SHA256 hash operation on the concatenated result to generate the hash value of the parent node of the next layer. If the total number of nodes in a certain layer is odd, copy the hash value of the last node as the paired node to participate in the operation. The calculation is iterated upwards layer by layer until only the unique root node hash value remains, thus obtaining the first layer credential root, the second layer credential root, and the third layer credential root in sequence.

[0076] Next, the first, second, and third layer credential roots are concatenated into a continuous hexadecimal string in a fixed order from lowest to highest level, without any separators. Then, the hash value of the block header already stored on-chain in the previous block is read; this hash value is also a string of 64 hexadecimal characters. The concatenated credential root string is then concatenated again with the previous block header hash value in the aforementioned order. A SHA256 hash operation is performed on the completed string, and the resulting 64-hexadecimal hash value is the credential root. The credential root simultaneously carries the integrity digest of all verification credentials in this block and the identity identifier of the preceding block, achieving chain-like anchoring of verification data.

[0077] All encrypted container data within the complete transaction segment, the deviation settlement segment, and the invalid transaction segment are extracted separately. Using a single encrypted container as the basic unit, a first, second, and third transaction Merkle tree are constructed. During construction, a SHA256 hash operation is first performed on the complete binary data of each encrypted container to generate the corresponding leaf node hash value. Leaf nodes within the same segment are arranged in ascending order according to the timestamp of the corresponding transaction, consistent with the sorting rules of the verification credential Merkle tree. Following the Merkle tree construction rules of pairing together, left-front-right concatenation, and layer-by-layer iteration, odd-numbered nodes are copied to fill in the gaps at the end. The first, second, and third transaction roots are calculated, each corresponding to a complete digest of the three types of transaction data within the current block.

[0078] Next, the first, second, and third transaction roots are concatenated into a continuous hexadecimal transaction root combination string, arranged in the order of complete transaction segment, deviation settlement segment, and invalid transaction segment. This transaction root combination string is then concatenated with the previously generated evidence root. A SHA256 hash operation is performed on the concatenated string to generate the block's verification-transaction anchor hash. The pre-configured encryption suite identifier is read. This identifier uses a 1-byte unsigned integer to identify the encryption algorithm combination used in the block's transaction data, and its value rules are consistent with the encryption algorithm identifier field in the encryption container. The verification-transaction anchor hash and the encryption suite identifier are written into the corresponding fixed fields in the block header, completing the assembly of the core content of the block header.

[0079] When a light node performs verification, it first obtains the Merkle branch data corresponding to the target verification layer. The branch contains the hash values ​​and hierarchical order of all sibling nodes along the path from the target credential leaf node to the credential root of that layer. Following the Merkle tree iteration rules, it calculates upwards layer by layer to derive the credential root of that layer. Next, it obtains the Merkle branch data for the corresponding transaction segment and derives the corresponding transaction root in the same way. Then, according to the concatenation and hashing rules agreed upon in the block header, it sequentially derives the evidence root and the verification-transaction anchor hash. The derivation results are compared with the verification-transaction anchor hash stored in the block header. If the values ​​match, the consistency between the verification credential and the corresponding transaction segment is verified.

[0080] By constructing block headers using a hierarchical Merkle tree structure and a standardized multi-level joint hash anchoring mechanism, the blockchain data chain integrity and tamper-proof nature are ensured. At the same time, it supports lightweight nodes to verify the correspondence between verification credentials and transaction data on demand, effectively reducing the verification cost of distributed power transaction settlement data and improving the verification credibility.

[0081] Furthermore, the method provided in this application embodiment includes: After the block is broadcast to the blockchain network, the verification node verifies the received block. The verification includes: verifying the consistency between the credential Merkle root and the evidence root, the consistency between the three-transaction Merkle root and the verification-transaction anchor hash, and the matching of the cryptographic suite identifier with the current network configuration. When the verification is successful, the block is appended to the local ledger and a confirmation message is broadcast to the entire network.

[0082] In one embodiment, after a pre-authorized full verification node in the blockchain network receives the complete block data broadcast across the network, it automatically triggers the block verification process. The node first performs a CRC32 integrity check on the received raw data. If the check passes, it splits the overall block structure, separating the block header and the block body. From the block header, it extracts the evidence root, verification-transaction anchor hash, cryptographic suite identifier, and the hash field of the previous block. From the block body, it extracts three types of verification credentials corresponding to the format signature verification layer, multi-source consistency verification layer, and time continuity verification layer, as well as three segments of transaction data corresponding to the complete transaction segment, the deviation settlement segment, and the invalid transaction segment. All subsequent Merkle tree reconstruction operations strictly follow the unified operation rules of the block construction stage. The hash algorithm is uniformly SHA256, leaf nodes are arranged in ascending order according to the timestamp of the corresponding transaction, node pairing follows the direct concatenation rule of left node first, right node last, and odd-numbered layer nodes are filled by copying the last node, ensuring that the operation standards of the block generation and verification stages are completely consistent.

[0083] When performing consistency verification between the Merkle tree root and the evidence root of the verification credentials, three Merkle trees are reconstructed based on the three types of verification credentials obtained from the splitting. The first-level, second-level, and third-level credential roots are obtained through iterative calculations layer by layer. These three credential roots are then directly concatenated in ascending order of hierarchy. A joint hash operation is then performed using the hash value of the previous block header stored in the local ledger to derive the locally computed evidence root. The derived result is compared bit-by-bit with the evidence root extracted from the block header. If the values ​​are completely identical, the verification passes; otherwise, the verification fails, the node discards the current block, marks the block sending node with an anomaly record, and does not forward the block to other adjacent nodes.

[0084] When performing consistency verification of the Merkle tree roots and the verification-transaction anchor hash of the three transaction segments, all encrypted containers within the three transaction data segments are extracted. Using a single encrypted container as the basic unit, the first, second, and third transaction Merkle trees are reconstructed, yielding the first, second, and third transaction roots. These three transaction roots are then concatenated in their segmented order and subjected to a joint hash operation with the verified evidence roots to derive the locally calculated verification-transaction anchor hash. The derived result is compared bit-by-bit with the verification-transaction anchor hash extracted from the block header. If the values ​​are completely identical, the verification passes; otherwise, the node discards the current block, terminating all subsequent verification processes.

[0085] When performing the matching verification of the cipher suite identifier and the current network configuration, the unified encryption configuration file of the entire network stored locally on the verification node is retrieved. The preset standard cipher suite identifier code in the file is read and compared with the cipher suite identifier extracted from the block header. If the codes match completely, the verification passes. Preferably, after all three core content verifications pass, the node additionally performs a blockchain-style continuity verification, comparing the hash value of the previous block in the block header with the hash value of the latest block in the local ledger to confirm that the block height is correctly connected. If the match fails, it is determined that the block has a risk of chain breakage, and the block is directly discarded and an anomaly log is recorded synchronously.

[0086] After all verification items pass, the verification node acquires an exclusive lock on its local ledger file and appends the current complete block to the end of the local blockchain ledger in ascending block height order. Once the writing is complete, the file lock is released. The node then assembles a verification confirmation message, which includes the hash value of the current block, the verification node's digital signature, and a verification success status indicator. For example, the confirmation message uses a unified binary encoding format. The message header contains a 4-byte message type field with a value of 1 indicating verification confirmation, followed by a 32-byte block hash value, then a 64-byte verification node digital signature, and finally a 1-byte verification status indicator, with a value of 1 indicating successful verification. After the message is assembled, it is broadcast to the entire blockchain network, allowing other ordinary nodes to quickly identify legitimate blocks and reduce the computational overhead of duplicate verification.

[0087] The aforementioned multi-dimensional closed-loop verification process, through reverse verification of unified computing standards, chain-based continuous verification, and a network-wide confirmation mechanism, accurately intercepts illegally tampered and non-compliant blocks, ensuring the data consistency and reliability of the distributed power trading and settlement network.

[0088] In summary, the blockchain-based distributed power trading settlement method provided in this application has the following technical effects: This application collects power data from different physical sources and performs hierarchical verification. After residual vector decomposition and normalization discretization, the verification status level is obtained. The transaction payload is allocated to different encrypted containers according to the level and the storage segment is located. By combining multiple Merkle trees to construct block headers and evidence roots, the block is encapsulated and broadcast to the entire network. This achieves hierarchical storage and trusted settlement of distributed power transaction data, making data integrity verification and privacy protection more efficient and reliable. It achieves hierarchical verification and hierarchical storage of power transaction data, improves the reliability and processing efficiency of settlement data, and ensures the traceability of transaction data.

[0089] Example 2, as Figure 2 As shown, based on the same inventive concept as Embodiment 1 above, this application provides a blockchain-based distributed power trading and settlement system, the system comprising: The raw data unit construction module 1 is used to collect power data from different physical sources and construct raw data units.

[0090] Verification description vector construction module 2 is used to perform hierarchical verification on the original data unit and establish a structured verification description vector. The hierarchical verification includes format signature verification, multi-source consistency verification, and time continuity verification.

[0091] Verification data generation module 3 is used to generate verification data for each transaction based on the structured verification description vector. The verification data includes verification status level and verification credentials at each level.

[0092] Storage segment positioning module 4 uses the verification status level to allocate the transaction payload associated with the original data unit to different encrypted containers and locate the storage segment. The first verification status level corresponds to the complete transaction segment of the block body, the second verification status level corresponds to the deviation settlement segment of the block body, and the third verification status level corresponds to the invalid transaction segment of the block body.

[0093] Block header construction module 5 is used to construct a block header, which includes an evidence root generated by the verification credentials grouped and aggregated according to the verification layer, Merkle tree roots corresponding to the three Merkle subtrees constructed by the complete transaction segment, the deviation clearing segment and the invalid transaction segment respectively, and a cryptographic suite identifier.

[0094] The settlement on-chain execution module 6 is used to combine the block header and the block body containing the encrypted container into a block, and broadcast the block to the blockchain network to complete the settlement on-chain of distributed power transactions.

[0095] Furthermore, the storage segmentation and positioning module 4 is used to perform the following steps: After using the verification status level to allocate the transaction payload associated with the original data unit to different encrypted containers and locate the storage segments, the located complete transaction segments, deviation settlement segments and invalid transaction segments are combined in sequence to form a block body.

[0096] Furthermore, the verification description vector construction module 2 is used to perform the following steps: The original data units are compared using data templates, including byte length, field type, and unit verification, to verify the device-side data signature and gateway signature, establishing a first-level verification state. A constraint channel, containing node power balance constraints and line power constraints, is established based on the power topology relationships corresponding to the original data units. This constraint channel describes the physical relationships between different data sources. Original data units from different physical sources are mapped to the constraint channel, and residual vectors are calculated. These residual vectors characterize the degree of deviation of multi-source data from physical constraints. The residual vectors are decomposed according to the constraint types within the constraint channel, establishing node power balance residual components, line power constraint residual components, and multi-source observation conflict residual components. Normalization processing is performed on each residual component, and interval discretization is performed according to a preset quantization interval to generate corresponding discrete residual levels, establishing a second-level verification state. A structured verification description vector is established based on the first-level and second-level verification states.

[0097] Furthermore, the verification description vector construction module 2 is used to perform the following steps: The original data units are arranged in chronological order according to a preset sliding time window to construct a continuous time series vector; the rate of change and missing ratio of adjacent data units within the continuous time series vector are calculated to establish a time continuity residual vector, which is used to characterize the temporal continuity and anomaly degree of the data; the time continuity residual vector is normalized and mapped to discrete continuity levels according to a preset quantization interval to generate a third-level verification state; a structured verification description vector is established based on the first-level verification state, the second-level verification state, and the third-level verification state.

[0098] Furthermore, the storage segmentation and positioning module 4 is used to perform the following steps: The transaction payload corresponding to the first verification status level is encrypted using an attribute-based encryption algorithm and then placed into the complete transaction segment of the block body. The transaction payload corresponding to the second verification status level is encrypted with sensitive fields and then placed into the deviation clearing segment of the block body. The transaction payload corresponding to the third verification status level is placed in the invalid transaction segment of the block body in plaintext form.

[0099] Furthermore, the block header construction module 5 is used to perform the following steps: The verification credentials for all transactions within the current block are collected separately according to the format signature verification layer, multi-source consistency verification layer, and time continuity verification layer. A Merkle tree for each verification layer is independently constructed, resulting in a first-layer credential root, a second-layer credential root, and a third-layer credential root. The first-layer, second-layer, and third-layer credential roots are concatenated in sequence and then subjected to a joint hash operation with the block header hash of the previous block to generate the evidence root. This evidence root simultaneously anchors the integrity of the verification credentials for this block and its chain association with the previous block. The allocated complete transaction segments, deviation clearing segments, and invalid transaction segments are then processed. First, second, and third transaction Merkle trees are constructed respectively to obtain first, second, and third transaction roots. The first, second, and third transaction roots are then combined with the evidence root to perform a joint hash operation, generating the verification-transaction anchor hash for this block. This verification-transaction anchor hash, along with the cryptographic suite identifier, is written into the block header. The verification-transaction anchor hash is used by light nodes to verify the consistency between the verification credential and the corresponding transaction segment when only a single verification layer's credential branch and a single transaction segment's transaction branch are obtained.

[0100] Furthermore, the storage segmentation and positioning module 4 is used to perform the following steps: The encrypted container includes a container type identifier field, an encryption algorithm identifier field, and an encryption payload field, wherein the container type identifier field is used to distinguish between a fully private container, a biased witness container, and a denial-of-proof container.

[0101] Furthermore, the verification data generation module 3 is used to perform the following steps: The verification status levels of each layer in the structured verification description vector are sequentially encoded into status code strings; the credentials generated by each layer of verification are hashed to establish the hash value of each layer of credentials; the status code strings, the hash values ​​of each layer of credentials, the verification timestamps, and the verification node identifiers are combined to generate the verification data.

[0102] Furthermore, the settlement on-chain execution module 6 is used to perform the following steps: After the block is broadcast to the blockchain network, the verification node verifies the received block. The verification includes: verifying the consistency between the credential Merkle root and the evidence root, the consistency between the three-transaction Merkle root and the verification-transaction anchor hash, and the matching of the cryptographic suite identifier with the current network configuration. When the verification is successful, the block is appended to the local ledger and a confirmation message is broadcast to the entire network.

[0103] The blockchain-based distributed power trading and settlement system provided in this embodiment of the invention can execute the blockchain-based distributed power trading and settlement method provided in any embodiment of the invention, and has the corresponding functional modules and beneficial effects of the execution method.

[0104] Although this application makes various references to certain modules in the system according to the embodiments of this application, any number of different modules can be used and run on user terminals and / or servers. The various units and modules included are only divided according to functional logic, but are not limited to the above division, as long as the corresponding functions can be achieved; in addition, the specific names of each functional unit are only for easy distinction between each other and are not used to limit the scope of protection of this invention.

[0105] The specific embodiments described above do not constitute a limitation on the scope of protection of this application. 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 spirit and principles of this application should be included within the scope of protection of this application. In some cases, the actions or steps described in this application can be performed in a different order than that shown in the embodiments and still achieve the desired results. Furthermore, the processes depicted in the accompanying drawings do not necessarily require a specific or sequential order to achieve the desired results. In some embodiments, multitasking and parallel processing are also possible or may be advantageous.

Claims

1. A distributed power trading and settlement method based on blockchain, characterized in that, The method includes: Collect power data from different physical sources to construct raw data units; Perform hierarchical verification on the original data unit and establish a structured verification description vector. The hierarchical verification includes format signature verification, multi-source consistency verification, and time continuity verification. Verification data for each transaction is generated based on the structured verification description vector. The verification data includes the verification status level and verification credentials at each level. The transaction payload associated with the original data unit is allocated to different encrypted containers and storage segments are located by using the verification status level. The first verification status level corresponds to the complete transaction segment of the block body, the second verification status level corresponds to the deviation settlement segment of the block body, and the third verification status level corresponds to the invalid transaction segment of the block body. Construct a block header, which includes the evidence root generated by the aggregation of the verification credentials grouped by verification layer, the Merkel tree root corresponding to the three Merkel subtrees constructed by the complete transaction segment, the deviation clearing segment, and the invalid transaction segment, and the cipher suite identifier; The block header and the block body containing the encrypted container are combined into a block, and the block is broadcast to the blockchain network to complete the settlement and on-chaining of distributed power transactions.

2. The blockchain-based distributed power trading settlement method as described in claim 1, characterized in that, After using the verification status level to allocate the transaction payload associated with the original data unit to different encrypted containers and locate the storage segments, the located complete transaction segments, deviation settlement segments and invalid transaction segments are combined in sequence to form a block body.

3. The blockchain-based distributed power trading settlement method as described in claim 1, characterized in that, Perform hierarchical verification on the original data units and establish a structured verification description vector, including: The original data units are compared with data templates, including byte length, field type, and unit verification, to verify the device-side data signature and the gateway signature and establish the first layer of verification status. Based on the power topology relationship corresponding to the original data unit, a constraint channel is established that includes node power balance constraints and line power constraints. The constraint channel is used to describe the physical relationship between different data sources. The raw data units from different physical sources are mapped to the constraint channels, and the residual vector is calculated. The residual vector is used to characterize the degree of deviation of the multi-source data from the physical constraints. The residual vector is decomposed into components according to the constraint type in the constraint channel to establish node power balance residual components, line power constraint residual components and multi-source observation conflict residual components. Normalization processing is performed on each residual component, and interval discretization is performed according to the preset quantization interval to generate the corresponding discrete residual level and establish the second layer of verification state. A structured verification description vector is established based on the first-level verification status and the second-level verification status.

4. The blockchain-based distributed power trading settlement method as described in claim 3, characterized in that, A structured verification description vector is established based on the first-level verification state and the second-level verification state, including: The original data units are arranged in chronological order according to a preset sliding time window to construct a continuous time series vector. Calculate the rate of change and missing ratio of adjacent data units within the continuous time series vector, and establish a time continuity residual vector. The time continuity residual vector is used to characterize the temporal continuity and anomaly degree of the data. The time continuity residual vector is normalized and mapped to discrete continuity levels according to a preset quantization interval to generate a third-layer verification state. A structured verification description vector is established based on the first-level verification status, the second-level verification status, and the third-level verification status.

5. The blockchain-based distributed power trading settlement method as described in claim 1, characterized in that, The transaction payload corresponding to the first verification status level is encrypted using an attribute-based encryption algorithm and then placed into the complete transaction segment of the block body. The transaction payload corresponding to the second verification status level is encrypted with sensitive fields and then placed into the deviation clearing segment of the block body. The transaction payload corresponding to the third verification status level is placed in the invalid transaction segment of the block body in plaintext form.

6. The blockchain-based distributed power trading settlement method as described in claim 1, characterized in that, Construct the block header, including: The verification credentials of all transactions in the current block are collected separately according to the format signature verification layer, the multi-source consistency verification layer, and the time continuity verification layer. A Merkle tree of verification credentials is independently constructed for each verification layer to obtain the first layer credential root, the second layer credential root, and the third layer credential root. The first layer of credential root, the second layer of credential root, and the third layer of credential root are concatenated in sequence and then subjected to a joint hash operation with the block header hash of the previous block to generate the evidence root, so that the evidence root simultaneously anchors the integrity of the verification credentials of this block and the chain association with the previous block. Construct the first transaction Merkle tree, the second transaction Merkle tree, and the third transaction Merkle tree for the allocated complete transaction segments, deviation settlement segments, and invalid transaction segments respectively, and obtain the first transaction root, the second transaction root, and the third transaction root; The first transaction root, the second transaction root, the third transaction root, and the evidence root are combined with a hash operation to generate the verification-transaction anchor hash of this block, and the verification-transaction anchor hash and the cryptographic suite identifier are written together into the block header; The verification-transaction anchor hash is used by light nodes to verify the consistency of ownership between the verification credential and the corresponding transaction segment when only a single verification layer credential branch and a single transaction segment transaction branch are obtained.

7. The blockchain-based distributed power trading settlement method as described in claim 1, characterized in that, The encrypted container includes a container type identifier field, an encryption algorithm identifier field, and an encryption payload field, wherein the container type identifier field is used to distinguish between a fully private container, a biased witness container, and a denial-of-proof container.

8. The blockchain-based distributed power trading settlement method as described in claim 1, characterized in that, Verification data for each transaction is generated based on the structured verification description vector, including: The verification status levels of each layer in the structured verification description vector are sequentially encoded into status code strings; Perform hash operations on the credentials generated at each layer of verification to establish the hash value of each layer of credentials; The verification data is generated by combining the status code string, the hash values ​​of each layer of credentials, the verification timestamp, and the verification node identifier.

9. The blockchain-based distributed power trading settlement method as described in claim 1, characterized in that, After the block is broadcast to the blockchain network, the verification node verifies the received block. The verification includes: verifying the consistency between the credential Merkle root and the evidence root, the consistency between the three transaction Merkle root and the verification-transaction anchor hash, and the matching of the cryptographic suite identifier with the current network configuration. When the verification is successful, the block is appended to the local ledger and a confirmation message is broadcast to the entire network.

10. A blockchain-based distributed power trading and settlement system, characterized in that, The system is used to implement the blockchain-based distributed power trading settlement method according to any one of claims 1-9, the system comprising: The raw data unit construction module is used to collect power data from different physical sources and construct raw data units; The verification description vector construction module is used to perform hierarchical verification on the original data unit and establish a structured verification description vector. The hierarchical verification includes format signature verification, multi-source consistency verification, and time continuity verification. The verification data generation module is used to generate verification data for each transaction based on the structured verification description vector. The verification data includes the verification status level and verification credentials at each level. The storage segment positioning module uses the verification status level to allocate the transaction payload associated with the original data unit to different encrypted containers and locate the storage segment. The first verification status level corresponds to the complete transaction segment of the block body, the second verification status level corresponds to the deviation settlement segment of the block body, and the third verification status level corresponds to the invalid transaction segment of the block body. The block header construction module is used to construct the block header, which includes the evidence root generated by the verification credentials grouped and aggregated according to the verification layer, the Merkle tree root corresponding to the three Merkle subtrees constructed by the complete transaction segment, the deviation clearing segment and the invalid transaction segment respectively, and the cipher suite identifier; The settlement on-chain execution module is used to combine the block header and the block body containing the encrypted container into a block, and broadcast the block to the blockchain network to complete the settlement on-chain of distributed power transactions.

Images