MHBDS: Healthcare blockchain data sharing scheme based on SMPC and TRP-PBFT

Abstract

The decentralized and immutable nature of blockchain technology offers promising avenues for secure healthcare data sharing among legitimate institutions. However, current blockchain systems face critical bottlenecks in handling large volumes of medical data, low storage efficiency, and vulnerabilities in security. To overcome these challenges, a novel healthcare blockchain data-sharing scheme integrating Secure Multi-party Computation (SMPC) is proposed. To mitigate the risk of data leaks resulting from key compromise, Blakley’s secret sharing technique is employed for key distribution management, and Ciphertext-Policy Attribute-Based Encryption (CP-ABE) is integrated for access control. To address the challenge of handling large data on the chain, data that needs to be uploaded to the blockchain is encoded and fragmented using erasure coding techniques. Additionally, a Byzantine Fault Tolerance mechanism based on Reputation and Polling verification (TRP-PBFT) is introduced to enhance data sharing efficiency and system robustness. Simulation experiments conducted on platforms like Fabric demonstrate that this solution improves data sharing efficiency while ensuring data confidentiality and integrity. In comparison to Practical Byzantine Fault Tolerance (PBFT) under similar conditions, TRP-PBFT reduces the average latency from 655.42 ms to 342.22 ms and increases the average throughput from 107.31 TPS to 143.45 TPS. The scheme maintains high throughput and offers relatively stable latency performance.

1. Introduction

Smart healthcare uses digital and intelligent information technology to meet the diverse needs in healthcare. ¹ With the widespread adoption of technologies like artificial intelligence, cloud computing, and big data, ² medical data has grown rapidly, sparking significant concerns about the security management of healthcare data. ³ At present, the management of medical data predominantly relies on centralized systems. ⁴ However, these systems pose several challenges, including intricate privilege management, the risk of privacy breaches, and the complexity of achieving meaningful data sharing. Therefore, the shift from centralized to distributed medical data sharing systems has become an inevitable trend for providing better medical services. ⁵

Blockchain technology has introduced innovative solutions for ensuring the secure exchange of medical data. Its decentralized network architecture enhances the resilience of the system against various security threats. However, despite the promising potential of blockchain technology, existing medical data sharing schemes still exhibit significant disadvantages that hinder their practical deployment in large-scale healthcare ecosystems. First, cloud-storage-based medical data sharing technologies face inherent trust and security issues due to their reliance on semi-trusted servers, leaving systems vulnerable to single-point failures and internal data breaches. ⁶ Second, to circumvent cloud vulnerabilities, many existing blockchain schemes opt to upload complete original user data onto the chain. However, the openness and transparency of generic blockchains inevitably expose highly sensitive electronic health records to the risk of privacy leakage. ⁷ Third, directly storing massive amounts of medical data on the blockchain results in severe on-chain storage bottlenecks, making existing systems completely incapable of sustaining the continuous influx of modern medical data. Fourth, although various advanced consensus mechanisms ⁸ and Layer-II protocols ⁹ have been recently proposed to improve scalability, generic blockchain frameworks still suffer from severe efficiency bottlenecks and unacceptably high communication overheads when strictly required to satisfy the deterministic finality and low-latency demands of multi-institutional medical collaboration.

Motivated by these critical challenges, there is an urgent need for a highly scalable and secure architecture that can simultaneously ensure data confidentiality, alleviate on-chain storage burdens, and achieve high-throughput consensus. This paper aims to design a highly scalable, secure, and efficient healthcare data-sharing architecture to overcome the risk of data leakage in transparent blockchain networks, alleviate the substantial on-chain storage burden caused by raw medical data, and address the performance bottlenecks of traditional consensus mechanisms in large-scale sharing networks. To achieve this goal, this research focuses on combining SMPC and blockchain technology to comprehensively enhance the security, privacy, and efficiency of medical data sharing. Specifically, Blakley secret sharing technology is employed for key distribution management to ensure data confidentiality. Simultaneously, CP-ABE is introduced for access control to mitigate the risk of data leakage. Furthermore, erasure coding techniques are applied to encode and shard the data destined for the blockchain, thereby reducing the storage space requirements for on-chain transactions. Finally, a more secure and efficient Practical Byzantine Fault Tolerance consensus mechanism, referred to as TRP-PBFT, is introduced to enhance sharing efficiency and system robustness. The primary contributions of this study are as follows:

1) A multiparty secure medical data-sharing model is established and detailed in Section 4. By integrating SMPC with consortium blockchain technology, it provides a decentralized and highly secure framework. Its overall capability to handle large-scale medical datasets is validated through the System Throughput evaluation in Section 8.4.

2) A decentralized key management and fine-grained access control strategy is designed and elaborated in Section 6.2. This strategy combines the Blakley secret-sharing technique with CP-ABE to prevent single points of failure, and its theoretical security is formally analyzed and proven in Section 7.2.

3) An on-chain storage optimization method utilizing erasure-coding techniques is introduced in Section 6.1. Instead of broadcasting massive raw files, this scheme independently shards and encodes the encrypted data to alleviate storage burdens. Its processing efficiency is thoroughly evaluated through the experiments in Section 8.3.

4) A practical Byzantine fault-tolerant mechanism based on reputation and polling verification (TRP-PBFT) is proposed and formulated in Section 5. This mechanism improves system robustness by integrating trust assessment and fast-polling timers. Its performance superiority is quantitatively validated through Consensus Throughput (Section 8.5) and Consensus Latency (Section 8.6) comparisons.

The remaining structure is as follows: Section 2 discusses related work; Section 3 introduces preliminary knowledge; Section 4 describes the system model and workflow of the healthcare blockchain data sharing scheme; Section 5 introduces the proposed improved PBFT consensus in detail; Section 6 describes the key algorithm design of the multi-party secure healthcare blockchain data sharing scheme; Section 7 analyzes and proves the security of the scheme; Section 8 compares and evaluates the performance of various schemes. Finally, a summary and discussion of future work are presented.

2. Related work

2.1. Medical data sharing

Liu ¹⁰ proposed a searchable encryption framework for cloud assisted electronic health record sharing, aiming to address the trust crisis and data untraceability in traditional cloud storage. Nevertheless, reliance on semi trusted cloud service providers for centralized data management still entails inherent privacy leakage risks. Capraz ¹¹ introduced a secure medical data sharing framework based on public blockchains. In contrast, storing massive amounts of raw medical data directly on a transparent blockchain network entails severe on chain storage bottlenecks. Similarly, Kaur ¹² introduced a secure sharing system combining blockchain, the InterPlanetary File System, and CP-ABE to achieve fine grained access control. However, it is worth noting that executing complex encryption algorithms introduces significant computational overhead, and lacking a distributed key management mechanism leaves the system vulnerable to single point key leakage risks. Nekouie ¹³ introduced an escrow less blockchain assisted attribute-based encryption scheme for secure medical data sharing in the cloud, utilizing partial private keys to prevent key generation centers from accessing user keys. However, it is worth noting that executing complex encryption algorithms still brings high computational overhead, and relying on centralized cloud storage cannot completely eliminate the inherent risks of single point of failures.

In medical blockchain networks, efficient collaboration depends on robust and scalable architectures. Sunitha ¹⁴ introduced a hybrid framework integrating Attribute Based Access Control with Ethereum blockchain technology to establish a multi layered security architecture for cloud-based healthcare systems. However, it is worth noting that combining multiple complex cryptographic techniques and traditional public blockchain networks still brings significant computational overhead and faces scalability bottlenecks when handling massive real time medical data. Expanding the application scope to the medical supply chain ecosystem, Namasudra ¹⁵ introduced a blockchain and Internet of Things enabled system to ensure the traceability and transparency of medical drugs. However, it is worth noting that continuously recording massive amounts of supply chain data directly on the Ethereum network inevitably introduces significant transaction costs and latency issues. Furthermore, addressing network security during data auditing, Hanumantharaju ¹⁶ introduced a distributed intrusion detection architecture combining fog computing, cloud services, and blockchain technology. However, it is worth noting that deploying additional fog computing layers and continuous monitoring processes inevitably increases the systemic architectural complexity and edge node resource consumption.

To address availability and partition resistance in cloud resource management, Arias ¹⁷ proposed a decentralized architecture utilizing Byzantine-resistant consensus to replace traditional Paxos or Raft data stores. While this approach significantly increases overall system availability during network partitions, applying standard Byzantine consensus directly to large-scale healthcare data sharing still incurs considerable communication overhead and latency. To address the secure exchange of Electronic Medical Records between hospitals, Hasan ¹⁸ recently integrated blockchain, the Inter-Planetary File System, and proxy re-encryption. While proxy re-encryption enables secure sharing without revealing original data, its complex cryptographic operations inevitably introduce substantial computational overhead. Zhang ¹⁹ focused on attribute-based encryption ciphertext protection strategy to solve the data security problem during data sharing by designing suitable ciphertext and key structure. Sun ²⁰ introduced a secure medical information storage solution utilizing Hyperledger Fabric and Attribute Based Access Control to guarantee data security through smart contracts. However, it is worth noting that storing data directly within the blockchain limits system scalability and poses challenges in handling large scale data.

2.2. Secure multi-party computation

To establish a trusted execution environment for SMPC, certain researchers have opted to carry out SMPC via a trusted third party. Wu ²¹ developed a generalized server-assisted secure multiparty framework to facilitate secure execution of collaborative computation tasks within the cloud. This framework enables the analysis of secure multi-party federated datasets in the cloud while safeguarding the privacy of individual datasets during the computing protocol. However, if the trusted third party is attacked or malfunctions, the whole system will not work properly, which may also lead to computation disruption or result in leakage. In addition to this, the trusted third party may collude with malicious parties to leak sensitive information or tamper with computation results.

To solve the potential problems posed by trusted third parties, some researchers have combined blockchain technology with SMPC to reduce the dependence on trusted third parties. The distributed nature and security features of blockchain can furnish a more reliable execution environment for SMPC, and by recording the computation tasks and results on the blockchain, it can realize the openness, transparency, and immutability of the data, as well as the validation and traceability of the computation process. Yang ²² introduced a blockchain enabled privacy preserving multiparty computation scheme integrating non interactive zero knowledge proofs for public auditing in the industrial Internet of Things. However, it is worth noting that executing complex zero knowledge proofs on the blockchain still incurs significant computational and communication overhead. Li ²³ introduced a publicly verifiable secure multiparty computation framework utilizing homomorphic message authentication codes and bulletin boards to detect malicious servers. In contrast, executing complex pairing based homomorphic commitments still introduces significant computational burdens during the verification phase. Gilbert ²⁴ introduced an innovative privacy solution combining zero knowledge proofs and SMPC to facilitate collaborative computations in blockchain ecosystems. However, integrating these advanced cryptographic technologies encounters severe challenges related to systemic complexity and scalability.

Although prior research focused on mitigating single points of failure and enhancing privacy using blockchain technology, it often overlooked the intricacies of secret sharing schemes and failed to adequately tackle the storage demands associated with blockchain implementations. Shree ²⁵ introduced a data protection architecture combining blockchain, the InterPlanetary File System, and a secret sharing algorithm to fragment data and resist emerging cryptographic threats in the Internet of Medical Things. However, it is worth noting that retrieving and reconstructing fragmented data from public decentralized storage clusters introduces significant communication overhead and system latency. Building upon this, Alam ²⁶ introduced a verifiable multi secret sharing scheme with a hierarchical access structure to enable authorized participants across different priority levels to reconstruct secrets. However, it is worth noting that coordinating participants across multiple hierarchy levels and performing continuous share verification inevitably introduces significant communication delays and computational complexity. Zhang ²⁷ introduced a publicly verifiable secret sharing method combining on chain audit verification and off chain secure multiparty computation to enable secure data sharing between edge devices. However, it is worth noting that integrating multiple cryptographic primitives such as Pedersen commitments and Beaver triplets inevitably introduces substantial computational and communication overhead for resource constrained edge devices.

Li ²⁸ introduced a layered blockchain based medical data asset sharing framework integrating zero knowledge proofs and group signatures to establish a supervisory privacy preserving mechanism. However, it is worth noting that executing complex cryptographic proofs within smart contracts inevitably sacrifices system throughput and introduces additional computational overhead during large scale concurrent transactions. Lu ²⁹ introduced a personal health record sharing mechanism combining zero knowledge proofs and a linear secret sharing scheme to verify user attributes while protecting privacy. However, it is worth noting that generating complex zero knowledge proofs during the verification phase produces non negligible computational latency, and its system throughput faces obvious performance bottlenecks when handling high concurrency requests. Borges ³⁰ introduced a secure multi-party computation methodology integrating a blockchain based platform and the MPyC library to facilitate collaborative clinical trial cohort creation without complex cryptographic key management. However, it is worth noting that as a proof of concept study operating on partitioned Fast Healthcare Interoperability Resources format data, its reliance on frequent multi-party network interactions inevitably introduces communication latency and scalability bottlenecks when applied to massive real time medical datasets.

As illustrated in Table 1, although the research related to medical data sharing and secure multiparty computing has been very extensive, there is still a lack of a reasonable scheme combining secure multiparty computing with blockchain technology for medical secure data sharing. Existing schemes have a single sharing mode that only realizes one-to-one data sharing, with insufficient system scalability to realize large-scale medical data sharing, and face threats to the security and robustness of the system in case of malicious node intrusion. The multi-party security-based medical blockchain data sharing scheme (MHBDS) proposed in this paper utilizes the Blakley space plane equation system matrix to achieve multi-point distribution of keys, realizes the many-to-many sharing mode, and adopts a consensus mechanism with higher efficiency and better security to reduce system resource consumption.

Table 1.

Summary of relevant work.

Scheme	Core mechanisms	Limitations
Liu 10	Searchable encryption framework combined with cloud assisted electronic health record centralized storage.	Relying on semi trusted cloud service providers entails inherent privacy leakage risks.
Capraz 11	Public blockchain based framework specifically designed for direct medical data storage and exchange.	Storing massive amounts of raw medical data directly on a transparent blockchain network entails severe on chain storage bottlenecks.
Kaur 12	Integration of blockchain architecture, InterPlanetary File System distributed storage, and CP-ABE	Lacking a distributed key management mechanism leaves the system vulnerable to single point key leakage risks, and executing complex algorithms introduces significant computational overhead.
Wu 21	Generalized server assisted secure multiparty framework executed within centralized cloud environments.	If the trusted third party is attacked or malfunctions, it may lead to computation disruption, or the server may collude with malicious parties to leak sensitive information.
Yang 22	Blockchain enabled secure multiparty computation scheme integrated with non-interactive zero knowledge proofs	Executing complex zero knowledge proofs on the blockchain incurs significant computational and communication overhead.
Shree 25	Data protection architecture combining blockchain, the InterPlanetary File System, and secret sharing algorithms for data fragmentation.	Retrieving and reconstructing fragmented data from public decentralized storage clusters introduces significant communication overhead and system latency.
Borges 30	SMPC methodology integrating a blockchain platform and the MPyC library operating on partitioned Fast Healthcare Interoperability Resources data.	The reliance on frequent multi- party network interactions inevitably introduces communication latency and scalability bottlenecks.

3. Preliminaries

3.1. Bilinear mapping

A bilinear mapping forms the mathematical foundation for constructing attribute-based encryption algorithms based on the Diffie-Hellman problem. Let $G_1$ and $G_2$ be two multiplicative cyclic groups of prime order, and let $g$ be a generator of $G_1$ . A mapping $e:G_1\times G_1\to G_2$ is defined to be bilinear if it satisfies the following three conditions:

Bilinearity: For all elements $g,h\in G_1$ and all integers $a,b\in {\mathbb{Z}}_p$ , the mapping $e$ satisfies the equation $e\left(g^a,h^b\right)=e{\left(g,h\right)}^{ab}$ .

Non-degeneracy: There exist elements $g,h\in G_1$ such that $e\left(g,h\right)\ne 1$ .

Computability: For all elements $g,h\in G_1$ , there exists an efficient algorithm to compute the value $e\left(g,h\right)\in G_2$ .

3.2. Ciphertext-Policy Attribute-Based Encryption (CP-ABE)

Ciphertext-Policy Attribute-Based Encryption (CP-ABE) is a fine-grained access control encryption scheme in which the access policy is embedded within the ciphertext, and the user’s attributes are embedded within the user’s key. ³¹ Decryption is successful only if the user’s attributes satisfy the access policy specified in the ciphertext. The steps in CP-ABE are as follows:

Setup: Given security parameters $\delta$ and a set of attributes $U=\left\{A1,A2,\dots ,An\right\}$ , the setup algorithm generates a master public key $\left(PK\right)$ and a master secret key $\left(MSK\right)$ .

Encryption: The encryption algorithm takes as input an access policy $P$ , a plaintext message $Msg$ , and master public key $\left(PK\right)$ . It outputs the ciphertext $C$ .

Key Generation (KeyGen): This algorithm takes as input a set of attributes $A$ , the master secret key $\left(MSK\right)$ , and the master public key $\left(PK\right)$ . It outputs a user’s secret key $ku$ corresponding to the attributes $A$ .

Decryption: The decryption algorithm uses the user’s secret key $ku$ , the master public key $\left(PK\right)$ , and the ciphertext $C$ to retrieve the original plaintext message $Msg$ , provided the attributes $A$ satisfy the access policy $P$ . If the attributes do not satisfy the policy, the decryption output is $\text{null}$ (indicating decryption failure). The typical architecture and fundamental algorithms of the CP-ABE scheme are shown in Figure 1.

Figure 1.

The typical architecture and fundamental algorithms of the CP-ABE scheme.

3.3. Blakley secret sharing scheme

The Blakley Secret Sharing Scheme is a method of secret sharing that leverages geometric principles. ³² In this scheme, the secret is viewed as the intersection of all hyperplanes in an n-dimensional space, with each hyperplane representing a share of the secret, known as a sub-secret. The steps of this scheme are as follows:

Secret representation: The secret $\mathit{S}$ is viewed as a point in an n-dimensional space.

Hyperplane Generation: Generate $k$ hyperplanes, each passing through the point $S$ . Each hyperplane can be represented by a linear equation of the form $a_1{x}_1+a_2{x}_2+\cdots +a_n{x}_n=b$ , where $a_1,a_2,\dots ,a_n$ ​ are random coefficients, and $b$ is a constant.

Share distribution: Distribute the coefficients and constant $\left(a_1,a_2,\dots ,a_n,b\right)$ of each hyperplane equation to the participants, with each participant receiving one hyperplane.

Secret reconstruction: When at least $k$ participants combine their hyperplane equations, the secret $S$ can be reconstructed by solving the system of linear equations.

3.4. Erasure code scheme

Erasure coding is a robust mathematical method for data protection and storage optimization, with the Reed-Solomon (RS) code being one of its most prominent implementations. ³³ In a decentralized or distributed storage system, the erasure code scheme transforms a message into a longer message with redundant data components, ensuring data availability even in the presence of node failures or data loss.

The fundamental principle of an $\left(n,k\right)$ erasure code can be defined by the following two primary phases:

Encoding phase: The original data $D$ is partitioned into $k$ equal-sized independent data blocks. A predefined generator matrix is then applied to these $k$ blocks to compute $m$ additional parity (or checksum) blocks, where $n=k+m$ . Consequently, the system outputs a total of $n$ encoded blocks.

Decoding and reconstruction phase: The optimal property of the RS erasure code is its fault tolerance. The original data $D$ can be flawlessly reconstructed using any subset of $k$ blocks out of the total $n$ generated blocks.

4. Scheme framework

4.1. System model

To mitigate data leakage risks and bolster overall system security, the proposed model adopts a consortium blockchain architecture specifically implemented on the Hyperledger Fabric platform. The rationale for selecting this network is threefold. First, its permissioned nature ensures that strictly authenticated medical institutions can participate, thereby shielding highly sensitive healthcare data from unauthorized public exposure. Second, by circumventing computationally intensive mining processes, the platform achieves the high transaction-processing throughput and low latency mandated by massive medical datasets. Third, its modular design seamlessly accommodates the deployment of our customized TRP-PBFT consensus mechanism, providing a highly scalable and robust infrastructure for secure healthcare data sharing. Specifically, unlike public blockchains that rely on Proof-of-Work, block generation in our system is not executed through competitive hashing. Instead, transactions are efficiently verified, ordered, and committed by high-reputation consensus nodes utilizing the TRP-PBFT mechanism, ensuring deterministic finality while strictly avoiding any resource-intensive mining process. The system model of the Multi-Party Secure Medical Blockchain Data Sharing Scheme (MHBDS) is depicted in Figure 2. Users are categorized into data owners (DO) and data sharing users (DSU) based on their distinct roles in data sharing transactions.

Figure 2.

Data sharing model.

The system model of MHBDS primarily consists of three key entities: data owners, shared users, and the blockchain storage system. Below is an introduction to each entity:

1) Data Owners (DO): DOs are the genuine holders of the data, typically patients. They possess medical data and have the authority to decide whether to share the data. In this scheme, DOs are tasked with uploading encrypted data shards onto the blockchain, enabling DSUs to access and verify the data. Additionally, DOs have the ability to specify data sharing permissions and define access policies that govern DSU authorization. Regarding key management, DOs are responsible for generating the symmetric encryption key, splitting it into multiple sub-keys using the Blakley secret sharing technique, and encapsulating these sub-keys with the CP-ABE mechanism before distribution.

2) Data Shared Users (DSU): DSUs encompass entities like healthcare institutions and research organizations that share a common requirement for medical data. DSUs can request access to specific medical data from the blockchain storage system. Additionally, DSUs play a crucial role in verifying the integrity and correctness of the data uploaded to the blockchain in this scheme to ensure that the on-chain data is accurate and unaltered. Furthermore, DSUs must adhere to access policies established by DOs to guarantee that only authorized users can access the data. In the key management process, authorized DSUs who satisfy the CP-ABE access policy can decrypt their assigned sub-keys. When a threshold number of DSUs collaborate, they can successfully reconstruct the original symmetric encryption key by solving the shared spatial equations.

3) Blockchain Storage System (BS): BS plays a central role in data storage and sharing within MHBDS, ensuring data security, integrity, and traceability. It provides a high degree of immutability through distributed blockchain technology. Additionally, BS assists in key management and data decoding, facilitating secure data-sharing and access. In addition to data storage, BS assists in the key management workflow by securely maintaining the metadata of the distributed sub-keys and facilitating the decentralized authorization validations during the key recovery and data decoding phases.

4.2. System processes

The complete interaction process of different roles in the simulation system model to carry out shared transactions, the specific system flow is shown in Figure 3.

1) Initialization: The shared model is initialized using the security parameter $\delta$ . The master key pair $\left\{SK,PK\right\}$ and the symmetric encryption key $K_{sym}$ are successfully generated by the $KeyGen\left(\delta \right)$ algorithm.

2) Data encryption: DO encrypts the original medical data $D$ utilizing the symmetric encryption key $K_{sym}$ . This process is executed through the explicitly defined encryption function $DataEncrypt\left(K_{sym},D\right)$ , which outputs the corresponding ciphertext, denoted as $D^{*}$ .

3) Generation of order non-singular matrix: The system generates different matrix coefficients according to different user IDs, thus forming the corresponding $n\times m$ order non-singular matrix $M$ . The non-singular property mathematically guarantees that any square submatrix formed during the subsequent data decoding phase is strictly invertible, which is the prerequisite for successfully reconstructing the original data from the retrieved encoded blocks. Furthermore, it serves as the coefficient matrix in the spatial geometric equations, ensuring a unique solution during the secret sharing key recovery phase.

4) Data slicing and corrective deletion code encoding: Data slicing and corrective deletion code encoding operations are performed on the ciphertext, and the matrix M and ciphertext $D^{*}$ are utilized to generate the encoded block $C=\left\{C_i,i\in \left[0,n-1\right]\right\}$ , which is stored in the block store (BS) on the blockchain.

5) Key splitting and sharing: Generate the key sharing equation $\phi$ for key splitting, and sharing based on the key $K_{sym}$ , matrix $M,$ number of users $n$ and threshold $m$ .

6) Data sharing permission application: DSUs apply for access privileges from DO, and only DSUs with access privileges can receive multiple shared subkeys distributed by DO through the Blakley secret sharing technique.

7) Key recovery: DSU uses the key sharing equation $\phi$ to recover the encryption key $K_{sym}$ .

8) Data decoding and decryption: The DSU obtains a certain number of data-coded blocks from the BS, decodes the coded blocks using matrix $M$ to realize data reconstruction and generate the original ciphertext $D^{*}$ , and decrypts the data using key $K_{sym}$ to obtain the original data $D$ .

Figure 3.

System process.

5. Improved PBFT consensus mechanism

5.1. Ideas for improvement

In view of the low consensus efficiency, high-performance overhead, and low scalability of the traditional consensus mechanisms previously used in the consensus phase of the blockchain, ³⁴ as well as the threat to the security and robustness of the system in case of intrusion by malicious nodes, a Trust-based Reputation Polling Byzantine Fault Tolerance (TRP-PBFT) mechanism based on credibility and polling verification is proposed.

Based on the traditional PBFT consensus mechanism, TRP-PBFT makes the following three improvements:

1) Introducing a trust assessment mechanism in the process of node entry and dynamic adjustment. The credibility of nodes is assessed through their performance scores and network reputation scores, and more reliable nodes are prioritized as consensus nodes to reduce the possibility of malicious node invasion and improve the system’s ability to identify abnormal nodes.

2) Introducing a multi-party signature mechanism in PBFT ensures that the transaction is recognized by at least t different nodes before $\left(t,n\right)$ threshold signature, which improves the security and trustworthiness of the transaction.

3) Introducing a fast-polling method speeds up the process of message delivery and consensus reaching among nodes. The performance and response speed of the PBFT algorithm is improved by introducing a fast-polling timer in the nodes.

5.2. Design and implementation of the improved PBFT consensus mechanism

5.2.1. Trust assessment mechanism design

For the selection of consensus nodes, nodes with elevated reputation values are selected as the primary and backup participants in consensus activities through the introduction of a trust assessment mechanism, and these consensus nodes are utilized to pack data and generate blocks.

5.2.1.1. Performance indicator score

Assuming that node i has a set of performance indicators $\left\{Per{f}_R,Per{f}_T,Per{f}_D\right\}$ , which are response time, transaction processing speed, and data transmission rate, the performance of the node is judged to be stable and efficient through a weighted average performance score. Nodes with good performance are considered more trustworthy.

Step 1: Normalize the performance metrics. The collected performance metrics are normalized by mapping the range of values of different metrics between [0, 1], and the normalization is calculated as follows.

$Normalize{d}_X=\frac{X-X_{\mathit{min}}}{X_{\mathit{max}}-X_{\mathit{min}}}$

(1)

Where: $X$ represents the current value of the corresponding raw performance metric. Additionally, $X_{\mathit{min}}$ and $X_{\mathit{max}}$ explicitly denote the minimum and maximum historical values of that specific metric previously recorded in the system, respectively. Through this formula, the normalized response time $Normalize{d}_R$ , normalized transaction processing speed $Normalize{d}_T$ , and normalized data transfer rate $Normalize{d}_D$ can be effectively obtained.

X represents the value of the corresponding raw performance metrics, through which the normalized response time $Normalize{d}_R$ , transaction processing speed as $Normalize{d}_T$ ,and data transfer rate as $Normalize{d}_D$ can be obtained.

Step 2: Calculate the weighted average performance score. Assign a weight to each performance metric and determine the weight value based on its importance. Then calculate the weighted average performance score of node $i$ .

$WAP{S}_i=w_R\times Normalize{d}_R+w_T\times Normalize{d}_T+w_D\times Normalize{d}_D$

(2)

Where, $WAPS$ is the weighted average performance score of node i, and $w_R$ 、 $w_T$ 、 $w_D$ are the weight parameters of the corresponding performance indicators, which represent the relative importance of each indicator.

5.2.1.2. Network reputation evaluation score

The network reputation is formed through the evaluation and feedback of the target node by other nodes in the network. Suppose there are $N$ nodes in the consensus network, node $i$ is identified as $I{D}_i$ and its reputation score is $Re{p}_i$ . Here again, $Re{p}_i$ is mapped between [0, 1], $Re{p}_i$ =1 means that the target node is fully trusted; $Re{p}_i$ =0.5 means that it is not possible to judge the trustworthiness of the target node; $Re{p}_i$ =0 means that the target node is not trustworthy; and the default value of $Re{p}_i$ is set to 0.5.

Step 1: Define the trust relationship of nodes. Three variables, $t$ , $d$ , and $u$ , are introduced to describe the trust relationship of nodes, which are computed from the evaluations generated by historical transaction nodes.

$t=\frac{r}{\hspace{0.17em}\left(r+p\ast s+c\right)};d=\frac{\hspace{0.17em}p\ast s\hspace{0.17em}}{\hspace{0.17em}\left(r+p\ast s+c\right)};u=c\left(r+p\ast s+c\right)$

(3)

where t denotes the trust in the target node, $d$ denotes the distrust in the target node, and $u$ denotes the uncertainty in the target node. These three variables satisfy the formula $t+d+u=1$ and take values between [0, 1]. $p$ is the penalty factor for negating an event to a node, which takes a value greater than 1; c is the uncertainty factor, which is computed as $c=E-\left(r+s\right)$ . $r$ denotes the number of times that the consensus about the target node has been completed with certainty; $s$ denotes the number of events in which the node has not been determined to have completed the consensus; and $E$ is the total number of nodes’ consensus.

Step 2: Calculate the reputation score. Based on the trust relationship of nodes, the reputation score $Re{p}_i$ of node i is calculated as:

$Re{p}_i=t+u\hspace{0.17em}/\hspace{0.17em}2=\left(r+E-s\right)\hspace{0.17em}/\hspace{0.17em}2\left(p\ast s+E-s\right)$

(4)

5.2.1.3. Comprehensive trust score

Combining the performance index and network reputation evaluation scores, the final trust calculation formula can be expressed as $Trus{t}_i=\mathit{min}\left(1,WAP{S}_i+\gamma \hspace{0.17em}\ast \hspace{0.17em}\left(Re{p}_i-0.5\right)\right)$ . This trust calculation formula takes into account the node’s performance metrics score and network reputation evaluation score, and adjusts the weights of both through γ. When γ = 0, only performance metric scores are considered, while when $\gamma =1$ , only network reputation trust scores are considered.

5.2.1.4. Tolerance assessment

Set the threshold of trust $\delta$ . Only nodes with a certain level of trust can participate in the consensus process, and if $Trus{t}_i$ <δ, the node is eliminated. The threshold setting is balanced according to the security and performance requirements of the system.

5.2.2. Introduce multi-party signature

Decrypt the hash value encrypted by the corresponding private key through the user’s public key, establish a multi-party signature function to generate a multi-party encryption string, and jointly encrypt the transaction information through the multi-party encryption string. The multi-party signature process is shown in Figures 4 and 5.

Figure 4.

Multi-party signature encryption.

Figure 5.

Multi-party signature decryption.

Instead of two scalars $\left(r,s\right)$ , a random point R on an elliptic curve $\left(R=K\times G\right)$ and a scalar s are used. $s=k+hash\left(P,R,msg\right)·sk$ . Here, $sk$ is the private key, while $P=sk\times G$ is the public key and $msg$ is the message. This signature can be verified by checking $\times G=R+hash\left(P,R,msg\right)\times P$ .

By using the multi-party signature function, all the signature verification equations can be summed, and since the verification equations are linear, the sum of several equations is valid as long as all signatures are valid. For example, suppose 10 signatures are required to be verified:

$\left(s1+s2+\cdots +s10\right)\times G=\left(R1+\cdots +R10\right)+(hash(P1,R1,msg1)\times P1+hash(P2,R2,msg2)\times P2+\cdots +hash(P10,R10,msg10)\times P10$

(5)

5.3. Consensus process of the improved PBFT consensus mechanism

The TRP-PBFT consensus process is shown in Figure 6.

Figure 6.

TRP-PBFT consensus process.

Includes the following eight stages:

1) Initialization Phase: In the initialization phase of the system, the number of master and replica nodes is set and the reputation value is calculated for each node. Sort the replica nodes according to the reputation value from high to low, and use the node with a higher reputation value as the primary backup node and the node with a lower reputation value as the replica ordinary node

2) Request Pre-prepare Phase: The client sends the request to the master node (Primary).

Upon receiving the request, the master node prepares the request and broadcasts a pre-prepare message (Pre-prepare) to all replica nodes in its group. The master node sets a fast-polling timer and starts waiting for Pre-prepare messages from a sufficient number of replica nodes. After the replica node receives a Pre-prepare message from the master node, it also sets a fast-polling timer and starts waiting for Pre-prepare messages from other replica nodes.

3) Backup Node Verify Pre-prepare Phase: The replica node receives the pre-prepared messages from the master node and other replica nodes. The replica node verifies the pre-prepared message based on the multi-party signature mechanism to ensure the integrity and authenticity of the message. If the verification passes, the replica node continues the preparation phase, otherwise the message is ignored.

4) Prepare Phase: Once the master node receives a pre-prepare message from a sufficient number of replica nodes, it broadcasts a Prepare message to all the nodes in its group, including itself and the replica nodes. The master node and the replica and backup nodes start waiting for a sufficient number of Prepare messages. After the replica nodes receive a sufficient number of Prepare messages, they broadcast a Prepare message to all nodes.

5) Fast Poll Verify Prepare Phase: During the preparation phase, the node performs fast polling according to the setting of the fast-polling timer. When a node needs to perform fast polling during the preparation phase, the timer starts timing. Once a sufficient number of ready messages are received or the threshold set by the timer is reached, the node can proceed to the commit phase immediately without waiting for responses from other nodes.

6) Commit Phase: Once the master node receives a sufficient number of ready messages, it broadcasts a commit message to all the nodes in its group, including itself and the replica nodes. The master and replica nodes start waiting for a sufficient number of commit messages. Once the replica nodes receive a sufficient number of commit messages, they broadcast a commit message to all the nodes in their group.

7) Fast Poll Verify Commit Phase: During the commit phase, the node performs fast polling based on the setting of the fast-polling timer. When a node needs to perform fast polling during the submit phase, the timer starts timing. Once a sufficient number of commit messages are received or the threshold set by the timer is reached, the node can proceed to the completion phase immediately without waiting for responses from other nodes.

8) Finalization Phase: Once the master node receives a sufficient number of commit messages, it confirms the execution of the transaction and broadcasts the result to all nodes in its group, including the replica nodes. The master and replica nodes update the local state based on the result.

At any stage, if the system detects a malicious node intrusion or data anomaly, a fault-tolerant transaction replay mechanism is adopted. That is, the affected transactions are re-executed to ensure that the correct transaction results are written to the blockchain. If a malicious attack behavior occurs then the evil node is kicked out from the cluster. At the same time, the replica node backup node is introduced to replace the evicted malicious node.

5.4. Theoretical analysis of TRP-PBFT

To comprehensively evaluate the TRP-PBFT consensus mechanism, this section analyzes its core theoretical properties including fault tolerance bound, safety, and liveness under a partially synchronous network model comprising $N$ total nodes and a maximum of $f$ Byzantine faulty nodes.

1) Fault Tolerance Bound: TRP-PBFT strictly adheres to the identical Byzantine fault tolerance lower bound as standard PBFT. To guarantee safety and liveness within a partially synchronous network, the system can tolerate up to $f$ malicious nodes out of $N$ total nodes, satisfying the strict inequality constraint $N\ge 3f+1$ .

2) Safety Analysis: Safety dictates that no two honest nodes will ever commit conflicting blocks at the same height. TRP-PBFT guarantees this property through a rigorous intersection of quorums combined with unforgeable multi-party cryptographic signatures. During the Prepare and Commit phases, a node advances its state only after collecting at least $2f+1$ valid signatures. Suppose two conflicting blocks, $B_1$ and $B_2$ , are proposed for the same height. For both to be committed, their respective $2f+1$ quorums must intersect at a minimum of $f+1$ nodes. Given a global maximum of $f$ malicious nodes, this intersection must contain at least one honest node. Since an honest node will never double-sign conflicting blocks, and multi-party signatures are cryptographically unforgeable, system safety is mathematically proven.

3) Liveness and Practical Robustness: Liveness ensures that legitimate client requests are eventually committed, preventing system deadlocks. In standard PBFT, malicious primary nodes easily trigger the high-overhead View Change protocol, severely degrading practical liveness. TRP-PBFT reshapes this guarantee by introducing a Fast-Polling Timer and a dynamic Trust Assessment Mechanism. The fast-polling mechanism curtails long-tail network latencies, preventing sluggish Byzantine nodes from stalling the consensus workflow. Concurrently, the trust assessment mechanism proactively isolates low-reputation nodes and revokes their primary node candidacy, successfully circumventing frequent view-change overheads. Consequently, even under adverse conditions approaching the fault tolerance limit, TRP-PBFT sustains stable block generation and system throughput, demonstrating exceptional practical robustness.

6. Schematic design

This section provides a detailed explanation of the key stages and algorithms involved in the encryption, upload, storage, key distribution, key recovery, and data reconstruction processes in medical data sharing. Table 2 defines and explains the symbols used throughout the article.

Table 2.

System parameters and symbols.

Symbol	Definition
$\delta$	Security parameter
$p$	A large prime number
$D^{*}$	Encrypted data
$e$	The third type of bilinear mapping
$K_{sym}$	Symmetric encryption key
$SK$	Master secret key
$PK$	Master public key
$KeyGen$	Key generation function
$\mathrm{g},h$	Generator of cycle group $G_1$
$G_1,G_2$	Multiplicative cyclic group of prime number $p$
$H,H_1,H_2,H_3$	Hash function
$a,b,c$	Random numbers are used to construct the key
$Z_p$	A finite field with $p$ terms
$M$	Matrix generated by $Matrix\left(ID,n,m\right)$
$ID$	Data ID
$n$	Number of rows
$m$	Number of columns
$a_{i,j}$	Element of matrix M
$K_{\mathrm{i}}$	The i-th element of the encryption key
$k_i$	Subkey share
${{\mathrm{k}}_{\mathrm{i}}}^{\prime }$	Set of split key shares {k1’, k2’, ⋯, kn′}
$C$	Set of encoded blocks
$B$	Intermediate variable or matrix, used for calculating ki’ or solving equations
${\mathrm{b}}_{\mathrm{i}}$	Element of matrix B
$I_i$	The space equation sub-coefficient
$sk$	Node’s private signing key
$msg$	Transaction message

6.1. Encrypted data upload and storage

Step 1: The patient generates a large amount of medical data $D$ during the consultation process, and to encrypt and store it, it is first necessary to utilize $KeyGen\left(\delta \right)$ to generate the system parameters $\delta$ and the symmetric encryption key $K_{sym}$ . The original data $D$ is then securely encrypted via the function $DataEncrypt\left(K_{sym},D\right)$ to generate the ciphertext $D^{*}$ . The pseudo-code for key generation and data encryption is shown in Algorithm 1.

Step 2: Due to the limitation of BS’s characteristics, uploading large volumes of data to BS needs to consume a large amount of storage resources, MHBDS, in order to solve the problem of excessive consumption of this type of storage, utilizes the corrective censoring code to encode and store the data, so that the BS nodes do not need to store the complete data in order to realize the data uploading. Firstly, DO utilizes the $Matrix\left(ID,n,m\right)$ algorithm to generate a non-singular matrix $M$ of order $n\times m$ according to ID (at this time, $n=Num\left(nod{e}_{BS}\right),m=\frac{\left(n-1\right)}{3}$ ), and then encodes and slices the ciphertext data. During the encoding process, the original ciphertext data $D^{*}$ will be encoded and sliced with matrix $M$ as the corrective censoring code coding matrix, which in turn will form multiple coding blocks.

$C=\left\{C_i,i\in \left[0,n-1\right]\right\}$

(6)

which contains m checksum encoding blocks. Finally, the generated multiple coded blocks need to be uplinked, and each node only needs to store part of the complete coded blocks and the block headers of the remaining coded blocks, without the need to synchronize all the coded blocks completely to each node, thus effectively reducing the storage consumption. The pseudo-code for this step is shown in Algorithm 2.

6.2. Key splitting and sharing

The key splitting and sharing phase splits the data encryption key $K_{sym}$ using the secret sharing technique and distributes and stores it to multiple DSU users, and only multiple DSU users work together to recover the key, realizing the secure management of the key.

Step1: The DO user generates a Cauchy matrix $M$ of order $n\times m$ , where $n$ represents the number of DSU users and $m$ is a predefined threshold. This matrix serves as the coefficient matrix for the m-dimensional spatial geometric equations, enabling the distributed sharing of the key $K_{sym}$ . Multiple subkey shares $k_i^{\prime }=\left\{k_1^{\prime },k_2^{\prime },\cdots ,k_n^{\prime }\right\}$ are generated. The pseudo-code for key splitting share is shown in Algorithm 3.

Step 2: The CP-ABE algorithm is utilized to encrypt each subkey share, and the access control policy is embedded into the subkey share, so that only the DSU user who meets the requirements of the access policy can decrypt the subkey share. The DO user inputs the access policy $A^{*}$ , the subkey share ${\hspace{0.17em}k}_i^{\prime }$ , and the master public key $PK$ , and generates the ciphertext with the access control policy, $c_i^k=\left\{c_1^k,c_2^k,\cdots ,c_n^k\right\}$ and distributes $c_i^k$ to the shared user DSU.

6.3. Recovering keys and data reconstruction

Step 1: When the DSU wants to access the medical data, it needs to first initiate an access request to the BS, and then obtain the ciphertext coding blocks $C=\left\{C_i,i\in \left[0,n-1\right]\right\}$ formed by encoding and slicing. However, these coded blocks are binary strings formed by encryption and encoding processes, and it is not possible to view the details of the data directly.

Step 2: To view the detailed data information first need to decode $C=\left\{C_i,i\in \left[0,n-1\right]\right\}$ , according to the principle of corrective censoring code can be known that when the number of coded blocks obtained from the BS is more than (at this time the value of n is equal to the number of nodes of the BS), you can recover the ciphertext data $D^{*}$ .

Step 3: After receiving the subkey share ciphertext $c_i^k$ distributed by the data owner DO, the DSU decrypts it using its private key, and only those DSUs that comply with the access policy $A^{*}$ can successfully decrypt it and get the correct subkey share $k_i^{\prime }$ .

Step 4: When the number of DSUs reaches a threshold $m$ , DSUs can utilize their own $m\times 1$ dimensional spatial plane equations to collaborate with other users to recover the m-dimensional spatial plane equation set.

$\{\begin{array}{l}{a}_{11}{x}_1+a_{12}{x}_2+\cdots +a_{1m}{x}_m=b_1\\ a_{21}{x}_1+a_{22}{x}_2+\cdots +a_{2m}{x}_m=b_2\\ \cdots \\ a_{n1}{x}_1+a_{n2}{x}_2+\cdots +a_{nm}{x}_m=b_n\end{array}$

(7)

In this system of linear equations, the key terms are defined as follows: $a_{ij}$ represents the spatial equation sub-coefficients previously distributed to the respective users, $x_j$ denotes the unknown coordinate variables required to reconstruct the original geometric point (i.e., the encryption key), and $b_i$ is the constant term corresponding to the specific user’s equation share.

The above equation can be written as $AX-B=0$ . The assembled coefficient matrix ( $A$ ) originates from the previously constructed non-singular matrix. This non-singular nature guarantees that matrix ( $A$ ) is strictly invertible, which is the mandatory mathematical condition to solve the linear equations and obtain a single unique solution. Consequently, the correct decryption key $K_{sym}$ can be accurately recovered to decrypt the ciphertext data $D^{*}$ . The pseudo-code for key recovery and data reconstruction is shown in Algorithm 4.

7. Security analysis

7.1. Threat model

Before proceeding with the formal security proofs, it is imperative to establish the rigorous threat models and collusion assumptions under which the MHBDS scheme operates. Given the hybrid architectural nature of the proposed framework, the threat landscape is defined based on the capabilities of three distinct types of adversaries:

1) External PPT Adversaries. For the data encryption layer, a Probabilistic Polynomial Time (PPT) adversary is assumed. The primary threat involves executing Chosen-Plaintext Attacks (CPA) from outside the authorized network or by unauthorized data-sharing users attempting to challenge data confidentiality. Regarding collusion assumptions, it is formally assumed that multiple unauthorized users can collude by pooling their respective attribute secret keys. The security boundary establishes that unless the mathematically pooled attribute set satisfies the target access policy ${\mathbb{A}}^{*}$ , the PPT attacker cannot reconstruct the symmetric encryption key.

2) Malicious Insiders. During the Blakley secret sharing and key distribution phase, a malicious adversary model is considered. Corrupted internal nodes in this phase are fully capable of arbitrarily deviating from the prescribed protocol. They pose active threats such as forging secret shares, submitting invalid spatial equations, and actively colluding to reconstruct the symmetric key illegally. The rigorous security assumption dictates that the total number of colluding malicious adversaries must be strictly bounded below the predefined spatial reconstruction threshold $m$ .

3) Semi-Honest Participants. During the SMPC-based collaborative computation phase, the standard Semi-Honest Model is adopted. Under this threat model, the corrupted entities strictly follow the protocol execution steps without malicious deviations. However, these semi-honest nodes are curious; they will collude and meticulously analyze all intermediate execution views to infer the private inputs of honest participants. The fundamental assumption is that at least one participant remains perfectly honest throughout the protocol execution.

7.2. Security proofs

Theorem 1

The proposed CP-ABE-based data encryption scheme is Indistinguishable under Chosen-Plaintext Attack (IND-CPA) secure, assuming the Decisional Bilinear Diffie-Hellman (DBDH) problem is intractable for any PPT adversary.

Proof

A formal IND-CPA game interacting between a PPT Adversary $\mathcal{A}$ and a Challenger $\mathcal{C}$ is constructed. The adversary’s capability is restricted such that $\mathcal{A}$ cannot query secret keys for any attribute set that satisfies the challenge access policy ${\mathbb{A}}^{*}$ . To provide an explicit reduction, a simulator $\mathcal{B}$ is constructed, which receives a DBDH challenge tuple $\left(g,A=g^a,B=g^b,C=g^c,Z\in {\mathbb{G}}_T\right)$ and uses $\mathcal{A}$ to determine if $Z=e{\left(g,g\right)}^{abc}$ .

Initialization: Adversary $\mathcal{A}$ chooses the challenge access structure ${\mathbb{A}}^{*}$ that it wishes to attack and sends it to Simulator $\mathcal{B}$ .

Setup: $\mathcal{B}$ implicitly sets the master secret key components utilizing the DBDH tuple elements $a$ and $b$ . It generates the public parameters $PK$ by embedding $g^a$ and $g^b$ into the attribute group elements, and sends $PK$ to $\mathcal{A}$ .

Phase 1: Adversary $\mathcal{A}$ adaptively issues polynomial bounded private key queries for attribute sets $S_1,S_2,...,S_q$ .

Adversary Capability Constraint: The strict constraint is that no queried attribute set $S_i$ satisfies the challenge access structure ${\mathbb{A}}^{*}$ . Since $S_i—{\mathbb{A}}^{*}$ , $\mathcal{B}$ can simulate the private keys by randomly choosing parameters and canceling out the unknown $a$ and $b$ components, outputting a valid simulated key $S{K}_{S_i}$ to $\mathcal{A}$ .

Challenge: $\mathcal{A}$ submits two distinct equal-length messages, $M_0$ and $M_1$ . $\mathcal{B}$ flips a random coin $\beta \in \left\{0,1\right\}$ . $\mathcal{B}$ constructs the challenge ciphertext $C{T}^{*}$ under ${\mathbb{A}}^{*}$ by implicitly setting the secret sharing scalar to $c$ (extracted from $C=g^c$ ). The core ciphertext component is masked by multiplying $M_{\beta }$ with $Z$ . $\mathcal{B}$ sends $C{T}^{*}$ to $\mathcal{A}$ .

Phase 2: $\mathcal{A}$ continues to query private keys with the exact same restriction as Phase 1.

Guess: $\mathcal{A}$ outputs a guess bit ${\beta }^{\prime }\in \left\{0,1\right\}$ .

Explicit Reduction: The reduction step is established as follows. If ${\beta }^{\prime }=\beta$ , it implies $C{T}^{*}$ is a valid encryption, meaning $Z=e{\left(g,g\right)}^{abc}$ (the input is a valid DBDH tuple). In this case, $\mathcal{B}$ outputs 1. If ${\beta }^{\prime }\ne \beta$ , it implies $Z$ is a random element in ${\mathbb{G}}_T$ (making the ciphertext independent of $M_{\beta }$ ), and $\mathcal{B}$ outputs 0. Let $ϵ$ be the non-negligible advantage of $\mathcal{A}$ . The probability that $\mathcal{B}$ correctly solves the DBDH problem is:

$\mathit{Pr}\left[\mathcal{B} \text{solves} \text{DBDH}\right]=\frac{1}{2}\left(\frac{1}{2}+ϵ\right)+\frac{1}{2}\left(\frac{1}{2}\right)=\frac{1}{2}+\frac{ϵ}{2}$

(8)

Thus, $\mathcal{B}$ gains an advantage of $ϵ/2$ in solving the DBDH problem. Since the DBDH problem is assumed to be intractable, the advantage $ϵ$ must be negligible. This completes the formal proof.

Theorem 2

Under the malicious model, the Blakley secret sharing mechanism guarantees information-theoretic security, ensuring no key leakage occurs as long as the number of colluding adversaries is strictly less than the reconstruction threshold $m$ .

Proof

A semantic security game is formalized. Let ${\mathcal{A}}_{mal}$ be an adversary capable of maliciously acquiring up to $k$ shares of the spatial equations, where $k\le m-1$ . ${\mathcal{A}}_{mal}$ chooses two target secret keys $K_0$ and $K_1$ . The Challenger flips a coin $b\in \left\{0,1\right\}$ , splits $K_b$ into $n$ spatial equations using threshold $m$ , and provides ${\mathcal{A}}_{mal}$ with $m-1$ shares.

Geometrically, the secret is a point in an $m$ -dimensional finite field space. Each share represents an $m-1$ -dimensional hyperplane. The intersection of $m-1$ non-parallel hyperplanes intrinsically forms a 1-dimensional line. Since the underlying finite field is uniformly distributed, every point on this line is equally probable to be the true secret. Therefore, the adversary’s view is entirely statistically independent of the embedded secret $K_b$ . The probability of ${\mathcal{A}}_{mal}$ correctly guessing $b$ is exactly $1/2$ , yielding an advantage of 0. Thus, unconditional security is guaranteed against $m-1$ colluding attackers.

Theorem 3

The proposed SMPC protocol operates securely in the semi-honest model, ensuring computational privacy provided there is at least one honest participant.

Proof

The standard Real vs. Ideal simulation paradigm is employed. Let $\mathrm{\Pi }$ be the protocol execution and ${\mathcal{A}}_{sh}$ be a semi-honest adversary controlling a subset of corrupted parties ${\mathcal{P}}_c$ with size $\left|{\mathcal{P}}_c\right|\le n-1$ .

Adversary View: The real view $Vie{w}_{\mathcal{A}}^{Real}$ consists of the inputs of ${\mathcal{P}}_c$ , internal coin tosses, and all messages (secret shares) received during the execution.

Simulator Construction: A PPT simulator $\mathcal{S}$ is constructed that only has access to the inputs and the final output of ${\mathcal{P}}_c$ . $\mathcal{S}$ generates a simulated view $Vie{w}_{\mathcal{S}}^{Ideal}$ by sampling random uniform values from the finite field for the incoming messages, subject to the constraint that the sum of all shares equals the final valid output.

Indistinguishability: In the equation $S=x_1+x_2+...+x_n$ , the underlying secret shares $x_i$ are generated using a uniformly random distribution. Consequently, the marginal distribution of any proper subset of shares (the messages received by ${\mathcal{P}}_c$ ) is perfectly uniform. Thus, the simulated messages generated by $\mathcal{S}$ are perfectly indistinguishable from the real messages. Mathematically, it holds that $Vie{w}_{\mathcal{A}}^{Real}\equiv Vie{w}_{\mathcal{S}}^{Ideal}$ . This formalizes that ${\mathcal{A}}_{sh}$ learns absolutely nothing beyond its own inputs and the legitimate outputs.

8. Performance analysis

8.1. Experimental environment

To ensure the reproducibility of the proposed MHBDS scheme, the experimental environment is structured into three primary components:

1) Infrastructure and software stack: The core blockchain framework is deployed on a server running Ubuntu 18.04 LTS, equipped with 32GB RAM and an Intel(R) Core (TM) i5-4590 CPU. All smart contracts and sharding logic are implemented using Golang v1.12. For performance evaluation, the TRP-PBFT consensus mechanism is simulated in IntelliJ IDEA on a Windows 10 environment (i5-8250U CPU) utilizing the JPBC (Java Pairing-Based Cryptography) library.

2) Blockchain network topology: We configured a permissioned consortium blockchain utilizing Hyperledger Fabric v1.4.0. The network consists of one medical organization managing four Peer nodes to simulate a distributed healthcare environment, and one Orderer node utilizing the Raft service for transaction ordering. The nodes are interconnected via a high-speed local network to minimize external propagation noise during throughput and latency testing.

3) Data characterization: Experiments were conducted using a synthetic medical dataset to maintain rigorous control over data volume variables. Data blocks ranging from 256 KB to 2048 KB were dynamically generated, with the erasure coding process utilizing the open-source Reed-Solomon library in Golang to perform precise sharding and encoding.

The detailed system specifications are summarized in Table 3.

Table 3.

Experimental environment.

Software/Hardware	Parameters
Operating System	Ubuntu18.04
Experimental platforms	Hyperledger Fabric1.40
Language	Golang
Memory	32GB
CPU	Intel(R) Core (TM) i5-4590

8.2. Functional comparison

Table 4 summarizes the functional comparison between our proposed scheme and three recent state-of-the-art baselines. While all schemes guarantee basic privacy protection and access control, the baselines exhibit significant limitations in handling large-scale medical data. Regarding storage efficiency, the schemes in Refs. 28 and 29 rely on standard full-replica IPFS, which inevitably causes a storage explosion when processing massive medical images. In contrast, MHBDS innovatively integrates erasure coding to construct a storage efficient sharding architecture, fundamentally minimizing network redundancy. Concerning consensus and robustness, the scheme in Ref. 29 utilizes standard PBFT, remaining vulnerable to view-change deadlocks caused by Byzantine nodes. Furthermore, the model in Ref. 30 lacks underlying consensus optimization. Conversely, the proposed TRP-PBFT incorporates dynamic trust evaluation and fast-polling to proactively isolate malicious nodes, thereby guaranteeing highly efficient and stable consensus for high concurrency healthcare environments.

Table 4.

Comparison of program functions.

​	MHBDS	Literature 28	Literature 29	Literature 30
privacy protection	√	√	√	√
access control	√	√	√	√
storage optimization	√	×	×	×
consensus improvement	√	×	×	×
trust management	√	×	×	×

8.3. Encoding and decoding efficiency

Before data is uploaded, encryption and encoding are necessary, while during data access, decoding and decryption processes are required. Therefore, the efficiency of encoding and decoding has a significant impact on the entire system. Figure 7 presents experimental test results related to data encoding and decoding. To generate these results, the Reed-Solomon algorithm from the Go open-source library was executed on 1024 KB synthetic data blocks. The number of encoding blocks was systematically varied from 11 to 20. For each configuration, the execution time for encoding and decoding was recorded in milliseconds using built-in time-tracking functions, as shown in Figure 7(a). The execution rates in Figure 7(b) were calculated by dividing the processed data volume by the recorded execution time. All plotted data points represent the average values from multiple test iterations to ensure reliability.

Figure 7.

Encoding and decoding efficiency.

The range for the number of encoding blocks is specified as 11 to 20, with the minimum execution time observed when utilizing 11 encoding blocks. At this point, the encoding operation takes approximately 223ms, and the decoding operation takes about 161ms. As indicated by Figure 7(a), an elevated quantity of encoding blocks results in extended durations for both encoding and decoding processes. Moreover, as shown in Figure 7(b), with the continuous increase in redundant data, the corresponding processing rate gradually decreases. However, since MHBDS generates relatively small data scales when splitting data, its impact on the overall system’s operational speed is also relatively minor.

8.4. System throughput

To generate the end-to-end system throughput results, a multi-threaded client simulator was deployed to mimic high-concurrency transaction requests encompassing the entire data-sharing lifecycle. The system throughput, defined as Transactions Per Second (TPS), was calculated using the formula: $TPS=N_{tx}/\mathrm{\Delta }T$ , where $N_{tx}$ represents the total number of successfully committed transactions, and $\mathrm{\Delta }T$ denotes the total end-to-end time elapsed from the initial data submission to final block storage. To ensure a fair comparison, the end-to-end operational logic of the baseline schemes was replicated and executed under the exact same environmental constraints. The block size was set to 1024KB, and the data transactions of MHBDS, Literature, ²⁸ Literature ²⁹ and Literature ³⁰ under different node counts were recorded and plotted into curves, respectively. The throughput comparison is shown in Figure 8.

Figure 8.

System throughput comparison.

Under the same number of nodes, MHBDS consistently outperforms the baselines. When operating with eight nodes, MHBDS achieves a throughput of approximately 1040 transactions per second (TPS). As the number of nodes increases, the throughput gradually declines and stabilizes. This superiority stems from MHBDS’s adoption of the optimized TRP-PBFT consensus mechanism coupled with an efficient data structure. Both the Healthcare 4.0 framework in Ref. 28 and the PHR sharing scheme in Ref. 29 utilize standard PBFT consensus. Since standard PBFT inherently imposes an $O\left(n^2\right)$ communication complexity for state synchronization, their communication overheads surge as the node count expands, leading to a sharp decline in TPS. Furthermore, the model in Ref. 30 relies on multi-round SMPC interactions, resulting in the lowest overall throughput. Overall, MHBDS significantly enhances data-sharing efficiency, demonstrating its superiority in handling large-scale distributed systems.

8.5. Consensus throughput

Throughput is an important indicator of the efficiency and performance of a consensus protocol, and a higher throughput means that the system can process more transactions or blocks more quickly, thus improving the overall performance. The experiment sets the number of transactions to 50 for a block-packing transaction and tests the throughput difference between TRP-PBFT and traditional PBFT under different nodes when the consensus time (block time) is 5 seconds. The throughput comparison is shown in Figure 9.

Figure 9.

Consensus throughput comparison.

Experimental results indicate that PBFT throughput increases from an initial 39.73 to 158.9649, while TRP-PBFT throughput rises from 108.3784 to 172.8357. Both PBFT and TRP-PBFT demonstrate a trend of increasing throughput with the addition of more nodes, as more nodes can process transactions in parallel, enhancing overall system throughput. However, when the number of nodes reaches a certain threshold, further additions may no longer significantly improve throughput, indicating a saturation point. Under these experimental conditions, the TRP-PBFT algorithm consistently outperforms the traditional PBFT algorithm across all node counts, exhibiting superior throughput performance and greater stability with a higher number of nodes. This is because, compared to PBFT, TRP-PBFT incorporates reputation value calculations and node grouping mechanisms, and selects primary nodes with lower fault probabilities, thereby enhancing the system’s parallel processing capability and fault tolerance, maintaining high throughput in large-scale node networks.

The throughput superiority in TRP-PBFT stems from two fundamental cryptographic and architectural mechanisms. First, the multi-party signature algorithm aggregates multiple independent signature verifications into a singular linear equation system. This cryptographic compression drastically reduces the message payload size during the prepare and commit broadcast phases. Second, the dynamic trust assessment acts as a strict network filter. By systematically excluding nodes with historically high response latency from the primary consensus group, the system proactively avoids the exorbitant computational costs associated with view-change protocols, ensuring continuous block generation.

8.6. Consensus latency

Blockchain latency is a key performance metric for consensus algorithms, which is the time elapsed from the time a transaction is submitted to the time it is finally confirmed on the blockchain. Experiments are conducted to compare the latency of the two algorithms in the time range of 10-60s, respectively. The consensus delay comparison is shown in Figure 10.

Figure 10.

Delay comparison.

It is evident that, within a specific time range, the TRP-PBFT algorithm demonstrates reduced latency compared to the PBFT algorithm. Specifically, it reduces average latency from 655.42 ms to 342.22 ms and exhibits superior latency stability. The latency of the TRP-PBFT algorithm rises in a relatively gentle trend, for example, in the time period of 10 to 20 seconds, the latency increases from 325.00 ms to 330.02 ms, and the increase is small and smooth. The latency of the TRP-PBFT algorithm shows a similar trend in the other time periods without a significant jump. On the other hand, the rising trend of PBFT delay is relatively more obvious, with large fluctuations in different time periods. Therefore, the experimental results indicate that as the number of nodes increases, the efficiency of PBFT diminishes, whereas TRP-PBFT demonstrates enhanced stability and robustness. Additionally, TRP-PBFT exhibits superior performance with reduced delay.

The remarkable reduction and stability in latency primarily stem from optimized communication complexity. Traditional PBFT protocols inherently suffer from an $O\left(n^2\right)$ message broadcast complexity, which inevitably triggers severe network congestion and exponential delay spikes as the participant scale expands. Conversely, the fast-polling timer integrated into TRP-PBFT fundamentally alters this waiting mechanism. By enabling nodes to transition to the next consensus phase immediately upon receiving a sufficient threshold of verified responses, the protocol effectively truncates the long-tail latency typically caused by slow or Byzantine nodes. This localized temporal cutoff ensures that the overall consensus delay remains decoupled from the worst-performing nodes.

9. Conclusions

The paper proposes a multi-party secure medical blockchain data-sharing scheme. The architecture employs Blakley’s secret-sharing technology for decentralized key distribution and integrates CP-ABE to implement fine-grained access control, thereby significantly reducing data leakage risks. To address the storage bottlenecks of large-scale medical datasets, data uploaded to the blockchain is encoded and fragmented using erasure-coding techniques. Furthermore, the introduction of the TRP-PBFT consensus mechanism enhances system efficiency, stability, and robustness. Experimental results demonstrate that MHBDS is both effective and practical; compared to the traditional PBFT mechanism, the proposed TRP-PBFT reduces average latency from 655.42 ms to 342.22 ms and increases average throughput from 107.31 TPS to 143.45 TPS.

Furthermore, while this paper has established a solid theoretical foundation for security through robust architectural design and rigorous mathematical proofs, the quantitative evaluation of the empirical performance of these security mechanisms remains an important area for exploration. Future work will design specific attack simulation scenarios to quantitatively measure the defense success rate and the precise computational overhead of the proposed security architecture under various malicious network conditions.