Campus carbon benefit system

Abstract

The invention relates to the technical field of carbon popularity management, in particular to a campus carbon popularity system which writes a carbon emission value into a personal carbon account of a corresponding user and calculates a user hash value; using the user hash value as a leaf node to calculate and obtain a root hash value of a hospital Merkel tree; taking the root hash value of the hospital Merkel tree as a leaf node to calculate and obtain a root hash value of the school-level Merkel tree; when a data verification request initiated by a target user is received, extracting brother node hash values from a hospital Merkel tree and forming a Merkel verification path; and calculating to obtain a verification root hash value by using a locally stored personal carbon emission value and a Merkel verification path, and when the verification root hash value is consistent with a root hash value of a hospital Merkel tree stored in the block chain network, determining that the personal carbon emission data of the target user has been correctly incorporated into hospital aggregation statistics. The problem of how to ensure the data credibility in the multi-level aggregation statistical process of the campus carbon popularity data is effectively solved.

Description

Technical Field

[0001] This invention relates to the field of carbon credit management technology, specifically a campus carbon credit system. Background Technology

[0002] Carbon inclusion is an incentive mechanism based on quantified carbon emission reductions. It aims to record and quantify the low-carbon behaviors of individuals or organizations, converting these behaviors into measurable carbon emission reduction figures, thereby generating corresponding incentives. The carbon inclusion mechanism has gradually extended from the general public to the education sector, with campus carbon inclusion emerging as a carbon emission reduction management model for university faculty and students. Campus carbon inclusion collects various behavioral data of faculty and students in their campus life, converts it into corresponding carbon emission or carbon emission reduction figures, and establishes a personal carbon account for each faculty member and student for recording and management, thereby achieving refined tracking and statistics of individual carbon footprints on campus.

[0003] However, campus carbon credit systems face significant challenges in data credibility during actual operation. Due to the hierarchical nature of campus organizational structures, individual carbon emission data needs to be aggregated and statistically analyzed at each level, from the individual level to the departmental level, and then from the departmental level to the university level, forming a multi-layered data aggregation system. During this aggregation process, the integrity and authenticity of the data are difficult to guarantee effectively. On the one hand, traditional data storage methods rely on centralized servers, and data may be intentionally or unintentionally tampered with by administrators during the aggregation and statistical process, leading to discrepancies between the final departmental or university statistical data and the actual carbon emission data generated by individuals. On the other hand, ordinary users cannot independently verify whether their personal carbon emission data has been accurately and completely included in the aggregated statistical results of higher-level organizations; they can only passively accept the statistical values ​​provided by the system, lacking effective verification methods and a foundation of trust. This information asymmetry not only affects the enthusiasm of teachers and students to participate in carbon credit activities but also restricts the credibility and promotion effectiveness of the carbon credit mechanism on campus. Existing carbon inclusion data management technologies primarily focus on data collection, storage, and display. While some systems have incorporated blockchain technology for data notarization, this often only involves storing raw data or final statistical results on the blockchain, failing to establish a verifiable link between individual data and aggregated organizational data. When users question the statistical results, there is no efficient, low-cost method that protects the privacy of other users to prove that their data was indeed correctly included in the aggregated statistics. Verification by publicly disclosing all raw data would lead to the leakage of a large amount of user privacy information; relying on third-party auditing agencies for verification would incur additional time and trust costs.

[0004] Therefore, a campus carbon credit system is needed that provides an efficient and reliable data integrity verification mechanism while protecting user privacy, thus ensuring data trustworthiness. Summary of the Invention

[0005] (1) Technical problems to be solved This invention provides a campus carbon credit system to address the issue of ensuring data reliability during multi-level aggregation and statistical analysis of campus carbon credit data.

[0006] (2) Technical solution To achieve the above objectives, the present invention provides a campus carbon credit system, the system comprising: a data acquisition and account creation module, a departmental Merkle tree construction module, a school-level Merkle tree construction and storage module, a data verification path return module, and a data verification module, wherein each module is sequentially connected to the other in a communication manner; The data acquisition and account creation module is used to acquire raw carbon emission data generated by multiple data source systems within the campus; convert the raw carbon emission data into carbon emission values ​​according to preset carbon emission conversion rules; create a personal carbon account for each user, write the carbon emission values ​​into the corresponding user's personal carbon account, and calculate the user hash value for the carbon emission values.

[0007] The department Merkle tree construction module is used to calculate the root hash value of the department Merkle tree for each department by using the user hash values ​​of all individual carbon accounts belonging to the same department as leaf nodes, based on the organizational structure hierarchy.

[0008] The school-level Merkle tree construction and notarization module is used to take the root hash value of all departments' Merkle trees as leaf nodes, and calculate the root hash value of the school-level Merkle tree layer by layer using the Merkle tree algorithm; the root hash value of the department Merkle trees, the root hash value of the school-level Merkle tree, and the corresponding notarization timestamp are written into the blockchain network for notarization.

[0009] The data verification path return module is used to extract the hash values ​​of all sibling nodes on the path from the leaf node corresponding to the target user to the root node from the department Merkel tree when a data verification request initiated by the target user is received, and to form the Merkel verification path by combining the hash values ​​of the sibling nodes.

[0010] The data verification module is used to return the root hash value of the department Merkel tree stored in the blockchain network and the Merkel verification path to the target user. The target user calculates the local verification hash value using the locally stored personal carbon emission value and calculates the verification root hash value in combination with the Merkel verification path. When the verification root hash value is consistent with the root hash value of the department Merkel tree stored in the blockchain network, it is confirmed that the target user's personal carbon emission data has been correctly included in the department aggregate statistics.

[0011] Furthermore, the departmental Merkel tree construction module includes: The leaf node sequence preparation module is used to obtain a list of user identifiers for all personal carbon accounts belonging to the same department, sort the user identifier list according to the user identifiers in the original carbon emission data to obtain an ordered user identifier sequence, extract the user hash value of the personal carbon account corresponding to each user identifier according to the ordered user identifier sequence, and arrange the user hash values ​​according to the order of the ordered user identifier sequence to form a leaf node sequence.

[0012] The root hash value generation module is used to determine whether the number of nodes in the leaf node sequence is odd. If it is odd, the last leaf node is copied and appended to the end of the leaf node sequence to make the number of nodes in the leaf node sequence even. Adjacent nodes in the leaf node sequence are paired, and the hash values ​​of each pair of paired nodes are concatenated to calculate a new hash value. This new hash value is used as the parent node of the paired node. All parent nodes form the node sequence of the next level, and this next level node sequence is used as the new node sequence to be processed. The steps of determining whether the number of nodes is odd, pairing adjacent nodes, and calculating the hash value of the parent node are repeated for the node sequence to be processed until only a single root node remains in the node sequence to be processed. The hash value of the root node is used as the root hash value of the department Merkle tree.

[0013] Furthermore, the leaf node sequence preparation module includes the following steps: Extract the first carbon emission record timestamp corresponding to each user identifier from the original carbon emission data, establish a mapping relationship between the first carbon emission record timestamp and the corresponding user identifier to form a timestamp mapping table; sort the user identifiers in the timestamp mapping table according to the time order of the first carbon emission record timestamp from earliest to latest to obtain a time-ordered user identifier list.

[0014] When multiple user identifiers in the time-sequenced user identifier list have the same first carbon emission record timestamp, the user identifiers with the same first carbon emission record timestamp are extracted to form a subset to be sorted assistedly; each user identifier in the subset to be sorted assistedly is sorted in ascending order of character encoding value to obtain a subsequence of user identifiers after assisted sorting; the subsequence of user identifiers after assisted sorting replaces the user identifiers with the same first carbon emission record timestamp at the corresponding position in the time-sequenced user identifier list to form an ordered user identifier sequence.

[0015] Furthermore, the school-level Merkle tree construction and storage module includes: The evidence storage transaction data preparation module is used to obtain the current system time as the evidence storage timestamp after the root hash values ​​of the department Merkle tree and the school-level Merkle tree are calculated; associate the department identifier of each department with the root hash value of the corresponding department Merkle tree to form a department evidence storage dataset; associate the root hash value of the school-level Merkle tree with the school identifier to form a school evidence storage dataset; and encapsulate the department evidence storage dataset, the school evidence storage dataset, and the evidence storage timestamp according to a preset data structure to form evidence storage transaction data.

[0016] The signature and consensus verification module is used to digitally sign the notarized transaction data using the private key of the blockchain network to obtain signed notarized transaction data; broadcast the signed notarized transaction data to each consensus node in the blockchain network, and have each consensus node perform consensus verification on the signed notarized transaction data; when the consensus verification is successful, write the signed notarized transaction data into a new block of the blockchain network to complete the notarization, and return the notarized transaction hash value as the index basis for querying the root hash value of the department Merkle tree when making subsequent data verification requests.

[0017] Furthermore, the signature and consensus verification module includes the following steps: The system performs a hash operation on the evidence storage transaction data using a preset hash algorithm to obtain a digest value of the evidence storage transaction data; it reads the private key registered by the system in the blockchain network from the secure storage medium, and uses the private key to encrypt the digest value of the evidence storage transaction data using an asymmetric encryption algorithm to obtain a digital signature value; it reads the public key corresponding to the private key from the secure storage medium, and converts the public key into an account address in the blockchain network as a signer identifier; it appends the digital signature value, the signer identifier, and the signature timestamp to the evidence storage transaction data to form the signed evidence storage transaction data.

[0018] Furthermore, the data verification module includes: The verification request processing and data sending module is used to receive data verification requests sent by the target user, parse the user identifier and the statistical period to be verified from the data verification request; according to the user identifier and the statistical period to be verified, query the root hash value of the corresponding department Merkel tree from the blockchain network, extract the Merkel verification path from the locally stored department Merkel tree, and send the root hash value of the department Merkel tree and the Merkel verification path to the target user's terminal device. The terminal device verification calculation module is used to read the target user's personal carbon emission value within the statistical period to be verified from local storage, and calculate the personal carbon emission value to obtain a local verification hash value; the terminal device uses the local verification hash value as the current node hash value, and according to the hierarchical order of the hash values ​​of each sibling node in the Merkel verification path, concatenates the current node hash value with the corresponding sibling node hash value to calculate the parent node hash value, updates the parent node hash value to the new current node hash value, and repeats the process until the verification root hash value is calculated.

[0019] Furthermore, the verification request processing and data sending module includes the following steps: The target user's department identifier is determined by querying the organizational structure mapping table based on the user identifier. The department identifier is then combined with the statistical period to be verified to form a blockchain query index. The corresponding evidence record is retrieved in the blockchain network based on the blockchain query index. The root hash value of the department Merkle tree corresponding to the department identifier within the statistical period to be verified is extracted from the evidence record.

[0020] Furthermore, the terminal device verification calculation module includes the following steps: The terminal device determines the corresponding start and end times based on the statistical period to be verified, and retrieves all carbon emission records generated by the target user between the start and end times from local storage; it categorizes and summarizes all retrieved carbon emission records according to carbon emission type, and accumulates the carbon emission values ​​corresponding to each carbon emission type to obtain the individual carbon emission value within the statistical period to be verified; it concatenates the target user's user identifier, the statistical period to be verified, and the individual carbon emission value according to a preset field concatenation order to form a string to be hashed; it performs a hash operation on the string to be hashed using the same hash algorithm used to calculate the user's hash value to obtain a local verification hash value.

[0021] Furthermore, the data acquisition and account creation module includes: The raw carbon emission data includes user identifier, data type, data value, and collection timestamp. The data type includes internet usage time, water consumption during bathing, steps taken, and self-reported carbon neutrality behavior.

[0022] (3) Beneficial effects Compared with the prior art, the beneficial effects of the present invention are: 1. By constructing a multi-level Merkle tree structure from individual to department to university, the carbon emission data hash value of each user is aggregated and calculated layer by layer as a leaf node. The root hash value of each level of the Merkle tree is written into the blockchain network for notarization. This ensures that any tampering with the underlying individual carbon emission data will cause the root hash value to change, thus creating inconsistency with the root hash value already notarized on the blockchain. This achieves tamper-proof protection for campus carbon inclusiveness data in the multi-level aggregation and statistical process, ensuring the integrity and authenticity of carbon emission statistics data at all levels from individual to department to university.

[0023] 2. Building upon the achievement of data tamper-proofing, a user-initiated verification mechanism based on the Merkel verification path was further designed. When a user initiates a data verification request, the system only needs to return the hash values ​​of sibling nodes along the path from the user's leaf node to the root node. The user can then verify locally whether the root hash value matches the blockchain-stored value. The entire verification process does not require the disclosure of other users' original data or hash values, thus ensuring the user's right to independently verify whether their personal data has been correctly included in the aggregate statistics, while also effectively protecting the data privacy of other users.

[0024] 3. Based on the implementation of anti-tampering protection and privacy protection verification, a complete trusted data governance system is constructed by adopting technologies such as constructing a Merkle tree based on the deterministic sorting rules of the first carbon emission record timestamp, writing the evidence data into the blockchain after digital signature and consensus verification, and completing hash calculation and path verification locally on the terminal device. This enables the campus carbon inclusive system to have the characteristics of traceable data source, auditable aggregation process, and reliable verification results. Attached Figure Description

[0025] Figure 1 This is a schematic diagram of the module composition of a campus carbon benefit system according to Embodiment 1 of the present invention. Detailed Implementation

[0026] 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, and 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.

[0027] Before providing examples, it is necessary to describe the application scenario of this invention. This invention is a campus carbon credit system. Due to the hierarchical structure of campus organizations (individual-department-university), carbon emission data needs to be aggregated and statistically analyzed upwards level by level. In this process, traditional centralized storage methods make the data susceptible to tampering, and users cannot independently verify whether their personal data has been correctly included in the higher-level statistics. Moreover, when users question the statistical results, disclosing all data would leak privacy, leading to a challenge to the data credibility of the campus carbon credit system.

[0028] Example 1: As Figure 1 As shown, this embodiment provides a campus carbon credit system, which includes: a data acquisition and account creation module, a departmental Merkel tree construction module, a school-level Merkel tree construction and storage module, a data verification path return module, and a data verification module, with each module communicating with each other in sequence; The data acquisition and account creation module is used to acquire raw carbon emission data generated by multiple data source systems within the campus; convert the raw carbon emission data into carbon emission values ​​according to preset carbon emission conversion rules; create a personal carbon account for each user, write the carbon emission value into the corresponding user's personal carbon account, and calculate the user's hash value for the carbon emission value; in the raw carbon emission data acquisition stage, the system collects user behavior data from multiple data source systems within the campus. These data source systems include, but are not limited to, the campus network management system, the bathroom water metering system, the campus sports application backend, and the carbon neutrality behavior self-reporting platform. Taking the campus network management system as an example, when students log in to the campus network to engage in online activities, the system records their online time data; the bathroom water metering system collects real-time water consumption data for each student when swiping their card to shower through smart flow meters installed at shower heads or faucets. These raw data are typically stored in a structured format, including user identifiers, data types, data values, and collection timestamps. User identifiers are used to associate with specific teachers and students; data types indicate whether the record belongs to categories such as internet usage time, water consumption during showers, or others; data values ​​record specific quantitative values; and collection timestamps precisely record the time the data was generated. After obtaining the raw carbon emission data, the system converts various types of behavioral data into carbon emission values ​​according to preset carbon emission conversion rules. Different types of behavioral data correspond to different conversion coefficients or calculation formulas. Taking internet usage time as an example, the system can calculate the electricity consumed per unit of internet usage time based on energy consumption statistics from the campus data center, and then multiply it by the local power grid's carbon emission factor to obtain the corresponding carbon emission amount. Assuming that a university data center calculates that the carbon emission corresponding to one hour of internet activity is 0.05 kg of CO2 equivalent, then a student's carbon emission for 3 hours of internet use in a day would be 0.15 kg. For water consumption during bathing, the carbon emissions can be calculated based on the energy required to heat the water. If a gas boiler is used for heating, the carbon emissions per liter of hot water are approximately 0.002 kg of CO2 equivalent. A student consuming 40 liters of hot water for bathing would have 0.08 kg of carbon emissions. Step count is also considered a carbon reduction activity. When walking replaces taking the campus shuttle bus or driving a motor vehicle, the carbon emission reduction can be calculated based on the alternative mode of transportation. The system can assign a fixed carbon emission reduction value to each type of activity based on a pre-set list of self-reported carbon-neutral behaviors. After converting the carbon emission values, the system creates a personal carbon account for each user. The personal carbon account is the basic unit for recording and managing a single user's carbon emission data, storing the user's carbon emission values ​​for each statistical period. The system writes the calculated carbon emission values ​​into the corresponding user's personal carbon account and calculates the user's hash value. The process of calculating the user hash value involves combining the user identifier, statistical period, and carbon emission value into a string according to a pre-set field concatenation order, and then performing a cryptographic hash algorithm on this string.For example, for a student with student ID 2021001, whose carbon emissions in October 2022 were 12.5 kg, the system would input the string "2021001|2022-10|12.5" into the SHA-256 hash algorithm, outputting a 256-bit hash value as the user's hash value for that statistical period. The one-way nature of the hash algorithm ensures that the original data cannot be deduced from the hash value, while its collision resistance guarantees that different original data are almost impossible to produce the same hash value.

[0029] The department Merkle tree construction module is used to calculate the root hash value of the department Merkle tree for each department by using the user hash values ​​of all individual carbon accounts belonging to the same department as leaf nodes, based on the organizational structure hierarchy.

[0030] The university-level Merkle tree construction and notarization module uses the root hash values ​​of all departmental Merkle trees as leaf nodes, and calculates the root hash value of the university-level Merkle tree layer by layer using the Merkle tree algorithm. The root hash values ​​of the departmental Merkle trees, the root hash value of the university-level Merkle tree, and the corresponding notarization timestamps are then written to the blockchain network for notarization. Assuming a university has 20 departments, the root hash values ​​of the 20 departmental Merkle trees serve as leaf nodes of the university-level Merkle tree. Through layer-by-layer aggregation, the university-level root hash value representing the integrity of the entire university's carbon emission data is finally obtained. This nested two-level Merkle tree structure forms a data aggregation system corresponding to the campus organizational structure, making the hierarchical relationship of the data clear and traceable.

[0031] The data verification path return module, upon receiving a data verification request from a target user, extracts the hash values ​​of all sibling nodes along the path from the leaf node corresponding to the target user to the root node in the department Merkle tree, and assembles these sibling node hash values ​​into a Merkle verification path. When a target user has doubts about whether their personal carbon emission data has been correctly included in the department's aggregated statistics, they can initiate a data verification request. Upon receiving the verification request, the system extracts the hash values ​​of all sibling nodes along the path from the leaf node corresponding to the target user to the root node in the department Merkle tree, and assembles these sibling node hash values ​​into a Merkle verification path in hierarchical order. The Merkle verification path is an efficient data integrity proof mechanism. Its ingenuity lies in the fact that the verifier does not need to obtain all node data in the Merkle tree; they only need to obtain a limited number of sibling node hash values ​​on the verification path to complete the verification. Taking a department Merkle tree with 1000 leaf nodes as an example, the tree has approximately 10 levels, therefore the verification path contains a maximum of 10 sibling node hash values.

[0032] The data verification module returns the root hash value of the Merkel verification path and the departmental Merkel tree stored in the blockchain network to the target user. The target user calculates a local verification hash value using their locally stored personal carbon emission data and combines it with the Merkel verification path to calculate a verification root hash value. When the verification root hash value matches the root hash value of the departmental Merkel tree stored in the blockchain network, it confirms that the target user's personal carbon emission data has been correctly included in the departmental aggregate statistics. If the verification root hash value is completely consistent with the root hash value of the departmental Merkel tree stored in the blockchain network, it confirms that the target user's personal carbon emission data has indeed been correctly included in the departmental aggregate statistics, and that the data has not been tampered with or omitted during the aggregation process. If the two are inconsistent, it indicates an anomaly, which may be due to a missynchronization between the user's local data and the system data, or an error in the system's construction of the Merkel tree. The user can then file an appeal with the system administrator. This verification process has important privacy protection features. Since the verification path only contains the hash value of the sibling node, rather than the original data or identifiable information of other users, the target user cannot know the specific carbon emission data of other users while verifying their own data, and the privacy of other users is effectively protected.

[0033] The departmental Merkel tree construction module includes: The leaf node sequence preparation module is used to obtain a list of user identifiers for all personal carbon accounts belonging to the same department. This list is then sorted according to the user identifiers in the original carbon emission data to obtain an ordered user identifier sequence. The user hash values ​​of the personal carbon accounts corresponding to each user identifier are extracted sequentially from this ordered user identifier sequence. These user hash values ​​are then arranged according to the order of the ordered user identifier sequence to form a leaf node sequence. Before constructing the departmental Merkle tree, the system first needs to determine the order of the leaf nodes. Since the root hash value of the Merkle tree is closely related to the order of the leaf nodes, different orderings of the same set of leaf nodes will produce different root hash values. Therefore, a deterministic sorting rule must be established to ensure that the order of the leaf nodes remains consistent each time the Merkle tree is constructed. The system obtains a list of user identifiers for all personal carbon accounts belonging to the same department. This list contains unique identifiers for all faculty and students within the department who have established personal carbon accounts. The list is then sorted according to the user identifier information in the original carbon emission data to obtain an ordered user identifier sequence. After obtaining the ordered user identifier sequence, the system extracts the user hash values ​​of the personal carbon accounts corresponding to each user identifier sequentially according to the sequence. For example, if the ordered user identifier sequence is [U001, U002, U003, ...], the system sequentially reads the user hash value H1 of U001, the user hash value H2 of U002, the user hash value H3 of U003, and so on, arranging these hash values ​​according to the order of the ordered user identifier sequence to form the leaf node sequence [H1, H2, H3, ...]. This step ensures a strict one-to-one correspondence between the leaf node sequence and the user identifier sequence, providing a location basis for subsequent data verification.

[0034] The root hash value generation module is used to determine whether the number of nodes in the leaf node sequence is odd. If it is odd, the last leaf node is copied and appended to the end of the leaf node sequence to make the number of nodes even. Adjacent nodes in the leaf node sequence are paired, and the hash values ​​of each pair are concatenated to calculate a new hash value. This new hash value is used as the parent node of the paired node. All parent nodes form the node sequence of the next level, and this next level node sequence is used as the new node sequence to be processed. The steps of determining whether the number of nodes is odd, pairing adjacent nodes, and calculating the hash value of the parent node are repeated for the node sequence to be processed until only a single root node remains. The hash value of this root node is used as the root hash value of the department Merkle tree. Since a standard Merkle tree uses a binary tree structure, each non-leaf node has exactly two child nodes, therefore, the number of nodes at each level must be even. The system determines whether the number of nodes in the leaf node sequence is odd; if it is odd, padding is required. Assuming a department has 101 students, the leaf node sequence contains 101 hash values. The system copies the 101st hash value and appends it to the end, forming a sequence with 102 nodes. This process ensures smooth subsequent pairing operations, and because the value of the padded node is exactly the same as its predecessor, it does not introduce extra information or create ambiguity. After preparing the leaf node sequence, the system begins the layer-by-layer construction process of the Merkle tree. First, adjacent nodes in the leaf node sequence are paired: the first node is paired with the second, the third with the fourth, and so on. For each pair of paired nodes, the system concatenates their hash values ​​in a fixed order, for example, placing the hash value of the left node first and the hash value of the right node last, forming a concatenated string. Then, a hash algorithm is used to calculate a new hash value from this concatenated string. This new hash value is the parent node value of the two paired nodes. To illustrate with specific values, if H1 is a1b2c3... and H2 is d4e5f6..., then the concatenated string is a1b2c3...d4e5f6... Performing SHA-256 on this string yields the parent node hash value P1. The parent node hash values ​​of all paired nodes are sequentially arranged to form the next-level node sequence, i.e., [P1, P2, P3, ...]. The number of nodes in this sequence is half that of the leaf node sequence. The system uses the next-level node sequence as a new sequence to be processed and repeats the aforementioned processing steps: first, it checks if the number of nodes is odd; if so, it copies the last node to complete the sequence; then, it pairs adjacent nodes, concatenates their hash values, and calculates the parent node hash value; all parent nodes form the next-level node sequence. This iterative process continues, and with each iteration, the length of the node sequence is reduced by approximately half.Assuming an initial number of leaf nodes of 1024, the first iteration yields 512 nodes, the second 256, the third 128, and so on, until only one node remains after 10 iterations. The iteration terminates when only one node remains in the sequence of nodes to be processed; the hash value of this node is the root hash value of the department Merkle tree. This hierarchical tree structure possesses important cryptographic properties. Due to the avalanche effect of hash algorithms, a small change in the hash value of any leaf node will lead to a significant change in the hash value of its parent node. This change propagates upwards along the tree hierarchy, inevitably resulting in a change in the root hash value. Therefore, if someone attempts to tamper with a user's carbon emission data, the root hash value of the department Merkle tree will inevitably differ from the root hash value stored on the blockchain, and the tampering will be detected. Furthermore, the hierarchical structure of the Merkle tree ensures that the length of the verification path is only proportional to the depth of the tree, and the depth of the tree is logarithmically related to the number of leaf nodes. For a department with 10,000 users, its Merkle tree depth is about 14 levels, and the verification path only needs to contain the hash values ​​of 14 sibling nodes, which is extremely efficient.

[0035] The leaf node sequence preparation module includes the following steps: The system extracts the first carbon emission record timestamp corresponding to each user identifier from the original carbon emission data, and establishes a mapping relationship between the first carbon emission record timestamp and the corresponding user identifier to form a timestamp mapping table. The user identifiers in the timestamp mapping table are then sorted in chronological order according to the first carbon emission record timestamps, resulting in a time-ordered user identifier list. The design of deterministic sorting rules is crucial for the correct construction and verification of the Merkle tree. If the sorting rules are unclear or ambiguous, the Merkle tree structure constructed by the system at different time points may be inconsistent, leading to different root hash values ​​and preventing users from correctly verifying their data. This method uses the first carbon emission record timestamp as the primary sorting basis. Its rationale is that the time when each user first generates a carbon emission record is an objective historical fact, possessing uniqueness and immutability, making it suitable as a stable sorting benchmark. The first step in the sorting process is to extract the first carbon emission record timestamp corresponding to each user identifier from the original carbon emission data. The system traverses the carbon emission records of all users in the department, finds the earliest carbon emission record for each user identifier, and extracts the collection timestamp of that record as the user's first carbon emission record timestamp. For example, if student ID 2021001's first carbon emission record in the system occurred at 08:30:15 on September 1, 2022, then their first carbon emission record timestamp would be 2022-09-01 08:30:15. The system establishes a mapping relationship between the first carbon emission record timestamp and the corresponding user ID, forming a timestamp mapping table. This mapping table can be represented as {2021001:2022-09-01 08:30:15,2021002:2022-09-01 09:15:22,2021003:2022-09-01 08:30:15,...}. Next, the system sorts the user IDs in the timestamp mapping table according to the first carbon emission record timestamp from earliest to latest. User IDs with earlier timestamps are listed first. This sorting method conforms to the intuitive logic of first-come, first-served and is easy to understand and trace. After primary sorting, a time-sequential user identifier list is obtained, for example, arranged in chronological order as [2021001, 2021003, 2021002, ...].

[0036] When multiple user identifiers in the time-sequence user identifier list have the same first carbon emission record timestamp, these user identifiers are extracted to form a subset for auxiliary sorting. Each user identifier in this subset is then auxiliary-sorted according to its character encoding value in ascending order, resulting in an auxiliary-sorted user identifier subsequence. This auxiliary-sorted subsequence replaces the corresponding user identifiers with the same first carbon emission record timestamp in the time-sequence user identifier list, forming an ordered user identifier sequence. However, in real-world scenarios, multiple users may have the same first carbon emission record timestamp. For example, on the first day of a new semester, many students simultaneously swipe their cards to enter the shower room. If the system's timestamp accuracy is at the second level, multiple students may have identical first carbon emission record timestamps. In the example above, the first carbon emission record timestamps for 2021001 and 2021003 are both 2022-09-01 08:30:15, and their order cannot be determined solely by the timestamps. Failure to address this situation will lead to uncertainty in the sorting results. To address this issue, the system introduces an auxiliary sorting mechanism. When multiple user identifiers in the primary time-sequence user identifier list share the same first carbon emission record timestamp, the system extracts these identifiers to form a subset for auxiliary sorting. For each user identifier in this subset, the system performs auxiliary sorting based on its character encoding values, from smallest to largest. The character encoding value refers to the ASCII or Unicode code point of each character in the user identifier string. Sorting begins with comparing the first character of the string; if the first characters are the same, the second character is compared, and so on. This sorting method is commonly referred to as lexicographical order. For example, user identifiers 2021001 and 2021003 have identical first six characters, and their seventh characters are 1 and 3 respectively. Since the ASCII code value of character 1 is less than that of character 3, 2021001 is sorted before 2021003. After auxiliary sorting, the resulting subsequence of user identifiers is obtained, for example, [2021001, 2021003]. The system replaces the corresponding user identifiers with the same first carbon emission record timestamp in the time-sequenced user identifier list with this subsequence, forming the final ordered user identifier sequence. By combining primary and secondary sorting, it ensures that any two different user identifiers can obtain a definite order, and the sorting result is unique and repeatable, providing a stable and reliable basis for the arrangement of leaf nodes in the Merkle tree.

[0037] The school-level Merkle tree construction and storage module includes: The notarization transaction data preparation module is used to obtain the current system time as the notarization timestamp after the root hash values ​​of the department Merkle tree and the university Merkle tree are calculated; to associate the department identifiers of each department with the root hash values ​​of the corresponding department Merkle trees to form a department notarization dataset; and to associate the root hash values ​​of the university Merkle trees with the university identifiers to form a university notarization dataset; and to encapsulate the department notarization datasets, university notarization datasets, and notarization timestamps according to a preset data structure to form notarization transaction data. Blockchain notarization is a key link in ensuring the immutability of data. Although the Merkle tree structure itself can detect data tampering, if the root hash value is stored on a centralized server, there is still a risk of synchronous tampering by the system administrator. By writing the root hash value into a decentralized blockchain network, the immutability of the blockchain is used to provide a reliable storage environment for the root hash value. The first step in the notarization process is to obtain the current system time as the notarization timestamp after the root hash values ​​of the department Merkle tree and the university Merkle tree are calculated. The timestamp of the evidence storage records the precise time when the evidence storage operation occurred, serving an important role in temporal proof. In subsequent data verification, users can query the evidence storage records at the corresponding time point based on the statistical period to be verified, obtaining the root hash value of the evidence storage at that time as a verification benchmark. The system typically obtains timestamps from trusted time sources to ensure the accuracy and authority of the time. The system organizes the evidence storage data in a structured manner. For evidence storage data at the departmental level, the system associates the departmental identifier with the corresponding departmental Merkle tree root hash value to form a departmental evidence storage dataset. Assuming a university has departments such as Computer Science, Economics and Management, and Foreign Languages, with departmental identifiers CS, EM, and FL respectively, and corresponding departmental Merkle tree root hash values ​​RootCS, RootEM, and RootFL respectively, then the departmental evidence storage dataset can be represented as {(CS,RootCS),(EM,RootEM),(FL,RootFL),...}. For school-level evidence storage data, the system associates the root hash value of the school-level Merkle tree with the school identifier to form a school evidence storage dataset, such as {(UnivA,RootSchool)}. The predefined data structure defines the order, data type, and encoding format of each field, ensuring a standardized and consistent format for evidence storage transaction data. A typical evidence storage transaction data structure might include the following fields: evidence storage type identifier, evidence storage timestamp, school identifier, school-level root hash value, number of departments, and evidence storage records for each department. This structured encapsulation facilitates subsequent data parsing and querying.

[0038] The signature and consensus verification module is used to digitally sign the notarized transaction data using the private key of the blockchain network to obtain signed notarized transaction data. The signed notarized transaction data is then broadcast to each consensus node in the blockchain network, where each consensus node verifies the signed notarized transaction data. Once the consensus verification is successful, the signed notarized transaction data is written into a new block of the blockchain network to complete the notarization, and the notarized transaction hash value is returned as the index for querying the root hash value of the department Merkle tree in subsequent data verification requests. To ensure the credibility and integrity of the notarized transaction data, the system digitally signs the notarized transaction data using the private key of the blockchain network. The signed notarized transaction data contains the original data content and the digital signature value. The recipient can verify the signature to confirm that the data indeed comes from a legitimate signer and has not been tampered with. The system broadcasts the signed notarized transaction data to each consensus node in the blockchain network. A blockchain network typically consists of multiple distributed nodes that reach consensus on transaction data within the network through a consensus protocol. Common consensus protocols include Proof-of-Work, Proof-of-Stake, and Practical Byzantine Fault Tolerance, with different blockchain platforms employing different consensus mechanisms. After receiving the signed notarized transaction data, each consensus node first verifies the validity of the digital signature to confirm the legitimacy of the transaction's origin. Then, according to the rules of the consensus protocol, it participates in the consensus process, voting or calculating the validity of the transaction with other nodes. Once consensus verification is successful, the signed notarized transaction data is written into a new block of the blockchain network, completing on-chain notarization. The chain-like data structure of the blockchain ensures that each new block contains the hash value of the previous block, forming a chain of interconnected blockchain segments. Attempting to modify data in a historical block will cause the hash value of that block to change, requiring the recalculation of the hash values ​​of all subsequent blocks, which is computationally infeasible, thus achieving data immutability. After notarization is completed, the blockchain network returns the notarized transaction hash value, which is a unique identifier for this notarized transaction and can be used as an index for querying the Merkel root hash value in subsequent data verification requests.

[0039] The signature and consensus verification module includes the following steps: The process involves hashing the stored transaction data using a preset hash algorithm to obtain a digest value. The private key registered in the blockchain network is retrieved from a secure storage medium, and an asymmetric encryption algorithm is used to encrypt the digest value to obtain a digital signature value. The public key corresponding to the private key is retrieved from the secure storage medium and converted into an account address in the blockchain network as the signer identifier. The digital signature value, signer identifier, and signature timestamp are then appended to the stored transaction data to form the signed stored transaction data. Digital signatures are an important application of modern cryptography, similar to handwritten signatures on paper documents, used to prove the source of data and ensure that the data has not been tampered with. In a blockchain system, digital signatures are the core mechanism for verifying the legitimacy of transactions. The first step in the signing process is to hash the stored transaction data using a preset hash algorithm to obtain a digest value. The choice of hash algorithm should be consistent with the technical specifications of the blockchain network; commonly used hash algorithms include SHA-256 and Keccak-256. Taking SHA-256 as an example, regardless of the length of the evidence-stored transaction data, a fixed-length 256-bit digest value will be output after hashing. Due to the collision resistance of hash algorithms, different evidence-stored transaction data are almost impossible to produce the same digest value, so the digest value can uniquely represent the original data. Signing the digest value instead of directly signing the original data can reduce the amount of data for signature operations and improve signature efficiency; on the other hand, it can ensure the fixed signature length, which is convenient for subsequent processing. The second step is to read the private key registered by the system in the blockchain network from the secure storage medium. The private key is the core secret information in the asymmetric encryption system and must be properly kept to prevent leakage. The secure storage medium can be a hardware security module, an encrypted USB key, a trusted execution environment, or other storage devices with physical or logical isolation protection. During the initialization phase, the system will register its identity in the blockchain network and generate a pair of public and private keys. The private key is stored in the secure storage medium, while the public key is publicly released for authentication. After reading the private key, the system uses an asymmetric encryption algorithm to encrypt the digest value of the evidence-stored transaction data to obtain a digital signature value. Commonly used asymmetric encryption algorithms include RSA, ECDSA, and EdDSA, with ECDSA being the most widely used in the blockchain field. The result of a signature operation is a numerical value associated with the private key and its digest. Only the signer holding the private key can generate a valid signature, while anyone can verify the signature's validity using the corresponding public key. The third step involves retrieving the public key corresponding to the private key from secure storage and converting it into an account address in the blockchain network as the signer's identifier. In many blockchain systems, the account address is a string obtained by hashing and encoding the public key, resulting in a short address that is easy to display and transmit.The signer identifier uniquely identifies the signer within the blockchain network. The recipient can obtain the corresponding public key based on the signer identifier to verify the signature. The signature timestamp records the time the signing operation occurred and can be used to prevent replay attacks. The signed and stored transaction data contains the original data content and signature-related information, forming a complete and verifiable data packet.

[0040] The data verification module includes: The verification request processing and data sending module receives data verification requests sent by target users, parses the user's identifier and the statistical period to be verified from the data verification request, queries the root hash value of the corresponding department Merkel tree in the blockchain network based on the user identifier and the statistical period to be verified, extracts the Merkel verification path from the locally stored department Merkel tree, and sends the root hash value of the department Merkel tree and the Merkel verification path to the target user's terminal device. The data verification request is initiated by the user through the Carbon Inclusive application on the terminal device, and the request contains two key parameters: user identifier and the statistical period to be verified. The user identifier is used to locate the user's corresponding leaf node position in the department Merkel tree, and the statistical period to be verified indicates which time period of carbon emission data aggregation the user wants to verify. After receiving the data verification request, the system first parses the data verification request to extract the user identifier and the statistical period to be verified.

[0041] The terminal device verification calculation module is used to read the target user's personal carbon emission value within the statistical period to be verified from local storage, and calculate a local verification hash value based on the personal carbon emission value. The terminal device uses this local verification hash value as the current node hash value, and sequentially concatenates the current node hash value with the corresponding sibling node hash values ​​according to the hierarchical order of the sibling node hash values ​​in the Merkel verification path, calculating the parent node hash value. The parent node hash value is then updated to the new current node hash value, and this process is repeated until the verification root hash value is calculated. At each level, the terminal device determines the concatenation order based on the position information of the sibling nodes: if the sibling node is on the left, the sibling node hash value is placed first, and the current node hash value is placed last; if the sibling node is on the right, the current node hash value is placed first, and the sibling node hash value is placed last. After concatenation, a hash operation is performed on the concatenated string to obtain the parent node hash value, and this parent node hash value is updated to the new current node hash value. Repeat the above steps until all sibling nodes in the Merkel verification path have been processed. The hash value of the current node obtained at this point is the verification root hash value.

[0042] The verification request processing and data sending module includes the following steps: The system determines the department ID of the target user by querying the organizational structure mapping table based on the user identifier. This department ID is then combined with the statistical period to be verified to form a blockchain query index. The corresponding stored records are retrieved from the blockchain network based on this index, and the root hash value of the department Merkle tree corresponding to the department ID within the statistical period to be verified is extracted from these records. The blockchain stores the root hash values ​​of the department Merkle trees for each statistical period. However, since the blockchain is a distributed ledger that appends data chronologically, an effective indexing mechanism is needed to quickly retrieve specific stored records. The first step in the query process is to determine the department of the target user based on the user identifier. The system maintains an organizational structure mapping table that records the affiliation between all users on campus and their respective departments. Taking a university as an example, the structure of the organizational structure mapping table might be {user ID: department ID}, such as {2021001:CS, 2021002: EM,...}, where CS represents the School of Computer Science and EM represents the School of Economics and Management. The system queries the organizational structure mapping table based on the user identifier in the data verification request to determine the department identifier to which the user belongs. After determining the department identifier, the system combines it with the statistical period to be verified to form a blockchain query index. The query index format can be department identifier_statistical period, for example, CS_2022-10 represents the evidence storage record of the School of Computer Science in October 2022. This index design allows for precise location of evidence storage data for a specific department within a specific statistical period. Blockchain networks typically provide query interfaces or smart contract methods, allowing external systems to retrieve on-chain data based on specific conditions. The system calls the corresponding query interface, passing the department identifier and statistical period as query parameters. Blockchain nodes search for matching evidence storage records in their locally stored block data. Since the evidence storage transaction data is encapsulated according to a standardized data structure when uploaded to the chain, including fields such as department identifier and evidence storage timestamp, precise matching can be performed based on these fields. After retrieving the corresponding evidence storage record, the system extracts the department Merkle root hash value corresponding to the department identifier within the statistical period to be verified. The evidence storage record contains the root hash values ​​of all departments within the statistical period. The system locates the data item of the target department based on the department identifier and reads its root hash value field. For example, if the retrieved evidence storage record contains {timestamp: 2022-10-31 23:59:59, department data: {(CS,abc123...),(EM,def456...),...}, school-level root hash value:xyz789...}, the system extracts the root hash value abc123... based on the department identifier CS. This value is the benchmark value that needs to be compared during user verification.

[0043] The terminal device verification calculation module includes the following steps: The terminal device determines the corresponding start and end times based on the statistical period to be verified, and retrieves all carbon emission records generated by the target user between the start and end times from local storage. All retrieved carbon emission records are categorized and summarized according to carbon emission type, and the carbon emission values ​​corresponding to each carbon emission type are summed to obtain the individual carbon emission value within the statistical period to be verified. The user identifier, the statistical period to be verified, and the individual carbon emission value are concatenated according to a preset field concatenation order to form a string to be hashed. The string to be hashed is hashed using the same hash algorithm used to calculate the user's hash value to obtain a local verification hash value. To ensure that the local calculation result is consistent with the system calculation result, the terminal device must use the exact same data extraction range, summarization method, and hash calculation method as the system. The first step in the calculation process is to determine the time range for data extraction. Statistical periods are typically measured in calendar months, quarters, or years. For example, October 2022's start time is 2022-10-01 00:00:00, and its end time is 2022-10-31 23:59:59. The terminal device parses the statistical period string to calculate the precise start and end times. After determining the time range, the terminal device retrieves all carbon emission records generated by the target user within that time range from its local storage. During the user's use of the Carbon Inclusive application, each carbon emission record generated is synchronously saved to the terminal device's local storage. Local storage can use an SQLite database, local files, or other persistent storage methods. During retrieval, the terminal device uses the user identifier and collection timestamp as query criteria to filter all carbon emission records whose collection timestamps fall between the start and end times. After obtaining the set of carbon emission records, the terminal device categorizes and summarizes these records. Because the raw carbon emission data contains different data types, such as internet usage time, water consumption during bathing, steps taken, and self-reported carbon neutrality behavior, the carbon emission values ​​for each type need to be summed separately. The terminal device iterates through all carbon emission records, groups the records according to the data type field, and then sums the carbon emission values ​​within each group to obtain the summary value for each carbon emission type. Finally, the summary values ​​for each type are added together to obtain the total personal carbon emission value for the statistical period to be verified. This summarization process must be consistent with the summarization logic used by the system when calculating the user's hash value; otherwise, the final hash value will not match. After the data summarization is completed, the terminal device concatenates the target user's user identifier, the statistical period to be verified, and the personal carbon emission value according to a preset field concatenation order to form a string to be hashed. The preset field concatenation order must be completely consistent with the order in which the system calculates the user's hash value, for example, uniformly using the format "user identifier|statistical period|carbon emission value".Assuming the user identifier is 2021001, the statistical period is 2022-10, and the carbon emission value is 12.50, then the string to be hashed is 2021001|2022-10|12.50. It is important to note that the numerical representation format should also be consistent, such as consistently retaining two decimal places and using a specific numerical encoding format, to avoid different hash values ​​due to format differences. The choice of hash algorithm is determined during system design; for example, SHA-256, the terminal device has the same hash algorithm implementation built into its application.

[0044] The data acquisition and account creation module includes: The raw carbon emission data includes user identifier, data type, data value, and collection timestamp. The data type includes internet usage time, water consumption during showering, steps taken, and self-reported carbon neutrality behavior. Raw carbon emission data forms the foundation of the entire campus carbon credit system, and its structural design directly impacts subsequent data processing and carbon emission calculation. Raw carbon emission data contains four basic fields: user identifier, data type, data value, and collection timestamp. The user identifier is a unique code that identifies each individual student or faculty member on campus, typically using student ID or employee ID. The uniqueness of the user identifier ensures that carbon emission data can be accurately attributed to the corresponding individual carbon account, a prerequisite for personal carbon footprint tracking. In the system design, the user identifier is also used to associate organizational structure information and determine the user's department, thereby supporting multi-level data aggregation and statistics. The data type field indicates the type of activity for which the carbon emission record belongs. This method lists four typical data types: internet usage time, water consumption during showering, steps taken, and self-reported carbon neutrality behavior. Internet usage time data comes from the campus network management system, recording the cumulative time users spend online on the campus network, usually in minutes or hours. Internet activity consumes electricity for the data center, indirectly generating carbon emissions. Bathing water consumption data comes from the bathroom water metering system, recording the amount of hot water consumed each time a user showers, usually in liters. Heating hot water requires energy, generating corresponding carbon emissions. Step count data comes from campus sports applications or wearable devices, recording the number of steps a user takes daily. Walking, as a zero-carbon mode of transportation, can reduce carbon emissions when it replaces motor vehicle travel. Self-reported carbon neutrality behavior refers to various low-carbon and environmentally friendly behaviors actively reported by users, such as participating in tree planting activities, using their own tableware, and participating in second-hand goods exchanges. These behaviors are difficult to collect through automated systems but contribute positively to carbon reduction; therefore, users are allowed to self-report, and after verification, the data is recorded in their personal carbon account. The above four data types cover the main carbon emission and carbon reduction scenarios in campus life, but the system design is scalable, and other data types can be added as needed. The data value field records the specific quantitative value corresponding to the carbon emission record; its unit and meaning depend on the data type. For internet browsing time, a value of 120 might represent 120 minutes; for shower water consumption, a value of 35.5 might represent 35.5 liters; for step count, a value of 8000 might represent 8000 steps; and for self-reported carbon neutrality, the value might be the carbon emission reduction figure verified by the system. These data values ​​serve as the input for subsequent carbon emission conversion calculations. The data collection timestamp field records the precise time point when this carbon emission data was generated, typically accurate to the second.Collection timestamps serve multiple purposes: first, they define the statistical period to which the data belongs, ensuring accurate filtering of data within the corresponding time range when conducting monthly, quarterly, or annual statistics; second, they determine the timestamp of a user's first carbon emission record, serving as the basis for sorting leaf nodes when constructing a Merkle tree; and third, they establish the temporal sequence of data, supporting data traceability and anomaly detection. Collection timestamps are typically automatically generated by the data source system during data collection and synchronously written to the original carbon emission data records.

[0045] Finally, it should be noted that although the present invention has been described in detail with reference to the foregoing embodiments, those skilled in the art can still modify the technical solutions described in the foregoing embodiments or make equivalent substitutions for some of the technical features. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of the present invention should be included within the protection scope of the present invention.

Claims

1. A campus carbon credit system, characterized in that, The system includes: a data acquisition and account creation module, a departmental Merkle tree construction module, a school-level Merkle tree construction and storage module, a data verification path return module, and a data verification module, with each module communicating and connecting to the others in sequence. The data acquisition and account creation module is used to acquire raw carbon emission data generated by multiple data source systems within the campus; convert the raw carbon emission data into carbon emission values ​​according to preset carbon emission conversion rules; create a personal carbon account for each user, write the carbon emission values ​​into the corresponding user's personal carbon account, and calculate the user hash value for the carbon emission values. The department Merkle tree construction module is used to calculate the root hash value of the department Merkle tree for each department by using the user hash values ​​of all individual carbon accounts belonging to the same department as leaf nodes and the Merkle tree algorithm to calculate the root hash value of the department Merkle tree layer by layer according to the organizational structure hierarchy. The school-level Merkle tree construction and notarization module is used to take the root hash value of all departments' Merkle trees as leaf nodes, and calculate the root hash value of the school-level Merkle tree layer by layer using the Merkle tree algorithm; the root hash value of the department Merkle trees, the root hash value of the school-level Merkle tree, and the corresponding notarization timestamp are written into the blockchain network for notarization. The data verification path return module is used to extract the hash values ​​of all sibling nodes on the path from the leaf node corresponding to the target user to the root node from the department Merkel tree when a data verification request initiated by the target user is received, and to form the Merkel verification path by combining the hash values ​​of the sibling nodes. The data verification module is used to return the root hash value of the department Merkel tree stored in the blockchain network and the Merkel verification path to the target user. The target user calculates the local verification hash value using the locally stored personal carbon emission value and calculates the verification root hash value in combination with the Merkel verification path. When the verification root hash value is consistent with the root hash value of the department Merkel tree stored in the blockchain network, it is confirmed that the target user's personal carbon emission data has been correctly included in the department aggregate statistics.

2. The campus carbon credit system according to claim 1, characterized in that, The departmental Merkel tree construction module includes: The leaf node sequence preparation module is used to obtain a list of user identifiers for all personal carbon accounts belonging to the same department, sort the user identifier list according to the user identifiers in the original carbon emission data to obtain an ordered user identifier sequence, extract the user hash value of the personal carbon account corresponding to each user identifier according to the ordered user identifier sequence, and arrange the user hash values ​​according to the order of the ordered user identifier sequence to form a leaf node sequence. The root hash value generation module is used to determine whether the number of nodes in the leaf node sequence is odd. If it is odd, the last leaf node is copied and appended to the end of the leaf node sequence to make the number of nodes in the leaf node sequence even. Adjacent nodes in the leaf node sequence are paired, and the hash values ​​of each pair of paired nodes are concatenated to calculate a new hash value. This new hash value is used as the parent node of the paired node. All parent nodes form the node sequence of the next level, and this next level node sequence is used as the new node sequence to be processed. The steps of determining whether the number of nodes is odd, pairing adjacent nodes, and calculating the hash value of the parent node are repeated for the node sequence to be processed until only a single root node remains in the node sequence to be processed. The hash value of the root node is used as the root hash value of the department Merkle tree.

3. A campus carbon credit system according to claim 2, characterized in that, The leaf node sequence preparation module includes the following steps: Extract the first carbon emission record timestamp corresponding to each user identifier from the original carbon emission data, establish a mapping relationship between the first carbon emission record timestamp and the corresponding user identifier to form a timestamp mapping table; sort the user identifiers in the timestamp mapping table according to the time order of the first carbon emission record timestamp from early to late to obtain a time-ordered user identifier list. When multiple user identifiers in the time-sequenced user identifier list have the same first carbon emission record timestamp, the user identifiers with the same first carbon emission record timestamp are extracted to form a subset to be sorted assistedly; each user identifier in the subset to be sorted assistedly is sorted in ascending order of character encoding value to obtain a subsequence of user identifiers after assisted sorting; the subsequence of user identifiers after assisted sorting replaces the user identifiers with the same first carbon emission record timestamp at the corresponding position in the time-sequenced user identifier list to form an ordered user identifier sequence.

4. A campus carbon credit system according to claim 1, characterized in that, The school-level Merkle tree construction and storage module includes: The evidence storage transaction data preparation module is used to obtain the current system time as the evidence storage timestamp after the root hash values ​​of the department Merkle tree and the school-level Merkle tree are calculated; associate the department identifier of each department with the root hash value of the corresponding department Merkle tree to form a department evidence storage dataset; associate the root hash value of the school-level Merkle tree with the school identifier to form a school evidence storage dataset; and encapsulate the department evidence storage dataset, the school evidence storage dataset, and the evidence storage timestamp according to a preset data structure to form evidence storage transaction data. The signature and consensus verification module is used to digitally sign the notarized transaction data using the private key of the blockchain network to obtain signed notarized transaction data; broadcast the signed notarized transaction data to each consensus node in the blockchain network, and have each consensus node perform consensus verification on the signed notarized transaction data; when the consensus verification is successful, write the signed notarized transaction data into a new block of the blockchain network to complete the notarization, and return the notarized transaction hash value as the index basis for querying the root hash value of the department Merkle tree when making subsequent data verification requests.

5. A campus carbon credit system according to claim 4, characterized in that, The signature and consensus verification module includes the following steps: The system performs a hash operation on the evidence storage transaction data using a preset hash algorithm to obtain a digest value of the evidence storage transaction data; it reads the private key registered by the system in the blockchain network from the secure storage medium, and uses the private key to encrypt the digest value of the evidence storage transaction data using an asymmetric encryption algorithm to obtain a digital signature value; it reads the public key corresponding to the private key from the secure storage medium, and converts the public key into an account address in the blockchain network as a signer identifier; it appends the digital signature value, the signer identifier, and the signature timestamp to the evidence storage transaction data to form the signed evidence storage transaction data.

6. A campus carbon credit system according to claim 1, characterized in that, The data verification module includes: The verification request processing and data sending module is used to receive data verification requests sent by the target user, parse the user identifier and the statistical period to be verified from the data verification request; according to the user identifier and the statistical period to be verified, query the root hash value of the corresponding department Merkel tree from the blockchain network, extract the Merkel verification path from the locally stored department Merkel tree, and send the root hash value of the department Merkel tree and the Merkel verification path to the target user's terminal device. The terminal device verification calculation module is used to read the target user's personal carbon emission value within the statistical period to be verified from local storage, and calculate the personal carbon emission value to obtain a local verification hash value; the terminal device uses the local verification hash value as the current node hash value, and according to the hierarchical order of the hash values ​​of each sibling node in the Merkel verification path, concatenates the current node hash value with the corresponding sibling node hash value to calculate the parent node hash value, updates the parent node hash value to the new current node hash value, and repeats the process until the verification root hash value is calculated.

7. A campus carbon credit system according to claim 6, characterized in that, The verification request processing and data sending module includes the following steps: The target user's department identifier is determined by querying the organizational structure mapping table based on the user identifier. The department identifier is then combined with the statistical period to be verified to form a blockchain query index. The corresponding evidence record is retrieved in the blockchain network based on the blockchain query index. The root hash value of the department Merkle tree corresponding to the department identifier within the statistical period to be verified is extracted from the evidence record.

8. A campus carbon credit system according to claim 6, characterized in that, The terminal device verification calculation module includes the following steps: The terminal device determines the corresponding start and end times based on the statistical period to be verified, and retrieves all carbon emission records generated by the target user between the start and end times from local storage; it categorizes and summarizes all retrieved carbon emission records according to carbon emission type, and accumulates the carbon emission values ​​corresponding to each carbon emission type to obtain the individual carbon emission value within the statistical period to be verified; it concatenates the target user's user identifier, the statistical period to be verified, and the individual carbon emission value according to a preset field concatenation order to form a string to be hashed; it performs a hash operation on the string to be hashed using the same hash algorithm used to calculate the user's hash value to obtain a local verification hash value.

9. A campus carbon credit system according to claim 1, characterized in that, The data acquisition and account creation module includes: The raw carbon emission data includes user identifier, data type, data value, and collection timestamp. The data type includes internet usage time, water consumption during bathing, steps taken, and self-reported carbon neutrality behavior.

Images