Verification data provision device, verification method, and program

Abstract

This invention provides a verification data provision device, verification method, and program that allow a third-party verification device to reconstruct the calculation rules and update process of numerical calculations performed on the server side, and to verify their consistency with the cryptographic commit root. [Solution] The state value update core 190 includes a profile management unit 110 that maintains a fixed version of a verification profile including interval rules for the index axis, numerical representation format, rounding direction, algorithm identifiers for approximate and exact procedures, threshold values ​​for indicators used for switching determination, and logical join rules; an order determination engine 120 that determines the entire order of event columns based on the verification profile; a constant-time update / evaluation means 130 that evaluates metric values ​​in a constant time from the saved state for each aggregation window; and a minimum term logger 160 that records switching information between approximate and exact procedures as minimum terms. The public verification subsystem 195 includes a commit root generator 150 and a public verification API 180.

Description

Technical Field

[0003] ,

[0005] , , , , , , , , , , , , , , , ,

[0004] ,

[0001] The present invention relates to the management and verification of state values that change depending on time or order. In particular, for numerical arithmetic processing performed on the server side, a verification data providing device, a verification method, and a program are provided that enable a third-party verification device to reconstruct the arithmetic rules and update process and confirm the consistency with a cryptographic commitment root.

Background Art

[0002] Conventionally, in a method of providing only transaction history, event logs, and the final balance to the outside, due to implementation-dependent differences such as rounding rules, end-point processing rules, arrival order rules, etc., external verifiers cannot reproduce the same calculation procedure, and there is a risk that the calculation results inside the server and the recalculation results on the verification side do not match. Also, when state values are sensitive to time and order, such as time-dependent depreciating currencies or points, even a slight difference in rules can cause recalculation inconsistencies and double counting, resulting in an increase in the cost of auditing and dispute resolution.

Prior Art Documents

Patent Documents

[0003] [Patent Document 1] US20190259007A1, Lamontagne, 2019, Date of reference November 11, 2025

Non-Patent Documents

[0004] [Non-Patent Document 1] Freicoin official document, Internet published material (https: / / freico.in / ), 2012, Date of reference November 11, 2025

Summary of the Invention

Problems to be Solved by the Invention

[0006] The present invention has been made in view of these problems, and aims to provide a verification dataset that combines a set of calculation rules for numerical calculations used by a server device, minimal term data (log records corresponding to minimal term logs as defined in this application) including a summary of the state before and after the application of each event and event information, and the cryptographic commit root of the state, thereby providing a framework in which an external verification device can recalculate the update process of the state value based solely on the verification dataset and compare it with the commit root on the server side. [Effects of the Invention]

[0007] According to the present invention, The profile management unit manages "verification profile identifiers" that bundle rounding rules, endpoint rules, ordering rules, etc. The generation unit generates "minimal term data" which includes state summary information before and after the application of each event and event information, and a "cryptographic commit root" which represents the definitive state. The interface unit provides an external "verification dataset" containing profile_id+minterm+commit_root, and the client-side verification device uses this to recalculate and compare it with commit_root. If necessary, allowable error and calculation method switching (approx / strict) should also be included in profile_id and minterm, allowing for re-verification even if switching occurs. By chaining state hashes for each time interval / window, consistency verification and non-inclusion proofs spanning multiple time intervals become possible. This provides a framework that allows external verifiers to accurately reproduce the calculation rules (rounding, endpoints, order, etc.) used internally by the server, and easily verify that the same final state is reached from the logs and state hash / commit_root. [Brief explanation of the drawing]

[0008] [Figure 1] The overall structure (core lines) of the present invention is shown.

[0009] [Figure 2] The processing flow (1 window) of the present invention is shown.

[0010] [Figure 3] The data structure of the present invention (storage state and minimum term) is shown.

[0011] [Figure 4] This document shows the correspondence between the proof engine and API of the present invention.

[0012] [Figure 5] An example of the application of the present invention (simple interest approximation → exact switching) is shown. [Modes for carrying out the invention]

[0013] [1] Overview of the structure Although not shown in the figures, the verification data provision device of this embodiment (hereinafter also simply referred to as the "server device") includes a profile management unit, a generation unit, and an interface unit. The server device updates internal state values ​​based on an event sequence input from an external source, records the update process in a format that can be reproduced by a third party, and provides it to the outside as a verification dataset.

[0014] The profile management unit manages a verification profile identifier (profile_id) that identifies a set of calculation rules in numerical calculations, including at least rounding rules, endpoint processing rules, and ordering rules. Here, the ordering rules include event comparison keys and tie-breaking rules, and are used to determine the application order of multiple events arriving at the same timestamp or within the same window.

[0015] The generation unit executes an update process of the state value based on the application order and application time of events input from the outside according to a set of operation rules specified by the profile management unit. At the same time, for each event, it generates minterm data including event identification information related to the event, state hash information summarizing the state values before and after event application, and information related to the operation rules applied to the event. Also, the generation unit calculates a cryptographic commit root representing the finalized state at the end of a predetermined time interval or window. A Merkle root may be used as an example of the cryptographic commit root.

[0016] The interface unit outputs a verification dataset including at least a verification profile identifier, minterm data, and a cryptographic commit root in response to a request from an external verification device or the like. The verification dataset may be output as a single response data, or as a plurality of data groups that mutually associate profile information, minterm data, and the commit root. Also, the communication method and data serialization method used by the interface unit are implementation options and do not limit the present invention. For example, the interface unit may provide the verification dataset by means of a request-response type API based on HTTP or other communication forms, and the representation format of the verification dataset may be either text format or binary format. However, regardless of the method adopted, the verification dataset is configured to include the necessary information so that the receiving side can identify a set of operation rules based on the verification profile identifier, perform recalculation based on the minterm data, and verify the consistency by comparing with the cryptographic commit root.

[0017] [2] An embodiment of the verification profile The verification profile identifier (profile_id) is an ID for uniquely identifying a set of operation rules used by the server device to update the state value, and can be taken as an example associated with at least the following information. That is, (a) Rounding modes in numerical calculations (e.g., truncation, rounding, etc.), (b) Endpoint handling rules that define how to handle the endpoints of time intervals (e.g., starting endpoint is included as a half-open interval and ending endpoint is not included, etc.), (c) Ordering rules that define the comparison keys and tie-breaking chains for event sequences, (d) If necessary, tolerance ranges and switching rules to a high-precision calculation method used when exceeding the tolerance range, (e) Identification information regarding the hash family and serialization method used for calculating cryptographic commitment roots, and so on. The switching rules according to claim 2 correspond to switch_condition and error_bound in P19.

[0018] As a result, the verification device can reproduce each of the rounding, endpoint, and ordering rules in its own environment based on the profile_id obtained from the server device. As a result, the verification device can recalculate the update process of the state value in the same procedure as the server device using the same event sequence and minterm data.

[0019] [3] An embodiment of minterm data Minterm data (minterm) contains the minimum information necessary for the application of each event and is a log record that enables recalculation and consistency verification by a third party. As one embodiment, minterm can include at least the following fields. (1) Verification profile identifier (profile_id) used for the processing of the event, (2) Event identifier (idempotency_key, etc.) that uniquely identifies the event, (3) Identifier indicating the time interval or aggregation window to which the event belongs, (4) State hash information (state_hash_before, etc.) summarizing the state value before the application of the event, (5) State hash information (state_hash_after, etc.) summarizing the state value after the application of the event, (6) Hash information from the previous interval (prev_commit_root, etc.) to indicate chain consistency of the state hash, (7) Identification information that identifies the ordering rules or calculation methods applied to the event, if necessary. And so on.

[0020] If the configuration is such that the calculation method is switched when the tolerance range is exceeded, minterm can include switching range information indicating the time interval or sequence range to which the switch is applied, and identification information (information equivalent to from_algo_id and to_algo_id) that identifies the calculation method before and after the switch. With this configuration, the verification device can reproduce the calculation method according to the switching information recorded in minterm and track the same calculation path as the server device.

[0021] [4] Validation dataset and validation process The interface unit of the server device, upon receiving a request from an external source that includes a specific time interval or window identifier, generates and responds with a verification dataset corresponding to that time interval. As an example, the verification dataset may include the following elements: (a) State hash information summarizing the state value at the start of the time interval, (b) A list of minimum term data corresponding to events within the time interval, (c) The cryptographic commit root at the end of the time interval, (d) Verification profile identifier identified by the profile management unit, And so on.

[0022] The verification device first identifies a set of calculation rules associated with a verification profile identifier based on the verification dataset obtained from the server device. Next, using the state hash information as the initial state, it sequentially applies the events included in the list of minimum term data and recalculates the state value update process. After that, it recalculates the cryptographic commit root from the obtained final state and compares it with the commit root included in the verification dataset to determine whether it is consistent with the calculation result of the server device.

[0023] Furthermore, the verification device can confirm the consistency of state transitions across multiple consecutive time intervals by verifying the chain relationship between state hash information and cryptographic commit roots obtained for those intervals. It is also possible to verify that a specific event is not included in a deterministic set by obtaining non-inclusion proof data from the server device by specifying an event identifier and comparing it with the cryptographic commit root. A deterministic set refers to the objects that commit_root commits (e.g., a set of event identifiers, or a set of event identifiers and associated data).

[0024] [Drawing description] Figure 1 Overall structure (core lines) This figure shows the overall configuration of the present invention. As an example of a backend implementation in one embodiment of this application, it consists of a verification profile registry, a sequence determination engine, a constant time update / evaluation means, an idempotency determination means, a commit root generator, a minimum term logger, a switching control (switch_condition) / high-precision switch, and a public verification API. 110: Profile Management Department (Verification Profile Registry). 120: Sequencing engine. 130: Constant time update / evaluation method. 140: Idempotent determinant. 150: Committed root generator. 160: Minterm logger. 170: Error monitoring and high-precision switch. 180: Public verification API. 190: State value update core. 195: Public verification subsystem.

[0025] Figure 2 Processing flow (1 window) This figure shows an example of a processing flow in one embodiment of the present invention, illustrating the time series of event capture → lock ID assignment → total ordering → idempotency application → O(1) evaluation → error determination → switching → minimum term recording → root generation. The core of this approach lies in determinism of identical inputs to identical outputs based on validation profiles, minimization of saved states, and unique convergence through sequential application of lock IDs. 210: Aggregation window. 220: Event capture. 240: Strict procedure switch. 250: Recalculate value. 255: Status confirmed. 260: Window end.

[0026] Figure 3 Data structure (storage state and minimum term) This figure shows the data structure. As an example of the data structure in one embodiment of this application, and as an example of future extension, the minimum term includes { profile_id, idempotency_key, window_id, order_rule_id, prev_commit_root, state_hash_before / after} as required. Optionally, { account_id, asset_id, from_algo_id, to_algo_id, switch_range, effective_error_bound} may also be held (an example for easier verification and reference). Note that per account and asset are examples of one embodiment. All IDs are to hold only numerical IDs, and the policy is to not record the name. The key of the State Store is (account_id, asset_id), and B_w·t_w·HWM corresponds to snapshot_rule_id in the API section (ID=0 is undefined, higher ranges are reserved). 310: Condition of preservation. 320: Minimum term. The policy is to store only numerical IDs for profile_id, etc., and not record the name. See the API definition section (snapshot_rule_id) for details.

[0027] Figure 4 Correspondence between proof engines and APIs This diagram shows the input and output of non-inclusion, consistency, and differences in APIs ( / windows.list, / minterms.get, / proofs.non_membership, / proofs.consistency, / diff). The zk-related endpoints are an example of future extensions. 410: Proof device (SMT / cumulative root). 420: Input (commit_root, idempotency_key, window range). 430: Output (proof, suspect_ranges).

[0028] Figure 5. Application example (Simple interest approximation → Strict switching) This figure visualizes boundaries and transitions using a miniature example of real data (n=floor((t-t0) / P), step difference in R(t), and highlighting of transition sections). 510: Switching to an approximate version.

Claims

1. A verification data providing device that manages state values ​​that change depending on time or order, A profile management unit that stores a verification profile identifier (profile_id) that identifies a set of calculation rules, including at least rounding rules, endpoint processing rules, and sequence determination rules, in numerical calculations, A generation unit that, based on an event input from an external source, performs a status value update process according to the application order and timing of the event, and generates minterm data including event information related to the update process and summary information of at least one of the status values ​​before or after the update, and a cryptographic commit root representing the final state after the update process. The generation unit generates the minimum term data and the cryptographic commit root in a format that allows recalculation and verification by an external verification device, An interface unit that outputs a verification dataset including at least the verification profile identifier, the minimum term data, and the cryptographic commit root in response to an external request, Equipped with, The verification dataset is configured such that the recipient can verify the integrity by applying the event information contained in the minimum term data to the set of calculation rules identified based on the verification profile identifier, recalculating at least part or all of the state value update process, and comparing the cryptographic commit root calculated based on the recalculation result with the cryptographic commit root contained in the verification dataset. A verification data provision device characterized by, A verification device that acquires the verification dataset, identifies the set of calculation rules based on the verification profile identifier, recalculates the state value update process using the minimum term data according to the set of calculation rules, and determines consistency with the cryptographic commit root based on the recalculation result, A verification system equipped with the following features.

2. A verification system according to claim 1, The aforementioned verification profile identifier is an identifier that further specifies the tolerance range and the rule for switching to the calculation method applied when the tolerance range is exceeded. The minimum term data includes, in the event that a switch in the calculation method actually occurs, switch range information indicating the time interval or sequence range to which the switch is applied, and calculation method identification information identifying the calculation method before and after the switch. A verification system characterized by the following:

3. A verification system according to claim 1, When the interface unit receives a specification of a specific time interval or window identifier, The state hash information summarizing the state value at the start of the interval, the list of minimum term data corresponding to events belonging to the interval, and the cryptographic commit root at the end of the interval are output together with the verification profile identifier as a single response data or a group of related data. The state hash information is configured such that the chain consistency between the cryptographic commit roots can be definitively verified over multiple consecutive time intervals. A verification system characterized by the following:

4. A verification system according to claim 1, The aforementioned verification data provision device is a server device, The verification device is a verification device that verifies the validity of status values ​​based on data acquired from the server device, An acquisition unit acquires a verification dataset containing a verification profile identifier, minimum term data, and cryptographic commit root from the server device which serves as the verification data provision device. A rule identification unit identifies a set of arithmetic rules, including at least rounding rules, endpoint processing rules, and sequence determination rules, based on the acquired verification profile identifier. A verification execution unit that recalculates the update process of the state value using the minimum term data according to the set of calculation rules, and determines whether or not it is consistent with the cryptographic commit root based on the obtained recalculation result, To be prepared A verification system characterized by the following:

5. A program for causing a computer to function as the verification device in the verification system described in claim 4.

6. A verification method performed by a verification data providing device and a verification device for state values ​​that change depending on time or order, The verification data providing device includes the step of storing a verification profile identifier that identifies a set of calculation rules, including at least rounding rules, endpoint processing rules, and sequence determination rules in numerical calculations, in a fixed format. The verification data providing device performs a state value update process based on an event input from an external source, according to the application order and timing of the event, and generates minimal term data including event information related to the update process, summary information of at least one of the state values ​​before or after the update, and a cryptographic commit root representing the final state after the update process. The verification data providing device outputs a verification dataset in response to an external request, which includes at least the verification profile identifier, the minimum term data, and the cryptographic commit root. The verification device includes the steps of acquiring the verification dataset, The verification device includes the step of identifying the set of calculation rules based on the acquired verification profile identifier, The verification device performs the steps of recalculating the update process of the state value using the minimum term data in accordance with the set of calculation rules, The verification device performs the step of determining consistency with the cryptographic commit root based on the recalculation result, To be prepared A verification method characterized by the following.

7. The verification method according to claim 6, The aforementioned verification data provision device is a server device, The verification device is a verification device that verifies the validity of status values ​​based on data acquired from the server device, In the step where the verification device acquires the verification dataset, it acquires the verification dataset, which includes a verification profile identifier, minimum term data, and cryptographic commit root, from the server device acting as the verification data provider. In the step where the verification device identifies the set of calculation rules, it identifies the set of calculation rules, which includes at least rounding rules, endpoint processing rules, and sequence determination rules, based on the acquired verification profile identifier. In the step where the verification device recalculates the update process for the state value, it recalculates the update process for the state value using the minimum term data in accordance with the set of calculation rules, In the step where the verification device determines the consistency, it determines whether or not the result is consistent with the cryptographic commit root based on the obtained recalculation result. A verification method characterized by the following.

Images