引言：一个协议的构建起源
上一篇文章里，我把 Amboss 拆开来看了一遍。拆完之后留下一个问题：如果 Amboss 的中心化不是它自己的选择，而是被比特币脚本的能力边界给逼出来的，那换一条链呢？
这就是 Opticrum 的起点。不是「我要做一个更好的 Amboss」，而是「如果流动性市场可以重新设计，它应该长什么样」。
我的目标很具体，在 CKB 上构建一个入金流动性租赁市场——买方需要更大的收款额度，卖方愿意出借通道容量换取收益，双方不需要把资金托管给任何第三方。
不在于「能不能做出来」，而在于「能不能在完全去中心化的前提下做出来」。Amboss 用平台担保解决了信任问题，但 Opticrum 可以有更好的选择。
第一章：链上身份绑定——MuSig2 聚合签名方案
我从最关键的环节开始。
Amboss 为什么要做中心化托管？因为链上没法验证「卖方到底有没有真的给买方开通道」。买方把钱交给了 Amboss，Amboss 确认通道存在之后才放款给卖方。这个「确认通道存在」的动作，在比特币上只能由人来做，脚本做不到，但 CKB 的合约脚本理论上是有能力验证的。
所以我问自己一个问题：**能不能让链上合约自己判断一条 Fiber 通道是不是真的服务于某一笔订单？**如果能，Amboss 的整个托管层就可以被删掉。
我的第一个方案是通过密码学的思路去解决：
- 买方发布一个链上 Order Cell，塞入自己的 Fiber 公钥。
- 卖方扫描链上 Order Cell，找到合适的订单后创建一条 Fiber 通道，再使用该通道创建 Match Cell，也塞入自己的 Fiber 公钥。
- 假设 Fiber 通道的锁定脚本是通过 MuSig2 聚合签名把通道两端的 Fiber 公钥聚合起来的，那就能通过聚合买卖双方的 Fiber 公钥来实现通道身份验证。
这样，Opticrum 合约就不需要信任任何人，因为它能自己亲自检验通道的归属。
测试用例跑通了，却遇到一个很现实的问题：这条路从一开始就走不通。
第二章：Fiber 的隐私设计——一次性通道身份
Fiber 在创建通道时，参与密钥协商的公钥不是节点运营者固定的身份公钥，而是双方基于一个临时协商的种子随机生成的密钥，只有通道双方才知道。
你可以把它理解成一个每次入住都会更换的房间号，酒店大堂永远在那里，但你每次拿到的那把钥匙上面的号码都是新的，外人看到房号，无法反推住在里面的是谁。
同样，Fiber 通道的聚合密钥每一次都是全新的，与通道双方的节点公钥没有任何关系。
这意味着，我设计的 MuSig2 聚合验证方案，从一开始就不成立：我可以在链上证明通道存在，但无法证明通道的归属，因为 Fiber 的通道身份是一次性的。
这是一个分水岭时刻，我意识到自己撞上了南墙——不是技术实现的墙，而是协议假设的墙——试图在链上通过密码学完整验证 Fiber 的通道归属，从根上就是一个伪命题。
好，那然后呢？
第三章：从密码学到博弈论——赋予买方作恶权
既然无法在链上证明通道归属，那就必须接受一个现实，那就是卖方在技术上永远可以用一条不相干的通道来匹配订单，因为 Opticrum 合约已无法检验链下通道的真伪。
所以问题变成了：不能阻止卖方作恶，但能不能让作恶变得毫无意义？答案是同样赋予买方作恶的权力。
买方拥有随时撤回全部未消耗租金的权利，这把通道检验的责任从链上合约转移到了流动性买方，于是买方自己判断卖方匹配的通道是不是指向自己，如果不是，可随时撤回。
买方会不会恶意撤回？理论上可以，但没有这个动机。买方已提前质押了租金到订单中，恶意撤回的最大受害者其实是自己。买家的 “撤回权” 就像是一把 达摩克利斯之剑，悬在卖方头上。一旦作恶，随时都会斩下。
反过来，卖方仍然可以选择作恶，拿假通道骗几期租金，但买方一旦发现通道无法收款，撤回操作几乎是即时发生的——这意味着卖方全部的未来收益将归零。短期骗租的收益，其实远比不上长期提供真实通道所产生的累积收益。
第四章：工程化实践——从用户视角出发
Opticrum 的系统架构围绕买方和卖方两套日常操作逻辑展开。
买方的日常操作很简单：
- 在 Fiber Wallet 中输入期望的通道容量和目标年化收益率，钱包调用 SDK 构建 Order Cell 创建交易，签名后发送上链
- 钱包持续扫描链上状态：当 Order Cell 被消耗、对应 Match Cell 产生时，通道已开通
- 买方随时可通过 SDK 发起撤回交易，将 Match Cell 中未消耗的租金提取回自己的地址
- 从头到尾，买方只和钱包交互，钱包只和 SDK 交互，SDK 背后是链上合约在执行规则
卖方的日常操作需要更完整的工具链：
- 卖方在一台服务器上同时运行 Fiber 节点和 Opticrum 后端，两者结伴工作
- 后端通过 CKB 节点持续扫描链上 Order Cell，过滤符合收益率要求的订单；通过 Fiber 节点管理通道的创建与关闭
- 三个后台调度器：
- 链上索引保持订单和匹配状态的实时缓存
- 租金提取按周期自动对名下 Match Cell 执行提取交易
- 自动匹配自主完成通道创建与订单匹配
- 卖方通过 Web 控制台管理整个流程——控制台是响应式页面，手机和桌面端同一套界面，不需要 SSH 进服务器，直观方便
SDK 是连接两端的桥梁：
- 同一套 Rust 代码库，核心逻辑完全共享：类型定义、交易构建、状态扫描
- 通过条件编译产出两个目标：
wasm-bindgen→ WebAssembly，供浏览器端钱包集成UniFFI→ iOS Swift / Android Kotlin 原生绑定，供移动端钱包集成
- 不存在平台分支维护，同一套逻辑覆盖所有运行环境
第五章：一个小小的愿望
CKB 过去几年的发展，大部分注意力都压在底层的共识优化和虚拟机升级上，却忽略了面向终端用户的应用生态建设。底层网络的重要性毋庸置疑，但一个网络最终能不能被人用起来，取决于它上面有没有人在盖房子。底层框架和上层生态，是一体两面的事情。
Fiber 现在还处于非常早期的阶段，这反而是一个机会窗口：在基础设施建设的同时，把应用生态一起拉起来。入金流动性只是其中一个具体的切口，但它背后折射的问题更普遍：没有服务层，用户进不来。
Opticrum 不需要什么宏大叙事，它只是我在这个方向上做的一次很小的尝试：
- 一份合约
- 一个 SDK
- 一台能给卖方省点力气的后端
如果它能让大家意识到 Fiber 的生态建设也需要有人去做、也可以从今天就开始做，那它的目的就达到了。
我也希望看到更多人在 Fiber 上做应用层的探索——钱包、市场、自动化工具、数据分析，甚至跟 Opticrum 完全无关的东西。底层是骨架，应用是血肉，少了哪一样，Fiber 都不可能站起来。
结语
入金流动性问题，是任何一个支付通道网络都绕不过去的坎。它扮演着一个默默无闻的角色——不是共识算法，不是跨链桥，不是 DeFi 协议，只为商家接入网络提供便利。
Opticrum 合约已经部署在 CKB 测试网上，以下是它的项目仓库：
- Opticrum/ckb-contract-script — 链上 RISC-V 合约
- Opticrum/client-sdk — 多平台 SDK（WASM + UniFFI）
- Opticrum/daemon-server — 卖方服务器与管理控制台
在密码学走不通的地方，博弈论可以派上用场——变通不是妥协，是协议设计的本质。