# Secure and Transparent Space Exploration Data Management Using a Hybrid Blockchain Model
## 4 Implementation and Experimental Analysis
### Performance Evaluation and Discussion  
Aggregating the outcomes of the above experiments, we observe that the hybrid blockchain-based system successfully meets the primary objectives of secure and transparent data management, albeit with some performance overhead. The selection of blockchain consensus algorithms directly affects network performance, transaction latency, and throughput, which are critical for real-time space mission data management [20]. The hybrid system provides security and data integrity assurances superior to the traditional centralized approach. All data writes to the blockchain are tamper-evident, and even cross-organizational data remain trustworthy due to the public audit trail. Our experiments confirmed that any attempts to modify data are quickly detected through hash comparisons or ZKP verification. Furthermore, the use of smart contracts for access control proved effective in strictly protecting confidential data--unauthorized parties could not bypass the system to retrieve sensitive information. In terms of performance, the trade-off is clear--the blockchain-based solution is slower in transaction throughput and data retrieval rate compared to a classical database. To identify these potential bottlenecks, a comprehensive performance evaluation methodology is essential [21]. For instance, reading data via Ethereum calls was on the order of a few hundred QPS, far below a database's capacity. Writing datasets to a public blockchain \begin{table}
\begin{tabular}{l c c} \hline \hline
**Evaluation Metric** & **Oracle-Based Method** &
\begin{tabular}{c} **CCIP-Based Method** \\ **(Proposed)** \\ \end{tabular} \\ \hline Avg. Synchronization Delay & 15–30 s & 1–2 s \\ \hline Decentralization Level & 1 Node (Centralized) & 3 or more Nodes (Distributed) \\ \hline Security (Integrity Check) & Single verification & Triple verification \\ \hline Failure Rate (Reliability) & 1–3\% & less than 0.5\% \\ \hline Computational Overhead & 50–100 ms per verification & 100–250 ms per verification \\ \hline \hline \end{tabular}
\end{table} 
Table 4: Performance comparison of Oracle-based and CCIP-based integration methods. Figure 3: Synchronization ZKP verification performance comparison: hash-based vs. ZKP-based verification methods. is several orders of magnitude slower than inserting them into a traditional database. This performance disparity is primarily due to the additional computational overhead associated with the blockchain's consensus mechanisms and cryptographic processes [22] and indicates that for extremely data-intensive operations, the current form of our hybrid blockchain might become a bottleneck. However, many space mission data scenarios occur at a manageable frequency, and batch processing or layer-2 scaling solutions [23] could be employed to raise throughput if needed. Specifically, optimistic rollups could be adopted to aggregate multiple transactions off-chain and only submit proofs to the blockchain, significantly increasing throughput. Alternatively, zero-knowledge rollups could provide scalability with strong cryptographic guarantees while maintaining the integrity of the data across chains. These layer-2 solutions would be particularly effective for handling periods of intensive data generation during space missions. The strengths of the hybrid model lie in its trust model and resilience. Even if one participating organization's systems are compromised, the blockchain's distributed nature means the data history is still safe and verifiable elsewhere. Additionally, by using the public blockchain as a referee of sorts, we eliminate the need for blind trust between agencies--the system itself enforces honesty. This is a substantial improvement over purely centralized or even purely private consortium approaches, where subtle data manipulations might go unnoticed or disputes might be hard to resolve without a neutral ledger. Another observation is that the overhead of ZKP did not severely impede our use case. We were able to incorporate it effectively.