Page 449 - 《软件学报》2025年第4期

陶静怡 等: 基于区块链和去中心化可问责属性认证的众包方案 1855

表 2 基于区块链的众包方案比较

方案 任务保护 工作者筛选 匿名性 可链接性 可追踪性
ZebraLancer [21] × × √ √ ×
Ghaffaripour等人 [38] × × × × ×
CrowdBC [39] × √ × × ×
Feng等人 [40] × √ √ × ×
Tan等人 [4] √ √ × × ×
SecBCS [20] √ √ √ × √
本文方案 √ √ √ √ √

5.2 实验仿真
本节通过在 macOS Monterey 12.5, CPU 为 Apple M1 Pro 的 PC 机上对本方案进行仿真实验, 使用 gnark 0.7.1 [41]
来实现 zk-SNARKs, 运行在 Hyperledger Fabric 网络环境下. 表 3 列出了本方案各阶段理论上的计算开销与实际开
|C| 表示任务加密涉及的属
39.011 ms, 符合实际的使用要求.
销. 为了便于分析, 忽略序列化反序列化、智能合约调用和网络传输等方面的影响, 令
t
性个数, |S | 表示任务解密时实际用到的属性个数, 和 n 为门限秘密分享算法的阈值和总数, E 表示群 G 上指数运
H 表示哈希运算
算耗时, P 表示双线性配对运算耗时, N 表示整数域上的指数运算, E T 表示群 G T 上的指数运算,
耗时. 实验模拟了 t = 2,n = 3,|C| = 1,|S | = 1 时的场景. 由于系统初始化时要使用 ZK.Setup 算法, 因此耗时较长, 但
由于只需要在初始化时执行一次, 因此是可以接受的. 此外, 生成匿名认证的过程也耗时较长, 但可以由工作者链
下执行. 其他步骤的时间开销均为毫秒级, 可以满足实际应用场景的需求.

表 3 方案的时间开销

算法 理论时间开销 实际时间开销 (ms)
GlobalSetup P+ZK.Setup 435 687.188
UserSetup H 0.782
AASetup 成员 : 2n(t −2)N + E + E T 智能合约 : t(E + E T ) 成员: 1.725, 智能合约: 1.466
TracerSetup 追踪者 : n(t −2)N + E 智能合约 : tE 追踪者: 0.106, 智能合约: 0.205
KeyGen 成员 : 4E + H 申请用户 : 2tE 成员: 0.262, 申请用户: 0.834
Encrypt E T +|C|(2E T +4E) 4.196
Decrypt |S |(3P+ E T )+ H 1.991
Auth 2E +2H +ZK.Prove 14 115.249
Verify ZK.Verify 1.947
Trace 追踪者 : E 智能合约 : tE 追踪者: 0.080, 智能合约: 0.138

图 2 显示了在属性权威机构和追踪机构的初始化阶段, 当 n = 30 , 门限值 从 t 10 逐渐增加到 20 时合约计算时
t
间的仿真结果和其拟合曲线. 合约计算 PK, TPK 的时间和 成正比, 与理论结果相符.
图 3 显示了不同属性数量下, 分别使用全与和全或策略时加解密的运行时间, 可以看到加密的时间开销与访
问控制策略中的属性个数呈线性关系, 且与逻辑控制符比或要复杂. 而解密的时间开销与实际使用的属性个数也
呈线性关系, 符合理论结果. 加解密的运算均在链下执行, 在涉及属性数量为 32 的情况下, 全与加密所用时间为
53.206 ms, 而解密为
为提高众包系统的性能, 智能合约的运算开销与链上的存储开销应尽可能小. 本方案在链上不存储工作结果
的密文, 而是存储两个哈希值和密钥 S 2 , 节省了存储开销. 匿名认证的生成在链下进行, 而验证则由智能合约执行,
同时链上要存储匿名认证, 因此 zk-SNARKs 证明的大小和验证效率对系统的性能影响很大.
通过实验将本方案的匿名认证大小、验证认证时间与生成认证时间和 ZebraLancer [21] 方案进行了比较, 使用
了 EdDSA 数字签名算法 [42] 来实现 ZebraLancer 方案中的证书. 由于 zk-SNARKs 的证明大小为 O(1) , 本方案的匿
名认证大小为 687 B, 几乎不受属性数量和策略的影响, 而 ZebraLancer [21] 为 559 B. 图 4 和图 5 显示了 ZebraLancer