A method and system for verifying carbon asset transaction data

Abstract

The application provides a kind of carbon asset transaction data verification method and system, it is related to the technical field of data verification, the method comprises: generating unique project identification for each emission reduction project, and accordingly establish the association between each emission reduction project and multiple data tables;When receiving the transaction request proposed by the user for the target emission reduction project, obtain the in-table data from the multiple data tables based on the association, calculate the first tradable balance using the in-table data, and preliminarily compare the first tradable balance with the proposed transaction quantity;If it passes the preliminary comparison, retrieve the real-time data stored in the database according to the unique project identification, calculate the second tradable balance using the real-time data, and secondarily compare the second tradable balance with the proposed transaction quantity, and issue an alarm signal if the second comparison fails.The application can improve the accuracy of transaction results in a high-concurrency transaction scenario.

Description

Technical Field

[0001] This application relates to the technical field of data verification, and in particular to a method and system for verifying carbon asset trading data. Background Technology

[0002] Carbon asset trading, as an important market tool for achieving carbon neutrality, has developed rapidly globally in recent years. Carbon assets are essentially equity-consuming digital assets, and their trading process requires real-time and accurate verification of the tradable surplus of emission reduction projects to prevent overselling. Traditional carbon trading systems typically employ a single-table total surplus management approach, using database row locks or optimistic locking for transaction verification. However, this method is prone to hotspot row contention in high-concurrency trading scenarios, leading to decreased system throughput or even deadlocks. If offline aggregated data or cached data is used for verification, it can easily cause overselling issues, where multiple transactions pass verification simultaneously but the actual surplus is insufficient.

[0003] Chinese patent application CN119379223A, published on January 28, 2025, discloses an automated data verification system for carbon asset trading. This system employs an LSTM time series analysis unit combined with a sliding window technique to increase the number of training samples, and utilizes an SVM classification verification unit to process nonlinear data using kernel function techniques. Parameters are optimized through cross-validation, enabling the two systems to work synergistically to predict trends and identify anomalies in carbon data.

[0004] After the aforementioned scheme determines that there are no anomalies in the current transaction through a machine learning model, the transaction process immediately enters the execution phase. During this process, if multiple concurrent transaction requests are judged to be normal almost simultaneously, they will each perform deduction based on the remaining data read at the verification time. However, the existence of other concurrent transactions cannot be detected before the actual deduction is completed, which may ultimately lead to the actual total deduction exceeding the available remaining amount. Summary of the Invention

[0005] In order to improve the accuracy of transaction results in high-concurrency trading scenarios, this application provides a method and system for verifying carbon asset trading data.

[0006] Firstly, this application provides a method for verifying carbon asset trading data, employing the following technical solution: A method for verifying carbon asset trading data includes the following steps: Generate a unique project identifier for each emission reduction project, and establish the association between each emission reduction project and multiple data tables based on the unique project identifier; In response to a transaction request for a target emission reduction project, data is retrieved from the multiple data tables based on the correlation relationship, and a first tradable surplus is calculated based on the data in the tables; Obtain the proposed transaction quantity from the transaction request, compare the proposed transaction quantity with the first available tradable reserve in real time, and obtain the initial comparison result; When the initial comparison result meets expectations, real-time data is retrieved from the preset database based on the unique project identifier. The second tradable surplus is calculated based on the real-time data. The proposed tradable quantity is compared with the second tradable surplus to obtain the second comparison result. When the second comparison result does not meet expectations, an alarm signal is issued.

[0007] By adopting the above technical solution, this application can reduce the risk of over-trading in carbon emission reduction projects through a two-level margin verification mechanism. The first-level verification calculates the first tradable margin based on data from multiple tables, quickly screening transaction requests and blocking requests that significantly exceed the margin. This minimizes invalid requests from entering the high-cost real-time query process, thus significantly reducing system load in high-concurrency scenarios. The second-level verification, after the initial screening, retrieves real-time data from a preset database to calculate the second tradable margin, verifying the proposed transaction quantity. This allows for the detection of potential data window differences between the first-level verification and actual transaction execution, such as margin changes caused by concurrent transactions, thereby improving the accuracy of the final transaction results and reducing the risk of overselling.

[0008] This application achieves data-level decoupling by generating a unique project identifier for each emission reduction project and establishing its association with multiple data tables. The data table structure can evolve independently without affecting the association logic, and the same emission reduction project can flexibly mount different types of data tables. This application only needs to pass in the unique project identifier to automatically route to all associated tables for data retrieval, thereby improving the maintainability and scalability of the system.

[0009] Optionally, the verification method further includes: Based on preset attribute dimensions, the project registration volume of each emission reduction project is divided into multiple asset units, and a dynamic reserve field and a unique unit identifier are configured for each asset unit. The asset consumption strategy is set according to the dynamic reserve field and unique unit identifier of each asset unit. The dynamic reserve field is used to represent the tradable reserve of the asset unit.

[0010] This application divides the registered amount of a project into multiple asset units by pre-defined attribute dimensions, so that emission reductions of different attributes under the same emission reduction project (such as emission reductions generated from different sources, different types, and different regions) can be managed independently, thereby improving the overall transaction efficiency and surplus utilization rate of each emission reduction project.

[0011] This application configures a dynamic balance field and a unique unit identifier for each asset unit. The dynamic balance field can reflect the current tradable status of the asset unit in real time, and can capture the balance changes within the trading window better than static snapshots. The unique unit identifier makes the circulation path of each asset unit clear and traceable. In case of a dispute, it can be accurately located which unit has an abnormal balance, thus improving traceability.

[0012] This application sets up an asset consumption strategy based on the dynamic surplus field and unique unit identifier of each asset unit. This allows for the customization of different consumption rules for different units, adapting to diverse trading scenarios, rather than simply supporting a single mode where trading is possible as long as there is surplus. The asset unitization setting in this application has a risk isolation effect. If data anomalies or alarms are triggered in one asset unit, it will not affect other asset units or cause the entire emission reduction project to be frozen, thereby reducing risk.

[0013] Optionally, the database stores the lock timestamps of each dynamic margin field. When the second comparison result meets expectations, the verification method further includes: Obtain the used increment of the target emission reduction project, and determine the target combination that meets the proposed transaction quantity and the used increment from multiple asset units corresponding to the target emission reduction project according to the asset consumption strategy. Perform pre-occupancy processing on the target combination to obtain the pre-occupancy processing result. After the current transaction is confirmed, a database transaction is submitted and executed. The database transaction includes: based on the pre-occupancy processing result, converting the pre-occupancy amount of each asset unit into the traded amount or the used amount, updating the dynamic balance field of each asset unit, and updating the lock timestamp to the current timestamp.

[0014] This application introduces a pre-allocation process as a soft locking step before the formal transaction. Before the user confirms the transaction, the remaining amount of the target combination is pre-locked. This effectively prevents other concurrent transaction requests from preempting the remaining amount during the user's decision-making gap, and minimizes the possibility of the transaction passing verification but having no remaining amount at the time of submission. If the user ultimately cancels the transaction, the pre-allocation can be released without causing substantial resource loss, thus balancing transaction determinism and operational fault tolerance.

[0015] Optionally, the multiple data tables include an asset application registration table and a transaction details table, and the verification method further includes an update step, specifically: Update the proposed transaction quantity to the transaction details table, update the used increment to the asset application registration table, and output the quantity update result, which includes quantity update success and quantity update failure. If the dynamic balance field of an asset unit is zero, the status of the asset unit with the zero dynamic balance field is updated to "used up", and the status update result is output. The status update result includes status update success and status update failure. If the quantity update result is a quantity update failure or the status update result is a status update failure, the data in the database will be rolled back to the state before the database transaction was executed, and an update failure signal will be sent.

[0016] This application updates the proposed transaction quantity to the transaction details table and the used increment to the asset application registration table. These two tables have their own functions and do not interfere with each other. The transaction details table focuses on recording the flow data of each transaction, while the asset application registration table records the cumulative consumption. The separation of the two allows subsequent queries and audits to retrieve data from different dimensions as needed, without having to repeatedly filter through a large table. This reduces the write pressure on a single table and is beneficial for improving overall write performance in high-concurrency scenarios.

[0017] This application establishes an automatic status update mechanism after the dynamic balance reaches zero. When the tradable balance of an asset unit drops to zero, its status is automatically updated to "used up," establishing a clear lifecycle marker for the asset unit. Subsequent transaction requests, when scanning tradable units, can directly filter out used units through the status field without recalculating the balance, thereby improving query efficiency.

[0018] Optionally, the execution process and update steps of the database transaction adopt a publish-subscribe pattern, specifically as follows: After the database transaction is successfully committed, the transaction service acts as the event publisher and publishes a domain event containing target information. The target information includes the unique project identifier of the target emission reduction project, the transaction ID, the operator identifier, the unique unit identifier of the asset units contained in the target portfolio, the quantity to be traded, and the increment already used. The domain event is broadcast to the event subscribers who subscribe to the domain event, and the event subscribers are the data processing services corresponding to the transaction details table; The event subscriber asynchronously receives the domain events and coordinates updates with the event publisher. These updates include updating the transaction volume, the usage volume, and the status of the asset unit.

[0019] This application achieves asynchronous decoupling between the main transaction process and the data update process through a publish-subscribe pattern. While improving system performance and scalability, it ensures the accuracy and traceability of data updates with the help of a complete event payload.

[0020] Optionally, after asynchronously receiving the domain event, the event subscriber further includes: The domain events are parsed, target information is extracted, and a reconciliation record containing the target information is generated and written into a preset database.

[0021] Optionally, the linked update employs an incremental synchronization algorithm, including: Based on the unique project identifier and proposed transaction quantity of the target emission reduction projects included in the domain event, the transaction details table is incrementally updated; The database is incrementally updated based on the unique unit identifier of the asset unit contained in the domain event and the number of transactions to be completed.

[0022] Optionally, the multiple data tables also include a management table that records the number of registered projects. Before sending the update failure signal, the verification method further includes: verifying the data consistency between the management table, the asset application registration table, the transaction details table and the database to obtain a consistency verification result. If the consistency verification result does not meet expectations, the consistency verification result and the update failure signal are sent to the front end together.

[0023] This application enables event subscribers to parse and extract target information upon receiving domain events, generating reconciliation transaction records and writing them to a pre-defined database, thus establishing an independent reconciliation voucher for each transaction. Unlike the summary data in the transaction details table, the reconciliation transaction record comprehensively records the entire process from event publication to data update at the granularity of a single transaction, including project identifier, transaction ID, operator, asset unit, and transaction quantity. This eliminates the need for repeated comparisons between multiple tables during subsequent reconciliation, auditing, or dispute resolution; the entire transaction can be reconstructed directly from the reconciliation transaction record, improving data traceability and reconciliation efficiency. Furthermore, as an independent persistent record, the reconciliation transaction record allows for data reconstruction even if the transaction details table or asset application registration table is lost or damaged for some reason, providing additional data redundancy for the system.

[0024] The linked update employs an incremental synchronization algorithm. This involves incrementally updating the transaction details table based on unique item identifiers and the number of transactions to be completed within the domain event, and incrementally updating the database based on unique unit identifiers and the number of transactions to be completed, thus reducing write overhead. In high-frequency trading scenarios, if the entire table is rewritten every time, the database I / O pressure and lock contention will increase dramatically. Incremental updates, however, only modify rows relevant to the current transaction. The number of write operations is proportional to the number of transactions, not the total table size, thus significantly ensuring the system's write performance and concurrency capabilities. Incremental updates also reduce the data coverage area, lowering the risk of large-scale data corruption due to write anomalies.

[0025] This application adds a cross-table consistency check before sending the update failure signal. Specifically, it checks whether the data in the management table, asset application registration table, transaction details table, and database is consistent. If the consistency check fails, the check result and the update failure signal are sent to the front end. This solves the problem of partial updates succeeding but overall data inconsistency. For example, the transaction details table may be updated, but the asset application registration table may not. This partially successful state is more dangerous than complete failure. By performing a consistency check before failure, this application can accurately identify which table has data inconsistency and push this information along with the failure signal to the front end. This allows business users or operations personnel to quickly locate the root cause of the problem, improving diagnosability and operational efficiency in abnormal scenarios.

[0026] Optionally, after calculating the second tradable surplus, the method further includes: If the second tradable margin is equal to zero, a no-margin signal is generated; If the second tradable surplus is less than the intended tradable quantity but greater than zero, a specific status code containing the second tradable surplus is generated and sent to the front end to prompt the user to re-initiate the transaction request. The specific status code is used to drive the front end page to display the maximum tradable quantity.

[0027] When the second available trading balance is zero, a no-balance signal is generated, clearly informing the user that the emission reduction project currently has no available trading balance. This allows the user to know the project status immediately and avoids the user repeatedly initiating trading requests when there is no balance. This saves the resource overhead of processing invalid requests and reduces the operational confusion caused by the user being rejected multiple times.

[0028] Secondly, this application provides a verification system for carbon asset trading data, which adopts the following technical solution: A carbon asset trading data verification system includes: a processor and a memory communicatively connected to the processor; The memory is provided with a computer-readable storage medium, and a computer program is stored on the computer-readable storage medium. When the processor processes a computer program stored on the computer-readable storage medium, it implements the method as described in the first aspect.

[0029] In summary, this application includes at least one of the following beneficial technical effects: 1. This application reduces the risk of overtrading in carbon emission reduction projects through a two-level margin verification mechanism. The first level of verification calculates the first tradable margin based on data from multiple tables, quickly screening transaction requests and blocking requests that significantly exceed the margin. This minimizes invalid requests from entering the costly real-time query process, thus significantly reducing system load in high-concurrency scenarios. The second level of verification, after the initial screening, retrieves real-time data from a pre-set database to calculate the second tradable margin, verifying the proposed transaction quantity. This allows for the detection of potential data window discrepancies between the first-level verification and actual transaction execution, such as margin changes caused by concurrent transactions, thereby improving the accuracy of the final transaction results.

[0030] 2. This application achieves data-level decoupling by generating a unique project identifier for each emission reduction project and establishing its association with multiple data tables. The data table structure can evolve independently without affecting the association logic, and the same emission reduction project can flexibly mount different types of data tables. This application only needs to pass in the unique project identifier to automatically route to all associated tables for data retrieval, thereby improving the maintainability and scalability of the system. Attached Figure Description

[0031] Figure 1 This is a flowchart of Embodiment 1 of this application; Figure 2 This is a flowchart of Embodiment 2 of this application. Detailed Implementation

[0032] The following combination Figure 1 and Figure 2 This application will be described in further detail.

[0033] Example 1: This example discloses a method for verifying carbon asset trading data, referring to... Figure 1 The method includes: S11 establishing a connection, S12 obtaining the first tradable surplus, S13 initial comparison, S14 obtaining the second tradable surplus, and S15 comparison again. In this embodiment, a unique project identifier is first generated for each emission reduction project, and a relationship is established between each emission reduction project and multiple data tables based on this identifier. When a transaction request is received from a user for a target emission reduction project, data is retrieved from multiple data tables based on the relationship, and the first tradable surplus is calculated using the data. The first tradable surplus is then initially compared with the proposed transaction quantity. If the initial comparison passes, real-time data stored in the database is retrieved based on the unique project identifier, and the second tradable surplus is calculated using the real-time data. The second tradable surplus is then compared a second time with the proposed transaction quantity. If the second comparison fails, an alarm signal is issued. The execution process of each step in this embodiment is as follows: S11 establishes a unique project identifier for each emission reduction project after registration. This embodiment uses a universally unique identifier format to generate the unique project identifier. For example, the project registration date and emission reduction project number are concatenated to obtain the unique project identifier, reducing identifier conflicts between different emission reduction projects.

[0034] This embodiment pre-defines multiple data tables, including: a management table, an asset application registration table, and a transaction details table. The management table records the registered amount of each emission reduction project (including emission reductions, the number of green electricity certificates, etc.); the asset application registration table records the real-time value of the used amount of each emission reduction project; and the transaction details table records the traded amount of each emission reduction project. In this embodiment, the management table and the transaction details table store static data on the registered amount and traded amount of each emission reduction project. This static data is cached at the front end and, together with the real-time value of the used amount, is used to calculate the first tradable surplus. After each transaction confirmation, the static data in the transaction details table is updated.

[0035] In this embodiment, the unique project identifier of each emission reduction project is used as the primary key to establish cross-table links between multiple data tables (i.e., establish the association relationship between each emission reduction project and multiple data tables), so that all related data of the emission reduction project (i.e., the project registration volume, real-time value of the used volume, and the transaction volume of the target emission reduction project) can be queried across tables through the unique project identifier of the target emission reduction project.

[0036] S12 obtains the first tradable surplus. When a user initiates a transaction request for a target emission reduction project through the front end, the front end extracts the table data of the target emission reduction project from the management table, asset application registration table, and transaction details table based on the association established in S11. These data include the project registration quantity, the real-time value of the used quantity, and the traded quantity.

[0037] The first tradable surplus is calculated as follows: based on the registered amount of the target emission reduction project, the real-time value of the used amount and the traded amount are subtracted in sequence to obtain the first tradable surplus.

[0038] In S13, the front-end extracts the proposed transaction quantity from the transaction request and compares it with the first tradable surplus to obtain the initial comparison result. If the proposed transaction quantity is less than or equal to the first tradable surplus, the initial comparison result is determined to meet expectations. The front-end then submits the transaction request, along with the unique project identifier of the target emission reduction project and the proposed transaction quantity, to the back-end and executes S14 to obtain the second tradable surplus.

[0039] If the quantity to be traded exceeds the first available trading limit, the initial comparison result is determined to be inconsistent with expectations. The front end directly returns a trade rejection signal to the user, and the trading process is terminated without interaction with the back end.

[0040] S14 obtains the second tradable surplus. After receiving the transaction request, unique project identifier, and proposed transaction quantity submitted by the front end, the back end accesses the preset database using the unique project identifier as an index. In this embodiment, the preset database stores real-time data with the same data type as the table. The difference between storing data in multiple data tables and storing data in the database is that the transaction volume stored in the database is dynamic data. That is, the data stored in the database includes: project registration quantity, real-time value of transaction volume, and real-time value of usage.

[0041] The backend retrieves real-time data from a preset database, and the calculation method is the same as that for the first tradable surplus. In this embodiment, the real-time data is used to calculate the second tradable surplus.

[0042] The second tradable surplus is calculated as follows: extract the real-time values ​​of project registration, usage, and transaction from the preset database, and subtract the real-time values ​​of usage and transaction from the preset database in turn using the project registration stored in the preset database as the base to obtain the second tradable surplus.

[0043] In other embodiments, after obtaining the second tradable surplus, the verification method further includes: If the second tradable surplus is zero, a zero surplus signal is generated and sent to the front end to inform the user that there are currently no tradable carbon assets.

[0044] If the second tradable reserve is less than the intended transaction quantity but greater than zero, a specific status code containing the second tradable reserve is generated and sent to the front end, prompting the user to re-initiate the transaction request. This specific status code drives the front end page to display the maximum available quantity (which is the second tradable reserve), allowing the user to intuitively understand the current maximum tradable quantity. For example, a specific business code (such as REMAIN_INSUFFICIENT) can be used to identify scenarios where the second tradable reserve is insufficient. Simultaneously, an additional field in the response object can be set to directly input the specific value of the second tradable reserve, and this response object can be returned to the front end via an interface.

[0045] After receiving the response, the front end first reads the status code field to identify that the current situation is an insufficient reserve rather than a real transaction failure. Then, it directly retrieves the value of the field for filling in the second tradable reserve from the response object and fills the second tradable reserve into the maximum sellable quantity display position on the front end page.

[0046] S15 compares again. The backend compares the proposed transaction quantity with the second tradable reserve. If the proposed transaction quantity is less than or equal to the second tradable reserve, the second comparison result is determined to meet expectations, and the transaction enters the subsequent confirmation process (i.e., whether to confirm the transaction). If the proposed transaction quantity is greater than the second tradable reserve, the second comparison result is determined to not meet expectations, and an alarm signal is issued. The alarm signal includes information such as the unique project identifier of the target emission reduction project, the proposed transaction quantity, and the second tradable reserve. The alarm signal is pushed to the user's front end to indicate that there is an over-limit risk in the transaction.

[0047] This embodiment employs a verification method that uses a front-end to calculate the first tradable surplus based on static data and real-time values ​​of used quantities and quickly provides feedback to the user, while the back-end calculates the second tradable surplus based on real-time data and performs precise verification. This method not only enhances the user interaction experience but also improves the security and consistency of transaction data.

[0048] Example 2: Refer to Figure 2 The difference between this embodiment and Embodiment 1 is that the verification method further includes: S21 splitting involves dividing the project registration volume of each emission reduction project stored in the database into multiple asset units based on the preset attribute dimensions of each emission reduction project. Each asset unit is then configured with a dynamic margin field and a unique unit identifier. The attribute dimensions include: type, source, port area, etc.

[0049] Taking a certain emission reduction project with a registered volume of 10,000 tons as an example, this embodiment divides it into multiple asset units according to the attribute dimension. Each asset unit is configured with a unique unit identifier and a dynamic reserve field. The dynamic reserve field is used to represent the tradable reserve of the asset unit in real time. For example, the asset unit with the unique unit identifier 001, the type is CCER, the source is shore power emission reduction, and the port area is the first port area, and its initial value of the dynamic reserve field is 4,000 tons; the asset unit with the unique unit identifier 002, the type is CCER, the source is photovoltaic power generation, and the port area is the second port area, and its initial value of the dynamic reserve field is 6,000 tons.

[0050] S22 sets the strategy. In this embodiment, the asset consumption strategy for each emission reduction project is set according to the dynamic margin field and unique unit identifier of each asset unit. The asset consumption strategy defines the consumption rules of the asset unit, such as prioritizing the consumption of the asset unit with the smallest dynamic margin field, or prioritizing the consumption of asset units from a certain source, or prioritizing the consumption of asset units whose tradable margin can meet the planned consumption quantity, etc.

[0051] In other embodiments, the asset consumption strategy can also be set according to requirements.

[0052] S23 pre-occupancy processing: After the second comparison results meet expectations, the used increment of the target emission reduction project is obtained. The backend selects asset units from the asset unit set of the target emission reduction project according to the consumption rules, based on the asset consumption strategy, until the cumulative value of the tradable surplus of the selected asset units is not less than the sum of the intended tradable quantity and the used increment. All selected asset units are then marked as the target combination.

[0053] If the tradable margin of a certain asset unit is greater than the sum of the quantity to be traded and the increment already used, then the target portfolio will only include that asset unit.

[0054] Taking the asset consumption strategy of prioritizing the consumption of the asset unit with the least remaining balance as an example, when the used increment is 2,000 tons and the proposed transaction quantity in the transaction request is 3,000 tons, according to the asset consumption strategy set in this embodiment, the asset unit with unique unit identifier 001 (with a remaining balance of 4,000 tons) and the asset unit with unique unit identifier 002 (from which 1,000 tons are deducted) are selected as the target combination.

[0055] The backend performs pre-occupancy processing on the tradable surplus in each asset unit of the target portfolio. Specifically, it pre-deducts the dynamic surplus field of each asset unit and records the pre-occupancy amount to obtain the pre-occupancy processing result. The pre-occupancy processing result includes: the unique project identifier of the target emission reduction project, the unique unit identifier of each asset unit in the target portfolio, the pre-occupancy amount (the value of which is equal to the sum of the proposed transaction quantity and the used increment), the proposed transaction quantity, the used increment, and the lock timestamp, etc.

[0056] In this embodiment, the pre-deduction is a non-persistent operation, that is, temporarily locking the dynamic balance field (or part of the dynamic balance field) of the asset unit in the target portfolio. If the dynamic balance field of an asset unit is temporarily locked, the remaining tradable balance of the asset unit can still participate in other transaction processes.

[0057] After pre-deducting the dynamic balance field in the target portfolio, a countdown begins. Before the transaction is confirmed, if other transaction requests exist, they cannot occupy the pre-deducted dynamic balance field of the asset units included in this transaction before the countdown ends. This improves the reliability of the transaction and reduces the risk of overselling in high-concurrency transaction scenarios. The countdown duration is a preset duration, which can be a pre-set value, such as 10 minutes, or it can be set based on the average duration of historical transactions.

[0058] If the transaction is not confirmed within the preset time period, this embodiment will release the pre-deducted dynamic balance field after the preset time period. After releasing the pre-deducted dynamic balance field, a stop pre-occupancy signal will be sent to the front end.

[0059] S24 Submits and executes the database transaction. After the user performs a transaction confirmation operation on the front end, the database transaction is submitted to the back end. The database transaction is an atomic operation and includes the following sub-operations: Sub-operation 1: Based on the pre-occupancy processing results, convert the pre-occupancy amount of each asset unit in the database into the traded amount or the used amount. Specifically, convert the planned traded quantity into the traded quantity and the used increment into the used quantity.

[0060] Sub-operation 2: Update the dynamic balance field of each asset unit according to the pre-occupancy amount. Specifically, subtract the pre-deducted amount from the value before the update to obtain the updated dynamic balance field.

[0061] Sub-operation 3: Update the lock timestamp of the dynamic balance field of each asset unit to the current timestamp to identify the latest lock status of the asset unit and reduce the risk of data inconsistency caused by concurrent transactions.

[0062] S25 update includes S251 data update, S252 status update and S253 verification update result.

[0063] S251 Data Update: After the database transaction is successfully committed, the quantity to be traded is written to the transaction details table to update the traded quantity in the transaction details table. The updated traded quantity in the transaction details table is equal to the sum of the traded quantity before the update and the quantity to be traded.

[0064] Similarly, update the used increments of the target emission reduction projects to the asset application register.

[0065] Based on the updated transaction volume in the transaction details table and the used volume in the asset application registration table, the quantity update result is output, which includes two cases: successful quantity update and failed quantity update. If the intended transaction quantity is successfully written into the transaction details table and the used increment is successfully updated to the asset application registration table, the quantity update is considered successful; otherwise, the quantity update is considered failed.

[0066] In S252 status update, the backend checks the dynamic reserve field of each asset unit one by one. If the dynamic reserve field of an asset unit is equal to zero after the update, the status field of the asset unit is updated to "used up", and the status update result is output. The status update result includes two cases: status update success and status update failure.

[0067] A successful status update means that the status field of an asset unit whose dynamic reserve field is equal to zero after the update is successfully updated to "used up". A failed status update means that the status field of an asset unit whose dynamic reserve field is equal to zero after the update is not successfully updated to "used up".

[0068] S253 verifies the update results, and the backend verifies the quantity update results and the status update results.

[0069] If either result is a failure (i.e., the quantity update result is a quantity update failure or the status update result is a status update failure), the data rollback mechanism is triggered, restoring all relevant data in the database to the state before the database transaction was executed, and generating an update failure signal. After the countdown ends, the dynamic balance field of the pre-deducted asset unit is released.

[0070] After restoring all relevant data in the database to the state before the database transaction was executed, this step also includes: performing consistency verification on the data between the management table, asset application registration table, transaction details table, and the database to obtain the consistency verification result. The consistency verification specifically includes: using the unique project identifier of the target emission reduction project as a benchmark, verifying whether the result of subtracting the real-time value of the used amount in the asset application registration table from the project registration amount in the management table, and then subtracting the transaction amount in the transaction details table, is equal to the sum of the dynamic balance fields of each asset unit in the database (in this step, the dynamic balance fields of each asset unit in the database include the pre-deducted portion).

[0071] If the result is equal to the sum of the dynamic balance fields of each asset unit, the consistency check is considered passed and the consistency check result is as expected. If the result is not equal to the sum of the dynamic balance fields of each asset unit, the consistency check is considered failed and the consistency check result is as expected.

[0072] If the consistency check result does not meet expectations, the consistency check result and the update failure signal will be sent to the front end together to help the operation and maintenance personnel locate the specific link of the data anomaly.

[0073] Example 3: The difference between this example and Example 2 is that, in this example, the execution process and update steps of the database transaction adopt a publish-subscribe pattern, specifically as follows: After the database transaction is successfully committed, the backend transaction service acts as the event publisher and publishes a domain event containing a unique project identifier of the target emission reduction project, transaction ID, operator identifier, unique unit identifier of the asset units included in the target portfolio, the quantity to be traded, and the increments used. The domain event is broadcast to the event subscribers who subscribe to the domain event, and the event subscribers are the data processing services corresponding to the transaction details table; The event subscriber asynchronously receives the domain events and coordinates updates with the event publisher. These updates include updating the transaction volume, the usage volume, and the status of the asset unit.

[0074] In this embodiment, the linked update includes the following two steps: The event publisher updates the status of each asset unit in the database (that is, updates the status field of the asset unit whose dynamic balance field is zero to "used up"), updates the real-time value of the traded amount and the real-time value of the used amount in the database, and updates the lock timestamp of each asset unit, etc. After receiving a domain event, the event subscriber will update the number of transactions to the transaction details table.

[0075] The linked update adopts an incremental synchronization algorithm, including: Once each event subscriber receives a domain event, it deserializes the event. Core fields for location and calculation are extracted from the event body, including the unique project identifier of the target emission reduction project, the unique unit identifier of the asset unit, and the quantity to be traded. Simultaneously, anchor data for concurrency control, namely the timestamp when the transaction occurred, is extracted. Before performing a database write operation, a check is performed using the transaction ID as an idempotent key. The domain event is verified by querying local cache (such as Redis) and database records to confirm whether it has already been successfully processed. If it has been processed, the current message is discarded to prevent duplicate deductions. If not processed, the event subscriber locates the data row that needs to be updated in the database based on the unique unit identifier of the parsed asset unit. An atomic incremental update instruction is constructed. This instruction not only includes the accumulation operation of the proposed transaction quantity, but also incorporates a strict optimistic locking condition into the update conditions: that is, the passed-in lock timestamp must be strictly equal to (or greater than) the most recent lock timestamp in the database; The update command is submitted to the database for execution. During execution, the database performs a condition comparison. If the optimistic locking conditions are met, the update will be posted to disk and the lock timestamp will be updated. If the conditions are not met (indicating that an updated transaction event has already been posted to disk), the update operation will be rejected. Event subscribers obtain the actual number of rows affected from the database, using this as the basis for state transitions. If the number of affected rows is 1, the incremental update is successful, and the event in that domain is marked as traded. If the number of affected rows is 0, it indicates that network latency caused message out-of-order delivery, and the old data attempting to overwrite the new data was intercepted. In this case, the event subscriber should discard the expired event or move it to a dead-letter queue for manual intervention to improve data consistency.

[0076] After asynchronously receiving the domain event, the event subscriber also includes: The domain event is parsed, the target information is extracted, and the backend generates a reconciliation record containing the complete transaction path based on the target information, and writes the reconciliation record into a preset database.

[0077] Example 4: This example discloses a verification system for carbon asset trading data. The system includes a processor and a memory communicatively connected to the processor. The memory is provided with a computer-readable storage medium, and a computer program is stored on the computer-readable storage medium. When the processor processes the computer program stored on the computer-readable storage medium, it implements the method for verifying carbon asset trading data.

[0078] The above are all preferred embodiments of this application, and are not intended to limit the scope of protection of this application. Therefore, all equivalent changes made in accordance with the structure, shape and principle of this application should be covered within the scope of protection of this application.

Claims

1. A method for verifying carbon asset trading data, characterized in that, include: Generate a unique project identifier for each emission reduction project, and establish the association between each emission reduction project and multiple data tables based on the unique project identifier; In response to a transaction request for a target emission reduction project, data is retrieved from the multiple data tables based on the correlation relationship, and a first tradable surplus is calculated based on the data in the tables; Obtain the proposed transaction quantity from the transaction request, compare the proposed transaction quantity with the first available tradable reserve in real time, and obtain the initial comparison result; When the initial comparison result meets expectations, real-time data is retrieved from the preset database based on the unique project identifier. The second tradable surplus is calculated based on the real-time data. The proposed tradable quantity is compared with the second tradable surplus to obtain the second comparison result. When the second comparison result does not meet expectations, an alarm signal is issued.

2. The method for verifying carbon asset trading data according to claim 1, characterized in that, The verification method further includes: Based on preset attribute dimensions, the project registration volume of each emission reduction project is divided into multiple asset units, and a dynamic reserve field and a unique unit identifier are configured for each asset unit. The asset consumption strategy is set according to the dynamic reserve field and unique unit identifier of each asset unit. The dynamic reserve field is used to represent the tradable reserve of the asset unit.

3. The method for verifying carbon asset trading data according to claim 2, characterized in that, The database stores the lock timestamps for each dynamic margin field. When the second comparison result meets expectations, the verification method further includes: Obtain the used increment of the target emission reduction project, and determine the target combination that meets the proposed transaction quantity and the used increment from multiple asset units corresponding to the target emission reduction project according to the asset consumption strategy. Perform pre-occupancy processing on the target combination to obtain the pre-occupancy processing result. After the current transaction is confirmed, a database transaction is submitted and executed. The database transaction includes: based on the pre-occupancy processing result, converting the pre-occupancy amount of each asset unit into the traded amount or the used amount, updating the dynamic balance field of each asset unit, and updating the lock timestamp to the current timestamp.

4. The method for verifying carbon asset trading data according to claim 3, characterized in that, The multiple data tables include an asset application registration table and a transaction details table. The verification method also includes an update step, specifically: Update the proposed transaction quantity to the transaction details table, update the used increment to the asset application registration table, and output the quantity update result, which includes quantity update success and quantity update failure. If the dynamic balance field of an asset unit is zero, the status of the asset unit with the zero dynamic balance field is updated to "used up", and the status update result is output. The status update result includes status update success and status update failure. If the quantity update result is a quantity update failure or the status update result is a status update failure, the data in the database will be rolled back to the state before the database transaction was executed, and an update failure signal will be sent.

5. The method for verifying carbon asset trading data according to claim 4, characterized in that, The execution process and update steps of the database transaction adopt a publish-subscribe pattern, specifically as follows: After the database transaction is successfully committed, the transaction service acts as the event publisher and publishes a domain event containing target information. The target information includes the unique project identifier of the target emission reduction project, the transaction ID, the operator identifier, the unique unit identifier of the asset units contained in the target portfolio, the quantity to be traded, and the increment already used. The domain event is broadcast to the event subscribers who subscribe to the domain event, and the event subscribers are the data processing services corresponding to the transaction details table; The event subscriber asynchronously receives the domain events and coordinates updates with the event publisher. These updates include updating the transaction volume, the usage volume, and the status of the asset unit.

6. The method for verifying carbon asset trading data according to claim 5, characterized in that, After asynchronously receiving the domain event, the event subscriber also includes: The domain events are parsed, target information is extracted, and a reconciliation record containing the target information is generated and written into a preset database.

7. The method for verifying carbon asset trading data according to claim 5, characterized in that, The linked update adopts an incremental synchronization algorithm, including: Based on the unique project identifier and proposed transaction quantity of the target emission reduction projects included in the domain event, the transaction details table is incrementally updated; The database is incrementally updated based on the unique unit identifier of the asset unit contained in the domain event and the number of transactions to be completed.

8. The method for verifying carbon asset trading data according to claim 4, characterized in that, The multiple data tables also include a management table that records the number of registered projects. Before sending the update failure signal, the verification method also includes: verifying the data consistency between the management table, the asset application registration table, the transaction details table and the database, obtaining a consistency verification result, and sending the consistency verification result and the update failure signal to the front end together when the consistency verification result does not meet expectations.

9. The method for verifying carbon asset trading data according to claim 1, characterized in that, After calculating the second tradable margin, the following is also included: If the second tradable margin is equal to zero, a no-margin signal is generated; If the second tradable surplus is less than the intended tradable quantity but greater than zero, a specific status code containing the second tradable surplus is generated and sent to the front end to prompt the user to re-initiate the transaction request. The specific status code is used to drive the front end page to display the maximum tradable quantity.

10. A verification system for carbon asset trading data, characterized in that, include: A processor, and a memory communicatively connected to the processor; The memory is provided with a computer-readable storage medium, and a computer program is stored on the computer-readable storage medium. When the processor processes a computer program stored on the computer-readable storage medium, it implements the method as described in any one of claims 1-9.

Images