Hawk：从零理解隐私智能合约——论文阅读笔记

论文：Hawk: The Blockchain Model of Cryptography and Privacy-Preserving Smart Contracts
作者：Ahmed Kosba、Andrew Miller、Elaine Shi、Zikai Wen、Charalampos Papamanthou
发表：IEEE Symposium on Security and Privacy（S&P），2016
关键词：隐私智能合约、Commitment、Zerocash、NIZK、zk-SNARK、UC Security、算术电路

1. 为什么需要 Hawk？

区块链上的智能合约有一个天然矛盾：合约需要公开可验证，但业务输入往往不希望公开。

以密封竞价拍卖（sealed-bid auction）为例：Alice 出价 10，Bob 出价 20。我们希望合约正确判断赢家、分配资金，但不希望所有链上观察者在投标时就看到每个人的报价。普通的链上程序容易实现”人人可复核”，却很难直接实现”秘密输入”。

Hawk 的思路不是让区块链秘密地执行所有计算，而是把私有计算移到链下，让链上验证关于计算正确性的零知识证明。由此，区块链依然负责资金状态与公开规则，秘密输入则尽量不暴露给链上观察者。

Hawk 系统分工：用户、链下 Manager、区块链与私有 Coin 结算

需要先明确一个边界：Hawk 并没有消除所有信任。 在其主要方案中，Manager 在 Compute 阶段会得到用户秘密，因此用户仍需信任 Manager 不在事后泄露这些信息；但不需要信任 Manager 会诚实计算结果，因为计算正确性由证明约束。

2. 阅读前需要建立的基础概念

2.1 公开可验证，不等于所有数据都公开

区块链擅长维护公开、不可随意篡改的状态，并让参与者检查交易是否合法。但”验证一笔交易合法”并不必然要求”看到交易的所有秘密数据”。Hawk 正是围绕这个区分展开设计。

2.2 Commitment：先把秘密锁定，之后再打开

密码学承诺（commitment）可以写作：

cm=\operatorname{Comm}_s(m)

其中 $m$ 是消息， $s$ 是随机数， $cm$ 是公开承诺。它具有两个重要性质：

Hiding（隐藏性）：观察承诺的人难以获知 $m$ 。
Binding（绑定性）：承诺生成后，提交者不能随意将它解释为另一个消息。

可以把承诺理解为一个”先封存答案、后揭晓”的密码学信封。它与普通加密不同：承诺主要用于固定一个秘密值，而不是让接收者解密消息。

2.3 私有 Coin、Serial Number 和 Merkle Tree

Hawk 的私有资金机制借鉴 Zerocash 的思想。一枚私有 Coin 可以包含对金额的承诺，例如：

coin=\operatorname{Comm}_s(\$val)

链上维护 Coin 集合；Merkle Tree 使用户能够证明某枚 Coin 属于集合，而不必直接暴露它是哪一枚。花费 Coin 时还需要提供 Serial Number（序列号），由链上记录已花费序列号，从而阻止双重花费。

这里有三个不同问题：

机制主要解决的问题

Commitment 金额隐藏、事后不能任意更改 Merkle 成员证明证明输入 Coin 确实存在于合法集合 Serial Number 防止同一枚 Coin 被重复花费

特别注意：证明某枚 Coin 存在，不等于证明自己有权花费它。 还需要通过秘密密钥、序列号生成关系等约束来证明花费授权。

2.4 NIZK：只证明”我做对了”，不公开”我是怎么做的”

非交互式零知识证明（Non-Interactive Zero-Knowledge Proof，NIZK）可以抽象为：

\pi=\operatorname{Prove}(L,x,w),\qquad \operatorname{Verify}(L,x,\pi)\in\{0,1\}

$L$ ：需要满足的关系（例如金额守恒、承诺一致）；
$x$ ：公开声明（statement）；
$w$ ：秘密见证（witness），例如金额、随机数、密钥；
$\pi$ ：证明。

三项基本性质是 Completeness（完备性）、Soundness（可靠性）、Zero-Knowledge（零知识性）。直观地说：诚实证明应当通过、错误声明难以通过、证明不应额外泄露秘密。

3. Hawk 的核心：Freeze → Compute → Finalize

这条流程是全文最重要的主线。它把”锁定秘密输入""链下计算""链上结算”分成不同阶段。

Hawk 三阶段协议时序：Freeze、Compute 与 Finalize

3.1 Freeze：先锁钱，也锁定秘密输入

用户首先选择要冻结的私有 Coin，并为合约生成承诺：

cm_i=\operatorname{Comm}_{s'_i}(\$val_i\parallel in_i\parallel k_i)

其中 $\$ val_i $是金额，$ in_i $是私有业务输入，$ k_i$ 是后续用于加密结算结果的对称密钥。

L_FREEZE 的证明关系要求：输入 Coin 确实存在、用户有权花费、序列号正确，以及新承诺中的金额与输入 Coin 金额一致。

理解重点：Freeze 不只是把资金存进合约；它还把后续要使用的私有输入固定下来，防止用户看到别人的行为后随意改口。

3.2 Compute：向 Manager 提交秘密，但不能换一套输入

用户把之前承诺的秘密加密给 Manager：

ct_i=\operatorname{ENC}(PM.epk,r_i, (\$val_i\parallel in_i\parallel k_i\parallel s'_i))

这里最容易忽略的是 L_COMPUTE：它不只是证明”密文可以被解密”，而是证明密文中的秘密和 Freeze 时承诺的秘密是同一套数据。

换言之，承诺的绑定性只能说明”承诺本身不能被改写”，却不能自动保证”另一个密文一定加密了该承诺中的内容”。这两个对象之间的一致性关系仍需要 NIZK 证明。

3.3 Finalize：Manager 计算，区块链验证

Manager 收集秘密输入，执行私有合约：

(\{\$val'_i\},out)= \phi_{\mathrm{priv}}(\{\$val_i,in_i\},in_M)

这里 $in_M$ 是 Manager 提供的额外公开输入，例如某个结算时点的市场价格；它与用户的秘密输入 $in_i$ 不同。

Manager 还需证明一系列约束，例如：

\sum_i\$val_i=\sum_i\$val'_i

coin'_i=\operatorname{Comm}_{s''_i}(\$val'_i)

并保证发给用户的加密结算信息与新 Coin 的金额相一致。链上验证 L_FINALIZE 的证明，再调用公开合约中的 $\phi_{\mathrm{pub}}.check(in_M,out)$ 。

因此，区块链验证的是”计算符合给定输入和规则”，而不需要重新看到秘密输入、执行整段私有计算。 但如果 $in_M$ 代表外部价格，证明并不能自动保证价格来源真实；是否检查价格可信，仍取决于公开合约的规则和外部数据机制。

3.4 一个重要区分：正确性不等于一定完成

即使 Manager 无法伪造错误的 Finalize 证明，它仍可能拒绝提交结果（abort）。零知识证明约束的是”提交的结果是否正确”，并不能强迫一个人按时发送消息。

论文在 IV-C 讨论了超时退款：当超过 $T_3>T_2$ ，用户可以重新构造私有 Coin，并证明新 Coin 金额等于被冻结的金额。由于退款可以公开指出对应的冻结记录，不需要像匿名 Pour 那样证明自己属于整个冻结资金池中的某个隐藏位置。

这说明 Hawk 必须同时考虑资金安全、隐私、正确性和中止后的公平性，不能只看 NIZK 是否可靠。

4. 理想功能与 UC 安全：为什么还要有”另一个世界”？

初读时，UC（Universal Composability，通用可组合性）可能是全文最抽象的部分。我现在更愿意把它理解为一种通过对照实验定义协议安全性的方法。

4.1 理想功能：把安全目标写成规则

想象有一个绝对按规则行事的拍卖裁判：用户直接向它提交秘密报价，它只在规则允许的时候公开结果，且不会凭空多发钱。这个抽象裁判就是 Ideal Functionality（理想功能）。

Hawk 第三章用 IdealP_cash 和 IdealP_hawk 等形式化对象描述理想情况下资金和合约应该怎样运作。理想功能不是实际部署的服务器，也不意味着所有操作都一定成功；它只保证按照被定义的规则执行。

4.2 环境、攻击者和模拟器分别做什么？

UC 安全对照：环境、真实攻击者、模拟器与两个世界的执行视图

环境 $\mathcal Z$ ：安全测试者，选择输入、与参与者和攻击者交互，并试图区分两个世界。
攻击者 $\mathcal A$ ：在真实世界中控制恶意参与者、发送恶意消息。
模拟器 $\mathcal S$ ：在理想世界中模拟真实攻击者的行为与可见信息。

UC 安全直观上要求：对于任意真实攻击者，都能构造相应模拟器，使任何有效率的环境都难以区分真实与理想执行：

\forall\mathcal A\;\exists\mathcal S\;\forall\mathcal Z:\quad \operatorname{Real}_{\mathcal A,\mathcal Z} \approx_c \operatorname{Ideal}_{\mathcal S,\mathcal Z}

例如，若真实 Hawk 在 Freeze 阶段泄露了 Alice 的秘密报价，但理想功能不允许泄露，环境就可能利用该秘密区分两个世界。此时模拟器不能凭空知道诚实 Alice 的报价，也就无法掩盖这类额外泄露。

4.3 为什么模拟器要提取 Witness？

假设恶意 Bob 提交了一个有效的 Freeze 证明。真实区块链只需验证证明就能接受操作；但理想功能可能需要知道 Bob 实际冻结的金额和输入，才能维护对应状态。

模拟器通常只看到公开声明与证明，所以需要从恶意方的有效证明中提取秘密见证，把对应输入提交给理想功能。这里的提取是安全证明中的理论能力，不意味着普通链上验证者能从零知识证明中恢复秘密。

这也引出第五章的技术难点：普通 SNARK 的知识提取器可能是 non-black-box 的，需要了解恶意算法的内部结构；而 UC 模拟器必须应对任意环境，不能直接依赖环境的内部代码。Hawk 因此采用 SNARK-lifting 转换，构造满足所需模拟可提取性质的证明系统。

5. NIZK、SNARK 与算术电路：三者并不在同一层

这是我读第五章后最重要的一次概念整理：

概念我现在的理解

L_FREEZE / L_COMPUTE / L_FINALIZE 定义”什么样的输入和结果才合法”

算术电路（Arithmetic Circuit）将合法性检查转换成加法、乘法等可证明的数学约束

NIZK 规定”不泄露 Witness 也能证明关系成立”的证明接口与安全目标

zk-SNARK 一类证明简短、验证高效的零知识证明技术，可用于实现 NIZK

SNARK-lifting 在 SNARK 基础上补足 Hawk 的 UC 证明所需的更强性质

一个极简电路可以是：证明自己知道秘密 $a$ ，使得公开的 $y=25$ 满足 $a\cdot a=y$ 。真实的 Hawk 电路则复杂得多：既包含 $\phi_{\mathrm{priv}}$ 的业务逻辑，也包含 Commitment、加密和金额守恒等密码学约束。

Hawk 编译与证明流程：业务电路、密码学约束、链下证明与链上验证

5.1 为什么作者这么在意电路大小？

因为在论文采用的 SNARK 实现中，证明生成的主要成本与电路的乘法门数量密切相关。同样的哈希、加密功能，如果能用更少的乘法门实现，证明成本就可能显著降低。

作者因此采用 SNARK-friendly 的密码学原语，并对最昂贵的 Finalize 电路做了两项优化：

Finalize 使用普通 SNARK：在该安全证明中，模拟器需要的信息此前已获得或提取，因此不需要在 Finalize 阶段提取新的 Witness；Freeze 和 Compute 仍使用更强的 NIZK。
Finalize 尽量使用对称加密：用户在 Freeze 时承诺密钥 $k_i$ ，Compute 时将其加密给 Manager，Finalize 用 $k_i$ 加密结算信息，避免在大型证明电路中反复执行昂贵的公钥加密。

这解释了第四章 Figure 6 中 $k_i$ 的设计：它并不是无关紧要的附加字段，而是协议正确性和实现效率之间的衔接点。

6. 第六章：从协议描述到真正可运行的系统

第六章展示了 Hawk 编译器和实验。它让前面抽象的 NIZK.Prove 不再只是一个接口。

6.1 编译器做了什么？

作者将 Hawk 程序拆成两部分：

公开合约：使用当时以太坊生态中的 Serpent 语言表示链上逻辑。
私有合约：用 C 语言子集描述，经过 Pinocchio 相关编译工具转换为算术电路。

之后，Hawk 的电路扩充工具自动补上 Commitment、Encryption、Balance Check 等约束，最后交给 libsnark 生成和验证证明。论文中的实现还需要为当时的 Ethereum 虚拟机增加 SNARK 验证操作支持，因此不能把它直接等同于”无需修改即可部署在今天任意 EVM 链上”。

6.2 论文实际实现了哪些应用？

除了密封竞价拍卖，论文还实现了众筹（Crowdfunding）、石头剪刀布（Rock—Paper—Scissors）、金融互换（Swap）等示例，用来说明相同的协议框架可以支持不同的私有合约逻辑。

6.3 性能结果应该怎样读？

论文的实验是在当时的 Amazon EC2 环境中进行的，属于 2016 年实现的历史基准，不应直接视为今天硬件或现代 zk 系统的性能。

从论文的表格与图中，我重点记录了以下结论：

用户侧操作：Pour、Freeze、Compute 的证明时间在实验配置下均少于一分钟，而且基本不随合约参与人数增加而增长。
Manager 侧 Finalize：开销随参与人数增长；对于 100 名参与者的拍卖或众筹，论文报告单核证明时间低于约 6.5 分钟、四核低于约 2.85 分钟。
链上验证：验证时间远小于证明生成时间，这是把复杂计算放到链下的核心收益。
优化效果：用户侧 SNARK-friendly 实现使电路规模相比朴素实现减少约 2.0—2.6 倍；结合第五章的优化，拍卖 Finalize 电路相对直接实现可获得约 10 倍的规模改进。

这里必须区分三个指标：电路大小、生成证明时间、验证证明时间。电路缩小通常有助于证明效率，但不能把”电路缩小 10 倍”直接理解成”所有运行时间都缩短 10 倍”。

7. Hawk 的安全边界与局限

读完论文后，我觉得理解它的贡献，必须同时看清它没有解决什么。

第一，Manager 仍然可能泄露秘密。 主要协议保证输入在 Compute 之前不被公开，并通过证明约束结果正确；但 Manager 在 Compute 后获知秘密，后验隐私（posterior privacy）仍依赖其不泄露信息。论文讨论了使用 SGX 或 MPC 分担这一信任，但这并不意味着基本方案已经实现完全去信任。

第二，正确性不等于活性（liveness）。 Manager 即使不能提交错误结果，也可能中止执行。超时退款与押金惩罚能够缓解资金风险，却不能保证业务结果一定按时产生。

第三，证明正确不等于外部数据真实。 对 $in_M$ 这样的公开外部输入，NIZK 只能证明”按照该输入执行了规则”。数据是否可信，需要公开合约或其他可信数据机制额外验证。

第四，密码学证明并非没有工程代价。 论文中的电路依赖合约结构，SNARK 参数生成、证明密钥规模、Manager 的计算时间都构成部署成本；不同安全级别和参与人数也会影响开销。

第五，隐私有不同层次。 隐藏金额、隐藏业务输入、隐藏资金来源与去向、隐藏接收者长期身份，不是同一个安全目标。例如论文 IV-C 指出，基础 Pour 形式化会暴露接收者假名，完整的接收者匿名性需要进一步扩展。

8. 我的理解与收获

这篇论文让我建立起了一个比较完整的知识链条：

\text{隐私业务需求} \longrightarrow \text{理想功能定义} \longrightarrow \text{Freeze/Compute/Finalize 协议} \longrightarrow \text{NIZK 关系} \longrightarrow \text{算术电路与 SNARK 实现} \longrightarrow \text{UC 安全证明与性能评估}

其中，我认为最值得记住的有三点。

（1）隐私和正确性是两个不同的安全目标。 Commitment、加密主要帮助隐藏和绑定数据；NIZK 则让不掌握秘密的验证者也能检查关系成立。单独依赖其中一种工具，无法直接得到完整的隐私智能合约。

（2）“证明一个结果正确”与”证明一个协议安全”不是一回事。 SNARK 可以证明某次计算满足电路约束；UC 安全则进一步追问，在任意恶意交互和组合环境下，真实协议是否仍然只表现出理想功能允许的行为。

（3）密码学协议与系统实现必须一起考虑。 Figure 6 中的密钥 $k_i$ 、Figure 7 中的电路扩充，以及第五章对 Finalize 的优化，体现了安全目标、协议结构和工程成本之间的联系。

从今天的视角看，Hawk 更像是一篇奠定问题框架与设计思路的论文：它清楚地提出，隐私智能合约不必让区块链亲自执行秘密计算，而可以借助密码学证明，把私有执行与公开验证结合起来。后续研究可以继续围绕减少可信 Manager、降低证明成本、改进隐私与公平性等方向展开。

参考资料

Kosba, A., Miller, A., Shi, E., Wen, Z., & Papamanthou, C. Hawk: The Blockchain Model of Cryptography and Privacy-Preserving Smart Contracts. IEEE Symposium on Security and Privacy, 2016.
论文中的 Figure 5（私有货币机制）、Figure 6（Hawk 协议与证明关系）、Figure 7（编译器结构）、Tables I—II / Figures 8—9（性能数据）值得对照原文阅读。

写作说明：本文是基于原论文整理的个人学习笔记。为便于理解，部分拍卖例子和流程图进行了简化；涉及严格的安全定义、证明关系及性能指标时，应以论文原文及其完整技术版本为准。

✳ 记录于 cidernwork

#区块链 #隐私智能合约 #零知识证明 #SNARK #论文阅读