A blockchain-based carbon data processing method, device, equipment and medium

Abstract

The application relates to the technical field of blockchains, and in particular to a carbon data processing method and device based on a blockchain, equipment and a medium. First, after obtaining carbon data collected by an Internet of Things device, a dynamic key is generated based on the device information of the Internet of Things device and the collection parameters corresponding to the carbon data, and then the carbon data is encrypted using the dynamic key to obtain encrypted carbon data, effectively solving the problems of low data security and lack of effective encryption protection measures. Next, the encrypted carbon data and the dynamic key are sent to a blockchain node for verification, ensuring the security and reliability of the data. When the verification result is passed, a target smart contract that matches the encrypted carbon data is selected according to the characteristics of the encrypted carbon data, and the target smart contract is used to analyze the encrypted carbon data, realizing the intelligentization and automation of the analysis means, and being capable of deeply mining the value behind the data, and making up for the defects of the insufficient intelligentization and automation of traditional analysis means.

Description

Technical Field

[0001] This invention relates to the field of blockchain technology, and specifically to a method, apparatus, device, and medium for processing carbon data based on blockchain. Background Technology

[0002] Existing technologies have certain limitations in processing corporate carbon emission data. They typically only collect carbon emission source data without in-depth consideration of data security and accuracy. During data transmission and storage, effective encryption measures are not implemented, making the carbon data vulnerable to data leakage and tampering, and the legitimacy and integrity of the data sources are difficult to guarantee. Furthermore, the collected carbon data lacks intelligent and automated analysis methods, relying mostly on manual or simple statistical methods, making it difficult to deeply extract value from the data, such as carbon emission trends and their correlation with various factors in the production process, and also failing to accurately assess a company's carbon emission level within the industry. Summary of the Invention

[0003] In view of this, embodiments of the present invention provide a blockchain-based carbon data processing method, apparatus, device and medium to address the problems of low data security, lack of effective encryption protection measures and insufficient intelligent and automated analysis methods in enterprise carbon emission data processing.

[0004] In a first aspect, embodiments of the present invention provide a blockchain-based carbon data processing method, the method comprising:

[0005] Acquire carbon data collected by IoT devices from the carbon emission sources of enterprises;

[0006] A dynamic key is generated based on the device information of the IoT device and the collection parameters corresponding to the carbon data, and the carbon data is encrypted using the dynamic key to obtain encrypted carbon data.

[0007] The encrypted carbon data and the dynamic key are sent to the blockchain node, and the blockchain node verifies the encrypted carbon data and the dynamic key to obtain the verification result.

[0008] If the verification result indicates that the encrypted carbon data and the dynamic key have passed verification, then a target smart contract matching the encrypted carbon data is selected based on the multiple smart contracts deployed in the blockchain node, and the encrypted carbon data is analyzed using the target smart contract to obtain evaluation information.

[0009] Furthermore, the acquisition of carbon data obtained by IoT devices from enterprise carbon emission sources includes:

[0010] Obtain the key monitoring data of the enterprise's carbon emission sources;

[0011] If the indicator data reaches the preset threshold corresponding to the key monitoring indicator, a data collection command is triggered;

[0012] Based on the acquisition command, the IoT device is controlled to collect data from the enterprise's carbon emission sources, resulting in multiple dimensions of collected data.

[0013] The carbon data is obtained by calculating based on collected data from multiple different dimensions.

[0014] Furthermore, the generation of a dynamic key based on the device information of the IoT device and the acquisition parameters corresponding to the carbon data includes:

[0015] Obtain the device model and device type of the IoT device;

[0016] Obtain the collection timestamp and data type corresponding to the carbon data;

[0017] The dynamic key is generated based on the device model, the device type, the collection timestamp, and the data type.

[0018] Furthermore, generating the dynamic key based on the device model, the device type, the collection timestamp, and the data type includes:

[0019] Obtain an encoding mapping table, wherein the encoding mapping table includes numerical codes corresponding to preset device models, preset device types, and preset data types respectively;

[0020] Obtain from the encoding mapping table the first digital code corresponding to the device model, the second digital code corresponding to the device type, and the third digital code corresponding to the data type;

[0021] The initial data sequence is obtained by concatenating the first digital code, the second digital code, the third digital code, and the timestamp.

[0022] The initial data sequence is processed using a hash algorithm to obtain a hash code, and a code of a preset length is extracted from the hash code as the initial dynamic key;

[0023] The dynamic key is obtained by transforming a portion of the encoding in the initial dynamic key.

[0024] Furthermore, the transformation of a portion of the encoding in the initial dynamic key to obtain the dynamic key includes:

[0025] The initial dynamic key is divided into multiple coding groups, and the algorithm corresponding to each coding group is obtained;

[0026] The algorithm is used to replace characters in the corresponding encoding group, or the algorithm is used to shift characters in the corresponding encoding group to obtain the adjusted encoding group;

[0027] The adjusted coding group is recombined to obtain the dynamic key.

[0028] Furthermore, the verification of the encrypted carbon data and the dynamic key through the blockchain node to obtain the verification result includes:

[0029] The data source corresponding to the encrypted carbon data and the relevant feature information in the dynamic key are extracted using a preset verification mechanism.

[0030] Based on the preset consensus algorithm and preset contract, query the list of authorized devices already existing on the blockchain node. If the IoT device corresponding to the data source belongs to the list of authorized devices, then use the key generation algorithm stored in the blockchain node and the historical key.

[0031] The key generation algorithm and the historical key are used to verify whether the generation logic of the dynamic key is correct.

[0032] If the dynamic key generation logic is correct, then the encrypted carbon data is decrypted to obtain the carbon data.

[0033] The carbon data is verified based on the data specifications on the blockchain node to obtain the verification result.

[0034] Furthermore, the analysis of the encrypted carbon data using the target smart contract to obtain evaluation information includes:

[0035] Extract data extraction strategies and data analysis strategies from the target smart contract;

[0036] Key data elements are extracted from the carbon data obtained by encrypting the encrypted carbon data according to the data extraction strategy described above.

[0037] By comparing the key data elements with data values ​​of different types, the comparison results are obtained;

[0038] The key data elements are analyzed according to the data analysis strategy described above to obtain process parameters and correlation parameters.

[0039] The evaluation information is generated based on the comparison results, the process parameters, and the correlation parameters.

[0040] Secondly, embodiments of the present invention provide a blockchain-based carbon data processing device, the device comprising:

[0041] The acquisition module is used to acquire carbon data collected by IoT devices from the enterprise's carbon emission sources;

[0042] The generation module is used to generate a dynamic key based on the device information of the Internet of Things device and the acquisition parameters corresponding to the carbon data, and to encrypt the carbon data using the dynamic key to obtain encrypted carbon data.

[0043] The sending module is used to send the encrypted carbon data and the dynamic key to the blockchain node, and to verify the encrypted carbon data and the dynamic key through the blockchain node to obtain the verification result;

[0044] The analysis module is used to select a target smart contract that matches the encrypted carbon data based on multiple smart contracts deployed in the blockchain node if the verification result is that the encrypted carbon data and the dynamic key are verified successfully, and to use the target smart contract to analyze the encrypted carbon data to obtain evaluation information.

[0045] Thirdly, embodiments of the present invention provide a computer device, including: a memory and a processor, the memory and the processor being communicatively connected to each other, the memory storing computer instructions, and the processor executing the computer instructions to perform the method described in the first aspect or any corresponding embodiment thereof.

[0046] Fourthly, embodiments of the present invention provide a computer-readable storage medium storing computer instructions that cause a computer to perform the method described in the first aspect or any of its corresponding embodiments.

[0047] This application first acquires carbon data collected by IoT devices. Based on the device information and the corresponding acquisition parameters of the carbon data, a dynamic key is generated. This dynamic key is then used to encrypt the carbon data, resulting in encrypted carbon data. This process provides robust encryption protection, ensuring high confidentiality and integrity during transmission and storage, effectively addressing the problems of low data security and lack of effective encryption protection. Next, the encrypted carbon data and the dynamic key are sent to a blockchain node for verification. The blockchain node's verification mechanism ensures the legality of the data source and the correctness of the key generation logic, further guaranteeing data security and reliability. Once the verification is successful, multiple smart contracts deployed on the blockchain node select a matching target smart contract based on the characteristics of the encrypted carbon data. This target smart contract is then used to analyze the encrypted carbon data, achieving intelligent and automated analysis. This allows for in-depth mining of the value behind the data, such as carbon emission trends and their correlation with various factors in the production process, thereby accurately assessing a company's carbon emission level within the industry and compensating for the shortcomings of traditional analysis methods in terms of intelligence and automation. Attached Figure Description

[0048] To more clearly illustrate the specific embodiments of the present invention or the technical solutions in the prior art, the drawings used in the description of the specific embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are some embodiments of the present invention. For those skilled in the art, other drawings can be obtained from these drawings without creative effort.

[0049] Figure 1 This is a schematic flowchart of a blockchain-based carbon data processing method according to some embodiments of the present invention;

[0050] Figure 2 This is a schematic flowchart of another blockchain-based carbon data processing method according to some embodiments of the present invention;

[0051] Figure 3 This is a flowchart illustrating yet another blockchain-based carbon data processing method according to some embodiments of the present invention;

[0052] Figure 4 This is a flowchart illustrating yet another blockchain-based carbon data processing method according to some embodiments of the present invention;

[0053] Figure 5 This is a flowchart illustrating yet another blockchain-based carbon data processing method according to some embodiments of the present invention;

[0054] Figure 6 This is a structural block diagram of a blockchain-based carbon data processing device according to an embodiment of the present invention;

[0055] Figure 7 This is a schematic diagram of the hardware structure of a computer device according to an embodiment of the present invention. Detailed Implementation

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

[0057] According to embodiments of the present invention, a method, apparatus, device, and medium for processing carbon data based on blockchain are provided. It should be noted that the steps shown in the flowcharts in the accompanying drawings can be executed in a computer system such as a set of computer-executable instructions. Furthermore, although a logical order is shown in the flowcharts, in some cases, the steps shown or described may be executed in a different order than that shown here.

[0058] This embodiment provides a blockchain-based carbon data processing method. Figure 1 This is a flowchart of a blockchain-based carbon data processing method according to an embodiment of the present invention, such as... Figure 1 As shown, the process includes the following steps:

[0059] Step S101: Obtain carbon data collected by IoT devices from the enterprise's carbon emission sources.

[0060] In this embodiment of the application, carbon data collected by IoT devices from the carbon emission sources of an enterprise is obtained, such as... Figure 2 As shown, the steps include A1-A4:

[0061] Step A1: Obtain the key monitoring data of the enterprise's carbon emission sources.

[0062] Specifically, based on their own production processes, energy usage patterns, and industry characteristics, companies identify which factors play a key role in carbon emissions, thus determining key monitoring indicators (KPIs). For example, for a chemical company, KPIs might include raw material consumption, energy consumption (such as electricity and natural gas), operating hours and power of production equipment, and conversion rates of specific chemical reactions; for a manufacturing company, KPIs might include raw material processing volume, equipment utilization rate, and energy consumption. These indicators will be the focus of subsequent monitoring and data collection.

[0063] Based on the identified key monitoring indicators, corresponding monitoring equipment and systems are deployed at each stage related to the enterprise's carbon emission sources. For example, for energy consumption indicators, smart meters, gas meters, and other devices that can record energy usage in real time are installed, and the data is transmitted to a unified monitoring system via network connection. For the operating parameters of production equipment, sensors such as temperature sensors, pressure sensors, and speed sensors are installed on the equipment to collect equipment operating status data, and these data are also transmitted to the monitoring system.

[0064] Monitoring equipment and systems continuously collect data at a set frequency (e.g., hourly, daily), and transmit the raw data on various key monitoring indicators to a data processing center or server. At the data processing center, the raw data from different monitoring equipment and systems is integrated, and duplicate, erroneous, or incomplete data is removed to ensure accuracy and completeness, thereby obtaining the indicator data for the key monitoring indicators.

[0065] Step A2: If the indicator data reaches the preset threshold corresponding to the key monitoring indicator, a data collection command is triggered.

[0066] Specifically, for each key monitoring indicator, companies set reasonable preset thresholds based on their own carbon emission targets, production plans, and historical data. For example, for energy consumption indicators, if a company plans to control its monthly electricity consumption within a certain range, it sets a corresponding preset threshold for electricity consumption based on this target. For raw material consumption indicators, preset thresholds for raw material consumption at different production stages are set, taking into account factors such as product output and raw material utilization rates. These thresholds will serve as the basis for determining whether further detailed carbon data collection is necessary.

[0067] At the data processing center, the real-time collected data of key monitoring indicators are compared with their corresponding preset thresholds. By writing data comparison programs or using data analysis software, the current data and preset thresholds of each key monitoring indicator are checked one by one. For example, when comparing the real-time collected electricity consumption data of a workshop with the set preset electricity consumption threshold, if it is found that the current electricity consumption data has reached or exceeded the preset threshold, it means that there is an abnormal carbon emission situation, and further detailed data collection and analysis are required.

[0068] Once a key monitoring indicator's data reaches its preset threshold, the data processing center's control system automatically triggers a data acquisition command. This triggering mechanism can be implemented through software programming. For example, conditional statements can be set in the data comparison program. When the threshold condition is met, a data acquisition command signal is sent to the module responsible for controlling the IoT device, notifying it to prepare for the next step of detailed carbon data acquisition.

[0069] Step A3: Based on the acquisition command, control the IoT device to collect data on the enterprise's carbon emission sources and obtain data from multiple dimensions.

[0070] Specifically, upon receiving a data collection command, the first step is to ensure that the IoT devices are in normal working order. For IoT devices already deployed at various stages of the enterprise's carbon emission sources, such as various sensors and data collectors, a status check should be performed, including checking the device's battery level, network connectivity, and sensor sensitivity. If any malfunctions or abnormalities are found, they should be repaired or replaced promptly to ensure the devices can accurately collect data.

[0071] Based on the requirements of the data collection instructions and the specific circumstances of the enterprise's carbon emission sources, the data collection parameters of the IoT devices are set. For example, for sensor devices, parameters such as the collection frequency (e.g., once per minute), collection accuracy (e.g., accurate to several decimal places), and collection range (e.g., the collection range of a temperature sensor in degrees Celsius) are set; for data acquisition devices, parameters such as data storage format and transmission protocol are set. These data collection parameters will determine the quality and type of the collected data.

[0072] Following the pre-set data collection parameters, the IoT devices begin collecting data on the company's carbon emission sources. Data is collected from multiple dimensions, including: time (continuously collecting data from different time periods); space (collecting data from different production workshops, equipment, and regions); and data types (including temperature, pressure, flow rate, and energy consumption). This multi-dimensional collection approach allows for comprehensive and detailed acquisition of relevant data on the company's carbon emission sources, resulting in data from multiple perspectives.

[0073] Step A4 involves calculating carbon data based on collected data from multiple different dimensions.

[0074] Specifically, the first step is to preprocess the collected data from multiple dimensions. This includes cleaning the data to remove noise, erroneous data, and duplicate data; and standardizing the data to ensure that data from different sources and in different formats can be compared and calculated on the same scale. For example, for temperature data, if the collected temperature data is in both Celsius and Fahrenheit, it needs to be converted to Celsius; for energy consumption data, if some data is in kilowatts and others in megawatts, it needs to be converted to the same unit.

[0075] Based on a company's production processes, energy usage, and relevant theories and research findings on carbon emissions, a carbon data calculation model suitable for the company itself should be established. This calculation model can be based on physicochemical principles or statistical analysis methods. For example, for companies whose main energy source is burning fossil fuels, a calculation model based on physicochemical principles can be established based on factors such as fuel type, combustion efficiency, and carbon dioxide emissions. For complex production processes, a calculation model based on statistical analysis methods is needed. This involves analyzing a large amount of historical data to identify the relationship between different production stages, different data types, and carbon emissions, thereby establishing the calculation model.

[0076] The pre-processed data from multiple dimensions is fed into a pre-established computational model for calculation. The data is calculated one by one according to the calculation methods and formulas specified in the model. For example, in a physicochemical-based model, the carbon dioxide emissions are calculated based on the type of fuel, combustion efficiency, and collected energy consumption data; in a statistical analysis-based model, the overall carbon emissions of the enterprise are calculated based on various data from different production stages and relationships established with historical data. In this way, carbon data is obtained by calculating based on data from multiple dimensions.

[0077] Step S102: Generate a dynamic key based on the device information of the IoT device and the acquisition parameters corresponding to the carbon data, and use the dynamic key to encrypt the carbon data to obtain encrypted carbon data.

[0078] In this embodiment of the application, a dynamic key is generated based on the device information of the IoT device and the acquisition parameters corresponding to the carbon data, such as... Figure 3 As shown, it includes the following steps B1-B3:

[0079] Step B1: Obtain the device model and device type of the IoT device.

[0080] Specifically, firstly, a detailed device information database is established within the enterprise's IoT device management system. This database requires the entry of relevant information for each IoT device during initial network access or deployment. The device model is a specific identifier assigned by the device manufacturer to distinguish different versions or specifications of the same type of device. During device access, the device model is accurately extracted using the device's own identification information or information explicitly recorded in the configuration file and stored in the corresponding device record in the device information database. Device types are categorized based on their functions and characteristics in carbon emission monitoring and data collection. For example, they can be classified as sensor types (such as temperature sensors and pressure sensors used to collect various environmental data), data acquisition devices (responsible for collecting and aggregating data from multiple sensors), and controller types (used to control and regulate the operating status of other devices, indirectly affecting carbon emissions). During device deployment, staff determine the device type based on its actual use and function and similarly enter this information into the corresponding record in the device information database. In this way, when it is necessary to obtain the device model and device type of an IoT device, one only needs to query this established device information database according to the device's unique identifier (such as the device's MAC address) to quickly and accurately extract the corresponding device model and device type information.

[0081] Step B2: Obtain the collection timestamp and data type corresponding to the carbon data.

[0082] Specifically, in a company's carbon emission data acquisition system, each piece of carbon data collected is assigned a timestamp. This timestamp is typically generated automatically by the data acquisition device or software at the moment of acquisition, precisely recording the exact time of carbon data collection, and can be in a common time format. When the timestamp corresponding to carbon data needs to be obtained, the corresponding timestamp field can be found directly in the database table structure storing the carbon data, and the accurate timestamp for each piece of carbon data can be extracted from it. Regarding data types, the data types collected by different acquisition devices are already defined when the company sets key monitoring indicators for carbon emission sources and deploys relevant acquisition devices. For example, some devices collect temperature data, and their data type is "temperature"; others collect energy consumption data, and their data type is "energy consumption," etc. During carbon data storage, a dedicated data type field is also set in the database table structure to record the specific data type of each piece of carbon data. Therefore, to obtain the data type corresponding to carbon data, simply query the corresponding dataset from the database storing the carbon data according to the data record's index or unique identifier, and then extract the accurate data type information from the data type field.

[0083] Step B3: Generate a dynamic key based on the device model, device type, collection timestamp, and data type.

[0084] Specifically, generating a dynamic key based on device model, device type, data acquisition timestamp, and data type includes: obtaining an encoding mapping table, wherein the encoding mapping table includes digital codes corresponding to preset device model, preset device type, and preset data type; obtaining a first digital code corresponding to the device model, a second digital code corresponding to the device type, and a third digital code corresponding to the data type from the encoding mapping table; concatenating the first digital code, the second digital code, the third digital code, and the timestamp to obtain an initial data sequence; performing a hash algorithm on the initial data sequence to obtain a hash code, and extracting a code of a preset length from the hash code as the initial dynamic key; and transforming a portion of the code in the initial dynamic key to obtain the dynamic key.

[0085] It's important to note that generating dynamic keys by acquiring the device model, device type, and corresponding collection timestamp and data type of the carbon data from IoT devices achieves highly targeted and dynamic encryption of carbon data. Using an encoding mapping table, different device models, types, and data types are assigned digital codes, allowing various types of information to participate in key generation in a standardized and digital form. This not only facilitates unified management and processing but also ensures that each device and its corresponding data have a unique identifier for key construction. After concatenating these codes with the collection timestamp to form an initial data sequence, a hash algorithm is used to obtain a hash code, which is then truncated to a preset length as the initial dynamic key. This fully utilizes the one-wayness and collision resistance of hash algorithms to ensure the security and uniqueness of the key. Furthermore, transforming a portion of the encoding in the initial dynamic key to obtain the final dynamic key further increases the key's complexity and randomness, significantly improving the confidentiality and integrity of carbon data during transmission and storage. This effectively prevents risks such as data leakage and tampering, providing reliable protection for the secure processing of enterprise carbon emission data.

[0086] Specifically, enterprises or related technical teams need to pre-define a coding mapping table based on the characteristics of the IoT devices and carbon emission data involved in their business. The purpose of this table is to uniformly digitize different device models, device types, and data types to facilitate standardized processing and calculations in the future.

[0087] When constructing the coding mapping table, for preset device models, the specific models of all IoT devices used by the enterprise should be listed one by one, such as device model A, device model B, etc., and then a unique numerical code should be assigned to each device model. For example, device model A corresponds to numerical code 1001, device model B corresponds to 1002, and so on. These codes can be assigned according to certain rules, such as the order of device release or functional characteristics, but it must be ensured that each model has exactly one corresponding numerical code to avoid confusion. Similarly, for preset device types, based on the functional classification of the device in the entire carbon emission monitoring and data acquisition system, such as sensor type, data acquisition device type, controller type, etc., a specific numerical code is assigned to each device type. For example, sensor type devices are uniformly coded as 2001, data acquisition device type as 2002, controller type as 2003, etc. For preset data types, considering that the collected carbon data includes multiple types, such as temperature data, flow data, energy consumption data, etc., a corresponding numerical code is also set for each data type. For example, temperature data is coded as 3001, flow data as 3002, energy consumption data as 3003, etc. Through such meticulous coding settings, the coding mapping table is constructed, which will serve as an important basis for subsequent data processing.

[0088] When it is necessary to generate a dynamic key, determine the device model, device type, and carbon data data of the IoT devices involved, and obtain their respective digital codes from the pre-built encoding mapping table.

[0089] Specifically, by querying the encoding mapping table, the entry that perfectly matches the current device model is found, and the corresponding first numerical code is extracted. For example, if the current device model is device model A mentioned earlier, then its corresponding numerical code 1001 is obtained from the encoding mapping table as the first numerical code. Next, following the same query method, the record matching the current device type is found in the encoding mapping table, and its corresponding second numerical code is obtained. For example, if the current device type is a sensor, then its corresponding code 2001 is obtained as the second numerical code. Finally, based on the data type of the collected carbon data, the corresponding third numerical code is searched again in the encoding mapping table and obtained. Assuming that temperature data is collected, then 3001 is obtained from the encoding mapping table as the third numerical code.

[0090] After obtaining the first digital code corresponding to the device model, the second digital code corresponding to the device type, and the third digital code corresponding to the data type, the next step is to concatenate these codes with the timestamp of the carbon data collection to form an initial data sequence. The collection timestamp is usually a number or string representing a specific point in time. Assume the collection timestamp is represented in seconds as 1698573000 (this is just an example). The first, second, and third digital codes, along with the collection timestamp, are concatenated in a specific order. For example, they can be arranged in the order of device model code, device type code, data type code, and collection timestamp, forming an initial data sequence similar to [1001, 2001, 3001, 1698573000]. This initial data sequence will serve as the input data for subsequent hash operations.

[0091] Choose a hash algorithm such as SHA-256 (SecureHashAlgorithm 256-bit). Hash algorithms are characterized by one-wayness and collision resistance, and can convert input data into a fixed-length hash value. Take the previously concatenated initial data sequence as input and perform the operation using the selected hash algorithm. For example, hashing [1001, 2001, 3001, 1698573000] using SHA-256 will yield a 256-bit hash code. Then, based on the key length requirements of the actual application scenario, as well as subsequent encryption operations and system compatibility, the length of the hash code to be truncated is predetermined as the length of the initial dynamic key. For example, considering the adaptability of the encryption algorithm to the key length and the efficiency of data transmission and storage, a truncated 128-bit length is set as the initial dynamic key length. Once the preset length is determined, a corresponding length of code segment is truncated from the generated hash code according to specific rules as the initial dynamic key.

[0092] Finally, the initial dynamic key is divided into multiple coding groups, and the algorithm corresponding to each coding group is obtained; the algorithm is used to replace the characters in the corresponding coding group, or the algorithm is used to shift the characters in the corresponding coding group to obtain the adjusted coding group; the adjusted coding group is recombined to obtain the dynamic key.

[0093] Specifically, firstly, the initial dynamic key is segmented according to pre-defined rules. These rules can be determined based on factors such as key length, data type, or specific encoding patterns. For example, if the initial dynamic key is a 128-bit string (for ease of explanation, let's assume it's represented in hexadecimal, such as: 3A5B7C9D1E2F4A6B8C9D0E1F2A3B4C5D6E7F8A9B), it can be segmented into groups of 16 bits each, resulting in 8 encoded groups: [3A5B7C9D1E2F4A6B], [8C9D0E1F2A3B4C5D], [6E7F8A9B] (only the first 3 are shown here; the complete segmentation should consist of 8 groups), etc.

[0094] Next, a corresponding algorithm needs to be determined for each segmented coding block. This is achieved based on a pre-designed algorithm mapping mechanism. This mechanism can associate coding blocks with algorithms based on various factors, such as the position of the coding block in the key, the data characteristics contained in the coding block, or specific rules related to the system.

[0095] For example, for the first encoding group [3A5B7C9D1E2F4A6B], according to the algorithm mapping mechanism, its corresponding algorithm is determined to be a character substitution algorithm based on the XOR operation. For the second encoding group [8C9D0E1F2A3B4C5D], the corresponding algorithm is based on cyclic shifting. This algorithm allocation method is to ensure that the final generated dynamic key has higher randomness and security by processing different parts of the encoding through different transformation methods.

[0096] Processing based on character substitution algorithms (taking XOR operation as an example): For code groups that are determined to use character substitution algorithms, such as the XOR operation-based case mentioned above. Suppose there is a code group [3A5B7C9D1E2F4A6B], and a predetermined XOR key (also in hexadecimal form, such as: 123456789ABCDEF0).

[0097] Perform an XOR operation on each character (each hexadecimal bit) in the encoding group and the corresponding character in the XOR key. For example, the first character "3" in the encoding group is XORed with the first character "1" in the XOR key: 3XOR 1 = 2 (hexadecimal operation). Repeat this process for the other characters in the encoding group to obtain the replaced encoding group. Assume the new encoding group after the complete operation is [28692A050F0B5A7B] (this is just an example result; the actual operation depends on the specific data).

[0098] Processing based on character shift algorithms (taking cyclic shift as an example): For a character shift algorithm to be used, such as the previously mentioned cyclic shift-based character shift character shift [8C9D0E1F2A3B4C5D]. Assume the cyclic shift rule is to shift 3 positions to the left. Then, the first character "8" in the character shifts 3 positions to the left and becomes "C" (in hexadecimal cyclic order), the second character "C" shifts 3 positions to the left and becomes "F", and so on. All characters in the character shift character shift are processed according to the set cyclic shift rule to obtain the adjusted character shift character. Assume that after complete calculation, the new character shift character is [CFD03E4F5A6B7C8D] (this is only an example result; actual calculations depend on specific data).

[0099] After processing each coding group using appropriate algorithms to obtain adjusted coding groups, these adjusted coding groups need to be reassembled in a certain order to form the final dynamic key. This reassembly order can be based on the original order of the coding groups in the initial dynamic key, or it can be determined according to other specific rules. For example, if the initial splitting was done sequentially from left to right to obtain the coding groups, then the reassembly can also be done sequentially from left to right to concatenate the adjusted coding groups.

[0100] Assuming that the previous processing yielded 8 adjusted coding groups (for simplicity, different coding groups are represented by symbols, such as coding group 1 as [28692A050F0B5A7B], coding group 2 as [CFD03E4F5A6B7C8D], etc.), these coding groups are concatenated sequentially according to a determined reassembly order (assuming the original order) to obtain the final dynamic key.

[0101] For example, the dynamic key obtained by concatenating code group 1, code group 2, etc., in sequence is: 28692A050F0B5A7BCFD03E4F5A6B7C8D… (The content of other code groups concatenated later is omitted here; it should actually be a complete concatenation of all adjusted code groups). Through this recombination operation, the final dynamic key is generated from the transformed code groups. This dynamic key has higher randomness and security than the initial dynamic key and can be used for subsequent encryption, decryption, and other related operations.

[0102] It should be noted that dividing the initial dynamic key into multiple coding groups and determining the corresponding algorithm for each coding group increases the complexity and diversity of key generation. By using different algorithms to replace or shift characters in the corresponding coding groups to obtain adjusted coding groups, not only is the original order and meaning of the characters effectively disrupted, but the original form of the key is further obscured, greatly improving the confidentiality and security of the key. Finally, the adjusted coding groups are recombined to obtain the final dynamic key. Combining the transformation effects of the previous steps, the generated dynamic key possesses a high degree of randomness and complexity. This effectively prevents the illegal acquisition, tampering, or leakage of carbon data during transmission and storage, strongly guaranteeing the security of enterprise carbon emission data.

[0103] Step S103: Send encrypted carbon data and dynamic key to the blockchain node. The blockchain node verifies the encrypted carbon data and dynamic key to obtain the verification result.

[0104] In this embodiment of the application, the encrypted carbon data and dynamic key are verified through a blockchain node to obtain the verification result, such as... Figure 4 As shown, the steps include C1-C5:

[0105] Step C1: Use a preset verification mechanism to extract the data source corresponding to the encrypted carbon data and the relevant feature information in the dynamic key.

[0106] Specifically, encrypted carbon data typically embeds identifying information during its generation to indicate its source. A pre-defined verification mechanism first identifies the storage location and format of this identifying information. For example, the header or specific fields of the encrypted carbon data may contain unique identifiers for IoT devices (such as MAC addresses, device serial numbers, etc.) and relevant environmental information about the data collection environment (such as collection location, workshop, etc.). Through specific decoding or parsing programs, this key information that clearly identifies the data source is extracted from the encrypted data according to pre-set rules.

[0107] For dynamic keys, there are also some relevant characteristics that can be used for verification. This information includes the hash values ​​of some key parameters used in the key generation process, the key length characteristics, and patterns in characters or character combinations at specific positions. The default verification mechanism uses appropriate analysis tools and algorithms to analyze the dynamic key and extract this information that reflects its generation characteristics. For example, if the dynamic key is generated using device model, type, acquisition timestamp, and data type, the verification mechanism will extract certain encoding or hash features related to these parameters for subsequent comparison and verification with records in the blockchain nodes.

[0108] Step C2: Based on the preset consensus algorithm and preset contract, query the list of authorized devices already on the blockchain node. If the IoT device corresponding to the data source belongs to the list of authorized devices, then use the key generation algorithm and historical keys stored in the blockchain node.

[0109] Specifically, the pre-defined consensus algorithm and pre-defined contracts define various rules and operational procedures within the blockchain network. During the verification process, firstly, based on these rules, the system uses query interfaces provided by the blockchain nodes to search for records in the existing list of authorized devices stored on the blockchain that match the data source information extracted from the encrypted carbon data. This list of authorized devices is rigorously reviewed and managed, containing detailed information about IoT devices that the company is permitted to access and provide valid carbon data, such as device model, serial number, and department.

[0110] If the query results indicate that the IoT device corresponding to the data source belongs to the authorized device list, this means that the device is qualified to provide legitimate carbon data. At this point, further verification can be performed using the relevant resources stored in the blockchain nodes. The key generation algorithm stored in the blockchain nodes is a standard algorithm used to generate dynamic keys, and its parameters and rules are fixed and known. Historical keys are records of valid dynamic keys generated in similar situations in the past; these records can be used as a reference to verify the rationality of the current dynamic key.

[0111] Step C3: Verify the correctness of the dynamic key generation logic using the key generation algorithm and historical keys.

[0112] Specifically, the key generation algorithm obtained from the blockchain nodes is the core basis for verifying the dynamic key generation logic. The relevant feature information extracted from the dynamic key (such as that extracted in step C1 above) is compared with the features that a virtual dynamic key should possess according to the key generation algorithm. For example, if the key generation algorithm specifies that a dynamic key is generated by performing hash operations in a specific order based on the device model, device type, acquisition timestamp, and data type, then in the same way, using these parameters extracted from the encrypted carbon data and the dynamic key, a temporary dynamic key is regenerated using the algorithm, and its features are compared one by one with the features of the actually provided dynamic key to check for differences, such as whether the hash values ​​are consistent or whether the key parameter encodings match.

[0113] Historical keys record the valid dynamic keys generated under normal circumstances in the past. By analyzing the similarities and differences between the current dynamic key and historical keys, we can further determine whether its generation logic is reasonable. For example, observe whether the length and character distribution of the current dynamic key are consistent with the performance of historical keys under similar circumstances. If there are significant differences that cannot be reconciled with a reasonable explanation, it indicates that there is a problem with the dynamic key generation logic.

[0114] Step C4: If the dynamic key generation logic is correct, then the encrypted carbon data is decrypted to obtain the carbon data.

[0115] Specifically, once the dynamic key generation logic is verified to be correct, it means that the received encrypted carbon data and the dynamic key are a match and valid. This satisfies the basic condition for decrypting the encrypted carbon data, because only the correctly generated dynamic key can accurately decrypt the carbon data it encrypts.

[0116] The encrypted carbon data is decrypted using a decryption algorithm corresponding to the encryption algorithm (usually paired with the encryption algorithm, such as AES encryption and AES decryption in symmetric encryption), with the correct dynamic key as input. The decryption algorithm reverses the encryption process according to its internal mathematical rules, gradually restoring the original carbon data. For example, if encryption involves specific bitwise transformations (such as XOR or shift operations) on the carbon data, decryption follows the reverse transformation rules, using the dynamic key to restore the encrypted carbon data to its original unencrypted state, thus obtaining the original carbon data.

[0117] Step C5 involves verifying the carbon data based on the data specifications on the blockchain node to obtain the verification results.

[0118] Specifically, the data specifications on blockchain nodes are a set of pre-defined standards regarding carbon data formats, value ranges, and data integrity. These specifications include what the unit of carbon data should be (e.g., tons of carbon dioxide equivalent), whether the value ranges for different types of carbon data (e.g., direct carbon emissions, indirect carbon emissions, etc.) are reasonable (e.g., the direct carbon emissions of a certain type of production process should not exceed a certain specific value), and whether the data is complete (whether it contains all the necessary fields and information), etc.

[0119] The decrypted carbon data is compared one by one with the data specifications on the blockchain nodes. This involves checking whether the units of the carbon data conform to the specifications, whether the value range is within a reasonable range, and whether it contains complete information. For example, if the data specification stipulates that the unit for carbon data related to energy consumption in a certain production process is "tons of CO2 equivalent per hour," then the unit of the decrypted carbon data for that process is checked to ensure it matches. If the data specification sets the value range for a certain type of carbon data to be between [0, 100], then the value of the decrypted carbon data for that type is checked to ensure it falls within this range. Additionally, it is necessary to check whether the carbon data contains necessary information such as collection time and data source.

[0120] Based on the comparison results above, a verification result is generated. If the carbon data conforms to the data specifications on the blockchain node in terms of format, value range, and data integrity, the verification result is "passed"; otherwise, if any non-compliance exists, the verification result is "failed". This verification result will serve as an important basis for further processing of the carbon data (such as analysis using smart contracts).

[0121] Step S104: If the verification result is that the encrypted carbon data and the dynamic key are verified, then select a target smart contract that matches the encrypted carbon data based on the multiple smart contracts deployed in the blockchain node, and use the target smart contract to analyze the encrypted carbon data to obtain evaluation information.

[0122] In this embodiment, once the verification results show that both the encrypted carbon data and the dynamic key have passed verification, the next step is to select a target smart contract that matches the encrypted carbon data from among the multiple smart contracts deployed on the blockchain node. First, the encrypted carbon data is analyzed in detail to clarify its various key information, such as data source, data type (whether it's carbon emission data related to energy consumption or carbon emission data from a specific stage of the production process), and collection timestamp. Then, the applicable conditions and rules set by each smart contract deployed on the blockchain node are examined one by one. These smart contracts are given specific functions and processing logic for different situations when they are created. For example, some smart contracts may be specifically designed to analyze carbon emission data generated by a particular type of production equipment, and their applicable conditions will explicitly stipulate that the data type must be carbon emission data related to that equipment and the collection time must be within a specific time period. By meticulously comparing the key information of encrypted carbon data with the applicable conditions of various smart contracts, the smart contract that best matches the encrypted carbon data in terms of data type, collection time, data source, and other aspects is identified and designated as the target smart contract that matches the encrypted carbon data, so that it can be used for more targeted analysis and processing of the encrypted carbon data in the future.

[0123] In this embodiment of the application, the target smart contract is used to analyze the encrypted carbon data to obtain evaluation information, such as... Figure 5 As shown, it includes the following steps D1-D5:

[0124] Step D1: Extract data extraction strategies and data analysis strategies from the target smart contract.

[0125] Specifically, a target smart contract is program code deployed on a blockchain node specifically for processing encrypted carbon data. It contains a series of predefined rules and operational logic. Smart contracts are typically written in a programming language (such as Solidity, a programming language suitable for blockchain), and their code structure is organized into different parts such as functions, variables, and conditional statements.

[0126] The smart contract code explicitly defines how to extract useful information from the received encrypted carbon data (referring to the carbon data obtained after decryption in the previous steps). This is the data extraction strategy. It involves determining which types of data to extract from which locations based on the specific format of the carbon data (such as following a certain field order, data type markers, etc.). For example, if the carbon data is stored in JSON format, the data extraction strategy might specify extracting the value under a specific key-value pair as the key data element, such as extracting the value of "carbonEmissionValue" under the key "emissionData".

[0127] Simultaneously, smart contracts also define specific methods for further analysis of the extracted key data elements, i.e., data analysis strategies. This includes the statistical analysis methods used (such as mean and variance calculations), time series analysis (such as trend analysis and seasonality analysis), or correlation analysis. For example, a data analysis strategy might specify to perform trend analysis on carbon emission data from different time periods to observe the changing trends of carbon emissions, or to perform correlation analysis on carbon emission and production data to determine the degree of correlation between the two.

[0128] Step D2: Extract key data elements from the carbon data obtained by encrypting the encrypted carbon data according to the data extraction strategy.

[0129] Specifically, first, the carbon data needs to be parsed according to its actual storage format. If the carbon data is stored in a database table structure, then it's necessary to understand the meaning of the fields, their data types, and the relationships between them. If it's in other formats, such as XML or JSON, then it's equally important to be familiar with their syntax and data organization. For example, for JSON-formatted carbon data, it's crucial to understand the meaning of each key and the type of its corresponding value.

[0130] Following the data extraction strategy extracted from the target smart contract, specific extraction operations are performed on the parsed carbon data. For example, if the data extraction strategy specifies extracting carbon emission information related to production equipment, then the identification field of the corresponding equipment (such as equipment number) is located in the carbon data, and then relevant data such as carbon emissions and operating time of that equipment at different time periods are extracted as key data elements. Similarly, if the strategy requires extracting energy consumption data and corresponding carbon emissions for a specific production stage, the relevant records for that stage are located in the carbon data, and the energy consumption and carbon emission values ​​are extracted as key data elements.

[0131] Step D3: Compare key data elements with data values ​​of different types to obtain comparison results;

[0132] Specifically, the different types of data values ​​mentioned here typically refer to pre-defined standard values, industry averages, and company-specific target values. For example, for carbon emission data, there may be national or regional industry average carbon emission standards, as well as internal carbon emission targets set by companies to achieve their emission reduction goals. These different types of data values ​​will serve as references for comparison with key data elements.

[0133] Key data elements extracted from carbon data are compared one by one with these different types of data values. For example, the actual carbon emissions (key data element) of a production workshop are compared with the industry average carbon emission standard to see if they are higher or lower than the standard; the carbon emissions corresponding to the energy consumption of a company over a certain period are compared with the company's internally set target value to check whether the target requirements have been met. The comparison operation can use different methods depending on the type of data and specific requirements, such as simple numerical comparison, percentage calculation, etc.

[0134] Based on the results of the comparison operation, comparison results are generated. These results can be described simply (e.g., "above industry average," "below company target") or expressed in more specific numerical values ​​(e.g., actual carbon emissions are many tons higher than the industry average). These comparison results will provide important information for subsequent assessment.

[0135] Step D4: Analyze the key data elements according to the data analysis strategy to obtain process parameters and correlation parameters.

[0136] Specifically, based on the data analysis strategy extracted from the target smart contract, specific analysis operations are performed on the extracted key data elements. For example, if the data analysis strategy specifies time series analysis, then the carbon emission data in the key data elements are arranged in chronological order, and then time series analysis methods (such as moving average method, exponential smoothing method, etc.) are used to analyze its changing trend, obtaining process parameters of carbon emissions changing over time, such as the growth rate of carbon emissions and the amplitude of fluctuations.

[0137] Data analysis strategies also include correlation analysis, which involves performing correlation analysis on carbon emissions data, a key data element, with other relevant data (such as production volume and energy consumption). Correlation coefficients (such as the Pearson correlation coefficient) are calculated to determine the degree of association between carbon emissions and other factors, thus obtaining correlation parameters. For example, a Pearson correlation coefficient of 0.8 between carbon emissions and production volume indicates a strong correlation between the two, and this coefficient is a correlation parameter.

[0138] As an example, (1) process parameters are analyzed through time series analysis (taking carbon emissions as an example). The trend analysis is as follows:

[0139] If the data has a clear time sequence, moving averages or exponential smoothing can be used. For moving averages, choose an appropriate window size (e.g., a 5-day moving average) and calculate the moving average for each time point to observe short-term trends in carbon emissions. For exponential smoothing, determine a smoothing constant (e.g., α = 0.3) to obtain a smoothed carbon emissions sequence and analyze long-term trends. Alternatively, a trend line can be fitted, such as using a linear regression model to fit the trend of carbon emissions over time. Assuming time is the independent variable and carbon emissions are the dependent variable, the slope of the fitted linear equation represents the trend parameter of carbon emissions, indicating the rate of change of carbon emissions per unit time.

[0140] The seasonality and cyclicality analysis are as follows:

[0141] Seasonal decomposition methods (such as additive or multiplicative models) can be used to decompose carbon emissions data into trend, seasonal, and residual components. For example, if significant fluctuations in carbon emissions are observed during specific seasons of the year (such as the winter heating season), the impact of seasonal factors on carbon emissions can be analyzed. The periodicity of the data can be analyzed using the autocorrelation function (ACF) and partial autocorrelation function (PACF). If the ACF has a significant peak at a specific lag order, it may indicate the existence of corresponding cyclical fluctuations. For example, finding a peak in the ACF at a 12-month lag may suggest an annual cycle in carbon emissions.

[0142] Volatility analysis is as follows:

[0143] Calculate statistics such as the standard deviation and coefficient of variation for carbon emission data. The standard deviation measures how much the data is dispersed around the mean, while the coefficient of variation (standard deviation divided by the mean) can be used to compare the volatility of data at different magnitudes. For example, calculate the standard deviation of carbon emissions for each month to assess the stability of carbon emissions.

[0144] Other process parameter analysis (taking production process-related data as an example):

[0145] Equipment operating efficiency analysis: Calculate the equipment's output per unit time, i.e., production efficiency, based on equipment operating time and output. For example, if the equipment operates for 500 hours in a month and produces 10,000 units, the production efficiency is 20 units / hour. Observe the changes in production efficiency over time to analyze the stability and trend of the equipment's operating status.

[0146] Energy efficiency analysis: This involves calculating energy consumption per unit of output, such as electricity consumption per ton of product. If electricity consumption per unit of output gradually increases over a period of time, it may indicate a decline in energy efficiency, requiring further inspection of equipment or production processes.

[0147] (2) Analyze correlation parameters, including correlation analysis, regression analysis, causal analysis, etc.

[0148] The correlation analysis is as follows:

[0149] Calculate correlation coefficients: Use methods such as Pearson correlation coefficient and Spearman's rank correlation coefficient to calculate the correlation between key data elements. For example, calculate the Pearson correlation coefficient between carbon emissions and energy consumption (such as electricity consumption). If the correlation coefficient is close to 1, it indicates a strong positive correlation, meaning that higher electricity consumption leads to higher carbon emissions; if it is close to -1, it indicates a strong negative correlation; and if it is close to 0, it indicates a weak correlation.

[0150] Create a correlation matrix or heatmap: Display the correlation coefficients between all key data elements in the form of a matrix or heatmap to visually observe the relationships between different data elements. For example, you can quickly see the strength of the correlation between carbon emissions and multiple factors such as production, energy consumption, and equipment operating parameters.

[0151] The regression analysis is as follows:

[0152] Multiple linear regression (with carbon emissions as the dependent variable): If correlation analysis shows that carbon emissions are related to multiple factors (such as energy consumption, output, and ambient temperature), a multiple linear regression model can be established. For example, assuming that carbon emissions are related to electricity consumption, output, and ambient temperature, a model can be built. Regression coefficients are estimated using methods such as least squares to analyze the degree of influence of each independent variable on carbon emissions. For example, it represents the magnitude of the impact of changes in unit electricity consumption on carbon emissions.

[0153] Model Evaluation: Statistical tests are used to evaluate the significance and goodness of fit of the regression model. The significance test is used to examine the overall significance of the model, i.e., whether the independent variables have a significant effect on the dependent variable; the coefficient test is used to examine whether the coefficient of each independent variable is significantly different from zero. Simultaneously, the coefficient of determination can be calculated, representing the degree of model fit to the data; the closer it is to 1, the better the model fit.

[0154] The causal analysis is as follows:

[0155] If further determination of the causal relationship between variables is needed, methods such as Granger causality tests can be used. For example, testing whether electricity consumption is a Granger cause of carbon emissions—that is, whether past electricity consumption data can help predict carbon emissions—can be conducted. If the test results indicate that electricity consumption is a Granger cause of carbon emissions, then optimizing electricity usage can be a key consideration when formulating emission reduction strategies.

[0156] Step D5: Generate evaluation information based on the comparison results, process parameters, and correlation parameters.

[0157] Specifically, the comparison results, process parameters, and correlation parameters are integrated. For example, information such as the comparison results of carbon emissions with the industry average, process parameters of carbon emissions changing over time (such as growth rate), and correlation parameters between carbon emissions and production (such as correlation coefficient) are collected to form a comprehensive dataset.

[0158] Based on the integrated dataset, assessment information is generated. This assessment information can include an overall evaluation of the company's carbon emissions (e.g., "The company's carbon emissions are at a medium level in the industry, but the growth rate is relatively fast and closely related to production output"), specific evaluations of different production stages or equipment (e.g., "The carbon emissions of a certain production equipment are higher than the industry average and are highly correlated with energy consumption"), and an assessment of the company's emission reduction potential (e.g., "Based on current carbon emission trends and related factors, the company has significant emission reduction potential in optimizing its energy structure"). This assessment information will provide important references for companies to understand their own carbon emission status and formulate emission reduction strategies.

[0159] It's important to note that extracting data extraction and analysis strategies from the target smart contract ensures a standardized and targeted process. The predefined rules of the smart contract guarantee consistency and accuracy in the processing. Extracting key data elements from encrypted carbon data according to the data extraction strategy accurately identifies data valuable for the assessment, avoids interference from irrelevant information, and improves processing efficiency. Comparing key data elements with different types of data yields comparative results, clearly showing the differences between a company's carbon emissions and standard, target, or other reference values, allowing the company to clearly understand its emission levels within a specific range. Analyzing key data elements using the data analysis strategy yields process and correlation parameters, which helps to gain a deeper understanding of the dynamic trends in carbon emissions and their intrinsic relationships with other relevant factors. Finally, based on the comparison results, process parameters, and correlation parameters, assessment information is generated, providing companies with comprehensive, in-depth, and valuable carbon emission assessment content. This assists companies in making precise decisions, such as formulating emission reduction strategies and optimizing production processes, to better address carbon emission-related issues and achieve sustainable development goals.

[0160] This application first acquires carbon data collected by IoT devices. Based on the device information and the corresponding acquisition parameters of the carbon data, a dynamic key is generated. This dynamic key is then used to encrypt the carbon data, resulting in encrypted carbon data. This process provides robust encryption protection, ensuring high confidentiality and integrity during transmission and storage, effectively addressing the problems of low data security and lack of effective encryption protection. Next, the encrypted carbon data and the dynamic key are sent to a blockchain node for verification. The blockchain node's verification mechanism ensures the legality of the data source and the correctness of the key generation logic, further guaranteeing data security and reliability. Once the verification is successful, multiple smart contracts deployed on the blockchain node select a matching target smart contract based on the characteristics of the encrypted carbon data. This target smart contract is then used to analyze the encrypted carbon data, achieving intelligent and automated analysis. This allows for in-depth mining of the value behind the data, such as carbon emission trends and their correlation with various factors in the production process, thereby accurately assessing a company's carbon emission level within the industry and compensating for the shortcomings of traditional analysis methods in terms of intelligence and automation.

[0161] In this embodiment, the construction process of the blockchain network is as follows: Based on the enterprise's size, data processing volume, and security requirements for carbon emission data management, suitable hardware devices are selected as nodes. These devices should have stable network connectivity, sufficient storage capacity, and computing power. Simultaneously, the geographical distribution of the nodes needs to be determined. Nodes can be set up in different data centers or key departments within the enterprise to ensure distributed data storage and high availability.

[0162] After determining the blockchain nodes, the steps for building a blockchain network are as follows: Initialize the configuration of each node, installing blockchain-related software platforms and protocols, such as selecting a suitable underlying blockchain framework (e.g., Ethereum, Hyperledger). Generate a unique identity and key pair for each node for communication authentication and permission management. Establish network connections between nodes, enabling them to communicate by configuring network parameters (e.g., IP address, port number). Next, determine the blockchain's consensus mechanism (e.g., Proof-of-Work, Proof-of-Stake, Practical Byzantine Fault Tolerance), which will determine how nodes reach consensus on new data blocks. Then, create a genesis block, defining the initial state of the blockchain, including the initial carbon emission data structure, smart contract templates, etc. Subsequently, as IoT devices collect carbon data, nodes begin receiving encrypted carbon data and dynamic keys, verifying and storing the data based on the consensus mechanism, adding new data blocks to the blockchain, and gradually building a complete blockchain network, providing a reliable infrastructure for subsequent processing and analysis of encrypted carbon data.

[0163] This embodiment also provides a blockchain-based carbon data processing device for implementing the above embodiments and preferred embodiments; details already described will not be repeated. As used below, the term "module" can refer to a combination of software and / or hardware that performs a predetermined function. Although the device described in the following embodiments is preferably implemented in software, hardware implementation, or a combination of software and hardware, is also contemplated.

[0164] This embodiment provides a blockchain-based carbon data processing device, such as... Figure 6 As shown, it includes:

[0165] The acquisition module 601 is used to acquire carbon data collected by IoT devices from the carbon emission sources of an enterprise;

[0166] The generation module 602 is used to generate a dynamic key based on the device information of the Internet of Things device and the collection parameters corresponding to the carbon data, and to encrypt the carbon data using the dynamic key to obtain encrypted carbon data.

[0167] The sending module 603 is used to send encrypted carbon data and dynamic keys to the blockchain node, and the blockchain node verifies the encrypted carbon data and dynamic keys to obtain the verification result.

[0168] Analysis module 604 is used to select a target smart contract that matches the encrypted carbon data based on multiple smart contracts deployed in the blockchain node if the verification result is that the encrypted carbon data and the dynamic key verification are successful, and to use the target smart contract to analyze the encrypted carbon data to obtain evaluation information.

[0169] In this embodiment of the application, the acquisition module 601 is used to acquire indicator data of key monitoring indicators of the enterprise's carbon emission sources; if the indicator data reaches the preset threshold corresponding to the key monitoring indicator, a collection command is triggered; based on the collection command, the IoT device is controlled to collect data from the enterprise's carbon emission sources to obtain multiple collection data of different dimensions; based on the collection data of multiple different dimensions, carbon data is obtained.

[0170] In this embodiment, the generation module 602 is used to obtain the device model and device type of the Internet of Things device; obtain the collection timestamp and data type corresponding to the carbon data; and generate a dynamic key based on the device model, device type, collection timestamp and data type.

[0171] In this embodiment, the generation module 602 is used to obtain an encoding mapping table, wherein the encoding mapping table includes digital codes corresponding to a preset device model, a preset device type, and a preset data type, respectively; obtains a first digital code corresponding to the device model, a second digital code corresponding to the device type, and a third digital code corresponding to the data type from the encoding mapping table; concatenates the first digital code, the second digital code, the third digital code, and a timestamp to obtain an initial data sequence; performs a hash algorithm on the initial data sequence to obtain a hash code, and extracts a code of a preset length from the hash code as an initial dynamic key; transforms a portion of the code in the initial dynamic key to obtain a dynamic key.

[0172] In this embodiment of the application, the generation module 602 is used to divide the initial dynamic key into multiple coding groups and obtain the algorithm corresponding to each coding group; use the algorithm to replace the characters in the corresponding coding group, or use the algorithm to shift the characters in the corresponding coding group to obtain the adjusted coding group; and reassemble the adjusted coding group to obtain the dynamic key.

[0173] In this embodiment, the analysis module 604 is used to extract relevant feature information from the data source and dynamic key corresponding to the encrypted carbon data using a preset verification mechanism; according to a preset consensus algorithm and a preset contract, it queries the list of authorized devices already existing on the blockchain node; if the IoT device corresponding to the data source belongs to the list of authorized devices, it uses the key generation algorithm and historical keys stored in the blockchain node; it uses the key generation algorithm and historical keys to verify whether the generation logic of the dynamic key is correct; if the generation logic of the dynamic key is correct, it decrypts the encrypted carbon data to obtain the carbon data; and it verifies the carbon data based on the data specifications on the blockchain node to obtain the verification result.

[0174] In this embodiment, the analysis module 604 is used to extract a data extraction strategy and a data analysis strategy from the target smart contract; extract key data elements from the carbon data obtained by encrypting the encrypted carbon data according to the data extraction strategy; compare the key data elements with data values ​​of different types to obtain comparison results; analyze the key data elements according to the data analysis strategy to obtain process parameters and correlation parameters; and generate evaluation information based on the comparison results, process parameters, and correlation parameters.

[0175] Please see Figure 7 , Figure 7 This is a schematic diagram of the structure of a computer device provided in an optional embodiment of the present invention, such as... Figure 7 As shown, the computer device includes one or more processors 10, memory 20, and interfaces for connecting the components, including high-speed interfaces and low-speed interfaces. The components communicate with each other using different buses and can be mounted on a common motherboard or otherwise installed as needed. The processors can process instructions executed within the computer device, including instructions stored in or on memory to display graphical information of a GUI on external input / output devices (such as display devices coupled to the interfaces). In some alternative implementations, multiple processors and / or multiple buses can be used with multiple memories and multiple memory modules, if desired. Similarly, multiple computer devices can be connected, each providing some of the necessary operations (e.g., as a server array, a group of blade servers, or a multiprocessor system). The processor 10 can be a central processing unit, a network processor, or a combination thereof. The processor 10 may further include hardware chips. The hardware chips can be application-specific integrated circuits (ASICs), programmable logic devices (PLDs), or combinations thereof. The programmable logic devices can be complex programmable logic devices (CLPs), field-programmable gate arrays (FPGAs), general-purpose array logic (GPRS), or any combination thereof.

[0176] The memory 20 stores instructions executable by at least one processor 10 to cause the at least one processor 10 to perform the method shown in the above embodiments.

[0177] The memory 20 may include a program storage area and a data storage area. The program storage area may store the operating system and applications required for at least one function; the data storage area may store data created based on the use of the computer device as shown by a landing page for an app. Furthermore, the memory 20 may include high-speed random access memory and may also include non-transitory memory, such as at least one disk storage device, flash memory device, or other non-transitory solid-state storage device. In some alternative embodiments, the memory 20 may optionally include memory remotely located relative to the processor 10, which can be connected to the computer device via a network. Examples of such networks include, but are not limited to, the Internet, intranets, local area networks, mobile communication networks, and combinations thereof.

[0178] The memory 20 may include volatile memory, such as random access memory; the memory may also include non-volatile memory, such as flash memory, hard disk or solid-state drive; the memory 20 may also include a combination of the above types of memory.

[0179] The computer device also includes a communication interface 30 for communicating with other devices or communication networks.

[0180] This invention also provides a computer-readable storage medium. The methods described above according to embodiments of the invention can be implemented in hardware or firmware, or implemented as computer code that can be recorded on a storage medium, or implemented as computer code downloaded via a network and originally stored on a remote storage medium or a non-transitory machine-readable storage medium and then stored on a local storage medium. Thus, the methods described herein can be processed by software stored on a storage medium using a general-purpose computer, a dedicated processor, or programmable or dedicated hardware. The storage medium can be a magnetic disk, optical disk, read-only memory, random access memory, flash memory, hard disk, or solid-state drive, etc.; further, the storage medium can also include combinations of the above types of memory. It is understood that computers, processors, microprocessor controllers, or programmable hardware include storage components capable of storing or receiving software or computer code, which, when accessed and executed by the computer, processor, or hardware, implements the methods shown in the above embodiments.

[0181] Although embodiments of the invention have been described in conjunction with the accompanying drawings, those skilled in the art can make various modifications and variations without departing from the spirit and scope of the invention, and such modifications and variations all fall within the scope defined by the appended claims.

Claims

1. A blockchain-based carbon data processing method, characterized in that, The method includes: Acquire carbon data collected by IoT devices from the carbon emission sources of enterprises; A dynamic key is generated based on the device information of the IoT device and the collection parameters corresponding to the carbon data, and the carbon data is encrypted using the dynamic key to obtain encrypted carbon data. The encrypted carbon data and the dynamic key are sent to the blockchain node, and the blockchain node verifies the encrypted carbon data and the dynamic key to obtain the verification result. If the verification result is that the encrypted carbon data and the dynamic key are verified, then a target smart contract that matches the encrypted carbon data is selected based on the multiple smart contracts deployed in the blockchain node, and the encrypted carbon data is analyzed using the target smart contract to obtain evaluation information. The verification of the encrypted carbon data and the dynamic key through the blockchain node to obtain the verification result includes: extracting relevant feature information from the data source corresponding to the encrypted carbon data and the dynamic key using a preset verification mechanism. The relevant feature information includes the hash values ​​of some key parameters used in the key generation process, the key length characteristics, and the character or character combination patterns at specific positions; querying the list of authorized devices on the blockchain node according to a preset consensus algorithm and a preset contract; if the IoT device corresponding to the data source belongs to the list of authorized devices, then using the key generation algorithm and historical keys stored in the blockchain node, where the historical keys record the valid dynamic keys generated under normal circumstances in the past; verifying the correctness of the dynamic key generation logic using the key generation algorithm and the historical keys; if the dynamic key generation logic is correct, decrypting the encrypted carbon data to obtain the carbon data; and verifying the carbon data based on the data specifications on the blockchain node to obtain the verification result. The step of verifying the correctness of the dynamic key generation logic using the key generation algorithm includes: comparing the relevant feature information extracted from the dynamic key with the features that a virtual dynamic key should possess when regenerated according to the key generation algorithm. The step of using historical keys to verify whether the generation logic of dynamic keys is correct includes: observing whether the relevant feature information of the current dynamic key is consistent with the performance of historical keys under similar circumstances.

2. The method according to claim 1, characterized in that, The acquisition of carbon data obtained by IoT devices from enterprise carbon emission sources includes: Obtain the key monitoring data of the enterprise's carbon emission sources; If the indicator data reaches the preset threshold corresponding to the key monitoring indicator, a data collection command is triggered; Based on the acquisition command, the IoT device is controlled to collect data from the enterprise's carbon emission sources, resulting in multiple dimensions of collected data. The carbon data is obtained by calculating based on collected data from multiple different dimensions.

3. The method according to claim 1, characterized in that, The generation of a dynamic key based on the device information of the IoT device and the acquisition parameters corresponding to the carbon data includes: Obtain the device model and device type of the IoT device; Obtain the collection timestamp and data type corresponding to the carbon data; The dynamic key is generated based on the device model, the device type, the collection timestamp, and the data type.

4. The method according to claim 3, characterized in that, The process of generating the dynamic key based on the device model, device type, collection timestamp, and data type includes: Obtain an encoding mapping table, wherein the encoding mapping table includes numerical codes corresponding to preset device models, preset device types, and preset data types respectively; Obtain from the encoding mapping table the first digital code corresponding to the device model, the second digital code corresponding to the device type, and the third digital code corresponding to the data type; The initial data sequence is obtained by concatenating the first digital code, the second digital code, the third digital code, and the timestamp. The initial data sequence is processed using a hash algorithm to obtain a hash code, and a code of a preset length is extracted from the hash code as the initial dynamic key; The dynamic key is obtained by transforming a portion of the encoding in the initial dynamic key.

5. The method according to claim 4, characterized in that, The step of transforming a portion of the encoding in the initial dynamic key to obtain the dynamic key includes: The initial dynamic key is divided into multiple coding groups, and the algorithm corresponding to each coding group is obtained; The algorithm is used to replace characters in the corresponding encoding group, or the algorithm is used to shift characters in the corresponding encoding group to obtain the adjusted encoding group; The adjusted coding group is recombined to obtain the dynamic key.

6. The method according to claim 1, characterized in that, The process of analyzing the encrypted carbon data using the target smart contract to obtain evaluation information includes: Extract data extraction strategies and data analysis strategies from the target smart contract; Key data elements are extracted from the carbon data obtained by decrypting the encrypted carbon data according to the data extraction strategy described above. By comparing the key data elements with data values ​​of different types, the comparison results are obtained; The key data elements are analyzed according to the data analysis strategy described above to obtain process parameters and correlation parameters. The evaluation information is generated based on the comparison results, the process parameters, and the correlation parameters.

7. A blockchain-based carbon data processing device, characterized in that, The device includes: The acquisition module is used to acquire carbon data collected by IoT devices from the enterprise's carbon emission sources; The generation module is used to generate a dynamic key based on the device information of the Internet of Things device and the acquisition parameters corresponding to the carbon data, and to encrypt the carbon data using the dynamic key to obtain encrypted carbon data. A sending module is used to send the encrypted carbon data and the dynamic key to a blockchain node, and to verify the encrypted carbon data and the dynamic key through the blockchain node to obtain a verification result. The verification of the encrypted carbon data and the dynamic key through the blockchain node to obtain a verification result includes: extracting relevant feature information from the data source corresponding to the encrypted carbon data and the dynamic key using a preset verification mechanism; the relevant feature information includes the hash value of some key parameters used in the key generation process, the length characteristics of the key, and the character or character combination rules at specific positions; querying the list of authorized devices already existing on the blockchain node according to a preset consensus algorithm and a preset contract; if the IoT device corresponding to the data source belongs to the list of authorized devices, then using the key stored in the blockchain node to generate... The algorithm and historical keys are used to verify the correctness of the dynamic key generation logic. If the dynamic key generation logic is correct, the encrypted carbon data is decrypted to obtain carbon data. The carbon data is verified based on the data specifications on the blockchain node to obtain the verification result. Verifying the correctness of the dynamic key generation logic using the key generation algorithm includes comparing the relevant feature information extracted from the dynamic key with the features that a virtual dynamic key should possess when regenerated according to the key generation algorithm. Verifying the correctness of the dynamic key generation logic using historical keys includes observing whether the relevant feature information of the current dynamic key matches the performance of the historical key under similar conditions. The analysis module is used to select a target smart contract that matches the encrypted carbon data based on multiple smart contracts deployed in the blockchain node if the verification result is that the encrypted carbon data and the dynamic key are verified successfully, and to use the target smart contract to analyze the encrypted carbon data to obtain evaluation information.

8. A computer device, characterized in that, include: A memory and a processor, the memory and the processor being communicatively connected to each other, the memory storing computer instructions, the processor executing the computer instructions to perform the method of any one of claims 1 to 6.

9. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores computer instructions for causing a computer to perform the method of any one of claims 1 to 6.

Images