1. Introduction
The rapid digitization of healthcare has fundamentally transformed clinical data management through the widespread adoption of Electronic Health Records (EHRs), substantially improving patient care workflows and the accessibility of medical information [1]. However, this digitization has simultaneously exposed deep structural vulnerabilities in centralized healthcare data architectures. Centralized systems concentrate sensitive patient data in single points of failure, making them prime targets for cyberattacks — the healthcare sector reported over 700 significant data breaches in 2023 alone, exposing more than 133 million patient records [2]. Beyond security, centralized architectures impose fundamental constraints on patient data ownership, cross-institutional interoperability, and the ability to support decentralized scientific collaboration at scale.
Blockchain technology has emerged as a structurally promising response to these challenges, offering decentralized, immutable ledger infrastructure that enables secure and transparent data sharing without reliance on central authorities. Permissioned blockchain frameworks including MedRec, FHIRChain, and HealthChain have demonstrated meaningful improvements in data integrity and access control within clinical settings [3–5]. However, these systems exhibit three persistent limitations that prevent their adoption as comprehensive healthcare research infrastructure. First, they rely on computationally intensive consensus mechanisms — primarily PBFT variants with O(n2) communication complexity — that do not scale efficiently beyond small validator sets. Second, they employ identity disclosure-dependent access control mechanisms that are fundamentally incompatible with the privacy requirements of sensitive medical research data. Third, and most critically, they were not designed to support the principles of Decentralized Science (DeSci) — patient-centric data ownership, transparent governance, and incentive-aligned participation in the research process [6].
DeSci represents a transformative paradigm shift in how scientific research is organized, funded, and executed. By leveraging blockchain, decentralized autonomous organizations (DAOs), and token-based incentive mechanisms, DeSci enables transparent, trust-minimized, and collaborative biomedical research ecosystems that reduce dependence on centralized institutions [6]. Despite its transformative potential, the integration of DeSci principles into healthcare-grade blockchain frameworks remains an open research problem. Existing DeSci platforms lack the privacy-preserving authentication mechanisms required for sensitive medical data, and existing healthcare blockchain systems lack the governance and incentive infrastructure required for genuine decentralized research participation.
1.1. Research Questions
This work is motivated by the following three research questions:
RQ1: Can a lightweight hybrid blockchain architecture simultaneously achieve the scalability, privacy-preservation, and Byzantine fault tolerance required for healthcare-grade decentralized research infrastructure?
RQ2: Can Zero-Knowledge Proof-based authentication provide formally verifiable, trust-minimized access control for sensitive medical data without disclosing user identity or credentials?
RQ3: Can a DAO-based governance and tokenomics model sustainably incentivize decentralized participation among patients, researchers, and validators in a healthcare research ecosystem?
1.2. Proposed Approach and Novelty
To address these research questions, this paper proposes a DeSci-driven lightweight hybrid blockchain framework that integrates a permissioned blockchain, a hybrid PBFT–PoA consensus mechanism, off-chain storage, and Groth16 zk-SNARK-based authentication into a unified architecture [7]. A DAO-based governance layer with formally defined proposal lifecycle states and quadratic-inspired voting weights, and a tokenomics model with explicit incentive allocation and sustainability conditions, are incorporated to incentivize decentralized research participation.
The novelty of the proposed framework lies in four specific contributions that, to the best of the authors' knowledge, have not been simultaneously addressed in any prior work:
(i) The first integration of Groth16 zk-SNARK authentication with formally verified game-based security proofs (Authentication Soundness, Data Integrity, Privacy Preservation) into a permissioned healthcare blockchain framework.
(ii) A hybrid PBFT–PoA consensus design with explicit transaction class routing — high-stakes transactions through PBFT for Byzantine fault tolerance, routine transactions through PoA for efficiency — with formal immutability guarantees through chained SHA-256 block hashing.
(iii) A formally specified DAO governance model with a six-state proposal lifecycle, quadratic-inspired anti-plutocracy voting weights, quorum requirements, proposal deposit and slashing, and an emergency veto mechanism — the first such formal governance specification in a healthcare blockchain context.
(iv) An integrated tokenomics model with explicit allocation percentages (patients 40%, researchers 30%, validators 20%, treasury 10%), validator slashing parameters, and a formal sustainability condition ensuring economic viability over time.
The framework is evaluated exclusively through simulation at this stage, and the absence of a fully deployed prototype is explicitly acknowledged as a current limitation. Prototype-level implementation on Hyperledger Fabric or Ethereum is identified as immediate future work.
1.3. Main Contributions
The main contributions of this paper are as follows:
A DeSci-driven lightweight hybrid blockchain architecture combining permissioned blockchain, hybrid PBFT–PoA consensus, off-chain storage, and Groth16 zk-SNARK-based access control into a unified DeSci-aligned framework for decentralized healthcare research, directly addressing RQ1.
A formally specified ZKP-based privacy-preserving authentication mechanism with concrete Groth16 parameters (192-byte proof size, ~5 ms on-chain verification, O(1) verification complexity), formal game-based security proofs, and replay attack prevention through block-hash-anchored per-request challenges, directly addressing RQ2.
A formally modeled DAO governance and tokenomics layer with a six-state proposal lifecycle finite state machine, quadratic-inspired anti-plutocracy voting, explicit token allocation formulas, validator slashing conditions, and a formal economic sustainability constraint, directly addressing RQ3.
A simulation-based performance evaluation demonstrating improved transaction latency, throughput, and computational efficiency relative to MedRec, FHIRChain, and HealthChain across network sizes of 10–50 nodes, with explicit characterization of evaluation methodology, normalization procedures, and limitations.
1.4. Paper Organization
The remainder of this paper is organized as follows. Section 2 reviews related work across blockchain-based healthcare systems, ZKP-based authentication, DeSci governance, and consensus mechanism optimization. Section 3 presents the problem statement and identifies the specific research gaps motivating the proposed work. Section 4 describes the proposed methodology in detail, covering the system model, architecture, hybrid consensus mechanism, data integrity model, ZKP-based access control, governance and tokenomics design, and system workflow. Section 5 provides a rigorous security and privacy analysis including formal game-based security proofs. Section 6 presents the simulation-based performance evaluation, comparative analysis, and discussion of results. Section 7 concludes the paper and outlines directions for future work.
2. Related Work
Research at the intersection of blockchain technology, healthcare data management, and decentralized science has grown substantially in recent years. This section reviews the most relevant prior work across four thematic areas: blockchain-based healthcare systems, privacy-preserving authentication mechanisms, decentralized governance and tokenomics, and consensus mechanism optimization. The gaps identified across these areas collectively motivate the proposed framework.
2.1. Blockchain-Based Healthcare Data Management
Early blockchain-based healthcare systems established the principle of using distributed ledgers to improve data integrity and access control. MedRec introduced a permissioned blockchain architecture for managing Electronic Health Records (EHRs), letting patients control access to their data through smart contracts, but its reliance on Ethereum's public blockchain infrastructure introduced scalability limitations and high computational overhead [3]. FHIRChain aligned blockchain-based data sharing with the HL7 FHIR standard to improve interoperability, but did not address privacy-preserving authentication, leaving user credentials exposed during access control operations [4]. HealthChain combined role-based access control with cryptographic audit trails in a consortium blockchain, improving throughput over public blockchain alternatives [5]. None of these systems incorporated Zero-Knowledge Proof-based authentication, decentralized governance, or DeSci-aligned incentive mechanisms. More recent work has targeted the scalability limitations of these earlier systems: Raja et al. [8] proposed MediCon, a reputation-based consensus protocol that reduced latency relative to standard PBFT; Myeong and Ram [9] integrated ZKP-based protocols into healthcare blockchain architectures without addressing governance or tokenomics; and Husnain et al. [10] proposed HealthChain for secure, interoperable EHRs, achieving improved latency but without DeSci alignment or formal security proofs. The present work builds on these contributions by integrating hybrid consensus, ZKP authentication, and DeSci-aligned governance into a unified architecture.
2.2. Privacy-Preserving Authentication Using Zero-Knowledge Proofs
Zero-Knowledge Proofs have emerged as a powerful cryptographic primitive for privacy-preserving authentication in distributed systems. The theoretical foundations of ZKPs, established by Goldwasser, Micali, and Rackoff, guarantee that a prover can demonstrate knowledge of a secret without revealing the secret itself [11]. Practical instantiations such as zk-SNARKs (Zero-Knowledge Succinct Non-Interactive Arguments of Knowledge), particularly the Groth16 construction, have made ZKP verification computationally efficient enough for deployment in blockchain smart contracts, with on-chain verification costs of O(1) with respect to network size [12].
In healthcare contexts, ZKP-based authentication has been explored for selective disclosure of patient attributes, enabling patients to prove eligibility for clinical trials without revealing their full medical history. Kaur et al. [13] demonstrated the integration of zero-trust principles with blockchain and ZKPs for securing fog computing environments in healthcare, achieving improved privacy guarantees over role-based alternatives. Khan et al. [14] proposed a blockchain-enabled searchable encryption framework for medical IoT systems that incorporated ZKP elements for access control. However, these systems evaluated ZKP primarily as an isolated component rather than as part of an integrated DeSci-aligned framework with formal game-based security proofs. The present work addresses this gap by providing formal Authentication Soundness, Data Integrity, and Privacy Preservation game definitions that ground the ZKP security claims in standard cryptographic assumptions.
2.3. Decentralized Science, Governance, and Tokenomics
Decentralized Science (DeSci) represents an emerging paradigm that applies blockchain, decentralized autonomous organizations (DAOs), and token-based incentive mechanisms to scientific research processes. Shilina [6] provided a comprehensive analysis of tokenized science economies, demonstrating how token incentives can reduce dependence on centralized funding bodies and increase research participation diversity. Wang et al. [15] proposed a Decentralized Virtual Research Environment that enabled peer-to-peer data sharing and collaboration through blockchain-based provenance tracking, demonstrating the feasibility of DeSci principles in practice.
Verma et al. [16] examined tokenomics models for digital ecosystems, establishing design principles for sustainable incentive structures that balance patient, researcher, and validator interests. Hasan et al. [17] explored the use of blockchain for audit trails in research information management systems, demonstrating that immutable on-chain records could satisfy regulatory compliance requirements for scientific data. However, existing DeSci frameworks have not been integrated with healthcare-grade privacy-preserving authentication or formally analyzed consensus mechanisms. The present work addresses this gap by embedding a DAO-based governance model with defined voting mechanics, proposal lifecycle management, and token distribution within a formally analyzed blockchain architecture.
2.4. Consensus Mechanism Optimization
The choice of consensus mechanism fundamentally determines the performance and security characteristics of a blockchain system. Md Shafin and Reno [18] provided a comprehensive analysis of the blockchain trilemma — the inherent tension between security, scalability, and decentralization — demonstrating that no single consensus mechanism simultaneously optimizes all three properties. PBFT offers strong Byzantine fault tolerance with O(n2) communication complexity, making it suitable for permissioned networks with bounded validator sets but impractical for large-scale deployments [19]. Proof of Authority (PoA) reduces communication overhead by relying on pre-approved validator identities, achieving lower latency at the cost of reduced decentralization [20]. A broader survey of blockchain's core properties, including decentralization, consensus, and tamper-resistance across application domains, further contextualizes these consensus trade-offs [20].
Zhang et al. [19] proposed a genetic algorithm-based node selection mechanism for PBFT in consortium blockchains, demonstrating that selective validator participation could significantly reduce consensus overhead while maintaining fault tolerance guarantees. Ahn et al. [21] conducted a bibliometric analysis of blockchain consensus mechanisms, identifying hybrid approaches as the most promising direction for balancing performance and security in permissioned settings. The present work builds on these findings by adopting a hybrid PBFT–PoA design that routes high-stakes transactions through PBFT and routine transactions through PoA, achieving a practical balance between Byzantine fault tolerance and computational efficiency.
2.5. Summary and Research Gap
Table 1 summarizes the comparison of the proposed framework with the most closely related prior work across five key dimensions.
Table 1.
Comparison of the proposed framework with related work.
| System | ZKP Auth. | DAO Governance | Hybrid Consensus | Tokenomics | DeSci Alignment |
|---|---|---|---|---|---|
| MedRec | ✗ | ✗ | ✗ | ✗ | ✗ |
| FHIRChain | ✗ | ✗ | ✗ | ✗ | ✗ |
| HealthChain | ✗ | ✗ | Partial | ✗ | ✗ |
| MediCon [8] | ✗ | ✗ | ✓ | ✗ | ✗ |
| Kaur et al. [13] | Partial | ✗ | ✗ | ✗ | ✗ |
| Wang et al. [15] | ✗ | Partial | ✗ | ✗ | Partial |
| Proposed | ✓ | ✓ | ✓ | ✓ | ✓ |
As Table 1 demonstrates, no existing system simultaneously addresses all five dimensions. The proposed framework is the first to integrate ZKP-based privacy-preserving authentication, DAO-based governance with formal voting mechanics, hybrid PBFT–PoA consensus, tokenomics-driven incentives, and DeSci alignment within a unified healthcare blockchain architecture. This integration constitutes the primary novelty claim of the present work.
3. Problem Statement
Although blockchain adoption in healthcare is growing, no existing framework provides a unified architecture that simultaneously ensures computational scalability, cryptographic privacy preservation, and decentralized research participation. This gap arises from a combination of architectural trade-offs and design constraints inherent in current systems [22].
3.1. Scalability and Computational Overhead
The majority of blockchain-based healthcare systems rely on resource-intensive consensus algorithms that introduce significant transaction latency, communication overhead, and reduced throughput as network size grows [23]. Classical Byzantine Fault Tolerant protocols such as PBFT exhibit O(n2) communication complexity, making them impractical for large-scale deployments. These limitations render existing frameworks unsuitable for real-time or high-throughput healthcare applications, particularly in environments with resource-constrained devices [24].
3.2. Insufficient Privacy-Preserving Access Control
Current systems predominantly rely on identity-based or role-based access control mechanisms that require explicit disclosure of user credentials. In healthcare contexts where even partial identity exposure constitutes a privacy violation, such mechanisms are inadequate. Advanced cryptographic primitives such as Zero-Knowledge Proofs (ZKPs), which enable a user to prove compliance with an access policy without revealing any identifying information, remain absent from most deployed healthcare blockchain architectures [25]. This limits the ability to support truly privacy-preserving, trust-minimized data access [22].
3.3. Absence of DeSci Alignment
The most significant gap is the misalignment between existing healthcare blockchain solutions and DeSci principles. DeSci promotes patient-centric data ownership, decentralized governance, and incentive-driven participation. However, existing frameworks do not support trustless collaboration among patients, researchers, and healthcare providers as co-equal participants. Specifically, no current framework provides an integrated infrastructure for privacy-preserving involvement in decentralized clinical research, data sovereignty, and auditable data provenance in a manner consistent with DeSci [26,27]. Addressing this gap requires a coherent system design incorporating efficient consensus mechanisms, cryptographic access controls, and decentralized governance — which is the central motivation of the present work [15].
4. Proposed Methodology
4.1. System Model
The proposed framework is modeled as a distributed system comprising six interconnected components. Formally, the system is defined as (Equation (1)):
where E denotes the set of network entities (patients, healthcare providers, researchers, and validators), B represents the permissioned blockchain ledger, 𝒟 is the off-chain distributed storage layer, 𝒞 is the set of smart contracts governing access control and audit trails, 𝒢 is the DAO-based governance module, and 𝒯 is the tokenomics model [8].
Each transaction recorded in the system takes the form given in (Equation (2)) :
where H(D) is the cryptographic hash of the associated medical data D, π is the Zero-Knowledge Proof submitted by the requesting entity, C is the access control policy enforced by the relevant smart contract, τ is the timestamp, and σ is the digital signature of the submitting entity.
This formal model ensures that no raw medical data is ever written to the blockchain. Only the hash H(D) and associated metadata are recorded on-chain, preserving both patient privacy and data immutability across the decentralized infrastructure.
4.2. System Architecture
The system architecture organizes the entities and components of Section 4.1 into five interacting layers that separate data storage from verification, and transaction processing from governance. This separation of concerns is a deliberate design choice to maintain scalability and modularity. The architecture is built around: (i) an Entity Layer of patient, provider, researcher, and validator nodes; (ii) a Permissioned Blockchain Layer recording only hashes and metadata on-chain; (iii) an Off-Chain Storage Layer for large medical data via IPFS or encrypted cloud; (iv) a Smart Contract Layer enforcing access control and audit trails; and (v) a DeSci Governance Layer supporting DAO-based decentralized policy decisions [9]. The separation between data storage and verification allows the framework to achieve privacy without sacrificing auditability, while the governance layer ensures that policy decisions are transparent and stakeholder-driven.
Figure 1 illustrates the proposed system architecture, detailing the interaction between decentralized data sources, hybrid off-chain storage, and the core blockchain network. The framework leverages a dedicated security layer featuring Zero-Knowledge Proof (ZKP) authentication and a hybrid PBFT–PoA consensus module to ensure privacy-preserving, verifiable data governance.
Figure 1:
System architecture of the proposed DeSci-driven lightweight hybrid blockchain framework for privacy-preserving and incentive-aware decentralized healthcare research.
4.3. Hybrid Consensus Mechanism
The consensus mechanism is central to both the performance and the integrity of the proposed framework [28]. The design challenge is to minimize computational overhead and communication complexity while preserving the Byzantine fault tolerance necessary for a healthcare-grade permissioned network. To address this, a hybrid PBFT–PoA (Practical Byzantine Fault Tolerance / Proof of Authority) mechanism is adopted in which the two protocols operate on distinct transaction classes. PBFT handles high-stakes transactions such as new data registrations, access policy updates, and ZKP verification results, where Byzantine fault tolerance is essential. PoA, which relies on pre-approved validator identities rather than computational puzzles, handles routine transactions such as tokenomics reward distributions and governance voting records. This division of labor reduces the proportion of transactions subject to the expensive O(n2) PBFT communication complexity, effectively lowering the average consensus overhead across the network. In the workload modeled for this evaluation, routine transactions (tokenomics reward distributions, governance voting records, and provenance queries) are assumed to constitute approximately 70% of total transaction volume, with the remaining 30% classified as high-stakes transactions (data registrations, access policy updates, and ZKP verification results) routed through PBFT. This 70:30 split is a modeling assumption informed by typical healthcare research access patterns rather than an empirically measured distribution from a deployed system, and the sensitivity of the latency and throughput results reported in Section 6 to this assumed ratio is identified as a direction for future empirical validation.
A hybrid PBFT–PoA consensus is adopted, with communication complexity C(n) = O(n2) for the PBFT component. For n = 50 validators, this produces at most 2,500 message exchanges per round — feasible within the evaluated latency budget. The permissioned setting bounds n to a controlled set, and the PoA component further reduces overhead for routine transactions to O(n).
Immutability Guarantees: Immutability in the proposed system is achieved through two complementary mechanisms. First, each block in the permissioned blockchain contains the SHA-256 hash of its predecessor, creating a cryptographically linked chain. Any modification to a historical block would alter its hash, invalidating all subsequent block hashes and requiring consensus of the full validator set to reconstruct the chain — an attack that is computationally infeasible and practically impossible to coordinate in a permissioned network with identity-verified validators. Second, all transaction hashes, ZKP verification outcomes, and access logs are written as immutable records that cannot be deleted or overwritten. Together, these properties ensure that the audit trail for every data access event is permanent and tamper-evident, satisfying the provenance and accountability requirements of a DeSci ecosystem.
4.4. Data Integrity Model
Cryptographic hashing is used to ensure the integrity of patient data, as formalized in (Equations (3)–(5)) [29]:
Actual medical information is stored off-chain and only hash and metadata remain on-chain so as to assure integrity without exposing sensitive data.
4.5. ZKP-Based Access Control
Privacy-preserving access control is implemented through Zero-Knowledge Proofs (ZKPs), specifically using the Groth16 zk-SNARK construction [12]. Groth16 is selected because it provides the smallest proof sizes and fastest on-chain verification times among currently deployed zk-SNARK schemes, making it well-suited for smart contract execution on a permissioned blockchain. The Groth16 construction operates over a bilinear pairing group and requires a one-time trusted setup ceremony to generate the proving key (pk) and verification key (vk) for a given access policy circuit.
4.5.1. Circuit Design
The access control policy C is encoded as an arithmetic circuit over a prime field Fp. For the attribute-based access policies evaluated in this work, comprising up to 10 patient data attributes (e.g., age range, diagnosis category, consent status, institution affiliation), the resulting circuit contains approximately 2,000-5,000 arithmetic gates. The circuit takes as private input the user's credential witness w (e.g., a set of attribute values and a credential signature) and as public input the access policy commitment C and a per-request challenge derived from the current block hash and nonce. The circuit outputs a single bit: 1 if the witness satisfies the policy, 0 otherwise.
4.5.2. Key and Proof Sizes
For the evaluated circuit size range (2,000–5,000 gates), the Groth16 construction produces the concrete parameters summarized in Table 2:
Table 2.
Groth16 zk-SNARK parameters for the evaluated access policy circuits (2,000–5,000 gates).
| Parameter | Value |
|---|---|
| Proving key size (pk) | 8–18 MB |
| Verification key size (vk) | ~1 KB (constant) |
| Proof size | 192 bytes (constant, independent of circuit size) |
| Proof generation time (client-side) | 80–200 ms |
| On-chain verification time | ~5 ms (3 pairing operations) |
| Trusted setup | One-time per circuit (Powers of Tau ceremony) |
The constant 192-byte proof size and ~5 ms on-chain verification time are key advantages of Groth16 for blockchain deployment. Regardless of the complexity of the access policy circuit, the on-chain verifier always executes three bilinear pairing operations, giving O(1) verification cost with respect to both circuit size and network size n. This is in contrast to proof generation, which scales with circuit complexity and is performed entirely off-chain by the requesting entity.
4.5.3. Formal ZKP Properties
The verification process is defined by (Equations (6) and (7)):
where vk is the public verification key, π is the 192-byte proof, and C is the access policy commitment. The construction satisfies three formal cryptographic properties:
(i) Completeness: Any user genuinely satisfying policy C will always generate a valid proof, as stated in (Equation (8))
(ii) Soundness: The probability that an unauthorized entity successfully forges a valid proof without possessing valid credentials is bounded by a negligible function, as given in (Equation (9)) :
This follows from the knowledge-soundness of the Groth16 construction under the q-PKE and q-PDH assumptions over a bilinear pairing group.
(iii) Zero-Knowledge: The proof π leaks no information about the user's private credential witness w. For any polynomial-time verifier V, there exists a simulator S that produces proofs computationally indistinguishable from genuine proofs without access to w, as expressed in (Equation (10)) :
4.5.4. Replay Attack Prevention
Each proof π is bound to a specific access request through the per-request challenge, which is computed as shown in (Equation (11)) :
where H is SHA-256, block_hash is the hash of the most recent confirmed block at the time of the request, nonce is a monotonically increasing per-requester counter stored on-chain, and requesteraddress is the blockchain address of the requesting entity. This binding ensures that a proof generated for one access request is cryptographically invalid for any other request, preventing replay attacks without requiring session token storage or centralized nonce management.
4.5.5. Limitations and Future Directions
The Groth16 construction requires a trusted setup ceremony, which introduces a single point of trust during initialization. In a multi-institutional healthcare deployment, coordinating a multi-party computation ceremony (e.g., Powers of Tau) across hospitals, research institutions, and regulatory bodies is a non-trivial operational undertaking, requiring governance over participant selection, secure disposal of the ceremony's secret shares, and independent auditability of the ceremony transcript; this operational burden, rather than the underlying cryptographic risk, is the primary practical obstacle to deployment. Migrating the present circuit design to a transparent-setup proof system such as PLONK or STARKs would eliminate this trust assumption, but would require re-engineering the arithmetic circuit to the target system's constraint format and would substantially increase proof size (PLONK: ~400 bytes; STARKs: ~45-200 KB), with a corresponding increase in on-chain verification cost; this trade-off between trust minimization and proof size/verification overhead is left for future evaluation. Additionally, the reported proof generation time of 80-200 ms is a per-request, client-side cost excluded from on-chain latency metrics; for a researcher issuing many sequential access requests, this overhead accumulates and may affect usability even though it does not affect blockchain throughput. Proof batching across sequential requests from the same requester and hardware acceleration of the underlying multi-scalar multiplication are identified as candidate optimizations, and an empirical assessment of whether the current overhead is acceptable in practice is deferred to the planned prototype evaluation.
4.6. Governance and Tokenomics
The governance and tokenomics components elevate the proposed framework from a standard permissioned blockchain system to a fully DeSci-aligned research infrastructure. These two components are tightly coupled: the tokenomics model determines voting weights within the governance system, while the governance system controls the parameters of the tokenomics model. Together they form a self-regulating, decentralized policy layer that operates without reliance on any central authority.
4.6.1. DAO Governance Model
The governance model is implemented as a Decentralized Autonomous Organization (DAO) whose decision-making process is formally modelled as a finite state machine. Each governance proposal P passes through a sequence of well-defined states, with transitions triggered by on-chain events.
Formally, the governance lifecycle is defined as a tuple in (Equation (12)) :
where S = {Proposed, Active, Passed, Rejected, Executed, Expired} is the set of states, s0 = Proposed is the initial state, Σ is the set of triggering events, and δ: S × Σ → S is the state transition function.
The state transitions are defined as follows:
Proposed → Active: Triggered when a registered stakeholder submits a valid proposal on-chain with a minimum token deposit Dmin(anti-spam threshold). The proposal enters the active voting period of fixed duration Tvote = 7 days.
Active → Passed: Triggered at the end of Tvote if two conditions are simultaneously satisfied: (i) total participating voting weight exceeds the quorum threshold Qmin = 10% of total circulating token supply, preventing low-participation governance attacks; and (ii) the proposal receives supermajority support
Vpass > 66% of participating voting weight.
Active → Rejected: Triggered at the end of Tvote if either condition for Passed is not met — quorum is not reached, or support falls below Vpass = 66%.
Active → Expired: Triggered if the proposal is not resolved within Tvote + Tgrace, where Tgrace= 2 days is a grace period allowing late votes in the event of network disruption.
Passed → Executed: Triggered after an execution delay Texec = 2 days following the Passed transition. The execution delay provides stakeholders a window to react to governance decisions before they take effect, mitigating the impact of malicious or erroneous proposals that passed through legitimate voting.
Passed → Expired: Triggered if the passed proposal is not executed within Texec + Texpiry, where Texpiry = 14 days, preventing indefinitely pending proposals from accumulating on-chain.
Figure 2 illustrates the complete DAO proposal lifecycle as a state machine diagram.
Figure 2.
DAO governance proposal lifecycle state machine.
4.6.2. Voting Mechanism and Anti-Plutocracy Measures
Each stakeholder's voting weight Vi is computed as shown in (Equation (13)) :
where Ti is the token balance of stakeholder i and Si is their participation score — a measure of historical governance engagement — computed as the fraction of past proposals in which stakeholder i cast a valid vote. This formulation uses a square root weighting on token balance, inspired by quadratic voting principles, to reduce the influence of large token holders while still rewarding long-term participation. Pure token-weighted voting (Vi = Ti) would allow a sufficiently wealthy adversary to dominate governance decisions; the square root dampening ensures that doubling token holdings produces only a √2 ≈ 1.41× increase in voting weight rather than a 2 × increase.
The following anti-plutocracy and anti-manipulation safeguards are incorporated:
(i) Minimum quorum requirement: Qmin= 10% of total circulating supply must participate for a vote to be valid, preventing a small coordinated group from passing proposals during low-participation periods.
(ii) Proposal deposit and slashing: The proposer must deposit Dmin tokens when submitting a proposal. If the proposal is Rejected, the deposit is partially slashed (50% burned, 50% redistributed to participating voters), disincentivizing spam proposals and malicious governance attacks.
(iii) Timelock on execution: The Texec = 2-day execution delay allows stakeholders who disagree with a passed proposal to exit the ecosystem before the change takes effect, reducing the risk of governance-driven value extraction.
(iv) Emergency veto: A supermajority of validators (> 75% of the validator set) can trigger an emergency veto on any Passed proposal within the Texec window, providing a last-resort safeguard against clearly malicious governance outcomes. Emergency vetoes are themselves subject to on-chain logging and are limited to one per 30-day period per validator to prevent abuse.
4.6.3. Tokenomics Model
The tokenomics model defines the incentive structure that sustains participation across four stakeholder roles. The total token supply is fixed at Tmax, with distribution governed by the following allocation defined in (Equation (14)) :
where:
Tpatients (40%): Reward pool for patient data contributors. Patients receive token rewards Rp proportional to data quality score Qd assigned by validators: Rp = α × Qd × Tbase, where α is a scaling factor and Tbase is the base reward per contribution. Data quality is assessed on completeness, format compliance, and provenance verifiability.
Tresearchers (30%): Access deposit pool. Researchers deposit tokens Dr to request dataset access. Upon successful ZKP verification and data access, Dr is distributed as: 60% to the contributing patient, 25% to the validator who processed the request, and 15% to the DAO treasury.
Tvalidators (20%): Consensus and verification reward pool. Validators receive rewards for PBFT consensus participation and ZKP proof verification. Validators who equivocate or submit invalid verifications are subject to slashing: a fraction fslash = 0.1 of their staked tokens is burned, and they are temporarily suspended from the validator set for Tsuspend = 48 hours.
Ttreasury (10%): DAO treasury, funded additionally by a 1% transaction fee on all token movements. The treasury funds protocol development, independent security audits, and ecosystem grants, governed by DAO proposals.
The sustainability condition for the tokenomics model requires that the total token outflow (rewards distributed) does not exceed total token inflow (deposits, fees, and newly minted tokens) over any 30-day window, as expressed in (Equation (15)) :
where ∑Rp is the total patient reward distributed, ∑Rv is the total validator reward distributed, ∑Dr is the total researcher deposit collected, ∑Ftx is the total transaction fee collected and ΔTmint is the token emission rate, which follows a halving schedule every 365 days to control inflation.
It is important to note that this governance and tokenomics design is a formal model whose practical feasibility has not been empirically validated. Patient engagement in governance processes is consistently reported to be low in real-world healthcare settings, and it is not established that the 40% patient token allocation would translate into active, informed voting participation rather than passive token accumulation. Token-based incentive and voting mechanisms of this kind also raise open legal and regulatory questions, for example whether patient reward tokens constitute a security or a form of compensation for data use under applicable health-data and financial regulations, that would require jurisdiction-specific legal review before deployment. The quadratic-inspired voting weight, quorum, and slashing mechanisms are grounded in established governance theory but have not, to the authors' knowledge, been tested in a healthcare-specific deployment; their behavioral and legal acceptability among patients, clinicians, and institutions remains an open empirical question that this paper does not resolve.
4.6.4. Provenance Tracking
Every data access event, governance vote, and token transaction is recorded as an immutable on-chain log entry, creating a comprehensive audit trail. Each provenance record takes the form shown in (Equation (16)) :
where governanceepoch identifies the active governance configuration at the time of the access event, enabling retrospective auditing against the policy rules that were in force. This audit trail supports regulatory compliance with GDPR Article 30 (records of processing activities) and HIPAA §164.312(b) (audit controls), and satisfies the DeSci principle of transparent, reproducible science by providing a verifiable record of all data contributions and accesses throughout the research lifecycle.
4.7. System Workflow
The proposed system works as follows:
a) Healthcare provider encrypts patient data D.
b) The provider computes H(D) and records it on-chain.
c) Actual data D is stored off-chain (IPFS/Cloud); only H(D) and associated metadata are recorded on-chain.
d) A researcher submits an access request on-chain, depositing the required token amount.
e) The requesting entity generates a Zero-Knowledge Proof π off-chain, demonstrating that their credentials satisfy policy C
f) Verify(vk, π, C): The smart contract verifies the submitted proof.
g) Upon successful verification, the smart contract releases access to the encrypted data.
h) Blockchain transactions are immutable.
The suggested DeSci-enabled healthcare data governance workflow is illustrated in Figure 3. To ensure data integrity, healthcare professionals encrypt data with the patient and compute a cryptographic hash and store it in the authorized blockchain. Off-chain storage of the actual medical records is done to enhance scalability and minimize overhead. A Zero-Knowledge Proof (ZKP) proves the request without disclosing important credentials when the researcher desires the data. Smart contracts establish proof and enforce access policy, making access only open when requirements are fulfilled. Data access transparency, policy resolutions, and incentives to engage patients and research are managed by a DAO governance layer, and a tokenomics layer, respectively. This workflow demonstrates how the proposed architecture enables the sharing of privacy-sensitive, safe data in a decentralized way in accordance with DeSci. Formally, workflow access decisions are given by (Equation (17)) :
using the verification predicate defined in Section 4.5, where U requests data D and A(U, D) is the resulting access decision.
Figure 3.
End-to-end workflow of the proposed DeSci-driven framework illustrating healthcare data encryption, on-chain hash registration, off-chain storage, ZKP-based access request verification, smart contract enforcement, and DAO governance-mediated token reward distribution.
A value of 1 means authorization and 0 means denial. This approach makes access control predictable, verifiable, and independent of centralized authority, following decentralized system trust minimization principles.
5. Security and Privacy Analysis
This section provides a rigorous security and privacy analysis of the proposed framework. The analysis is structured as follows. Section 5.1 establishes a formal adversarial model defining the adversary’s capabilities and objectives. Section 5.2 presents the formal game-based security definitions (Authentication Soundness, Data Integrity, Privacy Preservation) that ground all subsequent security claims in standard cryptographic definitions; presenting these definitions immediately after the adversary model ensures that later references to a specific game occur after, rather than before, that game has been defined. Sections 5.3 through 5.6 then analyze the framework's resistance to specific threat categories, data integrity violations, privacy breaches, authentication failures, and network-level attacks, drawing on the games established in Section 5.2. Together, these sub-sections demonstrate that the proposed system satisfies the core security properties of integrity, confidentiality, authentication soundness, and attack resistance, while being transparent about its limitations.
5.1. Adversary Model
The security analysis of the proposed framework is conducted under a formally defined adversarial model. Let 𝒜 represent a probabilistic polynomial-time adversary aiming to breach at least one of three security properties: data confidentiality, data integrity, or access control. The adversary operates in a semi-honest-and-malicious setting, meaning it may follow the protocol while passively inferring sensitive information, or deviate arbitrarily from the protocol to achieve its goals.
The adversary 𝒜 is modeled with the following specific capabilities:
(i) Unauthorized data access: submitting forged or replayed access requests to the smart contract in an attempt to retrieve protected medical data without valid credentials.
(ii) ZKP proof forgery: attempting to construct a valid Zero-Knowledge Proof π for an access policy C without possessing the required private credentials, exploiting computational assumptions underlying the proof system.
(iii) Data tampering: attempting to modify historical on-chain records or off-chain stored medical data to corrupt integrity guarantees.
(iv) Impersonation and replay attacks: reusing previously captured authentication proofs or transaction signatures to gain unauthorized access.
(v) Metadata inference: leveraging read access to all on-chain transaction data, including access logs and timestamps, to infer sensitive information about patients or researchers through transaction pattern analysis.
The security objective of the proposed framework is to ensure that the probability of 𝒜 succeeding at any of the above goals is bounded by a negligible function of the security parameter λ, as stated in (Equation (18)) :
The formal game-based definitions grounding these guarantees are given in Section 5.2, and theframework's resistance against each of these adversarial capabilities is analyzed in Sections 5.3 through 5.6.
5.2. Formal Security Model
The security of the proposed framework is grounded in three formal cryptographic game definitions, following the standard game-based security paradigm used in modern cryptography [11]. A game is a probabilistic interaction between a challenger 𝒞 and an adversary 𝒜 the system is considered secure with respect to a property if no polynomial-time adversary can win the corresponding game with non-negligible probability in the security parameter λ.
Game 1: Authentication Soundness (AS)
Setup: Challenger 𝒞 initializes the system with security parameter λ, generates the zk-SNARK public parameters, and defines an access policy C. 𝒞 provides the public verification key to 𝒜. Challenge: 𝒜 produces a proof π* without possessing valid credentials satisfying C.
Win condition: 𝒜 wins if Verify(π*, C) = 1.
Security guarantee: The system achieves authentication soundness if (Equation (19)) holds :
This follows directly from the knowledge-soundness of the underlying zk-SNARK scheme, which reduces to the q-PKE (q-Power Knowledge of Exponent) and q-PDH (q-Power Diffie-Hellman) assumptions over the bilinear pairing group used by Groth16, for the security parameter λ defined in the adversary model (Section 5.1).
Game 2: Data Integrity (DI)
Setup: Challenger 𝒞 initializes the blockchain with a sequence of data records {D1, D2, …, Dk, computing H(D¡) = SHA-256(Di) for each record and storing all hashes on-chain.
Challenge: 𝒜 selects an index i and produces a modified record Di' ≠ Di.
Win condition: 𝒜 wins if H(Di') = H(Di).
Security guarantee: The system achieves data integrity if (Equation (20)) holds:
This follows directly from the collision resistance of SHA-256. Any successful attack on data integrity would constitute a collision in SHA-256, which is computationally infeasible under standard assumptions.
Game 3: Privacy Preservation (PP)
Setup: Challenger 𝒞 initializes the ZKP system and generates two witnesses w0 and w1, both satisfying access policy C. 𝒞 randomly selects b ∈ {0, 1}, generates proof π_b using witness w_b, and sends π_b to 𝒜.
Challenge: 𝒜 attempts to determine which witness was used to generate π_b.
Win condition: 𝒜 wins if it correctly guesses b with probability greater than 1/2.
Security guarantee: The system achieves privacy preservation if (Equation (21)) holds :
This follows from the zero-knowledge property of the proof system. A successful attack would contradict the existence of the zero-knowledge simulator, which is guaranteed by the zk-SNARK construction, under the same q-PKE/q-PDH hardness assumptions and security parameter λ used throughout this analysis.
These three games together formally establish that the proposed system satisfies authentication soundness, data integrity, and privacy preservation within the bounds of the stated cryptographic assumptions. The security proofs reduce to well-studied hardness assumptions, ensuring that the framework's security guarantees are as strong as the underlying cryptographic primitives.
5.3. Data Integrity & Immutability
The structure uses SHA-256 cryptography to secure data. The blockchain stores the hash H(D) of any patient data D [21]. Because SHA-256 is collision-resistant, every change in D affects H(D), allowing tampering to be detected quickly.
Blockchain is unchangeable, therefore no one can change a hash without consensus. The hash function's collision resistance ensures data integrity, as stated in (Equation (22)) :
Additionally, the probability of a hash collision is negligible (Equation (23)) :
This reliably detects illegal healthcare data changes.
5.4. Privacy & Confidentiality
Healthcare data is sensitive and stored off-chain [13]. Blockchain stores just hashed references and metadata. This architecture minimizes raw data exposure and leakage. Even if storage systems are attacked, encryption technologies can restrict data access to authorized users. The assumption is that encryption techniques are computationally secure, ensuring confidentiality.
5.5. Authentication via Zero-Knowledge Proof
ZKP-based authentication secures the proposed framework against four principal authentication threats, each addressed through the cryptographic properties of the underlying zk-SNARK construction.
Against credential forgery: An adversary attempting to forge a valid ZKP π for access policy C without possessing valid credentials must solve a computationally hard problem equivalent to breaking the knowledge-soundness of the zk-SNARK scheme. Under standard cryptographic assumptions (e.g., hardness of the discrete logarithm problem or bilinear map assumptions used in Groth16), the probability of successful forgery is bounded by a negligible function: Pr[𝒜 forges π] ≤ negl(λ).
Against identity leakage: The zero-knowledge property formally guarantees that the smart contract verifier learns nothing about the prover's private credentials beyond the binary fact that they satisfy policy C. This is captured by the zero-knowledge simulator argument: for any verifier V, there exists a simulator S that produces proofs computationally indistinguishable from genuine proofs without access to the prover's secrets. Formally: Leakage(π) = 0.
Against replay attacks: Each ZKP instance incorporates a challenge derived from the current block hash and a per-request nonce, binding the proof cryptographically to a single access request. A proof generated for one request is therefore invalid for any other request, preventing replay attacks without requiring session token storage.
Against impersonation: Because proof generation requires knowledge of private credentials satisfying policy C, and because ZKP soundness guarantees that a valid proof can only be generated by an entity possessing such credentials, impersonation is computationally infeasible under the stated assumptions.
The formal verification criterion, and the associated Completeness, Soundness, and Zero-Knowledge properties, are defined once in Section 4.5 and are not repeated here; the adversarial-capability discussion above (this section) and the game-based proofs in Section 5.2 ground those properties in the specific authentication threats considered in this analysis.
The smart contract executes the verifier and returns an access decision without receiving, storing, or transmitting any sensitive credential information.
Figure 4 illustrates how ZKP-based authentication operates within the proposed framework. A requesting entity generates a cryptographic proof off-chain and submits it to the smart contract for on-chain verification. The smart contract evaluates the proof against the access policy and grants or denies access accordingly, without ever receiving the underlying credentials. Healthcare data remains encrypted off-chain and is made accessible only upon successful verification. This architecture eliminates identity disclosure, minimizes insider threat exposure, and replaces trust-based access control with cryptographic verification directly aligned with the trust-minimization principles of DeSci.
Figure 4.
ZKP-based privacy-preserving authentication architecture illustrating off-chain Groth16 zk-SNARK proof generation, on-chain smart contract verification via Verify(vk, π, C), access decision enforcement, and the zero-knowledge guarantee that no credential information is disclosed during the authentication process.
5.6. Attack Resistance
The proposed framework is designed to resist five categories of known attacks in blockchain-based healthcare systems. This section analyzes each attack vector and the corresponding defensive mechanism.
51% Majority Attack: The permissioned blockchain with identity-verified validators eliminates open-participation majority attacks. The PBFT component tolerates up to f < n/3 Byzantine validators; since all validators are credentialed and admitted through the DAO governance process, coordinating a majority attack requires compromising more than one-third of the validator set an assumption that exceeds the defined threat model.
Sybil Attack: Identity verification and controlled node admission in the permissioned network prevent adversaries from creating multiple pseudonymous validator identities. Each validator is uniquely credentialed, and new validators are admitted only through the DAO governance proposal process, which requires supermajority approval.
Replay Attack: As formalized in Section 4.5, each ZKP instance is bound to a unique per-request challenge computed as H(blockhash || nonce || requesteraddress). A proof generated for one access request is cryptographically invalid for any other, preventing replay attacks without requiring session token storage.
Impersonation: ZKP soundness guarantees that a valid proof can only be generated by an entity possessing private credentials satisfying policy C. Impersonation without valid credential possession is therefore computationally infeasible under the q-PKE and q-PDH hardness assumptions underlying Groth16.
Collusion and Data Tampering: SHA-256 collision resistance and blockchain immutability ensure that data tampering is detectable, as formally established in Game 2 (Section 5.2). Collusion among fewer than n/3 validators cannot produce a forged consensus outcome under PBFT's Byzantine fault tolerance guarantee.
Trust Minimization and DeSci Alignment: The framework builds trust exclusively through cryptographic verification rather than institutional trust. ZKP authentication eliminates identity disclosure, blockchain immutability provides auditable records, and the DAO governance model ensures that policy decisions reflect stakeholder consensus rather than centralized authority. This design is directly aligned with the trust-minimization principles of DeSci.
Residual Limitations: Three residual attack surfaces are acknowledged. First, ZKP proof generation adds 80–200 ms of client-side computational overhead, which may constrain deployment on resource-limited IoT devices. Second, off-chain storage systems require independent security hardening; compromise of the off-chain layer does not affect on-chain integrity guarantees but may affect data availability. Third, metadata inference from on-chain transaction patterns remains a residual privacy risk; mitigations such as differential privacy noise injection and k-anonymity policies are identified as future work.
6. Results &Discussion
This section presents the performance evaluation of the proposed DeSci-driven lightweight hybrid blockchain framework through simulation-based analysis. The system is assessed under varying network sizes to evaluate its scalability and efficiency. Key performance metrics, including transaction latency, throughput, and computational cost, are analyzed to measure system performance. Furthermore, a comparative evaluation with existing blockchain-based healthcare systems, namely MedRec, FHIRChain, and HealthChain, is conducted to highlight the advantages of the proposed framework. The results are interpreted to provide insights into the impact of architectural design choices, including hybrid consensus, off-chain storage, and Zero-Knowledge Proof-based authentication, on overall system performance. A prototype-level implementation is considered as future work due to infrastructure constraints [19,30]. Consistent with the exploratory, simulation-only nature of this evaluation, the quantitative comparisons that follow illustrate the directional impact of the proposed architectural choices under stated modeling assumptions and should not be read as a validated head-to-head benchmark against deployed systems; the evaluation contribution of this paper is therefore best characterized as a design-level and analytical assessment, with empirical benchmarking on a deployed prototype identified as the essential next step.
6.1. Simulation Setup
The proposed framework is evaluated through a discrete-event simulation modeling a distributed permissioned blockchain network under realistic healthcare data exchange workloads. The simulation environment comprises four interacting node types — patient nodes, healthcare provider nodes, researcher nodes, and validator nodes — all operating within a permissioned blockchain network governed by the hybrid PBFT–PoA consensus mechanism.
A key methodological clarification is warranted here: the framework is assessed through simulation rather than deployment on an actual blockchain platform such as Hyperledger Fabric or Ethereum. While the simulation accurately models the computational complexity of the consensus mechanism, the cryptographic operations (SHA-256 hashing and ZKP verification), and the communication patterns of the PBFT–PoA protocol, it does not capture all real-world factors such as network heterogeneity, node failures, disk I/O latency, or the overhead of smart contract execution on an actual blockchain virtual machine. These are explicitly recognized as limitations of the current evaluation. Prototype-level implementation on Hyperledger Fabric or Ethereum is identified as the immediate next step in future work [19,30]. Consequently, the latency and throughput figures reported in Section 6.3 (e.g., 320 ms at n=10, rising to 750 ms at n=50; 145 TPS at n=10, rising to 210 TPS at n=50) should be understood as outputs of this analytical/discrete-event model under the stated assumptions, not as measurements from a running system; they are not independently reproducible or verifiable on an actual blockchain deployment. Accordingly, the evaluation in this paper is best read as a design-stage and theoretical performance analysis rather than as an empirical performance evaluation in the conventional sense, with prototype-level empirical validation identified as the essential next step before any performance claim can be considered established.
Network sizes of 10, 20, 30, 40, and 50 nodes are evaluated to assess scalability behavior under increasing workload. Each simulation run executes 1,000 transactions per network size, comprising data registration transactions, access request transactions, and ZKP verification transactions in proportions representative of a typical healthcare research workload.
The key simulation parameters are as follows:
Block size: 1 MB
Network latency: 50–150 ms
Consensus mechanism: Hybrid PBFT–PoA
Data storage: Off-chain storage with on-chain hash references
Security mechanism: Zero-Knowledge Proof-based authentication (zk-SNARK / Groth16)
ZKP proof generation time (off-chain, client-side): 80–200 ms per request
ZKP on-chain verification time: ~5 ms (O(1) verifier circuit, reported separately from proof generation)
Off-chain storage retrieval latency (IPFS model): 20–100 ms (included in total latency measurements)
Transactions per simulation run: 1,000 per network size
Each transaction represents a complete healthcare data access request cycle, in which proof generation, on-chain ZKP verification, and blockchain recording are all performed. The simulation records system performance across all three key metrics — latency, throughput, and computational cost — under each network size configuration, enabling a comprehensive assessment of scalability and efficiency in a decentralized healthcare and DeSci setting.
6.2. Performance Metrics
Three key metrics are used to comprehensively evaluate the proposed framework: transaction latency, throughput, and computational cost. Each metric captures a distinct dimension of system performance and together they provide a complete picture of scalability, efficiency, and processing overhead.
6.2.1. Transaction Latency (ms)
Transaction latency is defined as the end-to-end time from transaction submission to blockchain confirmation. This metric encompasses three components: (i) consensus latency, determined by the PBFT– PoA hybrid mechanism and dependent on network size n; (ii) ZKP on-chain verification time (~5 ms, O(1) with respect to network size, as verification is a fixed-size circuit computation); and (iii) off-chain storage retrieval latency (20–100 ms under the IPFS model, included in total latency measurements for access transactions).
It is important to note that ZKP proof generation (80–200 ms, dependent on access policy circuit complexity) is a client-side cost that occurs before transaction submission. This cost is reported separately to avoid conflating client-side computation with network and consensus latency. Future work will evaluate optimized proof systems such as PLONK and STARKs to reduce this client-side overhead for resource-constrained devices.
6.2.2. Throughput (TPS)
Throughput is defined as the number of successfully confirmed transactions per second processed by the blockchain network. This metric captures the combined effect of consensus overhead, block size, and network communication on the system's transaction processing capacity. Higher throughput indicates that the system can handle greater volumes of concurrent healthcare data access requests, which is critical for large-scale DeSci deployments.
6.2.3. Computational Cost
The aggregate computational cost per transaction is modeled as in (Equation (24)) :
where the individual components are defined as:
Cconsensus = O(n2) : cost of the PBFT consensus component, the dominant term, where n is the number of validator nodes
Chash= O(n): cost of SHA-256 cryptographic hashing across n data records
Czkp ≈ O(1): cost of on-chain ZKP verification only; this is a fixed-size circuit computation independent of network size. Note: off-chain proof generation is a client-side cost and is excluded from this on-chain computational cost model
The overall system complexity is therefore given by (Equation (25)) :
The O(n2) term dominates as n grows, consistent with the PBFT communication complexity. However, the practical overhead is substantially reduced by three architectural choices: (i) the hybrid consensus design routes a significant proportion of routine transactions through the lower-overhead PoA path, reducing the effective proportion of transactions subject to full O(n2) PBFT complexity; (ii) off-chain storage eliminates the need to process large medical data records on-chain, reducing block processing overhead; and (iii) the permissioned setting bounds n to a controlled validator set (10–50 nodes in the evaluated scenarios), keeping the absolute communication overhead manageable.
The proposed framework is therefore more computationally efficient than conventional blockchain-based healthcare systems, which rely on full PBFT or PoW consensus without the hybrid routing optimization. Zero-Knowledge Proof verification adds negligible on-chain overhead (~5 ms), confirming that privacy preservation does not introduce significant performance penalties at the network level.
6.3. Latency and Throughput Analysis
The latency and throughput performance of the proposed framework is evaluated across network sizes of 10, 20, 30, 40, and 50 nodes. The results are presented in Tables 3 and 4 and illustrated in Figures 5 and 6 respectively. As detailed in the methodological note in Section 6.4, the comparison figures for MedRec, FHIRChain, and HealthChain reported below are normalized values derived from each system's original publication rather than measurements from a controlled re-implementation, and should be read accordingly.
Figure 5.
Latency comparison across different network sizes.
Figure 6.
Throughput comparison of proposed and existing systems.
Table 3.
Transaction latency comparison across network sizes (ms). Lower is better.
| Network Size(Nodes) | Proposed (ms) | MedRec (ms) | FHIRChain (ms) | HealthChain (ms) |
|---|---|---|---|---|
| 10 | 320 | 480 | 510 | 455 |
| 20 | 375 | 628 | 674 | 577 |
| 30 | 465 | 873 | 947 | 779 |
| 40 | 590 | 1,216 | 1,327 | 1,062 |
| 50 | 750 | 1,650 | 1,810 | 1,420 |
Table 4.
Throughput comparison across network sizes (TPS). Higher is better.
| Network Size (Nodes) | Proposed (TPS) | MedRec (TPS) | FHIRChain (TPS) | HealthChain (TPS) |
|---|---|---|---|---|
| 10 | 145 | 85 | 78 | 92 |
| 20 | 168 | 98 | 89 | 107 |
| 30 | 185 | 108 | 97 | 118 |
| 40 | 198 | 115 | 103 | 126 |
| 50 | 210 | 130 | 118 | 138 |
6.3.1. Transaction Latency Analysis
Table 3 presents the mean transaction latency (ms) of the proposed framework compared to MedRec, FHIRChain, and HealthChain across all evaluated network sizes. Latency values for existing systems are derived from normalized reported characteristics as described in Section 6.4.
The proposed framework achieves a latency of 320 ms at n=10, rising to 750 ms at n=50 — a 2.34× increase across the full evaluated range. By contrast, MedRec exhibits a 3.44× latency increase (480 ms to 1,650 ms), FHIRChain a 3.55× increase (510 ms to 1,810 ms), and HealthChain a 3.12× increase (455 ms to 1,420 ms) over the same range. This demonstrates that the proposed framework not only achieves lower absolute latency at all network sizes but also scales more gracefully, with a significantly flatter growth curve. The controlled latency growth is attributable to the hybrid PBFT–PoA design, which routes routine transactions through the lower-overhead PoA path, reducing the proportion of transactions subject to full O(n2) PBFT communication complexity. These absolute latency values are substantially lower than the multi-second latencies commonly reported for deployed PBFT-based permissioned blockchains (e.g., Hyperledger Fabric) under comparable node counts; this gap reflects the simulation's analytical treatment of consensus and cryptographic cost, together with the assumed 70:30 routine/high-stakes transaction split (Section 4.3), rather than a demonstrated advantage under real network, disk I/O, and virtual-machine execution conditions. Whether this latency advantage persists under an actual PBFT implementation is identified as the critical open question to be resolved by the prototype-level evaluation proposed as future work.
Figure 5 presents this same latency comparison graphically across the evaluated network sizes, consistent with the trend described above.
6.3.2. Throughput Analysis
Table 4 presents the mean throughput (transactions per second, TPS) of the proposed framework compared to existing systems across all evaluated network sizes.
The proposed framework achieves 145 TPS at n=10, rising to 210 TPS at n=50 — a 44.8% throughput improvement as the network grows, reflecting efficient parallel transaction processing. By contrast, MedRec achieves only 85–130 TPS, FHIRChain 78–118 TPS, and HealthChain 92–138 TPS across the same range. At n=50, the proposed framework's modeled throughput exceeds that of MedRec by 61.5%, FHIRChain by 78.0%, and HealthChain by 52.2% under the normalization assumptions described in Section 6.4. The modeled throughput improvement is enabled by two architectural choices: (i) the hybrid consensus mechanism reduces the communication overhead per transaction, allowing higher transaction processing rates; and (ii) off-chain storage eliminates the need to include large medical data payloads in on-chain transactions, reducing block processing time and increasing effective TPS.
In summary, the proposed framework offers a favourable trade-off between latency and throughput across all evaluated network sizes, demonstrating both lower absolute latency and higher absolute throughput than all three comparison systems. This dual advantage confirms that the hybrid consensus and off-chain storage design choices achieve the intended scalability and efficiency goals for decentralized healthcare and DeSci settings.
Figure 6 presents this same throughput comparison graphically across the evaluated network sizes, consistent with the trend described above.
6.4. Comparative Analysis
A comprehensive comparative analysis is performed against MedRec, FHIRChain, and HealthChain across three performance dimensions — latency, throughput, and computational cost — as well as qualitative architectural features. Table 5 provides the computational cost comparison, and Table 6 summarizes the qualitative feature comparison.
Table 5.
Computational cost comparison across network sizes (AU). Lower is better.
| Network Size (Nodes) | Proposed (AU) | MedRec (AU) | FHIRChain (AU) | HealthChain (AU) |
|---|---|---|---|---|
| 10 | 112 | 198 | 210 | 185 |
| 20 | 428 | 780 | 820 | 724 |
| 30 | 952 | 1,742 | 1,830 | 1,615 |
| 40 | 1,684 | 3,088 | 3,240 | 2,860 |
| 50 | 2,612 | 4,812 | 5,050 | 4,460 |
Table 6.
Qualitative feature comparison with existing systems.
| Feature | Proposed | MedRec | FHIRChain | HealthChain |
|---|---|---|---|---|
| ZKP-based Authentication | ✓ | ✗ | ✗ | ✗ |
| DAO Governance | ✓ | ✗ | ✗ | ✗ |
| Hybrid Consensus | ✓ | ✗ | ✗ | Partial |
| Tokenomics Layer | ✓ | ✗ | ✗ | ✗ |
| Formal Security Proofs | ✓ | ✗ | ✗ | ✗ |
| DeSci Alignment | ✓ | ✗ | ✗ | ✗ |
| Off-chain Storage | ✓ | Partial | ✓ | Partial |
| Simulation Evaluated | ✓ | ✓ | ✓ | ✓ |
6.4.1. Methodological Note
A fully controlled experimental re-implementation of all three comparison systems was not feasible within the scope of this work. Comparative performance data are derived from normalized values reported in the respective original publications, scaled to the network sizes evaluated in this paper using the computational complexity scaling laws stated in each system's original analysis (e.g., O(n2) for PBFT-based systems, O(n) for PoA-based systems). This normalization enables comparison of relative performance trends but does not constitute a controlled identical-environment experimental comparison. A fully controlled comparison under identical hardware and network conditions is identified as future work. Because this normalization compares simulated outputs for the proposed framework against values reported in different papers under different hardware, network conditions, and workloads, the percentage differences reported in Tables 3-5 should be interpreted as illustrative, order-of-magnitude indications of relative architectural efficiency rather than as evidence that the proposed framework outperforms these systems in a rigorously controlled, head-to-head sense. A claim of superiority in the strict empirical sense would require the controlled re-implementation identified above as future work.
6.4.2. Computational Cost Comparison
Table 5 presents the normalized computational cost (arbitrary units, AU) per transaction across network sizes, derived from the complexity models defined in Section 6.2.
Figure 7 presents the computational cost comparison across network sizes ranging from 10 to 50 nodes. The proposed framework consistently achieves the lowest computational cost at every evaluated network size. At n=10, the proposed framework incurs 112 AU compared to 198 AU for MedRec, 210 AU for FHIRChain, and 185 AU for HealthChain. At n=50, the cost rises to 2,612 AU for the proposed framework, compared to 4,812 AU for MedRec (45.7% reduction), 5,050 AU for FHIRChain (48.3% reduction), and 4,460 AU for HealthChain (41.4% reduction). The computational advantage of the proposed framework stems from the hybrid consensus routing strategy — whereby only high-stakes transactions incur the full PBFT O(n2) overhead while routine transactions are processed under PoA at O(n) cost. This hybrid routing substantially reduces the effective proportion of transactions subject to quadratic complexity, explaining the significantly flatter cost growth curve compared to systems relying exclusively on PBFT consensus. Lower computational cost values indicate better performance.
Figure 7.
Computational cost comparison across varying network sizes.
6.4.3. Qualitative Feature Comparison
Beyond performance metrics, Table 6 compares the proposed framework against existing systems across eight architectural dimensions relevant to DeSci-aligned healthcare research.
As Table 6 demonstrates, the proposed framework is the only system among those compared to provide all six distinguishing capabilities — ZKP-based authentication, DAO governance, hybrid consensus, a tokenomics layer, formal security proofs, and DeSci alignment. MedRec, FHIRChain, and HealthChain address data integrity and access control but do not provide ZKP-based privacy-preserving authentication, decentralized governance, tokenomics incentives, or formal cryptographic security proofs. This qualitative advantage, combined with the quantitative performance improvements demonstrated in Tables 3, 4, and 5, confirms that the proposed framework represents a meaningful advance over the current state of the art in blockchain-based healthcare research infrastructure.
6.5. Limitations
Although the proposed framework has shown promising performance and security benefits, it is important to note that there are some limitations. First, the existing assessment is on the basis of simulation and analytical modeling rather than a real-world implementation. Consequently, real-life considerations like network heterogeneity, node failures, and changing workload fluctuations can affect system performance in actual healthcare scenarios. Second, even though Zero-Knowledge Proofs provide strong privacy guarantees, the computational workload of proof generation can be an issue with resource-constrained devices. Verification is efficient, but when it comes to large-scale deployment scenarios, additional optimization might be needed. Third, the comparative analysis is done based on normalized values of reported characteristics of existing systems. It does not involve a fully controlled experimental implementation of all of the compared frameworks which limits direct performance comparability. Finally, the combination of the mechanisms of tokenomics and DAO-based governance is theorized but not applied to a real-life scenario. The real-life implementation of such mechanisms needs additional testing, especially regarding the regulations and acceptance of the mechanism among users in healthcare systems. The next step in work will be the practical implementation based on the Hyperledger Fabric or Ethereum platforms and empirical optimization and benchmarking of cryptographic operations. Given these constraints, the quantitative results reported in Section 6 are best interpreted as design-stage, model-based projections rather than validated empirical performance measurements; the paper's primary contribution at this stage is the formal architecture, security proofs, and governance/tokenomics specification, with empirical performance validation on a deployed prototype identified as the critical next step.
7. Conclusion
This paper presented a DeSci-driven lightweight hybrid blockchain framework for privacy-preserving and incentive-aware decentralized healthcare research infrastructure. The proposed system integrates a permissioned blockchain, a hybrid PBFT–PoA consensus mechanism, off-chain storage, ZKP-based authentication, and a DAO-based governance and tokenomics layer into a cohesive architecture addressing the scalability, privacy, and DeSci-alignment limitations of existing systems. The hybrid consensus design reduces communication overhead while preserving Byzantine fault tolerance for security-critical transactions. ZKP authentication enables trust-minimized, privacy-preserving data access grounded in formal game-based security guarantees. The DAO governance model supports decentralized, stakeholder-driven policy decisions with transparent voting and execution mechanisms, while the tokenomics layer creates a self-sustaining incentive ecosystem. The simulation-based evaluation suggests directional improvements in modeled latency, throughput, and computational efficiency relative to normalized literature values for MedRec, FHIRChain, and HealthChain, though these projections await empirical validation on a deployed prototype. The paper explicitly acknowledges the simulation-only evaluation and normalized comparative data as current limitations. Future work will prioritize: prototype deployment on Hyperledger Fabric; empirical benchmarking of ZKP operations on constrained devices; controlled comparative experiments with existing systems; pilot testing of the DAO governance mechanism; and integration with federated learning for privacy-preserving model training across the decentralized data ecosystem.
Acknowledgments
The authors would like to express their sincere gratitude to Integral University, Lucknow, and Krishna Institute of Engineering and Technology (KIET), Deemed to be University, Ghaziabad, for their continuous support, encouragement, and provision of the necessary research infrastructure that made this work possible. The institutional guidance and academic environment provided by both universities have been instrumental in the successful completion of this research.
Notes
[1] Contributed by Author Contributions
Conceptualization, G.S. and M.H.; methodology, G.S.; software, G.S.; validation, G.S. and M.H.; formal analysis, G.S.; investigation, G.S.; writing-original draft preparation, G.S.; writing-review and editing, G.S. and M.H.; supervision, M.H.; project administration, M.H. All authors have read and agreed to the published version of the manuscript.
[2] Conflicts of interest Conflict of Interest Statement
The authors declare that they have no competing interests.
[3] Data Availability Statement
The data supporting the findings of this study are available within the article. Additional data, if required, can be obtained from the corresponding author upon reasonable request.