A Trust-Oriented Blockchain Architecture for Compliant and Secure Cross-Border Data Flows

Abstract

Compliant cross-border data flows face persistent challenges from fragmented regulatory regimes, inconsistent enforcement, and limited trust among stakeholders. Current approaches typically rely on centralized oversight or excessive data disclosure, both compromising regulatory interoperability and operational security. This paper introduces a trust-oriented blockchain architecture that enables secure cross-border data exchange while ensuring verifiable compliance without revealing sensitive content. The architecture decouples policy enforcement, privacy-preserving validation, and cross-jurisdiction auditability, enabling entities to share cryptographically verifiable compliance proofs rather than raw data. To capture the behavioral dynamics across heterogeneous regulatory environments, we incorporate a strategic interaction layer that models how domestic firms, foreign enterprises, and cross-border data platforms adjust decisions under varying incentive structures. These insights guide the design of an adaptive compliance verification pipeline that maintains trust equilibrium across participants. Our design records only cryptographic digests and structured compliance evidence on-chain, while off-chain components execute privacy-preserving checks using secure computation and decentralized storage. Through a case-driven evaluation, we show that the proposed architecture reduces governance friction, enhances institutional trust, and achieves interoperable compliance validation with minimal disclosure overhead. Through component-level evaluation and architectural analysis, this work establishes a technical foundation for secure, transparent, and regulation-aligned cross-border data governance. The framework provides a blueprint for future multi-party pilot deployments in operational environments.

1. Introduction

Cross-border data flows have become a core enabler of digital trade and cross-domain services. At the same time, their operationalization faces persistent governance barriers: fragmented regulations, inconsistent enforcement, and limited trust among stakeholders. Divergent national approaches to data governance have accelerated data protectionism and sovereignty-driven controls, which complicate cooperation and weaken institutional trust [1,2]. In practice, organizations are often required to demonstrate compliance to multiple jurisdictions while avoiding unnecessary disclosure of sensitive payloads. Consequently, enabling verifiable cross-border data exchange that aligns with both privacy requirements and regulatory mandates remains an urgent challenge [3].

Privacy risks expand with the scale and granularity of exchanged data, especially for personal identifiers and sensitive records. Moreover, heterogeneous legal requirements for encryption, processing, and cross-border transfer create additional complexity [4]. Recent global events (e.g., pandemic-era health-data collaboration) further highlighted the tension between rapid information sharing and strict privacy constraints under conflicting legal frameworks [5,6]. These experiences suggest that sustainable cross-border data exchange depends not only on technical protection, but also on institutional trust and coordination mechanisms that can reduce disputes and clarify accountability.

From an operational perspective, cross-border verification often involves multiple actors with conflicting incentives. Domestic enterprises, foreign enterprises, and cross-border platforms may strategically adjust their choices (e.g., whether to collaborate on compliance) depending on enforcement intensity, costs, and expected benefits. Therefore, governance outcomes are shaped by both technical feasibility and strategic behavior. This motivates us to complement the technical architecture with a strategic interaction layer that helps explain when collaboration is likely to emerge and persist.

Blockchain-based approaches provide useful building blocks for cross-jurisdiction accountability because they offer tamper resistance, traceability, and programmable coordination [7]. In particular, consortium blockchains can support verification among authorized participants and reduce unilateral control risks. When combined with privacy-preserving techniques such as attribute-based access control [8] and privacy-preserving [9]. Security challenges and future development trends of blockchain are in the healthcare field [10], while a blockchain-based renewable energy trading model constructed on the basis of information entropy theory has also provided valuable theoretical insights for the technological implementation and optimization in this domain [11]. Blockchain can enable auditable workflows while keeping sensitive content protected. However, transparency also increases confidentiality risks if payloads are recorded directly on-chain, and many existing designs do not explicitly separate evidence from payload in a way that supports cross-jurisdiction compliance verification.

Against this background, cross-jurisdiction data sharing remains constrained by three practical gaps: (i) compliance requirements are fragmented and sometimes conflicting across jurisdictions; (ii) stakeholders often lack mutual trust and a shared audit boundary; (iii) compliance must be demonstrated without disclosing sensitive payloads to platforms or auditors. Existing solutions commonly rely on centralized oversight, full disclosure, or purely on-chain storage, each of which creates scalability or confidentiality limitations. These gaps motivate a design that supports verifiable compliance with minimal disclosure while remaining deployable in consortium settings.

This paper proposes a hybrid governance-and-technology framework that integrates consortium blockchain, decentralized off-chain storage, and homomorphic computation, together with a three-party evolutionary-game layer. The architecture anchors cryptographic digests and structured compliance evidence on-chain, while keeping payloads off-chain and protected. The game-theoretic layer models how domestic enterprises, foreign enterprises, and cross-border platforms adjust compliance collaboration under heterogeneous incentives, providing guidance for equilibrium-oriented mechanism design.

This paper responds by proposing a hybrid governance and technology framework that integrates consortium blockchain and privacy-preserving computation, together with a multi-party game-theoretic perspective. Our approach models the strategic interactions among domestic enterprises, foreign enterprises, and data platforms, thereby explaining how cooperative and trust-enhancing equilibria can emerge. More broadly, it contributes to ongoing efforts toward a fair, cooperative, and compliance-oriented global data governance system, helping to navigate the fragmented landscape of international privacy regulation.

The main contributions of this paper are as follows:

• We propose a trust-oriented consortium blockchain architecture that decouples policy enforcement, privacy-preserving validation, and cross-jurisdiction auditability, enabling compliance proofs instead of raw data disclosure.
• We integrate hybrid storage (IPFS + on-chain hash anchoring) and homomorphic computation to support privacy-preserving cross-domain verification while maintaining integrity and traceability.
• We introduce a strategic interaction layer (three-party evolutionary game) to capture how platforms and firms adjust compliance collaboration under heterogeneous incentives, informing equilibrium-oriented mechanism design.

Organization. Section 2 reviews related work and highlights remaining gaps. Section 3 presents the system design. Section 4 details access control and the verification workflow. Section 5 introduces the evolutionary-game analysis. Section 6 and Section 7 report security and performance evaluations, followed by conclusions.

2. Related Works

2.1. Blockchain

Blockchain is a distributed ledger technology that employs encryption for data integrity and security. Fundamentally, it constructs a trust system independent of any third party, where the authenticity of data is verified by all nodes within the blockchain network, data storage is managed by consensus nodes, and data manipulation and programming are facilitated through smart contracts [12]. The advantages of this chain-like data structure include the difficulty of altering the interconnected blocks and the capability to trace back from any given block to the genesis block. Blockchain technology is characterized by its decentralization, transaction transparency, collective maintenance, anonymity, immutability, and traceability [13]. These technical features enable blockchain to address trust issues among cross-border organizations during data sharing [14]. Blockchains can be categorized into public chains, private chains, and consortium chains. Public chains operate independently without centralized management, open to all organizations and individuals, with a completely transparent ledger. Their applications are primarily in digital currencies, such as Bitcoin [15] and Ethereum [16]. Private chains are confined within a specific domain, typically within an enterprise or organization, with blockchain rules tailored to operational needs and data read-write permissions restricted to internal nodes. Consortium chains [17], often referred to as industry blockchains or regional chains [18], achieve partial decentralization and are accessible only to specific organizations or groups, with data permissions managed within the consortium and the possibility of data modification [19]. These chains are mainly applied in banking [20], product traceability [21], and supply chain [22].

2.2. Homomorphic Encryption

Homomorphic encryption [23] allows a party with the decryption key to obtain the results of operations performed on homomorphically encrypted data, without access to the individual encrypted messages involved in the computations. The definition of homomorphic encryption is as follows: Let $E(k,x)$ denote the encryption of x with encryption algorithm E and key k, and let F be an operation. If for encryption algorithm E and operation F, there exists an efficient algorithm G such that:

$$E\left(k,F(x_1,x_2,\dots ,x_n)\right)=F\left(E(k,x_1),E(k,x_2),\dots ,E(k,x_n)\right).$$

(1)

then the encryption algorithm E is said to be homomorphic with respect to operation F. If $F(x_1,x_2,\dots ,x_n)={\sum }_{i=1}^n{x}_i$, the encryption algorithm is referred to as an additive homomorphic encryption algorithm. If $F(x_1,x_2,\dots ,x_n)={\prod }_{i=1}^n{x}_i$, it is called a multiplicative homomorphic encryption algorithm. If the defined equality holds for $F(x_1,x_2,\dots ,x_n)$ involving both addition and multiplication, then the scheme is a fully homomorphic encryption scheme. Homomorphic encryption algorithms are divided into three categories: semi-homomorphic [24], somewhat homomorphic [25], and fully homomorphic encryption [26]. Semi-homomorphic encryption supports only one of a few algebraic operations like addition or multiplication; somewhat homomorphic encryption can perform a limited number of additions and multiplications; fully homomorphic encryption supports an arbitrary number of mixed operations of addition and multiplication [27].

2.3. Blockchain and Homomorphic Encryption

Recent studies increasingly combine blockchain with homomorphic encryption to improve accountability and confidentiality in distributed systems. A first line of work uses blockchain as a coordination and provenance layer, while encrypted computation protects sensitive inputs. For example, Ma et al. [28] explore privacy-preserving computation in cross-edge blockchain settings, and Xiong et al. [29] integrate blockchain and homomorphic encryption to mitigate collusion risks in federated learning. Related applications also appear in personalized services, where decentralized training and encrypted computation reduce exposure [30].

A second line of work focuses on domain-specific designs. In healthcare and IIoMT, Ali et al. [31] integrate consortium blockchain and homomorphic encryption to protect medical data while supporting learning and coordination. In cloud services, Wu et al. [32] propose fair-payment mechanisms with privacy guarantees. Financial-market scenarios further demonstrate that blockchain and encrypted computation can jointly support traceability and confidentiality [33]. In addition, consortium-chain interoperability has been studied to improve synchronization and concurrency in multi-domain environments [34].

For cross-jurisdiction verification, existing research can be summarized into four streams:

• Immutable logging and coordination: blockchain used for traceability and accountability in multi-party sharing [7,35,36].
• Hybrid storage: payloads stored off-chain (e.g., IPFS), with integrity proofs anchored on-chain, often with access control [8].
• Privacy-preserving computation: homomorphic encryption enables encrypted-domain processing while blockchain manages provenance and verifiability [28,29,31,32,33].
• Interoperability and cross-chain designs: synchronization across consortium environments [34].

However, recurring gaps remain for cross-jurisdiction compliance verification under heterogeneous rules. First, compliance is often treated as authorization, while structured compliance evidence is not explicitly defined. Second, threat models are frequently implicit, security discussions may not clearly distinguish on-chain exposure, off-chain protection, and active attacks (e.g., replay or payload substitution). Third, many designs are technology-centric and omit incentive dynamics that affect sustained collaboration.

Table 1. Concise comparison with representative works.

Work	Core	Limitation in Cross-Jurisdiction Settings
Jiang et al. [7]	Blockchain sharing (ITS)	Limited audit-oriented evidence design.
Kaur et al. [8]	Blockchain+IPFS, ABAC	Compliance mainly as access control; weak evidence workflow.
Ma et al. [28]	Blockchain-assisted FHE	Focus on compute privacy; audit boundary not explicit.
Xiong et al. [29]	Blockchain+HE (FL)	Scenario-specific; compliance verification not central.
Ali et al. [31]	Consortium BC + HE (IIoMT)	Domain-oriented; threat/audit model incomplete.
Wu et al. [32]	BC+HE for fair payment	Compliance evidence and governance aspects underexplored.
Zhu et al. [34]	Consortium cross-chain	Interop-focused; no privacy-preserving verification pipeline.
Our work	Consortium BC + IPFS + HE + game model	Evidence–payload separation + auditable compliance + incentive-aware collaboration.

summarizes these differences and motivates our design.

3. Design

3.1. System Overview

We propose a cross-border data verification system integrating consortium blockchain, homomorphic encryption, and IPFS. This design enables verifiable cross-jurisdiction validation while maintaining sensitive payloads off-chain under cryptographic protection. The consortium blockchain serves as the trust anchor; only authorized members participate, which improves efficiency and aligns with regulatory requirements. Figure 1 illustrates the overall architecture.

In the system, consortium nodes A and B represent different data owners or users. Smart contracts manage access permissions and record verifiable evidence of compliance-relevant actions. Two off-chain components support confidentiality and scalability: (i) an IPFS cluster for decentralized storage of encrypted payloads, and (ii) a homomorphic computing service for encrypted-domain operations.

The system adopts a hybrid storage model. Only content hashes (digests) and structured compliance evidence are recorded on-chain, while encrypted files are stored off-chain on IPFS. This reduces on-chain storage overhead while preserving integrity and traceability; any party can verify that an off-chain file matches the on-chain digest.

When nodes A and B need to verify data consistency or eligibility, each party encrypts its private inputs and delegates encrypted-domain operations to the homomorphic computing service. The resulting ciphertext output is stored on IPFS, and its content address is anchored on-chain via a smart contract. The requester then decrypts the result locally to determine whether the verification condition holds. Throughout the process, the blockchain records only evidence and digests, thereby mitigating leakage risks and supporting auditability.

To improve readability, we use D for data objects, P and $PK$ for public/private keys, and $Addr(·)$ for content-addressable identifiers (e.g., IPFS hashes). Subscripts indicate the source module (e.g., $BS$ for business system). The composite superscript $Sig\oplus FHE\oplus EN$ denotes a package that is signed for integrity, protected by homomorphic encryption for encrypted computation, and encrypted at file level for secure storage/transport.

3.2. Data Access

Cross-border data exchange in our setting involves two access-control contexts: (i) access across jurisdictions among cross-border organizations, and (ii) access within a jurisdiction among domestic organizations. We denote a participating organization as a Cross-Border Organization (CBO), which includes four functional modules: a business system $S_{BS}$, a consortium blockchain node $S_{BC}$, an IPFS storage service $S_{IPFS}$, and a homomorphic computing service $S_{C\_FHE}$. Multiple CBOs form a Cross-Domain Data Compliance and Trust Computing Alliance. Information exchange among CBOs is carried over a consortium network layer $CNL$ (Figure 2). Following the principle that access permissions are granted by the data originator, $S_{BC}$ manages access rights through smart contracts.

Table 2. Data access design.

Data	Permission	Description
$D_{BK}$	Read	Share blockchain ledger information within CNL.
$P_{Sig}$	Read	Obtain CBO signature public key for verifying the determinacy of $D_{FHE(BS⊳)}^{Sig\oplus FHE\oplus EN}$.
$P_{FHE}$	Read	Obtain CBO homomorphic encryption public key for data computation.
$P_{File\_EN}$	Read	Obtain CBO file encryption key for encrypting files when pushing $D_{FHE(BS⊳)}^{Sig\oplus FHE\oplus EN}$ to CBO.
$Add{r}_{H\left(xml\right)⊳FHE\left(C\right)}$	Read	Obtain the address of CBO’s homomorphic encryption computation result for decryption and cross-domain data exchange.
$D_{BS}^{Sig\oplus FHE\oplus EN}$	Write	Submit cross-border data to CBO, writing into CBO’s cross-border data.
$D_{FHE(BS⊳)}^{Sig\oplus FHE\oplus EN}$	Read	Obtain $D_{FHE(BS⊳)}^{Sig\oplus FHE\oplus EN}$ based on $Add{r}_{H\left(xml\right)⊳FHE\left(C\right)}$ for local decryption.

summarizes the key data items and their associated permissions in the proposed access control mechanism. The table lists seven primary permissions, categorized by the type of data involved. For instance, read permissions dominate for shared cryptographic materials such as blockchain ledger data ($D_{BK}$), signature public keys ($P_{Sig}$), homomorphic encryption public keys ($P_{FHE}$), and file encryption keys ($P_{File\_EN}$), enabling secure verification, computation, and encryption without exposing sensitive information. Additionally, the address of homomorphic computation results ($Add{r}_{H\left(xml\right)⊳FHE\left(C\right)}$) and the encrypted homomorphic data ($D_{FHE(BS⊳)}^{Sig\oplus FHE\oplus EN}$) are readable for authorized parties to facilitate decryption and cross-domain exchange. In contrast, write permission is strictly limited to submitting signed, homomorphically encrypted, and additionally encrypted business data ($D_{BS}^{Sig\oplus FHE\oplus EN}$), ensuring that only the data originator can initiate cross-border submissions while maintaining traceability and privacy.

Figure 2 illustrates the overall architecture of the blockchain and homomorphic encryption-based cross-border data privacy protection system. The diagram depicts multiple CBOs interconnected via the Consortium Network Layer (CNL), with each CBO comprising the four core modules: the business system ($S_{BS}$) for data origination, the consortium blockchain node ($S_{BC}$) for access control and ledger management, the IPFS service ($S_{IPFS}$) for decentralized off-chain storage of encrypted files, and the homomorphic computing service ($S_{C\_FHE}$) for privacy-preserving computations on encrypted data. Data flows are shown with layered encryption (signature, FHE, and additional file encryption) to ensure compliance, traceability, and privacy during cross-border exchanges, while smart contracts on the blockchain enforce originator-granted permissions.

3.3. Design Rationale and Alternatives

Whyhomomorphic encryption (HE). Our design prioritizes cross-jurisdiction verification with minimal disclosure and limited interaction. HE supports encrypted-domain evaluation—processing ciphertexts without revealing plaintexts—while maintaining secret keys locally with data owners. This reduces the operational burden of multi-round cross-border coordination compared with interactive MPC protocols. We do not claim HE is universally superior; rather, it is a pragmatic choice under low-interaction and key-locality requirements.

Alternatives (MPC/ZKP/TEE). MPC can offer strong privacy guarantees but typically requires multiple interactive rounds and online availability of all parties, which may be difficult under cross-border operational constraints. ZKP can provide stronger public verifiability (e.g., proving correct execution of a policy check), but it often requires circuit/constraint-system engineering and may incur substantial computational overhead. TEEs improve efficiency but introduce hardware trust and attestation assumptions that may not be acceptable in some governance settings. In this work, we adopt HE as a deployable baseline and leave ZKP-enhanced compliance proofs and MPC/TEE hybrids as future extensions.

Why a permissioned consortium blockchain. The governance setting requires controlled membership, accountable identities, and immutable audit trails among authorized stakeholders. A permissioned consortium blockchain provides tamper-resistant evidence anchoring and programmable verification via smart contracts. While we implement the prototype on FISCO BCOS, the architecture is compatible with other BFT-style permissioned ledgers offering similar identity and smart-contract capabilities.

Why IPFS-based off-chain storage. We separate evidence from payload. Only digests and structured compliance evidence are anchored on-chain, while encrypted payloads and encrypted computation artifacts are stored off-chain. IPFS provides content-addressable identifiers, enabling integrity verification by matching on-chain digests with off-chain objects, while avoiding excessive on-chain storage overhead. We also discuss availability and metadata leakage risks and adopt mitigations (e.g., padding and handle rotation) in our threat model.

Design rationale and trade-off analysis. The choice of HE for encrypted-domain verification reflects three operational imperatives in cross-jurisdiction settings. First, interaction minimization: cross-border protocols face unpredictable network latency and availability constraints; HE’s non-interactive property (submit ciphertext, retrieve result) reduces coordination overhead compared to multi-round MPC protocols. Second, key governance alignment: HE maintains key locality—secret keys never leave the data owner’s jurisdiction—which simplifies compliance with sovereignty requirements and avoids distributed key management ceremonies that may conflict with regulatory constraints. Third, consortium audit compatibility: while HE does not provide native public verifiability (unlike ZKP), it supports integrity verification through signed computation transcripts, which suffices for permissioned settings with accountable members.

Table 3. Rationaleand trade-offs of candidate verification technologies in cross-jurisdiction settings.

Tech	Interaction	Correctness Verifiability	Trust Assumptions	Overhead
HE	Low (submit ciphertext, retrieve result)	Medium (integrity via signatures/logs; no public proof by default)	Cryptographic hardness + key locality	Moderate
MPC	Medium–High (multi-round)	Medium (protocol-level)	Party availability + protocol honesty model	High
ZKP	Low (verify proof)	High (public verifiability)	Cryptographic assumptions + circuit correctness	High
TEE	Low–Medium	Medium (attestation-based)	Hardware + attestation infrastructure	Medium

summarizes these trade-offs qualitatively. A quantitative comparison—implementing MPC-based, ZKP-augmented, and TEE-assisted variants of the same compliance checks and benchmarking latency, communication overhead, and computational cost—would provide deeper insight into the efficiency frontier. Such comparative analysis represents a valuable research direction once the architectural framework is validated through pilot deployment. The present work establishes HE as a pragmatic baseline for the stated requirements and demonstrates its feasibility through component-level evaluation.

3.4. Evaluation Philosophy and Research Positioning

This work adopts a design-science approach where the architectural framework is validated through component-level performance characterization. Section 6 demonstrates that individual subsystems—consortium blockchain, homomorphic computation, and decentralized storage—meet necessary performance thresholds for cross-jurisdiction workflows. This methodology enables systematic identification of bottlenecks (e.g., HE computation overhead) and provides reproducible benchmarks under controlled conditions. Integrated end-to-end evaluation across geographically distributed nodes represents the natural next phase, requiring operational partnerships and regulatory alignment beyond the current study’s scope.

The selection of HE over alternatives (MPC, ZKP, TEE) reflects three operational requirements: low-interaction overhead (avoiding multi-round coordination across jurisdictions), key locality (secret keys remain with data owners), and consortium audit compatibility (integrity verifiable through signed transcripts). Table 3 structures this comparison. Quantitative benchmarks comparing protocol variants under equivalent workloads would require substantial engineering effort; the present work establishes the rationale for HE adoption and demonstrates feasibility, providing a foundation for comparative analysis in future research.

The evolutionary-game model (Section 5) functions as a mechanism-design interpretation layer, formalizing how system parameters influence strategic decisions and deriving conditions for sustainable collaboration (Equation (12)). It links architectural choices—such as evidence–payload separation (reduces ${\zeta }_i$) and enforceable penalties (increases ${\varphi }_i$)—to incentive structures. Parameter calibration through stakeholder surveys or pilot telemetry will enable quantitative sensitivity analysis; the model’s current contribution is making governance design actionable.

4. Scheme Implementation

For readability,

Table 4. Condensed notation used in Section 3, Section 4, Section 5 and Section 6 (see Abbreviations for the full list).

Symbol	Meaning (Functional Role)
$D_{BS}$	Business-origin data produced/managed by a CBO’s business system.
$D_{BS}^P$	Public/non-sensitive subset of $D_{BS}$ for exchange or indexing.
$D_{BS}^{PK}$	Privacy-sensitive subset of $D_{BS}$ (not shared in plaintext).
$P_{Sig},P{K}_{Sig}$	Public/private keys for digital signatures (integrity and non-repudiation).
$P_{FHE},P{K}_{FHE}$	Public/private keys for (fully) homomorphic encryption (privacy-preserving computation).
$P_{File\_EN},P{K}_{File\_EN}$	Key pair for file-level encryption (secure transport/storage of payloads).
$D_{BS}^{Sig\oplus FHE\oplus EN}$	Data package protected by signing + homomorphic encryption + file encryption.
$D_{FHE(BS⊳)}^{Sig\oplus FHE\oplus EN}$	Homomorphic computation result (still protected), returned to the requester for decryption.
$Add{r}_{H\left(xml\right)⊳FHE\left(C\right)}$	Content-address (e.g., IPFS hash) pointing to the homomorphic result file.
$S_{BC}$	Consortium blockchain node server (smart contracts, logging, access control).
$S_{IPFS}$	Off-chain decentralized storage server (stores encrypted payloads/content).
$S_{C\_FHE}$	Homomorphic computing server (executes encrypted-domain operations).
$CBO,CB{O}^{\sim }$	Cross-border organizations (domestic vs. foreign participant).
$CNL$	Consortium network/communication layer for cross-organization interaction.

summarizes the most frequently used symbols in this section, the complete notation list is provided in Abbreviations.

This section illustrates the verification workflow through a concrete cross-jurisdiction scenario between regions A and B. We assume that trust between the two regions is limited. Region B holds privacy-sensitive identifiers (e.g., social security numbers) that cannot be transmitted in plaintext due to legal constraints. Region A needs to verify whether a claimed identifier matches a record in region B (or whether it has valid usage rights under B’s policies). Therefore, verification must be performed without disclosing B’s sensitive payload. We use homomorphic encryption to enable encrypted-domain equality checking, as described below:

1.

Initially, region A generates a pair of public and private keys, subsequently transmitting the public key to region B. It encrypts the social security number requiring verification using this public key, resulting in ciphertext $C_A$, and dispatches $C_A$ along with some non-private information (e.g., name, age) to region B.

2.

Subsequently, region B, utilizing the provided non-private information, locates the corresponding social security number within its local database and encrypts it employing region A’s public key, yielding ciphertext $C_B$. It then applies a homomorphic encryption algorithm to perform a subtraction operation on $C_A$ and $C_B$, generating the ciphertext $C_D=C_A-C_B$, and relays $C_D$ back to region A.

3.

Finally, region A decrypts $C_D$ with its private key, obtaining the plaintext D. If $D=0$, it signifies that the social security number indeed originates from region B, validating the verification; conversely, if $D\ne 0$, it denotes a mismatch with region B’s data, indicating verification failure.

The key advantage is that private data are processed locally by the data holder and never leave the jurisdiction in plaintext. Region A learns only the verification outcome, not B’s sensitive record. In addition, we compute the verification result via homomorphic operations rather than comparing ciphertexts directly, which reduces the risk of manipulation and avoids reliance on a trusted third party. Algorithm 1 presents the Paillier-based subtraction used for equality checking.

The framework for cross-domain data exchange encompasses the exchange of two principal data types: public data $D_{BS}^P$ and private data $D_{BS}^{PK}$. Private data $D_{BS}^{PK}$ is rigorously protected under international laws and regulations, which preclude its transfer across borders without explicit consent from the data subject. Given these legal prerequisites, this project introduces a methodology employing homomorphic encryption for $D_{BS}^{PK}$, thereby enabling homomorphic computations on $D_{BS}^{PK}$ across borders to fulfill the aim of cross-domain data verification. The process necessitates adherence to the following three stipulations:

Algorithm 1 Paillier Subtraction for Encrypted Data

Require: $c_1,c_2$: ciphertexts encrypted by Paillier algorithm; n: public key; $(\lambda ,\mu )$: private key Ensure: m: plaintext result of subtraction   1: procedure PaillierSub($c_1,c_2,n,\lambda ,\mu$)   2:       Define $L\left(x\right)={\displaystyle \frac{x-1}{n}}$   3:       Compute the inverse of $c_2$ using Euler’s theorem: $c_2^{-1}=c_2^{\varphi \left(n^2\right)-1}mod{n}^2$   4:       Compute the product of $c_1$ and $c_2^{-1}$ using homomorphic addition property: $c=(c_1·c_2^{-1})mod{n}^2$   5:       Compute the decryption of c using Paillier decryption process: $m=L(c^{\lambda }mod{n}^2)·\mu modn$   6: end procedure   7: return m

1.

Post-transmission of $D_{BS}^{PK}$ from the Cross-Border Organization (CBO) to its counterpart $CB{O}^{\sim }$, it is imperative that $CB{O}^{\sim }$ cannot access the private information of $D_{BS}^{PK}$ using the decryption key.

2.

Upon receipt of $D_{PY⊳}^{FHE}$ data by $CB{O}^{\sim }$, it is crucial for $CB{O}^{\sim }$ to ensure the provision of $D_{PY⊳}^{FHE}$ in alignment with cross-domain data exchange requisites, facilitating homomorphic operations between $D_{PY⊳}^{FHE}$ instances.

3.

The outcome of the homomorphic computation $D_{FHE(BS⊳)}^{Sig\oplus FHE\oplus EN}$ should be exclusively obtainable by the requesting party for cross-domain data exchange $D_{BS}^{PK}$.

Incorporating blockchain’s immutable characteristic, the ensuing scenario is delineated:

1.

The homomorphic encryption public key $P_{FHE}$ is logged on the blockchain. CBO disseminates its $P_{FHE}$, permitting $CB{O}^{\sim }$ to access $P_{FHE}$ and to conduct homomorphic encryption on its $D_{BS}^{PK}$, thus enabling homomorphic computations between $D_{PY⊳}^{FHE}$ entities.

2.

Homomorphic computations and their results $D_{FHE(BS⊳)}^{Sig\oplus FHE\oplus EN}$ are registered on the blockchain, facilitating CBO’s acquisition of $D_{FHE(BS⊳)}^{Sig\oplus FHE\oplus EN}$ and the realization of cross-domain data exchange.

3.

The procurement and decryption of homomorphic computation outcomes.

This method integrates the indelible nature of blockchain technology with homomorphic encryption to safeguard privacy whilst enabling cross-domain data verification and exchange.

The rational analysis of this scheme is shown in Figure 3, which illustrates the process in which each cross-border organization (CBO) transmits cross-border data to $CB{O}_n$. Each CBO encrypts its data using its own public homomorphic encryption key $P_{FHE}$ and sends it to the homomorphic computing server $S_{C_{FHE}}$ at $CB{O}_n$. Concurrently, $CB{O}_n$, in response to the requirements of each CBO, encrypts its data using the $P_{FHE}$ of each CBO and transmits encrypted data to $S_{C_{FHE}}$. After homomorphic computations are conducted by $S_{C_{FHE}}$, the outcomes are returned to each CBO. Subsequently, each CBO utilizes its private key $P{K}_{FHE}$ to decrypt the results of these homomorphic computations, thereby facilitating cross-border data exchange.

This method presents several advantages:

1.

Compliance with Legal Regulations: The $D_{PY⊳}^{FHE}$ data sent by each CBO to $CB{O}_n$’s computing server $S_{C_{FHE}}$ utilizes that CBO’s $P_{FHE}$. Since $CB{O}_n$ lacks the corresponding $P{K}_{FHE}$, it is incapable of decrypting the data. This ensures that encrypted data maintains its privacy integrity, as it cannot be decrypted by any party other than the originating CBO. Additionally, since $S_{C_{FHE}}$ is situated within the territorial jurisdiction of $CB{O}_n$ and does not involve data leaving the country, this methodology adheres to legal stipulations concerning the prohibition of cross-border private data transfer.

2.

Enabling Cross-Border Data Exchange: The homomorphic encryption technique permits computations on encrypted data, where the homomorphic operation results $D_{FHE(BS⊳)}^{Sig\oplus FHE\oplus EN}$ can only be decrypted with the CBO’s $P{K}_{FHE}$, thereby accomplishing cross-border data exchange.

The discussion underscores the strategic application of homomorphic encryption to safeguard data privacy in the context of cross-border data exchanges. It demonstrates a comprehensive approach to circumvent traditional challenges associated with such exchanges.

5. Evolutionary Path Analysis of Three Parties

In order to examine the strategic dynamics of cross-border data governance, we establish a three-party evolutionary game model involving the cross-border data platform, foreign enterprises, and domestic enterprises. Each participant can choose between compliance collaboration and non-collaboration, and their payoffs depend on both their own strategies and those of the other two parties. By applying replicator dynamic equations, we model how the probabilities of adopting collaboration evolve over time. To strengthen the connection between the evolutionary-game layer and the proposed architecture, we clarify that Section 5 is used as a mechanism-design interpretation layer rather than a standalone behavioral prediction module. The replicator dynamics provide (i) an explicit incentive threshold for when compliance collaboration becomes self-reinforcing, and (ii) actionable comparative-statics guidance on how system knobs shift stakeholders toward a cooperative equilibrium. Therefore, the game parameters are mapped to concrete design controls in the blockchain–IPFS–HE pipeline, enabling the analysis to directly inform architectural choices (

Table 5. Mapping between game parameters and actionable architectural control knobs.

Parameter	Behavioral Meaning in Game	Architectural Control Knob in Our System
${\chi }_i$	Collaboration cost (integration, compliance effort, computation/ops overhead)	Reduce via evidence–payload separation, batching, lightweight HE checks, off-chain computation service, and streamlined smart-contract interfaces.
${\varphi }_i$	Loss from exclusion/consequences of non-collaboration	Enforce via permissioned membership rules, access revocation, deposit/slashing, and on-chain dispute/audit triggers.
${\zeta }_i$	Privacy/compliance risk cost perceived by party i	Reduce via encrypted payload off-chain, digest anchoring, key-locality, padding/handle rotation, and policy-bound evidence objects.
$\mathrm{\Lambda }$	Standardization level of cross-jurisdiction compliance	Increase via unified evidence schema (e.g., policyID/jurisTag/purposeTag), rule binding, and interoperable audit semantics.
${\mathrm{\Gamma }}_i$	Share of collaborative benefit for party i	Tune via incentive allocation (service fees, priority access, reputation benefits) recorded and enforced by smart contracts.
${\beta }_i$	Capability of party i to process/execute compliance tasks	Reflect through role-based responsibilities (platform verification capacity, enterprise compliance tooling), and capability-aware policy routing.

).

5.1. Cross-Border Data Platform

For the cross-border data platform, the expected payoffs of choosing “compliance collaboration” and “non-collaboration” are denoted by $U_P^C$ and $U_P^N$, respectively, with the average payoff ${\overline{U}}_P$. The replicator dynamic equation is given as:

$$\dot{p}={\displaystyle \frac{dp}{dt}}=p(U_P^C-{\overline{U}}_P)=p(1-p)(U_P^C-U_P^N).$$

(2)

Expanding the payoff difference yields:

$$\dot{p}=p(1-p)\left[qr({\beta }_P\mathrm{\Lambda }-2{\beta }_P\sigma +{\mathrm{\Gamma }}_P+{\varphi }_P+{\chi }_P)+q({\beta }_P\sigma +{\mathrm{\Gamma }}_P-{\chi }_P)+r({\beta }_P\sigma +{\mathrm{\Gamma }}_P-{\chi }_P)-{\zeta }_P\right].$$

(3)

Here, p denotes the probability that the platform adopts compliance collaboration; q and r are the probabilities of collaboration for foreign and domestic enterprises, respectively; ${\beta }_P$ represents the platform’s data processing capability; $\mathrm{\Lambda }$ is the level of standardization of cross-border compliance; $\sigma$ denotes the amount of data under partial collaboration; ${\mathrm{\Gamma }}_P$ is the platform’s share of collaborative benefits; ${\varphi }_P$ is the penalty from exclusion in case of non-collaboration; ${\chi }_P$ is the investment cost; and ${\zeta }_P$ is the privacy risk cost.

5.2. Foreign Enterprise

For the foreign enterprise, the replicator dynamic equation is:

$$\dot{q}=q(1-q)(U_F^C-U_F^N).$$

(4)

Expanding this gives:

$$\dot{q}=q(1-q)\left[pr({\beta }_F\mathrm{\Lambda }-2{\beta }_F\sigma +{\mathrm{\Gamma }}_F+{\varphi }_F+{\chi }_F)+p({\beta }_F\sigma +{\mathrm{\Gamma }}_F-{\chi }_F)+r({\beta }_F\sigma +{\mathrm{\Gamma }}_F-{\chi }_F)-{\zeta }_F\right].$$

(5)

Here, ${\beta }_F$ represents the compliance capability of the foreign enterprise, and ${\mathrm{\Gamma }}_F, {\varphi }_F, {\chi }_F, {\zeta }_F$ denote its benefit share, exclusion loss, cost input, and risk cost, respectively.

5.3. Domestic Enterprise

For the domestic enterprise, the replicator dynamic equation is:

$$\dot{r}=r(1-r)(U_D^C-U_D^N).$$

(6)

Expanding this gives:

$$\dot{r}=r(1-r)\left[pq({\beta }_D\mathrm{\Lambda }-2{\beta }_D\sigma +{\mathrm{\Gamma }}_D+{\varphi }_D+{\chi }_D)+p({\beta }_D\sigma +{\mathrm{\Gamma }}_D-{\chi }_D)+q({\beta }_D\sigma +{\mathrm{\Gamma }}_D-{\chi }_D)-{\zeta }_D\right].$$

(7)

Here, ${\beta }_D$ denotes the compliance capability of the domestic enterprise, and ${\mathrm{\Gamma }}_D, {\varphi }_D, {\chi }_D, {\zeta }_D$ represent its collaborative benefit share, exclusion loss, cost input, and risk cost, respectively.

5.4. Equilibrium Interpretation and Local Stability Conditions

For compactness, define the incentive-gap terms in the replicator dynamics:

$$\begin{array}{cc}\hfill F_P(q,r)& =a_{P}qr+b_P(q+r)-{\zeta }_P,\hfill \end{array}$$

(8)

$$\begin{array}{cc}\hfill F_F(p,r)& =a_{F}pr+b_F(p+r)-{\zeta }_F,\hfill \end{array}$$

(9)

$$\begin{array}{cc}\hfill F_D(p,q)& =a_{D}pq+b_D(p+q)-{\zeta }_D,\hfill \end{array}$$

(10)

where $a_i={\beta }_i\mathrm{\Lambda }-2{\beta }_i\sigma +{\mathrm{\Gamma }}_i+{\varphi }_i+{\chi }_i$ and $b_i={\beta }_i\sigma +{\mathrm{\Gamma }}_i-{\chi }_i$ for $i\in \{P,F,D\}$. The system can be rewritten as $\dot{p}=p(1-p)F_P(q,r)$, $\dot{q}=q(1-q)F_F(p,r)$, and $\dot{r}=r(1-r)F_D(p,q)$.

• Equilibria.

All vertices $(p,q,r)\in {\{0,1\}}^3$ are equilibria. An interior equilibrium may exist if the three conditions $F_P(q,r)=0$, $F_F(p,r)=0$, and $F_D(p,q)=0$ admit a solution in ${(0,1)}^3$.

• Jacobian and local stability at vertex equilibria.

The Jacobian matrix J has the form:

$$J=\left[\begin{array}{ccc}(1-2p)F_P& p(1-p){\displaystyle \frac{\partial F_P}{\partial q}}& p(1-p){\displaystyle \frac{\partial F_P}{\partial r}}\\ q(1-q){\displaystyle \frac{\partial F_F}{\partial p}}& (1-2q)F_F& q(1-q){\displaystyle \frac{\partial F_F}{\partial r}}\\ r(1-r){\displaystyle \frac{\partial F_D}{\partial p}}& r(1-r){\displaystyle \frac{\partial F_D}{\partial q}}& (1-2r)F_D\end{array}\right].$$

(11)

Atvertex equilibria, the off-diagonal terms vanish because $p(1-p)$, $q(1-q)$, and $r(1-r)$ are zero. Hence, the local stability is determined by the signs of the diagonal eigenvalues.

• Design-relevant cooperative equilibrium.

For the full-collaboration equilibrium $(p,q,r)=(1,1,1)$, local asymptotic stability requires $F_P(1,1)>0$, $F_F(1,1)>0$, and $F_D(1,1)>0$. Noting that $-2{\beta }_i\sigma +2{\beta }_i\sigma$ cancels, we obtain a concise threshold:

$$F_i(1,1)={\beta }_i\mathrm{\Lambda }+3{\mathrm{\Gamma }}_i+{\varphi }_i-{\chi }_i-{\zeta }_i>0,i\in \{P,F,D\}.$$

(12)

Equation (12) directly links the cooperative outcome to architectural controls: increasing compliance standardization ($\mathrm{\Lambda }$), improving collaboration payoff allocation (${\mathrm{\Gamma }}_i$), and strengthening enforceable exclusion penalties (${\varphi }_i$) promotes cooperation; reducing operational/computation burden (${\chi }_i$) and perceived privacy/compliance risk (${\zeta }_i$) stabilizes collaboration.

• Comparative-statics implications.

From (12), $\partial F_i(1,1)/\partial \mathrm{\Lambda }={\beta }_i>0$, $\partial F_i(1,1)/\partial {\mathrm{\Gamma }}_i=3>0$, $\partial F_i(1,1)/\partial {\varphi }_i=1>0$, while $\partial F_i(1,1)/\partial {\chi }_i=-1<0$ and $\partial F_i(1,1)/\partial {\zeta }_i=-1<0$. Therefore, the proposed evidence–payload separation (reducing ${\zeta }_i$) and low-interaction HE-based verification (reducing ${\chi }_i$) are consistent with shifting the system toward a stable cooperative equilibrium.

In summary, the game layer is used to derive the incentive thresholds and parameter directions that justify the architectural choices (HE, consortium blockchain, and IPFS-based evidence–payload separation) in a deployable cross-jurisdiction setting.

6. Security Analysis

To help readers map the proof symbols to the actual cross-border workflow of Section 4, we first summarize the correspondence in

Table 6. Mapping of proof symbols to system components.

Symbol	System Meaning
$\mathcal{C}$	Ciphertext of input data, uploaded to IPFS
$\mathcal{D}$	Homomorphic result, address = $AddrH\left(xml\right)⊳FHE\left(C\right)$
$p{k}_{\mathcal{LHE}}$	$P_{\mathrm{FHE}}$ listed on-chain in Table 2
$s{k}_{\mathcal{LHE}}$	Paillier private key, kept only by data requester
$\sigma$	Schnorr signature, verified by smart contract (Algorithm 1, line 3)

. Each variable used below is hyper-linked to its first system appearance.

6.1. Adversarial Model and Trust Assumptions

We consider a static adversary that can corrupt up to $f<{\displaystyle \frac{n}{3}}$ out of n consortium members (CBOs). A corrupted member may behave as honest-but-curious—following the protocol while attempting to infer plaintexts or link access patterns—or as a fully malicious participant that deviates from the protocol. In particular, the adversary may submit malformed or replayed ciphertexts, selectively drop messages or refuse to return computation artifacts, probe IPFS content addresses to infer access behavior, or attempt unauthorized on-chain actions such as replacing another member’s registered public key.

Our security objectives are confidentiality, integrity, non-repudiation, and auditability. Confidentiality requires that no party other than the authorized data owner can obtain plaintext inputs or plaintext payloads. Integrity requires that any modification of ciphertexts or computation outputs is detectable. Non-repudiation ensures that a CBO cannot deny a signed submission after the fact. Auditability requires that compliance-relevant actions are immutably recorded so that disputes can be resolved using verifiable evidence rather than trust-based claims.

These guarantees rely on standard assumptions for permissioned deployment. The consortium blockchain satisfies BFT safety as long as $f<{\displaystyle \frac{n}{3}}$, and private keys (signing keys, Paillier/HE keys, and file-encryption keys) remain local to their owners. Public-key registration and updates are governed by explicit authorization (e.g., multi-signature approval) to prevent unilateral key substitution. For off-chain storage, we mitigate metadata leakage by padding IPFS objects to fixed sizes and rotating client-side handles periodically.

Operationally, every ciphertext $\mathcal{C}$ is accompanied by a Schnorr signature $\sigma =Sign(s{k}_{\mathrm{SIG}},\mathcal{H}\left(\mathcal{C}\right))$, which is verified by smart contracts against the on-chain $p{k}_{\mathrm{SIG}}$. Invalid submissions are rejected and logged as on-chain events. Homomorphic computation outputs are signed by the evaluator so that the requester can verify integrity before decryption; if a mismatch is detected, the requester can raise an on-chain dispute with signed transcripts as evidence for accountability and enforcement. Future work will integrate onion-encrypted retrieval.

6.2. Generic Construction with Blockchain Integration

Our enhanced scheme assumes the existence of the following primitives:

• A fully homomorphic encryption scheme denoted by $\mathcal{FHE}$, which includes the algorithms $\mathcal{FHE}.\mathrm{KeyGen}$, $\mathcal{FHE}.\mathrm{Enc}$, $\mathcal{FHE}.\mathrm{Eval}$, and $\mathcal{FHE}.\mathrm{Dec}$, and possesses a linear decrypt-and-multiply capability with a noise bound denoted by B.
• A linearly homomorphic encryption system $\mathcal{LHE}$ consisting of $\mathcal{LHE}.\mathrm{KeyGen}$, $\mathcal{LHE}.\mathrm{Enc}$, $\mathcal{LHE}.\mathrm{Eval}$, $\mathcal{LHE}.\mathrm{PDec}$, and $\mathcal{LHE}.\mathrm{Rec}$, with the provision of simulatable decryption hints.
• A consortium blockchain framework $\mathcal{BC}$, which incorporates smart contract functionality $\mathcal{BC}.\mathrm{SmartContract}$ and the capability to interface with IPFS for decentralized off-chain data storage, referred to as $\mathcal{BC}.\mathrm{IPFSInterface}$.

6.3. Cross-Border Data Verification Integration

In the context of cross-border data verification, blockchain integration is executed as follows:

KeyGen$\left(1^{\lambda }\right)$: The key generation process, denoted as $\mathcal{LHE}.\mathrm{KeyGen}$, mirrors the traditional approach with the additional procedure of registering the public keys and encryption algorithms on the blockchain via smart contracts, which enhances transparency and ensures the integrity of the process.

Enc$({\mathrm{pk}}_{\mathcal{LHE}},m)$: The encryption function, now referred to as $\mathcal{LHE}.\mathrm{Enc}$, produces a ciphertext $\mathcal{C}$. This ciphertext is stored on the IPFS, and its corresponding hash is then recorded on the blockchain for immutable tracking.

EvalSample$({\mathrm{pk}}_{\mathcal{LHE}},\mathcal{C},({\mathcal{C}}_1,\dots ,{\mathcal{C}}_{\ell }))$: Data to be evaluated, $\mathcal{C}$, is processed homomorphically. The IPFS is used to store the outcome, and the resulting IPFS hash is inscribed on the blockchain, allowing verification by other entities without breaching confidentiality.

PDec$({\mathrm{sk}}_{\mathcal{LHE}},\mathcal{C})$: and Rec$(\varrho ,\mathcal{C})$: The partial decryption functions $\mathcal{LHE}.\mathrm{PDec}$ and reconstruction $\mathcal{LHE}.\mathrm{Rec}$ remain as originally defined. Each decryption action and its result are logged on the blockchain, thanks to smart contracts, thus ensuring the auditability and traceability of all operations.

Cross-Border Data Verification: For verifying data between regions A and B, homomorphic operations $\mathcal{LHE}.\mathrm{Eval}$ are utilized to execute the necessary computations. The computed outcomes are uploaded to IPFS and their addresses are registered on the blockchain. This maintains the privacy of the data while providing a mechanism for trustless verification across jurisdictions.

Let $\mathcal{FHE}$ be a fully homomorphic encryption scheme with noise bound B, and let $\mathcal{LHE}$ be a linearly homomorphic encryption scheme. Assume $\mathcal{BC}$ is a consortium blockchain with smart contract facility $\mathcal{BC}.\mathrm{Smart}\mathrm{Contract}$ and $\mathcal{IPFS}$ for off-chain data storage. Suppose q, the plaintext space, is large enough to accommodate noise growth and ciphertext expansion. Then, the scheme described, which comprises $\mathcal{FHE}$, $\mathcal{LHE}$, and $\mathcal{BC}$, ensures that:

1.

The encrypted output $\widehat{m}$ correctly represents the outcome of a given computation $C(m_1,\dots ,m_{\ell })$, preserving its higher-order bits despite noise.

2.

Each computational step, intermediate state, and the output $\widehat{m}$ are transparently and immutably recorded on $\mathcal{BC}$ via $\mathcal{BC}.\mathrm{Smart}\mathrm{Contract}$, ensuring verifiability without revealing the underlying plain texts.

3.

The entire computation process respects the privacy and confidentiality constraints inherent in cross-border data verification scenarios.

This scheme enables public verification of the accuracy of the computations on encrypted data, facilitated by the immutable record keeping attributes of $\mathcal{BC}$, thus establishing a trustless environment for the verification of secure data across borders.

Proof. 

Let us consider the reconstructed message denoted by $\widehat{m}$, which is obtained as follows:

$$\widehat{m}=\mathcal{LHE}.\mathrm{Rec}(\varrho ,\mathcal{C})=\mathcal{LHE}.\mathrm{Rec}(\mathcal{LHE}.\mathrm{PDec}({\mathrm{sk}}_{\mathcal{LHE}},\mathcal{C}),\mathcal{C})$$

(13)

where

$$\mathcal{C}=\mathcal{LHE}.\mathrm{Eval}\left({\mathrm{pk}}_{\mathcal{LHE}},\oplus ,(\mathcal{D},\alpha )\right).$$

(14)

The term $\mathcal{D}$ is defined through the evaluation function of LHE as:

$$\mathcal{D}=\mathcal{LHE}.\mathrm{Eval}({\mathrm{pk}}_{\mathcal{LHE}},\gamma ,({\mathcal{C}}_1,\dots ,{\mathcal{C}}_n)).$$

(15)

$$\mathcal{D}=\mathcal{LHE}.\mathrm{Eval}({\mathrm{pk}}_{\mathcal{LHE}},\gamma ,(\mathcal{LHE}.\mathrm{Enc}({\mathrm{pk}}_{\mathcal{LHE}},{\sigma }_1),\dots ,\mathcal{LHE}.\mathrm{Enc}({\mathrm{pk}}_{\mathcal{LHE}},{\sigma }_n))).$$

(16)

$$\mathcal{D}=\mathcal{LHE}.\mathrm{Enc}\left({\mathrm{pk}}_{\mathcal{LHE}},\underset{j=1}{\overset{k}{⨁}}\mathcal{LHE}.\mathrm{Dec}\&\mathrm{Mult}\left(({\sigma }_1,\dots ,{\sigma }_n),{\mathcal{D}}_j,2^{\lceil log(\tilde{q}+(k+1)B)\rceil +j}\right)\right).$$

(17)

where ${\mathcal{D}}_j$ is the result of the FHE evaluation defined as

$${\mathcal{D}}_j=\mathsf{FHE}.\mathsf{Eval}({\mathrm{pk}}_{\mathsf{FHE}},{\mathcal{C}}_j,({\mathcal{C}}_1,\dots ,{\mathcal{C}}_{\ell })).$$

(18)

and ${\mathcal{C}}_i$ are the encrypted inputs

$${\mathcal{C}}_i=\mathsf{FHE}.\mathsf{Enc}({\mathrm{pk}}_{\mathsf{FHE}},m_i).$$

(19)

Hence, by the correctness of the decrypt-and-multiply operation within the FHE scheme, we can express $\mathcal{D}$ as

$$\mathcal{D}=\mathcal{LHE}.\mathrm{Enc}\left({\mathrm{pk}}_{\mathcal{LHE}},\underset{j=1}{\overset{k}{⨁}}{2}^{\lceil log(\tilde{q}+(k+1)B)\rceil +j}·{\mathcal{C}}_j(m_1,\dots ,m_{\ell })+{ϵ}_j\right).$$

(20)

$$\mathcal{D}=\mathcal{LHE}.\mathrm{Enc}\left({\mathrm{pk}}_{\mathcal{LHE}},\underset{j=1}{\overset{k}{⨁}}{2}^{\lceil log(\tilde{q}+(k+1)B)\rceil +j}·{\mathcal{C}}_j(m_1,\dots ,m_{\ell })+\underset{j=1}{\overset{k}{⨁}}{ϵ}_j\right).$$

(21)

In this context, $\alpha$ is the encryption of a uniformly random element r from ${\mathbb{Z}}_{\tilde{q}}$, as specified by the $\mathcal{LHE}.\mathrm{Sample}$ oracle, and so $\mathcal{C}$ can be written as

$$\mathcal{C}=\mathcal{LHE}.\mathrm{Eval}\left({\mathrm{pk}}_{\mathcal{LHE}},\oplus ,(\mathcal{D},\alpha )\right).$$

(22)

$$\mathcal{C}=\mathcal{LHE}.\mathrm{Enc}\left({\mathrm{pk}}_{\mathcal{LHE}},\left(\underset{j=1}{\overset{k}{⨁}}{2}^{\lceil log(\tilde{q}+(k+1)B)\rceil +j}·{\mathcal{C}}_j(m_1,\dots ,m_{\ell })+\widetilde{ϵ}\right)+r\right).$$

(23)

Here, $\widetilde{ϵ}$ encapsulates the cumulative noise from the homomorphic evaluations and is bounded by $k·B$, ensuring that the magnitude of the noise does not interfere with the correctness of the output. The randomness r, selected from ${\mathbb{Z}}_{\tilde{q}}$, contributes to the security of the encryption.

Therefore, the correct output of the computation ${\mathcal{C}}_j(m_1,\dots ,m_{\ell })$ is preserved within the higher-order bits of $\widehat{m}$, given that the plaintext space q is sufficiently large to accommodate the noise along with the growth of the ciphertext.

Incorporating the blockchain aspect, every step of the computation, including the application of $\mathcal{LHE}.\mathrm{Eval}$ and $\mathcal{LHE}.\mathrm{Enc}$, is immutably recorded on the consortium blockchain through smart contracts. These records provide cryptographic evidence for each computation step, facilitating transparency and verifiability.

This blockchain-powered log ensures that while the underlying data remains encrypted and private, the process of its transformation via homomorphic encryption is openly verifiable, enhancing the trustworthiness of the entire system.

To conclude, this construction demonstrates how split fully homomorphic encryption, when amalgamated with the decentralized trust and immutable record-keeping of blockchain technology, offers a potent solution for secure, transparent, and verifiable computations. Such a system is particularly advantageous for scenarios like cross-border data verification, where maintaining the integrity and confidentiality of the data is of paramount importance. □

7. Evaluation

The performance evaluation characterizes three key subsystems enabling cross-border compliance verification: consortium blockchain for transaction processing, homomorphic encryption for privacy-preserving computation, and off-chain storage for encrypted payload management. We measure (i) blockchain latency and throughput under varying transaction arrival rates, (ii) homomorphic encryption/decryption times for datasets of different sizes, and (iii) computational overhead of homomorphic operations. These measurements establish that each component achieves performance thresholds compatible with cross-jurisdiction workflows, while identifying optimization targets (particularly HE computation for large-scale data).

The evaluation follows a component-centric methodology consistent with design-science research, where architectural validation precedes integrated deployment. Metrics such as end-to-end multi-party verification latency, cross-border audit trail generation time, and compliance-check throughput under realistic network conditions are deferred to pilot studies with operational partners, as these require institutional partnerships and regulatory alignment beyond the current study’s scope.

7.1. Experiment Setup

The experimental environment of

Table 7. Hardware configuration for business server, IPFS server, and blockchain node server.

Component	Specification
Host System	64-bit Windows 10
CPU	11th Gen Intel(R) Core(TM) i7-11800H @ 2.30 GHz
RAM	48 GB
Storage	1 TB HDD
Virtualization	V16.1.1
Number of VMs	3
VM Operating System	Ubuntu 20.04.3 LTS
VM RAM	4 GB
VM CPUs	2
VM Storage	20 GB HDD

for this study comprises four main components: a business server, an IPFS (InterPlanetary File System) server, a blockchain node server, and a cloud server configured for simulating homomorphic operations. Below are detailed specifications of the system configurations used in the experiment.

The blockchain platform utilized in this study is FISCO BCOS, an enterprise-grade consortium blockchain platform that was open-sourced by the Financial Blockchain Shenzhen Consortium (FISCO) in 2017. It features high performance, security, stability, and ease of use. Supporting various development languages and smart contract engines, FISCO BCOS offers comprehensive development kits and application cases, building a domestic open-source consortium blockchain ecosystem that spans multiple industries and fields. The core philosophy of FISCO BCOS is to use blockchain as the infrastructure for multi-party collaboration, integrating with existing business systems to enable data sharing and value transfer. FISCO BCOS employs a multi-chain architecture to enhance system concurrency and cross-chain interoperability, balancing regulatory communication and compliance, thereby catering to the Chinese market environment. FISCO BCOS stands as a one-stop solution for blockchain applications across various sectors, combining international standards with domestic features.

7.2. Performance

To evaluate the performance of the FISCO BCOS blockchain platform, this study meticulously measured its average transaction latency and blockchain throughput. Average transaction latency refers to the network delay experienced during transaction processing, while blockchain throughput is defined as the number of transactions the system can process per second. These critical metrics shed light on the blockchain system’s response speed and processing capacity, essential for assessing overall system performance.

The experimental setup involved the FISCO BCOS hybrid storage blockchain system, with a focus on varying transaction volumes across three distinct transaction operations: AddUser (adding chain participants), Generate (block generation and node addition), and Send (on-chain transmission of basic information). By analyzing average transaction latency and throughput across different operations and transaction volumes, the aim was to comprehensively evaluate system performance. The experiment revealed a linear positive correlation between increasing transaction volumes and both average transaction latency and blockchain throughput. The trends in performance changes for adding nodes and information on-chain were consistent across these metrics, aligning with blockchain’s fundamental characteristics—namely, that block size and the number of transactions within a block directly impact average transaction latency and throughput. Notably, the system showcased exceptional performance, with average transaction latencies maintained under 1 s and throughput demonstrating a positive growth trend.

In Figure 4a,b, when examining the AddUser operation, latency increased from 0.29 s with 100 transactions to 0.47 s with 1000 transactions, reflecting a manageable growth in response time as transaction volume expanded. Concurrently, throughput for the AddUser operation evolved from 47.5 transactions per second (TPS) with 100 transactions to 382.8 TPS with 1000 transactions, illustrating the system’s capacity to handle escalating transaction loads efficiently. These results underscore the FISCO BCOS blockchain platform’s effectiveness and high performance in managing a substantial volume of transactions, highlighting its potential for efficient data processing and transaction verification.

In assessing the performance of homomorphic encryption operations within our system, which crucially incorporates both hybrid storage blockchain and homomorphic encryption computations, we note that the computational time of homomorphic encryption significantly impacts the overall efficiency of the system. This paper undertakes an evaluation of the homomorphic encryption algorithm used in our system through three experimental segments.

Homomorphic encryption and decryption times constitute a major component of homomorphic computations, with the duration of these processes being related to the dataset size. Experiments were conducted on three datasets of the same content but varying sizes: 5, 50, and 500 datasets (Figure 5). Our findings reveal that as the size of the dataset increases, the encryption and decryption times of homomorphic encryption also multiply, although the decryption process consumes relatively less time.

The experiments tested the computational time for addition operations under homomorphic encryption, performing calculations on 5, 50, and 500 identical datasets. With the increase in the number of computations, the time required for homomorphic addition operations similarly grows. While computational times remain modest for smaller datasets, larger datasets exhibit a more significant time consumption. As dataset sizes expand, the encryption and decryption processes, crucial for maintaining data privacy while enabling computation, increasingly burden system efficiency.

The proposed framework demonstrates that combining consortium-blockchain anchoring with off-chain encrypted storage and homomorphic verification can achieve a workable balance between auditability and confidentiality in cross-jurisdiction data exchange. By logging only cryptographic digests and structured compliance evidence on-chain, the architecture supports verifiable accountability without exposing sensitive payloads, while the hybrid storage design mitigates on-chain scalability pressure.

Nevertheless, several practical limitations remain. First, homomorphic computation tends to dominate end-to-end latency as data volume grows, which may constrain real-time deployment in high-throughput settings unless further optimization or batching strategies are applied. Second, operational key management across jurisdictions introduces nontrivial complexity that can affect both security and usability. Third, the security and integrity of consortium operation still rely on governance and consensus assumptions, adverse collusion beyond the assumed threshold can weaken guarantees, and enforcement mechanisms may vary by jurisdiction. Fourth, off-chain availability depends on IPFS replication and incentive policies, and encrypted payloads may still leak behavioral metadata through observable transaction traces. Future work will therefore focus on strengthening the protocol layer with richer compliance proofs (e.g., zero-knowledge techniques), improving smart-contract assurance via formal verification, and validating the architecture in pilot deployments that reflect real regulatory workflows and cross-jurisdiction operational constraints.

8. Conclusions

This study presents a framework for cross-jurisdiction data verification that integrates privacy-preserving computation, consortium blockchain, and decentralized storage. The framework addresses three practical challenges in cross-border data exchange: fragmented regulations, privacy risks, and limited institutional trust. By enabling verification without exposing sensitive payloads, the proposed design helps reduce governance friction while improving auditability and accountability.

The core technical contribution is an evidence–payload separation architecture; cryptographic digests and structured compliance evidence are anchored on-chain, while encrypted payloads remain off-chain under homomorphic computation and secure storage protection. In addition, we introduce a three-party evolutionary-game layer to explain how domestic enterprises, foreign enterprises, and cross-border platforms may adjust compliance collaboration under heterogeneous incentives. This behavioral perspective complements the technical workflow and provides guidance for mechanism design aimed at sustaining cooperation.

Future work will focus on strengthening the verification layer with richer compliance proofs (e.g., zero-knowledge techniques), improving smart-contract assurance through formal verification, and validating the framework in pilot deployments that match real regulatory workflows.