## 5 Spatio-Temporal Big Data Collaborative Storage Mechanism
### Scheme Description  
In this section, we propose the design of an on-chain and off-chain collaborative storage scheme based on the construction of incrementally aggregatable subvector commitments. Define the signature \(\delta:=((U,C),n),U=g^{\prod_{i\in[n]}e_{i}}\), progressive construction of \(U\) as the value of the RSA accumulator when expanding or reducing the records, \(S_{I}=g^{\prod_{i\in[n]\setminus t}e_{i}}\) as the witness of accumulator, commitment C, state \(st:=\pi_{I}\), where \(\pi_{I}:=(S_{I},\Lambda_{I})\), for each \(e_{i}\) can be generated by the prime generation algorithm, e.g., \(e_{i}\gets PrimeGen(i)\). For all \(J\subseteq I\), anyone who has possession of \(S_{I}\) can be able to compute \(S_{I}\gets S_{I}\prod_{j\in I\cup J}e_{j}\). Setup phase: given the security parameter \(K\), create a group with the hidden order \(G\gets Ggen(1^{\lambda})\) and sample a generator \(g\overset{\delta}{\leftarrow}G\). It defines a deterministic collision-resistant function, \(PrimeGen\), which maps integers to prime numbers of \(L+1\) bits. Set original signature \(\delta_{0}\leftarrow((1,g),n_{0}),n_{0}\gets 0\), states\(t_{0}\gets g\) (All algorithms implicitly accept the public parameter as input). Creating Parameters \(pp\) and Initial Commitments for Empty records in an Off-Chain Storage Server \(C\gets VC.Com(),pp:=(G,g,PrimeGen)\), Use this function to compute aggregate auxiliary proof information \(S_{I}\). Query phase: the data verifier sends the index set Q of the query location to the off-chain storage server and queries the blockchain to get the signature \(\delta\) and computes  
\[S_{Q}\gets S_{I}^{\prod_{i\in[n]\setminus Q}e_{i}} \tag{6}\]  
If the data set index \(Q\) to be queried is a subset of the previously computed proof \(I\) in the off-chain storage server, i.e., \(Q\subseteq I\), the proof \(\Lambda_{I}\) is disaggregated, \(\Lambda_{Q}\gets VC.Disagg(S_{Q},I,V_{I},A_{I},Q)\). Otherwise, the aggregated proof protocol needs to be executed to generate the location proof \(\Lambda_{Q}\) and return it to the data verifier. Verification phase: the data verifier runs the commitment verification algorithm based on obtaining the current latest signature \(\delta_{n}\) and proof \(\pi_{Q}\) from the blockchain, and data \(V_{Q}\) returned from the off-chain storage server:  
\[b\gets VC.Ver(pp,C,Q,V_{Q},\Lambda_{I})\wedge(S_{Q}^{\prod_{i\in Q}e_{i}} =U) \tag{7}\]  
If \(b=1\), it means that data \(V_{Q}\) are valid. Update phase: mainly divided into modification, insertion, and deletion operations. The data owner provides operation \(op=(mod,add,del)\) to update data \(\Delta=(K,V_{K})\). Firstly, it determines whether \(K\) is a subset of \(I\). If not, it is necessary to calculate \(S_{K}\), \(e_{i}\gets PrimeGen(i)\), and \(S_{K}=g\prod_{i\in[n]\setminus K}e_{i}\), \(i\in K\) that need to be uploaded by data initialization, and the blockchain runs a smart contract to verify whether \(s_{K}\) is legal or not, i.e., \(b\gets(S_{K}^{\prod_{i\in K}e_{i}}=U)\). Then, the data owner transmits the updated data to the off-chain storage server, and updates the database data. There are the following operations depending on the update form:  
* Modify:\(op=mod\), \(\Delta:=(K,V_{K}^{\prime})\) \[C^{\prime}\gets C\cdot\prod_{i\in K}S_{i}^{V_{i}^{\prime}-V_{i}}\] (8) Updating other supporting information \(U^{\prime}\gets U,\Lambda_{I}^{\prime}\leftarrow\Lambda_{I},n^{\prime} \gets n,S_{K}^{\prime}\gets S_{K},Y_{\Delta}\leftarrow(V_{K},S_{K})\).