Kaspa的KCC协调论坛敲定三项代币与约束标准

KCC-1、KCC-2与KCC-20进入最终状态

对在Kaspa上构建的开发者来说,生态长期缺少一份统一的约束规范,各项目此前只能各自协商数据格式。这种局面在本周被打破:10月21日,KCC协调论坛正式宣布KCC-1、KCC-2和KCC-20三项标准进入最终状态,论坛将这一状态定义为可在整个生态内全面采用。公告由论坛的官方账号发布,并邀请开发者加入公开频道,就实现细节和支持问题展开讨论。kaspanet组织下的标准库目前将三份文档全部列为最终状态,并标注各自定位:KCC-1是约束规范,KCC-2是授权规范,KCC-20则是面向同质化代币约束的应用标准。由Romain Billot、Michael Sutton和Ori Newman撰写的KCC-1定义了约束的通用术语、数据布局和应用二进制接口,也就是软件如何编码信息、调用程序函数以及标识交易之间传递的状态。规范列出了需要就这些细节达成一致的工具类别,包括编译器、钱包、索引器和交易构建器,同时允许开发者自由选择任何编程语言、编译器或框架。共享接口覆盖程序入口点、状态模板以及涉及多个输入的交易规则。没有绑定约束的程序也可以遵循KCC-1,但规范明确指出,这类程序不会获得KIP-20提供的谱系与授权保障。由Billot和Sutton撰写的KCC-2规定程序如何识别授权方,以及确认其批准所需的最低校验。规范为五种授权方案分配了标准标识符:覆盖Schnorr和ECDSA签名的公钥方案,以及允许脚本或延续中的约束谱系充当授权方的方案。以公钥哈希授权为例,交易必须披露对应的公钥,将其哈希与存储的授权值比对,并提供有效签名。自定义方案无需等待标准化即可采用,前提是其定义说明了格式、含义和审批校验。

由Sivan Helfer、Sutton、Newman和Billot完成的KCC-20建立在前两份文档之上,定义代币数量、所有权和转账接口。该标准面向同质化代币,而非NFT。每一条代币约束都必须公布程序信息,供软件解码状态并构造转账;配置还需披露所支持的所有权方案,以及代币输入与输出的限制。一项名为借用接收的功能允许发送方把接收方已有的兼容代币输出用作目的地:交易重建该输出并增加代币数量,保留其所有权和状态,但不能降低其中的KAS金额。安全章节提醒,替换输出会改变其交易引用,使花费先前引用的未确认交易失效。Argent的参考实现随附生成的SilverScript合约和Rust一致性测试。在管控流程的KCC-0之下,最终状态附带硬性要求:进入征询期之前,一份标准轨道约定需要人类可读与机器可读的测试向量、至少一个通过机器可读检查的公开实现,以及针对威胁、信任假设和重放问题的安全考量。依赖项对其他KCC而言必须是最终状态,对KIP而言则须处于活跃状态,状态变更通过拉取请求推进。该标准库把这类共享约定与共识或核心节点行为的改动分开,后者归属Kaspa改进提案。此外,进入最终状态并不要求生态内每个参与者实现该约定,实质性修改通常需要提出替代性的KCC。此前,网络上的应用开发依赖分散的基础设施。Gate在4月宣布集成Kasplex二层网络,支持通过该EVM兼容网络进行KAS存取。Kasplex将其描述为一种轻量级rollup,把EVM字节码嵌入Kaspa交易并在链下执行,同时提供双向跨链桥,桥接后的KAS充当二层的燃料代币。

标准的边界在哪里

这次标准化把过去逐项目协调格式的做法,变成了对照规范实现:钱包或索引器团队只需针对KCC-1的接口和KCC-2的授权标识符构建一次,而不必再与每个代币项目单独对齐约定。KCC-0的测试向量规则为这些团队提供了客观的达标线,Argent实现连同其Rust检查已经是可以直接参照的现成基准。我们实时监测的数据显示,KAS现货价格在过去24小时内上涨5.3%,市场正在消化这一消息与正常资金流。变化后仍然保留的边界是管辖范围:三份文档均不涉及共识或核心节点行为,绑定约束之外的程序得不到KIP-20保障,生态内的采纳也保持自愿。