## 5 Spatio-Temporal Big Data Collaborative Storage Mechanism
### Aggregation Proof Protocol
At all data block sizes, the time required for Query1 is noticeably higher than that for Query2 and the verification operation. Especially when there are many data blocks, the time required is far higher than the other two operations. This indicates that when the query location \(Q\cap I=\varnothing\), when the positions involved in the query need to run the aggregation algorithm, the processing time significantly increases, suggesting that the aggregation

Figure 4: Comparison chart of verification and query experimental results. Figure 3: Comparison result of communication overhead of different schemes. algorithm may be more computationally complex. Therefore, we divide the aggregation algorithm into two parts: one that runs on-chain and another that runs off-chain. In the experimental analysis of data updates within the scheme, we categorized updates into modifications, insertions, and deletions. As shown in Figure 5, modifications do not require updates to the accumulator, thereby saving a significant amount of time, making the cost of modification operations the lowest. However, insertions and deletions involve updates to the accumulator, leading to relatively higher costs. Additionally, since deletion operations require updates to the proofs, they incur the highest costs, followed by insertions. This distinction in cost reflects the computational overhead associated with managing the completeness and uniformity of the data when the underlying structure of the dataset changes. ### On-Chain Overhead

In the scheme proposed in this chapter, the on-chain operations within the blockchain primarily involve signature verification and the execution of parts of the aggregation algorithm by smart contracts. The smart contracts mainly execute a portion of the aggregation algorithm proposed in this scheme, specifically utilizing the ShamirTrick to generate auxiliary proof information. To simulate the conditions of a real blockchain network for testing and developing smart contracts, the experiments deploy the smart contracts using the JavaScript VM environment in the Remix compiler. The deployment time for smart contracts using Remix is approximately 2 seconds. This setup allows for an efficient and realistic testing environment, aiding in the optimization of the smart contracts before they are deployed on an actual blockchain network. Given the limited count of nodes in the test network, the mining difficulty is relatively low, which allows for faster block generation speeds. However, in real-world application scenarios, as the count of nodes participating in the network rises, maintaining a low mining difficulty could lead to the production of too many blocks at the same time, potentially causing congestion in network transactions. Therefore, the average block time on the Ethereum mainnet is currently stabilized at around 12 seconds. To comprehensively evaluate the performance of the smart contracts in this setup, we used the Caliper tool to conduct detailed tests on the verification and aggregation functions within the smart contracts. Each function was independently tested 400 times to accurately measure various performance metrics, including sending rate, maximum delay, minimum

Figure 5: Comparison chart of updated experimental results. delay, average delay, and throughput, as shown in Table 2. These tests confirmed that both verification and aggregation operations can be executed successfully, with verification operations being more efficient than aggregation operations. This efficiency difference is crucial for optimizing blockchain performance, especially in environments where rapid transaction processing is required. Improving the efficiency of verification operations can significantly enhance system responsiveness, while optimizing aggregation operations can further boost the overall performance of the system in handling complex data tasks.