Kaspa 的托卡塔硬分叉：契约、ZK 操作码和新的 6 月目标

卡斯帕即将推出的 Toccata 硬分叉将为网络添加两条新的可编程路径：原生 L1 契约编程和基于零知识的编程（zk应用基础设施，主网激活时间现已定于 2026 年 6 月 5 日至 20 日，比原定的 5 月 5 日目标时间推迟。

迈克尔·萨顿 卡斯帕 核心优势 出版了 详细更新 本文将介绍此次硬分叉的具体内容、日期变更的原因以及未来几个月的发展趋势。此次分叉最初由 Ori Newman 发起，旨在将契约机制引入 Kaspa 的脚本引擎，部分原因是为了应对…… OP_CAT 讨论 比特币 最初是圆圈。后来它发展成了一个规模大得多的东西。

什么是托卡塔硬叉？

Toccata 是 Kaspa 网络的一次计划内硬分叉，它将新功能直接引入到底层。对于不太熟悉硬分叉的人来说，它指的是不向下兼容的协议升级。所有节点都必须升级才能继续参与网络。

此次升级的名称延续了Kaspa一贯的风格，即以音乐典故来命名重大升级产品。它的名字来源于古典音乐形式——托卡塔，这种乐曲旨在展现键盘乐器演奏者的精湛技艺。

从总体上看，托卡塔在卡斯帕的基础上增加了两点：

• 原生 L1 契约编程 通过名为 Silverscript 的新编译器。
• 基于 zk 应用基础设施建立在这些相同的契约基础之上

这些系统不能互换。它们服务于不同的使用场景，面向不同的开发者群体。

什么是盟约？为什么盟约对卡斯帕很重要？

契约是对交易输出中资金未来使用方式的限制。在标准的比特币或 Kaspa 交易中，一旦代币发送出去，接收者就可以随意处置。契约通过将支出规则直接嵌入交易脚本来改变这一点。

Kaspa 使用类似比特币的 UTXO 模型，其中每笔交易都会消耗现有输出并创建新输出。UTXO 系统中的契约机制允许开发者构建极其复杂的、有状态的多合约流程，即使底层计算仍然局限于每个 UTXO 内部。

为了让契约开发更加便捷，Kaspa Core 正在最终完善 Silverscript，这是一个由 Ori Newman、Michael Sutton、IzioDev 和 Manyfest 共同发起的编译器。Silverscript 旨在让开发者能够更轻松、更安全地直接在 Kaspa L1 上编写和部署复杂的契约，而无需深入到原始脚本引擎层面。

什么是基于零知识的应用？

ZK 代表零知识证明，这是一种密码学方法，允许一方在不泄露底层数据的情况下证明某事属实。ZK 证明在区块链扩容中应用日益广泛，因为它能够以低成本且安全的方式在链上验证链下计算结果。

在此上下文中，“基于”指的是零知识管理系统完全遵循 L1 排序规则。基于零知识管理系统的应用程序无法独立添加或删除事务。它与 Kaspa 自身的事务顺序紧密关联，因此无需单独的排序器即可保证其可靠性。

Toccata引入了几个组件来支持这一点：

• ZK验证操作码包括一个灵活的 Groth16 验证器和一个 RISC Zero STARK 验证器
• 排序承诺访问操作码使基于应用程序能够将自身锚定到 L1 排序
• KIP-21一种分区排序承诺架构，确保零知识应用程序的证明成本与其自身活动量成正比，而不是与整体 DAG 活动量成正比。

RISC Zero STARK 验证器已在测试网 12 上实现并激活。是否在主网上激活仍在决定中。

为什么证明成本很重要

任何零知识应用要想实用，其生成证明的成本必须与应用本身的工作量保持成比例。如果零知识应用需要证明其工作量与整个有向无环图 (DAG) 上的所有活动相关，那么成本将变得不可预测且难以管理。KIP-21 通过划分顺序承诺来解决这一问题，从而保持每个应用的工作负载独立。

目前已有哪些措施到位？

此次硬分叉的大部分内容已经实现。以下功能已构建完成：

• 扩展脚本引擎操作码支持，核心契约骨干，KIP-17
• 根据 KIP-20，血缘管理的契约 ID 作为共识和引擎功能
• 由 Alexander Safstrom 编写的，基于 KIP-16 的带有 zk-verifier 预编译子系统的 ZK 操作码
• 排序承诺访问操作码
• KIP-21 由 Sutton 编写，Maxim Biryukov 实施，已全面实施，目前正在等待审核。

Maxim 还完成了概念验证里程碑，包括内联零知识契约和基于 KAS 规范桥的零知识契约，这些里程碑对最终分支的设计起到了重要作用。

为什么硬分叉日期改到了六月？

原主网目标上线日期为 2026 年 5 月 5 日。此后，上线日期调整为 2026 年 6 月 5 日至 20 日。

原因在于架构层面。一旦零知识电路和运行时绑定到顺序承诺哈希结构，事后任何结构性更改都会变成破坏性更改。设计出错后再进行修补，其破坏性远大于现在多花些时间。

KIP-21 的设计已考虑到未来与 vprogs（Kaspa 的长期路线图，旨在实现同步可组合可验证程序）最终所需的承诺机制的兼容性。在主网上线前锁定正确的结构可以避免后续代价高昂的迁移。

功能冻结预计将于 2026 年 4 月 15 日进行。

功能冻结和主网上线之间会发生什么？

在 4 月 15 日功能冻结之后，Kaspa Core 计划对专用测试网 TN12 进行一次干净的重启，届时将包含所有最终功能。这并非模拟硬分叉过渡，而是一个用于测试最终版完整功能集的全新网络。

接下来，团队会将长期待定分支中积累的数月工作成果合并回主代码库。这个过程包括最终审核、解决未决问题、完善硬分叉激活逻辑以及处理数据库升级问题。

一旦这项工作完成，将在长期测试网 TN10 上进行一次硬分叉测试，以模拟完整的主网过渡过程。只有在这次演练运行成功并获得团队认可后，主网上线日期才会最终确定。

节点运营商应期待什么

对于矿工和节点运营商而言，此次升级旨在简化流程。节点需要更新，现有功能应继续正常运行。预计磁盘空间需求将增加约 20% 至 50%。预计不会对基础设施造成重大影响。

Toccata 为 Kaspa 带来的实际效果

Toccata 为 Kaspa 的基础层添加了两个可用的可编程系统：通过 Silverscript 实现的本地 L1 契约脚本，以及通过 KIP-16、KIP-20 和 KIP-21 实现的基于 zk 的应用基础设施。大部分技术工作已经完成。剩下的工作包括最终确定接口、将待合并的分支合并到主分支，以及在主网上线日期确定之前在 TN10 上进行一次完整的演练。

之所以选择 2026 年 6 月 5 日至 20 日这个时间窗口，是因为团队选择一次性把排序承诺架构做好，而不是在实际运行环境下再去修复。对于节点运维人员来说，此次升级设计得非常简单，除了磁盘空间略微增加之外，不会进行其他重大的基础设施变更。

相关资源

1. Kaspa on X：帖子（2026年4月）

2. 迈克尔·萨顿的博客文章：Kaspa Covenants++“Toccata”硬分叉展望