Secure and Transparent Space Exploration Data Management Using a Hybrid Blockchain Model

Abstract

This study proposes a hybrid blockchain system for secure and transparent data management in multinational space missions. By combining public and private blockchains, the model enables open access to non-sensitive data while protecting confidential mission records. Data integrity is ensured through cryptographic proofs without exposing the underlying content, and a cross-chain protocol enables real-time synchronization between chains without relying on centralized intermediaries. The system was implemented using Ethereum and Hyperledger Fabric and tested with real extravehicular activity data. Results show that it effectively detects data tampering, enforces access control, and synchronizes records with low latency. Compared to traditional centralized systems, this approach offers improved resilience, auditability, and trust across organizations. It provides a practical foundation for future space data infrastructures requiring both transparency and confidentiality.

1. Introduction

The rapid advancement of space exploration has led to increased international collaboration among space agencies, research institutions, and private enterprises. Countries such as the United States, Russia, China, and member states of the European Space Agency frequently conduct joint missions, technology exchanges, and collaborative research projects. However, managing and securing space-related data across multiple organizations. Involving multiple organizations presents serious challenges in terms of integrity, transparency, and confidentiality. Traditional space data management systems rely heavily on centralized infrastructures, which are prone to single points of failure, unauthorized access, and data tampering risks pose risks such as data tampering, unauthorized access, and single points of failure. As data sensitivity grows—covering astronaut activity records, spacecraft diagnostics, and extraterrestrial observations—trust in data handling mechanisms becomes a mission-critical requirement.

Blockchain technology [1] provides a decentralized alternative, enabling transparent and tamper-resistant record-keeping provides a decentralized approach to data management, ensuring integrity and transparency. Moreover, such technologies have shown promise in enhancing cybersecurity [2] and securing inter-agency data transactions. Yet, public blockchains are often unsuitable for sensitive data due to their transparency and performance limitations. However, a fully public blockchain system is not suitable for storing confidential or mission-critical data due to privacy concerns and high computational costs. In contrast, private blockchains [3] offer controlled access but lack global verifiability, transparency, and inter-organizational verification mechanisms. This leads to a trade-off between privacy and transparency, which is especially pronounced in multinational space missions.

To overcome this, we propose a hybrid blockchain architecture [4] that integrates the benefits of both public and private blockchains. Recent studies have demonstrated the applicability of hybrid blockchain models for secure and privacy-preserving applications across various domains, such as vehicular networks [5] and decentralized file storage systems utilizing Soulbound tokens [6]. These works highlight the increasing relevance and versatility of hybrid blockchain architectures in addressing both transparency and confidentiality challenges. In this model, non-sensitive data—such as mission logs—are stored on a public blockchain [7], enabling universal access and verification. Sensitive data are retained within a private blockchain, protected via cryptographic access control mechanisms. Data integrity is guaranteed using zero-knowledge proofs [8], allowing verifiers to confirm authenticity without exposing private content. Among various ZKP techniques, zk-SNARKs are particularly suitable due to their succinct proof size and efficient on-chain verification [9].

To ensure interoperability and near-real-time consistency across chains, the system employs the Cross-Chain Interoperability Protocol [10], which supports event-driven communication between smart contracts deployed on separate blockchains. This method avoids reliance on centralized oracles [11] and ensures secure synchronization. Smart contracts [12] enforce access control policies through a role-based access control model, allowing only authorized roles to retrieve sensitive data.

This paper presents a practical implementation of the proposed architecture using Ethereum and Hyperledger Fabric. The model was validated through a case study involving extravehicular activity data from NASA and Roscosmos. The system demonstrated high integrity verification, strong access control, and feasible synchronization performance. As international collaboration in space exploration intensifies, this approach provides a foundational framework for trustworthy, decentralized, and auditable data management in cross-agency missions.

2. Related Work

2.1. Hybrid Blockchain

A hybrid blockchain combines the advantages of both public and private blockchains, balancing data accessibility and security. Publicly accessible data are stored on the public blockchain to ensure transparency and verifiability, while confidential data are secured on the private blockchain. The use of ZKP techniques ensures data integrity without exposing sensitive information.

2.2. Related Paper

NASA (2018) proposed the use of public blockchain technology to enhance the security of space communications, emphasizing its potential to guarantee data immutability and traceability in space exploration missions [13]. Public blockchain-based frameworks can significantly improve inter-organizational trust by ensuring tamper-proof data storage and auditability. However, this approach presents notable limitations when dealing with sensitive space mission data due to privacy concerns and the computational overhead associated with consensus mechanisms, which makes real-time processing of large datasets inefficient. Similar challenges have been observed in the healthcare sector, where blockchain-based models have been applied to enable the secure sharing of electronic health records (EHRs). In these cases, maintaining both data confidentiality and reliability is considered a critical concern [14]. In response to these limitations, our study adopts a hybrid blockchain architecture that integrates the transparency of public blockchains with the access control and confidentiality of private blockchains, achieving a balanced solution between data integrity, privacy, and operational efficiency.

The study titled “Private Blockchain Solutions for Aerospace Data Integrity” (2022) investigated the application of private blockchains to ensure the integrity of aerospace data [15]. The authors emphasized that private blockchains offer advantages such as controlled access and low-latency processing, making them suitable for handling sensitive and high-frequency data. However, the research also pointed out inherent limitations, particularly the lack of decentralization and external auditability, which may undermine inter-organizational trust and data reliability. In response to these limitations, our proposed hybrid blockchain model aims to preserve the benefits of private blockchains while incorporating public chain elements to enhance transparency and cross-institutional verifiability.

Recent advancements in zero-knowledge proofs have extended their applicability to resource-constrained environments such as data streams, allowing verification of computational integrity without revealing the actual content. For instance, research by Chakrabarti et al. (2023) [16] introduced streaming zero-knowledge interactive proofs that enable low-memory verification of large-scale data computations in a privacy-preserving manner. While the study focuses primarily on generic streaming data settings, it highlights the potential for scalable and efficient ZKP implementations in domains where memory and communication costs are critical—such as space exploration missions. Building upon this foundation, our research embeds ZKPs within a hybrid blockchain framework and validates their practicality by applying them to real extravehicular activity datasets. The results demonstrate that ZKP-based verification not only preserves data confidentiality but also achieves feasible performance in realistic mission scenarios.

3. Proposed Model

3.1. Hybrid Blockchain Data Storage Strategy

In the hybrid model, all mission data are classified as either public data or private data based on their sensitivity level. Public data includes information such as mission logs and general scientific findings, which can be accessed by all users and are directly stored on the public blockchain, allowing anyone to verify them. Due to the high storage cost of directly writing data to the blockchain, only the cryptographic hash of the original data is stored on-chain. A smart contract is used to encapsulate the hash value and relevant metadata, and users can call the smart contract to retrieve the metadata and verify the integrity of the data via hash comparison. Private data, on the other hand, includes confidential records such as astronaut medical histories or proprietary mission strategies, which are stored on a permissioned blockchain to restrict access and maintain confidentiality.

To achieve this, the proposed system adopts a layered architecture that separates the public and private domains while maintaining secure interoperability. Public blockchain components, such as the Ethereum Linea Testnet, are leveraged for their transparency and auditability features, ensuring that all public information remains tamper-evident and verifiable. Private blockchain components, specifically Hyperledger Fabric, are used due to their modular architecture and fine-grained access control capabilities. Hyperledger Fabric’s support for permissioned membership and its use of the Practical Byzantine Fault Tolerance consensus algorithm enables low-latency transactions and enhanced control over user roles and permissions.

The two blockchain environments are synchronized via a dedicated interoperability layer powered by Chainlink’s cross-chain interoperability protocol. CCIP enables real-time, event-driven data synchronization by allowing signed and authenticated messages to be transferred between the chains. This ensures that when a change occurs on the private blockchain, the corresponding integrity proof is securely and automatically relayed to the public chain without disclosing the raw data itself. By replacing traditional centralized oracles with CCIP, the system avoids single points of failure and ensures decentralized validation of cross-chain interactions. The overall architecture and performance summary are presented in

Table 1. Comparison of blockchain types based on key characteristics.

Feature	Public Blockchain	Private Blockchain	Hybrid Blockchain
Access Control	Everyone	Authorized users	Public data are accessible to all, private data are restricted to authorized users
Governance	Fully decentralized	Centralized	Hybrid model
Transparency	Publicly visible	Transactions are only visible within the organization	Public data are open, private data remains protected
Security	High integrity due to distributed storage, but low confidentiality	High confidentiality due to restricted access, but potential trust issues	Combines the security advantages of both public and private blockchains to ensure integrity and confidentiality
Data Integrity	Strong immutability ensured by blockchain consensus	Integrity is guaranteed within the organization, but not publicly verifiable	Uses ZKP on the public blockchain to ensure data integrity without exposing sensitive data

. And Figure 1 shows a hybrid blockchain model where each country stores sensitive data on a private blockchain and shares verified public data through a public blockchain. Zero-knowledge proofs are used to ensure data integrity without exposing the actual content.

3.2. Data Integrity Verification Using Zero-Knowledge Proofs

The process of proving data integrity consists of two main stages: Data Registration and Data Verification. In the data registration stage, the raw data generated during the exploration is collected, and a cryptographic hash function is applied to the original data D to generate a hash value $H\left(D\right)$. Then, a zero-knowledge proof algorithm is applied to $H\left(D\right)$ to generate a cryptographic proof $\pi \left(D\right)$. The generated ZKP proof is published on the public blockchain without disclosing the actual data D.

To verify the integrity of private data later, the system retrieves the data from the private blockchain and re-computes the hash and ZKP proof. It then compares these with the originally published hash and proof using a verification smart contract. If the hashes and ZKPs match, it confirms that the data have not been altered. This process ensures that verifiers can confirm data integrity without accessing the underlying sensitive data, thus preserving confidentiality.

ZKP algorithm selection and overhead:

In our implementation, we adopt zk-SNARKs, short for zero-knowledge succinct non-interactive argument of knowledge, which provide efficient and compact proof sizes suitable for blockchain environments. zk-SNARKs allow for fast on-chain verification with minimal gas costs and do not require interaction between the prover and verifier. While zk-STARKs offer post-quantum security and transparency, they generally incur higher proof sizes and computation time, which are less optimal for current smart contract deployment. Therefore, zk-SNARKs were chosen to balance efficiency and practicality.

The computational overhead for generating a zk-SNARK proof for a single data record was approximately 0.6–0.8 s in our tests, while on-chain verification time was under 0.1 s. This performance is sufficient for periodic integrity verification and aligns with the resource constraints of typical space communication systems. For the implementation of zk-SNARK proofs, we employed the Circom and SnarkJS toolchain, which are widely used frameworks for generating and verifying zero-knowledge proofs. The system setup required a trusted setup phase, which involved the generation of a common reference string to ensure the validity of the proofs without revealing sensitive data. Parameters were configured to balance proof size and generation time, optimizing for efficient on-chain verification.

Verification flow summary:

• Data D is hashed: $H\left(D\right)$.
• A ZKP proof $\pi \left(D\right)$ is generated using zk-SNARK algorithms.
• The hash and proof are stored on the public blockchain.
• When verification is needed, a new hash $H^{\prime }\left(D\right)$ and proof ${\pi }^{\prime }\left(D\right)$ are generated and compared with stored values.
• A smart contract accepts or rejects the data integrity based on the result.

This architecture allows secure, trustless verification of private data integrity while maintaining performance and scalability.

3.3. Public and Private Data Access Control

To maintain both transparency and confidentiality, our system separates data access pathways based on data sensitivity. Public data, such as mission logs or general telemetry, is stored on the public blockchain and is accessible to all users. Users can retrieve data integrity proofs from the public blockchain and validate them independently via smart contracts without restrictions.

In contrast, private data—such as astronaut health records or mission-critical configurations—is stored on the private blockchain with strict access controls. We implement a role-based access control system to manage authorization. Under RBAC, users are assigned specific roles, and each role is granted a defined set of permissions. Access to private data is permitted only if the requester’s role matches the access policy defined for that data category.

Access control is enforced using smart contracts deployed on the private blockchain. Each access request triggers a chaincode invocation, during which the user’s identity and role are verified using the Membership Service Provider. The access control logic checks the user’s role against the required permission level before authorizing data retrieval.

Example Access Logic:

-

If a user requests data labeled as "eva_log_secure", the smart contract verifies:

-

Is the user’s role in {MissionCommander, EVAController}?

-

Has the user’s identity been cryptographically validated via X.509 certificates?

-

If so, grant access and log the event; otherwise, deny access.

This approach ensures that only authorized personnel can access sensitive information while keeping audit logs for traceability. All successful and failed attempts are recorded in the Fabric ledger for post-mission audit analysis.

Additionally, we store only cryptographic proofs for private data on the public blockchain. This enables third-party auditors to verify data integrity without accessing the actual content, preserving confidentiality while ensuring transparency.

3.4. Limitations of Existing Oracle-Based Integration Methods

Prior approaches to connecting public and private blockchains have primarily relied on oracle mechanisms, which act as external data relays to feed verified off-chain or private-chain data into smart contracts. However, this approach presents several technical limitations.

First, traditional oracles are often centralized, operating through a single trusted data provider. This contradicts the decentralized trust model of blockchain systems and introduces a single point of failure. Furthermore, validating the authenticity of oracle-fed data is non-trivial, as malicious actors can manipulate or delay data delivery. These risks undermine the security guarantees that blockchain is intended to provide.

Another limitation is related to data synchronization latency. Oracle-based systems typically require polling or manual triggers to initiate data transfer, which adds verification time. This results in delayed updates between private and public chains, a critical issue for real-time applications such as mission control systems or space telemetry synchronization.

To address these challenges, we adopt the cross-chain interoperability protocol, developed by Chainlink. CCIP is a decentralized messaging protocol that supports event-driven, smart contract-based communication between heterogeneous blockchain networks. Rather than relying on a polling model, CCIP allows the private blockchain to generate a signed message containing a data hash whenever new information is recorded. This message is then automatically transmitted to the public blockchain, where it is verified using on-chain logic. To ensure the integrity and authenticity of cross-chain messages transmitted via CCIP, each message is digitally signed by the sending smart contract and verified by the receiving contract before acceptance. This signature verification ensures that messages cannot be forged or tampered with during transmission. Furthermore, Merkle proofs can optionally be embedded within CCIP payloads to provide compact verifiable evidence of data inclusion in a block, further enhancing trust in message validity. This design aligns with recent proposals on trustless cross-chain communication protocols for secure blockchain interoperability [17].

This method improves both reliability and speed. While public blockchains such as Ethereum typically require 12–15 s for block confirmation, private blockchains using Practical Byzantine Fault Tolerance consensus can achieve sub-second finality. CCIP bridges these systems by enabling near-instantaneous data consistency between chains without sacrificing decentralization or auditability.

By employing CCIP, the proposed model eliminates the bottlenecks associated with traditional oracles and ensures secure, real-time synchronization of critical data across blockchain layers.

4. Implementation and Experimental Analysis

4.1. Implementation Environment

To verify the effectiveness of the hybrid blockchain-based space exploration data management model, an experimental environment was established, and performance was evaluated. The spacewalk dataset used in this study was obtained from NASA’s public data portal, containing extravehicular activity data from the United States and Russia [18]. These data entries served as representative records for testing both public and private data handling within the proposed architecture.

The public blockchain component was implemented using the Ethereum Linea Testnet. Ethereum was selected due to its robust smart contract ecosystem and its compatibility with zero-knowledge proof frameworks. Linea Testnet, in particular, supports zkEVM operations, enabling cost-effective validation of cryptographic proofs on-chain. It ensures transparency and verifiability for non-sensitive mission data.

For the private blockchain, we adopted Hyperledger Fabric, a permissioned blockchain platform designed for enterprise-grade data management. Hyperledger Fabric offers modular components, fine-grained access control policies, and a Practical Byzantine Fault Tolerance consensus algorithm, allowing for high-speed, low-latency transaction processing. This makes it suitable for managing sensitive data, such as astronaut health logs and proprietary mission protocols, with strict confidentiality.

To enable interoperability between the two blockchains, we employed Chainlink’s Cross-Chain Interoperability Protocol. Unlike traditional oracle-based systems that depend on a centralized data relay, CCIP enables secure, event-driven cross-chain communication through smart contracts. It provides cryptographic assurances for message delivery and minimizes synchronization delays, ensuring real-time propagation of integrity proofs such as hashes and ZKPs between chains.

The smart contracts used in this implementation were written in Solidity and deployed using Remix IDE and Truffle. Ethereum nodes were emulated using Ganache for development and testing, while the Hyperledger Fabric environment was constructed using Docker containers to simulate a multi-organization network with role-based permissions and certificate-based identity verification.

This configuration allowed us to assess the system’s behavior in terms of data integrity, access control, and performance under a realistic yet controlled experimental setup. The implementation environment, including blockchain platforms, development tools, and node configurations, is summarized in

Table 2. Implementation environment of a hybrid blockchain system.

Category	Details
Public Blockchain	Linea Testnet
Private Blockchain	Hyperledger Fabric [19]
Blockchain Interconnection	Oraclize and Chainlink
Smart Contracts	Solidity-based smart contracts
Node Configuration	3 Ethereum full nodes, 2 Hyperledger Fabric peer nodes
Development & Testing Tools	Remix IDE, Truffle, Ganache, Docker-based Hyperledger Fabric

.

4.2. Experiment Scenarios

We devised four main experiment scenarios to validate whether the hybrid blockchain system meets its goals of ensuring data integrity, security, and overall performance. These scenarios were designed around a realistic data pipeline involving actual extravehicular activity data.

In our implementation, EVA mission data were categorized based on sensitivity. Public mission logs, such as task schedules and environmental readings, were processed through the public blockchain. In contrast, private data—such as astronaut health metrics and biometric logs—were stored on the private blockchain. Integrity for sensitive records was ensured through ZKP mechanisms, while synchronization between blockchains was handled using Chainlink’s CCIP.

Each of the four experiments focused on a distinct objective, as follows: verifying public data integrity, enforcing private data access control, assessing ZKP-based verification performance, and comparing system performance with a traditional centralized database. The experimental setup, procedure, and results for each scenario are described below.

4.2.1. Public Blockchain Data Integrity Verification

The objective is to verify that the public blockchain can detect any tampering of data by using stored hashes, thereby ensuring the integrity of public data. We took a sample EVA mission log entry (considered as D_pub) and had it go through the system’s public data pipeline. The entry was hashed (H(D_pub)) and recorded on the Ethereum blockchain via our smart contract. Later, to test integrity, we simulated a scenario where a user retrieves the mission log and verifies its authenticity. The user calls the smart contract to obtain the official hash from the blockchain, and then computes a fresh hash of the local copy of the data. We performed two sub-tests, (a) using an unaltered copy of the data, and (b) using a deliberately modified copy.

In case (a), the hash computed by the user exactly matched the hash stored on the blockchain. The smart contract’s verification function confirmed the match, indicating that the data had not been altered. In case (b), as expected, the hash of the modified data did not match the blockchain’s hash. The discrepancy was immediately flagged, effectively detecting the tampering. Throughout multiple trials with different log entries, the system consistently detected even minor modifications. This experiment demonstrated that the public blockchain serves as a reliable integrity ledger, that is, as long as the hash on-chain and the data off-chain are compared, any unauthorized changes to the public data are caught. There were no false positives or false negatives observed. This confirms that our approach of storing hashes on the public blockchain provides robust data integrity verification for all stakeholders.

4.2.2. Private Blockchain Access Control and Security

The objective is to ensure that sensitive data on the private blockchain is accessible only to authorized users and that unauthorized access attempts are blocked by the smart contract-based access control. We used a set of private data entries. We defined access control rules such that one user had permission to view the data, whereas another user did not. On the Hyperledger Fabric network, we attempted to retrieve D_priv using both User A’s credentials and User B’s credentials. This invocation goes through the Fabric chaincode that checks permissions.

When User A requested the data, the smart contract verified the credentials and returned the data successfully, logging the access event. In contrast, when User B attempted to fetch the same data, the smart contract immediately rejected the request. The contract threw an “access denied” response and did not disclose any information about the data. This behavior was consistent across different types of data we tested and different unauthorized accounts; any entity not on the approved list was uniformly blocked. The experiment confirms that the private blockchain’s access control mechanism is effective: it strictly enforces confidentiality by preventing unauthorized reads. Additionally, we observed that even the authorized accesses were recorded on the private ledger’s audit log, which could be reviewed by administrators to ensure proper data usage. No data from the private chain ever leaked to the public domain or to unauthorized parties during our tests, validating the security of the private data storage. This controlled access, combined with the integrity checks from the previous experiment, means that participants can trust that sensitive data remains both intact and confidential.

4.2.3. ZKP-Based Verification Performance

The objective is to evaluate the performance impact and accuracy of using zero-knowledge proofs for data integrity verification, comparing it to traditional hash-based verification. We measure how quickly and reliably the system can perform a ZKP verification of a private data record. For this test, we focused on a representative private dataset. We ran our ZKP generation and verification process on the data. Specifically, we generated a ZK proof $\pi$(D_priv) and posted it to Ethereum, then later regenerated a proof $\pi$(D_priv’) for the same data and ran the verification check. We recorded the time taken for each step—especially the proof generation time and the proof verification time—as these are critical to performance. We also conducted a baseline measurement, i.e., computing just a hash of the data and comparing hashes to see the difference in overhead. Each test was repeated multiple times to obtain an average timing and to ensure consistency.

The ZKP-based verification succeeded in every trial, correctly validating the data integrity each time. Figure 2 provides a comparison of transaction throughput between centralized and hybrid blockchain systems. On average, generating and verifying the ZK proof for a single data item took about 0.73 s. In comparison, a simple hash computation and comparison for the same data took only around 0.1–0.2 s on average. Thus, the ZKP approach was somewhat slower—roughly on the order of a second—whereas direct hash comparison was near-instantaneous. The roughly 0.73 s delay stems from the computational complexity of ZK proof algorithms and the on-chain verification cost. However, this level of performance remains feasible for many use cases. For example, verifying a piece of data in under a second is acceptable for periodic integrity checks or for data that isn’t requested constantly. Furthermore, during this experiment, we found that the verification process was accurate. Whenever we intentionally altered the private data and generated a new proof, the verification failed, indicating detection of tampering. There were no instances where tampered data passed the ZKP check or where untampered data failed it, confirming the reliability of the cryptographic method. In summary, ZKP-based verification adds a slight overhead compared to basic hashing, but provides the invaluable benefit of privacy-preserving integrity checks. We consider this overhead to be a reasonable trade-off in the context of space missions, where data integrity and confidentiality are paramount. Potential optimizations could further reduce this delay in the future.

4.2.4. Centralized Database vs. Hybrid Blockchain Performance

The objective is to compare the performance of our hybrid blockchain system with a traditional centralized database approach in terms of data retrieval speed and transaction throughput, as well as assess the differences in security and functionality. This experiment highlights the trade-offs between conventional and blockchain-based solutions. We set up a standard centralized database (MySQL) to represent the traditional approach to space data management. We loaded it with the same dataset as the blockchain system. We then measured two things on both systems: (a) Data retrieval speed—how many queries per second (QPS) can be handled when reading data records, and (b) transaction throughput—how many write transactions per second (TPS) can be processed. For retrieval, we simulated multiple concurrent read requests to the database and the blockchain. For throughput, we executed sequences of data insertions on the database, and analogously, sequences of transactions on the blockchain. We also qualitatively compared the integrity verification and security aspects: in the database, one typically has to trust the administrator or implement application-level checks, whereas in blockchain, integrity is inherent.

Table 3. Performance comparison of the centralized database and the hybrid blockchain.

Experiment Item	Centralized DB	Hybrid Blockchain
Data Retrieval Speed	5000 QPS	200 QPS
Integrity Verification	Not possible	Possible
Data Tamper Resistance	Administrator-dependent	Cryptographically Guaranteed
Transaction Throughput (TPS)	1000+	12.5

summarizes the detailed performance comparison between the centralized database and the hybrid blockchain system.

As seen above, the centralized database drastically outperforms the blockchain in raw speed for both reads and writes. The MySQL server handled thousands of reads per second and over a thousand writes per second without issue, whereas our hybrid blockchain processed on the order of tens or low hundreds at best. However, the qualitative differences are equally important. In terms of integrity and trust, the blockchain system has a clear advantage, which automatically provides integrity verification and non-repudiation. In the database scenario, if someone with high privileges alters or deletes a record, it might be impossible for others to know after the fact; there is no immutable log. In contrast, every action on the blockchain is logged and verifiable. Also, our hybrid approach inherently prevents unauthorized data views, whereas a database relies on a firewall and authentication, which, if misconfigured or breached, could lead to major data leaks. Figure 3 shows the transaction throughput performance of the centralized database compared to the hybrid blockchain under varying concurrent transactions.

Table 4. Performance comparison of Oracle-based and CCIP-based integration methods.

Evaluation Metric	Oracle-Based Method	CCIP-Based Method (Proposed)
Avg. Synchronization Delay	15–30 s	1–2 s
Decentralization Level	1 Node (Centralized)	3 or more Nodes (Distributed)
Security (Integrity Check)	Single verification	Triple verification
Failure Rate (Reliability)	1–3‰	less than 0.5%
Computational Overhead	50–100 ms per verification	100–250 ms per verification

further details the comparative evaluation of Oracle-based and CCIP-based integration methods, highlighting the advantages of the proposed CCIP method in synchronization delay, decentralization, security, and reliability. To visually illustrate the performance trade-off, we compare the average verification times of hash-based methods and ZKP-based verification in Figure 3.

4.3. 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 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. There is, of course, room to improve the efficiency of ZKP generation and to possibly parallelize verification for multiple data points. As ZKP technology matures, we expect this overhead to diminish further, making the case for using ZKPs in such systems even stronger.

Overall, our evaluation shows that the hybrid blockchain approach is practical for enhancing data security and integrity in collaborative space missions, given the typical scale of data and required trust level. It does require some compromises in performance and added complexity in setup, but the benefits in terms of reliability, trustworthiness, and tamper resistance are significant for mission-critical contexts. Figure 4 compares the average synchronization delay between the Oracle-based approach and the proposed CCIP-based method, clearly highlighting the superior real-time synchronization performance of our proposed approach.

4.4. Attack Scenarios and Mitigation Strategies

Attack Scenario 1: Cross-chain synchronization attack. An attacker could exploit vulnerabilities in the cross-chain interoperability protocol during data synchronization between public and private blockchains by altering or intercepting the transmitted hash data or synchronization messages, leading to incorrect data being recorded on the public blockchain. To mitigate this risk, a robust digital signature-based authentication mechanism should be enforced, requiring all cross-chain messages to carry digital signatures verified through smart contracts. Additionally, duplicated verification checks involving original data hashes and Zero-Knowledge Proofs should be employed at the receiving blockchain to ensure data integrity.

Attack Scenario 2: Insider attack via unauthorized access. Authorized users within the organization might misuse their privileges to improperly access or leak sensitive data stored on the private blockchain. To prevent such insider threats, a role-based access control system combined with multi-signature verification processes should be implemented, necessitating multiple approvals for accessing highly sensitive information. Furthermore, real-time monitoring systems should be established to detect abnormal access patterns instantly, allowing immediate suspension of suspicious accounts and conducting thorough security investigations.

Table 5. Summary of attack scenarios and mitigation strategies.

Attack Scenario	Attack Vector	Potential Impact	Mitigation Strategy
Cross-chain synchronization attack	Data tampering during cross-chain communication	Incorrect data recorded on blockchain	Digital signatures, duplicate verification protocols
Insider attack via unauthorized access	Privilege misuse by authorized insiders	Sensitive data leakage	Role-based access control, multi-signature, real-time monitoring

summarizes the described attack scenarios and mitigation strategies.

5. Conclusions

In this paper, we propose a hybrid blockchain model to ensure the security and transparency of space exploration data in multinational collaborations. Our approach addresses the trade-off between transparency and confidentiality by combining the openness of public blockchains with the restricted access control of private blockchains. Data integrity is preserved through cryptographic hashing and zero-knowledge proofs, enabling the verification of even sensitive information without revealing its content. We also introduced a decentralized cross-chain synchronization mechanism using Chainlink’s CCIP, mitigating the trust and failure risks associated with centralized oracles.

A prototype system was implemented using Ethereum and Hyperledger Fabric, and validated with real extravehicular activity data from the United States and Russia. The results show that the system effectively detects data tampering, enforces role-based access control, and supports trustworthy collaboration between organizations. Compared to conventional centralized databases, the hybrid blockchain approach provides enhanced data security, auditability, and resistance to unauthorized modification. Compared to pure private blockchains, which offer strong access control but lack transparency and verifiability across organizations, the hybrid model enhances auditability through public blockchain anchoring while maintaining data privacy. Similarly, compared to consortium blockchains that rely on mutual trust among a limited set of entities, our approach reduces the risks of collusion or unintentional data manipulation by enabling an immutable, publicly auditable ledger. This combination of transparency and confidentiality makes the hybrid model particularly suitable for multinational space collaborations where trust boundaries are complex. Although blockchain platforms naturally exhibit lower throughput and higher latency, our experimental findings indicate that the performance remains acceptable for typical space mission data management scenarios. These findings align with broader observations on the potential of blockchain technologies in distributed systems [24].

However, several limitations should be noted. Another important limitation is that the current evaluation focuses on short-term system behavior. Over prolonged operational periods, factors such as blockchain storage growth could increase data retrieval times and transaction costs. Additionally, the latency associated with zero-knowledge proof generation and verification may accumulate as the volume of protected data expands. Future work should investigate long-term performance scalability strategies, including storage pruning, data compression techniques, and the adoption of efficient zk-SNARK frameworks to mitigate potential degradation in system responsiveness. And there is a lack of precise quantification of energy consumption associated with zero-knowledge proof generation and blockchain operations. Although the computational latency was manageable, the energy efficiency of the system under extended deployment remains unexplored. Considering the constrained power environments typical of space missions, future work should include detailed profiling of energy usage during proof generation, data synchronization, and smart contract execution, with the goal of optimizing resource consumption. The current system has not been tested with extremely large-scale datasets, such as petabyte-level satellite telemetry, and its performance under such conditions remains to be explored. Additionally, while computational costs associated with ZKP were manageable in our prototype, further work is needed to assess energy efficiency and resource consumption in long-term deployments. Another limitation is the dataset scope; our evaluation was limited to EVA records. Future studies may consider broader space datasets, such as deep-space sensor readings or satellite command logs, to assess generalizability.

For future research, we propose three directions. First, transaction scalability can be improved through the adoption of layer-2 protocols or more efficient consensus mechanisms such as Proof-of-Stake variants optimized for throughput [25]. Second, hardware acceleration techniques offer promising paths to reduce proof generation latency. Recent frameworks such as GZKP demonstrate how GPU-based systems can significantly improve performance while maintaining security [26]. Third, applying this model to a wider range of real-world space datasets would provide insight into its robustness and adaptability across mission types. Fourth, we plan to extend validation by incorporating additional datasets such as satellite telemetry data and deep-space sensor readings. This will enable a more comprehensive evaluation of the system’s performance and adaptability across a broader range of space mission environments.

In addition, evaluating energy consumption and operational costs in large-scale deployments would strengthen the practical feasibility of the system. Formal security threat modeling using frameworks such as STRIDE could also improve the system’s resilience and trustworthiness.

In summary, the proposed hybrid blockchain model offers a practical framework for secure and transparent data management in collaborative space missions. As international cooperation in space exploration intensifies, this approach has the potential to serve as a foundational layer for trustworthy data infrastructure in future scientific and technical operations beyond Earth.