Kaspa KCC协调论坛最终确定三项标准：建立应用开发者共享规范

Kaspa的KCC协调论坛（KCC Coordination Forum）已正式敲定三项涵盖契约接口、授权机制以及同质化代币标准的规范，为在该网络上构建应用程序的开发者确立了共享的技术规格。

核心摘要

• KCC-1 定义了钱包、编译器、索引器及其他处理契约工具所需的共享接口。
• KCC-2 规定了五种标准授权方案，包括公钥、脚本及契约标识符。
• KCC-20 设定了代币转移规则，并支持通过现有的兼容输出接收代币。

这些标准的最终确立旨在建立生态系统内的惯例，而无需修改共识规则或要求所有参与者强制采用。KCC协调论坛在10月21日的公告中表示，KCC-1、KCC-2和KCC-20现已成为正式标准（Final），可供整个生态系统全面采用。论坛邀请开发者加入其公共频道，以提出问题、讨论实现细节并获得技术支持。

问候 $KAS。KCC-1、KCC-2 和 KCC-20 现已成为正式标准，意味着它们已准备好在整个生态系统中全面采用。
我们邀请 Kaspa 的构建者加入公共 KCC 频道，以提问、获取支持、讨论实现方案并分享您的成果。
与我们一同构建。

标准文档详情与分类

Kaspa官方标准仓库将上述三份文件均标记为“最终版”。其索引明确指出：
- KCC-1 为契约规范；
- KCC-2 为授权规范；
- KCC-20 为同质化代币契约的应用标准。

仓库文档强调，KCC被视为独立实现的共享惯例。其文档明确将这些惯例与共识变更或核心节点行为的改变区分开来，后者属于Kaspa改进提案（KIP）的范畴。

KCC-1：契约接口的标准化

KCC-1 定义了通用的术语、数据布局以及用于契约的应用程序二进制接口（ABI）。该规范详细说明了软件如何编码信息、调用程序函数，以及如何识别交易间传递的状态。

该文档的作者 Romain Billot、Michael Sutton 和 Ori Newman 指出，编译器、钱包、索引器和交易构建器等工具需要在这些细节上达成一致。文档强调，独立实现不仅需要产生能通过共识检查的脚本，还需要超越此层面的通用格式。

KCC-1 允许开发者自由选择编程语言、编译器和框架。其共享接口涵盖了程序入口点、状态模板以及处理涉及多输入交易时的规则。在同一份文档中，作者区分了基本接口规则与依赖于契约标识符的功能。没有绑定契约的程序可以遵循 KCC-1，但规范指出，这类程序无法获得由 KIP-20 提供的谱系和授权保证。

KCC-2：明确操作授权主体

由 Billot 和 Sutton 撰写的 KCC-2 规范了程序如何识别权威机构以及建立批准所需的最小检查要求。权威机构可以是公钥、对密钥的承诺、脚本或持续的契约谱系。

该规范为五种授权方案分配了标准标识符。其公钥选项涵盖 Schnorr 和 ECDSA 签名，而其他选项则允许脚本或契约谱系作为权威机构参与。对于公钥哈希授权，KCC-2 要求交易必须揭示相应的公钥，将其哈希值与存储的权威值进行匹配，并提供有效签名。更高级别的规范则定义签名的消息内容及其他附加条件。

授权注册表为标准方案和自定义方案保留了独立的范围。KCC-2 允许参与者在等待标准化的同时采用自定义方案，前提是其定义需明确指定格式、含义及审批检查流程。在其契约标识符方案下，批准需要来自已识别契约谱系的输入。KCC-2 指出，更高级别的惯例可对该输入的程序和状态施加进一步的检查。

KCC-20：设定代币转移与接收规则

KCC-20 建立在前三两项标准之上，定义了代币数量、所有权及转移接口。该文档的作者包括 Sivan Helfer、Sutton、Newman 和 Billot。

规范要求每个代币契约发布程序信息，供软件解码状态并构造转移。配置必须披露支持的所有权方案以及代币输入和输出的限制。

其中一项名为“借用接收”（borrowed receive）的功能，允许发送方使用接收方现有的兼容代币输出作为目的地。KCC-20 规定，交易将重建该输出以增加代币数量，保留其所有权和扩展状态，且不能减少其 KAS 价值。

安全部分警告称，替换输出会改变其交易引用，从而使花费先前引用的未确认交易失效。根据文档，钱包必须在花费之前发现该替换输出。该标准将 Argent 参考实现、生成的 SilverScript 合约以及 Rust 合规性测试联系起来。

最终状态的实施要求

管理标准流程的文件 KCC-0 规定，除了完成最终审查期外，还有更多要求。它指出，标准轨道上的惯例需要具备人类可读和机器可读的测试向量，以及至少一个通过机器可读检查的公开实现。

根据相同规则，其他 KCC 的依赖项必须处于“最终版”状态，而 KIP 的依赖项必须处于“活跃”状态。KCC-0 指出，状态变更通过拉取请求发生，且仓库索引必须随之更新。

KCC-0 描述机器可读的测试向量为自动化测试的权威形式，当其与人类可读示例一起提供时。其提交规则要求，在进入最后呼叫阶段之前，安全性考量必须解决威胁、信任假设以及潜在的重放问题。

该治理文件声明，最终化并不要求生态系统中的每个参与者都实施某项惯例。实质性更改通常需要替代性的新 KCC，而修正和澄清则遵循文件的修订规则。

生态系统背景与应用开发

Kaspa 的应用开发此前曾包含单独的 Layer 2 基础设施。Gate 于四月宣布集成 Kasplex Layer 2，通过兼容 EVM 的网络实现 KAS 的存入和提取。

在此前的集成公告中，Gate 表示客户可以将 KAS 从基础网络转移到 Kasplex 钱包。Kasplex 的项目资料描述了一种双向桥接机制，并表示熟悉以太坊工具的开发者可以通过更改远程过程调用（RPC）端点来部署合约。

Kasplex 将其设计描述为一种轻量级 Rollup，它将 EVM 字节码置于 Kaspa 交易中并在链下执行。其文档指出，Kaspa 提供交易排序和数据可用性，而桥接的 KAS 则充当 Layer 2 的气体代币。