简介面向区块链开发者与高校科研场景的区块链安全数据共享系统设计源码项目整合了IPFS去中心化存储、Ethereum智能合约与基于属性加密ABE的访问控制适合做毕业设计、课程设计或高安全数据共享产品原型参考。包体约64.99MB共2000个文件以C/C源代码、头文件、目标文件及测试文件为主并包含Python脚本、Makefile构建脚本、配置文件和属性基加密工具链整体目录结构完整便于按存储、合约、加密等模块拆解研读。已有331人下载学习在相关技术栈中具备一定参考热度。通过阅读源码可掌握IPFS数据上传与检索、Ethereum交易与智能合约部署、ABE属性策略定义与密钥生成的关键编码实现并借助配套构建与测试文件快速调试运行为后续二次开发安全数据共享系统提供可复用的基础代码和排错思路。1. 把 IPFS 当隐私存储用是数据共享项目里最大的坑做数据共享系统时我踩过最大的坑是把 IPFS 当成“隐私存储链”。文件一旦通过ipfs add发布CID 就是全网公开的任何拿到 CID 的人都能从网关拉取原始数据Ethereum 上的数据又被所有节点复制无法隐藏。标题里的“基于 IPFS、Ethereum 与 ABE 的区块链安全数据共享系统”核心思路是把“存”“管”“控”三层拆开IPFS 只保存密文Ethereum 只登记 CID 存证和策略哈希真正做细粒度访问控制的是 ABEAttribute-Based Encryption。它解决的是“存储公开、权限不能公开”的矛盾适合医疗病历交换、政务协同这类既要跨机构共享、又要能审计授权记录的业务。下面我按自己搭这类系统的顺序讲先立住三者的角色边界再给一套最小可运行源码最后落到参数、坑和产品化技巧。2. ABE、IPFS 与 Ethereum 的角色边界为什么密文进 IPFS、策略哈希进链2.1 数据面、密钥面与控制面的职责分离没有任何单一技术能同时满足去中心化存储、不可篡改审计和属性级访问控制。常见做法是把系统切成三个层面数据面用 IPFS只负责存储密文和内容寻址密钥面用 ABE决定谁能解开包裹数据密钥的密文控制面用 Ethereum 合约记录 CID 的哈希、策略哈希、所有者与状态。三者缺一不可没有 IPFSEthereum 存大量数据会贵得不可用没有 ABEIPFS 上的文件就是明文裸奔没有 EthereumIPFS 网络无法证明谁在何时注册过哪份数据。层面保存内容机密性假设对共享系统提供的保证数据面IPFSABE 密文、外层加密后的文件加密密钥不泄露密文不可读内容寻址、跨节点冗余、去重密钥面ABE包裹数据密钥的策略密文用户属性私钥不泄露策略外密文不可解按角色/属性做细粒度授权控制面EthereumCID 哈希、策略哈希、所有者地址链上数据完全公开不保存明文授权记录不可篡改时间可审计这条边界决定了代码怎么写不要直接把业务文件ipfs add而是先在本地把文件加密成密文再把密文传到 IPFS最后把密文的 CID 存证到链上。2.2 先用 CP-ABE 跑通一条策略最小加密雏形ABE 最常见的一族实现是 CP-ABECiphertext-Policy ABE加密者在策略里写下“属性门限”解密者的密钥被打上属性集。教学阶段可以用 Charm-Crypto 的CPabe_BSW07快速验证逻辑但这个库已不维护工程上建议后续用 OpenABE 或封装成独立密钥服务。下面这段代码是完整的策略加解密流程from charm.toolbox.pairinggroup import PairingGroup from charm.schemes.abenc.abenc_bsw07 import CPabe_BSW07 # SS512: 对称双线性群便于原型验证生产环境换 BN254 或更安全曲线 group PairingGroup(SS512) cpabe CPabe_BSW07(group) # 系统初始化公钥 pk 可公开主密钥 mk 只能交给可信密钥中心 (pk, mk) cpabe.setup() # 访问策略医生且属于 A 医院或者审计角色可读 policy ((doctor and hospital_a) or (admin and audit)) # keygen 给用户签发属性私钥这里只给用户 doctor 属性 sk cpabe.keygen(pk, mk, [doctor]) # 明文可以是随机 GT 元素实际系统中这个元素就是数据加密密钥 DEK msg group.random(group.GT()) ct cpabe.encrypt(pk, msg, policy) # 当前用户不满足策略解密会失败 try: cpabe.decrypt(pk, sk, ct) print(unexpected success) except Exception: print(expected deny: user has only doctor but not hospital_a/audit)这段代码说明三点一策略写在密文里不是写在密钥里所以文件发给谁都能分发能不能解由属性决定二keygen签发的属性集越少用户能解开的密文越少三ABE 只适合加密体积小、价值高的数据直接加密大文件会非常慢所以后面要把它和 AES 混合加密结合。真实系统里ABE 加密的是一个 256 位 AES 密钥AES 密钥再去加密文件。2.3 IPFS 节点只接收密文加参命令与 CID 版本选择IPFS 侧需要养成的习惯是“能交给 IPFS 的只有密文、CID、以及公开的元数据。” 本地初始化并上传密文的命令如下# 初始化时直接使用 server profile减少局域网发现和 mdns 干扰 ipfs init --profile server # 启动后台节点 ipfs daemon # 上传密文文件强制输出 CIDv1方便在浏览器和 HTTP 网关间迁移 ipfs add --cid-version 1 medical_record.bin--profile server会关闭不必要的服务发现适合跑在云服务器上--cid-version 1使 CID 可被ipfs://和常规 HTTP 网关直接识别也避免 v0 的Qm前缀本身携带额外格式假设。返回的 CID 是对密文内容的哈希寻址文件只要改一个字节CID 就完全变化这天然适合做完整性校验。下一步要做的就是把 CID 摘要和策略摘要写进智能合约。3. Ethereum 合约把 CID 与策略绑定不需要从 0 搭建区块链平台3.1 合约存储模型链上只存哈希完整 CID 走事件链上存的字段越少Gas 越低。CID 本身是一串文本存到 storage 会占据 32 字节的整数倍空间更好的做法是合约只保存keccak256(cid)摘要完整 CID 在DataRegistered事件中发出链下索引器从事件日志读取。策略同样只存哈希策略原文放在链下配置服务或 IPFS 中链上哈希用于对账和防篡改。下面最小合约可以完成注册、更新策略和查询存证// SPDX-License-Identifier: MIT pragma solidity ^0.8.20; contract SecureShare { struct Entry { bytes32 cidHash; bytes32 policyHash; address owner; bool revoked; uint256 createdAt; } mapping(bytes32 id Entry) private entries; event DataRegistered(bytes32 indexed id, string cid, bytes32 policyHash); event PolicyUpdated(bytes32 indexed id, bytes32 oldPolicyHash, bytes32 newPolicyHash); // id 是业务侧唯一编号例如 record-001cid_ 是完整 CID仅用于事件输出 function register( bytes32 id, string calldata cid_, bytes32 cidHash_, bytes32 policyHash_ ) external { require(entries[id].owner address(0), id exists); require(keccak256(bytes(cid_)) cidHash_, cid hash mismatch); entries[id] Entry(cidHash_, policyHash_, msg.sender, false, block.timestamp); emit DataRegistered(id, cid_, policyHash_); } // 只有 owner 可以更新策略哈希历史版本由事件日志保留便于审计 function updatePolicy(bytes32 id, bytes32 newPolicyHash) external { Entry storage e entries[id]; require(e.owner msg.sender, not owner); require(!e.revoked, entry revoked); emit PolicyUpdated(id, e.policyHash, newPolicyHash); e.policyHash newPolicyHash; } function get(bytes32 id) external view returns ( bytes32 cidHash, bytes32 policyHash, address owner, bool revoked, uint256 createdAt ) { Entry storage e entries[id]; require(e.owner ! address(0), not found); return (e.cidHash, e.policyHash, e.owner, e.revoked, e.createdAt); } }合约里register的三个参数相互校验cidHash_是调用者本地算出的摘要cid_是完整 CID 字符串keccak256(bytes(cid_)) cidHash_保证事件里看到的 CID 和链上摘要来自同一个文件。updatePolicy只允许 owner 改策略哈希旧哈希在PolicyUpdated事件中保留作为授权记录的历史版本。get是只读函数不消耗 Gas 但可以随时检查当前状态。3.2 本地部署和注册脚本一条命令跑通测试网这里不需要从 0 搭建一个区块链平台直接用 Hardhat 配置一条测试网即可。部署脚本:const { ethers } require(hardhat); async function main() { const SecureShare await ethers.getContractFactory(SecureShare); const share await SecureShare.deploy(); await share.waitForDeployment(); console.log(SecureShare deployed at, await share.getAddress()); } main().catch((e) { console.error(e); process.exit(1); });ethers.getContractFactory会根据编译产物自动获得合约 ABIwaitForDeployment()等待交易上链并得到合约地址。再写一个交互脚本用于注册数据const { ethers } require(hardhat); async function register() { const cid QmVersion1CidFromIpfsAdd; const policy ((doctor and hospital_a) or (admin and audit)); const cidHash ethers.keccak256(ethers.toUtf8Bytes(cid)); const policyHash ethers.keccak256(ethers.toUtf8Bytes(policy)); const recordId ethers.encodeBytes32String(record-001); const share await ethers.getContractAt(SecureShare, process.env.SHARE_ADDRESS); const tx await share.register(recordId, cid, cidHash, policyHash); await tx.wait(); const events await share.queryFilter(DataRegistered); const ev events[events.length - 1]; console.log(id:, ev.args[0]); console.log(cid:, ev.args[1]); console.log(policyHash:, ev.args[2]); } register().catch(console.error);这个脚本的坑点是ethers.getContractAt需要已经部署的地址建议通过环境变量注入而不是硬编码。脚本先算出 CID 与策略的摘要再调用合约事件里的cid是完整原始值而链上Entry只有摘要这样既把索引数据暴露给链下服务又压缩了合约的存储成本。3.3 为什么事件是记录的“真身”合约 storage 可以被updatePolicy覆盖但历史事件一旦上链就无法删除。换句话说链上Entry给出的是当前状态事件日志才是审计事实。把 CID 放事件还有个额外好处链下节点可以在监听事件的同时直接把密文 pin 到本地 IPFS形成“登记即拉取”的自动化流程。这个模式会在第 5 章展开。4. 参数表与高频坑ABE Ethereum IPFS 从能跑到能上线4.1 上线前必须定死的安全参数原型跑通后第一件事不是加功能而是把参数固定下来否则后续升级很痛苦。我一般会先定出下表后的参数再写密钥派生和 IPFS 固定代码。参数推荐值用途与注意点双线性群BN254 / BLS12-381生产级 CP-ABE 需要非对称群原型用 SS512 即可数据加密算法AES-256-GCMABE 明文是 DEKDEK 负责加密业务文件DEK 长度256 bit与 AES-256 对应必须使用密码学安全随机源链上 CID 存证keccak256(bytes(cid))链上只存 32 字节完整 CID 走事件策略原文存储版本化配置服务或加密 IPFS 文件链上只存 policyHashCID 版本1sha2-256兼容 HTTP 网关与后续跨链迁移这里一个容易混淆的点链上存的是keccak256(cid字符串)不是 IPFS 对文件内容的 CID 哈希。前者用于给链上记录做一个短摘要后者是文件定位符。两者要分开看待不要混用。4.2 策略明文与策略哈希的版本管理策略字符串本身可以公开因为它描述的是角色与属性。但策略更新时必须能证明“链上记录的是这份新策略”做法是在提交合约前用和链上一致的摘要算法计算并比对pip install web3from web3 import Web3 policy ((doctor and hospital_a) or (admin and audit)) policy_hash Web3.keccak(textpolicy).hex() print(policy_hash)输出结果应与合约事件中的policyHash完全一致。注意Web3.keccak(text...)会把字符串按 UTF-8 编码后再计算和合约端keccak256(bytes(policy))一致。策略文件建议用policy_v1.json这类带版本号的结构管理每次updatePolicy只上传新哈希不把全文放链上。4.3 三个必踩的坑与处置方式4.3.1 更新策略哈希不等于数据撤销ABE 的访问策略是在加密时固化进密文的。即使你更新了合约里的policyHash旧密文依然绑定旧策略持有旧属性私钥的用户依然能解密。要真正撤销过去权限只能对数据重新加密# 重新生成密文再上传 IPFS最后把新 CID 注册到合约 new_ct abe_encrypt(pk, dek, ((doctor and hospital_b) or (admin and audit))) new_cid ipfs_add(new_ct) contract.register(new_id, new_cid, compute_cid_hash(new_cid), policy_hash)这段逻辑说明撤销的粒度是“密文代”不是“用户”。属性撤销可以通过让密钥中心不再签发该属性来阻止新授权但对已发布的 ABE 密文无效。因此敏感数据建议把 DEK 的更新周期缩短并在业务上把加密文件分块每个块独立 ABE 加密使重加密的代价可控。4.3.2 把 CID 本身当作访问令牌IPFS 网关对 CID 访问没有权限控制。任何一次curl ipfs-gateway/ipfs/CID都能绕过你的前端。不要认为“没人知道 CID”就安全网关日志、CDN 缓存、跨机构共享都可能泄露。正确的层级是文件先由 AES-256-GCM 加密DEK 再由 ABE 加密IPFS 上永远只出现两层密文CID 泄露时攻击者拿到的也是密文。4.3.3 忽略链上元数据的关联性链上存证会留下时间、owner 地址、策略哈希更新节奏。攻击者不需要解密文件只分析注册时间和地址关联就能推断业务活动。如果项目有强匿名需求不要把record-001这类语义化 id 作为合约 id改用客户端生成的随机 bytes32。业务方通过事件日志里的关联表映射语义链上只保留随机标识符。5. 把链下事件变成数据通路产品化集成中的固定与缓存技巧5.1 用事件驱动自动 pin当数据注册量上来后靠人工ipfs pin add是不现实的。一般我会在 IPFS 节点旁跑一个事件监听进程发现DataRegistered事件后立刻把 CID 固定到本地节点避免请求者还没下载密文就因 GC 被清理。const { ethers } require(ethers); const provider new ethers.WebSocketProvider(process.env.RPC_WS_URL); const share new ethers.Contract(process.env.SHARE_ADDRESS, ABi, provider); share.on(share.filters.DataRegistered(), async (id, cid) { const url http://localhost:5001/api/v0/pin/add?arg${cid}; await fetch(url, { method: POST }); console.log(pinned, cid, for, id); });监听器必须做幂等处理事件可能因 WebSocket 重连被重复投递pin 重复执行不会报错但如果同时触发了重加密需要以 CID 为键做去重。更稳妥的做法是在数据库里记录(cid, blockNumber, logIndex)避免重复处理同一事件。5.2 用 DEK 缓存降低 ABE 重复解密开销CP-ABE 解密涉及双线性配对性能远慢于 AES。同一个文件被多个节点请求时如果每次都从 IPFS 下载 ABE 密文并重新解出 DEK节点很快会成为瓶颈。常见做法是把解出的 DEK 放进内存缓存只缓存当前策略版本的 DEK策略一更新立即失效from functools import lru_cache import ipfsapi lru_cache(maxsize128) def load_dek(attr_private_key, cid: str) - bytes: abe_ciphertext ipfsapi.connect().cat(cid) dek cpabe_decrypt(attr_private_key, abe_ciphertext) return dek这个函数的第一参数我没写进lru_cache因为对象不可哈希实际部署时建议用hashlib.sha256(serialize_attr_key).hexdigest()作缓存 key。缓存过期时间宜设置为 ABE 策略版本的平均变更周期并在updatePolicy事件里显式清理对应缓存。链下索引器同时维护cid - policyVersion的本地映射离线节点补拉数据时跳过已撤销密文这是把事件流变成数据通路的关键一步。本文还有配套的精品资源点击获取