这是一份我想提出的社区讨论稿。它想讨论的不是 “yet another Lightning”，也不是要和 Fiber 比高低，而是一个更贴近 CKB Cell 模型的问题：
如果资金锚点稳定不动，只让签名状态证据在争议时移动，CKB 能不能表达一种更干净的通道和通道工厂结构？
一句话版本：
钱不动，状态动；业务资产不付手续费，费用由 sponsor 支付；只有最终结算时才真正移动通道资产。
思想来源
这个方向借鉴了几条成熟线索。
- Lightning 给出的基本直觉是：大多数支付留在链下，但合作失败时，链上必须能执行最新余额。[1]
- eltoo 给出的直觉是：争议期内，较新的签名状态应该能压过较旧的状态。[2]
- Channel factory 的直觉是：共享一组链上资金，可以在链下承载很多子通道，不必每条通道都单独上链 funding。[3]
- CKB 的特殊之处在于：Cell 本身就是状态对象；脚本可以检查状态变化；
cell_deps可以读取上下文；since可以表达相对等待时间。[4][5][6] - 多资产部分必须尊重 CKB 的现实：capacity、存储占用、xUDT 数量和手续费资金不是一回事，不能混成一个余额。[7][8]
这里需要很谨慎地说：Morph 不是 Bitcoin eltoo 的移植。Bitcoin eltoo 原本依赖 Bitcoin sighash 层面的变化；Morph 借的是“较新状态胜出”的思想，但用 CKB 的 Cell、脚本和相对等待时间来表达。
核心模型
Morph 把一条通道拆成三层。
第一层 是稳定资金锚点。它保存通道身份、参与者、资产信息和结算规则。正常状态推进时，这层不动。
第二层 是状态证据。它记录“现在谁持有多少、处于什么阶段、使用哪套挑战期规则”。争议时移动的是这层。
第三层 是费用赞助。它只负责支付单边发布交易的手续费，不属于通道资产。
这就是全文最重要的拆分：
- 通道资产证明“钱属于这个通道”。
- 签名状态证明“现在该怎么分”。
- 赞助费用证明“这笔链上交易谁来付手续费”。
把这三件事混在一起，单边退出就会变得很难推理。
为什么手续费要单独付
通道参与者签名时，只应该签“通道状态是真的”。他们不应该签具体手续费、钱包找零、选了哪几个 sponsor inputs。
原因很实际：单边关闭时，手续费可能变了，钱包可用 Cell 也可能变了。如果通道状态签名绑定了这些钱包细节，就会出现一个尴尬情况：状态是真的，但交易发不出去，或者需要对方重新签名。
Morph 的做法是把费用层拿出来：
这样，状态包可以复用，交易体可以重建。
这点对 tx-pool 竞争尤其重要。如果旧状态先上链，较新状态的挑战交易不一定能沿用原来的交易体。挑战者或 watchtower 应该能针对当前还活着的状态 Cell 重新组装交易，只复用“较新状态是真的”这份证据。
cell_deps 不是权威本身
cell_deps 很适合给脚本提供只读上下文，但它不是自动的权威证明。
通道状态必须绑定正确的资金锚点。可以绑定具体的 funding outpoint，也可以绑定一个不可变的通道 genesis identity。关键是不能只说“我读到了一个长得像通道描述的 Cell”。
否则，攻击者可能引用一个看起来描述相同、但并不是这条通道真正资金锚点的 Cell。
这条规则可以用人话概括：
只读引用负责“让我看到它”，通道身份绑定负责“确认它就是正确的那个”。
两方通道为什么先用明文
两方通道的状态通常很小：双方余额、少量待完成支付、超时条件和关闭脚本。
第一版没有必要把这些东西全 Merkle 化。明文 witness 有几个好处：
- 容易审计；
- 容易调试；
- 链上看到 force close 时，开发者能直接看懂发生了什么；
- 对小状态来说，proof system 不一定更便宜。
这不是说隐私不重要，而是说两方通道第一版应该优先清楚、便宜、可验证。
通道工厂为什么不能只靠明文
Factory 的情况不同。
一个 factory 可能包含很多参与者、很多子通道和很多局部退出路径。如果每次只处理一个局部分支，却要暴露并验证整个 factory state，那就不太像一个可扩展设计。
因此 factory 更适合用 commitment + proof：
- 链上只看这次被触碰的局部状态；
- 未相关的参与者和子通道不需要暴露；
- 子通道可以先作为 committed state 存在，之后再 materialize 成真实 CKB cells。
当然这里也不能过度承诺。Proof mode 不默认更便宜。只有当 factory 总状态足够大，局部 proof 的验证成本低于暴露完整状态时，它才值得。Proof size、交易大小和 CKB-VM cycles 必须测。
Factory coordination 也不应该假装已经解决。第一版可以保守一些：只要求本次受影响的人对本次触碰的状态签名。Threshold、delegation、committee 这些可以以后再讨论。
挑战期按 CKB-原生 风格设计
这个设计不假设亚秒确认，也不假设很快的最终性。
争议流程应该按 CKB 的确认行为设计：
挑战窗口至少要考虑：
- 等多少确认后才认为某个状态值得响应；
- finalization 的 relative
since应该多长； - watchtower 多久检查一次；
- 主网手续费波动和重组容忍度。
最短安全挑战期不是论文里的常数，而是 CKB 上的产品参数。
多资产里，存储押金和余额要分开
CKB 上最容易出错的地方，是把所有东西都叫“余额”。
实际上至少有三层：
这三层必须分开。
手续费资金是普通钱包资金。它可以换、可以加、可以找零。
通道 reserve 是为了让通道 Cell 存在而锁住的 CKB capacity。它属于通道，但不能被悄悄拿去付手续费。
业务资产是用户真正关心的余额，包括 CKB 业务余额和 xUDT 数量。xUDT 还必须遵守自己的 type script 规则。
一句更强硬的话是：
如果一个通道实现允许 channel-owned capacity 悄悄支付 publication fee，那它的 accounting model 已经不干净了。
Watchtower 不应该托管通道资产
Watchtower 的角色不是保管资金，也不是惩罚对方。
它只需要在看到旧状态上链时，帮用户发布较新的状态证据。
它需要的东西包括：
- 最新状态编号；
- 最新签名状态；
- 能发布状态的 witness 或 proof；
- 费用赞助策略，或者它自己的 sponsor cells。
它不需要拿到通道资产的控制权。
结论
Morph Channel 的核心不是复杂脚本名，也不是一套新 runtime。
它真正想表达的是一个很 CKB 的通道对象模型：
资金锚点稳定，状态证据移动，手续费独立支付，多资产分层守恒，factory 只在需要时验证局部状态。
参考资料
[1] Joseph Poon and Thaddeus Dryja, The Bitcoin Lightning Network: Scalable Off-Chain Instant Payments.
[2] Christian Decker, Rusty Russell, and Olaoluwa Osuntokun, eltoo: A Simple Layer2 Protocol for Bitcoin.
[3] Conrad Burchert, Christian Decker, and Roger Wattenhofer, Scalable Funding of Bitcoin Micropayment Channel Networks.
[4] Nervos RFC 0002, CKB Cell Model.
[5] Nervos RFC 0022, CKB Transaction Structure.
[6] Nervos RFC 0017, since Field.
[7] Nervos RFC 0025, Simple UDT.
[8] Nervos Talk, RFC: Extensible UDT.
