SecLog 精读：让「数据已交付」自己留下证据

一句话：想让「用户无法否认收到数据」成立，不用信任 API，也不用把数据放上链——只要让解密数据的最后一半钥匙，只可能从一条会留下记录的路径里出来。

这篇论文只有四页。它讲的事情也小：一次数据查询交付之后，怎么保证链上一定留下一条记录。小到你第一反应是「记个日志而已」，可跟着作者走完，会发现每一步都卡在同一个问题上——谁值得信任。

读完我最想记住的是一句话：区块链保证「写上去的改不掉」，可这里缺的是「该写的那一条一定会被写」。两句话很像，方向正好相反：一个管已经发生的，一个管还没发生的。

论文是 Hughes、Hossain、Tang、Jung、Chenli 五个人写的，发在 METAVERSE 2025（LNCS 16159，pp. 115–124）。四页，结构却很清楚：先说问题，再把前人工作分成两堆，然后给模型、协议和两条定理，最后用三个合约量 gas、老老实实谈代价。下面我就按这个顺序走。

一、签完那份同意书，后面的事你就不知道了

假设你的病历在一家医院的库里。某天有人查了它——为了研究也好，为了别的什么也好，你分不清。

签字那一下你是知道的。之后呢？论文第一节把话说得很直：数据所有者对这个流程的了解，往往止步于最初签下共享协议的那一刻。此后的访问记录、访问时间、数据被拿去做了什么，全都与他无关。这不是体验问题。HIPAA、GDPR、CCPA 要的都是可追溯，而不透明的共享本身就踩在这三条线的红线上。

去中心化数据库（论文点了 recallnet 那份去中心化数据库清单）把所有权和控制权还给了数据所有者，算是解决了前半截。可所有权一回来，后半截露出来一个洞：没人负责记账。

这时候你会发现，「让谁记一下」这件事比想象中难。论文把三条看起来都能用的路都堵了：让用户自己确认收到？想赖账的人根本不会确认。让 API 单方面写日志？网络一抖，用户是真的没收到，那条日志就成了假的，顺便 API 还成了单点故障。那直接把共享行为写进区块链呢——论文自己的原话是，这样做保证不了日志的正确性和完整性。

堵完这三条，作者转身去了另一个领域：公平交换。那里早就在用 HTLC 这类原子交换，把「拿到数据访问权」和「付款」绑成一次要么全有、要么全无的操作。

SecLog 的全部巧思就在这一步：把付款换成记录，原子性照样成立。因为在这个场景里，用户本来就不为取数付钱给 API；真正需要绑在一起的，是「拿到数据」和「有件事被触发」。

论文列了四条贡献，说得挺克制：一个能在去中心化环境下强制「共享成功即留痕」的协议、一份安全性证明、一组显示比付款型原子交换更省 gas 的仿真、以及开源代码（github.com/avocado-avery/SecLog）。

二、两条研究线各解决了一半，缺口留在中间

论文的第二部分把前人工作分成两堆，正好对应下面这张图的两列——有意思的是，两堆各自都做得很扎实，却都漏了同一个角落。

先说区块链日志这一堆。Gao 用同态加密保护链上审计日志，保密性上去了，代价是把用户排除在「验证自己有没有被记上」之外。Cha 的 IoT 审计系统依赖可信基础设施。Zhao 和 López-Pimentel 把 Merkle 树的哈希和根记到链上，防篡改没问题，但明细留在链下，链下那份靠不靠得住只能靠假设。Hsu 把区块链和访问控制拼在 IoT 存储里，Cha 与 Hasan 用可信执行环境护住云日志。AuditChain、BlockAuditor、LogChain 更彻底一些，可是论文的评语一点没客气：它们仍然假设基础设施里的参与者是诚实的，也不处理漏记——也就是事件被悄悄排除、没人能发现。

作者用一句话总结了这堆工作的共同缺口：缺少一种机制，让用户能独立确认「我这次操作确实被记下了」。而 SecLog 想做的，是把验证直接塞进记账这个动作里，做到「可验证的包含关系」，并且不依赖某个可信的记账者、存储节点或任何单一参与者。

另一堆是公平交换。FairSwap、OptiSwap、Universal Atomic Swaps 用合约和密码学原语把原子性做得很干净，Zhu 和 Tas 又把它推到私钥交换与零知识证明。它们的问题不在质量，在适用范围：都是为一次性交换设计的，一笔币换一份文件。用论文的判断说，这些模型承载不了持续、可审计的事件流——「每次查询都记一笔」这种需求，它们没打算管。

两条线之外，还站着一个底座系统，SecLog 就挂在它身上：Web3DB，一个能跑 SQL 的去中心化关系库，分四层——数据注入、访问控制、数据库引擎、存储（底层用 IPFS）。

一次查询是这样走的：用户把请求发给 SQL API；API 先找访问控制层，校验凭证、按 ACL 把查询重写一遍；再转给数据库引擎层，由一个随机选出的 master 节点协调其他 slave 去执行；结果回到 API，API 再回给用户。

注意最后那一跳。论文在这里点出了一颗要松的螺丝：这套流程底下压着一个假设——用户是诚实的，不会否认自己收到了结果。这话在院内局域网里勉强能站住，放到公网上就不成立了。

三、作者把话说得很克制：三类实体、两条定义、三个假设

第三部分先把范围划小：只考虑三类角色——用户（发查询、等结果）、API（收请求、汇结果、回用户）、区块链节点（校验交易、执行合约）。节点作恶明确排除在外，因为那属于共识机制的研究范围，跟本文无关。

接着只定义两条性质，一句话一条：

• 正确性：链上任何一条共享记录，对应的共享确实完成了——API 发了结果，用户收到了数据。
• 完整性：任何一次成功的数据获取，链上都有对应记录。

这两句就是全文的靶子。撑住它们的是三个假设，读的时候值得慢一点，因为后面两条定理的分量全在这里：

一是底层区块链安全、且不会被定向审查：没有 51% 这类攻击，节点不串通去卡掉某笔交易（用户的部署、API 的调用），所以活性有保证——只要用户在 API 的调用被确认之后能连上一次网，就终将拿到数据。二是查询结果加密传输，否则数据要么对链上所有节点可见，要么查询方可以翻脸不认。三是 API 只会崩、不会骗：只考虑崩溃故障，拜占庭故障不考虑；恶意数据提供方也不在范围内，数据正确性交给 Fair²Trade 那条线。

四、协议只有四步，关键是一个点

设计部分其实很短。跟着图看就是四步：

API 拿到结果后，用自己的密钥 sk 加密，再把 sk 随机拆成两半，sk = sk1 + sk2。这两步都在链下，一分钱 gas 都不花。

然后它把 sk1 和密文一起发给用户。到这一刻，sk1 只有 API 和用户知道。

接下来是整篇论文最妙的一小步。用户拿 sk1 算出一个条件值，再以这个条件去部署合约。论文用 ElGamal 举例：公钥是 pk = g^sk，于是

1cond = pk / g^sk1 = g^sk / g^sk1 = g^(sk − sk1) = g^sk2

这个 cond 就是一个承诺点：谁能给出 sk2，谁就证明自己握着另一半钥匙。合约是 HTLC 的变体，只有当 ecMul(sk2, G) == cond 时才触发「收到回执」这个事件；给不出来，事件不触发，合约到期作废。

最后一步：API 看到合约，先校验 cond 是不是它该给的那个点。是，就拿 sk2 调合约，触发记账；不是，就干脆不理这份合约。

输入验证这一步不是新东西，作者明说沿用了 Fair²Trade 的实现——本文的贡献在「强制记账」，不在验证原语，篇幅所限就没展开，请读者去看原来那篇。

合约本身 4.2 KB，读的时候有个坑值得先讲：字段叫 sk1x / sk1y，装的其实是 g^sk2 这个承诺点，不是 sk1。

1// contracts/SecLog.sol：sklockMatches 这个修饰器就是整篇论文的原子性
2(sk2x, sk2y) = EllipticCurve.ecMul(sk2, GX, GY, AA, PP);      // sk2 * G
3require(logs[_logId].sk1x == sk2x, "sk2 does not match");     // 与用户预置的点比对
4require(logs[_logId].sk1y == sk2y, "sk2 does not match");

1// contracts/SecLog.sol：只有 receiver（API）能触发，一次为限
2require(log.receiver == msg.sender, "Only receiver can verify");
3require(keccak256(_message) == log.messageHash, "Message hash mismatch");
4log.verified = true;
5emit LogVerified(_logId);

整篇论文的骨架，其实就落在两个事件上：

LogEntryNew 在用户部署时发出，记下 logId、双方地址、承诺点、消息哈希和时间锁——它证明的是意图。LogVerified 在 API 调通时发出，只有点匹配、哈希匹配才会发生——它证明的是事实，顺便把 sk2 永久写进 calldata。

五、两条定理，每条的证明只有一段

安全分析写得极省：每条定理配一段证明。

定理一，正确性：只要用户在 API 的响应被区块链确认之后至少能访问一次链，协议就保证正确性。证明的思路也直白：用户网络正常时，API 一给出正确的 sk2，他就能恢复 sk。麻烦的只是断网那一小会儿——但按前面的假设，链是活的，所以只要用户连上来一次、收到一次更新，sk2 就到手了。

定理二，完整性：只要 API 向用户部署的合法合约提供了合法输入，协议就保证完整性。证明同理：按 HTLC 的原子属性，正确输入被提供时，链上节点会验证并执行记账事件，记录必然上链。

两条都成立，也都很短。我读第二遍时才反应过来短在哪里：它们做的事情，是把模型已经给出的东西命名清楚。真正的工作量不在证明里，在第一节那三个假设里——活性、加密、API 不撒谎。

所以我不太愿意把这篇论文说成「消灭了信任」。它更像是把信任挪了个位置：从信任一个 API，变成信任一整条链。这个区别很重要，因为它决定了账单最后由谁付。

六、三个合约、一张图，以及我重跑出来的分歧

评估部分的设置很朴素：以太坊智能合约，Truffle 加本地 Ganache，Solidity 0.5.0，gas 直接从 Ganache 日志和 Truffle 控制台里捞。比三个合约。

SecLog.sol 是本文方案。Fair2Trade.sol 是付款型原子交换的基准：在 Fair²Trade 里，数据买方建 HTLC，数据中间方（broker）交出数据访问权来换押金。第三个 CIDLog.sol 是作者自造的天真基准——不加密结果，把结果往 IPFS 一存，拿结果的 CID 当 sk 去做 HTLC 交换。

结论是 SecLog 比 Fair²Trade 省约 8,000 gas。原因不复杂：Fair²Trade 在 broker 交出合法 sk2 之后要真的发起一笔押金转账，而 SecLog 只触发一个「收到合法输入」的事件。差额又小于一次 ETH 转账的 21,000 gas，因为 SecLog 多出来的确认动作自己也要花钱。CIDLog 的 gas 与 SecLog 一模一样——CID 和 sk 都是 32 字节，验证成本相同；但 CIDLog 的用户得等原子交换做完才能下载数据，还凭空多出一个 IPFS 实体，验证起来更麻烦。

我把同一份字节码搬到一个本地 EVM 上重跑（solc 0.5.17，py-evm 的 Istanbul 与 London 两个分叉）。结果一半对上，一半对不上：

对上的那一半挺漂亮：Fair2Trade − SecLog 在 London 上是 8,038 gas，在 Istanbul 上是 8,026。论文正文说 8,000，作者仓库里的图表数据是 8,166（696,991 减 688,825），误差 1.6%。

对不上的那一半有点扎眼：论文 Fig.2 报 688,825 gas，同一份字节码在我这儿是 186,415，差 3.7 倍。我第一反应是 EVM 分叉——Berlin 前后的 modexp 计价差很多，而这条曲线的库正是靠 modexp 做模逆。可惜 Istanbul 上也只有 179,327，仍然差得远，这个解释站不住。

所以我更愿意把这件事说成一个提醒，而不是一次打脸：短文的数字是 Truffle 加 Ganache 采的，栈不一样；这类论文的 gas 绝对值不能跨文比较，能带走的只有差额和量级。

论文还留了一个能自己算的锚：按 Etherscan 的 gas tracker（2025-07-26），一次执行约 0.75 美元。用同一个 gas 价折算，我复现的 186,415 gas 约 0.20 美元，而用户的部署费（1,164,022 gas）约 1.27 美元。

七、讨论那一节，作者比正文更诚实

§4.2 是我最愿意推荐的一节。它列了三类新增成本，没有粉饰。

第一是网络负担：用户必须和链交互才能收到 API 的输入，这对网络质量提出了额外要求；而且同步频率取决于底层链——比特币出块约 10 分钟，以太坊约 12 秒。第二是链的维护成本：论文把活性当成假设，但维护一条链的钱没算进协议账里，具体选哪条链由实现决定，成本跟着变。第三是链下开销：加解密和密钥拆分。论文给的数量级是，AES 加密 1 MB 载荷不到 10 毫秒，密钥拆分 1 毫秒以内——和链上开销比，基本可以忽略。

把这三条和第六节的 gas 放到同一把尺子上，画面就有点刺：

一句话总结：密码学比起共识几乎免费。这条协议的钱不花在椭圆曲线上，花在「等一个块」和「付一笔 gas」上。所以「比付款型交换省 8,000 gas」是对的，只是它只是链上账单里的一小格；真正的账，是一次交换要先付 116 万 gas 的部署费。

把范围再画成一个矩阵，边界就更清楚了：前两行是设计真堵住的，后三行是论文明确不管、或者直接当假设的。

八、所有数字，连同来源

九、三件你可以自己动手的事，和两个我不想装作知道的问题

三条命令，都只用公开数据，不用跑链：

 1# 1. 原子性到底落在哪一行
 2curl -s https://raw.githubusercontent.com/avocado-avery/SecLog/main/contracts/SecLog.sol \
 3  | grep -n "ecMul\|keccak256(_message)\|emit LogVerified"
 4
 5# 2. 查询内容是不是明文上链：看 verifyLog 的参数
 6curl -s https://raw.githubusercontent.com/avocado-avery/SecLog/main/contracts/SecLog.sol \
 7  | grep -n "function verifyLog" -A 3
 8
 9# 3. 成本换算：从「688,825 gas 约 0.75 美元」反推隐含 gas 价，再看我的数字
10python3 -c "p=0.75/688825; print(round(p*1e9,3),'gwei-equivalent'); print('186,415 gas ->', round(186415*p,2), 'USD')"

第二条最值得动手。verifyLog(logId, sk2, message) 里的 message 必须是明文，不然 keccak256(_message) 对不上 messageHash。换句话说，这套设计默认查询内容会跟着记录一起公开。想同时要隐私，就得把 messageHash 换成承诺（比如哈希的哈希），可那样合约就校验不了内容了。这是个二选一，论文没有选。

最后留两个问题，我答不上来。

一个是付账的人到底是谁。论文只比较了「验证」这一步。把一次交换的总账算完：用户先掏 116 万 gas 部署，API 再掏 18.6 万 gas 验证；而最朴素的「API 记一条日志」只需要一次 SSTORE 加一个事件。那 8,000 gas 买来的是「不信任 API」。问题在于，这份不信任在多少场景里值 100 万 gas？论文没有回答。

另一个是能不能聚合。每个查询一笔交易，一万次查询就是一万笔。作者另一条 Fair²Trade 的线用 epoch 加 Merkle 根来摊销（他们 repo 里的 Chart.ipynb 就在算这个），SecLog 这篇没做。把一个椭圆曲线承诺换成一棵 Merkle 树，原子性还在吗？

第二个问题，我觉得就是这篇论文最明显的下一站。

参考

• Hughes, A., Hossain, S., Tang, W., Jung, T., Chenli, C.: SecLog: Atomic-Swap Based Secure Logging for Decentralized Data Sharing. METAVERSE 2025, LNCS 16159, pp. 115–124, Springer, 2026. doi:10.1007/978-3-032-06323-6_9
• 代码：github.com/avocado-avery/SecLog（SecLog.sol、CIDLog.sol、FT.sol、EllipticCurve.sol）
• Chenli, C., Tang, W., Lee, H., Jung, T.: Fair²Trade: Digital Trading Platform Ensuring Exchange and Distribution Fairness. IEEE TDSC 21(5), 4827–4842, 2024.
• Mukherjee, S. S., et al.: Web3DB: Web 3.0 RDBMS for Individual Data Ownership. arXiv:2504.02713
• Dziembowski, S., Eckey, L., Faust, S.: FairSwap: How to Fairly Exchange Digital Goods. CCS 2018.
• Eckey, L., Faust, S., Schlosser, B.: OptiSwap: Fast Optimistic Fair Exchange. ASIA CCS 2020.
• Thyagarajan, S. A. K., Malavolta, G., Moreno-Sanchez, P.: Universal Atomic Swaps. IEEE S&P 2022.
• Tas, E. N., et al.: Atomic and Fair Data Exchange via Blockchain. CCS 2024.
• Zhu, Z., Zhang, R., Tao, Y.: Atomic Cross-Chain Swap Based on Private Key Exchange. Cybersecurity 7(1), 2024.
• Vishnia, G., Peters, G. W.: AuditChain: A Trading Audit Platform over Blockchain. Frontiers in Blockchain 3, 2020.
• Pourmajidi, W., Miranskyy, A.: LogChain: Blockchain-Assisted Log Storage. arXiv:1805.08868.
• Tang, W., Chenli, C., Ju, C., Jung, T.: Trac2Chain: Trackability and Traceability of Graph Data in Blockchain with Linkage Privacy. ACM/SIGAPP SAC 2022.
• Zhao, W., et al.: A Blockchain-Facilitated Secure Sensing Data Processing and Logging System. IEEE Access 11, 2023.
• Lopez-Pimentel, J. C., Morales-Rosales, L. A., Monroy, R.: RootLogChain: Registering Log-Events in a Blockchain for Audit Issues. Sensors 21(22), 7669, 2021.
• Ethereum 文档：一笔 ETH 转账的 21,000 gas 基准，ethereum.org/en/developers/docs/gas
• 资助：NASA ULI（80NSSC23M0058）与 NSF（OAC-2312973），论文致谢原文。

• Previous
  Go 为什么成了 Agent 时代的默认语言
• Next
  思维先于行动：JevAct 给 LLM Agent 加的决策门