A method for on-chain trusted verification of carbon asset certificates

Abstract

The present application relates to the technical field of carbon asset data trust verification, and particularly relates to a carbon asset voucher on-chain trust verification method, which comprises the following steps: firstly, responding to a source node on-chain trust verification request, calculating a gray epidemic risk value based on a node carbon pulse window, an immune danger value and a voucher bite degree, and screening source nodes meeting on-chain conditions; secondly, obtaining voucher original data, on-chain storage data, signature data and circulation state data, generating a carbon certificate base grain and a misalignment fold grain abstract, and comparing the abstract with an on-chain abstract; then, verifying signature trustworthiness in combination with a right attribution shadow spectrum, a complex salt echo signature verification, signature time coherence and a shadow salt unused code; finally, verifying a voucher circulation state according to a circulation pulse code, a carbon conservation funnel and a reverse sequence damping abnormal result, and outputting an on-chain verification result of an abstract, a signature and a circulation state. The present application can improve the tamper-proofing, anti-replay, right ownership consistency and repeated use risk identification capability of carbon asset vouchers.

Description

Technical Field

[0001] This invention relates to the field of carbon asset data trust verification technology, specifically to a trust verification method for carbon asset certificates on the blockchain. Background Technology

[0002] With the development of carbon trading, carbon offsetting, and carbon finance, carbon asset certificates, as an important carrier representing carbon emission reductions, ownership entities, usage restrictions, issuance status, and circulation status, are widely used in business scenarios such as carbon asset issuance and registration, trading and transfer, pledge financing, offsetting and cancellation.

[0003] Current carbon asset certificate verification typically relies on data provided by registration systems, trading platforms, on-chain records, or third-party verification agencies. This involves querying and comparing certificate number, project number, carbon content, issuing authority, ownership entity, signature information, and current circulation status. The main problems are as follows: First, attackers may modify fields such as certificate number, project number, carbon content, ownership entity, usage restrictions, or circulation status, causing inconsistencies between the certificate content and on-chain records, thus creating the risk of certificate tampering. They may also insert, delete, or reverse historical circulation records, or re-mark offset, cancelled, or pledged carbon asset certificates as tradable, causing the risk of circulation status tampering or rollback. Second, there is insufficient ability to identify the reuse of carbon asset certificates. For example, the same signature value, signature salt value, or historical signature materials may be submitted repeatedly, leading to the risk of signature replay; the same carbon content, even after offsetting, cancellation, or unreleased pledge, may still be used again for transfer, offsetting, pledging, or other uses, resulting in the problems of reuse, overuse, or double pledging of carbon asset certificates.

[0004] Therefore, there is an urgent need for a reliable on-chain verification method for carbon asset certificates to solve the above problems. Summary of the Invention

[0005] The purpose of this invention is to provide a reliable on-chain verification method for carbon asset certificates, in order to solve the technical problems of high risk of certificate tampering and low ability to identify the reuse of carbon asset certificates in existing carbon asset certificate verification.

[0006] The objective of this invention can be achieved through the following technical solutions:

[0007] A reliable on-chain verification method for carbon asset certificates, comprising the following steps:

[0008] Step 1, Source Node Trust Pre-Verification: Respond to the on-chain trust verification request of the source node corresponding to the carbon asset certificate to be verified and determine whether the source node corresponding to the carbon asset certificate to be verified meets the on-chain conditions.

[0009] Step 2: For source nodes that meet the conditions for on-chain verification, obtain the multi-source verification data corresponding to the carbon asset certificates to be verified uploaded by them.

[0010] Step 3, On-chain verification of certificate summary based on carbon-based pattern: Identify key fields in multi-source verification data, generate carbon dimension field vectors based on key fields, and generate independently verifiable pattern petals based on carbon dimension field vectors. Fold multiple pattern petals in a misaligned manner according to preset misalignment mapping rules and cyclic displacement to generate misaligned pattern summary. Compare the misaligned pattern summary with the on-chain certificate summary to obtain the summary crack degree, and determine whether the certificate summary has a risk of tampering based on the summary verification threshold.

[0011] Step 4: After completing the on-chain verification of the certificate summary, perform on-chain trusted verification of the signature data corresponding to the carbon asset certificate to be verified based on the signature echo coherence rule, and generate the on-chain verification result of the signature.

[0012] Step 5: After completing the on-chain verification of the signature, perform on-chain trusted verification of the circulation status of the carbon asset certificate to be verified, and generate the on-chain verification result of the circulation status.

[0013] Furthermore, determining whether the source node corresponding to the carbon asset certificate to be verified meets the on-chain conditions includes:

[0014] Determine the source node cluster corresponding to this source node;

[0015] Using the source node cluster as the scope of the trusted pre-verification object of the source node, the on-chain interaction behavior information of the source node and the data fields that the source node intends to provide are obtained within the preset observation window;

[0016] The gray epidemic risk value of the source node is calculated based on the on-chain interaction behavior information of the source node and the data fields that the source node intends to provide.

[0017] When the gray epidemic risk value of the source node does not exceed the preset threshold, it is determined that the source node corresponding to the carbon asset certificate to be verified meets the conditions for on-chain.

[0018] Furthermore, based on the on-chain interaction behavior information of the source node and the data fields that the source node currently intends to provide, the node gray epidemic risk value of the source node is calculated as follows:

[0019] A node carbon pulse window is constructed based on the on-chain interaction behavior information of the source node;

[0020] Calculate the node behavior carbon pulse dispersion of the source node based on the time interval between adjacent interactions in the node carbon pulse window; calculate the node immunity risk value of the source node based on the on-chain interaction behavior information of the source node; calculate the node credential fit of the source node based on the data fields that the source node currently intends to provide.

[0021] The gray epidemic risk value of the source node is calculated based on the node behavior carbon pulse dispersion, node immunity risk value, and node credential engagement degree.

[0022] Furthermore, the generation of carbon dimension field vectors based on key fields, and the generation of independently verifiable base folds based on carbon dimension field vectors, includes:

[0023] Based on the bag-of-words model, key fields corresponding to the certificate number, project number, carbon content, verification standard, issuing authority, ownership entity, usage restrictions, and circulation status in carbon asset certificates are identified.

[0024] The key fields are standardized and encoded according to the preset encoding rules to generate a carbon dimension field vector.

[0025] For each key field in the carbon dimensional field vector, introduce field perturbation salt values ​​and basic texture lobe naming keywords, and call a hash function to generate the corresponding independently verifiable basic texture lobe.

[0026] Furthermore, multiple basic texture lobes are misaligned and folded according to preset misalignment mapping rules and cyclic displacement amounts to generate a misalignment texture summary, including:

[0027] Obtain all basic pattern petals and determine the field misalignment mapping sequence based on the voucher number, on-chain block height, voucher version number, field sequence number, or preset mapping table;

[0028] Select basic pattern petals according to the sequence, and determine the cyclic displacement amount based on the field sequence number, voucher number, field perturbation salt value or on-chain block information, and perform cyclic displacement on the corresponding basic pattern petals;

[0029] The misaligned basic pattern lobes are combined with the cyclically displaced basic pattern lobes in position to obtain the intermediate folded result.

[0030] The keyword "misaligned crease" is concatenated with the intermediate folding results and then hashed to generate a summary of the misaligned crease.

[0031] Furthermore, based on the signature echo coherence rules, on-chain trusted verification is performed on the signature data corresponding to the carbon asset certificate to be verified, generating on-chain signature verification results including:

[0032] Generate a signature authorization spectrum by binding the signature public key, signature role, registration authority, authorization limit, and signature time slice;

[0033] The misaligned crease summary, signature image spectrum, voucher number and signature salt value are concatenated to form the data to be verified;

[0034] The signature public key is used to verify the data to be signed and the signature value, generating a complex salt echo verification result.

[0035] Generate signature temporal coherence based on complex salt echo verification results;

[0036] By combining the signature temporal coherence and the comparison results of the unused shadow salt code, the on-chain verification result is output. The unused shadow salt code is generated from the credential number, the misaligned crease digest, the signature value, the signature salt value, and the signature subject identifier.

[0037] Furthermore, the generation of signature temporal coherence based on the complex salt echo verification results includes:

[0038] The verification results of the complex salt echo are quantified, with 1 for successful verification and 0 for failed verification; the current verification time, signature generation time, signature time decay constant, current signature authority shadow spectrum and on-chain signature authority shadow spectrum are obtained; the signature time offset and signature authority shadow spectrum difference are calculated and combined with the quantization results to generate the signature temporal coherence.

[0039] Furthermore, the circulation status of the carbon asset certificates to be verified is subject to on-chain trusted verification, generating on-chain verification results of the circulation status, including:

[0040] Obtain the circulation status data and sort the circulation events by block height, transaction time, or event sequence number;

[0041] The current circulation pulse code is generated based on the previous circulation pulse code, voucher number, current circulation status, transferor account, transferee account, carbon quantity, and circulation time;

[0042] The carbon amount occupied, locked, or consumed in each circulation event is statistically analyzed to generate the carbon conservation funnel results.

[0043] Perform time sequence consistency and state level consistency verification, and generate reverse-order damping anomaly results;

[0044] The combined results of the carbon conservation funnel and the reverse-order damping anomaly output the verification results on the flow state chain.

[0045] Furthermore, timing consistency and state level consistency are verified, and the reverse-order damping anomaly results are generated, including:

[0046] Read the occurrence time, block height, and transaction confirmation order of adjacent transaction events in sequence;

[0047] Determine if there is time inversion, block height inversion, or inconsistent event sequence numbers;

[0048] Call the preset flow status level table and compare the allowed migration relationships between adjacent flow statuses;

[0049] When there is historical event insertion, state rollback, re-transition after termination, or illegal migration, a reverse-order damped abnormal result is generated.

[0050] Compared to existing solutions, the beneficial effects achieved by this invention are:

[0051] Before performing on-chain verification of carbon asset certificates, this invention first performs trusted pre-verification on the source node. By using the node carbon pulse window, node immune hazard value, and node certificate fit, it determines whether the source node meets the conditions for on-chain verification. This can identify abnormal nodes, unauthorized nodes, or nodes with high-risk behavior during the data upload stage, preventing untrusted data from entering the subsequent verification process and improving the reliability of on-chain verification of carbon asset certificates from the source.

[0052] This invention generates carbon asset certificate base patterns and misaligned crease summaries from key fields such as certificate number, project number, carbon content, ownership entity, usage restrictions, and current circulation status. By comparing the recalculated summaries with the on-chain stored summaries, it can identify abnormal situations such as certificate fields being modified, field order being adjusted, field sources being replaced, or historical summaries being reused, thereby improving the tamper-proof capability of carbon asset certificate content.

[0053] This invention further combines signature echo coherence rules and on-chain verification mechanisms for circulation status to comprehensively assess certificate signatures, signature salt values, authorized limits, signature times, circulation pulse codes, carbon conservation results, and state transition relationships. This enables the identification of risks such as old signature reuse, signature replay, reuse without unreleased staking, recirculation after offsetting or cancellation, insertion / deletion of historical circulation events, or state rollback. Therefore, this invention achieves reliable on-chain verification of carbon asset certificate summaries, signatures, and circulation status, effectively preventing certificate reuse and tampering. Attached Figure Description

[0054] To more clearly illustrate the technical solutions in the embodiments of this application or the prior art, the drawings used in the embodiments will be briefly introduced below. Obviously, the drawings described below are only some embodiments recorded in this invention. For those skilled in the art, other drawings can be obtained based on these drawings.

[0055] Figure 1 This is a flowchart of the first on-chain credible verification method for carbon asset certificates according to an embodiment of the present invention.

[0056] Figure 2 This is a flowchart of the second on-chain credible verification method for carbon asset certificates according to an embodiment of the present invention.

[0057] Figure 3 This is a flowchart of the third on-chain credible verification method for carbon asset certificates according to an embodiment of the present invention. Detailed Implementation

[0058] 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.

[0059] Furthermore, the described features, structures, or characteristics can be combined in any suitable manner in one or more exemplary embodiments. Numerous specific details are provided in the following description to give a full understanding of exemplary embodiments of this disclosure. However, those skilled in the art will recognize that the technical solutions of this disclosure can be practiced with one or more of the specific details omitted, or other methods, components, steps, etc., can be employed. In other instances, well-known structures, methods, implementations, or operations are not shown or described in detail to avoid obscuring various aspects of this disclosure.

[0060] This invention provides a trusted on-chain verification method for carbon asset certificates. This method can be applied to blockchain systems used for verifying carbon asset certificate data. Figure 1 This is a flowchart of the first on-chain trusted verification method for carbon asset certificates according to an embodiment of the present invention, as follows: Figure 1 As shown, the method includes:

[0061] Step 1, Source Node Trust Pre-Verification: Respond to the on-chain trust verification request of the source node corresponding to the carbon asset certificate to be verified and determine whether the source node corresponding to the carbon asset certificate to be verified meets the on-chain conditions.

[0062] Figure 2 This is a flowchart of the second on-chain trusted verification method for carbon asset certificates according to an embodiment of the present invention, as follows: Figure 2 As shown, determining whether the source node corresponding to the carbon asset certificate to be verified meets the on-chain conditions includes the following process:

[0063] In response to the on-chain trusted verification request for the source node corresponding to the carbon asset certificate to be verified, determine the source node cluster corresponding to the source node:

[0064] Before obtaining multi-source verification data for the carbon asset certificate to be verified, the source node corresponding to the carbon asset certificate to be verified must be identified, and the reliability of the source node must be assessed. The source node includes one or more of the following: carbon asset issuance node, registration node, verification node, trading platform node, offset registration node, staking registration node, on-chain oracle node, and data gateway node.

[0065] Based on the carbon asset certificate number to be verified, the source nodes associated with the certificate are obtained from the on-chain node registration contract, the carbon asset registration system, and the certificate source mapping table, forming a source node cluster:

[0066]

[0067] in, This represents the set of source nodes associated with the carbon asset certificate to be verified, which originates from the node set generated by the verification system based on the source relationship of the certificate fields. Indicates the first Each source node originates from the node identifier registered on the blockchain, such as carbon asset registration nodes, issuance nodes, transaction nodes, and staking registration nodes; Indicates the first Each certificate field, such as project number, carbon content, issuing authority, certification standard, ownership entity, usage restrictions, or circulation status; Represents voucher fields The source node originates from the on-chain node registration contract, data source mapping table, or credential field source record.

[0068] After forming the source node cluster, the verification system uses the source node cluster as the scope of the node trust pre-verification object, and establishes a corresponding behavior observation object for each source node in the source node cluster. Since different certificate fields may come from different business nodes, and the issuance, registration, verification, trading, offsetting, staking, or oracle reporting behavior of the same carbon asset certificate is generated by different source nodes, the source node cluster limits the set of nodes whose on-chain interaction behavior needs to be collected. Within a preset observation window, the verification system retrieves on-chain transaction records, node access logs, signature records, event logs, and block header information corresponding to each source node according to the node identifier in the source node cluster. It then aggregates multiple on-chain interactions of the same source node within this observation window in chronological order to form a node carbon pulse window corresponding to that source node. A node carbon pulse window refers to the set of on-chain interaction records of a source node within the preset observation window, ordered by time. Thus, a one-to-one or one-to-many relationship is formed between source node clusters and node carbon pulse windows; that is, each source node in a source node cluster corresponds to at least one node carbon pulse window. The node carbon pulse window is used to characterize the on-chain interaction rhythm, signature status, data digest changes, and block time sequence status of the source node in the relevant business of the carbon asset certificate to be verified.

[0069] Specifically, the on-chain interaction behavior of the source node within a preset observation period is regarded as the node carbon pulse, and a node carbon pulse window is constructed: ;

[0070] in, Indicates the first The node carbon pulse window of each source node within a preset time range; Indicates the first The source node The time of each on-chain interaction is derived from the on-chain transaction timestamp or node access log; Indicates the first The source node The node signature corresponding to this interaction is derived from the on-chain transaction signature; Indicates the first The source node The data summary submitted in each interaction comes from on-chain event logs, oracle reporting records, or node data messages; Indicates the first The source node The block hash of the block where the next interaction occurs is derived from the blockchain block header; This indicates the length of the node pre-verification observation window, which is derived from system configuration or smart contract parameters. This indicates the current verification time, which is derived from the verification system time or the on-chain block time.

[0071] Calculate the carbon pulse dispersion of node behavior based on the time interval between adjacent interactions in the node carbon pulse window:

[0072]

[0073] in, Indicates the first Carbon pulse dispersion of node behavior corresponding to each source node; Indicates the first The source node The timing of the next on-chain interaction; Indicates the number of interaction records within the node's carbon pulse window; Indicates the first The average interaction interval of each source node within the observation window is derived from the average time interval of the node's carbon pulse window; when The larger the value, the more significant the change in the interaction rhythm of the source node, which may indicate risks such as concentrated reporting, abnormal preemption, concentrated submission after being hijacked, or resumption of submission after abnormal silence.

[0074] Abnormal node behavior is considered a danger signal, including identity migration, signature failure, duplicate signature salt values, abnormal latency, frequent changes in data digests, and unauthorized field submissions. A node immunity danger value is then calculated. :

[0075]

[0076] Among them, the node immunity risk value refers to the weighted anomaly degree of abnormal events such as identity migration, signature failure, duplicate signature salt value, abnormal delay, frequent changes in data digest, and submission of unauthorized fields. The number of danger signal types is derived from the system's preset node risk index table; Indicates the first The weights of different types of danger signals are derived from system configuration, regulatory rules, or training results from historical anomaly samples; Indicates the first The source node In the second interaction The observations of danger signals are derived from node access logs, on-chain transaction records, signature verification records, and field authorization records; Indicates the first The source node The historical baseline average of the danger signal is derived from the node's historical trusted interaction records or the regulatory system's baseline library; Indicates the first The source node The historical standard deviation of the danger signal is derived from the node's historical trusted interaction records or the regulatory system's benchmark library. This represents an extremely small positive number that prevents the denominator from being zero, and is derived from the system's calculation configuration.

[0077] Determine whether the data fields that the source node intends to provide match its on-chain authorization scope, certificate type, and carbon asset quota, and generate the node certificate fit. Node credential fit refers to the degree of matching between the fields the source node intends to provide and its authorized field range, operable carbon quantity, and authorization validity period.

[0078]

[0079] In the formula, Indicates the first Each source node is intended to provide a set of fields for carbon asset certificates to be verified, which are derived from the node data reporting declaration or the certificate source mapping table. Indicates the first The set of fields that a source node is authorized to provide or modify comes from the on-chain node authorization contract, the institutional permission system, or the regulatory configuration table; This indicates an indicator function that takes the value 1 when the condition is true and 0 when the condition is false. Indicates the first The remaining operable carbon credits for each source node come from on-chain authorized credit contracts or the carbon asset registration system; This indicates that the verification was conducted by the [number]th [person / entity]. The carbon amount involved in each source node comes from carbon asset certificates to be verified, transfer events, or node-reported data. Indicates the first The most recent authorization time of each source node is derived from on-chain authorization events or institutional authorization records; This represents the node authorization time decay constant, which originates from system configuration or regulatory rules.

[0080] Based on the carbon pulse dispersion of node behavior, node immunity risk value and node certificate overlap, a node gray epidemic risk value is generated. Based on the node gray epidemic risk value, it is determined whether the source node meets the node trust verification requirements. Source nodes that meet the node trust verification requirements are allowed to upload multi-source verification data of carbon asset certificates to be verified. Source nodes that do not meet the node trust verification requirements are not allowed to upload multi-source verification data of carbon asset certificates to be verified.

[0081] Specifically, generate node gray epidemic risk values. :

[0082]

[0083] in, The carbon pulse dispersion normalization constant is derived from system configuration or historical node behavior statistics. , and As a weighting coefficient, preferably, in order to accurately determine whether the source node meets the node trust verification requirements, , and The values ​​are set to 0.35, 0.45, and 0.2 respectively; where the node gray epidemic risk value refers to the risk score of abnormal interaction on the source node chain.

[0084] Furthermore, load the gray epidemic risk value threshold for the node and determine the gray epidemic risk value of the node. If the threshold for gray epidemic risk value of a node is exceeded, and if not, the source node is determined to meet the node trust verification requirements; if yes, the source node is determined not to meet the node trust verification requirements.

[0085] Step 2: For source nodes that meet the conditions for on-chain verification, obtain the multi-source verification data corresponding to the carbon asset certificates to be verified uploaded by them.

[0086] Source nodes that meet the node trust verification requirements are permitted to upload multi-source verification data for carbon asset certificates to be verified, and acquire this multi-source verification data, which includes original certificate data, on-chain evidence storage data, signature data, and circulation status data. Original certificate data includes carbon asset certificate number, project number, emission reductions, issuing authority, verification standard, issuance year, ownership entity, usage restrictions, issuance time, validity period, and certificate type. On-chain evidence storage data includes on-chain digest, on-chain signature shadow spectrum, on-chain circulation events, on-chain status, previous block hash, smart contract address, transaction hash, and block height. Signature data includes signature value, signature public key, signature time, signature salt value, signature entity role, authorized amount, authorized validity period, and issuing authority identifier. Circulation status data includes circulation events such as transfer, offset, pledge, unpledge, cancellation, freezing, splitting, and merging, as well as the transferor, transferee, circulating carbon amount, usage, and time corresponding to each circulation.

[0087] Step 3: On-chain verification of the certificate digest based on the carbon-based fingerprint:

[0088] The key fields in carbon asset certificates are identified based on the bag-of-words model. These key fields may include certificate number, project number, carbon content, certification standard, issuing authority, ownership entity, usage restrictions, current circulation status, carbon asset type, certification authority, on-chain account address, validity period, and circulation purpose.

[0089] Key fields in carbon asset certificates Perform standardized coding to generate a carbon dimensional field vector. :

[0090]

[0091] In the formula, The carbon content value is a numeric field derived from the original data of the voucher. ; This indicates the rounding operation. This indicates the project number, which is derived from the carbon emission reduction project registration system. This indicates the verification standard or verification rule identifier, which originates from the original fields of the credential or on-chain registration records; Indicates the year of issuance or the year to which the emission reduction belongs, derived from the voucher issuance record; The identifier representing the ownership entity originates from the corporate carbon account, registration account, or on-chain account address. The indication of usage restriction is derived from the usage field of the carbon asset certificate. This indicates the field encoding function, which is derived from the system's preset encoding rules.

[0092] Key fields in the carbon dimensional field vector Generate a partial summary to form independently verifiable base pattern petals. The carbon certificate base pattern or base pattern petal refers to the field-level hash commitment corresponding to the key fields of the carbon asset certificate.

[0093] in, The hash function is derived from the system's cryptographic algorithm configuration. Hash functions can include: HMAC-SHA256, HMAC-SHA512, or HMAC-SM3. This indicates a custom-named keyword derived from a system-preset constant. This indicates the field perturbation salt value, which originates from the system's random number generator, the credential issuance system, or the salt value assigned by the on-chain contract. Indicates data concatenation;

[0094] After obtaining multiple basic pattern lobes, the verification system does not simply concatenate them according to the original field order of the carbon asset certificate. Instead, it performs misaligned folding processing on the multiple basic pattern lobes according to a preset misalignment mapping rule to generate a misaligned folding summary: The verification system first obtains all basic pattern lobes participating in the summary calculation and determines the field misalignment mapping sequence based on the certificate number, on-chain block height, certificate version number, field sequence number, or a system preset mapping table. This field misalignment mapping sequence is used to change the order in which the basic pattern lobes participate in subsequent summary processing, so that the basic pattern lobes are no longer combined solely according to the original field arrangement. Subsequently, the verification system selects the corresponding basic pattern lobes according to the field misalignment mapping sequence and performs cyclic displacement processing on the basic pattern lobes corresponding to the original field sequence number. The displacement amount of the cyclic displacement processing can be determined by the field sequence number, certificate number, field perturbation salt value, or on-chain block information. The verification system performs position-by-position combination processing on the misaligned basic pattern lobes and the cyclically shifted basic pattern lobes to obtain multiple folded intermediate results. After obtaining all the folded intermediate results, the verification system concatenates the custom-named keyword "misaligned crease" with multiple folded intermediate results in a preset order, and calls a preset hash algorithm to generate a misaligned crease summary of the carbon asset certificate to be verified. Through the above processing, the misaligned crease summary is simultaneously affected by field content, field source, field order, field perturbation salt value, misalignment mapping sequence, and cycle displacement. If an attacker modifies only a local field, adjusts the field order, replaces the field source, or reuses historical field summaries, the misaligned crease summary will change, thereby improving the tamper resistance and field recombination identification capabilities of the carbon asset certificate summary. The misaligned crease summary is not only used to determine whether the certificate as a whole has been tampered with, but also to generate field crack location vectors. When calculating the misaligned crease summary, the verification system retains the field identifier, field source node, field version number, and cycle displacement position corresponding to each basic crease petal. When the misaligned crease summary is inconsistent with the on-chain evidence storage summary, the verification system generates a field crack location vector by recalculating field by field and reverse-engineering the misalignment mapping. This vector is used to identify the replaced field, the order adjustment field, the inconsistent source node field, or the historically reused field.

[0095] The recalculated misalignment crack summary is compared with the on-chain evidence summary to calculate the crack severity. :

[0096]

[0097] in, Represent the Hamming distance function; Summary of misaligned creases For on-chain evidence digest; The digest bit length is represented by the length output by the selected hash algorithm; when the digest is cracked... If the verification threshold is not exceeded, the verification of the credential summary is considered successful; otherwise, the summary is considered to be at risk of being tampered with. The verification threshold for the summary is configured by the system.

[0098] Step 4: Based on the signature echo coherence rule, perform on-chain trusted verification of the signature data corresponding to the carbon asset certificate to be verified, and generate the on-chain signature verification result.

[0099] Figure 3 This is a flowchart of the third on-chain trusted verification method for carbon asset certificates according to an embodiment of the present invention, as follows: Figure 3 As shown, after completing the on-chain verification of the carbon asset certificate summary, the verification system further performs on-chain trusted verification of the signature data corresponding to the carbon asset certificate to be verified, generating the signature on-chain verification result. The specific on-chain verification process includes the following steps:

[0100] By binding the signing public key, signing role, registration authority, authorization limit, and signing time slice, a signing authorization spectrum is generated. The signature spectrum refers to the context in which the signatory authorizes the signature.

[0101] This indicates that the signing public key originates from a signing certificate, on-chain account, public key registry, or key management system. The signatory role is indicated by either the carbon asset registration agency's access control system or an on-chain role contract. The identifier of the registration agency is derived from the carbon asset registration system, on-chain agency registration contract, or agency certificate. Indicates the time slice number to which the signature belongs; This indicates the remaining issueable, transferable, or operable carbon credits of the signatory within the corresponding time slice, sourced from an authorized credit agreement, carbon account balance agreement, or a registration agency's authorized database.

[0102] The verification system obtains the misaligned crease summary, signature image spectrum, carbon asset certificate number, signature salt value, and signature value generated in the aforementioned steps, and combines the misaligned crease summary, signature image spectrum, carbon asset certificate number, and signature salt value into data to be verified according to preset splicing rules. The carbon asset certificate number originates from the original certificate data or on-chain certificate registration record and is used to identify the unique certificate object corresponding to the signature; the signature salt value originates from the signature generation end or on-chain signature record and is used to prevent the same certificate content from generating reusable signatures in different signature scenarios; the signature value originates from the signature data submitted by the signing entity or on-chain signature record.

[0103] The verification system uses a signing public key to perform digital signature verification on the data to be verified and the signature value. If the verification passes, a multi-salted echo verification result is generated indicating successful verification; if the verification fails, a multi-salted echo verification result is generated indicating failed verification. For multi-salted echo verification to be considered a valid signature, the signature value must simultaneously match the document digest, the authorization status of the signing entity, the document number, and the signature salt value. Multi-salted echo verification involves binding the document digest, authorization context, document number, and signature salt value together for digital signature verification; thus, even if an attacker obtains a historical signature, it is difficult to reuse that signature for other carbon asset documents, other authorization statuses, or other signature salt value scenarios. Furthermore, the multi-salted echo verification results indicating successful and failed verification are quantified, and the numerical value corresponding to the multi-salted echo verification result indicating successful verification is... A value of 1 indicates the numerical value corresponding to the re-salt echo verification result of a failed signature verification. Set to 0;

[0104] The signature temporal coherence is generated by comprehensively calculating the signature verification result, the consistency of the authorization spectrum, and the signature time offset. :

[0105]

[0106] in, Indicates the current verification time; Indicates the moment the signature was generated, which may originate from signature data, signature certificate timestamp service, or on-chain signature event; This represents the signature time decay constant, which originates from system configuration or regulatory rules. The length of the signed image spectrum bits is derived from the output length of the selected hash algorithm. This indicates that the signature image spectrum stored on the chain originates from the on-chain signature storage contract;

[0107] To prevent the reuse of the same signature value, signature salt value, or signature material, the verification system further generates a shadow salt unused code: The verification system obtains the signature value, signature salt value, misaligned crease digest, and previous block hash, and concatenates them according to a preset field order, then combines them with a preset "shadow salt unused code" naming keyword to generate a shadow salt unused code. The previous block hash comes from blockchain nodes or on-chain block header information. The previous block hash serves as an on-chain time anchor value, used to bind the anti-replay identifier of this signature to a specific on-chain time position, preventing the same signature material from being submitted repeatedly in different block contexts. The shadow salt unused code refers to a one-time use identifier for the signature material; the verification system compares the generated shadow salt unused code with the set of shadow salt unused codes already registered on the chain. If the shadow salt unused code does not exist in the on-chain registered set, it is determined that the signature material has not been used; if the shadow salt unused code already exists in the on-chain registered set, it is determined that the signature material has a risk of reuse or signature replay. The set of unused shadow salt codes registered on-chain comes from the smart contract state table or on-chain event index. After verification, the system writes the newly generated unused shadow salt codes onto the chain so that duplicate signature materials can be identified during subsequent verifications.

[0108] The verification system outputs the on-chain verification result based on the resalted echo verification result, signature temporal coherence, and unused shadow salt code comparison result. When the resalted echo verification passes, the signature temporal coherence meets the preset threshold, and the unused shadow salt code does not appear in the on-chain registered set, the on-chain verification of the carbon asset certificate is deemed successful. When the resalted echo verification fails, it indicates that the signature value does not match the certificate summary, authorizing shadow spectrum, certificate number, or signature salt value, and the signature is deemed invalid. When the resalted echo verification passes but the signature temporal coherence does not meet the preset threshold, it indicates that the signature may have expired submission, inconsistent authorization status, abnormal role permissions, or mismatched quota risks, and the signature needs to be frozen for review. When the resalted echo verification passes but the unused shadow salt code already exists in the on-chain registered set, it indicates that the signature material has been used, indicating a risk of signature replay or reuse, and the verification operation is rejected.

[0109] Through the above steps, the system can jointly verify the identity of the signing entity, role permissions, registration authority, authorized amount, signing time, certificate digest, signature salt value and on-chain status without relying on a single public key verification result. This improves the credibility of on-chain verification of carbon asset certificate signatures and reduces the risks of unauthorized signatures, reuse of old signatures, signature replay, and signatures becoming detached from certificate content.

[0110] Step 5: After completing the on-chain verification of the signature, perform on-chain trusted verification of the circulation status of the carbon asset certificate to be verified, and generate the on-chain verification result of the circulation status.

[0111] After completing the carbon asset certificate summary verification and on-chain signature verification, the verification system further performs on-chain trusted verification of the circulation status of the carbon asset certificates to be verified:

[0112] The circulation status data includes one or more of the following: transfer events, offset events, staking events, unstaking events, cancellation events, freeze events, split events, and merger events. Each circulation event includes at least the carbon asset certificate number, current circulation status, previous circulation status, transferor account, transferee account, circulation carbon amount, circulation purpose, circulation occurrence time, on-chain transaction identifier, and block height. The carbon asset certificate number is derived from the original certificate data or on-chain certificate registration records; the circulation status is derived from on-chain circulation events, carbon trading platform records, offset registration system, staking registration system, or cancellation registration system; the transferor and transferee are derived from on-chain transaction events, carbon asset account system, or carbon trading platform; the circulation carbon amount is derived from circulation application records, offset application records, staking registration records, or on-chain event parameters; the circulation time is derived from on-chain block time, transaction confirmation time, or carbon asset registration system time.

[0113] The verification system sorts each transfer event of the carbon asset certificate to be verified according to the order of occurrence. The sorting criteria include on-chain block height, on-chain transaction time, registration system confirmation time, and transfer event sequence number. When there are discrepancies among multiple time sources, on-chain block height and on-chain transaction confirmation time are given priority as the primary sorting criteria, with registration system confirmation time used as a secondary sorting criterion.

[0114] For the current transfer event, the verification system obtains the transfer pulse code, carbon asset certificate number, current transfer status, transferor account, transferee account, current transferred carbon amount, and current transfer time corresponding to the previous transfer event. These are then standardized and concatenated according to a preset field order. Combined with a preset "transfer pulse code" naming keyword, a transfer pulse code corresponding to the current transfer event is generated. The transfer pulse code corresponding to the previous transfer event originates from historical on-chain transfer records. When the current transfer event is the first transfer event for this carbon asset certificate, the previous transfer pulse code uses the genesis pulse code, which is generated from the carbon asset certificate number, initial issuance time, initial issuing institution, and initial carbon amount. The current transfer status indicates which business state this transfer belongs to: transfer, pledge, unpledge, offset, cancellation, freeze, split, or merger. The transferor account and transferee account indicate the change in ownership of the carbon asset certificate or a portion of its carbon amount. The current transferred carbon amount indicates the scale of carbon involved in this transfer. The current transition time is used to define the temporal position of this transition event in the chain's state sequence.

[0115] The verification system obtains the initial carbon amount of the carbon asset certificate to be verified and statistically analyzes the carbon usage or consumption of each circulation stage according to the sequence of circulation events, generating a carbon conservation funnel result. This result refers to the consistency verification result of carbon usage, locking, offsetting, cancellation, and remaining available carbon in the circulation events. The initial carbon amount originates from carbon asset certificate issuance records, the carbon asset registration system, or on-chain initial registration events. The carbon amount involved in each circulation event originates from on-chain circulation events, transfer transaction records, offsetting application records, staking registration records, or cancellation registration records. Different circulation stages correspond to different carbon processing rules.

[0116] When the transfer status is ordinary transfer, the transfer event only changes the ownership of the carbon asset and does not reduce the available carbon amount on the certificate. The verification system records the changes in the transferor and transferee corresponding to this carbon amount, but does not include this carbon amount in the consumed carbon amount.

[0117] When the circulation status is offset or cancelled, the circulation event indicates that the corresponding carbon credits have been actually used or withdrawn from circulation. The verification system will include the corresponding carbon credits in the consumed carbon credits and prohibit this portion of carbon credits from being used for transfer, offset, pledge, or other occupation operations in subsequent verifications.

[0118] When the transfer status is pledged, the transfer event indicates that the corresponding carbon credits are frozen or secured. The verification system will include this portion of carbon credits in the locked carbon credits, and this portion of carbon credits will not be allowed to be offset, re-pledged, or transferred without restriction before the pledge is released.

[0119] When the transfer status is "unpledged," the verification system checks whether the unpledged event corresponds to an existing pledged event that has not yet been released. If a matching unreleased pledged event exists, the corresponding locked carbon amount is released; if no matching pledged event exists, the unpledged event is determined to have an abnormal status.

[0120] When the transfer status is split, the verification system divides the available carbon amount of the original carbon asset certificate into multiple sub-certificates or multiple carbon amount fragments according to the split record, and keeps the sum of the carbon amount of each fragment from not exceeding the remaining available carbon amount of the original certificate.

[0121] When the circulation status is merged, the verification system verifies whether all the multiple vouchers or fragments involved in the merge are in an available state, and verifies whether the total carbon amount after the merge is equal to the sum of the available carbon amounts involved in the merge.

[0122] The verification system verifies the consistency of the time sequence and the consistency of the state level of the historical transfer events of carbon asset certificates, and generates reverse-order damping anomaly results. Reverse-order damping anomalies refer to the results of the time sequence of transfer events being reversed or the state machine being illegally transitioned.

[0123] In the temporal consistency verification, the verification system compares the occurrence time of adjacent events, the on-chain block height, and the transaction confirmation order in sequence. If the occurrence time of a later event is earlier than that of a previous event, or the block height corresponding to a later event is lower than that of a previous event, or the transaction confirmation order is inconsistent with the on-chain event sequence number, then it is determined that there is a risk of time reversal or insertion of historical events.

[0124] In the consistency verification of status levels, the verification system pre-sets a flow status level table. This table includes the following: Issued, Available, Locked, Pledged, Unpledged, Transferred, Split, Merged, Offset, Cancelled, Frozen, and Invalidated. Permissible migration relationships include Issued to Available, Available to Transfer, Pledged, Offset, Cancelled, or Frozen, Pledged to Unpledged or Pledge Disposal, and Frozen to Unfreezing or Invalidated. Termination statuses include Offset, Cancelled, and Invalidated; a termination status cannot be migrated back to Available, Transferred, Pledged, or Offset. This status level table characterizes the permissible flow relationships between different business statuses. For example, an initial issuance status can enter a Transferred, Pledged, Frozen, or Offset status; a Pledged status cannot directly enter an Offset or Re-Pledged status before being unpledged; Offset and Cancelled statuses are typically termination statuses and cannot revert to a Transferable or Pledgeable status.

[0125] The verification system sequentially compares the status levels and permissible migration relationships of adjacent transfer events. If the current transfer status undergoes an unpermitted rollback relative to the previous transfer status, or if a new transfer, pledge, or offset event occurs after the termination status, it is determined that there is a risk of status rollback, status tampering, or illegal transfer.

[0126] By identifying anomalies caused by reversed damping, the system can detect anomalies that are difficult to identify using a single state field. For example, an attacker could re-mark offset certificates as tradable or insert earlier transfer records into the historical transaction sequence, both of which can be identified through temporal consistency and state level consistency verification.

[0127] The verification system integrates the verification results of the pulse code, the carbon conservation funnel, and the reverse-sequence damping anomaly results to output the verification results on the flow state chain.

[0128] If the current transfer pulse code is consistent with the on-chain transfer pulse code, the historical transfer pulse codes are continuous, the carbon conservation result is normal, and there is no time sequence reversal or state rollback anomaly, the on-chain verification of the transfer status of the carbon asset certificate is deemed to have passed.

[0129] When the pulse code of the flow is inconsistent with the record on the chain, or when any historical flow event causes the subsequent pulse codes to be unable to match continuously, it is determined that there is a risk of tampering, deletion, insertion or order adjustment of the historical flow event.

[0130] When the carbon conservation result is abnormal, such as the cumulative carbon consumption exceeding the initial carbon amount, the current circulating carbon amount exceeding the available carbon amount, repeated use before the pledge is released, or re-transfer after offsetting or re-circulation after cancellation, it is determined that there is a risk of repeated use or overuse.

[0131] When the reverse-order damping anomaly results indicate that the occurrence time of the flow event is reversed, the block height is reversed, the final state is rolled back, or the state transition does not conform to the preset state level table, it is determined that there is a risk of state rollback or illegal flow.

[0132] When the above anomalies do not meet the direct rejection conditions but there are missing data, delayed synchronization of on-chain events, reduced weight of source nodes, or insufficient state evidence, the system can mark the transfer status verification result as frozen for review and write the anomaly cause, related transfer events, and the corresponding on-chain transaction identifiers into the review task.

[0133] The on-chain verification results of the summary, signature, and circulation status output in this embodiment are used to control whether the on-chain trusted verification server allows the carbon asset certificate to be verified to be written into the verification pass record, whether to place the data submitted by the source node into the abnormal isolation queue, and whether to reject duplicate signature materials or duplicate circulation status requests. This method is not used for manual evaluation of carbon asset value or trading intention, but for computer security verification of the integrity of on-chain data, signature credibility, and consistency of circulation status of carbon asset certificates. It can simultaneously realize the verification of circulation status continuity, carbon conservation, status rollback identification, and fragmented reuse identification during the on-chain verification process. Compared with the method of querying only a single status field, this step can more accurately identify the tampering risk and reuse risk of carbon asset certificates in complex circulation scenarios such as transfer, offset, pledge, cancellation, splitting, and merging.

Claims

1. A reliable on-chain verification method for carbon asset certificates, characterized in that, The method includes the following steps: Step 1, Source Node Trust Pre-Verification: Respond to the on-chain trust verification request of the source node corresponding to the carbon asset certificate to be verified and determine whether the source node corresponding to the carbon asset certificate to be verified meets the on-chain conditions. Step 2: For source nodes that meet the conditions for on-chain verification, obtain the multi-source verification data corresponding to the carbon asset certificates to be verified uploaded by them. Step 3, On-chain Verification of Certificate Summary Based on Carbon Certificate Texture: Identify key fields in multi-source verification data, generate carbon quantity field vectors based on these key fields, and generate independently verifiable texture petals based on these carbon quantity field vectors. The carbon certificate texture or texture petal refers to the field-level hash commitment corresponding to the key fields of the carbon asset certificate. Generating carbon quantity field vectors based on key fields and generating independently verifiable texture petals based on these carbon quantity field vectors includes: identifying the certificate number, project number, carbon quantity, verification standard, issuing authority, and ownership in the carbon asset certificate based on a bag-of-words model. The system identifies key fields corresponding to the subject, usage restrictions, and circulation status; standardizes and encodes these key fields according to preset encoding rules to generate a carbon dimension field vector; introduces field perturbation salt values ​​and naming keywords for each key field in the carbon dimension field vector, and calls a hash function to generate corresponding independently verifiable base pattern petals; folds multiple base pattern petals according to preset misalignment mapping rules and cyclic displacement to generate a misaligned folding digest; the verification system first obtains all base pattern petals participating in the digest calculation, and then verifies them based on the credential number, on-chain block height, credential version number, and fields. The field misalignment mapping sequence is determined by the serial number or a system-preset mapping table. This sequence is used to change the order in which the basic pattern lobes participate in subsequent digest processing, so that the lobes are no longer combined solely according to the original field arrangement. The verification system selects the corresponding lobes according to the field misalignment mapping sequence and performs cyclic displacement processing on the lobes corresponding to the original field serial number. The displacement amount of the cyclic displacement processing is determined by the field serial number, voucher number, field perturbation salt value, or on-chain block information. The verification system then performs position-by-position combination processing on the misaligned lobes and the cyclically shifted lobes to obtain... Multiple folded intermediate results; after obtaining all folded intermediate results, the verification system concatenates the custom-named keyword "misaligned crease" with the multiple folded intermediate results in a preset order, and calls a preset hash algorithm to generate a misaligned crease summary of the carbon asset certificate to be verified; the misaligned crease summary is compared with the on-chain evidence storage summary to obtain the summary crack degree, which is calculated based on the Hamming distance between the misaligned crease summary and the on-chain evidence storage summary and the summary bit length, and determines whether the certificate summary has a risk of tampering based on the summary verification threshold, which is configured by the system; Step four: After completing the on-chain verification of the certificate digest, perform on-chain trusted verification of the signature data corresponding to the carbon asset certificate to be verified based on the signature echo coherence rules, and generate the on-chain signature verification result: bind the signature public key, signature role, registration agency, authorization limit, and signature time slice to generate the signature authorization image spectrum, where the signature authorization image spectrum refers to the authorization context of the signing subject; concatenate the misaligned crease digest, signature authorization image spectrum, certificate number, and signature salt value to form the data to be verified; use the signature public key to verify the data to be verified and the signature value to generate a double-salted echo verification result, where the double-salted echo verification refers to the digital signature verification after binding the certificate digest, authorization context, certificate number, and signature salt value together. The verification result of the complex salt echo is either a successful or failed signature verification. The signature verification result, authorization shadow spectrum consistency, and signature time offset are comprehensively calculated to generate the signature temporal coherence. Combining the signature temporal coherence and the shadow salt unused code comparison result, the on-chain verification result is output. The shadow salt unused code is generated by the verification system by obtaining the signature value, signature salt value, misaligned crease digest, and previous block hash, concatenating them according to a preset field order, and then combining them with the preset "shadow salt unused code" naming keyword. The signature temporal coherence is calculated as follows: the signature verification result, authorization shadow spectrum consistency, and signature time offset are comprehensively calculated to generate the signature temporal coherence. : in, The quantitative value of the resalt echo verification result represents the numerical value corresponding to the successful resalt echo verification. A value of 1 indicates the numerical value corresponding to the re-salt echo verification result of a failed signature verification. Set to 0; Indicates the current verification time; Indicates the moment the signature was generated, which may originate from signature data, signature certificate timestamp service, or on-chain signature event; This represents the signature time decay constant, which originates from system configuration or regulatory rules. The length of the signed image spectrum bits is derived from the output length of the selected hash algorithm. This is the copyrighted photo album; This represents the on-chain stored signature image spectrum; Represent the Hamming distance function; Step 5: After completing the on-chain verification of the signature, perform on-chain trusted verification of the circulation status of the carbon asset certificate to be verified, and generate the on-chain verification result of the circulation status.

2. The on-chain credible verification method for carbon asset certificates according to claim 1, characterized in that, Determining whether the source node corresponding to the carbon asset certificate to be verified meets the on-chain conditions includes: Determine the source node cluster corresponding to the source node, where the source node cluster refers to the set of source nodes related to the carbon asset certificate to be verified, which is derived from the node set generated by the verification system based on the source relationship of the certificate fields. Using the source node cluster as the scope of the trusted pre-verification object of the source node, the on-chain interaction behavior information of the source node and the data fields that the source node intends to provide are obtained within the preset observation window; The gray epidemic risk value of the source node is calculated based on the on-chain interaction behavior information of the source node and the data fields that the source node intends to provide. The gray epidemic risk value refers to the abnormal risk score of the on-chain interaction of the source node, which is used to determine whether the source node meets the node trust verification requirements. When the gray epidemic risk value of the source node does not exceed the preset threshold, it is determined that the source node corresponding to the carbon asset certificate to be verified meets the conditions for on-chain.

3. The on-chain credible verification method for carbon asset certificates according to claim 2, characterized in that, Based on the on-chain interaction behavior information of the source node and the data fields that the source node currently intends to provide, the node gray epidemic risk value of the source node is calculated as follows: A node carbon pulse window is constructed based on the on-chain interaction behavior information of the source node. The node carbon pulse window refers to the set of on-chain interaction records of the source node sorted by time within a preset observation window. It is used to characterize the on-chain interaction rhythm, signature status, data digest changes and block time sequence status of the source node in the business related to the carbon asset certificate to be verified. Based on the time interval between adjacent interactions in the node carbon pulse window, the node behavior carbon pulse dispersion of the source node is calculated, which is used to characterize the changes in the interaction rhythm of the source node. Based on the on-chain interaction behavior information of the source node, the node immunity risk value of the source node is calculated, which refers to the weighted anomaly degree of identity drift, signature failure, duplicate signature salt value, abnormal delay, frequent changes in data digest, and non-authorized field submission anomaly events. Based on the data fields that the source node currently intends to provide, the node credential fit degree of the source node is calculated, which refers to the matching degree between the fields that the source node intends to provide and its authorized field range, operable carbon amount, and authorized validity period. The gray epidemic risk value of the source node is calculated based on the node behavior carbon pulse dispersion, node immunity risk value, and node credential engagement degree.

4. The on-chain credible verification method for carbon asset certificates according to claim 1, characterized in that, The on-chain trusted verification of the circulation status of the carbon asset certificates to be verified is performed, and the on-chain verification results of the circulation status are generated, including: Obtain the circulation status data and sort the circulation events by block height, transaction time, or event sequence number; The current circulation pulse code is generated based on the previous circulation pulse code, voucher number, current circulation status, transferor account, transferee account, carbon quantity, and circulation time; The carbon usage, locking, or consumption of each circulation event is statistically analyzed to generate a carbon conservation funnel result. The carbon conservation funnel result refers to the consistency verification result of carbon usage, locking, offsetting, cancellation, and remaining available amount in the circulation event. Perform time sequence consistency and state level consistency verification to generate reverse order damping anomaly results. The reverse order damping anomaly results are used to characterize state anomaly results such as reversed occurrence time of flow events, reversed block height, rollback of final state, or state transition that does not conform to the preset state level table. The combined results of the carbon conservation funnel and the reverse-order damping anomaly output the verification results on the flow state chain.

5. The on-chain credible verification method for carbon asset certificates according to claim 4, characterized in that, Perform timing consistency and state level consistency verification to generate reverse-order damping anomaly results, including: Read the occurrence time, block height, and transaction confirmation order of adjacent transaction events in sequence; Determine if there is time inversion, block height inversion, or inconsistent event sequence numbers; Call the preset flow status level table and compare the allowed migration relationships between adjacent flow statuses; When there is historical event insertion, state rollback, re-transition after termination, or illegal migration, a reverse-order damped abnormal result is generated.

Images