经过与@missutton、@IzioDev、@saefstroem以及@someone235的几次迭代后，我起草了一份关于Kaspa上可互换代币协议的最小交互界面提案——https://gist.github.com/Manyfestation/be844fbe1e8c00ac990898e7a737bfec。

该界面提议了一个TokenDescription（代币描述），使工具能够识别、索引和转让协议代币，同时只需最小的共用形状即可，让每个代币自由扩展其自身的状态、逻辑和策略。

交互界面可分为三层：
1. 读者/索引器
  Kaspa节点之上的链下服务。它观察已接受的交易并维护实时代币状态。
2. 写入者/钱包
  钱包或交易构建器。它使用索引的代币状态，并根据用户意图创建有效的下一状态交易。
3. SDK/SilverScript/可组合性层
  面向开发者的后续层，用于可复用的协议模式、SilverScript集成和更高级的组合。

目前，重点应放在前两层：追踪代币和创建有效的转让。
诸如铸造、销毁、冻结和稳定币特定规则等事项固然重要，但我认为它们应位于基础代币接口之上，而非首个通用接口的一部分。

值得注意的是，KCC20代币旨在允许通过自定义状态和逻辑扩展基础接口，因此工具应能轻松验证已部署代币背后实际的高级SilverScript逻辑。

总体目标是达成一个在整个生态系统中简单、灵活且可用的标准。

其他待定义领域：
* 参考SilverScript示例和SDK级别的可组合性
* 关于铸造/销毁/冻结的策略约定
* 稳定币特定约定

欢迎大家提出任何反馈！

KCC20接口

KCC20 令牌是一种实现最小同质化令牌接口的契约实例。

要兼容KCC20，契约必须：

• 保持基本令牌状态：

• 谁是代币数量的所有者

• 他们拥有的数量

• 提供符合KCC20传输规范的传输入口点。

KCC20的相互作用可以归结为两个职责：

• 确定当前KCC20状态

• 创建有效的下一状态交易

这自然分为两个角色。

读者

读者观察已接受的Kaspa交易和项目KCC20状态。

给定已接受的交易和令牌描述符，它识别KCC20活动，解码令牌状态，并维护实时的KCC20 UTXO集合。

作家

写入者消耗读者提供的状态和用户意图。

给定实时的KCC20 UTXO、解码后的令牌状态和令牌描述符，它构建有效的KCC20交易。

令牌描述符

每个已知的KCC20令牌契约都由描述符文件描述。

描述符是根据令牌契约ID定义的，提供识别令牌UTXO、解码其状态、构造契约输出以及构建有效传输输入符号脚本所需的最小信息。

TokenDescriptor {     prefix     suffix     state_layout     leader_entrypoint_selector     delegator_entrypoint_selector } 

prefix和 分别是编码令牌状态前后的脚本字节。suffix

读取器用它们来验证解码状态是否与实际输出锁定脚本相符。

写入者利用它们来重建有效的令牌输出。

state_layout定义了原始状态字节的解码和编码方式。

它必须包含标准的KCC20状态头字段：

• owner_identifier

• identifier_type

• amount

读取器用于解码被接受的状态转换。state_layout

写入者用于编码前后状态。state_layout

leader_entrypoint_selector并用于构建传输事务的输入符号脚本。delegator_entrypoint_selector

读卡器操作

读卡器拥有每个已知KCC20令牌契约的描述符文件。

它跟踪已接受的Kaspa交易，对于每笔输入与注册代币描述符匹配的交易：

1. 识别契约输入领导，按惯例识别第一个契约输入。

2. 从领导输入 sigscript 中提取声明的原始字节数组。next_states

3. 将原始字节解码为状态数组，使用。next_statesstate_layout

4. 验证每个解码后的下一状态与匹配的交易输出。

5. 仅在验证成功后更新实时的KCC20 UTXO集合。

注：转让公约期望通过验证模式的契约声明。传输入口点应具有已知的下一状态形状，写入者在 sigscript 中提供预期的下一状态，入口点验证这些状态，而不是在运行时计算。

读取器不能信任声明的 ，对于每个解码的下一状态，它重建预期的输出脚本并将其与实际输出脚本匹配。next_states

decoded_next_states = decode(next_states_raw, state_layout) for index, next_state in enumerate(decoded_next_states):     encoded_state = encode(next_state, state_layout)     expected_output_p2sh =         P2SH(prefix || encoded_state || suffix)     output_index =         cov_output_index(index)     output_p2sh =         outputs[output_index].spk     assert output_p2sh == expected_output_p2sh 

读取器根据已验证的状态转换更新其令牌UTXO索引。

写手运营

写入者查询读取器最新的令牌状态和描述符，然后根据用户意图创建有效交易。

作者：

1. 从读卡器获取相关的所有者令牌 UTXO。

2. 通过将每个输入与 匹配来验证读取器的索引解码状态。spkP2SH(prefix || encoded_state || suffix)

3. 计算状态转变，生成 和 。prev_statesnext_states

4. 为leader输入创建sigscript。

redeem_script =     prefix || encode(prev_states[0], state_layout) || suffix builder.append(redeem_script) builder.append(leader_entrypoint_selector) for arg in transfer_arguments:     builder.append(arg) 

领导者转移参数包括声明的转换数据：

• next_states

• authorization_data

写入者随后为其他委派输入创建符号脚本：

for prev_state in prev_states[1:]:     redeem_script =         prefix || encode(prev_state, state_layout) || suffix     builder.append(redeem_script)     builder.append(delegator_entrypoint_selector) 

写入者根据以下方式设置输出脚本：next_states

for index, next_state in enumerate(next_states):     encoded_state =         encode(next_state, state_layout)     outputs[cov_output_index(index)].spk =         P2SH(prefix || encoded_state || suffix) 

最后，写入者允许用户签署事务，并将其广播到Kaspa节点。

扩展状态

KCC20令牌状态可以扩展标准KCC20状态头部并带有令牌特定状态。

encoded_state =     encoded_kcc20_state || extension_state_bytes 

通用读写器只需理解标准KCC20头部，通用写入器只需理解KCC20传输约定。

如果输入的扩展状态不同，写入者必须失败，而不是决定如何组合自定义状态。

附加注释

该规范的未来目标是支持一个实用实现，允许使用 SilverScript 与 KCC20 令牌交互和合成。

Explorers应提供一项服务，允许用户揭示代币起源交易并公开预编译的Silver逻辑。这使得部署的令牌契约能够与可见规则进行匹配，进行验证，并通过状态转换随时间执行。