Source-linked AI summary
A Blockchain-based Approach for Data Accountability and Provenance Tracking
Ricardo Neisse, Gary Steri, Igor Nai-Fovino
TL;DR
GDPR creates expanded, harmonized obligations for processing EU residents’ data, while subject-centered accountability and provenance tools remain limited. The paper proposes publicly auditable blockchain contracts and three design models, implementing two of them to examine feasibility, privacy, granularity, performance, and scalability. Its conclusions relate model choice to data sensitivity and exchange frequency, while identifying scalability, economic, and enforcement boundaries.
Problem
The paper addresses the lack of subject-centered solutions for tracking data access, use, transfer, provenance, consent compliance, and consent withdrawal under GDPR.
Method
The paper analyzes three blockchain-contract models for encoding usage-control policies and provenance information, implementing subject-created contracts and controller-deployed contracts that subjects may join or leave.
Results
For sensitive data exchanged less frequently, fine-grained subject contracts are more adequate, while dynamic data with frequent exchanges and strict scalability requirements favor controller-oriented approaches.
Takeaways & Limitations
Blockchain contracts can support publicly auditable data accountability and provenance tracking, with different models trading off privacy, granularity, performance, and scalability.
Takeaways & Limitations
Public-chain throughput and transaction fees constrain scalability, while private chains may let providers ignore opt-out requests unless cryptographic acknowledgment is used.
Abstract
from arXiv · showhide
The recent approval of the General Data Protection Regulation (GDPR) imposes new data protection requirements on data controllers and processors with respect to the processing of European Union (EU) residents' data. These requirements consist of a single set of rules that have binding legal status and should be enforced in all EU member states. In light of these requirements, we propose in this paper the use of a blockchain-based approach to support data accountability and provenance tracking. Our approach relies on the use of publicly auditable contracts deployed in a blockchain that increase the transparency with respect to the access and usage of data. We identify and discuss three different models for our approach with different granularity and scalability requirements where contracts can be used to encode data usage policies and provenance tracking information in a privacy-friendly way. From these three models we designed, implemented, and evaluated a model where contracts are deployed by data subjects for each data controller, and a model where subjects join contracts deployed by data controllers in case they accept the data handling conditions. Our implementations show in practice the feasibility and limitations of contracts for the purposes identified in this paper.
1 INTRODUCTION
The GDPR expands and standardizes data-protection obligations, while this paper addresses the lack of subject-centered tools for accountable, provenance-aware data handling. It proposes blockchain contracts to encode consent and usage conditions for data access, use, and transfer.
- The GDPR applies to organizations outside the EU processing EU residents’ personal data and establishes one set of rules across EU member states.
- Data subjects authorize controllers to access personal data, while controllers determine processing purposes and may delegate processing to processors.
- The paper identifies a lack of subject-centered solutions for tracking access, use, transfer, consent compliance, and consent withdrawal.
- Its blockchain platform encodes usage-control policies in contracts deployed per recipient or joined by subjects accepting controller-defined conditions.
- The paper analyzes three models and implements two, comparing their privacy, accountability granularity, performance, and scalability properties.
2 BACKGROUND
The paper uses a public blockchain ledger and smart contracts as the technical foundation for provenance tracking and usage-control enforcement. Data and policy representations provide structured inputs for encoding accountability rules and evaluating permitted actions.
- The solution relies on the open-source Ethereum Virtual Machine as a public blockchain-based distributed ledger platform.
- The EVM maintains a decentralized transaction ledger and executes smart contracts without requiring a shared trusted third party.
- Blockchain transactions are organized into hash-linked blocks, making confirmed transactions non-modifiable or removable under the described chain verification.
- EVM contracts are stateful Turing-complete programs whose state-changing functions require paid transactions, while read-only functions can be invoked without them.
- Data provenance model: The provenance model specifies primitive and composite data types, data instantiations, and data instances.
- Usage-control policies: SecKit encodes data-usage restrictions as Event-Condition-Action rules with preventive actions that can allow, deny, modify, or delay activities.
3 SOLUTION DESIGN CHOICES
The design offers three blockchain-contract models that trade off contract cardinality, customization, provenance granularity, scalability, privacy, auditability, and censorship resistance. The paper also identifies practical boundaries involving throughput, fees, off-chain integration, and the guarantees provided by the system.
- Contract models: Three models vary contract cardinality: subject-specific contracts for controllers, subject-specific contracts for data instances, and controller contracts joined by subjects.The models differ in whether subjects tailor policies per controller or data instance, or accept a controller’s predefined policies.
- Granularity and scalability: Models (a) and (b) provide fine-grained provenance and data-usage tracking, while model (c) reduces contract count at the cost of customization.Model (a) is suited to highly sensitive exchanges, whereas model (c) has substantially fewer contracts but limited policy choice.
- Blockchain architecture: A public blockchain improves auditability and censorship resistance, but private deployment can allow an authority to reject subjects’ withdrawal transactions.The design therefore requires fair transaction processing, such as adding subject transactions within at most one day.
- Privacy: Privacy-friendly provenance encoding can avoid revealing exchanged data instances, while pseudo-identifiers prevent direct subscription linkability across controllers in models (a) and (c).Model (b) instead requires a unique address known by all controllers, making identity linkability unacceptable from the stated anonymity perspective.
- Performance and scalability: The controller-generic approach scales better in contract count but can exceed public-chain throughput for Facebook-like providers.Facebook’s approximate five new users per second would require five transactions per second for contract joining alone, compared with Bitcoin’s usual three tx/s and Ethereum’s roughly 15 tx/s.
- Economics: Public-chain fees may make high-transaction models impractical, and the paper does not provide a complete economic analysis.The authors identify private chains as a way to reduce processing fees, while noting that subjects and controllers would need an agreement over fee payment.
- Off-blockchain communication: The blockchain records and audits communications, but transferring data and integrating Swarm or Whisper remain off-chain requirements outside the paper’s scope.The proposed models therefore do not constitute a complete implementation of decentralized storage and messaging integration.
- Guarantees: The approach enables verifiable data custody and misuse notifications but does not prevent controllers or processors from unlawfully retaining or redistributing data.Controllers and processors may instead obtain certified evidence that data was acquired in a GDPR-compliant way for presentation to supervisory authorities.
4 SUBJECT CONTRACT MODEL
The subject contract model lets each subject regulate a controller’s use of shared data through a blockchain contract that tracks provenance, evaluates policies, and logs authorized events. Privacy is supported through obfuscated information and separate identifiers, while contract storage and processing limits constrain policy flexibility.
- Subject contract model: Each subject creates a policy-based data usage contract for each controller or processor receiving their data.The contract specifies constraints on data usage and redistribution.
- Subject contract model: The contract combines data provenance tracking, policy evaluation, and event logging for data transfers and usage transactions.Controllers check whether an activity is allowed before recording the actual usage event on the blockchain.
- Privacy-preserving provenance: Data provenance is stored in privacy-friendly form using a secret nonce and hashes rather than plaintext data values.The design aims to prevent blockchain crawling and re-identification through known data values.
- Policy enforcement: Policy behavior is encoded using obfuscated event attributes and operator-state updates, including temporal windows for cardinality and time-based rules.The sample policy permits one billing message every 30 days and denies other usage activities.
- Contract constraints: Because contracts have limited storage and processing capabilities, new policies or data transfers require new child contracts rather than flexible reconfiguration of one contract.The implementation evaluated storing hashes as state variables versus signaling them as contract events.
- Privacy and limitations: Separate blockchain addresses help prevent linkability across controllers, while pseudonymity and unobservability are provided by the model.Colluding controllers or processors can still achieve linkability when users provide unique identifiers such as email addresses.
5 CONTROLLER CONTRACT MODEL
The controller contract model uses one coarse-grained contract for many subscribing subjects, encoding reusable policy templates and supporting bulk event logging. Its implementation reduces transaction costs compared with the subject-specific model.
- Controller contract model: A controller or processor creates one contract containing shared usage and redistribution constraints for all subscribing subjects.The contract serves as a repository for configurable policy templates instantiated for individual subjects.
- Policy templates: Enforcement templates define reusable policy patterns, while configuration templates apply them to all users subscribing to the service.A data-assignment function associates policy variables with each subject’s encoded data.
- Bulk accountability: Bulk events allow the controller to log executions involving many subjects or activities completed at nearly the same time.Bulk attributes can be parameterized for subsets such as subjects from a particular country.
- Evaluation: Contract creation requires 0.34 million gas, while subjects joining or leaving requires around 40 thousand gas.The sample contract stores the policy as a string encoding such as XML or JSON and requires no other operation after joining or leaving.
6 RELATED WORK
Related work applies blockchains to provenance, access control, privacy, and healthcare data, but emphasizes challenges in representing digital data and achieving privacy and scalability. The paper builds on these directions with a more comprehensive accountability approach.
- Digital data provenance: Blockchain provenance for digital data must address cloning and transfer while establishing at least the data’s first origin.Unlike uniquely fingerprintable physical goods, digital data cannot be distinguished solely through inherent physical properties.
- Prior provenance work: Earlier blockchain proposals include high-level verification and attestation of individuals’ data provenance.The cited ID2020 workshop paper presents a proof of concept rather than the detailed approach developed here.
- Access control: Bitcoin-based privacy proposals encode access permissions in transactions while storing data hashes on-chain and data itself off-chain.These approaches use blockchain-executed protocols to govern access to private service-collected data.
- Healthcare applications: Healthcare applications use blockchains to control access to off-chain data, but prior work identifies scalability and data-privacy limitations.MedRec extends this direction with Ethereum smart contracts for authentication, confidentiality, accountability, and data sharing of electronic health records.
7 CONCLUSIONS AND FUTURE WORK
The paper finds that blockchain contracts are feasible for GDPR-oriented data accountability and provenance tracking, with the appropriate model depending on data sensitivity, exchange frequency, and scalability requirements. Future work targets blockchain scalability, business-oriented platforms, and automated contract generation.
- Conclusions: For sensitive data with infrequent exchanges, fine-grained subject-created contracts for each controller and processor are more adequate.This model provides more granular accountability and provenance tracking.
- Conclusions: For dynamic data with frequent exchanges and strict scalability and performance requirements, controllers or processors should manage contracts joined by subjects accepting usage conditions.This coarse-grained model registers subjects’ acceptance of all or part of the data usage conditions.
- Future scalability work: Sharding is being investigated as a scalability solution by assigning subsets of controllers and processors to separate chains that periodically synchronize with a public chain.The proposal also considers privately managed chains that supervisory authorities can observe.
- Future platform work: Hyperledger is planned for investigation because it offers a different consensus algorithm and a scalability and performance goal of thousands of transactions per second.The paper identifies it as a business-oriented blockchain platform supported by a large industry consortium.
- Future automation and evaluation: The current contract-generation process uses manual translation, while future work will investigate automatic model-based translation from policies.The authors also plan to evaluate scalability and performance as the blockchain accumulates contracts and events.