A Double-Blind Trial Platform Based on Distributed Ledger Technology

Abstract

In the pharmaceutical research and development process, the third phase of clinical trials involves double-blind trials to mitigate the influence of human subjective awareness on the experimental results and ensure the efficacy and safety of drugs or vaccines. However, conventional double-blind trials are often overseen by a single institution responsible for the entire trial process. Researchers centrally manage data, introducing risks of data loss and tampering. Furthermore, since researchers have full access to all experimental data, there is a potential for premature unblinding and leakage of results to specific individuals, giving rise to bias and conflicts of interest. To address these problems, this paper proposes a distributed-ledger-based double-blind trial platform called “BlindBox”. This platform leverages the immutability and decentralization of distributed ledgers to enhance the security of experimental data. On the other hand, the platform employs smart contracts to restrict personnel’s access to experimental data, coupled with RFID technology to encode and shuffle the experimental drugs discreetly. This ensures that no one can ascertain the pairing between test subjects and drug groups, preventing collusion and result manipulation. When the trial period concludes, smart contracts automatically unblind the results and publish them on the IOTA platform. By utilizing IOTA’s zero-value transactions, the platform reduces the cost of repeated data access and ensures information openness and transparency. This approach prevents deliberate premature unblinding or insider trading stemming from monopolized information. The platform proposed in this study is expected to enhance the credibility and accuracy of double-blind trials while promoting the willingness and convenience of public participation in experiments.

1. Introduction

Since 2019, the world has been grappling with the widespread outbreak of the novel coronavirus, prompting biotechnology firms across nations to embark on vaccine development to combat the pandemic. Notable pharmaceutical companies such as Pfizer [1], BioNTech [2], and Moderna [3] have actively engaged in these efforts. Varied vaccine technologies have been pursued, creating vaccines with distinct characteristics, ranging from mRNA-based to recombinant-spike-protein-based and adenovirus-based approaches. In the process of pharmaceutical research and development, it is necessary to carry out clinical trials to confirm the effectiveness and safety of a product before it can be marketed for public use. Clinical trials are typically divided into four phases [4]: Phase I clinical trials primarily focus on safety, observing the human body’s tolerance of the drug. Phase II clinical trials emphasize exploring adverse reactions and therapeutic efficacy. Phase III clinical trials are essential for confirming treatment effectiveness, involving a larger population and comprehensive evaluation to determine whether the drug can be marketed. Phase IV clinical trials, conducted after the drug’s approval and market launch, involve ongoing monitoring of the drug’s safety. If severe adverse effects arise, the medicine may need to be withdrawn. The double-blind trial is often introduced during Phase III clinical trials to mitigate the placebo effect [5]. This practice ensures that both the test subjects and the experimenters are unaware of which individuals belong to the control and experimental groups. By comparing the differences between the two groups, the influence of the placebo effect on the experimental results is minimized.

Traditionally, the process of a double-blind trial unfolds as follows: Initially, researchers issue recruitment notices to solicit volunteers. These researchers are usually affiliated with a centralized authoritative institution that upholds the experiment’s reliability through endorsement and supervision. To establish a reference point within the experiment, participants are divided into two groups: the experimental group and the control group. For instance, in vaccine testing, the vaccine is administered to the experimental group, while a placebo is given to the control group. The researchers manage the allocation of the participants into these groups. In a double-blind trial, neither the participants nor the experimenters know the distribution of the control and experimental groups. This blinding process prevents the experimenters and participants from gaining prior knowledge of their group assignments, thus reducing the potential impact of personal biases on the experimental results. During the trial, the experimenters administer the experiment to the participants and record the outcomes. Upon completing the investigation, the researchers disclose to the experimenters and the participants which group they were assigned. This disclosure is referred to as unblinding. After unblinding is completed, the researchers analyze the data and publish the results.

Research data are stored centrally in the abovementioned process, making it susceptible to loss due to single points of failure. Additionally, researchers have the potential to manipulate experimental data arbitrarily, thereby exerting control over the experimental outcomes. As experimental data are initially analyzed and interpreted by the researchers before being publicly disclosed, they may have access to the results before the general public. If these analyses are provided to interested parties before public release, it could result in significant issues of unfair advantage [6]. Numerous studies [7,8,9,10,11] have highlighted the substantial financial implications of clinical trial results for pharmaceutical companies. To ensure fairness in investment market trading and prevent clinical trial results from unduly affecting market activities, measures are required beyond legal actions. Researchers must be restricted from leveraging clinical trial results to manipulate trading markets. Furthermore, researchers might collude with participants or experimenters for economic gains. They might incentivize participants or experimenters with financial rewards to exaggerate the therapeutic effects of the experimental treatments, thus inflating the study’s outcomes for profit. For instance, in a double-blind trial, researchers could inform the participants or experimenters in advance whether they are in the control or experimental group, leading them to provide responses that align with the researcher’s expectations. This could artificially enhance the experimental effect in the experimental group beyond the actual outcomes or reduce the observed effect in the control group. These actions could magnify the observed differences between the two groups, thereby influencing the results of the double-blind trial. To address these potential issues, it is crucial to implement safeguards that ensure the integrity and transparency of the clinical trial processes, such as adopting decentralized and tamperproof technologies like blockchain, employing strict monitoring and auditing procedures, and establishing ethical guidelines for all involved parties.

Fortunately, blockchain [12] can address the above issues. Blockchain uses a data structure called a “block” to maintain, replicate, and share a decentralized ledger among multiple network nodes, offering decentralization, security, and transparency. Each block contains one or more transactions that are sequentially linked to form a continuously growing chain. Blockchain employs encryption techniques and consensus mechanisms to ensure the security and credibility of data. In addition to decentralization, security, and transparency, it possesses immutability; once data are recorded on the blockchain, they cannot be easily altered or deleted. Utilizing these features of blockchain can effectively address the problems associated with traditional double-blind trials. Originally stored within centralized institutions, experimental data can be maintained on a shared ledger by all nodes on the blockchain network. This approach resolves the issue of data loss due to single points of failure and prevents data monopolization by a few individuals. The problem of data tampering can be mitigated using blockchain’s immutability. As for the issue of premature unblinding leading to conflicts of interest, this can be mitigated using smart contracts [13]. Smart contracts are blockchain-based protocols that execute contract terms without requiring third-party verification. In addition to inheriting all of the features of blockchain, smart contracts are also autonomous. Once activated, a smart contract automatically executes its terms without human interference. Utilizing smart contracts’ autonomy, researchers cannot prematurely unblind and notify specific individuals of the experimental results. All experimental information is stored on the blockchain until the trial period concludes. The smart contract then automatically aggregates and analyzes the dispersed experimental records on the blockchain and publicly releases the unblinded results, ensuring access for everyone. Furthermore, smart contracts can be used to recruit, screen, and allocate experimenters and participants while maintaining the confidentiality of the experimental materials. This reduces the possibility of collusion between researchers and experimenters or participants, which could influence the experimental outcomes.

Based on the discussions above, the research objective of this study was to design and implement a distributed ledger-based double-blind trial platform called BlindBox. This platform encompasses the following functionalities:

Experimenter Recruitment: Users can register on the system, including researchers, experimenters, and participants, and undergo authentication. To prevent collusion between researchers and participants, both experimenters and participants must register for experiments through the system. After the recruitment period ends, the system randomly selects and notifies participants. Because the researchers cannot select the participants, fairness in the experiment is maintained. Additionally, to reduce the time and expenses that the participants would incur traveling to the experimental locations, the experimenters must specify their experimental locations during registration, enabling the participants to choose convenient options.

Access Control for Experimental Data: In a double-blind trial, different types of data exist, such as public data, semi-public data, and private data. Public data, such as experiment names, descriptions, and questionnaires, are open to all participants. Semi-public data are data that are viewable by specific participants, like completed experiment results and matched experimenters or items. During the experiment, the experimenters can only view their assigned participants, while the participants can only access their questionnaire results and corresponding item numbers, without accessing others’ information. Private data can only be accessed by smart contracts, like pre-unblinded experimental data and item–group associations. The system enforces data access permissions based on data categories.

Confidential Distribution of Experimental Items: In a double-blind trial, the experimenters and participants must not know whether they receive experimental items from the control group or the experimental group. The system hides group information within the smart contract to ensure integrity, making it unreadable. Furthermore, researchers could collude with experimenters through item serial numbers. To prevent this, the experimental items’ serial numbers are shuffled, and the connections between the experimenters and item groups are untraceable, avoiding researcher control over the experimental outcomes.

Automatic Unblinding Mechanism via Smart Contracts: Experimental results are stored on a decentralized blockchain instead of a centralized institution in this system. Thus, a smart contract automatically collects and unblinds experimental data stored on the blockchain, rewriting them for public query. Before smart contract unblinding, data access is restricted, preventing users from accessing data until the experiment concludes. Once the trial period ends, the smart contract triggers unblinding and opens data access, allowing all users to query the results.

The remaining sections of this paper are organized as follows: Section 2 introduces background knowledge and related work. Section 3 and Section 4 describe the framework and implementation of the proposed platform. Section 5 discusses the experimental results of performance evaluation in the proposed platform. Finally, Section 6 concludes the paper and outlines future work.

2. Related Work

2.1. Blockchain

Blockchain technology can be categorized into three generations: The first generation refers to the blockchain technology of Bitcoin. Its main characteristics are described as follows: It exploits proof of work (PoW) [14] to determine the next block producer, ensuring transaction verification and block addition. It has no central authority. Any participant can run nodes to validate transactions and maintain the blockchain. Transactions are protected using encryption techniques to ensure privacy and security. Once transactions are confirmed and added to the blockchain, they are difficult to modify or delete, ensuring their tamperproof nature. However, Bitcoin’s transaction processing speed could be faster and has limitations in handling a high volume of transactions. To address these scalability and application limitations, the second generation of blockchain technology, known as Blockchain 2.0, emerged, exemplified by Ethereum [15]. It introduced smart contracts that enable programmable code execution on the blockchain to automate and verify contract terms, facilitating various automated transactions and business logic [16,17]. It supports decentralized applications (DApps), such as decentralized financial services and supply chain tracing. It provides different consensus mechanisms like delegated proof of stake to achieve higher transaction throughput and faster confirmation speeds. It supports digital assets and tokenization, allowing real-world assets, stocks, voting rights, etc., to be traded and circulated on the blockchain. As for the third generation of blockchain, Blockchain 3.0, it introduces more innovative features and technologies to transform blockchain into a fundamental infrastructure for widespread application across various fields. For example, it utilizes more efficient consensus mechanisms and architecture to achieve higher transaction throughput and enhances cross-chain interoperability for data and asset exchange between different blockchains. The most important thing is avoiding energy-intensive mining processes to minimize energy consumption and environmental impact. Below are introductions to several commonly recognized blockchain platforms.

Bitcoin, proposed by Satoshi Nakamoto in 2008 [18], is currently the most valuable cryptocurrency in market capitalization. Bitcoin offers peer-to-peer electronic payments without the need for third-party financial institutions. Bitcoin uses the consensus mechanism of proof of work (PoW). It employs the SHA-256 hash function to convert any value into a fixed-length 256-bit value. The unique aspect of proof of work is its ease of verification but difficulty in calculating the answer. All nodes perform hash calculations on transactions. The earliest to calculate a hash value, meeting the condition of being less than the set difficulty value, confirms and establishes the transaction, achieving the goal of collective maintenance.

Ethereum [15] is an open-source public blockchain platform with smart contracts. Vitalik Buterin, influenced by Bitcoin, proposed it. Its main difference from Bitcoin is the inclusion of smart contracts. Unlike traditional contracts, smart contracts automatically execute when contract conditions are met. They have tracking, auditing, and user privacy protection features. Another feature of Ethereum is the Ethereum Virtual Machine (EVM), which executes smart contracts without being affected by the operating system. Similar to the Java Virtual Machine (JVM), the EVM provides protection. Smart contracts executed by the EVM cannot access system files, resources, or other applications. They can only access data within the smart contract, achieving isolation and protecting nodes from attacks. In Ethereum, any transaction or execution of a contract requires Gas as a miner’s work reward. The contract deployer determines the value and upper limit of Gas. The value of Gas influences whether miners process the contract. Higher-value contracts incentivize miners to compute more, increasing the transaction fees, while lower-value contracts reduce costs but extend the transaction completion time.

IOTA [19], proposed in 2015 by David Sønstebø, Sergey Ivancheglo, Dominik Schiener, and Serguei Popov, is a distributed ledger technology designed specifically for the Internet of Things (IoT). IOTA offers information security and payment methods, significantly improving transaction speed compared to Ethereum 2.0. IOTA abandons the linear blockchain structure in favor of a directed acyclic graph (DAG) known as Tangle [20]. Unlike traditional blockchains, Tangle does not package multiple transactions into a block for validation. Instead, each transaction is individually validated, requiring two other transactions to confirm it. IOTA employs the random-walk Monte Carlo (RWMC) algorithm to select two unconfirmed transactions and validate whether they conflict. This validation uses proof of work. IOTA eliminates mining, allowing users to verify transactions without fees and reducing energy wastage. This accelerates the transaction confirmation speed, as well as increasing the user numbers. Moreover, IOTA eliminates miners, enabling users to verify transactions, fostering scalability and transaction volume.

In addition to IOTA and Ethereum, there are other blockchains, including EOS.IO, Cardano, and Solana. EOS.IO [21], developed by block.one, is designed for enterprise use, processing thousands of transactions per second. However, its highly centralized node verification can compromise transaction security. Cardano [22], proposed by Charles Hoskinson, aims to replace Ethereum with cheaper transaction fees, higher scalability, and faster transaction speeds. Nevertheless, Cardano is still under development, with many technologies still needing to mature and become publicly available, potentially leading to drastic fee increases. Solana [23], introduced in 2020 by Anatoly Yakovenko and Raj Gokai, uses delegated proof of stake (DPOS) [24]. Users vote for transaction verifiers based on their cryptocurrency holdings, leading to faster transaction speeds. However, DPOS verification involves selected nodes, leading to centralization risks, potentially causing Solana to stop producing blocks due to limited storage or verified node failures.

In this paper, blockchain is chosen as the data storage platform, with security and transaction costs being the primary considerations for selecting a blockchain. EOS.IO’s and Solana’s extreme centralization compromises security. IOTA’s zero-fee transactions and Cardano’s and Ethereum’s lower transaction costs make transactions more affordable. However, IOTA’s smart contracts must be fully mature, Cardano is still developing, and Ethereum has more maturity and comprehensive development tools. Therefore, this paper uses Ethereum’s smart contracts for functionalities such as participant recruitment, permission control, automatic unblinding, and experimental material allocation. IOTA is employed to reduce transaction costs and improve query speed.

2.2. Blockchain-Based Clinical Trials

In recent years, blockchain’s attributes, such as decentralization, anonymity, and immutability, have driven its adoption across diverse sectors, including transportation [25,26], the Internet of Things (IoT) [27], smart agriculture [28], education [29,30], and healthcare [31]. Within the context of blockchain-based healthcare trial platforms, several pertinent studies have been undertaken:

Virtual clinical trials (VCTs) [32] have emerged as a modern alternative to conventional clinical trials, enabling participants to engage in trials from the comfort of their homes, thereby enhancing participation rates. Participants can provide informed consent online and continually report adverse events, a particularly advantageous approach for participants in rural areas or those with limited mobility. Yan Zhuang [33] introduced a blockchain-based VCT framework that addresses recruitment challenges and privacy concerns. This framework employs smart contracts to automate participant matching, recruitment, and remote monitoring, increasing convenience, data security, and patient confidentiality. It ensures that only authorized users can access patient data and monitors participant records for any unusual patterns. In case of anomalies, the smart contract alerts sponsors, mitigating the risk of participant dropout.

Peng Zhang et al. [34] put forth a solution for recruiting participants from rural areas and addressing the challenge of rare disease trials. They combined mobile computing and blockchain technology to validate research, facilitate data collection, and enable cross-study data sharing. Attaran et al. [35] introduced BBPM (Blockchain and Business Process Management), which leverages the InterPlanetary File System (IPFS) [36] to track COVID-19 transmission pathways and identify high-risk patients. Sidrah Abdullah et al. [37] proposed PRISED, a privacy-aware healthcare data-sharing framework using IOTA Tangle. This framework fortifies healthcare data security within an IoT environment, effectively addressing confidentiality, data integrity, and identity verification concerns. Ivan da Silva Sendin et al. [38] introduced VaccSC, a robust and transparent phase III vaccine trial system powered by smart contracts. Participants reported illnesses through smart contracts, and the vaccine’s effectiveness was measured until a predetermined threshold for unblinding was reached, ensuring a credible phase III clinical trial.

The studies mentioned above underscore the viability and efficacy of integrating blockchain technology into double-blind trials. The advantages of blockchain encompass safeguarding data through consensus mechanisms, decentralized upkeep, and autonomous privacy and analysis via smart contracts.

Table 1. Comparison of related work.

	Yan Zhuang [33]	BBPM [35]	VaccSC [34]	BlindBox
Blockchain	Ethereum	Built by POJO	Ethereum	Ethereum and IOTA
Experimental blockchain type	Private	Private	Private	Hybrid
Smart contract	With	Without	With	With
Purposes	Recruitment Data security	Process management Data security	Calculate vaccine efficiency	Auto-unblinding Collusion prevention Data security Recruitment

highlights the nuances among these trial frameworks. Yan Zhuang’s framework employed private Ethereum for trial experimentation in recruitment and data storage. BBPM devised a custom blockchain solution without engaging smart contract functionalities. VaccSC utilized private Ethereum to calculate vaccine effectiveness. Although the abovementioned research successfully solved the problem of participant recruitment, nevertheless, if the researcher deliberately arranges for people who collude with them to serve as subjects and informs them that they are the control or experimental group, they may control the experimental results. Although VaccSC uses smart contracts to automatically calculate the effectiveness of vaccines, it does not prevent the experimental results from being tampered with or monopolized by a few people, delaying the release of the experimental results, which may lead to problems such as profit transfer, insider trading, and even endangering public health.

In contrast, this paper’s proposed system integrates private Ethereum and public IOTA, offering capabilities for experiment publication, participant recruitment, data security and privacy maintenance, automatic unblinding, and result release. In terms of subject recruitment, we use smart contracts to automatically select subject candidates to reduce the possibility of colluded people participating in the experiment. For the pairing of experimental items and subjects, we use smart contracts and RFID to change the experimental item tag numbers and randomly pair them with the subjects, and we hide the old and new tag numbers and the experimental item and subject pairing table in the smart contract, which is not allowed to be read by anyone. Therefore, even if the subjects make illegal attempts, they cannot know whether they are in the experimental or control group and cannot fill in the questionnaire content that is helpful to their interests. For data security and privacy, we use smart contracts to protect the questionnaire content from modification and will not disclose it until the experiment is unblinded, to avoid the possibility of early unblinding. In addition, the subjects are identified by their digital wallet addresses on the blockchain rather than their personal information. The published questionnaire only has the serial number and filled-in content, without revealing who the subject of the questionnaire is. Therefore, no one will know the subjects’ reactions to the experiment unless they themselves reveal them. In terms of unblinding and publishing results, we use smart protection contract questionnaire contents to avoid them being read during the experiment and early unblinding. When the experiment deadline is reached, our system uses smart contracts to automatically collect the questionnaire contents, compute the experimental results, and publish the experimental results publicly on IOTA, which can prevent data falsification, delayed release of experimental results, or information monopoly. As mentioned above, the main contribution of this paper is to use blockchains and sensors to reduce human intervention in double-blind testing to eliminate illegal profit transfer, insider trading, and harm to public health caused by improper experimental processes.

3. BlindBox

The architecture of BlindBox is illustrated in Figure 1. The blue sections represent users, including researchers, experimenters, subjects, and sites. The registration contract consists of two main modules: the account module and the experiment module. The account module is responsible for handling user registration and login. Users within the system must possess an Ethereum address to represent their identity and access the contract. The experiment module serves two primary functions: verification of experiments by supervisory entities, and the creation of new experiments by researchers. The experiment contract incorporates modules for different user roles. The researcher module provides researchers with information about the current progress of the investigations. It offers interfaces for data querying, editing, and management based on the varying stages of the experiments. This includes experiment details, participant recruitment timelines, and survey locking. Researchers can design survey content using this module and add, delete, modify, and query surveys. The experimenter module empowers experimenters with permission to authenticate and participate in experiments. This module facilitates tasks such as matching experimental materials with subjects and submitting subject survey responses. The subject module provides subjects with features to authenticate the experimenters’ identities, match experimental materials, and engage in relevant experiment-related functions. The site module enables experimental sites to register experiments and request participation by experimenters.

In the BlindBox platform, a clinical trial includes five processes:

-

Experiment Publication and Review: Researchers publish experiments on the BlindBox platform. After creating an experiment within the system, it goes through a review process by supervisory entities. These entities verify the experiment’s legitimacy, ethical considerations, and adherence to guidelines before approval.

-

Recruitment of Sites and Subjects: Researchers can recruit experimenters and sites to participate in their experiments. Experimenters are responsible for administering the experiments and interacting with subjects. Sites provide the physical location for conducting the experiments. This recruitment process involves mutual agreement and collaboration.

-

Experimental Item Matching: The platform facilitates matching experimental items to subjects in item administration experiments. This ensures that subjects receive the appropriate items based on the experiment’s requirements. The matching process is carried out securely and accurately.

-

Conducting Experiments and Recording: Experimenters are responsible for conducting the experiments on the recruited subjects at the designated sites. This includes following the experimental protocol, providing the necessary instructions, and monitoring subjects during the experiment. The platform enables experimenters to record data, observations, and subject responses accurately.

-

Unblinding Procedure: Unblinding procedures reveal whether subjects received the experimental drug or a placebo. This step is typically carried out after the experiment has concluded and the data have been collected. It is essential to maintain the integrity of the results. The BlindBox platform ensures that the unblinding procedure is conducted securely and transparently, adhering to the predefined protocols.

In summary, the BlindBox platform facilitates the entire lifecycle of experiments, from publication and review to recruitment, drug matching, administration, recording, and the crucial unblinding procedure. This comprehensive approach ensures the integrity and reliability of experimental outcomes while providing a secure and collaborative environment for researchers, experimenters, sites, and subjects. The processes of double-blind trials in BlindBox are detailed as follows:

3.1. Experiment Publication and Review

Experiment publication is illustrated in Figure 2. Researchers input details such as the experiment name, content, duration, and number of subjects. These details are uploaded to the registration contract through the system. The registration contract stores the experiment information on the blockchain for future retrieval and reference. Subsequently, the registration contract generates a corresponding experimental contract and records the address of the experimental contract on the blockchain. Researchers then utilize the experimental contract to design the survey questionnaire. Survey questionnaires can include multiple-choice and open-ended questions, but only multiple-choice questions can be processed by smart contracts. Content from open-ended questions is anonymized and stored on the IOTA platform.

In Figure 3, the process of experiment review is depicted. After researchers submit their experiment for review by the supervisory entity, the entity assesses its details and content. This review ensures that the experiment aligns with established standards and guidelines. The supervisory entity examines information provided by the researchers, including experiment information and survey content. If the experiment is found to meet the supervisory entity’s criteria and is compliant with regulations, the system updates the status of the experimental contract. This transition marks the experiment’s advancement to the recruitment phase, allowing the recruitment of experimenters and subjects to begin. However, if the experiment fails to meet the supervisory entity’s criteria, the researchers are informed of the issues that must be addressed. This might involve modifying certain aspects of the experiment, revising the content, or making other necessary adjustments. Alternatively, the experiment might be canceled if the issues are significant and cannot be resolved.

The recruitment process on this platform involves two distinct phases: The first phase centers on enlisting suitable experimental sites. As depicted in Figure 4, these sites could include medical facilities like hospitals or clinics. Researchers initiate this stage by defining a recruitment timeline in the experimental contract. They actively invite hospitals or clinics to participate in the experiment. Interested sites wishing to join the study must formally register within the system, providing details about the site and responsible experimental personnel. After thoroughly verifying that the potential site meets the stipulated requirements, including appropriate facilities and qualified medical staff, the site is designated as a prospective location. Following the conclusion of the recruitment period, the experimental contract compiles a roster of eligible experimental sites. The final selection of the experimental site is accomplished through an automated randomization process conducted within the experimental contract.

The second phase involves recruiting subjects, as illustrated in Figure 5. Individuals interested in participating as subjects must await the completion of the experimental site recruitment phase before indicating their intent to partake in the experimental contract. Researchers set a deadline for subject recruitment after the culmination of the site recruitment. Potential subjects can access the experimental contract to select a preferred site upon expressing interest. Notably, subjects are presented only with minimal information about the hospital, such as its name, address, and lab location. Once the subjects choose a site, they undergo an interview or medical evaluation administered by the experimental site’s designated personnel. This step ensures that the subjects meet the predetermined eligibility criteria. Subsequently, subjects upload the required experiment consent forms and formally register their participation within the experimental contract. As the designated subject recruitment deadline established by the researcher approaches, the experimental contract automatically evaluates whether the number of recruited subjects satisfies the prerequisites. If the quota is met, the contract proceeds to select subjects and randomly communicate the outcomes to them. These selection results are logged within the experimental contract and can be accessed for post-unblinding queries. To enhance fairness and thwart potential manipulations, the recruited subject count must surpass at least twice the number stipulated within the experimental contract.

3.2. Experimental Item Matching

The experimental item pairing mechanism proposed by this platform consists of RFID and smart contracts. It utilizes rewritable RFID and smart contract permissions to achieve the effects of shuffling and confidential pairing of experimental items, preventing collusion between researchers, experimenters, and test subjects to produce biased questionnaire survey results favoring the experimental group. Initially, the smart contract divides experimenters and test subjects into groups, which are divided into two phases: In the first phase, experimenters and test subjects at each experimental location are evenly divided into control and experimental groups. The second phase involves pairing experimenters and test subjects, regardless of their group (experimental or control). The experimenters and test subjects only know the individuals who they are paired with; they do not know the group assignments of the test subjects. The smart contract automatically handles the above grouping methods, and no one can predict or influence the grouping results.

On the other hand, before the experiment begins, researchers need to send the experimental items to the experimental location for experimentation by the experimenters. Each experimental item has its own RFID tag. Researchers need to scan and record the RFID numbers (old) of the experimental items, which should equal the number of test subjects. Half of the experimental items belong to the control group, while the other half belong to the experimental group. Upon arrival at the experimental site, to prevent researchers from arranging the items to allow the experimenters to identify whether an item is from the experimental or control group, the experimenters must place all received experimental items into a black box for shuffling. The experimenters then sequentially retrieve the items from the black box and scan their RFID tags to allocate them to test subjects. The system randomly selects test subjects and generates new Tag IDs to replace the original ones for the experimental items. The new and old Tag IDs and the matching test subjects of the experimental items are recorded in the experimental contract (as shown in Figure 6). After the Tag IDs are replaced, even if the experimenters repeatedly scan, they will only obtain the new Tag IDs. On the contrary, the researchers can no longer read the Tag IDs of the experimental items before trial unblinding, thereby preventing researchers and experimenters from colluding with one another through Tag IDs. Except for the experimental contract, no user can know the mapping between the old and new Tag IDs. By querying the experimental contract, the matched subject and experimenter of each item can be found using the new Tag ID, and then the experimental item of the Tag ID can be used to test the subject.

3.3. Conducting Experiments and Recording

As illustrated in Figure 7, the process involves awaiting the arrival of test subjects at the designated experimental site. After the subject arrives at the experimental location, they scan the Tag ID of the experimental item to check the experimental contract with the paired experimenter and subject, allowing the experimenter and the subject to mutually confirm that the experimental item is indeed paired with both parties, and then drug administration can begin. After the experiment, the test subjects will submit the results of the experimental questionnaire to the experimental contract. The experimental contract can determine whether the sending trader is a registered test subject through the wallet address of the sending trader, whether or not the trial date has expired, and whether the filled-in questionnaire complies with the format designed by the researcher. If the above conditions are met, the experimental contract will record the questionnaire; otherwise, it will refuse to record the questionnaire.

It is worth noting that if the same subject fills in the questionnaire repeatedly, the experimental contract will be rejected. The filled-in questionnaires of the subjects cannot be changed or reviewed. Only when the blinding is removed will the statistics be collected through the experimental contract, thereby preventing the experimental data from being tampered with or unblinded in advance. Although the test subjects can write down the experimental results by hand and inform the researchers, since they cannot know whether they are in the control group or the experimental group, no one can unblind themselves and learn the experimental results in advance.

3.4. Unblinding and Result Disclosure

As illustrated in Figure 8, the control over querying questionnaire survey results is vested within the experimental contract. Upon receiving a read request, the experimental contract assesses whether the experiment progresses. If the experiment is ongoing, the contract denies the read request, informing the requester that the experiment has yet to reach its conclusion. As the predetermined experiment duration elapses, the experimental contract automatically computes statistical metrics (utilizing mean values as an example) for both the control and experimental groups. Concurrently, the experiment status transitions to the “unblinded” phase. The platform disseminates unblinded outcomes onto the IOTA network to optimize efficiency and economize costs associated with unblinding result queries. Additionally, the IOTA transaction address of the unblinded results is recorded within the experimental contract, serving as a reference point for future inquiries. Once the experimental contract registers the “unblinded” status, invoking the unblinding functionality a second time is precluded. This safeguard prevents researchers from exerting undue influence on outcomes by repeatedly invoking the unblinding process.

After the unblinding is completed, all users can obtain the experimental results through the experimental contract. To reduce the cost of accessing the experimental results, the system records the unblinding results in the IOTA transaction and records the IOTA transaction address in the experimental contract. The length of IOTA’s transaction address is 64 bytes, which is much smaller than that of the questionnaire results. Furthermore, IOTA does not require handling fees, which can effectively reduce the cost of repeatedly checking records. Anyone can check the unblinding results if there is an IOTA transaction address. This makes it possible to avoid the unblinding results being known to only a few people, resulting in opaque information and improper transfer of benefits, as depicted in Figure 9.

4. Implementation

The double-blind trial platform based on a distributed ledger proposed in this study has been successfully implemented. The software stack is illustrated in Figure 10. The uppermost blue section represents the user interface layer, which provides web interfaces for researchers, experimenters, and participants. The green section represents the management layer.

This layer consists of four main functionalities: The account manager is responsible for user account registration and authentication within the platform. The data manager oversees access control and ensures the presentation format of the experimental data. The contract manager handles creating and deploying experimental contracts and the signing of those contracts by researchers, experimenters, and subjects. The query manager is dedicated to searching for experimental contracts that meet specific criteria. The core layer, depicted in yellow, processes requests from the management layer and implements key functions. These functions include account registration and authentication, access control, contract building, contract deployment and execution, condition filtering, and contract exploration. The infrastructure layer, depicted in light orange, encompasses the primary software components used in the system. OpenSSL is responsible for generating encryption and decryption of public and private key pairs and encrypting and decrypting data. SHA and RSA provide different encryption and decryption methods, respectively. The Blockchain Access API provides a blockchain function library for blockchain-related operations. IOTA is responsible for publishing and querying the unblinded results, while Ethereum is responsible for deploying and using smart contracts. In the practical implementation, this plan utilizes iota.js [39] to publish and query IOTA transactions within the IOTA framework and uses web3.js [40] to deploy and interact with smart contracts on the Ethereum platform. Moreover, it uses Solidity [41] to compile smart contracts, exploits Geth [42] and Hornet to build Ethereum and IOTA nodes, respectively, and develops the web API using Express.js [43] within the Node.js environment. The rest of this section will detail the critical Solidity codes involved in experiment publication, experimental site and subject recruitment, experimental processes, and trial unblinding.

4.1. Experiment Publication

The experiment release process is shown in Figure 11. The process is as follows: (1) The researcher enters the experiment name, experiment information, experiment date, number of experimenters, and number of subjects into the web API (/NewExp) and enters the account password through Basic Auth. (2) The web API (/NewExp) checks whether the account password matches the information on the blockchain. An error message will be returned to the researcher if the account password is incorrect. (3) The web API (/NewExp) converts the unit of the input date into milliseconds because the time on the smart contract is based on the timestamp of the block, and the unit is milliseconds. (4) The web API (/NewExp) enters the above information into the registration contract. (5) The contract is registered to deploy a new experimental contract, the account address of the experimental contract is recorded, and it is returned to the web API (/NewExp). (6) The web API(/NewExp) then returns the address of the experimental contract to the researcher.

Figure 12 shows the data structure and codes for publishing the experimental contract, which are used to record and track experimental research contracts and associate them with specific addresses and other information. The serial number is used to retrieve the experimental contract in the registered contract. The experimental contract’s constructor records the number of experimenters, the number of subjects, and the experiment time.

4.2. Recruitment of Experimental Sites and Subjects

The recruitment process is divided into two stages: The first stage is to recruit experimental sites and experimenters. First, the researcher enters the recruitment time into the web API (/startrecruit)), and the web API calculates the recruitment time in milliseconds. Second, the web API (/startrecruit)) logs the recruitment time into the experimental contract. Third, the hospital staff in charge of the experiment log the experimental site into the experimental contact through the web API (/Expregister). The experimental contract checks whether the recruitment time has ended. If it has ended, the hospital staff will be notified by an information message saying ”recruitment has finished”; otherwise, they will be asked to input the list of experimenters into the experimental contract. After the first stage of recruitment finishes, the experimental contract generates a list of experimental sites.

The second stage is to recruit subjects. The process is as follows: The researcher enters the recruitment time into the web API (/startrecruitsubject), and the web API (/startrecruitsubject) calculates the recruitment time in milliseconds and logs the recruitment time into the experimental contract. Potential test subjects request a list of experimental sites for the experiment through the web API (/register), and then select one of the experimental sites. After registration, the subjects must go to the experimental site to take a health exam and to sign and upload the consent form through the web API (/Sendconsent). When the web API logs the consent file location into the experimental contract, the experimental contract will check whether the recruitment time has ended when deciding to accept or reject the log request.

Figure 13 shows the registration of experimental sites and participants. The first step is to set the identity of the participant based on their ID and generate a random number for grouping and sorting. If it is an experimenter (ID 1), set the hospital where they located and add them to the experimenter list. If it is a subject (ID 2), perform additional checks (such as confirming whether the selected hospital is on the list), set the selected hospital, and add it to the list of subjects. If it is a hospital (ID 3), add its address to the related list and add the hospital to the hospital list for the subject to choose.

4.3. Experimental Process

When the experiment begins, the researchers must send the experimental products to each experimental location. Before sending the items out, the experimental item’s RFID tag must be scanned and recorded in the experimental contract. The program code is shown in Figure 14. The steps are as follows: (1) Permission check: Confirm that the owner of the contract (i.e., the researcher) initiated this function call, to ensure that only authorized personnel can add items. (2) Group judgment: Determine whether the item is added to the experimental or control group based on the passed group parameter. (3) Quantity check: Check whether the quantity of items in the selected group has reached the predetermined quantity limit. (4) Add items: Add the RFID tag of the item to the item list of the corresponding group.

On the other hand, the researcher triggers the experimental contract to randomly select subjects, store them in the experimental contract, and notify the selected subjects to go to the hospital of their choice for testing. Figure 15 shows the codes for pairing subjects with experimenters. The steps are as follows: (1) Check the number: Ensure that the number of subjects is sufficient; that is, the length of the index_subject array must be at least equal to the subcount. Make sure that the number of items in the experimental group is consistent with the expected number; that is, the length of list_Experimental_Item must be equal to subcount_e. Make sure that the number of items in the control group also meets the requirements; that is, the length of list_Control_Item must be equal to subcount_c. (2) Assign subjects to experimenters in the hospital: Through a for-loop, subjects are randomly assigned to experimenters in the hospital. Use keccak256 to generate a pseudorandom number and select the subject from the index_subject array based on this number. After selection, update the index_subject array to remove the assigned subjects.

When the experimental items are delivered to the experimental site, the experimenter must place the experimental items in the black box and then randomly extract the experimental items and request the web API (/Scanitem) to scan the RFID tag of the experimental items. After the web API (/Scanitem) scans and reads the Tag ID, it will send the Tag ID to the experimental contract. The experimental contract will generate a new RFID Tag ID, record the corresponding relationship between the old and new Tag IDs in the experimental contract, and then return the new RFID Tag ID. The web API (/Scanitem) then returns the new Tag ID from the experimental contract, copies it to the RFID tag, and then sends it back to the user. After the item is rescanned, the experimental contract will automatically match the experimental items with the subjects and record them. When the subject comes to the hospital for testing and scans the experimental items, the new Tag ID will be used to query and verify the experimental contract with the subject and experimenter matched with this Tag ID. Since no one can read the correspondence between the old and new Tag IDs, the subjects cannot know whether they are in the experimental group or the control group and, therefore, cannot collude with the researchers to deliberately produce questionnaire results that are beneficial to the pharmaceutical company.

Figure 16 shows the program code for matching subjects with experimental items. The process assigns subjects by a for-loop to the experimental or control group according to the number of subjects and the number of experimenters in the hospital. If the subject is assigned to the experimental group, the exp is set as true, and the subject’s RFID pairing is performed. If the subject is assigned to the control group, the exp is set as false, and the RFID pairing of the experimental item is performed. The final step is to create an RFID pairing record for each subject and experimental item.

4.4. Trial Unblinding

When the subject comes to the experimental site for the experiment, the experimenter first verifies that the subject is registered at the site through identity verification and then scans the experimental item through RFID to confirm that both parties are the matched experimenter and subject for the experimental item. If this is correct, the experimenter will start the experiment on the subject. After the experiment is completed, the subjects fill in the questionnaire through the web API (/Fillquesetion), and the filled-in questionnaire results are transmitted to the experimental contract for storage.

Figure 17 shows the program code for filling out the questionnaire. The steps are as follows: (1) Make sure that the current time is still within the time range allowed by the experiment. (2) Confirm that the experiment has started and the questionnaire is available. (3) Check whether the number of answers provided is consistent with the number of questions in the questionnaire. (4). Store subjects’ answers to the questionnaire in the corresponding array according to the group of the subject.

After the experimental period is reached, the experimental contract automatically collects all questionnaire results, calls unblind_Ave() to calculate the average of the multiple-choice questions in the questionnaire, and formats the results of the multiple-choice questions and the answer questions. The experimental contract will upload the unblinded results to IOTA and then input the transaction address returned by IOTA into the experimental contract. After unblinding, anyone can retrieve the transaction address from the experimental contract through the web API (/GetResult) and query the results on IOTA. The web API (/GetResult) will return the unblinded results together with the transaction address. Anyone can then directly use the transaction address to query IOTA for the unblinded experimental results without having to read the experimental contract again. Figure 18 shows the unblinding code. The process is to check whether the experimental period has been reached and unblinding has not been executed. If true, traverse the data of the experimental group (answer) and the control group (answer_c), calculate the average answer value of each question, and then store the calculated average values in unblind_Average and unblind_Average_c, respectively.

5. Experimental Results

This study conducted performance evaluation experiments on BlindBox. The experiments conducted included testing the time required for experimental deployment and other experimental steps and the time needed for unblinding and querying. The resource specifications used during the experiment were four personal computers, as shown in

Table 2. Experimental environment.

Hostname	CPU	RAM	Usage	Remarks
Lab-01	Intel(R) i7-8700	32 GB	Ethereum, web API	Docker image
Lab-02	Intel(R) i7-8700	32 GB	Ethereum	Docker image
Lab-03	Intel(R) i7-8700	32 GB	Ethereum	Docker image
Lab-04	Intel(R) i7-8700	32 GB	IOTA	Docker image
DR050	N/A	N/A	UHF RFID reader

. Lab-01, Lab-02, and Lab-03 constitute a private Ethereum network with a PoW difficulty of 0x40000, while Lab-04 sets up a Hornet node to provide IOTA services. DR050 is an RFID reader–writer that uses USB to connect to devices and provides short-range RFID read–write capabilities. On the other hand, we also scanned the Solidity codes of the registration contract and experimental contract for analyzing the security disks of the proposed platform.

5.1. Experimental Deployment Time

In this experiment, we used Lab-01 to conduct 100 experimental deployments and calculated the average time of the experimental deployments for each word count. As shown in Figure 19, the average experimental deployment tends to increase linearly with the word count. The steps of the experimental deployment mainly consist of account authentication, writing the experimental contract onto Ethereum, and storing the address of the experimental contract in the registration contract. The costs of account authentication and storing the address of the experimental contract are 922.4 and 1242 ms, respectively, which are almost identical for different word counts. The remaining time is spent on writing the experimental contract. The more words the experimental contract has, the more obviously writing the experimental contact onto Ethereum dominates the cost of experimental deployment. Therefore, simplifying the contract’s content is essential for reducing the cost of the experimental deployment. Although the speed of experimental deployment currently seems slow, it will be improved with the advancement of blockchain technology.

5.2. Experimental Step Costs

The durations of each step of the experiment are illustrated in Figure 20. Throughout this study, Lab-01’s web API was employed to execute the experiment 100 times on a private Ethereum network, with averages being computed for each measured time in milliseconds (ms). The process involved the following steps:

-

“register” signifies the time users take to complete the registration process.

-

“login” denotes the duration users require to log into the system successfully.

-

“newitem” captures the time researchers expend on appending new items to the experiment.

-

“newoptions” reflects the time researchers spend introducing fresh questionnaire options.

-

“expregister” signifies the period needed for experiment venues and participants to register within the experimental contract.

The bulk of these steps can be accomplished within 1 to 2 s. The “expregister” step, while relatively lengthier, is also completed in roughly 3 s.

On the other hand, the time taken to fill out the questionnaires is depicted in Figure 21, with measurements in milliseconds (ms). Lab-01’s web API processes the requests and communicates with the experimental contract on the private Ethereum network to facilitate questionnaire completion. For each data point in this study, an average of 50 trials were conducted. The x-axis illustrates the length of the questionnaire, indicated by the number of questions, ranging from 5 to 45. The findings from the experiments reveal a notable correlation between the length of the questionnaire and the time taken for completion. As the number of questions in the questionnaire increases, the time required for participants to finalize the questionnaire also experiences an escalation. This phenomenon can be attributed to Ethereum’s reliance on the proof-of-work (PoW) mechanism, which exposes the execution speed to the influence of mining activities. Notably, when the questionnaire comprises 45 questions, the time required for completion extends to 12 s. The slightly increased waiting period suggests potential considerations for the future, such as the exploration of faster-executing smart contracts, exemplified by platforms like IOTA, to ameliorate execution time constraints.

5.3. Unblinding Cost

For this phase of the experiment, the NIDA-MDS-0004 dataset [44] was employed, specifically the Cocaine Craving Questionnaire, as a set of questionnaire items. This dataset aims to assess the effectiveness and safety of modafinil compared to a placebo in reducing cocaine dependence. The selected questionnaire contains 45 items about cocaine cravings. The experiment’s outcomes are presented using arithmetic means. In Figure 22, the questionnaire length progresses from 5 to 45 items, with a fixed pool of 50 participants. The experiment was conducted 300 times and averaged, with the time measured in milliseconds (ms). Comparable to the questionnaire completion time, the results indicate that the time required for unblinding increases almost linearly with the extension of the questionnaire’s length.

In Figure 23, with a constant questionnaire length of 45 items, the number of participants ranges from 25 to 100. The experiment was conducted 300 times and averaged, with the time measured in milliseconds (ms). Notably, as the subject count grows, the time taken for unblinding also increases accordingly. It is worth mentioning that the verification speed of the miners is random, and the unblinding time of experiments with large amounts of data may not necessarily be longer, and vice versa. Since the unblinding process occurs just once and is fully automated upon execution, the waiting time associated with it is considered quite tolerable when contrasted with conventional unblinding methods.

Moreover, Figure 24 shows that when the researchers attempted to request unblinding ahead of the designated end time, the experimental contract promptly declined this premature request and communicated to the researchers that the end time of the experiment had not been reached. This experimental result validates the data protection capabilities of the experimental contract.

5.4. Query Time

The visualization of various data-querying experiments is presented in Figure 25. In this study, Lab-01’s web API served as the recipient of requests, facilitating queries to either the experimental contract on the private Ethereum network or Lab-04’s Hornet node. Each data point in this experimental analysis represents an average outcome from 100 runs. The following types of queries were conducted:

-

“getquestionnaire” involved retrieving questionnaire content from the experimental contract.

-

“getexplist” encompassed querying the present roster of experiments from the registration contract.

-

“getresult” denoted users querying unblinding outcomes via the experimental contract.

-

“IOTA getresult” indicated users querying unblinding outcomes using an IOTA transaction address.

The findings indicate that IOTA exhibits significantly faster querying speeds than Ethereum, showcasing the potential efficiency to be gained by revealing unblinding outcomes on the IOTA network. This approach effectively mitigates subsequent economic and time expenditures related to querying processes. In contrast, the prior studies discussed in Section 2 did not furnish the essential blockchain environment configuration parameters and execution times. This omission hinders the direct comparison of their efficiency with our experiment. However, our research distinguishes itself by rigorously evaluating the BlindBox platform through the outlined experiments. This thorough assessment validates BlindBox’s efficacy and usability, setting it apart from the previous studies that needed comparable insights.

5.5. Security Analysis

In this study, we made use of smart contracts through Solidity programming to implement the proposed platform.

Therefore, for security analysis, we scanned the Solidity codes of the proposed platform using Slither [45], which is a smart contract static analyzer. Figure 26 shows that the registration contract has no program vulnerability.

However, the experimental contract has three major issues that may cause the failure to store and protect data, fund loss, and inconsistent states, as shown in Figure 27. We discuss the impact and solution of the issue as follows.

The first issue is using a weak PRNG (pseudorandom number generator) such as the following source code.

-

cpabeRegister.register(uint256,string) (Exp.sol#78-98) uses a weak PRNG: “table[msg.sender].random = uint256(keccak256(bytes)(abi.encodePacked(block.difficulty,block.timestamp))) % 1000 (Exp.sol#81)”.

-

cpabeRegister.startExp() (Exp.sol#176-220) uses a weak PRNG: “list_hospital_personnal[table[index_subject[temp % index_subject.length]].locate][1].push(index_subject[temp % index_subject.length]) (Exp.sol#183)”.

-

cpabeRegister.startExp() (Exp.sol#176-220) uses a weak PRNG: “j = temp % index_subject.length (Exp.sol#184)”.

The numbers generated by the PRNG are based on the initial seed and algorithm. The entire number sequence can be reproduced if the initial seed is known. This may lead to security risks. The solution is to change the initial seed in run time or use a cryptographically secure random number generator such as Chainlink VRF [46] or Provable [47].

The second issue is re-entrance functions such as the following analysis report:

-

Exp.fillQuestion(value,s_value,table[subject].exp): State variables written after the call(s), table[msg.sender].filled = 1 (Exp.sol#139).

-

pabeRegister.Explist(address[]) (Exp.sol#164-175).

-

cpabeRegister.checkhospital() (Exp.sol#50-53).

-

cpabeRegister.checknotReseacher() (Exp.sol#59-62).

-

cpabeRegister.fillExp(uint256[],string[],address) (Exp.sol#135-141.)

Reentrancy attacks may cause funds in the contract to be repeatedly withdrawn, causing unexpected fund losses or giving external contracts the opportunity to attack and manipulate the internal state of the contract. The solution to avoid reentrancy attacks is to check the appropriate state before executing logic and perform external calls at the end or consider using function modifiers like non-reentrant to prevent re-entry. Moreover, standard interfaces and contract templates are necessary to reduce risks when dealing with untrusted contracts.

The third issue is to use timestamps for comparison, such as the following source codes:

-

cpabeRegister.startExp() (Exp.sol#176-220) uses timestamps for comparisons.

Dangerous comparisons: - j < index_subject.length - 1 (Exp.sol#184).

-

cpabeRegister.get_new_RFID(uint256) (Exp.sol#228-231) uses timestamps for comparisons. Dangerous comparisons: require(bool,string)(RFID_pairing_table[ID] != 0,error RFID) (Exp.sol#229).

-

RecordExp.fillQuestion(uint256[],string[],bool) (RecordExp.sol#88-104) uses timestamps for comparisons. Dangerous comparisons: require(bool,string)(block.timestamp < EndTime,exp time is over) (RecordExp.sol#89).

Block times on the blockchain may not be consistently accurate and can fluctuate within a certain range. Using timestamps may result in inconsistent states. Moreover, malicious miners might attempt to manipulate timestamps to influence the execution of smart contracts. One solution is to consider using relative time measurements based on block intervals or other consensus-specific time units rather than relying solely on absolute timestamps. This can make smart contracts less susceptible to inaccuracies in block time. Another is to use trusted external services such as Chainlink’s Oracle [48] to fetch reliable timestamps.

Since a smart contract cannot be patched after it is deployed, addressing the above program vulnerabilities is essential to maintain the security and effectiveness of the proposed platform.

On the other hand, some information issues exist in the Solidity source codes of the proposed platform. These information issues are listed as follows:

-

Compare to a Boolean constant.

-

Variable, function name, or parameter is not inmixedCase.

-

Variable is never used.

-

Variable should be cached.

-

Variable should be declared immutable.

Although these issues have nothing to do with security (except for the last one), addressing these issues by modifying variable naming and declaration is necessary to improve performance and reliability, reduce resource usage, and make the program readable.

6. Conclusions and Future Work

This study successfully developed a double-blind trial platform called BlindBox based on a decentralized ledger. With the increasing demand for vaccine development due to recent outbreaks of novel coronaviruses, vaccines must undergo rigorous clinical trials before receiving regulatory approval. Among these trials, the double-blind trial is crucial but historically vulnerable to data loss, tampering, collusion, and conflicts of interest. The approach presented in this paper addresses these challenges by harnessing the decentralized and tamper-resistant nature of distributed ledgers to mitigate data loss and tampering risks. Additionally, integrating smart contracts mitigates the potential for collusion and conflicts of interest.

On the other hand, the combination of Ethereum and IOTA is leveraged to enhance the operational efficiency of the proposed platform. This involves storing experimental results on the IOTA network and publicly revealing IOTA transaction addresses. The experimental results confirm that IOTA significantly outperforms Ethereum, with querying through IOTA taking only 3 milliseconds compared to Ethereum’s 86 milliseconds. While the experiments of this study were conducted within a private Ethereum network, the transition to a public Ethereum network may entail a slight reduction in execution speed. Nevertheless, double-blind tests’ read-one-write-many data access pattern maintains reasonable overall data access efficiency. Furthermore, the experiments validate IOTA’s feeless nature in considerably reducing both the time and economic costs associated with repetitive experimental result queries.

Presently, the implementation of the proposed platform relies on Ethereum smart contracts. While the platform’s usability has been established through experiments, there remains the potential for security and efficiency enhancements. In the future, we will patch the program vulnerabilities of experimental contracts in the proposed platform according to our security analysis. IOTA’s smart contracts, although still in testing, present an avenue for future development by improving the system’s speed. By migrating smart contracts to IOTA, the execution speed of the proposed system can be improved, and the absence of transaction fees would markedly reduce contracts’ operational costs. Additionally, IOTA’s smart contracts are compatible with Ethereum’s Solidity programming language and the Ethereum Virtual Machine (EVM), which will help simplify the transition process. Moreover, we will enhance the reliability and scalability of the proposed platform for stratifying the demands of complex environments and heavy workloads.

Collaborations with medical institutions are on the horizon to apply this system to real-world medical experiments. We will conduct a comprehensive evaluation in real-world scenarios by collaborating with hospitals in the future. Furthermore, the heightened demand for cross-national and cross-disciplinary clinical trials during the COVID-19 pandemic underscores the need to extend the system’s scope beyond straightforward experimental processes. Overcoming complexities such as multi-language support for experimental contracts, allocation of experimental resources across diverse countries, and designing monitoring bodies and regulations for different nations pose promising areas for future research.