# A Privacy-Preserving Record Linkage Method Based on Secret Sharing and Blockchain
## 4 Methods
### System Architecture  
To implement the SSB-PPRL method, we propose a system architecture integrating blockchain and IPFS. The architecture comprises five components, participants, computational nodes, verification nodes, blockchain, and IPFS, with multiple smart contracts collaboratively managing data distribution, computation, and verification processes [19]. The specific roles in the system are defined as follows:  
Participants: Data owners who encode quasi-identifiers into Bloom filters, decompose them into shares using Boolean secret sharing and upload them to IPFS. They only access their own data CIDs and the final results. Computational Nodes: Off-chain entities that retrieve secret shares and masks from IPFS perform local similarity computations and are restricted to accessing assigned data. Verification Nodes: On-chain supervisors that audit computation results, update node reputation scores and access output results without interacting with raw data. Role assignments and data access control are implemented through smart contracts deployed on the blockchain. These contracts define role identities (participants, computational nodes, verification nodes), assign data access permissions, and enforce strict access control logic to ensure sensitive data is only accessed within authorized scopes. The data access control mechanism is designed as follows:  
Permission Definition and Negotiation: After participants upload data to IPFS and generate CIDs, they negotiate access permissions with the system through an on-chain mechanism. Metadata associated with each CID is stored in the blockchain's \"data record mapping\" in the form of a data structure, including the CID (pointing to Bloom filter shares on IPFS), the data owner's address, an access permission list (specifying authorized roles or addresses), and an expiration time (defining the validity period of the permission). For example, a participant may propose authorizing a specific computational node to access a particular CID. The system verifies this based on predefined rules (e.g., reputation thresholds) and updates the access permission list upon confirmation. Access Verification and Time Window: The smart contract provides an access permission verification function. Callers must pass two checks: the current time must be less than or equal to the expiration time, and the caller's address must be included in the access permission list. Only upon passing these checks can the caller retrieve the CID from the data record mapping and download the data from IPFS. Expired permissions automatically become invalid, preventing unauthorized long-term access. Dynamic Management and Security: Data owners can revoke or modify permissions at any time. Change requests are validated by the contract for consistency before updating state variables (e.g., the access permission list). To prevent inference attacks, CID distribution is strictly controlled by the contract, ensuring that unauthorized roles cannot directly query the data record mapping. The time window design, combined with on-chain verification, ensures data access remains controllable within the authorized period, enhancing security. Collaborative Support: The access control contract shares role mappings and reputation information with the computational node selection contract, synchronizes permission states (e.g., expiration) with the audit and verification contract, and provides CIDs and permission rules to the data distribution contract, ensuring compliance in computation and verification processes. Sensitive data is stored on IPFS, with only metadata recorded on the blockchain, making permission negotiation and verification fully transparent and auditable. The overall system architecture is illustrated in Figure 1.  
The system operates in stages: Participants preprocess data, encode it into Bloom filters, split it into secret shares, and upload them to IPFS, generating CIDs. The role and data access control smart contracts negotiate permissions, logging CIDs and permissions on the blockchain.