[Fiber] CKB 能让 Fiber 拥有更好的 Amboss

中文 生态与应用
1

我在调研闪电网络的生态应用时，惊讶的发现了 Amboss 这个项目，它的核心功能就是为闪电网络节点提供 “入向” 流动性，简单地说，就是为商家提供更大的收款额度。

在此基础之上，Amboss 将因为闪电网络固有的协议特性而带来的限制，转化为流动性市场，成为了闪电网络生态中为数不多的 Defi 项目，着实令人眼前一亮。

收款额度 这个问题目前主要有两种解决思路:

  1. JIT (Just-In-Time Channel，即时通道) 思路。也就是透过 LSP 服务商，在检测到要为某个钱包节点转账但对方却没有足够入金额度时，即时建立一条有足够额度的通道。

  2. 流动性市场思路。也就是 Amboss 的思路，将入金额度金融化和市场化，任何需要扩展自己入金额度的节点都可以通过平台付费购买。

很显然，JIT 思路是典型的基建思维，但 Amboss 提供的思路确是实打实的生态思维，它将 “年化收益率” 的概念首次引入到闪电网络生态，对闪电网络的金融活跃度提供了积极帮助。

但 Amboss 在我看来还是有些问题。

Amboss 的中心化问题

小明开了店铺，他下载了闪电网络钱包想要收取比特币，但他发现自己没有入金额度。

于是小明打开了 Amboss 网站，告诉 Amboss “我想要 1 个比特币的入金额度，愿意支付 0.0005 个比特币作为手续费”，于是 Amboss 开始从它的平台上寻找流动性贩卖方，最后找到了小王。

小王能够提供超过 1 个比特币的流动性，于是 Amboss 撮合小明与小王进行交易，Amboss 作为平台方提供担保：小明支付小王 0.0005 个比特币，小王即刻为小明开通 1 个比特币容量的通道，保证通道稳定运行 30 天。

如果小王收了钱但没有开通道，或者通道没有开够 30 天，那小王在 Amboss 平台上的保证金就需要扣除，并且他的声誉也会受到打击，以后就没人愿意再找他合作了。

Amboss 的核心职责有 3 个：

  • 匹配通道流动性的买方与卖方

  • 作为中间角色，保证买卖双方的 “买方付租金与卖方开通道” 的撮合操作的原子性

  • 时刻监控卖方的通道能稳定足额的运行 30 天，因为 30 天的租金是一次性结算的

我们一个一个的来说。

匹配的中心化对于 Amboss 来说是不可避免的，因为买方没办法直接在链上发布订单，因此始终需要一个平台服务型的地方。

撮合的中心化就涉及到由 Amboss 生成 Invoice 和 Preimage，然后只把 Invoice 给予卖方，待卖方在链上创建了通道后，Amboss 才把 Preimage 发给卖方，整个过程买方的资产都暂存在 Amboss 处。

监控的中心化也是因为需要 Amboss 负责时刻监控通道的链上状态，是否额度降低或者是否关闭，因为买方已经提前将 30 天的租金给予了卖方，Amboss 有义务提供售后服务。

Amboss 的遗憾

可以把 Amboss 想像成闪电网络上的只针对 “流动性” 这一单一商品的淘宝平台，卖方在上面上架自己的流动性商品，买方出钱租赁，那 Amboss 自然就需要在交易时暂存资金，在交易后提供售后服务。

虽然 Amboss 这个项目令我感到惊艳，但同时它也有让我觉得遗憾的地方，最根本的原因是受限于比特币网络的可编程能力，毕竟非图灵完备系统的可编程上限是肉眼可见的，况且还有 10 分钟一个块的出块间隔，这让 Amboss 的核心信任机制需建立在中心化的体系上。

其实为了对抗中心化的弊端，Amboss 同时引入了 “保证金 + 声誉系统”，通过保证金与声誉来限制卖方作恶，但不管怎样，买方仍然需要信任 Amboss 这个中间平台。

如果 Amboss 运行在 CKB 上，我想它是完全有能力做到完全去中心化的。

如果 Amboss 运行在 CKB 上呢？

Amboss 的核心职责可以直接借由 CKB 的图灵完备特性打造成完全的去中心化系统。

我们一个一个的来分析。

匹配的中心化。如果在 CKB 上开发一个链上合约，所有买方的流动性购买需求都通过 Amboss 合约形成一个个独立的 Cell，那卖方就只需要在链上搜索这些需求 Cell 就行。这能避免中心化匹配的问题。

撮合的中心化。如果采用闪电网络进行付款，那一定逃不过 Invoice 和 Preimage 的托管问题，因为目前闪电网络和 Fiber 都没有编程能力，但如果直接通过 CKB Layer1 实现租金的支付，那貌似就没有这个问题了。我们直接将买方需求的通道额度和租金同时塞入一个需求 Cell 中，卖方通过消耗这个 Cell 来创建通道，那撮合的原子性就能自动实现了。

监控的中心化。为什么会有监控需求，还不是因为租金一次性都给了卖方。如果我们将通道存续的时间换算成区块数量写入到需求 Cell 中，卖方不能一次性将租金全部拿走，而是需要拿着通道存在的证明定期提交租金提款交易，那这样就不存在监控的问题了，因为如果通道提前撤销，那剩余的租金卖方是拿不出来的，而买方在到期后可以一次性提取出来。

让我们着手设计一下

我们就将该系统命名为 Opticrum 吧。

首先我们需要设计一个系统合约（Opticrum Script），由流动性购买方首先创建订单 Cell：

#1. Order Cell

Capacity:
	<CKB Amount>
Data:
	<xUDT Amount> #Present or Placeholder
	#<xUDT Data> Disabled to present, prohibited to use in Opticrum
Lock:
	Code Hash:
		Opticrum Script
	Hash Type:
		Type
	Args: #Order Info
		<Fiber Pubkey>
		<Buyer Pubkey Hash>
		<Channel Capacity>
		<Escrow Blocks>
Type:
	xUDT Script #Optional
		
		
#2. Order Cell Creation Tx

Inputs:
	Buyer Cell
Outputs:
	Opticrum Order Cell

解释：

  • 如果 xUDT 资产不为空，则代表购入该资产的入金流动性，否则默认为购入 CKB 的入金流动性

  • Escrow Blocks 表示通道锁定时间换算成的区块数量

  • 若该 Cell 未成交，则买方可以随意撤销

  • 把 Fiber Pubkey 排在最前面是为了方便根据 Fiber 公钥信息进行过滤

  • 当合约以 “订单” 状态被执行时，会检查交易输出中是否包含指定容量的通道 Cell 和转为 “成单” 状态的成单 Cell

流动性提供方可在链上查看全网所有的流动性买单，找到年化收益率最高的一单进行交易。当订单成交后，由流动性贩卖方消耗需求 Cell 并创建成单 Cell：

#1. Match Cell

Capacity:
	<CKB Amount>
Data:
	<xUDT Amount> #Present or Placeholder
	<Match Created Blocknumber> #Updated once at first extraction
	<Last Extraction Blocknumber> #Updated when extracting
Lock:
	Code Hash:
		Opticrum Script
	Hash Type:
		Type
	Args: #Match Info
		<Fiber Pubkey>
		<Buyer Pubkey Hash>
		<Channel Capacity>
		<Escrow Blocks>
		<Channel Lock Hash>
		<Seller Pubkey Hash>
Type:
	xUDT Script #Optional


#2. Match Cell Creation Tx

Inputs:
	Seller Cell
	Opticrum Order Cell
Outputs:
	Channel Cell
	Opticrum Match Cell

解释：

  • Channel Lock Hash 为创建的通道 Cell 的锁定脚本哈希值

  • Match Created Blocknumber 需要在第一次提取交易中设置为成单 Cell 所在的区块号

  • Last Extraction Blocknumber 如果为 0 则表示该成单未被提取过租金

  • 当卖方提供通道存续证明时，可从该 Cell 中根据区块高度按比例提取租金

  • 买方能在该 Cell 过期时解锁并销毁，若卖方在此之前未能把租金全部提取出来，损失自负

  • 当合约以 “成单” 状态被执行时：

    • 如果未过期，则检查交易输入中是否包含卖方的 Lock，交易输出中是否包含 “更新后” 的成单 Cell 且其租金是否按规定被提取

    • 如果已过期，则检查交易输入中是否包含卖方或买方的 Lock，成单 Cell 是否在交易里被消耗

流动性提供方需要定期发起租金提取交易，以确保在订单失效前自己能收回全部租金，否则未收回的租金可能会被买方撤回：

#1. Seller Regular Extraction Tx

CellDep:
	Channel Cell
HeaderDep:
	Header of Channel Cell
	Tip Header
Inputs:
	Opticrum Match Cell
		Capacity:
			<CKB Amount>
		Data:
			...
			<Blocknumber>
	Seller Cell
Outputs:
	Opticrum Match Extracted Cell
		Capacity:
			<Extracted CKB Amount>
		Data:
			...
			<Blocknumber of Tip Header>
	Seller Extracted Cell
	
	
#2. Buyer Destroy Tx

HeaderDep:
	Tip Header
	Header of Match Cell #Optional, present if no extraction happens
Inputs:
	Opticrum Match Cell
	Buyer Cell
Outputs:
	Buyer Extracted Cell

为什么会取名为 Opticrum？这是由两个单词拼接得来，一个是 ”Optic“，另一个是 ”Fulcrum“，代表 Fiber 生态中的光学支点。为生态解决 “入金流动性” 问题是任何一个闪电网络系统里都不可避免需要考虑的问题，这就像是一个支点，撬动起整个生态往前走。

配套设施也要跟上

当我们把 Opticrum 部署到 CKB 链上后，很自然地需要为买方和卖方开发相应的 SDK 或者服务，让这套系统可以去中心化的运作起来。

对于流动性提供方，大多数情况下会在服务器上部署自己的 Fiber 节点。所以针对卖方，我们需要提供能独立运行的 Opticrum 服务器，能同时连接 CKB 节点和 Fiber 节点，如果可以的话，最好还能提供 Web 控制台界面：

  1. 在 CKB 网络上

    1. 监听流动性订单 Cell 的创建，自动或手动完成订单匹配操作

    2. 维护已完成匹配的成单 Cell，自动或手动完成租金提取操作

  2. 在 Fiber 网络上

    1. 发起通道创建请求，获得通道创建的交易，对该交易进行修改整合 Opticrum 相关合约

    2. 维护已创建的通道

对于流动性购买方，我们提供简单的 SDK 以集成进 Fiber Wallet 中或者任意 DApp 中，实现 Opticrum 订单 Cell 的创建和成单 Cell 的维护即可。

但，别高兴得太早

Opticrum 的设计在理论上是可行的，如果能开发出来，那就是完全去中心化版的 Amboss，但遗憾的是，对于当前的现实情况，Fiber 上的一个点会让 Opticrum 的开发遇到一些阻碍。

那就是 Fiber 目前还不支持自定义拓展通道创建交易，这会导致我们无法将 Opticrum 合约整合进通道创建交易中。

对于这个问题，我们可以通过将 “通道创建“ 与 “在 Opticrum 上成单“ 分成两步走，先用 Fiber 创建通道，然后再用创建好的通道 Cell 来匹配订单 Cell，不会影响去中心化特性，但原子性会打折扣。

我相信，随着 Fiber 开发进度的推进，自定义通道交易拓展功能迟早会拿上台面。

让我们一起期待 Fiber 的发展！

18 Likes
CKB Ecosystem Biweekly Update