OP_STARK_VERIFY - 比特币脚本中的原生 STARK 证明验证

  • XPTY
  • 发布于 2025-10-25 16:53
  • 阅读 5

该提案建议在 Tapscript 中添加一个操作码 OP_STARK_VERIFY，用于在比特币链上原生验证 STARK 证明，旨在实现零知识证明的链上验证，并提供后量子安全性。该提案概述了动机、威胁模型、边界/定价方法和初始操作码语义，用于支持有效性汇总、后量子签名和隐私保护交易等应用。

原文：https://delvingbitcoin.org/t/proposal-op-stark-verify-native-stark-proof-verification-in-bitcoin-script/2056

作者：Abdel

译者：Kurt Pan

本提案提议在 Tapscript 中添加一个操作码 OP_STARK_VERIFY ，用于验证有限大小的 STARK 证明。目标是实现零知识证明的链上验证，并基于透明且后量子安全的假设，而无需诉诸临时脚本编码（例如 OP_CAT）或大量使用算术操作码。我们概述了动机、威胁模型、边界/定价方法、初始操作码语义以及一些未解决的问题。欢迎就范围、参数边界、定价、替代方案和挑战提出反馈。

显然，该提案远未完善，且已经提出了多项重大挑战，其中最主要的挑战是关于选择特定类型的 STARK 协议的可信中立性。

主要目标是衡量在某个时候将原生 ZK 验证（即 OP_STARK_VERIFY、OP_GROTH16_VERIFY）纳入比特币的兴趣。这也是一个有趣的思想实验，可以开始思考这意味着什么挑战。

引言

人们越来越关注在比特币中实现零知识证明，以支持诸如有效性汇总、后量子签名和隐私保护交易等应用。当前的方法，例如具有零知识验证的 BitVM 式乐观欺诈证明，依赖于链下计算和链上挑战机制，从而引入了诸如延迟最终确定性、资金锁定和额外信任假设等复杂性。

本提案提出了一个原生操作码 OP_STARK_VERIFY，用于直接验证比特币脚本中的 STARK（可扩展透明知识论证）证明 。其旨在提供高效的链上验证，避免间接验证方法的弊端。

该提案重点关注 Stone 中实现的原生 STARK，因为其已被广泛理解、广泛应用并具备形式化特性。较新的变体，例如 Circle STARK（用于后续的 Stwo 证明器），在速度和整体效率方面有显著提升，但成熟度和理解度较低。选择 Stone 是基于其久经考验的特性、形式化验证以及易于集成到 Bitcoin Core 的优势。即使形式化零知识性质并非始终存在，有效性证明也通常被称为 ZK。

注意：我在提案中多次提到零知识验证/零知识证明，但有时应该称之为有效性证明，因为零知识（ZK）概念的正确性取决于证明者和验证者的实现方式。有效性证明通常被称为ZK。

动机

STARK 提供后量子时代安全透明的证明，其验证复杂度为多项式对数级，证明大小相对于计算规模呈亚线性增长。验证复杂度与计算规模呈对数级增长，从而可以设定一个足以满足所有用例的上限（即至少支持递归证明验证），从而在比特币的权重单位系统中实现静态定价（即在最坏情况下定价）。

集成 Stone 验证器将添加一个操作码，该操作码从堆栈中读取序列化并压缩的 STARK 证明，如果证明验证成功则验证成功，否则验证失败。未压缩的证明大小通常在数百 KB 到 1 MB 之间，但压缩（例如 bzip2）在许多情况下可以将其压缩到 100 KB 以下。在标准硬件上，链上验证时间约为数十毫秒，具体取决于证明参数。

潜在的用例包括可以帮助比特币作为货币改进的应用：用于扩展比特币 L1 的有效性汇总可以根据链上状态承诺验证状态转换。后量子签名聚合可以用一个简洁的正确性证明来代替大量的 PQ 签名。隐私功能，如掩藏交易，可以通过提供 ZK 资金证明来花费 UTXO。

还有一些其他的应用：Cashu 的证明或储备/负债方案可以使用 STARK 证明来证明铸币的行为正确，或者用户证明铸币存在作弊行为，避免使用部分储备，将大部分比特币放在链上，并在铸币者作弊时对其进行惩罚。帐户抽象可以在 L2 上启用各种身份验证方式（即 Oauth、Face ID、Nostr 等）。通过使用 ZK-TLS 提供通过 Wise、Revolut、Venmo 等进行的转账证明，实现 BTC 和法定货币之间的 P2P 交换。

一些限制和挑战包括与基于配对的 SNARK 相比证明尺寸较大，增加了交易权重并可能增加费用。确立一个特定的证明系统（原始 STARK），如果出现更好的系统，这可能会限制灵活性。共识改变需要软分叉，存在实现错误或不可预见的交互的风险。验证不是常数时间的；虽然有界，但它会随着计算的大小而变化。将特定的 STARK 变体纳入其中可能会引发人们对可信中立性的担忧。需要仔细考虑定价和资源使用，以避免 DoS 攻击。

替代方案和设计空间

脚本中基于 OP_CAT的验证器对于 Circle STARKs 来说可行且已得到证明，但效率极低且复杂，将复杂性推入脚本。

算术操作码（例如 M31 域操作）用于"构建"验证器的方案中，一组较小的精心挑选的操作可以使脚本内验证器易于处理和可重用，但仍然包含特定的算术模型并需要更大的操作码表面。

本机验证器操作码（本提案）仅包含一种具有严格界限的验证算法。最简洁的运行时和策略，但需要选择并确定具体的证明系统和证明格式。

图片

方法 效率（运行时间/字节） 复杂性（审查表面） 灵活性 协议确立 注释
基于OP_CAT的验证器 低 高（长脚本、工具） 高 低 已验证可用于Circle STARKs；不适合生产环境。
算术操作码（例如M31） 中-高 中 中 中 编码算术；仍需要在Script中构建验证器。
原生OP_STARK_VERIFY 高 低-中（一个界限明确的操作码） 低-中 高 单一、固定的验证器，边界清晰；最简单的运行时路径。

建议的高级语义（v0）

探索性实现可以将 Stone 验证器（一种用 C++ 实现的单变量 STARK 验证器，由 Starkware 在生产中使用，具有最少的依赖性）集成到 Bitcoin Core 中。

操作码 OP_STARK_VERIFY（仅限 Tapscript）的堆栈输入（从顶部）为：proof（字节字符串，有限长度，Stone 格式的证明（带版本标签））和 verifier_id（2 个字节，选择固定的验证器参数集，例如 0x0001 = Stone v1，固定）。

成功条件是 Node 在 proof 上运行与 verifier_id 对应的 Stone 验证器。如果验证者接受证明有效，则操作码成功。

共识界限（针对 DoS 安全）要求 len(proof) ≤ PROOF_MAX_BYTES（具体值讨论如下）。证明必须在固定的、紧密限定的集合内声明参数。

见证/阶段中交易摘要没有任何变化；操作码不会访问超出正常脚本评估的额外 tx 字段（保持与 sighash 机制正交）。支出的绑定 留给脚本作者 （例如，在创建 UTXO 时，要求对包含对锁定脚本中的证明的承诺的消息进行 Schnorr 签名）。

定价和界限

证明大小界限 ：操作码强制执行严格的 PROOF_MAX_BYTES。正在讨论的初始目标是大约 100 KB，由实际可靠性参数下的典型 CPU-AIR 证明决定；确切的常数必须由基准测试和安全分析支持。（悬而未决的问题：压缩是否应被视为传输层和非共识，在共识中添加像 bzip2 这样的特定解压缩器可能是不可取的。）

运行时绑定 ：修复验证器参数集（verifier_id）以确保运行时是证明大小和声明参数的可预测函数。

策略 （内存池/矿工）：进一步的保守限制（例如，每个输入最多 1 个 OP_STARK_VERIFY；更严格的大小上限；不允许在裸脚本中使用）可以与共识分开，并根据测量进行迭代。

开放性问题 ：是否应该像 sigops 那样为零知识验证添加一个明确的"成本单位"，还是纯粹依赖于字节绑定 + 参数固定。欢迎提出意见。

风险和缺点

确立证明系统：将一种验证算法/格式固定到共识中。缓解措施包括设置较小的 verifier_id 命名空间，以便在需要时允许添加额外的固定集。

复杂性和审计层面：验证器并非简单的 C++ 代码；我们需要一个清晰的、规范优先的定义，以及一个与精确提交和编译器设置绑定的、最小的、可审计的实现。Stone 已经通过了形式化验证，这很有帮助。它已在生产环境中大规模使用多年，并经过多方审计。

DoS 和最坏情况行为：必须保守地限制证明参数和大小；政策可以更严格。

可信中立：避免偏向某一特定协议。这似乎是将零知识证明直接应用于比特币的最大挑战。最好坚持使用易于理解、通用且有文档的原生 STARK 协议（与原始 STARK 论文非常接近）和参数集，而不是任何特定于应用程序的语义。

参考

点赞 0
收藏 0
分享
本文参与登链社区写作激励计划 ，好文好收益，欢迎正在阅读的你也加入。

0 条评论

请先 登录 后评论
XPTY
XPTY
江湖只有他的大名，没有他的介绍。

XPTY

如果觉得我的文章对您有用，请随意打赏。你的支持将鼓励我继续创作！