Source-linked AI summary
Using Blockchain and smart contracts for secure data provenance management
Aravind Ramachandran, Dr. Murat Kantarcioglu
TL;DR
Scientific research needs trustworthy provenance records, but prior provenance systems did not validate changes before storing them. DataProv combines blockchain, smart contracts, and cryptographic techniques to collect and verify provenance. In two real-world scenarios, it captured provenance with fixed cost and moderate overheads.
Problem
Prior provenance systems did not validate changes before storage, while research provenance must support trustworthy records without compromising privacy or ownership.
Source: §1 · p. 1Method
DataProv uses blockchain, smart contracts, encryption, and participant voting to collect provenance and verify submitted changes.
Source: §1.1 · p. 1, §1 · p. 1, §5 · p. 5Results
DataProv captured provenance with fixed cost and moderate overheads in clinical drug-trial and wheat-production scenarios.
Source: §1.1 · p. 2Takeaways & Limitations
Approved provenance changes are immutable on the blockchain, and trails are replicated across nodes for availability and fault tolerance.
Source: §1 · p. 1The current system permits only one outstanding change per document, restricting concurrent updates.
Source: §6.3 · p. 6
Abstract
from arXiv · showhide
Blockchain technology has evolved from being an immutable ledger of transactions for cryptocurrencies to a programmable interactive the environment for building distributed reliable applications. Although, blockchain technology has been used to address various challenges, to our knowledge none of the previous work focused on using blockchain to develop a secure and immutable scientific data provenance management framework that automatically verifies the provenance records. In this work, we leverage blockchain as a platform to facilitate trustworthy data provenance collection, verification, and management. The developed system utilizes smart contracts and open provenance model (OPM) to record immutable data trails. We show that our proposed framework can efficiently and securely capture and validate provenance data, and prevent any malicious modification to the captured data as long as the majority of the participants are honest.
1 INTRODUCTION
DataProv combines blockchain, smart contracts, and cryptographic techniques to capture and verify scientific data provenance. In two real-world scenarios, the system captured provenance with fixed cost and moderate overheads.
1 INTRODUCTION
- Maintaining provenance matters because scientific data manipulation can undermine research validation; one cited audit found fraud in 0.25% of trials.The audit was conducted by Cancer and Leukemia Group B, a National Cancer Institute-sponsored multicenter clinical-trial group.Source: §1 · p. 1
- Scientific data provenance records a dataset’s origin, owner, and transformations, supporting source verification and research transparency.The introduction motivates provenance tracking as a way to increase trustworthiness and transparency in research results.Source: §1 · p. 1
- The system uses blockchain, cryptographic techniques, and smart contracts to capture provenance and validate changes before logging them.Approved provenance changes cannot be modified after storage; trails are replicated across blockchain nodes.Source: §1 · p. 1, §1.1 · p. 1
1.1 Overview of Our Contributions
- DataProv uses randomized voting and monetary penalties to discourage malicious provenance changes, with penalties enforceable when at least half of participants are honest.The system stores provenance trails in smart-contract log events and provides customized verification scripts for authorized users.Source: §1.1 · p. 2
- DataProv captures provenance with fixed cost and moderate overheads in clinical drug-trial and wheat-production scenarios.The authors report implementation and evaluation in both settings.Source: §1.1 · p. 2
2 BACKGROUND
The background introduces Ethereum smart contracts, the paper’s provenance representation, and assumptions about adversaries and honest participants.
2.1 Ethereum
- Ethereum smart contracts are on-chain programs that execute when specified conditions are met, with computational steps charged as gas.DataProv is built on Ethereum, which records smart-contract executions on the blockchain.Source: §2.1 · p. 2
2.2 Provenance Model
- DataProv represents provenance using Open Provenance Model artifacts, agents, processes, and relationships between them.An action can be represented as a user, the old and new file versions, and the modification process.Source: §2.2 · p. 2
2.3 Threat Model
- The threat model includes external attackers lacking document access and internal users who can log incorrect changes; security assumes at least half of authorized users are honest.The system assumes cloud storage is untrustworthy and stores files encrypted.Source: §2.3 · p. 2
3 SYSTEM OVERVIEW
DataProv tracks encrypted, versioned research documents and records changes through a workflow that combines cloud verification, client voting, and blockchain logging.
3 SYSTEM OVERVIEW
- Documents are encrypted and versioned, and the system assumes modifications use only the latest version while ignoring changes absent from provenance records.The owner grants users access to the document and the keys needed to access it.Source: §3 · p. 2
- Users are encouraged to submit truthful change details through deposits, which are redistributed to voters who identify defective submissions.Client applications retain persistent information about documents each user can access.Source: §3 · p. 2
3.1 Provenance Capture Life Cycle
- A change requester uploads a new file version, submits a signed and timestamped request with hashes and a deposit, then authorized clients verify and vote on it.The request includes the document ID, encrypted hashes of the previous and current versions, and the cloud file link.Source: §3.1 · p. 3
- Rejected changes are penalized, while accepted changes are recorded in the document tracker with author, version hashes, an OPM representation, and a signature.The requester receives the deposit back when the change is accepted.Source: §3.1 · p. 3
4 SYSTEM DETAILS
DataProv divides provenance management between on-chain smart contracts and off-chain clients and cloud scripts. Contracts manage access, voting, and provenance events, while off-chain modules support user interaction and document verification.
4 SYSTEM DETAILS
- The system combines Ethereum contracts for access control, provenance trails, and voting with client applications, voting timers, and cloud verification scripts.These are its on-chain and off-chain components.Source: §4 · p. 3
4.1.1 Document Tracker contract.
- The Document Tracker manages document access, records provenance events, and stores trails in event logs to reduce Ethereum storage costs.It supports granting and revoking access, generating trails, and recording initiator signatures; actual data remains off-chain because of public accessibility and storage limits.Source: §4.1.1 · p. 3
- The owner controls who may add provenance trails, and each change must pass the vote contract before it can be logged.In the current implementation, document access rights are nontransferable.Source: §4.1.1 · p. 3
- Because verification needs vary by setting and on-chain checks may reveal sensitive information, participants run verification off-chain and vote on-chain.The authors cite the lack of sufficiently general and efficient zero-knowledge techniques for their use cases.Source: §4.1.1 · p. 4
4.1.2 Vote contract.
- Voting can run as simple majority or threshold voting; the contract accepts a change after the voting interval when the applicable vote requirements are met.Only one outstanding change per document is allowed to preserve chain continuity and consistency; documents with fewer than three users may log changes without voting.Source: §4.1.2 · p. 4
4.2.2 Event Watcher module.
- The client interface supports document tracking and access changes, while event watchers check signatures, invoke verification, and cast votes for clients.The watcher automates voting and keeps track of documents in which the user is a stakeholder.Source: §4.2.1 · p. 4, §4.2.2 · p. 4
4.2.3 Timer module.
- A timer starts the voting interval when a change event appears and ends the voting process when that interval expires.The client event watcher observes vote-contract events and coordinates verification with the cloud script.Source: §4.2.3 · p. 4
4.2.4 Verification script:
- The cloud verification script checks submitted hashes, compares the unconfirmed file with its last stable version, and flags unrequested changes.After validation, it restricts write access to the original owner; the script is customizable and the current implementation supports Google Drive through Google Apps Script.Source: §4.2.4 · p. 4
5 VOTING PROCESS
The voting process combines stakeholder decisions with randomized threshold voting for larger groups, and analyzes the probability and cost of obtaining enough votes.
5 VOTING PROCESS
- A change triggers a voting-phase event and client timer; clients verify it, cast votes, and the contract rejects it if most votes are against.Accepted changes return the initiator’s deposit; rejected changes divide it among voting participants.Source: §5 · pp. 4–5, Figure 2 · p. 5
5.1 Majority voting
- For documents with fewer than five stakeholders, simple majority voting accepts or rejects a change according to whether most users vote against it.This scheme requires every stakeholder to vote, making it expensive for larger user groups.Source: §5.1 · p. 5
5.2 Randomized Threshold Voting
- Randomized threshold voting targets at least s votes by selecting clients with probability t/n, where t > s, and restarts rounds that fall short.Clients hash the current block number, encrypted change text, gas limit, and initiator address; after the maximum restarts, a change lacking enough votes is rejected and the deposit refunded.Source: §5.2 · p. 5
5.2.1 Randomized Voting Analysis.
- For n users selected with probability t/n, the analysis bounds the chance that fewer than s votes arrive, accounting for a chosen user’s probability of failing to vote.The text notes that the failure probability pf can be adjusted for users who are offline or do not want to vote.Source: §5.2.1 · p. 5
- With n = 100 and s = 60, no failures were observed in 100 trials when t > 70, although the theoretical upper bound remained non-zero.Figure 3 compares estimated and theoretical failure probabilities for varying t when pf = 0.0.Source: Figure 3 · p. 6, §5.2.1 · p. 6
- Expected voting cost is analyzed for rounds that continue until at least s votes arrive, using the one-round probability of falling short.The analysis relates t, s, n, and that failure probability to expected cost.Source: §5.2.1 · p. 6
6 SYSTEM ANALYSIS
The analysis examines DataProv’s security and privacy defenses and identifies a concurrency constraint: the current system does not allow multiple outstanding changes for one document.
6.1 Security Analysis
- Access controls reject change requests from users without document access, while stale signed requests are ignored using each document’s latest timestamp.Source: §6.1 · p. 6
- A non-owner internal adversary succeeds only with control of more than half the document’s allowed users; randomized voting obscures voter selection, while owner collusion can still leave a traceable trail.Source: §6.1 · p. 6
6.2 Privacy Analysis
- Observers can infer document IDs, change counts, ciphertexts, signatures, and associated public addresses, but not users’ identities; only the owner knows identity.Source: §6.2 · p. 6
6.3 Concurrency
- The current system permits only one outstanding change per document; supporting non-conflicting concurrent changes would require an extra verification-script check.Source: §6.3 · pp. 6–7
7 EXPERIMENTAL EVALUATION
Across two real-life scenarios, DataProv’s individual smart-contract operations used nearly constant gas at reasonable overhead. The clinical-trial case evaluates provenance operations and patient-set verification.
7 EXPERIMENTAL EVALUATION
- Across two real-life scenarios, individual operations used nearly constant gas at reasonable overhead.The evaluation calculated average costs for individual smart-contract operations.Source: §7 · p. 7
7.1 Clinical Drug trial
- The clinical-trial scenario tracks monthly updates to a shared drug-trial document and verifies that the original patient set is retained.The trial spans twelve months, with updates from experiment groups in various locations.Source: §7.1 · p. 7
7.1.1 Add Document.
- 139552 gas was the average cost to add the trial’s single file; provenance records stay fixed-size regardless of the original file size.The document owner supplies the initial file, which includes patient details and drug dosage.Source: §7.1.1 · p. 7
7.1.2 Add User.
- 90559 gas was the average cost per user-addition transaction; user details are stored as hashes of user addresses.Only the document owner can grant access, and Figure 5’s gas spikes reflect differences in hashing requirements.Source: §7.1.2 · p. 7, Figure 5 · p. 7
7.1.3 Initiate Change.
- 731768 gas was the average cost to initiate a change and its voting process.Doctors initiate changes monthly to record side effects, if any; Figure 6 shows gas distribution across initiations.Source: §7.1.3 · p. 7, Figure 6 · p. 7
7.1.4 Voting phase.
- 89176 gas was the average voting-process cost; Figure 7’s opening-period spikes reflect voting-interval initialization.Participants’ votes are recorded and tallied as for or against the change.Source: §7.1.4 · p. 8, Figure 7 · p. 8
7.1.5 Termination:
- 249812 gas was the average termination cost; rejecting a change uses more gas because voters receive portions of the initiator’s deposit.A majority against rejects the change; acceptance records it in the event log and refunds the deposit. Figure 8 shows termination-cost distribution.Source: §7.1.5 · p. 8, Figure 8 · p. 8
7.1.6 Verification Script:
- The verification script compares submitted and independently generated hashes, then checks whether the current file retains the original patients.It uses the current file’s link and submitted hashes to check the change.Source: §7.1.6 · p. 8
7.2 Tracking Wheat Production
The wheat-production use case applies DataProv to quarterly updates of annual production data. Its threshold-voting process rejects out-of-turn votes and restarts when too few votes arrive.
7.2 Tracking Wheat Production
- The system’s shared functions use the same gas as in the clinical-trial case, while voting and termination use slightly more.The use case tracks annual wheat production with quarterly file updates.Source: §7.2 · p. 8
7.2.1 Initiate vote phase:
- 778979.5 gas was the average cost to initiate the voting phase for a submitted document change.The vote contract checks the current user’s access and initiates the protocol.Source: §7.2.1 · p. 8
7.2.2 Vote phase:
- 90862 gas was the average cost per registered vote; the contract rejects votes cast outside the randomized threshold.Simulated internal-adversary votes outside the threshold cost less gas to reject than valid votes; Figure 9 shows cost distribution.Source: §7.2.2 · p. 8
7.2.3 Termination:
- Threshold voting restarted an average of three times per change, with each restart using less gas than terminating the change phase.The timer ends a voting phase after a fixed interval; Figure 10 shows termination-cost distribution.Source: §7.2.3 · p. 8, Figure 10 · p. 9
7.2.4 Verification Script:
- For wheat-tracking files sized 1KB to 5KB, verification took 10 to 45 seconds.The script compares the current file’s year-on-year data with verified data.Source: §7.2.4 · p. 9
7.3 Operation Cost
DataProv’s evaluation reports nearly constant gas per transaction and near-linear cumulative gas use for individual functions. Contract operations take near-constant time and less than a second in the reported usage scenarios.
7.3 Operation Cost
- Per-transaction gas remains almost constant, while cumulative gas for an individual function grows near-linearly.The paper cites the voting function as an example and reports that most operations have relatively little cost.Source: §7.3 · p. 9, Table 1 · p. 9
7.4 Contract Execution Duration
- Contract operations take near-constant time and less than a second in the reported usage scenarios.The reported average time is per thousand operations; execution time depends on network speed and block-mining speed.Source: §7.4 · p. 9, Table 2 · p. 9
8 RELATED WORK
DataProv extends blockchain provenance work with privacy-preserving storage, access control, and verification tailored to scientific data. Unlike ProvChain, it automatically checks and rejects invalid changes before they enter the change hash-chain, using incentivized randomized voting instead of a physical verifier.
8 RELATED WORK
- DataProv implements access-control policies while focusing on provenance capture, and its smart contracts act as a decentralized trusted authority for provenance trails accepted through voting.Unlike approaches that store provenance in transactions, DataProv uses smart-contract event logs.Source: §8 · p. 9
- DataProv uses encryption and hashing for privacy, digital signatures against malicious logging, and address checks to restrict access to smart-contract methods.Verification is performed off-chain for efficiency and generalizability.Source: §8 · p. 10
- DataProv combines blockchain immutability with access control, privacy, and verification, extending earlier provenance proposals for food products, blockchain platforms, and research objectives.Its trails are stored in smart-contract event logs, and authorized users can run application-specific verification scripts.Source: §8 · p. 10
- Automated verification scripts reject invalid changes before they enter the change hash-chain, while incentivized randomized voting removes the need for a physical verifier.Verification scripts can be reused by similar applications to reduce development costs.Source: §8 · p. 10
9 CONCLUSION
DataProv provides access-controlled, privacy-preserving provenance trails with signed and timestamped proof of file changes. In two real-life scenarios, operations had acceptable cost and near-constant time.
9 CONCLUSION
- In two real-life scenarios, DataProv operations ran with acceptable cost and near-constant time.The evaluation covered clinical trials and wheat production tracking.Source: §9 · p. 10
- Digital signatures and timestamps provide proof of file changes, while appropriate keys restrict access to blockchain change logs.Source: §9 · p. 10
- Randomized voting strengthens trust in captured change trails, and smart contracts impose monetary penalties for deviations.Source: §9 · p. 10
10 APPENDIX
The appendix specifies the change-log event fields and outlines proofs concerning randomized-voting selections and voting-phase cost. It also notes that the cost of one voting round varies linearly with the number of participants.
10.1 Change Log Event Format
- Each change-log event records a document ID, initiator address, encrypted prior and new file hashes, cloud link, OPM representation, timestamp, and initiator signature.Source: §10.1 · p. 10
10.2 Proof of Theorem 5.2
- The proof represents the number V of selected users as a sum of individual selection indicators and sets its expectation to t − n·pf using Theorem 5.1.It applies the theorem with a = t − n·pf − s.Source: §10.2 · p. 10
10.3 Proof of Theorem 5.3
- The per-round voting cost C_t is linear in t, and a failed round incurs its cost before voting restarts.The expected voting-phase cost is modeled recursively from the one-round failure probability p_t and cost C_t.Source: §10.3 · p. 11