Time series data storage method and device, block chain system and storage medium

Abstract

The embodiment of the invention provides a time series data storage method and device, a block chain system and a storage medium, and belongs to the technical field of data storage. The method comprises the following steps: acquiring time sequence data, and determining a current time sequence characteristic of the time sequence data based on a preset window configuration parameter; time sequence proof information and a window check value of the current time window are constructed based on the current time sequence characteristics, the window check value of the previous time window and the window configuration parameters; generating a current window anchoring request according to the time sequence proof information, the window check values of the current time window and the previous time window, the current time sequence characteristics and the window configuration parameters; sending the current window anchoring request to the block chain, and receiving a processing result returned by the block chain after verification is passed; and if the processing result indicates that anchoring succeeds, storing the time sequence data to an off-chain storage medium. The time characteristic of the time sequence data can be sensed, and the exposure risk of the time sequence data is reduced.

Description

Technical Field

[0001] This application relates to the field of data storage technology, and in particular to a time-series data storage method and apparatus, a blockchain system and storage medium. Background Technology

[0002] Traditional time-series data storage methods are often centralized, such as centralized relational databases and time-series databases. These are typically operated by a single institution, focusing on index design, compression encoding, and query optimization to support high-frequency writes and complex queries. However, they struggle to provide publicly verifiable and traceable tamper-proof guarantees in multi-party environments, and cannot solve the cross-institutional trust issue regarding the integrity of time-series data. Among related technologies, blockchain-based data storage technology has been applied to time-series data storage. This involves storing time-series data in external databases or decentralized storage networks, recording only hash values, pointers, or a small amount of metadata-based data digests on the blockchain to achieve tamper-proof indexing and access control. However, due to the inherent limitations of blockchain, massive amounts of multi-source, heterogeneous time-series data cannot be directly stored on the chain. Storing only data digests on the chain prevents the blockchain from directly sensing the temporal characteristics of the time-series data. Timestamp-bound data may contain sensitive information, increasing the risk of exposure. Therefore, how to sense the temporal characteristics of time-series data and reduce its exposure risk has become a pressing technical problem. Summary of the Invention

[0003] The main objective of this application is to propose a time-series data storage method and apparatus, a blockchain system and storage medium, which aims to perceive the temporal characteristics of time-series data and reduce the risk of exposure of time-series data.

[0004] To achieve the above objectives, a first aspect of this application proposes a time-series data storage method, wherein the method is executed by a data node in a blockchain system, the data node being communicatively connected to the blockchain, and the method includes: Acquire time-series data and determine the current time-series characteristics of the time-series data based on preset window configuration parameters; Based on the current time series characteristics, the window verification value of the previous time window, and the window configuration parameters, the time series proof information of the current time window is constructed, and the window verification value of the current time window is determined; wherein, the previous time window is the time window preceding the current time window; The current window anchoring request is generated based on the time series proof information, the window verification value of the current time window, the window verification value of the previous time window, the current time series characteristics, and the window configuration parameters. The current window anchoring request is sent to the blockchain, so that the blockchain verifies the current window anchoring request and receives the processing result returned by the blockchain after the verification is successful. If the processing result indicates successful anchoring, the time-series data is stored in the off-chain storage medium.

[0005] In some embodiments, constructing the timing proof information of the current time window based on the current timing features, the window check value of the previous time window, and the window configuration parameters includes: The current time-series features are encoded to obtain the current time-series encoded data; A hash operation is performed on the current time-series encoded data and the window check value of the previous time window to obtain a preliminary window check value; Based on the preset timing constraint information, the current timing encoded data is used as the object to be proved, and the current timing features are constrained and verified in combination with the window configuration parameters. During the constraint verification process, the hash operation is reconstructed in the proof-side circuit to obtain the window verification value of the current time window, and the window verification value of the current time window is forced to be consistent with the initial window verification value to obtain the timing constraint verification result. The timing proof information for the current time window is generated based on the timing constraint verification results.

[0006] In some embodiments, the step of using the current time-series encoded data as the object to be proved based on preset time-series constraint information, and performing constraint verification on the current time-series features in conjunction with the window configuration parameters, and obtaining the window verification value of the current time window by reconstructing a hash operation in the proof-side circuit during the constraint verification process, and forcing the window verification value of the current time window to be consistent with the preliminary window verification value, to obtain the time-series constraint verification result, includes: Within the proof-side circuit, based on the window check value of the previous time window, the current time-series encoded data, and the hash operation rule that the initial window check value is consistent, the current time-series encoded data is iteratively hashed and reconstructed to obtain the window check value of the current time window. A consistency constraint is applied to the window check value of the current time window and the initial window check value to obtain the time-series constraint verification result.

[0007] In some embodiments, acquiring time-series data and determining the current time-series characteristics of the time-series data based on preset window configuration parameters includes: Obtain the time series data; The time-series data is stored in a buffer, and the data storage information of the buffer is collected; If the data storage information meets the preset window conditions, obtain the current time window of the time series data in the buffer; The time series data is subjected to time series feature extraction based on the current time window and the window configuration parameters to obtain the current time series features.

[0008] To achieve the above objectives, a second aspect of this application proposes a time-series data storage method, wherein the method is executed by a blockchain, the blockchain being communicatively connected to data nodes, and the method includes: Receive a current window anchoring request sent by a data node; wherein the current window anchoring request is obtained through the time-series data storage method described in the first aspect; Obtain the reference timing information of the current block based on the current window anchoring request; The current window anchoring request is verified based on the reference timing information to obtain request verification information; If the request verification information indicates that the current window anchoring request has been verified, the current window anchoring request is solidified as an on-chain anchoring record for the current time window, and the on-chain anchoring record is stored in the current block.

[0009] In some embodiments, the reference timing information includes: the current block timestamp information and the on-chain anchoring record of the previous time window; The step of verifying the current window anchoring request based on the reference timing information to obtain request verification information includes: The current window anchoring request is parsed to obtain the current time series parsing information; wherein, the current time series parsing information includes: current time series features, window check value of the current time window and window check value of the previous time window; Based on the current block timestamp information, the current time series feature is time series verified to obtain time series verification information; The window verification values ​​of the current time window and the previous time window are verified based on the on-chain anchoring record of the previous time window to obtain verification value verification information. The request verification information is determined based on the timing verification information and the check value verification information.

[0010] In some embodiments, after verifying the current window anchoring request based on the reference timing information to obtain request verification information, the method further includes: If the request verification information indicates that the current window anchoring request verification failed, abnormal window anchoring information is generated based on the current window anchoring request; The current window anchoring request is rolled back based on the abnormal window anchoring information.

[0011] To achieve the above objectives, a third aspect of this application provides a time-series data storage device, which is disposed in a data node of a blockchain system. The device includes: The acquisition module is used to acquire time series data and determine the current time series characteristics of the time series data based on preset window configuration parameters; The time series proof construction module is used to construct the time series proof information of the current time window based on the current time series characteristics, the window verification value of the previous time window and the window configuration parameters, and to determine the window verification value of the current time window; wherein, the previous time window is the time window before the current time window; The request generation module is used to generate a current window anchoring request based on the time series proof information, the window verification value of the current time window, the window verification value of the previous time window, the current time series characteristics, and the window configuration parameters. The sending module is used to send the current window anchoring request to the blockchain, so that the blockchain verifies the current window anchoring request and receives the processing result returned by the blockchain after the verification is successful. A storage module is used to store the time-series data to an off-chain storage medium if the processing result indicates successful anchoring.

[0012] To achieve the above objectives, a fourth aspect of the present application proposes a blockchain system comprising: at least one data node and a blockchain, wherein the data node executes the time-series data storage method as described in the first aspect, and the blockchain executes the time-series data storage method as described in the second aspect.

[0013] To achieve the above objectives, a fifth aspect of the present application provides a computer-readable storage medium, wherein when the computer program is executed by a processor, it implements the time-series data storage method described in the first aspect, or implements the time-series data storage method described in the second aspect.

[0014] The time-series data storage method, apparatus, electronic device, and storage medium proposed in this application collect the current time-series characteristics of the time-series data and generate time-series proof information for the current time window based on the current time-series characteristics, the window check value of the previous time window, and window configuration parameters, and determine the window check value of the current time window. Therefore, the time-series proof information characterizes the time-series characteristics of the current time window and is also associated with the window check value of the previous time window, characterizing the temporal continuity of the time-series data. Then, based on the time-series proof information and window check value of the current time window, a current window anchoring request is generated and sent to the blockchain for verification and processing. When the processing result returned by the blockchain indicates successful anchoring, the time-series data is stored in the off-chain storage medium. Therefore, a system is constructed that generates time-series proofs and stores time-series data off-chain, verifies and stores window anchoring requests for time-series data on-chain, stores time-series proofs when the time-series data's time window anchoring is successful, and the time-series proofs are witnesses that the proof system can process. This application uniformly constrains the temporal characteristics within the current time window and between adjacent time windows in a zero-knowledge circuit. Therefore, this application ingeniously combines the privacy protection capabilities of zero-knowledge proofs with the immutable evidence storage capabilities of blockchain, and constructs a data storage method that balances data privacy and trusted evidence storage for time-series data, an important data type, thereby improving the security and reliability of time-series data storage. Attached Figure Description

[0015] Figure 1A This is a system architecture diagram of the time-series data storage method provided in the embodiments of this application; Figure 1B This is a system block diagram of the time-series data storage method provided in the embodiments of this application; Figure 2 This is a flowchart of the time-series data storage method provided in the embodiments of this application; Figure 3 yes Figure 2 The flowchart of step S201 in the text; Figure 4 yes Figure 2 The flowchart of step S202 in the text; Figure 5 yes Figure 4 The flowchart of step S403 in the process; Figure 6 This is a flowchart of the time-series zero-knowledge proof algorithm in the time-series data storage method provided in the embodiments of this application; Figure 7 This is a flowchart of a time-series data storage method provided in another embodiment of this application; Figure 8 yes Figure 7 The flowchart of step S703 in the process; Figure 9This is a flowchart of the time anchoring algorithm in the time-series data storage method provided in the embodiments of this application; Figure 10 This is a flowchart of a time-series data storage method provided in another embodiment of this application; Figure 11 This is a schematic diagram of the structure of the time-series data storage device provided in the embodiments of this application. Detailed Implementation

[0016] To make the objectives, technical solutions, and advantages of this application clearer, the following detailed description is provided in conjunction with the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are merely illustrative and not intended to limit the scope of this application.

[0017] It should be noted that although functional modules are divided in the device schematic diagram and a logical order is shown in the flowchart, in some cases, the steps shown or described may be performed in a different order than the module division in the device or the order in the flowchart. The terms "first," "second," etc., in the specification, claims, and the aforementioned drawings are used to distinguish similar objects and are not necessarily used to describe a specific order or sequence.

[0018] Unless otherwise defined, all technical and scientific terms used herein have the same meaning as commonly understood by one of ordinary skill in the art to which this application belongs. The terminology used herein is for the purpose of describing embodiments of this application only and is not intended to limit this application.

[0019] First, let's analyze some of the terms used in this application: Blockchain: A decentralized distributed ledger that is block-based, immutable, secure and reliable. It combines distributed storage, peer-to-peer transmission, consensus mechanisms, cryptography and other technologies to record transactions and information through a continuously growing chain of data blocks, ensuring data security and transparency.

[0020] Time-series data, also known as time series data, is a sequence of data arranged in chronological order. In daily life, data collected by devices and sensors is time-series data, as are records of securities transactions.

[0021] Zero-Knowledge Proof (ZKP) algorithms are cryptographic techniques that allow a prover to demonstrate the truth of a statement to a verifier without revealing any sensitive information. This technique ensures data authenticity while protecting privacy and is widely used in fields such as blockchain, identity verification, and secure communication.

[0022] A hash chain is a data structure that uses a hash function to sequentially link data blocks. Each data block contains the hash value of the previous data block, thus ensuring data integrity and immutability. It is widely used in blockchain, data integrity verification, secure storage, and other fields.

[0023] Merkle trees are hash-based tree data structures. Their main characteristic is the use of recursive hash calculations to verify data integrity and consistency. Merkle trees are widely used in blockchain, distributed storage, and digital signatures.

[0024] As various information systems rapidly evolve towards online, automated, and refined operations, a large number of business processes, such as financial transaction flows, industrial process monitoring records, equipment operation logs, and network access trajectories, are continuously collected and accumulated in time-series form, forming multi-source, multi-dimensional, and high-frequency time-series data sets. On the one hand, multi-dimensional time-series data requires highly reliable and complete traceability to prevent subsequent tampering or selective disclosure; on the other hand, due to its massive volume and sensitive details, it is often difficult to directly store in plaintext for long periods in public or alliance settings. This leads to a particularly prominent contradiction: "both scalable and traceable reliable evidence storage and controlled exposure scope are needed." Therefore, the simple storage method of "recording the data" is no longer sufficient to address the concerns and needs of all parties regarding "when did something happen, whether the record is complete, and whether there was any subsequent deletion or modification" on the timeline. "How should time-series data be stored?" is no longer a simple implementation detail but is evolving into a core issue related to the reliable operation of the system and the usability of the data.

[0025] Currently, traditional storage solutions for time-series data are often centralized, such as centralized relational databases and time-series databases. These are typically operated by a single institution, focusing on index design, compression encoding, and query optimization to support high-frequency writes and complex queries. However, they struggle to provide publicly verifiable and traceable tamper-proof guarantees in multi-party environments, failing to address the cross-institutional trust issue of "who can prove the data hasn't been altered," and easily leading to data silos. Furthermore, while blockchain is a potential solution, current research often uses it to store simple key-value pairs or batch-level summaries, lacking a specific storage solution for massive, multi-source, heterogeneous time-series data. In recent years, blockchain-based data storage technologies have discussed storage designs for other large-scale, high-frequency data. On-chain storage systems treat the blockchain itself as a distributed database, while hybrid storage systems typically store raw data in external databases or decentralized storage networks, recording only hash values, pointers, or limited metadata on the blockchain to achieve tamper-proof indexing and access control. Simultaneously, blockchain timestamp technology has also received extensive research. Existing blockchain-based trusted timestamp technologies primarily rely on off-chain data hashing and anchoring to block timestamps, or employ sophisticated protocols and smart contract timestamps like Chronoos+ to prove the existence of individual files or events. Off-chain logs and device clocks may be unreliable before anchoring, and their timelines may be subject to missing, rewritten, or rollback risks. Meanwhile, while blockchain timestamps possess tamper-resistance, they are limited by block generation mechanisms and network latency, often exhibiting coarsening and inaccuracies relative to physical time. In summary, while blockchain has proven itself a secure infrastructure for large-scale data storage and a decentralized mechanism for proving the existence of digital objects, current work typically treats data as independent records or files. It has not yet treated high-frequency, multi-source time series as holistic objects with a defined time structure for window-level modeling, nor has it systematically addressed the issues of authenticity, integrity, and cross-window continuity of multi-source high-frequency time series data at the time window level by explicitly anchoring off-chain timestamps to consensus-protected on-chain timestamps.

[0026] Therefore, blockchain-based sequential data storage faces multiple challenges. Due to the inherent limitations of blockchain, massive amounts of multi-source, heterogeneous time-series data cannot be directly stored on the chain. Simply storing raw data summaries on the chain does not allow the blockchain to directly perceive the temporal characteristics of the time-series data. Data bound to timestamps may contain sensitive information, and the storage process needs to minimize the risk of data exposure.

[0027] Based on this, embodiments of this application provide a time-series data storage method and apparatus, a blockchain system, and a storage medium. The aim is to establish a blockchain-based time-series data storage method. This method generates time-series proof information and a window verification value for the current time window based on the current time-series characteristics of the time-series data within the current time window, the window verification value of the previous time window, and window configuration parameters. Then, a current window anchoring request is generated based on the time-series proof information and the current time window's window verification value, and this request is sent to the blockchain storage. The time-series proof information is lightweight, enabling lightweight time-series proofs to be stored on-chain while time-series data is stored off-chain, saving on-chain storage space. Therefore, without disclosing the time-series data, the numerical authenticity, window integrity, and temporal continuity of the time-series data during its generation and storage process can be publicly and reliably proven. This allows the blockchain to perceive the temporal characteristics of the time-series data without needing to access the data itself, reducing the risk of data leakage.

[0028] The time-series data storage method and apparatus, blockchain system and storage medium provided in the embodiments of this application are specifically described through the following embodiments. First, the time-series data storage method in the embodiments of this application is described.

[0029] The embodiments of this application can acquire and process relevant data based on artificial intelligence technology. Artificial intelligence (AI) refers to the theories, methods, technologies, and application systems that use digital computers or machines controlled by digital computers to simulate, extend, and expand human intelligence, perceive the environment, acquire knowledge, and use that knowledge to obtain optimal results.

[0030] The fundamental technologies of artificial intelligence generally include sensors, dedicated AI chips, cloud computing, distributed storage, big data processing, operating / interactive systems, and mechatronics. AI software technologies mainly encompass computer vision, robotics, biometrics, speech processing, natural language processing, and machine learning / deep learning.

[0031] The time-series data storage method provided in this application relates to the field of data storage technology. This method can be applied to a terminal, a server, or software running on either a terminal or a server. In some embodiments, the terminal can be a smartphone, tablet, laptop, desktop computer, etc.; the server can be configured as an independent physical server, a server cluster or distributed system composed of multiple physical servers, or a cloud server providing basic cloud computing services such as cloud services, cloud databases, cloud computing, cloud functions, cloud storage, network services, cloud communication, middleware services, domain name services, security services, CDN, and big data and artificial intelligence platforms; the software can be an application implementing the time-series data storage method, but is not limited to the above forms.

[0032] This application can be used in a wide variety of general-purpose or special-purpose computer system environments or configurations. Examples include: personal computers, server computers, handheld or portable devices, tablet devices, multiprocessor systems, microprocessor-based systems, set-top boxes, programmable consumer electronics, network PCs, minicomputers, mainframe computers, and distributed computing environments including any of the above systems or devices. This application can be described in the general context of computer-executable instructions executed by a computer, such as program modules. Generally, program modules include routines, programs, objects, components, data structures, etc., that perform specific tasks or implement specific abstract data types. This application can also be practiced in distributed computing environments where tasks are performed by remote processing devices connected via a communication network. In distributed computing environments, program modules can reside in local and remote computer storage media, including storage devices.

[0033] It should be noted that in all specific embodiments of this application, when processing data related to user identity or characteristics, such as user information, user behavior data, user historical data, and user location information, user permission or consent will be obtained first. Furthermore, the collection, use, and processing of this data will comply with relevant laws, regulations, and standards. In addition, when embodiments of this application require access to sensitive personal information of users, separate permission or consent from the user will be obtained through pop-ups or redirects to confirmation pages. Only after obtaining the user's separate permission or consent will the necessary user-related data for the normal operation of the embodiments of this application be obtained.

[0034] Figure 1AThis application provides a blockchain system, which refers to a system for storing time-series data sent by data nodes. This blockchain system is a distributed system formed by multiple data nodes (any form of computer device connected to the network, such as servers or user terminals) connected through network communication. The data nodes form a peer-to-peer (P2P) network, and the P2P protocol is an application layer protocol running on top of the Transmission Control Protocol (TCP). In the blockchain system, any machine, such as a server or terminal, can join and become a data node. Data nodes communicate with the blockchain and include off-chain storage media. It should be noted that information transmission between multiple data nodes is achieved through routing. For example... Figure 1B As shown, the data nodes consist of a bottom layer, a middle layer, and an upper layer. The bottom layer is the time-series data acquisition and slicing layer, receiving continuous time-series data from multiple sources such as sensors, business systems, and log pipelines, and slicing it according to a set slicing strategy, with each time slice forming a time window. The middle layer is the time-series zero-knowledge proof layer, generating concise time-series proof information for time-series characteristics such as timestamp continuity, window integrity, and numerical constraints within each time window without disclosing the time-series data, and outputting the time-series proof information. The upper layer is the blockchain storage and verification layer, verifying the time-series proof information for each time window, and writing the time-series proof information to the blockchain only after successful verification, achieving cross-time-window authenticity traceability and rapid verification. Therefore, this embodiment implements a method of generating and storing time-series proof information off-chain, and verifying and storing the time-series proof information on-chain. On one hand, it provides a time-series proof for the time-series data, generated without exposing the data, thus characterizing the temporal continuity and window integrity of the data. On the other hand, on-chain verification before storage enhances the credibility of the time-series proof, and the on-chain stored proof is lightweight, saving storage space. Furthermore, the generated time-series proof incorporates verification of temporal features such as timestamp continuity, window integrity, and numerical constraints, enabling the blockchain to "understand" and verify temporal characteristics like temporal continuity without accessing the data.

[0035] Figure 2 This is an optional flowchart of a time-series data storage method provided in the embodiments of this application. The time-series data storage method is applied to the data nodes of the blockchain, and the data nodes are connected to the blockchain for communication. Figure 2 The method may include, but is not limited to, steps S201 to S205.

[0036] Step S201: Acquire time series data and determine the current time series characteristics of the time series data based on preset window configuration parameters; Step S202: Construct the time series proof information of the current time window based on the current time series characteristics, the window verification value of the previous time window, and the window configuration parameters, and determine the window verification value of the current time window; wherein, the previous time window is the time window before the current time window; Step S203: Generate the current window anchoring request based on the time series proof information, the window verification value of the current time window, the window verification value of the previous time window, the current time series characteristics, and the window configuration parameters; Step S204: Send the current window anchoring request to the blockchain, so that the blockchain verifies the current window anchoring request and receives the processing result returned by the blockchain after the verification is successful. Step S205: If the processing result indicates successful anchoring, the time-series data is stored in the off-chain storage medium.

[0037] Steps S201 to S205 of this embodiment involve collecting the current temporal characteristics of the time-series data according to window configuration parameters, and generating temporal proof information and window verification value for the current time window based on the current temporal characteristics, the window verification value of the previous time window, and the window configuration parameters. The temporal proof information characterizes the temporal characteristics of the time-series data and is also associated with the window verification value of the previous time window, indicating the continuity of time. Then, a current window anchoring request is generated based on the current time window's temporal proof information and window verification value, the previous time window's window verification value, the current temporal characteristics, and the window configuration parameters. The current window anchoring request is sent to the blockchain for verification and processing. After the blockchain verifies the current window anchoring request, the time-series data is stored on an off-chain storage medium. Therefore, this method constructs a system that generates temporal proofs and stores temporal data off-chain, verifies and stores temporal proofs on-chain, and generates temporal proofs based on temporal characteristics within a window, making it a witness that the proof system can process. This system uniformly constrains the temporal characteristics within the current time window and between adjacent time windows in a zero-knowledge circuit. Therefore, the embodiments of this application cleverly combine the privacy protection capabilities of zero-knowledge proofs with the immutable evidence storage capabilities of blockchain, and construct a data storage method that takes into account both data privacy and trusted evidence storage for time-series data, an important data type, thereby improving the security and time-series data storage reliability.

[0038] In step S201 of some embodiments, the time-series data comes from data sources such as sensors and business systems, and the time-series data has time-series characteristics. It should be noted that the current time window is the time window that currently meets the preset window conditions, and the previous time window is defined as the previous time window. Therefore, using the time window as the basic unit, time-series characteristics are collected, and time-series proof information is generated based on the current time-series characteristics, the window check value of the previous time window, and window configuration parameters, thus constructing proof information that characterizes the continuity and integrity of time.

[0039] In one application scenario, taking surveillance video as an example, the surveillance video is divided into multiple segments according to time windows. For each segment, a time-series proof and window verification value are generated, containing the current time-series characteristics, the window verification value of the previous time window, and window configuration parameters. These are then stored on the blockchain in the form of a window anchoring request. Essentially, the window verification value of each surveillance video segment is stored on a hyperledger (blockchain). When it's necessary to verify the time sequence, integrity, and modification status of a surveillance video segment, only the window verification value needs to be retrieved from the blockchain for verification. The entire process does not disclose the content of the surveillance video segment, improving data security and efficiently verifying the credibility of time-series data.

[0040] Please see Figure 3 In some embodiments, step S201 may include, but is not limited to, steps S301 to S304: Step S301: Obtain timing data; Step S302: Store the time series data in the buffer and collect the data storage information of the buffer; Step S303: If the data storage information meets the preset window conditions, obtain the current time window of the time series data in the buffer; Step S304: Extract time series features from the time series data based on the current time window and window configuration parameters to obtain the current time series features.

[0041] In step S301 of some embodiments, the time-series data is continuously collected and accumulated in the form of time series to form multi-source, multi-dimensional, and high-frequency data. The time-series data can be financial transaction flow, industrial process monitoring data, equipment operation data, and network access trajectory, etc. This embodiment does not limit the specific form of the time-series data.

[0042] In step S302 of some embodiments, time-series data is accessed through the multi-source time-series data input module of the source data layer, and then input to the time-series data slicing module and the off-chain hash commitment module of the acquisition and slicing layer. However, before inputting the time-series data into the preprocessing layer, the multi-source time-series data input module divides the buffer according to the data channel or dataset and caches the time-series data in the buffer. The time-series characteristics of the time-series data are maintained in the buffer according to the arrival order of the time-series data. Data storage information of the time-series data in each buffer is collected at preset time intervals, and the data storage information may include at least one of the following: data cache size, data cache duration, and data cache count. This embodiment does not limit the data storage information.

[0043] In steps S303 to S304 of some embodiments, preset window conditions are used to constrain the conditions of the time-series data window, and the preset window conditions include at least one of the following: preset cache size, preset cache duration, and preset cache count. Specifically, if the data storage information is the data cache size, and the data cache size reaches the preset cache size, the time window of the time-series data in the buffer is determined to be the current time window. If the data storage information is the data cache duration, and the data cache duration reaches the preset cache duration, the time window of the time-series data in the buffer is determined to be the current time window. If the data storage information is the data cache count, and the data cache count reaches the preset cache count, the time window of the time-series data in the buffer is determined to be the current time window. After determining the current time window, the time-series data within the current time window is sorted by time, and the start and end times of the current time window are determined as the current time-series feature.

[0044] Specifically, the current time window is determined, and the preceding time window is defined as the previous time window. By dividing the data into the previous and current time windows, the time series data generated continuously is effectively segmented into multiple time windows according to a preset segmentation strategy. Upon reaching each time window, time series verification information and a window validation value are generated, matching the time series reliability verification scenarios of continuously generated time series data. This approach is suitable for segmented verification of excessively long time series data. It should be noted that the segmented window can be a fixed window, a sliding window, or an adaptive window, adapting to different lengths or scenarios of time series data segmentation.

[0045] Taking sensor data as an example, sensor data is continuously generated and needs to be stored in real time. A time window is pre-defined. When the cached duration of sensor data in the buffer reaches the preset cache duration, the arrival time of the sensor data in the buffer and the current time are recorded as the start and end times of the window. Then, the time sequence proof information and window verification value for the current time window are generated. Therefore, each time window of continuously generated sensor data has a window verification value. When it is necessary to obtain sensor data for a specific time period, the window verification value is extracted from the blockchain in advance. The temporal integrity of the corresponding sensor data is determined by the window verification value, and then the sensor data is extracted, improving the temporal reliability of the sensor data.

[0046] In steps S301 to S304 of this embodiment, the time series data is first stored in a buffer. When the data storage information of the time series data in the buffer meets the preset window conditions, the time series data of that part is closed into a time window to obtain the current time window. The start and end times of the current time window are determined as the current time series feature. This realizes that the time series data is divided according to the time window, and the time series proof information is quickly generated using the time window as a unit, without having to process endless time series data.

[0047] In step S202 of some embodiments, time series proof information for the current time window is generated. This embodiment employs a time series zero-knowledge proof algorithm to generate time series proof information for the current time window based on the current time series characteristics, the window check value of the previous time window, and window configuration parameters without disclosing the time series data. It also determines the window check value for the current time window to generate simplified proofs and window check values ​​for time series characteristics such as timestamp continuity, window integrity, and numerical constraints within the current time window. For example... Figure 1B As shown, in this embodiment, the time-series proof information of the current time window is generated by the time-series zero-knowledge proof layer, and the time-series zero-knowledge proof layer includes a time-series feature circuit and a hash structure circuit. The time-series feature circuit is used to constrain the time-series features generated by the time-series proof information, and the hash structure circuit is used to perform hash operations on the current time-series features.

[0048] Please see Figure 4 In some embodiments, the construction of timing proof information based on the current timing features, the window check value of the previous time window, and the window configuration parameters in step S202 may include, but is not limited to, steps S401 to S404: Step S401: Encode the current time series features to obtain the current time series encoded data; Step S402: Perform a hash operation on the current time-series encoded data and the window check value of the previous time window to obtain a preliminary window check value; Step S403: Based on the preset timing constraint information, the current timing encoded data is used as the object to be proved, and the current timing features are constrained and verified in combination with the window configuration parameters. During the constraint verification process, the hash operation is reconstructed in the proof side circuit to obtain the window verification value of the current time window, and the window verification value of the current time window is forced to be consistent with the initial window verification value to obtain the timing constraint verification result. Step S404: Generate the timing proof information for the current time window based on the timing constraint verification results.

[0049] In step S401 of some embodiments, the current time sequence characteristics within the current time window are encoded under the blockchain through a hash structure circuit. Specifically, the timestamp and value of the current time window are encoded to obtain the current time sequence encoded data.

[0050] In step S402 of some embodiments, the window check value of the previous time window is also called the commitment value of the previous time window, which is unique sealed data of the previous time window. The current time-series encoded data and the window check value of the previous time window are hashed sequentially according to a pre-agreed hash chain queue to obtain the preliminary window check value of the current time window. Specifically, the window check value of the previous time window is defined as... According to the pre-agreed Poseidon hash chain rules, the window check values ​​of the previous time window are aggregated sequentially. Combined with the current time-series encoded data, obtain the preliminary window check value for the current time window. This allows the various time windows to be naturally linked together into an irreversible hash chain under the blockchain.

[0051] In step S403 of some embodiments, the timing constraint information is used to evaluate the current timing encoded data, the preliminary window check value, the window check value of the previous time window, the current timing characteristics, and the window configuration parameters. Specifically, it evaluates the timestamp ordering, whether the current time interval is within a preset interval range, window integrity, and configurable values, etc. This allows for multi-faceted temporal verification of the timing data under a blockchain framework. Generating the window check value of the current time window can directly clarify the window integrity and temporal continuity of the timing data. It should be noted that the generated preliminary window check value cannot be directly used as the window check value of the current time window. It is still necessary to uniformly constrain the timing characteristics within the current time window and between adjacent time windows using a zero-knowledge circuit. This constructs a check value that can characterize the timestamp continuity, window integrity, and numerical constraint characteristics of the timing data within the current time window. The window check value of the current time window can then be used to determine the integrity and temporal continuity of the timing data, thereby improving the reliability of the timing data. Therefore, the current time-series encoded data is used as the object to be proved, and the current time-series characteristics are constrained and verified in conjunction with window configuration parameters. The constraint verification process involves reconstructing the hash operation within the proof-side circuit to obtain the window verification value of the current time window, which is defined as follows: This is equivalent to reconstructing the window check value of the current time window based on the orderliness of the timestamps, interval requirements, the integrity of the window length, and configurable values. Specifically, when constructing the window check value of the current time window, it is forced to be consistent with the initial window check value to determine the timing constraint verification result.

[0052] In step S404 of some embodiments, timing proof information for the current time window is generated based on the timing constraint verification result, and the timing proof information is a timing zero-knowledge proof π. Simultaneously, the window verification value corresponding to the timing zero-knowledge proof π is... This serves as the window checksum for the current time window. It should be noted that the process for determining the window checksum for the previous time window is the same as that for the current time window, and will not be repeated in this embodiment.

[0053] In steps S401 to S404 of this embodiment, the process of generating the temporal proof information for the current time window specifically employs a zero-knowledge temporal proof algorithm. First, the current temporal features of the current time window are encoded into current temporal encoded data. Then, based on a hash chain, the current temporal encoded data and the window verification value of the previous time window are hashed to obtain the preliminary window verification value of the current time window. Using the current encoded data as a private witness, the current temporal features are constrained and verified in conjunction with window configuration parameters. The constraint verification process involves reconstructing the hash operation within the proof-side circuit to obtain the window verification value of the current time window. Finally, the window verification value of the current time window is forced to match the preliminary window verification value to obtain the temporal proof information for the current time window. Therefore, constructing the temporal proof information for the current time window is done without leaking the temporal data, and it can directly characterize the window integrity, temporal continuity, and numerical constraints of the temporal data, thereby improving the credibility of the temporal data.

[0054] Please see Figure 5 In some embodiments, step S403 may include, but is not limited to, steps S501 to S502: Step S501: In the proof-side circuit, according to the hash operation rule that the window check value of the previous time window, the current time-series encoded data, and the initial window check value are consistent, the current time-series encoded data is iteratively hashed and reconstructed to obtain the window check value of the current time window. Step S502: Apply consistency constraints to the window check value and the preliminary window check value of the current time window to obtain the time constraint verification result.

[0055] In steps S501 to S502 of some embodiments, the window configuration parameters include the current time interval and the current window length. The proof-side circuit is also called the timing constraint circuit. In the timing constraint circuit, the encoded current timing encoded data is a private witness. The window verification value of the previous time window, the preliminary window verification value, the window start and end time, the current time interval, and the current window length are publicly input to the timing constraint circuit. In the timing constraint circuit, the orderliness of the timestamp, the current time interval, and the integrity of the window are verified. Inside the timing constraint circuit, the current timing encoded data is iteratively hashed and reconstructed according to the hash chain logic consistent with the blockchain to obtain the window verification value of the current time window. The reconstructed window verification value of the current time window is forced to be equal to the given preliminary window verification value. Finally, the timing constraint verification result is determined.

[0056] In steps S501 to S502 of this embodiment, within the timing constraint circuit, the current timing encoded data is iteratively hashed and reconstructed according to the hash operation rule that the window check value of the previous time window, the current timing encoded data, and the preliminary window check value are consistent. The window check value of the current time window is required to be consistent with the preliminary window check value to determine the timing constraint verification result, and finally, the timing proof information of the current time window is determined. Therefore, the constructed window check value of the current time window can characterize the timing characteristics of the timing data, such as timing continuity, window integrity, and numerical constraints. This allows the credibility of the timing data to be determined directly by retrieving the window check value on the blockchain, reducing the risk of timing data leakage.

[0057] Please refer to Figure 6 , Figure 6 This illustrates a time-series zero-knowledge proof algorithm and its process. In a blockchain system, the algorithm first obtains the current time-series characteristics within the current time window and the window verification value of the previous time window within the blockchain. The current time series feature is the start and end times of the current time window. These start and end times are mapped sequentially to finite field elements or fixed-length bit strings that the system can process, with the encoding order corresponding one-to-one with the actual time order, resulting in the current time series encoded data. A preliminary window check value is generated based on the current time series encoded data and the window check value of the previous time window. The timing constraint circuit uses the encoded current timing data as a private witness and the window check value of the previous time window. Preliminary window verification value Parameters such as window timestamp, current time window, and current window length are used as public inputs. Multiple timing constraints are simultaneously characterized in the timing constraint circuit. These constraints include, but are not limited to: the window timestamp must be strictly incremental; the difference between adjacent time windows must be within a preset range, reflecting the acquisition period and jitter upper bound; the number of records within the window must equal the preset length, ensuring the integrity of the window granularity. If the timing constraint output of the timing constraint circuit satisfies the constraints, the window verification value is reconstructed. Specifically, following the hash chain logic consistent with blockchain, the timing constraint circuit triggers the sequential aggregation of the current encoded data within the window, starting from the window verification value of the previous time window, to reconstruct the window verification value of the current time window. And force the window checksum of the current time window. And the initial window validation value of the publicly input The consistency verifies that the time-series data has not been tampered with since its generation, thus possessing verifiable authenticity. Therefore, when the initial window check value... Window checksum of the current time window Consistent, output the window checksum of the current time window. And based on the window check value of the current time window. The time-series proof information for the current time window is generated. Therefore, the time-series proof information for the current time window implies the existence of a set of unpublished time-series data that simultaneously satisfies the preset time-series constraints and hash chain heterogeneity. The resulting time-series proof information for the current time window is relatively small in size, suitable for scalable on-chain storage, and only exposes the window checksum of the current time window, the window checksum of the previous time window, the window timestamp, and a small number of window configuration parameters. This allows the verifier of the time-series data to confirm the time-series characteristics of the data without accessing the data itself.

[0058] For example, an industrial system may be equipped with various sensor devices. The sensor data generated by these devices is stored directly on off-chain storage, while on-chain storage contains temporal proof information and window verification values ​​characterizing the sensor data's temporal continuity, window integrity, and numerical constraints. Therefore, when sensor data needs to be accessed, if it's necessary to assess the window integrity and temporal continuity of the data to be accessed, verification can be achieved by directly extracting the window verification value from the blockchain, and then retrieving the sensor data from the off-chain storage. This simplifies verification and reduces the risk of sensor data leakage.

[0059] In step S203 of some embodiments, in order to resolve the discrepancy between the off-chain "real time" and the on-chain "consensus time" and to prevent time-series data from being cached for a long time and then "post-marked", this application embodiment sets a timestamp anchoring algorithm. While generating the time-series proof information of the current time window, the timestamp anchoring algorithm extracts the real start and end time of the current time window from the trusted event source or the network side, and encapsulates it together with hash chain information including the window verification value of the current time window and the window verification value of the previous time window into the current window anchoring request.

[0060] Specifically, the temporal proof information is a temporal zero-knowledge proof π, and a proof digest is obtained by performing a hash operation on the temporal zero-knowledge proof π under the blockchain. Only retain the window checksum of the current time window. Window validation value of the previous time window Proof Summary The necessary metadata, such as the window start and end time, window number, and channel identifier, are used to construct the current window anchoring request.

[0061] In step S204 of some embodiments, the current window anchoring request is submitted to the blockchain via a blockchain node. A time anchoring and blockchain notarization module is set up on the blockchain. This module receives the current window anchoring request via an on-chain time anchoring contract and performs a time-series verification to obtain request verification information. If the request verification information indicates that the current window anchoring request has passed verification, the current window anchoring request is stored, and the processing result returned by the current window anchoring request indicates successful anchoring.

[0062] Please see Figure 7 This embodiment also discloses a time-series data storage method, executed by a blockchain. The time-series data storage method may include, but is not limited to, steps S701 to S704: Step S701: Receive the current window anchoring request sent by the data node; wherein, the current window anchoring request is obtained through the above-described time-series data storage method; Step S702: Obtain the reference timing information of the current block according to the current window anchoring request; Step S703: Verify the current window anchoring request based on the reference timing information to obtain the request verification information; Step S704: If the verification information indicates that the current window anchoring request has been verified, the current window anchoring request is solidified into an on-chain anchoring record for the current time window, and the on-chain anchoring record is stored in the current block.

[0063] In step S702 of some embodiments, the reference timing information is used to verify the continuity and consistency of the current window anchoring request in timing, specifically to verify whether adjacent time windows are continuous without anomalies.

[0064] In step S703 of some embodiments, as disclosed above, the current window anchoring request records the window checksum of the current time window, the window checksum of the previous time window, the current timing characteristics, and window configuration parameters. Verification mainly verifies the accuracy of the window checksum of the previous time window, the timing differences of the current timing characteristics, and the continuity of the time window, thereby obtaining the requested verification information.

[0065] In step S704 of some embodiments, if the current window anchoring request is verified as passed, the current window anchoring request, which includes the current window verification value, the window verification value of the previous time window, the current time sequence characteristics, window configuration parameters, and the time sequence proof information of the current time window, is solidified into an on-chain anchoring record for the current time window. This on-chain anchoring record is then written into the evidence storage structure on the blockchain, forming an anchoring chain recursively ordered by time window. Simultaneously, time sequence data, verified as passed by the current window anchoring request, is transferred from the buffer to the off-chain storage medium.

[0066] In steps S701 to S704 of this embodiment, after receiving the current window anchoring request, the current window anchoring request is verified for temporal continuity and consistency to obtain request verification information. If the request verification information indicates that the current window anchoring request has passed verification, the current window anchoring request is then solidified into an on-chain anchoring record and stored on the blockchain, thereby improving the accuracy of the on-chain anchoring record stored on the blockchain. This embodiment is equivalent to establishing a mapping relationship between off-chain time and on-chain consensus time at the time window level, constraining and auditing the authenticity and freshness of cross-window time links, and improving the credibility of the on-chain anchoring record stored on the blockchain.

[0067] In some embodiments, the reference timing information includes: the current block timestamp information and the on-chain anchor record of the previous time window; the current block timestamp information is defined as follows: The on-chain anchor record of the previous time window contains the window check value of the time window before the previous one, the window check value of the previous time window, the previous time series characteristics, the previous time series proof information, and the window configuration parameters.

[0068] Please see Figure 8 In some embodiments, step S703 includes, but is not limited to, steps S801 to S804: Step S801: Parse the current window anchoring request to obtain the current time series parsing information; wherein, the current time series parsing information includes: the current time series characteristics, the window check value of the current time window and the window check value of the previous time window; Step S802: Perform time-series verification on the current time-series features based on the current block timestamp information to obtain time-series verification information; Step S803: Verify the current window check value and the previous window check value based on the on-chain anchoring record of the previous time window to obtain the check value verification information. Step S804: Determine the request verification information based on the timing verification information and the check value verification information.

[0069] In step S802 of some embodiments, the current timing feature is the start and end time of the current time window, defined as follows: , Temporal verification of the current time series features mainly involves imposing constraints on the temporal relationship between the start and end times of the current window and the timestamp information of the current block. For example, the current window end time... No later than the current block timestamp information And the current block timestamp information With the current window deadline The lag value between windows does not exceed a preset threshold, and the continuity of adjacent windows is verified based on the start and end times of the current window and the time of the previous window.

[0070] In step S803 of some embodiments, the window verification value of the chain anchoring record of the previous time window is compared with the window verification value of the current window anchoring request to obtain verification value verification information.

[0071] In step S804 of some embodiments, if both the timing verification information and the checksum verification information indicate successful verification, then the request verification information indicates that the current window anchoring request verification has passed. If either the timing verification information or the checksum verification information indicates verification failure, then the request verification information indicates that the current window anchoring request verification has failed.

[0072] In steps S801 to S804 of this embodiment, the current window anchoring request is verified in multiple dimensions such as time sequence and verification value to ensure that the newly generated current window anchoring request is consistent and continuous at the adjacent window boundary time, thereby improving the accuracy of the integrity and continuity of the time sequence data represented by the current window anchoring request on the blockchain.

[0073] Please refer to Figure 9 , Figure 9 The flowchart of the time anchoring algorithm is shown. After generating the zero-knowledge proof π for the current time window, the system performs a hash operation on the zero-knowledge proof π under the blockchain to obtain the proof digest. And construct a value containing the current window's validation value. Window validation value of the previous time window Proof Summary The current window anchoring request includes information such as the current window start and end times and window number. This request is submitted to the time anchoring contract on the blockchain via data nodes. During execution, the time anchoring contract reads the consensus timestamp of the current block as the current block timestamp information. It compares this timestamp with the current window's end time in the current window start and end timestamp to check if the lag between the generation of time-series data on the blockchain and its confirmation on the blockchain is within a preset range. Simultaneously, the time anchoring contract queries the on-chain anchoring record of the previous time window and compares the window verification value in the previous time window's on-chain anchoring record with the window verification value in the current window anchoring request to determine consistency. It also checks the relationship between the current window's start time in the current window start and end timestamp and the previous time window's end time in the previous time window's on-chain anchoring record, identifying time regression, abnormal overlap, or unexplained time spaces, thereby constraining the continuity of cross-window time boundaries. Finally, only when the lag check (i.e., the reconnaissance check) and the cross-window continuity check both pass, will the time anchoring contract store the window checksum of the current time window, the window checksum of the previous time window, the window time boundary, the current block timestamp information, and the proof digest. The relevant metadata is solidified into new on-chain anchor records, enabling multiple time windows to form a time anchor chain on the chain, recursively linked according to the time windows. These on-chain anchor records can be viewed by the time series data verification end. The time series continuity and window integrity of the time series data can be determined simply by viewing the on-chain anchor records, reducing the risk of time series data leakage and improving the efficiency of time series data credibility verification.

[0074] It should be noted that the window anchoring request for each time window is verified and stored in the manner described above. This embodiment uses the current time window as a specific example for illustration, and the verification and storage of window anchoring requests for other time windows will not be elaborated here. In summary, for continuously generated time-series data, the window anchoring request for each time window is continuously stored on a time-window basis. The generated window anchoring request has already undergone a pre-assessment of the temporal continuity and integrity of the time-series data off-chain, and further verification is performed on-chain. This ensures that the window anchoring request stored on-chain can accurately characterize the temporal continuity, integrity, and numerical constraints of the time-series data in each time window, and that the window anchoring request is generated without disclosing the time-series data. This improves the efficiency of time-series data credibility verification and reduces the risk of data leakage.

[0075] Please see Figure 10 In some embodiments, after step S802, the time-series data storage method may also include, but is not limited to, steps S1001 to S1002: Step S1001: If the verification request information indicates that the current window anchoring request verification has failed, generate abnormal window anchoring information based on the current window anchoring request. Step S1002: Perform a rollback operation on the current window anchoring request based on the abnormal window anchoring information.

[0076] In step S1001 of some embodiments, the request verification information indicates that the current window anchoring request verification failed, indicating that the lag check or cross-window continuity check of the current window anchoring request failed, generating abnormal window anchoring information, and the abnormal window anchoring information indicates the reason for the current window anchoring request verification failure and window information, so as to provide a basis for subsequent auditing and accountability through the abnormal window anchoring information.

[0077] In step S1002 of some embodiments, performing a rollback operation on the current window anchoring request means rolling back the current window anchoring request to the data node corresponding to the time series data. This allows the staff at the data node to connect the time series data, which is not continuous in time and is at risk of tampering. This facilitates the staff at the data node to maintain the output device of the time series data.

[0078] Taking time-series financial data as an example, specifically the financial transaction records of each user in a bank, a window anchoring request is generated for each time window's financial transaction records. When the window anchoring request is stored on the blockchain, it is considered to have failed verification, indicating that the financial transaction records are discontinuous or incomplete in time sequence, with missing or modified consumption records, which will affect financial fairness. Therefore, if the finance department receives a rejected window anchoring request, it can promptly find and analyze abnormal financial transaction records. It should be noted that the financial transaction records are segmented according to time windows to generate window anchoring requests, allowing for direct retrieval of the corresponding financial transaction records based on the rejected window anchoring requests, simplifying the search for abnormal financial transaction records and improving the efficiency of financial transaction anomaly analysis.

[0079] In steps S1001 to S1002 of this embodiment, if the current window anchoring request verification fails, an abnormal window anchoring request is generated, and the current window anchoring request is rolled back according to the abnormal window anchoring request, so that the data node receiving the current window anchoring request can quickly find the abnormal time series data and quickly complete the time series anomaly analysis.

[0080] The key point of this application's embodiments lies in constructing a time-aware blockchain evidence storage method for time-series data, which combines "time-series zero-knowledge proof" and "block timestamp anchoring." This method enables multi-dimensional, high-frequency time-series data to obtain verifiable authenticity and temporal continuity on the blockchain, using time windows as the basic unit, without exposing the original plaintext. The key technical solutions for the two protection points are described below: 1. Temporal zero-knowledge proof algorithm.

[0081] Key points: For any time window, this application embodiment encodes the timestamp and multi-dimensional values ​​of each time window into a witness vector according to the actual occurrence order. Using the window verification value of the previous time window, the window verification value of the current time window, the start and end times of the window, the time interval, and the window length as public inputs, multiple types of temporal constraints are simultaneously characterized within the same zero-knowledge circuit. These constraints include, but are not limited to: timestamps must be strictly incremental; the difference between adjacent timestamps must fall within a preset interval to reflect the sampling period and jitter upper bound; and the number of records within the window must equal a preset length to ensure window granularity and integrity. Internally, the circuit then aggregates the encoded data within the window sequentially, starting from the window verification value of the previous time window, according to hash chain rules completely consistent with off-chain methods. This reconstructs the window verification value of the current time window, forcing the reconstruction result to be consistent with the window verification value of the current time window in the public input. Thus, the temporal structure, which originally only existed at the off-chain storage medium level, is elevated to a constraint semantic that can be directly verified by the zero-knowledge proof system, and folded into a smaller temporal zero-knowledge proof suitable for storage on the blockchain.

[0082] Protection points: Protect this time window-level time-series zero-knowledge proof construction method, especially the combination of the following features: (1) Map the time-series data within the window to witness vectors that the proof system can process in chronological order; (2) Constrain time-series features such as timestamp monotonicity, time interval and window granularity integrity in the zero-knowledge circuit (the above-mentioned time-series constraint circuit), and introduce range constraints or association constraints of multi-dimensional values ​​in an extensible manner; (3) Reconstruct the window commitment in the zero-knowledge circuit in a manner consistent with the logic of the off-chain hash chain, and force it to be equal to the window check value of the current time window in the public input, thereby ensuring that the off-chain time-series data is tamper-proof and the consistency between the off-chain commitment and the data being proved; (4) Only expose the adjacent window commitment, window time boundary and a small number of configuration parameters to the outside world, while hiding all time-series data and specific constraint details in the zero-knowledge proof.

[0083] 2. Timestamp anchoring algorithm.

[0084] Key points: The timestamp anchoring algorithm proposed in this application explicitly binds the real event time under the blockchain to the consensus-protected on-chain block time at the time window level. The system extracts the start and end times of each window that has completed time-series proof, along with the corresponding window verification value, the window verification value of the previous time window, and the proof digest, and constructs a window anchoring request to be submitted to the blockchain. After receiving the window anchoring request on the blockchain, the time anchoring contract reads the consensus timestamp of the current block and, combined with the on-chain record of the previous window, applies joint constraints on upload lag, window boundary continuity, and commitment chain continuity. Only when all constraints are satisfied is the current window written onto the chain, thus forming a time anchoring chain recursively based on the time window.

[0085] Protection Points: Protect the block timestamp anchoring method with time windows as the granularity, especially the combination of the following technical features: (1) Encapsulate the start and end times of each time window, the window verification value of the current time window, the window verification value of the previous time window, and the corresponding proof digest into a window anchoring request off-chain; (2) The on-chain time anchoring contract reads the current block timestamp and compares it with the window end time to check whether the lag between off-chain proof generation and on-chain confirmation falls within the preset threshold range, thereby preventing serious delays in uploading or retroactive recording; (3) By querying the on-chain anchor of the previous time window Record, compare the consistency between the window check value of the previous time window in the current window anchoring request and the on-chain anchoring record, and verify that there is no time backtracking, abnormal overlap or unexplained gap between the start time of the current window and the end time of the previous window, thereby constraining the continuity of cross-window time boundaries; (4) When the above checks pass, solidify the window check value of the current time window, the window check value of the previous time window, the window time boundary, the block timestamp and the proof summary into a new on-chain anchoring record. When the checks fail, reject or record the request in an abnormal state to provide evidence for subsequent audits.

[0086] 3. Overall framework and collaboration mechanism of time-series blockchain.

[0087] Key points: In terms of overall architecture, this application decouples off-chain time-series data slicing and commitment, time-series zero-knowledge proof generation, and blockchain timestamp anchoring into a layered and collaborative time-series blockchain framework. The bottom layer, consisting of a multi-source time-series data input and time window segmentation module, is responsible for slicing data according to a preset strategy and forming hash chain commitments. The middle layer, consisting of a time-series zero-knowledge proof module, generates simplified proofs of the time-series characteristics within each window and between adjacent windows without disclosing the original data. The upper layer, consisting of a time anchoring and blockchain notarization module, writes window commitments, time boundaries, and proof digests onto the chain and maintains a traceable time anchor chain through a timestamp anchoring algorithm. Compared to existing solutions that only record data hashes or log digests on the chain, this framework enables the blockchain to directly verify the authenticity, integrity, and cross-window continuity of multi-dimensional time-series data at the time window level without accessing the original data.

[0088] Protection Point: The overall technical solution and its workflow consist of a multi-source time-series data input module, a time window partitioning and commitment module, a time-series zero-knowledge proof module, and a time anchoring and blockchain evidence storage module, especially the layered collaborative mode of "off-chain time window slicing and commitment → time window-level time-series zero-knowledge proof → timestamp anchoring and on-chain evidence storage".

[0089] As disclosed above, this application embodiment sets up a time-series proof method for time-series data using "time-series zero-knowledge proof" + "block timestamp anchoring". Regarding "time-series zero-knowledge proof", it satisfies the following: "using a time window as the basic unit, encoding timestamp monotonicity and window granularity integrity within the proof system, and ensuring consistency between off-chain verification values ​​and circuit reconstruction verification values". In some embodiments, in generating the time-series proof information for the current time window, in addition to using a SNARK-based proof system, STARK, Bulletproof, a non-interactive zero-knowledge proof system based on the Sigma protocol, or other proof systems with completeness, zero-knowledge content, and high efficiency and verifiability can also be used. This embodiment does not limit the type of proof system. As long as the proof system can express the time-series constraints within the time window in the circuit and output compact time-series proof information suitable for on-chain processing, it can be considered an equivalent replacement for the proposed time-series zero-knowledge proof algorithm. In addition to the currently used hash chain / commitment structure, this embodiment can also employ Merkle trees, vector commitments, Pedersen commitments, multinomial commitments, or other cryptographic commitment schemes with equivalent concealment and binding properties for generating window checksums within a commitment time window. The commitment can be organized as a linear hash chain, a tree structure constructed by the window, or a hierarchical aggregation structure, as long as it can prove the integrity, order, and continuity of the data within the window without revealing the time-series data, and implement "commitment reconstruction and constraint equivalence" internally within the circuit. Therefore, this embodiment does not limit the method of generating window checksums.

[0090] Regarding "block timestamp anchoring", as long as the overall idea of ​​"using the blockchain time protected by consensus to calibrate the start and end times of the blockchain time window and detecting the continuity and anomalies between adjacent time windows" remains unchanged, there can be multiple alternatives for the method of obtaining the on-chain time source, the organization form of the anchored transaction, and the specific verification logic implementation. Therefore, this embodiment does not limit the implementation method of "block timestamp anchoring".

[0091] Specifically, regarding on-chain time sources, in addition to directly using the block timestamps of the target blockchain's main chain, sidechain or cross-chain time services, time oracle services jointly provided and written on-chain by multiple witness nodes, or timestamps issued by a trusted time server and then uploaded to the chain through transactions can also be used. As long as the time source is ultimately protected by the blockchain consensus process and can serve as a trusted benchmark for the on-chain time axis, it can be regarded as an equivalent time source selection in this application.

[0092] Regarding anchoring methods, in addition to submitting anchoring requests one at a time for each window, other methods include batch aggregating the proof digests and time boundaries of multiple time windows and submitting them uniformly, caching window records off-chain for a period of time and then submitting them periodically, or having off-chain relay / aggregation nodes uniformly package window records of multiple data channels and submit them. As long as an on-chain anchoring record containing "window start and end time, adjacent window commitment relationship, block timestamp or its derived time" can be ultimately formed on-chain, and time lag checks, cross-window boundary continuity checks and commitment chain continuity checks are completed in the contract or verification logic, it constitutes an equivalent implementation of the timestamp anchoring algorithm of this application.

[0093] Therefore, within the scope of protection of the embodiments of this application, any system or method that uses blockchain as a consensus-protected timeline and evidence storage infrastructure, uses time-series zero-knowledge proofs to characterize the temporal characteristics of multi-dimensional time-series data within and across windows, and further uses block timestamp anchoring algorithms to anchor the start and end times of the window and its proof digest to the blockchain timeline, thereby achieving verifiable evidence storage of the authenticity and temporal continuity of time-series data without disclosing the original data.

[0094] Please see Figure 11 This application also provides a time-series data storage device that can implement the above-described time-series data storage method. The device includes: The acquisition module 1101 is used to acquire time series data and determine the current time series characteristics of the time series data based on preset window configuration parameters; The time series proof construction module 1102 is used to construct the time series proof information of the current time window based on the current time series characteristics, the window verification value of the previous time window and the window configuration parameters, and to determine the window verification value of the current time window; wherein, the previous time window is the time window before the current time window; The request generation module 1103 is used to generate the current window anchoring request based on the time series proof information, the window verification value of the current time window, the window verification value of the previous time window, the current time series characteristics, and the window configuration parameters. The sending module 1104 is used to send the current window anchoring request to the blockchain, so that the blockchain can verify the current window anchoring request and receive the processing result returned by the blockchain after the verification is successful. Storage module 1105 is used to store time-series data to an off-chain storage medium if the processing result indicates successful anchoring.

[0095] The specific implementation of this time-series data storage device is basically the same as the specific embodiment of the time-series data storage method described above, and will not be repeated here.

[0096] This application also provides a blockchain system, comprising at least one data node and a blockchain, wherein the data node and the blockchain implement the aforementioned time-series data storage method. The data node can be any smart terminal, including tablet computers, in-vehicle computers, etc.

[0097] This application also provides a computer-readable storage medium storing a computer program that, when executed by a processor, implements the above-described timing data storage method.

[0098] Memory, as a non-transitory computer-readable storage medium, can be used to store non-transitory software programs and non-transitory computer-executable programs. Furthermore, memory may include high-speed random access memory, and may also include non-transitory memory, such as at least one disk storage device, flash memory device, or other non-transitory solid-state storage device. In some embodiments, memory may optionally include memory remotely located relative to the processor, and these remote memories can be connected to the processor via a network. Examples of such networks include, but are not limited to, the Internet, intranets, local area networks, mobile communication networks, and combinations thereof.

[0099] The embodiments described in this application are for the purpose of more clearly illustrating the technical solutions of the embodiments of this application, and do not constitute a limitation on the technical solutions provided by the embodiments of this application. As those skilled in the art will know, with the evolution of technology and the emergence of new application scenarios, the technical solutions provided by the embodiments of this application are also applicable to similar technical problems.

[0100] Those skilled in the art will understand that the technical solutions shown in the figures do not constitute a limitation on the embodiments of this application, and may include more or fewer steps than shown, or combine certain steps, or different steps.

[0101] The device embodiments described above are merely illustrative. The units described as separate components may or may not be physically separate; that is, they may be located in one place or distributed across multiple network units. Some or all of the modules can be selected to achieve the purpose of this embodiment according to actual needs.

[0102] Those skilled in the art will understand that all or some of the steps in the methods disclosed above, as well as the functional modules / units in the systems and devices, can be implemented as software, firmware, hardware, or appropriate combinations thereof.

[0103] The terms “first,” “second,” “third,” “fourth,” etc. (if present) in the specification and accompanying drawings of this application are used to distinguish similar objects and are not necessarily used to describe a specific order or sequence. It should be understood that such data can be interchanged where appropriate so that the embodiments of this application described herein can be implemented in orders other than those illustrated or described herein. Furthermore, the terms “comprising” and “having,” and any variations thereof, are intended to cover non-exclusive inclusion; for example, a process, method, system, product, or apparatus that comprises a series of steps or units is not necessarily limited to those steps or units explicitly listed, but may include other steps or units not explicitly listed or inherent to such processes, methods, products, or apparatus.

[0104] It should be understood that in this application, "at least one (item)" means one or more, and "more than" means two or more. "And / or" is used to describe the relationship between related objects, indicating that three relationships can exist. For example, "A and / or B" can represent three cases: only A exists, only B exists, and both A and B exist simultaneously, where A and B can be singular or plural. The character " / " generally indicates that the preceding and following related objects are in an "or" relationship. "At least one (item) of the following" or similar expressions refer to any combination of these items, including any combination of single or plural items. For example, at least one (item) of a, b, or c can represent: a, b, c, "a and b", "a and c", "b and c", or "a and b and c", where a, b, and c can be single or multiple.

[0105] In the several embodiments provided in this application, it should be understood that the disclosed apparatus and methods can be implemented in other ways. For example, the apparatus embodiments described above are merely illustrative; for instance, the division of the units described above is only a logical functional division, and in actual implementation, there may be other division methods. For example, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. Furthermore, the coupling or direct coupling or communication connection shown or discussed may be through some interfaces; the indirect coupling or communication connection between apparatuses or units may be electrical, mechanical, or other forms.

[0106] The units described above as separate components may or may not be physically separate. The components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the units can be selected to achieve the purpose of this embodiment according to actual needs.

[0107] Furthermore, the functional units in the various embodiments of this application can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit. The integrated unit can be implemented in hardware or as a software functional unit.

[0108] If the integrated unit is implemented as a software functional unit and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, or all or part of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes multiple instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the steps of the methods of the various embodiments of this application. The aforementioned storage medium includes various media capable of storing programs, such as USB flash drives, portable hard drives, read-only memory (ROM), random access memory (RAM), magnetic disks, or optical disks.

[0109] The preferred embodiments of the present application have been described above with reference to the accompanying drawings, but this does not limit the scope of the claims of the present application. Any modifications, equivalent substitutions, and improvements made by those skilled in the art without departing from the scope and substance of the embodiments of the present application shall be within the scope of the claims of the present application.

Claims

1. A time-series data storage method, characterized in that, The method is executed by data nodes in a blockchain system, the data nodes being communicatively connected to the blockchain, and the method includes: Acquire time-series data and determine the current time-series characteristics of the time-series data based on preset window configuration parameters; Based on the current time series characteristics, the window verification value of the previous time window, and the window configuration parameters, the time series proof information of the current time window is constructed, and the window verification value of the current time window is determined; wherein, the previous time window is the time window preceding the current time window; The current window anchoring request is generated based on the time series proof information, the window verification value of the current time window, the window verification value of the previous time window, the current time series characteristics, and the window configuration parameters. The current window anchoring request is sent to the blockchain, so that the blockchain verifies the current window anchoring request and receives the processing result returned by the blockchain after the verification is successful. If the processing result indicates successful anchoring, the time-series data is stored in the off-chain storage medium.

2. The method according to claim 1, characterized in that, The construction of the time series proof information for the current time window based on the current time series characteristics, the window check value of the previous time window, and the window configuration parameters includes: The current time-series features are encoded to obtain the current time-series encoded data; A hash operation is performed on the current time-series encoded data and the window check value of the previous time window to obtain a preliminary window check value; Based on the preset timing constraint information, the current timing encoded data is used as the object to be proved, and the current timing features are constrained and verified in combination with the window configuration parameters. During the constraint verification process, the hash operation is reconstructed in the proof-side circuit to obtain the window verification value of the current time window, and the window verification value of the current time window is forced to be consistent with the initial window verification value to obtain the timing constraint verification result. The timing proof information for the current time window is generated based on the timing constraint verification results.

3. The method according to claim 2, characterized in that, The process involves using the current time-series encoded data as the object to be proven, based on preset time-series constraint information, and performing constraint verification on the current time-series features in conjunction with the window configuration parameters. During the constraint verification process, a hash operation is reconstructed within the proof-side circuit to obtain the window verification value of the current time window, and the window verification value of the current time window is forced to be consistent with the initial window verification value, thus obtaining the time-series constraint verification result. This includes: Within the proof-side circuit, based on the window check value of the previous time window, the current time-series encoded data, and the hash operation rule that the initial window check value is consistent, the current time-series encoded data is iteratively hashed and reconstructed to obtain the window check value of the current time window. A consistency constraint is applied to the window check value of the current time window and the initial window check value to obtain the time-series constraint verification result.

4. The method according to any one of claims 1 to 3, characterized in that, The step of acquiring time-series data and determining the current time-series characteristics of the time-series data based on preset window configuration parameters includes: Obtain the time series data; The time-series data is stored in a buffer, and the data storage information of the buffer is collected; If the data storage information meets the preset window conditions, obtain the current time window of the time series data in the buffer; The time series data is subjected to time series feature extraction based on the current time window and the window configuration parameters to obtain the current time series features.

5. A time-series data storage method, characterized in that, The method is executed by a blockchain, which is communicatively connected to data nodes, and the method includes: Receive a current window anchoring request sent by a data node; wherein the current window anchoring request is obtained by the time-series data storage method according to any one of claims 1 to 4; Obtain the reference timing information of the current block based on the current window anchoring request; The current window anchoring request is verified based on the reference timing information to obtain request verification information; If the request verification information indicates that the current window anchoring request has been verified, the current window anchoring request is solidified as an on-chain anchoring record for the current time window, and the on-chain anchoring record is stored in the current block.

6. The method according to claim 5, characterized in that, The reference timing information includes: the current block timestamp information and the on-chain anchoring record of the previous time window; The step of verifying the current window anchoring request based on the reference timing information to obtain request verification information includes: The current window anchoring request is parsed to obtain the current time series parsing information; wherein, the current time series parsing information includes: current time series features, window check value of the current time window and window check value of the previous time window; Based on the current block timestamp information, the current time series feature is time series verified to obtain time series verification information; The window verification values ​​of the current time window and the previous time window are verified based on the on-chain anchoring record of the previous time window to obtain verification value verification information. The request verification information is determined based on the timing verification information and the check value verification information.

7. The method according to claim 5, characterized in that, After verifying the current window anchoring request based on the reference timing information to obtain request verification information, the method further includes: If the request verification information indicates that the current window anchoring request verification failed, abnormal window anchoring information is generated based on the current window anchoring request; The current window anchoring request is rolled back based on the abnormal window anchoring information.

8. A time-series data storage device, characterized in that, The time-series data storage device is located in the data nodes of the blockchain system, and the device includes: The acquisition module is used to acquire time series data and determine the current time series characteristics of the time series data based on preset window configuration parameters; The timing proof construction module is used to construct the timing proof information of the current time window based on the current timing features, the window verification value of the previous time window, and the window configuration parameters, and to determine the window verification value of the current time window; wherein, the previous time window is the time window before the current time window; The request generation module is used to generate a current window anchoring request based on the time series proof information, the window verification value of the current time window, the window verification value of the previous time window, the current time series characteristics, and the window configuration parameters. The sending module is used to send the current window anchoring request to the blockchain, so that the blockchain verifies the current window anchoring request and receives the processing result returned by the blockchain after the verification is successful. A storage module is used to store the time-series data to an off-chain storage medium if the processing result indicates successful anchoring.

9. A blockchain system, characterized in that, The blockchain system includes: at least one data node and a blockchain, wherein the data node performs the time-series data storage method as described in any one of claims 1 to 4, and the blockchain performs the time-series data storage method as described in any one of claims 5 to 7.

10. A computer-readable storage medium storing a computer program, characterized in that, When the computer program is executed by the processor, it implements the time-series data storage method according to any one of claims 1 to 4, or the time-series data storage method according to any one of claims 5 to 7.

Images